Delphi programming blog, UML моделювання в Delphi
Ефективне UML моделювання полегшує процес розробки ваших проектів. Тісна інтеграція середовища та інструментів моделювання дозволяє легко трансформувати модель у вихідний код. Головна мета UML моделювання полягає в організації та представленні структури та компонентів програмних систем, розроблених в стилі ООП . Моделі використовуються для візуального представлення вимог, підсистем, логічних та фізичних елементів, структурних схем, а також схем поведінки (патернів). У Delphi побудовані UML моделі автоматично синхронізуються із вихідним кодом. UML діаграми проектуються із застосуванням концепцій пакетів, інтерфейсів, класів, атрибутів (властивостей) та операцій.
UML модель не тільки представляє систему повністю, а й дозволяє вам сфокусуватися на її структурі та поведінці. Цей інструментарій надає функції необхідні для проектування та побудова об'єктно орієнтованих систем, дозволяючи всій команді розробників (архітекторам, розробникам, тестувальникам, менеджерам, керівникам) використовувати спільну мову, незалежно від мови програмування, що спрацьовує, спрощуючи обговорення проекту та його розробку.
Звичайно ж, без постійної взаємної синхронізації моделі та коду такий інструмент був би не дуже корисний/зручний. Як вже писалося, інструменти моделювання вбудовані в IDE (залежить від версії продукту, зрозуміло в Architect версії все є). При включенні підтримки моделювання для проекту (Project-Modeling Support) до структури проекту додається директорія для моделі. Стає активна вкладка Model View, де відображається структура та ієрарахія модулів/класів проекту, а також Diagram View, де наведені створені для проекту діаграми. За допомогою двох цих вікон можнавиконати досить велику кількість дій: створення та видалення діаграм, створення, видалення або перейменування елментів діаграм (вузлів та зв'язків), додавання/видалення членів для елементів діаграм; створення діаграм з різних патерн проектування (синглтони, фабрики тощо), експортувати діаграми у зображення, генерувати документацію до коду. На мене так останні два пункти дуже важливі.
Крім цих вікон, розширюється функціональність інспектора об'єктів (Object Inspector), де можна змінювати властивості діаграм. У режимі редагування діаграми на панелі інструментів (Tool Palette) з'являються іконки, специфічні для цього виду діаграм. Меню проекту поповнюється різними специфічними командами.
Загалом, інструменти моделювання дозволяють вам будувати різні види UML діаграм поза залежністю від мови Delphi або С++. Діаграми синхронізовані з кодом в обидві сторони, тому зміни діаграми впливатимуть на код, а зміни коду відбиваються на діаграмах. Відповідно до діаграм може бути згенерований вихідний код для класів, при цьому ви можете використовувати різні патерни проектування. При активації моделювання стає доступним використання аудитів і метрик. Моделі можуть бути імпортовані з форматів IBM Rational Rose та XMI (тобто ви можете імпортувати модель проекту, розроблену в іншому пакеті проектування, та побудувати по ній вихідний код вашого проекту). За допомогою моделювання доступна функція автогенерації документації до вихідного коду у форматі HTML. Можна супроводжувати діаграми нотатками та зображеннями, всяко їх розфарбовувати, та використовувати OCL обмеження [не знаю поки що це :)]
UML має версії, інструменти моделювання Delphi дозволяють використовувати UML 1.5 і UML 2.0. Номерверсії, що використовується, залежить від типу проекту. У контексті моделювання існує два типи проектів: проект з реалізацією вихідного коду та проект архітектури. Перший випадок це звичний проект з вихідним кодом, в якому включена підтримка моделювання. Другий тип проекту (design project) призначений для побудови архітектури/дизайну системи або її компонентів. Для створення такого проекту необхідно вибрати пункт File - New - Other - Design Projects. Для проектів з реалізацією доступно використання UML 1.5, а для проектів дизайну можливий вибір між UML 1.5 і UML 2.0. Залежно від вибраної версії UML може змінюватись кількість підтримуваних типів діаграм та елементів діаграм.
У моделюванні використовуються терміни пакет (package) та простір імен (namespace). Загалом кажучи, ці терміни – синоніми. Однак термін "пакет" відноситься саме до проектування, а "простір імен" до реалізації у вигляді вихідного коду. Під час увімкнення підтримки моделювання створюється пакет з іменем default. За наявності інших пакетів їх можна відобразити на спеціальній диграмі пакетів, яка відображає самі пакети та елементи, які вони здригають. Кожен клас може міститися лише в одному пакеті та мати унікальне ім'я в ньому. Однак, різні пакети можуть містити класи з ідентичними іменами.
Діаграми є граф вузлів і зв'язків між ними. Кожна діаграма має тип. Відповідно для кожної диграми вузли та зв'язки мають своє значення/сенс. Наприклад, діаграма класів містить класи пакета, і зв'язок між ними, зв'язку у разі можуть визначати спадкування. Діаграми та їх елементи мають властивості. Крім стандартних властивостей існує можливість створення властивостей користувача. Для цього необхідно для діаграми або її елемента вв контекстному меню вибрати пункт User Properties. Властивості є парою "ім'я=значення", і при додаванні відображаються в інспекторі об'єктів.
Для проектів з реалізацією важливе місце в інструментарії моделювання займає синхронізація моделі та вихідного коду. З одного боку існує можливість побудувати діаграми для існуючого коду, з іншого боку ви можете побудувати загальну диграму класів, а потім згенерувати вихідний код для неї. Всі зміни, що вносяться або у вихідний код, або в діаграму відразу ж відображаються "з іншого боку". Тут є одне "але": для перейменування класів потрібно використовувати відповідні інструменти рефакторингу, а не просто перейменовувати його вручну у вихідному коді.
Діаграми класів
Діаграми класів це один із видів UML діаграм, що описують структуру вашого проекту з погляду просторів імен, класів та інтерфейсів, їх атрибутів, властивостей та методів. Також діаграма представляє відносини між цими елементами. Усі зміни на диграмі класів відразу ж відображаються у вихідному коді.
Узагальнення (generalization) - один з тремінів UML, що використовується для позначення спадкування класів. При побудові моделі за вихідним кодом такі зв'язки створюються автоматично. На діаграмі зв'язок успадкування відображається суцільною лінією зі стрілкою (без заливання, порожнім) від нащадка до батька. Відносини "Реалізація інтерфейсу " (теж термін UML) на діаграмі відображаються аналогічно, але лінія не суцільна, а пунктирна. Якщо як спадкоємця у нас може виступати тільки один клас (бо множинного успадкування у нас немає), то стрілка успадкування у класу може бути тільки одна. А ось зв'язків реалізації інтерфейсу, звичайно, може бути кілька. І всі вони на діаграмівідображаються.Асоціація - це вид зв'язку між двома класами, коли перший клас містить посилання на інший (атріубт або властивість). На діаграмі члени структурних типів даних розбиваються 4 групи: класи (вкладені типи), методи, властивості, поля.
Нижче наведено діаграму класів, яку я створив у порожньому консольному проекті для демонстрації.
Як видно праворуч відкрита вкладка ModelView, що представляє дерево структури. Проект називається uml і спочатку був порожній (тобто 1 dpr файл). Після включення підтримки моделювання перейшов на вкладку Model View. Виділивши верхній вузол uml та використовуючи контекстне меню я додав пакет uTest. На рівні вихідного коду це означає додавання uTest.pas до проекту. Панель інструментів містить специфічні діаграми елементів. Використовуючи діаграму я створив 2 інтерфейси ITest і ITest2, батьківський клас TCustomTest, що підтримує обидва ці інтерфейси. Вказати підтримку інтерфейсу можна або за допомогою Інспектора об'єктів, заповнивши полеinherites або мишею на самій діаграмі. Батьківський клас для TCustomTest був автоматично встановлений в TInterfacedObject. Далі я додав дочірній клас TTest, у результаті на діаграмі відобразився відповідний зв'язок. Після цього я ввів клас TItem і структуру TTestStruct, а класі TTest створив відповідні поля. На діаграмі відобразились зв'язки асоціації. TMyAttribute це rtti-атрибут, спадкоємець класу TCustomAttribute. Клас TTest був позначений цим атрибутом, але на діаграмі класів відображення це не знайшло (Delphi 2010, треба перевірити в ХЕ2), ймовірно, таких зв'язків немає в самому UML 1.5.
Дуже зручною є ще одна функція. Елемент на диграмі та відповідний клас можуть мати різні назви. Вірніше сказати, якщо ім'я класу унас поставлено, наприклад, TItem, то на діаграмі ми можемо відобразити його інакше, наприклад, "Елемент", для цього необхідно заповнити властивість Alias. Таким чином, поле Name в інспекторі об'єктів при виборі класу означає фактичне ім'я класу, а значення поля Alias відображається на діаграмі. Це дає нам можливість підписувати сутності на диграмі, використовуючи свою рідну мову, що спрощує роботу над проектом усім учасникам процесу.