Модель анализа вариантов использования
Модель анализа строится на основе разработанных вариантов использования и модели предметной области. Модель анализа является основой для проектирования системы.
Анализ вариантов использования включает в себя:
идентификацию классов, участвующих в реализации потоков событий вариантов исользования;
распределения поведения, реализуемого вриантом использования, между классами;
определение атрибутов (свойств) и ассоциаций классов.
В процессе анализа в потоках событий выявляются классы следующих стереотипов:
граничные классы (Boundary) – служат посредниками при взаимодействии внешних объектов с системой. Обычно это классы интерфейса пользователя, систмного и аппаратного интерфейсов;
классы-сущности (Entity) – представляют собой понятия разрабатываемой системы (соответствуют классам модели предметной области);
управляющие классы (Control) – обеспечивают координацию поведения объектов в системе.
Классы анализа отражают функциональные требования к системе и моделируют объекты предметной областии. Совокупность классов анализа представляет собой концептуальную модель системы.
Проектирование
Целью объектно-ориентированного проектирования является адаптация концептуальной модели (совокупность классов анализа), составляющей стабильную основу архитектуры системы, к среде реализации с учетом всех нефункциональных требований.
Проектирование включает в себя:
идентификацию архитектурных решений и механизмов;
выявление подсистем и интерфейсов на основе анализа взаимодействий между классами анализа;
формирование архитектурных уровней;
проектирование конфигурации системы;
детализация классов, уточнение их операций и атрибутов, а также моделирование состояний системы и уточнение взаимосвязей между классами.
Модель проектирования
Модель проектирования – это объектная модель, которая описывает физическую реализацию вариантов использования.
Модель проектирования представляет собой иерархию подсистем проектирования, содержащих классы проектирования, проекты реализаций вариантов использования и интерфейсы. Для данной модели характерны следующие особенности:
специфична для данной реализации;
стереотипы классов модели зависят от выбранного языка реализации;
многоуровневая, динамическая и формализованная;
должна поддерживться в течение всего жизненного цикла системы;
в процессе визуальной разработки находиться в тесной связи с моделью реализации.
Основой для разработки классов проектирования является диаграмма классов. Диаграмма классов (design class diagram) иллюстрирует спецификации программных классов и интерфейсов (например, интерфейсов Java, С#) в приложении. Обычно на такую диаграмму выносится следующая информация:
классы, ассоциации и атрибуты;
интерфейсы со своими операциями и константами;
методы и зависимости.
Пример диаграммы классов (с учетом классов среды разработки MS Visual Studio) приведен на рисунке 4.9. В отличие от диаграммы классов из модели предметной области, диаграммы классов проектирования отображают определения программных сущностей, а не понятия предметной области (рисунок 4.10).
Рисунок 4.9 – Диаграмма классов проектирования
Рисунок 4.10 – От классов предметной области к классам проектирования
Класс проектирования может быть реализован в выбранном языке проектирования как интерфейс.
Обычно классы проектирования неактивны. Это значит, что все их объекты «запускаются» в одном адресном пространстве под управлением другого активного объекта.
Класс проектирования может быть активным, т.е. объекты этого класса будут использовать свой собственный поток (нить) управления, работая параллельно с другими активными объектами.
Для описания взаимодейсвия классов проектирования используются диаграммы взаимодействия (последовательности, коммуникации) и состояний. Пример диаграммы состояний приведен на рисунке 4.11.
Ахитектурно значимым в модели проектирования обычно считается декомпозиция модели проектирования на подсистемы, интерфейсы и зависимости между ними (пример на рисунке 4.12). Эта декомпозиция очень важна, так как перечисленные артефакты образуют общую структуру системы.
Рисунок 4.11 – Диаграмма состояний
Рисунок 4.12 – Декомпозиция системы на подсистемы (диаграмма пакетов)
В структурном проектировании, когда главное внимание уделяется функциональности системы, для отображения архитектурных решений можно использовать схему взаимодействия программ (пример на рисунке 4.13)
Рисунок 4.13 – Схема взаимодействия программ (ГОСТ 19.701-90)