第三章 结构化方法

结构化方法是一种思想；

可以用于定义需求；建立功能模型——结构化需求分析。

可以用于定义满足需求的结构；软件解决方案——结构化设计。

3.1 结构化需求分析

1.表达问题域信息的基本术语及其表示

（1）数据流：在结构化分析方法中，数据流是数据的流动，用于表达在分析中所要使用的、用于表达“客体”的信息。

（2）加工：在结构化分析方法中，加工是数据的变换单位，即它接受输入的数据，对其进行处理，并产生输出。

（3）数据存储：数据存储是数据的静态接口。

（4）数据源和数据潭：数据源是数据流的起点，数据潭是数据流的归宿地。数据源和数据潭是系统之外的实体，可以是人、物或其他软件。它们均用一个矩形表示。

2.表达功能模型的工具——DFD图（Data Flow Diagram） DFD图，即数据流图，是表达功能模型的工具。它是一种描述数据变换的图形化工具，其中包含的元素可以是数据流、数据存储、加工、数据源和数据潭等。

概念模型主要关注系统中的概念、实体、属性和它们之间的关系，用于描述系统的静态结构。概念模型通常以实体关系图、类图等形式表示，它能够帮助开发人员理解系统中的实体和它们之间的关系，从而设计系统的数据结构和数据流动。

功能模型则主要关注系统的功能和行为，用于描述系统的动态行为。功能模型通常以流程图、数据流图、状态转换图等形式表示，它描述了系统的输入、输出和数据流转过程，能够帮助开发人员理解系统的功能需求和交互逻辑。

虽然概念模型和功能模型在某种程度上都描述了系统，但它们关注的方面不同。概念模型描述了系统的实体和关系，帮助开发人员设计系统的数据结构；而功能模型描述了系统的功能和行为，帮助开发人员设计系统的功能和交互逻辑。两者在软件工程中扮演不同的角色，分别用于需求分析和系统设计阶段。

数据流：箭头表示。是由一组固定成分的数据组成，表示数据的流向。值得注意的是，数据流图中描述的是数据流，而不是控制流。除了流向数据存储或从数据存储流出的数据不必命名外，每个数据流必须要有一个合适的名字，以反映该数据流的含义。

加工：椭圆表示。加工描述了输入数据流到输出数据之间的变换，也就是输入数据流经过什么处理后变成了输出数据。每个加工都有一个名字和编号。编号能反映该加工位于分层的数据流图的哪个层次和哪张图中，能够看出它是由哪个加工分解出来的子加工。

数据存储：双下划线表示。数据存储表示暂时存储的数据。每个数据存储都有一个名字。一般都是数据库文件中的一个表。

数据源点终点（外部实体；也被称为数据源和数据潭）：矩形表示。外部实体是存在于软件系统之外的人员或组织，他指出数据所需要的发源地或系统所产生的数据的归属地。一般只出现在数据流图的顶层图。

3.数据字典、判定表和判定树

（1）在数据字典中，为了使定义的结构数据便于理解和阅读，一般按三种条目来组织，即数据流条目、数据存储数目和数据条目。

数据字典是一个用于描述系统中数据流、数据存储和数据加工的详细说明文档或表格。它提供了对数据流、数据存储和数据加工的定义、属性和描述。

（2）判定表：判定表是用以描述加工的一种工具，通常用来描述一些不易用自然语言表达清楚或需要很大篇幅才能表示清楚的加工。

（3）判定树：判定树也是一种描述加工的工具，判定表可以用判定树等价表示。

4.结构化分析方法中每一术语在建模中的作用

（1）数据流用于表达在分析中所要使用的、用于表达“客体”的信息。

（2）加工用于表达在分析中所要使用、用于表达“处理”的信息。

（3）数据存储用于表达在分析中所要使用的、用于表达“结构化客体”的信息。

（4）数据源和数据潭为了表示系统的环境，可以使用它们和相关数据流来定义系统的边界。

5.构建系统功能模型的步骤

（1）建立系统环境图，确定系统语境。

（2）自顶向下，逐步求精，建立系统的层次数据流图。

（3）定义数据流。

（4）描述加工。

6.需求验证中发现的错误类型及方法

（1）需求验证中发现的错误类型有不正确的事实、遗漏、不一致、歧义性、错放及其他。

（2）需求验证中发现错误的方法有审查、单元测试、评估、集成和其他。

每个需求的5个性质：必要性/无歧义性/可跟踪性/可测性/可测量性。

需求规格说明书的4个性质：重要性和稳定程度、可修改性、完整性、一致性。

3.2 结构化设计

3.2.1 总体设计

目的：将DFD图映射为设计层面的模块及模块调用。

结构设计的结果通常用模块结构图表达。

首先将系统的DFD图转换为初始的模块结构图，再基于“高内聚低耦合”这一软件原理，通过模块化，将初始的模块结构图转换为最终的、可详细设计使用的模块结构图（MSD）。

结构图(Structure Chart)

是对软件总体结构的一种图形描述，它显示了软件的层次结构、 组织和通讯。也就是说，在结构图中，显示了软件是由哪些模块组成的，这些模块按照什么样 的层次结构组织在一起以及模块之间通过什么接口联系在一起。结构图也称之为控制结构图、 模块结构图或系统结构图。

①模块符号

② 模块调用关系

③ 模块间的数据传递

④ 模块间的控制信息传递

⑤ 循环调用结构

⑥ 选择调用结构

⑦ 数据存

层次图：（H图）

层次图中一个矩形框代表一个模块，框间的连线表示调用关系（位于上方的矩形框所代表 的模块调用位于下方的矩形框所代表的模块）。

HIPO图：

HIPO图是美国IBM公司发明的“层次图加输入/处理/输出图”的英文缩写。为了使HIPO图 具有可追踪性，在H图(即层次图)里除了顶层的方框之外，每个方框都加了编号。 H图+IPO图。

1.变换型数据流图和事务型数据流图

（1）变换型数据流图：具有较明显的输入部分，和变换部分之间的界面、变换部分和输出部分之间界面的数据流图，称为变换型数据流图。（线性结构）

（2）事务型数据流图：数据到达一个加工T，该加工T根据输入数据的值，在其后的若干动作序列中选出一个来执行，这类数据流图称为事务型数据流图。（分支结构）

2.模块以及模块内聚和耦合

（1）模块。模块是执行一个特殊任务的一个过程你以及相关的数据结构，通常有两个部分组成，一部分是接口，另一部分是模块体。

（2）模块内聚。内聚是指一个模块内部各成分之间相互关联程度的。从低到高常见的内聚类型有：偶然内聚、逻辑内聚、时间内聚、过程内聚、通信内聚、顺序内聚、功能内聚。

（3）模块耦合。耦合是指不同模块之间相互依赖程度的量。从强到弱常见的耦合类型有：内容耦合、公共耦合、控制耦合、标记耦合、数据耦合。

3.2.2 详细设计

3.详细设计工具：框图、PAD图、N-S图和伪码 （1）框图。程序流程图又称框图，是软件设计的主要工具，是历史最悠久，使用最广泛的软件设计工具。采用“顺序”“选择”和“循环”三种结构

三种基本的控制结构：（顺序、选择、重复）

• 顺序结构，先执行 A 再执行 B；
• IF-THEN-ELSE 型选择(分支)结构；
• DO-WHILE 型循环结构

（2）PAD图。是问题分析图的缩写。

（3）N-S图。N-S图又称为盒图。

（4）伪码（PDL）。类程序设计语言也成为伪码，它是一种正文形式表示数据结构和处理过程的设计工具。PDL是一种“混合”语言。

伪代码是一种介于自然语言和形式化语言之间的半形式化语言，是一种用于描述功能模块的算法设计和加工细节的语言，也称为程序设计语言（Program Design Language，PDL）

伪代码的基本控制结构:

简单陈述句结构：避免复合语句。

判定结构：IF_THEN_ELSE或CASE_OF结构。

重复结构：WHILE_DO或REPEAT_UNTIL结构

4.变换设计和事务设计

（1）变换设计。变换设计是在需求规约的基础上，经过一系列设计步骤，将变换型数据流图转换成系统的模块结构图。

基本步骤是：

·设计准备——复审并精化系统模型；

·确定输入、交换、输出这三部分之间的边界；

·第一级分解——系统模块结构图顶层和第一层的设计；

·第二级分解——自顶向下，逐步求精。

（2）事务设计。当数据流图具有明显的事务型特征时，也就是有一个明显的事务处理中心时，则比较适宜采用事务设计。

事务设计的基本步骤和变换设计大体相同：

·设计准备——复审并精化系统模型；

·确定事务处理中心；

·第一级分解——系统模块结构图顶层和第一层设计；

·第二级分解——自顶向下，逐步求精。

5.内聚

定义：一个模块之内各成分之间相互依赖程度的度量 好的设计满足：模块功能单一，模块各部分都和模块功能直接相关，高内聚 内聚类型

• 偶然内聚：一个模块之内各成分之间没有任何关系
• 逻辑内聚：几个逻辑上相关的功能放在统一模块中
• 时间内聚：一个模块完成的功能必须在同一时间内完成，而这些功能只是因为时间因素关联在一起
• 过程内聚：处理成分必须以特定的次序执行
• 通信内聚：各成分都操作在同一数据集或生成同一数据集
• 顺序内聚：各成分与一个功能相关，且一个成分的输出作为另一个成分的输入
• 功能内聚：模块所有成分对完成单一功能是最基本的，且该模块对完成这一功能而言是充分必要的

6.耦合 定义：不同模块之间相互依赖程度的度量

耦合强度所依赖的因素：

• 一个模块对另一个模块对引用
• 一个模块向另一个模块传递的数据量
• 一个模块施加到另一个模块的控制的数量
• 模块之间接口的复杂程度

耦合类型（由强到弱）

• 内容耦合：一个模块直接修改或操作另一个模块的数据
• 公共耦合：两个以上的模块共同应用一个全局数据项
• 控制耦合：一个模块向另一模块传递一个控制信号，接受信号的模块执行相应的活动
• 标记耦合：两个模块至少有一个通过界面传递的公共参数，包含内部结构，如数组，字符串等
• 数据耦合：模块之间通过参数传递基本类型的数据

7.“高内聚低耦合”的启发式规则

（1）改进软件结构，提高模块独立性。

（2）力求模块规模适中。

（3）力求深度、宽度、扇入、扇出适中。

（4）尽力使模块的作用域在其控制域之内。

（5）尽力降低模块接口的复杂度。

（6）力求模块功能可以预测。

控制域：模块本身以及所有直接或间接从属于它的模块的集合。

作用域：受该模块内的一个判定所影响的所有模块的影响

8.概要设计规约指明的高层软件体系结构

（1）系统环境，包括硬件/软件接口、人机界面、外部定义的数据库及其与设计有关的限定条件等。

（2）软件模块的结构，包括模块之间的接口及设计的数据库和主要数据结构等。

（3）模块描述，包括模块接口定义、模块处理逻辑及必要的注释等。

（4）文件结构和全局数据文件的逻辑结构，包括记录描述、访问方式以及交叉引用等。

（5）测试需求等。

第四章 面向对象方法－UML

在我们开始研究 UML 的理论之前，我们将简单介绍一下 UML 的一些主要概念。

首先要注意的是 UML 涉及很多不同的图表（模型），其原因是提供从许多不同的角度来審視系统。软件开发流程往往有许多持分者参与其中，例如：

• 分析师
• 设计师
• 程序员
• 测试员
• 质量保证员
• 客户
• 技术文件撰稿员

这些人都对系统的不同方面各持不同兴趣，故此在建模时需要考虑不同的细节层次。例如，程序员需要了解系统的设计，并将设计转换为代码，而技术文件撰稿员则对整个系统的行为感兴趣，借以了解产品的功能。UML 提供了极富表达能力的建模语言，好让各持分者至少可以从一个 UML 图表得到感兴趣的资讯。

4.1 UML术语表

4.1.1 UML术语表

为了支持抽象分析和设计中的事物，UML给出了八个基本术语即：

• 类
• 接口
• 协作
• 用况
• 主动类
• 构件
• 制品
• 节点

每个术语都体现着一定的软件设计原理，例如：

类体现了数据抽象、过程抽象、局部化以及信息隐蔽等原理；

用况体现了问题分离、功能抽象等原理；

接口体现了功能抽象等。

4.1.2 类、接口、用况、协作等概念

(1)类：类是一组具有相同属性、操作、关系和语义的对象的描述。类主要用于抽象客观世界中的事物；

(2)接口：每个操作描述了类、构件或子系统的一个服务，接口就是操作的一个集合。接口是对系统/产品的 “ 接缝 ” 予以模型化，表明了一个类、构件、子系统所需要得到的、且与实现无关的行为；

(3)用况：用况是对一组动作序列的描述，系统执行这些动作应产生对特定参与者有值的、可观察的结果；

(4)协作：协作是一个交互，涉及交互的三要素：交互各方、交互方式以及交内容。

可见性使用+、#、－和~分别表示public、protected、private和同包内可见。

用况与协作：

"用况"（Use Case）和"协作"（Collaboration）是软件开发中的两个重要概念，它们有不同的含义和用途：

1. 用况（Use Case）：

• 用况是一种用于描述系统或软件系统如何满足特定用户或系统的需求的技术。它是一种功能性需求文档，用于捕捉系统与外部参与者之间的交互，以及系统对这些交互的响应。
• 用况通常包括了参与者（Actors）、用例（Use Cases）和场景（Scenarios）的描述。参与者是系统的外部角色或实体，用例是描述系统功能的文档，场景则是具体的交互情境，描述了参与者如何与系统交互以实现某个特定目标。
• 用况模型是用于定义系统功能和用户需求的一种方法，有助于开发团队更好地理解系统的行为，指导系统设计，以及验证系统是否满足用户期望。

2. 协作（Collaboration）：

• 协作是一种软件建模技术，用于描述多个对象或类之间的交互关系和协作方式。它通常用于面向对象的分析和设计中，帮助设计师理清对象之间的通信和合作。
• 在协作图中，对象或类被表示为图中的元素，它们之间的交互通过消息传递来表示。消息可以表示方法调用、数据传输等对象之间的通信方式。
• 协作图有助于可视化和描述系统中对象之间的协作和通信模式，它们通常用于系统设计的过程中，以便更好地理解系统的结构和交互。

区别：

• 主要区别在于它们的关注点和用途。用况主要关注系统的功能性需求和用户需求，用于描述系统的功能和用户如何与系统交互。而协作主要关注对象或类之间的协作和通信方式，用于描述系统的结构和对象之间的交互关系。
• 用况通常用于需求分析阶段，帮助捕捉用户需求和功能需求，而协作通常在系统设计阶段用于设计对象之间的协作和通信。
• 用况图和协作图是两种不同类型的图表，用况图是用于表示用况模型的图表，而协作图是用于表示对象之间的协作的图表。

4.1.3 UML的4种关系术语

为了表达各类事物之间的相互依赖和作用，UML给出了4种关系术语，即关联、泛化、细化和依赖； (1)关联：关联是对一组有相同结构、相同链的描述，是类目之间的一种结构关系。关联可以用一条连接两个类目的线段表示，并可对其命名，其结构可以具有（也可以不具有）方向性,若有方向则用一个实心三角形来指示关联的方向； (2)泛化：泛化是一般性类目和它的较为特殊类目之间的一种关系。子类可以继承父类的属性和操作，同时，也可以替换父类的声明； (3)细化：细化是类目之间的语义关系，其中一个类目规约了保证另一个类目执行的契约；可以理解为实现关系。 (4)依赖：依赖用于描述一个类目使用另一个类目的信息和服务，是一种使用关系。

聚合与组合

• 【聚合关系】：是一种整体与部分的关系。且部分可以离开整体而单独存在。聚合关系是关联关系的一种，是强的关联关系；关联和聚合在语法上无法区分，必须考察具体的逻辑关系。
• 【组合关系】：是一种整体与部分的关系。但部分不能离开整体而单独存在，组合关系是关联关系的一种，是比聚合关系还要强的关系。

4.1.4 表达组合信息的术语

为了控制信息组织的复杂性，UML提供了组织信息的一种通用机制——包，支持形成一些可管理的部分。换言之，包可以作为“模块化“和“构件化“的一种机制。为了模型化包之间的关系，UML给出了两种依赖，即：

1. 访问
2. 引入

用于描述一个包可以访问和引入其他包。

4.1.5 UML术语的作用

(1). 类用于抽象客观事物。

(2). 接口用于抽象事物之间的缝隙。

(3). 协作用于抽象协作性行为。

(4). 用况用于抽象功能。

(5). 主动类用于抽象并发行为。

(6). 构件用于抽象软件解中可标识的成分。

(7). 制品用于抽象工作产品。

(8). 节点用于抽象计算单元。

(9). 关联用于抽象结构关系。

(10). 泛化用于抽象“一般/特殊”关系。

(11). 实现用于抽象精化关系。

(12). 依赖用于抽象使用关系。

4.1.6 类在建模中的主要用途

(1)模型化问题域中的概念。

(2)建立系统的职责分布模型。

(3)模型化建模中使用的基本类型。

4.1.7 使用接口应注意的问题

在建立系统模型中，若使用接口对系统中那些“接缝”进行模型化时，应注意以下问题。

(1)接口只可以被其他类目使用，而其本身不能访问其他类目。

(2)接口描述类的外部可见操作，通常是该类的一个特定有限行为。这些操作可以使用可见性、并发性、衍型、标记值和约束来修饰。

(3)接口不描述其中操作的实现，也没有属性和状态。据此可见,接口在形式上等价于一个没有属性、没有方法而只有抽象操作的抽象类。

(4)接口之间没有关联、泛化、实现和依赖，但可以参与泛化、实现和依赖。

4.2 UML的模型表达式

4.2.1 结构图和行为图

UML的图形化工具分为两类：

一类是结构图，用于表达系统或系统成分的静态结构模型，给出系统或系统成分的一些说明性信息；

另一类是行为图，用于表达系统或系统成分的动态结构模型，给出系统或系统成分的一些行为信息。

网上找到的一张图画的很好：

4.2.2 类图、用况图、顺序图及状态图

https://www.visual-paradigm.com/cn/guide/uml-unified-modeling-language/what-is-uml/#class-diagram

(1)类图是可视化地表达系统静态结构功能模型的工具，使用类图所表达的系统静态结构模型，给出的是一些关于系统的说明性信息。

(2)用况图是一种表达系统功能模型的图形化工具，它包含六个模型元素，分别是主题、用况、参与者、关联、泛化、依赖。

(3)顺序图由一组对象以及按时序组织的对象之间的关系组成，是一种交互图，包含对象之间传递的信息。 为了控制交互行为描述的复杂性，以便更好地表达顺序图的复杂控制，UML定义了四种常见的控制操作：选择执行操作、条件操作、并发迭代操作和迭代执行操作。

(4)状态图强调了从一个状态到另一个状态的控制流，是显示一个状态机的图。状态图由状态、事件和状态转移构成。使用状态图的作用有两个：一是创建一个系统的动态模型：二是创建一个场景的模型。

类图：

用况图：

状态图：

4.2.3 创建一个系统的类图的步骤

(1)模型化待建系统中的概念，形成类图中的基本元素。 使用UML中的术语“类”，来抽象系统中的各个组成部分，包括系统环境。继而确定每类的职责，最终形成类图中的模型元素。

(2)模型化待建系统中的各种关系，形成该系统的初始类图。 使用UML中表达关系的术语，例如关联、泛化等，来抽象系统中各成分之间的关系，形成该系统的初始类图。

(3)模型化系统中的协作,给出该系统的最终类图。 在研究系统中以类表达的某一事物语义的基础上，使用类和UML中表达关系的术语，模型化一些类之间的协作，并使用有关增强语义的术语，给出该模型的详细描述。

(4)模型化逻辑数据库模式。 对要在数据库中存储的信息，以类作为工具，模型化系统所需要的数据库模式，建立数据库概念模型。

4.2.4 信号事件、调用事件、时间事件和变化事件

在UML中，可以把信号、调用、时间、变化模型化为事件，分别称为信号事件，调用事件、时间事件和变化事件。

(1)信号事件是一种异步事件，信号通常由状态机处理。如果没有定义对该事件的响应，那么事件均可能丢失。事件的丢失，就有可能引发接收者—状态机的一个错误的状态转移。

(2)调用事件往往是一个同步事件，即发送者和接收者多处在该操作执行期间的一个汇合点上，发送者的控制流一直被挂起，直到该操作执行完成。但可以把调用规约为异步调用。

(3)时间事件是表示推移一段时间的事件。时间事件是通过时间表达式来规约的。

(4)变化事件表示状态的一个变化，或表示某一条件得到满足。

4.2.5 状态转换所涉及的内容

描述一个状态转换，一般涉及五个部分。

(1)源状态：发生状态转移的那个状态。

(2)转移触发器：在源状态中由对象识别的事件，并且一旦满足其监护条件，则使状态发生转移。

(3)监护条件：一个布尔表达式，当某个事件触发器接收一个事件时，如果该表达式有值为真，则触发一个转移;若有值为假，则不发生状态转移。

(4)效应：一种可执行的行为。

(5)目标状态：转移完成后所处的状态。

4.2.6 最常用的控制操作

(1)选择执行操作。该操作由两部分组成：一是监护条件，二是控制体。

(2)条件执行操作。控制体通过水平线将其分为一些部分，每一部分表示一个条件分支，每一分支有一个监护条件。

(3)并发执行操作。该控制操作子的体通过水平线将其分为多个部分，每一部分表示一个并行计算。该控制操作子表明，当进入该控制操作时，所有部分并发执行。

(4)选代执行操作。该控制操作表明，只要在每一次选代之前该监护条件为真，那么该控制体就反复执行；当该控制体上面的监护条件为假时，控制绕过该控制操作。

4.2.7 子状态机、简单状态和组合状态的概念

(1)子状态机：为了有效地组织状态、控制对象状态的复杂性，UML提供了组合状态，在一个状态机中引入了另一个状态机，被引入的状态机就称为子状态机

(2)简单状态：子状态是被嵌套到另一状态中的状态。相对地,把没有子状态的状态称为简单状态。

(3)组合状态：把含子状态的状态称为组合状态，组合状态可包含两种类型的子状态机，即非正交(顺序)子状态机和正交(并发)子状态机。

其实，关于UML的各种图的作用及画法，很多优秀的博主已经提供了很好的文章进行说明；我这里推荐：

https://juejin.cn/post/7097869959476297741

进行进一步的了解。

本人能力有限，文中内容难免有纰漏，真诚欢迎大家斧正~

喜欢本文的朋友请三连哦！！！

另外本文也参考了网络上其他优秀博主的观点和实例，这里虽不能一一列举但内心属实感谢无私分享知识的每一位原创作者。