20. Призначення та правила побудови діаграми прецедентів uml: типи зв’язків між прецедентами(з прикладами), зображення на діаграмі прецедентів ролей (акторів).

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

Розробка діаграми прецедентів переслідує цілі:

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

• Сформулювати загальні вимоги до функціональної поведінки проектованої системи.

• Розробити початкову концептуальну модель системи для її подальшій деталізації у формі логічних і фізичних моделей.

• Підготувати початкову документацію для взаємодії розробників системи з її замовниками і користувачами.

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

Суть даної діаграми полягає в наступному: проектована система представляється у вигляді множини сутностей або акторів, що взаємодіють з системою за допомогою так званих варіантів використання. При цьому актором (actor) або дійовою особою називається будь-яка суть, що взаємодіє з системою ззовні. Це може бути людина, технічний пристрій, програма або будь-яка інша система, яка може служити джерелом дії на модельовану систему так, як визначить сам розробник. У свою чергу, варіант використання (use case) служить для опису сервісів, які система надає акторові. Іншими словами, кожен варіант використання визначає деякий набір дій, що здійснюється системою при діалозі з актором. При цьому нічого не мовиться про те, яким чином буде реалізовано взаємодію акторів з системою.

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

Відношення на діаграмі варіантів використання

У мові UML є декілька стандартних видів відношення між акторами і варіантами використання:

• Відношення асоціації (association relationship) це відношення встановлює, яку конкретну роль грає актор при взаємодії з екземпляром варіанту використання. На діаграмі варіантів використання, так само як і на інших діаграмах, відношення асоціації позначається суцільною лінією між актором і варіантом використання. Ця лінія може мати додаткові умовні позначення, такі, наприклад, як ім'я і кратність.

• Відношення розширення (extend relationship) визначає взаємозв'язок екземплярів окремого варіанту використання з більш загальним варіантом, властивості якого визначаються на основі способу сумісного об'єднання даних екземплярів.Відношення розширення між варіантами використання позначається пунктирною лінією із стрілкою (варіант відношення залежності), направленою від того варіанту використання, який є розширенням для початкового варіанту використання. Дана лінія із стрілкою позначається ключовим словом "extend" ("розширює").

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

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

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

21. Призначення та правила побудови діаграми класів UML. Як позначаються класи, поля(атрибути) та методи(операції) класів? Як на діаграмі класів позначаються зв’язки між класами(типи зв’язків з прикладами, кратність зв’язку). У яких випадках на діаграмі класів позначаються атрибути зв’язку?

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

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

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

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

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

О бов'язковим елементів позначення класу є його ім'я.

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

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

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

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

<квантор видимості><ім'я атрибута>[кратність]:

<тип атрибута> = <вихідне значення>{рядок-властивість}

Квантор видимості може приймати одне із трьох можливих значень й, відповідно, відображається за допомогою спеціальних символів:

• Символ "+" позначає атрибут з областю видимості типу загальнодоступний (public). Атрибут із цією областю видимості доступний або видний з будь-якого іншого класу пакета, у якому визначена діаграма.

• Символ "#" позначає атрибут з областю видимості типу захищений (protected). Атрибут із цією областю видимості недоступний або невидний для всіх класів, за винятком підкласів даного класу.

• І, нарешті, знак "-" позначає атрибут з областю видимості типу закритий (private). Атрибут із цією областю видимості недоступний або невидний для всіх класів без винятку.

Квантор видимості може бути опущений. У цьому випадку його відсутність просто означає, що видимість атрибута не вказується. Однак замість умовних графічних позначень можна записувати відповідне ключове слово: public, protected, private.

Ім'я атрибута використається як ідентифікатор тому повинне бути унікально в межах даного класу.

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

[нижня_границя1 .. верхня_границя1, нижня_границя2.. верхня_границя2, ..., нuжняя_гpaнuцяk .. верхня_границяk],

де нижня_границя й верхня_границя є позитивними цілими числами, кожна пара яких служить для позначення окремого замкнутого інтервалу цілих чисел, у якого нижня (верхня) границя дорівнює значенню нижня_границя (верхня_границя). У якості верхньої_границі може використатися спеціальний символ "*", що означає довільне позитивне ціле число. Інакше кажучи, це означає необмежене зверху значення кратності відповідного атрибута.

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

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

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

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

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

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

<квантор видимості><ім'я операції>(список параметрів):

<вираження типу значення, що повертає,>{рядок-властивість}

Квантор видимості, як й у випадку атрибутів класу, може приймати одне із трьох можливих значень. "+" - загальнодоступна операція (public). "#" - захищена (protected). "-" закрита (private).

Квантор видимості для операції може бути опущений. У цьому випадку його відсутність просто означає, що видимість операції не вказується. Замість умовних графічних позначень також можна записувати відповідне ключове слово: public, protected, private.

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

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

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

Для підвищення продуктивності системи одні операції можуть виконуватися паралельно або одночасно, а інші - тільки послідовно. У цьому випадку для вказівки паралельності виконання операції використається рядок-властивість виду "{concurrency = ім'я}", де ім'я може приймати одне з наступних значень: послідовна (sequential), паралельна (concurrent), охоронювана (guarded). При цьому дотримуються наступної семантики для даних значень:

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

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

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

Відсутність даної рядка-властивості означає, що семантика паралельності для операції не визначена. Поява сигнатури операції на самому верхньому рівні повідомляє цю операцію на весь клас, при цьому дана операція успадковується всіма нащадками даного класу. Якщо в деякому класі операція не виконується (тобто деякий метод не застосовується), то така операція може бути позначена як абстрактна "{abstract}". Інший спосіб показати абстрактний характер операції - записати її сигнатуру курсивом. Підлегла поява запису даної операції без властивості {абстрактна} указує на той факт, що відповідний клас-нащадок може виконувати дану операцію як свій метод.

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

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

Відносини між класами

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

• Відношення залежності (dependency relationship)

• Відношення асоціації (association relationship)

• Відношення узагальнення (generalization relationship)

• Відношення реалізації (realization relationship)

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

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

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

• "access" - служить для позначення доступності відкритих атрибутів й операцій класу-джерела для класів-клієнтів;

• "bind" - клас-клієнт може використати деякий шаблон для своєї наступної параметризації;

• "derive" - атрибути класу-клієнта можуть бути обчислені по атрибутах класу-джерела;

• "import" - відкриті атрибути й операції класу-джерела стають частиною класу-клієнта, як якби вони були оголошені безпосередньо в ньому;

• "refine" - указує, що клас-клієнт служить уточненням класу-джерела в силу причин історичного характеру, коли з'являється додаткова інформація в ході роботи над проектом.

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

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

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

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

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

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

Часткою случаємо відносини асоціації є так називана асоціація, що виключає (Xor-association). Семантика даної асоціації вказує на той факт, що з декількох потенційно можливих варіантів даної асоціації в кожен момент часу може використатися тільки один її екземпляр. На діаграмі класів асоціація, що виключає, зображується пунктирною лінією, що з'єднує дві й більше асоціації, поруч із якої записується рядок-обмеження "{хог}".

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

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

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

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

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

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

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

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

Як обмеження можуть бути використані наступні ключові слова мови UML:

• {complete} — означає, що в даному відношенні узагальнення специфіковані всі класи-нащадки, і інших класів-нащадків у даного класу-предка бути не може.

• {disjoint} - означає, що класи-нащадки не можуть містити об'єктів, що одночасно є екземплярами двох або більше класів

• {incomplete} - означає випадок, протилежний першому. А саме, передбачається, що на діаграмі зазначені не всі класи-нащадки.

• {overlapping} - означає, що окремі екземпляри класів-нащадків можуть належати одночасно декільком класам.

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

Об'єкт (object) є окремим екземпляром класу, що створюється на етапі виконання програми. Він має своє власне ім'я й конкретні значення атрибутів. У силу всіляких причин може виникнути необхідність показати взаємозв'язки не тільки між класами моделі, але й між окремими об'єктами, що реалізують ці класи. Для графічного зображення об'єктів використається такий же символ прямокутника, що й для класів. Відмінності проявляються при вказівці імен об'єктів, які у випадку об'єктів обов'язково підкреслюються, запис імені об'єкта являє собою рядок тексту "ім'я об'єкта : ім'я класу".

  Шаблон (template) або параметризований клас (parametrized class) призначений для позначення такого класу, що має один (або більше) нефіксований формальний параметр. Він визначає ціле сімейство або безліч класів, кожний з яких може бути отриманий зв'язуванням цих параметрів з дійсними значеннями. Звичайно параметрами шаблонів служать типи атрибутів класів, такі як цілі числа, перерахування, масив рядків й ін. У більше складному випадку формальні параметри можуть представляти й операції класу.

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

Шаблон не може бути безпосередньо використаний як клас, оскільки містить невизначені параметри. Найчастіше як шаблон виступає деякий суперклас, параметри якого уточнюються в його класах-нащадках. Очевидно, у цьому випадку між ними існує відношення залежності із ключовим словом "bind", коли клас-клієнт може використати деякий шаблон для своєї наступної параметризації. У більше окремому випадку між шаблоном і формованим від нього класом має місце відношення узагальнення зі спадкуванням властивостей шаблона. У даному прикладі відзначений той факт, що клас "Адреса" може бути отриманий із шаблона Зв'язний_список на основі актуалізації формальних параметрів "S, k, l" фактичними атрибутами "вулиця, будинок, квартира".

Цей же шаблон може використатися для завдання іншого класу, скажемо, класу "Крапки_на_площині". У цьому випадку клас "Крапки_на_площині" актуалізує ті ж формальні параметри, але з іншими значеннями, наприклад, "Ьтсг<координати_крапки, х, в>. Концепція шаблонів є досить потужним засобом в ООП, і тому її використання в мові UML дозволяє не тільки скоротити розміри діаграм, але й найбільше коректно управляти спадкуванням властивостей і поводження окремих елементів моделі.

22. Різновид діаграм взаємодії. Що спільного і в чому різниця в UML діаграмах послідовності та кооперації? Як на цих діаграмах позначаються об’єкти та класи; передача повідомлень між класами, розгалужені та циклічні повідомлення?

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

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

По-перше, на них показана лінія життя об'єкта. Це вертикальна пунктирна лінія, що відбиває існування об'єкта в часі.Більша частина об'єктів, представлених на діаграмі взаємодій, існує на протязі всього взаємодії, тому їх зображують у верхній частині діаграми, а їх лінії життя промальована зверху донизу. Об'єкти можуть створюватися і під час взаємодій.Лінії життя таких об'єктів починаються з отримання повідомлення зі стереотипів create. Об'єкти можуть також знищуватися під час взаємодій;в такому разі їх лінії життя закінчуються одержанням повідомлення зі стереотипів destroy, а в якості візуального образу використовується більша буква X, що позначає кінець життя об'єкта.

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

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

Позначення на діаграмі кооперацій

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

<Ім'я объекта>'/' <Ім'я ролі класифікатора> ':' <Ім'я класифікатора>

[':' <Ім'я класифікатора >]*

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

Перше - це шлях.Для опису зв'язку одного об'єкта з іншим до далекої кінцевий точці цьому зв'язку можна приєднати стереотип шляху (наприклад, local, який показує, що позначений об'єкт є локальним по відношенню до відправнику повідомлення).Має сенс явним чином зображувати шлях зв'язку тільки щодо шляхів типу local, parameter, global і self (але не associations).

Друге властивість - це порядковий номер повідомлення.Для позначення тимчасової послідовності перед повідомленням можна поставити номер (нумерація починається з одиниці), який повинен поступово зростати для кожного нового повідомлення (2, 3и. Т.д.). Для позначення вкладеності використовується десяткова нотацію Дьюі (1 - перше повідомлення; 1.1 - перше повідомлення, вкладені в повідомлення 1; 1.2 - друге повідомлення, вкладені в повідомлення 1і т.д.). Рівень вкладеності не обмежений. Для кожної зв'язку можна показати кілька повідомлень (ймовірно, надісланих різними відправниками), і кожна з них повинна мати унікальний порядковий номер.

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

Мультиобъект (multiobject) є ціла безліч об'єктів на одному з кінців асоціації. На діаграмі кооперації Мультиобъект використовується для того, щоб показати операції і сигнали, які адресовані всій безлічі об'єктів, а не тільки одному.

Складений об'єкт (composite object) або об'єкт-контейнер призначений для представлення об'єкту, що має власну структуру і внутрішні потоки (нитки) управління. Складений об'єкт є екземпляром складеного класу (класу-контейнера), який зв'язаний відношенням агрегації або композиції з своїми частинами.

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

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

1.Суцільна лінія з трикутною стрілкою (а) позначає виклик процедури або іншого вкладеного потоку управління.2.Суцільна лінія з V-образною стрілкою (б) позначає простій потік управління.3.Суцільна лінія з напівстрілкою (в) використовується для позначення асинхронного потоку управління.4.Пунктирна лінія з V-образною стрілкою (мал. 9.10, г)

Позначення на діаграмі послідовності

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

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

Щоб явно виділити подібну активність об'єктів застосовується спеціальне поняття, що отримало назву фокусу управління (focus of control). Фокус управління зображається у формі витягнутого вузького прямокутника, верхня сторона якого позначає початок отримання фокусу управління об'єкту (початок активності), а її нижня сторона — закінчення фокусу управління (закінчення активності). Цей прямокутник розташовується нижче за позначення відповідного об'єкту і може замінювати його лінію життя, якщо на всьому її протязі він є активним.

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

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

23. Різновид діаграм поведінки. Що спільного і в чому різниця в UML діаграмах станів та діяльності? Як на цих діаграмах позначаються простий та складений стани об’єктів; прості переходи між станами та паралельні переходи?

o Діаграмма станів (statechart diagram)

o Діаграма діяльності (activity diagram)

o Діаграми взаємодії (interaction diagrams)

 Діаграма послідовності (sequence diagram)

 Діаграма кооперації (collaboration diagram

Діаграма станів (statechart diagram)

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

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

Автомат (state machine) в мові UML являє собою деякий формалізм для моделювання поведінки елементів моделі і системи в цілому.Кожна діаграма станів представляє деякий автомат.

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

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

Формалізм звичайного автомата базується на виконанні наступних обов'язкових умов:

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

2.В кожний момент часу автомат може перебувати в одному і тільки в одному зі своїх станів.

4. Кількість станів автомата повинно бути обов'язково кінцевим (в мові UML розглядаються тільки кінцеві автомати), і всі вони повинні бути специфицированы явним чином.

5.Граф автомата не повинен містити ізольованих станів і переходів. Кожен перехід повинен обов'язково поєднувати два стану автомата. Допускається перехід зі стану в себе, такий перехід ще називають "петлею".

6. Автомат не повинен містити конфліктуючих переходів, тобто роздвоєння.

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

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

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

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

На діаграмі станів перехід зображається суцільною лінією зі стрілкою, яка направлена в целевое стан.

Термін подія (event) вимагає окремого пояснення, оскільки є самостійним елементом мови UML.Формально, подія являє собою специфікацію деякого факту, що має місце в просторі і в часі. Про події кажуть, що вони "відбуваються", при цьому окремі події повинні бути впорядковані в часі.Після настання деякого події не можна вже повернутися до попередніх подій, якщо така можливість не передбачена явно в моделі. Ім'я події ідентифікує кожен окремий перехід на діаграмі станів і може містити рядок тексту, що починається з рядкової букви.У цьому випадку прийнято вважати перехід тріггерним. Якщо поруч зі стрілкою переходу не вказана жодна рядок тексту, то відповідний перехід є нетріггерним.

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

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

Складовою стан може містити два чи більше паралельних подавтомата або кілька послідовних подсостояній.

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

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

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

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

Історичне стан (history state) застосовується у контексті складеного стану. Воно використовується для запам'ятовування того з послідовних подсостояній, яке було поточним в момент виходу з складеного стану.При цьому існує два різновиди історичного стану: недавнє і давнє.

Недавнє історичне стан (shallow history state) позначається у формі невеликої кола, в яку поміщено латинська буква "Н" (а).Давнє історичне стан (deep history state) позначається у формі невеликої кола, в яку поміщено латинська буква "Н" з символом "*" (б) і служить для запам'ятовування всіх подсостояній будь-якого рівня вкладеності для поточного подавтомата.

Складні переходи

Переходи між паралельними станами

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

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

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

Переходи між складовими станами

Перехід, стрілка якого сполучена з кордоном деякого складеного стану, означає перехід до складу стан (перехід b).Він еквівалентний переходу в початковий стан кожного з подавтоматов (можливо, єдиний), що входять до складу даного суперсостоянія. Перехід, що виходить з складеного стану (переходи f і g), відноситься до кожного з вкладених подсостояній.Це означає, що об'єкт може покинути складовою суперсостояніе, перебуваючи в будь-якому з його подсостояній.

Синхронізує стан (synch state) позначається невеликий окружністю, всередині якої розміщено символ зірочки "*".Воно використовується спільно з переходом-з'єднанням або переходом-розгалуження для того, щоб явно вказати події в інших подавтоматах, що роблять безпосередній вплив на поведінку даного подавтомата.

Діаграма діяльності (activity diagram)

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

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

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

Графічно стан дії зображується фігурою, яка нагадує прямокутник, бічні сторони якого замінені випуклими дугами. Всередині цієї фігури записується вираз дії (action-expression), яка має бути унікальним в межах однієї діаграми діяльності.

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

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

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

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

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

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

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

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

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

Синхронізація та запараллеліваніе процесів.

Якщо діаграма діяльності показує потік керування від діяльності до діяльності, то на діаграмі станів представлений потік управління від стану до стану.