Джесс Либерти - Освой самостоятельно С++ за 21 день.

Рис. 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 показывает, что объекты Расчетный счет и Депозитный счет обобщены в Банковский счет, а в объект Банковский счет вложены объекта Сальдо и Записи трансакций.

Третье отношение — ассоциация обычно фиксируется во время анализа домена

Ассоциация предполагает, что два объекта "знают" друг друга и некоторым образом взаимодействуют. Определение станет намного точнее на этапе проектирования, но для анализа лишь предполагается, что Объект А и Объект Б взаимодействуют, но ми один из них не содержит и не является частным видом другого. В UML эта ассоциация показана с помощью простой прямой линии между объектами (рис, 18.8).

Рис. 18.8. Отношение ассоциации

Диаграмма на рис. 18.8 означает, что Объект А некоторым образом взаимодейетву' ет с Объектом Б.

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

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

• Клиент делает запрос на снятие $300 с расчетного счета, кладет наличные в кошелек и ожидает квитанции.

• Клиент делает запрос на снятие $300 с расчетного счета, но остаток на счете составляет всего $200. Ему поступает информация, что для выполнения операции недостаточно денег на расчетном счете.

• Клиент делает запрос на снятие $300 с расчетного счета, но сегодня с этого счета уже сняли $100, а дневной лимит составляет $300. Поступает информация, что ему разрешается снять только $200.

• Клиент делает запрос на снятие $300 с расчетного счета, но в рулоне для печатания квитанций закончилась бумага. Ему поступает информация о возникшей технической неисправности и предложение подождать, пока персонал банка устранит эту проблему.

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

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

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

• Предварительные условия, определяющие начало сценария.

• Переключатели, включающие выполнение именно этого сценария.

• Действия, выполняемые пользователем.