Определение первой ситуации использования

Начнем с клиента. В общих чертах опишем, как клиент будет взаимодействовать с нашей системой.

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

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

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

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

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

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

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

Чтобы определить; представляют ли эти действия одну ситуацию использования или две, надо выяснить, различны ли механизмы обработки (делает ли клиент нечто существенно различное с этими вкладами) и различны ли выходы (реагирует ли система по-разному). На оба вопроса в нашем случае ответ будет отрицательным: механизм внесения клиентом денег на разные счета в целом одинаков и система в обоих случаях прореагирует однотипно — увеличит сумму на соответствующем счете.

При условии, что пользователь и система ведут себя более-менее идентично в двух разных ситуациях, эти ситуации можно объединить в одну. Позднее можно конкретизировать сценарии использования системы и разделить эти ситуации, если возникнет необходимость.

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

• Почему пользователь использует систему?

Чтобы получить наличные, сделать вклад или проверить остаток на счете.

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

• Что заставило пользователя прибегнуть к этой системе сейчас? Возможно, ему недавно выплатили зарплату или надо сделать покупку.

• Что следует выполнить пользователю, чтобы воспользоваться системой? Вставить карточку в гнездо кассового аппарата ATM.

Ага! Нужно учесть ситуацию, когда клиент регистрируется в системе.

• Какую информацию клиент должен предоставить системе? Ввести личный идентификационный номер.

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

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

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

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

Ассоциация

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

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

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

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

Разработка сценариев

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

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

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

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

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

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

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

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

Разработка путеводителей

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

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

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

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

• Требуемые результаты выполнения программы.

• Информация, возвращаемая пользователю.

• Запускаемые циклы и условия выхода из них.

• Логическое описание сценария.

• Условие завершения сценария.

• Итоги выполнения сценария.

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

Ситуация использования: Клиент снимает наличные со счета

Сценарий: Успешное снятие наличных с расчетного счета

Предварительные условия: Клиент уже имеет доступ в систему

Переключатель: Запрос от клиента на снятие денег со счета

Описание: От клиента поступил запрос на снятие денег с расчетного счета. На счете имеется достаточная сумма. В кассовом аппарате достаточно денег и заправлена бумага для квитанций; сеть включена и работает. ATM просит клиента указать сумму денег для снятия. Клиент указывает сумму, не превышающую $300. Машина выдает деньги и печатает квитанцию

Итоги: Со счета клиента снята указанная сумма; сальдо счета уменьшено на эту сумму

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

Диаграмма не может похвастаться обилием отображаемой информации. Отношения между пользователем и системой показаны довольно абстрактно. Эта диаграмма станет гораздо полезнее, когда будут показаны взаимоотношения между разными ситуациями использования. Таких отношений может быть только два: использование и расширение. Отношение использования означает, что одна ситуация использует другую. Например, невозможно снять деньги со счета без регистрации в системе. Это отношение показано на рис. 18.10.

Рис. 18.9. Диаграмма ситуации использования

Рис. 18.10. Отношение подчинения между

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

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

Диаграммы взаимодействий

Хотя диаграмма ситуации использования вряд ли представляет собой большую ценность, такого рода диаграммы можно комбинировать, что значительно улучшает документацию и понимание взаимоотношений объектов системы. Например, известно, что сценарий ситуации Снятие со счета представляет взаимодействие между такими объектами домена, как клиент, расчетный счет и интерфейс пользователя системы. Это можно документировать диаграммой взаимодействий, показанной на рис. 18.11.

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

Рис.18.11. Диаграмма взаимодействий системы кассового аппарата АTM с клиентом при выполнении операции снятия со счета

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

Ошибка! Недопустимый объект гиперссылки.

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

Пакет напоминает папку в файловой системе компьютера. Он является набором объектов моделирования (классов, деятелей и т.п.). Чтобы упорядочить ситуации использования, их можно распределить по пакетам в соответствии с конкретными логическими концепциями. Так, можно объединить вместе ситуации использования определенных банковских счетов (расчетных или депозитных) либо разделить их по типам клиентов или любым другим важным характеристикам. Одна и та же ситуация использования может быть представлена в разных пакетах, в результате чего между пакетами образуются логические взаимосвязи.