PPT 01 人机交互概述

什么是人机交互？

人机交互是解决终端用户与技术的“最后一公里”

人机交互是一门关注为人类使用而设计、评估和实现交互式计算机系统的学科，同时研究围绕人与计算机互动的主要现象。

什么是用户体验？

用户体验包含了终端用户与公司、其服务及其产品交互的所有方面。

用户体验是人与生俱来的感受能力

不能够设计用户体验，只能为用户体验而设计

人机交互、用户体验与交互设计的关系与区别

人机交互 Human-Computer Interaction

• 较为学术化
• 常见于计算机专业研究人员
• 如今也包含体验的诸多方面

用户体验 User Experience

• 广泛的用户基础

• 受业界青睐

• 常见于产品设计、工业 设计领域

交互设计 Interaction Design

• 泛指关于交互式产品和服务的设计

HCI的重要性

市场角度

• 用户期望简单易用的系统

• 对设计低劣系统的容忍度越来越差

企业角度

• 提高员工的生产效率
• 降低产品的开发成本
• 降低产品的后续支持成本

用户角度

• 获得较高的主观满意度

• 减少时间、金钱、生命损失

PPT 02 人机交互历史

四大阶段

主要分四个阶段

批处理阶段 (1940s - 1950s)

特征： 每次只能由一个用户操作，使用机器语言（01串）编写程序。

局限： 不符合人的习惯，耗时且易出错，仅限少数专业人士使用。

代表： 1946年的 ENIAC。

联机终端/命令行界面时代 (1950s - 1960s)

特征： 出现命令行界面（CLI），属于一维界面。命令名称的缩写在一定程度上减轻了用户的使用负担。

局限： 回车后不可修改命令内容，对输入要求非常严格。

图形用户界面 (GUI) 时期 (1960s - 1990s)

特征： 引入 WIMP 界面（窗口、图标、菜单、指点设备） ，该界面属于二维半界面。用户可在窗口内选取任意交互位置，且不同窗口之间能够叠加。

核心理念： “直接操纵”是 GUI 的主要特征。

问题：图形用户界面优于字符界面？

不同的交互方式本身在可用性方面并没有根本性的不同，更重要的是认真对待界面设计的态度。

下一代界面 (1990s 至今)

著名的人物与事件

重要系统与商业里程碑

VisiCalc (1979): Apple II 上的电子表格软件，为非技术用户带来了巨大价值。

Xerox Alto (1973): 真正意义上的首台个人计算机，集成了键盘、显示器、图形界面和以太网技术。

Xerox Star (1981): 首个为商务人员设计的商用 GUI PC，也是首个基于可用性工程（原型设计、迭代改进）的系统。

IBM PC (1981): 标志着人类正式进入个人电脑时代，改变了生活和工作方式。

Apple Lisa (1982): 概念成功但商业失败的文档处理工作站。

Apple Macintosh (1984): 凭借低价、友好界面和支持第三方应用获得巨大商业成功。

未来的人机交互

多媒体界面

• 引入动画、音视频等动态媒体

• 二维半-> 三维 或更高

多通道交互技术

• 具有并行性，可同时接收来自多个通道的信息

虚拟现实、语音交互、脑机交互

PPT 03 交互设计的原则和目标

交互框架

作用

提供理解或定义某种事物的一种结构

能够帮助人们结构化设计过程

认识设计过程中的主要问题

有助于定义问题所涉及的领域

执行/评估活动周期EEC

最有影响力的框架

用用户视角探讨人机界面问题

定义了活动的四个组成部分

• 目标(Goal) ≠意图(Intention)
• 执行(Execution)
• 客观因素(World)
• 评估(Evaluation)

共有七个阶段

• 1-4：执行阶段

• 5-7：评估阶段

• 1形成目标 $\rightarrow$ 2形成意图 $\rightarrow$3 明确动作 $\rightarrow$ 4执行动作 $\rightarrow$ 5感知系统状态 $\rightarrow$ 6解释系统状态 $\rightarrow$ 7评估输出

核心概念：目标 vs. 意图：一个目标可以对应多个意图（例如：删除文档可以通过菜单或删除按钮），每个意图可包含一系列活动。

两个隔阂 (Gaps)

EEC 模型解释了界面易用性问题的根源：

• 执行隔阂：用户为达目标制定的动作与系统允许动作之间的差别。
• 评估隔阂：系统状态的实际表现与用户预期之间的差别。

意义

• 如何才能够使用户简单地确定哪些活动是被允许的
• 如何确定系统是否处于期望的运行状态等问题

扩展 EEC 模型

EEC模型不能描述人与系统通过界面进行的通信

引入了翻译 过程，包含四个构成部分 ：

1. 系统：使用内核语言 (Core Language)。
2. 用户：使用任务语言 (Task Language)。
3. 输入：输入语言。
4. 输出：输出语言。

执行阶段

• 定义，执行，表现

• 设计人员应保证从输 入到系统的翻译是容易的

评估阶段

• 观察

可用性目标

目的是为交互设计人员提供一个评估交互式产品和用户体验各方 面的具体方法

易学性（learnability）

指使用系统的难易。用户准备花费多少时间学习一个产品？让用户学会执行某种任务需要花费多长时间

易记性（memorability）

学会使用并记住该产品如何使用的难易程度。学会某个系统后，应能够迅速回想起它的使用方法，而不必重复学习

影响因素

• 意义：有意义的图标、命令名和菜单项
• 位置：将特定对象放在某个特殊位置
• 分组：对事物按照逻辑进行恰当的分组
• 惯例：尽可能使用通用的对象或符号
• 冗余：使用多个感知通道对信息进行编码

启发：要良好组织，使用用户已有的经验帮助提高易记性

效用性（utility）

产品是否提供了正确且功能强大的工具，可以让用户做他们需要做的或想做的事情

高效率（efficiency）

效率指熟练用户到达学习曲线上平坦阶段时的稳定绩效水平

安全性（safety）

避免用户发生危险和陷入不好的情形

• 第一个层面和工效学相关，如在特殊环境中允许远程操控计算机

• 第二个层面指帮助任何用户在任何情况下避免因偶然执行不必要的行动而造成的危险，包括

  • 用户对出错可能导致的后果引起的恐惧
  • 恐惧心理如何影响用户行为

建议：

• 减少按键/按钮被误启动的风险
• 为用户提供各种出错时的恢复方法

用户体验目标

涵盖用户在交互时的情绪和感受。

• 与可用性的关系：主观vs.客观。有时会产生矛盾。例如，游戏可能故意违反可用性（增加挑战性）以提升有趣性，因此有些可用性和用户体验目标是不兼容的。
• 超越可用性：某些网站的核心是“说服或影响”，而非高效完成任务（如网上商店）。

简易可用性工程

特点

• 以提高产品的可用性为目标的先进的产品开发方法论
• 借鉴了许多不同领域的方法和技术->降低复杂性
• 强调以人为中心来进行交互式产品的设计研发

四种主要技术：

用户和任务观察

第一步：了解产品的目标用户。要直接与潜在用户进行接触。“你”不是用户。

场景（原型）

简便易行的原型工具，通过省略来减少实现的复杂性

• 水平原型：减少功能的深度，获得界面的表层

• 垂直原型：减少功能的数量，对所选功能进行完整实现

边做边说法

让真实用户在使用系统执行一组特定任务的时候，讲出他们的所思所想，可了解用户为什么这样做，并确定其可能对系统产生的误解

最有价值的方法

启发式评估

由专家根据规则评估。

• 结论：5名专家通常能发现约 80% 的可用性问题。

常用组合：

• 启发式评估+边做边说
• 访谈+问卷调查

设计规则

Alan Dix 的基本规则

• 可学习性：新用户能开始有效交互并能获得最大的性能。
• 灵活性：用户和系统交换信息的方式多样。
• 健壮性：支持用户决定成就（我刚才的操作成功了吗）和目标评估（系统现在的状态，是我想要的状态吗？）。

Shneiderman 的 8 黄金规则

1. 尽可能保证一致。
2. 符合普遍可用性（考虑新手与专家，残疾与健康等）。
3. 提供信息丰富的反馈（操作越不常用，反馈应越丰富）。
4. 设计说明对话框以生成结束信息（让用户知道任务已完成）。
5. 预防并处理错误（如灰色屏蔽不可选菜单）。
6. 让操作容易撤销。
7. 支持内部控制点（用户应是主动者而非响应者，避免模态对话框）。
8. 减轻短时记忆负担（显示尽可能简单）。

Nielsen 的 10 项启发式规则

1. 系统状态可见度：用时超过 3-5 秒的操作需显示进度条等反馈。
2. 系统与现实世界吻合：使用用户熟悉的词汇，遵循现实惯例。
3. 用户享有控制权和自主权：提供撤销、重做和返回主页的链接。
4. 一致性和标准化：产品内部术语、图标、颜色、布局一致。
5. 避免出错：例如通过日期选择器代替手动输入。
6. 依赖识别而非记忆：例如显示最近转账记录。
7. 使用的灵活性和高效性：为专家提供快捷键或缩写。
8. 帮助用户识别、诊断和恢复错误：错误信息应使用通俗语言，不使用代码，并提示解决方法。
9. 帮助和文档：应易于搜索，使用标准术语。
10. 审美感和最小化设计：对话框不应包含无关信息；用标准且常用的控件；选择适合屏幕显示的字体/字号，以最大化可读性

PPT 04 交互式系统的需求

交互设计过程

背景

无论取代或更新已有系统，还是开发新产品，需求的建立都是非常重要的

需求获取是项目设计的第一个阶段

• 确定和记录现有的工作流程：收集

• 将信息组织起来，涵盖工作的各方面：描述

产品是不同的：对需求提出了特殊的要求

用户是不同的

需求是什么

定义：关于目标产品的一种陈述，它指定了产品应做什么，或者应如何工作。它应该是具体、明确和无歧义的

**需求活动：**搜集数据 -> 解释数据 -> 提取需求

产品与用户特性

产品特性

1. 功能

2. 物理条件（移动设备屏幕显示限制等 ）

3. 使用环境

• 物理环境：如操作环境中的采光、噪音和尘土状况
• 社会环境：是否要共享数据，同步还是异步？
• 组织环境：用户支持的质量、响应速度如何？是否提供培训资源或设施？
• 技术环境：运行平台与兼容性

用户特性与体验水平

1. 心理学原理部分，假设每个人都有相似的能力和局限性

   • 合理的，心理学原理可以适用于大多数人

2. 交互产品设计人员应该意识到用户并不是完全相同的，在设计中体现差异

3. 用户差异：体验水平、年龄、文化、健康

体验水平差异设计目标：让新手快速和无痛苦地成为中间用户，避免为想成为专家的用户设置障碍。让中间用户感到愉快

1. 新手用户：敏感且易产生挫折感。设计应让学习过程快速、有针对性，提供向导式对话框，菜单项需具解释性。
2. **专家用户：欣赏强大功能，不被复杂性干扰。设计应提供快速访问常用工具集的手段（如快捷键、宏）。
3. 中间用户：人数最多、最稳定的群体。设计应使用工具提示 (Tooltip)** 和在线帮助，并将常用功能放在界面中心。

• 其他差异：需考虑老年人（视觉/灵活性支持）、儿童（多种输入模式）、文化差异（符号与颜色的意义）以及健康残疾状况。

人物角色

人物角色是基于真实用户行为数据形成的综合原型，在设计过程中代表真实的人。

作用

• 解决弹性用户问题（避免开发者随心所欲编码）。
• 避免自参考设计（设计者将自己的心智模型投射给用户）。
• 处理边缘情况设计（将关注点集中在典型操作上）。

构造过程

包括拼凑（头脑风暴）、组织（分组分类）、细节（补充数据）和求精四个循环反复的步骤。

需求获取与定义

获取技术

• 观察：直接观察（陪同工作）或间接观察（录音录像）。
• 场景：任务和工作结构的“非正式叙述性描述”。以讲故事的方式发掘用户目标和上下文环境。（加工成剧本）

需求定义的 5 个步骤

1. 创建问题和前景综述：反映需要改变的情况。
2. 头脑风暴：尽可能去除成见。
3. 确定人物角色的期望：使界面表现模型与用户心理模型匹配。
4. 构建情境场景剧本：专注于高层次的活动，不描述具体交互细节。
5. 确立需求：提取数据需求（对象/信息）和功能需求（操作/控件）。

原型与需求验证

原型是评估和反馈的核心，让用户在尝试中发现自己的需求。

原型的类型

• 低保真原型：使用与最终产品不同的材料（如纸张、草图、故事板）。优点是简单、快速、便宜，易于修改。
  • 绿野仙踪法：用户以为在与系统交互，实际上是开发人员在后台响应。
• 高保真原型：材料与最终产品接近。缺点是制作时间长，难以修改，且可能让用户误以为就是最终系统。

原型的重要性

• 评估和反馈是交互设计的核心

• 用户往往不能准确描述自己的需要，但在看到或尝试某些事物后，就能立即知道自己不需要什么

• 与文档相比，涉众能够更容易地看到、持有和与原型进行交互

• 团队成员能够有效沟通

• 原型回答问题，并支持设计师在备选方案中进行选择

任务分析

记录人们如何完成任务的一种方式

作用

用来了解通过观察和访谈目前参与工作流程的人收集到的数据

用于调查现有情形，而不是展望新系统或设备

分析基本原理，了解人们想要达到什么目标，如何达到这些目标，并由此建立需求

层次化任务分析（HTA）

这是应用最广的任务分析技术，通过将任务逐层分解为子任务，并组织成“执行次序”。

• 执行次序 (Plans)：说明在什么条件下执行哪些子任务。
• 终止规则：当任务包含复杂机械响应（如移动鼠标）或纯粹内部认知决断时，停止分解。

PPT 05 交互式系统的设计

设计框架

设计框架应先从高层次关注用户界面和行为的整体结构，定义屏幕布局、产品工作流和组织，而非过早纠结细节。

1. 定义外形因素和输入方法：确定产品类型（如Web应用或手机产品）及其输入方式（互动形式），这取决于外形和人物角色的能力。
2. 定义功能和数据元素：识别交互中的基本主体（如相片、邮件）及对其操作的工具。
3. 决定功能组合层次：通过元素分组促进操作流程，考虑容器组织、元素相邻关系及步骤次序。
4. 勾画大致设计框架：使用简单的方块图（附标签和注解）表达并区分每个视图，避免被细枝末节分散精力。
5. 构建关键情景场景剧本：描述人物角色最频繁使用界面的主要路径，重点在任务层，可使用低保真草图故事板。
6. 通过验证性场景剧本检查设计：包括关键线路的变种、必须要执行但不经常发生的情况（必须使用场景）以及边缘情形。

视觉设计与情绪板

• 情绪板作用：通过代表用户情绪的文本、元素和图片，客观表达设计理念，定义色彩、图形、质感、构图和字体五大内容。
• 制作步骤：寻找关键词（来自战略、功能或用户需求）—> 关键词联想 —> 搜索匹配图片 —> 创建情绪板 —> 最终视觉设计。
• 审美与实用：一个漂亮的界面不一定是好界面。应根据语义和任务因素进行视觉组织，先实现良好的基本布局，再改进美学效果。

软件设计中的关键考虑

个性化与配置

个性化需简单易用、容易撤销并提供预览；配置则是为经验丰富的用户提供移动、增删对象的权利。

本地化和国际化

国际化

指在设计软件时，将软件与特定语言及地区脱钩的过程

当移植到不同的语言及地区时，软件本身不用做内部工程上的改变或修正

意味着产品有适用于任何地方的“潜力”

只需做一次

本地化

当移植软件时，加上与特定区域设置有关的信息和翻译文件的过程

为了更适合于“特定”地方的使用，而另外增添的特色

针对不同的区域各做一次

审美学与实用性

漂亮的界面 != 一个好的界面

审美与实用的冲突

• 为确保文本的可读性，文本的背景采用较低的对比度

• 复杂而强烈的对比可能获奖，但不实用

交互设计角度

• 根据语义和任务因素来进行视觉组织

• 其次是视觉美学

• 先实现一个良好的基本布局，然后再在基础上进行改进来实现好的美学效果

软件设计中的考虑

• 积极的文字表达
• 消除歧义
• 让软件友好和体贴
• 有趣的用语

响应时间与等待感

利用程序空闲时间（如索引硬盘） ；通过反馈（如进度条）、渐进呈现结果或分散用户注意力来减少等待感。

减轻记忆负担

通过回忆用户上次的行为（如默认设置、窗口位置）来预测操作。

减少用户的等待感

以某种形式的反馈让用户了解操作进行的进度和状态

以渐进方式向用户呈现处理结果

设计好的出错信息

四个简单原则

• 使用清晰的语言来表达，而不要使用难懂的代码
• 使用的语言应当精炼准确，而不是空泛而模糊的
• 对用户解决问题提供建设性的帮助
• 出错信息应当友好，不要威胁或责备用户

模式

交互设计模式

模式捕捉的只是良好设计中不变的特性

具体实现，将取决于环境和设计者的创造性

模式不是拿来即用的商品，每一次模式的运用都有所不同

主导航模式

轮播模式

简化设计的四种策略

删除 (Delete)

删除从未使用或极少使用的杂乱特性，让设计专注于核心功能和真正有价值的内容。同时需删除视觉混乱，删减文字。如用空白代替线条、减少元素大小和形状的变化。

组织 (Organize)

最快捷的简化方式 。通过分块（7±2法则）和利用不可见的网格对齐元素，使布局清晰 。

隐藏 (Hide)

隐藏不常用、事关细节或特定于地区的功能，避免分散主流用户注意力 。采用渐进展示，在合适的时机和位置显示功能 。

转移 (Transfer)

在不同设备间转移（如手机收集数据，网站查看细节） ；或向用户转移，搞清楚把什么工作交给计算机（执行、计算、检索），把什么留给用户（设定目标、估算、想象） 。

卡片分类

定义：让参与者对物体（照片、词语）或概念、术语进行分类，帮助用户找到所需信息 。

优点：是研究问题域中用户观点的高效、低代价方法，可用于布局研究 。

分类：定性研究（人数少，纸质卡片）和定量研究（至少15人，纸质或在线） 。

PPT 06 评估的基础知识

背景

评估是一个通过系统收集信息来判断产品是否满足用户需求和设计标准的过程。

• 核心目标：检查设计的表现，确保产品能解决用户面临的问题。
• 关注点：主要集中在产品的 可用性 (Usability) 和 用户体验 (User Experience) 上。
• 必要性：评估可以早期发现并纠正错误，从而降低开发成本，确保产品高质量。

评估的四个“W”

Why-为什么要评估？

用户不仅期望一个可用的系统，还在追求愉悦感与参与感

对企业而言，好的设计有很大卖点；设计师可以专注于真实问题和不同用户群体的需求，而非与人们对喜爱与厌恶之处进行辩论

What-评估什么？

对象：原型、可运行系统、特定屏幕功能、完整工作流程、审美设计、安全性等等

Where-在哪里评估？

取决于正在评估的对象，实验室环境或实地环境

When-何时开展评估？

取决于产品的类型

形成性评估：在设计和开发过程中进行，目的是改进产品设计。

总结性评估：在产品交付或发布阶段进行，目的是评估最终成效。

评估原则

**评估应该依赖于产品的用户。**与专业技术人员的水平和技术无关

**评估与设计应结合进行。**仅靠用户最后对产品的一两次评估，是不能全面反映出软件可用性的

**评估应在用户的实际工作任务和操作环境下进行。**根据用户完成任务的结果，进行客观的分析和评估

**要选择有广泛代表性的用户。**参加测试的人必须具有代表性

评估范型

快速评估

非正式地快速获取用户反馈，以低成本验证想法。

可用性测试

评测典型用户执行典型任务时的情况，以量化表示用户的执行情况

是在评估人员的密切控制之下实行的（实验室）

缺点

• 测试用户的数量通常较少
• 不适合进行细致的统计分析

实地研究

在自然工作环境中进行

理解用户的实际工作情形以及技术对他们的影响

重难点

• 如何不对受试者造成影响
• 控制权在用户，很难预测即将发生和出现的情况

预测性评估

专家根据可用性准则或模型预测可能出现的问题，无需用户参与。

PPT 07 观察用户

Goetz and Lecomfte框架

人员：有哪些人员在场？他们有何特征？承担什么角色？

行为：人们说了什么？做了什么？举止如何？是否存在规律性的行为？语 调和肢体语言如何？

时间：行为何时发生？是否与其他行为相关联？

地点：行为发生于何处？是否受物理条件的影响？

原因：行为为何发生？事件或交互的促成因素是什么？不同的人是否有不 同的看法？

方式：行为是如何组织的？受哪些规则或标准的影响？

Robson框架

有助于组织观察和数据搜集活动

空间：物理空间及其布局如何？

行为者：涉及哪些人员？人员详情？

活动：行为者的活动及其原因？

物体：存在哪些实际物体（如家具）？

举止：具体成员的举止如何？

事件：所观察的是不是特定事件的一部分？

目标：行为者希望达到什么目标？

感觉：用户组及个别成员的情绪如何？

PPT 08 询问用户和专家

询问用户之访谈

访谈：有目的的对话过程

• 开放式（或非结构化）访谈，结构化访谈，半结构化访谈和集体访谈

指导原则

• 避免过长的问题
• 避免使用复合句
  • “这款手机与你先前拥有的手机相比，你觉得如何”
  • “你觉得这款手机怎么样？你是否有其他的手机？若是的话，你觉得它怎么样？”

避免使用可能让用户感觉尴尬的术语或他们无法理解的语言

避免使用有诱导性的问题

• 你为什么喜欢这种交互方式？

尽可能保证问题是中性的

访谈步骤

“开始”阶段

• 访问人先介绍自己
• 解释访谈的原因，消除受访人对道德问题的疑虑，询问受访人是否介意被

记录（录音或摄像）

“热身”阶段

• 先提出简单的问题

主要访谈阶段

• 按逻辑次序由易到难提问

“冷却”阶段

• 提出若干容易的问题，消除用户的紧张感觉

结束访谈

• 感谢受访者，关闭录音机，收好笔记本，表面访谈已经结束

访谈类型

非结构化访谈

• 问题是开放式的，不限定内容和格式

• 受访人自行选择详细回答还是简要回答

• 访问人应确保能够搜集到重要问题的回答

结构化访谈

• 根据预先确定的一组问题进行访谈

• 问题通常是“封闭式”的，它要求准确的回答

半结构化访谈

• 开放式问题+封闭式问题

• 注意不要暗示答案

集体访谈

• 基本思想：个别成员的看法是在应用的上下文中通过与其他用户的交流而形成的

• “焦点小组”是集体访谈的一种形式

焦点小组

非正式的评估方法

由大约6到9个典型用户组成

焦点小组存在风险

询问用户之问卷调查

问卷调查是用于搜集统计数据和用户意见的常用方法

问卷设计原则

• 应确保问题明确，具体
• 在可能时，采用封闭式问题并提供充分的答案选项
• 对于征求用户意见的问题，应提供一个“无看法”的答案选项
• 注意提问次序，先提出一般化问题，再提出具体问题
• 避免使用复杂的多重问题
• 在使用等级标度时，应设定适当的等级范围，并确保它们不重叠、直观、一致
• 避免使用术语
• 明确说明如何完成问卷，如说明应在选项前的方框内打“√”
• 在设计问卷时，既要做到紧凑，也应适当留空

询问专家之认知走查

评估应该贯穿于整个设计过程中

认知走查

• 逐步检查使用系统执行任务的过程，从中找出可用性问题
• 无需用户参与
• 认知走查的主要目标是确定使一个系统如何易于学习
• 试图想象出人们在第一次使用某个产品时的想法以及所采取的动作，它的大体流程是怎样的
• 评估的具体过程就是把用户在完成这个功能时所做的所有动作讲述成一个令人可以信服的故事

走查的步骤

标识并记录典型用户的特性

基于评估重点，设计样本任务（典型任务）

制作界面原型（或界面描述），明确用户执行任务的具体步骤

由设计人员和专家级评估人员（一位或多位）共同进行分析

评估人员检查每项任务的操作步骤

• 可预见：正确的操作对于用户是否足够明显？（即用户能否知道如何完成任务）
• 可理解：用户能否注意到正确的操作？（功能名称或图标设计是否容易理解）
• 可解释：能否正确解释操作的响应？

在完成逐步检查之后，汇总关键信息

修改设计，更正发现的问题

协作走查

由用户、开发人员和可用性专家合作，逐步检查任务场景，讨论与对话元素相关的可用性问题

• 在评估过程中，每一位专家都承担用户的角色

优点

• 专注于用户任务；能够产生定量数据

• 符合参与式设计原则

缺点

• 需要各方面的专家，速度慢

• 由于时间限制，通常只能评估有限的场景

询问专家之启发式评估

灵活而又相当廉价的评估方式

由可用性专家完成（3-5个可用性专家）

步骤：

• 彻底检查界面

• 将界面与启发式规则进行对比

• 列举可用性问题

• 应用启发式规则对每一个问题进行解释与确认

问题的严重性分类

不同作用因素：频率、持续时间、影响（多难克服？）

严重性等级

• 表面问题：不需要被修复

• 次要问题：需要修复，但优先级较低

• 主要问题：需要修复且优先级很高

• 灾难性问题：必须被修复

如何正确评估

分析每个问题对应的启发式规则

• 如“主页上有太多选项”对应“审美与最小化设计”

• 不能简单地说“我不喜欢它的颜色”

列出所有问题

• 即便可能某个界面元素存在多个问题

至少遍历两次界面

• 一次获得系统的初始体验

• 另一次关注特定界面元素

不要局限于10条启发式规则

• 还有各种affordances、constraints、颜色原理等

PPT 09 用户测试

DECIDE评估框架

D (Determine Goals)：决定评估需要完成的总体目标（如：寻找最佳隐喻、测试特定功能）。

E (Explore Questions)：发掘需要回答的具体问题。

C (Choose Paradigm & Techniques)：选择评估范型和技术

I (Identify Practical Issues)：标识/明确必须解决的实际问题（如：招募用户、准备设备、安排预算和时间）。

D (Decide Ethical Issues)：决定如何处理伦理问题（如：签署知情同意书、保护用户隐私、数据保密）。

E (Evaluate, Analyze & Present)：评估，对收集的数据进行科学分析并展示结果。

• 搜集什么类型的数据，如何分析，如何表示
• 可靠性
• 有效性
• 偏见
• 范围
• 环境影响

小规模试验

对评估计划进行小范围测试

• 以确保评估计划的可行性

• 如检查设备及使用说明

• 练习访谈技巧

• 检查问卷中的问题是否明确

小规模试验可进行多次

• 类似迭代设计

• 测试——反馈——修改——再测试

• 快速、成本低

可用性问题分级

评估结果总是可用性问题清单，以及改进建议

方法一：基于量化数据的分级。如多少人遇到该问题，耗费多少时间等

方法二：问题严重性的主观打分，取平均值

方法三：可用性分级的两个因素

• 多少用户会遇到这个问题
• 用户受该问题影响的程度

方法四：该问题只在第一次使用时出现，还是会永远出现

测试设计

用户测试须考虑实际限制并做出适当的折衷

• 应确保不同参与者的测试条件相同

• 应确保评估目标特征具有代表性

• 实验可重复，但通常不能得到完全相同的结果

• 以DECIDE框架为基础

1：定义目标和问题

• 目标描述了开展一个测试的原因，定义了测试在整个项目中的价值

• 目标是对关注点的说明和解答

2：选择参与者

• 参与者的选择对于任何实验的成功至关重要

• 了解用户的特性有助于选择典型用户，所以要尽可能接近实际用户

• 通常也需要平衡性别比例

• 越多越好，通常20-30比较恰当（视情况而言）

参与者安排

• 各种实验情形的参与者不同

• 各种情形的参与者相同

• 参与者配对

  • 	描述	缺点	优点
    参与者不同	随机指派某个参与者组执行某个实验情形	要求有足够多的参与者 实验结果可能会受到个别参与者的影响	不存在“顺序效应”
    参与者相同	相同的参与者执行所有实验情形，与前一种方法相比，它只需一半的参与者	可能产生“顺序效应”	能够消除个别差异带来的影响
    参与者配对	根据用户特性，把两位参与者组成一组，再随机地安排他们执行某一种实验情形。适用于参与者无法执行两个实验的情形	实验结果可能会受一些未考虑到的重要变量的影响

3：设计测试任务

• 测试任务应当与定义的目标相关
• 测试任务通常是简单任务
• 有时采用较为复杂的任务
• 任务不能仅限于所要测试的功能，应使用户全面的使用设计的各个区域
• 每项任务的时间应介于5~20分钟
• 应当以某些合乎逻辑的方法安排任务

4：明确测试步骤

• 在测试之前，准备好测试进度表和说明，设置好各种设备

• 正式测试前应进行小规模测试

• 在必要时，评估人员应询问参与者遇到了什么问题

• 若用户确实无法完成某些任务，应让他们继续下一项任务

• 测试过程应控制在1小时之内

• 必须分析所有搜集到的数据

5：数据搜集

• 确定如何度量观测的结果

• 使用的度量类型（定性/定量）依赖于所选择的任务

分析方法

定量数据：常用的有次数统计、平均数统计

定性数据：通常按主题分类

总结报告

将测试的结果以书面形式反馈给产品的设计人员，以便于他们对设计进一步的分析和改进

PPT 10 基础知识

格式塔心理学

相近性原则

空间上比较靠近的物体容易被视为整体。因此设计界面时，应按照相关性对组件进行分组

相似性原则

人们习惯将看上去相似的物体看成一个整体。因此功能相近的组件应该使用相同或相近的表现形式

连续性原则

共线或具有相同方向的物体会被组合在一起。因此将组件对齐，更有助于增强用户的主观感知效果

对称性原则

相互对称且能够组合为有意义单元的物体会被组合在一起

完整和闭合性原则

人们倾向于忽视轮廓的间隙而将其视作一个完整的整体。因而页面上的空白可帮助实现分组

人脑记忆结构

感觉记忆

又称瞬时记忆

在人脑中持续约为1秒钟，帮助我们把相继出现的一组图片组合成一个连续的图像序列，产生动态的影像信息

短时记忆

感觉记忆经编码后形成

又称工作记忆，约保持30秒

储存的是当前正在使用的信息，是信息加工系统的核心，可理解为计算机的内存

短时记忆的存储能力约为7±2个信息单元

长时记忆

短时记忆->长时记忆

• 短时记忆中的信息经进一步加工后会变为长时记忆

• 只有与长时记忆区的信息具有某种联系的新信息才能够进入长时记忆

长时记忆的信息容量几乎是无限的

启发

• 注意使用线索来引导用户完成特定任务

• 在追求独特的创新设计时也应注重结合优秀的交互范型

遗忘

• 长时记忆中的信息有时是无法提取，但这不代表长时记忆区的信息丢失了

易出错

• “人为错误”被定义为“人未发挥自身所具备的功能而产生的失误，它可能降低交互系统的功能”
• 从表面上看是由于用户的误解、误操作或一时大意
• 大部分交互问题都源于系统设计本身

界面类型

基于命令的界面

用户通过在屏幕某个位置上键入特定命令或靠组合键的方式来执行任务

优点

• 专家用户能够快速而精确地完成任务；

• 较GUI节约系统资源；

• 可动态配置可操作选项；

设计和研究问题

• 命令的形式、语法和组织

• 选择易于标记/命名命令的方法应尽可能一致

WIMP和GUI

WIMP全称：Window, Icon, Menu, Pointing

GUI的全称：Graphical User Interface

GUI的演化：更少的记忆、更多的识别、更少的键盘和点击、更不易出错、以及更可视的上下文

多媒体界面

在单个界面中组合不同的媒体，即图形、文本、视频、声音和动画，并将他们与各种形式的交互相连接

优点

• 媒体和交互性的组合可以比其中任何一个提供更好的呈现信息的方式

• 增强了快速访问多种信息的能力

• 更易学习、更好理解、更多的参与度和乐趣

研究和设计问题：多媒体内容设计。何时使用音频与图形、声音与动画？

虚拟现实和增强现实

Virtual Reality & Augmented Reality

信息可视化和仪表盘Dashboard

信息可视化

• 通过计算复杂数据生成的图形，通常是可交互且动态的，其目标是提高发现、决策、解释现象的能力

仪表盘

• 一种日益流行的可视化信息形式，往往是不可交互的，数据旨在描述系统或过程的当前状态

笔式交互和触摸交互

手势界面

借助相机、传感器和计算机视觉技术，可以准确识别人的身体、手臂和手势

实物界面Tangible Interface

通常基于传感器，物理对象与数字表示相结合

优点

• 可以创造性地操纵，使得动态信息以不同方式呈现
• 支持多人一起探索

可穿戴计算

脑机界面

PPT 11 交互设计模型

背景

设计学科通常借助模型生成新的想法并对其测试

交互设计领域

• 计算用户完成任务的时间：KLM
• 描述交互过程中系统状态的变化：状态转移网
• 探讨任务的执行方法等：GOMS

预测模型

能够预测用户的执行情况，但不需要对用户做实际测试

适合于无法进行用户测试的情形

不同模型关注用户执行的不同方面

• GOMS

  • 击键层次模型KLM

• Fitts定律

GOMS模型

最著名的预测模型

1983年由Card, Morgan和Newell提出

是关于人类如何执行认知—动作型任务以及如何与系统交互的理论 模型

• 采用“分而治之”的思想，将一个任务进行多层次的细化
• 把每个操作的时间相加就可以得到一项任务的时间

Goal-目标

用户要达到什么目的

Operator-操作

任务执行的底层行为，不能分解，即为达到目标而使用的认知过程和物理行为，如点击鼠标。

Method-方法

如何完成目标的过程，即对应目标的子目标序列和所需操作

如移动鼠标，输入关键字，点击Go按钮，使用菜单删除文本

Selection-选择规则

确定当有多种方法时选择和方法

GOMS认为方法的选择不是随机的

GOMS模型分析

优点

能够容易地对不同的界面或系统进行比较分析

美国电话公司 NYNEX 利用GOMS分析一套即将被采用的新的计算机系统的应用效果不理想，放弃了使用新系统，为公司节约了数百万的资金。

局限性

假设用户完全按一种正确的方式进行人机交互，没有清楚地描述错误处理的过程

只针对那些不犯任何错误的专家用户

任务之间的关系描述过于简单

忽略了用户间的个体差异

KLM (Keystroke-Level Model - 击键层次模型)

对用户执行情况进行量化预测，仅涉及任务性能的一个方面：时间

用途

• 预测无错误情况下专家用户在下列输入前提下完成任务的时间

• 便于比较不同系统

• 确定何种方案能最有效地支持特定任务

K (Keystroke)：按键或点击

P (Pointing)：移动鼠标到目标位置

H (Homing)：手在键盘和鼠标之间切换

M (Mental preparation)：心理准备/思考

R (Response)：系统响应时间

放置M操作符的启发规则

1: 在每一步需要访问长时记忆区的操作前放置一个M

2: 在所有K和P之前放置M

K -> MK; P -> MP

3：删除键入单词或字符串之间的M

MKMKMK -> MKKK

4：删除复合操作之间的M (如, 选中P和点击P1)

MPMP1-> MPP1

Fitts定律 - 菲茨定律

用于预测用户移动到目标区域（如按钮）所需的时间。

三个部分

困难指数ID (Index of Difficulty) = log2(A/W + 1) (bits)

• 对任务困难程度的量化

• 与宽度和距离有关

运动时间MT (Movement Time) = a + b*ID (secs)

• 在ID基础上将完成任务的时间量化

性能指数IP (Index of Performance) = ID/MT (bits/sec)

• 基于MT和ID的关系

• 也称吞吐量

Fitts定律建议

• 大目标、小距离具有优势
• 屏幕元素应该尽可能多的占据屏幕空间
• 屏幕元素应尽可能利用屏幕边缘的优势
• 最好的像素是光标所处的像素
• 大菜单，如饼型菜单，比其他类型的菜单使用简单

Hick’s Law

一个人拥有的选择越多，他们做决定的时间就越长。

PPT 12 以用户为中心

背景

把人置于系统设计过程的中心

以用户为中心

• 以真实用户和用户目标作为产品开发的驱动力，而不仅仅是以技术为驱动力

• 应能充分利用人们的技能和判断力，应支持用户，而不是限制用户

• 需要透彻了解用户及用户的任务，并使用这些信息指导设计

• 这是一种设计思想，而不是纯粹的技术

工程设计过程的三个假设

设计的结果是一种产品（成品、机器或系统）；

产品通过由客户给出的规格说明导出。原则上，有了足够的知识和计算能力，这种导出就可以被机械化；

一旦客户和设计人员就规格说明达成一致，直到交付之前，客户和设计人员之间不大可能再需要进行接触。

后果：常导致“软件危机”，因为规格说明往往是不正确或不完备的。

以用户为中心的设计思想

侧重以人为本

重点是获得对使用拟设计系统的人的全面了解

三个方面的假设

1. 好的设计结果使客户感到满意

2. 设计过程是设计人员与客户之间的协作过程

   • 设计要进化并适应客户不断变化的考虑
   • 规格说明是该过程的副产品

3. 在整个过程中，客户和设计人员要不断沟通

以用户为中心的设计原则

及早以用户为中心

• 在设计过程的早期就致力于了解用户的需要

综合设计

• 设计的所有方面应当齐头并进地发展

及早并持续性地进行测试

• 若实际用户认为设计是可行的，它就是可行的

迭代设计

• 大问题往往会掩盖小问题的存在

• 已得到广泛重视

UCD项目包含的方法

PICTIVE

协作式产品的界面造型技术

• 使用低保真的办公室用品模型来研究系统的特定屏幕和窗口布局

目的

• 使得用户能够参与设计过程

• 改进设计过程的知识获取方法

四个阶段

• 当事人做自我介绍

• 简短讲解说明不同应用域

• 围绕设计的集策讨论

• 设计走查和决策讨论

CARD

需求和设计的协作分析

• 使用画有计算机和屏幕图像的卡片发掘

各种工作流

• 是“情节串联图”的一种形式

CARD & PICTIVE

• 侧重点不同

• PICTIVE关注的是系统细节，而CARD注重的是宏观的任务流

• 可互为补充

上下文询问法（情景调查）

观察并与用户交流会比仅仅观察的效果要好

强调到用户工作的地方，在用户工作时观察，并和用户讨论他的工作

基于“学徒模型”：用户是师傅，研究人员是学徒

上下文询问法的4个原则

上下文环境

• 应深入工作空间，以了解其中发生的事情

• 可以要求用户边做边说，也可以只在必要时发问

伙伴关系

• 开发人员和用户应相互合作

• 提醒用户是专家，将研究人员作为新手

解释

• 解释过程必须由用户和开发人员合作完成

• 杜绝设计人员片面地对事实作出解释或假设

焦点

• 把问题集中在所定的研究题目上

• 准备一个观察方向的列表

上下文询问法vs.民族志观察

一

字符串操作

$ab$：$a$和$b$连接

$s^R$：$s$反转

$|s|$：$s$的长度

语言操作

$L_1L_2$：$\{ ab \mid a \in L_1, b \in L_2 \}$

$L^n$：$L^0=\{ \epsilon \}, L^n=\{ s_1 s_2 \cdots s_n \mid s_1, s_2, \cdots, s_n \in L\}$

$L^*$：$\bigcup_{i=0}^\infty L^i$

$L^+$：$\bigcup_{i=1}^\infty L^i$

$\bar L$：$\{ s \in \Sigma^* \mid s \not\in L \}$

$L^R$：$\{ s^R \mid s \in L \}$

正则表达式

$\emptyset$：$L(\emptyset)=\emptyset$

$\epsilon$：$L(\epsilon)=\{ \epsilon \}$

$A | B$：$L(A | B)=L(A) \cup L(B)$

$AB$：$L(AB)=L(A)L(B)$

$A^*$：$L(A^*)=L(A)^*$

$(A)$：$L((A))=L(A)$

DFA

定义：$M=(Q, \Sigma, \delta, q_0, F)$，状态集合$Q$，字母表$\Sigma$，转移函数$\delta \in Q^{Q \times \Sigma}$，起始状态$q_0 \in Q$，终止状态集合$F \subseteq Q$

拓展转移记号$\delta^* \in Q^{Q \times \Sigma^*}$：一次接受多个字符进行转移

接受的语言：$L(M)=\{ s \in \Sigma^* \mid \delta^*(q_0, s) \in F \}$

NFA

定义：$M=(Q, \Sigma, \delta, q_0, F)$，状态集合$Q$，字母表$\Sigma$，转移函数$\delta \in \left(2^Q\right)^{Q \times (\Sigma \cup { \epsilon })}$，$\epsilon$转移是不消耗字符的转移，起始状态$q_0 \in Q$，终止状态集合$F \subseteq Q$

同样也定义拓展转移记号，一次接受多个字符进行转移，得到可能到达的所有状态集合

接受的语言：$L(M)=\{ s \in \Sigma^* \mid \delta^*(q_0, s) \cap F \neq \emptyset \}$

NFA到DFA

子集构造法：对于NFA$M=(Q, \Sigma \cup \{ \epsilon \}, \delta, q_0, F)$，定义一个DFA，使其状态集合为$2^Q$，每个状态对应NFA中的一组状态，转移定义为从当前这组状态出发接受给定字符后可能到达的所有状态集合，起始状态定义为$\{ q_0 \}$，终止状态集合定义为$\{ S \in 2^Q \mid S \cap F \neq \emptyset \}$，这一新DFA接受的语言和原NFA等同

由此也可以看出，DFA能接受的语言类和NFA等价，称为正则语言RL

DFA最小化

对于两个状态$q_1, q_2$，定义$k$-等价为

$$\forall s \in \bigcup_{i=0}^k \Sigma^i, \delta^(q_1, s) \in F \iff \delta^(q_2, s) \in F$$

定义$\omega$-等价为对任意自然数$k$都$k$-等价，容易验证这些“等价”关系都确实是等价关系，并且它们互相包含

DFA最小化的目标就是找到所有的$\omega$-等价类，并合并其中的状态

显然，所有非终止状态是$0$-等价的，所有终止状态也是$0$-等价的

两个状态$k+1$-等价当且仅当$\forall c \in \Sigma, \delta(q_1, c)$和$\delta(q_2, c)$是$k$-等价的

于是只需从$0$-等价开始迭代直到不动点，便找到了$\omega$-等价类，合并状态即可

DFA等价性判断

两个DFA等价当且仅当它们的起始状态$\omega$-等价

两个状态$\omega$-等价当且仅当$\forall c \in \Sigma, \delta(q_1, c)$和$\delta(q_2, c)$也是$\omega$-等价的

非终止状态和终止状态不可能$\omega$-等价。从起始状态出发，检查如果等价关系成立是否导出矛盾，即可确认两个DFA是否等价

正则语言性质

正则语言关于并集、交集（可用取反和并集构造）、连接、反转、取反、克莱尼星号封闭，具体构造略

每个正则语言都有对应的正则表达式，从DFA构造正则表达式的方法略

正则语言泵引理：考虑DFA的状态有限，足够长的字符串在DFA中必定经过重复状态。因此$\forall L \in RL, \exists C \in \mathbb{N}, \forall s \in L \wedge |s| \geq C$，存在一个分解$s=xyz, |xy| \leq C$，使得$\forall i \in \mathbb{N}, x y^i z \in L$

泵引理可用于证明一个语言不是正则语言

二

上下文无关文法

定义：四元组$G=(N, T, S, P)$，非终结符集合$N$，终结符集合$T$，$N \cap T = \emptyset$，起始符号$S \in N$，产生式集合$P$

每条产生式将一个非终结符展开为若干符号的序列，如$A \rightarrow a A b$

派生：$xAy \Rightarrow xaAby$，将字符串中的一个非终结符用某个产生式展开

连续派生：$\Rightarrow^*$，多次派生的简记

最左派生：$\Rightarrow_{lm}$，每次都展开最左侧的非终结符

最右派生：$\Rightarrow_{rm}$，每次都展开最右侧的非终结符

推导树

CFG定义的语言是所有可以由起始符号派生得到的终结符串，派生得到一个字符串的过程定义了一颗树，称为推导树

同一个字符串可能有不同的推导树，这称为二义性

一个CFG是否有二义性是不可判定的，而且有些语言存在内在二义性（不存在一个无二义性的CFG描述相同语言）

部分二义性可以使用优先级与结合性技巧消除

如$E \rightarrow E + E \mid E \times E \mid a$有二义性，可改成$T \rightarrow a \mid T \times a, E \rightarrow T \mid E + T$

NPDA

定义：七元组$P=(Q, \Sigma, \Gamma, \delta, q_0, z_0, F)$，状态集合$Q$，输入字母表$\Sigma$，栈上字母表$\Gamma$，转移函数$\delta \in (2^{Q \times \Gamma^*})^{Q \times (\Sigma \cup \{ \epsilon \}) \times \Gamma}$，起始状态$q_0 \in Q$，起始栈上符号$z_0 \in \Gamma$，终止状态集合$F \subseteq Q$

每次转移消耗一个栈顶符号，推入若干栈上符号（也可以加一个$\epsilon$转移变成不一定消耗栈顶符号的形式，容易证明有没有$\epsilon$转移都是等价的），在图上写成$S, G \rightarrow G_1G_2\cdots G_n$形式

NPDA接受的语言与NFA类似，存在一条路径在终止状态停止即可（也可定义空栈为接受，二者是等价的，证明略）

每个CFG都有一个NPDA接受它定义的语言，只需在NPDA的栈上展开符号即可，具体略

每个NPDA都有一个对应的CFG，方法和CFG到NPDA类似，方向反转即可，具体略

因此CFG和NPDA定义了同样的语言，称为上下文无关语言CFL

NPDA比DPDA更强

CFL

CFL关于并集、连接、反转、克莱尼星号封闭，关于交集不封闭（$a^n b^n c^m$和$a^n b^m c^m$是CFL，而$a^n b^n c^n$不是CFL），于是关于取反、做差也不封闭

CFL泵引理：考虑一个CFL中非终结符的数量是有限的，于是对于足够长的字符串，它的推导树深度足够大，那么一定存在一条从根出发的路径上会出现重复的非终结符，可以用更大的这颗子树替换更小的子树得到另一个字符串。因此$\forall L \in CFL, \exists C \in \mathbb{N}, \forall s \in L \wedge |s| \geq C$，存在一个分解$s=uvwxy, vx \neq \epsilon, |vwx| \leq C$，使得$\forall i \in \mathbb{N}, u v^i w x^i y \in L$

自顶向下解析

自顶向下解析：从起始符号开始逐步展开，直到展开到给定字符串

左递归消除：自顶向下解析器难以处理左递归（一个非终结符经过若干步展开后最左侧的非终结符是自己），需要使用技巧消除左递归

直接的左递归可以改写成开头加增量的的形式，如$E \rightarrow Ea \mid b$可以改写为$E \rightarrow b E’, E’ \rightarrow \epsilon \mid a E’$；间接的左递归可以展开到直接的左递归

LL(1)解析器：每次考虑最左侧的符号，消耗终结符，展开非终结符。LL(1)代表只需要提前看一个字符，就可以确定展开最左侧的非终结符使用的产生式，这使用预测分析表进行（非终结符与一个提前看符号组成的二维表$M$）

LL(1)解析器的构建使用FIRST和FOLLOW进行，FIRST是一个符号展开后所有可能的第一个终结符组成的集合（可能为空串则有$\epsilon$），FOLLOW是紧邻一个符号之后可能出现的所有终结符组成的集合（起始符号的FOLLOW有$，即字符串结尾），二者可以通过迭代传播求出，具体略

然后对于规则$A \rightarrow \alpha$，$\forall a \in FIRST(\alpha), M(A, a)=A \rightarrow \alpha$；若$\epsilon \in FIRST(\alpha)$则还有$\forall a \in FOLLOW(\alpha), M(A, a)=A \rightarrow \alpha$

自底向上解析

自底向上解析：基于栈进行，每次向栈内移入一个新符号，或者对栈内符号进行规约（折叠产生式），直到将整个给定字符串规约为起始符号就说明解析成功

LR(0)解析器：不断向栈内移入符号，直到看到某个产生式的右手侧就进行规约。检查是否看到了产生式的右手侧可以用DFA进行

语义分析

在推导树上进行类型检查和传递

三

三地址码

三地址码：每条指令包含至多三个地址

如$x = y \operatorname{op} z$，$\text{goto } L$，$\text{if } x \operatorname{op} y \text{ goto } L \text{ else goto } L’$等

语法制导定义

在产生式上附加计算规则，通过语法来定义属性的计算方式

用于计算属性、语义检查、语法制导翻译等，具体没什么好说的

SSA

SSA：每个变量只有一个定义，使用$\phi$函数合并来自不同前驱的定义，可以保证清晰的def-use链

基本块：只有单一入口和出口的一段连续指令

转换到SSA

支配：如果从程序入口到基本块$A$的任何一条路径都经过基本块$B$，称$B$支配$A$

后支配：如果从基本块$A$到程序出口的任何一条路径都经过基本块$B$，称$B$后支配$A$

严格(后)支配：若$B$(后)支配$A$，且$B \neq A$，则$B$严格(后)支配$A$

直接支配：若$B$严格支配$A$，且不存在$C \neq A, B$使得$B$支配$C$，$C$支配$A$，称$B$直接支配$A$

基本块的支配关系构成一颗有根树，每个节点的父节点是它的直接支配者

支配边界：基本块$B$的支配边界是由所有这样的$A$组成的集合：$A$有至少一个前驱被$B$支配，但$A$不被$B$支配。支配边界是刚刚离开$B$的支配范围的基本块集合

迭代支配边界是在基本块集合$\mathbb{B}$上不断求支配边界加入其中，迭代到不动点的结果

对于一个变量，它的所有定义组成的集合的迭代支配边界就是需要插入$\phi$函数合并定义的地方，可以证明这样插入的$\phi$总数是最小的（尽管有些合并的结果不会被用到）

四

目标代码生成

一堆体系结构知识略

寻址模式

以下*R2代表寄存器R2中的值

LD R1, a(R2)：取(*R2)+a地址处的数据放入R1

LD R1, 100(R2)：取(*R2)+100地址处的数据放入R1

LD R1, *R2：取*R2地址处的数据放入R1

LD R1, *100(R2)：取(*R2)+100地址处的数据作为新地址，取该处的数据，放入R1

LD R1, #100：将字面量100放入R1

块内优化

局部公共子表达式：将不同部分的公共表达式合并为一次计算

强度削弱：将部分算术操作替换为等价的简单操作，如$x^2=x * x, x * 2=x + x, x / 2=x * 0.5$

使用机器习语：如$x=x+1$可以直接编译到INC x

去除冗余的LOAD和STORE

窥孔优化：匹配一小窗口内特定的指令序列，替换成更高效的序列

转换出SSA*

从SSA生成机器代码需要移除$\phi$函数，我们希望在保证程序等价性的条件下尽量将$\phi$函数中的多个变量直接合并为一个

对于$a=\phi(a_1, a_2, \cdots, a_n)$，消除的方法如下：

1. 在每个$a_i$对应的基本块末尾插入$a_i’=a_i$
2. 将原$\phi$函数替换为$a’=\phi(a_1’, a_2’, \cdots, a_n’)$
3. 在替换后的$\phi$函数之后插入$a=a’$
4. 将所有$a’$和$a_i’$替换为一个相同的新变量
5. 通过向前驱的末尾插入赋值语句的方式，消除替换后的$\phi$函数
6. 上一步插入的赋值是并行进行的，需要将其串行化
7. 消除多余的赋值

寄存器分配

虚拟寄存器是无限的，而实际的寄存器是有限的，需要决定何时将哪些量留在物理寄存器中，哪些放在栈上

Speed: Registers > Memory

Physical machines have limited number of registers

Register allocation: $\infty$ virtual registers $\rightarrow$ $k$ physical registers

Requirement:

Produce correct code using k or fewer registers

Minimize loads, stores, and space to hold spilled values

Efficient register allocation ($O(n)$ or $O(n \log n)$)

局部寄存器分配

在基本块内部没有跳转，我们可以轻易地求出块内变量的存活区间

MAXLIVE：对于一个语句，它结束时还有多少变量存活

当有语句的MAXLIVE超过实际寄存器数量时，在这条语句开始之前需要把一个量spill到栈上，选择spill的变量的方法是选择距其下一次使用最远的变量

全局寄存器分配

全程序的寄存器分配一般使用冲突图进行

如果两个变量的存活区间有交，我们称它们是冲突的，在冲突图上二者之间有一条无向边

最终我们需要spill掉一些变量使得冲突图顶点是可以被$k$染色的，其中$k$是可用的物理寄存器数量

图染色近似算法

Chaitin算法：度小于$k$的顶点最后总是可以被染色，每次把这样的点从图中删掉放入栈中，对剩下的顶点继续过程，直到图为空就可以以删除顺序的逆序（出栈序）依次染色节点。如果过程中图的每个点度数都大于等于$k$，选择一个顶点spill掉再继续。

Chaitin-Briggs算法：考虑到度大于等于$k$的点实际上也可能可以被染色，相比于Chaitin算法，这个算法在所有点度数都过大时不直接spill掉点，而是仍然放入栈中。最后出栈染色的时候再检查是否能够染色，如果不能再在这时spill。

五

指令调度

由于CPU实际上有并行地执行多个指令的能力，编译时如果将独立的、可并行的若干指令放在一起，可以让CPU并行地执行这些指令，提高程序执行的效率

Hardware only can execute instructions that have been fetched

Hardware has limited space to buffer stalled operations

Compilers can place independent operations close together to allow better hardware utilization

块内调度

读与读：无依赖，可以任意调换

写后读：真依赖，不能调换顺序

读后写：假依赖（存储依赖），分配额外的寄存器可以消除

未消除的依赖构成依赖图，为一DAG，能以该图的任意拓扑序重新调度指令

列表调度：考虑依赖图的拓扑序，对每个时钟周期尝试安排已就绪的指令，若有多个就绪的指令，以特定优先级来确定安排哪一个（如优先安排路径延迟最高的等等）

跨块调度*

拓展基本块（EBB）：一组基本块，满足这组基本块只有一个入口，同时除入口块之外的其他基本块只有一个前驱

对于一个拓展基本块内的的一条路径，指令调度和块内调度方法一致，不过在指令移动时需要注意，向上/向下移动时若不满足对应的支配关系要进行额外处理

每次选择一条EBB路径做指令调度，然后把这个路径从图里删去，重复这样做直到图为空

对循环的处理*

可以考虑展开循环后调度，也可以考虑循环整体来优化，不过没有完美的方法

六

数据流分析

基本结构：数据流分析的结果组织为facts，每个基本块的入口和出口分别有in facts和out facts，每个基本块描述一个transfer function，用于从in/out facts产生out/in facts，同时还有一个meet function用来合并两个facts的结果，用于合并基本块前驱/后继传递的结果

以前向数据流分析为例，每个基本块的in facts为其所有前驱的out facts的合并，out facts则是将自身的transfer function应用于in facts的结果。从某个初始条件开始迭代，满足这些条件的最小/最大不动点就是数据流分析需要的结果。

Worklist算法：可以发现每个基本块的in/out facts只与前驱的out facts/后继的in facts有关，而out/in facts是由in/out facts通过transfer function求出，因此只有某一前驱/后继的facts更新时这个基本块才需要更新。在每次更新后将当前基本块的后继/前驱加入列表，只需不断从列表中取出基本块更新即可，而无需更新所有的基本块。

典型的数据流分析：可达定值分析、可用表达式分析、活跃变量分析，三个分析的转移函数全都是gen-kill标准型，即$D’=(D-Kill) \cup Gen$

可达定值分析：哪些定义可能不被覆盖地到达当前点。前向分析，meet function是并，facts初始化为空集，kill被覆盖的定义，gen当前基本块中的定义。

可用表达式分析：哪些表达式在到达当前点之前一定被计算过，而且使用到的变量值没有被改变。前向分析，meet function是交，facts初始化为全集，entry out facts初始化为空集，kill包含当前块中被重新定义的变量的表达式，gen当前基本块中被计算的表达式。

活跃变量分析：哪些变量的定义在当前点之后还可能被使用。后向分析，meet function是并，facts初始化为空集，kill当前基本块中定义的变量，gen当前基本块中使用的变量。

还有许多不特别的分析，还有不甚特别的稀疏分析技术，不在考察范围内，略

符号执行

三个重要的敏感性：路径敏感（特定路径）、流敏感（特定程序点）、上下文敏感（特定上下文）

符号执行提供路径敏感，但是带来路径爆炸问题，对外部函数也难以处理。对断言等的检查还引入约束求解的需求。

路径爆炸可以通过State Merging（合并不同路径的状态）、Loop Induction（对循环效果做归纳）缓解，对外部函数的处理可以用Concolic Execution（结合符号执行和具体执行的值）进行

布尔可满足性

CNF：形如$\wedge_i \vee_j l_{i,j}$的公式

可满足性：称公式$F$是可满足的，当且仅当存在一种对于$F$中所有布尔变量的指派，使得最后$F$的值为真

同时可满足性：对于公式$F_1, F_2$，如果$F_1$可满足当且仅当$F_2$可满足，称它们是同时可满足的

Tseitin变换：对于任何公式$F$，存在一个CNF公式$F_c$，满足$F$与$F_c$同时可满足，且$F_c$至多比$F$长常数倍。具体方法为考虑$F$的语法树，将每个节点都对应到一个新变量，用于描述这个节点的语义

如对于$A \Rightarrow (B \wedge C)$，可将其变换为$x_1 \wedge (x_1 \iff (A \Rightarrow x_2)) \wedge (x_2 \iff B \wedge C)$，再将其中的$\iff$等变换到使用$\neg$和$\vee$的形式即可

DPLL：每次选择公式中的一个布尔变量，赋真或假值，并在公式中传播该值，当公式化简到假时回滚重试，重复直到找到一个解或者尝试完所有可能

CDCL：每次出错时从矛盾式中学习不可能的赋值组合，使得DPLL更快

可满足性模理论

对于一阶谓词逻辑，考虑谓词的输入，如果可以建模为位向量就可以使用以下方式求解：

1. 限制谓词输入到固定字长
2. 将固定字长的位向量拆成若干单独位，并将对应的操作也转换为对单独位的操作，将一阶谓词逻辑公式转换为命题逻辑公式
3. 使用DPLL/CDCL求解

七

跨过程分析*

主要是提供上下文敏感性，方案众多

有在经典的数据流分析基础上设计的，基于克隆的方法和基于函数概要的方法

还有对于满足分配律的数据流分析，建模到CFL可达性的方法，在此之上又有许多优化方法

内容复杂，不在考察范围中，不介绍

指针分析

Andersen算法：

Steensgaard算法：

前者的实现基于图闭包（指针流图），后者将包含改为相等，可以用并查集实现

二者都是可能分析，是实际的指向关系的上近似，后者效率更高，但是精确度更低

基于Datalog的数据流分析

Datalog是关于facts和rules的语言

rules说明能从什么条件推出什么结论，定义语法是P(a,b,…) :- A(…), B(…), …

facts则是从外部加入的事实，用于推导其他结论

使用Datalog进行数据流分析，只需要定义数据流分析的规则，而不再需要自己解决产生结果的过程，更为方便

如使用Datalog实现可达定值分析，用到的谓词如下：

def(B, N, X)： 基本块B中的第N条语句可能定义变量X

succ(B, N, C)：基本块C是B的后继，B有N条语句

rd(B, N, C, M, X)：基本块C的第M条语句对变量X的定义可能到达基本块B的第N条语句

定义规则如下：

rd(B, N, B, N, X) :- def(B, N, X)

rd(B, N, C, M, X) :- rd(B, N-1, C, M, X), def(B, N, Y), X≠Y

rd(B, 0, C, M, X) :- rd(D, N, C, M, X), succ(D, N, B)

即可自动进行可达定值分析，指针分析等也类似，不赘述

第一、二章

名词解释

软件工程：

1. 运用系统的、规范的、可量化的方法进行软件的开发、使用、和维护，即将工程应用于软件；2. 以及对上述过程的方法的研究。

简答：

从1950s~2000s之间的特点：

50 年代：科学计算；以机器为中心进行编程；软件是硬件的一部分。

60 年代：业务应用；软件不同于硬件；用软件工程的方式生产软件。

70 年代：结构化方法；瀑布模型；强调规则和纪律

80 年代：追求生产力最大化；现代结构化/面向对象编程广泛使用；重视过程的作用

90 年代：企业为中心的大规模软件开发；追求快速开发、可变更新和用户价值；Web应用出现

00 年代：大规模Web应用；大量面向大众的Web产品；追求快速开发、可变更新、用户价值和创新

第四章

如何管理团队？

在实验中采取了哪些办法？有哪些经验？

团队结构有哪几种？

• 主程序员团队（一名主程序员，其他人只对主程序员负责）、

• 民主团队（团队成员完全交流，项目经理只管理、解决冲突、取得共识）、

• 开放团队（成员自由交流，项目经理也弱化管理，将团队作为黑箱运行，适用于创新性工作）

质量保障有哪些措施？结合实验进行说明

• 评审（由作者之外的其他人进行检查）：规划 → 总体部署 → 准备 → 审查会议 → 返工 → 跟踪

• 质量度量（测度（用于量化的指标）、测量（基于指标评估软件活动）、度量（软件在某个属性上的量化测度程度））、

• 测试

配置管理有哪些活动？实验中是如何进行配置管理的？

配置管理活动：

• 标识配置项（确定需要保存/管理的配置项）、

• 版本管理（为配置项设置版本号，变更时需要更新版本号）、

• 变更控制（配置项发生变化时，需要根据变更控制过程管理）、

• 配置审计（确认配置项的完整性、正确性、一致性和可跟踪性）、

• 状态报告（标记、收集和维持配置状态信息）、

• 软件发布管理（将配置项发布到开发活动之外，创建和发布可用的产品）

第五章

名词解释：

需求

• 用户为了解决问题或达到某些目标所需要的条件或能力；

• 系统或系统部件为了满足合同、标准、规范或其他正式文档所规定的要求而需要具备的条件或能力；

• 对前两者中的一个条件或一种能力的一种文档化表述。

区分需求的三个层次

给出一个实例，给出其三个层次的例子

对给定的需求示例，判定其层次，例如课程实验/ATM/图书管理

需求层次：业务需求（大目标）→ 用户需求（小任务）→ 系统需求（系统行为）

掌握需求的类型

对给定的实例，给出其不同类型的需求例子

对给定的需求示例，判定其类型，例如课程实验/ATM/图书管理…

需求类型：

• 功能需求、

• 性能需求（如速度，容量、吞吐量、负载、实时性）、

• 质量属性（完成的质量，如可靠性、可维护性、安全性、可用性）、

• 对外接口、

• 约束、

• 数据需求

第六章

为给定的描述建立：

用例图、分析类图（概念类图）（只有属性，没有方法）、系统顺序图、状态图

数据流图：

实体关系图：

用例图：

• 用例（圈）、

• 参与者（小人）、

• 关系（线）、

• 系统边界（框）

用例粒度：

为应对一个业务事件，由一个用户发起，在一个连续时间段内完成，可以增加业务价值的任务

概念类图：

• 概念类（名字与重要属性），

• 依赖（虚线V字箭头），

• 关联（实线，单向V字箭头或双向），

• 聚合（实线空心菱形），

• 组合（实线实心菱形），

• 继承（实线空心三角），

• 实现（虚线空心三角）

概念类图的建立：

• 识别候选类（名词分析），

• 筛选概念类（状态与行为），

• 识别关联，

• 识别重要属性

系统顺序图：

• 对象（人或者方框），

• 生命线（虚线），

• 执行态（生命线上的条带），

• 同步消息（实线实心三角箭头），

• 异步消息（实线V字箭头），

• 返回消息（虚线V字箭头），

  

• 组合段（左上角带名字的方框，opt/alt/loop/…）

状态图：

• 起始状态（实心圆），

• 状态（圆角矩形），

• 转移（实线V字箭头，标注格式为 事件 [监护条件]/动作），

• 结束状态（空心圆套实心圆）

第七章

为什么需要需求规格说明？结合实验进行说明

• 软件开发过程中会将开发任务细分为多个子任务分配给不同的人员，分解的子任务之间需要相互沟通和交流。

• 子任务和人员间存在错综复杂的关系，存在大量沟通与交流，所以软件系统开发中需要编写多种不同类型的文档来针对项目中需要进行广泛交流的内容。

• 用例文档以用户的角度以用例文本来描述系统和外界交互；需求规格说明文档从软件产品角度以系统级需求列表方式描述系统解决方案

对给定的需求示例，判定并修正其错误，对给定的需求规格说明片段，找出并修正其错误

需求规格说明：

• 使用用户术语：不要使用「类、函数、参数、对象」等计算机术语

• 可验证：不能模糊不清，不要用模糊和歧义词汇

• 可行：技术上、成本上，不能不切实际

对给定的需求示例，设计功能测试用例（结合测试方法）

第八章

名词解释：

软件设计

关于软件对象的设计，既指软件对象实现的规格说明，也指产生这个规格说明的过程。

具体地说，软件设计是一份软件设计工程师创造的设计规格说明，包含软件设计描述和软件原型，保证软件能够满足需求规格，在一定的时间、费用、人员等限制条件下能够将软件部署在一定的物理环境里，达到业务目标。

软件设计的核心思想是什么？

主要思路：分而治之

核心思想：

• 抽象：分离接口和实现

• 分解：将系统分割为子系统以及子系统之间的联系

软件工程设计有哪三个层次？各层的主要思想是什么？

• 高层设计（部件、连接件、配置）：反映软件高层抽象的构建层次，描述高层结构、关注点和设计决策

• 中层设计（过程、调用；类、协作）：模块化、信息隐藏、OO原则

• 低层设计（数据结构、算法）：将基本的语言单位（类型与语句）组织起来，建立高质量的「数据结构+算法」的代码设计

第九、十章

体系结构的概念

软件体系结构 = 部件 + 连接件 + 配置

• 部件：承载系统主要功能
• 连接件：定义部件间交互（和部件平等）
• 配置：定义了部件和连接件之间的关联

一个软件系统的体系结构定义了系统的计算部件和部件之间的交互

体系结构的风格的优缺点

体系结构风格：主程序/子程序风格，面向对象式风格，分层风格，MVC风格

主程序/子程序风格：

树状连接，以程序调用作为连接件。

• 优点：

  • 流程清晰易于理解，

  • 易于控制程序的正确性。

• 缺点：

  • 强耦合，依赖交互方的接口规格，难以修改和复用；

  • 限制数据交互，可能产生公共耦合。

面向对象式风格：

将系统组织为多个独立的对象，对象通过协作机制共同完成任务。

• 优点：

  • 可以容易地修改对象的内部实现，

  • 契合模块化思想，易开发、理解和复用。

• 缺点：

  • 接口的耦合性，

  • 标志耦合，

  • 引入了OO的副作用，更难以控制程序的正确性。

分层风格：

系统被分为多个层次，抽象程度随层次提高而提升，相邻层次间常通过程序调用连接，跨层次和逆层次的调用被禁止。

• 优点：

  • 设计清晰易于理解，

  • 不同层次可以并行开发，

  • 每个层次具有良好的可复用性和内部可修改性。

• 缺点：

  • 交互协议难以修改，

  • 层次较多还可能有性能损失，

  • 层次的数量和粒度难以确定。

MVC风格：

（模型-视图-控制 Model-View-Control）以程序调用为连接件，将系统组织为模型、视图、控制三部件。

• 优点：

  • 机制清晰易于开发，

  • 视图和控制有可修改性，

  • 适用于网络系统开发。

• 缺点：

  • 复杂性，

  • 模型部分修改困难。

体系结构设计的过程？

1. 分析关键需求和项目约束
2. 选择合适的体系结构风格
3. 进行体系结构逻辑（抽象）设计
4. 根据逻辑设计进行体系结构物理（实现）设计
5. 完善体系结构设计
6. 添加构件接口
7. 迭代3~7

包的原则

内聚

重用发布等价原则：重用的单元 ≌ 发布的单元，

共同闭包原则：「修改时一起改」共同改变的类在同一个包里，利于开发者维护，

共同复用原则：「使用时一起用」共同被重用的类在同一个包里，利于使用者重用，倾向于产生小的包，

耦合

无环依赖原则：依赖不该有环，出现了环可以使用依赖倒置解决，

稳定依赖原则：依赖只应该从不稳定到稳定的方向，

稳定抽象原则：越稳定的包越抽象

体系结构构建之间接口的定义*

构件接口定义：每个构件有供和需接口，对供接口给出语法、前置的后置条件，对需接口给出来源和所需的服务。

提供的服务（供接口）

语法，
前置条件
后置条件

需要的服务（需接口）

服务名
服务

体系结构开发集成测试用例（Stub和Driver）

集成策略分为

大爆炸式

一次全塞了

增量式

• 自顶向下
  • 一个Driver，下层用stub，不断用下层模块来代替stub
  • 按深度优先可以首先验证一个完整的功能需求；利于定位故障
  • 桩开发量大；底层测试不充分
• 自底向上
  • 用Driver来替代上层
  • 桩工作量小；底层组件开发可以并行；利于故障定位
  • 驱动开发量大；高层测试不充分
• 持续集成
  • 每次完成一些开发任务后就用开发结果来替代stub测试

第十一章

名词解释：

（人机交互的）可用性*：

• 易学性：新手用户容易学习；完全没有培训的用户完成特定任务所需的时间
• 效率：熟练用户完成特定任务需要的时间
• 易记性：以前使用过系统的用户完成特定任务需要的时间
• 出错率：用户使用系统时犯多少错、错误多严重、能否从错误中容易地恢复
• 主管满意度：用户体验，调查问卷

界面设计原则：

人

• 精神模型

  • 用户总是看到自己想看的

  • 精神模型就是人机交互时头脑中的人物模型。用户识别图像，根据隐喻将控件和熟悉事务联系起来。

• 差异性

  • 不同群体的任务模型不同，比如新手用户、熟练用户、专家用户
  • 为不同用户群体提供差异化的交互机制。比如为新手提供GUI，为专家提供命令行、快捷方式、热键

机

• 可视化设计
  • 不要暴露内部设计
  • 展示细节

交互

• 导航
  • 为用户提供完成任务的入口，好的导航符合精神模型
  • 菜单导航、快捷方式导航、列表导航、状态栏导航、按钮导航
• 反馈
  • 对用户行为进行反馈，让用户意识到行为的后果
  • 声音、视觉…
• 交互原则（重点）
  • 简洁设计：图片比描述文字更清晰。7±2原则，有效表达下越简洁越好
  • 一致性设计：
    • 相似的任务相似的交互；
    • 与已有的软件类似，遵循用户已有的精神模型
  • 低出错率设计：
    • 避免错误操作（disabled button）；
    • 良好而有建设性的错误提示；
    • 错误恢复与故障解决帮助手册
  • 易记性：
    • 减少记忆负担（自动补全、提示）；
    • 逐层递进地展示；
    • 直观的快捷方式（图片按钮）；
    • 设置有意义的默认值

导航：帮助用户找到任务入口，分为全局结构和局部结构

反馈：提示用户交互行为的接口，同时不打断用户工作的意识流

协作式设计：以用户为中心，调整计算机因素以更好地适应并帮助⽤户的设计方式

详细设计的出发点

• 需求开发的结果（需求规格说明和需求分析模型）
• 软件体系结构的结果（软件体系结构设计方案与原型）

职责分配

通过职责建立静态模型：面向对象分解中，系统是由很多对象组成的。对象各自完成相应的职责，从而协作完成一个大的职责。

类的职责主要有两部分构成：属性职责和方法职责。

类与类之间也不是孤立存在的，它们之间存在一定的关系。关系表达了相应职责的划分和组合。它们的强弱顺序为：依赖<关联<聚合<组合<继承。

协作：

根据协作建立动态模型：

• 从小到大，将对象的小职责聚合形成大职责；

• 大到小，将大职责分配给各个小对象。

通过这两种方法，共同完成对协作的抽象。

GRASP：信息专家（职责分配给信息足够的类），对象创建者（组合/聚合容器，记录者，密切使用者，有足够信息者），高内聚，低耦合，控制器（处理系统事件，传递给合适的类）

控制风格

控制风格决定了决策由谁来做和怎么做决策

分散式：系统行为完全分散于各个类
集中式：少数大控制器处理所有系统逻辑
委托式：任务委托给若干中等规模控制器，分别处理部分重要逻辑

第十三章

名词解释：

耦合*：

两个模块之间关系的复杂程度。

分内容耦合（直接使用模块的内容）、

公共耦合（共同使用全局变量）、

重复耦合（共有重复的逻辑）、

控制耦合（传递控制信息）、

标记耦合（传递数据结构）、

数据耦合（传递基本类型数据）

内聚*：

一个模块内部联系的紧密性。

偶然内聚（模块提供多个不相关的操作）、

逻辑内聚（模块提供一系列逻辑上相似但不直接关联的操作）、

时间内聚（模块提供有时间相关性的操作）、

过程内聚（模块提供同属一个过程的操作）、

通信内聚（模块提供针对同一数据的一系列操作）、

功能内聚（模块只提供一个操作或达成单一目的）、

信息内聚（模块提供一系列操作，在同一个数据结构上进行而成为一个统一的整体）

信息隐藏

基本思想：

每个模块都隐藏着一个重要的设计决策。每个模块都有一个职责，对外表现为一份契约，契约之下隐藏着只有模块本身知道的设计决策或秘密，其细节只有模块自己知道。

两种常见的信息隐藏决策：

• 根据需求分配职责
• 内部实现机制

第十四章

模块化原则：

避免全局变量，

访问调用等尽量写成显式的，

1
2

martin.data["firstname"] = "Martin"; // 不好 
martin.firstName = "Martin"; // 好

避免重复代码，

基于接口编程（契约式设计，为软件组件定义正式、精确、可验证的接口，可以利用异常和断言来实现），

迪米特法则（只依赖离自己最近的单元），

接口隔离原则（用户不应被迫依赖他们不需要的功能，要拆分小接口），

里氏替换原则（子类对象应该能完全替代基类对象），

组合优于继承（尽量通过组合进行复用），

单一职责原则（一个类应该拥有单一的职责，并且这一职责由这个类完全封装起来）

第十五章

信息隐藏的含义

每一个模块都隐藏了这个模块中关于重要设计决策的实现，以至于只有这个模块的每一个组成部分才能知道具体的细节

需要隐藏的两种常见设计决策

• 需求（模块说明的主要秘密）与实现——暴露外部表现，封装内部结构
• 实现机制变更（模块说明的次要秘密）——暴露稳定抽象接口，封装具体实现细节

封装：

同时封装数据和行为，

分离外部接口和内部实现

开放封闭原则（OCP）：

「类/好的设计」应该对拓展开放，对修改封闭，新需求的实现应该通过增加代码而不是改动现有代码进行

违反了OCP原则的典型标志：出现了switch或者if-else

依赖倒置原则（DIP）：

抽象不应该依赖细节，细节应该依赖抽象；

高层模块不应该依赖低层模块，而是二者应该共同依赖抽象

使用抽象类（继承）机制倒置依赖

第十六章

如何实现可修改性、可扩展性、灵活性

进行接口和实现的分离

具体地说，

• 通过接口和实现该接口的类；

• 通过子类继承父类

策略模式，抽象工厂模式，单例模式，迭代器模式：

略

第十七、十八章

构造包含的活动

详细设计；编程；测试；调试；代码评审；集成与构建；构造管理。

名词解释

重构

修改软件系统的严谨方法，在不修改外部表现（不改变软件功能）的情况下改进内部结构（提升详细设计结构质量）

测试驱动开发

测试驱动开发要求程序员在编写一段代码之前，优先完成该段代码的测试代码。

测试代码之后，程序员再编写程序代码，并在编程中重复执行测试代码，以验证程序代码的正确性。

结对编程

两个程序员挨着坐在一起，共同协作进行软件构造活动

驾驶员：输入代码

观察员：评审，考虑战略性方向

两个程序员经常互换角色

代码的坏味道：

• 太长的方法（往往意味着方法完成了太多的任务，不是功能内聚的），

• 太大的类（往往意味着类不是单一职责的，需要分解），

• 太多的方法参数（往往意味着方法的任务太多，或者参数的类型抽象层次太低），

• 多处相似的复杂控制结构（往往意味着多态策略不足），

• 重复的代码（往往意味着重复耦合），

• 过多的注释（往往意味着代码逻辑不清晰或可读性不好）

契约式设计

契约式设计又称断言式设计，它的基本思想是：如果一个函数或方法，在前置条件满足的情况下开始执行，完成后能够满足后置条件，那么这个函数就是正确、可靠的。

• 异常

• 断言

防御性编程

对输入不做任何假设，主动进行检查来保证参数的有效性

表驱动编程

将复杂的决策包装为决策表，利用决策表解决

单元测试用例的设计

用MockObject创建桩程序来测试类方法，与为类开发测试用例

桩程序：与被测试部件交互，在规格上扮演其他系统组件

驱动程序：创建被测试部件的测试环境，驱动并监控部件执行测试用例，检查执行结果

第十九章

黑盒测试方法：

• 等价类划分（将输入域划分成若干等价类，从每个等价类中取若干代表数据作为测试用例），

• 边界值分析（针对每个等价类的边界情况设计测试用例，更有利于发现程序的缺陷），

• 决策表（将复杂逻辑转为决策表，并对每个决策规则设计测试用例），

• 状态转换（为测试对象建立状态图，以图中的状态转换为基础设计测试用例）

白盒测试方法：

• 语句覆盖（保证每行代码都被执行至少一次），

• 条件覆盖（每个条件判断的每个结果都至少出现一次），

• 路径覆盖（程序可能的每条执行路径都至少经过一次）

• 缺点：开销大，不能检验需求的规格

第二十、二十一章

如何理解软件维护的重要性？

• 由于会出现新的需求，如不维护软件将减小甚至失去服务用户的作用。

• 随着软件产品的生命周期越来越长，在软件生存期内外界环境发生变化的可能性越来越大，因此，软件经常需要修改以适应外界环境的改变

• 软件产品或多或少的会有缺陷，当缺陷暴露出来时，必须予以及时的解决

开发可维护软件的方法

考虑软件的可变性：分析需求易变性、为变更进行设计
为降低维护困难而开发：编写详细的技术文档并保持及时更新、保证代码可读性、维护需求跟踪链、维护回归测试基线

演化式生命周期模型

初始开发（开发软件的第一个版本） –第一个版本–>

演化（修改）（处理预先安排的需求增量、需求变更等，过程中复杂性逐渐增高，直到丧失可演化性） –丧失可演化性–>

服务（补丁）（不再增加价值，只是修正已有缺陷） –终止服务–>

逐步淘汰（开发者不再维护，有用户还在使用） –替换–>

停止（开发者不再维护，用户也不再使用）

用户文档

是指为用户编写参考指南或者操作教程，常见的如用户使用手册、联机帮助文档等，统称为用户文档。
文档内容的组织应当支持其使用模式，常见的是指导模式和参考模式两种。

• 指导模式根据用户的任务组织程序规程，相关的软件任务组织在相同的章节或主题。指导模式要先描述简单的、共性的任务，然后再以其为基础组织更加复杂的任务描述。 「有主线」

• 参考模式按照方便随机访问独立信息单元的方式组织内容。例如，按字母顺序排列软件的命令或错误消息列表。如果文档需要同时包含两种模式，就需要将其清楚地区分成不同的章节或主题，或者在同一个章节或主题内区分为不同的格式。「易查询」

系统文档

更注重系统维护方面的内容，例如系统性能调整、访问权限控制、常见故障解决等等。

因此，系统管理员文档需要详细介绍软硬件的配置方式、网络连接方式、安全验证与访问授权方法、备份与容灾方法、部件替换方法等等。

逆向工程

定义：分析目标系统，标识系统的部件及其交互关系，并且使用其它形式或者更高层的抽象创建系统表现的过程。

基本原理：抽取软件系统的需求与设计而隐藏实现细节，然后在需求与设计的层次上描述软件系统，以建立对系统更加准确和清晰的理解

主要关注点是理解软件，但并不修改软件

再工程

定义：检查和改造一个目标系统，用新的模式式及其实现复原该目标系统。

目的：对遗留软件系统进行分析和重新开发，以便进一步利用新技术来改善系统或促进现存系统的再利用。

主要包括：

• 改进人们对软件的理解；

• 改进软件自身，通常是提高其可维护性、可复用性和可演化性。

常见具体活动有：

• 重新文档化；

• 重组系统的结构；

• 将系统转换为更新的编程语言；

• 修改数据的结构组织。

主要关注如何修改软件，不花大力气理解软件。所以再工程前常有一个前导的逆向工程

第二十二、二十三章

软件生命周期模型：

将软件从生产到报废的生命周期分割为不同阶段，每段阶段有明确的典型输入/输出、主要活动和执行人，各个阶段形成明确、连续的顺次过程，这些阶段的划分就被称为软件生命周期模型。

典型的软件生命周期模型：需求工程->软件设计->软件实现->软件测试->软件交付->软件维护

软件演化生命周期模型就是一种软件生命周期模型

软件过程模型：

构建-修复模型：

特征：

• 没有对开发过程进行规范和组织，因此一旦开发过程超出个人控制能力，就会导致开发过程无法有效进行而失败。
• 对需求的真实性没有进行分析
• 没有考虑软件结构的质量，导致结构在修改中越来越糟，直至无法修改
• 没有考虑测试和程序的可维护性，也没有任何文档，导致难以维护

构建->修复->维护。

完全无组织，全是缺点

瀑布模型：

需求开发->软件设计->软件实现->软件测试->软件交付->软件维护，

文档驱动

特征：

• 对于软件开发活动有明确阶段划分
• 每个阶段的结果都必须验证，使得该模型是“文档驱动”

允许活动出现反复和迭代。

优点： 清晰的阶段划分有利于开发者以关注点分离的方式更好的进行复杂软件项目的开发。

缺点：

• ​​​​​​​对文档期望过高
• 对开发活动的线性顺序假设（线性顺序与迭代相反）
• 客户参与度不够（需求被限制在一个时间段）
• 里程碑粒度过粗（软件复杂使得每个阶段时间长，无法尽早发现缺陷）

增量迭代模型：

对每个增量应用瀑布模型，得到多个并行的瀑布式开发。

需求驱动

特征： 项目开始时，通过系统需求开发和核心体系结构设计活动完成项目的前景范围的界定，然后将后续开发活动组织为多个迭代、并行的瀑布式开发活动。第一个迭代完成的往往是核心工作，满足基本需求，后续迭代完成附带特性。

优点：

• 迭代式开发更符合实际情况；

• 并行开发可以缩短开发时间；

• 渐进交付可以加强用户反馈从而降低风险。

缺点：

• 各个增量是逐步并入系统的，不能破坏已构造好的部分，这要求系统有开放式的结构；

• 需要一个清晰的项目前景和范围来进行开发规划

演化模型：

以瀑布模型开发核心系统，此后根据用户反馈不断设计演进的新系统，启动若干并行的瀑布开发。

需求驱动

模糊了维护和新开发的界限

特征： 更好地应对需求变更，更适用于需求变更比较频繁或不确定性较多的领域。将软件开发组织为多个迭代

优点：

• 增量迭代模型一样。

缺点：

• 无法在项目早期确定项目范围；

• 后续迭代的开发是在旧系统基础上进行的，把握不好可能退化成构建-修复模型

原型模型：

对抛弃式原型进行演化，得到清晰需求后再基于此使用瀑布模型。

需求驱动

特点： 大量使用抛弃式原型（抛弃式原型：通过模拟“未来”的产品，将“未来”的知识置于“现在”进行推敲，解决不确定性）

优点：

• 加强了与客户的交流，能取得较好的客户满意度；

• 适用于不确定性大的新颖领域。

缺点：

• 原型开发可能带来新的风险，如原型开发耗费大量成本；

• 若负责人不舍得抛弃抛弃式原型，可能会使得原型的低质量代码流入产品，影响最终产品的质量

螺旋模型：

风险驱动

基于原型解决风险，通过四次迭代解决风险较高的几个阶段后进入瀑布模型。

特点： 基本思想是尽早解决比较高的风险，如果有些问题实在无法解决，那么早发现比项目结束时再发现要好，至少损失要小得多。风险是指因为不确定性（对未来知识了解有限）而可能给项目带来损失的情况，原型能够澄清不确定性，所以原型能够解决风险。

迭代与瀑布的结合：开发阶段是瀑布式的，风险分析是迭代的

优点：

• 可以降低风险。

缺点：

• 需要利用原型手段，会有原型带来的风险；

• 模型较为复杂，不利于管理者根据其组织软件开发活动

Rational 统一过程，敏捷过程

Welcome to Hexo! This is your very first post. Check documentation for more info. If you get any problems when using Hexo, you can find the answer in troubleshooting or you can ask me on GitHub.

Quick Start

Create a new post

1

hexo new "My New Post"

More info: Writing

Run server

1

hexo server

More info: Server

Generate static files

1

hexo generate

More info: Generating

Deploy to remote sites

1

hexo deploy

More info: Deployment