В программной и системной инженерии фраза вариант использования является полисемой с двумя смыслами :
В этой статье обсуждается последнее значение. (Более подробную информацию о другом значении см., например, в разделе «Персона пользователя» .)
Вариант использования — это список действий или шагов событий, обычно определяющих взаимодействия между ролью (известной в унифицированном языке моделирования (UML) как актор ) и системой для достижения цели. Актором может быть человек или другая внешняя система. В системной инженерии варианты использования используются на более высоком уровне, чем в программной инженерии , часто представляя миссии или цели заинтересованных сторон . Подробные требования затем могут быть зафиксированы в системном языке моделирования (SysML) или в виде договорных утверждений.
В 1987 году Ивар Якобсон представил первую статью о вариантах использования на конференции OOPSLA '87. [1] Он описал, как эта техника использовалась в Ericsson для сбора и указания требований к системе с использованием текстовых, структурных и визуальных методов моделирования для управления объектно-ориентированным анализом и проектированием. [2] Первоначально он использовал термины сценарии использования и вариант использования (последний был прямым переводом его шведского термина användningsfall ), но обнаружил, что ни один из этих терминов не звучит естественно на английском языке, и в конечном итоге он остановился на варианте использования (use case) . [3]
В 1992 году он стал соавтором книги Object-Oriented Software Engineering - A Use Case Driven Approach [ 4] , которая заложила основу метода системной инженерии OOSE и помогла популяризировать варианты использования для сбора функциональных требований , особенно в разработке программного обеспечения . В 1994 году он опубликовал книгу о вариантах использования и объектно-ориентированных методах, применяемых к бизнес-моделям и реинжинирингу бизнес-процессов . [5]
В то же время Грэди Буч и Джеймс Рамбо работали над объединением своих методов объектно-ориентированного анализа и проектирования , метода Буча и метода объектного моделирования (OMT) соответственно. В 1995 году к ним присоединился Ивар Якобсон, и вместе они создали Унифицированный язык моделирования (UML) , который включает моделирование вариантов использования. UML был стандартизирован Object Management Group (OMG) в 1997 году. [6] Якобсон, Буч и Рамбо также работали над усовершенствованием процесса разработки программного обеспечения Objectory . Полученный Унифицированный процесс был опубликован в 1999 году и продвигал подход, основанный на вариантах использования. [7]
С тех пор многие авторы внесли свой вклад в развитие этой методики, в частности: Ларри Константин разработал в 1995 году в контексте дизайна, ориентированного на использование , так называемые «основные варианты использования», которые направлены на описание намерений пользователя, а не последовательности действий или сценариев, которые могут ограничивать или искажать дизайн пользовательского интерфейса; [8] Алистер Кокберн опубликовал в 2000 году ориентированную на цель практику вариантов использования, основанную на текстовых повествованиях и табличных спецификациях; [9] Курт Биттнер и Ян Спенс разработали в 2002 году передовые методы анализа функциональных требований с вариантами использования; [10] Дин Леффингвелл и Дон Видриг предложили применять варианты использования для управления изменениями и мероприятий по взаимодействию с заинтересованными сторонами; [11] Гуннар Овергаард предложил в 2004 году распространить принципы шаблонов проектирования на варианты использования. [12]
В 2011 году Якобсон совместно с Яном Спенсом и Куртом Биттнером опубликовал электронную книгу Use Case 2.0, чтобы адаптировать эту технику к контексту гибкой разработки, обогатив ее постепенными «срезами» вариантов использования и продвигая ее использование на протяжении всего жизненного цикла разработки [13] после представления обновленного подхода на ежегодной конференции IIBA. [14] [15]
Варианты использования — это метод фиксации, моделирования и спецификации требований системы. [10] Вариант использования соответствует набору поведений, которые система может выполнять во взаимодействии со своими акторами, и которые производят наблюдаемый результат, способствующий достижению ее целей. Актеры представляют роль, которую играют пользователи-люди или другие системы во взаимодействии.
В анализе требований , при их идентификации, вариант использования именуется в соответствии с конкретной целью пользователя, которую он представляет для своего основного субъекта. Вариант далее детализируется с помощью текстового описания или дополнительных графических моделей, которые объясняют общую последовательность действий и событий, а также варианты, такие как особые условия, исключения или ситуации с ошибками.
Согласно Своду знаний по программной инженерии (SWEBOK) [16] , варианты использования относятся к методам выявления требований на основе сценариев , а также к методам анализа на основе моделей . Но варианты использования также поддерживают сбор требований на основе повествования, инкрементальное приобретение требований, системную документацию и приемочное тестирование. [1]
Существуют различные варианты использования и вариации этой техники:
Область применения варианта использования может быть определена субъектом и целями:
Известно, что варианты использования применяются в следующих контекстах:
Существует множество способов написать вариант использования в тексте, от краткого варианта использования , повседневного , плана до полностью оформленного и т. д., и с различными шаблонами. Написание вариантов использования в шаблонах, разработанных различными поставщиками или экспертами, является обычной отраслевой практикой для получения высококачественных функциональных системных требований.
Шаблон, определенный Алистером Кокберном в его книге «Написание эффективных вариантов использования», стал одним из наиболее широко используемых стилей описания вариантов использования. [ необходима ссылка ]
Кокберн предлагает аннотировать каждый вариант использования символом, показывающим «Область проектирования», который может быть черным ящиком (внутренние детали скрыты) или белым ящиком (внутренние детали показаны). Доступно пять символов: [20]
Другие авторы иногда называют варианты использования на уровне организации «бизнес-вариантами использования». [21]
Кокберн предлагает аннотировать каждый вариант использования символом, показывающим «уровень цели»; [22] предпочтительным уровнем является «цель пользователя» (или, говоря простым языком, «уровень моря» [23] : 101 ).
Иногда при написании текста название варианта использования, за которым следует альтернативный текстовый символ (! +, - и т. д.), является более кратким и удобным способом обозначения уровней, например, разместить заказ! , войти в систему- .
Кокберн описывает более подробную структуру для варианта использования, но позволяет упростить его, когда требуется меньше деталей. Его полностью одетый шаблон варианта использования содержит следующие поля: [24]
Кроме того, Кокберн предлагает использовать два инструмента для обозначения характера каждого варианта использования: значки для области проектирования и уровня цели.
Подход Кокберна оказал влияние на других авторов; например, Александер и Беус-Дукич обобщают шаблон «Полностью готовый вариант использования» Кокберна с программного обеспечения на системы всех видов, при этом следующие поля отличаются от Кокберна: [26]
Кокберн признает, что проекты не всегда нуждаются в подробных "полностью одетых" вариантах использования. Он описывает случайный вариант использования с полями: [24]
Мартин Фаулер утверждает: «Не существует стандартного способа описания содержания варианта использования, и в разных случаях хорошо работают разные форматы». [23] : 100 Он описывает «общий стиль использования» следующим образом: [23] : 101
Стиль Фаулера можно также рассматривать как упрощенный вариант шаблона Кокберна. Этот вариант называется пользовательской историей .
Алистер Кокберн заявил: [27]
Подумайте о пользовательской истории как о варианте использования с точностью 2 бита. Бит 1 точности называет цель варианта использования, а бит 2 добавляет основной сценарий. Бит 3 добавляет условия отказа, бит 4 добавляет действия при отказе. Бит 5 добавляет описание данных входящих/исходящих данных. Я бы поставил Catalysis на 6-й бит точности, так как они также включают модель получателя сообщения. В семействе CrystalMethodology по-разному основанные проекты используют варианты использования с разной степенью точности. Методологически легкий проект использует пользовательские истории, методологически более тяжелый проект использует варианты использования с точностью 4 бита, а Catalysis использует точность 6 бит.
Мартин Фаулер заявил: [27]
Все дело в том, как люди используют кейсы. Я видел, как многие люди используют кейсы очень формализованным образом. Кент делает свои UserStories гораздо более доступным образом. Я использую кейсы так, как Кент делает User Stories. Я называю их use cases, чтобы лучше общаться с другими разработчиками и влиять на них, чтобы использовать более легкий подход.
Вариант использования определяет взаимодействия между внешними субъектами и рассматриваемой системой для достижения цели. Субъекты должны иметь возможность принимать решения, но не обязательно быть людьми: «Актёр может быть человеком, компанией или организацией, компьютерной программой или компьютерной системой — оборудованием, программным обеспечением или и тем, и другим». [28] Субъекты всегда являются заинтересованными сторонами , но не все заинтересованные стороны являются акторами, поскольку они могут «никогда не взаимодействовать напрямую с системой, хотя у них есть право заботиться о том, как система себя ведёт». [28] Например, «владельцы системы, совет директоров компании и регулирующие органы, такие как Налоговая служба и Департамент страхования» могут быть заинтересованными сторонами, но вряд ли будут акторами. [28]
Аналогично, человек, использующий систему, может быть представлен как другой актер, поскольку играет разные роли. Например, пользователь «Джо» может играть роль Клиента при использовании банкомата для снятия наличных со своего счета или роль Банковского кассира при использовании системы для пополнения денежного ящика от имени банка.
Актеры часто работают от имени кого-то другого. Кокберн пишет, что «В эти дни я пишу «торговый представитель для клиента» или «клерк для отдела маркетинга», чтобы зафиксировать, что пользователь системы действует для кого-то другого». Это говорит проекту, что «пользовательский интерфейс и допуски безопасности» должны быть разработаны для торгового представителя и клерка, но что клиенты и отдел маркетинга — это роли, которые обеспокоены результатами. [29]
Заинтересованная сторона может играть как активную, так и неактивную роль: например, Потребитель является одновременно «покупателем массового рынка» (не взаимодействующим с системой) и Пользователем (актором, активно взаимодействующим с приобретенным продуктом). [30] В свою очередь, Пользователь является одновременно «обычным оператором» (актором, использующим систему по назначению) и «функциональным бенефициаром» (заинтересованная сторона, получающая выгоду от использования системы). [30] Например, когда пользователь «Джо» снимает наличные со своего счета, он управляет банкоматом и получает результат от своего имени.
Кокберн советует искать действующих лиц среди заинтересованных сторон системы, основных и вспомогательных (вторичных) действующих лиц варианта использования, самой проектируемой системы (SuD) и, наконец, среди «внутренних действующих лиц», а именно компонентов проектируемой системы. [28]
Точно так же, как вариант использования описывает ряд событий и взаимодействий между пользователем (или другими типами субъектов) и системой для получения результата, представляющего ценность (цель), вариант использования бизнеса описывает более общее взаимодействие между бизнес-системой и пользователями/субъектами этой системы для получения бизнес-результатов, представляющих ценность. Основное отличие заключается в том, что система, рассматриваемая в модели варианта использования бизнеса, может содержать людей в дополнение к технологическим системам. Эти «люди в системе» называются бизнес-работниками. В примере с рестораном необходимо принять решение, рассматривать ли каждого человека как субъекта (то есть вне системы) или как бизнес-работника (внутри системы). Если официант считается субъектом, как показано в примере ниже, то система ресторана не включает официанта, и модель раскрывает взаимодействие между официантом и рестораном. Альтернативой было бы рассматривать официанта как часть системы ресторана (бизнес-работника), при этом считая клиента находящимся вне системы (субъектом). [31]
Варианты использования — это не только тексты, но и диаграммы, если необходимо. В унифицированном языке моделирования отношения между вариантами использования и субъектами представлены в диаграммах вариантов использования, изначально основанных на нотации объектов Ивара Якобсона . SysML использует ту же нотацию на уровне системных блоков.
Кроме того, другие поведенческие диаграммы UML, такие как диаграммы активности , диаграммы последовательности , диаграммы связи и диаграммы конечного автомата , также могут использоваться для визуализации вариантов использования соответствующим образом. В частности, диаграмма последовательности системы (SSD) — это диаграмма последовательности, часто используемая для отображения взаимодействий между внешними субъектами и проектируемой системой (SuD), обычно для визуализации конкретного сценария варианта использования.
Анализ вариантов использования обычно начинается с рисования диаграмм вариантов использования. Для гибкой разработки модель требований из множества диаграмм UML, изображающих варианты использования, плюс некоторые текстовые описания, заметки или краткие описания вариантов использования были бы очень легкими и достаточными для небольших или простых проектов. Как хорошее дополнение к текстам вариантов использования, визуальные представления вариантов использования в виде диаграмм также являются эффективными инструментами для лучшего понимания, коммуникации и проектирования сложных поведенческих требований системы.
Ниже приведен пример варианта использования, написанный с использованием слегка измененной версии шаблона в стиле Кокберна. Обратите внимание, что в базовом описании варианта использования нет кнопок, элементов управления, форм или других элементов пользовательского интерфейса и операций, где на каждом шаге базового потока или расширений выражаются только цели, подцели или намерения пользователя. Такая практика делает спецификацию требований более ясной и максимизирует гибкость проектирования и реализации.
Вариант использования : Редактирование статьи
Основное действующее лицо : Участник (зарегистрированный пользователь)
Область применения : система Wiki
Уровень : ! (Цель пользователя или уровень моря)
Краткая информация : (эквивалент пользовательской истории или эпоса)
Заинтересованные стороны
...
Постусловия
Предпосылки :
Триггеры :
Основной поток :
Расширения :
2–3.
4а. Тайм-аут:
...
С момента зарождения движения Agile метод пользовательских историй из Extreme Programming стал настолько популярен, что многие считают его единственным и лучшим решением для Agile-требований всех проектов. Алистер Кокберн перечисляет пять причин, по которым он до сих пор пишет сценарии использования в Agile-разработке . [32]
Подводя итог, можно сказать, что указание системных требований в вариантах использования имеет следующие очевидные преимущества по сравнению с традиционными или другими подходами:
Ориентирован на пользователя
Варианты использования представляют собой мощный, ориентированный на пользователя инструмент для процесса спецификации требований к программному обеспечению. [33] Моделирование вариантов использования обычно начинается с определения ключевых ролей заинтересованных сторон ( актеров ), взаимодействующих с системой, и их целей или задач, которые система должна выполнять (внешняя перспектива). Затем эти цели пользователя становятся идеальными кандидатами для имен или названий вариантов использования, которые представляют желаемые функциональные возможности или услуги, предоставляемые системой. Этот ориентированный на пользователя подход гарантирует, что разрабатывается то, что имеет реальную ценность для бизнеса и действительно нужно пользователю, а не те тривиальные функции, которые предполагаются с точки зрения разработчика или системы (изнутри).
Разработка вариантов использования уже много лет является важным и ценным инструментом анализа в области проектирования, ориентированного на пользователя (UCD) .
Лучшая коммуникация
Сценарии использования часто пишутся на естественных языках с использованием структурированных шаблонов. Эта повествовательная текстовая форма (разборчивые истории требований), понятная почти всем и дополненная визуальными диаграммами UML, способствует лучшему и более глубокому общению между всеми заинтересованными сторонами, включая клиентов, конечных пользователей, разработчиков, тестировщиков и менеджеров. Лучшая коммуникация приводит к качественным требованиям и, следовательно, к качественным поставляемым системам.
Требования к качеству структурированного исследования
Одна из самых мощных вещей в вариантах использования заключается в форматах шаблонов вариантов использования, особенно в основном сценарии успеха (базовый поток) и фрагментах сценариев расширения (расширения, исключительные и альтернативные потоки). Пошаговый анализ варианта использования от предварительных условий до постусловий, изучение и расследование каждого шага действия потоков вариантов использования, от базовых до расширений, для выявления сложных, обычно скрытых и игнорируемых, кажущихся тривиальными, но на самом деле часто дорогостоящих требований (как упомянул выше Кокберн), является структурированным и полезным способом систематического получения четких, стабильных и качественных требований.
Минимизация и оптимизация шагов действия варианта использования для достижения цели пользователя также способствуют лучшему проектированию взаимодействия и пользовательскому опыту системы.
Упрощение тестирования и пользовательской документации
С контентом, основанным на структуре потока действий или событий, модель хорошо написанных вариантов использования также служит отличной основой и ценными рекомендациями для проектирования тестовых случаев и руководств пользователя системы или продукта, что является стоящей инвестиций на начальном этапе. Существуют очевидные связи между путями потока варианта использования и его тестовыми случаями. Выведение функциональных тестовых случаев из варианта использования через его сценарии (запуск экземпляров варианта использования) является простым. [34]
Ограничения вариантов использования включают в себя:
Распространенные заблуждения относительно вариантов использования:
Истории пользователей гибки, а вот варианты использования — нет.
Agile и Scrum нейтральны в отношении требований к методам. Как гласит Scrum Primer [39] ,
Элементы Product Backlog сформулированы любым понятным и устойчивым способом. Вопреки распространенному заблуждению, Product Backlog не содержит «пользовательские истории»; он просто содержит элементы. Эти элементы могут быть выражены как пользовательские истории, варианты использования или любой другой подход к требованиям, который группа считает полезным. Но какой бы подход ни использовался, большинство элементов должны быть сосредоточены на предоставлении ценности клиентам.
Методы вариантов использования развились с целью учета подходов Agile путем использования фрагментов вариантов использования для постепенного обогащения варианта использования. [13]
Варианты использования в основном представлены в виде диаграмм.
Крейг Ларман подчеркивает, что «варианты использования — это не диаграммы, это текст». [40]
В вариантах использования слишком много контента, связанного с пользовательским интерфейсом.
Как некоторые говорят, [ кто? ]
Варианты использования часто содержат такой уровень детализации (например, наименование меток и кнопок), что делает их неподходящими для определения требований к новой системе с нуля.
Недоразумения новичков. Каждый шаг хорошо написанного варианта использования должен представлять цели или намерения субъекта (сущность функциональных требований), и обычно он не должен содержать никаких деталей пользовательского интерфейса, например, наименования меток и кнопок, операций пользовательского интерфейса и т. д., что является плохой практикой и неоправданно усложнит написание варианта использования и ограничит его реализацию.
Что касается сбора требований к новой системе с нуля, диаграммы вариантов использования и краткие описания вариантов использования часто используются как удобные и ценные инструменты, по крайней мере такие же легкие, как пользовательские истории. [ необходима цитата ]
Написание сценариев использования для больших систем — утомительное занятие и пустая трата времени.
Как некоторые говорят, [ кто? ]
Формат варианта использования затрудняет описание большой системы (например, CRM-системы) менее чем на нескольких сотнях страниц. Это отнимает много времени, и вы обнаружите, что тратите время на ненужную переделку.
Тратить много времени на написание утомительных вариантов использования, которые не добавляют никакой или мало ценности и приводят к большому количеству переделок, — это плохой запах, указывающий на то, что писатели не очень квалифицированы и не имеют достаточных знаний о том, как писать качественные варианты использования эффективно и действенно. Варианты использования должны создаваться итеративным, инкрементальным и эволюционным ( agile ) способом. Применение шаблонов вариантов использования не означает, что все поля шаблона варианта использования должны использоваться и заполняться исчерпывающим образом с самого начала или во время специального выделенного этапа, т. е. фазы требований в традиционной модели каскадной разработки.
Фактически, форматы вариантов использования, сформулированные этими популярными стилями шаблонов, например, RUP и Cockburn (также принятые методом OUM ) и т. д., на практике доказали свою ценность и полезность в качестве инструментов для сбора, анализа и документирования сложных требований больших систем. Качество хорошей документации варианта использования ( модели ) не следует оценивать в основном или только по ее размеру. Также возможно, что качественная и всеобъемлющая модель варианта использования большой системы может в конечном итоге развиться до сотен страниц, в основном из-за присущей сложности рассматриваемой проблемы , а не из-за плохих навыков письма ее авторов. [ необходима цитата ]
Для написания вариантов использования часто используются текстовые редакторы и/или текстовые процессоры с поддержкой шаблонов. Для больших и сложных системных требований полезны специальные инструменты для вариантов использования.
Некоторые из известных инструментов вариантов использования включают в себя:
Большинство инструментов UML поддерживают как написание текста, так и визуальное моделирование вариантов использования.