Визначення вимог через прецеденти

Моделювання прецедентів – це форма вироблення вимог. Ідея опису функціональних вимог через прецеденти була запропонована Айваром Якобсоном в 1986 році. Найбільш вагомий внесок в проблему опису прецедентів вніс Алістер Кокбурн.

Виконавець (актор) – сутність, якій притаманна деяка поведінка, наприклад людина (що ідентифікується своєю роллю), комп’ютерна система або організація, яка взаємодіє з суб’єктом моделювання (системою) але є зовнішньою по відношенню до нього.

Сценарій (екземпляр прецедента) – спеціальна послідовність дій або взаємодій між виконавцем та системою, це конкретний випадок використання системи або один прохід прецедента.

Неформально, прецедент – набір взаємопов’язаних успішних та неуспішних сценаріїв.

Прецедент (за RUP) – набір сценаріїв використання, в якому кожний екземпляр сценарію являє собою послідовність дій, що виконуються системою для досягнення відчутного або значущого для конкретного актора результату.

На етапі аналізу вимог слід розглядати прецедент як «чорний ящик», і зосереджуватися на питанні ЩО повинен виконати прецедент, а не те як він повинен це зробити.

Моделювання прецедентів зазвичай відбувається таким чином:

b. визначаються основний та альтернативні потоки.

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

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

• Межа системи – прямокутник, що окреслює прецеденти для позначення краю, або межі, модельованої системи. У UML 2 цю межу називають суб’єктом (контекстом або контекстним класификатором) системи.

• Актори – ролі, що виконуються людьми або сутностями, що використовують систему.

• Прецеденти – те, що актори можуть робити з системою.

• Відношення – значущі відношення між акторами і прецедентами.

Модель прецедентів є основним джерелом об'єктів і класів. Це основні початкові дані для моделювання класів.

Розглянемо початкові дані для діяльності Виявлення акторів і прецедентів.

• Бізнес-модель – може бути надана розробникам моделі системи. Якщо вона є, це чудове джерело для збору вимог.

• Модель вимог – створення цієї моделі було описане в розділі 3 Арлоу. Ці вимоги є хорошим початковим матеріалом для процесу моделювання прецедентів. Зокрема, функціональні вимоги запропонують прецеденти і акторів. Нефункціональні вимоги – те, про що треба пам'ятати при створенні моделі прецедентів.

• Список можливостей – це набір потенційних вимог, які можуть бути представлені у формі загального опису, бачення (vision), проекту або чого-небудь подібного.

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

Актор може представляти роль користувача або роль, що виконується іншою системою чи частиною апаратних засобів, що пов’язуються з системою. У UML 2 актори можуть також представляти інші контексти системи, забезпечуючи можливість об'єднання різних моделей прецедентів.

Для ідентифікації акторів необхідно відповісти на питання: хто або що використовує систему і які ролі виконуються акторами при взаємодії з системою. Наступні питання допоможуть ідентифікувати акторів.

Хто або що отримує і надає інформацію системі?

Чи відбувається що-небудь в точно встановлений час?

При моделюванні акторів необхідно пам'ятати наступні моменти.

Актори завжди є зовнішніми по відношенню до системи.

Актори взаємодіють безпосередньо з системою – так вони допомагають у визначенні контексту системи.

Актори представляють ролі, що виконуються людьми або сутностями, а не конкретних людей чи конкретні сутності.

Одна людина або сутність може грати по відношенню до системи безліч ролей одночасно або послідовно в часі.

У кожного актора має бути коротке, змістовне з прикладної точки зору ім'я.

Кожного актора повинен супроводжувати короткий опис (що даний актор з себе представляє з точки зору системи).

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

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

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

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

прецеденти завжди описуються з точки зору акторів.

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

Визначення прецедентів краще за все розпочати зі списку акторів, а потім розглянути, як кожний актор збирається використовувати систему. За допомогою такої стратегії можна отримати список потенційних прецедентів. Ім’я <виконати щось>: «сформувати звіт», «перевірити код», «зареєструвати користувача».

Під час ідентифікації прецедентів можуть виявитися додаткові актори. Процес моделювання прецедентів є ітеративним і виконується шляхом поетапного уточнення.

Для виявлення прецедентів стануть в нагоді наступні питання.

Які функціональні можливості знадобляться конкретному актору від системи?

Система зберігає і зчитує інформацію? Якщо так, який з акторів ініціює цю поведінку?

Що відбувається, коли система змінює стан (наприклад, при запуску і виключенні системи)? Хто-небудь з акторів отримує при цьому повідомлення?

Які-небудь зовнішні події впливають на систему? Як система дізнається про ці події?

Чи взаємодіє система з якою-небудь зовнішньою системою?

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

Керованість на кінцях асоціації не визначається на діаграмі прецедентів.

Однак на кінцях може бути визначена кратність учасників взаємодії.

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

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

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

Ці обставини повинні уточнюватися в специфікаціях в кожному окремому випадку.

Після побудови діаграми прецедентів, кожний прецедент детально описують. Важливо пам’ятати, що прецедент – це текстовий опис. Основною помилкою є нехтування текстовим описом прецедента і зосередження головної уваги на побудові діаграми прецедентів. Діаграма є лише додатковим наочним зображенням, навіть, необов’язковим. UML не визначає стандарт для опису прецедентів. Компанії самостійно обирають стандарт опису прецедентів.

Розрізняють кілька ступенів формалізації прецедента:

стислий – анотація на один абзац, зазвичай вона описує лише основний успішний сценарій

вільний – неформальний стиль: опис займає кілька абзаців і охоплює кілька сценаріїв.

розгорнутий – найбільш докладний стиль опису, містить всі сценарії, передумови, результати,…

Часто використовують наступну специфікацію:

15) актори, що задіяні в прецеденті (виконавці);

17) постумови – результати, що отримують по закінченні прецедента;

19) альтернативні потоки або розширення (PD: Extension Points).

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

Основний потік іноді називають основним сценарієм (primary scenario), а альтернативні потоки – другорядними сценаріями (secondary scenarios).

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

прості відхилення – розгалуження основного потоку;

складні відхилення – альтернативні потоки.

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

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

В розділі основного сценарію описуються три види дій:

6. Зміна стану системи (наприклад запис або модифікація сутностей).

Для опису простого розгалуження можна використовувати ключове слово «Якщо», для опису дій, що повторюються можна використовувати ключове слово «Повторити Для» (For) <чого?>, а також «Виконувати Поки» (While).

1. Прецедент починається, коли Покупець вибирає опцію «знайти продукт».

2. Система запитує у Покупця критерій пошуку.

4. Система шукає продукти, відповідні критерію Покупця.

5. Якщо система знаходить відповідні продукти, тоді

5.1.1. Система виводить на екран мініатюрне представлення продукту.

5.1.2. Система виводить на екран короткий опис продукту.

5.1.3. Система виводить на екран ціну продукту.

6.1. Система повідомляє Покупця про те, що відповідні продукти не знайдені.

Деякі розробники вважають за краще всі розгалуження описувати в розширеннях (через альтернативні потоки). Для опису альтернативних потоків можна використовувати нумерацію літерами: 3а, 3б – позначають першу і другу альтернативу основного потоку, що розгалужуються від п. 3. І далі описувати як основний потік. Можна описувати кожний альтернативний потік окремо (тоді в специфікації прецедента задаються лише назви альтернативних потоків), задаючи йому наступні параметри:

1) ім’я <НазваПрецедента>:<НазваАльтернативногоПотоку>;

2) ID – можливе застосування ієрархічної нумерації;

Альтернативні потоки не повинні містити альтернативні потоки.

Альтернативні потоки можуть бути ініційовані трьома різними способами:

1. Альтернативний потік може бути ініційований замість основного потоку. Він ініціюється головним актором і повністю заміщає весь прецедент.

2. Альтернативний потік може бути ініційований після певного етапу основного потоку. Він повинен починатися таким чином:

1. Альтернативний потік починається після кроку X основного потоку.

3. Альтернативний потік може бути ініційований у будь-який момент в ході виконання основного потоку (PD: Exceptions). Починати його треба таким чином:

1. Альтернативний потік починається у будь-який момент часу.

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

Щоб виявити альтернативні потоки, потрібно уважно вивчити основний потік. На кожному кроці основного потоку необхідно шукати:

• помилки, які можуть виникнути в основному потоці;

• переривання, які можуть трапитися в конкретній точці основного потоку;

• переривання, які можуть відбутися в будь-якій точці основного потоку.

Основний принцип в моделюванні прецедентів – забезпечити необхідний мінімум інформації. Для розуміння функціонування системи може виявитися цілком достатнім короткий опис альтернативних потоків у вигляді одного рядка. Необхідно пам'ятати, що прецеденти виявляються, щоб зрозуміти необхідну поведінку системи, а не з метою створення повної моделі прецедентів.

1. Поняття актора. Хто або що може вистувати актором?

2. На яке питання відповідає діаграма прецедентів?

4. З яких будівельних блоків складається діаграма прецедентів?

5. За яким алгоритмом будується діаграма прецедентів?

6. З яких джерел можна брати інформацію для визначення акторів та прецедентів?

7. Які дані про актора можуть бути встановлені відповідно до UML?

8. Чи описує діаграма прецедентів взаємодії між акторами?

9. Чи може актор взаємодіяти з системою опосередковано?

11. Які бувають форми опису прецедента (ступені формалізації)?

12. Яким чином відображається ваємодія актора системою на діаграмі прецедентів?

15. Як слід описувати основний потік прецедента?

16. Які види дій можуть міститися в основному потоці прецедента?

17. Яким чином можна відображати рогалуження основного потоку прецедента?

19. Яким чином можуть бути ініційовані альтернативні потоки?

Что способствует осуществлению желаний? Стопроцентная, непоколебимая уверенность в своем...

ЧТО ПРОИСХОДИТ, КОГДА МЫ ССОРИМСЯ Не понимая различий, существующих между мужчинами и женщинами, очень легко довести дело до ссоры...

Что делать, если нет взаимности? А теперь спустимся с небес на землю. Приземлились? Продолжаем разговор...

ЧТО И КАК ПИСАЛИ О МОДЕ В ЖУРНАЛАХ НАЧАЛА XX ВЕКА Первый номер журнала «Аполлон» за 1909 г. начинался, по сути, с программного заявления редакции журнала...

Не нашли то, что искали? Воспользуйтесь поиском гугл на сайте: