Размещено на http://www.allbest.ru/

• Пермский филиал федерального государственного автономного
• образовательного учреждения высшего образования
• «Национальный исследовательский университет
• «Высшая школа экономики»
• Факультет экономики, менеджмента и бизнес-информатики
• Выпускная квалификационная работа
• Разработка инструментальных средств создания текстовых предметно-ориентированных языков: компонент проверки синтаксиса
• по направлению подготовки 09.03.04 Программная инженерия
• образовательная программа «Программная инженерия»
• Медведева Екатерина Юрьевна
• Рецензент: к.ф.-м.н., доцент, доцент кафедры математического
• обеспечения вычислительных систем ПГНИУ, Н.Н. Дацун
• Руководитель: к.ф.-м.н., доцент,
• доцент кафедры информационных технологий в бизнесе А.О. Сухов
• Пермь, 2017 год


Аннотация

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



• Содержание
• Введение
• Глава 1. Анализ языковых инструментариев
• 1.1 OpenArchitectureWare
• 1.2 JetBrains MPS
• 1.3 IDE Meta-Tooling Platform
• 1.4 MontiCore
• 1.5 Spoofax Language Workbench
• Глава 2. Описание метода создания текстовых предметно_ориентированных языков
• 2.1 Расчет трудоемкости разработки компонента проверки синтаксиса
• 2.2 Требования к метаязыку
• 2.3 Описание метаязыка
• 2.4 Алгоритмы разбора грамматики DSL
• 2.5 Алгоритм проверки синтаксиса модели
• 2.6 Алгоритм формирования списка подсказок
• Глава 3. Проектирование архитектуры языкового инструментария
• 3.1 Проектирование языкового инструментария
• 3.2 Проектирование компонента проверки синтаксиса
• 3.3 Проектирование пользовательского интерфейса
• Глава 4. Программная реализация компонента проверки синтаксиса
• 4.1 Построение дерева разбора
• 4.2 Анализ модели
• 4.3 Разработка репозитория
• 4.4 Тестирование компонента проверки синтаксиса
• Заключение
• Библиографический список
• Приложение А. Диаграмма прецедентов
• Приложение Б. Диаграммы последовательностей
• Приложение В. Диаграмма классов
• Приложение Г. Таблица взаимодействия классов
• Приложение Д. Нормативные коэффициенты трудоемкости
• Приложение Е. Поправочные коэффициенты
• Приложение Ж. Техническое задание
• Приложение И. Руководство пользователя
• Приложение К. Руководство системного программиста
• Приложение Л. Тестирование методом сценариев
• Приложение М. Программный код


Введение

В настоящее время информационные системы, активно развиваясь, находят применение в различных областях экономического рынка. Для эффективного функционирования таких систем необходимо, чтобы они адекватно отражали бизнес-процессы организаций. Вследствие чего появляется необходимость привлечения бизнес-аналитиков и конечных пользователей в процесс создания программного продукта на некоторые этапы его жизненного цикла. Однако возникает ряд сложностей, связанных с использованием традиционных подходов к разработке информационных систем (ИС), поскольку они предполагают применение языков программирования и моделирования общего назначения, которые сложны для понимания экспертам, не являющимся специалистами в области информационных технологий. А профессиональные программисты, в свою очередь, не всегда способны с точностью до специфичных деталей построить концептуальную модель решаемой задачи, так как большинство особенностей предметной области могут быть выявлены только бизнес-аналитиками или конечными пользователями [5].

Для решения данных проблем необходимо изменить подход к разработке программного обеспечения так, чтобы разные категории специалистов имели возможность работать над программным продуктом. Поэтому появляется необходимость использования модельно-ориентированного подхода (МОП) для создания ИС. При помощи данного подхода на каждом этапе строятся модели с определенным уровнем абстракции [5], тем самым эффективно координируется работа всех участников разработки, ведь ключевым становится не написание программного кода, а построение моделей. Также данный подход позволяет повторно использовать уже описанные модели, что значительно снижает трудоемкость работы над проектом, ведь для модификации достаточно изменить модель без внесения правок в программный код [4].

При использовании МОП необходимо определить языки моделирования для каждого уровня формирования моделей. Поскольку языки моделирования общего назначения, такие как UML, являются не всегда понятными как бизнес-аналитику, так и программисту, становится актуальным использование предметно-ориентированных языков (DSL), позволяющих формально описать модель системы, используя при этом понятную пользователю терминологию [4].

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

При создании информационной системы с применением текстовых предметно-ориентированных языков можно использовать уже разработанные DSL, однако, не для всех предметных областей и задач подойдут имеющиеся решения. Поэтому становится необходимым создание собственных текстовых предметно-ориентированных языков, что является довольно трудоемким процессом, поскольку помимо самого языка необходимо разработать текстовый редактор для работы с ним, отладчик, генератор кода и др. Языковой инструментарий - это вид программного обеспечения, призванный упростить процесс разработки DSL за счет наличия редактора кода с подсветкой синтаксиса, браузера проектов, отладчика для удобства поиска ошибок и трансформатора для выполнения преобразования моделей в программный код или в модель, спроектированную с использованием другого DSL. В настоящее время существуют различные языковые инструментарии, позволяющие создавать текстовые предметно-ориентированные языки. При анализе самых распространенных инструментальных средств, таких как Eclipse OpenArchitectureWare, JetBrainsMPS, Microsoft Language Tools, Lisp DSLs, MontiCore, Spoofax Language Workbench были выявлены следующие недостатки:

1. Отсутствие возможности модификации, расширения (добавления новых конструкций) DSL без перегенерации программного кода редактора языка.

2. Наличие избыточного функционала, который мешает изучению инструментария пользователям, не являющимся профессиональными программистами.

3. Отсутствие возможности определять, модифицировать правила преобразования программ, созданных с помощью DSL, в программный код на других языках.

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

Объектом исследования данной работы является текстовые предметно-ориентированные языки, а предметом исследования - инструментальные средства создания текстовых предметно-ориентированных языков.

Цель выпускной квалификационной работы - разработка компонента проверки синтаксиса инструментальных средств создания текстовых предметно-ориентированных языков. Для достижения данной цели необходимо выполнить следующие задачи:

1. Расширить набор конструкций метаязыка предопределенными нетерминалами (идентификатор, буква, цифра, пропуск) для повышения эффективности работы с языковым инструментарием.

2. Сформировать алгоритмы анализа моделей разного уровня:

2.1. Создать алгоритм разбора метамодели для построения синтаксического дерева.

2.2. Создать алгоритм парсинга и проверки корректности модели.

3. Доработать редактор кода:

3.1. Добавить возможность формирования и отображения списка ожидаемых терминальных символов для каждой конструкции метаязыка.

3.2. Доработать пользовательский интерфейс.

4. Спроектировать компонент проверки синтаксиса.

5. Программно реализовать спроектированный компонент.

6. Выполнить тестирование разработанной части системы.

В данной работе планируется использовать следующие методы исследования: теория формальных языков и грамматик, методы объектно-ориентированного проектирования и программирования, методы трансляции.

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

Во второй главе будет приведено обоснование сроков разработки компонента, концепции создания текстовых DSL, в частности будет определен набор основных конструкций разрабатываемого метаязыка, способ формирования DSL на его основе, а также алгоритмы построения дерева синтаксического разбора, анализа корректности модели на предмет лексических и синтаксических ошибок, формирования списка ожидаемых терминальных символов для конструкций языка.

Третья глава будет содержать описание архитектуры всего языкового инструментария с обоснованием необходимости включения каждого из компонентов, в частности будет приведена архитектура рассматриваемого компонента проверки синтаксиса. Кроме того, в данной главе будет рассмотрено проектирование пользовательского интерфейса для разрабатываемой части системы.

Четвертая глава будет посвящена разработке и тестированию компонента проверки синтаксиса, репозитория и браузера проектов, в частности будет приведено описание реализации алгоритмов, разработанных на этапе анализа.

В заключении будут описаны результаты выполненной работы.



Глава 1. Анализ языковых инструментариев

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

Модельно-ориентированный подход к разработке системы предполагает создание многоуровневой модели приложения во время выполнения проектирования и дальнейшее использование построенных моделей в качестве исходного кода, что позволяет оперировать терминами предметной области, а не конструкциями языка общего назначения. Так, для построения моделей может быть использован предметно-ориентированный язык (DSL) - язык программирования, предназначенный для решения узкого круга задач в конкретной предметной области. Все DSL можно разделить на две основные группы по методу реализации:

1. Внутренние DSL (internal DSL).

2. Внешние DSL (external DSL).

Внутренний DSL - это язык, который является надстройкой над выбранным в качестве базового языком программирования. С его помощью можно более эффективно решать определенный круг задач, используя при этом все возможности базового языка программирования [7]. Таким образом, при создании данного DSL приходится оперировать только конструкциями основного языка, что позволяет использовать уже готовые компиляторы, однако это накладывает ряд ограничений и, следовательно, делает такой DSL менее гибким. Внутренние предметно-ориентированные языки полностью не устраняют проблему семантического разрыва между синтаксисом программы и терминами предметной области, но позволяют в более простой форме решить задачу управления отельными частями разрабатываемой системы. Примерами применения внутренних DSL могут служить Ruby и Lisp [9].

Внешние DSL обладают собственным синтаксисом, никак не связанным с синтаксисом языка программирования самого приложения, что предполагает наличие внешнего компилятора и интерпретатора. В качестве примеров таких языков выступают SQL, XML, awk [7]. Для создания внешнего DSL, необходимо заранее определить синтаксис языка (метамодель), а для описания этого синтаксиса необходим метаязык (метаметамодель). Также для перехода от модели предметной области, описанной с помощью DSL к программе на определенном языке программирования, следует предусмотреть правила трансформации, которые включают в себя вертикальные трансформации (переход от одного уровня иерархии к другому) и горизонтальные (переход от одной модели к другой на одном уровне иерархии). Данный итеративный процесс в итоге и образует иерархию моделей в MDD подходе.

Поскольку в рамках данного исследования основной задачей является сокращение семантического разрыва между терминами предметной области и инструментальными средствами, предметом дальнейшего анализа является разработка внешних DSL как языка моделирования.

Разработка собственных предметно-ориентированных языков является нетривиальной задачей, вследствие чего становится необходимым использовать средства автоматизации их построения - языковой инструментарий.

Перед тем, как приступить к анализу инструментов, следует определить требования, предъявляемые к системам разработки текстовых DSL:

1. Наличие возможности создания собственного метаязыка или изменения существующего.

2. Наличие возможности расширения DSL без перегенерации кода редактора языка.

3. Наличие возможности выполнения горизонтальных и вертикальных трансформаций.

4. Отсутствие избыточной функциональности, усложняющей изучение системы пользователями непрофессиональными программистами.

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

Выполним сравнение языковых инструментариев, широко применяемых при разработке текстовых DSL.

1.1 OpenArchitectureWare

OpenArchitectureWare (oAW) - это инструментарий с открытым кодом для реализации MDA/MDD подходов к разработке приложений, основанный на платформе Eclipse (рис. 1.1):

Рисунок 1.1. oAW текстовый редактор

Данный программный продукт включает в себя компонент xText, предназначенный для генерации текстового языка моделирования из простого описания грамматики. Также xText создает техническую метамодель при описании конкретного синтаксиса, которая соответствует требованиям контекстно-свободной грамматики, схема которой поддерживает наследование типов, перекрестные ссылки и перечисления. Граф абстрактного синтаксиса генерируется в форме Ecore-модели, базирующейся на Eclipse Modeling Framework (EMF). Прямые вертикальные трансформации выполняются при помощи Antlr для генерации сканера и парсера, тогда как обратные трансформации используют шаблонный движок xPand [9] (см. рис. 1.2):

Рисунок 1.2. Компоненты oAW

Сгенерированный текстовый редактор для проектирования моделей с использованием DSL выполняет проверку корректности моделей, поскольку они могут быть семантически неверными, даже если синтаксические правила не нарушены. Также данный редактор поддерживает подсветку синтаксиса, интеллектуальное автодополнение кода [10].

Достоинства данной системы:

1. Возможность построения текстовых DSL для различных предметных областей.

2. Наличие удобного текстового редактора с подсветкой синтаксиса.

3. Возможность настройки системы под конкретные требования, т.к. oAW является проектом с открытым кодом.

К недостаткам можно отнести:

1. Отсутствие возможности проведение горизонтальных трансформаций.

2. Отсутствие динамического изменения программного кода при изменении метамоделей.

3. Сложность работы с системой специалистам, не являющимися профессиональными программистами.

1.2 JetBrains MPS

MPS - это интегрированная среда для языковой разработки, позволяющая либо определять новые языки общего назначения и предметно-ориентированные языки, либо создавать модульные расширения уже существующих языков (рис. 1.3).

Рисунок 1.3. MPS текстовый редактор

Для определения различных аспектов языка в MPS необходимо описать DSL с использованием набора компонентов, таких как структура, редактор, система типов, генератор, также в данной системе существует поддержка сложной функциональности IDE, а именно автозавершение кода, рефакторинг, отладчик, анализ потока данных (рис. 1.4).

Рисунок 1.4. Компоненты MPS

Процесс создания DSL с помощью MPS начинается с определения структуры языка (абстрактного синтаксиса или метамодели). Это напоминает объектно-ориентированное программирование, языковые концепты подобны классам. Концепты в MPS - это типы узлов абстрактного синтаксического дерева, содержащие информацию о свойствах, методах, наследниках и ссылках, которые могут иметь экземпляры узлов. MPS предлагает три языковых аспекта для определения абстрактного синтаксиса: структурный аспект определяет концепты, их свойства и связи; ограничительный аспект изменяет набор значений для свойств и ссылок в соответствии с требованиями; аспект поведения связывает методы с концептами [14].

Вторым шагом является определение редактора для концептов. Поскольку код в MPS никогда не представляется как обычный текст (ни на экране, ни на диске), никакая грамматика не требуется, что позволяет использовать для визуализации таблицы или математические символы. Вместо анализатора определяется редактор для языковых концептов - визуальное представление узлов абстрактного синтаксического дерева. Редактор может быть собран из блоков для повторного использования визуальных элементов синтаксиса. Кроме того, данный редактор оснащен функцией интеллектуального завершения кода, подсветкой синтаксиса, системами контроля корректности концептов.

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

Далее определяются правила преобразования модели в язык более низкого уровня или в обычный текст. Процесс генерации состоит из двух фаз: горизонтальная трансформация для уменьшения программного кода на целевом языке программирования, а когда никакое преобразование от модели к модели не применимо, используется текстовая генерация для преобразования конечной модели в программу, отправляемую компилятору [14].

Можно отметить следующие преимущества MPS:

1. Способность быстро построить IDE для языка.

2. Наличие удобного редактора, предоставляющего не только свободный выбор нотации, но и гибкий состав языков.

3. Возможность выполнения как горизонтальных, так и вертикальных преобразований моделей.

4. Возможность настройки системы под конкретные требования, т.к. MPS является проектом с открытым кодом.

Недостатками данного инструментария являются:

1. Сложность освоения данной системы пользователями, не являющимися разработчиками.

2. Отсутствие динамического изменения сгенерированного программного кода при изменении метамоделей.

1.3 IDE Meta-Tooling Platform

IDE Meta-Tooling Platform (IMP) - это плагин Eclipse, разработанный главным образом компанией IBM с целью упрощения создания IDE для новых языков (рис. 1.5).

Рисунок 1.5. Редактор кода IMP

При использовании данного плагина необходимо определение только конкретного синтаксиса, представляющего собой контекстно-свободную грамматику, а абстрактный синтаксис строится исходя из него при помощи генератора синтаксического анализатора LPG (см. рис. 1.6):

Рисунок 1.6. Компоненты IMP

IMP имеет функциональный редактор, основанный на платформе Eclipse, включающий в себя подсветку синтаксиса, всплывающие подсказки, автозавершение, сворачивание и форматирование кода. Однако IDE Meta-Tooling Platform не содержит редактор шаблонов, необходимый для генерации кода [6, 8].

Преимуществами системы IMP являются:

1. Требуется определение только конкретного синтаксиса.

2. Удобный и функциональный редактор.

3. Гибкость использования, не ограничивающаяся конструкциями DSL.

Недостатки IMP:

1. Отсутствие встроенных возможностей трансформаций моделей.

2. Отсутствие встроенной возможности представления целевого кода.

3. Сложность освоения данной системы пользователями, не являющимися разработчиками.

4. Отсутствие динамического изменения сгенерированного программного кода при изменении метамоделей.

1.4 MontiCore

MontiCore - инструментарий для создания текстовых предметно-ориентированных языков, базирующийся на платформе Eclipse (см. рис.1.7).

Рисунок 1.7. Редактор MontiCore

Данный программный продукт для определения DSL использует расширенную грамматику, включающую в себя конкретный и абстрактный синтаксисы, моделирование которых осуществляется с использованием единого источника данных, что позволяет избежать проблем, связанных с избыточностью. Для представления абстрактного синтаксиса используется древовидная структура (AST), связи между узлами которой определяются стандартными средствами данной платформы [13] (рис. 1.8).

Рисунок 1.8. Компоненты MontiCore

MontiCore предоставляет возможность повторного применения разработанных языков с помощью переопределения грамматики, а именно ее расширения с использованием механизмов наследования и «встраивания» одной грамматики в другую посредством неописанных нетерминалов.

Кроме того, данный инструментарий обладает возможностью выполнения вертикальных трансформаций, как внутри MontiCore, так и с использованием внешних средств: генератора Java, программного ядра для реализации шаблонов.

Данная платформа обладает следующими преимуществами:

1. Возможность расширения DSL без перегенерирования программного кода.

2. Наличие интеллектуального редактора кода.

3. Возможность выполнения вертикальных трансформаций.

Из недостатков можно отметить:

1. Отсутствие возможности выполнения горизонтальных трансформаций (модель-модель).

2. Отсутствие встроенного интерпретатора.

3. Для изменения правил трансформации требуется использовать Java-код.

4. Сложность освоения данной системы пользователями, не являющимися разработчиками.

1.5 Spoofax Language Workbench

Данная платформа позволяет итеративно разрабатывать текстовые предметно-ориентированные языки и выполнять запуск написанных программ в экземпляре среды разработки Eclipse. Spoofax предлагает комплексную среду разработки программных систем, включающую в себя компоненты описания, анализа синтаксиса, трансформации и генерации объектного кода. Для каждой из этих частей система обеспечивает высокую гибкость метаязыка, что позволяет разработчикам не заострять внимание на реализации языковых процессов, а уделять внимание только разработке [12].

Spoofax Language Workbench имеет интеллектуальный редактор кода (см. рис.1.9), основанный на формализме SDF3, который объединяет контекстный и абстрактный синтаксис в едином шаблоне. Использование SDF3 обеспечивает инструментарий следующими функциями IDE [16]:

1. Наличие синтаксического анализатора, который преобразует конкретный синтаксис в абстрактное представление и формирует список ошибок.

2. Наличие трансформатора, который преобразует абстрактное представление в конкретный синтаксис.

3. Подсветка синтаксиса.

4. Сворачивание и автодополнение кода.

5. Выполнение рефакторинга.

Рисунок 1.9. Редактор Spoofax Language Workbench

Spoofax использует Srtatego для определения правил трансформации и генерации кода. Трансформатор транслирует каждую продукцию написанной программы из компонента определения синтаксиса (SDF3) в компонент преобразования синтаксиса (Stratego) [12]. Полученные правила образуют абстрактное представление, объединяя конкретные фрагменты синтаксиса, разделители и отформатированные подэлементы. Данное промежуточное представление позволят получить программу на объектном языке программирования с помощью интерпретатора Stratego или компилятора Java.

Данная платформа обладает следующими преимуществами:

1. Наличие компилятора и интерпретатора для выполнения написанной программы.

2. Возможность расширения грамматики языка.

3. Наличие интеллектуального редактора кода.

4. Возможность выполнения вертикальных трансформаций.

Из недостатков можно отметить:

1. Отсутствие возможности выполнения горизонтальных трансформаций (модель-модель).

2. Отсутствие автоматического динамического изменения сгенерированного программного кода при изменении метамоделей.

Результаты сравнительного анализа широко распространенных языковых инструментариев приведены в таблице 1.1.

Таблица 1.1. Сравнительный анализ языковых инструментариев

Критерий сравнения	OpenArchitectureWare	JetBrains MPS	IDE Meta-Tooling Platform	MontiCore	Spoolfax
Средства описания абстрактного синтаксиса	Ecore-модель	Синтакси-ческое дерево	LPG	Синтакси-ческое дерево	SDF3, Stratego
Наличие возможности создания собственного метаязыка или изменения существующего	+	+	+	+	+
Наличие возможности расширения DSL без перегенерации кода редактора языка	-	-	-	+	-
Наличие возможности выполнения горизонтальных трансформаций	-	+	-	-	-
Отсутствие избыточной функциональности	-	-	-	-	-



Глава 2. Описание метода создания текстовых предметно_ориентированных языков

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

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

Рисунок 2.1. Иерархия моделей в MDD

Таким образом, важно определить метаязык, на основе которого будет выполняться построение текстового DSL. Он должен включать определенные терминальные символы, которые, с одной стороны, должны быть лаконичны, понятны пользователю, а с другой стороны, позволять описывать различные метамодели индивидуально для каждой предметной области, не ограничивая уровень детализации. Также данный метаязык должен иметь возможность выполнения многоуровневого моделирования с целью проектирования метаязыков и метамоделей.

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

Все функциональные требования были формализованы с помощью диаграммы прецедентов UML (см. прил. А), а взаимосвязь объектов системы, детализация сценариев ее использования описана в диаграммах последовательностей (см. прил. Б).

2.1 Расчет трудоемкости разработки компонента проверки синтаксиса

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

В данной работе используется методика CETIN [3] для оценки трудоемкости создания компонента проверки синтаксиса, поскольку ее применение возможно на ранних этапах процесса разработки, кроме того она позволяет выполнить учет как функциональных, так и нефункциональных требованийза счет универсального механизма определения размера проекта с возможностью использования данных, полученных из UML диаграмм.

Первым этапом выбранного подхода является оценка функционального размера системы, представленная следующим тождеством (1):

(1)

Каждый из параметров данного выражения можно оценить, оперируя построенными диаграммами UML, а также другими документами, представляющими модель разрабатываемого компонента. Результат выполнения данного шага и расшифровки отдельных показателей представлены в таблице (табл. 2.1):

Параметр	Описание	Источник данных	Результат оценки
C	Количество неодинаковых функциональных возможностей (вариантов использования) для всех акторов системы	Диаграмма прецедентов (см. прил. А)	11
E	Количество уникальных типов объектов предметной области, которые участвуют в реализации вариантов использования системы	Диаграмма классов (см. прил. В)	18
T	Количество свойств типов объектов предметной области, необходимые для реализации вариантов использования	Диаграмма классов	51
I	Количество уникальных связей между всеми типами объектов	Таблица взаимодействия классов (см. прил. Г)	33
N	Количество типов процессов, участвующих в функционировании разрабатываемой системы		1

Количество связей между типами объектов (I) представляет собой сумму значений в бинарной таблице, где 1 обозначает наличие взаимодействия, а 0 - его отсутствие (см. прил. Г).

Следующим этапом является расчет базовой трудоемкости реализации системы по формуле (2), базирующийся на оценке трудоемкости каждого из шести процессов разработки методологии RUP (табл. 2.2).

(2)

где (параметр) - нормативный коэффициент трудоемкости (см. прил. Д).

Таблица 2.2. Расчет базовой трудоемкости

Процесс	Формула	Результат (чел.-мес.)
Бизнес моделирование		7,56
Управление требованиями		5,50
Проектирование		20,76
Реализация		20,20
Тестирование		5,93
Развертывание		0,50

Далее выполняется расчет поправочных коэффициентов, который позволяет скорректировать базовую трудоемкость по процессу в соответствии с требованиями предметной области. Значения частных поправочных коэффициентов представлены в приложении Д, а результирующие общие коэффициенты для каждого процесса приведены в таблице 2.3.

Таблица 2.3. Расчет общих поправочных коэффициентов

Процесс	Формула	Результат (чел.-мес.)
Бизнес моделирование (КП1)	К11·К16·К17	1,02
Управление требованиями (КП2)	К1·К2·К4·К5·К6·К7·К8·К9·К16·К17·К18	0,66
Проектирование (КП3)	К1·К2·К4·К5·К6·К7·К8·К9·К11·К12·К13· К14·К15 К16·К17·К18	0,63
Реализация (КП4)	К1·К2·К4·К5·К6·К7·К8·К9·К10·К12·К13· К14·К15·К16·К17·К18	0,58
Тестирование (КП5)	К1·К2·К4·К5·К6·К7·К8·К9·К10·К11·К12· К13·К14·К15·К16·К17·К18	0,62
Развертывание (КП6)	К1·К2·К11·К16 К18	0,87

После определения общих поправочных коэффициентов выполняется расчет трудоемкости разработки по следующей формуле (3):

(3)

где - поправочный коэффициент соответствующего процесса (см. прил. Е).

В данном случае трудоемкость разработки составит сорок человека-месяцев. Для определения срока реализации системы необходимо найти среднее арифметическое между максимальным (пять месяцев) и минимальным (два месяца) сроками, полученными из справочной таблицы на основании рассчитанного значения [3]. Таким образом, разработка компонента проверки синтаксиса займет три с половиной месяца.

Примерную стоимость реализации можно определить, как сумму произведений трудоемкости этапа жизненного цикла разработки программного компонента на заработную плату соответствующей роли: аналитика, архитектора, программиста и тестировщика. Анализ данных сервисов [1, 11, 15], аккумулирующих информацию о вакансиях, позволил определить среднюю заработную плату по городу Пермь для каждой проектной роли (табл. 2.4).



Таблица 2.4. Средняя заработная плата по каждой проектной роли

Проектная роль	Средняя оплата месяца работы по городу Пермь (руб.)	Трудоемкость в рамках проекта (чел/мес.)	Срок работы над проектом (мес.)
Бизнес-аналитик	30 000	11,33	1,0
Архитектор	40 000	13,00	1,0
Разработчик C#	45 000	12,04	1,0
Тестировщик	30 000	3,67	0,5

Таким образом, затраты на реализацию компонента системы составят 130 000 рублей. Поскольку коммерциализация проекта в дальнейшем не планируется, в рамках данной работы расчет срока окупаемости не производится.

2.2 Требования к метаязыку

Метаязык представляет собой набор правил, на основе которых строятся различные предметно-ориентированные языки. Создание пользователем DSL делает систему более гибкой, относительно подхода, заключающегося в использовании стандартных метаязыков, за счет возможности самостоятельной настройки метамодели, а затем и модели, что в свою очередь позволяет выполнять многоуровневое моделирование [4].

В рамках курсовой работы в качестве основы для описания метаязыка были выбраны формы Бэкуса-Наура. Однако, некоторые конструкции должны быть включены в разрабатываемый DSL по умолчанию, поскольку они необходимы для проектирования большинства моделей. Поэтому следует расширить стандартный набор конструкций метаязыка списком предопределенных нетерминалов, включающим в себя такие нетерминалы, как буква, цифра, идентификатор и пропуск (рис. 2.2).

Рисунок 2.2. Описание предопределенных нетерминалов

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

2.3 Описание метаязыка

Разработанный в рамках курсовой работы метаязык позволяет описывать правила, имеющие следующую структуру: имя инициализируемого нетерминала в угловых скобках, метасимвол «::=», обозначающий начало области описания, последовательность терминалов, нетерминалов, метасимволов и символ «;», указывающий на окончание правила, поскольку его запись может не ограничиваться одной строкой. В качестве основных конструкций языка используются следующие метасимволы:

1. «{», «}» - указывают на возможность присутствия конструкций языка, заключенных в фигурные скобки, в программе как несколько раз, так и ни разу.

2. «[», «]» - указывают на необязательность присутствия конструкций языка, заключенных в квадратные скобки, в программе.

3. «|» - обозначает альтернативность использования конструкций языка, находящихся по разные стороны от данного метасимвола. Если он используется совместно с метасимволами, указанными в пунктах 1 и 2, то его действие распространяется только на те конструкции языка, которые ими ограниченны.

4. «\» - экранирует метасимволы, позволяя использовать их в качестве терминалов в описании правил языка.

Описанная грамматика принадлежит классу контекстно-свободных, поскольку она содержит один стартовый символ - нетерминал, ее правила имеют вид: , где А - нетерминальный символ, - произвольная последовательность терминалов и нетерминалов, также существует конечный вывод слов, порождаемых данной грамматикой из стартового символа.

2.4 Алгоритмы разбора грамматики DSL

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

Таким образом, разбор начинается с левой части первого корректного правила, описываемый нетерминал которого добавляется в список поддеревьев, изначально содержащий только предопределенные нетерминалы и их определения. Далее анализируется правая часть, где все нетерминалы образуют узлы, а терминалы и метасимволы - листья. Если в правой части какого-либо правила встречается еще неопределенный нетерминал, он добавляется в список поддеревьев в качестве корневого элемента. При переопределении пользователем стандартных конструкций языка, поддерево для соответствующего нетерминала перестраивается относительно нового описания. Разбор продолжается до тех пор, пока не будет разобрано последнее корректное правило метамодели.

Завершающим этапом построения дерева разбора является определение его корневого элемента, стартового символа грамматики. В качестве корня принимается нетерминал, который не встречается в описании ни одного из нетерминалов метамодели, то есть он не попадает в множество узлов никакого поддерева.

Метамодель может содержать следующие семантические ошибки:

1. Наличие нескольких корней дерева разбора.

2. Отсутствие корня в дереве.

3. Неоднократное описание нетерминала.

4. Рекурсивное описание нетерминала, то есть определение его через самого себя.

Рассмотрим пример построения дерева синтаксического разбора для заданного языка (рис. 2.3). В данном дереве окружностями с непрерывной линией обозначены нетерминалы, с пунктирной линией - терминалы, а со штрих пунктирной - метасимволы. Корневые элементы каждого поддерева выделены жирной линией, стартовый символ всего языка представлен окружностью с двойной линией.

Рисунок 2.3. Язык для построения дерева разбора

Изначально в списке поддеревьев содержатся предопределенные нетерминалы (цифра, буква, идентификатор (идент.), пропуск) и их описание. Далее в качестве корневого элемента нового поддерева добавляется нетерминал «Адресная книга» (АК) и его описание в виде узлов: метасимволы «{», «}», «;». нетерминал «Адресная запись» (АЗ) (см. рис. 2.4).

Размещено на http://www.allbest.ru/

Рисунок 2.4. Дерево разбора - добавление первого правила

После чего запускается поиск корневого элемента для нетерминала левой части рассматриваемого правила («Адресная запись») во всех поддеревьях. Поскольку описание для данной конструкции еще не было введено, создается новое поддерево с нулевым количеством потомков и признаком наличия ссылки на нетерминал в правой части первого правила (рис. 2.5).

Размещено на http://www.allbest.ru/

Рисунок 2.5. Дерево разбора - добавление ссылки на нетерминал первого правила

Разбор следующего правила начинается с поиска описываемого нетерминала во всех поддеревьях в виде корневого элемента. Так как данный узел уже был определен на предыдущем шаге, создаются только его потомки аналогично тому, как это было сделано для первого правила (см. рис. 2.6).

Размещено на http://www.allbest.ru/

Рисунок 2.6. Дерево разбора - добавление второго правила

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

По завершении разбора метамодели итоговый список поддеревьев включает в себя одинадцать объектов (см. рис. 2.7).

Далее выполняется поиск корневого элемента, при этом анализируются признаки наличия ссылок, которые были проставлены при разборе правил, в результате чего в качестве стартового символа языка принимается нетерминал «Адресная книга».

Размещено на http://www.allbest.ru/

Рисунок 2.7. Дерево разбора - результат

2.5 Алгоритм проверки синтаксиса модели

После успешного создания предметно-ориентированного языка строится программа на его основе. Модель считается корректно спроектированной, если она полностью удовлетворяет требованиям, предъявленным к метамодели в виде описанных правил. Динамическая проверка программы позволяет повысить эффективность работы пользователя с языковым инструментарием за счет автоматизации процесса выполнения соотнесения спроектированной метамодели с моделью.

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

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

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

Если возникают ситуации, при которых программа не может представить текущий рассматриваемый символ в качестве ожидаемой конструкции спроектированного языка, она возвращается к определенному фрагменту программы по следующим правилам:

1. Для группы альтернатив с опционной возможностью выбора конструкций внутри нее анализатор возвращается к стартовому символу - символу, следующему за последней корректно разобранной конструкцией, предшествующей данной группе, и рассматривает его, как одну из альтернатив внутри группы.

1.1. Если конструкция программы не может быть интерпретирована как одна из альтернатив, анализатор возвращается на предыдущий уровень и анализирует символ, следующий за рассматриваемой группой.

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

1.3. После успешного завершения разбора альтернативы рассматриваемой группы происходит возврат на предыдущий уровень к анализу следующего символа. Если в какой-то момент символ программы не может быть интерпретирован как конструкция языка, анализатор возвращается к стартовому символу и выполняет шаги, описанные в пункте 1.2 настоящего списка.

2. Для группы с возможностью множественного присутствия конструкций в тексте языка анализатор выполняет действия аналогичные пункту 1 с той лишь разницей, что после успешного завершения разбора одной из альтернатив, он переходит к началу группы и пытается представить текущий рассматриваемый символ, как одну из альтернатив.

2.1. Если на каком-либо этапе анализа невозможно представить текущую лексему как ожидаемую конструкцию языка, анализатор возвращается к символу, следующему за N-1 успешно разобранной альтернативой группы, где N общее количество корректно сопоставленных альтернатив с конструкциями программы, и ищет другой вариант разбора текста программы по алгоритму, описанному в пункте 2.

2.2. При появлении ошибки компиляции для последней примененной альтернативы устанавливается статус «Некорректно», количество успешно примененных альтернатив (N) уменьшается на 1, и на следующей итерации разбора программы данная альтернатива исключается из списка возможных вариантов интерпретации текста модели.

Если описание нетерминала содержит метасимвол, определяющий альтернативность применения конструкций языка («|») без использования группировки, данное правило интерпретируется как группа альтернатив, и ее анализ выполняется в соответствие с описанным алгоритмом.

Разбор считается успешным при одновременном завершении анализа дерева разбора и текста программы.

1. Если цепочка терминалов стартового символа языка завершилась, а текст программы до конца не разобран, или рассмотрены все возможные варианты представления конструкций модели, и ни один из них не позволяет корректно проанализировать программу, то последняя, наиболее продвинувшаяся в разборе строка считается ошибочной.

2. В случае окончания текста программы при незавершенном разборе строки терминалов, выводимых из стартового символа, в качестве ошибочно принимается последняя непустая строка текста модели.

Рассмотрим пример выполнения проверки синтаксиса модели (Иванов Иван Россия Пермский край;), построенной на основе метамодели, приведенной ранее (см. раздел 2.4).

Разбор начинается с первого символа модели («Иванов»), параллельно выполняется обход по построенному дереву (со стартового нетерминала «Адресная книга») (см. рис. 2.7). В качестве ожидаемых символов выступают терминалы, составляющие описание предопределенного нетерминала «Идентификатор», который в свою очередь является дочерним узлом по отношению к элементам дерева разбора «Адресная книга» и «Адресная запись». синтаксис языковой инструментарий программный

Однако поскольку нетерминал «Адресная запись» представляет собой группу альтернатив, стартовые символы которой являются одинаковыми, анализатор пытается выполнить разбор правила по первому из вариантов. Таким образом, соответствие первых двух лексем конструкциям языка представлено на рисунке (см. рис. 2.8).

Далее анализатор возвращается к родительскому нетерминалу «Адресная книга», который в описании содержит группу с возможностью неоднократного присутствия конструкций языка, и вновь переходит к дочерним узлам нетерминала «Адресная запись», продолжая разбор программы по первой альтернативе, аналогично предыдущим двум лексемам.

Данные шаги повторяются до того момента, пока в строке модели не встретится терминал «;», поскольку ожидаемым символом является пропуск, что не соответствует текущей рассматриваемой лексеме. Поэтому данный вариант разбора признается некорректным (рис. 2.9).

Размещено на http://www.allbest.ru/

Рисунок 2.8. Проверка синтаксиса модели - разбор первых двух лексем

Анализатор возвращается к самой первой группе (лексема модели «Иванов») и пытается выполнить разбор по второй альтернативе. Одновременное завершение анализа текста модели и конструкций синтаксического дерева определяет успешность последнего варианта, строка разбора (разметка текста) которого выглядит следующим образом: <Фамилия><Имя><Страна><Область>.

Размещено на http://www.allbest.ru/

Рисунок 2.9. Проверка синтаксиса модели - повторная ошибка компиляции

2.6 Алгоритм формирования списка подсказок

Помимо анализа соответствия модели правилам метамодели, выполнения разметки текста языка и программы, возможность формирования списка подсказок для написания программы также способствует более эффективному использованию языкового инструментария пользователями за счет сокращения возможного числа синтаксических ошибок.

Составление списка терминалов и метасимволов выполняется на этапе разбора метамодели, для того чтобы не выполнять анализ правил языка повторно. Для каждого типа конструкции метаязыка строится собственное меню, формирование которого осуществляется следующим образом:

...