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

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 19)

В 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. Время как актерЕсли необходимо смоделировать чтото, происходящее с системой в определенный момент времени, но не инициируемое ни одним из актеров, можно ввести актера под названием 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. Диаграмма прецедентовНа диаграмме прецедентов контекст модели прецедентов изображается в виде блока с именем контекста.

Характеристики

Список файлов книги