软件设计师-6.结构化开发方法

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

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

6.1 系统分析与设计概述

6.1.1 系统分析概述

系统分析是一种问题求解技术，它将一个系统分解成各个组成部分，目的是研究各个部分如何工作、交互，以实现其系统目标。系统分析强调业务方面的问题，而非技术实现方面。

系统分析的目的和任务：进行一系列分析，提交系统分析报告，即系统方案说明书。

系统分析的主要步骤：

1. 认识和理解当前现实环境，获得当前系统的“物理模型”
2. 从当前系统的物理模式抽象出当前系统的“逻辑模型”
3. 从当前系统的“物理模型”进行分析和优化，建立目标系统的“逻辑模型”
4. 从目标系统的逻辑模型具体化，建立目标系统的物理模型

 

按照上图，可将系统分析阶段的主要工作分为以下几步：

1. 对当前系统进行详细调查，收集数据。
2. 建立当前系统的逻辑模型。
3. 对现状进行分析，提出改进意见和新系统应达到的目标。
4. 建立新系统的逻辑模型。
5. 编写系统方案说明书。

6.1.2 系统设计的基本原理

1. 抽象

   重点说明实体的本质方面，忽略非本质的方面。抽象的最底层就是实现该软件的源程序代码。

   较低抽象层次的模块是较高抽象层次模块对问题解法描述的细化。

2. 模块化

   在程序中是数据说明、可执行语句等程序对象的集合，或者是单独命名和编制的元素，模块是可以组合分解和更快的单元。

   【目的】使程序的结构清晰、易读、理解、测试和修改。

3. 信息隐蔽

   开发整体程序结构时使用的法则，即将每个程序的成分隐蔽或封装在一个单一的设计模块中，在定义一个模块时，尽可能少地暴露其内部的处理。

   【目的】提供软件的可修改性、可测试性、可移植性。

4. 模块独立

   每个模块完成一个相对独立的特定子宫内，并且与其他模块联系简单。

   【衡量标准】：耦合性和内聚性。

 

内聚（从高到底）

• 功能内聚：最强的内聚，完成一个单一功能，各个部分协同工作，缺一不可。
• 顺序内聚：各个处理元素都密切相关与同一功能，且必须顺序执行，前一个功能元素的输出就是下一个功能元素的输入
• 通信内聚：所有处理元素集中在一个数据结构区域上，或者各处理使用相同的输入数据或产生相同的输出数据
• 过程内聚：模块内部的处理成分是相关的，而且这些处理必须以特定的次序执行
• 瞬时内聚（时间内聚）：把需要同时执行的动作组合在一起形成的模块
• 逻辑内聚：模块内执行若干个逻辑上相似的功能，通过参数确定该模块完成哪一个功能
• 偶然内聚（巧合内聚）：模块内的各处理元素之间没有任何联系

耦合（从低到高）

• 非直接耦合：两个模块之间没有直接关系，分别从属于不同模块的控制和调用，之间不传递任何信息。
• 数据耦合：两个模块之间有调用关系，传递简单的数据值
• 标记耦合：两个模块之间传递的是数据结构
• 控制耦合：一个模块调用另一个模块时，传递的是控制变量，被调用模块根据控制变量执行某个功能
• 外部耦合：模块间通过软件之外的环境联结（如 I/O 将模块耦合到特定的设备、格式、通用协议上）
• 公共耦合：通过一个公共数据环境互相作用的那些模块间的耦合
• 内容耦合：一个模块直接使用另一个模块的内部数据；或通过非正常入口而转入另一个模块内部

6.1.3 系统总体结构设计

系统结构设计原则：

1. 分解-协调原则。复杂问题分解成多个小问题，在处理问题过程中协调各部门关系。
2. 自顶向下原则。
3. 信息隐蔽、抽象原则。
4. 一致性原则。
5. 明确性原则。
6. 模块之间的耦合尽可能小，内聚尽可能高。
7. 模块的扇入系数和扇出系数要合理。一个模块直接调用其他模块的个数称为模块的扇出系数；反之，一个模块被其他模块调用时，直接调用它的模块个数称为模块的扇入系数。
8. 模块的规模适当。

子系统的划分：

1. 子系统划分的原则
   • 子系统要具有相对独立性
   • 子系统之间数据的依赖性尽量小。
   • 子系统划分的结果应使数据冗余较小。
   • 子系统的设置应考虑今后管理发展的需要。
   • 子系统的划分应便于系统分阶段实现。
   • 子系统的划分应考虑到各类资源的充分利用。
2. 子系统结构设计
   • 每个子系统如何划分成多个模块。
   • 如何确定子系统之间、模块之间传送的数据及其调用关系。
   • 如何评价并改进模块结构的质量。
   • 如何从数据流图导出模块结构图。

系统模块结构设计:

1. 一个模块应具备4个要素（前两个是模块外部属性，后两个是内部属性）

   • 输入与输出
   • 处理功能
   • 内部数据
   • 程序代码

2. 模块结构图

   模块结构图主要关心的是模块的外部属性，即上下级模块、同级模块之间的数据穿肚和调用关系，并不关系模块的内部结构。

   模块结构图是结构化设计中描述系统结构的图形工具。

   模块结构图由模块、调用、数据、控制信息和转接符号5种基本符号组成。

    

   • 模块：指一个名字就可以调用的一段程序语句。在长方形中间标上能反映模块处理功能的模块名字。

   • 调用：箭头（调用模块指向被调用模块），但是应该理解被调用模块指向后又返回调用模块

     调用分为以下三种

      

   • 数据：当一个模块调用另一个模块时，调用模块可以把数据传送到被调用模块供处理，而被调用模块可以将处理结果送回到调用模块。如下图表示模块A 调用 模块B 时，A 将数据 x、y 传送给 B，B 将处理结果数据 z 返回给 A；

      

   • 控制信息：模块间有时必须传送某些控制信息。例如，数据输入完后给出结束标志，文件读到末尾时所产生的文件结束标志等等。控制信息与数据的主要区别就是前置只能反映数据的某种状态，不必进行处理。图中的“无此职工”就是用来表示送来的职工号有误的控制信息。

      

   • 转接符号：当模块结构图在一张智商画不下，需要转接到另一张纸上，或者为了避免图上线条交叉，都可以使用转接符号，圆圈内加上标号，如下图所示。

      

数据存储设计

1. 有关数据库及数据库设计的相关内容可参见本书第7章节。
2. 建立了数据的整体结构之后，剩下 但就是要确定数据的资源分布和安全保密性。其中数据分布是针对分布数据库系统而言，而安全保密属性是则是针对某些特殊信息，例如财务数据等而言的。

6.1.4 系统文档

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

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

1. 用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通。这里的文档主要包括可行性报告、总体规划报告、系统开发合同和系统方案说明书等。
2. 系统开发人员与项目管理人员通过文档通过在项目期内进行沟通。文档主要有系统开发计划（包括工作任务分解表、PERT图、甘特图和预算分配表等）、系统开发月报以及系统开发总结报告等项目管理文件。
3. 系统测试人员与系统开发人员通过文档进行沟通。系统测试人员可以根据系统方案说明书、系统开发合同、系统设计说明书和测试计划等文档对开发人员所开发的系统进行测试。系统测试人员再将评估结果撰写成系统测试报告。
4. 用户通过系统开发人员撰写的文档运行系统。这里的文档主要是用户手册和操作指南。
5. 系统开发人员和系统维护人员通过文档进行沟通。这里的文档主要有系统设计说明书和系统开发总结报告。有的开发总结报告写的很详细，分为研制报告、技术报告和技术手册3个文档，其中技术手册记录了系统开发过程中的各种主要技术细节。
6. 用户与维修人员在运行维护期间进行沟通。用户在使用信息系统的过程中，将运行过程中的问题进行记录，形成系统运行报告和维护修改建议。系统维护人员根据维护修改建议以及系统开发人员留下的技术手册等文档对系统进行维护和升级。

6.2 结构化分析方法

结构化分析与设计方法是一种面向数据流的传统软件开发方法，它以数据流为中心构建软件的分析模型和设计模型。

6.2.1结构化分析方法概述

抽象和分解是处理任何复杂问题的两个基本手段。

结构化分析的结构一般由以下几个部分组成：一套分层的数据流图、一本数据词典、一组小说明（也称加工逻辑说明）、补充材料。

6.2.2 数据流图

数据流图也称数据流程图，它是一种用户理解、分析数据流程的图形工具。是系统逻辑模型的重要组成部分。

1.数据流图的基本图形元素

数据流图的基本图形元素包括 数据流（data flow）、加工（process）、数据存储（data store）和外部实体（external agent）。其中，数据流、加工、数据存储用于构建软件系统内部的数据处理模型；外部实体表示存在系统之外的对象，用来帮助用户理解数据的来源和去向。DFD的基本图形元素如下所示。

 

1. 数据流

   数据流由一组固定成分的数据组成，表示数据的流向。在DFD中，数据流的流向可以有以下几种：

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

   DFD中的每个数据流用一个定义明确的名字表示。除了流向数据存储或从数据存储流出的数据流不必命名外，每个数据流都必须有一个合适的名字，以反应该数据流的含义。值得注意的是，DFD中描述的数据流，而不是控制流。

   数据流或者由具体的数据属性（也称数据结构）构成，或者由其他数据流构成。组合数据流是由其他数据流构成的数据流，它用于在高层的数据流图找那个组合相似的数据，以便使数据流图更便于阅读。

2. 加工

   加工描述了数据流到输出流之间的转换。每个加工都有一个名字和编号。编号能翻译出该加工位于分层DFD中的哪一个层次和那张图中，也能够看出它是哪个加工分解出来的自加工。

   一个加工可以有多个输入数据流和多个输出数据流，但至少有一个输入数据流和一个输出数据流。常见的错误，如下所示：

   • 3.1.2 有输入但没有输出，我们称之为“黑洞”。
   • 3.1.3 有输出但没有输入。
   • 3.1.1 中输入不足以产生输出，我们称之为“灰洞”。这有几种可能原因：一个错误的命名过程；错误命名的输入或输出；不完全的事实。“灰洞”是最为常见的错误，也是最使人为难的命名过程。一旦数据流图交给了程序员，到一个加工的输入流必须足以产生输出数据流。

    

3. 数据存储

   数据存储用来存储数据。通常，一个输入流加工的数据流经过加工处理后就小时了，而它的某些数据（或全部数据）可能被加工成输出数据流，流向其他加工或外部实体。除此之外，在软件系统中还常常要把某些信息保存下来以供以后使用，这时可以使用数据存储。例如，在考务处理系统中，报名时产生的考生名册要随着报名的过程不断补充，在统计成绩和制作考生通知书时还要使用考生名册的相关信息。因此，考生名册可以作为数据存储存在，以保存相关的考生信息。

   每个数据存储都有一个明确的名字标识。可以有数据输入流数据存储，表示数据的写入操作；也有可可有数据流从数据存储流出，表示数据的读操作；还可以用双箭头的数据流执行数据存储，表示对数据的修改。

   这里要说明的是 DFD 中的数据存储在具体实现时可以用文件系统实现，也可以用数据库系统实现。数据存储的存储介质可以说磁盘、磁带或其他存储介质。

4. 外部实体（外部主体）

   外部实体是指存在于软件系统之外的人员或组织，它指出系统所需数据的发源地（源）和系统所产生的数据的归宿地（宿）。例如，对于一个考务处理系统而言，考生向系统提供报名单（输入数据流），所以考生是考务处理系统的一个源；而考务处理系统将要考试成绩的统计分析表（输出数据流）传递给考试中心，所以考试中心是该系统的一个宿。

   在许多系统中，某个源和某个宿可以是同一个人员或组织，此时 DFD 中可以用同一个符号表示。考生向系统提供名单，而系统向考生送出准考证，所以在考务处理系统中，考生既是源又是宿。

   源和宿采用相同的图像符号表示，当数据流从该符号流出时，表示它是源；当数据流流向该符号时，表示它是宿；当两者皆有时，表示它既是源又是宿。

2.数据流图的扩充符号

在DFD中，一个加工可以有多个输入数据流和多个输出数据流，此时可以加上一些扩充符号来描述多个数据流之间的关系。

1. 星号(*)：与关系，所有输入数据流全部到达后才能处理；加工结束时将同时产生所有的输出数据流。
2. 加号(+)：或关系，任何
3. 异或(⊕)：异或表示数据流之间存在“互斥关系”。

3.数据流图的层次结构

理论上讲，只要纸足够大，一个软件系统的分析模型就可以画在一张纸上。然而，一个复杂的软件系统可能设计上百个加工和上百个数据流，甚至更多。如果将它们画在一张图上，则会十分复杂。

项目根据自顶向下逐层分解的思想，可以将数据流图按照层次结构来绘制，每张图的加工格尔书可大致控制在“7加减2”的范围内，从而构成一套分层数据流图。

1. 层次结构

   分层数据流图的顶层只有一张图，其中只有一个加工，代表整个系统，该加工描述了软件系统与外界之间的数据流，称为顶层图。

   顶层图中的加工（即系统）经分解后的图称为0层图，也只有一张。处于分层数据流图最底层的图称为底层图，在底层图中，所有的加工不在进行分解。分层数据流图中的其他图称为中间层，其中至少有一个加工（也可以是所有加工）被分解成一张子图。在整个分层数据流图中，凡是不在分解成子图的加工，称为基本加工。

2. 图和加工的编号

   首先介绍父图和子图的概念。

   如果某图（记为A）中的某一个加工分解成一张子图（记为B），则称A是B的父图，B是A的子图。若父图中有n个加工，则它可以有0~n 张子图，但每张子图只能对应一张父图。

   为了方便对图进行管理和查找，可以采用下列方式对 DFD 中的图和加工编号。

   • 顶层图中只有一个加工（代表整个系统），该加工不必编号。
   • 0层图中的加工变红分别为 1、2、3...。
   • 子图号就是父图中被分解的加工号。
   • 对于子图中的加工编号，若父图中的加工号为 x 的加工分解成某一子图，则该子图中的加工编号分别为 x.1、x.2、x.3、...。

4.分层数据流图的画法

下面以某考务处理系统为例介绍分层数据流图的画法。

考务处理系统需求分析如下：

1. 对考生送来的报名单进行检查。
2. 对合格的报名单编好准考证后将准考证送给考生，并将汇总后的考生名单送给阅卷站。
3. 对阅卷站送来的成绩清单进行检查，并根据考试中心指定的合格标准审定合格者。
4. 制作考生通知单（内含成绩合格/不合格标志）送给考生。
5. 按地区、年龄、文化程度、职业和考试级别等进行成绩分类统计和试题难度分析，产生统计分析表。

部分数据流的组成如下：

• 报名单 = 地区 + 序号 + 姓名 + 文化程度 + 职业 + 考试界别 + 通信地址
• 正式报名单 = 准考证号 + 报名单
• 准考证 = 地区 + 序号 + 姓名 + 准考证号 + 考试级别 + 考场
• 考生名单 = {准考证号 + 考试级别} （其中，{w}表示 w 重复多次）
• 考生名册 = 正式报名单
• 统计分析表 = 分类统计表 + 难度分析表
• 考生通知单 = 准考证号 + 姓名 + 通信地址 + 考试级别 + 考试成绩 + 合格标志

下面介绍话分层数据流图的步骤

1. 画系统的输入和输出

   系统的输入和输出用底层图来描述，即描述系统从哪些外部实体接收数据流，以及系统发送到数据流到哪些外部实体。

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

    

2. 画系统的内部

   先将顶层图的加工分解成若干个加工，并用数据流将这些加工连起来，是的顶层图中的输入数据经过若干个加工处理后变换成底层图中的输出数据流。这张图称为0层图。从一个加工画出一张数据流图的过程实际上就是对这个加工的分解。

   1. 确定加工。这里的加工指的是父图中某加工分解而成的自加工，可以用下面两种方法来确定加工。

      • 根据功能分解来确定加工。

      一个加工实际上翻译了系统的一种功能，根据功能分解的原理，将一个复杂的功能分解成若干个较小的功能，每个较小的功能就是分解后的子加工。这种方法多应用于高层 DFD 中加工的分解。

      • 根据业务处理流程确定加工。

      分析父图中的待分解的加工的业务处理流程，流程中的每一步都可能是一个子加工。特别注意在业务流程中数据流发生变化或数据流的值发生变化的地方，应该存在一个加工，该加工将元数据流处理成变化后的数据流。该方法多用于底层 DFD 中加工的分解，它能描述父加工中输入数据流到输出数据流之间的加工细节。

   2. 确定数据流。当用户把若干个数据看做一个整体来处理时，可以把这些数据看出一个数据流。通常，实际工作中的表单就是一种数据流。

      在父图某加工分解而成的子图中，父图中相应加工的输入/输出数据流就是子图边界上的输入/输出数据流。另外,在分解的子加工之间应增添一些新的数据流，这些数据流是加工过程中的中间数据，它们与所有的子加工一起完成了父图中相应加工的输入数据流到输出数据流的变换。如果某些中间数据需要保存，那么可以表示为流向数据存储的数据流。

      同一个源或加工可以有多个数据流向另一个加工，如果它们不是一起到达和一起加工的，那么将他们分成多个数据流。同样，同一个加工也可以有多个数据流流向另一个加工或宿。

   3. 确定数据存储。再由父图某加工分解而成的子图中，若父图中该加工存在流向数据存储的数据流，或从数据存储流向该加工的数据流，则这种数据存储和相关的数据流都画在子图中。

      在分解的子图中，如果需要保存某些中间数据，那么可以将这些数据组成一个新的文件。在自顶向下画分层数据流图时，新数据存储（第一次出现）至少应该有一个加工为其写入记录，同时至少存在一个加工读取该数据存储的记录。

      注意，从父图中继承下来的数据存储，在子图中只能对其读记录，或者写记录。

   4. 确定源和宿。通常在0层和其他子图中不必画出源和宿，但有时为了提供可读性，可以将底层图中的源和宿画在0层图中。

      当同一个外部实体（人或组织）既是系统的源又是宿时，可用同一个图像符号来表示。为了方便画图，同一个源或宿可重复画在DFD的不同位置，但它们仍代表一个实体。

在考务处理系统的0层图中，采用功能分解方法来确定加工。分析系统的需求说明，可知，系统功能分为考试报名及统计成绩，其中报名工作在考试前进行，统计成绩在考试后进行。

为此，定义两个加工：登记报名表和统计成绩。

 

1. 画内部加工

   当DFD中存在某个比较复杂的加工时，可以将它分解成一张DFD子图。分解的方法是将该加工看作是一个小系统，该加工的输入/输出数据流就是这个假设的小系统的输入/输出数据流，然后采用画0层的方法画出该加工的子图。

   下面介绍考务处理系统0层图中加工1的分解，这里根据业务处理流程来确定加工1的分解。分析考务处理系统的功能需求和0层图，将加工1分成3个子加工：检查报名表、编准考证号和登记考生。加工1分解而成的子图如下所示

    

   采用同样的方法画出加工2分解的 DFD 子图如下所示

    

   重复步骤3的分解，直到图中尚未分解的加工都足够简单。

5.分层数据流图的审查

1. 分层数据流图的一致性和完整性

   一致性

   • 父图与子图的平衡：即一种DFD子图边界上的输入/输出数据流必须与其父图中对应加工的输入/输出数据流保持 一致。
   • 数据守恒：一个加工的所有输出数据流中的数据，必须能从该加工的输入数据流中直接获得，或通过加工的处理产生；加工未使用其输入数据流中的某些数据项，这些数据项是多余的 ，可以从输入数据流中删除。
   • 局部数据存储：在一张DFD上，当一个数据存储为多个加工之间的交界面时，那么数据存储应该画在该DFD上；如果在一张DFD种，一个数据存储仅与一个加工进行读写操作，且该DFD的父（祖先）图中未出现该数据存储，那么这张DFD不该画出数据存储。
   • 同一加工的输出数据流不能与该加工的输入数据流同名。

   完整性

   • 每个加工至少有一个输入数据流和一个输出数据流。
   • 在整套分层数据流图中，每个数据存储应至少有一个加工对其进行读操作，另一个加工对其进行写操作。
   • 分层流图中的每个数据流和文件都必须命名（除了流入或流出数据存储的数据流），并与数据字典一致。
   • 分层数据流图中的每个基本加工都应有一个加工规约。

2. 构造分层DFD时需要注意的问题

   a)适当命名

   • 名字应反映整个对象，而不是只反映它的某一部分。
   • 避免使用空洞、含义不清的名字，如数据、信息、处理、统计等。
   • 若发现某个数据流或加工难以命名，往往是DFD分解不当的征兆，要考虑重新分解。

   b)画数据流而不是控制流

   c)避免一个加工有过多的数据流，若出现过多的数据流需重新分解，步骤如下：

   • 把需要分解的某图的所有子图连接成一张图。
   • 连接后的图分成几个部分，使各部分联系最小。
   • 重新定义父图，即步骤2的每个部分作为父图中的一个加工。
   • 建立各子图，即步骤2的每个部分都是一张子图
   • 为所有加工重新命名并编号。

   d)分解尽可能均匀。

   e)先考虑确定状态，忽略琐碎的细节。

   f)随时准备重画。

3. 分解的程度

   • 7加减2
   • 分解应自然，概念上清晰、合理
   • 只要不影响 DFD 的易理解性，可适当增加子加工数量、以减少层数
   • 一般来说，上层分解的快些，下层分解的慢些。
   • 分解要均匀

逻辑数据流图与物理数据流图之间的主要区别

• 物理数据流图关注的是系统中的物理实体，以及一些具体的文档、报告和其他输入/输出硬拷贝。物理数据流图用做系统构造和实现的技术性蓝图。
• 逻辑数据流图强调参与者所做的事情，可以帮助设计者决定哪些系统资源、为了运行系统用户必须执行的活动、在系统安装之后如何保护和控制这些系统。逻辑数据流图是物理数据流图去掉了所有物理细节后得到的变换形式，逻辑数据流图被用做系统分析的需求分析阶段的起点。

在 DFD 建模时，需要对有些复杂加工（处理）进行进一步精化，绘制下层数据流图。在复杂加工进行分解是要注意哪些问题？

• 保持父图与子图的平衡。父图中某加工的输入输出数据流必须与它的子图的输入输出数据流在数量和名字上相同。如果父图的一个输入/输出数据流对应子图中几个输入/输出数据流，而子图中组成这些数据流的数据项全体正好是父图中的这一个数据流，那么它们仍然算式平衡的。

数据流图是在系统分析与总体设计阶段宏观地描述系统功能需求的重要图形化工具，程序流程图也是软件开发过程中比较常用的图形化工具。简要说明程序流程图的使用场合与作用

• 程序流程图通常用在进行详细设计时使用，用来描述程序的逻辑结构。

6.2.3 数据字典

1. 数据字典内容

   • 数据流条目：DFD的数据流的定义，通常列出数据流的各组成属性。在定义数据流或数据存储组成时，使用下表给出的符号

     符号	含义	说明
     =	被定义为
     +	与	x = a+b，表示x由a和b组成
     {...\	...}	或
     {...}	重复	x = {a}，表示x由0或多个a组成
     m{...}n	重复	x = 2{a}5，表示x中最少出现2次a，最多出现5次a
     (...)	可选	x=(a)，表示a可在x中出现，也可不出现
     “...”	基本数据元素	x="a"，表示x是取值为字符a的数据元素
     ..	连接符	x=1..9，表示x可取 1~9中的任意一个值

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

   • 数据项条目：数据项条目是不可再分解的数据单位

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

2. 数据词典管理

   词典管理主要是把词典条目按照某种格式组织后存储在词典中，并提供排序、查找和统计等功能。

3. 加工逻辑的描述

   加工逻辑也称“小说明”

   • 结构化语言

     一种介于自然语言和形式化语言之间的半形式化语言，是自然语言的一个受限子集。

     它的结构通常分为外层和内层。外层语法严格，主要用来描述控制结构，采用顺序、选择和重复3中基本结构；内层使用数据字典中的名词和有限的自定义词，其动词含义要具体，尽量不要用形容词和副词来修饰，还可以使用一些简单的算法运算和逻辑运算符号。

   • 判定表

     某些情况，某个加工的一组动作仅依赖于多个路基条件的值，这时用自然语言和结构语言都不易与清楚的描述出来，而用判定表能够清楚地表示复杂的条件组合与应做的动作之间的对应关系。

     判定表由4个部分组成，用双线分割成4个区域，如下所示。

      

   • 判定树

     判定树是判定表的变形，一般情况下它比判定表更直观，且易于理解和使用。

6.3 结构化设计方法

结构化设计（structure design）方法是一种面向数据流的设计方法。

6.3.1 结构化设计的步骤

1.建立初始结构图

结构化方法本质上是一种功能分解方法。在结构化设计时，可以将整个软件看作一个大的功能模块，通过功能分解成若干个较小的功能模块，每个较小的功能模块还可以进一步分解。

功能模块的分解应满足自顶向下、逐步求精、信息隐蔽、高内聚低耦合等设计原则，模块的大小适中。通常，一个模块的大小以50100行代码为宜，即一个模块的程序代码可以写在12页纸。

2.对结构图的改进

根据设计准则对初始结构图进行改进

3.书写设计文档

在概要设计完成后应书写设计规格说明书，特别要为每个模块书写模块的功能、接口、约束和限制等，必要时可建立模块开发卷宗。

4.设计评审

对设计结果及文档进行评审。

6.3.2 数据流图到软件体系结构的映射

结构化设计是将结构化分析的结果(数据流图)映射成软件的体系结构（结构图）。根据信息流的特点，可将数据流图分为变换型数据流图和事务型数据流图，其对应的映射分别为变换分析和事务分析。

1.信息流的类型

面向数据流的设计能方便地将 DFD 转换成程序结构图。DFD中从系统的输入数据流到系统的输出数据流的一连串连续变换形成了一条信息流。DFD的信息流可以分为2类：变换流和事务流。

• 变换流

  信息沿着输入通路进入系统，同时将信息的外部形式转换成内部表示，然后通过变换中心处理，再沿着输出通路转换成外部形式离开系统。具有这种特性的信息流称为变换流。变换流型的DFD可以明显地分成输入、变换和输出三大部分。

• 事务流

  信息沿着输入通路到达一个事务中心，事务中心根据输入信息的类型在若干个动作序列中选择一个来执行，这种信息流称为事务流。事务流有明显的事务中心，各活动以事务中心为起点呈辐射状流出。

2.变换分析

变换分析是从变换流型的DFD导出程序结构图。

1. 确定输入流和输出流，分离出变换中心

   DFD中系统输入端的数据流称为物理输入，系统输出端的数据称为物理输出。物理输入经过编辑、格式转换、合法性检查、预处理等辅助性的加工才能称为真正输入（称为逻辑输入）。同样，由主加工产生的输出（称为逻辑输出）也要经过编辑、格式转换、组成物理块、缓冲处理等辅助加工才能变成物理输出。

   DFD中从物理输入到逻辑输入的部分构成输入流，从逻辑输出到物理输出的部分构成系统的输出流，位于输入流和输出流之间的部分就是变换中心。

2. 第一级分解

   第一级分解主要是设计模块结构的顶层和第一层。一个变换流型的 DFD 可以映射成如图所示的程序结构图。图中底层模块的功能就是整个系统的功能。输入控制模块可用来接收所有的输入数据，变换控制模块实现输入到输出的变换，输出控制模块用来产生所有的输出数据。

    

3. 第二级分解

   第二级分解主要是设计中、下层模块。

   1. 输入控制模的分解。从变换中心的边界开始，沿着每条输入通路，把输入通路上的每个加工映射成输入控制模块的一个低层模块。
   2. 输出控制模的分解。从变换中心的边界开始，沿着每条输出通路，把输除通路上的每个加工映射成输入控制模块的一个低层模块。
   3. 变换控制模的分解。变换控制模块通常没有通用的分解方法，应根据DFD中变换部分的实际情况进行设计。

4. 事务分析

   事务分析是从事务流型DFD导出程序结构图。

   1. 确定事务中心和每条活动流的流特性。下图给出了事务流型DFD的一般形式。其中，事务中心位于数条活动流的起点。每条活动流既可以是变换流也可以是是物流。一个事务流型的DFD由输入流、事务中心和若干条活动流组成。

       

   2. 将事务流型DFD映射成高层的程序结构。事务流型的高层结构图如下所示。顶层模块是正规系统的功能。接收模块用来接收输入数据，它对应于输入流。发送模块是一个调度模块，控制下层的所有活动模块。每个活动模型对应一个活动流，它也是该活动流映射成的程序结构图中的顶层模块。

       

5. SD 方法的设计步骤

   • 复查并精化数据流图
   • 确定DFD的信息流类型
   • 根据流类型分别变换分析或事务分析
   • 根据系统设计的原则，对程序结构图进行优化。

6.4 WebApp 分析与设计

6.4.1 WebApp 的特性

1. 网络密集性
2. 并发性
3. 无法预知的负载量
4. 性能
5. 可用性
6. 数据驱动

6.4.2 WebApp 需求模型

建模以需求工程中确定的用户类别、可用目标、使用场景、业务环节等各类需求等为输入产生如下5个模型类型。

1.内容模型

内容模型给出由 WebApp 提供的全部系列内容，包括文学、图形、图像、音频和视频。

内容模型包含结构元素，它们为 WebApp 的内容提供了一个重要的视图。这些结构元素包含内容对象和所有分类，在用户与WebApp交互时生成操作用户可见的实体。

内容的开发可能发生在 WebApp 实现之前、构建之中或者投入运行以后的很长一段时间里。它通过导航链接合并到 WebApp 的总体结构中。内容对象可能是产品的文本描述、描述新闻事件的一篇文章、拍摄的一张照片动作、在一次论坛讨论中某个用户的回答、一个演讲的简短视频等。这些内容对象可能存储于分离的文件中，直接嵌入Web页中，或从数据库中动态获得。换句话说，内容对象是呈现给最终用户具有汇聚信息的所有条目。

内容模型必须具备描述内容对象的能力。一些实例中，用一些简单的内容对象列表，并给出每个对象的简短描述就足以定义和实现所必需的内容需求。但是在某些情况下，内容模型可以从更丰富的分析中获得好处，即在内容对象之间的关系和 WebApp 维护的内容层次中采用图形表示关系。

下图的数据树表述了某个构建的一种信息层次，不带阴影的长方形表示简单或复合数据项，带阴影的长方形表示内容对象。在此图中，“描述说明”是由5个内容对象定义的。在某些情况下，随着数据的扩展，其中的一个或多个对象将会得到进一步细化。

 

由多项内容对象和数据项组成的任何内容都可以生成数据树。开发数据树尽力在内容对象中定义层级关系，并提供一种审核内容的方法，以便在开始设计前发现遗漏和不一致的内容。另外，数据可以作为内容设计的基础。

2.交互模型

交互模型描述了用户与 WebApp 采用了哪种交互方式。交互模型由一种或多种元素构成，包括用例、顺序图、状态图、用户界面原型等。

1. 用例是交互分析的主要工具，方便客户经理理解系统的功能。许多实例中，一套用例足够描述所有的交互活动。然而遇到复杂的交互时，更值得采用严格图解方式描述它们。
2. 顺序图是交互分析中描述用户与系统进行交互的方式。
3. 状态图是交互分析中对系统进行动态的描述。
4. 用户界面原型展现用户界面布局、内容、主要导航链接、实施的交互机制及用户 WebApp 的整体美观度。对用户的物理表示评估的越早，越有可能满足最终用户的需求。

3.功能模型

许多WebApp 提供大量的计算和操作功能，这些功能与内容直接相关。这些功能常以用户——WebApp 的交互活动为主要目标，由于这个原因，必须对功能需求进行分析。

功能模型描述 WebApp 的两个处理元素：

1. 用户可观察到的功能是由WebApp传递给最终用户的。
2. 分析类中的操作实现与类相关的行为。

用户可观察到的功能包括直接由用户启动的任何处理功能。这些功能实际上可能使用分析类中的操作完成，但是从最终用户的角度看，这些功能是可见的。

在抽象过程的更低层次，分析模型描述了由分析类操作执行的处理。这些操作可以操纵类的属性，并参与类之间的写作来完成所需要的行为。不管抽象过程的层次如何，UML活动图可以用来表示处理细节。在分析阶段，仅在功能相对复杂的地方才会使用活动图。许多 WebApp 的复杂性不是出现在提供的功能中，而是与可访问信息的性质以及操作的方式相关。

4.导航模型

导航模型为 WebApp 定义所有导航策略。导航模型考虑用户如何从一个 WebApp 元素导航到另一个元素。在这个阶段，分析人员应关注总体的导航需求，应考虑以下问题：

• 某些元素比其他元素更容易到达吗？表示的优先级是什么？
• 为促使用户以他们自己的方向导航，应该强调某些元素吗？
• 应该怎样处理导航错误？
• 导航到关键元素组的优先级应高于导航到某个特定元素的优先级吗？
• 应该通过链接方式、基于搜索的方式还是其他方式实现导航？
• 根据前面的导航行为，某些确定元素应该展现给用户吗？
• 应该为用户维护导航日志吗？
• 在用户交互的每一点处，一个完整的导航地图或菜单都可以吗？
• 导航设计应该由大多数普遍期望的用户行为来驱动，还是由自己定义的 WebApp 元素可感知的重要性来驱动？
• 为了促进将来使用快捷方式，一个用户能否存储他以前对 WebApp 的导航？
• 应该为哪类用户设计最佳导航？
• 应该如何处理 WebApp 的外部链接？应该覆盖现有的浏览器窗口吗？能否作为一个新的浏览器窗口，还是作为一个单独的框架？

5.配置模型

配置模型描述 WebApp 所在的环境和基础设施。

某些情况下，配置模型只不过是服务器端和客户端的属性列表。但是对于更复杂的 WebApp 来说，多种配置的复杂性（例如，多服务器直接的负载均衡、高速缓存的体系结构、远程数据库、同一页上服务于不同对象的多个服务器）可能对分析和设计产生影响。在必须考虑复杂配置系统结构的情况下，可以使用UML部署图。

6.4.3 WebApp 设计

好的 WebApp 应该具有最相关的通用特性是可用性、功能性、可靠性、效率、可维护性、安全性、可扩展性以及及时性。

1. 架构设计

   WebApp 描述了是 WebApp达到其业务目标的基础结构，典型使用多层架构来构造，包括用户界面或展示层、基于一组业务规则来指导与客户端浏览器进行信息交互的控制器、以及可以包含 WebApp 业务UI则的模型层，描述将以什么方式来管理用户交互、操作内部处理、实现导航及展示内容。模型-视图-控制器结构是 WebApp 基础结构模型之一，它将 WebApp 功能及信息内容分离。

2. 构件设计

   在 WebApp 功能和内容的界限通常并不清晰，因此首先明确 WebApp 构件：（1）定义良好的聚合功能，为最终用户处理内容、提供计算、处理数据；（2）内容和功能的聚合包，提供最终用户所需要的功能。因此 WebApp 构件设计通常包含 内容设计和功能设计元素。

   1. 构件级内容设计。关注内容对象，以及包装后展示给最终用户的方式，应该适合创建的 WebApp 特性。
   2. 构件级功能设计。

3. 内容设计

   WebApp 的内容结构（线性或非线性）也影响架构。内容体系结构着重于内容对象的表现和导航的组织，通常采用线性结构、网格结构、层次结构、网络结构四种机构及其组合。

4. 导航设计

   定义导航路径，使用户可以访问 WebApp 的内容和功能。当用户与WebApp进行交互时，会接触一些列导航语义单元。定义导航机制，如导航链接、水平或垂直导航条，标签或一个完整的站点地图入口。

6.5 用户界面设计

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

6.5.1 用户界面设计的黄金原则

1.用户操纵原则

1. 以不强迫用户的方式定义交互模式

2. 提供灵活的交互。

3. 允许中断和撤销用户交互。

4. 当技能级别增长时可以使交互流线化并允许定制交互。

   用户经常发现他们重复完成相同的交互序列。因此，值得设计一种“宏”机制，使得高级用户能够定制界面以方便交互。

5. 使用户与内部技术细节隔离开

6. 设计应允许用户与出现在屏幕上对象直接交互。

2.减轻用户记忆负担

1. 减少对短期记忆的要求
2. 建立有意义的默认
3. 定义直观的快捷方法
4. 界面的视觉布局应该基于真是世界的象征
5. 以不断进展的方式揭示信息

3.保持界面一致

1. 允许用户将当前任务放入有意义的环境中
2. 在应用系统家族内保持一致
3. 如果过去的交互已经建立起了用户期望，除非不得已的理由，否则不要改变它。

6.5.2 用户界面的分析与设计

1.用户界面分析和模型设计

1. 软件工程师所创建的设计模型。整个系统设计模型包括对软件的数据结构、体系结构、界面和过程的表示。界面设计往往是设计模型的附带结果。
2. 人机界面设计工程师创建的用户模型。用户模型描述最终系统用户的特点。
3. 最终用户在脑海里对界面产生的映像，称为用户的心理模型或系统感觉。系统感觉是最终用户的系统映像，描述了期望的系统能提供的操作，其描述的精确程度依赖于最终用户对软件的熟悉程度。
4. 系统实现者创建的系统映像。系统映像包括基于计算机的系统外在表示和用来描述系统语法和意义的支撑信息。如果系统映像和系统感觉是一致的，用户就会感觉软件很舒服，使用起来很有效。

2.用户界面分析和设计的过程

用户界面分析和设计的过程是迭代的，包括4个不同的框架活动：界面分析建模、界面设计、界面构造和界面确认。

6.5.3 用户界面设计问题

1. 系统响应时间

   系统响应时间指从用户开始执行动作到软件以预期的输出和动作形式给出响应这段时间。

   系统响应时间包括两方面的熟悉：时间长度和可变性。

2. 帮助设施

   考虑帮助设施时需要在设计中解决以下问题

   • 进行系统交互时是否在任何时候对任何系统功能都得到帮助？有两种选择：提供部分功能帮助与动作的帮助、提供全部功能的帮助。
   • 用户怎样请求帮助？有3种：帮助菜单、特殊功能键、HELP命令
   • 如何表达帮助？有3种：提供一个单独的帮助窗口、在另一个窗口中指示参考某个已印刷的文档、屏幕特殊位置给出一行或两行的简单提示。
   • 用户如何回到正常的交互模式？返回按钮、功能键、控制序列
   • 如何构造帮助信息？有3种：平面结构、分层结构、超文本的使用。

3. 错误信息

   错误信息应具备以下特征：

   1. 消息以用户可以理解的语言描述问题
   2. 消息应提供如何从错误中回复建设性的建议。
   3. 消息应只是初可能导致哪些不良后果，以便用户检查是否出现了这些情况。
   4. 消息伴随着视觉或听觉上的提示。
   5. 消息不应是裁判性的，即不能指责用户。

4. 菜单和命令标记

   在提供命令或菜单标签交互方式时，必须考虑以下问题：

   1. 每个菜单选择是否都有对应的命令？
   2. 以何种方式提供命令？ 控制序列（如Alt+P）、功能键、输入命令
   3. 学习和记忆命令的难度有多大？忘记命令了怎么办？
   4. 用户是否可以定制和缩写命令
   5. 在界面环境中菜单标签是不是自解释的
   6. 子菜单是否与主菜单所指的功能一致