Анализ требований клиента. Зачем нужны анализ и проектирование. Анализ проблемы, страница 4

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

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

Неясно, надо ли рассматривать добавление и удаление продавца как два разных прецедента или как один общий прецедент — "Изменение списка продавцов". Можно даже привести доказательства того, что это на самом деле части прецедента выплаты по счету. Вряд ли клиент будет входить в систему HomeDirect лишь затем, чтобы добавить продавца. В этом случае требуется дальнейшее исследование. В некоторых реальных электронных банковских системах требуется, чтобы клиент добавил продавца в список по крайней мере за несколько рабочих дней до совершения первой выплаты. Если такое требование существует, имеет смысл ожидать, что клиент может войти в систему, добавить одного или н е-скольких продавцов и затем выйти, не обязательно производя выплату по счету. Для простоты, мы будем считать, что такое требование поступило от ACMEBank и будем использовать при моделировании один прецедент — "Изменение списка продавцов".

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

·  Изменение пароля.

·  Просмотр счета.

·  Список транзакций.

·  Загрузка транзакций.

·  Перевод денег.

·  Редактирование профиля.

·  Выплата по счету.

·  Покупка ценных бумаг.

·  Продажа ценных бумаг.

Окончательный набор прецедентов для системы HomeDirect приводится в главе 16.

Диаграммы прецедентов

В языке UML исполнители изображаются схематическим рисунком человечка, а прецеденты изображаются овалами. Диаграмма прецедента просто отображает структурные отношения между исполнителями и прецедентами, а не динамические отношения. Отношения между исполнителями и прецедентами изображаются посредством направленных ассоциаций, указывающих на предмет вызова. На рис. 7.1 показаны прецеденты "Просмотр счета" и "Перевод денег" для системы HomeDirect. Оба прецедента вызываются клиентом.

Отношения между прецедентами

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

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

Включение

Отношение включения позволяет выразить некоторую часть функциональных возможностей в отдельном прецеденте и затем "включать" их в другие прецеденты. Отношение включения изображается как отношение зависимости со стереотипом <<include>>. Пример такого отношения показан на рис. 7.2.

Расширение