Діаграми uml дозволяють описувати у процесі моделювання. Загальна характеристика мови UML

Анотація: Предметом цього курсу є The UML – уніфікована мова моделювання. У попередній лекції було розказано про те, що ж таке UML, про його історію, призначення, способи використання мови, структуру її визначення, термінологію та нотацію. Було зазначено, що модель UML – це набір діаграм. У цій лекції ми розглянемо такі питання: чому потрібні кілька видів діаграм; види діаграм; ООП та послідовність побудови діаграм

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

Ми будуємо моделі складних систем, тому що не можемо описати їх повністю, окинути одним поглядом. Тому ми виділяємо лише суттєві для конкретного завдання властивості системи та будуємо її модель, що відображає ці властивості. Метод об'єктно-орієнтованого аналізу дозволяє описувати реальні складні системи найбільш адекватним чином. Але зі збільшенням складності систем виникає потреба у хорошій технології моделювання. Як ми вже говорили в попередній лекції, як така "стандартна" технологія використовується уніфікований мова моделювання( Unified Modeling Language , UML ), який є графічною мовою для специфікації, візуалізації, проектування та документування систем. За допомогою UML можна розробити докладну модель системи, що створюється, що відображає не тільки її концепцію, але і конкретні особливості реалізації. В рамках UML-моделі уявлення про систему фіксуються у вигляді спеціальних графічних конструкцій, що отримали назву діаграм.

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

Чому потрібно кілька видів діаграм

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

Система- Сукупність взаємопов'язаних керованих підсистем, об'єднаних спільною метою функціонування.

Так, не надто інформативно. А що ж тоді підсистема? Щоб прояснити ситуацію, звернемося до класиків:

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

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

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

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

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

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

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

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

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

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

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

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

Види діаграм

UML 1.5 визначав дванадцять типів діаграм, Поділених на три групи:

• чотири типи діаграм представляють статичну структуру додатку;
• п'ять представляють поведінкові аспекти системи;
• три становлять фізичні аспекти функціонування системи (діаграми реалізації).

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

Втім, точне число канонічних діаграмнам абсолютно неважливо, оскільки ми розглянемо в повному обсязі їх, лише деякі - з тієї причини, що кількість типів діаграм для конкретної моделі конкретного докладання перестав бути суворо фіксованим. Для простих програм немає необхідності будувати все без винятку діаграми. Наприклад, для локальної програми не обов'язково будувати діаграму розгортання. Важливо розуміти, що перелік діаграм залежить від специфіки проекту, що розробляється, і визначається самим розробником. Якщо ж цікавий читач все-таки забажає дізнатися про всі діаграми UML, ми відішлемо його до стандарту UML (http://www.omg.org/technology/documents/modeling_spec_catalog.htm#UML). Мета цього курсу - не описати абсолютно всі можливості UML, а лише познайомити з цією мовою, дати первісне уявлення про цю технологію.

Отже, ми коротко розглянемо такі види діаграм, як:

• діаграма прецедентів;
• діаграма класів;
• діаграма об'єктів;
• діаграма послідовностей;
• діаграма взаємодії;
• діаграма станів;
• діаграма активності;
• діаграма розгортання.

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

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

Будь-які (у тому числі і програмні) системи проектуються з урахуванням того, що в процесі своєї роботи вони будуть використовуватися людьми та взаємодіяти з іншими системами. Сутності, з якими взаємодіє система у процесі своєї роботи, називаються екторами, причому кожен ектор очікує, що система поводитиметься строго певним, передбачуваним чином. Спробуємо дати суворіше визначення ектора. Для цього скористаємося чудовим візуальним словникомза UML Zicom Mentor:

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

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

Уважний читач відразу може поставити запитання: а чому ектор, а не актор? Згодні, слово "ектор" трохи ріже слух російської людини. Причина ж, чому ми говоримо саме так, проста – ектор утворено від слова action, що в перекладі означає дія. Дослівний переклад слова "ектор" - дійова особа- Надто довгий і незручний для вживання. Тому ми й далі говоритимемо саме так.

Той же уважний читач міг помітити слово "прецедент", що промайнуло у визначенні ектора. Що це таке? Це питання зацікавить нас ще більше, якщо згадати, що зараз ми говоримо про діаграмі прецедентів. Отже,

Прецедент (use-case)- Опис окремого аспекту поведінки системи з точки зору користувача (Буч).

Визначення цілком зрозуміле і вичерпне, але його можна ще трохи уточнити, скориставшись тим самим Zicom Mentor"ом:

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

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

Уніфікована мова моделювання (UML) зараз є стандартом де-факто при описі (документування) результатів проектування та розробки об'єктно-орієнтованих систем. Початок розробки UML було покладено в 1994 р. Граді Бучем та Джеймсом Рамбо, які працювали в компанії Rational Software. Восени 1995 р. до них приєднався Івар Якобсон і в жовтні того ж року було випущено попередню версію 0.8 уніфікованого методу (англ. Unified Method). З цього часу було випущено кілька версій специфікації UML, дві з яких мають статус міжнародного стандарту:

UML 1.4.2 – ISO/IEC 19501:2005. Інформаційні технології. Відкрита розподільча обробка. Уніфікована мова моделювання (UML). Версія 1.4.2" (англ. "Information technology. Open distributed processing. Unified modeling language (UML). Version 1.4.2");

UML 2.4.1 – "ISO/IEC 19505-1:2012. Інформаційні технології. Уніфікована мова моделювання групи з управління об'єктами (OMG UML). Частина 1. Інфраструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language ( OMG UML) - Part 1: Infrastructure") та "ISO/IEC 19505-2:2012. Інформаційні технології. Уніфікована мова моделювання групи з управління об'єктами (OMG UML). Частина 2. Надструктура" (англ. "Information technology -- Object Management Group Unified Modeling Language (OMG UML) - Part 2: Superstructure").

Останню офіційну специфікацію мови можна знайти на сайті www.omg.org.

Загальна структура UML показана на наступному малюнку.

Мал. 11.1. Структура UML

11.2. Семантика та синтаксис UML

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

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

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

11.3. Нотація UML

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

У UML визначено три типу сутностей :

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

Групуюча - елемент, що використовується для деякого значеннєвого об'єднання елементів діаграми;

Пояснювальна (анотаційна) – коментар до елемента діаграми.

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

Таблиця 11.1. Сутності

Тип	Найменування	Позначення	Визначення (семантика)
Структурна	(class)		Безліч об'єктів, що мають загальну структуру та поведінку
	(object)		Абстракція реальної чи уявної сутності з чітко вираженими концептуальними межами, індивідуальністю (ідентичності), станом та поведінкою. З точки зору UML об'єкти є екземплярами класу (примірниками сутності)
	(actor)	Інженер служби шляху	Зовнішня по відношенню до системи сутність, яка взаємодіє із системою та використовує її функціональні можливостідля досягнення певних цілей чи вирішення приватних завдань. Таким чином актор – це зовнішнє джерело або приймач інформації
	(use case)		Опис виконуваних системою дій, що призводить до значущого для актора результату
	(state)		Опис моменту в ході життя сутності, коли вона задовольняє певну умову, виконує деяку діяльність або чекає настання деякої події
	Кооперація (Colaboration)		Опис сукупності екземплярів акторів, об'єктів та їх взаємодії у процесі вирішення деякого завдання
	(component)		Фізична частина системи (файл), у тому числі модулі системи, що забезпечують реалізацію узгодженого набору інтерфейсів
	(Interface)	iРозрахунок	Сукупність операцій, що визначає сервіс (набір послуг), що надається класом чи компонентом
	(node)		Фізична частина системи (комп'ютер, принтер тощо), що надає ресурси для вирішення задачі
Групуюча	(package)		Загальний механізм угруповання елементів. На відміну від компонента, пакет – суто концептуальне (абстрактне) поняття. Приватними випадками пакету є система та модель
	(fragment)		Область специфічної взаємодії екземплярів акторів та об'єктів
	(діяльність партії)		Група операцій (зона відповідальності), що виконуються однією сутністю (актором, об'єктом, компонентом, вузлом тощо)
	(Interruptible activity region)		Група операцій, звичайна послідовність виконання яких може бути перервана в результаті настання нестандартної ситуації
Пояснювальна	Примітка (comment)		Коментар до елемента. Приєднується до коментованого елемента штриховою лінією

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

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

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

Таблиця 11.3. Відносини

Найменування	Позначення	Визначення (семантика)
Асоціація (association)		Відношення, що описує значний зв'язок між двома та більш сутностями. Найбільш загальний виглядвідносини
Агрегація (aggregation)		Підвид асоціації, що описує зв'язок "частина" - "ціле", в якому "частина" може існувати окремо від "цілого". Ромб вказується з боку "цілого". Ставлення вказується лише між сутностями одного типу
Композиція (composition)		Підвид агрегації, у якій " частини " що неспроможні існувати окремо від " цілого " . Як правило, "частини" створюються та знищуються одночасно з "цілим"
Залежність (dependency)		Відношення між двома сутностями, в якому зміна в одній сутності (незалежній) може впливати на стан чи поведінку іншої сутності (залежної). З боку стрілки вказується незалежна сутність
Узагальнення (generalization)		Відношення між узагальненою сутністю (предком, батьком) та спеціалізованою сутністю (нащадком, донькою). Трикутник вказується з боку батька. Відношення вказується лише між сутностями одного типу
Реалізація (Realization)		Відношення між сутностями, де одна сутність визначає дію, яку інша сутність зобов'язується виконати. Відносини використовуються у двох випадках: між інтерфейсами та класами (або компонентами), між варіантами використання та коопераціями. З боку стрілки вказується сутність, що визначає дію (інтерфейс чи варіант використання)

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

- * – будь-яку кількість екземплярів, у тому числі й жодного;

Ціле невід'ємне число - кратність суворо фіксована і дорівнює вказаній кількості (наприклад: 1, 2 або 5);

Діапазон цілих невід'ємних чисел "перше число. друге число" (наприклад: 1..5, 2..10 або 0..5);

Діапазон чисел від конкретного початкового значення до будь-якого кінцевого "перше число.. *" (наприклад: 1..*, 5..* або 0..*);

Перелік цілих невід'ємних чисел та діапазонів через кому (наприклад: 1, 3..5, 10, 15..*).

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

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

Таблиця 11.4. Механізми розширення

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

a) стандартне позначення		б) стандартне позначення із текстовим стереотипом		в) графічний стереотип

Мал. 11.2. Приклади стандартного та стереотипного відображення класу

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

Таблиця 11.5. Діаграми

Стандарт UML 2.x визначає також додаткові, вузькоспеціалізовані діаграми:

Діаграма об'єктів (object diagram) - аналогічна, але замість класів відображаються об'єкти;

Діаграму синхронізації (timing diagram) - визначає стан об'єкта з часом;

Композитну структурну діаграму (composite structure diagram) – визначає порти (включаючи інтерфейси) класу для взаємодії з іншими класами;

Профільну діаграму (profile diagram) – аналогічна з описом класів, що входять до них;

Оглядову діаграму взаємодії (interaction overview diagram) - аналогічна, але із прихованими фрагментами взаємодії (фрагментами з позначкою ref). Є контекстною (концептуальною) , елементи якої будуть конкретизовані на окремих діаграмах декомпозиції.

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

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

Таблиця 11.6. Зв'язок моделей та діаграм

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

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

4. Дайте визначення поняття "".

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

Навіщо вона потрібна?

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

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

Також є кілька видів таких діаграм.

Діаграма класів

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

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

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

Діаграма компонентів

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

Діаграма композитної/складової структури

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

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

Слід зазначити, що одночасно можна використовувати види діаграм UML класів і композитної структури.

Діаграма розгортання

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

Між артефактом і тим компонентом, що він реалізує, формується залежність маніфестації.

Діаграма об'єктів

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

Діаграма пакетів

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

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

Діаграма діяльності

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

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

Діаграма автомата

Цей вид називається і трохи інакше – діаграма станів UML. Має представлений кінцевий автомат із простими та композитними станами, а також переходами.

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

Як аналоги таких діаграм можуть використовуватися так звані дракон-схеми.

Діаграми сценаріїв використання

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

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

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

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

Комунікації

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

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

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

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

Діаграма послідовності

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

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

Діаграма співробітництва

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

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

Діаграми огляду взаємодії

Це діаграми мови UML, які відносяться до різновиду діаграм діяльності і включають одночасно елементи Sequence і конструкції потоку управління.

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

Діаграма синхронізації

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

У чому переваги?

Варто відзначити кілька переваг, якими відрізняється UML діаграма користування та інші:

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

Недоліки

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

• Надмірність. У переважній більшості випадків критики говорять про те, що UML є занадто великим і складним, і це часто невиправдано. До нього входить досить багато надмірних або практично марних конструкцій і діаграм, причому найчастіше подібна критика йде на адресу другої версії, а не першої, тому що в нових ревізіях присутня більша кількість компромісів «розроблених комітетом».
• Різні неточності у семантиці. З тієї причини, що UML визначається комбінацією себе, англійської та OCL, у нього відсутня скутість, яка є властивою мовам, точно визначеним технікою формального опису. У певних ситуаціях абстрактний синтаксис OCL, UML та англійська починають один одному суперечити, тоді як в інших випадках вони є неповними. Неточність опису самої мови однаково відбивається як у користувачах, і на постачальниках інструментів, що зрештою призводить до несумісності інструментів через унікального способу трактування різних специфікацій.
• Проблеми у процесі впровадження та вивчення. Всі зазначені вище проблеми створюють певні складнощі в процесі впровадження та вивчення UML, і особливо це стосується тих випадків, коли керівництво змушує інженерів насильно використовувати його, в той час як у них відсутні попередні навички.
• Код відбиває код. Ще однією думкою є те, що важливість мають не гарні та привабливі моделі, а безпосередньо робочі системи, тобто код і є проект. Відповідно до цієї думки є потреба в тому, щоб розробити ефективніший спосіб написання програмного забезпечення. UML прийнято цінувати при підходах, що компілюють моделі для регенерування здійснюваного або вихідного коду. Але насправді цього може бути недостатньо, тому що в даній мові відсутні властивості повноти по Тьюрингу, і кожен згенерований код в кінцевому підсумку буде обмежуватися тим, що може припустити або визначити UML інструмент, що інтерпретує.
• Узгодження навантаження. Цей термін походить з теорії системного аналізу визначення нездатності входу певної системи сприйняти вихід інший. Як у будь-яких стандартних системах позначень, UML може представляти одні системи більш ефективному і короткому вигляді порівняно з іншими. Таким чином, розробник більше схиляється до тих рішень, які більш комфортні для переплетення всіх сильних сторін UML, а також інших мов програмування. Ця проблемає більш очевидною у тому випадку, якщо мова розробки не відповідає основним принципам об'єктно-орієнтованої ортодоксальної доктрини, тобто не намагається працювати відповідно до принципів ОВП.
• Намагається бути універсальним. UML є мовою моделювання загального призначення, яка намагається забезпечити сумісність з будь-якою мовою обробки, що існує на сьогоднішній день. У контексті певного проекту, щоб команда проектувальників змогла досягти кінцевої мети, потрібно вибирати застосовні можливості цієї мови. Крім цього, можливі шляхи обмеження сфери використання UML в якійсь певній галузі проходять через формалізм, який є не повністю сформульованим, а який сам є об'єктом критики.

Таким чином, використання цієї мови є актуальним далеко не у всіх ситуаціях.

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

Навіщо вона потрібна?

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

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

Також є кілька видів таких діаграм.

Діаграма класів

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

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

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

Діаграма компонентів

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

Діаграма композитної/складової структури

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

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

Слід зазначити, що одночасно можна використовувати види діаграм UML класів і композитної структури.

Діаграма розгортання

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

Між артефактом і тим компонентом, що він реалізує, формується залежність маніфестації.

Діаграма об'єктів

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

Діаграма пакетів

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

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

Діаграма діяльності

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

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

Діаграма автомата

Цей вид називається і трохи інакше – діаграма станів UML. Має представлений кінцевий автомат із простими та композитними станами, а також переходами.

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

Як аналоги таких діаграм можуть використовуватися так звані дракон-схеми.

Діаграми сценаріїв використання

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

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

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

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

Комунікації

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

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

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

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

Діаграма послідовності

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

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

Діаграма співробітництва

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

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

Діаграми огляду взаємодії

Це діаграми мови UML, які відносяться до різновиду діаграм діяльності і включають одночасно елементи Sequence і конструкції потоку управління.

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

Діаграма синхронізації

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

У чому переваги?

Варто відзначити кілька переваг, якими відрізняється UML діаграма користування та інші:

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

Недоліки

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

• Надмірність. У переважній більшості випадків критики говорять про те, що UML є занадто великим і складним, і це часто невиправдано. До нього входить досить багато надмірних або практично марних конструкцій і діаграм, причому найчастіше подібна критика йде на адресу другої версії, а не першої, тому що в нових ревізіях присутня більша кількість компромісів «розроблених комітетом».
• Різні неточності у семантиці. З тієї причини, що UML визначається комбінацією себе, англійської та OCL, у нього відсутня скутість, яка є властивою мовам, точно визначеним технікою формального опису. У певних ситуаціях абстрактний синтаксис OCL, UML та англійська починають один одному суперечити, тоді як в інших випадках вони є неповними. Неточність опису самої мови однаково відбивається як у користувачах, і на постачальниках інструментів, що зрештою призводить до несумісності інструментів через унікального способу трактування різних специфікацій.
• Проблеми у процесі впровадження та вивчення. Всі зазначені вище проблеми створюють певні складнощі в процесі впровадження та вивчення UML, і особливо це стосується тих випадків, коли керівництво змушує інженерів насильно використовувати його, в той час як у них відсутні попередні навички.
• Код відбиває код. Ще однією думкою є те, що важливість мають не гарні та привабливі моделі, а безпосередньо робочі системи, тобто код і є проект. Відповідно до цієї думки є потреба в тому, щоб розробити ефективніший спосіб написання програмного забезпечення. UML прийнято цінувати при підходах, що компілюють моделі для регенерування здійснюваного або вихідного коду. Але насправді цього може бути недостатньо, тому що в даній мові відсутні властивості повноти по Тьюрингу, і кожен згенерований код в кінцевому підсумку буде обмежуватися тим, що може припустити або визначити UML інструмент, що інтерпретує.
• Узгодження навантаження. Цей термін походить з теорії системного аналізу визначення нездатності входу певної системи сприйняти вихід інший. Як у будь-яких стандартних системах позначень, UML може представляти одні системи більш ефективному і короткому вигляді порівняно з іншими. Таким чином, розробник більше схиляється до тих рішень, які більш комфортні для переплетення всіх сильних сторін UML, а також інших мов програмування. Ця проблема є більш очевидною у тому випадку, якщо мова розробки не відповідає основним принципам об'єктно-орієнтованої ортодоксальної доктрини, тобто не намагається працювати відповідно до принципів ОВП.
• Намагається бути універсальним. UML є мовою моделювання загального призначення, яка намагається забезпечити сумісність з будь-якою мовою обробки, що існує на сьогоднішній день. У контексті певного проекту, щоб команда проектувальників змогла досягти кінцевої мети, потрібно вибирати застосовні можливості цієї мови. Крім цього, можливі шляхи обмеження сфери використання UML в якійсь певній галузі проходять через формалізм, який є не повністю сформульованим, а який сам є об'єктом критики.

Таким чином, використання цієї мови є актуальним далеко не у всіх ситуаціях.

Усі діаграми UML можна умовно розбити на дві групи, перша з яких – спільні діаграми. Загальні діаграми практично не залежать від предмета моделювання та можуть застосовуватись у будь-якому програмному проекті без огляду на предметну область, область рішень тощо.

1.5.1. Діаграма використання

Діаграма використання(use case diagram) ‒ це найбільш загальне уявлення функціонального призначення системи.

Діаграма використання покликана відповісти на головне питаннямоделювання: що робить система у зовнішньому світі?

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

• асоціація між дійовою особою та варіантом використання 3 ;
• узагальнення між дійовими особами 4;
• узагальнення між варіантами використання 5;
• залежності ( різних типів) між варіантами використання 6 .

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

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

1.5.2. Діаграма класів

Діаграма класів(class diagram) – основний спосіб опису структури системи.

Це не дивно, оскільки UML насамперед об'єктно-орієнтована мова, і класи є основним (якщо не єдиним) "будівельним матеріалом".

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

• асоціація між класами 2 (з безліччю додаткових подробиць);
• узагальнення між класами 3;
• залежності (різних типів) між класами 4 та між класами та інтерфейсами.

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

1.5.3. Діаграма автомата

Діаграма автомата(state machine diagram) ‒ це один із способів детального опису поведінки в UML на основі явного виділення станів та опису переходів між станами.

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

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

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

1.5.4. Діаграма діяльності

Діаграма діяльності(activity diagram) ‒ спосіб опису поведінки на основі вказівки потоків управління та потоків даних.

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

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

1.5.5. Діаграма послідовності

Діаграма послідовності(sequence diagram) ‒ це спосіб опису поведінки системи на основі вказівки послідовності повідомлень, що передаються.

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

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

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

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

На наступному малюнку показані основні елементи нотації, які застосовуються на діаграмі послідовності. Для позначення самих взаємодіючих об'єктів застосовується стандартна нотація прямокутник з ім'ям екземпляра класифікатора. Пунктирна лінія, що виходить із нього, називається лінією життя (lifeline) 4 . Це не позначення відносини в моделі, а графічний коментар, покликаний звернути увагу читача діаграми в правильному напрямку. Фігури у вигляді вузьких смужок, накладених на лінію життя, також не є зображеннями сутностей, що моделюються. Це графічний коментар, що показує відрізки часу, протягом яких об'єкт володіє потоком управління (execution occurrence) 5 чи іншими словами має місце активація (activation) об'єкта. Складові кроки взаємодії (combined fragment) 6 дозволяють на діаграмі послідовності, відображати алгоритмічні аспекти протоколу взаємодії. Інші деталі нотації діаграми послідовностей див. у розділі 4 .

1.5.6. Діаграма комунікації

Діаграма комунікації(Communication diagram) ‒ спосіб опису поведінки, семантично еквівалентний діаграмі послідовності.

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

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

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

1.5.7. Діаграма компонентів

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

Основний тип сутностей на діаграмі компонентів - це самі компоненти 1, а також інтерфейси 2, за допомогою яких вказується взаємозв'язок між компонентами. На діаграмі компонентів застосовуються такі відносини:

• реалізації між компонентами та інтерфейсами (компонент реалізує інтерфейс);
• залежності між компонентами та інтерфейсами (компонент використовує інтерфейс) 3 .

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

1.5.8. Діаграма розміщення

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

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

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