软件工程第3章结构化与设计3-1章需求和结构化系统CUMT2.dps

《计算机网络》课件制作人：谢希仁王荣存博士rcwang@第3-1章需求分析和

结构化系统分析第3章结构化分析与设计3-1.1

需求分析概述3-1.2需求获取3-1.3需求分析原则3-1.4需求规格说明3-1.5传统的软件需求分析基础

软件需求作为软件生命周期的第一个阶段，其重要性越来越突出，到20世纪80年代中期，逐步形成了软件工程的子领域——需求工程。90年代后，需求工程成为软件界研究的重点之一。从1993年起，每两年举办一次需求工程国际研讨会（ISRE），1994年起，每两年举办一次需求工程国际会议（ICRE）。一些关于需求工程的工作小组相继成立，使需求工程的研究得到了迅速进展。3-1.1

需求分析概述3-1.1.1需求分析的内容软件需求的重要性

软件需求无疑是当前软件工程中的关键问题，没有需求就没有软件。美国于1995年开始对全国范围内的8000个软件项目进行跟踪调查。分析失败的原因发现，与需求过程相关的原因占了45%，而其中缺乏最终用户的参与以及不完整的需求又是两大首要原因，各占13%和12%。未完成完成未实施完成需求:成功的软件开发的前提软件质量=系统所实现的需求/客户所期望的需求软件项目投标及签订合同的基础软件系统实现的基础系统确认移交的基础需求的定义IEEEStandardGlossaryofSoftwareEngineeringTerminology用户解决一个问题或达到一个目标所需要的一种状况或能力系统为了满足一种约定、标准、规格说明或其它正式文件而必须满足或拥有的一种状况或能力以上两种状态或能力的文档化表示主观需求客观需求需求文档IEEE公布的需求定义分别从用户和软件工程师的角度阐述了什么是需求，需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。比较通俗的需求定义如下：需求是指明系统必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。

软件需求用户需求系统需求功能需求非功能需求领域需求由客户管理员、用户等提出功能需求它是对系统应该提供的服务、功能以及系统在特定条件下的行为的描述。它与软件系统的类型、使用系统的用户等相关，有时需要详细描述系统的功能、输入/输出、异常等，有时还需要申明系统不应该做什么。领域需求是由软件系统的应用领域所决定的特有的功能需求，或是对功能的约束。课件制作人：谢希仁非功能需求产品需求机构需求外部需求互操作需求道德需求立法需求性能需求空间需求交付需求实现需求标准需求隐私需求安全性需求可用性需求效率需求可靠性需求可移植性需求课件制作人：谢希仁3-1.1.2需求类型1.按内容分类软件需求代表系统的综合要求，包括以下几种类型：(1)系统功能需求系统功能需求指根据系统所能实现的功能要求，对于每一类功能或者有时对于每一个功能，需要书弄清输入、加工和输出等需求。(2)系统性能需求按照系统的性能要求分类。例如联机系统的响应时间、系统需要的存储容量、后援存储器、重新启动、安全性和可靠性等方面的要求。课件制作人：谢希仁(3)系统运行需求这类要求集中表现为对系统运行时所处的环境、使用的资源、安全保密和用户界面的要求。如支持系统运行的硬件和软件是什么，采取哪种数据库管理系统，需要什么样的外存储器和数据通信接口。(4)未来可能出现的问题就是把不属于当前系统开发范围的问题都明确地列出来，因为将来很可能会提出这些问题。这些问题主要是为了系统将来的扩充和修改做准备，当以后需要时就可以很容易地进行扩展和修改了。课件制作人：谢希仁2.按用户的期望分类(1)正常需求用户陈述的针对系统的目标。(2)期望需求隐式的需求，可能由于是非常基础的而用户没有显示的陈述，如人机交互的容易性、整体的操作正确性和可靠性，以及软件安装的容易性。(3)兴奋需求在用户的期望范围之外，如果实现将令人愉快和出乎意料。课件制作人：谢希仁3.按必要性分类(1)强制的需求是指除非软件与这些需求一致，则该软件是不可接受的。(2)希望的需求是指这些需求将增进软件产品功能，但是如果缺乏的话也不是不可接受。(3)任选的需求是指这个功能可有可无。课件制作人：谢希仁3-1.1.3需求特性(1)正确性需求规格说明书中的功能、行为、性能描述必须与用户对目标软件产品的期望相吻合。(2)无歧义性对于用户、分析人员、设计人员和测试人员而言，需求规格说明书中的任何语法单位只能有唯一的语义解释。确保无歧义性的一种有效措施是在需求规格说明书中使用标准化术语，并对术语的语义进行显式的、统一的解释。课件制作人：谢希仁(3)完整性需求规格说明书不能遗漏任何用户需求，具体地说，目标软件产品的所有功能、行为、行为约束以及它在所有可能情况下的预期行为，均应完整地包含在需求规格说明书中。(4)可验证性对于规格说明书中的每一个需求，均应存在技术和经济上可行的手段进行验证和确认。课件制作人：谢希仁(5)一致性需求规格说明书的各部分之间不能相互矛盾。这些矛盾可以表现为术语使用方面的冲突，功能和行为方面的冲突，以及时序方面的前后不一致。(6)可理解性追求上述目标不应妨碍需求规格说明书对于用户、设计人员和测试人员的易理解性。特别是对于非计算机专业的用户而言，不宜在说明书中使用太多的专业化词汇。课件制作人：谢希仁(7)可修改性需求规格说明书的格式和组织方式应保证能够比较容易地接纳后续的增删和修改，并使修改后的说明书能够较好地保持其他各项属性。(8)可追踪性需求规格说明书必须将分析后获得的每项需求与用户的原始需求项清晰地联系起来，并为后续开发和其他文档引用这些需求项提供便利。课件制作人：谢希仁3-1.2需求分析(工程)的活动

需求工程是系统工程和软件工程的一个交叉分支，涉及到软件系统的目标、软件系统提供的服务、软件系统的约束和软件系统运行的环境。它还涉及这些因素和系统的精确规格说明以及系统进化之间的关系。它也提供现实需求和软件能力之间的桥梁。需求工程系统目标系统服务软件约束运行环境课件制作人：谢希仁需求工程的基本活动包括：●

获取需求；深入实际，在充分理解用户需求的基础上，获取系统需求。●需求分析与建模；进行需求建模、对模型或原型进行分析。●确认需求；确保需求说明准确、完整地表达系统的主要特性。●进化需求。客户的需要总是不断（连续）增长的，进化需求是必要的。课件制作人：谢希仁是需求工程的主体。●缺乏领域知识,应用领域的问题常常是模糊的、不精确的；●存在默认的知识,如难以描述的常识问题；●存在多个知识源,且多知识源之间可能有冲突；●客户可能的偏见，如不能提供或不想告知你所需要了解的事情。——非常困难，主要原因有：3-1.2.1需求获取(requirementelicitation)课件制作人：谢希仁需求获取技术需求抽取的方法一般有：1.面谈法重要而直接，简单的需求获取技术。2.问卷调查法是对面谈法的补充。

3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法还有知识工程方法等如：场记分析法、卡片分类法、分类表格技术和基于模型的知识获取等。面谈的对象主要有用户和领域专家：1）面谈前的准备要充分；2）面谈后注意认真分析总结；3）注意掌握面谈的人际交流技能。

课件制作人：谢希仁需求抽取的方法一般有：1.面谈法重要而直接，简单的需求获取技术。2.问卷调查法是对面谈法的补充。

3.需求专题讨论会最有力的需求获取技术。有利于培养高效团队。需求获取技术是从多个用户中收集需求信息的有效方式，一般问卷设计形式：1）多项选择问题；2）评分问题；3）排序问题。由开发方和用户方共同召开,操作步骤：①开发方根据双方制定的《需求调研计划》召开相关需求主题沟通会；②会后开发方整理出《需求调研记录》提交给用户方确认；③如果此主题还有未明确的问题则再次沟通,否则开始下一主题；④所有需求都沟通清楚后，开发方根据历次《需求调研记录》整理出《用户需求说明书》，提交给用户方确认签字。课件制作人：谢希仁需求抽取的方法一般有：4.观察用户的工作流程适用于用户无法准确表达需求的情况。5.原型化方法6.基于用例的方法需求获取技术课件制作人：谢希仁因此系统应该具备以下功能：⑴基本数据维护功能⑵基本业务功能⑶数据库管理功能⑷信息查询功能例1：有一个大学图书管理系统，该系统除了一般的图书管理功能外，还能够为学生和教工从其他图书馆借阅图书和文献资料提供服务。课件制作人：谢希仁1.功能需求⑴基本数据维护功能：提供使用者录入，修改并进行维护基本数据的途径。基本数据包括读者的信息、图书资料的相关信息，可以对这些信息进行修改，更新。⑵基本业务功能：读者借、还书籍的登记管理功能，随时根据读者借、还书籍的情况更新数据库系统，如果书籍已经借出，可以进行预留操作，书籍的编目、入库、更新等操作。课件制作人：谢希仁⑶数据库管理功能：对所有图书信息及读者信息进行统一管理维护的功能，对书籍的借还也要进行详细的登记，以便协调整个图书馆的运作。⑷信息查询功能：提供对各类信息的查询功能，如对本图书馆的用户借书信息，还书的信息，书籍源信息，预留信息等进行查询，对其他图书馆的书籍、资料源信息的查询功能。课件制作人：谢希仁2.非功能需求①系统安全性需求：为保证系统安全性，对本图书馆的各项功能进行分级、分权限操作，对各类用户进行确认。对其它图书馆借阅图书和文献资料服务控制访问范围：如限IP、限用户等。②对系统可用性的需求：为了方便使用者，要求对所有交互操作提供在线帮助功能。③对系统查询速度的需求：要求系统在20S之内响应查询服务请求。④对系统可靠性的需求：要求系统失败发生率小于1%。课件制作人：谢希仁3.领域需求例如：对“大学图书管理系统”，提出一些与图书管理的业务相关的需求：⑴图书编目要求按照《中国图书馆分类法》进行；⑵由于版权限制，某些文献资料只能在图书馆规定的阅览室阅读，并限制复制和打印。第一条需求是对遵循我国图书管理的规定，执行对图书的分类管理的标准。而第二条需求则是版权法对图书馆文献资料的保护的需要，描述了对一类文献资料有限制的使用和服务。课件制作人：谢希仁

需求分析和建模又包含三个层次的工作。1、需求分析2、需求建模（分为企业建模、功能需求建模和非功能需求建模等）3、需求规格说明—不同的描述方式。主要对收集到的需求进行提炼、分析和认真审查，确保所有参加人员取得一致共识。找出错误、遗漏和不足，建立完整的分析模型。3-1.2.2需求分析与建模需求分析常用技术为了降低软件的复杂度，便于对问题的分析和理解，常采用以下技术：1.分解将大问题分解为小问题，通常是自顶而下，不断细化的过程。2.抽象抓住问题的本质特性，从不同抽象层次进行分析，提出解决问题的方案。3.多视点注意从各类开发人员和不同用户的角度考虑问题，才能获得对系统的全面完整的需求。需求规格说明软件需求规格说明是分析任务的最终产物，美国国家标准局、IEEE以及美国防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。软件需求规格说明必须正确地定义所有的软件需求；除了设计上的特殊限制之外，软件需求规格说明中一般不描述任何设计、验证或项目管理的细节。需求必须描述的基本问题功能——所设计的软件要做什么；性能——软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；强加给实现的设计限制——在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；属性——可移植性、正确性、可维护性及安全性等方面的考虑因素；外部接口——与人、硬件、其他软件和其他硬件的相互关系。软件需求规格说明的大纲

1前言1.1目的1.2范围1.3定义、缩写词、略语1.4参考资料2项目概述2.1产品描述2.2产品功能2.3用户特点2.4一般约束2.5假设和依据

3具体需求3.1功能需求3.1.1功能需求引言输入加工输出3.1.2功能需求2……

3.1.n功能需求n3.2外部接口需求3.2.1用户接口3.2.2硬件接口3.2.3软件接口3.2.4通信接口3.3性能需求3.4设计约束3.4.1其他标准的约束3.4.2硬件的限制…………

3.5属性3.5.1安全性3.5.2可维护性…………

3.6其他需求3.6.1数据库3.6.2操作3.6.3场合适应性…………

附录索引

需求验证的重要性

１.由于需求是软件开发的第一阶段，直接影响后面各阶段的开发。

２.需求的可变性必须进行验证。软件需求软件设计软件编码软件测试运行维护做什么怎么做3-1.2.3需求的有效性验证需求验证的内容

1.有效性检查—指功能需求是否符合用户所提出的需求。

2.一致性检查—系统功能描述及约束是否一致。

3.完备性检查—是否包含所有系统用户的需求和约束。

4.可检验性检查—是否能设计出一组验证方法，确定了检验的标准。需求管理贯穿需求分析全过程，包括:需求管理变更控制建议变更分析影响交流合并测量需求的稳定性版本控制定义需求文档版本确定单个需求文档版本需求跟踪定义与其他需求的链接定义与其他系统元素的链接需求状态跟踪定义需求状态跟踪所有需求状态3-1.2.3需求管理需求管理的所有活动中，最重要的是——

“需求变更管理”，包括:问题分析和变更描述变更分析和成本计算变更实现修正后的需求识别出的问题需求管理过程需要CASE(ComputerAidedSoftwareEngineering)工具支持。1.传统的变化管理基本内容包括软件配置、软件基线和变化审查。2.新的管理方法

⑴软件家族法。即软件产品线方法，该方法是源于工业界产品线的概念，关注于一个软件企业如何组织一组具有共性特征的，相似产品的生产，并应用软件复用的相关原理与技术。

⑵多视点方法。它可以用于管理不一致性并进行关于变化的推理。是从多个视点出发在软件工具的协助下对需求描述，进行自动需求建模，从而提高需求模型的完整性。需求变更管理方法需求工程过程

可行性研究需求导出和分析需求描述需求有效性验证可行性报告系统模型用户需求和系统需求需求文挡在整个需求分析活动中，需求分析师起着关键的作用，其本人应该具备突出的能力，如：能掌握抽象概念，能对其进行分类，能从中综合出解的能力；能从冲突或者混淆中吸取恰当事实的能力；能弄清用户环境的能力；能为用户系统恰当配置软硬件的能力能较好地用书面和口头形式进行沟通的能力有“从树木见森林”的能力。

需求分析师的主要能力功能分解方法

将系统看作若干功能模块的集合，每个功能又可以分解为子功能,子功能还可继续分解,分解的结果即是系统的雏形。存在问题1.需要人工完成2.无法对描述的准确度进行验证。3.难以适应需求的变化。问题空间功能子功能映射3-1.3需求分析方法1．客房预定系统2．前台接待系统3．前台收银系统4．帐务系统

5．管家系统6．电话系统

7．客历系统8．合约系统

9．经理系统10．总经理系统

11．密码管理系统12．报表系统

13．帐务报表酒店管理系统例：按照功能分解为以下子系统：盘存/销售系统1.0.0销售处理1.1.0盘存处理1.2.0例：盘存/销售系统，用户提出系统应有以下功能:①计算买主订单②准备销售报表③建立买主文件和应收帐发票④运行更新的盘存文件

⑤产生托运单和包装单⑥保证库存及时订货计算销售记录1.1.1产生销售报表1.1.2核对买主贷方金额1.1.3验证库存量级1.2.1产生货运订单1.2.2执行买主汇票1.2.3产生盘存报表1.2.4结构化分析方法是一种以数据、数据的封闭性为基础，从问题空间到某种表示的映射方法,由数据流图(DFD图)表示。顾客出版社验证订单汇总订单订单出版社订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件订货存根文件面向对象的分析方法

面向对象分析方法(OOA)的关键是识别问题域内的对象,分析它们之间的关系,并建立起三类模型。功能模型定义“做什么”，状态模型定义“何时做”，对象模型定义“谁对谁做”信息建模法

是从数据的角度对现实世界建立系统的信息模型,基本工具是ER图。是由实体、属性和关系组成的网络图。E-实体，是一个或一组对象；R-关系，实体之间联系或交互作用。分解：对于一个复杂的系统，为了将复杂性降低到可以掌握的程度，可以把大问题分解成若干小问题，然后分别解决（如右图）。抽象：分解可以分层进行，即先考虑问题最本质的属性，暂把细节略去,以后再逐层添加细节，直至涉及到最详细的内容，这种用最本质的属性表示一个系统的方法就是“抽象”。x21.11.33-1.4结构化分析方法3-1.4.1SA法的基本思想——“分解”和“抽象”。

基本思想与步骤SA法的描述方法1、分层的数据流图(DFD图)2、数据词典3、描述加工逻辑的结构化语言、判定表及判定树当前系统具体模型建立当前系统逻辑模型抽象目标系统逻辑模型建立完善的系统逻辑模型改进深入调查研究分析用户需求,用DFD图描述分析系统需求,用DFD图描述修改完善DFD图,增添功能3-1.4.2SA法的步骤实体—关系图状态—迁移图数据流图数据对象描述加工规格说明数据字典控制规格说明数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能（和子功能）。它可以用于信息域的分析，作为功能建模的基础。状态转换图指明系统将如何动作。为此，状态转换图表示了系统的各种行为模式（称为“状态”），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。顾客出版社验证订单汇总订单订单出版社订单图书目录文件顾客档案待处理订单文件正确订单一批订单出版社档案文件订货存根文件画图步骤：1、确定外部实体及输入、输出数据流。2、确定分解顶层的加工。3、确定使用的文件。4、用数据流将各部分连接起来，形成数据封闭。注意：标注各加工框及数据流名称。例一图书预定系统（顶层DFD图）数据流图（DFD,DataFlowDiagram）是用来描绘软件系统的逻辑模型的工具。通过数据流图描绘信息在系统中流动和加工处理的情况。是各类人员之间极好的交流、沟通的工具设计数据流图只需考虑系统必须完成的基本逻辑功能，一般在图中不使用具体的物理元素，完全不需要考虑如何具体地实现这些功能。3-1.4.3数据流图组成符号任何软件系统（或计算机系统）从根本上来说，都是对数据进行加工或变换的工具。

例下面以教材购销系统中的教材销售为例，说明如何画数据流图。从用户调查中了解到某高校向学生销售教材的手续是：先由系办公室的张秘书开购书证明，学生凭证明找教材科的王会计开购书发票，向李出纳员交付书款，然后到书库找赵保管员领书。现欲将上述手工操作改为计算机处理，试画出教材销售过程的数据流图。首先找出数据的源点和终点，即找出数据源与数据汇，由此确定系统的边界。由于是由学生开始购书，最后由学生领书，因此数据的源点和终点都是“学生”。第二步找出加工，需要从描述中抽象出系统要完成的工作。学生须凭购书证明得到购书发票，然后交付书款，得到领书凭证，最后领书。其间能由计算机完成的工作是审查学生的购书凭证并开出发票，按发票开出领书单，由此得到2个加工（审查并开发票，开领书单）。

第三步要找出数据流。

学生向系统提交购书单，学生从系统得到领书单，在加工之间要传输发票信息，这样得到3个数据流。同时还要注意在“审查并开发票”加工中排除了无效的书单，它也应作为一个数据流。因此最后得到4个数据流：购书单，发票，领书单，无效书单。还要补充数据存储。数据存储一般不能通过系统描述确定，而要在设计数据流图时按照需要添加。

实际上在审查购书单和开出发票之前，至少要查阅两个文件：①各班学生用书表，②教材存量表。

把这两个文件加进上图中，并给加工添上编号，就得到计算机售书系统的完整的数据流图。命名

数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。给这些成分起名字时应该仔细推敲。名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。考生姓名分类后的姓名录取分类注意合适的命名，尽量用现实存在的表格、单据。不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。不要把控制流作为数据流。汇款单合格的汇款单核准的汇款单格式检查计算汇费取下一个考生成绩录取分类为处理命名通常先为数据流命名，再为与之相关联的处理命名名字应该反映整个处理的功能，而不是它的一部分功能。名字最好有一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能跟恰当些。如果在为某个处理命名时遇到了困难，则很可能是分解不恰当造成的，应该考虑重新分解。数据的源点和终点并不需要在系统中实现，它们只是系统的外围环境（可能是人员、计算机外部设备或传感器等）。通常为数据的源点和终点命名是采用它们在问题中习惯使用的名字，如“学生”，“管理员”。

分层数据流图对任何一层数据流图来说，称它的上层图为父图，在它下一层的图则称为子图。在多层数据流图中，顶层流图仅包含一个加工，它代表将被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。底层流图是指其加工不需再做分解的数据流图，它处在最底层。中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。X13....1顶层中间层底层先全局后局部,先整体后细节,先抽象后具体.0图1图2图1.1图2.1图2.2图分层DFD图需求案例分析案例医院病房监护系统

（采用结构化分析方法）一、问题的描述

在医院ICU病房里，将病症监视器安置在每个病床，对病人进行监护。监视器将病人的组合病症信号实时地传送到中央监护系统进行分析处理。在中心值班室里，值班护士使用中央监护系统对病员的情况进行监控，监护系统实时地将病人的病症信号与标准的病诊信号进行比较分析，当病症出现异常时，系统会立即自动报警，并打印病情报告和更新病历。根据医生的要求随时打印病人的病情报告，系统还定期自动更新病历。案例

医院病房监护系统经过初步的需求分析，得到系统功能要求：1、监视病员的病症(血压、体温、脉搏等)。2、定时更新病历。3、病情出现异常情况时报警。4、随机地产生某一病员的病情报告。产生病情报告监视病情更新病历1、监视病员的病症

♦采集病症信号(血压、体温、脉搏等)。♦组合病症信号。♦将模拟病症信号转换为数字信号（A-D转换）。2、定时更新病历♦将病症信号进行格式化并加入更新日期、时间。♦更新病历库中病人的信息。♦可人工设定更新病历的时间间隔。3、病情出现异常情况时报警♦根据标准病症信号库中的值，判断是否报警。♦将报警信号转换为各种模拟信号（D-A转换）。♦实时打印病情报告，立即更新病历。4、随机地产生某一病员的病情报告系统功能需求—局部监视—更新日志—产生病情报告非功能需求1、监视器与网络的可靠性要求，涉及人的生命安全。2、效率需求中对时间、空间的需求，所采集的病症信号数据量大。3、互操作需求—如要求监视器采样频率可人工调整等。4、对病人病历的隐私的要求。病员护士护士病员监护系统病员日志病症信号要求报告病症报告报警顶层DFD图医院病房监护系统分层DFD图顶层确定了系统的范围，其外部实体为病员和护士护士病员护士第一层：病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据格式化病员数据生理信号极限值1324日志数据日志数据医院病房监护系统一层DFD图紧急报告第二层：加工“中央监视”分解医院病房监护系统二层DFD图计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.4紧急报告计算超过极限值否病员数据超过极限值报警开解信号产生报警信息病员极限格式化病员数据体温血压、体温、脉搏生理信号极限值时间脉搏血压日期时钟格式化病员数据3.4第二层：加工“中央监视”分解医院病房监护系统分层DFD图第一层格式化病员数据生理信号极限值病员护士护士中央监视病员日志病症信号要求报告病症报告报警局部监视生成报告病员极限更新日志病员数据1324日志数据紧急报告紧急报告加工分解的原则

自然性：概念上合理、清晰；

均匀性：理想的分解是将一个问题分解成大小均匀的几个部分；分解度：一般每一个加工每次分解最多不要超过７个子加工,分解应分解到基本加工为止。画分层DFD图的基本原则数据守恒与数据封闭原则数据守恒是指加工的输入/出数据流是否匹配，即每一个加工既有输入数据流又有输出数据流。数据封闭是对整个系统而言。合理使用文件

当文件作为某些加工之间的交界面时，文件必须画出来，一旦文件作为数据流图中的一个独立成份画出来了，那么他同其他成份之间的联系也应同时表达出来。注意DFD图不是流程图,不表示软件的控制流程。子图与父图的“平衡”

父图中某个加工的输入输出数据流应该同相应的子图的输入输出相同(相对应），分层数据流图的这种特点称为子图与父图“平衡”。分层DFD图的改进

DFD图须经过反复修改，才能获得最终的目标系统的DFD图。从以下方面改进DFD图：

1、检查数据流的正确性

①数据守恒②子图、父图的平衡③文件使用是否合理。特别注意输入/出文件的数据流。2、改进DFD图的易理解性①简化加工之间的联系（联系越少，独立性越强，易理解性越好）。②改进分解的均匀性。③适当命名（各成分名称无二义性，准确、具体）数据流图实例

建立数据流模型的基本步骤概括地说，就是自外向内、自顶向下、逐层细化、完善求精。例.建立一个简化的商业自动化系统。其中：售货员负责录入销售的商品（商品名，编号，单价，数量），有时要根据特定情况对销售的商品进行修改或删除。收款员负责收取现金，并将多交的付款退还用户。销售经理需要随时查询整个部门的销售情况（时间，商品编号，销售金额），并在每日结束时，统计各类商品的销售金额。首先：建立系统环境，确定系统边界，画出顶层DFD。其中：1数据流为：销售的商品，日销售额等2数据源点为：营业员，经理，收款员3数据终点为：经理，收款员4加工名为：要建立的系统名字然后自顶向下，逐层分解。

A、按人或部门的功能要求，将加工“打碎”，形成：录入、修改或删除商品信息录入、修改现金额,并计算余额查询商品销售情况计算日销售额123注：需给每一加工编号B、”分派”数据流，形成：录入、修改或删除商品信息

2录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品现金额现金余额查询要求销售情况日销售额13其中：要根据特定的加工要求进行分派；保持与顶层数据流的一致；可以不引入数据源和数据终点。C、引入文件，使之形成一个有机整体—系统录入、修改或删除商品信息24录入、修改现金额,并计算余额查询商品销售情况计算日销售额销售的商品现金额现金余额查询要求销售情况日销售额销售文件123注：到一个文件，既有输入流，又有输出流，则可简化为，并可不给出标识。至此，体现精化，形成0层数据流图。

继续A、B、C：自顶向下，逐层分解。例如：加工3查询商品销售情况计算日销售额查询要求销售情况日销售额销售文件3可分解为：3.1判定要求查询要求3.2统计销售情况3.3计算日销售额销售文件查询要求2查询要求1销售情况日销售额注意事项

画数据流图不是画流程图。数据流图只描述“做什么”，不描述“怎么做”和做的顺序，而流程图表述对数据进行加工的次序和细节。父图和子图的平衡。正常情况下，父图和子图的输入数据和输出数据应分别保持一致，称为父子平衡。局部文件。随着数据流图的分解，在下层数据流图中允许出现父图中没有的文件。要遵守加工编号规则。顶层加工不编号；第二层的加工编为1，2，…，n号；第三层编为1.1，1.2，…，n.1，n.2，…等号，依此类推。分解的深度与层次。逐层分解时，要求加工分解到足够简单，易于理解为止，这一加工也就是常说的基本加工。分解的层次多少是合适的，这应当根据问题的复杂程度来确定。可以参考以下一些经验性的原则。一个加工的分解，最多不要超出7个子加工。分解在逻辑上应合理、自然，不能硬性分割。在保证数据流得以理解的前提下，尽量少分解层次。分解要均匀。即在一张数据流图中，尽量少出现有些加工已是基本加工，有些还要分解好几层的情况。

描述银行取款过程的数据流图3-1.4.3数据字典DD

数据流图描述系统的逻辑模型，但它不可能表达一个系统的全部逻辑特性，特别是有关数据的详细内容。数据字典恰恰弥补了数据流图在这个方面的不足，它专门记录有关数据方面的信息，作为对数据流图的补充和解释。数据流图和数据字典共同构成全面描述软件需求说明书的核心。

定义方法数据字典要对数据流图中出现的所有名字进行定义。同日常使用的词典一样，为了便于查阅，词典中的所有条目都要按一定的次序排列起来，也可采用卡片的形式，以供开发与维护人员方便地使用。数据流定义中常用的符号含义如下：= 表示“被定义为”；+ 表示“和”，连接两个或多个分量；[.|.]表示“选择”，即可选择方括号中的一项，用“|”作为各项的分割符；()表示“可选”，即括号内的项可选可不选；m{}n n表示“重复”，n为重复次数的上限，m为重复次数的下限，如重复次数没有限定可不标出上下限。也可以利用上下标表示。实现数据字典可以用人工方式建立，记录在卡片上。也可以用自动化的方式记录在计算机的存储器上。数据字典的内容主要包括：数据元素、数据流、数据存储、外部项、加工处理等。按词条形式描述数据的属性、结构、逻辑关系、特征信息等。1.数据元素词条描述数据元素名：类型：数字（离散值，连续值），文字（编码类型）长度：取值范围：相关的数据元素及数据结构：2.数据流数据流名：说明：简要介绍作用即它产生的原因和结果数据流来源：来自何方数据流去向：去向何处数据流组成：数据结构数据量流通量：数据量，流通量3.数据存储数据存储名：简述：存放的是什么数据输入数据：输出数据：数据文件组成：数据结构存储方式：顺序，直接，关键码存取频率：4.加工逻辑加工名：加工编号：反映该加工的层次简要描述：加工逻辑及功能简述输入数据流：输出数据流：加工逻辑：简述加工程序，加工顺序对数据流图的每一个基本加工，必须有一个基本加工逻辑说明基本加工逻辑说明必须描述基本加工如何把输入数据流变换为输出数据流的加工规则加工逻辑说明必须描述实现加工的策略而不是实现加工的细节加工逻辑说明中包含的信息应是充足的，完备的，有用的，没有重复的多余信息5.源点及终点词条描述名称：外部实体名简要描述：什么外部实体有关数据流：数目：6.数据结构的描述符号 含义 举例＝被定义为＋与x=a＋b[...,...]或[...|...]或x=[a,b]，x=[a|b]{...}或m{...}n重复x={a}，x=3{a}8(...)可选x=(a)“...”基本数据元素x=“a”.. 连结符x=1..9结构化语言判定表判定树

对DFD图中每一个基本加工都必须有一个小说明给出该加工的精确描述。小说明中应精确地描述加工的激发条件、加工逻辑、优先级、执行频率和出错处理等。加工逻辑是其中最基本的部分，指用户对这个加工的逻辑要求。对基本加工说明有三种描述方式：3-1.4.4加工说明1结构化语言是一种介于自然语言和形式化语言之间的语言语言的正文用基本控制结构进行分割，加工中的操作用自然语言短语来表示其基本控制结构有三种：简单陈述句结构：避免复合语句；重复结构：WHILE_DO或REPEAT_UNTIL结构。判定结构：IF_THEN_ELSE或CASE_OF结构；结构化英语的词汇表英语命令动词数据词典中定义的名字有限的自定义词逻辑关系词IF_THEN_ELSE、CASE_OF、WHILE_DO、REPEAT_UNTIL等组成。商店业务处理系统中“检查发货单”IF发货单金额超过$500THENIF欠款超过了60天THEN在偿还欠款前不予批准ELSE（欠款未超期）发批准书，发货单ENDIFELSE（发货单金额未超过$500）IF欠款超过60天THEN发批准书，发货单及赊欠报告ELSE（欠款未超期）发批准书，发货单ENDIFENDIFBEGIN输入用户账号和口令IF输入空的帐号或口令THENBEGIN 提示错误 中断登录END验证帐号、口令IF非合法用户OR权限=“禁止”THENBEGIN 提示错误 中断登录END初试化运行环境数据库事务操作逻辑2.判定表

判定表也是一种表达加工逻辑的工具。在某些数据处理中，某数据流图的加工需要依赖于多个逻辑条件的取值，就是说完成这一加工的动作是由于某一组条件取值的组合而引发的。这时使用判定表来描述比较合适。判定表的组成条件：列出一组条件的对象；条件取值：列出各种可能的条件取值组合；操作：列出所有的操作；操作条目：列出对应的条件组合下所选的操作。判定表的一般结构

条件1条件1取值条件1取值…条件2条件2取值条件2取值……………操作1操作1取值操作1取值操作2操作2取值操作2取值…………建立判定表的步骤列出与一个具体加工(或过程)有关的所有处理列出过程执行期间的所有条件(或所有判断)将特定条件取值组合与特定的处理相匹配，消去不可能发生的条件取值组合将右部每一纵列规定为一个处理规则，即对于某一条件取值组合将有什么动作毕业证、学位证书授予判定表

12345没有未通过的必修课程YNNNN未通过的必修课程学分总数小于等于12YNNYY通过的课程学分数大于等于30YYNYN授予毕业证书√授予结业证书√授予肄业证书√不授予任何证书√√以“检查发货单”为例例某校对于各种不同职称教师，根据是本校专职教师还是外聘兼职教师决定其讲课的每课时津贴标准。本校专职教师每课时津贴费：教授50元．副教授40元。讲师30元，助教20元。外聘兼职教师每课时津贴费：教授60元，副教授50元，讲师40元，助教30元。

3判定树判定树是判定表的变种，它能清晰地表达复杂的条件组合与所对应的操作之间的关系。判定树的优点在于它含义清楚，易于理解和使用，比判定表更加直观。计算折扣量7～9月，12月1～6月，10、11月订票量>50：15%订票量<=50：5%订票量>50：30%订票量<=50：20%4IPO图IPO图是输入/处理/输出图的简称，它是美国IBM公司发展