Введение в DSL. Часть 1 — Проблематика проектирования и кодирования

    На протяжении нескольких десятилетий стоит задача поиска повторяемого, предсказуемого процесса или методологии, которая бы улучшила продуктивность, качество и надежность разработки. Одни пытались систематизировать и формализовать этот, по-видимому, непредсказуемый процесс. Другие применяли к нему методы управления проектами и методы программной инженерии. Третьи считали, что без постоянного контроля со стороны заказчика разработка ПО выходит из-под контроля, что влечет за собой увеличение временных и финансовых затрат.
    Информатика как научная дисциплина предлагает и использует на базе методов структурного программирования технологию надежной разработки программного обеспечения, используя тестирование программ и их верификацию на основе методов доказательного программирования для систематического анализа правильности алгоритмов и разработки программ без алгоритмических ошибок.
    Данная методология направлена на решение задач на ЭВМ, аналогичной технологии разработки алгоритмов и программ, используемой на олимпиадах по программированию отечественными студентами и программистами с использованием тестирования и структурного псевдокода для документирования программ в корпорации 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 и конструкциями языка программирования общего назначения.


    На этом первая (вводная) часть заканчивается.
    Спасибо тем, кто дочитал до конца, хотелось бы услышать ваше мнение по поводу проблематики проектирования в целом и языков описания предметных областей в частности как одного из вариантов решения возникающих трудностей.
    Поделиться публикацией
    Комментарии 27
      +1
      Хорошая статья, но местами слишком быстро, не хватает примеров. Те что есть попали в точку, но может их немного деталировать, чтобы читателю не приходилось долго соображать выстраивая связи. Например почему Регулярные выражения и XML являются внешними DSL.

      Надеюсь увидеть в следущих статьях:
      1. Один или Два конкретных примера,
      2. Теорию или просто ваши соображения о том как же выявить части проекта, которые желательно вынести в DSL,
      3. Теорию или ваши соображения о этапах разработки своих DSL,
      4. Инструменты позволяющие работать со своими DSL.

      Спасибо!
        0
        Спасибо.
        Все это будет, я выношу на обсуждение по частям записку диплома магистра по ИТ. Тема как раз «Исследование информационных технологий для создания языков описания предметной области»
        Впереди и примеры, и матмодель, и тулзы, и описание выбора их и т.д.
          0
          Я бы, на самом деле, предпочёл бы начать с конца. Т.е. для решения какой задачи вы решили применить DSL, как оцениваете результат данного применения (например: всё замечательно, буду везде сам применять и другим рекомендую или теория хорошая, но инструменты разработки ещё в процессе). Ну, и собственно список тулзов.

          А после статьи с таким содержанием народ сам вам в комментариях напишет, про что ещё рассказать.
        +1
        В нашей предметной области определён некий язык для описания устройств. На базе него мы сделали свой DSL, компилируемый. Сделали хорошо — разработка пошла куда быстрее. Учить там нечего — спецификация на пятидесяти страницах. По опыту, основная трудность с DSL возникает у людей, привыкших часто менять работу не вникая в предметную область. Многие уж лучше напишут кучу строк на языке общего назначения чем будут учить что-то, что не пригодится на следующей работе.
          +1
          вот тут твердый плюс, не могу не согласиться, инертность — основная проблема зачастую, к сожалению
          +1
          Тема интересная, но написано уж очень сухо.
            –1
            да чел видимо просто решил своим курсовиком похвастаться. куча высосанных из пальца слов и ни одного по делу.
              0
              Аргументируйте.

              З.Ы. В конце статьи (если вы ее читали) написано, что это вводная. А в заголовке фигурирует Часть 1
                0
                я имел дурость прочитать =_="
                не надо никаких вводных, выводных, рецензий, объяснительных записок и прочей мурни. есть есть что сказать по делу — так и пиши, нормальным человеческим языком, а не разводи отвлечённые разглагольствования.
            +2
            Читается как фрагмент из диплома. Уж очень информативно и компактно, этот пост можно было бы разбавить примерами и разбить на два-три отдельных поста. Тема очень сложная и глубокая, без примеров «на пальцах» сложно объяснить неподготовленному человеку все прелести DSL.

            Ну и ещё мелкая придирка: я бы не стал DSL называть языком программирования.
              0
              >Ну и ещё мелкая придирка: я бы не стал DSL называть языком программирования.

              Позвольте не согласиться. Так уж получилось что в нашей стране принято алгоритмом называть _последовательность_ действий, приводящих к получению правильного результатая, а программированием — запись алгоритма на одном из ЯП. Но такие определения плохо сочетаются и с MDD и с декларативным программированием. Очень хорошо эту проблему освещал в свое время Нариньяни: www.artint.ru/articles/narin/PARAD-R1.htm
                +1
                Но DSL может быть вовсе не описывать процессы, а описывать, например, структуру данных и ничего больше. Никакой последовательностью действий это не является.
                  0
                  По идее, наиболее точным будет прямой перевод, т.е. «Предметно-ориентированный язык». А вот если добавить ещё programming (DSPL), тогда уже «Предметно-ориентированный язык программирования».
                0
                Это не последний пост, это только начало, но на будущее постараюсь чуть подразбавить академический стиль.

                >Ну и ещё мелкая придирка: я бы не стал DSL называть языком программирования.
                Предметно-ориентированный язык программирования (англ. domain-specific programming language, domain-specific language, DSL) — язык программирования, специально разработанный для решения определённого круга задач, в отличие от языков программирования общего назначения, таких, как Си, или языков моделирования общего назначения наподобие UML, Postscript, SQL и др. (русская вики)

                In software development and domain engineering, a domain-specific language (DSL) is a programming language or specification language dedicated to a particular problem domain, a particular problem representation technique, and/or a particular solution technique. (английская вики)

                Фаулер в DSL-WIP несколько раз приводит пример DSL, как языка, но языка вспомогательного (" You couldn't write a whole application in this language — all you can do is describe one small aspect of an application.")
                  0
                  or specification language
                0
                А вот скажите, пожалуйста, каким образом DSL решает проблемы, описанные вами в самом первом списке («проблемы традиционного подхода»)?
                  +1
                  Видно, что текст писался, чтобы написать, а не чтобы его кто-то понимал.

                  «Онтология — представление любой области знаний или части реального мира, который используется для семантического анализа текстов.». Кто этот «который»? Реальный мир используется для семантического анализа текста? Больше там, вроде, нет слов мужского рода.

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

                  Не получилось у вас полезной статьи, хотя тема действительно интересная.
                    0
                    «Не получилось у вас полезной статьи»
                    А что вы хотите от пояснительной записки диплома?

                    Вообще, автору на заметку: научная работа и статья на хабре — это два разных жанра.
                    0
                    Что-то подобное уже существует в виде связки «UML (архитекторы)» + «генерация кода (программисты)», здесь предлагается более «размазанный» вариант создания приложений. Если UML не всегда себя окупает за счет высокого порога вхождения, то за DSL и подавно не уверен.
                      0
                      >UML не всегда себя окупает за счет высокого порога вхождения
                      Пожалуйста, скажите что вы это так шутите!

                      УМЛ (как и ГОСТ блок-схемы) может читать неподготовленный человек. Факт.

                      ЗЫ а DSL он кагбе не для проектирования. А для того чтоб вместо кучи java/C++ кода писать на своем лаконичном и компактном мета-языке.
                        0
                        1. Читать и понимать — это разные вещи. UML — это немного больше, чем просто структурированный текст.
                        2. На вскидку могу вспомнить JDeveloper, в котором можно «вместо кучи java/C++ кода писать на своем лаконичном и компактном мета-языке», т.е. на UML :)

                          0
                          На UML писать не получится :) Идея о том что UML может что-то заменить ошибочна и провальна, как собственно и идея MDA (Model-Driven Architecture). Не работает это.
                            0
                            Я тоже не знаю и одной успешной реализации проекта, где в качестве основного средства разработки использовался UML. В частности:

                            1. Высокий порог вхождения в UML. Необходимо, чтобы все участники проектирования умели на нем говорить.
                            2. На маленьких проектах UML не выгоден.
                            3. На больших проектах UML теряет необходимую гибкость.

                            Думаю с DSL будет тоже самое.
                              0
                              UML — это проектирование
                              DSL — реализация.

                              Вы путаете мух с котлетами
                                0
                                Я уже приводил пример с JDeveloper. Там есть возможность из UML генерировать сразу Java-код (J2EE). Чем не реализация?
                                Затем и нужны различные абстракции типа DSL, чтобы стереть грань между проектированием и реализацией, точнее чтобы реализация была максимально автоматизирована.
                      0
                      Качество статьи, мягко говоря, невысокое. Много откровенно не относящегося к делу текста. Часть информации относящейся к делу является косметически-подправленной цитатой с википедии, при этом без ссылки на первоисточник (статья в википедии). Статья содержит множество деклараций без аргументации.

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

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

                    Самое читаемое