Do you use MDA/MDD/MDSD, any kind of model-driven approach? Will it be the future?编程语言在其历史上曾经历过几个(进化)步骤。有人认为，模型驱动的方法将是"下一件大事"。有诸如openArchitectureWare，AndroMDA，Sculptor / Fornax平台之类的工具，它们有望极大地提高生产率。但是，我的经验是，开始时很容易上手，但是在尝试一些意料之外的事情时容易陷入困境，或者很难找到足够的信息来告诉您如何启动项目，因为可能有很多事情要考虑。 我认为从模型驱动的东西中获取任何东西的重要见解是要理解模型不一定是一组漂亮的图片或树模型或UML，而是文本描述(例如状态机，业务规则)等等。)。 您如何看待，您的经验告诉您什么？模型驱动的开发是否有未来(或您可能想称呼的未来)？ 更新：这个主题似乎没有引起太多兴趣。如果您对模型驱动的方法有任何(好或坏)经验，或者为什么认为这一点都不有趣，请告诉我。 免责声明：我是业务应用程序开发人员。以下观点肯定是由我在企业IT领域的经验所塑造的。我知道，软件开发还有其他领域。特别是在工业和/或嵌入式系统开发中，世界可能看起来有所不同。 我认为MDSD仍然与代码生成息息相关。 仅当您的代码包含大量噪声和/或非常重复时，代码生成才有用。换句话说，当您的代码不能主要关注本质的复杂性，而是被偶然的复杂性污染时。 在我看来，当前平台和框架的趋势恰恰是消除意外的复杂性，并使应用程序代码专注于基本的复杂性。 因此，这些新的平台/框架使MDSD运动摆脱了很多风。 DSL(文本的)是另一种趋势，试图使人们仅关注本质的复杂性。 DSL可以用作代码生成的源，但它们并不主要与代码生成相关。 DSL(尤其是内部DSL)基本上允许它打开以在运行时进行解释/执行。 [运行时代码生成介于两者之间]。 因此，即使经常将DSL与MDSD一起提及，我认为它们确实是MDSD的替代方案。鉴于目前的炒作，他们也摆脱了MDSD运动的势头。 如果您已经达到了最终从代码中消除意外复杂性的目标(我知道这是虚构的)，那么您已经得出了业务问题的文本模型。这无法进一步简化！ 漂亮的方框和图表不会再简化或提高抽象级别！它们可能对可视化很有用，但即使这样也值得怀疑。图片并非始终是把握复杂性的最佳代表！ 此外，MDSD中涉及的工具的当前状态增加了另一种偶然的复杂性(认为：同步，差异/合并，重构...)，这从根本上简化了最终的简化目标！ 查看以下ActiveRecord模型，作为我的理论的一个说明：
我不认为这可以进一步简化。同样，任何带有方框和线条的图形表示都不会得到简化，也不会提供更多的便利(请考虑布局，重构，搜索，区分...)。 模型驱动开发已经存在了很长时间。 在早期尝试中，最成功的是詹姆斯·马丁斯综合工程设施"，该设施仍在CA周围销售，并且以" Coolgen"品牌极为冷淡。 那么，如果它是如此出色，为什么不占领世界呢？ 好了，这些工具擅长使简单的东西变得更简单，但是，它们并没有使困难的东西变得更容易，并且在许多情况下，使困难的东西变得更难！ 当您知道用Java / C / SQL或其他无关紧要的代码进行编码时，您可能会花费数小时试图说服4GL图形语言"正确地做事"。 我认为，这需要时间，直到工具变得更加完善，更多的人获得了使用MDD的经验。目前，如果您想从MDD中获益，则必须投入大量资金，因此其使用仍然受到限制。 以openArchitectureWare为例，例如：尽管它非常健壮并且存在基本文档，但是缺少内部工作文档，并且仍存在可伸缩性问题，这些都是未记录的-也许当Xtext和Xpand被重写时会变得更好。 但是，通过oAW消除这些限制本身就很容易，您可以像在Xtend和Xpand中一样吸引人地浏览模型，并且通过将多个工作流程组合成更大的工作流程，还可以完成非常复杂的事情。如果需要，您可以求助于Java，因此在模型处理方面具有很大的灵活性。同样，在oAW中使用Xtext编写自己的DSL也很快完成，但是基本上可以免费获得元模型，解析器和非常好的编辑器。您也可以基本上从任何地方获得模型，例如可以将数据库转换为元模型的组件，而无需费力即可编写相应的模型。 所以我想说，随着工具和经验的增加，MDD仍在建立。如果您具有必要的专业知识，并准备将其推入公司，它已经可以成功使用。最后，我认为这是一件非常好的事情，因为可以并且应该生成很多胶水代码(也称为复制粘贴)。我认为，使用MDD进行此操作是一种非常好的结构化方式，可促进可重用性。 我认为也许没有明确的答案-因此在这个问题上缺乏"兴趣"。 但是我本人在MDA方面有不同的经历。唯一一次获得良好体验的就是使用出色的工具-我曾经使用过TogetherSoft(我相信他们最终以某种方式落在了borland上)-他们是最早引入不是"代码生成"而是实际上是编辑代码的编辑的人之一。直接建模(这样一来，您就可以编辑代码或模型了)。他们还进行了重构(这是我记得它第一次发布在Smalltalk环境中)。 从那时起，我就再也没有看到MDA的普及性了，至少在主流方面没有了，因此就普及度而言，它似乎并不是未来(因此可以回答)。 当然，普及并不是全部，而且有回升的趋势，但是暂时，我认为MDA +工具被许多人视为"基于向导的代码生成"工具(无论它到底是什么)，所以我认为这真的需要一段时间甚至可能永远不会开始。 MDD的问题之一是，由于它在更高的抽象级别上工作，因此它也需要开发人员也可以在抽象级别上进行开发。这极大地减少了可以理解和使用这种方法的开发人员的范围。 当且仅当它使用的模型能够像编写应该生成的代码一样灵活时，模型驱动开发才是未来。我认为它现在表现不佳的原因是，您很难像基于文本的编程语言几十年来所做的那样"往返"。 使用基于文本的编程语言，更改模型就像更改几行代码一样简单。使用图形化编程语言(又称UML之类的MDD图)时，您必须找到一种方法，可以将该模型一直转换回其基于文本的等效模型(首先已经表现出很高的表达效率)，并且可以变得非常非常混乱 恕我直言，如果MDD从头开始构建，使其与基于文本的副本一样具有表现力和灵活性，那么它唯一有用的方法。尝试将现有的自上而下的图形设计语言(例如UML)用于使用分层抽象(例如编程语言)从下而上固有地构建的工具会造成巨大的阻抗失配。我还没全力以赴，但是MDD中仍然缺少一些东西，这使它像人们声称的那样有用。 我们在itemis(www.itemis.com)上大量使用模型驱动的软件开发。到目前为止，我们确实有很好的经验。舒尔不是灵丹妙药，但可以帮助提高软件质量，从而为我们的客户带来更多使用。
我认为这里的参与者是" No Silver Bullet"阵营的一部分(我肯定是)。如果MDA起作用(等于"大量节省")，那么我们肯定会知道的。问题是：在保持系统可管理性的同时，您可以走多远的"元"？当他们引入更正式的元元模型时，这就是UML 2.0的转折点。到目前为止，我还没有看到UML 2.0建模能力的真实用法(但是我的世界相当有限)。此外，采用模型驱动的方法只有两种选择：生成代码或运行时利用模型。最终的无约束代码生成器称为"人类"，而最终的运行时可以在4GL中找到(当今的当前数量是多少？)。也许这可以解释缺乏热情的原因。 这是一个很晚的答复，但是我目前正在寻找MDD工具来代替Rose RT，不幸的是Rhapsody已取代了Rose RT。我们处于实时，嵌入式和分布式C ++空间中，并且从MDD中获得了很多收益。我们正在努力开发更好的工具，并在我们的大型公司中更广泛地使用该工具。由于此处提到的一些很好的原因，这是一场艰苦的战斗。 我认为MDD只是编译器之上的一层，就像编译器高于汇编程序一样。我想要一个工具，让我作为架构师能够开发应用程序框架，并广泛地编辑代码生成(脚本)以使用该框架以及我们用于消息传递的任何中间件。我希望开发人员制作完整的UML类和状态图，其中包括生成应用程序和/或库所需的所有代码。 的确，您可以使用代码执行任何操作，但是我将大致总结一下MDD的好处，如下所示： 即使输入此内容，我也意识到您可以用代码完成所有工作。我喜欢在代码之上使用薄工具jsut来实现统一性，记录设计并简化重构。 我遇到的主要问题是我没有一个好的答案，因为这些模型没有标准的功能和文件格式。人们担心供应商会离开然后被卡住。 (我们基本上在Rose RT中发生了这种情况。)您在源代码中没有这种情况。但是，您将拥有该工具的最新版本以及最后生成的课程代码:)。我敢打赌，收益大于风险。 我还没有找到这样的工具，但是我试图让一些供应商听我的话，或者接受金钱来实现这一目标。 |
