软件体系结构和软件体系结构风格

软件体系结构

是具有一定形式的结构化元素，即构建的集合，包括处理构件、数据构件和连接构件

三层体系结构

三层体系结构
客户层	用户连接和用于请求的出发地 JBDC DHTML AppLet
	典型应用是网络浏览和胖客户（如Java程序）
服务器层	典型应用是Web服务器和运行业务代码的应用程序服务器
	CGI SAPI ASP PHP JSP EJB ServLet
数据层	典型应用是关系型数据库和其他后端数据资源，如Oracle ，SQL Server等

软件体系结构风格

软件体系结构风格
数据流风格	预处理序列     管道/过滤器
调用/返回风格	主程序/子程序    面向对象风格    层次结构
独立构件风格	进程通讯    事件系统
虚拟机风格	解释器    基于规则的系统
仓库风格	数据库系统    超文本系统    黑板系统

软件工程概述及软件工程的三要素

软件危机

由于软件开发技术无法满足日益增长的需求，引发了软件危机
由于软件开发本身的复杂性
是与当时的手工作坊软件开发模式有密切关系

软件工程

是开发、运行、维护和修复软件的系统方法

三个要素

三个要素
方法	是指完成软件开发的各项任务的技术方法
工具	是指为运用方法而提供的软件工程支撑环境
过程	是指为获得高质量的软件所需要完成的一系列任务的框架

软件设计的基本原则

基本原则

基本原则
信息隐蔽	包含在模块内的信息对于无需这些信息的其他模块是不可存取的，即将不需要的信息都隐藏起来，只允许其他模块知道其本身所需要的信息
模块独立性	指软件系统中每个模块只涉及软件需求的具体子功能，而和软件系统中其他的模块接口是简单的
抽象	从具体问题中，提取出具有共性的模式，在使用通用的解决方法加以处理

配置管理

配置管理
配置项	是逻辑上组成软件系统的各组成部分
	如果一个产品同时包括硬件和软件部分，一般一个CI也同时包括软件和硬件部分
基线（属性）	通过正式的评审过程建立
	第一个基线包含了通过评审的软件需求

基线 开发库/受控库/产品库

基线开发库/受控库/产品库
开发库	用于存放项目期间处于开发状态的相关文档和代码
	以及存放项目组工作期间的相关沟通记录等
受控库(软件配置库)	用于存放经过验证后的产品（包括基线产品）
	建立测试区，用于存放开发工作结束后需要进入测试的配置项
	以及为变更实施提供工作空间
产品库	存放发布后的产品

能力成熟度模型CMM的分级介绍

能力成熟度模型CMM的分级介绍
CMM	软件工程能力成熟度模型
	衡量软件企业开发和管理水平的主要参考因素
	软件过程改进事实上的工业标准
CMM的分级	1、初始级：软件过程的特点是无序的，有时甚至是混乱的
	2、可重复级：已经建立了基本的项目管理过程，可用于对成本、进度和功能特性进行跟踪
	3、已定义级：用于管理和工程的软件过程均已文档化、标准化，并形成整个软件组织的标准软件过程
	4、已管理级：软件工程和产品质量有详细的度量标准
	5、优化级：通过对来自过程、新概念和新技术等方面的各种有用信息的定量分析，能够不断地、持续地进行过程改进

新旧系统转换

新旧系统转换
直接转换	直接转换
	不能用于重要的系统
	节约资源，风险大
试点后直接转换	试点成功后直接转换
	风险较小，试点的部分可用于示范和培训
逐步转换	分期分批进行转换
	增加接口，导致衔接问题
	避免和直接转换的风险，又避免了并行转换时费用大的问题
	在转换过程中，可以问题进行修改，调试，不断完善新系统
并行转换	安排一段时间，新旧系统并行运行
	可进行对比，发现和改造新系统的问题，风险小，安全，可靠

开发模型

瀑布模型

严格遵循软件生命周期个阶段的固定顺序，一阶段完成后才进入下一阶段
适用项目 需求明确、解决方案明确的项目

瀑布模型
优点	线性，阶段划分明确
	以项目的阶段评审和文档控制为手段有效的对整个开发过程进行指导
缺点	过于理想化，缺乏灵活性
	无法在开发过程中逐渐明确用户难以确切表达或一时难以想到的需求
	直到开发完成后才发现与用户需求之间的差距，修正偏差代价高，风险高
	早期的错误可能要等到开发后期的测试阶段才能发现

V模型

是瀑布模型的改进
将测试分级，并且与开发阶段对应
适用项目 与瀑布模型类似，但对性能、安全要求较高的项目

V模型
优点	纠正了不重视测试阶段重要性的错误认识，将测试分等级，并和前面的开发阶段对应起来
缺点	过于理想化，缺乏灵活性

原型模型

模拟某种产品的原始模型
软件原型是一个早期可以运行的版本
它反映最终系统的部分主要特性
快速原型模型：是一种抛弃式的原型化方法
演化模型：是一种原型化开发、渐进式的原型化方法
适用项目：需求不明确，动态变化的项目（如界面的开发）

原型模型
优点	利于增进软件人员和用户对系统服务需求的理解
	原型的最终版本可作为最终产品或者最终系统的一部分
缺点	文档容易被忽略
	建立原型的许多工作会浪费
	项目难以规划和管理

增量模型

运行客户的需求可以逐步提出来
软件产品被增量式的一块块开发，每一个增量均发布一个可操作产品
使用项目：需求大部分明确，系统较为复杂，有一点技术风险

增量模型
优点	增强了客户使用系统的信息，逐步提出对后续增量的需求
	增量从高到低的优先级确定保障了系统重要功能部分的可靠性
	项目总体失败的风险较低
缺点	增量的粒度选择问题
	确定所以的基本业务服务比较困难

螺旋模型

采用一种周期性的方法来进行系统开发，结合原型方法和瀑布模型
每一周期都包括指定计划、风险分析、实施工程和评审4个阶段，进行迭代
适用项目：庞大、复杂并具有高风险的系统

螺旋模型
优点	客户始终参与，和管理层有效地交互
	强调风险分析，使得开发人员和用户对每个演化层出现的风险有所了解
缺点	需要具有相当丰富的风险评估经验，在风险较大的项目开发中，如果未能够及时标识风险，势必造成重大损失
	过多的迭代次数会增加开发成本，延迟提交时间

喷泉模型

认为软件开发过程自下而上周期的各阶段是相互迭代和无间隙的特性
软件的某个部分常常被重复工作多次，相关对象在每次迭代中随之加入渐进的软件成分
适用项目：主要用于采用对象技术的软件开发项目

喷泉模型
优点	模型的各个阶段没有明显的界限，开发人员可以同步进行开发
	是可以提高软件项目开发效率，节省开发时间，适应于面向对象的软件开发过程
缺点	由于喷泉模型在各个开发阶段是重叠的，因此在开发过程中需要大量的开发人员，因此不利于项目的管理
	此外这种模型要求严格管理文档，是的审核的难度加大，尤其是面对可能随时加入各种信息、需求与资料的情况

统一过程模型（UP/RUP）

统一过程又称为UP、或RUP，是基于构件的。统一过程是一个通用的过程框架，可以用于各种各样的软件项目。
特点：用例驱动、以基本架构为中心、迭代和增量。
基于UP的软件过程是一个迭代的过程有四个阶段：
初始阶段：为系统建立业务模型并确定项目的边界；
细化阶段：分析问题领域，建立健全的架构基础 。主要是要完成系统的架构。
构件阶段：开发剩余的构件和应用程序功能，形成产品并且进行详细的测试
交付阶段：主要任务是进行β测试(用户环境，用户做的测试)

统一过程的设计概念：
工件：是活动生产、创建或修改的一段信息
活动：是一个明确的独立工作单元
角色：描述某个人或者一个小组的行为职责
工作流

敏捷方法

适用于中小型项目，理论上是不适用大型项目。但是在实际开发中，往往我们会把大型项目拆分为多个小型项目，然后使用敏捷开发方法

设计方法

面向对象

Booch方法：
动态逻辑模型描述对象之间的相互作用
静态物理模型通过模块描述代码的布局

面向数据结构

Jacobson方法：
涉及到整个软件生命周期，包括需求分析，设计，实现和测试等4个阶段(面向数据结构的设计方法)

面向数据结构的设计方法

关键概念：use case

是指行为相关的事物序列，该序列将由用户在于系统的对话中执行
一个use case就是一个使用系统的方式

结构化分析方法

（是一种面向数据流的需求分析方法）

基本思想是自动向下逐层分解，把一个大问题分解成若干个小问题，每个问题在分解成若干个更小的问题
经过逐层分解，复杂的问题就简单化了

结构化设计方法

（是一种面向数据流的设计方法）
以结构化阶段所产生的文档为基础，自顶向下，逐步求精和模块化的过程

分类

概要设计：确定软件系统的结构，进行模块划分，确定每个模块的功能、接口及模块间的调用关系

详细设计：为每个模块设计实现的细节

软件生命周期及各个阶段的特点

软件生命周期：

软件是从形成概念开始，经过开发，使用和维护，直到最后退役的全过程

主要包括

可行性研究和项目开发计划：

通过分析用户提出的软件开发要求，确定软件项目的性质、目标和规模，得出可行性研究报告

需求分析：

是软件生命周期中重要的一步，也是决定性的一步
把软件功能和性能的总体概念描述为具体的软件需求规格说明，奠定软件开发的基础（系统的逻辑模型）

设计：

概要设计
详细设计
系统设计说明书

实现：

写出正确的、易理解的和易维护的程序模块

需求分析中的需求层次，类型等

业务需求

指反映企业或客户对系统高层次的目标要求
可以确定项目试图和范围

用户需求

用户的具体目标，或用户要求系统必须完成的任务

系统需求

从系统的角度来说明软件的需求

功能需求

规定了开发人员必须在系统中实现的软件功能
行为需求：通常是通过系统特性的描述表现出来的

非功能需求

指系统必须具备的属性和品质
可细分为：软件质量属性（如：可维护性、可靠性、效率等）和其他的非功能需求

设计约束

限制条件或补充规约
通常是对系统的一些约束说明
如：必须采用国有自主知识产权的数据库系统，必须在UNIX操作系统之下等

结构化开发常用工具

结构化开发常用工具
结构化分析	数据流图        数据字典
	描述加工逻辑的结构化语言、判定表或判断树
结构化设计	概要设计	结构图
		层次图
		HIPO图
	详细设计	程序流程图        程序框图
		盒图（N-S图）
		PAD图
		PDL（伪码）

MVC中M,V,C的含义及主要作用

实现一种动态的程序设计，简化日后对程序的修改和扩展，使程序的某一部分重复利用成为可能

可维护性及软件维护的分类

可维护性是指理解、改正、改动、改进软件的难易程度

可维护性

可维护性
可理解性	指维护人员理解软件的结构、接口、功能和内部过程的难易程度
可测试性	是指测试和诊断软件错误的难易程度
可修改性	是指修改软件的难易程度

软件维护分类

软件维护分类
改正性维护 （25%）	是指在适用过程中发现了隐蔽的错误后，为了诊断和改正这些隐蔽错误而修改软件的活动
适应性维护 （20%）	是指为了适用变化了的环境而修改软件的活动
完善性维护 （50%）	是指为了扩充或完善原有软件的功能或性能而修改软件的活动
预防性维护 （5%）	是指为了提高软件的可维护性和可靠性、为未来的进一步改进打下基础而修改软件的活动

系统分析的任务与步骤

系统分析的任务与步骤
主要任务	理解用户需求
	确定系统逻辑模型
	形成系统分析报告	系统设计的依据
		系统验收的依据

数据流图与数据字典

数据流图

DFD，从数据传递和加工的角度，以图形的方式刻画系统内数据的运动情况

数据字典

对数据流图的主要补充和说明
是以特定格式记录下来的、对系统的数据流图中各个基本要素（数据流、处理逻辑、数据存储和外部实体）的内容和特征所做的完整定义

两者区别

数据流图：描述了系统的分解，描述的数据的处理流程

数据字典：描述具体的内容和特征

数据流图的基本成分与绘制方法

数据流图设计注意事项

分成数据流图
层次关系	顶层数据流图，中间数据流图和底层数据流图
	除顶层图外，其余分层数据流图从0开始编号
顶层数据流图	只含有一个加工，表示整个系统
	输入和输出数据流为系统的输入数据和输出数据，表明了系统的范围，以及与外部环境的数据交换关系
底层数据流图	指其加工不能再分解的数据流图，其加工成为“原子加工”（不可再分解）
中间数据流图	是对父层数据流图中某个加工进行细化，而其某个加工可以细化，形成子图

原则：

自外向内，自顶向下，逐层细化，完善求精
保持父图与子图的平衡
保持数据守恒
加工细节隐藏
简化加工间的关系
均匀分解
适当取名，避免空洞的名字
表现的是数据流而不是控制流
每个加工必须既有输入数据流，又有输出数据流

系统总体设计与详细设计的内容

总体设计（概要设计）	总体布局设计	网络拓扑结构设计
		资源配置设计
	模块化结构设计	划分功能模块
		模块功能和职责
		模块间的调用关系
		模块间的信息传递
详细设计	代码设计
	数据库设计
	输入/输出设计
	用户界面设计
	处理过程设计
其他设计任务	标准化设计
	描述设计结构
	拟定实施方案

结构化设计方法和工具-系统流程图

系统流程图是表达系统执行过程的描述工具

着重与表达：数据在系统中传输时所通过的存储介质和工作站，与物理技术密切联系
缺点：不能反映系统结构、模块功能、无法评审是否符合要求

绘制图的主要依据

结构化设计方法和工具-HIPO图

IPO图是一种反映模块的输入、处理和输出的图形化表格
描述了模块的输入输出关系、处理内容、模块的内部数据和模块的调用关系
HIPO图：分层次自顶向下分解系统，将每个模块的输入、处理和输出关系表示出来就得到了HIPO图

结构化设计方法和工具-控制结构图

控制结构图描述了模块之间的调用方式，体现了模块之间的控制关系

结构化设计方法和工具-模块结构图

数据流程图着眼于数据流，反映系统的逻辑功能，即系统能够“做什么”
结构图着眼于控制层次，反映系统的物理模型，即怎样逐步实现系统的总功能
程序框图与结构图：前者用于说明程序的步骤，先做什么，再做什么。后者描述各模块的”责任“

信息系统设计的原则

软件系统结构设计的原则

软件系统结构设计的原则
主要原则	分解—协调原则
	信息隐蔽和抽象的原则
	自顶向下原则
	一致性原则
	面向用户原则

模块结构设计

模块独立性的度量（高聚合，低耦合）

聚合：衡量模块内部各元素结合的紧密程度
耦合：度量不同模块间互相依赖的程度

聚合

聚合度 （低–高）	偶然聚合	模块完成的动作之间没有任何关系，或者仅仅是一种非常松散的关系
	逻辑聚合	模块内部的各个组成在逻辑上具有相似的处理动作，但功能用途上批次无关
	时间聚合	模块内部的各个组成部分所包含的处理动作必须在同一时间内执行
	过程聚合	模块内部各个组成部分所要完成的动作虽然没有关系，但必须按特定的次序执行
	通信聚合	模块的各个组成部分所完成的动作都要使用了同一个数据或产生同一输出数据
	顺序聚合	模块内部的各个部分，前一部分处理动作的最后输出是后一部分处理动作的输入
	功能内聚	模块内部各个部分全部属于一个整体，并执行同一功能，且各部分对实现该功能都必不可少

耦合

耦合度（低–高）	非直接耦合	两个模块之间没有直接关系，他们的联系完全是通过主模块的控制和调用来实现的
	数据耦合	两个模块彼此间通过数据参数交换信息
	标记耦合	一组模块通过参数表传递记录信息，这个记录时某一个数据结构的子结构，而不是简单变量
	控制耦合	两个模块彼此间传递的信息中有控制信息
	外部耦合	一组模块都范围同一全局简单变量而不是同一全局数据结构，而且不是通过参数表传递该全局变量的信息
	公共耦合	两个模块之间通过一个公共的数据区域传递信息
	内容耦合	一个模块需要涉及到另一个模块的内部信息

功能模块设计原则

系统分解有层次
适宜的系统深度和宽度比例
模块大小适中 50~100行，最多不超过500行
适度控制模块的扇入扇出 扇出3~4一般不超过7，扇入越大越好
较小的数据冗余

数据库设计的4个阶段及各阶段的任务

数据库设计

核心问题：从系统的观点出发，根据系统分析和设计的要求，结合选用的DMBS，建立一个数据模式

用户接口界面设计与内容

设计原则

统一原则
简明易学原则
灵活原则
美观原则
宽容原则
严谨原则

内容

定义界面形式
定义基本的交互控制形式
定义图形和符号
定义各种操作方式
定义信息反馈的策略
定义Help策略

界面类型

菜单式
填表式
对话式
图形式
窗口式

处理过程设计与程序流程图

程序流程图

程序框图
通过对输入输出数据和处理过程的详细分析，将计算机的主要运行步骤和内容用框图表示出来

程序框图三种基本成分

加工步骤：用方框表示
逻辑条件：用菱形表示
控制流：用箭头表示

三种基本逻辑结构

顺序结构

是一种线性有序的结构，由一系列依次执行的语句或模块构成

循环结构

时由一个或几个模块构成，程序运行时重复执行，知道满足某一条件为止

选择结构

是根据条件成立与否选择执行路径的结构

编码的原则与提高可读性的方法

编码原则

测试优先 在开始编码之前建立单元测试

选择良好的程序设计风格

对代码进行正确的注释，是注释与代码保持一致

变量规范命名，如取见名知意

提高可阅读性，可维护性的方法

可读性好

结构化程序设计

限制使用GOTO语句
逐步求精的设计方法
自顶向下的设计、编码和调试
主程序元制的组织形式

注释

序言性注释

在每个程序或模块的开头的一段说明，起对程序理解的作用
程序的表示、名称和版本号
程序功能描述
接口与截面描述
输入/输出数据说明
开发历史
与运行环境有关的信息

解释下注释

一般嵌在程序之中，与要注释的部分匹配
注释一定要找程序编制中书写
解释下注释不是简单直译查询语句，应能说明”做什么“
一定要保证注释与程序的一致性，程序修改时注释也要修改

系统排错调试的5种方法

排错调试	试探法	分析错误症状    猜测问题的位置（效率低、缓慢 适用于简单程序）
	回溯法	从发现症状的位置开始    人工沿控制流往回跟踪（适用于小型程序）
	对分查找法	前提：知道变量若干位置的正确值从相关地方赋值，运行程序，观察结构
	归纳法	从错误出发，收集数据，分析之间的关系，提出假想原因，用这些数据来证明
	演绎法	列出所有可能的原因，分析已有的数据，排除不可能或矛盾的原因，选择可能性最大的，完善假想

UML

UML 是一种定义良好、易于表达、功能强大且普遍实用的建模语言（是一种建模语言，不是方法）

UML概念	一种可视化语言	一组图形符号    一种图形化语言    建立了模型
	一种构造语言	可用UML描述的模型映射成编程语言
	一种文档语言	UML适于建立体系结构及其所有的细节文档

UML三要素

事物

是对模型种最具有代表性的成分的抽象

结构事物
行为事物
分组事物
注释事物

关系

把事物结合在一起

依赖关系
关联关系
泛化关系（继承关系）
实现关系

图

聚集了相关的事物

用例图
静态图
行为图
交互图
实现图

UML-事物

结构事物

UML模型种的静态部分，描述概念或物理元素，共7种
类
接口
协作
用例
活动类
组件
结点

行为事物

UML模型中的动态部分，描述了跨时间和空间的行为，共2类
交互
状态机

分组事物

UML模型的组织部分，是一些有模型分解成的”盒子“
包

注释事物

UML模型的注释部分，描述，说明和标注模型的任何元素
注解

UML-关系

依赖关系

是两个事物间的语义关系，其中一个事物（独立事物）发生变化会影响另一个事物的语义

关联关系

是一种结构关系，描述了一组链，链是对象之间的链接
聚合是一种特殊的类型关联，描述了整体和部分间的结构关系

泛化关系（继承关系）

是一种特色/一般关系，特俗元素（子元素）的对象可替代一般元素（父元素）的对象

实现关系

是类元之间的语义关系，其中的一个类元指定了有另一个类元保证执行的契约

UML-图

用例图

从用户角度描述系统功能，并指出各功能的操作者

静态图

类图 描述系统中类的静态结构
对象图 是类图的实例，一个对象图是类图的一个实例
包图 包图描述系统的分层结构

行为图

状态图 描述类的对象所有可能的状态以及事件发生时状态的转移条件
活动图 描述满足用例要求所要进行的活动以及活动间的约束关系，利于识别并行活动

交互图

顺序图 显示对象之间的动态合作关系，强调对象之间消息发生的顺序，同时显示对象之间的交互
合作图 描述对象间的协作关系，显示对象间的动态合作关系
如果强调时间和顺序，则使用顺序图
如果强调上下级关系，则选择合作图

实现图

组件图 描述代码部件的物理结构及各部件之间的依赖关系
配置图 定义系统中软硬件的物理体系结构
显示连接关系 显示依赖关系

软件评审评价及通用的软件评价过程

使用质量

使用质量是从用户角度看待的质量

使用质量

有效性 指软件产品在指定使用环境下，使用户获得满足准确度和完整性要求的规定目标的能力

生产率 指软件产品在指定的使用环境下，使用户可使用与获得的有效性有关的合适数量资源的能力

安全性 指软件产品在指定使用环境下，获得可接受的对人类、事物、软件、财产或环境有害的风险级别的能力

满意度 指软件产品在指定使用环境下，使用户满意的能力

软件评审

在软件开发的各个阶段都要进行评审

目标

发现任何形式的软件功能、逻辑或实现方面的错误
通过评审验证软件的需求
保证软件按预先定义的标准表示
以获得的软件是以统一的方式开发的
使项目更容易管理

质量评审

是为了确定、达到和维护需要的软件质量而进行的所有 有计划、有组织的管理活动

主要目标

是计划软件质量保证活动
客观地验证软件产品和活动符合规定的标准、程序和需求，评审过程的符合性，审计工作产品的符合性
将软件质量保证活动和结果通知到相关的组合个人，并将软件项目中不能解决的不符合要求的问题报告给有关的高级管理者

设计质量评审

对象

软件需求规格说明书
数据需求规格说明书
概要设计说明书

评审方面

评价软件的规格说明是否合乎用户的要求
评审可靠性
评审保密措施实施情况
评审性能实施情况
评审操作特性实施情况
评审软件是否具有可修改性、可扩充性、可交互性和可移植性
评审软件是否具有可测试性
评审软件是否具有复用性

正式的技术评审

软件评审时评审软件产品，不要涉及对软件生产者能力的评价

评审前要制定严格的评审计划，并严格遵守预计的日程安排

对评审中出现的问题要记录再按，不要过多的讨论解决方案，把问题留给软件生产者来解决

要现在参与者人数，并要求参加评审的人员在评审会之前仔细阅读文档，做好充分的准备

度量

软件产品的测量套能简单有经济地运行，而且测量结果要易于使用

质量特性的定义方式不允许对其进行直接测量

与某个质量特性相关的每个可量化的软件内部属性和每个可量化的软件外部属性，与其软件环境进行相互作用，能被确立为一种度量

用于开发过程的度量应与用户观点的度量有关，从用户视角出发的度量时至关重要的

软件评价-GB/T8905.5

评价者用的过程

这种评价是应开发者、需方或其他的请求来进行的 这部分将由那些执行独立的人员使用，通常为第三方组织工作

通用评价过程

确立评价需求

设计评价 选择度量 测量的种类 确立度量判定等级 确立评估准则

规定评价

执行评价

软件评价过程的特性

可重复性 指由同一评价者按同一评价规格说明对同一产品进行重复的评价，应产生同一种可接受的结果

可再现性 指由不同评价者按同一评价规格说明对同一产品进行评价，应产生同一种可接受的结果

公正性 指评价应不偏向任何特殊的结果

客观性 指评价结果应是客观事实，不带有评价者的感情色彩或主观意见

评价规格说明

目的

定义评价范围，定义供评价产品及各种部件执行的测量

应详细到以此能确保评价的可重复性和可再现性

活动组成

分析产品的描述

规定对产品及部件执行的测量

安装评价需求验证编制的规格说明

软件部件管理

评价这应登记全部软件部件和软件的相关文档

在证实了软件的规模和复杂程度之后，应使用正式的配置管理

登记信息

部件或文档的唯一标识符
部件的名称或文档标题
文档的状态（包括物理状态和变异状态）
请求者提供样品的版本、配置和日期信息
接收的日期

评价过程文档

中间产品

评价需求： 描述评价的目标，特别是描述了产品的质量需求
评价规格说明： 确定对软件及其部件实行的所有分析的测量，表示要分析和测量的软件部件
评价计划： 描述评价规格说明需要实施的操作过程 描述评价所需用到的方法和工具

最终产品

评价记录：评价执行计划时详细记载的动作组成，记录有评价者保留
评价报告：执行测量和分析的结果，以及能被重复和重新评价的必要信息
评价报告首先作为评审草案来发布，其最终版本将交给请求者

识别面向对象的概念，对象，类，消息，继承等

识别面向对象

面向对象 = 对象 + 分类 + 继承 + 通过消息的通信

对象

是最基本运行时的实体，既包括数据（属性），也包括（行为）

类

类所包含的方法和数据描述一组对象的共同行为和属性

类是在对象之上的抽象，对象是类的具体化，是类的实例

消息

对象之间进行通信的一种构造

继承

父类和子类之间共享数据和方法的机制

多态

收到同一消息，可用产生完全不同的结果

面向对象分析与面向对象设计

面向对象分析

目的

是为了活动对应用问题的理解
确定系统的功能、性能要求
明确用户的功能需求
面向对象分析方法是将数据和功能结合在一起作为一个综合对象来考虑
面向对象分析技术可用将系统的行为和信息间的关系表示为迭代构造特征

5个活动

认定对象
组织对象
描述对象间的相互作用
定义对象的操作
定义对象的内部消息

面向对象设计

目的

确定实现用户需求的方法

即怎样左才能满足用户需求，并构造出系统的实现蓝图

设计模式

是对被用来在特写场景下解决一般设计问题的类和相互通信的对象的描述

设计描述可用帮助开发者做出有利于复用的选择，避免设计是损害系统复用性

设计模式的4个基本要素

模式名称 描述模式的问题、解决方案和效果

问题 描述了应该在何时使用模式

解决方案 描述了设计的组成成分，他们之间的相互关系及各自的职责和协作方式

效果 描述了模式应用的效果及使用模式应权衡的问题

面向对象程序设计

面向对象程序设计范型

基于前面的设计范型（过程，模块化，函数，逻辑等程序设计泛型）

关键在于加入类和继承性

类和继承性，提高了抽象的程度

类库

是一种预先定义的程序库，可由开发人员自己扩充

丰富的类库是衡量一个面向对象程序设计语言成熟与否的一个重要标志

创建型设计模型，行为模型与结构型设计模型

模式

创建型设计模式

抽象了实例化过程，其帮助一个系统独立于如何创建、组合和表示它的那些对象

单身（Singleton）模式

保证Configure类只能有一个实例，这样，Configure类的使用者无法定义该类的多个实例，否则会产生编译错误

行为模式

涉及到算法和对象间职责的分配

不仅描述对象或类的模式，还描述他们之间的通信模式

TemplateMethod

模板方法是一个算法的抽象定义

Interpreter

将一个文法表示为一个类层次，并实现一个解释器作为这些类的实例上的一个操作

结构型设计模式

涉及到如何组合类和对象以获得更大的结构

采用继承机制来组合接口或实现

Composition模式

描述了如何构造一个类层次是式结构，这一结构有两种类型的对象多对应的类构成

Flyweight模式

为共享对象定义了一个结构

共享机制主要强调对象的空间效率

Facade模式

描述了如何用单个对象表示整个子系统

Bridge模式

将对象的抽象和其现实分离，从而可用独立地改变他们

Decorator

描述了如何动态的为对象添加职责

采用递归方式组合对象，从而允许添加任意多的对象职责