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

https://stackoverflow.com/questions/21091

09-06-2019
|

Вопрос

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

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

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

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

Решение

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

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

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

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

Другие советы

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

Я думаю, что 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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow