软件工程 第五章
合集下载
软件工程概述-第5章 结构化需求分析
实体 属性 联系
用矩形表示，矩形内写 明实体名
用椭圆形表示，并用无 向边将其与对应实体连 接起来
用菱形表示，并用无向 边分别与有关实体连接 起来，同时在无向边旁 标上联系的类型。
E-R 图表示图示 例 2-1 中的例子
练习
例：简单的学生选课系统：
(1)学生 属性有学号，姓名， 性别，年龄，所在系
x
1.1
1.2
1.3
1
3
2
2.1 2.3
2.2
1.1 1.3
目录
1
5.1结构化分析
2
5.2数据流图
3
5.3数据字典
4
5.4 实体关系图
5
5.5 状态转换图
数据流图
数据流图（Data Flow Diagram，DFD）是描述系统中数据 流程的图形工具，它描述了将系统的逻辑输入转换为逻辑输出 所需的加工处理过程。
(2)课程 属性有课程号，课程 名称，先修课程号，学分
实体之间的联系：
一个学生可同时选修多门 课程，而一门课程可以同时被 若干学生选修。用成绩来表示 某个学生学习某门课程的成绩 。
分解：对于一个复杂的系统，为了将复杂性降 低到可以掌握的程度，可以把大问题分解成若 干小问题，然后分别解决。
抽象：分解可以分层进行，即先考虑问题最本 质的属性，暂把细节略去,以后再逐层添加细 节，直至涉及到最详细的内容，这种用最本质 的属性表示一个系统的方法就是“抽象”
结构化分析
结构化分析方法基本思想 “分解”和“抽象”
取值范围：数据项的取值范围，例如，职工年龄 的取值范围定义为18至60岁，表示为18..60。
初始值：数据项的初始值，例如，为了操作简便， 软件定义借书日期的初始值默认为系统的当前日 期。
软件工程课件 第5章_
盒图N 盒图N-S图
• N-S图也叫做盒图 。 五种基本控 图也叫做盒图。 图也叫做盒图 制结构由五种图形构件表示。 制结构由五种图形构件表示。
示例
N-S图的嵌套定义形式
5.2.3 问题分析图(PAD) 问题分析图(PAD)
• PAD图是日本日立公司于 图是日本日立公司于1979年提出的一种算法 图是日本日立公司于 年提出的一种算法 描述工具， 描述工具 ， 它是一种由左往右展开的二维树型结 图的控制流程为自上而下， 构 。 PAD图的控制流程为自上而下 ， 从左往右地 图的控制流程为自上而下 执行。优点： 执行。优点： • 清晰地反映了程序的层次结构。 清晰地反映了程序的层次结构。 • 支持逐步求精的设计方法 ， 左边层次中的内容可 支持逐步求精的设计方法， 以抽象，然后由左到右逐步细化。 以抽象，然后由左到右逐步细化。 • 易读易写，使用方便。 易读易写，使用方便。 • 支持结构化的程序设计原理。 支持结构化的程序设计原理。 • 可自动生成程序。 可自动生成程序。
5.2.6过程设计语言（Process Design 过程设计语言（ 过程设计语言 Language ,PDL） ）
• 也称程序描述语言 （ Program Description 也称程序描述语言（ Language ,PDL ） , 又 称 为 伪 码 （ pseudo code）。属于文字形式的表达工具。它并非 ） 属于文字形式的表达工具。 真正的代码，也不能在计算机上执行， 真正的代码，也不能在计算机上执行，但形 式上与代码相似。 式上与代码相似。它是一种用于描述模块算 法设计和处理细节的语言。 法设计和处理细节的语言。PDL具有严格的 具有严格的 关键字外层语法，用于定义控制结构、 关键字外层语法，用于定义控制结构、数据 结构和模块接口， 结构和模块接口，而它表示实际操作和条件 的内层语法又是灵活自由的， 的内层语法又是灵活自由的，使用自然语言 的词汇。 的词汇。
软件工程 第5章--RUP统一开发过程
10
(3) 制品（Artifact）
制品是过程生产、修改或使用的一种信息。制 品可分为输入制品和输出制品。
在面向对象设计中，制品被当作活动的参数。 制品有多种可能的形式，如：
模型 : 如用例模型或设计模型； 模型元素 : 如类、用例或子系统； 文档 : 如一个业务用例或体系结构文档； 源代码； 可执行文件。
13
a) 核心工作流
在 RUP 中共有 9 个核心过程工作流。它们将 所有工作人员和活动进行逻辑分组。
核心过程工作流分为 6 个核心工程工作流和 3 个核心支持工作流。
核心工程工作流有：业务建模工作流、需求 工作流、分析和设计工作流、实现工作流、 测试工作流、实施工作流。
核心支持工作流有：项目管理工作流、配置 和变更管理工作流、环境工作流。
11
Iteration Plan Storyboard
Use Case Model Project Measurements User-Interface Prototype
Developer Test
Iteration Assessment
Business Goal Test Environment Configuration
场景的系统大致轮廓； 估计整个项目需要的成本和时间； 评估风险，即分析不确定性的原因；
31
制品
a) 构想文档：有关项目核心需求、关键特 性和主要限制的构想。
b) 用例模型调查：包括所有在此阶段可确 定的用例和参与者。
c) 初期的项目术语。 d) 初始的业务用例：包括业务环境、是否
成功的评价标准、经济预测。 e) 早期的风险评估。 f) 项目计划：表明阶段和迭代。
内部发布 小里程碑
第1个外部发布 （如Beta版本）
(3) 制品（Artifact）
制品是过程生产、修改或使用的一种信息。制 品可分为输入制品和输出制品。
在面向对象设计中，制品被当作活动的参数。 制品有多种可能的形式，如：
模型 : 如用例模型或设计模型； 模型元素 : 如类、用例或子系统； 文档 : 如一个业务用例或体系结构文档； 源代码； 可执行文件。
13
a) 核心工作流
在 RUP 中共有 9 个核心过程工作流。它们将 所有工作人员和活动进行逻辑分组。
核心过程工作流分为 6 个核心工程工作流和 3 个核心支持工作流。
核心工程工作流有：业务建模工作流、需求 工作流、分析和设计工作流、实现工作流、 测试工作流、实施工作流。
核心支持工作流有：项目管理工作流、配置 和变更管理工作流、环境工作流。
11
Iteration Plan Storyboard
Use Case Model Project Measurements User-Interface Prototype
Developer Test
Iteration Assessment
Business Goal Test Environment Configuration
场景的系统大致轮廓； 估计整个项目需要的成本和时间； 评估风险，即分析不确定性的原因；
31
制品
a) 构想文档：有关项目核心需求、关键特 性和主要限制的构想。
b) 用例模型调查：包括所有在此阶段可确 定的用例和参与者。
c) 初期的项目术语。 d) 初始的业务用例：包括业务环境、是否
成功的评价标准、经济预测。 e) 早期的风险评估。 f) 项目计划：表明阶段和迭代。
内部发布 小里程碑
第1个外部发布 （如Beta版本）
软件工程第五章
5.2.1、结构化程序设计技术
1. 结构化设计技术的形成
－－对“取消GOTO 语句”的争论 －－只用“顺序”、“选择”和“循环”三 种基本控制结构就能实现任何单入口单出 口的程序设计 －－程序应该只有一个入口和一个出口；自 顶向下，逐步求精
5.2.1、结构化程序设计技术
2. 结构化设计技术的概念 经典定义：“如果一个程序的代码仅仅通 过顺序、选择和循环这三种基本控制结构 进行连接，并且每个代码块只有一个入口 和一个出口，则称这个程序为结构化的。”
1. 模块的逻辑结构设计 逻辑结构设计是结合所开发项目的具体要 求和对每个模块规定的功能，开发出模块 处理的详细算法，选择某种适当的工具加 以精确描述。
5.1.1、详细设计的任务
详细设计阶段的主要任务：
2. 模块的数据设计 为在需求分析阶段的数据对象定义逻辑数 据结构，并且对不同的逻辑数据结构进行 不同的算法设计，选择最有效的方案。同 时，确定实现逻辑数据结构所必需的操作 模块，以便了解数据结构的影响范围。
第五章
详细设计
详细设计
教学提示：
上一章学习了概要设计的有关知识，本章将 介绍详细设计的内容。主要包括详细设计的 任务与原则、设计方法以及详细设计规格说 明及评审等。
详细设计
教学目标：
理解详细设计的设计任务和设计原则。掌握 详细设计的方法和常用工具的使用，了解详 细的设计规格说明书的内容和评审。
5.2.1、结构化程序设计技术
5.2.1、结构化程序设计技术
2. 结构化设计技术的概念 当前结构化程序设计的基本内容如下： (1) 程序的控制结构一般采用顺序、选择、循环3 种结构来构成，确保结构简单。 (2) 使用单入口单出口的控制结构。 (3) 程序设计中应尽量少用GOTO 语句，以确保 程序结构的独立性。 (4) 采用自顶向下逐步求精方法完成算法设计。
软件工程 第五章(总结和课后习题)
第五章 RUP
出：分析类[完成]；4、对包进行分析： 输入：系统体系结构描述[分析]、分析 包[概述]输出：分析类[完成]。 � （18）创建系统的分析模型，一般应进 行体系结构分析、用况分析、类的分析 以及包的分析 4 项活动。 � （19）用况分析[分析]的目标：1、标识 那些在用况事件流执行中所需要的分析 类和对象；2、将用况的行为，分布到参 与交互的各个分析对象；3、捕获用况细 化上的特定需求。 � （20）用况分析[分析]开展的活动包括： 1、标识分析类，标识在细化一个用况中 所需要的实体类、控制类和边界类，给 出它们的名字、责任、属性和关系；2、 描述分析（类）对象之间的交互，通常 使用交互图来描述。 � （21）类的分析[分析]的目标：1、标识 并维护分析类的责任；2、基于它们在用 况细化中的角色，标识并维护分析类的 属性和关系；3、捕获分析类细化中的特 定需求。 � （22）类的分析[分析] 开展的活动包 括：1、标识责任；2、标识属性；3 标识 关联与聚合； � （23）需求分析模型对以后开发工作的 影响？1、对设计中子系统的影响。分析 包一般将影响设计子系统的结构；2、对 设计类的影响。分析包可以作为类设计 时的规格说明；3、对用况细化[设计]的 影响。用况细分[分析]对用况细化[设计] 有两方面影响，一个是它们有乃至于为 用况创建更精确的规格说明，另一个是 当对用况进行设计时，用况细化[分析] 可作为其输入。 （24）需求获取模型与需求分析模型之
第五章 RUP
[概述];输出：子系统[完成]、接口[完 成]。 � （29）用况的设计包括以下任务：1、标 识参与用况细化的设计类；2、标识参与 用况细化的子系统的接口。 � （30）类的设计包括以下任务：1、概括 描述设计类；2、标识操作；3、标识属 性；4、标识关联、聚合；5、标识泛化； 6、描述方法； � � � （31）RUP 设计的突出优点：P165 页 （32）RUP 的设计系统生成构件；对构件进行测试，进行 集成测试和连接；把可执行的构件映射 到部署模型。 � （34）RUP 实现包括以下活动：1、实现 模型；2、实现子系统；3、实现模型视 角下的体系结构描述；4、实现类； � � （35）RUP 测试包括内部测试、中间测试 和最终测试。 （36）RUP 测试的主要活动：1、计划测 试；2、设计测试；3、实现测试；4、执 行集成测试；5、执行系统测试；6、评 价测试。
出：分析类[完成]；4、对包进行分析： 输入：系统体系结构描述[分析]、分析 包[概述]输出：分析类[完成]。 � （18）创建系统的分析模型，一般应进 行体系结构分析、用况分析、类的分析 以及包的分析 4 项活动。 � （19）用况分析[分析]的目标：1、标识 那些在用况事件流执行中所需要的分析 类和对象；2、将用况的行为，分布到参 与交互的各个分析对象；3、捕获用况细 化上的特定需求。 � （20）用况分析[分析]开展的活动包括： 1、标识分析类，标识在细化一个用况中 所需要的实体类、控制类和边界类，给 出它们的名字、责任、属性和关系；2、 描述分析（类）对象之间的交互，通常 使用交互图来描述。 � （21）类的分析[分析]的目标：1、标识 并维护分析类的责任；2、基于它们在用 况细化中的角色，标识并维护分析类的 属性和关系；3、捕获分析类细化中的特 定需求。 � （22）类的分析[分析] 开展的活动包 括：1、标识责任；2、标识属性；3 标识 关联与聚合； � （23）需求分析模型对以后开发工作的 影响？1、对设计中子系统的影响。分析 包一般将影响设计子系统的结构；2、对 设计类的影响。分析包可以作为类设计 时的规格说明；3、对用况细化[设计]的 影响。用况细分[分析]对用况细化[设计] 有两方面影响，一个是它们有乃至于为 用况创建更精确的规格说明，另一个是 当对用况进行设计时，用况细化[分析] 可作为其输入。 （24）需求获取模型与需求分析模型之
第五章 RUP
[概述];输出：子系统[完成]、接口[完 成]。 � （29）用况的设计包括以下任务：1、标 识参与用况细化的设计类；2、标识参与 用况细化的子系统的接口。 � （30）类的设计包括以下任务：1、概括 描述设计类；2、标识操作；3、标识属 性；4、标识关联、聚合；5、标识泛化； 6、描述方法； � � � （31）RUP 设计的突出优点：P165 页 （32）RUP 的设计系统生成构件；对构件进行测试，进行 集成测试和连接；把可执行的构件映射 到部署模型。 � （34）RUP 实现包括以下活动：1、实现 模型；2、实现子系统；3、实现模型视 角下的体系结构描述；4、实现类； � � （35）RUP 测试包括内部测试、中间测试 和最终测试。 （36）RUP 测试的主要活动：1、计划测 试；2、设计测试；3、实现测试；4、执 行集成测试；5、执行系统测试；6、评 价测试。
课件：软件工程--05指令系统
5. 输入输出
入
端口地址
CPU 的寄存器
如 IN AL, n IN AX, n IN AL, DX IN AX, DX
出 CPU 的寄存器
端口地址
如 OUT n, AL OUT n, AX OUT DX, AL OUT DX, AX
五、操作码编码
操作码的编码有两种方式 - Fixed Length Opcodes (定长操作码法) - Expanding Opcodes (扩展操作码编法)
ADD D + ( N -1 ) DIV # N STA ANS 共 N + 2 条指令
LDA # 0 LDX # 0 M ADD X, D INX CPX # N BNE M DIV # N STA ANS 共 8 条指令
X 为变址寄存器 D 为形式地址 (X) +1 X (X) 和 #N 比较 结果不为零则转
10. 堆栈寻址
(1) 堆栈的特点 硬堆栈
堆栈 软堆栈
多个寄存器 指定的存储空间
先进后出（一个入出口） 栈顶地址 由 SP 指出
进栈 （SP）– 1 SP 出栈 （SP）+ 1 SP
SP
1FFFH 2000 H
12F0F0F0 H
–1
进栈
栈顶 栈顶
SP
1FFFH 2000 H
12F0F00F HH
无条件转移；……
二、操作数类型
地址
无符号整数
数字 定点数、浮点数、十进制数 位、位串、字符和字符串 ASCII 逻辑数 逻辑运算
三、寻址方式
确定 本条指令 的 操作数地址
数据寻址
下一条 欲执行 指令 的 指令地址 指令寻址 • 指令的寻址——简单
(完整版)软件工程 第五章 面向对象的需求分析
第五章面向对象的需求分析面向对象的需求分析方法的核心是利用面向对象的概念和方法为软件需求建造模型。
它包含面向对象风格的图形语言机制和用于指导需求分析的面向对象方法学。
面向对象的思想最初起源于 20世纪 60年代中期的仿真程序设计语言Simula67。
20世纪80年代初出现的Smalltalk 语言及其程序设计环境对面向对象技术的推广应用起到了显著的促进作用。
20世纪90年代中后期诞生并迅速成熟的UML（Unified Modeling Language，统一建模语言）是面向对象技术发展的一个重要里程碑。
UML 统一了面向对象建模的基本概念、术语和表示方法，不仅为面向对象的软件开发过程提供了丰富的表达手段，而且也为软件开发人员提供了互相交流、分享经验的共用语言。
本章首先介绍面向对象的主要概念和思想。
在概述了UML的全貌之后，以“家庭保安系统”为实例，介绍与需求分析相关的部分 UML语言机制以及基于UML的面向对象的需求分析方法和过程。
第一节面向对象的概念与思想一、面向对象的概念关于“面向对象”，有许多不同的看法。
Coad和 Yourdon给出了一个定义：“面向对象 = 对象 + 类 + 继承 + 消息通信”。
如果一个软件系统是使用这样4个概念设计和实现的，则认为这个软件系统是面向对象的。
一个面向对象的程序的每一成分应是对象，计算是通过新的对象的建立和对象之间的消息通信来执行的。
1.对象（object）一般意义来讲，对象是现实世界中存在的一个事物。
可以是物理的，如一个家具或桌子，如图 5-1-1所示，可以是概念上的，如一个开发项目。
对象是构成现实世界的一个独立的单位，具有自己的静态特征（用数据描述）和动态特征（行为或具有的功能）。
例如：人的特征：姓名、性别、年龄等，行为：衣、食、住、行等。
图 5-1-1 对象的定义（1）对象、属性、操作、消息定义对象可以定义为系统中用来描述客观事物的一个实体，它是构成系统的一个基本单位，由一组属性和一组对属性进行操作的服务组成。
《软件工程(第二版)》 第五章
5.2.4 模块独立性
模块的独立性是软件质量的关键： （1）模块化程度较高的软件容易开发； （2）模块化程度较高的软件也比较容易测试和维护。 模块的独立性的度量标准：耦合和内聚。
1、耦合 耦合：软件结构中各个模块之间相互关联程度的度量。
常见的耦合：
（1）非直接耦合 （2）数据耦合 （3）标记耦合 （4）控制耦合 （5）公共耦合 （6）内容耦合 设计原则：尽量使用数据耦合，少用控制耦合，限制公 共耦合的范围，避免使用内容耦合。
这个不等式表明：单独解决问题 P1 和 P2 所需的工作 量之和，比把 P1 和 P2 合起来作为一个问题来解决时所需 的工作量要少。 这种“分而治之”的思想提供了模块化的根据：把复 杂的问题分解成许多容易解决的小问题，原来的问题也 就容易解决了。
模块化和软件成本的关系
软件总成本 最小成本区 M 接口成本
5.5.1 数据流图的类型 5.5.2 设计步骤 5.5.3 变换设计 5.5.4 事务设计 5.5.5 设计的后处理
需求分析阶段得出的数据流图是总体设计的根 本出发点。 通常，选取的这些方案中至少应包括低成本、 中成本和高成本的三种方案类型。 对每个合理方案要提供以下几方面资料： （1）系统流程图； （2）数据字典； （3）成本／效益分析； （4）实现这个系统的进度计划。
5.1.2 推荐最佳方案
分析员从合理方案中选择一个最佳方案向用户 推荐，并为推荐的方案制定详细的实现计划。 对于分析员推荐的最佳方案，用户和有关专家 应该认真审查。如果确认该方案确实符合用户的需 要，并且在现有条件下完全能够实现，则应该提请 使用部门负责人进一步审批。在使用部门负责人也 接受了分析员所推荐的方案之后，方可进入总体设 计过程的下一步工作，即结构设计阶段。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
模块数目 用此模块的上 级的模块数目
43
深度 = 分层的层数。过大表示分工过细。 宽度 = 同一层上模块数的最大值。过大表示系统复杂 度大。 44
信息来控制另一个模块
B Flag
Fn ……
F2 ……
A
Flag
F1
接口单一， 但仍然影响 被控模块的 内部逻辑。
数据耦合(Data coupling): 只有数据在模块之间进行
交换
The most desirable.
36
耦合是影响软件复杂程度的一个重要因
素,应采取下述设计原则: 应该尽量使用数据耦合 少用控制耦合 限制公共耦合的范围
9
5.1
设计过程
• 对数据流图进一步细化，进行功能分解
10
5.1
设计过程
5.设计软件结构
• 软件结构反映系统中模块的相互调用关系：顶
层模块调用它的下层模块以实现程序的完整功
能，每个下层模块再调用更下层的模块，最下
层的模块完成最具体的功能。
• 软件结构通过层次图或结构图来描绘，可以直
接从数据流图映射出软件结构。
概括起来，暂时忽略它们之间的差异，这就
是抽象。或者说抽象就是抽出事物的本质特
性而暂时不考虑它们的细节。
20
处理复杂系统：用层次的方式构造和分析。
一个复杂的动态系统首先可以用一些高级的 抽象概念构造和理解，这些高级概念又可以 用一些较低级的概念构造和理解，如此进行 下去，直至最低层次的具体元素。
21
A:
Read inputs
38
from ……
时间内聚（Temporal cohesion）：模块内的功能在
同一时间段内完成
例如：系统的初始化 问题：不同功能混在一个模块中，有时共用部分 编码，使局部功能的修改牵动全局。
中内聚： 过程内聚 （Procedural cohesion）：模块内的处理是相 关的，而且必须以特定顺序执行
完全不用内容耦合。
37
⑵ 内聚 (Cohesion): 一个模块内各元素结合的紧密程度.
Goal: as cohesive as possible.
低内聚：
偶然内聚（Coincidental cohesion）
逻辑内聚（Logical cohesion）
例如：
from disk from tape
内聚度量一个模块内的各 个元素彼此结合的紧密程 度。设计时应该力求做到 高内聚。
41
5.3
启 发 规 则
改进软件结构提高模块独立性 过小的模块开销大于有效操作，而
且模块数目过多将使系统接口复杂。 设计出软件的初步结构以后，应该审 因此过小的模块有时不值得单独存 查分析这个结构，通过模块分解或合并， 在，特别是只有一个模块调用它时， 通常可以把它合并到上级模块中去 力求降低耦合提高内聚。 而不必单独存在。
2、选取合理的方案
• 从上一步得到的一系列供选择的方案中选取若干个合 理的方案，通常，考虑的这些方案中至少应包括低成本、 中成本和高成本的三种方案类型。 • 对每个合理方案要提供以下几方面资料： （1）系统流程图； （2）数据字典； （3）成本／效益分析；
（4）实现这个系统的进度计划。
6
5.1
设计过程
图5.1 模块化和软件成本的关系
18
采用模块化原理的优点
使软件结构清晰，容易设计、容易阅读和理解。 使软件容易测试和调试，从而提高软件的可靠性。 能够提高软件的可修改性。 有助于软件开发工程的组织管理。
19
抽象
人们在实践中认识到，在现实世界中一
定事物、状态或过程之间总存在着某些相似
的方面（共性）。把这些相似的方面集中和
Global : V1 V2 Global : V1 V2
公共区可以是：全程数据区、共享通信区、内存公共覆盖 区、任何介质上的文件、物理设备等。
A: ………… ………… A1=V1+V2 ………… …………
B: ………… ………… V1=B1 ………… …………
A: ………… ………… V1++ ………… …………
•
如果A模块读取该项数据，然后调用C模块对该项重新
计算，并进行数据更新。
34
A
D
B
C
全程数 据区
E
（3）公共耦合
• 如果此时C模块错误地更新了该项数据，在往下的处
理中模块E读该数据项时出现错误。 • 表面上看，问题由模块E产生，实际上由模块C引起。
35
控制耦合(Control coupling)：一个模块通过传递控制
8
5.1
设计过程
4.功能分解
为了最终实现目标系统，必须设计出组成这个系统的所 有程序和文件（或数据库）。
对于大型程序的设计，通常分为两个阶段：结构设计和 过程设计。 结构设计：确定程序由哪些模块组成，以及这些模块之 间的相互关系。
过程设计：确定每个模块的处理过程。
其中，结构设计是总体设计阶段的任务，而过程设计则 是详细设计阶段的任务。
设计软件的结构，确定系统中每个程序是由哪些
模块组成的，以及这些模块相互间的关系。
3
站在全局高度上，花较少成本，从较抽象的层次上 分析对比多种可能的系统实现方案和软件结构，从 中选出最佳方案和最合理的软件结构，从而用较低 成本开发出较高质量的软件系统。
寻找实现目标系统的各种不同的方案
从若干个合理的方案中选取最佳方案
B: ………… ………… V2=B1+V1 ………… …………
问题： 公共部分的改动将影响所有调用它的模块； 公共部分的数据存取无法控制； 复杂程度随耦合模块的个数增加而增加。
33
A B C 全程数 据区
D
E
（3）公共耦合
• 图中存在公共耦合，假设模块A、C、E都存取全程数据
区（如公用一个磁盘文件）中的一个数据项。
23
逐步求精是一项把一个时期内必须解决
的种种问题按优先级排序的技术。它确
保每个问题都将被解决，而且每个问题
都将在适当的时候被解决，但是，在任
何时候一个人都不需要同时处理7个以上
知识块。
24
抽象与求精是一对互补的概念。 抽象使得设计者能够说明过程和数据，同
时却忽略低层细节。
求精则帮助设计者在设计过程中逐步揭示 出低层细节。
统一的功能密切相关，而且这些处理必须顺序执行。 功能内聚（Functional cohesion）：所有元素合力完成一 个单一功能，缺一不可
40
模块独立
耦合
耦合是对一个软件结构内 不同模块之间互连程度的 度量。尽量使用数据耦合 ，少用控制耦合，限制公 共环境耦合的范围，完全 不用内容耦合。
内聚
模块化就是把程序划分成独立命名且可独立 访问的模块，每个模块完成一个子功能，把这些 模块集成起来构成一个整体，可以完成指定的功 能满足用户的需求。
17
模块化与模块独立
当模块数目增加时每 个模块的规模将减小，开 发单个模块需要的成本 （工作量）确实减少了； 但是，随着模块数目增加， 设计模块间接口所需要的 工作量也将增加。每个程 序都相应地有一个最适当 的模块数目 M ，使得系统 的开发成本最小。
复合耦合
数据耦合 低
高
偶然型 内聚性 弱
逻辑型
时间型
通信型
顺序型
功能型 强
29
⑴ 耦合(Coupling)
耦合表示一个软件结构内各个模块之间的互连程度，应 尽量选用松散耦合的系统
Great deal of dependence Independent
Highly coupled
Loosely coupled
考虑对任何问题的模块化解法时，可以提出 许多抽象的层次。在抽象的最高层次使用问 题环境的语言，以概括的方式叙述问题的解 法；在较低抽象层次采用更过程化的方法， 把面向问题的术语和面向实现的术语结合起 来叙述问题的解法；最后在最低的抽象层次 用可直接实现的方式叙述问题的解法。
22
逐步求精
定义：“为了能集中精力解决主要问题而 尽量推迟对问题细节的考虑。” Miller法则：一个人在任何时候都只能 把注意力集中在7±2个知识块上 求精要求设计者细化原始陈述，随着每个 后续求精（细化）步骤的完成而提供越来越多 的细节。
有效的模块化（即具有独立性的模块）的软 件比较容易开发出来； 独立的模块比较容易测试和维护。
27
模块的独立程度由两个定性标准度量， 分别是耦合和内聚。 耦合：衡量不同模块彼此间互相依赖(连接) 的紧密程度； 内聚：衡量一个模块内部各个元素彼此结合 的紧密程度。
28
内容耦合 耦合性
公共耦合
控制耦合
25
信息隐藏
问题：“为了得到最好的一组模块，应 该怎样分解软件”。
信息隐藏原理指出：应该这样设计和确 定模块，使得一个模块内包含的信息（过程 和数据）对于不需要这些信息的模块来说， 是不能访问的。 实际上，应该隐藏的不是有关模块的一 切信息，而是模块的实现细节。 26
模块独立
开发具有独立功能而且和其他模块之 间没有过多的相互作用的模块，就可以做 到模块独立。
Uncoupled
30
独立性由弱到强（耦合程度由强到弱）排列为：
内容耦合(Content Coupling): 一个模块直接影响另一个
……
例1：A访问C的内部 数据或不通过正 常入口而转入C 的内 goto C1 ………… …………
C
D
C: ………… ………… C1: …… ……
11
5.1
设计过程
数据库的应用越来越广泛，目前大多数的
6.数据库设计 系统都要用到数据库技术。 数据库设计是一项专门的技术，包括模式
43
深度 = 分层的层数。过大表示分工过细。 宽度 = 同一层上模块数的最大值。过大表示系统复杂 度大。 44
信息来控制另一个模块
B Flag
Fn ……
F2 ……
A
Flag
F1
接口单一， 但仍然影响 被控模块的 内部逻辑。
数据耦合(Data coupling): 只有数据在模块之间进行
交换
The most desirable.
36
耦合是影响软件复杂程度的一个重要因
素,应采取下述设计原则: 应该尽量使用数据耦合 少用控制耦合 限制公共耦合的范围
9
5.1
设计过程
• 对数据流图进一步细化，进行功能分解
10
5.1
设计过程
5.设计软件结构
• 软件结构反映系统中模块的相互调用关系：顶
层模块调用它的下层模块以实现程序的完整功
能，每个下层模块再调用更下层的模块，最下
层的模块完成最具体的功能。
• 软件结构通过层次图或结构图来描绘，可以直
接从数据流图映射出软件结构。
概括起来，暂时忽略它们之间的差异，这就
是抽象。或者说抽象就是抽出事物的本质特
性而暂时不考虑它们的细节。
20
处理复杂系统：用层次的方式构造和分析。
一个复杂的动态系统首先可以用一些高级的 抽象概念构造和理解，这些高级概念又可以 用一些较低级的概念构造和理解，如此进行 下去，直至最低层次的具体元素。
21
A:
Read inputs
38
from ……
时间内聚（Temporal cohesion）：模块内的功能在
同一时间段内完成
例如：系统的初始化 问题：不同功能混在一个模块中，有时共用部分 编码，使局部功能的修改牵动全局。
中内聚： 过程内聚 （Procedural cohesion）：模块内的处理是相 关的，而且必须以特定顺序执行
完全不用内容耦合。
37
⑵ 内聚 (Cohesion): 一个模块内各元素结合的紧密程度.
Goal: as cohesive as possible.
低内聚：
偶然内聚（Coincidental cohesion）
逻辑内聚（Logical cohesion）
例如：
from disk from tape
内聚度量一个模块内的各 个元素彼此结合的紧密程 度。设计时应该力求做到 高内聚。
41
5.3
启 发 规 则
改进软件结构提高模块独立性 过小的模块开销大于有效操作，而
且模块数目过多将使系统接口复杂。 设计出软件的初步结构以后，应该审 因此过小的模块有时不值得单独存 查分析这个结构，通过模块分解或合并， 在，特别是只有一个模块调用它时， 通常可以把它合并到上级模块中去 力求降低耦合提高内聚。 而不必单独存在。
2、选取合理的方案
• 从上一步得到的一系列供选择的方案中选取若干个合 理的方案，通常，考虑的这些方案中至少应包括低成本、 中成本和高成本的三种方案类型。 • 对每个合理方案要提供以下几方面资料： （1）系统流程图； （2）数据字典； （3）成本／效益分析；
（4）实现这个系统的进度计划。
6
5.1
设计过程
图5.1 模块化和软件成本的关系
18
采用模块化原理的优点
使软件结构清晰，容易设计、容易阅读和理解。 使软件容易测试和调试，从而提高软件的可靠性。 能够提高软件的可修改性。 有助于软件开发工程的组织管理。
19
抽象
人们在实践中认识到，在现实世界中一
定事物、状态或过程之间总存在着某些相似
的方面（共性）。把这些相似的方面集中和
Global : V1 V2 Global : V1 V2
公共区可以是：全程数据区、共享通信区、内存公共覆盖 区、任何介质上的文件、物理设备等。
A: ………… ………… A1=V1+V2 ………… …………
B: ………… ………… V1=B1 ………… …………
A: ………… ………… V1++ ………… …………
•
如果A模块读取该项数据，然后调用C模块对该项重新
计算，并进行数据更新。
34
A
D
B
C
全程数 据区
E
（3）公共耦合
• 如果此时C模块错误地更新了该项数据，在往下的处
理中模块E读该数据项时出现错误。 • 表面上看，问题由模块E产生，实际上由模块C引起。
35
控制耦合(Control coupling)：一个模块通过传递控制
8
5.1
设计过程
4.功能分解
为了最终实现目标系统，必须设计出组成这个系统的所 有程序和文件（或数据库）。
对于大型程序的设计，通常分为两个阶段：结构设计和 过程设计。 结构设计：确定程序由哪些模块组成，以及这些模块之 间的相互关系。
过程设计：确定每个模块的处理过程。
其中，结构设计是总体设计阶段的任务，而过程设计则 是详细设计阶段的任务。
设计软件的结构，确定系统中每个程序是由哪些
模块组成的，以及这些模块相互间的关系。
3
站在全局高度上，花较少成本，从较抽象的层次上 分析对比多种可能的系统实现方案和软件结构，从 中选出最佳方案和最合理的软件结构，从而用较低 成本开发出较高质量的软件系统。
寻找实现目标系统的各种不同的方案
从若干个合理的方案中选取最佳方案
B: ………… ………… V2=B1+V1 ………… …………
问题： 公共部分的改动将影响所有调用它的模块； 公共部分的数据存取无法控制； 复杂程度随耦合模块的个数增加而增加。
33
A B C 全程数 据区
D
E
（3）公共耦合
• 图中存在公共耦合，假设模块A、C、E都存取全程数据
区（如公用一个磁盘文件）中的一个数据项。
23
逐步求精是一项把一个时期内必须解决
的种种问题按优先级排序的技术。它确
保每个问题都将被解决，而且每个问题
都将在适当的时候被解决，但是，在任
何时候一个人都不需要同时处理7个以上
知识块。
24
抽象与求精是一对互补的概念。 抽象使得设计者能够说明过程和数据，同
时却忽略低层细节。
求精则帮助设计者在设计过程中逐步揭示 出低层细节。
统一的功能密切相关，而且这些处理必须顺序执行。 功能内聚（Functional cohesion）：所有元素合力完成一 个单一功能，缺一不可
40
模块独立
耦合
耦合是对一个软件结构内 不同模块之间互连程度的 度量。尽量使用数据耦合 ，少用控制耦合，限制公 共环境耦合的范围，完全 不用内容耦合。
内聚
模块化就是把程序划分成独立命名且可独立 访问的模块，每个模块完成一个子功能，把这些 模块集成起来构成一个整体，可以完成指定的功 能满足用户的需求。
17
模块化与模块独立
当模块数目增加时每 个模块的规模将减小，开 发单个模块需要的成本 （工作量）确实减少了； 但是，随着模块数目增加， 设计模块间接口所需要的 工作量也将增加。每个程 序都相应地有一个最适当 的模块数目 M ，使得系统 的开发成本最小。
复合耦合
数据耦合 低
高
偶然型 内聚性 弱
逻辑型
时间型
通信型
顺序型
功能型 强
29
⑴ 耦合(Coupling)
耦合表示一个软件结构内各个模块之间的互连程度，应 尽量选用松散耦合的系统
Great deal of dependence Independent
Highly coupled
Loosely coupled
考虑对任何问题的模块化解法时，可以提出 许多抽象的层次。在抽象的最高层次使用问 题环境的语言，以概括的方式叙述问题的解 法；在较低抽象层次采用更过程化的方法， 把面向问题的术语和面向实现的术语结合起 来叙述问题的解法；最后在最低的抽象层次 用可直接实现的方式叙述问题的解法。
22
逐步求精
定义：“为了能集中精力解决主要问题而 尽量推迟对问题细节的考虑。” Miller法则：一个人在任何时候都只能 把注意力集中在7±2个知识块上 求精要求设计者细化原始陈述，随着每个 后续求精（细化）步骤的完成而提供越来越多 的细节。
有效的模块化（即具有独立性的模块）的软 件比较容易开发出来； 独立的模块比较容易测试和维护。
27
模块的独立程度由两个定性标准度量， 分别是耦合和内聚。 耦合：衡量不同模块彼此间互相依赖(连接) 的紧密程度； 内聚：衡量一个模块内部各个元素彼此结合 的紧密程度。
28
内容耦合 耦合性
公共耦合
控制耦合
25
信息隐藏
问题：“为了得到最好的一组模块，应 该怎样分解软件”。
信息隐藏原理指出：应该这样设计和确 定模块，使得一个模块内包含的信息（过程 和数据）对于不需要这些信息的模块来说， 是不能访问的。 实际上，应该隐藏的不是有关模块的一 切信息，而是模块的实现细节。 26
模块独立
开发具有独立功能而且和其他模块之 间没有过多的相互作用的模块，就可以做 到模块独立。
Uncoupled
30
独立性由弱到强（耦合程度由强到弱）排列为：
内容耦合(Content Coupling): 一个模块直接影响另一个
……
例1：A访问C的内部 数据或不通过正 常入口而转入C 的内 goto C1 ………… …………
C
D
C: ………… ………… C1: …… ……
11
5.1
设计过程
数据库的应用越来越广泛，目前大多数的
6.数据库设计 系统都要用到数据库技术。 数据库设计是一项专门的技术，包括模式