Ага/ Нужно предоставить возможность клиенту получить или изменить личный идентификационный номер.

Какую информацию пользователь хочет получить от системы? Остатки на счетах и т. д.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

a eolji ::}Aii*of

The cuitofner is any patron trf the bank who has one a rweacca. 4tt Thecustonw ysts ATM lodeposJ money, Irenitw between accounti, checi hu balance and lo get cash

Pmc. /<?.4. Система Rational Rose

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

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

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

Обобщение

Банковский счет

Доменный объект

Расчетный счет

Депозитный счет

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

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

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

ООоОщение

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

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

Вложение

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

Расчетный счет

Депозитный счет

Агрегация

Банковский счет

Сальдо

Записи трансакций

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

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