Диссертация (Методы и средства разработки графических предметно-ориентированных языков), страница 9
Описание файла
Файл "Диссертация" внутри архива находится в папке "Методы и средства разработки графических предметно-ориентированных языков". PDF-файл из архива "Методы и средства разработки графических предметно-ориентированных языков", который расположен в категории "". Всё это находится в предмете "технические науки" из Аспирантура и докторантура, которые можно найти в файловом архиве СПбГУ. Не смотря на прямую связь этого архива с СПбГУ, его также можно найти и в других разделах. , а ещё этот архив представляет собой кандидатскую диссертацию, поэтому ещё представлен в разделе всех диссертаций на соискание учёной степени кандидата технических наук.
Просмотр PDF-файла онлайн
Текст 9 страницы из PDF
Разумеется, нам будут интересны и статьи,содержащие опыт разработки визуальных языков, пусть и слабоструктурированный, поскольку они могут послужить базисом для создания методик разработки.По этим же причинам в обзор будут включены статьи, в которых обсуждаютсяаспекты организации языковой инфраструктуры (например, [4]) –– различныеточки зрения на внутреннюю структуру и устройство визуальных языков могутприводить к необходимости выполнения разных действий при их создании.Также значительное внимание в обзоре будет уделено существующим инструментальным средствам, аналогам системы QReal.
Поскольку данная работапосвящена процессу создания визуальных языков, особенности инструментальных средств, к этому процессу непосредственно не относящиеся, рассматриватьсяне будут. Большинство имеющихся описаний инструментальных средств нефокусируются на какой-либо методике создания визуального языка (представляяcредства, но не указания по их использованию).
В тех редких случаях, когдаэто не так, и инструментальное средство имеет за собой чёткую методику егоприменения (как, например, в работе [69]), такое описание будет рассмотрено впервой части обзора, вместе с работами, излагающими общие методологическиеуказания.Существующихинструментальныхсредствсозданияпредметно-ориентированных визуальных языков много, однако опыт в этой областипрограммной инженерии практически не переиспользуется (что отмечаюти авторы [36]).
Например, в обзоре будет упомянута система, публикацияпо которой датируется 1977 годом, имеющая все признаки типичнойDSM-платформы [77], тогда как сам термин «предметно-ориентированноемоделирование» (Domain-Specific Modeling) начал упоминаться в литературеначиная примерно с 1995 года, причём до сих пор данный подход во многихработах преподносится как новый и активно развивающийся. Поэтому средствабудут рассматриваться не в хронологическом порядке, а в порядке частоты ихупоминаний в литературе, от наиболее часто упоминаемых к менее известным,насколько может судить автор данной работы.
Автору известно порядка 40подобных средств, но, в силу ограниченности объёма диссертации, будутрассмотрены только наиболее известные, а также особенно интересные вконтексте данной работы.44В данном обзоре не будут рассмотрены работы, доказывающие экономическую целесообразность применимости предметно-ориентированного подхода ивизуального моделирования вообще, ссылки на них читатель может найти вовведении к диссертации. Кроме того, не будут рассмотрены работы, в которых вводятся различные определения, относящиеся к визуальным предметноориентированным языкам, классификации языков и т.д., имеющие лишь вспомогательное значение для диссертации, ссылки на такие работы содержатся вглаве 1.2.2.
Существующие методики и приёмы разработкипредметно-ориентированных языков2.2.1. Модели жизненного цикла языкаНачатьследуетсобщихвопросовжизненногоциклапредметно-ориентированных языков. В данном случае не имеет особого значения,визуальные это языки или текстовые, поскольку различия между ними играютсущественную роль лишь при реализации. Наиболее обстоятельное, наскольконам известно, обсуждение данных вопросов приводится в статье [47]. Авторывыделяют следующие фазы существования предметно-ориентированного языка:принятие решения (о необходимости создания DSL), анализ (предметнойобласти), проектирование (переиспользование языка общего назначения длясоздания DSL и спецификация DSL), реализация и развёртывание.
Рекомендациипо деятельности коллектива разработчиков на каждой фазе даны в виде паттерновс примерами применения в реальных проектах.В фазе принятия решения наиболее интересными для нас показателямиприменимости DSM-подхода могут служить:• наличие сложного интерфейса прикладных программ (API1 ), который можно было бы представить сущностями созданного языка;• наличие необходимости (или возможности) предметно-ориентированногоанализа, верификации, оптимизации, параллелизации и трансформации1Application Programming Interface45(авторами используется акроним AVOPT, образованный первыми буквами английских эквивалентов перечисленных терминов), которые требуютзнания особенностей предметной области и поэтому неосуществимы наязыке общего назначения (авторы используют термин GPL, General PurposeLanguage);• наличие семейства программных продуктов, имеющего довольно многообщих частей и некоторые различия, которые могут быть выражены посредством DSL;• представление сложных структур данных и работа с ними.На фазе анализа в основном применяются неформальные методы, хотя авторы упоминают несколько существующих формальных методик (перечисленыметодики DARE, DSSA, FAST, FODA, ODE, ODM).
Авторы отмечают отсутствие поддержки анализа предметной области в имеющихся инструментальныхсредствах, и из дальнейшего обзора станет ясно, что с визуальными предметноориентированными языками ситуация обстоит аналогичным образом. Существуют отдельные инструменты, поддерживающие формальный анализ предметнойобласти, но ни один из них не интегрирован со средствами разработки языков,хотя анализ предметной области является входом для наиболее важной при создании предметно-ориентированного языка деятельности — выделения основныхсущностей языка.Паттерны фаз проектирования и реализации, описанные в статье, оказываютсяесли не полностью неприменимы к визуальным языкам, то достаточно далеки отприменяемых в случае визуальных языков подходов, чтобы было необходимо рассматривать другие источники.
Действительно, авторы выделяют переиспользование языка общего назначения при создании DSL как один из возможных подходовк проектированию, и для визуальных языков это тоже может быть применимо,например, использование механизмов расширения языка UML, но это отдельнаятема, которая заслуживает отдельного обсуждения. Подходы, типичные для этихфаз, будут обсуждаться далее при рассмотрении более подходящих для этогоисточников.В статье совершенно не рассматриваются аспекты существования языка послеего развёртывания, что довольно странно, поскольку редко бывает, чтобы язык46был сразу же создан таким, каким его было бы удобно использовать. Эволюцияпредметно-ориентированного языка требует особого рассмотрения, посколькудолжна осуществляться совместно с созданными на этом языке моделями (илипрограммами), и её нельзя исключать из модели жизненного цикла.
Интересныев контексте данной работы выводы, сделанные в статье — существующиеинструментальные средства фокусируются в основном на вопросах реализациии либо не предоставляют вообще средств автоматизации других фаз жизненногоцикла, либо эта поддержка весьма ограничена.Работа [95] интересна сама по себе как подробная библиография, посвящённаятекстовым предметно-ориентированным языкам, покрывающая вопросы терминологии, целесообразности использования DSL, методики создания, реализацииDSL и содержащая ссылки на массу примеров. Для нас существенны методологические вопросы. Авторы делят фазы жизненного цикла языка на три группы —анализ, реализация и использование.
Этап анализа, как и в предыдущей работе,предполагает применение неформального подхода или одной из формальныхметодик (здесь их применение называется инженерией предметной области, илиdomain engineering), кроме того, в качестве источника информации для анализа указываются унаследованные системы (legacy systems) либо существующиебиблиотеки и каркасы приложений. Реализация рассмотрена исключительнодля текстовых языков, информации по последнему этапу жизненного цикла —использованию языка — не представлено.Работы [39] и [116] рассматривают процесс разработки языка с менее технической точки зрения. Предлагается в качестве модели для разработки DSMрешения в небольших и средних компаниях использовать методологию MicrosoftSolution Framework (MSF), несколько адаптированную под специфику DSMподхода.
Автор выделяет фазы выработки концепции (envisioning), планирования,разработки, стабилизации, внедрения и эксплуатации и сопровождения. При этомфаза планирования включает в себя выбор технологии, разработку первой версииметамодели, после чего фаза разработки состоит из нескольких циклов, состоящих из уточнения требований, модификации метамодели, генерации редакторови ручного кодирования, демонстрации и сбора обратной связи. Стабилизациявключает в себя интеграцию, пилотное внедрение и доработку, после чего, послеэтапа внедрения, DSM-решение переходит в фазу сопровождения. Более подроб-47но методология разработки языка изложена в диссертации [117], где помимомодели разработки описываются также сопутствующие деятельности и инструменты.
Система QReal может рассматриваться как одно из инструментальныхсредств, которые могут быть применены в рамках предложенной Д.В. Козновымметодологии, а предлагаемая в данной работе методика разработки предметноориентированных языков — как одна из методик в рамках методологии Д.В.Кознова.Интересная методика разработки предметно-ориентированных визуальныхязыков, а также поддерживающая её технология AgentSheets, предлагается вработе [69]. Поскольку необходимыми знаниями о предметной области обладаюттолько эксперты, как правило, не обладающие навыками создания языков, авторыпредлагают коллаборативный подход к разработке — эксперт предметной областии эксперт по созданию языков работают вместе. Модель жизненного цикла вэтом случае — последовательность итераций, каждая из которых состоит из фазиспользования, «поломки» (breakdown), обсуждения (negotiation), модификации итестирования.
Сначала пользователь пытается что-то сделать на текущей версииязыка, доходит до того места, где у него что-то не получается или кажется неудобным, при этом разработчик языка сидит рядом и наблюдает за действиями пользователя. Потом разработчик и пользователь обсуждают необходимые измененияв языке, разработчик прямо на глазах у пользователя вносит изменения, при этомимея перед глазами созданную пользователем модель, тестирует изменения ипередаёт управление снова пользователю, начиная следующую итерацию. Такойподход требует специальной поддержки со стороны инструментария, ведь еслина внесение изменений в язык требуется слишком много времени, пользовательне сможет ждать.