软件=程序+文档+数据
软件危机：计算机软件的开发和维护过程所遇到的一系列严重问题
为什么会产生软件危机：
（1）. 软件维护费用急剧上升，直接威胁计算机应用的扩大
（2）. 软件生产技术进步缓慢
软件工程：把软件当作一种工业产品，要求 “采用工程化的原理与方法对软件进行计划、开发和维护 ”
软件工程环境：方法与工具相结合，再加上配套的软、硬件支持就形成软件工程环境。
（1）、过程式编程范型
遵循“程序=数据结构+算法”的思路，认为程序由一组被动的 数据和一组能动的过程所构成。
（2）、面向对象编程范型
数据及其操作被封装在对象中，程序=对象+消息，着眼于程序中的对象，粒度比较大
（3）、基于构件编程范型
构件是通用的、可复用的标准化对象类，程序=构件+架构，着眼于适合整个领域的类对象，粒度更大
软件生存周期（Software Life Cycle）：一个软件项目从问题提出开始，直到软件产品最终退役（废弃不用）为止。应该可以说是最早的软件工程概念。
（1）需求分析
（2）软件分析
（3）软件设计
（4）编码
（5）软件测试
（6）运行维护
瀑布模型：
特点：
阶段的顺序性和依赖性
推迟实现的观点（编码开始早，开发时间长）
质量保证的观点（文档，审查）
存在问题：
不适合需求模糊的系统
开发初始阶段很难彻底弄清软件需求
阶段：
快速原型模型：
特点：
“逼真”的原型可以使用户迅速作出反馈
循环回溯和迭代：非线性模型
使用快速开发工具
硬件相比原型的不同之处及相应措施
单件产品
增量模型：
增量：
小而可用的软件
第一个增量通常是软件的核心
特点：
在前面增量的基础上开发后面的增量
每个增量的开发可用瀑布或快速原型模型
每个增量开发的顺序性和总体的迭代性相结合
任务：建立分析模型 (analysis model)：功能模型（DFD）、数据模型（DD）、行为模型（STD）
作用：指明数据在系统中是如何移动和变换，描述使数据流进行变换的功能和子功能。
概述：
面向数据流设计和面向数据设计
面向数据流：数据流是考虑一切问题的出发点
面向数据：以数据结构作为分析与设计的基础
从分析模型导出设计模型
结构化设计的描述工具：SC图
SC图：
程序流程图：
扇入和扇出：
瓮形结构：
面向对象的基本特征：抽象、封装、继承、多态
面向对象开发的优点：
*提高软件系统的可复用性
*提高软件系统的可扩展性
*提高软件系统的可维护性
UML：UML提供丰富的以图形符号表示的模型元素，这些标准的图形符号隐含了UML的语法，而由这些图形符号组成的各种模型则给出UML的语义。
UML的模型元素：
静态图：用例图、类图、对象图、构件图和部署图
动态图：状态图、时序图、协作图和活动图
包：
在OO设计中，可将许多类集合成一个更高层次的单位。形成一个高内聚、低耦合的类的集合。
包的内容：可以是类的列表,也可以是另一个包图,还可以是一个类图。
和类一样包中的元素也有可见性，利用可见性控制外部包对包的内容的存取方式，UML中常用的两种 可见性：私有(private)，公有(public)。
包可以有接口，接口与包之间用实线相连，接口通常由包的一个或多个类实现。
用例之间的关系：
状态图描述一个特定对象的所有可能的状态以及引起状态转换的事件。使用用状态图表示单个对象在其生命期中的行为。一个状态图包括一系列状态和状态之间的转移（事件）。
时序图通过描述对象之间发送消息的时间顺序显示多个对象之间的动态协作。着重表现对象间消息传递的时间顺序。
时序图有两个坐标轴：纵坐标轴表示时间，横坐标轴表示不同的对象。
时序图中包括如下元素：参与者，对象，生命线，激活期和消息
1、参与者：系统发生交互的外部实体。可以是人或者其他系统。
2，对象。对象位于时序图顶部。对象一般包含三种命名方式：
包含包含对象名和类名；
只显示类名不显示对象名，即为一个匿名对象；
只显示对象名不显示类名。
3，生命线(Lifeline) ：代表时序图中的对象在一段时期内的存在。时序图中每个对象下方有一条垂直的虚线，这就是对象的生命线，对象间的消息存在于两条虚线间。
4，激活期(Activation)：激活期代表时序图中的对象执行一项操作的时期，在时序图中每条生命线上的窄的矩形代表活动期。
5、消息：用对象生命线之间的水平消息线来表示，消息箭头的形状表明消息的类型(同步、异步或简单)。
消息通常用消息名和参数表来标识。
消息还可以带有条件表达式，用以表示决定是否发送消息。如果用条件表达式表示分支，则会有若干个互斥的箭头，也就是说，在某一时刻仅可发送分支中的一个消息。
协作图用于描述相互协作的对象间的交互关系和链接关系。虽然时序图和协作图都描述对象间的交互关系，但它们的侧重点不同：时序图着重表现交互的时间顺序，协作图则着重表现交互对象的上下文相关。
活动图(Activity Diagram)的应用非常广泛,它既可用来描述操作(类的方法)的行为,也可以描述用例的工作流程,还可用于表示并行过程。
活动图是由状态图变化而来的,它们各自用于不同的目的。活动图描述了系统中各种活动的执行的顺序。刻化一个方法中所要进行的各项活动的执行流程。
活动图中一个活动结束后将立即进入下一个活动(在状态图中状态的变迁可能需要事件的触发)。
业务需求
业务需求（business requirement）反映了组织机构或客户对系统、产品高层次的目标要求，通常在项目定义与范围文档中予以说明 。
业务需求的确定对之后的用户需求和功能需求起了限定作用，业务需求就是需求过程的宪法，任何需求不得与之相违背。
用户需求
用户需求(user requirement) 从用户使用角度来描述软件产品必须完成的任务。通常在用例模型中描述，同时引出软件的质量属性。
用户需求的重心是如何收集用户的需求，即确定软件系统的功能以及软件与环境的交互。
功能需求
功能需求(functional requirement)定义了开发人员必须实现的软件功能，以及为了有效实现这些功能而必须达到的非功能要求、约束条件等，使得用户能完成他们的任务，从而满足了业务需求。
功能需求依赖于用户需求，是用户需求在系统上的一个映射（Mapping）。
开发者思考的角度从用户转移到开发者。
可通过原型法与用户共同需求。
是否有必要采用快速原型开发法和原型应开发到何种地步取决于具体的项目，可用一些简单的方法来生成原型
（1）.画用例图
a.确定参与者
b.确定用例
c.绘制和检查用例图
（2）.写用例规约
内容：
简要说明（brief description):简要介绍该用例的作用和目的。
事件流 (Flow of Event)：包括基本流和备选流，事件流应该表示出所有的场景；
特殊需求 (Special Requirement)：描述与该用例相关的非功能性需求（包括性能、可靠性、可用性和可扩展性等）和设计约束（所使用的操作系统、开发工具等）；
前置条件 (Pre-Condition)：执行用例之前系统必须所处的状态；
后置条件 (Post-Condition)：用例执行完毕后系统可能处于的一组状态。
（3）.描述补充规约
（4）.编写术语表
（5）调整用例模型
用例规约
补充规约
术语表
识别与确定分析类
为用例规约补充必要的详细信息，因为用例规约仅从用户角度对每个用例进行说明。而现在需要的是从内部角度观察系统响应的说明
（1）分析类的类型
边界类：提供了对参与者或外部系统交互协议的接口,它将系统和外界的变化隔离。
控制类：用于封装一个或几个用例所特有的流程控制行为，通过它可建立系统的动态行为模型。有效地分离了边界类对象与实体类对象。
实体类：用于对必须存储的信息和相关行为建模的类。用于保存和管理系统中的有关信息。通常都是永久性的，它们所具有的属性和关系是长期需要的，有时甚至在系统的整个生存期都需要。
（2）查找分析类
建立对象–行为模型
根据用例规约中的事件流，绘制用例动态图
a、时序图或者协作图
b、状态图
建立对象—关系模型
分析类的属性:
*分析类本身具有的信息
*属性名称是一个名词,属性类型是简单的数据类型,
*属性设置是粗略的
分析类的关联:
*通过关联可以找到其他分析类
*协作图中,链与关联的对应关系
分析类图:
*表现分析类及其关系
*参与类图VOPC( view of participating classes)
分析类的合并:
每个分析类都代表一个明确定义的概念，具有不相重叠的职责
模块独立性：把软件划分为模块时要遵守的准则，也是判断模块构造是否合理的标准。独立性可以从2个方面来衡量，即模块本身的内聚和模块之间的耦合。
内聚：从功能的角度对模块内部聚合能力的量度。
耦合：对软件内部块间联系的度量
模式：解决某一类问题的方法论，也是通过问题的通用解决方案。其目的是把解决某类问题的方法总结、归纳到理论高度，供其他人员在解决类似问题时参考或直接套用。
软件模式：架构模式、设计模式、习惯用法
系统架构设计：指系统主要组成元素的组织或结构，以及其他全局性决策，组成元素之间通过接口进行交互。
系统架构设计包含六方面的内容:
①系统高层结构设计
套用软件架构模式来设计高层组织结构
②确定设计元素
识别和确定设计类和子系统，将设计类组织到相应的包中，为子系统设计接口，确定复用机会。
③确定任务管理策略
多任务、并发执行等可能引起的冲突或运行性能等
④实现分布式机制
选择支持远程通信的构件，给出实现构件通信的统一方案
⑤设计数据存储方案
选择数据库访问的支持构件，设计类/对象数据的存储、读取、删除或修改等操作的方法
⑥人机界面设计
确定统一要求和规范，确定实现的技术基础和工具
系统元素设计：
包括类、子系统与接口、包等。系统元素设计包括三方面的内容:
①类/对象设计
在分析类的基础上对每个设计类的属性及其类型、操作及其算法、接收及发送的消息等进行详细设计。
②子系统设计
设计与确定每个子系统内部组织、子系统对应接口、子系统之间的关联等。
③包设计
将逻辑上相关的设计元素组织在一起。
类/对象是设计工作的核心，主要考虑三个问题。
1)如何实现分析模型中的边界类、控制类与实体类
2)在解决类设计中的实现问题时如何应用设计模式
3)系统架构中的全局性决定如何在类设计中体现
类设计的步骤：
（1）设计初始类（边界类、实体类、控制类）
（2）定义操作
（3）定义方法
（4）定义状态
（5）定义属性
（6）定义依赖关系
（7）定义关联关系
（8）定义泛化关系
（9）处理非功能需求
（1）在清晰的前提下追求效率
（2）使用标准的控制结构
选择结构(IF THEN；IF THEN ELSE；CASE OF)；
循环结构(FOR DO；WHILE DO；REPEAT UNTIL)；
采用单入口/单出口，确保源程序清晰可读。
（3）源程序的文档化
软件=程序+文档
有意义的变量名称
适当的注释
标准的书写格式
用分层缩进的写法显示嵌套结构的层次；
在注释段的周围加上边框；
在注释段与程序段、以及不同程序段之间插入空行；
每行只写一条语句；
书写表达式时，适当使用空格或圆括号等作隔离符
（4）满足用户友好的输入输出风格
对所有输入数据要进行校检,防止对程序的有意或无意的破坏；
检查输入项重要组合的合法性，剔除模糊的输入值；
输入格式力求简单、一致，并尽可能采用自由格式输入；
向用户提供“请输入”的提示信息及允许的选择范围和边界值；
所有输出的报表、报告要具有良好的格式；
标志所有的输出数据，加以必要的说明；
对于人-机交互的系统，能为用户提供“在线”帮助；对会产生 重要后果的 请求，能给出醒目的提示；当操作发生错误时能迅速恢复正常。
概念：通过对被测程序的静态审查，发现代码中潜在的错误。
（1）自动方式
静态分析器分析
（2）人工方式
代码评审（代码会审、走查、办公桌检查）
（1）概念
把测试对象看做一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明。
黑盒测试又叫做功能测试或数据驱动测试。
（2）等价分类法
把输入数据的可能值划分为若干等价类，使每类中的任何一个测试用例，都能代表同一等价类中的其他测试用例。如果从某一等价类中任意选出一个测试用例未能发现程序的错误，该类中的其他测试用例也不会发现错误。不仅考虑有效等价类，还要考虑无效等价类
（3）边界值分析法
边界值分析法，就是要选择测试用例，使得被测程序能在边界值及其附近运行，从而有效地暴露程序中潜在的错误。
（1）概念
此方法把测试对象看做一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试。通过在不同点检查程序的状态，确定实际的状态是否与预期的状态一致。因此白盒测试又称为结构测试或逻辑驱动测试。
逻辑覆盖测试:对所有的逻辑判定，取“真”与取“假”的两种情况都至少测试一次.
路径测试:对程序模块的所有独立的执行路径至少测试一次。
例题：假设现有以下的三角形分类程序。该程序的功能是，读入代表三角形边长的3个整数，判断他们能否组成三角形。如果能够，则输出三角形是等边、等腰或任意三角形的分类信息。
黑盒测试：
a.用等价类法划分有效和无效等价类
b.用边界值法和猜错法作补充
白盒测试：采用路径覆盖方法
单元测试，是针对软件设计的最小单位 ─ 程序模块，进行正确性检验的测试工作。
目的：在于发现各模块内部可能存在的各种差错。
单元测试需要从程序的内部结构出发设计测试用例。
多个模块可以平行地独立进行单元测试。
通常在单元测试的基础上，将所有模块按照设计要求组装成为系统。
在把各个模块连接起来的时侯，穿越模块接口的数据是否会丢失；
一个模块的功能是否会对另一个模块的功能产生不利的影响；
各个子功能组合起来，能否达到预期要求的父功能；
全局数据结构是否有问题；
单个模块的误差累积起来，是否会放大，从而达到不能接受的程度。
任务是验证软件的功能和性能及其它特性是否与用户的要求一致。
软件确认测试的基础是软件需求规格说明书。
系统测试，是将通过确认测试的软件，作为整个基于计算机系统的一个元素，与计算机硬件、外设、某些支持软件、数据和人员等其它系统元素结合在一起，在实际运行环境下，对计算机系统进行一系列的组装测试和确认测试。
系统测试的目的在于确认软件能否与系统的其它部分协调运行，并且实现SRS的要求。
α测试是在受控的环境下，由用户在开发者的指导下进行的测试，由开发者负责记录错误和使用中发现的问题。
β测试是由软件的用户在实际使用环境下进行的测试。开发者通常不在测试现场，无法控制应用环境。由用户负责记录错误和使用中发现的问题
软件维护是指软件系统交付使用以后，为了改正软件运行错误，或者因满足新的需求而加入新功能的修改软件的过程。
软件开发完成交付用户使用后，就进入软件的运行和维护阶段。
软件维护工作处于软件生命期的最后阶段，维护阶段是软件生存期中最长的一个阶段，所花费的人力、物力最多，其花费高达整个软件生命期花费的约60-70％。
完善性维护
扩充软件功能、增强软件性能、提高软件运行效率和可维护性而进行的维护活动
完善性维护约占50-60%
适应性维护
使软件适应外部新的硬件和软件环境或者数据环境（数据库、数据格式、数据输入/输出方式、数据存储介质）发生的变化，而进行修改软件的过程。
大约占整个维护的25%
纠错性维护
在于纠正在开发期间未能发现的遗留错误
约占总维护量的20%
预防性维护
选择那些还能使用数年、目前虽能运行但不久就须作重大修改或加强的软件，进行预先的维护
对该类维护工作的必要性有争议，所以它在整个维护活动中占较小的比例约占4%。