UML与结构化分析中的数据流图有什么相似之处？

在黑暗时代（20世纪80年代中期），我使用了大量的，并且发现它们非常有用

我现在的雇主喜欢UML。我通常使用BOUML，它不做非UML绘图

与数据流图相对应的UML图是什么

---

如果没有，建议使用什么UML图来表示相应的数据？

最接近的可能是。不太一样；比dfd更受流程图的影响。然而，您可以在DFD中做一些有用的事情，例如，ADs确实支持并发性并区分控制流和数据流

更多关于比较和差异的详细信息

[fwiw，我仍然使用DFD：它们在许多情况下更简单、更优雅]

---

hth.

没有直接的类比，因为UML强调OO设计，而DFD来自结构化系统分析与设计（SSAD）。在UML中，许多图，特别是那些在with interaction diagrams组中的图，具有可能对数据流和处理的元素建模的特征。通信图通常可用于反映DFD的大多数方面，而序列图可对特定的流序列进行建模。若您想建议DFD语义，那个么您可以将原型对象用于数据处理和数据存储，并将参与者用于外部实体

---

值得注意的是，Sparx Systems Enterprise Architect主要是一个UML工具，它包括DFD作为扩展。

在OOD中没有等效的模型。DFD的重点是从函数中分离数据。这在以程序方式处理时非常有用。DFD的可伸缩性要比OOD好得多，如果你试图使用OOD向外扩展（到世界视图），你最终会使用用例图，这对捕捉本质很有用。我喜欢DFD的，他们是如此的高水平，但可以通过打开一个DFD盒并称之为1级等来扩展

我目前正在学习Go编程语言，它不使用任何对象，在某些方面我觉得DFD建模更适合它

我也在寻找一个可以做这种工作的图表。In-Go结构被广泛使用，这是一种基本的数据类型。可以附加一个类似于OO的基本扩展方法，但事实上，如果查看汇编代码，它似乎是函数的语法糖，第一个参数是希望函数操作的结构

我的建议是，如果你在做OO代码，那么就使用OOD。它们可以更好地绘制地图，并有助于思考系统。你需要一段时间才能从程序代码中清醒过来，特别是如果你是80/90年代的编程专家。一旦你进入思考对象的区域，那么OOD方法就可以很好地工作。这并不是严格意义上的方法论，因为没有直接的答案来回答你使用哪一部分，只是思考我发现最难的部分。关于这方面的一本好书是《物体思考——大卫·韦斯特》……它有助于首先思考物体。一旦你开始它很难停止，你甚至可能像一些人一样被困在名词的王国里，这是一个可怕的地方，因为你写了无数的锅炉板代码，只是为了完美地描述系统。这是一种编码地狱的形式，我多年来一直不知道它的存在

如果您使用的是一种允许过程性代码的语言，甚至是混合OO/过程性的语言，那么在开始编码之前，您需要确定您的范例，例如在Python和Object Pascal（Delphi）中，您可以选择OO或过程性编码，将代码混合到一堆范例中。这将决定应该使用哪些图表工具，以及如何分析系统

最近，Java和c语言在提供函数式编程技术方面发生了变化。我发现这些不属于编程的任何一类（OO或过程）。试图将函数式编程代码映射到对象是一场噩梦

---

很抱歉，我没有提供答案，但这取决于您正在编写的代码。

理论上，新的图表类型可以在UML中定义，可以选择扩展一种或多种传统的图表类型。UML中定义的规范图类型本质上被定义为UML元模型本身的一部分

形式上，由对象管理组（OMG）发布的中提供了UML元模型的定义，以及MOF定义的相应元元模型，其中也有一个，此外，与形式化，关于UML中OCL语言应用程序中UML模型中约束的定义，还有，关于如何以机器可读格式存储UML模型的规范

从表面上看，所有这些规范都可以结合起来应用，就像在任何一个UML建模框架的“引擎盖”下一样——无论是在UML metmodel的Ecore子集的应用程序中，还是在规范的UML中

回顾——虽然在某种程度上偏离了UML图类型的正式定义，但在MOF元元模型（可能是规范元模型）应用的更广泛背景下，回顾其传统，图形抽象语法-也许BPMN可以提供一些类似于数据流图的东西？

---

当然，建模实践可能因供应商和应用程序环境而异。

UML2非常类似于数据流图： “信息流程图”

信息流程图如下所示：

注意，UML2.5有信息流和信息项，但术语“信息流图”不是官方UML2.5图分类法的一部分。因此，形式上，您只需创建一个包含大量信息流的类或组件图