Подход к реализации среды разработки для dsl

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

Ausführliche Beschreibung

Gespeichert in:

Bibliographische Detailangaben
Datum:	2007
1. Verfasser:	Рябко, В.А.
Format:	Artikel
Sprache:	Russian
Veröffentlicht:	Інститут програмних систем НАН України 2007
Schlagworte:	Методи і засоби програмної інженерії
Online Zugang:	https://nasplib.isofts.kiev.ua/handle/123456789/270
Tags:	Tag hinzufügen Keine Tags, Fügen Sie den ersten Tag hinzu!
Назва журналу:	Digital Library of Periodicals of National Academy of Sciences of Ukraine
Zitieren:	Подход к реализации среды разработки для dsl / В.А. Рябко // Пробл. програмув. — 2007. — N 4. — С. 3-12. — Бібліогр.: 7 назв. — рос.

Institution

Digital Library of Periodicals of National Academy of Sciences of Ukraine

id	nasplib_isofts_kiev_ua-123456789-270
record_format	dspace
spelling	nasplib_isofts_kiev_ua-123456789-2702025-02-23T17:21:35Z Подход к реализации среды разработки для dsl Рябко, В.А. Методи і засоби програмної інженерії Рассмотрены вопросы, касающиеся методологии разработки DSL, предложены подходы к созданию среды разработки на основе DSL, ее архитектура и способы реализации. Исследованы ключевые особенности построения отдельных инструментов, а также подсуммированы основные достоинства и недостатки MDD подхода. 2007 Article Подход к реализации среды разработки для dsl / В.А. Рябко // Пробл. програмув. — 2007. — N 4. — С. 3-12. — Бібліогр.: 7 назв. — рос. 1727-4907 https://nasplib.isofts.kiev.ua/handle/123456789/270 681.3 ru application/pdf Інститут програмних систем НАН України
institution	Digital Library of Periodicals of National Academy of Sciences of Ukraine
collection	DSpace DC
language	Russian
topic	Методи і засоби програмної інженерії Методи і засоби програмної інженерії
spellingShingle	Методи і засоби програмної інженерії Методи і засоби програмної інженерії Рябко, В.А. Подход к реализации среды разработки для dsl
description	Рассмотрены вопросы, касающиеся методологии разработки DSL, предложены подходы к созданию среды разработки на основе DSL, ее архитектура и способы реализации. Исследованы ключевые особенности построения отдельных инструментов, а также подсуммированы основные достоинства и недостатки MDD подхода.
format	Article
author	Рябко, В.А.
author_facet	Рябко, В.А.
author_sort	Рябко, В.А.
title	Подход к реализации среды разработки для dsl
title_short	Подход к реализации среды разработки для dsl
title_full	Подход к реализации среды разработки для dsl
title_fullStr	Подход к реализации среды разработки для dsl
title_full_unstemmed	Подход к реализации среды разработки для dsl
title_sort	подход к реализации среды разработки для dsl
publisher	Інститут програмних систем НАН України
publishDate	2007
topic_facet	Методи і засоби програмної інженерії
url	https://nasplib.isofts.kiev.ua/handle/123456789/270
citation_txt	Подход к реализации среды разработки для dsl / В.А. Рябко // Пробл. програмув. — 2007. — N 4. — С. 3-12. — Бібліогр.: 7 назв. — рос.
work_keys_str_mv	AT râbkova podhodkrealizaciisredyrazrabotkidlâdsl
first_indexed	2025-11-24T03:16:03Z
last_indexed	2025-11-24T03:16:03Z
_version_	1849640000910524416
fulltext	Методи і засоби програмної інженерії © Д.М. Рябко, 2007 ISSN 1727-4907. Проблеми програмування. 2007. № 4 3 УДК 681.3 Д.М. Рябко ПОДХОД К РЕАЛИЗАЦИИ СРЕДЫ РАЗРАБОТКИ ДЛЯ DSL Рассмотрены вопросы, касающиеся методологии разработки DSL, предложены подходы к созданию среды разработки на основе DSL, ее архитектура и способы реализации. Исследованы ключевые осо- бенности построения отдельных инструментов, а также подсуммированы основные достоинства и не- достатки MDD подхода. Введение Изучив опыт разработки программного обеспечения (ПО) на протяжении послед- них десятилетий, можно сделать вывод, что в этой области прогресс двигается в направлении повышения уровня автома- тизации, что в свою очередь, предъявляет более строгие требования к качеству обслуживания. Это ведет к усложнению архитектуры. Мы можем наблюдать, как глобальные коммуникации, позволяя за- казчикам и партнерам более тесно участвовать в бизнес-процессах, требуют более частого обновления приложений и их версий. В индустрии разработки ПО имеется ряд проблем, которые определя- ются методами программирования и могут быть представлены таким образом: − сложность систем; − особенность предметной области; − формализация разработки; − накопленный опыт; − наглядность; − гибкость; − верифицируемость; − повторное использование. Эти проблемы являются симптомами других, более низкоуровневых проблем, отражающих недостатки в существующем способе построения ПО. Данные проблемы подробно рассмотрены и проанализиро- ваны в [1]. В данной работе рассматриваются достоинства и недостатки новой методоло- гии в программировании, известной как Model Driven Development (MDD, разра- ботка управляемая моделями). Цель этой методологии в создании ПО предметной области из моделей домена. Для описания моделей домена используется Domain Specific Language (DSL – язык описания специфики предметной области). В работе излагается методология MDD. Рассматриваются вопросы реализа- ции архитектуры среды разработки, спо- собы построения инструментов для удоб- ного использования языков типа DSL, ва- рианты редакторов, валидации моделей с помощью ограничений, преобразования моделей, генерации кода и интеграции его с исходным кодом. Особенности языков DSL в MDD Методология MDD включает: − модельно-управляемая архитектура (Model-Driven Architecture, MDA). Проектируемые системы представляются с использованием языка моделирования об- щего назначения Unified Modeling Langua- ge (UML) и его конкретных профилей. Эти модели преобразуются в артефакты, вы- полняемые на разнообразных платформах; − модельно-интегрированные вы- числения (Model-Integrated Computing, MIC). Для представления элементов сис- темы и их связей используются предметно- ориентированные языки моделирования DSML, а также их преобразования в плат- форменно-зависимые артефакты. В свою очередь MIC объединяет: − предметно-ориентированные языки моделирования DSML (Domain-Specific Modeling Language), в системах типов которых формализуется структура, пове- дения и требования приложения внутри соответствующей предметной области. В используемых метамоделях определяются связи между понятиями предметной об- ласти, точно специфицируется основная Методи і засоби програмної інженерії 4 семантика и ограничения, ассоциируемые с этими понятиями; − трансформационные процессоры и генераторы, которые анализируют опреде- ленные аспекты моделей и синтезируют исходный код, входные данные для имита- ционного моделирования, XML-описания развертывания или альтернативные пред- ставления моделей. Возможность синтеза на основе моделей помогает поддерживать согласованность между реализациями и аналитической информацией о зафиксиро- ванных в модели требованиях к функцио- нальным возможностям системы и ее качеству. Сами по себе модели бесполезны в конечном приложении. Модели должны быть преобразованы в исполнимый код для конкретной платформы. Такие преоб- разования осуществляются с помощью преобразования моделей. Модель преобра- зуется в другую модель с понижением аб- стракции, т.е. в модель более конкретную и менее абстрактную. Серия таких преоб- разований в конечном итоге приводит к исполнимому коду и последнее преобразо- вание будет являться преобразованием модель-код. Характеристика языка DSL Как и любой другой язык, DSL состоит из трех частей: − мета модель (также известна как абстрактный синтаксис) определяет строи- тельные составляющие языка и правила, по которым они должны собираться, чтобы образовывать правильные модели; − конкретный синтаксис служит для описания нотаций, используемых для описания моделей. Мета модель может иметь несколько конкретных синтаксисов. Которые могут быть текстовыми, где предложения записываются в виде специ- фикаций и графическим – в виде моделей; − семантический смысл моделей дол- жен быть хорошо определен. Использование языка DSL позволяет решить три основные проблемы, присущие языкам GPL (General Purpose Language, язык общего назначения), используемых в объектно-ориентированом программирова- нии (ООП): − большой временной разрыв, между реализацией идей и их воплощением; − понимание существующего кода; − расширение языка. Рассмотрим каждую из них. Проблема 1 заключается в том, что основная временная задержка между формулировкой задачи и ее воплощением находится между составлением модели программной системы и ее реализацией на GPL. Можно рассмотреть такой пример: программисты объясняют модель програм- мной системы друг другу в считанные часы, но на реализацию этой системы каждый из них потратит дни. Это про- исходит потому, что для описания модели программисты используют специальный язык, который содержит специфичные термины и формулировки. Для реализации модели на компьютере программисты ис- пользуют GPL, который содержат в себе несколько десятков понятий, используя которые можно описывать модель. Естест- венные языки содержат десятки тысяч по- нятий, с помощью которой модель можно кратко описать (рис. 1). Поэтому чтобы объяснить поставленную задачу компью- теру, необходимо ее представить более детально. Задача Решение ПО (ис- ходник) ПО (код) Создание концептуаль- ной модели Менталь ная работа программ истов Описание домена Т р а н с ф о р м а ц и и м о д е л и Компиляция GPL DSL Рис. 1. Сравнение разработки приложе- ния с использованием языка GPL и DSL Методи і засоби програмної інженерії 5 Большую часть времени программисты тратят на поиск способа выражения абстракций модели в языке GPL, используя объектно-ориентированный ди- зайн (OOD). Используя методологию MDD, OOD не применяется. Проблема 2 возникает, при попытке понять, что было сделано ранее для решения определенной задачи. Процесс понимания кода заключается в обратной трансформации абстракций GPL в абстрак- ции высокоуровневой модели, т.е. вос- становление информации, которая была потеряна в процессе кодирования. Традиционный способ решения данной проблемы это комментарии, документация, дизайн модели и т.д. Но это довольно посредственное решение поскольку оно имеет ряд слабых сторон, таких как дополнительные затраты на написание документации, необходимость постоянной синхронизации и обновления написанной документации и т.д. В идеале код сам по себе должен быть и документацией, которая позволяет понять данный код. Проблема 3 заключается в том, что библиотеки языка не выражаются в понятиях доменной модели, а выражаются в низкоуровневых понятиях GPL, таких как классы и методы. Чтобы использовать какие-то библиотеки программист должен изучить их, изучить способ преоб- разования модели его задачи в решение на уровне библиотеки. Относительно простые понятия доменной модели требуют усерд- ной предварительной работы, чтобы ин- терфейсы библиотеки были использованы правильно. Подсуммируем преимущества раз- работки с использованием DSL. − DSL позволяет выразить решение в терминах предметной области на соотве- тствующем уровне абстракции. Следо- вательно, специалисты в данной пред- метной области могут разбирать, ве- рифицировать, изменять и разрабатывать DSL-программы. Что позволит сместить акцент в программировании в сторону специалистов в конкретной области, т.е. не специалистов в программировании. Что позволит избежать потери информации или ее искажение при передачи от специа- листа доменной области программисту. − DSL-программы лаконичные, во многом самодокументирующиеся и могут повторно использоваться для различных целей. Использование в конструкциях языка понятий предметной области позво- лит в дальнейшем читать программу также легко, как-будто она была изложена на разговорном языке. − DSL повышает эффективность, на- дёжность, переносимость и качество со- провождения. Операции, осуществляемые на уровне моделей, гораздо эффективнее, намного легче и подвержены меньшему количеству ошибок, чем те же операции, осуществляемые на уровне исходного кода. − DSL содержит знания о предметной области, обеспечивая таким образом воз- можность их хранения и повторного ис- пользования. − DSL позволяет проводить вали- дацию и оптимизацию на уровне абстрак- ции, соответствующем предметной об- ласти. Валидация модели, используя пре- дикаты на каждом уровне абстракции, по- зволяет избежать изнурительного тестиро- вания на поздних этапах разработки. − DSL улучшает тестируемость ПО и позволяет автоматизировать этот процесс. Вместо разработки сценариев тести- рования и ручного набора данных, на- пример, мы можем сгенерировать и применить их на основе декларативной информации, зафиксированной в моделях. Можно также конфигурировать и контро- лировать тесты, а также наблюдать за их выполнением, используя модели. Произ- водя отладку на уровне моделей, пользова- тель может контролировать систему, при- меняя для этого выражения на языке моде- лирования. − Модели, описанные с помощью одного DSL, могут быть трансформиро- ваны в модели описанные с помощью другого DSL. Это позволяет свободно ин- тегрировать между собой различные части системы, написанные на разных DSL. − Предметная область может быть описана на одном уровне абстракции, а Методи і засоби програмної інженерії 6 затем преобразована с дополнительно де- тализацией на более низкие уровни абст- ракции, что позволяет дополнять модель на разных этапах разработки. − Возможность автоматизировать ре- структуризацию, сборку и развертывание. Реструктуризация может быть авто- матизирована, используя высокоточные доменно-специфичные модели, настроен- ные специально на язык программирова- ния. Модели могут содержать информа- цию о сборке, включая артефакты, участ- вующие в ней, а также их зависимости. Они также могут содержать информацию о развертывании, включая конфигурацию развертываемых исполняемых программ, объемы и конфигурации аппаратных и программных ресурсов, необходимых ис- полняемым программам. К недостаткам применения DSL можно отнести: − высокую стоимость проектирова- ния, реализации и сопровождения; − необходимость начального обу- чения пользователей; − отсутствие доступных реализаций различных вариантов DSL; − сложность определения области действия DSL; − необходимость сохранения равнове- сия между конструкциями, специфичными для предметной области, и конструкциями языков программирования общего назна- чения; − возможное снижение эффектив- ности по сравнению с программным обес- печением, написанном на языке програм- мирования общего назначения. Методология разработки DSL Разработка языка, зависящего от предметной области, как правило, вклю- чает следующие этапы жизненного цикла (рис. 2). Этап анализа: − определение предметной области; − сбор всех релевантных знаний предметной области; − построение системы знаний в виде нескольких семантических нотаций и операций над ними; − проектирование DSL, лаконично описывающего приложение в предметной области; − подготовка правил, для последо- вательных преобразований моделей; − определение предикатов, прове- ряющих семантику моделей. Рис. 2. Этапы методологии DSL Этап реализация: − изготовление индивидуального ре- дактора, реализующего семантику языка; − создание библиотеки, реализующей семантические верификации; − проектирование и реализация ге- нератора для выполнения последова- тельных трансформаций моделей, в ко- нечном итоге приводящей к последова- тельности библиотечных вызовов. Этап применения: − описание модели с помощью спро- ектированного DSL; − выполнение преобразований мо- делей и интеграция их на каждом этапе; − генерация кода и интеграция кода с рукописным кодом. Архитектура среды разработки MDD В результате анализа методологии MDD предложена модель архитектуры Методи і засоби програмної інженерії 7 среды разработки для описания мета моделей и моделей, составления конкрет- ных DSL, разработки графических и тек- стовых редакторов, модификации моделей и генерации кода (рис. 3). На рис. 3 ис- пользуются такие цифровые обозначе¬ния: 1) проверка семантики модели, ис- пользуя предикаты валидации, на соответ- ствие метамодели предметной области. Валидация может быть реализована в ре- альном времени, так как она реализована в средах разработки при проверке правиль- ности кода; 2) преобразование модель-модель по- зволяют свободно интегрировать между собой различные части системы, а также преобразовывать модель на разные уровни абстракции; 3) дополнение и завершение модели. Добавление новых артефактов в модель или завершение существующих; 4) загрузка и сохранение модели. Модель должна хранится в каком-то пред- ставлении в системе. Это может быть се- риализация во внутренний формат или поддержка международных стандартов хранения моделей, например xmi; 5) создание индивидуального гра- фического редактора модели на основе метамодели; 6) редактирование модели с помощью текстового редактора; 7) генерация кода на основе шабло- нов; 8) интеграция сгенерированного кода с рукописным кодом. Рассмотрим основные блоки архи- тектуры более детально. Мета модель может быть спроекти- рована в любом графическом (ER-диа- граммы) или текстовом (спецификации) редакторе. Используя редактор UML также можно определить мета модель. Далее мета модель может быть сохранена в стан- дартном формате XMI и загружена в лю- бой среде разработки для дальнейшей об- работки. Например, модель может быть описана с помощью инструментов UML, или если рассматривать open source IDE Eclipse, то с помощью Eclipse Modeling Framework (EMF). Индивидуальный графический ре- дактор – одна из самых сложных частей в архитектуре среды разработки MDD. Из наиболее известных редакторов можно выделить: − Eclipse GMF (Graphical Modeling Framework); − Microsoft DSL Tools; − Meta Programming System (MPS) от JetBrains; Рассмотрим создание редактора в каждой из сред разработки более детально. В GMF предполагается, что мета модель была описана или загружена с ис- Метамодель I Метамодель II Модель I Модель II instanceof instanceof 2 3 Сохраненная модель (.xmi) 4 1 Текстовый редактор Спецификация текстовото редактора Индивидуальный графический редактор Спецификация графического редактора 5 6 UML редактор Редактирование Редактирование Редактирование Сгенерированный код Исходный код 7 8 Рис. 3. Архитектура среды разработки MDD Методи і засоби програмної інженерії 8 пользованием EMF. Далее из этой метамо- дели генерируется набор артефактов. Во- первых, генерируется genmodel. Это в ос- новном модель-декоратор (или модель- маркер) вокруг метамодели, которая «де- корирует» набор дополнительных свойств. Далее определяются такие модели [5]: − определяющая графическое пред- ставление, включая формы, декорации, узлы и связи, она называется gmfgraph; − модель для палитры редактора и других инструментов, называется gmftool; − модель отображения для связи этих двух моделей с мета моделью. На рис. 4 показано как эти все модели связаны вместе. Для всех добавочных моделей GMF создает gmfgen модель – «низко-уровневую» модель, которую генератор кода использует как входную, окончательно производя diagram проект, который и будет содержать требуемый графический редактор. В DSL Tools инструменте ин- дивидуальный графический редактор входит в состав индивидуального дизай- нера, создаваемого под конкретную до- менную модель [7]. Дизайнер создания DSL требует выбора базового шаблона, состоящего из: − минимального языка – простой шаблон, создающий очень маленький базо- вый язык, включающий только два объ- ектных понятия и нотацию содержащую одно поле и одну линию; − диаграммы активности – шаблон демонстрирующий диаграмму активности UML; − диаграммы классов – шаблон де- монстрирующий диаграммы классов UML; − диаграммы вариантов использо- вания – шаблон демонстрирующий диаг- раммы вариантов использования UML. При построении нового дизайнера пользователь может контролировать вид будущего DSL. Формы, иконки и свойства компонентов могут быть настроены или добавлены новые. Все измененные ре- сурсы будут включены в дизайнер при компиляции (рис. 5). После создания до- менной модели и дизайнера могут быть добавлены шаблоны кода для усовершен- ствования и настройки DSL. Эти шаблоны будут использоваться для генерации кода из экземпляров модели, которые пользова- Метамодель .ecore EMF EMF Genmodel .genmodel Модель отображения .gmfmap Графическая нотация .gmfgraph Определение инструментов .gmftool GMF Gen Model GMF GMF .diagram ПРОЕКТ EMF GMF Рис. 4. Создание индивидуального графического редактора в GMF Методи і засоби програмної інженерії 9 тель создаст. После добавления всех ас- пектов дизайнер компилируется и может быть установлен на Visual Studio.NET 2005, где может быть использован для ге- нерации артефактов и шаблонов. Разработчики MPS не добавили в свою среду разработки возможность создания индивидуального графического редактора, вместо которого предложили другой вид редактора. Этот редактор языков использует свой собственный язык Editor Language. Поле редактора разделено на прямоугольные ячейки, которые могут содержать ключевые слова, скобки, разде- лители и т.д. Каждая ячейка может содер- жать в себе другие ячейки. Использование ячеек имеет ряд интересных преимуществ. Во-первых, это позволяет редактору ими- тировать текстовый редактор, работая на- прямую с графовой структурой про- граммы. Во-вторых, в ячейки можно вво- дить не только текст, но и графики, таб- лицы и т.д. К тому же ячеечная структура это не обязательный атрибут, программист может создать что-то свое. Таким образом Editor Language позволяет создать ячееч- ную структуру для каждого понятия в языке. Можно определить какие понятия постоянные, например, как скобки, а какие переменные и пользователь должен опре- делять их. Editor Language позволяет доба- вить такие возможности, как рефакторинг, автозаполнение, подсветка синтаксиса, подсветка ошибок и т.д. Ограничения – это правила, которым должна удовлетворять модель, чтобы быть правильной. Формально ограничения – часть метамодели. Ограничения это булевские выражения (предикаты), кото- рые истинны в случае, когда модель удов- летворяет метамодели. Проверка ограничений должна быть доступна как в процессе выполнения мо- дели, так и интерактивно, в процессе мо- делирования в редакторе. В основном для определения ограничений используют функциональные языки, например Object Constraint Language (OCL). Один из поддерживаемых языков в среде OMG/MOF/UML (рис. 6). Преобразования модели, преобра- зования модель-модель. Каждая модель представляется с помощью какого-то кон- кретного синтаксиса, например xmi для моделей основанных на MOF. Однако, оп- ределять преобразования в терминах кон- кретного синтаксиса очень сложная, запу- танная и не эффективная задача. Поэтому предлагается следующая схема (рис. 7): − преобразовать модель в объектную структуру; − преобразовать исходную модель в выходную (в объектной структуре); − преобразовать целевую модель в конкретный синтаксис. Генерация кода Логика и сообщения об ошибках для валидирующих ограничений Пользовательские меню и т .п. Усовершенствование дизайнера Обновление ресурсов Локализированые строки , иконки и т .п. Добавление кода Тело и сообщения об ошибках для валидирующих ограничений Пользовательские меню и т .п. Усовершенствование дизайнера Редактирование доменной модели Объектная модель доменных понятий Редактирование определений дизайнера Нотации Валидации Определение DSL Изменение и расширение дизайнера Рис. 5. Процесс создания нового дизайнера в MS DSL Tools Методи і засоби програмної інженерії 10 Этот подход к преобразованию гораздо эффективнее. В этом случае преоб- разователь становится намного гибче, по- скольку он может преобразовывать модели с любым конкретным синтаксисом. Это очень важно в случае конкретного синтак- сиса, основанного на XMI, поскольку де- тали XMI могут значительно отличаться между инструментами UML. И нет ника- кой необходимости привязывать преобра- зователь к конкретному синтаксису. Генерация кода используется для генерации исполняемого кода из моделей, на основе метамодели. Существует три подхода к генерации кода: − итеративный – где перечисляются все узлы исходной модели и используя язык преобразований генерируются узлы целевой модели; − использование шаблона или мак- росов. Шаблоны работают аналогично шаблонам Velocity или XSLT. Шаблон по- хож на целевой язык, но позволяет встав- лять макрос в любой части шаблона. Мак- росы это участки кода, которые будут вы- полняться, когда запуститься трансформа- ция. Шаблоны также могут быть полезны в других задачах, таких как рефакторинг, оптимизация и т.д; − использование шаблонов поиска, для поиска мест в исходной модели, где можно применить преобразование. В этом подходе можно представить шаблон как некое регулярное выражение для кон- цептуальной модели. По аналогии с пре- дыдущим подходом создается язык шаб- лона, основанный на исходном языке. Язык шаблона похож на исходный язык, но содержит гибкие критерии, позволяю- щие искать сложные совпадения в исход- ной модели. Можно представить этот под- ход как мощную технологию поиска и за- мены. Этот подход также может использо- ваться для проверки кода в редакторах. Рассматривая процесс генерации кода, должна быть обеспечена возможность настройки на целевую платформу. Различные преобразования могут быть выполнены в зависимости от платформы. Очень сложно включить все возможные варианты в один набор преобразований, которые бы обслуживали все возможные случаи. Для решения этой проблемы пред- лагается разделить генерацию на два этапа (рис. 8). Первый этап будет читать конфи- гурацию и создавать генератор для теку- щего преобразования. Второй – использо- вание созданного генератора для выполне- ния преобразований. Данный подход широко используется в поставках open source дистрибутивов, где первый вызов make install настраивает инсталлятор (makefile) и вторым шагом собирается и устанавливает приложение. Исходная модель (Конкретный синтаксис ) Парсер конкретного синтаксиса Дерево абстрактного синтаксиса исходной модели Пребразователь Целевая модель (Конкретный синтаксис ) Преобразователь в конкретный синтаксис Дерево абстрактного синтаксиса целевой модели Рис. 7. Преобразование модели Рис. 6. Определение ограничения с помощью OCL Методи і засоби програмної інженерії 11 Интеграция сгенерированного кода с рукописным. Если не все 100 % ис- полнимого кода генерируется из модели, то тогда незаполненные участки должны быть дописаны вручную. Однако, модифи- цирование сгенерированных файлов путем добавления рукописного кода создаст про- блемы с соответствием, управлением сборки, версиями и переписыванием руч- ного кода при регенерации из моделей. Если сгенерированный код никогда вруч- ную не модифицировался, то он может быть удален и перегенерирован заново. В случае, если этот код будет модифициро- ван, то в нем должны быть специальные защищенные области, чтобы генератор не мог удалить код при его регенерации. Для этого генератор должен перечитать ранее сгенерированный код, проанализировать его и сохранить защищенные области. Для решения вопросов использования сгене- рированного и исходного кода предла- гается: − хранить сгенерированный и ру- кописный код в отдельных файлах; − никогда не модифицировать сге- нерированный код; − разрабатывать дизайн и архитек- туру, которые четко определяют какие ар- тефакты сгенерированны, а которые нет; − использовать подходящие дизай- нерские решения склеивания сгене- рированых и рукописных частей; − интерфейсы также как и шаблоны проектирования такие как фабрика, стратегия, мост, шаблонный метод – хорошие исходные позиции [3]. Обобщая данный вопрос на тот случай, когда разные генераторы генерируют раз- личные части общей системы, можно рас- смотреть рукописный код как выход очень специфичного генератора – программиста. На следующей диаграмме показано как сгенерированный и исходный код могут быть скомбинированы, используя выше описанные шаблоны проектирования [2] (рис. 9). Рис. 9. Способы комбинирования сгенерированного и рукописного кода 1. Сгенерированный код может вы- зывать рукописный содержащийся в биб- лиотеках. Этот способ предлагает генери- ровать минимальное количество кода и ис- пользовать уже реализованные компо- ненты. 2. Рукописный framework может вы- зывать сгенерированные части. 3. Фабрики могут быть использованы, чтобы «подключить» сгенерированные блоки. 4. Рукописные классы могут содер- жать полезные общие методы, которые могут вызываться из внутренних сге- нерированных подклассов. Особенности платформы Модель Генератор Исполнимый код Настройка Рис. 8. Настройка на целевую платформу Методи і засоби програмної інженерії 12 5. Базовый класс может содержать абстрактный метод, который он вызывает, который может быть реализован в сгене- рированном подклассе. Выводы Данная работа – обзор подходов к организации архитектуры среды разработ- ки на основе парадигмы MDD. Рас- смотрены вопросы касающиеся особен- ностей реализации отдельных составляю- щих элементов этой среды разработки. Основа построения ее архитектуры – методология разработки DSL. Также про- анализированы преимущества и недо- статки парадигмы MDD. Автор соби- рается использовать данные разработки при проектировании и реализации инст- рументов для языков DSL. 1. Greenfield J., Short K., Cook S., Kent S. Software Factories: assembling applications with patterns, models, frameworks, and tools. Wiley Publishing Inc., September 2004. – P. 57 – 116. 2. Stahl T., Voelter M. Model-Driven Software Development, Wiley, 2006. – P. 184 – 185. 3. Gamma E., Helm R., Johnson R., Vlissdes J. Design Patterns, Addison-Wesley, 1995. – 416 p. 4. Rudorfer, Voelter. Domain-specific IDEs in embedded automotive software, http://www.voelter.de/data/presentations/Eclip seCon.pdf 5. GMF Tutorial Wiki, http://wiki.eclipse.org/index.php/Graphical_M odeling_Framework 6. Herrington J. Code Generation in Action. Manning, 2003. – 368 p. 7. Walkthrough. Domain-Specific Language (DSL) Tools, 2005. Получено 29.10.2007 Об авторе: Рябко Дмитрий Михайлович, аспирант Института программных систем НАН Украины. Место работы автора: Институт программных систем НАН Украины, 03680, Киев, проспект Академика Глушкова 40. Тел.: (097) 987 4829. e-mail: dmytro.ryabko@gmail.com

Подход к реализации среды разработки для dsl

Institution

Ähnliche Einträge