当前位置：文档之家 › 软件工程课件第四章

软件工程课件第四章

  • 格式：ppt
  • 大小：958.00 KB
  • 文档页数：65

下载文档原格式

  / 65

合集下载

软件工程第4章 软件设计PPT课件

软件工程第4章 软件设计PPT课件

A B
(1)顺 序 型
S F
P T
(4)后 判 定 循 环 (D O -U N T IL )
F
T
P
A
B
(2)选 择 型
F P T S
(3)先 判 定 型 循 环 (W H IL E -D O )
T
P=1
A1
F
T
P=2
A2
F
T
P=n
An
F
(5)多 情 况 选 择 型 (C A S E 型 )
A B
确定事务中心 和加工路径 事
务 分 析 映射成事务结构
“变换”
确定逻辑输入/输 变 出和变换中心 换 分 析
映射成变换结构
用启发式规则 精化软件结构
导出接口描述 和全程数据结构
未通过 复查
通过 详细设计
详细设计的过程中应遵循一下原则。 1.保证模块的逻辑描述要清晰易读、正确可靠。 2.采用结构化程序设计（Structured Programming） 方法，改善控制结构，降低程序的复杂程度，从 而提高程序的可读性、可测试性、可维护性。 3.选择恰当描述工具来描述各模块算法。
题域子系统、人机交互子系统、任务管理子系统和数据管理子 系统4个子系统组成。
任务也称进程，就是执行一系列活动的一段程序。当系统 中有许多并发任务时，需要依照各个行为的协调关系进行 任务划分，所以任务管理主要是对系统各种任务进行选择 和调整的过程。要标识任务管理子系统中的任务。
1.标识事件驱动任务 2.标识时钟驱动任务 3.标识优先任务 4.标识关键任务 5.标识协调任务
设计数据管理子系统设计数据管理子系统11数据存储格式的设计数据存储格式的设计22数据存放服务的设计数据存放服务的设计服务的算法设计与一般的软件算法的设计并无不同只是服务的算法设计与一般的软件算法的设计并无不同只是在设计过程中可能需要添加一些内部类和内部操作增加在设计过程中可能需要添加一些内部类和内部操作增加的新类主要用来存放在算法执行过程中所得出的某些中间的新类主要用来存放在算法执行过程中所得出的某些中间结果

软件工程第4章

软件工程第4章
《软件工程》陆惠恩主编 19
习题4
选择题答案
8. A：（2）； B：（3）；C ：（3）； D：2 ； E ：（2）。 9．A ：（5）；B ：（7）；C ：（3） D ：（2）； E：（1）。

《软件工程》陆惠恩主编
20
4.3 软件结构设计的图形工具

4.3.1 层次图（或HIPO图）
《软件工程》陆惠恩主编
9
4.3.2 结构图
1. 结构图的符号






（1）方框代表模块，框内注 明模块的名字和主要功能。 （2）方框之间的大箭头或直 线表示模块的调用关系。 （3）带注释的小箭头表示模 块调用时传递的信息及其传 递方向。 尾部加空心圆的小箭头表示 传递数据信息。 尾部加实心圆的小箭头表示 传递控制信息。 （4）选择结构 （5）循环结构，模块 H 循环 调用模块 A,B,C，见图4.5(b)。
《软件工程》陆惠恩主编
10
2. 结构图的绘制

【例4-6】学生成绩管理系统的结构图
《软件工程》陆惠恩主编
11
4.4 概要设计方法
4.4.1 结构化方法 结构化方法又称面向数据流设计方法(Structured Design，SD)。 设计步骤是先根据系统数据流图建立系统逻辑模型， 再进行结构设计。 1. 建立系统逻辑模型 （１）变换型数据流 （２）事务型数据流 【例4.7】学生成绩管理系统系统属于变换型数据流。 【例4.8】工资管理系统属于事务型数据流。 【例4.9】医疗费管理系统中事务型、变换型两种数据流 同时存在 2. 完成软件结构设计
《软件工程》陆惠恩主编
6
2. 模块的内聚
一个模块内各个元素彼此结合的紧密程度用内聚 来度量。 （１）偶然内聚 （２）逻辑内聚 （３）时间内聚 （４）通信内聚 （５）顺序内聚 （６）功能内聚 内聚按紧密程度从低到高排列： 偶然内聚、逻辑内聚、时间内聚、通信内聚、 功能内聚。

软件工程讲义第四章

软件工程讲义第四章
软件工程讲义第四章
需求确认检查表
❖需求说明清晰吗？有没有可能造成误解？ ❖需求的来源（如人员、规则、文档）弄清了吗？需求的最终说明是 否已经根据或对照最初来源检查过？ ❖需求是否用定量的术语界定？ ❖其他哪些需求与此需求相关？是否已经使用交叉索引或其他机制清 楚地加以说明了？ ❖需求是否违背某个系统领域的约束？ ❖需求是否可以测试？如果可以，能否说明测试检验了需求？ ❖对已经创建的任何系统模型，需求是否可跟踪？ ❖对整体系统/产品目标，需求是否可跟踪？ ❖规格说明的构造方式是否有助于理解、引用和翻译成更技术性的工 作产品？ ❖对已创建的规格说明是否建立了索引？ ❖和系统性能、行为及运行特征相关的需求的说明是否清楚？哪些需 求是隐含出现的？
软件工程讲义第四章
需求工程
❖需求工程是指致力于不断理解需求的大量任务 和技术。从软件过程的角度来看，需求工程是一 个软件工程动作，开始于沟通并持续至建模。 ❖需求工程在设计和构造之间建立起联系的桥梁。 有人认为开始于项目共利益者，即在那里定义业 务需求，刻画用户场景，描述功能和特性，识别 项目约束条件。另外一些人可能会建议从宽泛的 系统定义开始，此时软件只是更大的系统范围中 的一个构件。
软件工程讲义第四章
导出
❖系统或产品的目标是什么？ ❖想要实现什么？ ❖系统和产品如何满足业务的要求，最终系 统或产品如何用于日常工作？ ❖而实际上导出需求却是异常的困难。
软件工程讲义第四章
导出
❖范围问题：系统的边界不清楚，或客户/用户的 说明带有多余的技术细节，这些细节可能会混淆 而不是澄清系统的整体目标。 ❖理解问题：客户/用户并不完全确定需要什么， 对其计算环境的能力和限制所知甚少，对问题域 没有完整的认识，与系统工程师在沟通上有问题， 省略那些他们认为是“明显的”信息，确定的需求 和其他客户/用户的需求相冲突，需求说明有歧 义或不可测试。 ❖易变问题：需求随时间变化。

软件工程导论课件之第4章 形式化说明技术(第五版)(张海藩编著)_百度文库

软件工程导论课件之第4章 形式化说明技术(第五版)(张海藩编著)_百度文库
实质上与上面的通俗定义是一样的。
第4章 形式化说明技术
前言 4.1 概述 4.2 有穷状态机 4.3 Petri网 4.4 Z语言 4.5 小结
4.1 概述
4.1.1 非形式化方法的缺点
用自然语言（典型的非形式化方法）书写的系统规 格说明书，可能存在矛盾、二义性、含糊性、不完 整性及抽象层次混乱等问题。
矛盾是指一组相互冲突的陈述。
矛盾是指一组相互冲突的陈述。（不同系统分析员定义范围不同） 二义性是指读者可以用不同方式理解的陈述。 含糊性，例如：这样的需求：“系统界面应该是对 用户友好的。”实际上，这样笼统的陈述并没有给 出任何有用的信息。 不完整性可能是在系统规格说明中最常遇到的问题 之一。（如规格中没有考虑登录失败的转向的页面，即考虑问题不全面） 抽象层次混乱是指在非常抽象的陈述中混进了一些 关于细节的低层次陈述。（总体设计中混入了详细设计，分不清他们）
第4章 形式化说明技术
前言 4.1 概述 4.2 有穷状态机 4.3 Petri网 4.4 Z语言 4.5 小结
形式化说明技术=形式化方法，概念等同。
软件生命周期包括哪几个阶段？
可行性研究
需求分析 总体设计 详细设计
编码和单元测试 描述“系统规格说明书 ”的方法，有哪些？ 需求规格说明书
总体设计规格说明书
状态
事件/输入
图4.1 保险箱的状态转换图
图4.1是一个有穷状态机的状态转换图。状态转换 并不一定要用图形方式描述，表4.1的表格形式也 可以表达同样的信息。
转换函数：当前状态+事件/输入下个状态
从上面这个简单例子可以看出，一个有穷状态机包 括下述5个部分：状态集J、输入集K、由当前状态 和当前输入确定下一个状态(次态)的转换函数T、 初始态S和终态集F。对于保险箱的例子，相应的 有穷状态机的各部分如下。 状态集J：｛保险箱锁定，A，B，保险箱解锁，报 警｝。 输入集K：｛1L，1R，2L，2R，3L，3R｝。 转换函数T：如表4.1所示。（当前状态+事件/输入下个状态） 初始态S：保险箱锁定。 终态集F：｛保险箱解锁，报警｝。

软件工程课件之第4章用例和用例图

软件工程课件之第4章用例和用例图

4.2.3 泛化关系
借阅者
.9 泛化关系
4.2.4 分组关系
在一些用例图中，用例的数目可能很多，这时就需要把 这些用例组织起来。这种情况在一个系统包含很多子系 统时就会出现。另一种可能就是，当你按顺序和用户会 谈，收集系统需求时，每个需求必须用一个单独的用例 来表达，这时就需要某种方式来对这些需求进行分类。
4.1.1 参与者
例如，在“图书管理系统”中，可以认为“读者”是 “学生读者”和“教师读者”的泛化，而“学生读者” 还可以具体化为“本科生读者”和“研究生读者”；同 样，“图书管理员”也是“采购员”、“ 编目员”及 “借阅人员”的泛化。图4.3表示出了参与者之间的泛 化关系。
4.1.1 参与者
“<<extend>>”是扩展关系的构造型，箭头指向基本用例。
4.2.2 扩展关系
借阅者
<<include>>
还书
<<extend>>
查询图书 交罚款
图4.8 扩展关系
区别与联系：
联系：都是从现有的用例中抽取出公共的那部分信息
，作为一个单独的用例，然后通过不同的方法来重用这 个公共的用例，以减少模型维护的工作量。
因此，在“图书管理系统”中“借阅者”和“系统管理 员”都是参与者。
4.1.1 参与者
【例4-1】客户给销售员发来传真订货， 销售员下班前 将当日订货单汇总输入系统。谁是系统的参与者？
分析：根据参与者的定义可知，此系统的参与者是销售 员。
4.1.1 参与者
【例4-2】在需求分析中常见的权限控制问题，一般的 用户只可以使用一些常规的操作，如查询等，而管理员 除了常规操作之外还需要进行一些系统管理工作，如一 些关键数据的增加、删除、修改等，操作员既可以进行 常规操作又可以进行一些配置操作。

《软件工程与开发技术》课件第4章

《软件工程与开发技术》课件第4章

第4章 软件设计
模块化是指将整个程序划分为若干个模块，每个模块用于 实现一个特定的功能。划分模块对于解决大型复杂的问题是非 常必要的，可以大大降低解决问题的难度。为了说明这一点， 我们可对问题复杂性、开发工作量和模块数之间的关系进行以 下推理。
首先，我们设C(x)为问题x所对应的复杂度函数，E(x)为解 决问题x所需要的工作量函数。对于两个问题P1和P2，如果：
耦合是影响软件复杂度的一个重要因素，设计过程中应力 求降低程序的耦合性。在以上所介绍的耦合中，数据耦合的程 度最低，其次是公共耦合，再其次是控制耦合，程度最高的是 内容耦合。
第4章 软件设计
2) 内聚性
内聚性是对一个模块内部各个组成元素之间相互结合的紧密 程度的度量指标。模块中组成元素结合的越紧密，模块的内聚性 就越高，模块的独立性也就越高。理想的内聚性要求模块的功能 应明确、单一，即一个模块只做一件事情。模块的内聚性和耦合 性是两个相互对立且又密切相关的概念。事实上，它们是同一事 物的两个方面，模块的高内聚性往往就意味着模块间的低耦合性。 因为程序中的各个部分必定是有联系的，若将其中密切相关的部 分放在同一个模块中，模块间的联系就会降低；反之，若将密切 相关的部分分散放在不同的模块之中，模块间的联系必然会加强。 在进行模块化设计时，耦合性和内聚性都是必须考虑的重要指标。 但经实践证明，保证模块的高内聚性比低耦合性更为重要，在软 件设计时应将更多的注意力集中在提高模块的内聚性上。
C(P1)> C(P2) 即问题P1的复杂度比P2高，则显然有：
E(P1)> E(P2) 即解决问题P1比P2所需的工作量大。
第4章 软件设计
在人们解决问题的过程中，发现存在有另一个有趣的规律： C(P1+P2)> C(P1)+C(P2)

软件工程课件 第4章_

软件工程课件 第4章_

（2）数据库设计。指数据存储文件 的设计，主要进行以下几方面设计：
①概念设计。在数据分析的基础上， 采用自底向上的方法从用户角度进行 视图设计，一般用ER模型来表示数 据模型，这是一个概念模型。
②逻辑设计。
③物理设计。
3．编写总体设计文档
• 主要有：（1）总体设计说明书。（2） 数据库设计说明书，主要给出所使用 的DBMS简介、数据库的概念模型、逻 辑设计、结果。（3）用户手册，对需 求分析阶段编写的用户手册进行补充。 （4）修订测试计划， 对测试策略、方 法、步骤提出明确要求。
划分模块时尽量做到高内聚，低耦合， 保持模块相对独立性，并以此原则优 化初始的软件结构。 • （1）如果若干模块之间耦合强度过高， 每个模块内功能不复杂，可将它们合 并，以减少信息的传递和公共区的引 用。 • （2）若有多个相关模块，应对它们的 功能进行分析，消去重复功能。
4.3.2模块规模应该适中
巧合内聚（Coincidental Cohesion）
巧合内聚又称为偶然内聚。当模块内 各部分之间没有联系，或者即使有联 系，这种联 系也很松散， 则称这种模 块为巧合内 聚模块，它 是内聚程度 最低的模块。
逻 辑 内 聚 （ Logical Cohesion ）
这种模块把几种 相关的功能组合 在一起，每次被 调用时，由传送 给模块的判定参 数来确定该模块 应执行哪一种功 能。
信息内聚(Informational Cohesion) 这种模块完成多个功能，各个功 能都在同一数据结构上操作，每 一项功能有一个唯一的入口点。 这个模块将根据不同的要求，确 定该执行哪一个功能。由于这个 模块的所有功能都是基于同一个 数据结构（符号表），因此，它 是一个信息内聚的模块。
• 信息内聚模块可以看成是多 个功能内聚模块的组合，并 且达到信息的隐蔽。即把某 个数据结构、资源或设备隐 蔽在一个模块内，不为别的 模块所知晓。

软件工程第4章总体设计课件

软件工程第4章总体设计课件
2020/7/8
(6) 逻辑内聚（Logical Cohesion）
• 把几种相关功能（逻辑上相似的功能）组合 在一模块内，每次调用由传给模块的参数确 定执行哪种功能。
S
X
Y
Z
W
A
B
C
D
S
X
Y
Z
W
2020/7/8
ABCD
(7) 巧合内聚（Coincidental Cohesion）
• 当模块内各部分之 间没有联系，或者 即使有联系，这种 联也很松散，则称 这种模块为巧合内 聚模块，它是内聚 程度最低的模块。
模块独立性
弱
(1) 非直接耦合
两个模块没有直接关系(模块1和模块2)， 模块独立性最强。
模块1
模块3
2020/7/8
模块4
模块2
(2) 数据耦合
一模块调用另一 模块时，被调用 模块的输入、输 出都是简单的数 据(若干参数)。
属松散耦合。
开发票
单价 数量
金额
计算水费
2020/7/8
(3) 标记耦合(特征耦合)
(7) 内容耦合
A
B
A B
Entry1 ……
Entry2 ……
一模块直接 访问另一模 块的内部信 息 (程序代 码或数据）
不
模
块 代 码 重 叠
正 常
多
转
入
入
口
另 一 模
模 块
块
最不好的耦合形式！
2020/7/8
以上给出了 7种耦合类型，这只是从耦合的机制上所 做的分类，按耦合的强弱程度的排列只是相对的关系 。但它给设计人员在设计程序结构时提供了一决策准 则。实际上，开始时两个模块之间的耦合不只是一种 类型，而是多种类型的混合。这就要求设计人员按照 实际情况进行分析、比较和分析，逐步加以改进，以 提高模块的独立性。

软件工程课件第四章

软件工程课件第四章
第一，有效的模块化（即具有独立的模块）的软件比较容 易开发出来。
第二，独立的模块比较容易测试和维护。 模块的独立程度的度量标准:
内聚:衡量一个模块内部各个元素彼此结合的紧密程度； 耦合:衡量不同模块彼此间互相依赖（连接）的紧密程度。
06.04.2021
信息科学与技术学院
20
模块独立 – 耦合
耦合是对一个软件结构内不同模块之间互联程度的度量。 耦合强弱取决于模块之间接口的复杂程度，调用模块的方式， 以及通过接口的数据。实际上，耦合是接口数据对模块独立 性的影响。
18
信息的隐蔽和局部化
信息隐蔽：模块内部的信息（处理过程和数据），应对 不需要了解这些信息的模块隐蔽起来，使它们不能访问。
信息隐蔽是模块设计的基本原则。意味着在进行模块划 分时，应保证模块的独立性，使组成程序的模块之间只需交 换完成软件功能所必需的信息。
将信息隐蔽作为模块化设计标准，为软件测试和维护对 模块的修改带来了极大的方便，使得修改时无意引入的错误 不会被扩散到被修改模块以外的其它位置。
信息科学与技术学院
30
深度、宽度、扇出和扇入应适当
深度：软件层次结构的层数。 宽度：软件结构内同一层次上模块总数的最大值。 扇入：一个模块被调用的上级模块数量。扇入越大，表 示共享该模块的上级模块越多。 扇出：一个模块直接控制（调用）的模块个数。扇出影 响宽度。 扇出过大意味着模块过分复杂，需要控制和协调过多的 下级模块。 一个好的系统的平均扇出通常是3～4（上限是5～9)
内容耦合：一个模块直接引用另一个模块内部 的内容。例如：一个模块直接访问另一个模块的内 部数据；一个模块不通过正常入口转到另一个模块 的内部；两个模块有一部分代码重叠。最高程度的 耦合是内容耦合。

四章软件工程基础

四章软件工程基础
❖ 在SA方法中，利用数据在系统中的流动 来确定软件结构。这种方法可以概括为 以下两个步骤：
❖ ①用数据流图描述系统中信息的变 换和传递过程，并辅以其他形式的说明， 如数据字典、判断表和判定树等。
❖ ②将数据流图转换成相应的软件结 构。数据流图转换成相应的软件结构。
第四章 软件工程基础
❖ （2）数据流图的组成符号 ❖ 一般来说，数据流图由四种
基本成分组成：数据流，数据处 理，数据存储，外部实体。
第四章 软件工程基础
❖ ①数据流
❖ 数据流相当于一条管道，并有一组数据流经过 它。在数据流图中，用标有名字的箭头来表示数据 流。数据流可以从加工向文件流向加工，并且可以 从外部实体流向或从系统流向外部实体。
❖ ②数据处理
❖
数据处理又叫加工。在数据流图中，加工用标
有名字的圆圈表示，其中处理名就是对数据进行操
作的名字。指向加工的数据流表示该加工的输入数
据，离开加工的数据流表示该加工的输出数据。
第四章 软件工程基础
❖ ③数据存储 ❖ 数据流图中的数据存储用两根平行线表示，在计
算机中常用文件来表示数据存储，文件名写在两平 行线之间。如果某加工需要文件，则数据流向该加 工；如果加工输出的书要存如文件或修该文件，则 数据流是从该加工流向文件。 ❖ ④外部试题 ❖ 数据的源点与终点是软件之外的实体，通常称之为 外部实体，它们与软件系统的设计一般无直接关系， 只是用于说明数据流的来龙去脉。在数据流图中， 外部实体标有名字的方框来表示。
四章软件工程基础
第四章 软件工程基础
①一套分层的数据流图，用于描述系用 到的全部数据和文件。
③一组小说明，描述各个加工处理应完 成的工作。
❖
（3）面向用户

软件工程Chapter_4 需求工程PPT课件

软件工程Chapter_4 需求工程PPT课件
17 16
4.1.5非功能需求
非功能需求
从各个角度对系统的约束和限制，反映了应用对软 件系统质量和特性的额外要求，例如响应时间、数 据精度、可靠性、开发过程的标准等。
举例：MiniLibrary
✓系统应在 20 秒之内响应所有的请求。 ✓系统每周 7 天、每天 24 小时都可以使用。 ✓对于一个没有经验的用户而言，经过两个小时的培训就 可以使用系统的所有功能。
面谈之前
n 确立面谈目的 n 确定要包括的相关用户 n 确定参加会议的项目小组成员 n 建立要讨论的问题和要点列表 n 复查有关文档和资料 n 确立时间和地点 n 通知所有参加者有关会议的目的、时间和地点
30
4.2.1 用户面谈
面谈过程需要认真的计划和准备（续）
进行面谈
n 衣着得体，准时到达 n 寻找异常和错误情况 n 深入调查细节 n 详细记录 n 指出和记录下未回答条目和未解决问题
的浪费 软件规格说明有助于开发人员与客户在“What to
do”问题上达成正式契约 需求分析形成了软件开发的基线，有助于管理软件的
演化和变更 软件需求是软件质量的基础，为系统验收测试提供了
标准
4
软件需求的重要性
Trace ability
5
案例：小型图书资料管理系统
• 问题描述
– 某学院打算开发一个小型图书资料管理系统 MiniLibrary，该 系统基于 Internet 实现教师和学生对各种图书资料的借阅、查 询和管理。
14 13
案例：用户需求：MiniLibrary
• 举例：
用户可以通过 Internet 随时查询图书信息和个人借阅情况， 并可以快捷地查找和浏览所需要的电子资料。
• 分析：上述需求描述包含了三个不同的需求

第4章软件工程

第4章软件工程
② 调用关系只能从上到下。 ③ 不严格表示模块的调用次序，习惯上从左到右。有时 为了减少连线的交叉，适当地调整同一层模块左右位置， 以保持结构图的清晰性。
第4章 总体设计
4.3 软件设计的概念和原理
3.2.1模块化
模块化的概念在程序设计技术中就出现了。何为模块？模块 在程序中是数据说明、可执行语句等程序对象的集合，或者是单 独命名和编址的元素，如高级语言中的过程、函数和子程序等。 在软件的体系结构中，模块是可组合、分解和更换的单元。
第4章 总体设计
设问题x, 表示它的复杂性函数为C(x), 解决它所需的工作 量函数为E(x)。对于问题P1和P2；如果
C(P1)＞C(P2) 即P1比P2复杂， 那么
E(P1)＞E(P2) 即问题越复杂， 所需要的工作量越大。
根据解决一般问题的经验， 规律为：
C(P1+P2)＞C(P1)+C(P2) 即一个问题由两个问题组合而成的复杂度大于分别考虑每个问 题的复杂度之和。这样，可以推出：
第4章 总体设计
成本 (工作量)
软件成本 接口成本
最小区域
成本/模块
M
模块数
图 4.6 模块与开发软件成本
第4章 总体设计
4.3.2 抽象
抽象是认识复杂现象过程中使用的思维工具，即抽出事物本 质的共同特性而暂不考虑它的细节，不考虑其他因素。抽象的概 念被广泛应用于计算机软件领域，在软件工程学中更是如此。软 件工程实施中的每一步都可以看作是对软件抽象层次的一次细化。 在系统定义阶段，软件可作为整个计算机系统的一个元素来对待； 在软件需求分析阶段，软件的解决方案是使用问题环境中的术语 来描述；从概要设计到详细设计阶段，提象的层次逐步降低，将 面向问题的术语与面向实现的术语结合起来描述解决方法，直到 产生源程序时到达最低的抽象层次。这是软件工程整个过程的抽 象层次。具体到软件设计阶段，又有不同的抽象层次，在进行软 件设计时，抽象与逐步求精、模块化密切相关，可帮助定义软件 结构中模块的实体，由抽象到具体地分析和构造出软件的层次结 构，提高软件的可理解性。

软件工程课件第四章精品文档

软件工程课件第四章精品文档
局部化：指关系密切的软件元素物理地彼此靠近。局部 化是实现信息隐蔽的重要方法。如模块内使用的局部数据元 素，当模块被调用执行时发挥作用，退出后便失去意义。
2019/10/15
信息科学与技术学院
18
模块独立
模块独立(Independence)的概念是模块化、抽象、信 息隐蔽和局部化概念的直接结果。开发具有独立功能且与其 他模块之间没有过多的相互作用的模块，就可以做到模块独 立。
如果两个模块中的每一个都能独立地工作而不需要另一个 模块地存在，那么它们彼此完全独立，这意味着模块间无任 何连接，耦合程度最低。但一个软件系统中的模块之间是彼 此协同工作的，不可能所有模块间没有连结。
2019/10/15
信息科学与技术学院
20
模块独立 – 耦合
数据耦合 ：如果两个模块彼此间通过参数交 换信息，而且交换的信息仅仅是数据，那么这种 耦合称为数据耦合。
模块的内部特性：完成模块功能的代码和局部数据。
2019/10/15
信息科学与技术学院
13
模块化
模块化：以模块作为程序设计的基本单位，把程序划分 成若干个模块，每个模块完成一个子功能，把这些模块集总 起来，并通过模块间的调用关系把它们组成一个完整的整体， 完成指定的功能。
采用模块化的依据： 容易被理解。 使问题复杂度降低，容易被实现。
信息科学与技术学院
22
模块独立 – 内聚
内聚是一个模块内各个元素彼此结合的紧 密程度的度量。内聚是信息隐蔽功能的自然扩 展，是模块内部功能独立性的表现，理想内聚 的模块只做一件事情。
按程度分类：低内聚 中内聚 高内聚。
20前1一9/页10/15
信息科学与技术学院
23
模块独立 – 内聚
  1. 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
1、将系统划分成相互联系的逻辑单元--总体上应该怎样做--总体设计、概要设计、初步设计。
2、逻辑单元实现的设计--具体应该怎样做--详细设计。
29.10.2020
信息科学与技术学院
2
总体的设计过程
一、系统体系结构设计 ●设想供选择的方案 ●选取合理的方案 ●推荐最佳方案
二、软件结构设计 ●功能分解 ●设计软件结构
29.10.2020
信息科学与技术学院
8
审核和复审
最后应该对总体设计的结果进 行严格的技术审查，通过之后再由 使用部门从管理角度进行复审。
29.10.2020
信息科学与技术学院
9
软件设计原理
容主 要 内
抽象 模块化 信息隐蔽（和局部化） 模块独立
29.10.2020
信息科学与技术学院
10
抽象
在现实世界中，一定事物、状态或过程之间 总存在着某些相似的方面（共性)。把这些相似 的方面集中和概括起来，暂时忽略它们之间的差 异，这就是抽象。抽出事物的本质特征而暂不考 虑它们的细节。
储方式，建立索引）。 数据库完整性和安全性设计。
29.10.2020
信息科学与技术学院
6
制定测试计划
确定对各模块和系统联调的测试方案。 在软件开发的早期阶段考虑测试问题，
能促使软件设计人员在设计时注意提高 软件的可测试性 。
29.10.2020
信息科学与技术学院
7
书写文档
1.系统说明：概要设计说明书 2.用户手册 3.测试计划 4.详细的实现计划 5.数据库设计结果
29.10.2020
信息科学与技术学院
14
采用模块化的依据
容易被理解。 使问题复杂度降低，容易被实现。
设函数C（x）定义问题x的复杂程度，函数E（x） 确定解决问题x需要的工作量（时间），对于两个问题 p1和p2，如果
C（p1）> C（p2） 则： E（p1）> E（p2） 规律： C（p1＋p2）> C(P1) + C(p2) 必有： E（p1＋p2）> E（p1）+ E（p2）
29.10.2020

信息科学与技术学院
5
数据结构设计
1、文件系统的数据结构设计 确定输入、输出文件的详细的数据结构。 确定算法所需的逻辑数据结构及其操作规则。 确定逻辑数据结构所涉及的程序模块
2、数据库设计 如果目标系统以数据库为基础，则要进行数据库设计。 总体设计阶段的数据库设计包括： 数据库管理系统的选择 模式设计：确定有那些基本表组成和每个表的结构。 子模式设计：具体应用所能看到的数据库内容。 物理模式设计：确定数据的存储结构和存取路径（存
前2一9页.10.2020
信息科学与技术学院
12
模块化
模块：一组有序操作的总称，它可以单独的名字存在， 单独编译，可以通过名字来访问。一个函数、一个过程就是 一个模块。
模块基本属性： （1）功能：模块做什么； （2）逻辑：描述模块内部怎么做； （3）状态：模块使用时的环境和条件。
模块的外部属性： 模块名 功能 参数(输入参数和输出参数)。
17
信息的隐蔽和局部化
信息隐蔽：模块内部的信息（处理过程和数据），应对 不需要了解这些信息的模块隐蔽起来，使它们不能访问。
信息隐蔽是模块设计的基本原则。意味着在进行模块划 分时，应保证模块的独立性，使组成程序的模块之间只需交 换完成软件功能所必需的信息。
将信息隐蔽作为模块化设计标准，为软件测试和维护对 模块的修改带来了极大的方便，使得修改时无意引入的错误 不会被扩散到被修改模块以外的其它位置。
29.10.2020
信息科学与技术学院
4
软件结构设计
2、 设计软件结构 软件结构：以模块为单位的层次结构。即： 上层模块调用它的下层模块以实现程序的完整功能； 每个下层模块再调用更下层模块完成程序的一个子功能； 最下层的模块完成最具体的功能。 方法：根据数据流图的层次关系导出软件结构。 任务：
划分程序模块 确定模块间的逻辑关系及接口参数 如果数据流图设计得好，数据流图和软件结构具有极 强的对应关系。
模块的内部特性：完成模块功能的代码和局部数据。
29.10.2020
信息科学与技术学院
13
模块化
模块化：以模块作为程序设计的基本单位，把程序划分 成若干个模块，每个模块完成一个子功能，把这些模块集总 起来，并通过模块间的调用关系把它们组成一个完整的整体 ，完成指定的功能。
采用模块化的依据： 容易被理解。 使问题复杂度降低，容易被实现。
软件工程
（Software Engineering）
第四章 总体设计
29.10.2020
1
总体设计
需求分析解决“系统必须做什么(what)”的问题，软件设 计解决“怎样做(how)”，即从技术角度考虑如何实现用户
需求。需求解决“做正确的事”，设计解决“正确地做事” 。
软件设计是把软件需求变换成软件表示的过程。最初这种 表示只是描述出软件的总框架，然后进一步细化，在此框架 中填入细节，把它加工成在程序细节上非常接近于源程序的 表示。因此软件设计分两步进行：
29.10.2020
信息科学与技术学院
15
模块化与软件成本
29.10.2020
信息科学与技术学院
16
模块化结论
1、采用模块化，是使软件设计从难 到易的基本方法。
2、模块分解应适度。模块规模太小 ，完成每个模块的工作量很小，但设 计和调试模块间的接口工作量随之增 加。
29.10.2020
信息科学与技术学院
解决复杂问题的唯一有效的方法就是运用抽象 的思维方式，首先用一些高级的抽象概念构造和 理解它；这些高级概念又可以用一些较低级的概 念构造和理解，如此进行下去，直到最低层次的 具体元素。
29.10.2020
信息科学与技术学院
11
抽象
抽象的具体表现为：自顶向下、逐步求精。 软件工程过程的每一步都是对软件解法的抽象层 次的一次求精。 软件开发的三种抽象形式： 1、过程抽象：对过程的任务采用逐步求精的解 法； 2、数据抽象：通过层次结构来描述数据对象。 3、控制抽象：描述程序控制机制而无须规定内 部细节。 模块化就是一种程序设计的抽象机制。
三、数据库设计 四、制定测试计划 五、书写文档 六、审核和复审
29.10.2020
信息科学与技术学院
3
软件结构设计
1、功能分解 进行功能分解的目的，不是从应用角度，而是从 实现角度，针对的是少数功能。这些功能不是不明确 ，而是功能实现起来较复杂，将其分解成比较简单的 功能，使每个功能的实现变得明显易懂。 该步骤将导致数据流图的进一步细化。

相关主题