物理数据流图

物理数据流图（Physical Data Flow Diagram, PDFD）详解

物理数据流图是结构化系统分析中的一种建模工具，用于描述系统在物理环境下的具体实现方式，包括硬件、软件、人工操作和物理文件等实际组成部分。它与**逻辑数据流图（Logical DFD）**互补，共同构成系统设计的完整视图。

---

1. 核心概念

• 定义：
  物理数据流图展示系统如何实际运作，聚焦于具体的实现细节（如技术选择、物理介质、人工流程等），而非抽象的业务逻辑。
• 目的：
  • 指导系统开发人员和技术团队实现系统。
  • 明确数据存储、传输和处理的实际载体（如数据库、API、纸质表格等）。

---

2. 物理DFD vs 逻辑DFD

维度	物理数据流图（PDFD）	逻辑数据流图（LDFD）
关注点	“怎么做”（How）	“做什么”（What）
内容	具体技术、设备、人工步骤	纯业务功能，无技术细节
示例	显示“MySQL数据库”“REST API”“Excel文件”	仅标注“存储客户数据”“生成报表”
适用阶段	系统设计阶段	需求分析阶段

---

3. 物理DFD的核心元素

符号	名称	描述	示例
矩形	外部实体（Physical Entity）	具体的人、部门或外部系统（需标明物理形式）。	“客服人员（通过Web表单输入）”
圆角矩形	处理过程（Process）	具体的处理方式（含技术实现）。	“Python脚本生成PDF报表”
箭头	数据流（Data Flow）	数据流动的物理载体（格式/协议）。	“JSON over HTTPS”“纸质订单”
双横线	数据存储（Data Store）	物理存储介质（数据库、文件等）。	“MongoDB集群”“Excel文件（本地）”
虚线框	系统边界	明确系统范围（内部 vs 外部）。	框内为待开发系统，框外为外部接口。

---

4. 物理DFD的绘制步骤

1. 确定物理边界：
   • 明确系统包含哪些硬件、软件和人工操作。
2. 映射逻辑到物理：
   • 将逻辑DFD的每个元素转换为具体实现（如“存储订单”→“MySQL的orders表”）。
3. 标注技术细节：
   • 为数据流和处理过程添加技术说明（如协议、工具、文件格式）。
4. 验证完整性：
   • 检查是否覆盖所有物理交互（包括备份、人工干预等边缘场景）。

---

5. 物理DFD示例（电商订单系统）

graph LR
    A[客户 \n(浏览器)] -->|提交订单\n(HTTP/JSON)| B(订单处理服务 \nNode.js)
    B -->|写入订单数据\n(SQL)| C[(订单数据库 \nMySQL)]
    C -->|生成日志\n(CSV)| D[日志分析员 \n(Excel)]
    B -->|调用支付\n(REST API)| E[支付网关 \n第三方系统]

关键说明：

• 数据流标注了具体协议（HTTP/JSON、SQL）。
• 数据存储明确为MySQL数据库和CSV文件。
• 外部实体区分了用户浏览器和人工操作。

---

6. 物理DFD的典型应用场景

• 系统架构设计：选择数据库、API协议或中间件（如Kafka）。
• 遗留系统改造：分析现有技术栈的交互瓶颈。
• 合规性文档：满足审计要求（如数据存储位置、传输加密方式）。

---

7. 优缺点分析

优点	缺点
明确技术实现，指导开发	容易陷入过度细节，忽略业务本质
暴露物理层面的风险（如单点故障）	需频繁更新（技术变更时需重绘）

---

8. 相关工具

• 绘图工具：Microsoft Visio、Lucidchart、Draw.io。
• 架构设计工具：ArchiMate（支持物理视图）、Enterprise Architect。

---

总结

物理数据流图是系统设计阶段的蓝图，将抽象的业务需求转化为具体的技术实施方案。它帮助团队：

1. 统一技术理解：避免开发人员对实现方式的歧义。
2. 识别物理依赖：如第三方服务、硬件限制等。
3. 优化性能与安全：通过分析数据存储和传输方式发现潜在瓶颈。

最佳实践：

• 先绘制逻辑DFD明确需求，再衍生物理DFD。
• 与UML部署图、组件图结合使用，全面描述系统架构。