1、软件工程

软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件并对上述方法的研究。
软件要经历从需求分析、软件设计、软件开发、运行维护，直至被淘汰这样的全过程，这个过程称为软件的生命周期。
为了使软件生命周期中的各项任务能够有序地按照规程进行，需要一定的工作模型对各项任务给予规程约束，这样的工作模型称之为软件生命周期模型。

主要的开发模型有：

• 瀑布模型
• 原型化模型
• 螺旋模型
• 喷泉模型
• 智能模型
• 增量模型
• 迭代模型
• 构件组装模型
• V模型
• 快速应用开发模型
• 敏捷方法
• 统一过程(UP)

一、瀑布模型
瀑布模型也称为生命周期法，是结构化方法中最常用的开发模型，它把软件开发的过程分为软件计划、需求分析、软件设计、程序编码、软件测试和运行维护6个阶段。

瀑布模型的优点：
(1)为项目提供了按阶段划分的检查点。
(2)当前一阶段完成后，只需要去关注后续阶段。
(3)它提供了一个模板，这个模板使得分析、设计、编码、测试和支持的方法可以在该模板下有一个共同的指导。

瀑布模型的缺点：

• (1)各个阶段之间产生大量的文档，极大地增加了工作量。
• (2)由于开发模型是线性的，用户只有等到整个过程的末期才能见到开发成果，从而增加了开发风险。
• (3)不适应用户需求的变化，并且在需求分析阶段不可能完全获取。
• (4)在软件开发前期未发现的错误传到后面的开发活动中时，可能会扩散，进而可能会导致整个软件项目开发失败。所以，瀑布模型适用于需求明确或很少变更的项目

二、原型化模型
指在获取一组基本的需求定义后，利用高级软件工具可视化的开发环境，快速地建立一个目标系统的最初版本，并把它交给用户试用、补充和修改，再进行新的版本开发。反复进行这个过程，直到得出系统的“精确解”，即用户满意为止。

1.原型的分类
从原型是否实现功能来分，软件原型可分为：

• 水平原型
• 垂直原型

从原型的最终结果来分，软件原型可分为：

• 抛弃型原型
• 演化型原型

原型法适合于用户需求不明确的场合。
它是先根据已给的和分析的需求，建立一个原始模型，这是一个可以修改的模型。在软件开发的各个阶段都把有关信息相互反馈，直至模型的修改，使模型渐趋完善。在这个过程中，用户的参与和决策加强了，缩短了开发周期，降低了开发风险，最终的结果是更适合用户的要求。原型法成败的关键及效率的高低，在于模型的建立及建模的速度。

三、螺旋模型
将瀑布模型和演化模型相结合，综合了两者的优点，并增加了风险分析。它以原型为基础，沿着螺线自内向外旋转，每旋转一圈都要经过制订计划、风险分析、实施工程及客户评价等活动，并开发原型的一个新版本。经过若干次螺旋上升的过程，得到最终的系统。

螺旋模型的优点：

• (1)设计上灵活，可以在项目的各个阶段进行变更；
• (2)以小的分段来构建大型系统，使成本计算变得简单容易；
• (3)客户始终参与每个阶段的开发，保证了项目不偏离正确方向；
• (4) 随着项目推进，客户始终掌握项目的最新信息 , 从而能够和管理层有效地交互。

螺旋模型的缺点：

• (1) 需要具有相当丰富的风险评估经验和专门知识，如果未能够及时标识风险，势必造成重大损失；
• (2)过多的迭代次数会增加开发成本，延迟提交时间。

四、喷泉模型
是一种以用户需求为动力，以对象为驱动的模型，主要用于描述面向对象的软件开发过程，该模型认为软件开发过程自下而上的，各阶段是相互迭代和无间隙的。无间隙是指在开发活动中，分析、设计和编码之间不存在明显的边界。

五、智能模型
是基于知识的软件开发模型，它把瀑布模型和专家系统结合在一起，利用专家系统来帮助软件开发人员的工作。该模型应用基于规则的系统，采用归约和推理机制，帮助软件人员完成开发工作，并使维护在系统规格说明中一级进行。
该模型在实施过程中要建立知识库，将模型本身、软件工程知识与特定领域的知识分别存入数据库。

六、增量模型
融合了瀑布模型的基本成分和原型实现的迭代特征。当使用增量模型时，第一个增量往往是核心的产品，即第一个增量实现了基本的需求。客户对每一个增量的使用和评估都作为下一个增量发布的新特征和功能，这个过程在每一个增量发布后不断重复，直到产生了最终的完善产品。

增量模型与原型实现模型和其他演化方法一样，本质上是迭代的，但与原型实现不一样的是其强调每一个增量均发布一个可操作产品。
增量模型的特点是引进了增量包的概念，无须等到所有需求都出来，只要某个需求的增量包出来即可进行开发。

增量模型优点：
(1) 人员分配灵活，初期不用太大投入。
(2) 每隔一小段时间就提交用户部分功能，用户可以直观感受项目进展，及时试用产品功能。
(3) 有利于风险的把控。
增量模型将功能细化、分别开发的方法适应于需求经常改变的软件开发过程。

增量模型缺点：

• (1)由于各个构件是逐渐并入已有的软件体系结构中的，所以加入构件必须不破坏已构造好的系统部分，这需要软件具备开放式的体系结构。
• (2)需求的变化是不可避免的。增量模型的灵活性使其适应这种变化，但也很容易退化为边做边改，使软件过程的控制失去整体性。
• (3)如果增量包之间存在相交的情况且未很好处理，则必须做全盘系统分析。

七、迭代模型
迭代模型，摒弃了传统的需求分析，设计，编码，测试的流程，而是将整个生命周期变成若干个冲刺（Sprint）阶段，每一个阶段都是由以上若干或者全部传统的流程组成，在每一个阶段中，都包含下面阶段：初始阶段，细化阶段，构建阶段，交付阶段。

• 在迭代模型中，每一次的迭代都会产生一个可以发布的产品，这个产品是最终产品的一个子集。
• 迭代模型适用于项目事先不能完整定义产品所有需求、计划多期开发的软件开发。

八、构件组装模型
基于构件的软件开发(CBSD)模型是利用模块化方法，将整个系统模块化，并在一定构件模型的支持下，复用构件库中的一个或多个软件构件，通过组合手段高效率、高质量地构造应用软件系统的过程。CBSD模型融合了螺旋模型的许多特征，本质上是演化型的，开发过程是迭代的。

基于构件的软件开发方法由5个阶段组成：

• 需求分析和定义
• 体系结构设计
• 构件库的建立
• 应用软件构建
• 测试和发布

基于构件的软件开发的优点：

• (1)提高了软件开发的效率。
• (2)CBSD允许多个项目同时开发，降低了费用。
• (3)提高了可维护性和产品质量。

基于构件的软件开发的缺点：

• (1)由于采用自定义的组装结构标准，缺乏通用的组装结构标准引入具有较大的风险。
• (2)可重用性和软件高效性不易协调，需要精干的、有经验的分析人员和开发人员。
• (3)构件库的质量影响着产品的质量。

九、V模型
单元测试是检测代码的开发是否符合详细设计的要求。单元测试的计划是在软件详细设计阶段完成的。
集成测试是检测测试过的各组成部分是否能完好地结合到一起。
系统测试是检测已集成在一起的产品是否符合系统规格说明书的要求。
验收测试是检测产品是否符合最终用户的需求。

十、快速应用开发
快速应用开发（RAD）模型是一个增量型的软件开发过程模型，强调极短的开发周期。RAD模型是瀑布模型的一个高速变种，通过大量使用可复用构件，采用基于构件的建造方法赢得快速开发。

快速应用开发模型的流程：

• 业务建模
• 数据建模
• 过程建模
• 应用生成
• 测试与交付

十一、敏捷方法
敏捷开发是从20世纪90年代开始逐渐引起广泛关注的一些新型软件开发方法，以应对快速变化的需求。
敏捷开发更强调程序员团队与业务专家之间的紧密协作、面对面沟通、频繁交付新的软件版本、紧凑而自我组织型的团队、能够
很好地适应需求变化的代码编写和团队组织方法，也更注重人的作用。

常见的敏捷开发方法：

• 极限编程（XP）
• 自适应软件开发
• 水晶方法
• 特性驱动开发

从开发者的角度，主要的关注点：

• 短平快会议(Stand Up)
• 小版本发布(Frequent Release)
• 较少的文档(Minimal Documentation)
• 合作为重(Collaborative Focus)
• 客户直接参与(Customer Engagement)
• 自动化测试(Automated Testing)
• 适应性计划调整(Adaptiye Planning)
• 结对编程(Pair Programming)

从管理者的角度，主要的关注点：

• 测试驱动开发(Test-Driven Development)
• 持续集成(Continuous Integration)
• 重构(Refactoring)

敏捷方法适用于中小型软件开发团队，并且客户的需求模糊或需求多变。
这些方法所提出来的一些所谓的“最佳实践”并非对每个项目都是最佳的，需要项目团队根据实际情况来决定。而且，敏捷方法的有些原则在应用中不一定能得到贯彻和执行。

十二、统一过程（UP/RUP）
是一个通用过程框架，可以用于种类广泛的软件系统、不同的应用领域、不同的组织类型、不同的性能水平和不同的项目规模。UP是基于构件的，软件系统建模时，UP使用的是UML。与其他软件过程相比，UP具有三个显著的特点：

• 用例驱动
• 以体系结构为中心
• 迭代和增量

UP中的软件过程在时间上被分解为四个顺序的阶段

• 初始阶段
• 细化阶段
• 构建阶段
• 交付阶段
  每个阶段结束时都要安排一次技术评审，以确定这个阶段的目标是否已经达到。

CMM（能力成熟度模型）

• (1)初始级：软件过程的特点是无秩序的，有时甚至是混乱的。软件过程定义几乎处于无章法和无步骤可循的状态，软件产品所取得的成功往往依赖于极个人的努力和机遇。
• (2)可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪。对类似的应用项目，有章可循并能重复以往所取得的成功。
• (3)已定义级：用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程。
• (4)已管理级：软件过程和产品质量有详细的度量标准。软件过程和产品质量得到了定量的认识和控制。
• (5)优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进。

CMMI（软件能力成熟度模型集成）
与CMM相比，CMMI涉及面更广，专业领域覆盖软件工程、系统工程、集成产品开发和系统采购。
CMMI模型分为5个级别：

• (1)初始级
• (2)已管理级
• (3)严格定义级
• (4)定量管理级
• (5)优化级

2、需求工程

需求工程是包括创建和维护系统需求文档所必需的一切活动的过程，可分为需求开发和需求管理两大工作。

(1)需求开发

• 需求获取
• 需求分析
• 编写规格说明书 (需求定义）
• 需求验证

(2)需求管理

• 定义需求基线
• 处理需求变更
• 需求跟踪

这两个方面是相辅相成的，需求开发是主线，是目标；需求管理是支持，是保障。

需求开发概述
需求开发所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件与其他系统元素的接口细节，定义软件的其他有效性需求，细化软件要处理的数据域。用一句话概括：需求开发主要确定开发软件的功能、性能、数据和界面等要求。

需求的分类
软件需求包括功能需求、非功能需求和设计约束3个方面的内容。

• (1)功能需求：是指系统必须完成的工作，即为了向它的用户提供有用的功能，产品必须执行的动作。
• (2)非功能需求：是指产品必须具备的性能或品质，例如，可靠性、容错性等。
• (3)设计约束：也称为限制条件、补充规约，通常是对解决方案的一些约束说明。

三个处于不同层面下的需求概念：

• (1)业务需求：是指反映组织机构或客户对系统、产品高层次的目标要求，通常问题定义本身就是业务需求。
• (2)用户需求：是指描述用户使用产品必须要完成什么任务以及怎么完成的需求，是从具体用户角度考虑的需求。
• (3)系统需求：是从系统的角度来说明软件的需求，它包括了用特性说明的功能需求，质量属性及其他非功能需求，还有设计约束等。

需求获取

• (1)用户访谈
• (2)用户调查
• (3)现场观摩
• (4)阅读历史文档
• (5)联合讨论会

需求捕获的策略
在整个需求过程中，需求捕获、需求分析、需求定义、需求验证四个阶段不是瀑布式的发展，而是迭代式的演化过程。在进行需求捕获时，不要期望着一次就将需求收集完，而是应该捕获到一些信息后，进行相应的需求分析，并针对分析中发现的疑问和不足，带着问题再进行有针对性的需求捕获工作。

需求分析

• (1)结构化分析方法。
• (2)面向对象分析方法。
• (3)面向问题域的分析（PDOA）方法。

需求定义
需求定义的过程就是形成需求规格说明书的过程，通常有两种需求定义方法：

• 严格定义方法
• 原型方法

严格定义方法
严格定义（预先定义）是目前采用较多的一种需求定义方法。在采用严格定义的传统的结构化开发方法中，各个工作阶段排列成一个理想的线性开发序列，在每一工作阶段中，都用上一阶段所提供的完整、严格的文档作为指导文件，因此它本质上是一种顺序型的开发方法。

需求的严格定义建立在以下的假设基础之上：

• (1)所有需求都能够被预先定义
• (2)开发人员与用户之间能够准确而清晰地交流。
• (3)采用图形/文字可以充分体现最终系统。

严格定义的结构化开发方法存在以下缺陷：

• (1)文档量大
• (2)开发过程可见性差，来自用户的反馈太迟

原型方法
原型化的需求定义过程是一个开发人员与用户通力合作的反复过程。从一个能满足用户基本需求的原型系统开始，允许用户在开发过程中提出更好的要求，根据用户的要求不断地对系统进行完善，它实质上是一种迭代的循环型的开发方式。

采用原型方法时需要注意的问题：

• (1)并非所有的需求都能在系统开发前被准确地说明。
• (2)项目参加者之间通常都存在交流上的困难，原型提供了克服该困难的一个手段。
• (3)需要实际的、可供用户参与的系统模型。
• (4)有合适的系统开发环境。
• (5)反复是完全需要和值得提倡的，需求一旦确定，就应遵从严格的方法。

软件需求说明书
软件需求说明书（SRS）是需求开发阶段的成果。

• 是所有子系列项目规划、设计和编码的基础。
• 是软件项目后期开发和维护的基础。
• 是系统测试和用户文档的基础。
  但不应该包括设计、构造、测试或工程管理的细节，也不应该包括对算法的详细过程描述。

需求管理
需求管理通常包括定义需求基线、处理需求变更及需求跟踪方面的工作。
需求跟踪分为正向跟踪和逆向跟踪，合称为“双向跟踪”。

• 不论采用何种跟踪方式，都要建立与维护需求跟踪矩阵。
• 需求跟踪矩阵保存了需求与后续工作成果的对应关系，通过需求跟踪矩阵可以跟踪一个需求使用期限的全过程，即从需求源到实现的前后生存期。

3、系统分析与设计

系统分析的基本任务是在充分了解用户需求的基础上，把对新系统的理解表达为系统需求规格说明书。
系统设计的目标是根据系统分析的结果，完成系统的构建过程。其主要目的是绘制系统的蓝图，权衡和比较各种技术和实施方法的利弊，合理分配各种资源，构建新系统的详细设计方案和相关模型，指导系统实施工作的顺利开展。

结构化方法
结构化方法也称为面向功能的软件开发方法或面向数据流的软件开发方法。它利用图形表达用户需求，强调开发方法的结构合理
性以及所开发软件的结构合理性。结构化开发方法提出了一组提高软件结构合理性的准则，如分解与抽象、模块独立性、信息隐蔽等。
针对软件生存周期的不同阶段，结构化方法又包括结构化分析(SA)、结构化设计(SD)和结构化编程(SP)等方法。

结构化分析(SA)
结构化分析方法给出一组帮助系统分析人员产生功能规约的原理与技术。它一般利用图形表达用户需求，使用的手段主要有数据流图、数据字典、结构化语言、判定表以及判定树等。结构化分析的常用手段是数据流图(DFD)和数据字典(DD)。

• 1)数据流图DFD
  DFD 建模方法的核心是数据流，从应用系统的数据流着手以图形方式描述一个业务系统中的数据流从输入到输出的变换过程。
  

数据流图DFD由4种基本元素(模型对象)构成:

• (1)数据流(Data Flow)。
  数据流用一个带有名字的箭线表示，名字表示流经的数据，箭头表示流向。
  如“订单信息”，它由商品名、订购数量、产地、单价等数据组成。
  

• (2)加工(处理)。表示对数据的加工和转换，加工名包含一个动词。用圆角矩形或圆表示。
  

• (3)数据存储。表示用数据库或文件的形式存储的数据。用开口矩形表示。
  

• (4)外部实体。也称数据源或者数据终点。描述系统数据的提供者或者数据的使用者。外部实体指系统之外的人、物或者其它系统。
  

数据字典
数据字典(DD)对数据流程图中的各个元素做出详细的说明和解释。数据流图上所有元素的定义和解释的文字集合就是数据字典。
数据字典包括：

• (1)数据结构：数据流图中数据块的数据结构说明，反映了数据之间的组合关系。
  数据结构描述={数据结构名，含义说明，组成:{数据项或数据结构}}

• (2)数据项：数据流图中数据块的数据结构中的数据项说明。数据项是不可再分的数据单位。
  数据项描述={数据项名，数据项含义说明，别名，数据类型，长度，取值范围，取值含义，与其他数据项的逻辑关系}

• (3)数据流：数据流图中流线的说明。数据流是数据结构在系统内传输的路径。
  数据流描述={数据流名，说明，数据流来源，数据流去向，组成:{数据结构}，平均流量，高峰期流量}

• (4)数据存储：数据流图中数据块的存储特性说明。数据存储是数据结构停留或保存的地方，一般是数据流的来源和去向之一。
  数据存储描述={数据存储名，说明，编号，流入的数据流，流出的数据流，组成:{数据结构}，数据量，存取方式}

• (5)处理过程：数据流图中功能块的说明。数据字典中只需要描述处理过程的说明性信息。
  处理过程描述={处理过程名，说明，输入:{数据流}，输出:{数据流}，处理:{简要说明}}

结构化设计
结构化设计(SD)是一种面向数据流的设计方法，它以SRS 和SA阶段产生的数据流图和数据字典等文档为基础，是一个自顶向下、逐步求精和模块化的过程。

1)概要设计
也称为高层设计或总体设计，即将软件需求转化为数据结构和软件的系统结构。
概要设计包括：

• 设计软件的结构
• 确定系统由哪些模块组成
• 每个模块之间的关系

2)详细设计
也称为低层设计，即对结构图进行细化，得到详细的数据结构与算法。详细设计的任务就是为每个模块进行设计。
采用自顶向下、逐步求精的设计方式和单入口单出口的控制结构。
使用的工具包括：

• 程序流程图
• 盒图(NS流程图)
• PAD图(Problem Analysis Diagram,问题分析图)
• PDL (ProgrmDesign Language,伪代码)

3)模块结构
模块结构是指将程序或系统按照功能或其他原则划分为若干个具有一定独立性和大小的模块，每个模块具有某方面的功能。
模块是组成系统的基本单位，它的特点是可自由组合、分解和变换，系统中任何一个处理功能都可以看成一个模块。
由于模块之间的互相联系越多，模块的独立性就越少，因此，引入衡量模块独立程度的两个标准：耦合和内聚。
我们要求模块之间是**“高内聚、低耦合”。** （容易考选择题 记忆 ☆☆☆☆☆）

(1)内聚
内聚表示模块内部各代码成分之间联系的紧密程度。一个好的内聚模块应当恰好做目标单一的一件事情。
模块的内聚类型

内聚强度从高到低排列如下

内聚类型	描述
功能内聚	完成一个单一功能，各个部分协同工作，缺一不可
顺序内聚	处理元素相关，而且必须顺序执行
通信内聚	所有处理元素集中在一个数据结构的区域上
过程内聚	处理元素相关，而且必须按特定的次序执行
时间内聚	所包含的任务必须在同一时间间隔内执行
逻辑内聚	完成逻辑上相关的一组任务
偶然内聚	完成一组没有关系或松散关系的任务

(2)耦合
耦合表示模块之间联系的程度。
耦合强度从低到高排列如下

耦合类型	描述
非直接耦合	两个模块之间没有直接关系，它们之间的联系完全是通过上级模块的控制和调用来实现的
数据耦合	一组模块借助参数表传递简单数据
标记耦合	一组模块通过参数表传递记录等复杂信息(数据结构)
控制耦合	模块之间传递的信息中包含用于控制模块内部逻辑的信息
通信耦合	一组模块共用了一组输入信息，或者它们的输出需要整合以形成完整数据，即共享了输入或输出
公共耦合	多个模块都访问同一个公共数据环境，公共的数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等
内容耦合	一个模块直接访问另一个模块的内部数据; 一个模块不通过正常入口转到另一个模块的内部:两个模块有一部分程序代码重叠;一个模块有多个入口等

例:软件设计过程中，可以用耦合和内聚两个定性标准来衡量模块的独立程度，耦合衡量不同模块彼此间互相依赖的紧密程度，应采用以下设计原则( )，内聚衡量一个模块内部各个元素彼此结合的紧密程度，以下属于高内聚的是( )。
A.尽量使用内容耦合、少用控制耦合和特征耦合、限制公共环境耦合的范围、完全不用数据耦合
B.尽量使用数据耦合、少用控制耦合和特征耦合、限制公共环境耦合的范围、完全不用内容耦合
C.尽量使用控制耦合、少用数据耦合和特征耦合、限制公共环境耦合的范围、完全不用内容耦合
D.尽量使用特征耦合、少用数据耦合和控制耦合、限制公共环境耦合的范围、完全不用内容耦合

A.偶然内聚 B.时间内聚 C.功能内聚 D.逻辑内聚

答案： B 、 C
解析：
内容耦合耦合性最强，模块的独立性最弱，因此不应该使用内容耦合。根据题干信息，数据耦合在这里耦合性最弱，尽量使用数据耦合。
功能内聚内聚性最强，模块独立性也最强。

(3)信息隐藏与抽象
信息隐藏原则要求采用封装技术，将程序模块的实现细节(过程或数据) 隐藏起来，通过接口按要求来访问。按照信息隐藏的原则，系统中的模块应设计成“黑盒”，模块外部只能使用模块接口说明中给出的信息，例如，操作和数据类型等。模块之间相对独立，既易于实现，也易于理解和维护。
抽象原则要求抽取事物最基本的特性和行为，忽略非本质的细节，采用分层次抽象的方式可以控制软件开发过程的复杂性，有利于软件的可理解性和开发过程的管理。抽象层次包括过程抽象、数据抽象和控制抽象。

4)系统结构图
又称模块结构图，是概要设计阶段的工具，反映系统的功能实现和模块之间的联系与通信，包括各模块之间的层次结构，即反了系统的总体结构。

数据库设计
数据库设计的内容包括：需求分析、概念结构设计、逻辑结构设计、物理设计、数据库的实施和数据库的运行和维护

面向对象方法
面向对象 (OO)开发方法将面向对象的思想应用于软件开发过程中，指导开发活动，是建立在“对象”概念基础上的方法学。
面向对象开发方法认为客观世界是由对象组成的，对象由对象名、属性和操作(方法)组成，对象可按其属性进行分类，对象之间的联系通过传递消息来实现，对象具有封装性、继承性和多态性。

面向对象开发方法是以用例驱动的、以体系结构为中心的、迭代的和渐增式的开发过程。
面向对象的方法由OOA(面向对象分析)、OOD(面向对象设计)和OOP(面向对象编程)三个部分组成。
OOA和OOD 统一采用UML（统一建模语言）来描述并记录。

面向对象分析OOA
OOA 模型由5个层次(主题层、对象类层、结构层、属性层和服务层)和5个活动(标识对象类、标识结构、定义主题、定义属性和定义服务) 组成。
OOA定义了两种对象类之间的结构：

• 分类结构：就是一般与特殊的关系。
• 组装结构：反映了对象之间的整体与部分的关系。

1)OOA原则

• (1)抽象：从许多事物中舍弃个别的、非本质的特征，抽取共同的、本质性的特征叫作抽象。抽象原则包括过程抽象和数据抽象两方面。

• 过程抽象是指任何一个完成确定功能的操作序列，其使用者都可以把它看作一个单一的实体，尽管实际上它可能是由一系列更低级的操作完成的。

• 数据抽象是根据施加于数据之上的操作来定义数据类型，并限定数据的值只能由这些操作来修改和观察。数据抽象是OOA的核心原则。它强调把数据（属性）和操作（服务）结合为一个不可分的系统单位（即对象），对象的外部只需要知道它做什么，而不必知道它如何做。

• (2)封装：把对象的属性和操作结合为一个不可分的系统单位，并尽可能隐蔽对象的内部细节。

• (3)继承：特殊类的对象拥有的其一般类的全部属性与操作，称特殊类对一般类的继承。继承的好处：使系统模型比较简练、清晰。

• (4)多态(polymorphism)
  在OO技术中，多态性是指同一个操作作用于不同的对象时可以有不同的解释，并产生不同的执行结果。

• (5)分类：就是把具有相同属性和操作的对象划分为一类，用类作为这些对象的抽象描述。
  分类原则实际上是抽象原则运用于对象描述时的一种表现形式。

• (6)聚合：又称组装，其原则是把一个复杂的事物看成若干比较简单的事物的组装体，从而简化对复杂事物的描述。

• (7)关联：是人类思考问题时经常运用的思想方法，通过一个事物联想到另外的事物。能使人发生联想的原因是事物之间确实存在着某些联系。

• (8)消息通信：指对象之间只能通过消息进行通信，而不允许在对象之外直接地存取对象内部的属性。通过消息进行通信是由于封装原则而引起的。在OOA中要求用消息连接表示出对象之间的动态联系。

• (9)粒度控制：人在面对一个复杂的问题域时，不可能在同一时刻既能纵观全局，又能洞察秋毫。因此需要控制自己的视野：考虑全局时，注意其大的组成部分，暂时不详察每一部分的细节；考虑某部分的细节时则暂时撇开其余的部分。这就是粒度控制原则。

• (10)行为分析：现实世界中事物的行为是复杂的。由大量的事物所构成的问题域中各种行为往往相互依赖、相互交织。

面向对象设计OOD
类封装了信息和行为，是面向对象的重要组成部分，它是具有相同属性、方法和关系的对象集合的总称。在定义类时，将类的职
责分解为类的属性和方法，其中属性用于封装数据，方法用于封装行为。
设计类是OOD中最重要的组成部分，也是最复杂和最耗时的部分。在OOD 中，类分为三种类型：实体类、控制类和边界类。

1)实体类
实体类映射需求中的每个实体，实体类是指需要存储在永久存储体中的信息，例如在线教育平台系统可以提取出学员类和课程类，它们都属于实体类。
实体类对用户来说是最有意义的类，通常采用业务领域术语命名，一般是一个名词。在用例模型向领域模型的转化中，一个参与者一般对应于实体类。通常可以从SRS 中的那些数据库表(需要持久存储)对应的名词来找寻实体类。实体类一定有属性但不一定有操作。

例如： 客户、仓库 等 可以设计成实体类

2)控制类
控制类是用于控制用例工作的类，一般是由动宾结构的短语 (“动词+名词"或"名词+动词"转化来的名词，例如，用例"身份验证"对应一个控制类"身份验证器”，它提供了与身份验证有关的所有操作。
控制类将用例的特有行为进行封装，控制对象的行为与特定用例的实现密切相关，当系统执行用例的时候，就产生了一个控制对象，控制对象经常在它对应的用例执行完毕后消亡。控制类没有属性，但一定有方法(操作)。

3)边界类
边界类位于系统与外界的交接处，用于封装在用例内、外流动的信息或数据流。常见的边界类有窗体、报表、通信协议、打印机和扫描仪接口、传感器，以及与其他系统的接口。要寻找和定义边类，可以检查用例模型，每个参与者和用例交互至少要有一个边界类，边界类使参与者能与系统交互。边界类可以既有属性也有方法

4、软件测试

持续更新中。。。