DFD（数据流图）和活动图的区别
我需要了解这些差异才能了解如何正确使用它们。
DFD和活动图有哪些区别？
I need to know this differences in order to undestand how to use them right.
Which are the differences of DFD and Activity diagram?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（5）
事实上，这是合理的逻辑。你只需要看看名字就可以了。
在数据流程图中，“框”之间的线表示在系统组件之间流动的数据。由于这些仅显示数据流，因此不指示排序(1)。
在活动图中，这些线只是活动之间的转换，根本不代表数据流。它们更多地代表了活动和决策的顺序。您可以从这些中看出事情发生的顺序。
这是一个简单的解释，但应该是一个很好的起点。可以从 Wikipedia 获取有关 DFD 和 活动图。
(1) 还有另一种类型的图，即 UML 序列图，它可以显示特定会话类型的排序，例如（请参阅 Wikipedia 条目的 序列图):
时间从上到下增加，因此序列希望是显而易见的。
Actually, it's reasonably logical. You only have to look at the names.
In data flow diagrams, the lines between "boxes" represent data that flows between components of a system. Because these only show the flow of data, they do not give an indication of sequencing(1).
In activity diagrams, those lines are simply transitions between activities and do not represent data flow at all. They more represent the sequencing of activities and decisions. You can tell from these what order things happen in.
That's a simplistic explanation but should be a good starting point. Further information can be garnered from Wikipedia for DFDs and activity diagrams.
(1) There's another style of diagram, the UML sequence diagram, which can show sequencing for specific session types, such as (see Wikipedia entry for sequence diagrams):
This has time increasing from top to bottom so the sequence is hopefully obvious.
明显的偏见：我是 DFD 的支持者。
@John 是正确的，活动图可以用于表示对象流。 @pax 同样正确，但他们很少这样做。
DFD 对我来说有两大优势：
链接到对象模型。 DFD 上的数据存储提供了一种将生成/消耗的数据链接到对象模型的非常好的方法。对于一致性和确保您的思维是一致的非常有用。
他们不再强调控制流。设计时常常会过度限制测序。活动图确实支持并发 - 但它要求用户（a）记住并（b）使用它。所以默认是过度序列化。 DFD 则不然。它们暴露了真实的序列依赖关系，而用户无需付出任何额外的努力。因此，它们也让我们更容易看到因果关系。如果进程 a 和 b 都需要数据输入 D，那么在图表上就很明显了。因此并行活动是显而易见的。
不要误会我的意思 - 我并不反对活动诊断。如果控制流是主要考虑因素，我将使用 AD 而不是 DFD。但根据经验，我发现 DFD 在大约 70-80% 的情况下是更有用的工具。
当然，YMMV。
Explicit bias: I'm a DFDs proponent.
@John is correct that Activity diagrams can be used to represent object flow. @pax equally correct they seldom are.
Two big DFD advantages for me:
Link to object model. Data stores on a DFD provide a really nice way to link the data produced / consumed to the object model. Very useful for consistency and ensuring your thinking is joined up.
They de-emphasise control flow. Far too often designs over-constrain sequencing. Activity diagrams do support concurrency - but it requires the user to (a) remember and (b) use it. So the default is over-serialisation. DFDs don't. They lay bare the real sequence dependencies without any extra effort on the part of the user. Consequently they also make it easier to see causal relationships. If processes a and b both require data input D then it's obvious on the diagram. And hence parallel activity is obvious.
Don't get me wrong - I'm not against Activity diags. Where control flow is the primary consideration I'll use an AD over a DFD. But empirically I'd say I find DFDs a more useful tool in ~70-80% of cases.
Of course, YMMV.
这只是一个不得不向高层管理人员和首席信息官解释计算机和手动流程的人的拙见。我发现简单更好，而且当我实际“询问”细节时，DFD 能够传达信息。话虽这么说，更好的方法是始终练习故事情节并用简单的答案进行回答。
关于工具和产品时代的最后评论。请记住，在大多数情况下，这些人正在经营业务并且工作得非常好。格言“你打破它（或替换它），你就拥有它”可以让你成为英雄，也可以让你成为小丑。
我们有一位首席信息官想要更换所有大型机应用程序，原因很简单，因为它们是旧技术。人们必须权衡后果并了解替代者是否能够处理工作量。您有没有想过为什么摩根大通、瑞士信贷、沃尔玛和美国银行等仍然运行大型机？
我很抱歉朝这个方向发展。只要确保无论使用什么分析工具，替换的所有方面都被记录下来，包括工作负载、I/O、并发用户、采用曲线和可扩展性。
Just a humble opinion from someone who has had to explain processes, both computer and manual, to upper management and CIOs. I have found simple is better and pound-for-pound, DFDs get the message across when I am actually "asked" about details. That being said, the better approach is to always practice the story line and answer in simple answers.
One final comment regarding the age of tools and products. Remember that in most cases these are running the business and work pretty darn good. The adage "you break it (or replace it) and you own it" can make you a hero or make you into a clown.
We have a CIO who wants to replace all mainframe application for the simple reason that they are old technology. One must weigh the consequences and understand if the replacement can handle workload. Have you ever wondered why JPMC, Credit Swiss, Walmart, and Bank of America to name a few still run mainframes?
My apologies for taking it in that direction. Just make sure, whatever analysis tool is used, that all aspects of the replacement are documented including workload, I/O, concurrent users, adoption curve, and scalability.
数据流表示一个模块或一个独立代码内的流。然而，序列图表示不同模块之间的活动序列。是的，在某些时候他们可能会传递相同的信息。
我基本上在接口文档中使用
序列图，这些文档将与其他模块/元素共享，但是DFD将用于低级设计文档，该文档将用于开发代码在一个模块或网络元件内。Data Flowrepresents flow within one module or one independent code. HoweverSequence Diagramrepresents sequence of activity in between different modules.Yes at some points they may pass the same messages.
I basically use
Sequence diagramin interface documents which will be shared with other modules/elements, howeverDFDwill be used in Low level design documents which will be used to develop the code within one module or network element.如果我们仔细观察数据流图，我们可以注意到，当节点从其所有边缘收集数据时，它就会开始处理它们。为了进行处理，它需要一个活动令牌，它代表对处理器的访问。通常，获取该令牌的过程被省略，但它必须存在。通常，整个节点作为令牌放入双端队列中，在该队列的另一端存储自由活动（处理器或线程）。线程池是此类队列的完美示例，准备工作的节点表示为任务。一旦节点遇到活动，它们就会从队列中取出并开始实际处理。处理完成后，活动将返回到队列。这样我们就可以将活动视为一种特殊的代币。
因此，数据流和活动图都只是一般活动数据流图的简化变体，省略了活动或数据标记。但一般来说，这两种标记可以同时在图中表示。
程序员过去常常将线程视为活动，但如果我们仔细观察它们，我们会注意到，当线程准备好执行时，它会与处理器保持一致，并且只有当空闲处理器切换到该线程时才开始真正的执行。这绝对是类比，因为任务是在线程池上执行的。因此，从简化的角度来看，线程是一个活动，而从更严格的角度来看，线程是一个数据令牌，唯一真正的活动是物理处理器。这表明活动令牌与数据令牌没有什么不同。事实上，我们可以省略节点追逐活动的路线，并将数据流节点视为活动本身，当它的所有边（输入）都包含数据时，它立即开始工作。
If we look closer to a dataflow diagram, we can notice that when a node collects data from all its edges, it starts to process them. And to process, it needs an activity token, which represents access to a processor. Usually the process of obtaining that token is omitted, but it has to exist. Typically, the whole node as a token is put in a double-ended queue, where on the other end of that queue free activities (processors or threads) are stored. A thread pool is a perfect example of such a queue, and the nodes ready to work are represented as tasks. As soon as a node meets activity, they both are taken from the queue and actual processing starts. When processing finishes, activity is returned to the queue. This way we can think of activity as a special kind of token.
So both dataflow and activity diagrams are just simplified variants of a general active-data-flow diagram, with either activities or data tokens omitted. But generally, both kinds of tokens can be represented in a diagram simultaneously.
Programmers used to think about threads as activities, but if we look at them closer, we notice that when a thread is ready to execute, it gets in a line to processors, and real execution starts only when a free processor switch to that thread. This is absolute analogy as tasks are executed on a thread pool. So from simplified point of view, a thread is an activity, and from more rigorous point of view a thread is a data token and the only real activity is a physical processor. This shows that activity tokens are not different from data tokens. And indeed, we can omit the route of node chasing an activity and consider a dataflow node as an activity itself, which starts to work immediately when all its edges (inputs) contain data.