完整版pdf：http://www.northgis.cn/download/

目录

ref="https://http://zhuanlan.zhihu.com/write#_Toc9623119">第一部分 软件工程导论（重点）... 2

href="https://zhuanlan.zhihu.com/write#_Toc9623120">第一章 概述... 2

1.1 软件工程... 2

1.2 软件工程职业道德... 3

href="https://zhuanlan.zhihu.com/write#_Toc9623123">第二章 软件过程... 3

2.1 瀑布模型... 3

2.2 增量式开发... 4

2.3 面向复用的软件工程... 4

2.4 软件活动过程... 4

2.5 Rational 统一过程... 5

href="https://http://zhuanlan.zhihu.com/write#_Toc9623129">第三章 敏捷软件开发... 5

3.1 极限编程... 5

3.2 敏捷项目管理... 5

href="https://http://zhuanlan.zhihu.com/write#_Toc9623132">第四章 软件需求工程... 6

4.1 需求类型... 6

4.2 软件需求文档... 6

4.3 需求工程活动... 7

4.4 需求管理... 7

href="https://zhuanlan.zhihu.com/write#_Toc9623137">第五章 系统建模... 7

5.1 上下文模型... 8

5.2 交互模型... 8

5.3 结构模型... 9

5.4 行为模型... 10

5.5 模型驱动工程... 11

href="https://http://zhuanlan.zhihu.com/write#_Toc9623143">第六章 体系结构设计... 11

6.1 系统结构视图... 12

6.2 体系结构模式... 12

6.3 应用体系结构... 13

href="https://zhuanlan.zhihu.com/write#_Toc9623147">第七章 设计与实现... 13

7.1 使用UML的面向对象设计... 13

7.2 设计模式... 14

7.3 实现问题... 14

7.4 开源开发... 14

href="https://zhuanlan.zhihu.com/write#_Toc9623152">第八章 软件测试... 14

8.1 开发测试... 15

8.2 测试驱动开发... 16

8.3 发布测试... 16

8.4 用户测试... 16

href="https://zhuanlan.zhihu.com/write#_Toc9623157">第九章 软件进化... 16

9.1 进化过程... 17

9.2 程序进化动态特性... 17

9.3 软件维护... 17

9.4 遗留系统管理... 18

ref="https://zhuanlan.zhihu.com/write#_Toc9623162">其他内容... 18

1.项目管理... 18

2.项目规划... 19

3.质量管理... 19

4.配置管理... 20

第一部分 软件工程导论（重点）

第一章 概述

1.1 软件工程

l 软件：是程序和所使程序正确运行所需的相关文档和配置信息（包括定制软件产品和通用软件产品）（程序+文档）

l 程序：是按事先设计的功能和性能要求执行的指令序列（算法+数据结构）

l 数据：是使程序能正常操纵信息的数据结构

l 文档：是与程序开发、维护和使用有关的图文材料

l 软件危机：把计算机软件的开发和维护过程中出现的一系列严重的问题称为软件危机

1. 软件开发无计划

2. 软件需求不充分

3. 软件开发过程不规范

4. 软件产品无评测手段

5. 软件开发周期大大超过预算

6. 软件开发成本严重超标

7. 软件质量难于保证

l 软件工程是一门工程学科，涉及到软件生产的各个方面

1. 原则：采取适宜的开发范型，采用合适的设计方法，提供高质量的工程支持，重视软件工程的管理

2. 目标：可用性，正确性，核算性

3. 过程：基本过程，支持过程，组织过程

l 软件工程的本质特性：

1. 软件工程关注于大型程序的构造

2. 软件工程的中心课题是控制复杂性

3. 软件经常变化

4. 开发软件的效率非常重要

5. 和谐地合作是软件开发的关键

6. 软件必须有效地支持客户

7. 在软件工程领域中是由具有一种文化背景的人替具有另一种文化背景的人创造产品

l 软件工程关心的是专业软件开发的理论、方法和工具，而不是个体编程

l 软件工程之所以重要的原因：

1. 个人和社会越来越依赖于先进的软件系统

2. 运用软件工程方法开发软件系统比个人程序项目写程序更加便宜

l 影响软件的主要因素：异质性、业务和社会的变革、安全和可信

l 软件工程的多样性：1.独立的应用；2.以交易为基础的交互式应用；3.嵌入式控制系统；4.批处理系统；5.娱乐系统；6.建模和仿真系统；7.数据采集系统；8.集成系统

l 软件工程与Web：1.基于Web系统的开发；2.基于Web系统的服务（软件本身就是一种服务）；3.以网络为基础的系统设计（软件复用）

l 计算机科学研究的是构成计算机和软件系统基础的有关理论和方法，而软件工程则是研究软件制作过程中的实际问题；计算机科学理论更适用于相对较小的程序

l 系统工程研究由软件起主导作用、有关复杂系统的开发和进化的各个方面，而软件工程是系统工程中关于开发软件基础设施、控制、应用和系统数据库的部分

l 软件工程方法：是软件开发的结构化方法，包括1.模型描述；2.规则；3.建议；4.过程指南

l 软件除了为用户提供相应的功能和性能外还需要有可维护性、可依赖性、信息安全性和有效性等产品特性

1.2 软件工程职业道德

l 需要合乎道德、必须有责任心；道德行为不仅仅是遵守法律

l 职业责任问题：1.保密；2.工作能力；3.知识产权；4.计算机滥用

l 道德准则：1.公众感；2.客户和雇主；3.产品；4.判断力；5.管理；6.职业感；7.同事；8.自己

第二章 软件过程

l 软件过程：制作软件产品的一组活动及其结果，包括1.软件描述；2.软件开发 3.软件有效性验证；4.软件进化（四种活动）

l 软件过程包括基本过程、支持过程、组织过程

l 软件过程不但包括活动和活动顺序的描述，还包括产品、角色、前置和后置条件的描述

l 软件过程可区分为计划驱动过程和敏捷过程

l 基本软件过程模型（三种模型）：

1. 瀑布模型：将软件描述、开发、有效性验证、进化分为独立阶段

2. 增量式开发：软件描述、开发、有效性验证交错进行

3. 面向复用：基于已存在的可复用组件，侧重于集成组件到新系统

4. 其他模型：原型模型、喷泉模型、螺旋模型、统一过程模型、敏捷过程模型、微软工程模型

2.1 瀑布模型

l 瀑布模型阶段：

1. 需求分析和定义

2. 系统与软件设计

3. 实现与单元测试

4. 集成与系统测试

5. 运行与维护

l 瀑布模型特点：1.活动间具有顺序性和依赖性；2.推迟实现的观点；3.保证质量的观点

l 瀑布模型缺点：1.难以适应过程中进行的变化；2.难以应付变化的客户需求；3.需求明确才可使用该模型；4.只适用于项目开始时需求已定情况；5.主要用于大型系统工程项目

2.2 增量式开发

l 增量式开发假设需求可以分段

l 1.探索式开发：与客户一起工作，共同探索系统需求；2.抛弃式原型：理解用户需求，再给出系统的一个较好的需求定义，构造软件原型，评估反馈，抛弃

l 优点：1.降低适应变更的成本；2.容易得到客户及时反馈；3.为及时交付有用的系统提供可能

l 缺点：1.过程不常见；2.系统结构通常较差；3.需要专业技能

l 适用于：1.对小型或中型的交互系统；2.对于大型系统的某部分；3.对生命周期短的系统

2.3 面向复用的软件工程

l 过程阶段：1.组件分析；2.需求修改；3.使用复用的系统设计；4.开发和集成

l 组建类型：1.通过标准服务开发的Web服务；2.对象的集合，作为一个包和组建框架；3.独立的软件系统

2.4 软件活动过程

l 软件描述：理解并定义系统需要哪些服务以及找出开发和运行期间受到哪些约束

1. 可行性研究

2. 需求导出和分析

3. 需求描述

4. 需求有效性验证

l 软件开发：把系统描述转化为一个可运行系统的过程，包含设计和实现

Ø 软件设计内容：1.体系结构设计；2.接口设计；3.组件设计；4.数据库设计；5.算法设计

Ø 软件设计方法：面向过程的开发、面向对象的开发、面向组件的开发、面向服务体系的开发

Ø 编程和调试：编程是个人活动，调试是把设计转换成程序并去除程序中错误的过程

l 有效性验证：检验和有效性验证是为了表明系统符合其描述，满足了客户的需求

1. 组建或单元测试

2. 系统测试：侧重于找到组件间非预期的交互行为和组件接口问题

3. 接收测试

l 软件进化：由于业务环境、客户需求的改变，软件支持的业务也必须不断更新和修改

l 应对变更：变更无法避免。两个方法可以降低返工成本：1.变更避免；2.变更容忍；两种应付变更系统需求的方法：1.系统原型；2.增量交付

2.5 Rational 统一过程

l 是新式过程模型的一个实例，是软件工程过程，是一个过程产品，是一个阶段化模型

l 三大特点：用例驱动、以架构为中心、迭代和增量开发

l 由阶段构成：开端、细化、构造和转换

l 把活动（需求、分析和设计等）与这些阶段分离

第三章 敏捷软件开发

l 关注代码而非设计、以软件开发的迭代方法为基础、迅速完成和移交可用软件

l 适合开发小型或中型业务和机构内部的定制系统

l 敏捷方法：并非一个具体过程，而是一个涵盖性术语；着眼于能够高质量地快速交付客户满意的工作软件

l 敏捷方法原则：客户参与、增量式交付、人非过程、接受变更、保持简单性

l 敏捷方法特性：

1. 描述、设计和实现过程是并发的

2. 系统通过一系列增量开发出来

3. 系统用户界面通常是采用交互开发系统开发的

l 问题：1.缺乏文档，维护困难；2.软件交付后用户持续参与困难；3.保持开发团队持续性难

l 计划驱动开发是提前计划好所有过程活动，然后按照计划去考核过程的执行；而敏捷开发是增量式的，很容易根据不断变化的客户需求变更过程 在计划驱动的方法中，迭代发生在各个活动之中，而在敏捷方法中，迭代发生在所有活动之间 计划驱动的软件可以支持增量式开发和交付

3.1 极限编程

l 原则：1.增量式开发是通过系统小的频繁开发版本来支持的；2.客户参与是通过全时雇佣到开发团队的方式；3.人通过结对编程、对系统代码的集体拥有、可持续的开发过程而无需超额的工作时间来运作；4.变更是通过经常性的系统版本、测试优先开发等支持的；5.通过持续再分解、重构来维护系统简洁性

l 在极限编程中，所有需求表示为脚本

l 适合规模小、进度紧、需求变化大、质量要求严的项目

l 极限编程是测试优先的开发

l 结对编程：所有的产品软件都是由两个程序员、并排坐在一起在 同一台机器上构建的，让两个人共同设计和开发代码

3.2 敏捷项目管理

l 项目管理的标准方法是计划驱动的，但不适合于敏捷方法，其需求开发是增量式的，短期内快速地交付增量，经常有需求和软件的变更

l Scrum方法注重迭代开发的管理：有明确的最高目标、熟悉开发流程中所具备的最佳典范与技术、具有高度自主权、紧密地沟通合作、以高度弹性解决各种挑战、确保每天每个阶段都朝着目标有明确的推进

1. 规划纲要阶段：建立大致的项目目标和设计软件体系结构

2. 冲刺循环阶段：中心阶段，一个循环就是一个计划单元，包括评估、特征选择和开发、软件实现

3. 交付使用阶段：交付给用户

l 可扩展的敏捷方法：使敏捷方法适应大型系统的开发

l 大型公司难以引进敏捷方法的原因：1.不愿接受风险；2.项目体制跟敏捷不兼容；3.开发人员技术参差不齐；4.文化抵制

第四章 软件需求工程

l 需求：被视为对系统应提供的服务或对系统约束的一个高层抽象描述，被定义为对系统功能详细的、用数学方法的形式化描述

l 需求作为双重的功能，是不可避免：

1. 可以作为合同竞标的基础：对描述是公开的

2. 可以作为合同自身的基础：对文件进行定义

3. 两种文件描述都被称为需求文档

l 需求具有全面性：用户需要的所有服务都应该给出描述；一致性：对系统功能需求进行描述时，不能前后矛盾

l 需求的不精确性来源于对需求描述的不严密

l 需求工程：对服务和约束的发现、分析、建立文档、检验的过程

1. 描述功能性和非功能性需求

2. 介绍用户需求和系统需求的概念

3. 说明如何在文档中组织需求

4.1 需求类型

l 用户需求：用自然语言加图表形式，从用户角度描述系统功能和非功能需求，给出以下声明：

1. 关于系统需要提供哪些服务

2. 系统操作受到哪些约束

l 系统需求：详细给出系统的服务和约束，应该是精确的，是对系统功能、服务和约束更加详细的描述

1. 功能需求：对系统应该提供的服务、如何对输入做出反应以及系统在特定条件下的行为描述

2. 非功能需求：对系统提供的服务或功能给出的约束（非功能需求比功能性需求更关键）（产品需求、机构需求、外部需求）

3. 领域需求（非并列）：来自系统应用领域的需求，一般包括专用性很强的领域术语

4.2 软件需求文档

l 是对系统开发者应当实现的内容的正式陈述，包括系统的用户需求和一个详细的系统需求描述，尽可能规定系统应该做什么而不是应该怎么做

l 结构：序言、引言、术语、用户需求定义、系统体系结构、系统需求描述、系统模型、系统进化、附录、索引

l 需求描述的书写方法：自然语言、结构化的自然语言、设计描述语言、图形化描述、数字描述

l 自然语言缺点：二义性、随意性太大、缺乏模块化

l 结构化语言描述：严格的格式、标准的方式、词汇限制、一致性约束

l 标准格式描述：实体或功能、输入及输入来源、输出及输出趋向、其他被引用实体、对所采取行动、条件、对操作的副作用

l 表格描述：用来补充自然语言

l 图形描述：给出状态是如何改变或者需要描述一个动作序列

4.3 需求工程活动

l 四个高层活动：

1. 系统可行性研究：评估系统是否对业务有用

2. 需求导出和分析：需求发现

3. 需求描述：将需求转变为某种标准格式描述

4. 需求有效性验证：检验需求是否正确地定义了客户希望的系统

l 可行性分析：系统是否对机构的总体目标有贡献、系统能否在时间要求内完成、系统是否能和正在使用中的其他系统集成

l 需求导出和分析：需求发现、需求分类和组织、需求优先权排序和协商、需求描述

Ø 访谈：在对信息持有者的正式和非正式访谈中，需求工程团队会向信息持有者提出一系列的问题

Ø 脚本：场景是对交互实现片段的描述

Ø 用例：是一种基于场景的需求导出技术

Ø 深入实际：是一项用来了解并帮助导出社会和机构如何影响系统运行过程支持需求的观察技术

l 需求有效性验证：需求检查（有效性检查、一致性检查、完备性检查、真实性检查、可检验性检查）、需求有效性验证技术（需求评审【可检验性、可理解性、可跟踪性、适应性】、原型建立、测试用例生成）

4.4 需求管理

l 需求管理是在需求工程过程和系统开发过程中，对系统需求变更理解和控制的过程

l 需求变更

1. 系统业务和技术环境在安装之后总是发生变化

2. 系统购买者和系统最终用户很少是同一人

3. 不同用户群有不通过的需求和优先次序

l 持久的需求：相对稳定的需求；易变的需求：很不稳定的需求

l 规划管理：1.需求识别；2.变更管理过程；3.可追溯策略【源可追溯性、需求可追溯性、设计可追溯性】；4.工具支持【需求存储、变更管理、可追溯管理】

l 变更管理：应该处理全部的需求变更

1. 问题分析和变更描述

2. 变更分析和成本计算

3. 变更实现

第五章 系统建模

l UML已经成为面向对象建模的标准建模语言

1. 活动图：表示一个过程或数据处理中所涉及的活动

2. 用例图：表示一个系统和它所处环境之间的交互

3. 时序图：表示参与者和系统之间、系统各部分之间的交互

4. 类图：表示系统中的对象类以及这些类之间的联系

5. 状态图：标识系统是如何响应内部和外部事件的

l 系统建模有助于分析增进对系统功能的理解

l 系统建模就是建立系统抽象模型的过程（外部、交互、结构、行为）

5.1 上下文模型

l 通常表示某一环境几个其他的自动系统，却没有描述其他自系统之间的、以及待描述系统与它们之间的关联关系类型

l 上下文模型的意图在于说清“系统的环境是什么”， 说不清的（不确定的）就通过讨论来逐渐明确

l 所谓“系统的环境是什么”——即从系统外部对系统 的输入开始，直到系统处理之后对系统外部的响应， 此过程的结构化描述

l 具体的建模方法：

1. 对系统命名，表示出确定的系统边界

2. 标识系统外部的所有参与要素

3. 说明外部要素与系统之间的关系

5.2 交互模型

l 所有系统都会涉及到交互，交互模型是为了更好地识别用户的需求

l 用例图用于定义系统的功能需求，描述系统的参与者和系统提供的用例之间的关系

l 时序图用来为系统各部分之间的交互建模

l 参与者是系统外部的一个实体，它以某种方式参与用例的执行过程

l 用例是一组连续操作，当用户使用系统来完成某个过程时出现，是外部可见的系统功能单元。通过将这些不同功能单元的组合，构成对系统总体需求的描述

1. 位于系统：必须由系统运行

2. 目标导向：用例运行必须有所目的

3. 止于边界：可观测到结果，且在边界和外部有所交互

4. 用户观点：参与者观测

5. 粒度：由共同目标或可以类聚的目标实例构成

l 用例的目标是定义一个或整个系统的行为，侧重目的，轻过程

l 用例与参与者之间的连线称为关系，关系也称为关联 或通信关联，它表示参与者与用例之间的通信；一般情况下，不用带箭头的直线表示信息流动方向，因为信息流动是双向的；如果使用箭头，则特意表示信息的发起者或接受者

l 用例建模：主要用来为系统与外部参与者之间的交互建模，每一个用例表示一个具体任务

l 时序图：用来为系统各部分之间的交互建模，包括一些外部因素，表示在特定用例中的交互顺序

5.3 结构模型

l 表示系统的构成，表示为组件构成系统以及组件之间的关系

l 类图：表示系统中的类和这些类之间的关联

l 泛化：对类的所有成员给出一般性描述

l 聚合：显示对象类是如何由其他对象组合而成，类似于部分-整体关系

5.4 行为模型

l 用来描述系统的所有行为，表示当系统响应来自所处环境的刺激时所发生和有可能发生的事情

l 两类行为模型：数据流模型，用来描述系统中的数据处理过程；状态机模型：用来描述系统如何对事件做出响应

l 数据流图用来表示建模系统的处理方式，数据流模型描述数据是怎样在处理序列中流动

1. 数据流模型是从功能角度来看待系统而得到的模型表示

2. 价值体现在它对系统中数据和数据在特定过程中流动的跟踪和记录

3. 用来显示一个系统在它的环境中，与其他系统进行的数据交换

l 数据流模型作用：

1. 数据流模型是从功能角度分析而得到的系统模型，为系统的软件需求提供一个基本框架

2. 数据流模型中的数据处理部分，既是软件功能的划分，也是对系统结构的一个假定——用函数来执行函数的变换

3. 数据流模型描述了系统中“端到端”的数据处理过程，能够支持或证明上下文模型的分析观点——从对输入的处理到系统的响应

l 圆角矩形：表示数据处理的功能模块；直角矩形：表示功能模块的处理结果；带标记箭头：表示处理过程中数据的流动

l 状态机模型是一种描述系统对内部或外部事件响应的行为模型

l 适合用来描述实时系统，因为这类系统多由外界环境刺激而驱动

l 状态机模型用节点表示系统状态，用节点之间的弧来表示事件

l 状态图：它允许将一个模型分解成多个子模型

l 为了描述系统内部或外部事件的发生/响应行为，需要使用状态机模型

1. 描述系统状态和事件

2. 描述事件引发的系统状态及状态间的转换

3. 但不描述系统中数据的流动

l 圆角矩形：代表系统状态；带标识箭头：表示状态转换；实心圆：状态始末

l 状态机模型的作用：需求分析与获取；软件测试

5.5 模型驱动工程

l 模型驱动工程是软件开发的一种方法，模型是主要输出，程序由模型自动生成

l 模型驱动工程起源于模型驱动体系结构

1. 计算独立模型：为系统中使用的重要领域抽象建模

2. 平台独立模型：在没有它的实现作为参考的条件下，为系统的运行建模

3. 平台特定模型：由平台独立模型转化得到

l 基本概念：模型向代码的完全自动化转化是可行的

l UML可执行的子集模型：领域模型；类模型；状态模型

第六章 体系结构设计

l 软件体系结构是有关软件系统如何组织的描述。体系结构为软件系统提供了一个结构、行为和属性的高级抽象，由组件及其相互作用、指导组件集成的模式及其约束组成

l 体系结构模型能够用来聚焦关于软件需求和设计的讨论，并且可以用来文档化设计过程

l 初始设计过程的任务是要识别出组成大型系统的多个子系统，并建立起子系统控制与通信框架，这个过程叫做体系结构设计。体系结构设计输出的一个描述就是软件体系结构

1. 体系结构设计是设计过程的初始阶段

2. 表现为设计和需求工程过程之间的桥梁

3. 通常与一些系统描述活动同时进行

4. 包括识别出系统的主要组件以及它们之间的通信

l 系统体系结构常用方块图建模。方块代表组件，方块中的方块代表子组件，箭头表示有数据和控制信号从一个组件流动到另一个组件。缺点：没有给出系统之间的关系类型，也没有显示出组件可见的外部特性

l 清晰结构的三个好处：1.信息持有者之间的沟通；2.系统分析；3.大规模复用

l 体系结构设计取决于开发系统的类型，但都有一些共同决策阶段

l 体系结构风格和结构依赖于非功能性系统需求：1.性能；2.信息安全性；3.安全性；4.可用性；5.可维护性

l 体系结构之间的冲突：

1. 使用大粒度组件虽然改进了系统的性能，但是降低了可维护性

2. 引入冗余性数据提高系统可用性，但使得系统信息安全性降低

3. 定位与安全相关的操作意味着增加了子系统之间的通信，但降低了系统性能

6.1 系统结构视图

l 概念视图：系统的高层抽象视图，给出系统本质内容

l 逻辑视图：显示系统中对象、对象类的抽象，通过该视图可将系统需求和实体关联

l 进程视图：显示系统运行时一组交互的进程，对于分析系统非功能特性很有效

l 开发视图：显示软件如何为了开发被分解，即将系统分解成组件

l 物理视图：即部署图，显示了系统硬件软件组件如何分布在处理器上

6.2 体系结构模式

l 体系结构风格是构造的一种模式，是描述某一特定应用域中系统组织方式的惯用模式，是对好的实践经验所做出的格式化抽象描述

l 体系结构模式就是模式思想：作为一种表示、共享和复用软件系统知识的方法

l MVC模式是构建基于web应用系统体系结构的基础。模型管理系统数据及其操作；视图管理显示数据；控制器管理用户交互

l 研究体系结构风格的意义：

1. 有利于发现不同系统在较高级别上的共同特性

2. 对体系结构的了解，使得在设计软件结构时选择合适的模式

3. 使用常用的、规范的模式来组织结构，使别的设计者易于理解，便于交流

4. 有利于较高级别上的软件复用

l 分层体系结构：用来把系统组织成一系列层次，支持增量式开发；当一层接口改变，只有毗邻层受到影响。该模式是实现分离性和独立性的另一个方式

4. 优点：1.支持基于抽象程度递增的系统设计；2.具有较好的可扩展性；3.支持软件复用

5. 缺点：并不是所有系统都会清晰分层，高层可能直接同底层交互，从而影响性能

l 容器体系结构：一个基于共享数据库的系统模型。是由一个子系统产生而由其他子系统使用的情形

6. 优点：1.是共享大量数据的一个高效方法；2.共享模型能通过容器模式看见；3.组件是独立的

7. 缺点：1.子系统一定要与容器数据模型一致；2.容器模型迫使所有子系统使用相同策略；3.很难将容器有效分配到多台机器上

l 客户机-服务器体系结构：是分布式系统运行时的组织，主要由服务器、客户机、网络构成

8. 优点：1.数据分布最直接；2.服务器可以分布到网络上；3.很容易就添加一台新服务器或更新现有服务器

9. 缺点：1.没有共享数据模型，数据交换效率无可预知；2.没有中央寄存器的名字和服务。很难找出哪个服务器和哪些服务可用；3.每个服务器上出现冗余数据管理

l 管道和过滤器体系结构：一个系统运行时组织的模型，函数转换处理输入并产生输出，数据从一个处理单元流到另一个，每经过一个单元做一次变换。转换可以串行也可以并行。系统运行时组织的模型，可以看作是对相继输入数据的一系列变换。组件称为过滤器，数据流通路称为管道

10. 优点：1.没有复杂的组件交互；2.支持软件复用；3.易于维护；4.支持并行

11. 缺点：适用批处理方式

6.3 应用体系结构

l 应用体系结构通用模型（封装了该类系统的基本特征），能帮助我们较好地进行应用系统设计，通过比较相同类型的应用，达到模型或大粒度组件的复用，并能验证应用系统设计的有效性

l 分类：

12. 1.事务处理应用（事务是为了达到某个目标的相关操作序列，事务处理系统用来处理用户对数据库的查询或请求，并更新数据库）：以数据库为中心；【1.表示层：Web服务器负责对所有用户通信；2.应用逻辑层：应用服务器负责实现与应用有关的逻辑；3.数据层：数据库服务器负责管理数据的存入和检出】

13. 2.语言处理系统：用形式化语言来表达

第七章 设计与实现

l 一个系统中，对象是实体，表示真实世界中的实例，对象类是对象的模板，可以创建对象，对象类可以继承其他对象类的属性和服务

l 面向对象的分析：功能模型；面向对象的设计：解决方案；面向对象的程序设计：软件设计

l 对象是现实世界或者系统实体的抽象；对象是独立的；系统的功能表达为对象服务；对象通过信息传递进行通信；对象可能是分布式的

l 优点：易维护、易复用、易拓展

7.1 使用UML的面向对象设计

l UML是面向对象建模的一个标准

l 由概念设计转变为详细设计，需要完成以下几点：

1. 了解并定义上下文和系统的外部交互（系统上下文模型；系统时序模型）（用例模型代表与系统的每个交互）

2. 设计系统体系结构

3. 识别出系统中的主要对象（最难部分；迭代的过程）（对自然语言描述做文法分析、使用领域中的真实实体等、使用基于脚本的分析、使用行为方法）

4. 开发设计模型 （对系统中包含的对象或对象类以及它们之间的不同类型关系描述）（子系统模型、序列模型、状态机模型、其他模型）

5. 定义对象接口（将具体的接口实现方法隐藏起来）

7.2 设计模式

l 模式：对问题和解决方案基本内容的描述（名字、问题域的描述、对部分设计的解决方案描述、结果陈述）

7.3 实现问题

l 复用：抽象层（运用软件设计中的成功抽象）、对象层（直接复用库中对象）、组件层（增加自己的代码对组件进行调整和扩展）、系统层（复用整个应用系统）

l 配置管理：版本管理（对组件不同版本追踪提供支持）、系统集成（提供支持帮助开发人员定义在创建每个系统版本时所用的组件版本）、问题追踪（允许客户报告缺陷）

l 宿主机-目标机开发：软件在一台计算机开发，在另一台计算机中运行

7.4 开源开发

l 开源开发：用于描述那些源码可以被公众使用的软件

第八章 软件测试

l 有效性测试、缺陷测试（只能证明存在错误，不能证明不存在）

l 检验和有效性测试的区别：前者是一般过程，确保满足用户期望；后者是审查软件满足它所规定的功能和非功能性需求

l 软件审查：审查系统需求、设计模型、程序源代码，是静态过程；软件测试：动态过程

l 软件审查的优势：可以发现系统的多个错误，也可以考虑程序的质量属性，审查不完整版本不需要额外代价，比测试更有效地发现缺陷

l 软件审查的不足：难以发现1.由于程序间未预料到的交互造成的 2.时序问题产生的 3.系统性能问题造成的 问题

l 程序测试：可以揭示错误的地方；通过执行软件来观察其行为；应与静态检验联合

l 调试：错误出现的地方和如何改正错误

l 定义了在选择系统测试中使用的方法：

1. 所有的能从菜单中得到的系统功能都应该被测试到

2. 可以从同一菜单中访问的组合功能需要被测试

3. 提供用户输入的地方，所有功能都必须用正确和不正确的输入进行测试

l 三个阶段：开发测试、发布测试、用户测试

8.1 开发测试

l A.单元测试：1.测试与对象相关的所有操作；2.设置和检查与对象相关的属性；3.让对象处于所有可能的状态下

n 泛化或继承让对象类测试更困难原因是要测试的数据没有被定位

n 自动化测试的三部分：准备部分、调用部分、断言部分

n 单元测试案例的有效性

Ø 划分测试：识别具有共同特性和以相同方法处理的一组数据

14. • 程序的输入数据和输出结果总是落在几个不同类中，这些类中的数据有公共特征

15. • 由于类中成员的这些等价行为，这些类通常叫做等价划分或者域

16. • 测试用例应从每个划分中选择

Ø 基于准则测试：使用测试准则来选择测试案例。当测试带有序列、数组或是链表的程序时，有多个准则可以揭露缺陷

1. 选择能够迫使系统产生所有错误信息的输入

2. 设计能够使系统的输入缓冲溢出的输入

17. 3. 重复相同的输入或一系列输入很多次

18. 4. 迫使产生无效的输出

19. 5. 迫使输出结果太大或太小

l B.组件测试：通常有许多彼此交互的对象组合的符合组件，首先关心的是组件接口行为是否符合描述

n 接口测试：目标是为了检测由于接口的错误或无效的接口假设所造成的故障

n 接口类型：1.参数接口、共享内存接口、程序接口、消息传递接口

n 接口错误：接口误用、接口误解、时序错误

n 接口测试准则：

1. 检查要测试的代码并明确列出对外部组件的每个调用

2. 当有指针从接口传递时，总用空指针参数来测试接口

3. 当通过程序接口调用组件时，设计一些容易引起组件失败的测试

4. 在消息传递系统中进行强度测试

5. 当组件间通过共享内存交互时，可以设计一种测试，使其对激活组件的次序有所改变

6. 审查和复查有时比发现接口错误的测试更有效

l C.系统测试：包括组件继承后的系统或子系统，两个阶段：集成测试、发布测试，注重交互

n 集成测试：从组件建立系统和对合成的系统进行测试，发现组件交互引起的问题

n 系统测试策略：

1. 所有的能从菜单中得到的系统功能都应该被测试到

2. 可以从同一菜单中访问的组合功能需要被测试

3. 提供用户输入的地方，所有功能都必须用正确和不正确的输入进行测试

n 黑盒测试：把测试对象看作一个黑盒子，测试人员完全不考虑程序内部的逻辑结构和内部特性，只依据程序的需求规格说明书，检查程序的功能是否符合它的功能说明

n 白盒测试：此方法把测试对象看作一个透明的盒子，它允许测试人员利用程序内部的逻辑结构及有关信息，设计或选择测试用例，对程序所有逻辑路径进行测试

8.2 测试驱动开发

l 是一种程序开发方法，交错地进行测试和代码开发

l 步骤：

1. 从识别所需要的功能增量开始

2. 针对此功能编写一个测试并实现为一个自动测试

3. 运行此测试，以及所有已实现的其他测试

4. 实现这个功能，并重新运行这个测试

5. 一旦所有的测试成功，转去实现下一个功能模块

l 优势：便于理解、代码覆盖、回归测试、简化调试、系统文档

8.3 发布测试

l 发布测试：是对将要分发给用户的系统版本的测试过程

l 一般使黑盒测试或者是功能测试

l 基于需求的测试：有效性验证测试而非缺陷测试

l 情景测试：也叫脚本测试、场景测试，将用户和工作联系起来

l 性能测试：释放测试的部分可能涉及测试系统的重要属性，保证系统可以处理预期负荷

8.4 用户测试

l α测试：软件的用户和开发小组一起在开发者的地点测试软件

l β测试：该软件的版本提供给用户让他们进行试验，并向开发者提出所发现的问题

l 接收测试：客户测试系统，以决定他们是否愿意从系统开发者那里接收系统

第九章 软件进化

l 软件的开发不会因为系统的交付而停止，它贯穿于系统的整个生命周期

9.1 进化过程

l 软件变更是不可避免的（用户需求改变，运行环境变化，软件错误报告，硬件变更，性能提升）

l 软件移交之后的变更过程被称为软件维护

l 软件工程是一个贯穿于系统生命周期的由需求、设计、实现、测试、运行组成的螺旋过程

l 进化：涉及软件体系结构和功能性重大改变的阶段；服务：对软件做一些小的和必不可少的改变；淘汰：软件仍在使用但不会有进一步改动

l 变更建议驱动系统进化

l 迭代开发过程中完成对系统涉及的修改、实现、测试

l 紧急修补：紧急变更的实现不需要经历软件工程的所有阶段

1. 如果有严重的系统缺陷发生，那么必须修补
2. 如果系统操作环境的变更中有不期望的情况发生
3. 如果系统上运行的业务有未预料的改变发生

9.2 程序进化动态特性

l Lehman定律的内容

1. • 第1条：系统维护是一个不可避免的过程

2. • 第2条：随着系统的改变，其结构在退化

3. • 第3条：大型系统自身的动态特性是在开发过程的早期阶段建立的

4. • 第4条：绝大多数大型程序设计项目是在一种称之为“饱和”状态下运作的

5. • 第5条：关于在每个系统版本中的变更增量

6. • 第6条、第7条：软件用户将变得愈加的不满意，除非软件得到维护并且有新功能加入进来

7. • 第8条：反馈过程

l Lehman定律适用于大型组织开发大型、定制软件

9.3 软件维护

l 软件交付后变更软件的过程称为软件维护

1. 纠正性维护：修补软件缺陷

2. 适应性维护：使软件适应不同操作环境

3. 完善性维护：增加或修改系统功能

l 对于业务应用系统，维护成本和系统开发成本大体相等。对于嵌入式实时系统，维护费用是开发成本的四倍以上

l 变更预测：预测变更请求的数目需要了解系统和外部环境之间的关系。影响这个关系的因素有：

1. 系统接口的数目和复杂性

2. 固有的易变性系统需求数目

3. 系统所处的业务过程

l 可维护性度量：

1. 请求纠正性维护的数目

2. 作用分析所需的平均时间：反映受变更请求影响的程序组件数目

3. 实现一个变更请求的平均时间：取决于程序设计的难易程度

4. 突出的变更请求的数目

l 软件再工程：

Ø 重组，或重写一部分或全部的遗留系统而不变更其功能

Ø 适用于大型系统中需要频繁维护的子系统

Ø 系统再工程使得系统更易于维护

Ø 优势：较小的风险和成本

1. 源代码转换：使用工具将语言转换成相同语言新版本或另一种语言
2. 逆向工程：从源代码中抽取系统的说明和设计信息，把这种信息求精与简化以备用
3. 程序结构改善：对控制结构进行分析和修改，提高可读性
4. 程序模块化：可能涉及到体系结构的重构
5. 数据再工程：对数据及其结构进行分析重组

l 再工程和重构的区别：再工程发生在系统已经维护了一段时间并且维护费用不断上升的情况下；重构是一个连续不断的改进过程

l 可通过重构被改进的情况：1.冗余代码；2.长方法；3.选择语句；4.数据聚集；5.假设的一般性

9.4 遗留系统管理

l 对遗留系统的四种基本选择：1.彻底抛弃这个系统；2.继续维护这个系统；3.对系统再工程以改善这个系统；4.以一个新的系统代替整个或部分系统

l 系统业务价值评估要考虑：1.系统的使用；2.支持的业务流程；3.系统可靠性；4.系统的输出

l 评估应用系统技术质量：1.请求系统变更的数目；2.用户界面数目；3.系统使用的数据量

其他内容

1.项目管理

l 目标：按时交付、成本控制、满足用户要求、好的团队

l 软件工程与其他工程的不同 1. 软件产品是无形的2. 大型软件常常是一次性的项目 3. 软件开发过程是可变的和机构特定的

l 风险管理：种类：项目风险、产品风险、业务风险；过程：风险识别、分析、规划、监控（最重要）

l 人员管理：一致性、尊重、包容、诚实

l 要点：

n 软件项目管理是必要的 

n 软件项目管理与其他工程管理的区别 

n 风险管理是项目管理最重要的任务之一 

n 开发小组不宜太大而且要有凝聚力 

n 小组内部沟通受到多种因素影响

2.项目规划

l 软件成本组成部分：1.硬件软件费用2.差旅费和培训费3.工作成本4.管理费用

l 计划驱动开发：基于计划的开发，给开发过程制定详细计划（项目计划和项目规划）

l 进度安排：决定如何组织项目工作，将其分为单独任务，并何时何方式完成项目的过程

l 要点

n 系统报价并不仅仅取决于它的估计开发成本和开发公司要求的利润。机构因素可能提高售价以补偿升高的风险，或者降低售价以获得竞争的优势

n 软件通常是先有定价以得到合同，然后再据此调整相应的功能 

n 计划驱动开发是围绕一个详细定义的项目计划进行组织的 

n 项目进度安排需要创建有关项目计划的各种图形化表示

3.质量管理

l 质量：产品必须符合其描述

l 软件质量管理：关心一个软件产品是否达到需要的质量水平（确定适当的质量标准和程序）

l 质量管理范围：质量文档和质量文化

l 质量管理活动：1.质量保证2.质量规划3.质量控制（质量管理和项目管理应该分开）

l 过程和产品质量：开发过程的质量直接影响了交付产品的质量；因某些质量属性难以评估，所以这十分重要；过程质量和产品质量的关系十分复杂和难以理解

l 质量规划：列出了所需的产品品质以及如何达到这些品质要求，同时确定最重要的质量属性（质量规划应定义质量评估过程）

l 质量规划结构:1. 产品介绍 2. 产品计划 3. 过程描述 4. 质量目标 5. 风险和风险管理

l 质量控制：包括监督检查整个软件开发过程（质量评审、自动化的软件评估）

l 质量评审：是验证一个过程或产品指令最广泛的方法（设计或程序检查 (产品) 过程审查 (产品和过程) 质量审查 (产品和标准)）

l 质量审查：目标是发现系统中错误和不一致的地方，所有文档都有被审查到

l 审查结果：审查过程中的所有意见都应分类（1. 不采取行动2. 参照修理3. 重新考虑整体设计）

l 标准是有效地进行质量管理的关键

n 产品标准：用于待开发的所有组件，如文档标准等

n 过程标准：定义了软件开发必须遵循的过程

l 标准的重要性：

1. 软件标准封装了最成功至少是最恰当的软件开发经验

2. 软件标准提供了一个框架，围绕这个框架才能实现质量保证过程

3. 软件标准还有助于工作的连贯性，由一个人着手进行的工作，别人可以接着做

l 存在的问题：

1. 在软件工程师看来，它们可能是不相关或不是最新的

2. 它们往往涉及太多的形式化内容

3. 如果软件工具不支持这些标准，那么为了能使文档和标准联系起来，则需要繁琐的手工劳动

l 标准开发：1.软件工程人员参与产品标准的选择 2.定期评审和修改标准，以反映技术的变化 3.尽可能提供支持软件标准的软件工具

l 文档化标准：1. 文档过程标准2. 文档标准3. 文档转换标准

l 文档标准：1. 文档标识标准2. 文档结构标准3. 文档书写标准4. 文档更新标准

l 文档转化标准：交换标准允许电子文件间的转换和邮发等

l 复查和审查：复查与审查是检查项目可交付文档质量的互动

l 软件度量：量是对软件产品或过程的某种属性进行量化

l 软件量度是能够被客观度量的软件系统、系统文档或开发过程有关的特性，包括控制量度（支持过程管理）和预言者量度（帮助预测软件特性）

4.配置管理

l 配置管理关注的是管理不断变化的软件系统，配置管理有时候被看做是软件质量管理过程的一部分

1. 变更管理 • 包括跟踪来自客户和开发者的软件变更请求，计算做出这些变更的花费并估计其影响，决定是否变更、何时完成变更

2. 版本管理 • 包括跟踪系统组件的多个版本，确保由不同开发者对组件做出的变更不会彼此干涉

3. 系统构建 • 是一个组装程序组件、数据和库的过程，然后把这些组件编译链接成一个可执行系统

4. 发布管理 • 包括准备对外发布的软件，持续跟踪已经发布以供客户使用的系统版本

l 配置管理(CM)应始终基于组织内部应用标准，标准应基于外部配置管理标准

l 配置项识别：大型项目中可能包含数以千计的文档，它们的配置中一定要唯一标识（分层命名规则）

配置数据库：所有的CM信息都要存储CM数据库中，配置数据库必须能够对各种系统配置查询做出应