Диссертация (1148272), страница 17

Просмтор этого файла доступен только зарегистрированным пользователям. Но у нас супер быстрая регистрация: достаточно только электронной почты!

Текст из файла (страница 17)

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

Как и в случае с текстовыми языками, визуальный языквовсе не обязательно создавать с нуля, можно использовать уже существующиеязыки и использовать их как базу для создаваемого, путём создания «лёгких»расширений (например, с помощью механизма профилей UML), либо путёмпереиспользования и расширения частей существующих метамоделей. Существующие технологии имеют тенденцию поощрять создание DSL с нуля, этоне всегда оптимально. А чтобы поддержать переиспользование метамоделей,в DSM-платформе должны наличествовать специальные средства, такие какпросмотрщики метамоделей, возможность декомпозиции метамодели и импорта.Требования к инструментальной поддержке фазы реализации подробно описаны в литературе (например, в [36]).

Тут укажем лишь те требования, которыебыли положены в основу проекта QReal.1. Наличие визуального языка описания метамодели и визуального редактораконкретного синтаксиса языка (редактора формы фигур).2. Наличие возможности визуально задавать ограничения на модели, семантику интерпретации языка и правила рефакторингов.3. Возможность автоматически сгенерировать редактор визуального языка пометамодели и описанию конкретного синтаксиса.4.

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

То, как эти требованияреализованы в DSM-платформе QReal, описано в главе 4.3.2.4. РазвёртываниеФаза развёртывания предполагает наличие инструментальных средств поддержки языка, которые необходимо, во-первых, установить на рабочих местахпользователей, а во-вторых, обучить пользователей работе с ними. Подготовкаинсталляционного пакета особых сложностей не представляет (при этом наличиев DSM-платформе поддержки создания инсталлятора созданного DSM-решениябыло бы весьма желательно), основное внимание на фазе развёртывания уделяется работе с пользователями. Несмотря на то, что визуальные предметноориентированные языки специально создаются для удобства использованияконкретной группой пользователей, существуют тенденции по их отторжению.Связано это с тем, что, во-первых, люди привыкли пользоваться текстовымиязыками программирования (в тех случаях, когда это не так, например, привнедрении технологии QReal:Robots, описанной в разделе A.1, процесс внедренияпроходит легче), во-вторых, предметно-ориентированные языки практическивсегда будут новыми для пользователей.

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

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

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

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

Прежде всего, пользователи не должны терять результаты своей работы: при изменении визуального языка и его метамодели, модели, созданныев соответствии со старыми метамоделями, должны продолжать открываться вредакторе. Существует несколько подходов к тому, как это обеспечить, самыйпростой — снабдить модели информацией о версии метамодели, с помощьюкоторой они были созданы, и вручную создавать конвертеры, преобразующиемодели в более новые версии. При этом могут быть полезны возможности DSMплатформы, такие как средства задания преобразования моделей (так, например,делается в Eclipse Modeling Project, правила миграции моделей описываются кактрансформации «модель-в-модель»). Такой подход чрезвычайно распространён ив текстовых средах разработки, современные IDE часто предлагают сконверти-86ровать проект при открытии его в более новой версии.

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

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

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

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

Инструментальная поддержка этой фазы со стороныDSM-платформы обычно не требуется, однако забывать об этой фазе не следует.3.3. «Классическая» методикаНа основе представленных фаз жизненного цикла визуального языка можнопредложить модели жизненного цикла DSM-решения и методики на их основе.Первая методика, поддерживаемая DSM-платформой QReal и предлагаемая в данной работе, — методика, основанная на применении визуального метаредактора.Такой подход к разработке визуальных языков реализуется в большинстве существующих DSM-платформ, поэтому его можно назвать «классическим» подходом,и здесь автор не претендует на научную новизну. Вклад данной работы состоитв описании этой методики в той форме, в которой её рекомендуется применять, ипредставлении реализации её инструментальной поддержки, описанной в главе 4.Поскольку в рамках проекта QReal никогда не создавались по-настоящемубольшие визуальные языки и DSM-решения, методика предназначена и апробирована для небольших и средних DSM-проектов.

Характеристики

Список файлов диссертации