第7章SEI软件工程环境
- 格式：ppt
- 大小：1.85 MB
- 文档页数：61
下载文档原格式
合集下载
软件工程第7章 软件维护与再工程
在测试结束时进行最正式的可维护性复审，这个复审 称为配置复审。配置复审的目的是保证软件配置的所 有成分是完整的、一致的和可理解的，而且为了便于 修改和管理已经编目归档了。
3. 软件维护实施
开发组可承担软件初期维护，但当软件转入正 常使用以后，其维护工作则一般由专门的维护 机构承担。软件维护机构人员组成有：维护负 责人、系统监督员、配置管理员、维护工程师。 其中，维护负责人全权负责维护任务，包括技 术与管理两个方面的工作。
4. 软件再工程
软件再工程是指对已存在软件系统的重构与扩 充。
再工程主要用于一些老系统改造，所涉及活动 有：逆向工程、重构工程、正向工程。
典型的软件再工程过程模型如下图所示。在某些情况下这 些活动以线性顺序发生，但也并非总是这样。例如，为了理 解某个程序的内部工作原理，可能在文档重构开始之前必须 先进行逆向工程。
在维护活动开始之前就明确维护 责任是十分必要的，这样做可以大大 减少维护过程中可能出现的混乱。
维护管理员
转交维护要求
系统管理员
评价后上交， 促成决定活动
指定维护人员
程序技术人员
变化授权人
2. 维护报告
应该用标准化的格式表达所有软件维护要求。 软件维护人员通常给用户提供空白的维护要求表—— 有时称为软件问题报告表，这个表格由要求一项维护活动 的用户填写。如果遇到了一个错误，那么必须完整描述导 致出现错误的环境(包括输入数据、全部输出数据以及其他 有关信息)。 对于适应性或完善性的维护要求，应该提出一个简短 的需求说明书。如前所述，由维护管理员和系统管理员评 价用户提交的维护要求表。
哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供 的反馈信息对有效地管理软件组织十分重要。
3. 软件维护实施
开发组可承担软件初期维护，但当软件转入正 常使用以后，其维护工作则一般由专门的维护 机构承担。软件维护机构人员组成有：维护负 责人、系统监督员、配置管理员、维护工程师。 其中，维护负责人全权负责维护任务，包括技 术与管理两个方面的工作。
4. 软件再工程
软件再工程是指对已存在软件系统的重构与扩 充。
再工程主要用于一些老系统改造，所涉及活动 有：逆向工程、重构工程、正向工程。
典型的软件再工程过程模型如下图所示。在某些情况下这 些活动以线性顺序发生，但也并非总是这样。例如，为了理 解某个程序的内部工作原理，可能在文档重构开始之前必须 先进行逆向工程。
在维护活动开始之前就明确维护 责任是十分必要的，这样做可以大大 减少维护过程中可能出现的混乱。
维护管理员
转交维护要求
系统管理员
评价后上交， 促成决定活动
指定维护人员
程序技术人员
变化授权人
2. 维护报告
应该用标准化的格式表达所有软件维护要求。 软件维护人员通常给用户提供空白的维护要求表—— 有时称为软件问题报告表，这个表格由要求一项维护活动 的用户填写。如果遇到了一个错误，那么必须完整描述导 致出现错误的环境(包括输入数据、全部输出数据以及其他 有关信息)。 对于适应性或完善性的维护要求，应该提出一个简短 的需求说明书。如前所述，由维护管理员和系统管理员评 价用户提交的维护要求表。
哪些维护资源是应该有而事实上却没有的? 对于这项维护工作什么是主要的(以及次要的)障碍? 要求的维护类型中有预防性维护吗? 处境复查对将来维护工作的进行有重要影响，而且所提供 的反馈信息对有效地管理软件组织十分重要。
软件工程-第7章第1节
7.1.2 瀑布模型的特点
在这种严格定义的模型中，开发人员试图在每一活 动过程结束后，通过严格的阶段性复审与确认，得 到该阶段的一致、完整、准确和无二义性的良好文 档，以“冻结”这些文档为该阶段结束的标志，保 持不变，作为下一阶段活动的唯一基础，从而形成 一个理想的线性开发序列，以每一步的正确性和完 整性来保证最终系统的质量。
要求定义 确认
需求说明书
设计 确认
设计说明书
编码 确认
源程序清单
测试 确认
测试报告
维护 确认软件维护报告源自7.1.2 瀑布模型的特点
瀑布模型严格按照生存周期各个阶段的目标、任务、文档和要求来进行 开发。它强调了每一阶段的严格性，尤其是开发前期的良好需求说明， 这样，就能解决在开发阶段后期修正不完善的需求说明将花费巨大的费 用的问题。于是人们需付出很大的努力来加强各阶段活动的严格性，特 别是要求定义阶段，希望得到完整、准确、无二义性的需求说明，以减 少后面各阶段不易估量的浪费。在传统的观念中，人们认为只要认真努 力，总可以通过详尽分析来确定完整、准确的需求说明，从而明确系统 的各种需求，只要采用一套严格规定的术语及表达方式，就一定可以准 确清楚地表达和通讯，以便在严格的开发管理下得到完美的结果。
7.1.2 瀑布模型的特点
瀑布模型是以文档形式驱动的，为合同双方最终确认的产品规定了蓝本，为管 理者进行项目开发管理提供了基础，为开发过程施加了“政策”或纪律限制， 约束了开发过程中的活动。 瀑布模型以里程碑开发原则为基础，提供各阶段的检查点，确保用户需求，满 足预算和时间限制。 瀑布模型是一种整体开发模型，在开发过程中，用户看不见系统是什么样，只 有开发完成，向用户提交整个系统时，用户就能看到一个完整的系统。 瀑布模型适合于功能和性能明确、完整、无重大变化的软件开发。大部分的系 统软件就具有这些特征，例如编译系统、数据库管理系统和操作系统等。在开 发前均可完整、准确、一致和无二义性地定义其目标、功能和性能等。
软件工程环境
软件工程环境软件工程环境是软件工程学的组成部分,也是实现软件生产工程化的重要基础。
“工欲善其事,必先利其器”,在软件开发中,无论技术活动与管理活动,都离不开环境(包括工具）的支持。
近20多年来,各技术先进国家大力开展软件环境的研究,计算机辅助软件工程( computer-aided software engineering,简称CASE)、集成化项目支持环境(Integrated Project Support Environment，简称IPSE)等课题,始终都受到人们的关注,一大批实用的环境应运而生。
这些环境建立在现代软件开发的基础上,反过来又促进了现代方法的推广与流行,不仅提高了软件的生产率,而且逐渐影响和改变着软件的生产方式。
本章将简要叙述软件工程环境的变迁、现状和发展趋势,使读者进一步了解学习和研究软件工程环境的意义。
13.1什么是软件工程环境“环境”一词,对不同的用户往往具有不同的含义。
对于不从事软件开发的最终用户( end-user)来说,环境就是他运行程序所使用的计算机—由硬件和操作系统所组成的虚拟机。
这类用户对环境的要求,主要是运行可靠、操作容易,便于掌握和使用。
对于开发者来说,环境是他们进行开发活动的重要舞台。
在软件工程时代,开发者要求环境支持他们按照软件工程的方法,全面完成生存周期中的各项任务。
通常把这种开发环境称为软件工程环境,而把前一类环境称为运行环境或工作环境。
具体而言,软件工程环境是指支持软件产品开发、维护和管理的软件系统,它在统一的集成机制下由一系列软件工具组成。
这些工具对与软件开发相关的过程、活动和任务提供全面的支持,从而大大提高软件产品的生产效率和软件产品的质量,降低软件开发、维护和管理的成本。
这类环境通常都有一套包括数据集成、控制集成和界面集成的集成机制,让各个工具使用统一的、规范存取的环境信息仓库,采用统一的用户界面,同时为各个工具或开发活动之间的通信、切换、调度和协同工作提供支持。
第7章计算机软件开发软件工程
计算机科学与技术系
计算机科学与技术总论
二、软件工程的基本原则
6、软件测试
计算机科学与技术系
计算机科学与技术总论
6.1 程序测试的基本概念
测试是软件开发的最后一个阶段，是保 证软件质量的重要环节，它是对需求分 析、设计和编码的最后复审，通过测试 可以发现和纠正软件中的错误，以保证 软件的可靠性。
计算机科学与技术系
计算机科学与技术系
计算机科学与技术总论
一、软件工程概念
❖ Boehm：运用现代科学技术知识来设计并构造 计算机程序及为开发、运行和维护这些程序 所必需的相关文件资料。
❖ IEEE：软件工程是开发、运行、维护和修复 软件的系统方法。
❖ Fritz Bauer：建立并使用完善的工程化原则， 以较经济的手段获得能在实际机器上有效运 行的可靠软件的一系列方法。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
❖ 在程序测试期，通常进行两类测试：人工测 试和机器测试。 ① 人工测试（静态测试） 对程序首先进行的不是机器测试，而是通过 人工集体协同的方式来对被测程序进行静态 审查，以发现代码中的错误。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
计算机科学与技术系
计算机科学与技术总论
1、瀑布模型 瀑布模型有什么缺 点？如何改进？
计算机科学与技术系
计算机科学与技术总论
❖ 从上一阶段接受本阶段工作的对象作为输入。 ❖ 本阶段的工作成果作为输出传入下一阶段。 ❖ 评估各阶段，若本阶段工作得到确认，继续，
否则返回前一阶段。 ❖ 可以增加反馈线来表示具有反馈回路的瀑布
计算机科学与技术系
计算机科学与技术总论
计算机科学与技术总论
二、软件工程的基本原则
6、软件测试
计算机科学与技术系
计算机科学与技术总论
6.1 程序测试的基本概念
测试是软件开发的最后一个阶段，是保 证软件质量的重要环节，它是对需求分 析、设计和编码的最后复审，通过测试 可以发现和纠正软件中的错误，以保证 软件的可靠性。
计算机科学与技术系
计算机科学与技术系
计算机科学与技术总论
一、软件工程概念
❖ Boehm：运用现代科学技术知识来设计并构造 计算机程序及为开发、运行和维护这些程序 所必需的相关文件资料。
❖ IEEE：软件工程是开发、运行、维护和修复 软件的系统方法。
❖ Fritz Bauer：建立并使用完善的工程化原则， 以较经济的手段获得能在实际机器上有效运 行的可靠软件的一系列方法。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
❖ 在程序测试期，通常进行两类测试：人工测 试和机器测试。 ① 人工测试（静态测试） 对程序首先进行的不是机器测试，而是通过 人工集体协同的方式来对被测程序进行静态 审查，以发现代码中的错误。
计算机科学与技术系
计算机科学与技术总论
6.2 测试的种类
计算机科学与技术系
计算机科学与技术总论
1、瀑布模型 瀑布模型有什么缺 点？如何改进？
计算机科学与技术系
计算机科学与技术总论
❖ 从上一阶段接受本阶段工作的对象作为输入。 ❖ 本阶段的工作成果作为输出传入下一阶段。 ❖ 评估各阶段，若本阶段工作得到确认，继续，
否则返回前一阶段。 ❖ 可以增加反馈线来表示具有反馈回路的瀑布
计算机科学与技术系
计算机科学与技术总论
软件工第7章
《软件工程(第3版)》陆惠恩主编
3
7.2 软件的可维护性
软件可维护性指软件被理解、改正、调整和改进的难易程度。
7.2.1 决定可维护性的因素
是否拥有一组训练有素的软件人员； 系统结构是否可理解、是否合理； 文档结构是否标准化； 测试用例是否合适； 是否已有嵌入系统的调试工具； 所选的程序设计语言是否合适； 所选的操作系统等是否合适。 其他，数据库技术、应用的类型、开发人员是否参加维护等。
《软件工程(第3版)》陆惠恩主编
5
7.2.2 可维护性的度量 7.2.3 提高软件的可维护性
1．明确软件工程的质量目标 2．利用先进的软件技术和工具 3．选择便于维护的程序设计语言 4．采取有效的质量保证措施 5．完善软件文档
《软件工程(第3版)》陆惠恩主编 4
第7章小结
软件维护（software maintenance） 就是在软件产品交付之后对其进行修改，以纠正错误，或改进性能和 其它属性，或使产品适应改变了的环境。 四种软件维护： 改正性维护、适应性维护、完善性维护和预防性维护。 软件可维护性就是维护人员对该软件进行维护的难易程度，具体包括 理解、改正、改动和改进该软件的难易程度。 提高软件的可维护性是软件工程各阶段追求的目标之一。 在开发时明确质量目标、考虑软件的维护问题是必须的、重要的。 在软件开发阶段提供完整、一致的文档，采用先进的软件开发方法和 软件开发工具是提高软件可维护性的关键。
第7章软件维护
本章内容：软件维护过程 软件的可维护性 本章重点：软件的可维护性。
7.1 软件维护
软件维护（software maintenance）就是在软件产品交付之后 为了延长使用寿命，对其进行修改以改正错误，或改进性能和其 它属性，或使产品适应改变了的环境。
软件工程 第7章--面向对象设计
8
§1. OOD准则
5、Cohesion：模块内各个元素彼此结合的紧密程度。 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分 解之。
一般-特殊内聚（general-particular cohesion):
17
类构件
类构件：面向对象技术中的“类” 。类构件有3种 重用方式：
–实例重用 –继承重用 –多态重用 1. 可重用类构件应具备的特点 (1) 模块独立性强。具有单一、完整的功能，且经 过反复测试被确认是正确的。是一个不受或很少受 外界干扰的封装体，其内部实现在外面是不可见的。
18
(2) 具有高度可塑性。软构件的应用环境比集成电 路更广阔、更复杂。显然，要求一个软构件能满足 任何一个系统的设计需求是不现实的。因此，可重 用的软构件必须具有高度可裁剪性，必须提供为适 应特定需求而扩充或修改已有构件的机制，而且所 提供的机制必须使用起来非常简单方便。
对象 设计
面向对 象分析
人机界 面设计
任务管 理设计
数据管 理设计
4
§1. OOD准则
§1. OOD准则：优秀软件设计的一个重要特点是 容易维护
回顾：SD准则包括
Modularization Information hiding
Abstraction
Module independence
对于 OOD有类似的准则： 1、Module = Object
• Inheritance —— 无须改动原有代码
13
② 设计重用 —— 当移植系统时
§3. 软件重用
③ 分析重用 —— 当需求未变，而系统结构改变 时（例如将HDIS改为OO实现）
§1. OOD准则
5、Cohesion：模块内各个元素彼此结合的紧密程度。 服务内聚(service cohesion)：一个服务只完成一个功能。
类内聚(class cohesion)：一个类只有一个用途，否则分 解之。
一般-特殊内聚（general-particular cohesion):
17
类构件
类构件：面向对象技术中的“类” 。类构件有3种 重用方式：
–实例重用 –继承重用 –多态重用 1. 可重用类构件应具备的特点 (1) 模块独立性强。具有单一、完整的功能，且经 过反复测试被确认是正确的。是一个不受或很少受 外界干扰的封装体，其内部实现在外面是不可见的。
18
(2) 具有高度可塑性。软构件的应用环境比集成电 路更广阔、更复杂。显然，要求一个软构件能满足 任何一个系统的设计需求是不现实的。因此，可重 用的软构件必须具有高度可裁剪性，必须提供为适 应特定需求而扩充或修改已有构件的机制，而且所 提供的机制必须使用起来非常简单方便。
对象 设计
面向对 象分析
人机界 面设计
任务管 理设计
数据管 理设计
4
§1. OOD准则
§1. OOD准则：优秀软件设计的一个重要特点是 容易维护
回顾：SD准则包括
Modularization Information hiding
Abstraction
Module independence
对于 OOD有类似的准则： 1、Module = Object
• Inheritance —— 无须改动原有代码
13
② 设计重用 —— 当移植系统时
§3. 软件重用
③ 分析重用 —— 当需求未变，而系统结构改变 时（例如将HDIS改为OO实现）
软件工程-第7章修改
也可以用数据库系统等实现
源或宿
存在于软件系统之外的人员或组织，表示软件系统 输入数据的来源和输出数据的去向，因此也称为源 点和终点
例如，对一个考务处理系统而言 考生向系统提供报名单(输入数据流)，所以考生是考试系统(软件) 的一个源 考务处理系统要将考试成绩的统计分析表(输出数据流)传递给考 试中心，所以考试中心是该系统的一个宿
(5) 对需求说明进行复审，直到确认文档齐全， 并且符合用户的全部需求为止。
需求获取的常用方法 1.需求获取的目的
清楚地理解所要解决的问题
完整地获取用户需求
2.需求获取面临的挑战
问题的复杂性和对问题空间理解的不完备性
与不一致性
交流障碍
需求易变性
3.需求获取的常用方法
• 建立联合分析小组
源或宿用相同的图形符号表示
当数据流从该符号流出时表示是源 当数据流流向该符号时表示是宿 当两者皆有时表示既是源又是宿
（b）导出数据流图的过程
① ② ③
第0层的数据流图应将软件/系统描述为一个泡泡 主要的输入和输出应被仔细的标记 通过把下一层表示的候补处理过程、数据对象和数 据存储分离，开始求精过程
脉冲发生器 PC机 声波采集器 软件
软件数据建模 软件行为建模 软件功能建模
输入功能构件 输出功能构件 控制功能构件 操作界面构件
采集声波功能构件 控制脉冲输出构件 延时计算功能构件 操作界面构件
7.2 需求分析
为什么要需求分析？
需求分析就是要彻底理解要解决的问题，真正 明确用户需求。在解决问题之前要理解问题， 只有真正的理解问题才能更好的解决问题。 需求分析就是软件人员和用户之间进行交流， 以理解问题。需求分析是软件开发工程中的一 个重要阶段，在这个阶段中，软件系统分析人 员研究用户在需要解决问题上的意愿，分析出 软件系统应该达到的目标，以及有哪些功能要 求、性能要求等等。
第七章_软件工程(实现)
23
动态测试方法——黑盒和白盒测试 黑盒测试(black-box , or closed-box testing): 又称为功能测试或数据驱动测试，其测试用例完 全是根据程序的功能说明来设计的，测试者完全不考 虑程序内部结构和内部特征，把程序看成一个黑盒。 测试时只考虑如何找出使程序不按要求运行的情况， 因而测试是在程序接口处进行的。 黑盒测试主要能发现的错误 P180 白盒测试(white-box , clear-box testing): 白盒法又称为结构测试或逻辑驱动测试，其测试 用例根据程序内部的逻辑结构来设计的。以检测程序 内部的每条通路是否按预定要求正确工作。 24
主要问题：穷尽测试(complete test)通常是不可能的。
例：(Black-box) 程序要求输入3个整形数据。若字长 16位（即一个整形数据由16位二进制数组成）， 则各种可能输入的排列组合共有：
216 216 216 3 1014 （种）
若程序执行一次需10-3 秒，则对于所有合法输 入的测试大约需用一万年，而且还应测试输入非 法数据的情况。
一、定义
测试: 根据软件开发各阶段的规格说明和程序内部结 构而精心设计一批测试用例（即输入数据及预 期的输出结果），并利用这些测试用例去运行 程序，以发现程序中的错误的过程。p176 调试(纠错): 诊断程序的错误性质、出错的位臵并加 以改正的过程。通常由编码人员承担。 失败：当一个程序不能运行时称失败。失败是系统执 行中出现的情况，失败源于代码缺陷。 错误：程序中的缺陷所产生的不正确的结果称错误。
2、数据说明 P162
数据说明是在写程序时确定的，为了使 数据更容易理解和维护，需遵循以下原则：
数据说明的次序应该标准化；
动态测试方法——黑盒和白盒测试 黑盒测试(black-box , or closed-box testing): 又称为功能测试或数据驱动测试，其测试用例完 全是根据程序的功能说明来设计的，测试者完全不考 虑程序内部结构和内部特征，把程序看成一个黑盒。 测试时只考虑如何找出使程序不按要求运行的情况， 因而测试是在程序接口处进行的。 黑盒测试主要能发现的错误 P180 白盒测试(white-box , clear-box testing): 白盒法又称为结构测试或逻辑驱动测试，其测试 用例根据程序内部的逻辑结构来设计的。以检测程序 内部的每条通路是否按预定要求正确工作。 24
主要问题：穷尽测试(complete test)通常是不可能的。
例：(Black-box) 程序要求输入3个整形数据。若字长 16位（即一个整形数据由16位二进制数组成）， 则各种可能输入的排列组合共有：
216 216 216 3 1014 （种）
若程序执行一次需10-3 秒，则对于所有合法输 入的测试大约需用一万年，而且还应测试输入非 法数据的情况。
一、定义
测试: 根据软件开发各阶段的规格说明和程序内部结 构而精心设计一批测试用例（即输入数据及预 期的输出结果），并利用这些测试用例去运行 程序，以发现程序中的错误的过程。p176 调试(纠错): 诊断程序的错误性质、出错的位臵并加 以改正的过程。通常由编码人员承担。 失败：当一个程序不能运行时称失败。失败是系统执 行中出现的情况，失败源于代码缺陷。 错误：程序中的缺陷所产生的不正确的结果称错误。
2、数据说明 P162
数据说明是在写程序时确定的，为了使 数据更容易理解和维护，需遵循以下原则：
数据说明的次序应该标准化；
软件工程-第7章
源程序代码的逻辑简明清晰、易读易懂是好程序的一个重 要标准，为了做到这一点，应该遵循下述规则。
1.程序内部的文档
所谓程序内部的文档包括恰当的标识符、适当的注解和程 序的视觉组织等。
标识符：含义鲜明的名字、缩写规则一致、为名字加注 解；
注解：正确性，简要描述模块的功能、主要算法、接口 特点、重要数据以及开发简史或解释包含这段代码的必 要性；
子系统测试和系统测试，都兼有检测和组装两重含义， 通常称为集成测试。
第7章 实现
7.2.4 测试步骤
28
7.2 软件测试基础
4.验收测试 验收测试把软件系统作为单一的实体进行测试，测试内
容与系统测试基本类似，但是它是在用户积极参与下进行的， 而且可能主要使用实际数据(系统将来要处理的信息)进行测 试。
7.1 编码
17
编码规范的意义：
➢促进团队合作 ➢减少bug处理 ➢降低维护成本 ➢有助于代码审查
7.1 编码
18
编码规范的原则：
➢方便交流和维护 ➢不影响编码的效率，符合大众习惯 ➢使代码更美观，阅读更方便 ➢使代码的逻辑更清晰，更易于理解
7.1 编码
代码开源网站 ：
20
主要内容
7.1 编码 7.2 软件测试基础 7.3 单元测试 7.4 集成测试 7.5 确认测试 7.6 白盒测试技术 7.7 黑盒测试技术 7.8 调试 7.9 软件可靠性
视觉组织：适当的阶梯形式使程序的层次结构清晰明显。
第7章 实现
7.1.2 编码风格
7.1 编码
7.1.2.编码风格
要做到按照良好的编程风格进行编程，可以从以下几点入手。 1．版权和版本声明。 应该在每个代码文件的开头对代码的版权和版本 进行声明，主要内容有：
1.程序内部的文档
所谓程序内部的文档包括恰当的标识符、适当的注解和程 序的视觉组织等。
标识符：含义鲜明的名字、缩写规则一致、为名字加注 解；
注解：正确性，简要描述模块的功能、主要算法、接口 特点、重要数据以及开发简史或解释包含这段代码的必 要性；
子系统测试和系统测试，都兼有检测和组装两重含义， 通常称为集成测试。
第7章 实现
7.2.4 测试步骤
28
7.2 软件测试基础
4.验收测试 验收测试把软件系统作为单一的实体进行测试，测试内
容与系统测试基本类似，但是它是在用户积极参与下进行的， 而且可能主要使用实际数据(系统将来要处理的信息)进行测 试。
7.1 编码
17
编码规范的意义：
➢促进团队合作 ➢减少bug处理 ➢降低维护成本 ➢有助于代码审查
7.1 编码
18
编码规范的原则：
➢方便交流和维护 ➢不影响编码的效率，符合大众习惯 ➢使代码更美观，阅读更方便 ➢使代码的逻辑更清晰，更易于理解
7.1 编码
代码开源网站 ：
20
主要内容
7.1 编码 7.2 软件测试基础 7.3 单元测试 7.4 集成测试 7.5 确认测试 7.6 白盒测试技术 7.7 黑盒测试技术 7.8 调试 7.9 软件可靠性
视觉组织：适当的阶梯形式使程序的层次结构清晰明显。
第7章 实现
7.1.2 编码风格
7.1 编码
7.1.2.编码风格
要做到按照良好的编程风格进行编程，可以从以下几点入手。 1．版权和版本声明。 应该在每个代码文件的开头对代码的版权和版本 进行声明，主要内容有：
软件工程第七章实现
度。
信息科学与技术学院 闵笛
软件工程
集成测试的两种方式
① 非渐增式组装方式
对每个模块分别进行单元测试，再把所有模 块组装成一个完整的系统进行的测试，从而 得到要求的软件系统。
② 渐增式组装方式
测试过程需要二类输入
软件配置：软件需求规格说明、软件 设计规格说明、源代码等；
测试配置：测试计划、测试用例、
测试程序等；
信息科学与技术学院 闵笛
软件工程
7. 3 单元测试（ Unit Testing )
又称模块测试，需要从程序的内部结构出发 设计测试用例。
测试目的：发现模块内部可能存在的差错 测试依据：详细设计说明书和源程序清单 测试方法：白盒测试为主，黑盒测试为辅，
由于一行中包括了多个语句，掩盖了程序的 循环结构和条件结构，使其可读性变得很差。
信息科学与技术学院 闵笛
软件工程
FOR I:=1 TO N-1 DO //改进布局 BEGIN T:=I； FOR J:=I＋1 TO N DO IF A[J]＜A[T] THEN T:=J； IF T≠I THEN BEGIN WORK:=A[T]； A[T]:=A[I]； A[I]:=WORK； END END；
系统测试的相关概念及方法 程序调试步骤和几种程序调试方法、过程
信息科学与技术学院 闵笛
软件工程
7.1 编码
7. 1.1 选择程序设计语言 程序设计语言的分类
从软件工程的角度，根据程序设计语言发展 的历程，大致分为 4 类：
第一代语言：从属于机器的语言 第二代语言：汇编语言 第三代语言：高级程序设计语言 第四代语言（ 4GL )
编码风格是指一个人编制程序时所表现出来 的特点、习惯、逻辑思路等。
信息科学与技术学院 闵笛
软件工程
集成测试的两种方式
① 非渐增式组装方式
对每个模块分别进行单元测试，再把所有模 块组装成一个完整的系统进行的测试，从而 得到要求的软件系统。
② 渐增式组装方式
测试过程需要二类输入
软件配置：软件需求规格说明、软件 设计规格说明、源代码等；
测试配置：测试计划、测试用例、
测试程序等；
信息科学与技术学院 闵笛
软件工程
7. 3 单元测试（ Unit Testing )
又称模块测试，需要从程序的内部结构出发 设计测试用例。
测试目的：发现模块内部可能存在的差错 测试依据：详细设计说明书和源程序清单 测试方法：白盒测试为主，黑盒测试为辅，
由于一行中包括了多个语句，掩盖了程序的 循环结构和条件结构，使其可读性变得很差。
信息科学与技术学院 闵笛
软件工程
FOR I:=1 TO N-1 DO //改进布局 BEGIN T:=I； FOR J:=I＋1 TO N DO IF A[J]＜A[T] THEN T:=J； IF T≠I THEN BEGIN WORK:=A[T]； A[T]:=A[I]； A[I]:=WORK； END END；
系统测试的相关概念及方法 程序调试步骤和几种程序调试方法、过程
信息科学与技术学院 闵笛
软件工程
7.1 编码
7. 1.1 选择程序设计语言 程序设计语言的分类
从软件工程的角度，根据程序设计语言发展 的历程，大致分为 4 类：
第一代语言：从属于机器的语言 第二代语言：汇编语言 第三代语言：高级程序设计语言 第四代语言（ 4GL )
编码风格是指一个人编制程序时所表现出来 的特点、习惯、逻辑思路等。
课件：第7章_集成化CASE环境(赵志升) (1)
CASE技术是软件工具和软件开发方法的结合，CASE是多年来在软 件开发管理，软件开发方法，软件开发环境和软件工具等方面研究和发 展的产物。
CASE把软件开发技术，软件工具和软件开发方法集成到一个统一 的框架中，并且吸收了CAD，软件工程，操作系统，数据库，网络和其 他许多计算机领域的原理和技术。它不同于以前的软件技术，它强调了 解决整个软件开发过程的效率问题，而不是解决个别阶段的问题，由于 它跨越了软件生存周期各个阶段，着眼于软件分析和设计以及实现和维 护的自动化，因而解决了软件生存周期的生产率问题。
软件工具通常由工具、工具接口和工具用户接口3部分构成。工具通 过工具接口与其它工具、操作系统或网络操作系统以及通信接口、环境信 息库接口等进行交互作用，当工具需要与用户进行交互作用时，则通过工 具的用户接口来进行。
但是，孤立的软件工具只能支持软件工程的某些项活动。各种软件工 具的数据结构不统一，程序界面不标准，软件工程引用和加工的数据需要 进行格式转换，相关的软件工具因设计标准不一致很难集成为一个软件系 统，严重影响软件开发和维护的效率。
２、按软件开发环境的演变趋向分 以语言为中心的环境（InterLisp语言、SmallTalk语言、Ada环境等）、
工具箱环境 其特点是由一整套工具组成，供程序设计选择之用。典型的有UNIX、
Windows、SPSE等。 ３、还可以按照集成度来分类。
9.2 CA采用“工程化”的原则，方法和技术来开发，维 护，管理软件。
9.1.1 常见的软件开发工具
7.1.1常见的软件开发工具
大家最熟悉的软件工具末过于微软的Office系列工具：如word 它是常用的文本编辑和正文格式处理工具，其界面如图9.1所示。
图9.1 WORD 界面
CASE把软件开发技术，软件工具和软件开发方法集成到一个统一 的框架中，并且吸收了CAD，软件工程，操作系统，数据库，网络和其 他许多计算机领域的原理和技术。它不同于以前的软件技术，它强调了 解决整个软件开发过程的效率问题，而不是解决个别阶段的问题，由于 它跨越了软件生存周期各个阶段，着眼于软件分析和设计以及实现和维 护的自动化，因而解决了软件生存周期的生产率问题。
软件工具通常由工具、工具接口和工具用户接口3部分构成。工具通 过工具接口与其它工具、操作系统或网络操作系统以及通信接口、环境信 息库接口等进行交互作用，当工具需要与用户进行交互作用时，则通过工 具的用户接口来进行。
但是，孤立的软件工具只能支持软件工程的某些项活动。各种软件工 具的数据结构不统一，程序界面不标准，软件工程引用和加工的数据需要 进行格式转换，相关的软件工具因设计标准不一致很难集成为一个软件系 统，严重影响软件开发和维护的效率。
２、按软件开发环境的演变趋向分 以语言为中心的环境（InterLisp语言、SmallTalk语言、Ada环境等）、
工具箱环境 其特点是由一整套工具组成，供程序设计选择之用。典型的有UNIX、
Windows、SPSE等。 ３、还可以按照集成度来分类。
9.2 CA采用“工程化”的原则，方法和技术来开发，维 护，管理软件。
9.1.1 常见的软件开发工具
7.1.1常见的软件开发工具
大家最熟悉的软件工具末过于微软的Office系列工具：如word 它是常用的文本编辑和正文格式处理工具，其界面如图9.1所示。
图9.1 WORD 界面
软件工程 第七章 实现2
任何工业产品在出厂前都要经过严格的质 量检验，软件产品也不例外,在编码和调 量检验，软件产品也不例外 在编码和调 试完成之后，还需要进行严格的测试！ 试完成之后，还需要进行严格的测试！软 严格 件测试是软件质量保证的主要手段。 件测试是软件质量保证的主要手段。 质量保证
软件测试是软件开发过程中最艰巨最繁重的 任务，测试的目的就是在软件投入生产性运 任务，测试的目的就是在软件投入生产性运 行之前，尽可能多地发现软件中的错误。 行之前，尽可能多地发现软件中的错误。 大型软件的测试应该分阶段地进行， 大型软件的测试应该分阶段地进行，通常至 少分为单元测试 集成测试和验收测试3个 单元测试、 少分为单元测试、集成测试和验收测试 个 基本阶段。 基本阶段。 其中,设计测试方案 设计测试方案是测试阶段的关键技术问 其中 设计测试方案是测试阶段的关键技术问 基本目标是选用最少量的高效测试数据 是选用最少量的高效测试数据， 题，基本目标是选用最少量的高效测试数据， 做到尽可能完善的测试， 尽可能完善的测试 做到尽可能完善的测试，从而尽可能多地发 现软件中的问题。 现软件中的问题。
?程序设计语言的选择原则?程序设计风格71编码711711程序设计语言的选择程序设计语言的选择程序设计语言是人和计算机通信的最基本的工具它的特点必然会影响人的思维和解题方式会影响人和计算机通信的方式和质量也会影响其他人阅读和理解程序的难易程度
第七章 实现
通常把编码和测试统称为实现。 通常把编码和测试统称为实现。 编码 统称为实现 所谓编码就是把软件设计结果翻译成用某种 就是把软件设计结果 所谓编码就是把软件设计结果翻译成用某种 程序设计语言书写的程序 程序。 程序设计语言书写的程序。 编码（Coding）阶段的任务简单说， 编码（Coding）阶段的任务简单说，是为 的任务简单说 每个模块编写程序 模块编写程序。 每个模块编写程序。即是将详细设计的结 果转换为用某种计算机语言写的程序—— 果转换为用某种计算机语言写的程序 源程序代码。 源程序代码。 编码阶段结束时交付的是不含语法错误的 程序和有关程序说明的“内部文档” 程序和有关程序说明的“内部文档”