Что такое сценарий uml

Диаграмма прецедентов (вариантов использования или Use Case)

Используемые материалы:

Диаграмма прецедентов (простенько, но не полно)
Более полное описание
Конспект лекции (с видео) от WorldSkills

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

Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между акторами и вариантами использования (прецедентами).

Актор это калька с английского Actor что расшифровывается как действующее лицо (Act — действие, суффикс -or — человек, осуществляющий действие)

Диаграмма вариантов использования — это исходное концептуальное представление или концептуальная модель системы в процессе ее проектирования и разработки. Создание диаграммы вариантов использования имеет следующие цели:

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

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

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

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

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

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

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

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

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

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

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

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

Актор (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.

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

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

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

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

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

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

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

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

В языке UML имеется несколько стандартных видов отношений между акторами и вариантами использования:

ассоциации (association relationship)
включения (include relationship)
расширения (extend relationship)
обобщения (generalization relationship)

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

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

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

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

Так, например, отношение включения, направленное от варианта использования «Предоставление кредита в банке» к варианту использования «Проверка платежеспособности клиента», указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия помечается стереотипом «include».

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

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

В нашем случае прецедент «оплатить заказ» на входе получает список товаров (причем не важно откуда, от клиента в магазине или от онлайн-покупателя на сайте).

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

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

В нашем случае, при оплате в магазине доступны оба расширения, а при оплате на сайте только оплата картой (на самом деле второй вариант сложнее: нужно выделить отдельный прецедент «онлайн оплата» с расширениями «оплата картой», «оплата при получении» и т.п.)

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

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

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

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

Разбор скринкаста семинара «Системный анализ и проектирование»

Текст задания:

Пользователь устанавливает приложение и регистрируется, указав ФИО и лицевой счёт, пароль. Так же пользователь может прикрепить данные банковской карты для быстрой оплаты, но не обязательно.

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

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

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

В Visio создаёте новый документ и открываете Дополнительные фигуры -> Программы и базы данных -> Программное обеспечение -> Сценарии выполнения UML

Цвет моих диаграмм отличается от сделанных в Visio, т.к. я делаю в visual-paradigm онлайн

Порядок работы:

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

Рисуем прямоугольник подсистемы:
Определяем акторов

В нашей системе это обычный пользователь и авторизованный пользователь. Рисуем их рядом с нашей подсистемой, причём учитываем, что авторизованный пользователь наследует (обобщает) свойства обычного пользователя (может прикрепить карту) и рисуем связь «обобщение»:
Определение вариантов использования

Обратите внимание: связи между акторами и прецедентами прямые и рисуются без всяких стрелок
- установка приложения — такой вариант использования есть в описании предметной области, но т.к. он не относится к подсистеме, то его рисуем за пределами подсистемы
- у обычного пользователя есть только один вариант использования: регистрация
  
  Но при регистрации возникают дополнительные действия (прецеденты): ввод ФИО, лицевого счёта и пароля, и не обязательный ввод данных карты.
  
  Для обязательных прецедентов используется отношение включения, для не обязательных — расширения
- оплата услуг авторизованным пользователем. Причём пользователь должен внести показания прибора учета. И может запросить отчет с возможным выбором периода
  
  После ввода показаний прибора учёта пользователь должен подтвердить оплату (обязательное действие, поэтому делаем включение). Если карта не была привязана в личном кабинете, то добавляем через включение действие ввод данных карты. Visio не полностью реализует стандарт UML — для альтернативных действий там есть специальные формы прецедентов. Но можно альтернативность прецедента акцентировать надписью на стрелке (тип ассоциации и так понятен по направлению стрелки)
  
  После подтверждения оплаты система генерирует квитанцию (делает это всегда, поэтому включение). Действия пользователя в этом случае не описаны, но т.к. сказано, что система не хранит квитанции, то напрашивается расширение для сохранения квитанции
- после всего вспомнили, что обычному пользователю для превращения в авторизованного нужно авторизоваться и, хотя этого нет в описании предметной области, добавляем этот прецедент:

Итоговый вариант диаграммы прецедентов:

Задание для самостоятельной работы:

Программа для фитнес-центра по распределению фитнес – расписания и контроля его соблюдения

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

Клиенты могут зарегистрироваться в системе, указав ФИО, телефон, пароль, дату рождения, фото профиля, пол.

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

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

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

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

Тренер также может посмотреть список своих текущих клиентов с указанием у каждого: проценты выполнения всего цикла тренировок (зависит от длительности цикла) и процента выполненных упражнений (т.к. некоторые упражнения могут быть пропущены). По каждому клиенту выводится средний показатель пульса во время выполнения упражнений.

Источник

Диаграммы прецедентов и их нотация

Что ж, у нас есть пример диаграммы. Итак, какие же элементы мы на ней видим? Первое, что бросается в глаза, — большой прямоугольник, внутри которого размещаются эллипсы, обозначающие, как мы уже поняли, прецеденты. В верхней части прямоугольника указано название моделируемой системы, а называют его рамками системы (system boundary, subject boundary), контекстом или просто системой. Этот элемент диаграммы показывает границу между тем, что вы как аналитик показали в виде прецедентов (внутри этих рамок), и тем, что вы изобразили как действующие лица (вне их). Чаще всего таким прямоугольником показывают границы самой моделируемой системы. То есть внутри границы находятся прецеденты — тот функционал, который реализует система (и в этом смысле прецеденты могут рассматриваться как представления подсистем и классов модели), а снаружи — действующие лица: пользователи и другие внешние сущности, взаимодействующие с моделируемой системой.

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

Кроме рамок системы или ее контекста на диаграмме мы видим еще два вида связанных с ней сущностей — это действующие лица (экторы, actors) и прецеденты. Начнем с экторов. Довольно часто в русскоязычной литературе по UML для обозначения действующих лиц можно встретить термин «актер«. В принципе, смысл его более-менее понятен и оригинальному английскому термину он созвучен. Более того, есть еще одна причина такого перевода. Какое слово первым приходит к вам в голову, когда вы слышите слово «актер«? Да, конечно же — слово «роль»! Именно о ролях мы вскоре и поговорим, когда будем пытаться разобраться, что скрывается за понятием «действующее лицо». А пока, да простит нас читатель, далее мы все же будем пользоваться словом «эктор» — транскрипцией оригинального термина. Помнится, мы уже как-то писали о нашем отношении к буквальному переводу терминологии…

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

Возможно, слова «роли, исполняемые пользователем» в определении эктора звучат не очень понятно. Очень забавно это понятие объясняется в Zicom Mentor:

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

Действительно, наденьте шляпу пирата — и вы капитан Джек Воробей, а наденьте цилиндр и вы — Джек-потрошитель! Шутка… «Физический» пользователь может играть роль одного или даже нескольких экторов, выполняя их функции в ходе взаимодействия с системой. И наоборот, роль одного и того же эктора может выполняться несколькими пользователями.

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

Рис.
6.4.

Несмотря на «человеческий» вид этого обозначения, не следует забывать, что экторы — это не обязательно люди. Эктором, как мы уже говорили ранее, может быть внешняя система, подсистема, класс и т. д. Кстати, человечек ( «stick-person» ) — это не единственное обозначение эктора, используемое в UML. На диаграммах прецедентов обычно применяется именно «человекоподобная» форма эктора, но на других диаграммах, и особенно в случаях, когда эктор имеет атрибуты, которые важно показать, используется изображение эктора как класса со стереотипом <<actor>> (рис. 6.5):

Рис.
6.5.

С системой экторы, как мы уже сказали, общаются через сообщения, но если говорить на более высоком уровне абстракции, в терминах модели прецедентов, то взаимодействуют они с системой через прецеденты. Один и тот же эктор может быть связан с несколькими прецедентами, и наоборот, один прецедент может быть связан с несколькими разными экторами. Ассоциации между эктором и прецедентом всегда бинарные — т. е. представляют отношения типа «один к одному», использование кратности недопустимо. Это не противоречит сказанному выше: действительно, один эктор может быть связан с несколькими прецедентами, но только с помощью отдельных ассоциаций — по одной на каждый прецедент. Мы видели это в нашем примере. Кстати, там мы видели ассоциации, изображенные не просто в виде линий, а стрелками. Думаем, смысл этого обозначения вполне понятен: это направленная ассоциация и стрелка (как и на других диаграммах) всегда направлена в сторону той сущности, от которой что-то требуют, чьим сервисом пользуются и т. д.

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

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

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

Рис.
6.6.

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

Внимательный читатель, возможно, отметил то, как незаметно мы ввели в употребление слово » сценарий «. Что же такое сценарий и как понятие сценария связано с понятием прецедента? На первый вопрос хорошо отвечают классики (Г. Буч):

Сценарий — это конкретная последовательность действий, иллюстрирующая поведение.

Сценарий — это повествовательный рассказ о совершаемых эктором действиях, история, эпизод, происходящий в данных временных рамках и данном контексте взаимодействия. Сценарии (в различных формах представления) широко применяются в процессе разработки программного обеспечения. Как мы уже только что отметили, написание сценария напоминает написание художественного рассказа, и этим объясняется тот факт, что использование сценариев широко распространено среди аналитиков, которые часто обладают художественными или литературными способностями. Несмотря на непрерывный повествовательный характер, сценарии можно рассматривать как последовательности действий (делать раскадровку ). При разработке пользовательского интерфейса сценарии описывают взаимодействие между пользователем (или категорией пользователей, например, администраторами системы, конечными пользователями) и системой. Такой сценарий состоит из последовательного описания комбинаций отдельных действий и задач (например, нажатий клавиш, щелчков по элементам управления, ввода данных в соответствующие поля и т. д.). Вспомните, к примеру, описания последовательностей действий пользователя (предназначенных для достижения определенных результатов, решения определенных задач), которые вы находите в справке к малознакомой программе. То же самое можно сказать о модных сейчас «how-to videos», в которых такие последовательности отображаются визуально, на конкретных примерах. В любом случае, цель подобных справочных материалов — предоставить описание типичных сценариев использования системы, сценариев взаимодействия между пользователем и системой.

Сценарии также иногда можно увидеть на диаграмме прецедентов. Иногда их изображают в виде » листа бумаги «, на котором написано имя файла, — прямоугольника с загнутым нижним левым уголком. В этом случае указанный файл содержит в себе описание данного сценария. А иногда сценарий записывается в комментарий. Как вы, наверное, помните, комментарии (ноутсы, notes) изображаются прямоугольниками с загнутым верхним правым углом и соединяются с элементом, который они поясняют, пунктирной линией (рис. 6.7).

Рис.
6.7.

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

Вот пример простого (неформализованного) текстового описания сценария.

Пользователь вводит логин, пароль, адрес электронной почты и код подтверждения и нажимает кнопку «Далее». Система запрашивает ввод проверочного кода. Пользователь вводит код и нажимает кнопку «Далее». Система проверяет соответствие кода изображенному на картинке.

Не правда ли, знакомая процедура? Да, это описание регистрации пользователя на некотором сайте. Правда, не совсем полное: не рассмотрены случаи, когда выбранный пользователем логин уже занят, адрес электронной почты введен неправильно, пароль не удовлетворяет требованиям или код не соответствует изображенному на картинке. О таких случаях — альтернативных сценариях — мы поговорим чуть позже.

А вот тот же сценарий в табличном представлении:

Действия пользователя	Реакция системы
Ввод логина, пароля, адреса электронной почты и нажатие кнопки «Далее»	Запрос ввода проверочного кода
Ввод проверочного кода и нажатие кнопки «Далее»	Проверка кода на соответствие изображенному на картинке

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

А пока попробуем ответить на второй вопрос, а именно: как связаны понятия сценария и прецедента. Прецеденты, как мы уже говорили, рождаются из требований к системе. Но говорят они о том, что делает система. Как система это делает, говорят сценарии. Таким образом, прецедент можно специфицировать путем описания потока действий или событий в текстовой форме — в виде, понятном для «постороннего» (не занятого в непосредственной разработке системы) читателя. А ведь такое описание — это и есть сценарий! Таким образом, сценарии специфицируют прецеденты. И еще. Поскольку сценарии — это, по сути, рассказы, они являются весьма эффективным средством извлечения информации из бесед с заказчиком и предоставляют превосходное, понятное непрофессионалу описание создаваемого приложения. Сценарии, да и вообще диаграммы прецедентов (дополненные сценариями) являются отличным средством общения между разработчиками и заказчиком, причем, в силу простоты нотации, — средством, понятным обеим сторонам. В конечном итоге, взаимосвязь между требованиями, прецедентами и сценариями можно изобразить такой «псевдодиаграммой» (рис. 6.8).

Рис.
6.8.

Источник

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

Диаграмма
классов
(class diagram) — диаграмма языка UML, на
которой представлена совокупность
декларативных или статических
элементов модели, таких как классы
с атрибутами
и операциями,
а также связывающие их отношения.

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

Класс

Класс
(class) — абстрактное описание множества
однородных объектов, имеющих
одинаковые атрибуты,
операции
и отношения с объектами других
классов
.

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

Рис.
5.1.
Варианты графического изображения
класса на диаграмме классов

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

Даже
если секции атрибутов
и операций
пусты, в обозначении класса
они должны быть выделены горизонтальной
линией, с тем чтобы отличить класс
от других элементов языка UML. Примеры
графического изображения конкретных
классов
приведены на рис.
5.2.
В первом случае для класса
Окружность (рис.
5.2, а)
указаны только его атрибуты
– точка на координатной плоскости,
которая определяет расположение ее
центра. Для класса
Окно (рис.
5.2, б)
указаны только его операции,
при этом секция его атрибутов
оставлена пустой. Для класса
Счет (рис.
5.2, в)
дополнительно изображена четвертая
секция, в которой указано требование
– реализовать резервное копирование
объектов этого класса.

Рис.
5.2.
Примеры графического изображения
конкретных классов

Имя
класса

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

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

Класс
может иметь или не иметь экземпляров
или объектов. В зависимости от этого
в языке UML различают конкретные
и абстрактные
классы.

Конкретный
класс
(concrete class) — класс,
на основе которого могут быть
непосредственно созданы экземпляры
или объекты.

Рассмотренные
выше обозначения относятся к
конкретным
классам.
От них следует отличать абстрактные
классы.

Абстрактный
класс
(abstract class) — класс,
который не имеет экземпляров или
объектов.

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

В
некоторых случаях необходимо явно
указать, к какому пакету относится
тот или иной класс.
Для этой цели используется специальный
символ разделитель – двойное
двоеточие — ( ::).
Синтаксис строки имени
класса
в этом случае будет следующий: <Имя
пакета>::< Имя
класса
>.
Другими словами, перед именем
класса
должно быть явно указано имя пакета,
к которому его следует отнести.
Например, если определен пакет с
именем Банк,
то класс
Счет
в этом банке может быть записан в
виде: Банк::Счет.

Атрибуты
класса

Атрибут
(attribute)
— содержательная характеристика
класса,
описывающая множество значений,
которые могут принимать отдельные
объекты этого класса
.

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

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

<квантор
видимости> <имя атрибута>
[кратность] :

<тип
атрибута> = <исходное значение>
{строка-свойство}.

Видимость
(visibility) — качественная характеристика
описания элементов класса,
характеризующая потенциальную
возможность других объектов модели
оказывать влияние на отдельные
аспекты поведения данного класса.

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

Символ
» +
» – обозначает атрибут
с областью видимости типа общедоступный
( public
). Атрибут
с этой областью видимости доступен
или виден из любого другого класса
пакета, в котором определена
диаграмма.
Символ
» #
» – обозначает атрибут
с областью видимости типа защищенный
( protected
). Атрибут
с этой областью видимости недоступен
или невиден для всех классов,
за исключением подклассов данного
класса.
Символ
» —
» – обозначает атрибут
с областью видимости типа закрытый
( private
). Атрибут
с этой областью видимости недоступен
или невиден для всех классов
без исключения.
И,
наконец, символ » ~
» — обозначает атрибут
с областью видимости типа пакетный
( package
). Атрибут
с этой областью видимости недоступен
или невиден для всех классов
за пределами пакета, в котором
определен класс
-владелец данного атрибута.

Квантор
видимости
может быть опущен. Его отсутствие
означает, что видимость атрибута
не указывается. Эта ситуация отличается
от принятых по умолчанию соглашений
в традиционных языках программирования,
когда отсутствие квантора
видимости
трактуется как public
или private.
Однако вместо условных графических
обозначений можно записывать
соответствующее ключевое слово:
public,
protected,
private,
package.

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

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

Кратность
атрибута
характеризует общее количество
конкретных атрибутов
данного типа, входящих в состав
отдельного класса.
В общем случае кратность
записывается в форме строки текста
из цифр в квадратных скобках после
имени соответствующего атрибута,
при этом цифры разделяются двумя
точками: [нижняя
граница .. верхняя граница],
где нижняя и верхняя границы
положительные целые числа. Каждая
такая пара служит для обозначения
отдельного замкнутого интервала
целых чисел, у которого нижняя
(верхняя) граница равна значению
нижней границы (верхней). В качестве
верхней границы может использоваться
специальный символ » *
» (звездочка), который означает
произвольное положительное целое
число, т.е. неограниченное сверху
значение кратности
соответствующего атрибута.

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

Если
в качестве кратности
указывается единственное число, то
кратность
атрибута
принимается равной данному числу.
Если же указывается единственный
знак » *
«, то это означает, что кратность
атрибута
может быть произвольным положительным
целым числом или нулем. В языке UML
кратность
широко используется также для задания
ролей ассоциаций, составных объектов
и значений атрибутов.
Если кратность
атрибута
не указана, то по умолчанию в языке
UML принимается ее значение равное
[1..1],
т.е. в точности 1.

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

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

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

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

Знак
» /
» перед именем атрибута
указывает на то, что данный атрибут
является производным от некоторого
другого атрибута
этого же класса.

Производный
атрибут
(derived element) — атрибут
класса,
значение которого для отдельных
объектов может быть вычислено
посредством значений других атрибутов
этого же объекта.

Операции
класса

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

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

<квантор
видимости> <имя операции>(

список
параметров):

<выражение
типа возвращаемого значения>

{строка-свойство}

Квантор
видимости,
как и в случае атрибутов
класса,
может принимать одно из четырех
возможных значений и, соответственно,
отображается при помощи специального
символа либо ключевого слова. Символ
» +
» обозначает операцию
с областью видимости типа общедоступный
( public
). Символ » #
» обозначает операцию
с областью видимости типа защищенный
( protected
). Символ » —
» используется для обозначения
операции
с областью видимости типа закрытый
( private
). И, наконец, символ » ~
» используется для обозначения
операции
с областью видимости типа пакетный
( package
).

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

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

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

<направление
параметра> <имя параметра>:

<выражение
типа> =

<значение
параметра по умолчанию>.

Параметр
(parameter)
— спецификация переменной операции,
которая может быть изменена, передана
или возвращена.

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

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

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

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

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

Расширение
языка UML для построения моделей
программного обеспечения и
бизнес-систем

Одним
из несомненных достоинств языка UML
является наличие механизмов
расширения, которые позволяют ввести
в рассмотрение дополнительные
графические обозначения, ориентированные
для решения задач из определенной
предметной области. Язык UML содержит
два специальных расширения: профиль
для процесса разработки программного
обеспечения (The UML Profile for Software
Development Processes) и профиль для
бизнес-моделирования (The UML Profile for
Business Modeling).

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

Управляющий
класс
(control class) — класс,
отвечающий за координацию действий
других классов.
На каждой диаграмме классов
должен быть хотя бы один управляющий
класс,
причем количество посылаемых
объектам управляющего класса
сообщений мало, по сравнению с числом
рассылаемых ими. Управляющий класс
отвечает за координацию действий
других классов.
У каждой диаграммы классов
должен быть хотя бы один управляющий
класс,
контролирующий последовательность
выполнения действий этого варианта
использования. Как правило, данный
класс
является активным и инициирует
рассылку множества сообщений другим
классам
модели. Кроме специального обозначения
управляющий класс
может быть изображен в форме
прямоугольника класса
со стереотипом <<control>>
(рис.
5.3, а).
Класс
-сущность (entity class) — пассивный класс,
информация о котором должна храниться
постоянно и не уничтожаться с
выключением системы. Класс
-сущность содержит информацию,
которая должна храниться постоянно
и не уничтожается с уничтожением
объектов данного класса
или прекращением работы моделируемой
системы, связанные с выключением
системы или завершением программы.
Как правило, этот класс
соответствует отдельной таблице
базы данных. В этом случае его
атрибуты
являются полями таблицы, а операции
– присоединенными или хранимыми
процедурами. Этот класс
пассивный и лишь принимает сообщения
от других классов
модели. Класс
-сущность может быть изображен также
стандартным образом в форме
прямоугольника класса
со стереотипом <<entity>>
(рис.
5.3, б).
Граничный
класс
(boundary class) — класс,
который располагается на границе
системы с внешней средой и
непосредственно взаимодействует
с актерами, но является составной
частью системы. Граничный класс
может быть изображен также стандартным
образом в форме прямоугольника
класса
со стереотипом <<boundary>>
(рис.
5.3, в).

Рис.
5.3.
Графическое изображение классов
для моделирования программного
обеспечения

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

Сотрудник
(business worker) — класс,
служащий на диаграмме классов
для представления любого сотрудника,
который является элементом
бизнес-системы и взаимодействует
с другими сотрудниками при реализации
бизнес-процесса. Этот класс
также может быть изображен в форме
прямоугольника класса
со стереотипом <<worker>>
или <<internalWorker>>
(рис.
5.4, а).
Сотрудник
для связи с окружением (caseworker) –
класс,
служащий для представления в
бизнес-системе такого сотрудника,
который, являясь элементом
бизнес-системы, непосредственно
взаимодействует с актерами
(бизнес-актерами) при реализации
бизнес-процесса. Этот класс
также может быть изображен в форме
прямоугольника класса
со стереотипом <<caseWorker>>
(рис.
5.4, б).
Бизнес-сущность
(business entity) — специальный случай
класса
-сущности, который также не инициирует
никаких сообщений. Этот класс
служит для сохранения информации
о результатах выполнения бизнес-процесса
в моделируемой бизнес-системе или
организации. Этот класс
также может быть изображен в форме
прямоугольника класса
со стереотипом <<business
entity>>
(рис.
5.4, в).

Рис.
5.4.
Графическое изображение классов
для моделирования бизнес-систем

Интерфейс

Интерфейс
(interface) — именованное множество
операций,
которые характеризуют поведение
отдельного элемента модели.

Интерфейс
в контексте языка UML является
специальным случаем класса,
у которого имеются операции,
но отсутствуют атрибуты.
Для обозначения интерфейса
используется специальный графический
символ окружность или стандартный
способ – прямоугольник класса
со стереотипом <<interface>>
(рис.
5.5).

На
диаграмме вариантов использования
интерфейс
изображается в виде маленького
круга, рядом с которым записывается
его имя (рис.
5.5, а).
В качестве имени может использоваться
существительное, которое характеризует
соответствующую информацию или
сервис, например, » Датчик
температуры
«, » Форма
ввода
«, » Сирена
«, » Видеокамера
» (рис.
5.5, б).
С учетом языка реализации модели
имя интерфейса,
как и имена
других классов,
рекомендуется записывать на английском
и начинать с заглавной буквы I,
например, ITemperatureSensor,
IsecureInformation
(рис.
5.5, в).

Рис.
5.5.
Примеры графического изображения
интерфейсов на диаграммах классов

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

Источник

Это первая статья из цикла про методологию ICONIX, посвящена UML-диаграммам вариантов использования. В публикациях и книгах по ICONIX, use-case диаграммы обычно описываются очень бегло, а в книгах по UML — слишком подробно. Я постараюсь сделать это настолько подробно, чтобы можно было приступить к использованию диаграмм, но при этом не было скучно. Важно, что до тех пор, до знакомства с ICONIX я не считал use-case диаграммы хоть сколько-нибудь полезными, поэтому в статье я попробую сконцентрироваться на том, что они могут принести проекту.

Вне зависимости от методологии разработки, которую вы применяете, первым этапом разработки будет являться формулировка требований к продукту (Градди Буч описывает Rational Unified Process [1], а Розенберг — ICONIX [2]). Набор требований к продукту представляет собой техническое задание, при этом требования делятся на функциональные (то, что система позволяет сделать, желаемая функциональность) и нефункциональные (требования к оборудованию, операционной системе и т.п.). В языке UML для формализации функциональных требований применяются диаграммы использования.

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

На диаграмме использования изображаются:

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

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

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

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

Рассмотрим разработку диаграмм вариантов использования на примере — пусть заказчик дал нам следующее техническое задание:

Цель — развитие у детей математических навыков.
Платформа: Linux, Windows, Android.
Функциональность:

для учеников:

выбор подготовленного учителем блока заданий;

выполнение заданий;

для учителя:

подготовка для учеников блоков заданий;

добавление в систему ученика;

просмотр отчетов.

При первом запуске система должна позволять ввести пароль учителя. Задания представляют собой математические задачи на сложение, вычитание, умножение и деление. В блоке задач могут быть задачи различных типов (указывается количество). Помимо ввода типа выполняемой в примере операции необходимо указывать допустимые диапазоны чисел (или даже отдельные числа, т.к. при изучении таблицы умножения часто сначала учат умножение на 2, затем на 5, а только потом все остальное). Кроме того, для операции вычитания необходимо иметь возможность установить вычитаемое меньше уменьшаемого (т.к. в противном случае результат будет отрицательным, а отрицательные числа в школе проходят гораздо позже).

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

Пример диаграммы использования

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

Название прецедента: регистрация ученика

Действующее лицо: учитель

Цель: добавить ученика в систему, получив его пароль

Предусловия: учитель осуществил вход в систему

Главная последовательность:

учитель выбирает в главном меню пункт «добавить ученика«;

система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;

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

учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

Альтернативная последовательность (возврат в главное меню без добавления ученика):

учитель выбирает в главном меню пункт «добавить ученика«;

система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

учитель нажимает кнопку «назад»;

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

Альтернативная последовательность (добавление ученика, уже имеющегося в системе):

учитель выбирает в главном меню пункт «добавить ученика«;

система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;

учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;

учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

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

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

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

Отношение включения на диаграмме использования

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

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

Таким образом можно показать, что у учителя появляется возможность (но не обязанность) удалить набор задач при просмотре отчетов если все ученики выполнили этот набор.

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

нефункциональные требования к системе (при этом используется стереотип <<requirement>>);
сценарии вариантов использования (связывая комментарий с соответствующим прецедентом);
детали реализации и другие выводы, к которым разработчики пришли в процессе обсуждения задачи (не все с этим согласны, т.к. use-case диаграмма показывается заказчику, которому не нужны детали).

Наиболее типичными ошибками при построении этого вида диаграмм являются:

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

Важно, что процесс ICONIX является итеративным, поэтому если вы допустите неточности на этапе разработке диаграмм использования — их можно будет найти и исправить на следующих этапах (в частности, пропущенные объекты могут быть выделены при работе над диаграммами робастности, а сценарии детально проработаны при построении диаграмм последовательности).

Стоит отметить, что нет единого мнения по поводу использования в текстах сценария условных операторов или циклов. Ряд аналитиков считают, что наличие слов типа «если» в сценарии является ошибкой, которая исправляется добавлением альтернативной последовательности. Другие — допускают использование 1-2 ветвлений в сценарии, при этом отмечают, что такой подход улучшает читабельность сценариев.

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

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

Буч Градди Объектно-ориентированный анализ и проектирование с примерами приложений, 3-е изд. / Буч Градди, Максимчук Роберт А., Энгл Майкл У., Янг Бобби Дж., Коналлен Джим, Хьюстон Келли А.: Пер с англ. – М.: ООО “И.Д. Вильямс”, 2010. – 720 с.
Розенберг Д., Скотт К. Применение объектного моделирования с использованием UML и анализ прецедентов.: Пер. с англ. М.: ДМК Пресс, 2002
Бабич А. В. Введение в UML // Интернет университет информационных технологий. 2008. URL: http://www.intuit.ru/studies/courses/1007/229/info (дата обращения: 19.03.2016).
Леоненков, A.B. Объектно-ориентированный анализ и проектирование с использованием UML и IBM Rational Rose: учеб. пособие Текст. / A.B. Леоненков. М.: Интернет-Ун-т информ. технологий: БИНОМ, Лаборатория знаний, 2006. — 320 с.

Источник

Диаграммы использования были предложены Иваром
Якобсоном в их нынешней графической форме еще в 1986 году. Диаграммы использования являются, безусловно,
самым стабильным элементом UML — они не менялись уже двадцать лет с лишним, фактически, приняли законченную
форму задолго до появления языка. Одновременно эти диаграммы имеют самую простую нотацию: всего два основных
типа сущностей (действующие лица и варианты использования) и три типа отношений (зависимости, ассоциации,
обобщения)!

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

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

Роль (role) в UML — это интерфейс (interface)^∇, поддерживаемый данным классификатором
(classifier) в данной ассоциации (assocation).

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

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

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

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

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

Опираясь на собственные советы, применительно к нашему примеру мы в первом приближении склонны выделить
две категории пользователей:

менеджер персонала, который работает с конкретными людьми;
менеджер штатного расписания, который работает с абстрактными должностями и подразделениями.

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

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

На следующем фрагменте диаграммы использования мы начинаем формировать представление использования
информационной системы отдела кадров. Менеджер персонала имеет имя Personnel Manager, а менеджер штатного расписания — Staff Manager, в
соответствии с используемой дисциплиной имен.

Рис. Действующие лица ИС ОК

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

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

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

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

Каждая конкретная последовательность действий называется сценарием (scenario).

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

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

В нашем примере простой анализ текста технического задания (приведенного в разделе
2.1.1) выявляет семь вариантов использования:

прием сотрудника;
перевод сотрудника;
увольнение сотрудника;
создание подразделения;
ликвидация подразделения;
создание вакансии;
сокращение должности;

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

Рис. Варианты использования ИС ОК

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

В отличие от большинства языков программирования комментарии в UML синтаксически оформлены с помощью
специальной нотации и выступают на тех же правах, что и остальные сущности^∇. А именно, комментарий имеет свою
графическую нотацию ‒ прямоугольник с загнутым уголком («собачье ухо»), в котором находится текст
комментария. Комментарии могут находиться в отношении соответствия с другими сущностями ‒ эти
отношения изображаются пунктирной линией без стрелок. Если пунктирная линия отсутствует, то комментарий
относится ко всей диаграмме.

Комментарий содержит текст, который вводит пользователь — создатель модели. Это может быть текст в
произвольном формате: на естественном языке, на языке программирования, на формальном логическом языке,
например, OCL и т. д. Более того, если возможности инструмента это позволяют, в примечаниях можно
хранить гиперссылки, вложенные файлы и другие артефакты, внешние по отношению к модели.

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

Комментарии могут иметь стереотипы. В UML определены два стандартных стереотипа для комментариев:

«requirement» — описывает общее требование к системе;
«responsibility» — описывает ответственность сущности (классификатора).

Комментарии первого стереотипа часто присутствуют на диаграммах использования, а комментарии второго
стереотипа — на диаграммах классов.

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

Рис. Нефункциональное требование к ИС ОК

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

ассоциация между действующим лицом и вариантом использования;
обобщение между действующими лицами;
обобщение между вариантами использования;
зависимости между вариантами использования;

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

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

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

Рис. Ассоциации между действующими лицами и вариантами использования

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

Такое обобщение является весьма мощным средством моделирования.

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

Рис. Иерархия категорий пользователей ИС ОК

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

Информационная система должна предоставлять возможность просматривать данные без внесения в них каких-либо изменений.

Данное требование следует оформить в виде дополнительного варианта использования ‒ Browse. Если мы проектируем систему отдела кадров для обычной организации, а не
для государственной секретной службы, то разумно предположить, что просматривать данные могут все
категории пользователей. В этом случае можно установить ассоциации между новым вариантом использования и
всеми действующими лицами, а можно поступить так, как показано следующем рисунке, т.е. ввести
обобщенного абстрактного пользователя User 1,
который будет связан ассоциацией с вариантом использования Browse 2. При этом все специализации 3 и
4 обобщенного пользователя автоматически будут связаны ассоциацией с
вариантом использования Browse.

Рис. Абстрактное действующее лицо

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

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

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

Система должна поддерживать два способа увольнения сотрудника: по инициативе администрации и по собственному желанию.

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

Рис. Обобщение вариантов использования

Обобщенный абстрактный (имя написано курсивом) вариант использования Fire Person имеет две специализации, которые соответствуют увольнению работника по собственному
желанию Self Fire и по инициативе администрации Adm Fire.

Зависимость между вариантами использования показывает, что один вариант
использования зависит от другого варианта использования.

В UML имеются два стандартных стереотипа зависимости между вариантами использования, которые в некотором
смысле двойственны друг другу:

«include» — показывает, что в каждый сценарий
зависимого варианта использования в определенном месте вставляется в качестве подпоследовательности
действий в сценарий независимого варианта использования.
«extend» — показывает, что в некоторый сценарий
независимого варианта использования может быть в определенном месте вставлен в
качестве подпоследовательности действий сценарий зависимого варианта использования. Другой вариант
интерпретации: в определенном месте сценария независимого варианта использования вызывается для
выполнения сценарий зависимого варианта использования. При этом последовательность действий в
вызываемом сценарии определяется местом, откуда он был вызван, т.е. из какого варианта использования
и конкретно из какого места какого сценария этого варианта использования.

На первый взгляд не очень понятно, чем отличается семантика этих зависимостей ‒ ведь обе они
отражают отношение включения для последовательностей действий. Нам будет удобнее объяснить тонкости
семантики этих отношений в параграфе 2.3.2, а здесь мы ограничимся
примерами.

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

Учетная запись сотрудника при увольнении должна быть заблокирована.

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

Рис. Зависимости между вариантами использования

Последний пример можно отобразить еще компактнее, комбинируя возможности отношений обобщения и
зависимости, подобно тому, как скомбинированы возможности отношений обобщения и ассоциации на рис. Абстрактное действующее лицо.

Рис. Комбинация отношений обобщения и зависимости

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

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

Обычно совершенно ясно, что находится внутри моделируемой системы, а что снаружи. Если это почему-либо
неясно, или же требуется увеличить наглядность диаграмм, то можно воспользоваться специальной
конструкцией, которая называется «границы системы».

Границы системы (system boundary) — это графический комментарий в форме
прямоугольной рамки, применяемый на диаграммах использования и отделяющий внутреннюю часть системы
от ее внешнего окружения.

Внутренняя часть, выделяемая границами, имеет в UML конкретное название ‒ субъект.

Субъект (subject) — это классификатор, который реализует поведение, декларируемое
вариантами использования.

Если границы системы используются на диаграмме, то можно указать имя (и стереотип!), которые будут
относиться к субъекту^∇.

На следующей диаграмме мы построили пример аналогичный представленному на рис. Ассоциации между действующими лицами и вариантами
использования, но использовали другие возможности нотации UML.

Рис. Границы системы

В приведенных примерах действующими лицами являются категории пользователей. Это не случайно, в
большинстве случаев действующими лицами в моделях UML действительно являются категории пользователей. Но
оборот «в большинстве случаев» еще не означает «всегда». В самом деле, в определениях действующего лица
(параграф 2.2.1) и варианта использования (параграф
2.2.2) ничто не указывает на ограничения в применении этих понятий. Выше мы отметили, что
варианты использования описывают внутренность системы, а действующие лица ‒ ее окружение. Так вот,
в качестве системы может выступать любая сущность, для которой можно определить функциональные
или не функциональные требования. Это может быть и подсистема главной системы, отдельный
компонент и просто класс. Если мы рассматриваем модель использования некоторой подсистемы, то другие
подсистемы (взаимодействующие с рассматриваемой) будут действующими лицами для рассматриваемой
подсистемы. Если мы рассматриваем модель использования некоторого класса, то другие классы
(взаимодействующие с рассматриваемым) будут действующими лицами для рассматриваемого класса.

Рассмотрим пример, связанный с взаимодействием нашей информационной системы отдела кадров с внешним
программным окружением.

ИЗМЕНЕНИЯ В ТЕХНИЧЕСКОМ ЗАДАНИИ

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

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

На следующей диаграмме действующее лицо ИС ОК ‒ это наша информационная
система отдела кадров, действующее лицо ERP ‒ некоторая другая
информационная система, а Adapter ‒ модуль с единственным вариантом
использования. Обратите внимание, что на этой диаграмме все сущности ‒ программные системы, никаких
пользователей здесь нет!

Рис. Программные системы в качестве действующих лиц

Источник

Сценарии использования, варианты использования или прецеденты (Use cases) — спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности) в UML, которые может осуществлять система, подсистема или класс, взаимодействуя с внешними действующими лицами (англ. Actors).

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

Степени детальности

Степень формализма выполняемого проекта и стадия, на которой он находится, прямо влияют на степень детальности и проработанности вариантов использования. Алистер Кокберн (Alistair Cockburn) определяет 3 степени детальности при написании вариантов использования:

Краткий (brief) вариант использования состоит (помимо названия) из одного-двух описательных предложений. Он хорош при сведении функциональных требований в таблицу при планировании приоритетности, технической сложности, номера версии продукта и т. д.
Бессистемный (casual) вариант использования является более подробным и объёмным описанием развития событий, но без какой-либо строгой предопределённой структуры изложения.
Детальный (detailed) вариант использования – это формальный документ с предопределённой структурой разделов; это, собственно, и есть Use case в его традиционном понимании.

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

Шаблон

Детальные варианты использования составляются по определенному шаблону. Таких конкурирующих шаблонов (схем) предложено несколько. В конкретном проекте можно, при необходимости, использовать собственную, наиболее подходящую схему. Типичная схема включает по меньшей мере следующие разделы:

Название (Name). Краткое, максимально понятное, в виде команды (что сделать).
Цель (Goal). Краткая (до нескольких предложений) характеристика задачи, которую должен в результате решить вариант использования.
Начальное состояние (Initial state). Формулировка условий, при которых данный вариант использования может быть инициирован. Условие, помимо прочего, может быть упоминанием о выполнении других вариантов использования.
Основной сценарий (Main scenario). Сценарий – это последовательность шагов, описывающая процесс решения задачи, которой посвящен вариант использования. Шаги удобно последовательно нумеровать.
Альтернативные сценарии, в которых процесс развития событий на каком-либо шаге чем-либо заметно отличается от основного, то есть имеет место ветвление.

Нотация

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

См. также

Пользовательские истории
Use-Case 2.0

Источник