Декомпозиция системы на подсистемы реализует принцип модульности (см. подразд. 2.4.1). Целями такой декомпозиции являются:
· повышение уровня абстракции системы;
· декомпозиция системы на части, которые могут независимо: конфигурироваться или поставляться;
разрабатываться (при условии стабильности интерфейсов);
размещаться в распределенной среде;
изменяться без воздействия на остальные части системы;
· разделение системы на части из соображений ограничения доступа к основным ресурсам;
· представление существующих продуктов или внешних систем (компонентов), которые не подлежат изменениям-
Первым действием архитектора при выявлении подсистем является преобразование классов анализа в проектные классы (design classes). По каждому классу анализа принимается одно из двух решений:
· класс анализа отображается в проектный класс, если он простой или представляет единственную логическую абстракцию;
· сложный класс анализа может быть разбит на несколько классов, преобразован в пакет или в подсистему.
Объединение классов в подсистемы осуществляется, исходя из следующих соображений:
· функциональная связь: объединяются классы, участвующие в реализации варианта использования и взаимодействующие только друг с другом;
· обязательность: совокупность классов, реализующая функциональность, которая может быть удалена из системы или заменена на альтернативную;
· связанность: объединение в подсистемы сильно связанных классов;
· распределение: объединение классов, размещенных на конкретном узле сети.
Примеры возможных подсистем:
· совокупность классов, обеспечивающих сложный комплекс функций (например, обеспечение безопасности и защиты данных);
· граничные классы, реализующие сложный пользовательский интерфейс или интерфейс с внешними системами;
· различные продукты: коммуникационное ПО, доступ к базам данных, общие утилиты (библиотеки), различные прикладные пакеты.
При создании подсистем в модели выполняются следующие преобразования:
· объединяемые классы помещаются в специальный пакет с
именем подсистемы и стереотипом <<subsystem>>;
· спецификации операций классов, образующих подсистему, выносятся в интерфейс подсистемы — класс со стереотипом <<Interface>>;
· описание интерфейса должно включать:
имя интерфейса, отражающее его роль в системе;
текстовое описание интерфейса размером в небольшой абзац, отражающее его обязанности;
описание операций интерфейса (имя, отражающее результат операции, алгоритм выполнения операции, возвращаемое значение, параметры с их типами);
характер использования операций интерфейса и порядок их выполнения документируется с помощью диаграмм взаимодействия, описывающих взаимодействие классов подсистемы при реализации операций интерфейса, которые вместе с диаграммой классов подсистемы объединяются в кооперацию с именем интерфейса и стереотипом << Interface realization>>;
· в подсистеме создается класс-посредник со стереотипом <<subsystem proxy>>, управляющий реализацией операций интерфейса.
Все интерфейсы подсистем должны быть полностью определены в процессе проектирования архитектуры, поскольку они будут служить в качестве точек синхронизации при параллельной разработке системы.
В качестве примера (для системы регистрации) приведем подсистему CourseCatalogSystem, которая создана вместо граничного класса CourseCatalogSystem. Диаграммы классов и взаимодействия, описывающие данную подсистему и ее интерфейс, приведены на рис. 4.20-4.22. Классы DBCourseOfferring и CourseOfferringList отвечают за взаимодействие с БД каталога курсов в рамках JDBC. Объект CourseCatalogSystem Client на рис. 4.22 может принадлежать либо классу CloseRegistrationController, либо классу RegistrationController, в зависимости от того, в каком из вариантов использования запрашивается каталог курсов.
