О доменных языках
В отличие от универсального языка, такого как C# или UML, доменный язык (DSL) предназначен для выражения инструкций в определенном пространстве или домене.
Хорошо известный домен DSL включает регулярные выражения и SQL. Каждый домен DSL гораздо лучше, чем универсальный язык для описания операций с текстовыми строками или базами данных, но гораздо хуже для описания идей, находящихся за пределами собственной области. Для отдельных отраслей также предусмотрен собственный домен. Например, в телекоммуникационной отрасли языки описания вызовов широко используются для указания последовательности Штатов в телефонном звонке, а в индустрии авиаперелетов Стандартный DSL используется для описания полетом.
Ваш бизнес и ваш проект также имеют дело с особыми наборами концепций, которые можно описать с помощью DSL. Например, можно определить DSL для одного из следующих приложений:
Планирование путей перехода на веб-сайте.
Схемы подключения для электронных компонентов.
Сети конвейера конвейерных и багажа, обрабатывающие оборудование для аэропорта.
Пользователи вашего DSL создают модели. Модели являются экземплярами DSL. Например, они описывают конкретный веб-сайт или подключение определенного устройства или систему обработки багажа в определенном аэропорту.
пользователи могут просматривать модель в виде диаграммы или формы Windows. Модели также можно просматривать в виде XML, то есть как они хранятся. При определении DSL вы определяете, как экземпляры каждого доменного класса и отношения отображаются на экране пользователя. Обычный DSL отображается как коллекция значков или прямоугольников, Соединенных стрелками.
На следующем рисунке показана небольшая модель в схематическое DSL:
Возможности DSL
Например, можно написать шаблоны, которые принимают план аэропорта и создают часть программного обеспечения для обработки багажа, а также некоторые пользовательские документы, описывающие этот план.
После определения DSL его можно распространить другим пользователям, которые могут установить его на своих компьютерах. Пользователи DSL могут создавать и изменять модели в Visual Studio.
Можно также определить команды меню и другие средства, помогающие пользователям редактировать DSL, ограничения проверки, чтобы обеспечить правильное использование DSL, а также шаблоны элементов, помогающие пользователям создавать новые экземпляры. в качестве интегрированного пакета можно включить один или несколько языков dsl с помощью средств и других расширений Visual Studio.
Как правило, доменный язык создается, когда группа разработчиков должна написать подобный код для нескольких продуктов. Например, компания, специализирующаяся на системах обработки багажа, может определить DSL Track, с помощью которого можно создать некоторый код для каждой установки. Преимущество DSL заключается в том, что они могут быть понятны своим клиентам, что код, созданный из него, надежен и что система может быть быстро обновлена при изменении требований клиентов.
Инструменты доменного языка позволяет создать доменный язык с собственным графическим конструктором и собственной нотацией схемы, а затем использовать этот язык для создания соответствующего исходного кода для каждого проекта.
Разработка Domain-Specific
Разработка для конкретного домена — это процесс определения частей приложений, которые можно моделировать с помощью доменного языка, а затем создание языка и его развертывание разработчикам приложений. Разработчики используют доменный язык для создания моделей, характерных для их приложений, используют модели для создания исходного кода, а затем используют исходный код для разработки приложений.
Аспекты разработки графических Domain-Specific
Графический язык, относящийся к домену, должен включать следующие функции:
Модель предметной области
Интеграция с Visual Studio
Notation
Доменный язык должен иметь достаточно небольшой набор элементов, который можно легко определить и расширить, чтобы представить специфические для домена конструкции. Нотация состоит из фигур, представляющих элементы, и соединителей, которые представляют связи между элементами на графической поверхности диаграммы. В Инструменты доменного языка формы можно расширять и уточнять, чтобы представить элементы доменного языка.
Модель предметной области
Доменный язык должен объединять набор элементов и связи между ними с согласованной грамматикой. Он также должен определять, являются ли сочетания элементов и связей допустимыми. Например, языки программирования обычно предотвращают циклическое наследование, при котором один класс является производным от второго класса, а второй класс является производным от первого класса. Ограничения также можно использовать для выражения бизнес-логики, например, один человек не может быть зависимым от самого себя. Инструменты доменного языка использует ограничения для выражения типов ограничений, требуемых для большинства языков, зависящих от домена.
Создание артефактов
Одной из основных целей доменного языка является создание артефакта, например исходного кода, XML-файла или других полезных данных. Как правило, изменение в модели означает изменение в артефакте. Можно использовать Инструменты доменного языка для создания артефактов и их повторного создания при изменении модели.
Сериализация
Доменный язык должен быть сохранен в определенной форме, которая может быть изменена, сохранена, закрыта и перезагружена. Инструменты доменного языка использует формат XML, который позволяет определить и настроить сериализацию или сохранение доменного языка.
Интеграция с Visual Studio
поскольку Инструменты доменного языка размещается в Visual Studio, он расширяет множество Visual Studioных окон и элементов управления. Он также позволяет настраивать поведение команд меню, элементов панели элементов и других элементов пользовательского интерфейса.
Вы также можете создать адаптер шины модели для конкретного доменного языка. Этот адаптер позволяет ссылаться на модель и элементы в модели и позволяет писать код, который может получать доступ к экземпляру DSL и обновлять его. используя мощный механизм шины модели, можно писать расширения Visual Studio, работающие с несколькими моделями. Кроме того, можно создавать автономные приложения, работающие с моделями. дополнительные сведения см. в разделе интеграция моделей с помощью Visual Studio Modelbus.
Преимущества разработки Domain-Specific
Доменный язык может предоставить следующие преимущества:
Содержит конструкции, точно соответствующие области проблемы.
В отличие от языков общего назначения, доменный язык состоит из элементов и связей, которые непосредственно представляют логику пространства проблем. Например, приложение страхового полиса должно включать элементы для политик и утверждений. Доменный язык упрощает проектирование приложения и поиск и исправление ошибок логики.
Позволяет неразработчикам и людям, не знающим домен, понять общую структуру.
С помощью графического доменного языка можно создать визуальное представление домена, чтобы разработчики, не являющиеся разработчиками, могли легко понять структуру приложения.
Упрощает создание прототипа окончательного приложения.
Разработчики могут использовать код, создаваемый их моделью, для создания приложения-прототипа, которое они могут отображать клиентам.
Процесс разработки Domain-Specific
Большинство команд разработки программного обеспечения, использующих доменные языки, выполняют следующие шаги для создания и использования их моделей:
Команда различает переменные части домена из частей, которые никогда не изменяются.
Разработчики пишут код для фиксированных частей и оставляют точки расширения для переменных частей.
Ведущий разработчик программного обеспечения или архитектор создает доменный язык, включающий шаблоны разработки фиксированных частей домена и точки расширения для переменных частей.
Ведущий разработчик программного обеспечения или архитектор развертывает доменный язык для разработчиков различных приложений, создаваемых группой.
Каждый разработчик создает модель, которая применяется к конкретному приложению.
Сделать сложное простым: что такое DSL, или зачем вам новый язык программирования
Сделать простое иногда во много раз сложнее, чем сложное
© Михаил Калашников
Здравствуйте, меня зовут Владимир Кожаев, я фрилансер-разработчик инструментальных средств (звучит почти как анонимный алкоголик). Этой статьёй я открываю цикл материалов, посвящённый разработке парсеров, трансляторов, компиляторов и тому подобных инструментов, облегчающих жизнь.
Действительно, зачем это нужен ещё один язык программирования? Понятно, он может быть нужен в каких-то НИИ при университетах, но обыкновенному бизнесу — какой толк от этой заумной мути? Вообще к чему столько разных языков, почему бы не использовать один единственный? Давайте разберёмся.
Почему бы не пользоваться одним языком
Жил да был в Великобритании выдающийся математик, логик, криптограф, и звали его Алан Тьюринг. В числе других открытий он придумал машину имени себя. Опуская подробности, скажем, что с помощью этой машины можно реализовать всё то же, что и с помощью любых средств программирования более высокого уровня. То есть любую программу на любом языке можно переписать с помощью этого достаточно простого средства. Тем более на любом языке типа Java или PHP можно реализовать эту самую машину.
Как следствие, существует критерий полноты по Тьюрингу-Чёрчу. Язык называется полным, если на нём можно реализовать машину Тьюринга. Все популярные языки программирования общего назначения (Java, C#, PHP, Python, Scala, JavaScript и так далее) являются полными. Что же это означает? Все популярные языки эквивалентны! Ну вот, смотрите: мы знаем, что все программы можно выполнить с помощью машины. Машину же, которая выполняет, можно написать что на PHP, что на C++. Получается, одну и ту же программу, записав её на языке машины Тьюринга, можно выполнить везде. А мы знаем, что так можно записать вообще любую программу.
На практике это означает, что программу на языке, скажем, JavaScript, поднатужившись, можно переписать на С++. Обратное тоже справедливо. Да, имеют значение библиотеки и фреймворки, но саму логику можно без проблем перенести с одного языка на другой.
Зачем тогда разные языки нужны, почему бы не пользоваться одним? В знаменитом романе Семюэля Дилэни «Вавилон 17» описан человек с выключенной частью мозга. Вместо этого он обучен искусственному языку, близкому по синтаксису к записям математических выражений. Он замечательно подходит для быстрого решения логических задач, компактен и удобен, но ограничен. Например, отсутствовали слова «я» и «ты». Поэтому парадоксы, такие как «Севильский цирюльник», мозг ограниченный «Вавилоном 17», сожжет или заставит обратиться к отключенной части. То есть языковые конструкции во многом определяют способ мышления.
Рассмотрим язык математики более подробно. Вот, например, описание доказательства теорем методом математической индукции:
Расшифровывается это так. Допустим, что:
Тогда все утверждения нашей последовательности верны. Обратите внимание: вместо нескольких строк текста имеем лишь одну строку со строгим определением, понятным любому математику.
Что же такое DSL
Domain Specific Language, или язык предметной области, — это язык, созданный для конкретной области применения. Построение его, или структуры данных, отражают специфику решаемых им задач © Википедия.
То есть, если человек знает свою работу, учить DSL не надо — достаточно взглянуть один раз, и всё понятно (см. пример с математикой). Также хороший DSL не требует больших знаний в теории и практике программирования. Во многих, например, нет циклов. В некоторых — условных операторов (типа «if»). Часто язык является не полным по Тьюрингу, то есть написать любую программу с его помощью нельзя. Опять же, вспомним язык математики или кванторов. Он используется лишь для описания теорем или для их автоматического доказательства. Писать web-сервисы с его помощью было бы затруднительно.
Примеры использования DSL
DSL используются очень по-разному. Рассмотрим несколько из них и постараемся понять, в каком же случае следует их использовать.
Резак лазера
Положим, вы — инженер кораблестроитель и хотите вырезать большущую деталь для корпуса судна. Раньше это делалось так: на плотном картоне или фанере вычерчивали детальки, вырезали, прикладывали к листу стали, и люди, которых называли кернильщиками, ползали по листу и набивали по контуру выкройки впадинки. Дальше газорезчик шёл по контуру и вырезал. Представляете, что будет, если резчик с утра перебрал? А можно сделать это автоматически, чтобы робот считывал чертёж и сам ехал по листу, вырезая нужную деталь? Да, можно! Однако проблема в том, что траекторию его передвижения нужно как-то задать. Мол, поедь туда, опусти резак и дальше двигайся эдаким манером. Для этого нам нужны следующие команды:
Таким образом, в наиболее простом случае нам нужны только три команды:
Как видите, язык очень простой, но с его помощью можно вырезать деталь любой сложности. Для программирования с его помощью достаточно навыков на уровне уверенного использования ПК. Добавив к этому языку переменные, условные операторы, циклы и процедуры, получим очень мощное средство. Как бонус — исследование кода методом белого ящика. К примеру, можно проверить, не вылезает ли наш резак за пределы листа металла.
Алгоритмический трейдинг
Трейдер редко ошибается дважды — обычно раза три или больше
© Из грустного опыта продавшего квартиру
Каждый хочет купить дешевле и продать дороже — вроде бы понятно. Но как определить правильное время для сделки, если завтра цена может вырасти или упасть? Решение принимается с помощью фундаментального (новости, анализ экономических и политических событий) и технического (экстраполяция стоимости ресурса на основании предыдущих данных). Признаки, по которым судят о поведении цены, теоретически не доказаны и не точны. То есть какая то связь с реальностью усматривается, но обычно берут несколько признаков и принимают решение о закрытии или открытии сделки, когда сигнал о покупке либо продаже подают все используемые индикаторы.
Кривая цены меняется очень быстро. Данные, полученные 15 минут назад, как правило, интересны только для историков. Деньги на бирже крутятся большие, так что потерять несколько сот миллионов долларов за минуту можно запросто. Поэтому человеческий фактор хорошо бы свести к минимуму. Но как это сделать, если общей теории поведения цены не существует и стратегии торговли трейдер выбирает их с помощью интуиции? Один из способов уберечься от ошибки — создать специальный язык с минимумом «шума». Оставить в языке только необходимое, безжалостно избавясь от возможностей, которые нам не нужны. Что же нужно для трейдинга?
Давайте посмотрим, как будет выглядеть эта стратегия на языке Java. Допустим, мы хотим получить сигналы о покупке/продаже валют на серверах трех бирж с помощью стратегий: «фибоначчи», «скользящее среднее», «преобразование Гильберта». Для простоты будем считать, что время измеряется в тиках, название биржи, на которой работает сервер, задается просто строкой, и торгуем мы валютами — меняем доллары, евро или ещё что-нибудь на украинскую гривню и обратно.
На первый взгляд, код выглядит хорошо, но, если приглядеться, в нём полно ошибок.
Во первых, время работы стратегий меньше, чем время, в течение которого работает сервер. Во вторых, мы запускаем только один сервер, вместо трёх. Так что с этим кодом материальные потери не заставят себя долго ждать.
С другой стороны, трейдинг — это постоянный стресс и гонка. Работать нужно действительно быстро, но без ошибок. Как же быть?
Давайте посмотрим, как мог бы выглядеть текст программы, представленной выше, записанный на действительно удобном языке.
Сверху маркер начала программы, дальше идёт список серверов. У каждого сервера один раз задается название биржи, с которой происходит работа, и время его работы. Дальше идёт список стратегий, каждая с специфическими параметрами.
Преимущества предложенного примера очевидны. Во первых, текст стал лаконичным: сервера указываются ровно один раз. Стратегии — в непосредственной близости от сервера, на котором запускаются. Во вторых, мы избавляемся от ненужных подробностей. Трейдеру вовсе и не нужно знать, что такое Thread или что итоговая программа будет написана на языке Java.
Разработка игровой логики
Ошибка: робот погибает при попадании в него гранаты (именно от попадания, а не от взрыва). Д — дизайнер, П — программист.
Д: программисты всё сломали! почему так получается?!
П: естественно, так получается! потому, что у гранаты масса 100 кг! зачем вы это сделали?
Д: да?! а чтобы граната в воде тонула!
П: а почему она с нормальной массой не тонет?
Д: а потому что у воды плотность большая! (прим.: больше, чем у ртути)
П: а почему плотность такая большая?!
Д: а чтобы ящики деревянные плавали!
П: а почему они иначе не плавают?!
Д: а потому что у них масса 50 кг!
П: а зачем такая масса?!
Д: а иначе они некрасиво разваливаются!
Более того, игры сейчас выходят на множестве разных платформ. Выпустили под Windows, и надо выходить на Vii, на планшетах, на smart TV и так далее. Каждый релиз приводит к переписыванию кода, который уже работает и оттестирован, хотя логика действий персонажей не меняется при переходе от устройству к устройству. Можно, конечно, использовать кроссплатформенные средства. Такие как Unity, или Haxe, но, как правило, проблема в том, что кроссплатформа работает одинаково плохо на всех устройствах. То есть хотелось бы сделать так, чтобы разрабатывать заново нужно было только специфические для конкретной платформы вещи, оставив логику без изменений.
Можно ещё использовать для логики скриптовые языки, однако даже они слишком сложны для того, чтобы использовать их без изучения. Там много подробностей, нужных для программиста, но лишних для конструкций: «Если произошло это — сделай то».
Что же делать, учить дизайнера программированию? Но это две довольно разные и в каком-то смысле противоположные специальности. Хотелось бы сделать так, чтобы дизайнер достаточно простым способом без помощи программиста мог поменять поведение персонажей.
Конечный автомат
Представим игровую логику в виде состояний персонажа и переходов между ними. К примеру, у робота может быть три состояния: «бежать к игроку», «стрелять» и «искать патроны», когда они кончились. Действия происходят при входе в состояние, выходе из него, переходе от одного состояния в другое и когда состояние между через определенный метод времени не изменилось. Можно описать состояния и переходы с помощью JSON, или XML и потом воспользоваться шаблоном проектирования «машина состояний», как это описано в банде четырёх. XML для описания представлен ниже:
Но XML очень не удобен для программирования. Покажем, как это описать с помощью DSL-языка.
Как видите, описание стало гораздо более лаконичным и удобочитаемым. Появилась подсветка синтаксиса. Скажу вам по секрету, автокомплит и подсветка ошибок тоже есть.
Таким образом, можно отделять игровую логику от платформозависимых вещей: графики, ввода-вывода, управления и даже от того, как методы «стрелять», «бежать» и «кричать» реализованы на практике. Последнее является частным случаем декларативного программирования: вместо того, чтобы реализовывать детальный алгоритм, мы описываем конечный результат. Вместо того, чтобы говорить компьютеру как делать, мы говорим что.
Выводы
Все рассмотренные DSL:
DSL применяется, когда необходимо записать достаточно сложную логику и избавить специалиста в определённом домене от необходимости изучать программирование, а программиста — разбираться в предмете. Обратно, если для реализации задачи не нужно обладать квалификацией помимо собственно программирования, DSL вам не нужен.
Вторая статья будет посвящена графическим языкам программирования, последующие — способам реализовать DSL и применениям их в разных, иногда неожиданных областях.
Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті.
Разработка приложений на основе DSL и генерации кода
О чем вообще речь
Что такое DSL (Domain Specific Language) и кодогенерация
DSL — это язык, специфичный для конкретной доменной области. Т.е. это язык, который оперирует понятиями данной области напрямую. Обычно противопоставляется языкам общего назначения. В принципе ничто не мешает быть языку быть просто формальным синтаксисом, никак не интерпретируемым компьютером, но пользы от такого языка не очень много. Компьютерный язык обычно подразумевает обработку каким-либо образом, поэтому к DSL неплохо бы иметь какой-нибудь интерпретатор. Соответственно есть два стандартных подхода — интерпретация и компиляция. С интерпретацией более-менее ясно, а с компиляцией история следующая. Можно конечно транслировать сразу в инструкции процессора или на худой конец в ассемблер, но зачем, если можно «писать» нормальный код, в смысле компилировать в текст высокоуровневого языка, который потом преобразуется своим компилятором в нечто, запускаемое не компьютере. Поэтому чаще и говорят «кодогенерация», а не компиляция, хотя последний термин тоже корректен и используется.
Производительность труда
Если взять разработку приложений, то главной проблемой я считаю низкую производительность, т.е. «количество продукта» на затраченные усилия. В принципе похожая проблема встречается во всех отраслях промышленности, и есть как общие методы решения, так и специфичные. У нас есть много разных вещей для поднятия этой самой производительности — высокоуровневые языки, мощные IDE, continious integration tools, scrum, canban, coffee points, coffee ladies и много чего еще. Но тем не менее разработка продуктов занимает кучу времени. Особенно это заметно, когда то, что нужно сделать можно легко описать словами за несколько минут, а сделать — занимает недели. Существенный разрыв между «что» и «как». «Что делать» — просто и понятно, «как делать» — просто, понятно, но долго. Я хочу сделать «как» — быстро, а в идеале вообще не делать. Короче, декларативный подход.
Уровни абстракции
Есть очень полезное понятие — уровень абстракции. Оно помогает структурировать приложения. Допустим у нас есть приложение для некоторой предметной области. С одной стороны (вверху) есть понятия из этой предметной области, которые так или иначе будут фигурировать в приложении, с другой стороны есть язык программирования общего назначения (внизу), в котором есть байты, типы, методы и тому подобные элементы, не имеющие ничего общего с предметной областью (не будем спускаться ниже до операционной системы, электрических импульсов, транзисторов, молекул, атомов, протонов, кварков. ). Работа программиста как раз и состоит в том чтобы увязать эти два слоя или заполнить область на картинке (левая картинка). Если приложение большое и доменная область достаточно «далеко», то в приложении возникают различные промежуточные уровни абстракции, иначе можно не совладать со сложностью (правая картинка). 
Уровни, конечно, возникают, но возникают они логически. И надо прикладывать определенные усилия, чтобы код тоже поддерживал уровни. Это особенно сложно, если язык один и все запущено в одном процессе. Ведь ничто не мешает вызвать метод из уровня 1 на уровне 3. Да и функции или классы обычно не маркируются уровнем абстракции. Что нам по этому поводу предлагает DSL с кодогеном? Нам по-прежнему надо заполнить ту же область. Соответственно, верхнюю часть заполняем нашим языком, а нижнюю сгенерированным кодом:
В отличие от предыдущего примера уровень здесь непроницаем, т.е. из генерированного кода нельзя вызвать инструкции DSL (особенно если их там нет). Не будем рассматривать случаи, когда генератор делает код на том же DSL… Еще один важный момент здесь — это то, что generated code можно рассматривать как скомпилированный, в том смысле, что он создается автоматически и смотреть в него незачем. При условии, что генератор уже написан (и хорошо протестирован). Т.е. написав язык и генератор к нему можно значительно сузить область приложения. Это особенно ценно при разработке нескольких приложений в этой сфере или при постоянном изменении одного.
Управление «усложнением»
Давайте представим себе ситуацию, которая, как мне кажется, встречается довольно часто. Допустим вы получаете заказ на разработку некоторой системы. Вам приносят идеальную спецификацию и вы придумываете идеальную архитектуру системы где все прекрасно, компоненты, интерфейсы. инкапсуляция и много других не менее прекрасных паттернов. Возьмем конкретный пример — интернет-магазин велосипедов. Вы написали согласно спецификации интернет-магазин и все счастливы. Магазин процветает и задумывается о расширении бизнеса, а именно начать еще торговать скутерами и мотоциклами. И вот они приходят к вам и просят доработать магазин. У вас была прекрасная архитектура, заточенная на велосипеды, но теперь надо перетачивать. С одной стороны скутеры и мотоциклы похожи на велосипеды, и у тех и у тех есть запчасти, аксессуары, сопутствующие товары, но есть и различия.
Система в целом остается такой же, но часть функций должна поддерживать еще новые типы объектов, или должны появиться отдельные функции для новых типов объектов.
Произошло усложнение доменной области, т.е. вместо только велосипедов теперь надо поддерживать велосипеды, скутеры и мотоциклы. Наша системы тоже должна быть усложнена. Я думаю, что в общем случае сложность программной системы соответствует сложности моделируемой системы. При этом существуют минимально возможный уровень сложности при котором все еще можно решить задачу. (Верхнего уровня не существует — можно придумать бесконечно сложное решение для любой проблемы). Я считаю, что надо стремиться к минимальному уровню сложности, так как из всех возможных решений самое простое — самое лучшее. Короче, код должен быть простым.
Вернемся к нашему интернет-магазину. Пусть есть некая функция, которая написана для велосипеда. Теперь она должна работать и для новых типов.
public void process(Bicycle b) <
genericCode
specificForBicycle
>
для этого должен быть specificForMotobike код внутри. Какие есть варианты решения?
Copy/paste
public void process(Motobike b) <
genericCode
specificForMotobike
>
Скопировали метод, заменили специфичный для типа код и все. Просто, но есть проблема. Если надо менять genericCode, то надо менять то же самое в нескольких местах, а это время, ошибки…
If/else
public void process(Object b) <
genericCode
if(b instanceof Bicycle) <
specificForBicycle
> else if(b instanceof Motobike) <
specificForMotobike
>
>
Наставили условий и все готово. Немного лучше, чем copy/paste, но опять есть проблема. А завтра они захотят продавать квадроциклы и придется по всему коду искать такие куски и добавлять еще один else.
Абстрактный метод
abstract void specific()
public void process(Vehicle b) <
genericCode
b.specific()
>
В этом месте вызывается абстрактный метод, который реализован для каждого типа. В принципе это может оказаться приемлемым вариантом, а может и существенно усложнить систему. Многоэтажные иерархии наследования с кучей переопределенных методов, когда нелегко разобраться какой конкретно метод вызывается — нередкая ситуация.
DSL и генерация кода
DSL разрабатывается таким образом, что все особенности типов можно описать. В генераторе кода пишутся шаблоны, которые применяются к описанию типов и получается код как в copy/paste
Шаблон:
public void process(«TYPE» b) <
genericCode
«SPECIFIC CODE»
>
DSL вначале или формализованная спецификация
Здесь я подхожу к самому главному. (до этого было вступление 
Как обычно выглядит процесс начала проекта? Пишутся спецификации, рисуются диаграммы, прорабатывается архитектура, этапы проекта. И когда это все сделано, начинают писать код. Спецификации — это документы в свободной форме. Почему бы спецификации не быть формализованной? Моя основная идея — сначала разрабатывать язык описания системы в терминах доменной области. Это будет частично и описание архитектуры, и частично формализованной спецификацией. При этом заказчику будет понятен язык, так как он непосредственно оперирует терминами предметной области, и он тоже сможет принять участие в разработке системы. Идея, конечно, не моя. В литературе такой подход называется Domain-Driven Design (DDD). Я лишь утверждаю, что подход DDD хорошо получается с DSL и генерацией кода.
Формализация означает возможность автоматической обработки. Можно добавить различные проверки на консистентность, непротиворечивость. С другой стороны, разработчики системы имеют готовую формализованную декларацию что должно быть. Остается написать преобразователь в как в работающую систему, те самые кодогенераторы.
Не все так гладко
Средства для разработки DSL и написания генераторов кода
Все что я написал до этого имело бы мало практического смысла без нормальных средств разработки. К счастью такие средства есть. Средства есть разные, но мой выбор Eclipse Xtext. Самое главное, что есть в xtext — интеграция в Eclipse IDE, а именно есть все стандартные свойства — подсветка синтаксиса, ошибки и предупреждения, content assist, quick fix. Это что называется «из коробки». А дальше на что фантазии хватит. Я думаю, что сделаю еще несколько практических постов по теме, если будет интерес.