计算机软件基础 (12)

下一页计算机软件基础Thesoftwarebasicofcomputer主讲：赵英良第16单元传统程序设计方法下一页上一页停止放映第2页本讲内容一、结构化开发方法二、软件需求定义三、系统设计（软件的设计）四、程序编码五、系统测试六、软件维护下一页上一页停止放映第3页教学目标了解传统程序设计方法:–基本概念–方法及特点–步骤及准则下一页上一页停止放映第4页本单元涉及内容第10章传统的软件开发方法–10.1结构化开发方法概述–10.2系统分析与定义–10.3系统设计–10.4系统编程–10.5系统测试–10.6系统维护P273~P333下一页上一页停止放映第5页一、结构化开发方法结构化开发方法是传统的软件系统开发方法。结构化开发方法的基本思想：把一个复杂问题的求解过程分阶段进行，每个阶段处理的问题都控制在人们容易理解和处理的范围内。基本要点是：–自顶向下–逐步求精–模块化设计–结构化编码–主程序员组织–结构化设计SD下一页上一页停止放映第6页“自顶向下”将复杂的大问题分解为小问题，找出问题的关键、重点所在，同时找出技术难点来。然后用精确的思维定性、定量地描述问题。问题的核心是”分解“。如何划分？准则是什么？实现的手段是”子程序“、”函数“，即模块化。要点：将大问题化为小问题，找出关键、难点，定量描述核心是：分解手段是：模块化（函数、子程序）下一页上一页停止放映第7页“逐步求精”将现实世界的问题经抽象转化为逻辑空间或求解空间的问题。复杂问题经抽象化处理变为相对较简单的问题。经几次抽象（精化）处理，最后到求解域中只是非常简单的编程问题。求解（抽象）过程可以划分为若干个阶段，在不同阶段用不同工具来描述。实现细则在前期阶段可以不去管它。在每个阶段有不同的规划和标准，产生出不同阶段的文档资料。将现实问题抽象为逻辑空间问题，几经抽象化为简单的编程问题。下一页上一页停止放映第8页模块化处理模块化就是把程序划分为若干个模块，而每个模块完成一个子功能，把这些模块汇总起来构成一个有机整体，即可完成指定的功能。模块化的目的是为了降低软件复杂度，使软件设计，调试和维护等操作变得简易。下一页上一页停止放映第9页结构化编码SP编码的方法强调清晰简洁，它是一种构造程序的技术，有利于提高软件生产率及降低软件维护代价。1966年Bohm和Jacopin就证明了只要用三中基本结构，就足以表示所有形式的程序控制结构。1978年Kernihan和Plauger对一些编码风格进行归纳，提出了16种具体方法。下一页上一页停止放映第10页结构化编码风格尽量使用标准库函数程序讲究清晰，避免过于精巧对重复使用的表达式尽量调用公共函数代替使用括号，以避免二义性用逻辑表达式代替分支嵌套使用缩排格式避免使用IFTHEN和空ELSE注意计算机运算特点，如10.0乘0.1很少等于1.0使用有意义的变量名对输入进行错误判别注释勿用太滥模块化功能专一,模块间偶合清晰递归定义的DS尽量采用递归过程访问把大程序分成小块去编写和测试勿追求不必要的效率,尽量采用基本控制结构避免循环多个出口下一页上一页停止放映第11页主程序员组织是一种人员的组织形式主程序员组织负责人,全权负责,包括解决技术难题,有时一些关键性技术问题,主程序员应亲自动手遍程去解决；他必须是技术高手，是程序生产过程中的总体设计师。程序员按任务书要求编程；是程序生产线上的“工人”。测试工程师具有较高遍程水准和经验，负责系统测试；是程序生产过程中的检验员。文档人员自始至终参加程序生产活动，负责编写一切有关文档资料。下一页上一页停止放映第12页结构化方法的体系结构结构化方法的体系结构是:–结构化分析（SA—StructuredAnalysis）–结构化设计（SD—StructuredDesign）–结构化程序设计（SP—StructuredProgramming）下一页上一页停止放映第13页结构化分析SASA方法是建立在自顶向下、逐步求精思想基础上的分析方法，SA方法是分析方法，基础是自顶向下、逐步求精要点：分解和抽象：–把复杂问题自顶向下逐层分解，再从分解出的对象中抽象出相对简单的子问题。–经过一系列分解和抽象，到最底层的问题已经是很容易求解的了。下一页上一页停止放映第14页结构化设计SDSD方法是由IBM公司的Constentine等人花了十几年时间研究出来的一种程序设计方法，发表于1974年。简述：SD是一种用于概要设计的方法，与SA方法配合使用。（SD是用于概要设计的方法）目标：建立一个结构良好的软件系统。SD方法的基础：是数据流程图，因此也称为面向数据流的设计方法。问题：SA方法用于软件开发的哪个阶段？下一页上一页停止放映第15页结构化程序设计SPSP的思想最早是由著名计算机科学家E.W.Dijkstra提出的。1966年Bohm和Jacopin证明了只用三种基本结构就能实现任何一个入口，一个出口的程序；1977年IBM公司的Mills又进一步提出：“程序应该只有一个入口和一个出口。在长期程序设计的实践中，SP方法不断得以完善，使之成为开发传统应用领域应用系统的主要方法之一。下一页上一页停止放映第16页关于SP的定义北大王选院士认为：–没有GOTO语句–一个入口、一个出口–自顶向下，逐步求精的分解–主程序员组谭浩强认为：–自顶向下–逐步求精–模块化设计–结构化编码下一页上一页停止放映第17页关于SP的定义（续）另一种说法：–自顶向下，逐步求精–程序结构按功能划分为模块–模块功能单一、简单–模块由三种基本结构组成–程序由函数、子程序来实现下一页上一页停止放映第18页二、软件需求定义概述：软件需求分析就是明确软件系统将来达到的目标。基本任务：准确地回答系统“做什么？”目标：规定项目必须满足的总目标；确定项目的可行性；拟定完成项目各个目标的策略，制定项目资源成本和进度。下一页上一页停止放映第19页1、软件需求定义的任务理解和表达用户要求，制定软件开发计划，编写要求说明书。下一页上一页停止放映第20页（1）软件需求定义的特点（1）它是软件生存周期中最容易出错的一个阶段，（2）也是软件工程中最困难的一个阶段。（3）它是其它阶段的基础，十分重要的阶段。困难在于：–不能准确地理解和清楚地描述–软件系统非常复杂，以致用户和软件人员都不能完整、精确地理解它或不能清楚地表达出来；软件人员和用户缺乏共同语言。–用户熟悉业务，但不了解计算机；而软件人员则相反；这种隔阂使双方不能进行交流。下一页上一页停止放映第21页（2）确定对系统的综合要求系统功能要求找出系统必须完成的所有功能。系统性能要求例如，联机系统的响应时间，系统需要的存储容量以及后援存储，重新启动和安全性等问题。运行要求（环境要求）对系统运行环境的要求。例如，什么样的硬件环境？采用哪种DBMS？OS平台是什么？需要什么样的外存储器和数据通信接口等。将来可能提出的要求为系统将来可能的扩充和修改预做准备。下一页上一页停止放映第22页（3）软件需求定义的工作流程系统定义用户要求软件功能范围功能说明书软件计划软件定义软件功能费用、资源进度下一页上一页停止放映第23页2、需求分析过程基本过程示意图沿数据流回溯用户复查细化数据流图修改开发计划书写文档资料审查和复审下一页上一页停止放映第24页需求分析的基本过程用户分析员程序员软件开发计划软件需求说明书分析追踪数据流图用户复查细化数据流图无补充修改需要分解不要分解有补充修改交换意见作出贡献下一页上一页停止放映第25页沿数据流回溯通常从数据流图的输出端着手分析，要搞清楚：–数据元素从哪儿来？–每个输出数据元素又是从哪儿来的？有时对用户具体的数据元素还搞不清楚，则需要和用户探讨、商量解决。通常把分析过程中得到的有关部门数据元素信息记录到数据字典DD中。把对算法的简明描述记录在IPO（输入|处理|输出图）图中。通过分析而补充的数据流、数据存储和处理，应该添加到DFD的适当位置上。数据字典（DD）、输入处理输出图（IPO）数据流图（DFD）下一页上一页停止放映第26页用户复查经分析将在数据流图回溯过程中找出的数据元素，并由此定义的DD和算法是否正确？这只能由最有发言权的用户来复查。在复查过程中反映出新的问题，应及时修改、补充DFD、DD和IPO图，并将对系统的新认识及时记录下来。实际上，追踪DFD和复查系统的逻辑模型这两个步骤是交替进行的循环过程。下一页上一页停止放映第27页细化数据流图在反复循环的分析过程中，不断细化DFD（即把数据流图扩展到更低的层次）。通过功能分解可以完成DFD的细化，即将一些处理比较复杂的功能再划分为若干个子功能。下一页上一页停止放映第28页修改开发计划在分析过程中可能会不断地修改原拟定的开发计划，这是正常的。下一页上一页停止放映第29页书写文档资料本阶段应完成4份文档资料：–系统规格说明描述目标系统的概貌、功能要求、性能、运行及将来可能提出的要求。–用户系统描述从用户角度描述系统，类似一份用户手册初稿。–数据要求包括DD、数据结构的层次框图等。–修改的开发计划包括成本估计、进度计划表、资源使用计划等。下一页上一页停止放映第30页说明需求说明书主要内容：–概述开发系统的意义、目的、背景及技术术语；–现行系统的概况业务流程、范围、存在的问题等；–需求说明•功能描述：•信息描述：DFD、DD、DS、IPO、接口等•性能描述–运行环境–系统限制用户系统描述–系统功能和性能的描述–使用系统的主要步骤和方法–系统用户的责任等下一页上一页停止放映第31页审查和复审分析阶段最后一步是按结束标准对该阶段的工作成果进行正式的技术审查和管理审查。下一页上一页停止放映第32页3、需求分析的原则1．能够表达和理解问题的信息域信息域反映的是用户业务系统中数据的流向和对数据进行加工的处理过程，因此信息域是解决“做什么？”的关键因素。2．要建立描述系统信息、功能和行为的模型建立模型的过程是“由粗到精”的分析综合的过程。3．能够对所建模型按一定形式进行分解分解是为了降低问题的复杂性，增加问题的可解性和可描述性。4．分清系统的逻辑视图和物理视图–软件需求的逻辑视图描述的是系统要达到的功能和要处理的信息之间的关系，这与实现细节无关；–而物理视图描述的是处理功能和信息结构的实际表现形式，这与实现细节是有关的–需求分析只研究软件系统“做什么？”，而不考虑“怎样做？”。下一页上一页停止放映第33页4、需求分析的图形工具图形工具在描述复杂关系时比文字叙述要优越。在系统需求分析过程中为了准确描述需求，常采用一些简单的描述工具，例如：数据流图（DFD，DataFlowDiagram）、数据字典（DD,DataDictionary）、结构化分析语言（LanguageofStructuredAnalysis）、判定表(DecisionTable)判定树等(DecisionTree)下一页上一页停止放映第34页（1）数据流图DFD数据流图（DFD——DataFlowDiagram）以图形的方式表达数据处理系统中信息的变换和传递过程。它有四种基本符号：SPX数据源及数据终点加工对数据进行的加工或变换，指向加工的数据流是输入数据；离开的是输出数据。数据流具有名字且有流向的数据文件存放数据的场所下一页上一页停止放映第35页数据流图举例——宾馆管理系统客人预订登录房管客人信息库可售房库售出房库客帐库公安预付款财务IDD下一页上一页停止放映第36页数据流图的结构一个实际问题的数据加工流程是非常复杂的。如果绘制在一个平面图上就显的太乱了。因此，通常采用分层次结构。把一个复杂的问题，分解为一些相互独立的子问题，再绘出分层DFD。数据流图的组成成分：数据流、加工、文件、源终点下一页上一页停止放映第37页结构图分层举例宾馆管理DFD/L0顶层图第2层图DFD/L1ADCE第3层图DFD/L2.2DFD/L2.1