一、引言

结构化分析（SA）是一种面向数据流进行需求分析的方法，特别适用于数据处理类型软件的需求分析。下面我们将详细介绍其分析模型的结构，包括数据建模、功能建模、系统行为建模以及数据词典等方面。

二、数据建模与范式

2.1 概念性数据模型

为清晰表达用户的数据要求，软件开发人员常建立概念性的数据模型（信息模型）。这是一种面向问题的数据模型，按照用户观点对数据和信息建模，描述从用户角度看到的数据，反映现实环境，与软件系统实现方法无关。最常用的表示方法是实体 / 关系方法（Entity Relationship Approach），用 ER 图描述现实世界中的实体，以此表示的概念性数据模型称为 ER 模型。

2.2 数据对象、属性和关系

2.2.1 数据对象

数据对象可能是外部实体（如生产或消费信息的事物）、事物（如报告或显示）、发生（如电话呼叫）、事件（如警报）、角色（如销售人员）、组织单位（如统计部门）、地点（如仓库）或结构（如文件）。通常将数据对象简称为 “实体”，它只封装数据（属性），无指向操作的引用。

2.2.2 属性

属性定义了数据对象的性质，有三种特性：

• 为数据对象的实例命名。
• 描述这个实例。
• 建立对另一个表中的另一个实例的引用。

一个或多个属性可定义为标识符，作为 “关键字”，其值在有些情况下唯一，但非必须。

2.2.3 关系

客观世界中事物彼此关联，在软件系统中以数据对象表示，数据对象间的连接方式称为关系。例如教师与课程的 “教课” 联系，学生与课程的 “上课” 或 “听课” 联系。

2.2.4 基数（Cardinality）

数据模型需表示给定关系中实体出现的次数，即对象 — 关系对的基数。两个实体可能的关联有：

• 一对一（1：1）：实体 A 的一次出现只能关联到实体 B 的一次出现，反之亦然。
• 一对多（1：N）：实体 A 的一次出现可关联到实体 B 的零次、一次或多次出现，但 B 的一次出现只能关联到 A 的一次出现。
• 多对多（M：N）：实体 A 的一次出现可关联到实体 B 的一次或多次出现，同时 B 的一次出现也可关联到 A 的一次或多次出现。

2.3 实体关系图 (ER 图)

ER 图以图形形式表示实体及实体之间的关系，标识了实体、属性、关系等基本构件。带标记（或名称）的矩形表示实体，连接实体的线表示关系。

2.4 数据结构规范化

规范化目的是消除数据冗余、消除多义性、使关系单纯化、方便数据操作、使关系模式更灵活。关系规范化程度按属性间依赖程度区分，以范式（Normal Form，NF）表达。一般数据库满足第三范式（3NF）即可。

• 第一范式（1NF）：关系中所有属性都是 “单纯域”，无 “表中有表”，即实体中属性无多个值或重复属性，无重复列。
• 第二范式（2NF）：非主属性完全函数依赖于关键字，满足 2NF 需先满足 1NF，要求数据库表中每个实例或行可唯一区分，即非主属性完全依赖于主关键字。
• 第三范式（3NF）：非主属性相互独立，无函数依赖，满足 3NF 需先满足 2NF，即属性不依赖于其它非主属性。

三、功能建模与数据流图

3.1 数据流图概述

当数据或信息 “流” 过计算机系统时，会被系统功能处理、加工或变换后输出。数据流图是描述信息流和数据变换的图形化技术，可抽象表示系统或软件，提供功能建模和数据流建模机制，以自顶向下机制表示层级细节。DFD 也称为数据流图（Data Flow Diagram）或泡泡图（Bubble Chart）。

3.2 数据流图的结构

• 外部实体 (数据源点或汇点)：表示数据输入来源或处理结果去向，是数据流图外围环境中的实体。
• 加工：以数据结构或内容为加工对象，名字通常是动词短语，表明完成的加工。
• 数据存储：在数据流图中保存数据，可是数据库文件或任何数据组织形式。
• 数据流：沿箭头方向传送数据的通道，大多是加工间传输数据的命名通道，也有连接数据存储和加工的无命名通道。

3.3 数据流与加工之间的关系

在数据流图中，若有两个以上数据流指向一个加工，或从一个加工引出两个以上数据流，这些数据流间往往存在一定关系。

3.4 分层的数据流图

为表达复杂问题，按问题层次结构分解，以分层数据流图反映结构关系。多层数据流图可分为顶层流图、底层流图和中间层流图。

• 顶层流图仅含一个加工，代表被开发系统。
• 底层流图的加工无须再分解，其加工称为 “原子加工”。
• 中间层流图是对上层父图的细化。

3.5 数据流图的画法

自外向内，自顶向下，逐层细化，完善求精。步骤如下：

1. 找系统的数据源点与汇点（外部实体），确定系统与外界接口。
2. 在图边画出外部实体。
3. 找出外部实体的输出与输入数据流。
4. 从外部实体输出数据流出发，按系统逻辑画逻辑加工，直到找到输入数据流，形成数据流封闭（先画顶层，再细化）。
5. 从各加工出发画子图。
6. 按检查原则检查和修改。

3.6 数据流图的检查和修改原则

1. 数据流图上图形符号限于四种基本元素。
2. 主图必须包含四种基本元素，缺一不可。
3. 主图上的数据流必须封闭在外部实体之间，外部实体可多个。
4. 每个加工至少有一个输入和一个输出数据流。
5. 按层给加工框编号，表明层次及父子图对应关系。
6. 子图与上一层加工对应，输入输出数据流一致（父图与子图平衡）。
7. 子图添加新加工、数据流和数据存储时，更新上层父图到顶层。
8. 图上每个元素必须有名字。
9. 不可夹带控制流，数据流图说明 “做什么”，非 “如何做”。
10. 初画可忽略琐碎细节，集中精力于主要数据流。

3.7 数据流图示例 —— 医院就诊管理系统

3.7.1 业务流程

• 挂号：挂号人员接受病人就诊请求，分配医生，记录打印挂号凭据，收取挂号费。
• 问诊：医生按挂号次序诊断病情，获取病历，记录问诊结果，开具处方。
• 收费：收费员根据处方收费，打印清单找零钱。
• 取药：药剂师核对处方，交付药品。

3.7.2 顶层数据流图要素

• 外部实体：挂号人员、医生、收费人员、药剂师。
• 加工：医院就诊管理系统（整个系统作为一个加工）。
• 数据流：
  • 挂号人员与 “加工”：挂号请求、挂号费、挂号单。
  • 医生与 “加工”：病历信息、处方信息。
  • 收费人员与 “加工”：实收金额、处方状态、收费清单。
  • 药剂师与 “加工”：处方状态。
• 数据存储：病历、挂号单、医生排队信息、处方、收费清单。数据存储与加工间用双向箭头表示数据交互，具体内容在数据词典说明。

3.8 实时系统的数据流图

除原有数据流，引入控制流及连续的数据流等符号，适应实时系统要求：

• 在时间连续基础上接收或产生数据流。
• 贯穿系统的控制信息和相关控制处理。
• 多任务时可能遇到同一加工的多个实例。
• 系统状态及导致状态迁移的机制。

四、系统行为建模

为直观分析系统动作，采用动态分析方法，常用的有状态迁移图（STD）、时序图（UML 中的序列图）、Petri 网。

4.1 状态迁移图 (STD)

利用状态迁移图或表描述系统或对象的状态及状态改变的事件，描述系统行为。状态代表行为模式，用圆圈表示状态，箭头表示状态迁移，箭头上写导致迁移的信号或事件名字。状态迁移会伴随相应处理，复杂系统可分层表示。当一个状态和事件决定的下一状态有多个时，可采用变形，如加判断框和处理框。

4.2 Petri 网

最初用于表达异步系统控制规则，后在计算机科学广泛应用。Petri 网（PNG）是有向图，包含位置 P（圆圈表示）、转换 T（短直线表示）、输入函数 I（位置指向转换的箭头）、输出函数 O（转换指向位置的箭头）。位置中有黑点称为标记（token），标记出现表明处理要求到来，系统处于此位置。当输入位置标记数大于等于到转换的线数时，允许转换。标记总数不固定，具有非确定性，多个转换满足激发条件时，任意一个可被激发。

五、数据词典 (DD，Data Dictionary)

5.1 数据词典的作用

对数据流图中命名的图形元素在数据词典中定义，消除二义性，使名字有确切解释。

5.2 数据词典的构成

• 数据流词条：数据结构在系统内传播的路径。
• 数据元素词条：数据处理最小单元，不可再细分，反映事物特征。
• 数据文件词条：数据结构保存的地方。
• 加工逻辑词条：对加工逻辑或规则进行描述，方法有判定表、判定树或结构化英语等。
• 外部实体词条

5.3 数据词典的使用

• 按数据名称查问定义。
• 按要求列各种表。
• 按描述内容查询数据名称。
• 检查加工逻辑功能，实现和检查数据与程序的一致性和完整性。
• 设计、实现和维护阶段参考查询。

5.4 数据结构的描述

Warnier 图是表示数据层次结构的图形工具，用树形结构描绘数据结构。用花括号表示层次关系，同一括号下数据项顺序排列，部分数据项后括号给出重复次数，可细化组合数据项分解信息域。

5.5 加工逻辑说明

5.5.1 基本加工

数据流图最底层的加工，每个基本加工必须有逻辑说明，描述输入到输出的加工规则、实现策略而非细节，信息应充足、完备、有用、无冗余。

5.5.2 工具

• 结构化英语：介于自然语言和形式化语言之间的半形式化语言，词汇表由英语命令动词、数据词典定义的名字、自定义词和控制结构关键词组成，有简单陈述句、判定和重复结构。
• 判定表：适用于加工依赖多个逻辑条件取值的情况，由条件桩（列出条件）、条件项（条件取值组合）、动作桩（可能采取的动作）、动作项（不同条件组合下的动作）四部分组成。
• 判定树：表达加工逻辑的工具，比判定表更直观，易被用户接受。

通过结构化分析的这些方法和工具，能够全面、系统地对软件需求进行分析，为后续的设计和开发打下坚实的基础。