关于软件开发相关知识的记录（超详细！）

目录

1.结构化程序设计

2.面向对象的基本概念

3.面向对象的主要特征

4.面向对象的方法

5.软件规模度量

6. UML

7.软件开发模型

8.CMM模型

9.软件测试

10.白盒测试和黑盒测试

---

内容有点多，想了解哪一个就跳过去吧！

1.结构化程序设计

结构化程序设计是以模块功能和详细处理过程设计为主的一种传统的程序设计思想，通常采用自顶向下、逐步求精的方式进行。在结构化程序设计中，任何程序都可以由顺序、选择、循环三种基本结构构成。结构化程序往往采用模块化设计的思想来实现，其基本思路是:任何复杂问题都是由若干相对简单的问题构成的。从这个角度来看，模块化是把程序要解决的总目标分解为若干个相对简单的小目标来处理，甚至可以再进一步分解为具体的任务项来实现。每一个小目标就称为一个模块。由于模块相互独立，因此在模块化的程序设计中，应尽量做到模块之间的高内聚低耦合。也就是说，功能的实现尽可能在模块内部完成，以降低模块之间的联系，减少彼此之间的相万影响。

2.面向对象的基本概念

(1)对象
对象简单来说就是要研究的任何事物，可以是自然界的任何事物，如一本书、一条流水生产线等都可以看作是对象，它不仅能表示有形的实体，也能表示抽象的规则、计划或事件等。对象由数据和作用于数据的操作构成一个独立整体。从程序设计者来看,对象是一个程序模块;从用户来看，对象可以提供用户所希望的行为。
(2)类
类可以看作是对象的模板。类是对一组有相同数据和相同操作的对象的定义，一个类所包含的方法和数据描述是一组对象的共同属性和行为。类是在对象之上的抽象，对象则是类的具体化，是类的实例。面向对象的程序设计语言通过类库来代替传统的函数库，程序设计语言的类库越丰富，则该程序设计语言越成熟。面向对象的软件工程可以把多个相关的类构成一个组件。

(3)消息和方法
对象之间进行通信的机制叫做消息。在对象的操作中，当一个消息发送给某个对象时，消息包含接收对象去执行某种操作的信息。发送一条消息至少要包括接收消息的对象名、发送给该对象的消息名等基本信息，通常还要对参数加以说明，参数一般是认识该消息的对象所知道的变量名。类中操作的实现过程叫做方法，一个方法有方法名、参数等信息。

3.面向对象的主要特征
 

(1)继承性
继承性是子类自动共享父类的数据结构和方法的一种机制。在定义和实现一个类时，可以在一个已经存在的类的基础上来进行，把这个已经存在的类所定义的内容作为自己的内容，并加入若干新的内容。继承性是面向对象程序设计语言不同于其他语言的最重要的特点。在类层次中，子类若只继承一个父类的数据结构和方法，则称为单重继承;若是子类继承了多个父类的数据结构和方法。则称为多重继承。在软件开发中，类的继承性使所建立的软件具有开放性和可扩充性。它简化了对象和类的创建工作量，增加了代码的可重用性。
(2)多态性
多态性是指相同的操作、函数或过程可作用于多种不同类型的对象上，并获得不同的结果。不同的对象收到同一个消息可以产生不同的结果，这种现象称为多态性。多态性允许每个对象以适合自身的方式去响应共同的消息，也增强了软件的灵活性和重用性。
(3)封装性
封装是一种信息隐蔽技术，它体现在类的说明，是对象的一种重要特性。封装使数据和加工该数据的方法变为一个整体以实现独立性很强的模块，使得用户只能见到对象的外部特性，而对象的内部特性对用户是隐蔽的。封装的目的在于把对象的设计者和使用者分开，使用者不必知道行为实现的细节，只须用设计者提供的消息来访问该对象即可。

4.面向对象的方法

面向对象开发方法主要有Booch方法、Coad方法和 OMT方法等。
(1)Booch方法
Booch方法最先探讨面向对象的软件开发方法中的基础问题，认为面向对象开发是一种根本不
同于传统的功能分解的设计方法，软件分解应该最接近人对客观事务的理解。Booch方法可分为逻
辑设计和物理设计，其中逻辑设计包含类图文件和对象图文件;物理设计包含模块图文件和进程图
文件，用以描述软件系统结构。Booch方法中的基本概念有:
●类图:描述类与类之间的关系。
●对象图:描述实例和对象间传递消息。
●模块图:描述构件。
●进程图:描述进程分配处理器的情况。
Booch方法也可划分为静态模型和动态模型，其中静态模型表示系统的构成和结构;动态模型
表示系统执行的行为。动态模型又包含时序图和状态转换图。

●时序图:描述对象图中不同对象之间的动态交互关系。
●状态图:描述一个类的状态变化。
(2)Coad方法
该方法是多年来开发大系统的经验与面向对象概念的有机结合，在对象、结构、属性和操作的认定方面提出了一套系统的原则。Coad方法可分为面向对象分析(OOA)和面向对象设计(OOD)两部分。在OOA中建立了概念模型，由类与对象、属性、服务、结构和主题等5个分析层次组成。
●类与对象:从问题域和文字出发，寻找并标识类与对象。
●属性:确定对象信息及其之间的关系。可分为原子概念层的单个数据和类结构中的公有属性与特定属性。
●服务:标识消息连接和所有服务说明。
●结构:标识类层次结构，确定类之间的整体部分结构与通用特定结构。
●主题:主题是比结构更高层次的模块，与相关类一起控制着系统的复杂度。

面向对象设计(OOD)就是根据已建立的分析模型，运用面向对象技术进行系统软件设计，它将OOA模型直接变成OOD模型。

(3)OMT 方法
该方法认为开发工作的基础是对真实世界的对象建模，然后围绕这些对象使用分析模型来进行独立于语言的设计，面向对象的建模和设计促进了对需求的理解，有利于开发更清晰、更容易维护的软件系统。

5.软件规模度量

准确的软件规模度量是科学进行项目工作量估算、计划进度编制和成本预算的前提。软件规模
度量有助于开发人员把握开发时间、费用等。常用的方法有以下几种:
(1)代码行
代码行(lineofcode)指所有可执行的源代码行数。此方法的问题是只能等软件开发完毕之后才能准确地计算，而且越是高级的语言，实现同样的功能其代码行越多，因此现在已经很不准确了，在现代软件工程中不再使用此方法。
(2)功能点分析法
功能点分析法(Function Point Analysis，FPA)是在软件需求分析阶段依据系统功能的一种规模估算方法，由IBM的研究人员提出的，随后被国际功能点用户协会(The International Function Point UsersGroup，IFPUG)提出的IFPUG方法继承。从系统的复杂性和特性两个角度来度量软件的规模，根据具体方法和编程语言的不同，功能点可以转换为代码行。
(3)德尔菲法
德尔菲法(Delphi Technique)是最流行的一种专家评估技术，这种方式适用于评定过去与将来、新技术与特定程序之间的差别，这个结果会受专家的影响，利用德尔菲技术可以尽量减少这种影响。

(4)构造性成本模型
构造性成本模型(Constructive Cost Model，COCOMO)是一种精确的、易于使用的基于模型的成本估算方法。该模型按其详细程度分为三种:基本模型、中间模型和详细模型

基本模型是一个静态模型;中间模则在基本模型的基础上，再参考产品、硬件、人员等因素的影响来调整工作量的估算:详细模型在中间模型的基础上，还要考虑对软件工程过程中的分析和设计
等的影响。

6. UML

UML最早由著名的Jim Rumbaugh、Ivar Jacobson和GradyBooch创造，因为他们各自的建模方法(分别是OMT、OOSE和Booch)彼此之间存在竞争。最终，他们一起创造了一种开放的标准。UML成为标准建模语言主要是因为它与程序设计语言无关。而且，UML符号集只是一种语言，而不是一种方法学。因为是一种语言，所以可以在不做任何更改的情况下很容易地适应各种业务运作方式。
UML提供了多种类型的模型描述图(Diagram)，当使用这些图时，UML使得开发中的应用程序更易理解。这些最常用的 UML 图包括用例图、类图、序列图、状态图、活动图、组件图和部署图

(1)用例图
用例图描述了系统提供的一个功能单元，帮助开发人员以一种可视化的方式理解系统的功能需求。
(2)类图
类图表示不同的实体如何彼此相关，换句话说，它显示了系统的静态结构。类图可用于表示逻辑类(通常就是业务人员所谈及的事物种类)和实现类(程序员处理的实体)。
(3)序列图
序列图显示具体用例的详细流程。它几乎是自描述的，并且显示了流程中不同对象之间的调用关系，同时还可以很详细地显示对不同对象的不同调用。
(4)状态图
状态图表示某个类所处的不同状态和该类的状态转换信息。
(5)活动图
活动图表示在处理某个活动时，两个或多个类对象之间的过程控制流。活动图可用于在业务单元的级别上对更高级别的业务过程进行建模，或者对低级别的内部类操作进行建模。
(6)组件图
组件图提供系统的物理视图，显示系统中的软件对其他软件的依赖关系。
(7)部署图
部署图表示该软件系统如何部署到硬件环境中。用于显示该系统不同的组件将在何处运行，以及将如何彼此通信。

7.软件开发模型

软件开发模型(Software Development Model)是指软件开发的全部过程、活动和任务的结构框架。其主要过程包括需求、设计、编码、测试及维护阶段等环节。软件开发模型使开发人员能清晰、直观地表达软件开发的全过程，明确了解要完成的主要活动和任务。对于不同的软件，通常会采用不同的开发方法和不同的程序设计语言，并运用不同的管理方法和手段。现在软件开发过程中，常用的软件开发模型可以概括成以下六类:
(1)瀑布模型
瀑布模型是最早出现的软件开发模型，它将软件生命周期分为制定计划、需求分析、软件设计、
程序编写、软件测试和运行维护六个基本活动，并且规定了它们自上而下、相互衔接的固定次序，
如同瀑布流水，逐级落下，因此形象地称为瀑布模型。在瀑布模刑中，软件开发的各项活动业格按
照线性方式组织，当前活动依据上一项活动的工作成果完成所需的工作内容。当前活动的工作成果
需要进行验证，若验证通过，则该成果作为下一项活动的输入继续进行下一项活动，否则返回修改。尤其要注意的是瀑布模型强调文档的作用，并在每个阶段都进行仔细验证。由于这种模型的线性过程太过理想化，已不适合现代的软件开发模式。
(2)快速原型模型
快速原型模型首先建立一个快速原型，以实现客户与系统的交互，用户通过对原型进行评价，进一步细化软件的开发需求，从而开发出令客户满意的软件产品。因此快速原型法可以克服瀑布模型的缺点，减少由于软件需求不明确带来的风险。因此快速原型的关键在于尽可能快速地建造出软件原型，并能迅速修改原型以反映客户的需求。
(3)增量模型
增量模型又称演化模型，增量模型认为软件开发是通过一系列的增量构件来设计、实现、集成
和测试的，每一个构件由多种相互作用的模块构成。增量模型在各个阶段并不交付一个完整的产品。而仅交付满足客户需求子集的一个可运行产品即可。整个产品被分解成若干个构件，开发人员逐个构件地交付产品以便适应需求的变化，用户可以不断地看到新开发的软件，从而降低风险。但是需求的变化会使软件过程的控制失去整体性。

(4)螺旋模型
结合了瀑布模型和快速原型模型的特点，尤其强调了风险分析，特别适合于大型复杂的系统。螺旋模型沿着螺线进行若干次迭代以实现系统的开发，是由风险驱动的，强调可选方案和约束条件，从而支持软件的重用，因此尤其注重软件质量。
(5)喷泉模型
喷泉模型也称为面向对象的生存期模型，相对传统的结构化生存期而言其增量和迭代更多。生存期的各个阶段可以相互重叠和多次反复，而且在项目的整个生存期中还可以嵌入子生存期。就像喷泉水喷上去又可以落下来，可以落在中间，也可以落在最底部一样。
(6)混合模型
混合模型也称为过程开发模型或元模型(Meta-Model)，把几种不同模型组合成一种混合模型。它允许一个项目能沿着最有效的路径发展，这就是过程开发模型。在实际的软件开发模型的选择上,通常开发企业为了确保开发都是使用由几种不同的开发方法组成的混合模型。

8.CMM模型

能力成熟度模型(Capability Maturity Model for SoftwareCMM)是对软件组织在定义、实施、度量、控制和改善其软件过程的实践中各个发展阶段的描述。最早是在美国国防部的指导下，由软件开发团体和软件工程学院(SEI)等共同开发的。CMM 的核心是把软件开发视为一个过程，并根据这一原则对软件开发和维护进行过程监控和研究，以使其更加科学化、标准化，使企业能够更好地实现商业目标。CMM 是一种用于评价软件承包能力并帮助其改善软件质量的方法，侧重于软件开发过程的管理及工程能力的提高与评估。CMM分为五个等级:一级为初始级;二级为可重复级;三级为已定义级;四级为已管理级;五级为优化级

●初始级:这个级别的特点是无秩序，甚至是混乱。整个软件开发过程中没有一个标准的规范或步骤可以遵循的一种状态，所开发的软件产品能否取得成功往往取决于个别人的努力或机遇初始级的软件过程是一种无定义的随性过程，项目的执行也很随意。
●可重复级:这个级别已经建立了最基本的项目管理过程，可以对成本、进度等进行跟踪管理。对类似的软件项目，可以借鉴之前的成功经验来获职成功。也就是说，在软件管理过程中，一个可以借鉴的成功的过程是一个可重复的过程，并且这个重复能逐渐完善和成熟。
●可定义级:这个级别已经用于管理和工程的软件过程标准化，并形成相应的文档进行管理。各种项目都可以采用结合实际情况修改后的标准软件过程来进行操作。此级别中的过程管理口以遵照形成了标准的文档执行，各种开发的项目都需要根据这个标准进行操作。
●可管理级:这个级别通过详细的度量标准来衡量软件过程和产品质量，实现了质量的和管理的量化。
●优化级:这个级别通过将新方法、新技术等各种有用信息进行定量分析，从而持续地对软件过程和管理进行改进。

9.软件测试

软件测试是软件开发过程中的一个重要环节，其主要目的是检验软件是否符合需求，尽可能多地发现软件中潜在的错误并加以改正。测试的对象不仅有程序部分，还有整个软件开发过程中各个阶段产生的文档，如需求规格说明、概要设计文档等。根据软件开发过程中阶段的不同，可以分为

单元测试、集成测试、系统测试、验收测试和回归测试
根据动态测试在软件开发过程中所处的阶段和作用，动态测试可分为:单元测试、集成测试、系统测试、验收测试和回归测试。
(1)单元测试
单元测试是对软件中的基本组成单位进行的测试，如一个模块、一个过程等，是最微小规
模的测试。它是软件动态测试最基本的部分，也是最重要的部分之一，其目的是检验软件基本
组成单位的正确性。一个软件单元的正确性是相对于该单元的规约而言的，因此单元测试以被测试单位的规约为基准。典型的由程序员而非测试员来做，因为它需要工作人员知道内部程序
设计和编码的细节知识。
(2)集成测试
集成测试是指一个应用系统的各个部件的联合测试，以决定其能否在一起共同工作而没有冲突。部件可以是代码块、独立的应用、网络上的客户端或服务器端程序。这种类型的测试尤其与客户服务器和分布式系统有关。一般在集成测试前单元测试已经完成。集成测试是单元测试的逻辑扩展，其最简单的形式是：两个已经测试过的单元组合成一个组件，并且测试它们之间的接口。从这一层
意义上讲，组件是指多个单元的集成聚合。

在现实方案中，许多单元组合成组件，而这些组件又聚合成程序的更大部分。方法是测试片段的组合并最终扩展讲程，将模块与其他组的模块一起测试。最后，将构成讲程的所有模块一起测试。此外，如果程序由多个进程组成，应该对其进行成对测试，而不是同时测试所有进程。集成测试识别组合单元时出现的问题。通过使用要求在组合单元前测试每个单元，并确保每个单元的生存能力的测试计划，可以知道在组合单元时所发现的任何错误很可能与单元之间的接口有关。这种方法将可能发生的情况数量减少到更简单的分析级别系统测试。
(3)系统测试
系统测试的对象不仅包括需要测试的产品系统的软件，还包括软件所依赖的硬件、外设甚至其些数据、某些支持软件及其接口等。因此，必须将系统中的软件与各种依赖的资源结合起来，在系统实际运行环境下进行测试。

(4)验收测试
验收测试是指系统开发生命周期方法的一个重要阶段，也是部署软件之前的最后一个测试操作。
测试目的就是确保软件准备就绪，并且可以让最终用户能执行该软件的实现既定功能和任务。测试
中，相关的用户或独立测试人员根据测试计划和结果对系统进行测试和接收，让系统用户决定是否
接收系统。它是一项确定产品是否能够满足合同或用户所规定的需求的测试。验收测试一般有三种
策略:正式验收、非正式验收、a测试、B测试。

●正式验收。
正式验收测试是一项管理严格的过程，它通常是系统测试的延续。计划和设计这些测试的周密和详细程度甚至超过系统测试。正式验收测试一般是开发组织与最终用户组织的代表一起执行的。也有一些完全由最终用户组织执行。
●非正式验收
在非正式验收测试中，执行测试过程的限制不如正式验收测试中那样严格。测试过程中，主要是确定并记录要研究的功能和业务任务，但没有可以遵循的特定测试用例。测试内容由各测试员决定。这种验收测试方法不像正式验收测试那样组织有序，并且主观性比较大。
●测试(AlphaTesting)
又称Alpha测试，是由一个用户在开发环境下进行的测试，也可以是公司内部的用户在模拟实际操作环境下进行的受控测试，Alpha测试不能由该系统的程序员或测试员完成。在系统开发接近完成时对应用系统进行的测试;测试后仍然会有少量的设计变更。这种测试一般由最终用户或其他人员来完成，不能由程序员或测试员完成。
●测试(Beta Testing)。
又称Beta测试、用户验收测试(UAT)。测试是软件的多个用户在一个或多个用户的实际使用环境下进行的测试。开发者通常不在测试现场，Beta测试不能由程序员或测试员完成。当开发和测试基本完成时所做的测试，而最终的错误和问题需要在发行前找到。这种测试一般由最终用户或其他人员完成，不能由程序员或测试员完成。
(5)回归测试
回归测试是指在发生修改之后重新测试之前的测试以保证修改的正确性。理论上，软件产生新版本都需要进行回归测试，验证之前发现和修复的错误是否在新软件版本上再次出现。根据修复好了的缺陷再重新进行测试。回归测试的目的在于验证之前出现过但已经修复好的缺陷不再重新出现。一般指对某已知修正的缺陷再次围绕它原来出现时的步骤重新测试。通常确定所需的再测试范围时是比较困难的，特别当临近产品发布日期时。因为为了修正某缺陷必须更改源代码。因而就有可能影响这部分源代码所控制的功能。所以在验证修好的缺陷时不仅要服从缺陷原来出现时的步骤重新测试，而且还要测试有可能受影响的所有功能。因此应当对所有回归测试用例进行自动化测试。

10.白盒测试和黑盒测试

（1）白盒测试(White Box Testing)
又称结构测试或逻辑驱动测试。它是把测试对象看作一个能打开、可以看见内部结构的盒子。
利用白盒测试法对软件进行动态测试时，主要是测试软件产品的内部结构和处理过程，而不关注软
件产品的功能。白盒测试法中对测试的覆盖标准主要有;逻辑覆盖、循环覆盖和基本路径测试。由于知道产品内部的工作过程，因此白盒测试可以检测产品内部动作是否按照规格说明书的规定正常
进行，按照程序内部的结构测试程序，检验程序中的每条通路是否都有能按预定要求正确工作而不
顾它的功能，白盒测试的主要方法有逻辑驱动、基路测试笔，通常用于软件验证。

（2）黑盒测试(Black Box Testing)
又称功能测试或数据驱动测试。是根据软件的规格进行的测试，这类测试把软件看作一个不能打开的盒子，因此不考虑软件内部的运作原理。软件测试人员以用户的角度，通过各种输入和对应的输出结果来发现软件存在的缺陷，而不关心程序具体是如何实现的。