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

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

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

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

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

4、其他的过程模型如 在信息工程中使用的过程依赖图和用于业 务流程再造的工作流程图，但数据流程图 是最常用的过程模型。 外部实体 :在系统边界之外的个人或组织， 它提供数据输入或接受数据输出。 过程 :在 DFD中的一个符号，它代表从数据 输入转换到数据输出的算法或程序。 数据流 :在 DFD中的箭头，它表示在过程、 数据存储和外部实体之间的数据移动。 数据存储 :保存数据的地方，以便将来由一 个或多个过程来访问这些数据。 过程 数据流 一步步地执行指令。将输入换成输出 (由人、机器或这两者完成这个工作 ) 从一处到另一处的数据流向，如从输入或输 出到一个过程的数据流 系统之外的数据源或目的 外部

5、实体 数据存储 存放数据的地方，这些数据在以后使用，通 常与实体 -联系图中的一个数据实体祖对应 实时连接 当过程执行时，外部实体与过程之间来回通 信 (如信用卡验证 ) 一个 DFD演示处理“查找可用条目” 1 客户 查询可用条目 条目查询 可用条目细节 目录 产品条目 库存条目 这个事件是客户想检查可用条目，触发器是条目 查询，来源是客户，响应是可用条目细节，响应 的目标是客户。所以，这个数据流程图以一个图 形方式响应一个事件来显示系统活动。 但是 DFD的另一个信息没有包含在事件表中。数 据存储包括条目可用性的信息。每一个数据存储 在实体一联系图 (ERD)中代表一个数据实体。在 DFD

6、中的过程使用了在 ERD中我们所提供的数据 实体及其属性信息。所以，数据流程图将事件触 发的过程和在 ERD中定义的数据实体相结合。下 图总结了 DFD的组成部分、在事件表中描述的事 件及在 ERD中定义的数据实体这三者的一致性。 客户 查询可用条目 条目查询 可用条目细节 目录 产品条目 库存条目 外部实体、数据流、和过程来自于事件 表中有关事件的信息 数据存储来自于实体一联系图 来源 触发器 动作 目的地 响应 10 .2.1数据流程图和抽象水平 抽象水平 :能把系统分解成一个逐渐细化的分层集 合的建模技术。 有许多种类型的数据流程图用于描述系统需求。 刚才描述的例子是 DFD的一部分，它

7、显示了响应 一个事件的过程。其他的数据流程图用于显示一 个更高层 (系统更概括的概念 )或更低层 (系统更详 细的概念 )的处理。这些不同的系统概念 (高层的 和低层的 )被认为是 抽象水平 。数据流程图的另一 个非常有用的特性是能够表现系统高层和低层概 念。在一个 DFD中高层次过程可以分解成若干独 立的、低层次的、详细的 DFD，详细的 DFD中的 过程可以进一步分解成其他的图形以便提供多层 次或多水平的抽象。 10.2.2关联图 关联图 是指描述系统高层结构的 DFD。所 有的外部实体和进出系统的数据流都画在 一张图中，并且整个系统被表示成一个过 程。如图显示了一个简单的大学课程注册 系

8、统的关联图，这个图与三个外部实体交 互 :学术部、学生和教员。学术部提供有关 课程的信息，学生申请注册，教员在注册 完成后得到班级列表。 学术部 教员 时间表数据 班级列表 课程注册系统 0 注册请求 时间表 学生 图 10-5大学课程注册系统的关联图 关联图在表达系统边界时很有用。系统的 范围是通过单过程和外部实体所表示的事 物来定义的。提供和接收数据的外部实体 在系统范围以外，其他任何事情属于系统 的范围。 数据存储不画在关联图中是因为数据存储 本身被认为是属于系统内部的。在系统计 划阶段，我们将关联图当做确定新系统范 围的工具使用。 10.2.3 DFD片段 一个 DFD片段是为事件清单

9、 (扩展为事件表 ) 中的每个事件创建的。每个 DFD片段是 一个显示系统如何响应某个事件的独立模 型。分析员通常是一次创建一个 DFD片段， 这样能将精力集中在系统的一个部分中。 下图显示了课程注册系统的三个 DFD片段。 每一个 DFD片段在一个过程符号中代表对 一个事件的所有响应过程。但是这些片段 展示厂在过程、外部实体和内部数据存储 之间的交互细节。在 DFD片段中的数据存 储代表 ERD中的实体。每个 DFD片段仅显 示要响应该事件的那些数据存储。 学术部 计划课程 提供的课程 1 计划安排 数据 课程注册 教员 产生班级列表 3 班级列表 学生 提供的课程 计划课程 提供的课程 计

10、划安排 数据 学生 注册学生 2 学生 提供的课程 课程注册 注册请求 计划安排 图 10-7课程注册系统的 DFD片段 10.2.4事件划分的系统模型 DFD片段的完全集可以组合到一个叫做事件 划分的系统模型或 0层图中。 0层图通常在单个的 DFD中显示完整的系统，它比关联图包含更多的 细节。图 10-10显示了四个相关的 DFD以展示每一 层是如何为上一层提供更进一步的信息的。最高 层的 DFD就是大学课程注册系统的关联图。紧接 在关联图下方的 DFD是事件划分系统模型（或 0层 图）。注意 0层图实际上是关联图中对过程的分解， 它也是图 10-7中的三个 DFD片段的一个组合。在 0

11、层图中的每一个过程表示处理一个事件。 教员 学术部 学生 课程注册 系统 班级列表 课程安排数据 注册请求 课程安排 0 关联图 课程安排 课程注册 注册学生 2 班级 列表 注册请求 课程安排 学生 教员 提供的课程 学生 产生班级 列表 3 学术部 1 课程安 排数据 0层图 学术部 课程安排 提供的课程 课程安排数据 1 学术部 选择日期和 时间 1.1 分配教员 1.2 提供的课程 分配教室 1.3 课程 可用教员 可用教室 学术部 DFD片断 1 图 1 在图 10-10中的第三个 DFD展示了对应与 0层图中 过程 1的一个 DFD片段。由于在 0层图中有三个过 程，因此，应该有三

12、个独立的 DFD片段，每一个 对应于一个过程或事件。但在图中只画了一个 DFD片段。在这个 DFD的下面是过程 1中的一个 分解。 创建一个 DFD是用来描述系统如何分解为子系统。 一旦子系统的 DFD创建好，系统分析员就为每一 个子系统画一个独立的事件划分 DFD。当子系统 定义好， DFD集合就一个个相互联结起来。关联 图分解为一个子系统 DFD，而子系统 DFD进一步 分解为事件划分的 DFD集合。没有单独的 0层图。 相反，每一个子系统有一个事件划分的 DFD。本 质上来说，一个事件划分的 DFD是一个子系统的 0 层图。 10.2.5 分解过程以查看一项活动更详细的信 息 有时一些

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

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

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

16、要很快的来回流动。如果信用卡是 可用的，就在数据存储“订单交易”中创建一条 记录，同时一条交易数据流直接传到银行。 最后一个过程是处理给客户的订单确认信 息和发给运输部门的订单细节。根据订单 号过程 2.4可以在订单、客户、每一个订单 条目 (加上产品条目中的条目描述 )中查询数 据和产生必要的输出。 10.2.6 评估 DFD质量 高质量的 DFD是可读的、内部一致的以及能准确 表示系统需求的。表示的准确性主要取决于是否 咨询了用户或其他博识的系统相关者。通过在 DFD结构上应用一些简单的规则，一个项目小组 可以保证 DFD的可读性和内部一致性。分析员应 该在开发 DFD时或在准备好草图后的

17、某一部分质 量检查过程中使用这些规则。 复杂性最小化 人们对复杂的信息处理是有局限 性的。当太多的信息同时出现时，人们把这种现 象叫做信息超量。当信息超量发生时，一个人很 难理解呈现在面前的信息。避免信息超量的关键 是把信息划分为小的且相对独立的子集，每一个 子集有一定数量的可单独考察和理解的信息。 DFD分层结构是把信息划分为小的且相对独立的 一大批子集例子，这样可以单独考察每一个 DFD。 读者要了解某个过程更加详细的信息可以跳转到 该过程的下一层，如果要知道一个 DFD如何与其 他 DFD相关联可以跳转到上一层的 DFD去考察。 分析员要在任何一个 DFD中避免信息超量可以遵 循以下两条

18、 DFD构造规则： 7 2 接口最小化 7 2规则 (也称为 Miller数 )来源于心理学研究。心 理学研究表明一个人可同时记住或操纵的信息 “块”的数量介于 5到 9之间。信息块的数量太大 就要引起信息超量。信息块可以包括许多事情如 名称、在一个列表中的单词、数字或一个图片中 的各部分。 7 2规则 :模型设计规则，它限制模型中组成元素 个数或元素之间的连接数不能超过 9 7 2规则在 DFD中的应用如下 : 单个 DFD中不应有超过 7 2个过程 单个 DFD不应超过 7 2个数据流进出一个过程、数据 存储和数据元素 接口最小化 是与 7 2规则直接相关的。接口是指 一个问题或描述中的一

19、部分与其他部分的连接。 与信息块一样，一个人可同时记住或操纵的连接 是有限的，所以连接数应保证最小。 DFD中的过 程表示业务和处理逻辑块，它们通过数据流与其 他过程、实体和数据存储相关联。有大量接口 (数 据流 )的单个过程会复杂到不能理解。这也许会作 为 7 2规则的违反行为直接在过程分解中显现出 来。分析员通常可以这样来解决这个问题，即把 这种过程分解为二个或更多的过程 ;以使分解后的 过程接口更少。 接口最小化 :模型设计的原则，该原则通过使模型 中各个元素之间的接口放或连接数最小化来达到 简单的目的。 过程成对或成组且在它们之间有大量的数 据流是与接口最小化规则相冲突的另一个 例子

20、:通常这样的条件预示着过程中的任务 处理划分都比较差。解决这个问题的办法 是重新分配处理任务以使在它们之间需要 更少的接口。在过程之间对工作的最好划 分是保证最简单。而保证最简单的划分需 要过程之间使用最少的接口。 数据流一致性 分析员通过查找 DFD中各种类型的 不一致性可以发现错误或忽略的东西以下是三个 经常发生且易 辨别的一致性错误 : 一个过程和它的过程分解在数据流内容中有差别 有数据流出但没有相应的数据流入 有数据流入但没有相应的数据流出 过程分解以一种更详细的形式展示了一个高层过 程的内部细节 :在大多数情况下， DFD层次中流入 和流出过程的数据内容应与分解后的 DFD中流入 和

21、流出所有过程的数据内容一致，这种一致性叫 做平衡，且高层的 DFD与过程分解的 DFD称为 “在平衡中”。 平衡 :进出过程的数据流与进出过程分解 DFD的数 据流在数据内容上一致。 如果由于在高层忽略了一些数据流而引起 数据流程图不平衡，则不平衡的 DFD也是 可接收的。例如一个大系统的 0层图通常省 略错误处理的细节，如当订购了一件商品 但库存量不够或者该商品不再继续生产， 在 0层图有一个过程叫“完成订单”，在这 种情况下就没有任何相关的数据流，而在 过程“完成订单”的分解图中系统分析员 可以加上一个过程和一些数据流去处理这 些下能继续的项目。 DFD不一致性还可以发生在单个过程或数 据

22、存储的数据流入或流出之间。根据定义， 过程将输入数据转换成输出数据。在一个 逻辑 DFD中，数据不应该没有意义地传给 过程。以下的一致性规则来源于这些事实： 流入过程的所有数据必须流出该过程或用于产 生流出该过程的数据。 流出过程的所有数据必须曾流入过该过程或是 由流入该过程的数据产生。 A,B,C,X X 计算 X 过程详述 If A5 Then X=X*1.05 Else X=X*1.10 Endif 黑洞 :带有输入数据的过程，但是数据的输入并不用 来产生数据输出。 A A,B,Y 计算 Y 过程详述 If A5 Then X=100 Else Y=250 Endif 奇迹 :一个带有数

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

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

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

26、。 处理投票程序 收集所有投票 把所有投票放进一个栈 把 Yes计数器和 No汁数器置为零 对栈中的每一个投票进行循环处理 if 如果 )是 Yes， then(那么 ) 给 Yes计数数器加 1 Else(否则 ) 给 No计数器加 1 end if 把投票放入己计数的栈 End(结束 )循环 If(如果 )Yes计数器的值比 No计数器的值大 then(那么 ) 宣布 Yes一方获胜 Else(否则 ) 宣布 NO一方获胜 Endif 把已统计的投票栈存储到一个安全的地方 处理投票程序结束 结构化英语非常适合用来描述带有一系列处理步 骤和相对简单控制逻辑 (如一个简单的循环语句或 一个 i

27、f-then-else语句 )的过程。但结构化英语不适 合描述有下列特点的过程 : 复杂的决策逻辑 连续的处理步骤很少 (或没有 ) 当需要考虑大量的变量和这些变量许多可能的组 合时，这样的决策逻辑就变得复杂起来。如果使 用结构化英语描述带有复杂决策逻辑的过程时势 必会导致冗长且很难理解的描述。例如，描述相 对较长且包含较多的控制语句 (if， else , endif语 句 )。 决策表和决策树 可以比结构化英语更简捷 地描述复杂决策逻辑。把决策逻辑描述为 表或树的形式比相应的结构化英语的可读 性要高。决策表更严密，但决策树更易读。 有时，分析员在决定使用哪种方式最能准 确地描述过程之前都应

28、用这三种方法来描 述该过程。 10.3.2 数据流定义 数据流是数据元素的集合，所以数据流定义将列 出所有的数据元素。例如，一个简化了的“新订 单”数据流包含客户名、信用卡号码和商品种类 数及每一类的数量。 一些数据元素实际上是其他数据元素的结构，例 如一个客户名包含首名、中间首字母和姓。大部 分的这些数据元素由系统保存，所以它们与 ERD 中的数据实体属性一致。 数据流定义 :数据流内容和内部结构的文本描述。 10.3.3数据元素定义 数据元素定义描述数据类型，如字符型、整型、浮点型和 布尔型。每一个元素应该清楚地表明它表示什么。有时这 些描述非常特别。有时用订单收到时的支付日期定义售出 日

29、期。或者，售出日期也可以是订单发出的日期。有时在 同一个公司不同的部门对同一个元素有不同的定义，所以 对分析员来说，确切地说明元素的意义是很重要的。 数据元素定义的其他部分根据数据类型的不同而不同。字 符型通常要定义其长度。例如中间首字母可能最多只需要 一个字符的大小，但是首名要多长才合适呢 ?数值通常要 定义其最大和最小值作为其有效范围。有时，某个元素允 许一个特殊的值，例如有效码。如果这个元素是一个代码， 则定义有效码及其意义是非常重要的。例如，代码 A表示 立即发运，代码 B表示存放一天，代码 c表示需要紧急确认 的发运。 10.3.4数据存储定义 由于在 DFD中的数据存储在 ERD中

30、表示数 据实体，所以它无需特别的定义 (除了给读 者一些有关 ERD的提示 )。如果数据存储与 ERD不相关联，则分析员可以用定义数据 流的方法把数据存储定义为一个元素集合 (可能使用一个结构 )。 10.4信息工程模型 信息工程方法在开发时主要侧重于策略系 统计划和系统的数据需求上。信息工程 (IE) 在八十年代初由 Jams Martin开发。在那时， ie与结构化系统开发方法虽然有很多共同的 特性但却被认为是相互竟争的。由于两种 方法都比较成熟，所以许多分析员开始寻 求将两者最好的特性结合。这一节给出了 IE 方法的一个概览并描述一些 IE系统模型，随 后描述如何将它用于本章前面的结构化

31、分 析模型中。 10.4.1 IE系统开发生命周期 IS策略计划 实体 -联系食型 企业模型 系统开发优先考 虑内容 过程模型原型 过程分解模型 过程依赖模型 数据使用模型 阶段 1 系统规划 阶段 2 业务领域分析 阶段 4 系统构建 阶段 3 系统设计 信息工程系统升发生命周期的各个阶段 上图显示了 IE系统开发生命周期 (SDLC)的 各个阶段。 IE系统开发生命周期的第一个阶 段集中往对全企业建模和创建协调的信息 系统计划。企业根据它的策略目标、计划、 信息技术设施、存储的数据需求和主要的 功能区域建立模型。数据和功能模型中的 交叉部分使用在 IE系统开发生命期中第二阶 段的进一步分析

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

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

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

35、分析的计 划活动做假设。结构化方法可以适应于整 个企业、企业内相对较小的系统或介于两 者之间的任何系统。结构化分析不需要明 确企业级的计划和描述活动。所以，它的 模型不直接与企业的组织结构、企业策略 和目标、现有的和计划的信息技术设施等 信息结合。 两种方法论的另一个重要差别是相应的工 具和技术如何紧密结合起来。 IE的紧密集合 表现在 :前一阶段的输出是下一个阶段的输 入。这种方法论是完整的且是全封闭的。 所以，在 IE内引入其他技术或模型是非常困 难的 (且通常是不必要的 )。相反，在结构化 方法中所有的技术或模型只是中等程度地 结合在一起。在这此方法中是有许多间隙， 因此从像 IE之类的

36、其他方法中引入技术或模 型足可能的 (且通常是理想的 )。 在 IE的第一阶段一个企业的 ERD就开发出 来了。这个模型提供了一些信息，这些信 息在以后的建模和设计过程中将广泛使用。 结构化分析也开发和使用 ERD。尽管在结 构化方法中它的作用不如在 IE方法中这么重 要。因为两种方法均使用 ERD，所以我们 就可能在结构化方法中引入 ERD的 IE模型。 10.4.3 过程分解和依赖模型 与结构化分析相比， IE使用不同的方法去建 立过程模型。 IE过程模型显示了三种类型的 信息 : 过程分解为其他过程 过程间的依赖关系 内部处理逻辑 分析员首先通过把业务领域分解成补充过 程来进行业务范围的

37、模型化。下图是 RMO 客户支持系统的过程分解图例子。图中显 示系统 (业务领域 )被分解成几个主要的子系 统。订单输入子系统被进一步分解成能轮 流分解的过程。在图中，左上角有三点的 过程表明该过程的进一步分解画在另外的 纸上。 过程依赖图 :用存储实体描述过程顺序和交互的一 种模型。 下图是一个名为“创建新订单”的过程依赖图， 这个图对应于图 10-15所示的过程分解图“创建新 订单”。在图中标有“收到订单”的大箭头表示 触发第一个过程事件，连接过程的线和箭头表示 过程之间的依赖关系。过程“产品确认”依赖于 “处理订单交易”，即表示直到“处理订单交 易处理完毕“产品确认”才可以开始。 依赖关系与数据流的差别是微妙的但也是 重要的。过程依赖图不直接展示过程之间 的数据流。“产品确认”依赖于“处理订 单交易”是因为确认一个没有完成的订单 (例如一个信用仍没有通过验证的订单 )是没 有意义的。即使一个过程产生数据另一个 过程使用数据，这种过程之间的数据流也 不直接反映在过程依赖图中。