我需要知道这些差异才能理解如何正确使用它们。
DFD和活动图的区别是什么？
答案 0 :(得分：20)
实际上，这是合乎逻辑的。你只需要查看名称。
在 data 流程图中，“框”之间的线表示在系统组件之间流动的数据。因为这些只显示数据流，所以它们没有给出测序的指示。
在活动图表中，这些行只是活动之间的转换，根本不代表数据流。它们更多地代表了活动和决策的顺序。你可以从中了解事情发生的顺序。
这是一个简单的解释，但应该是一个很好的起点。更多信息可以从维基百科中获取DFDs和activity diagrams。
答案 1 :(得分：14)
显性偏见：我是DFD的支持者。
@John是正确的，活动图可以用于表示对象流。 @pax同样正确，他们很少。
对我来说有两大DFD优势：
链接到对象模型。 DFD上的数据存储提供了一种将生成/消费的数据链接到对象模型的非常好的方法。对于一致性非常有用，并确保您的思维能够融合在一起。
他们不再强调控制流程。经常设计过度约束测序。活动图确实支持并发 - 但它要求用户（a）记住并（b）使用它。所以默认是过度序列化。 DFD没有。它们显示了真正的序列依赖关系，而无需用户做任何额外的努力。因此，他们也更容易看到因果关系。如果进程a和b都需要数据输入D那么它在图上是显而易见的。因此并行活动是显而易见的。
不要误解我的意思 - 我不反对Activity diags。在控制流程是主要考虑因素的情况下，我将在DFD上使用AD。但凭经验我会说在大约70-80％的情况下我发现DFD是一个更有用的工具。
当然，YMMV。
答案 2 :(得分：1)
来自那些不得不向高层管理人员和首席信息官解释流程（包括计算机和手册）的人的拙见。我发现简单的更好，更好，当我实际上“询问”细节时，DFD会传达信息。话虽如此，更好的方法是始终练习故事情节并以简单的答案回答。
关于工具和产品时代的最后评论。请记住，在大多数情况下，这些都在经营业务并且工作非常好。谚语“你打破它（或替换它）并拥有它”可以使你成为英雄或让你成为一个小丑。
我们有一位CIO想要替换所有大型机应用程序，原因很简单，因为它们是旧技术。必须权衡后果并了解替换是否可以处理工作量。你有没有想过为什么JPMC，瑞士信贷，沃尔玛和美国银行都列举了一些仍然运行大型机？
我很抱歉把它朝这个方向发展。只要确保使用任何分析工具，就可以记录替换的所有方面，包括工作负载，I / O，并发用户，采用曲线和可伸缩性。
答案 3 :(得分：0)
Data Flow表示一个模块或一个独立代码中的流。但是Sequence Diagram表示不同模块之间的活动顺序。
是的，在某些时候，他们可能会传递相同的消息。
我基本上在接口文档中使用Sequence diagram，它将与其他模块/元素共享，但DFD将用于低级设计文档，用于在一个模块内开发代码或网络元素。
答案 4 :(得分：0)
如果我们仔细观察数据流图，我们可以注意到，当节点从其所有边缘收集数据时，它会开始处理它们。要处理，它需要一个活动令牌，表示对处理器的访问。通常省略获取该令牌的过程，但它必须存在。通常，将整个节点作为令牌放入双端队列，在该队列的另一端存储空闲活动（处理器或线程）。线程池是这种队列的完美示例，准备工作的节点表示为任务。一旦节点满足活动，它们都将从队列中取出并开始实际处理。处理完成后，活动将返回到队列。这样我们就可以将活动视为一种特殊的令牌。
因此，数据流和活动图只是一般活动数据流图的简化变体，省略了活动或数据令牌。但通常，两种令牌都可以同时在图表中表示。
程序员过去常常将线程视为活动，但如果我们仔细观察它们，我们会注意到，当一个线程准备好执行时，它会进入处理器行，并且只有当一个空闲的处理器切换到那个帖子。这是绝对类比，因为任务在线程池上执行。因此，从简化的角度来看，线程是一种活动，从更严格的角度来看，线程是数据令牌，唯一真正的活动是物理处理器。这表明活动令牌与数据令牌没有区别。实际上，我们可以省略节点追踪活动的路径，并将数据流节点视为活动本身，当所有边（输入）包含数据时，它立即开始工作。