Разработка программных средств банковской системы

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

Рисунок 4.23 – Диаграмма вариантов использования

Определим, как пример описания, основной поток событий варианта использования Снять деньги со счета (очень упрощенно):

1) кассир банка идентифицирует клиента;

2) кассир банка выбирает счет, с которого будут сняты деньги, и определяет снимаемую сумму;

3) система снимает соответствующую сумму со счета и выдает деньги.

К варианту использования Снять деньги со счета может быть приложено следующее нефункциональное требование: время отклика для клиента банка, измеряемое от ввода снимаемой суммы до выдачи купюр, не должно превышать 30 секунд в 95% всех операций.

Модель анализа

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

Рассмотрим использование стереотипов классов для варианта использования Снять деньги со счета (рисунок 4.24):

- устройство выдачи и Интерфейс кассира – это граничные классы; эти классы в основном используются для моделирования взаимодействия между системой и ее действующими лицами (то есть пользователями и внешними системами);

- получение – управляющий класс; эти классы в основном используются для представления координации, последовательности, взаимодействия и управления другими объектами – и часто применяются для инкапсуляции управления, относящегося к определенному варианту использования;

- банковский счет – класс сущности; эти классы в основном используются для моделирования информации длительного хранения, часто постоянной.

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

Рисунок 4.24 – Стереотипы классов варианта использования Снять деньги со счета

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

- реализации трех вариантов использования Снять деньги со счета, Перечислить деньги на другой счет и Внести деньги на счет используют граничный класс Интерфейс кассира и класс сущности Банковский счет. Выполнение каждого варианта использования начинается с объекта Интерфейс кассира. Затем выполнение переходит к управляющему объекту, который координирует выполнение варианта использования. Класс этого объекта уникален для каждого варианта использования. Класс Получение участвует в варианте использования Снять деньги со счета. Объект этого класса предлагает объекту Устройству выдачи выдать деньги, а объекту Банковский счет– уменьшить баланс счета;

- в реализации варианта использования Перечислить деньги на другой счет участвуют два объекта Банковский счет. Они оба нуждаются в запросе на изменение баланса счета от управляющего объекта Перечисление;

- в реализации варианта использования Внести деньги на счет управляющий объект Вклад принимает деньги через объект Устройство приема и предлагает объекту Банковский счет увеличить баланс счета.

На основании этих рассуждений построим следующую модель анализа (рисунок 4.25).

Рисунок 4.25 – Модель анализа

Построив модель анализа с помощью стереотипов классов, мы знаем какие классы будут участвовать в реализации варианта использования. Мы также знаем, какие у них обязанности. Однако нам не известно, как объекты этих классов взаимодействуют между собой в реализации варианта использования. Сначала используем диаграммы кооперации для того, чтобы смоделировать взаимодействия между объектами анализа. Диаграмма показывает, как по мере выполнения варианта использования фокус перемещается от объекта к объекту и как между объектами пересылаются сообщения. Сообщение, посланное от одного объекта другому, переключает фокус на объект-приемник и побуждает его выполнить одну из обязанностей, порученных этому классу.

Название сообщения описывает предполагаемый смысл взаимодействия вызывающего объекта с вызываемым. Позже, в ходе проекта, эти сообщения будут преобразованы в одну или более операции, содержащиеся в соответствующих классах проектирования.

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

Рисунок 4.26 – Коммуникационная диаграмма

Последовательность событий реализации варианта использования Снять деньги со счета (рисунок 4.26) следующая (сравните с описанием варианта использования):

- Клиент банка, желая снять деньги со счета, активирует объект Интерфейс кассира. Клиент банка идентифицирует себя и указывает, сколько денег снять и с какого счета (1).

- Интерфейс кассира проверяет идентификацию Клиента банка и предлагает объекту Получение выполнить операцию (2).

- Если идентификация Клиента банка признана верной, объект Получение предлагает объекту Банковский счет подтвердить, что Клиент банка имеет право получить запрошенную сумму. Объект Получение делает это, предлагая объекту Банковский счет подтвердить правильность запроса и, если он верен, списать указанную сумму с баланса (3).

- После этого объект Получение разрешает Устройству выдачи выдать сумму, запрошенную Клиентом банка (4).

- Клиент банка при этом получает запрошенную сумму денег (5).

Модель проектирования

После того как классы анализа разработаны, с их помощью определяются уточненные классы проектирования, которые адаптированы к среде выполнения. Это иллюстрируется на рисунке 4.27 (для варианта использования Снять деньги со счета). Обратите внимание, что множество классов проектирования трассируются от единственного класса анализа. Так, например, класс анализа Интерфейс кассира преобразуется в четыре класса проектирования — Дисплей, Клавиатура, Считыватель карт и Менеджер клиентов (который является активным классом).

Кроме того, активные классы (Менеджер клиентов, Менеджер транзакций и Менеджер счетов) представляют собой специальные процессы, которые организуют работу других (неактивных) классов в случае распределенной системы.

Рисунок 4.27 – Модель проектирования

Как следствие, реализация варианта использования Снять деньги со счета в модели проектирования должна описывать, как вариант использования реализован в понятиях соответствующих классов проекта. Рисунок 4.28 изображает диаграмму классов, которая является частью реализации варианта использования.

Рисунок 4.28 – Диаграмма классов проектирования варианта использования Снять деньги со счета

Как и при анализе, мы должны идентифицировать взаимодействия между объектами проектирования, которые появились после того, как в модели проектирования были реализованы варианты использования. Прежде всего, воспользуемся диаграммой последовательности, чтобы промоделировать взаимодействия между объектами проектирования, как показано на рисунке 4.29.

Диаграмма последовательности показывает, как фокус – исходно находящийся в верхнем левом углу – перемещается от объекта к объекту по мере выполнения варианта использования и как объекты обмениваются сообщениями. Сообщение, посланное одним объектом, побуждает объект-приемник этого сообщения получить фокус и выполнить одну из операций его класса.

Весь набор сообщений диаграммы последовательности (рисунок 4.29) показывает во что превратились первые два сообщения из диаграммы кооперации («1. идентифицировать» и «2. запросить снятие») на рисунке 4.26. Это дает понятие о сложности и уровне детализации модели проектирования по сравнению с моделью анализа.

Рисунок 4.29 – Диаграмма последовательности варианта использования Снять деньги со счета

Как можно заметить по этому примеру, модель проектирования, вероятно, будет содержать множество классов. Значит, нам потребуется способ организации классов. Это можно сделать при помощи подсистем.

Подсистема – это осмысленная группировка классов или других подсистем. В данном примере классы группируются в три подсистемы (рисунок 4.30).

Рисунок 8 – Диаграмма пакетов для идентификации подсистем

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

Преимущество размещения всех классов интерфейса пользователя в подсистеме Интерфейс ATM (банкомат) в том, что эту подсистему можно при необходимости заменить на любую другую подсистему, которая предоставляет подсистеме Управление транзакциями ту же самую функциональность. Альтернативная Интерфейсу ATM подсистема может иметь совершенно другую реализацию пользовательского интерфейса, например предназначенную для приема и выдачи монет, а не купюр.

Классы, связанные с вариантами использования, такие как класс Получение в подсистеме Управления транзакциями, заключены в свои собственные сервисные подсистемы. Каждая такая сервисная подсистема может в действительности содержать больше одного класса, но у нас упрощенный пример, и на нем этого не показать.

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

Модель развертывания

Предположим, что мы выбрали для нашего примера решение на основе архитектуры клиент/сервер.

Упрощенная модель развертывания приведена на рисунке 4.31. Каждый активный класс спроектированных подсистем размещается на соответствующем узле, превращаясь в работающий на этом узле процесс. Активные объекты показаны в виде прямоугольников с утолщенной рамкой.

Рисунок 4.31 – Диаграмма развертывания

Модель реализации

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

В ходе рабочего процесса реализации мы разрабатываем все необходимое для создания исполняемой системы: исполняемые компоненты, файлы компонентов (исходный код, сценарии для командного процессора и т. п.), табличные компоненты (элементы баз данных) и другие.

Компонентом мы называем физическую заменяемую часть системы, которая использует и обеспечивает реализацию некоторого набора интерфейсов.

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

Рисунок 4.32 – Диаграмма компонентов варианта использования Снять деньги со счета

Файл компонента dispenser.c содержит исходный текст и реализует три класса: Подаватель устройства выдачи, Датчик устройства выдачии Счетчик купюр. Этот файл компилируется и компонуется с файлом компонента client.c в компонент client.exe, который является исполняемым файлом.

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