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

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

Коротка історія UML

До середини 90-х років різними авторами було запропоновано кілька десятків методів ГО моделювання, кожен із яких використовував свою графічну нотацію. При цьому будь-який з цих методів мав свої сильні сторони, але не дозволяв побудувати досить повну модель ПС, показати її «з усіх боків», тобто всі необхідні проекції (див. статтю 1). До того ж відсутність стандарту ГО моделювання ускладнювало для розробників вибір найбільш відповідного методу, що перешкоджало поширенню ГО підходу до розробки ПС.

За запитом Object Management Group (OMG) – організації, відповідальної за прийняття стандартів у галузі об'єктних технологій та баз даних, назрілу проблему уніфікації та стандартизації було вирішено авторами трьох найбільш популярних ГО методів – Г.Бучем, Д.Рамбо та А.Джекобсоном, які об'єднані зусиллями створили версію UML 1.1, затверджену OMG у 1997 році як стандарт.

UML – це мова

Будь-яка мова складається зі словника та правил комбінування слів для отримання осмислених конструкцій. Так, зокрема, влаштовані мови програмування, такою є UML. Відмінною його особливістю є те, що словник утворюють графічні елементи. Кожному графічному символу відповідає конкретна семантика, тому модель, створена одним розробником, може бути однозначно зрозуміла іншим, а також програмним засобом, що інтерпретує UML. Звідси, зокрема, випливає, що модель ПС, представлена на UML, може автоматично бути переведена на ГО мову програмування (такі як Java, C++, VisualBasic), тобто, за наявності гарного інструментального засобу візуального моделювання, що підтримує UML, побудувавши модель , ми отримаємо і заготівлю програмного коду, що відповідає цій моделі.

Слід наголосити, що UML – це саме мова, а не метод. Він пояснює, з яких елементів створювати моделі та як їх читати, але нічого не говорить про те, які моделі та в яких випадках слід розробляти. Щоб створити метод з урахуванням UML, треба доповнити його описом процесу розробки ПС. Прикладом такого процесу є Rational Unified Process, який розглядатиметься у наступних статтях.

Словник UML

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

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

Відносинипоказують різні зв'язки між сутностями. У UML визначено такі типи відносин:

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

діаграми.У UML передбачені такі діаграми:

Діаграми, що описують поведінку системи:

Діаграми станів (State diagrams),
Діаграми діяльності (Activity diagrams),
Діаграми об'єктів (Object diagrams),
Діаграми послідовностей (Sequence diagrams),
Діаграми взаємодії (Collaboration diagrams);

Діаграми, що описують фізичну реалізацію системи:

Діаграми компонентів (Component diagrams);
Діаграми розгортання (Deployment diagrams).

Подання керування моделлю. Пакети.

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

Що забезпечує UML.

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

І останнє…

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

11.1. Структура уніфікованої мови моделювання

Уніфікована мова моделювання (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. Механізми розширення

Найменування	Позначення	Визначення (семантика)
Стереотип (stereotype)	« »	Позначення, що уточнює семантику елемента нотації (наприклад: залежність зі стереотипом "include" розглядається як ставлення включення, а клас зі стереотипом "boundary" - граничний клас)
Сторожова умова (guard condition)		Логічне умова (наприклад: або [ідентифікація виконана])
Обмеження (Constraint)	{ }	Правило, що обмежує семантику елемента моделі (наприклад (час виконання менше 10 мс))
Позначене значення (Tagged value)	{ }	Нова або уточнююча властивість елемента нотації (наприклад: (version = 3.2))

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


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

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

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

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

Діаграма			Призначення
				за ступенем фізичної реалізації	з відображення динаміки	за відображуваним аспектом
(use case)			Відображає функції системи, взаємодію між акторами та функціями	Логічна	Статична	Функціональна
(class)			Відображає набір класів, інтерфейсів та відносин між ними	Логічна або фізична	Статична	Функціонально-інформаційна
(package)			Відображає набір пакетів та відносин між ними	Логічна або фізична	Статична	Компонентна
Поводження (behavior)	(state machine)		Відображає стан сутності та переходи між ними в процесі її життєвого циклу	Логічна	Динамічна	Поведінкова
	(діяльність)		Відображає бізнес-процеси у системі (опис алгоритмів поведінки)
	Взаємодія (Interaction)	(Sequence)	Відображає послідовність передачі повідомлень між об'єктами та акторами.
		(Communication)	Аналогічна діаграмі послідовності, але основний акцент робиться на структуру взаємодії між об'єктами
Реалізації (implementation)	(component)		Відображає компоненти системи (програми, бібліотеки, таблиці тощо) та зв'язки між ними	Фізична	Статична	Компонентна
	(Deployment)		Відображає розміщення компонентів по вузлах мережі та її конфігурацію

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

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

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

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

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

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

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

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

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

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

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

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

Модель UML(UML model) – це сукупність кінцевої множини конструкцій мови, головні з яких – це сутності та відносини між ними.

Самі сутності та відносини моделі є екземплярами метакласів метамоделі.

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

1.4.1. Сутності

Для зручності огляду сутності в UML можна поділити на чотири групи:

структурні;
поведінкові;
групуючі;
анотаційні.

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

Об'єкт(object) 1 – сутність, що має унікальність та інкапсулює в собі стан і поведінку.

Клас(class) 2 ‒ опис безлічі об'єктів із загальними атрибутами, що визначають стан, та операціями, що визначають поведінку.

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

Кооперація(collaboration) 4 ‒ сукупність об'єктів, які взаємодіють задля досягнення певної мети.

Дійова особа(actor) 5 ‒ сутність, що знаходиться поза модельованою системою і безпосередньо взаємодіє з нею.

∇ Подібний взаємозв'язок безумовно існує, що виражається на рис. Ієрархія типів діаграм для UML 1як відносини залежності зі стереотипом «refine» .

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

∇∇∇ У UML 2 синтаксичне та смислове навантаження діаграми станів настільки змінилося, що назва вже не відображала змісту.

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

Діаграма внутрішньої структури (Composite Structure diagram)
Діаграма пакетів (Package diagram)
Діаграма автомата (State machine diagram)
Діаграма комунікації (Communication diagram)
Оглядова діаграма взаємодії (Interaction Overview diagram)
Діаграма синхронізації (Timing diagram)

На рис. Ієрархія типів діаграм для UML 2 (частина 1 та 2)наведена діаграма класів, що відображає взаємозв'язок діаграм UML 2.

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

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

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

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

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

Табл. Типи та теги діаграм

Назва діаграми	Тег (стандартний)	Тег (пропонований)
Діаграма використання	use caseабо uc	use case
Діаграма класів	class	class
Діаграма автомата	state machineабо stm	state machine
Діаграма діяльності	Діяльністьабо act	Діяльність
Діаграма послідовності	interactionабо sd	sd
Діаграма комунікації	interactionабо sd	comm
Діаграма компонентів	componentабо cmp	component
Діаграма розміщення	не визначений	deployment
Діаграма об'єктів	не визначений	object
Діаграма внутрішньої структури	class	classабо component
Оглядова діаграма взаємодії	interactionабо sd	interaction
Діаграма синхронізації	interactionабо sd	timing
Діаграма пакетів	packageабо pkg	package

UML або Unified Modeling Language – мова графічного опису для об'єктного моделювання в галузі розробки програмного забезпечення. Але використання UML не обмежується IT, інша велика сфера практичного застосування UML – моделювання бізнес-процесів, системного проектування та відображення організаційних структур. UML дає можливість розробникам програмного забезпечення досягти угоди у графічних позначеннях для представлення загальних понять та сконцентруватися на проектуванні та розробці.

Переваги UML

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

Типи діаграм UML

У UML 14 типів діаграм. Їх можна розділити на 2 категорії:

структурні, Що представляють інформаційну структуру;
поведінкові, що представляють поведінку системи та різні аспекти взаємодій. Окремим підвидом діаграм поведінки вважаються діаграми взаємодії.

Ієрархія типів діаграм UML,
представлена діаграмою класів

Структурні діаграми

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

Приклад UML-діаграм класів

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

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

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

Комерційні продукти

Microsoft Visio

Тип: комерційне ПЗ

Популярний програмний продукт від компанії Microsoft, який дозволяє малювати багаті діаграми, зокрема UML:

Починаючи з 2010 версії з'явилася можливість публікувати діаграми в Інтернеті (SharePoint + Visio Services):

Visio Viewer- Безкоштовна програма, яка дозволяє переглядати створені раніше Visio діаграми. Завантажити можна по %D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5%20.

%0A

Microsoft%20Visual%20Studio%202010

%0A

%D0%A2%D0%B8%D0%BF:%20%D0%BA%D0%BE%D0%BC%D0%BC%D0%B5%D1%80%D1%87%D0%B5%D1% 81%D0%BA%D0%BE%D0%B5%20%D0%9F%D0%9E%20(%D0%B5%D1%81%D1%82%D1%8C%20%D0%B1%D0 %B5%D1%81%D0%BF%D0%BB%D0%B0%D1%82%D0%BD%D0%B0%D1%8F%20Express%20%D0%B2%D0%B5%D1%80 %D1%81%D0%B8%D1%8F).

%0A

%D0%92%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BD%D0%B5%D0%B9%20%D0%B2%D0 %B5%D1%80%D1%81%D0%B8%D0%B8%20Microsoft%20Visual%20Studio%202010%20%D0%BF%D0%BE%D1%8F%D0%B2%D0%B8%D0 %BB%D1%81%D1%8F%20%D0%BD%D0%BE%D0%B2%D1%8B%D0%B9%20%D1%82%D0%B8%D0%BF%20%D0 %BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B0%20-%20Modelling,%20%D0%BA%D0%BE%D1%82%D0%BE %D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82 %20%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%80%D0%B0%D0%B7%D0 %BB%D0%B8%D1%87%D0%BD%D1%8B%D0%B5%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0 %D0%BC%D0%BC%D0%B0%20%D0%B8%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1 %82%D1%8C%20%D0%BD%D0%B0%D0%BF%D0%B8%D1%81%D0%B0%D0%BD%D0%BD%D1%8B%D0%B5%20 %D1%80%D0%B5%D1%88%D0%B5%D0%BD%D0%B8%D1%8F%20%D0%BD%D0%B0%20%D1%81%D0%BE%D0 %BE%D1%82%D0%B2%D0%B5%D1%82%D1%81%D1%82%D0%B2%D0%B8%D0%B5%20%D1%81%20%D0%BD %D0%B5%D0%BE%D0%B1%D1%85%D0%BE%D0%B4%D0%B8%D0%BC%D0%BE%20%D0%B0%D1%80%D1%85 %D0%B8%D1%82%D0%B5%D0%BA%D1%82%D1%83%D1%80%D0%BE%D0%B9.

%0A

%D0%9F%D0%BE%D0%B7%D0%B2%D0%BE%D0%BB%D1%8F%D0%B5%D1%82%20%D0%B3%D0%B5%D0%BD %D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20Sequence%20Diagram%20%D0%BD%D0%B0 %20%D0%BE%D1%81%D0%BD%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B8%20%D0%BA%D0%BE%D0 %B4%D0%B0,%20%D0%B2%D0%B8%D0%B7%D1%83%D0%B0%D0%BB%D0%B8%D0%B7%D0%B8%D1%80% D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20%D1%81%D0%B2%D1%8F%D0%B7%D0%B8%20%D0%B2%20% D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%B5%20%D0%BC%D0%B5%D0%B6%D0%B4%D1%83% 20%D0%BA%D0%BE%D0%BC%D0%BF%D0%BE%D0%BD%D0%B5%D0%BD%D1%82%D0%B0%D0%BC%D0%B8, %20%D1%81%D0%B1%D0%BE%D1%80%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%81%D1%81 %D1%8B%D0%BB%D0%BA%D0%B0%D0%BC%D0%B8%20%D0%B8%20%D1%82.%D0%B4.

%0A

%D0%9F%D1%80%D0%B8%D0%BC%D0%B5%D1%80%20Use%20case%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80 %D0%B0%D0%BC%D0%BC%D1%8B,%20%D0%BD%D0%B0%D1%80%D0%B8%D1%81%D0%BE%D0%B2%D0% B0%D0%BD%D0%BD%D0%BE%D0%B9%20%D0%B2%20Visual%20Studio%202010:

%0A%0A

%D0%9A%D1%80%D0%BE%D0%BC%D0%B5%20%D1%82%D0%BE%D0%B3%D0%BE,%20%D0%B4%D0%BE% D1%81%D1%82%D1%83%D0%BF%D0%B5%D0%BD%20Visualization%20and%20Modeling%20Feature%20Pack%20(%D0%B4%D0%BB%D1%8F%20 %D0%BF%D0%BE%D0%B4%D0%BF%D0%B8%D1%81%D1%87%D0%B8%D0%BA%D0%BE%D0%B2%20MSDN),%20 %D0%BA%D0%BE%D1%82%D0%BE%D1%80%D1%8B%D0%B9%20%D0%BF%D0%BE%D0%B7%D0%B2%D0%BE %D0%BB%D1%8F%D0%B5%D1%82:

%0A

%D0%B3%D0%B5%D0%BD%D0%B5%D1%80%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1%8C%20 %D0%BA%D0%BE%D0%B4%20%D0%BD%D0%B0%20%D0%B1%D0%B0%D0%B7%D0%B5%20UML%20%D0%B4%D0 %B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%20%D0%BA%D0%BB%D0%B0%D1%81%D1%81%D0 %BE%D0%B2
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20UML%20%D0%B4%D0%B8%D0 %B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B8%D0%B7%20%D0%BA%D0%BE%D0%B4 %D0%B0
%D0%B8%D0%BC%D0%BF%D0%BE%D1%80%D1%82%D0%B8%D1%80%D0%BE%D0%B2%D0%B0%D1%82%D1 %8C%20UML%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%BA%D0 %BB%D0%B0%D1%81%D1%81%D0%BE%D0%B2,%20%D0%B4%D0%B8%D0%B0%D0%B3%D1%80%D0%B0% D0%BC%D0%BC%D1%8B%20%D0%BF%D0%BE%D1%81%D0%BB%D0%B5%D0%B4%D0%BE%D0%B2%D0%B0% D1%82%D0%B5%D0%BB%D1%8C%D0%BD%D0%BE%D1%81%D1%82%D0%B5%D0%B9,%20%D0%B4%D0%B8 %D0%B0%D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B2%D0%B0%D1%80%D0%B8%D0%B0 %D0%BD%D1%82%D0%BE%D0%B2%20%D0%B8%D1%81%D0%BF%D0%BE%D0%BB%D1%8C%D0%B7%D0%BE %D0%B2%D0%B0%D0%BD%D0%B8%D1%8F%20%D1%81%20XMI%202.1
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B4%D0%B8%D0%B0 %D0%B3%D1%80%D0%B0%D0%BC%D0%BC%D1%8B%20%D0%B7%D0%B0%D0%B2%D0%B8%D1%81%D0%B8 %D0%BC%D0%BE%D1%81%D1%82%D0%B5%D0%B9%20%D0%B4%D0%BB%D1%8F%20ASP.NET,%20C%20%D0% B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%D1%81%D0%BE%D0%B7%D0%B4%D0%B0%D0%B2%D0%B0%D1%82%D1%8C%20%D0%B8%20%D0%BF%D1 %80%D0%BE%D0%B2%D0%B5%D1%80%D1%8F%D1%82%D1%8C%20layer%20diagrams%20%D0%B4%D0%BB%D1%8F%20C %20%D0%B8%20C++%20%D0%BF%D1%80%D0%BE%D0%B5%D0%BA%D1%82%D0%BE%D0%B2
%D0%BF%D0%B8%D1%81%D0%B0%D1%82%D1%8C%20%D1%81%D0%BE%D0%B1%D1%81%D1%82%D0%B2 %D0%B5%D0%BD%D0%BD%D1%8B%D0%B5%20%D0%BF%D1%80%D0%BE%D0%B2%D0%B5%D1%80%D0%BA %D0%B8%20%D0%B4%D0%BB%D1%8F%20layer%20diagrams

%D0%A1%D0%BA%D0%B0%D1%87%D0%B0%D1%82%D1%8C%20Visualization%20and%20Modeling%20Feature%20Pack%20%D0%BC%D0%BE%D0 %B6%D0%BD%D0%BE%20%D0%BF%D0%BE%20%D1%81%D1%81%D1%8B%D0%BB%D0%BA%D0%B5:%20 http://msdn.microsoft.com/ru-ua/vstudio/ff655021%28en-us%29.aspx.

IBM Rational Rose

Можливості:

Use case diagram (діаграми прецедентів);
Deployment diagram (діаграми топології);
Statechart diagram (діаграми станів);
Activity diagram (діаграми активності);
Interaction diagram (діаграми взаємодії);
Sequence diagram (діаграми послідовностей дій);
Collaboration diagram (діаграми співробітництва);
Class diagram (діаграми класів);
Component diagram (діаграми компонент).

Скріншоти:

Open source програми

StarUML

Можливості:

підтримка UML 2.0
MDA (Model Driven Architecture)
Plug-in Architecture (писати можна на COM сумісних мовах: C++, Delphi, C#, VB, ...)

StarUML написана в основному на Delphi, але дописувати компоненти можна і іншими мовами, наприклад C/C++, Java, Visual Basic, Delphi, JScript, VBScript, C#, VB.NET. Нижче показано кілька скріншотів.

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