Консорциум Object Management Group начал разрабатывать UML 2.0, чтобы преодолеть существенные недостатки ранних версий. Язык Unified Modeling Language 2.0 в некоторых отношениях превосходит предыдущие версии, но его громоздкость и сложность могут создать проблемы для пользователей, разработчиков инструментальных средств и рабочих групп OMG, развивающих этот стандарт.

Технологический прогресс в сферах обработки информации и создания программного обеспечения порождает попытки построения все более и более сложных программных систем. И они все больше выявляют неадекватность абстракций, предлагаемых современными языками программирования высокого уровня. Назрела необходимость в новых языках, методах и технологиях, способных повысить уровень абстракции, на котором задумываются, строятся и развиваются программные системы. Консорциум OMG ответил на эти запросы выпуском UML 2.0 [1] и концепцией архитектуры на базе моделей (Model Driven Architecture, MDA; www.omg.org/mda).

Среди проблем, которые пытались решить архитекторы стандарта UML 2.0, были очевидное разбухание ранних версий UML и недостатки определения семантики. В процессе создания стандарта возникло требование включить в него поддержку разработки на базе моделей (Model-Driven Development, MDD) и, в частности, подхода к такой разработке с позиций архитектуры MDA. Словом, от создателей UML 2.0 ждали языка моделирования, который окажется настоящей «серебряной пулей».

Те, кто незнаком с «кухней» стандартизации языка общественными усилиями, были поражены громоздкостью и сложностью UML 2.0. Кажется, конечный результат полностью противоречит благим намерениям, породившим радикальный пересмотр стандарта. Многочисленность концепций моделирования, плохо определенная семантика и облегченные механизмы расширения UML 2.0 затрудняют его изучение и применение в среде MDD.

С этими проблемами нужно бороться, но не стоит удивляться тому, что язык моделирования первого поколения далек от совершенства. Как отмечают некоторые их авторов UML 2.0, мы все еще находимся в младенческом возрасте разработки языков моделирования [2].

Сторонники UML 2.0 утверждают, что этот язык отражает передовой опыт и лучшие методы моделирования. На первый план выдвигаются следующие его достоинства:

  • расширение представления об UML как о семействе языков с помощью профилей и точек семантических вариаций; они помечают преднамеренно оставленные без семантики части UML, чтобы облегчить добавление семантики, определенной пользователем;
  • большая выразительность моделирования, в том числе улучшенное моделирование бизнес-процессов, поддержка моделирования классификаторов многократного использования и архитектур распределенных гетерогенных систем;
  • интеграция семантики действий (Action Semantics), которую разработчики могут использовать для определения семантики среды выполнения моделей и обеспечения семантической точности, необходимой для анализа моделей и их преобразования в конкретные реализации.

Чрезмерно усердная пропаганда UML и связанных с ним технологий MDD столь же вредна, как несправедливая критика. Такая пропаганда может подогреть ожидания пользователей до уровня, недостижимого в настоящее время. Продираясь сквозь шумиху, окружающую UML 2.0, постараемся прояснить, насколько хорошо он способен поддерживать MDD.

UML 2.0

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

  • инфраструктура (infrastructure) — определяет базовые классы, на которых основаны модельные конструкции UML;
  • суперструктура (superstructure) — определяет концепции построения моделей UML;
  • язык описания объектных ограничений (object constraint language) — определяет язык, описания запросов, инвариантов и операций в моделях UML;
  • обмен диаграммами (diagram interchange) — определяет расширение метамодели UML, которое поддерживает хранение и обмен информацией, относящейся к компоновке моделей.

Суперструктура UML 2.0 описывает «видимые извне» части стандарта, т. е. концепции, используемые для описания систем. Чтобы появилась возможность справиться со сложностью, концепции суперструктуры организованы в единицы языка. Каждая из них служит для моделирования системы с определенной точки зрения. Например, единица «Взаимодействия» (Interactions) применяется для моделирования взаимодействий между элементами поведения, а «Деятельности» (Activities) — для описания потоков работ в приложениях. Кроме того, некоторые более сложные единицы языка организованы в виде приращений, каждое последующее из которых уточняет предыдущее. Так, «Деятельности» состоят из приращений Fundamental Activities, Structured Activities и Complete Structured Activities. Разделение UML 2.0 на относительно независимые языковые единицы позволяет выбирать для изучения лишь необходимые его части.

Относительная новизна UML-моделирования может потребовать от пользователей глубокого понимания большей части (если не всего) языка для выбора модели, соответствующей конкретным условиям. Однако было бы ошибкой рассматривать стандарт как учебник по UML. Он определяет концепции языка независимо от методов и технологий, используемых в его реализации. Аудитория, на которую он рассчитан, — это разработчики инструментальных средств, методологи и авторы учебников по UML. Мы пока не встречали книг, полностью раскрывающих особенности UML 2.0, но надеемся, что они скоро появятся.

Представления UML 2.0

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

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

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

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

Разработчикам сложных систем не помешала бы возможность их моделирования в пользовательском представлении. Сейчас UML 2.0 не имеет механизмов создания моделей с использованием представлений, отличающихся от имеющихся в языке. В работе [3], посвященной аспектно-ориентированному моделированию (aspect-oriented modeling, AOM) на базе UML, предлагаются некоторые средства описания систем с точки зрения пользователя. Аспектная модель является срезом UML-модели системы, содержащим лишь ту информацию, которая относится к представлению потребителя.

Разработчики применяют методы AOM для создания модели проекта, состоящей из аспектных и базовой моделей. Аспектные модели в сочетании с базовой образуют интегрированное представление проекта. Моделирование AOM требует определенных инструментов для создания нескольких (возможно, пересекающихся) диаграмм определенного типа, например диаграмм классов, и для объединения однотипных диаграмм. Коммерческих версий этих инструментов пока не существует.

Адаптация UML 2.0

Признавая, что с некоторыми концепциями UML можно связать целый ряд полезных семантик, разработчики UML 2.0 вводят точки семантических вариаций. Например, с их помощью компенсируется неточность в определении понятия агрегации, характерная для предыдущих версий UML. В [4, 5], критикующих ранние версии концепции агрегации, указано множество семантик, которые в агрегированной (в частности, слабоагрегированной) структуре можно связать с отношениями между целым и частями. UML 2.0 справляется с проблемой путем отказа от ассоциации конкретной семантики со слабой агрегацией. В нем также не определено, как именно созданы части агрегата. Приведем несколько примеров точек семантических вариаций в UML 2.0:

  • семантика, связанная с приемом событий в конечных автоматах;
  • средства, с помощью которых система в ходе взаимодействия доставляет сообщения получателям;
  • определение точек, расширяющих вариант использования.

Точки семантических вариаций позволяют рас?смат?ривать UML как семейство языков. Ответственность за определение и обнародование соответствующей семантики, подключенной к точке вариации, UML 2.0 возлагает на пользователя. Язык не обеспечивает семантику по умолчанию или список возможных вариаций. Он формально не ограничивает семантики, которые допускается подключать к точкам вариаций. Это может привести к ошибкам. Например, пользователь назначает семантику, не согласованную с семантикой относящихся к делу концепций, либо не может «донести» конкретную семантику до пользователей модели или инструментальных средств ее анализа. Результат — неверное истолкование и неправильный анализ модели. Пользователи должны знать о доступных для подключения вариациях, чтобы соответствующим образом адаптировать семантику UML 2.0.

Точки семантических вариаций обеспечивают малый уровень адаптации, а профили — высокий уровень. Профиль UML описывает расширение элементов модели UML для использования в конкретном контексте моделирования. Например, с помощью профиля можно определить вариант UML, адаптированный для моделирования прикладных компонентов Enterprise JavaBeans.

В профиле элементы модели UML расширяются с помощью стереотипов, определяющих дополнительные свойства элемента. Свойства, которые определены расширением, введенным стереотипом, не должны противоречить свойствам, ассоциированным с элементом модели. С помощью профиля можно ввести новые ограничения и определить дополнительные атрибуты в классах, но нельзя ввести новые или удалить существующие классы элементов модели. По этой причине профили рассматриваются как облегченные механизмы расширения. В качестве примеров профилей можно назвать UML Profile for Schedulability, OMG Performance and Time и профиль SysML, предназначенный для моделирования систем (www.uml.org/#UMLProfiles).

К сожалению, механизм профилей UML 2.0 не обеспечивает средств точного определения семантики, связанной с расширениями. По этой причине разработчики не могут использовать профили в их нынешней форме для создания проблемно-ориентированных вариантов UML с поддержкой формальных манипуляций с моделью, необходимых в среде MDD. Если UML не содержит базовые элементы для моделирования проблемно-ориентированных концепций, разработчики могут применять механизмы расширения для изменения метамодели UML. Эти «тяжелые» механизмы задействуют метаобъектные средства MOF (Meta-Object Facility), чтобы определить метамодель для варианта UML.

Технологии разработки проблемно-ориентированных языков моделирования с помощью «тяжелых» расширений развивают несколько поставщиков инструментальных средств. Специалисты по языкам будут использовать эти технологии для разработки сред MDD, состоящих из проблемно-ориентированных языков моделирования и инструментов разработки приложений. Применение таких технологий перенесет бремя разработки языка на плечи пользователей.

Концепции моделирования структуры

Из всех концепций UML наиболее широко используются концепции моделирования классов. В некоторых проектах создаются только модели классов. В концепциях моделирования классов UML 2.0 появились некоторые небольшие, но заметные изменения. Одно из усовершенствований в диаграммах классов — введение нового маркера допустимости навигации для ассоциаций. Данная нотация позволяет разработчикам отличить случай, когда навигация явно запрещена, от случая, когда не принято решение о запрете или разрешении навигации. Знак X в конце ассоциации указывает, что навигация через этот конец ассоциации запрещена; отсутствие пометки (стрелки или знака X) указывает на то, что решение относительно навигации в концевой точке ассоциации пока не принято.

Для улучшения поддержки моделирования программной архитектуры и многократного использования классификаторов в нескольких средах в UML 2.0 введены понятия структурированного классификатора и порта. Структурированный классификатор имеет внутреннюю структуру, описываемую структурой его составных частей. Часть специфицирует коллекцию экземпляров. Например, внутренняя структура структурированного класса определяется конфигурацией объектов, а внутренняя структура структурированного классификатора — композитной структурной диаграммой.

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

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

Рис. 1. Пример структурированных классов UML 2.0, взятый из спецификации Суперструктуры UML 2.0. Структурированный класс Car («автомобиль») состоит из двух частей: W:Wheel («колесо») и e:Engine («двигатель»). Часть W состоит из двух «колес», а «двигатель» e является экземпляром структурированного класса Engine. Последний имеет порт p, реализующий интерфейс Powertrain («силовая передача»)

На рис. 1 показан пример структурированных классов. Так, класс Car («автомобиль») состоит из двух частей: W:Wheel («колесо») и e:Engine («двигатель»). Часть W состоит из двух «колес», а «двигатель» e является экземпляром структурированного класса Engine («мотор»). Эти части связывает соединитель axle («вал»). Класс Engine имеет порт с именем p, реализующий предоставляемый интерфейс Powertrain («силовая передача») и требующий операций, описанных в требуемом интерфейсе Power («мощность»).

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

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

Концепции моделирования поведения

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

Чтобы определить исполняемую модель UML, язык должен точно описывать действия. В UML 2.0 это достигается с помощью концепций, определенных в документе Action Semantics for the UML, который идентифицирует действия и описывает их эффекты. В нем, например, определены действия создания и удаления объектов и ссылок, а также действия для получения и установки значений атрибутов. Документ Action Semantics для UML 2.0 не определяет конкретный синтаксис действий. Исследователи и методологи предложили несколько внешних языков описания действий, в том числе язык семантики действий (Action Semantics Language, ASL, www.kc.com/download/index.php) и Java-подобный язык действий (Action Language, www.cs.colostate.edu/~trungdt/uml_testing/tool).

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

В UML 2.0 сильно изменились диаграммы последовательности и деятельности. Изменения диаграммы последовательности обусловлены богатым опытом, накопленным в ходе разработки языка диаграмм последовательности сообщений (Message Sequence Diagram, MSD). Диаграммы MSD использовались в течение многих десятилетий в индустрии телекоммуникаций. На современном этапе развития этот стандарт имеет формализованную и документированную семантику. Усовершенствования диаграммы последовательности позволяют:

  • именовать и ссылаться на именованные фрагменты взаимодействий;
  • разбивать линии жизни участников с внутренней структурой на отдельные взаимодействия внутренних частей в контексте диаграммы последовательности.

В UML 2.0 также введен новый тип диаграммы. Это обзорная диаграмма взаимодействия (Interaction Overview Diagram), которая показывает отношения потоков между фрагментами и диаграммами последовательности.

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

Рис. 2. Моделирование цикла с использованием нотации UML 2.0. Объект Engine («двигатель») посылает сообщения rotate («вращать») в коллекцию, состоящую из двух Wheel («колес»)

На рис. 2 представлен сценарий, в котором объект Engine («двигатель») посылает сообщения rotate («вращать») в коллекцию, состоящую из двух Wheel («колес»). В этом случае проблема далеко не очевидна, поскольку «колес» всего два. Если их в коллекции много или число «колес» может меняться, проблема проявляется более наглядно. Некоторые пользователи обходят ее с помощью неформально определенных динамических линий жизни, показанных на рис. 3. Здесь w[i] — это динамическая линия жизни, которая на первой итерации получает значение w1, а на второй — w2. Такая импровизированная нотация является более краткой и интуитивной, но зачастую ассоциированная с динамическими линиями жизни семантика определяется недостаточно точно.

Диаграммы последовательности определяют лишь взаимодействия между экземплярами. Чтобы описать, как участники взаимодействия отвечают на посланные им сообщения, разработчики могут использовать модели конечных автоматов и диаграммы деятельности. Конечные автоматы в UML 2.0 напоминают конечные автоматы в предыдущей версии и используются в качестве базиса для исполняемых вариантов UML [6]. Применение их для полного описания поведения реактивных систем является допустимым, но описание поведения информационных и других систем с использованием одних лишь состояний и переходов может привести к дополнительному усложнению модели.

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

Рис. 3. Моделирование цикла с использованием динамической линии жизни. Здесь w[i] — динамическая линия жизни, которая на первой итерации получает значение w1, а на второй — w2

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

Тестирование проектов UML

В MDD модели обеспечивают базис для понимания поведения системы и генерации реализаций. Анимация модели способствует лучшему пониманию смоделированного поведения, а тестирование помогает выявить ошибки перед реализацией. Визуализация поведения модели с помощью средств анимации окажется полезной как для новичков, так и для опытных разработчиков: первые смогут выявить неправильное использование модельных конструкций, а вторые — лучше разобраться в проектах, созданных другими разработчиками.

Чтобы ошибки не проникли в реализацию, модель нужно протестировать. Сейчас разработчики оценивают проектные модели UML с помощью пошагового просмотра, инспекции и других неформальных методов ревизии проекта, преимущественно ручных. Такая проверка больших проектов утомительна и не гарантирует отсутствия ошибок. Можно применить и формальные методы проверки, но лишь немногие из них способны справиться с моделями больших систем. Семантика времени выполнения, ассоциированная с моделями UML 2.0, прокладывает путь к разработке систематических методов тестирования моделей. Они обеспечивают выполнение модели с применением проверочных входных данных [7, 8].

Мы разработали опытный образец инструмента UML Animator and Tester UMLAnT (UMLAnT) [9], который использует информацию из диаграмм классов, последовательности и деятельности для анимации и тестирования проектных моделей UML. В процессе тестирования UMLAnT показывает диаграммы последовательности, перехватывающие сообщения, которыми обмениваются объекты. Он также отображает диаграммы объектов, которые описывают конфигурации, созданные в ходе выполнения тестов.

Разработчики могут использовать UMLAnT для генерации проверочных входных данных от моделей классов и моделей последовательности. Набор испытательных критериев определяет цели тестирования и используется инструментом для оценки адекватности входных проверочных наборов данных. Инструмент генерирует исполняемую форму проектной модели, исходя из диаграмм классов и диаграмм деятельности. Модель тестируется путем подачи проверочных данных в исполняемую форму.

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

Метамодель UML

Разработчики методов преобразования моделей и других механизмов MDD для манипуляций с моделями часто работают на уровне метамоделей. Например, они выражают трансформации моделей в виде соответствий между элементами метамодели. Более того, в технологиях MDD иногда расширяют метамодели и определяют новые конструкции языка ради удобства проблемно-ориентированного моделирования или моделирования семейства продуктов. Поэтому разработчики MDD-технологий на базе UML должны хорошо разбираться в метамодели UML. Однако сложность нынешней метамодели UML 2.0 может затруднить ее понимание, использование, расширение и развитие.

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

Рассмотрим задачу извлечения из метамодели UML 2.0 простого представления, которое фокусируется лишь на взаимосвязях концепций, используемых для создания базовых моделей последовательности. Изучение метамодели UML показывает, что требуемая информация равномерно рассеяна по ней. Языковая единица «взаимодействия» организована в виде множества взаимосвязанных пакетов. Например, пакет Basic Interaction непосредственно зависит от пакетов Basic Behaviors, Basic Actions и Internal Structures. А они зависят от других пакетов, описанных в других частях более чем 1000-страничной спецификации Суперструктуры. Прослеживание с помощью этих пакетов зависимостей с целью извлечения субструктуры метамодели, описывающей базовые модели последовательности, оказывается весьма утомительным делом.

В спецификации UML 2.0 не хватает удобного обзора моделей взаимодействия. Например, хотелось бы, чтобы отношения между концами стрелок-сообщений и линиями жизни можно было легко идентифицировать. Удивительно, но для получения этого простого отношения нужно пройти через несколько ассоциаций и иерархий наследования. На рис. 4 показан «мгновенный снимок» работы, необходимой для отыскания простой метамодели взаимодействий. Закрашенные прямоугольники обозначают интересующие нас концепции взаимодействия. Чтобы получить требуемые отношения, нужно пройти через другие концепции. В некоторых случаях для выявления производных отношений необходимо пройти через иерархии наследования, простирающиеся за пределы пакетов. Например, линия жизни наследует NamedElement, который определен в другом пакете, описанном в другой части Суперструктуры.

Использование метамодели UML

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

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

Подобные инструменты могут быть разработаны с использованием существующих технологий. Инструменты UML, имеющие базовые средства доступа к внутренним представлениям метамодели UML, могут быть дополнены возможностями извлечения представлений по запросу. Некоторые из таких возможностей имеют инструменты метамоделирования, разработанные компаниями Xactium (www.xactium.com), Adaptive Software (www.adaptive.com) и пропагандируемые Джином Безивином (www.sciences.uni v-nantes.fr/lina/atl/contrib/bezivin) [10]. Облегчить задачу использования метамодели UML мог бы еще один инструмент, который по модели UML строил бы представление метамодели, описывающее ее структуру. Разработчикам такой инструмент пригодится для проверки соответствия моделей, полученных в результате трансформаций. Например, они смогут удостовериться, что исходная, целевая и трансформированная модели соответствуют своим метамоделям.

Развитие комплексной метамодели UML 2.0 будет нелегким делом. Предполагается, что UML станет изменяться. Следовательно, пользователи стандарта столкнутся с проблемами оценки последствий предложенных изменений, последовательного проведения изменений во всей метамодели, а также проверки целостности и осмысленности измененной метамодели. Чтобы лучше управлять развитием метамодели UML, мы предлагаем с помощью методов AOM представить ее в виде аспектных моделей. Можно определить, например, следующие аспекты:

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

Каждая аспектная модель дает ясное представление о том, как решается та или иная проблема в метамодели UML. Аспектные модели должны быть собраны вместе, чтобы создать интегрированное представление метамодели. Аспектный подход к метамодели позволяет разработчику вносить изменения в один из аспектов или создать новый аспект, а затем объединить его с другими, чтобы определить влияние изменения на метамодель. Использование механизма композиции помогает и согласованно проводить изменения всей метамодели. Прототип механизма композиции для диаграмм классов UML, который может служить для этой цели, предложен в работе [11].

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

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

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

Громоздкость и сложность UML 2.0 создают проблемы не только для разработчиков инструментов MDD на базе UML, но и для рабочих групп OMG, ответственных за развитие стандарта. Будет чрезвычайно трудно развивать UML 2.0 с применением только ручных методов. Развитие стандарта может потребовать изменения концепций, рассеянных по всей метамодели, проверки согласованности изменений в рамках метамодели, оценки влияния изменений на другие элементы метамодели. Необходимо также убедиться, что изменения не приведут к появлению метамодели, определяющей противоречивые или бессмысленные конструкции языка. Для упрощения развития метамодель должна быть реструктурирована и снабжена инструментами навигации.

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

Литература
  1. The Object Management Group. Unified Modeling Language: Superstructure. Version 2.0, OMG document formal/05-07-04, 2004.
  2. B. Henderson-Sellers et al., UML — The Good, the Bad or the Ugly? Perspectives from a Panel of Experts. Software and System Modeling, Feb. 2005.
  3. R. France et al., An Aspect-Oriented Approach to Design Modeling. IEE Proc. Software, special issue on Early Aspects: Aspect-Oriented Requirements Eng. and Architecture Design, Aug. 2004.
  4. B. Henderson-Sellers, F. Barbier, Black and White Diamonds. Proc. UML99, LNCS 1723, Springer-Verlag, 1999.
  5. M. Saksena, R. France, M. Larrondo-Petrie, A Characterization of Aggregation. Int?l J. Computer Systems Science & Eng., 1999, vol. 14, no. 6.
  6. S. Mellor, M. Balcer, Executable UML: A Foundation for Model-Driven Architecture. Addison-Wesley, 2002.
  7. A. Andrews et al., Test Adequacy Criteria for UML Design Models. J. Software Testing, Verification and Reliability, 2003, vol. 13, no. 2.
  8. T. Dinh-Trong et al., A Tool-Supported Approach to Testing UML Design Models. Proc. 10th IEEE Int?l Conf. Eng. Complex Computer Systems (ICECC05), IEEE Press, 2005.
  9. T. Dinh-Trong et al., UMLAnT: An Eclipse Plugin for Animating and Testing UML Designs. Proc. Eclipse Technology eXchange Workshop. Conf. Object-Oriented Programming, Systems, Languages and Applications (OOPSLA), ACM Press, 2006.
  10. J. Bezivin, F. Jouault, P. Valduriez, On the Need for Megamodels. www.sciences.univ-nantes.fr/lina/atl/www/papers/ OOPS LA04/bezi vin-megamodel.pdf.
  11. Y. Reddy et al., Directives for Composing Aspect-Oriented Design Class Models. Trans. Aspect-Oriented Software Development, 2006.

Роберт Франс (france@cs.colostate.edu) — профессор Университета Колорадо. В область его научных интересов входят разработка на базе модели, аспектно-ориентированная разработка и формальные методы. Судипто Гош (ghosh@cs.colostate.edu) — доцент Университета Колорадо. Его научные интересы — испытания программного обеспечения, аспектно-ориентированная и компонентно-ориентированная разработка. Транг Дин-Тронг (trungdt@cs.colostate.edu) — докторант Университета Колорадо. В круг его научных интересов входят испытания и моделирование программного обеспечения. Эрнор Соулберг (arnor.solberg@sintef.no) — научный сотрудник Фонда научных и промышленных исследований при Норвежском технологическом институте. В сферу его научных интересов входят разработка на базе моделей и аспектно-ориентированная разработка.

Robert B. France, Sudipto Ghosh, Trung Dinh-Trong, Arnor Solberg. Model-Driven Development Using UML 2.0: Promises and Pitfalls, IEEE Computer, February 2006. IEEE Computer Society, 2006. All rights reserved. Reprinted with permission.