软件设计师——系统基础开发

一、软件工程概述

1.1、考点1、信息系统基本生存周期 (⭐⭐⭐)

1. 可行性分析与项目开发计划
2. 需求分析
3. 概要设计
4. 详细设计
5. 编码
6. 测试
7. 维护

1.2、考点2、软件过程

1.2.1、CMM

1. 初始级：杂乱无章，甚至混乱，几乎没有明确定义的步骤项目的成功完全依赖个人的努力和英雄式核心人物的作用。
2. 可重复级：建立了基本的项目管理过程和实践来跟踪项目费用、进度和功能特性，有必要的过程准则来重复以前在同类项目中成功。
3. 已定义级：管理和工程两方面的软件过程已经文档化、标准化并综合成整个软件开发组织的标准过程。
4. 已管理级：制定了软件过程和产品质量的详细度量标准。
5. 优化级:加强了定量分析，通过来自过程质量反馈和来自新观念、新技术的反馈使过程能不断持续地改进。

1.2.2、CMMI

1.2.2.1、阶段模型

1. 初始的：过程不可预测且缺乏控制
2. 已管理的：过程为项目服务。
3. 已定义的：过程为组织服务。
4. 定量管理的：过程已度量和控制。
5. 优化的：集中于过程改进。

1.2.2.2连续式模型

二、软件开发方法

结构化方法（需求明确）

• 用户至上
• 严格区分工作阶段，每阶段有任务和结果
• 强调系统开发过程的整体性和全局性
• 系统开发过程工程化，文档资料标准化
• 自顶向下，逐步分解(求精)

原型法（需求不明确）

面向对象法（复杂，大项目）

• 更好的复用性
• 关键在于建立一个全面、合理、统一的模型
• 分析、设计、实现三个阶段，界限不明确

面向服务的方法

• 抽象级别：操作、服务、业务流程

Jackson

• 面向数据结构

三、软件开发模型(⭐⭐⭐)

3.1、考点1：瀑布模型与V模型(⭐⭐⭐)

​

瀑布模型特点：以文档作为驱动、适合于软件需求很明确的软件项目。

​

V模型特点：将验证确认活动应用于早期软件工程工作中，测试贯穿始终

3.2、考点2：演化模型(原型模型、螺旋模型)(⭐⭐⭐)

演化模型：演化模型是迭代的过程模型，使得软件开发人员能够逐步开发出更完整的软件版本。演化模型特别适用于对软件需求缺乏确认识的情况

原型方法比较适合于用户需求不清、需求经常变化的情况，当系统规模不是很大也不太复杂时，采用该方法比较好。

​

原型有多种分法：抛弃性原型、演化性原型

探索性原型、实验性原型、演化性原型

螺旋模型：瀑布模型和演化模型结合，加入了风险分析。特别适用于庞大、复杂并且具有高风险的系统。

​

3.3、考点3：增量模型(⭐⭐⭐)

第1个增量往往是核心产品。将需求分段为一系列增量产品，每一增量可以分别开发。

​

3.4、考点4：喷泉模型（面向对象）

以用户需求为动力，以对象作为驱动的模型，适合于面向对象的开发方法。

特点:迭代无间隙

​

3.5、考点5：统一过程UP(RUP)

​

3.6、考点6：敏捷方法(⭐⭐⭐)

3.6.1、基本原则

• 短平快的会议
• 小型版本发布
• 较小的文档
• 合作为重
• 客户直接参与
• 自动化测试
• 适应性计划调整
• 结对编程
• 测试驱动开发
• 持续集成
• 重构

总体目标是通过“尽可能早地、持续地对有价值的软件的交付”使客户满意。适用于:“小步快跑”的思想，适合小项目小团队。

3.6.1.2、敏捷开发方法

四、需求分析(⭐⭐⭐)

4.1、考点1：需求分析的概念

软件需求包括：功能需求、性能需求、用户或人的因素、环境需求、界面需求、文档需求、数据需求、资源使用需求、安全保密需求、可靠性要求、软件成本消耗与开发进度需求、其他非功能需求。

需求分析阶段的输出包括：数据流图、实体联系图、状态迁移图、数据字典，补充材料。

4.2、考点2：需求的分类

​

4.3、考点3：需求分析的工具

4.3.1、数据流图(⭐⭐⭐)

​

​

​

4.3.1、数据字典(⭐⭐⭐)

数据字典有以下四个条目：数据流、数据项、数据存储和基本加工，（源点和终点不在系统之内，不在字典中说明）

​

​

​

4.3.3、判定表

​

4.3.4、判定树

​

五、系统设计

5.1、考点1：系统设计概述

系统设计分为概要设计和详细设计 概要设计：

1. 设计软件系统总体结构
2. 数据结构及数据库设计
3. 1. 概念设计
   2. 逻辑设计
   3. 物理设计
4. 编写概要设计文档
5. 评审

详细设计：对每个模块进行详细的算法设计

​

5.2、考点2：模块设计(⭐⭐⭐)

5.2.1、模块设计原则：

1. 保持模块的大小适中
2. 尽可能减少调用的深度（适中）
3. 多扇入，少扇出（适中）
4. 单入口，单出口
5. 模块的作用域应该在模块之内
6. 模块的作用域应该在模块之内

控制域>作用域

被调用模块和调用模块组成控制域名

高层依赖低层

5.2.2、高内聚、低耦合

内聚

​

5.2.3、耦合(板块与板块之间的关联)

​

5.3、考点3：人机界面设计考(⭐⭐⭐)

黄金三原则

1. 置于用户控制之下
2. 1. 允许用户交互可以被终端和撤销
   2. 当技能级别增加可以使交互流水化并允许定制交互
3. 减少用户的记忆负担
4. 1. 建立有意义的缺省
   2. 定义直觉性的捷径
5. 保持界面的一致性

5.4、考点4：架构设计(⭐⭐⭐)

5.4.1、软件架构风格

架构设计的一个核心问题是能否达到架构级的软件复用 架构风格反映了领域中众多系统所共有的结构和语义特性，并指导如何将各个构件有效地组织成一个完整的系统 架构风格定义了用于描述系统的术语表和一组指导构建系统的规则

数据流风格：批处理序列、管道-过滤器 调用/返回风格：主程序/子程序、面向对象、层次结构J(MVC、C/S、B/S) 独立构件风格：进程通信、事件驱动系统(隐式调用) 虚拟机风格：解释器、基于规则的系统 仓库风格： 数据库系统、超文本系统、黑板系统

5.4.2、数据流风格

批处理序列

构件为一系列固定顺序的计算单元，构件之间只通过数据传递交互。每个处理步骤是一个独立的程序，每一步必须在其前一步结束后才能开始数据必须是完整的，以整体的方式传递。

管道-过滤器

每个构件都有一组输入和输出，构件读输入的数据流，经过内部处理:然后产生输出数据流。这个过程通常是通过对输入数据流的变换或计算来完成的，包括通过计算和增加信息以丰富数据、通过浓缩和删除以精简数据、通过改变记录方式以转化数据和递增地转化数据等。这里的构件称为过滤器，连接件就是数据流传输的管道，将一个过滤器的输出传到另一个过滤器的输入。

早期编译器就是采用的这种架构。要一步一步处理的，均可考虑采用此架构风格。

5.4.3、调用/放回风格

主程序/子程序

单线程控制，把问题划分为若干个处理步骤，构件即为主程序和子程序，子程序通常可合成为模块。过程调用作为交互机制，即充当连接件的角色。调用关系具有层次性，其语义逻辑表现为主程序的正确性取决于它调用的子程序的正确性

面向对象

构件是对象，对象是抽象数据类型的实例。在抽象数据类型中，数据的表示和它们的相应操作被封装起来，对象的行为体现在其接受和请求的动作。连接件即是对象间交互的方式，对象是通过函数和过程的调用来交互的

层次结构

构件 组织成一个层次结构，连接件通过决定层间如何交互的协议来定义。每层为上一层提供服务，使用下一层的服务，只能见到与自己邻接的层。通过层次结构，可以将大的问题分解为若干个渐进的小问题逐步解决，可以隐藏问题的复杂度。修改某一层，最多影响其相邻的两层(通常只能影响上层)

优点：

1、这种风格支持基于可增加抽象层的设计，允许将一个复杂问题分解成一个增量步骤序列的实现。2、不同的层次处于不同的抽象级别:越靠近底层，抽象级别越高;越靠近顶层，抽象级别越低;

3、由于每一层最多只影响两层，同时只要给相邻层提供相同的接口，允许每层用不同的方法实现，同样为软件复用提供了强大的支持。

缺点:

1、并不是每个系统都可以很容易地划分为分层的模式。

2、很难找到一个合适的、正确的层次抽象方法。

5.4.4、层次架构风格

两层C/S

客户端和服务器都有处理功能。处理在表示层（客户端）和数据层（服务器）进行

三层C/S架构

将处理功能独立出来。表示层在客户机上，功能层在应用服务器上，数据层在数据库服务器上。

三层B/S架构

将客户端变为用户客户端上的浏览器，将应用服务器变为网络上的WEB服务器，又称为0客户端架构.

5.4.5、MVC架构风格

Model(模型)是应用程序中用于处理应用程序数据逻辑的部分。通常模型对象负责在数据库中存取数据。

View(视图)是应用程序中处理数据显示的部分。通常视图是依据模型数据创建的。

Controller(控制器)是应用程序中处理用户交互的部分。通常控制器负责从视图读取数据，控制用户输入，并向模型发送数据。

J2EE体系结构中:

• 视图(View):JSP
• 控制(Controller):Servlet
• 模型(Model ): Entity Bean、 Session Bean

5.4.6、独立构件风格

进程通信

构件是独立的过程，连接件是消息传递。构件通常是命名过程，消息传递的方式可以是点对点、异步或同步方式，以及远程过程(方法)调用等。

事件驱动系统(隐式调用)

构件不直接调用一个过程，而是触发或广播一个或多个事件。构件中的过程在一个或多个事件中注册，当某个事件被触发时，系统自动调用在这个事件中注册的所有过程。一个事件的触发就导致了另一个模块中的过程调用。这种风格中的构件是匿名的过程，它们之间交互的连接件往往是以过程之间的隐式调用来实现的。主要优点是为软件复用提供了强大的支持，为构件的维护和演化带来了方便:其缺点是构件放弃了对系统计算的控制。

5.4.7、虚拟机风格

解释器

解释器通常包括一个完成解释工作的解释引擎、一个包含将被解释的代码的存储区、一个记录解释引擎当前工作状态的数据结构，以及一个记录源代码被解释执行的进度的数据结构。具有解释器风格的软件中含有一个虚拟机，可以仿真硬件的执行过程和一些关键应用，其缺点是执行效率比较低。

基于规则的系统

基于规则的系统包括规则集、规则解释器、规则/数据选择器和工作内存一般用在人工智能领域和DSS中。

5.4.8、仓库风格（以数据为中心的风格）

数据库系统

构件主要有两大类，一类是中央共享数据源，保存当前系统的数据状态;另一类是多个独立处理单元，处理单元对数据元素进行操作。

黑板系统

包括知识源、黑板和控制三部分。知识源包括若干独立计算的不同单元，提供解决问题的知识。知识源响应黑板的变化，也只修改黑板;黑板是一个全局数据库包含问题域解空间的全部状态，是知识源相互作用的唯一介;知识源响应是通过黑板状态的变化来控制的。黑板系统通常应用在对于解决问题没有确定性算法的软件中(信号处理、问题规划和编译器优化等)。

超文本系统

构件以网状链接方式相互连接，用户可以在构件之间进行按照人类的联想思维方式任意跳转到相关构件。超文本是一种非线性的网状信息组织方法，它以结点为基本单位，链作为结点之间的联想式关联。超文本系统通常应用在互联网领域。

现代集成编译环境一般采用这种架构风格。

六、系统测试

6.1、考点1：测试的基本概念及分类

测试遵循的原则：

1. 尽早、不断的进行测试
2. 程序员避免测试自己设计的程序
3. 既要选择有效、合理的数据，也要选择无效、不合理的数据
4. 修改后应进行回归测试
5. 尚未发现的错误数量与该程序已发现错误数成正比

6.2、考点2：黑盒测试

等价类划分

1. 确定无效与有效等价类
2. 设计用例尽可能多的覆盖有效类
3. 设计用例只覆盖一个无效类

边界值分析

1. 处理边界情况时最容易出错
2. 选取的测试数据应该恰好等于、稍小于或稍大手边界值

6.3、考点3：白盒测试(⭐⭐⭐)

6.4、考点4：测试阶段划分

​

单元测试：模块测试，模块功能、性能、接口等 集成测试：模块间的接口 系统测试：真实环境下，验证完整的软件配置项能否和系统正确连接。 确认测试：验证软件与需求的一致性。内部确认测试、Alpha测试（开发）、Beta测试（用户），验收测试。 回归测试：测试软件变更之后，变更部分的正确性对变更需求的符合性。

6.5、考点5：McCabe复杂度计算(⭐⭐⭐)

​

计算有向图的环路复杂度公式：V=m-n+2 说明：其中V是有向图中的环路个数，m是G中的有向弧数，n是G中的节点个数。

上图：15-12+2=5

​

​

七、软件维护(⭐⭐⭐)

可维护性因素决定

• 可理解性
• 可测试性
• 可修改性

软件维护类型

• 改正性维护
• 适应性维护
• 预防性维护
• 完善性维护

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

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

八、软件文档(⭐⭐⭐)

• 可行性研究和项目任务书
• 需求规格说明
• 功能规格说明
• 设计规格说明(包括程序和数据规格说明)
• 开发计划
• 软件集成和测试计划
• 质量保证计划、标准、进度
• 安全和测试信息
• 培训手册
• 参考手册和用户指南
• 软件支持手册
• 产品手册和信息广告
• 开发过程的每个阶段的进度和进度变更的记录
• 软件变更情况的记录
• 相对于开发的判定记录
• 职责定义

九、软件质量保证模型(⭐⭐⭐)