软件设计师重要知识点

第一章

一、软件工程概述

1.CMM模型

初始级：没有明确定义的步骤，项目杂乱无章，甚至混乱。项目完成依靠个人努力；

可重复级：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性。有必要的过程准则来重复以前在同类项目中的成功。

已定义级：管理和工程两方面的软件过程已经文档化、标准化，并综合成整个软件开发组织的标准过程。

已管理级：制定了软件过程和产品质量的详细度量标准

优化级：加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈过程能不断持续地改进

2.CMMI阶段式模型

初始的：过程不可预测且缺乏控制

已管理的：过程为项目服务。

已定义的：过程为组织服务。

定量管理的：过程已度量和控制

优化的：集中于过程改进

3.CMMI连续式模型

CL0（未完成的）：过程域未执行或未得到CL1中定义的所有目标。

CL1（已执行的）：其共性目标是过程将可表示的输入工作产品转换成可标识的输出工作产品，已实现支持过程域的特定目标。

CL2(已管理的)：其共性目标是集中于已管理的过程的制度化

CL3（已定义的）：其共性目标集中于已定义的过程的制度化

CL4(定量管理的)：其共性目标集中于可定量管理的过程的制度化

CL5(优化的)：使用量化手段改变和优化过程域，以满足客户的改变和持续改进计划中的过程域的功效。

二、软件开发方法

1.结构化开发方法：用户至上，严格区分工作阶段，每阶段有任务和结果，强调系统开发过程的整体性和全局性，系统开发过程工程化，文档子类标准化，自顶向下，逐步分解

2.原型开发方法：适用于需求不明确的情况

3.面向对象开发方法：更好地复用性，关键在于建立一个全面、合理、同一的模型，分析、设计、实现三个阶段，界限不明确

4.面向服务开发方法：面向对象更高标准的抽象。

三、软件开发模型

1.瀑布模型：瀑布模型是将软件生存周期中的各个活动规定为依线性顺序连接的若干阶段的模型，包括需求分析、设计、编码、运行和维护；瀑布模型容易理解，管理成本低，每个阶段都有对应的成果产物，各阶段有明显的界限划分和顺序要求，一旦发生错误，只能让各个项目推倒重来；适合需求明确的项目。

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

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

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

6.螺旋模型：典型特点是引入了风险分析，结合了瀑布模型和演化模型的优点，最主要的特点是加入了风险分析，是由制定计划、风险分析、实施工程、客户评估这一新欢组成，最初从概念仙姑开始第一个螺旋，属于面向对象开发模型，强调风险引入。

7.统一过程：典型特点是用例驱动，以架构为中心、迭代和增量，统一过程把一个项目分为四个不同的阶段：

构思阶段：包括用户沟通和计划活动两个方面，强调定义和细化用例，并将其作为主要模型。

细化阶段：包括用户沟通和建模活动，重点是创建分析和设计模型，强调类的定义和体系结构的表示。

构建阶段：将设计转换为实现，并进行集成和测试。

移交阶段：将产品发布给用户进行测试评价，并手机用户的意见，之后再次进行迭代修改产品使之完善。

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

四、系统分析

1.需求分析的任务是解决做什么的问题

2.需求的分类：

• 功能需求：考虑系统要做什么，在何时做，以及如何修改升级
• 非功能需求：考虑软件开发的技术性指标，例如存储容量限制、执行速度、响应时间以及吞吐率
• 设计约束：除了功能需求和肺功能需求以外的需求，例如操作系统限制、开发语言限制等

3.需求分析的工具：判定表、判定树、数据流图和数据字典

4.需求分析的产物有：需求规格说明书（SRS）

五、系统设计

1.软件设计的任务是解决怎么做的问题

软件设计包括：体系结构设计、接口设计、数据设计和过程设计

过程设计：系统结构部件转换成软件的过程描述

结构设计：定义软件系统各主要部件之间的关系。

接口设计：软件内部、软件和操作系统之间以及软件和人之间如何通信

数据设计：将模型转换成数据结构的定义,好的数据设计将改善程序结构和模块的划分，降低过程复杂性。

2.系统设计的步骤

（1）概要设计

• 设计软件系统总体结构：基本任务还是采用某种设计方法，将一个复杂的系统按功能划分为模块，确定每个模块的功能，确定模块之间的调用关系，确定模块之间的接口，模块之间传递的信息；评价模块结构的质量
• 数据结构及数据库设计：在需求分析阶段对数据的组成、操作约束和数据之间的关系进行了描述，概要设计阶段加以细化，详细设计阶段规定具体的实现细节。
• 编写概要设计文档：概要设计说明书、数据库设计说明书、用户手册以及修订测试计划
• 评审：对设计部分是否完整地是实现了需求中规定的功能、性能等要求，设计的可行性，关键的处理以及外部接口定义的正确性、有效性、和部分之间的一致性等一一进行评审。

（2）详细设计

对每个模块进行详细的算法设计，用某种图形、表格和语言等工具将每个模块处理过程的详细算法描述出来。

对模块内的数据结构进行设计

对数据库进行物理设计，确定数据库的物理结构

其他设计：根据软件系统类型，需要进行代码设计、输入输出格式设计，用户界面设计等

编写设计说明书

评审：对处理过程的算法和数据库的物理结构都要评审

2.软件设计的原则：高内聚 低耦合

六、系统测试

1.常见的软件测试方法分类：

• 静态测试：桌前测试、代码走查、代码审查
• 动态测试
• 黑盒测试：等价类划分、边界值分析、错误推测、因果图
• 白盒测试：语句覆盖、判定覆盖、条件/判定覆盖、路径覆盖

2.常见的黑盒测试方法：

等价类划分：确定无效与有效等价类，设计用例尽可能多的覆盖有效类，设计用例只覆盖一个无效类

边界值分析：处理边界情况时最容易出错，选取的测试数据应恰好等于、稍小于或稍大于边界值

3.常见的白盒测试方法

	定义	特点
语句覆盖	被测试程序中的每条语句至少执行一次	对执行逻辑覆盖很低，一般认为是很弱的逻辑覆盖
判断覆盖	被测程序每个判定表达式至少获取一次 true false值	判断覆盖比语句覆盖更强些 判定可以是一个条件 或者是多个条件的组合
条件覆盖	每个判定语句中每个逻辑条件各种可能的值至少满足一次	条件覆盖和判断覆盖没有包含关系
判断/条件覆盖	判定中每个条件的所有可能取值 至少出现过一次，并使每个判定本身的判定结果至少出现一次	同时满足判定覆盖和条件覆盖
条件组合覆盖	每个判定中的各种可能值的组合至少出现一次	同时满足判定覆盖、条件覆盖、判定条件覆盖
路径覆盖	覆盖被测试程序中所有可能的路径	对程序的彻底的测试

4.各测试阶段的任务

• 验收测试：有效性测试、软件配置审查、验收测试
• 系统测试：恢复测试、安全性测试、强度测试、性能测试、可靠性测试、安装测试
• 集成测试：模块间的接口和通信
• 单元测试：模块接口、局部数据结构、边界条件、独立的路径、错误处理
• 其他测试：回归测试（修改软件后的测试，防止新错误）、负载测试（对软件负载能力的测试）、压力测试（对软件超负荷条件下运行情况的测试）

5.测试的基本原则

尽早、不断地进行测试

程序员尽量避免测试自己设计的程序

既要选择有效、合理的数据，也要选择无效、不合理的数据

修改后应进行回归测试

尚未发现的错误应该与已发现的错误成正比

6.McCabe复杂度计算

• McCabe复杂度计算公式 V（G）=m-n+2 其中m是有向弧的条数、n是节点数，可以计算闭环数量+1
• 对于伪代码可以先转换为程序流程图，对程序流程图转换为节点图，主要将交点的地方标注为新的节点，交易最终的节点图带入公式计算McCabe复杂度。

七、软件维护

1.更正性维护：针对真实存在但已经发生的错误进行维护行为

2.预防性维护：针对真实存在但还未发生的错误进行维护

3.适应性维护：使软件适应信息技术变化和管理需求变化而进行的修改，企业外部市场环境和管理需求不断变化也使得各级管理人员不断提出新的信息需求

4.完善性维护：扩充功能和改善性能而进行的修改，对已有的软件系统增加一些在系统分析和设计阶段中没有规定的功能和性能特征。

八、软件质量保证

1.功能性：适合性、准确性、互操作性、安全保密性

2.可靠性

3.易用性

4.效率

5.维护性

6.可移植性

第三章 项目管理

一、进度管理

1.甘特图能够清洗描述每个任务的开始/结束时间以及个任务之间的并行性，也可以动态地反映相聚的开发进展情况 单难以反映多个任务之间存在的逻辑关系 PERT利用项目的网络图和各活动所需时间的估计值，去计算项目的总时间，强调任务之间的先后关系，但不能反映任务之间的并行性，以及项目的当前进展情况

2.关键路径法是图中源点到汇点的最长路径，关键路径时间称之为项目工期，也表述为完成所需的最少时间

二、风险管理

对风险相关概念描述判断正误 计算风险曝光度

1.风险的特性：具有不确定性，可能会造成损失

2.风险的类别：项目风险涉及到各种形式的预算、进度、人员、资源以及客户相关的问你，并且可能导致项目损失。技术风险涉及到技术相关的可能会导致项目损失的问题，商业风险与市场因素相关，社会风险涉及到政策、法规等因素。

3.风险暴露：风险曝光度，测量的是资产的整个安全性风险，将实际损失的可能性与标识大量可能损失的咨询结合到单一数字评估中。在形式最简单的定量性风险分析中，风险曝光度可通过将风险可能性及影响相乘算出。

风险曝光度=错误出现率*错误损失

三、成本管理

COCOMO 是一种层次结构的估算模型，被分为3哥阶段性模型

应用组装模型，在软件工程前期阶段使用。这时用户界面的原型开发、对软件和系统交互的考虑、性能的评估以及技术成熟度的评价是最重要的

早期设计界面模型，在需求已经稳定并且基本的软件体系结构已经建立时使用。

体系结构阶段模型，在软件的构造过程中使用。

规模估算选择：对象点，功能点，代码行

应用组装模型使用的是对象点；早期设计阶段模型使用的是功能点，功能点可以转换为代码行

四、沟通管理

n个小组成员 1个主程序员

有主程：沟通路径n-1

无主程：沟通路径n*（n-1）/2

第四章 面向对象技术

一、面向对象基础

1.基础概念

对象：属性（数据）+方法（操作）+对象ID

封装：隐藏对象的属性和实现细节，对外只公布接口（信息隐藏技术）

类（实体类、控制类、边界类）

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

继承与泛化：复用机制

重写/覆盖overriding：在子类重新定义父类已经定义的方法

动态绑定：根据接受对象的具体情况将请求的操作与实现的方法进行连接（运行时绑定）

多态：不同对象收到同样的消息产生不同的结果，多态实质上是将子类的指针对象或者引用对象传递给父类指针对象，通过这个父类指针对象调用的函数，不是父类中定义的，而是传递进来的子类对象中重写的函数。

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

类属类：类的模板。

消息和消息通信：对象之间进行通信的一种构造叫做消息。消息是异步通信的，消息传递：接收到信息的对象经过解释，然后予以响应。

面向对象设计原则：

单一职责原则：设计目的单一的类

开放-封闭原则：对拓展开放，对修改封闭

李氏替换原则：子类可以替换父类

依赖倒置原则：要依赖于抽象，而不是具体实现。针对接口编程，不要针对实现编程。

接口隔离原则，使用多个专门的接口比使用单一的总接口要好。

组合重用原则：要尽量使用组合，而不是继承关系大道重用目的。

最少知识法原则：一个对象应当对其他对象尽可能少的了解。

面向对象其他设计原则

• 重用·发布等价原则：重用的粒度就是发布的粒度
• 共同封闭原则：包中的所有类对于同一性质的变化应该是共同封闭的，一个变化若对一个包产生影响，则将对包里的所有类产生影响，而对于其他包不造成任何影响
• 共同重用原则：一个包里的所有类应该是共同重用的，如果重用了包里的一个类，那么就要重用包中的所有类
• 无环依赖原则：在包的依赖关系图中不允许存在环，即包之间的结构必须是一个无环图形。
• 稳定依赖原则：朝着稳定的方向进行依赖
• 稳定抽象原则：包的抽象程度应该和其稳定程度一致、

面向对象开发过程

面向对象分析：认定对象；组织对象；对象间的相互作用；基于对象的操作

面向对象设计：设备类及对象；定义属性；定义服务；识别关系；识别包

面向对象开发：程序设计泛型；选择一种OOPL

面向对象测试：算法层；类层；模板层；系统层

二、UML

1.UML图分类：

2.用例图：用例图描述一组用例、参与者以及他们的关系

创建型设计模式：

工厂方法模式：定义一个创建对象的接口，但由子类决定需要实例化哪一个类，工厂方法使得子类的实例化过程推迟。动态生产对象

抽象工厂模式：提供一个接口，可以创建一系列相关或相互依赖的对象，而无需指定它们具体的类。生产成系列对象

构建器模式：讲一个复杂的类的表示与其构造相分离，使得相同的构建过程能够得出不同的表示。复杂对象构造

原型模式：用原型实例指定创建对象的类型，并且通过拷贝这个原型来创建新的对象。克隆对象

单例模式：保证一个类只有一个实例，并提供一个访问它的全局访问点 单实例

结构型模式：

适配器模式：将一个类的接口抓换成用户希望得到的另一种接口，它使原本不相容的接口得以协同工作。转换接口

桥接模式：将类的抽象部分和它的实现部分分离开来，使它们可以独立地变化。继承树拆分

组合模式：将对象组合成树形结构以表示“整体-部分”的层次结构，使得用户对单个对象和组合对象的使用具有一致性 树形目录结构

装饰模式：动态地给一个对象添加一些额外的职责，提供了用子类拓展功能的一个灵活的替代，比派生一个子类更加灵活 动态附加职责

外观模式：定义一个高层接口，为子系统的一组接口提供一个一致的外观，从而简化了该子系统的使用 对外统一接口

享元模式：提供支持大量细粒度对象共享的有效方法 汉字编码

代理模式：为其他对象提供一种代理以控制这个对象的访问 快捷方式