软件工程课件(全)

单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,*,1,软件工程概述,2,软件的定义及可行性研究,3,需求分析,4,概要设计,5,详细设计,目 录,6,面向对象概念和,Rose,建模技术,7,面向对象的分析与设计,8,编码,9,软件测试,10,软件维护,11,软件项目管理,软件工程概述,第,1,章,教学,要求,1,了解软件的概念、特点及主要分类；,2,掌握软件危机的产生、表现及原因；,3,掌握软件工程的定义以及基本原理；,4,掌握软件生存周期概念；,5,理解软件开发模型；,6,了解软件开发工具与环境。,1.1,软件与软件危机,第,1,章,1,软件的定义,软件是计算机中与硬件相互依存的另一部分，软件包括程序、数据及其相关文档的完整集合。,1.1.1,软件的定义及其特点,软件,程序,数据,文档,程序是按事先设计的功能和性能要求执行的指令序列,数据是使程序能够正确地处理信息的数据结构,文档是与程序开发、维护和使用有关的图文资料,2.,软件具有下列特点：,1.1,软件与软件危机,第,1,章,1.1.1,软件的定义及其特点,软件,是逻辑产品,生产与硬件不同,不会磨损和老化,依赖硬件,手工开发为主,成本高、风险高,比硬件发展慢,1.,软件技术的发展,1.1,软件与软件危机,第,1,章,1.1.2,软件的发展及其分类,程序设计,程序系统,软件工程,2.,软件的分类,1.1,软件与软件危机,第,1,章,1.1.2,软件的发展及其分类,重点掌握,1.,软件危机的主要表现,1.1,软件与软件危机,第,1,章,1.1.3,软件危机,（,1,）软件不能满足用户的,需求,。,（,2,）软件开发,成本,严重超标，开发,周期,大大超过规定日期。,（,3,）软件,质量,难于保证，可靠性差。,（,4,）软件难于,维护,。,（,5,）软件开发,速度,跟不上计算机发展速度。,2.,软件危机产生的原因,1.1,软件与软件危机,第,1,章,1.1.3,软件危机,（,1,）忽视软件开发,前期的调研和需求分析,工作。,（,2,）缺乏软件开发的,经验,和有关软件开发数据的积累，使得开发计划很难制定。,（,3,）开发过程缺乏统一的、规范化的,方法论,指导。,（,4,）忽视与用户、开发组成员间的及时有效的,沟通,。,（,5,）,文档,资料不规范或不准确。导致开发者失去工作的基础，管理者失去管理的依据。,（,6,）没有完善的,质量保证体系,。,3.,软件危机解决途径,1.1,软件与软件危机,第,1,章,1.1.3,软件危机,要解决软件危机问题，需要采取以下措施：,（,1,）使用好的软件开发,技术和方法,。,（,2,）使用好的,软件开发工具,，提高软件生产率。,（,3,）有良好的组织、严密的,管理,，各方面人员相互配合共同完成任务。,为了解决软件危机，既要有技术措施（好的方法和工具），也要有组织管理措施。软件工程正是从,技术和管理,两方面来研究如何更好地开发和维护计算机软件的。,为了克服软件危机，,1968,年,10,月,在北大西洋公约组织（,NATO,）召开的计算机科学会议上，,Fritz Bauer,首次提出“软件工程”的概念。,按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一条主要出路。,软件工程的,主要思想,是强调软件开发过程中应用工程化原则的重要性。软件工程的,目标,是实现软件的优质高产。软件工程的,目的,是在经费的预算范围内，按期交付出用户满意的、质量合格的软件产品。,1.2,软件工程,第,1,章,1.2.1,软件工程的定义和目标,著名软件工程专家,Boehm,提出。,（,1,）用,分阶段,的软件生存周期计划进行严格的质量管理。,（,2,）坚持进行,阶段评审,。,（,3,）实行严格的,产品控制,。,（,4,）采用,现代程序设计技术,。,（,5,）软件工程,结果,应能清楚地,审查,。,（,6,）开发小组的人员应该,少而精,。,（,7,）承认,不断改进软件工程实践,的必要性。,1.2,软件工程,第,1,章,1.2.2,软件工程的基本原理,1.2,软件工程,第,1,章,1.2.3,软件工程的研究内容,1.3,软件生存周期,第,1,章,可行性研究,问题定义,需求分析,详细设计,总体设计,编码,系统测试,确认测试,集成测试,单元测试,运行与维护,计划时期,开发时期,运行时期,时间,1.4,软件开发模型,第,1,章,1.4.1,瀑布模型,问题定义,可行性研究,需求分析,软件设计,编码,软件测试,运行维护,开发时期,运行时期,计划,时期,1.4,软件开发模型,第,1,章,1.4.1,瀑布模型,瀑布模型的主要,优点,：,（,1,）原理简单、容易掌握。,（,2,）各阶段间都有验证和确认环节，以便进行质量管理。,（,3,）主要用于支持结构化方法。,瀑布模型的主要,缺点,：,（,1,）缺乏灵活性，,不能适应用户需求的变化,。,（,2,）缺乏演化性，,返回,上一级的开发需要付出十分高昂的,代价,。,（,3,）是线性的软件开发模型，,回溯性很差,。,1.4,软件开发模型,第,1,章,1.4.2,快速原型模型,1.4,软件开发模型,第,1,章,1.4.2,快速原型模型,快速原型模型的优点：,（,1,）增强了开发者与用户间的,交流,，有助于满足用户的真实需求。,（,2,）用户可,及早得到,有用的,产品,，可及早发现问题，随时纠正错误。,（,3,）减小技术、应用风险，可降低开发费用，缩短开发时间。,快速原型模型的缺点：,（,1,）缺乏丰富而强有力的,软件工具和开发环境,。,（,2,）对设计人员水平及开发环境,要求较高,。,（,3,）在多次重复改变原型的过程中，,程序员会厌倦,。,（,4,）对于做到彻底测试，更新文档较为困难。,1.4,软件开发模型,第,1,章,1.4.3,渐增模型,1.4,软件开发模型,第,1,章,1.4.3,渐增模型,渐增模型的,优点,：,渐增模型是瀑布模型的一个变体，可以看作是重复执行的多个瀑布模型，具有瀑布模型的所有优点，此外，还有以下优点：,（,1,）,可分批次提交软件产品,，方便用户及时了解软件开发进展情况，及早发现问题。,（,2,）,以组件为单位进行开发,，降低了软件开发风险。,（,3,）开发顺序灵活。优先级最高的服务首先交付。,渐增模型的,缺点,：,（,1,）由于对整个软件系统的需求没有一个完整的定义，,会给总体设计带来麻烦,。,（,2,）在把每个新的增量构件集成到现有软件结构中时，,必须不破坏原来已开发出的产品,。,（,3,）软件的体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。每次增量开发的产品都应当是,可测试的、可扩充的,。,1.4,软件开发模型,第,1,章,1.4.4,喷泉模型,1.4,软件开发模型,第,1,章,1.4.4,喷泉模型,喷泉模型的主要特点：,（,1,）各阶段相互重叠，反映了软件过程的并行性。,（,2,）以分析为基础，资源消耗呈塔形，在分析阶段消耗资源最多。,（,3,）反映了软件过程迭代的自然特性，从高层返回低层无资源消耗。,（,4,）强调增量开发，依据分析一点、设计一点的原则，不要求一个阶段的彻底完成，整个过程是一个迭代的逐步提炼的过程。,（,5,）是对象驱动的过程，对象是所有活动作用的主体，也是项目管理的基本内容。,1.4,软件开发模型,第,1,章,1.4.5,螺旋模型,1.4,软件开发模型,第,1,章,1.4.5,螺旋模型,1.5,软件开发方法,第,1,章,1,结构化方法,结构化方法又称传统方法、生存周期法、面向过程的方法、面向功能的方法、面向数据流的方法。,所谓,结构化分析,，就是根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析。,所谓,结构化设计,，就是根据模块独立性准则、软件结构准则，将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的总体设计。,所谓,结构化程序设计,，就是根据结构程序设计原理，将每个模块的功能用相应的标准控制结构表示出来，从而实现详细设计。,1.5,软件开发方法,第,1,章,2,面向数据结构方法,面向数据结构方法（也称为,Jackson,方法）。该方法从目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其他细节，就可得到完整的程序结构图。这一方法以数据结构为驱动，其优点是通俗易懂，特别适合信息系统中数据层（数据库服务器）上的设计与实现，对输入、输出数据结构明确的中小型系统特别有效。其缺点是实现窗口界面较困难。该方法也可与其他方法结合，用于模块的详细设计。,1.5,软件开发方法,第,1,章,3,面向对象方法,面向对象方法是一种自底向上和自顶向下相结合的方法，该方法把对象作为数据和在数据上的操作（服务）相结合的软件构件。,用对象分解取代结构化方法的功能分解,。把所有对象都划分成类，把若干个相关的类组织成具有层次结构的系统，下层的类继承上层的类所定义的属性和服务。对象之间通过发送消息进行联系。,使用面向对象方法开发软件时，,可以重复使用对象和类等构件,，从而降低了软件开发成本，所开发的软件,能适应需求变化，稳定性好，可重用性好，可维护性好，,对于大型、复杂及交互性比较强的系统，使用面向对象方法更有优势。,1.6,软件工具与开发环境,第,1,章,1.6.1,软件工具,软件工具是指用来,辅助计算机软件开发、维护和管理的软件,。按照软件过程活动可将软件工具分为支持软件开发过程的工具、支持软件维护过程的工具、支持软件管理过程与支持过程的工具等。,支持软件开发过程的工具,包括需求分析工具、设计工具、编码与排错工具和测试工具等；,支持软件维护过程的工具,包括版本控制工具、文档分析工具、开发信息库工具、逆向工程工具和再工程工具等；,支持软件管理与软件支持的工具,包括项目管理工具、配置管理工具和软件评价工具等。,1.6,软件工具与开发环境,第,1,章,1.6.2,软件开发环境,1,计算机辅助软件工程,计算机辅助软件工程,（,Computer Aided Software Engineering,，,CASE,）将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。,2,集成化,CASE,环境,集成化开发环境,（,Integrated- CASE,，,I -CASE,）是一种把支持多种软件开发方法和过程模型的软件工具集成到一起的软件开发环境。,3,软件工程环境,软件工程环境,（,Software Engineering Environment,，,SEE,）是指以软件工程为依据，支持典型软件生产的系统。包括三层含义，一组软件工具的集合；工具按一定方法或模型组织；工具支持整个生存周期各阶段或部分阶段。,软件的定义及可行性研究,第,2,章,本章,要点,理解问题定义的内容与方法；,学会书写问题定义报告；,理解可行性研究的任务与步骤；,学会书写可行性研究报告；,学会绘制系统流程图。,2.1,问题定义,第,2,章,（,1,）问题的背景，弄清楚待开发系统现在处于什么状态，为什么要开发它，是否具备开发条件等问题。,（,2,）提出开发系统的问题要求以及总体要求。,（,3,）明确问题的性质、类型和范围。,（,4,）明确待开发系统要实现的目标、功能和规模。,（,5,）提出开发的条件要求和环境要求。,以上主要内容应写在问题定义报告（或系统目标和范围说明书）中，作为这一阶段的“工作总结”。,2.1,问题定义,第,2,章,2.1.1,问题定义的内容,具体步骤如下,:,首先，系统分析员要针对用户的要求做详细的调查研究，认真听取用户对问题的介绍；阅读与问题有关的资料，必要时还要深入现场，亲自操作；调查开发系统的背景；了解用户对开发的要求。,其次是与用户反复讨论，以使问题进一步确定化。经过用户和系统分析员双方充分协商，确定问题定义的内容。,最后写出双方均认可的问题定义报告。,2.1,问题定义,第,2,章,2.1.2,问题定义的方法,可行性研究是在问题定义之后进行的，它是软件定义时期的第二个阶段。可行性研究是指在项目进行开发之前，根据项目发起文件（或称项目建议书）和实际情况，对该项目是否能在特定的资源、时间等制约条件下完成做出评估，并且确定该项目是否值得去开发。可行性研究的目的不在于如何解决问题，而在于确定问题“是否能够解决”和“是否值得解决”。其中的项目发起文件（或称项目建议书），是项目发起时，由发起人或单位递交给项目支持者或领导的书面材料，其作用是让项目支持者或领导明白项目的必要性和可行性。,2.2,可行性研究,第,2,章,2.2,可行性研究,第,2,章,1.,技术可行性,技术可行性从技术的角度去研究系统实现的可行性。主要包括风险、资源和技术分析。风险分析主要考虑在给定的约束条件下设计和实现系统的风险；资源分析是考虑技术资源的可行性，也就是参与人员的技术基础、基础硬件与软件的可用性和软件工具的实用性；技术分析是考虑技术解决方案的实用性，即所使用技术的实用化程度和技术解决方案的合理程度。,2.,经济可行性,经济可行性从经济角度评价开发一个新系统是否可行。主要任务是对软件开发项目进行成本估算、效益估算和成本,/,效益分析，分析实现这个系统有没有经济效益和社会效益。,2.2.1,可行性研究的任务,2.2,可行性研究,第,2,章,3.,运行可行性（或用户使用可行性）,即判断为新系统规定的运行方式是否可行。首先要分析用户类型（如外行型、熟练型或专家型），然后从操作习惯、使用单位的计算机使用情况和相关规章制度等方面进行分析，判断当系统交付使用后，使用单位是否有能力保证系统的正常运行和使用。,4.,法律可行性,研究新系统的开发在社会上和政治上会不会引起侵权和责任问题，如是否违反专利法、著作权法和软件保护条例等法律，是否涉及信息安全和个人隐私等问题。,2.2.1,可行性研究的任务,2.2,可行性研究,第,2,章,1.,审核系统的规模和目标,2.,分析研究现行系统,3.,设计新系统的高层逻辑模型,4.,获得并比较可行的方案,5.,撰写可行性研究报告,2.2.2,可行性研究的步骤,2.2,可行性研究,第,2,章,2.2.3,系统流程图,2.2,可行性研究,第,2,章,在可行性研究过程中，经济可行性研究占有重要地位，它从经济上衡量一个项目是否有开发价值。,经济可行性研究主要包括两个方面的内容：一是新系统成本的估计；二是新系统可能产生的效益。又称为成本,/,效益分析。,2.2.4,经济可行性,2.3,可行性研究报告的内容及作用,第,2,章,可行性研究报告编制中应注意以下几个方面的问题：,（,1,）坚持实事求是的原则，不要随意夸大新系统的功能和其他指标。,（,2,）任何一项内容的书写均要以科学分析的结果为依据，不能凭空想象。,（,3,）对每一项内容的描述必须反复推敲，一定要做到用词恰当、准确。,（,4,）从具体情况出发。可行性研究报告不一定面面俱到，但对于用户关心的部分或项目中重要的部分要重点阐明。,（,5,）书写形式要规范。,2.3.1,可行性研究报告编制中应注意的问题,2.3,可行性研究报告的内容及作用,第,2,章,可行性研究报告在软件开发中起着重要的作用：,（,1,）可行性研究报告是可行性研究阶段的成果。,（,2,）可行性研究报告提出了软件开发的总体目标和范围，因此它是软件开发的行动指南。,（,3,）可行性研究报告是需求分析的基础和依据。,2.3.2,可行性研究报告在软件开发中的作用,2.4,项目开发计划,第,2,章,经过可行性研究后，如果一个项目是值得开发的，则接下来应制定项目开发计划。软件项目开发计划是软件工程中的一种管理性文档，主要是对所开发的软件项目的费用、时间进度、人员组织、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划，是项目管理人员对项目进行管理的依据，据此对项目的费用、进度和资源进行控制和管理。,项目开发计划的目的是提供一个框架，使得主管人员在项目开始后较短时间内就可以对资源、成本、进度进行合理的估计，而不必等到详细的需求分析完成之后。,项目开发计划有分析和估算两项任务。分析是对系统内各软件功能界限的划定，估算是指根据已有的定性数据和以往的经验对系统开发的资源、费用和进度进行定量的估计。项目复杂性越高、规模越大，估算的难度就越大，当项目的结构化程度越高且估算人员的经验越丰富时，则估算就更为准确。,需求分析,第,3,章,本章,要点,理解需求分析的任务；,熟悉需求分析的步骤；,理解结构化需求分析的基本思想；,掌握数据流图和数据词典的用法。,3.1,需求分析的任务,第,3,章,需求分析的任务是要准确地定义新系统的目标，准确回答“系统必须做什么”的问题，并用需求规格说明书规范的形式准确地表达用户的需求。,需求分析是理解、分析和表达“系统必须做什么”的过程。,虽然在可行性研究阶段，对用户需求有了初步了解，但对需求的了解是概括的、粗略的，许多细节被忽略了。可行性研究是决定“做还是不做”，而不是对需求进行定义。而需求分析阶段则需要充分理解用户需求，通过分析得出对新系统完整、准确、清晰、具体的要求。,需求分析的结果是否正确，关系到软件开发的成败和软件产品的质量，正确的需求分析是整个系统开发的基础。,3.2,需求获取的方法,第,3,章,在需求分析过程中，需求获取阶段是开发人员和用户交往最多的阶段。一般情况下，用户并不熟悉计算机的相关知识，更不懂得需求分析方法，所以他们不知道如何全面而又准确无误地表达自己的需求。而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会给需求分析带来很大困难。所以，开发人员与用户之间要进行充分和有效的沟通，需要采取科学的需求获取方法与技巧，恰当地启发引导用户表达自己的需求，以减少后期重复修改需求的次数。,3.2,需求获取的方法,第,3,章,1,深入浅出,需求获取要尽可能全面、细致。调研获取的需求是个全集，而目标系统真正实现的是个子集。分析时的调研内容并不一定都要纳入到新系统中，但全面、细致的调研既有利于弄清系统全局，又有利于以后的扩充。,2,以流程为主线,在与用户交流的过程中，应该用流程将所有的内容串起来，如单据、信息、组织结构和处理规则等，这样便于交流沟通。流程的描述既要有宏观描述，也要有微观描述。,3.2.1,需求获取的基本原则,3.2,需求获取的方法,第,3,章,1.,问卷调查,2.,访谈和会议,3.,市场调查,4.,实地操作,5.,建立原型,3.2.2,需求获取的途径和方法,3.2,需求获取的方法,第,3,章,要获取用户需求，就需要深入企业现场调研，需求调研的步骤如下：,（,1,）调研用户领域的组织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。,（,2,）调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表和账本等原始资料，分析物流、资金流和信息流三者的关系，以及如何用数据流来表示这三者的关系。,（,3,）对调研的内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层和决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。,（,4,）对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。,（,5,）若需求基线符合要求，则需求分析完毕；反之返回到前面某一步。如此循环多次，直到需求分析使双方满意为止。,3.2.3,需求调研的步骤,3.3,需求获取的步骤,第,3,章,3.3,需求获取的步骤,第,3,章,此阶段的工作是需求获取、问题识别，即收集并明确用户需求的过程。,首先，系统分析员要研究可行性研究报告和软件项目实施计划。主要是从系统的角度来理解软件，确定对目标系统的综合要求，即软件的需求。还要提出这些需求实现的条件，以及需求应达到的标准。也就是解决待开发系统需要“做什么”，“做到什么程度”的问题。这些需求包括：（,1,）功能需求：（,2,）性能需求：（,3,）环境需求：（,4,）可靠性需求：（,5,）安全保密性需求：（,6,）用户界面需求：（,7,）资源使用需求：（,8,）软件成本消耗与开发进度需求：（,9,）预计系统可达到的目标：,3.3.1,需求获取,3.3,需求获取的步骤,第,3,章,获取到需求后，要把来自用户的信息加以分析，通过“抽象”建立待开发的系统逻辑模型。模型是为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。为待开发系统建立模型，有助于人们更好地理解问题，常用的建模方法有数据流图、实体联系图（,E-R,图）、状态转换图、用例图、类图、对象图等。,系统分析员根据目标系统的模型，从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和对设计的限制，剔除需求中不合理的成分，增加需要的部分，最终把各项需求组织起来，提交目标系统的详细逻辑模型。,3.3.2,分析建模,3.3,需求获取的步骤,第,3,章,需求描述就是指编制需求分析阶段的文档。即将已经过分析的需求清晰、全面、系统、准确地描述成正式的文档,软件需求规格说明书。,软件需求规格说明书以开发人员的角度，对开发系统的业务模型、功能模型、数据模型等内容进行描述，明确地表达了用户与系统分析员对软件系统的共同理解，将作为概要设计和详细设计的基线。,对于复杂的软件系统，此阶段除产生软件需求规格说明书（称软件需求文档，主要描述软件部分的需求）外，还要产生系统定义文档（即用户需求报告）和系统需求文档（即系统需求规格说明书）。,3.3.3,需求描述,3.3,需求获取的步骤,第,3,章,需求验证就是验证（复查）需求分析的成果，也称综合评审。需求验证就是对需求的正确性进行严格的验证，确保需求的一致性、完整性、清晰性、现实性和有效性，确保设计与实现过程中的需求可回溯性，并进行需求变更管理。,一般情况下，需求验证以用户、系统分析员、系统设计人员和管理人员共同参与的会议形式进行，最后由评审负责人签字。,3.3.4,需求验证,3.4,结构化需求分析方法,第,3,章,1.,分析策略,结构化分析（,Structured Analysis,，简称,SA,）方法是,20,世纪,70,年代由,EYourdon,等人提出的一种面向数据流的分析方法，适用于大型的数据处理系统。由于利用图形来表达需求会使文档清晰、简明、易于学习和掌握，所以软件分析人员仍在广泛使用这种传统的分析方法。,结构化分析方法总的指导思想是“自顶向下，逐步求精”，它的两个基本原则是“抽象”和“分解”，即按照功能分解的原则，对系统进行逐层分解，直到找到所有满足功能要求的可实现软件元素为止。,3.4.1,结构化分析方法概述,3.4,结构化需求分析方法,第,3,章,3.4.1,结构化分析方法概述,3.4,结构化需求分析方法,第,3,章,2.,描述工具,结构化分析方法利用图形等半形式化的描述表达需求，用它们形成需求规格说明书的主要部分，主要工具有：,（,1,）数据流图（,DFD,）。描述系统的分解，即描述系统由哪几部分组成，各部分之间有什么联系等。,（,2,）数据词典（,DD,）。明确定义数据流图中的数据和加工。它是数据流条目、数据存储条目、数据项条目和基本加工条目的汇集。,（,3,）结构化语言、判定表和判定树。用于详细描述数据流图中不能再分解的每一个基本加工的处理逻辑。,3.4.1,结构化分析方法概述,3.4,结构化需求分析方法,第,3,章,3.,分析步骤,3.4.1,结构化分析方法概述,3.4,结构化需求分析方法,第,3,章,1.,数据流图的基本符号,3.4.2,数据流图,3.4,结构化需求分析方法,第,3,章,2.,数据流图的绘制步骤,（,1,）画顶层数据流图,列出系统的全部数据源点和终点，将系统加工处理过程作为一个整体，就可能得到顶层图。具体说就是：画一个圆，在其中写上系统名称，然后在圆的外围画上系统的输入和输出，这一步工作实际上是决定研究的内容和系统的范围。,（,2,）画各层数据流图,对系统处理过程自顶向下，逐步分解，画出各层的数据流图。,（,3,）画总的数据流图,这一步对了解整个系统很有好处，但也要根据实际情况来决定总图的布局，不要把数据流图画得太复杂。,3.4.2,数据流图,3.4,结构化需求分析方法,第,3,章,3.,数据流图中的命名规则,（,1,）数据流,数据流表明数据和数据流向，它通常由一组数据项组成。,（,2,）加工,加工是对数据的某种操作或变换。,（,3,）文件,文件起暂时保存数据的作用。,（,4,）数据源点和终点,数据源点和终点是数据的始发点和终止点，是软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称外部实体。,3.4.2,数据流图,3.4,结构化需求分析方法,第,3,章,4.,数据流图中分层技术,对于比较复杂的实际问题，在数据流图上常常出现十几个乃至几十个、上百个加工，这样的数据流图复杂而且难以理解。为了避免这种情况出现，可以采用数据流图的分层技术。分层技术的基本思想是，不是在一个数据流图中一次引入太多的细节，而是有控制地逐步增加细节，实现从抽象到具体的逐步过渡。,3.4.2,数据流图,3.4,结构化需求分析方法,第,3,章,1.,数据词典的内容,一般说来，数据词典的每个条目中应包括以下信息。,（,1,）名字：数据流、数据项、数据存储或外部实体的名称。,（,2,）别名或编号：第（,1,）项中对象的其他名字。,（,3,）分类：数据流、数据项、加工、数据存储、外部实体等。,（,4,）内容描述：描述内容或数据结构等。,（,5,）何处使用：哪些加工使用该条目。,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,2.,数据词典中使用的符号,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,3.,数据词典书写实例,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,3.,数据词典书写实例,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,3.,数据词典书写实例,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,4.,数据词典的实现,通常，实现数据词典有三种途径：,(1),人工方法：人工方法实现时，每一词典条目（即每一个数据定义或每一个加工逻辑说明）写在一张卡片上，由专人管理和维护。为了便于搜索，所有卡片按数据名称排序。人工方法的优点是容易实现。,(2),自动方法：把词典存在计算机中，用计算机对它搜索和维护。现有多种“词典管理程序”，如,PLS/PSA,。用计算机管理词典质量高，搜索、维护方便。,(3),人工和自动混合的方法：在人工过程中可借助正文编写程序、报告生成程序等工具辅助完成。,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,4.,数据词典的实现,不论通过哪种途径实现的数据词典都应尽量做到以下几点：,(1),没有冗余：主要指数据定义不能重复。在规格说明书的其他组成部分中已出现的信息不能重复。,(2),查阅方便：通过名字可以方便地查阅数据词典中的每个定义。,(3),定义的书写方法简单、方便、严谨，而且可读性强。,(4),建议采用卡片形式书写。,3.4.3,数据词典,3.4,结构化需求分析方法,第,3,章,1.,结构化语言,3.4.4,加工逻辑的描述,3.4,结构化需求分析方法,第,3,章,2.,判定表,在一些数据处理中，数据流图的加工需要经过多个逻辑条件组合的取值而确定，此时用自然语言或结构化语言难以描述，而运用判定表描述就比较清晰明了。,3.4.4,加工逻辑的描述,3.4,结构化需求分析方法,第,3,章,3.,判定树,判定树也是用来表达加工逻辑的工具，它是判定表的变形，有时比判定表更直观，更易于理解和使用。图书优惠政策的判定树如图,3-8,所示。,3.4.4,加工逻辑的描述,3.5,需求规格说明书的编写与评审,第,3,章,1,需求规格说明书的编写内容,需求分析阶段应交付的主要文档是软件需求规格说明书。它提供了用户与开发人员对开发软件的共同理解，其作用相当于用户与开发单位之间的技术合同，是后续设计和编码的基础，是测试和验收的依据。,软件需求规格说明书的内容框架可参阅,GB/T 8567-2006,计算机软件文档编制规范,。,在编写需求规格说明书时应注意以下几个问题：,（,1,）说明书中的每一部分都非常重要，因此要慎重对待。,（,2,）问题的描述要做到准确无误，没有二义性。,（,3,）说明书的书写形式要规范。,（,4,）允许用户根据项目的具体情况适当的将书写内容进行调整和筛选。,3.5,需求规格说明书的编写与评审,第,3,章,2,需求分析的评审,在需求分析规格说明书编写完成后，必须进行需求评审，以验证需求的正确性。,如果在评审过程中发现说明书存在错误或缺陷，应及时进行更改或弥补，重新进行相应部分的需求分析、需求建模、修改需求规格说明书，并再行评审。,需求分析评审的主要内容如下：,（,1,）一致性。所有需求必须是一致的，任何一条需求不能和其他需求相矛盾。,（,2,）完整性。需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。,（,3,）现实性。指定的需求应该是用现有的软硬件技术基本上可以实现的。对硬件技术的进步可以预测，对软件技术的进步则很难预测，只能从现有技术水平判断需求的现实性。,（,4,）有效性。必须证明需求是正确而有效的，确实能解决用户所面对的问题。,3.6,项目实践：,“,图书管理系统,”,软件需求分析,第,3,章,下面以第,2,章的“图书管理系统”为例，说明面向数据流的结构化分析方法及软件需求说明书的编写内容。,在图书馆负责人和计算机系的技术人员通过了“图书管理系统”,项目开发计划,后，项目组随即进入了项目开发阶段，计算机系教师与图书馆相关业务人员紧密合作，经过,15,天的工作，形成了“图书管理系统”,软件需求说明书,。主要数据流图如下：,3.6,项目实践：,“,高校图书管理系统,”,软件需求分析,第,3,章,3.6,项目实践：,“,高校图书管理系统,”,软件需求分析,第,3,章,3.6,项目实践：,“,高校图书管理系统,”,软件需求分析,第,3,章,3.6,项目实践：,“,高校图书管理系统,”,软件需求分析,第,3,章,3.6,项目实践：,“,高校图书管理系统,”,软件需求分析,第,3,章,3.6,项目实践：,“,高校图书管理系统,”,软件需求分析,第,3,章,概要设计,第,4,章,本章,要点,掌握软件设计的概念与原则；,理解软件设计的任务；,掌握概要设计的内容与步骤；,掌握结构化设计方法；,了解概要设计说明书的内容。,4.1,软件设计概述,第,4,章,软件设计是软件工程的重要阶段，是一个将软件需求转换为软件表示的过程。软件设计的基本目标是用比较抽象概括的方式确定目标系统如何完成预定的任务，即确定系统的物理模型，解决软件系统“怎么做”的问题。,软件设计不同于程序设计，程序设计是软件设计的编码实现过程。软件设计的重要性有以下几点：,（,1,）软件开发阶段（设计、编码、测试）占据软件项目开发总成本绝大部分，是在软件开发中形成质量的关键环节。,（,2,）软件设计是开发阶段最重要的步骤，是将用户需求准确地转化为最终的软件产品的唯一途径。,（,3,）软件设计作出的决策，最终将直接影响软件实现的成败。,（,4,）软件设计是软件工程和软件维护的基础。,4.1.1,软件设计的概念与重要性,4.1,软件设计概述,第,4,章,从工程管理的角度来看，可以将软件设计分为两个阶段：概要设计（又称总体设计）阶段和详细设计（又称过程设计）阶段。概要设计阶段得到软件系统的基本框架，详细设计阶段明确系统内部的实现细节。,4.1.2,软件设计的任务,4.2,概要设计的任务与步骤,第,4,章,概要设计的基本任务是：,（,1,）设计软件系统结构；,（,2,）数据结构及数据库设计；,（,3,）编写概要设计文档；,（,4,）评审概要设计文档。,4.2.1,概要设计的任务,4.2,概要设计的任务与步骤,第,4,章,概要设计的一般步骤如下：,1.,选定体系结构,2.,确定设计方案,3.,设计软件结构,4.,数据结构及数据库设计,5.,制订测试计划,6.,编写概要设计文档,7.,概要设计文档评审,4.2.2,概要设计的步骤,4.3,概要设计的原则,第,4,章,1.,模块化,模块化是“分而治之”策略的具体表现。模块化就是将整体软件划分成独立命名且可独立访问的模块，不同的模块通常具有不同,的功能或职责。每个模块可独立地开发、,测试，最后组装成完整的软件。在结构,化方法中，函数、过程和子程序等都可,作为模块；在面向对象方法中，对象、,对象内的方法也是模块。模块是构成软,件的基本构件。,4.3,概要设计的原则,第,4,章,2.,抽象与分解,抽象是指忽视一个主题中与当前目标无关的方面，以便更充分地注意与当前目标有关的方面。抽象可以分成若干级别，级别越高，细节越少。其实整个软件的开发过程就是一个从抽象到具体的过程：需求分析时，使用问题域语言来概括性地描述解决方案，抽象级别最高；软件设计时，同时使用面向问题域和面向实现的两种术语描述解决方案，抽象级别次之；在编码时，使用直接实现的方式（源程序代码）来描述解决方案，抽象级别最低。在软件设计中，过程抽象和数据抽象是两种常用的抽象手段。,4.3,概要设计的原则,第,4,章,3.,信息隐蔽和局部化,信息隐蔽是指模块所包含的信息，不允许其他不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。信息隐蔽的目的是提高模块的独立性，减少修改或维护时的影响面。,局部化就是把关系密切的软件元素物理地放得彼此靠近。其优点是可维护性、可靠性和可理解性好。,4.,模块独立性,模块独立性概括了把软件划分为模块时要遵守的准则，也是判断模块构造是否合理的标准。模块独立性好的软件接口简单、容易开发，独立的模块也容易测试和维护。因此，模块独立性是软件质量的关键。,4.3,概要设计的原则,第,4,章,5.,复用性设计,复用是指同一事物不做修改或稍加修改就可以多次重复使用。将复用思想用于软件开发称为软件复用，将软件的重用部分称为软构件。也就是说，在构造软件系统时不必从零做起，可通过直接使用或加以修改已有软构件来组装成新系统。,软件复用可提高软件的生产率。由于软构件是经过反复使用验证的，自身具有较高的质量，因此由软构件组成的新系统也具有较高的质量。软件复用并不局限于软件代码，其范围也可扩展到软件开发各个阶段，包括需求模型和规格说明、设计模型、文档、测试用例等。,4.4,模块的独立性,第,4,章,模块独立性是指软件系统中每个模块只涉及软件要求的具体的子功能，而与软件系统中其他模块的接口是简单的。模块独立性取决于模块的内部和外部特征。一般用耦合和内聚两个定性的指标来度量。,耦合是模块之间相互依赖的紧密程度的度量，内聚是一个模块内部各个元素之间彼此结合的紧密程度的度量。一个模块内部各个元素之间的联系越紧密，则模块的内聚度就越高，相对地，它与其他模块之间的耦合就越低，模块的独立性就越强。一个优秀的软件设计，应尽量做到高内聚、低耦合，从而提高模块的独立性。,4.4,模块的独立性,第,4,章,耦合是模块之间相互连接的紧密程度的度量。耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。模块之间的连接越紧密，联系越多，耦合性就越高，而其模块独立性就越弱。通常希望一个软件系统具有较低的耦合性。,4.4.1,耦合性（,Coupling,）,4.4,模块的独立性,第,4,章,1.,非直接耦合,两个模块间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。耦合度最弱，模块独立性最强。,2.,数据耦合,调用模块和被调用模块之间只传递简单的数据,项参数。相当于高级语言中的值传递。,4.4.1,耦合性（,Coupling,）,4.4,模块的独立性,第,4,章,3.,标记耦合,调用模块和被调用模块之间传递数据结构而不是简单数据。也称特征耦合。,标记耦合的模块间传递的不是简单变量，而是像高级语言中的数组名、记录名和文件名等数据结构，这些名字即为标记，其实传递的是地址。,4.4.1,耦合性（,Coupling,）,4.4,模块的独立性,第,4,章,4.,控制耦合,模块之间传递的不是数据信息，而是控制信息如标志、开关量，一个模块控制了另一模块的功能。,4.4.1,耦合性（,Coupling,）,4.4,模块的独立性,第,4,章,5.,外部耦合,一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合。,6.,公共耦合,若一组模块都访问同一全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。,如果模块只是向公共数据环境输入数据，或是只从公共数据环境取出数据，这属于比较松散的公共耦合；如果模块既向公共数据环境输入数据又从公共数据环境取出数据，这属于较紧密的公共耦合。,4.4.1,耦合性（,Coupling,）,4.4,模块的独立性,第,4,章,7.,内容耦合,一个模块直接访问另一模块的内容，则称这两个模块为内容耦合。,若在程序中出现下列情况之一，则说明两个模块之间发生了内容耦合：,（,1,）一个模块直接访问另一个模块的内部数据,;,（,2,）一个模块不通过正常入口而直接转入到另一个模块的内部,;,（,3,）两个模块有一部分代码重叠（该部分代码具有一定的独立功能）,;,（,4,）一个模块有多个入口。,4.4.1,耦合性（,Coupling,）,4.4,模块的独立性,第,4,章,一个模块内各个元素彼此结合的紧密程度用内聚（或称聚合）来度量。一个理想的模块只完成一个功能，模块设计的目标之一是尽可能高内聚。,4.4.2,内聚性（,Cohesion,）,4.4,模块的独立性,第,4,章,1.,偶然内聚,一个模块内的各处理元素之间没有任何联系，只是偶然地被凑到一起。这种模块也称巧合内聚，内聚程度最低。,4.4.2,内聚性（,Cohesion,）,4.4,模块的独立性,第,4,章,2.,逻辑内聚,指模块内执行几个逻辑上相关的功能，通过参数确定该模块完成哪一个功能。,4.4.2,内聚性（,Cohesion,）,4.4,模块的独立性,第,4,章,3.,时间内聚,把需要同时或顺序执行的动作组合在一起形成的模块。,时间内聚模块中的功能元素只因时间因素关联在一起，各元素之间没有共用数据，而且一般情况下各部分可以以任意次序执行。,4.,过程内聚,如果一个模块内的处理元素是相关的，而且必须以特定次序执行则称为过程内聚。,4.4.2,内聚性（,Cohesion,）,4.4,模块的独立性,第,4,章,5.,通信内聚,指模块内所有处理功能都通过公用数据而发生关系。即模块内各个组成部分都使用相同的输入数据或产生相同的输出结果。,4.4.2,内聚性（,Cohesion,）,4.4,模块的独立性,第,4,章,6.,顺序内聚,指一个模块中各个处理元素和同一个功能密切相关，而且这些处理必须顺序执行，通常前一个处理元素的输出是后一个处理元素的输入。,顺序内聚的内聚度比较高，但缺点是不如功能内聚易于维护。,7.,功能内聚,指模块内所有元素的各个组成部分全部都为完成同一个功能而存在，共同完成一个单一的功能，模块已不可再分。即模块仅包括为完成某个功能所必须的所有成分，这些成分紧密联系、缺一不可。,4.4.2,内聚性（,Cohesion,）,4.4,模块的独立性,第,4,章,1.,模块功能的完善化,2.,消除重复功能，改善软件结构,3.,模块规模应该适中,4.,模块的深度、宽度、扇出和扇入都应适当,5.,模块的作用范围应该在控制范围之内,6.,力争降低模块接口的复杂程度,7.,设计单入口、单出口的模块,8.,模块功能应该可以预测,4.4.2,软件结构优化准则,4.5,软件结构设计的图形工具,第,4,章,层次图（,Hierarchy,）也称,H,图，用于表示软件的层次结构，特别适合于在自顶向下设计时使用。,4.5.1,层次图,4.5,软件结构设计的图形工具,第,4,章,IPO,图是输入,/,处理,/,输出图（,Input Process Output,），其基本形式是三个方框，左边方框列出所有的输入数据，中间框列出主要的处理，右边框列出输出数据。,4.5.2 IPO,图,4.5,软件结构设计的图形工具,第,4,章,模块结构图（,Structure Chart,，,SC,图）用于表示软件系统的层次分解关系、模块调用关系、模块之间数据流和控制信息流的传递关系，是描述软件系统物理模型、进行概要设计的主要工具，也是软件文档的一部分。,4.5.3,结构图,4.6,结构化的设计方法,第,4,章,结构化设计方法是面向数据流的设计方法，它以数据流图为基础，定义了将数据流图映射为软件结构图（即,DFDSC,）的方法，而数据流的类型决定了映射的方法。数据流分为变换流和事务流两种，因此由数据流组成的数据流图也分为变换型数据流图和事务型数据流图两种类型。由变换型数据流图向结构图的映射称变换分析，由事务型数据流图向结构图的映射称事务分析。,4.6,结构化的设计方法,第,4,章,1,数据流图的类型,（,1,）变换流,变换型数据流的特征是可以把它看成由输入、变换中心和输出三部分组成，这样的数据流图称为变换型数据流图。如图,4-20,所示。,4.6,结构化的设计方法,第,4,章,（,2,）事务流,事务型数据流的特征是可以把它看成具有在多种事务中选择执行某类事务的能力。这样的数据流图称为事务型数据流图。,4.6,结构化的设计方法,第,4,章,2.,结构化设计过程,面向数据流的结构化方法的设计,过程如图,4-22,所示。,4.6,结构化的设计方法,第,4,章,（,1,）精化,DFD,。,（,2,）确定,DFD,类型。,（,3,）把,DFD,映射到系统模块结构，设计模块结构的上层。,（,4,）基于,DFD,逐步分解高层模块，设计出下层模块。,（,5,）根据模块独立性原理，精化模块结构。,（,6,）描述模块接口。,4.6,结构化的设计方法,第,4,章,两种映射方法都是先映射出初始软件结构图。,4.6,结构化的设计方法,第,4,章,3.,变换分析,变换分析是一系列设计步骤的总称，通过执行这些步骤，将具有变换流特点的数据流图按预先确定的模式映射成软件结构。采用变换分析方法开发出的软件结构图，其一般方式为：“输入,处理,输出”。,变换分析方法的设计步骤如下：,第一步复查基本系统模型。以确定输入数据和输出数据是否与实际相符。,第二步复查并精化数据流图。完成对需求分析阶段得出的数据流图的复查和精化。,第三步判断数据流图具有变换特性还是事务特性。根据数据流图中占优势的属性是事务的还是变换的，来确定数据流的全局属性。,第四步确定输入流和输出流的边界，从而将变换中心划分出来。,第五步完成“第一级分解”。分配控制的过程，划分顶层模块和从属模块。,第六步完成“第二级分解”。就是把数据流图中的每个处理映射成软件结构中一个适当的模块。,第七步采用启发式设计规则和设计度量对得到的软件结构进行精化。,4.6,结构化的设计方法,第,4,章,4.,事务分析,事务分析的设计步骤和变换分析的设计步骤基本类似，主要差别在于数据流图到软件结构的映射方法不同。在事务分析的设计中，由数据流图映射到软件结构时，从事务中心边界开始，把接收通路映射成一个模块，在发送通路设立一个控制模块，用以控制由不同发送通路映射成的分支模块。,4.7,概要设计文档与评审,第,4,章,软件设计规格说明书是软件设计阶段要完成的文档，作为设计任务的最终成果。概要设计、详细设计、数据设计规格说明书可根据项目的大小分别编写或合并为一份设计规格说明书。我国国家标准,GB/T 8567|2006,计算机软件文档编制规范,都给出了设计说明书的内容框架，可以选择使用。本章,4.8,节给出的“高校图书管理系统”,软件概要设计说明书,可供读者参考。,4.7.1,概要设计说明书的编写内容,4.7,概要设计文档与评审,第,4,章,设计评审就是对设计文档的评审。目的是为了尽早发现软件的欠缺并尽早纠正，因此评审对于项目的成功是绝对必要的。,（,1,）评审的指导原则,概要设计评审和详细设计评审应分开进行，不可合并为一次评审；,概要设计评审应邀请用户代表和有关领域专家到会，详细设计评审则不需要；,评审是为了提前揭露错误，参加评审的设计人员应该欢迎别人提出批评和建议，不要掩盖设计的缺陷。评审的对象是设计文档而不是设计者；,评审中提出的问题应详细记录，但不谋求当场解决；,评审结束前应做出本次评审能否通过的结论。,4.7.2,概要设计评审,4.7,概要设计文档与评审,第,4,章,（,2,）评审的主要内容,概要设计评审应该把重点放在系统的总体结构、模块划分、内外接口等方面。如软件结构能否满足需求；结构形态是否合理；层次是否清晰；模块划分是否符合优化原则；人机界面、内外部接口和出错处理是否合理等。,详细设计评审的重点应该放在各个模块的具体设计上。如模块的设计能否满足其功能和性能要求；算法和数据结构是否合理；设计描述是否简单、清晰等。,4.7.2,概要设计评审,4.7,概要设计文档与评审,第,4,章,（,3,）评审的方式,评审分为正式和非正式两种方式。,非正式评审参加人数少，且均为软件人员，带有同行讨论性质，不拘泥于时间和形式，适宜详细设计评审。,正式评审除软件开发人员外，还应邀请用户代表和有关领域专家参加。通常采用答辩方式，与会者提前审阅文档资料，设计人员使用幻灯片等方式对设计方案详细说明之后，回答与会者的问题并记录各种重要的评审意见。正式评审是概要设计评审的常用方式。,4.7.2,概要设计评审,4.8,项目实践：,“,图书管理系统,”,概要设计,第,4,章,4.8,项目实践：,“,图书管理系统,”,概要设计,第,4,章,功能模块与相应数据表之间的关系表,程序实现的功能模块,涉及的主要数据表,审核读者,读者信息表,检查借书数量,读者信息表、读者类型表,检查图书,图书信息表,办理借书,读者信息表、图书信息表、借阅信息表、借还日志表,办理续借,读者信息表、图书信息表、借阅信息表、借还日志表,办理还书,读者信息表、图书信息表、借阅信息表、罚款信息表、系统参数表、借还日志表,办理预借,读者信息表、图书信息表、预借详情表、借还日志表,详细设计,第,5,章,本章,要点,理解详细设计的任务与原则；,掌握详细设计的表达工具；,学会书写软件详细设计文档。,5.1,详细设计的任务与原则,第,5,章,详细设计（又称为过程设计或模块设计），是编码的前导。其主要任务是确定每一个模块所使用的算法、块内数据结构和接口细节，用描述工具表达算法的过程，即对模块的具体实现过程进行详细地描述。具体任务如下：,（,1,）算法设计,（,2,）数据结构设计,（,3,）模块接口细节,（,4,）测试用例设计,（,5,）数据库物理设计,（,6,）数据代码设计,（,7,）其他设计,（,8,）编写详细设计说明书并进行评审。,5.1.1,详细设计的任务,5.1,详细设计的任务与原则,第,5,章,进行详细设计时应遵循以下原则