软件工程导论 第6章 详细设计FinishedWord文档格式.docx
- 文档编号:7515313
- 上传时间:2023-05-08
- 格式:DOCX
- 页数:45
- 大小:352.87KB
软件工程导论 第6章 详细设计FinishedWord文档格式.docx
《软件工程导论 第6章 详细设计FinishedWord文档格式.docx》由会员分享,可在线阅读,更多相关《软件工程导论 第6章 详细设计FinishedWord文档格式.docx(45页珍藏版)》请在冰点文库上搜索。
上述经典定义过于狭隘了,结构程序设计本质上并不是无GOTO语句的编程方法,而是一种使程序代码容易阅读、容易理解的编程方法。
在多数情况下,无GOTO语句的代码确实是容易阅读、容易理解的代码,但是,在某些情况下,为了达到容易阅读和容易理解的目的,反而需要使用GOTO语句。
例如,当出现了错误条件时,重要的是在数据库崩溃或栈溢出之前,尽可能快地从当前程序转到一个出错处理程序,实现这个目标的最好方法就是使用前向GOTO语句(或与之等效的专用语句),机械地使用3种基本控制结构实现这个目标,反而会使程序晦涩难懂。
因此,下述的结构程序设计的定义可能更全面一些:
“结构程序设计是尽可能少用GOTO语句的程序设计方法。
最好仅在检测出错误
时才使用GOTO语句,而且应该总是使用前向GOTO语句。
虽然从理论上说只用上述3种基本控制结构就可以实现任何单入口单出口的程序,
但是为了实际使用方便起见,常常还允许使用DO_UNTIL和DO_CASE两种控制结
构,它们的流程图分别是图6.2(a)和图6.2(b)。
有时需要立即从循环(甚至嵌套的循环)中转移出来,如果允许使用LEAVE(或BREAK)结构,则不仅方便而且会使效率提高很多。
LEAVE或BREAK结构实质上是受限制的GOTO语句,用于转移到循环结构后面的语句。
如果只允许使用顺序、IF_THEN_ELSE型分支和DO_WHILE型循环这3种基本控制结构,则称为经典的结构程序设计;
如果除了上述3种基本控制结构之外,还允许使用DO_CASE型多分支结构和DO_UNTIL型循环结构,则称为扩展的结构程序设计;
如果再加上允许使用LEAVE(或BREAK)结构,则称为修正的结构程序设计。
6.2人机界面设计
人机界面设计是接口设计的一个重要的组成部分。
对于交互式系统来说,人机界面设计和数据设计、体系结构设计及过程设计一样重要。
近年来,人机界面在系统中所占的比例越来越大,在个别系统中人机界面的设计工作量甚至占总设计量的一半以上。
人机界面的设计质量,直接影响用户对软件产品的评价,从而影响软件产品的竞争力和寿命,因此,必须对人机界面设计给予足够重视。
6.2.1设计问题
在设计人机界面的过程中,几乎总会遇到下述4个问题:
系统响应时间、用户帮助设施、出错信息处理和命令交互。
不幸的是,许多设计者直到设计过程后期才开始考虑这些问题,这样做往往导致出现不必要的设计反复、项目延期和用户产生挫折感。
最好在设计初期就把这些问题作为重要的设计问题来考虑,这时修改比较容易,代价也低。
下面讨论这4个设计问题。
1.系统响应时间
系统响应时间是许多交互式系统用户经常抱怨的问题。
一般说来,系统响应时间指从用户完成某个控制动作(例如,按回车键或点击鼠标),到软件给出预期的响应(输出信息或做动作)之间的这段时间。
系统响应时间有两个重要属性,分别是长度和易变性。
如果系统响应时间过长,用户就会感到紧张和沮丧。
但是,当用户工作速度是由人机界面决定的时候,系统响应时间过短也不好,这会迫使用户加快操作节奏,从而可能会犯错误。
易变性指系统响应时间相对于平均响应时间的偏差,在许多情况下,这是系统响应时间的更重要的属性。
即使系统响应时间较长,响应时间易变性低也有助于用户建立起稳定的工作节奏。
例如,稳定在1秒的响应时间比从0.1秒到2.5秒变化的响应时间要好。
用户往往比较敏感,他们总是担心响应时间变化暗示系统工作出现了异常。
2.用户帮助设施
几乎交互式系统的每个用户都需要帮助,当遇到复杂问题时甚至需要查看用户手册以寻找答案。
大多数现代软件都提供联机帮助设施,这使得用户无须离开用户界面就能解决自己的问题。
常见的帮助设施可分为集成的和附加的两类。
集成的帮助设施从一开始就设计在软件里面,通常,它对用户工作内容是敏感的,因此用户可以从与刚刚完成的操作有关的主题中选择一个请求帮助。
显然,这可以缩短用户获得帮助的时间,增加界面的友好性。
附加的帮助设施是在系统建成后再添加到软件中的,在多数情况下它实际上是一种查询能力有限的联机用户手册,人们普遍认为,集成的帮助设施优于附加的帮助设施。
具体设计帮助设施时,必须解决下述的一系列问题。
(1)在用户与系统交互期间,是否在任何时候都能获得关于系统任何功能的帮助信息?
有两种选择:
提供部分功能的帮助信息和提供全部功能的帮助信息。
(2)用户怎样请求帮助?
有3种选择:
帮助菜单,特殊功能键和HELP命令。
(3)怎样显示帮助信息?
在独立的窗口中,指出参考某个文档(不理想)和在屏幕固定位置显示简短提示。
(4)用户怎样返回到正常的交互方式中?
屏幕上的返回按钮和功能键。
(5)怎样组织帮助信息?
有3种选择:
平面结构(所有信息都通过关键字访问),信息的层次结构(用户可在该结构中查到更详细的信息)和超文本结构。
3.出错信息处理
出错信息和警告信息,是出现问题时交互式系统给出的“坏消息”。
出错信息设计得不好,将向用户提供无用的甚至误导的信息,反而会加重用户的挫折感。
一般说来,交互式系统给出的出错信息或警告信息,应该具有下述属性。
(1)信息应该用用户可以理解的术语描述问题。
(2)信息应该提供有助于从错误中恢复的建设性意见。
(3)信息应该指出错误可能导致哪些负面后果(例如,破坏数据文件),以便用户检查是否出现了这些问题,并在确实出现问题时及时解决。
(4)信息应该伴随着听觉上或视觉上的提示,例如,在显示信息时同时发出警告铃声,或者信息用闪烁方式显示,或者信息用明显表示出错的颜色显示。
(5)信息不能带有指责色彩,也就是说,不能责怪用户。
当确实出现了问题的时候,有效的出错信息能提高交互式系统的质量,减轻用户的挫折感。
4.命令交互
命令行曾经是用户和系统软件交互的最常用的方式,并且也曾经广泛地用于各种应用软件中。
现在,面向窗口的、点击和拾取方式的界面已经减少了用户对命令行的依赖,但是,许多高级用户仍然偏爱面向命令行的交互方式。
在多数情况下,用户既可以从菜单中选择软件功能,也可以通过键盘命令序列调用软件功能。
在提供命令交互方式时,必须考虑下列设计问题。
(1)是否每个菜单选项都有对应的命令?
(2)采用何种命令形式?
控制序列(例如,Ctrl+P),功能键和键入命令。
(3)学习和记忆命令的难度有多大?
忘记了命令怎么办?
(4)用户是否可以定制或缩写命令?
在越来越多的应用软件中,人机界面设计者都提供了“命令宏机制”,利用这种机制用户可以用自己定义的名字代表一个常用的命令序列。
需要使用这个命令序列时,用户无须依次键入每个命令,只需输入命令宏的名字就可以顺序执行它所代表的全部命令。
在理想的情况下,所有应用软件都有一致的命令使用方法。
如果在一个应用软件中命令Ctrl+D表示复制一个图形对象,而在另一个应用软件中Ctrl+D命令的含义是删除一个图形对象,显然会使用户感到困惑,并且往往会导致用错命令。
6.2.2设计过程
用户界面设计是一个迭代的过程,也就是说,通常先创建设计模型,再用原型实现这个设计模型,并由用户试用和评估,然后根据用户意见进行修改。
为了支持上述迭代过程,各种用于界面设计和原型开发的软件工具应运而生。
这些工具被称为用户界面工具箱或用户界面开发系统,它们为简化窗口、菜单、设备交互、出错信息、命令及交互环境的许多其他元素的创建,提供了各种例程或对象。
这些工具所提供的功能,既可以用基于语言的方式也可以用基于图形的方式来实现。
一旦建立起用户界面的原型,就必须对它进行评估,以确定其是否满足用户的需求。
评估可以是非正式的,例如,用户即兴发表一些反馈意见;
评估也可以十分正式,例如,运用统计学方法评价全体终端用户填写的调查表。
用户界面的评估周期如下所述:
完成初步设计之后就创建第一级原型;
用户试用并评估该原型,直接向设计者表述对界面的评价;
设计者根据用户意见修改设计并实现下一级原型。
上述评估过程持续进行下去,直到用户感到满意,不需要再修改界面设计时为止。
当然,也可以在创建原型之前就对用户界面的设计质量进行初步评估。
如果能及早发现并改正潜在的问题,就可以减少评估周期的执行次数,从而缩短软件的开发时间。
在创建了用户界面的设计模型之后,可以运用下述评估标准对设计进行早期复审。
(1)系统及其界面的规格说明书的长度和复杂程度,预示了用户学习使用该系统所需要的工作量。
(2)命令或动作的数量、命令的平均参数个数或动作中单个操作的个数,预示了系统的交互时间和总体效率。
(3)设计模型中包含的动作、命令和系统状态的数量,预示了用户学习使用该系统时需要记忆的内容的多少。
(4)界面风格、帮助设施和出错处理协议,预示了界面的复杂程度及用户接受该界面的程度。
6.2.3人机界面设计指南
用户界面设计主要依靠设计者的经验。
总结众多设计者的经验得出的设计指南,有助于设计者设计出友好、高效的人机界面。
下面介绍3类人机界面设计指南。
1.一般交互指南
一般交互指南涉及信息显示、数据输入和系统整体控制,因此,这类指南是全局性的,忽略它们将承担较大风险。
下面讲述一般交互指南。
(1)保持一致性。
应该为人机界面中的菜单选择、命令输入、数据显示以及众多的其他功能,使用一致的格式。
(2)提供有意义的反馈。
应向用户提供视觉的和听觉的反馈,以保证在用户和系统之间建立双向通信。
(3)在执行有较大破坏性的动作之前要求用户确认。
如果用户要删除一个文件,或覆盖一些重要信息,或终止一个程序的运行,应该给出“您是否确实要……”的信息,以请求用户确认他的命令。
(4)允许取消绝大多数操作。
UNDO或REVERSE功能曾经使众多终端用户避免了大量时间浪费。
每个交互式系统都应该能方便地取消已完成的操作。
(5)减少在两次操作之间必须记忆的信息量。
不应该期望用户能记住在下一步操作中需使用的一大串数字或标识符。
应该尽量减少记忆量。
(6)提高对话、移动和思考的效率。
应该尽量减少用户击键的次数,设计屏幕布局时应该考虑尽量减少鼠标移动的距离,应该尽量避免出现用户问“这是什么意思?
”的情况。
(7)允许犯错误。
系统应该能保护自己不受严重错误的破坏。
(8)按功能对动作分类,并据此设计屏幕布局。
下拉菜单的一个主要优点就是能按动作类型组织命令。
实际上,设计者应该尽力提高命令和动作组织的“内聚性”。
(9)提供对用户工作内容敏感的帮助设施(参见6.2.1节)。
(10)用简单动词或动词短语作为命令名。
过长的命令名难于识别和记忆,也会占用过多的菜单空间。
2.信息显示指南
如果人机界面显示的信息是不完整的、含糊的或难于理解的,则该应用系统显然不能满足用户的需求。
可以用多种不同方式“显示”信息:
用文字、图形和声音;
按位置、移动和大小;
使用颜色、分辨率和省略。
下面是关于信息显示的设计指南。
(1)只显示与当前工作内容有关的信息。
用户在获得有关系统的特定功能的信息时,不必看到与之无关的数据、菜单和图形。
(2)不要用数据淹没用户,应该用便于用户迅速吸取信息的方式来表示数据。
例如,可以用图形或图表来取代庞大的表格。
(3)使用一致的标记、标准的缩写和可预知的颜色。
显示的含义应该非常明确,用户无须参照其他信息源就能理解。
(4)允许用户保持可视化的语境。
如果对所显示的图形进行缩放,原始的图像应该一直显示着(以缩小的形式放在显示屏的一角),以使用户知道当前看到的图像部分在原图中所处的相对位置。
(5)产生有意义的出错信息(参见6.2.1节)。
(6)使用大小写、缩进和文本分组以帮助理解。
人机界面显示的信息大部分是文字
文字的布局和形式对用户从中提取信息的难易程度有很大影响。
(7)使用窗口分隔不同类型的信息。
利用窗口用户能够方便地“保存”多种不同类型的信息。
(8)使用“模拟”显示方式表示信息,以使信息更容易被用户提取。
例如,显示炼油厂储油罐的压力时,如果简单地用数字表示压力,则不易引起用户注意。
但是,如果用类似温度计的形式来表示压力,用垂直移动和颜色变化来指示危险的压力状况,就容易引起用户的警觉,因为这样做为用户提供了绝对和相对两方面的信息。
(9)高效率地使用显示屏。
当使用多窗口时,应该有足够的空间使得每个窗口至少都能显示出一部分。
此外,屏幕大小应该选得和应用系统的类型相配套(这实际上是一个系统工程问题)。
3.数据输入指南
用户的大部分时间用在选择命令、键入数据和向系统提供输入。
在许多应用系统中键盘仍然是主要的输入介质,但是,鼠标、数字化仪和语音识别系统正迅速地成为重要的输入手段。
下面是关于数据输入的设计指南。
(1)尽量减少用户的输入动作。
最重要的是减少击键次数,这可以用下列方法实现:
用鼠标从预定义的一组输入中选一个;
用“滑动标尺”在给定的值域中指定输入值;
利用宏把一次击键转变成更复杂的输入数据集合。
(2)保持信息显示和数据输入之间的一致性。
显示的视觉特征(例如,文字大小、颜色和位置)应该与输入域一致。
(3)允许用户自定义输入。
专家级的用户可能希望定义自己专用的命令或略去某些类型的警告信息和动作确认,人机界面应该为用户提供这样做的机制。
(4)交互应该是灵活的,并且可调整成用户最喜欢的输入方式。
用户类型与喜好的输入方式有关,例如,秘书可能非常喜欢键盘输入,而经理可能更喜欢使用鼠标之类的点击设备。
(5)使在当前动作语境中不适用的命令不起作用。
这可使得用户不去做那些肯定会导致错误的动作。
(6)让用户控制交互流。
用户应该能够跳过不必要的动作,改变所需做的动作的顺序(在应用环境允许的前提下),以及在不退出程序的情况下从错误状态中恢复正常。
(7)对所有输入动作都提供帮助(参见6.2.1节)。
(8)消除冗余的输入。
除非可能发生误解,否则不要要求用户指定输入数据的单位;
尽可能提供默认值;
绝对不要要求用户提供程序可以自动获得或计算出来的信息。
6.3过程设计的工具
描述程序处理过程的工具称为过程设计的工具,它们可以分为图形、表格和语言3类。
不论是哪类工具,对它们的基本要求都是能提供对设计的无歧义的描述,也就是应该能指明控制流程、处理功能、数据组织以及其他方面的实现细节,从而在编码阶段能把对设计的描述直接翻译成程序代码。
6.3.1程序流程图
程序流程图又称为程序框图,它是历史最悠久、使用最广泛的描述过程设计的方法,然而它也是用得最混乱的一种方法。
在6.1节中已经用程序流程图描绘了一些常用的控制结构,相信读者对程序流程图中使用的基本符号已经有了一些了解。
图6.3中列出了程序流程图中使用的各种符号。
(a)选择(分支);
(b)注释;
(c)预先定义的处理;
(d)多分支;
(e)开始或停止;
(f)准备;
(g)循环上界限;
(h)循环下界限;
(i)虚线;
(j)省略符;
(k)并行方式;
(l)处理;
(m)输入输出;
(n)连接;
(o)换页连接;
(p)控制流
从20世纪40年代末到70年代中期,程序流程图一直是软件设计的主要工具。
它的主要优点是对控制流程的描绘很直观,便于初学者掌握。
由于程序流程图历史悠久,为最广泛的人所熟悉,尽管它有种种缺点,许多人建议停止使用它,但至今仍在广泛使用着。
不过总的趋势是越来越多的人不再使用程序流程图了。
程序流程图的主要缺点如下:
(1)程序流程图本质上不是逐步求精的好工具,它诱使程序员过早地考虑程序的控制流程,而不去考虑程序的全局结构。
(2)程序流程图中用箭头代表控制流,因此程序员不受任何约束,可以完全不顾结构程序设计的精神,随意转移控制。
(3)程序流程图不易表示数据结构。
6.3.2盒图(N--S图)
出于要有一种不允许违背结构程序设计精神的图形工具的考虑,Nassi和Shneiderman提出了盒图,又称为N-S图。
它有下述特点:
(1)功能域(即,个特定控制结构的作用域)明确,可以从盒图上一眼就看出来。
(2)不可能任意转移控制。
(3)很容易确定局部和全程数据的作用域。
(4)很容易表现嵌套关系,也可以表示模块的层次结构。
图6.4给出了结构化控制结构的盒图表示,也给出了调用子程序的盒图表示方法:
条件
T
F
THEN
部分
ELSE
(b)
盒图没有箭头,因此不允许随意转移控制。
坚持使用盒图作为详细设计的工具,可以使程序员逐步养成用结构化的方式思考问题和解决问题的习惯。
6.3.3PAD图
PAD是问题分析图(problemanalysisdiagram)的英文缩写,自1973年由日本日立公司发明以后,已得到一定程度的推广。
它用二维树形结构的图来表示程序的控制流,将这种图翻译成程序代码比较容易。
图6.5给出PAD图的基本符号。
PAD图的主要优点如下:
(1)使用表示结构化控制结构的PAD符号所设计出来的程序必然是结构化程序。
(2)PAD图所描绘的程序结构十分清晰。
图中最左面的竖线是程序的主线,即第一层结构。
随着程序层次的增加,PAD图逐渐向右延伸,每增加一个层次,图形向右扩展一条竖线。
PAD图中竖线的总条数就是程序的层次数。
(3)用PAD图表现程序逻辑,易读、易懂、易记。
PAD图是二维树形结构的图形,程序从图中最左竖线上端的结点开始执行,自上而下,从左向右顺序执行,遍历所有结点。
(4)容易将PAD图转换成高级语言源程序,这种转换可用软件工具自动完成,从而可省去人工编码的工作,有利于提高软件可靠性和软件生产率。
(5)即可用于表示程序逻辑,也可用于描绘数据结构。
(6)PAD图的符号支持.自顶向下、逐步求精方法的使用。
开始时设计者可以定义一个抽象的程序,随着设计工作的深入而使用def符号逐步增加细节,直至完成详细设计,如图6.6所示。
PAD图是面向高级程序设计语言的,为FORTRAN,COBOL和PASCAL等每种常用的高级程序设计语言都提供了一整套相应的图形符号。
由于每种控制语句都有一个图形符号与之对应,显然将PAD图转换成与之对应的高级语言程序比较容易。
6.3.4判定表
当算法中包含多重嵌套的条件选择时,用程序流程图、盒图、PAD图或后面即将介绍的过程设计语言(PDL)都不易清楚地描述。
然而判定表却能够清晰地表示复杂的条件组合与应做的动作之间的对应关系。
一张判定表由4部分组成,左上部列出所有条件,左下部是所有可能做的动作,右上部是表示各种条件组合的一个矩阵,右下部是和每种条件组合相对应的动作。
判定表右半部的每一列实质上是一条规则,规定了与特定的条件组合相对应的动作。
下面以行李托运费的算法为例说明判定表的组织方法。
假设某航空公司规定,乘客可以免费托运重量不超过30kg的行李。
当行李重量超过30kg时,对头等舱的国内乘客超重部分每公斤收费4元,对其他舱的国内乘客超重部分每公斤收费6元,对外国乘客超重部分每公斤收费比国内乘客多一倍,对残疾乘客超重部分每公斤收费比正常乘客少一半。
用判定表可以清楚地表示与上述每种条件组合相对应的计算行李费的算法,如表6.1所示。
表6.1用判定表表示计算行李费的算法
1
2
3
4
5
6
7
8
9
国内乘客
头等舱
残疾乘客
行李重量W≤30kg
免费
╳
(W-30)×
12
在表的右上部分中“T”表示它左边那个条件成立,“F”表示条件不成立,空白表示这个条件成立与否并不影响对动作的选择。
判定表右下部分中画“X”表示做它左边的那项动作(在本例中就是用该公式计算行李费),空白表示不做这项动作。
从表6.1可以看出,只要行李重
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 软件工程导论 第6章 详细设计Finished 软件工程 导论 详细 设计 Finished