问对软件系统建模与在代码中进行建模有什么好处呢？

EN

建模软件系统与所有代码的优点是:我可以将模型安装在白板上。

我非常相信在一张纸上交流的魔力。如果我试着把代码放在白板上，当我教我们的系统给新的程序员时，根本就没有适合白板的抽象级别的代码。

我知道你所指的对模特的痴迷。人们做事情是因为他们以前就是这样做的，不去想他们为什么要这么做。我是来称之为形式主义的。我更喜欢非正式的工作，因为很难把愚蠢隐藏在传统的背后。

这并不意味着我不会时不时地拿出一个UML草图。但我永远不会要求你在编码之前提交一个UML文档。我可能要求你花5分钟时间来解释你在做什么，因为我无法忍受只有一个人能理解的代码的存在。

福勒指出了人们使用UML的不同方式，他称之为UML模式。所有这些方法的危险之处在于，它们可以被用来躲避有用的工作。如果你是用鼠标编写代码的话，我见过很多次尝试。还没见过有人让它真正发挥作用。如果你这样做是为了沟通，你最好确保别人理解你。如果你这么做是为了设计，你最好在工作中找到并解决问题。如果一切进展顺利，而且你的大部分时间都花在了让箭看起来很漂亮的时候，那就关掉它，回去工作吧。

最重要的是，不要产生一天以上有效的图表。如果你能做到的话，你就失败了。因为软件应该是软的。不要花上几个星期的时间就能得到正确的图表。告诉我怎么回事。如果有必要，就用餐巾纸。

也就是说，我更喜欢知道他们的UML和设计模式的程序员。他们更容易沟通。只要他们知道制作图表不是一项全职工作。

我的问题是，使用(非代码)文档将软件建模为软件设计真相的主要来源是否有意义？

不是的。这一点都说不通。您的代码是您的主要设计文档(即“软件设计真相的主要来源”)。只有代码才能准确地描述应用程序在编译器接受该设计并从中创建应用程序时所做的工作。

无论如何，要使用图表作为辅助设计文档，但如果它们不是由代码自动生成的，请注意，它们讲述的是与实际设计不同的故事。如果UML在您的船上浮动，请使用它。如果不是的话，用点别的吧。

有些人发现，在开始编写代码之前，用图表的形式勾勒出他们的思想是有用的。但记住鲍勃叔叔在这件事上说过的话：

“所以，是的，有时图表可能是不合适的。它们什么时候不合适?当你在没有代码的情况下创建它们来验证它们，然后打算遵循它们。画一个图表来探索一个想法是没有错的。”

如果您确实使用UML来探索一个设计，那么在开始编写代码时将它们扔掉。编写一个测试，然后编写一些代码以使其通过。重复一遍。这样，您最终将得到一个经过验证的设计。UML永远不能为您提供相同级别的设计验证。

我想问的是，使用(非代码)文档将软件建模作为软件设计真相的主要来源是否有意义。如果代码的很大一部分是从这些文档自动生成的，我就不会想到这种情况。如果是这样的话，我会把文档本身看作是源代码，而不是模型。

大量的非代码文档作为蓝图是有用的。也就是说，设计的“真理”应该遵循这个方向。这是一种为设计必须实现的元素建模的方法。您可以称它们为需求文档，但在我可以给出的所有示例中，这可能太强了。我已经通过PlantUML通过PlantText.com来生产这些。

• 用例图可以显示预期的特性和与用户或外部系统的交互。

• 活动图可以显示软件需要支持的业务流程。

• 状态图可以在网站上显示预期的动态：

• 提出了四种设计模式的静态模型和动态模型。例如，Memento:

我列举了这个过程的一些缺点，让我想知道为什么这么多人(在我的经验中)认为它是进行软件设计的最好方式。

如果您在体验之外对一些有关UML使用的真实信息感兴趣，那么有一些研究已经完成(我试图找到指向非付费文章的链接)：

• Petre，Marian (2013年)。UML在实践中。第35届软件工程国际会议(ICSE，2013年)，2013年5月18日至26日，美国加利福尼亚州旧金山，第722-731页。
• N. Mangano，T. D. LaToza，M. Petre和A. van der Hoek (2015年)。软件设计者如何与白板上的草图交互。见: IEEE软件工程交易，第41卷，第2期，第135至156页。
• 安德鲁·前锋和蒂莫西·C·莱斯布里奇。2008年。以模型为中心的软件开发与以代码为中心的软件开发的问题和机会:对软件专业人员的调查。“2008年软件工程模型国际研讨会论文集”(MiSE '08)，美国纽约州纽约ACM，27-32页。