5. Модель анализа и классы анализа.

• Цель: добиться понимания требований в той степени, которая необходима для представления системы в целом, включая архитектуру.

• Результат: объектная модель анализа, начальный вариант архитектуры системы

Модель анализа является абстракцией для модели проектирования. Служит для того, чтобы последовательно приблизиться к модели проектирования. Необязательна в сложных системах. Не сохраняется в проекте, т.к. неоднозначная, промежуточная.

Решаемые задачи:

1. учитывается взаимодействие прецедентов

2. прецедентам дается формальное описание в виде различного вида диаграмм (активности, последовательности, сотрудничества)

3. выделяются общие и внутренние ресурсы системы

4. разрабатывается первый вариант архитектуры системы.

Классы модели анализа – определяют ответственности на высоком уровне абстракции (без детализации методов и конкретных атрибутов). Используются следующие стереотипы классов:

• Граничные – моделируют взаимодействие между системой и актантом (запросы и получение информации). Запросы актантов – системные операции. Может быть абстракцией интерфейса пользователя, программного или коммуникационного интерфейсов, не содержит физической реализации, должен быть связан хотя бы с одним актантом. Объекты живут во время выполнения прецедента.

• Классы сущностей – моделируют информацию, существующую некоторое время. Как правило классы сущностей получаются из классов предметной области. Объекты живут между прецедентами.

• Управляющие – моделируют управление другими объектами (граничных классов и классов сущности). Управляющий класс может соответствовать одному или нескольким вариантам использования. Объекты живут во время выполнения прецедента.

Варианты управляющих классов:

1. один прецедент – один класс

2. объединение прецедентов в один класс

3. граничный класс представляет одну сущность, тогда функции управляющего класса передаются граничному классу

6. Архитектурное представление.

1. Логическое представление – подмножество модели проектирования, которое содержит наиболее значимые классы и их распределение по пакетам и подсистемам. Представляет интерес для пользователей (с точки зрения функциональности), а также для аналитиков и тестеров (поведение системы)

2. Представление развертывания – подмножество модели реализации, описывающее ответственность физических узлов; развертывание и распределение задач, процессов и потоков по узлам. Рассчитано на системных инженеров (системная топология, установка, связь).

3. Представление реализации – подмножество модели реализации, описывающее ПО в терминах пакетов, а также распределение классов и пакетов по модулям. Если пакеты заимствуются из модели проектирования, то это представление отсутствует. Представляет интерес для программистов (управление ПО).

4. Представление процессов – содержит описание задач, их взаимодействие и конфигурацию. Интересует системных интеграторов (производительность, масштабируемость, пропускна способность).

5. Представление данных – подмножество модели данных.

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

1. Эволюция системы (переход к очередному циклы разработки)

2. Повторное использование архитектуры в линейке программных продуктов.

3. Оценивание дополнительных показателей (производительность, надежность)

4. Назначение работы командам сотрудников.

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