Языковые фабрики и управляемая моделью архитектура

Автор: Мартин Фаулер
Перевод с английского языка: Андрей Фрунт
[ Электронный источник: читать ]

В последнее время наблюдается рост количества инструментов, которые дают возможность интегрировать множество специфических языков предметной области (Domain Specific Language, DSL) — инструменты, которые я называю языковыми фабриками. Множество дискуссий вокруг них очень похожи на дискуссии вокруг управляемой моделями архитектуры (Model Driven Architecture, MDA). С моей точки зрения, множество людей понимают MDA по-разному и это определяет то, как мы связываем MDA и языковые фабрики. Конечно, на практике MDA используют для создания языковых фабрик. Но, я считаю, что помощь MDA в этом носит частичный характер. В более основоположной школе управляемой моделями разработки (Model Driven Development, MDD) отражаются многие идеи MDA безо всякого упоминания о стандартах MDA.

Три лагеря MDA

Первым шагом в обсуждении является понимание того, что MDA, на самом деле, воспринимается людьми тремя абсолютно разными и несовместимыми способами. Стив Кук (Steve Cook) описал разделение на три презирающих друг друга лагеря: UML PIM: используют UML (Unified Modeling Language) для построения независимой от платформы модели (Platform Independent Model, PIM), которая преобразовывается (или реализуется человеком) в исходные коды. MOF: совсем не используют UML, но определяют языки и преобразования, используя возможность объектных преобразований (Meta Object Facity, MOF); Executable UML: создают компилятор для UML или расширенного подмножества и трактуют его как язык программирования. MOF и UML PIM лагери работают в определенной степени над языково-ориентированным программированием. Executable UML лагерь в действительности не заинтересован в языково-ориентированном программировании. Нельзя сказать, что это плохо. На самом деле, некоторые из защитников UML из этого лагеря являются наиболее рассудительными и значащими профессионалами области, но это не относится к текущему обсуждению. Есть другой лагерь, который наиболее корректно называть лагерем управляемой моделью разработки (MDD camp). Они совсем не являются частью MDA, так как они не принимают всерьез стандарты OMG. Возникает путаница, когда люди ссылаются на работы MDD, не упоминая OMG MDA. Чтобы быть более точным, лучше говорить, что MDA — это MDD, но с использованием стандартов OMG. Все вышесказанное означает, что обсуждая роль MDA в языковых фабриках я должен оценить и описать UML PIM и MOF по-отдельности, потому что они рассуждают о языково-ориентированном программировании совершенно различным образом.

Лагерь UML PIM

Стиль UML PIM основан на идее разработки систем, используя UML в качестве PIM, которая трансформируется с помощью платформо-специфической модели (Platform Specific Model, PSM) в исходные коды. Эта PIM представляет собой UML и, как и у языковых фабрик, ключевой источник информации сохранен в абстрактном представлении, используя метамодель UML. Редактирование (обычно с использованием графических инструментов без использования CASE-средств) происходит с использованием проекционных редакторов, которые визуализируют UML. Использование сохраняемого абстрактного представления и проекционных редакторов — это то, за что отвечают языковые фабрики, но этого недостаточно, чтобы охарактеризовать языковую фабрику. Чтобы соответствовать, фабрика должна быть способна определять собственные языки и интегрировать их с остальными необходимыми. Путь UML PIM заключается в использовании языковых расширений, встроенных в UML, - стереотипов и их семейств. Нет причин, по которым UML PIM не может быть языковой фабрикой. Вопрос состоит в том, хорошая ли идея, использовать подход UML PIM для создания языковой фабрики. Проблема в том, что UML — это довольно сложный язык. Механизм расширений тоже довольно сложен и трудно предугадать, как он себя на практике. Неизвестно, насколько удобно манипулировать ими. Не существует стандартов по преобразованию стандартного UML в исходные коды. Как результат, нет достаточно точной семантики для UML. В действительности, я слышал, как сторонники UML хвалились тем, что они не имеют строгой семантики. Вы можете использовать метамодель UML для определения структуры DSL, но, в этом случае, она окажется настолько же избыточной с одной стороны, насколько скудной — с другой. UML включает в себя множество элементов, которые не нужны для определения структуры DSL. Кроме того, UML не содержит ничего, что могло бы помочь редакторам или генераторам. Для этих целей метамодель UML неоправданно большая, сложная и не удовлетворяет базовых требований языковых фабрик, кроме того, несет с собой еще и определенное множество неудобств. Это похоже на то, если бы мы строили скоростные корабли из грузовиков только потому что и те и другие имеют рулевое управление. Несмотря на моё очевидное пренебрежение этим подходом, существует много людей, создающих языковые фабрики на базе UML PIM. Если вы не согласны с моей оценкой пригодности UML для подобных целей, то вам следовало бы обратить внимание на работы таких людей.

Лагерь MOF

MOF пришли не из тех сообществ внутри OMG, что и UML и отношения между этими сообществами обычно были и остаются достаточно прохладными. Усилия лагеря MOF более связаны с работами OMG CORBA и многие идеи MOF возникли как следствия работы с CORBA (Common Object Request Broker Architecture). Стандарт MOF — это стандарт для метамоделей, на основе которых строятся метамодели более высоких порядков. Поэтому вы можете использовать MOF как язык для определения метамодели UML. В терминах языковых фабрик, MOF соответствует DSL для определения структуры новых DSL, это похоже на структурный язык MPS. Если вы ознакомитесь с документацией MOF, то увидите множество вещей похожих на те, которые мы видели в структурном редакторе MPS. Поэтому, MOF — это просто еще одна метамодель для моделирования данных. Ее история объектов, в общих чертах, предоставляет определенные операции, но полноценные механизмы моделирования поведения отсутствуют, в отличие от UML. MOF намного меньше, чем UML, - это, на самом деле, подмножество средств диаграмм классов UML. Из этого следует, что MOF — это именно то, что наилучшим образом подходит для определения структуры DSL, намного лучше вписываясь в задачу, чем UML. Разумеется, многие люди предлагают MOF как хороший структуру для абстрактного представления или даже представления для хранения данных языковых фабрик. В любом случае, MOF все же не идеально подходит. Определения операций более уместны в контексте работы с удаленными объектами (CORBA), но не для структуры DSL. Множество споров вокруг использования MOF для структур DSL наталкивают на вопрос о том, насколько же хорошо они для этого подходит? Несет ли MOF с собой багаж ненужных возможностей, присутствуют ли в ней все необходимые элементы? Я не имею четкого суждения об этом, поэтому для меня этот вопрос остается открытым. Ближе к делу, MOF не имеет ничего для взаимодействия с редакторами или реализациями генераторов. Учитывая, что это две ключевые составляющие языковых фабрик, то это две большие дыры в MOF с точки зрения языковых фабрик. OMG готовит стандарт под названием QVT(Query, View, Transformation), чтобы устранить эти недочеты, Но этот стандарт находится лишь на ранних стадиях разработки. MOF может быть весьма полезен как механизм обмена между языковыми фабриками и структурами DSL. В этом контексте MOF может быть полезной, но не полностью, так как ей не хватает элементов для поддержки генераторов и редакторов. Все же она кажется мне самой полезной частью стандартов MDA для языковых фабрик.

MDA и стандартизация

Одной из небольших неудач языковых фабрик стала критика и игнорирование MDA в своих работах над Software Factories со стороны Microsoft. Вы наверное заметили, что Intentional Software и MPS тоже игнорируют MDA, каждый из них видит смотрит на различные стандарты MDA, как на непригодные для их деятельности. Microsoft имеет наибольшую компетенцию в области MDA, так как многие создатели Software Factories длительное вемя были членами сообщества UML. Они пришли к одному выводу — MDA не лучшим образом подходит для того, что они хотят делать. Я считаю, что есть вполне весомые причины для такого суждения. Оба лагеря, UML PIM и MOF могут претендовать на стандартизацию структур DSL, но не менее важными элементами, такими, как поддержка редакторов и генераторов, они не обладают. С моей точки зрения, вы определяете стандарты как только вы выпустите основные элементы рабочих технологий. Языковые фабрики еще слишком незрелые, чтобы быть готовыми к стандартизации. Я подозреваю, что стандарт для DSL будет построен на основе MOF или, по крайней мере, будет на нее похож. Но языковые фабрики все еще пытаются выразить, что им нужно. Поэтому сейчас любая попытка свести стандарт воедино рискует обернуться незрелым стандартом в итоге. Есть люди, которые создают инструменты под флагом MDA, которые могут рассматриваться как языковые фабрики. Я внимательно не рассматривал ни одну из них. Кажется, что такие инструменты имеют шанс быть удобными, но, в то же время, складывается впечатление, что UML или MOF, вследствие их сложности, могут стать на самом деле вредными. Все сказанное выше не значит, что нотация UML неприменима для языковых фабрик. Я думаю, что есть доля правды в критике в сторону Software Factories, действительно, их графические стандарты могли бы быть ближе к UML. Для определенных типов диаграмм нотация UML имеет огромный смысл. UML широко известен. Я рассчитываю, что инструменты будут использовать UML-подобные диаграммы тогда, когда это необходимо. В общем случае, они могут даже не следовать полностью стандартам UML и не использовать метамодель UML как абстрактное представление.

Управляемая моделью разработка

Как я уже говорил, есть множество людей, которые любят многие идеи использования, в основном, графических моделей для разработки ПО, но не сильно склонных к жесткому следованию стандартам OMG. Это сообщество называется сообществом управляемой моделью разработки (Model Driven Development community, MDD). Они имеют много общего с сообществом MDA. Многие из них работали над CASE-системами в 80-х и 90-х. Они более предпочитают графические модели, нежели текстовые. Они любят подход редактирования абстрактного представления с использованием проекционных редакторов. Многие из них дают разработчикам возможность определять даже свои графические языки. В этих отношениях есть множество философских соглашений между MDD и языковыми фабриками. Можно сказать, что интерес к языковым фермам пришел с двух сторон — со стороны разработчиков на классических языках программирования и со стороны моделирующий людей. Не все сторонники MDD считают важным то, что люди могут без особых усилий определить и интегрировать свой собственный язык. Для многих людей в мире MDA более важным является определение систем в терминах набора моделей.

Заключение

Известно, что я довольно скептически отношусь к MDA. Большая часть этого скептицизма относится к лагерю UML PIM. Я думаю, что UML слишком сложен и не подходит в качестве базы для последующих работ в этом направлении. Но вопрос этой статьи состоит в том, какую роль должна играть MDA в языковых фабриках? Мой ответ: «она не подходит вообще». Ведь необходимо определить эффективный механизм обмена между представлением и языковыми фабриками. Без этого есть риск, что можно отпугнуть потенциальных пользователей от использования языковых фабрик. В любом случае, я не думаю, что стандарты OMG — это ответ, в основном, потому что они были созданы для других целей. Я считаю, что сначала вы должны представить себе «как» делать «что-то», а уже затем определиться с тем, как прийти к использованию стандартов и каких именно. Стандарты OMG могут быть применимы для определенных участков. Но еще слишком рано что-то точно утверждать.