第8章系统分析与建模-《信息管理与管理信息系统》.ppt

信息管理与管理信息系统 李联宁 编著 8.5.4.1 数据流图 组成数据流图的元素可以从描述问题的信息中提取 8.5.4.1 数据流图 任何计算机系统实质上都是信息处理系统，也就是说计算机系统本质上都是把输入数据变换成输出数据。 因此，任何系统的基本模型都由若干个数据源点/终点以及一个处理组成，这个处理就代表了系统对数据加工变换的基本功能。对于上述的定货系统可以画出下图这样的基本系统模型。 8.5.4.1 数据流图 上图毕竟太抽象了，从这张图上对定货系统所能了解到的信息非常有限。下一步应该把基本系统模型细化，描绘系统的主要功能。 “产生报表”和“处理事务”是系统必须完成的两个主要功能，它们将代替上图 中的“定货系统”，见下图. 8.5.4.1 数据流图 接下来对系统主要功能进一步细化。把“处理事务”这个功能分解为下述3个步骤，这在逻辑上是合理的： “接收事务”、“更新库存清单” 、 “处理定货” 8.5.4.1 数据流图 3. 命名 在命名时应注意的问题： （1） 为数据流(或数据存储)命名 ① 名字应代表整个数据流(或数据存储)的内容。 ② 不要使用空洞的、缺乏具体含义的名字(如“数据”、“信息”、“输入”之类)。 ③ 如果在起名字时遇到了困难，则很可能是因为对数据流图分解不恰当造成的，应该试试重新分解。 8.5.4.1 数据流图 （2）为处理命名 ① 通常先为数据流命名，然后再为与之相关联的处理命名。体现了人类习惯的“由表及里”的思考过程。 ② 名字应该反映整个处理的功能，而不是它的一部分功能。 ③ 名字最好由一个具体的及物动词加上一个具体的宾语组成。应该尽量避免使用“加工”、“处理”等空洞笼统的动词作名字。 8.5.4.1 数据流图 ④ 通常名字中仅包括一个动词，如果必须用两个动词才能描述整个处理的功能，则把这个处理再分解成两个处理可能更恰当些。 ⑤ 如果在为某个处理命名时遇到困难，则很可能是发现了分解不当的迹象，应考虑重新分解。 8.5.4.1 数据流图 （3）为数据源点/终点命名 通常，为数据源点/终点命名时采用它们在问题域中习惯使用的名字(如“采购员”、“仓库管理员”)。 8.5.2 对象模型 ③ 限定关联 限定关联通常用在一对多或多对多的关联关系中，可以把模型中的重数从一对多变成一对一，或从多对多简化成多对一。在类图中把限定词放在关联关系末端的一个小方框内。 例如，某操作系统中一个目录下有许多文件，一个文件仅属于一个目录，在一个目录内文件名确定了惟一一个文件。下图利用限定词“文件名”表示了目录与文件之间的关系。 8.5.2 对象模型 ④ 关联类 为了说明关联的性质可能需要一些附加信息。可以引入一个关联类来记录这些信息。关联中的每个连接与关联类的一个对象相联系。关联类通过一条虚线与关联连接。 例如，下图是一个电梯系统的类模型，队列就是电梯控制器类与电梯类的关联关系上的关联类。 8.5.2 对象模型 关键类示例 8.5.2 对象模型 从图中可以看出，一个电梯控制器控制着4台电梯，这样，控制器和电梯之间的实际连接就有4个，每个连接都对应一个队列(对象)，每个队列(对象)存储着来自控制器和电梯内部按钮的请求服务信息。 电梯控制器通过读取队列信息，选择一个合适的电梯为乘客服务。 关联类与一般的类一样，也有属性、操作和关联。 8.5.2 对象模型 （2）聚集 聚集也称为聚合，是关联的特例。聚集表示类与类之间的关系是整体与部分的关系。 在陈述需求时使用的“包含”、“组成”、“分为……部分”等字句，往往意味着存在聚集关系。 除了一般聚集之外，还有两种特殊的聚集关系，分别是共享聚集和组合聚集。 8.5.2 对象模型 ① 共享聚集 如果在聚集关系中处于部分方的对象可同时参与多个处于整体方对象的构成，则该聚集称为共享聚集。 例如，一个课题组包含许多成员，每个成员又可以是另一个课题组的成员，则课题组和成员之间是共享聚集关系，如下图所示。一般聚集和共享聚集的图示符号，都是在表示关联关系的直线末端紧挨着整体类的地方画一个空心菱形。 8.5.2 对象模型 ② 组合聚集 如果部分类完全隶属于整体类，部分与整体共存，整体不存在了部分也会随之消失(或失去存在价值了)，则该聚集称为组合聚集(简称为组成)。 例如，在屏幕上打开一个窗口它就由文本框、列表框、按钮和菜单组成，一旦关闭了窗口，各个组成部分也同时消失，窗口和它的组成部分之间存在着组合聚集关系。 8.5.2 对象模型 下图是窗口的组成，从图上可以看出，组成关系用实心菱形表示。 组合聚集示例 8.5.2 对象模型 （3）泛化 UML中的泛化关系就是通常所说的继承关系，它是通用元素和具体元