Варіант використання

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

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

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

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

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

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

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

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

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

Актори

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

Рис. 2. Графічне позначення актора

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

Примітка

Ім'я актора повинно бути достатньо інформативним з точки зору семантики. Цілком підходять для цієї мети найменування посад в компанії (наприклад, продавець, касир, менеджер, президент). Не рекомендується давати акторам імена власні або моделей конкретних пристроїв (наприклад, «маршрутизатор Cisco 3640»), навіть якщо це з очевидністю випливає з контексту проекту. Справа в тому, що одна й та сама особа може виступати в кількох ролях і, відповідно, звертатися до різних сервісів системи. Наприклад, відвідувач банку може бути як потенційним клієнтом, і тоді він затребує один з його сервісів, а може бути і податковим інспектором або слідчим прокуратури. Сервіс для останнього може бути абсолютно винятковим за своїм характером.

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

Примітка

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

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

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

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

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

Лекція 3. Діаграми класів

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

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

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

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

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

Клас (class) в мові UML служить для позначення безлічі об'єктів, які мають однаковою структурою, поведінкою та стосунками з об'єктами з інших класів. Графічно клас зображається у вигляді прямокутника, який додатково може бути розділений горизонтальними лініями на розділи або секції (рис. 6.1). У цих розділах можуть зазначатися ім'я класу, атрибути (змінні) та операції (методи).

Обов'язковим елементом позначення класу є його ім'я. На початкових етапах розробки діаграми окремі класи можуть позначатися простим прямокутником із зазначенням тільки імені відповідного класу (рис. 6.1, а). У міру опрацювання окремих компонентів діаграми опису класів доповнюються атрибутами (рис. 6.1, б) і операціями (рис. 6.1, в).

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

Лекція 5. Діаграма станів

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

Розглянемо простий приклад. Будь-яке технічний пристрій, таке як телевізор, комп'ютер, автомобіль, телефонний апарат у самому загальному випадку може характеризуватися такими своїми станами, як «справний» і «несправний». Інтуїтивно зрозуміло, який зміст вкладається в кожне з цих понять. Більш того, використання за призначенням даного пристрою можливо тільки тоді, коли воно знаходиться в справному стані. В іншому випадку необхідно зробити абсолютно конкретні дії щодо його ремонту та відновленню працездатності.

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

Раніше, ми відзначали, що кожна інформаційна система характеризується не тільки структурою складових її елементів, але і деяким поведінкою або функціональністю. Для загального уявлення функціональності модельованої системи призначені діаграми варіантів використання, які на концептуальному рівні описують поведінку системи в цілому. Але на даному етапі моделювання наступне завдання полягає в тому, щоб представити поведінку більш детально на логічному рівні, тим самим розкрити сутність відповіді на запитання: «В процесі якої поведінки система забезпечує необхідну функціональність?».

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

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

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

Лекція 6. Діаграма діяльності

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

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

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

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

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

У контексті мови UML діяльність (activity) являє собою деяку сукупність окремих обчислень, виконуваних автоматом. При цьому окремі елементарні обчислення можуть приводити до деякого результату або дії (action). На діаграмі діяльності відображається логіка або послідовність переходу від однієї діяльності до іншої, при цьому увага фіксується на результаті діяльності. Сам же результат може призвести до зміни стану системи або поверненню деякого значення.

Лекція 7. Діаграма послідовності

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

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

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

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

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

Дата добавления: 2015-07-15