язок одне одного, багато до одного і т.д. На малюнку 1.5 наведено приклад зв'язку між актором і варіантом використання.
Малюнок 1.5 - Візуальний елемент Communicate (з'єднання)
Малюнок 1.6 - Extends (розширення)
Автоматизоване робоче місце касира
Візуальний елемент Extends показує, що за деяких умов варіант використання UseCase2 може бути доданий до варіанту використання UseCase1. При цьому UseCase1 є точкою розширення для UseCase2. Розширення зображується стрілкою, спрямованої від варіанту використання, що забезпечує розширення, до основного варіанту використання. Стрілка забезпечується позначкою «extend».
Малюнок 1.7 - include (включення)
Зв'язок типу include від варіанту використання UseCase1 до варіанту використання UseCase2 показує, що варіант використання UseCase1 включає в себе також і поведінку специфіковану для варіанту використання UseCase2. Включення зображується стрілкою, спрямованої від основного варіанту використання до такого, що включається варіанту використання. Стрілка забезпечується позначкою «include».
Замість того, щоб описувати прецеденти безпосередньо, краще використовувати сценарій. Сценарій - послідовність кроків, що описують взаємодію користувача і системи. Опишемо сценарій «Прийом комунальних платежів».
Платник комунальних послуг являє касиру квитанцію. Касир вводить дані з отриманою квитанції (вводить дані платника і визначає одержувача). Касир називає платнику суму оплати і приймає гроші. Касир проводить платіж в системі і віддає платнику чек.
Подібний сценарій описує тільки одну ситуацію, яка може мати місце. Якщо під час проведення платежу станеться якийсь збій зв'язку, то подібна ситуація може послужити предметом вже іншого сценарію. В іншому випадку касир може обслуговувати постійного клієнта, інформація про який вже є в системі, і вводити інформацію по ньому не потрібно, і це породжує ще один сценарій.
У будь-якому разі, всі ці сценарії мають одну спільну мету: у платника - оплатити послуги, а у касира - обслужити платника і здійснити платіж. Правда, касир не завжди може досягти зазначену мету. Саме мета є ключем до прецедентів. Сформулюємо сценарій прецеденту «Прийом комунальних платежів».
Описавши сценарій виконання процесу прийому комунальних платежів, можна перейти до його графічного опису. Зі сценарію відразу можна виділити двох акторів - касир і платник.
Малюнок 1.8 - Касир і платник
На рис.6 зображені основні дії, які виконуються при прийомі комунальних платежів. Як можна помітити, прецедент «Отримати чек» залежить від прецеденту «Надрукувати чек». Цю залежність можна відобразити на діаграмі (малюнок 1.9)
Малюнок 1.9 - Діаграма прецедентів касир-платник
Отримана діаграма повністю описує взаємодію двох основних акторів - касира і платника. Однак при більш глибокому розгляді процесу прийому комунальних платежів, можна виділити ще двох акторів:
ККМ - контрольно-касова машина, за допомогою якої касир друкує чек, що означає проведення платежу, який далі передається платнику
АРМ «Касир» і система зберігання і обробки інформації про проведені платежі (БД платежів)
Малюнок 1.10 - Розгорнута діаграма системи
На малюнку 1.10 представлено більше повний опис функціональних зв'язків у системі прийому комунальних платежів.
Після опису прецедентів системи можна перейти до опису бізнес-процесів в нотації BPMN. Правильно побудована діаграма прецедентів дозволить швидко перейти до розгляду бізнес процесів, так як можна встановити зв'язок між акторами в діаграмі прецедентів і пулами (доріжками) в діаграмах в нотації BPMN, а прецеденти розкриваються за допомогою діяльностей. Однак перед тим як описувати процес прийому комунальних платежів в нотації BPMN, необхідно чітко визначити, з точки зору якоїсь діяльності описується цей процес. Від цього може залежати правильність пос?? роїння всієї системи в цілому. Побудуємо на прикладі аналізованої системи дві діаграми, які описують процес прийому платежів, але з точки зору різних акторів.
Малюнок 1.11 - Процес з погляду платника комунальних платежів
Діаграма, наведена на малюнку 1.11, описує процес прийому платежів з погляду людини, яка оплачує послуги. За допомогою основних графічних елементів показані дії платника. Нотація BPMN дозволила показати і альтернативний хід процесу в разі виникнення помилкових ситуацій. Розглянемо більш детально цей процес.
...
