流程图与UML活动图

使用流程图和UML活动图之间的实际区别是什么？ 我有一些想法，但也许我在房间里丢了一头大象

流程图：

广泛使用

非程序员容易理解

老

UML活动图：

标准化

支持并发

不太熟悉的语法，但仍然足够简单

---

对于我特别记录应用程序逻辑的特定块的案例，我决定使用流程图。公司中更多的人将能够理解它们。

正如您所注意到的，活动图本质上可以包括并发性和时间安排。如果你看维基百科上的cribbed，如下所示，你可以看到两个沉重的单杠，以及两个平行的活动“当前想法”和“记录想法”。这被理解为“并行地开始这些活动，并且只有当两者都完成时才继续。”流程图不能用符号来表达这一点

实际上，使用活动图可以让您清楚地思考并发进程。我想你会发现任何能阅读流程图的人都会很快适应

借​西班牙维基百科用户Gwaur，通过Wikimedia Commons：

---

您可以从UML生成源代码，反之亦然；因此，您提到的“标准化”特性。

UML本身用于分享您的理解。以标准化的方式分享理解。由于您的案例是特别的，UML图的主要用途是提供非正式的草图，所以这里可以使用活动图。但流程图也可以，因为这里没有涉及到parellism。我总是觉得下面的论点很有帮助。我正在制作的人工制品将使谁受益？我可以用流程图以一种自解释的方式来表达流程吗。如果是的话，你应该继续使用流程图。但是如果你的类图、序列图等是UML格式的，那么为了一致性起见，将你的活动图也放在UML中是有意义的（这里的论点是，如果人们能够理解类图、序列图和UML语义，那么你就不需要活动图了。）。

这似乎是一种偏好，但是，如果我们有一种标准化的语言来描述软件系统，为什么还要使用其他语言呢？这会导致过度使用流程图的坏习惯。活动图非常简单。但是，如果您决定描述系统的一个更复杂的方面，或者尝试更改您正在描述的部分，您可能无论如何都必须切换。因此，只需使用UML，避免将来出现混淆。

根据网站：

在许多方面，UML活动图是结构化开发中流程图和数据流图（DFD）的面向对象等价物

发件人：

但是，流程图不包括和状态，操作流程图不能接收事件

---

可能这就是为什么流程图更容易理解，因为活动图具有面向对象开发和并发的概念。

我相信这更适用于类图。我还没有找到一个像样的往返生成器，它能够在代码更改时重建图表。@Vladimir Sinenko:如果你能生成实现活动模型逻辑的代码，不要试图寻找往返-只需更改活动模型-你将避免许多问题Hanks，Charlie，我在最初的帖子中也提到了这一点。在我的例子中，逻辑是单线程的，所以流程图和活动图都适合。假设一个标准更好，因为标准这么说，它就像（1）无限循环一样，最好不要进入。活动图以其自身的名称传播混乱，必须有一个原因，为什么没有人理解它们并提出类似的问题。