图4.1 数据流图图元
接口:用直角矩形表示。这里接口可以是与其它信息系统的接口,也可以是角色(人机接口)。
l 进程:一般用椭圆表示,但Visio中用圆角矩形表示,可能是考虑椭圆中可以容纳的字比较少的原因。数据流图中的矩形一般表示一个功能模块或一个过程,对应一个或一组动作。
l 数据存储:用右边开口的矩形表示,表示数据库中存储的对象。另外在数据流图中,如果一个存储过程在同一个图中出现多次(主要是防止画的线交叉),还经常在在矩形左侧向右一点加个竖直线表示,但Visio中没有做区别。
l 数据流:用带箭头的直线表示,表示数据的流动方向。
5.数据流图举例
这是教科书上的一个例子(王珊,《数据库系统概论》),某厂管理信息系统包括三个模块:销售管理子系统、劳动人事管理子系统和物资子系统。其中销售子系统的基本需求是:
(1) 处理顾客和销售员送来的订单。
(2) 工厂是根据订货(订单)安排生产的。
(3) 交出货物同时开出发票,并记入应收帐款。
(4) 收到顾客付款后,根据发票存根和信贷情况进行应收帐款处理。
这个需求太笼统了,我们逐步细化这个需求,并采用数据流图作为辅助分析手段。
5.1 销售管理子系统第一层数据流图
图5.1 第一层数据流图
该图的绘制依据以下需求(可以将下面的描述与图形对比以理解图形):
(1) 不管是顾客还是销售员送来的订单,发起者都是顾客,销售员只是顾客的一个代理,因此系统都认为是顾客送来的订单。
(2) 顾客送来订单后,订单数据进入1.0(送进订单)模块进行处理。这里编号为1.0是为了后续分析方便,如果这个模块还能细分处其它子功能,则编号为1.n。
(3) 主管部门在送进订单模块对订单进行核对,主要核对价格是否正确,以及顾客账目状况(是否拖欠了太多应收帐款),因此要参考产品描述信息和应收帐款信息。这里我们就发现了两个需要存储的对象。
(4) 主管部门审核后,告知1.0模块(一般是点个按钮),不管批准与否,都要通知顾客。
(5) 已批准订单送入2.0模块进行处理。
(6) 2.0模块首先将订单信息保存,存入“订单记录本”。同时生成生产通知单,发送给生产部门以进行生产。
(7) 生产部门的生产是一个封闭过程,该系统无法控制。生产完成后,开具发票。
(8) 开发票时,一方面要调整应收帐款(财务术语,只要开了发票,就是应收帐款;付款后冲抵掉应收帐款);另一方面,生成包装通知单(包括发票、产品说明等、配件说明等)发送给顾客。
(9) 顾客结算数据时,使用支付过账模块(4.0),调整应收帐款。
(10) 另外系统需要提供一个应收帐款辅助模块,用于:为主管部门生成应收帐款报表;若实际业务往来中出现漏操作的情况,手工调整未付差额,并将财务变动通知顾客。
图中两个“应收帐款”是同一个数据存储,画到一起数据线会出现大量交叉的情况,所以画了两个。
下面我们看一下各个功能模块是否可以细分。
5.2 接收订单
这个对应第一层数据流图的1.0模块,对顾客来说,在第一层数据流图中名为“送进订单”,但对于我们的系统来说,称为“接收订单”更确切一些。
这一步的过程是:主管部门拿着用户(或销售员)填写的订单,调出价格信息和该顾客账目信息进行核对,决定是否批准,然后将订单的某一联反馈给顾客(毕竟顾客没有操作这个系统的权限,只好手工处理了)。对已批准的订单,送入下一步进行处理(2.0)。
图5.2 接收订单
顾客送进订单数据后,首先核对价格,这时要参考“产品描述”里面存储的价格信息。
(2) 价格核对后,核对顾客账目状况,看一下该顾客是否拖欠了太多款项,这时要参考“应收帐款”信息。
(3) 账目已核对的订单,将价格和账目的核对情况,发送给主管部门,由主管部门决定是否批准。
(4) 不管是否批准,都要通知顾客。
(5) 已批准订单送入2.0(处理订单)。
5.3 处理订单
已批准的订单进行登记,并分配工种(如车工、钳工、焊工、电工等),生成生产通知单发送给生产部门安排生产。同时生成待完成订货清单,供生产部门参考。
生产完成后由生产部门将数据送入下一环节:开发票(3.0)。
5.4 开发票
图5.4 开发票
生产完成后,开具发票。开发票后合同额即记入应收帐款,同时将发票信息存入发票主清单,并由系统生成包装通知单信息提供给顾客。
开发票后将发票分配一个发票号(当然现在的发票都是全国统一编号,每张发票事先都已经编好号了,呵呵),并记人发票记录本。
5.5 支付过账
顾客结算时有两种方式:支付货款或信贷。
支付货款后,系统记入贷方余额,具体操作是调整应收帐款信息。如果信贷,需要根据有个审批环节,如果批准,则记入借方余额,操作也是调整应收帐款(似乎这个地方不用调整,因为开发票时已经调整了)。
5.6 提供应收帐款
这步不能进一步细化,已经完成。