Сценарий использования
Сценарий использования, вариант использования, прецедент использования (англ. use case) — в разработке программного обеспечения и системном проектировании это описание поведения системы, когда она взаимодействует с кем-то (или чем-то) из внешней среды. Система может отвечать на внешние запросы Актора (англ. actor, в русском языке ударение на первый слог; может применяться термин Актант), может сама выступать инициатором взаимодействия. Другими словами, сценарий использования описывает, «кто» и «что» может сделать с рассматриваемой системой, или что система может сделать с «кем» или «чем». Методика сценариев использования применяется для выявления требований к поведению системы, известных также как пользовательские и функциональные требования.
В системном проектировании сценарии использования применяются на более высоком уровне, чем при разработке программного обеспечения, часто представляя цели заинтересованных лиц или миссии. На стадии анализа требований сценарии использования могут быть преобразованы в ряд детальных требований и задокументированы с помощью диаграмм требований SysML или других подобных механизмов.
История
В 1986 году Ивар Якобсон, позже соавтор Унифицированного Языка Моделирования (UML) и Рационального Унифицированного Процесса (RUP), впервые сформулировал методику визуального моделирования для описания сценариев использования. Первоначально он использовал несколько иные термины — англ. usage scenarios и usage case, но ни один из них не был естественным для английского языка. И в конечном счете он остановился на термине use case — сценарий использования. После создания Якобсоном методики моделирования сценариев использования многие специалисты в области инженерии ПО поспособствовали улучшению этой методики, включая Курта Биттнера, , Ганнэра Овергарда, и Джери Шнайдера.
В течение 1990-х сценарии использования стали одной из самых распространенных методик документирования функциональных требований, особенно в объектно-ориентированной среде, откуда они и произошли. Но их применение не ограничивается объектно-ориентированными системами, поскольку сценарии использования не объектно-ориентированы по природе.
Цели сценариев использования
«Каждый сценарий использования сосредотачивается на описании того, как достигнуть цели или задачи. Для большинства программных проектов это означает, что потребуется множество сценариев использования, чтобы определить необходимый набор свойств новой системы. Степень формальности программного проекта и его стадии будет влиять на необходимый уровень детализации, для каждого сценария использования.»
Сценарии использования не должны путаться с понятием свойств системы (англ. Feature). Сценарий использования может быть связан с одним или более свойством системы, и свойство может быть связано с одним или более сценарием использования.
Сценарий использования определяет взаимодействия между внешними агентами и системой, направленные на достижение цели. Актор (англ. Actor) представляет собой роль, которую играет человек или вещь, взаимодействуя с системой. Один и тот же человек, использующий систему, может быть представлен как различные акторы, потому что они играют различные роли. Например, «Джек» может играть роль Клиента, использующего Банкомат, чтобы забрать наличные деньги, или играть роль Работника Банка, использующего систему для пополнения банкомата купюрами.
Сценарии использования рассматривают систему как «черный ящик», и взаимодействия с системой, включая системные ответы, описываются с точки зрения внешнего наблюдателя. Это преднамеренная политика, потому что это вынуждает автора сосредоточиться на том, что система должна сделать, а не как это должно быть сделано, и позволяет избегать создания предположений о том, как функциональные возможности будут реализованы.
Сценарии использования могут быть описаны на абстрактном уровне, описывающем часть предметной области (бизнес-сценарий использования, иногда называемый ключевым сценарием использования), или на системном уровне (системный сценарий использования). Различия между ними лежат в деталях.
- Бизнес-сценарий использования не затрагивает технологии, а рассматривает систему как «черный ящик» и описывает бизнес-процесс, который используется бизнес-акторами (людьми, или системами, внешними к бизнесу) для достижения своих целей (например обработка оплаты, одобрение авансового отчета, управление корпоративным недвижимым имуществом). Бизнес-сценарий использования описывает, что именно делает процесс, ценный для бизнес-агента.
- Системный сценарий использования обычно описывается на уровне функций системы (например: «Создайте ваучер») и определяет функцию или сервис, предоставляемые системой для пользователя. Системный сценарий использования описывает, что актор может сделать, взаимодействуя с системой. Поэтому рекомендуется, чтобы системные случаи использования начинались с глагола (например: «Создайте ваучер», «Выберите платежи», «Отмените ваучер»).
Сценарий использования должен:
- Описывать, что именно система должна сделать, чтобы актор достиг своей цели.
- Не затрагивать деталей реализации.
- Иметь достаточный уровень детализации.
- Не описывать пользовательские интерфейсы и экраны. Это делается во время проектирования пользовательского интерфейса.
Уровень детализации
Алистер Коберн в книге «Написание эффективных сценариев использования» выделил три уровня детализации сценариев использования:
- Краткий сценарий использования состоит из нескольких предложений. Он может быть легко вставлен в ячейку электронной таблицы, позволяя записать в соседних столбцах приоритет, продолжительности, техническую сложность и другие параметры.
- Обычный сценарий использования состоит из нескольких параграфов текста, подытоживающих сценарий использования.
- Полностью детализированный сценарий использования — формальный документ, основанный на подробном шаблоне с различными разделами. Именно этот вариант подразумевается в большинстве случаев под понятием сценария использования.
Подходящая детализация
Некоторым процессам разработки программного обеспечения достаточно простого сценария использования для определения требований системы. Другим необходимо много детализированных сценариев использования. В общем случае чем больше и сложнее проект, тем более вероятно, что будет необходимо использовать много детализированных сценариев.
Уровень деталей в сценарии использования часто зависит от стадии проекта. Начальные сценарии могут быть краткими, но в процессе развития проекта они становятся более детальными. Это отражает различные требования к сценариям использования. Первоначально они должны только быть краткими, так как они применяются для получения общих бизнес-требований с точки зрения пользователей. Однако, позже в процессе создания системы разработчики нуждаются в намного более определенном и детальном руководстве.
Рациональный Унифицированный Процесс (RUP) стимулирует разработчиков использовать краткое описание сценариев использования в диаграмме прецедентов с обычным уровнем детализации в виде комментария и детальным описанием в текстовом анализе. Сценарии могут быть задокументированы с помощью специальных инструментов (например, , SysML Tool), или написаны в обычном текстовом редакторе.
Нотация сценариев использования
В Унифицированном языке моделирования отношения между всеми или частью сценариев использования и акторами представлены в виде диаграммы сценария использования или в диаграммах, первоначально основанных на объектной записи Ивара Якобсона. SysML использует то же самое представление на системном уровне.
На диаграммах сценариев использования в UML сценарий отображается в виде эллипса. Внутри эллипса или под ним указывается имя элемента.
К сценариям использования в UML применимы следующие виды отношений:
- Ассоциация (англ. Association) — может указывать на то, что актор инициирует соответствующий вариант использования.
В том числе между прецедентами:
- Расширение (англ. Extend) — разновидность отношения зависимости между базовым вариантом использования и его специальным случаем.
- Включение (англ. Include) — определяет взаимосвязь базового варианта использования с другим вариантом использования, функциональное поведение которого всегда задействуется базовым вариантом использования.
- Обобщение (англ. Generalization, наследование) — моделирует соответствующую общность ролей.
Сценарии использования и процесс разработки
Варианты применения сценариев в процессе разработки зависят от используемой методологии разработки. В одних методологиях разработки все, что требуется, — это краткий обзор сценария. В других сценарии использования усложняются и изменяются в ходе разработки. В некоторых методологиях они могут начаться как краткие бизнес-сценарии, развиться в детальные системные сценарии использования, и затем перерасти в чрезвычайно детальные и исчерпывающие тесты.
Шаблоны сценариев использования
Нет никакого стандартного шаблона для документации детальных сценариев использования. Существуют много конкурирующих схем, но лучше всего использовать те шаблоны, которые лучше подходят для проекта. Есть, однако, смысл упомянуть об основных моментах, на которые стоит обратить внимание.
- Имя сценария
- Имя сценария стоит писать в формате глагол-существительное (например, Заимствовать Книги, Забрать Наличные деньги). Оно должно описывать достижимую цель (например, Регистрация Пользователя лучше, чем Регистрирующийся Пользователь), и должно объяснять смысл сценария использования. Неплохо использовать имя сценария, цель актора, гарантируя таким образом внимание к потребностям пользователя. Два-три слова — оптимум. Если слов в названии больше, то обычно есть более короткое и более информативное имя.
- Цель
- Без цели сценарий бесполезен. Нет никакой необходимости в сценарии использования, когда нет никакой потребности ни в каком акторе, чтобы достигнуть цели. Цель кратко описывает то, чего пользователь намеревается достигнуть с этим сценарием.
- Акторы (действующие лица)
- Актор — это кто-то или что-то вне системы, влияющий(-ее) на систему или находящийся(-ееся) под её влиянием. Актор может быть человеком, устройством, другой системой или подсистемой, или временем. Человек в реальном мире может быть представлен несколькими акторами, если у них есть несколько различных ролей и целей по отношению к системе. Они взаимодействуют с системой и производят над ней некоторые действия.
- Заинтересованные лица (Стейкхолдеры)
- Заинтересованное лицо — человек или отдел, которых затрагивает сценарий использования. Обычно это работники организации или отдела, для которого создается сценарий. К заинтересованному лицу можно обратиться с просьбой предоставить информацию, отзыв, или разрешение для сценария использования.
- Предварительные условия
- Стоит определить все условия, которые должны быть истиной (то есть, описать состояние системы) при которых исполнение сценария имеет смысл. Таким образом, если система не находится в состоянии, описанном в предварительных условиях, поведение сценария неопределенно. Заметьте также, что предварительные условия это не «активаторы» (см. ниже), так как верные предварительные условия НЕ инициируют выполнение сценария.
- Активаторы
- Активатор — это событие, инициирующее выполнение сценария. Это событие может быть внешним, временным или внутренним. Если активатор не реальное событие (например, клиент нажимает кнопку), а ряд сложных условий, тогда стоит описать процесс активации. Этот процесс должен периодически или постоянно проверять условия активации и инициировать сценарий.
Есть несколько вариантов, как описать ситуацию, когда активация происходит, но предварительные условия не выполнены.
- Один путь состоит в том, чтобы обработать «ошибку» в пределах сценария (как исключение). В принципе такой подход нелогичен, потому что «предварительные условия» — теперь не истинные предварительные условия вообще (потому что поведение сценария определено, даже когда предварительные условия не выполнены).
- Другой путь — поместить все предварительные условия в активатор (так, чтобы сценарий не выполнялся, если предварительные условия не выполнены), и создать отдельный сценарий, описывающий проблему.
- Порядок Событий
- Как минимум, каждый сценарий использования должен описать типичный ход событий, часто представленный как ряд пронумерованных шагов.
- Альтернативные пути и дополнения
- Сценарии использования могут содержать вторичные пути или альтернативные сценарии, которые являются вариантами основного. Каждое проверенное правило может привести к альтернативному пути, и, когда правил много, количество альтернативных путей возрастает, приводя к очень сложным документам. Иногда лучше использовать условную логику или диаграммы, чтобы описать сценарии со многими правилами и условиями.
- Бизнес-правила
- Бизнес-правила — способ задания логики системы для определения результата в зависимости от конкретного запроса к системе (например, входных данных). Правила описывают логику типа: «Если на входе такие данные, то система реагирует вот так». Они могут касаться одного сценария использования, применяться ко всем сценариям или ко всему бизнесу. Сценарии использования должны ясно ссылаться на бизнес-правила, которые для них применимы и используются.
Ограничения сценариев использования
- Сценарии использования плохо подходят для документирования требований, не основанных на взаимодействии с системой (таких как алгоритм или математические требования), или нефункциональных требований (такие как платформа, производительность, синхронизация, безопасность).
- Следование шаблонам не гарантирует качество сценариев. Качество зависит только от навыков создателя сценария.
- Есть кривая обучения правильному пониманию сценариев использования как для конечных пользователей, так и для разработчиков. Так как нет никаких полностью стандартных определений сценариев, каждая группа должна постепенно развивать свою собственную интерпретацию.
- Сторонники Экстремального программирования часто считают сценарии использования слишком формальными документами, предпочитая использовать более простой подход пользовательских историй.
- Создателям сценариев часто сложно определить, на каком уровне следует описывать пользовательский интерфейс (UI). Хоть теория сценариев использования и предлагает, чтобы пользовательские интерфейсы не описывались в сценариях, часто достаточно трудно описать сценарий не затрагивая описания пользовательского интерфейса.
- Важность сценариев использования может быть переоценена. В книге «Object Oriented Software Construction» (2-й выпуск), Бертран Мейер обсуждает проблемы, такие как проектирование системы только по сценариям использования, исключая другие потенциально ценные методики анализа требований.
- Сценарии использования получили некоторый интерес как отправная точка для тест-дизайна. Определенная литература по сценариям использования, однако, утверждает, что предварительные и результирующие условия, описанные в сценарии, должны применяться ко всему сценарию (то есть ко всем возможным путям развития сценария). Это ограничивает пользу сценариев с точки зрения тест-дизайна. Если результирующие условия сценария использования являются достаточно общими, чтобы быть правильными для всех вариантов развития событий, они, вероятно, бесполезны как основа для определения ожидаемого поведения системы в тест-дизайне. Например, результирующие условия неудавшейся попытки снять наличные деньги из банкомата отличаются от результирующих условий после успешной операции. Если результирующие условия отразят этот факт, то они также будут отличаться. Если результирующие условия не отражают этого, то они не могут использоваться для определения ожидаемого поведения тестов.
См. также
- Прецедент (UML)
- Анализ требований
- Пользовательские истории
Примечания
- UML Специальный справочник: «use case (вариант использования, прецедент)». Дата обращения: 21 сентября 2015. Архивировано из оригинала 4 марта 2016 года.
Ссылки
- Use Case 2.0. Неофициальный перевод
- Use Case VS User Story Выбираем подход к специфицированию требований
Википедия, чтение, книга, библиотека, поиск, нажмите, истории, книги, статьи, wikipedia, учить, информация, история, скачать, скачать бесплатно, mp3, видео, mp4, 3gp, jpg, jpeg, gif, png, картинка, музыка, песня, фильм, игра, игры, мобильный, телефон, Android, iOS, apple, мобильный телефон, Samsung, iphone, xiomi, xiaomi, redmi, honor, oppo, nokia, sonya, mi, ПК, web, Сеть, компьютер, Информация о Сценарий использования, Что такое Сценарий использования? Что означает Сценарий использования?
Scenarij ispolzovaniya variant ispolzovaniya precedent ispolzovaniya angl use case v razrabotke programmnogo obespecheniya i sistemnom proektirovanii eto opisanie povedeniya sistemy kogda ona vzaimodejstvuet s kem to ili chem to iz vneshnej sredy Sistema mozhet otvechat na vneshnie zaprosy Aktora angl actor v russkom yazyke udarenie na pervyj slog mozhet primenyatsya termin Aktant mozhet sama vystupat iniciatorom vzaimodejstviya Drugimi slovami scenarij ispolzovaniya opisyvaet kto i chto mozhet sdelat s rassmatrivaemoj sistemoj ili chto sistema mozhet sdelat s kem ili chem Metodika scenariev ispolzovaniya primenyaetsya dlya vyyavleniya trebovanij k povedeniyu sistemy izvestnyh takzhe kak polzovatelskie i funkcionalnye trebovaniya Scenarij ispolzovaniya Aktor zaregistrirovannyj polzovatel Wiki redaktiruet statyu Shema sozdana na osnov opisaniya na yazyke UML V sistemnom proektirovanii scenarii ispolzovaniya primenyayutsya na bolee vysokom urovne chem pri razrabotke programmnogo obespecheniya chasto predstavlyaya celi zainteresovannyh lic ili missii Na stadii analiza trebovanij scenarii ispolzovaniya mogut byt preobrazovany v ryad detalnyh trebovanij i zadokumentirovany s pomoshyu diagramm trebovanij SysML ili drugih podobnyh mehanizmov IstoriyaV 1986 godu Ivar Yakobson pozzhe soavtor Unificirovannogo Yazyka Modelirovaniya UML i Racionalnogo Unificirovannogo Processa RUP vpervye sformuliroval metodiku vizualnogo modelirovaniya dlya opisaniya scenariev ispolzovaniya Pervonachalno on ispolzoval neskolko inye terminy angl usage scenarios i usage case no ni odin iz nih ne byl estestvennym dlya anglijskogo yazyka I v konechnom schete on ostanovilsya na termine use case scenarij ispolzovaniya Posle sozdaniya Yakobsonom metodiki modelirovaniya scenariev ispolzovaniya mnogie specialisty v oblasti inzhenerii PO posposobstvovali uluchsheniyu etoj metodiki vklyuchaya Kurta Bittnera Gannera Overgarda i Dzheri Shnajdera V techenie 1990 h scenarii ispolzovaniya stali odnoj iz samyh rasprostranennyh metodik dokumentirovaniya funkcionalnyh trebovanij osobenno v obektno orientirovannoj srede otkuda oni i proizoshli No ih primenenie ne ogranichivaetsya obektno orientirovannymi sistemami poskolku scenarii ispolzovaniya ne obektno orientirovany po prirode Celi scenariev ispolzovaniya Kazhdyj scenarij ispolzovaniya sosredotachivaetsya na opisanii togo kak dostignut celi ili zadachi Dlya bolshinstva programmnyh proektov eto oznachaet chto potrebuetsya mnozhestvo scenariev ispolzovaniya chtoby opredelit neobhodimyj nabor svojstv novoj sistemy Stepen formalnosti programmnogo proekta i ego stadii budet vliyat na neobhodimyj uroven detalizacii dlya kazhdogo scenariya ispolzovaniya Scenarii ispolzovaniya ne dolzhny putatsya s ponyatiem svojstv sistemy angl Feature Scenarij ispolzovaniya mozhet byt svyazan s odnim ili bolee svojstvom sistemy i svojstvo mozhet byt svyazano s odnim ili bolee scenariem ispolzovaniya Scenarij ispolzovaniya opredelyaet vzaimodejstviya mezhdu vneshnimi agentami i sistemoj napravlennye na dostizhenie celi Aktor angl Actor predstavlyaet soboj rol kotoruyu igraet chelovek ili vesh vzaimodejstvuya s sistemoj Odin i tot zhe chelovek ispolzuyushij sistemu mozhet byt predstavlen kak razlichnye aktory potomu chto oni igrayut razlichnye roli Naprimer Dzhek mozhet igrat rol Klienta ispolzuyushego Bankomat chtoby zabrat nalichnye dengi ili igrat rol Rabotnika Banka ispolzuyushego sistemu dlya popolneniya bankomata kupyurami Scenarii ispolzovaniya rassmatrivayut sistemu kak chernyj yashik i vzaimodejstviya s sistemoj vklyuchaya sistemnye otvety opisyvayutsya s tochki zreniya vneshnego nablyudatelya Eto prednamerennaya politika potomu chto eto vynuzhdaet avtora sosredotochitsya na tom chto sistema dolzhna sdelat a ne kak eto dolzhno byt sdelano i pozvolyaet izbegat sozdaniya predpolozhenij o tom kak funkcionalnye vozmozhnosti budut realizovany Scenarii ispolzovaniya mogut byt opisany na abstraktnom urovne opisyvayushem chast predmetnoj oblasti biznes scenarij ispolzovaniya inogda nazyvaemyj klyuchevym scenariem ispolzovaniya ili na sistemnom urovne sistemnyj scenarij ispolzovaniya Razlichiya mezhdu nimi lezhat v detalyah Biznes scenarij ispolzovaniya ne zatragivaet tehnologii a rassmatrivaet sistemu kak chernyj yashik i opisyvaet biznes process kotoryj ispolzuetsya biznes aktorami lyudmi ili sistemami vneshnimi k biznesu dlya dostizheniya svoih celej naprimer obrabotka oplaty odobrenie avansovogo otcheta upravlenie korporativnym nedvizhimym imushestvom Biznes scenarij ispolzovaniya opisyvaet chto imenno delaet process cennyj dlya biznes agenta Sistemnyj scenarij ispolzovaniya obychno opisyvaetsya na urovne funkcij sistemy naprimer Sozdajte vaucher i opredelyaet funkciyu ili servis predostavlyaemye sistemoj dlya polzovatelya Sistemnyj scenarij ispolzovaniya opisyvaet chto aktor mozhet sdelat vzaimodejstvuya s sistemoj Poetomu rekomenduetsya chtoby sistemnye sluchai ispolzovaniya nachinalis s glagola naprimer Sozdajte vaucher Vyberite platezhi Otmenite vaucher Scenarij ispolzovaniya dolzhen Opisyvat chto imenno sistema dolzhna sdelat chtoby aktor dostig svoej celi Ne zatragivat detalej realizacii Imet dostatochnyj uroven detalizacii Ne opisyvat polzovatelskie interfejsy i ekrany Eto delaetsya vo vremya proektirovaniya polzovatelskogo interfejsa Uroven detalizaciiAlister Kobern v knige Napisanie effektivnyh scenariev ispolzovaniya vydelil tri urovnya detalizacii scenariev ispolzovaniya Kratkij scenarij ispolzovaniya sostoit iz neskolkih predlozhenij On mozhet byt legko vstavlen v yachejku elektronnoj tablicy pozvolyaya zapisat v sosednih stolbcah prioritet prodolzhitelnosti tehnicheskuyu slozhnost i drugie parametry Obychnyj scenarij ispolzovaniya sostoit iz neskolkih paragrafov teksta podytozhivayushih scenarij ispolzovaniya Polnostyu detalizirovannyj scenarij ispolzovaniya formalnyj dokument osnovannyj na podrobnom shablone s razlichnymi razdelami Imenno etot variant podrazumevaetsya v bolshinstve sluchaev pod ponyatiem scenariya ispolzovaniya Podhodyashaya detalizaciyaNekotorym processam razrabotki programmnogo obespecheniya dostatochno prostogo scenariya ispolzovaniya dlya opredeleniya trebovanij sistemy Drugim neobhodimo mnogo detalizirovannyh scenariev ispolzovaniya V obshem sluchae chem bolshe i slozhnee proekt tem bolee veroyatno chto budet neobhodimo ispolzovat mnogo detalizirovannyh scenariev Uroven detalej v scenarii ispolzovaniya chasto zavisit ot stadii proekta Nachalnye scenarii mogut byt kratkimi no v processe razvitiya proekta oni stanovyatsya bolee detalnymi Eto otrazhaet razlichnye trebovaniya k scenariyam ispolzovaniya Pervonachalno oni dolzhny tolko byt kratkimi tak kak oni primenyayutsya dlya polucheniya obshih biznes trebovanij s tochki zreniya polzovatelej Odnako pozzhe v processe sozdaniya sistemy razrabotchiki nuzhdayutsya v namnogo bolee opredelennom i detalnom rukovodstve Racionalnyj Unificirovannyj Process RUP stimuliruet razrabotchikov ispolzovat kratkoe opisanie scenariev ispolzovaniya v diagramme precedentov s obychnym urovnem detalizacii v vide kommentariya i detalnym opisaniem v tekstovom analize Scenarii mogut byt zadokumentirovany s pomoshyu specialnyh instrumentov naprimer SysML Tool ili napisany v obychnom tekstovom redaktore Notaciya scenariev ispolzovaniyaOsnovnaya statya Precedent UML V Unificirovannom yazyke modelirovaniya otnosheniya mezhdu vsemi ili chastyu scenariev ispolzovaniya i aktorami predstavleny v vide diagrammy scenariya ispolzovaniya ili v diagrammah pervonachalno osnovannyh na obektnoj zapisi Ivara Yakobsona SysML ispolzuet to zhe samoe predstavlenie na sistemnom urovne Na diagrammah scenariev ispolzovaniya v UML scenarij otobrazhaetsya v vide ellipsa Vnutri ellipsa ili pod nim ukazyvaetsya imya elementa K scenariyam ispolzovaniya v UML primenimy sleduyushie vidy otnoshenij Associaciya angl Association mozhet ukazyvat na to chto aktor iniciiruet sootvetstvuyushij variant ispolzovaniya V tom chisle mezhdu precedentami Rasshirenie angl Extend raznovidnost otnosheniya zavisimosti mezhdu bazovym variantom ispolzovaniya i ego specialnym sluchaem Vklyuchenie angl Include opredelyaet vzaimosvyaz bazovogo varianta ispolzovaniya s drugim variantom ispolzovaniya funkcionalnoe povedenie kotorogo vsegda zadejstvuetsya bazovym variantom ispolzovaniya Obobshenie angl Generalization nasledovanie modeliruet sootvetstvuyushuyu obshnost rolej Scenarii ispolzovaniya i process razrabotkiVarianty primeneniya scenariev v processe razrabotki zavisyat ot ispolzuemoj metodologii razrabotki V odnih metodologiyah razrabotki vse chto trebuetsya eto kratkij obzor scenariya V drugih scenarii ispolzovaniya uslozhnyayutsya i izmenyayutsya v hode razrabotki V nekotoryh metodologiyah oni mogut nachatsya kak kratkie biznes scenarii razvitsya v detalnye sistemnye scenarii ispolzovaniya i zatem pererasti v chrezvychajno detalnye i ischerpyvayushie testy Shablony scenariev ispolzovaniyaNet nikakogo standartnogo shablona dlya dokumentacii detalnyh scenariev ispolzovaniya Sushestvuyut mnogo konkuriruyushih shem no luchshe vsego ispolzovat te shablony kotorye luchshe podhodyat dlya proekta Est odnako smysl upomyanut ob osnovnyh momentah na kotorye stoit obratit vnimanie Imya scenariya Imya scenariya stoit pisat v formate glagol sushestvitelnoe naprimer Zaimstvovat Knigi Zabrat Nalichnye dengi Ono dolzhno opisyvat dostizhimuyu cel naprimer Registraciya Polzovatelya luchshe chem Registriruyushijsya Polzovatel i dolzhno obyasnyat smysl scenariya ispolzovaniya Neploho ispolzovat imya scenariya cel aktora garantiruya takim obrazom vnimanie k potrebnostyam polzovatelya Dva tri slova optimum Esli slov v nazvanii bolshe to obychno est bolee korotkoe i bolee informativnoe imya Cel Bez celi scenarij bespolezen Net nikakoj neobhodimosti v scenarii ispolzovaniya kogda net nikakoj potrebnosti ni v kakom aktore chtoby dostignut celi Cel kratko opisyvaet to chego polzovatel namerevaetsya dostignut s etim scenariem Aktory dejstvuyushie lica Aktor eto kto to ili chto to vne sistemy vliyayushij ee na sistemu ili nahodyashijsya eesya pod eyo vliyaniem Aktor mozhet byt chelovekom ustrojstvom drugoj sistemoj ili podsistemoj ili vremenem Chelovek v realnom mire mozhet byt predstavlen neskolkimi aktorami esli u nih est neskolko razlichnyh rolej i celej po otnosheniyu k sisteme Oni vzaimodejstvuyut s sistemoj i proizvodyat nad nej nekotorye dejstviya Zainteresovannye lica Stejkholdery Zainteresovannoe lico chelovek ili otdel kotoryh zatragivaet scenarij ispolzovaniya Obychno eto rabotniki organizacii ili otdela dlya kotorogo sozdaetsya scenarij K zainteresovannomu licu mozhno obratitsya s prosboj predostavit informaciyu otzyv ili razreshenie dlya scenariya ispolzovaniya Predvaritelnye usloviya Stoit opredelit vse usloviya kotorye dolzhny byt istinoj to est opisat sostoyanie sistemy pri kotoryh ispolnenie scenariya imeet smysl Takim obrazom esli sistema ne nahoditsya v sostoyanii opisannom v predvaritelnyh usloviyah povedenie scenariya neopredelenno Zamette takzhe chto predvaritelnye usloviya eto ne aktivatory sm nizhe tak kak vernye predvaritelnye usloviya NE iniciiruyut vypolnenie scenariya Aktivatory Aktivator eto sobytie iniciiruyushee vypolnenie scenariya Eto sobytie mozhet byt vneshnim vremennym ili vnutrennim Esli aktivator ne realnoe sobytie naprimer klient nazhimaet knopku a ryad slozhnyh uslovij togda stoit opisat process aktivacii Etot process dolzhen periodicheski ili postoyanno proveryat usloviya aktivacii i iniciirovat scenarij Est neskolko variantov kak opisat situaciyu kogda aktivaciya proishodit no predvaritelnye usloviya ne vypolneny Odin put sostoit v tom chtoby obrabotat oshibku v predelah scenariya kak isklyuchenie V principe takoj podhod nelogichen potomu chto predvaritelnye usloviya teper ne istinnye predvaritelnye usloviya voobshe potomu chto povedenie scenariya opredeleno dazhe kogda predvaritelnye usloviya ne vypolneny Drugoj put pomestit vse predvaritelnye usloviya v aktivator tak chtoby scenarij ne vypolnyalsya esli predvaritelnye usloviya ne vypolneny i sozdat otdelnyj scenarij opisyvayushij problemu Poryadok Sobytij Kak minimum kazhdyj scenarij ispolzovaniya dolzhen opisat tipichnyj hod sobytij chasto predstavlennyj kak ryad pronumerovannyh shagov Alternativnye puti i dopolneniya Scenarii ispolzovaniya mogut soderzhat vtorichnye puti ili alternativnye scenarii kotorye yavlyayutsya variantami osnovnogo Kazhdoe proverennoe pravilo mozhet privesti k alternativnomu puti i kogda pravil mnogo kolichestvo alternativnyh putej vozrastaet privodya k ochen slozhnym dokumentam Inogda luchshe ispolzovat uslovnuyu logiku ili diagrammy chtoby opisat scenarii so mnogimi pravilami i usloviyami Biznes pravila Biznes pravila sposob zadaniya logiki sistemy dlya opredeleniya rezultata v zavisimosti ot konkretnogo zaprosa k sisteme naprimer vhodnyh dannyh Pravila opisyvayut logiku tipa Esli na vhode takie dannye to sistema reagiruet vot tak Oni mogut kasatsya odnogo scenariya ispolzovaniya primenyatsya ko vsem scenariyam ili ko vsemu biznesu Scenarii ispolzovaniya dolzhny yasno ssylatsya na biznes pravila kotorye dlya nih primenimy i ispolzuyutsya Ogranicheniya scenariev ispolzovaniyaScenarii ispolzovaniya ploho podhodyat dlya dokumentirovaniya trebovanij ne osnovannyh na vzaimodejstvii s sistemoj takih kak algoritm ili matematicheskie trebovaniya ili nefunkcionalnyh trebovanij takie kak platforma proizvoditelnost sinhronizaciya bezopasnost Sledovanie shablonam ne garantiruet kachestvo scenariev Kachestvo zavisit tolko ot navykov sozdatelya scenariya Est krivaya obucheniya pravilnomu ponimaniyu scenariev ispolzovaniya kak dlya konechnyh polzovatelej tak i dlya razrabotchikov Tak kak net nikakih polnostyu standartnyh opredelenij scenariev kazhdaya gruppa dolzhna postepenno razvivat svoyu sobstvennuyu interpretaciyu Storonniki Ekstremalnogo programmirovaniya chasto schitayut scenarii ispolzovaniya slishkom formalnymi dokumentami predpochitaya ispolzovat bolee prostoj podhod polzovatelskih istorij Sozdatelyam scenariev chasto slozhno opredelit na kakom urovne sleduet opisyvat polzovatelskij interfejs UI Hot teoriya scenariev ispolzovaniya i predlagaet chtoby polzovatelskie interfejsy ne opisyvalis v scenariyah chasto dostatochno trudno opisat scenarij ne zatragivaya opisaniya polzovatelskogo interfejsa Vazhnost scenariev ispolzovaniya mozhet byt pereocenena V knige Object Oriented Software Construction 2 j vypusk Bertran Mejer obsuzhdaet problemy takie kak proektirovanie sistemy tolko po scenariyam ispolzovaniya isklyuchaya drugie potencialno cennye metodiki analiza trebovanij Scenarii ispolzovaniya poluchili nekotoryj interes kak otpravnaya tochka dlya test dizajna Opredelennaya literatura po scenariyam ispolzovaniya odnako utverzhdaet chto predvaritelnye i rezultiruyushie usloviya opisannye v scenarii dolzhny primenyatsya ko vsemu scenariyu to est ko vsem vozmozhnym putyam razvitiya scenariya Eto ogranichivaet polzu scenariev s tochki zreniya test dizajna Esli rezultiruyushie usloviya scenariya ispolzovaniya yavlyayutsya dostatochno obshimi chtoby byt pravilnymi dlya vseh variantov razvitiya sobytij oni veroyatno bespolezny kak osnova dlya opredeleniya ozhidaemogo povedeniya sistemy v test dizajne Naprimer rezultiruyushie usloviya neudavshejsya popytki snyat nalichnye dengi iz bankomata otlichayutsya ot rezultiruyushih uslovij posle uspeshnoj operacii Esli rezultiruyushie usloviya otrazyat etot fakt to oni takzhe budut otlichatsya Esli rezultiruyushie usloviya ne otrazhayut etogo to oni ne mogut ispolzovatsya dlya opredeleniya ozhidaemogo povedeniya testov Sm takzhePrecedent UML Analiz trebovanij Polzovatelskie istoriiPrimechaniyaUML Specialnyj spravochnik use case variant ispolzovaniya precedent neopr Data obrasheniya 21 sentyabrya 2015 Arhivirovano iz originala 4 marta 2016 goda SsylkiUse Case 2 0 Neoficialnyj perevod Use Case VS User Story Vybiraem podhod k specificirovaniyu trebovanij
