“凋零的是那花，不是春天。”
前言
本来是期末复习用的，但是写到一半发现只用看那些 mark 的章节，而我全看了…
一不做二不休直接看完，以后就不看书看这个了！
题目有名词解释、简答题、综合题。章节有以下三种 mark：
了解：小题；理解：小题、大题；掌握：大题
然后针对考试整理一波…
副标题开玩笑的，具体内容有不理解还是要看书嗷
看完书再来看这个大纲就挺有用的了
考试要看的
1.2.1 软件工程定义（了解）
2.1 基于计算机的系统（了解）
2.2 系统工程的任务（理解）
2.3 可行性分析（了解）
3.1 需求工程概述（了解）
3.2.2 需求获取方法与策略（掌握）
4.1 软件设计工程概述（了解、理解）
5.1 结构化分析方法概述（了解）
5.4.2 字典条目（理解）
7.1 面向对象的基本概念（了解）
8.1 用况建模（了解）
9.1.1 构件（了解）
10.1.3 敏捷方法综述（了解）
11.4.3 黄金原则（了解）
13.1.2 软件测试的基本原则（理解）
13.4.2 单元测试（了解）
15.1.1 软件维护的概念（了解）
15.1.3 软件可维护性（理解）
16.1 软件项目管理概述（了解）
16.2.2 面向功能的度量（掌握）
Software Engineering
Ch1 概论
1.1 计算机软件
定义：计算机软件指计算机系统中的程序机器文档
特点：
1. 软件是逻辑实体，开发成本和进度难以精确估算
2. 软件被开发或设计，没有明显制造过程，维护工作量大
3. 没有硬件的机器磨损和老化问题。
分类：
1. 系统软件：与应用领域无关，其他软件通过其发挥作用
2. 支撑软件：支撑软件开发和维护
3. 应用软件：特定应用领域专用
语言：
1. 需求定义语言：书写软件需求定义的语言（功需求和非功能需求），有PSL/PSA等。
2. 功能性语言：即软件功能规约，是软件所完成功能的精确完整陈述，有光谱语言、Z语言等。
3. 设计性语言：书写软件设计规约的语言（总体设计和详细设计），有PDL等。
4. 实现性语言：即程序设计语言，可如下细分
语言级别：高级语言、低级语言
用户要求：过程式语言、非过程是语言
应用范围：通用语言、专用语言
使用方式：交互式语言、非交互式语言
成分性质：顺序语言、并发语言、分布语言
5. 文档语言：书写软件文档的语言。
1.2 软件工程
软件工程定义（了解，记一个就好）：
1. Fritz Bauer：建立和使用一套合理的工程原则，以便获得经济可靠的软件，可在实际机器上高效运行
2. IEEE：软件工程是将系统化的、严格约束的、可量化的方法应用于软件的开发、运行和维护，即将工程化应用于软件；以及对其方法的研究
3. 《计算机科学技术百科全书》：是应用计算机科学理论和技术以及工程管理原则和方法，按预算和进度实现满足用户要求的软件产品的工程，或以此为研究对象的科学
软件工程框架
目标：生产具有正确性、可用性和开销合宜的产品。
过程：生产一个最终满足需求且达到工程目标的软件产品所需的步骤
原则：1. 选取适宜的开发模型； 2. 采用合适的设计方法； 3. 提供高质量的工程支持； 4. 重视软件工程的管理
生存周期：
1. 计算机系统工程：包括软硬件及人、数据库、文档等元素。
2. 需求分析：确定软件的功能、性能、数据、界面等要求，生成 软件需求规约。
3. 设计：系统设计和详细设计
4. 编码：敲代码
5. 测试：发现并纠正软件的错误和缺陷
6. 运行和维护：修改潜藏错误/增加新的功能
1.3 软件过程
ISO/IEC 标准：5 个基本过程了，8 个支持过程，4 个组织过程。每一个过程划分为一组活动，每项活动划分为一组任务
基本过程：
1. 获取过程
2. 供应过程
3. 开发过程
4. 运作过程
5. 过程维护
支持过程
1. 文档编制过程
2. 配置管理过程
3. 质量保证过程
4. 验证过程
5. 确认过程
6. 联合评审过程
7. 审计过程
8. 问题解决过程
组织过程：
1. 管理过程
2. 基础设施过程
3. 改进过程
4. 培训过程
能力成熟度模型 CMM（Capability Maturity Model）：提供一种评价软件承接方能力的方法
1. 初始级(initial)：无秩序、混乱的
2. 可重复级(repeatable)：基本项目管理过程来跟踪成本、进度和功能特性
3. 已定义的(defined)：将管理和工程活动两方面的软件过程文档化、标准化，综合成该组织的标准软件过程
4. 已管理级(managed)：收集对软件过程和产品质量的详细度量值，有定量的理解和控制
5. 优化级(optimizing)：过程的量化反馈和先进的新思想、新技术不断改进过程
能力成熟度模型继承 CMMI：若干过过程模型的综合和改进，是支持多个工程学科和领域的、系统的、一致的过程改进框架
提供两种表示法：连续式模型和阶段式模型
1.4 软件过程模型
1. 瀑布模型
- 接受上一阶段活动的结果作为本阶段活动的输入
- 依据上一阶段活动的结果实施本阶段应完成的活动
- 对本阶段的活动进行评审
- 将本阶段的活动结果作为输出，传递给下一阶段
2. 演化模型
构建软件初始化版本，即原型，根据用户在试用原型的过程中提出的意见和建议，或新的需求，对其进行改造
典型的演化模型有：增量模型、原型模型、螺旋模型
3. 增量模型
将软件的开发过程分为若干个日程时间交错的线性序列，每个线性序列产生一个可发布的“增量”版本。后一个版本是对前一个版本的修改和补充
适用于需求经常变化的软件开发
4. 原型模型
原型是预期系统一个可执行版本，不必满足目标软件所有约束。
被开发原型交付客户试用，并根据反馈意见不断迭代改进。
原型类型：
1. 探索型：弄清目标系统的要求，探讨多种方案
2. 实验型：验证方案或算法的合理性
3. 演化型：原型作为最终系统的一部分，将其逐步改进演化为最终系统
原型使用策略：
1. 废弃策略：主要用于探索型和实验型。关注最终系统的某些而非全部特性，最终被废弃，根据结果重新设计最终系统
2. 追加策略：主要用于演化型。对其不断修改扩充，追加新的要求，最终成为最终系统。
5. 螺旋模型
结合原型的迭代和瀑布模型中控制和系统化的方法，增加了风险分析。
四个象限（任务区域）：
1. 制定计划：确定软件目标
2. 风险分析：评价方案，识别风险
3. 工程实施：软件开发，验收产品
4. 客户评估：评价工作，提出建议
每转一圈，表示开发出一个更为完善的版本，最终得到期望的系统。
6. 喷泉模型
支持面向对象开发的过程模型。
开发的各个活动没有明确边界，各个活动重复迭代交替进行
7. 基于构建的开发模型
利用预先包装的构建来构造系统。
其中一种模型包括领域工程和应用系统工程
- 领域工程： 构建领域模型、领域基准体系结构（参考体系结构）、可复用构件库
- 应用系统工程：使用可复用构建组装应用系统
8. 形式化方法模型
建立在严格数学基础上，采用严格的数学语言，具有精确的数学语义的方法
易于发现需求的歧义性、不完整性和不一致性，易于分析模型、设计模型和程序进行验证
例如净室软件工程，强调在程序构造开始前进行正确性验证、统计质量控制技术，分析使用情况的概率分布等
1.5 CASE 工具与环境
CASE（Computer Aided Software Engineering），计算机辅助软件工程
软件工具
分类：
1. 支持软件开发过程：需求分析工具、设计工具、编码工具、排错工具、测试工具
2. 支持软件维护过程：版本控制工具、文档分析工具、开发信息库工具、逆向工程工具、再工程工具
3. 支持软件管理过程和支持过程：项目管理工具、配置管理工具、软件评价工具
衡量标准：
1. 功能
2. 易用性
3. 稳健性
4. 硬件要求和性能
5. 服务和支持
软件开发环境
特征：
1. 环境的服务是集成的
2. 环境应支持小组工作方式
3. 环境的服务可用于支持各种软件开发活动
环境集成机制：
1. 数据集成
2. 界面集成
3. 控制继承
4. 方法与过程集成
5. 平台集成
Ch2 系统工程
2.1 基于计算机的系统（了解）
通过处理信息来完成某些预定义目标而组织在一起的元素集合或排列
元素主要有：
1. 软件：计算机程序、数据结构等用以实现所需的逻辑方法、规程或控制
2. 硬件：提供计算能力的电子设备、支持数据流的互连设备、支持外部功能的机电设备
3. 人员：软硬件的使用者
4. 数据库：通过软件访问并持久存储的大型有组织数据的集合
5. 文档：描绘系统的使用或操作的描述性星信息
6. 规程：定义每个系统元素或其外部相关流程的具体使用步骤
2.2 系统工程的任务（理解）
1.识别用户的要求：识别用户的总体要求，标识功能和性能范围，确定功能、性能、约束、接口
2.系统建模和模拟：可考虑以下模型
1. 硬件系统模型：基于硬件配置、通信协议、拓扑结构，确保系统的安全性、可靠性、性能要求等
2. 软件系统模型：基于软件部分，可分解为若干子系统。描述子系统功能、性能、子系统之间的交互等
3. 人机接口模型：描述人如何与计算机的系统进行交互，包括用户环境、用户活动、语法语义等
4. 数据模型：基于数据库管理系统。描述多个数据库管理系统间的数据转换方式（如果有），必要时给出数据结构
3.成本估算及进度安排
4.可行性分析：经济、技术、法律等方面分析方案是否具有一定经济效益、社会效益
5.生成系统规格说明：形成系统规格说明，基于系统功能、性能、约束条件。描述输入输出、控制信息、元素模型、可行性分析、成本估算和进度安排
2.3 可行性分析（了解）
可行性分析最终结论：
- 可立即开始
- 推迟到某些条件落实后开始
- 对开发目标修改后开始
- 不能进行
经济可行性
成本效益
- 成本：软硬件、设备费用、开发费用、安装运行维护费用、人员培训费用
- 效益：经济效益（货币的时间价值、投资回收期、纯收入），社会效益（对社会产生的影响，定性估计）
- 货币的时间价值：现在的钱 P，n 年后得到的钱 F，年利率 i。P=F/(1+i)^n
- 投资回收期：累计的经济效益等于投资成本所需的时间（回本时间）
- 纯收入：累计经济效益-成本
技术可行性
- 风险分析：不成熟技术风险、人员流动风险、成本和人员估算不合理的预算风险
- 资源分析：论证是否具备开发所需的人员、软硬件等资源和工作环境
- 技术分析：当前科学技术是否支持系统开发各项活动。根据系统性能、可靠性、可维护性、生产率，分析实现所需的技术、方法、算法、或过程
法律可行性
涉及合同、侵权、责任等问题。
《中华人民共和国著作权法》、《计算机软件保护条例》
方案选择和折衷
评估依据：功能、性能、成本、开发时间、采用技术、设备、风险、对开发人员的要求等
Ch3 需求工程
需求开发是一个迭代的过程
3.1 需求工程概述（了解）
6 个阶段：
- 需求获取：与用户交流、观察现有系统、分析任务，确定系统范围的限制性描述、人员及特征列表、技术环境描述、功能列表、不同应用场景等，为需求分析提供基础。
- 需求分析与协商：检查需求的一致性、重叠、遗漏，对需求排序。可能出现需求超出实现能力或需求冲突等问题，需要谈判解决。（球球你了甲方爸爸）
- 系统建模：通过合适的工具和符号系统描述需求。常用方法有面向数据流方法、面向数据结构方法、面向对象方法
- 需求规约：建立完整信息描述、功能和行为描述、性能需求和设计约束、验收标准
- 需求验证：评价功能的正确性、完整性、清晰性。
- 需求管理：对需求工程所有活动的规划和控制。
3.2 需求获取
软件需求：
1. 功能需求
2. 性能需求
3. 用户或人的因素
4. 环境需求
5. 界面需求
6. 文档需求
7. 数据需求
8. 资源使用需求
9. 安全保密需求
10. 可靠性需求
11. 软件成本消耗与开发进度需求
12. 其他非功能需求
需求获取方法与策略（掌握）
1. 建立顺畅的通信渠道
2. 访谈与调查（面谈、市场调查、访问专家）
原则：
1. 问题循序渐进；
2. 不限制用户回答；
3. 反应用户需求全貌
3. 观察用户操作流程：了解用户实际操作环境、过程和要求
4. 组成联合小组：即便利的应用规约技术FAST
原则：
1. 在中立地点举行会议
2. 建立准备和与会原则
3. 自由交流的议程
4. “协调者”控制会议
5. 使用“定义机制”
6. 目标：标识问题、提出解决方案、商议不同方法、刻画初步需求
5. 用况（用例）：创建的一组最终系统的使用场景
建模原则：
1. 确定系统的执行者
2. 选取一个执行者
3. 定义执行者希望系统做什么（每件事将成为一个用况）
4. 描述该用况的基本过程
3.3 需求分析、协商与建模
需求分析原则：
1. 表示和理解问题的信息域
2. 定义软件将完成的功能
3. 表示软件的行为
4. 划分描述数据、功能和行为的模型，分层次揭示细节
5. 从要素信息移向细节信息
信息域：包括信息内容、信息流、信息结构
1. 信息内容：单个数据和控制对象。构成软件所有处理的信息集合
2. 信息流：数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息，然后变为输出
3. 信息结构：数据和控制项的内部组织形式
需求协商：讨论需求冲突，找出大家都满意的折衷方案（和甲方爸爸 battle）
注意因素：
1. 不一致的目标
2. 责任的丧失或转移
3. 组织文化
4. 组织管理态度和士气
5. 部门差异
需求建模：常用分析方法如下
1. 面向数据流的结构化分析方法（SA）
2. 面向数据结构的分析方法
3. 面向对象的分析方法（OOA）
3.4 需求规约与验证
需求规约的原则：
1. 从现实中分离功能
2. 使用面向处理的规约语言
3. 若被开发软件是一个元素，则大系统也包括在规格说明中
4. 规约包括运行环境
5. 规约是一个认识模型
6. 规约是可操作的
7. 规约允许不完备性并允许扩充
8. 规约必须局部化和松散耦合
需求规约：IEEE 标准
1. 引言
2. 信息描述
3. 功能描述
4. 行为描述
5. 检验标准
6. 参考书目
7. 附录
需求验证：检验需求是否反应用户的医院
检查内容：
1. 系统定义的目标和用户要求是否一致
2. 系统需求分析阶段提供的文档资料是否齐全，是否完整清晰准确反应用户要求
3. 系统的数据流与数据结构是否确定且重组
4. 是否已包括主要功能
5. 约束条件或限制条件是否符合实际
6. 技术风险是什么
7. 是否制定检验标准
3.5 需求管理
帮助项目组标识、控制、跟踪需求的一组活动
每个需求被赋予唯一标识，可建立跟踪表。
需求跟踪两种方式：1. 正向跟踪，检查用户需求；2. 逆向跟踪：检查文档、代码、测试用例等
Ch4 设计工程
4.1 软件设计工程概述（了解、理解）
软件设计任务
1. 数据/类设计：将分析类模型变换成实现所需的数据结构，即数据各元素间逻辑关系的表示
数据标准化：
1. 数据获取：第一次出现被获取，之后内部共享
2. 数据分布：基于完整性和应用需求
3. 数据词典：为所有程序存取的标准化定义
4. 数据共享：共享相关数据
5. 数据所有权：信息单元有唯一指派的拥有者
6. 数据质量：准确性、完整性、规范性等
2. 体系结构设计：软件部件、外部可见属性和他们间的关系组成
3. 接口设计：软件内部、软件和协作系统、软件和人之间的通信方式。
包括设计软件模块间的接口、设计模块与其他非人的生产者和消费者之间的外部接口、设计人与计算机间的人机接口
4. 部件级设计：将软件体系结构的结构性元素变换为软件部件的过程性描述
软件设计目标
目标：
1. 设计实现分析模型中的显式需求，满足用户希望的隐式需求
2. 设计可读、可理解、易于编程、易于测试、易于维护
3. 设计从现实角度出发，展示软件全貌
衡量设计的技术标准：
1. 设计应是分层结构
2. 设计应当模块化
3. 设计包含数据抽象和过程抽象
4. 设计包含独立功能特征的模块
5. 设计具有降低模块与外部环境间复杂连接的接口
6. 设计能建立可驱动、可重复的方法
软件设计过程
1. 制定规范
2. 体系结构和接口设计
3. 数据/类设计
4. 部件级设计
5. 编写设计文档
6. 设计评审
4.2 软件设计原则
抽象与逐步求精
- 抽象：忽略低层次细节。上层是下层的抽象，下层是上层的精化和细化
- 逐步求精：揭示底层细节
模块化
按照规定原则，把软件划分成较小的、相对独立又相互关联的部件。实际上是系统分解和抽象的过程
有描述问题x复杂性的函数C(x)和解决问题x的工作量函数E(x)
若C(p1) > C(p2)，则E(p1) > E(p2)
有C(p1+p2) > C(p1)+C(p2)，即E(p1+p2) > E(p1)+E(p2)
模块数量越多，单个模块规模越小，单个模块开发成本越低，但是所有模块的集成成本越高
信息隐藏
每个模块的实现细节对其他来说是隐蔽的，即相对独立
功能独立
模块实现独立的功能且与其他模块的接口相对简单。
功能独立是模块化、抽象、信息隐藏的直接结果
衡量指标：内聚度和耦合度。最好高内聚、低耦合。
1. 内聚：模块内部元素的紧密程度。内聚性越低，功能越分散
内聚类型（从低到高）：
1. 巧合内聚（偶然内聚）
2. 逻辑内聚
3. 时间内据
4. 过程内聚
5. 通信内聚
6. 顺序内聚
7. 功能内聚
2. 耦合：模块间的相对独立性。耦合性越高，功能独立性越弱
耦合类型（从高到低）：
1. 内容耦合：直接访问其他模块内部数据、不通过正常入口、程序代码重叠、模块有多个入口等
2. 公共耦合：访问同一个公共数据环境
3. 外部耦合：模块通过软件之外的环境联结
4. 控制耦合：传递的参数中包含控制信息
5. 标记耦合：通过参数传递数据结构的一个部分
6. 数据耦合：仅通过参数传递简单数据
7. 非直接耦合：没有直接关系
4.3 软件体系结构设计
C/S，B/S 等
C/S 即 3 层/多层计算（3 层体系结构），应用程序和用户分离
软件体系结构的风格：
1. 数据为中心的体系结构
2. 数据流风格的体系结构
3. 调用和返回风格的体系结构
4. 面向对象风格的体系结构
5. 层次风格的体系结构
评估体系结构方法：ATAM（体系结构权衡分析法）
1. 定义应用场景（整用况图）
2. 得出需求、约束、环境描述
3. 描述满足需求的体系结构风格
4. 单独评价各项性能
5. 评价不同架构下的性能敏感程度
6. 进行敏感度分析
4.4 部件级设计技术
是编码的先导，其设计文档质量影响下一阶段程序质量
1. 为每个部件确定算法
2. 确定部件内部使用的数据结构
3. 将结果写入部件级设计说明书
结构化程序设计方法
没有明确定义
“程序代码仅由顺序、选择、循环 3 种基本控制结构联结，每个代码块只有一个入口和出口，则称其为结构化”
图形表示法
- 程序流程图：独立于设计语言
- N-S 图：盒图。
- PAD：用结构化程序设计思想表现程序逻辑结构的图形工具
判定表
简洁、无二义性描述所有处理规则，但其表示静态逻辑，不能表达加工顺序或循环结构。
4.5 设计规约与设计评审
设计规约大纲：
1. 工作范围
2. 体系结构设计
3. 数据设计
4. 接口设计
5. 各部件过程设计
6. 运行设计
7. 出错处理设计
8. 安全保密设计
9. 需求/设计交叉索引
10. 测试部分
11. 特殊注解
12. 附录
设计评审：
1. 可追溯性： 系统、子系统结构是否满足需求
2. 接口：是否明确定义且高内聚低耦合
3. 风险：能否按时实现
4. 实用性：是否实用
5. 技术清晰度：是否易于翻译成代码
6. 可维护性：是否便于维护
7. 质量：是否质量良好
8. 各种可选方案：比较方案的标准
9. 限制：是否与需求一致
10. 其他具体问题
Ch5 结构化分析与设计
5.1 结构化分析方法概述（了解）
抽象和分解：自顶向下是分解，自底向上是抽象
结构化分析过程
1. 获得系统的具体模型（物理模型）
2. 抽象出系统的逻辑模型
3. 分析目标系统与当前系统逻辑上的差别，建立目标系统的逻辑模型
4. 补充逻辑模型
结构化分析模型的描述形式
1. 数据流图+加工规约：用于功能建模。描述输入数据流如何变为输出数据流。其中数据流、文件、数据项等在数据字典中描述
2. 实体-关系图（E-R图）+数据对象描述：用于数据建模，描述数据字典中数据之间的关系
3. 状态转换图+控制规约：用于行为建模。描述系统接受哪些外部事件及系统状态迁移。
5.2 数据流图
DFD，（data flow diagram），描述输入数据流到输出数据流的变换，用于系统的功能建模
基本图形元素
1. 源或宿：输入数据的来源和输出数据的去向。源是输入，宿是输出。
2. 加工：输入数据流到输出数据流的变换
3. 数据流：一组固定成分的数据（源到加工、加工到加工、加工到文件、文件到加工、加工到宿）
4. 文件：存放是数据
扩充符号
1. 星号（*）：与。例如输入数据全部到达才进行加工
2. 加号（+）：或。任何一个数据到达才进行加工
3. 异或（⊕）：互斥。当且仅当一个数据到达才进行加工（两个都到不加工）
层次结构
1. 层次结构：
1. 顶层一张图，只有一个加工，表示整个系统，即顶层图。
2. 顶层图的那一个加工分解后为0层图，只有一张。
3. 最底层的为底层图，其加工不分解。不分解的加工为基本加工
4. 其他为中间层图，至少有一个加工被分解
2. 图和加工的编号：
1. 顶层图只有一个加工，不用编号
2. 0层图的加工编号为1、2、3...
3. 加工号x被分解，其子图记为图x
4. 其中加工编号为x.1、x.2...比如
5.3 分层数据流图的审查
一致性：不存在矛盾和冲突
1. 父图和子图的平衡：输入流和输出流一致
2. 数据守恒：输出数据流的数据从输入数据流中得到，删去未使用数据
3. 局部文件：当文件涉及多个加工则画出
4. 一个加工的输出数据流和输入数据流不同名
完整性：没有遗漏的数据流、加工等元素
1. 每个加工至少有一个输入数据流和输出数据流
2. 每个文件至少有一个加工读它，有另一个加工写它
3. 每个数据流和文件都必须命名，与数据字典一致
4. 每个基本加工都有一个加工规约
注意事项
1. 适当命名
2. 画数据流而非控制流
3. 避免一个加工数据流过多
4. 分解均匀
5. 先考虑稳定状态，忽略启动、结束、出错等细节
6. 随时准备重画
5.4 数据字典
种类：数据流、文件、数据项、加工、源或宿
字典条目
1.数据流条目
1. 名称
2. 别名
3. 简述
4. 数据流组成
5. 数据流来源
6. 数据流去向
7. 数据量
8. 峰值
9. 注解
2.文件条目
1. 名称
2. 别名
3. 简述
4. 文件组成
5. 写文件的加工
6. 读文件的加工
7. 文件组织
8. 使用权限
9. 数据量
10. 存取频率
11. 注解
3.数据项条目
1. 名称
2. 别名
3. 简述
4. 数据类型
5. 计量单位
6. 取值范围
7. 编辑方式
8. 与其他数据项的关系
9. 注解
4.加工条目
1. 名称
2. 别名
3. 加工号
4. 简述
5. 输入数据流
6. 输出数据流
7. 加工逻辑
8. 异常处理
9. 加工激发时间：加工条件，如身份认证正确
10. 执行频率
11. 注解
5.源或宿条目
1. 名称
2. 别名
3. 简要描述
4. 输入数据流
5. 输出数据流
6. 注解
6.别名条目
1. 别名
2. 类型
3. 基本名
4. 简述
5. 说明
5.5 描述基本加工的小说明
小说明是基本加工的加工规约
结构化语言
- 力求精炼
- 易读易理解，无二义性
- 主要使用祈使句
- 名字必须在数据字典中定义
- 不使用形容词、副词
判定表
- 条件桩：列出条件对象
- 条件条目：列出条件对象的取值
- 动作桩：列出可能采取的动作
- 动作条目：各种条件组合下采取的动作
判定树：判定表的变种，本质相同，表现形式不同
5.6 结构化设计概述
结构化设计 SD：将结构化分析得到的数据流图映射成软件体系结构。强调模块化、逐步求精、信息隐蔽、高内聚低耦合等准则
详细设计是对模块实现细节的设计，采用结构化程序设计（SP）
SA（结构化分析方法）、SD、SP 构成完整的结构化方法体系
结构图
结构图描述软件系统的体系结构，指出软件系统中的模块及其调用关系
基本成分
1. 模块：具有一定功能并可以用模块名调用的一组程序。包括外部特征（接口和功能）和内部特征（内部数据）。SD只关注外部特征
2. 调用
3. 数据
辅助符号
1. 条件调用
2. 循环调用
3. 递归调用
概念
1. 深度：控制的层数
2. 宽度：最多的同一层模块数量
3. 扇出：该模块直接调用的模块数
4. 扇入：能直接调用该模块的模块数
启发式设计策略
- 改造程序结构图，降低耦合度，提高内聚度
- 避免高扇出，力求高扇入
- 模块的影响范围限制在控制范围内
- 降低模块接口复杂度和冗余度，提高一致性
- 模块功能可预测
- 尽可能设计单入口和单出口模块
5.7 数据流图到软件体系结构的映射
信息流
- 变换流：分为输入、变换、输出
- 事务流：数据流到达事务中心，在若干条动作路劲中选择一条执行
数据流图到结构图的映射步骤
- 复审精化数据流图
- 确定数据流图类型（信息流类型）
- 将 DFD 映射成初始结构图
- 改进初始结构图
变换分析
- 划定输入流和输出流边界，确定变换中心
- 进行一级分解：映射成变换型程序结构
- 进行二级分解：将加工映射成模块
- 标注输入输出信息
事务分析
- 确定事务中心
- 将 DFD 映射成事务型结构图
- 分解每条路径所对应的结构图
5.8 初始结构图的改进
改进技巧：
- 减少模块耦合度
- 消除重复功能
- 消除管道模块
- 模块大小适中避免高扇出
- 考虑全局
Ch7 面向对象方法基础
7.1 面向对象的基本概念（了解）
面向对象=对象+分类+继承+通过消息的通信
- 对象：一组属性及其专用操作的封装体。属性可以是数据或对象。
- 类：具有相同属性和相同操作的对象集合
- 继承：类间的一种基本关系，基于层次关系的不同类共享属性和操作的机制。
- 消息传递：对象间通信的手段，对象向另一个对象发送消息请求服务
- 多态性：同一个操作在不同的对象上有不同的解释，产生不同的结果
- 动态绑定：程序运行时才将消息请求的操作和实现方法进行连接
7.2 面向对象分析和设计过程
面向对象分析：OOA
面向对象设计：OOD
面向对象分析过程
分析任务
1. 沟通用户需求
2. 标识类
3. 刻画类的层次结构
4. 表示类之间的关系
5. 行为建模
6. 递归直至完成建模
分析步骤
1. 获取需求、场景、用况，建造需求模型
2. 选择类和对象
3. 定义类的结构层次
4. 建造对象-关系模型
5. 建造对象-行为模型
6. 利用场景/用况分析模型
面向对象设计过程
步骤
1. 系统设计
2. 对象设计
3. 消息设计
4. 复审
系统设计
1. 将分析模型划分为子系统
2. 标识问题本身并发性，为子系统分配处理器
3. 任务管理设计
4. 数据管理设计
5. 资源管理设计
6. 人机界面设计
7. 子系统间通信
对象设计
1. 对象描述（可采用以下形式之一）
1. 协议描述：描述对象接口，定义接收消息即接收消息后的操作
2. 实现描述：描述传送给对象的消息所蕴含的每个操作的实现细节
2. 设计数据结构和算法
设计模式
- 模式名称
- 问题
- 解决方案
- 效果
7.3 UML 概述
视图：由图组成的抽象，是系统描述的一个投影，说明了系统的一个特殊侧面。
主题域+视图+图
1. 结构化
1. 静态视图
1. 类图
2. 设计视图
1. 内部结构
2. 协作图
3. 构件图
3. 用况视图
1. 用况图
2. 动态的
1. 状态机视图
1. 状态机图
2. 活动视图
1. 活动图
3. 交互视图
1. 顺序图
2. 通信图
3. 物理的
1. 部署视图
1. 部署图
4. 模型管理
1. 模型管理视图
1. 包图
2. 剖面
1. 包图
Ch8 面向对象建模
用况建模（了解）
步骤：
1. 定义系统
2. 确定执行者：与系统交互的人或其它系统。分为主执行者和副执行者
3. 确定用况：用况总是被执行者启动；向执行者提供值；是一个完整的描述
4. 定义用况间的关系：关联、扩展、包含、用况泛化
5. 确认模型
用况描述：
- 用况的简单描述
- 用况的详细描述
静态建模
包含类及类之间的关系，展示了软件系统的静态结构
类图和对象图
CRC 技术：类-责任-协作者
1. 标识类
2. 标识责任
3. 标识协作者
4. 复审CRC卡
类之间的关系
1. 关联
2. 依赖
3. 泛化（继承、多态等）
4. 实现
5. 约束和派生
6. 模板：参数化的模型元素，生成实际类时绑定参数，不能直接使用（这不是抽象类？）
动态建模
状态机图
1. 顺序：
1. 列出对象所有状态
2. 标志状态结束事件
3. 定义状态和迁移的状态变量和动作
2. 状态：表示对象执行之前活动后的结果
3. 状态迁移
4. 事件
5. 状态机图之间发送消息
6. 组合状态：正交状态、非正交状态
7. 复杂迁移
8. 历史指示器
活动图
1. 活动图：特殊的状态机图。对计算流和工作流建模
2. 泳道：矩形区
3. 动作迁移的分解和合并
4. 活动图中的对象
5. 描述用况的活动图
顺序图
1. 概述：坐标（时间+对象）
2. 顺序图中的消息
3. 带条件和分支的顺序图
4. 定义循环和约束的标记
5. 创建对象和对象的消亡
6. 结构化控制结构
通信图
1. 通信图中的消息
2. 链：两个对象之间关联的实例
3. 对象的生存期
物理体系结构建模
- 构件图
- 部署图
1. 节点：运行时的计算机资源
2. 制品：物理实现单元
Ch9 基于构件的软件开发
CBSD，指使用可复用构件来开发应用软件
等于 CBSE，基于构件的软件工程
9.1 概述
构件（了解）
定义：
1. Pressman：构件是系统中有价值的、几乎独立并可替换的一个部分，在体系结构语境中满足某种清晰的功能
2. Brown：构件是一个独立发布的功能部分，可通过接口访问它的服务
3. 《计算机科学技术百科全书》：软件构件是软件系统中具有相对独立功能，可以明确辨识，接口由规约指定，与语境有依赖关系，可独立部署，多由第三方提供的可组装软件实体
要素：
1. 规格说明
2. 一个或多个实现
3. 受约束的构件标准
4. 包装方法
5. 部署方法
构件描述模型：
1. 3C模型
1. 概念：构件目的
2. 内容：概念的具体实现，构件功能
3. 周境：构件和周围环境在概念和内容的关系。包括概念周境、操作周境、实现周境
2. REBOOT模型：基于面向对象技术的复用构建模型。是基于刻面的模型
1. 抽象
2. 操作
3. 操作对象
4. 依赖
常用的构建标准
1. CORBA：OMG（国际对象管理组织）发布的公共对象请求代理体系结构
2. COM/DCOM：Microsoft开发
3. EJB：Enterprise Java Beans，提供客户端使用远程分布式对象的框架
9.2 建造可复用构件
对可复用构件的要求
1. 较高通用性
2. 易于定制
3. 易于组装
4. 可检索性
5. 经过充分测试
设计框架
1. 标准数据
2. 标准接口协议：软件内接口，软件外接口，人机接口
3. 程序模板
可变性分析
可变性机制：继承、扩展和扩展点、参数化
9.3 应用系统工程
基于 CBSD 的应用系统分析和设计
1. 关注接口的设计
2. 关注基于构件的体系结构
3. 基于构件的应用系统开发方法
1. Rational同意过程（RUP）
2. Sterling软件公司的企业级构件化开发方法
构建的鉴定、特化和组装
1. 构件鉴定
2. 构件特化
3. 构建组装
9.4 构件的管理
构件的分类描述
1. 枚举分类：将构件组织成分类层次结构。构件分大类，大类分小类
2. 刻面分类：根据一组刻面对构件分类
3. 属性-值分类：为所有构件定义属性
构件库管理系统
1. 构件库管理系统功能：分类存储、检索、浏览、删除、使用评价
2. 构件检索方法：查准率、查全率
Ch10 敏捷软件开发
10.1 概述
软件开发特征：
1. 提前预测需求困难
2. 软件设计和构建交错进行
3. 分析、设计、构建、测试活动难以预测
四个价值观
1. 个体和交互 > 过程和工具
2. 工作的软件 > 详尽的文档
3. 客户合作 > 合同谈判
4. 响应变化 > 遵循计划
十二个原则
1. 最高优先级是不断、及早交付有价值的软件，使客户满意
2. 拥抱变化
3. 经常交付可工作的软件
4. 业务人员和开发人员紧密合作
5. 围绕被激励的个体构件项目
6. 面对面交流最高效
7. 可工作的软件是首要度量标准
8. 倡导可持续开发
9. 持续追求技术卓越和良好设计
10. 简洁为本
11. 架构、需求、设计来自团队
12. 定期反思、调整
精益思想
- 识别价值
- 定义价值流
- 保持价值流的流动
- 拉动系统
- 持续改善
敏捷方法综述（了解）
开发方法：极限编程、Scrum、看板方法、精益软件开发方法、水晶软件开发方法、自适应软件开发（ASD）、动态系统开发方法（DSDM）
特征：
- 致力于降低变化嗲来的成本
- 强调价值：关注客户价值、强调快速交付
- 强调人的作用
- 使用增量和迭代的开发方法
Scrum 方法
- 时间盒
- Scrum 团队
- 制品
- 规则
极限编程方法
价值观和原则
1. 沟通
2. 简单
3. 反馈
4. 勇气
5. 尊重
实践
1. 故事
2. 估算
3. 简单设计
4. 重构
5. 测试驱动开发
6. 结对编程
7. 持续集成
8. 其他实践
看板方法
原则
1. 从组织的现状开始
2. 以渐进的、演化的方式改善系统
3. 尊重当前的过程定义、角色、职责、头衔
规则
1. 可视化工作流
2. 限制WIP（在制品）数量
3. 度量并管理周期时间
4. 明确过程准则
5. 通过科学的方法改善工作流
Ch11 人机界面设计
11.1 人的因素
- 人对感知过程的认识
- 用户的技能和行为方式
- 人体测量学对设计的影响
11.2 人机界面风格
- 语言界面
- 图形用户界面
- 直接操纵用户界面
- 多媒体用户界面
- 多通道用户界面
11.3 人机界面分析与建模
四个框架活动：
1. 用户、任务和环境分析及建模
2. 界面设计
3. 界面构造
4. 界面确认
模型：
1. 软件工程师：设计模型
2. 人机界面设计工程师：用户模型
3. 系统实现者：系统映像
11.4 界面设计活动
定义界面对象和动作
- 建立任务目标和意图
- 每个目标或意图映射为一系列动作
- 按界面执行方式说明动作顺序
- 指明系统状态
- 定义控制机制
- 知名控制机制如何影响系统状态
- 指明用户如何通过信息解释系统状态
设计问题
- 系统响应时间
- 用户求助设施
- 错误信息处理
- 命令标记
黄金原则（了解）
让用户拥有控制权
1. 交互模式的定义不能强迫用户进入不必要的或不希望的动作
2. 提供灵活的交互
3. 允许用户交互可以被终端或撤销
4. 交互流水化并允许定制交互
5. 用户隔离内部技术细节
减少用户记忆负担
1. 减少对短期记忆要求
2. 建立有意义的默认值
3. 定义直觉性捷径
4. 视觉布局基于真实世界
5. 以不断进展的方式揭示信息
保持界面一致
1. 允许用户将当前任务放在有意义的语境中
2. 在应用系列内保持一致性
3. 不改变用户熟悉的用户交互模型
11.5 实现工具
用户界面工具箱或用户界面开发系统（UIDS）
11.6 设计评估
- 专家评审：启发式评审、指导文档评审、一致性检查、认知尝试、正式的可用性评审
- 可用性测试
Ch13 软件测试
13.1 软件测试基础
目的
1. 测试是为了发现错误
2. 好的测试用例是可能找到尚未发现的错误的用例
3. 成功的测试是找到了了尚未发现的错误的测试
软件测试的基本原则（理解）
- 测试可追溯到用户需求
- 在测试开始前进行测试计划
- Pareto 原则可用于软件测试
- 从小规模转向大规模
- 穷举测试不可能
- 由第三方承担测试
- 包括合理和不合理耳朵输入条件
- 严格执行测试计划
- 对每个测试结果全面检查
- 妥善保存测试计划、测试用例、出错统计、分析报告
- 检查程序是否做了不该做的事
- 规划测试时不要设想程序不会出错
13.2 白盒测试
又称结构测试，检查所有逻辑路径是否正确工作，主要用于对程序模块测试
1. 程序模块中所有独立路径至少执行一次
2. 对所有逻辑判定的取值（T/F）至少测试一次
3. 上下边界及操作范围内所有循环
4. 测试内部数据结构的有效性
13.3 黑盒测试
又称行为测试，不考虑内部，检查功能是否符合需求
1. 不正确或遗漏的功能
2. 接口错误
3. 数据结构错误或外部信息访问错误
4. 性能错误
5. 初始化和终止错误
13.4 测试策略
V 模型
系统工程------------------系统测试
＼ ／
需求分析------------确认测试
＼ ／
设计---------集成测试
＼ ／
编码---单元测试
单元测试（了解）
又称模块测试，对软件构件或模块进行测试
单元测试内容
1. 接口
2. 局部数据结构
3. 边界条件
4. 独立路径
5. 错误处理路径
单元测试规程：为被测模块开发驱动程序和桩模块
集成测试
- 非增量集成测试和增量集成测试
- 自顶向下集成测试
- 自底向上集成测试
- 策略选择：结合自顶向下和自底向上策略，成为三明治测试
- 回归测试
确认测试
- 确认测试的标准：以软件需求规约为依据
- 软件配置评审
- α 测试和 β 测试
系统测试
- 回复测试
- 安全保密性测试
- 压力测试（强度测试）
- 性能测试
13.5 面向对象测试
语境对测试的影响
1. 单元：编译执行的最小部件，不会指派给多个设计人员开发
2. 封装：给测试带来困难
3. 继承：子类继承的操作要重新测试
4. 多态性：测试覆盖所有实现方法
5. 基于消息的通信：自顶向下和自底向上集成策略不适用与面向对象软件测试
测试策略：基于线程的测试和基于使用的测试 测试用例设计
1. 传统测试用例仍坦克用
2. 类测试
3. 类间测试
4. 基于场景的测试
13.6 测试完成标准
测试过程中单位时间内发现错误数目的曲线
上升时不应停止测试，下降时可以停止测试
13.7 调试
- 蛮力法：设置断电，打印存储内容
- 回溯法：反向跟踪控制流，找到错误根源
- 原因排除法：分为归纳法和演绎法。归纳法收集证据，提出假设；演绎法从原理出发，假设所有原因再进行排除
Ch15 软件维护与再工程
15.1 软件维护
软件维护的概念（了解）
定义：交付后，修改软件系统或部件以排除故障、改进性能或其他属性、适应环境的过程
分类
1. 纠错性维护
2. 适应性维护
3. 改善型维护
4. 预防性维护
维护问题
1. 难以理解他人代码
2. 文档没有或缺失
3. 没有原来的开发人员提供解释
4. 设计时没有考虑修改问题
5. 工作没有吸引力
维护成本
M = p + Ke^(c-d)
M=维护总工作量，p=生产性工作量，K=经验常数，c=软件复杂度，d=维护人员对软件的熟悉度
维护过程
- 维护组织
- 维护过程
- 维护记录
- 维护评价
软件可维护性（理解）
指理解、改正、调整、改进软件的难易程度。
影响因素
1. 可理解性：理解软件的结构、接口、功能、内部过程的难易程度
2. 可测试性：测试和诊断软件错误的难易程度
3. 可修改性：修改软件的难易程度
4. 可移植性：程序转移到新的计算环境的难易程度
软件可维护性评审 提高可维护性的方法
1. 确定质量管理目标和优先级
2. 使用提高软件质量的技术和工具
3. 使用可维护性较高的升序设计语言
4. 完善程序文档
5. 进行质量保证审查
15.2 再工程技术
逆向工程：在软件生存周期中，将软件的某种形式描述转换成更抽象的活动
重构：同一抽象级别上转换系统的描述形式
设计恢复：接枝共聚从程序中抽象出数据结构设计、体系结构设计、过程设计
再工程：在逆向工程所获信息的基础上修改或重构已有的系统，产生一个新的版本，为遗留系统转化为科演化系统提供可行途径
Ch16 软件项目管理
软件项目成功率低的原因可能是项目管理能力太弱。
将项目管理思想引入软件工程领域，形成软件项目管理
16.1 软件项目管理概述（了解）
通过项目经理和项目组织的努力，运用系统理论的方法对项目及资源进行计划、组织、协调、控制，以实现项目的特定目标
基本内容为：
- 项目定义
- 项目计划
- 项目执行
- 项目控制
- 项目收尾
关注点
- 人员：项目管理人员、高级管理人员、开发人员、客户、最终客户
- 产品：周境、信息目标、功能和特性
- 过程：客户交流、计划、风险分析、构造及发布、客户评估
- 项目：明确目标及过程、保持动力、跟踪进展、做出聪明的决策、项目总结
内容
- 启动软件项目
- 项目组织
- 项目计划
- 软件度量：为软件过程和软件本身定义测量方法和标度，以改进过程、提高产品质量
- 项目估算
- 风险管理
- 进度安排
- 追踪与控制
- 软件配置管理（SCM）
16.2 软件度量
面向规模的度量
利用软件的规模对软件属性进行度量的方法
用常用程序代码行（LOC）或千行代码（1000LOC）来衡量
面向功能的度量（掌握）
功能点度量
1. 计算信息域特征值CT
2. 计算复杂度调整值F
3. 计算功能点FP：FP = CT*(0.65+0.01*F)
扩展的功能点度量：信息域中增加算法特征，使用特征点度量
基于规模与居于功能度量的比较：代码行和功能点的关系依赖于实现软件采用的程序设计语言和设计质量
软件质量模型
- McCall 模型：软件质量要素、软件质量要素评价准则
- GB/T 16260 质量模型
- ISO/IEC 25010 质量模型
16.3 软件项目估算
估算方法
1. 基于已完成的类似项目估算
2. 基于分解技术估算
3. 基于经验估算模型的估算（IBM估算模型、CoCoMo模型、Putnam模型）
软件可靠性估算
1. 错误植入法
2. 分别测试法
3. 软件平均故障间隔时间估算
16.4 项目进度管理
- 划分
- 相互依赖性
- 时间分配
- 工作量确认
- 定义责任
- 定义结果
- 定有里程碑
16.5 风险管理
- 风险标识
- 风险预测
- 风险评估
- 风险管理和监控：风险避免、风险监控、风险管理及监控计划
16.6 软件项目的组织
- 尽早落实责任
- 减少交流接口
- 责权均衡
组织结构的模式
1. 按项目划分的模式
2. 按职能划分的模式
3. 矩阵形模式
程序设计小组的组织形式
1. 主程序员制小组
2. 民主制小组
3. 层次式小组
人员配备
1. 各类开发活动所需人员
2. 配备人员的原则
3. 项目经理的要求
4. 软件人员的素质要求
16.7 软件质量管理
- 软件质量保证
- 软件评审
16.8 软件配置管理
- 计算机软件配置项
- 软件配置
- 配置管理
- 版本
- 发布
- 基线
- 变更控制
- 配置审核
- 配置状态记录
