软件工程导论(第4版)电子教案第3章.ppt

单击此处编辑母版标题样式,单击此处编辑母版副标题样式,3.6,状态转换图,3.7,其他图形工具,3.8,验证软件需求,3.9,小结,习题,需求分析是软件定义时期的最后一个阶段，它的基本任务是准确地回答“系统必须做什么,?”,这个问题。,需求分析的任务还不是确定系统怎样完成它的工作，而仅仅是确定系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。,在需求分析阶段结束之前，系统分析员应该写出软件需求规格说明书，以书面形式准确地描述软件需求。,在分析软件需求和书写软件需求规格说明书的过程中，分析员和用户都起着关键的、必不可少的作用。只有用户才真正知道自己需要什么，但是他们并不知道怎样用软件实现自己的需求，用户必须把他们对软件的需求尽量准确、具体地描述出来；分析员知道怎样用软件实现人们的需求，但是在需求分析开始时他们对用户的需求并不十分清楚，必须通过与用户沟通获取用户对软件的需求。,1.,功能需求,这方面的需求指定系统必须提供的服务。通过需求分析应该划分出系统必须完成的所有功能。,2.,性能需求,性能需求指定系统必须满足的定时约束或容量约束，通常包括速度,(,响应时间,),、信息量速率、主存容量、磁盘容量、安全性等方面的需求。,3.1,需求分析的任务,3.1.1,确定对系统的综合要求,3.,可靠性和可用性需求,可靠性需求定量地指定系统的可靠性。,可用性与可靠性密切相关，它量化了用户可以使用系统的程度。,4.,出错处理需求,这类需求说明系统对环境错误应该怎样响应。例如，如果它接收到从另一个系统发来的违反协议格式的消息，应该做什么,?,注意，上述这类错误并不是由该应用系统本身造成的。,在某些情况下，“出错处理”指的是当应用系统发现它自己犯下一个错误时所采取的行动。但是，应该有选择地提出这类出错处理需求。我们的目的是开发出正确的系统，而不是用无休止的出错处理代码掩盖自己的错误。总之，对应用系统本身错误的检测应该仅限于系统的关键部分，而且应该尽可能少。,5.,接口需求,接口需求描述应用系统与它的环境通信的格式。常见的接口需求有：用户接口需求；硬件接口需求；软件接口需求；通信接口需求。,6.,约束,设计约束或实现约束描述在设计或实现应用系统时应遵守的限制条件。在需求分析阶段提出这类需求，并不是要取代设计,(,或实现,),过程，只是说明用户或环境强加给项目的限制条件。常见的约束有：精度；工具和语言约束；设计约束；应该使用的标准；应该使用的硬件平台。,7.,逆向需求,逆向需求说明软件系统不应该做什么。理论上有无限多个逆向需求，我们应该仅选取能澄清真实需求且可消除可能发生的误解的那些逆向需求。,8.,将来可能提出的要求,应该明确地列出那些虽然不属于当前系统开发范畴，但是据分析将来很可能会提出来的要求。这样做的目的是，在设计过程中对系统将来可能的扩充和修改预做准备，以便一旦确实需要时能比较容易地进行这种扩充和修改。,任何一个软件系统本质上都是信息处理系统，系统必须处理的信息和系统应该产生的信息在很大程度上决定了系统的面貌，对软件设计有深远影响，因此，必须分析系统的数据要求，这是软件需求分析的一个重要任务。分析系统的数据要求通常采用建立数据模型的方法,(,见,3.4,节,),。,3.1.2,分析系统的数据要求,复杂的数据由许多基本的数据元素组成，数据结构表示数据元素之间的逻辑关系。利用数据字典可以全面准确地定义数据，但是数据字典的缺点是不够形象直观。为了提高可理解性，常常利用图形工具辅助描绘数据结构。常用的图形工具有层次方框图和,Warnier,图，在本章第,3.7,节中将简要地介绍这两种图形工具。,软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化,(,见,3.5,节,),。,综合上述两项分析的结果可以导出系统的详细的逻辑模型，通常用数据流图、实体,-,联系图、状态转换图、数据字典和主要的处理算法描述这个逻辑模型。,3.1.3,导出系统的逻辑模型,根据在分析过程中获得的对系统的更深入更具体的了解，可以比较准确地估计系统的成本和进度，修正以前制定的开发计划。,3.1.4,修正系统开发计划,访谈是最早开始使用的获取用户需求的技术，也是迄今为止仍然广泛使用的需求分析技术。,访谈有两种基本形式，分别是正式的和非正式的访谈。正式访谈时，系统分析员将提出一些事先准备好的具体问题。在非正式访谈中，分析员将提出一些用户可以自由回答的开放性问题，以鼓励被访问人员说出自己的想法。,3.2,与用户沟通获取需求的方法,3.2.1,访谈,当需要调查大量人员的意见时，向被调查人分发调查表是一个十分有效的做法。经过仔细考虑写出的书面回答可能比被访者对问题的口头回答更准确。分析员仔细阅读收回的调查表，然后再有针对性地访问一些用户，以便向他们询问在分析调查表时发现的新问题。,在访问用户的过程中使用情景分析技术往往非常有效。所谓情景分析就是对用户将来使用目标系统解决某个具体问题的方法和结果进行分析。,情景分析技术的用处主要体现在下述两个方面：,(1),它能在某种程度上演示目标系统的行为，从而便于用户理解，而且还可能进一步揭示出一些分析员目前还不知道的需求。,(2),由于情景分析较易为用户所理解，使用这种技术能保证用户在需求分析过程中始终扮演一个积极主动的角色。需求分析的目标是获知用户的真实需求，而这一信息的惟一来源是用户，因此，让用户起积极主动的作用对需求分析工作获得成功是至关重要的。,软件系统本质上是信息处理系统，而任何信息处理系统的基本功能都是把输入数据转变成需要的输出信息。数据决定了需要的处理和算法，看来数据显然是需求分析的出发点。在可行性研究阶段许多实际的数据元素被忽略了，当时分析员还不需要考虑这些细节，现在是定义这些数据元素的时候了。,3.2.2,面向数据流自顶向下求精,结构化分析方法就是面向数据流自顶向下逐步求精进行需求分析的方法。通过可行性研究已经得出了目标系统的高层数据流图，需求分析的目标之一就是把数据流和数据存储定义到元素级。为了达到这个目标，通常从数据流图的输出端着手分析，这是因为系统的基本功能是产生这些输出，输出数据决定了系统必须具有的最基本的组成元素。,输出数据是由哪些元素组成的呢,?,通过调查访问不难搞清这个问题。那么，每个输出数据元素又是从哪里来的呢,?,既然它们是系统的输出，显然它们或者是从外面输入到系统中来的，或者是通过计算由系统中产生出来的。沿数据流图从输出端往输入端回溯，应该能够确定每个数据元素的来源，与此同时也就初步定义了有关的算法。但是，可行性研究阶段产生的是高层数据流图，许多具体的细节没有包括在里面，因此沿数据流图回溯时常常遇到下述问题：为了得到某个数据元素需要用到数据流图中目前还没有的数据元素，或者得出这个数据元素需要用的算法尚不完全清楚。,为了解决这些问题，往往需要向用户和其他有关人员请教，他们的回答使分析员对目标系统的认识更深入更具体了，系统中更多的数据元素被划分出来了，更多的算法被搞清楚了。通常把分析过程中得到的有关数据元素的信息记录在数据字典中，把对算法的简明描述记录在,IPO,图,(,见,3.7,节,),中。通过分析而补充的数据流、数据存储和处理，应该添加到数据流图的适当位置上。,必须请用户对上述分析过程中得出的结果仔细地复查，数据流图是帮助复查的极好工具。从输入端开始，分析员借助数据流图、数据字典和,IPO,图向用户解释输入数据是怎样一步一步地转变成输出数据的。这些解释集中反映了通过前面的分析工作分析员所获得的对目标系统的认识。这些认识正确吗,?,有没有遗漏,?,用户应该注意倾听分析员的报告，并及时纠正和补充分析员的认识。复查过程验证了已知的元素，补充了未知的元素，填补了文档中的空白。,反复进行上述分析过程，分析员越来越深入地定义了系统中的数据和系统应该完成的功能。为了追踪更详细的数据流，分析员应该把数据流图扩展到更低的层次。通过功能分解可以完成数据流图的细化。,对数据流图细化之后得到一组新的数据流图，不同的系统元素之间的关系变得更清楚了。对这组新数据流图的分析追踪可能产生新的问题，这些问题的答案可能又在数据字典中增加一些新条目，并且可能导致新的或精化的算法描述。随着分析过程的进展，经过问题和解答的反复循环，分析员越来越深入具体地定义了目标系统，最终得到对系统数据和功能要求的满意了解。图,3.1,粗略地概括了上述分析过程。,图,3.1,面向数据流自顶向下求精过程,使用传统的访谈或面向数据流自顶向下求精方法定义需求时，用户处于被动地位而且往往有意无意地与开发者区分“彼此”。由于不能像同一个团队的人那样齐心协力地识别和精化需求，这两种方法的效果有时并不理想。,为了解决上述问题，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术。这种方法提倡用户与开发者密切合作，共同标识问题，提出解决方案要素，商讨不同方案并指定基本需求。今天，简易的应用规格说明技术已经成为信息系统领域使用的主流技术。,3.2.3,简易的应用规格说明技术,使用简易的应用规格说明技术分析需求的典型过程如下：,首先进行初步的访谈，通过用户对基本问题的回答，初步确定待解决的问题的范围和解决方案。然后开发者和用户分别写出“产品需求”。选定会议的时间和地点，并选举一个负责主持会议的协调人。邀请开发者和用户双方组织的代表出席会议，并在开会前预先把写好的产品需求分发给每位与会者。,要求每位与会者在开会的前几天认真审查产品需求，并且列出作为系统环境组成部分的对象、系统将产生的对象以及系统为了完成自己的功能将使用的对象。此外，还要求每位与会者列出操作这些对象或与这些对象交互的服务,(,即处理或功能,),。最后还应该列出约束条件,(,例如，成本、规模、完成日期,),和性能标准,(,例如，速度、容量,),。并不期望每位与会者列出的内容都是毫无遗漏的，但是，希望能准确地表达出每个人对目标系统的认识。,会议开始后，讨论的第一个问题是，是否需要这个新产品，一旦大家都同意确实需要这个新产品，每位与会者就应该把他们在会前准备好的列表展示出来供大家讨论。可以把这些列表抄写在大纸上钉在墙上，或者写在白板上挂在墙上。理想的情况是，表中每一项都能单独移动，这样就能方便地删除或增添表项，或组合不同的列表。在这个阶段，严格禁止批评与争论。,在展示了每个人针对某个议题的列表之后，大家共同创建一张组合列表。在组合列表中消去了冗余项，加入了在展示过程中产生的新想法，但是并不删除任何实质性内容。在针对每个议题的组合列表都建立起来之后，由协调人主持讨论这些列表。组合列表将被缩短、加长或重新措辞，以便更准确地描述将被开发的产品。讨论的目标是，针对每个议题,(,对象、服务、约束和性能,),都创建出一张意见一致的列表。,一旦得出了意见一致的列表，就把与会者分成更小的小组，每个小组的工作目标是为每张列表中的项目制定小型规格说明。小型规格说明是对列表中包含的单词或短语的准确说明。,然后，每个小组都向全体与会者展示他们制定的小型规格说明，供大家讨论。通过讨论可能会增加或删除一些内容，也可能进一步做些精化工作。,在完成了小型规格说明之后，每个与会者都制定出产品的一整套确认标准，并把自己制定的标准提交会议讨论，以创建出意见一致的确认标准。最后，由一名或多名与会者根据会议成果起草完整的软件需求规格说明书。,简易的应用规格说明技术并不是解决需求分析阶段遇到的所有问题的“万能灵药”，但是，这种面向团队的需求收集方法确实有许多突出优点：开发者与用户不分彼此，齐心协力，密切合作；即时讨论并求精；有能导出规格说明的具体步骤。,正如第,1,章已经讲过的，快速建立软件原型是最准确、最有效、最强大的需求分析技术。快速原型就是快速建立起来的旨在演示目标系统主要功能的可运行的程序。构建原型的要点是，它应该实现用户看得见的功能,(,例如，屏幕显示或打印报表,),，省略目标系统的“隐含”功能,(,例如，修改文件,),。,3.2.4,快速建立软件原型,快速原型应该具备的第一个特性是“快速”。快速原型的目的是尽快向用户提供一个可在计算机上运行的目标系统的模型，以便使用户和开发者在目标系统应该“做什么”这个问题上尽可能快地达成共识。因此，原型的某些缺陷是可以忽略的，只要这些缺陷不严重地损害原型的功能，不会使用户对产品的行为产生误解，就不必管它们。,快速原型应该具备的第二个特性是“容易修改”。如果原型的第一版不是用户所需要的，就必须根据用户的意见迅速地修改它，构建出原型的第二版，以更好地满足用户需求。在实际开发软件产品时，原型的“修改,试用,反馈”过程可能重复多遍，如果修改耗时过多，势必延误软件开发时间。,为了快速地构建和修改原型，通常使用下述,3,种方法和工具：,(1),第四代技术,第四代技术包括众多数据库查询和报表语言、程序和应用系统生成器以及其他非常高级的非过程语言。第四代技术使得软件工程师能够快速地生成可执行的代码，它们是较理想的快速原型工具。,(2),可重用的软件构件,另外一种快速构建原型的方法，是使用一组已有的软件构件,(,也称为组件,),来装配,(,而不是从头构造,),原型。软件构件可以是数据结构,(,或数据库,),，或软件体系结构构件,(,即程序,),，或过程构件,(,即模块,),。必须把软件构件设计成能在不知其内部工作细节的条件下重用。,应该注意，现有的软件可以被用作“新的或改进的”产品的原型。,(3),形式化规格说明和原型环境,在过去的,20,多年中，人们已经研究出许多形式化规格说明语言和工具,(,参见第,4,章,),，用于替代自然语言规格说明技术。今天，形式化语言的倡导者正在开发交互式环境，以便可以调用自动工具把基于形式语言的规格说明翻译成可执行的程序代码，用户能够使用可执行的原型代码去进一步精化形式化的规格说明。,为了更好地理解复杂事物，人们常常采用建立事物模型的方法。所谓模型，就是为了理解事物而对事物做出的一种抽象，是对事物的一种无歧义的书面描述。通常，模型由一组图形符号和组织这些符号的规则组成。,3.3,分析建模与规格说明,3.3.1,分析建模,结构化分析实质上是一种创建模型的活动。为了开发出复杂的软件系统，系统分析员应该从不同角度抽象出目标系统的特性，使用精确的表示方法构造系统的模型，验证模型是否满足用户对目标系统的需求，并在设计过程中逐渐把和实现有关的细节加进模型中，直至最终用程序实现模型。,根据本章开头讲述的结构化分析准则，需求分析过程应该建立,3,种模型，它们分别是数据模型、功能模型和行为模型。,3.4,节将介绍的实体,-,联系图，描绘数据对象及数据对象之间的关系，是用于建立数据模型的图形。,2.4,节讲过的数据流图，描绘当数据在软件系统中移动时被变换的逻辑过程，指明系统具有的变换数据的功能，因此，数据流图是建立功能模型的基础。,3.6,节将介绍的状态转换图,(,简称为状态图,),，指明了作为外部事件结果的系统行为。为此，状态转换图描绘了系统的各种行为模式,(,称为“状态”,),和在不同状态间转换的方式。状态转换图是行为建模的基础。,通过需求分析除了创建分析模型之外，还应该写出软件需求规格说明书，它是需求分析阶段得出的最主要的文档。,通常用自然语言完整、准确、具体地描述系统的数据要求、功能需求、性能需求、可靠性和可用性要求、出错处理需求、接口需求、约束、逆向需求以及将来可能提出的要求。自然语言的规格说明具有容易书写、容易理解的优点，为大多数人所欢迎和采用。,3.3.2,软件需求规格说明,为了消除用自然语言书写的软件需求规格说明书中可能存在的不一致、歧义、含糊、不完整及抽象层次混乱等问题，有些人主张用形式化方法描述用户对软件系统的需求，第,4,章将简要地介绍形式化说明技术。,为了把用户的数据要求清楚、准确地描述出来，系统分析员通常建立一个概念性的数据模型,(,也称为信息模型,),。概念性数据模型是一种面向问题的数据模型，是按照用户的观点对数据建立的模型。它描述了从用户角度看到的数据，它反映了用户的现实环境，而且与在软件系统中的实现方法无关。,数据模型中包含,3,种相互关联的信息：数据对象、数据对象的属性及数据对象彼此间相互连接的关系。,3.4,实体,-,联系图,数据对象是对软件必须理解的复合信息的抽象。所谓复合信息是指具有一系列不同性质或属性的事物，仅有单个值的事物,(,例如，宽度,),不是数据对象。,数据对象可以是外部实体,(,例如，产生或使用信息的任何事物,),、事物,(,例如，报表,),、行为,(,例如，打电话,),、事件,(,例如，响警报,),、角色,(,例如，教师、学生,),、单位,(,例如，会计科,),、地点,(,例如，仓库,),或结构,(,例如，文件,),等。总之，可以由一组属性来定义的实体都可以被认为是数据对象。,3.4.1,数据对象,数据对象彼此间是有关联的，例如，教师“教”课程，学生“学”课程，教或学的关系表示教师和课程或学生和课程之间的一种特定的连接。,数据对象只封装了数据而没有对施加于数据上的操作的引用，这是数据对象与面向对象范型,(,参见本书第,9,章,),中的“类”或“对象”的显著区别。,属性定义了数据对象的性质。必须把一个或多个属性定义为“标识符”，也就是说，当我们希望找到数据对象的一个实例时，用标识符属性作为“关键字”,(,通常简称为“键”,),。,应该根据对所要解决的问题的理解，来确定特定数据对象的一组合适的属性。,3.4.2,属性,数据对象彼此之间相互连接的方式称为联系，也称为关系。联系可分为以下,3,种类型：,(1),一对一联系,(11),例如，一个部门有一个经理，而每个经理只在一个部门任职，则部门与经理的联系是一对一的。,(2),一对多联系,(1N),例如，某校教师与课程之间存在一对多的联系“教”，即每位教师可以教多门课程，但是每门课程只能由一位教师来教,(,见图,3.2),。,3.4.3,联系,图,3.2,某校教学管理,ER,图,(3),多对多联系,(MN),例如，图,3.2,表示学生与课程间的联系,(“,学”,),是多对多的，即一个学生可以学多门课程，而每门课程可以有多个学生来学。,联系也可能有属性。例如，学生“学”某门课程所取得的成绩，既不是学生的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学生又依赖于某门特定的课程，所以它是学生与课程之间的联系“学”的属性,(,见图,3.2),。,通常，使用实体,-,联系图,(entity-relationship diagram),来建立数据模型。可以把实体,-,联系图简称为,ER,图，相应地可把用,ER,图描绘的数据模型称为,ER,模型。,ER,图中包含了实体,(,即数据对象,),、关系和属性等,3,种基本成分，通常用矩形框代表实体，用连接相关实体的菱形框表示关系，用椭圆形或圆角矩形表示实体,(,或关系,),的属性，并用直线把实体,(,或关系,),与其属性连接起来。例如，图,3.2,是某学校教学管理的,ER,图。,3.4.4,实体,-,联系图的符号,人们通常就是用实体、联系和属性这,3,个概念来理解现实问题的，因此，,ER,模型比较接近人的习惯思维方式。此外，,ER,模型使用简单的图形符号表达系统分析员对问题域的理解，不熟悉计算机技术的用户也能理解它，因此，,ER,模型可以作为用户与分析员之间有效的交流工具。,软件系统经常使用各种长期保存的信息，这些信息通常以一定方式组织并存储在数据库或文件中，为减少数据冗余，避免出现插入异常或删除异常，简化修改数据的过程，通常需要把数据结构规范化。,3.5,数据规范化,通常用“范式,(normal forms)”,定义消除数据冗余的程度。第一范式,(1 NF),数据冗余程度最大，第五范式,(5 NF),数据冗余程度最小。但是，范式级别越高，存储同样数据就需要分解成更多张表，因此，“存储自身”的过程也就越复杂。第二，随着范式级别的提高，数据的存储结构与基于问题域的结构间的匹配程度也随之下降，因此，在需求变化时数据的稳定性较差。第三，范式级别提高则需要访问的表增多，因此性能,(,速度,),将下降。从实用角度看来，在大多数场合选用第三范式都比较恰当。,通常按照属性间的依赖情况区分规范化的程度。属性间依赖情况满足不同程度要求的为不同范式，满足最低要求的是第一范式，在第一范式中再进一步满足一些要求的为第二范式，其余依此类推。下面给出第一、第二和第三范式的定义：,(1),第一范式每个属性值都必须是原子值，即仅仅是一个简单值而不含内部结构。,(2),第二范式满足第一范式条件，而且每个非关键字属性都由整个关键字决定,(,而不是由关键字的一部分来决定,),。,(3),第三范式符合第二范式的条件，每个非关键字属性都仅由关键字决定，而且一个非关键字属性不能仅仅是对另一个非关键字属性的进一步描述,(,即一个非关键字属性值不依赖于另一个非关键字属性值,),。,根据本章开头讲的结构化分析的第,3,条准则，在需求分析过程中应该建立起软件系统的行为模型。状态转换图,(,简称为状态图,),通过描绘系统的状态及引起系统状态转换的事件，来表示系统的行为。此外，状态图还指明了作为特定事件的结果系统将做哪些动作,(,例如，处理数据,),。因此，状态图提供了行为建模机制，可以满足第,3,条分析准则的要求。,3.6,状态转换图,状态是任何可以被观察到的系统行为模式，一个状态代表系统的一种行为模式。状态规定了系统对事件的响应方式。系统对事件的响应，既可以是做一个,(,或一系列,),动作，也可以是仅仅改变系统本身的状态，还可以是既改变状态又做动作。,在状态图中定义的状态主要有：初态,(,即初始状态,),、终态,(,即最终状态,),和中间状态。在一张状态图中只能有一个初态，而终态则可以有,0,至多个。,3.6.1,状态,状态图既可以表示系统循环运行过程，也可以表示系统单程生命期。当描绘循环运行过程时，通常并不关心循环是怎样启动的。当描绘单程生命期时，需要标明初始状态,(,系统启动时进入初始状态,),和最终状态,(,系统运行结束时到达最终状态,),。,事件是在某个特定时刻发生的事情，它是对引起系统做动作或,(,和,),从一个状态转换到另一个状态的外界事件的抽象。例如，内部时钟表明某个规定的时间段已经过去，用户移动或点击鼠标等都是事件。简而言之，事件就是引起系统做动作或,(,和,),转换状态的控制信息。,3.6.2,事件,在状态图中，初态用实心圆表示，终态用一对同心圆,(,内圆为实心圆,),表示。,中间状态用圆角矩形表示，可以用两条水平横线把它分成上、中、下,3,个部分。上面部分为状态的名称，这部分是必须有的；中间部分为状态变量的名字和值，这部分是可选的；下面部分是活动表，这部分也是可选的。,活动表的语法格式如下：,事件名,(,参数表,)/,动作表达式,3.6.3,符号,其中，“事件名”可以是任何事件的名称。在活动表中经常使用下述,3,种标准事件：,entry,，,exit,和,do,。,entry,事件指定进入该状态的动作，,exit,事件指定退出该状态的动作，而,do,事件则指定在该状态下的动作。需要时可以为事件指定参数表。活动表中的动作表达式描述应做的具体动作。,状态图中两个状态之间带箭头的连线称为状态转换，箭头指明了转换方向。状态变迁通常是由事件触发的，在这种情况下应在表示状态转换的箭头线上标出触发转换的事件表达式；如果在箭头线上未标明事件，则表示在源状态的内部活动执行完之后自动触发转换。,事件表达式的语法如下：,事件说明守卫条件动作表达式,其中，,事件说明的语法为：事件名,(,参数表,),。,守卫条件是一个布尔表达式。如果同时使用事件说明和守卫条件，则当且仅当事件发生且布尔表达式为真时，状态转换才发生。如果只有守卫条件没有事件说明，则只要守卫条件为真状态转换就发生。,动作表达式是一个过程表达式，当状态转换开始时执行该表达式。,图,3.3,给出了状态图中使用的主要符号。,图,3.3,状态图中使用的主要符号,为了具体说明怎样用状态图建立系统的行为模型，下面举一个例子。图,3.4,（见书,57,页）是人们非常熟悉的电话系统的状态图。,图中表明，没有人打电话时电话处于闲置状态；有人拿起听筒则进入拨号音状态，到达这个状态后，电话的行为是响起拨号音并计时；这时如果拿起听筒的人改变主意不想打了，他把听筒放下,(,挂断,),，电话重又回到闲置状态；如果拿起听筒很长时间不拨号,(,超时,),，则进入超时状态；,。,3.6.4,例子,层次方框图用树形结构的一系列多层次的矩形框描绘数据的层次结构。树形结构的顶层是一个单独的矩形框，它代表完整的数据结构，下面的各层矩形框代表这个数据的子集，最底层的各个框代表组成这个数据的实际数据元素,(,不能再分割的元素,),。,例如，描绘一家计算机公司全部产品的数据结构可以用图,3.5,中的层次方框图表示。,3.7,其他图形工具,3.7.1,层次方框图,图,3.5,层次方框图的一个例子,随着结构的精细化，层次方框图对数据结构也描绘得越来越详细，这种模式非常适合于需求分析阶段的需要。系统分析员从对顶层信息的分类开始，沿图中每条路径反复细化，直到确定了数据结构的全部细节时为止。,法国计算机科学家,Warnier,提出了表示信息层次结构的另外一种图形工具。和层次方框图类似，,Warnier,图也用树形结构描绘信息，但是这种图形工具比层次方框图提供了更丰富的描绘手段。,用,Warnier,图可以表明信息的逻辑组织，也就是说，它可以指出一类信息或一个信息元素是重复出现的，也可以表示特定信息在某一类信息中是有条件地出现的。因为重复和条件约束是说明软件处理过程的基础，所以很容易把,Warnier,图转变成软件设计的工具。,3.7.2 Warnier,图,图,3.6,是用,Warnier,图描绘一类软件产品的例子，它说明了这种图形工具的用法。,图,3.6,中的,Warnier,图表示一种软件产品要么是系统软件要么是应用软件。系统软件中有,P1,种操作系统，,P2,种编译程序，此外还有软件工具。软件工具是系统软件的一种，它又可以进一步细分为编辑程序、测试驱动程序和设计辅助工具，图中标出了每种软件工具的数量。,图,3.6 Warnier,图的一个例子,IPO,图是输入、处理、输出图的简称，它是美国,IBM,公司发展完善起来的一种图形工具，能够方便地描绘输入数据、对数据的处理和输出数据之间的关系。,3.7.3 IPO,图,IPO,图使用的基本符号既少又简单，因此很容易学会使用这种图形工具。它的基本形式是在左边的框中列出有关的输入数据，在中间的框内列出主要的处理，在右边的框内列出产生的输出数据。处理框中列出处理的次序暗示了执行的顺序，但是用这些基本符号还不足以精确描述执行处理的详细情况。在,IPO,图中还用类似向量符号的粗大箭头清楚地指出数据通信的情况。图,3.7,是一个主文件更新的例子，通过这个例子不难了解,IPO,图的用法。,图,3.7 IPO,图的一个例子图,本书建议使用一种改进的,IPO,图,(,也称为,IPO,表,),，这种图中包含某些附加的信息，在软件设计过程中将比原始的,IPO,图更有用。如图,3.8,所示。在需求分析阶段可以使用,IPO,图简略地描述系统的主要算法,(,即数据流图中各个处理的基本算法,),。当然，在需求分析阶段，,IPO,图中的许多附加信息暂时还不具备，但是在软件设计阶段可以进一步补充修正这些图，作为设计阶段的文档。这正是在需求分析阶段用,IPO,图作为描述算法的工具的重要优点。,图,3.8,改进的,IPO,图的形式,需求分析阶段的工作结果是开发软件系统的重要基础，大量统计数字表明，软件系统中,15%,的错误起源于错误的需求。为了提高软件质量，确保软件开发成功，降低软件开发成本，一旦对目标系统提出一组要求之后，必须严格验证这些需求的正确性。一般说来，应该从下述,4,个方面进行验证：,3.8,验证软件需求,3.8.1,从哪些方面验证软件需求的正确性,(1),一致性所有需求必须是一致的，任何一条需求不能和其他需求互相矛盾。,(2),完整性需求必须是完整的，规格说明书应该包括用户需要的每一个功能或性能。,(3),现实性指定的需求应该是用现有的硬件技术和软件技术基本上可以实现的。对硬件技术的进步可以做些预测，对软件技术的进步则很难做出预测，只能从现有技术水平出发判断需求的现实性。,(4),有效性必须证明需求是正确有效的，确实能解决用户面对的问题。,1.,验证需求的一致性,当需求分析的结果是用自然语言书写的时候，除了靠人工技术审查验证软件系统规格说明书的正确性之外，目前还没有其他更好的“测试”方法。但是，这种非形式化的规格说明书是难于验证的，特别在目标系统规模庞大、规格说明书篇幅很长的时候，人工审查的效果是没有保证的，冗余、遗漏和不一致等问题可能没被发现而继续保留下来，以致软件开发工作不能在正确的基础上顺利进行。,3.8.2,验证软件需求的方法,为了克服上述困难，人们提出了形式化的描述软件需求的方法。当软件需求规格说明书是用形式化的需求陈述语言书写的时候，可以用软件工具验证需求的一致性,(,见,3.8.3,节,),，从而能有效地保证软件需求的一致性。,2.,验证需求的现实性,为了验证需求的现实性，分析员应该参照以往开发类似系统的经验，分析用现有的软、硬件技术实现目标系统的可能性。必要的时候应该采用仿真或性能模拟技术，辅助分析软件需求规格说明书的现实性。,3.,验证需求的完整性和有效性,只有目标系统的用户才真正知道软件需求规格说明书是否完整、准确地描述了他们的需求。因此，检验需求的完整性，特别是证明系统确实满足用户的实际需要,(,即，需求的有效性,),，只有在用户的密切合作下才能完成。然而许多用户并不能清楚地认识到他们的需要,(,特别在要开发的系统是全新的，以前没有使用类似系统的经验时，情况更是如此,),，不能有效地比较陈述需求的语句和实际需要的功能。只有当他们有某种工作着的软件系统可以实际使用和评价时，才能完整确切地提出他们的需要。,理想的做法是先根据需求分析的结果开发出一个软件系统，请用户试用一段时间以便能认识到他们的实际需要是什么，在此基础上再写出正式的“正确的”规格说明书。但是，这种做法将使软件成本增加一倍，因此实际上几乎不可能采用这种方法。使用原型系统是一个比较现实的替代方法，开发原型系统所需要的成本和时间可以大大少于开发实际系统所需要的。用户通过试用原型系统，也能获得许多宝贵的经验，从而可以提出更符合实际的要求。,使用原型系统的目的，通常是显示目标系统的主要功能而不是性能。为了达到这个目的可以使用本章,3.2.4,小节介绍的方法快速建立原型系统，并且可以适当降低对接口、可靠性和程序质量的要求，此外还可以省掉许多文档资料方面的工作，从而可以大大降低原型系统的开发成本。,为了更有效地保证软件需求的正确性，特别是为了保证需求的一致性，需要有适当的软件工具支持需求分析工作。这类软件工具应该满足下列要求：,(1),必须有形式化的语法,(,或表,),，因此可以用计算机自动处理使用这种语法说明的内容；,(2),使用这个软件工具能够导出详细的文档；,(3),必须提供分析,(,测试,),规格说明书的不一致性和冗余性的手段，并且应该能够产生一组报告指明对完整性分析的结果；,3.8.3,用于需求分析的软件工具,(4),使用这个软件工具之后，应该能够改进通信状况。,作为需求工程方法学的一部分，在,1977,年设计完成了,RSL(,需求陈述语言,),。,RSL,中的语句是计算机可以处理的，处理以后把从这些语句中得到的信息集中存放在一个称为,ASSM,（抽象系统语义模型）的数据库中。有一组软件工具处理,ASSM,数据库中的信息以产生出用,PASCAL,语言书写的模拟程序，从而可以检验需求的一致性、完整性和现实性。,1977,年美国密执安大学开发了,PSL/PSA(,问题陈述语言,/,问题陈述分析程序,),系统。这个系统是,CADSAT,（计算机辅助设计和规格说明分析工具）的一部分，它的基本结构类似于,RSL,。其中,PSL,是用来描述系统的形式语言，,PSA,是处理,PSL,描述的分析程序。用,PSL,描述的系统属性放在一个数据库中。一旦建立起数据库之后即可增加信息、删除信息或修改信息，并且保持信息的一致性。,PSA,对数据库进行处理以产生各种报告，测试不一致性或遗漏，并且生成文档资料。,PSL/PSA,系统的功能主要有下述,4,种：,(1),描述任何应用领域的信息系统；,(2),创建一个数据库保存对该信息系统的描述符；,(3),对描述符施加增加、删除和更改等操作；,(4),产生格式化的文档和关于规格说明书的各种分析报告。,PSL/PSA,系统用描述符从系统信息流、系统结构、数据结构、数据导出、系统规模、系统动态、系统性质和项目管理等,8,个方面描述信息系统。,一旦用,PSL,对系统做了完整描述，就可以调用,PSA,产生一组分析报告，其中包括所有修改规格说明数据库的记录，用各种形式描述数据库信息的参照报告,(,包括图形形式的描述,),，关于项目管理信息的总结报告，以及评价数据库特性的分析报告。,借助,PSL/PSA,系统可以边对目标系统进行自顶向下的逐层分解，边将需求分析过程中遇到的数据流、文件、处理等对象用,PSL,描述出来并输入到,PSL/PSA,系统中。,PSA,将对输入信息作一致性和完整性检查，并且保存这些描述信息。,PSL/PSA,系统的主要优点是它改进了文档质量，能保证文档具有完整性、一致性和无二义性，从而可以减少管理和维护的费用。数据存放在数据库中，便于增加、删除和更改，这也是它的一个优点。,传统软件工程方法学使用结构化分析技术，完成分析用户需求的工作。需求分析是发现、求精、建模、规格说明和复审的过程。需求分析的第一步是进一步了解用户当前所处的情况，发现用户所面临的问题和对目标系统的基本需求；接下来应该与用户深入交流，对用户的基本需求反复细化逐步求精，以得出对目标系统的完整、准确和具体的需求。具体地说，应该确定系统必须具有的功能、性能、可靠性和可用性，必须实现的出错处理需求、接口需求和逆向需求，必须满足的约束条件，并且预测系统的发展前景。,3.9,小结,为了详细地了解并正确地理解用户的需求，必须使用适当方法与用户沟通。访谈是与用户通信的历史悠久的技术，至今仍被许多系统分析员采用。从可行性研究阶段得到的数据流图出发，在用户的协助下面向数据流自顶向下逐步求精，也是与用户沟通获取需求的一个有效的方法。为了促使用户与分析员齐心协力共同分析需求，人们研究出一种面向团队的需求收集法，称为简易的应用规格说明技术，现在这种技术已经成为信息系统领域使用的主流技术。实践表明，快速建立软件原型是最准确、最有效和最强大的需求分析技术。,快速原型应该具备的基本特性是“快速”和“容易修改”，因此，必须用适当的软件工具支持快速原型技术。通常使用第四代技术、可重用的软件构件及形式化规格说明与原型环境，快速地构建和修改原型。,为了更好地理解问题，人们常常采用建立模型的方法，结构化分析实质上就是一种建模活动，在需求分析阶段通常建立数据模型、功能模型和行为模型。,除了创建分析模型之外，在需求分析阶段还应该写出软件需求规格说明书，经过严格评审并得到用户确认之后，作为这个阶段的最终成果。通常主要从一致性、完整性、现实性和有效性等,4,个方面复审软件需求规格说明书。,多数人习惯于使用实体,-,联系图建立数据模型，使用数据流图建立功能模型，使用状态图建立行为模型。读者应该掌握这些图形的基本符号，并能正确地使用这些符号建立软件系统的模型。,数据字典描述在数据模型、功能模型和行为模型中出现的数据对象及控制信息的特性，给出它们的准确定义。因此，数据字典成为把,3,种分析模型粘合在一起的“粘合剂”，是分析模型的“核心”。为了提高可理解性，还可以用层次方框图或,Warnier,图等图形工具辅助描绘系统中的数据结构。为了减少冗余、简化修改步骤，往