我们都知道软件是什么，但有时候会止步于软件要“做什么”的问题。在下面这篇文章中，我们将从结构化系统分析的角度出发，来解决软件“做什么”的问题。

一、系统分析的任务和过程

1、系统分析的任务

借助当前系统的逻辑模型，去导出目标系统的逻辑模型，解决目标系统“做什么”的问题。

2、系统分析的过程

系统分析的过程包含以下四个步骤：

• 问题识别
• 分析与综合
• 编制文档
• 系统分析评审

接下来将对这四个步骤进行一一讲解。

（1）问题识别

1） 从系统的角度来理解软件并评审软件范围是否恰当。

2） 确定软件的需求，即提出这些需求应实现的条件，和这些需求应达到的标准。

软件的需求包括：

• 功能需求（最重要，功能是一切需求的根本）
• 性能需求
• 环境需求
• 可靠性需求
• 资源使用需求
• 成本消耗需求
• 开发进度需求
• 用户界面需求
• 安全保密需求（经常会被遗漏的需求）

3） 建立通信路径。建立和分析所需要的通信路径，以保证能顺利地对问题进行分析。

（2）分析与综合

1） 逐步细化软件功能，找出系统各元素间的联系、接口特性和设计上的约束，分析是否满足功能要求，是否合理。

2） 剔除不合理部分，增加其需要部分。最终综合成系统的解决方案，给出目标系统的详细逻辑模型。（核心：建立逻辑模型）

3）常用的分析方法

• 面向数据流的结构化分析方法 (SA)
• 面向数据结构的 Jackson 方法 (JSD)
• 面向数据结构的结构化数据系统开发方法 (DSSD)
• 面向对象的分析方法 (OOA) 等

（3）编制文档

• 软件需求说明书；
• 数据要求说明书；
• 初步的用户手册；
• 修改、完善与确定软件开发实施计划。

（4）系统分析评审

系统分析的评审内容主要有以下内容：

• 系统定义的目标是否与用户的要求一致；

• 系统需求分析阶段提供的文档资料是否齐全；

• 文档中的所有描述是否完整、清晰、准确反映用户要求；

• 与所有其它系统成分的重要接口是否都已经描述；

• 被开发项目的数据流与数据结构是否足够；

• 所有图表是否清楚，在不补充说明时能否理解；

• 主要功能是否已包括在规定的软件范围之内，是否都已充分说明；

• 设计的约束条件或限制条件是否符合实际；

• 开发的技术风险是什么；

• 是否考虑过软件需求的其它方案；

• 是否考虑过将来可能会提出的软件需求；

• 是否详细制定了检验标准，它们能否对系统定义是否成功进行确认；

• ……

二、结构化分析方法

1、结构化分析方法是什么？

• 结构化分析方法是一种面向数据流进行需求分析的方法；
• 适用于数据处理类型 （MIS） 软件的需求分析；
• 用抽象模型的概念，按照软件内部数据传递、变换的关系，自顶向下逐层分解，直到满足所有功能要求为止。（自顶向下逐层分解是结构化分析的基本思路）

2、结构化分析方法使用的工具

结构化分析所使用的工具主要有五种：

• 数据流图 (DFD)
• 数据字典 (DD)
• 结构化英语 (Structured English)
• 判定表 (Decision Table)
• 判定树 (Decision Tree)

接下来将对这五种工具进行一一介绍。

（1）数据流图 (Data Flow Diagram, DFD)

1）作用

• 数据流图是组织中信息运动的抽象，是信息系统逻辑模型的主要形式，是分析人员与用户进行交流的有效手段，也是系统设计的依据之一。
• 简单来说，数据流图是用一种图形及与图形相关的注释来表示系统的逻辑功能。

2）主要图形元素

数据流图主要图形元素为以下四种。圆圈代表数据加工，矩形代表外部实体，箭头代表数据流，“椅子”形状图形代表数据存储文件。

了解完数据流图的主要图形元素，再来了解这四种主要图形元素常用的三种符号。

讲到这里，相信大家都对数据流图的主要图形元素有了一定的了解，那么我们继续来对这四个元素的含义做个归纳。

• 外部项(外部实体)： 外部项在数据流图中表示所描述系统的数据来源和去处的各种实体或工作环节。系统开发不能改变这些外部项本身的结构和固有属性。
• 加工(数据加工)： 又称数据处理逻辑，描述系统对信息进行处理的逻辑功能。
• 数据存储： 逻辑意义上的数据存储环节，即系统信息处理功能所需要的、不考虑存储物理介质和技术手段的数据存储环节。
• 数据流： 与所描述系统信息处理功能有关的各类信息的载体，是各加工环节进行处理和输出的数据集合。

介绍完具体的主要图形元素，我们还要思考一个问题：这些图形要怎么连接才是合理的？是不是只有有随意一个图形出现就可以了？那结果自然是否定的。这就引出了我们应该要注意的一个问题：数据流图的规范。 具体内容如下：

DFD中允许的数据流：
①实体 -> 加工；②加工 -> 实体；③加工 -> 加工；④加工 -> 存储；⑤存储 -> 加工。

DFD中不允许的数据流：
①实体 -> 实体；②实体 -> 存储；③存储 -> 实体；④存储 -> 存储。

总结： 所有的数据流都要有加工，任意一个没有经过加工的数据流都是不规范的。
注意： 所有数据流信息都要标注，除了加工与存储相连时传递的信息刚好是数据存储的内容（可省略），其它一律不可以。

3）数据流图的层次结构

• 为了表达数据处理过程的数据加工情况，需要采用层次结构的数据流图。
• 按照系统的层次结构进行逐步分解，以分层的数据流图反映这种结构关系，能清楚地表达和容易理解系统。
• 在多层数据流图中，顶层流图仅包含一个加工，它代表被开发的系统。它的输入流是该系统的输入数据，输出流是系统所输出的数据。除顶层数据流图外，其他数据流图从零开始编号。
• 中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。
• 底层流图是指其加工不需再做分解的数据流图，它处在最底层。

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

• 数据流图上所有图形符号只限于上述四种基本图形元素。
• 数据流图的主图必须包括上述四种基本元素，缺一不可。
• 数据流图的主图上的数据流必须封闭在外部实体之间。
• 每个加工至少有一个输入数据流和一个输出数据流，而且所有的数据流都要经过加工。
• 在数据流图中，需按照层次给加工框编号，编号表明该加工所处层次及上下层的亲子关系；有一种特殊情况就是，顶层图的加工可以不用加编号。
• 当数据流图只有一个加工时，可以不考虑存储，但当数据流图有多个加工时，一定要考虑存储。
• 规定任何一个数据流子图必须与它上一层的一个加工对应，两者的输入数据流和输出数据流必须一致，即父图与子图的平衡。
• 图上每个元素都必须有名字。
• 数据流图中不可夹带控制流。

5）错误实例
我们来看几个错误实例。

错误原因： 布局不够合理，实体应该在四周，加工在中间。

---

错误原因： 数据流图画的像数据流程图。

---

错误原因： 数据流没有标注，加工项没有编号。

---

错误原因： 加工项出现名词。

---

错误原因： 加工项只有输入没有输出。

---

错误原因： 没有数据存储。

---

错误原因： 实体与数据存储相连，所有的实体和存储都必须经过加工。

6）数据流图的局限性

只能给出系统逻辑功能的一个总框架，缺乏详细、具体的内容。
7）案例分析

关于数据流图的案例分析放在下一篇文章中，大家可以根据自身需求进行查看。

（2）数据字典 (Data Flow Diagram, DFD)

1）作用

数据字典对数据流图中的各种成分起注解、说明作用，给这些成分赋以实际的内容。

数据字典与数据流图配合，能清楚地表达数据处理的要求。

条目：数据流、数据元素、数据存储、数据加工、外部实体

2）条目

数据字典有五个条目，即数据流图 DFD 的四要素 + 数据元素，分别是 数据流 、 数据元素 、 数据存储 、 数据加工 、 外部实体 。

具体图例如下：

条目一：数据流

条目二：数据元素

条目三：数据存储

条目四：数据加工

条目五：外部项

3）数据结构的符号描述

符号	含义	举例
=	被定义为	x=a
+	与	x=a+b
[…,…]或[…|…]	或	x = [a , b]，x = [a|b]
{ … }或 m{…}n	重复	x = {a}, x = 3{a}8
(…)	可选	x = (a)
“…”	基本数据元素	x = “a”
…	连结符	x = 1…9

4）案例分析

关于数据字典的案例分析放在下一篇文章中，大家可以根据自身需求进行查看。下面将结构化英语。

在讲结构化英语之前，我们需要先来了解一个知识点。

对于数据流图的每一个基本加工，都必须要有一个基本加工逻辑说明，那么基本加工逻辑说明是什么呢？基本加工逻辑说明是用来描述基本加工如何把 输入数据流 变换为 输出数据流 的加工规则。且用于写基本加工逻辑说明的工具主要有 结构化英语 、 判定表 和 判定树 ，所以说 结构化英语 是一个用来写基本加工逻辑说明的工具。

了解完这个知识点后，我们开始来看结构化英语是什么吧！

（3）结构化英语 (Data Flow Diagram, DFD)

1）结构化英语是什么

• 结构化英语就是一种基本加工逻辑说明的方法。
• 结构化英语是一种介于自然语言和形式化语言之间的语言。
• 语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示。

2）结构化英语的词汇表构成

• 英语命令动词；
• 数据词典中定义的名字；
• 有限的自定义词；
• 逻辑关系词 IF_THEN_ELSE 、CASE_OF 、WHILE_DO 、REPEAT_UNTIL 等组成。

3）常见基本控制结构

• 顺序结构；
• 重复结构while_do 或 repeat_until 结构；
• 判定结构：if_then_else 或 case_of 结构。

4）案例：商店业务处理系统中”检查发货单“

if 发货单金额超过$500 thenif 欠款超过了60天 then在偿还欠款前不予批准else //（欠款未超期）发批准书，发货单      
else //（发货单金额未超过$500）if 欠款超过60天 then发批准书，发货单及赊欠报告else //（欠款未超期）发批准书，发货单      

（4）判定表 (Data Flow Diagram, DFD)

1）使用条件

如果数据流图的加工需要依赖于多个逻辑条件的取值，使用判定表来描述比较合适。

2）图例

3）案例剖析

案例一：检查发货单

大家可以看到，在上图中，左上角的地方是条件，也称为条件桩。而因为条件引发的操作/动作，即左下角部分，称为动作桩。

有了条件桩和动作桩以后，它们有一一对应的数据。条件桩对应条件项，动作桩对应动作项，即右上角和右下角部分。

案例二：旅游预订票系统“计算折扣量”

同样的，与依据案例一的例子同样判断。上面是条件桩和条件项，下面是动作桩和动作项。

（5）判定树 (Data Flow Diagram, DFD)

1）使用条件

判定树也是用来表达加工逻辑的一种工具，有时侯它比判定表更直观。

2）案例剖析

同样，我们依据判定表的两个例子来做成判定树。

案例一：检查发货单

案例二：旅游预订票系统“计算折扣量”

从上面两张图中可以看到，判定树相较于判定表来说会更加直观。

三、动态分析方法

1、为什么需要系统动态分析方法？

• 系统的需求规格说明通常是用自然语言来叙述的，但是用自然语言描述往往会出现歧义性。

• 因此，为了直观地分析系统的动作，从特定的视角出发去描述系统的行为，需要采用动态分析的方法。

2、最常用的动态分析方法

（1）状态迁移图

1）状态迁移图是什么？

状态迁移图，即 State Transition Diagram，缩写为 STD 。状态迁移图是描述系统的状态如何使外部的信号进行推移的一种图形表示。

2）状态迁移图的表示方式

• 圆圈 ○ 表示可得到的系统状态。
• 箭头 → 表示从一种状态向另一种状态的迁移。

3）案例剖析：CPU进程的状态迁移

假设某个系统当前有多个状态申请占用CPU运行的进程, 其中CPU所分配进程的状态迁移如下。

由上图可分析出状态迁移图，状态迁移表以及相对应的状态，如下图所示。

4）状态迁移图的优点

• 状态之间的关系能够直观地被捕捉到。

• 由于状态迁移图的单纯性，能够机械地分析许多情况，可很容易地建立分析工具。

（2）时序图

1）时序图是什么？

时序图 （Sequence Diagram） ，又名序列图、循序图，是一种 UML 交互图。它通过描述对象之间发送消息的时间顺序来显示多个对象之间的动态协作。

2）案例剖析：功能事件

在下图中, 对于事件 e , 功能1～功能3 的处理时间总计为 (T1＋T2＋T3） ，其中功能间切换时间为 0 。

3）案例剖析：进程间的通信流

在下图中，采用扩充时序图可表示进程间的通信流，用于分析几个事件的交错现象。 C1 与 C2 ，R1 与 R2 是交错的。因此，可以做如下分析：“ HOST1 在等待 C1 的回答时（即 R1 期间），要能接收从 HOST2 发出的命令 C2 。”

四、写在最后

对于软件工程中的结构化系统分析来说，主要解决软件“做什么”的问题。特别是关于数据流图和数据字典的内容较多，学完要多消化总结。同时我也将在下一篇文章讲解关于数据流图与数据字典的一些案例分析。

关于软件工程的结构化系统分析就讲到这里啦！如有需要了解软件工程相关的其他内容，可到『软件工程』栏目进行查看学习~

如有不理解或有误的地方也欢迎评论区评论或私信我交流~

• 关注公众号 星期一研究室 ，不定期分享学习干货，学习路上不迷路~
• 如果这篇文章对你有用，记得点个赞加个关注再走哦~