7. Об'єктно-орієнтоване проектування.

UML
7.1. Уніфікована мова моделювання - UML.
Кому і навіщо потрібен UML
В даний час уніфікована мова моделювання - UML є наймоднішою технологією в
області програмної інженерії. Справа в тому, що UML дозволяє системним
архітекторам представляти своє бачення системи у вигляді набору стандартних
діаграм, які, до того ж, служать відмінним засобом комунікації в команді
розробників і прекрасним помічником в спілкуванні з замовником. І при всьому
цьому, UML - досить логічна і проста для вивчення нотація, навичками
використання якої повинен опанувати будь-який фахівець, що збирається
працювати в області програмної інженерії. Знання UML потрібно розробникам,
системним архітекторам, менеджерам ...
Що таке UML
UML - уніфікована мова моделювання. З цих трьох слів головним є слово "мова".
Що ж таке мова?
Мова - система знаків, що служить засобом людського спілкування і розумової
діяльності; засобом збереження і передачі інформації. Мова включає в себе набір
знаків (словник) і правила їх вживання та інтерпретації (граматику).
UML - мова формальна і штучна. Штучна - у неї є автори. Формальна - є правила її
вживання. Ще UML - мова графічна.
При описі формальної штучної мови, що ми вже бачили на прикладах опису мов
програмування, описуються такі його елементи:
1. синтаксис - визначення правил побудови конструкцій мови;
2. семантика - визначення правил, відповідно до яких конструкції мови набувають
смислове значення;
3. прагматика - визначення правил використання конструкцій мови для досягнення
потрібних цілей.
UML включає всі ці елементи, хоча в їх описі спостерігаються відмінності від
правил, прийнятих в мовах програмування.
Друге слово в абревіатурі UML - моделювання. UML - це мова об'єктно-
орієнтованого моделювання. В англійській мові є два слова - modeling і simulation,
які обидва переводяться як "моделювання", хоча означають різні поняття.
Modeling має на увазі створення моделі, яка лише описує об'єкт, а simulation має
на увазі одержання за допомогою створеної моделі деякої додаткової інформації
про об'єкт. UML в першу чергу - мова моделювання саме в першому сенсі, тобто
засіб побудови описових моделей. Як засіб симулювання її теж можна
використовувати, хоча для цієї ролі вона підходить не так добре.
Третє слово в назві UML - слово уніфікована. Його можна розуміти теж
неоднозначно. У літературі можна зустріти опис ери "до UML" як "війни методів"
моделювання, жоден з яких «не дотягував" до рівня індустріального стандарту.
UML стала таким єдиним універсальним стандартом для об'єктно-орієнтованого
моделювання. "Єдиною" мовою моделювання UML можна назвати ще й тому, що в
її створенні об'єдналися зусилля авторів трьох найбільш популярних методів
моделювання (і не тільки їх).
У 80-ті роки було безліч різних методологій моделювання. Кожна з них мала свої
переваги і недоліки, а також свою нотацію. Проблема в тому, що різні люди
використовували різні нотації, і для того щоб зрозуміти, що описує та чи інша
діаграма, часто був потрібний "перекладач". Один і той же символ міг означати в
різних нотаціях абсолютно різні речі! До 1994-му існувало 72 методи, або приватні
методики. Існувала гостра потреба, "соціальне замовлення" - закінчити "війну
методів" і об'єднати в одному уніфікованому засобі все краще, що було створено в
області моделювання.
Способи використання мови
Автори визначають UML як графічну мову моделювання загального призначення
(тобто її можна застосовувати для проектування чого завгодно), призначену для
специфікації, візуалізації, проектування та документування всіх артефактів, що
створюються в ході розробки (артефакт - будь-який штучно створений об'єкт,
продукт людської діяльності).
Отже, UML в першу чергу - це специфікації.
Специфікація - докладний опис системи, який повністю визначає її мету та
функціональні можливості. Розрізняють: словесні специфікації на природній мові;
модельні специфікації; формальні специфікації.
Замовник і розробник (ще аналітики, менеджери, бізнес-консультанти...) мають,
абсолютно різне розуміння сенсу цього артефакту. Кожен з них називає
специфікації по-своєму: постановка задачі, вимоги користувача, технічне
завдання, функціональна специфікація, архітектура системи ...
Всі ці люди, будучи фахівцями в абсолютно різних предметних областях,
розмовляють кожен на своїй мові і часто просто не розуміють один одного. Ось
тому-то і виникає проблема, яку може вирішити тільки наявність єдиного,
уніфікованого засобу створення специфікацій, досить простого і зрозумілого для
всіх зацікавлених осіб.
Словесні специфікації на природній мові викликають масу проблем, оскільки
створюються різними фахівцями на "їхньою мовою".
Формальна специфікація є, по суті, математичною моделлю задачі і тому для
обчислювальних задач все виглядає досить просто. Формалізація ж завдань з
інших областей знань може виявитися більш складною і трудомісткою проблемою,
ніж розробка самого додатка через відсутність чіткої математичної моделі.
UML - це засіб візуалізації, створення модельних специфікацій.
UML дозволяє створювати такі прості і зрозумілі картинки (моделі), що описують
систему з різних сторін, які можна показати замовнику і обговорити з ним, тобто
служить засобом комунікації в команді.
Проектування. UML дозволяє будувати моделі програмних систем (взагалі кажучи
- БУДЬ-ЯКИХ систем). За цим моделям потім може проводитися генерація
каркасного коду проектованих додатків.Также можливий процес, який часто
називають "реверс-інжинірингом", - тобто створення UML-моделі з існуючого коду
програми. Якість вихідного коду або моделей при реверс-інжинірингу поки що
далека від ідеалу, але технології та інструменти постійно вдосконалюються, так
що можна сподіватися, що коли-небудь ми зможемо створювати додатки
візуально, не вдаючись до мови програмування, а користуючись лише UML ...
Документування. UML-моделі самі по собі вже є документами, зрозумілими,
навіть для неспеціаліста, як видно з попереднього малюнка. Крім цього, моделі
UML є XML-документами. Причому будь-який елемент на будь-який діаграмі може
бути забезпечений ноутсом - текстовим коментарем. Тобто побудова набору
діаграм вже є процесом документування майбутньої системи. Більш того,
більшість інструментів UML-проектування вміють витягати текстову інформацію з
моделей і генерувати відносно легкий для читання тексти.
Тобто,
 UML може служити засобом обміну інформацією всередині команди і в ході
взаємодії з замовником.
 UML є відмінним засобом специфікації систем, причому специфікації в
процесі розробки.
 Розроблені архітектурні рішення, задокументовані за допомогою UML,
можуть бути використані повторно.
 Можлива генерація коду, симуляція і верифікація моделей.
Ми будуємо моделі складних систем, тому що не можемо описати їх повністю,
"окинути одним поглядом". Метод об'єктно-орієнтованого аналізу дозволяє
описувати реальні складні системи найбільш адекватним чином. Але зі
збільшенням складності систем виникає потреба в хорошій технології
моделювання. В якості такої "стандартної" технології використовується
уніфікована мова моделювання (Unified Modeling Language, UML), яка є графічною
мовою для специфікації, візуалізації, проектування та документування систем. За
допомогою UML можна розробити детальну модель створюваної системи, яка
буде показувати не тільки її концепцію, а й конкретні особливості реалізації.
Чим UML не є.
UML не є мовою програмування, хоча існують засоби виконання UML-моделей як
інтерпретованого коду (Unimod, FLORA і ін.) та можлива кодогенерація. Проте
UML це засіб моделювання а не програмування, тобто створіння не програм, а
моделей будь-якого рівня абстракції для систем з будь-якої предметної області.
UML не є специфікацією якого б то не було інструменту моделювання, хоча такі
інструменти є. Наприклад, TAU G2, Borland Together, Poseidon, Enterprise Architect,
IBM Rational Rose, Dia, Visio і ін.
UML не є моделлю будь-якого процесу розробки, навіть Rational Unified Process
(RUP), який був описаний саме за допомогою UML. UML можна використовувати
незалежно від того, яку методологію розробки ПО ви використовуєте, і навіть якщо
ви взагалі не користуєтеся ніякою методологією!
Нотації і метамоделі
Мова UML в своєму нинішньому стані визначає нотацію та метамодель.
Нотація є сукупність графічних елементів, які застосовуються в моделях; вона і є
синтаксис цієї мови моделювання. Наприклад, нотація діаграми класів визначає
спосіб представлення таких елементів і понять, як клас, асоціація і кратність.
Більшість графічних мов моделювання є аж ніяк не строгими; їх нотація більшою
мірою апелює до інтуїції, ніж до формального визначення.
Однак методологи шукають способи домогтися більшої строгості методів, не
жертвуючи при цьому їх практичною корисністю. Один із способів полягає у
визначенні деякої метамоделі - діаграми (як правило, діаграми класів), яка
визначає поняття мови.
Для кого важлива метамодель. Творця ескізів зазвичай це не дуже хвилює;
проектувальника це повинно турбувати значно більше. І це життєво важливо для
тих, хто використовує UML в якості мови програмування, оскільки метамодель
визначає абстрактний синтаксис цієї мови.
Саме слово нотація підкреслює, що UML - мова графічна і моделі (а точніше
діаграми) не «записують», а малюють. Одне із завдань UML - служити засобом
комунікації всередині команди і при спілкуванні з замовником. "У робочому
порядку" діаграми часто малюють на папері від руки, причому зазвичай - не дуже
акуратно. Тому при виборі елементів нотації основним принципом був відбір
значків, які добре виглядали б і були б правильно інтерпретовані в будь-якому
випадку - якби вони були намальовані олівцем на серветці або створені на
комп'ютері і роздруковані на лазерному принтері.
В UML використовується чотири види елементів нотації:
1.фігури,
2.лініі,
3.значки,
4.надписи.
Фігури використовуються "плоскі" - прямокутники, еліпси, ромби і т. д.
Але є один виняток - на діаграмі розгортання для позначення вузлів
інфраструктури застосовується "тривимірне" зображення паралелепіпеда.
Усередині будь-якої фігури можуть поміщатися інші елементи нотації.
Лінії своїми кінцями вони повинні з'єднуватися з фігурами. На UML діаграмах не
буває ліній, які не з'єднують фігури. Застосовується два типи ліній - суцільна і
пунктирна. Лінії можуть перетинатися, хоча таких випадків слід по можливості
уникати.
UML надає виняткову свободу - можна малювати що завгодно і як заманеться, аби
можна було зрозуміти сенс створених діаграм.
7.2. Моделі і діаграми UML
Розробка моделі будь-якої системи завжди передує її створенню або оновленню.
Це необхідно для того, щоб чіткіше уявити собі завдання. Моделі дуже важливі і
для взаємодії всередині команди розробників, і для взаєморозуміння із
замовником. Модель дозволяє переконатися в "архітектурній узгодженості"
проекту до того, як він буде реалізований в коді.
В рамках UML-моделі все уявлення про систему фіксуються у вигляді спеціальних
графічних конструкцій - діаграм.
В процесі проектування система розглядається з різних точок зору за допомогою
моделей, які постають у формі діаграм.
Модель - це деякий об'єкт, що відображає лише найбільш значущі для даної
задачі характеристики системи. Моделі бувають різні - матеріальні та
нематеріальні, штучні і природні, декоративні та математичні ...
Діаграма - це графічне представлення множини елементів. Зазвичай
зображується у вигляді графа з вершинами (сутностями) і ребрами (відносинами).
Приклади діаграм. Це і знайома всім блок-схема, і схеми монтажу різного
устаткування, і дерево файлів і каталогів на диску, і багато-багато іншого. Діаграми
оточують нас з усіх боків, адже малюнок сприймається нами легше, ніж текст ...
При проектуванні програмного забезпечення за допомогою діаграм можна
візуалізувати систему з різних точок зору. Одна з діаграм, наприклад, може
описувати взаємодію користувача з системою, інша - зміна станів системи в
процесі її роботи, третя - взаємодія між собою елементів системи і т. д. Складну
систему можна і потрібно представити у вигляді набору невеликих і майже
незалежних моделей-діаграм, кожна з яких фокусується на певному аспекті
функціонування системи і виражає різний рівень абстракції. Кожна модель
відповідає деякій точці зору на проектовану систему.
Жодна окрема діаграма не є моделлю. Діаграми - лише засіб візуалізації моделі, і
ці два поняття слід розрізняти. Лише набір діаграм становить модель системи і
найбільш повно її описує, але не одна діаграма, вирвана з контексту.
Види діаграм
В UML діаграми розділені на три групи:
• діаграми, що представляють статичну структуру програми;
• діаграми, що представляють поведінкові аспекти системи;
• діаграми, що представляють фізичні аспекти функціонування системи (діаграми
реалізації).
Кількість та види діаграм змінюються з версіями. Отже, ми коротко розглянемо такі
види діаграм, як:
• діаграма прецедентів;
• діаграма класів;
• діаграма об'єктів;
• діаграма послідовностей;
• діаграма взаємодії;
• діаграма станів;
• діаграма активності;
• діаграма розгортання

Діаграма прецедентів (use case diagram)

Будь-які системи проектуються з урахуванням того, що в процесі своєї роботи
вони будуть використовуватися людьми і/або взаємодіяти з іншими системами.
Сутності, з якими взаємодіє система в процесі своєї роботи, називаються
екторами.
Ектор (actor) - це множина логічно
пов'язаних ролей, що виконються при
взаємодії з прецедентами або
сутностями (система, підсистема або
клас). Ектором може бути людина або
інша система, підсистема або клас, які
представляють щось зовнішнє для
системи.
Графічно Ектор зображується або "чоловічком", або символом класу з відповідним
стереотипом, як показано на малюнку. Обидві форми подання мають один і той же
зміст і можуть використовуватися в діаграмах.
Прецедент (use-case) - опис окремого аспекту поведінки системи з точки зору
користувача (Буч).
Прецедент (use-case) - опис безлічі послідовних подій (включаючи варіанти), що
виконуються системою, які призводять до результату, що спостерігається Ектором.
Прецедент являє поведінку сутності, описуючи взаємодію між Ектором і системою.
Прецедент не показує, "як" досягається певний результат, а тільки "що" саме
виконується.
Прецеденти позначаються у вигляді еліпса,
всередині якого вказано його назву. Прецеденти і
Ектори з'єднуються за допомогою ліній. Часто на
одному з кінців лінії зображують стрілку, причому
спрямована вона до того, у кого запитують сервіс, чиїми послугами користуються.
Прецеденти можуть включати інші прецеденти, розширюватися ними,
успадковуватися і т.д.

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

тієї групи діаграм, які представляють динамічні або поведінкові аспекти системи.
Це відмінний засіб для досягнення взаєморозуміння між розробниками,
експертами та кінцевими користувачами продукту. Такі діаграми дуже прості для
розуміння і можуть сприйматися і, що важливо, обговорюватися людьми, які не є
фахівцями в області розробки програмного забезпечення.
Підводячи підсумки, можна виділити такі цілі створення діаграм прецедентів:
• визначення меж і контексту предметної області на ранніх етапах проектування;
• формування загальних вимог до поведінки проектованої системи;
• розробка концептуальної моделі системи для її подальшої деталізації;
• підготовка документації для взаємодії з замовниками і користувачами системи.
Діаграма класів (class diagram)
Клас (class) - категорія речей, які мають загальні атрибути та операції.
Класи - це будівельні блоки будь-якої об'єктно-орієнтованої системи. Вони
являють собою опис сукупності об'єктів із загальними атрибутами, операціями,
відносинами і семантикою. При проектуванні об'єктно-орієнтованих систем
діаграми класів обов'язкові.
Класи використовуються в процесі аналізу предметної області для складання
словника предметної області системи, що розробляється. Це можуть бути як
абстрактні поняття предметної області, так і класи, на які спирається розробка і які
описують програмні або апаратні сутності.
Діаграма класів - це набір статичних, декларативних елементів моделі. Діаграми
класів можуть застосовуватися при прямому проектуванні, тобто в процесі
розробки нової системи, і при зворотному проектуванні - описі існуючих і
працюючих систем. Діаграма класів - кінцевий результат проектування і
відправна точка процесу розробки.
Приклад ілюструє за допомогою операції успадкування "генеалогічне древо"
побутової техніки. Сенс цієї діаграми зрозумілий навіть якщо нічого не знати про
класи і програмуванні.

Наступна діаграма описує предметну область завдання по автоматизації роботи

якогось вузу або навчального центру. Зверніть увагу на позначення кратності на

кінцях зв'язків.

Крім кратності позначені властивості (і їх типи) і операції, ця діаграма виглядає як

набір класів для реалізації, а не просто опису предметної області, як попередня.
Але, тим не менше, все одно все просто і зрозуміло.
 Діаграма об'єктів (object diagram)
Об'єкт (object) - екземпляр класу.
Більш детально, об'єкт це -
• конкретна матеріалізація абстракції;
• сутність з добре визначеними межами, в якій вміщені стан і поведінку;
• екземпляр класу (вірніше, класифікатора - Ектор, клас або інтерфейс).
Об'єкт унікально ідентифікується значеннями атрибутів, що визначають його стан
в даний момент часу.
Об'єкт - це екземпляр класу. Наприклад, об'єктом класу "Мікрохвильова піч" з
прикладу вище, може бути і найпростіший прилад фірми Х невеликої ємності і з
механічним управлінням, і наворочений агрегат з грилем, сенсорним управлінням і
системою тривимірного розподілу енергії Samsung.
Ще приклад - всі ми є об'єктами класу "людина" і відрізняємося між собою за
такими ознаками (значенням атрибутів), як ім'я, колір волосся, очей, зріст, вага, вік
і т. Д. (В залежності від того, яке завдання ми розглядаємо і які властивості

людини для нас в ній важливі).

Як позначається об'єкт в UML? Об'єкт, як і клас, позначається прямокутником, але

його ім'я підкреслюється. Під словом ім'я тут ми розуміємо назву об'єкта і
найменування його класу, розділені двокрапкою. Для вказівки значень атрибутів
об'єкта в його позначенні може бути передбачена спеціальна секція. Ще один
нюанс полягає в тому, що об'єкт може бути анонімним: це потрібно в тому випадку,
якщо в даний момент не має значення, який саме об'єкт даного класу бере участь
у взаємодії.
Для чого потрібні діаграми
об'єктів? Вони показують множину
об'єктів - екземплярів класів
(зображених на діаграмі класів) і
відносин між ними в певний
момент часу. Тобто діаграма
об'єктів - це свого роду знімок
стану системи в певний момент
часу, що складає множину об'єктів,
їх стану і відносини між ними в
даний момент.
Діаграми об'єктів представляють статичний вид системи з точки зору
проектування і процесів, будучи основою для сценаріїв, описуваних діаграмами
взаємодії. Діаграма об'єктів використовується для пояснення і деталізації діаграм
взаємодії, наприклад, діаграм послідовностей.
Деяка фірма "розкручує" новий товар або послугу. Перераховано учасники. Навіть
без вказівки повідомлень, якими обмінюються об'єкти, видно, хто з ким взаємодіє.
На цій діаграмі всі об'єкти анонімні
Діаграма послідовностей (sequence diagram)
Діаграма об'єктів показує відносини між об'єктами в певний момент часу, тобто
надає знімок стану системи, будучи статичною. Діаграма послідовностей
відображає взаємодію об'єктів в динаміці. Діаграми послідовностей - це відмінний
засіб документування поведінки системи, деталізації логіки сценаріїв.
В UML взаємодія об'єктів розуміється як обмін інформацією між ними. При цьому
інформація набуває вигляду повідомлень. Крім того, що повідомлення несе якусь
інформацію, воно певним чином також впливає на одержувача. Тобто UML
повністю відповідає основним принципам ООП, відповідно до яких інформаційну
взаємодію між об'єктами зводиться до відправки і прийому повідомлень.
Діаграма послідовностей відноситься до діаграм взаємодії UML, що описує
поведінкові аспекти системи, розглядаючи взаємодію об'єктів в часі, відображаючи
тимчасові особливості передачі і прийому повідомлень об'єктами.
Щось подібне робить і діаграма прецедентів. Діаграми послідовностей можна (і
потрібно!) використовувати для уточнення діаграм прецедентів, більш детального
опису логіки сценаріїв використання. Діаграми послідовностей зазвичай містять
об'єкти, які взаємодіють в рамках сценарію, повідомлення, якими вони
обмінюються, і які повертаються результати, пов'язані з повідомленнями (в разі,
якщо це не очевидно з контексту).
Позначення на діаграмі послідовностей. Об'єкти позначаються прямокутниками
з підкресленими іменами (щоб відрізнити їх від класів), повідомлення (виклики
методів) - лініями зі стрілками, результати, які повертаються - пунктирними лініями
зі стрілками. Прямокутники на вертикальних лініях під кожним з об'єктів показують
"час життя" (фокус) об'єктів. Втім, досить часто їх не зображують на діаграмі, все
це залежить від індивідуального стилю проектування.

Сенс діаграми: студент хоче записатися на якийсь семінар, пропонований в

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

Діаграма описує процес управління навчальними курсами (очевидно, шляхом

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

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

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

Тут - складений стан, що включає інші стани, одне з яких містить також паралельні
підстани. Це діаграма проходження академічного курсу студентом. Для того щоб
пройти курс, студент повинен виконати лабораторні роботи, захистити курсовий
проект і скласти іспит.
Діаграма активності (діяльності, activity diagram)
Моделюючи поведінку проектованої системи, часто недостатньо зобразити процес
зміни її станів, а потрібно також розкрити деталі алгоритмічної реалізації операцій,
що виконуються системою. Для цієї мети традиційно використовуються блок-схеми
або структурні схеми алгоритмів. В UML для цього існують діаграми діяльності, які
є окремим випадком діаграм станів. Діаграми діяльності зручно застосовувати для
візуалізації алгоритмів, за якими працюють операції класів.
Алгоритм - послідовність певних дій або елементарних операцій, виконання яких
призводить до отримання бажаного результату.
Позначення на діаграмі активності також нагадують позначення на блок-схемі,
хоча є і деякі суттєві відмінності. З іншого боку, нотація діаграм активності дуже
схожа на ту, яка використовується в діаграмах станів.

Діаграма розгортання (deployment diagram)

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

Діаграма розгортання показує топологію системи і розподіл компонентів системи

між її вузлів, а також сполуки - маршрути передачі інформації між апаратними
вузлами. Це єдина діаграма, на якій застосовуються "тривимірні" позначення:
вузли системи позначаються кубиками. Всі інші позначення в UML - плоскі фігури
ООП і послідовність побудови діаграм
Так само як і інші мови, UML вимагає особливого способу мислення, вміння
розглядати систему з різних сторін і точок зору. Діаграми можна і потрібно
будувати в деякій логічній послідовності.
Ми говоримо про об'єктно орієнтовані системи. Тому можна запропонувати таку
послідовність побудови діаграм:
• діаграма прецедентів,
• діаграма класів,
• діаграма об'єктів,
• діаграма послідовностей,
• діаграма кооперації (взаємодії),
• діаграма станів,
• діаграма активності (діяльності),
• діаграма розгортання.
Це не єдина можлива послідовність. Можливо зручніше почати діаграми класів,
можливо якісь з діаграм не будуть потрібні.
7.3. Діаграма класів: крупним планом
Архітектор програмного забезпечення в першу чергу звертає увагу на об'єкти
предметної області. Програміст же концентрується на поведінці цих об'єктів,
користуючись класами, до яких вони належать. Тому діаграма класів є однією з
найважливіших діаграм UML. Вона використовується для документування
програмних систем, і основним її компонентом є клас.
Клас на діаграмі зображується у
вигляді прямокутника, розділеного
горизонтальними лініями на три
частини. У першій частині вказується
назва класу. Друга частина містить
перелік атрибутів класу, які
характеризують той чи інший об'єкт
цього класу в моделі предметної області. Третя частина містить перелік
операцій, що відображають його поведінку в моделі предметної області.
Так клас виглядає «зовні» для користувача (програміста). Програміст, який
використовує в своїй програмі створені кимось компоненти, як раз і виступає в ролі
такого користувача. Йому непотрібно знати що всередині - він знає, які атрибути
треба модифікувати і які операції використовувати, щоб змусити об'єкт працювати
як йому потрібно. Приховування від користувача внутрішнього устрою об'єктів
називається інкапсуляцією. Інкапсуляція - це захист окремих елементів об'єкта, що
не зачіпають суттєвих характеристик його як цілого.
Інкапсуляція забезпечується за допомогою модифікаторів видимості. З їх
допомогою можна обмежити доступ до атрибутів і операцій об'єкта з боку інших
об'єктів. Якщо атрибут або операція описані з модифікатором private - доступ до
них можна отримати тільки з операції, визначеної в тому ж класі, public - доступ
можна отримати доступ з будь-якої частини програми, protected - доступ тільки з
операцій цього ж класу і класів спадкоємців. У мовах програмування можуть
зустрічатися модифікатори видимості, що обмежують доступ на більш високому
рівні, наприклад, до класів або їх груп, проте сенс інкапсуляції від цього не
змінюється.
В UML атрибути і операції з модифікаторами доступу позначаються спеціальними
символами зліва від їх імен:
+ public - відкритий доступ
- private - тільки з операцій того ж класу
# protected - тільки з операцій цього ж класу і класів, що створюються на його
основі
Використання об'єктів класу.
Для захисту об'єктів класу існує стандартний і безпечний, не залежний від мови
програмування, спосіб доступу до об'єкта - інтерфейс - логічна група відкритих
(public) операцій об'єкта. Один і той же об'єкт може мати кілька інтерфейсів.
Інтерфейс відображає зовнішні прояви об'єкта, показує, яким чином здійснюється
взаємодія з ним, приховуючи інші деталі, що не мають відношення до процесу
взаємодії.
Інтерфейс завжди реалізується деяким класом. Оскільки
один і той же об'єкт може мати кілька інтерфейсів, значить
клас цього об'єкта реалізує всі операції цих інтерфейсів.
Інтерфейс зображується на діаграмах декількома
способами. Перший і найпростіший - це клас зі стереотипом
<<interface>>, хороший, якщо потрібно показати, які саме операції надає
інтерфейс. Якщо ж такі подробиці в даний момент не
важливі, що надається інтерфейс зображують у вигляді
кружечка або, як кажуть, "льодяника" (lollipop).
Маленький значок на закладці папки ConduitSet - це позначення підсистеми,
можна не малювати його, а просто використовувати стереотип <<subsystem>>.
Ще один спосіб зображення інтерфейсів, але не тих, що надаються об'єктом, а
тих, що потрібні об'єкту для виконання його роботи. Позначається він дуже
простим і логічним символом. Наданий і необхідний
інтерфейси логічно поєднуються на діаграмах.
Назви інтерфейсів зазвичай починаються з літери I.
Суперклас і підкласи. Спадкування. Поліморфізм.
Узагальнення - це відношення між більш загальної сутністю, званою суперкласом,
і її конкретним втіленням, званим підклассом. Узагальнення це відношення типу "є"
- одні суті є втіленням більш загальної сутності. При цьому всі атрибути і операції
суперкласу незалежно від модифікаторів видимості входять до складу підкласу.
Узагальнення (успадкування) на діаграмах позначається не зафарбованою
трикутною стрілкою, спрямованою на суперклас.
Ефективно моделювати спадкування можна в такій послідовності (Г.Буч):
1.Знайдіть атрибути, операції і обов'язки, загальні для двох або більше класів з
даної сукупності.
2.Винесіте ці елементи в певний загальний суперклас, а якщо такого не існує, то
створіть новий клас.
3.Відзначте в моделі, що підкласи успадковуються від суперкласу.
Положення всіх трьох фігур можна
однозначно визначити за
допомогою пари чисел. Для точки -
це взагалі єдині її характеристики,
для кола і прямокутника - їх центри.
Це загальні атрибути. Виносимо їх
в суперклас "Фігура".
Всі інші класи на цій діаграмі
пов'язані з класом "Фігура" відношенням узагальнення, в них потрібно визначити
тільки "відсутні" атрибути - радіус, ширину і висоту. Атрибути, що описують
координати центру, ці класи мають спочатку як нащадки класу "Фігура" - вони їх
успадковують. З операціями класів та ж історія.
Класи-нащадки успадковують атрибути та операції суперкласу. Таким чином, вони
можуть наслідувати й їх інтерфейси - тобто об'єкти абсолютно різної природи
можуть мати один і той же інтерфейс.
Об'єкти різної природи (різних класів) можуть підтримувати один і той же
інтерфейс. Приклад - діаграма з геометричними фігурами. Всі розглянуті фігури
мають, наприклад, операцію малювання на екрані (draw()). З точки зору
користувача в кожному випадку це одна і та ж дія. Реалізовано ці операції по-
різному (процедура зображення прямокутника відрізняється від подібної
процедури для кола). Але сигнатура-то одна і та ж. Робота механізму
поліморфізму заснована на збігу сигнатури методу, оголошеного в інтерфейсі, і
сигнатури самого методу. Методи всередині класів-нащадків можуть бути (і
напевно будуть!) перевизначені, їх реалізації будуть різними, а сигнатури
залишаться незмінними. Таким чином (і в цьому могутність ООП), виконуючи одні і
ті ж операції, різні об'єкти можуть вести себе по-різному.
Поліморфізм є основою для реалізації механізму інтерфейсів в мовах
програмування.
Інкапсуляція, успадкування і поліморфізм є трьома китами, на яких тримається
ООП.
Відносини між класами
Жоден з об'єктів навколишнього нас світу не існує сам по собі. Точно так же і класи
пов'язані між собою. І щоб в повній мірі оволодіти ООП, необхідно зрозуміти суть
цих відносин і навчитися їх ідентифікувати.
Залежність. Один з типів таких відносин - це залежність. Залежність виникає
тоді, коли реалізація класу одного об'єкта залежить від специфікації операцій
класу іншого об'єкта. І якщо зміниться специфікація операцій цього класу, нам
неминуче доведеться вносити зміни і в залежний клас.
Приклад: операція "Програвання", що реалізується програмою-медіаплеєром,
залежить від операції "Декомпресія", що реалізовується кодеком. Якщо
специфікація операції
"Декомпресія" зміниться,
доведеться міняти код
медіаплеєра, інакше він не
зможе працювати з якимось
кодеком і, в кращому
випадку, завершить свою
роботу з помилкою. А ось
так залежність між класами
зображується в UML:
Залежності на діаграмах зазвичай зображують тільки в тих випадках, коли їх
відображення є важливим для розуміння моделі. Часто залежності логічно
випливають з природи класів.
Асоціація. Інший вид відносин
між об'єктами - асоціація. Це
просто зв'язок між об'єктами, по
якому можна між ними
переміщатися. Асоціація може
мати ім'я, що відбиває природу відносин між об'єктами, може вказуватися напрям
читання зв'язку за допомогою трикутного маркера. Односпрямована асоціація
зображується стрілкою.
Крім напрямку асоціації, ми
можемо вказати на діаграмі ролі,
які кожен клас відіграє в даному
відношенні, і кратність, тобто
кількість об'єктів, пов'язаних
ставленням.
Кратності на діаграмі вище - людина може взагалі не працювати, працювати в
одній або більше компаніях, а ось компанії в будь-якому випадку потрібен хоча б
один співробітник.
Асоціація може об'єднувати три і більше класу. В цьому випадку вона називається
n-арною і зображується ромбом на перетині ліні

Агрегацію і композиція. Асоціація - це "просто зв'язок" між об'єктами. Але часто

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

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