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

Стр 1 из 3Следующая ⇒

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

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

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

Нефункциональные требования - это описание таких свойств системы, как:

· особенности среды и реализации,

· производительность,

· расширяемость,

· надежность и т. д.

Часто нефункциональные требования не привязаны к конкретному варианту использования и потому выносятся в отдельный список дополнительных требований к системе (рис. 7.2).

Рис. 7.2. Замена полностью текстовых описаний на более компактные

Кто определяет прецеденты, цель их идентификации и последовательность действий при их определении?

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

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

Подобный вид деятельности обычно выполняется в такой последовательности:

1. Определение действующих лиц.

2. Определение прецедентов.

3. Составление описания каждого прецедента.

4. Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).

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

Рассмотрим пример из области фантастики: сотрудники одной из фирм могут выбрать и заказать себе обеденные блюда на неделю.

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

Офис-менеджер должен иметь возможность сформировать счет и оплатить его. Система должна быть написана на ASP.NET. Такое вот нехитрое интранет-приложение для автоматизации заказов обедов в офис.

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

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

Здесь нигде не сказано о том, что система должна быть написана на ASP.NET, так как это - нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. Следовательно, в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно применить генерализацию. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис. 7.3):

Рис. 7.3.

Рис. 7.4.

Несмотря на " человеческий" вид этого обозначения, не следует забывать, что экторы - это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д.

Кстати, человечек (" stick-person" ) - это не единственное обозначение эктора, используемое в UML. На диаграммах прецедентов обычно применяется именно " человекоподобная" форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом < < actor> > (рис. 7.5):

Рис. 7.5.

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

Рис. 7.6.

В этом примере пассажир может купить в сервисной кассе билет на некоторый вид транспорта. Покупка билета - это название сценария, по которому эктор (пассажир) может взаимодействовать с системой (кассой). Заметьте, это не описание сценария, а именно название - оно говорит нам, что делает эктор в процессе взаимодействия, но не говорит, как именно!

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

Рис. 6.7.

Запись сценария

Сценарии должны быть записаны. Это также можно сделать различными способами в разных формах.

Это может быть:

· структурированный, но неформализованный текст,

· формализованный структурированный текст,

· псевдокод,

· таблица,

· диаграмма активностей, наконец!

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

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

Вот пример простого (неформализованного) текстового описания сценария.

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

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

А вот тот же сценарий в табличном представлении:

Действия пользователя	Реакция системы
Ввод логина, пароля, адреса электронной почты и нажатие кнопки " Далее"	Запрос ввода проверочного кода
Ввод проверочного кода и нажатие кнопки " Далее"	Проверка кода на соответствие изображенному на картинке

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

7.5 Связь прецедента и сценария (сценариев! )

Прецеденты рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии.

Таким образом, прецедент можно специфицировать ( то есть полностью определить) путем описания потока действий или событий в текстовой форме - в виде, понятном для " постороннего" ( не занятого в непосредственной разработке системы) читателя. А ведь такое описание - это и есть сценарий!

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

В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой " псевдодиаграммой" (рис. 7.8).

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

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

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

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

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

Рис. 7.9.

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

Рис. 7.10.

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

Рис. 7.11.

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

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

Рис. 7.12.

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

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

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

7.6.4. Резюме по выделению общих прецедентов и их вариантов

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

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

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

Рис. 7.15.

Следующие три примера взяты с сайта шуток на UML (http: //www.umljokes.com), продолжая доказывать, что на UML можно шутить - это полноценный язык общения, который можно применять так же, как и любой другой. Первый из примеров - это часть всем известной сказки о " Курочке Рябе", которую автор очень красочно оформил (рис. 7.16).

Рис. 7.16.

Вторая диаграмма, тоже неплохо оформленная, говорит нам о том, что утки очень не любят платить за пиво, предпочитая пить в долг (рис. 7.17).

Рис. 7.17.

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

И наконец, третья картинка, которая не является хорошим примером диаграммы прецедентов, но просто забавна. Это рассказ о способах поведения, позволяющих гарантированно (! ) провалить любой экзамен (рис. 7.18):

Рис. 7.18.

Выводы

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

Контрольные вопросы

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