软件工程期末复习

软件工程期末复习提纲

第1章 软件工程学概述

1.1 软件危机、软件危机的典型表现、产生原因、消除途径

软件危机:

  • 是指在计算机软件的开发和维护过程中所遇到的一系列严重问题。
  • 所有软件都不同程度地存在问题。
  • 包含两方面问题:如何开发软件、如何维护数量不断膨胀的已有软件
  • 又称软件萧条或软件困扰

典型表现:

产生原因: 
在这里插入图片描述

消除途径:

  1. 对计算机软件有一个正确的认识。消除软件就是程序的错误观念。
  2. 必须充分认识到软件开发不是某种个体劳动的技巧,而是一种合作完成的工程项目
  3. 推广和使用开发软件的成功的技术和方法
  4. 开发和使用更好的软件工具

1.2 软件=程序+数据+相关文档。

1.3 文档的作用

  1. 提高软件开发过程的能见度。把开发过程中发生的事件以某种可阅读的形式记录在文档中。
  2. 管理人员可把这些记载下来的材料作为检查软件开发进度和开发质量的依据,实现对软件开发的工程管理。
  3. 提高开发效率。 软件文档的编制,使得开发人员对各个阶段的工作都进行周密思考、全盘权衡、减少返工。并且可在开发早期发现错误和不一致性,便于及时加以纠正。
  4. 作为开发人员在一定阶段的工作成果和结束标志。
  5. 记录开发过程中有关信息,便于协调以后的软件开发、使用和维护。
  6. 提供对软件的运行、维护和培训的有关信息,便于管理人员、开发人员、操作人员、用户之间的协作、交流和了解。 使软件开发活动更科学、更有成效。
  7. 便于潜在用户了解软件的功能、性能等各项指标,为他们选购符合自己需要的软件提供依据。

1.4 软件工程的本质特性(7 点)

  1. 软件工程关注于大型程序的构造
  2. 软件工程的中心课题是控制复杂性
  3. 软件经常变化
  4. 开发软件的效率非常重要
  5. 和谐的合作是开发软件的关键
  6. 软件必须有效的支持他的用户
  7. 在软件工程领域中通常由具有一种文化背景的人替具有另一种文化背景的人创造产品

1.5 软件工程的基本原理(7 条)

  1. 用分阶段的生命周期计划严格管理
  2. 坚持进行阶段评审
  3. 实行严格的产品控制
  4. 采用现代程序设计技术
  5. 结果应能清楚的审查
  6. 开发小组的人员应该少而精
  7. 承认不断改进软件工程实践的必要性

1.6 软件工程方法学:

包含三个要素:方法、工具和过程
传统方法学
① 也称生命周期方法学或结构化范型。
② 把软件生命周期的全过程划分为若干阶段,顺序完成每个阶段的任务。
③ 前一个阶段的任务是后一个阶段的前提,后一个阶段是前一阶段具体化。
④ 前一个阶段结束的标准是后一个阶段开始的标准。
面向对象方法学
① 一种以数据为主线,把数据和对于数据的操作紧密结合起来的方法
② 出发点和基本原则:模拟人类习惯的思维方式。
③ 开发软件的过程是一个主动多次反复迭代的演化过程
④ 优点:促进了软件重用
4个要点: 对象分解、数据专有、继承、封装性

  1. 对象分解。把对象作为融合了数据以及在数据上的操作行为的统一的软件构件。
  2. 数据专有。把所有对象都划分为类
  3. 继承。按照父类与子类的关系,把若干个相关类组成一个层次结构的系统(也称为类等级)
  4. 封装性。对象彼此间仅能通过发送消息相互联系。

1.7 软件生命周期的概念

一个软件从定义到开发、使用和维护,直到最终被废弃,要经历一个漫长的时期,通常把软件经历的这个漫长的时期称为生存周期。软件生存周期就是从提出软件产品开始,直到该软件产品被淘汰的全过程。

生命周期的每一个周期都有确定的任务,并产生一定规格的文档(资料),提交给下一个周期作为继续工作的依据。按照软件的生命周期,软件的开发不再只单单强调“编码”,而是概括了软件开发的全过程。软件工程要求每一周期工作的开始只能必须是建立在前一个周期结果“正确”前提上的延续;因此,每一周期都是按“活动-结果-审核-再活动-直至结果正确”循环往复进展的。

1.8 软件生命周期主要划分为:

软件定义:
① 确定软件开发工程必须完成的总目标
② 确定工程的可行性
③ 导出实现工程目标硬采用的策略以及系统必须完成的功能
④ 估计需要的资源和成本,并制定工作进度表
⑤ 由系统分析员负责完成。
⑥ 三个阶段:问题定义、可行性研究、需求分析
软件开发:
① 具体设计和实现在前一个时期定义的软件。
② 系统设计:总体设计、详细设计;系统实现:编码和单元测试,综合测试
运行维护:
① 使软件持久地满足用户需要
② 使用过程中发现错误;环境改变时;用户有新要求时;
③ 每次维护活动本质上都是一次压缩和简化了的定义和开发过程。

1.9 软件生命周期的8个阶段;每个阶段要回答的问题和工作内容及阶段性成果

八个阶段回答的问题工作内容阶段性成果
问题定义要解决的问题是什么?对客户的访问调查,扼要地写出关于问题性质、工程目标和工程规模的书面报告问题定义报告
可行性研究对于上一个阶段所确定的问题有行得通的解决办法吗系统分析员进行简要的系统分析和设计过程。在较抽象的高层次上进行的分析和设计过程。研究问题的范围,探索是否值得去解决。可行性分析报告
需求分析为了解决这个问题目标系统必须做什么,确定目标系统必须具备哪些功能在需求分析阶段和用户密切配合,充分交流信息,得出经过用户确认的系统逻辑模型需求规格说明书;包括数据流图、数据字典和简要的算法表示系统的逻辑模型。
总体设计概况的说,应该怎样实现目标系统又称为概要设计系统设计:用适当的表达工具描述每种方案,分析每种方案的优缺点。制定出实现最佳方案的详细计划。结构设计:确定程序有哪些模块组成以及模块间的关系
详细设计具体化揭发,应该怎样具体地实现这个系统模块设计,确定实现模块功能所需的算法和数据结构设计出程序的详细规格说明
编码和单元测试写出正确的容易理解、容易维护的程序模块程序员选择适当的程序设计语言,把详细设计的结果敲成代码。并测试。
综合测试通过各种类型的测试,是软件达到预定的要求集成测试:根据程序的软件结构,把经过单元测试的模块按某种策略装配起来。验收测试。按照规格说明书由用户参与下对目标系统进行验收保存测试计划、详细测试方案
软件维护通过各种必要的维护活动使系统持久地满足用户需要改成型维护、适应性维护、完善性维护、预防性维护记录每一项维护活动,作为正式的文档资料保存

1.10 生命周期模型、特点及适用场景:

在这里插入图片描述在这里插入图片描述在这里插入图片描述
在这里插入图片描述
在这里插入图片描述

生命周期模型特点优点缺点适用场景
瀑布模型1)阶段间具有顺序性和依赖性2)推迟实现的观点3)质量保证的观点1),可强迫开发人员采用规范的方法(例如:结构化技术)2),严格地规定了每个阶段必须提交的文档;“瀑布模型是由文档驱动的”在可运行的软件产品交付给用户之前,用户只能通过文档来了解产品是什么样子的。但是通需求明确,小规模软件开发。
快速原型模型快速建立起能够在计算机上运行的程序(最终产品功能的一个子集)软件产品的开发基本上是线性的必须迅速地构建原型然后根据用户意见循序的修改原型用户需求不明确,需要通过构建原型来清楚的了解用户的真实需求。
增量模型把软件产品作为一系列的增量构件来设计,编码,集成和测试。每个构件有多个相互作用的模块构成,并且能够完成特定的功能。使用增量模型时,第一个增量模型时,第一个增量构件往往实现软件的基本需求,提供最核心的功能。1),能够在较短的时间内向用户提交可完成部分工作的产品;2),逐步增加产品功能可以使用户有较充裕的时间学习适应新产品,从而减少一个全新的软件可能给客户组织带来的冲击。1),较难把每个新的增量构件集成到现有的软件体系结构中,而又不破坏原来已经开发出的产品。2),增量模型本身是自相矛盾的,它一方面要求开发人员把软件当做一个整体,另一个方面又要求开发人员把软件构件序列,每个构件本质上都独立于另一个构件,除非开发人员有足够的技术能力协调好这一明显的矛盾,否则增量模型开发出来的产品可能并不能令人满意。软件开发周期较长的软件,有持续的合作。
螺旋模型螺旋模型的基本思想是,使用原型及其他方法来尽量降低风险,即是在每个阶段之前都增加了风险分析过程。1),对可选方案和约束条件的强调有利于已有软件的重用,也有利于把软件质量作为软件开发的一个重要目标;2),减少了过多测试(浪费资金)或者不足(产品故障多)所带来的风险;3),在螺旋中维护的只是模型的另一个周期,在维护和开发之间没有本质的区别;除非软件开发人员具有丰富的风险评估经验和这方面的专门知识,否则将出现真正的风险,当项目实际上正在走向灾难时,开发人员可能还认为一切正常。内部软件开发的大规模软件项目。
喷泉模型1.阶段间具有顺序性和依赖性2.推迟实现的观点:在编码之前设置了系统分析与系统设计的各个阶段,3.质量保证的观点1),对生命周期各阶段的区分变得不重要,不明显了;2),分析阶段得到的对象模型也适用设计阶段和实现阶段;3),提高软件项目开发效率,节省开发时间1),开发过程过分无序;2),面向对象范型本身要求经常对开发活动进行迭代或求精;3),在开发过程中需要大量的开发人员,因此不利于项目的管理。面向对象的软件开发过程

1.11 什么是软件工程?

软件工程是指导计算机软件开发和维护的工程学科。采用工程的概念、原理、技术和方法来开发与维护软件,把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来。

第2章 可行性研究

2.1 可行性研究的目的

确定问题是否值得去解决。实质上是要进行一次大大压缩简化了的系统分析和设计的过程,在较高层次上以较抽象的方式进行的系统分析和设计的过程。

2.2 可行性研究的 3 个方面:技术可行性、经济可行性、操作可行性

技术可行性:使用现有的技术能实现这个系统吗
经济可行性:这个系统的经济效益能超过他的开发成本吗
操作可行性:系统的操作方式在这个用户组织内行得通吗

2.3 系统流程图概念、图形符号

概括地描绘物理系统的传统工具。基本思想是用图形符号一黑盒子形式描绘组成系统的每个部件(程序、文档、数据库、人工过程等)。系统流程图表达的是数据在系统各部件之间流动的情况,而不是对数据进行加工处理的控制过程。
在这里插入图片描述

在这里插入图片描述
在这里插入图片描述在这里插入图片描述

2.4 数据流图的概念、图形符号、绘制方法

一种图形化技术,他描绘信息流和数据从输入移动到输出过程中所经受的变换。
在这里插入图片描述
在这里插入图片描述在这里插入图片描述在这里插入图片描述

2.5 数据字典的概念、内容(数据流、数据元素、数据存储、处理)

概念: 是关于数据的信息的集合,也就是对数据流图中包含的所有元素的定义的集合。
用途: 作为分析阶段的工具。是开发数据库的第一步
内容包括: 数据流、数据元素、数据存储、处理

2.6 成本效益分析

概念: 目的是从经济角度分析开发一个特定的新系统是否划算,从而帮助客户组织的负责人正确地做出是否投资于这项开发工程的决定。为了对比成本和效益,首先要估计他们的数量。
系统的经济效益=因使用新系统而增加的收入+使用新系统可以节省的运行费用。

成本估计的方法:

  1. 代码行技术。 把开发每个软件功能的成本和实现这个功能需要用的源代码行数联系起来。每行代码的平均成本主要取决于软件的复杂程度和工资水平。
  2. 任务分解技术 。分解任务,分别估计,累加得出总成本。
  3. 自动估计成本技术 。这种技术必须有长期搜集的大量历史数据为基础,并且需要有良好的数据库系统支持

成本效益分析时应考虑:

  1. 货币的时间价值
  2. 投资回收期
  3. 纯收入
  4. 投资回收率

第3章 需求分析

3.1 需求分析需要回答的问题

准确的回答系统必须做什么这个问题

3.2 需求分析的任务、需求分析的成果

  1. 确定对系统的综合要求
    (1) 功能需求。指定系统必须提供的服务。需求分析应该划分出系统必须完成的所有功能。
    (2) 性能需求。通常包括:速度(响
    应时间)、信息量速率、主存容量、磁盘容量、安全性等方面的需求。
    (3) 可靠性和可用性需求。可靠性需求定量地指定系统的可靠性。
    (4) 出错处理需求。说明系统对环境错误应该怎样响应
    (5) 接口需求。接口需求描述应用系统与它的环境通信的格式。
    (6) 约束。设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。
    (7) 逆向需求。逆向需求说明软件系统不应该做什么。
    (8) 将来可能提出的要求。应该明确地列出那些虽然不属于当前系统开发范畴,但是据分析将来很可能会提出来的要求。
  2. 分析系统的数据要求
  3. 导出系统的逻辑模型
  4. 修正系统开发计划
    需求分析的成果:需求规格说明书

3.3 分析建模:

数据模型(实体-联系图)
功能模型(数据流图)
行为模型(状态转换图)

3.4 E-R 图的作用、图形符号、实体关系、绘制方法、数据库表的设计、实体属性

概念性数据模型是一种面向问题的数据模型,是按照用户的观点对数据建立的模型;它描述了从用户角度看到的数据,它反映了用户的现实环境,而且与在软件系统中的实现方法无关。
在这里插入图片描述

3.5 数据规范化

在这里插入图片描述

3.6 IPO 图

在这里插入图片描述

第5章 总体设计

5.1 总体设计的目的

回答“概括地说,系统应该如何实现”

5.2 了解总体设计过程

  1. 设想供选择的方案
  2. 选择合理的方案
  3. 推荐最佳方案
  4. 功能分解
  5. 设计软件结构
  6. 设计数据库
  7. 制定测试计划
  8. 书写文档
    1)系统说明
    2)用户手册
    3)测试计划
    4)详细的事先计划
    5)数据库设计结果
  9. 审查和复审

5.3 软件设计过程中应该遵循的基本原理:

  1. 模块化。每个模块完成一个子功能。
  2. 抽象。抽出事物的本质特性而暂时不考虑他们的细节。
  3. 逐步求精。为了能集中精力解决主要问题而尽量推迟对问题细节的考虑。遵循Miller法则:一个人在任何时候都只能把注意力集中在(7±2)个知识块上。
  4. 信息隐藏和局部化。所谓局部化是指把一些关系密切的软件物理地放得彼此靠近。

5.4 模块独立的概念、定量度量标准(耦合、内聚)

是模块化、抽象、信息隐藏和局部化概念的直接结果。
①有效的模块化地软件比较容易开发出来。独立化模块能分割功能而且接口可以简化;
②独立的模块比较容易测试和维护。
耦合: 衡量不同模块彼此间相互依赖地紧密程度。
内聚: 衡量一个模块内部哥哥元素彼此结合地紧密程度。

5.5 耦合方式、内聚方式、扇出、扇入,以及这些概念在模块设计方面的意义

数据耦合: 交换的信息仅为数据。
控制耦合: 传递地信息中有控制信息。
特征耦合: 调用的模块只使用其中一部分数据元素。
公共环境耦合: 当两个或多个模块通过一个公共数据环境相互作用时,它们之间的耦合
称为
内容耦合::一个模块访问另一个模块的内部数据; 一个模块不通过正常入口而转到另一个模块的内部;两个模块有一部分程序代码重叠(只可能出现在汇编程序中);一个模块有多个入口(这意味着一个模块有几种功能)。
尽量使用数据耦合,少用控制耦合和特征耦合,限制公共环境耦合地范围,完全不用内容耦合

内聚:

  • 功能内聚 10分
  • 顺序内聚 9分
  • 通信内聚 7分
  • 过程内聚 5分
  • 时间内聚 3分
  • 逻辑内聚 1分
  • 偶然内聚 0分

扇入: 指直接调用该模块的上级模块的个数
扇出: 指该模块直接调用的下级模块的个数
低耦合高内聚,得较高的模块独立性。顶层扇出高,底层扇入高,是好的模块设计。

如果一个模块被 n 个模块调用,其中直接的上级模块的个数是 m 个( m<=n )那么该模块的扇入数是 m 个。

5.6 作用域、控制域

控制域:本身及其所有下级模块
作用域:受该模块内一个判定影响的所有模块的集合
模块的作用域应在模块的控制域之内

5.7 启发规则

改进软件设计提高软件质量的途径。

  1. 改进软件结构提高模块独立性
  2. 模块规模应该适中
  3. 深度宽度扇入扇出都应该适当
  4. 模块的作用域应该在控制域之内
  5. 力争降低模块接口的复杂程度
  6. 设计单入口单出口的模块
  7. 模块功能应该可以预测

5.8 层次图和结构图的绘制

在这里插入图片描述
在这里插入图片描述

5.9 面向数据流的设计方法,了解变换流、事务流的概念及区别,了解变换分析、事务分析。

面向数据流的设计方法的目标是:给出设计软件结构的一个系统化的途径。

第6章 详细设计

6.1 结构程序设计的概念、基本控制结构(顺序、选择、循环)

结构化程序设计的定义:如果一个程序的代码块仅仅通过顺序、选择、循环这3种基本控制结构进行链接,并且每个代码块只能一个入口和一个出口,则这个程序是结构化的。
(尽可能少用GOTO语句)

说明结构化程序设计的主要思想是什么?
答:(1)自顶向下、逐步求精的程序设计方法;(2)使用 3 种基本控制结构、单入口、单出口来构造程序。

6.2 程序流程图

缺点如下:

  1. 本质上不是逐步求精的好工具,它诱使程序员过早考虑程序流程而不考虑程序的全局结构
  2. 完全不顾结构程序设计的精神
  3. 不宜表示数据结构

6.3 PAD

在这里插入图片描述

在这里插入图片描述

6.4 判定表

6.5 判定树

6.6 Jackson 图

在这里插入图片描述

6.7 了解 Jackson 结构程序设计方法

在这里插入图片描述在这里插入图片描述在这里插入图片描述

6.8 流图的概念、流图的绘制、环形复杂度的方法

概念: 流图实质上是“退化了的”程序流程图,描绘程序的控制流程,不表现对数据的具体操作以及分支或循环的具体条件。
在这里插入图片描述在这里插入图片描述

第7章 实现

7.1 实现=编码+测试

7.2 程序设计语言的选择

遵循标准
① 系统用户的要求
② 可以使用的编译程序
③ 可以得到的软件工具
④ 工程规模
⑤ 程序员的知识
⑥ 软件可以执行要求
⑦ 软件的应用领域

7.3 系统软件测试的目标

  1. 测试是为了发现程序中的错误而执行程序的过程
  2. 好的测试方案是极有可能发现迄今为止尚未发现的错误的测试方案
  3. 成功的测试是发现了至今为止尚未发现的错误的测试

7.4 大型软件系统的测试过程中的测试步骤

  1. 模块测试。又称单元测试,目的是保证每个模块作为一个单元能正确运行。
  2. 子系统测试。着重测试模块的接口,模块间的协调和通信是这个模块的主要问题。
  3. 系统测试。发现设计和编码的错误,验收系统在需求说明书中指定的功能。与子系统测试通常称为集成测试。
  4. 验收测试。与系统测试基本类似,不同的是在用户积极参与下进行,可能主要使用实际数据进行测试。目的是验证系统确实能满足用户的需要。又称为确认测试。
  5. 平行运行。又称驱动测试。验收后不利己投入生产性运行,而是要经过一段平行运行时间的考验。同时运行新开发出来的系统和将被它取代的旧系统,比较二者处理结果。目的有:
    ① 可以在准生产环境中运行新系统而又不冒风险。
    ② 用户能有一段熟悉新系统的时间。
    ③ 可以验证用户指南和使用手册之类的文档
    ④ 能够以准生产环境对新系统进行全负荷测试,可以用测试结果验证性能指标。

7.5 测试方法:黑盒测试、白盒测试

白盒测试

概念:

白盒测试也称结构测试或逻辑驱动测试,是针对被测单元内部是如何进行工作的测试。它根据程序的控制结构设计测试用例,主要用于软件程序验证。

典型技术:逻辑覆盖

测试数据执行(或叫覆盖)程序逻辑的程度划分为以下几个等级:

  1. 语句覆盖:选择足够多的测试数据,是被测程序中的每个语句至少执行一次。逻辑覆盖很少。
  2. 判定覆盖:又叫分支覆盖,不仅每个语句必须至少执行一次,而且每个判定的每种可能的结果都应该至少执行一次。比语句覆盖强,但是对程序逻辑的覆盖程度仍然不高。
  3. 条件覆盖:不仅每个语句必须至少执行一次,而且使判定表达式中的每个条件都取到各种可能的结果。通常比判定覆盖强,但也有可能每个条件都去了两个不同的结果,判定表达式确实同一个值。
  4. 判定/条件覆盖:选取足够多的测试数据,使得判定表达式中的每个条件都取到各种可能的值,而且表达式也都取到各种可能的结果。
  5. 条件组合覆盖:覆盖标准最强。但是不一定能使每条路径都执行到。
  6. 点覆盖通常与语句覆盖标准相同。
  7. 边覆盖通常与判定覆盖一致。
  8. 路径覆盖:使程序的每条可能路径都至少执行一次。
典型技术:控制结构测试
  1. 基本路径测试
  2. 条件测试
  3. 循环测试

黑盒测试

概念:

黑盒测试法把程序看成一个黑盒子,完全不考虑程序的内部结构和处理过程,它只检查程序功能是否能按照规格说明书的规定正常使用,程序是否能适当地接收输入数据,产生正确地输出信息。

着重测试软件功能。与白盒测试互补。白盒测试在测试的早期,黑盒测试主要用于测试过程的后期。力图发现下述错误:

  1. 功能不正确或疏漏了功能
  2. 界面错误
  3. 数据结构错误或外部数据库访问错误
  4. 性能错误
  5. 初始化和终止错误。

设计黑盒测试方案时,应该考虑:

  1. 怎样测试功能的有效性
  2. 哪些类型的输入可以构成好测试用例
  3. 系统是否对特定的输入值特别敏感
  4. 怎样划定数据类的边界
  5. 系统能承受什么样的数据率和数据量
  6. 数据的特定组合将对系统运行产生什么影响

应用黑盒测试,能够设计出满足下述标准的测试用例集:

  1. 所设计出的测试用例能够减少未达到合理测试所需要的设计的测试用例的总数。
  2. 所设计出的测试用例能够告诉人们,是否存在某类型的错误,而不是仅仅指出与特定测试相关的错误是否存在。
典型技术:等价划分

把程序的输入与划分成若干个数据类,据此导出测试用例。力图设计出能发现若干类程序错误的测试用例,从而减少必须设计的测试用例的数目。

典型技术:边界值分析

选取刚好等于、稍小于和稍大于等价类边界值的数据作为测试数据,而不是选取每个等价类内的典型值或任意值作为测试数据。

典型技术:错误推测

依靠经验和直觉,从各种可能的测试方案中选出一些最可能引起程序出错的方案。

7.6 驱动程序、存根程序

驱动程序:指的是设备驱动程序,是一种可以使计算机和设备通信的特殊程序。通常驱动程序也就是一个“主程序”。自底向上集成需要,
存根程序:简化了被调用模块的程序。“虚拟子程序”。自顶向下集成需要。

7.7 集成测试、渐增式集成测试的集成策略及其优缺点

集成测试指模块组装时的系统化技术。主要目标是发现与接口有关的问题。
非渐增式测试:改正错误极端困难,定位错误困难,改正错误会产生新的错误。
渐增式测试:比较容易定位和改正错误;对接口可以进行更彻底的测试;可以使用系统化的测试方法。

7.8 单元测试

单元测试的重点

  1. 模块接口:全局变量的定义和用法是否一致、是否修改了只读的数据、参数的属性是否一致。
  2. 局部数据结构:数据说明、初始化、默认值等。
  3. 重要的执行通路:应设计测试方案用于发现由于错误的计算、不正确的比较或不适当的控制流而引起的错误。
  4. 出错处理通路:设置适当的处理错误的通路
  5. 边界条件

7.9 确认测试

  • 确认测试必须有用户积极参与,或者以用户为主进行。
  • 确认测试通常使用黑盒测试法。要保证软件能满足所有的功能要求,达到性能要求,文档资料准确完整;安全性要求、可移植性、可维护性等。
  • 确认测试有以下两种可能的结果:①功能与性能与用户要求一致,软件可以接受。②仍有差距
  • 重要内容是:复查软件配置。目的是:保证软件配置的所有成分齐全,质量符合要求,文档与程序完全一致,具有完成软件维护所必须的细节,且已经编号目录。
  • 测试过程中应该严格遵循用户指南以及其他操作程序,以便检验这些使用手册的完整性和正确性。

7.10 Alpha 测试和 Beta 测试

Alpha测试: 由用户在开发者的场所进行,在开发者对用户的指导下进行测试。在受控的环境中
Beta测试: 软件在开发者不能控制的环境中的真是应用。由用户记录在Beta测试过程中所遇到的一切问题,并定期报告给开发者。

7.11 调试

测试的目的是判断和发现软件是否有错误。调试的目的是定位软件错误并纠正错误。
调试的方法:

  1. 蛮干法。打印内容。
  2. 回溯法。适用于小程序。
  3. 原因排除法。对分查找法、归纳法、演绎法。

第9章 面向对象方法学

9.1 面向对象方法学

出发点和原则: 尽可能模拟人类习惯的思维方式,使开发软件的方法与过程尽可能接近人类认识世界解决问题的方法与过程。

四个要点: 对象分解、数据专有、继承、封装性。

  1. 对象分解。认为客观世界室友各种对象组成的,任何事物都是对象,复杂的对象可以由比较简单的对象以某种方式组合而成。
  2. 数据专有。把所有对象都划分成各种对象类(简称为类,class),每个对象类都定义了一组数据和一组方法。
  3. 继承。按照子类与父类关系,把若干个对象类组成一个层次结构的系统
  4. 封装性。对象彼此之间仅能通过传递消息互相联系。

9.2 面向对象方法学的优点

  1. 与人类习惯的思维方法一致
  2. 稳定性好
  3. 可重用性好
  4. 较易开发大型软件产品
  5. 可维护性好

9.3 面向对象的基本概念:对象、类、消息、封装、继承、多态性、重载等

对象: 对象是具有相同状态的一组操作的集合。
类: 对具有相同数据和相同操作的一组相似对象的定义。
实例: 有某个特定的类所描述的一个具体的对象
消息: 要求某个对象执行在定义它的那个类中所定义的某个操作的规格说明。由接收消息的对象;消息选择符;零个或多个变元组成。
继承: 能够直接获得已有的性质和特征,不必重复定义。
多态性: 子类对象可以向父类对象那样使用。在类等级的不同层次中可以共享一个行为的名字,然而不同层次中的每个类却各自按自己的需要来实现这个行为。
重载: 运算符重载和函数重载。

9.4 三种模型:对象模型、功能模型、动态模型

对象模型: 表示静态的、结构化的系统的 “数据” 性质。强调围绕对象而不是围绕功能。
功能模型: 表示变化的系统的 “功能” 性质,指明了系统应该做什么,更直接的反映了用户对目标系统的需求。
动态模型: 表示瞬时的、行为化的系统的 “控制” 性质。规定了对象模型中的对象的合法变化序列。要考察对象的动态行为。
三个模型的关系:
在这里插入图片描述

9.5 常见 UML 图及其作用

UML9种图的分类及运用

  • 8
    点赞
  • 64
    收藏
    觉得还不错? 一键收藏
  • 1
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值