你现在在做 MDA（模型驱动架构）吗？如果是这样，您使用什么工具，效果如何？答案

【问题标题】：Are you doing MDA (Model Driven Architecture) right now? If so, what tools do you use, and how is it working out?你现在在做 MDA（模型驱动架构）吗？如果是这样，您使用什么工具，效果如何？
【发布时间】：2024-12-19 06:30:02
【问题描述】：

模型驱动架构的想法是，您创建模型来表达您需要解决的问题，而无需任何（或至少大多数）实现技术，然后您为一个或多个特定平台生成实现。声称是在更高的抽象层次上工作更强大和更有生产力。此外，您的模型比技术更有效（因此，当您的第一语言/平台过时时，您仍然有一些东西可以用于下一代解决方案）。另一个声称的关键好处是可以生成许多样板文件和“繁重的工作”。一旦计算机理解了你的情况的语义，它就可以为你提供更多帮助。

有人声称这种方法的生产力提高了 10 倍，而且这是 10 年后我们都将构建软件的方式。

然而，这一切都只是理论。我想知道当橡胶遇到道路时会产生什么结果。另外，MDA的“官方”版本来自OMG，看起来很重。它在很大程度上基于 UML，这可能被认为是好还是坏取决于你问谁（我倾向于“坏”）。

但是，尽管存在这些担忧，但很难与在更高抽象级别上工作并“教”计算机理解问题和解决方案的语义的想法争论不休。想象一系列简单表达真理的 ER 模型，然后想象使用这些模型来生成解决方案的重要部分，首先是在一组技术中，然后是在另一组技术中。

所以，我很想听听现在真正在做 MDA（“官方”与否）的人的意见。你使用什么工具？效果如何？你能够捕捉到多少理论上的承诺？您是否看到真正的 10 倍效率提升？

【问题讨论】：

标签： architecture mda

【解决方案1】：

对这个问题缺乏回应有点不祥……也许我会让Dijkstra 回答它。

...因为计算机在十年内出现当相信进步和科学的健全性和技术几乎是无限的，它回想一下可能是明智的，鉴于其最初的目标，人类的科学上的努力，比如说，过去五个世纪是一个壮观的失败。

大家都记得，第一个和首要目标是发展的长生不老药，会给一个喝了它永恒的青春。但由于永恒没有多大意义贫穷，科学世界很快开始了它的第二个项目，即。魔法石让你赚到和你一样多的金币需要。

...

对理想编程的追求语言和理想的人机可以制作软件的界面危机像阳光下的雪一样融化了 ——现在还有！——所有的搜索的特点长生不老药和石头。这个搜索得到两个人的大力支持双方，首先是因为行神迹是最少的您可以从计算机中获得的，其次，从财务和来自一个社会的政治支持一直要求长生不老药和首先是石头。

两个主要流可以是尊贵的，对石头的追求以及对长生不老药的追求。

对石头的追求是基于假设我们的“编程工具”太弱了。一个例子是相信当前的编程语言缺乏我们需要的“特征”。 PL/I 是最壮观的之一将产生的石头。我仍然记得里面的广告 Datamation，1968，其中一个微笑 Susie Mayer 全彩宣布她已经解决了她的一切通过切换到编程问题 PL/I。太可预见了几年后，可怜的苏西梅耶尔不再微笑了。不必要可以说，任务继续进行并适时进行下一块石头的时间以 Ada 的形式产生（后面感知地提到的铁幕为 PL/II)。即使是最基本的占星学初学者就够了预测艾达不会是最后一个这种石头。

...

形式中的另一系列石头 “编程工具”的产生打着“软件”的旗号工程”，随着时间的推移，试图取代知识分子管理纪律的纪律它现在接受的程度它的章程“如果你不能。”

【讨论】：

是的，绝对相关。我怀疑任何开发人员是否真的相信某些方法会使开发人员过时。但这是我可以相信的：一个完整的工具生态系统，它需要一流的开发人员并显着提高他/她的效率。不过，也许 OMG MDA 并非如此。
“一个完整的工具生态系统，它需要一流的开发人员并显着提高他/她的效率”我认为这就是 Emacs。 :-D
真的吗？也许我应该给它第二次（不，第三次）机会 :)
我也是半开玩笑的。如果您认为您的工具供应商无法预测您的所有需求，那么您必须选择最灵活的工具才能保持有效。像 Eclipse 这样更现代的“工具平台”在定制方面的门槛要高得多。

【解决方案2】：

自 1999 年以来，我一直在模型驱动软件开发领域进行自己的独立研究。我终于在 2006 年开发了一种通用建模方法，我将其命名为 ABSE（基于 Atom 的软件工程）。

因此，ABSE 建立在两个基本方面：

编程就是问题分解
一切都可以在树上表示

一些 ABSE 功能：

它可以支持所有其他形式的软件工程，从传统的从面向文件的方法到基于组件的开发、面向方面的编程、特定领域的建模、软件产品线和软件工厂。
它的通用性足以应用于企业软件、嵌入式、游戏、航空电子设备、互联网，实际上是任何领域。
您无需成为火箭科学家即可有效使用。 “纯粹的开发人员凡人”可以访问 ABSE。没有 oAW/MDA/XMI/GMF/etc 工具链中的复杂性。
其元元模型旨在支持从模型中 100% 生成代码。无需往返。元模型直接支持自定义/生成的代码组合。
可以同时操作模型。可以应用工作流程和版本控制（需要工具支持）。

这听起来像是在乌托邦方面，但实际上我已经离开了研究阶段，现在我正处于将上述所有内容付诸实践的 IDE 的实施阶段。我想我会在几周内（大约四月底）准备好一个基本的原型。 IDE（名为 AtomWeaver）是通过 ABSE 构建的，因此 AtomWeaver 将成为 ABSE 方法的第一个概念验证。

所以，这不是 MDA（谢天谢地！），但至少是一种非常易于管理的方法。作为 ABSE 的发明者，我对此感到兴奋是可以理解的，但我确信模型驱动软件开发将在 2009 年得到推动！

敬请期待……

【讨论】：

这听起来很有趣。如果您有一些关于它的博客文章，或者如果您希望其他人查看它并提供反馈，请告诉我。
目前还没有具体的博文，但您可以关注我的博客（请参阅我的个人资料）或我在模型驱动软件网络 (modeldrivensoftware.net) 上的讨论
我知道这是一个非常古老的答案，但如果可能的话，我很想知道你为什么说它是“谢天谢地！”不是 MDA？
@Yohsoog 我说的是众所周知的 MDA 及其子系统的复杂性。相比之下，ABSE 可能没有那么“强大”，但可以在更简单（尽管更长）的解决方案中实现相同的结果。

【解决方案3】：

模型驱动的软件开发仍然是一个小众领域，但已发表的案例研究和越来越多的其他文献表明，它比手动编码方法取得了成功。

OMG 的 MDA 只是一种方法，其他人正在使用领域特定语言（不使用 UML 进行建模）取得成功。

关键是从模型生成代码并在生成器没有生成您想要的内容时更新它 - 而不是修改您的代码。帮助您执行此操作的专业工具已经存在多年，但在过去五年左右的时间里，由于 Microsoft 进入该领域并通过 Eclipse 世界中的 openArchitectureWare 等开源项目，对这种方法的兴趣有所增加。

我经营着几个网站：www.modeldrivensoftware.net 和 www.codegeneration.net，在那里您可以获得关于这些主题的更多讨论、采访、文章和工具选项。

【讨论】：

酷，我去看看。我看过 codegeneration.net，但还没有看过 modeldrivensoftware.net。

【解决方案4】：

我从 1997 年开始研究模型驱动技术和 DSL，我对 MDE 越来越感兴趣。

我可以证明，在某些情况下，达到 10 倍以上的生产力（甚至可能更多；-）是可能的。我已经实现了许多模型驱动的软件工厂，它们能够使用非常简单的模型生成可执行软件，从持久层到 UI 层，都与它们生成的技术文档相关联。

但我不遵循 MDA 标准有几个原因。 MDA 承诺以 PIM 模型表达您的软件，并能够自动将其转换为一个或多个技术堆栈 (PSM)。

但是：

现实生活中谁需要针对多个技术堆栈？谁需要针对一个单一且定义明确的架构？
MDA 的魔力在于 PIM->PSM 转换，但迭代和增量方式的模型 2 模型转换很困难：
- model2model 的实现、调试和维护要比 model2text 复杂得多。
- 由于几乎不可能生成 100% 的软件，因此必须将细节添加到生成的 PSM 模型中，并在转换后保留转换。这意味着合并操作（3 路，以记住添加的细节）。在处理模型时，对象的合并图比文本合并要复杂得多（效果很好）。
- 您必须处理一个 PSM 模型（也就是说，一个看起来非常接近您最终生成的源代码的模型）。这对工具供应商来说很有趣，因为现成的 PSM 配置文件和相关的代码生成器可以随 MDA 工具一起销售和交付。

我提倡 MDE 策略，其中 PIM 是一种 DSL，它讲述您的逻辑架构（独立于任何技术堆栈），并使用自定义和特定代码生成器从该 PIM 生成代码。

优点：

您不必处理复杂的技术 PSM 模型。你有你的代码。
使用 DSL 技术，PIM 更高效、更可持续、更具表现力并且易于由代码和文档生成器解释。模型保持简单和精确。
它使您有义务尽早定义您的架构要求和概念（因为它是您的 PIM 元模型），独立于任何技术堆栈。通常，它是关于识别各种类型的数据、服务、UI 组件及其定义、功能和特性（属性、与其他概念的链接；...）。
生成的代码符合您的需要，因为它是自定义的。如果您生成的代码扩展了一些额外的手动维护的框架类，您可以使其更加简单。
您以多种正交方式利用知识：
- 模型利用功能/业务
- 代码生成器利用从您的逻辑架构组件到特定技术堆栈的技术映射决策。
- PIM DSL 将您的逻辑架构的定义大写
使用面向逻辑架构的 PIM，可以生成所有技术代码和其他非代码文件（配置、属性等）。开发人员可以专注于模型无法完全表达的业务功能的实现，通常不必再处理技术堆栈。
合并操作都是关于平面源代码文件的，这很好用。
如果您针对多个技术堆栈，您仍然可以定义多个代码生成器。

缺点：

您必须实现和维护自己的特定代码和文档生成器
一般而言，要充分利用 DSL 方法，您必须投资于特定工具（模型验证、特定向导、对话框、菜单、导入/导出...）。
在更新/改进 DSL 时，您有时需要迁移模型。通常这可以使用一些一次性迁移代码或手动完成（取决于影响）。
所有这些缺点都需要具有模型驱动技能的特定开发团队

这种特殊方法可以在具有 UML 配置文件或特定模型编辑器（文本或图形）的可扩展 UML 建模器之上实现。

MDA 和 MDE 的最大区别可以概括为：

MDA 是一组通用工具和语言，为每个人的需要提供现成的 md 配置文件和工具。这对于工具供应商来说是完美的，但我怀疑每个人的需求和背景都不同。
使用 MDE + 特定的 DSL 和工具，您需要一些辅助的熟练的模型驱动开发人员来维护您的自定义软件工厂（建模器、建模器扩展、生成器...），但您可以随时随地利用并管理非常简单-精确-可持续模型。

这两种方法之间存在某种利益冲突。一种主张重用现成的预资本化模型驱动组件，另一种则通过定义 DSL 和相关工具来实现自己的资本化。

【讨论】：

【解决方案5】：

我试过一次。大约在项目进行到一半时，我意识到我的模型与我的代码相比已经过时了，而且非常复杂，以至于让它们保持最新是令人望而却步的，这让我放慢了速度。

问题是软件充满了边缘情况。模型非常擅长捕捉大局，但是一旦您开始实际编写实现代码，您就会不断发现所有这些边缘情况，不久之后您会注意到模型过于精细，您必须在维护模型或获取模型之间做出选择写了一些代码。也许样板生成对启动有好处，但在那之后好处很快就消失了，我发现我的生产力急剧下降。这些模型最终从那个项目中消失了。

【讨论】：

谢谢。有趣的是，魔鬼在细节中。模型从定义上讲是过度简化，这就是给你带来最大痛苦的原因。 +1
模型驱动的软件开发是关于从模型中生成代码。您修改元模型、模型和生成器以修改或添加行为。它不是关于创建和维护一个独立的模型，在你更新代码时手动更新。
这正是我的观点。在某些时候，生成的代码不再有用。一旦你必须开始手动修改代码，这个过程就会崩溃。
这怎么可能是这个（实际上很有趣）问题的“正确”答案？顺便说一句：如果您需要向生成的类添加“手动”代码，有几种可用的策略。其中之一是在您的代码中定义生成器识别的受保护区域，并保护手动代码插入在生成时不被删除。大多数主要框架（oAW、acceleo）都支持这一点。

【解决方案6】：

我们确实使用 MDA 和 EMF 作为工具。它通过代码生成而不是手动编码为我们节省了大量工时。它确实需要高素质的分析，但这就是 IT 的意义所在。因此，我们主要关注问题本身以及执行代码生成和生成代码的运行时支持的工具/框架。最后，我可以确认使用 MDA 确实使我们的生产力提高了 10 倍。

【讨论】：