Архитектура, управляемая моделью

Мы профессиональная команда, которая на рынке работает уже более 2 лет и специализируемся исключительно на лучших продуктах.

У нас лучший товар, который вы когда-либо пробовали!

Наши контакты:

Telegram:

https://t.me/stuff_men

E-mail:

stuffmen@protonmail.com

ВНИМАНИЕ!!! В Телеграмм переходить только по ссылке, в поиске много Фейков!

Внимание! Роскомнадзор заблокировал Telegram ! Как обойти блокировку:

http://telegra.ph/Kak-obojti-blokirovku-Telegram-04-13-15

В последнее время наблюдается рост количества инструментов, которые дают возможность интегрировать множество специфических языков предметной области Domain Specific Language, DSL — инструменты, которые я называю языковыми фабриками. Множество дискуссий вокруг них очень похожи на дискуссии вокруг управляемой моделями архитектуры Model Driven Architecture, MDA. С моей точки зрения, множество людей понимают MDA по-разному и это определяет то, как мы связываем MDA и языковые фабрики. Конечно, на практике MDA используют для создания языковых фабрик. Но, я считаю, что помощь MDA в этом носит частичный характер. Первым шагом в обсуждении является понимание того, что MDA, на самом деле, воспринимается людьми тремя абсолютно разными и несовместимыми способами. Стив Кук Steve Cook описал разделение на три презирающих друг друга лагеря: Executable UML лагерь в действительности не заинтересован в языково-ориентированном программировании. Нельзя сказать, что это плохо. На самом деле, некоторые из защитников UML из этого лагеря являются наиболее рассудительными и значащими профессионалами области, но это не относится к текущему обсуждению. Есть другой лагерь, который наиболее корректно называть лагерем управляемой моделью разработки MDD camp. Все вышесказанное означает, что обсуждая роль MDA в языковых фабриках я должен оценить и описать UML PIM и MOF по-отдельности, потому что они рассуждают о языково-ориентированном программировании совершенно различным образом. Редактирование обычно с использованием графических инструментов без использования CASE-средств происходит с использованием проекционных редакторов, которые визуализируют UML. Использование сохраняемого абстрактного представления и проекционных редакторов — это то, за что отвечают языковые фабрики, но этого недостаточно, чтобы охарактеризовать языковую фабрику. Чтобы соответствовать, фабрика должна быть способна определять собственные языки и интегрировать их с остальными необходимыми. Проблема в том, что UML — это довольно сложный язык. Механизм расширений тоже довольно сложен и трудно предугадать, как он себя на практике. Неизвестно, насколько удобно манипулировать ими. Не существует стандартов по преобразованию стандартного UML в исходные коды. Как результат, нет достаточно точной семантики для UML. В действительности, я слышал, как сторонники UML хвалились тем, что они не имеют строгой семантики. Вы можете использовать метамодель UML для определения структуры DSL, но, в этом случае, она окажется настолько же избыточной с одной стороны, насколько скудной — с другой. Кроме того, UML не содержит ничего, что могло бы помочь редакторам или генераторам. Для этих целей метамодель UML неоправданно большая, сложная и не удовлетворяет базовых требований языковых фабрик, кроме того, несет с собой еще и определенное множество неудобств. Это похоже на то, если бы мы строили скоростные корабли из грузовиков только потому что и те и другие имеют рулевое управление. Несмотря на моё очевидное пренебрежение этим подходом, существует много людей, создающих языковые фабрики на базе UML PIM. Если вы не согласны с моей оценкой пригодности UML для подобных целей, то вам следовало бы обратить внимание на работы таких людей. Стандарт MOF — это стандарт для метамоделей, на основе которых строятся метамодели более высоких порядков. Если вы ознакомитесь с документацией MOF, то увидите множество вещей похожих на те, которые мы видели в структурном редакторе MPS. Поэтому, MOF — это просто еще одна метамодель для моделирования данных. Ее история объектов, в общих чертах, предоставляет определенные операции, но полноценные механизмы моделирования поведения отсутствуют, в отличие от UML. Разумеется, многие люди предлагают MOF как хороший структуру для абстрактного представления или даже представления для хранения данных языковых фабрик. В любом случае, MOF все же не идеально подходит. Множество споров вокруг использования MOF для структур DSL наталкивают на вопрос о том, насколько же хорошо они для этого подходит? Несет ли MOF с собой багаж ненужных возможностей, присутствуют ли в ней все необходимые элементы? Я не имею четкого суждения об этом, поэтому для меня этот вопрос остается открытым. Ближе к делу, MOF не имеет ничего для взаимодействия с редакторами или реализациями генераторов. Учитывая, что это две ключевые составляющие языковых фабрик, то это две большие дыры в MOF с точки зрения языковых фабрик. В этом контексте MOF может быть полезной, но не полностью, так как ей не хватает элементов для поддержки генераторов и редакторов. Все же она кажется мне самой полезной частью стандартов MDA для языковых фабрик. Одной из небольших неудач языковых фабрик стала критика и игнорирование MDA в своих работах над Software Factories со стороны Microsoft. Они пришли к одному выводу — MDA не лучшим образом подходит для того, что они хотят делать. Я считаю, что есть вполне весомые причины для такого суждения. С моей точки зрения, вы определяете стандарты как только вы выпустите основные элементы рабочих технологий. Языковые фабрики еще слишком незрелые, чтобы быть готовыми к стандартизации. Но языковые фабрики все еще пытаются выразить, что им нужно. Поэтому сейчас любая попытка свести стандарт воедино рискует обернуться незрелым стандартом в итоге. Есть люди, которые создают инструменты под флагом MDA, которые могут рассматриваться как языковые фабрики. Я внимательно не рассматривал ни одну из них. Кажется, что такие инструменты имеют шанс быть удобными, но, в то же время, складывается впечатление, что UML или MOF, вследствие их сложности, могут стать на самом деле вредными. Все сказанное выше не значит, что нотация UML неприменима для языковых фабрик. Я думаю, что есть доля правды в критике в сторону Software Factories, действительно, их графические стандарты могли бы быть ближе к UML. Для определенных типов диаграмм нотация UML имеет огромный смысл. Я рассчитываю, что инструменты будут использовать UML-подобные диаграммы тогда, когда это необходимо. В общем случае, они могут даже не следовать полностью стандартам UML и не использовать метамодель UML как абстрактное представление. Как я уже говорил, есть множество людей, которые любят многие идеи использования, в основном, графических моделей для разработки ПО, но не сильно склонных к жесткому следованию стандартам OMG. Они имеют много общего с сообществом MDA. Многие из них работали над CASE-системами в х и х. Они более предпочитают графические модели, нежели текстовые. Они любят подход редактирования абстрактного представления с использованием проекционных редакторов. Многие из них дают разработчикам возможность определять даже свои графические языки. В этих отношениях есть множество философских соглашений между MDD и языковыми фабриками. Можно сказать, что интерес к языковым фермам пришел с двух сторон — со стороны разработчиков на классических языках программирования и со стороны моделирующий людей. Не все сторонники MDD считают важным то, что люди могут без особых усилий определить и интегрировать свой собственный язык. Для многих людей в мире MDA более важным является определение систем в терминах набора моделей. Известно, что я довольно скептически отношусь к MDA. Я думаю, что UML слишком сложен и не подходит в качестве базы для последующих работ в этом направлении. Но вопрос этой статьи состоит в том, какую роль должна играть MDA в языковых фабриках? Ведь необходимо определить эффективный механизм обмена между представлением и языковыми фабриками. Без этого есть риск, что можно отпугнуть потенциальных пользователей от использования языковых фабрик. В любом случае, я не думаю, что стандарты OMG — это ответ, в основном, потому что они были созданы для других целей. Стандарты OMG могут быть применимы для определенных участков. Но еще слишком рано что-то точно утверждать. Языковые фабрики и управляемая моделью архитектура Автор: Мартин Фаулер Перевод с английского языка: Андрей Фрунт \\\\\\\\\\\\\\\[ Электронный источник: Управляемая моделью разработка Как я уже говорил, есть множество людей, которые любят многие идеи использования, в основном, графических моделей для разработки ПО, но не сильно склонных к жесткому следованию стандартам OMG. Заключение Известно, что я довольно скептически отношусь к MDA.

Архитектура, управляемая моделью

Технологическая архитектура, стандарты и шаблоны