需求的描述方法传统方法.ppt

《需求的描述方法传统方法.ppt》由会员分享，可在线阅读，更多相关《需求的描述方法传统方法.ppt（68页珍藏版）》请在三一办公上搜索。

1、第十章 需求的描述方法,第一部分 传统方法,用传统的观点和面向对象的观点看待活动数据流程图详细记录DFD部件信息工程模型考虑网络节点和通信工作流建模,第9章描述了在使用传统方法和面向对象方法的信息系统开发过程中与建立系统需求模型相关的两个关键概念:事件和事物。而在这一章。我们的重点将转向当事件发生时系统会做什么，即活动和交互。,10.1用传统方法的观点和面向对象的观点看待活动,传统方法和面向对象方法的区别在于当一个事件发生时所发生的事情是不同的。有关系统需求的一个关键问题是:系统如何响应事件。传统方法区别于面向对象方法的地方在于系统的建模和实现方法的不同。传统方法把系统看作一个过程的集合体，一

2、些由人完成，另一些由计算机完成。计算机过程就象常规的计算机程序有按顺序执行的指令。当过程开始执行时，它与数据进行交互、读出数据、又把数据写回数据文件中。过程或许也要与人进行交互，例如它有时要求用户输人一个值或者在计算机屏幕上显示信息给用户看。所以，系统的传统方法包括过程、数据、输人和输出。在为系统对事件做出的反应进行建模的过程中，传统方法包括了强调组件的过程模型。,相比之下，面向对象(oo)方法把系统看成是一个相互影响的对象集。这些对象已在第9章中讨论过。对象是有行为的(叫做方法)。这些方法可以使对象与其他对象或系统使用者进行交互。一个对象通过发送消息请求另一个对象做某事。就其本身而论，面向对

3、象方法不存在常规的计算机过程和数据文件。对象执行活动并记录下数值。当为系统响应事件建模的时候，面向对象方法包括显示对象的模型、模型的行为以及与对象的交互。图10-1总结了传统方法和面向对象这两种方法的不同点。,传缭方法 系统是过程的集合 过程与数据实体交互过程接受输入并产生输出,面向对象方法系统是交互对象的集合对象与人或其他对象交互对象发送与响应消息,10.2数据流程图,在信息系统开发中传统方法把活动描述为由人或计算机执行的过程。数据流程图已被证明它是建立过程模型非常有价值的图形化模型。当然，还有其他的过程模型如在信息工程中使用的过程依赖图和用于业务流程再造的工作流程图，但数据流程图是最常用的

4、过程模型。,外部实体:在系统边界之外的个人或组织，它提供数据输入或接受数据输出。过程:在DFD中的一个符号，它代表从数据输入转换到数据输出的算法或程序。数据流:在DFD中的箭头，它表示在过程、数据存储和外部实体之间的数据移动。数据存储:保存数据的地方，以便将来由一个或多个过程来访问这些数据。,一个DFD演示处理“查找可用条目”,1,这个事件是客户想检查可用条目，触发器是条目查询，来源是客户，响应是可用条目细节，响应的目标是客户。所以，这个数据流程图以一个图形方式响应一个事件来显示系统活动。但是DFD的另一个信息没有包含在事件表中。数据存储包括条目可用性的信息。每一个数据存储在实体一联系图(ER

5、D)中代表一个数据实体。在DFD中的过程使用了在ERD中我们所提供的数据实体及其属性信息。所以，数据流程图将事件触发的过程和在ERD中定义的数据实体相结合。下图总结了DFD的组成部分、在事件表中描述的事件及在ERD中定义的数据实体这三者的一致性。,10.2.1数据流程图和抽象水平抽象水平:能把系统分解成一个逐渐细化的分层集合的建模技术。有许多种类型的数据流程图用于描述系统需求。刚才描述的例子是DFD的一部分，它显示了响应一个事件的过程。其他的数据流程图用于显示一个更高层(系统更概括的概念)或更低层(系统更详细的概念)的处理。这些不同的系统概念(高层的和低层的)被认为是抽象水平。数据流程图的另一

6、个非常有用的特性是能够表现系统高层和低层概念。在一个DFD中高层次过程可以分解成若干独立的、低层次的、详细的DFD，详细的DFD中的过程可以进一步分解成其他的图形以便提供多层次或多水平的抽象。,关联图,关联图是指描述系统高层结构的DFD。所有的外部实体和进出系统的数据流都画在一张图中，并且整个系统被表示成一个过程。如图显示了一个简单的大学课程注册系统的关联图，这个图与三个外部实体交互:学术部、学生和教员。学术部提供有关课程的信息，学生申请注册，教员在注册完成后得到班级列表。,图10-5大学课程注册系统的关联图,关联图在表达系统边界时很有用。系统的范围是通过单过程和外部实体所表示的事物来定义的。

7、提供和接收数据的外部实体在系统范围以外，其他任何事情属于系统的范围。数据存储不画在关联图中是因为数据存储本身被认为是属于系统内部的。在系统计划阶段，我们将关联图当做确定新系统范围的工具使用。,10.2.3 DFD片段,一个DFD片段是为事件清单(扩展为事件表)中的每个事件创建的。每个DFD片段是 一个显示系统如何响应某个事件的独立模型。分析员通常是一次创建一个DFD片段，这样能将精力集中在系统的一个部分中。,下图显示了课程注册系统的三个DFD片段。每一个DFD片段在一个过程符号中代表对一个事件的所有响应过程。但是这些片段展示厂在过程、外部实体和内部数据存储之间的交互细节。在DFD片段中的数据存

8、储代表ERD中的实体。每个DFD片段仅显示要响应该事件的那些数据存储。,图10-7课程注册系统的DFD片段,事件划分的系统模型 DFD片段的完全集可以组合到一个叫做事件划分的系统模型或0层图中。0层图通常在单个的DFD中显示完整的系统，它比关联图包含更多的细节。图10-10显示了四个相关的DFD以展示每一层是如何为上一层提供更进一步的信息的。最高层的DFD就是大学课程注册系统的关联图。紧接在关联图下方的DFD是事件划分系统模型（或0层图）。注意0层图实际上是关联图中对过程的分解，它也是图10-7中的三个DFD片段的一个组合。在0层图中的每一个过程表示处理一个事件。,0层图,DFD片断1,图1,

9、在图10-10中的第三个DFD展示了对应与0层图中过程1的一个DFD片段。由于在0层图中有三个过程，因此，应该有三个独立的DFD片段，每一个对应于一个过程或事件。但在图中只画了一个DFD片段。在这个DFD的下面是过程1中的一个分解。创建一个DFD是用来描述系统如何分解为子系统。一旦子系统的DFD创建好，系统分析员就为每一个子系统画一个独立的事件划分DFD。当子系统定义好，DFD集合就一个个相互联结起来。关联图分解为一个子系统DFD，而子系统DFD进一步分解为事件划分的DFD集合。没有单独的0层图。相反，每一个子系统有一个事件划分的DFD。本质上来说，一个事件划分的DFD是一个子系统的0层图。,

10、10.2.5 分解过程以查看一项活动更详细的信息 有时一些DFD片段包括许多处理，这些处理需要系统分析员做更详细的研究。正像一个关联图可以分解为0层图一样，一个DFD片段也可以分解为子过程。在任何建模步骤中，进一步的分解都将帮助系统分析员了解更多的需求，同时产生需要的文档。,图2是DFD片段2“创建新订单”较为详细的分解图的一个例子。把它命名为图表2是由于它显示过程2的内部信息。子过程被编号为2.1、2.2、2.3、2.4。然而，编号方式不必要表示子处理的执行顺序。本图把过程2分解为四个子过程:“记录客户信息”、记录订单”、“处理订单交易”，“产生确认信息”。这些子过程被认为是完整活动的四个主

11、要步骤。这也是细化工作的一种办法。另一个分析员可能得到不同的分析结果。,第一步开始于客户提供“新订单这个数据流的信息。“新订单”数据流包含客户和客户想要订购的所有项目信息。过程2.1在一个叫“客户”的数据存储中保存客户信息(可创建新的客户信息或根据要求更新已有客户信息)。数据存储代表ERD中的客户数据实体。在数据存储中的数据与客户数据实体的属性列表相对应。如果客户是一个已有的客户，数据就已经在数据存储中，所以过程就把这些数据读出。过程2.1就把有关订单的其他信息名叫“订单细节”的数据流发送给过程2.2。,过程2.2使用“订单细节”数据流并在“订单”数据存储中通过加入数据创建一个新的订单记录。然

12、后，对应于每一个订单条目，在“产品项目”、“库存项目”的数据存储中查询库存和产品价格。如果当前有足够的库存，就创建一个订单条目记录，同时库存数据要修改。重复这些步骤直到所有的条目处理完毕。例如如果有三个项目被预定，则需要创建一个订单记录和三个订单条目记录。,过程2.2根据订单(每一个条目的单价、时间、数量)累计总数，同时发送交易细节”的数据流到过程2.3以记录交易。“交易细节”包含订单号、数量和信用卡信息。过程2.3需要一个与信用部门保持实时连接以取得客户的信用卡的信用权限。这里用实时连接而不是数据流是因为在过程执行的时候数据需要很快的来回流动。如果信用卡是可用的，就在数据存储“订单交易”中创

13、建一条记录，同时一条交易数据流直接传到银行。,最后一个过程是处理给客户的订单确认信息和发给运输部门的订单细节。根据订单号过程2.4可以在订单、客户、每一个订单条目(加上产品条目中的条目描述)中查询数据和产生必要的输出。,10.2.6 评估DFD质量 高质量的DFD是可读的、内部一致的以及能准确表示系统需求的。表示的准确性主要取决于是否咨询了用户或其他博识的系统相关者。通过在DFD结构上应用一些简单的规则，一个项目小组可以保证DFD的可读性和内部一致性。分析员应该在开发DFD时或在准备好草图后的某一部分质量检查过程中使用这些规则。复杂性最小化人们对复杂的信息处理是有局限性的。当太多的信息同时出现

14、时，人们把这种现象叫做信息超量。当信息超量发生时，一个人很难理解呈现在面前的信息。避免信息超量的关键是把信息划分为小的且相对独立的子集，每一个子集有一定数量的可单独考察和理解的信息。,DFD分层结构是把信息划分为小的且相对独立的一大批子集例子，这样可以单独考察每一个DFD。读者要了解某个过程更加详细的信息可以跳转到该过程的下一层，如果要知道一个DFD如何与其他DFD相关联可以跳转到上一层的DFD去考察。分析员要在任何一个DFD中避免信息超量可以遵循以下两条DFD构造规则：72接口最小化,72规则(也称为Miller数)来源于心理学研究。心理学研究表明一个人可同时记住或操纵的信息“块”的数量介于

15、5到9之间。信息块的数量太大就要引起信息超量。信息块可以包括许多事情如名称、在一个列表中的单词、数字或一个图片中的各部分。72规则:模型设计规则，它限制模型中组成元素个数或元素之间的连接数不能超过972规则在DFD中的应用如下:单个DFD中不应有超过72个过程单个DFD不应超过72个数据流进出一个过程、数据存储和数据元素,接口最小化是与72规则直接相关的。接口是指一个问题或描述中的一部分与其他部分的连接。与信息块一样，一个人可同时记住或操纵的连接是有限的，所以连接数应保证最小。DFD中的过程表示业务和处理逻辑块，它们通过数据流与其他过程、实体和数据存储相关联。有大量接口(数据流)的单个过程会复

16、杂到不能理解。这也许会作为72规则的违反行为直接在过程分解中显现出来。分析员通常可以这样来解决这个问题，即把这种过程分解为二个或更多的过程;以使分解后的过程接口更少。接口最小化:模型设计的原则，该原则通过使模型中各个元素之间的接口放或连接数最小化来达到简单的目的。,过程成对或成组且在它们之间有大量的数据流是与接口最小化规则相冲突的另一个例子:通常这样的条件预示着过程中的任务处理划分都比较差。解决这个问题的办法是重新分配处理任务以使在它们之间需要更少的接口。在过程之间对工作的最好划分是保证最简单。而保证最简单的划分需要过程之间使用最少的接口。,数据流一致性 分析员通过查找DFD中各种类型的不一致

17、性可以发现错误或忽略的东西以下是三个经常发生且易 辨别的一致性错误:一个过程和它的过程分解在数据流内容中有差别有数据流出但没有相应的数据流入有数据流入但没有相应的数据流出过程分解以一种更详细的形式展示了一个高层过程的内部细节:在大多数情况下，DFD层次中流入和流出过程的数据内容应与分解后的DFD中流入和流出所有过程的数据内容一致，这种一致性叫做平衡，且高层的DFD与过程分解的DFD称为“在平衡中”。平衡:进出过程的数据流与进出过程分解DFD的数据流在数据内容上一致。,如果由于在高层忽略了一些数据流而引起数据流程图不平衡，则不平衡的DFD也是可接收的。例如一个大系统的0层图通常省略错误处理的细节

18、，如当订购了一件商品但库存量不够或者该商品不再继续生产，在0层图有一个过程叫“完成订单”，在这种情况下就没有任何相关的数据流，而在过程“完成订单”的分解图中系统分析员可以加上一个过程和一些数据流去处理这些下能继续的项目。,DFD不一致性还可以发生在单个过程或数据存储的数据流入或流出之间。根据定义，过程将输入数据转换成输出数据。在一个逻辑DFD中，数据不应该没有意义地传给过程。以下的一致性规则来源于这些事实：流入过程的所有数据必须流出该过程或用于产生流出该过程的数据。流出过程的所有数据必须曾流入过该过程或是由流入该过程的数据产生。,黑洞:带有输入数据的过程，但是数据的输入并不用来产生数据输出。,

19、奇迹:一个带有数据输出的过程，这个输出数据没有任何产生来源。,注意:上述两个一致性规则不仅仅用于过程，对数据存储也有效。任何从数据存储读出来的数据元素必定在以前写进去过。类似地，任何写进数据存储的数据元素必定在以后要读出来。考察进出数据存储的数据一致性会由于以下的事实而变得复杂:相同的数据元素也许能在完全不同的DFD上进出数据存储。,10.3详细记录DFD部件,在传统的方法中，数据流程图在一个图上描述了所有的三种类型的内部系统部件-过程、数据流和数据存储，但仍需要更进一步描述细节。首先，需要详细描述每一个最低层过程;其次，系统分析员需要根据数据流包含的数据元素来定义数据流。数据存储也需要根据数

20、据元素定义。最后，系统分析员也需要定义每一个数据元素。,过程描述在DFD中的每一个过程都必须正式地定义。定义过程有多个可选的方法，其中包括已经讨论过的过程分解。在过程分解中，一个高层的过程正式地由它分解出来的DFD定义，而这个低层的过程又可依次进一步分解成更低层的DFD。最终过程可以达到无需再由DFD定义的状态。当过程简单到足以用另一个过程的描述方法把它描述清楚时，就达到了这个状态。这些方法包括结构化英语、决策表和决策树。在这些方法中每一种过程都被描述成一个算法。最合适的方法应该具有以下的特点:紧凑、可读性好、无歧义。在大多数情况下，结构化英语是最好的方法。,结构化英语 非常仔细地使用简短语句

21、描述过程。结构化英语看起来像程序中的语句，但它用不着计算机的概念。在这里也要遵守结构化编程的规则，并且为了清楚也要求缩进。例如图10-19是一套选举后投票处理的简单指令。一些语句是非常简单的指令，有一些则包含重复的指令，其他的一些则涉及执行一套指令或其他指令。程序总是从最上面开始到最下面结束。所以，在这里应应用结构化编程的规则。注意，虽然它没必要是一个计算机程序(它可由一个人执行)但它仍是一个逻辑模型。这是明确的，所以任何人只要顺着这些指令都可以得到相同的结果。所以可以把他它看成一个算法。,处理投票程序收集所有投票把所有投票放进一个栈把Yes计数器和No汁数器置为零对栈中的每一个投票进行循环处

22、理if如果)是Yes，then(那么)给Yes计数数器加1Else(否则)给No计数器加1end if把投票放入己计数的栈End(结束)循环If(如果)Yes计数器的值比No计数器的值大then(那么)宣布Yes一方获胜Else(否则)宣布NO一方获胜Endif把已统计的投票栈存储到一个安全的地方处理投票程序结束,结构化英语非常适合用来描述带有一系列处理步骤和相对简单控制逻辑(如一个简单的循环语句或一个if-then-else语句)的过程。但结构化英语不适合描述有下列特点的过程:复杂的决策逻辑连续的处理步骤很少(或没有)当需要考虑大量的变量和这些变量许多可能的组合时，这样的决策逻辑就变得复杂起

23、来。如果使用结构化英语描述带有复杂决策逻辑的过程时势必会导致冗长且很难理解的描述。例如，描述相对较长且包含较多的控制语句(if，else,endif语句)。,决策表和决策树 可以比结构化英语更简捷地描述复杂决策逻辑。把决策逻辑描述为表或树的形式比相应的结构化英语的可读性要高。决策表更严密，但决策树更易读。有时，分析员在决定使用哪种方式最能准确地描述过程之前都应用这三种方法来描述该过程。,10.3.2 数据流定义 数据流是数据元素的集合，所以数据流定义将列出所有的数据元素。例如，一个简化了的“新订单”数据流包含客户名、信用卡号码和商品种类数及每一类的数量。一些数据元素实际上是其他数据元素的结构，

24、例如一个客户名包含首名、中间首字母和姓。大部分的这些数据元素由系统保存，所以它们与ERD中的数据实体属性一致。数据流定义:数据流内容和内部结构的文本描述。,数据元素定义数据元素定义描述数据类型，如字符型、整型、浮点型和布尔型。每一个元素应该清楚地表明它表示什么。有时这些描述非常特别。有时用订单收到时的支付日期定义售出日期。或者，售出日期也可以是订单发出的日期。有时在同一个公司不同的部门对同一个元素有不同的定义，所以对分析员来说，确切地说明元素的意义是很重要的。数据元素定义的其他部分根据数据类型的不同而不同。字符型通常要定义其长度。例如中间首字母可能最多只需要一个字符的大小，但是首名要多长才合适

25、呢?数值通常要定义其最大和最小值作为其有效范围。有时，某个元素允许一个特殊的值，例如有效码。如果这个元素是一个代码，则定义有效码及其意义是非常重要的。例如，代码A表示立即发运，代码B表示存放一天，代码c表示需要紧急确认的发运。,数据存储定义 由于在DFD中的数据存储在ERD中表示数据实体，所以它无需特别的定义(除了给读者一些有关ERD的提示)。如果数据存储与ERD不相关联，则分析员可以用定义数据流的方法把数据存储定义为一个元素集合(可能使用一个结构)。,10.4信息工程模型,信息工程方法在开发时主要侧重于策略系统计划和系统的数据需求上。信息工程(IE)在八十年代初由Jams Martin开发。

26、在那时，ie与结构化系统开发方法虽然有很多共同的特性但却被认为是相互竟争的。由于两种方法都比较成熟，所以许多分析员开始寻求将两者最好的特性结合。这一节给出了IE方法的一个概览并描述一些IE系统模型，随后描述如何将它用于本章前面的结构化分析模型中。,10.4.1 IE系统开发生命周期,信息工程系统升发生命周期的各个阶段,上图显示了IE系统开发生命周期(SDLC)的各个阶段。IE系统开发生命周期的第一个阶段集中往对全企业建模和创建协调的信息系统计划。企业根据它的策略目标、计划、信息技术设施、存储的数据需求和主要的功能区域建立模型。数据和功能模型中的交叉部分使用在IE系统开发生命期中第二阶段的进一步

27、分析确定明确的业务范围上。,在IE系统开发生命周期的第一阶段出现的两个关键特性是它把业务作为一个整体来关注并注重数据存储。IE首先根据企业的策略、计划、目标、现状和组织结构描述企业和它的环境，然后才开始详细说明信息技术设施和信息处理应用的需求。集中考察数据存储基于这样的一个假设:业务数据是一种有组织的资源，它不像业务过程那样经常变化。内部和外部数据需求被假定用于引起处理需求和过程结构，但反之不成立。,IE系统开发生命周期的第二步是描述在企业中的每一个业务范围的处理需求。每一个业务范围被分解为相关过程的一个层次。过程分解模型描述层次，过程依赖摸型描述过程之间的内部关系，数据使用模型集描述过程和数

28、据之间的关系。IE系统开发生命周期的第三步是开发业务过程的详细设计。IE使用很多不同的技术和模型描述过程。这些方法强调用户输入过程设计和过程模型的正确性。开发人员开发图形化过程模型，用户检查这些模型是否正确。,IE系统开发生命周期的最后一步是系统构建。IE法使用CASE工具和代码生成器实现构建阶段。过程模型和在前一阶段开发的原型用于自动生成系统部件。代码生成器以CASE工具开发出来的数据和过程模型作为输入，以产生的应用程序和数据库创建命令作为输出。以前IE曾经以过程性编程语言(如COBOL和C)和关系型数据库管理系统作为目标，后来的IE CASE工具和代码生成器以面向对象环境作为目标。,10.

29、4.2 lE和结构化开发的比较IE和结构化方法之间的重要差别是它们的范围。IE设计用来说明企业级信息处理需求，它的第一步把企业作为一个整体并且根据组织结构、目标和策略来描述数据和信息处理。信息工程和结构化方法的比较,信息工程 结构化方法什么样的系统规格最合适?全企业 任意它与公司战略计划一致?是 否技术和模型相互间结合紧密吗?高度紧密 中等紧密分析的重点是什么?数据 过程其他的方法论的技术可以很容易 否 是 结合进来吗?,相比之下，结构化方法既不对应用程序的范围做假设，也不对先于结构化分析的计划活动做假设。结构化方法可以适应于整个企业、企业内相对较小的系统或介于两者之间的任何系统。结构化分析不

30、需要明确企业级的计划和描述活动。所以，它的模型不直接与企业的组织结构、企业策略和目标、现有的和计划的信息技术设施等信息结合。,两种方法论的另一个重要差别是相应的工具和技术如何紧密结合起来。IE的紧密集合表现在:前一阶段的输出是下一个阶段的输入。这种方法论是完整的且是全封闭的。所以，在IE内引入其他技术或模型是非常困难的(且通常是不必要的)。相反，在结构化方法中所有的技术或模型只是中等程度地结合在一起。在这此方法中是有许多间隙，因此从像IE之类的其他方法中引入技术或模型足可能的(且通常是理想的)。,在IE的第一阶段一个企业的ERD就开发出来了。这个模型提供了一些信息，这些信息在以后的建模和设计过

31、程中将广泛使用。结构化分析也开发和使用ERD。尽管在结构化方法中它的作用不如在IE方法中这么重要。因为两种方法均使用ERD，所以我们就可能在结构化方法中引入ERD的IE模型。,10.4.3 过程分解和依赖模型 与结构化分析相比，IE使用不同的方法去建立过程模型。IE过程模型显示了三种类型的信息:过程分解为其他过程过程间的依赖关系内部处理逻辑,分析员首先通过把业务领域分解成补充过程来进行业务范围的模型化。下图是RMO客户支持系统的过程分解图例子。图中显示系统(业务领域)被分解成几个主要的子系统。订单输入子系统被进一步分解成能轮流分解的过程。在图中，左上角有三点的过程表明该过程的进一步分解画在另外

32、的纸上。,过程依赖图:用存储实体描述过程顺序和交互的一种模型。下图是一个名为“创建新订单”的过程依赖图，这个图对应于图10-15所示的过程分解图“创建新订单”。在图中标有“收到订单”的大箭头表示触发第一个过程事件，连接过程的线和箭头表示过程之间的依赖关系。过程“产品确认”依赖于“处理订单交易”，即表示直到“处理订单交易处理完毕“产品确认”才可以开始。,依赖关系与数据流的差别是微妙的但也是重要的。过程依赖图不直接展示过程之间的数据流。“产品确认”依赖于“处理订单交易”是因为确认一个没有完成的订单(例如一个信用仍没有通过验证的订单)是没有意义的。即使一个过程产生数据另一个过程使用数据，这种过程之间的数据流也不直接反映在过程依赖图中。,