我在一家拥有约 350 名员工的公司工作，我们正在成长。我们当前的代码库结构不是很好，我们正在研究如何立即改进它（通过将对象组织到命名空间、分离关注点等）并转向模型驱动的架构方法，在这种方法中，我们首先使用 uml 对所有内容进行建模和设计，然后从该模型生成代码。我们一直在认真研究 Sparx Systems Enterprise Architect (EA)（支持 UML 2.0），我们也在考虑 VS 2010 中的工具。我知道还有其他工具（Rational XDE 就是其中之一），但我真的没有认为此时我们可以为每个许可证花费 1500 美元以上。
我不是在寻找哪种工具比另一个更好的答案，而是更多地寻找从牛仔编码环境（即，很少的规划和设计，只需进入并开始编码）到模型驱动架构的体验。回顾它对您的组织有帮助吗？痛点是什么？有哪些风险？有什么好处？
我们曾经使用 3 mloc 物流规划系统做过一次，效果很好。然而，我们很早就意识到 UML 是不够的。捕捉规范所需的详细程度实在是太迟钝了。最好的方法实际上是使用伪代码（每个人都在使用它来交流想法）！就这样实现了。使用 UML 感觉就像离清晰一步之遥。
随着想法开始缩小到解决方案，采用了版本控制系统来跟踪伪代码（和用例等）的变化。于是，群里的每个人都跟着变化。一点一点的部分被翻译成实际的代码以及文档和对动机和讨论的引用。
最后，从模型到代码的转换非常顺利。真正好的部分是，恕我直言，使用 vcs 甚至可以让您在不切换环境的情况下查看原始伪代码。
我写了关于模型驱动软件开发的学士论文，我只是想警告你，使用一种好的方法来完成你公司的意图是非常重要的。有很多事情可能会出错，比如直接编辑生成的代码，只能生成一次，因为手动编辑的代码在生成后会被删除，你必须做一些领域分析来创建一个好的元模型并使用一个好的代码生成框架...请不要理解我的错误，我认为 MDSD 很棒，但请注意你将如何做。最初的 MDA 和有关它的书籍提出了非常糟糕的方法，这些方法太昂贵且太脆弱。我建议您查看 voelter.de 网站，在那里您可以找到 Markus Voelter 的论文、演示文稿和播客，他是该领域非常有经验的顾问。
对我来说，关键是有时要务实。建模不应该是布尔活动（我们既不建模也不建模）。我们应该能够使建模级别/精度适应项目的特征（例如，看看从事敏捷建模工作的人是做什么的）和公司。建模太少或太多都可能有问题（太少您可能看不到好处，太多可能对您的公司造成过度杀伤，特别是在您开始过渡或没有所需工具的情况下）
在我的门户/博客 ( http://modeling-languages.com ) 中，我们经常讨论建模的好处或应该如何使用建模。你可能会觉得很有趣
我们当前的代码库的结构不是很好，我们正在研究如何立即改进它 [...] 并转向模型驱动的架构方法，我们首先使用 uml 建模和设计所有内容，然后从该模型生成代码。
首先，很高兴您和您的公司意识到您的软件开发过程中存在一些缺陷并且愿意改进。
然而，您面前似乎还有很多工作要做，还有很多事情需要在不同的方向上改进。我的第一个建议是不要试图一次改变一切。人们普遍不愿意改变，每个人都需要一些时间来消化新的变化。就需要设置的内容达成共识也非常重要。这种共识不是一天就能形成的。这种改变需要中期或长期的承诺。
然后，关于 MDA，重要的是要注意它需要一些纪律。根据您的团队，第一部分可能会首先着手准备下一步，即引入 MDA。我这么说是因为你说你有一个“牛仔”流程，这意味着人们可能习惯于为所欲为——这对 MDA 来说是不行的。
然后是 MDA 本身的介绍。做 MDA 的方法有很多种（我不会在这里详细介绍），但仍然占主导地位的方法是所谓的往返工程。那么最大的问题是保持模型和源同步。
（我的看法是，只有当模型可以在多个项目中重复使用时，MDA 才能带来正的投资回报。这意味着您必须一遍又一遍地确定您所做的事情，并对问题有足够清晰的认识能够创建一个足够完整的模型和转换，您可以跨项目重用。如果每个项目完全不同，我不相信 MDA 会起作用；获得正确的模型和转换等所花费的时间将大于仅使用代码和文档。）
另一种方法是不完全做 MDA——你不从模型生成代码——而是提高人们对建模和设计问题的认识，例如使用 UML。这样您就不会面临往返问题，但仍然可以提高软件开发过程的成熟度。