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

Подождите немного. Документ загружается.

4.3. Деятельность UP: Выявление актеров и прецедентов 93

В оригинальной работе Джекобсона [Jacobson 1] вместо Модели требова

ний (на рис. 4.2 этот прямоугольник затушеван, чтобы обозначить из

менение, внесенное в исходный рисунок) присутствовали дополни

тельные требования. Сюда были включены требования (обычно не

функциональные), не относящиеся ни к одному из конкретных преце

дентов. Этот документ являлся, главным образом, вместилищем для

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

В нашем более устойчивом подходе к выработке требований дополни

тельные требования были разбиты на категории и включены в Модель

требований в качестве подраздела.

4.3.1. Контекст системы (границы системы)

Контекст системы отделяет систему от остального мира.

Первое, что необходимо сделать при построении системы, – обозначить

ее границы. Иначе говоря, надо определить, что является частью сис

темы (находится внутри границ системы) и что находится вне системы

(вне ее границ). Это кажется очевидным, но встречается немало проек

тов, в которых изза неясности границы системы возникают серьезные

проблемы. Точное определение границ системы обычно играет важ

ную роль в выявлении функциональных (а иногда и нефункциональ

ных) требований. Мы уже были свидетелями того, как неполные и не

правильно заданные требования могут стать основной причиной не

удач проектов. В UML 2 границу системы называют контекстом сис+

темы (subject). Этого термина будем придерживаться и мы.

Контекст системы определяется тем, кто или что использует систему

(т. е. актерами), и тем, какие конкретные преимущества система пред

лагает этим актерам (т. е. прецедентами).

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

теры размещаются вне границ блока, а прецеденты – внутри. В нача

ле моделирования прецедентов имеется лишь предварительное пред

ставление о том, где находятся границы системы. По мере выявления

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

очертания.

4.3.2. Что такое актеры?

Актеры – это роли, исполняемые сущностями, непосредственно взаимо

действующими с системой.

Актер определяет роль, которую выполняет некоторая внешняя сущ

ность при непосредственном взаимодействии с данной системой. Он

может представлять роль пользователя или роль, исполняемую другой

94 Глава 4. Моделирование прецедентов

системой или частью аппаратных средств, которые касаются границ

системы.

В UML 2 актеры могут также представлять другие контексты системы,

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

Роль подобна шляпе, которую надевают в определенной ситуации.

Для понимания актеров важно понимать концепцию ролей. Роль мож

но рассматривать как шляпу, которую надевают в определенной си

туации. Сущности могут играть несколько ролей одновременно либо

исполнять их последовательно во времени. Это означает, что данная

роль может исполняться многими разными сущностями одновременно

либо последовательно во времени.

Например, если в системе определен актер Customer (покупатель), то

эту роль могут исполнять реальные люди – Джим, Ила, Вольфганг,

Роланд и многие другие. Эти люди могут играть и другие роли. Напри

мер, Роланд может быть и системным администратором (актер System

Administrator), и пользователем Customer.

Основная ошибка новичков в моделировании прецедентов – смешива

ние роли, выполняемой некоторой сущностью в контексте системы,

с самой сущностью. Всегда спрашивайте себя: «Какую роль играет эта

сущность по отношению к системе?» Так можно выявить общность по

ведения разных сущностей и таким образом упростить модель преце

дентов.

В UML актеры изображаются так, как показано на рис. 4.3. Они могут

быть изображены в виде пиктограммы класса с указанием стереотипа

«actor» или в виде пиктограммы «анимационный человечек». Допус

каются обе формы, но многие разработчики моделей предпочитают ис

пользовать «человечка» для тех ролей, которые, скорее всего, будут

выполняться людьми, а пиктограммы класса для ролей, которые бу

дут играть другие системы.

Актеры являются внешними по отношению к системе.

Важно осознавать, что актеры всегда являются внешними по отноше

нию к системе. Например, покупатель является внешним звеном в сис

теме электронной торговли, такой как книжный интернетмагазин.

Однако интересно отметить, что хотя сами актеры всегда находятся

«actor»

Customer

Рис. 4.3. Варианты изображения актера

4.3. Деятельность UP: Выявление актеров и прецедентов 95

вне системы, системы обычно имеют некоторое внутреннее представ

ление одного или более актеров. Например, книжный интернетмага

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

адрес и другую информацию. Это внутреннее представление внешнего

актера Customer. Важно четко разобраться в этом различии. Актер Cus

tomer является внешним по отношению к системе, но система может

обслуживать класс CustomerDetails (информация о покупателе), кото

рый является внутренним представлением субъектов, играющих

роль актера Customer.

4.3.2.1. Идентификация актеров

Для идентификации актеров необходимо ответить на вопросы: кто или

что использует систему и какие роли выполняются актерами при взаи

модействии с системой. Чтобы выявить роли, которые люди или сущ

ности играют во взаимодействии с системой, можно учесть, а затем

обобщить примеры конкретных людей и сущностей. Следующие во

просы помогут идентифицировать актеров.

Чтобы выявить актеров, спросите: «Кто или что использует или взаимо

действует с системой?»

• Кто или что использует систему?

• Какие роли они играю во взаимодействии?

• Кто устанавливает систему?

• Кто или что запускает и выключает систему?

• Кто обслуживает систему?

• Какие системы взаимодействуют с данной системой?

• Кто или что получает и предоставляет информацию системе?

• Происходит ли чтонибудь в точно установленное время?

При моделировании актеров необходимо помнить следующие моменты.

• Актеры всегда являются внешними по отношению к системе, сле

довательно, находятся вне вашего контроля.

• Актеры взаимодействуют непосредственно с системой – так они по

могают в определении контекста системы.

• Актеры представляют роли, исполняемые людьми или сущностями

по отношению к системе, а не конкретных людей или сущностей.

• Один человек или сущность может играть по отношению к системе

множество ролей одновременно или последовательно во времени.

Например, вы составляете и ведете учебные курсы. С точки зрения

системы планирования курсов вы играете две роли: Trainer (инструк

тор) и CourseAuthor (автор курса).

• У каждого актера должно быть короткое, осмысленное с приклад

ной точки зрения имя.

96 Глава 4. Моделирование прецедентов

• Каждого актера должно сопровождать краткое описание (одна или

две строчки), объясняющее, что данный актер из себя представляет

с прикладной точки зрения.

• Как и в классах, в обозначении актеров могут быть представлены

атрибуты актера и события, которые он может получать. Такие обо

значения не часто используются и редко отображаются на диаграм

мах прецедентов. Далее в этой книге они не упоминаются.

4.3.2.2. Время как актер

Если необходимо смоделировать чтото, происходящее с системой в оп

ределенный момент времени, но не инициируемое ни одним из акте

ров, можно ввести актера под названием Time (время) (рис. 4.4). В каче

стве примера приведем автоматическое сохранение резервной копии

системы, выполняемое ежедневно вечером.

4.3.3. Что такое прецеденты?

В книге «UML Reference Manual» [Rumbaugh 1] прецедент определен

как «Описание последовательности действий, включая альтернативные

и ошибочные последовательности, которые система, подсистема или

класс могут осуществлять, взаимодействуя с внешними актерами».

Прецедент описывает поведение, демонстрируемое системой с целью

получения значимого результата для одного или более актеров.

Прецедент – это чтото, что должна делать система по желанию акте

ра. Это «вариант использования» системы конкретным актером:

• прецеденты всегда инициируются актером;

• прецеденты всегда описываются с точки зрения актеров.

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

определению они могут применяться также и для описания «варианта

использования» подсистемы (части системы) или даже отдельного

класса. Прецеденты также могут быть очень эффективными при моде

лировании бизнеспроцессов, хотя данный вопрос не рассматривается

в этой книге.

На рис. 4.5 показана пиктограмма UML для прецедентов. Имя преце

дента может быть написано внутри овала или под ним.

Time

Рис. 4.4. Актер Time

4.3. Деятельность UP: Выявление актеров и прецедентов 97

4.3.3.1. Идентификация прецедентов

Чтобы найти прецедент, надо спросить: «Как каждый из актеров ис

пользует систему?» и «Что система делает для каждого актера?»

Идентификацию прецедентов лучше всего начать со списка актеров,

а затем рассмотреть, как каждый актер собирается использовать сис

тему. С помощью такой стратегии можно получить список потенци

альных прецедентов. Каждому прецеденту должно быть присвоено ко

роткое описательное имя, представляющее собой глагольную группу

(в конце концов, прецедент означает «выполнить» чтонибудь!).

Во время идентификации прецедентов могут обнаружиться некоторые

новые актеры. Это нормально. Иногда приходится очень тщательно

анализировать функциональность системы, чтобы выявить всех акте

ров, причем правильно выявить.

Моделирование прецедентов – итеративный процесс, осуществляемый

путем поэтапного уточнения. Все начинается с имени прецедента,

а детали дополняются позже. Эти детали состоят из исходного кратко

го описания, которое уточняется до полной спецификации. Ниже при

водится полезный список вопросов, которые можно задавать при иден

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

• Какие функциональные возможности понадобятся конкретному

актеру от системы?

• Система сохраняет и извлекает информацию? Если да, какой из ак

теров инициирует это поведение?

• Что происходит, когда система изменяет состояние (например, при

запуске и выключении системы)? Ктонибудь из актеров получает

при этом уведомление?

• Какиелибо внешние события оказывают влияние на систему? Как

система узнает об этих событиях?

• Система взаимодействует с какойлибо внешней системой?

• Система генерирует какиелибо отчеты?

4.3.3.2. Диаграмма прецедентов

На диаграмме прецедентов контекст модели прецедентов изображает

ся в виде блока с именем контекста. Этот блок является контекстом и,

как упоминалось в разделе 4.3.1, он представляет границу системы,

GetStatus

OnOrder

PlaceOrder

Рис. 4.5. Пиктограмма прецедента

98 Глава 4. Моделирование прецедентов

моделируемую прецедентами. Актеры располагаются вне контекста

(они внешние по отношению к системе), а прецеденты, составляющие

поведение системы, располагаются внутри контекста (они внутренние

по отношению к системе). Это проиллюстрировано на рис. 4.6.

Отношение между актером и прецедентом обозначается сплошной лини

ей. Это символ ассоциации в UML. Ассоциациям посвящена глава 9. Ас

социация между актером и прецедентом показывает, что актер и преце

дент какимто образом взаимодействуют.

4.3.4. Глоссарий проекта

В глоссариий проекта должна быть отражена бизнестерминология

и жаргон.

Глоссарий проекта – возможно, один из самых важных артефактов

проекта. Любая область деятельности имеет собственный уникальный

язык, и основной целью процесса выработки и анализа требований яв

ляется понимание и фиксация этого языка. Глоссарий обеспечивает

словарь ключевых деловых терминов и определений. Он должен быть

понятен всем участникам проекта, включая все заинтересованные сто

роны.

Кроме определения ключевых терминов глоссарий проекта должен

включать синонимы и омонимы.

• Синонимы – это разные слова, обозначающие одно и то же. ОО ана

литик должен выбрать и придерживаться одного из этих слов (того,

которое имеет наиболее широкое применение). Остальные вариан

Mail order system

PlaceOrder

Customer

CancelOrder

RequestCatalog

CheckOrderStatus

ShipProduct

ShippingCompany

Dispatcher

актер

отношение

взаимодействия

имя контекста системы

граница системы

прецедент

Рис. 4.6. Диаграмма прецедентов

4.3. Деятельность UP: Выявление актеров и прецедентов 99

ты должны быть полностью исключены из моделей. Это обусловле

но тем, что разрешение на применение синонимов может привести

к возникновению двух более или менее одинаковых классов с раз

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

ление всех синонимов, можно с уверенностью ожидать, что семан

тика терминов со временем будет отличаться.

• Омонимы – это слова, одинаковые по звучанию, но разные по значе

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

ку разные стороны говорят на разных языках, но при этом уверены,

что говорят об одном и том же. Способ решения – выбрать одно зна

чение для определенного термина, а для других омонимов, возмож

но, ввести новые термины.

В глоссарии проекта должен быть указан предпочтительный термин

и под его определением перечислены все синонимы. При этом, вероят

но, некоторым деловым партнерам придется привыкать к другой тер

минологии. Обычно тяжело заставить заинтересованные стороны из

менить используемый ими язык, но при некоторой настойчивости это

го удается добиться.

UML не устанавливает какихлибо стандартов для глоссария проекта.

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

Можно применять формат словаря с сортировкой слов и выражений по

алфавиту. Возможно, будет достаточно простого текстового докумен

та, но для больших проектов может потребоваться сетевой глоссарий

в формате HTML/XML или даже в виде несложной базы данных. За

помните, что чем глоссарий понятней и проще в использовании, тем

сильнее его положительное влияние на проект.

Часть примера глоссария проекта приведена в табл. 4.1. Если у слова

нет синонимов или омонимов, это явно указывается словом «нет» (поле

не оставляется пустым). Такой прием подчеркивает, что данный вопрос

был рассмотрен. Это придает глоссарию хороший стиль.

Термины и определения глоссария проекта также будут использовать

ся в модели UML. Необходимо гарантировать, что эти два документа

синхронизированы. К сожалению, большинство инструментальных

средств моделирования UML не обеспечивают какойлибо поддержки

синхронизации модели UML и глоссария, поэтому подобная синхро

низация обычно выполняется вручную.

Таблица 4.1. Глоссарий проекта для Clear View Training ECP

(платформа для электронной торговли)

Термин Определение

Catalog Список всех продуктов, имеющихся в продаже в Clear

View Training в настоящее время.

Синонимы: нет

Омонимы: нет

100 Глава 4. Моделирование прецедентов

Таблица 4.1 (продолжение)

4.4. Деятельность UP: Детализация прецедента

После создания диаграммы прецедентов и выявления актеров и клю

чевых прецедентов приступают к точному определению каждого пре

цедента по очереди. Эту деятельность UP известна как Детализация пре

цедента (рис. 4.7).

Термин Определение

Checkout Электронный аналог реальной кассы супермаркета.

Место, где покупатели могут оплатить продукты, нахо

дящиеся в их корзине для покупок.

Синонимы: нет

Омонимы: нет

Clear View Training Компания с ограниченной ответственностью, специали

зирующаяся на продаже книг и CD.

Синонимы: CVT

Омонимы: нет

Credit card Карточка, например VISA или Mastercard, которая мо

жет использоваться для оплаты.

Синонимы: карточка

Омонимы: нет

Customer Сторона, покупающая продукты или сервисы у Clear

View Training.

Синонимы: нет

Омонимы: нет

Составитель спецификации

прецедентов

Детализация

прецедента

Модель прецедентов

[в общих чертах]

Глоссарий проекта

Прецедент

[детализированный]

Модель требований

Рис. 4.7. Деятельность UP: Детализация прецедента. Адаптировано с рис. 7.1

[Jacobson 1] с разрешения издательства Addison+Wesley

4.5. Спецификация прецедентов 101

Здесь важно отметить, что некоторые или все прецеденты можно опи

сывать по мере их выявления, не соблюдая строгой очередности. На

против, в книге всегда очень сложно представить параллельную дея

тельность, поскольку книга по природе своей линейна!

Итог этой деятельности – более детализированный прецедент. Сюда

входят, по крайней мере, имя прецедента и его спецификация.

4.5. Спецификация прецедентов

UMLстандарта для спецификации прецедента не существует. Однако

широко используется шаблон, приведенный на рис. 4.8. Есть и более

сложные шаблоны, но из собственного опыта мы знаем, что при моде

лировании прецедентов лучше всего придерживаться максимальной

простоты.

Выберите стандарт для спецификации прецедентов.

Важно, чтобы организация выбрала стандарт для спецификаций преце

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

таких стандартов в компании делает весь процесс моделирования преце

дентов излишне сложным. В рамках одного проекта возникает масса

разных форматов, уровней детализации или даже интерпретаций того,

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

стандарт для спецификаций прецедентов может помочь обеспечить ус

Прецедент: PaySalesTax

Главные актеры:

Time (Время)

Предусловия:

1. Конец налогового периода.

Постусловия:

1. Налоговое управление получает соответствующую сумму Налога с оборота.

Основной поток:

1. Прецедент начинается в конце налогового периода.

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

Налоговому управлению.

3. Система посылает электронный платеж в Налоговое управление.

имя прецедента

актеры, вовлеченные

в прецедент

состояние системы

до начала прецедента

фактические этапы

прецедента

состояние системы после

окончания прецедента

Альтернативные потоки:

Нет.

альтернативные потоки

ID: 1

идентификатор прецедента

Краткое описание:

Выплата налога с оборота в Налоговое управление по окончанию налогового периода.

краткое описание

неявный актер Time

Второстепенные актеры:

TaxAuthority (налоговое управление)

Рис. 4.8. Шаблон спецификации прецедента

102 Глава 4. Моделирование прецедентов

пешный анализ прецедентов. В этой и следующей главах мы предлагаем

такой стандарт.

В наш шаблон простой спецификации прецедента входит следующая

информация:

• имя прецедента;

• ID прецедента;

• краткое описание – абзац, в котором изложена цель прецедента;

• актеры, задействованные в прецеденте;

• предусловия – условия, которые должны выполниться, чтобы пре

цедент мог осуществиться; это ограничения на состояние системы;

• основной поток – шаги выполнения прецедента;

• постусловия – условия, которые должны выполниться по оконча

нию прецедента;

• альтернативные потоки – список альтернативных основному пото

ку событий.

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

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

Прецедент, представленный на рис. 4.8, касается выплаты Налога с обо

рота – формы налога, взимаемого с продаж во многих странах. В дан

ном примере Налоговое управление в любом случае тем или иным об

разом получает соответствующую сумму налога. Поэтому факт полу

чения денег здесь заявлен как постусловие прецедента.

Записывайте прецеденты на структурированном естественном языке.

Хороший способ записи прецедента – «структурированный англий

ский» (или русский, или любой другой язык, являющийся для вас род

ным). В следующих разделах будет представлен простой стиль, кото

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

4.5.1. Имя прецедента

Не существует UMLстандарта по присваиванию имен прецедентам.

Мы всегда записываем имена прецедентов в стиле UpperCamelCase: от

дельные слова имени прецедента записываются слитно, каждое слово

начинается с заглавной буквы.

Прецеденты описывают поведение системы, поэтому имя прецедента

всегда должно быть глаголом или глагольной группой, например Pay

SalesTax (выплата налога с оборота). Всегда надо стремиться выбрать

имя, короткое и описательное одновременно. Человек, работающий

с моделью прецедентов, должен по одному его имени четко понимать

назначение моделируемой бизнесфункции или процесса. В этой и сле

дующих главах можно найти множество примеров имен прецедентов.