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

Классы анализа.

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

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

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

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

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

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

В модели анализа язык разработчиков состоит из классов анализа:

1. классы анализа не определяют сигнатуру метода, т.е. в целом представляется что класс будет делать, но не детально. Поведение класса определяется в виду ответственности.

2. класс анализа определяет только атрибуты более высокого уровня

Стереотипы:

- граничный класс

- моделирует взаимодействие между системой и актантом

- может быть абстракцией интерфейса пользователя

- абстракция программного интерфейса

- абстракция коммуникационных интерфейсов

- не содержит физической реализации

- должен быть связан хотя бы с одним актантом

- объекты живут во время выполнения прецедента

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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