Создание модели реализации

Классы группируются в подсистемы

Для большой системы, состоящей из сотен или тысяч классов, невозможно реализовать

варианты использования, пользуясь только классами. Такая система будет

слишком велика для того, чтобы в ней можно было обойтись без группировки высшего

порядка. Классы группируются в подсистемы. Подсистема — это осмысленная

группировка классов или других подсистем. Подсистема имеет набор интерфейсов,

которые обеспечивают ее существование и использование. Эти интерфейсы

определяют контекст подсистемы (актантов и другие подсистемы и классы).

Подсистемы нижнего уровня называются также сервисными подсистемами

(приложение Б, см. также главу 9), потому что их классы предоставляют сервисы

(более полное описание сервисов см. в подразделе «Артефакт: Описание архитектуры

» главы 8). Сервисная подсистема представляет собой минимальную самостоятельную

единицу дополнительных (или потенциально дополнительных) функциональных

возможностей. Невозможно установить клиенту только часть подсистемы.

Сервисные подсистемы также используются для моделирования совместно

изменяемых групп классов.

Подсистемы могут разрабатываться как сверху вниз, так и снизу вверх. При

разработке снизу вверх разработчики вводят подсистемы, отталкиваясь от уже существующих

классов; вводимые подсистемы при этом собирают классы в наборы

ясно определенных функций. Если же разработчики создают подсистемы сверху

вниз, то первым делом, до начала выделения классов, архитектор идентифицирует

подсистемы верхнего уровня и их интерфейсы. После этого разработчики исследуют

отдельные подсистемы, разыскивая в них и проектируя классы этих подсистем.

Понятие подсистем было введено в главе 1, подробнее они будут обсуждаться

в главах 4 и 9.

Пример. Подсистемы объединяют классы. Разработчики собирают классы

в три подсистемы, показанные на рис. 3.11. Эти подсистемы определены следующим

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

интерфейс, вся работа с банковскими счетами была сосредоточена во второй

подсистеме и классы, определяющие варианты использования, — в третьей.

Преимущество размещения всех классов интерфейса пользователя в подсистеме

Интерфейс ATM ъ том, что эту подсистему можно при необходимости заменить на

любую другую подсистему, которая предоставляет подсистеме Управление транзакциями

ту же самую функциональность. Альтернативная Интерфейсу ATM пол-

система может иметь совершенно другую реализацию пользовательского интерфейса,

например предназначенную для приема и выдачи монет, а не купюр.

Классы, связанные с вариантами использования, такие как класс Получение

в подсистеме Управления транзакциями, заключены в свои собственные сервисные

подсистемы. Каждая такая сервисная подсистема может в действительности

содержать больше одного класса, но у нас упрощенный пример, и на нем этого не

показать.

На рис. 3.11 также изображены интерфейсы между подсистемами. Круг представляет

интерфейс. Сплошная линия между классом и интерфейсом означает, что

класс предоставляет интерфейс. Стрелка с пунктирной линией от класса к интерфейсу

означает, что класс пользуется интерфейсом. Для простоты мы не показы-

используем обычные ассоциации.

Рис. 3.11. Три подсистемы с сервисной подсистемой ^изображена серым

в подсистеме Менеджера транзакции)

Интерфейс Перечисление определяет действия при перечислении денег со счета

на счет, снятия денег со счета и внесения их на счет. Интерфейс Получение определяет

действия при запросе на снятие денег со счета. Интерфейс Выдача определяет

действия, которые следует совершить другим подсистемам, например Управлению

транзакциями, для выдачи денег клиенту банка.