软件工程笔记
第一节课
2.3.2通用原则(HOOKER概括性原则)——在软件开发过程中,注意使用这些原则考虑问题
- 存在价值:原则一,最重要,最基础,有没有必要做
- 商业价值:是否有市场前景与市场价值,比如引入流量、占用市场、竞争客户等用途
- KISS(保持简洁):减少错误,易于维护,首先需要将问题理解透
- 保持愿景:软件项目成功的基础,团队具有一个一致的目标
- 关注使用者:广义的使用者——包括架构设计、编码人员、维护人员、客户等
- 面向未来:生命周期持久,价值高,即有前瞻性(比如遗留系统的核心业务,接纳新功能的能力)
- 提前计划复用:具有前瞻性设计和计划,积累经验,质量有保障
- 认真思考:权衡与决策
2.4软件开发神话
- 管理神话
- 客户神话
- 从业者神话
2.5一切是如何开始的——业务需求
案例:课本P18/P34/P37
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-SUObEFOT-1686190806459)(E:\课程\2019学年下学期\软件工程\笔记\246]VWTS$9S4K2FLJ_ZX`54.png)]
提出概念产品的设想:家庭管理软件
技术可行性研究:硬件、软件、技术
第四章 过程模型
软件工程工作的路线图=流程+动作+任务+迭代程度+工作产品+组织工作……
4.1惯用过程模型
4.1.1瀑布模型
框架过程流时按照线性关系排布的。
特点:
- 阶段间的顺序性,依赖性(下一步依赖上一步的结果)
- 推迟实现的观点,(产品到最后才能看见)
- 质量保证的观点(重视文档,以便尽早发现问题)
问题:
- 实际项目很少严格遵循,容易导致项目处于“阻塞状态”-------依赖关系
- 难适应有些项目开始阶段必然存在的需求不确定性------------适用于开始需求就明确的项目
- 客户到尾声才能得到可执行程序,前期存在缺陷,则造成很大损失
4.1.2V模型
在瀑布模型的每个阶段加上测试;
[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-0hPU3pQL-1686190806460)(E:\课程\2019学年下学期\软件工程\笔记\GB6$TZIMIQY%Q~DSE]0%5BI.png)]
4.1.3增量过程模型
将工作分为增量,增量内使用瀑布模型
内部:线性过程流
总体:并行过程流(多个增量同时进行)
优点:
- 在较短时间提交有用的工作产品
- 逐步增加功能,可以使用户有时间学习和适应新产品
- 失败风险低
- 优先级最高的服务首先交付,总重要的服务需要最多测试------保证核心功能质量
注意:
- 新的增量加入进来,不会破坏原来的产品
- 体系结构必须是开放的
- 比瀑布模型、原型模型需要更多设计
4.1.4演化过程模型
(1)原型模型
沟通-策划-建模-构建原型-部署交付的循环
常用工具:墨刀(制作原型)
目的:尽快获知用户需求
关注点:原型是否需要保留?一般是选择抛弃,需要事先沟通好
(2)螺旋模型
见P35
特点:
- 风险驱动型过程模型,每一步都有风险的评估与分析
- 适合大型系统和软件
- 把原型作为降低风险的机制
- 可以表示软件的整个生命周期,可以考虑到维护等
优点:
- 有助于将软件质量和软件重用定位重要目标的开发
- 主动控制风险
缺点:
- 对开发人员要求较高,要求具有丰富的风险评估经验和知识
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章 质量概念