结构化开发方法【软考】"/>
结构化开发方法【软考】
文章目录
- 一、 系统分析与设计概述
- 1. 系统分析概述
- (1)系统分析的任务
- (2)系统分析的主要步骤
- 2. 系统设计的基本原理
- (1)抽象
- (2)模块化
- (3)信息隐蔽
- (4)模块独立
- 3. 系统总体结构设计
- (1)系统结构设计原则
- (2)子系统划分
- ① 子系统划分的原则
- ② 子系统结构设计
- (3)系统模块结构设计
- ① 模块的概念
- ② 模块结构图
- (4)数据存储设计
- 4. 系统文档
- 二、 结构化分析方法
- 1. 结构化分析方法概述
- 2. 数据流图(Data Flow Diagram,DFD)
- (1)数据流图的基本图形元素
- (2)数据流图的扩充符号
- (3)数据流图的层次结构
- (4)分层数据流图的画法
- (5)分层数据流图的审查
- 3. 数据字典(DD)
- (1)数据字典的内容
- (2)数据词典管理
- (3)加工逻辑的描述
- 三、 结构化设计(Structured Design,SD)方法
- 1. 结构化设计的步骤
- (1)建立初始结构图
- (2)对结构图的改进
- (3)书写设计文档
- (4)设计评审
- 2. 数据流图到软件体系结构的映射
- (1)信息流的类型
- (2)变换分析
- 四、 WebApp分析与设计
- 1. WebApp的特性
- 2. WebApp 需求模型
- (1)内容模型
- (2)交互模型
- (3)功能模型
- (4)导航模型
- (5)配置模型
- 3. WebApp设计
- (1)架构设计
- (2)构件设计
- (3)内容设计
- (4)导航设计
- 五、 用户界面设计
- 1. 用户界面设计的黄金原则
- (1)1.用户操纵控制
- (2)减轻用户的记忆负担
- (3)保持界面一致
- 2. 用户界面的分析与设计
- (1)用户界面分析和设计模型
- (2)用户界面分析和设计的过程
- 3. 用户界面设计问题
- (1)系统响应时间
- (2)帮助设施
- (3)错误信息处理
- (4)菜单和命令标记
计算机技术与软件专业技术资格(水平)考试目录
一、 系统分析与设计概述
由结构化分析【根据分解与抽象的原则,按照系统中数据处理的流程,用数据流图来建立系统的功能模型,从而完成需求分析工作】、结构化设计【根据模块独立性准则、软件结构优化准则将数据流图转换为软件的体系结构,用软件结构图来建立系统的物理模型,实现系统的概要设计】、结构化程序设计【任何程序都可以由顺序、选择和重复 3 3 3种基本控制结构构造】构成,是一种面向数据流的开发方法,是软件工程中最早出现的开发方法,特别适合于数据处理领域的问题,但不适合解决大规模的、特别复杂的项目,且难以适应需求的变化。
指导思想:自顶向下、逐层分解;基本原则:功能的分解与抽象。
1. 系统分析概述
是一种问题求解技术,它将一个系统分解成各个组成部分,目的是研究各个部分如何工作、交互,以实现其系统目标。
目的:为项目团队提供对触发项目的问题和需求的更全面的理解,因此强调业务问题方面,而非技术或实现方面。系统分析阶段要求和系统用户一起工作,以便清楚地定义新系统的业务需求和预期。
(1)系统分析的任务
主要任务:对现行系统进一步详细调查,将调查中所得到的文档资料集中,对组织内部整体管理状况和信息处理过程进行分析,为系统开发提供所需的资料,并提交系统方案说明书。
(2)系统分析的主要步骤
- 认识、理解当前的现实环境,获得当前系统的“物理模型”
- 从当前系统的“物理模型”抽象出当前系统的“逻辑模型”
- 对当前系统的“逻辑模型”进行分析和优化,建立目标系统的“逻辑模型”
- 对目标系统的逻辑模型具体化(物理化),建立目标系统的“物理模型”
系统开发的目的:把现有系统的物理模型转化为目标系统的物理模型【反映的是系统的某一种具体实现方案】,系统分析阶段的结果:得到目标系统的逻辑模型【反映了系统的功能和性质】
可将系统分析阶段的主要工作分为以下几步:
① 对当前系统进行详细调查,收集数据。
② 建立当前系统的逻辑模型。
③ 对现状进行分析,提出改进意见和新系统应达到的目标。
④ 建立新系统的逻辑模型。
⑤ 编写系统方案说明书。
2. 系统设计的基本原理
(1)抽象
是一种设计技术,重点说明一个实体的本质方面,而忽略或者掩盖不太重要或非本质的方面;是一种重要的工具,用来将复杂的现象简化到可以分析、实验或者可以理解的程度。
(2)模块化
指将一个待开发的软件分解成若干个小的简单部分——模块【在程序中是数据说明、可执行语句等程序对象的集合,或者是单独命名和编址的元素】,每个模块可独立地开发、测试,最后组装成完整的程序。
目的:使程序的结构清晰,容易阅读、理解、测试和修改。
(3)信息隐蔽
是开发整体程序结构时使用的法则,即将每个程序的成分隐蔽或封装在一个单一的设计模块中,在定义每一个模块时尽可能少地显露其内部的处理。
信息隐蔽原则对提高软件的可修改性、可测试性和可移植性都有重要的作用。
(4)模块独立
指每个模块完成一个相对独立的特定子功能,并且与其他模块之间的联系简单。衡量模块独立程度的标准有两个:耦合性和内聚性。
耦合性和内聚性是模块独立性的两个定性标准,在将软件系统划分模块时,应尽量做到高内聚、低耦合
,提高模块的独立性。
- 耦合
是模块之间的相对独立性(互相连接的紧密程度)的度量。耦合取决于各个模块之间接口的复杂程度、调用模块的方式以及通过接口的信息类型等。
- 内聚
是对一个模块内部各个元素彼此结合的紧密程度的度量。一个内聚程度高的模块(在理想情况下)应当只做一件事。
3. 系统总体结构设计
是要根据系统分析的要求和组织的实际情况对新系统的总体结构形式和可利用的资源进行大致设计,这是一种宏观、总体上的设计和规划。
(1)系统结构设计原则
- 一致性原则
- 明确性原则
- 分解—协调原则
- 自顶向下的原则
- 模块的规模适当
- 信息隐蔽、抽象的原则
- 模块的扇入系数和扇出系数要合理
- 模块之间的耦合尽可能小,模块的内聚度尽可能高
(2)子系统划分
① 子系统划分的原则
- 子系统要具有相对独立性
- 子系统之间数据的依赖性尽量小
- 子系统划分的结果应使数据冗余较小
- 子系统的划分应便于系统分阶段实现
- 子系统的设置应考虑今后管理发展的需要
- 子系统的划分应考虑到各类资源的充分利用
② 子系统结构设计
任务:确定划分后的子系统模块结构,并画出模块结构图,子系统设计时必须考虑以下几个问题:
- 每个子系统如何划分成多个模块
- 如何评价并改进模块结构的质量
- 如何从数据流图导出模块结构图
- 如何确定子系统之间、模块之间传送的数据及其调用关系
(3)系统模块结构设计
① 模块的概念
是组成系统的基本单位,系统中的任何一个处理功能都可以看成是一个模块,根据功能具体化程度的不同,模块可以分为逻辑模块【定义的处理功能】和物理模块【是逻辑模块的具体化】,特点【可以组合、分解和更换】,一个模块应具备 4 4 4 个要素:输入和输出;处理功能;内部数据;程序代码。指用来实现模块功能的程序。
② 模块结构图
模主要关心:模块的外部属性【上下级模块、同级模块之间的数据传递和调用关系】,是结构化设计中描述系统结构的图形工具。结构设计原则:
- 模块之间的连接只能存在上下级之间的调用关系,不能有同级之间的横向联系
- 所有模块(包括后继 IPO 图)都必须严格地分类编码并建立归档文件
- 整个系统呈树状结构,不允许网状结构或交叉调用关系出现
- 具有较强的独立性
(4)数据存储设计
数据结构组织和数据库或文件设计:要根据数据的不同用途、使用要求、统计渠道和安全保密性等来决定数据的整体组织形式、表或文件的形式,以及决定数据的结构、类别、载体、组织方式、保密级别等一系列的问题。
一个好的数据结构和数据库应该充分满足组织的各级管理要求,同时还应该使后继系统的开发工作方便、快捷、系统开销小、易于管理和维护。
在建立了数据的整体结构之后,剩下的就是要确定数据的资源分布【针对分布数据库系统而言的】和安全保密性【针对某些特殊信息】
4. 系统文档
是系统建设过程的“痕迹”,是系统维护人员的指南,是开发人员与用户交流的工具。
规范的文档:意味着系统是按照工程化开发的,信息系统的质量有了形式上的保障。
文档的欠缺、文档的随意性和文档的不规范,极有可能导致原来的开发人员流动以后,系统不可维护、不可升级,变成了一个没有扩展性、没有生命力的系统。
- 用户与系统分析人员在系统规划和系统分析阶段通过文档进行沟通
- 系统开发人员与项目管理人员通过文档在项目期内进行沟通
- 系统开发人员与系统维护人员通过文档进行沟通
- 系统测试人员与系统开发人员通过文档进行沟通
- 系统开发人员与用户在系统运行期间进行沟通
- 用户与维修人员在运行维护期间进行沟通
二、 结构化分析方法
是一种面向数据流的传统软件开发方法,它以数据流为中心构建软件的分析模型和设计模型。
完整的结构化方法包括:结构化分析(Structured Analysis,SA)、结构化设计(Structured Design,SD)和结构化程序设计(Structured Programming Design,SPD)
1. 结构化分析方法概述
结构化方法:采用自顶向下逐层分解的思想进行分析建模的。
结构化方法的分析结果由:一套分层的数据流图、一本数据词典、一组小说明(也称加工逻辑说明)、补充材料组成。
抽象和分解是处理任何复杂问题的两个基本手段
。抽象:指忽略一个问题中与当前目标无关的那些方面,以便更充分地关注与当前目标有关的方面。
2. 数据流图(Data Flow Diagram,DFD)
也称数据流程图,它是一种便于用户理解、分析系统数据流程的图形工具,摆脱了系统的物理内容,精确地在逻辑上描述系统的功能、输入、输出和数据存储等,是系统逻辑模型的重要组成部分
。
(1)数据流图的基本图形元素
包括:数据流(Data Flow)、加工(Process)、数据存储(Data Store)和外部实体(External Agent)。其中,数据流、加工和数据存储用于构建软件系统内部的数据处理模型;外部实体表示存在于系统之外的对象,用来帮助用户理解系统数据的来源和去向。
- 数据流
由一组固定成分的数据组成,表示数据的流向。 - 加工
描述了输入数据流到输出数据流之间的变换,也就是输入数据流经过什么处理后变成了输出数据流。 - 数据存储
用来存储数据。 - 外部实体(外部主体)
指存在于软件系统之外的人员或组织,它指出系统所需数据的发源地(源)和系统所产生的数据的归宿地(宿)。
(2)数据流图的扩充符号
在DFD中,一个加工可以有多个输入数据流和多个输出数据流,此时可以加上一些扩充符号来描述多个数据流之间的关系。
- 星号(*)
表示数据流之间存在"与"关系。 - 加号(+)
表示数据流之间存在“或”关系。 - 异或(⊕)
表示数据流之间存在“互斥”关系。
(3)数据流图的层次结构
- 层次结构
顶层图:分层数据流图的顶层只有一张图,其中只有一个加工,代表整个软件系统,该加工描述了软件系统与外界之间的数据流。
0 0 0层图:顶层图中的加工(即系统)经分解后的图称,只有一张。
处于分层数据流图最
底层图:处于分层数据流图最底层的图,在底层图中,所有的加工不再进行分解。
中间层:分层数据流图中的其他图,其中至少有一个加工(也可以是所有加工)被分解成一张子图。
基本加工:在整套分层数据流图中,不再分解成子图的加工。 - 图和加工的编号
如果某图(记为A)中的某一个加工分解成一张子图(记为B),则称A是B的父图,B是
A的子图。若父图中有 n n n 个加工,则它可以有 0 ~ n 0~n 0~n 张子图,但每张子图只对应一张父图。
(4)分层数据流图的画法
-
画系统的输入和输出
系统的输入和输出用顶层图来描述,即描述系统从哪些外部实体接收数据流,以及系统发送数据流到哪些外部实体。 -
画系统的内部
将顶层图的加工分解成若干个加工,并用数据流将这些加工连接起来,使得顶层图中的输入数据经过若干个加工处理后变换成顶层图的输出数据流,这张图称为 0 0 0 层图。从一个加工画出一张数据流图的过程实际上就是对这个加工的分解:确定加工、确定数据流、确定数据存储、确定源和宿。 -
画加工的内部
当 DFD 中存在某个比较复杂的加工时,可以将它分解成一张 DFD 子图。分解的方法:将该加工看作一个小系统,该加工的输入/输出数据流就是这个假设的小系统的输入/输出数据流,然后采用画 0 0 0层图的方法画出该加工的子图。
考务处理系统的功能需求如下:
① 对考生送来的报名单进行检查。
② 对合格的报名单编好准考证号后将准考证送给考生,并将汇总后的考生名单送给阅卷站。
③ 对阅卷站送来的成绩清单进行检查,并根据考试中心指定的合格标准审定合格者。
④ 制作考生通知单(内含成绩合格/不合格标志)送给考生。
⑤ 按地区、年龄、文化程度、职业和考试级别等进行成绩分类统计和试题难度分析,产生统计分析表。
部分数据流的组成如下:
报名单 = 地区 + 序号 + 姓名 + 文化程度 + 职业 + 考试级别 + 通信地址
正式报名单 = 准考证号 + 报名单
准考证 = 地区 + 序号 + 姓名 + 准考证号 + 考试级别 + 考场
考生名单 = { 准考证号 + 考试级别 }( {w} :w 重复多次)
考生名册 = 正式报名单
统计分析表 = 分类统计表 + 难度分析表
考生通知单 = 准考证号 + 姓名 + 通信地址 + 考试级别 + 考试成绩 + 合格标志
(5)分层数据流图的审查
- 分层数据流图的一致性和完整性
分层数据流图的一致性:指分层DFD中不存在矛盾和冲突,包括:父图与子图的平衡;数据守恒;局部数据存储;一个加工的输出数据流不能与该加工的输入数据流同名
分层数据流图的完整性:分层 DFD 本身的完整性,即是否有遗漏的数据流、加工等元素,包括:每个加工至少有一个输入数据流和一个输出数据流;在整套分层数据流图中,每个数据存储应至少有一个加工对其进行读操作,另一个加工对其进行写操作;分层数据流图中的每个数据流和文件都必须命名,并保持与数据字典一致;分层数据流图中的每个基本加工都应有一个加工规约。
分层DFD的一致性和完整性实际上反映了图本身的正确性,但是图本身的正确性并不意味着分析模型的正确性,分析模型的正确性要根据模型是否满足用户的需求来判断。 - 构造分层DFD时需要注意的问题
适当命名
随时准备重画
分解尽可能均匀
画数据流而不是控制流
避免一个加工有过多的数据流
先考虑确定状态,忽略琐碎的细节 - 分解的程度
7 加减 2
分解要均匀
分解应自然,概念上应合理、清晰
只要不影响DFD的易理解性,可适当增加子加工数量,以减少层数
一般来说,上层分解得快一些(即多分解几个加工),下层分解得慢一些(即少分解几个加工)
3. 数据字典(DD)
是为数据流图中的每个数据流、文件、加工,以及组成数据流或文件的数据项做出说明。其中,对加工的描述称为“小说明”,也称为“加工逻辑说明”。
(1)数据字典的内容
有 4 4 4 类条目:数据流、数据项【是组成数据流和数据存储的最小元素】、数据存储和基本加工。源点、终点不在系统之内,故一般不在字典中说明。
- 数据流条目:通常列出该数据流的各组成数据项,在定义数据流或数据存储组成时,使用符号:
- 数据存储条目:是对数据存储的定义
- )数据项条目:是不可再分解的数据单位
- 基本加工条目:是用来说明DFD中基本加工的处理逻辑的
(2)数据词典管理
主要是把词典条目按照某种格式组织后存储在词典中,并提供排序、查找和统计等功能。如果数据流条目包含了来源和去向,文件条目包含了读文件和写文件,还可以检查数据词典与数据流图的一致性。
(3)加工逻辑的描述
- 结构化语言
一种介于自然语言和形式化语言之间的半形式化语言,是自然语言的一个受限子集。没有严格的语法,它的结构通常可分为内层【语法比较灵活,接近于自然语言的描述】和外层【有严格的语法,用来描述控制结构,采用顺序、选择和重复 3 3 3 种基本结构】。 - 判定表
能够清楚地表示复杂的条件组合与应做的动作之间的对应关系,由 4 4 4 个部分组成,用双线分割成 4 4 4 个区域:
- 判定树
是判定表的变形,一般情况下它比判定表更直观,且易于理解和使用。
三、 结构化设计(Structured Design,SD)方法
基本思想:将系统设计成由相对独立、功能单一的模块组成的结构。
是一种面向数据流的设计方法,可以与 SA 方法衔接,用结构图(Structure Chart)来描述软件系统的体系结构,指出一个软件系统由哪些模块组成,以及模块之间的调用关系。
1. 结构化设计的步骤
(1)建立初始结构图
结构化方法本质上是一种功能分解方法。
功能模块的分解设计准则:自顶向下、逐步求精、信息隐蔽、高内聚低耦合等。
(2)对结构图的改进
可根据设计准则对初始结构图存在一些不合理的设计(包括不合理的模块分解)进行改进。
(3)书写设计文档
在概要设计完成之后应书写设计规格说明,特别要为每个模块书写模块的功能、接口、约束和限制等,必要时可建立模块开发卷宗。
(4)设计评审
对设计结果及文档进行评审。
2. 数据流图到软件体系结构的映射
结构化设计是将结构化分析的结果(数据流图)映射成软件的体系结构(结构图)。根据信息流的特点,可将数据流图分为变换型数据流图和事务型数据流图,其对应的映射分别称为变换分析和事务分析。
(1)信息流的类型
- 变换流
信息沿着输入通路进入系统,同时将信息的外部形式转换成内部表示,然后通过变换中心(也称主加工)处理,再沿着输出通路转换成外部形式离开系统。分成:输入、变换(主加工)和输出三大部分。 - 事务流
信息沿着输入通路到达一个事务中心,事务中心根据输入信息(即事务)的类型在若干个动作序列(称为活动流)中选择一个来执行。有明显的事务中心,各活动流以事务中心为起点呈辐射状流出。
(2)变换分析
- 确定输入流和输出流,分离出变换中心
物理输入:系统输入端的数据流。
物理输出:系统输出端的数据流。
逻辑输入:从物理输入端开始,一步步向系统的中间移动,可找到离物理输入端最远,但仍可被看作系统输入的那个数据流。
逻辑输出:从物理输出端开始,一步步向系统的中间移动,可找到离物理输出端最远,但仍可被看作系统输出的那个数据流。
DFD 中从物理输入到逻辑输入的部分构成系统的输入流,从逻辑输出到物理输出的部分构成系统的输出流,位于输入流和输出流之间的部分就是变换中心。 - 第一级分解
主要是设计模块结构的顶层和第一层。顶层模块的功能就是整个系统的功能。输入控制模块用来接收所有的输入数据,变换控制模块用来实现输入到输出的变换,输出控制模块用来产生所有的输出数据。
- 第二级分解
要是设计中、下层模块。
输入控制模块的分解:从变换中心的边界开始,沿着每条输入通路,把输入通路上的每个加工映射成输入控制模块的一个低层模块。
输出控制模块的分解:从变换中心的边界开始,沿着每条输出通路,把输出通路上的每个加工映射成输出控制模块的一个低层模块。
变换控制模块的分解:没有通用的分解方法,根据 DFD 中变换部分的实际情况进行设计。 - 事务分析
是从事务流型 DFD 导出程序结构图。
① 确定事务中心和每条活动流的流特性。
② 将事务流型DFD映射成高层的程序结构。
③ 进一步分解 - SD 方法的设计步骤
① 复查并精化数据流图。
② 确定DFD的信息流类型(变换流或事务流)。
③ 根据流类型分别实施变换分析或事务分析。
⑤ 根据系统设计的原则对程序结构图进行优化。
四、 WebApp分析与设计
1. WebApp的特性
- 网络密集性
WebApp 驻留在网络上,服务于不同客户全体的需求。 - 并发性
大量用户可能同时访问 WebApp。 - 无法预知的负载量
WebApp 的用户数量每天都可能有数量级的变化。 - 性能
如果一位 WebApp 用户访问必须等待很长时间,该用户就可能转向其他地方。 - 可用性
对于热门的 WebApp,用户通常要求能够全天候访问。 - 数据驱动
许多 WebApp 的主要功能是使用超媒体向最终用户提供文本、图片、音频及视频内容;WebApp 还常被用来访问那些存储在 Web 应用环境之外的数据库中的信息。
2. WebApp 需求模型
(1)内容模型
给出由 WebApp 提供的全部系列内容
【包括文字、图形、图像、音频和视频】,包含结构元素【为WebApp的内容需求提供了一个重要的视图】,这些结构元素包含内容对象【是呈现给最终用户具有汇聚信息的所有条目】和所有分析类,在用户与WebApp交互时生成并操作用户可见的实体。
由多项内容对象和数据项组成的任何内容都可以生成数据树。开发数据树尽力在内容对象中定义层级关系,并提供一种审核内容的方法,以便在开始设计前发现遗漏和不一致的内容。数据树可以作为内容设计的基础
。
数据树表述了常用于描述某个构件的一种信息层次,不带阴影的长方形:简单或复合数据项(一个或多个数据值),带阴影的长方形:内容对象。在某些情况下,随着数据数的扩展,其中的一个或多个对象将会得
到进一步细化。
(2)交互模型
描述了用户与WebApp采用了哪种交互方式
,型由一种或多种元素构成。绝大多数 WebApp 都能使最终用户与应用系统的功能、内容及行为之间进行“会话”。
- 状态图是交互分析中对系统进行动态的描述
- 顺序图是交互分析中描述用户与系统进行交互的方式
- 用例是交互分析的主要工具,方便客户理解系统的功能
- 用户界面原型展现用户界面布局、内容、主要导航链接、实施的交互机制及用户 WebApp 的整体美观度
(3)功能模型
定义了将用于 WebApp 内容并描述其他处理功能的操作
,这些处理功能不依赖于内容却是最终用户所必需的。
描述 WebApp 的两个处理元素,每个处理元素代表抽象过程的不同层次:用户可观察到的功能是由 WebApp 传递给最终用户的;分析类中的操作实现与类相关的行为。
(4)导航模型
为 WebApp 定义所有导航策略
,考虑了每一类用户如何从一个 WebApp 元素导航到另一个元素。把导航机制定义为设计的一部分,在这个阶段,分析人员应该关注于总体的导航需求。
(5)配置模型
描述 WebApp 所在的环境和基础设施
。
3. WebApp设计
好的 WebApp 应该具有的最相关的通用特性:可用性、功能性、可靠性、效率、可维护性、安全性、可扩展性、以及及时性。
目标:简单性、一致性、符合性、健壮性、导航性、视觉吸引力与兼容性。
(1)架构设计
典型使用多层架构来构造,模型-视图-控制器(Model-View-Controller,MVC)结构是WebApp 基础结构模型之一,它将 WebApp 功能及信息内容分离。
(2)构件设计
通常包括内容设计元素【注内容对象,以及包装后展示给最终用户的方式,应该适合创建的WebApp特性】和功能设计元素【将WebApp作为一系列构件加以交付,这些构件与信息体系结构并行开发,以确保一致性】
(3)内容设计
内容体系结构着重于内容对象(诸如网页的组成对象)的表现和导航的组织,通常采用线性结构、网格结构、层次结构、网络结构四种结构及其组合。
(4)导航设计
定义导航路径,使用户可以访问 WebApp 的内容和功能。
五、 用户界面设计
在人与计算机之间搭建了一个有效的交流媒介。遵循一系列的界面设计原则定义界面对象和界面设计动作,然后创建构成用户界面原型基础的屏幕布局。
1. 用户界面设计的黄金原则
(1)1.用户操纵控制
- 提供灵活的交互
- 允许中断和撤销用户交互
- 使用户与内部技术细节隔离开来
- 设计应允许用户与出现在屏幕上的对象直接交互
- 当技能级别增长时可以使交互流线化并允许定制交互
- 以不强迫用户进入不必要的或不希望的动作的方式来定义交互模式
(2)减轻用户的记忆负担
- 建立有意义的默认
- 定义直观的快捷方法
- 减少对短期记忆的要求
- 以不断进展的方式揭示信息
- 界面的视觉布局应该基于真实世界的象征
(3)保持界面一致
- 在应用系统家族内保持一致性
- 允许用户将当前任务放入有意义的环境中
- 如果过去的交互模型已经建立起了用户期望,除非有不得已的理由,否则不要改变它
2. 用户界面的分析与设计
(1)用户界面分析和设计模型
- 软件工程师所创建的设计模型(Design Model)
包括对软件的数据结构、体系结构、界面和过程的表示,界面设计往往是设计模型的附带结果。 - 人机界面设计工程师创建的用户模型(User Model)
用户模型描述系统最终用户的特点
。 - 最终用户在脑海里对界面产生的映像,称为用户的心理模型或系统感觉(SystemPerception)
是最终用户主观想象的系统映像,描述了期望的系统能提供的操作,其描述的精确程度依赖于最终用户对软件的熟悉程度。 - 系统实现者创建的系统映像(System Image)
包括基于计算机的系统的外在表示和用来描述系统语法和意义的支撑信息。
(2)用户界面分析和设计的过程
是迭代的,包括 4 4 4 个不同的框架活动:
- 界面分析及建模
重点在于那些与系统交互的用户的轮廓,记录技能级别、业务理解以及对新系统的一般感悟,并定义不同的用户类型,对每个用户类别进行需求引导。 - 界面设计
目标是定义一组界面对象和动作,使得用户能够以满足系统所定义的每个使用目标的方式完成所有定义的任务。 - 界面构造
通常开始于创建可评估使用场景的原型。 - 界面确认
着重于:界面正确地实现每个用户任务的能力、适应所有任务变化的能力以及达到所有一般用户需求的能力;界面容易使用和学习的程度;用户将界面作为其工作中有用工具的接受程度。
3. 用户界面设计问题
在进行用户界面设计时,几乎总会遇到以下4个问题:系统响应时间、帮助设施、错误信
息处理、菜单和命令标记。
(1)系统响应时间
指从用户开始执行动作到软件以预期的输出和动作形式给出响应这段时间。
系统响应时间包括两方面的属性:时间长度【如果系统响应时间过长,用户就会感到焦虑和沮丧】和可变性【指相对于平均时间的偏差,是最重要的响应时间特性
,即使响应时间比较长,响应时间的低可变性也有助于用户建立稳定的交互节奏】
(2)帮助设施
- 进行系统交互时,是否在任何时候对任何系统功能都能得到帮助
提供部分功能与动作的帮助、提供全部功能的帮助。 - 用户怎样请求帮助
帮助菜单、特殊功能键、HELP命令。 - 如何表达帮助
提供单独的帮助窗口、在另一个窗口中指示参考某个已印刷的文档、在屏幕特定位置给出一行或两行的简单提示。 - 用户如何回到正常的交互方式
屏幕上显示的返回按钮、功能键或控制序列。 - 如何构造帮助信息
平面结构、分层结构、超文本的使用
(3)错误信息处理
出错信息和警告是指出现问题时系统反馈给用户的“坏消息”,应具备以下特征:
- 消息伴随着视觉或听觉上的提示
- 消息以用户可以理解的语言描述问题
- 消息不应是裁判性的,即不能指责用户
- 消息应提供如何从错误中回复的建设性意见
- 消息应指出错误可能导致哪些不良后果,以便用户检查是否出现了这些情况
(4)菜单和命令标记
- 每个菜单选择是否都有对应的命令
- 以何种方式提供命令
控制序列、功能键、输入命令。 - 学习和记忆命令的难度有多大、忘记命令怎么办
- 用户是否可以定制和缩写命令
- 在界面环境中菜单标签是不是自解释的
- 子菜单是否与主菜单所指的功能相一致
更多推荐
结构化开发方法【软考】
发布评论