物理数据流图
物理数据流图（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的绘制步骤
- 确定物理边界：
- 明确系统包含哪些硬件、软件和人工操作。
- 映射逻辑到物理：
- 将逻辑DFD的每个元素转换为具体实现（如“存储订单”→“MySQL的orders表”）。
- 标注技术细节：
- 为数据流和处理过程添加技术说明（如协议、工具、文件格式）。
- 验证完整性：
- 检查是否覆盖所有物理交互（包括备份、人工干预等边缘场景）。
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。
总结
物理数据流图是系统设计阶段的蓝图，将抽象的业务需求转化为具体的技术实施方案。它帮助团队：
- 统一技术理解：避免开发人员对实现方式的歧义。
- 识别物理依赖：如第三方服务、硬件限制等。
- 优化性能与安全：通过分析数据存储和传输方式发现潜在瓶颈。
最佳实践：
- 先绘制逻辑DFD明确需求，再衍生物理DFD。
- 与UML部署图、组件图结合使用，全面描述系统架构。