Что определяют варианты использования

UML — диаграмма вариантов использования (use case diagram)

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

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

Вариант использования (use case)

В данном примере вариант использования Part включается в вариант использования Base.

В данном примере вариант использования Base расширяется вариантом использования Another.

В данном примере вариант использования Child обобщает вариант использования Base.

Действующее лицо (actor)

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

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

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

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

Источник

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

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

Назначение

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

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

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

Один и тот же прецедент может быть описан с различной степенью детализации.

В 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 … Википедия

Источник

Что такое use case? Теория и примеры

Use case (также юзкейс, сценарий использования) – это сценарий взаимодействия пользователя (или пользователей) с программным продуктом для достижения конкретной цели.

Юзкейсы содержат следующие сведения:

Юзкейсы не содержат детали реализации, а также описания пользовательского интерфейса или экранов.

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

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

Элементы use case

Юзкейсы могут содержать следующие элементы (их количество зависит от сложности сценария):

Как написать use case?

Шаги в юзкейсе описываются максимально понятно. Что касается самих шагов, они могут быть следующими:

Пример use case

В этом юзкейсе изложен сценарий входа пользователя в школьную систему.

Юзкейс-диаграммы

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

Пример диаграммы для юзкейсов входа в школьную систему:

Зачем нужны use case?

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

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

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

Юзкейсы — отличная основа для формирования тест-кейсов. Это, по сути, пригодные для тестирования требования с понятной целью и путями ее достижения. Тестирование по сценариям использования (use case testing) позволяет обнаружить в приложении недостатки, которые сложно найти, например, при юнит-тестировании.

Источник

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

Диаграмма вариантов использования как концептуальное представление бизнес-системы в процессе ее разработки.

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

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

Имя (name) — строка текста, которая используется для идентификации любого элемента модели.

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

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

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

Источник

Бизнес-анализ — варианты использования

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

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

Актер — это Кто в системе, другими словами, он конечный пользователь.

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

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

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

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

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

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

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

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

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

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

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

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

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

Имя : Описательное имя, которое иллюстрирует цель варианта использования.

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

Актер : Перечислите любых актеров, которые участвуют в сценарии использования.

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

Поток событий : описание взаимодействия между системой и актером.

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

Руководство для шаблона использования

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

Идентификация варианта использования

Идентификатор варианта использования — присвойте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования можно сгруппировать в иерархии. Функциональные требования можно проследить до обозначенного варианта использования.

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

Просмотр информации о номере детали.

Вручную пометьте источник гипертекста и установите ссылку на цель.

Сделайте заказ на компакт-диск с обновленной версией программного обеспечения.

Идентификатор варианта использования — присвойте каждому варианту использования уникальный числовой идентификатор в иерархической форме: XY Связанные варианты использования можно сгруппировать в иерархии. Функциональные требования можно проследить до обозначенного варианта использования.

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

Просмотр информации о номере детали.

Вручную пометьте источник гипертекста и установите ссылку на цель.

Сделайте заказ на компакт-диск с обновленной версией программного обеспечения.

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

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

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

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

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

Дата последнего обновления — введите дату последнего использования варианта использования.

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

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

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

Дата последнего обновления — введите дату последнего использования варианта использования.

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

Ниже приведены определения ключевых концепций варианта использования.

Актер

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

Описание

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

Предпосылками

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

Условия размещения

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

приоритет

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

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

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

Нормальный ход событий

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

Документируйте другие, законные сценарии использования, которые могут иметь место в этом сценарии использования отдельно в этом разделе. Укажите альтернативный курс и опишите любые различия в последовательности шагов. Пронумеруйте каждый альтернативный курс, используя идентификатор прецедента, а затем «AC», чтобы указать «Альтернативный курс». Пример: XYAC.1.

Исключения

Опишите любые ожидаемые ошибки, которые могут возникнуть во время выполнения сценария использования, и определите, как система должна реагировать на эти условия. Кроме того, опишите, как система должна реагировать в случае сбоя при выполнении варианта использования по какой-то непредвиденной причине. Пронумеруйте каждое исключение, используя ID прецедента в качестве префикса, затем «EX» для обозначения «Exception». Пример: XYEX.1.

Включает в себя

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

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

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

Предположения

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

Примечания и проблемы

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

Управление изменениями и контроль версий

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

Источник