В программной и системной инженерии словосочетание вариант использования является многозначным и имеет два значения :
В этой статье обсуждается последний смысл. (Подробнее о другом значении см., например, в разделе «Персона пользователя »).
Вариант использования — это список действий или шагов событий, обычно определяющих взаимодействие между ролью (известной в унифицированном языке моделирования (UML) как актер ) и системой для достижения цели. Действующим лицом может быть человек или другая внешняя система. В системной инженерии варианты использования используются на более высоком уровне, чем в разработке программного обеспечения , часто отражая миссии или цели заинтересованных сторон . Подробные требования затем могут быть отражены на языке системного моделирования (SysML) или в виде договорных положений.
В 1987 году Ивар Джейкобсон представил первую статью о вариантах использования на конференции OOPSLA '87. [1] Он описал, как этот метод использовался в Ericsson для сбора и определения требований к системе с использованием методов текстового, структурного и визуального моделирования для реализации объектно-ориентированного анализа и проектирования. [2] Первоначально он использовал термины « сценарии использования» и «вариант использования » (последний является прямым переводом его шведского термина användningsfall ), но обнаружил, что ни один из этих терминов не звучит естественно на английском языке, и в конечном итоге он остановился на варианте использования . [3]
В 1992 году он стал соавтором книги « Объектно-ориентированная разработка программного обеспечения — подход, основанный на сценариях использования» , [4] , которая заложила основу метода системного проектирования OOSE и помогла популяризировать варианты использования для фиксации функциональных требований , особенно в разработке программного обеспечения . В 1994 году он опубликовал книгу о вариантах использования и объектно-ориентированных методах, применяемых к бизнес-моделям и реинжинирингу бизнес-процессов . [5]
В то же время Грэди Буч и Джеймс Рамбо работали над унификацией своих методов объектно-ориентированного анализа и проектирования — метода Буча и техники объектного моделирования (OMT) соответственно. В 1995 году к ним присоединился Ивар Якобсон, и вместе они создали унифицированный язык моделирования (UML) , включающий моделирование вариантов использования. UML был стандартизирован Группой управления объектами (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 добавляет описание данных ввода/вывода. Я бы поставил Катализ на 6-й бит точности, так как они включают в себя еще и модель получателя сообщения. В семействе CrystalMethodology проекты, основанные по-разному, используют варианты с разными уровнями точности. Методологически легкий проект использует пользовательские истории, методологически более тяжелый проект использует варианты использования с точностью до 4 бит, а Catalysis использует точность до 6 бит.
Мартин Фаулер заявил: [27]
Все дело в том, как люди используют кейсы. Я видел, как многие люди использовали прецеденты очень формализованно. Кент создает свои UserStories гораздо более доступным способом. Я использую кейсы так же, как Кент использует пользовательские истории. Я призываю их использовать варианты, чтобы лучше общаться с другими разработчиками и побуждать их использовать более упрощенный подход.
Вариант использования определяет взаимодействие между внешними участниками и рассматриваемой системой для достижения цели. Актеры должны иметь возможность принимать решения, но не обязательно быть людьми: «Актером может быть человек, компания или организация, компьютерная программа или компьютерная система — аппаратное обеспечение, программное обеспечение или и то, и другое». [28] Субъекты всегда являются заинтересованными сторонами , но не все заинтересованные стороны являются акторами, поскольку они могут «никогда не взаимодействовать напрямую с системой, даже если они имеют право заботиться о том, как ведет себя система». [28] Например, «владельцы системы, совет директоров компании и регулирующие органы, такие как Налоговая служба и Департамент страхования» — все могут быть заинтересованными сторонами, но вряд ли будут действующими лицами. [28]
Аналогичным образом, человек, использующий систему, может быть представлен как другой актер, поскольку он играет разные роли. Например, пользователь «Джо» может играть роль Клиента при использовании банкомата для снятия наличных со своего счета или играть роль банковского кассира при использовании системы для пополнения запасов кассы от имени банка. .
Актеры часто работают от имени кого-то другого. Кокберн пишет: «В наши дни я пишу «торговый представитель клиента» или «клерк отдела маркетинга», чтобы понять, что пользователь системы действует от имени кого-то другого». Это говорит проекту о том, что «пользовательский интерфейс и уровень доступа» должны быть разработаны для торгового представителя и клерка, но что роли, которые заботятся о результатах, — это отдел обслуживания клиентов и маркетинга. [29]
Заинтересованная сторона может играть как активную, так и неактивную роль: например, Потребитель является одновременно «массовым покупателем» (не взаимодействующим с системой) и Пользователем (актером, активно взаимодействующим с приобретаемым продуктом). [30] В свою очередь, Пользователь является одновременно «обычным оператором» (субъектом, использующим систему по назначению), и «функциональным бенефициаром» (заинтересованной стороной, получающей выгоду от использования системы). [30] Например, когда пользователь «Джо» снимает наличные со своего счета, он управляет банкоматом и получает результат от своего имени.
Кокберн советует искать действующих лиц среди заинтересованных сторон системы, первичных и вспомогательных (вторичных) действующих лиц варианта использования, самой проектируемой системы (SuD) и, наконец, среди «внутренних действующих лиц», а именно компонентов разрабатываемой системы. дизайн. [28]
Точно так же, как вариант использования описывает серию событий и взаимодействий между пользователем (или другими типами субъектов) и системой, чтобы получить ценный результат (цель), вариант использования для бизнеса описывает более общее взаимодействие. между бизнес-системой и пользователями/субъектами этой системы для получения ценных бизнес-результатов. Основное отличие состоит в том, что система, рассматриваемая в модели бизнес-использования, помимо технологических систем может содержать людей. Этих «людей в системе» называют бизнес-работниками. В примере с рестораном необходимо принять решение, относиться ли к каждому человеку как к действующему лицу (то есть вне системы) или как к деловому работнику (внутри системы). Если официант считается действующим лицом, как показано в примере ниже, то ресторанная система не включает официанта, а модель отображает взаимодействие между официантом и рестораном. Альтернативой было бы рассматривать официанта как часть ресторанной системы (бизнес-работника), а клиента – как вне системы (актера). [31]
Варианты использования — это не только тексты, но и диаграммы, если это необходимо. В Unified Modeling Language отношения между вариантами использования и субъектами представлены в диаграммах вариантов использования, первоначально основанных на нотации Objectory Ивара Джейкобсона . SysML использует ту же нотацию на уровне системного блока.
Кроме того, для соответствующей визуализации вариантов использования также можно использовать другие поведенческие диаграммы UML, такие как диаграммы деятельности , диаграммы последовательности , диаграммы связи и диаграммы конечных автоматов . В частности, диаграмма последовательности системы (SSD) — это диаграмма последовательности, часто используемая для отображения взаимодействия между внешними участниками и проектируемой системой (SuD), обычно для визуализации конкретного сценария варианта использования.
Анализ вариантов использования обычно начинается с построения диаграмм вариантов использования. Для гибкой разработки модель требований, состоящая из множества UML-диаграмм, изображающих варианты использования, а также некоторых текстовых описаний, примечаний или кратких описаний вариантов использования, будет очень легкой и достаточной для небольшого или простого использования в проекте. Являясь хорошим дополнением к текстам вариантов использования, визуальные диаграммы вариантов использования также являются эффективными инструментами, способствующими лучшему пониманию, общению и разработке требований к поведению сложных систем.
Ниже приведен пример варианта использования, написанный с использованием слегка измененной версии шаблона в стиле Cockburn. Обратите внимание, что в базовом описании варианта использования нет кнопок, элементов управления, форм или любых других элементов и операций пользовательского интерфейса, где на каждом этапе базового потока или расширений выражаются только цели, подцели или намерения пользователя. Такая практика делает спецификацию требований более четкой и максимизирует гибкость проектирования и реализации.
Вариант использования : редактирование статьи.
Основной участник : Участник (зарегистрированный пользователь)
Область применения : система Wiki.
Уровень : ! (Цель пользователя или уровень моря)
Краткое описание : (эквивалент пользовательской истории или эпоса)
Заинтересованные стороны
...
Постусловия
Предварительные условия :
Триггеры :
Основной поток :
Расширения :
2–3.
4а. Тайм-аут:
...
С момента зарождения гибкого движения техника пользовательских историй из «Экстремального программирования» стала настолько популярной, что многие считают ее единственным и лучшим решением для гибких требований всех проектов. Алистер Кокберн перечисляет пять причин, по которым он до сих пор пишет сценарии использования в гибкой разработке . [32]
Подводя итог, определение системных требований в вариантах использования имеет следующие очевидные преимущества по сравнению с традиционными или другими подходами:
Ориентированный на пользователя
Варианты использования представляют собой мощный, ориентированный на пользователя инструмент для процесса спецификации требований к программному обеспечению. [33] Моделирование вариантов использования обычно начинается с определения ключевых ролей заинтересованных сторон ( актеров ), взаимодействующих с системой, а также их целей или задач, которые система должна выполнить (взгляд со стороны). Эти пользовательские цели затем становятся идеальными кандидатами на названия или названия вариантов использования, которые представляют желаемые функциональные возможности или услуги, предоставляемые системой. Такой подход, ориентированный на пользователя, гарантирует, что разрабатывается то, что имеет реальную бизнес-ценность и что действительно хочет пользователь, а не те тривиальные функции, которые предполагаются с точки зрения разработчика или системы (внутри).
Разработка вариантов использования уже много лет является важным и ценным инструментом анализа в области пользовательско-ориентированного проектирования (UCD) .
Лучшее общение
Варианты использования часто пишутся на естественных языках со структурированными шаблонами. Эта повествовательная текстовая форма (разборчивые истории требований), понятная практически каждому и дополненная визуальными UML-диаграммами, способствует улучшению и более глубокому общению между всеми заинтересованными сторонами, включая клиентов, конечных пользователей, разработчиков, тестировщиков и менеджеров. Улучшение коммуникации приводит к формированию требований к качеству и, следовательно, к созданию систем качества.
Требования к качеству при структурированной разведке
Одна из самых важных особенностей вариантов использования заключается в форматах шаблонов вариантов использования, особенно в основном сценарии успеха (базовый поток) и фрагментах сценария расширения (расширения, исключительные и альтернативные потоки). Анализ варианта использования шаг за шагом от предусловий до постусловий, изучение и исследование каждого шага действия в потоке вариантов использования, от базового до расширений, для выявления тех сложных, обычно скрытых и игнорируемых, кажущихся тривиальными, но на самом деле часто дорогостоящих требований (как упомянул Кокберн выше), представляет собой структурированный и полезный способ систематического получения четких, стабильных и качественных требований.
Минимизация и оптимизация шагов варианта использования для достижения цели пользователя также способствуют улучшению дизайна взаимодействия и улучшению пользовательского опыта системы.
Упрощение тестирования и пользовательской документации
Поскольку контент основан на структуре потока действий или событий, модель хорошо написанных вариантов использования также служит отличной основой и ценным руководством для разработки тестовых сценариев и руководств пользователя системы или продукта, что является достойным вложением усилий. -передний. Существуют очевидные связи между путями реализации варианта использования и его тестовыми примерами. Вывести функциональные тестовые сценарии из варианта использования через его сценарии (запуск экземпляров варианта использования) несложно. [34]
Ограничения вариантов использования включают в себя:
Распространенными заблуждениями относительно вариантов использования являются:
Пользовательские истории гибки; варианты использования - нет.
Agile и Scrum нейтральны в отношении методов требований. Как говорится в Scrum Primer [39] ,
Элементы бэклога продукта формулируются любым понятным и устойчивым способом. Вопреки распространенному заблуждению, Бэклог продукта не содержит «пользовательских историй»; он просто содержит элементы. Эти элементы могут быть выражены в виде пользовательских историй, вариантов использования или любого другого подхода к требованиям, который группа сочтет полезным. Но каким бы ни был подход, большинство продуктов должны быть направлены на предоставление ценности клиентам.
Методы сценариев использования были разработаны с учетом подходов Agile путем использования срезов вариантов использования для постепенного обогащения варианта использования. [13]
Варианты использования в основном представляют собой диаграммы.
Крейг Ларман подчеркивает, что «варианты использования — это не диаграммы, это текст». [40]
Варианты использования содержат слишком много контента, связанного с пользовательским интерфейсом.
Как выразились некоторые, [ кто? ]
Варианты использования часто содержат такой уровень детализации (т. е. присвоение имен меткам и кнопкам), что делает его неподходящим для определения требований к новой системе с нуля.
Недоразумения новичков. Каждый шаг хорошо написанного варианта использования должен представлять цели или намерения действующих лиц (суть функциональных требований) и, как правило, не должен содержать каких-либо деталей пользовательского интерфейса, например, наименований меток и кнопок, операций пользовательского интерфейса и т. д., что является плохая практика и излишне усложнит написание варианта использования и ограничит его реализацию.
Что касается сбора требований к новой системе с нуля, диаграммы вариантов использования и краткие описания вариантов использования часто используются как удобные и ценные инструменты, по крайней мере такие же легкие, как и пользовательские истории. [ нужна цитата ]
Написание вариантов использования для больших систем утомительно и является пустой тратой времени.
Как выразились некоторые, [ кто? ]
Формат варианта использования затрудняет описание большой системы (например, CRM-системы) менее чем на нескольких сотнях страниц. Это отнимает много времени, и вы обнаружите, что тратите время на ненужную переделку.
[ нужна цитата ]
Тратить много времени на написание утомительных вариантов использования, которые не приносят пользы или приносят мало пользы и приводят к большому количеству переделок, — это неприятный запах , указывающий на то, что авторы недостаточно квалифицированы и мало знают, как писать качественные варианты использования эффективно и действенно. Варианты использования должны разрабатываться итеративным, инкрементным и эволюционным ( гибким ) способом. Применение шаблонов вариантов использования не означает, что все поля шаблона варианта использования должны использоваться и полностью заполняться с самого начала или на специальном этапе, т. е. на этапе требований в традиционной водопадной модели разработки.
Фактически, форматы вариантов использования, сформулированные с помощью этих популярных стилей шаблонов, например, RUP и Cockburn (также принятых методом OUM ) и т. д., оказались на практике ценными и полезными инструментами для сбора, анализа и документирования сложных требований. больших систем. Качество хорошей документации варианта использования ( модели ) не следует оценивать в основном или только по ее размеру. Также возможно, что качественная и всеобъемлющая модель варианта использования большой системы может в конечном итоге превратиться в сотни страниц, главным образом из-за присущей сложности решаемой проблемы , а не из-за плохих навыков письма ее авторов. [ нужна цитата ]
Текстовые редакторы и/или текстовые процессоры с поддержкой шаблонов часто используются для написания вариантов использования. Для больших и сложных системных требований полезны специальные инструменты для сценариев использования.
Некоторые из известных инструментов сценариев использования включают в себя:
Большинство инструментов UML поддерживают как написание текста, так и визуальное моделирование вариантов использования.