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

визначати прецеденти?
Опис прецедентів. Потоки подій та сценарії
Відношення між акторами та

прецедентами
Залучення ділових моделей при пошуку прецедентів та акторів
Відношення узагальнення
Організація прецедентів. Відношення залежності між прецедентами. Відношення включення (include) та розширення (extend)
Варіанти діаграм прецедентів

первісним, концептуальним представленням (концептуальною моделлю) програмних систем в процесі проектування

й розробки цих систем.
Діаграми прецедентів виступають основою подальшої деталізації системи у формі різних логічних і фізичних моделей. (Управління прецедентами є одним з наріжних каменів RUP.) Зокрема, прецеденти допомагають перевіряти й контролювати архітектуру ПС у процесі її розробки.
Діаграмами прецедентів:
визначаються загальні кордони та контекст ПС;
уточнюється зовнішня функціональна поведінка ПС;
визначається первісна документація, яка може використовуватись для предметного обговорення ПС розробниками, замовниками, користувачами та іншими зацікавленими сторонами – стейкхолдерами.

представляють основні ідеї, закладені у RUP
Модель архітектури “4+1”

граф) складається з:
прецедентів та акторів (як вершин графа);
відношень (як дуг

графа).

складі) або діяч – це об'єкт (дехто чи дещо), який

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





Приклади акторів: клієнт, адміністратор, білінгова система.
Важливо зауважити два моменти:
Поняття актора несе ролеву ознаку. (Актори, по суті, – це типи: актором є клієнт чи адміністратор, а не Петренко, Шевченко чи Буш).
Акторами можуть виступати інші програмні системи.

Актори позначаються у діаграмах прецедентів стилізованими людськими фігурками.

основних акторів.
Основні актори – це ті актори, які ініціюють взаємодію

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

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

Уэнди Боггс, Майкл Боггс)

(функцій) системи з точки зору отримання основними акторами деяких суттєвих

для них результатів.
Простий спосіб виявлення прецедентів полягає в тому, що треба розглянути кожного основного актора та визначити, які суттєві результати (суттєві цілі) він може переслідувати, використовуючи ПС.
Отже, прецеденти мають функціональне забарвлення, “прив'язуючись” до суттєвих цілей основних акторів.




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

Прецеденти зображуються еліпсами.
Як правило, для іменування прецедентів використовуються дієслова чи короткі дієслівні фрази (“Створення таблиці”, “Створити таблицю”).

(функцій) ПС з точки зору отримання основними акторами деяких суттєвих

для них результатів при взаємодії з ПС.
Айвер Якобсон (Ivar Jacobson) у середині 1980-х років придумав шведський термін "anvendningfall", що в приблизному перекладі означає "ситуація використання" чи, англійською, "usage case" ("case of use”). Працюючи над англійським перекладом своєї статті, він вирішив, що термін "usage case" звучить якось не по-англійськи, і переробив його в "use case".

їм у відповідність описи – потоки подій.
Потоки подій описують поведінку

системи в процесі отримання необхідного суттєвого результата (цілі). Опис здійснюється мовою предметної області, а не в термінах реалізації.
Коли Айвера Якобсона (Ivar Jacobson) запитали, чи не має він моделі для формального опису варіантів використання, він відповів: ”Звичайно, я зробив таку модель. Є тільки одна проблема – ніхто не хоче нею користуватися".

що складається з напівформальних текстів.
У цьому випадку можна:
з одного

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

потоку подій може використовуватись наступна структура:
заголовок (наприклад, “Потік подій для

прецедента <Зняти гроші>”);
короткий опис потоку (наприклад, “Дозволяє клієнту зняти гроші з його рахунку”);
передумови (pre-conditions); //послідовність виконання прецедентів!
головний потік подій та, можливо, його підпотоки;
альтернативні потоки подій;
постумови (post-conditions).

(Перед-, постумови важливі для генерації сценаріїв тестів).

подій для прецедента ”);

// X - номер потоку (прецедента)
X.1. Передумови (pre-conditions).
X.2. Головний потік.
X.3. Підпотоки (S-1, S-2, …).
X.4. Альтернативні потоки (E-1, E-2, ).
X.5. Постумови (post-conditions).

“Банкомат”)
(Передумова – картка сприйнята банкоматом).
1. Банкомат пропонує обрати мову спілкування,

а за цим - увести код. Клієнт уводить відповідну інформацію.
2. Система перевіряє код (E-1) і пропонує обрати варіант транзакції.
// E-1 – альтернативний потік “Невірний код”.
3. Клієнт обирає транзакцію “Зняти гроші” і задає суму, яку він бажає зняти.
4. Система перевіряє наявність відповідної суми на рахунку (E-2).
// E-2 – альтернативний потік “Немає достатньо грошей”.
. . .

прецедентів так само, як і для акторів, природним є використання

відношень на зразок “типи - екземпляри”.
Коли користувач Петренко (як екземпляр діяча) взаємодіє із системою, виконується (спрацьовує) деякий сценарій (sсепаriо).
Приклад. Прецедент “Зняти гроші”. Сценарії:
Петренко зняв 20 грн. у банкоматі.
Ющенко тричі уводив невірний код, і банкомат не повернув йому картку. ...
Зрозуміло, що одному прецеденту можуть відповідати кілька (як правило багато) різних сценаріїв, і, якщо на потік подій подивитись з “позиції типу”, то його “екземплярами” виступатимуть сценарії.
Множини сценаріїв можуть об'єднуватись у типові сценарії – т. з. основні сценарії.

набір основних сценаріїв. І не завжди (не у кожному сценарії)

відповідна ціль виявляється досяжною. (Приклад: людина вводить невірний пароль при одержанні грошей з банкомата. А якщо картка крадена! Система має переконатися, що людині можна спілкуватися з банкоматом.)
Отже, опис прецедента іноді доцільно поділяти дві частини: опис послідовності дій, коли “усе йде, як треба” та опис того, як поводиться система, коли відбувається якийсь збій.
При цьому найбільшу практичну користь, яку можна отримати з опису варіанта використання, являє собою не основний результативний сценарій, а опис саме альтернативної поведінки, коли бажаний (цільовий) результат не досягається.
Практика свідчить, що основний сценарій може займати лише від чверті до однієї десятої всього опису прецедента.

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

рівні деталізації опису прецедентів: короткий опис, звичайний опис і повний

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

не доводилося писати основний сценарій, у якому було б більше

дев'яти кроків: “ Справа не в тім, що дев'ятка - моє щасливе число, просто на той час, як я визначу другорядні цілі користувача на досить високому рівні абстракції і позбудуся від згадування елементів дизайну системи, у сценарії завжди виявляється менше дев'яти кроків”.
Отже, якщо основний сценарій містить до дев'яти кроків, весь варіант використання буде займати максимум дві-три сторінки, що робить його читабельним.
Не рекомендується включати в опис прецедентів специфіку інтерфейса користувача.

інтерфейса
Чому не рекомендується?
По-перше, дизайн доцільно розробляти, коли вже

відомо, що має робити система і як (!) вона повинна працювати.
По-друге, дизайн інтерфейса – дуже непостійна річ, часто потребує змін. Якщо описувати інтерфейс, беручи за основу варіанти використання, то вийде, що цей опис потрібно буде дуже часто міняти.
На жаль, новачки вважають своїм обов'язком описувати всі кнопки "ОК", поля введення, вікна і т.п. Цьому є тільки одне виправдання – люди люблять працювати з конкретними концепціями.
Краще витрачати час і сили на те, щоб писати у нейтрально-технологічному стилі: "Система пропонує набір таких-то можливостей. Користувач обирає визначену дію".
Результати виправдають зусилля – описи прецедентів стануть більш короткими і стабільними, їх можна буде легко прочитати і зрозуміти.

(система “Банкомат”)
(Передумова – картка сприйнята банкоматом).
1. Банкомат пропонує обрати мову

спілкування, а за цим - увести код. Клієнт уводить відповідну інформацію.
2. Система перевіряє код (E-1) і пропонує обрати варіант транзакції.
// E-1 – альтернативний потік “Невірний код”.
3. Клієнт обирає транзакцію “Зняти гроші” і задає суму, яку він бажає зняти.
4. Система перевіряє наявність відповідної суми на рахунку (E-2).
// E-2 – альтернативний потік “Немає грошей”.
. . .

Снятие денег со счета через банкомат
Главное действующее лицо. Клиент
Масштаб. Банкомат
Уровень.

Цель пользователя
Основной успешный сценарий.
1. Клиент вставляет карточку в банкомат.
2. Банкомат считывает с карточки код банка, номер счета, PIN-код и сверяет код банка и номер счета с данными в банке.
3. Клиент вставляет карточку и вводит PIN-код. Банкомат проверяет совпадение введенного кода и кода на карточке.
4. Клиент выбирает режим "Снять деньги наличными" и вводит сумму, кратную $5.
5. Банкомат соединяется с центральной системой в банке, передает данные о транзакции, получает подтверждение и новый остаток по счету.
6. Банкомат выдает деньги, возвращает карточку и печатает чек, на котором указан новый остаток по счету.
7. Банкомат записывает информацию о транзакции в журнал.

виробляється, досліджуючи “архітектурно істотні” сценарії (для підмножини прецедентів, що представляють

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

таким чином, щоб для чергової версії вони разом забезпечували реалізацію

значної частини поведінки ПС та вказували на необхідність “розібратися” з наступним найбільшим ризиком.
(Пріоритет – Rank – можна встановлювати для прецедентів при їх специфікації).
Г.Буч рекомендує проектувати 5±2 проміжних випусків системи, RUP – 6±3 випуски .

– фази задуму (або початку) з віхою “Вимоги життєвого циклу”

(LCO – lifecycle objective) має бути здійснена ідентифікація основних прецедентів та акторів, а також описані найбільш важливі прецеденти. Бажаним вважається також отримання первісної моделі прецедентів, розробленої на 10-20%.
Модель прецедентів з ідентифікованими всіма прецедентами та акторами, з описом більшості прецедентів (мінімум на 80%) вимагається на виході

другої фази – фази уточнення з віхою “Архітектура життєвого циклу” (LCA – lifecycle architecture) .

прецедентами – комунікації – у діаграмах прецедентів представляються односпрямованими асоціаціями

(відповідний стереотип - <>) і зображаються суцільною стрілкою у напрямку від “ініціатора зв'язку”. Це єдиний тип відношень, які можливі між акторами та прецедентами , тому можна цей стереотип і не задавати.

ПС, представляючи схеми потоків управління (від однієї діяльності до іншої).
Зокрема,

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

викладачам”, “Надіслати електронні листи студентам” (з підтримкою цих можливостей безпосередньо

в ІС!).
Мабуть, не варто автоматизовува-ти (реалізовувати в ІС) діяльність “Багаторазові нагадування кура-тором студентів про необхідність обрати теми дипломних робіт”.

задачі на автоматизацію: “Оприбуткування товару на складі підприємства від продавця”.
Документ

(вхідний, вихідний) - дія -підрозділ - виконавець.
На основі опису бізнес-процесів з використанням діаграми діяльності (activity diagram) визначаються (і позначаються кольором) діяльності, які варто автоматизувати:
1. Виписує доручення;
2. Виписує прийомний акт у двох екземплярах;
3. Реєструє товар у картотеці;
4. Передає екземпляр акта в бухгалтерію;
5. Одержує прибутковий акт.

Е.Б. Золотухина, Р.В. Алфимов Пример описания предметной области с использованием Unified Modeling Language (UML) при разработке программных систем, Interface Ltd., 2001

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

успадковує поведінку й семантику свого батька, може заміщувати чи доповнювати його поведінку та, крім того, може бути підставлений усюди, де з'являється його батько.
Відношення узагальнення можуть застосовуватись і між акторами. Це, можливо, більш звично. До того ж, у Rational Rose для специфікації акторів використовується та ж сама форма, що і у випадку класів (тобто актори по суті розглядаються як класи).
Узагальнення – це єдиний тип відношень, який може задаватись між акторами. (Можна, наприклад, визначати загальні типи акторів, а потім спеціалізувати їх, створюючи різновиди.)
Відношення узагальнення між прецедентами (акторами, а також між класами у діаграмах класів) зображуються у вигляді лінії з незафарбованою стрілкою (стрілка спрямована у бік батьківського прецедента, актора чи класа).

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

найголовніших стратегій у програмування.
Виходячи з неї може бути доцільним уведення додаткових прецедентів. Як наслідок, прецеденти потребують організації на базі відношень, які фіксують залежності між існуючими прецедентами з огляду на згадану стратегію.
Загалом, між прецедентами можуть існувати й інші семантичні залежності, які іноді також доцільно представляти у діаграмах (для зображення відношень залежностей використовуються пунктирні стрілки).
Усе ж найважливішими випадками відношень залежності є відношення включення та розширення зі стереотипами <> та <>, які втілюють застосування стратегії повторного використання коду.
Зауваження:
у Rational Rose ці стереотипи застосовуються не тільки для відношення залежності, а й для односпрямованої асоціації;
<> та <> як залежності не дуже “стикуються” щодо позиції “використання коду” (напрямки стрілок чомусь протилежні?!). Відмінність цих відношень виявляється з огляду на обов'язковість чи не обов'язковість використання функціональності, що відповідає прецеденту).

означає, що в деякій “точці” опису потоків подій базового прецедента

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

(не ініціюється безпосередньо актором). В UML такі прецеденти вважаються абстрактними,

їх імена на діаграмі зображаються курсивом).

базовий прецедент включає поведінку іншого, можна просто писати слово include,

за яким іде ім'я прецедента, що включається.
Приклад: include(“Перевірити клієнта”).
У діаграмі прецедентів відношення включення зображують у вигляді залежності зі стереотипом <> (пунктирна стрілка спрямована від базового прецедента до того, що включається, абстрактного).

Використання відношення включення (include) у потоках подій та у діаграмах прецедентів

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

поведінку системи. (Моделюються підпотоки, виконувані тільки при певних умовах).

містити кілька точок розширення, ідентифікованих іменем прецедента, що використовується для

розширення.
Приклад: При обранні . . . extend(“Надати квитанцію”).
На діаграмі прецедентів відношення розширення зображують у вигляді залежності зі стереотипом extend. Пунктирна стрілка має бути спрямована до базового прецедента (до прецедента, який розширюється), від абстрактного (того, що розширює).

Використання відношення розширення (extend) у потоках подій та у діаграмах прецедентів

актори та основні, можливо всі, прецеденти);
діаграма з прецедентами для окремого

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

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

між собою, реалізуючи прецедент.

car accident
1. Claimant submits claim with substantiating data.
2. Insurance company

verifies claimant owns a valid policy
3. Insurance company assigns agent to examine case
4. Agent verifies all details are within policy guidelines
5. Insurance company pays claimant
Extensions:
1a. Submitted data is incomplete:
1a1. Insurance company requests missing information
1a2. Claimant supplies missing information
2a. Claimant does not own a valid policy:
2a1. Insurance company declines claim, notifies claimant, records all this, terminates proceedings.
3a. No agents are available at this time
3a1. (What does the insurance company do here?)

Sample. System under discussion: the insurance company (http://alistair.cockburn.us) (1)

(http://alistair.cockburn.us) (2)
4a. Accident violates basic policy guidelines:
4a1. Insurance company declines

claim, notifies claimant, records all this, terminates proceedings.
4b. Accident violates some minor policy guidelines:
4b1. Insurance company begins negotiation with claimant as to degree of payment to be made.
Variations:
1. Claimant is
a. a person
b. another insurance company
c. the government
5. Payment is
a. by check
b. by interbank transfer
c. by automatic prepayment of next installment
d. by creation and payment of another policy

Risberg, Rick Evans, Portia Tung)

Rose”, Уэнди Боггс, Майкл Боггс) (1/2)
Primary Flow of Events for

‘Enter New Order’ Use Case

1.The salesperson selects the ‘Create New Order’ option from the options menu.
2.System displays the Order Detail form.
3.Salesperson enters the order number, customer, and items ordered.
4.Salesperson saves the order.
5.System creates a new order and saves it to the database.

Rose”, Уэнди Боггс, Майкл Боггс) (2/2)

to the Unified Modeling Language» - www.rational.com)

to the Unified Modeling Language» - www.rational.com)