functional-diagrams

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Functional Diagrams

功能图表

Overview

概述

Functional diagrams describe systems in terms of processes, data flows, and transformations rather than objects or containers. They answer the question "what does the system do with data?" and "how are functions decomposed into sub-functions?"
This skill covers four complementary functional diagramming techniques:
  1. Data Flow Diagrams (DFD) — Show how data moves through a system
  2. Functional Decomposition — Break high-level functions into sub-functions
  3. IDEF0 — Model decisions, actions, and activities with inputs, controls, outputs, and mechanisms
  4. BPMN — Model business processes with standardized notation
功能图表从流程、数据流和转换的角度描述系统,而非从对象或容器的角度。它们回答了“系统如何处理数据?”以及“功能如何分解为子功能?”这类问题。 本文涵盖四种互补的功能图表绘制技术:
  1. 数据流图(DFD) —— 展示数据在系统中的流动路径
  2. 功能分解 —— 将高层级功能拆分为子功能
  3. IDEF0 —— 通过输入、控制、输出和机制对决策、操作和活动进行建模
  4. BPMN —— 使用标准化符号对业务流程进行建模

Data Flow Diagrams (DFD)

数据流图(DFD)

DFDs show how data is processed by a system. They use four core element types and are organized into hierarchical levels.
DFD展示系统如何处理数据。它们使用四种核心元素类型,并按层级结构组织。

DFD Elements

DFD元素

ElementSymbolDescription
ProcessCircle or rounded rectangleTransforms input data into output data
Data StoreOpen-ended rectangle (parallel lines)Repository where data is held for later use
External EntityRectangle (square)Source or sink of data outside the system boundary
Data FlowArrow with labelMovement of data between elements
元素符号描述
流程圆形或圆角矩形将输入数据转换为输出数据
数据存储开口矩形(平行线)用于存储数据供后续使用的仓库
外部实体矩形(正方形)系统边界外的数据来源或接收方
数据流带标签的箭头元素之间的数据移动路径

DFD Levels

DFD层级

DFDs are organized hierarchically, with each level providing more detail:
┌─────────────────────────────────────────────────────────┐
│ Context Diagram (Level -1)                               │
│                                                          │
│  ┌──────────┐    order     ┌──────────┐   receipt       │
│  │ Customer  │────────────►│  Order    │──────────►      │
│  │ (External)│◄────────────│  System   │   ┌──────────┐ │
│  └──────────┘  confirmation│ (Process) │──►│ Warehouse│ │
│                             └──────────┘   │ (External)│ │
│                                            └──────────┘ │
│  Shows: entire system as ONE process                     │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Level 0 Diagram                                          │
│                                                          │
│  ┌──────────┐  order   ┌─────────┐  valid   ┌────────┐ │
│  │ Customer  │────────►│ 1.0     │  order   │ 2.0    │ │
│  │           │         │ Validate │────────►│ Process │ │
│  └──────────┘         │ Order   │         │ Payment │ │
│                        └─────────┘         └───┬────┘ │
│                             │                   │      │
│                        error│              payment     │
│                             ▼              info │      │
│                        ┌─────────┐              ▼      │
│                        │ D1:     │         ┌────────┐ │
│                        │ Error   │         │ 3.0    │ │
│                        │ Log     │         │ Fulfill │ │
│                        └─────────┘         │ Order  │ │
│                                            └───┬────┘ │
│  Shows: major processes within the system       │      │
│                                           shipment    │
│                                            info │      │
│                                                 ▼      │
│                                           ┌──────────┐ │
│                                           │ Warehouse│ │
│                                           └──────────┘ │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Level 1+ Diagrams                                        │
│                                                          │
│  Explodes a single Level 0 process into sub-processes.   │
│  E.g., "1.0 Validate Order" becomes:                     │
│                                                          │
│  ┌─────────┐ order  ┌─────────┐ checked  ┌─────────┐   │
│  │ 1.1     │───────►│ 1.2     │────────►│ 1.3     │   │
│  │ Check   │        │ Verify  │          │ Confirm │   │
│  │ Syntax  │        │ Stock   │          │ Price   │   │
│  └─────────┘        └────┬────┘          └─────────┘   │
│                          │                              │
│                     ┌────▼────┐                          │
│                     │ D2:     │                          │
│                     │ Inventory│                          │
│                     │ DB       │                          │
│                     └─────────┘                          │
└─────────────────────────────────────────────────────────┘
DFD按层级组织,每个层级提供更详细的内容:
┌─────────────────────────────────────────────────────────┐
│ 上下文图(Level -1)                               │
│                                                          │
│  ┌──────────┐    order     ┌──────────┐   receipt       │
│  │ Customer  │────────────►│  Order    │──────────►      │
│  │ (External)│◄────────────│  System   │   ┌──────────┐ │
│  └──────────┘  confirmation│ (Process) │──►│ Warehouse│ │
│                             └──────────┘   │ (External)│ │
│                                            └──────────┘ │
│  展示:将整个系统视为单一流程                     │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Level 0 Diagram                                          │
│                                                          │
│  ┌──────────┐  order   ┌─────────┐  valid   ┌────────┐ │
│  │ Customer  │────────►│ 1.0     │  order   │ 2.0    │ │
│  │           │         │ Validate │────────►│ Process │ │
│  └──────────┘         │ Order   │         │ Payment │ │
│                        └─────────┘         └───┬────┘ │
│                             │                   │      │
│                        error│              payment     │
│                             ▼              info │      │
│                        ┌─────────┐              ▼      │
│                        │ D1:     │         ┌────────┐ │
│                        │ Error   │         │ 3.0    │ │
│                        │ Log     │         │ Fulfill │ │
│                        └─────────┘         │ Order  │ │
│                                            └───┬────┘ │
│  展示:系统内的主要流程       │      │
│                                           shipment    │
│                                            info │      │
│                                                 ▼      │
│                                           ┌──────────┐ │
│                                           │ Warehouse│ │
│                                           └──────────┘ │
└─────────────────────────────────────────────────────────┘

┌─────────────────────────────────────────────────────────┐
│ Level 1+ Diagrams                                        │
│                                                          │
│  将单个Level 0流程展开为子流程。   │
│  例如,“1.0 Validate Order”展开为:                     │
│                                                          │
│  ┌─────────┐ order  ┌─────────┐ checked  ┌─────────┐   │
│  │ 1.1     │───────►│ 1.2     │────────►│ 1.3     │   │
│  │ Check   │        │ Verify  │          │ Confirm │   │
│  │ Syntax  │        │ Stock   │          │ Price   │   │
│  └─────────┘        └────┬────┘          └─────────┘   │
│                          │                              │
│                     ┌────▼────┐                          │
│                     │ D2:     │                          │
│                     │ Inventory│                          │
│                     │ DB       │                          │
│                     └─────────┘                          │
└─────────────────────────────────────────────────────────┘

DFD Rules

DFD规则

  1. All data flows must be labeled. Unlabeled arrows are ambiguous.
  2. No data flow between two external entities. The diagram models the system, not the outside world.
  3. No data flow between two data stores. Data movement requires a process.
  4. Every process must have at least one input and one output. A process with no inputs is a "miracle"; a process with no outputs is a "black hole."
  5. Data stores must connect to processes, not external entities. External entities interact through processes.
  6. Level numbers must be consistent. Sub-processes of Process 1.0 are 1.1, 1.2, 1.3, etc.
  1. 所有数据流必须标注标签。未标注的箭头会造成歧义。
  2. 外部实体之间不能有数据流。图表建模的是系统,而非外部世界。
  3. 数据存储之间不能有数据流。数据移动需要通过流程完成。
  4. 每个流程必须至少有一个输入和一个输出。没有输入的流程是“奇迹”;没有输出的流程是“黑洞”。
  5. 数据存储必须连接到流程,而非外部实体。外部实体通过流程与系统交互。
  6. 层级编号必须保持一致。流程1.0的子流程编号为1.1、1.2、1.3等。

DFD in Mermaid Syntax

Mermaid语法实现DFD

Mermaid does not have native DFD support, but flowchart syntax can represent DFD concepts:
mermaid
flowchart LR
    %% External Entities (rectangles)
    Customer[Customer]
    Warehouse[Warehouse]

    %% Processes (rounded)
    P1([1.0 Validate Order])
    P2([2.0 Process Payment])
    P3([3.0 Fulfill Order])

    %% Data Stores (cylinder shape for databases)
    D1[(D1: Orders DB)]
    D2[(D2: Inventory DB)]

    %% Data Flows
    Customer -->|order| P1
    P1 -->|valid order| P2
    P1 -->|order record| D1
    P2 -->|payment confirmation| P3
    P3 -->|stock query| D2
    D2 -->|availability| P3
    P3 -->|shipment request| Warehouse
    P1 -->|confirmation| Customer
Mermaid本身不支持原生DFD,但可以使用流程图语法来表达DFD的概念:
mermaid
flowchart LR
    %% External Entities (rectangles)
    Customer[Customer]
    Warehouse[Warehouse]

    %% Processes (rounded)
    P1([1.0 Validate Order])
    P2([2.0 Process Payment])
    P3([3.0 Fulfill Order])

    %% Data Stores (cylinder shape for databases)
    D1[(D1: Orders DB)]
    D2[(D2: Inventory DB)]

    %% Data Flows
    Customer -->|order| P1
    P1 -->|valid order| P2
    P1 -->|order record| D1
    P2 -->|payment confirmation| P3
    P3 -->|stock query| D2
    D2 -->|availability| P3
    P3 -->|shipment request| Warehouse
    P1 -->|confirmation| Customer

Functional Decomposition

功能分解

Functional decomposition breaks a system into hierarchical sub-functions. Each level reveals more detail about how a function is accomplished.
功能分解将系统拆分为层级化的子功能。每个层级会更详细地展示功能的实现方式。

Decomposition Tree Structure

分解树结构

┌──────────────────────────────────────────┐
│         Order Management System           │
│              (Level 0)                    │
└──────────────┬───────────────────────────┘
    ┌──────────┼──────────────┬─────────────────┐
    │          │              │                  │
    ▼          ▼              ▼                  ▼
┌────────┐ ┌────────┐  ┌──────────┐      ┌──────────┐
│ Receive│ │ Process│  │ Fulfill  │      │ Manage   │
│ Order  │ │ Payment│  │ Order    │      │ Returns  │
│ (1.0)  │ │ (2.0)  │  │ (3.0)   │      │ (4.0)    │
└───┬────┘ └───┬────┘  └────┬─────┘      └────┬─────┘
    │          │             │                  │
  ┌─┼─┐     ┌─┼─┐       ┌──┼──┐           ┌──┼──┐
  ▼ ▼ ▼     ▼ ▼ ▼       ▼  ▼  ▼           ▼  ▼  ▼
1.1 1.2    2.1 2.2     3.1 3.2 3.3       4.1 4.2 4.3
Val Cap    Auth Rec    Pick Pack Ship    Auth Proc Ref
┌──────────────────────────────────────────┐
│         订单管理系统           │
│              (Level 0)                    │
└──────────────┬───────────────────────────┘
    ┌──────────┼──────────────┬─────────────────┐
    │          │              │                  │
    ▼          ▼              ▼                  ▼
┌────────┐ ┌────────┐  ┌──────────┐      ┌──────────┐
│ 接收订单│ │ 处理支付│  │ 履行订单    │      │ 管理退货   │
│ (1.0)  │ │ (2.0)  │  │ (3.0)   │      │ (4.0)    │
└───┬────┘ └───┬────┘  └────┬─────┘      └────┬─────┘
    │          │             │                  │
  ┌─┼─┐     ┌─┼─┐       ┌──┼──┐           ┌──┼──┐
  ▼ ▼ ▼     ▼ ▼ ▼       ▼  ▼  ▼           ▼  ▼  ▼
1.1 1.2    2.1 2.2     3.1 3.2 3.3       4.1 4.2 4.3
验证 捕获    授权 记录    拣货 打包 发货    授权 处理 退款

Decomposition Guidelines

分解指南

  • Stop decomposing when a function is simple enough to be implemented as a single unit of work.
  • Each parent function should decompose into 2-7 child functions. Too few suggests unnecessary hierarchy; too many suggests the parent is not well-defined.
  • Naming convention: Use verb-noun pairs (e.g., "Validate Order", "Process Payment", "Ship Package").
  • Maintain consistency: All children at the same level should be at the same granularity.
  • 停止分解的时机:当功能简单到可以作为单一工作单元实现时,停止分解。
  • 父功能的子功能数量:每个父功能应分解为2-7个子功能。数量过少说明层级不必要;数量过多说明父功能定义不清晰。
  • 命名规范:使用动词-名词组合(例如:“验证订单”、“处理支付”、“发货”),而非“订单验证”或“支付模块”。
  • 保持一致性:同一层级的所有子功能应保持相同的粒度。

Functional Decomposition in Mermaid

Mermaid语法实现功能分解

mermaid
flowchart TD
    A[Order Management System]
    A --> B[1.0 Receive Order]
    A --> C[2.0 Process Payment]
    A --> D[3.0 Fulfill Order]
    A --> E[4.0 Manage Returns]

    B --> B1[1.1 Validate Order]
    B --> B2[1.2 Capture Order Details]
    B --> B3[1.3 Confirm Order]

    D --> D1[3.1 Pick Items]
    D --> D2[3.2 Pack Order]
    D --> D3[3.3 Ship Package]
mermaid
flowchart TD
    A[订单管理系统]
    A --> B[1.0 接收订单]
    A --> C[2.0 处理支付]
    A --> D[3.0 履行订单]
    A --> E[4.0 管理退货]

    B --> B1[1.1 验证订单]
    B --> B2[1.2 捕获订单详情]
    B --> B3[1.3 确认订单]

    D --> D1[3.1 拣货]
    D --> D2[3.2 打包订单]
    D --> D3[3.3 发货]

IDEF0 (Integration Definition for Function Modeling)

IDEF0(功能建模集成定义)

IDEF0 models functions (activities, processes, operations) and the data/objects that inter-relate those functions. Each function is represented as a box with four types of arrows.
IDEF0对功能(活动、流程、操作)以及与这些功能相关的数据/对象进行建模。每个功能用一个带有四种箭头的方框表示。

ICOM Convention

ICOM规范

        Controls (top)
    ┌───────────────┐
    │               │
Inputs ──►│   Function    │──► Outputs
(left)    │               │    (right)
    └───────┬───────┘
        Mechanisms (bottom)
Arrow PositionNameDescriptionExample
Left (entering)InputsData or objects transformed by the functionRaw order data
Top (entering)ControlsConditions, rules, or constraints that govern the functionBusiness rules, regulations
Right (exiting)OutputsData or objects produced by the functionValidated order
Bottom (entering)MechanismsResources that perform the functionStaff, software, equipment
        控制项(顶部)
    ┌───────────────┐
    │               │
输入项 ──►│   功能    │──► 输出项
(左侧)    │               │    (右侧)
    └───────┬───────┘
        机制项(底部)
箭头位置名称描述示例
左侧(进入)输入项被功能转换的数据或对象原始订单数据
顶部(进入)控制项约束功能的条件、规则或限制业务规则、法规
右侧(离开)输出项功能产生的数据或对象已验证订单
底部(进入)机制项执行功能的资源员工、软件、设备

IDEF0 Example: Process Customer Order

IDEF0示例:处理客户订单

              Business Rules     Pricing Policy
                   │                  │
                   ▼                  ▼
              ┌──────────────────────────────┐
              │                              │
Customer  ──►│    Process Customer Order     │──► Confirmed Order
Order         │          (A0)                │──► Invoice
              │                              │──► Shipment Request
              └──────────────┬───────────────┘
                  ┌──────────┼──────────┐
                  ▲          ▲          ▲
              Order Mgmt   ERP       Warehouse
              Team        System     Staff
              业务规则     定价策略
                   │                  │
                   ▼                  ▼
              ┌──────────────────────────────┐
              │                              │
客户  ──►│    处理客户订单     │──► 已确认订单
订单         │          (A0)                │──► 发票
              │                              │──► 发货请求
              └──────────────┬───────────────┘
                  ┌──────────┼──────────┐
                  ▲          ▲          ▲
              订单管理团队   ERP系统       仓库员工

IDEF0 Decomposition

IDEF0分解

Like DFDs, IDEF0 diagrams decompose hierarchically:
  • A-0: Top-level context diagram (single box)
  • A0: First decomposition (3-6 child functions)
  • A1, A2, ...: Further decomposition of each function
A-0: Process Customer Order
 └── A0 Decomposition:
      ├── A1: Validate Order
      ├── A2: Check Inventory
      ├── A3: Calculate Pricing
      ├── A4: Process Payment
      └── A5: Initiate Fulfillment
与DFD类似,IDEF0图也按层级分解:
  • A-0:顶层上下文图(单一方框)
  • A0:首次分解(3-6个子功能)
  • A1、A2...:对每个功能进行进一步分解
A-0: 处理客户订单
 └── A0分解:
      ├── A1: 验证订单
      ├── A2: 检查库存
      ├── A3: 计算定价
      ├── A4: 处理支付
      └── A5: 启动履行流程

IDEF0 Rules

IDEF0规则

  1. Each function box must have at least one control and one output. Inputs and mechanisms may be optional.
  2. 3-6 functions per diagram. Too few does not add value; too many becomes unreadable.
  3. Arrows between boxes model data/object flow. An output of one function can become the input or control of another.
  4. Boundary arrows connect to parent diagram arrows via ICOM codes.
  5. Node numbering: A0 decomposes to A1-A6; A1 decomposes to A11-A16; etc.
  1. 每个功能方框必须至少有一个控制项和一个输出项。输入项和机制项为可选。
  2. 每个图表包含3-6个功能。数量过少无价值;数量过多会难以阅读。
  3. 方框之间的箭头表示数据/对象流动。一个功能的输出可以成为另一个功能的输入或控制项。
  4. 边界箭头通过ICOM代码与父图表的箭头关联。
  5. 节点编号:A0分解为A1-A6;A1分解为A11-A16;以此类推。

IDEF0 in Mermaid

Mermaid语法实现IDEF0

mermaid
flowchart LR
    subgraph Controls
        BR[Business Rules]
        PP[Pricing Policy]
    end

    subgraph Inputs
        CO[Customer Order]
    end

    subgraph "A0: Process Customer Order"
        A1([A1: Validate Order])
        A2([A2: Check Inventory])
        A3([A3: Calculate Pricing])
        A4([A4: Process Payment])
        A5([A5: Initiate Fulfillment])
    end

    subgraph Outputs
        CF[Confirmed Order]
        INV[Invoice]
        SR[Shipment Request]
    end

    subgraph Mechanisms
        OT[Order Mgmt Team]
        ERP[ERP System]
        WS[Warehouse Staff]
    end

    CO --> A1
    BR --> A1
    BR --> A3
    PP --> A3
    A1 -->|valid order| A2
    A2 -->|stock confirmed| A3
    A3 -->|priced order| A4
    A4 -->|paid order| A5
    A5 --> CF
    A4 --> INV
    A5 --> SR
    OT -.-> A1
    ERP -.-> A2
    ERP -.-> A3
    ERP -.-> A4
    WS -.-> A5
mermaid
flowchart LR
    subgraph Controls
        BR[Business Rules]
        PP[Pricing Policy]
    end

    subgraph Inputs
        CO[Customer Order]
    end

    subgraph "A0: Process Customer Order"
        A1([A1: Validate Order])
        A2([A2: Check Inventory])
        A3([A3: Calculate Pricing])
        A4([A4: Process Payment])
        A5([A5: Initiate Fulfillment])
    end

    subgraph Outputs
        CF[Confirmed Order]
        INV[Invoice]
        SR[Shipment Request]
    end

    subgraph Mechanisms
        OT[Order Mgmt Team]
        ERP[ERP System]
        WS[Warehouse Staff]
    end

    CO --> A1
    BR --> A1
    BR --> A3
    PP --> A3
    A1 -->|valid order| A2
    A2 -->|stock confirmed| A3
    A3 -->|priced order| A4
    A4 -->|paid order| A5
    A5 --> CF
    A4 --> INV
    A5 --> SR
    OT -.-> A1
    ERP -.-> A2
    ERP -.-> A3
    ERP -.-> A4
    WS -.-> A5

BPMN (Business Process Model and Notation)

BPMN(业务流程模型与符号)

BPMN is an ISO standard (ISO/IEC 19510) for graphically representing business processes. It is the most widely used process modeling notation.
BPMN是一项ISO标准(ISO/IEC 19510),用于以图形方式表示业务流程。它是使用最广泛的流程建模符号。

Core BPMN Elements

BPMN核心元素

Flow Objects

流对象

ElementSymbolDescription
TaskRounded rectangleAn atomic activity within a process
Sub-ProcessRounded rectangle with +A compound activity containing a nested process
Event (Start)Thin circleIndicates where a process begins
Event (Intermediate)Double circleOccurs between start and end
Event (End)Thick circleIndicates where a process ends
Exclusive Gateway (XOR)Diamond with XDecision point, only one path taken
Parallel Gateway (AND)Diamond with +All paths are taken simultaneously
Inclusive Gateway (OR)Diamond with OOne or more paths taken
Event-Based GatewayDiamond with pentagonPath determined by event occurrence
元素符号描述
任务圆角矩形流程中的原子活动
子流程带+号的圆角矩形包含嵌套流程的复合活动
事件(开始)细圆圈表示流程的起点
事件(中间)双圆圈发生在开始和结束事件之间
事件(结束)粗圆圈表示流程的终点
排他网关(XOR)带X的菱形决策点,仅选择一条路径
并行网关(AND)带+的菱形同时选择所有路径
包容网关(OR)带O的菱形选择一条或多条路径
事件网关带五边形的菱形根据事件发生情况选择路径

Swimlane Elements

泳道元素

ElementDescription
PoolA container representing a participant (organization, system, role)
LaneA sub-partition within a pool, typically representing a specific role or department
元素描述
代表参与者(组织、系统、角色)的容器
池内的子分区,通常代表特定角色或部门

Connecting Objects

连接对象

ElementDescription
Sequence FlowSolid arrow showing order of activities within a pool
Message FlowDashed arrow showing communication between pools
AssociationDotted line connecting data objects or annotations to flow objects
元素描述
序列流实心箭头,展示池内活动的执行顺序
消息流虚线箭头,展示池之间的通信
关联虚线,将数据对象或注释与流对象连接

Data Elements

数据元素

ElementDescription
Data ObjectInformation required or produced by a task
Data StoreA persistent repository
元素描述
数据对象任务所需或产生的信息
数据存储持久化存储库

BPMN Example: Order Fulfillment Process

BPMN示例:订单履行流程

┌──────────────────────────────────────────────────────────────────────┐
│ Pool: Order Fulfillment                                               │
│                                                                       │
│ ┌─────────────────────────────────────────────────────────────────┐  │
│ │ Lane: Sales                                                      │  │
│ │                                                                  │  │
│ │  (○)──►[Receive Order]──►<X>──►[Send Confirmation]──►           │  │
│ │  Start                   │                                       │  │
│ │                     invalid                                      │  │
│ │                          │                                       │  │
│ │                          ▼                                       │  │
│ │                   [Reject Order]──►(●)                           │  │
│ │                                   End                            │  │
│ └──────────────────────────────────┼──────────────────────────────┘  │
│                                     │ valid                          │
│ ┌──────────────────────────────────▼──────────────────────────────┐  │
│ │ Lane: Warehouse                                                  │  │
│ │                                                                  │  │
│ │  [Pick Items]──►[Pack Order]──►[Ship Order]──►(●)               │  │
│ │                                                End               │  │
│ └──────────────────────────────────────────────────────────────────┘  │
│                                                                       │
│ ┌──────────────────────────────────────────────────────────────────┐  │
│ │ Lane: Finance                                                    │  │
│ │                                                                  │  │
│ │  [Process Payment]──►<X>──►[Issue Invoice]──►(●)                │  │
│ │                       │                      End                 │  │
│ │                  failed│                                          │  │
│ │                       ▼                                          │  │
│ │                [Escalate to Manager]──►(●)                       │  │
│ │                                       End                        │  │
│ └──────────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────┘

Legend: (○) = Start Event, (●) = End Event, <X> = Exclusive Gateway
        [Task] = Task/Activity
┌──────────────────────────────────────────────────────────────────────┐
│ 池:订单履行                                               │
│                                                                       │
│ ┌─────────────────────────────────────────────────────────────────┐  │
│ │ 道:销售部                                                      │  │
│ │                                                                  │  │
│ │  (○)──►[接收订单]──►<X>──►[发送确认]──►           │  │
│ │  开始                   │                                       │  │
│ │                     无效                                      │  │
│ │                          │                                       │  │
│ │                          ▼                                       │  │
│ │                   [拒绝订单]──►(●)                           │  │
│ │                                   结束                            │  │
│ └──────────────────────────────────┼──────────────────────────────┘  │
│                                     │ 有效                          │
│ ┌──────────────────────────────────▼──────────────────────────────┐  │
│ │ 道:仓库部                                                  │  │
│ │                                                                  │  │
│ │  [拣货]──►[打包订单]──►[发货]──►(●)               │  │
│ │                                                结束               │  │
│ └──────────────────────────────────────────────────────────────────┘  │
│                                                                       │
│ ┌──────────────────────────────────────────────────────────────────┐  │
│ │ 道:财务部                                                    │  │
│ │                                                                  │  │
│ │  [处理支付]──►<X>──►[开具发票]──►(●)                │  │
│ │                       │                      结束                 │  │
│ │                  失败│                                          │  │
│ │                       ▼                                          │  │
│ │                [上报经理]──►(●)                       │  │
│ │                                       结束                        │  │
│ └──────────────────────────────────────────────────────────────────┘  │
└──────────────────────────────────────────────────────────────────────┘

图例:(○) = 开始事件, (●) = 结束事件, <X> = 排他网关
        [Task] = 任务/活动

BPMN in Mermaid

Mermaid语法实现BPMN

Mermaid does not have native BPMN support, but flowchart syntax can approximate BPMN processes:
mermaid
flowchart TD
    Start((Start)) --> ReceiveOrder[Receive Order]
    ReceiveOrder --> ValidCheck{Valid?}
    ValidCheck -->|Yes| SendConfirmation[Send Confirmation]
    ValidCheck -->|No| RejectOrder[Reject Order]
    RejectOrder --> EndReject((End))

    SendConfirmation --> Fork{Parallel}
    Fork --> PickItems[Pick Items]
    Fork --> ProcessPayment[Process Payment]

    PickItems --> PackOrder[Pack Order]
    PackOrder --> ShipOrder[Ship Order]
    ShipOrder --> Join{Join}

    ProcessPayment --> PayCheck{Payment OK?}
    PayCheck -->|Yes| IssueInvoice[Issue Invoice]
    PayCheck -->|No| Escalate[Escalate to Manager]
    Escalate --> EndEsc((End))
    IssueInvoice --> Join

    Join --> EndSuccess((End))
Mermaid本身不支持原生BPMN,但可以使用流程图语法近似实现BPMN流程:
mermaid
flowchart TD
    Start((Start)) --> ReceiveOrder[Receive Order]
    ReceiveOrder --> ValidCheck{Valid?}
    ValidCheck -->|Yes| SendConfirmation[Send Confirmation]
    ValidCheck -->|No| RejectOrder[Reject Order]
    RejectOrder --> EndReject((End))

    SendConfirmation --> Fork{Parallel}
    Fork --> PickItems[Pick Items]
    Fork --> ProcessPayment[Process Payment]

    PickItems --> PackOrder[Pack Order]
    PackOrder --> ShipOrder[Ship Order]
    ShipOrder --> Join{Join}

    ProcessPayment --> PayCheck{Payment OK?}
    PayCheck -->|Yes| IssueInvoice[Issue Invoice]
    PayCheck -->|No| Escalate[Escalate to Manager]
    Escalate --> EndEsc((End))
    IssueInvoice --> Join

    Join --> EndSuccess((End))

Choosing the Right Functional Diagram

选择合适的功能图表

Diagram TypeBest ForNot Suitable For
DFDData transformation analysis, system boundaries, data store identificationProcess timing, organizational roles
Functional DecompositionBreaking complex systems into manageable pieces, scope definitionData flow, process sequencing
IDEF0Understanding function constraints and resources, manufacturing and engineering processesSimple workflows, quick communication
BPMNBusiness process documentation, workflow automation, cross-department handoffsData modeling, system architecture
图表类型最佳适用场景不适用场景
DFD数据转换分析、系统边界定义、数据存储识别流程时序、组织角色
功能分解将复杂系统拆分为可管理的模块、范围定义数据流、流程排序
IDEF0理解功能约束和资源、制造与工程流程简单工作流、快速沟通
BPMN业务流程文档编制、工作流自动化、跨部门交接数据建模、系统架构

Combining Functional Diagram Types

功能图表类型的组合使用

These diagram types are complementary:
Functional Decomposition Tree
    │ identifies functions to model
IDEF0 Diagrams
    │ identifies data transformations
Data Flow Diagrams
    │ identifies processes to orchestrate
BPMN Process Models
  1. Start with Functional Decomposition to identify the major functions of the system.
  2. Use IDEF0 to understand the inputs, outputs, controls, and mechanisms of critical functions.
  3. Create DFDs to trace how data moves through and between the functions.
  4. Model in BPMN when the focus shifts to implementing business processes with specific roles and decision logic.
这些图表类型是互补的:
功能分解树
    │ 识别需要建模的功能
IDEF0图
    │ 识别数据转换
数据流图
    │ 识别需要编排的流程
BPMN流程模型
  1. 从功能分解开始:识别系统的主要功能。
  2. 使用IDEF0:理解关键功能的输入、输出、控制项和机制项。
  3. 创建DFD:追踪数据在功能之间的流动路径。
  4. 使用BPMN建模:当重点转向实现带有特定角色和决策逻辑的业务流程时。

Best Practices

最佳实践

  • Start at the context level. Whether using DFD or IDEF0, begin with a single-process context diagram before decomposing. This establishes scope and boundaries.
  • Maintain level consistency. All processes at the same decomposition level should be at the same granularity. Do not mix high-level and detailed processes on the same diagram.
  • Label every data flow. Unlabeled arrows are the most common DFD error and make diagrams ambiguous.
  • Limit elements per diagram. Follow the 3-7 process guideline per decomposition level. More than 7 processes on a single diagram reduces readability.
  • Use verb-noun naming for processes. "Validate Order", "Calculate Tax", "Ship Package" — not "Order Validation" or "Tax Module."
  • Distinguish between data flow and control flow. In DFDs, arrows represent data movement. In BPMN, arrows represent sequence flow. Do not mix paradigms on a single diagram.
  • Validate data conservation. All data entering a process must either be output or stored. Data does not appear or disappear inside processes.
  • Use BPMN pools for organizational boundaries. Each pool represents a distinct participant. Use lanes within pools for roles or departments.
  • Use Mermaid flowcharts as a practical approximation. While Mermaid does not natively support DFD or IDEF0 notation, flowchart syntax captures the essential structure and is renderable in documentation platforms.
  • Cross-reference between diagram types. When using both DFDs and BPMN, ensure process names and data labels are consistent across all diagrams. A process called "Validate Order" in the DFD should have the same name in the BPMN model.
  • 从上下文层级开始:无论使用DFD还是IDEF0,先创建单一流程的上下文图,再进行分解。这有助于确定范围和边界。
  • 保持层级一致性:同一分解层级的所有流程应保持相同的粒度。不要在同一图表中混合高层级和详细流程。
  • 为每个数据流标注标签:未标注的箭头是DFD最常见的错误,会导致图表歧义。
  • 限制每个图表的元素数量:遵循每个分解层级3-7个流程的准则。单个图表中的流程超过7个会降低可读性。
  • 使用动词-名词组合命名流程:例如“验证订单”、“计算税费”、“发货”——而非“订单验证”或“税费模块”。
  • 区分数据流和控制流:在DFD中,箭头表示数据移动;在BPMN中,箭头表示序列流。不要在同一图表中混合两种范式。
  • 验证数据守恒:进入流程的所有数据要么被输出,要么被存储。数据不会在流程内部凭空出现或消失。
  • 使用BPMN池表示组织边界:每个池代表一个独立的参与者。在池内使用道表示角色或部门。
  • 使用Mermaid流程图作为实用的近似实现:虽然Mermaid不原生支持DFD或IDEF0符号,但流程图语法可以捕获核心结构,并且可以在文档平台中渲染。
  • 在不同图表类型之间交叉引用:当同时使用DFD和BPMN时,确保所有图表中的流程名称和数据标签保持一致。DFD中名为“验证订单”的流程在BPMN模型中应使用相同的名称。