Диссертация (1148272), страница 19
Текст из файла (страница 19)
После того, какприложение отлажено, в DSM-решении рисуется модель, по которой оно могло бы быть сгенерировано.ii. Когда модельное приложение готово, его части, которые не будутменяться от модели к модели, имеет смысл вынести в отдельнуюбиблиотеку, написанную вручную. Такая библиотека называетсябиблиотекой времени выполнения (runtime) и нужна для того,чтобы упростить написание генератора. Она может быть довольносложной (вплоть до того, что представлять из себя полноценноеприложение, которое лишь конфигурируется результатом генерации), её может вообще не быть (если генерируются достаточно общие приложения, которым хватает возможностей целевой93платформы).
Подробнее соображения по разработке предметноориентированной библиотеки и балансе функциональности междуней и генератором см. в [36].iii. Разработка собственно генератора, как правило, заключается в«шаблонизации» готового модельного приложения — места, параметризуемые информацией из модели, размечаются директивами, руководствуясь которыми генератор формирует целевой код.Конкретный способ задания правил генерации зависит от возможностей DSM-платформы: как правило, используется текстовыйязык описания правил генерации либо генератор пишется вручную. В проекте QReal также используется текстовый предметноориентированный язык или рукописные генераторы, велись работы и по созданию визуального языка для этой цели. В процессеразработки генератора часто приходится править модельное приложение, чтобы сделать его структуру более пригодной для генерации, после чего корректировать библиотеку времени выполнения,поэтому процесс разработки генератора итеративен.5.
Следующий шаг, генерация инструментария, должен производиться с возможно меньшим участием человека. Кроме того, генерация должна бытьдостаточно быстрой, и результат генерации должно быть можно сразу жепроверить в среде. Это важно, поскольку тогда результат внесения своихизменений разработчик языка может проверить, ещё помня о них, и непереключая своё внимание на рутинные действия.6.
Тестирование и апробация созданных инструментов проводятся сначаларазработчиком, затем экспертами предметной области, для которых создаётся язык. Для начальных итераций обычно достаточно наличия одного эксперта, который бы попробовал воспользоваться созданным DSMрешением и высказал замечания, для более поздних итераций требуетсярасширять базу пользователей и давать им возможность решать реальныепрактические задачи. Чем раньше это будет сделано, тем быстрее будетполучена обратная связь и тем быстрее можно будет внести коррективы всоздаваемый инструментарий или выявить нужную пользователям функци-94ональность, которая пока не была реализована. На этом этапе потребуетсясборка инсталляционного пакета для DSM-решения, написание документации, исправление большого количества мелких ошибок, демонстрацияинструмента пользователям, наблюдение за их действиями в инструменте,сбор обратной связи.
По результатам апробации вносятся необходимыекоррективы в концептуальную модель и в метамодель языка, после чегоцикл разработки повторяется заново.Следующий этап, поддержка и сопровождение, включает в себя прежде всегоисправление ошибок в инструментарии и расширение или корректировку визуального языка. К этому моменту основная разработка должна быть завершена,поэтому сопровождение осуществляется меньшей командой разработчиков. Наэтом этапе важным фактором является версионирование метамодели вместес другими исходными кодами DSM-решения, чтобы не допустить ситуации,когда изменения в метамодели не согласованы с изменениями в инструментах,которые её используют.
Кроме того, необходимо следить за совместимостьюсуществующих пользовательских моделей с новыми версиями метамодели языка— пользователи не должны потерять уже проделанную работу. Поддержка исопровождение обычно состоит из коротких циклов внесения изменений, подготовки, если требуется, средств миграции моделей на новую версию метамодели,подготовку инсталляционного пакета, тестирование и развёртывание новой версии инструментария у пользователей. Даже небольшие DSM-решения могут бытьиспользуемыми годами, поэтому поддержка и сопровождение могут быть оченьпродолжительны по времени.Вывод из эксплуатации — заключительная фаза жизненного цикла DSMрешения.
Устаревшее DSM-решение может быть заменено более новым, можетбыть произведён реинжиниринг, оно может быть просто снято с сопровождения.При этом в любом случае пользователей следует заранее оповестить о прекращении поддержки и запланировать дальнейшие действия.3.4. Метамоделирование на лету«Метамоделирование на лету» — новая методика, разработанная в рамкахданной диссертационной работы и призванная оптимизировать начальные этапы95«классической» методики с целью максимально возможно сократить время отпринятия решения о реализации DSM-решения до получения первого работающего прототипа редактора визуального языка, и максимально вовлечь конечногопользователя в процесс разработки.
Основной принцип данной методики состоитв том, что создание визуального языка проходит непосредственно в процессерисования диаграммы, без использования метаредактора. Для этого требуетсяспециальная поддержка со стороны DSM-платформы, реализация которой в QRealбудет описана в главе 4:• интерпретация метамодели, когда редактор не генерируется по метамоделиязыка, а имеется настраиваемый редактор, который использует внутреннеепредставление метамодели в памяти для получения информации о языке;• пользовательский интерфейс над интерпретатором метамодели, дающийвозможность добавлять элементы, удалять элементы, добавлять, редактировать и удалять свойства элементов, менять графическое представлениеэлементов прямо во время работы.Основной этап предлагаемой методики — прототипирование языка — начинается сразу после этапа анализа применимости, и идейно близок к методике,изложенной в работе [69].
Разработчик языка и будущий пользователь работаютза одним рабочим местом. При запуске DSM-платформы они видят канву длярисования и пустую палитру. Пользователь объясняет, что он примерно хотелбы нарисовать, разработчик языка добавляет на палитру новые элементы, определяет для них графическое представление, пользователь рисует. Пользовательможет сказать, что такой-то элемент должен содержать такую-то дополнительнуюинформацию, тогда разработчик добавляет элементу новое свойство, задаёт еготип и значение по умолчанию, и пользователь продолжает рисовать диаграмму,используя новое свойство.
Через некоторое время пользователь может сам добавлять и редактировать типы элементов, и работа полностью передаётся ему,разработчик языка лишь следит за процессом и консультирует при необходимостипользователя. Работа заканчивается, когда модельное приложение полностьюнарисовано, после чего текущая интерпретируемая метамодель сохраняетсяв виде, пригодном для дальнейшего редактирования в метаредакторе. Послеэтой фазы идут итерации «классической» методики по доработке созданного96прототипа, дополнению его ограничениями, рефакторингами, интерпретатороми генератором, подготовки инсталляционного пакета, развертывания и сбораобратной связи. На этих этапах пользователи, как и в «классической» модели,непосредственно в разработке не участвуют, поскольку этапы гораздо болеепродолжительны во времени и прямо при пользователе выполнены быть не могут.Модель жизненного цикла языка, использующая «метамоделирование налету», представлена на рисунке 3.3.Рис.
3.3: методика «метамоделирования на лету».Здесь не проводится формального или даже неформального анализа предметной области в общепринятом понимании, знания о предметной области извлекаются из эксперта прямо в процессе прототипирования языка. Также отсутствуетфаза доказательства осуществимости (proof of concept), поскольку редактор создаётся прямо на глазах пользователя, и пользователь может сразу сказать, то ли это,что он хочет. Разумеется, генератор, предметно-ориентированную библиотеку ит.д. придётся писать потом, так что на самом деле proof of concept просто смещённа первую итерацию разработки, но по окончании прототипирования по крайнеймере у одного будущего пользователя DSM-решения есть уверенность в егополезности и применимости (причём, довольно сильная, потому что фактическион сам это решение создал).97Все остальные этапы жизненного цикла и деятельности на этих этапах совпадают с аналогичными этапами в «классической» методике (поскольку результатом прототипирования будет обычная метамодель).
Для небольших проектовэта методика наиболее применима, поскольку в таком случае всю остальнуюинструментальную поддержку оказывается возможно реализовать за одну-двеитерации и получить максимальную выгоду от высокой скорости начальногопрототипирования языка. При этом наиболее эффективна эта методика в томслучае, если пользователем будущего языка станет сам его разработчик.Инструментальные средства поддержки метамоделирования на лету не могутбыть такими же выразительными, как средства, предоставляемые полноценнымметаредактором. Связано это с тем, что, функциональность метамоделированияна лету должна быть максимально простой и легковесной, чтобы ею мог пользоваться эксперт предметной области, не разбирающийся в тонкостях созданиявизуальных языков. По сути эксперт работает с метамоделью языка, но не долженподозревать об этом и тем более не должен владеть связанной с метамоделированием терминологией.
Метамодель оказывается скрыта от пользователя.Разумеется, полноценный синтаксис визуального языка таким образом не задать,простой пример — указание того, к каким узлам может быть подключена связь,было бы слишком сложно для такого режима. Поэтому в режиме метамоделирования на лету для метамодели предполагаются разумные умолчания, дающиемаксимальную свободу действий пользователя — например, связям разрешаетсясоединять любые узлы языка. Это допустимо, поскольку при первоначальномпрототипировании пользователь рисует заведомо «правильные» диаграммы, тоесть то, что он хочет увидеть.
Для полноценного решения такой подход недопустим, поскольку пользователи неизбежно будут ошибаться, и система должнане давать пользователю совершать ошибок настолько, насколько это возможно.Поэтому после быстрого прототипирования требуется правка метамодели языкав метаредакторе и внесение в неё дополнительных ограничений. Кроме того, самязык после быстрого прототипирования будет задан не так, как это делалось бывручную — без учёта инфраструктурных соображений, таких как группировкасущностей языка по пакетам или отношений наследования между элементами.Таким образом, чтобы получить сопровождаемую и переиспользуемую метамо-98дель языка, требуется рефакторинг полученной после метамоделирования на летуметамодели.Сформулируем требования к интерфейсу и функциональности режима метамоделирования на лету.1.
![](https://s.studizba.com/z.php?f=/templates/si/i/noavatar.png&w=100&h=100&t=1"){kind=avatar}
