Введение в DSL. Проблематика проектирования и кодирования

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

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

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

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

Однако при использовании классического подхода к разработке возникают проблемы, описанные под хабракатом:

1. Недостаток прозрачности. В любой момент времени сложно сказать, в каком состоянии находится проект и каков процент его завершения. Данная проблема возникает при недостаточном планировании структуры (или архитектуры) будущего программного продукта, что чаще всего является следствием отсутствия достаточного финансирования проекта либо низкой квалификации разработчиков.
2. Недостаток контроля. Без точной оценки процесса разработки срываются графики выполнения работ и превышаются установленные бюджеты. Сложно оценить объем выполненной и оставшейся работы. Данная проблема возникает на этапе, когда проект, завершённый более, чем на половину, продолжает разрабатываться после дополнительного финансирования без оценки степени завершённости проекта.
3. Недостаток мониторинга. Проблемы, связанные с невозможностью наблюдения за ходом развития проекта, не позволяют контролировать ход разработки в реальном времени. С помощью инструментальных средств менеджеры проектов принимают решения на основе данных, поступающих в реальном времени. Данная проблема возникает в условиях, когда стоимость обучения менеджмента владению инструментальными средствами сравнима со стоимостью разработки самой программы.
4. Неконтролируемые изменения. У заказчика постоянно возникают новые идеи относительно разрабатываемого программного обеспечения. Влияние изменений может сильно изменить архитектуру разрабатываемого проекта, поэтому важно оценивать предлагаемые изменения и реализовывать только одобренные, контролируя этот процесс с помощью программных средств. Данная проблема возникает вследствие нежелания конечного потребителя использовать те или иные программные среды. Например, когда при создании клиент-серверной системы потребитель предъявляет требования не только к операционной системе на компьютерах-клиентах, но и на компьютере-сервере.
5. Недостаточная надежность. Самый сложный процесс — поиск и исправление ошибок в программах на ЭВМ. Поскольку число ошибок в программах заранее неизвестно, то заранее неизвестна и продолжительность отладки программ и отсутствие гарантий отсутствия ошибок в программах. Следует отметить, что привлечение доказательного подхода к проектированию ПО позволяет обнаружить ошибки в программе до её выполнения. Профессор Вирт при разработке Паскаля и Оберона за счет строгости их синтаксиса добился математической доказуемости завершаемости и правильности программ, написанной на этих языках. Особенно крупный вклад в дисциплину программирования внёс Дональд Кнут. Его четырёхтомник «Искусство программирования» является необходимой для каждого серьезного программиста книгой.
6. Отсутствие гарантий качества и надежности программ из-за невозможности обеспечить отсутствие ошибок в программных продуктах вплоть до формальной сдачи программ заказчикам.

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

1. Систематическое многократное использование. Наиболее важным подходом является выделение семейств продуктов, составляющие которых варьируются. На основе этих семейств разрабатываются линейки продуктов. Продукты, разработанные как компоненты семейств, повторно используют требования, архитектуру, каркасы, компоненты, тексты и т.д.
2. Автоматизация сборки. Облегчает сборку независимо разработанных компонентов. При автоматизации сборки появляется еще ряд нововведений:
   
• независимые от платформ протоколы;
• автоописание (снижает архитектурные несоответствия на основании контракта и спецификации);
• отложенная инкапсуляция (снижает уровень архитектурных несоответствий за счет вплетения адаптаций в опубликованные компоненты);
• разработка, управляемая архитектурой (на основе архитектуры ПО можно делать предложения о его эксплуатационных качествах).




3. Разработка, управляемая моделями (Model Driven Development — MDD). В данном подходе предлагается использование модели, как исходного кода, а не как документации. Для этого модель должна быть точной, а точный язык моделирования должен быть спроектирован для специфической цели. Язык моделирования – система, созданная для спецификации основанных на моделях программ. Она повышает уровень абстракции и переводит реализацию в словарь предметной области.
   

Технологии моделирования знаний о предметной области

Application Programming Interface (API) — группа системных сервисов, ориентированных на решение общих задач.

Компонентные технологии – набор программных модулей с стандартизированным интерфейсом, ориентированных на решение общих задач.

Архитектурные паттерны — проектные решения, описывающие архитектуру программной системы на основе некоторой концепции.

Шаблоны GoF — проектные решения, которые описывают аспекты реализации программной системы для решения определенных задач программирования.

Языки на основе XML — структурированное описание некоторых данных и механизмов преобразования.

SQL — язык структурированных запросов к СУБД.

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

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

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

• внутренний DSL (internal DSL);
• внешний DSL (external DSL) — это DSL, который написан на языке, отличающемся от основного языка программного приложения;
• интегрированная среда разработки DSL (Language Workbench).

Три основных типа DSL

Внешний DSL использует отдельные от основного синтаксиса конструкции, близкие к естественному языку. Требует наличия внешнего компилятора, интерпретатора или постпроцессора, в связи с чем исполняется на этапе компиляции, в отличие от внутреннего DSL. Внешний DSL часто использует специальные языки, но во многих общих случаях используются теги, которые берутся из синтаксиса других языков, например, XML, как общей альтернативы. Традиционно в Unix-системах используется стиль «небольших языков» (little languages). Одними из первых примеров внешнего DSL были регулярные выражения, SQL, awk и XML, которые использовались в системах подобных Struts и Hibernate. Наибольший плюс внешних DSL состоит в том, что их можно писать так, как пожелает разработчик. Другими словами, можно выразить предметную область в простейшей и доступной для чтения и редактирования форме. Формат такого DSL будет ограничен лишь умением создавать транслятор, который сможет считать конфигурационный файл и выдать некоторое выполняемый код на основном языке приложения. Отсюда же следует и основной недостаток внешних DSL — необходимость в создании непосредственно транслятора.

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

Интегрированная среда разработки (Integrated Development Environment — IDE) – это инструмент для создания DSL. Он предоставляет возможности редактора и генератора для определения абстрактного синтаксиса языка, подобно современным IDE по разработке программ.

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

Обобщенный алгоритм разработки нового DSL состоит в следующем:

1. Определить синтаксис в терминах языка реализации
2. Использовать паттерны DSL для реализации нового DSL
3. Использовать средства метапрограммирования для реализации DSL в рамках исходного языка

Использование DSL имеет также ряд преимуществ:

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

К недостаткам использования относят следующее:

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

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