Виявлення акторів
Розглянемо початкові дані для діяльності Виявлення акторів і прецедентів.
• Бізнес-модель – може бути надана розробникам моделі системи. Якщо вона є, це чудове джерело для збору вимог.
• Модель вимог – створення цієї моделі було описане в розділі 3 Арлоу. Ці вимоги є хорошим початковим матеріалом для процесу моделювання прецедентів. Зокрема, функціональні вимоги запропонують прецеденти і акторів. Нефункціональні вимоги – те, про що треба пам'ятати при створенні моделі прецедентів.
• Список можливостей – це набір потенційних вимог, які можуть бути представлені у формі загального опису, бачення (vision), проекту або чого-небудь подібного.
Актори – це ролі, які виконуються зовнішніми сутностями, що безпосередньо взаємодіють з системою.
Актор може представляти роль користувача або роль, що виконується іншою системою чи частиною апаратних засобів, що пов’язуються з системою. У UML 2 актори можуть також представляти інші контексти системи, забезпечуючи можливість об'єднання різних моделей прецедентів.
Для ідентифікації акторів необхідно відповісти на питання: хто або що використовує систему і які ролі виконуються акторами при взаємодії з системою. Наступні питання допоможуть ідентифікувати акторів.
Хто або що використовує систему?
Які ролі вони граю у взаємодії?
Хто встановлює систему?
Хто або що запускає і вимикає систему?
Хто обслуговує систему?
Які системи взаємодіють з даною системою?
Хто або що отримує і надає інформацію системі?
Чи відбувається що-небудь в точно встановлений час?
При моделюванні акторів необхідно пам'ятати наступні моменти.
Актори завжди є зовнішніми по відношенню до системи.
Актори взаємодіють безпосередньо з системою – так вони допомагають у визначенні контексту системи.
Актори представляють ролі, що виконуються людьми або сутностями, а не конкретних людей чи конкретні сутності.
Одна людина або сутність може грати по відношенню до системи безліч ролей одночасно або послідовно в часі.
У кожного актора має бути коротке, змістовне з прикладної точки зору ім'я.
Кожного актора повинен супроводжувати короткий опис (що даний актор з себе представляє з точки зору системи).
Як і в класах, в позначенні акторів можуть бути представлені атрибути актора і події, які він може отримувати. Такі позначення не часто використовуються і рідко відображаються на діаграмах прецедентів.
Якщо необхідно змоделювати щось, що відбувається з системою в певний момент часу, але що не ініціюється жодним з акторів, можна ввести актора під назвою Time (час).
Нотація акторів
Для відображення акторів, що моделюють зовнішні системи або апаратні засоби зазвичай не використовують стандартну нотацію.
Визначення прецедентів
Прецедент описує поведінку, що демонструється системою з метою отримання значущого результату для одного або більше акторів. Прецедент – це те, що повинна робити система за бажанням актора. Це «варіант використання» системи конкретним актором:
прецеденти завжди ініціюються актором;
прецеденти завжди описуються з точки зору акторів.
Зазвичай прецеденти розглядаються на рівні системи, але їх можна використовувати і для опису підсистеми або класу.
Визначення прецедентів краще за все розпочати зі списку акторів, а потім розглянути, як кожний актор збирається використовувати систему. За допомогою такої стратегії можна отримати список потенційних прецедентів. Ім’я <виконати щось>: «сформувати звіт», «перевірити код», «зареєструвати користувача».
Під час ідентифікації прецедентів можуть виявитися додаткові актори. Процес моделювання прецедентів є ітеративним і виконується шляхом поетапного уточнення.
Для виявлення прецедентів стануть в нагоді наступні питання.
Які функціональні можливості знадобляться конкретному актору від системи?
Система зберігає і зчитує інформацію? Якщо так, який з акторів ініціює цю поведінку?
Що відбувається, коли система змінює стан (наприклад, при запуску і виключенні системи)? Хто-небудь з акторів отримує при цьому повідомлення?
Які-небудь зовнішні події впливають на систему? Як система дізнається про ці події?
Чи взаємодіє система з якою-небудь зовнішньою системою?
Система генерує звіти?
Взаємодію між акторами та прецедентами зображають у вигляді суцільної лінії (це зв’язок асоціації), напрямок асоціації на діаграмі прецедентів не вказується стрілками. Він задається розташуванням актора по відношенню до прецедента: Якщо актор знаходиться лівіше чи вище за прецедент, це означає, що він ініціює прецедент і є головним, інакше – актор є другорядним, тобто взаємодію ініціює система, наприклад система надсилає актору результати виконання деяких дій або запитує в актора додаткову інформацію чи викликає деякі функції актора, що є зовнішньою системою. Зазвичай на діаграмі прецедентів зв’язки асоціації не мають назви, однак якщо назву визначено, вона може бути доповнена трикутною заповненою стрілкою, що вказує напрямок читання даної взаємодії. Ця стрілка не впливає на суть взаємодії.
PD: Property→GeneralTab → Orientation (Primary Actor, Secondary Actor).
Керованість на кінцях асоціації не визначається на діаграмі прецедентів.
Однак на кінцях може бути визначена кратність учасників взаємодії.
Якщо кратність більше одного з боку головного актора, це означає, що прецедент починається по виконанні деяких дій кількома конкретними учасниками взаємодії, що виконують визначену актором роль. При цьому в стандарті не вказується, чи це повинна бути одна дія, що має виконуватися учасниками одночасно (як наприклад, при запуску атомної бомби), чи це мають бути доповнюючі успішні дії (наприклад, один актор починає щось, а інший завершує).
Якщо кратність більше одного з боку другорядного актора, це може вказувати на одночасне сповіщення кількох учасників про деякі дії з боку системи (прецедента) або на послідовні дії, що направлені до різних учасників.
Якщо кратність більше одного з боку прецедента, це означає актор може бути залучений в кілька таких прецедентів одночасно. При цьому стандарт не визначає, як саме. Наприклад актор може одночасно викликати той самий прецедент або ці прецеденти можуть бути взаємовиключними в часі.
Ці обставини повинні уточнюватися в специфікаціях в кожному окремому випадку.