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

Время как актерЕсли необходимо смоделировать чтото, происходящее с системой в определенный момент времени, но не инициируемое ни одним из актеров, можно ввести актера под названием Time (время) (рис. 4.4). В качестве примера приведем автоматическое сохранение резервной копиисистемы, выполняемое ежедневно вечером.TimeРис.

4.4. Актер Time4.3.3. Что такое прецеденты?В книге «UML Reference Manual» [Rumbaugh 1] прецедент определенкак «Описание последовательности действий, включая альтернативныеи ошибочные последовательности, которые система, подсистема иликласс могут осуществлять, взаимодействуя с внешними актерами».Прецедент описывает поведение, демонстрируемое системой с цельюполучения значимого результата для одного или более актеров.Прецедент – это чтото, что должна делать система по желанию актера.

Это «вариант использования» системы конкретным актером:•прецеденты всегда инициируются актером;•прецеденты всегда описываются с точки зрения актеров.Обычно прецеденты рассматриваются на уровне системы, но согласноопределению они могут применяться также и для описания «вариантаиспользования» подсистемы (части системы) или даже отдельногокласса. Прецеденты также могут быть очень эффективными при моделировании бизнеспроцессов, хотя данный вопрос не рассматриваетсяв этой книге.На рис.

4.5 показана пиктограмма UML для прецедентов. Имя прецедента может быть написано внутри овала или под ним.4.3. Деятельность UP: Выявление актеров и прецедентовPlaceOrder97GetStatusOnOrderРис. 4.5. Пиктограмма прецедента4.3.3.1. Идентификация прецедентовЧтобы найти прецедент, надо спросить: «Как каждый из актеров использует систему?» и «Что система делает для каждого актера?»Идентификацию прецедентов лучше всего начать со списка актеров,а затем рассмотреть, как каждый актер собирается использовать систему. С помощью такой стратегии можно получить список потенциальных прецедентов.

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

Ниже приводится полезный список вопросов, которые можно задавать при идентификации прецедентов.•Какие функциональные возможности понадобятся конкретномуактеру от системы?•Система сохраняет и извлекает информацию? Если да, какой из актеров инициирует это поведение?•Что происходит, когда система изменяет состояние (например, призапуске и выключении системы)? Ктонибудь из актеров получаетпри этом уведомление?•Какиелибо внешние события оказывают влияние на систему? Каксистема узнает об этих событиях?•Система взаимодействует с какойлибо внешней системой?•Система генерирует какиелибо отчеты?4.3.3.2.

Диаграмма прецедентовНа диаграмме прецедентов контекст модели прецедентов изображается в виде блока с именем контекста. Этот блок является контекстом и,как упоминалось в разделе 4.3.1, он представляет границу системы,98Глава 4. Моделирование прецедентовмоделируемую прецедентами. Актеры располагаются вне контекста(они внешние по отношению к системе), а прецеденты, составляющиеповедение системы, располагаются внутри контекста (они внутренниепо отношению к системе).

Это проиллюстрировано на рис. 4.6.Отношение между актером и прецедентом обозначается сплошной линией. Это символ ассоциации в UML. Ассоциациям посвящена глава 9. Ассоциация между актером и прецедентом показывает, что актер и прецедент какимто образом взаимодействуют.имя контекста системыMail order systemграница системыотношениевзаимодействияPlaceOrderCancelOrderShipProductShippingCompanyCustomerCheckOrderStatusпрецедентактерRequestCatalogDispatcherРис.

4.6. Диаграмма прецедентов4.3.4. Глоссарий проектаВ глоссариий проекта должна быть отражена бизнестерминологияи жаргон.Глоссарий проекта – возможно, один из самых важных артефактовпроекта. Любая область деятельности имеет собственный уникальныйязык, и основной целью процесса выработки и анализа требований является понимание и фиксация этого языка. Глоссарий обеспечиваетсловарь ключевых деловых терминов и определений.

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

Остальные вариан4.3. Деятельность UP: Выявление актеров и прецедентов99ты должны быть полностью исключены из моделей. Это обусловлено тем, что разрешение на применение синонимов может привестик возникновению двух более или менее одинаковых классов с разными именами. Кроме того, если позволить эпизодическое употребление всех синонимов, можно с уверенностью ожидать, что семантика терминов со временем будет отличаться.•Омонимы – это слова, одинаковые по звучанию, но разные по значению.

В этом случае всегда возникают проблемы общения, поскольку разные стороны говорят на разных языках, но при этом уверены,что говорят об одном и том же. Способ решения – выбрать одно значение для определенного термина, а для других омонимов, возможно, ввести новые термины.В глоссарии проекта должен быть указан предпочтительный термини под его определением перечислены все синонимы. При этом, вероятно, некоторым деловым партнерам придется привыкать к другой терминологии. Обычно тяжело заставить заинтересованные стороны изменить используемый ими язык, но при некоторой настойчивости этого удается добиться.UML не устанавливает какихлибо стандартов для глоссария проекта.Лучше всего, если глоссарий будет максимально простым и кратким.Можно применять формат словаря с сортировкой слов и выражений поалфавиту.

Возможно, будет достаточно простого текстового документа, но для больших проектов может потребоваться сетевой глоссарийв формате HTML/XML или даже в виде несложной базы данных. Запомните, что чем глоссарий понятней и проще в использовании, темсильнее его положительное влияние на проект.Часть примера глоссария проекта приведена в табл. 4.1. Если у слованет синонимов или омонимов, это явно указывается словом «нет» (полене оставляется пустым). Такой прием подчеркивает, что данный вопросбыл рассмотрен. Это придает глоссарию хороший стиль.Термины и определения глоссария проекта также будут использоваться в модели UML.

Необходимо гарантировать, что эти два документасинхронизированы. К сожалению, большинство инструментальныхсредств моделирования UML не обеспечивают какойлибо поддержкисинхронизации модели UML и глоссария, поэтому подобная синхронизация обычно выполняется вручную.Таблица 4.1. Глоссарий проекта для Clear View Training ECP(платформа для электронной торговли)ТерминОпределениеCatalogСписок всех продуктов, имеющихся в продаже в ClearView Training в настоящее время.Синонимы: нетОмонимы: нет100Глава 4.

Моделирование прецедентовТаблица 4.1 (продолжение)ТерминОпределениеCheckoutЭлектронный аналог реальной кассы супермаркета.Место, где покупатели могут оплатить продукты, находящиеся в их корзине для покупок.Синонимы: нетОмонимы: нетClear View Training Компания с ограниченной ответственностью, специализирующаяся на продаже книг и CD.Синонимы: CVTОмонимы: нетCredit cardКарточка, например VISA или Mastercard, которая может использоваться для оплаты.Синонимы: карточкаОмонимы: нетCustomerСторона, покупающая продукты или сервисы у ClearView Training.Синонимы: нетОмонимы: нет4.4.

Деятельность UP: Детализация прецедентаПосле создания диаграммы прецедентов и выявления актеров и ключевых прецедентов приступают к точному определению каждого прецедента по очереди. Эту деятельность UP известна как Детализация прецедента (рис. 4.7).Модель прецедентов[в общих чертах]Составитель спецификациипрецедентовМодель требованийДетализацияпрецедентаПрецедент[детализированный]Глоссарий проектаРис. 4.7. Деятельность UP: Детализация прецедента. Адаптировано с рис. 7.1[Jacobson 1] с разрешения издательства Addison+Wesley1014.5. Спецификация прецедентовЗдесь важно отметить, что некоторые или все прецеденты можно описывать по мере их выявления, не соблюдая строгой очередности.