概述

结构化方法是一种面向数据流的开 发方法，它由以下构成：

  • 结构化分析：根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析工作。
  • 结构化设计：根据模块独立性准则、软件结构优 化准则将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的 概要设计。
  • 结构化程序设计：使用3种基本控制结构构造程序，任何程序都可以由顺序、选择和重复3种基本控制结构构造。

结构化方法总的指导思想是自顶向下、逐层分解，它的基本原则是功能的分解与抽象。它是软件工程中最早出现的开发方法，特别适合于数据处理领域的问题，但是不适合解决大规模的、特别复杂的项目，且难以适应需求的变化。

系统设计

抽象

抽象是一种设计技术，重点说明一个实体的本质方面，而忽略或者掩盖不太重要或非本质的方面。

抽象是一种重要的工具，用来将复杂的现象简化到可以分析、实验或者可以理解的程度。

软件工程中从软件定义到软件开发要经历多个阶段，在这个过程中每前进一步都可看作是对软件解法的抽象层次的一次细化。

抽象的最底层就是实现该软件的源程序代码。在进行模块化设计时也可以有多个抽象层次，最高抽象层次的模块用概括的方式叙述问题的解法，较低抽象层次的模块是较高抽象层次模块对问题解法描述的细化。

模块化

  • 模块：是在程序中是数据说明、可执行语句等程序对象的集合，或者是单独命名和编址的元素，例如高级语言中的过程、函数和子程序等。

    在软件的体系结构中，模块是可组合、分解和更换的单元。

  • 模块化：是指将一个待开发的软件分解成若干个小的简单部分一模块，每个模块可独立地开发、测试，最后组装成完整的程序。

    这是一种复杂问题“分而治之”的原则。

    模块化的目的是使程序的结构清晰，容易阅读、理解、测试和修改。

  • 模块独立：是指每个模块完成一个相对独立的特定子功能，并且与其他模块之间的联系简单。

    衡量模块独立程度的标准有（模块独立性的两个定性标准）：

    • 耦合性；
    • 内聚性。

    在将软件系统划分模块时，应尽量做到高内聚、低耦合，提高模块的独立性。

通常，可以按照在软件系统中的功能将模块分为四种类型：

  • 传入模块：取得数据或输入数据，经过某些处理，再将其传送给其他模块。
  • 传出模块：输出数据，在输出前可能进行某些处理。数据可能被输出到系统的外部，或者会输出到其他模块进行进一步处理。
  • 变换模块：从上级调用模块得到数据，进行特定的处理，转换成其他形式，再将加工结果返回给调用模块。
  • 协调模块：一般不对数据进行加工，主要是通过调用、协调和管理其他模块来完成特定的功能。

耦合

耦合是模块之间的相对独立性（互相连接的紧密程度）的度量。

模块之间的耦合取决于：

  • 各个模块之间接口的复杂程度；
  • 调用模块的方式；
  • 通过接口的信息类型。

一般模块之间可能的耦合方式有7种类型：

耦合的种类

  • 无直接耦合：指两个模块之间没有直接的关系，它们分别从属于不同模块的控制与调用，它们之间不传递任何信息。

    无直接耦合的模块间：

    • 耦合性最弱；
    • 模块独立性最高。

  • 数据耦合：指两个模块之间有调用关系，传递的是简单的数据值，相当于高级语言中的值传递。

  • 标记耦合：指两个模块之间传递的是数据结构。

  • 控制耦合：指一个模块调用另一个模块时，传递的是控制变量，被调用模块通过该控制变量的值有选择地执行模块内的某一功能。

  • 外部耦合：模块间通过软件之外的环境联结（如I/O将模块耦合到特定的设备、格式、通信协议上）时称为外部耦合。

  • 公共耦合：指通过一个公共数据环境相互作用的那些模块间的耦合。

  • 内容耦合：当一个模块直接使用另一个模块的内部数据，或通过非正常入口转入另一个模块内部时，这种模块之间的耦合称为内容耦合。

耦合类型 说明
无直接耦合 没有直接关系，不传递任何信息
数据耦合 调用关系，传递简单数据值
标记耦合 传递数据结构
控制耦合 调用关系，被调模块传递给主调模块控制变量
外部耦合 通过软件之外的环境联结
公共耦合 通过公共数据环境相互作用
内容耦合 直接使用另一个模块的内部数据
或通过非正常入口转入另一个模块内部

解耦：降低模块之间的耦合性的过程。

内聚

内聚是对一个模块内部各个元素彼此结合的紧密程度的度量。一个内聚程度高的模块（在理想情况下）应当只做一件事。

一般模块的内聚性分为7种类型：

内聚的种类

  • 偶然内聚（巧合内聚）：指一个模块内的各处理元素之间没有任何联系。

    偶然内聚具有最低的内聚性。

    具有偶然内聚的模块具有以下特点（缺点）：

    • 不易修改、理解和维护；
    • 会影响到模块间的耦合关系。

  • 逻辑内聚：指模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能。

  • 时间内聚：把需要同时执行的动作组合在一起形成的模块。

  • 过程内聚：指一个模块完成多个任务，这些任务必须按指定的过程执行。

  • 通信内聚：指模块内的所有处理元素都在同一个数据结构上操作，或者各处理使用相同的输入数据或者产生相同的输出数据。

  • 顺序内聚：指一个模块中的各个处理元素都密切相关于同一功能且必须顺序执行，前一功能元素的输出就是下一功能元素的输入。

  • 功能内聚：指模块内的所有元素共同作用完成一个功能，缺一不可。

    这是最强的内聚。

内聚类型 说明
偶然内聚
（巧合内聚）		 各处理之间没有任何联系
逻辑内聚 执行若干个逻辑上相似的功能，
通过参数确定该模块完成哪一个功能
时间内聚 把需要同时执行的动作组合在一起
过程内聚 完成多个任务，这些任务必须按指定的过程执行
通信内聚 所有处理都在同一个数据结构上操作，
或者各处理使用相同的输入数据或者产生相同的输出数据
顺序内聚 各处理都与同一功能密切相关且必须顺序执行，
前一功能元素的输出就是下一功能元素的输入
功能内聚 所有元素共同作用完成一个功能，缺一不可

系统结构设计原则

为保证总体结构设计顺利完成，应遵循以下几条原则：

  • 分解——协调原则：

    系统整体，具有其整体的目的和功能，但这些目的和功能的实现又是由相互联系的各个组成部分共同工作的结果。解决复杂问题的一个很重要的原则就是把它分解成多个小问题分别处理，在处理过程中根据系统总体要求协调各部门的关系。

  • 自顶向下的原则：

    从上往下，逐层分解；先确定上层模块的功能，再确定下层模块的功能。

  • 信息隐蔽、抽象的原则：

    上层模块只规定下层模块做什么和所属模块间的协调关系，但不规定怎么做，以保证各模块的相对独立性和内部结构的合理性，使得模块与模块之间层次分明，易于理解、实施和维护。

  • 一致性原则：

    要保证整个软件设计过程中具有：

    • 统一的规范、
    • 统一的标准、
    • 统一的文件模式
    • ……

  • 明确性原则：

    每个模块必须：

    • 功能明确、接口明确；
    • 消除多重功能和无用接口。

  • 高内聚、低耦合：

    模块之间的耦合尽可能小，模块的内聚度尽可能高。

  • 模块的扇入系数和扇出系数要合理：

    • 扇出系数：模块直接调用其他模块的个数。
    • 扇入系数：模块被其他模块调用时，直接调用它的模块个数。

    经验表明，一个设计得好的系统的平均扇入、扇出系数通常是 3 或 4，一般不应超过 7，否则会引起出错概率的增大。但菜单调用型模块的扇入与扇出系数可以大一些，公用模块的扇入系数可以大一些。

  • 模块的规模适当：

    • 过大的模块常常使系统分解得不充分；
    • 过小的模块有可能降低模块的独立性，造成系统接口的复杂性。

  • 模块的作用范围应该在其控制范围之内。

  • 避免或减少使用病态连接：病态连接是指从中部进入或访问一个模块。

系统文档

信息系统的文档是系统建设过程的“痕迹”，是系统维护人员的指南，是开发人员与用户交流的工具。

对文档在系统开发人员、项目管理人员、系统维护人员、系统评价人员以及用户之间的多种作用总结如下：

  • 用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通。

    这里的文档主要包括：

    • 可行性研究报告、
    • 总体规划报告、
    • 系统开发合同、
    • 系统方案说明书。

  • 系统开发人员与项目管理人员通过文档在项目期内进行沟通。

    这里的文档是指项目管理文件，主要有：

    • 系统开发计划，

      包括：

      • 工作任务分解表、
      • PERT图、
      • 甘特图、
      • 预算分配表；

    • 系统开发月报；

    • 系统开发总结报告。

    有了这些文档可以：

    • 不同阶段开发人员工作的顺利交接；
    • 降低因为人员流动带来的风险。

  • 系统测试人员与系统开发人员通过文档进行沟通。

    系统测试人员可以根据以下文档对系统开发人员所开发的系统进行测试：

    • 系统方案说明书、
    • 系统开发合同、
    • 系统设计说明书、
    • 测试计划。

    系统测试人员再将评估结果撰写成系统测试报告。

  • 系统开发人员与用户在系统运行期间进行沟通。

    用户通过系统开发人员撰写的文档运行系统。这里的文档主要是：

    • 用户手册、
    • 操作指南。

  • 系统开发人员与系统维护人员通过文档进行沟通。

    这里的文档主要有：

    • 系统设计说明书；

    • 系统开发总结报告。

      开发总结报告还可分为以下3个文档：

      • 研制报告；
      • 技术报告；
      • 技术手册：记录了系统开发过程中的各种主要技术细节。

  • 用户与维修人员在运行维护期间进行沟通。

    用户在使用信息系统的过程中，将运行过程中的问题进行记载，形成：

    • 系统运行报告、
    • 维护修改建议。

    系统维护人员根据以下文档对系统进行维护和升级：

    • 维护修改建议；
    • 系统开发人员留下的技术手册等文档。
人员 阶段 文档
用户
系统分析人员		 系统规划
系统分析		 沟通文档，主要是规划报告、合同、方案：
  • 可行性研究报告
  • 总体规划报告
  • 系统开发合同
  • 系统方案说明书
系统开发人员
项目管理人员		 项目期内 沟通文档（项目管理文件），主要是计划、报告类文档：
  • 系统开发计划
    • 工作任务分解表
    • PERT图
    • 甘特图
    • 预算分配表
  • 系统开发月报
  • 系统开发总结报告
系统测试人员
系统开发人员		 测试 系统测试人员根据以下文档对系统进行测试：
  • 系统方案说明书
  • 系统开发合同
  • 系统设计说明书
  • 测试计划
系统测试人员再将评估结果撰写成系统测试报告
系统开发人员
用户		 系统运行期间 用户通过系统开发人员撰写的文档运行系统：
  • 用户手册
  • 操作指南
系统开发人员
系统维护人员		 维护 沟通文档：
  • 系统设计说明书
  • 系统开发总结报告
    • 研制报告
    • 研制报告
    • 技术手册
用户
维修人员		 运维 用户将运行过程中的问题进行记载：
  • 系统运行报告
  • 维护修改建议
系统维护人员根据以下文档对系统进行维护和升级：
  • 维护修改建议
  • 系统开发人员留下的技术手册等文档

结构化分析方法

数据流图

数据流图也称数据流程图（Data Flow Diagram，DFD），是一种便于用户理解、分析系统数据流程的图形工具。它摆脱了系统的物理内容，精确地在逻辑上描述系统的功能、输入、输出和数据存储等，是系统逻辑模型的重要组成部分。

数据流图中的基本图形元素包括：

  • 数据流（Data Flow）：由一组固定成分的数据组成，表示数据的流向。

    数据流

    在DFD种，数据流的流向由以下几种：

    • 从加工流向另一个加工；
    • 从加工流向数据存储（写）；
    • 从数据存储流向加工（读）；
    • 从外部实体流向加工（输入）；
    • 从加工流向外部实体（输出）。

    即数据流的起点或终点必须至少有一个是加工。

    除了与数据存储有关的数据流（流向数据存储或从数据存储流出），DFD中的每个数据流都必须用一个定义明确的名字表示。

  • 加工（Process）：加工描述了输入数据流到输出数据流之间的变换，也就是输入数据流经过什么处理后变成了输出数据流。

    加工

    每个加工都有一个名字和编号。

    一个加工可以有多个输入数据流和多个输出数据流，但至少有一个输入数据流和一个输出数据流。

    数据流图中常见的3种错误如下所示：

    • 黑洞：加工只有输入，没有输出。

      如下图加工1。

    • 白洞：加工只有输出但没有输入。

      如下图加工2。

    • 灰洞：加工中输入数据不足以产生输出数据。

      有几种可能的原因：

      • 一个错误的命名过程；
      • 错误命名的输入或输出；
      • 不完全的事实。

      如下图加工3。

    数据流图中常见错误

  • 数据存储（Data Store）：存储和提供数据。

    数据存储

    每个数据存储都有一个定义明确的名字标识。

    数据存储可以：

    • 存储加工的输出数据：数据流流入数据存储，表示数据的写入操作；
    • 提供加工的输入数据：数据流从数据存储流出，表示数据的读操作。
    • 双向箭头的数据流指向数据存储，表示对数据的修改。

    DFD中的数据存储在具体实现时可以用以下方式实现：

    • 文件系统实现；
    • 数据库系统实现。

    数据存储的存储介质可以是：

    • 磁盘、
    • 磁带、
    • 其他存储介质。

  • 外部实体（External Agent，外部主体）：指存在于软件系统之外的人员、组织、物体或外部系统，它指出系统所需数据的发源地（源）和系统所产生的数据的归宿地（宿）。

    外部实体

    例如：

    • 人员：学生、老师、员工、主观、医生、客户……
    • 组织：供应商、采购部门……
    • 物体：传感器、控制器、单车、车辆……
    • 外部系统：支付系统、车辆交易系统、库存管理系统、道闸控制系统……

    在许多系统中，某个源和某个宿可以是同一个人员、组织、物体或外部系统，此时，在DFD中可以用同一个符号表示：

    • 当数据流从该符号流出时，表示它是源；
    • 当数据流流向该符号时，表示它是宿；
    • 当两者皆有时，表示它既是源又是宿。

    外部实体表示存在于系统之外的对象，用来帮助用户理解系统数据的来源和去向。

软件系统内部的数据处理模型：使用数据流、加工和数据存储构建。

数据流图描述了系统的分解，但没有对图中各成分进行说明。

基本元素 图形表示
数据流 数据流
加工 加工
数据存储 数据存储
外部实体 外部实体

数据流图必须确保：

  • 数据流的起点或终点必须至少有一个是加工。
  • 加工至少有一个输入数据流和一个输出数据流。

分层数据流图：

  1. 顶层图：描述系统的输入和输出。

    即描述系统从哪些外部实体接受数据流，以及系统发送数据流到哪些外部实体。

    • 顶层图只有一个加工，即待开发的软件系统。
    • 顶层图中的数据流就是系统的输入/输出信息。
    • 顶层图中通常没有数据存储。

  2. 0层图：分解顶层图的加工。

  3. 再分解：将DFD中某些比较复杂的加工再次分解成一张DFD子图。

数据字典

数据字典（DD）是为数据流图中的以下成分做出说明：

  • 数据流；
  • 文件；
  • 加工：对加工的描述称为“小说明”或“加工逻辑说明”；
  • 组成数据流或文件的数据项。

数据字典有以下4类条目：

  • 数据流条目：对DFD中数据流的定义，通常列出该数据流的各组成数据项。

    符号 含义 举例及说明
    $=$ 被定义为
    $+$ 与 $x = a + b$：$x$由$a$和$b$组成
    $[a|b]$ 或 $x = [a
    $\{a\}$ 重复 $x = \{a\}$：$x$由任意个$a$组成
    $m\{a\}n$
    或
    $\big\{ a \big\}^{n}_{m}$    		 重复 $x=m\{a\}n$ 或 $x=\big\{a\big\}^{n}_{m}$：$x$中出现$m \sim n$次$a$
    • $n$：重复次数的上限
    • $m$：重复次数的下限
    $(a)$ 可选 $x = (a)$：$a$在$x$中出现$0$或$1$次
    $“a”$ 基本数据元素 $x = “a”$：$x$是取值为字符$a$的数据元素
    $m..n$ 连接符 $x = m..n$：$x$可取$m \sim n$中的任意一个值

  • 数据项条目：组成数据流和数据存储的最小元素，是不可再分解的数据单位。

  • 数据存储条目：对DFD中数据存储的定义。

  • 基本加工条目：用来说明DFD中（下层）基本加工的处理逻辑（加工逻辑）。

    • 对每一个基本加工，必须有一个加工规格说明（加工逻辑描述）。
    • 加工规格说明（加工逻辑描述）必须描述基本加工如何把输入数据流变换为输出数据流的加工规则。
    • 加工规格说明必须描述实现加工的策略，而不是实现加工的细节。
    • 加工规格说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息。

    结构化语言、判定树和判定表可以用来表示加工逻辑。

源点、终点不在系统之内，故一般不在字典中说明。

用户界面设计

用户界面（UI）设计在人与计算机之间搭建了一个有效的交流媒介。

黄金原则

黄金原则一共有3条：

  • 用户操纵控制
  • 减少用户的记忆负担
  • 保持界面一致