软件工程与开发技术(西电第二版)第3章-软件需求分析与建模课件.ppt

1、第3章 软件需求分析与建模 第3章 软件需求分析与建模 3.1 需求分析需求分析 3.2 数据建模数据建模 3.3 功能建模功能建模 3.4 行为建模行为建模 3.5 数据字典数据字典 3.6 结构化需求分析的若干技术结构化需求分析的若干技术3.7 验证软件需求验证软件需求 3.8 小结小结第3章 软件需求分析与建模 3.1 3.1 需需 求求 分分 析析3.1.1 3.1.1 需求分析的任务需求分析的任务 需求分析的主要任务就是要通过软件开发人员与用户的交流和讨论，准确地获取用户对系统的具体要求。需求分析中任何的含混不清或微小的遗漏都可能会造成系统开发中的重大问题甚至导致失败。在正确理解用户

2、需求的前提下，软件开发人员还需要将这些需求准确地以文档的形式表达出来，作为设计阶段的依据。需求分析阶段结束时需要提交的主要文档是软件规格说明书。第3章 软件需求分析与建模 由于需求分析研究的对象是用户对开发项目的要求，在实现这一阶段任务时必须要注意两个问题。问题之一在于：一个项目的参与者既包括软件设计开发人员，又包括用户，他们之间交流的难题会给软件的开发留下隐患。用户往往在软件交付使用时，才会发现系统存在的一系列问题。这就要求双方必须在需求分析过程中加强沟通和协调。一方面，软件设计人员应尽量使用通俗的语言与用户进行交流；另一方面，用户应积极主动地配合软件设计人员的工作。问题之二在于：为了保证需

3、求阶段能够提出完整、准确的系统逻辑模型，开发人员必须花费足够的时间，全面了解用户的需要，绝不能在需求模糊的情况下仓促进行软件的设计和编程。根据国外的统计资料表明，在典型环境下开发软件，需求分析阶段的工作量大约要占到整个系统开发工作量的20%左右。第3章 软件需求分析与建模 用户对系统的需求通常可分为如下两类：(1)功能性需求：主要说明了待开发系统在功能上实际应做到什么，是用户最主要的需求。通常包括系统的输入、系统能完成的功能、系统的输出及其他反应。(2)非功能性需求：从各个角度对所考虑的可能的解决方案的约束和限制。主要包括：过程需求(如交付需求、实现方法需求等)、产品需求(如可靠性需求、可移植

4、性需求、安全保密性需求等)和外部需求(如法规需求、费用需求等)等。第3章 软件需求分析与建模 3.1.2 3.1.2 需求分析的步骤需求分析的步骤 需求分析阶段的工作，大致可分为如下几个步骤进行：(1)通过调查研究，获取用户的需求。软件开发人员只有通过认真细致的调查研究，才能获得进行系统分析的原始资料。需求信息的获取可来源于阅读描述系统需求的用户文档；对相关软件、技术的市场调查；对管理部门、用户的访问咨询；对工作现场的实际考察等。第3章 软件需求分析与建模 (2)去除非本质因素，确定系统的真正需求。对于获取的原始需求，软件开发人员需要根据掌握的专业知识，运用抽象的逻辑思维，找出需求间的内在联系

5、和矛盾，去除需求中不合理和非本质的部分，确定软件系统的真正需求。(3)描述需求，建立系统的逻辑模型。对于确定的系统需求，软件开发人员要通过现有的需求分析方法及工具对其进行清晰、准确的描述，建立无二义性的、完整的系统逻辑模型。第3章 软件需求分析与建模 (4)书写需求说明书，进行需求复审。需求阶段应提交的主要文档包括需求规格说明书、初步的用户手册和修正后的开发计划。其中，需求规格说明书是对分析阶段主要成果的综合描述，是该阶段最重要的技术文档。为了保证软件开发的质量，对需求分析阶段的工作要按照严格的规范进行复审，从不同的技术角度对该阶段工作做出综合性的评价。复审即要有用户参加，也要有管理部门和软件

6、开发人员参加。第3章 软件需求分析与建模 3.1.3 3.1.3 需求分析的原则需求分析的原则 目前存在着许多需求分析的方法，虽然各种方法都有其独特的描述方法，但不论采用何种方法，需求分析都必须遵循以下基本原则：(1)能够表达和理解问题的数据域和功能域。所有软件开发的最终目的都是为了解决数据处理的问题，数据处理的本质就是将一种形式的数据转换成另一种形式的数据，即通过进行一系列加工将输入的原始数据转换为所需的结果数据。需求分析阶段必须明确系统中应具备的每一个加工、加工的处理对象和由加工所引起的数据形式的变化。第3章 软件需求分析与建模 (2)能够将复杂问题分解化简。为了便于问题的解决和实现，在需

7、求分析过程中需要对于原本复杂的问题按照某种合适的方式进行分解(对功能域和数据域均可)。分解可以是同一层次上的横向分解，也可以是多层上的纵向分解。每一步分解都是在原有基础上对系统的细化，使系统的理解和实现变得较为容易。第3章 软件需求分析与建模 (3)能够给出系统的逻辑表示和物理表示。系统需求的逻辑表示用于指明系统所要达到的功能要求和需要处理的数据，不涉及实现的细节。系统需求的物理表示用于指明处理功能和数据结构的实际表现形式，通常由系统中的设备决定。如处理数据的来源，某些软件可能由终端输入，另一些软件可能由特定设备提供。给出系统的逻辑表示和物理表示对满足系统处理需求所提出的逻辑限制条件和系统中其

8、他成分提出的物理限制是必不可少的。第3章 软件需求分析与建模 3.2 3.2 数数 据据 建建 模模3.2.1 3.2.1 实体模型实体模型 1.1.实体模型的概念实体模型的概念 对于一个软件系统来说，所涉及的数据成千上万，如何对这些复杂数据及其之间的关系进行分析并将它们以最优的方式组织起来，对软件开发的成败起着非常重要的作用。第3章 软件需求分析与建模 E-R(Entity-Relation)方法，即实体联系方法是目前最常用的数据建模方法，可以用于在需求分析阶段清晰地表达目标系统中数据之间的联系及其组织方式，建立系统的实体数据模型(E-R模型)。实体模型是一种面向问题的概念数据模型，是按照用

9、户的观点对系统的数据和信息进行建模的，因此它与软件系统中的实现方法，如数据结构、存取路径、存取效率等无关。实体模型可以根据需要在软件实现时转换成各种不同数据库管理系统所支持的数据物理模型。实体模型由实体、联系和属性三个基本成分组成。第3章 软件需求分析与建模 (1)实体：指客观世界存在的且可以相互区分的事物。实体可以是人，也可以是物，还可以是抽象概念。如职工、计算机、产品都是实体。(2)属性：有时也称性质，是指实体某一方面的特征。一个实体通常由多个属性值组成。如学生实体具有学号、姓名、专业、年级等属性。(3)联系：指实体之间的相互关系。实体之间的联系可主要划分为三类：一对一(1:1)、一对多(

10、1:n)和多对多(m:n)。联系也可以具有属性。为了便于实现，在进行数据库设计时通常将多对多的联系转换为一对多的联系，如图4.1所示。第3章 软件需求分析与建模 图3.1 学生和课程之间的E-R模型(a)学生和课程之间的多对多联系E-R模型；(b)将多对多联系转换为一对多联系E-R模型第3章 软件需求分析与建模 2.2.实体实体-模型中的基本符号模型中的基本符号表表3.1 E-R3.1 E-R模型中的基本符号模型中的基本符号符号含 义表示实体表示实体间的联系，与实体间的连线上需用数字标明具体的对应关系表示与实体有关的属性用于实体、属性及联系的连接第3章 软件需求分析与建模 3.3.实体实体-模

11、型的建立模型的建立 要建立系统的实体模型，通常可按如下步骤进行：(1)对系统的数据域和功能域进行分析，确定系统中所涉及的实体。例如，在图3.2所示的工资计算系统中，单位对职工的工作情况进行考勤，根据出勤结果、基本工资档案、奖金及扣款计算职工的实发工资。因此，工资系统中所涉及的实体就包括职工、出勤、奖励和扣款。第3章 软件需求分析与建模 图3.2 工资计算系统的E-R模型第3章 软件需求分析与建模 (2)确定系统中各实体之间的联系。如工资计算系统中，一名职工一个月只有一条出勤记录，因此职工和出勤两个实体之间是一对一的联系；一名职工在一个月中对应着多项扣款，如水电费、缺勤扣款、个人所得税等，因此职

12、工和扣款之间是一对多的联系；同理，一名职工在一个月中可以获得多项奖励，因此职工和奖金之间也是一对多的联系。第3章 软件需求分析与建模 (3)确定各实体及联系的属性。例如，工资计算系统的职工实体具有职工号、性别、职称、年龄、部门、基本工资等属性。目前，最常用的数据库模型是关系模型，它是通过一张二维表来表示和处理实体集合和属性关系的数据库系统方法。在关系数据库中，为了避免出现数据冗余、二义性的问题，方便数据库的各种操作，二维表必须满足以下的规范化约束条件：第3章 软件需求分析与建模 (1)表格中的每个信息项必须是一个不可分割的数据项。(2)表格每一列中所有信息项必须是同类型的数据，各列在表中的次序

13、任意，每列对应一个惟一的名字。(3)表格中每一行的数据各不相同，各行在表中的次序任意。第3章 软件需求分析与建模 3.2.2 3.2.2 数据建模的其他图形工具数据建模的其他图形工具 1.1.层次方框图层次方框图 层次方框图通过树型结构的一系列多层次的矩形框描述复杂数据的层次结构。树型结构顶端的矩形框只有一个，用于代表完整的数据结构。下面各层的矩形框是对完整数据结构的逐步分解和细化得到的数据子集；底层的矩形框代表组成该数据结构的基本元素，是数据的最小单位，不可再分割。层次方框图非常适合描述自顶向下的需求分析方法中数据的层次关系。系统分析员可以从对顶层信息的分类开始，沿着层次图中的每条路径逐步细

14、化，直到确定了数据结构的全部细节为止。例如，某单位职工的实发工资由应发工资和扣款两部分组成，每部分又可进一步细分。如应发工资又可分为基本工资和奖金；基本工资又可分为国家工资、津贴、补贴；奖金也可分为出勤奖和业绩奖；津贴和补贴还可以再进一步地细分。实发工资的层次方框图如图3.3所示。第3章 软件需求分析与建模 图3.3 某单位职工实发工资的层次方框图实发工资国家津贴职务津贴交通补贴部门补贴其他补贴补贴津贴国家工资基本工资出勤奖业绩奖奖金应发工资扣款缺勤扣款水电扣款个人所得税扣款第3章 软件需求分析与建模 2.2.WarnierWarnier图图 Warnier图是法国科学家Warnier提出的另

15、一种描述数据层次结构的图形工具。与层次方框图类似，Warnier图也采用了树型结构表示数据，但与层次方框图相比，Warnier图对数据的描绘手段更加丰富。利用Warnier图可以清楚地表明数据的逻辑结构中某类信息的重复出现及某些特定信息出现的条件约束，因此，Warnier图可以较为容易地转变成软件设计的工具。第3章 软件需求分析与建模 在Warnier图中，使用大括号来区分数据结构的层次。一个大括号内的所有名字都属于同一类信息；异或符号“?”用于表明一类信息或一个数据元素在一定条件下出现，而且在这个符号上、下方的两个名字所代表的数据只能出现一个。在一个名字下面或右边的圆括号中出现的数字指明了这

16、个名字所代表的信息类或数据元素在该数据结构中重复出现的次数。例如，某计算机公司的一种软件产品要么是系统软件，要么是应用软件；系统软件中有k1种操作系统、k2种编译程序，此外还有工具软件；工具软件进一步又可划分为编辑程序、测试工具和辅助设计工具，它们各自的数量分别为j1、j2和j3。描绘这种软件产品的Warnier 图如图3.4所示。第3章 软件需求分析与建模 图3.4 描绘一种软件产品的Warnier图第3章 软件需求分析与建模 3.3 3.3 功功 能能 建建 模模 在需求分析阶段，数据流(也称信息流)是系统分析的基础。所谓数据流，形象地说就是系统中“流动的数据结构”。数据流图(DFD，Da

17、ta Flow Diagram)是描述软件系统中数据处理过程的一种有力的图形工具。数据流图从数据传递和加工的角度出发，刻画数据流从输入到输出的移动和变换过程。由于它能够清晰地反映系统必须完成的逻辑功能，所以它已经成为需求分析阶段中功能建模最常用的工具。第3章 软件需求分析与建模 3.3.1 3.3.1 数据流图的基本符号数据流图的基本符号表表3.2 3.2 数据流图中的基本符号数据流图中的基本符号或或或符 号含 义数据的源点或终点数据流数据存储加工第3章 软件需求分析与建模 1.1.数据的源点或终点数据的源点或终点 数据的源点或终点用于反映数据流图与外部实体之间的联系，表示图中的输入数据来自哪

18、里或处理结果送向何处。如图3.5中的人事部门、后勤部门是工资系统中数据的源点，而职工和银行则是工资系统中数据的终点。第3章 软件需求分析与建模 2.2.数据流数据流 数据流是数据在系统中(包括数据处理之间、数据处理和数据存储之间以及数据处理和数据的源点或终点之间)的传送通道，数据流符号的箭头指明了数据的流动方向。如图3.5中的出勤表、业绩表、水电扣款表、工资条及工资存款清单等均为数据流。在数据流图中，除了连接加工和数据存储的数据流以外，其他的数据流在图中都对应一个惟一的名字。第3章 软件需求分析与建模 图3.5 工资计算系统的顶层(0层)数据流图第3章 软件需求分析与建模 3.3.加工加工 加

19、工也称为数据处理，是对系统中的数据流进行的某些操作或变换。图中每个加工都要有对应的名称，最常见的名称是由一个表明具体动作的动词和一个表明处理对象的名词构成的，如计算应发工资、打印工资清单等。4.4.数据存储数据存储 在数据流图中用于保存数据的数据文件被称为数据存储，它可以是数据库文件或任何其他形式的数据组织。流向数据存储的数据流可理解为向文件写入数据或对文件进行查询，流出数据存储的数据流可理解为从文件中读取数据或得到查询结果。第3章 软件需求分析与建模 3.3.2 3.3.2 数据流与加工之间的关系数据流与加工之间的关系 在数据流图中，可以有两个以上的数据流进入同一个加工，也可以有两个以上的数

20、据流从同一个加工中流出，这样的多个数据流之间往往存在一定的关系。为了表示这些数据流之间的关系，需要在数据流图中给这些数据流对应的加工加上一定的标记符号。在表3.3中列出了加工中常见的几种关系的表示方法。(表中以从加工流入或流出两个数据流为例)。第3章 软件需求分析与建模 表表3.3 3.3 加工中常见关系的符号表示加工中常见关系的符号表示T*T*T+T+TT符 号含 义由数据A和B共同变换为数据C由数据A变换为数据B和数据C由数据A或B，或者数据A和B共同变换为数据C由数据A变换为数据B或C，或者同时变换为数据B和C由数据A或B其中之一变换为数据C由数据A变换为数据B或C其中之一第3章 软件需

21、求分析与建模 3.3.3 3.3.3 数据流模型的建立方法数据流模型的建立方法 对于一个复杂的系统来说，可能存在着几十个甚至成百上千个加工，若要在一个数据流图中清楚地描述出整个系统加工的过程是很困难的，而采用对数据流图进行分层的方法则可以很好地解决这个问题。按照结构化分析方法中“自顶向下，逐步分解”的思想，可以先将整个系统看作是一个加工，它的输入数据和输出数据表明了系统和外部环境的接口，从而首先画出系统的顶层数据流图。为了能够清楚地表明系统加工的详细过程，接着从顶层数据流图出发，逐层地对系统进行分解。每分解一次，系统中加工的数量就随之增加，每个加工的功能描述也越来越具体。重复这种分解，直至得到

22、系统的底层数据流图。底层数据流图中的所有加工都应是不可再分解的、最简单的“原子加工”。通过分解过程中得到的这一组分层数据流图(由顶层、中间层和底层数据流图共同构成)就可以十分清晰地描述出整个系统所有加工的详细情况。第3章 软件需求分析与建模 下面以某单位工资管理系统为例，来介绍一下分层数据流模型的建立方法。1.1.建立顶层数据流图建立顶层数据流图 任何系统的顶层数据流图都只有一个，用于反映目标系统所要实现的功能及与外部环境的接口。顶层数据流图中只有一个代表整个系统的加工，数据的源点和终点对应着系统的外部实体，表明了系统输入数据的来源和输出数据的去向。工资管理系统的顶层数据流图如图3.5所示。第

23、3章 软件需求分析与建模 2.2.数据流图的分层细化数据流图的分层细化 首先按照系统的功能，对顶层数据流图进行分解，生成第一层数据流图。如例子中的工资计算系统可划分为计算工资、打印工资清单和工资转存三个加工。其中，计算工资完成单位职工工资计算，生成工资清单的功能；打印工资清单完成工资条的打印功能；工资转存完成生成职工工资存款清单并将其发送到银行的功能。对划分得到的加工应进行编号，如图3.6中工资计算的编号为1，打印工资清单的编号为2，工资转存的编号为3。加工之间的数据流也应在数据流图中标明，如图3.6中计算工资将单位职工的实发工资表传送给工资转存。此外，在标出数据流和划分加工的同时，还要在图中

24、画出涉及的数据存储。第3章 软件需求分析与建模 图3.6 工资计算系统第一层数据流图第3章 软件需求分析与建模 对第一层数据流图中的加工继续分解，则可得到第二层数据流图，如图3.7所示。对分解得到的加工进行编号，以反映出它与上层数据流图之间的关系，如对第一层数据流图中的计算工资分解得到的数据流图中的加工的编号分别为1.11.4。若数据流图中的加工还可继续细化，则重复以上分解过程，直到获得系统的底层数据流图。工资计算系统的第三层数据流图如图3.8所示。第3章 软件需求分析与建模 图3.7 工资计算系统的第二层数据流图(a)“计算工资”子数据流图；(b)“工资转存”子数据流图第3章 软件需求分析与

25、建模 图3.8 工资计算系统的第三层数据流图人事部门1.1.2计算业绩奖出勤表业绩表请假、旷工时数出勤时数1.1.3计算出勤奖1.1.4计算缺勤扣款业绩奖奖惩条例F1缺勤扣款表1.1.5计算各项奖金之和奖金发放表1.1.1统计出勤、请假及旷工时数出勤奖1.2.1计算各项基本数据之和1.2.2计算工资奖金之和工资档案F2应发工资表奖金发放表基本工资第3章 软件需求分析与建模 3.3.4 3.3.4 建立数据流模型的原则建立数据流模型的原则 建立数据流模型要遵循以下的原则：(1)每个加工至少应有一个输入数据流(反映被处理数据的来源)和一个输出数据流(反映加工的结果)。(2)数据流图中各构成元素的名

26、称必须具有明确的含义且能够代表对应元素的内容或功能。(3)对数据流图中某个加工进行细化生成的下层数据流图，称为其上层图的子图。应保证分层数据流图中任意对应的父图和子图的输入/输出数据保持一致。第3章 软件需求分析与建模 (4)在数据流图中，应按照层次给每个加工编号，用于表明该加工所处的层次及上、下层的父图与子图的关系。编号的规则为：顶层加工不用编号；第二层加工的编号为1，2，n；第三层加工的编号为1.1，1.2，2.1，n.1，n.2，等，依次类推。如编号1.2表明该加工处于第三层数据流图中，序号为2，该图是对上层数据流图中编号为1的加工进行细化得到的子图。(5)在父图中不要出现子图中涉及的局

27、部数据存储文件。通常除底层数据流图中需标明所有数据存储外，为了保持画面的整洁，各中间层数据流图只需显示处于加工之间的接口文件即可。第3章 软件需求分析与建模 (6)数据流图只能由四种基本符号组成，是实际业务流程的客观映象，用于说明系统应该“做什么”，而不需要指明系统“如何做”。(7)数据流图的分解速度应保持适中。通常一个加工每次可分解为24个子加工，最多不要超过七个，因为过快的分解会增加用户对系统模型理解的难度。(8)为了便于数据流图在计算机上的输入和输出，免去画斜线、弧线、圆等符号的麻烦，数据流图还有另一套表示符号，如表4.4所示。第3章 软件需求分析与建模 表表3.4 3.4 数据流图的另

28、一套表示符号数据流图的另一套表示符号编号编号符 号含 义数据流，只能为水平或垂直的带箭头直线 加工数据存储数据的源点或终点第3章 软件需求分析与建模 3.4 3.4 行行 为为 建建 模模3.4.1 3.4.1 状态迁移图状态迁移图 状态迁移图是一种描述系统状态随外部信号或事件进行迁移的有效的图形手段。在状态迁移图中，用圆圈表示可得到的系统状态，在圆圈中需要标明状态的名字。此外，用带箭头的线表示从一种系统状态向另一种系统状态的迁移，在线上要写明导致状态迁移的信号或事件的名字。例如，在操作系统中，当存在多个申请占用CPU运行的进程(进程是分配CPU的最小处理单位)时，系统将按照某种调度策略为各个

29、进程分配CPU。此时，进程的状态可能有三种：就绪、运行和等待。第3章 软件需求分析与建模 就绪：等待分配CPU；运行：占用CPU进行相应的处理；挂起：放弃CPU的使用。导致系统状态发生迁移的事件有四种：t1、t2、t3、t4，分述如下：t1：因I/O等事件的发生而要求中断；t2：中断事件已经处理完毕；t3：分配CPU；t4：已用完分配的CPU时间。第3章 软件需求分析与建模 在上面描述的情况下，有关CPU分配的进程的状态迁移图如图3.9所示。状态迁移图还可以表示为等价的表格形式，这样的表格称为状态迁移表。状态迁移表的列由所有的系统状态组成，行由引起状态迁移的所有信号或事件组成，表格中第i行第j

30、列的元素是从状态Sj因发生事件ti而会迁移到的状态。与图3.9等价的状态迁移表如表3.5所示。在表中，S1代表就绪状态；S2代表运行状态；S3代表挂起状态。第3章 软件需求分析与建模 图3.9 进程的状态迁移图第3章 软件需求分析与建模 表表3.5 3.5 进程的状态迁移表进程的状态迁移表 状 态 事件S1S2S3t1 S3 t2 S1t3S2 t4 S1 第3章 软件需求分析与建模 如果状态迁移图所描述的系统比较复杂，则可以采用状态图的分层表示法。即先确定系统的大状态，画出相应的状态图，再对状态图中的大状态进一步进行细分，得到更为详细的系统下层状态迁移图。例如对图3.10(a)所示的状态图中

31、的大状态S1进行细化，就得到了图3.10(b)所示的下层状态迁移图。此外，在状态迁移图，一个状态由于某个事件而导致的下一个状态可能会有多个，具体迁移的状态是由更详细的内部状态和更详细的事件信息所决定的。为了能够描述这种情况下系统状态的变换过程，可在状态迁移图中引入判断框和处理框，如图3.10(c)中所示的状态迁移图就是采用这种方法对图3.10(a)的变形。第3章 软件需求分析与建模 图3.10 状态迁移图举例(a)状态迁移图；(b)细化后的状态迁移图；(c)状态迁移图的变形S1S2S3S2S3S1S3C2P1P2P5P3P4S2S11t4t3t1t2t2t4t3t1t3t4t1t2S1C1NN

32、YY C1、C2：判断条件P1P5：处理内容(a)(b)(c)S12第3章 软件需求分析与建模 3.4.2 3.4.2 PetriPetri网网 Petri网是德国人CAPetri于1962年提出的，它是一种使用图形方式对系统进行需求规格说明的技术，不仅能够描述同步模型，而且适用于描述相互独立、协同工作的处理系统，即并发系统。目前，Petri网在硬件、软件等领域都得到了广泛的应用，已经大量地应用于各种系统的模型化。在形式上，Petri网通常被描述为一张有向图。Petri网的图简称为PNG(Petri Net Graph)。在PNG中，组成的基本符号有三类，符号及其对应的含义如表3.6所示。第3

33、章 软件需求分析与建模 表表3.6 3.6 PetriPetri网中的基本符号及含义网中的基本符号及含义符 号含 义位置(place)，用于表示系统中的状态变迁(transition)，用于表示系统中的事件由状态指向事件的有向边，用于表示事件发生的前提，即对事件的输入由事件指向状态的有向边，用于表示事件导致的结果，即事件的输出第3章 软件需求分析与建模 图3.11是描述一个处于静止状态的系统的Petri网，图中只给出了系统中各个状态通过变迁而表现出来的相互关系。为了采用Petri网描述系统的动态行为，需要在Petri网中引入令牌(token)的概念。若Petri网中某个状态拥有令牌(在图中，拥

34、有令牌的状态对应的圆圈中间标记有实心黑点)，则表明该状态处理要求的到来。如果一个事件(变迁)发生的所有前提都满足，即作为输入的所有位置都拥有令牌，则称该事件是使能(enable)的，这时此事件就可以被激发(fire)。事件激发后，令牌将由事件的输入状态移至事件的输出状态。采用Petri网描述系统动态行为的状态变迁图如图4.12所示。第3章 软件需求分析与建模 将Petri网用于需求分析阶段的系统行为建模，可以使系统中时间之间的因果相关性及不相关性得到清楚的描述。虽然Petri网和状态迁移图同样都是通过一些定义好的状态来描述系统的行为，但Petri网更适用于并发系统的描述。第3章 软件需求分析与

35、建模 图3.11 描述静态系统的Petri网第3章 软件需求分析与建模 图3.12 采用Petri网描述系统动态行为的状态变迁图(a)初始状态；(b)激发t1之后；(c)(b)激发t2之后；(d)同时激发t1和t2之后第3章 软件需求分析与建模 3.5 3.5 数数 据据 字字 典典 虽然数据流图能够形象、清晰地描述数据在系统中流动、加工、存储的情况，但数据流图中的许多构成元素，如数据流、数据存储、加工，仅依靠名称并不能反映其本质含义，因此必须对这些构成元素进行严格的定义。作为对数据流图的补充，数据字典(DD，Data Dictionary)能够准确地定义数据流图中各组成成分的具体含义，二者共

36、同构成了系统的逻辑模型。第3章 软件需求分析与建模 3.5.1 3.5.1 数据字典的基本符号数据字典的基本符号表表3.7 3.7 数据字典中的基本符号及其含义数据字典中的基本符号及其含义符 号含 义说 明=表示定义为用于对=左边的条目进行确切的定义+表示与关系X=a+b表示X由a和b共同构成|,表示或关系X=a|b与X=a,b等价，表示X由a或b组成()表示可选项X=(a)表示a可以在X中出现，也可以不出现 表示重复大括号中的内容重复0到多次m n表示规定次数的重复重复的次数最少m次，最多n次“”表示基本数据元素“”中的内容是基本数据元素，不可再分.连接符month=1.12表示month可

37、取112中的任意值*表示注释两个星号之间的内容为注释信息第3章 软件需求分析与建模 3.5.2 3.5.2 数据字典中的条目及说明格式数据字典中的条目及说明格式 数据字典是关于数据流图中各种成分详细定义的信息集合，可将其按照说明对象的类型划分为四类条目，分别为数据流条目、数据项条目、数据文件条目和数据加工条目。为了便于软件开发人员方便地查找所需的条目，应按照一定的顺序对数据字典中的不同条目进行排列。下面分别对各类条目的内容及说明格式进行介绍。第3章 软件需求分析与建模 1.1.数据流条目数据流条目 数据流在数据流图中主要用于说明数据结构在系统中的作用和流动方向，因此数据流也被称作“流动的数据结

38、构”。数据字典中数据流条目应包括以下几项主要内容：数据流名称、数据流别名、说明、数据流来源、数据流流向、数据流组成和数据流量等。例如：工资系统中的出勤表数据流在数据字典中的条目描述为第3章 软件需求分析与建模 数据流名称：出勤表数据流别名：无说明：由人事部门每月月底上报的职工考勤统计数字数据流来源：人事部门数据流流向：加工1.2(计算应发工资)数据流组成：出勤表=年份+月份+职工号+出勤时数+病假时数+事假时数+旷工时数数据流量：1份/月第3章 软件需求分析与建模 2.2.数据项条目数据项条目 数据流图中每个数据结构都是由若干个数据项构成的，数据项是加工中的最小单位，不可再分。数据字典的数据项

39、条目中应包含的主要内容有：数据项名称、数据项别名、说明、类型、长度、取值范围及含义等。例如：出勤表中的职工号数据项在数据字典中的条目描述为 数据项名称：职工号 数据项别名：employee_no 说明：本单位职工的惟一标识 类型：字符串 长度：6 取值范围及含义：12位(00.99)为部门编号：36位(XX0001.XX9999)为人员编号第3章 软件需求分析与建模 3.3.数据文件条目数据文件条目 数据文件是数据流图中数据结构的载体。数据字典的数据文件条目中应包含的主要内容有：数据文件名称、说明、数据文件组成、组织方式、存取方式、存取频率等。例如：工资系统中的职工工资档案文件在数据字典中的条

40、目描述为 数据文件名称：工资档案 说明：单位职工的基本工资、各项津贴及补贴信息 数据文件组成：职工号+国家工资+国家津贴+职务津贴+职龄津贴+交通补贴+部门补贴+其他补贴 组织方式：按职工号从小到大排列 存取方式：顺序 存取频率：1次/月第3章 软件需求分析与建模 4.4.数据加工条目数据加工条目 在数据流图中只简单给出了每个加工的名称，在数据字典中通过数据加工条目主要是要说明每个加工是用来“做什么”的。数据字典的数据文件条目中应包含的主要内容有：数据加工名称、加工编号、说明、输入数据流、输出数据流、加工逻辑等。例如：工资系统中的计算应发工资这个加工在数据字典中的条目描述为 数据加工名称：计算

41、应发工资 加工编号：1.2第3章 软件需求分析与建模 说明：根据职工的工资档案及本月奖金发放表数据计算每个职工的应发工资 输入数据流：奖金发放表及工资档案 输出数据流：应发工资表 加工逻辑：DO WHILE 工资档案文件指针未指向文件尾 从工资档案中取出当前职工工资的各项基本数据进行累加 在奖金发放表中按职工号查找到该职工的奖金数 对奖金数与工资基本数据的累加和进行求和得到该职工的应发工资数ENDDO第3章 软件需求分析与建模 4.5.3 4.5.3 加工逻辑的描述加工逻辑的描述 1.1.结构化语言结构化语言 结构化语言是一种介于自然语言和形式化语言之间的半形式化语言，例如，上面对计算应发工资

42、条目中加工逻辑的描述就是采用的结构化语言。它是在自然语言的基础上加入了一定的限制，通过使用有限的词汇和有限的语句来较为严格地描述加工逻辑。描述时可以使用的词汇包括：数据字典中定义的名字、基本控制结构中的关键词、自然语言中具有明确意义的动词和少量的自定义词汇等。尽量不使用形容词或副词，可以使用一些简单的算术或逻辑运算符。结构化语言中的三种基本结构的描述方法如下：第3章 软件需求分析与建模 (1)顺序结构：由自然语言中的简单祈使语句序列构成。(2)选择结构：通常采用IFTHENELSEENDIF和CASEOFENDCASE结构。(3)循环结构：通常采用DO WHILEENDDO和REPEATUNT

43、IL结构。第3章 软件需求分析与建模 2.2.判定表判定表 当某一加工的实现需要同时依赖多个逻辑条件的取值时，对加工逻辑的描述就会变得较为复杂，很难采用结构化语言清楚地将其描述出来，而采用判定表则能够完整且清晰地表达复杂的条件组合与由此产生的动作之间的对应关系。判定表通常由用双线分隔开的四个部分构成：左上部用于列出所有相关的条件；左下部用于列出所有可能产生的动作；右上部用于列出所有可能的条件组合；右下部用于列出在各种组合条件下需要进行的动作。通常把表中任意一个条件组合的特定取值及其相应要执行的动作称为规则。判定表的一般格式如下所示。第3章 软件需求分析与建模 下面以描述某单位工资档案管理系统中

44、“职务津贴计算”加工逻辑为例说明判定表的写法。由于篇幅限制，在下面的例子中假定职工的职称只分为助工、工程师和高工三种，对应的判定表见表3.8。条件列表条件组合动作列表对应的动作第3章 软件需求分析与建模 表表3.8 “3.8 “职务津贴计算职务津贴计算”判定表判定表第3章 软件需求分析与建模 要生成上面的判定表，具体的步骤如下：(1)确定规则的个数。例子中有两个条件，每个条件有三种取值，故规则个数为33=9。(2)列出所有的条件和动作。(3)列出所有的条件组合。(4)填写每种条件组合下对应的动作。(5)若表中存在不同规则对应相同动作且其条件组合存在某种关系时，需要对表进行必要的化简。第3章 软

45、件需求分析与建模 3.3.判定树判定树 判定树是判定表的图形表示，它与判定表的作用大致相同，但比判定表更加直观，更易于理解和掌握。例如，图3.13是采用判定树对“基本奖金计算”加工逻辑的描述。图3.13 “基本奖金计算”判定树第3章 软件需求分析与建模 判定树虽然形式上比判定表直观，但逻辑上没有判定表严格，用户在使用判定树时容易造成个别条件的遗漏。由于三种描述方法具有的不同特点，因而在实际的软件开发工作中，结构化语言、判定表和判定树通常被混合使用。对于顺序结构和循环结构采用结构化语言进行描述；对于存在多个条件组合的复杂判定问题采用判定表或判定树进行描述。第3章 软件需求分析与建模 3.5.4

46、3.5.4 数据字典的建立数据字典的建立 1.1.建立数据字典的方法建立数据字典的方法 (1)手工建立。分别将数据字典中每一个条目按照规定的格式写在卡片上，由专人负责管理和维护。为了便于查找，通常可将卡片分类，按条目的名称或编号进行排序。(2)自动建立。利用现有的数据字典建立程序，通过按照指定格式输入各类条目的内容，由计算机自动建立相应的数据字典。且通常这类工具软件还能够对建立好的数据字典进行完整性、一致性检查，以及进行日常的管理和维护工作。如由美国密执安大学开发的PSL/PSA系统就是这类软件的杰出代表。第3章 软件需求分析与建模 2.2.建立数据字典的原则建立数据字典的原则(1)所有定义必

47、须严密、精确，不能存在二义性。(2)书写格式应简洁且严格。(3)应可方便地实现对所需条目的按名查阅。(4)应便于修改和更新。第3章 软件需求分析与建模 3.6 3.6 结构化需求分析的若干技术结构化需求分析的若干技术 传统软件工程中的需求分析方法主要包括原型化分析方法和结构化分析方法等。其中，结构化分析方法的出现最早，其应用也最为广泛，在设计阶段还能与结构化设计方法很好地衔接起来，构成结构化分析与设计方法，即SADT方法。本节将简要介绍采用结构化分析方法进行需求分析的技术。第3章 软件需求分析与建模 结构化分析(Structure Analysis)方法，简称SA方法，是在20世纪70年代由美

48、国Yourdon E.等人提出的一种面向数据流进行需求分析的方法。这种方法简单实用，适合于加工类型软件系统的需求分析工作，尤其是信息管理类型的应用软件的开发。由于结构化分析方法中利用许多图形工具来表达系统的需求，使需求模型清晰、简洁、易读、易修改，因此在软件开发中得到了广泛的应用，相应的支持工具也较多。第3章 软件需求分析与建模 在软件工程技术中，用于控制问题复杂性的基本手段是“分解”和“抽象”。所谓分解，是指对于一个复杂的问题，为了将其复杂性降低到人们可以掌握的程度，可以将问题划分为若干的小问题，然后分别加以解决。此外，在解决复杂问题时，还可以分层进行，即先暂时忽略细节，只考虑问题最本质的属

49、性，然后再逐层细化，直至涉及到最详细的内容，这就是“抽象”。结构化分析方法的基本思想正是运用了“分解”和“抽象”这两个基本手段，采用“自顶向下，逐层分解”的分析思路，首先将整个系统抽象成一个加工，如图3.14中的系统加工S。由于系统加工S很复杂，接着需要将其分解成若干个子加工；如果子系统仍然比较复杂，则需对子加工继续进行分解；第3章 软件需求分析与建模 系统加工S输入数据输出数据I1InO1On图3.14 系统的顶层数据流图 第3章 软件需求分析与建模 重复这样的分解，直到每个子加工都足够简单，能够被清楚地理解和表达为止。结构化分析方法的“自顶向下，逐层分解”的过程如图3.15所示。“自顶向下

50、，逐层分解”充分体现了分解和抽象结合的原则，使人们不至于过早地陷入细节，有助于有控制地逐步解决复杂的问题。顶层抽象地描述整个系统，底层具体描述系统中的每一个细节，而中间层则是从抽象向具体的逐步过渡。无论系统多么复杂，分析工作的难度都能得到有效的控制，使整个需求分析过程可以有条不紊地进行。第3章 软件需求分析与建模 图3.15 “自顶向下，逐步分解”过程示意图第3章 软件需求分析与建模 1建立数据模型建立数据模型实体关系模型(E-R模型)是目前最常用的数据建模技术，可以用于在需求分析阶段完整、清晰地刻画目标系统中数据对象的构成、属性及数据对象之间的关系。建立E-R模型时需注意以下几点：(1)调查