Сценарій використання

Різновид використання, варіант використання, прецедент (англ. Use Case) — у розробці програмного забезпечення та системному проєктуванні це опис поведінки системи, як вона відповідає на зовнішні запити. Іншими словами, різновид використання описує, «хто» і «що» може зробити з розглянутою системою. Методика різновидів використання застосовується для виявлення вимог до поведінки системи, відомих також як функціональні вимоги.

У системному проєктуванні різновиди використання застосовуються на більш високому рівні ніж при розробці програмного забезпечення, часто представляючи цілі зацікавлених осіб або місії. На стадії аналізу вимог різновиди використання можуть бути перетворені на ряд детальних вимог і задокументовані за допомогою діаграм вимог SysML або інших подібних механізмів.

Історія

У 1986 році Івар Якобсон, пізніше співавтор Уніфікованої Мови Моделювання (UML) та Раціонального Уніфікованого Процесу (RUP), вперше сформулював методику візуального моделювання для опису різновидів використання. Спочатку він використовував дещо інші терміни — англ. Usage scenarios і usage case , але жоден з них не був природним для англійської мови. І в кінцевому рахунку він зупинився на терміні use case — різновид використання. Після створення Якобсоном методики моделювання різновидів використання багато людей посприяли поліпшенню цієї методики, включаючи Курта Біттнера, Алістера Кокберн, Ганнера Овергарда, і Джері Шнайдера.

Протягом 1990-их різновиди використання стали однією з найпоширеніших методик документування функціональних вимог, особливо в об'єктно-орієнтованому середовищі, звідки вони й вийшли. Але їхнє застосування не обмежується об'єктно-орієнтованими системами, оскільки різновиди використання не об'єктно-орієнтовані по природі.

Мета різновидів використання

Кожен різновид використання зосереджується на описі того, як досягти мети або завдання. Для більшості програмних проєктів це означає, що потрібно безліч різновидів використання щоб визначити необхідний набір властивостей нової системи. Ступінь формальності програмного проєкту і його стадії буде впливати на необхідний рівень деталізації, для кожного різновиду використання.

Різновиди використання не можна плутати з поняттям властивостей системи (англ. Feature). Різновид використання може бути пов'язаний з однією або більше властивістю системи, і властивість може бути пов'язана з одним або більше різновидом використання.

Різновид використання визначає взаємодії між зовнішніми агентами і системою, спрямовані на досягнення мети. Актор (англ. Actor) являє собою роль, яку грає людина або річ, взаємодіючи з системою. Той же самий чоловік, який використовує систему, може бути представлений як різні актори, тому що вони грають різні ролі. Наприклад, «Джек» може грати роль Клієнта, що використовує Банкомат, щоб забрати готівку гроші, або грати роль Працівника Банку, що використовує систему для поповнення банкомату купюрами.

Різновиди використання розглядають систему як «чорний ящик», і взаємодії з системою, включаючи системні відповіді, описуються з точки зору зовнішнього спостерігача. Це — навмисна політика, тому що це змушує автора зосередитися на тому, що система повинна зробити, а не, як це повинно бути зроблено, і дозволяє уникати створення припущень про те, як функціональні можливості будуть реалізовані.

різновиди використання можуть бути описані на абстрактному рівні (діловий різновид використання, іноді званий ключовим різновидом використання), або на системному рівні (системний різновид використання). Відмінності між ними — в деталях.

Діловий різновид використання не зачіпає технологій, розглядає систему як «чорний ящик» і описує бізнес-процес, який використовується діловими акторами (людьми, або системами, зовнішніми до бізнесу) для досягнення своїх цілей (наприклад, обробка оплати, схвалення авансового звіту, управління корпоративними нерухомим майном). Діловий різновид використання описує процес, цінний для ділового агента, описує що саме робить процес.
Системний різновид використання зазвичай описується на рівні функцій системи (наприклад, створіть ваучер), і визначає функцію або сервіс, що надаються системою для користувача. Системний різновид використання описує що актор може зробити взаємодіючи з системою. З цієї причини рекомендується, щоб системні випадки використання починалися з дієслова (наприклад, створіть ваучер, виберіть платежі, скасуйте ваучер).

різновид використання повинен:

Описувати що саме система має зробити, щоб актор досяг своєї мети.
Не торкатися деталей реалізації.
Мати достатній рівень деталізації.
Не описувати інтерфейси та екрани. Це робиться під час дизайну користувальницького інтерфейсу.

Рівень деталізації

Алістер Кокберн у книзі «Написання ефективних різновидів використання» виділив три рівні деталізації різновидів використання:

Короткий різновид використання: Складається з декількох речень. Він може бути легко вставлений у клітинку електронної таблиці, дозволяючи записати в сусідніх стовпцях пріоритет, тривалості, технічну складність і інші параметри.
Звичайний різновид використання: Складається з декількох параграфів тексту, підсумовує різновид використання.
Повністю деталізований різновид використання: Формальний документ, заснований на детальному шаблоні з різними розділами. Саме цей варіант мається на увазі в більшості випадків під поняттям різновиду використання.

Належна деталізація

Деяким процесам розробки програмного забезпечення достатньо простого різновиду використання для визначення вимог до системи. Іншим необхідно багато деталізованих різновидів використання. У загальному випадку чим більше і складніше проєкт, тим більше ймовірно, що буде необхідно використовувати багато деталізованих різновидів.

Рівень деталей у різновиди використання часто залежить від стадії проєкту. Початкові різновиди можуть бути короткими, але в процесі розвитку проєкту вони стають детальнішими. Це відображає різні вимоги до різновидів використання. Спочатку вони повинні тільки бути короткими, оскільки вони застосовуються для отримання загальних ділових вимог з точки зору користувачів. Однак, пізніше в процесі створення системи розробники потребують набагато певніше і детальне керівництво.

Раціональний Уніфікований Процес (RUP) стимулює розробників використовувати короткий опис різновидів використання в діаграмі різновидів використання зі звичайним рівнем деталізації у вигляді коментаря і детальним описом у текстовому аналізі. різновиди можуть бути задокументовані за допомогою спеціальних інструментів (наприклад, UML Tool, SysML Tool), або написані в звичайному текстовому редакторі.

Записування різновидів використання

Докладніше: Прецедент (UML)

В уніфікованій мові моделювання відносини між усіма або частиною різновидів використання й акторами представлені у вигляді діаграми різновиду використання або діаграмах, спочатку заснованих на об'єктному запису Івара Якобсона. SysML використовує те ж саме уявлення на системному рівні.

На діаграмах різновидів використання в UML різновид відображається у вигляді еліпса. Всередині еліпса або під ним вказується ім'я елемента.

До різновиду використання в UML застосовують наступні види відносин:

Асоціація (англ. Association) — Може вказувати на те, що актор ініціює відповідний варіант використання.

У тому числі між прецедентами:

Розширення (англ. Extend) — Різновид відносини залежності між базовим варіантом використання та його спеціальним випадком.
Включення (англ. Include) — Визначає взаємозв'язок базового варіанту використання з іншим варіантом використання, функціональна поведінка якого задіюється базовим не завжди, а тільки при виконанні додаткових умов.
Узагальнення (англ. Generalization , наслідування) — моделює відповідну спільність ролей.

Різновиди використання та процес розробки

Варіанти застосування різновидів у процесі розробки залежать від використовуваної методології розробки. В одних методологіях розробки все, що потрібно це короткий огляд різновиду. В інших різновиди використання ускладнюються і змінюються в ході розробки. У деяких методологіях вони можуть почати як короткі ділові різновиди, розвинутися в детальні системні різновиди використання, і потім перерости в надзвичайно детальні та вичерпні тести.

Шаблони різновидів використання

Немає ніякого стандартного шаблону для документації детальних різновидів використання. Існує багато конкуруючих схем, але краще всього використовувати ті шаблони, які краще підходять для проєкту. Є, проте сенс згадати про основні моменти на які варто звернути увагу.

Ім'я різновиду: Ім'я різновиду варто писати у форматі дієслово-іменник (наприклад, запозичувати Книги, Забрати Готівкові гроші). Воно має описувати досяжну мету (наприклад, Реєстрація Користувача краще ніж реєструє користувачів), і повинно пояснювати про що різновид використання.

Непогано використовувати як ім'я різновиду мету актора, гарантуючи таким чином увагу до потреб користувача. Два-три слова — оптимум. Якщо слів в назві більше, то зазвичай є коротше і інформативніше ім'я.

Мета: Без мети різновид непотрібний. Немає ніякої необхідності в різновидах використання, коли немає ніякої потреби ні в якому акторі, щоб досягти мети. Мета коротко описує те, чого користувач має намір досягти за цим різновидом.

Актори: Актор це хтось чи щось поза системою і що впливає на систему або знаходиться під її впливом. Актор може бути людиною, пристроєм, іншою системою або підсистемою, або часом. Людина в реальному світі може бути представлена декількома акторами, якщо у них є кілька різних ролей і цілей стосовно системи. Вони взаємодіють з системою і роблять над нею деякі дії.

Зацікавлені особи: Зацікавлена особа — людина або відділ, яких зачіпає різновид використання. Зазвичай це працівники організації або відділу, для якого створюється різновид. До зацікавленої особи можна звернутися з проханням надати інформацію, відгук, або дозвіл для різновиду використання.

Попередні умови: Варто визначити всі умови, які повинні бути істиною (тобто, описати стан системи) при яких виконання різновиду має сенс. Таким чином, якщо система не перебуває в стані, описаному в попередніх умовах, поведінка різновиду невизначена. Зауважте так само, що попередні умови це не «Активатори» (див. нижче). Оскільки вірні попередні умови НЕ ініціюють виконання різновиду.

Активатори: Активатор — це подія що ініціює виконання різновиду. Ця подія може бути зовнішньою, тимчасовою або внутрішньою. Якщо активатор не реальна подія (наприклад, клієнт натискає кнопку), а ряд складних умов, тоді варто описати процес активації. Цей процес повинен періодично або постійно перевіряти умови активації та ініціювати різновид.

Є кілька варіантів як описати ситуацію, коли активація відбувається, але попередні умови не виконуються.

Один шлях полягає в тому, щоб обробити «помилку» в межах різновиду (як виняток). У принципі такий підхід нелогічний, тому що «попередні умови» — тепер не істинні попередні умови взагалі (тому що поведінку різновиду визначено, навіть коли попередні умови не зустрінуті).
Інший шлях — помістити всі попередні умови в активатор (так, щоб різновид не виконувався, якщо попередні умови не зустрінуті), і створити окремий різновид, що описує проблему.

Порядок Подій: Як мінімум, кожен різновид використання повинен описати типовий хід подій, часто представлений як ряд пронумерованих кроків.

Альтернативні шляхи і доповнення: Різновиди використання можуть містити вторинні шляхи або альтернативні різновиди, які є варіантами основного. Кожне перевірене правило може призвести до альтернативного шляху і коли правил багато кількість альтернативних шляхів зростає приводячи до дуже складних документів. Іноді краще використовувати умовну логіку чи діаграми, щоб описати різновиди з багатьма правилами і умовами.

Бізнес правила: Бізнес правила визначають як організація веде свій бізнес щодо різновиду використання. Бізнес правила — спеціальний вид вимог. Вони можуть стосуватися одного різновиду використання, застосовуватися до всіх різновидів або до всього бізнесу. різновиди використання повинні ясно посилатися на бізнес правила, які для них застосовні і використовуються.

Обмеження різновидів використання

Різновиди використання погано підходять для документування вимог не заснованих на взаємодії з системою (таких як алгоритм або математичні вимоги) або нефункціональних вимог (такі як платформа, продуктивність, синхронізація, безпека).
Дотримання шаблонів не гарантує якість різновидів. Якість залежить тільки від навичок творця різновиду.
Є крива навчання правильному розумінню різновидів використання, як для кінцевих користувачів так і для розробників. Оскільки немає ніяких повністю стандартних визначень різновидів, кожна група повинна поступово розвивати свою власну інтерпретацію.
Прихильники Екстремального програмування часто вважають різновиди використання занадто формальними документами, воліючи використовувати простіший підхід користувальницьких історій.
Творцям різновидів часто складно визначити на якому рівні слід описувати користувальницький інтерфейс (UI). Хоч теорія різновидів використання і пропонує, щоб для користувача інтерфейси не описувалися в різновидах, часто досить важко описати різновид не зачіпаючи опису користувацького інтерфейсу.
Важливість різновидів використання може бути переоцінена. У книзі «Object Oriented Software Construction» (2-ий випуск), Бертран Мейер обговорює проблеми, такі як проєктування системи тільки за різновидами використання виключаючи інші потенційно цінні методики аналізу вимог.
Різновиди використання одержали деякий інтерес як відправна точка для тест дизайну. Певна література за різновидами використання, однак, стверджує що попередні і результуючі умови, описані в різновиди, повинні застосовуватися до всього різновиду (тобто, до всіх можливих шляхів розвитку різновиду). Це обмежує користь різновидів з точки зору тест дизайну. Якщо результуючі умови різновиду використання є досить загальними, щоб бути правильними для всіх варіантів розвитку подій, вони ймовірно марні як основа для визначення очікуваної поведінки системи в тест дизайні. Наприклад, результуючі умови невдалої спроби зняти готівку з банкомату відрізняються від результуючих умов після успішної операції. Якщо результуючі умови відіб'ють цей факт, то вони також будуть відрізнятися. Якщо результуючі умови не відображають цього, то вони не можуть використовуватися для визначення очікуваної поведінки тестів.