Діаграма прецедентів (варіантів використання) UML

1. Діаграма прецедентів (варіантів використання) UML Для чого використовується техніка креативності
2. План дій
3. Зауваження (опис)
4. Як застосовувати техніку креативності
5. як навчитися
6. вміст прецедентів
7. діаграми прецедентів
8. Прецеденти та можливості (або побажання)

Діаграма прецедентів (варіантів використання) UML

Для чого використовується техніка креативності

Визначити функціональні вимоги до системи.

Описати типові взаємодії між користувачами системи і самою системою і надати опис процесу її функціонування.

План дій

У розділі «Опис» вивчіть основний набір символів діаграми прецедентів, необхідний для того, щоб вміти читати діаграми.

Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви можете спробувати свої сили в самостійному складанні діаграм прецедентів.

Зауваження (опис)

Тут представлений основний набір символів діаграми варіантів використання (прецедентів), необхідний для того, щоб зуміти прочитати діаграму. Після ознайомлення з іншими розділами ( «Приклад», «Застосування») ви зможете складати діаграми варіантів використання системи (ВІС) самостійно!

Як застосовувати техніку креативності

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

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

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

як навчитися

приклад використання

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

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

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

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

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

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

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

вміст прецедентів

Не існує стандартного способу опису вмісту прецеденту; в різних випадках застосовуються різні формати. На рис. 9.1 показаний загальний стиль використання. Ви починаєте з вибору одного з сценаріїв в якості головного успішного сценарію (main success scenario). Спочатку ви описуєте тіло прецеденту, в якому головний успішний сценарій представлений послідовністю нумерованих кроків. Потім берете інший сценарій і вставляєте його у вигляді розширення (extension), описуючи його в термінах змін головного успішного сценарію. Розширення можуть бути успішними - користувач досяг своєї мети, як у варіанті 3a, або невдалими, як у варіанті 6a.

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

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

Розширення всередині прецеденту вказує умова, яке призводить до взаємодій, відмінним від описаних в головному успішному сценарії (main success scenario, MSS), і встановлює, в чому полягають ці відмінності. Розширення починається з імені кроку, на якому визначається ця умова, і надає короткий опис цієї умови.
Дотримуйтесь цій умові, нумеруя кроки таким же чином, що і в головному успішному сценарії. Закінчуйте ці кроки описом точки повернення в головний успішний сценарій, якщо це необхідно.

Структура прецеденту - це відмінний інструмент для пошуку альтернатив головного успішного сценарію. На кожному кроці питайте:
«Що може ще статися?» І зокрема «Що може піти не так?»

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

Складний крок в прецеденті можна представити іншим прецедентом. У термінах мови UML ми говоримо, що перший прецедент включає (includes) другий. Не існує стандартного способу показати в тексті включення прецеденту, але я думаю, що підкреслення, яке передбачає гіперпосилання, працює прекрасно, а в багатьох інструментах дійсно буде гіперпосиланням. Так, на рис. 9.1 перший крок включає шаблон «переглядає каталог і вибирає товари для покупки».

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

Поряд з кроками сценарію можна вставити в прецедент додаткову загальну інформацію.
• передумовою (pre-condition) описує дії, обов'язково виконуються системою перед тим, як вона дозволить почати роботу прецеденту. Це корисна інформація, що дозволяє розробникам не перевіряти деякі умови в їхній програмі.
• Гарантія (guarantee) описує обов'язкові дії системи після закінчення роботи шаблону відповіді. Успішні гарантії виконуються після успішного сценарію; мінімальні гарантії виконуються після будь-якого сценарію.
• Тригер (trigger) визначає подія, що ініціює виконання прецеденту.

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

діаграми прецедентів

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

Найкраще обмірковувати діаграму прецедентів за допомогою графічної таблиці, яка б показала їх вміст. Вона нагадує діаграму контексту, використовувану в структурних методах, оскільки вона показує межі системи і її взаємодія з зовнішнім світом. Діаграма прецедентів показує акторів, прецеденти і відносини між ними:
• Які актори виконують той чи інший прецедент
• Які прецеденти включають інші прецеденти
У мові UML крім відносини «include» (включає) є й інші типи відносин між прецедентами, наприклад відношення «extend» (розширює). Настійно рекомендуємо його уникати. Занадто часто розробники цілими командами надовго занурювалися в розгляд різних відносин між прецедентами, даремно витрачаючи сили. Краще приділяйте більше уваги текстового опису прецеденту; саме в цьому полягає справжня цінність цієї технології.

Прецеденти та можливості (або побажання)

У багатьох підходах можливості системи застосовуються для опису вимог до системи; в екстремальному програмуванні (Extreme Programming) можливості системи називаються побажаннями користувача. Спільним є питання про те, як встановити відповідність між можливостями і прецедентами.

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

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

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

Якщо ви хочете навчитися працювати на фрілансі професійно, запрошуємо на курс « Як заробляти на фрілансі ».

Перейти на сторінку курсу

Якщо вам сподобалася стаття - поділіться посиланням з друзями!