转向模型驱动架构方法有哪些好处和风险？

Question

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

我不是在寻找哪种工具比另一种工具更好的答案,而是更多地寻找从牛仔编码环境(即,很少计划和设计,只是跳入并开始编码)到模型驱动架构的体验.回顾它对您的组织有帮助吗？有哪些痛点？有什么风险？有什么好处？

Answer 1

我们当前的代码库结构不是很好，我们正在研究如何立即改进它[...]并转向模型驱动的架构方法，在该方法中，我们首先使用 uml 建模和设计所有内容，然后从该模型生成代码。

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

然而，你面前的工作似乎还有很多，还有很多不同方向需要改进的地方。我的第一个建议是不要试图立即改变一切。人们普遍不愿意改变，每个人都需要一些时间来消化新的改变。对于需要设置的内容达成共识也非常重要。这种共识不是一天就能形成的。这种改变需要中长期的承诺。

然后，关于 MDA，重要的是要注意它需要一些纪律。根据您的团队的不同，第一部分可能会先解决这个问题，为下一步做好准备，即引入 MDA。我这么说是因为你说你有一个“牛仔”流程，这意味着人们可能习惯于为所欲为——这对 MDA 来说是不行的。

然后是MDA本身的介绍。进行 MDA 的方法有很多种（我不会在这里详细介绍），但仍然占主导地位的方法是所谓的往返工程。那么最大的问题是保持模型和源同步。

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

另一种方法是不完全进行 MDA——不从模型生成代码——而是提高人们对建模和设计问题的认识，例如使用 UML。这样您就不会面临往返问题，但仍然可以提高软件开发过程的成熟度。