Материал: 695_Poletajkin_A.N._Uchebno-metodicheskoe_posobie_Realizatsija_zhiznennogo_ch.1_

Внимание! Если размещение файла нарушает Ваши авторские права, то обязательно сообщите нам

концептуальной модели исходной бизнес-системы к логической модели ИС, а затем и к физической модели соответствующей программного приложения. К базовым моделям UML относятся модель прецедентов (требований) и модель классов (объектную модель).

3.2. Модель вариантов использования

Модель прецедентов (модель требований, модель вариантов использования) – это диаграмма UML, на которой изображаются отношения между актерами и вариантами использования. Это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:

определение общих границ и контекста моделируемой предметной области на начальных этапах проектирования ИС;

формальное представление требований к функциональному поведению (функциональных требований) проектируемой ИС;

разработка исходной концептуальной модели системы для ее последующей детализации в форме логических и физических моделей в нотации UML;

модельное обеспечение командной разработки ИС при помощи специальных программных средств управления жизненным циклом ИС;

подготовка исходной документации для взаимодействия

разработчиков системы с ее заказчиками и пользователями.

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

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

Рассматривая диаграмму вариантов использования в качестве модели бизнес-системы, можно ассоциировать ее с "черным ящиком" (см. рис. 2). Концептуальный характер этой диаграммы проявляется в том, что подробная детализация диаграммы или включение в нее элементов физического уровня представления на начальном этапе проектирования скорее имеет

21

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

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

Вариант использования (use case) – внешняя спецификация последовательности действий, которые система или другая сущность могут выполнять в процессе взаимодействия с актерами, представляет собой спецификацию общих особенностей поведения или функционирования моделируемой системы без рассмотрения ее внутренней структуры.

Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме глагольного существительного (рис. 3, а) или глагола (рис. 3, б) с пояснительными словами. Сам текст имени прецедента должен начинаться с заглавной буквы.

Имя (name) – строка текста, которая используется для идентификации любого элемента модели.

а) глагольное существительное

б) глагол

в) актер

Рис. 3. Графическое обозначение варианта использования и актера

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

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

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

22

Стандартным графическим обозначением актера на диаграммах является фигурка человечка, под которой записывается имя актера (рис. 3, в).

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

3.3. Отношения на диаграмме вариантов использования.

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

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

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

23

которая может иметь дополнительные обозначения, например, имя и кратность

(рис. 4, а).

а) отношение ассоциации

б) отношение включения

в) отношение расширения

г) отношение обобщения

Рис. 4. Пример графического представления отношений на диаграмме вариантом использования

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

Включение (include) в языке UML – это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) неизбежно приводит к изменению другого элемента (зависимого).

Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве обязательного составного фрагмента в последовательность поведения другого варианта использования. Данное отношение является направленным бинарным отношением в том смысле, что пара экземпляров вариантов использования всегда упорядочена в этом отношении.

Так, например, отношение включения, направленное от варианта использования "Предоставление кредита в банке" к варианту использования "Проверка платежеспособности клиента", указывает на то, что каждый экземпляр первого (базового) прецедента всегда включает в себя функциональное поведение или выполнение второго (включаемого) прецедента, то есть поведение второго прецедента является частью поведения первого прецедента на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового прецедента к включаемому, при этом данная линия помечается стереотипом <<include>>, как показано на рис. 4, б. Семантика этого отношения определяется следующим образом. Процесс выполнения базового варианта использования включает в себя как собственное

24

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

Один вариант использования может входить в несколько других прецедентов, а также включать в себя другие прецеденты. Включаемый вариант использования является независимым от базового прецедента в том смысле, что он предоставляет последнему инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми прецедентами. Более того, базовый вариант использования зависит только от результатов выполнения включаемого в него варианта использования, но не от структуры включаемых в него прецедентов.

Расширение (extend) определяет взаимосвязь базового прецедента с другим прецедентом, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.

В языке UML отношение расширения устанавливается только между вариантами использования, и является зависимостью, направленной к базовому прецеденту и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от прецедента, который является расширением для базового прецедента, и помеченная стереотипом <<extend>>, как показано на рис. 4, в. В изображенном фрагменте имеет место отношение расширения между базовым прецедентом "Предоставление кредита в банке" и прецедентом "Предоставление налоговых льгот". Это означает, что свойства поведения первого прецедента в некоторых случаях могут быть дополнены функциональностью второго прецедента, для чего должно быть выполнено определенное логическое условие данного отношения расширения.

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

Семантика отношения расширения определяется следующим образом. Если базовый прецедент выполняет некоторую последовательность действий, которая определяет его поведение, и при этом имеется точка расширения на экземпляр другого прецедента, которая является первой из всех точек расширения у базового прецедента, то проверяется логическое условие данного

25