Выявление подсистем и интерфейсов

Декомпозиция системы на подсистемы реализует принцип модульности (см. подразд. 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, в зависимости от того, в каком из вариантов использования запрашивается каталог курсов.