Жизненный цикл программной системы. Этапы проектирования ПС, страница 5

6.  Отношения между прецедентами.

Обобщение, расширение, включение.

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

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

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

1. учитывается взаимодействие прецедентов
2. прецедентам дается формальное описание в виде различного вида диаграмм (активности, последовательности, сотрудничества)
3. выделяются общие и внутренние ресурсы системы
4. разрабатывается первый вариант архитектуры системы.

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

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

Стереотипы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Логическое представление – подмножество модели проектирования, которое содержит наиболее значимые классы и их распределение по пакетам и подсистемам.
2. Представление развертывания – подмножество модели реализации, описывающее ответственность физических узлов; развертывание и распределение задач, процессов и потоков по узлам.
3. Представление реализации – подмножество модели реализации, описывающее ПО в терминах пакетов, а также распределение классов и пакетов по модулям. Если пакеты заимствуются из модели проектирования, то это представление отсутствует.
4. Представление процессов – содержит описание задач, их взаимодействие и конфигурацию.
5. Представление данных – подмножество модели данных.

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

1. Эволюция системы (переход к очередному циклы разработки)
2. Повторное использование архитектуры в линейке программных продуктов.
3. Оценивание дополнительных показателей (производительность, надежность)
4. Назначение работы командам сотрудников.
5. При разработке принимаются решения включения в проект готовых программных продуктов.

9.  Диаграмма сотрудничества для модели анализа.

10.  Диаграмма последовательности.