转向模型驱动的建筑方法有哪些好处和风险？

Question

我在一家拥有约350名员工的公司工作，我们正在成长。我们当前的代码库的结构不太好，我们都在考虑如何立即改进它（通过将对象组织成名称空间，分开关注等）并转移到模型驱动的体系结构方法，我们首先使用UML建模和设计所有内容，然后从该模型生成代码。我们一直在大量寻找Sparx Systems Enterprise Architect（EA）（功能UML 2.0），我们还在考虑VS 2010中的工具。我知道还有其他工具（理性XDE是一个），但我真的没有认为此时我们可以花费$ 1500+。

我不是在寻找有关哪种工具比另一个工具更好的答案，而是为了从牛仔编码环境（即几乎没有计划和设计，只需跳入并开始编码）到模型驱动的体系结构而获得更多的体验。回顾过去对您的组织有帮助吗？有什么疼痛点？有什么风险？有什么好处？

Answer 1

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

首先，您和您的公司意识到您的软件开发过程中存在一些缺陷，这真是太好了，并且有一个 愿意改善.

然而，似乎您面前有很多工作，还有很多事情要改善不同的方向。我的第一个建议是不尝试改变 一切 立刻。人们通常不愿意改变，每个人都需要一些时间来消化新的变化。对需要设置的内容有一个共同的理解也非常重要。这种共同的理解不会在一天之内创造。这样的变化需要一个 中期或长期承诺.

然后，关于MDA，重要的是要注意到它需要一些 纪律. 。根据您的团队，第一部分很可能以准备下一步的方式首先进行该操作，这将是介绍MDA。我之所以这样说，是因为您说您有一个“牛仔”过程，这意味着人们可能会习惯于做任何他们想做的事情 - 这对MDA来说是不做的。

然后是MDA本身的引入。有多种方法可以执行MDA（我不会在这里扩展），但是仍然是这样做的主要方式是所谓的 往返工程. 。然后，最大的问题是保持模型和源同步。

（我的看法是，只有在模型可以重复使用多个项目的情况下，MDA才能获得积极的投资回报。这意味着您必须一遍又一遍地确定您所做的事情，并且对问题有足够的清晰观点，可以能够创建一个足够完整的模型和您可以在项目中重复使用的转换。我认为，如果每个项目完全不同，MDA都可以正常工作；将模型正确和转换等等的时间都大于仅处理代码和文档。）

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

Answer 2

我们使用3个MLOC物流计划者系统做到了一次，并且效果很好。但是，我们很早就意识到UML是不够的。这太钝了，无法捕获规范所需的细节级别。最好的方法实际上是使用伪代码（每个人都在使用它来传达想法）！这就是实现的方式。使用UML感觉就像是远离清晰度的一步。

随着想法开始缩小到解决方案，采用了版本控制系统，以跟踪伪代码（和用例等）的变化。因此，小组中的每个人都遵循了更改。刻薄的一部分被转化为实际代码，并提及动机和讨论。

最后，从模型到代码的转移非常顺利。恕我直言，非常好的部分是使用VCS，它使您甚至可以在不切换环境的情况下看到原始的伪代码。

Answer 3

我写了关于模型驱动的软件开发的学士学位论文，我只想警告您，使用良好的方法来执行公司打算做的事情非常重要。可能会出错很多事情，例如直接编辑生成的代码，只能生成一次，因为在一代之后将删除手动编辑的代码，您必须进行一些域分析才能创建一个好的元模型并使用良好的元素模型代码生成框架...请不要理解我错了，我认为MDSD很棒，但请注意如何做。原始的MDA及其书籍表明，非常糟糕的应用程序，太昂贵且过于脆弱。我建议您查看voelter.de网站，您可以在那里找到来自该领域非常有经验的顾问的Markus Voelter的论文，演示和播客。

Answer 4

对我来说，关键方面有时是务实的。建模不应是布尔活动（我们不是模型或不模型）。我们应该能够将建模级别/精度调整到项目的特征（例如，请参阅从事敏捷建模的人做什么）和公司。太少或太多的建模可能是有问题的（由于太少，您可能看不到好处，太多的公司可能会使您的公司过度犯罪，特别是如果您开始过渡或没有所需的工具）

在我的门户/博客中（http://modeling-languages.com）我们经常讨论建模的好处或应如何使用建模。您可能会发现它很有趣