Дж. Арлоу, А. Нейштадт - UML 2 и Унифицированный процесс - Практический объектно-ориентированный анализ и проектирование, страница 19

Затем все действия осуществляютсяитеративно и зачастую параллельно.Прецеденты – способ записи требований.Результат этой деятельности – модель прецедентов. В этой модели четыре компонента:•Граница системы – прямоугольник, очерчивающий прецеденты дляобозначения края, или границы, моделируемой системы. В UML 2эту границу называют контекстом системы (subject).•Актеры – роли, выполняемые людьми или сущностями, использующими систему.•Прецеденты – то, что актеры могут делать с системой.•Отношения – значимые отношения между актерами и прецедентами.Модель прецедентов является основным источником объектов и классов. Это основные исходные данные для моделирования классов.92Глава 4. Моделирование прецедентов4.3.

Деятельность UP: Выявление актерови прецедентовМоделирование прецедентов включает выявление актеров и прецедентов.В этом разделе основное внимание сосредоточено на деятельности Выявление актеров и прецедентов рабочего потока определения требований(см. раздел 3.4), изображенной на рис. 4.2. В разделе 4.4 мы рассмотрим деятельность Детализация прецедента.Рассмотрим исходные данные для деятельности Выявление актеров и прецедентов.•Бизнесмодель – может быть предоставлена в распоряжение разработчиков модели системы, но это не всегда выполняется.

Если онаесть, это превосходный источник для сбора требований.•Модель требований – создание этой модели было описано в главе 3.Эти требования являются хорошим исходным материалом для процесса моделирования прецедентов. В частности, функциональныетребования предложат прецеденты и актеров. Нефункциональныетребования – то, о чем надо помнить при создании модели прецедентов.•Список возможностей – это набор потенциальных требований, которые могут быть представлены в форме общего описания (vision)проекта или чеголибо подобного.Бизнес!модель[или модель предметной области]Модель требованийСписок возможностейСистемныйаналитикМодель прецедентов[в общих чертах]Выявление актерови прецедентовГлоссарий проектаРис.

4.2. Деятельность UP: Выявление актеров и прецедентов. Адаптированос рис. 7.11 [Jacobson 1] с разрешения издательства Addison+Wesley4.3. Деятельность UP: Выявление актеров и прецедентов93В оригинальной работе Джекобсона [Jacobson 1] вместо Модели требований (на рис. 4.2 этот прямоугольник затушеван, чтобы обозначить изменение, внесенное в исходный рисунок) присутствовали дополнительные требования. Сюда были включены требования (обычно нефункциональные), не относящиеся ни к одному из конкретных прецедентов. Этот документ являлся, главным образом, вместилищем длявсех нефункциональных требований, противоречащих прецедентам.В нашем более устойчивом подходе к выработке требований дополнительные требования были разбиты на категории и включены в Модельтребований в качестве подраздела.4.3.1.

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

В UML 2 границу системы называют контекстом сис+темы (subject). Этого термина будем придерживаться и мы.Контекст системы определяется тем, кто или что использует систему(т. е. актерами), и тем, какие конкретные преимущества система предлагает этим актерам (т. е. прецедентами).Контекст изображается в виде прямоугольника с именем системы. Актеры размещаются вне границ блока, а прецеденты – внутри.

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

Онможет представлять роль пользователя или роль, исполняемую другой94Глава 4. Моделирование прецедентовсистемой или частью аппаратных средств, которые касаются границсистемы.В UML 2 актеры могут также представлять другие контексты системы,обеспечивая возможность объединения разных моделей прецедентов.Роль подобна шляпе, которую надевают в определенной ситуации.Для понимания актеров важно понимать концепцию ролей.

Роль можно рассматривать как шляпу, которую надевают в определенной ситуации. Сущности могут играть несколько ролей одновременно либоисполнять их последовательно во времени. Это означает, что даннаяроль может исполняться многими разными сущностями одновременнолибо последовательно во времени.Например, если в системе определен актер Customer (покупатель), тоэту роль могут исполнять реальные люди – Джим, Ила, Вольфганг,Роланд и многие другие.

Эти люди могут играть и другие роли. Например, Роланд может быть и системным администратором (актер SystemAdministrator), и пользователем Customer.Основная ошибка новичков в моделировании прецедентов – смешивание роли, выполняемой некоторой сущностью в контексте системы,с самой сущностью. Всегда спрашивайте себя: «Какую роль играет этасущность по отношению к системе?» Так можно выявить общность поведения разных сущностей и таким образом упростить модель прецедентов.В UML актеры изображаются так, как показано на рис. 4.3. Они могутбыть изображены в виде пиктограммы класса с указанием стереотипа«actor» или в виде пиктограммы «анимационный человечек».

Допускаются обе формы, но многие разработчики моделей предпочитают использовать «человечка» для тех ролей, которые, скорее всего, будутвыполняться людьми, а пиктограммы класса для ролей, которые будут играть другие системы.Актеры являются внешними по отношению к системе.Важно осознавать, что актеры всегда являются внешними по отношению к системе. Например, покупатель является внешним звеном в системе электронной торговли, такой как книжный интернетмагазин.Однако интересно отметить, что хотя сами актеры всегда находятся«actor»CustomerCustomerРис.

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

Это внутреннее представление внешнегоактера Customer. Важно четко разобраться в этом различии. Актер Customer является внешним по отношению к системе, но система можетобслуживать класс CustomerDetails (информация о покупателе), который является внутренним представлением субъектов, играющихроль актера Customer.4.3.2.1.

Идентификация актеровДля идентификации актеров необходимо ответить на вопросы: кто иличто использует систему и какие роли выполняются актерами при взаимодействии с системой. Чтобы выявить роли, которые люди или сущности играют во взаимодействии с системой, можно учесть, а затемобобщить примеры конкретных людей и сущностей. Следующие вопросы помогут идентифицировать актеров.Чтобы выявить актеров, спросите: «Кто или что использует или взаимодействует с системой?»••••••••Кто или что использует систему?Какие роли они играю во взаимодействии?Кто устанавливает систему?Кто или что запускает и выключает систему?Кто обслуживает систему?Какие системы взаимодействуют с данной системой?Кто или что получает и предоставляет информацию системе?Происходит ли чтонибудь в точно установленное время?При моделировании актеров необходимо помнить следующие моменты.• Актеры всегда являются внешними по отношению к системе, следовательно, находятся вне вашего контроля.• Актеры взаимодействуют непосредственно с системой – так они помогают в определении контекста системы.• Актеры представляют роли, исполняемые людьми или сущностямипо отношению к системе, а не конкретных людей или сущностей.• Один человек или сущность может играть по отношению к системемножество ролей одновременно или последовательно во времени.Например, вы составляете и ведете учебные курсы.

С точки зрениясистемы планирования курсов вы играете две роли: Trainer (инструктор) и CourseAuthor (автор курса).• У каждого актера должно быть короткое, осмысленное с прикладной точки зрения имя.96Глава 4. Моделирование прецедентов•Каждого актера должно сопровождать краткое описание (одна илидве строчки), объясняющее, что данный актер из себя представляетс прикладной точки зрения.•Как и в классах, в обозначении актеров могут быть представленыатрибуты актера и события, которые он может получать. Такие обозначения не часто используются и редко отображаются на диаграммах прецедентов. Далее в этой книге они не упоминаются.4.3.2.2.