软件工程ppt课件全.ppt

《软件工程ppt课件全.ppt》由会员分享，可在线阅读，更多相关《软件工程ppt课件全.ppt（336页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、1目录页1软件工程概述2软件的定义及可行性研究3需求分析4概要设计5详细设计目 录6面向对象概念和Rose建模技术7面向对象的分析与设计8编码9软件测试10软件维护11软件项目管理2目录页软件工程概述第1章教学要求n1了解软件的概念、特点及主要分类；n2掌握软件危机的产生、表现及原因；n3掌握软件工程的定义以及基本原理；n4掌握软件生存周期概念；n5理解软件开发模型；n6了解软件开发工具与环境。3目录页1.1软件与软件危机第1章1软件的定义软件是计算机中与硬件相互依存的另一部分，软件包括程序、数据及其相关文档的完整集合。1.1.1 软件的定义及其特点软件 程序 数据文档程序是按事先设计的功能和

2、性能要求执行的指令序列数据是使程序能够正确地处理信息的数据结构文档是与程序开发、维护和使用有关的图文资料4目录页2.软件具有下列特点：1.1软件与软件危机第1章1.1.1 软件的定义及其特点软件是逻辑产品生产与硬件不同不会磨损和老化依赖硬件手工开发为主成本高、风险高比硬件发展慢5目录页1.软件技术的发展1.1软件与软件危机第1章1.1.2 软件的发展及其分类 程序设计 程序系统 软件工程6目录页2.软件的分类1.1软件与软件危机第1章1.1.2 软件的发展及其分类 重点掌握7目录页1.软件危机的主要表现1.1软件与软件危机第1章1.1.3 软件危机（1）软件不能满足用户的需求。（2）软件开发成

3、本严重超标，开发周期大大超过规定日期。（3）软件质量难于保证，可靠性差。（4）软件难于维护。（5）软件开发速度跟不上计算机发展速度。8目录页2.软件危机产生的原因1.1软件与软件危机第1章1.1.3 软件危机（1）忽视软件开发前期的调研和需求分析工作。（2）缺乏软件开发的经验和有关软件开发数据的积累，使得开发计划很难制定。（3）开发过程缺乏统一的、规范化的方法论指导。（4）忽视与用户、开发组成员间的及时有效的沟通。（5）文档资料不规范或不准确。导致开发者失去工作的基础，管理者失去管理的依据。（6）没有完善的质量保证体系。9目录页3.软件危机解决途径1.1软件与软件危机第1章1.1.3 软件危机

4、 要解决软件危机问题，需要采取以下措施：（1）使用好的软件开发技术和方法。（2）使用好的软件开发工具，提高软件生产率。（3）有良好的组织、严密的管理，各方面人员相互配合共同完成任务。为了解决软件危机，既要有技术措施（好的方法和工具），也要有组织管理措施。软件工程正是从技术和管理两方面来研究如何更好地开发和维护计算机软件的。10目录页 为了克服软件危机，1968年10月在北大西洋公约组织（NATO）召开的计算机科学会议上，Fritz Bauer首次提出“软件工程”的概念。按工程化的原则和方法组织软件开发工作是有效的，是摆脱软件危机的一条主要出路。软件工程的主要思想是强调软件开发过程中应用工程化原

5、则的重要性。软件工程的目标是实现软件的优质高产。软件工程的目的是在经费的预算范围内，按期交付出用户满意的、质量合格的软件产品。1.2软件工程第1章1.2.1 软件工程的定义和目标11目录页 著名软件工程专家Boehm提出。（1）用分阶段的软件生存周期计划进行严格的质量管理。（2）坚持进行阶段评审。（3）实行严格的产品控制。（4）采用现代程序设计技术。（5）软件工程结果应能清楚地审查。（6）开发小组的人员应该少而精。（7）承认不断改进软件工程实践的必要性。1.2软件工程第1章1.2.2 软件工程的基本原理12目录页1.2软件工程第1章1.2.3 软件工程的研究内容13目录页1.3软件生存周期第1

6、章可行性研究问题定义需求分析 详细设计总体设计编码 系统测试确认测试集成测试单元测试运行与维护计划时期 开发时期 运行时期时间14目录页1.4软件开发模型第1章1.4.1 瀑布模型问题定义可行性研究需求分析软件设计编码软件测试运行维护开发时期运行时期计划时期15目录页1.4软件开发模型第1章1.4.1 瀑布模型瀑布模型的主要优点：（1）原理简单、容易掌握。（2）各阶段间都有验证和确认环节，以便进行质量管理。（3）主要用于支持结构化方法。瀑布模型的主要缺点：（1）缺乏灵活性，不能适应用户需求的变化。（2）缺乏演化性，返回上一级的开发需要付出十分高昂的代价。（3）是线性的软件开发模型，回溯性很差。

7、16目录页1.4软件开发模型第1章1.4.2 快速原型模型17目录页1.4软件开发模型第1章1.4.2 快速原型模型快速原型模型的优点：（1）增强了开发者与用户间的交流，有助于满足用户的真实需求。（2）用户可及早得到有用的产品，可及早发现问题，随时纠正错误。（3）减小技术、应用风险，可降低开发费用，缩短开发时间。快速原型模型的缺点：（1）缺乏丰富而强有力的软件工具和开发环境。（2）对设计人员水平及开发环境要求较高。（3）在多次重复改变原型的过程中，程序员会厌倦。（4）对于做到彻底测试，更新文档较为困难。18目录页1.4软件开发模型第1章1.4.3 渐增模型19目录页1.4软件开发模型第1章1.

8、4.3 渐增模型渐增模型的优点：渐增模型是瀑布模型的一个变体，可以看作是重复执行的多个瀑布模型，具有瀑布模型的所有优点，此外，还有以下优点：（1）可分批次提交软件产品，方便用户及时了解软件开发进展情况，及早发现问题。（2）以组件为单位进行开发，降低了软件开发风险。（3）开发顺序灵活。优先级最高的服务首先交付。渐增模型的缺点：（1）由于对整个软件系统的需求没有一个完整的定义，会给总体设计带来麻烦。（2）在把每个新的增量构件集成到现有软件结构中时，必须不破坏原来已开发出的产品。（3）软件的体系结构必须是开放的，即向现有产品中加入新构件的过程必须简单、方便。每次增量开发的产品都应当是可测试的、可扩充

9、的。20目录页1.4软件开发模型第1章1.4.4 喷泉模型21目录页1.4软件开发模型第1章1.4.4 喷泉模型喷泉模型的主要特点：（1）各阶段相互重叠，反映了软件过程的并行性。（2）以分析为基础，资源消耗呈塔形，在分析阶段消耗资源最多。（3）反映了软件过程迭代的自然特性，从高层返回低层无资源消耗。（4）强调增量开发，依据分析一点、设计一点的原则，不要求一个阶段的彻底完成，整个过程是一个迭代的逐步提炼的过程。（5）是对象驱动的过程，对象是所有活动作用的主体，也是项目管理的基本内容。22目录页1.4软件开发模型第1章1.4.5 螺旋模型23目录页1.4软件开发模型第1章1.4.5 螺旋模型24目

10、录页1.5软件开发方法第1章1结构化方法结构化方法又称传统方法、生存周期法、面向过程的方法、面向功能的方法、面向数据流的方法。所谓结构化分析，就是根据分解与抽象的原则，按照系统中数据处理的流程，用数据流图来建立系统的功能模型，从而完成需求分析。所谓结构化设计，就是根据模块独立性准则、软件结构准则，将数据流图转换为软件的体系结构，用软件结构图来建立系统的物理模型，实现系统的总体设计。所谓结构化程序设计，就是根据结构程序设计原理，将每个模块的功能用相应的标准控制结构表示出来，从而实现详细设计。25目录页1.5软件开发方法第1章2面向数据结构方法面向数据结构方法（也称为Jackson方法）。该方法从

11、目标系统的输入、输出数据结构入手，导出程序框架结构，再补充其他细节，就可得到完整的程序结构图。这一方法以数据结构为驱动，其优点是通俗易懂，特别适合信息系统中数据层（数据库服务器）上的设计与实现，对输入、输出数据结构明确的中小型系统特别有效。其缺点是实现窗口界面较困难。该方法也可与其他方法结合，用于模块的详细设计。26目录页1.5软件开发方法第1章3面向对象方法面向对象方法是一种自底向上和自顶向下相结合的方法，该方法把对象作为数据和在数据上的操作（服务）相结合的软件构件。用对象分解取代结构化方法的功能分解。把所有对象都划分成类，把若干个相关的类组织成具有层次结构的系统，下层的类继承上层的类所定义

12、的属性和服务。对象之间通过发送消息进行联系。使用面向对象方法开发软件时，可以重复使用对象和类等构件，从而降低了软件开发成本，所开发的软件能适应需求变化，稳定性好，可重用性好，可维护性好，对于大型、复杂及交互性比较强的系统，使用面向对象方法更有优势。27目录页1.6软件工具与开发环境第1章1.6.1 软件工具软件工具是指用来辅助计算机软件开发、维护和管理的软件。按照软件过程活动可将软件工具分为支持软件开发过程的工具、支持软件维护过程的工具、支持软件管理过程与支持过程的工具等。支持软件开发过程的工具包括需求分析工具、设计工具、编码与排错工具和测试工具等；支持软件维护过程的工具包括版本控制工具、文档

13、分析工具、开发信息库工具、逆向工程工具和再工程工具等；支持软件管理与软件支持的工具包括项目管理工具、配置管理工具和软件评价工具等。28目录页1.6软件工具与开发环境第1章1.6.2 软件开发环境1计算机辅助软件工程 计算机辅助软件工程（Computer Aided Software Engineering，CASE）将各种软件工具、开发机器和一个存放开发过程信息的工程数据库组合起来形成一个软件工程环境。2集成化CASE环境集成化开发环境（Integrated-CASE，I-CASE）是一种把支持多种软件开发方法和过程模型的软件工具集成到一起的软件开发环境。3软件工程环境软件工程环境（Softw

14、are Engineering Environment，SEE）是指以软件工程为依据，支持典型软件生产的系统。包括三层含义，一组软件工具的集合；工具按一定方法或模型组织；工具支持整个生存周期各阶段或部分阶段。29目录页软件的定义及可行性研究第2章本章要点n理解问题定义的内容与方法；n学会书写问题定义报告；n理解可行性研究的任务与步骤；n学会书写可行性研究报告；n学会绘制系统流程图。30目录页2.1问题定义第2章31目录页（1）问题的背景，弄清楚待开发系统现在处于什么状态，为什么要开发它，是否具备开发条件等问题。（2）提出开发系统的问题要求以及总体要求。（3）明确问题的性质、类型和范围。（4）明

15、确待开发系统要实现的目标、功能和规模。（5）提出开发的条件要求和环境要求。以上主要内容应写在问题定义报告（或系统目标和范围说明书）中，作为这一阶段的“工作总结”。2.1问题定义第2章2.1.1 问题定义的内容32目录页具体步骤如下:首先，系统分析员要针对用户的要求做详细的调查研究，认真听取用户对问题的介绍；阅读与问题有关的资料，必要时还要深入现场，亲自操作；调查开发系统的背景；了解用户对开发的要求。其次是与用户反复讨论，以使问题进一步确定化。经过用户和系统分析员双方充分协商，确定问题定义的内容。最后写出双方均认可的问题定义报告。2.1问题定义第2章2.1.2 问题定义的方法 33目录页可行性研

16、究是在问题定义之后进行的，它是软件定义时期的第二个阶段。可行性研究是指在项目进行开发之前，根据项目发起文件（或称项目建议书）和实际情况，对该项目是否能在特定的资源、时间等制约条件下完成做出评估，并且确定该项目是否值得去开发。可行性研究的目的不在于如何解决问题，而在于确定问题“是否能够解决”和“是否值得解决”。其中的项目发起文件（或称项目建议书），是项目发起时，由发起人或单位递交给项目支持者或领导的书面材料，其作用是让项目支持者或领导明白项目的必要性和可行性。2.2 可行性研究 第2章34目录页2.2 可行性研究 第2章1.技术可行性技术可行性从技术的角度去研究系统实现的可行性。主要包括风险、资

17、源和技术分析。风险分析主要考虑在给定的约束条件下设计和实现系统的风险；资源分析是考虑技术资源的可行性，也就是参与人员的技术基础、基础硬件与软件的可用性和软件工具的实用性；技术分析是考虑技术解决方案的实用性，即所使用技术的实用化程度和技术解决方案的合理程度。2.经济可行性经济可行性从经济角度评价开发一个新系统是否可行。主要任务是对软件开发项目进行成本估算、效益估算和成本/效益分析，分析实现这个系统有没有经济效益和社会效益。2.2.1 可行性研究的任务 35目录页2.2 可行性研究 第2章3.运行可行性（或用户使用可行性）即判断为新系统规定的运行方式是否可行。首先要分析用户类型（如外行型、熟练型或

18、专家型），然后从操作习惯、使用单位的计算机使用情况和相关规章制度等方面进行分析，判断当系统交付使用后，使用单位是否有能力保证系统的正常运行和使用。4.法律可行性研究新系统的开发在社会上和政治上会不会引起侵权和责任问题，如是否违反专利法、著作权法和软件保护条例等法律，是否涉及信息安全和个人隐私等问题。2.2.1 可行性研究的任务 36目录页2.2 可行性研究 第2章1.审核系统的规模和目标2.分析研究现行系统3.设计新系统的高层逻辑模型4.获得并比较可行的方案5.撰写可行性研究报告2.2.2 可行性研究的步骤 37目录页2.2 可行性研究 第2章2.2.3 系统流程图 38目录页2.2 可行性研

19、究 第2章在可行性研究过程中，经济可行性研究占有重要地位，它从经济上衡量一个项目是否有开发价值。经济可行性研究主要包括两个方面的内容：一是新系统成本的估计；二是新系统可能产生的效益。又称为成本/效益分析。2.2.4 经济可行性 39目录页2.3 可行性研究报告的内容及作用 第2章可行性研究报告编制中应注意以下几个方面的问题：（1）坚持实事求是的原则，不要随意夸大新系统的功能和其他指标。（2）任何一项内容的书写均要以科学分析的结果为依据，不能凭空想象。（3）对每一项内容的描述必须反复推敲，一定要做到用词恰当、准确。（4）从具体情况出发。可行性研究报告不一定面面俱到，但对于用户关心的部分或项目中重

20、要的部分要重点阐明。（5）书写形式要规范。2.3.1 可行性研究报告编制中应注意的问题 40目录页2.3 可行性研究报告的内容及作用 第2章可行性研究报告在软件开发中起着重要的作用：（1）可行性研究报告是可行性研究阶段的成果。（2）可行性研究报告提出了软件开发的总体目标和范围，因此它是软件开发的行动指南。（3）可行性研究报告是需求分析的基础和依据。2.3.2 可行性研究报告在软件开发中的作用 41目录页2.4 项目开发计划第2章经过可行性研究后，如果一个项目是值得开发的，则接下来应制定项目开发计划。软件项目开发计划是软件工程中的一种管理性文档，主要是对所开发的软件项目的费用、时间进度、人员组织

21、、硬件设备的配置、软件开发环境和运行环境的配置等进行说明和规划，是项目管理人员对项目进行管理的依据，据此对项目的费用、进度和资源进行控制和管理。项目开发计划的目的是提供一个框架，使得主管人员在项目开始后较短时间内就可以对资源、成本、进度进行合理的估计，而不必等到详细的需求分析完成之后。项目开发计划有分析和估算两项任务。分析是对系统内各软件功能界限的划定，估算是指根据已有的定性数据和以往的经验对系统开发的资源、费用和进度进行定量的估计。项目复杂性越高、规模越大，估算的难度就越大，当项目的结构化程度越高且估算人员的经验越丰富时，则估算就更为准确。42目录页需求分析第3章本章要点n理解需求分析的任务

22、；n熟悉需求分析的步骤；n理解结构化需求分析的基本思想；n掌握数据流图和数据词典的用法。43目录页3.1需求分析的任务第3章需求分析的任务是要准确地定义新系统的目标，准确回答“系统必须做什么”的问题，并用需求规格说明书规范的形式准确地表达用户的需求。需求分析是理解、分析和表达“系统必须做什么”的过程。虽然在可行性研究阶段，对用户需求有了初步了解，但对需求的了解是概括的、粗略的，许多细节被忽略了。可行性研究是决定“做还是不做”，而不是对需求进行定义。而需求分析阶段则需要充分理解用户需求，通过分析得出对新系统完整、准确、清晰、具体的要求。需求分析的结果是否正确，关系到软件开发的成败和软件产品的质量

23、，正确的需求分析是整个系统开发的基础。44目录页3.2需求获取的方法第3章在需求分析过程中，需求获取阶段是开发人员和用户交往最多的阶段。一般情况下，用户并不熟悉计算机的相关知识，更不懂得需求分析方法，所以他们不知道如何全面而又准确无误地表达自己的需求。而软件开发人员对相关的业务领域也不甚了解，用户与开发人员之间对同一问题理解的差异和习惯用语的不同往往会给需求分析带来很大困难。所以，开发人员与用户之间要进行充分和有效的沟通，需要采取科学的需求获取方法与技巧，恰当地启发引导用户表达自己的需求，以减少后期重复修改需求的次数。45目录页3.2需求获取的方法第3章1深入浅出需求获取要尽可能全面、细致。调

24、研获取的需求是个全集，而目标系统真正实现的是个子集。分析时的调研内容并不一定都要纳入到新系统中，但全面、细致的调研既有利于弄清系统全局，又有利于以后的扩充。2以流程为主线在与用户交流的过程中，应该用流程将所有的内容串起来，如单据、信息、组织结构和处理规则等，这样便于交流沟通。流程的描述既要有宏观描述，也要有微观描述。3.2.1 需求获取的基本原则 46目录页3.2需求获取的方法第3章1.问卷调查2.访谈和会议3.市场调查4.实地操作5.建立原型3.2.2 需求获取的途径和方法 47目录页3.2需求获取的方法第3章要获取用户需求，就需要深入企业现场调研，需求调研的步骤如下：（1）调研用户领域的组

25、织结构、岗位设置和职责定义，从功能上区分有多少个子系统，划分系统的大致范围，明确系统的目标。（2）调研每个子系统所需的工作流程、功能与处理规则，收集单据、报表和账本等原始资料，分析物流、资金流和信息流三者的关系，以及如何用数据流来表示这三者的关系。（3）对调研的内容事先准备，针对不同管理层次的用户询问不同的问题，列出问题清单。将操作层、管理层和决策层的需求既联系又区分开来，形成一个金字塔，使下层满足上层的需求。（4）对与用户沟通的情况及时总结归纳，整理调研结果，找出新的疑点，初步构成需求基线。（5）若需求基线符合要求，则需求分析完毕；反之返回到前面某一步。如此循环多次，直到需求分析使双方满意为

26、止。3.2.3 需求调研的步骤 48目录页3.3需求获取的步骤第3章49目录页3.3需求获取的步骤第3章此阶段的工作是需求获取、问题识别，即收集并明确用户需求的过程。首先，系统分析员要研究可行性研究报告和软件项目实施计划。主要是从系统的角度来理解软件，确定对目标系统的综合要求，即软件的需求。还要提出这些需求实现的条件，以及需求应达到的标准。也就是解决待开发系统需要“做什么”，“做到什么程度”的问题。这些需求包括：（1）功能需求：（2）性能需求：（3）环境需求：（4）可靠性需求：（5）安全保密性需求：（6）用户界面需求：（7）资源使用需求：（8）软件成本消耗与开发进度需求：（9）预计系统可达到的

27、目标：3.3.1 需求获取 50目录页3.3需求获取的步骤第3章获取到需求后，要把来自用户的信息加以分析，通过“抽象”建立待开发的系统逻辑模型。模型是为了理解事物而对事物做出的一种抽象，通常由一组符号和组织这些符号的规则组成。为待开发系统建立模型，有助于人们更好地理解问题，常用的建模方法有数据流图、实体联系图（E-R图）、状态转换图、用例图、类图、对象图等。系统分析员根据目标系统的模型，从信息流和信息结构出发，逐步细化所有的软件功能，找出系统各元素之间的联系、接口特性和对设计的限制，剔除需求中不合理的成分，增加需要的部分，最终把各项需求组织起来，提交目标系统的详细逻辑模型。3.3.2 分析建模

28、 51目录页3.3需求获取的步骤第3章需求描述就是指编制需求分析阶段的文档。即将已经过分析的需求清晰、全面、系统、准确地描述成正式的文档软件需求规格说明书。软件需求规格说明书以开发人员的角度，对开发系统的业务模型、功能模型、数据模型等内容进行描述，明确地表达了用户与系统分析员对软件系统的共同理解，将作为概要设计和详细设计的基线。对于复杂的软件系统，此阶段除产生软件需求规格说明书（称软件需求文档，主要描述软件部分的需求）外，还要产生系统定义文档（即用户需求报告）和系统需求文档（即系统需求规格说明书）。3.3.3 需求描述52目录页3.3需求获取的步骤第3章需求验证就是验证（复查）需求分析的成果，

29、也称综合评审。需求验证就是对需求的正确性进行严格的验证，确保需求的一致性、完整性、清晰性、现实性和有效性，确保设计与实现过程中的需求可回溯性，并进行需求变更管理。一般情况下，需求验证以用户、系统分析员、系统设计人员和管理人员共同参与的会议形式进行，最后由评审负责人签字。3.3.4 需求验证 53目录页3.4结构化需求分析方法第3章1.分析策略结构化分析（Structured Analysis，简称SA）方法是20世纪70年代由EYourdon等人提出的一种面向数据流的分析方法，适用于大型的数据处理系统。由于利用图形来表达需求会使文档清晰、简明、易于学习和掌握，所以软件分析人员仍在广泛使用这种传

30、统的分析方法。结构化分析方法总的指导思想是“自顶向下，逐步求精”，它的两个基本原则是“抽象”和“分解”，即按照功能分解的原则，对系统进行逐层分解，直到找到所有满足功能要求的可实现软件元素为止。3.4.1 结构化分析方法概述 54目录页3.4结构化需求分析方法第3章3.4.1 结构化分析方法概述 55目录页3.4结构化需求分析方法第3章2.描述工具结构化分析方法利用图形等半形式化的描述表达需求，用它们形成需求规格说明书的主要部分，主要工具有：（1）数据流图（DFD）。描述系统的分解，即描述系统由哪几部分组成，各部分之间有什么联系等。（2）数据词典（DD）。明确定义数据流图中的数据和加工。它是数据

31、流条目、数据存储条目、数据项条目和基本加工条目的汇集。（3）结构化语言、判定表和判定树。用于详细描述数据流图中不能再分解的每一个基本加工的处理逻辑。3.4.1 结构化分析方法概述 56目录页3.4结构化需求分析方法第3章3.分析步骤3.4.1 结构化分析方法概述 57目录页3.4结构化需求分析方法第3章1.数据流图的基本符号3.4.2 数据流图 58目录页3.4结构化需求分析方法第3章2.数据流图的绘制步骤（1）画顶层数据流图列出系统的全部数据源点和终点，将系统加工处理过程作为一个整体，就可能得到顶层图。具体说就是：画一个圆，在其中写上系统名称，然后在圆的外围画上系统的输入和输出，这一步工作实

32、际上是决定研究的内容和系统的范围。（2）画各层数据流图对系统处理过程自顶向下，逐步分解，画出各层的数据流图。（3）画总的数据流图这一步对了解整个系统很有好处，但也要根据实际情况来决定总图的布局，不要把数据流图画得太复杂。3.4.2 数据流图 59目录页3.4结构化需求分析方法第3章3.数据流图中的命名规则（1）数据流 数据流表明数据和数据流向，它通常由一组数据项组成。（2）加工加工是对数据的某种操作或变换。（3）文件文件起暂时保存数据的作用。（4）数据源点和终点数据源点和终点是数据的始发点和终止点，是软件系统外部环境中的实体（包括人员、组织或其他软件系统），统称外部实体。3.4.2 数据流图

33、60目录页3.4结构化需求分析方法第3章4.数据流图中分层技术对于比较复杂的实际问题，在数据流图上常常出现十几个乃至几十个、上百个加工，这样的数据流图复杂而且难以理解。为了避免这种情况出现，可以采用数据流图的分层技术。分层技术的基本思想是，不是在一个数据流图中一次引入太多的细节，而是有控制地逐步增加细节，实现从抽象到具体的逐步过渡。3.4.2 数据流图 61目录页3.4结构化需求分析方法第3章1.数据词典的内容一般说来，数据词典的每个条目中应包括以下信息。（1）名字：数据流、数据项、数据存储或外部实体的名称。（2）别名或编号：第（1）项中对象的其他名字。（3）分类：数据流、数据项、加工、数据存

34、储、外部实体等。（4）内容描述：描述内容或数据结构等。（5）何处使用：哪些加工使用该条目。3.4.3 数据词典 62目录页3.4结构化需求分析方法第3章2.数据词典中使用的符号3.4.3 数据词典 63目录页3.4结构化需求分析方法第3章3.数据词典书写实例3.4.3 数据词典 64目录页3.4结构化需求分析方法第3章3.数据词典书写实例3.4.3 数据词典 65目录页3.4结构化需求分析方法第3章3.数据词典书写实例3.4.3 数据词典 66目录页3.4结构化需求分析方法第3章4.数据词典的实现通常，实现数据词典有三种途径：(1)人工方法：人工方法实现时，每一词典条目（即每一个数据定义或每一

35、个加工逻辑说明）写在一张卡片上，由专人管理和维护。为了便于搜索，所有卡片按数据名称排序。人工方法的优点是容易实现。(2)自动方法：把词典存在计算机中，用计算机对它搜索和维护。现有多种“词典管理程序”，如PLS/PSA。用计算机管理词典质量高，搜索、维护方便。(3)人工和自动混合的方法：在人工过程中可借助正文编写程序、报告生成程序等工具辅助完成。3.4.3 数据词典 67目录页3.4结构化需求分析方法第3章4.数据词典的实现不论通过哪种途径实现的数据词典都应尽量做到以下几点：(1)没有冗余：主要指数据定义不能重复。在规格说明书的其他组成部分中已出现的信息不能重复。(2)查阅方便：通过名字可以方便

36、地查阅数据词典中的每个定义。(3)定义的书写方法简单、方便、严谨，而且可读性强。(4)建议采用卡片形式书写。3.4.3 数据词典 68目录页3.4结构化需求分析方法第3章1.结构化语言3.4.4 加工逻辑的描述 69目录页3.4结构化需求分析方法第3章2.判定表在一些数据处理中，数据流图的加工需要经过多个逻辑条件组合的取值而确定，此时用自然语言或结构化语言难以描述，而运用判定表描述就比较清晰明了。3.4.4 加工逻辑的描述 70目录页3.4结构化需求分析方法第3章3.判定树判定树也是用来表达加工逻辑的工具，它是判定表的变形，有时比判定表更直观，更易于理解和使用。图书优惠政策的判定树如图3-8所

37、示。3.4.4 加工逻辑的描述 71目录页3.5需求规格说明书的编写与评审第3章1需求规格说明书的编写内容需求分析阶段应交付的主要文档是软件需求规格说明书。它提供了用户与开发人员对开发软件的共同理解，其作用相当于用户与开发单位之间的技术合同，是后续设计和编码的基础，是测试和验收的依据。软件需求规格说明书的内容框架可参阅GB/T 8567-2006计算机软件文档编制规范。在编写需求规格说明书时应注意以下几个问题：（1）说明书中的每一部分都非常重要，因此要慎重对待。（2）问题的描述要做到准确无误，没有二义性。（3）说明书的书写形式要规范。（4）允许用户根据项目的具体情况适当的将书写内容进行调整和筛

38、选。72目录页3.5需求规格说明书的编写与评审第3章2需求分析的评审在需求分析规格说明书编写完成后，必须进行需求评审，以验证需求的正确性。如果在评审过程中发现说明书存在错误或缺陷，应及时进行更改或弥补，重新进行相应部分的需求分析、需求建模、修改需求规格说明书，并再行评审。需求分析评审的主要内容如下：（1）一致性。所有需求必须是一致的，任何一条需求不能和其他需求相矛盾。（2）完整性。需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。（3）现实性。指定的需求应该是用现有的软硬件技术基本上可以实现的。对硬件技术的进步可以预测，对软件技术的进步则很难预测，只能从现有技术水平判断需求的现实

39、性。（4）有效性。必须证明需求是正确而有效的，确实能解决用户所面对的问题。73目录页3.6项目实践：“图书管理系统”软件需求分析第3章下面以第2章的“图书管理系统”为例，说明面向数据流的结构化分析方法及软件需求说明书的编写内容。在图书馆负责人和计算机系的技术人员通过了“图书管理系统”项目开发计划后，项目组随即进入了项目开发阶段，计算机系教师与图书馆相关业务人员紧密合作，经过15天的工作，形成了“图书管理系统”软件需求说明书。主要数据流图如下：74目录页3.6项目实践：“高校图书管理系统”软件需求分析第3章75目录页3.6项目实践：“高校图书管理系统”软件需求分析第3章76目录页3.6项目实践：

40、“高校图书管理系统”软件需求分析第3章77目录页3.6项目实践：“高校图书管理系统”软件需求分析第3章78目录页3.6项目实践：“高校图书管理系统”软件需求分析第3章79目录页3.6项目实践：“高校图书管理系统”软件需求分析第3章80目录页概要设计第4章本章要点n 掌握软件设计的概念与原则；n 理解软件设计的任务；n 掌握概要设计的内容与步骤；n 掌握结构化设计方法；n 了解概要设计说明书的内容。81目录页4.1软件设计概述第4章软件设计是软件工程的重要阶段，是一个将软件需求转换为软件表示的过程。软件设计的基本目标是用比较抽象概括的方式确定目标系统如何完成预定的任务，即确定系统的物理模型，解决

41、软件系统“怎么做”的问题。软件设计不同于程序设计，程序设计是软件设计的编码实现过程。软件设计的重要性有以下几点：（1）软件开发阶段（设计、编码、测试）占据软件项目开发总成本绝大部分，是在软件开发中形成质量的关键环节。（2）软件设计是开发阶段最重要的步骤，是将用户需求准确地转化为最终的软件产品的唯一途径。（3）软件设计作出的决策，最终将直接影响软件实现的成败。（4）软件设计是软件工程和软件维护的基础。4.1.1 软件设计的概念与重要性82目录页4.1软件设计概述第4章从工程管理的角度来看，可以将软件设计分为两个阶段：概要设计（又称总体设计）阶段和详细设计（又称过程设计）阶段。概要设计阶段得到软件

42、系统的基本框架，详细设计阶段明确系统内部的实现细节。4.1.2 软件设计的任务83目录页4.2 概要设计的任务与步骤第4章概要设计的基本任务是：（1）设计软件系统结构；（2）数据结构及数据库设计；（3）编写概要设计文档；（4）评审概要设计文档。4.2.1 概要设计的任务84目录页4.2 概要设计的任务与步骤第4章概要设计的一般步骤如下：1.选定体系结构2.确定设计方案3.设计软件结构4.数据结构及数据库设计5.制订测试计划6.编写概要设计文档7.概要设计文档评审4.2.2 概要设计的步骤85目录页4.3 概要设计的原则第4章1.模块化模块化是“分而治之”策略的具体表现。模块化就是将整体软件划分

43、成独立命名且可独立访问的模块，不同的模块通常具有不同的功能或职责。每个模块可独立地开发、测试，最后组装成完整的软件。在结构化方法中，函数、过程和子程序等都可作为模块；在面向对象方法中，对象、对象内的方法也是模块。模块是构成软件的基本构件。86目录页4.3 概要设计的原则第4章2.抽象与分解抽象是指忽视一个主题中与当前目标无关的方面，以便更充分地注意与当前目标有关的方面。抽象可以分成若干级别，级别越高，细节越少。其实整个软件的开发过程就是一个从抽象到具体的过程：需求分析时，使用问题域语言来概括性地描述解决方案，抽象级别最高；软件设计时，同时使用面向问题域和面向实现的两种术语描述解决方案，抽象级别

44、次之；在编码时，使用直接实现的方式（源程序代码）来描述解决方案，抽象级别最低。在软件设计中，过程抽象和数据抽象是两种常用的抽象手段。87目录页4.3 概要设计的原则第4章3.信息隐蔽和局部化信息隐蔽是指模块所包含的信息，不允许其他不需要这些信息的模块访问，独立的模块间仅仅交换为完成系统功能而必须交换的信息。信息隐蔽的目的是提高模块的独立性，减少修改或维护时的影响面。局部化就是把关系密切的软件元素物理地放得彼此靠近。其优点是可维护性、可靠性和可理解性好。4.模块独立性模块独立性概括了把软件划分为模块时要遵守的准则，也是判断模块构造是否合理的标准。模块独立性好的软件接口简单、容易开发，独立的模块也

45、容易测试和维护。因此，模块独立性是软件质量的关键。88目录页4.3 概要设计的原则第4章5.复用性设计复用是指同一事物不做修改或稍加修改就可以多次重复使用。将复用思想用于软件开发称为软件复用，将软件的重用部分称为软构件。也就是说，在构造软件系统时不必从零做起，可通过直接使用或加以修改已有软构件来组装成新系统。软件复用可提高软件的生产率。由于软构件是经过反复使用验证的，自身具有较高的质量，因此由软构件组成的新系统也具有较高的质量。软件复用并不局限于软件代码，其范围也可扩展到软件开发各个阶段，包括需求模型和规格说明、设计模型、文档、测试用例等。89目录页4.4 模块的独立性第4章模块独立性是指软件

46、系统中每个模块只涉及软件要求的具体的子功能，而与软件系统中其他模块的接口是简单的。模块独立性取决于模块的内部和外部特征。一般用耦合和内聚两个定性的指标来度量。耦合是模块之间相互依赖的紧密程度的度量，内聚是一个模块内部各个元素之间彼此结合的紧密程度的度量。一个模块内部各个元素之间的联系越紧密，则模块的内聚度就越高，相对地，它与其他模块之间的耦合就越低，模块的独立性就越强。一个优秀的软件设计，应尽量做到高内聚、低耦合，从而提高模块的独立性。90目录页4.4 模块的独立性第4章耦合是模块之间相互连接的紧密程度的度量。耦合强弱取决于模块间接口的复杂程度、进入或访问一个模块的点以及通过接口的数据。模块之

47、间的连接越紧密，联系越多，耦合性就越高，而其模块独立性就越弱。通常希望一个软件系统具有较低的耦合性。4.4.1 耦合性（Coupling）91目录页4.4 模块的独立性第4章1.非直接耦合两个模块间没有直接关系，它们之间的联系完全是通过主模块的控制和调用来实现的。耦合度最弱，模块独立性最强。2.数据耦合调用模块和被调用模块之间只传递简单的数据项参数。相当于高级语言中的值传递。4.4.1 耦合性（Coupling）92目录页4.4 模块的独立性第4章3.标记耦合调用模块和被调用模块之间传递数据结构而不是简单数据。也称特征耦合。标记耦合的模块间传递的不是简单变量，而是像高级语言中的数组名、记录名和

48、文件名等数据结构，这些名字即为标记，其实传递的是地址。4.4.1 耦合性（Coupling）93目录页4.4 模块的独立性第4章4.控制耦合模块之间传递的不是数据信息，而是控制信息如标志、开关量，一个模块控制了另一模块的功能。4.4.1 耦合性（Coupling）94目录页4.4 模块的独立性第4章5.外部耦合一组模块都访问同一全局简单变量，而且不通过参数表传递该全局变量的信息，则称之为外部耦合。6.公共耦合若一组模块都访问同一全局数据结构，则称之为公共耦合。公共数据环境可以是全局数据结构、共享的通信区、内存的公共覆盖区等。如果模块只是向公共数据环境输入数据，或是只从公共数据环境取出数据，这属

49、于比较松散的公共耦合；如果模块既向公共数据环境输入数据又从公共数据环境取出数据，这属于较紧密的公共耦合。4.4.1 耦合性（Coupling）95目录页4.4 模块的独立性第4章7.内容耦合一个模块直接访问另一模块的内容，则称这两个模块为内容耦合。若在程序中出现下列情况之一，则说明两个模块之间发生了内容耦合：（1）一个模块直接访问另一个模块的内部数据;（2）一个模块不通过正常入口而直接转入到另一个模块的内部;（3）两个模块有一部分代码重叠（该部分代码具有一定的独立功能）;（4）一个模块有多个入口。4.4.1 耦合性（Coupling）96目录页4.4 模块的独立性第4章一个模块内各个元素彼此结

50、合的紧密程度用内聚（或称聚合）来度量。一个理想的模块只完成一个功能，模块设计的目标之一是尽可能高内聚。4.4.2 内聚性（Cohesion）97目录页4.4 模块的独立性第4章1.偶然内聚一个模块内的各处理元素之间没有任何联系，只是偶然地被凑到一起。这种模块也称巧合内聚，内聚程度最低。4.4.2 内聚性（Cohesion）98目录页4.4 模块的独立性第4章2.逻辑内聚指模块内执行几个逻辑上相关的功能，通过参数确定该模块完成哪一个功能。4.4.2 内聚性（Cohesion）99目录页4.4 模块的独立性第4章3.时间内聚把需要同时或顺序执行的动作组合在一起形成的模块。时间内聚模块中的功能元素只