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

Question

Языки программирования имели несколько эволюционных этапов в своей истории. Некоторые люди утверждают, что модельно-ориентированные подходы будут Следующим Большим Вещем. Существуют такие инструменты, как openArchitectureWare, AndroMDA, Sculptor / Fornax Platform и т. Д., Которые обещают невероятное повышение производительности. Тем не менее, я понял, что с самого начала довольно легко начать работу, а также застревать в какой-то момент, когда вы пытаетесь что-то неожиданное или довольно сложно найти достаточно информации, которая говорит вам, как начать ваш проект, потому что там может быть много вещей для рассмотрения.

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

Что вы думаете и о чем говорит ваш опыт? Есть ли будущее у модельно-ориентированной разработки (или как вы можете ее назвать)?

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

Answer 1

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

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

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

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

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

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

Таким образом, даже если DSL часто упоминаются вместе с MDSD, я думаю, что они действительно являются альтернативой MDSD. И учитывая текущую ажиотаж, они также убирают импульс из движения MDSD.

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

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

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

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

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

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

Answer 2

Модель управляемой разработки существует очень давно.

Самой успешной из первых попыток было комплексное инженерное оборудование Джеймса Мартинса ", которое все еще существует и продается CA под серьезным названием" Coolgen ".

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

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

Answer 5

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

Answer 6

Model Driven Development станет будущим, если и только если модели, которые она использует, могут быть такими же гибкими, как написание кода, который предполагается генерировать. Я думаю, что причина того, почему сейчас дела идут не так хорошо, заключается в том, что вам трудно совершать те же «обходы», что и текстовые языки программирования, которые делались десятилетиями.

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

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

Answer 7

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

Answer 8

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

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

Answer 9

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

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

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

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

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

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

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