笔记

第二章 软件工程(Software Engineering)

一、软件工程基本概念(Defining the Discipline)

1.软件工程定义
(1)The application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software; that is, the application of engineering to software.
(2)The study of approaches as in (1). 关键词：
- systematic, disciplined, quantifiable
- development, operation, and maintenance

2.软件工程特点
（1）系统化(systematic)：应用系统思维思考问题。
（2）遵守纪律(disciplined)：遵守若干规则。
（3）定量(quantifiable)：定量研究贯穿软件工程全过程。

3.软件工程——层次化技术
（1）高质量目标(a quality focus)
（2）过程模型(process model)：一种高质量的路线图(road map)，保证及时、高质量的结果。
（3）方法：包括需求分析、设计、测试、构造等，即如何构造软件。
（4）工具：CASE(Computer-Aided Software Engineering)

二、软件过程(Softwar Process)

1.公共过程框架(Common Porcess Framework)
- 定义了过程由哪些要素组成。
- 由若干框架活动(Framework Activities)组成。

2.框架活动(Framework Activities)
- 工作任务(work tasks)
- 工作产品(work products)
- 关键点、考核物(milestones & deliverables)
- 检查点(QA checkpoints)

3.普适性活动(Umbrella Activities)
- 项目管理(Project management)
- 质量保证(Quality assurance)
- 工作产品生产(Work product production)
- 评估(Measurement)
- 正式技术评审(Formal technical reviews)
- 配置管理(Configuration management)
- 可重用性管理(Reusability management)
- 风险管理(Risk management)

4.通用过程框架(Generic Process Framework)
(1)交流(communication)：客户沟通、需求汇总。
(2)规划(planning)：建立工程计划，描述技术风险，列举资源需求，定义工作规划。
(3)建模(modeling)：建立模型，以帮助开发者和用户理解需求、软件设计。
(4)构造(construction)：代码生成、测试。
(5)部署(deployment)：软件部署（如：制作安装包、安装程序，写指导文档，培训等；云时代需将软件部署至云上，部署更为复杂）

5.过程适配(process adaptation)——适应性的过程改造
- activaties, actions and tasks的总体流程(overall flow)，及其内在迁移
- 每个框架活动内部，动作、任务定义的程度
- 工作产品被识别、需求的程度
- 应用质量保证的方式
- 进行项目追踪和控制的方法
- 过程描述细节和严密性的程度
- 消费者参与工程的程度
- 软件团队的自主权(autonomy)
- 团队组织和角色的规定

三、软件工程实践(Software Engineering Principle)

1.实践关键
（1）理解问题(communication + analysis)
（2）解决方案规划(modeling + software design)
（3）执行计划(code generation)
（4）检查结果的精确度(testing + quality assurance)

2.一般原则
（1）用户思维：软件工程的存在原因——为用户提供价值。
（2）大道至简：Keep it Simple, Stupid
（3）不忘初心：Maintain the Vision
（4）换位思考：What you produce, others will consume
（5）面向未来：Be open to the future
（6）谋划复用：Plan ahead for reuse
（7）多思考：Think

3.管理误区(management myths)
（1）规章制度需要依靠质量保证手段进行落实。
（2）给进度落后的项目添加人手，反而可能进一步延迟项目进度。
（3）软件项目外包，并不意味着完成了一切。

4.客户误区(consumer myths)
（1）需求定义必须足够详细，项目规划必须完善、充分。
（2）随着需求的不断变化，软件的相应更改不可以轻易进行，而是更改代价不断上升。

5.实践者误区
（1）并非写好程序，能够跑起来，就完成了所有工作。
（2）能工作的程序只是软件配置(configuration)的一部分，还包括文档、数据等。
（3）软件工程的文档并非无用，而是让产品更具有质量，生命周期更长。

第三章 软件过程结构(Software Process Structure)

一、一般过程模型(A Generic Process Model)

1.软件过程框架
- 框架(framework)
- 框架活动(framework activity)
- 若干动作(action)及其相应任务集

2.过程流(process flow)
- 交流(Communication)
- 规划(Planning)
- 建模(Modeling)
- 构造(Construction)
- 部署(Deployment)
（1）线性(linear)过程流

（2）迭代(iterative)过程流

（3）演化(evolutionaru)过程流

（4）并行过程流(parallel)
- 例如：产品定义与建模并行进行。

二、过程模式(process patterns)

1.过程模式
- 定义了一组由活动、动作、工作任务、工作产品和相关行为构成的集合。

2.模板
- 提取共性，定义过程模式。

3.一般软件模式的元素
- 有意义的模板名
- 目标
- 类型：任务模式、Stage模式、Phase模式
- 初始上下文：使用该模板的先验条件
- 解决方案：如何正确实现该模式
- 结果上下文：模式正确实现后，产生的结果
- 相关模式
- 已知使用/例子：模式可以应用的领域

三、过程评价(process assessment)

1.过程评价：对软件过程进行检验和评价。
- 过程评价 引导 能力判定
- 过程评价 引导 软件过程改进
- 能力判定 促进 软件过程改进

2.CMMI(The Capability Maturity Model Integration)标准
（1）背景
- 由CMU软件工程学院提出
- 评价和指导企业软件工程的能力与成熟度

（2）级别
- 级别0-不完整(Incomplete)：未执行软件过程，或不能完成所有本级别目标。
- 级别1-执行级(Performed)：软件过程完整。
- 级别2-管理级(Managed)：顾客积极交互，任务和过程受到监督、回顾和评估，分析是否与过程描述一致。
- 级别3-定义级(Defined)：管理和工程过程文档化、标准化，融入组织级别的软件过程。
- 级别4-量化管理级(Quantitatively Managed)：软件过程和产品能够通过细节化的评估，进行量化理解和控制。
- 级别5-优化级(Optimizing)：通过过程和新概念测试得到的反馈，进行持续的过程改善。

第四章 过程模型(Process Models)

一、惯例模型(prescriptive models)

1.惯例过程
- 对于软件工程，定义了一些有序的方法。

2.问题
（1）惯例模型如果讲究结构和顺序，能否适应软件世界的变化？
（2）如果拒绝传统的过程模型（及其顺序），是否可能实现协调和一致？

3.惯例模型——瀑布式模型（线性模型）

• 沟通、规划、建模、建设、部署逐步执行。
• 优点
  • 简单
• 缺点
  • 实际工程很少遵从顺序流。
  • 用户一般不能清晰地说明所有需求，因此沟通阶段耗时较长。
  • 最后才能得到工程结果，反馈不及时。
• 适用情况
  • 需求明确，更改少的情形，如工程实施项目。

4.瀑布式模型的改进（V模型）

• 设计步骤：需求建模->体系结构设计（高层）->构件设计（底层）->代码生成
• 测试细化：单元测试、整合测试、系统测试、接受性测试，分别与四个设计步骤对应。

5.增量模型

• 一个增量相当于一个子流程(subprocess)。
• 后一增量在前一增量基础上进行，无需等待前一子流程结束。
• 优点
  • 资源利用更充分。

6.增量模型——快速应用部署(RAD, Rapid Application Deployment)模型

• 不同队伍可以并行进行建模、构建等工作。
• 各队伍工作最终打包并部署。
• 好处
  • 快速开发产品。
• 要求
  • 系统正确得到模块化，各模块解耦，不能有太多的交互。
  • 人力资源充足。

7.演化式模型——原型（Prototyping）系统

• 用户提意见->快速规划->快速设计
• 好处
  • 适合进行需求分析（如：只设计界面，不实现具体功能）、关键技术攻关。

8.演化式模型——螺旋(Spiral)模型

• 定义目标、约束和可选方案->可选方案评价->开发、验证、方针->下一阶段的需求规划、生命周期规划
• 适合大型、高要求的模型，时间周期较长。

9.演化式模型——并行模型

- 对于每个活动、动作和任务，定义了一系列引发状态转移的事件。
- 对于客户-服务器应用尤其适用。
- 定义一组活动的网络(a network of activities)，而非事件的线性序列。
- 注重高质量，但是灵活性、可扩展性、开发速度受影响。

二、专用过程模型(Specialized Process Models)

1.基于构件(component)的开发
- 重用作为一个开发目标时，可以应用的过程模型。

2.形式化方法(formal methods)
- 强调需求的数学声明(mathematical specification)。

3.面向客面(aspect)的软件开发

三、统一过程(The Unified Process)

1.定义
- 用户案例(use-case)驱动、以体系结构为中心、迭代式、增量式的软件过程。
- 由统一建模语言(UML, Unified Modeling Language)进行一致化(align)。

2.阶段

• 开端(Inception)：沟通阶段、规划阶段。
• 详尽(Elaboration)：规划阶段、建模阶段。
• 构造(Construction)：构造阶段。
• 迁移(Transition)：构造阶段、部署阶段。
• 产出(Production)：发布、增量开发。

3.每个步骤的产品——面向对象
[注]软件需求分析、软件设计部分均会详细讲解。

四、人和团队过程模型(Personal and Team Process Models)

1.个人软件过程(PSP, Personal Software Process)
- 规划
- 高层次设计
- 高层次设计回顾(review)
- 开发
- 事后反思(postmortem)

2.团队软件过程(TSP, Team Software Process)
- 涉及团队自组织、文化建设、投入与奉献精神等理念。

第六章 软件工程的人的因素(Human Aspects of Software Engineering)

一、软件工程师的特点

• 责任心、敏锐意识、勇于承认错误、提供建设性意见、抗压(Resilient under pressure)、公正、细度、实在(Pragmatic)

二、软件工程心理学(Psychology)

1.软件工程行为模型(Behavioral Model)

• 商业环境：通过组织化行为进行管理
• 企业：通过组织化行为进行管理
• 项目：强调团队能动性
• 团队：强调团队能动性
• 个人：强调认知、动力

2.团队跨界沟通角色
- 外联员(Ambassador)
- 侦查员(Scout)
- 守护员(Guard)
- 安检员(Sentry)
- 协调员(Coordinator)

三、软件团队

1.高效团队的意识
- 目标意识
- 参与意识
- 信任意识
- 改进意识
- 团队成员技能的多样性

2.避免团队“毒性”
- 凝固(frenzied)的工作氛围
- 高度沮丧(high frustration)，矛盾重重
- 管理不善，协同困难(fragmented or poorly coordinated procedures)
- 分工不明
- 连续失败，缺失信心

四、团队结构

1.组织范式(Organizational Paradigms)
- 封闭范式(Closed paradigm)：根据传统权限层次，构建团队。
- 随机范式(Random paradigm)：松散地进行团队组织，依赖于团队成员的个人意愿。有利于激发创新意识，但效率不一定高。
- 开放范式(Open paradigm)：结合封闭范式的一部分控制权，以及随机范式产生的创新性特点。
- 同步范式(Synchronous paradigm)：依赖于问题的自然分解(compartmentalization)，组织团队成员解决问题的不同方面。

2.影响团队组织方式的因素
- 问题困难程度：问题较难时，随机范式更有利于创新。
- 程序规模：规模较大时，管理难度上升，封闭范式更合适。
- 团队生命周期 - 问题的模块化程度：模块化程度越高，越自由；程度越低，越需要管理权。
- 待建立系统的质量和可靠性
- 交付时间是否紧张
- 项目对通讯的要求：通讯要求越高，封闭范式越适用。

五、敏捷团队(Agile Team)

1.一般敏捷团队
- 强调个人能力、团队协作都是成功的重要因素。
- 人比过程重要，策略比人重要。
- 可以进行自组织，快速适应问题及其变化，高效进行自主调节。
- 计划最小化，仅受商业需求、组织标准限制。

2.XP团队价值
- 沟通
- 简单化
- 反馈
- 勇气、原则
- 尊重

六、社交媒体的影响

1.博客(blogs)：团队成员、消费者间进行信息共享。
2.微博客(microblogs)：允许实时信息的发送。
3.在线论坛(targeted on-line forums)：提问、收集回答。
4.社交网站(social networking sites)：允许开发者共享信息。
5.social book marking

七、使用云进行软件工程开发

1.好处
- 随时随地访问软件产品
- 去除了设备依赖性
- 对分布、测试软件提供了便捷的路径
- 允许某个工程师的软件工程开发信息为整个团队共享

2.担忧
- 可靠性、安全风险
- 内部互操作问题
- 云服务强调可使用性、性能，通常与安全、隐私、可靠性产生冲突。

八、协作工具(Collaboration Tools)

• 命名空间(Namespace)：允许安全的、隐私的存储或工作产品。
• 日历(Calender)：记录项目事件。
• 模板(Templates)
• 标准支持(Metrics support)：允许团队成员贡献的量化评价。
• 沟通分析(Communication Analysis)：追踪信息，挖掘能解决问题的范式。
• 手工艺品（代码产出）聚类(Artifact Clustering)：发现产品之间的关联。

九、全球化团队(Global Team)

1.挑战
- 问题复杂性
- 决策的不确定性与风险
- 与决策有关的工作，可能对其他项目产生影响。
- 不同的视野会带来不同的结论。

2.影响全球软件开发团队的因素

• 沟通问题(communication)
• 障碍与复杂性(Barriers and Complexity)
• 协调(coordination)

第七章 引导实践的原则(Principles that Guide Practice)

一、软件工程知识(Software Engineering Knowledge)

1.3-year half life：现有知识在3年内可能过时(obsolete)一半。

2.引导过程的原则(Principles that guide the process)
- 敏捷化(be agile)
- 每一步追求高质量(focus on quality at every step)
- 活学活用(be ready to adapt)
- 建立高效团队(build an effective team)
- 建立沟通、协调机制(establish mechanisms for communications and coordination)
- 管理变化(manage change)
- 风险评估(access risk)
- 创造能为他人提供价值的工作产品(create work products that provide value for others)

3.引导实践的原则
- 分治(divide and conquer)
- 理解抽象(abstraction)的作用
- 努力追求一致性(strive for consistency)
- 关注信息的传输(transfer)
- 建立高效模块化(effective modularity)的软件
- 寻找模式(pattern)
- 尽可能从不同视角表示问题及其解决方案
- 记住某些人需要维护软件

4.沟通原则
- 倾听
- 在交流之前做准备
- 一些人需要促进(facilitate)沟通活动
- 面对面沟通是最好的
- 记笔记、用文档记录决策
- 努力追求协作
- 保持专注，对讨论进行模块化
- 画图表示不够清晰的内容
- 前进(move on)
- 协商最好是双赢的

5.规划原则
- 理解项目的范围(scope)
- 让顾客参与规划活动
- 记住规划是迭代的
- 基于自己掌握的内容进行评估
- 进行规划时需考虑风险
- 现实
- 在定义规划时，调整粗细度(granularity)
- 定义如何保证质量
- 定义应该如何容纳(accomodate)变化
- 频繁追踪计划，根据需要进行调整

本章其余内容参见课件、教材，不再记录。

第三十一章 项目管理概念

一、四个P的概念

1.人(Person)：成功项目的最重要元素。
2.产品(Product)：最终开发出的软件。
3.过程(Process)：框架活动、软件工程任务集合。
4.项目(Project)：保证产品实现的所有工作，包括了资源、协调、宣传等。

二、利益相关者(Stakeholder)

1.高级管理员(senior managers)：部门领导，定义项目的商业目的，提供资源（人、财、物）。
2.工程（技术）管理员(project(technical) managers)：项目领导，对进行软件开发的实践者(practitioners)进行规划、鼓励、组织和管控。
3.实践者(practitioners)：技术人员，包括系统架构师、系统分析员、程序员、测试员、软件配置经理等，带有完成工程/产品的必需技能。
4.客户(customers)：说明待开发软件的需求，以及产品定义。
5.终端用户(end-users)：软件发布后，与软件进行交互的人员。
[例]疫情上报系统中，医院是客户，呼吸科医生是终端用户。

三、软件团队管理要素

1.如何领导
2.如何组织
3.如何协作
4.如何激励
5.如何创造好的想法

四、团队领导——MOI模型

1.激励(motivation)：（通过push or pull的手段）激励技术人员，激发出技术人员最好潜质的能力。
2.组织(organization)：塑造现有过程（或：发明新过程），使得最初的理念能够转化为最终产品的能力。
3.想法/创新(ideas or innovation)：鼓励人们即使受到特定软件产品或应用的约束，也能创造，或者感到有创造力。

五、软件团队结构的选择

1.待解决问题的规模
2.产出程序的规模
3.软件团队的生命周期（软件团队共事的时间）
4.问题模块化的程度
5.软件质量和可靠性的要求
6.发布日期的刚性(rigidity)
7.团队交互程度
[注]避免团队毒药、敏捷团队：见第6章。

六、软件团队协作与沟通

1.正式非个人方法(formal, impersonal approches)：包括软件工程文档、项目计划、项目管理工具、项目里程碑、需求变换、错误跟踪报告等。
2.正式人际程序(formal, interpersonal procedures)：包括状态回顾会议(status review meetings)、设计和代码检查(design and code inspections)。
3.非正式人际程序(informal, interpersonal procedures)：包含以信息传播(dissemination)、问题解决、需求搭配(collocation)等为目的的小组会议。
4.电子交流(electronic communication)：电子邮件、视频会议等。
5.人际网络(interpersonal networking)：同团队成员进行非正式讨论、同项目以外具有经验或视野，能够帮助团队成员的人员进行讨论。

七、产品范围

1.软件上下文(Context)：软件运行的环境，软件适用于的大型系统（或商业上下文），以及上下文带来的限制。
2.信息目标(information objectives)：要求怎样的额内容作为输入数据对象，以及软件会产出何种顾客可见的输出数据对象。
3.功能与性能(function and performance)：软件将输入数据转化为输出的功能，以及软件比较有特色的性能特点。
4.可靠性、接口与安全性：软件工程范围必须是不模糊的，并且在管理、技术层面都易于理解。

八、问题分解(Problem Decomposition/Partitioning/Problem Elaboration)

1.定义范围后，进行问题分解：
- 分解为构成要素功能(constituent functions)
- 分解为用户可见的数据对象
- 分解为问题类别形成的集合(a set of problem classes)
2.分解过程一致持续，直到所有功能(functions)或者问题类别(problem classes)完成定义。

九、过程管理

1.定义过程框架后，进行下列与过程相关的定义与思考。
2.考虑项目特征
3.定义严谨(rigor)程度(the degree of rigor required)
4.对于每个软件工程活动，定义任务集。
5.任务集
- 软件工程任务
- 工作产品
- 质量检查点
- 里程碑

十、项目陷入困境的一些原因

1.软件团队不理解用户需求
2.产品范围定义不佳
3.更改、变化管理不佳
4.选定的技术发生变化
5.商业需求变化或定义不明确
6.截止日期不现实
7.用户抗拒(resistant)
8.失去赞助(sponsorship)或从未正确获得赞助
9.项目缺乏具有合适技能的人员
10.管理者/开发者经验不足

十一、项目共识

1.基于正确的出发点：努力理解问题，设定合理的目标和期望。
2.保持动量
3.追踪进展
4.进行聪明、简单的决策
5.进行事后分析

十二、项目的本质

1.五个W
- 为什么开发软件系统
- 做什么
- 何时完成
- 谁负责
- 团队在哪里

2.两个H
- 项目在技术上、管理上怎么完成
- 各类资源（人、软件、工具、数据库等）各需要多少

十三、关键过程实践

1.风险管理
2.经验代价和调度评估(schedule estimation)
3.基于标准(metrics-based)的项目管理
4.挣值管理追踪(earned value tracking)
5.针对质量目标的错误追踪
6.People Aware Project Management

第八章 需求理解

• 概念设计—>方案设计->构造->验收，每个阶段之间都存在“失真”的问题。
• 需求分析：将用户的抽象想法，勾勒为相对具象化的内容。

一、需求工程

[定义]应用工程化的方法，系统、全面地理解用户需求。

1.开端(Inception)
询问一系列问题，以建立下列属性：
- 问题的基本理解。
- 需要解决方案的人群特点。
- 解决方案的本质，如用户规模、移动端/Web端等大致情况。
- 建立沟通、协作机制。

2.需求获取(elicitation)
- 与所有相关人员进行充分的交流、沟通，得知用户需求。

3.需求细化(elaboration)
- 利用分析模型等手段，将用户的抽象需求细化为具象表达、无歧义的模型。

4.协商(negotiation)
- 综合所有人的意见，与用户谈判，查漏补缺，得到取得一致性认可的模型。
- 用户签字画押。

5.需求规格说明书(specification)
- 文档，说明use case、动态行为、约束等内容。
- 模型（如：UML建模语言及其相关模型）
- 数学公式
- 原型系统(prototype)
- 原则：能够清晰表达问题。

6.确认(validation)
- 针对所有文档、模型进行查漏补缺，找出矛盾、错误、缺漏之处。
- 进行协商，取得一致认识。

7.需求管理
- 模型不能停留在纸面上，而是专人进行质量管理，跟踪每个需求在各个环节是否得到实现。

二、开端(Inception)

1.识别利益相关者，确定进行需求沟通的对象群体。

2.发现各种各样的观点。

3.朝着协作的方向前进。

4.获得上下文无关的问题
- 谁是请求这份工作的人？
- 谁是解决方案的使用者？
- 一个成功的解决方案，会带来怎样的经济效益？
- 为了获得解决方案，是否需要其他资源？

三、需求获取(eliciting requirements)

1.由软件工程师、顾客一起开会，获取需求。

2.建立准备和参与的规则。

3.建议记录会议议程(agenda)。

4.主持人对需求获取会议进行控制，身份可以是顾客、开发人员或外部人员。

5.使用“定义机制”，具体的形式为工作表(work sheets)、挂图(flip charts)等。

6.建设软件最困难的部分——决定应该建设什么内容
- 范围问题
- 理解问题
- 波动(volatility)问题

7.需求获取流程图

四、质量功能部署(Quality Function Deployment)

1.功能部署(function deployment)
- 定义了系统每个功能对于消费者的“价值”。

2.信息部署(information deployment)
- 识别数据对象、事件。

3.任务部署(task deployment)
- 检验系统的行为。

4.价值分析(value analysis)
- 定义了需求的相对优先级。

5.三类需求
- 标准需求(normal requirement)：如直播时共享视频、共享PPT。
- 期望需求(expected requirement)：直播系统的稳定性。
- 惊艳的需求(exciting requirement)：基本没有网络延迟，超出预期。

五、非功能型需求(NFR, Non-Functional Requirements)

1.定义
- 质量要求、性能要求（如tps, transactions per second等）、可靠性、安全性（加密、解密、用户登录key、数字证书）、开放性、出错处理等。

2.二阶段过程——决定哪些非功能型需求是兼容的
（1）第一阶段
- 创建矩阵，每个NFR作为一个列标，系统SE guideline作为行标。
（2）第二阶段
- 团队使用一系列决策规则，对NFR进行优先级排序。
- 通过将(NFR, guideline) pair分类为互相补充(complementary)、重叠、冲突、独立四类，决定实际上要实现哪些NFR。

六、启发式工作产品(Elicitation Work Products)

1.需求声明、可能性。
2.系统和产品的范围。
3.参与需求启发的用户列表。
4.系统的技术环境：移动端、Web端、工厂、办公室、边缘端等。
5.功能型需求，以及每个需求的约束条件。
6.使用计划：为系统或产品在不同的操作条件下的用途提供见解。
7.原型：用于用于更好地定义需求。

七、用例(Use Cases)

1.定义：一组用户场景，用于描述系统的用途。
2.特点：简单、高效地实现与用户的交流，用户容易理解。
3.每个用例图从角色(actor)的角度出发，描述一个或多个角色（角色：人/设备）怎样与系统进行交互。
4.每个场景回答的问题
（1）主要actor和次要actor：老师、学生。
（2）actor的目标：成功开设网课。
（3）故事发生的先决条件：完成课程建设。
（4）actor执行的任务、功能：上传课件，点选课件和课程目录后，将课件上传到相关区域。
（5）扩展(extension)：文件预览、文件排序等。
（6）actor交互行为的变化性(variation)：除了在web端完成操作，在移动端是否可以完成。
（7）actor获得、产生和改变的系统信息。
（8）actor是否需要将外界信息的变化告知系统。
（9）actor希望从系统中获得的信息。
（10）actor是否希望被告知一些意料之外的变化。

[例1]SafeHome——家用安防系统
（1）需求
- 实时监控：传感器实时监控环境，包括非法入侵、火警等事件。
- 快速告知、快速处理

（2）用例图(Use-Case Diagram)
- 场景：圆圈
- 用户：小人
- 设备：小方框
- 场景的集合：大方框

（3）用户
- 装配、解除系统
- 通过互联网访问系统
- 对警报事件进行反馈
- 遇到错误条件

（4）系统管理员
- 配置传感器以及相关的系统特性

（5）传感器
- 配置传感器以及相关的系统特性
- 对警报事件进行反馈
- 遇到错误条件

八、需求模型的建立

1.需求模型的元素
（1）基于场景的元素
- 用例、用例图
- 特定上下文之内的事件序列
（2）基于类的元素
- 类图
（3）行为元素
- 状态图：形容系统、实体的状态和迁移变化
（4）基于流的元素
- 数据流图、控制流图
- 一种结构化的描述方法

2.类图

[例2]传感器类的属性、成员函数

3.状态图——对大型系统/某个类的状态及其变化的描述
- 状态名
- 状态变量
- 状态活动

[例3]安防系统——读取命令状态
- 状态名：读取命令。
- 状态变量：包括系统参数、系统状态、显示信息等。
- 状态活动：读取用户输入、理解用户输入。

4.状态图及其转移
- 箭头：表明哪些事件能够触发相应的状态迁移。

[例4]复印机状态及其转移

九、分析模式

1.模式名
2.目的
3.动机：模式可以如何用于解决问题。
4.输入、输出上下文、影响模式使用的外力(force)。
5.结果
6.设计
7.例子
8.相关模式

十、需求协商

目的：不同的人有不同的观点，需求协商的目的是取得不同人群在需求上的一致性。
1.识别关键的利益相关者(stakeholder)，这些利益相关者将参与到需求协商过程中。
2.定义利益相关者的底线，以及获利的条件。
3.协商，以获得双赢的需求。
若各方面无法达成一致，则项目失败的可能性非常高。

十一、需求确认

1.确认每个需求都跟系统/产品的总体设计目标相一致。
2.确定每个需求说明的抽象层次是否合理，是否某些需求的说明在当前阶段已经涉及到技术细节的层面（这是不合理的）。
3.确认需求必要性。
4.需求无歧义、不模糊。
5.需求归属(attribution)，即提出需求的人。
6.需求之间不能相互冲突。
7.在系统/产品的技术环境下，各需求是否可以实现。
8.各需求实现后是否可以测试。
9.需求模型是否正确地反映了系统的信息、功能和行为。
10.需求模式：是否被用于简化需求模型、是否正确地得到确认、是否与用户需求相符合。

十二、需求管理

需求管理在增量开发中尤其重要。
1.分布式debug：揭示错误及其原因。
2.运行时验证：判断软件是否与它的声明相符。
3.运行时确认：评估软件是否符合用户目标。
4.商业活动管理：评估系统是否满足商业目标。
5.升级与协作设计：在系统升级时，给利益相关者提供信息。

第九章 需求建模——基于场景的方法

一、需求分析回顾

1.目的
- 描述用户要求
- 为软件设计建立基础
- 定义一组可以被确认的需求

2.需求分析对软件工程师的作用
- 充分利用之前早期需求工程任务建立的基本需求
- 建立模型，以解释用户场景、功能活动、问题类及其关系、系统与类行为、数据流以及软件必须面临的约束。

3.桥梁作用
- 需求分析模型：系统描述和设计模型之间的桥梁。

二、需求分析原则

1.需求模型需要聚焦问题本质，关注问题或商业范围之内可见的需求，抽象层次相对高。
2.分析模型的每个元素，都要能够加深对软件需求的整体理解，对系统的信息领域、功能和表现提供深入理解，有这些用途才得以保留，否则都应丢弃。
3.延迟对技术架构、非功能模型的考虑，直到设计时才需考虑这些内容。
4.最小化系统的耦合度，实现高度模块化。
5.确保分析模型对所有利益相关者都有价值。
6.尽量简化模型。

三、领域分析

1.目的
- 从一个特定的应用领域，对普遍的需求进行识别、分析与详细说明，一般针对该应用领域内多个项目的重用(reuse)而进行。
- 实现对领域知识的重用。

2.领域分析过程图
- 领域知识->领域分析->领域分析模型
- 领域知识->领域分析：技术词汇、现有应用、消费者调查、专家建议、当前/未来的需求等。
- 领域分析->领域分析模型：分类方法、重用标准、功能模型、领域语言等。

3.举例
- 知识图谱：口罩、N95、医用外科口罩、一次性医疗设备

四、软件需求模型

1.基于场景的模型
- 用例文本
- 用例图
- 活动图
- 泳道图

2.面向流的模型
- 数据流图
- 控制流图
- 过程描述语言(Processing Narratives)

3.基于类的模型
- 类图
- 分析包
- CRC模型
- 协同图

4.行为模型
- 状态图
- 序列图

五、基于场景的模型

1.用例：简单地描述actor的操作，以及系统的工作。
- 需要写什么内容
- 写多少内容
- 描述的细节化程度如何
- 如何组织描述

2.场景：描述了系统的“使用线程”
- actor：代表了人或者设备在系统功能中的角色。
- user：在一个场景中，可以充当若干角色。

3.用例的开发
（1）主要actor和次要actor：老师、学生。
（2）actor的目标：成功开设网课。
（3）故事发生的先决条件：完成课程建设。
（4）actor执行的任务、功能：上传课件，点选课件和课程目录后，将课件上传到相关区域。
（5）扩展(extension)：文件预览、文件排序等。
（6）actor交互行为的变化性(variation)：除了在web端完成操作，在移动端是否可以完成。
（7）actor获得、产生和改变的系统信息。
（8）actor是否需要将外界信息的变化告知系统。
（9）actor希望从系统中获得的信息。
（10）actor是否希望被告知一些意料之外的变化。

六、活动图与泳道图

1.活动图：使用简图描述过程流，以对用例图进行补充。

2.泳道图：允许建模人员在表示由用例描述的活动流的同时，还能从活动角度，表明哪些actor或者分析类对动作负责。
- 角色：与泳道一一对应。
- 将活动图放到泳道上，可以清晰地知晓每个角色对应的动作。

3.活动图举例

4.泳道图举例

第十章 需求建模——基于类(class-based)的方法

分析类：用户能看懂，但并未精细到实现层次。
设计类：类别明晰，参数明确。

一、面向对象的基本概念

1.基本概念
- 类和对象
- 属性和操作
- 封装和实例化
- 继承

2.面向对象任务
（1）识别类的属性和方法。
（2）寻找类与类的层次关系、纵向继承关系。
（3）寻找类与类的横向关联关系。
[例1]
书、教师、学生：具有横向关联关系。
（4）对于类之间的交互行为进行建模，一般用状态图、序列图进行表示。

二、类

1.类的抽象定义
- 模板
- 一般化(generalized)的描述
- 对一组相似物品的描述

2.元类/超类：可以延伸出子类，进行重载，建立了类与类的层次关系。

3.组成部分
- 类名
- 属性
- 操作（成员函数）

三、封装/隐藏

1.作用：对信息进行抽象，实现“信息隐藏”。

2.封装对象：数据、用于操作数据的逻辑过程。

3.思想：模块化、细节隐藏，仅展示对外行为，用简单的方式对复杂问题进行建模。

四、类的层次

[例2]
- 超类：家具
- 子类：沙发、椅子

五、基于类的建模

1.基于类的建模对下列内容进行表示：
- 对象：系统操控的对象。
- 操作（也叫方法、服务）：应用于对象，以实现操作。
- 类间关系（关联关系、层次关系）
- 类间协作

2.分析类的识别
- 检验对问题的自然语言描述，以识别分析类（具体细节稍后阐述）
- 使用“语法分析”，以识别潜在的类
- 识别每个类的属性
- 识别对属性进行管理的operation

3.潜在类的识别
- 名词：可能成为潜在类，也可能是某个类的一个属性。
- 动词：可能成为某个潜在类的成员函数（操作），也可能成为类与类之间的协作关系。

4.可能成为“类”的七种事物
（以教务管理系统为例）
- 外部实体(external entity)
- 出版社
- 事物(thing)
- 教材
- 事件(occurences/events)
- 开课
- 角色(roles)
- 教师、学生、管理者
- 组织单元
- 班级、学院
- 场地
- 教室
- 结构
- 存储开课相关信息的数据结构

六、潜在类的识别原则

1.信息保留（必要性）(retained information)
- 蕴含系统运行所需的必要信息，不可或缺。

2.动态行为(needed services)
- 类要具有动态行为，而不是简单的静态信息。

3.多个属性
- 类需要具有多个属性。

4.公共属性

5.公共操作

6.必要需求
- 必要需求可能成为潜在类。

七、类图

1.单个类别的类图

2.使用类图表达各类间的关系

- 上例为家庭平面布局图类FloorPlan。
- 允许在布局图中放置相机。
- 墙体是平面布局图的一部分。
- 窗户、门、墙段均被应用于墙体的构建。

八、类责任协同关系建模(CRC, Class Responsibility Collaborator Modeling)

1.分析类的“责任”
- 分析类的责任：即由该类封装的属性和操作。

2.分析类的协同
- 协同类：提供必要信息，以完成当前分析类的责任。

【例3】协同类

- 平面图需要包含墙、门和窗户的信息，需要与墙类进行协同。
- 展示摄像头位置，需要与摄像头类进行协同。

九、类的类别——按照功能分类

1.实体类
- 描述商业逻辑，如平面图、摄像头、墙类。

2.边界类
- 用于形成用户使用、软件实现之间的交互interface，如：输入框、控制面板等。

3.控制类
- 控制实体对象的创建、更新与销毁，管控其生命周期。
- 控制边界对象的实例化，以及从实体对象中获取信息的过程。
- 实现对象之间的复杂沟通。
- 对于对象之间、用户与应用之间传递的信息进行验证。

十、责任分配原则

1.系统智能需要分布到各个类别上，以最好地解决问题的需求。

2.每个责任需要尽可能一般化、普适化地进行陈述。

3.信息及其相关行为需位于同一个类之中。

4.关于同一个事件的信息需要局部化到某一个类中，而不是分布于多个类上。

5.在合适的情况下，责任需要由与之相关的类共同承担。

十一、协同

1.类实现自己责任的方式
（1）使用自身的操作，以处理自身的属性，完成特定的责任。
（2）通过类间的协同，实现责任。

2.协同：对类间关系进行识别。

3.常见的协同关系
（1）is-part-of：一类是另一类的一部分。如头部类是游戏玩家类的一部分。
（2）has-knowledge-of：知识关联关系。
（3）dependence：依赖关系，如玩家头部类、玩家身体类存在依赖关系。

十二、CRC模型回顾

1.参与者：所有参与者都被给予CRC模型卡片的一个自己。
- 能够协同的卡片应该被分开（同一个参与者不能持有两张可以协同的卡片）。

2.用例分类
- 用例场景，以及相应的用例图，都应该被分类。

3.回顾领导
- 发现一个命名对象，就把令牌(token)交给持有相应类卡片的参与者。

十三、类的关联与依赖

• 分析类的关联(association)
• 两个分析类间常常存在客户-服务关系。
• 关系的多样性：一对一、一对多等。

十四、分析包(analysis packages)

1.分析包：对于分析类、用例等进行分组，每个分组就是一个分析包。
- 硬件包
- 交互包
- 工具包

2.分析类的visibility
- 加号：公共类，即该分析类对其他分析包都是可见的。
- 减号：表明该分析类对其他所有包均不可见。
- #：表明只有某些给定的包，才能访问该分析类。

[例]安防系统分析包

第十一章——需求建模：行为、模式和网络/移动应用

一、行为建模

1.行为模型：表明软件对特定的外部事件（或刺激）作出的反应。

2.建立行为模型必须经历的分析步骤
- 评估所有的用例，以充分理解系统内部的交互序列。
- 识别出驱动交互序列的事件，以及事件与特定对象的关联关系。
- 对于每个用例，创建序列。
- 为系统建立状态图。
- 回顾行为模型，检验准确性、一致性。

二、系统状态的组成部分

1.状态：系统在特定事件下所处的可观测的情境，这种情境对系统行为进行了表征。

2.状态转移

3.事件

4.行为：事件发生、状态转移时，系统执行的动作。

三、状态的表示

1.类状态：系统执行功能时，系统内部各个类的状态。

2.系统状态：从系统外部观测得到的系统状态。

[例]控制面板状态图

[例]序列图——从角色的角度描述状态迁移

[注]控制面板状态图、序列图的关系，类似于活动图、泳道图之间的关系。

四、基于流的数据建模

1.独立地检验数据对象
2.聚焦于数据域
3.在消费者的抽象角度建立模型
4.表明数据对象之间的关联

五、数据对象

1.对象：由一组属性（数据项）进行描述，并将被软件系统进行操作。

2.各个数据对象可以被独立地识别，比如书可以被出版号独立识别。

3.每个数据对象在系统中都不可或缺。

4.数据对象通过属性（数据项）进行描述。

5.典型的数据对象
- 外部实体
- 物体
- 事件
- 角色
- 组织单元
- 地点
- 数据结构

六、数据对象之间的关系

1.关系：无法由系统计算独处，必须由系统记忆。

2.关系：可以存在关系实例。

3.对象的关联：可通过许多不同方式进行关联。

七、实体关系图(ERD, Entity Relationship Diagram)

1.势(cardinality)：一对一、一对多、多对多。

2.模(modality)：必需、可选。

[例]客户订单处理实体关系图

八、基于流的建模

1.作用：表明数据对象在系统中移动时，如何经历变换。

2.数据流图(DFD, Data Flow Diagram)：用于描述基于流的建模。

3.面向流的建模方法：一种较为传统的方法，认为整个系统由输入、处理、输出组成，表达能力不错，使用较多，可以是其他建模方法的补充。

4.常用场景：嵌入式软件、图像处理、神经网络架构图等，面向流程，适合使用数据流图。

九、数据流图

1.思想：每个基于计算机的系统，都是一个对信息进行变换的系统。

2.数据流图：一种图表示，用以描述信息流，以及数据从输入到输出进行流动时，经历的变换。

3.可以在任何抽象层次下，对系统或软件进行表示。

4.记号
（1）外部实体（方框）
- 数据的生产者/消费者
- 举例：人、设备、传感器、基于计算机的系统

（2）处理(Process)（圆）
- 数据变换（接受输入，进行一定的计算，产生输出）
- 举例：计算面积、展示图片

（3）数据流（箭头）
- 起点/终点：可以是外部实体、数据存储、处理等。

（4）数据存储
- 存储数据，以供未来使用。

5.DFD——层次化的建模方式
- 从顶层到底层，依次为level 0 ~ level n，抽象程度依次降低。
- 顶层：仅描述外部输入、输出。
- 越往底层，对“处理”的描述越详细。

6.DFD图的细化原则
- 给数据流箭头添加标签，每个图标都应该标注具有意义的名字。
- level 0：上下文级别，展示外部实体。
- 保持信息流的连续性。

十、处理详细说明(PSPEC, Process Specification)

• 形式：自然语言、图示、表格等。
  

十一、DFD构造案例

（第一步——构建level 0 DFD）
1.回顾数据模型，孤立数据对象，使用“语法分析”决定操作。
2.判定外部实体（数据生产者、消费者）。
3.建立level 0的DFD。

（第二步——细化）
1.对transform进行自然语言描述。
2.使用“语法分析”，进行下一级的transform。
3.保持数据流的连续性。 4.扩展率：1:5。

十二、流建模注意事项

1.每个气泡不断进行修正，直到它只完成一个任务。

2.随着层数的加深，扩展率下降。

3.一般做3-7个level。

4.截止条件：事件可以得到清晰的表达。

[注]
分析模型可以直接转换为设计模型。

十三、书写软件说明书(Software Specification)

十四、需求建模的模式

1.软件模式：对领域的经验总结。

2.需求建模模式：从领域出发，面向一个特定问题（如：电子商务，人、货、厂协调）

3.发现需求分析模式
- 依赖领域专家的经验总结。
- 使用一些工具、方法，这些方法是软件工程的研究范畴。

【例】电商系统，淘宝、天猫、京东、唯品会等。使用某些方法发现电商系统的共性，将其变为DFD，或者图形等，之后使用图挖掘(graph mining)方法，寻找大量流程的公共流程，以及各个图的公共子图，即找到了所需的模式。

十五、网络应用的需求建模

1.内容分析
- 浏览器超链接可以展示文本、语音、图像等信息，针对网络应用的特定特征进行分析。
- 类、数据对象的分析。

2.交互分析
- 分析网络应用的交互性。

3.功能分析
- 分析系统提供的功能。

4.配置分析(configuration analysis)
- 网络应用的性能受到服务器数量、位置的影响，并在开放环境中运行。

5.导航分析
- 分析超链接怎么组织、串联在一起。

十六、必须进行显式分析的场景

1.应用规模较大，较复杂。

2.利益相关者较多；开发者较多。

3.团队成员之前没有合作过。

4.应用的成功将会带来巨大的商业成功。

十七、内容模型

1.简介
- 从用例中提取
- 对系统的数据结构进行分析
- 识别每个内容对象的属性
- 识别内容对象、内容层次之间的关联。

2.关联表示
- E-R图
- UML

3.层次表示
- 数据树
- UML

[例]零件的数据树，表明了各个数据对象的关联性、层次性。

十八、交互模型

1.元素
- 用例
- 序列图
- 状态图
- 用户界面原型

2.每一个元素，都是一个重要的UML记号。

十九、功能模型

1.描述的内容
- 用户可见的功能
- 分析类内部的操作

2.建模方法
- 活动图
- 泳道图

二十、配置模型

1.服务侧
- 声明服务端的硬件、操作系统环境
- 服务端的内部操作
- 合理的界面、沟通协议，以及相关的共享信息

2.客户侧
- 浏览器配置
- 测试要求

二十一、导航建模

• 导航交互细节：搜索框、主菜单、链接错误的处理。

第十二章 设计概念

一、软件设计

1.好软件的特性
- 可靠(firmness)
- 有用(commodity)
- 舒适的使用体验(delight)

2.软件设计
- 原则、概念和实践的集合
- 软件原则：进行好的设计的经验总结。
- 概念：设计概念。
- 实践：面向特定应用（Web、客户端应用）体系结构设计、UI设计、构建设计等各个层面的一系列方法。

3.软件设计的任务
- 分析模型->设计模型

4.设计模型
- 数据/类设计：数据的静态表示，如数据结构。来源于class-based elements。
- 体系结构设计：系统分为哪些大的模块，彼此应如何进行联系。来源于flow-oriented elements和class-based elements。
- 接口设计(interface design)：用户界面、互操作、软硬件交互。了来源于flow-based, class-based, scenario-oriented elements。
- 构件设计(component design)：来源于class-based, behavioral, flow-oriented elements。

5.高质量设计的特征
- 必须实现所有显式需求，以及隐式需求（如：性能、美观、可靠性等）。
- 测试人员可读、可理解。

6.好的设计
- 好的体系结构
- 模块化
- 相互独立、交互简单

7.设计原则
- 设计过程不能钻牛角尖，应该具有宏观视角。
- 可追溯到分析模型。
- 新技术不要采用太多，否则软件可靠性可能降低。
- 减少软件设计、实际问题之间的鸿沟，尽量符合现实习惯、现实印象，使得用户容易理解、接受。如报税表单，应该跟现实表单十分相似，把现实表项作为输入框。
- 设计风格一致性。
- 容忍变化的空间。
- 优雅地衰退，优雅地面对问题。
- 设计和编程是两码事，可以暂时搁置某些细节，使用伪代码进行设计。

二、设计的概念

1.数据抽象

2.过程抽象

3.体系结构

4.模式（设计模式）

5.问题分解思想：复杂问题分解，有利于降低困难程度。

6.模块化：现在的软件往往较为庞大，变量、参数、关联关系很多，模块化是极其必要的；但是模块化程度过高，也会导致开发成本重新上升。

7.信息隐藏：与模块化关系较大。模块与模块之间通过接口进行交互，而对接口的内部逻辑并不关心。信息隐藏有利于更好地适应变化，减少更改带来的副作用，限制更改范围；有利于各模块更加独立，降低耦合程度。

8.逐步细化

9.模块度量——模块的大小、内容

10.功能独立性评估：模块完成单一事件，内聚，信息收敛程度应该尽量高，完成该事件的信息应该尽量位于模块内部；模块间交互应该尽量简单。

11.客面(aspect)：某个功能需要所有模块的交互/横切，比如安全、日志等。

12.重构(refactor)：不改变系统外部行为，对内部结构进行优化、调整。检验冗余、无用的设计元素、低效或不必要的数据结构与算法、设计错误。

三、面向对象的设计概念

1.设计类
- 实体类
- 边界类
- 控制类

2.继承

3.消息

4.多态

5.设计类的特征
- 完整性
- 原子性
- 高内聚
- 低耦合

四、设计模型

设计模型元素
- 数据元素
- 体系结构元素
- 接口元素
- 构建元素
- 部署元素

五、数据建模

1.设计目的
- 检验数据对象，数据内部结构、关联关系、持久化方式等。
- 关注数据域
- 在消费者级别进行抽象，建立模型。

2.数据设计
- 输入：来自分析模型的数据对象。
- 输出：数据结构、程序访问持久化存储的方式、数据库。

六、部署元素——使用UML图描述

1.描述表格

2.实例表格

[例]安防系统部署UML图

每个方框表示一个服务器。

第十九章 质量概念

一、质量

1.先验视角：只可意会，不可言传。

2.用户视角：按照终端用户的特定目标是否得到满足，对质量进行评估。

3.生产者视角：产品的设计要求是否得到实现。

4.产品角度：质量是产品的特定特征，如功能特征、外观、耐用性等。

5.基于价值的视角：消费者愿意为软件付出的费用。

二、软件质量

1.客户的指责：轻率的实践，工程师没有花太多心思，导致低质量软件。

2.开发者的指责：客户要求离谱，发布时间变化频繁。

3.软件质量必须满足的特性
- 设计质量：包含需求、说明、系统设计的模块化程度等。
- 符合质量：代码实现与设计的一致程度。
- 用户满意度 = 功能性的期望 + 隐性期望 + 软件交付周期与成本。

4.软件质量的定义：一系列有效的软件过程集合，用于创造有价值的产品，提供可以度量的价值。
- 有效软件过程
- 目的：创造有用产品
- 提供可以度量的评估方式

5.有效的软件过程
- 有效的软件实践活动
- 过程管理手段：回顾、测试、正式/非正式技术复审等。
- 支撑性活动：质量保证活动等。

6.目的——创造对于用户有价值的产品
- 提供用户需要的功能、内容和特性
- 可靠性较高
- 实现利益相关者的各类显性、隐形需求

7.生产者、消费者两方面价值
- 给软件开发者、用户均提供价值。
- 软件开发者：高质量软件能减少维护成本。
- 用户：高质量软件可以更好地满足需求，获得更大的商业价值。

三、软件质量的维度

1.性能质量：吞吐量、响应时间等。

2.特性质量：使用便捷性、舒适性。

3.可靠性：随时满足用户需求不宕机。

4.符合性：满足各类标准和用户需求。

5.持久性：可维护性、适应变化。

6.可服务性：出问题后快速进行服务和恢复。

7.美观性：好的软件应该比较美观。

四、质量的度量

1.用户问卷

2.定量的评价标准

五、软件质量困境

1.提升软件质量，也意味着成本的提升，如：时间成本、人力成本等。

2.good enough平衡点
- 在一定代价之下，具有一定质量，但仍然存在一些bug，或者非常用功能的缺失。
- 不影响大部分用户使用，常用功能健全。
- 大公司较为从容，小公司较为危险。

六、质量成本

1.预防成本
- 质量规划
- 正式技术复审
- 测试
- 训练：针对开发者、测试者等。

2.内部故障成本
- 重做
- 修复
- 失败模式分析

3.外部故障成本
- 舆情平息成本
- 产品召回和修复
- 客服热线

七、低质量软件

1.“撕裂”感

2.安全隐患

3.用户需求得不到满足，体验差

八、质量与风险

九、管理决策的影响

1.估算决策：估算多长时间可以完成项目

2.调度决策：各个阶段任务的安排、串接

3.风险决策：应对各类风险的主动谋划

十、软件质量实现

1.好的软件质量是好的项目管理、坚实的软件工程实践的结果。

2.充分理解问题，进行高质量的设计。

3.消除结构错误。

4.项目管理

5.质量控制：监督、复审、测试

6.质量保证

第十三章 软件体系结构设计

一、架构

1.作用：对软件总体设计结构进行描述，是一种很好的全局描述，可以看到系统的全貌。
（1）分析设计的有效性
（2）考虑架构替代品
（3）降低风险

2.重要性
（1）很好的沟通工具：需求分析使用user case帮助用户理解，设计阶段architecture能够帮助用户理解、促进开发者交流，看到系统的总体情况。
（2）影响巨大：某个构件出问题，只需对该构件进行修改；但体系结构出问题的修改代价很大，需要尽力保证体系结构的正确性和有效性，与场景、用途相符。
（3）方便理解：需求分析->设计->写代码，是不断抽象的过程，用户越来越看不懂。

二、体系结构描述

1.画图表示

2.体系结构描述语言、描述方法

三、体系结构类型

1.类型：不同类型适应不同场景，快速找到需要的设计风格。

2.如：房子有办公室、家园、仓库等。

四、体系结构风格

1.体系结构风格：类似于pattern但范围大于pattern。

2.内容
（1）构件：如数据库、计算构件。
（2）构件之间的连接：如客户端、服务器通过HTTP协议进行交互。
（3）约束：如客户端遵循的分布式协议。
（4）语义模型：对系统的描述，有助于用于理解系统的局部和整体特征。

3.体系结构分类
（1）以数据为中心的体系结构
（2）数据流体系结构
（3）调用-返回体系结构
（4）面向对象的体系结构
（5）层次化体系结构
（6）面向服务的体系结构（最新、现在使用最多）

4.以数据为中心的体系结构
- 数据存储（文件/数据库等）为中心
- 所有应用围绕数据仓库进行操作
- 简单，适合小程序、小demo

5.数据流体系结构
- 根据数据的处理过程设计pipeline，自然安排系统架构。
- 适用于嵌入式系统，进行信号处理。
- 医疗影像处理：采集->去噪->处理->显示结果

6.调用-返回架构
- 主函数调用子函数，子函数调用孙函数，形成函数调用树。
- 传统体系结构。
- 度量：树的深度、宽度均不应该太大，否则体系结构太复杂；函数的扇出（同一个caller调用不同callee的数量）、扇入（对于同一个callee，不同caller的数量），可以衡量整个软件体系结构的复杂度。

7.面向对象体系结构
- 一切事物都视为对象
- 对象之间通过消息进行协作
- 许多开发都是基于面向对象的体系结构

8.分层体系结构
- 为了减少复杂问题的复杂度，按照各个功能的作用，进行层次化切分。
- 系统较为清晰，复杂度降低。
- 核心层：实现基本功能。
- 工具层：各类工具，如Hadoop等。
- 应用层/应用终台/中间件：实现商业逻辑。
- 前台/UI：用户UI，在客户端进行展示。

【例】分层体系结构图
- 数据层
- 通用服务层：通用服务
- 关键共性服务层：实现的服务更有针对性
- 应用层：文档管理等。
- 表示层/UI层、

【注】
分层、面向对象架构并不冲突，是横向、纵向的关系。

9.面向服务的架构
- 一切事物视为微服务。
- 各个构件的微服务可以独立部署、独立运行，提供独立的interface。
- 对象不能独立运行，标准不统一；服务更标准化。
- 服务架构交互：服务提供者（描述服务，向服务注册机构注册）、服务使用者、服务注册机构（服务注册机构：一个进行命名的服务）。
- 优点一：请求者、提供者之间是松耦合关系，耦合通过注册机构进行，服务变动后，只需修改注册结构即可。
- 优点二：分布式架构，符合服务的开放、分布式特性。

五、体系结构模式

1.并发模式
- 解决系统的高并发问题
- 操作系统：进程改为线程，减少资源占用，提高并发度；针对不同应用采取不同的资源调度策略。
- 分布式架构：支持线性扩展，较困难，通信代价高。
- 异步通信：发完消息无需等待，服务器处理好之后再告诉客户端。

2.持久化模式
- 云上持久化
- 本地持久化

3.分布式模式

六、体系结构设计（自顶向下）

1.软件需放入上下文，与外界沟通。

2.源体系结构
- 从入口开始，自顶向下细化。

3.体系结构上下左右图
- 上级系统：使用该系统的系统。
- 下级系统：该系统正常工作所依赖的系统，如传感器等。
- 左：用户。
- 右：同级、与之进行通讯的系统。

【例】安防系统
- 上级系统：互联网系统
- 下级系统：传感器
- 用户：户主。

4.系统内部的描述——体系结构原型
- 对系统内部进行的第一层抽象，最为简单。
- 如：安防系统包含传感器、报警器等部件。

5.逐层细化(refinement)

6.体系结构设计的考量
- 经济性
- 可视性
- 分隔性
- 一致性
- 自组织性

七、体系结构分析

1.收集用例

2.详细化需求

3.选择体系结构风格，进行体系结构描述。

4.评价体系结构适合程度。

八、体系结构度量方法

1.结构化体系结构：可使用宽度、深度、扇入、扇出等指标进行度量。

2.原则：复杂度尽量小，依赖关系尽可能少。

九、体系结构描述语言

十、敏捷性与体系结构

体系结构是高层次设计，对于敏捷设计同样有重要作用，必须保证其质量。

第十七章 网络应用设计

一、网络应用设计的考虑因素

1.安全问题
- 公网面临大量DoS攻击、黑客入侵。

2.可用性(availability)
- 如证券交易软件，availability需达到小数点后7-8位。

3.可伸缩性
- 无法控制用户行为，用户量在各个时段的差异可能较大。

4.发布时间

二、终端用户的质量评价标准

1.精确度、一致性

2.反应时间、延迟

三、网络应用设计目标

1.标识度：符合商业目的。

2.健壮性

3.可导航性

4.界面美观性

5.可兼容性：兼容不同的软硬件配置（如：浏览器、CPU）。

四、网络应用设计金字塔

1.构件、体系结构与传统应用设计类似。

2.导航设计（新增）：涉及超链接的组织和链接。

3.内容设计：类似于数据设计，包括声音、视频、多媒体等类型的数据。

4.美工设计（新增）

5.接口设计

五、内容设计

1.作用：对所有内容对象，设计其内部表示、存储方案。

2.存储：数据具有稀疏性，类型可能不相同，涉及大量文件（如：商品的图像放入数据库，图标等内容放在网络服务器上）。

3.内部表示：E-R图、数据类图。

六、体系结构设计

1.内容体系结构设计：数据对象如何在页面上进行组织。

2.WebAPP体系结构设计：数据对象在中台怎么组织，对象如何定义，如何连接。

3.内容体系结构
（1）线性结构：每一页串联；多个页面进行分支。
（2）网格结构：电子商务产品，可按照功能、档次、型号、厂商等标准进行分类，产品的展示可以采用网格方式。
（3）树形结构
（4）网状结构

4.MVC体系结构——最常用的中台体系结构
（1）模型：所有用于表达商业逻辑的内容的集合。
（2）view：生成前端页面。
（3）controller：连接、请求的接受与分发、调用模型、调用view生成前端页面。

【例】
（1）浏览器请求发给controller
（2）controller拿到soap消息，调用XML解析器，解析消息目的
（3）调用模型，模型可能需调用后台数据库，产生结果
（4）controller选择view的类型，生成view

七、导航设计

1.目的：对导航链接进行统一的规划。

2.链接：需满足用户的导航需求，输出为导航语义单元(NSU, Navigation Semantic Utils)。

3.导航语义单元：为满足用户某个需求的导航结果。
- 初始值：导航结点NN1。
- 导航结果：NN4。
- 导航语义单元：导航路径上的中间节点。
- 目的：从开始到结束结点，路径最短，让用户工作量最少。
- 提高热点路径的反映时间，能够显著提升用户体验。

4.NSU创建——以产品订购为例
- 用户从页面选择“洽谈室”，看到产品列表
- 选择产品，看到相关描述
- 看完相关描述，返回产品列表，下订单
- 生成页面（Bom表）
- 返回“洽谈室”，产品订购结束

5.导航语法
- 独立导航链接
- 垂直导航栏
- 纵向导航列
- Tab页面

六、构件设计

与传统应用设计类似，主要实现业务逻辑。

第十八章 移动App开发

贡献者：夏宇晨

一、移动APP开发需要考虑的事项

1. 软件、硬件是多平台的。
2. 可以使用和选择多种开发框架和编程语言。
3. 许多应用商店都有不同接受要求和工具要求，开发的移动应用需要与应用商店相对应。
4. 移动APP开发周期都比较短。
5. UI是有限的，不可能做太丰富的交互。
6. 移动APP和各种传感器的交互（例如GPS/Camera）等。
7. 移动APP需要利用用户的Context（包括位置信息）。
8. 能源管理对移动APP也相当重要。能源管理考虑的关键点：CPU使用情况、网络使用情况。
9. 隐私与安全问题。
10. 硬件限制：例如CPU算力以及存储能力。设计时需要考虑硬件限制。
11. 外部服务整合程度。
12. 测试复杂度。

二、移动APP开发过程模型

1. 规划（Formulation）：开会定义产品。
2. 计划（Planning）：制定具体工作步骤。
3. 分析（Analysis）：将移动APP的具体细节问题分析清楚。
4. 工程化（Engineering）：包括设计环节。
5. 实现与测试（Implementation and testing）。
6. 用户评估（User evaluation）：内测。

三、移动APP质量检测表

1. 内容和功能、导航选项能否根据用户偏好进行定制？
2. 内容和功能是否能够根据用户的通信带宽进行定制？该应用程序是否以可以接受的方式解释了微弱或丢失的信号？
3. 内容和功能、导航选项是否可以根据用户的偏好进行上下文感知？
4. 是否充分考虑了目标设备的电源可用性？
5. 图形、媒体、其他网络或云服务器是否得到了恰当使用？

四、移动APP用户交互界面需要考虑的问题

1. 用户交互界面需要有品牌印记。
2. 当同一个产品可以在不同平台上投放时，我们要实现效率最高的投放。
3. 满足用户的核心需求。
4. 要优化用户UI的流程，例如，让用户的导航步骤越少越好。
5. 定义各种缩放界面大小的规则。
6. 提供给用户一个性能面板（例如下载进度、上传进度）。
7. 依靠具有用户界面工程技能的专业人士。

五、移动APP设计过程中的错误做法

1. Kitchen Sink问题：避免“大杂烩”，防止在一个界面上展示出各种东西。
2. Inconsistency问题：界面不一致。
3. Overdesigning问题：过度设计。
4. Lack of Speed问题：速度加载过慢。
5. Verbiage 问题：无用功能太多。
6. Non-standard interaction: 非标准的交互。例如电子商务中的购物车，就是一种标准的交互方式。
7. Helps-and-FAQ-itis:不要总是通过“帮助”让用户解决问题。

六、移动APP设计的最佳实践

1. 理解用户，了解用户需求
2. 充分利用context（包括用户位置信息等）。
3. 分清“简单”和“偷懒”的界限。
4. 充分利用平台的优势。
5. 使用清晰的标签。
6. 不要使用自作聪明的标签。
7. 使用长滚动方式，代替分屏方式。

七、评估移动APP开发的IDE（集成化开发环境）

1. 编译、调试是否方便。
2. 第三方SDK的集成度如何。
3. 编译工具优劣。
4. 能否支持云开发。
5. 是否支持端到端的移动应用开发。
6. 帮助文档、教程是否健全。
7. 图形用户界面构建器。

八、MobileAPP MiddleWare（中间件）

1. 用来屏蔽环境、设备的异构性。中间件的作用是尽可能抽取出环境、设备的共性。
2. 促进分布式组件的通信与协调。

九、移动APP的例子——智慧城管市民互动应用

1. 提供城市管理的多项服务。
2. 提供市民快速参与城市管理的渠道。

第二十章 Review技术

Review
- 质量保证的重要手段。
- 提高质量：过程管理、项目管理、更改管理、需求分析等。

一、总览

1.评审：有多种形式的活动，比如：评审会，相关人员对软件开发过程的中间结果进行评价和分析；软件质量保证活动；对员工进行训练，也属于评审的范畴。

2.错误和缺陷
- 错误(error)：软件发布前的质量问题。
- 缺陷(defact)：软件发布后的质量问题。

3.评审目的：尽早找到bug。bug找到时间越早，修复代价越低；后期发现bug，不仅修复代价高，而且会随着软件开发过程的推进，不断带来新的问题。

二、缺陷放大与去除

1.缺陷放大模型
（1）当前开发步骤(development step)对于defects，有以下几种可能：
①pass，即未发现error。
②错误放大：某些以往的error会被放大，如需求分析产生的一个错误，可能会带来design阶段的若干问题。
③当前步骤可能会产生新增的error。
（2）不同阶段修复error的代价
①设计->测试->发布，error的修复代价急剧增长。
②第3页的例子：该图片表示，没有任何review，因此引入的error不断增多，且过往阶段的error随着软件开发过程的推进，修复代价不断升高。即使经过了集成测试、验证测试和系统测试，仍然剩下12个error，且error的修复代价很高。
②第4页的例子：各设计阶段、coding阶段均进行review，尽早修复大多数bug，不仅剩余的error只有3个，而且对于发现到的error，总修复代价约为无review情况下的\(\frac{1}{3}\)。

2.review代价
- review本身也有时间和资源的花费，但代价远远小于尽早修复error减少的损失。
- review代价 = prepare代价 + 评估(assess)代价 + 修复(repair)代价

3.总错误代价 = 小错误代价 + 大错误代价

4.缺陷浓度：总缺陷数目 / 工作产品规模（可能是：工作量、代码数量等）
- 好处：可以对于review工程的好坏、效率高低进行评价。

【例】
（1）review：
发现小error需要4人·小时，大error需要18人·小时，小error发生概率是大error的6倍。
加权平均可知，平均发现一个error需要6人·小时。
（2）测试阶段：平均发现一个error需要45人·小时。
（3）收益：相比于无review的情况，节省了39人·小时。

三、review度量标准

1.没有review时，测试占用巨大的工作量，开发周期长；有review时，不仅总工作量减小，而且开发周期也缩短了。

2.根据缺陷浓度评价review过程
- 如果仅发现少数的error，有可能是已经做的工作错误很少，但也有可能是review效果不好。

四、review的参考模型

1.参与者
·producer：产出成果的开发人员
·leader：项目引领者
·reviewer：评审专家

2.准备与规划
·确定什么需要review，什么不需要。

3.开会

4.记录、问题跟踪与验证

五、非正式技术复审

1.简单聊天、随意的会谈

2.组队编程

六、正式技术复审

1.目标
- 发现error
- 确认软件满足需求
- 保证软件符合预定义的标准
- 确认软件按照统一的方式进行开发
- 让项目更易于管理

2.复审会议
- 关键角色：producer（开发人员）、leader（项目主管）、reviewer（评审专家）、recorder（记录人员）、SQA（看review是否高效、是否符合标准）、maintenance oracle（外聘专家，帮助提高review效果）。
- 过程：准备阶段（形成问题列表，做好准备工作）、执行阶段（开会，开发人员介绍，评审人员提问，记录）、跟踪阶段（SQA人员对问题的更改情况进行跟踪）。

七、复审原则

1.问题明确，无需找到解决方案

2.会议记录

3.参会人员不要太多，找确实有水平的评审专家

4.制作checklist

5.对FTR进行时间分配、资源调度

6.对早期的review进行review，保证review效果。

八、案例驱动的review

1.目的：通过对案例的分析，合理分配有限的review资源，用到最迫切、最有可能发现error的环节。

2.方法：找work product的不同阶段，统计分别发现error的多少。

第二十一章 SQA（Software Quality Assurance）

贡献者：夏宇晨

一、关于质量管理的评论

质量管理的问题不在于人们不知道什么，而在于他们认为自己知道什么。每个人知道质量问题，每个人需要质量，每个人也都认为自己很理解质量，认为出了问题的原因总和别人相关。

二、SQA的要素

1. 标准
2. 核查与审计
3. 测试
4. 错误收集与分析
5. 更改管理
6. 学习与教育
7. 供应管理
8. 安全管理
9. 风险管理

三、SQA的任务

1. 为项目制定SQA开发计划。
   主要定义：
   ① 哪些东西需要纳入SQA的管理
   ② 需要做哪些审计工作
   ③ 当发现错误时，应当如何报告这些错误
   ④ 错误出现时，如何检测错误
   ⑤ 文档符合什么标准。
   ⑥ 如何反馈问题给sqi团队。
   进行评估、审计与审查，得到适用于项目的标准。
2. SQA人员参与到整个软件开发过程中。
   SQA小组审查过程描述是否符合组织政策、内部软件标准、外部强加的标准（如SO-9001）以及软件项目计划的其他部分。
3. 审查软件工程活动，验证这些活动是否符合定义的软件过程。
   识别、记录和跟踪过程中的偏差，以验证是否进行了纠正。
4. 审核指定的软件工作产品，以验证其是否符合定义的软件过程的一部分。
   审查选定的工作产品；识别、记录和跟踪偏差；验证是否已进行更正。
5. 确保软件工作和工作产品中的偏差记录在案，根据记录在案的程序进行处理。
   记录任何不合规情况并向高级管理层报告。跟踪不符合项，直到解决为止。

四、SQA的目标——提升一系列质量

1. 需求质量：需求模型正确性、完整性、一致性。
2. 设计质量：设计模型的每一个元素都应该由软件团队进行评估，以保证设计本身符合要求。
3. 代码质量：源代码和相关工作产品必须符合当地编码标准，以便维护。
4. 质量控制高效性：软件团队应该以最有可能实现高质量结果的方式应用有限的资源。

五、统计学SQA

使用统计学的方法对SQA活动进行分析与统计，从而提高SQA活动质量。
·软件工程中的Six-Sigma标准

例如有100万辆汽车，1-sigma表示其中有69万辆可能出现质量问题，2-sigma表示其中有30.8万辆可能出现质量问题，以此类推。
Six-Sigma方法定义了几个核心步骤：
1. 通过明确定义的客户沟通方法定义客户需求、可交付成果和项目目标。
2. 测量现有流程及其输出，以确定当前质量性能。
3. 分析缺陷指标并确定关键的几个原因。
4. 通过消除缺陷的根本原因来改进流程。
5. 控制过程，以确保未来的工作不会重新陷入引入缺陷的原因。

六、软件可靠性（Reliability）与可用性（Available）

七、软件安全

是一项软件质量保证活动，其重点是识别和评估可能对软件产生负面影响并导致整个系统故障的潜在危害。

八、SQA标准（软件质量保证标准）

最常见的是ISO 9001：2008标准。

第十四章 构件级设计(Component Level Design)

贡献者：夏宇晨

构件级的设计

也可以认为是模块化的设计。构件级的设计是一种模块化的、可以部署的、能够被替换的系统设计部分。这一部分封装了一些实现，对外提供接口。
① 面向对象的观点：一个模块，包含了一系列的协作类。
② 传统的观点：模块是一个函数包，包含三部分：处理逻辑、数据结构及初始化参数、供用户访问的一些接口。

构件级设计例子——打印作业

输入分为两部分：体系结构的分割、分析类。体系结构的设计结果会把我们的设计划分成很多的组成部分；每个组成部分的设计依据是分析类。
在分析类得到的结果可能并不那么规范，但在构件级的设计中，需要精准细致地进行定义。

构件级设计的基本设计原则

① OCP（Open-Closed Principle）：整个模块针对扩展是开放的，但所有的更改需要限制在模块内部，而尽量不要更改模块的接口。
② LSP（Liskov Substitution Principle）：所有的子类都可以替代基类。
③ 依赖反转原则DIP（Dependence Inversion Principle）：模块之间的交互与依赖只依赖于接口进行，而不依赖于具体实现。
④ 接口分离原则ISP（Interface Segregation Principle）：一个接口干一件事，不要使用同一个接口做很多事情，不然会使得风险增大。
⑤ 等价原则REP（Release Reuse Equivalency Principle）:释放的力度和重用的力度应当基本相同。
⑥ 公用闭包原则CCP（Common Closure Principle）：一起更改的类，尽量放在一起。
⑦ 公用重用原则CRP（Common Reuse Principle）：不能够被一同重用的类，不应当被放在一起。

设计注意事项

① 命名应当清晰易懂。
② 需要定义各种用于沟通的接口。

内聚（Cohesion）

用来形容一个模块内部的能力。
传统观点：一个模块的思想应当是“单一的”，即只干一件事情。
面向对象观点：封装一个类，应把相关的所有属性和操作都聚合在一起。
内聚的种类：
① 功能型的内聚：同一类的功能整合在一起，变成一个构件。
② 层次化的内聚：不同层次具有不同模块。
③ 通讯型的内聚：处理通讯协议的所有交流模块放在一起。
④ 序列化的内聚：同一个流程上的东西，按照时间顺序放在一起。
⑤ 过程化的内聚：同一个过程中的东西放在一起。
⑥ 时间化的内聚：同一个时间上的东西放在一起。
⑦ 工具化的内聚。

耦合（Coupling）

衡量两个构件之间依赖的程度。
我们的目标：高内聚，低耦合。
耦合的种类：
① 内容耦合：程序纠缠在一起（例如GOTO语句）。
② 公共耦合：不同模块之间共享全局变量。
③ 控制耦合：不同模块之间会传递参数，且传递的参数是控制参数。
④ 戳耦合：不同模块之间传递数据结构，该数据结构改动后，会对两个模块都有影响。
⑤ 数据耦合：不同模块之间传的参数既不是控制参数，也不是数据结构。
⑥ 类型耦合：不同模块继承自同一个基类。
……

构件级设计步骤

Step1：根据模型、问题域，得到所有的设计类。
Step2：根据基本结构域，得到所有的设计类。
Step3（a,b,c,d）：分别对每一个设计类进行细化，细化内容包括对每一个类的属性、接口、成员函数等进行细化，同时需要对类之间的交互进行细化，还需要对每一个成员变量、过程等进行细化。
Step4：数据持久化设计（数据库或文件）。
Step5：针对控制类的协同做以详细的设计。
Step6：针对部署进行设计。
Step7：对每个环节进行求精，评估是否有其他更优的可选方案。

构件级设计的图表示

包括协同图、类图（定义各个类之间的关联关系）、活动图（用来表示某一个类的具体过程）、状态图（对每一个参数、每一个过程的细化）。

Refactor（重构）

保证接口不变的情况下，对其中的内容、方法、冗余的东西可以去掉。

·网络应用的构件级设计：
·网络应用构件是：
（1）定义明确的内聚函数，来操纵内容或为用户提供计算或数据处理。
（2）内容和功能的内聚包，为最终用户提供一些所需的功能。
因此，网络应用的构件级设计通常包含内容设计和功能设计的元素。

网络应用的内容设计

网络应用需要接受各种用户输入的信息，还需要给用户反馈各种信息。设计的重点是这些信息应当怎么存放、怎么布局。因此，内容设计是网络应用设计的特有设计。 以安防系统为例：如果需要让用户选择一个摄像头，就可以看到摄像头对应的内容。内容设计：首先我们需要将房子大致的布局调出来，然后在布局中放置很多Camera的图标，点击图标就可以看到缩略图，双击就可以选择观看详细的监控视频，并且可以选择分辨率等。

网络应用的功能设计

需要设计相关的代码逻辑。例如仍针对刚刚的安防系统的例子：首先，我们需要初始化所有的摄像机。当用户点击其中一个摄像头时，需要对该摄像头进行网络连接，并读取信息流。最后，展示出信息流。
瘦客户端：基于HTML页面的客户端，表达和展示能力有限。
富客户端：基于HTML5页面的客户端，不仅能够进行展示，还能够进行交互与数据计算。

传统构件级设计

·处理逻辑的设计受算法设计和结构化编程的基本原则所支配。
·数据结构的设计由为系统开发的数据模型定义。
·接口的设计受组件必须实现的协作的控制。

基于构件的开发

当面临重用的可能性时，软件团队会考虑的问题有：
① 商用现货组件是否可以用于实现该要求？
② 内部开发的可重复使用组件是否可用于实现需求？
③ 可用组件的接口是否在待构建系统的体系结构内兼容？

重用的困境

① 由于业务导向时间常常较为紧迫，很少的企业或组织，会花精力在可重用方面的提升。
② 很多软件工程师不一定会选择重用。
③ 可帮助软件工程师或管理人员理解与应用重用技术的培训相对较少。
④ 许多软件从业者认为重用的麻烦超过了重用的价值。
⑤ 许多公司鼓励使用不利于重用的软件开发方法。

构件级开发的过程图

新增了领域工程。

领域工程步骤

① 定义要调查的领域。
② 对从域中提取出的项目进行分类。
③ 收集域中具有代表性的应用程序样本。
④ 分析样本中的每个应用程序。
⑤ 为对象开发一个分析模型。

·识别可重用的构件需要考虑的问题
·未来的实施是否需要该组件的功能？
·组件的功能在域中有多常见？
·域内是否存在组件功能的重复？
·组件是否依赖硬件？
·硬件在不同实施之间是否保持不变？
·硬件细节是否可以删除到另一个组件？
·对于下一个实施，设计是否足够优化？
·我们可以参数化一个不可重用的组件，使其成为可重用的吗？
·该组件在许多实现中是否可重复使用，只需很少的更改？
·通过修改重复使用是否可行？

基于构件的软件开发需要

① 一个构件库：构件需要具有一致的结构。
② IDE要和构件库做一个集成。
③ 构件需要具有一个标准。

CBSE（基于构建的软件开发）活动

① 构件质量评估
质量评估要素：能力、效率、准确率、API提供的形式、开发工具的集成、安全性要求。
② 构件适应性改造
有些构件经过步骤①可以直接投入使用，但有些构件并不能，因此需要做一些相应的改造和适配。
易于集成的含义是：
（1）已对库中的所有组件实施了一致的资源管理方法。
（2）所有组件都存在数据管理等常见活动。
③ 构件组合
必须建立一个将所有构件绑定在一起的基础设施。构成的建筑成分包括：数据交换模型、自动化、结构化存储、底层对象模型等。
④ 构件更新

构件级软件开发标准

最常见的是OMG/CORBA标准：公共对象请求代理体系结构，是一套支持远程对象访问的体系架构。使用该标准，即使对象和对象的访问者不在同一台机器上跑，通过网络连接，访问操作也可以正常进行。
微软开发标准——COM。

针对库进行分类：
① 枚举分类
② 分面分类
③ 属性值分类

索引：全文检索建立索引。

重用环境

· 一种构件数据库
· 一个为数据库提供访问支持的管理系统
· 一种软件组件检测系统
· CBSE工具

第十五章 UI设计

一、界面设计

1.总体目标：容易理解、容易使用。
2.设计教训
·缺少一致性
·需要太多记忆
·无引导/帮助
3.好的UI设计原则
·以用户为中心
·减少用户的记忆负担
·保持接口一致
4.设计原则一——以用户为中心
·交互模式不能强迫用户按照单一的方式进行交互，而是给用户提供多种灵活的选择。
·允许用户中断、撤销操作，保存中间结果。
·尽量隐藏技术细节，宁愿多写1000行代码，也不要对用户多产生一个约束。
·设计较为直接的交互，用户看到一个内容，可以简单、迅速地进行交互。
·细节的处理：有/无经验的工程师的重要区别；决定成败。
·细节处理举例——登录：弹出对话框，较好的弹出位置是屏幕的中间位置；“中间”应该根据屏幕的分辨率进行计算；对话框大小适中，需聘请美工、心理学专家进行分析；确定/取消、登录/取消、新用户；美化，添加logo。
5.设计原则二——减少用户记忆负担
·追求常规，如快捷键应该与常见用途保持一致。
·建立有意义的缺省值。
·直观的快捷键，不轻易进行改变。
·interface最好跟用户实际接触的内容一致，比如发票系统与实际的纸质发票格式一致，则用户基本没有学习成本。
6.设计原则三——保持界面一致性
·某公司的应用产品，应该符合产品家族的特征、公司文化的特征，如淘宝-橙色，谷歌-三基色，支付宝-蓝色等。
·如果过去的交互模型效果较好，不要轻易改变。

二、UI设计模型

1.用户模型：分析系统的所有终端用户。
2.设计模型：软件工程师根据需求分析文档设计的模型。
3.心理模型：用户心理期望的interface。
4.实现模型：工程师coding实现的模型。
用户满意的条件：心理模型与实现模型较为相符。

三、UI设计过程

1.设计过程
·UI分析与建模：分析用户、分析环境、分析任务、分析内容。
·UI设计
·UI构造：可使用美工画、PPT、HTML编辑器。
·UI验证

三、界面分析

1.组成部分
·用户分析：分析使用界面的人员及其特征
·分析任务：每个用户的任务，如何与系统交互，希望如何得到信息，用户为了得到信息需要执行的动作。
·分析内容：分析界面展示的内容。
·分析环境：分析任务执行的环境。
2.用户分析
·职业技能
·教育程度
·性别
·年龄
·语言

四、任务分析与建模

1.分析内容
·任务执行的环境
·各个任务及其子任务
·任务的工作流(workflow)
·任务之间的关联关系、层次关系
2.分析依据——用例
3.常用分析工具——泳道图
·按照角色，对工作流程进行清晰的切分。

五、内容显示分析

1.目的：分析每个任务需要显示哪些内容。
2.需要分析的内容
·订单：订单录入后，销售人员、销售经理、生产计划部门分别应该看到哪些信息，权限如何。
·是否需要定制化
·是否需要支持不同layout
·各类信息是否能在屏幕上正常、清晰展示
·大量信息是否进行切分
·图形展示是否适应分辨率变化
·颜色
·出错信息、警告对用户展示的方式

六、界面设计步骤

1.定义interface对象和动作
2.定义事件
3.描述interface的状态
4.表明用户怎样理解系统的各个状态
·总结：功能->任务->界面->界面元素细化->串接
·搭建大的框架->分析每个用户需要的系统交互功能->为实现功能需要完成的任务->设计各个任务各个步骤对应的界面->对各个界面的元素进行细化->串接

七、一些设计问题(issue)

1.响应时间：不同系统，用户对响应时间期望不同。如C-S模型，期望更高；Web应用，期望相对低一些。
2.帮助设施：便捷地对用户进行帮助。精准定位、包含在线帮助（语音交互）等。
3.错误处理：保护现场，易于恢复；对用户友好。
4.快捷键：用户可以通过键盘完成交互。
5.国际化

八、Web、Mobile应用界面设计

·WebApp特殊性：超链接、浏览器、多媒体。
·MobileApp特殊性：小屏幕（需要展示怎样的信息，如何展示）、公网、美工效果。
·入口、出口、导航路径较多，需要解决下列问题。
1.我在哪个位置
2.我可以去哪里，目前可以干什么
3.我已经走过的路径，我将要去哪里，都应该对用户呈现。
4.高效Web/Mobile App interface设计的特征
·吸引人、难忘
·屏蔽技术细节，用户只看到必要信息。

九、interface设计

1.设计原则
·一致性：界面、颜色、导航方式、布局
·预见性：预测用户下一步要做什么，是一种较好的推荐技术。推荐系统与此相关。
·Fitt's law：获取目标的时间，是到目标的距离（需要点多少次按钮），以及目标尺寸（按钮的大小）这两个因素的函数。
2.设计过程
·对分析模型进行复审，确认各个角色及其任务
·勾勒大致的interface layout
·把用户目标映射到interface的动作
·界面串接
·确定各个动作执行时，用户需要完成的任务，用活动图/泳道图进行描述。
·识别为了实现interface所需的对象
·对于用户与interface的交互，进行过程性描述。
·对interface进行行为表示。
·描述每个状态下的interface layout
·细化、复审interface设计模型
3.审美(aesthetic)设计
·强调内容
·从左上角到右下角组织元素
·考虑分辨率、浏览器窗口大小等因素
4.设计评估循环
·预备性设计
·建立原型interface
·用户对interface进行评估
·设计者对评估进行研究
·进行设计修改
·重新建构原型interface
·出口：设计者研究评估，认为设计完整，可以终止迭代。

第十六章 基于模式的设计

一、设计模式

1.模式：经验的总结。
2.设计模式：便于充分利用经验，将其快速用于应用场景，解决问题。
3.模式的三个组成部分：上下文（应用范围）、问题、解决方案。
·上下文：问题的背景与环境，可用于分析自己的问题与哪个模式相关性更强。
·挑战与限制(a system of forces)：设计模式的约束、局限性及其影响。
4.有效模式的特征
·能够解决问题
·可以证明的概念
·解决方案不是显然的，不是尝试
·能够描述关系，描述要素之间如何相互连接
5.生成模式的类型（根据问题域进行分类）
·体系结构模式：包含以数据为中心、批处理、层次化、SOI等内容。
·数据模式：数据模型如何建立、数据内部表示、数据库设计等。
·构建模式（最狭义的生成模式）：软件系统应包含哪些部分，各部分间应如何进行交互。
·界面设计模式
·WebApp模式
6.设计模式的另一种分类
（1）创造型模式
·关注：如何对对象的生命周期进行管理。
·抽象工厂模式：对工厂类进行创建。
·工厂方法模式：对各种对象进行创建。
（2）结构化模式
·关注：各个系统如何连接，形成大的系统。
·适配器模式：把类的界面调整到客户端期望的状态，一个事物需要适应多种方案。
·聚合模式：一类复合模式，带有聚合子构件、子系统的方法。
（3）行为模式
·关注：类之间如何协同，如何传输命令对象等。
7.框架
·pattern更倾向于方法论，framework则是有形的、具体的基础设施。
·framework：编程框架，已经完成许多基础工作，并留出许多可变点。基于可变点，可以演化出我们需要的软件系统。
·例如：盖房子，pattern是“三室一厅”模式（方法论），framework是打好地基，框架搭建完成（平台，完成面向领域的不可变的、公共的基础任务，留下可变点）。
8.模式的描述
·名字、上下文、意图、实现方式、面对的问题、系统、已知应用场景、动机、解决方案、结果、相关模式。

二、基于模式的软件设计

1.大致流程

·对问题进行分析，形成总体印象。
·进行模式匹配，看问题跟哪个pattern匹配程度高。
·如果pattern可以应用，则直接使用；否则需要自行设计。
2.模式设计表
·针对数据、体系结构、构建、用户界面，分别对数据库、应用、实现方法、基础设施，记录应用什么pattern是合适的。
3.常见的设计错误
·理解模式需要花费大量的精力，一些人没有花费充分的时间去理解设计模式。
·选择错误的模式后，工程师拒绝承认错误，强行适应模式。
·模式没有覆盖到问题的一些实际约束，导致适配效果差。

三、体系结构模式

四、构件模式

·应用于构件的设计过程中。

五、UI设计模式

·如：WebApp的经典UI（包括图片、菜单）、信息管理系统（登录界面->菜单、主界面、信息页等）。
·页面如何布局。
·表单如何输入。
·导航风格、搜索方式。
·购物车与人的交互。
·聊天机器人：直接应用在电商平台可能不适用；应抓住聊天的keypoint，创造新型的交互模式，有效促进消费。

六、WebApp模式

·信息组织模式
·导航模式
·功能模式
·交互模式

七、移动应用的模式

·UI设计模式：评论、地图（订餐地图：显示底图 + 浮动信息用于交互）、弹出式消息。

第二十九章 Software Configuration Management软件配置管理

·主要解决软件更改的问题
第一定律：无论你在系统生命周期中处于什么位置，系统都会发生变化，改变它的愿望将在整个生命周期中持续存在。

·这些更改是什么？
商业需求的变更。
用户需求的变更。
技术需求的变更。

·软件配置项
配置项包括：程序、相关文档（例如需求分析的过程文档、会议纪要、设计文档、测试文档等）、数据（为了支持运行开发，所需要的各种数据，包括：初始化数据（如人工智能训练集）、测试用例数据等）。

·Baseline（基线）
软件开发过程中，各个配置项协调一致的状态。基线是软件开发当中的一个里程碑，其标志是交付一个或多个软件配置项，并通过正式的技术审查获得这些SCIs的批准。
对基线的管理，需要一套比较规范的流程：一般会形成一个项目相关的配置库，称为受控库。每天开发的库称为开发库，在开发库中，主要会由程序员做一些项目的版本跟踪、控制。每隔一段时间，会把开发库的一部分东西导入受控库。受控库中一般存放的都是基线，一般一个部门控制一个受控库。产品release后，受控库中的东西会被放到产品库中。

·SCM存储库
SCM存储库是一组机制和数据结构，允许软件团队以有效的方式管理更改。数据库执行或促成下列功能：数据完整性、信息共享、工具集成、方法实施、文件标准化。
·配置项库内容
放置项目需求相关、商业管理相关、建模相关、代码相关、测试相关信息及其他文档。

·配置项库功能
① 版本控制：保存所有这些版本以实现对产品发布的有效管理。
② 依赖关系跟踪和更改管理：存储库管理存储在其中的数据元素之间的各种关系。
③ 需求跟踪：提供跟踪特定需求规范产生的所有设计和施工组件以及可交付成果的能力。
④ 配置管理：跟踪代表特定项目里程碑或生产发布的一系列配置。版本管理提供所需的版本，链接管理跟踪相互依存关系。
⑤ 审计跟踪：建立关于何时、为什么以及由谁进行更改的附加信息。

·SCM元素：
组件元素——耦合在文件管理系统（例如数据库）中的一组工具，用于访问和管理每个软件的配置项。
过程元素——一组程序和任务，为参与计算机软件管理、工程和使用的所有群体定义了一种有效的变更管理方法（以及相关活动）。
构建元素——一组工具，通过确保组装正确的一组经过验证的组件（即正确的版本）来自动化软件的构建。 人为因素——实现有效的供应链管理，包括软件团队使用的一套工具和流程特征。

·SCM（软件配置管理）过程：
解决如下问题：
·软件团队如何识别软件配置项（SCIs）？
·一个组织如何管理一个程序（及其文档）的许多现有版本，使其能够有效地适应变化？
·在软件发布之前，组织如何控制更改？
·谁来负责批准和名次变更？
·如何保证正确地进行了更改？
·使用什么机制评估他人做出的改变？

·版本控制：
结合了过程和工具来管理软件过程中的配置对象的不同版本。

·更改控制：
分为三个过程：
① 控制更改的申请。
② 控制更改的执行。
③ 检查更改的过程是否规范。

·审计：SQA负责审计。
审计应有的配置项是否存在等问题。

·用于Web和移动工程的SCM
典型的Web或移动应用程序包含大量内容——文本、图形、小程序、脚本、音频/视频文件、表单、活动页面元素、表格、流媒体数据和许多其他内容。
挑战在于将这片内容海洋组织成一组合理的配置对象，然后为这些对象建立适当的配置控制机制。

·内容管理
·除了对文档的对象进行管理，还需要对其中的内容做一些分析与管控。最简单的例子是对文档建立一个全文检索引擎。
·一般是基于Web的系统，实现内容管理。

第二十二章 软件测试战略

·“软件测试战略”针对的内容：测试活动如何组织、协作。

一、软件测试

·执行程序的过程，目的是在发布给用户前寻找漏洞，看功能跟需求分析是否相符，性能是否满足性能要求。
·测试也能指示软件质量。测试发现的bug少，有可能是软件质量高，也可能是测试不充分。

二、策略方法

1.技术复审：在有效测试之前，需进行技术复审。软件测试代价较高，应先作各类有效的正式/非正式技术复审，不把所有压力交给测试，才能提高效率，降低漏洞修复成本。
2.测试的自底向上集成：从构件级别的测试（单元测试）开始，自底向上进行测试，依次进行集成测试、系统测试、性能测试等。
·测试过程是逐步集成过程。
3.不同的测试技术：（单元测试、集成测试、系统测试等）适用于不同的阶段。
4.测试：部分测试由开发人员完成；部分（集成测试、系统测试）为独立测试组完成。
5.测试与debug的区别：测试只发现问题；debug在发现问题后还需修复问题。

三、测试的V & V

1.Verification验证：验证系统输入、输出的逻辑是否正确，系统是否能正常工作，软件产品是否已经实现用户需求。
2.Validation确认：所有软件功能是否都可以回溯到用户需求。

四、软件测试人员

1.开发人员：对系统了解更深刻；但是测试手段更温和，心理状态是更希望说明自己的工作产品是好的。
2.独立的测试人员：必须花时间学习系统，但是测试效率更高（测试效率与奖金挂钩），依靠质量驱动。

四、测试技术

·单元测试：对某个单元（模块/类）进行测试。
·集成测试：对单元的串联进行测试。
·确认测试：对整个系统进行测试，看需求是否完成。
·系统测试：软硬件联调。
上述测试技术自底向上，逐渐集成。
1.传统软件的模块：函数
2.OO模块：类

五、测试相关的观点

1.尽早按照可量化的方式声明产品需求
2.显式声明测试目标
3.理解用户是测试的基础
4.制定测试计划，测试也十分重要，需要留足资源。如航天软件开发中，测试人员可能多余开发人员。
5.技术复审十分重要，应经常进行。

六、单元测试

1.一般由软件开发工程师，对一个模块执行测试用例，得到结果。
2.测试内容
·interface是否达到要求
·局部数据结构
·边界条件
·独立路径：程序的所有分支都要覆盖。
·错误处理路径
3.对模块进行测试，首先要写一个驱动器。
·可能需要调用第三方模块，若第三方模块暂时没有，则需写若干stub（空函数）。

七、集成测试

1.每个模块均完成测试后，需测试各个模块互相连接后功能是否正常。
2.选择
·big bang-暴力地将所有模块直接组合在一起
·使用增量构造技术进行集成测试
3.自顶向下的集成
·首先，顶层模块使用空函数stub进行测试
·然后，stub按照深度优先的次序，逐个被替换为实际的模块。
·新模块集成后，某些测试子集需要被重新运行。
4.自底向上集成
·需要写很多驱动器进行测试。
·某几个模块形成一个cluster，可先对该cluster进行测试。测试完成后，该cluster可以作为一个整体，加入更高层次的测试。
5.三明治测试
·同时进行自顶向下、自底向上测试，提高测试效率。
6.回归测试
·用实际模块替换stub后，需要再次执行某些测试子集，该过程称为回归测试。
·原因：加入新模块后会带来新的问题。
·回归测试过程既可以手动进行，也可以自动化测试。
5.冒烟测试(smoke testing)
·核心：使用日创建(daily build)方法，每天编译一遍程序形成一个版本，用户每天都可以查看新的版本。

八、总体测试目标

·接口完整性测试
·功能有效性测试
·信息域测试
·性能测试

九、面向对象测试

·面向对象：使用类进行组织，测试策略有别于传统测试。
·单元测试：对类进行测试。
·集成测试：使用用户场景进行串接、集成。

十、WebApp测试

·对内容、导航、功能、接口等进行测试，本章跳过。

十一、移动App测试

·用户体验测试、设备兼容性测试、连接性测试、安全性测试

十二、高阶测试

·确认测试：确认软件是否满足用户需求。
·系统测试：软硬件结合在一起，看系统的表现。
·alpha/beta测试：分别是指开发环境、真实环境测试。
·恢复型测试：搞破坏，比如拔网线、关闭某结点，看系统的反应。
·安全测试：模拟各类攻击，看系统对攻击的反应，是否产生问题。
·压力测试：不断增加压力，看系统何时crash。
·性能测试

十三、debug——诊断性过程

·debug相当于“看病”
·debug过程：运行测试用例（系统无法支撑10万并发量）->找到原因（未使用数据库连接池）并修复（使用数据库连接池，要开socket，创建线程，进行资源共享）->进行回归测试（得出结果：系统能支持30万并发度）
·（28页左图）现象与根源在物理上可能是分离的；部分error为偶发/随机现象；bug原因可能是单个功能都正常，但是相互影响，或者连接不正确，或者编译器/服务版本不对；以为没问题的地方反而可能有问题。

十四、bug的严重程度(P29)

·微小的、烦人的、打扰人的、严重的、极端的、灾难性的、传染性的。

十五、debug技术

·debug是经验性过程，有经验的人更容易判断是发生怎样的问题。
·暴力：所有变量都输出
·回溯法：发现一个问题后，一步步追踪工作流、信息流。
·归纳法：经验丰富，根据经验确定性能不足可能是数据库连接/进程设计的问题，透过现象得到结论。
·演绎法：看到print数字错误，推断可能是%忘记。

十六、最后的思考

·先思考，再debug；使用debug工具拓展视野；无法找到bug，向别人寻求帮助；修复完bug要进行回归测试。

十七、修复error

·联想程序中是否有同类问题，找到一个问题就要解决一类问题。
·考虑修复某个error可能会导致的其他bug。
·从源头上遏制bug。

第二十三章 测试传统应用

·程序的可测试性
① 可运作性。
② 结果可视性较好。
③ 测试可控性较强（比较容易写测试用例）。
④ 可分解性好（模块化程度高）。
⑤ 比较简单。
⑥ 稳定性比较好。
⑦ 可理解性好（少用晦涩的设计方法）。

·好的测试特征：
① 最大概率的能够发现错误。
② 好的测试是不冗余的。
③ 测试用例应当是一个好的种子，通过它能够发现错误。这些测试用例既不那么简单，又不那么复杂。

·测试的内部视角与外部视角：
任何工程产品都可以通过下面两种方式之一进行测试：
1. 了解产品设计用于执行的特定功能后，可以进行测试，证明每个功能完全能够操作，同时查找每个功能中的错误。
2. 了解产品的内部工作原理后，可以进行测试以确保根据规范执行内部操作，并且内部组件得到了充分的提升。

·测试用例设计：
目标是以完整的方式，使用最少的时间和精力找出错误。
错误往往潜伏在角落与边界处。

· 穷尽测试
几乎做不到。图中的程序有10的14次方条可能的路径，如果我们每毫秒执行一次测试，那么测试这个程序需要3170年的时间。

· 选择性测试
选择一些相关路径进行测试，往往就足够了。我们希望选择的路径有一定的代表性，最低要求是每行代码都跑一遍。

·软件测试
分为白盒测试和黑盒测试两个方面。
【白盒测试】内部结构测试。保证所有的代码、所有的语句、所有的条件都被至少执行一次。这是因为，错误的发生的随机的，任何地方都有可能发生。并且，剩余的错误和我们已经进行的测试次数是成反比的。
基本路径测试方法：可以探明最少需要几次测试，可以达到代码覆盖率百分之百。

将程序执行图的每一条语句添加标签，变成一个流图。
然后，最少需要的测试数目可以由下面三种方法中的任意一种得出：
① 计算分割出的区域一共有几个。
② 计算得到的流图的边数 – 节点数 + 2的值。
③ P表示流图当中所有出度大于1的节点数目，计算P+1的值。
实际操作过程中，可以转化为流图，也可以不将程序执行图转化为流图，直接将断言节点（即上述P节点）的数目找出来即可。
测试路径数目被计算出来后，可得到各个测试路径，从而得到测试用例。
图矩阵法：
通过上述将每一条指令标号为a~k，可以得到一个矩阵，该矩阵的行是a~k，列也是a~k。
矩阵的项目表示节点x到节点y是否存在一条路径。把整个矩阵测试完毕后，就表明测试已经覆盖了所有的指令路径。
控制结构测试：
① 条件测试：一种测试用例设计方法，对每个条件语句的真分支和假分支都进行测试。
② 数据流测试：对每一个DU链形成测试用例。一个DU链是[X,S,S’]的形式。其中，X在语句S中被定义，在语句S’中被使用，并且在语句S’中，X在语句S中的定义是有效的。
③ 循环测试：对循环结构做一个测试。循环分为四类：简单循环、嵌套循环、级联式循环、非结构化循环（GOTO语句）。
对于一个简单循环，我们一般测试7次，就离开。1. 直接跳过循环。2. 测试循环1次的情形。3. 测试循环2次的情形。4. 测试循环m次的情形，m是大于2小于n-1的随机数。5. 测试循环n-1次的情形。6. 测试循环n次的情形。7. 测试循环n+1次的情形。 其中n是最大允许的循环次数。
对于一个嵌套循环，可以首先从内循环开始测起，内循环可以测7次（按照刚才的方法），外循环循环一次。然后固定住最里面的循环，循环一次，测外循环，测7次（按照刚才的方法），依此类推。

【黑盒测试】外部功能、性能、边界条件测试。
把程序当成一个黑盒子，由Input得到Output，与预期做比对。
① 基于图的测试方法
得到一个对象之间交互的状态图。
② 等价分割
等价类表示输入条件的一组有效或无效状态，因此没有特定的理由选择一个元素而不是另一个元素作为类代表。
③ 边界值分析
格外关注边界值。
1. 如果输入条件指定了a到b的范围，那么测试用例应该包括a和b，以及a、b附近的值。
2. 如果输入条件指定了值的数量，那么测试用例应该使用最小值和最大值，以及最小值、最大值附近的值。
3. 如果内部程序数据结构有边界，一定要测试边界。
④ 对比测试
仅在软件可靠性是十分关键的情况下，才会使用。
将独立的两个软件工程团队使用相同的规范开发出的应用程序的独立版本进行比较，建立一种“赛马”机制，取其优者，牺牲成本保证软件可靠性。
⑤ 正交阵列测试
当输入参数数量很小时使用，并且每个参数可能取的值都有明确的界限。
只需测试右图所示的九个点代表的输入，就可以表示27个点的正确结果。
⑥ 基于模型的测试
从整个分析模型入手，分析软件现有行为模型或创建一个行为模型。（行为模型表明软件将如何针对外部事件作出反应。
当软件从一个状态转换到另一个状态时，查看行为模型并记录预期输出。

·软件测试模式
测试模式的描述方式与12章中的设计模式大致相同。

第二十四章 面向对象的测试

一、面向对象测试的特点

1.面向对象的测试范围不仅局限于代码，还可以扩展到需求分析、设计模型。
2.集成测试强调类与类之间的协同，因此与传统测试而言，集成测试的过程发生了变化。
3.测试用例需要融合面向对象的特点。

二、面向对象模型的测试

复审OO分析和设计模型：有利于发现语义错误，原因是同样的构造（类、属性、方法等）在分析、设计、编程阶段都是对应起来的。

三、OO模型的修正

在分析、设计阶段，语义正确性可以通过模型对于现实世界问题域的一致性评价。

四、类模型一致性

1.CRC卡片在分析模型中是一个重要的组成部分，因此可对CRC卡片进行复审。
2.检查每个CRC卡片的各类责任，确认成员变量、方法是否正确。
3.可使用反转连接的方式（从协作者角度看，是否需要当前类的相关信息和方法），看协作者接受请求的来源是否是合理的。

五、面向对象的测试技术

1.单元测试
·单元的概念：从“函数”变为“类”
2.集成测试
·可使用多种方式，对类进行组织、协同。
·方法一——基于线程的测试（某个事件激活一系列类的动作，基于该事件激发的动作流程进行测试）
·方法二——基于用户场景的测试（对每个场景进行测试）
·方法三——聚类测试（根据协同关系发现协同类，进行协同测试）
3.确认测试
·基于用例进行确认测试
4.基于故障的测试
·让某些可能的故障发生，看系统的反馈
5.类测试与类的层次
·对某类方法的有效性测试的同时，还需测试其父类方法对当前类是否带来影响。
6.基于用户场景的测试设计

六、OOT方法——随机测试

1.随机测试
·对类的成员函数进行测试
·某个测试类有很多成员函数，各成员函数涉及的动作可能形成随机序列。对随机序列进行测试的过程即随机测试。
·如：银行用户类涉及开户、存钱、取钱、销户四类动作，约束是先开户一次，之后可以存取钱，销户一次后不能再操作。按照该约束，可以生成动作的随机序列，以对各个成员函数进行测试。
2.分片测试
·类的等价测试，对各个类按照类的状态、类的属性、类的功能进行分片。
3.多类测试(inter-class testing)
·客户端、服务端联合测试。
·第一步：对于客户端，可以按照约束生成随机的测试序列。
·第二步：客户端向服务端类发送消息，激活服务端某些类。
·第三步：服务端返回消息，又激活客户端内的若干类。
·通过某个随机操作序列，激活客户端、服务端中的一系列类，从而完成多个类的类间测试。

七、行为测试

·遍历状态图，完成状态图遍历，说明对类的行为进完成了测试。

第二十五章 测试WebApp

一、WebApp质量

1.内容
·语法层面：对于基于文本的文档，需评价拼写、停顿符号等。
·语义正确性：提供正确、一致的信息，没有模糊性。
2.功能
·正确性、稳定性、总体一致性。
3.结构
4.可用性
·对于用户而言，随时可用。
5.可导航性
·导航语法、语义
6.性能
·在不同的条件、配置、负载下，测试系统对用户交互的反应；测试系统在极端压力下的反应。
7.兼容性
·在不同的客户端、服务端软硬件平台上测试。
8.互操作性(interoperability)
·WebApp能与数据库/其他应用进行较好的交互。
9.安全性
·WebApp在公网环境下运行，安全挑战比较多。

二、测试流程

1.内容测试
2.界面测试
3.导航测试
4.构件测试
5.配置测试、性能测试、安全性测试

三、内容测试

1.内容测试
（1）揭示语法错误
（2）揭示语义错误
（3）看内容的展示方式、组织方式是否能清晰地展示给用户，用户是否容易理解。
2.语义测试的各个方面
·信息是否精准、符合事实
·内容方便用户理解
·信息的组织方式是否清晰，是否容易发现
·第三方图表、文章出处是否正确
·信息表示方式是否内部一致（如：同一个概念在不同页面表达方式应一致）
·内容是否有侵犯性、误导性
·美工风格是否符合公司风格

四、数据库测试

·对于数据库层、数据管理层、数据变换层、服务层、客户层这五个层次，分别进行测试。

五、用户界面测试

1.对图形界面、面向程序的接口进行测试。
2.看UI设计是否符合设计法则：以用户为中心、减少记忆量、美工。
3.导航单元是否按照设计，进行一步一步地的变更。
4.UI兼容性测试：在不同操作系统、不同浏览器进行兼容性测试。

六、用户界面测试机制

1.超链接
2.表单：能否正确填写、风格正确显示
3.客户端脚本：在各类浏览器、配置下，可以正常工作。
4.动态HTML：是否可以显示。
5.客户端弹窗：是否正确弹出。
6.CGI脚本
7.流文件
8.cookie

七、可用性测试

1.确定测试目标
2.选择组织测试的参与者，如：游戏测试选择不同水平的玩家。
3.选择测试方式：集中玩家进行测试/发布测试版软件；测试意见如何反馈；是否需要培训用户以提高效率。

八、兼容性测试

1.测试运行环境是否兼容各类软硬件。
2.兼容性与配置测试关系较大。
3.主要指的是客户端配置的兼容性。
4.对客户端硬件、操作系统、浏览器、网络连接方式（宽带、5G通信等）。

九、构件级测试

1.类似OO应用、传统应用，对各个模块、构件进行测试。
2.可应用传统模块、构件的各种测试方法。

十、导航测试

1.测试导航语法、语义。
2.导航语法
·导航连接是否工作
·重定向是否正确
·书签是否正确
·帧的显示
·站点地图

十一、配置测试

【服务端】
1.与兼容性测试相关，但更关注服务端的配置。
2.服务器操作系统
3.看系统数据能否被正确创建，文件能否正常部署。
4.安全性度量：网络协议、安全设施添加后，对性能影响如何。
5.前端js服务器、页面服务器、应用服务器、文件服务器、数据库服务器、Hadoop服务器如何部署。
6.是否支持代理服务器。
【客户端】
硬件、操作系统、浏览器、UI组件、控件、插件、网络连接。

十二、安全性测试

1.WebApp在互联网、企业网络上，均面临较多的安全挑战。
2.测试DoS攻击、脚本注入等攻击。

十三、性能测试

1.在给定用户量时，看系统响应速度是否达到要求。
2.看性能的瓶颈对应于怎样的并发量。
3.跟踪调用链，看性能瓶颈出现在哪个环节，究竟是数据库连接，还是文件处理，还是网络带宽。
4.性能对安全性是否有影响。
5.规模增加是否影响系统可靠性。

十四、负载测试

1.设\(N\)为并发用户数量，\(T\)为单位时间的在线事务数量，\(D\)为服务器每个事务处理的数据量，则总的吞吐量为：
\(P = N \times T \times D\)

十五、压力测试

1.严格并发、并发、在线用户的概念是有区别的。
2.压力测试主要看：系统的负载超过临界值时，系统会有怎样的表现，是否优雅。
3.负载超标时，事务是否会丢失，数据完整性是否会受到影响。

第二十八章 形式化建模和验证

一、净室软件工程与形式化方法

1.共性
·使用专用的规范方法，用专门语言定义需求，以及独特的验证(verification)方法（数学方法）。
·十分严格，但都未被广泛用于软件工程社区。
2.应用场景
·导弹、航天等，安全性要求极高，但规模不大的软件。

二、净室技术

1.增量模式
2.过程
·需求汇聚
·基于盒子结构进行规范
·形式化设计
·正确性验证（用数学方法验证设计是否完备、所有需求是否已覆盖）
·代码检查
·使用统计学方法生成测试用例
·确认(certification)（确认当前增量的需求、规范是否实现）

三、功能声明

基于盒子结构进行规范
·顶层：黑盒
·中间：状态盒
·底层：白盒/净室(clear box)，各状态、过程均得到清晰定义。

四、净室设计

1.设计完善(design refinement)
·序列
·条件
·循环
2.设计验证
·希望每个设计的实现都能达到零缺陷水平
·效果好于单元测试

五、净室测试

1.利用统计学方法进行测试
2.确认(certification)
·采样模型：从测试用例中随机采样
·构件模型
·确认模型

六、形式化方法

1.传统specification的问题
·矛盾、歧义、模糊、不完整、抽象层次混淆
2.形式化specification
·定义各类语言，追求一致性、完整性、不模糊性。
·形式化语言让设计只能按照一种方式理解，不存在歧义。
3.概念
·数据不变
·状态
·操作、前驱条件、后继条件

第三十四章 项目调度

一、项目工期延迟的原因

1.不现实的ddl：客户确定ddl，一般比较急，并且客户错误认为软件可以很快完成开发；或是软件开发公司高级经理的要求。
2.用户需求更改：商业模式、使用环境等的变换。
3.对项目资源需求、工作量估算不足。
4.可预测、不可预测的风险。
5.技术困难
6.人员困难：不同团队成员存在分歧。
7.沟通：开发团队与用户沟通不畅，导致办事效率低，或需求变更带来的影响扩大，或客户不信任。

二、调度原则

1.分解（compartmentalization）：分解为小型任务。
2.关联性：识别各个任务的关联。
3.工作量确认(effort validation)：确认每个任务需要多少工作量和资源。
4.定义责任：每个任务落实到具体的人，确认ddl和任务目标。
5.定义输出：定义每个任务的产出。
6.定义里程碑（关键delivery）：用于进行质量复审。

三、工作量和发布时间的关系

1.关系
·impossible region
·时间越长，工作量开销（人员投入量）越低。
·工作量开销先降后升。
2.寻找足够好的发布时间（如图中\(t_d\)）
3.模拟曲线方程
\(E_a = m\frac{t_d^4}{t_a^4}\)

四、工作量分配

1.前端活动——\(40\%-50\%\)
·用户沟通
·分析
·设计
·复审、修改
2.构建活动——\(15\%-20\%\)
·编程/代码生成
3.测试和安装——\(30\%-40\%\)
·单元测试、集成测试
·白盒测试、黑盒测试
·回归测试

五、任务集合定义

1.分析项目特征，定义项目类型
2.识别改造原则
3.选择合适的软件开发任务

六、任务集合完善

·Concept scoping：定义项目的整体范围。
·得到任务树

七、任务网络定义

·任务排序、识别任务关联，得到任务网络图(PERT图)。
·关键路径：路径上任一结点均不能延期，否则会导致整个任务延期。

八、甘特图(Timeline Charts)

·表明各个任务的起止时间范围，能够清晰地看到每个时间节点进行的所有任务，便于对每个任务进行状态跟踪。
·左侧：活动结点树。
·右侧：时间刻度。

九、使用自动化工具定义甘特图

·菱形：关键结点

十、调度跟踪

1.进行周期性项目状态会议
2.对各类复审结果进行评估
3.确认里程碑是否按期完成
4.对比：计划开始时间、实际开始时间。
5.非正式会议：获取参与者对进程的主观估计，以及问题。
6.获得值分析(earned value analysis)

十一、OO项目的里程碑

1.OO分析完成
2.OO系统设计完成（UI、数据库、体系结构、构件设计）

十二、获得值分析(EVA)

1.计划时间VCWS
2.实际时间ACWP
3.实际计划完成时间BCWP
4.总计划时间BAC
5.调度出入：SV = BCWP - BCWS
6.开销出入：CV = BCWP - ACWP

期末

[选择题]
课程网站
[大题]
1.需求分析：会画用例图、类图、CRC卡片、状态图
2.设计：体系结构设计（分层：如何画图-前端、中台、后台及其联系方式；传统：了解）、trade-off及其参考依据、构件设计（怎么一回事）、UI设计（三个原则、过程）、WebAPP设计（导航、内容设计）
3.测试：战略（单元、集成、系统、样例、导航、\(\alpha/\beta\)测试）、技术（路径测试、循环因子、循环测试）
4.过程：通用过程五步骤、惯例模型、敏捷开发过程
5.评价
6.估算、配置管理、更改管理、SQA、风险管理、技术复审