Лабораторная работа №3 Моделирование прецедентов

Лабораторная работа №3

Моделирование прецедентов

(методика ICONIX)

Моделирование прецедентов в теории. 1

Основные элементы моделирования прецедентов. 2

Зачем необходимы прецеденты в дополнение к функциональным требованиям?. 4

Не забудьте написать сценарии обработки исключительных ситуаций (Rainy-Day Scenarios). 4

Создайте предварительный вариант модели предметной области прежде чем писать сценарий прецедента 4

Правила составления прецедентов. 4

10 самых распространенных ошибок при моделировании прецедентов. 8

Работа с прецедентами. 10

Организация прецедентов в пакеты.. 10

Написание текстов прецедентов. 15

Основные отличия прецедента от алгоритма. 17

Варианты использования и аспектно-ориентированное проектирование. 17

Моделирование прецедентов на практике. 19

Упражнения. 19

Задания. 21

Приложения. 23

Готовая черновая модель предметной области. 23

Готовая диаграмма прецедентов. 24

Документация по прецедентам.. 25

Моделирование прецедентов в теории

Основной вопрос, который необходимо задать в начале разработки любой информационной системы: «Что хотят сделать ее пользователи?». Попытаемся как можно подробнее представить действия пользовате­лей и реакцию системы, поскольку ее поведение обусловлено их требова­ниями. Другими словами, работа системы зависит от того, как к ней обра­щаются и чего хотят добиться. Часто эти вопросы связаны с графическим интерфейсом пользователя.

На рисунке 1 показано место моделирования прецедентов в общей картине процесса ICONIX - для определения прецедентов нужно использовать про­тотипы. Кроме того, мы работаем над моделью прецедентов параллельно с моделированием предметной области на самых ранних этапах проекта. Вся динамическая часть объектной модели непосредственно вытекает из моде­ли прецедентов. Поскольку динамическая модель определяет статическую, модель прецедентов оказывает решающее воздействие на последнюю.

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

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

Рисунок 1 – Место моделирования прецедентов в общей картине процесса ICONIX

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

Основные элементы моделирования прецедентов

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

При выявлении прецедентов необходимо всегда помнить главный прин­цип: их следует тесно связывать с будущим руководством пользователя. Связь между каждым прецедентом и разделом руководства должна быть очевидной. Это подкрепляет основную идею, состоящую в том, что проект системы базируется на восприятии ее пользователями. Можно сказать, что «основа на прецедентах» означает: «Сначала напишите руководство поль­зователя, а потом код». Если вы перерабатываете унаследованную систе­му, то можете просто отталкиваться от руководства пользователя и вносить необходимые изменения.

Написав какой-то текст прецедента, отшлифуйте его, сформулировав предложения в ясной и краткой форме. Постарайтесь, чтобы каждое пред­ложение имело структуру существительное-глагол-существительное, а актеры и потенциальные доменные объекты были сразу видны. Как толь­ко обнаруживаются новые объекты или уточняется поведение ранее най­денных, сразу обновите модель предметной области (предыдущая лабораторная работа). И еще очень важно иметь в виду все возможные альтернативные последователь­ности действий для каждого прецедента, хотя на их учет уходит большая часть времени. Отметим, что анализ пригодности, который мы обсудим в лабораторной работе 5, способству­ет выполнению последовательных уточнений.

Некоторые авторы призывают использовать развернутые шаблоны пре­цедентов. Но наши рекомендации всем ученикам таковы:

1. Создайте шаблон прецедента, в котором есть разделы «Главная по­следовательность» и «Альтернативные последовательности». Другие разделы не нужны, они будут только отвлекать внимание.

2. Задайте себе вопрос: «Что происходит?». С ответа на него начинает­ся главная последовательность.

3. Спросите себя: «А что дальше?». Продолжайте в том же духе, пока все детали главной последовательности не будут записаны на бумаге.

А. Спросите себя: «А что еще может происходить?». Будьте упорны. Хоть что-нибудь еще может происходить? Вы уверены? Задавайте себе эти вопросы, пока не появится достаточно обширный набор аль­тернатив. Поверьте, проблемы на этом этапе - ничто по сравнению с бедами, возникающими, скажем, во время тестирования сопряжений.

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

Вы еще будете анализировать этот материал при рецензировании тре­бований (лабораторная работа 4), и еще раз во время рецензирования предварительного проекта (лабораторная работа 6), и снова при рецензировании окончательного проекта (лабораторная работа 8). Если вам кажется, что это чересчур, вспомните: чем четче опре­делено поведение системы, тем легче ее построить.

В вашем распоряжении есть несколько механизмов для вычленения фрагментов (к примеру, обработки ошибок), общих для некоторого набо­ра прецедентов. Обычно это разумно, так как разбиение на атомарные блоки упрощает анализ и экономит время при рисовании диаграмм. Бу­дете ли вы применять механизм обобщения прецедентов и отношения включения (include) и расширения (extend), имеющийся в UML, или от­ношения вызова (invoke) и предшествования (precede) из языка Open Modeling Language (OML), цель состоит в том, чтобы получить на­бор небольших, четко очерченных и допускающих повторное использо­вание прецедентов.

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

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

·  созданные прецеденты описывают всю требуемую функциональ­ность системы;

·  для каждого прецедента четко и кратко описана главная последова­тельность действий, а также все альтернативные последовательности;

·  выделены (с помощью того или иного удобного для вас механизма) сценарии, общие для нескольких прецедентов.

·   

Зачем необходимы прецеденты в дополнение к функциональным требованиям?

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

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

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

Не забудьте написать сценарии обработки исключительных ситуаций (Rainy-Day Scenarios).

В прецедентах нужно отражать действия пользователя и реакцию на них системы. Эти действия можно разделить на относящиеся к основному сценарию взаимодействия с системой (Sunny-Day Scenarios) и к альтернативному сценарию (Rainy-Day Scenarios) взаимодействия с системой. Альтернативный сценарий включает в себя действия, которые пользователь вынужден совершать, когда что-то пошло не так (возникли ошибки).

Создайте предварительный вариант модели предметной области прежде чем писать сценарий прецедента

Прецеденты должны быть написаны в контексте модели предметной области, то есть в них должны использоваться существительные и словосочетания, которые входят в словарь предметной области. Методология ICONIX предполагает, что модель предметной области, которые мы начали составлять на первом этапе, заведомо неполная, и предусматривает постепенное уточнение модели по мере выполнения анализа прецедентов. Поэтому мы не тратим много времени на создание модели предметной области на предыдущем этапе (лабораторная работа 2).

Прецеденты дадут дополнительную информацию, которую мы не учли на этапе моделирования предметной области.

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

Правила составления прецедентов

DUC1. Текст прецедента не должен превышать два абзаца.

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

В тексте прецедента должны быть даны ответы на вопросы: что происходит, если всё идет по плану и что может произойти, если что-то идет не по плану.

Прецеденты должны быть привязаны к участникам взаимодействия и размещены на диаграммах прецедентов (use case diagram).

Рисунок 2 – Привязка прецедентов на диаграмме прецедентов

Участник взаимодействия (актер) соответствует роли, которую может играть пользователь. Среди участников могут быть как люди, так и внешние системы – все, кто может взаимодействовать с системой извне.

Линия ассоциации между актером и прецедентом означает ответственность.

Например, если будет линия между Администратором и Модерирование форума, то это означает, что Администратор ответственен за модерирование сообщений форума. Связи могут быть и типа один-ко-многим. Актер может быть ассоциирован с несколькими прецедентами и один прецедент может быть инициирован несколькими актерами.

DUC2. Нужно писать текст от первого лица.

Необходимо писать текст сценария от первого лица. Рассмотрим данное правило на примере.

Такой вариант написания сценария является не правильным:

Пользователям должна быть обеспечена возможность авторизоваться на сайте с помощью логина и пароля.

В приведенном выше варианте не видны участники (действующие лица).

Лучше написать так:

Пользователь вводит логин и пароль и затем нажимает кнопку Войти. Система ищет данные пользователя по логину и проверяет совпадение пароля. Затем система пускает пользователя.

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

DUC3. Текст должен быть построен по принципу: событие/отклик системы на него, таким образом, будут затронуты обе взаимодействующие стороны: пользователь и система.

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

Еще лучше в начале добавить следующую фразу (выделено):

Система показывает экран авторизации пользователя. Пользователь вводит логин и пароль и затем нажимает кнопку Войти. Система ищет данные пользователя по логину и проверяет совпадение пароля. Затем система пускает пользователя.

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

Рисунок 3 – Взаимодействие системы и пользователя

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

DUC5. Необходимо использовать прототипы пользовательских интерфейсов.

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

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

Пример прототипа приведен на рисунке 4.

Рисунок 4 – Прототип

Ниже приведен Вариант использования, который можно создать по этому прототипу:

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

Такой вариант использования позволяет избежать какой-либо конкретики. Кнопки реально могут стать гиперссылками или Flash-кнопками. Главное здесь – генерирующиеся пользователем события и ответы системы на них.

DUC6. Прецеденты специфицируют поведение системы во время работы с ней пользователя.

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

Фактически, мы сначала пишем подробное руководство пользователя, а затем по нему создаем архитектуру.

DUC7. Прецеденты должны быть написаны с учетом принципом ООП.

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

DUC8. Предложения в тексте варианта использования нужно строить по принципу: Существительное-Глагол-Существительное.

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

DUC9. Классы предметной области должны быть явно упомянуты в тексте вариантов использования.

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

Можно было написать вариант использования так:

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

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

Поэтому лучше переписать так:

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

В этом тексте неоднозначностей уже меньше.

DUC10. Экранам интерфейса (пограничным классам) нужно дать названия.

Поскольку наша цель состоит в написании однозначных поведенческих требований, а они, как правило, связаны с пользовательским интерфейсом, нужно избегать общих фраз типа «система отображает веб-страницу». Лучше писать конкретно: «система отображает Страницу покупки», т. е. давать пограничным классам или экранам интерфейса названия. Часто приходится дописать информацию о том, как подготовить страницу перед показом пользователю: «система отображается Страницу покупки, на которой выводится текущее состояние счета и адреса, по которым была произведена доставка товаров ранее.

Поэтому приведенный выше пример лучше переписать так:

Пользователь выбирает Книгу и добавляет ее в Список желаний. Система отображает страницу со Списком предпочтений пользователя (на которой также отображается текущее состояние Корзины).

10 самых распространенных ошибок при моделировании прецедентов

Перечислим типичные ошибки, допускаемые студентами при моделировании прецедентов:

EUC1. Пишут функциональные требования вместо словесного сценария использования.

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

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

Тексты прецедентов не должны излишне подробно описывать детали представления. По возможности следует также воздерживаться от ссылок на поля в экранных формах. Имена полей часто соответствуют именам атрибутов классов предметной области, о которых говорилось в предыдущей лабораторной работе. Если вы ловите себя на перечис­лении, скажем, 13 полей в тексте прецедента, остановитесь. От­кройте модель предметной области, найдите классы, которым при­надлежат соответствующие атрибуты, и поместите имена полей в раздел атрибутов. Позже, когда эти атрибуты понадобятся, вы лег­ко сможете их найти. Что касается методов, их не следует ни име­новать, ни описывать в тексте прецедента, поскольку они говорят о том, как система делает нечто, а не о том, что она должна делать.

EUC3. Слишком лаконично записывают прецеденты.

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

EUC4. Полностью абстрагируются от интерфейса пользователя.

Один из фундаментальных принципов «основан на прецедентах» состоит в том, что при проектировании системы разработчики отталкиваются от ее восприятия пользователями. Но при этом ни­как нельзя игнорировать те действия, которые пользователи выпол­няют с помощью экрана и клавиатуры. При описании ошибки 9 уже отмечалось, что не нужно упоминать в тексте прецедента о полях на экране и не стоит вдаваться в описание косметических деталей ин­терфейса. Все это при необходимости можно отразить в прототипах. Но вы обязаны обсудить те особенности интерфейса, которые по­зволяют пользователю указать системе, что она должна делать.

EUC5.  Не присваивают явные имена граничным объектам.

Граничными называются объекты, с которыми взаимодействуют актеры. К их числу относятся экранные формы, диалоговые окна и меню. Стремясь включать побольше деталей и явно описывать способы навигации, мы считаем, что граничные объекты следует явно именовать в текстах прецедентов. Другая причина, по кото­рой это важно сделать, состоит в том, что поведение таких объек­тов будет подвергнуто исследованию на этапе анализа пригоднос­ти (лабораторная работа 5) и присвоение им имен на ранних стадиях позволит избежать неоднозначности в дальнейшем.

EUC6.  Описывают прецеденты не с точки зрения пользователя.

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

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

Текст прецедента должен отражать как событие, так и отклик на него, например: «Система делает то-то, когда пользователь делает то-то». Прецедент должен описывать многое из того, что происходит «под капотом» в ответ на действия пользователя: создание новых объектов, контроль вводимых данных или вывод сообщений об ошибках. Не забывайте, что в тексте прецедента рассматриваются обе стороны диалога пользователя с системой, а поведение программы - то, что вы и пытаетесь выявить, - находится на системной стороне этого диалога. Игнорируя реакцию системы, вы игнорируете поведение программы.

EUC8.  Опускают описание альтернативных последовательностей действий.

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

EUC9. Концентрируют внимание на чем-то не относящемся к самому прецеденту, например на том, когда он начинается или что происходит позже.

Некоторые известные авторы выступают в поддержку длинных и сложных шаблонов прецедентов. Обычно в них есть разделы для пред - и постусловий. Мы полагаем, что вполне достаточно двух разделов: «Главная последовательность» и «Альтернативные последовательности». Не следует настаивать на громоздких шаблонах только потому, что о них упоминается в книге или статье. Не тратьте зря свое время.

EUC10. Затрачивают много времени, решая, что использовать: включение или расширение.

За все время преподавания нам ни разу не пришлось для выделения общих фрагментов использовать более одного механизма. Можете применять механизм включения (include) из UML или меха­низмы вызова (invoke) и предшествования (precede) из OML либо еще что-нибудь - большой роли это не играет. Важно лишь оста­новиться на чем-то одном и далее придерживаться этого выбора. Две аналогичных конструкции хуже, чем одна. Пытаясь пользо­ваться обеими, легко запутаться и увязнуть.

Работа с прецедентами

Организация прецедентов в пакеты

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

Для интернет-магазина, например, может быть такая группировка как показана на рисунке 5.

Рисунок 5 – Пакеты

Сами прецедента, входящие в пакеты, использования выглядят так, как показано ниже на рисунках 6–9. На этом этапе важно выделить сами прецеденты и их текст, не тратя время на лишние отношения между ними. Про виды отношений мы поговорим позже.

Правда два вида отношений оказываются весьма полезными с самого начала. Это отношения, выражающиеся стереотипами <<invokes>> (включает) и <<precedes>> (предшествует). С помощью первого из них можно избежать повторов при выделении общего в прецедентах. Для прецедента «Checkout invokes Dispatch Order» это отношение читается так: при выполнении действий из Checkout выполняются действия из Dispatch Order. <<precedes>> означает, что один прецедент должен быть выполнен до того, как начнется другой. Например, Login должен быть выполнен перед тем, как будет выполняться Checkout.

Рисунок 6 – Пакет General

Рисунок 7 – Пакет Admin

Рисунок 8 – Пакет Shopping

Рисунок 9 – Пакет Searching

На последней диаграмме применено отношение обобщения (Generalization). Однако его использование не очень оправдано в отличие от наследования для классов. Наследование отличается от расширения, которое вводится стереотипом <<extends>>. Разница между ними в том, что

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

·  при расширении родительский прецедент должен знать о том, что он будет расширен и чем он будет расширен (этого не происходит при наследовании, при наследовании дочерний класс ответственен за добавление или переопределение шагов родительского сценария).

Приведем таблицу сравнения основных типов отношений между прецедентов

Таблица 1 – Сравнение основных типов отношений

Отношение	Описание
Обобщение (Generalization), непрерывная линия с белым треугольником от варианта В к варианту А	В является разновидностью А. Другими словами, дочерний сценарий получает шаги из родительского и некоторые может переопределить.
A <<includes>> B	В процессе выполнения сценария А вызывается сценарий В. Когда выполнение В завершается, продолжается выполнение А. Можно сказать, что В – часть А. А зависит от В и без него выполнятся не может. Стрелка рисуется от В к А аналогично агрегации.
A <<precedes>> B	Сценарий А должен быть выполнен полностью до начала выполнения В.
A <<extends>> B	Все шаги сценария А выполняются в некоторой точке (точке расширения) при выполнении сценария В. Можно сказать, то это отношение <<includes>> наоборот. <<includes>> и <<extends>> являются разновидностями <<invokes>>, но <<invokes>> не является разновидностью <<includes>> или <<extends>>. Стрелка рисуется от А к В аналогично наследованию. B должен знать, что его расширяет А (отличие от наследования). В узнает об этом через точки расширения. Таким образом, это опциональное дополнение сценария В шагами из сценария А.
A <<invokes>> B	Сценарий В необходим во время выполнения сценария А.

В итоге, можно сказать, что расширение (extends) не особенно полезно при моделировании. Например, что реально полезного мы можем узнать, видя, что абстрактный прецедент Search for Books обобщен через несколько прецедентов? Не особенно много! Это происходит потому, что сейчас мы работаем не с классами, а фактически с фрагментами руководства пользователя, а они должны быть конкретными.

Таким образом, при моделировании прецедентов рекомендуется использовать отношения <<invokes>> и <<precedes>>.

Написание текстов прецедентов

При написании текстов прецедентов необходимо:

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

Например, для прецедента Write Reader Review текст основного сценария может быть таким:

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

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

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

Пример.

ОСНОВНОЙ СЦЕНАРИЙ.

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

АЛЬТЕРНАТИВНЫЙ СЦЕНАРИЙ.

Пользователь не авторизован. Система перенаправляет пользователя на страницу Авторизации и если он авторизуется, то возвращает его на страницу написания отзыва.

Пользователь ввел слишком длинный текст (> 1 Mb). Система отвергает отзыв и выводит сообщение, объясняющие почему отзыв был отвергнут.

Пользователь слишком короткий (< 10 символов). Система отвергает отзыв.

Основные отличия прецедента от алгоритма

Основные отличия прецедента от алгоритма приведены в таблице 2

Таблица 2 – Отличия прецедента от алгоритма

Прецедент	Алгоритм
Прецедент описывает диалог между пользователем и системой.	Описывает вычисления.
Последовательность событие/реакция на событие	Последовательность шагов
Основной/альтернативные сценарии	Алгоритм соответствует одному шагу варианта использования
Множество участвующих понятий из модели предметной области	Действия производятся над классами объектов
Участники: пользователь и система	Участники: все элементы системы

Варианты использования и аспектно-ориентированное проектирование

Аспектно-ориентированное проектирование подробно рассмотрено в книге Jacobson, Aspect-Oriented Software Development with Use Cases (Addison-Wesley, 2004). Рекомендуется познакомиться с этим подходом.

Основные идеи следующи.

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

Постоянной проблемой при написании программ является пересечение функциональности методов в реализованной системе. Постоянно код для решения одной задачи распределяется между множеством классов и компонентов. Примерами пересекающейся функциональности являются задачи безопасности, управления транзакциями, сохранения состояния в БД и т. п. Код для решения этих задач возникает в методах классов, решающих совсем другие задачи.

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

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

Аспекты помогают избежать распыления и расширения классов можно хранить отдельно.

То есть при применении АОП становится полезным отношение <<extends>>, которое находит отражение непосредственно в коде программы на АОП.

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

Таким образом, на данном этапе мы проделали работу, место которой в общем процессе представлено на рисунке 10.

Рисунок 10 – Место моделирование прецедентов в Анализе требований

Моделирование прецедентов на практике.

Упражнения.

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

Упражнение 1.

A. [из прецедента Открыть Счет] Главная последовательность. Клиент вводит требуемую информацию. Система проверяет ее корректность и создает новый объект Счет. Альтернативная последовательность. Если введенные данные некоррект­ны, система выводит соответствующее сообщение об ошибке
B. [из прецедента Поиск по Автору] Пользователь отправляет запрос. Система выводит страницу, содержащую результаты поиска.
C. [из прецедента Регистрация] Клиент вводит свой код и пароль, после чего нажимает кнопку Зарегистри­роваться. Система выводит Начальную Страницу.

Упражнение 2.

A. [из прецедента Регистрация] Название. Регистрация. Назначение. Зарегистрировать вход Клиента в систему. Предусловие. Клиент еще не зарегистрировался. Главная последовательность. Клиент вводит свой код и пароль, после чего нажимает кнопку Зарегистрироваться. Постусловие. Вход Клиента в систему зарегистрирован.
B. [из прецедента Изменить Содержимое Корзины] На Странице Корзины Клиент изменяет количество Товара в Корзине и нажимает кнопку Обновить. Затем Клиент нажимает кнопку Продолжаю Покупать.
C. [из прецедента Отменить Заказ] Главная последовательность. Система выводит информацию о Заказе на Странице Отмены Заказа, в том числе состав заказа и адрес доставки. Клиент нажимает кнопку Подтвердить отмену...

Упражнение 3.

A. [из прецедента Поиск по Автору] Клиент вводит имя Автора и отправляет запрос на поиск... Система нахо­дит существенную информацию о каждой Книге и выводит список Книг.
B. [из прецедента Изменить Содержимое Корзины] Главная последовательность. Если Клиент изменяет количество Товара в Корзине и нажимает кнопку Обновить, то система сохраняет новое количество, а затем вычисляет и показывает новую стоимость данного товара... Альтернативная последовательность. Система удаляет Товар из Корзи­ны, если его количество становится равным нулю.
C. [из прецедента Обработать Готовый к Доставке Заказ] Приемщик проверяет, что каждой Строке Заказа, присутствующей в За­казе на Покупку, соответствует физический товар. Приемщик считывает штрих-коды с упаковочного листа. Система выполняет метод изменить состо­яние заказа, чтобы перевести Заказ в состояние «выполнен», а затем вызы­вает метод сменитьДоступноеКоличество для каждой книги. Приемщик передает Книги Учетчику.

Упражнение 4.

A. [из прецедента Оформить Заказ]  Клиент выбирает метод оплаты и нажимает кнопку Использовать этот ме­тод оплаты.- Затем Клиент нажимает кнопку Подтвердить Заказ. Прецедент завершается.
B. [из прецедента Доставить Заказ] Служащий считывает штрих-коды с упаковочного листа. Система изменяет состояние Заказа на «готовится к доставке», затем выясняет, какой Метод До­ставки был указан в Заказе, и выводит его на Консоль Участка Достав­ки...
C. [из прецедента Просмотреть Недавние Заказы] Клиент щелкает по гиперссылке. Система находит и показывает в режиме чтения Состав Заказа на Странице Деталей Заказа. В частности, наверху выводятся значения из объекта Заказ, а ниже - детали о каждом Товаре, вклю­чая основные сведения о заказанных Книгах, но без пиктограмм. Для возврата на Страницу Просмотра Заказов Клиент нажимает кнопку ОК.

Упражнение 5

A. [из прецедента Доставить Заказ] Служащий заканчивает упаковку Заказа, записывает его номер и отправляет через соответствующего Поставщика.
B. [из прецедента Просмотреть Недавние Заказы] Система выводит список Заказов, которые Клиент разместил за послед­ние 30 дней... Клиент запрашивает детальную информацию о Заказе. Система находит и выводит состав Заказа в режиме чтения. Закончив просмотр данного Заказа, Клиент возвращается к списку Заказов.
C. [из прецедента Просмотреть Список Книг] Клиент щелкает по ссылке Категория на Странице Просмотра Книг. Система вызывает метод отобразитьПодкатегории объекта Категория. Процесс продолжается, пока есть подкатегории, после чего система выводит спи­сок Книг в самой глубокой подкатегории.

Задания

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

1. Прецедент (use case) описывает …

A Объекты, классы и их ассоциации.

B) Поток операций в рамках системы.

C) Дискретные, видимые пользователем функции.

D) Кооперацию (Collaborations) между объектами организованную по времени.

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

A) Абстрактным, существенным, технологически нейтральным и независимым от реализации.

B) Расплывчатым, неполным, нечетким и неоднозначным

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

D) "Полностью одетым" – в частности, необходимо указать предпосылки, постусловия и функциональные требования.

3. При написании прецедента, сценарием «на черный день» (rainy-day scenario) называют …

A) Точку расширения (дополнения).

B) Обобщенную информацию о прецеденте.

C) Альтернативный курс действий.

D) Предпосылки.

4. Построение диаграмм пригодности (Robustness diagram) для прецедентов …

A) Дает уверенность, что вы понимаете, какие объекты участвуют в прецеденте

B) Дает уверенность, что вы понимаете, как пользователи взаимодействуют с графическим интерфейсом

C) Позволяет вам проверить и перепроверить, что вы уже рассмотрели все возможные варианты действий

D) Устраняет неоднозначность текста прецедента и трансформирует его в форму существительное-глагол-существительное

E) Все вышеперечисленное

5. Перечислите три вещи, которые являются общими и для прецедентов и для разделов руководства пользователя системы. А так же перечислите три вещи, которые являются различными. (Подсказка: Какие вещи отсутствуют в инструкции, но которые необходимы для разработки программное обеспечения объектно-ориентированным методом?)

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

7. Перечислите три основных различия между прецедентом и историей пользователя в экстремальном программировании (XP). Каковы преимущества каждого из них?

8. Объясните разницу между стереотипами <<includes>> и <<extends>> в соответствии со спецификацией UML. В частности, опровергните или докажите правильность следующего утверждения: разница между стереотипами <<includes>> и <<extends>> на диаграммах прецедентов является не значительной, при условии если программное обеспечение будет реализовано с использованием аспектно-ориентированного язык программирования, который непосредственно поддерживает организацию кода вокруг расширений (дополнений). Как стереотип <<invokes>> относятся к стереотипам <<includes>> и <<extends>>? Что является основной целью всех трех из этих стереотипов? Какой из наборов стереотипов вы считаете более полезным: <<invokes>> и <<precedes>> или <<includes>> и <<extends>>?

Приложения

Готовая черновая модель предметной области

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

Рисунок – Модель предметной области Internet магазина (диаграмма классов)

Готовая диаграмма прецедентов

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

Рисунок – Диаграмма прецедентов для книжного Internet-магазина

Документация по прецедентам

Прецедент - Просмотреть Список Книг

Главная последовательность.

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

Альтернативная последовательность.

Если система не находит Книг в данной Категории, она отображает соответствующее сообщение и предлагает Клиенту выбрать другую Категорию.

Список ассоциаций.

Клиент взаимодействует с прецедентом Просмотреть Список Книг.

Прецедент - Отменить Заказ

Главная последовательность.

Система проверяет, можно ли отменить Заказ (то есть не находится ли он в состоянии «готовится к доставке» или «доставлен»). Затем система выводит информацию о Заказе на Страни­це Отмены Заказа, в том числе его состав и адрес доставки. Клиент на­жимает кнопку Подтвердить отмену. Система помечает Заказ как «уда­ленный», а затем вызывает прецедент Вернуть Товар на Склад.

Альтернативная последовательность.

Если Заказ находится в состоянии «готовится к доставке» или «доставлен», то система выводит сообщение о том, что отменять Заказ уже поздно.

Список ассоциаций.

Страница Результатов Поиска взаимодействует с прецедентом Отменить Заказ.

Прецедент – Оформить Заказ

Главная последовательность.

Система создает объект Возможный Заказ, который содержит все товары из Корзины Клиента, затем извлекает Адреса Доставки, ассоциированные со Счетом Клиента, и отображает их на Странице Адреса Доставки.

Клиент выбирает адрес и нажимает кнопку Использовать этот адрес. Система ассоциирует выбранный Адрес Доставки с Возможным Заказом, после чего выводит разрешенные Методы Доставки на Странице Метода Доставки.

Клиент выбирает метод доставки и нажимает кнопку Использовать этот метод доставки. Система ассоциирует выбранный Метод Доставки с Возможным Заказом, после чего выводит содержимое объектов Платежная формация, ассоциированных со Счетом Клиента, на Странице Метода Платежа.

Клиент выбирает метод платежа и нажимает кнопку Использовать этот метод платежа. Система ассоциирует выбранный объект Платежная формация с Возможным Заказом, затем выводит Страницу Подтверждения Заказа.

Клиент нажимает кнопку Подтвердить заказ. Система преобразует Возможный Заказ в Заказ и уничтожает Корзину, а потом возвращает управление вызывающему прецеденту.

Альтернативные последовательности.

Если Клиент еще не зарегистрирован, система вызывает прецедент Регистрация.

Если система не находит Адресов Доставки, она вызывает прецедент Создать Адрес Доставки.

Если система не находит объектов Метод Платежа, она вызывает пре­цедент Определить Метод Платежа.

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

Список ассоциаций.

Клиент взаимодействует с прецедентом Оформить Заказ.

Страница Просмотра Корзины взаимодействует с прецедентом Оформить Заказ.

Прецедент - Изменить Содержимое Корзины

Главная последовательность.

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

Клиент нажимает кнопку Продолжаю Покупать. Система возвращает управление вызывающему прецеденту.

Альтернативные последовательности.

Если Клиент изменяет количество на 0, то система удаляет Товар из Корзины.

Если Клиент нажимает кнопку Удалить вместо кнопки Обновить, то система удаляет Товар из Корзины.

Если Клиент нажимает кнопку Оформить Заказ вместо кнопки Продолжаю Покупать, система передает управление прецеденту Оформить Заказ.

Список ассоциаций.

Клиент взаимодействует с прецедентом Изме­нить Содержимое Корзины.

Прецедент - Регистрация

Главная последовательность.

Клиент нажимает кнопку Зарегистриро­ваться на Начальной Странице. Система выводит Страницу Регистра­ции. Клиент вводит свой код и пароль и нажимает кнопку Зарегистриро­ваться.

Система сравнивает введенную информацию с данными, хранящими­ся в Счете, после чего открывает Начальную Страницу.

Альтернативные последовательности.

Если Клиент нажимает кнопку Новый счет на Странице Регистрации, то система вызывает прецедент Открыть Счет.

Если Клиент нажимает кнопку Вспомнить на Странице Регистра­ции, то система выводит секретный вопрос, хранящийся для этого Кли­ента, в отдельном диалоговом окне. Когда Клиент щелкает в нем по кноп­ке ОК, открывается Страница Регистрации.

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

Если Клиент ввел неправильный пароль, то система выводит соответ­ствующее сообщение и предлагает повторно ввести пароль.

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

Список ассоциаций.

Клиент взаимодействует со Страницей Регистрации.

Прецедент - Открыть Счет

Главная последовательность.

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

Альтернативные последовательности.

Если Клиент не ввел имя, сис­тема выводит соответствующее сообщение об ошибке и предлагает ввести имя.

Если формат введенного Клиентом электронного адреса некорректен, система выводит соответствующее сообщение об ошибке и предлагает Клиенту ввести другой адрес.

Если Клиент ввел слишком короткий пароль, система выводит соот­ветствующее сообщение об ошибке и предлагает ввести более длинный па­роль.

Если два введенных Клиентом пароля различаются, система выводит соответствующее сообщение об ошибке и предлагает ввести пароль по­вторно.

Если Счет уже есть в Главной Таблице Счетов, система сообщает об этом Клиенту.

Список ассоциаций.

Клиент взаимодействует с прецедентом Открыть Счет. Страница Регистрации взаимодействует с прецедентом Открыть Счет.

Прецедент Открыть Счет взаимодействует со Страницей Регис­трации.

Прецедент - Обработать Готовый к Доставке Заказ

Главная последовательность.

Приемщик проверяет, что каждой Стро­ке Заказа, присутствующей в Заказе на Покупку, соответствует физи­ческий товар. Приемщик считывает штрих-коды с упаковочного листа.

Система изменяет состояние Заказа на «выполнен» и обновляет ко­личество каждой книги. Приемщик передает Книги Учетчику.

Альтернативная последовательность.

Если Упаковщик обнаруживает расхождение между Заказом и подобранными физическими товарами, то он прекращает обработку Заказа до устранения неувязок.

Список ассоциаций.

Приемщик взаимодействует с прецедентом Об­работать Готовый к Доставке Заказ. Прецедент Обработать Гото­вый к Доставке Заказ взаимодействует с Учетчиком. Прецедент Об­работать Готовый к Доставке Заказ взаимодействует с Участком Приемки.

Прецедент - Поиск по Автору

Главная последовательность.

Клиент вводит имя Автора на Страни­це Поиска, после чего нажимает кнопку Искать. Система проверяет пра­вильность запроса, после чего ищет в Каталоге все удовлетворяющие за­просу Книги.

Для каждой найденной Книги система извлекает существенные дета­ли и создает на их основе объект Результаты Поиска. Затем система вы­водит список Книг на Странице Результатов Поиска, отсортированный по датам издания в порядке убывания. В каждой строке выводится пиктограмма обложки, название Книги и имена Авторов, средний Рейтинг и кнопка Добавить в корзину.

Клиент нажимает кнопку Добавить в корзину для выбранной книги. :ма передает управление прецеденту Добавить Товар в Корзину.

Альтернативные последовательности.

Если Клиент нажал кнопку Искать, ­не введя запроса, система отобразит сообщение об ошибке и предложит ввести критерий поиска.

Если система не находит Книг данного Автора, она выводит соответствующее сообщение и предлагает Клиенту задать другой критерий поиска, ли Клиент закрывает страницу не нажатием кнопки Добавить в корзину, а каким-то другим способом, система возвращает управление тому прецеденту, из которого был вызван данный.

Список ассоциаций.

Клиент взаимодействует с прецедентом Поиск по Автору

Прецедент - Доставить Заказ

Главная последовательность.

Упаковщик проверяет, что товары, перечисленные в упаковочном листе для данного Заказа, соответствуют физически представленным Товарам, и считывает штрих-коды с упаковочного листа.

Система изменяет состояние Заказа на «готовится к доставке», после чего находит Метод Доставки, указанный Клиентом для данного Заказа, и выводит его на Консоль Участка Доставки.

Упаковщик взвешивает и пакует физические Товары, наклеивает накладную, соответствующую методу доставки, и отправляет бандероль через соответствующего Поставщика.

Альтернативная последовательность.

Если Упаковщик обнаруживает несоответствия между Заказом и физическими Товарами, он прекращает обработку Заказа до выяснения обстоятельств.

Список ассоциаций.

Упаковщик взаимодействует с прецедентом Доставить Заказ. Прецедент Доставить Заказ взаимодействует с Поставщиком и Участком Доставки.

Прецедент - Просмотреть Недавние Заказы

Главная последовательность.

Система находит Заказы, которые Кли­ент разместил в течение последних 30 дней, и выводит данные об этих За­казах на Страницу Просмотра Заказов. В каждой строке указывается идентификатор (в виде гиперссылки), дата, состояние, получатель и Ме­тод Доставки Заказа.

Клиент щелкает по гиперссылке. Система извлекает данные о содержи­мом Заказа и создает объект Детали Заказа. Система выводит содержи­мое этого объекта в режиме чтения на Странице Деталей Заказа. Клиент нажимает кнопку ОК для возврата к Странице Просмотра Заказов.

Закончив просмотр Заказов, Клиент щелкает по ссылке Ведение сче­та на Странице Просмотра Заказов'. Система возвращает управление вызывающему прецеденту.

Альтернативная последовательность.

Если Клиент' не разместил за последние 30 дней ни одного Заказа, то на Странице Просмотра Зака­зов появляется соответствующее сообщение.

Список ассоциаций.

Клиент взаимодействует с прецедентом Про­смотреть Недавние Заказы.