为什么我们都还没有进行模型驱动的开发？[关闭]

我是模型驱动开发的忠实拥护者，我认为它有可能提高生产率，质量和可预测性。当查看MetaEdit时，结果是惊人的。荷兰的Mendix成长非常迅速，并取得了不错的成绩。

我也知道有很多问题

• 生成器，模板和框架的版本控制
• 不适用于模型驱动开发的项目（重复次数不足）
• 更高的风险（当第一个项目失败时，您得到的结果要少于传统开发中得到的结果）
• 等等

但是，这些问题似乎仍然可以解决，其收益应超过所需的努力。

问题：您认为哪些最大的问题使您甚至没有考虑模型驱动的开发？

我想将这些答案不仅用于我自己的理解，而且还可以用作我计划编写的一系列内部文章的可能来源。

没有金锤。在一个领域中行之有效的在另一个领域则毫无用处。软件开发存在一些固有的复杂性，没有魔术工具可以消除它。

也许还会有人争辩说，只有当语言本身（或框架）不够高级而无法使用强大的抽象（使MDD相对毫无意义）时，代码的生成才有用。

有趣的问题！我承认，我不是狂热者，但是后来我尝试在适合您刚提出的一些问题的项目中多次使用模型驱动的开发。

这是我的原因清单：

• 学习曲线-建模工具发展迅速，以至于我很难找到对工具有深刻理解的工程师。我仍然发现您只不过是您的建模工具。诚然，下面的许多问题都可以追溯到这个问题-每当您认为工具过于局限时，就有可能对它不够了解。
• 过于结构化-就我个人而言，我发现建模工具过于结构化而无法描述所需描述的一切。一旦我切换到在工具外部绘制模型的一些细节，随着人们开始漂移到工具外部以查找信息，事情就会迅速消失。
• 调整工具的成本-每次我尝试自动生成代码时，一旦我看到工具的想法是正确的，就最终不得不手工重新编写代码。我知道经过几转之后，这个问题就减少了，但这意味着您必须在前几轮中幸存下来。我一般认为我们在玩弄痣-制造模型->生成代码->修复代码->更新模型->修复模型，冲洗并重复。
• 模型配置管理-由于模型描述了项目的大部分内容，因此在某种程度上，模型CM比内置代码更具交叉性。分隔建模文件本身就是一门艺术-做错了，您常常会陷入开发人员僵局，或者由于人们放弃并使用代码而导致模型过时。
• 上市时间-在迫切需要工作软件的情况下，我遇到了确定的问题。如果项目和团队足够小，我认为没有理由浪费时间在建模工具上，而可以将时间用于编码和测试。并非每个项目都足以要求此类投资。
• 失败的代价-当我看到项目无法使用建模工具时，这是因为失败的代价很高-要使用这些工具，则需要每个开发人员参与其中。这是对培训和动手学习的巨额投资，如果有人对模型进行了错误的设置，那将是一个非常昂贵的错误。我的经验是，要使模型正确，可能需要两个或三个版本才能发布-因此许多项目不能幸免于建模错误，而无法实现收益。

它已经被引用过了，但是没有Silver Bullet很好地说明了这一点：

软件实体的本质是互锁概念的构建：数据集，数据项之间的关系，算法和功能调用。这种本质是抽象的，因为在许多不同的表示形式下，这种概念构造都是相同的。尽管如此，它还是非常精确且详细的。

我认为构建软件的难点在于对​​该概念结构的规范，设计和测试，而不是对其进行表示和测试表示形式的真实性的劳动。当然，我们仍然会犯语法错误。但是与大多数系统中的概念错误相比，它们是模糊的。

如果这是真的，那么构建软件将总是很困难。本质上没有银弹。

后来，布鲁克斯指出了有关“自动编程”概念的以下内容：

近40年来，人们一直在期待并撰写有关“自动编程”或从问题说明中生成用于解决问题的程序的文章。今天有些人写道，他们希望这项技术能够提供下一个突破。

帕纳斯（Parnas）暗示该术语用于魅力，而不是语义内容，他断言：“总之，自动编程一直是使用比当前程序员可用的高级语言进行编程的委婉说法。”

他从本质上说，在大多数情况下，必须给出解决方案，而不是问题。

基本上，我认为MDD只是使用比以前更高级别的语言进行编程的另一种委婉说法。

这并不是说使用高级语言进行编程无济于事-实际上通常可以。但是问题的本质仍然是一样的：无论您使用的是多么出色的工具或多么出色的语言，最终，您都需要仔细考虑所有问题并解决问题。任何工具或任何过程都可以做的最好的事情就是消除“模糊”，因此您可以专注于重要的问题，正如Brooks所说的，“ 这个概念构造的规范，设计和测试 ”。

因为并非所有编程都是面向对象的，所以所有MDD工具似乎都希望这样做。UML本身基于对象的假定。当然，您可以使用顺序图对功能进行建模，但是很多时候都很笨拙。

因为像我这样的程序员从TDD获得的进步和结果要比MDD多。

因为建模！=编程。

因为成本/收益在成本方面太高，而在收益方面却不够。自从我上次查看MDD以来，情况可能已经改变，那时您需要支付> $ 6000 /座（USD）的价格才能拥有中等能力的工具。

因为足以描述生成代码功能的模型不再可用作模型。

因为像我这样的程序员只使用高级模型，然后使用代码确定细节。您在代码中看到的东西与在建模软件中看到的东西不同。

这些就是我个人不进行MDD的原因。我已经接触过它，但是没有什么能使我convert依。也许我太老了。也许我太新了（不管是什么学校）。它只是我自己无法支付的工具。

微软/苹​​果/谷歌没有推动它:)

哪种开发方式得到普及与工具，支持者和传福音有很大关系。没有大量支持者很难突破某些东西（Ruby on rails可能是个例外，但与Java / C＃/ Python相比仍然很小）

由于一条影响所有这些建模工具的简单法律，您知道CASE，UML等：

在程序员和他的代码之间进行转换非常昂贵。

如果这样做，则需要构建适当的编译器/解释器，代码生成器将导致糟糕的工作流程和对程序员的糟糕反馈（错误消息等）。

域驱动设计的深刻见解之一是模型应该在代码中，而不是在代码外部。

最终的问题是：为什么您的模型不适合代码？如果您正在进行嵌入式开发并且坚持使用C或需要为不同的平台生成代码，那么代码生成可能是值得的。对于其他所有人来说，更强大的编程语言和更好的代码设计通常比以代码以外的其他方式设计代码更好。

• 似乎无济于事，无济于事。
• 我似乎总是和一些极端的情况和奇怪的事情混为一谈，这些神奇的东西似乎从未真正起作用。
• OO不是灵丹妙药；向OO夸大软件生成方法论并不能使它变成白银。

但是我一般不喜欢企业解决方案。

我进行了讨论，很想做MDA，但是目前最大的缺点是工具支持。我正在使用MDA的派生类，我将其称为“运行时模型评估”，但稍后会介绍更多。

据我所知，MDA的缺点是：

• 缺少重构支持：让我猜想我想用MDA（典型用例1）对数据模型的实体建模。如果我有一个模型，可以说是一个UML图，并且我对其进行了更改，那么我的代码也没有任何变化（至少是生成的类），并且得到了一个具有更好命名属性的有效应用程序，而不是我必须手动纠正很多错误。
• 缺少调试支持：通常，通过使用某种转换语言来完成从模型到代码的转换。通常，这通常不会有问题，但是在调试时，最好不要担心生成的代码，调试器应该进入转换模型。相反，它进入生成的代码，众所周知，转换应该看起来不错，而不是生成的代码。Okey，我们可以很漂亮地打印出来，但是在最佳情况下，生成的代码是编译器的伪像，因此永远不必在编辑器中打开它进行调试会话（我可以接受它，并且从理论上讲，这个参数有点过头，但这是反对MDA的原因之一）
• 编码模型很容易：在其他示例中，模型可以对领域方面进行建模，然后将其编译为代码。是的，它是MDA，但是大多数MDA模型只是复杂的配置文件，可以在运行时轻松处理。
• 转换很难测试：如果在专用的IDE中使用转换，则转换是由IDE的“编译器”完成的。但是转换必须被视为应用程序代码的一部分，因此也应接受应用程序的测试和代码覆盖要求。

我目前更喜欢的是“运行时模型评估”（如果有人知道这个名称，请给我启发）。我的实体存储在普通的Java类中，而我需要进行“建模”的所有内容都由我在应用程序开始时读取的注释构成。不需要任何转换，正确设置我的元模型有点困难。

其他所有操作都是使用属性文件或XML进行的，用于分层数据。如果您有一个模型，那么它总是分层的，因此您无法建模，也无法用XML表示。而且，如果您需要一个特殊的模型编辑器（可能还必须编写），则可以构建一个甚至可以在应用程序运行时使用的编辑器，并使该应用程序比您可以建模的所有东西更具可配置性。

我感到大多数人使用弗雷德·布鲁克斯（Fred Brooks）的《 No Silver Bullet》来解释为什么人们不进行MDD的原因是在错过布鲁克斯提出的观点。当然，最终结论是，开发软件的实际，内在的复杂性永远不会消失，因此MDD无法解决这个问题。

但是Brooks甚至讨论这种内在复杂性的一个原因是将其与我们通常花费大量时间与语言，库和工具进行战斗的时间相比，即不处理我们要解决的问题的内在复杂性。因此，这正是MDD发挥作用的地方：消除所有的麻烦，并创建量身定制的语言，模型或其他形式主义，以应对当前的实际复杂性。

因此，从这个角度来看，没有“银弹”是投资MDD的绝佳理由。就是说，如果不是因为这个问题我认为会阻碍MDD的采用：模型驱动环境的实际开发使您能够完全专注于要解决的问题的内在复杂性要比只是直接用通用语言解决问题。主要是因为现有的MDD工具非常复杂。

像这样比较：用C编写程序比编写C编译器容易得多。为其他开发人员提供MDD环境不仅需要解决问题并使用通用语言来处理问题，还需要您基本上编写一个程序来解决问题空间中所有可能的与问题相关的问题。这非常具有挑战性。

据我所知，MDE和MDA不能充分满足嵌入式控制器开发人员的需求。当然可以使用模型来描述系统，但是我认为嵌入式开发人员不准备信任该模型来提供最佳甚至正确的源代码。

有许多Eclipse插件可让开发人员使用模型来创建/更新Java代码，或使用Java代码来创建/更新模型。这似乎是一个方便的工具。不幸的是，我所有的开发工作都是在ANSI / ISO C中完成的，并且我所知道的没有插件可以让我做同样的事情。

此外，开发人员如何指示模型在任何其他设计模式（或反模式）上将代码实现为事件驱动的HSM或其他设计模式？如果将代码手动更新为使用未知的设计模式，则模型可以准确地描述吗？

您如何实现那些不适合模型的功能？

答案很短……因为模型驱动通常与代码生成相关，并且代码易碎；我们需要的是消除代码和模型驱动，这肯定是可行的方法。

一些人驳回了这个问题，认为没有金锤子，软件开发本质上是复杂的。

我完全同意他们的观点，即没有金锤，但我不认为模型驱动是追求金锤或银弹！

我想更加复杂些。有两种复杂性，我称之为有机或自然复杂性，这是业务及其流程固有的复杂性，但我们也具有礼仪性的复杂性。

复杂性日复一日地逐步渗透到系统指令中。礼仪复杂性-不必要的复杂性-实质上是由于技术代码与面向业务代码的不受控制的篡改而产生的，而且还源于系统缺乏结构和统一性。

今天，困扰信息系统发展并导致故障和腰部的整个复杂性是礼仪性的复杂性。可以消除的复杂性。

礼仪的复杂性是浪费，代码造成的浪费，价值减少，变更不利，代码不变；必须减少到最低限度的代码。

怎么做？简单！首先，不要编写它，也不要生成它！

必要的不变技术规范；用于读取/写入，显示，通信的代码…通过描述数据的逻辑结构，模型就可以进入其中-我将以一种相关的方式添加-模型可以实现对标准读取/写入，显示和通信的通用处理数据。

这就像一个操作系统，您不会为使用的每个项目都重写它。因此，需要一种技术引擎来处理给定模型的软件的不变方面。我称其为AaaS（架构即服务）引擎。

至于不必要的代码，那是不必要的代码，因此最好不要编写。

这给我们留下了必须编写的，面向业务的代码，应设计的必需的面向业务的数据以及应设计和想象的必要的用户界面和经验。

通过消除脆弱的代码，我们可以将体系结构即服务作为软件开发的新范例，而更多的是基于建模和设计，而不是基于代码。

我相信有多种原因，但可以肯定的是，MDD不在大学课程中。通常，最接近的是一门讲授建模的课程，并且模型在那里停留为草图（无需检查，代码生成，在模型级别进行调试）。该“建模”课程通常还会介绍UML，并且学生困惑为什么在创建的模型的价值较低时却要学习如此庞大而复杂的符号。

将此与其他工程领域（例如嵌入式硬件开发人员或控制工程师）进行对比，在这些领域中，学生会获得完全不同的体验。使用Simulink或Labview之类的工具，学生可以绘制一个模型，然后为您生成代码，或者至少可以在模拟中运行它。

过去，大学曾教过编译器和解析器，但现在，他们应该教如何制作发生器，实现DSL等。

模型驱动开发是没有意义的，因为这是自上而下的编码方法模型。仅从模型创建完全运行的应用程序是不可能的，因此MDD毫无用处！！

我要做的是仅在更高抽象级别上使用UML来创建应用程序的框架。我的意思是创建程序包，类等，然后立即开始用Java语言编写代码。

我发现当我于2004年首次开始建模时，使用诸如Togethersoft，Omondo之类的工具进行实时同步确实很有用。Omondo最近引入了一个新阶段，该阶段是Java，模型和数据库ID之间的一种映射。非常强大，在我的项目中效果很好。

我的UML图现在可以帮助我加快项目速度，并且不再是无用的了:-)

MDD在开发过程中又增加了一步，这在没有好的模型的情况下是不利的一面，而第一个无法预测或几乎崩溃的部分市场解决方案很可能会赢得最多的收益。

具有可执行的业务流程模型一直是冬青。从理论上讲，您根本不需要程序员。实践证明，使用MDE，使实际模型正常工作就像编写代码一样复杂。

我想说，对于有经验的开发人员而言，填写从UML生成的类要容易得多，而不必为例如ExecutableUML烦恼。另一方面，对于ExecutableUML，您需要大量的计算机科学知识，因此您不能指望业务经理自己创建它。从理论上讲，他只会合并准备好的块（类），但是实际上，“胶水”是导致问题的原因。

同样，MDE的用途仅限于具有大量组件重用的系统。

MBSE-基于模型的软件工程是更相关的术语。

MBSE提出了有效的解决方案中的各种工具，因此需要不同的项目工作流程。DSML（特定领域建模语言）必须处于有效与利益相关者沟通审核需求所需的抽象级别。然后，您需要通过不断提高的改进级别来转换模型，以最终生成代码。

当您完全正确地实现了DSML和转换/生成过程后，生成工件的成本将非常低。但是直到您到达调试工具的那个阶段，这还是很痛苦的。

MDD的大多数成功案例都在产品线工程（PLE）领域，在该领域中，使用已建立的工具可以生成一系列类似的产品。当然，许多Java代码生成器实际上是MDD的简化版本。一些XML输入并生成代码。

你写了：

我也知道这里有很多问题……那些不适合模型驱动开发的项目（重复次数不够）

如果您的代码是重复的，则说明您选择的是糟糕的编程语言，或者使用得不好。使用更好的语言，就无需重复。考虑Ruby Active Record库。数据库表是通过编写迁移来创建的。无需在任何其他地方重复模式定义。您不必使用与表列相对应的数据成员来定义类。一行代码将一个类连接到一个表。

我将模型驱动的开发视为针对弱编程语言的一种复杂且效率低下的解决方法。