Добавил:
Upload Опубликованный материал нарушает ваши авторские права? Сообщите нам.
Вуз: Предмет: Файл:
Самовчитель по UML.doc
Скачиваний:
4
Добавлен:
01.07.2025
Размер:
2.26 Mб
Скачать

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

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

Як актори даної системи можуть виступати два суб'єкти, один з яких є продавцем, а інший – покупцем. Кожний з цих акторів взаємодіє з даною системою продажу товарів по каталогу і є її користувачем, т.  е. вони обидва звертаються до відповідного сервісу «Оформити замовлення на покупку товару». Як випливає з істоти вимог, що висуваються до системи, цей сервіс виступає як варіант використовування діаграми, що розробляється, первинна структура якої може включати тільки двох вказаних акторів і єдиний варіант використовування (мал. 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. Ці особливості є предметом розгляду у всіх подальших розділах книги.

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

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