что такое вариант использования
Диаграмма сценариев использования в процессе разработки ПО
Уже несколько лет я, как аналитик, довольно широко использую в своей работе сценарии использования (СИ) и диаграммы СИ для документирования требований. Вообще, у сценариев использования есть разные названия. Их называют use cases, варианты использования и даже прецеденты. Помню, как в середине 2000-х, на некоторых аналитических ресурсах шло жаркое обсуждение того, как же перевести термин use case на русский язык. Вот тогда это страшное слово «прецедент» и появилось, даже более того, некоторые товарищи утверждали, что русский язык ущербен и не позволяет передать все тонкости понятия use case. Но как показало время, понятие сценарий использования (или вариант использования) вполне себе подходит и довольно приятно на слух.
Имея только положительный опыт работы с СИ, я был очень удивлен, когда при общении с коллегами из других компаний узнал, что они их не используют и, более того, даже пытались переубедить меня, что рисование человечков, овалов и палочек между ними – это пустая трата времени. Поэтому я и решил поделиться своим опытом и продемонстрировать, как диаграммы СИ помогают мне в работе.
Во-первых, что такое сценарий использования? Сценарий использования – это связный рассказ о поведении системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Кто-то или что-то может быть пользователем системы, это может быть какая-то информационная система или устройство. И этот кто-то или что-то называется Действующим лицом (ДЛ). А сам сценарий использования представляет собой последовательность шагов, которые описывают действия ДЛ и реакцию системы на них.
Например, сценарий регистрации на каком-нибудь сайте может выглядеть вот так:
Но въедливый читатель может справедливо возразить, что в разработку такой сценарий отдавать нельзя. И он будет прав! Мы ведь сейчас посмотрели на систему с высоты, наверно, 5-этажного дома, когда общее поведение уже понятно, но детальных требований ещё нет. Поэтому сценарий использования должен быть, как минимум, дополнен альтернативными потоками выполнения (то что представлено выше, называется основной поток и описывает действия системы, когда все идет как надо). Альтернативные потоки – это потоки, в которых описывается реакция системы на ошибочные действия пользователя или исключительные ситуации, либо же случаи альтернативных действий пользователя, если он захотел, например, зарегистрироваться с помощью аккаунта в социальной сети. Также документ со сценарием использования можно дополнить деталями пользовательского интерфейса, правилами валидации данных, различными бизнес-правилами и сообщениями об ошибках. А вот нефункциональные требования обычно описываются в отдельном документе, так как они обычно применимы ко всей системе целиком, а не к конкретным СИ.
Если же подняться ещё выше и посмотреть на систему с большей «высоты», то она будет выглядеть как набор услуг, предоставляемых системой пользователю (сценарии использования также можно рассматривать как высокоуровневые требования к системе). Тут мы приходим к тому, что неплохо бы было визуализировать эти требования, и для этого отлично подходит соответствующая диаграмма UML: диаграмма сценариев использования. Кусочек диаграммы показан ниже. Она состоит из действующих лиц, сценариев использования и различных связей между ними.
Для разработчиков и тестировщиков она, на первый взгляд, несет ещё меньше пользы, чем сами сценарии использования. Но ведь и предназначена она для другого!
Диаграмма СИ рисуется обычно аналитиком в самом начале проекта для того, чтобы широкими мазками охватить весь планируемый функционал проекта и согласовать его с заказчиком. И после этого каждый СИ уже детализируется с помощью шагов и детальных требований. СИ помогают смотреть на систему с точки зрения предоставляемых системой услуг и не закапываться в частности.
Я обычно использую диаграмму СИ для решения следующих задач:
Оценка трудоемкости проекта
Как показывает опыт и практика, оценка получается тем точнее, чем детальнее выделен список предстоящих работ. Ведь действительно, задачу «написать статью» оценить гораздо сложнее, чем задачу «найти 5 картинок для иллюстраций». Так вот, сценарии использования являются первой итерацией разбивки системы на отдельные элементы. Более того, эти элементы обладают хорошей связностью (в данном случае – функциональная) и могут быть оценены отдельно друг от друга. Если этого недостаточно, то уже каждый СИ можно декомпозировать на основной/альтернативные потоки или даже задачи, которые необходимо выполнить программисту для реализации отдельного сценария.
Здесь довольно часто также проявляется возможность повторного использования ранее созданных артефактов. Например, если для системы требуется функционал регистрации пользователей, то плюс/минус он будет работать одинаково во многих системах, что при оценке сразу же снижает степень неопределенности.
Даже существует специальный способ оценки, основанный на СИ – Use Case Points. В этом случае выделяются действующие лица и сценарии, у них по определенным правилам определяется сложность, задаются некоторые поправочные коэффициенты, учитывающие профессионализм команды и сложность предметной области, и на выходе появляется готовая оценка. То есть, к оценке, в идеале, даже не надо привлекать разработчиков и тестировщиков.
Планирование графика работ
В проектах с фиксированном бюджетом обычно явно выделяются последовательные стадии проектирования, разработки и тестирования (как в водопадной модели). Но в реальности тестирование уже частично начинается даже до завершения стадии проектирования, так как тестировщики подключатся к ревью разработанных требований и начинают писать тест-дизайн. И если для аналитика и, скажем, архитектора, составить график работ не составляет большого труда, так как активности этих ролей начинаются вместе со стартом проекта, то определить, когда и на какую задачу стоит подключать тестировщиков с разработчиками, уже становится сложнее. Действительно, ведь входными данными для них являются подготовленные и согласованные документы с требованиями. И для решения этой проблемы опять хорошо подходят СИ. Так как каждый сценарий содержит в себе завершенное описание какого-то процесса, то их проще согласовывать с заказчиками и, соответственно, можно довольно точно установить в план-графике ключевые точки согласования документов требований. А уже от этих точек планировать работу остальной команды.
Выявление пропущенных требований
Не удивительно, что когда заказчик каким-то образом озвучивает требования к будущей системе, то он в своем описании сконцентрирован именно на полезном функционале и никак не упоминает, например, функции настройки системы или функции управления учетными записями пользователей, хотя без них система не будет полноценно работать. Очень часто после получения таких требований команда начинает выполнять оценку. У меня на практике были случаи, когда команда сразу бросалась в бой и оценивала то, что описал заказчик, оставляя за бортом неозвученные, но, тем не менее, обязательные функции системы.
Также бывает и другая ситуация, когда в описании системы присутствуют требования о том, что в процессе работы пользователи должны создавать какие-то сущности. В подавляющем большинстве случаев, к таким сущностям применимы все CRUD (Create, Read (или также встречается расшифровка Retrieve), Update, Delete) операции, про которые тоже иногда забывают. В чем же здесь польза модели СИ? А как раз в графическом представлении требований. Когда глаз охватывает всю картинку, то гораздо проще заметить недостающие элементы, чем когда требования сформулированы обычным текстом.
«Оглавление» для проектных документов
Очень часто заказчик просит вместе с системой передавать комплект проектной документации. У себя в компании мы пишем проектную документацию в виде сценариев использования. Если же заказчик требует документы по ГОСТу, то все равно сперва пишутся сценарии использования, а затем уже на их основе формируются ГОСТовские документы.
У нас используется, как минимум, два подхода к документированию: когда каждый СИ описывается в отдельном документе, и когда в одном документе описываются сразу несколько СИ, относящихся к одной подсистеме. Часто тот или иной подход определяется, исходя из принятого процесса или привычек заказчика.
Выше уже было сказано, что первая версия списка сценариев использования уже формируется на этапе оценки и планирования графика работ. В дальнейшем этот список может дополняться и корректироваться, но уже с определенной степенью точности можно договариваться с заказчиком о том, какие именно документы будет предоставлять проектная команда.
Вариант использования
Прецеденты были предложены Иваром Якобсоном и значительно популяризированы Алистером Коберном.
Назначение
Прецеденты служат для документирования функциональных требований к программным системам. Прецедент описывает некоторый целостный фрагмент поведения системы, не вдаваясь при этом в особенности внутренней структуры субъекта. Определение прецедента содержит все свойственные ему виды поведения: основную последовательность, различные варианты стандартного поведения и различные исключительные ситуации с указанием ответной реакции на них. С точки зрения пользователя некоторые из видов поведения выглядят как ошибочные. Однако для системы ошибочная ситуация является одним из вариантов поведения, который должен быть описан и обработан.
Прецедент описывает взаимодействие программной системы с акторами в виде последовательности сообщений. В понятие актор входят люди, компьютерные системы и процессы.
При проектировании программной системы производится поиск таких классов для реализации прецедента, которые удачно сочетали бы в себе требуемые роли и не приводящие к излишнему усложнению системы. Реализацию прецедента можно смоделировать в виде одной или нескольких коопераций (реализаций прецедента).
Один и тот же прецедент может быть описан с различной степенью детализации.
В MSF используются аналоги прецедентов — сценарии (англ. Scenario ).
Нотация
На диаграммах прецедентов в эллипса. Внутри эллипса или под ним указывается имя элемента.
К прецедентам в UML применимы следующие виды отношений:
Ссылки
Полезное
Смотреть что такое «Вариант использования» в других словарях:
вариант использования — 01.05.13 вариант использования [ use case]: Детальное описание отдельного действия в бизнес процессе, устанавливающее входные и выходные данные, требования к выполнению/выбору времени, способы преодоления ошибочных ситуаций и интерфейсы с… … Словарь-справочник терминов нормативно-технической документации
вариант — 2.68 вариант (variant): Конфигурация всей информационной системы или ее части, наряду с которой существует другая система, имеющая другую конфигурацию, обеспечивающая те же услуги. Источник: ГОСТ Р ИСО/МЭК ТО 10032 2007: Эталонная модель… … Словарь-справочник терминов нормативно-технической документации
Вариант вывода из эксплуатации блока атомной станции — Вариант вывода из эксплуатации блока АС один из способов достижения заданного конечного состояния блока АС после завершения всех работ по выводу из эксплуатации. Основными вариантами вывода из эксплуатации блока АС являются: ликвидация блока АС;… … Официальная терминология
Вариант 1. — 7.7.1 Вариант 1. Определяются детали и элементы трубопроводов, работающие с наибольшими напряжениями с учетом: фактических условий эксплуатации; фактического состояния трасс и ОПС трубопроводов; фактической нагрузки пружинных опор и подвесок;… … Словарь-справочник терминов нормативно-технической документации
ВАРИАНТ РАЗВИТИЯ ЭКОНОМИКИ — оценка возможностей развития экономики с учетом различных предпосылок о масштабах, пропорциях, темпах, нормативах, ограничениях и целевых установках. Например, варианты развития можно формировать, исходя из различной структуры использования… … Большой экономический словарь
Сценарий использования — Сценарий использования, вариант использования, прецедент или же пользовательский сценарий (англ. Use Case) в разработке программного обеспечения и системном проектировании это описание поведения системы, которым она отвечает на внешние запросы.… … Википедия
Варианты использования — Прецедент (англ. Use Case, а также: вариант использования, сценарий использования) спецификация последовательностей действий (варианты последовательностей и ошибочные последовательности), которые может осуществлять система, подсистема или класс,… … Википедия
Новозеландский вариант английского языка — (англ. New Zealand English) форма английского языка, используемая в Новой Зеландии. Английский язык был занесён в Новую Зеландию колонистами в XIX в. Самое заметное влияние на новозеландский вариант английского языка оказал… … Википедия
Коэффициент использования площади бумаги — коэффициент, измеряемый отношением площади полосы к площади страницы до обрезки блока или книги (брошюры) в обложке и выражаемый в процентах. Разные форматы изданий различаются по К. и. п. б. При равных условиях набора и верстки чем этот… … Издательский словарь-справочник
Як-141 — Як 141 … Википедия
Элементы графической нотации диаграммы вариантов использования
Диаграмма вариантов использования как концептуальное представление бизнес-системы в процессе ее разработки.
Визуальное моделирование с использованием нотации UML можно представить как процесс поуровневого спуска от наиболее общей и абстрактной концептуальной модели исходной бизнес-системы к логической, а затем и к физической модели соответствующей программной системы. Для достижения этих целей вначале строится модель в форме так называемой диаграммы вариантов использования (use case diagram ), которая описывает функциональное назначение системы или, другими словами, то, что бизнес-система должна делать в процессе своего функционирования.
Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного (рис. 3.1, а) или глагола (рис. 3.1, б) с пояснительными словами. Сам текст имени варианта использования должен начинаться с заглавной буквы.
Имя (name) — строка текста, которая используется для идентификации любого элемента модели.
Примерами вариантов использования могут быть следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия.
Актер (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.
В некоторых случаях актер может обозначаться в виде прямоугольника класса со стереотипом и обычными составляющими элементами класса. Имена актеров должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели. При этом символ отдельного актера связывает соответствующее описание актера с конкретным именем.
Что такое вариант использования
Диаграмма прецедентов (вариантов использования или Use Case)
Диаграмма вариантов использования, общие понятия
Диаграмма вариантов использования (use case diagram) — диаграмма, на которой изображаются отношения между акторами и вариантами использования (прецедентами).
Назначение данной диаграммы состоит в следующем: проектируемая информационная система представляется в форме так называемых вариантов использования, с которыми взаимодействуют внешние сущности или акторы. При этом актором или действующим лицом называется любой объект, субъект или система, взаимодействующая с моделируемой бизнес-системой извне. Это может быть человек, техническое устройство, программа или любая другая система, которая служит источником воздействия на моделируемую систему так, как определит разработчик. Вариант использования служит для описания сервисов, которые система предоставляет актору. Другими словами каждый вариант использования определяет набор действий, совершаемый системой при диалоге с актором. При этом ничего не говорится о том, каким образом будет реализовано взаимодействие акторов с системой и собственно выполнение вариантов использования.
Рассматривая диаграмму вариантов использования в качестве модели бизнес-системы, можно ассоциировать ее с «черным ящиком». Концептуальный характер этой диаграммы проявляется в том, что подробная детализация диаграммы или включение в нее элементов физического уровня представления на начальном этапе проектирования скорее имеет отрицательный характер, поскольку предопределяет способы реализации поведения системы. Эти аспекты должны быть сознательно скрыты от разработчика на диаграмме вариантов использования.
В самом общем случае, диаграмма вариантов использования представляет собой граф специального вида, который является графической нотацией для представления конкретных вариантов использования, акторов и отношений между этими элементами. При этом отдельные элементы диаграммы заключают в прямоугольник, который обозначает границы проектируемой системы. В то же время отношения, которые могут быть изображены на данном графе, представляют собой только фиксированные типы взаимосвязей между акторами и вариантами использования, которые в совокупности описывают сервисы или функциональные требования к моделируемой системе.
Базовыми элементами диаграммы вариантов использования являются вариант использования и актор.
Вариант использования представляет собой спецификацию общих особенностей поведения или функционирования моделируемой системы без рассмотрения внутренней структуры этой системы. Несмотря на то, что каждый вариант использования определяет последовательность действий, которые должны быть выполнены проектируемой системой при взаимодействии ее с соответствующим актором, сами эти действия не изображаются на рассматриваемой диаграмме.
Содержание варианта использования может быть представлено в форме дополнительного пояснительного текста, который раскрывает смысл или семантику действий при выполнении данного варианта использования. Такой пояснительный текст получил название текста-сценария или просто сценария. Далее рассматривается один из шаблонов, который может быть рекомендован для написания сценариев вариантов использования.
Отдельный вариант использования обозначается на диаграмме эллипсом, внутри которого содержится его краткое имя в форме существительного или глагола с пояснительными словами. Сам текст имени варианта использования должен начинаться с заглавной буквы.
Цель варианта использования заключается в том, чтобы зафиксировать некоторый аспект или фрагмент поведения проектируемой системы без указания особенностей реализации данной функциональности. В этом смысле каждый вариант использования соответствует отдельному сервису, который предоставляет моделируемая система по запросу актора, т.е. определяет один из способов применения системы. Сервис, который инициализируется по запросу актора, должен представлять собой законченную последовательность действий. Это означает, что после того как система закончит обработку запроса актора, она должна возвратиться в исходное состояние, в котором снова готова к выполнению следующих запросов.
Диаграмма вариантов использования содержит конечное множество вариантов использования, которые в целом должны определять все возможные стороны ожидаемого поведения системы. Для удобства множество вариантов использования может рассматриваться как отдельный пакет. Применение вариантов использования на всех этапах работы над проектом позволяет не только достичь требуемого уровня унификации обозначений для представления функциональности подсистем и системы в целом, но и является мощным средством последовательного уточнения требований к проектируемой системе на основе их итеративного обсуждения со всеми заинтересованными специалистами.
Примерами вариантов использования могут быть следующие действия: проверка состояния текущего счета клиента, оформление заказа на покупку товара, получение дополнительной информации о кредитоспособности клиента, отображение графической формы на экране монитора и другие действия.
Актор (actor) — согласованное множество ролей, которые играют внешние сущности по отношению к вариантам использования при взаимодействии с ними.
Актор представляет собой любую внешнюю по отношению к моделируемой системе сущность, которая взаимодействует с системой и использует ее функциональные возможности для достижения определенных целей или решения частных задач. Каждый актор может рассматриваться как некая отдельная роль относительно конкретного варианта использования. Стандартным графическим обозначением актора на диаграммах является фигурка «человечка», под которой записывается имя актора
Имена акторов должны начинаться с заглавной буквы и следовать рекомендациям использования имен для типов и классов модели.
Имя актора должно быть достаточно информативным с точки зрения семантики. Для этой цели подходят наименования должностей в компании (например, продавец, кассир, менеджер, президент).
Акторы используются для моделирования внешних по отношению к проектируемой системе сущностей, которые взаимодействуют с системой. В качестве акторов могут выступать другие системы, в том числе подсистемы проектируемой системы или ее отдельные классы. Важно понимать, что каждый актор определяет согласованное множество ролей, в которых могут выступать пользователи данной системы в процессе взаимодействия с ней. В каждый момент времени с системой взаимодействует вполне определенный пользователь, при этом он играет или выступает в одной из таких ролей. Наиболее наглядный пример актора — конкретный покупатель в магазине автозапчастей.
Поскольку в общем случае актор всегда находится вне системы, его внутренняя структура никак не определяется. Для актора имеет значение только его внешнее представление, т.е. то, как он воспринимается со стороны системы. Акторы взаимодействуют с системой посредством передачи и приема сообщений от вариантов использования. Сообщение представляет собой запрос актором сервиса от системы и получение этого сервиса. Это взаимодействие может быть выражено посредством ассоциаций между отдельными акторами и вариантами использования. Кроме этого, с акторами могут быть связаны интерфейсы, которые определяют, каким образом другие элементы модели взаимодействуют с этими акторами.
Отношения на диаграмме вариантов использования
Между элементами диаграммы вариантов использования могут существовать различные отношения, которые описывают взаимодействие экземпляров одних акторов и вариантов использования с экземплярами других акторов и вариантов. Один актор может взаимодействовать с несколькими вариантами использования. В этом случае этот актор обращается к нескольким сервисам данной системы. В свою очередь один вариант использования может взаимодействовать с несколькими акторами, предоставляя для всех них свой сервис.
В то же время два варианта использования, определенные в рамках одной моделируемой системы, также могут взаимодействовать друг с другом, однако характер этого взаимодействия будет отличаться от взаимодействия с акторами. В обоих случаях способы взаимодействия элементов модели предполагают обмен сигналами или сообщениями, которые инициируют реализацию функционального поведения моделируемой системы.
В языке UML имеется несколько стандартных видов отношений между акторами и вариантами использования:
Отношение ассоциации – одно из фундаментальных понятий в языке UML и в той или иной степени используется при построении всех графических моделей систем в форме канонических диаграмм. Применительно к диаграммам вариантов использования ассоциация служит для обозначения специфической роли актора при его взаимодействии с отдельным вариантом использования. На диаграмме вариантов использования отношение ассоциации обозначается сплошной линией между актором и вариантом использования. Эта линия может иметь некоторые дополнительные обозначения, например, имя и кратность.
В контексте диаграммы вариантов использования отношение ассоциации между актором и вариантом использования может указывать на то, что актор инициирует соответствующий вариант использования. Такого актора называют главным. В других случаях подобная ассоциация может указывать на актора, которому предоставляется справочная информация о результатах функционирования моделируемой системы. Таких акторов часто называют второстепенными.
Включение (include) в языке UML — это разновидность отношения зависимости между базовым вариантом использования и его специальным случаем. При этом отношением зависимости (dependency) является такое отношение между двумя элементами модели, при котором изменение одного элемента (независимого) приводит к изменению другого элемента (зависимого).
Отношение включения устанавливается только между двумя вариантами использования и указывает на то, что заданное поведение для одного варианта использования включается в качестве составного фрагмента в последовательность поведения другого варианта использования.
Так, например, отношение включения, направленное от варианта использования «Предоставление кредита в банке» к варианту использования «Проверка платежеспособности клиента», указывает на то, что каждый экземпляр первого варианта использования всегда включает в себя функциональное поведение или выполнение второго варианта использования. В этом смысле поведение второго варианта использования является частью поведения первого варианта использования на данной диаграмме. Графически данное отношение обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от базового варианта использования к включаемому варианту использования. При этом данная линия помечается стереотипом «include».
Семантика этого отношения определяется следующим образом. Процесс выполнения базового варианта использования включает в себя, как собственное, подмножество последовательность действий, которая определена для включаемого варианта использования. При этом выполнение включаемой последовательности действий происходит всегда при инициировании базового варианта использования.
Один вариант использования может входить в несколько других вариантов, а также содержать в себе другие варианты. Включаемый вариант использования является независимым от базового варианта в том смысле, что он предоставляет последнему инкапсулированное поведение, детали реализации которого скрыты от последнего и могут быть легко перераспределены между несколькими включаемыми вариантами использования. Более того, базовый вариант зависит только от результатов выполнения включаемого в него варианта использования, но не от структуры включаемых в него вариантов.
В нашем случае прецедент «оплатить заказ» на входе получает список товаров (причем не важно откуда, от клиента в магазине или от онлайн-покупателя на сайте).
Отношение расширения (extend) определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого задействуется базовым не всегда, а только при выполнении дополнительных условий.
В языке UML отношение расширения является зависимостью, направленной к базовому варианту использования и соединенной с ним в так называемой точке расширения. Отношение расширения между вариантами использования обозначается как отношение зависимости в форме пунктирной линии со стрелкой, направленной от того варианта использования, который является расширением для базового варианта использования. Данная линия со стрелкой должна быть помечена стереотипом «extend».
В нашем случае, при оплате в магазине доступны оба расширения, а при оплате на сайте только оплата картой (на самом деле второй вариант сложнее: нужно выделить отдельный прецедент «онлайн оплата» с расширениями «оплата картой», «оплата при получении» и т.п.)
Два и более актора могут иметь общие свойства, т.е. взаимодействовать с одним и тем же множеством вариантов использования одинаковым образом. Такая общность свойств и поведения представляется в виде отношения обобщения с другим, возможно, абстрактным актором, который моделирует соответствующую общность ролей.
Графически отношение обобщения обозначается сплошной линией со стрелкой в форме незакрашенного треугольника, которая указывает на родительский вариант использования.
Рассматривая наш магазин при автосервисе, мы можем применить обобщение для закупок запчастей при тех.обслуживании автомобиля. Понятно, что делает это не клиент, а внутренняя служба, которая потом просто выставляет счёт со списком запчастей (и это еще один прецедент к варианту оплаты).
НИ В КОЕМ СЛУЧАЕ НЕ ИСПОЛЬЗУЙТЕ ЭТУ ДИАГРАММУ КАК ПРИМЕР ДЛЯ ПОДРАЖАНИЯ. Это первый «сырой» вариант, как минимум автосервис нужно выносить в отдельную подсистему и прецедент «покупка запчастей» инициируется менеджером автосервиса, а не сам по себе.
Мы рассмотрели только базовые элементы для диаграммы вариантов использования, на самом деле их больше. Но для нашего уровня обучения этого достаточно.