Практические аспекты разработки на базе моделей

Использование моделей при проектировании сложных систем становится модным в традиционных инженерных дисциплинах.

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

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

Сегодня методы разработки на базе моделей (в тех областях, где их применение имеет смысл) обладают уже достаточной зрелостью. Основная характеристика этих методов — их фундаментальная опора на автоматизацию и те преимущества, которые она приносит. Но, как и во всех прочих новых технологиях, успех разработки на базе моделей (model-driven development, MDD) зависит в первую очередь от качества ее интеграции в существующую технологическую и социальную среду. Чтобы проиллюстрировать это, рассмотрим ряд практических аспектов, которые я выделил исходя из собственного опыта промышленной разработки программных систем на базе моделей.

Грандиозная задача

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

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

С момента появления языков третьего поколения в конце 50-х годов суть программных технологий едва ли сильно изменилась. Конечно, с тех пор мы смогли познакомиться с целым рядом новых парадигм — в частности, со структурным и объектно-ориентированным программированием — и на шлифовку деталей было потрачено немало труда и времени, однако параметры абстрактности языков программирования, доминирующих на рынке, остались практически на том же уровне. Операторы If и Loop в современных языках наподобие Java или C++ почти не отличаются от операторов If и Loop в раннем Фортране. Даже наиболее многообещающие механизмы (скажем, классы и наследование), обладающие потенциалом, который нужен для достижения более высокой степени абстрактности, остаются невостребованными. Объекты, к примеру, сводятся к конструкциям, для которых характерен относительно невысокий уровень абстракции, и которые ограничены единым адресным пространством — к стекам, структурам данных или графическим примитивам. Подобные конструкции соответствуют детализации и уровню абстракции языков, в которых они появились.

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

Многие эксперты уже утратили всякую надежду на то, что сколько-нибудь значительный прогресс может стать результатом фундаментальных достижений в области программных технологий. Их ожидания связаны, прежде всего, с совершенствованием самого процесса программирования. Это в какой-то степени объясняет нынешний всплеск интереса к новым методам, таким как Extreme Programming и Rational Unified Process [2].

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

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

Основные положения

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

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

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

Технологии автоматизации

Автоматизация — самое эффективное средство повышения производительности и устойчивости. Однако поначалу при моделировании программного обеспечения автоматизации отводилась вспомогательная роль механизма поддержки построения диаграмм и генерации скелетного кода. Зачастую этого было недостаточно для оказания серьезного влияния на производительность. К примеру, после завершения генерации кода модели складывались на полку, потому что, как и у всей прочей программной документации, для их поддержки требовались дефицитные и дорогостоящие ресурсы. Вот почему решения, созданные на базе так называемого циклического инжиниринга (round-trip engineering), предусматривающего автоматическое обратное преобразование кода в модель, гораздо более полезны. Правда, недостаток их заключается в том, что при подобном автоматическом преобразовании обычно не удается добиться такого уровня абстракции, на который способен человек. Поэтому в полном объеме преимущества MDD раскрываются только при использовании всего потенциала воздействия данного подхода на автоматизацию. Он включает:

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

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

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

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

Стандарты

Последнее десятилетие ознаменовалось появлением целого ряда отраслевых стандартов, которые были предложены ассоциацией Object Management Group и получили достаточно широкое распространение. OMG представляет собой консорциум разработчиков программного обеспечения и пользователей, представляющих различные коммерческие, государственные и академические организации. Недавняя инициатива OMG Model-Driven Architecture предусматривает разработку концептуальных основ для определения набора стандартов, поддерживающих MDD (www.omg.org/mda/index.htm). Ключевым компонентом MDA является стандарт Unified Modeling Language, а также ряд других технологий, связанных с моделированием. Кроме того, MDD будет опираться на различные формальные и фактические стандарты (например, стандарты Web-технологий XML, SOAP и т.д.).

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

Качество моделей

Модели и моделирование являлись существенным компонентом проектирования с античных времен. Римский инженер Витрувиус, живший в I веке до нашей эры, затрагивал вопросы эффективности моделей в самом старом из известных в мире руководств по проектированию [6]. Инженерные модели призваны уменьшить риск, помогая лучше понять сложные проблемы и продумать потенциальные пути их решения еще до того, как мы начнем предпринимать какие-то действия по окончательной реализации проекта, требующие больших затрат. Разработчики крупных программных проектов, выбирающие иные подходы, обычно не уверены в жизнеспособности создаваемой конструкции вплоть до стадии завершения реализации. Но, к сожалению, на этом этапе стоимость внесения изменений в базовую архитектуру оказывается гораздо выше.

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

Вторая ключевая характеристика — понятность. Здесь нельзя ограничиваться абстрагированием от каких-то деталей; мы должны отразить все остальное в форме, которая будет для нас интуитивно понятной (например, в виде особой нотации, условных обозначений и т.д.). Понятность непосредственно связана с выразительностью используемой формы моделирования (под выразительностью в данном случае понимается эффективность описания сложных идей при минимальном объеме пересылаемой информации). Хорошая модель позволяет уловить суть при минимальных затратах интеллектуальных усилий на понимание. Одна из причин недостаточной выразительности даже тех программ, которые написаны на языке, поддерживающем высокий уровень абстракции, заключается в том, что для их правильного понимания требуется проводить подробный разбор текста. Классические программные операторы обрушивают на их читателя массу синтаксических деталей, соответствующих замысловатым лексическим правилам. Объем информации, который необходимо вычленить и обработать для понимания даже линейных программ, огромен и требует серьезных интеллектуальных усилий.

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

Четвертое — предсказуемость. У вас должна быть возможность использования модели для точного прогнозирования важных, но не очевидных параметров системы либо путем проведения эксперимента (выполнения модели на компьютере), либо с помощью какого-то формального анализа. Понятно, что это во многом зависит от точности модели и формы моделирования. Например, математическая модель моста позволит спрогнозировать максимально разрешенную нагрузку гораздо точнее, чем даже самая лучшая, выполненная с тщательным соблюдением масштаба деревянная модель.

И наконец, модель должна быть недорогой — ее конструирование и анализ должны стоить гораздо дешевле реальной системы.

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

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

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

Прагматизм

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

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

Наблюдаемость на уровне модели

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

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

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

С наблюдаемостью на уровне модели связаны и две другие критически важные функции: наличие средств объединения моделей и определения различий между ними. Данные средства, как правило, представляют собой интегрированную часть системы управления конфигурацией, которая помогает нам следить за различными версиями одной и той же модели. Средства объединения моделей обеспечивают слияние двух или более перекрывающихся моделей. В отличие от объединения исходного кода, которое используется в традиционных текстовых языках программирования, слияния на уровне моделей добиться гораздо сложнее, поскольку это требует глубокого понимания сложной семантики языка моделирования. В результате мы должны получить хорошо сформированную модель. Более того, инструменты обязаны выдавать отчет о возникающих затруднениях в форме понятной разработчику модели. Средства выявления различий определяют разницу между двумя моделями (как правило, между двумя разными версиями одной и той же модели). Они также должны работать на семантически понятном уровне.

Исполняемость модели

Один из фундаментальных способов изучения путем проведения эксперимента заключается в прогоне модели (Дэвид Хэрел сравнивает модели, которые нельзя запустить на выполнение, с автомобилями без двигателей). Одно из важнейших преимуществ моделей, запускаемых на выполнение, состоит в том, что они позволяют нам получить представление о системе на ранних этапах проектирования. (Изучение нового языка программирования мы всегда начинаем с успешного запуска тривиальной программы «hello world». Несмотря на простоту выполняемых действий, полученный опыт способствует повышению уверенности в своих силах и формирует точку отсчета для проведения дальнейших исследований.) Интуитивный опыт, приобретенный в ходе подобного эксперимента, отражает различия между более формальными знаниями и пониманием.

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

Эффективность сгенерированного кода

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

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

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

Масштабируемость

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

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

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

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

Интеграция с унаследованными системами

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

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

И последнее. У участников проекта MDD должна быть возможность использовать преимущества библиотек унаследованного кода и другого унаследованного программного обеспечения. Очень часто в нем аккумулированы знания, которые собирались на протяжении многих лет, и представлена наиболее ценная интеллектуальная собственность организации. Это может быть выполнено либо при помощи настраиваемых генераторов кода, либо путем прямого обращения к соответствующим утилитам внутри модели. К примеру, модель, в которой технология Java применяется для определения деталей каких-то действий путем переноса диаграмм состояний, может просто обращаться к соответствующим функциям Java без какого-либо дополнительного преобразования и использования промежуточного интерфейса.

Заключение

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

Литература

1. R. Pool, Beyond Engineering: How Society Shapes Technology, Oxford Univ. Press, 1997.
2. P. Kruchten, The Rational Unified Process, Addison-Wesley, 1999.
3. Unified Modeling Language, ver. 1.4, Object Management Group, 2002.
4. Meta-Object Facility (MOF), ver. 1.4, Object Management Group, 2002; www.omg.org/cgi-bin/doc?formal/2002-04-03.
5. Common Warehouse Metamodel (CWM) Specification, ver. 1.1, Object Management Group, 2003; www.omg.org/cgi-bin/doc?formal/03-03-02.
6. Vitruvius, The Ten Books on Architecture, Dover Publications, 1960.
7. B. Selic, G. Gullekson, P.W. Ward, Real-Time Object-Oriented Modeling, John Wiley & Sons, 1994.

Bran Selic, The Pragmatics of Model-Driven Development. IEEE Software, September/October 2003. IEEE Computer Society, 2003, All rights reserved. Reprinted with permission.