Архитектурное представление модели
Архитектурное представление модели проектирования содержит большинство
важных для архитектуры классификаторов модели проектирования: наиболее важ-
ные подсистемы, интерфейсы, несколько особенно важных классов, прежде всего
активные классы. Оно также показывает, как наиболее важные варианты использования
реализованы в понятиях этих классификаторов, то есть реализации вариантов
использования. Активные классы (занятия) также обсуждаются в следующем
подразделе данной главы при изучении модели развертывания (в которой активные
классы распределяются по узлам).
Пример. Архитектурное представление модели проектирования банкомата
(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. Интерфейс А ТМ выдает деньги Клиенту банка.