Приклад побудови діаграми варіантів використання

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

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

Мал. 4.12. Вихідна діаграма варіантів використання для прикладу розробки системи продажу товарів по каталогу

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

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

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

Отримана в результаті подальшої деталізації уточнена діаграма варіантів використання міститиме 5 варіантів використання і 2 акторів (мал. 4.13), між якими встановлені відношення включення і розширення.

Мал. 4.13. Уточнений варіант діаграми варіантів використання для прикладу системи продажу товарів по каталогу

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

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

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

Мал. 4.14. Один з варіантів подальшого уточнення діаграми варіантів використання для прикладу даної системи продажу

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

Мал. 4.15. Фрагмент діаграми варіантів використання, який в неявному вигляді присутній на уточненій діаграмі з відношенням асоціації між окремими компонентами

Примітка

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

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

Побудова діаграми варіантів використання є найпершим етапом процесу об'єктно-орієнтованого аналізу і проектування, мета якого – представити сукупність вимог до поведінки проектованої системи. Специфікація вимог до проектованої системи у формі діаграми варіантів використання є самостійною моделлю, яка в мові UML отримала назву моделі варіантів використання і має своє спеціальне стандартне ім'я або стереотип " useCaseModel".

У подальшому всі задані в цій моделі вимоги представляються у вигляді загальної моделі системи, яка складається з пакету Системи. Останній у свою чергу може бути ієрархією пакетів, на самому верхньому рівні яких міститься множина класів моделі проектованої системи. Якщо ж пакет системи із стандартним ім'ям " TopLevel Package" є підсистемою, то її абстрактна поведінка така ж, як і у вихідної системи.