Семантика і нотація діаграми класів. Нарисуйте елементи нотації і наведіть їх інтерпретацію.
Графічно клас зображають прямокутником, який поділяють горизонтальними лінями на три секції, у яких вказують ім'я класу (одне, максимум два слова), його атрибути і операції.
У розділі імені у подвійних кутових лапках може бути додатково вказаний стереотип класу – група, до яких належить клас.
Класи відповідно до своєї ролі у системі діляться на групи. В UML жорстко не обумовлює ці групи, залишаючи таке групування на розсуд розробників. Хоча, як правило, на етапі побудови діаграм аналізу виділяють наступні групи (категорії, стереотипи) класів:
граничні (boundary) – об’єкти цих класів реалізують інтерфейси системи із зовнішнім середовищем і різними користувачами (їх не треба змішувати з внутрішніми інтерфейсами взаємодії класів, які розглянуті вище);
сутнісні (entity) – об’єкти цих класів представляють собою блоки довготривало збережуваної інформації, які використовують для організації баз даних і знань, файлових систем збереження даних різної логічної структури. В основному у цих класах розвинутий атрибутивний розділ, однак, є невелике число операцій контролю обмеженої цілісності, як стандартних, так і специфічних для даної предметної області;
управління (control) – об’єкти цих класів є активними, які беруть на себе управління і організацію обчислювальних процесів, як правило, це стандартні компоненти операційних систем і систем управління базами даних, таймери, координатори і т.п.
Графічні, так звані, іконізовані представлення таких груп класів доступні для внесення їх на діаграми моделі за допомогою панелі інструментів Analysis.
Деталізацію графічного представлення класів, як правило, проводять на діаграмах проектування і реалізації.
Як було показано вище, стереотип або відношення класу до групи класів відображають у розділі позначення класу, який відповідає за його ім'я. Отже, один із граничних класів може бути звичайно зображений із стереотипом <<interface>>.
Таке представлення дає можливість показати, які саме операції надає інтерфейс. Якщо ж деталі представлення на даний момент є зайвими, то інтерфейс на діаграмах зображають у вигляді кружечка (lollipop).
Зокрема, на рисунку вище, окрім, інтерфейсу представлений іконізований стереотип підсистеми <<subsystem>>, який можна було також представити у вигляді повного опису класу ConduitSet з вказуванням відповідного стереотипу.
Назви класів, які належать до інтерфейсів, прийнято починати з букви І.
Застосовують також стереотип класів прикладної логіки (logic) – об’єкти цих класів реалізують основну логіку розв'язку завдань прикладної програми, як правило, це окремі програмні або апаратні модулі, які здійснюють складні розв'язки, розв’язують оптимізаційні завдання.
Для групування елементів і діаграм в UML використовують механізм пакетів. Пакет (package) – це контейнер з іменем, у якому можуть міститися елементи, діаграми або інші пакети, які володіють якою – небудь ступінню спорідненості, яка задається розробником системи. Пакет задає простір імен, які вирізняють сутності, що містяться у пакеті, із загальної множини. Особливими типами пакетів виступають, модель, підсистема і система.
Система (стереотип «system») – це коренева підсистема у ієрархії пакетів. Вона виступає у якості єдиної сутності, яка не може міститися у інших пакетах. У пакеті система розміщуються всі решту підсистем і моделей.
Підсистема (стереотип «subsystem») – це частина системи, яка може бути виділене розробником за тією чи іншою ознакою (як правило, функціональною або територіальною). У підсистеми є власна специфікація і програмна реалізація. Розбиття на підсистеми проводять для складних систем, реалізація яких базується на використанні великої кількості класів. Практично всі підсистеми будь – якого рівня деталізації є взаємозалежними. Кількість рівнів ієрархії в декомпозиції підсистем на підсистеми у мові UML не обмежуються.
Модель (стереотип «model») – деяке абстрактне представлення системи, яке використовує ту чи іншу точку зору розробника (визначені властивості системи). Може бути множина моделей, вони можуть бути взаємозалежними, а також вкладеними. Кожну модель представляють окремим пакетом. Всі вони містяться у пакеті система, можуть також бути у пакетах підсистема і модель більш високого рівня.
Між пакетами можуть існувати відношення залежності і узагальнення. Щоб виникло відношення залежності, достатньо, щоб хоча би один елемент всередині пакету залежав від якого небудь елемента всередині іншого пакету, наприклад, викликав його операції або використовував якимось іншим способом.
Перед іменем елементу, наприклад, класу, може ставитися ім'я пакету. Воно відділяється подвійною двокрапкою. Наприклад, displayWindow: WindowingSystem :: GraphicWindows:: Window
(вказані два пакети перед іменем класу Window). Так відображають ієрархію пакетів.
Пакет зображають у вигляді великого прямокутника до лівого кута якого прикріплений маленький прямокутник типу закладки. Якщо вміст пакету не розкривається, то всередині великого прямокутника ставлять ім'я пакету. У іншому випадку ім'я пакету розміщають на закладці. Над іменем пакету може розміщатися рядок стереотипу.
Частковим випадком діаграми класів, є діаграма об’єктів, на якій об’єкт зображають графічно, так як і клас. Об'єкт (object) – є екземпляром класу і створюється на етапі програмної реалізації. Кожен об’єкт володіє індивідуальністю, тобто, має власне ім'я, яке не співпадає з іменем класу, індивідуальні значення атрибутів. Для об’єкту вказують конкретні значення атрибутів, як його власних, так і успадкованих від всіх батьківських класів. Щоб відрізнити об’єкт від класу, ім'я об’єкту пишуть з малої букви і підкреслюють. Використовують різні варіанти позначення імен об’єктів, найповніший серед них – після імені об’єкта через двокрапку вказують ім'я класу. На UML діаграмах можна побачити позначення будь – якого об’єкта класу, який називають анонімним. У цьому випадку ім'я об’єкта складається тільки з імені класу перед яким ставиться двокрапка. Діаграму об’єктів, як правило, створюють для окремих об’єктів з складною поведінкою і взаємодією.