Освой самостоятельно С++ за 21 день.

Либерти Джесс

Часто можно обнаружить дополнительные ситуации использования, обратив внимание на структуру учета пользователей в доменах. У клиента есть имя, личный идентификационный номер и номер счета. Предусмотрена ли в системе возможность обработки и изменения этих данных? Счет имеет номер, остаток и записи трансакций. Как в системе будут возвращаться и обновляться эти данные?

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

системы:

• Клиент проверяет остатки на своих счетах.

• Клиент кладет деньги на свой счет.

• Клиент снимает деньги со своего счета.

• Клиент переводит деньги со счета на счет.

• Клиент открывает счет.

• Клиент закрывает счет.

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

• Клиент проверяет недавние трансакции.

• Банковский служащий получает доступ к специальному управляющему счету.

• Банковский служащий регулирует выплаты по счетам клиентов.

• Банковская компьютерная система обновляет счет клиента на основе внешних поступлений.

• Изменения на счете клиента отображаются и возвращаются в банковскую компьютерную систему.

• ATM сигнализирует об отсутствии наличных денег для выдачи.

• Банковский клерк заправляет ATM наличными и включает его.

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

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

Для каждого из этих объектов домена требуется зафиксировать такие данные: имя (например, клиента, счета и т.д.), основные атрибуты объекта, является ли объект пользователем и прочее. Многие средства моделирования поддерживают фиксирование такого рода информации в описаниях классов. На рис. 18.4 показано, как эта информация фиксируется с помощью системы Rational Rose.

Важно понять, что мы имеем дело не с программными объектами, а с реальными фигурантами, которых следует учитывать при разработке проекта. Никто не заставляет нас для каждого объекта домена создавать объекты в программе.

Рис. 18.4. Система Rational Rose

Используя соглашения UML, можно создать диаграмму для нашего кассового аппарата, в которой будут отражены отношения между объектами домена точно так же, как изображаются отношения между классами в программе. В этом одна из сильных сторон UML: на всех этапах проектирования можно использовать одни и те же средства.

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

На диаграмме, показанной на этом рисунке, прямоугольники представляют

различные объекты домена, а стрелки, направленные вверх, означают обобщение частных объектов в общий. Таким образом, в терминах языка C++ можно сказать, что объекты домена Расчетный счет и Депозитный счет являются производными от объекта Банковский счет.

Рис. 18.5. Отношения между объектами домена, выраженные средствами UML

UML — богатый язык моделирования, с помощью которого можно фиксировать самые разные отношения. Однако для нас наиболее важными будут отношения обобщения, вложения и ассоциации.

Примечание:Вновь обратите внимание, что в данном случае рассматриваются отношения между объектами домена. Позднее, при разработке проекта, возможно, вы захотите реализовать эти отношения между объектами классов CheckingAcnount (Расчетный счет) и BankAccount (Банковский счет), используя наследование классов, но это будет лишь один из возможных вариантов разработки проекта. Пока что мы просто пытаемся разобраться, как взаимодействуют друг с другом реальные объекты домена. 

Обобщение 

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

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

Вложение

Часто один объект состоит из многих подобъектов. Например, автомобиль состоит из руля, шин, дверей, коробки передач и т.п. Расчетный счет состоит из сальдо, записи трансакций, кода клиента и т.д. Мы говорим, что расчетный счет содержит эти объекты в себе, другими словами, эти объекты вложены в расчетный счет. Вложенность, или содержание в себе средствами UML обозначается стрелкой с ромбом на конце, которая направлена от внешнего объекта к внутреннему (рис. 18.6).

Рис. 18.6. Отношение вложения

Рис. 18.7. Сложные отношения между объектами

Диаграмма на рис. 18.6 показывает, что объект Расчетный счет содержит в себе другой доменный объект — Сальдо, Чтобы показать достаточно сложный набор отношений, две предыдущие диаграммы можно скомбинировать (рис, 18.7).

Диаграмма на рис. 18.7 показывает, что объекты Расчетный счет и Депозитный счет обобщены в Банковский счет, а в объект Банковский счет вложены объекта Сальдо и Записи трансакций.