软件工程导论学习笔记

1.1 软件

软件：有计算机程序，文档，运行程序所必须的数据，文档，软件开发过程当中所用到的方法，开发过程当中所遵循的规则。软件=程序+文档+数据

软件的分类：

基于软件功能来进行分类：系统软件（与计算机硬件想配合使得计算机各个部件相互协调工作：Eg：系统软件和编译程序），支持软件（协助用户进行开发的软件。EG：rational rose 用于实现UML建模），应用软件（商业处理软件：Eg超市管理系统。工程与科学计算软件：MATLAB。智能产品嵌入式软件：Eg：家用电器，智能手机。人工智能软件：利用非数值算法解决复杂问题Eg：人工神经网络软件，模式识别软件（进行人类识别）），个人计算机软件（world，WPS，游戏软件）

基于软件规模来进行划分：根据软件的开发人数开发周期来进行划分。

微型软件：一个人在1-4周之内就能够完成，代码数在500行

小型软件：一个人在1-6个月之内完成，代码在1000到2000行

中型软件：2-5人 1-2年 5000-50000行

大型软件：5-10人 2-3年 5W-10W行

1.2 软件工程

软件的发展：

程序设计阶段（软件发展的初级阶段，软件较小，基本由个人单独完成的），

程序系统阶段（软件作坊出现开始进行产品软件的生产，市场当中各种小型软件充斥混乱出现软件危机），

软件工程阶段（采用工程化的方式使得软件危机有了一定程度的缓解，软件的质量的到提升），

第四阶段（80年代：软件架构由传统的集中主机模式即将数据存取和应用程序都安装在同一台主机当中。缺陷：数据无法共享。客户端服务器端B/S或C/S.胖客户端：即所有的应用都放到客户端，服务器端只进行数据的存取操作。瘦客户端（三层模式）：分为客户端-服务器端-数据库服务器端，数据库服务器依然进行数据的存取操作，而将原来的应用程序分为两部分，用于实现人机交互的将之放在客户端，将实现业务逻辑应用服务处理的放在应用服务器端。B/S模式客户端只需要通过浏览器来实现对应用程序的访问，在应用程序进行升级的时候，只需要实现对服务器端的应用程序进行升级就行，而不是必须要对每一个客户端都进行程序的升级操作）

软件危机：计算机软甲在开发维护过程当中所遇到的一系列问题称之为软件危机。 1.对软件开发的成本和开发进度估计不准

由于用户和软件开发者对需求的理解不同而导致用户对所开发出来的软件不满意。
软件质量靠不住。
软件的可维护性差。在软件开发当中没有充分的考虑软件后期的维护。
软件没有适当的文档资料。

软件工程：将系统化规范化和可度量的途径应用与软件的开发运行和维护的过程当中，使得软件的发展由个体化转向工程化。

1.3 软件生存周期

定义：软件生存周期是指软件从生产，发展，成熟到衰亡为止的整个过程。

组成：软件的生存周期包括软件定义，软件开发，软件维护三个大的阶段。细分为：可行性研究与计划，需求分析，总体设计，详细设计，实现（编码和单元测试），集成测试，确认测试，使用和维护八个阶段。

可行性研究与计划：确认软件的开发是否具有可行性。成问题定义报告来实现对问题的性质，工程目标以及工程规模进行定义。生成可行性分析报告：用于实现对软件开发的经济可行性，技术可行性和社会可行性（判断其是否违反相关法律或社会道德）进行分析

需求分析：明确系统目标软件具体要实现哪些功能。实现用户对软件功能上的需求分析，性能需求分析等。生成需求分析说明书：来说明软件所要实现的所有的功能，然后共开发人员作为软件开发的目标。（用户将会根据需求分析说明书当中的内容来对所开发出来的软件进行验收操作。）

总体设计：根据需求分析来设计不同的软件总体架构方案，最后来选择性价比较高的一种方案来进行软件的设计操作。生成总体设计说明书：记录总体设计当中的内容。

详细设计：用于对总体设计当中的软件架构当中的每一个具体的功能模块如何进行实现，采用什么样的数据结构和方案。生成详细设计说明书：用于记录每一个功能模块当中所采用的算法与数据结构。

编码与单元测试：用于实现将详细设计阶段当中的每一个具体的功能模块以具体的代码来进行实现，并对每一个具体的模块晋进行单元测试。形成程序清单和单元测试报告。

集成测试：用于实现对由单元测试所组成的模块集合到一起形成一个子系统进行测试操作。形成测试报告用于说明如何进行测试，测试方案以及测试结果。

确认测试：又称之为验收测试，由用户来按照需求规格说明书来进行测试。生成确认测试报告用于记录确认测试当中的方案以及测试的结果。

使用与维护：包括改正性维护（即软件在使用的过程当中发现了问题），适应性维护（即软件的运行环境发生变化），完善性维护（用户要求进行功能的增加或系统性能进行改进），预防性维护（为将来可能要进行的维护做准备）。

1.4 软件生存周期模型

常用的软件过程模型：瀑布模型，快速原型模型，增量模型，螺旋模型，喷泉模型等。

瀑布模型：需求分析（进行验证），书写规格说明（进行验证），程序设计（进行验证），编码（进行测试），综合测试，维护。（特点：每一个阶段都具有顺序性和依赖性，下一个阶段要想进行实现必须要以前一个阶段为基础。具有推迟实现性，在进行编码实现之前充分的进行了需求分析，系统设计尽可能的保证编码之前出现少的错误，以保证编码出现错误的概率降低，提高编码效率。有着较高的质量保证，在每一个阶段都要有相应的文档说明书以保证软件后期的开发和维护，在每一个阶段完成之后都要对该阶段进行评审，以保证该阶段的问题尽可能的在本阶段进行解决，避免该问题在后期出现需要大量的成本进行解决）。缺点：传统的瀑布模型具有理想化在每一个过程当中人们不可能不犯错误（Eg：在需求分析阶段用户很难将一个软件的所有需求功能都获取到），所以对传统的瀑布模型进行了改进，加入了反馈环节即在进行下一个阶段的工作的时候发现上一个阶段当中有错误，可以返回到上一个阶段当中去。优点：能够提高软件的质量，降低维护成本，缓解软件危机。

快速原型模型：首先实现对用户主要功能需求的获取，然后建立一个简要的演示模型给用户然后让用户来对后续需求进行补充。快速原型模型主要是建立一个简单的原型模型，然后由用户不断的根据所建立起来的原型来实现对需求的补充，知道用户没有新的需求之后，才开始进行总体设计，详细设计，编码等后续步骤来实现软件产品的实现。优点：有利与用户需求不明确的时候来进行软件的开发。所建立的原型可能最终成为软件的一部分以及方便用户对软件产品的熟悉。缺点：由于原型模型是短时间之内所进行的开发，所以软件的内部结构可能会不好导致软件产品的质量低下。

增量模型：即不是一次性的将所有的软件功能实现之后再交给用户对象而是将整个软件分为多个构件，每次实现一个构件功能之后先交付给用户，如果用户觉得没有问题则继续进行下一个构件的开发与实现。需求分析（验证）->规格说明（验证）->总体设计（验证）->将整个软件分成多个构件来进行详细设计，编码和实现经测试之后将之交付给用户去使用->维护。优点：可以在较短的时间之内就能够向用户提交一个实现主要功能的产品来供用户使用，有效的缩短软件的开发周期，占用市场。用户能够有足够的时间来适应软件。由于在增量模型当中软件的过个构件是并行实现开发的，所以软件的结构架构一般设计的都比较开放，方便现有产品实现新的软件构件的添加即软件的可扩展性强。缺点：要想实现足够强的可扩展性一般实现的难度比较大。由于多个构件是并行进行开发的，所以在最后当多个构件集成到一起的时候，是否能够实现完美的结合是有一定的风险的。

螺旋模型：多使用与大型软件的开发，因为在螺旋模型当中加入了风险评估环节，指定计划，风险分析，实施开发，客户评估。即首先先建立一个较小的模型，然后进行风险分析和评估，当风险评估没有问题的时候将当前的原型模型先开发出来，将当前的原型交付个客户评估，如果没有问题的话则进入到一个周期当中。即在原有的原型的基础上建立功能更为完善的新的原型对象，并进行新一轮的风险评估。当进入到某一个环节之后，发现风险评估之后超出了预计的风险的话，则停止开发将当前已经完成的原型软件发布出去。优点：对于大型软件来说，可以将风险控制在一定范围之内。缺点：必须要有一套有效准确的风险评估方案才行，否则将会造成灾难性的后果。螺旋模型的开发周期长，不太适合当前市场机制。

喷泉模型：喷泉模型是面向对象模型，具有迭代和无缝的特性。迭代：即通过迭代来实现不断的求精，使得系统当中的某一部分工作被多次重复进行。无缝：在分析设计和编码各个阶段没有明确的边界。优点：由于各个阶段没有明确的界限，所以可以实现同步开发用以节约时间提高效率，适应面向对象的开发。缺点：由于是不断迭代重复进行的，所以在程序的开发过程当中在不断的添加一些新的文档需求说明书等，使得审核的难度加大。

Rational同一过程：RUP当中有9个核心工作流，包括6个核心过程工作流和3个核心支持工作流。

微软过程模型：将整个软件的开发分为规划阶段（项目的目标的到认可则标志着该阶段的完成），设计阶段（软件设计完成标志设计阶段完成），开发阶段（代码的开发完成），稳定阶段（可发布的准备阶段版本完成）和发布阶段（最终软件产品上市）。并为每一个阶段设定一个结束完成的标志。然后重复上述过程一轮就会形成一个新的版本，类似于螺旋模型。

优点：上一个版本当中的问题在下一个版本当中可以的到完成和解决。

2.1结构分析

结构化分析方面的核心思想：分解化解问题（即将一个大的问题分解为多个小的问题来减小问题的规模），物理与逻辑相分离开来（即对问题进行分析的时候先对其逻辑实现进行单独分析，然后再实现对其物理实现进行分析），进行数据和逻辑的抽象（先对问题的逻辑本质进行抽象，然后来对问题进行实现）。

具体步骤：

发现需求：通过与用户交谈提一些相关问题，参观用户的工作流程进行现场考察，向相关用户群体发一些问题调查，与相关领域专家进行交流，参考行业当中相类似的软件来获取相关的功能和性能方面的需求，从网上查找相关内容。
对问题逐步求精：对所发现的需求进行反复多次细化求精，得到一个比较完整准确的需求。
建模：根据所获得的完整的需求来建立一个模型，用一些图形或符号来对所要实现的功能进行一个书面的描写。Eg：由实体-关系图和数据对象描述所组成的数据模型，数据流图和功能规格说明组成的功能流图，由状态转换图和控制规格所组成的行为模型，以及建立一个核心的数据字典用于描述软件当中所产生的一些数据信息。

数据字典：用于实现对软件的使用和所产生的所有的数据信息进行描述。

数据模型：使用E-R图来实现表达，用于实现对数据对象间的关系进行描述

功能模型：DFD图表达（数据流图），用于描述软件当中的一些数据的移动，和状态变换等。

行为模型：用状态转换图来进行表达。用于描述系统当中有哪些状态以及不同状态之间如何进行装换。

编写规格说明书：将所有的分析结果和以及所建立的模型写入到需求规格说明书当中去，作为分析阶段的最终成果。
复审：用于保证在需求分析阶段尽可能的不出问题，避免后期在后期设计阶段出现问题需要花费较高的成本来重新进行修改。

2.2 数据模型

数据模型：由数据对象（学生，教师），数据对象之间的关系（1:1,1:N,N:N）和数据对象的属性（定义数据对象的性质：学号，成绩）所组成的，用于描述不同的数据对象之间的关系。

实体关系图：使用矩形框来表示实体（数据对象），圆角矩形（用于表示数据对象的属性），菱形（用于表示两个实体对象之间的联系）。

2.3 数据流图

数据流图：用于实现对数据信息在系统当中的流动情况的描述。可以作为用户和系统分析员之间进行交流的工具，也是系统设计者和系统分析员之间进行交流的工具。

2.4行为模型

软件的行为有三部分组成：状态，事件（引起事物的状态发生改变）和行为（事物进入某一状态所进行的动作）。

2.5 数据字典

数据字典：对系统当中使用到的所有的数据对象定义的集合。

数组字典定义方法：实现对数据流（数据的名称，数据的作用，数据的来源，以及数据的去向），数据元素（数据元素的名称，数据元素的类型，数据元素的长度，数据元素的取值范围，相关数据元素和其数据结构），数据存储（简述存放的是什么数据，输入数据，输出数据，数据文件的组成结构，数据的存储方式是顺序直接还是关键值，以及数据的存取频率）和处理（处理名，处理编号，简要描述处理所实现的逻辑功能，处理的输入数据流输出数据流，处理的加工逻辑即进一步详细的描述处理的功能）进行定义。

3.1结构化的设计

结构化的设计分为两个大的部分，即一部分是概要设计（将软件的需求转变为多个系统模块）另一部分则是详细设计（详细设计有称之为过程设计，通过对软件的细化，得到软件详细的数据结构和其对应的算法）。

模块化：即在进行软件的设计的过程当中按照一定的原则来将软件划分为一个个较小的相关又相互独立的模块。（将一个问题化分为多个小的问题来进行解决的工作量要小于直接对一个复杂工作进行解决的工作量，所以当将一个软件划分成的模块越多则每一个模块所对应的成本就越低，但是相应的多个模块之间进行接口的维护的工作量就越大）

抽象原理：即在进行问题的解决设计的时候，先实现对问题的本质内容的抽象，而忽略问题的细节。

求精：集中精力先实现对主要问题的解决，对主要问题不断的进行细化。

信息隐藏：每一个模块内部的细节的实现对于调用该模块的其它模块来说是隐藏的，不能够被其它模块进行访问，其它某块只能通过接口来实现对该模块功能的调用。相对独立的模块有利于进行分工合作，容易进行测试（容易进行测试程序的编写）和维护（问题一般是出现在某一个独立的模块当中而不是整个程序当中，进行后期功能扩充也比较方便）

3.2模块独立（内聚和耦合）

耦合：不同软件模块之间的相关联系程度。取决于模块间接口的复杂程度和通过接口的数据量。模块间接口的复杂度越高，通过的数据量越大则模块间的耦合度就越高。

非直接耦合：即两个模块直接能够相互独立的工作，不需要另一个模块。

数据耦合：即两个模块之间通过数据参数来实现信息的传递，则这两个模块之间发生数据耦合。

控制耦合：两个模块之间进行交换的参数信息是一些控制信息，则这两个模块之间所发生的是控制耦合。控制耦合是一种相对联系较为紧密的耦合，接收控制信息的模块依赖于传递信息模块。

公共环境耦合：即两个模块都是通过对公共环境当中的一些参数数据进行调用操作，则这两个模块对象之间所发生的就是公共耦合。当一个模块对象向环境当中进行数据的传输，而另一个模块则从该环境当中实现数据的获取，则是一个相对松散的耦合等价于数据耦合，当两个模块当中即往公共环境当中进行数据的传递，又从公共环境当中进行数据的获取，耦合程度一眼是高于数据耦合而低于控制耦合。

内容耦合：耦合程度很高，一个模块之间实现对另一个模块当中的内部数据进行访问，一个模块没有通过正常的方式直接进入到另一个模块当中（Eg：通过goto来直接跳转到另一个模块对象当中的某一个语句当中去），两个模块之间有一部分代码的内容发生了重叠，一个模块有多个入口。

耦合的原则：尽量使用数据耦合，少用控制耦合，限制公共环境耦合，完全不用内容耦合。

内聚：指的是模块内部各个部分之间的联系的紧密程度。

功能内聚（10）：模块内部的各个部分的对于完成模块当中的某一个功能是必不可少的组成部分，是最紧密的内聚。

顺序内聚（9）：模块内部当中的处理元素数据的顺序是不能够发生改变的，交高的内聚。

通信内聚（7）：即一个模块对象内部的各个功能部分使用相同的输入数据或产生相同的输出数据。

过程内聚（5）：模块内部进行元素的处理的时候是相关的，有特定的次序。是一种中等的内聚模块

时间内聚（3）：多为多个功能模块要求在同一时间之内进行执行操作。Eg：初始化模块当中用于实现程序当中的一些数据的初始化操作的时候，会将这些操作都放入到一个初始化模块当中去。Eg：异常处理模块，用于实现对各种异常信息的处理

逻辑内聚（1）：一个模块在所完成的功能上在逻辑上是相同或相识的。EG：对数据库当中的信息进行操作的时候，，可能会出现的多组查询删除等操作。

偶然内聚（0）：模块内部之间基本没有关联。

3.3启发规则

一：改进软件结构提高模块之间的独立性，使得模块尽量瞒住高内聚低耦合。

模块规模的设计要适中：模块规模太大的话，要进行进一步的分解操作，但是在分解的过程二：当中不应该降低模块之间的相对独立性，模块的规模设计也不能够太小，模块规模太小会导致模块接口直接的复杂程度增加。即一个模块的语句数尽量控制在50--100行当中。

三：模块的深度，宽度，扇入，扇出要适当

深度：软件接口纵向的控制层数，标志着一个系统的大小和复杂程度。

宽度：指的是软件系统横向同一层当中的模块数量的最大值，宽度越大标志着软件的程度越复杂。

扇出：一个模块对象直接进行调用控制的模块的最大数。扇出数一般在3-9之间。

扇入：即该模块对象被多少个上级模块进行调用的最大数值，扇入越大，则表明该模块被共享的程度越大。

四：模块的作用域应该在控制域之内

作用域：指得是受该模块所影响的所有的模块对象。

控制欲：模块本身或模块直接间接调用的模块的集合。

五：降低模块接口的复杂程度

因为模块与模块接口之间是软件发生错误的一个主要的原因。

七：设计单入口单出口

单入口和单出口可以避免内容耦合

3.4面向数据流的设计方法

3.5 人机界面设计

系统响应时间：0.1s-1s之内用户感觉响应及时。

响应时间易变性：即系统响应时间相对于平均响应时间的偏差，偏差越小用户体验越好。

用户帮助测试：包括手册和联机帮助。在联机帮助当中分为集成联机帮助（设计在了软件里面的帮助）和附加联机帮助（系统完成之后，添加到软件当中的）

出错信息处理：要以用户理解为主，出错位置要清晰，以及对处理出错信息的一些建设性意见，可能会造成的后果，保持一些公用的命令Ctrl+C

人机界面设计指南：界面的设计风格尽量一致，在进行交互的时候提供一些有意义的反馈信息，进行一些删除操作的时候要有确认，可以使用一些可以撤销性的操作，提高对话操作效率，软件要具有一定容错率

信息显示：要显示与当前工作有关的信息，显示内容要尽量简洁，出错信息要有意义

进行数据输入的时候：尽量减少用户手动进行数据的输入量

3.6过程设计

结构化程序设计：在程序的设计当中只使用顺序，选择和循环三种控制结构，进行单入口单出口的设计。即在程序当中尽量不使用goto语句。

程序流程图：

盒图N-S图：

3.7面向数据结构的设计方法

Jackson设计方式：

描述数据结构：顺序，选择，重复。

4.1 编码

用于实现将概要设计和详细设计阶段所设计的程序通过代码来进行实现。

机器语言：计算机能够直接进行识别。效率低，重用性低。

汇编语言：使用一些符号来代替机器指令，方便进行记忆。

高级语言：面向用户的语言，编码效率提高，使用性和可移植性高。但程序的执行效率较低

编码风格：编码要简明清晰易懂。

4.2软件测试基础

软件测试的目的：为了发现程序当中所存在的错误而进行执行的程序。

黑盒测试：也称之为功能测试。

白盒测试：即实现对软件内部的逻辑功能进行测试。

测试的准则：

所有的测试都要能够满足用户的需求，测试要应该尽并且不断的进行测试尽早的发现问题。

在测试当中有80%的问题是出现在20%的模块当中。

测试应从小规模进行测试，逐步集成到较大的模块来进行测试。

在测试当中要避免穷举测试（将所有的测试结果都式一遍），应该使用一些适当的方法来进行测试。

测试的时候应该尽可能的让第三方来进行测试。

4.3白盒测试

进行测试用例设计：

白盒测试当中：

进行逻辑覆盖：

语句覆盖：即选择的测试用例能够让程序当中的每一条语句执行一次，是逻辑覆盖当中最弱的一种覆盖。

判定覆盖：所选用的测试让每一个语句能够执行一次之外，每一个判定的真假分支也能够执行一次。比语句覆盖的情况要强，但是在判定测试当中只进行了一半的判定测试即全为true或全为false，在分支判定请阔测试当中依然会出现漏测的情况。

条件判定：即在每一个判定当中可能是由多个不同的条件所组成的，所以在进行测试用例的设计时，要将判定当中的所有的条件所对应的真假情况都要执行一次，即判定当中所有的条件都为真执行一次，所有判定当中的条件都为假也执行一次。并且要保证所选定的测试用例同时要能够实现对所有的语句至少进行一次覆盖操作。

判定/条件覆盖：即所取的测试用例即能够满足判定覆盖又能够满足条件覆盖。判定1和判定二的真假判定都能够执行一次，并且两个判定当中的四个条件的真假也都能够执行一次，程序当中的每一条语句也能够执行一次。

条件组合覆盖：即两个判定当中的四个条件实现所有的组合至少执行一次，两个判定的真假至少执行一次，程序的语句至少执行一次。

Eg：判定一当中：

条件1（T）条件2（T）

条件1（T）条件2（F）

条件1（F）条件2（T）

条件1（F）条件2（F）

判定二当中：

条件3（T）条件4（T）

条件3（T）条件4（F）

条件3（F）条件4（T）

条件3（F）条件4（F）

两组判定当中公有四个条件8种测试用例情况。

正在上传…重新上传取消

结构测试（控制结构测试）：

基本路径测试：对程序当中的所有路径进行测试

进行基本路径测试之前要先计算环形复杂度。

环形复杂度：用于实现对程序逻辑复杂程度进行描述。

V(G)=e-n+2;环形复杂度=边数-结点数+2；

V(G)=图所在平面被划分的区域数；

V(G)=流图当中的判定结点数+1；

确定独立路径：当环形复杂度为5的时候则表明在途中有5条独立的路径。独立路径的找发可以使用深度遍历来进行寻找。

循环测试：

简单循环测试：

0次循环测试：实现对循环入口和出口所进行的测试。

1次循环测试：实现对循环初始值的测试。

2次循环测试：判定最小循环次数是否错误

N次循环测试：判定中间循环是否出错。

Max次循环测试：判定最大值边界循环测试是否出错。

嵌套循环测试：

从最内层循环进行测试，此时所有外层循环都只执行一次，逐层向外进行测试。

4.4 黑盒测试

黑盒测试：用于实现对软件的功能进行测试。

等价类划分：将所要进行测试的数据划分为多个不同的类型，然后从每一个类型当中选取一组典型数据来作为测试用例。在进行等价类的划分的时候除了进行有效类等价域的划分之外，还要进行无效等价类的划分。进行测试用例的设计的时候，要尽可能的实现一条测试用例能够覆盖较多的有效等价类，以减少数据冗余，对于无效等价类来说一条测试用例覆盖一条无效等价类。

边界值分析：边界值测试是对等价类测试的一个补充。实现对边界值，大于边界值，小于边界值等。

错误推测法：根据经验来针对性的进行代码的编写来进行测试。

4.5 测试策略

测试的步骤：单元测试，集成测试，系统测试，验收测试。

单元测试内容：模块接口测试（形参实参等），局部数据结构测试（局部变量的定义，初始化等有没有问题），边界值测试，重要的执行路径测试（模块当中的逻辑结构是否正确），错误处理测试（错误描述是否明确，错误描述与实际是否相同，错误处理是否完善）。

测试方法：

人工测试：

代码审查：测序编写人员实现对代码描述，其它小组人员进行错误查找。

计算机测试：

在对指定的目标模块进行测试的时候需要实现辅助模块的编写操作。辅助模块一般分为两种类型。驱动模块：用于实现对被测试的目标模块进行调用驱动，实现为被测试的目标模块进行测试数据的传递和接收。桩模块：用于供被测试的模块进行调用，以保证被测试的目标模块能够正常执行。

集成测试：主要用于实现对模块与模块接口之间的数据传递进行测试。

数据在穿越接口的过程当中是否发生了丢失。

模块与模块之间功能是否相互影响。

子模块组合起来之后是否能够达到预期的功能。

全局的数据结构，变量等定义是否有问题。

单个模块当中的数据误差集合起来之后是否会被放大超过指定的范围。

测试方法：

非渐增式测试：即当所有的模块开发完毕之后一次性实现对所有的模块进行集成。但是这样进行测试和错误排查的时候难度较大。

渐增式集成：分为自顶向下和自底向上测试两种方式。

回归测试：在进行集成之后，用之前单元测试当中的测试用例重新来重新对集成之后的模块进行测试，开是否有错误发生。一般是对受集成之后影响的模块或修改的模块重新进行测试。

系统测试：

恢复测试：使用不同的方式强制性的另软件出现错误，然后检查软件是否能够进行恢复，恢复测试一般分为自动恢复测试和人工恢复测试两种。

自动恢复测试：当程序出现错误之后，另程序重新进行启动，检查程序是否能够进行重新初始化，数据恢复等。

人工干预恢复：检测人工进行恢复的时间是否在允许的范围之内。

安全测试：一般只要有足够的时间和资源就一定能够对一个系统的安全进行攻破，一般只要攻破系统的代价大于可获取数据的价值的代价，则认为系统就是安全的。

强度测试：使得系统运行的强度高于系统本身能够承担的最大限度。

性能测试：测试软件的性能是否满足用户所要求的性能。

验收测试：以需求规格说明书来为标准进行测试，。

α测试：用户对软件功能进行测试，开发者则在旁边进行相关数据的记录，程序的测试在开发人员的控制范围之内。

β测试：用户将软件产品放入到实际环境当中进行运行测试。开发者是无法控制的测试。

4.6软件调试

软件调试的目的：用于找到错误，明确错误的类型以及对错误进行改进。调试一般根据测试当中的错误报告来进行调试。

调试一般分为两类：1.根据错误能够判定错误的原因。2.根据错误无法直接判定错误的原因，则开发者则通过一些测试用例来进行错误假设猜测和排除。

调试方法：

强行排错。即将程序内存当中的内容进行打印输出，然后进行错误的排查。
在一些关键部分设定输出语句来对可能出现的错误进行排查
使用一些自动化调试工具来实现对错误的排查
根据错误所出现的位置流向推导回溯到错误位置

4.7软件的可靠性

软件的可靠性：程序在给定的时间段之内（该段时间内可能出现过错误，但是又被进行了修复）和环境当中，按照说明规格说明书成功运行的概率。

软件的可用性：程序在摸一个时刻是否能够进行使用。

面向对象的方法

面向对象的方法=对象+类+继承+对象间通过传递消息来实现通信。

面向对象方法学的概念

对象：具有相同状态的一组集合，对这一状态集合操作进行的封装。

类：对具有相同或相识状态的操作进行的分装，即实现对相识类的分装操作。

实例：由某个特定的类进行描述的一个具体对象。

消息：要求某个对象所执行的某些操作。包括接收消息的对象，消息名，和变量。

方法：对象当中要执行的一组操作，即类当中所定义的服务。

属性：类中所定义的一些数据用于实现对现实世界当中事物的一些特性进行映射。

继承：子类可以实现对父类当中所定义的方法和属性进行共享的一种机制。

多态性：多态即子类能够实现对其所继承的父类当中的方法进行重写，使得不同的子类对于所继承的同一个父类当中的方法进行不同方式的重写，进而表现出不同的功能。

重载：在同一个类当中方法的名字相同，而其所拥有的参数个数或类型不同，实现对功能相似的一些方法进行定义。

面向对象的方法更好的与人类的思维向符合，对象实现了对现实事物的抽象，软件的稳定性，可重用性较好，封装性好。

5.2UML简介

建模的必要性：为了实现对现实世界当中的一些复杂问题的本质进行抽象表达出来。

UML建模有点：能够实现不同领域之间的沟通，将复杂问题进行分解，实现软件架构的定义，实现一些可复用模块的建立。

UnifiedModelingLanguage：同一建模语言。

5.3静态视图：

用例视图：定义了系统的需求，外部行为，用于实现外对外部执行者和用户系统进行交互的描述。

用例：系统外部执行者与计算机之间完成的一次典型的交互操作，代表系统的某一完整功能。

类图：描述系统当中的类和类之间的关系。

类的可见性：public（可供外部对象进行访问），private（只能够被本类进行访问），protected（只能被本类及其子类进行访问）。

边界类：位于系统和用户交界处的一些类。控制类：控制某一个具体的用例功能当中的事件的发生顺序。实体类：用于对对必须进行存储的类和相关行为的类进行的定义操作。接口类：描述一个类当中所应提供的一些方法的声明，不包含属性。

类图间的关系：关联，泛化（继承），依赖，实现。

关联关系：

普通关联：关联关系是双向的，用实现来实现对两个类之间进行连接。

导航关联：具有方向性，用实线箭头来连接。

聚合关系：是一种较弱的实现对整体和部分之间所进行的描述，当部分消失的时候整体不一定会消失。

组合关系：是一种较强的整体与部分关系。即部分是完全依赖于整体的，当部分消失的时候整体也会消失。

泛化关系（继承）：是一种用于描述一般与特殊之间的关系。

依赖关系：一种模型的变化必然会对另一种模型对象造成影响。

实现关系：用于描述一个类由另一个对象进行描述。

对象图：用于表示对象之间的相互关系，对象图是类图的实例。

5.4动态视图：

消息：

简单消息：没有描述通信细节的消息。

同步消息：调用者在发送消息之后，只有等待接收到消息返回后的响应之后才会继续进行执行。

异步消息：调用者在发出消息之后，不等待消息的返回就继续进行执行。

返回消息：代表从过程调用当中返回的一些信息。

顺序图：用于描述不同对象相互之间进行消息的交互操作。顺序图侧重于以交互时间来进行描述。

协作图：侧重于描述对象之间相互进行交互的关系和链接关系。

活动图：用于描述为了完成某一个用例而需要进行的活动以及这些活动的执行次序。

5.5UML物理架构机制

物理架构：关心的是实现，类和对象物理上分布在那个程序或进程当中，程序在那台计算机当中进行运行，系统当中有哪些硬件设备，如何进行连接，构件图和配置图。

构件图：构件代表一个系统的物理实现块，构件图则展现了一组构件的类型，以及内部结构和它们之间的依赖关系。

配置图：描述了系统硬件和软件的物理配置和系统的体系结构。

6.1 面向对象分析

7.1 面向对象设计

面向对象分析：实现对用户的需求进行提取分析建立对应的问题域和模型的方法。

面向对象设计：将所建立的需求模型转变为具体的系统的实现方案

面向对象设计的准则：

抽象，通过类来实现抽象的原则以提高代码的复用率。

隐藏，通过类的分装来实现类中数据信息的隐藏，来提高独立性，用户只需要通过接口来进行调用对象，而不用关心内部的实现方式。

弱耦合，不同的类和对象之间信息传递的参数值要进可能的简化以降低耦合度。

高内聚。

可重用性，提高设计的可重用性。

启发规则：1.设计的结构要清晰。2.设计结构的深度以7+/-2为准。3.对象间进行信息传递的时候尽量使用简单的协议。5.使用一些简单的服务。