UML или DSL: какой медведь лучше?

Лен Фенстер (Len Fenster), корпорация Microsoft

Брук Гамильтон (Brooke Hamilton), корпорация Microsoft

Март 2010 г.

Краткое содержание.В этой статье рассказывается о том, в каких случаях следует использовать UML, а в каких – DSL, и как обеспечить их эффективную интеграцию друг с другом.

Введение

С выходом Microsoft Visual Studio 2010 Ultimate впервые архитекторы ПО получили набор инструментов моделирования UML и DSL в одной среде разработки. Хотя концепции моделирования UML и DSL витали в воздухе на протяжении длительного времени, эта среда разработки стала первым инструментом, в котором они эффективно объединены в один продукт, обеспечивающий широкие возможности для интеграции различных моделей.

Однако вскоре после анонсирования новых возможностей UML возникла дискуссия по поводу того, какой инструмент моделирования лучше. Однако эта дискуссия была, возможно, настолько же бессмысленной, как и юмористическая сцена из американского телесериала «Офис»:

«Джим Халперт: Вопрос. Какой медведь лучше?

Дуайт Шрут: Это нелепый вопрос.

ДХ: Неверно. Черный медведь.

ДШ: Ну, это спорно. Вообще-то существует две теории...

ДХ: Факт. Медведи едят свеклу. Медведи. Свекла. Звездный крейсер «Галактика»…

ДШ: Медведи не... Что происходит?! Что ты делаешь?!»

Спор о том, какой «медведь лучше», лишен смысла. В статье авторы также показывают, что ни UML, ни DSL не «лучше». Также как белый медведь и черный медведь лучше подходят для определенной среды, так и UML и DSL обладают своими уникальными функциями для определенной предметной области.

В этой статье авторы не пытаются доказать, какой из инструментов «лучше» другого, вместо этого они описывают сценарии, в которых лучше использовать UML или DSL, а также указывают эффективные способы интеграции этих двух инструментов между собой.

Где используется UML в продуктах Microsoft?

Почти все архитекторы и разработчики программного обеспечения знают хотя бы немного об унифицированном языке моделирования (Unified Modeling Language, UML). Разработанный Рамбо, Бучем и Якобсоном как способ ускорения процесса внедрения объектно-ориентированных технологий, UML 1.1 был предложен и принят консорциумом OMG в 1997 году. С того времени до текущей версии 2.2 UML был подвергнут ряду изменений. Однако на протяжении последних 12–13 лет разработчики и архитекторы, работающие с набором инструментов Microsoft, должны были обращаться к Microsoft Visio или программному обеспечению стороннего производителя, пожиная плоды обещанной унифицированности UML. Недостатки инструментария UML и поддержки в основной среде разработки Microsoft, Visual Studio, стали тем пробелом, который многие архитекторы и разработчики давно хотели бы заполнить.

Вместо этого корпорация Microsoft предоставила многофункциональную среду разработки для графических доменных языков программирования, добавив инструменты доменного языка программирования (Domain-Specific Language, DSL) в Visual Studio 2005. В выпуске Visual Studio 2010 Ultimate, в числе прочего, добавлена возможность взаимодействия DSL-диаграмм между собой и с UML-диаграммами. Также добавлены совместимые с UML 2.x (или «логические») диаграммы классов, компонентов, деятельности, последовательностей и сценариев выполнения.

Внимательные читатели, наверное, уже заметили, что это неполный список диаграмм UML 2.x. UML 2.2 определяет 14 типов диаграмм, 7 из которых являются структурными диаграммами (например, диаграммы классов и компонентов), а 7 – диаграммами поведения (например, диаграмма деятельности, последовательностей и сценариев выполнения). Однако поддерживаемые диаграммы покрывают только наиболее часто используемые функции UML, а лежащая в основе платформа моделирования позволяет динамически добавлять другие диаграммы в более поздние версии, пакеты обновления или инструменты.

Какую технологию моделирования следует использовать?

Используя Visual Studio с поддержкой инструментов DSL, архитекторы ПО создавали настраиваемые визуальные конструкторы специально для определенных доменов, а также разрабатывали код и другие артефакты на их основе. Однако если настраиваемые конструкторы были необходимы для моделирования определенного домена, выбор до настоящего момента был небогат: единственной помощью были инструменты DSL. Даже если нужна была всего лишь диаграмма состояния с генератором кода, необходимо было создать настраиваемый DSL. Некоторые пользователи заново изобретали похожие на UML конструкторы, используя инструменты DSL.

Теперь же появились диаграммы UML и возможность не только расширять поверхность проектирования для них, но и генерировать артефакты на их основе. Следует ли полагать, что Microsoft больше не будет поощрять разработку настраиваемых DSL? Сместится ли фокус от разработки настраиваемых DSL в сторону расширения диаграмм UML, которые поддерживаются в Visual Studio? В конце концов главным преимуществом поддержки этих новых функций UML является появление новых возможностей; они позволяют создавать модели и артефакты, создание которых в прошлом было в лучшем случае нетривиальным процессом. Но с появлением новых возможностей появилась и проблема выбора. Когда нам следует расширять возможности конструкторов UML, а когда – создавать абсолютно новые DSL?

В таблице 1 описаны основные отличия двух подходов для архитекторов.

Таблица 1. Сравнение UML и DSL для моделирования приложений с точки зрения архитекторов

С другой стороны, DSL имеет некоторые преимущества по сравнению с UML. Например:

• В них не содержатся ненужные элементы того, что они моделируют. Если вы посмотрите на модель UML, то увидите множество диаграмм и множество элементов в каждой из них, которые не используются для определенной модели. DSL более сосредоточен на деталях соответствующего домена и использовании его терминологии.
• Долгосрочные затраты на использование DSL могут быть значительно ниже, чем для UML, так как DSL разрабатывают для определенного домена, в отличие от работ, которые необходимо выполнить пользователю для применения универсального UML для конкретной цели.

Сценарии

Как UML, так и DSL являются полезными технологиями моделирования. Однако следует понимать, для каких сценариев целесообразно применять ту или иную технологию.

Сценарий 1: использование UML для моделирования проблемного домена

С UML наиболее перспективным может стать моделирование проблемных доменов. Иными словами, эта технология великолепно подойдет для определения объектов, их отношений и взаимодействий. Эти модели не должны быть специфичными для определенной платформы, или же они могут содержать специфическую для платформы информацию, примененную через профили UML. Этот сценарий, без сомнений, не является чем-то новым для большинства архитекторов и разработчиков, так как они привыкли видеть (и игнорировать) модели UML, используемые для документации.

Новым аспектом UML для моделирования доменов является то, что теперь в Visual Studio 2010 модели UML связаны с кодом, который реализует эти модели. Рассмотрим отличие между моделью, которая приведена в документе, и моделью, которая существует вместе с кодом и определяет структуру – объекты и их отношения – этого кода. Следует признать, что предыдущие инструменты UML (например, конструкторы UML в Visio) позволяли создавать заглушки кода, но основным отличием является то, что теперь мы можем связывать модели непосредственно с кодом. Это приводит к тому, что изменения в моделях сразу отражаются и в коде. Таким образом, модели из неудобной концепции для документации превращаются в полезную абстракцию, которая может использоваться для продуктивных дискуссий между архитекторами и разработчиками, а UML становится инструментом опережающей разработки, а не только инструментом схематического описания.

Однако чтобы опережающая разработка функционировала с UML, необходимо расширить модель из чистой спецификации языка UML и сделать ее более конкретной для определенной реализации. У нас появляется выбор. Мы можем:

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

Проще всего сделать допущения в генераторе кода. В самых простых случаях все будет работать просто замечательно. Однако вся конструкция рассыплется, как только модели станут более сложными, так как может понадобиться указать определенные специфические для платформы атрибуты, которые отсутствуют в других случаях. Применение профиля – это простой и недорогой способ добавления специфической для платформы информации в модели UML.

На рисунке 1 проиллюстрирован этот способ: диаграмма класса UML с профилем C#. Следует уделить особое внимание тому, как стереотип C# расширяет UML с помощью свойств Is Partial (Разделяемый) и Package Visibility (Видимость пакета), что помогает в опережающей разработке.

Рисунок 1. Диаграмма классов UML с профилем C#

Последний подход — создание дополнительных моделей для конкретной платформы — целесообразен, когда необходимо, чтобы UML оставался исключительно платформо-независимым. Это неактуально для большинства программ для Windows, но часто необходимо для встроенных систем или программного обеспечения, которое должно работать в течение многих лет и на различных платформах.

Сценарий 2: использование DSL для моделирования изменчивости в хорошо известном проблемном домене

Мы ежедневно используем платформы, и часто код, который пишется для этих платформ, повторяется лишь с небольшими различиями. Наилучший вариант применения DSL: абстрагирование изменчивости в стереотипный код и предоставление этой изменчивости разработчику через простую конфигурацию в конструкторах. Хорошим примером такого типа DSL является платформа Microsoft Entity Framework. Вы можете либо писать код непосредственно на основе платформы, либо использовать конструктор DSL, встроенный в Visual Studio. Конструкторы связаны с генераторами кода, которые вставляют конфигурацию разработчика в стереотипный код для настройки API.

Сценарий 3: использование DSL для настройки домена, моделируемого на UML

Этот сценарий сложнее предыдущих двух, но он предполагает более эффективное совместное использование UML и DSL. Некоторые проблемные домены, моделируемые на UML, можно выполнить различными способами, используя дополнительный код во время выполнения. Например, можно использовать UML для описания домена или платформы для расчетов ставки страховой премии. Домену могут потребоваться данные конфигурации во время выполнения, или это может быть API, который используется различными страховыми программами для расчета ставки. Кроме того, вы можете предоставить набор инструментов в виде DSL, который упрощает настройку или программирование домена для расчетов страховых ставок. (Более подробный пример такого сценария приведен в конце этой статьи.)

Этот сценарий также можно рассматривать как комбинацию сценария 1 и сценария 2, так как реально создать платформу, смоделировав ее в UML, а затем создать DSL, чтобы повысить эффективность работы с этой платформой. (см. рисунок 2.)

Рисунок 2. UML и DSL в одной системе

Однако следует отметить, что обычно платформу и DSL создают одни люди, а используют DSL другие. Вспомним пример с расчетами страховых ставок. Вероятнее всего, одна группа будет отвечать за создание API для расчетов и DSL, а другая – использовать DSL для создания приложений для расчетов. Группа, применяющая DSL, не будет взаимодействовать с моделями UML, так как необходимые концепции доменов будут представлены в DSL.

Сценарий 4: использование UML в качестве DSL

UML иногда может использоваться в качестве DSL. Например, фабрика WebService Software Factory Modeling Edition (которую также называют фабрикой служб), созданная группой Patterns & Practices в корпорации Microsoft, предоставляет набор часто используемых DSL, известных многим разработчикам. Для тех, кто не знаком с ними, в фабрике служб предусмотрена среда моделирования, которая упрощает архитекторам задачу моделирования единообразных веб-служб вне зависимости от определенной реализации (например, ASMX и WCF). Кроме того, фабрика служб позволяет настраивать определенные аспекты реализации (например, позволяет создавать код, отличающийся для реализаций веб-служб ASMX и WCF).

На рисунке 3 показана модель DSL контракта службы в фабрике служб. Элементы DSL в фабрике служб описывают логические компоненты веб-службы и создают несколько экземпляров классов и интерфейсов, которые завершают реализацию желаемой технологии (WCF или ASMX).

Рисунок 3. Пример модели контракта службы из фабрики служб

Интересно, что эта модель очень похожа на диаграмму классов UML. Не случайно возникает вопрос: «Можно ли расширить новые возможности UML в Visual Studio 2010 настолько, чтобы они покрывали возможности этого DSL?» Ответ: «Да». На рисунке 4 показано, как мы расширили диаграмму классов UML с помощью настраиваемого профиля, чтобы обеспечить ту же функциональность, которая имеется в фабрике служб.

Рисунок 4. Расширенная диаграмма классов UML в виде модели контракта службы DSL

Итак, теперь мы знаем, что мы можем получить аналогичные DSL возможности, расширив модели UML в Visual Studio 2010. Но следует ли так делать? На этот вопрос ответить значительно сложнее. К сожалению, ответом на этот, как и на все сложные вопросы, будет: «Все зависит от обстоятельств».

Вспомним таблицу 1, где сказано, что обычно начальная реализация DSL требует больших затрат. Одним из преимуществ использования UML в качестве DSL является то, что моделирование с помощью UML можно использовать для создания прототипа DSL. Расширение моделей UML может стать менее затратной альтернативой для вас. Позже, когда станет понятно, какие элементы должны использоваться в DSL, можно создать DSL на основе знаний, полученных при использовании модели UML. Иначе говоря, универсальная модель UML, используемая с определенной целью, в дальнейшем может применяться как основа для создания DSL.

Если вы не хотите тратить много усилий для создания UML, который бы соответствовал вашим потребностям моделирования, вам, возможно, удастся обойтись даже без создания DSL. Но здесь действуйте осторожно. Мы все знаем, что то, что начинается с «маленькой утилиты», созданной для решения небольшой задачи, часто превращается в нечто значительно большее. Суть в том, что если вы видите, что затраты на расширение моделей UML для удовлетворения ваших потребностей превышают или равны затратам на создание тех же возможностей с помощью DSL, вам следует прибегнуть к DSL.

Хотя изначальные затраты на использование UML ниже, чем на создание DSL, следует обратить внимание еще на следующее:

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

Практический пример совместной работы DSL и UML

Недавно авторы этой статьи работали с программой ASPEN (Advanced Software Productivity Environments) в компании Raytheon (американская компания, крупный поставщик военного ведомства) над реализацией фабрики программного обеспечения для создания служб обмена сообщениями. Служба обмена сообщениями – это компонент, который получает внешние сообщения, преобразовывает их в сообщения внутреннего формата, а затем передает эти сообщения внутренним получателям. В контексте этой статьи мы слегка упростим пример, чтобы вы могли больше сосредоточиться на понимании того, как UML и DSL могут работать вместе, а не вникать в определенный проблемный домен.

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

Процесс разработки начался с анализа домена, для которого создаются службы, с помощью платформо-независимых моделей UML. Поведение модели было реализовано на языке действий. (Язык действий – это реализация стандартной семантики действий UML для определения поведения в моделях.) Платформо-зависимые модели использовались, чтобы сопоставить UML и концепции языка действий с целевым языком. Набор генераторов кода применялся для преобразования моделей как на язык C++, так и на Java. При необходимости будут добавлены другие требуемые платформы.

Для исполняемой службы обмена сообщениями необходимы сведения о конфигурации, чтобы указать, какие сообщения должны сопоставляться и какие транспортные протоколы должны использоваться. Информация по конфигурации предоставляется в формате XML. Чтобы упростить создание и обеспечить единообразие информации по конфигурации в формате XML, авторы фабрики создали различные DSL. Один DSL был создан для импортирования и создания сообщений; другой был написан для сопоставления сообщений, указания транспортных протоколов и информации о публикации/получении сообщений. Разработчики не взаимодействуют с моделями UML при использовании фабрики.

Совокупность следующих этапов отражает процесс создания фабрики:

1. Платформо-независимые модели созданы с помощью UML и семантики действий.
2. Платформо-зависимые модели и генераторы кода использовались для создания исполняемого кода на выбранных платформах.
3. Созданы DSL, что позволяет разработчикам описывать желаемую конфигурацию обработчика сообщений.

Что необходимо сделать с точки зрения разработчика, использующего фабрику для создания службы обмена сообщениями:

1. Создать новый экземпляр фабрики службы обмена сообщениями.
2. Использовать набор DSL для настройки сообщений, сопоставления сообщений и транспортных протоколов.
3. Выполнить сборку, которая активирует создание файлов конфигурации и упаковку исполняемой службы обмена сообщениями.

Вот что говорит Питер ДеРоса (Peter DeRosa), менеджер проекта ASPEN в компании Raytheon: «Работая с корпорацией Microsoft и группой Visual Studio, при разработке программы ASPEN мы оставили идеологические дискуссии по поводу моделирования и перешли к созданию конкретных технологических решений, в которых сочетаются преимущества обоих подходов для получения высококачественных решений и для значительного снижения затрат на протяжении всего жизненного цикла. Наряду с хорошо известными нам технологиями разработки программного обеспечения на основе UML, мы дополнительно используем DSL, чтобы получить те же результаты для доменов и областей, которые сложно представить с помощью UML».

Заключение

Хотя черный медведь – боле «универсальное» животное, которое может приспособиться к различным условиям обитания, в Арктике он будет себя чувствовать значительно хуже, чем белый медведь. Белый медведь приспособился к жизни в условиях Арктики. У каждого медведя есть собственные уникальные сильные стороны, необходимые для удовлетворения определенных потребностей. Такая же ситуация с DSL и UML. UML более универсален; его можно использовать для различных целей, от описания требований к системе до моделирования набора объектно-ориентированных доменов и классов. Преимуществом DSL является то, что он значительно более специфичен по сравнению с универсальным UML.

В этой статье мы попытались изложить факты, подтверждающие, что между UML и DSL сложно выбрать «лучший» в качестве средства моделирования, так как каждый из них имеет свои уникальные преимущества. Также показано, как Visual Studio 2010 Ultimate может помочь в объединении этих технологий моделирования для создания еще более мощной среды моделирования. Платформо-независимые модели UML, UML с платформо-зависимыми профилями, а также DSL могут обмениваться данными, создавая полную модель системы.

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

«Лучшего» нет. И если кто-то попытается спорить с вами на эту тему, вы можете просто ответить:

«Факт. Медведи едят свеклу. Медведи. Свекла. Звездный крейсер ”Галактика”».

Благодарности

Авторы статьи хотели бы поблагодарить Майка Греймера (Mike Cramer), Питера ДеРоса (Peter DeRosa), Терри Поттса (Terri Potts), Джеза Сэнтоса (Jezz Santos), Джона Слейби (John Slaby) и Кристофа Спренгера (Christof Sprenger) за помощь в составлении и внесении уточнений в эту статью.

Об авторах

Лен Фенстер (lfenster@microsoft.com) – ведущий архитектор проекта .NET Development по Восточному региону США подразделения Microsoft Consulting Service. На протяжении 13 лет работы в корпорации Microsoft Лен занимался оказанием помощи компаниям в разработке надежных приложений на основе технологий Microsoft. В последнее время Лен работал в группе Patterns & Practices корпорации Microsoft над библиотекой Microsoft Enterprise Library и в группе Visual Studio над разработкой решения по интеграции Microsoft Office Project Server и Team Foundation Server системы Visual Studio Team System. Еще до начала работы в корпорации Microsoft он руководил группой разработчиков и архитекторов, которая создавала распределенные приложения на основе технологий Microsoft. После появления платформы .NET Лен занял должность архитектора решений в подразделении Microsoft Consulting Services, где потребовался его значительный опыт, чтобы помочь компаниям включить .NET в их собственные технологические стратегии и циклы разработки решений.

Лен – автор нескольких технических статей, а также книги Effective Use of Enterprise Library: Building Blocks for Creating Enterprise Applications and Services («ЭффективноеиспользованиеMicrosoft Enterprise Library.Конструктивные элементы для создания корпоративных приложений и служб», издательство Addison-Wesley Professional, 2006 г.). Он часто выступает перед сотрудниками компаний и на форумах архитекторов, рассказывая о том, как создать архитектуру решения на основе технологии .NET и включить разработку этого решения в общий жизненный цикл разработки программного обеспечения.

Брук Гамильтон (brhamilt@microsoft.com) – старший консультант группы Civilian Federal Services Group в подразделении Microsoft Consulting Services. Он более 15 лет занимался проектированием и реализацией систем для различных отраслей, включая нефтяные, финансовые, некоммерческие, медицинские, страховые и правительственные организации. Брук специализируется на повышении уровня абстракции с помощью разработки на основе моделей и использования моделей для обеспечения соответствия бизнеса корпоративных заказчиков их программным решениям. Сейчас он работает над проектом, направленным на внедрение программных фабрик, и руководит процессом разработки для компании Raytheon.