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