Основний потік

1. Клієнт вставляє свою картку в АТМ.

2. АТМ виводить привітання і пропонує клієнтові ввести PIN-код.

3. Клієнт вводить PIN-код.

4. АТМ підтверджує введений код.

5. АТМ виводить список доступних дій.

6. Клієнт вибирає пункт «Зняти гроші».

7. АТМ запрошує, суму яку треба зняти.

8. Клієнт вводить потрібну суму.

9. АТМ підтверджує достатність грошей на рахунку.

10. АТМ віднімає потрібну суму з рахунку клієнта.

11. АТМ видає клієнтові потрібну суму готівкою.

12. АТМ повертає клієнтові його картку.

13. АТМ друкує чек для клієнта.

14. Варіант використання завершується.

Альтернативний потік 4а. Введення неправильного PIN-коду

4а1. Якщо PIN-код введений неправильно, АТМ інформує клієнта.

4а2. АТМ повертає клієнтові його картку.

4а3. Варіант використання завершується.

Альтернативний потік 9а. Недостатньо грошей на рахунку

9а1. Якщо грошей на рахунку недостатньо, АТМ інформує клієнта.

9а2. АТМ повертає клієнтові його картку.

9а3. Варіант використання завершується.

Альтернативний потік 9б. Помилка у підтвердженні суми

9б1. Якщо при підтвердженні запрошуваної суми відбулася помилка, АТМ повідомляє про це клієнта і дає йому номер телефону служби підтримки клієнтів банку.

9б2. АТМ заносить відомості про помилку в журнал помилок. Кожен запис містить дату і час помилки, ім'я клієнта, номер його рахунку і код помилки.

9б3. АТМ повертає клієнтові його картку.

9б4. Варіант використання завершується.

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

Шаблон RUP для опису варіанта використання схожий на запропонований Коберном, він відрізняється тим, що альтернативні потоки описуються окремо від решти розширень.

1. Назва варіанту використання.

1.1. Короткий опис.

1.2. Дійові особи.

1.3. Трігери.

2. Потік подій (сценарій).

2.1. Основний потік.

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

2.2.1. Умова 1

2.2.2. Умова 2

...

3. Спеціальні вимоги.

3.1. Платформа.

.

4. Передумови.

5. Післяумови.

6. Точки розширення.

Типові помилки в описах варіантів використання:

Ø Відсутня система (описані тільки дії акторів - дійових осіб).

Ø Відсутня основна дійова особа (описані лише дії системи).

Ø Занадто багато деталей інтерфейсу користувача (розписано які саме дані і в якому порядку вводить користувач, які кнопки натискає і т. п.).

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

Зв'язки між варіантами використання і дійовими особами відображаються на діаграмі варіантів використання (рис. 5.1.).

Правила складання цих діаграм:

  1. Кожен неабстрактний варіант використання повинен бути ініційований дійовою особою (зображається на діаграмі стрілкою-комунікацією від актора до варіанта використання).
  2. Не моделюйте зв'язки між дійовими особами.
  3. Не сполучайте стрілкою (комунікацією) два варіанти використання безпосередньо. Діаграми даного типу описують тільки, які варіанти використання доступні системі, а не порядок їх виконання. Для відображення порядку виконання варіантів використання застосовують діаграми діяльності.
  4. Уникайте численних і заплутаних зв'язків між дійовими особами і варіантами використання.
  5. Зв'язок <<include>> (включення) між реальним варіантом використання і абстрактним варіантом використання застосовується в тих ситуаціях, коли є який-небудь фрагмент поведінки системи, який повторюється більш ніж в одному варіанті використання, оформлений як абстрактний use-case.

 

Рис. 5.1. Діаграма варіантів використання

 

  1. Зв'язок <<extend>> (розширення) між абстрактним і реальним варіантом використання застосовується при описі змін у нормальній поведінці системи, оформленій як абстрактний use-case.

 

 

Рис. 5.2. Зв’язки включення і розширення

 

Методика моделювання варіантів використання в технології Rational Unified Process передбачає спеціальну угоду, пов'язану з групуванням структурних елементів і діаграм моделі. Ця угода включає наступні правила:

Ø Всі дійові особи, варіанти використання і діаграми варіантів використання поміщаються в пакет з ім'ям Use Case Model.

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

o структуризації моделі відповідно до типів користувачів (дійових осіб);

o функціональна декомпозиція;

o розділення моделі на пакети між групами розробників (як об'єкти управління конфігурацією).

Специфікація вимог у технології Rational Unified Process не вимагає обов'язкового моделювання бізнес-процесів організації, для яких створюється ПЗ, проте, наявність бізнес-моделей істотно спрощує побудову системної моделі варіантів використання.

 

 

 

Рис. 5.3. Приклад переходу від бізнес-моделі до моделі варіантів-використання.

 

При переході від бізнес-моделі до початкової версії моделі варіантів використання застосовуються наступні правила:

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

Ø Варіанти використання для даної дійової особи створюються на основі аналізу обов'язків відповідного виконавця (у простому випадку для кожної операції виконавця створюється варіант використання, який реалізовує дану операцію в системі).

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

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

Для опису функціональних вимог крім діаграм варіантів використання використовуються діаграми діяльності:

для опису поведінки, яка включає велику кількість паралельних процесів;

для аналізу варіанту використання (описують послідовність дій і їх взаємозв'язок);

для аналізу потоків робіт (workflow) у різних варіантах використання. Коли варіанти використання взаємодіють один з одним, діаграми діяльності є засобом представлення і аналізу їх поведінки.

Приклад:

 

Рис. 5.4. Приклад діаграми діяльності

 

Модель варіантів використання можна вважати завершеною, якщо є ствердна відповідь на наступні питання:

Ø Чи можна на підставі моделі сформувати чітке уявлення про функції системи і їх взаємозв'язки?

Ø Чи присутня кожна функціональна вимога хоч би в одному варіанті використання? Якщо вимога не знайшла віддзеркалення у варіанті використання, вона не буде реалізовано.

Ø Чи врахували ви, як з системою працюватиме кожна зацікавлена особа?

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

Ø Чи врахували ви всі зовнішні системи, з якими взаємодіятиме дана?

 

Література до лекції 5

 

1. Коберн А. Современные методы описания функциональных требований к системам.: Пер. с англ. – М. Лори, 2002.

2. Вендров А. М. Проектирование программного обеспечения экономических информационных систем. 2-е изд. – М.: Финансы и статистика, 2005. Параграфы 2.4-2.5.

3. Соммервил И. Инженерия программного обеспечения. 6-е изд.: Пер. с англ. – М.: Вильямс, 2002. – Главы 5, 6.

4. Якобсон А., Буч Г., Рамбо Дж. Унифицированный процесс разработки программного обеспечения.: Пер. с англ. – СПб.: Питер, 2002. – Главы 6, 7.

5. Кулямин В. В. Технологии программирования. Компонентный подход. – М.: Бином. Лаборатория знаний. 2007. Лекция 4.