Используете ли вы MDA/MDD/MDSD, какой-либо подход, основанный на модели? Будет ли это будущее?

Отказ от ответственности: я являюсь разработчиком бизнес-приложений. Следующая точка зрения, безусловно, сформирована моим опытом работы в окопах предприятия IT. Я знаю, что существуют и другие области разработки программного обеспечения. Особенно при разработке промышленных и/или встраиваемых систем Мир может выглядеть иначе.

Я думаю, что MDSD все еще слишком сильно привязан к генерации кода.

Генерация кода полезна только тогда, когда ваш код содержит много шума и/или очень часто повторяется. Другими словами, когда ваш код не может в основном сосредоточиться на существенной сложности, но загрязнен случайной сложностью.

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

Таким образом, эти новые платформы/фреймворки забирают много ветра из парусов движения MDSD.

DSLs (текстуальные) - это еще одна тенденция, которая пытается дать возможность сосредоточиться исключительно на существенной сложности. Хотя DSLs можно использовать в качестве источника для генерации кода, они не связаны в первую очередь с генерацией кода. DSLs (особенно внутренний DSLs) в основном позволяет ему открыться для интерпретации/выполнения во время выполнения. [генерация кода во время выполнения находится где-то посередине].

Поэтому, даже если DSLs часто упоминается вместе с MDSD, я думаю, что они действительно являются альтернативой MDSD. И учитывая нынешнюю шумиху, они также извлекают импульс из движения MDSD.

Если вы достигли цели окончательного устранения случайной сложности из вашего кода (я знаю, что это фикция), то вы пришли к текстовой модели вашей бизнес-проблемы. Это не может быть еще более упрощено!

Красивые коробки и диаграммы не предлагают еще одно упрощение или Повышение уровня абстракции! Они могут быть хороши для визуализации, но даже это сомнительно. Картина не всегда является лучшим представлением для понимания сложности!

Кроме того, текущее состояние инструментов, задействованных в MDSD, добавляет еще один уровень случайной сложности (подумайте: синхронизация, рефакторинг diffing/merging, ...) что в принципе сводит на нет конечную цель упрощения!

Посмотрите на следующую модель ActiveRecord, как на иллюстрацию моей теории:

class Firm < ActiveRecord::Base
   has_many   :clients
   has_one    :account
   belongs_to :conglomorate
end

Я не думаю, что это можно еще больше упростить. Кроме того, любое графическое представление с прямоугольниками и линиями не было бы упрощением и не предлагало бы больше удобства (подумайте о компоновке, рефакторинге, поиске, диффинге ...).

Разработка на основе моделей существует уже очень давно.

Наиболее успешной из ранних попыток была James Martins Integrated Engineering Facility", которая до сих пор существует и продается компанией CA под серьезно некрутым брендом "Coolgen".

Так почему же он не захватил весь мир, если он был так хорош?

Ну, эти инструменты хороши в том, чтобы сделать простые вещи проще, но они не делают трудные вещи легче, и во многих случаях делают трудные вещи сложнее!

Вы можете потратить часы, пытаясь убедить графический язык моделирования 4GL в "do the right thing", когда вы знаете, что кодирование правильной вещи в Java/C/SQL или что-то еще будет тривиальным.

Я думаю, что, возможно, нет окончательного ответа - отсюда и отсутствие "interest" в этом вопросе.

Но у меня лично был смешанный опыт с MDA. Единственный раз, когда это был хороший опыт, был с большими инструментами - я использовал TogetherSoft (я думаю, что они каким - то образом оказались в borland) - они были одними из первых, кто ввел редактирование, которое не было "code generation", но фактически редактировало код/модель напрямую (так что вы могли редактировать код или модель, это было все одно). У них также был рефакторинг (который был первым разом, когда я помню его в среде smalltalk).

С тех пор я больше не видел роста популярности MDA, по крайней мере в мейнстриме, так что с точки зрения популярности это не похоже на будущее (так что это вроде как ответ на него).

Конечно, популярность-это еще не все, и вещи имеют тенденцию возвращаться, но на данный момент я думаю, что MDA+tools рассматривается многими как "wizard based code generation" tools (независимо от того, что это на самом деле), поэтому я думаю, что это будет некоторое время или, возможно, никогда не произойдет.

Я думаю, что это займет время, пока инструменты не станут более совершенными, больше людей получат опыт работы с MDD. На данный момент, если вы хотите получить что-то из MDD, вам придется инвестировать довольно много, поэтому его использование остается ограниченным.

Например, глядя на openArchitectureWare: хотя он достаточно надежен и существует базовая документация, документация по внутренней работе отсутствует, и все еще существуют проблемы с масштабируемостью, которые не документированы - возможно, это станет лучше, когда Xtext и Xpand будут переписаны.

Но презирайте эти ограничения само поколение довольно легко с помощью oAW, вы можете перемещаться по своим моделям, как шарм в Xtend и Xpand, и, объединяя несколько рабочих процессов в более крупные рабочие процессы, вы также можете делать очень сложные вещи. При необходимости вы можете прибегнуть к Java, так что у вас есть очень большая гибкость в том, что вы можете сделать с вашими моделями. Написание собственного DSL с помощью Xtext в oAW тоже быстро делается, но вы получаете свою метамодель, парсер и очень хороший редактор практически бесплатно. Кроме того, вы можете получить свои модели практически отовсюду, например, компонент, который может преобразовать базу данных в метамодель и соответствующие модели могут быть написаны без больших усилий.

Поэтому я бы сказал, что MDD все еще накапливается, поскольку инструменты и опыт работы с ним увеличиваются. Его уже можно успешно использовать, если вы обладаете необходимым опытом и готовы продвигать его в рамках своей компании. В конце концов, я думаю, что это очень хорошая вещь, потому что много клеевого кода (он же copy paste) может и должно быть сгенерировано. Делать это с MDD-очень хороший и структурированный способ сделать это, что, на мой взгляд, облегчает повторное использование.

Одна из проблем MDD заключается в том, что, поскольку он работает на более высоком уровне абстракции, он требует разработчиков, которые также могут подняться на уровень абстракции. Это значительно сокращает число разработчиков, которые могут понять и использовать такие методологии.

Пожалуйста, дайте мне знать, если у вас есть какой-либо (хороший или плохой) опыт работы с модельными подходами или почему вы считаете, что это совсем не интересно.

Я думаю, что участники здесь являются частью лагеря "No Silver Bullet" (я определенно). Если бы MDA сработало (равнозначно "огромной экономии"), мы бы это точно знали. Вопрос заключается в следующем: как далеко "meta" вы можете зайти, сохраняя вашу систему управляемой? Это был поворотный момент в UML 2.0, когда они ввели более формальный meta-meta-model. До сих пор я не видел реального использования силы моделирования UML 2.0 (но мой мир довольно ограничен). Кроме того, при использовании подхода, основанного на модели, у вас есть только два варианта: генерировать код или иметь среду выполнения, использующую вашу модель. Конечный генератор кода без ограничений называется "human", тогда как конечные времена выполнения находятся в 4GLs (каково текущее число в настоящее время?). Может быть, это и объясняет отсутствие энтузиазма.

Мы, в пункт (www.itemis.com) использование управляемой моделями разработки программного обеспечения много. До сих пор у нас были действительно хорошие впечатления. Shure это не серебряная пуля, но это помогает улучшить качество программного обеспечения, следовательно, больше пользы для наших клиентов.

Разработка на основе моделей станет будущим, если и только если модели, которые она использует, могут быть такими же гибкими, как написание кода, который она должна генерировать. Я думаю, что причина, по которой он не работает так хорошо прямо сейчас, заключается в том, что вам трудно сделать то же самое "round-tripping", что делают текстовые языки программирования на протяжении десятилетий.

При использовании текстовых языков программирования изменить модель так же просто, как изменить несколько строк кода. С помощью графического языка программирования (он же MDD-диаграмма, как UML), вы должны найти способ перевести эту модель полностью вниз к ее текстовому эквиваленту (который уже был выразительно эффективным в первую очередь), и это может быть очень, очень грязно.

IMHO, единственный способ MDD может быть полезен, если он построен с нуля, чтобы быть таким же выразительным и гибким, как его текстовый аналог. Попытка использовать существующие нисходящие графические языки проектирования (такие как UML) для инструментов, которые по своей сути построены снизу вверх с использованием многоуровневых абстракций (таких как языки программирования), создает огромное несоответствие импеданса. Я не могу точно сказать, что это такое, но в MDD все еще чего-то не хватает, что сделало бы его настолько полезным, как утверждают люди...

Это очень поздний ответ, но в настоящее время я ищу MDD инструментов для замены Rose RT, который, к сожалению, вытесняется Rhapsody. Мы находимся в реальном времени, встроенном и распределенном пространстве C++, и мы получаем LOT из MDD. Мы пытаемся перейти к более совершенному инструменту и получить более широкое применение этого инструмента в нашей очень большой компании. Это тяжелое сражение из-за некоторых прекрасных причин, упомянутых здесь.

Я думаю о MDD как всего лишь на один уровень выше компилятора, точно так же, как компилятор находится выше assembly. Мне нужен инструмент, который позволит мне, как архитектору, разработать структуру приложения и широко редактировать генерацию кода (скрипты), чтобы использовать эту структуру и любое промежуточное программное обеспечение, которое мы используем для передачи сообщений. Я хочу, чтобы разработчики сделали полные классы UML и диаграммы состояний, которые включают весь код, необходимый для создания приложения и / или библиотеки.

Это правда, что вы можете делать с кодом все, что угодно, но я бы примерно суммировал преимущества MDD, как это:

1. Несколько человек делают фреймворк приложения, адаптеры промежуточного ПО и приклеивают его к инструменту MDD. Они строят "house".
2. Другие люди создают полные классы, диаграммы и код перехода к автомату состояний. Это позволяет им сосредоточиться на приложении вместо "house".
3. Его легко увидеть, когда люди имеют странный дизайн, так как диаграмма - это код. У нас нет всех опытных разработчиков, и приятно воспитывать молодых людей таким образом.
4. В основном это неприятный государственный машинный код, который может произойти в чем-то вроде мобильного робототехнического проекта. Я хочу, чтобы люди делали диаграммы состояния, которые я могу понять, критиковать и работать с ними.
5. Вы также можете иметь хороший рефакторинг, например перетаскивание операций и атрибутов вверх по цепочкам наследования или в другие классы и т. д. Мне это нравится больше, чем копаться в файлах.

Даже когда я печатаю это, я понимаю, что вы можете сделать все в коде. Мне нравится тонкий инструмент jsut поверх кода, чтобы обеспечить единообразие, документировать дизайн и позволить немного упростить рефакторинг.

Основная проблема, с которой я сталкиваюсь, на которую у меня нет хорошего ответа, заключается в том, что для таких моделей нет стандартного набора функций и формата файлов. Люди беспокоятся о том, что продавец уйдет, а потом застрянет. (У нас в основном это произошло с Розой RT.) У вас нет этого с исходным кодом. Однако у вас будет последняя версия инструмента и код курса, который вы создали последним :). Я готов поспорить, что выгода перевешивает риск.

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