Глава 1. Введение
Модельно-ориентированный подход к разработке программного обеспечения (MDA) - это новая методика разработки программ, развиваемая консорциумом OMG начиная с 2000-го года. Этот подход имеет ряд преимуществ по сравнению с используемыми на данный момент. В его основу положен процесс создания пары программных моделей разрабатываемой системы, одна из которых представляет структуру и поведение системы с точки зрения пользователя, а другая - детали реализации этой системы с использованием какого-либо вида программного обеспечения промежуточного уровня [1]. Далее в работе подход MDA, его особенности и преимущества будут рассмотрены подробнее.
Но при всех достоинствах такого подхода необходимость создания двух моделей вместо одной при разработке программной системы, основанной на MDA, может существенно замедлить процесс разработки программного обеспечения. Этот недостаток уменьшает эффективность и область применимости подхода MDA. Однако разработчиками подхода было замечено, что после создания одной из пары моделей, используемых в MDA, можно существенно автоматизировать процесс получения другой модели. Для этого необходимо задать набор преобразований, который позволяет из исходной модели, отражающей одно представление системы, получить модель, соответствующую другому представлению. Каждое представление при этом отражает набор понятий и элементов, характерных для определённой технологической платформы или программного обеспечения промежуточного уровня. Если преобразование моделей задано на некотором формальном языке, и существует алгоритм автоматического выполнения таких преобразований, оно будет называться описанием трансформации моделей (model transformation). Язык описания трансформации, алгоритм автоматического выполнения трансформаций и программный инструмент, их выполняющий, будем называть средством трансформации моделей.
Целью данной работы является разработка средства описания трансформации программных моделей, пригодного для автоматизации преобразования моделей в технологии MDA.
Для достижения этой цели требуется решить следующие задачи: - анализ критериев оценки эффективности средств трансформации моделей с точки зрения их использования в MDA;
5
- разработка языка трансформации моделей, соответствующего сформулированным критериям;
- создание инструмента трансформации, позволяющего автоматически выполнять трансформации, заданные с помощью разработанного языка.
Актуальность работы заключается в том, что без использования автоматического преобразования моделей подход MDA не может реализовать весь свой потенциал. В то же время существующие средства и языки общего назначения, с помощью которых можно было бы описать преобразования моделей, оказываются недостаточно эффективными в контексте применения в MDA, что обуславливает необходимость создания нового специализированного средства трансформации с учётом потребностей этой технологии.
1.1 Обзор содержания работы
Во введении проводится обзор модельно-ориентированного подхода к разработке программных систем (MDA), рассматриваются его особенности и преимущества по сравнению с традиционными подходами. Описываются основные этапы разработки программной системы по методике MDA и основные понятия этой методики. В частности, вводятся понятия платформо-независимой и платформо-зависимой моделей, описываются различия между ними и преимущества, получаемые от описания программной системы с помощью двух моделей разного уровня абстракции.
Далее описывается роль трансформации моделей в технологии MDA и ставится задача автоматизации перехода от платформо-независимой к платформо-зависимой модели. Вводятся понятия трансформации как перехода от одной модели к другой по заданному описанию, языка описания трансформации и инструмента, автоматически выполняющего трансформацию моделей, заданную с помощью формального языка. Производится постановка задачи автоматизированной трансформации моделей, рассматриваются характеристики, которыми должен обладать язык трансформации для его успешного использования в задачах преобразования моделей, характерных для технологии MDA.
Во второй главе данной работы рассматриваются основные стандарты, имеющие отношение к трансформации моделей. Также исследуется возможность применения для описания трансформации моделей ряда существующих языков и методов из других областей программирования. Анализируются недостатки каждого из этих методов применительно к задаче трансформации моделей в контексте MDA. Делается вывод о том, что необходимо создание нового языка, специализированного для описания
6
трансформаций UML-моделей, оперирующего в терминах данной предметной области и учитывающего специфику применения.
Далее во второй главе проводится обзор работ в области трансформации моделей. Особое внимание уделено работам, в которых разработчики подхода MDA сформулировали требования, которым, по их мнению, должно удовлетворять средство трансформации моделей для его эффективного использования в MDA. Помимо этого, рассматривается ряд работ, предлагающих общие подходы к трансформации моделей.
В третьей главе работы описывается предложенный автором язык трансформации моделей. На основе рассмотренных ранее работ делается вывод о том, что язык должен быть основан на концепции правил трансформации. Правило трансформации - это конструкция языка, задающая соответствие между фрагментом исходной модели и желаемым результатом преобразования этого фрагмента. Описание трансформации, задаваемое с помощью набора таких правил, по структуре наиболее близко к описаниям преобразований моделей на естественном языке и потому удобнее в использовании и легче для понимания по сравнению с другими методами (такими, как императивное описание трансформации в виде последовательности действий).
При описании правила трансформации предлагается задавать область применимости правила в виде шаблона, представляющего собой набор элементов метамодели и условий, которые должны быть выполнены, чтобы правило считалось применимым. В работе предлагаются синтаксические конструкции языка, основанные на синтаксисе языка объектных ограничений ОСЬ, которые позволяют задавать подобные шаблоны.
Каждому используемому в шаблоне элементу метамодели ставится в соответствие уникальное имя переменной, что позволяет легко задавать условия, уточняющие шаблон, а также использовать эти переменные для описания результата применения правила. Результат применения правила к фрагменту модели, подходящему под шаблон, предлагается описывать императивно, в виде набора операторов изменения модели, применяемых к объявленным в шаблоне переменным.
Описание трансформации на предложенном языке представляет собой набор правил трансформации, сгруппированных в блоки трансформации. В работе предложен простой алгоритм, позволяющий автоматически выполнять заданные таким образом описания. Процесс трансформации заключается в поиске применимого правила и фрагмента модели, подходящего под шаблон, и модификации выбранного фрагмента
7
модели в соответствии с заданным в правиле набором операций. После этого поиск применимого к изменённой модели правила начинается заново.
Предложенный язык трансформации решает задачу преобразования одной модели, однако в работе описано расширение этого языка, позволяющее задавать трансформации нескольких моделей и генерацию новой модели по исходной.
В работе предложен оригинальный механизм трансформационных связей — структур данных, сохраняющих информацию о применении правил. Это позволяет не только отслеживать соответствие между исходными и порождёнными элементами модели после трансформации, что является одним из требований технологии MDA, но и использовать результат применения одних правил в других правилах, тем самым создавая зависимости между правилами и иерархии правил. Эти структуры объединяются в специальную модель связей, имеющую структуру, аналогичную структуре трансформируемых моделей. Благодаря такому сходству структур оказывается возможным использовать общие принципы и конструкции языка для работы с обычными моделями и моделью связей, что упрощает синтаксис языка и облегчает его понимание.
Далее в работе проводится исследование класса преобразований моделей, который можно описать с помощью предложенного языка. Доказывается, что можно формально описать любые преобразования, заданные с помощью однозначного отображения конечных множеств моделей. Также доказывается, что можно описать любые преобразования, заданные в виде формальных алгоритмов (для формализации понятия алгоритма используется концепция машины Тьюринга).
В четвертой главе работы на примерах показана возможность и удобство использования разработанного языка для описания трансформаций. В качестве примеров выбраны типичные задачи перехода от платформо-независимой к платформо-зависимой модели, решение которых используется в технологии MDA. Также демонстрируется возможность использования разработанного языка для контроля правильности трансформаций и обнаружения ошибок.
Кроме того, в четвертой главе работы рассмотрена структура прототипа инструмента трансформации, созданного в рамках данной работы и предназначенного для автоматического выполнения заданных на предложенном языке трансформаций моделей. Обсуждаются основные компоненты этого инструмента, принципы и особенности их функционирования, а также практические задачи, возникшие в процессе реализации инструмента, и способы их решения.
8
В заключении диссертации подводятся итоги работы и анализируются полученные результаты. Рассматриваются перспективы дальнейшего развития разработанного средства трансформации моделей. Ставится ряд задач, связанных с проведённой работой в области трансформации моделей и требующих дальнейшего изучения.
1.2 Основы модельно-ориентированного подхода к разработке программного обеспечения
1.2.1 Проблемы и задачи, которые решает MDA
На данный момент разработаны и активно используются множество стандартов, технологий промежуточного уровня и платформ (CORBA, DCOM, Dot-Net, WebServices, JA VA-технологии и т.д.), призванных упростить и повысить эффективность разработки программного обеспечения. У каждой из этих технологий имеются свои преимущества, область применения, в которой она наиболее эффективна, и множество использующих эту технологии специалистов и фирм. Причём процесс устаревания и прекращения использования технологий идёт очень медленно, так что в будущем число реально применяемых технологий будет расти. Попытки создать универсальную платформу, которая бы заменила все существующие, приводят только к увеличению количества используемых технологий — «универсальные» платформы просто становятся одними из многих используемых. Всё более важными становятся проблемы выбора технологии для конкретного проекта, осуществления взаимодействия и интеграции разнородных систем и переноса систем на новую технологическую платформу, когда используемая платформа устаревает и уже не может удовлетворить потребности заказчика. Решение этих проблем может основываться на использовании новой, более совершенной методики разработки программного обеспечения.
Новая концепция, предложенная консорциумом OMG - модельно-ориентированный подход к разработке программного обеспечения (Model Driven Architecture, MDA) [2] - позволяет существенно упростить и частично автоматизировать разработку, интеграцию и модернизацию систем. MDA отделяет спецификацию фундаментальной логики приложения от спецификаций различного программного обеспечения промежуточного уровня, используемого при реализации приложения. Это позволяет быстро и эффективно создавать системы, которые используют новые технологии, но основаны на ранее разработанных и проверенных бизнес моделях. Использование MDA для разработки и интеграции программного обеспечения позволяет
9
сохранить инвестиции в разработку бизнес логики даже при смене технологических платформ (программного обеспечения промежуточного уровня, middleware).
MDA предоставляет архитектуру, которая соответствует современным требованиям и предоставляет ряд преимуществ:
- Портируемость, нарастающее повторное использование программного обеспечения, уменьшение стоимости и сложности разработки и управления приложением сейчас и в будущем.
- Строгие методы для обеспечения гарантии того, что системы, базирующиеся на различных технологиях реализации, соответствуют общей бизнес-логике и требованиям.
- Независимость от платформы, значительное сокращение времени, стоимости и сложности, связанной с переработкой приложений для различных платформ и сменой платформ.
- Специализация для предметной области через специфические для области модели, которые позволяют быстро реализовывать новые приложения, используя стандартные для данной области средства и компоненты.
- Производительность за счёт предоставления разработчикам, дизайнерам и системным администраторам возможности использовать удобные им языки, понятия и концепции; при этом обеспечивается бесшовное связывание и интегрирование фрагментов, разрабатываемых разными командами и на разных технологиях.
1.2.2 Процесс разработки программного обеспечения по методике MDA
При разработке программного обеспечения по технологии MDA используется набор стадий, сходный с другими распространёнными подходами к разработке, такими как, например, методика Rational Unified Process (RUP). В этом смысле MDA является эволюционным развитием существующих методик. Новизна подхода заключается в результатах стадий анализа и проектирования, а именно в представлении системы с помощью двух моделей, создающихся на разных стадиях.
10
Стадии разработки
Постановка задачи"
Анализ
Проектирование
Кодирование
Тестирование
Внедрение
Результаты стадий
Неформальное описание
Платформо-независимая модель (PIM)
Платформо-зависимая модель (PSM)
Код программы
Программное обеспечение
Рис. 1. Стадии разработки программного обеспечения по технологии MDA
В основе MDA лежат понятия платформо-независимой и платформо-зависимой моделей (platform-independent и platform-specific models, PIM и PSM) [3]. В процессе разработки системы сначала создаётся Р1М - программная модель, содержащая бизнес-логику системы без конкретных деталей её реализации, относящихся к какой либо технологической платформе. Принципиальным является именно тот факт, что на этапе создания этой модели не принимается никаких решений по поводу её реализации, разрабатываемый программный продукт не привязывается к технологиям. На этом этапе в модель закладывается бизнес-логика, сценарии использования, функциональные требования и другая информация о взаимодействии системы с пользователем и о желаемом поведении системы. При использовании MDA рекомендуется доводить платформо-независимую модель по достаточно высокой степени детализации, вплоть до использования высокоуровневого платформо-независимого языка программирования для описания функциональности и создания исполняемой модели. Однако следует отличать детали функциональности, описывающие поведение системы с точки зрения пользователя, от деталей её практической реализации: последние не должны присутствовать в платформо-независимой модели.
Заметим, что даже если PIM доводится до стадии детальной исполняемой модели, её вряд ли можно использовать на практике как финальный программный продукт. Такая модель может быть крайне неэффективной при выполнении, не удовлетворять некоторым функциональным требованиям, не полностью реализовывать функциональность системы и даже требовать участия человека в процессе исполнения. Только после привязывания к конкретной платформе можно получить программный код промышленного качества. Но хотя исполнение PIM-модели и не применимо для решения практических задач, оно
11
необычайно важно для тестирования и отладки. Фактически, появляется возможность получить первый прототип системы ещё до начала стадии кодирования, когда сравнительно легко вносить даже существенные изменения в систему, в том числе производить изменения требований и технического задания.
Итак, результатом первого этапа разработки по технологии MDA является платформо-независимая модель, заданная с помощью некоторого формального языка моделирования. Завершённая платформо-независимая модель содержит полное описание системы, но свободна от деталей, относящихся к реализации и используемым технологиям.
После того, как Р1М в достаточной степени детализирована, выполняется переход к платформо-зависимой модели. Эта модель описывает уже не только функциональность системы, но и её реализацию с использованием конкретной (выбранной для данного проекта) технологической платформы. Происходит дальнейшая детализация модели и добавление элементов и конструкций, специфичных для выбранной технологии реализации. После того, как модель достаточно разработана, выполняется генерация кода по модели, затем производится доработка этого кода и его компиляция, так же, как и в традиционных методиках разработки программного обеспечения.
Разумеется, реально процесс разработки не столь линеен. Для сложного проекта практически невозможно сразу создать платформо-независимую модель, которая бы не потребовала изменений на более поздних стадиях. В процессе разработки платформо-зависимой модели и даже при написании кода может возникнуть необходимость в изменении любой из моделей. Это вполне допускается технологическим процессом MDA, однако необходимо следить, чтобы сохранялось соответствие между моделями: изменения в одной должны быть отображены на другие. Таким образом, при использовании технологии MDA одновременно разрабатываются и изменяются сразу три модели (Р1М, PSM и код), представляющие разрабатываемую систему с разных точек зрения и с различными уровнями детализации.
В принципе, идея, положенная в основу MDA, не зависит от инструментов и языка моделирования. Но поскольку эта технология создана консорциумом OMG, который занимается, помимо прочего, развитием языка моделирования UML (Unified Modeling Language) [4,5], предполагается, что именно этот язык будет использоваться для описания моделей при разработке программного обеспечения по технологии MDA. Язык UML в настоящее время очень популярен и повсеместно используется для моделирования программных систем, так что ориентация методики MDA именно на этот язык вполне
12
оправдана. В последних версиях стандарта UML появились дополнения, которые делают этот язык более удобным для такого использования: язык действий (action semantics) [6] позволяет описывать функциональность системы на платформо-независимом уровне, а профили (UML Profiles) [7,8] облегчают создание платформо-зависимой модели для наиболее популярных технологических платформ.
1.2.3 Преимущества использования методики MDA
Разделение платформо-зависимой и платформо-независимой моделей обеспечивает ряд преимуществ по сравнению с традиционным подходом к разработке программного обеспечения [9,10]. Облегчается перенос системы на другую платформу и модернизация систем. При смене платформы или переносе системы на новую технологию уже нет необходимости разрабатывать систему заново. Можно взять существующую платформо-независимую модель системы, и, основываясь на ней, построить новую платформо-зависимую модель. Таким образом, обеспечивается эффективное повторное использование моделей. Аналогично, упрощается создание много платформенных систем: достаточно создать одну общую PIM и построить по ней 'несколько PSM для каждой платформы. При этом уменьшается риск того, что основанные на разных платформах версии разрабатываемой системы будут несовместимы друг с другом или будут иметь разную функциональность, так как эта общая часть их поведения описана в общей для всех версий модели.
Кроме того, уменьшается риск ошибки проектирования: на относительно простой и полностью основанной на требованиях заказчика Р1М (в отличие от традиционной модели, загромождённой деталями реализации) легко находить и исправлять подобные ошибки. Благодаря разделению двух моделей может быть также упрощено создание документации, интеграция систем, создание гетерогенных систем и многое другое.
1.2.4 Роль автоматизированной трансформации моделей в MDA
При всех достоинствах у такого подхода к разработке имеется и очевидный недостаток. При использовании MDA нужно создать две модели системы вместо одной, что ведёт к замедлению процесса разработки. Однако оказывается, что этот недостаток можно превратить в достоинство, и использование MDA позволяет ускорить разработку, а не замедляет её. Это достигается за счёт автоматизированной генерации платформо-зависимой модели по платформо-независимой. Процесс перехода к платформо-зависимой модели, основанной на конкретной технологической платформе, в значительной степени формализован [11]. Профили UML, существующие для большинства распространённых
13
технологий, содержат рекомендации по отображению различных конструкций UML в специфичные для выбранной технологии формы — но это рекомендации для разработчика, а не инструкции для автоматического исполнения. Если удастся задать подобное отображение так, чтобы оно выполнялось автоматически, то уже не потребуется создавать платформо-зависимую модель вручную. Тогда процесс разработки существенно ускорится даже по сравнению с традиционным подходом, так как значительное количество элементов, специфичных для выбранной разработчиком технологии реализации, будет вноситься в модель автоматически [12]. Кроме того, сократится количество ошибок, неизбежно возникающих при ручном моделировании. Описание перехода к платформо-зависимой модели может быть произведено и тщательно отлажено всего один раз для каждой технологии и потом может использоваться во всех проектах, использующих данную технологию.
Итак, при использовании автоматизированного перехода к платформо-зависимой модели весь цикл разработки ПО с использованием подхода MDA будет выглядеть следующим образом:
- Постановка задачи, создание сценариев использования и списка формальных требований.
- Создание платформо-независимой модели.
- Автоматизированная трансформация PIM в платформо-зависимую модель с использованием ранее разработанного или стандартного описания трансформации для выбранной технологической платформы.
- Модификация и доработка как платформо-зависимой, так и платформо-независимой моделей, добавление необходимых деталей. При этом должно поддерживаться соответствие между моделями, то есть они должны отображать одну и ту же систему.
- Автоматизированная генерация кода по детальной платформо-зависимой модели.
- Ручная доработка кода, компиляция.
Переход от PSM к коду достаточно хорошо разработан; до появления MDA это называлось «генерацией кода по UML-модели» и в большей или меньшей степени поддерживается многими средствами для работы с UML для всех популярных платформ, языков и технологий. Автоматизированный переход к PSM — это новая и недостаточно разработанная идея. Поскольку и PIM, и PSM — это модели, представленные на языке UML, переход между ними, по сути, является трансформацией UML-модели по заданному описанию трансформации (содержащему формальным образом заданное описание
14
перехода от UML-модели общего вида к конкретной технологии). Именно разработке средства для задания и выполнения подобных трансформаций и посвящена данная работа.
Вообще говоря, в MDA автоматизированная трансформация моделей может использоваться для решения трёх задач. Во-первых, это автоматизация перехода от платформо-независимой модели к платформо-зависимой, что и было описано выше. Во-вторых, автоматизированная трансформация моделей может быть использована для целей обратной инженерии, то есть получения платформо-независимой модели высокого уровня абстракции по существующей платформо-зависимой модели. Эта задача может быть полезна для того, чтобы переносить в рамки подхода MDA существующие системы, созданные без использования этой методики. И в третьих, автоматизированная трансформация может применяться для перехода от PSM, основанной на одной технологии, к другой PSM. Такое применение было бы полезно даже за пределами методики MDA, но на практике построение подобных прямых соответствий между низкоуровневыми платформо-зависимыми моделями возможно, только если используемые в них технологии имеют очень похожие структуры и наборы понятий.
Но все эти задачи сводятся к одной - по одной модели на UML и формально заданному описанию преобразования построить другую модель UML. То есть, решив задачу трансформации моделей, мы сможем использовать это решение для всех перечисленных выше прикладных задач. А без поддержки автоматизированной трансформации моделей использование подхода MDA хоть и возможно, но никогда не будет эффективным.
1.3 Задача автоматизированной трансформации моделей 1.3.1 Описание трансформации и инструмент трансформации
Цель данной работы - разработка способа для задания и автоматизированного выполнения трансформаций UML-моделей. Под трансформацией моделей будем понимать преобразование существующих моделей (или генерацию новых моделей по существующим) в соответствии с некоторым формализованным описанием трансформации. Чтобы задавать подобные описания трансформаций, необходимо разработать алгоритмический язык описания трансформаций. Наконец, чтобы выполнять трансформации, потребуется инструмент трансформации [11].
15
Описание трансформации
Исходная
модель
Преобразованная
модель
Инструмент трансформации
Рис. 2. Трансформация моделей
Инструмент трансформации -- это программное средство, предназначенное для выполнения автоматических преобразований моделей программного обеспечения в соответствии с заданным описанием такого преобразования. Этот инструмент может быть самостоятельным программным продуктом или компонентом комплексной среды разработки. В цикле разработке, основанном на MDA, он предназначается для частичной автоматизации генерации платформо-зависимой модели на основе платформо-независимой модели и информации о выбранной технологической платформе. В общем случае входными данными для инструмента трансформации являются:
- одна или несколько исходных моделей;
- метамодель для каждой модели, принимающей участие в трансформации. Метамодель - это формализованное описание структуры модели; подробнее о метамоделях говорится в главе 2 в обзоре стандарта MOF;
- описание трансформации на языке описания трансформаций. Описание трансформации зависит от используемых метамоделей, но, по возможности, универсально относительно исходных моделей. То есть одно и то же описание трансформации применимо для трансформации множества моделей, имеющих заданный набор метамоделей.
Результатом работы инструмента являются:
- набор исходных моделей с изменениями, внесёнными в процессе трансформации;
- новые сгенерированные модели, созданные в процессе трансформации; наличие и количество таких моделей зависит от используемого описания трансформации; каждая сгенерированная модель соответствует одной из метамоделей, заданных в качестве исходных данных;
- информация о связях и отображениях между элементами модели, образованных в процессе трансформации; такая информация необходима для того, чтобы можно было понять, на основании каких исходных данных был получен тот или иной элемент исходной модели, что позволит поддерживать соответствие между
16
исходными и генерируемыми моделями при их модификации уже после завершения трансформации.
Вообще говоря, имеются три разных подхода к задаче автоматизированного преобразования моделей и к описанию таких трансформаций.
- Задача генерации моделей предполагает, что в процессе трансформации создаются новые модели, а исходные модели не изменяются и используются только как источник информации для трансформации. То есть в этом случае описание трансформации не преобразует модели, а формирует новые модели на основе существующих.
- Задача трансформации моделей предполагает, что во время трансформации не создаётся новых моделей, а только изменяются существующие. То есть вся совокупность принимающих участие в трансформации моделей должна предоставляться инструменту трансформации в виде исходных моделей.
- При решении смешанной задачи описание трансформации может включать как изменение исходных моделей, так и генерацию новых моделей.
Все эти задачи предполагают немного разные подходы к построению описаний трансформаций, но легко сводятся друг к другу. То есть, научившись решать одну из этих задач, можно использовать это же решение для другой. В дальнейшем при рассмотрении языка описания трансформаций нами будет описан подобный переход от задачи трансформации к задаче генерации моделей.
1.3.2 Требования к средству трансформации для его использования в MDA
В принципе, описания трансформации можно было бы задавать с помощью любого из существующих алгоритмических языков. Но применение задачи трансформации в методике MDA имеет свои особенности и накладывает на язык описания трансформации ряд ограничений и требований [13,14]. Именно поэтому задачу трансформации моделей следует рассматривать не в общем случае, а именно в контексте её применения в MDA, что позволяет оценить эффективность того или иного подхода к решению задачи для данной области применения. Попробуем сформулировать ряд требований, которым должен удовлетворять язык описания трансформации с точки зрения его использования в MDA. По степени соответствия этим требованиям можно будет оценить эффективность того или иного подхода к трансформации моделей, и именно они учитывались при разработке предложенного в данной работе языка описания трансформаций [15].
17
- Формальность. Язык описания трансформаций должен иметь строгую синтаксическую структуру, допускающую анализ средствами формальных грамматик.
- Возможность автоматического выполнения. Язык должен иметь заданную императивную семантику, то есть чёткий алгоритм автоматического выполнения описаний трансформаций, заданных на этом языке.
- Полнота. Язык описания трансформаций должен предоставлять возможность задания любой однозначной трансформации моделей с разными метамоделями. При этом недостаточно, чтобы существовала возможность задавать трансформации в платформо-зависимые модели для всех существующих платформ. Использование технологии MDA предполагает облегчение портирования системы даже на те платформы, которые не существовали на момент её создания, то есть при разработке языка трансформаций следует учитывать, что в будущем появятся новые технологические платформы и понадобятся новые описания трансформаций для этих платформ.
- Универсальность описаний трансформации. MDA имеет преимущество по сравнению со стандартными подходами к разработке программного обеспечения за счёт того, что для перехода к PSM можно использовать стандартные описания трансформаций. Если бы для каждой системы трансформацию приходилось описывать заново, это оказалось бы даже менее эффективно, чем переход от PIM к PSM вручную. Поэтому необходимо, чтобы язык описания трансформации позволял задавать трансформации, применимые для множества проектов, а не только для одной конкретной UML-модели. Желательно, чтобы в языке были предусмотрены средства для настройки и параметризации трансформации, не требующей кардинальной переделки всего описания трансформации.
- Наличие средств поддержки согласованности трансформируемых моделей. Во время разработки ни одна модель не остаётся неизменной. Это значит, что уже после трансформации как исходные модели, так и модели, созданные в процессе трансформации, могут быть изменены. При этом должен иметься способ поддерживать согласованность между этими моделями, достигнутую в процессе трансформации. Для этого необходимо сохранять информацию о ходе трансформации и о получившихся в процессе трансформации зависимостях между элементами модели (то есть информацию о том, когда и на основании каких исходных данных во время трансформации был создан или изменён тот или иной элемент модели). Инструмент трансформации должен сохранять такую |
