结构化分析中的数据流程图的 UML 类似物是什么？
回到黑暗时代（20 世纪 80 年代中期），我使用了 结构化分析相当多，并且发现它们非常有用。
我现在的雇主喜欢 UML。我通常使用 BOUML，它不做非 UML 绘图。
数据流图对应的UML图是什么？
如果没有，推荐使用哪种 UML 图来呈现相应的数据？
Back in the Dark Ages (mid-1980s), I used Data Flow Diagrams from Structured Analysis a fair amount, and found them very useful.
My current employer loves UML. I normally use BOUML, which doesn't do non-UML drawings.
What is the UML drawing that corresponds to the Data Flow Diagram?
If there isn't one, what is the recommended UML diagram to present the corresponding data?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（8）
最接近的可能是活动图。这并不完全相同；与 dfd 相比，受流程图的影响更大。但是：您可以在 DFD 中做一些有用的事情，例如 AD 确实支持并发并区分控制流和数据流。
有关比较和的更多详细信息此问题的差异。
[fwiw，我仍然使用 DFD：它们在许多情况下更简单、更优雅]
hth。
Probably the closest thing is the activity diagram. It's not quite the same; more influenced by flow chart than dfd. However: you can do some of the useful things in DFDs, e.g. ADs do support concurrency and differentiate control flow from dataflow.
More details on comparisons & differences in this question.
[fwiw, I still use DFDs: they're simpler and more elegant in many circumstances]
hth.
UML 2 非常类似于数据流图：
“信息流程图”。
信息流程图解释如下：
https://web .archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
请注意，UML 2.5 具有信息流和信息项，但术语“信息流图”不是官方 UML 2.5 图分类法的一部分。因此，形式上，您只需创建一个包含大量信息流的类或组件图即可获得“信息流图”。
我一直这样做，使用 UML 的信息项来表示我的数据。
UML 2 has a very good analogue to a data flow diagram:
the "information flow diagram".
Information flow diagrams are explained here:
https://web.archive.org/web/20121118061853/http://www.uml-diagrams.org/information-flow-diagrams.html
Note that UML 2.5 has information flows and information items, but the term "information flow diagram" is not part of official UML 2.5 diagram taxonomy. So formally, you just create a class or component diagram with lots of information flows in it to obtain your "information flow diagram".
I do this all the time, using information items of UML to represent my data.
OOD 中没有等效模型。 DFD 的重点是数据与功能分离。这在以程序方式处理时最有帮助。 DFD 的规模比 OOD 好得多，如果您尝试使用 OOD 进行扩展（到世界观），您最终会使用用例图，这对于捕获本质非常有用。我喜欢 DFD，它们是如此高级，但可以通过打开 DFD 框并将其称为级别 1 等进行扩展。
我目前正在学习 Go 编程语言，这在某些方面不使用任何对象我觉得 DFD 建模更适合它。
我也在寻找可以完成此类工作的图表。在 Go 中，结构体被广泛使用，它们是基本数据类型。您可以附加一个类似于面向对象的原始扩展方法，但事实上，如果您查看汇编代码，它似乎是函数的语法糖，其第一个参数是您希望函数操作的结构。
我的建议是，如果您正在编写 OO 代码，那么就使用 OOD。它们可以更好地映射，并且确实有助于思考系统。需要一段时间才能让你的头脑摆脱过程代码，特别是如果你来自 80 年代/90 年代的编程。一旦你进入了思考对象的状态，那么 OOD 方法就可以正常工作了。严格来说，它不是一种方法论，因为对于您使用哪些部分没有直接的答案，只是思考我认为最难的部分的对象。关于这方面的一本好书是《对象思维——大卫·韦斯特》……它有助于首先思考对象。一旦你开始就很难停止，你甚至可能会喜欢一些人最终陷入名词王国，这是一个可怕的地方，因为你编写了无尽的样板代码，只是为了完美地描述系统。这是一种编码地狱，我多年来一直远离它。
如果您使用允许过程性代码甚至混合 OO/过程性代码的语言进行编码，则需要在开始编码之前决定您的范例，例如在 Python 和 Object Pascal (Delphi) 中，您可以选择 OO 或过程性路线编码将代码混合成一堆混乱的范式。这将决定应该使用哪些图表工具，以及如何分析系统。
最近，Java 和 C# 发生了转变，以提供函数式编程技术。我发现这些不属于任何一类编程（OO 或过程式）。尝试将函数式编程代码映射到对象中是一场噩梦。
很抱歉我没有提供答案，但这取决于您编写的代码。
There is no equivalent model in OOD. The emphasis on DFD's is data separated from the function. This is most helpful when dealing in a procedural way. DFD's scale much better than OOD, if you try to scale out (to the world view) using OOD you end up using Use Case diagrams, which are useful for capturing essences. I loved DFD's they are so high level, and yet can be expanded by opening up a DFD box and calling it level 1 etc.
I am currently in the process of learning the Go programming language, this does not use Objects whatsoever and in some respects I feel that DFD modelling would suit it much better.
I too am looking for a diagram that could do this sort of work. In Go structs are used intensively which are basic data types. You can have a primitive extension method attached to it which resembles OO but in fact if you look at the Assembly code it appears to be syntax sugar for a function, who's first parameter is the struct you wish the function to operate on.
My advice, is that if you're doing OO code, then use OOD. They map better, and do help in the thinking about a system. It takes a while to get your head out of Procedural code, especially if you're coming from programming from the 80's/90's. Once you're in the zone with thinking about objects then the OOD methods work fine. Its not strictly a methodology as there is no straight answer to which parts you use, just thinking in objects I find to be the hardest part. A good book on this is "Object Thinking--David West"...it helps to think about objects first. Once you start its very difficult to stop, you may even like some end up getting trapped in the kingdom of the nouns which is a horrible place to be, because you write endless boiler plate code, just so that the system is described perfectly. This is a form of coding hell which I have stayed clear of for many years.
If you are coding in a language that allows procedural code, or even mixed OO/Procedural, you need to decide your paradigm before you start coding, for example in both Python and Object Pascal (Delphi) you can go either route of OO or procedural coding mixing the code up into a mess of paradigms. This will decide which diagramming tools that should be used, and how you are going to analyze the system.
Recently there have been shifts in Java and c# to provide functional programming techniques. These I have discovered don't fall into either category of programming (OO or procedural). Trying to map functional programming code into an object is a nightmare.
I am sorry I haven't provided an answer, but it depends on what code you are writing.
没有直接的类比，因为 UML 强调 OO 设计，而 DFD 来自结构化系统分析和设计 (SSAD)。在 UML 中，许多图，特别是交互图组中的那些图，都具有可以对数据流和处理元素进行建模的特征。通信图通常可用于反映 DFD 的大多数方面，而序列图可以对特定的流序列进行建模。如果您想建议 DFD 语义，那么您可以使用构造型对象进行数据处理和数据存储，并使用参与者作为外部实体。
值得注意的是，Sparx Systems Enterprise Architect 虽然主要是一个 UML 工具，但包含 DFD 作为扩展。
There is no direct analogue, since UML emphasises OO design wheras DFD comes from structured systems analysis and design (SSAD). In UML a number of diagrams, specifically those in the with interaction diagrams group have characteristics that might model elements of data flow and processing. A Communication Diagram can be used to reflect most aspects of a DFD in general, while a sequence diagram may model specific sequences of flow. If you wanted to suggest DFD semantics then you could use stereotyped objects for data process and data store, and use actors for external entities.
It may be worth noting that Sparx Systems Enterprise Architect, while primarily a UML tool includes DFD as an extension.
类似的图是：
Similar diagrams would be:
理论上，可以在 UML 中定义新的图类型，可以选择扩展一种或多种传统的图类型。 UML 中定义的规范图类型本质上被定义为 UML 元模型本身的一部分。
正式地，对象管理组发布的 UML 规范 中提供了 UML 元模型的定义(OMG)，以及 MOF 定义的相应元元模型 - 其中还有一个 相应的规范 -此外，伴随着正式的 OCL 规范，关于 UML 模型中约束的定义OCL 语言在 UML 中的应用 - 然后是 XMI 规范，就规范而言了解如何存储 UML 模型以机器可读的格式。
表面上，所有这些规范都可以组合起来应用，就像任何单个 UML 建模框架的“幕后”一样——无论是在 UML 元模型的 Ecore 子集的应用程序中，还是在规范的 UML 中。
回顾关于数据流图的简短学术演示 - 尽管有点偏离 UML 图类型的正式定义，但仍然在 MOF 元元模型的应用的更广泛的背景下 - 也许规范的 BPMN 元模型 - 以其传统的图形抽象语法 - 也许 BPMN 可以提供以下功能：与数据流程图的类比？
当然，建模实践可能会因供应商和应用程序环境而异。
Theoretically, new diagram kinds can be defined in UML, optionally extending of one or more conventional diagram kinds. The canonical diagram kinds defined in UML are essentially defined as a part of the UML metamodel itself.
Formally, a definition of the UML metamodel is provided in the UML specification published by the Object Management Group (OMG), as well as the corresponding meta-metamodel defined of MOF - to which there is also a corresponding specification - moreover as accompanied with the formal OCL specification, as with regards to definitions of constraints in UML models in applications of the OCL language in UML - and then there's the XMI specification, as with regards to specifications for how UML models may be stored in machine-readable format.
Ostensibly, all of these specifications may be combined for application as though "Under the hood" of any single framework for UML modeling - whether in applications of the Ecore subset of the UML metmodel, or in canonical UML.
Reviewing a short academic presentation about Data Flow Diagrams -although somewhat in departing from formal definitions of UML diagram kinds, but nonetheless in a broader context of applications of the MOF meta-metamodel - perhaps the canonical BPMN metamodel - in its conventional, graphical abstract syntax - perhaps BPMN may serve to provide something of an analogy to Data Flow Diagrams?
Of course, modeling practices may vary by vendor and by application environment.
我将数据流图视为序列图，数据生产者和数据消费者通过同步和/或异步消息创建、使用和销毁数据对象。
I consider a Data Flow Diagram as a Sequence Diagram, with Data Producers and Data Consumers creating, using and destroying Data objects by means of synchronous and/or asynchronous messages.
我使用 Enterprise Architect 的“动态视图”分析图。
控制=过程
信息 = 数据存储
在很多方面，他们的分析图比数据流图要好得多，因为您还可以以发送和接收的形式显示事件，并且也有一个过程符号，但我更喜欢控制。它包括目标和决定。
I use Enterprise Architect 'Dynamic View' Analysis diagram.
Control = Process
Information = Data Store
In many ways their Analysis diagram is much better than a data flow diagram, as you can also show events in the form of sending and receiving and there is a process symbol too but I prefer Control. It includes object and decision.