UML 图是对软件建模的唯一方法吗

Question

我经常在一张纸上绘制数据流。甚至我的小工具的规划也是在纸上完成的。

存在UML。问题是 - 我不喜欢它。我使用过的所有工具（Visio 和许多在线编辑器）都不适合我的手。使用铅笔，您可以轻松绘制形状并将它们连接起来，描述它们。

为了以最快、最自然和最简单的方式创建数据流图、序列图等，您有什么建议，除了在计算机上而不是在纸上:)

****评论中发布的有用链接：** SO Link #1 SO Link #2

现在我对两件事很好奇，其中一件很久以前就在我的脑海中：

1)思维导图 - 我之前尝试过，很喜欢但放弃了。Hoever会再试一次

2）白板。这将是最简单、最自然的方法，只是拍照并将其存储在计算机上的某个位置会使该过程变得重复和无聊。

还有其他有趣的想法吗？我真的很想听听其他人正在使用什么来设计他们的软件以及它的进展。

非常感谢！

Answer 1

你为什么要手绘 UML，不管是在纸上还是在电脑上？

我同意您需要一个模型来表示设计。但即使在大约 500 人月的大型项目中，我观察到只有 3-4 个序列图真正重要并且有机会在应用程序的整个生命周期中幸存下来。那些 3-4 个序列图（以及表示它们静态时间关系的类图），通常表示应用程序的高级设计。

或者，这样看：

任何体面的企业应用程序都不会有 20 个不同的调用流。将有一个或两个通用（或抽象）调用流，所有具体用例都实现了这些调用流。让我们以一个简单的 Struts/EJB 应用程序为例。通用流程将类似于 - 一个操作类调用验证器，然后调用一个无状态会话 bean，后者又调用一个域类，后者将调用一个 DAO。应用程序的所有用例只是使用特定于该用例的具体类来实现此流程。

你同意？

如果您不知道，我想听听有 20 种不同调用流并在第一个版本发布后存活了 5 年的应用程序。

如果您同意我的观点，即使对于包含数千个类的大型企业应用程序，我们也将归结为 3-4 个类和序列图。为什么你如何绘制和维护这 3-4 个图表很重要？

您可能会说您想记录所有用例以用于培训或文档目的。在我过去 14 年在真实企业软件世界的经验中，我不记得看到过“维护良好”的 UML 文档。首先，好的文档很难生成，而且不常被发现。其次，它们大部分时间都与代码不同步。我的大部分经验都是与大型银行、保险公司、汽车公司等合作。这些环境太忙了，而且他们的资源有限（真的吗？我们是在说银行吗？是的，很难相信，但确实如此）以“维持”良好文档。

那么我是在建议我们摆脱 UML 吗？

不。我们需要视觉模型来表示复杂的系统。人类大脑在处理视觉效果时似乎处于最佳状态。负责处理视觉图像的视觉皮层是人脑中最大的系统。

那么，轻松生成和维护 UML 模型的合理解决方案是什么？

1. 可能我们最好使用当前的 UML 工具来绘制那些 3-4 个高级 UML 图。如果您讨厌使用它们，请检查下面的选项 3。
2. 对于下一个抽象级别的图（任何有用的模型都应该具有不同的抽象级别），从源代码生成 UML。您可以生成类图和序列图。
3. 在这个敏捷方法论的时代，为什么不直接编写 shell 类并生成那些 3-4 个高级 UML 类和序列图呢？这样就根本不需要维护任何 UML。

源代码是事实。

你能反驳这种说法吗？如果没有，为什么不从源代码本身生成模型？顺便说一下，我不是在建议往返工程。我只是建议单程旅行 - 从代码到模型。

然而，生成的 UML 有两个主要问题。

1. 当我们手绘一个类图时，我们展示了一个场景中涉及的类之间的关系。大多数现有的类图生成工具允许用户将 Java 类（源代码）放入工具中，并且该工具会自动显示类之间的关系。这里的问题是，人们如何知道一开始场景中涉及的类？
2. 第二个问题是生成的图表的冗长性。有一些工具可用于为场景生成运行时序列图和类图。但是图表往往非常冗长，违背了模型的目的，模型的目的是突出重要方面并过滤掉不重要的细节。

好的 UML 生成工具应该解决上述两个问题。Java 领域中有一些工具试图解决这些问题。检查下面的讨论：

我应该使用什么工具来可视化我的代码结构

是否有任何工具可以检测代码中的架构和设计模式？

我希望我回答了最初的问题：

还有其他有趣的想法吗？我真的很想听听其他人正在使用什么来设计他们的软件以及它的进展。

我是运行时 UML 生成工具MaintainJ 的作者，但我试图以客观的方式解决原始问题。欢迎您提出意见。