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

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

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

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

Історія цієї мови почалася, по комп'ютерним мірками, не так уже й недавно, але і не сказати, щоб сильно давно - в 1994 році. Так що UML практично ровесник нашої газети. Зародився він в надрах компанії Rational Software, яка задумала випустити на ринок нову мову об'єктно-орієнтованого моделювання - природно, найкращий, ніж всі, які вже існували на той момент. Зазвичай початок історії UML пов'язують з прізвищами Буч, Рамбо і приєдналася до них пізніше Якобсона, які в кінці 1995 вже створили консорціум Object Management Group (OMG), який восени 1996 випустив версію 0.9 специфікації UML, яку багато хто вважає важливою віхою в історії мови. Оскільки після неї до консорціуму приєдналися компанії Digital Equipment Corporation, Hewlett-Packard, i-Logix, IntelliCorp, IBM, ICON Computing, MCI Systemhouse, Microsoft, Oracle Corporation, сама прародителька UML Rational Software, а також Texas Instruments і Unisys. З їх допомогою в січні 1997 побачила світ версія 1.0 стандарту. Але зараз, звичайно, більш актуальною є випущена в 2005-му версія 2.0.

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

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

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

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

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

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

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

Засоби UML-моделювання, як я вже говорив на самому початку статті, є вже у багатьох засобах розробки. Наприклад, в CodeGear RAD Studio 2007 (це те, що раніше називалося Borland Developer Studio). Має вбудовані можливості моделювання і інше середовище від тих же розробників - JBuilder. Але, тим не менше, вбудовані засоби моделювання традиційно вважаються менш потужними, ніж спеціалізовані програмні продукти. У тій же Borland є продукт Together, потужний продукт для UML-моделювання. Говорячи про інші подібні програми, не можна не згадати Enterprise Architect ( www.sparxsystems.com.au ), UML Studio ( www.pragsoft.com ), Visual Paradigm for UML ( www.visual-paradigm.com ), А також PowerDesigner від Sybase.

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

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

Вадим СТАНКЕВИЧ, [email protected]