PrIS

381

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

Точка розширення може бути як окремою точкою в послідовності дій, так і множиною окремих точок. Якщо відношення розширення має деяку послідовність точок розширення, тільки перша з них може визначати множину окремих точок. Всі решта мають визначати лише одну таку точку, яка із точок має бути першою точкою розширення, тобто визначатися єдиним розширенням. Такі посилання на розташування точок розширення можуть зображаттися різними способами, наприклад, за допомогою тексту примітки природною мовою (рис. 18.8), перед- і післяумов, а також за допомогою використання імен станів в автоматі.

Рис. 18.8. Графічне зображення відношення розширення з примітками умов виконання варіантів використання.

18.5.3. Відношення узагальнення

Відношення узагальнення служить для вказання на той факт, що деякий варіант використання А може бути узагальнений до варіанту використання В. У цьому випадку варіант А буде спеціалізацією варіанту В. При цьому В називається предком або батьком по відношенню до А, а варіант А – нащадком по відношенню до варіанту використання В. Отже, нащадок успадковує всі властивості і поведінку свого батька, а також може бути доповнений новими властивостями й особливостями поведінки. Графічно таке відношення позначається суцільною лінією зі стрілкою, яка вказує на батьківський варіант використання (рис. 18.9). Ця лінія зі стрілкою має спеціальну назву – стрілка "узагальнення".

383

18.5.4. Відношення включення

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

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

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

Відношення включення, напрямлене від варіанту використання А до варіанту використання В, вказує, що кожний екземпляр варіанту А включає функціональні властивості, задані для варіанту В. Ці властивості спеціалізують поведінку відповідного варіанту А на відповідній діаграмі. Графічно таке відношення позначається пунктирною лінією зі стрілкою (варіант відношення залежності), напрямленою від базового варіанту використання до того, що включається. При цьому така лінія зі стрілкою позначається ключовим словом "include" ("включає"), як показано на рис. 18.11.

384

Рис. 18.11. Приклад графічного зображення відношення включення між варіантами використання.

Примітка

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

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

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

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

(рис. 18.12).

385

Рис. 18.12. Початкова діаграма варіантів використання для прикладу розроблення системи продажу товарів за каталогом.

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

Примітка

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

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

ітому між ними матиме місце відношення включення.

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

386

продажу. Цілком природно зображати сервіс "Запитати каталог товарів" як самостійний варіант використання.

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

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

“розширює”

Запитати каталог товарів

Рис. 18.13. Уточнена діаграма варіантів використання для прикладу системи продажу товарів за каталогом.

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

Урамках загальної парадигми ООАП подібна деталізація може виконуватися у двох основних напрямах.

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

Уцьому випадку діаграма може бути доповнена варіантом використання "Оформити замовлення на придбання комп'ютера" і акторами "Покупець

387

комп'ютера" і "Продавець комп'ютерів", які пов'язані з відповідними компонентами діаграми відношення узагальнення (рис. 18.14).

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

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

Для пояснення викладеного можна навести фраґмент діаграми варіантів використання для розглянутого прикладу, на якому явно вказані відношення асоціації між компонентами-нащадками (рис. 13.15). Таке

388

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

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

Примітка

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

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

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

389

використання є самостійною моделлю, яка в мові UML отримала назву моделі варіантів використання і має своє спеціальне стандартне ім'я або стереотип "useCaseModel".

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

18.7. Рекомендації з розроблення діаграм варіантів використання

Головне призначення діаграми варіантів використання полягає у формалізації функціональних вимог до системи за допомогою понять відповідного пакету і можливості узгодження отриманої моделі із замовником на ранній стадії проектування. Будь-який з варіантів використання може бути підданий подальшій декомпозиції на множині підваріантів використання окремих елементів, які утворюють початкову сутність. Загальна кількість акторів, що рекомендується, у моделі – не більше як 20, а варіантів використання – не більше як 50. Інакше модель втрачає свою наочність і, можливо, замінює собою одну з деяких інших діаграм.

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

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

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

390

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

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

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

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

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