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

我经常在一张纸上画一个数据流。甚至我的小工具的计划都是在纸上完成的

存在UML。 问题是——我不喜欢它。我使用过的所有工具（Visio和许多在线编辑器）对我来说都不够灵活。用铅笔你可以很容易地画出形状，连接它们，描述它们

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

****评论中发布的有用链接：**

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

1）思维导图-我刚才试过，很喜欢，但放弃了。霍弗会再试一次

2）白板。这将是最简单和最自然的方法，除了拍照并将其存储在计算机上会使过程重复和无聊之外

还有其他有趣的想法吗？我真的很想听听其他人用什么来设计他们的软件和它的进展

---

非常感谢

有各种工具允许您基于文本输入创建图表。有一些预先学习，你需要学习语法。然而，这并不难做到。一旦你有了，创建图表可以非常快。有一些缺点；在大多数情况下，更改布局/样式的能力有限。这一点的重要性将取决于你是否喜欢他们的风格

数量越来越多，下面是一些您可能想看的：

• ：桌面应用程序，支持大多数UML和各种其他图表。还可以创建自己的自定义形状和连接器。自由和开放源码软件
• ：在线序列图
• ：桌面应用程序。重点是可执行模型，自动生成类图。自由和开放源码软件。它也有

---

hth.

我认为UML和代码应该使用类图混合使用。您使用类图（例如包、类等）对架构进行建模，然后对业务进行编码，最后在代码和模型之间进行多次迭代

---

我认为UML应该更多地面向代码，而不是关注文本输入。

如果Visio不够灵活，我建议使用带有白板软件的数字白板或触摸屏。经过一些调整后，你可能还可以使用一个简单的平板电脑（没有显示器），它们真的很便宜

---

关于纯软件：我们正试图用UML实验室实现一种“笔式”输入法，但它目前只支持类图…

你为什么要在纸上或计算机上手工绘制UML

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

或者，这样看：

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

你同意吗

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

如果您同意我的观点，我们将简化为3-4个类和序列图，即使对于包含数千个类的大型企业应用程序也是如此。为什么绘制和维护这些3-4图有什么大不了的

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

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

不，我们需要可视化模型来表示复杂的系统。人类大脑在处理视觉信息时似乎处于最佳状态。负责处理视觉图像的计算机是人脑中最大的系统

那么，什么是一个合理的解决方案来轻松地生成和维护UML模型呢

也许我们最好使用当前大量的UML工具来绘制3-4个高级UML图。如果您不喜欢使用它们，请选择下面的选项3

对于下一个抽象级别的图（任何有用的模型都应该有不同的抽象级别），从源代码生成UML。您可以生成类图和序列图

在这个敏捷方法的时代，为什么不编写shell类并生成3-4个高级UML类图和序列图呢？这样就不会有任何UML需要维护

源代码是真实的。

你能反驳那句话吗？如果不是，为什么不从源代码本身生成模型呢？我并不是建议采用往返工程