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

Матеріал з Вікіпедії — вільної енциклопедії.
Перейти до: навігація, пошук

Сценарій використання , варіант використання, прецедент (англ. 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-ий випуск), Бертран Мейер обговорює проблеми, такі як проектування системи тільки за сценаріями використання виключаючи інші потенційно цінні методики аналізу вимог.
  • Сценарії використання одержали деякий інтерес як відправна точка для тест дизайну. Певна література за сценаріями використання, однак, стверджує що попередні і результуючі умови, описані в сценарії, повинні застосовуватися до всього сценарію (тобто, до всіх можливих шляхів розвитку сценарію). Це обмежує користь сценаріїв з точки зору тест дизайну. Якщо результуючі умови сценарію використання є досить загальними, щоб бути правильними для всіх варіантів розвитку подій, вони ймовірно марні як основа для визначення очікуваної поведінки системи в тест дизайні. Наприклад, результуючі умови невдалої спроби зняти готівку з банкомату відрізняються від результуючих умов після успішної операції. Якщо результуючі умови відіб'ють цей факт, то вони також будуть відрізнятися. Якщо результуючі умови не відображають цього, то вони не можуть використовуватися для визначення очікуваної поведінки тестів.

Див. також[ред.ред. код]

Примітки[ред.ред. код]

Посилання[ред.ред. код]