软件工程-总

软件工程

什么是软件工程？

	简单来说就是用工程化的方法来开发软件
	任何生产活动都要按照目标化、规范化、文档化、标准化进行，这就是工程化

	软件并不是简单的程序，软件 = 程序 + 数据 + 文档
	造成软件开发困难的根本原因在于软件固有的内在特征：
	复杂性，一致性，可变性，不可见性

软件工程是从管理和技术两个方面研究如何更好的开发和维护计算机软件的学科
软件工程的目的就是为开发更高质量的软件产品提供一个工程框架

为什么会产生软件危机

• 软件开发成本估计不准
• 开发进度不能保证
• 开发出来的产品不符合用户的需求 （三点 由于忽视了软件开发前期的调研和分析工作）
• 软件产品的质量无法保证 （没有统一的，规范的方法指导，忽视测试阶段的工作）
• 软件的可维护程度低 （文档资料不齐全，忽视人与人的交流，忽视测试阶段的工作，忽视软件的维护）
• 软件开发生产率的发展跟不上硬件发展速度和人们需求的增长

主观上看：是由于开发方法不正确，用户需求不明确，缺乏正确的理论指导
客观上看：是由于软件开发规模越来越大，软件开发复杂度越来越高

软件危机产生的原因与软件本身的特点有关 ： 难以维护  逻辑复杂
还与软件开发和维护的方法不正确有关
软件  不等于 程序

软件需求是为解决特定问题而必须由被开发的软件展示的特性
定义一个系统或组件的体系结构，组件，接口和其他特征的过程，以及这个过程的结果被称为软件设计
软件构造是指通过编码，验证，单元测试，集成测试和调试的组合，详细地创建可工作的和有意义的软件的过程
软件测试是为评价和改进产品的质量，标识产品的缺陷和问题而进行的活动
软件维护是指由于一个问题或改进的需要而修改代码和相关文档，进而修正现有的软件产品并保证其完整性的过程
软件配置管理是一个支持性的软件生命周期过程
为了保证软件的开发和维护是系统的，规范的和量化的，对软件工程进行管理是非常必要的

软件工程的基本原则

1. 将软件的生命周期划分为多个阶段，实施严格的项目管理
2. 坚持阶段评审
3. 实施严格的产品控制
4. 采用现代化程序设计技术
5. 开发组人员应少而精
6. 不断改进软件工程实践

软件工程三要素

过程 方法 工具

软件工程过程是指在生命周期内，为了实现特定目标而进行的一系列相关活动。每个活动都有其确定的实现步骤
软件工程方法包含软件开发方法，软件度量方法，软件管理方法和软件环境方法，通常情况下软件工程方法等同于软件开发方法
面向过程 面向对象 面向构件 面向服务
软件工程工具

软件开发的基本策略

• 软件复用
• 分而治之
• 逐步演化
• 优化折中

软件质量

软件质量包含功能质量 结构质量 过程质量
软件运行正确并不等于正确的软件

质量不是被测出来的，而是在开发过程中逐渐构建起来的

高质量的软件要求高质量的设计，规范的编码，有效的测试

软件的生命周期

软件从功能确定，设计到开发成功投入使用，并在使用中不断的修改，增补和完善，直到被新的需要所代替而停止使用该软件的全过程

软件生命周期分为三个大的阶段

1. 软件定义阶段
2. 软件开发阶段
3. 运行和维护阶段
   
   系统的维护包括：
   改正性维护： 诊断和改正在使用过程中发现的软件错误
   适应性维护： 修改软件易适应环境的变化
   完善性维护： 根据用户的要求改进或扩充软件使它更完善（适应需求的变化）
   预防性维护： 修改软件为将来的维护活动预先做准备

软件过程模型

软件过程： 是为获得软件产品，在软件工具支持下由软件工程师完成的一系列软件工程活动
软件过程是研究软件开发的方法论，规范软件开发的活动集合和活动顺序

过程模型：

• 瀑布模型
• 原型（演化）模型
• 螺旋模型
• 统一过程模型（迭代式模型）
• 敏捷模型
• 等

瀑布模型

以预测性为原则
以文档驱动开发过程
以过程控制为核心
开发阶段严格按照线性方式进行，每一个阶段具有相关的里程碑和交付产品，且需要确认和验证
强调开发的阶段性，早期计划和需求调查以及产品测试是一种有效的面向过程的管理模式，缺乏灵活性

适合于用户需求明确，完整，无重大变化的软件项目开发

缺陷：
需求分析阶段，完全确定用户需求较为困难，甚至说是不可能的
开发周期较长，且期间用户无法看到软件效果，增加了一定的风险
实际项目很少按照要求的顺序进行

原型模型（快速原型模型）

在用户需求不明确时，快速构造一个原型（可视化的软件样机，展示系统的主要功能和接口），用户通过对原型作出评价，开发者据此意见进行修改
可视化，强化沟通降低风险，建造原型的目的仅是为了挖掘需求，之后就被抛弃

适合于那些不能预先确切定义需求的软件系统的开发

缺陷：
为了使原型尽快的工作，未考虑软件的总体质量和长期的可维护性
为了演示，可能采用了不合适的操作系统等
在需求没有完全弄清楚，过程管理不够严格时会影响最终产品的性能

增量模型

渐进的开发逐步完善的软件版本的模型。把待开发的软件系统模块化，将每个模块作为一个增量组件，从而分批次的分析，设计，编码和测试这些增量组件

增量模型融合了瀑布模型的基本成分和原型实现模型的迭代特征
增量模型强调每一个增量均发布一个可操作产品
将软件看做一组增量的构建，每次设计，实现，集成，测试和交付一块构件，知道所有构件全部实现为止

优点：
可逐步开发
可在较短时间内向用户提供部分产品
以构件为单位，降低了软件开发的风险
开发的顺序灵活
用户可一步一步的适应新产品
困难：
软件体系结构必须是开放的
多个构件并行开发，具有无法集成的风险
比瀑布模型和原型模型更需要更精心的设计

适合于具有以下特征的软件开发项目：
软件产品可分批次交付
待开发的软件可模块化
软件开发人员对应用领域不熟悉，难以一次性的进行系统开发
项目管理人员把握全局的水平较高

增量模型和迭代模型的区别：
增量模型： 在每一个新的发布中逐步增加功能直到构造全部功能
迭代模型： 先提交一个完整的系统，但其功能都是未实现的，在后续开发中逐步完善各个功能

螺旋模型

基本思想是：降低风险
适用于： 规模较大的复杂系统

螺旋模型把开发过程分为指定计划，风险分析，实施工程和客户评估四个活动

优点：
有利于软件的重用，提高了软件的质量
减少了过多测试和测试不足
维护和开发之间并没有本质区别

缺点：
风险驱动，需要相当丰富的风险评估经验和专门知识，否则风险更大
主要用于内部开发的大规模软件项目
随着迭代次数的增加，工作量加大，软件开发成本增加

喷泉模型

该模型认为软件开发过程自上而下周期的各阶段是相互重叠和多次反复的，就像喷泉的水喷上去落下来一样。特点是各项活动之间没有明显的界限。而面向对象方法学在概念和表示方法上的一致性，保证了各个开发活动之间的无缝过度

该模型重视软件研发工作的重复与渐进，通过相关对象的反复迭代在迭代中充实扩展，实现了开发工作的迭代和无间隙

RUP（统一过程模型）

RUP是基于迭代思想的软件开发模型，可以多次执行各个工作流程，有利于更好地理解需求，设计出合理的系统构架，但是对开发人员的素质要求较高

RUP是风险驱动的，基于UseCase技术的，以架构为中心的，迭代的，可配置的软件开发流程

软件开发是一个迭代与增量相结合的过程；
软件开发是由用例驱动的；
软件开发是以架构设计为中心的

软件过程模型的应用

1. 在软件开发活动中要遵循软件工程原理实行分阶段，实行阶段评审和控制。按基线与里程碑的目标进行总结，评审，调整和部署阶段活动
2. 在活动的执行顺序上可以有循环，往复，重叠，迭代，嵌套或者是有条件地引发，不一定都是线性顺序
3. 在活动的内容上是遵循自顶向下，层层分解，逐步抽象与细化的思想
4. 在构件软件的结构上遵循模块分解原理，可以自顶向下，也可以自底向上

敏捷开发

传统计划驱动的开发方法强调过分过程控制
在计划驱动方法中，过程和工具不是为人（指程序员）服务的，而是为管理者服务的

敏捷不是便捷
敏捷是一组软件开发思想的统称

什么是敏捷开发？
敏捷开发过程是容易适应变化并迅速做出调整，在保证质量的前提下做到文档适量适度
敏捷开发并不是一个具体的过程，而是一个概况行的术语
具有以人为核心，循环迭代，相应变化的特点，着眼于高质量的快速交付令客户满意的工作软件

敏捷开发不见得就会节省时间，但是能更准确的知道项目成本，或者更早知道产品的问题

敏捷方法的特征：
开发过程以代码为核心，而不是以文档为核心，经过多次小型迭代开发过程逐步逼近实际需求
以人为本，注重人与人之间面对面的交流

Scrum偏重项目管理，XP偏重编程实践

在Scrum中一个Sprint内需求是不允许变化的

极限编程（XP） 是一种轻量型的以编码为核心任务的灵活软件开发方法

目标： 在最短的时间内将较为模糊，变化较大的用户需求转化为符合用户要求的软件产品
极限编程加强开发者与用户的沟通需求，让客户全面参与软件的开发设计，保证变化的需求及时得到修正

XP的十三个实践分为三个层面：
第一层面：XP的团队组织与需求响应
第二层面：开发环境
第三层面：XP的变成核心：
测试驱动开发
结对变成
简单设计
重构

极限编程优点：
与传统的软件工程方法相比
重视客户参与，重视团队合作和沟通，制定计划前做出合理预测，重视质量，简单设计，连续的过程评估，对过去的工作的持续不断的检车，高频的重新设计和重构，递增开发

缺点：
以代码为中心，忽略了设计
缺乏设计文档，局限于小规模项目
缺乏质量规划
开发过程不想洗
质量保证依赖于测试

Scrum和XP的区别：

1. 迭代长度的不同：
   XP的一个Sprint的迭代长度大致为1-2周，而Scrum的迭代长度一般为2~4周
2. 在迭代中是否允许修改需求：
   XP在一个迭代中，如果一个User Story（用户素材，也就是一个需求）还没有实现，则可以考虑另外的需求将其替换。
   Scrum中则不允许这样做
3. 在迭代中，User Story是否严格按照优先级别来实现：
   XP是务必遵循优先级别的
   Scrum可以不按照优先级别来
4. 软件的实施过程中，是否采用严格的工程方法，保证进度或者质量：
   Scrum要求开发者自己保证
   XP则对整个流程方法定义非常严格

雨课堂第5章项目团队管理

可行性研究

三个方面：
技术可行性
社会可行性
经济可行性

UML语言概述

UML（Unified Modeling Language）， 统一建模语言

**类图：**类图是类的可视化表达，展示了系统中类的静态结构，一个类图表达类的内部封装和外部关系；若干相关类图联系在一起构成的是模型，称为类模型或逻辑模型
**对象图：**对线图是类图的一种实例化；一张对象图表示的是与其对应的类图的一个具体实例，即系统在某一时期或者某一特定时刻可能存在的具体对象实例以及他们相互之间的具体关系
**用例图：**从用户的观点对系统行为的描述。由用例（User Case）， 操作者（Actor）以及它们的关系连线组成
用例图来从用户的观察角度收集系统需求，表达系统的外部事物（参与者）与系统的交互，它表达系统的功能，即系统所提供的服务
整个软件项目的开发可以采用User Case驱动的方法进行
**用例：**是从用户角度描述系统的行为，使用椭圆表示，具有唯一的名称
**操作者：**使用人形符号表示，也具有唯一的名称
操作者和用例之间使用带箭头的实线连接，由操作者指向用例
操作者之间可以存在泛化关系，类似的参与者可以组成一个层级结构。在网上书店的例子中，会员是游客的泛化，游客有浏览图书的用例，而会员不仅包含游客的全部用例，还具有自己特有的购买图书用例

**包图：**包是类的集合，采用包可以增强代码的复用
**活动图：**活动图实质上是一种流程图，表现的是一个活动到另一个活动的控制流
**状态图：**在任一给定的时刻，一个对象总是处于某一特定的状态
状态图主要表现一个对象所经历的状态序列，引起状态或活动转移的事件，以及因状态或活动转移而伴随的动作
时序图： 时序图又称顺序图，表达的是基于时间的动态交互。重点是完成某个行为的对象类和这些对象类之间所传递的消息的时间顺序
**协作图：**又称为通信图，通过对象之间的连接和它们相互发送的消息来显示参与交互的对象；
顺序图和协作图都是表现对象之间的交互和协作的，顺序图侧重在交互的时间顺序上，协作图着重在交互对象的空间链接上

需求分析

需求内容来源：
干系人： 任何与系统有关的人（资方，客户，系统用用户，领域专家，项目研发团队）
业务过程
组织规章制度：组织规范，协议，技术标准
现有系统的：用户手册，数据样本，界面描述，报告样本，屏幕截图

需求的不同层次：
业务需求
用户需求：描述了用户通过该软件产品必须要完成的任务
系统需求
功能需求（也包括非功能需求）：定义了开发人员必须实现的软件功能

需求工程：
包含了需求开发和需求管理

需求的易变性 唯一不变的就是变化

需求变更是指增加或改进软件的功能

需求编程控制的原则是拒绝不切实际的变更，减少变更带来的风险，防止变更范围扩大，蔓延，杜绝随意的变更申请及受理过程

参与者（actor）又叫执行者，是在系统之外，透过系统边界与系统进行有意义交互的任何事物， 参与者可以是人，另外一个系统，硬件设备，其他用例等系统外部的实体。参与者是用来执行用例的
用例（user case）是系统所提供的一个功能（或某一特定用法）的描述，是执行者和系统交互的一个完整过程。一个用例是用户和计算机之间的一次典型交互，在UML中用例被定义成系统执行的一个功能单元，每个用例都必须有一个唯一的名字
参与者和用例分别描述了“谁来做？”和“做什么？”这两个问题

识别参与者的方法：

• 谁使用系统的主要功能？
• 谁改变系统的数据？
• 谁从系统获取信息？
• 谁需要系统的支持以完成日常工作？
• 谁负责日常维护、管理并保证系统正常运行？
• 系统需要应付（处理）哪些硬件设备？
• 系统需要和哪些外部系统交互？
• 谁（或什么）对系统运行产生的结果（值）感兴趣？
• 有哪些时间，气温等内部或外部条件？
  

识别用例的方法（难点）

• 每个参与者的目标是什么？为什么参与者要使用这个系统？
• 参与者希望系统提供什么功能？
• 系统是否存储和检索信息，如读取，创建，删除，修改，存储等；如果是，这个行为由哪个参与者触发
• 当系统改变状态时，是否通知参与者
• 是否存在影响系统的外部事件，是哪个参与者通知系统这些外部事件？
• 系统需要哪些输入输出？谁从系统获取信息？
• 参与者是否需要知道系统内部发生的事件或改变？
• 系统是否能够应对业务中所有的正确行为与操作

识别用例时一般是抽取业务调研报告中的动词或者动词词组
**用例的命名：**采用主动语态
将操作者和其用例连在一起读，看是否构成一个完整的场景或句子；比如：游客浏览图书，游客注册登陆，而 游客图书 就不是一个完整场景或句子
用例必须是由某一个参与者触发而产生的活动，如果存在跟参与者不进行交互的用例，则可以考虑并入其他用例，或者检查是否缺少参与者。反之，每个参与者也必须至少涉及一个用例

用例图中的关系

包含关系： 如果系统用例较多，不同用例之间存在共同行为，可以将这些共同行为提取出来，单独组成一个用例。当其他用例使用这个用例之时，他们就构成了包含关系(表示一个用例作为另一个用例的必需部分被使用，是依赖关系的一种，被包含的叫包含用例，它是基础用例中一个不得不执行的用例部分）
**扩展关系：**在用例的执行过程中，可能出现一些异常行为，也可能会在不同的分支中选择执行，这时可将异常行为与可选分支抽象成一个单独的扩展用例，这样扩展用例与主用例之间就构成了扩展关系。一个用例常常有多个扩展用例
**泛化关系：**用例之间的泛化关系描述用例的一般与特殊关系，不同的子用例代表了父用例的不同实现

参与者和用例间的关系：
关联关系
参与者之间的关系：
泛化关系
用例之间的关系：
包含关系（include）
扩展关系（Extend）
泛化关系

用例描述（用例规约）

用例描述一般包括以下内容：

1. 简要描述（说明）
2. 前置（前提）条件
3. 基本事件流，其他事件流
4. 后置（事后）条件等
   

建立USE CASE模型的步骤

1. 找出系统外部的参与者和外部系统，确定系统的边界和范围；
2. 确定每一个参与者所期望的系统行为；
3. 把这些系统行为命名为Use Case；
4. 使用泛化，包含，扩展等关系处理系统公共行为的公共或变更部分；
5. 编制每一个Use Case的脚本；
6. 绘制Use Case图；
7. 区分主事件流和异常情况的事件流，可以把表示异常情况的事件流作为单独的Use Case处理
8. 细化Use Case图，解决Use Case间的重复与冲突问题

活动图

活动图元素包括：
初始节点，终点，活动节点，转换，分支，分岔与汇合
在活动图中可能包含多个活动终点

在活动图中，为了有效的表示各个活动由谁负责，可以通过泳道来实现

建立领域模型

领域模型是将用例模型向计算机表示的进一步过度

三大模型：
视图模型：表示角色与系统之间的交互
逻辑模型：表示由系统执行的任务或称业务逻辑
实体模型：表示系统存储和管理的永久信息

类中的各种关系

依赖
泛化
实现
关联

强弱顺序：
泛化 == 实现 > 组合 > 聚合 > 关联 > 依赖

依赖：
两个元素X,Y， 如果修改X会引起Y的修改，则成Y依赖于X
三种情况：
X是Y类方法中的一个参数
X是Y中的局部变量
X向Y发送消息，从而影响Y变化

泛化：
表示类与类之间的继承关系
表示：
实线 + 空心箭头 箭头指向父类
虚线 + 空心箭头 如父类是接口

实现：
大多数情况下，实现关系用来规定接口和实现接口的类或组件之间的关系

关联：
对于两个相对独立的对象，当一个对象的实例与另一个对象的一些特定实例存在固定的对应关系时，这两个对象之间为关联关系；
两种特殊的关联关系：
聚合关系：
用来描述整体和部分的关系，有着聚合关系的两个类，一个是整体，一个是部分。在聚集中，部分类可以单独存在；比如电脑和它的显示器，键盘，主板以及内存

合成（组合）关系：
也是用来描述整体和部分的关系。在合成关系中，部分类不能脱离整体类而存在。一旦整体对象不存在，部分对象也将不存在（同生共死）；比如滑翔机与机身，机尾，左右机翼

筛选对象的原则：

1. 关键性：不可缺少，缺少无法运作
2. 可操作性：对象必须拥有一组可标识的操作，可以修改对象属性的值
3. 信息含量：只有一个属性的对象需要合并或取消
4. 公共属性和操作
5. 关键外部信息

非功能性需求

可靠性 可用性 有效性 可移植性

软件设计

OOD（面向对象设计）是对OOA的细化，两者之间不存在空间映射，过渡具有平滑性；
OOD主要解决与实现有关的问题，它是针对具体的软，硬件构成环境对OOA模型的细化，OOD模型是与实现有关；
OOA是针对问题域的一个分类活动，OOA模型独立于具体的实现

问题域是指领域内在问题之间的逻辑关系

优秀设计就是使得系统在整个生命周期中的总开销最小的设计，其主要特点就是：容易维护

软件体系结构

软件体系结构包括构成系统的设计元素的描述，设计元素之间的交互，设计元素的组合模式以及在这些模式中的约束

软件体系结构 = 构件 + 连接件 + 约束
构件是具有某种功能的可复用的软件结构单元，表示系统中主要的计算元素和数据存储
连接是构件间建立和维护行为关联与信息传递的途径。连接件表示构件之间的交互并实现构件之间的连接

**体系结构风格：**用于描述某一特定应用领域中系统组织的惯用模式，反映了领域中众多系统所共有的结构和语义特性
**设计模式：**描述了软件系统设计过程中常见问题的一些解决方案，通常是从大量的成功实践中总结出来的且被广泛公认的实践和知识
**软件框架：**软件框架是由开发人员定制的应用系统的骨架，是整个或部分系统的可重用设计，由一组抽象构建和构件实例间的交互方式组成

框架和体系结构的关系：
体系结构的呈现形式是一个设计规约，而框架则是“半成品”的软件
体系结构的目的是指导软件系统的开发，而框架的目的是设计复用
框架和设计模式的关系：
框架给出的是整个应用的体系结构；而设计模式则给出了单一设计问题的解决方案，且可以在不同的应用程序或者框架中进行应用
设计模式的目标是改善代码结构，提高程序的结构质量；框架强调的是设计的重用性和系统的可扩展性，以缩短开发周期，提高开发质量

软件设计原则：

抽象
封装
模块化
复用
层次化

软件设计原理

模块化：
模块是相对独立的程序体，是数据说明，可执行语句等程序对象的集合
模块化就是把程序划分成若干个模块，每个模块独立的完成一个子功能，把这些模块集中起来组成一个整体，就可以完成指定的功能，满足问题的需求
模块之间既相互独立，又相互关联
优点：
可以使软件结构清晰
可以使软件容易测试和调试，因而有助于提高软件的可靠性
可以提高软件产品的复用率
可以提高软件对的可修改性
有助于软件开发工程的组织管理
抽象：
面向对象方法支持过程和数据抽象
过程抽象：把用文字形成的功能描述演变成代码
数据抽象：文字表达的数据结构演变成数据库表和存储过程。数据抽象与过程抽象一样，能使设计者按不同的详细程度表示数据对象
信息隐蔽和局部化：
信息隐藏是实现抽象，模块化机制的基本支撑
模块独立：
模块完成独立的功能
符合信息隐藏和信息局部化原则
模块间关联和依赖程度尽量小
模块独立的概念是模块化，抽象，信息隐蔽和局部化概念的直接结果
模块的独立程度可以由两个定性标准度量，分别是耦合度和内聚度

耦合和内聚

内聚度：一个模块内部各个元素间（语句和程序段）彼此的紧密程度
耦合度：指软件结构中各模块之间相互联系紧密程度的度量

软件独立性和衡量标准：
**高内聚：**内部结构紧密
**低耦合：**模块间关联和依赖程度尽可能的小，与其他模块的接口简单

降低耦合度：
两个对象应该通过类的接口实现耦合，而不应该依赖于类的具体实现细节（例如友元）
采用简单的数据传输方式，减少消息中包含的参数个数，降低参数的复杂程度（尽量使用基本类型作为接口的参数类型），减少消息数

内聚：一个模块内各个元素彼此结合的紧密程度
模块内的高内聚往往意味着模块间的松耦合
紧密的继承耦合与高度的一般-特殊内聚是一致的

时间内聚也属于低内聚度的类型
过程内聚和通信内聚都属于中内聚度模块
顺序内聚属于高内聚度模块
顺序内聚与过程内聚的区别：
过程内聚强调加工处理的次序，成分之间不一定有数据传递
顺序内聚强调数据的顺序，成分之间一定有数据的传递，并且按顺序执行

开闭原则是所有面向对象原则的核心
一个软件实体应当对扩展开放，对修改关闭

顺序图

交互图是用来描述对象之间，对象与参与者之间的动态协作关系，以及协作过程中行为次序的图形
交互图的类型：
顺序图又称时序图
协作图

活动图： 从用户的角度描述用例
顺序图： 从计算机的角度描述用例（对象间的交互）
类图描述系统的静态结构
顺序图描述系统的动态行为

顺序图的作用：
用对象间的交互来描述用例
寻找类的操作
顺序图中，消息的阅读顺序时严格自上而下的

顺序图的四大元素：
对象
生命线：
表示对象的生存时间。生命线从对象创建开始到对象销毁终止
激活： 当一个对象没有被激活期时，该对象处于休眠状态，什么事都不做，但它依然存在，等待新的消息来激活它；当一条消息被传递给对象的时候，它会触发该对象的某个行为，这就是说该对象被激活了
消息： 当一个对象处于激活期时，表明该对象正在执行某个动作

用例图和领域类图示时序图绘制的前提，是绘制时序图的基础

协作图强调交互中实例间的结构关系以及所传送的消息

协作图有别与时序图的两点特性：
协作图有路径
协作图有顺序号

状态图和活动图的区别：
状态图：用来描述对象，子系统，系统的生命周期。通过状态图可以了解一个对象所能达到的所有状态，以及对象收到的事件对对象状态的影响。清晰的描述了状态转换所必需的触发事件，监护条件和动作等影响因素，有利于程序员分析程序中非法事件的进入
活动图：显示动作及其结果。着重描述操作（方法）实现中所完成的工作以及用例实例或对象中的活动，它是状态图的一个变种
活动图主要描述动作及对象状态改变的结果。状态图主要描述的是事件对对象状态的影响

人机界面设计

很好的表示可视信息是设计友好界面的关键

注释分为序言性注释和功能性注释

测试确定不是一种发技术，而是一分析技术

代码审查：
自我复打码
同伴 复审
团对复审

软件测试

软件测试只能找出程序中的错误，但不能证明程序中没有错误

测试的不彻底性：
测试只能说明错误的存在，不能说明错误不存在
经过测试后的软件不能保证没有缺陷和错误
测试的不完备性：
测试无法覆盖到每个应该测试的内容
不可能测试到软件的全部输入与响应
不可能测试到全部的程序分支的执行路径
测试作用的间接性：
测试不能直接提高软件质量，软件质量的提高要依靠开发
测试通过早期发现缺陷并督促修正缺陷来间接地提高软件质量

软件测试贯穿软件开发的整个周期

测试是为了证明程序有错，而不是为了证明程序无错

测试包含了“分析”或“运行”软件
分析软件产品的过程称为静态测试，运行软件的测试过程称为动态测试

软件测试有两个基本功能：验证和确认
验证保证产品的正确性，确认保证生产了正确的产品

重要意义：
产品质量的保证
控制成本的关键
软件可靠性确认
让企业具备国际竞争的实力

测试原则：
所有的软件测试都应追溯到用户需求
应当把尽早的和不断的进行软件测试作为软件测试人的座右铭
完全测试是不可能的，测试需要终止
测试无法显示系统所有潜在的缺陷
充分注意测试中的群集现象
程序员应避免检查自己的程序
设计测试用例时，应包括合理的输入条件和不合理的输入条件
尽量避免测试的随意性，应从工程的角度理解软件测试，它是有组织，有计划，有步骤的活动
妥善保存测试计划，测试用例，出错统计和最终分析报告，为维护提供方便，因为改正错误或维护后要做回归测试

静态测试：
人工测试方法
计算机辅助静态分析方法
动态测试：
白盒测试方法
对程序模块的所有独立执行路径至少测试一次
对所有的逻辑判断，取’真‘与取’假‘的两种情况都能至少测试一次
在循环的边界和运行边界限内执行循环体
测试内部数据结构的有效性
五种标准（强弱能力，从低到高）
语句覆盖： 每条语句至少执行一次
判定覆盖：每一判定的每个分支至少执行一次
条件覆盖：每一判定中的每个条件，分别按’真‘，’假‘至少各执行一次
判定/条件覆盖：同时满足条件覆盖和判定覆盖的要求
条件组合覆盖（强）求出判定中所有条件的各种可能组合值，每一可能的条件组合至少执行一次
黑盒测试方法
主要关注软件的功能测试和性能测试，而不是内部逻辑结构的测试。已知产品的功能规格设计，可以进行测试证明每个实现了的功能是否符合要求
功能不正确或遗漏
界面错误
数据库访问错误
性能错误
初始化和终止错误
等价类划分法：
把所有可能的输入数据（有效的和无效的）划分成若干个等价的子集（称为等价类），使得每个子集中的一个典型值在测试中的作用与这一子集中所有其它值的作用相同
同一输入域的等价类划分可能不唯一
只需从每一个等价类中选取一个输入作为测试用例
回归测试是指重新执行已经做过的测试的某个子集，以保证修改变化没有带来非预期的副作用

面向对象测试（OOT）
类内测试（相当于单元测试）
类间测试（相当于集成测试）
基于场景的测试（相当于确认测试和系统测试）
白盒测试和黑盒测试方法也适用于面向对象

总：
软件测试包含静态测试和动态测试，测试步骤至少分为：
单元测试 单元
子系统测试 局部
系统测试 集成
验收测试 用户参与

系统维护

软件维护：
为了修改软件缺陷或者增加新功能而对软件进行修改；而修改通常发生在局部，一般不会改变整个结构。
改正性维护 为了识别和纠正软件错误，改正软件性能上的缺陷，排除实施中的误使用，所进行的诊断和改正错误的过程就叫改正性维护
适应性维护 为使软件适应这种外部环境或者数据环境的变化，而去修改软件的过程就叫做适应性维护
扩充与完善性维护 为了满足用户对软件提出的新的功能与性能要求而进行的维护活动叫做扩充与完善性维护
预防性维护 预防性维护是为了提高软件的可维护性，可靠性等
文档是影响软件可维护性的决定元素。往往文档比程序代码更重要
可分为用户文档和系统文档两类

提高可维护性的方法
建立明确的软件质量目标和优先级
使用提高软件质量的技术和工具
进行明确的质量保证审查
选择可维护的程序设计语言
改进程序的文档

软件预防性维护 又称 软件再工程
软件再工程：
为了避免软件本身退化而对软件的一部分进行重新设计和构造，以便提高软件的可维护性和可靠性；成本低：比重新开发软件的成本低的多
包括：
1. 库存目录分析
2. 文档重构
3. 逆向工程
4. 代码重构
5. 数据重构
6. 正向工程
重构就是在不改变软件现有功能的基础上，通过调整程序代码改善软件的质量，性能，使其程序的设计模式和架构更趋合理，提高软件的扩展性和维护性