一、考情分析

二、考点精讲

2.1 软件过程模型 

（1）原型模型
        典型的原型开发方法模型。适用于需求不明确的场景,可以帮助用户明确需求。可以分为[抛弃型原型]与[演化型原型]

        原型模型两个阶段:

• 1、原型开发阶段;
• 2、目标软件开发阶段。

（2）瀑布模型
        瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、运行与维护。

        瀑布模型的特点是严格区分阶段，每个阶段因果关系紧密相连，只适合需求明确的项目。

缺点:

• 软件需求完整性、正确性难确定;
• 严格串行化，很长时间才能看到结果;
• 瀑布模型要求每个阶段一次性完全解决该阶段工作，这不现实。

（3）增量模型
        融合了瀑布模型的基本成分和原型实现的迭代特征，可以有多个可用版本的发布,核心功能往往最先完成，在此基础.上，每轮迭代会有新的增量发布，核心功能可以得到充分测试。强调每一个增量均发布一个可操作的产品。

（4）螺旋模型
        以快速原型为基础+瀑布模型，典型特点是引入了风险分析。它是由制定计划、风险分析、实施工程、客户评估这一循环组成的，它最初从概念项目开始第一个螺旋。

（5）V模型
        强调测试贯穿项目始终，而不是集中在测试阶段。是一种测试的开发模型。

（6）喷泉模型
        典型的面向对象的模型。特点是迭代、无间隙。会将软件开发划分为多个阶段，但各个阶段无明显界限，并且可以迭代交叉。

（7）快速应用开发RAD
        概念: RAD是瀑布模型的一个高速变种，适用比传统生命周期快得多的开发方法，它强调极短的开发周期，通常适用基于构件的开发方法获得快速开发。

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

        适用性: RAD对模块化要求比较高,如果某项功能不能被模块化,则其构件就会出问题;如果高性
能是一个指标，且必须通过调整结构使其适应系统构件才能获得，则RAD也有可能不能奏效; RAD要求开发者和客户必须在很短的时间完成一系列的需求分析，任何一方配合不当都会导致失败；RAD只能用于管理信息系统的开发，不适合技术风险很高的情况。

（8）构件组装模型

        [优点] 易扩展、易重用、降低成本、安排任务更灵活。
        [缺点]构件设计要求经验丰富的架构师、设计不好的构件难重用、强调重用可能牺牲其它指标(如性能)、第三方构件质量难控制。

（9）统一过程(在软考中UP、RUP都指统一过程)
典型特点是用例驱动、以架构为中心、迭代和增量。
统一过程把一个项目分为四个不同的阶段:

• 构思阶段(初始/初启阶段) : 定义最终产品视图和业务模型、确定系统范围。
• 细化阶段(精化阶段) :设计及确定系统架构、制定工作计划及资源要求。
• 构造阶段:开发剩余构件和应用程序功能，把这些构件集成为产品，并进行详细测试。
• 移交阶段:确保软件对最终用户是可用的，进行β测试,制作产品发布版本。

        9个核心工作流:业务建模、需求、分析与设计、实现、测试、部署、配置与变更管理、项目管理、环境。

（10）敏捷开发
        敏捷开发是一种以人为核心、迭代、循序渐进的开发方法，适用于小团队和小项目，具有小步快跑的思想。常见的敏捷开发方法有极限编程法、水晶法、并列争球法和自适应软件开发方法。

        极限编程(XP) : 一些对费用控制严格的公司中的使用，非常有效，近螺旋式的开发方法。四大价值观(沟通[加强面对面沟通]、简单[不过度设计]、反馈[及时反馈]、勇气[接受变更的勇气] ) ,十二大最佳实践(简单设计、测试驱动、代码重构、结对编程、持续集成、现场客户、发行版本小型化、系统隐喻、代码集体所有制、规划策略、规范代码、40 小时工作机制)。

        水晶方法:提倡“机动性”的方法，拥有对不同类型项目非常有效的敏捷过程。

        开放式源码:程序开发人员在地域.上分布很广(其他方法强调集中办公]。

        SCRUM:明确定义了可重复的方法过程。

        特征驱动开发方法(FDD) :认为有效的软件开发需要3要素[人、过程、技术]。定义了6种关键的项目角色:项目经理、首席架构设计师、开发经理、主程序员、程序员和领域专家。

        ASD方法:其核心是三个非线性的、重叠的开发阶段:猜测、合作与学习。

        动态系统开发方法(DSDM) :倡导以业务为核心。

   敏捷宣言:

• 个体和交互胜过过程和工具;
• 可工作的软件胜过大量的文档;
• 客户合作胜过合同谈判;
• 响应变化胜过遵循计划。

2.2 基于构件的软件工程(CBSE)

CBSE体现了“购买而不是重新构造”的哲学。
CBSE的构件应该具备的特征:
1、可组装性:所有外部交互必须通过公开定义的接口进行。
2、可部署性:构件总是二进制形式的，能作为一个独立实体在平台上运行。
3、文档化:用户根据文档来判断构件是否满足需求。
4、独立性:可以在无其他特殊构件的情况下进行组装和部署。
5、标准化:符合某种标准化的构件模型。
[构件的组装] :
1、顺序组装:按顺序调用已经存在的构件，可以用两个已经存在的构件来创造一个新的构件。
2、层次组装:被调用构件的“提供”接口必须和调用构件的“请求”接口兼容。
3、叠加组装:多个构件合并形成新构件，新构件整合原构件的功能，对外提供新的接口。

2.3 需求工程

2.3.1需求工程阶段划分

软件需求是指用户对系统在功能、行为、性能、设计约束等方面的期望。
软件需求是指用户解决问题或达到目标所需的条件或能力，是系统或系统部件要满足合同、标准、
规范或其他正式规定文档所需具有的条件或能力，以及反映这些条件或能力的文档说明。
[需求工程主要活动的阶段划分]

2.3.2需求开发

2.3.2.1需求获取

2.3.2.2需求分析

结构化需求分析(SA)

(1)结构化分析过程

(2)结构化分析工具-数据流图DFD

面向对象需求分析

（1）面向对象基本概念

        对象:属性(数据) +方法(操作) +对象ID
        类(实体类/控制类/边界类)

        实体类映射需求中的每个实体,实体类保存需要存储在永久存储体中的信息，例如，在线教育平台系统可以提取出学员类和课程类,它们都属于实体类。

        控制类是用于控制用例工作的类,一般是由动宾结构的短语(“动词+名词”或“名词+动词”)转化来的名词，例如，用例“身份验证”可以对应于-个控制类“身份验证器”,它提供了与身份验证相关的所有操作。

        边界类用于封装在用例内、外流动的信息或数据流。边界类位于系统与外界的交接处，包括所有窗体、报表、打印机和扫描仪等硬件的接口，以及与其他系统的接口。

        继承与泛化:复用机制

        封装:隐藏对象的属性和实现细节,仅对外公开接口。

        多态:不同对象收到同样的消息产生不同的结果。

        接口:一种特殊的类，它只有方法定义没有实现。

        重载: 一个类可以有多个同名而参数类型不同的方法。

        消息和消息通信:消息是异步通信的。

 (2) UML图概念

 UML包括两组公共分类,分别是类与对象(类表示概念,而对象表示具体的实体)、接口与实现(接口用来定义契约，而实现就是具体的内容)

        结构事物:结构事物在模型中属于最静态的部分，代表概念.上或物理.上的元素。UML有七种结构事物，分别是类、接口、协作、用例、活动类、构件和节点。类是描述具有相同属性、方法、关系和语义的对象的集合，一个类实现一个或多个接口;接口是指类或构件提供特定服务的一组操作的集合,接口描述了类或构件的对外的可见的动作;协作定义了交互的操作,是一些角色和其它事物一起工作,提供一些合作的动作，这些动作比事物的总和要大;用例是描述一系列的动作, 产生有价值的结果。在模型中用例通常用来组织行为事物。用例是通过协作来实现的;活动类的对象有一个或多个进程或线程。活动类和类很相似,只是它的对象代表的事物的行为和其他事物是同时存在的;构件是物理上或可替换的系统部分,它实现了一个接口集合;节点是一个物理元素,它在运行时存在,代表-个可计算的资源，通常占用一些内存和具有处理能力。一个构件集合一般来说位于一个节点，但有可能从一个节点转到另一个节点。

        行为事物:行为事物是UML模型中的动态部分，代表时间和空间上的动作。UML 有两种主要的行为事物。第-种是交互(内部活动) ,交互是由一组对象之间在特定.上下文中，为达到特定目的而进行的一系列消息交换而组成的动作。交互中组成动作的对象的每个操作都要详细列出，包括消息、动作次序(消息产生的动作)、连接(对象之间的连接) ;第二种是状态机，状态机由一系列对象的状态组成。

        分组事物:分组事物是UML模型中组织的部分，可以把它们看成是个盒子，模型可以在其中进行分解。UML只有一种分组事物，称为包。包是一种将有组织的元素分组的机制。与构件不同的是，包纯粹是一种概念上的事物，只存在于开发阶段，而构件可以存在于系统运行阶段。

        注释事物:注释事物是UML模型的解释部分。

(3) UML图分类

 (4) UML图关系

用例关系包括:包含关系、扩展关系、泛化关系。

 

        包含关系:其中这个提取出来的公共用例称为抽象用例,而把原始用例称为基本用例或基础用例,当可以从两个或两个以上的用例中提取公共行为时，应该使用包含关系来表示它们。

        扩展关系:如果一个用例明显地混合了两种或两种以上的不同场景，即根据情况可能发生多种分支，则可以将这个用例分为一个基本用例和一个或多个扩展用例，这样使描述可能更加清晰。

        泛化关系:当多个用例共同拥有-种类似的结构和行为的时候，可以将它们的共性抽象成为父用例，其他的用例作为泛化关系中的子用例。在用例的泛化关系中，子用例是父用例的一种特殊形式,子用例继承了父用例所有的结构、行为和关系。

        依赖关系: 一个事物发生变化影响另一个事物。
        泛化关系:特殊/一般关系

关联关系:描述了一组链，链是对象之间的连接。

• 聚合关系:整体与部分生命周期不同。
• 组合关系:整体与部分生命周期相同。
   

实现关系:接口与类之间的关系

（5）“4+1”视图

UML采用4+1视图来描述软件和软件开发过程:
逻辑视图:以问题域的语汇组成的类和对象集合。
进程视图:可执行线程和进程作为活动类的建模，它是逻辑视图的一次执行实例,描绘了所设计的并发与同步结构。
实现视图:对组成基于系统的物理代码的文件和组件进行建模。
部署视图:把构件部署到一组物理的、可计算的节点上，表示软件到硬件的映射及分布结构。
用例视图:最基本的需求分析模型。

（6）OOA需求建模

 2.3.2.3需求定义

2.3.2.4需求验证

 

2.3.3需求管理

(3)变更控制
        带有风险的做法:无足够用户参与，忽略了用户分类，用户需求的不断增加，模棱两可的需求，不必要的特性，过于精简的SRS,不准确的估算。

2.4系统设计

2.4.1界面设计

        用户界面设计是指用户与系统之间架起一座桥梁，主要内容包括:定义界面形式、定义基本的交互控制形成、定义图形和符号、定义通用的功能键和组合键的含义及其操作内容、定义帮助策略等。

 2.4.2结构化设计

(1)概要设计[外部设计] :功能需求分配给软件模块,确定每个模块的功能和调用关系,形成模块结构图。
(2)详细设计[内部设计] :为每个具体任务选择适当的技术手段和处理方法。
(3)结构化设计原则:

• 模块独立性原则(高内聚、低耦合) ;
• 保持模块的大小适中;
• 多扇入，少扇出;
• 深度和宽度均不宜过高。

(4)模块四要素:

• 输入和输出:模块的输入来源和输出去向都是同一个调用者,即一个模块从调用者那) L取得输入进行加工后再把输出返回调用者。
• 处理功能:指模块把输入转换成输出所做的工作。
• 内部数据:指仅供该模块本身引用的数据。
• 程序代码:指用来实现模块功能的程序。

(5)模块独立性的度量

1.聚合:衡量模块内部各元素结合的紧密程度

2.耦合:度量不同模块间互相依赖的程度
 

 2.4.3面向对象设计

(1) 过程

 (2)设计原则

• 单一职责原则:设计目的单一的类。
• 开放-封闭原则:对扩展开放，对修改封闭。
• 李氏(Liskov) 替换原则:子类可以替换父类。
• 依赖倒置原则:要依赖于抽象，而不是具体实现;针对接口编程，不要针对实现编程。
• 接口隔离原则:使用多个专门的接口比使用单一的总接口要好。
• 组合重用原则:要尽量使用组合，而不是继承关系达到重用目的。
• 迪米特(Demeter) 原则(最少知识法则) : 一个对象应当对其他对象有尽可能少的了解。

(3)类的分类

2.5软件测试

(1)动态测试与静态测试

控制流分析:是否存在没有使用的语句/无法达到的语句/调用并不存在的子程序。
数据流分析:引用未定义的变量、对以前未使用的变量再次赋值。
接口分析:模块之间接口的一致性、子程序和函数之间的接口一致性、函数形参与实参的数量、顺序、类型的一致性。
表达式分析:括号不配对、数组引用越界、除数为零。

单元测试:依据[详细设计]，模块测试，模块功能、性能、接口等。
集成测试:依据[概要设计] ,模块间的接口。
系统测试:依据[需求文档]，在真实环境下，验证完整的软件配置项能否和系统正确连接。
确认测试:依据[需求文档]，验证软件与需求的一致性。内部确认测试、Alpha 测试、Beta测试、验收测试。
回归测试:测试软件变更之后，变更部分的正确性和对变更需求的符合性。

(4)集成测试策略

 (5)系统测试