2.7.1Обозначения в диаграмме вариантов использования
В
UML
актёр представляется в виде фигуры
(имя обязательно), вариант использования
в виде эллипса (имя обязательно):
Отношение между актёром и вариантом использования называют коммуникативной ассоциацией (communicate association). Отношение может быть либо двухсторонним (от актёра к функции и от функции к актёру), либо односторонним (от актёра к функции или от функции к актёру). Направление показывает, кто является инициатором (актёр или функция). Следует заметить, что не имеет смысла связывать друг с другом актёров, поскольку они действуют вне системы.
Между прецедентами существует два типа отношений зависимости:
Отношение включения (include relationship).
О
тношение
дополнения (extend
relationship).
Стереотип коммуникативной ассоциации (communicate) обычно не указывается на диаграмме, потому что это единственный тип связи между актёром и функцией. Стереотипы включения и дополнения обязательно должны быть указаны на диаграмме.
Отношение включения между двумя прецедентами создаётся тогда, когда один прецедент использует другой. Различные прецеденты могут иметь одинаково функционирующие фрагменты. Такие фрагменты обычно помещают в один прецедент, чтобы не повторять несколько раз. Например, действия по аутентификации пользователя или проверке определённого состояния объекта могут использоваться многими прецедентами системы.
Отношение дополнения используется для отражения:
дополнительных режимов;
режимов, которые запускаются только при определённых условиях (например, сигнал тревоги);
альтернативных потоков, которые запускаются по выбору актёров.
Отношение дополнения направлено от дополнительного прецедента к базовому прецеденту.
Г
лавная
диаграмма функций системы РЕГИСТРАТОР:
2.7.2Идентификация актёров и вариантов использования
Актёры и возможные варианты использования выявляются в модели предметной области, а также в имеющихся документах, заданиях, требованиях, специальной литературе, диалогах с пользователями. Известны два способа:
Анализ актёров. Идентификация кого-то или чего-то, что связано с предприятием, и что должно взаимодействовать с системой. Это могут быть исполняемые людьми роли (начальник, диспетчер, клиент, системный администратор); другие компьютерные системы (бухгалтерская система, система безопасности); электромеханические устройства (напольная автоматика, датчик), время (если от него зависит выполнение системой каких-либо функций). Далее детализируются для каждого действующего лица процессы, которые эти лица инициируют или в которых участвуют (кассир – регистрация в системе, работа с деньгами; покупатель – покупка товаров, возврат товаров).
Анализ событий. Идентификация внешних событий, на которые должна реагировать система. Связывание событий с актёрами и вариантами использования.
Рассмотрим пример определения актёров в системе регистрации курсов университета. Допустим, известны следующие события:
Студент хочет зарегистрироваться на курсы.
Преподаватель хочет выбрать курсы, которые должен читать.
Регистратор должен создать учебный план и составить каталог на семестр.
Регистратор должен хранить информацию о студентах, преподавателях и курсах.
Система оплаты должна получать необходимую информацию из системы регистрации.
Анализ событий позволяет выделить для системы актёров и прецеденты.
Актёры:
студент,
преподаватель,
регистратор,
система оплаты.
Прецеденты:
для студента: регистрироваться на курсы;
для преподавателя: выбирать курсы; запрашивать расписание;
для регистратора: регистрировать на курсы; управлять информацией о студентах, преподавателях и курсах; создавать каталог и расписание.
Следующий пример демонстрирует идентификацию актёров и прецедентов автоматизированной системы розничной торговли.
Допустим, в результате анализа определены следующие актёры и связанные с ними прецеденты:
Кассир |
Регистрация в системе Оформление покупки |
Покупатель |
Покупка товара Возврат товара |
Менеджер |
Включение системы Отключение системы |
Системный администратор |
Добавление новых пользователей |