UML工具Visual Paradigm案例：证券交易平台数据流程图示例研究

Visual Paradigm是包含设计共享、线框图和数据库设计新特性的企业项目设计工具。现在你只需要这样单独的一款模型软件 Visual Paradigm就可以完成用UML设计软件，用BPMN去执行业务流程分析，用ERD企业设计数据库的任务。Visual Paradigm年终钜惠来袭，Visual Paradigm Modeler 订阅1年只需666元，现在抢购立享优惠！

下载Visual Paradigm最新试用版【慧都网】

数据流图（DFD）提供了系统内信息（即数据）流的直观表示。通过绘制数据流程图，您可以了解参与系统流程的人员所提供和传递的信息，完成流程所需的信息以及需要存储和访问的信息。本文以证券交易平台为例，介绍和解释数据流图（DFD）。
证券交易平台示例

上下文DFD

下图显示了为证券交易平台绘制的上下文数据流程图。它包含一个过程（形状），代表要建模的系统，在本例中为“证券交易平台”。它还显示了将与系统交互的参与者，称为外部实体。在此示例中，CS Assistant，客户和经纪人是将与系统进行交互的实体。在流程与外部实体之间，存在数据流（连接器），这些数据流指示实体与系统之间存在信息交换。

 

上下文DFD是数据流模型的入口。它仅包含一个进程，并且不显示任何数据存储。

1级DFD

下图显示了1级DFD，它是上下文DFD中所示的证券交易平台流程的分解（即分解）。通读该图，然后我们将基于此图介绍一些关键概念。

证券交易平台数据流程图示例包含五个流程，三个外部实体和三个数据存储。尽管没有设计准则可以控制形状在数据流程图中的位置，但是我们倾向于将过程放在中间，而将数据存储区和外部实体放在侧面，以便于理解。

根据该图，我们知道客户服务助理会向“开设帐户”流程提供客户详细信息。结果是将客户明细存储在客户数据存储中，将帐户明细存储在帐户数据存储中。尽管我们说过尝试存储客户和帐户详细信息是在客户服务助理提供详细信息之后进行的，但数据流程图并不意味着这种情况。我们的常识使我们以自然理解图表的方式来解释它。严格来说，该图仅告诉我们“开设帐户”流程收到的信息客户详细信息，并生成客户和帐户详细信息，但未指定订单。请注意，数据流图不会以什么方式和以什么顺序来回答整个系统中使用的信息。如果此信息很重要且值得一提，请考虑使用BPMN业务流程图或UML活动图之类的图对其进行建模。

流程Check Transaction从交易数据存储中接收交易明细，并将其传递给客户。

一个客户能存入现金通过提供存款金额，结果是更新的帐户余额存储在客户数据存储。

同样，客户可以提取现金。结果是他将收到提款金额，并且更新的帐户余额将存储在帐户数据存储区中。

最后，客户和经纪人都可以启动下订单过程，这导致交易明细存储在交易数据存储中。下订单流程还将交易详细信息传递到证券交易所中心，该中心是系统范围之外的实体。在下一节中，我们将介绍一种表示这种实体的方法。

2级DFD

就像上下文DFD中的流程一样，级别1 DFD中的流程也可以分解为更深层次的流程，甚至可以分解成更多层次的流程详细信息。下图显示了下订单流程的2级DFD 。

 

该DFD中的外部实体和数据存储与上层所示的外部实体和数据存储相对应（即，上图）。与众不同的是，将下达订单流程细分为下达订单（在线）流程和下达订单（离线）流程。

根据此图表，我们知道，客户可以进行下订单（在线）通过提供订购详细而经纪人可以进行下订单（电话）通过提供也令细节; 在两种情况下，都将交易细节存储在交易数据存储中并传递到证券交易中心。

使用构造型为“特殊类型”实体建模

刻板印象和标记值是对象管理组（OMG）引入的一种可扩展性机制。它允许设计人员扩展UML的词汇表，以便创建新的模型元素。作为一种软件设计工具，Visual Paradigm将对原型的支持扩展到非UML标准，例如DFD和ERD。以证券交易平台为例，我们可以为外部实体定义原型“第三方”。具有指定原型的外部实体被称为“一种第三方实体”。

注意细节级别

在此数据流图示例中，标记数据时，多次使用单词“ details”。我们有“客户详细信息”，“交易详细信息”等。如果我们将其明确写为“客户名称，电子邮件地址，工作，地址”以及“库存数量，金额，投标价格”怎么办？它是否正确？好吧，这个问题没有确定的答案，但是在做出决定时尝试问自己一个问题。为什么要绘制DFD？

在大多数情况下，数据流程图是在系统开发的早期阶段绘制的，其中许多细节尚待确认。诸如“详细信息”，“信息”，“凭证”之类的通用术语的使用无疑为讨论留下了空间。但是，使用通用术语可能会缺乏细节，从而使设计失去其用处。因此，这实际上取决于您的设计目的。

不要透支

在数据流程图中，我们专注于系统与外部各方之间的交互，而不是接口之间的内部通信。因此，接口与所使用的数据存储之间的数据流被认为是超出范围的，因此不应在图中显示。

不要混淆数据流和流程流

有些设计人员看到连接器从数据存储连接到流程时可能会感到不舒服，而看不到该图上以某种方式显示了数据请求的步骤。其中一些会尝试通过在流程和数据存储之间添加连接器来表示请求，将其标记为“请求”或“对某物的请求”，这是错误的。

请记住，数据流程图是为表示信息交换而设计的。数据流程图中的连接器用于表示数据，而不用于表示过程流，步骤或其他任何内容。当我们将以数据存储结尾的数据流标记为“请求”时，从字面上看，这意味着我们正在将请求作为数据传递到数据存储中。尽管在实现级别可能是这种情况，因为某些DBMS确实支持使用函数，这些函数会吸收一些值作为参数并返回结果，但在数据流程图中，我们倾向于将数据存储视为唯一的数据持有人，而不是具有任何处理能力。如果要对系统流或流程进行建模，请改用UML活动图或BPMN业务流程图。如果要对数据存储的内部结构建模，请使用实体关系图。