UML моделирование в Delphi. Часть 1

Наверное, многие видели в самом Delphi и в справочной системе раздел UML Modeling, но не все это самое моделирование используют в работе. Я как раз и отношусь к числу таких разработчиков. Чтобы сей пробел восполнить, я решил прочитать указанный раздел справки и изложить усвоенные материал здесь. В общем говоря, первоисточником статьи является справочная система Delphi, а ниже приведены частичные выдержки из справки в моем вольном переводе с комментариями. К слову сказать, если сравнить объем справки по данному разделу в D2010 и для XE2, то различается он в разы.

Эффективное 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.

Что мне не совсем понравилось при начальной работе с элементами диаграммы, дак это инспектор объектов. В инспекторе объектов доступна одна вкладка "Свойства" (название иногда на русском, иногда на английском:) ). Обычно в инспекторе объектов у меня включен вид "по-алфавиту", хотя если память не изменяет, с Delphi 2009 доступен вид "по категориям". Выделяя какой-либо метод класса, например, TTest.DoCheck в инспекторе объектов появляются его свойства. К алфавитной сортировке претензий нет, однако переключаясь на категорию "по категориям" я ожидал увидеть разграничение на свойства относящие к модели и к свойствам самого метода (абстрактный, виртульный, final, параметры и т.д), но такого разделения нет. Вернее он есть, но не очень хорошо сделано. При выделении класса целиком, такое разделение намного лучше. Среди свойства метода также отсутствует выбор модели соглашения о вызовах. Думаю эти недочеты отсутствуют в версии XE2.

 Очень удобной является еще одна функция. Элемент на диграмме и соответствующий класс могут иметь различные названия. Вернее сказать, если имя класса у нас задано, например, TItem, то на диаграмме мы можем отоброзить его иначе, например "Элемент", для этого необходимо заполнить свойство Alias. Таким образом поле Name в инспекторе объектов при выборе класса означает фактическое имя класса, а значение поля Alias отображается на диаграмме. Это дает  нам возможность подписывать сущности на диграмме используя свой родной язык, что упрощает работу над проектом всем участникам процесса.

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