软件工程笔记文字

软件工程笔记

第一节课

2.3.2通用原则（HOOKER概括性原则）——在软件开发过程中，注意使用这些原则考虑问题

1. 存在价值：原则一，最重要，最基础，有没有必要做
2. 商业价值：是否有市场前景与市场价值，比如引入流量、占用市场、竞争客户等用途
3. KISS（保持简洁）：减少错误，易于维护，首先需要将问题理解透
4. 保持愿景：软件项目成功的基础，团队具有一个一致的目标
5. 关注使用者：广义的使用者——包括架构设计、编码人员、维护人员、客户等
6. 面向未来：生命周期持久，价值高，即有前瞻性（比如遗留系统的核心业务，接纳新功能的能力）
7. 提前计划复用：具有前瞻性设计和计划，积累经验，质量有保障
8. 认真思考：权衡与决策

2.4软件开发神话

• 管理神话
• 客户神话
• 从业者神话

2.5一切是如何开始的——业务需求

案例：课本P18/P34/P37

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SUObEFOT-1686190806459)(E:\课程\2019学年下学期\软件工程\笔记\246]VWTS$9S4K2FLJ_ZX`54.png)]

提出概念产品的设想：家庭管理软件

技术可行性研究：硬件、软件、技术

第四章 过程模型

软件工程工作的路线图=流程+动作+任务+迭代程度+工作产品+组织工作……

4.1惯用过程模型

4.1.1瀑布模型

框架过程流时按照线性关系排布的。

特点：

1. 阶段间的顺序性，依赖性（下一步依赖上一步的结果）
2. 推迟实现的观点，（产品到最后才能看见）
3. 质量保证的观点（重视文档，以便尽早发现问题）

问题：

1. 实际项目很少严格遵循，容易导致项目处于“阻塞状态”-------依赖关系
2. 难适应有些项目开始阶段必然存在的需求不确定性------------适用于开始需求就明确的项目
3. 客户到尾声才能得到可执行程序，前期存在缺陷，则造成很大损失

4.1.2V模型

在瀑布模型的每个阶段加上测试；

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0hPU3pQL-1686190806460)(E:\课程\2019学年下学期\软件工程\笔记\GB6$TZIMIQY%Q~DSE]0%5BI.png)]

4.1.3增量过程模型

将工作分为增量，增量内使用瀑布模型

内部：线性过程流

总体：并行过程流（多个增量同时进行）

优点：

1. 在较短时间提交有用的工作产品
2. 逐步增加功能，可以使用户有时间学习和适应新产品
3. 失败风险低
4. 优先级最高的服务首先交付，总重要的服务需要最多测试------保证核心功能质量

注意：

1. 新的增量加入进来，不会破坏原来的产品
2. 体系结构必须是开放的
3. 比瀑布模型、原型模型需要更多设计

4.1.4演化过程模型

（1）原型模型

沟通-策划-建模-构建原型-部署交付的循环

常用工具：墨刀（制作原型）

目的：尽快获知用户需求

关注点：原型是否需要保留？一般是选择抛弃，需要事先沟通好

（2）螺旋模型

见P35

特点：

1. 风险驱动型过程模型，每一步都有风险的评估与分析
2. 适合大型系统和软件
3. 把原型作为降低风险的机制
4. 可以表示软件的整个生命周期，可以考虑到维护等

优点：

1. 有助于将软件质量和软件重用定位重要目标的开发
2. 主动控制风险

缺点：

1. 对开发人员要求较高，要求具有丰富的风险评估经验和知识

4.1.5并行模型

适用于不同团队共同开发

第二节课

4.1.6演化过程的最终评述

现代软件现状：

【1】总是在持续改变

【2】要在非常短的周期内实现改变

【3】充分满足客户要求

【4】及时投入市场

//\

||通过演化过程模型

||

软件团队及经理面临的挑战：在客户满意度、严格项目、产品参数间合理平衡

4.2专用过程模型

4.2.1基于构建的开发

• 使用可复用的软件-----构件设计与创造

• 前提大型软件系统中存在足够多的共性，以便复用

• 用集成代替构建

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-oF4fLCgO-1686190806461)(E:\课程\2019学年下学期\软件工程\笔记\L5T@4`$~L1K6QFN%}0T%UEN.png)]

4.2.2形式化方法模型

• 基于形式化数学变换的软件开发方法，可将系统规格说明书转换为可执行程序
• 使用严格的数学符号说明、开发、验证系统

特点：

【1】对于歧义性问题，不完整问题，不一致问题等容易被发现和改正

【2】提供无缺陷的软件

【3】适用于高度关注安全的软件、一旦出错将导致大量经济损失的软件

缺点：

【1】耗时，成本高

【2】对程序员要求高

【3】很难与客户沟通

4.2.3面向方面的软件开发

是对横切关注点进行局部表示的机制，共同关注的一个方面，比如日志、事务、认证、安全、性能等

4.3统一过程

• RUP：一种完整且完美的软件过程，面向大型的

• 用例驱动、以架构为中心的迭代和猪呢个两，与UML结合紧密

• 6条最佳实践经验：

【1】迭代式开发：需求可以在迭代中变化

【2】管理需求：需求文档化

【3】基于构建的体系结构：降低开发复杂性、提高软件重用率

【4】可视化建模：UML语言建立模型，提高管理软件复杂性的能力

【5】验证软件质量:评估贯穿于整个过程，全体成员参与

【6】控制软件变更

• 五个阶段（不断迭代）-----在面向对象开发过程中，每个部分交叉的
  • 构思阶段：沟通、策划-------版本文档、初始用例模型、初始项目表、初始商业用例、初始风险评估、项目计划、阶段、迭代、商业模式、原型
  • 细化阶段：策划、建模-------用例模型、补充需求、可执行框架原型、初步设计模型、修正的风险清单、项目计划、初步使用手册
  • 构建阶段：构建-------设计模型、软件构件、集成软件增量、测试计划和步骤、测试用例、支持文档、用户手册、安装手册、当前版本描述
  • 移交阶段：构建、部署-------交付软件增量、Bata测试报告、用户反馈报告
  • 生产阶段：软件增量

第五章 敏捷开发

哲学理念和一系列开发指南的综合，从重型过程到轻量敏捷

• 哲学理念：

【1】让客户满意，尽早增量发布

【2】小而高度自主的项目团队

【3】非正式方法，最小化工作产品及精简开发，最小任务集

• 开发指南：

【1】超越分析与设计的发布

【2】开发人员和客户持续沟通

• 敏捷开发宣言

【1】个人和他人之间的交流>开发过程和工具

【2】运行的软件>宽泛的文档

【3】客户合作>合同谈判

【4】对变化的良好响应>按部就班遵循计划

5.1敏捷策略–关键词

【1】响应变化

【2】有效沟通（包括客户、最终用户）

【3】将客户加入到开发团队中

【4】高度自主的项目团队

【5】快速交付可运行软件

5.3.1敏捷原则

5.3.2敏捷开发战略

• 考虑人的因素：对团队成员的要求
  • 基本能力
  • 共同目标
  • 精诚合作
  • 决策能力
  • 模糊问题解决能力
  • 互相信任和尊重
  • 自组织
• 适用范围：见笔记

5.4极限编程xp

5.4.1极限编程过程

把重要和有效=的做法发挥到极致

• 策划
  • 用户故事
  • 权值，优先级别划分
  • 验收测试准则
  • 迭代计划
• 设计
  • 简单设计，极简原则
  • CRC卡，类-责任-协作
  • 当设计时遇到困难，则使用spike解决方案，建立原型
• 编码
  • 结对编程
  • 单元测试与集成
• 测试：
  • 单元测试
  • 连续集成
  • 验收测试
• 发布----》loop

第三节课

5.5其他的敏捷过程模型

5.5.1 SCRUM

产品待定项-》区分优先级-》划分冲刺待定项-》展开项目（2-6周）-》每日例会（15分钟）-》展示新功能

• 每日例会

【1】上次会后做了什么？

【2】遇到什么困难？

【3】下次例会前做了些什么？

第x章 项目可行性研究

x.1可行性研究的概述

【1】可行性研究的意义

• 能否在规定成本和时间内做出产品
• 资源的消费与经费
• 用最小的代价在尽可能短的时间确定问题是否能够解决

x.2可行性研究的任务

确定问题是否值得解决

【1】分析思路

• 进一步分析和澄清问题的定义
• 导出系统的逻辑模型
• 搜索若干可供选择的主要解法

【2】研究解法的可行性的方面

• 技术可行性
• 经济可行性
• 社会可行性：法律政策、著作权等

x.3可行性研究的过程

【1】确定规模和目标：确保分析人员所解决的问题是客户要求的问题

做法：

• 访问关键人员
• 仔细阅读和分析有关材料
• 在问题定义阶段，关于规模和目标进一步的复查，改正含糊或不确切的叙述
• 清晰描述对目标系统的一切限制和约束

【2】研究目前正在使用的系统

做法：

• 现有系统是新系统信息的重要来源：人工、信息化
• 新系统解决旧系统中的问题，分析优缺点

【3】导出系统高层的逻辑模型

做法：物理系统-》导出逻辑模型-》参考逻辑模型-》设想逻辑模型-》建造新的物理系统

【4】进一步定义问题

–》loop

【5】导出和评价供选择的解法

• 技术可行性分析
• 经济：预算开支与收入
• 社会
• 每个可行系统指定实现进度表

【6】推荐行动方针（包括经济方面，因此需要成本/效益分析）

【7】草拟开发计划

• 指定工程进度表
• 估计开发人员和各种资源需要
• 估计系统生命周期每个阶段的成本

【8】书写可行性研究报告

x.4系统的描述

【1】方式

• 系统流程图：物理数据流图，
• 数据流图：
  • DFD，描述信息流和数据流动过程的变换
  • 信息交流的工具
  • 分析和设计的工具
  • 描述出系统的边界
• 数据字典：
  • 数据流：数据流中的箭头，定义词汇，消除二义性
  • 数据存储：数据库的二义性描述
  • 数据项

参考mooc第三周：结构化分析过程

x.5成本/效益分析

第四节课

第七章 理解需求

7.1需求工程

需求工程的7项任务

• 启动：提出一系列问题
  • 对问题的基本理解
  • 谁需要解决方案
  • 期望解决方案的性质
  • 初步交流发出合作效果
• 获取：征求利益相关者的需求
• 细化：开发需求模型，说明功能、特征、信息等
• 协商：令利益相关者都满意的可交付系统
• 规格说明：一个或多个
  • 一份写好的文档：需求规格说明书
  • 一套模型
  • 一个形式化的数学模型
  • 一组使用场景
  • 一个原型
• 确认：一组检查机制
  • 内容或解释上的错误
  • 需求进一步解释
  • 丢失的信息
  • 不一致性，二义性
  • 冲突需求或不可实现的
• 需求管理

7.2建立根基

【启动】的步骤：

• 确定利益相关者：逐渐增多的人员列表
• 认识多重观点：收集利益相关者的需求，进行分析分类
• 协同合作：优先点投票----划分优先级别，删减需求，做最终判断
• 首次提问：
  • 与整体目标和利益相关的提问
  • 有助于开发组更好理解问题的提问
  • 关注沟通本身效率的提问

7.3获取需求

7.3.1协作收集需求

标识问题、提出解决方案要素、协商方法、确定一套完成解决需求的初级方案

• 软件工程师必须考虑建立系统的语境
  • 我们能建立系统吗？
  • 开发流程能让我们打败市场竞争对手吗？
  • 有适当资源可建立和维护需求吗？
  • 系统性能能满足客户需求吗？

7.3.2质量功能部署QFD

【1】目的：最大限度让客户满意

【2】强调：什么是对客户有价值的，并且部署这些价值

• 常规需求：客户表述的，需求存在，客户会满意
• 期望需求：客户未表述的，不存在，则客户会不满
• 兴奋需求：超出客户预期，存在则令人满意-----导致产品有突破性

7.3.3使用场景

如果……

7.3.4获取工作产品

【1】必要性可行性陈述

【2】系统或产品范围的界限说明

【3】利益相关者的名单

【4】系统技术环境说明

【5】需求的领域限制

【6】一系列使用场景

【7】可以更好定义需求的原型

*7.3.4敏捷需求获取

【1】用户故事

【2】故事卡片：记录用户故事

【3】用户故事不足讨论：缺乏背景、缺少非功能需求考量、没有机会展望未来工作

与用例的区别：用例可以考虑多种情况，及处理办法，但用户故事不会这样详细全面

*7.3.5面向服务的方法

在云计算中运用较多

第五节课

7.4开发用例

【1】用户场景的集合描述了系统线程使用

【2】每个场景需要回答的问题：

• 主要参与者和次要参与者是谁？
• 参与者的目标是什么？
• 故事开始前有什么前提条件？
• 参与者完成的主要工作或功能是什么？
• 按照故事所描述的还可能需要考虑什么异常？
• 参与者的交互中有什么可能的变化？
• 参与者将获得、产生或改变哪些系统信息？
• 参与者必须通知系统有关外部环境的改变吗？
• 参与者希望从系统获取什么信息？
• 参与者希望得知会有意料之外的变更吗？

详情参考案例进行学习

7.5构建分析模型

7.5.1分析模型元素

【1】基于场景的元素：用例图

【2】基于类的元素：名词提取法

【3】行为元素：状态图

【4】流化元素：数据流图

7.5.2分析模式

在特定应用领域提供解决放案，使建模时可以重复使用=类+功能+行为

7.6避免常见的错误

第六节课

第八章 需求建模：基于场景的方法

细化、协商、规格说明、确认

8.1需求分析（建模通用）

8.1.1实现的目标

• 描述客户需求是什么
• 为设计奠定基础：系统描述-》模型-》设计模型
• 定义软件完成后被确认的一组需求

8.1.2分析的经验原则

【1】抽象级别尽量高一些

【2】将细节延迟到设计阶段考虑

【3】最小化系统的内关联–》低耦合

【4】尽量为每个利益相关者带来价值

【6】尽可能保持模型简洁

8.1.3域分析

【1】目的：查找、创建分析类或分析模式，使其能够复用

【2】概念：识别、分析、详细说明某个特定领域的公共需求

【3】步骤：

• 定义调查领域
• 收集该领域具有代表性的应用程序
• 分析样本的每个应用程序
• 建立对象的域分析模型

8.1.4需求建模方法

• 场景：用例、用户故事
• 类：类图、协作图
• 行为模型：状态图、顺序图
• 流模型：数据流图、数据模型

8.2基于场景建模

8.2.1创建初始用例

【1】用例内容：在需求获取时获得的东西，在这里也需要出现

【2】写多少：为每个标记功能开发用例

案例步骤：对于某一功能

• 从某一角色出发，得出主场景

8.2.2细化初始用例

【1】对每一条主场景进行评估，梳理可能出现的异常情况

【2】头脑风暴，如：

还可以做其他动作吗？

有没有可能遇到错误条件？如果有，这些错误是什么？

有没有可能遇到其他行为？如果有，是什么？

是否有具有确认功能的用例出现？

是否支持功能应答失败？

性能差的系统是否导致无法预期或不正确？

……

8.2.3编写正式用例

参考用例模板

8.3用例的UML模型

8.3.1活动图

可以看到功能的实现流程

8.3.2泳道图

可以看到每一个功能的参与者

第七节课

第九章 需求建模：基于类的方法

9.1识别分析类

对用例进行==（名词）==语法解析，利用潜在类判断

9.1.1分析类表现的方式

• 外部实体：其他系统、设备、人员
• 事物：报告、显示、字母、信号
• 偶发事件或事件
• 角色：经理、工程师、销售人员
• 组织单位：部门、组、团队
• 场地：制造车间、码头
• 结构：传感器、四轮交通工具、计算机

9.1.2潜在类

判断得到的分析类是否是正确的，满足以下要求，全部满足：

• 保留信息
• 所需服务
• 多个属性
• 公共属性
• 公共操作
• 必要需求

9.2描述属性

属性描述了已经选择包含在需求模型中的类

9.3定义操作

9.3.1操作的类型：

• 操作数据：增删改查
• 计算操作
• 请求状态操作
• 监控操作
• 初始化、释放操作

……

9.4类-职责-协作者CRC建模

CRC为类的标准索引卡片集合

9.4.1类的分类

• 实体类：模型、业务类，会在数据库长久存储
• 边界类：接口，交互屏幕、打印报表
• 控制类：管理实体类和边界类

9.4.2协作

类本身不能实现自身的每个职责，需要与其他类协作完成

【1】是xxx一部分：复合聚合类，不能离开整体起作用（实心）

【2】有xxx的知识

【3】依赖xxx

9.5关系和依赖

9.5.1多样性

类之间的关系：一对一、多对一、一对多、多对多

9.5.2依赖access

【1】使用依赖性：一个类的对象作为另一个类的参数

【2】交互依赖性：一个类的方法被另一个类调用，方法依赖性

9.6分析包

用于管理类，避免闭包的出现

第八节课

第十章 需求建模：行为和模式

10.1生成行为模型

显示了软件如何对外部事件或激励做出响应

10.2识别用例事件

【1】确定事件：信号、输入、输出、中断、动作

【2】画出事件跟踪图：简化的顺序图，没有考虑异常情况

10.3状态表达

必须考虑两种不同的状态：

【1】每个类的状态

• 被动：对象属性的当前状态
• 主动：属性持续变化或处理时的当前状态

【2】从外部观察到的系统状态

第九节课

案例分析，暂不介绍，主要是讨论需求分析的问题

第十节课

案例分析，暂不介绍，主要是讨论需求分析的问题

第十一节课

10.4需求建模的模式

10.4.1发现分析模式

• 需求模型描述中最基本元素是用例
• 如果存在一套连贯用例，则可以成为分析模式的基础

第十一章 设计概念

【1】良好软件的特性：坚固性、适用性、愉悦性

【2】什么是软件设计：一系列原理、概念、实践

11.1软件工程中的设计

11.1.1元素

• 数据/类设计
• 体系结构设计
• 接口设计
• 构件级设计

注：体系结构设计描述了构造元素的关系，构件级设计将构造元素变换为对软件构件的过程性描述

11.1.2需求分析的元素与设计的对应关系

• 基于类的元素（类图、分析包、CRC模型、协作图）：数据/类设计，体系结构设计，构件级设计
• 行为元素（状态图、顺序图）：接口设计，构件级设计
• 基于场景的元素（用例文本、用例图、活动图、泳道图）：接口设计

11.2设计过程

11.2.1软件质量指导原则和属性

【1】指导良好设计演化的特征

• 设计必须实现所有包含在需求模型中的明确要求
• 设计必须是可读的，可理解的指南
• 设计必须提供软件的概貌：数据域、功能域、行为域

【2】质量指导原则

• 设计应展示出一种结构（体系结构）
• 设计应该模块化
• 设计应该清晰表示（数据、体系结构、接口、构件）
• 设计应导出数据结构
• 设计导出显示独立功能特征的构件
• 设计应导出接口
• 设计导出应根据需求分析中获取的信息采用可重复的方法进行
• 设计应有效表示法（建模）

【3】质量属性——FURPS软件质量属性

• 功能性
• 易用性
• 可靠性
• 性能：处理速度、响应事件、资源消耗、吞吐量和效率
• 可支持性：可扩展性、可适应性、可用性

11.2.2软件设计的演化

模块化–》面向对象方法–》基于设计抽象设计模式–》面向方面方法、模型驱动方法、测试驱动方法

参考P136，软件设计的任务集

11.3基本概念

11.3.1抽象——处理复杂问题的方法之一

• 抽象：提取出公共部分
• 过程抽象：操作数据
• 数据抽象

11.3.2体系结构

【1】定义：软件的整体结构和结构为系统提供概念完整性的方式

• 结构特性：定义了构件（模块、对象、过滤器）被封装方式、及相互作用方式
• 外部功能特性：满足性能、能力、可靠性、安全性、可适应性等需求
• 相关系统族：使用重用模式

举例：mvc

【2】体系结构建模

体系结构可以使用多种模型表达

• 结构模型
• 框架模型
• 动态模型
• 过程模型
• 功能模型

11.3.3模式

【1】设计模式定义：在给定环境中一类共同问题的共同解决方案

【2】微观结构：实体模式、结构模式、行为模式

【3】推荐书籍：

• 《设计模式：可复用面向对象软件的基础》
• 研磨设计模式（一本值得反复研读的书）
• 大话设计模式（大鸟和小菜，通俗易懂）

【4】设计模式模板

模式名称、目的、别名、动机、适用性、结构、关联者、协作、效果、相关模式

*【5】抽象工厂模式——实体模式

优势：客户可以很容易的变更选择产品

第十二节课

基本概念：2思维、6内容、2经验、4机制

11.3.4关注分离点

体现在模块化、方面、功能独立

【1】复杂问题分解为可以独立解决优化的若干块，就能够容易的被处理

【2】关注点：一个特性或者行为，被指定为需求模型的一部分

【3】如何分解：分割为更小的关注点

如：城市规划、家庭装修，mvc，面向对象

11.3.5模块化

【1】单一属性，使程序能被智能化管理

【2】模块化权衡：由模块数量/成本工作量关系图权衡

【3】设计标准：

• 分解性：可分解为子问题
• 组合型：可重用
• 可理解性
• 连续型：需求小变化只影响单个模块
• 保护：模块异常影响模块自己

如：微架构

11.3.6信息隐藏

【1】将信息封装起来，隐藏到接口之后

【2】原因：

• 减少局部设计决策对全局的影响
• 阻止全局数据使用
• 促进封装——高质量设计的属性之一
• 形成高质量软件

11.3.7功能独立

【1】方式：

• 开发具有专一功能模块
• 避免与其他模块过多交互

【2】功能独立的定性评价标准

• 内聚性：模块内相关功能强度
• 耦合性：显示模块间的相互依赖性

11.3.8求精

【1】逐步求精：自顶向下的设计策略

【2】与抽象是互补的概念

11.3.9方面

【1】一个方面是一个横切关注点

如：安全

11.3.10重构

【1】保证外部不变的情况下，优化内部

【2】重构的情况

• 冗余性
• 没有使用的设计元素
• 低效的不必要的算法
• 拙劣不恰当的数据结构
• 其他不足

11.3.11面向对象的设计概念

设计类、继承、消息、多态

11.3.12设计类

【1】实体类、边界类、控制类

【2】特征：完整性、充分性、原始性、高内聚低耦合性

11.3.12依赖倒置

【1】针对接口编程，接口隔离

【2】高层、底层模块依赖抽象层

第十三节课

11.4设计模型

11.4.1数据设计

【1】在程序构件级：

• 数据建模：数据字典、ER图、类图
• 数据结构：算法、计算机存储、组织数据的方式

【2】在应用级：

• 数据库

【3】*在业务级：

• 数据仓库

11.4.2体系结构设计

11.4.3接口设计

【1】信息如何流入流出系统：如controller

【2】描述类的部分行为操作：如mapper

【3】接口的表现形式：用户界面、外部接口、内部接口

11.4.4构件级设计

【1】描述每个软件构件内部细节

【2】定义内容：

• 局部数据对象的数据结构
• 算法细节
• 允许访问所有构件的操作接口

11.4.5部署级设计

【1】软件功能和子系统在支持软件的物理环境内分布

第十二章 体系结构设计

输入：分析模型、用例模型

输出：物理结构（部署图）、子系统及接口、概要的设计类

12.1软件的体系结构

12.1.1体系结构特点

【1】分析设计有效性；

【2】考虑多种体系结构设计方案；

【3】降低风险

12.1.2体系结构为什么重要

【1】有利于交流

【2】早期设计决策

【3】可传递可复用性

12.3体系结构的风格

一组构建+一组连接件+约束+语义模型

12.3.1风格简单分类

• 以数据为中心：数据库系统、超文本系统、黑板系统（分享知识）、在线文档处理
• 数据流体系：批处理、编译器、图像处理、音视频处理
• 调用返回体系结构：如函数调用
• 面向对象体系结构：mvc
• 层次体系结构：操作系统

第十四节课

12.3.2体系结构模式

【1】体系结构模式：特点问题的解决方案

• 并发性：操作系统进程管理模式、任务调度模式
• 持久性
• 分布性：代理

12.3.3组织和求精

基本问题：

【1】控制：管理模块，如何优化

【2】数据：数据如何传递

12.4体系结构要考虑的要素

• 经济性
• 易见性
• 隔离性
• 对称性
• 应急性：紧急的，自组织的行为和控制

12.5体系结构决策记录

12.6体系结构设计

案例，采用uml设计表示

12.6.1系统环境的表示

12.6.2定义原型

UML关系图

12.6.3将体系结构细化为构件

使用包管理构件，黑色为顶层构件

12.6.4描述系统实例

进一步细化

12.7体系结构的评审

12.7.1评选候选体系结构

【1】方法：迭代评估

• 收集场景
• 引出需求、约束、环境描述
• 描述已经被选择用于解决场景、需求的体系结构风格/模式
  • 模块视图
  • 过程视图
  • 数据流视图
• 单独考虑每个属性来评估质量属性
• 针对特定体系结构风格，确定质量属性对各种体系结构属性的敏感
• 进行敏感性分析鉴定候选体系结构

【2】体系结构的复杂性

通过中间件的依赖，对体系结构整体复杂性进行评估

• 共享依赖
• 流依赖
• 约束依赖

12.7.2体系结构评审

【1】目的：满足系统质量需求、降低项目成本

【2】常用评审技术：基于经验的推理、原型评估、情景评审、检查单

12.9基于模式的体系结构评审

12.11敏捷性与体系结构

【1】有节制的敏捷

第十五节课

第十四章 用户界面设计

典型的设计错误：

• 缺乏一致性：色彩、布局

• 记忆负担过重

• 没有导向或帮助

• 语境不敏感

• 反馈不佳

• 晦涩难懂/不友好

14.1黄金原则

14.1.1用户操纵控制

• 不强迫用户进入不必要的不希望的动作来定义交互模式：接口隔离
• 提供灵活交互：响应时长等
• 允许用户交互被中断和撤销
• 当技能级别增长时可以交互流线化，允许定制交互
• 用户与内部技术细节隔离开来
• 设计应用应允许用户与屏幕对象直接交互

14.1.2减少用户记忆负担

• 减少短期记忆要求：十分钟法则
• 建立有意义的省缺
• 定义直观的快捷方式
• 视觉布局应该具有真实世界象征：图标清晰明了
• 渐进式揭示信息

14.1.3保持界面一致

• 允许用户将当前任务放入有意义的环境
• 完整的产品线内一致性

14.2用户界面设计

14.2.1用户界面设计过程

界面分析、建模–》界面确认–》界面构造–》界面设计

14.3界面分析

14.3.1用户分析

• 经过训练？
• 正规教育水平？
• 能力？
• 键盘恐惧？
• 年龄范围？
• 性别差异？
• 办公时间？
• 集成？
• 交流语言？
• 出错？
• 领域专家？

14.3.2任务分析和建模

【1】目标：

• 指定环境用户将完成什么工作
• 当用户工作完成时将完成什么任务和子任务
• 在工作中用户将处理什么特殊问题域对象
• 工作任务的顺序（工作流）
• 任务的层次关系

【2】分析和建模

• 用例：基本的交互方式
• 任务细化：细化交互任务
• 对象细化：标识界面对象（类）
• 工作流分析：多个角色工作过程，泳道图
• 层次表示

14.3.3显示内容分析

内容格式、位置、美感

• 不同类型数据放在固定位置？（照片一般在xx）
• 用户能否定制内容位置
• 所有内容适当屏幕标识
• 如何划分长篇报告
• 大集合数据，费否存在直接移动到摘要信息的机制
• 输出图形大小受设备限制
• 颜色增强理解
• 出错信息和警告如何呈现

14.3.4工作环境分析

• 确定了接口操作的物理结构、社会结构：键盘、鼠标、触摸屏、显示方为、亮度/文化氛围、信息共享、交互时间、准确性

14.4界面设计步骤

14.4.1应用界面设计步骤

【1】运用界面设计模式

【2】设计时注意的问题：系统响应时间、帮助设施、错误处理、菜单、命令标记、可访问性、国际化

【3】再结合一下步骤：

• 定义界面对象和动作
• 确定事件
• 描述每个状态的表示形式
• 说明用户如何从界面提供信息来解释状态

14.4.2用户界面设计模式

14.4.3设计问题

14.5设计评估

14.5.1设计评估周期

• 初步设计
• 建立第一级原型界面
• 用户评估界面
• 设计者研究评估
• 对设计进行修改
• 建立第n级原型界面
• 在3和6进行迭代
• 界面设计完成

14.5.2评估标准

避免设计错误

• 学习难度
• 交互时间
• 记忆内容
• 接收程度
• 系统总体效率

第十六节课

第15章 质量概念

第十七节课