软件工程第六章详细设计资料.pptVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
详细设计的目标 确定怎样具体地实现所要求的系统 经过这个阶段的设计工作,应该得出对目标系统的精确描述,从而在编码阶段可以把这个描述直接翻译成用某种程序设计语言书写的程序。 详细设计的目标 在详细设计过程中,需要完成的工作是: (1)确定软件各个组成部分内的算法以及内部数据组织。 (2)选定某种过程的表达形式来描述各种算法。 可选用的过程表达形式有:流程图、盒图、PAD图、Jackson图等。 (3)编写详细设计说明书。 (4)制定单元测试计划。 (5)进行详细设计评审。 本章纲要 6.1 结构程序设计 6.2 人机界面设计 6.3 过程设计的工具 6.4 面向数据结构的设计方法 6.5 程序复杂度的定量度量 6.1 结构程序设计 结构程序设计的概念最早由E.W.Dijkstra提出。 1965年,他在一次会议上指出:“可以从高级语言中取消GOTO语句”,“程序的质量与程序中所包含的GOTO语句的数量成反比”。 1966年Bohm和Jacopini证明了,只用三种基本的控制结构就能实现任何单入口单出口的程序。 这三种基本的控制结构是“顺序”、“选择”和“循环”。 1972年IBM公司的Mills进一步提出,程序应该只有一个入口和一个出口,从而补充了结构程序设计的规则。 6.1 结构程序设计——三种基本的控制结构 (a)顺序结构 先执行A再执行B (b)IF_THEN_ELSE型选择(分支)结构 (c)DO_WHILE型循环结构 在循环控制条件成立时,重复执行特定的加工 6.1 结构程序设计——目的和定义 目的:使程序易于理解和阅读 经典定义:由3种基本控制结构连接且只有一个入口和出口的程序是结构化的。(无goto语句) 1971年,IBM率先成功运用结构程序设计技术。 针对goto语句的使用问题,修正对结构程序设计的定义:尽可能少用goto语句(最好仅在检测出错时才使用) 6.1 结构程序设计——定义 结构程序设计是一种设计程序的技术,它采用自顶向下逐步求精的设计方法和单入口单出口的控制结构 总体设计阶段采用自顶向下逐步求精的方法: 把一个复杂问题的解法分解和细化成一个由许多模块组成的层次结构的软件系统。 详细设计或编码阶段采用自顶向下逐步求精的方法: 可以把一个模块的功能逐步分解细化为一系列具体的处理步骤或某种高级语言的语句。 6.1 结构程序设计——优点 可以显著提高软件开发工程的成功率和生产率 。 程序有清晰的层次结构,因此容易阅读和理解。 开发时比较容易保证程序的正确性,即使出现错误也比较容易诊断和纠正。 源程序清晰流畅,易读易懂而且容易测试。 程序清晰和模块化使得在修改和重新设计一个软件时可以重用的代码量最大。 程序的逻辑结构清晰,有利于程序正确性证明。 6.1 结构程序设计——扩充的控制结构 6.1 结构程序设计——扩充的控制结构 6.2 人机界面设计 人机界面设计是接口设计的一个重要的组成部分。 人机界面的设计质量,直接影响用户对软件产品的评价,从而影响软件产品的竞争力和寿命。 因此,必须对人机界面设计给予足够重视。 6.2.1 设计问题 在设计人机界面的过程中,常遇到以下4个问题: 系统响应时间 用户帮助设施 出错信息处理 命令交互 许多设计者直到设计过程后期才开始考虑这些问题,这样做往往导致出现不必要的设计反复、项目延期和用户产生挫折感。最好在设计初期就把这些问题作为重要的设计问题来考虑,这时修改比较容易,代价也低。 6.2.1 设计问题——系统响应时间 定义:系统响应时间指从用户完成某个控制动作(例如,按回车键或点击鼠标),到软件给出预期的响应(输出信息或做动作)之间的这段时间。 两个重要属性:长度和易变性 长度:系统响应时间过长,用户就会感到紧张和沮丧; 系统响应时间过短,迫使用户加快操作节奏,从而可能会犯错误。 易变性:指系统响应时间相对于平均响应时间的偏差。即使系统响应时间较长,响应时间易变性低也有助于用户建立起稳定的工作节奏。 6.2.1 设计问题——用户帮助设施 常见的帮助设施可分为集成的和附加的两类 。 集成的帮助设施从一开始就设计在软件里面,通常,它对用户工作内容是敏感的,因此用户可以从与刚刚完成的操作有关的主题中选择一个请求帮助。显然,这可以缩短用户获得帮助的时间,增加界面的友好性。 如:office的帮助 附加的帮助设施是在系统建成后再添加到软件中的,在多数情况下它实际上是一种查询能力有限的联机用户手册。 如:MSDN 6.2.1 设计问题——用户帮助设施 具体设计帮助设施时,必须解决下述的一系列问题 在用户与系统交互期间,是否在任何时候都能获得关于系统任

文档评论(0)

三四五 + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档