你现在是否正在进行模型驱动架构（MDA）？如果是，你使用哪些工具，它们的效果如何？

Question

你现在是否正在进行模型驱动架构（MDA）？如果是，你使用哪些工具，它们的效果如何？

10

模型驱动架构是一种思想，你可以创建模型来表达你需要解决的问题，这些模型不依赖于任何具体实现技术（或者至少大多数不依赖），然后你可以为一个或多个特定平台生成相应的实现。该方法声称在更高的抽象层次上工作更加强大和高效。此外，你的模型可以超越技术（所以即使你的第一种语言/平台过时了，你仍然有可用于下一代解决方案的东西）。另一个关键的好处是许多样板和“苦力活”都可以自动生成。一旦计算机理解了你的情境的语义，它就能更好地帮助你。

有人声称这种方法比传统方法提高10倍的生产力，并且这将是我们未来10年中都在使用的方法。

然而，这只是理论。我想知道的是当理论付诸实践时会出现什么结果。此外，“官方”的MDA版本来自OMG，并且看起来非常沉重。它基于UML，这可能会被认为是好还是坏（我倾向于“坏”）。

但是，尽管存在这些问题，但很难反驳在更高的抽象层次上工作并“教”计算机理解你的问题和解决方案的思想。想象一下一系列仅表达真相的ER模型，然后想象使用它们来生成你的解决方案的大部分内容，先是在一组技术中，然后再次在另一组技术中。

所以，我希望听听现在真正在做MDA的人（无论是“官方”还是非正式的）。你们使用什么工具？效果如何？你们能够实现多少理论承诺？你们看到真正的10倍效率提升吗？

- Charlie Flowers

6个回答

4

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

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

- 编程是关于问题分解的。 - 一切都可以表示为树形结构。

一些ABSE特点：

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

可能听起来有些理想化，但实际上我已经离开了研究阶段，现在正在实施阶段，正在开发一个将所有这些内容付诸实践的IDE。我认为我会在几周内（大约在4月底）准备好基本原型。该IDE（名为AtomWeaver）是通过ABSE构建的，因此AtomWeaver将是ABSE方法的第一个概念验证。

因此，这不是MDA（谢天谢地！），但至少是一种非常可管理的方法。作为ABSE的发明人，我对此感到兴奋，但我相信模型驱动软件开发将在2009年得到提升！

请继续关注...

- Rui Curado

听起来非常有趣。如果你有关于它的博客文章，或者想让其他人看看并提供反馈，请告诉我。 - Charlie Flowers

目前还没有具体的博客文章，但你可以关注我的博客（请查看我的个人资料）或者我在Model Driven Software Network上的讨论（http://www.modeldrivensoftware.net）。 - Rui Curado

我知道这是一个非常老的答案，但如果可能的话，我很想知道为什么你说它是“值得庆幸的！”而不是MDA？ - Yoh

1

@Yohsoog 我在谈论MDA及其子系统的复杂性。相比之下，ABSE可能不那么“强大”，但同样的结果可以通过更简单（尽管更长）的解决方案实现。 - Rui Curado

4

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

OMG 的 MDA 只是其中一种方法，其他人也展示了使用特定领域语言（不使用 UML 进行建模）的成功。

关键是从模型生成代码，并在生成器未生成所需内容时更新生成器，而不是修改代码。专业工具已经存在多年，但由于微软进入该领域以及像 Eclipse 世界中的 openArchitectureWare 这样的开源项目，对这种方法的兴趣在过去五年左右增长。

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

- Mark Dalgarno

好的，我会去看一下。我之前看过codegeneration.net，但还没有看过modeldrivensoftware.net。 - Charlie Flowers

1

我从1997年开始使用基于模型的技术和DSL，并且对MDE越来越热衷。

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

但我不遵循MDA标准，有几个原因。MDA的承诺是在PIM模型中表达您的软件，并具有将其自动转换为一个或多个技术堆栈（PSMs）的能力。

但是：

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

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

优点：

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

缺点：

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

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

MDA和MDE之间的主要区别可以概括如下：

MDA是一组通用的工具和语言，提供现成的md配置文件和工具，适用于每个人的需求。这非常适合工具供应商，但我怀疑每个人的需求和环境都不同。
通过MDE + 特定的DSL和工具，您需要一些补充的熟练的模型驱动开发人员来维护您的自定义软件工厂（建模工具、建模工具扩展、生成器...），但您可以在任何地方资本化并管理非常简单-精确-可持续的模型。

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

- Romain Bernard

0

我们使用MDA和EMF作为工具。这通过代码生成取代手动编码节省了大量的工时。需要高水平的分析能力，但这就是IT所涉及的。因此，我们主要关注问题本身以及进行代码生成和运行时支持的工具/框架。最后，我可以确认我们使用MDA实现了10倍的生产力增长。

- Vladimir Vaschenko

1

你能提供一个在你公司使用它的例子吗？你是如何使用它的？它解决了哪些问题？你看到使用它的人有哪些技能？ - H.Karatsanov

我们正在使用 MDA 开发具有非常丰富模型集的 ERP 平台。对于对象模型（PIM）开发，我们使用业务分析师。对于实现，我们使用 Eclipse Modeling Framework (EMF)。BPMN2 用于业务流程，Activiti 作为运行时引擎。对于 UI 模型，我们开发了自己的符号表示法，并以 Vaadin 作为实现基础。所有部分均基于开源和 Java。 - Vladimir Vaschenko

0

我曾经尝试过。大约在项目进行到一半的时候，我意识到我的模型已经与我的代码严重脱节，并且它们非常复杂，使得保持其更新变得困难且拖慢了我的进度。

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

- Jeremy Wall

谢谢。有趣的是魔鬼就在细节中。模型从定义上来说就是过度简化，这也是导致你最大痛苦的原因。+1 - Charlie Flowers

1

模型驱动软件开发是从模型生成代码的过程。您可以修改元模型、模型和生成器来修改或添加行为。它不是关于创建和维护一个独立的模型，该模型在更新代码时需要手动更新。 - Jeff Axelrod

这正是我的观点。在某个时候，生成的代码就不再有用了。一旦你必须开始手动修改代码，整个过程就会崩溃。 - Jeremy Wall

这怎么可能是这个（实际上相当有趣的）问题的“正确”答案呢？顺便说一下：如果您需要向生成的类添加“手动”代码，则有几种可用的策略。其中之一是在代码中定义受保护区域，这些区域由生成器识别，并保护手动代码插入不会在生成时被删除。大多数主要框架（oAW、acceleo）都支持此功能。 - mwhs

网页内容由stack overflow 提供, 点击上面的

可以查看英文原文，
原文链接

- Steven Huwig · Accepted Answer

这个问题没有得到回应，有点不祥的预感...也许我会让Dijkstra来回答它。

因为计算机出现在一个信仰科学技术进步和全面性的年代，所以回顾过去五个世纪人类的科学努力，就其最初目标而言，可以说是一个惊人的失败。众所周知，第一个也是最重要的目标是开发一种灵丹妙药，让喝它的人永葆青春。但由于永久贫困没有多少意义，科学界很快着手进行了第二个项目，即哲学石，使你能够制造需要的黄金。寻找理想的编程语言和理想的人机界面的追求，使软件危机消失如阳光下的雪，具有寻找灵丹妙药和哲学石的所有特征。这种追求得到两方面的强烈支持，首先是因为奇迹般的工作是你可以从计算机中期待的最小的，其次是来自社会的财政和政治支持，这个社会一直在寻求灵丹妙药和哲学石。可以区分两个主要流派，寻求哲学石和寻求灵丹妙药。寻求哲学石的前提是我们的“编程工具”太弱了。一个例子是认为当前的编程语言缺乏我们需要的“功能”。PL/I是其中一个更引人注目的假想石头。我仍然记得1968年Datamation上的广告，一个微笑的Susie Mayer在全彩色中宣布她通过转换到PL/I解决了所有的编程问题。几年后，可怜的Susie Mayer不再微笑，这一点是可以预见的。不用说，追求继续进行，适时地产生了下一个假想石头，以Ada的形式出现（在铁幕背后被称为PL/II）。即使是初学者的基本占星术也足以预测，Ada不会是这种类型的最后一块石头。另一系列以“编程工具”的形式出现的石头，是在“软件工程”的旗帜下生产的，随着时间的推移，软件工程试图用管理学科替代智力学科，以至于现在已经接受了“如果你不能编程该如何”的章程。