外部
实体 位于软件系统边界之外的信息⽣产者或消费者转换
变换数据流的处理过程,⼜称泡(bubble ) 为⼀个或多个转换提供数据源或数据存储服务的缓冲区、⽂件或数据库 数据存储在转换之间定向流动的数据项或数据项集合 第5章 ⾯向数据流的分析⽅法
⾯向数据流的分析⽅法(dataflow-oriented analysis method )与⾯向对象、⾯向数据的分析⽅法,都是需求建模⽅法。它们均有⼀组规范的语⾔表达机制,需求分析⼈员⽤来表达⽤户需求、构造软件系统模型。此外,它们还含有⼀些规则和经验知识,指导分析⼈员提取需求信息,促进⽤户需求精确化、完全化和⼀致化。
⾯向数据流的分析⽅法是结构化分析⽅法系列中的⼀⽀,具有明显的结构化特征。结构化分析⽅法的雏形出现于20世纪60年代后期。但是,直到1979年才由DeMarco 将其作为⼀种需求分析⽅法正式提出。由此,结构化分析⽅法得到了迅速发展和⼴泛应⽤。 本章主要介绍⼴为使⽤的⾯向数据流的分析⽅法及其需求分析CASE ⼯具。5.1 数据流图与数据字典
⼀个基于计算机的信息处理系统就是对数据流进⾏⼀系列加⼯的处理过程,⽽这些加⼯将输⼊数据流变换为输出数据流。数据流图就是⽤来刻画数据流和加⼯的信息系统建模技术。数据字典是与数据流图配套使⽤的,⽤来定义系统中数据元素的有机集合体。5.1.1 数据流图
数据流图(Data Flow Diagram ,DFD )描述输⼊数据流到输出数据流的转换(即加⼯),⽤于对系统的功能建模。1.数据流图的基本图形元素
数据流图中的基本图形元素包括:数据流、转换、数据存储以及外部实体,如图5-1所⽰。数据流、转换、数据存储⽤于构建软件系统内部的数据处理模型;外部实体表⽰存在于系统边界之外的对象,⽤来帮助我们理解软件系统数据的来源和去向。图5-1 数据流图的基本图形元素 需要说明的是,DFD 图形元素还可以⽤其他描述符号来表⽰,如⽤圆⾓矩形表⽰转换,⽤开放箭头表⽰数据流等。软件⼯程84
(1)外部实体。外部实体通常是指存在于软件系统之外的⼈员或组织,表⽰软件系统数据的来源和去向。例如,在考务处理系统中,考⽣向系统提供报名单,所以考⽣是考务处理系统的⼀个外部实体;⽽系统要将考试成绩的统计分析传递给考试中⼼,考试中⼼也是⼀个外部实体。
(2)转换。转换描述了输⼊数据流到输出数据流的变换,也就是将输⼊数据流加⼯成输出数据流。每个转换⽤⼀个定义明确的名字标识。⼀个转换可以有多个输⼊或输出数据流,但⾄少要有⼀个输⼊数据流和⼀个输出数据流。例如。考务处理系统中有审定合格者、编制准考证和统计成绩等转换。
⼀个转换可以代表⼀系列程序、单个程序或者程序的⼀个模块;它甚⾄可以代表⽬视检查数据正确性等⼈⼯处理过程。(3)数据流。数据流由⼀组固定成分的数据组成。例如,考务处理系统向考⽣送出的准考证由姓名、考场、考号、考试时间和考试科⽬等数据组成。
DFD中的每个数据流⽤⼀个定义明确的名字标识。对于流⼊或流出数据存储的数据流,由于代表了数据存储的⼀个有效内容,所以不必为其命名。
注意,数据流与程序流程图中⽤箭头表⽰的控制流有着本质不同,千万不要混淆。熟悉程序流程图的初学者在画数据流图时,往往试图在数据流图中表现分⽀条件或循环,殊不知这样做将造成混乱,导致画不出正确的数据流图。在数据流图中应该描绘所有可能的数据流向,⽽不是描绘出现某个数据流的条件。
(4)数据存储。在软件系统中常常把某些信息保存起来供以后使⽤,这在DFD中⽤数据存储来表⽰。例如,在考务处理系统中,考⽣名册要随着报名的过程不断补充。因此,考⽣名册可以作为⼀个数据存储。
DFD中的每个数据存储⽤⼀个定义明确的名字标识。可以有流⼊数据流,代表写操作;也可以有流出数据流,代表读操作。⼀个数据存储可以表⽰⼀个⽂件、⽂件的⼀部分、数据库的元素或记录的⼀部分等;数据可以存储在磁盘、主存及其他任何介质上(包括⼈脑)。
数据存储和数据流都是数据,仅仅所处的状态不同。数据存储是处于静⽌状态的数据,数据流则是处于运动中的数据。2.绘制数据流图
(1)顶级DFD。顶级数据流图只有⼀个转换,代表整个软件系统,主要描述了软件系统与外界(外部实体)之间的数据流。例如,图5-2是“家庭保安系统”的顶级数据流图。Array图5-2 “家庭保安系统”顶级数据流图第5章 ⾯向数据流的分析⽅法 85
(2)逐层分解。数据流图提供了层次结构,让分析⼈员能够⽅便地表⽰任意抽象级别上的信息系统或其⼦系统,并⽀持问题分解、逐步求精的分析⽅法,充分体现了分解和抽象的原则。
初始时,整个信息处理系统可以⽤图5-2所⽰的顶级(第0级)数据流图表⽰。随着需求分析活动的逐渐深⼊,较⾼抽象级别上的复杂加⼯可以精化为⼀系列相互关联的数据流和⼦加⼯,如图5-3所⽰。这种⾃上向下、逐层分解的过程⼀直进⾏到所有的加⼯都可以清晰、明确的定义为⽌,从⽽构成了整套分层数据流图。
图5-3 数据流图的精化与层间平衡 在数据流⽅法中,对数据(数据流)的精化是伴随着对加⼯的逐步精化⽽同步进⾏的。(3)原则。建⽴数据流模型要遵循以下原则。
1)每个加⼯⾄少应有⼀个输⼊数据流(反映被处理数据的来源)和⼀个输出数据流(反映加⼯的结果)。2)数据流图中各构成元素的名称必须具有明确的含义且能够代表对应元素的内容或功能。
3)对数据流图中某个加⼯进⾏细化⽣成的下层数据流图,称为其上层图的⼦图。应保证分层数据流图中任意对应的⽗图和⼦图的输⼊/输出数据流的⼀致性,如图5-3所⽰。
4)在数据流图中,应按照层次给每个加⼯编号,⽤于表明该加⼯所处的层次及上下层的⽗图与⼦图的关系。编号的规则为:顶层加⼯不⽤编号;第⼀层加⼯的编号为1,2,…,n 。第⼆层加⼯的编号为11,12,…,21,22,…,n1,n2,…,等,依此类推。
5)在⽗图中不要出现⼦图中涉及的局部数据存储⽂件。通常除底层数据流图中需表明所有数据存储外,为保持画⾯整洁,各中间层数据流图只需显⽰处于加⼯之间的接⼝⽂件即可。
6)数据流图只能由4种基本符号组成,是实际业务流程的客观映像,⽤于说明系统应该“做什么”,⽽不需要指明系统“如何做”。
7)数据流图的分解速度应保持适中。通常⼀个加⼯每次可分解为2~4个⼦加⼯,最多不要超过7个,否则会增加⽤户理解的难度。同时要注意,逐层精化必须适可⽽⽌。
8)为了便于数据流图在计算机上的输⼊和输出,应避免使⽤斜线、弧线、圆等符号。 0级 1级 2级软件⼯程86
3.标识数据流图的元素
数据流图中每个成分的命名是否恰当,直接影响数据流图的可理解性。因此,给这些成分起名字时应该仔细推敲。下⾯讲述在命名时应注意的问题。
(1)为数据流(或数据存储)命名。
1)名字应代表整个数据流(或数据存储)的内容,⽽不是仅仅反映它的某些成分。2)不要使⽤空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输⼊”之类)。
3)如果在为某个数据流(或数据存储)起名字时遇到了困难,则很可能是因为对数据流图分解不恰当造成的,应该试试重新分解,看是否能克服这个困难。(2)为加⼯命名。
1)通常先为数据流命名,然后再为与之相关联的加⼯命名。这样命名⽐较容易,⽽且体现了⼈类习惯的“由表及⾥”的思考过程。
2)名字应该反映整个加⼯的功能,⽽不是它的⼀部分功能。
3)名字最好由⼀个具体的及物动词,加上⼀个具体的宾语组成。应尽量避免使⽤“加⼯”、“处理”等空洞笼统的动词作名字。4)通常名字中仅包括⼀个动词。如果必须⽤两个动词才能描述整个加⼯的功能,则把这个加⼯再分解成两个加⼯可能更恰当些。
5)如果在为某个加⼯命名时遇到困难,则很可能是发现了分解不当的迹象,应考虑重新分解。
外部实体并不需要在开发⽬标系统的过程中设计和实现,它并不属于数据流图的核⼼内容,只不过是⽬标系统的外围环境部分(可能是⼈员、外部设备或传感器等)。通常,为外部实体命名时采⽤它们在问题域中习惯使⽤的名字(如“报警器”、“控制⾯板”等)。5.1.2 数据字典
前述的数据流图机制并不⾜以完整地描述软件需求,因为它没有描述数据流和数据源的内容。因此,需要⼀种系统化的⽅式来描述每个数据对象的特性,数据字典正是⽤来完成这项任务的。数据流图必须与描述并组织数据条⽬的数据字典配套使⽤。数据字典是在结构化分析过程中定义对象的内容时,使⽤的⼀种半形式化的⼯具。下⾯是对这个重要的建模⼯具的定义。数据字典是所有与系统相关的数据元素的有组织的列表,并且包含了对这些数据元素的精确、严格的定义。其作⽤是使得⽤户和系统分析员双⽅对输⼊、输出、存储的成分甚⾄中间加⼯结果有共同的理解。简⽽⾔之,数据字典是对系统中的所有数据元素的定义集合。
⽬前,数据字典作为CASE“结构化分析与设计⼯具”的⼀部分实现。尽管不同⼯具中数据字典的形式不同,但是数据字典⼀般应包含下列信息。
(1)名字——数据、控制项、数据存储或外部实体的主要名称。(2)别名——第⼀项中所列诸对象的其他名字。
(3)使⽤地点与⽅式——使⽤数据或控制项的加⼯的列表,以及使⽤这些对象的⽅式(例如,作为加⼯的输⼊,从加⼯输出,作为数据存储,作为外部实体)。
(4)内容描述——描述数据或控制项内容的符号。
(5)补充信息——关于数据类型、预置值、限制等的其他信息。第5章⾯向数据流的分析⽅法87
⼀旦把数据对象或控制项的名字和别名输进数据字典,就可以保持命名的⼀致性。也就是说,⽀持数据字典的CASE⼯具能够发现重名现象并发出警告信息,这提⾼了分析模型的⼀致性,有助于减少错误。
“使⽤地点与⽅式”信息是从数据流图中⾃动提取的。表⾯看起来,数据字典⼯具的这项功能好像并不重要,实际上这正是数据字典的主要优点之⼀。在分析过程中⼏乎始终在进⾏修改。但对于⼤型项⽬来说,确定修改的影响往往很困难。许多软件⼯程师都遇到过下述问题:这个数据对象在什么地⽅使⽤?如果修改了它,相应地还应该再修改哪些对象?这个改动在整体上有什么影响?利⽤数据字典中的“使⽤地点与⽅式”信息,完全可以回答上述问题。下⾯介绍⽤于书写“内容描述”信息的符号,也就是定义数据的⽅法。
定义绝⼤多数复杂事物,都是⽤被定义事物成分的某种组合来表⽰,这些组成成分⼜由更低层的成分的组合来定义。从这个意
义上说,定义就是⾃顶向下的分解。所以数据字典中的定义,就是对数据⾃顶向下的分解。那么,应该把数据分解到什么程度呢?⼀般说来,当分解到不需要进⼀步定义,每个和⼯程有关的⼈也都清楚其含义的元素时,这种分解过程就完成了。由数据元素组成数据的⽅式只有下述三种基本类型。(1)顺序——即以确定次序连接两个或多个分量。(2)选择——即从两个或多个可能的元素中选取⼀个。(3)重复——即把指定的分量重复零次或多次。
因此,可以使⽤上述三种关系算符定义数据字典中的任何条⽬。为了说明重复次数,重复算符通常和重复次数的上下限同时使⽤(当上下限相同时表⽰重复次数固定)。当重复的上下限分别为l和0时,可以⽤重复算符表⽰某个分量是可选的(可有可⽆的)。但是,“可选”是由数据元素组成数据时⼀种常见的⽅式,把它单独列为⼀种算符可以使数据字典更清晰⼀些。因此,增加了下述的第四种关系算符:
(4)可选——即⼀个分量是可有可⽆的(重复零次或⼀次)。
虽然可以使⽤⾃然语⾔描述由数据元素组成数据的关系,但是为了更加清晰简洁起见,建议在数据字典中采⽤如表5-1所⽰的基本符号。
表5-1 数据字典中的基本符号及其含义符号含义说明
= 表⽰定义为⽤于对=左边的条⽬进⾏确切的定义+ 表⽰与关系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可取1~12中的任意值* * 表⽰注释两个星号之间的内容为注释信息软件⼯程88
对于⼤型软件项⽬来说,数据字典的规模⼗分庞⼤,⼈⼯管理将⾮常困难。⽬前⼤多数⽀持数据流分析的CASE⼯具都具备数据字典管理功能,这些功能包括:
(1)⼀般性检查。当分析⼈员要求创建新的数据条⽬并键⼊名称或别名时,CASE⼯具⾃动进⾏重名检查,这就避免了数据流图中不⼀致的数据定义。
(2)CASE⼯具可根据已有的数据流图⽣成相关加⼯的列表。并且,随着数据流图的进化,CASE⼯具可⾃动修改该列表,以便数据字典和数据流图在任何时刻都保持⼀致。
(3)CASE⼯具将⾃动完成有关数据条⽬的各种查询,例如:该数据条⽬在何处使⽤?修改某⼀部分数据流图将会影响哪些数据条⽬?修改某数据条⽬⼜会造成哪些影响?显然,对这些问题的正确回答将有助于分析⼈员在需求模型的进化过程中维持模型的⼀致性。
数据条⽬的定义必须遵循以下原则:精确、简洁,并且能为⽤户⽅和软件开发⽅共同理解。可以使⽤形式语⾔中的语法定义机制描述数据条⽬的内容。原⼦语法成分则⽤简单明了的⾃然语⾔予以描述。例如,“家庭保安系统”中的“电话号码”数据条⽬可以定义如下:<电话号码>=<分机号>|<外线号码><分机号>=1816|1817|…|1858
<外线号码>=9+(<市话号码>|<长话号码>)
<长话号码>=0+(<区号>+<市话号码>)<区号>=*任何长度为3的数字串*<市话号码>=<局号>+<分局号><局号>=395|396|397|303|304|305<分局号>=*任何长度为4的数字串*
综上所述,利⽤数据字典可以对数据流图中的数据流、数据源以及外部实体进⾏描述、组织和管理。同时,对于加⼯,也需要⼀种⽐图形记号更为详尽的表⽰机制,这就是结构化的⽂字描述(参考7.2.6节)。分析⼈员可以在数据流图的任⼀加⼯上附加⼀段⽂字,⽤以说明加⼯的功能、性能要求及设计约束等,这种说明应尽可能简洁、清晰、易于理解。5.2 实体—关系图
在数据密集型应⽤问题中,对复杂数据及数据之间复杂关系的分析和建模将成为需求分析的重要任务。很显然,这项任务是简单的数据字典机制⽆法胜任的。所以,有必要在数据流分析⽅法中引进适合于复杂数据建模的⼯具:实体—关系图。5.2.1 数据对象、属性与关系1.数据对象
数据对象是现实世界中实体的数据表现。或者说,数据对象是现实世界中省略了功能和⾏为的实体。在数据流分析⽅法中,数据对象包括5.1节提及的数据存储、数据流以及外部实体的数据部分。例如,在汽车销售管理问题中,“制造商”、“汽车”以及“经销商”都是数据对象。
数据对象仅仅封装了数据⽽没有对作⽤于数据上的操作的引⽤,这是数据对象与⾯向对象范型中的“类”或“对象”的显著区别。第5章⾯向数据流的分析⽅法892.属性
数据对象的性质由其属性刻画。通常属性包括:
(1)命名性属性:对数据对象的实例命名,其中必含有⼀个或⼀组关键属性,以便唯⼀地标识数据对象的实例。同时,把⼀个或多个属性定义为“标识符”,也就是当我们希望找到数据对象的⼀个实例时,标识符属性就成为“关键字”。(2)描述性属性:对数据对象实例的性质进⾏刻画。(3)引⽤性属性:将⾃⾝与其他数据对象的实例关联起来。
⼀般⽽⾔,现实世界中任何给定实体都具有许多属性,分析⼈员应当并且只能考虑与应⽤问题有关的属性。例如,在汽车销售管理问题中,汽车的属性可能有:制造商、型号、标识码、车体类型、颜⾊和买主等。3.关系
应⽤问题中的任何数据对象都不是孤⽴的,它们与其他数据对象⼀定存在各种形式的关联。例如,在汽车销售管理问题
中,“制造商”与“汽车”之间存在“⽣产”关系,“购车者”与“汽车”之间存在“购买”关系。当然,关系的命名及内涵因具体问题⽽异。分析⼈员必须善于剔除与应⽤问题⽆关的关系。关系也称为联系。联系可分为以下三类。(1)⼀对⼀联系(1:1)。
例如,⼀个部门有⼀个经理,⽽每个经理只在⼀个部门任职,则部门与经理的联系是⼀对⼀的。(2)⼀对多联系(1:N)。
例如,某校教师与课程之间存在⼀对多的联系“教”,即每位教师可以教多门课程,但是每门课程只能由⼀位教师来教。(3)多对多联系(M:N)。
例如,表⽰学⽣与课程间的联系(“学”)是多对多的,即⼀个学⽣可以学多门课程,⽽每门课程可以有多个学⽣来学。联系也可能有属性。例如,学⽣“学”某门课程所取得的成绩,既不是学⽣的属性也不是课程的属性。由于“成绩”既依赖于某名特定的学⽣⼜依赖于某门特定的课程,所以这是学⽣与课程之间的联系“学”的属性。
基于数据对象、属性与关系,分析⼈员可以为应⽤问题建⽴数据模型。为确保模型的⼀致性并消除数据冗余,分析⼈员要掌握
以下规范化规则:
(1)数据对象的任何实例对每个属性必须有且仅有⼀个属性值。(2)属性是原⼦数据项,不能包含内部数据结构。
(3)如果数据对象的关键属性多于⼀个,那么其他的⾮关键属性必须表⽰整个数据对象⽽不是部分关键属性的特征。例如,如果在“汽车”数据对象中增加“经销商”属性并将其与标识码⼀起作为关键属性,那么,再添加“经销商地址”属性就违背了上述规则,因“经销商地址”仅仅是“经销商”的特征,它与汽车的“标识码”⽆关。(4)所有的⾮关键属性必须表⽰整个对象⽽不是部分属性的特征。
例如,在“汽车”数据对象中,增加“油漆名称”属性就违背了上述原则,因为它仅仅软件⼯程
90 与“颜⾊”有关,⽽不是整个“汽车”的特征。5.2.2 实体—关系图
实体—关系图(Entity-Relationship Diagram )是制定产品规格说明书的⼀种图形语⾔机制。它是由美籍华⼈陈平⼭于1976年提出的。
通常,使⽤实体—关系图来建⽴数据模型。常把实体—关系图简称为ER 图;相应地,⽤ER 图描绘的数据模型也称为ER 模型。
1.ER 图的基本成分
ER 图中包含了实体(即数据对象)、关系和属性三种基本成分。通常⽤矩形框代表实体,⽤连接相关实体的菱形框表⽰关系,⽤椭圆形或圆⾓矩形表⽰实体(或关系)的属性,并⽤⽆向边把实体(或关系)与其属性连接起来。为了便于区分,ER 模型中的实体、关系和属性都应在对应的框中写上各⾃的名字。2.基数与模态
基数是指在⼀个给定的关系中实体间数量上的对应。基数通常简单地⽤“1”或者“多”来表⽰,它描述了“重复性”。模态表⽰在⼀个关系中⼀个特定的实体是否必须参与的信息。
如图5-4所⽰,实体“教师”旁有两条竖线,靠近实体“教师”的竖线代表了“1位教师”;另⼀条竖线代表了“必须”由教师来教课程。另⼀个实体“课程”旁有多分⽀线和圆圈,多分⽀线代表了“多”门课程,圆圈代表了“可以教也可以不教”课程。也就是说⼀个教师可以教多门课程,也可以不教课程;但是,课程必须由教师来教。
图5-4 基数与模态3.ER 图⽰例
如图5-5所⽰是汽车销售管理问题的ER 图。其中,⼀个制造商⽣产⼀辆或多辆汽车,它可以给⼀个或多个经销商发放经销许可证。车辆可以通过⼀个或多个经销商销售,或者由⼚家直接销售等。图5-5省略了部分实体或关系的属性。
⼈们通常⽤实体、联系和属性这三个概念来理解现实问题,因此ER 模型⽐较接近⼈的习惯思维⽅式。此外,ER 模型使⽤简单的图形符号表达系统分析员对问题域的理解,不熟悉计算机技术的⽤户也能理解它。因此,ER 模型可以作为⽤户与分析员之间有效的交流⼯具。⽬前较为流⾏的ER 图开发⼯具有Power Designer 以及ER-WIN 等。模态:必须 模态:可选第5章⾯向数据流的分析⽅法91
图5-5 实体—关系图实例5.3 基于数据流的分析⽅法
本节结合“家庭保安系统”讨论⼀些常⽤的启发式经验知识和规则,从⽽为分析⼈员建造易于理解的、描述⽤户需求的数据流模型提供⽅法上的指导。
5.3.1 创建数据流模型
数据流图是⽬标软件系统中各个⼦加⼯以及它们之间的数据流动的图形表⽰。数据流图的精化过程实际上是⼦加⼯和数据流的细化过程。随着这⼀过程的进⾏,⽤户需求逐步精确化、⼀致化和完备化。在创建⽤户需求的数据流模型的过程中,分析⼈员应遵循以下规则:
(1)建⽴顶级数据流图,其中只含有⼀个代表⽬标软件系统整体处理功能的加⼯。
根据软件系统与外部环境的关系确定顶级数据流图中的外部实体以及它们与软件系统之间的数据流。基于4.2.1节的初步需求分析结果,“家庭保安系统”的顶级数据流图如图5-2所⽰。
(2)对⽤户需求的⽂字描述进⾏语法分析,其中的名词和名词短语构成潜在的外部实体、数据源或数据流,动词构成潜在的加⼯。
结合分析⼈员对问题域和⽤户需求的理解,确定软件系统的主要功能以及它们之间的数据流。例如图5-6,就是对图5-2的分析结果。
(3)采⽤通常的功能分解⽅法,按照“强内聚、松耦合”的原则逐个对加⼯进⾏精化;与此同时逐步完成对数据流的精化,并针对被精化的加⼯⽣成下⼀级数据流图。
“强内聚、松耦合”的原则是指被分解出来的各⼦加⼯之间的联系相对松散、简单,⼦加⼯内部各部分的联系相对紧密、复杂。这⼀原则对于⽬标软件系统的可修改性、可扩充性⼤有益处,因为开发⼈员可以缩⼩软件修改或扩充的影响传播范围。对数据流的精化包含两个⽅⾯的意义。⼀⽅⾯,伴随着功能分解的进⾏,数据流的内容及各项特征将逐步彰显,所以要将其作为数据字典的⼀个条⽬,并不断精化、调整内容;另⼀⽅⾯,在⽗数据流图中的复合数据项可被分解为⼦数据项,这种数据流分解不能违背平衡原则。软件⼯程
92 例如,如果将图5-6中的“启动/停⽌处理”功能分解为“启动系统”和“停⽌系统”,那么“启动/停⽌命令”应相应地精化为“启动命令”和“停⽌命令”。
图5-6 “家庭保安系统”1级数据流图
对“家庭保安系统”中“传感器监测”⼦功能进⾏分解,得到了“家庭保安系统”的2级⼦数据流图如图5-7所⽰。
图5-7 “家庭保安系统”2级数据流图:对“传感器监测”的分解(4)精化过程中必须维持各级数据流图之间的数据流平衡。
(5)精化过程应适可⽽⽌,避免涉及软件设计细节。⼀般说来,如果某⼦功能可以⽤⼀段简洁、精确的⽂字描述清楚,就⽆须进⼀步分解。5.3.2 过程规格说明
对于数据流图中不再分解的加⼯,分析⼈员要借助结构化⾃然语⾔对其功能进⾏精确、简洁的描述。图5-6中“⼝令核对”⼦功能分解出来的“设置⼝令”⼦功能可描述如下:(1)参数:⼝令;类别:字符串。第5章⾯向数据流的分析⽅法93(2)处理步骤如下:
①检查系统是否已有⼝令。若有,则验证⽤户输⼊⼝令的有效性。如果有效,则显⽰提⽰信息要求输⼊新⼝令;否则,显⽰失败信息并退出。
②检查⼝令长度是否合法。如果⾮法,则显⽰提⽰信息要求重新输⼊。
③要求⽤户再次键⼊合法⼝令,以便⽤户确认和记忆。如果两次键⼊的⼝令不符,则返回。
④将确认后的⼝令按某种加密⽅法转换为另⼀字符串存放于系统配置⽂件中。显⽰成功信息并退出。
(3)约束条件:
在上述①、②、③步骤中,⽤户重试的机会不超过3次。5.4 基于CASE⼯具的需求分析
使⽤前述⽅法进⾏需求分析时,需要计算机在数据流图的绘制、数据字典的存储、检索及⼀致性检查等⽅⾯提供帮助。因此,本节给出⼀个基于数据流图的需求分析CASE⼯具的蓝本DFA_Tool。考虑到传统的数据流图语⾔机制和分析⽅法对⼤中型软件开发的⽀持能⼒⽐较单薄,我们结合结构化分析CASE⼯具的发展趋势,在需求分析的⽅法学、语⾔机制和分析能⼒等⽅⾯进⾏了扩充,引进了具体的多视点分析⽅法、可视形式化和可执⾏的需求描述语⾔以及动态分析技术。
以下分别介绍:DFA_Tool的主要思想;具有可视形式化特征的语⾔机制;利⽤DFA_Tool 进⾏需求分析的⽅法。5.4.1 核⼼思想
CASE⼯具的开发必须基于某些基本的原则或思想。这些原则或思想不仅决定着CASE⼯具的开发过程,⽽且也将对基于该CASE⼯具的软件开发⾏为发挥重要的指导作⽤。DFA_Tool 的核⼼思想可以归纳为:多视点需求分析、可视形式化和可执⾏的需求规格说明语⾔。1.多视点需求分析
DFA_Tool从相互关联的结构、功能和⾏为三个⽅⾯分别为⽬标软件系统建⽴模型。
在结构视点,分析⼈员可根据系统的物理结构或软件结构(例如,物理构件、软件模块、任务等)进⾏层次分解,并标识系统各部分之间的数据流,进⽽建⽴系统的结构图。
在功能视点,分析⼈员利⽤功能分解⽅法刻画系统的活动(类似于数据流图中的加⼯)以及活动之间可能出现的数据流,以逐层精化的⽅式建⽴系统的活动图。与数据流图⼀样,DFA_Tool的活动图不包括任何动态性质。它既不关⼼活动是如何启动和终⽌的,也不关⼼活动能否与其他活动并⾏执⾏。⾄于数据流,活动图只说明它们可以在某些活动之间流动,并不指明何时流动。
应⽤系统在时间坐标系中的所有控制⾏为均由⾏为视点描述。对于层次结构中的每⼀级活动图,均有⼀个相应的⾏为图,它们刻画系统的动态⾏为,包括:
(1)由于各时间点上事件的刺激,某些活动被启动或终⽌,并引发新的事件。
(2)对活动的活跃情况及数据的流动情况进⾏连续监测,据此决定系统的下⼀步⾏为。由此可见,系统的活动图(功能视点)和⾏为图(⾏为视点)是紧密耦合的,它们共同软件⼯程94
构成系统的概念模型。结构图与活动图之间的关系是简单⽽直接的:结构图中的某些构件负责实现活动图中的某些功能。如图5-8所⽰是DFA_Tool的模型结构。Array +图5-8 DFA_Tool的模型结构
DFA_Tool可以⾃动完成三个视点之间的某些⼀致性检查。例如,结构图中的数据流是否与活动图的数据流⼀致,结构图中哪些模块未产⽣输出,活动图中哪些活动永远不会被启动。2.可视形式化
与⽂字相⽐,图形更为直观、简洁。因此,需求分析活动往往离不开图形机制的⽀持,例如前述的数据流图。DFA_Tool的结构图、活动图及状态图均基于⼀组共同的简单图形记号,并且都具有形式化语义。因此,DFA_Tool兼备了图形的简单直观和形式化机制的精确严谨。3.可执⾏的需求规格说明语⾔
对于⼤中型软件项⽬的开发,未对需求规格说明书进⾏详细的测试便进⾏软件设计往往是危险的。因此,⽤于表述需求规格说明书的语⾔机制应该具有可执⾏语义,以便系统能够在需求分析阶段实际展⽰⽬标软件系统的动态⾏为,为分析⼈员提供动态分析、调试和测试等⼿段,并让⽤户尽早进⾏需求确认。基于以上考虑,DFA_Tool为图形语⾔机制定义了操作语义,并且它不仅可以⽤步进⽅式,还可以⽤预编程⽅式演⽰系统的动态⾏为。DFA_Tool提供⼀种元级模拟控制语⾔(Simulation ControlLanguage,SCL)。借助SCL,分析⼈员可以采⽤各种⽅式模拟外部环境,捕获⽬标软件系统的状态或事件,并进⾏元级控制,例如模拟执⾏⾄某个预设断点,跳过不重要的中间状态或者忽略⼀些琐碎的执⾏细节。5.4.2 基于CASE⼯具的需求分析
基于CASE⼯具的需求分析⽅法⼤体上仍与5.3节类似。但是,针对具体的CASE⼯具,有必要对传统的⽅法和步骤做局部调整,以适应该CASE⼯具所确⽴的需求分析⽅法学。例如,基于DFA_Tool的需求分析过程⼤致如下:(1)从多个视点分别建⽴⽬标软件系统的结构模型、功能模型和⾏为模型。
(2)在上述建模过程中可以采取功能分解、逐步求精的⽅法对部分⼦系统展开分析活动。⼀般⽽⾔,⾸先应建⽴⼦系统的活动图(功能模型),然后再给出相应的状态图(⾏为模型)。第5章⾯向数据流的分析⽅法95
(3)利⽤DFA_Tool表格说明机制对各种图形表⽰中的所有图元的内容进⾏描述,这些图元包括数据流、事件、状态和原⼦活动等。
(4)利⽤DFA_Tool的动态分析能⼒对⽬标软件系统或其⼦部分的模型进⾏模拟执⾏,以便发现不⼀致性和不完全性,并进⾏相应的修改完善。
DFA_Tool可以为分析⼈员⾃动完成以下烦琐任务:(1)模型的图⽰、存储与检索。
(2)模型之间、数据条⽬之间的⼀致性检查。(3)⾏为模型中状态的可达性分析、死锁分析。(4)模型的动态模拟执⾏。
(5)模型修改的影响传播范围的确定等。习题
1.简述数据流图的主要思想,概述使⽤数据流图进⾏需求分析的过程。
2.可以分别采⽤数据流⽅法中的哪些技术来完成⽤户需求的精确化、⼀致化和完全化任务?3.实体—关系图所适⽤的领域的主要特征有哪些?4.如何判断数据流图的⼀致性和完全性?
5.在数据流图中,可否将两个加⼯⽤⼀个数据流相连?可否将两个数据源⽤⼀个数据流连接?为什么?
6.针对第4章习题5所述的图书馆管理问题,采⽤实体—关系图表⽰该问题所涉及的主要实体、属性及实体之间的相互关系。7.选取⼀个你⽐较熟悉的中⼩型软件问题,分别采⽤或综合采⽤数据流图、实体—关系图进⾏部分需求分析⼯作,要求:(1)⾄少给出第0~2级数据流图。(2)给出相应的数据字典和实体—关系图。
8.简述5.4节所述的需求分析CASE⼯具DFA_Tool的主要思想。
9.基于第4章习题5所给出的初步需求⽂档,仍以原来的分组为单位使⽤数据流⽅法完成需求建模任务。要求给出以数据流图和数据字典为主体的需求规格说明书,然后进⾏严格的需求评审。
因篇幅问题不能全部显示,请点此查看更多更全内容