软件工程 (8)
合集下载
软件工程第8章-面向对象建模
软件工程
第8章 面向对象建模
内容摘要
• • • • 用况建模 静态建模 动态建模 物理体系结构建模
复旦大学计算机科学技术学院
软件工程（第二版）
2
内容摘要
• • • • 用况建模 静态建模 动态建模 物理体系结构建模
复旦大学计算机科学技术学院
软件工程（第二版）
3
用况建模
用况建模是用于描述一个系统应该做什么的建模技 术，用况建模不仅用于新系统的需求获取，还可用于 已有系统的升级。用况模型用用况图来描述 用况图展示了各类外部执行者与系统所提供的用况 之间的连接。一个用况是系统所提供的一个功能（也 可以说是系统提供的某一特定用法）的描述 执行者是指那些可能使用这些用况的人或外部系统， 执行者与用况的连接表示该执行者使用了那个用况 用况图给出了用户所感受到的系统行为，但不描述 系统如何实现该功能 用况通常用普通正文描述，也可以用活动图来描述
复旦大学计算机科学技术学院 软件工程（第二版） 10
• 执行者还可分为主动执行者和被动执行 者： 主动执行者开始一个用况 被动执行者从不开始用况，只是参与 一个或多个用况
复旦大学计算机科学技术学院
软件工程（第二版）
11
我们可以通过回答下列问题来确定执行者： • 谁使用系统的主要功能（主执行者）？
19
复旦大学计算机科学技术学院
软件工程（第二版）
第8章 面向对象建模
内容摘要
• • • • 用况建模 静态建模 动态建模 物理体系结构建模
复旦大学计算机科学技术学院
软件工程（第二版）
2
内容摘要
• • • • 用况建模 静态建模 动态建模 物理体系结构建模
复旦大学计算机科学技术学院
软件工程（第二版）
3
用况建模
用况建模是用于描述一个系统应该做什么的建模技 术，用况建模不仅用于新系统的需求获取，还可用于 已有系统的升级。用况模型用用况图来描述 用况图展示了各类外部执行者与系统所提供的用况 之间的连接。一个用况是系统所提供的一个功能（也 可以说是系统提供的某一特定用法）的描述 执行者是指那些可能使用这些用况的人或外部系统， 执行者与用况的连接表示该执行者使用了那个用况 用况图给出了用户所感受到的系统行为，但不描述 系统如何实现该功能 用况通常用普通正文描述，也可以用活动图来描述
复旦大学计算机科学技术学院 软件工程（第二版） 10
• 执行者还可分为主动执行者和被动执行 者： 主动执行者开始一个用况 被动执行者从不开始用况，只是参与 一个或多个用况
复旦大学计算机科学技术学院
软件工程（第二版）
11
我们可以通过回答下列问题来确定执行者： • 谁使用系统的主要功能（主执行者）？
19
复旦大学计算机科学技术学院
软件工程（第二版）
软件工程第8章 软件维护
4
8.1.2 适应性维护（adaptive maintenance） 适应性维护是指使软件适应不断变化的运行环境而 进行修改过程。随着计算机技术近年来飞速发展，外部 环境（新的硬、软件配臵）或数据环境（数据库、数据 格式、数据输入/输出方式、数据存储介质）不断发生变 化，为了使软件适应这种变化而修改软件的过程称作适 应性维护。例如，适应性维护可以是将某个应用程序从 DOS环境移植到windows环境；将原来在VAX750机上 用Oracle的SQL实现的数据库移到Compaq机上；修改 程序使其适用于另外一种终端。
3
8.1.1 改正性维护（corrective maintenance） 改正性维护是在软件运行中发生异常或故障时进行 的维护工作。在软件交付使用后，由于开发时测试的不 彻底、不完全，必然会有一部分隐藏的错误被带到运行 阶段来。这些隐藏下来的错误在某些特定的使用环境下 会暴露出来。为了识别和纠正软件错误、改正软件性能 上的缺陷、排除实施中的误使用，应进行的诊断和改正 错误的过程，是改正性维护。例如，改正性维护可以是 改正原来程序中开关使用的错误；解决开发时未能测试 各种可能情况带来的问题；解决原来程序中遗漏处理文 件中最后一个记录的问题等。
1
8.1 软件维护的任务和分类
所谓软件维护就是在软件已经交付使用之后，为了 改正错误或满足新的需要而修改软件的过程。要求进行 软件维护的原因多种多样，归纳起来主要有4个原因： ①改正在特定的使用条件下暴露出来的一些潜在程 序错误或设计缺陷； ②因在软件使用过程中数据环境发生变化（例如， 某个事物处理代码发生改变）或运行环境发生变化（例 如，安装了新的硬件或操作系统），需要修改软件以适 应这种变化。
8.1.2 适应性维护（adaptive maintenance） 适应性维护是指使软件适应不断变化的运行环境而 进行修改过程。随着计算机技术近年来飞速发展，外部 环境（新的硬、软件配臵）或数据环境（数据库、数据 格式、数据输入/输出方式、数据存储介质）不断发生变 化，为了使软件适应这种变化而修改软件的过程称作适 应性维护。例如，适应性维护可以是将某个应用程序从 DOS环境移植到windows环境；将原来在VAX750机上 用Oracle的SQL实现的数据库移到Compaq机上；修改 程序使其适用于另外一种终端。
3
8.1.1 改正性维护（corrective maintenance） 改正性维护是在软件运行中发生异常或故障时进行 的维护工作。在软件交付使用后，由于开发时测试的不 彻底、不完全，必然会有一部分隐藏的错误被带到运行 阶段来。这些隐藏下来的错误在某些特定的使用环境下 会暴露出来。为了识别和纠正软件错误、改正软件性能 上的缺陷、排除实施中的误使用，应进行的诊断和改正 错误的过程，是改正性维护。例如，改正性维护可以是 改正原来程序中开关使用的错误；解决开发时未能测试 各种可能情况带来的问题；解决原来程序中遗漏处理文 件中最后一个记录的问题等。
1
8.1 软件维护的任务和分类
所谓软件维护就是在软件已经交付使用之后，为了 改正错误或满足新的需要而修改软件的过程。要求进行 软件维护的原因多种多样，归纳起来主要有4个原因： ①改正在特定的使用条件下暴露出来的一些潜在程 序错误或设计缺陷； ②因在软件使用过程中数据环境发生变化（例如， 某个事物处理代码发生改变）或运行环境发生变化（例 如，安装了新的硬件或操作系统），需要修改软件以适 应这种变化。
《软件工程》第8章_程序编码
例如一些目前可用的查询语言提供了自然语言接口，允
许用户给出的描述如“对东北地区和华北地区，使用最 近3年的实际销售额预测明年的销售前景”。绝大部分用 户都喜欢这种接口方式。
(2) 程序生成器：程序生成器代表更为复杂的一类 4GL，它只需很少的语句就能生成完整的第三代语言程 序，甚至是第五代程序语言，目前一般用于MIS系统、 菜单生成等方面。
机器语言由二进制的1、0指令代码组成的字 符串构成，机器语言属于低级语言。不同的 CPU具有不同的指令系统。由于机器语言是 二进制代码，这些代码不需要翻译，可以直 接被计算机识别和执行，因此用机器语言编 写的程序占用内存少，执行效率高。但机器 语言不直观，具有很多缺点，如难编写、难 修改、难维护，需要用户直接对存储空间进 行分配，编程效率极低。此外，由于不同的 机器有相应的一套机器语言，所以程序的可 移植性很差。
Java语言是于1995年由SUN公司推出的，是当今最流
行的新兴网络编程语言。 Java是一种简单的、面向对 象的、分布式的、功能强大的、安全的、解释的、高
效的、平台无关的、易移植的、多线程的、动态的编 程语言。 Java语法接近C++，但做了许多重大的修 改。它适用于Internet环境并具有较强的交互性和实时 性。它提供了对网络应用的支持和多媒体应用的支 持，推动了Internet和企业网络化应用的进步。
【本章重点】
许用户给出的描述如“对东北地区和华北地区，使用最 近3年的实际销售额预测明年的销售前景”。绝大部分用 户都喜欢这种接口方式。
(2) 程序生成器：程序生成器代表更为复杂的一类 4GL，它只需很少的语句就能生成完整的第三代语言程 序，甚至是第五代程序语言，目前一般用于MIS系统、 菜单生成等方面。
机器语言由二进制的1、0指令代码组成的字 符串构成，机器语言属于低级语言。不同的 CPU具有不同的指令系统。由于机器语言是 二进制代码，这些代码不需要翻译，可以直 接被计算机识别和执行，因此用机器语言编 写的程序占用内存少，执行效率高。但机器 语言不直观，具有很多缺点，如难编写、难 修改、难维护，需要用户直接对存储空间进 行分配，编程效率极低。此外，由于不同的 机器有相应的一套机器语言，所以程序的可 移植性很差。
Java语言是于1995年由SUN公司推出的，是当今最流
行的新兴网络编程语言。 Java是一种简单的、面向对 象的、分布式的、功能强大的、安全的、解释的、高
效的、平台无关的、易移植的、多线程的、动态的编 程语言。 Java语法接近C++，但做了许多重大的修 改。它适用于Internet环境并具有较强的交互性和实时 性。它提供了对网络应用的支持和多媒体应用的支 持，推动了Internet和企业网络化应用的进步。
【本章重点】
软件工程8
(2)分类性。 分类性是指将具有一致的数据结构(属性)和行为 (操作)的对象抽象成类。一个类就是这样一种抽 象，它反映了与应用有关的重要性质，而忽略其 他一些无关内容。任何类的划分都是主观的，但 必须与具体的应用有关。
• (3)继承性。 继承性是子类自动共享父类数据结构和方法的机制， 这是类之间的一种关系。在定义和实现一个类的时候， 可以在一个已经存在的类的基础之上来进行，把这个 已经存在的类所定义的内容作为自己的内容，并加入 若干新的内容。
• .在传统的数据库管理系统中增加面向对象的功能； • .在面向对象的编程语言中增加数据库的功能； • .开发全新的、自成体系的面向对象的数据库。
oodb是目前的一个研究热点，需要解决的问题既 有理论方面的也有技术方面的。
• 4、面向对象的软件开发环境
• 面向对象的软件开发环境的历史几乎和面 向对象的编程语言一样久远。第一个最有 影响的面向对象编程语言smalltalk-80同时 又是第一个面向对象的开发环境。其后出 现的环境有macintosh的macapp环境。 next计算机及环境、eiffel语言及环境等等。 然而在90年代，人们对面向对象的软件开 发环境寄予更高的希望 。
•
类中操作的实现过程叫做方法，一个方法有方法名、
参数、方法体。消息传递如图10-1所示。
面向对象方法
• 随着面向对象技术研究的不断发展和完善，自八 十年代以来，已经出现了几十种面向对象软件开 发方法，其中，Booch, Coad/Yourdon, OMT和 OOSE方法在面向对象软件开发界得到了广泛的认 可。每种方法都有一套自己的描述符号和实现过 程，每种方法都支持三种基本的活动：识别对象 和类，描述对象和类之间的关系，通过描述每个 类的功能定义对象的行为。
• (3)继承性。 继承性是子类自动共享父类数据结构和方法的机制， 这是类之间的一种关系。在定义和实现一个类的时候， 可以在一个已经存在的类的基础之上来进行，把这个 已经存在的类所定义的内容作为自己的内容，并加入 若干新的内容。
• .在传统的数据库管理系统中增加面向对象的功能； • .在面向对象的编程语言中增加数据库的功能； • .开发全新的、自成体系的面向对象的数据库。
oodb是目前的一个研究热点，需要解决的问题既 有理论方面的也有技术方面的。
• 4、面向对象的软件开发环境
• 面向对象的软件开发环境的历史几乎和面 向对象的编程语言一样久远。第一个最有 影响的面向对象编程语言smalltalk-80同时 又是第一个面向对象的开发环境。其后出 现的环境有macintosh的macapp环境。 next计算机及环境、eiffel语言及环境等等。 然而在90年代，人们对面向对象的软件开 发环境寄予更高的希望 。
•
类中操作的实现过程叫做方法，一个方法有方法名、
参数、方法体。消息传递如图10-1所示。
面向对象方法
• 随着面向对象技术研究的不断发展和完善，自八 十年代以来，已经出现了几十种面向对象软件开 发方法，其中，Booch, Coad/Yourdon, OMT和 OOSE方法在面向对象软件开发界得到了广泛的认 可。每种方法都有一套自己的描述符号和实现过 程，每种方法都支持三种基本的活动：识别对象 和类，描述对象和类之间的关系，通过描述每个 类的功能定义对象的行为。
软件工程作业8（含答案）
软件工程作业8（含答案）
1. 为了把握软件开发各个环节的正确性和协调性，人们需要进行（ A 2）和（ B 3 ）工作。（ A ）的目的是想证实在一给定的外部环境中软件的逻辑正确性。它包括（ C 2 ）和（ D 3 ），（ B ）则试图证明在软件生存期各个阶段，以及阶段间的逻辑（ E 3 ）、（ F 4 ）和正确性。
供选择的答案：
A, B. ①操作②确认③验证④测试⑤调试
C, D.①用户的确认②需求规格说明的确认
③程序的确认④测试的确认
E, F. ①可靠性②独立性③协调性④完备性⑤扩充性
2. 软件测试是软件质量保证的主要手段之一，测试的费用已超过（A 1）的30%以上。因此，提高测试的有效性十分重要。“高产”的测试是指（B 3 ）。根据国家标准GB 8566–88《计算机软件开发规范》的规定，软件的开发和维护划分为8个阶段，其中，单元测试是在（ C 5）阶段完成的，集成测试的计划是在（ D 3）阶段制定的，确认测试的计划是在（ E 2 ）阶段制定的。
供选择的答案：
A. ①软件开发费用②软件维护费用③软件开发和维护费用
④软件研制费用⑤软件生存期全部
B. ①用适量的测试用例运行程序，证明被测程序正确无误
②用适量的测试用例运行程序，证明被测程序符合相应的要求
③用少量的测试用例运行程序，发现被测程序尽可能多的错误
④用少量的测试用例运行程序，纠正被测程序尽可能多的错误
C ~ E. ①可行性研究和计划②需求分析③概要设计
④详细设计⑤实现⑥集成测试
⑦确认测试⑧使用和维护
3. 集成测试也叫做（ A 3）或（ B 6）。通常，在（ C 1）的基础上，将所有模块按照设计要求组装成为系统。子系统的集成测试特别
软件工程实验8
实验八 概要设计
一、实验目的
• 了解软件体系结构模型； • 掌握面向数据流的设计方法； • 掌握概要设计说明书的撰写。
二、实验原理
• ⑴软件概要设计的基本要点 • 基本目的是用比较抽象概括的方式确定系统 如何完成预定的任务，确定系统的物理配置 方案，确定系统的结构。 • ⑵系统分析与设计的关系 • 系统分析的基本任务是定义用户所需要的软 件任务，也就是回答系统必须“做什么”这 个问题。系统设计的基本任务是设计实现目 标系统的具体方案，也就是回答“怎样做” 这个问题。 • ⑶面向数据流的设计方法
三、Hale Waihona Puke Baidu验内容与步骤
• • • • ⑴软件体系结构模型 ⑵用面向数据流的方法设计系统软件结构 ⑶数据库逻辑结构设计 ⑷撰写概要设计说明书
五、分析与讨论
• 针对数据流图开展分析和讨论，如何划分 输入、输出流的边界，使得软件的结构更 加合理。 • 在对软件进行必要分解后，有时需要对其 中的若干模块再次进行分解和合并，请分 析和讨论什么情况下需要进行模块的再分 解或合并。
六、实验练习或思考题
• 根据大作业的选题，结合前一实验的需求 分析进行大作业软件的概要设计， • 撰写大作业软件的系统概要设计说明书。
一、实验目的
• 了解软件体系结构模型； • 掌握面向数据流的设计方法； • 掌握概要设计说明书的撰写。
二、实验原理
• ⑴软件概要设计的基本要点 • 基本目的是用比较抽象概括的方式确定系统 如何完成预定的任务，确定系统的物理配置 方案，确定系统的结构。 • ⑵系统分析与设计的关系 • 系统分析的基本任务是定义用户所需要的软 件任务，也就是回答系统必须“做什么”这 个问题。系统设计的基本任务是设计实现目 标系统的具体方案，也就是回答“怎样做” 这个问题。 • ⑶面向数据流的设计方法
三、Hale Waihona Puke Baidu验内容与步骤
• • • • ⑴软件体系结构模型 ⑵用面向数据流的方法设计系统软件结构 ⑶数据库逻辑结构设计 ⑷撰写概要设计说明书
五、分析与讨论
• 针对数据流图开展分析和讨论，如何划分 输入、输出流的边界，使得软件的结构更 加合理。 • 在对软件进行必要分解后，有时需要对其 中的若干模块再次进行分解和合并，请分 析和讨论什么情况下需要进行模块的再分 解或合并。
六、实验练习或思考题
• 根据大作业的选题，结合前一实验的需求 分析进行大作业软件的概要设计， • 撰写大作业软件的系统概要设计说明书。
软件工程第8章-面向对象建模
特殊需求：
系统必须在一秒内响应客户的输入
后置条件： （略）
复旦大学计算机科学技术学院 软件工程（第二版）
22
• 事件流可分为两部分：
➢ 基本路径
基本路径是运转正常时的路径，是一系列没 有分支和选择的简单陈述句
➢ 可选路径
可选路径是指不同于基本路径而允许不同的 事件序列的路径。
对于明显有可能随时发生的事情来说，可选 路径非常有效。
复旦大学计算机科学技术学院 软件工程（第二版）
25
五. 确定用况之间的关系
关系
说明
Байду номын сангаас记号
关联 执行者与他所参与的一个用况 之间的通信路径
扩展
扩展的用况到基本用况的一种 关系，它指出扩展的用况所定 义的行为如何插入到基本用况 所定义的行为中。扩展的用况 通过模块化方式增量地修改基 本用况
《extend》
•开发者：用况模型帮助他们理解系统要做什 么，同时为以后的其他模型建模、结构设计、 实现等提供依据
•集成测试和系统测试人员：根据用况来测试 系统，以验证系统是否完成了用况指定的功 能
复旦大学计算机科学技术学院 软件工程（第二版）
5
用况建模步骤
创建用况模型的步骤包括： 1．定义系统 2．确定执行者 3．确定用况 4．描述用况 5．定义用况间的关系 6．确认模型
《软件工程》第八章 软件维护与再工程
软件可维护性－提高可维护性的方法
使用提高软件质量的技术与工具
在进行软件设计时，采用如本书前面所述的模 块化程序设计、结构化程序设计等程序设计方 法，在软件开发过程中，采用结构化小组，建 立主程序小组，实现严格的组织化管理，职能 分工，规范标准，在对程序的质量进行检测时， 也可以采用分工合作的方法，这些方法会有效 地提高软件质量和检测效率，进而提高软件的 可维护性。
软件维护的概念－维护问题
和软件维护有关的部分问题 ：
理解别人的代码通常是非常困难的，而且难度 随着软件配置成分的缺失而迅速增加
需要维护的软件往往没有文档、或文档资料严 重不足、或软件的变化未在相应的文档中反映 出来
软件维护的概念－维护问题
当软件要求维护时，不能指望由原来的开发人 员来完成或提供软件的解释。由于维护持续时 间很长，因此当需要解释软件时候，往往开发 人员已经不在附近了 绝大多数软件在设计时没有考虑到将来的修改 问题 软件维护这项工作毫无吸引力。一方面是因为 软件维护，看不到什么“成果”，但工作量很 大，更重要的是维护工作难度大，软件维护人 员经常遭受挫折。
软件可维护性
可维护性（maintainability）
指理解、改正、调整和改进软件的难易程度。对 软件可维护性影响的主要因素有：可理解性 （understandability）、可测试性（testability）、 可修改性、modifiability）和可移植性 （portability）
软件工程导论习题及第8章讲义
12
(4) 维护过程中增加或删除一个源语句平均花 费的人时数； 费的人时数； 维护每种语言平均花费的人时数； (5) 维护每种语言平均花费的人时数； 一张维护要求表的平均周转时间； (6) 一张维护要求表的平均周转时间； 不同维护类型所占的百分比。 (7) 不同维护类型所占的百分比。
13
8.4 可维护性
2
维护种类： 维护种类：
1、改正性维护：对程序使用期间发现的程序错 、改正性维护： 误进行诊断和改正的过程； 诊断和改正的过程 17误进行诊断和改正的过程；占维护工作量1721%。 21%。
2、适应性维护：配合变化了的环境进行修改软 、适应性维护：配合变化了的环境进行修改 修改软 件的活动；占维护工作量18-25%。 件的活动； 18-25%。 3、完善性维护：满足用户在使用过程中提出增 、完善性维护：满足用户在使用过程中提出增 加新的功能或修改已有功能的建议而进行的改 加新的功能或修改已有功能的建议而进行的改 进工作； 50-66%。 进工作；占维护工作量50-66%。 4、预防性维护：为了改善未来的可维护性或可 改善未来的可维护性或可 、预防性维护：为了改善未来的可维护性 靠性而修改软件的工作； 4%左右 左右。 靠性而修改软件的工作；占维护工作量4%左右。
3
8.2 维护的特点
一. 维护方式
方式 结构化维护 非结构化维护 仅有程序代码 评价代码开始 软件结构、全程 软件结构、 数据结构、系统 数据结构、 接口、性能要求、 接口、性能要求、 设计约束等具体 特点不清楚 不清楚而很 特点不清楚而很 难确定。 难确定。 很高 维护困难
软件工程 8
而且应该为高级用户提供简捷的操作方法。
8.4 任务管理子系统设计
•
•
软件系统是完成系统任务的一个逻辑实体。在软件系统所完成的任务中，有些
任务是顺序完成的，而有些任务必须以并发交替的方式完成。 用传统方法设计的软件系统，其任务的执行方式多是顺序的。因此其任务管理 的功能可以很简单。而在面向对象的软件系统中，一个任务的完成可能需要多 个对象以并发交互的方式协同配合。这个并发任务的执行过程可以通过分析阶 段的动态模型来识别和确认。
系统数据存储设计。主要确定系统中各个数据对象的存储和访问方式，
包括数据结构、文件、数据库等。这项设计依赖于所采用的数据支持系统， 如：文件系统、数据库管理系统等。
系统资源访问设计。主要确定系统中需要使用的各种类型的资源以及实现
这些资源的访问和控制机制、安全性机制的设计。 网络与分布设计。在网络环境下运行一个面向对象系统，还应考虑网络流 量、分布式计算单元的计算能力和系统的总体效率的综合平衡设计。这对于 系统总体效能的发挥有重要作用。
类的结构应尽量简明，层次深度应适当
• 定义类的结构，不要太过复杂。一是结构层次的分解应当有度；二是 类的属性不要太多。属性过多通常表明这个类过于复杂，它所承担的系 统责任可能更多，应当分解它；三是分配给每个类完成的任务也应该简 单，并尽量简化对象之间的合作关系，如果完成一项任务需要太多的对 象协同配合，可能会破坏类的简明性和清晰性；四是类中提供的服务应 当少而精。 •在大型软件系统开发中，类的大小和数量二者会呈现翘翘板现象，这同 样会带来一定的复杂性。解决这个问题的办法，是把系统中的类按逻辑 分组，也就是划分“主题”。
软件工程第8章 设计基础
• 2抽象与细化 • 抽象是控制复杂性的策略之一。由高级抽象到低级抽象的转换过 程中，要进过程抽象和数据抽象。 • 细化的实质是分解。强调分解的“逐步”性质，利于验证。
• 3
信息隐藏
• 模块内部的数据与过程，对不需要了解这些数据与过程的模块隐 6 藏来，只有一些必须的信息才在模块间进行传传递。
8.2.2
29
结构图
30
结构图
31
模块的扇出和扇出
• 模块的扇出:模块直接控制(调用)的模块总数. • 扇出过大意味着模块过分复杂,需要控制和协调 过多的下级模块;扇出(例如总是1)过小,也不好. • 经验表明,一个设计得好的典型系统的平均扇出 通常是3或4(扇出的上限通常是5~9). • 模块的扇入:表明有多少个上级模块直接调用它, 扇入越大则共享该模块的上级模块数目越多,这 是有好处的.但是,不能违背模块独立原理单纯追 求高扇入.
18
如何降低模块间耦合度？ • (1) 如模块必须存在耦合，选择适当的耦合
c
类型，原则： –尽量使用数据耦合 –少用控制耦合 –限制公共耦合的范围 –坚决避免使用内容耦合
• (2) 降低模块间接口的复杂性
19
模块内聚
内聚是模块内部聚合能力的量度
c
20
功能内聚 (Functional Cohesion)
9
3、模块的独立性(module independence)
• 3
信息隐藏
• 模块内部的数据与过程，对不需要了解这些数据与过程的模块隐 6 藏来，只有一些必须的信息才在模块间进行传传递。
8.2.2
29
结构图
30
结构图
31
模块的扇出和扇出
• 模块的扇出:模块直接控制(调用)的模块总数. • 扇出过大意味着模块过分复杂,需要控制和协调 过多的下级模块;扇出(例如总是1)过小,也不好. • 经验表明,一个设计得好的典型系统的平均扇出 通常是3或4(扇出的上限通常是5~9). • 模块的扇入:表明有多少个上级模块直接调用它, 扇入越大则共享该模块的上级模块数目越多,这 是有好处的.但是,不能违背模块独立原理单纯追 求高扇入.
18
如何降低模块间耦合度？ • (1) 如模块必须存在耦合，选择适当的耦合
c
类型，原则： –尽量使用数据耦合 –少用控制耦合 –限制公共耦合的范围 –坚决避免使用内容耦合
• (2) 降低模块间接口的复杂性
19
模块内聚
内聚是模块内部聚合能力的量度
c
20
功能内聚 (Functional Cohesion)
9
3、模块的独立性(module independence)
《软件工程》第八章软件测试
第八章 软件测试
8.1 软件测试的基本概念 8.2 软件测试方法
8.3 测试用例的设计 8.4 软件测试的步骤 8.5 调试 8.6 软件可靠性 8.7 测试工具
退出
8.1 软件测试的基本概念
8.1.1 软件测试的定义 8.1.2 软件测试的基本原则 8.1.3 软件测试的步骤 8.1.4 软件测试的信息流计 退出
2、确定测试用例
划分出等价类后，根据以下原则设计测试用例： （1）为每个等价类编号。 （2）设计一个新的测试用例，使它能包含尽可能多wk.baidu.com 尚未被覆盖的有效等价类。重复这一过程，直到所有的有效 等价类都被覆盖。 （3）设计一个新的测试用例，使它包含一个尚未被覆 盖的无效等价类。重复这一过程，直到所有的无效等价类都 被覆盖。
黑盒测试不可能实现穷尽测试：
假设有一个很简单的小程序，输入量只有两个：A和 B，输出量只有一个：C。如果计算机的字长为32位，A 和B的数据类型都只是整数类型。利用黑盒法进行测试时， 将A和B的可能取值进行排列组合，输入数据的可能性有： 232×232 ＝264 种。假设这个程序执行一次需要1毫秒，要 完成所有的测试，计算机需要连续工作5亿年。显然，这 是不能容忍的，而且，设计测试用例时，不仅要有合法 的输入，而且还应该有非法的输入，在这个例子中，输 入还应该包括实数、字符串等，这样，输入数据的可能 性就更多了。所以说，穷尽测试是不可能实现的。
8.1 软件测试的基本概念 8.2 软件测试方法
8.3 测试用例的设计 8.4 软件测试的步骤 8.5 调试 8.6 软件可靠性 8.7 测试工具
退出
8.1 软件测试的基本概念
8.1.1 软件测试的定义 8.1.2 软件测试的基本原则 8.1.3 软件测试的步骤 8.1.4 软件测试的信息流计 退出
2、确定测试用例
划分出等价类后，根据以下原则设计测试用例： （1）为每个等价类编号。 （2）设计一个新的测试用例，使它能包含尽可能多wk.baidu.com 尚未被覆盖的有效等价类。重复这一过程，直到所有的有效 等价类都被覆盖。 （3）设计一个新的测试用例，使它包含一个尚未被覆 盖的无效等价类。重复这一过程，直到所有的无效等价类都 被覆盖。
黑盒测试不可能实现穷尽测试：
假设有一个很简单的小程序，输入量只有两个：A和 B，输出量只有一个：C。如果计算机的字长为32位，A 和B的数据类型都只是整数类型。利用黑盒法进行测试时， 将A和B的可能取值进行排列组合，输入数据的可能性有： 232×232 ＝264 种。假设这个程序执行一次需要1毫秒，要 完成所有的测试，计算机需要连续工作5亿年。显然，这 是不能容忍的，而且，设计测试用例时，不仅要有合法 的输入，而且还应该有非法的输入，在这个例子中，输 入还应该包括实数、字符串等，这样，输入数据的可能 性就更多了。所以说，穷尽测试是不可能实现的。
软件工程第8章 Web软件工程
后端服务器
02
17
17
8.2 Web的层次结构
8.2.1 两层C/S结构
客户机和服务器通过网络连接。图8-2所示为二 层C/S结构的数据处理流程图。客户机通过Web浏览 器向服务器发出请求，服务器处理后将结果返回给客 户浏览器端。在整个处理过程中，无论是胖客户机模 型还是瘦客户机模型，都必须将任务映射到两个系统 上，即客户端和服务器端。
来自百度文库
软
以上。对于基于Web的应用程序来说，常在客户端采用Java Applet（Java写的小程序）和
件 JavaScript（Java脚本语言）两种技术，在服务器端采用Servlet和动态网页技术标准JSP两种技
工 程
术。Servlet可以产生超文本标记语言（HTML）。HTML页面的Java代码由Web服务器管理，代
软件 工程
8 Web软件工程
Web 软件工程
随着网络技术的不断发展，应用Web（网页）的系统越来越多，Web在很多领域都有着巨
大的需求。基于Web的应用是指使用Internet浏览器管理用户界面所表现的内容，而业务逻辑和
数据库都部署在服务器上。
Web
典型的基于Web系统的组件至少部署在三层（即Web客户端、Web服务器和数据库服务器）
Web
本章从基于Web应用的角度，探讨和介绍Web系统的设计模式，并分析基于Web的系统和 应用（WebApp）设计的6个主要步骤。 界面设计：创建定义用户界面的总体布局和交互机制； 美学设计：建立最终用户所关注的外观和感觉； 内容设计：将从分析模型中获取的信息作为设计内容对象及它们之间的关系基础； 软 体系结构设计：重点关注所有内容对象和功能的总体超媒体结构； 件 工 构件设计：表示了WebApp功能元素的详细内部结构； 程 导航设计：定义最终用户是怎样对超媒体结构进行导航的。 本章最后介绍了WebApp的测试方法。 ★ 本章重点：Web的层次结构；Web的客户端和服务器所使用的技术；Web软件的设计模式， 模型－视图－控制器模式；WebApp设计方法；WebApp测试方法。
软件工程试题与答案（8）
软件工程试题与答案（8）
软件工程试题
一、简述题（4 * 10 = 40）
1 简述生命周期方法学及其特点。
2 什么是软件过程？简述RUP及其特点。
3 简述面向对象的基本思想。
4 简述控制软件复杂性的基本方法。
二、判断题（判断命题正确与否，如错误，请改正）（10 * 2 = 20）
1 （）在建立了设计模型之后，就可以开始制定测试计划。
2 （）耦合是指一个模块内各个元素彼此结合的紧密程度。
3 （）数据流程图是描绘物理系统的传统工具。
4 （）软件工程标准有5个不同的级别层次：国际标准、国家标准、行业标准、企业规范、项目规范。
5 （）软件重用是指在软件开发过程中重复使用相同或相似软件元素的过程。
6 （）模块的独立程度可以由两个定性标准度量，这两个标准分别称为内聚和耦合。
7 （）如果测试数据满足条件覆盖，则必然满足判定覆盖。
8 （）软件开发模型是跨越整个软件生命周期的系统开发、运作、维护所实施的全部工作和任务的结构框架。
9 （）能力成熟度模型是评价程序员程序设计能力的一种全面而客观的评审依据。
10（）好的测试具有较高的发现错误的可能性。
三、选择题（将正确的答案代号填入括号中，每小题2分，共20分）
1．需求分析阶段最重要的技术文档是（）
A．设计说明书 B．需求规格说明书
C．可行性分析报告 D．用户手册
2．所谓软件过程的里程碑，通常是指（）。
A．一定的时间间隔 B．每个项目活动 C．基线 D．开发项目月报3．耦合度最高的是（）耦合。
A．环境 B．内容 C．控制 D．数据
4．软件工程学中除重视软件开发的研究外，另一个重要的组成内容是软件的（）。
软件工程第八章(维护)
4、预防性维护
预防性维护是为了提高软件的可维护 性、可靠性等，为以后进一步改进软 件打下良好基础。 预防性维护定义为：采用先进的软件 工程方法对需要维护的软件或软件中 的某一部分（重新）进行设计、编制 和测试。 在整个维护活动中，预防性维护占很 小的比例，只占5%。
综述
在整个软件维护阶段所花费的全部工作量中 ，完善性维护占了几乎一半的工作量。
三．维护的问题 与软件维护有关的绝大多数问题，都可归因于 软件定义和软件开发的方法有缺点。
在软件生命周期的头两个时期没有严格而又科 学的管理和规划，几乎必然会导致在最后阶段 出现问题。
8.2 维护的特点
和软件维护有关的部分问题：
理解别人写的程序通常非常困难，而且困难程度随着 软件配置成分的减少而迅速增加。如果仅有程序代码 没有说明文档，则会出现严重的问题。
8.2 维护的特点
绝大多数软件在设计时没有考虑将来的修改。除非使 用强调模块独立原理的设计方法论，否则修改软件既 困难又容易发生差错。 软件维护不是一项吸引人的工作。形成这种观念很大 程度上是因为维护工作经常遭受挫折。
8.3 软件维护过程
维护过程本质上是修改和压缩了的软件定义和开 发过程。 为了有效地进行软件维护，应事先就开始做组织 工作。 首先建立一个维护组织 确定报告及评价的过程
软件工程第八章
软件工程第八章
第8章软件维护
软件投入使用后就进入软件维护阶段。维护阶段是软件生存周期中时间最长的一个阶段，所花费的精力和费用也是最多的一个阶段。
8.1软件维护的内容
软件维护内容有四种：校正性维护，适应性维护，完善性维护和预防性维护。
1.校正性维护
在软件交付使用后，由于在软件开发过程中产生的错误并没有完全彻底的在测试中发现，因此必然有一部分隐含的错误被带到维护阶段来。这些隐含的错误在某些特定的使用环境下会暴露出
来。为了识别和纠正错误，修改软件性能上的缺陷，应进行确定和修改错误的过程，这个过程就称为校正性维护。校正性维护占整个维护工作的20%左右。
2.适应性维护
随着计算机的飞速发展，计算机硬件和软件环境也在不断发生变化，数据环境也在不断发生变化。为了使应用软件适应这种而修改软件的过程称为适应性维护。这种维护活动占整个维护活动的25%。
3.完善性维护
在软件漫长的运行时期中，用户往往会对软件提出新的功能要求与性能要求。这是因为用户的业务会发生变化，组织机构也会发生变化。为了适应这些变化，应用软件原来的功能和性能需要扩充和增强，为达到这个目的而进行的维护活动称为完善性维护，占整个维护活动的50%。
4.预防性维护
为了提高软件的可维护性和可靠性而对软件进行的修改称为预防性维护。这是为以后进一步的运行和维护打好基础，占整个维护工作的4%。
8.2 维护的特点
8.2.1非结构化维护和结构化维护
软件的开发过程对软件的维护过程有较大的影响。若不采用软件过程的方法开发软件，则软件只有程序而无文档，维护工作非常难，这就是一种非结构化的维护。若采用软件工程的方法开发软件，则各阶段都有相应的文档，这容易进行维护工作，这是一种结构化的维护。
相关主题
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
在分析和设计期间，用例模型经分析模型转化为设计模 型。简单地说，分析模型和设计模型都是由类元(Classifier) 和说明如何实现用例的集合组成的。类元是一种描述行为和 结构特征的模型元素，它具有属性和操作，可以用状态图描 述，有的还可以实例化、参与协作等。类元的种类包括类、 行为、构件、数据类型、接口、节点、信号、子系统以及用 例。其中，类是最常见的类元。
第8章 用例驱动
分析模型也是一种模型，是需求的详细规格说明，可作 为设计模型的切入点。分析模型可能是暂时的，只存在于前 几次迭代中，然而，在某些情况下，尤其对于大型、复杂系 统，分析模型会存在于系统的整个生命周期。这种情况下， 分析模型的用例实现与设计模型中相应的用例实现之间存在 一种无缝的跟踪依赖关系，分析模型中每个元素都可以从实 现它的设计模型元素中跟踪到。
第8章 用例驱动
开发人员以用例模型为输入来创建分析模型。用例模型 中的每个用例都实现为分析模型中的用例实现，用例和用例 实现的依赖性支持需求和分析之间的无缝可跟踪性。通过对 用例进行处理，开发人员可以确定参与实现用例的类，例如， “取款”用例可以通过分析“取款”类、“账户”类、“分 配”类及其他无需在此标识的类来实现。开发人员将用例中 定义的职责分配为类的职责，因此“账户”类包括诸如“从 账户上提取一定数额的现金”的职责。这样，就可以得到一 个类的集合，合在一起就能实现用户所需的用例。
第8章 用例驱动
8.2 为什么使用用例
在软件开发中，很常见的问题是许多客户不知道他们需 要什么，进一步来讲，即便客户真正了解他们需要什么，也 有可能很难精确地把这些想法传达给开发者，因为大多数客 户的计算机知识不如开发团队的成员。对开发人员来说，对 软件产品及其功能进行形象化描述已经很难了，对并不精通 软件工程的客户来说则更加困难。
开发人员把设计好的类实现为实现模型中的构件(源代 码)集合，能够产生(即编译和连接)如DLL、JavaBeans和 ActiveX等可执行代码，用例有助于开发人员确定实现和集 成构件的次序。
第8章 用例驱动
在测试工作流期间，测试人员验证系统确实能够实现用 例描述的功能并满足系统需求。测试模型包含测试用例，测 试用例是测试数据集，定义了输入、运行条件和结果的集合。 许多测试用例直接从用例得到。因此，在测试用例和相应的 用例之间存在跟踪依赖关系，这意味着测试人员将验证系统 能够做用户需要的事，即能够执行用例。
第8章 用例驱动
第8章 用例驱动
8.1 用例驱动开发概述 8.2 为什么使用用例 8.3 确定客户需要什么 8.4 需求工作流 8.5 领域模型 8.6 业务模型 8.7 补充需求 8.8 初始需求 8.9 初始需求：考勤系统实例研究 8.10 继续需求流：考勤系统实例研究 8.11 修订需求：考勤系统实例研究 8.12 测试工作流：考勤系统实例研究 8.13 需求规格说明书 8.14 小结 习题８
第8章 用例驱动
设计模型具有下面的特点： 设计模型是有层次的，也包括跨层次的关系，这些关 系在UML中很常见：关联、泛化和依赖等； 用例实现是协作的构造型，协作表示类元在做某件事 情(如实现用例)时如何参与和扮演角色； 设计模型是实现的蓝图，设计模型的子系统和实现模 型的构件之间存在直接的映射关系。
第8章 用例驱动
8.1 用例驱动开发概述
在需求工作流中，开发者必须确定什么样的软件是客户 想要的。因此，需求捕获有两个目标：发现真正的需求，并 以适合于用户、客户和开发人员的方式加以描述。“真正的 需求”是指在实现时可以给用户带来预期价值的需求，但是， 很多客户不知道他们需要什么．
第8章 用例驱动
第8章 用例驱动
统一过程(UP)的核心思想是用例驱动、以构架为中心的 迭代和增量开发。图8-1描述了统一过程中的一系列工作流 和模型。从机器解释的角度看，实现模型是最形式化的，而 用例模型的形式化成分最少。也就是说，部分实现模型可以 通过编译和连接成为可执行代码，而用例模型主要用自然语 言来描述。
wenku.baidu.com
第8章 用例驱动
开发人员设计类和用例实现，以便更充分地应用相关的 产品和技术(如对象请求代理、图形用户界面、构造工具和 数据库管理系统等)来实现系统。根据子系统对设计类进行 分组，并定义子系统间的接口。开发人员还要进一步建立实 施模型，其中包括定义在计算节点上的系统的物理结构，以 验证用例能够实现并能在节点上运行。
第8章 用例驱动
知识点 需求工作流，领域模型，业务模型，建模技术。
难点 如何将理论与实践结合。
基于工作过程的教学任务 通过本章学习，了解为什么使用用例，学习用例驱动开
发的基本概念；确定客户需要什么，掌握需求工作流的基本 过程；理解领域模型、业务模型对需求的作用，掌握相关的 建模技术；以考勤系统为例，全面展示需求工作流的工作过 程；了解考勤系统的测试工作流。
“以适合于用户、客户和开发人员的方式”主要是指对需求 的最后描述必须能够让用户和客户理解，但是，即便客户真 正了解他们需要什么，也有可能很难精确地把其想法传达给 开发者，因为大多数客户的计算机知识不如开发团队的成员。 这也是需求工作流的难点之一。
第8章 用例驱动
系统通常有多种用户，每种用户都是一个参与者，参与 者使用系统与用例进行交互，用例是系统向参与者提供某些 有价值结果而执行的动作序列，即某种功能，参与者和用例 构成用例模型。
第8章 用例驱动
需求 分析 设计 实现 测试
用例模型 分析模型 设计模型 实施模型 实现模型 测试模型
图8-1 统一过程从需求到测试的一系列工作流
第8章 用例驱动
用例常用于捕获软件系统(尤其是基于构件的系统)的需 求。用例不只是捕获需求的工具，还能够驱动整个开发过程。 在寻找和确定类、子系统和接口时，在寻找并确定测试用例 时，在规划开发迭代和系统集成时，用例都将作为主要输入。 对每次迭代，用例驱动完成一整套工作流(从需求捕获，经 过分析、设计和实现，最后到测试)，并将这些不同的工作 流集成在一起。
第8章 用例驱动
分析模型也是一种模型，是需求的详细规格说明，可作 为设计模型的切入点。分析模型可能是暂时的，只存在于前 几次迭代中，然而，在某些情况下，尤其对于大型、复杂系 统，分析模型会存在于系统的整个生命周期。这种情况下， 分析模型的用例实现与设计模型中相应的用例实现之间存在 一种无缝的跟踪依赖关系，分析模型中每个元素都可以从实 现它的设计模型元素中跟踪到。
第8章 用例驱动
开发人员以用例模型为输入来创建分析模型。用例模型 中的每个用例都实现为分析模型中的用例实现，用例和用例 实现的依赖性支持需求和分析之间的无缝可跟踪性。通过对 用例进行处理，开发人员可以确定参与实现用例的类，例如， “取款”用例可以通过分析“取款”类、“账户”类、“分 配”类及其他无需在此标识的类来实现。开发人员将用例中 定义的职责分配为类的职责，因此“账户”类包括诸如“从 账户上提取一定数额的现金”的职责。这样，就可以得到一 个类的集合，合在一起就能实现用户所需的用例。
第8章 用例驱动
8.2 为什么使用用例
在软件开发中，很常见的问题是许多客户不知道他们需 要什么，进一步来讲，即便客户真正了解他们需要什么，也 有可能很难精确地把这些想法传达给开发者，因为大多数客 户的计算机知识不如开发团队的成员。对开发人员来说，对 软件产品及其功能进行形象化描述已经很难了，对并不精通 软件工程的客户来说则更加困难。
开发人员把设计好的类实现为实现模型中的构件(源代 码)集合，能够产生(即编译和连接)如DLL、JavaBeans和 ActiveX等可执行代码，用例有助于开发人员确定实现和集 成构件的次序。
第8章 用例驱动
在测试工作流期间，测试人员验证系统确实能够实现用 例描述的功能并满足系统需求。测试模型包含测试用例，测 试用例是测试数据集，定义了输入、运行条件和结果的集合。 许多测试用例直接从用例得到。因此，在测试用例和相应的 用例之间存在跟踪依赖关系，这意味着测试人员将验证系统 能够做用户需要的事，即能够执行用例。
第8章 用例驱动
第8章 用例驱动
8.1 用例驱动开发概述 8.2 为什么使用用例 8.3 确定客户需要什么 8.4 需求工作流 8.5 领域模型 8.6 业务模型 8.7 补充需求 8.8 初始需求 8.9 初始需求：考勤系统实例研究 8.10 继续需求流：考勤系统实例研究 8.11 修订需求：考勤系统实例研究 8.12 测试工作流：考勤系统实例研究 8.13 需求规格说明书 8.14 小结 习题８
第8章 用例驱动
设计模型具有下面的特点： 设计模型是有层次的，也包括跨层次的关系，这些关 系在UML中很常见：关联、泛化和依赖等； 用例实现是协作的构造型，协作表示类元在做某件事 情(如实现用例)时如何参与和扮演角色； 设计模型是实现的蓝图，设计模型的子系统和实现模 型的构件之间存在直接的映射关系。
第8章 用例驱动
8.1 用例驱动开发概述
在需求工作流中，开发者必须确定什么样的软件是客户 想要的。因此，需求捕获有两个目标：发现真正的需求，并 以适合于用户、客户和开发人员的方式加以描述。“真正的 需求”是指在实现时可以给用户带来预期价值的需求，但是， 很多客户不知道他们需要什么．
第8章 用例驱动
第8章 用例驱动
统一过程(UP)的核心思想是用例驱动、以构架为中心的 迭代和增量开发。图8-1描述了统一过程中的一系列工作流 和模型。从机器解释的角度看，实现模型是最形式化的，而 用例模型的形式化成分最少。也就是说，部分实现模型可以 通过编译和连接成为可执行代码，而用例模型主要用自然语 言来描述。
wenku.baidu.com
第8章 用例驱动
开发人员设计类和用例实现，以便更充分地应用相关的 产品和技术(如对象请求代理、图形用户界面、构造工具和 数据库管理系统等)来实现系统。根据子系统对设计类进行 分组，并定义子系统间的接口。开发人员还要进一步建立实 施模型，其中包括定义在计算节点上的系统的物理结构，以 验证用例能够实现并能在节点上运行。
第8章 用例驱动
知识点 需求工作流，领域模型，业务模型，建模技术。
难点 如何将理论与实践结合。
基于工作过程的教学任务 通过本章学习，了解为什么使用用例，学习用例驱动开
发的基本概念；确定客户需要什么，掌握需求工作流的基本 过程；理解领域模型、业务模型对需求的作用，掌握相关的 建模技术；以考勤系统为例，全面展示需求工作流的工作过 程；了解考勤系统的测试工作流。
“以适合于用户、客户和开发人员的方式”主要是指对需求 的最后描述必须能够让用户和客户理解，但是，即便客户真 正了解他们需要什么，也有可能很难精确地把其想法传达给 开发者，因为大多数客户的计算机知识不如开发团队的成员。 这也是需求工作流的难点之一。
第8章 用例驱动
系统通常有多种用户，每种用户都是一个参与者，参与 者使用系统与用例进行交互，用例是系统向参与者提供某些 有价值结果而执行的动作序列，即某种功能，参与者和用例 构成用例模型。
第8章 用例驱动
需求 分析 设计 实现 测试
用例模型 分析模型 设计模型 实施模型 实现模型 测试模型
图8-1 统一过程从需求到测试的一系列工作流
第8章 用例驱动
用例常用于捕获软件系统(尤其是基于构件的系统)的需 求。用例不只是捕获需求的工具，还能够驱动整个开发过程。 在寻找和确定类、子系统和接口时，在寻找并确定测试用例 时，在规划开发迭代和系统集成时，用例都将作为主要输入。 对每次迭代，用例驱动完成一整套工作流(从需求捕获，经 过分析、设计和实现，最后到测试)，并将这些不同的工作 流集成在一起。