Architecture 转向模型驱动的体系结构方法的好处和风险是什么？

我在一家有350名员工的公司工作，我们正在成长。我们当前的代码库结构不是很好，我们正在研究如何立即改进它（通过将对象组织到名称空间、分离关注点等），并转向模型驱动的体系结构方法，在这种方法中，我们首先使用uml建模和设计所有内容，然后从该模型生成代码。我们一直在关注Sparx Systems Enterprise Architect（EA）（它支持UML 2.0），我们也在考虑VS 2010中的工具。我知道还有其他的工具（RationalXDE就是其中之一），但我真的不认为我们现在可以在每个许可证上花费1500美元以上

---

我不是在寻找哪个工具比另一个更好的答案，而是更多地寻找从牛仔编码环境（也就是说，很少的规划和设计，只是跳入并开始编码）到模型驱动架构的体验。回顾过去，它对您的组织有帮助吗？痛点是什么？风险是什么？好处是什么？

我们曾经用一个3 mloc物流计划系统做过一次，它工作得很好。然而，我们很早就意识到UML是不够的。它太迟钝了，无法捕捉到规范所需的详细程度。最好的方法实际上是使用伪代码（每个人都在用它来交流想法）！这就是实现的方式。使用UML感觉像是远离清晰性的一步

随着这些想法开始缩小到一个解决方案，一个版本控制系统被用来跟踪伪代码（和用例等）的变化。所以，小组中的每个人都跟着变化。一点一点的部分被翻译成实际的代码，以及文档、动机和讨论的参考

---

最后，从模型到代码的转换非常顺利。真正好的部分是使用vcs，它允许您在不切换环境的情况下甚至可以看到原始的伪代码。

我写了一篇关于模型驱动软件开发的学士论文，我只想警告您，使用好的方法来实现公司的目标非常重要。有很多事情可能会出错，例如，直接编辑生成的代码，只能生成一次，因为手动编辑的代码在生成后会被删除，您必须进行一些域分析以创建一个好的元模型并使用一个好的代码生成框架。。。请不要误解我，我认为MDSD很好，但请注意你将如何做到这一点。最初的MDA和关于它的书籍建议了非常糟糕的AppProach，它们太昂贵、太脆弱。我建议你看看voelter.de网站，在那里你可以找到Markus voelter的论文、演讲和播客，他是该领域非常有经验的顾问。

对我来说，关键是有时要务实。建模不应该是布尔活动（我们既不建模也不建模）。我们应该能够根据项目和公司的特点调整建模级别/精度（例如，请参见从事敏捷建模的人员所做的工作）。建模太少或太多可能会有问题（建模太少可能看不到好处，建模太多可能会对公司造成过度伤害，特别是在您开始过渡或没有所需工具的情况下）

在我的门户/博客（）中，我们经常讨论建模的好处或应该如何使用建模。你可能会觉得很有趣

我们当前的代码库不是结构化的 很好，我们都在看 如何立即改进[…] 并转向模型驱动 架构方法，我们在其中建模 首先用uml设计一切， 然后从该模型生成代码

首先，很高兴您和您的公司意识到您的软件开发过程中存在一些不足，并且有改进的意愿

然而，似乎有相当多的工作摆在你面前，还有许多事情需要在不同的方向上改进。我的第一个建议是不要试图立刻改变一切。人们通常不愿意改变，每个人都需要一些时间来消化新的变化。就需要设置的内容达成共识也是非常重要的。这一共识不会在一天之内形成。这种变化需要中期或长期承诺

然后，关于MDA，重要的是要注意它需要一些规程。根据您的团队的不同，第一部分可能很好地完成第一步工作，以准备下一步，即引入MDA。我这么说是因为你说你有一个“牛仔”的过程，这意味着人们可能习惯于做他们想做的任何事情——这是MDA的禁忌

然后介绍了MDA本身。有各种各样的方法来进行MDA（我在这里不详细介绍thsat），但仍然主要的方法是所谓的往返工程。最大的问题是保持模型和源代码的同步

（我的看法是，只有当模型可以在多个项目中重用时，MDA才能带来积极的投资回报。这意味着您必须已经识别了您反复做的事情，并且对问题有足够清晰的认识，以便能够创建一个足够完整的模型和转换，以便在整个项目中重用。如果每个项目完全不同，我认为MDA不起作用；获得正确的模型和转换等所花费的时间将比只使用代码和文档要长。）

另一种方法是不完全执行MDA——您不从模型生成代码——而是提高人们对建模和de的认识