Проектирования

Архитектурное представление модели

Архитектурное представление модели проектирования содержит большинство

важных для архитектуры классификаторов модели проектирования: наиболее важ-

ные подсистемы, интерфейсы, несколько особенно важных классов, прежде всего

активные классы. Оно также показывает, как наиболее важные варианты использования

реализованы в понятиях этих классификаторов, то есть реализации вариантов

использования. Активные классы (занятия) также обсуждаются в следующем

подразделе данной главы при изучении модели развертывания (в которой активные

классы распределяются по узлам).

Пример. Архитектурное представление модели проектирования банкомата

(ATM). В подразделе «Создание модели проектирования из аналитической модели

» главы 3 мы идентифицировали три активных класса: Менеджер клиентов,

Менеджер транзакций и Менеджер счетов (рис. 4.7). Эти активные классы включаются

в архитектурное представление модели проектирования.

Рис. 4.7. Статическая структура архитектурного представления

модели проектирования для системы ATM.

Диаграмма классов, содержащая активные классы

Кроме того, из подраздела «Классы группируются в подсистемы» главы 3 нам

уже известно о трех подсистемах: Интерфейс ATM, Управление Транзакциями и Управление

Счетами; рис. 4.8. Эти подсистемы необходимы для понимания варианта

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

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

здесь они рассматриваться не будут.

Подсистема Интерфейс ATM берет на себя всю работу с клиентом банка, включая

прием от него информации и команд, предоставление информации и запросов

клиенту и печать квитанций. Подсистема Управление Счетами занимается обслуживанием

всей информации длительного хранения о банковских счетах и операциях

со счетами. Подсистема Управление Транзакциями содержит классы для поведения,

определяемого вариантами использования, например поведения, определяемого

вариантом использования Снять деньги со счета. В примере из подраздела

«Классы группируются в подсистемы» главы 3 мы упоминали, что классы, определяемые

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

такие как сервисные подсистемы для классов Снять деньги со счета, Перечислить

деньги на другой счет и Внести деньги на счет подсистемы Управление Транзакциями

(на рис. 4.8 не показаны). В реальности каждая сервисная подсистема

обычно содержит несколько классов, но наш пример очень прост.

Подсистемы на рис. 4.8 обеспечивают поведение друг друга через интерфейсы,

такие как интерфейс Перечисления, предоставляемый Управлением Счетами. Интерфейсы

Перечисления, Получение и Выдача описаны в подразделе «Классы группируются

в подсистемы» главы 3. Существуют также интерфейсы Перечисленные,

Вклады и История, но они не вовлечены в вариант использования, который мы

обсуждаем в этом примере, поэтому мы не будем о них говорить.

Однако статической структуры недостаточно. Мы также должны показать, как

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

модели проектирования. Поэтому мы еще раз опишем вариант использования__

Снять деньги со счетам на этот раз в понятиях взаимодействующих подсистем и актантов,

как показано на рис. 4.9, с использованием диаграммы коопераций (приложение

А). Объекты классов, принадлежащих подсистемам, взаимодействуют друг

с другом с целью исполнения экземпляра варианта использования. Объекты посылают

друг другу сообщения, эта коммуникация изображена на диаграмме. Сообщения

несут имена, определяющие операции, принадлежащие интерфейсам

подсистем. Эта структура сообщений обозначается знаком:: (например, Получе-

««^.-.•совершить (количество, счет), где Получение — интерфейс, предоставляемый

классом подсистемы Управление Транзакциями).

Рис. 4.9. Подсистемы, кооперирующиеся для осуществления

варианта использования Снять деньги со счета

Следующий список кратко описывает процессы в реализации варианта использования.

Текст почти такой же, как в подразделе «Создание по вариантам использования

аналитической модели» главы 3 (описание реализации варианта использования),

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

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

через ATM.

1. Актант Клиент банка желает снять деньги со счета и идентифицирует себя через

Интерфейс ATM, возможно, используя магнитную карту с номером и PIN-

кодом. Клиент банка также определяет, сколько он хочет снять и с какого счета.

Мы предполагаем, что подсистема Интерфейс ATM в состоянии проверить

идентификацию.

2. Интерфейс ATM запрашивает у подсистемы Управление __бhOЏв1Мтранзакциями получение

денег. Подсистема Управление транзакциями отвечает за выполнение всей

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

одновременно были списаны со счета и выданы Клиенту банка.

3. Управление транзакциями запрашивает у Управления счетами выдачу денег.

Подсистема Управление счетами определяет, возможна ли выдача денег, и, если

это так, уменьшает счет на указанную сумму и возвращает сообщение, что

выдачу можно совершить.

4. Управление транзакциями разрешает подсистеме Интерфейс ATM выдать

деньги.

5. Интерфейс А ТМ выдает деньги Клиенту банка.