外部实体
系统边界外的数据来源或接收者,如读者、客户或其他系统,常用矩形表示。
认识 DFD 的四类元素
谁提供数据、怎样处理、存在哪里、交给谁——用四类图形表达清楚,并在同一张图中保持符号一致。
系统边界外的数据来源或接收者,如读者、客户或其他系统,常用矩形表示。
对输入数据进行校验、计算或转换,命名宜用“整理查询”“检索馆藏”等动宾短语。
需要保留并供处理读取或写入的数据集合,如馆藏记录、订单档案,不等同于某一种数据库。
箭头表示数据流向,标签写具体的数据名称;它不是操作步骤,也不是“是/否”控制分支。
处理也可用圆形、数据存储也可用两条平行线表示。选择一种符号体系后,避免在同一张图里混用含义。
同一个案例,逐层看清
以馆藏查询为例:先确认读者与系统交换的数据,再展开内部处理,保持边界输入与输出对应。
以上为简化概念示例,聚焦查询,不展开馆藏维护。层级编号在不同方法中可能不同,本页用“上下文图”和“首层分解图”说明两种观察范围。
从个人绘图到团队共识
数据流图需要业务、产品与开发共同确认。用 Boardmix 整理图形、连接线和补充说明,让讨论围绕具体的数据来源、处理规则与交付结果展开。
顺着每条输出追问:需要哪些输入、由哪个处理生成、最终交给谁。
区分外部系统、内部处理和数据存储,确认哪些信息需要跨边界交换。
把字段含义、业务规则和待确认事项附在图旁,让后续修改有据可查。
按业务场景开始
从社区案例理解系统的数据关系,再按自己的业务边界调整实体、处理和数据名称。
模板用于启发建模,使用时仍需核对符号、缺失的数据流和上下层平衡。模板使用条件以对应详情页为准。
先有边界,再补细节
先明确要回答的问题,再选择符号和层级,避免一开始就把所有细节挤进同一张图。
列出与系统交换数据的外部实体,写清输入与输出。先将整个系统视为一个处理,画出上下文图。
按数据的转换关系拆分处理,使用“核验订单”“生成报表”等动宾短语命名,补上处理需要读取或写入的数据存储。
在箭头旁写“订单明细”“查询条件”等数据名称。两个外部实体之间不直接连线;实体与存储、存储与存储之间的数据交换应经过处理。
逐项对照父图与子图的边界输入输出,检查每个处理的输出是否有足够输入支持,再邀请团队评审并记录修改结论。
有没有只接收却不产生输出的处理?有没有缺少来源却产生输出的处理?内部拆分后,原有的边界数据是否仍能一一对应?
继续了解 DFD 符号、分层方法,以及与其他系统图的区别。
数据流图(DFD)表达数据从哪里来、经过什么处理、存放在哪里,以及流向谁;箭头表示数据传递。流程图表达操作的先后顺序和判断分支。要说明审批是否通过或任务下一步做什么,可使用在线流程图;要分析系统中的信息流转,则使用数据流图。
常见四要素是外部实体、处理、数据存储和数据流。外部实体通常用矩形,处理可用圆形或圆角矩形,存储可用两条平行线或开口矩形,数据流用带名称的有向箭头。不同表示法的外形有所差异,一张图中应保持同一种约定。
上下文图把整个系统视为一个处理,只展示它与外部实体交换的数据;首层分解展开主要处理与内部存储,再按需要细化子图。资料对“0层”的编号存在不同约定,有的指上下文图,有的指第一次内部拆分。团队应先统一命名,并始终核对父图与子图的边界输入输出。
不能完全代替。数据流图侧重数据的流动与处理;ER图侧重实体、属性与关系;UML图可分别表达系统结构、交互或行为。可以围绕同一个业务分别绘制,通过统一的数据名称把它们联系起来。
可以注册账号,按当前免费权益开始创建与编辑。可编辑文件、导出、协作及 AI 等能力的额度以账号和价格页为准;社区模板可能有独立的使用条件。选择前先确认自己需要的功能与额度。
可以把业务描述交给 AI 辅助整理外部实体、处理和数据清单,再据此绘图。无论初稿来自 AI 还是模板,都要由熟悉业务的人检查系统边界、数据名称、连接关系与分层平衡,不能直接把初稿当作已经验证的系统设计。