第三章软件需求分析基础.ppt

Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,*,Click to edit Master title style,Click to edit Master text styles,Second level,Third level,Fourth level,Fifth level,*,*,单击此处编辑母版标题样式,单击此处编辑母版文本样式,第二级,第三级,第四级,第五级,第三章软件需求分析基础,3.1,需求分析的概念和原则,需求分析的基本任务是准确地回答,“,系统必须做什么？,”,这一核心问题。,需求分析是发现、求精、建模和规约的过程。这一过程包括：详细精化最初由系统分析员建立在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择解决方案。,问题定义阶段,在需求分析之前，需要描述和定义问题。问题定义阶段必须回答的关键问题是,“,要解决的问题是什么,”,。,系统分析员扼要地写出对问题的理解，提出关于问题性质、工程目标和规模的书面报告，最后得出使用户和使用部门负责人都满意的文档。,问题定义阶段是软件生存周期中最简短的阶段，一般只需要一天甚至更少的时间。,发重修通知书 n y n,必须表示可理解的问题信息域。,如果在为某个处理命名时遇到了困难，则很可能是分解不恰当造成的，应该考虑重新分解。,为此，状态转换图表示了系统的各种行为模式（称为“状态”），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。,是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。,通常先为数据流命名，再为与之相关联的处理命名,不要把控制流作为数据流。,需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。,它的每一加工可能继续细化，形成子图。,实际的问题经常太大而且复杂难于进行整体理解，我们往往将这样的问题划分为易于理解的子问题，并建立各子问题间的接口，以便完成整个功能。,性能需求：指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求；,教材存量表，了解有没有该生要买的教材。,模型的核心是数据字典一个包含了软件使用或生产的所有数据对象描述的中心库。,系统内每一部分有几种状态,我们常使用图形符号创建模型。,可行性研究阶段,这个阶段要回答的关键问题是“对于上一个阶段所确定的问题有行得通的解决办法吗？”,系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程。,只有当 取得较大效益时，该工程项目才值得继续进行下去。,系统分析员得出该工程项目不值得做的结论，应该及时中止 该工程项目，避免更大的浪费。,可行性研究,问题识别,市场调查,分析准备,环境分析,物理分析,功能分析,信息分析,动态分析,确立系统方案，作出各种估算,模型评审,问题的初步认识,了解系统应解决的问题，这些问题是如何提出的,设想这些问题如何解决才能满足要求,了解问题的结构,市场调查,了解市场对待开发软件的需求情况,调查市场上已有的类似软件系统的功能、性能、价格情况,分析准备,确立分析计划,规定由谁参加分析作业，任务分配,对参加分析的人员进行必要的培训,环境分析,明确系统的目的和限制条件,使用单位的状况、经营方针和组织机构,使用单位的计算机利用情况,相关的硬件、软件及其它接口部分,用户的操作环境及操作要求,习惯、法律、制度上对软件的制约,开发能具备的技术条件和设备条件,物理分析,了解实际业务活动状况，特别对一些活动要点进行分析,明确在这些要点之间什么东西在流动，如何进行流动,对物理流量进行分析,对其模型化，得到实际业务系统（当前系统）的物理模型,功能分析,决定系统应具备的功能,(,工作域,),分析功能的结构：功能展开和功能分配,分析各功能之间的关系，整理它们之间传递的信息,利用数据流图，描述信息在系统流动与处理的情况,信息分析,调查系统的输入、输出、保存信息,明确信息的结构及各信息之间的关系,调查各信息的信息量,调查各种报表和文件的格式,建立粗略的数据词典，定义系统中使用的数据,动态分析,系统内每一部分有几种状态,各种状态转换的条件,同步产生的条件与同步后状态的变化,确立系统方案，进行各种估算,粗略地估算成本,估算可能取得的效益,提出可能需要的资源，包括人员、硬件、软件等,提出大概的进度安排,模型评审,将目标系统的逻辑模型提出管理部分与用户进行评审,复查问题定义、工程规模和系统目标,系统建模,为了开发系统模型，可通过构造模型进一步分析系统。,可以用系统流程图，数据流图和数据字典。,3.1.1,需求分析,需求分析是一种软件工程活动，使得系统分析员能够刻划出软件的功能和性能、指明软件和其他系统元素的接口、并建立软件必须满足的约束。,需求分析是软件设计师进行软件分解的基础，需求分析建造了软件处理的数据模型、功能模型和行为模型。,需求规约为软件设计师和客户提供了软件建造完后，进行质量评估的依据。,1.,软件需求的概念和分类,比较权威的需求的定义来自于,IEEE,软件工程标准词汇表中的定义：,l,用户解决问题或达到目标所需要的条件。,l,系统或系统部件要满足合同、标准、规范或其他正式规定的文档所要具有的条件。,l,反映上面两条的文档说明。,需求一方面反映了系统的外部行为，另一方面反映了系统的内部特性，反映的方式是需求文档。,比较通俗的需求定义如下：需求是指明系统必须实现什么的规格说明，它描述了系统的行为、特性或属性，是在开发过程中对系统的约束。,需求的类别,功能需求：指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；,性能需求：指定系统必须满足的定时约束或容量约束，通常包括速度（响应时间）、信息量速率、主存容量、磁盘容量、安全性等方面的需求；,可靠性和可用性需求：定量地指定系统的可靠性与可用性；,出错处理需求：说明系统对环境错误应该怎样响应；,接口需求：描述应用系统与其环境通信的格式，常见的接口需求有用户接口需求、硬件接口需求、软件接口需求和通信接口需求；,约束：描述了应用系统应遵守的限制条件，常见的约束有：精度约束、工具和语言约束、设计约束、应该使用的标准、应该使用的硬件平台等；,逆向需求：说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除发生误解的那些逆向需求；,将来可能提出的要求：应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。,另一种分类,功能性需求,产品的范围,功能与数据需求,非功能性需求,观感需求,易用性,性能,限制条件,操作需求,可维护性和可移植性需求,安全性需求,文化与,法律需求,需求的质量,完整性,正确性,可行性,必要性,划分优先级,无二义性,可验证性,设计无关性,2.,需求分析的任务,需求分析的任务是借助于当前系统的物理模型导出目标系统的逻辑模型，解决目标系统,“,做什么,”,的问题。,所要做的工作是深入描述软件的功能和性能，确定软件设计的限制和软件同其他系统元素的接口细节，定义软件的其他有效性需求。,必须全面理解用户的各项要求，但只能接受合理的要求。,要将软件的需求准确地表达出来，形成软件需求说明书。,目标系统,当前系统,物理模型,逻辑模型,模型化,抽象化,物理模型,逻辑模型,具体化,实例化,理,解,需,求,表,达,需,求,导,出,怎么做,做什么,需求分析的任务,获得当前系统的物理模型：首先，分析、理解当前系统是如何运行的，并用一个具体的模型来反映自己对当前系统的理解。,抽象出当前系统的逻辑模型：在理解当前系统,“,怎样做,”,的基础上，取出非本质因素，抽取出,“,做什么,”,的本质。,建立目标系统的逻辑模型：分析目标系统与当前系统逻辑上的差别，明确目标系统要“做什么”，从而从当前系统的逻辑模型中，导出目标系统的逻辑模型。,对目标系统逻辑模型进行补充：,具体内容如用户界面、启动和结束、出错处理、系统输入输出、系统性能、其他限制等等。,3,需求分析的主要工作,软件需求分析可被划分成,5,个工作阶段：问题分析；问题评估和方案综合；建模；规约；复审。,例,1.,汽车零件的主要供应商需要一个库存控制系统，系统分析员发现与当前的手工系统相关的问题包括：（,1,）不能快速地获得部件的状况；（,2,）更新卡片文件需要,2,至或,3,天的工作量；（,3,）由于没有办法查找相关厂商的部件信息，而使得对同一厂商同一货品多次再订货，等等。一旦问题被标识出来，系统分析员将确定新系统该产生什么信息，以及将提供什么信息。,例,2.,客户希望得到指明什么零件从库存中取出、以及还剩余多少相似零件的日报表。客户指明一旦当该零件离开仓库时库存管理员就该记载每个零件的标号。通过对当前问题和希望的信息（输入和输出）进行的评估，系统分析员开始综合一个或多个解决方案。为了便于开始，必须详细地定义系统的数据、处理功能和行为。,例,3.,在例,1,与例,2,的基础上，一些可以进一步思考内容是，一旦已经建立这些信息，就该考虑针对实现的基本体系结构，那么客户,/,服务器方法似乎是合适的，但是它确实属于软件计划的范围吗？似乎需要一个数据库管理系统，但是，该数据库系统真的是用户需要的吗？继续这种评估和综合的过程，直至分析员和客户均确信针对后面的开发步骤软件确实已被适当地刻划了。,在整个评估和综合过程中，分析员的主要焦点是,“,做什么,”,，而不是,“,怎么做,”,，即应该思考的是：系统会产生和使用什么数据？系统必须完成什么功能？将定义什么界面？会应用什么约束？,在问题评估和综合解决方案的活动中，系统分析员创建系统模型，以便可以更好地理解数据流和控制流、处理功能和操作行为以及信息内容。,4.,系统分析员的主要能力,在整个系统分析活动中，系统分析员起着关键的作用，其本人应该具备突出的能力，如：,能掌握抽象概念，能对其进行分类，能从中综合出解的能力；,能从冲突或者混淆中吸取恰当事实的能力；,能弄清用户环境的能力；,能为用户系统恰当配置软硬件的能力,能较好地用书面和口头形式进行沟通的能力,有,“,从树木见森林,”,的能力。,3.1.2,需求获取,软件需求分析中需要很好的的相互沟通，沟通总是要在两方或多方间进行。,客户和系统分析员之间最常用的交流方式，是通过预备会议或访谈进行的。,获取用户需求的主要方法是调查研究。,做好准备,制定调研计划,准备调研资料,访谈用户,写调研报告,评审,系统分析员所问的第一组问题可以关注客户、整体目标和收益，例如：谁是本工作的最初请求者？谁将使用该解决方案？成功的解决方案的经济收益是什么？,接下来的下一组问题使得系统分析员能够对问题做更好的理解，使得客户能够表达其关于解决方案的感觉，,最后一组问题关注于会议的效果。例如：你是回答这些问题的合适人员吗？你的回答是,“,正式的,”,吗？其他人员可以提供附加信息吗？有其他我应该问你的问题吗？,分析原则,在过去,20,年，研究者已经开发出一些实用分析方法及相应的建模符号，每种分析方法有独特的观点，然而，所有分析方法都遵循以下操作原则：,必须表示可理解的问题信息域。,必须定义软件将完成的功能。,必须表示软件的行为（作为外部事件的结果）。,必须划分描述信息、功能和行为的模型，从而能以层次的方式揭示细节。,分析过程应该从要素信息移向细节实现。,除了上面提到的操作性分析原则，,Davis,提出了一组针对需求工程的指导性原则：,在开始建立分析模型前，先充分理解问题。,开发原型，使得用户能够了解如何进行人机交互。,记录每个需求的起源及原因。,使用多个需求视图。建立数据、功能和行为模型，为软件工程师提供三种不同的视图。,给需求赋予优先级。,努力删除歧义性。,1.,信息域,所有的应用软件均可称为数据处理系统。,信息流表示了数据和控制在系统中流动时的变化方式，输入对象被变换为中间信息（数据和,/,或控制），这些信息被进一步变换为输出,数据的变换是程序必须完成的功能或子功能，在两个变换（功能）间流动的数据和控制定义了每个功能的接口。,信息结构表示了各种数据和控制项的内部组织，,2.,建模,我们创建模型，以获得对将要建造的实际实体有更好的理解。,要对软件变换的信息进行建模、对变换发生的功能（和子功能）进行建模、以及对变换发生时的系统行为进行建模。,在软件需求分析阶段，我们创建系统模型，这些模型着重于描述系统必须做什么而不是如何去做。,我们常使用图形符号创建模型。,功能模型：记录软件的变换信息，为了达到此目标必须至少完成三个常见功能：输入、处理和输出。,行为模型：,大多数软件对来自外界的事件做出反应，这种刺激,-,反应特征构成了行为模型的基础。行为模型创建了软件状态的表示，以及导致软件状态变化的事件表示。,需求分析阶段创建模型,的作用,模型帮助分析员理解系统的信息、功能和行为，因此，使得需求分析任务更容易实现。,模型变成了复审的焦点，因此，也成为确定规约的完整性、一致性和精确性的重要依据。,模型变成了设计的基础，为设计者提供了软件要素的表示视图，该表示可被转化到实现中去。,3.,划分,实际的问题经常太大而且复杂难于进行整体理解，我们往往将这样的问题划分为易于理解的子问题，并建立各子问题间的接口，以便完成整个功能。,第四条操作性分析原则,建议划分软件的信息、功能和行为域。,需求分析阶段的文档,软件需求说明书,初步的用户手册,修改、完善与确定软件开发实施计划,3.1.4,需求规格说明,软件需求规格说明是分析任务的最终产物，国家标准局、IEEE（标准号8301984）以及 防部门均已提出了软件需求规约（以及其他软件工程文档）的候选格式。,软件需求规格说明必须正确地定义所有的软件需求；除了设计上的特殊限制之外，软件需求规格说明中一般不描述任何设计、验证或项目管理的细节。,需求必须描述的基本问题,功能,所设计的软件要做什么；,性能,软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；,强加给实现的设计限制,在效果、实现的语言、数据库完整性、资源限制、操作环境等等方面所要求的标准；,属性,可移植性、正确性、可维护性及安全性等方面的考虑因素；,外部接口,与人、硬件其他软件和其他硬件的相互关系。,软件需求规格说明的大纲,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,功能需求,1,3.1.1.1,引言,3.1.1.2,输入,3.1.1.3,加工,3.1.1.4,输出,3.1.2,功能需求,2,3.1.n,功能需求,n,3.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.5,评审,需求审查是需求分析阶段工作的最后一步，是由软件软件工程师和客户一起进行并完成的。,目的是发现软件需求规格说明中的错误、二义性和遗漏的需求。,复审首先在宏观的级别上进行，复审者试图保证软件需求规格说明是完整的、一致的、精确的。例如提出以下问题：叙述的软件目标与系统的目标是否保持一致？图是否清楚？每个图可以没有文字补充而单独存在吗？是否考虑过开发的技术风险？是否存在不一致性、是否信息被忽略或存在冗余？和客户全面接触过吗？,软件需求规格说明的大纲,系统分析员需要进行一次大大压缩和简化了的系统分析和设计的过程。,选修课程=课程号+课名+学时+学分+课表,当给出了不完整的列表时，确定已理解了所有的项。,小心含糊的代词（例如，I/O模块与数据校验模块通信，且设置它的控制标志，那么标志是谁的？）,软件需求的概念和分类,销售文件=销售的商品,这一过程包括：详细精化最初由系统分析员建立在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择解决方案。,组织：按住房号递增排列,决定系统应具备的功能(工作域),例如：你是回答这些问题的合适人员吗？你的回答是“正式的”吗？其他人员可以提供附加信息吗？有其他我应该问你的问题吗？,开发原型，使得用户能够了解如何进行人机交互。,数据对象、属性与关系,除了设计上的特殊限制之外，软件需求规格说明中一般不描述任何设计、验证或项目管理的细节。,通常先为数据流命名，再为与之相关联的处理命名,然后复审会更详细，关注软件需求规格说明中的措词。例如：,着重于说服性的连接词（例如，当然、因此、明确地、显然地、紧随的），并问,“,为什么,”,。,观察含糊的术语（例如，一些、有时、经常、通常、一般地、大多数、大多数的），并进行澄清。,当给出了不完整的列表时，确定已理解了所有的项。关键是查找,“,等等、如此这样,”,。,小心含糊的动词如处理、拒绝、处制、跳过、限制,”,等，它们可以以很多方式来解释。,小心含糊的代词（例如，,I/O,模块与数据校验模块通信，且设置它的控制标志，那么标志是谁的？）,等等。,传统的软件需求分析基础,结构化的分析方法是最经典的需求分析方法。适用于数据处理类型软件的需求分析。,它提供的工具包括：数据流图、数据字典、结构化英语、判定表和判定树。,系统的分析模型必须达到三个主要目标：,（,1,）描述客户的需要；,（,2,）建立创建软件设计的基础；,（,3,）定义在软件完成后可以被确认的一组需求。,实体,关系图,状态,迁移图,数据流,图,数据对象描述,加工规格说明,数据,字典,控制规格说明,模型的核心是数据字典,一个包含了软件使用或生产的所有数据对象描述的中心库。,实体,-,关系图描述数据对象间的关系，实体,-,关系图是用来进行数据建模活动的。,数据流图有两个目的：指明数据在系统中移动时如何被变换；描述对数据流进行变换的功能（和子功能）。它可以用于信息域的分析，作为功能建模的基础。,状态转换图指明系统将如何动作。为此，状态转换图表示了系统的各种行为模式（称为,“,状态,”,），以及在状态间进行变迁的方式，状态转换图是行为建模的基础。,数据流图,任何软件系统（或计算机系统）从根本上来说，都是对数据进行加工或变换的工具。,1.,组成符号,例,4.,下面以教材购销系统中的教材销售为例，说明如何画数据流图。,从用户调查中了解到某高校向学生销售教材的手续是：先由系办公室的张秘书开购书证明，学生凭证明找教材科的王会计开购书发票，向李出纳员交付书款，然后到书库找赵保管员领书。现欲将上述手工操作改为计算机处理，试画出教材销售过程的数据流图。,首先找出数据的源点和终点，即找出数据源与数据汇，由此确定系统的边界。,由于是由学生开始购书，最后由学生领书，因此数据的源点和终点都是,“,学生,”,。,第二步找出加工，需要从描述中抽象出系统要完成的工作。,学生须凭购书证明得到购书发票，然后交付书款，得到领书凭证，最后领书。其间能由计算机完成的工作是审查学生的购书凭证并开出发票，按发票开出领书单，由此我们得到,2,个加工（审查并开发票，并领书单）。,第三步要找出数据流。,学生向系统提交购书单，学生从系统得到领书单，在加工之间要传输发票信息，这样我们得到,3,个数据流。同时还要注意在,“,审查并开发票,”,加工中排除了无效的书单，它也因作为一个数据流，因此最后得到,4,个数据流：购书单，发票，领书单，无效书单。,我们还要补充数据存储。数据存储一般不能通过系统描述确定，而要在设计数据流图时按照需要添加。,实际上在审查购书单和开出发票之前，至少要查阅两个文件：各班学生用书表，该表用以核对学生是否需用这些教材；教材存量表，了解有没有该生要买的教材。,把这两个文件加进上图中，并给加工添上编号，就得到计算机售书系统的完整的数据流图。,例子,在学生管理系统的一部分功能中，学术部安排好课程，学生通过系统注册想上的课程，得到课表，系统根据课程注册情况产生班级列表给相应教师。,2.,命名,数据流图中每个成分的命名是否恰当，直接影响数据流图的可理解性。给这些成分起名字时应该仔细推敲。下面讲述在命名时应注意的问题：,为数据流（或数据存储）命名,名字应代表整个数据流（或数据存储）的内容，而不是仅仅反映它的某些成分。,考生姓名,分类后的姓名,录取,分类,注意合适的命名，尽量用现实存在的表格、单据。,不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。,不要把控制流作为数据流。,汇款单,格式错误,合格的汇款单,核准的汇款单,格式,检查,计算,汇费,取下一个,考生成绩,录取,分类,为处理命名,通常先为数据流命名，再为与之相关联的处理命名,名字应该反映整个处理的功能，而不是它的一部分功能。,名字最好有一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。,通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能跟恰当些。,如果在为某个处理命名时遇到了困难，则很可能是分解不恰当造成的，应该考虑重新分解。,数据的源点和终点并不需要在系统中实现，它们只是系统的外围环境（可能是人员、计算机外部设备或传感器等）。通常为数据的源点和终点命名是采用它们在问题中习惯使用的名字，如,“,学生,”,，,“,管理员,”,。,软件需求分析可被划分成5个工作阶段：问题分析；,不要使用空洞的、缺乏具体含义的名字（如“数据”、“信息”、“输入”之类）。,功能需求：指定系统必须提供的服务，通过需求分析应该划分出系统必须完成的所有功能；,适用于数据处理类型软件的需求分析。,状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。,获取用户需求的主要方法是调查研究。,一对多联系（1N）,问题定义阶段必须回答的关键问题是“要解决的问题是什么”。,数据字典的作用，就是描述软件中的每个数据和加工的具体含义，以保持数据在系统中的一致性。,这一过程包括：详细精化最初由系统分析员建立在软件项目计划中确定的软件范围，创建所需数据流、控制流以及操作行为的模型，在此基础上选择解决方案。,A、按人或部门的功能要求，将加工“打碎”，形成：,即在一张数据流图中，尽量少出现有些加工已是基本加工，有些还要分解好几层的情况。,性能软件功能在执行过程中的速度、可使用性、响应时间、各种软件功能的恢复时间、吞吐能力、精度、频率等等；,系统内每一部分有几种状态,软件需求的概念和分类,3.,分层数据流图,对于大型的系统，按照其层次结构进行逐步分解，并以分层的数据流图反映这种结构关系，能清楚地表达和容易理解整个系统。,对任何一层数据流图来说，我们称它的上层图为父图，在它下一层的图则称为子图。,在多层数据流图中，顶层流图仅包含一个加工，它代表将被开发系统。它的输入流是该系统的输入数据，输出流是系统所输出数据。底层流图是指其加工不需再做分解的数据流图，它处在最底层。中间层流图则表示对其上层父图的细化。它的每一加工可能继续细化，形成子图。,4,数据流图实例,建立数据流模型的基本步骤概括地说，就是自外向内、自顶向下、逐层细化、完善求精。,例,5.,建立一个简化的商业自动化系统。其中：售货员负责录入销售的商品（商品名，编号，单价，数量），有时要根据特定情况对销售的商品进行修改或删除。收款员负责收取现金，并将多交的付款退还用户。销售经理需要随时查询整个部门的销售情况（时间，商品编号，销售金额），并在每日结束时，统计各类商品的销售金额。,首先：建立系统环境，确定系统边界，画出顶层,DFD,。,其中：,1,数据流为：销售的商品，日销售额等,2,数据源点为：营业员，经理，收款员,3,数据终点为：经理，收款员,4,加工名为：要建立的系统名字,然后自顶向下，逐层分解。,A,、按人或部门的功能要求，将加工,“,打碎,”,，形成：,录入、修改或,删除商品信息,录入、修改,现金额,并计算余额,查询商品销售情况,计算日销售额,1,2,3,注：需给每一加工编号,B,、,”,分派,”,数据流，形成：,录入、修改或,删除商品信息,2,录入、修改,现金额,并计算余额,查询商品销售情况,计算日销售额,销售的商品,现金额,现金余额,查询要求,销售情况,日销售额,1,3,其中：要根据特定的加工要求进行分派；,保持与顶层数据流的一致；,可以不引入数据源和数据终点。,C,、引入文件，使之形成一个有机整体,系统,录入、修改或,删除商品信息,录入、修改,现金额,并计算余额,查询商品销售情况,计算日销售额,销售的商品,现金额,现金余额,查询要求,销售情况,日销售额,销售文件,1,2,3,注：到一个文件，既有输入流，又有输出流，则可简化为,，并可不给出标识。,至此，体现精化，形成,0,层数据流图。,继续,A,、,B,、,C,：自顶向下，逐层分解。,例如：加工3,查询商品销售情况,计算日销售额,查询要求,销售情况,日销售额,销售文件,3,可分解为：,判定要求,查询要求,统计销售情况,计算日销售额,销售文件,查询要求,2,查询要求,1,销售情况,日销售额,5.,注意事项,画数据流图不是画流程图。数据流图只描述,“,做什么,”,，不描述,“,怎么做,”,和做的顺序，而流程图表述对数据进行加工的次序和细节。,父图和子图的平衡。正常情况下，父图和子图的输入数据和输出数据应分别保持一致，称为父子平衡。,局部文件。随着数据流图的分解，在下层数据流图中允许出现父图中没有的文件。,要遵守加工编号规则,。,顶层加工不编号；第,0,层的加工编为,1,，,2,，,，,n,号；第,1,层编为，,，等号，依此类推。,分解的深度与层次。逐层分解时，要求加工分解到足够简单，易于理解为止，这一加工也就是我们常说的基本加工。,分解的层次多少是合适的，这应当根据问题的复杂程度来确定。可以参考以下一些经验性的原则。,一个加工的分解，最多不要超出,7,个子加工。,分解在逻辑上应合理、自然，不能硬性分割。,在保证数据流得以理解的前提下，尽量少分解层次。,分解要均匀。即在一张数据流图中，尽量少出现有些加工已是基本加工，有些还要分解好几层的情况。,3.2.2,数据字典,数据字典的作用，就是描述软件中的每个数据和加工的具体含义，以保持数据在系统中的一致性。,有了数据流图和数据字典才算是较完整地描述了一个系统。数据流图和数据字典是需求规格说明书的主要组成部分。,数据字典要对数据流图中出现的所有名字（数据流、加工、数据存储）进行定义。,在数据字典中，描述数据元素之间的关系时，可以使用自然语言也可采用以下符号：,=,等价于（或定义为）,+,与,|,或（从方括号内由“,|,”,号隔开的分量中选择一个）,重复,（）选择,常常使用上限和下限符号，以进一步注释表示重复的括号。例如：和,1A5,都表示,A,重复,5,次。,数据流条目,学生,=,学号,+,姓名,+,性别,+,系,+,年级,+,选修课程,选修课程,=,课程号,+,课名,+,学时,+,学分,+,课表,课表,=,星期几,+,第几节,+,教室,年级,=1|2|3|4=1.4,文件条目,列出数据存储的组成数据项及文件的组织方式,航班目录文件,=,航班号,+,起点,+,终点,+,时间,组织：按航班号次序排列,加工条目,只列出基本加工的小说明,描述加工逻辑，也包括与加工有关的其他信息,用结构化自然语言描述,1,、数据流,:,销售的商品,=,商品名,+,商品编号,+,单价,+,数量,+,日期,现金额,=,余额,=,非负实数,查询要求,=,商品编号,|,日期,查询要求,1=,商品编号,查询要求,2=,日期,销售情况,=,商品名,+,商品编号,+,金额,日销售额,=,类名,+,现金额,2,、数据存贮,:,销售文件,=,销售的商品3,、数据项,给出加工小说明可以使用判定表、判定树,判断表,条件类别,条件组合,操作,操作执行,例如：,考试总分,=620 =620 2Kg,、,20Kg,20Kg,慢件,重量,20Kg,20Kg,收费,6,元,3,元,/Kg,4,元,/Kg,1,元,/Kg,2,元,/Kg,3,元,/Kg,实体关系图（,E-R,图）,实体关系图中包含,3,种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。,是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与软件系统中的实现方法无关。,1.,数据对象、属性与关系,数据对象是软件必须理解的复合信息的抽象。,数据对象彼此间是有关联的。,属性定义了数据对象的特征。它可用来：,为数据对象的实例命名；,描述这个实例；,建立对另一个数据对象的另一个实例的引用。,数据对象彼此之间相互连接的方式称为联系，也称为关系。,联系可分为以下,3,种类型,一对一联系（,1,1,）,一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。,一对多联系（,1,N,）,每位教师可以教多门课程，但是每门课程只能由一位教师来教，则某校教师与课程之间存在一对多的联系。,多对多联系（,M,N,）,一个学生可以学多门课程，而每门课程可以有多个学生来学，则学生与课程间的联系是多对多的。,2.,实体关系图实例,例,12.,在教学管理中，一个教师可以教授零门、一门或多门课程，每位学生也需要学习几门课程。用,E-R,图描述。,状态转换图,状态转换图（简称为状态图）通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果，系统将做哪些动作（例如，处理数据）。,1.,组成部分及其符号表示,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。,在状态图中定义的状态主要有：初态（即初始状态）、终态（即最终状态）和中间状态。在一张状态图中只能有一个初态，而终态则可以有,0,至多个。,状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。,事件是在某个特定时刻发生的事情，它是对引起系统做动作或系统状态转变的外界事件的抽象。状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。,当有多个进程申请占用,CPU,运行的时，有关,CPU,分配的进程的状况，可以用以下状态迁移图表示。,CPU,分配的状态迁移表,2.,状态转换图实例,画出 系统的状态图。,没有人打 时 ，处于闲置状态；有人拿起听筒，则进入拨号音状态，到达这个状态后，的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下（挂断），重又回到闲置状态；如果拿起听筒很长时间不拨号（超时），则进入超时状态；。,航班座位预订,练习,房产管理系统要用计算机对房产进行管理，包括住房的分配、调整和计算房租等。用户可以查询住房情况和房租金额，还可以对房产进行一些统计，给出统计表格，以便掌握全面的住房情况。,房管部门首先把住户要求（按照统一的格式由住户填写）输入进来，系统检查要求的合法性，如不合法则拒绝接受。如果是合法要求，根据要求类型处理。假定住户要求分三类：分房要求、调房要求、退房要求。分房要求根据分房单，先核准住户够不够分房资格，这要从住房标准文件中读出住房标准核准，如不够标准则不能分房，如够标准则输出核准后的分房单，再根据分房单分房。分配住房要从房产文件中读出相应的空房信息如房号、面积、房租等，并登记住户信息，如户主姓名、部门、分数等，写到住房文件中。输出分配后的住房单，同时计算房租，写入房租文件中。,咨询要求分查询住户情况、查询房租和统计全局住房情况三种。查询结果都能打印出来。,顶层数据流图,0,层数据流图,1,层数据流图,(1/2),1,层数据流图,(2/2),2,层数据流图,(1/3),2,层数据流图,(2/3),2,层数据流图,(3/3),数据字典,1.,数据流条目,住户要求,=,户主,+,分房要求,|,调房要求,|,退房要求,分房要求,=,部门,+,职称,+,家庭人口,+,住户分数,+,要求面积,住户情况,=,户主,+,部门,+,职称,+,家庭人口,+,住房分数,+住房面积,+,房租,+,房号,统计表,=,住房面积,+,已分住房数,+,空房数,分房单,=,户主,+,部门,+,职称,+,住房分数,+,住房面积,房号,=,楼号,+,房间号,2.,文件条目,文件名：住房标准文件,组成：,住房面积,+,最低住房分数,组织：按住房面积大小递增排列,文件名：房产文件,组成：,房号,+,住房面积,+,分配标志,+,每平米房租,组织：按住房号递增排列,文件名：住房文件,组成：,户主,+,部门,+,职称,+,家庭人员,+,住房分数,+,房号,+,住房面积,组织：按户主名拼音字母顺序排列,3.,小说明,加工编号：,1,加工名：检查合法性,加工逻辑：检查输入要求的合法性,有关信息：当有要求输入时执行此加工,加工编号：,加工名：要求类型处理,加工逻辑：根据住户要求选择,Case1,：要求分房，输出分房单,Case2,：要求调房，输出调房单,Case3,：要求退房，输出退房单,有关信息：当有合法住户要求输入时执行此加工,加工编号：,加工名：核准住房条件,加工逻辑：根据分房要求的住房面积从住房标准文件读出住房标准,IF,住房分数,=,最低住房分数,THEN,输出审核后的分房单,ELSE,取消分房资格,有关信息：当有分房单输入时执行此加工,