为什么大多数免费软件（例如Linux）上不使用UML？

我试图了解为什么大多数免费软件项目中未使用UML。例如，我的Debian / Linux系统可能有超过一万个免费软件包，我什至不能说出使用显式 UML框架和方法开发的软件包。例如，Qt的，GCC，Linux内核，庆典，GNU 化妆，ocaml的，侏儒，齐奏，lighttpd的，libonion，码头工人都是免费的软件项目，其中（据我所知）完全不提UML。

^{（我的猜测是UML非常适合开发任务的正式分包，而这不是自由软件的开发方式）}

请注意，尽管我确实阅读了一些有关UML的材料，但并没有声称对它有很好的理解。

实际上，我不能轻易地命名使用UML的自由软件（也许某些以自由软件实现的UML工具除外）。也许openstack是一个例外（其中提到了UML）。

^{（即使是旧的免费软件项目在启动后也可能采用了UML，但没有这样做）}

一些从事Papyrus研究的同事提到，大多数自由软件项目在开始时就没有任何明确（且足够深入）的形式化模型。而且，UML看起来与Java的关系要比它声称的要多得多（我不完全确定对于Ocaml或Common Lisp或Haskell或Java脚本是否有意义，甚至对于C ++ 11也不可能。）。也许敏捷软件开发不是很友好的UML。

又见这个答案的一个主题相关的问题。M.Fowler的博客设计死了吗？有见地。

^{PS。我认为这主要不是意见问题；自由软件应该有一些客观原因和一些基本特征，这可以解释原因。我倾向于猜测UML仅对形式化转包有用，并且仅在隐藏了一部分已开发软件时才有用，例如在专有项目中。如果这是真的，那么UML将与自由软件开发不兼容。}

^{注意：我自己不是UML迷。我不仅将UML定义为书面文档，还定义为软件工具的[元]数据格式}

有多种使用UML的方法。马丁·福勒（Martin Fowler）调用了这些UML模式，并确定了以下四种：UML为Notes，UML为Sketch，UML作为Blueprint，以及UML作为编程语言。

UML作为一种编程语言从未真正起飞。在该领域有一些工作使用不同的名称进行命名，例如“ 模型驱动的体系结构”或“基于模型的软件工程”。通过这种方法，您可以创建软件系统的高度详细的模型，并从这些模型中生成代码。在某些用例中，此方法很有用，但不适用于通用软件，特别是不适用于有能力提供支持此方法的工具的大型公司。这也是一个耗时的过程-我可以为一个类键入代码，而不是创建实现它所需的所有图形模型更快。

作为蓝图的UML通常表示“大型设计”项目。当然不是必须的。该模型也可以针对特定增量进行完整描述。但想法是，花费时间来创建UML模型形式的设计，然后将其移交给某人以转换为代码。阐明了所有细节，并且代码转换趋向于更加机械化。

作为草图的UML和作为注释的UML本质上相似，但是根据使用时间的不同而有所不同。将UML用作草绘意味着您将使用UML表示法草绘设计，但是这些图可能并不完整，但将重点放在您需要与他人进行交流的设计的特定方面。UML as Notes类似，但是模型是在代码之后创建的，以帮助理解代码库。

当您考虑这一点时，我认为以上所有内容对于任何一种建模符号都是正确的。您可以将其应用于实体关系图，IDEF图，业务流程建模表示法等。无论采用哪种建模表示法，都可以选择何时应用（作为规格之前，作为替代表示）以及多少细节（关键方面的全部细节）。

另一方面是开源文化。

通常，开源项目是从解决个人（或今天的公司）所遇到的问题开始的。如果是由个人启动的，则开发人员的数量为1。在这种情况下，通信开销非常低，几乎没有必要就要求和设计进行交流。在一家公司中，可能会有一个小团队。在这种情况下，您可能需要传达设计可能性并讨论取舍。但是，一旦做出了设计决策，就需要随着代码库随时间的变化而维护模型或将其丢弃。用敏捷建模术语，“连续记录”并维护“单一信息源”。

简短地说，有人认为代码是设计，而模型只是设计的替代视图。杰克·里夫斯（Jack Reeves）撰写了三篇关于代码作为设计的文章，并且在C2 Wiki上也进行了讨论，讨论了源代码是设计，设计是源代码以及源代码和建模的思想。如果您坚持这种信念（我愿意），那么源代码就是现实，应该存在任何图来理解代码，更重要的是，其背后的原因是代码的本质。

就像您提到的那样，一个成功的开源项目在全球都有贡献者。这些贡献者往往在为软件提供动力的技术上具有技术能力，并且很可能也是该软件的用户。参与人员可以像阅读模型一样轻松地阅读源代码，并且可以使用工具（IDE和逆向工程工具）来理解代码（如果需要，可以包括生成模型）。他们还可以自己创建流程草图。

在Fowler描述的四种模式中，我认为您不会找到使用建模语言作为编程语言或蓝图的开源项目或任何地方的很多项目。这样就可以将注释和草图用于UML。注释将由贡献者为贡献者创建，因此您可能找不到在任何地方上传的笔记。随着代码变得更加完整，草图的价值将降低，并且可能不会得到维护，因为这将使贡献者付出更多的努力。

许多开源项目没有可用的模型，因为它没有增加价值。但是，这并不意味着模型不是由项目早期的某个人创建的，也不意味着个人没有创建自己的系统模型。维护设计信息的一个源（源代码）只是时间更有效。

如果您想找人交换设计信息，我建议您查看供稿人使用的任何类型的论坛或邮件列表。这些论坛和邮件列表通常用作项目的设计文档。您可能找不到正式的UML，但在那里可能找到某种形式的设计信息和模型的图形表示。您还可以进入项目的聊天室或其他交流渠道-如果您看到人们在谈论设计决策，则他们可能正在与图形模型进行交流。但是它们很可能不会成为存储库的一部分，因为一旦达到了通信目的，它们就不会有价值。

让我们以Linux为例，

• 这不是一个面向对象的项目，某些部分，例如VFS可以在UML中建模，而其他部分则不能或不是很有效，即基本上只是直接转换struct成没有关系的类图。
• UML非常适合用于文档编制，可以使项目获得一些新知识。那不是Linux真正满足的，人们应该自己学习。
• 不确定要使用哪种UML工具，如果要维护某些东西，人们需要达成共识。有一个免费的Java应用程序，但是我认为没有人愿意使用它。
• 在90年代，GUI在Linux上仍然是一个挑战。只是去挖掘邮件列表档案，我敢打赌，除了在启动时显示的xpm格式的Linux本身徽标以外，您不会找到任何其他图形。纯文本是首选格式。
• 我认为没有人真正关心设计。人们关心功能，如果功能被接受，则将仔细检查代码。用例最好还是用语言来描述，就像POSIX和SUS这样的标准是如何编写的。
• 在社区中，操作系统领域的许多对象已得到很好的理解和标准化。例如，人们会知道struct in_addr内存中的外观，没有图表可以使它更清晰。
• UML在建模算法（例如内存分配器，调度程序，中断处理程序等）方面没有太大帮助。源可能更容易理解。

这些就是我在Linux项目设置中可以想到的东西。我想这更多是关于实用性的。奇怪的是，我不记得Tanenbaum在他的OS教科书中使用任何UML 来描述Minix。

也许值得一提，我也不在工作中使用UML。与我一起工作的大约20％的人知道UML的某些子集。

UML是一种表示形式，因此它是一种语言，出于争论的缘故，让我们假设其目的是将一个人的心理模型传达给另一个人。

我在寻找一种语言时所期望的是它在捕捉人的思维模式变化方面的效率。假设在写了一个人的模型的描述之后，需要做一个小的改变。必须对表示形式进行多大的更改？在文本语言中，一种测量的方法是diff在代码前后运行一个，并计算差异。在图形语言中，应该有一种类似的方法来测量差异。

恕我直言，我将一种语言称为“特定于域的”（DSL），以使其最小化上述措施，这在降低维护成本和错误方面具有明显的好处。如何制作DSL？有几种方法。最简单的方法之一就是仅使用现有编程语言定义数据结构和方法。这会将名词和动词添加到基本语言中，从而使说出想要的内容变得更加容易。（注意：我并不是希望DSL没有学习曲线。这可能是DSL的读者必须投入一次学习的费用。）

重要的一点是：在所有情况下，DSL必须包含使表达自己的模型的术语以及对模型的更改变得方便。由于对可能域的范围没有明显限制，因此没有单个DSL可以为所有域提供服务。

我对UML的印象是它试图做到的。