Сценарий uml это

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

Диаграмма
классов
(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. 
Примеры графического изображения
интерфейсов на диаграммах классов

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

• Что такое диаграмма вариантов использования?

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

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

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

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

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

  • Укажите контекст системы
  • Зафиксируйте требования системы
  • Проверить архитектуру системы
  • Управляйте внедрением и создавайте тестовые примеры
  • Совместная разработка аналитиками, экспертами в предметной области и целевыми конечными пользователями

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  Актеры

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

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

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

  Люди против нечеловеческих актеров

  Время от времени на систему воздействуют различные события для выполнения определенных функций в той или иной ситуации. Например, при прохождении аудита система заранее отправляет письмо, чтобы уведомить людей; так отправка письма осуществляется системой автоматически? Этот вариант использования на самом деле запускается по времени, тогда действующим лицом является Таймер; например, этот вариант использования можно рассматривать как «автоматически отправлять письмо в 5:00 каждый день», тогда актор, который запускает это событие — отправку письма — не система, а на самом деле актор-таймер

  Первичные и второстепенные актеры

  A primary actor is an actor that uses the system to achieve a goal. Use cases document the interactions between the system and actors to achieve the goals of the primary actor. Secondary actors are the actors that the system needs to assist in order to achieve the goals of the primary actor.

  • Actors may be primary or secondary. Primary actors initiate interactions with the system.
  • Secondary actors are typically called upon by the system for help and a secondary actor never initiates the use case.

  Note that: The symbol for an actor does not differentiate between a primary actor and a secondary actor; the difference must be inferred from the use case descriptions (also called use case narratives).

  For Example:

  A bank loan officer wants to review a customer’s loan application, and part of the process involves a real-time credit rating check.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  • Используйте имя дела. Рассмотреть заявку на кредит
  • Главный актер. Кредитный специалист
  • Второстепенный актер. Система кредитного рейтинга

  Как определить актеров?

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

  • Кто будет использовать систему после ее разработки?
  • От кого или от каких других систем система должна будет получать данные?
  • Для кого или для каких других систем система будет предоставлять данные?
  • С какими другими системами будет связана система?
  • Кто будет поддерживать и администрировать систему?

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

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

  Вариант использования

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

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

  Как определить варианты использования?

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

  • Почему актеры используют систему?
  • Создает ли участник, изменяет, удаляет, получает доступ и хранит данные в системе? Если да, то как актор выполняет эти операции?
  • Уведомляет ли актор систему об определенных внешних событиях?
  • Уведомляет ли система актора об определенных внутренних событиях?

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

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

  Системная граница

  Границы системы описывают систему, группируя варианты использования в прямоугольные границы, а границы системы в Visual Paradigm обеспечивают поведение ограничения вариантов использования.

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

  Обратите внимание, что: 

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

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

  Отношение

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

  Вариант использования можно разбить на несколько вариантов использования, которые связаны отношениями <<включить>>, <<расширить>> или <<обобщить>> (описано далее в этом посте).

  Связь канала связи

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  <<Включить>> Связь

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

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  <<Расширить>> отношения

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

  Отношение обобщения

  Обобщенное отношение похоже на обобщенное отношение объектно-ориентированного языка на диаграммах классов и может применяться к обобщению ролей (акторов) и вариантов использования.

  Например, в системе бронирования есть два типа методов бронирования: «забронировать билет по телефону» и «забронировать билет через Интернет», а также базовый вариант использования «забронировать билет», поэтому вы можете использовать обобщение для формирования случая, и добавьте <<essential>> к родительскому варианту использования (бронирование), чтобы указать обобщенную связь.

  

  ИЗМЕНИТЬ ЭТОТ ПРИМЕР ДИАГРАММЫ ВАРИАНТОВ ИСПОЛЬЗОВАНИЯ

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

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

  Вариант использования — поток событий

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

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

  Сценарии использования и поток событий – снятие денег через банкомат

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

  Обычный сценарий – вывод средств – основной ход событий:

  1. Пользователь вставляет кредитную карту
  2. Введите PIN-код
  3. Введите сумму вывода
  4. Снимает наличные
  5. Выйдите из системы и получите кредитную карту

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

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

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

  Альтернативные сценарии

  Для варианта использования «Снятие средств» в системе банкомата мы можем получить несколько альтернативных процессов следующим образом.

  Снятие – альтернативные процессы событий.

  1. Альтернативный сценарий I: Пользователь может отказаться на любом шаге основного процесса и перейти к шагу 5 основного процесса.
  2. Альтернативный процесс II: на шаге 1 основного процесса пользователь вставляет недействительную кредитную карту, система отображает ошибку и закрывает кредитную карту, и вариант использования заканчивается.
  3. Альтернативный процесс III: на шаге 2 основного процесса пользователь вводит неверный пароль, система отображает ошибку и предлагает пользователю повторно ввести пароль и вернуться к шагу 2 основного процесса; после трех неправильных вводов пароля кредитная карта конфискуется системой, и вариант использования заканчивается.
  4. …

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

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

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

  Модель вариантов использования состоит из диаграммы вариантов использования и подробного описания каждого варианта использования, спецификации варианта использования, которая предоставляется в виде шаблона в RUP.

  Краткое описание
  Краткое описание роли и цели варианта использования.

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

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

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

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

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

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

  Например:

  • диаграммы деятельности полезны для описания сложных процессов принятия решений,
  • диаграммы перехода состояний полезны для описания поведения системы, связанного с состоянием, и
  • диаграммы последовательности подходят для описания обмена сообщениями на основе времени.

  Используйте инструменты кейса

  Онлайн-версия

  Бесплатная версия бесплатного инструмента для рисования Visual Paradigm Online (VP Online) поддерживает UML, ERD и организационные диаграммы. Вы можете быстро нарисовать диаграммы вариантов использования с помощью интуитивно понятного редактора чертежей UML. В этом бесплатном инструменте UML нет рекламы, нет ограниченного периода доступа и нет ограничений, таких как количество диаграмм, количество фигур и т. д. Рисуйте UML свободно. Рисуйте UML свободно. вам принадлежат диаграммы, которые вы создаете для личных и некоммерческих целей.

  Настольная версия

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

  использованная литература

  • Что такое диаграмма вариантов использования?
  • Типы актеров в модели вариантов использования
  • Определите требования пользователя с помощью диаграмм вариантов использования
  • Что такое спецификация варианта использования?
  • История пользователя и вариант использования для гибкой разработки программного обеспечения
  • Используйте подход, основанный на прецедентах, для гибкой разработки

  UML-ресурсы

  • Что такое УМЛ?
  • Почему UML-моделирование?
  • Обзор 14 типов диаграмм UML

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Требование (requirement) — желательное свойство, характеристика или условие, которым должна удовлетворять система в процессе своей эксплуатации.

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

• функциональные требования (Functionality)
• требования удобства использования (Usability)
• требования надежности (Reliability)
• требования производительности (Performance)
• требования возможности сопровождения (Supportability)

При этом символом «+» обозначены дополнительные условия, к которым относятся:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. система добавляет ученика;
5. учителю открывается главное меню и в течении 5 секунд выводится уведомление о том, что ученик был добавлен успешно.

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

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель нажимает кнопку «назад»;
4. учителю открывается главное меню (при этом данные, введенные в формы окна добавления ученика не сохраняются).

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

1. учитель выбирает в главном меню пункт «добавить ученика«;
2. система показывает учителю окно добавления ученика, содержащее поля для ввода логина и пароля, а также кнопки «далее» и «назад»;
3. учитель вводит желаемый логин и пароль ученика, нажимает кнопку «далее»;
4. учителю в течении 5 секунд отображается уведомление о том, что запрашиваемый логин занят.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Шаблон

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

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

Нотация

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

См. также

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