Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
TPISPP_MOYe_FINAL.doc
Скачиваний:
6
Добавлен:
28.10.2018
Размер:
151.55 Кб
Скачать

5.Основи мови uml. Сутності uml.

UML – это стандартизованный язык для создания рабочих чертежей программирования. UML это язык для

-Визуализации,

-Спецификации,

-Конструирования,

-Документации артефактов программной системы.

В UML задействованы три типа блоков: 1.Сущность (things)

2.Отношение (relationships) (зависимость, ассоциация, обобщение, реализация).

3.Диаграмма (diagrams).

Cущности являются основой модели, отношения обеспечивают их привязку друг к другу, а диаграммы группируют наборы сущностей.

В UML представлены четыре типа сущностей:

-Структурные

-Поведенческие

-Групповые

-Аннотационные.

7 типов структурных сущностей:

1.Класс-это набор объектов которые используют одни и те же атрибуты, операции, отношения и семантику.

2.Интерфейс-это набор операций которые специфицируют услуги класса или компонента. Т.е. интерфейс описывает поведение элемента.

3.Cотрудничество-определяет взаимодействия и является сообществом ролей и других элементов, которые работают вместе для обеспечения некоторого совместного поведения, которое больше, чем совокупность всех элементов. Класс может участвовать в нескольких сущностях сотрудничества.

4.Актёр-пользователь системы – набор согласованных ролей.

5.Cценарий использования (Use Case) описывает набор последовательностей действий, которые выполняются системой и дают результат с конкретным значением для конкретного участника (actor).

5.Активный класс- это класс, объекты которого владеют одним или более процессами и могут инициировать управляющие воздействия.

6.Компонент-физическая и перемещаемая часть системы, которая удовлетворяет и обеспечивает реализацию набора интерфейсов. 

7.Узел- физич. элемент, который существует в момент исполнения действий системы и представляет вычислительный ресурс, содержащий некоторую память и способность к обработке данных.

Поведенческие сущности (динамические составляющие UML-модели).

1.Взаимодействие включает набор сообщений, передаваемых внутри набора объектов.

2.Машина состояний – поведение, кот-е определяет последов-ть состояний объекта или взаимодействия, выполняемые в ходе его существ-ия в ответ на события.

Групповые сущности это “ящики”, на кот-е может быть осуществлена декомпозиция модели. Пакет- это механизм общего назначения для организации элементов в виде единой группы.

Аннотационные сущности - поясняющая и комментирующая часть UML. Типом ан. сущности является примечание. 

6.Шаблони проектування (патерни), їхні види й використання при розробці архітектури програмного забезпечення.

Кооперации (сотрудничества) являются средством представления комплексных решений в разработке ПО на высшем, архитектурном уровне. Кооперации содержат две составляющие — статическую (структурную) и динамическую (поведенческую). Статическая составляющая кооперации задает структуру классов,интерфейсов, компонентов. Динамическая составляющая определяет поведение элементов. Настраиваемые кооперации называют паттернами (образцами). Паттерн является решением типичной проблемы в определенном контексте. Паттерны рассматриваются как крупные строительные блоки. Их использование приводит к существенному сокращению затрат на анализ и проектирование ПО. Паттерны — это наборы готовых решений, предлагающиеся к повторному использованию. Паттерн Наблюдатель задает между объектами такую зависимость «один-ко-многим», при которой изменение состояния одного объекта приводит к оповещению и обновлению всех зависящих от него объектов. Паттерн Компоновщик обеспечивает представление иерархий часть-целое, объединяя объекты в древовидные структуры. Паттерн Команда выполняет преобразование запроса в объект. Шаблон не может участвовать в большинстве обычных отношений между классами. Существует всего два вида отношений, в которых он может участвовать – связи между шаблоном и классом, порожденным от него подстановкой параметров, и направленные ассоциации. Направленная ассоциация должна идти в направлении от шаблона.

По степени подготовленности к тестированию:

  • Тестирование по документации

  • Тестирование ad hoc или интуитивное тестирование

Уровни тестирования

  • Модульное тестирование (юнит-тестирование) - тестируется минимально возможный для тестирования компонент, например, отдельный класс или функция. Часто модульное тестирование осуществляется разработчиками ПО.

Интеграционное тестирование — тестируются интерфейсы между компонентами,

  • подсистемами. При наличии резерва времени на данной стадии тестирование ведётся итерационно, с постепенным подключением последующих подсистем.

  • Системное тестирование — тестируется интегрированная система на её соответствие требованиям.

  • Альфа-тестирование — имитация реальной работы с системой штатными разработчиками, либо реальная работа с системой потенциальными пользователями/заказчиком. Чаще всего альфа-тестирование проводится на ранней стадии разработки продукта, но в некоторых случаях может применяться для законченного продукта в качестве внутреннего приёмочного тестирования. Иногда альфа-тестирование выполняется под отладчиком или с использованием окружения, которое помогает быстро выявлять найденные ошибки. Обнаруженные ошибки могут быть переданы тестировщикам для дополнительного исследования в окружении, подобном тому, в котором будет использоваться ПО.

  • Бета-тестирование — в некоторых случаях выполняется распространение версии с ограничениями (по функциональности или времени работы) для некоторой группы лиц, с тем чтобы убедиться, что продукт содержит достаточно мало ошибок. Иногда бета-тестирование выполняется для того, чтобы получить обратную связь о продукте от его будущих пользователей.

  • Часто для свободного/открытого ПО стадия альфа-тестирования характеризует функциональное наполнение кода, а бета-тестирования — стадию исправления ошибок. При этом как правило на каждом этапе разработки промежуточные результаты работы доступны конечным пользователям.

  • Создается экономическое обоснование (business case).

  • Определяются основные требования, ограничения и ключевая функциональность продукта.

  • Создается базовая версия модели прецедентов.

  • Оцениваются риски.

При завершении начальной фазы оценивается достижение вехи целей жизненного цикла, которое предполагает соглашение

заинтересованных сторон о продолжении проекта.

Соседние файлы в предмете [НЕСОРТИРОВАННОЕ]