Диссертация (1148272), страница 18
Текст из файла (страница 18)
Что здесь понимается под«небольшими и средними проектами»: в [42] упоминаются языки, состоящиеболее чем из 500 сущностей, авторы сравнивают это с UML, где по их данным 286сущностей в метамодели. Сейчас самый большой язык, созданный с помощьюQReal, имеет 43 сущности в метамодели, разработка соответствующего DSMрешения велась в течение двух лет командой в среднем из 3-4 человек, этоDSM-решение описано в разделе A.1 данной работы. Будем называть средними проектами проекты примерно такого масштаба (не более 50 сущностейв метамодели). О применимости предложенных методик к более масштабнымпроектам нет сведений, экспериментальное подтверждение или опровержениеих применимости к таким проектам является интересной темой дальнейшихисследований.Большинство авторов обращают особое внимание на итеративность процессаразработки визуального языка.
Итерации необходимы, чтобы последовательно88уточнять понимание предметной области и получать обратную связь от пользователей тогда, когда вносить изменение в проект ещё не поздно. Кроме того,следуя [36], будем выделять отдельно первую итерацию — доказательство осуществимости (proof of concept). Она особенно важна, поскольку часто к самомуDSM-подходу, как и ко всему новому, относятся с некоторым подозрением.Доказательство осуществимости заключается в выделении какого-то небольшогофрагмента предметной области и быстрой реализации инструментария толькодля него — с языком, редактором, генератором и т.д., чтобы результатом этойитерации уже можно было пользоваться и было видно, что он уже улучшаетпроизводительность труда. В отличие от [36], мы не будем выделять отдельнопилотный проект.
Опыт разработки решений в рамках проекта QReal показывает,что у небольших проектов нельзя выделить время, когда решение готово и можетбыть использовано для пилотного внедрения. Внедрение обычно начинаетсяпрямо с готовности первого прототипа, пользователей желательно вовлекатьпрямо в процесс разработки.В остальном, модель жизненного цикла, используемого в «классической»методике, похожа на предлагаемую в [116], её общая схема представлена нарисунке 3.1.Деятельность на фазе анализа применимости была описана в разделе 3.2.1данной работы, её результатом является решение о том, имеет ли смысл применять предметно-ориентированный подход для данной ситуации. Этот этап неимеет инструментальной поддержки и требует опыта экспертов в предметноориентированном подходе.Анализ предметной области в предлагаемой методике проводится неформально, согласно рекомендациям из 3.2.2 данной работы.
Специальной инструментальной поддержки этого этапа в данном случае не предполагается, впрочем, длянебольших проектов, она и не требуется. Этап анализа предметной области можетперекрываться с этапом анализа применимости, поскольку для принятия решенияо применении DSM-подхода могут требоваться знания о предметной области.Этот этап также может перекрываться с первой итерацией разработки, посколькудля записи знаний о предметной области может использоваться метаредактор(это рекомендуемая практика, набросок метамодели полезен как для понимания89Рис. 3.1: «Классическая» методика разработки визуальногопредметно-ориентированного языка.взаимосвязи основных концепций предметной области, так и как то, из чего можетбыть получен первый прототип редактора языка).Следующий этап, доказательство осуществимости (proof of concept) являетсяпервым этапом разработки и имеет внутреннюю структуру такую же, как однаиз итераций следующего этапа, итерации разработки и внедрения.
Отличие егоот последующих итераций в том, что он не имеет своей целью реализациювсего, что необходимо, и относительно короток по времени. На этом этапевыбирается какой-то узкий срез предметной области и для него строится законченное DSM-решение, с редактором, генератором, предметно-ориентированнойбиблиотекой и т.д. Задача этого этапа — убедить будущих пользователей ируководство в применимости DSM-подхода, получить раннюю обратную связьи самим убедиться в осуществимости проекта. Результатом должен являтьсяпервый ограниченный в функциональности прототип, демонстрирующий, тем неменее, все составные части будущего продукта.
На основании результатов этогоэтапа может быть принято решение отказаться от продолжения проекта.Разработка и внедрение состоит из нескольких итераций, порядок действийдля каждой из которых представлен на рисунке 3.2. Начинается разработка с опре-90деления метамодели языка с помощью визуального метаязыка, либо внесенияизменений в уже существующую метамодель. Как только абстрактный синтаксисзадан, следующие действия можно выполнять параллельно.Рис. 3.2: Итерация проектирования и разработки языка.1. Определение графического представления символов языка.
Это должноделаться либо в графическом редакторе формы фигур, либо с помощью декларативного текстового языка описания формы, DSM-платформа должнаминимизировать ручное кодирование. Связано это с тем, что разработкупредполагается вести короткими итерациями, и тратить время на кодирование и отладку весьма нежелательно.2.
Задание ограничений на модели. Здесь речь идёт не про ограниченияна состояние создаваемой с помощью DSM-решения системы во времявыполнения, а про ограничения на модели, создаваемые при помощи DSMрешения, которые проверяются при рисовании моделей. Ограничения могутбыть заданы различными способами, насколько это позволяет выбраннаядля реализации DSM-платформа. В проекте QReal ограничения задаются с91помощью визуального языка, при этом модель ограничений отделена от метамодели и не обязательна для создания редактора.
Это позволяет авторамязыков не задумываться об ограничениях до тех пор, пока необходимостьих использования не станет очевидной.3. Определение правил рефакторингов моделей — довольно редко встречающаяся в DSM-платформах функциональность, но, поскольку автоматизация рефакторингов становится всё более распространённой в текстовыхсредах разработки, представляется, что скоро и инструменты визуальногопрограммирования без рефакторингов будут немыслимы. Простой примеррефакторинга — вынесение фрагмента диаграммы на языке описания поведения в подпрограмму.
Рефакторинги специфичны для конкретных языков,поэтому их необходимо задавать на уровне метамодели, а не поддерживатьвручную в DSM-решении. Как и в случае с ограничениями, используемыйинструментарий должен позволять не задумываться над рефакторингамибез нужды и генерировать инструменты без них.
Кроме того, правилазадания рефакторингов должны описываться на визуальном предметноориентированном языке, опять-таки, по той причине, что при быстромцикле итераций, предполагаемом данной методикой, на ручное кодированиетратить усилия нежелательно.4. Разработка семантики языка может осуществляться в двух видах, либопутём описания правил интерпретации, либо путём создания генератора вкакой-либо текстовый язык. Наиболее часто требуется только порождатьпо моделям код, тогда используется генератор, иногда бывает полезноделать и то, и другое (например, интерпретатор для интерактивной отладкина уровне модели и генератор для порождения результирующего кода).Иногда генерировать текстовое представление программы не требуетсявовсе (например, в режиме удалённого управления роботом или симуляциина двухмерной модели в примере из раздела A.1).
Подходы к заданию этихдвух видов описания семантики совершенно разные.(a) Семантика интерпретации, как правило, задаётся в виде правил преобразования графа модели, сродни рефакторингам. Интерпретаторприменяет эти правила до тех пор, пока существует хотя бы одно92правило, которое он может применить. Правила преобразования могутиметь побочные эффекты, с помощью которых может быть реализовано взаимодействие с внешними компонентами или устройствами,вычисление выражений на текстовом языке, встроенном в визуальный,и даже генерация. Семантика интерпретации должна задаваться навизуальном языке (наиболее удобный формализм для этого — графовые грамматики), побочные эффекты могут записываться на текстовомязыке.(b) Разработка генератора в текстовый язык обычно несколько сложнее.Процесс разработки состоит из трёх шагов, как правило, выполняемыхитеративно.i.
Разработка модельного приложения. Модельное приложениездесь — это пример того, что требуется сгенерировать. Писать генератор сразу же, без чёткого понимания, что именно должно бытьсгенерировано, очень сложно, поэтому сначала требуется создатьпример приложения вручную и добиться его работоспособности.Пример должен быть простым, но покрывать все разумные случаи,которые могут быть сгенерированы по диаграмме. При этом принаписании примера необходимо помнить о том, что его потомпридётся генерировать, так что структура программы должна бытьудобной для генерации. Для разработки примера используютсясредства программирования целевой платформы.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
