DSL — различия между версиями

Версия 17:36, 11 мая 2016

Предметно-ориентированный язык или предметно-специфичный язык (англ. Domain Specific language, DSL — «язык, специфичный для предметной области») — язык программирования, специализированный для конкретной области применения (в противоположность языку общего назначения, применимому к широкому спектру областей и не учитывающему особенности конкретных сфер знаний). Является ключевым понятием языково-ориентированного программирования.

DSL - ветвь модельного движения, которая связана с понятием предметно-специфичного языка, обеспечивающего применяемый экспертами метод описания для получения предметно-специфичной группы описаний. DSL объединяет (концептуальную) метамодель и (графическую и/или текстовую) нотацию. Это отличается от MDA, в которой предписываются нотации и метамодели, основанные только на MOF/UML. Тем самым программисты должны обеспечивать отдельную интерактивную среду разработки (IDE, interactive development environment) для каждого DSL, а затем эксперты-непрограммисты будут использовать эти предметно-специфичные IDE для моделирования их систем.

DSL и САПР

Все САПР могут быть рассмотрены как наборы таких IDE для инженерных предметно-специфичных языков (например, диаграмм P&ID для моделирования гидравлических систем). Если мы хотим создать модель завода непрерывного цикла (например, нефтеперерабатывающего завода), то предстоит трудный выбор между моделированием гидравлических систем в MDA/SysML и традиционным P&ID-моделированием. Предметно-специфические языки современных САПР легко выигрывают. Но потом мы все равно должны объединить все эти несовместимые между собой модели на разных DSL в одну связанную модель завода.

Связанность наборов DSL

Есть две возможности предоставить такую связанность для зоопарка различных DSL:

1. Онтологическое совмещение (mapping) метамоделей различных DSL, и тем самым совмещение моделей в датацентрическом репозитории моделей.
2. Использование языковых рабочих мест (language workbenches).

Онтологическое совмещение

Онтологическое совмещение сегодня используется всеми основными поставщиками САПР, хотя при этом используются разные "верхние" (upper) онтологии и предметные таксономии:

• ISO 15926 для непрерывных производств,
• ISO 18269/PSL для (в том числе бизнес) процессов,
• ISO 16739/BIM для строительства и т.д.

Это хорошая возможность справиться с зоопарком устаревших систем, которые поддерживают "старые добрые предметно-специфичные языки инженерного моделирования". Онтологическое совмещение - относительно недавнее движение (начавшееся с работ 1994г. по созданию модели данных перерабатывающих производств Shell[1]), его корни лежат в моделировании данных при разработке программных средств. Те, кто воспринял этот онтологический подход, двигаются сегодня к применению уже готовых инструментов семантического веба[2] и вдобавок к исключительно моделированию данных и интеграции данных начинают эксперименты по логическому выводу (reasoning), таким образом обеспечивая "исполнение" ("executing") онтологических моделей. Интересно, что UML не слишком распространен в онтологических кругах, а OMG озабочена совмещением (mapping) метамоделей MDA/MOF и разработанных вне OMG "верхних" и "средних" онтологий (http://www.omg.org/ontology). Нужно заметить, что большинство онтологов (или модельеров данных) вышли из программистов, программных аналитиков и архитекторов баз данных, т.е. из областей, которые де факто сейчас часть программной инженерии, а не системной инженерии.

Языковые рабочие места

Языковые рабочие места — это новые IDE, специально посвященные созданию связанных наборов DSL (http://martinfowler.com/articles/languageWorkbench.html). Эту парадигму для разработки программных средств пробуют сейчас не слишком много разработчиков (http://martinfowler.com/bliki/IntentionalSoftware.html). Разработка "языконезависимого интерпретатора/компилятора" и "языконезависимого (в т.ч. графического) редактора" является очень сложной задачей. Зато перспективы очень заманчивы: каждый эксперт-непрограммист может получить собственный кастомизированный (инженерный, финансовый, управленческий и т.д.) DSL, и все эти DSL, адресующие множество различных интересов заинтересованных сторон, будут работать совместно.

Более того, эти отдельные обеспечивающие разделение интересов (separation of concerns) описания далее могут обрабатываться различными способами и для различных нужд:

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

Благодаря свободе выбора языков, это может быть лучше, чем MDA/UML (или MDA/SysML), и так же предотвращать потерю связности общей модели. Сейчас это движение исключительно программистов, системные инженеры не знают об этом DSL-тренде в целом и тренде разработки языковых рабочих мест в частности.

Системная инженерия может, как обычно, ждать 10 лет до заимствования из программной инженерии этих новых подходов к моделированию, или начинать экспериментировать с новыми технологиями немедленно. Моделеориентированная системная инженерия не должна быть синонимом SysML-ориентированной системной инженерии. SysML — это только отправной пункт для моделеориентированной системной инженерии, а не пункт назначения.

Примеры DSL

• TeX/LaTeX для подготовки (компьютерной вёрстки) текстовых документов;
• Perl для манипулирования текстами;
• SQL для СУБД;
• Tcl/Tk для графического интерфейса пользователя;
• HTML и SGML для разметки документов;
• Verilog и VHDL для описания аппаратного обеспечения;
• Mathematica и Maple для символьных вычислений;
• AutoLisp для компьютерного моделирования (САПР);
• Prolog для задач, сформулированных в терминах исчисления предикатов;
• ML и Haskell для задач, сформулированных в терминах функций (Haskell временами определяется как DSL для денотационной семантики).