Модель анализа и классы анализа.
Классы анализа.
Модель анализа является абстракцией для модели проектирования. Служит для того, чтобы последовательно приблизиться к модели проектирования. Необязательна в сложных системах. Не сохраняется в проекте, т.к. неоднозначная, промежуточная.
Решаемые задачи:
1.учитывается взаимодействие прецедентов
2.прецедентам дается формальное описание в виде различного вида диаграмм (активности, последовательности, сотрудничества)
3.выделяются общие и внутренние ресурсы системы
4.разрабатывается первый вариант архитектуры системы.
В модели анализа язык разработчиков состоит из классов анализа:
1.классы анализа не определяют сигнатуру метода, т.е. в целом представляется что класс будет делать, но не детально. Поведение класса определяется в виду ответственности.
2.класс анализа определяет только атрибуты более высокого уровня
Стереотипы:
- граничный класс
- моделирует взаимодействие между системой и актантом
- может быть абстракцией интерфейса пользователя
- абстракция программного интерфейса
- абстракция коммуникационных интерфейсов
- не содержит физической реализации
- должен быть связан хотя бы с одним актантом
- объекты живут во время выполнения прецедента
- класс сущности – моделирует информацию, которая существует в системе некоторое время, в том числе хранимую длительное время. Класс сущности является отображением классов предметной области. Объекты живут между прецедентами.
|
|
|
- управляющий класс – моделирует управление, соответствующее одному или нескольким прецедентам. Объекты живут во время выполнения прецедента.
Варианты управляющих классов:
1) один прецедент – один класс
2) объединение прецедентов в один класс
3) граничный класс представляет одну сущность, тогда функции управляющего класса передаются граничному классу
Архитектурное представление.
1.Логическое представление – подмножество модели проектирования, которое содержит наиболее значимые классы и их распределение по пакетам и подсистемам.
2.Представление развертывания – подмножество модели реализации, описывающее ответственность физических узлов; развертывание и распределение задач, процессов и потоков по узлам.
3.Представление реализации – подмножество модели реализации, описывающее ПО в терминах пакетов, а также распределение классов и пакетов по модулям. Если пакеты заимствуются из модели проектирования, то это представление отсутствует.
4.Представление процессов – содержит описание задач, их взаимодействие и конфигурацию.
5.Представление данных – подмножество модели данных.
|
|
|
В архитектурных представлениях фиксируются устойчивые характеристики системы, которые необходимы для решения следующих задач:
1.Эволюция системы (переход к очередному циклы разработки)
2.Повторное использование архитектуры в линейке программных продуктов.
3.Оценивание дополнительных показателей (производительность, надежность)
4.Назначение работы командам сотрудников.
5.При разработке принимаются решения включения в проект готовых программных продуктов.
Дата добавления: 2018-06-01; просмотров: 276; Мы поможем в написании вашей работы! |
Мы поможем в написании ваших работ!