Редактирование данных, Поиск лекарства, Учет заказов, Формирование отчетов, Выдача рецепта, Авторизация. Элементы диаграммы прецедентов (прецеденты и актеры) должны быть связаны отношениями. Наиболее распространенным отношением между прецедентами, прецедентами и актерами является ассоциация. В некоторых случаях могут быть использованы отношения обобщения. Данные отношения имеют тот же смысл, что и на диаграмме классов. Кроме того, между прецедентами в языке UML определены две специфические зависимости - отношение включения и отношение расширения. Отношение включения между прецедентами означает, что в некоторой точке базового прецедента инкорпорировано (включено) поведение другого прецедента. Включаемый прецедент никогда не существует автономно, а инсталлируется только как часть объемлющего прецедента. Можно считать, что базовый прецедент заимствует поведение включаемых. Благодаря наличию отношений включения удается избежать многократного описания одного и того же потока событий, поскольку общее поведение можно описать в виде самостоятельного прецедента, включаемого в базовые. Отношение включения является примером делегирования, при котором ряд обязанностей системы описывается в одном месте (во включаемом прецеденте), а остальные прецеденты, когда необходимо, включают эти обязанности в свой набор. Отношения включения изображаются в виде зависимостей со стереотипом «include». Чтобы специфицировать место в потоке событий, где базовый прецедент включает поведение другого, вы просто пишете слово include, за которым следует имя включаемого прецедента. Отношение расширения применяют для моделирования таких частей прецедента, которые пользователь воспринимает как необязательное поведение системы. Тем самым можно разделить обязательное и необязательное поведение. Отношения расширения используются также для моделирования отдельных субпотоков, выполняемых лишь при определенных обстоятельствах. Наконец, их применяют для моделирования нескольких потоков, которые могут включаться в некоторой точке сценария в результате явного взаимодействия с актером. Отношение расширения изображают в виде зависимости со стереотипом «extend». Точки расширения базового сценария перечисляются в дополнительном разделе. Они являются просто метками, которые могут появляться в потоке базового прецедента. Примером использования данного отношения может быть доступ к базе данных имеющую оперативную часть и архив. При этом если запрос обеспечивается данными оперативной части, выполняется основной (базовый) доступ к данным, если же данных оперативной части недостаточно, производится доступ к данным архива, то есть доступ идет по расширенному сценарию. В нашем случае, прецедент редактирование данных включает в себя прецеденты: ввод данных, удаление данных, изменение данных. Диаграмма прецедентов информационно-справочной системы «Аптека» показана на рис. 1. Прецедент поиск лекарства предполагает поиск по группе и поиск по названию. При разработке вида с точки зрения прецедентов часто необходимо дать расширенное описание прецедента (в сокращенном варианте указывается только его имя). Как правило, в начале работы потоки событий прецедента описывают в текстовой форме. По мере уточнения требований к системе будет удобнее перейти к графическому изображению потоков на диаграммах деятельности и взаимодействия.
Рис. 1. Диаграмма прецедентов информационно-справочной системы «Аптека»
Потоки событий могут быть описаны посредством неструктурированного текста, структурированного текста (содержащего служебные слова: если, до тех пор, пока и т.п.), специализированного формального языка (псевдокода). При описании прецедента потоком событий важно обозначить также основной и альтернативный потоки поведения системы. Для примера рассмотрим описание потока событий прецедента авторизация. Основной поток событий. Прецедент начинается, когда система запрашивает у пользователя его входное имя (Login) и пароль (Password). Пользователь может ввести его с клавиатуры. Завершается ввод нажатием клавиши Enter. После этого система проверяет введенные Login и пароль, и если они соответствуют администратору, подтверждает полномочия администратора. На этом прецедент заканчивается. Исключительный поток событий. Клиент может прекратить транзакцию в любой момент, нажав клавишу Cancel. Это действие начинает прецедент заново. Ввод в систему не производится.
Рис. 2. Авторизация пользователя. Диаграмма деятельности
Исключительный поток событий. Клиент может в любой момент до нажатия клавиши Enter стереть свои Login и пароль. Исключительный поток событий. Если клиент ввел Login и пароль не соответствующий администратору, ему предлагается произвести повторный ввод или войти в систему на правах рядового пользователя. Очевидно, что описание прецедента потоком событий предполагает некоторый алгоритм, который можно представить на диаграмме деятельности (рис. 2). Диаграмма алгоритма должна содержать начальную и конечную вершины, причем, только одну начальную, и одну конечную. Диаграмма содержит исполняемые вершины - деятельности (обозначаются скругленными прямоугольниками), условные вершины (decision - выбор, распознавание, обозначаются ромбиками) и связи. Подобными диаграммами можно пояснить и выполнение других прецедентов, таким образом дополнить вид системы с точки зрения прецедентов использования.