Диаграммы вариантов использования
В настоящее время существуют десятки приемов, методик, визуальных представлений, позволяющих моделировать требования к программному обеспечению. Необходимо определить целесообразность использования тех или иных приемов. Анализ требований должен соответствовать тому что делает система, абстрагируясь от деталей реализации, т.е. от того, как она это делает.
Язык UML предоставляет в распоряжение пользователей легко воспринимаемый и выразительный язык визуального моделирования, предназначенный для разработки и документирования сложных моделей систем различного целевого назначения.
Язык UML представляет набор разработанных инженерных задач практического профиля, которые успешно испытаны при моделировании крупных и сложных систем. Поддерживается метамодель для диаграмм классов и набор семантических и синтаксических правил, определяющих суть элементов и их отношений. Модель поддерживается большим количеством автоматизированных инструментов. Основные цели использования языка UML на этапе разработки проекта ПС:
— поддержка на уровне пользователей готового к применению, выразительного визуального языка моделирования, применяемого для разработки и обмена моделями;
— поддержка спецификаций, независимых от определенных языков программирования и процессов разработки;
— поддержка формального базиса для представления языка моделирования;
— поддержка высокоуровневых понятий, таких как компоненты, элементы сотрудничества, каркасы и шаблоны;
— интеграция наилучшего опыта.
Разработчики UML установили, что даже при использовании современных передовых технологий, при сборе требований, анализе и разработке продолжается борьба с неадекватными и постоянно изменяющимися требованиями заказчиков. Варианты использования предназначены для уточнения динамических требований и выработки более четкого представления возможных изменений в поведении системы. Они позволяют реализовать функциональные усовершенствования, которые отражаются и адресуются в организованной форме. Классы и объекты языка UML демонстрируют гибкость и управляемость при использовании статично и динамично несовершенных описаний. Для оживления общения в команде специалистов ООП позволяет реализовать в группе программистов интегрированный подход с помощью общего словаря и языка; инкапсуляция данных и алгоритмов позволяет членам команды работать над компонентами в параллельном режиме. Также в этом случае можно ограничить влияние изменчивости требований; наследственные свойства функций и атрибутов являются эффективным дополнением к функциональным возможностям.
Определение вариантов использования. Разработку спецификаций программного обеспечения начинают с анализа требований к функциональности, указанных в техническом задании. В процессе анализа выявляют внешних пользователей разрабатываемого программного обеспечения и перечень отдельных аспектов его поведения в процессе взаимодействия с конкретными пользователями. Аспекты поведения программного обеспечения были названы вариантами использования, или прецедентами (use cases).
Не следует путать вариант использования с конкретными операциями будущей системы. Каждый вариант использования связан с некоторой целью, имеющей самостоятельное значение; например, для текстового редактора Формирование оглавления - это вариант использования, а Связывание заголовков со специальными стилями — операция, которую необходимо выполнить, чтобы стало возможно автоматическое построение оглавления.
В зависимости от цели выполнения процедуры различают следующие варианты использования:
основные (базовые) — обеспечивают требуемую функциональность разрабатываемого ПО;
вспомогательные — обеспечивают выполнение необходимых настроек системы и ее обслуживание (например;; архивирование информации и т.п.);
дополнительные — обеспечивают дополнительные удобства для пользователя (как правило, реализуются, если не требуют серьезных затрат каких-либо ресурсов ни при разработке, ни при эксплуатации).
Графических средств языка UML на практике оказывается недостаточно для спецификации функциональных требований к программной системе. Следует отметить, что одним из требований языка UML является самодостаточность диаграмм для представления информации о моделях проектируемых систем. Однако изобразительных средств языка UML явно не хватает для того, чтобы учесть на диаграммах вариантов использования особенности функционального поведения сложной системы. С этой целью рекомендуется дополнять этот тип диаграмм текстовыми сценариями, которые уточняют или детализируют последовательность действий, совершаемых системой при выполнении ее вариантов использования.
В контексте языка UML сценарий используется для дополнительной иллюстрации взаимодействия актеров и вариантов использования. Предлагаются различные способы представления или написания подобных сценариев. Один из таких шаблонов представлен в табл. 4.1 и может быть рекомендован для применения на начальных этапах концептуального моделирования. В зависимости от уровня абстракции вариант использования может описываться кратко или более подробно. Краткая форма описания содержит: имя варианта использования, перечень действующих лиц (актеров) и тип варианта использования (основной, вспомогательный или дополнительный) и его краткое описание.
При написании сценариев вариантов использования важно понимать, что текст сценария должен дополнять или уточнять диаграмму вариантов использования, но не заменять ее полностью. В противном случае будут потеряны достоинства визуального представления моделей.
Основные понятия. Диаграммы вариантов использования. Диаграммы вариантов использования позволяют наглядно представить ожидаемое поведение программной системы. Основными понятиями диаграмм вариантов использования являются действующее лицо, вариант использования и связь.
На рис. 4.1 приведены условные обозначения, которые применяют при изображении диаграмм вариантов использования.
Рис. 4.1. Основные условные обозначения диаграмм вариантов использования: а — действуюсцев лицо; б — вариант использования; в — связь
Действующее лицо - внешняя по отношению к разрабатываемому программному обеспечению сущность, которая взаимодействует с ним в целях получения или предоставления какой-либо информации. Как уже упоминалось выше, действующими лицами могут быть пользователи, другое программное обеспечение или какие-либо технические средства.
Вариант использования — некоторая очевидная для действующего лица процедура, решающая его конкретную задачу. Все варианты использования так или иначе связаны с требованиями к функциональности разрабатываемой системы и могут сильно раздаться по объему выполняемой работы (рис. 4.2).
Связь — взаимодействие действующих лиц и соответствующих вариантов использования.
Варианты использования также могут быть связаны между собой. При этом фиксируют связи использования и расширения.
Использование (uses (include)) подразумевает, что существует некоторый фрагмент поведения разрабатываемого ПО, который повторяется в нескольких вариантах использования. Этот фрагмент оформляют как отдельный вариант и указывают связь с ним типа «использование».
Расширение (extends) применяют, если имеется два подобных варианта использования, различающиеся наличием в одном из них некоторых дополнительных действий. В этом случае дополнительные действия определяют как отдельный вариант использования, который связан с основным вариантом связью типа «расширение».
Главное назначение диаграммы вариантов использования заключается в формализации функциональных требований к системе и возможности согласования полученной модели с заказчиком на ранней стадии проектирования. Любой из вариантов использования может быть подвергнут дальнейшей декомпозиции на множество подвариантов использования отдельных элементов, которые образуют исходную сущность.
Пример разработки диаграммы вариантов использования.
Модель системы «Склад оптовой торговли»
+++++++++++++++++
Расматриваемая система имеет пять актеров, двое из которых выступают контрагентами, а другие — менеджерами склада, осуществляющими выполнение всех операций. Каждый из этих актеров взаимодействует c системой, хотя главными актерами, являются поставщики и покупатели (контрагенты), поскольку именно ониинициирует функциональность системы. Далее формулируются варианты использования, т.е, действия, выполняемые системой для реализации общения действующих лиц (aктеров)
Каждый из действующих лиц проследует определенные цели по отношению к системе: поставщик — сдать товар на склад, покупатель — приобрести товар, менеджер склада принять и отпустить товар, менеджер учетного отдела — определить объемы поступления и продаж и проанализировать товарный запас. На основании этих целей можно сформулировать базовые варианты использования и проанализировать взаимосвязи между ними. На самом деле вариантов использования может быть гораздо больше. Например, проверить платежеспособность клиента, получить информацию о товаре, оценить запасы товара на складе, получить оплату и т.д. Однако эта диаграмма дает понять, что будет делать система, как она будет функционировать.
На следующем этапе разработки модели вариантов использования для рассматриваемой системы следует дополнить данную диаграмму текстовым сценарием, написанным на основе предложенного ранее шаблона. Этот сценарий будет дополнять диаграмму, раскрывая содержание и логическую последовательность отдельных действий, которые выполняются системой и актерами в процессе поступления и реализации товаров. В этом случае сценарий удобно представить в виде таблиц, каждая из которых описывает отдельный раздел шаблона.
В главном разделе сценария указывается имя рассматриваемого варианта использования, имена взаимосвязанных с ним актеров, цель выполнения варианта, условный тип и ссылки на другие варианты использования (табл. 4.2).
| Вариант использования | Продажа товара |
| Актеры | Покупатель, Менеджер отдела оформления заказов, Менеджер склада |
| Краткое описание | Покупатель запрашивает товар. Менеджер отдела оформления заказов резервирует товар, оформляет заказ, передает заказ Менеджеру склада. Покупатель оплачивает товар, получает товар на складе |
| Цель | Получение необходимого товара |
| Тип | Базовый |
| Ссылки на другие варианты использования | Включает в себя варианты использования: определить наличие товара; оформить заказ |
В следующем разделе сценария описывается последовательность действий, приводящая к успешному выполнению рассматриваемого варианта использования. При этом инициатором действий должен выступать актер Покупатель. Для удобства последующих ссылок каждое действие актеров помечается порядковым номером в последовательности действий (табл. 4.3).
| Действия актеров | Отклик системы |
| 1. Покупатель запрашивает товар – Исключение 1. На складе нет необходимого количества запрашиваемого товара | 2. Менеджер отдела оформления заказов проверяет нличие необходимого товара на складе 3. Менеджер отдела оформления заказов резервирует нежный товар |
| 4. Покупатель оплачивает товар – исключение2. Покупатель не оплатил товар | 5. Менеджер отдела оформления заказов выдает разрешение на получение товара 6. Менеджер отдела оформления заказов передает заказ на склад 7. Менеджер склада выдает товар и расходную накладную покупателю 8. Менеджер оформления заказов блокирует получение товара |
В третьем разделе сценария описывается последовательность действий, выполняемых при возникновении исключительных ситуаций, или исключений (табл. 4.4).
| Действия актеров | Отклик системы |
| Исключение 1. На складе нет необходимого количества запрашиваемого товара | |
| 4. Покупатель оплачивает товар | 3. Менеджер отдела оформления заказов инициирует поставку нужного товара |
| Исключение 2. Покупатель не onлатил товар | |
| 8. Менеджер оформления заказов блокирует получение товара покупателем |
Можно дополнить данный сценарий, аналогичным образом описав не только варианты использования «Оформление заказа» и «Определение наличия товара», но и рассмотрев другие исключения, например оформление скидок постоянным покупателям и т. п.
При этом полнота сценариев и модели вариантов использования будут определяться теми функциональными требованиями, которые сформулированы в рамках конкретного проекта.
Отдельные небольшие по своему объему сценарии могут быть размещены на диаграмме в форме примечаний note, предназначенных для включения в модель произвольной текстовой информации, которая имеет непосредственное отношение к контексту разрабатываемого проекта. В качестве такой информации могут быть комментарии разработчика (например, дата и версия разработки диаграммы или ее отдельных компонентов), ограничения (например, на значения отдельных связей или экземпляры сущностей) и помеченные значения. Применительно к диаграммам вариантов использования примечание может иметь уточняющую информацию, относящуюся к контексту тех или иных вариантов использования.
Графически примечания на всех типах диаграмм обозначаются. прямоугольником с «загнутым» верхним правым уголком (рис. 4.4).
Собственно текст примечания размещается внутри этого прямоугольника. Примечание может относиться к любому элементу диаграммы, в этом случае их соединяет пунктирная линия. Если примечание относится к нескольким элементам, то от него проводятся, соответственно, несколько линий. Как уже отмечалось, примечания могут присутствовать не только на диаграмме вариантов использования, но и на других канонических диаграммах.
Рекомендации к разработке диаграмм вариантов использования. Как было отмечено ранее, одно из главных назначений диаграммы вариантов использования заключается в формализации функциональных требований к системе. Диаграмма вариантов использования может служить основой для согласования с заказчи функциональных требований к системе на ранней стадии проектирования. Любой из базовых вариантов использования в последующем может быть подвергнут декомпозиции на частные варианты использования. При этом рекомендуется, чтобы общее количество актеров в модели не превышало 20, а вариантов использования — 50. В противном случае модель теряет свою наглядность и, возможно, заменяет собой одну из некоторых других диаграмм.
Для разработки диаграммы вариантов использования рекомендуется соблюдать некоторую последовательность действий:
определить главных, или первичных, и второстепенных актеров;
определить цели главных актеров по отношению к системе;
сформулировать основные варианты использования, которые специфицируют функциональные требования к системе;
упорядочить варианты использования по степени убывания риска их реализации;
рассмотреть все базовые варианты использования в порядке убывания их степени риска;
выделить участников, интересы, предисловия и постусловия выполнения выбранного варианта использования;
написать успешный сценарий реализации выбранного варианта использования,
определить исключения или неуспех в выполнении сценария варианта использования;
написать сценарии для всех исключений;
выделить общие варианты использования и изобразить их взаимосвязи с базовыми со стереотипом uses include);
выделить варианты использования для исключений и из обратить их взаимосвязи с базовыми со стереотипом extend;
проверить диаграмму на отсутствие дублирования вариантов использования и актеров.
Семантика построения диаграммы вариантов использования должна определяться следующими особенностями рассмотренных выше элементов модели. Отдельный экземпляр варианта использования по своему содержанию является выполнением последовательности действий, которая инициализируется посредством экземпляра сообщения от экземпляра актера. В качестве отклика или ответной реакции на сообщение актера выполняется последовательность действий, установленная для данного варианта использования. При этом актеры могут негерировать новые сообщения для инициирования вариантов использования.