7.2 Кто определяет прецеденты, цель их идентификации и последовательность действий при их определении?
Идентифицировать прецеденты и действующие лица - обязанность системного аналитика. И делает он это для того, чтобы:
четко разграничить систему и ее окружение;
определить, какие действующие лица и как именно взаимодействуют с системой, какой функционал (варианты использования) ожидается от системы;
определить и описать в словаре предметной области (глоссарии) общие понятия, которые необходимы для детального описания функционала системы (прецедентов).
Подобный вид деятельности обычно выполняется в такой последовательности:
Определение действующих лиц.
Определение прецедентов.
Составление описания каждого прецедента.
Описание модели прецедентов в целом (этот этап включает в себя создание словаря предметной области).
Вначале требования оформляются в виде обычного текстового документа, который создается или самим пользователем, или пользователем и разработчиком вместе. Далее требования оформляют в виде таблицы. В левую колонку помещают прецеденты, а в правую - действующих лиц, участвующих в прецеденте.
Рассмотрим пример из области фантастики: сотрудники одной из фирм могут выбрать и заказать себе обеденные блюда на неделю.
Для реализации такого сервиса секретарь размещает на сервере меню обеденных блюд на неделю. Сотрудники должны иметь возможность ознакомиться с меню и сделать заказ, выбрав блюда на каждый день следующей недели.
Офис-менеджер должен иметь возможность сформировать счет и оплатить его. Система должна быть написана на ASP.NET. Такое вот нехитрое интранет-приложение для автоматизации заказов обедов в офис.
Таблица с описанием требований может быть, например, такой:
Прецедент |
Действующее лицо |
разместить меню |
секретарь |
ознакомиться с меню |
сотрудник, секретарь, офис-менеджер |
сделать заказ |
сотрудник, секретарь, офис-менеджер |
сформировать счет |
офис-менеджер |
оплатить счет |
офис-менеджер |
Здесь нигде не сказано о том, что система должна быть написана на ASP.NET, так как это - нефункциональное требование! И еще, очевидно, что секретарь и офис-менеджер тоже являются сотрудниками. Следовательно, в данном случае, создавая модель прецедентов, говоря о действующих лицах, можно применить генерализацию. Действительно, диаграмма прецедентов, построенная на основе этой таблицы, может быть, например, такой (рис. 7.3):
Рис. 7.3.
7.3 Диаграммы прецедентов: и их нотация и правила их изображения
Какие же элементы мы видим на этой диаграмме?
Большой прямоугольник, внутри которого размещаются эллипсы, обозначающие прецеденты. В верхней части прямоугольника указано название моделируемой системы. Этот прямоугольник называется рамками системы (system boundary, subject boundary), контекстом или просто системой. Этот элемент диаграммы показывает границу между тем, что вы как аналитик показали в виде прецедентов (внутри этих рамок), и тем, что вы изобразили как действующих лиц (вне их). Чаще всего таким прямоугольником показывают границы самой моделируемой системы. То есть внутри границы находятся прецеденты - тот функционал, который реализует система (и в этом смысле прецеденты могут рассматриваться как представления подсистем и классов модели), а снаружи - действующие лица: пользователи и другие внешние сущности, взаимодействующие с моделируемой системой.
Рамки системы на диаграммах прецедентов изображают довольно редко, т. к. они неявно подразумеваются самой диаграммой. По сути, этот элемент не привносит в диаграмму какой-либо дополнительной значимой информации, так что его использование - дело вкуса аналитика. Появление рамок системы на диаграмме прецедентов чаще всего диктуется особенностями персонального стиля проектирования.
Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей - это действующие лица (экторы, actors) и прецеденты.
Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин "актер". В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово "актер"? Это слово - "роль"!
Какой же смысл вкладывают в понятие эктора?
Эктор - это набор ролей, которые исполняет пользователь в ходе взаимодействия с некоторой сущностью (системой, подсистемой, классом).
Эктор может быть:
человеком,
другой системой,
подсистемой или
классом,
которые представляют нечто за пределами рассматриваемой сущности.
Экторы "общаются" с системой путем обмена сообщениями. Четко выделив экторов, вы тем самым ясно определяете границу между тем, что внутри системы, и тем, что снаружи, - рамки системы.
Возможно, слова "роли, исполняемые пользователем" звучат не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor:
«Роль - это не конкретный пользователь, а подобие шляпы, которую человек надевает, когда взаимодействует с сущностью.»
"Физический" пользователь может играть роль одного или даже нескольких экторов, выполняя их функции в ходе взаимодействия с системой. И наоборот, роль одного и того же эктора может выполняться несколькими пользователями.
На диаграммах UML экторы изображаются в виде стилизованных человечков, так как идея языка UML была в создании нотации, любой символ которой легко может быть изображен от руки (рис. 7.4):
Рис. 7.4.
Несмотря на "человеческий" вид этого обозначения, не следует забывать, что экторы - это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д.
Кстати, человечек ("stick-person") - это не единственное обозначение эктора, используемое в UML. На диаграммах прецедентов обычно применяется именно "человекоподобная" форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом <<actor>> (рис. 7.5):
Рис. 7.5.
С системой экторы общаются через сообщения, но, если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты.
Рассмотрим определение понятия ассоциации.
Один и тот же эктор может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными экторами. Ассоциации между эктором и прецедентом всегда бинарные - т. е. представляют отношения типа "один к одному", использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один эктор может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций - по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого обозначения вполне понятен: это направленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д.
Наконец, очень важное требование к правильности отображения диаграмм прецедентов: - экторы не могут быть связаны друг с другом ничем кроме как единственного вида отношения между - генерализации (наследования).
В примере с заказом обедов в офис показан именно такой вид отношений между экторами. Это не значит, что в реальной жизни офис-менеджер и секретарь (да и вообще любые два сотрудника) не могут общаться: просто при создании модели прецедентов такое общение не попадает в область наших интересов, считается несущественным.
Еще один тип элементов, встречающийся на диаграммах прецедентов, более того, давший им название, - это собственно прецеденты, или варианты использования.
Прецедент - это описание набора последовательных событий (включая возможные варианты), выполняемых системой, которые приводят к наблюдаемому эктором результату.
Прецеденты описывают сервисы, предоставляемые системой экторам, с которыми она взаимодействует. Причем прецедент никогда не объясняет, "как" работает сервис, а только описывает, "что" делается.
Изображаются прецеденты в виде эллипса, внутрь контура которого помещается имя (описание) прецедента. Имя прецедента обычно намного длиннее имен других элементов модели. Почему это так, в принципе, понятно: имя прецедента описывает взаимодействие эктора с системой, говорит о том, какими сообщениями они обмениваются между собой. В примере с заказом обедов представлены несколько прецеденто, и имя прецедента - это, скорее, название сценария, воспроизводящегося в ходе взаимодействия эктора с системой. Причем это всегда описание с точки зрения эктора, описание услуг, предоставляемых системой пользователю. Приведем пример простейшей диаграммы, иллюстрирующей сказанное нами об обозначениях прецедента (рис. 7.6).
Рис. 7.6.
В этом примере пассажир может купить в сервисной кассе билет на некоторый вид транспорта. Покупка билета - это название сценария, по которому эктор (пассажир) может взаимодействовать с системой (кассой). Заметьте, это не описание сценария, а именно название - оно говорит нам, что делает эктор в процессе взаимодействия, но не говорит, как именно!
И еще - прецеденты определяют непересекающиеся сценарии поведения. Выполнение одного прецедента не может быть прервано в результате работы другого прецедента. Другими словами, выполнение одного прецедента не может быть прервано в результате событий или действий, вызванных выполнением другого прецедента.
Прецеденты выступают как атомарные транзакции, выполнение которых не может быть прервано.