该系列计划包括5部分:完整性约束理论及应用、范式理论及应用、需求分析、概念结构设计、逻辑结构设计。本文是第三部分,介绍需求分析中如何借助数据流图发现存储对象的方法。
1.引言
不管对数据库设计还是对系统设计来说,需求分析都是第一步。需求的目的就是搞清楚用户要做什么,如果需求做的仔细,可以在后面的设计和实现中少做很多无用功,其重要性是不言自明的。
需求分析的方法在软件工程中都有说明,不管哪种方法,最重要的都是与用户的沟通和交流,引导用户正确的确认问题。做需求分析需要有点心理学的知识,这里我就不啰嗦了。
本文的重点在于如何通过需求分析,找出需要存储的数据。
2.工具选择
对于与用户的交流来说,需求分析阶段比较直观的工具是UML中的用例图。其优点非常明显,就是用图形方式表示功能和角色,需求分析人员和用户都能非常容易的读懂并以此交流(当然我说的是草图设计,不是蓝图设计或基于程序的设计)。
那么我们看一下UML是否能很好的支持数据库设计——这点要从UML设计过程分析。有了用例图,我们得到的是系统的功能需求,而且仔细的话,我们可以做的很好。那么下一步,一般是通过时序图(也有翻译成顺序图或序列图的)发现系统中的对象。这种图向用户简单说明也很容易理解和交流。发现了系统中的对象后,就可以进行类图的设计了。类图是系统中对象的抽象,一般可以与编码实现的类和对象对应起来。
这是一个完美的设计过程,方便交流,还容易转换为编码。但是,我们从这个过程也可以看到,UML没有涉及数据库的设计过程。那么是不是可以把在时序图中发现的对象转换为数据库实体(表)呢?我们分析一下这些对象的特点,会发现这些对象对应的是我们设计的应用程序内存中保存的对象,而内存中的对象,有些可以简单的和数据库表对应,但大部分却是几个表的组合——对应的是数据库中的视图。
对用户来说,表和视图是不必区分的,用户只关心看到的数据,这也是UML与用户容易交流的一个原因。但对于数据库设计人员来说,要使数据冗余尽量少,使编码时更新数据尽可能局限在局部范围内,就必须重新设计对象的存储方式,把表和视图区分开来。这一步的工作还包括视图如何分解为基本表的过程。这项工作没有什么方法值得信赖,只能依靠设计人员的经验和技巧了。这样得到的结果也很难让人信赖。
通过以上分析,我们可以了解,UML支持系统设计是非常好的工具,但在数据库设计中,其支持明显不足。
UML为什么难以支持数据库设计呢?主要原因在于UML是以功能为中心的,而不是以数据为中心的。这样我们需要找个以数据为中心的工具,这就是数据流图法。
数据流图表达了数据和处理的过程,其绘制总是围绕数据如何加工以及如何流转的,因此,它可以非常好的支持数据库的设计。
补充一点:有些教科书中把数据流图的绘制放到概念结构设计中,另一些则放到需求分析中。个人意见,数据库中存储的对象不是设计出来的,而是从用户那里获得的,所以我倾向于把数据流图归到需求分析过程中。不管哪种分法,在做需求时就需要做数据流图,以便把实体中的属性(字段)搞清楚。
3.需求分析的方法和过程
确定了工具后,就可以按照教科书上的方法和过程进行分析了。大家不要对教科书上呆板的叙述嗤之以鼻,那可是无数人经验和教训的总结,是有相当高的参考价值的。另一方面,也不要纸上谈兵,要用心去感受,思考这些方法如何使用。
需求分析的方法一般有跟班作业、开调查会、请专人介绍、询问、设计调查表请用户填写、查阅记录等。一般需要根据具体情况选用一种或多种方法,这里我就不罗嗦了。
需求分析的过程一般是:
(1) 调查组织机构总体情况;
(2) 熟悉业务活动;
(3) 明确用户需求;
(4) 确定系统边界。
这里容易忽略的是第一个步骤,主要是因为这个步骤太简单,看上去似乎也可有可无。但在实际需求分析中,这个过程很重要,这点要从组织机构的作用说起。一个单位的部门,不是因为有几个人,然后把他们组织起来就形成的。而是因为业务原因,需要有一个部门专门负责某项工作,然后才组织人手形成的部门。因此在实际系统中,部门是完成某项工作的核心,一个部门一般对应一个角色。如果把组织机构搞清楚了,总体业务逻辑基本也就清楚了,这样做可以起到事半功倍的效果。
其它几点的作用就不必说明了。
数据流图可以用作明确用户需求和确定系统边界两个步骤中,帮助设计者了解数据如何流动,并发现需要存储的对象。
4.数据流图图元
我们使用Visio 2003作为绘图工具。因为我们使用数据流图仅做草图设计,因此选择“软件”中的“数据流图模型”模版进行绘制。
数据流图语义比较简单,图元一共四个,图4.1为Visio中的表示法。
图4.1 数据流图图元
接口:用直角矩形表示。这里接口可以是与其它信息系统的接口,也可以是角色(人机接口)。进程:一般用椭圆表示,但Visio中用圆角矩形表示,可能是考虑椭圆中可以容纳的字比较少的原因。数据流图中的矩形一般表示一个功能模块或一个过程,对应一个或一组动作。
数据存储:用右边开口的矩形表示,表示数据库中存储的对象。另外在数据流图中,如果一个存储过程在同一个图中出现多次(主要是防止画的线交叉),还经常在在矩形左侧向右一点加个竖直线表示,但Visio中没有做区别。
数据流:用带箭头的直线表示,表示数据的流动方向。 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 接收订单
(1)顾客送进订单数据后,首先核对价格,这时要参考“产品描述”里面存储的价格信息。
(2)价格核对后,核对顾客账目状况,看一下该顾客是否拖欠了太多款项,这时要参考“应收帐款”信息。
(3)账目已核对的订单,将价格和账目的核对情况,发送给主管部门,由主管部门决定是否批准。
(4)不管是否批准,都要通知顾客。
(5)已批准订单送入2.0(处理订单)。
5.3 处理订单已批准的订单进行登记,并分配工种(如车工、钳工、焊工、电工等),生成生产通知单发送给生产部门安排生产。同时生成待完成订货清单,供生产部门参考。
生产完成后由生产部门将数据送入下一环节:开发票(3.0)。
图5.3 处理订单
5.4 开发票
图5.4 开发票
生产完成后,开具发票。开发票后合同额即记入应收帐款,同时将发票信息存入发票主清单,并由系统生成包装通知单信息提供给顾客。
开发票后将发票分配一个发票号(当然现在的发票都是全国统一编号,每张发票事先都已经编好号了,呵呵),并记人发票记录本。
5.5 支付过账
顾客结算时有两种方式:支付货款或信贷。
支付货款后,系统记入贷方余额,具体操作是调整应收帐款信息。如果信贷,需要根据有个审批环节,如果批准,则记入借方余额,操作也是调整应收帐款(似乎这个地方不用调整,因为开发票时已经调整了)。
5.6 提供应收帐款
这步不能进一步细化,已经完成。
5.7 小结
通过以上数据流图,我们明确了用户需求,并发现了几个要存储的对象。在下一节,我们考虑如何用发现的这些数据存储构造E-R图。
|