# 软工基础

## 题型

### 简答题 6题 30pts

- 画*号地方

### 综合题 30pts

### 填空选择判断40pts

## 1 软件过程

### 01 软件的本质

- 软件的定义

	- 来自教科书p3

		- （1）指令的集合（计算机程序），通过执行这些指令可以满足预期的特性、功能和性能需求
		- （2）数据结构，使得程序可以合理利用信息
		- （3）软件描述信息，它以拷贝和虚拟性质存在，用来描述程序的操作和使用

- 软件的特征

	- 教材p4、ppt

		- （1）软件是设计开发的，而不是传统意义上生产制造的
		- （2）软件不会磨损

			- 硬件失效
			- 软件失效

		- （3）虽然整个工业向着基于构件的构造模式发展， 然而大多数软件仍是根据实
际的顾客需求定制的。
		- （4）软件是逻辑的而非物理的系统元素

### 02 软件工程

- 软件工程

	- 种子定义

		- （软件工程是）建立和使用一套合理的工程
原则，以便经济地获得可靠的、可以在实际
机器上高效运行的软件。
未提及软件质量，直接谈到用户满意度或按
时交付产品的要求、忽略了测量和度量的重
要性和有效的软件过程的重要性。

	- IEEE定义

		- （1）将系统化的、规范的、可量化的方法应用于软件的开发、运行和维护，即将工程化方法应用于软件。
		- （2）对（1）中所述方法的研究。

	- 软件工程是一种层次化技术

		- 软件工程的基础是过程层
		- 软件工程方法为构建软件提供技术上的解决方法
		- 软件工程工具为过程和方法提供自动化或半自动化的支持

- 软件过程

	- 定义

		- 软件过程是工作产品构建时所执行的一系列活动、动作和任务的集合。

	- 过程框架

		- 沟通
		- 策划
		- 建模
		- 构建
		- 部署

### 03 软件过程结构

- 软件过程

	- 一个创建高质量软件所需要完成的活动、动作和任务的框架

		- 每个框架活动由一系列软件工程动作构成
		- 每个软件工程动作由任务集来定义，这个任务集明确了将要完成的工作任务、将要产生的工作产品、所需要的质量保证点，以及用于表明过程状态的里程碑

- 通用过程模型

	- 五种框架活动

		- 沟通、策划、建模、构建、部署

	- 过程流

		- 过程流描述了在执行顺序和执行之间上如何组织框架中的活动、动作和任务

	- 类型

		- 线性过程流
		- 迭代过程流
		- 演化过程流
		- 并行过程流

### 04 过程模型

- 瀑布模型：经典生命周期

	- 使用情景

		- 瀑布模型适用当需求确定、工作采用线性
方式完成时，瀑布模型是一个有用的过程
模型。

	- 提出了一个系统的、顺序的软件开发方法，从用户需求规格说明开始，通过策划、建模、构建、部署的过程，最终提供完整的软件支持
	- 
	- V模型

		- 描述了质量保证动作同沟通、建模相关动作以及早期构建相关的动作之间的关系。
		- 
		- 提供了一种将验证和确认动作应用宇早期软件工程工作中的直观方法。

- 增量模型

	- 适用情景

		- （1）初始的软件需求明确，但是整个
开发过程却不宜单纯运用线性模
型。
		- （2）同时可能迫切需要为用户
迅速提供一套功能有限的软件产
品，然后在后续版本中再进行细
化和扩展功能。
		- （3）例如第一个增量往往是核心产品，
附加功能进入下个增量计划。

	- 特点

		- 综合了线性过程流和并行过程流的
特征。
		- 每个增量都提交一个可以运行的产
品。

	- 
	- 第一个增量为核心产品，满足了基本的需求

- 原型模型

	- 适用情景

		- （1）客户提出了一些基本功能，但没有详细定义功能和特性需求。
		- （2）开发人员可能对算法的效率、操作系统的兼容性和人机交互的形式等情况并没有把握。

	- 特点

		- （1）当需求很模糊时，原型开发模型都能帮助开发人员和利益相关者更好地理解究竟需要做什么。
		- （2）构建的一个系统很少是好用的，可能因为太慢太大，难以使用。
		- （3）原型一般作为被丢弃的系统。

	- 
	- 问题

		- （1）整体软件质量不如人意
		- （2）可能会采用一种折衷手段导致不完美

- 统一过程模型

	- 一种“用例驱动，以架构为核心，迭代并且增量”的软件过程与统一建模语
言的紧密结合
	- 
	- 特性

		- 用例驱动，以架构为核心，迭代并且增量
		- 尝试从传统的软件过程中挖掘最好的特征和性质
		- 认识到与客户沟通以及从用户的角度描述系统（用例）并保持该描述一致性的重要性
		- 强调软件体系结构的重要作用
		- 建立了迭代的、增量的过程流，提供了演进的特性

	- 统一过程（UP）的阶段

		- 起始阶段
		- 细化阶段
		- 构建阶段
		- 转换阶段
		- 生产阶段

### 05 敏捷开发

- 简述

	- （1）是由客户对他们的需求的描述（场景）所驱动的
	- （2）意识到计划是短期的
	- （3）着重强调构建活动的软件迭代开发
	- （4）交付多个软件增量
	- （5）适应变更的出现

## 2 建模

### 07 理解需求

- 软件需求IEEE定义

	- （1）用户解决问题或达到目标所需的条件或能力
	- （2）系统或系统部件要满足合同、标准、规范或其它正式规定文档所需具有的条件或能力
	- （3）一种反映上面（1）或（2）所描述的条件或能力的文档说明

- 需求工程7项明确任务

	- （1）起始
	- （2）获取
	- （3）细化
	- （4）协商
	- （5）规格说明
	- （6）确认
	- （7）管理

### 08 需求建模：基于场景的方法

- 简述需求建模模型（教材）

	- （1）场景模型

		- 出自各种系统“参与者”观点的需求

	- （2）数据模型

		- 描述问题信息域的模型

	- （3）面向类的模型

		- 表示面向对象类（属性和操作）的模型，方式为通过类的协作者获得系统需求。

	- （4）面向流的模型

		- 表示系统的功能元素并且描述当功能元素在系统中运行时怎样进行数据变换

	- （5）基于行为和模式的模型

		- 描述如何将软件行为看作外部“事件”后续的模型

- 需求建模模型（007）？？？

	- （1）场景模型

		- 从用户角度来看的系统

	- （2）数据模型

		- 表示数据在系统内是如何转换的

	- （3）面向类的模型

		- 定义对象、属性和关系

	- （4）面向流的模型

		- 表述数据在系统内是如何转换的

	- （5）行为模型

		- 表示事件对系统状态的影响

- 需求建模的方法（ppt）

	- （1）基于场景的模型

		- 从用户角度来看的系统

	- （2）类模型

		- 定义对象、属性和关系

	- （3）流模型

		- 表述数据在系统内是如何转换的

	- （4）行为模型

		- 表示事件对系统状态的影响

### 09 需求建模：基于类的方法

- 评审CRC（类-职责-协作者建模）模型

	- （1）所有的参与者（CRC模型）评审的人员拿到一部分CRC卡模型索引卡。拆分协作卡片（也就是说每个评审员不得有两张存在协作关系的卡片）。
	- （2）分类管理所有的用例场景（以及相关的用例图）。
	- （3）评审组长细致地阅读用例。 当评审组长看到一个已命名的对象时，给拥有相应类索引卡的人员一个令牌。
	- （4）当令牌传递时，类卡的拥有者需要描述卡上记录的职责。评审组确定（一个或多个）职责是否满足用例需求。
	- （5）如果记录在索引卡上的职责和协作不能满足用例，就需要修改卡片。修改可能包括定义新类（和相关的CRC索引卡），或者在已有的卡上说明新的或修改的职责、协作。

### 10 需求建模：行为和模式

- 行为模型建模步骤

	- （1）评估所有的用例，以保证完全理解系统内的交互顺序
	- （2）识别驱动交互顺序的事件，并理解这些事情如何与特定的对象相互关联
	- （3）为每个用例生成序列
	- （4）创建系统状态图
	- （5）评审行为模型以验证准确性和一致性

### 11 设计概念

- 从需求模型到设计模型的转换

	- 

- 模块功能独立性及其评估标准 11.3.7 p140

	- 功能独立性

		- 通过开发具有“专一”功能和“避免”与其他模块过多的交互模式，可以实现功能独立

	- 评估标准

		- （1）内聚性显示了某个模块相关功能的强度。

			- 一个内聚的模块执行一个独立的任务，与程序的其他部分构建只需要很少的交互。简单地说，一个内聚的模块应该只能完成一件事情。

		- （2）耦合性显示了模块间的相互依赖性。

			- 耦合性依赖于模块间的接口复杂性、引用或进入模块所在的点以及什么数据通过接口信息传递。

- 重构的定义及其检查要点 11.3.10 p141

	- 重构定义

		- 重构是使用这样一种方式改变软件系统的过程：不改变代码（设计）的外部行为而是改进其内部结构。

	- 检查要点

		- 检查现有设计的：

			- （1）冗余性
			- （2）没有使用的设计元素
			- （3）低效的或不必要的算法
			- （4）拙劣的或不恰当的数据结构
			- （5）其他设计不足，修改这些不足以获取更好的设计

### 12 体系结构设计

- 体系风格描述4要素

	- （1）完成系统需要的某种功能的一组构建（例如数据库、计算模块）
	- （2）能使构件间实现“通信、合作和协调”的一组连接件
	- （3）定义构件如何集成成为系统的约束
	- （4）语义模型，能使设计者通过分析系统组成的已知属性来理解系统的整体性质

- 风格分类

	- （1）以数据为中心的体系结构
	- （2）数据流体系结构
	- （3）调用和返回体系结构
	- （4）面向对象体系结构
	- （5）层次体结构

### 13 构件级设计

- 构件级设计的7个基本原则

	- （1）开闭原则(OCP)。“模块[构件]应该对外延具有开放性，对修改具有封闭性”。
	- （2）Liskov 替换原则(LSP)。“子类可以替换它们的基类”。
	- （3）依赖倒置原则(DIP)。“依赖于抽象，而非具体实现”。
	- （4）接口分离原则(ISP)。“多个客户专用接口比一个通用接口要好”。
	- （5）发布复用等价性原则(REP)。“复用的粒度就是发布的粒度”。
	- （6）共同封装原则(CCP)。“一同变更的类应该合在一起”。
	- （7）共同复用原则(CRP).。“不能一起复用的类不能被分到一组”。

- 内聚性13.2.3 p183

	- 我们将内聚性描述为构件的“专一性”
	- 内聚性级别排序

		- （1）功能内聚
		- （2）分层内聚
		- （3）通信内聚

- 耦合性13.2.4 p184

	- 耦合性是类之间彼此联系程度的一种定性度量。
	- 耦合分类

		- （1）内容耦合
		- （2）控制耦合
		- （3）外部耦合

### 14 用户界面设计

- 黄金规则

	- （1）把控制权交给用户

		- （1）以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式。
		- （2）提供灵活的交互。
		- （3）允许用户交互被中断和撤销。
		- （4）当技能级别增长时可以使交互流线化并允许定制交互。使用户与内部技术细节隔离开来。
		- （5）设计应允许用户与出现在屏幕上的对象直接交互。

	- （2）减少用户记忆负担

		- （1）减少对短期记忆的要求。
		- （2）建立有意义的缺省。
		- （3）定义直观的快捷方式。
		- （4）界面的视觉布局应该基于真实世界的象征。
		- （5）以不断进展的方式揭示信息。

	- （3）保持界面一致

		- （1）允许用户将当前任务放入有意义的环境中。
		- （2）在应用系统家族内保持一致性。
		- （3）如果过去的交互模型已经建立起了用户期望，除非有不得已的理由，否则不要改变它。

##