PrIS

401

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

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

Примітка

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

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

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

<вид параметра><ім’я параметра>:<опис типу>=<значення параметра за замовчуванням>.

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

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

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

402

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

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

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

(sequential), паралельна (concurrent), збережувана (guarded). При цьому дотримуються такої семантики для цих значень:

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

паралельна (concurrent) – ця операція через свої особливості може виконуватися паралельно з іншими операціями в системі, при цьому паралельність повинна підтримуватися на рівні реалізації моделі;

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

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

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

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

403

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

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

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

Як приклади запису операцій можна навести такі позначення окремих операцій:

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

+намалювати(форма: Багатокутник = прямокутник, колір_заливки: Color = (Про, Про, 255)) – може позначати операцію зображення на екрані монітора з прямокутною областю синього кольору, якщо не вказуються інші значення як арґументи цієї операції;

запит_рахунку_клієнта(номер_рахунку: Сurrеnсу):Сurrеnсу – позначає операцію встановлення наявності коштів на поточному рахунку клієнта банку; при цьому арґументом такої операції є номер рахунку клієнта, який записується у вигляді цілого числа (наприклад, "123456"); результатом виконання цієї операції є деяке число, записане в прийнятому грошовому форматі (наприклад, $1,500.00);

видати_повідомлення():{"Помилка ділення на нуль"} – сенс такої операції не вимагає пояснення, оскільки міститься в рядку-властивості

404

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

19.2. Відношення між класами

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

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

відношення асоціації (association relationship);

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

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

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

19.2.1. Відношення залежності

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

Відношення залежності графічно зображається пунктирною лінією між відповідними елементами зі стрілкою на одному з її кінців (" " або " "). На діаграмі класів таке відношення зв'язує окремі класи між собою, при цьому стрілка напрямлена від класу-клієнта залежності до незалежного класу або класу-джерела (рис. 19.3). На цьому рисунку зображено два класи: Клас_А і Клас_Б, при цьому Клас_Б є джерелом деякої залежності, а Клас_А – клієнтом цієї залежності.

Клас_А Клас_Б

405

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

Як клас-клієнт і клас-джерело залежності може виступати ціла множина елементів моделі. У цьому випадку одна лінія зі стрілкою, що виходить від джерела залежності, розщеплюється в деякій крапці на декілька окремих ліній, кожна з яких має окрему стрілку для класуклієнта. Наприклад, якщо функціонування Класу_С залежить від особливостей реалізації Класу_А і Класу_Б>, то така залежність може бути зображена таким чином, як на рис. 19.4.

Клас_С

Клас_А Клас_Б

Рис. 19.4. Графічне зображення залежності між класом-клієнтом (Клас_С) і класами-джерелами (Клас_А і Клас_Б).

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

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

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

"derive" – атрибути класу-клієнта можуть бути обчислені згідно з атрибутами класу-джерела;

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

406

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

Примітка

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

19.2.2. Відношення асоціації

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

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

Як простий приклад відношення бінарної асоціації розглянемо відношення між двома класами – класом "Компанія" і класом "Співробітник" (рис. 19.5). Вони зв'язані між собою бінарною асоціацією Робота, ім'я якої вказане на рисунку поряд з лінією асоціації. Для цього відношення визначений порядок проходження класів, першим з яких є клас "Співробітник", а другим – клас "Компанія". Окремим прикладом або екземпляром такого відношення може бути пара значень (Петренко І.І., "Роги&копита"). Це означає, що співробітник Петренко І.І. працює в компанії "Роги&копита".

407

Символ порядку класів

Кратність асоціації

Рис. 19.5. Графічне зображення відношення бінарної асоціації між класами.

Тернарна асоціація і асоціації вищої арності в загальному випадку називаються N-кратною асоціацією (читається – "ен кратна асоціація"). Така асоціація зв'язує деяким відношенням 3 і більше класи, при цьому один клас може брати участь в асоціації більше, ніж один раз. Клас асоціації має певну роль у відповідному відношенні, що може бути явно вказане на діаграмі. Кожний екземпляр N-кратної асоціації є N-кратним кортежем значень об'єктів з відповідних класів. Бінарна асоціація є окремим випадком N-кратної асоціації, коли значення N=2, і має своє власне позначення.

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

Порядок класів в N-арній асоціації, на відміну від порядку множин у відношенні, на діаграмі не фіксується. Деякий клас може бути приєднаний до ромба пунктирною лінією. Це означає, що такий клас забезпечує підтримку властивостей відповідної N-арної асоціації, а сама N-арна асоціація має атрибути, операції і/або асоціації. Іншими словами, така асоціація, своєю чергою, є класом з відповідним позначенням у вигляді прямокутника і є самостійним елементом мови UML – асоціацією-класом (Association Class). N-арна асоціація не може містити символа аґреґації для жодної зі своїх ролей.

Як приклад конкретної тернарної асоціації розглянемо відношення між трьома класами: "Футбольна команда", "Рік" і "Гра". Така асоціація вказує на наявність відношення між цими трьома класами, яка може задавати інформацію про ігри футбольних команд у національному чемпіонаті протягом декількох останніх років (рис. 19.6).

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

408

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

Рис. 19.6. Графічне зображення тернарної асоціації між трьома класами.

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

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

Так, для розглянутого раніше прикладу (див. рис. 19.5) кратність "1" для класу "Компанія" означає, що кожний співробітник може працювати тільки в одній компанії. Кратність "1..*" для класу "Співробітник" означає, що в кожній компанії можуть працювати декілька співробітників, загальна кількість яких заздалегідь невідома і нічим не обмежена. Зазначимо, що замість кратності "1..*" записати тільки символ "*" не можна, оскільки останній означає кратність "0..*". Для нашого прикладу це означало б, що окремі компанії можуть зовсім не мати співробітників у своєму штаті. Але така кратність цілком прийнятна в інших ситуаціях, як це видно з розглянутого вище прикладу (рис. 19.6).

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

409

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

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

"{Xor}".

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

Рис. 19.7. Графічне зображення виключної асоціації між трьома класами.

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

19.2.3. Відношення аґреґації

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

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

410

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

Примітка

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

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

Як приклад відношення аґреґації розглянемо взаємозв'язок типу «частина-ціле», який має місце між сутністю "Вантажний автомобіль" і такими компонентами, як "Двигун", "Шасі", "Кабіна", "Кузов". Не претендуючи на точну відповідність термінології такої предметної області, неважко уявити собі, що вантажний автомобіль складається з двигуна, шасі, кабіни і кузова. Саме це відношення між класом "Вантажний_автомобіль" і класами "Двигун", "Шасі", "Кабіна", "Кузов" описує відношення аґреґації.

Графічно відношення аґреґації зображається суцільною лінією, один з кінців якої є не зафарбованим всередині ромбом. Цей ромб вказує на той із класів, який є "цілим". Решта класів є його "частинами" (рис. 19.8).

Рис. 19.8. Графічне зображення відношення аґреґації в мові UML.

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