UML数据库

UML数据库（精选六篇）

UML数据库 篇1

目前,系统建模比较推崇的是统一建模语言UML(Unified Modeling Language),它采用一种简单而直观的图形化方式描述系统设计中的各个问题和细节,包括数据建模部分,这样不同技术背景的设计师只需懂得UML符号就可以与对方交流、共同设计。

本文将重点讨论如何在数据库系统设计中使用UML技术,并结合实例车载GPS终端项目演示采用UML的数据库系统设计过程。

1. UML简介

UML不限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。UML凭借其简洁明晰的表达方式和超凡脱俗的表达能力而为业界广泛认同。目前,在多数大型企业的正规化开发流程中,开发人员普遍使用UML进行模型的建立。

进行数据库建模前,先来看看几个重要的UML基本概念。

UML中事物是实体抽象化的最终结果,是模型中的基本成员,UML中包含结构事物、行为事物、分组事物和注释事物。

UML建模图是事物集合的分类,UML中包含多种图:(1)类图(Class Diagram)、(2)对象图(Object Diagram)、(3)包图(Package Diagram)、(4)组件图(Compoment Diagram,也称构件图)、(5)部署图(Deployment Diagram)、(6)用例图(Usecase Diagram)、(7)时序图(Sequence Diagram)、(8)协作图(Collaboration Diagram)、(9)状态图(Statechart Diagram)、(10)活动图(Activity Diagram)。(11)数据模型图(Data Model Diagram):这是本文要重点介绍的。

2. 数据建模

2.1 数据建模的必要性

使用数据库建模工具进行数据库设计可以把目光集中在数据库的设计上,只需建立起各个实体及他们的关系,建立实体时,实体的属性就是表的各个字段,实体之间的关系就是表与表之间的关系,只要这一步完成,就可以直接生成创建数据库的代码(比如Sql代码),或者让建模工具和数据库建立连接,此后就可以随时通过更改实体及它们之间的关系来直接更改数据库结构了。数据库建模工具是和数据库平台无关的,可以简单的移植到不同的数据库平台。此外,数据库建模工具大部分都是图形界面的,这更有利于与实体关系的建立,至少比文字方式要直观、简练,比如要建立一个主、外键之间的关系只需托放一个控件,再做几下选择就可以了。数据库建模工具还支持强大的数据导出功能,能够生成完全自定义格式的超文本或word文档,可以满足你想要的输出格式,而且这个操作也不复杂。

另外,现在很多被广泛使用的商业数据库建模工具都能通过双向工程自动生成跨平台、一致性好、图形界面的数据操作代码,而且支持多种语言,比如Rationnal Rose支持java、sql、oracle等,Power Designer支持.net、java、pb、delphi等各种语言。它们的易用性、功能、对流行技术框架的支持、以及它的模型库的管理理念,都深受设计师们喜欢。

2.2 数据建模工具

UML数据库建模工具不少,比如:

ERDesigner NG,属于sourceforge的一个开源产品,该软件支持多种主流的数据库,比如mysql、oracle、MS Sql Server等。功能方面支持反向工程、数据库比较、通过建模自动产生ddl、将模型图导成图片等等。

Model Right,支持Postgre SQL、DB2 for z/OS、DB2 for LUW、Access、Oracle、MySQL、MS Sql Server等。

PowerDesigner:由法国SD公司一华人首次开发的,起初主要专用于数据库建模,逐步发展到今天是一个兼具OOD建模的优秀数据建模工具,其在逆向工程,特别是文档输出和代码生成这些功能上提供了精细的控制,让用户拥有高度的自由。

Rational Rose:是业界使用最广泛之一的UML建模工具,Rational Rose为团队开发和规范的开发过程管理提供了良好的支持。

2.3 数据建模

UML OOD系统设计、建模一般是数据设计之前应先完成的,从应用的角度上来讲,面向对象的系统设计一般需要完成如下工作:(1)描述需求;(2)根据需求建立系统的静态模型;(3)描述系统的行为。

因篇幅原因,本文仅结合一个简单实例“车载GPS终端”说明UML数据建模部分及与其相关的UML OOD建模中的类图。

2.3.1 问题描述

车载GPS终端是置于机动车内的实时定位装置。目前很多PDA产品都具备了GPS功能,包括手机。GPS主要应用在运输车队和出租车等。车辆可以通过终端和GPS卫星进行实时、准确的定位,并通过无线通讯网络上报远程的中心系统。中心可以通过终端远程监视车行轨迹,甚至在特殊情况下通过终端来控制车辆。实际上GPS终端也是车载电话,可在车辆遇险时进行报警,通过GPS终端车辆还可以接收调度信息。当然,对于用户来说,GPS本身也是一个活地图,具备语音导航功能。

对于车载GPS终端,主要角色有两种:车载终端用户和监控中心用户。终端用户可以报警、打车载电话等;监控中心可以查询车辆位置,发送调度信息等。

2.3.2 类图

根据以上问题描述说明,分析之后得到部分类图,如下:

图1中,类“MainControler”继承自类“GPS_User”和类“GPSData”。

2.3.3 数据模型图

由该类图得到数据模型图,本例中数据库名:GPSDB,所建表如下:

在此,我们仅以类图中“GPS_User”、“GPSDat a”和“Main Controler”三个类的关系,射出它们三者在数据模型图中的关系,请对照图1和图2,显然,数据模型图中表的“field”及表之间的相互关系恰好与前述类图属性及关系相一致。显然,从该例可见Rose没有将数据库设计和面向对象设计清晰地分开,仅以不同的目录来区分。

3. 双向工程

3.1 正向工程

Rational Rose中可实现正向(为模型产生相应的代码)、逆向(从用户原来的软件系统导出该系统的模型)和双向工程(实现模型和代码之间的循环工程),包括数据模型图的双向工程,从而保证模型与代码的高度一致。Rational Rose支持C++、Visual C++、Java、Smalltalk、Ada、Visual Basic、PowerBuilder等语言和开发工具,并能为CORBA应用生成接口定义语言(IDL),为数据库应用生成数据库描述语言(DDL)等;数据库支持Ms Sql Server、Oracle、IBM DB2、Sybase等。

比如,本文中所建库可导入Ms Sql Server 2000中。步骤是:在Rose中对着“GPSDB”数据库点击右键——“Data Modeler”——“Forward Engineer”,依提示操作即可。

3.2 逆向工程

本例中,逆向工程的操作类似正向工程,不再赘述。

逆向工程的好处在于随着软件功能的实现及新的用户需求的加入,原建模文件在需要更新时,可不需要重新画图,只需进行逆向工程操作即可。

4. 小结

好的设计才有好的数据系统;本文以一个简单的例子,说明使用数据建模开发软件是软件开发中一个不错的选择,UML数据建模的使用,使得无论是数据维护还是更新都能极大减轻程序员的工作量。

参考文献

[1]徐宝文.UML与软件建模[M].清华大学出版社,2003.

[2]吴建.UML基础与Rose建模案例[M].人民邮电出版社,2001.

UML实验报告 篇2

在我国十年前ATM（自动取款机）还是一个很新鲜的事物，现在在城市的大街小巷随处可见。我们在日常生活中也经常和ATM打交道。本章我们将以简化的ATM系统为例将前面几章中学到的用例图、类图、顺序图、状态图、活动图及协作图知识运用到此例中。二：银行ATM机系统UML建模设计 1.用例图

参与者“银行储户”和ATM机。简化后的ATM机仅有取款、存款及其余功能。其余功能不做详细说明。

银行储户在ATM机上完成取款、存款及其他业务。2.类图

整个银行系统包括了帐户库、银行储户库及ATM系统。

许多单个的帐户组成了帐户库。帐户具有帐户类型、帐户号、余额三个属性，均为private，其类型分别为char，int，double。六个操作分别为setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance为protected其余均为public。

setType设置帐户类型，返回类型为void，参数类型为char，输入帐户类型。getType获取帐户类型，返回类型为char，无参数。

setAccountNumbe设置帐户号，返回类型为void，参数类型为int，输入帐户号。getAccountNumbe获取帐户号，返回类型为int，无参数。

caculateBalance计算余额，返回类型为void，参数为double，第一个参数为输入存取款数额，第二个参数为存款余额，既为输入也为输出。getBalance获取帐户余额，返回类型为double，无参数。

许多银行储户组成了储户库。ATM系统包含了许多ATM机。银行储户及ATM机两个类包含哪些属性，哪些操作，它们的可见性及操作的返回类型、参数个数、参数类型从类图上都一目了然。更多的属性及操作都可以一一加上，使这个类图更详细更完整，从而使参与项目的每个成员都能无歧义的明了整个设计的类的结构。同样对于一个真正的银行系统，这个类图过于简单。比如帐户类型我们可以先定义一个abstract class，它包含一个帐户最基本的属性及操作。而有些操作先定义为abstract，如余额的计算。然后再继承这个abstract class，我们可以有saving account 和checking account等等。不同的帐户有不同的余额计算方法，我们可以加上具体的算法。对于不同的帐户可能还有一些它特有的操作，我们也可以加上，比如saving account在存款达到多少时可以享受机票打折的优惠。通过类图不仅可以使设计者明确的表达自己的设计意图，也能帮组自己整理思路，充实及优化自己的设计。

3.顺序图

描述顾客在ATM机上取款时信息的流动情况。以时间为顺序。因为是示例图，所以整个过程是没有出现任何故障时的流程，并且只画到了取款结束。通过这个图，我们可以看出消息是如何在系统中不同对象之间进行交互。

通过流程图我们可以很清楚地看到系统是如何工作的，系统各部分之间的信息及控制是如何发送的，整个流程是否合理。流程图对我们的设计起到了很好的帮助作用。注意在本图没有一个生命线终端有一个“X”，这是因为这个流程中还未遇到有对象生命结束。当有对象生命结束时需在对应的生命线终端画“X”，表明这个对象在这时被销毁。

UML数据库 篇3

在数据密集型软件系统的开发过程中,数据库设计占据着非常重要的地位。20世纪90年代至今,面向对象技术在软件工程领域得到了广泛应用,统一建模语言UML(Unified Modeling Language)成为软件系统分析和设计中的主要建模工具。[1]当今数据库的设计和实现仍然是以关系模型为基础,常用的数据建模工具与UML完全不同,这些数据建模工具针对数据实体本身进行描述、忽略了软件系统的其他业务因素和需求对数据的影响。[2]这种情况使得软件分析设计团队与数据库设计团队之间的关注点在项目开发之初就出现偏差,导致团队之间的通信和协同工作产生困难,系统的应用程序和数据库之间容易产生不一致性,最终会影响整个软件系统的质量。

针对上述问题,提出了一个基于UML的关系数据库建模框架。在整个软件项目开发阶段,软件分析设计团队与数据库设计团队使用相同的建模工具,解决了彼此之间通信和沟通不畅问题,既避免了上述问题带来的弊端、也从一定程度上提高了整个软件项目的开发效率。

UML是一种建模语言、一种标准的表示方法。UML共定义了9种不同的图,把它们有机地结合起来可以描述一个软件系统的整体特征。UML利用通用机制为图附加了一些额外的信息,提供了适当的扩展机制,增加了使用上的灵活性。[3]使用UML进行数据库建模就是利用了UML的可扩展机制和可定制特点。

2 关系数据库建模方法及步骤

2.1 数据库概念模型的设计

数据库设计的首要任务是概念模型的设计。概念模型不仅能表现设计人员的思想,而且应简单清晰,便于用户理解。最常用的概念模型表示方法是实体—联系方法,该方法用E-R图描述现实世界的数据及数据之间的联系,与系统分析和设计阶段采用的建模工具UML没有直接联系,不利于系统分析设计人员和数据库设计人员之间的协同工作。[4]如果从UML所表示的系统需求分析模型出发,直接将系统分析阶段得到的对象模型映射成数据库的概念模型,就可以较好的实现数据库设计与系统分析设计之间的一致和同步。

用面向对象方法和UML进行需求分析,通常建立三种形式的模型,它们分别是功能模型、对象模型和动态模型。这三种模型从三个不同但又密切相关的角度描述目标系统,从不同侧面反映了系统的实质性内容,综合起来则全面地反映了对目标系统的完整需求。对象模型表示静态的、结构化的系统的“数据”性质,它是对模拟客观世界实体的对象以及对象彼此间的关系的映射。通常使用UML提供的类图来表示对象模型,类图由类(对象)及类(对象)之间的关系组成。[5]

数据库设计以系统的需求分析结果为前提,可以将需求分析阶段得到的对象模型即类图直接映射成数据库的概念模型。下面以一个简化的教学管理系统为例,说明从UML类图出发映射得到数据库概念模型的方法。

在表示教学管理系统的对象模型(类图)中,包括的主要内容有:1)学校分为若干系部、各个系部由特定的教师组成;2)课程分别由不同的系部开设,学生与课程之间存在选课关系;3)学生分为本科生和研究生两类。

将类图直接映射成相应数据库的概念模型如图1所示。具体的映射和表示方法是,将类图中的每个类(对象)映射为一个数据实体,数据实体的表示符号与类(对象)表示符号有细微差别,数据实体中只包括实体名称和描述实体静态特征的属性两部分内容。此外为了将数据库概念模型中的实体表示符号与对象模型中的类(对象)表示符号区分开,在每个实体名称的右侧附加了一个数据库模型标志。

在图1所表示的数据库概念模型中,将相应类图中类(对象)之间的关系直接映射成为数据实体之间的关系。系部实体与教师实体之间存在一对多的聚集关系;系部与课程之间存在一对多的开课关联。课程与学生之间存在多对多的选课关联,并将该关联表示成一个关联实体,它沿用了UML类图中关联类的含义,表示两个实体之间复杂的多对多关联及其关联的性质(附加信息)。有些情况下,在系统分析的对象模型中,关联类是隐含的,在将对象模型映射成数据库概念模型的过程中,建议将两个类(对象)之间的多对多关联映射成两个实体间带显式关联实体的多对多关联类型,以方便进一步将概念模型映射为关系数据模型。图1中,学生实体与研究生、本科生两个实体之间的继承关系是由相应类图直接映射得到的。

对于每个独立主实体(非子类实体、非关联实体),应该标出相应的主键属性,在图1中以下划线标示。

2.2 概念模型向关系模型的映射方法

关系数据库设计中,概念模型建立之后,需要将数据库的概念结构转换成关系数据库的逻辑结构表示、即基本表结构形式。在概念模型向关系模型的转换过程中,仍然沿用传统的关系数据库建模思想,但基本表结构的表示方法是基于UML的符号。下面从图1所示的例子出发,阐述概念模型到基本表结构的转换规则。

1)实体的转换

对于概念模型中的独立主实体,可将每一个实体转换为一个关系(即基本表),实体的属性即为关系的属性,实体的主键即为关系的主键。

2)对于实体间的关联和聚集关系,可根据不同情况分别转换

(1)对于一对一的关联或聚集关系,可在相关联的两个实体的任一实体所对应的关系中增加新属性,新属性为另一实体所对应的主键。

(2)对于一对多的关联或聚集关系,可在多端实体所对应的关系中增加新属性,新属性为一端实体所对应的主键。

(3)对于多对多的关联或聚集关系,将关联实体转换为一个独立的关系(即基本表),关系的属性由两端实体的主键和关联实体本身的属性组合而成;关系的主键由两端实体所对应的主键组合而成。

对于图1所表示的概念模型,按照上述转换规则转换得到的一部分基本关系(基本表)如图2所示,其中PK表示主键、FK表示外键。

3)对于实体之间的继承关系有两种转换方法

一种方法称为“子类实体上卷”法,将整个继承结构涉及的实体映射成一个基本关系。具体方法是,首先以父类实体为基础映射成一个基本表(可以称其为父表),然后逐渐将相关子类实体中的属性添加到父表中,父类实体的主键即为该基本表的主键。图3所示的学生表就是通过“子类实体上卷”法得到的结果,为了体现出学生的分类关系,在学生表中增加了一个属性“学生类别”,其取值只能是“研究生”或“本科生”。图2和图3所表示的表结构综合起来,就是由图1所示的概念模型映射得到的关系数据库的结构,即教学管理数据库的基本表结构。这种方法可以减少基本表的数量,便于数据管理和提高查询效率;缺点是在基本表的使用过程中,某些元组的部分属性值为空,降低了数据库的存储效率。

概念模型中继承关系的另一种映射方法称为“父类实体下卷”法,将每个子类实体转换为一个基本表,可以称为子表;并把父类实体中的属性添加到各个子表中,即子表的属性由其父类实体属性和自身属性两部分组成,父类实体的主键即为子表的主键。图4所示的研究生表和本科生表是根据“父类实体下卷”法映射得到的结果。图2和图4综合起来,同样可以表示由图1所示的概念模型映射得到的关系数据库的完整结构,即教学管理数据库的基本表结构。这种方法将一个继承结构映射成多个基本表,在数据库使用过程中会涉及多个表的访问,但便于将不同的信息分类管理,也解决了“子类实体上卷”法中的浪费存储空间问题。

3 结束语

基于UML的关系数据库建模方法,将通用建模语言UML引入数据库设计过程,直接从需求分析阶段得到的对象模型映射出数据库概念模型,从而打破了软件系统分析设计团队和数据库设计团队之间的分隔,便于团队之间通过协同工作来定义软件系统的业务活动。在软件项目开发和使用过程中经常会发生需求变化,上述提出的关系数据库建模方法也便于数据库能够根据应用系统的改进而进行及时修改和完善。

参考文献

[1]刁成嘉.UML系统建模与分析设计[M].北京:机械工业出版社,2007:9-12.

[2]Naiburg E J,Maksimchuk R A..UML数据库设计应用[M].陈立军,郭旭,译.北京:人民邮电出版社,2002:6-8.

[3]兰博,雅各布森,布切.UML参考手册[M].姚淑珍,译.北京:机械工业出版社,2001:17-29.

[4]Jeffrey D.Ullman/Jennifer Widom.A First Course In Database Systems(影印版)[M].北京:清华大学出版社,1998:40-51.

UML实验二 篇4

一、实验目的

1.学会分析系统中的参与者和用例 2.掌握用例图的绘制方法 3.掌握需求分析阶段的用例建模

二、实验器材

1.计算机一台； 2.StarUML工具软件。

三、实验内容

1.画出ATM系统的用例图 2.完成ATM系统用例的事件流描述 3.完成网络教学系统的用例建模 4.完成学生课程注册系统的用例建模

四、ATM系统的用例建摸

1.分析

ATM自动取款机：客户可以取钱，存钱，查询余额，转帐，修改密码。通过分析可找出如下几个参与者：（1）ATM（2）客户

通过分析得到如下用例：

（1）存款（2）取款（3）查询余额（4）转帐（5）修改密码（6）打印收据 2．绘图步骤：

下面介绍在StarUML中创建用例图的过程：

（1）在“Use Case View”中双击Main图，双击图标，出现图1，为编辑用例图做准备。

图1（2）在用例视图中，从工具栏中选择Actor图标，在右边的绘图区中添加一个新元素，并取名客户表明新增一个参与者，如图2所示。

图2（3）同样的方法添加参与者“ATM”,如图3所示。

图3(4)在工具栏上选择用例的图标，依次添加存款、取款、查询余额、转帐、修改密码、打印收据，如图4所示。

图4（5）添加参与者和用例间的关联关系，如图5所示。

图5 依照个人理解，增加一些功能或修改该用例图。（增加的功能或修改的用例图放在此处）

参照如下的取款用例的事件流描述，给出ATM系统的其它用例的事件流描述。

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）储户按确认键，输入取款金额。

5）ATM把帐号和取款金额传递给银行系统，取回帐户余额。6）ATM输出现金，并显示帐户余额。7）ATM记录事务到日志文件。

（ATM系统的其它用例的事件流描述放在此处）登录用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，ATM系统检验密码。4）储户进入ATM系统 存款用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）储户选择存款事务 5）储户添加存款金额 6）ATM系统验证钞票

7）ATM系统显示储户存款金额 8）储户确定储户存款金额

9）ATM把帐号和存款金额传递给银行系统，更新账户金额 10）ATM记录事务到日志文件。查询余额用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）储户选择查询事务

5）ATM系统显示账户余额 转账的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）选择转账事务 5）储户输入转账账号

6）ATM系统验证转账账号 7）储户输入转账金额

8）ATM系统验证输入金额是否符合输入要求 9）ATM系统验证储户账户余额 10）ATM系统显示储户转账账户及转账金额 11）ATM记录事务到日志文件。修改密码用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）选择修改密码事务

5）储户输入旧密码，ATM系统验证账户旧密码 6）储户输入2次新密码，确认输入密码 7）ATM系统更新储户的密码为新密码 8）储户修改密码成功 查询历史记录用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）选择查询历史事务记录用例

5）ATM系统查询并显示相关的信息 打印数据用例的事件流：

1）通过读卡机，储户插入ATM卡

2）ATM系统从卡上读取银行ID、帐号、并验证帐号。3）储户键入密码，系统检验密码。4）ATM系统核实操作 5）系统提示是否打印数据 6）储户确认打印数据 7）返回主界面

五、根据下属需求，分析参与者和用例，并建立网络教学系统的用例图，给出各用例的事件流描述。

网络教学系统的功能需求主要包括以下几个方面：

① 学生可以登录网站浏览信息、查找信息和下载文件。

② 教师可以登录网站输入课程简介、上传课件文件、发布消息、修改和更新消息。③ 系统管理员可以对页面维护以及批准用户的注册申请。（建立的网络教学系统的用例图放在此处）

（各用例的事件流描述放在此处）学生浏览信息用例的事件流：

1）学生输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入网站主页界面 4）浏览到相关的信息 学生查找信息用例的事件流：

1）学生输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入网站搜索界面 4）输入关键词进行搜索 5）找到自己所需要的信息 学生下载文件用例的事件流：

1）学生输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入下载文件界面 4）查找到相关信息 5）保存在指定的硬盘 6）确定下载

教师输入课程简介用例的事件流：

1）教师输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入课程简介界面 4）增加课程简介 5）保存课程简介 6）确定输入成功

教师上传课件用例的事件流：

1）教师输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入上传课件界面 4）选择上传的课件 5）确定上传课件

教师发布、修改、更新消息用例的事件流：

1）教师输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入发布、修改、更新的消息界面 4）填写好要发布、修改、更新的消息 5）保存要发布、修改、更新的消息 6）确定消息

系统管理员页面维护用例的事件流：

1）系统管理员输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）系统管理员进入页面维护界面 4）修改相关页面

5）保存修改过的相关页面 6）确定修改相关页面

系统管理员批准用户的注册申请用例的事件流：

1）系统管理员输入账号、密码

2）网络教学系统验证账号、密码是否正确 3）进入用户的注册申请界面 4）审核相关用户注册的信息 5）保存相关用户注册的信息 6）确定用户的注册申请通过

六、请根据以下需求画出学生课程注册系统的用例图。

某大学准备开发一个学生课程注册系统，学生可以使用该系统查询新学期将开设的课程和讲课教师情况，选择自己要学习的课程进行登记注册，并可以查询成绩单；教师可以使用该系统查询新学期将开设的课程和选课学生情况，并可以登记成绩单；注册管理员使用该系统进行注册管理，包括维护教师信息、学生信息和课程信息等。

在每个学期的开始，学生可以获得该学期的课程目录表，课程目录表列出每门课程的所有信息，诸如基本信息、教师、开课系和选课条件等。

新学期开始前两周为选课注册时间，在此期间学生可以选课注册，并且允许改变或取消注册申请，开学两周后注册管理员负责关闭课程注册。每个学生可以选择不超过4门课程，同时指定2门侯选课程以备主选课程未选上。每门课程最多不能超过10人，最少不能低于3人，低于3人选课的课程将被取消。一旦学生的注册过程完毕，注册系统将有关信息提交收费系统以便学生付费。如果在实际注册过程中名额已满，系统将通知学生在提交课程表之前予以更改。

UML数据库 篇5

数据仓库技术在决策支持系统中发挥着关键的作用, 它对决策支持系统提供一些商业信息, 从而提高了决策能力。数据建模作为数据仓库构建过程中最为关键的技术环节, 它直接决定数据仓库构建的成败。一方面, 多维数据模型更加接近于人们分析数据的方式;另一方面, 多维数据模型简单的结构能够提高我们预测最终用户需求的能力。现有方法都没有考虑把数据仓库作为一个集成的整体来设计, 由平台无关模型PIM (Platform Independence Model) 、平台相关模型PSM (Platform Specific Model) 、代码 (CODE) 驱动开发的模型驱动体系架构MDA (Model Driven Architecture) 就是为解决分布、异构系统的集成问题而提出的下一代解决方案。PIM不同于PSM, PSM与具体的平台相结合, 必须考虑开发平台的特性。PIM是业务系统与软件系统的结合点, 是考虑业务模型如何能更好地用计算机表述, 而这种表述与特定的平台无关。从数据仓库MDA开发过程可以看出, PIM是非常重要的一环, 关系到PSM建模的实现。本文主要讲述了数据仓库多维数据的PIM (即多维数据概念模型) 建模问题。

目前, 在数据仓库概念建模领域, 国内外采用的方法有:DWER概念建模方法[5], 此方法建立在ER模型的基础上, 主要应用于静态结构建模, 对动态部分 (预测查询行为) 和功能建模 (在维上增加度量或者层次级别间的功能关系) 的建模能力非常弱;事实-维模型 (DFM) [6], 它是一种数据仓库概念设计的专用模型, 但在概念模型中没有使用标准的符号, 这样就要为此学习其相应的符号及表示法。相对于其他概念建模方法, 由Juan Trujillo提出的基于UML扩展的多维数据概念建模方法[1]较其他方法更加具有通用性, 主要是因为它采用UML这个定义元数据结构和语义的标准语言进行建模, 这为后来的元数据的管理和集成带来了极大的便利。但是此方法没有给出多维模型的形式化表述, 从而使得模型在理解上过于繁琐。针对上述概念建模方法中存在的问题, 本文在Juan Trujillo提出的基于UML扩展的多维数据概念建模方法基础上, 提出了构建多维数据模型事实和维的数学定义方法, 并从模型通用性上, 给出了简约的版类集合以及每个版类的自然语言描述约束。

1 相关技术介绍

1.1 MDA

MDA是对象管理组织OMG (Object Management Organization) 为解决分布、异构系统的集成问题而提出的一种解决方案。

MDA开发方法强调了“模型是MDA关注点”的事实。在MDA标准中, 一个模型是对一个系统的功能、行为、性能及系统结构等因素的描述或表示, 是对系统的功能、行为、性能及系统结构等因素的形式化规约。MDA所指的“模型驱动”, 决不意味着模型只在软件系统开发的前期发挥重要作用, 而是要求模型必须贯穿于整个生命周期, 从理解系统开始, 到分析、设计、构建、部署直到后期的实际运行维护和二次修改, 都要以模型作为指导。MDA目前定义了三类最基本的模型:PIM是具有高抽象层次、独立于任何实现技术的模型。PSM为某种特定实现技术量身定做, 让你用这种技术中可用的实现构造来描述系统的模型。CODE:MDA中实现相关模型不是程序员通过程序语言翻译设计模型实现的, 而是通过转换规则定义人员在实施人员的协助下定义转换规则, 通过指定目标系统的实现方式和具体中间件技术后, 通过MDA工具和自动程序设计软件自动生成的, 它的建立意味着系统的实现。

1.2 UML扩展

UML是由OMG维护使用的PIM建模语言, 也是目前为止应用最广泛的。UML中语义归约和实现归约的分离, UML的可扩展性都是其作为PIM建模语言的优点。可以充分利用UML的扩展机制, 通过使用版类、加标签值和约束来增强特定的UML模型元素的语义信息, 使它们能更好地满足用户的建模需求。下面就简要地介绍一下UML的这三种扩展机制:

·版类 版类扩展机制是指在已有的模型元素基础上建立一种新的模型元素。版类的表示方法是在元素名称上面添加一个版类的名字。版类的名字用字符串 (用双尖括号括起来) 表示, 同时版类也可以用一个图型表示。

·加标签值 加标签值是一种模型元素的新性质, 加标签值把性质明确地定义为一个名—值对, 其中, 把名称为标签, 标签和值都用字符串表示。且用大括号把他们括起来, 放在其他元素的下面。

·约束 约束是元素的一种语义条件或限制。通过约束限定元素的用法或元素的语义。约束显示在大括号内, 放在模型元素的旁边, 约束可以用自然语言表达, 也可以用OCL表示。

2 基于UML扩展的多维数据PIM建模

多维数据模型由维和事实来定义。维是关于一个组织想要记录的视角或观点。事实是一个数据度量, 对所要考察的数据的一个数值度量。本文首先进行了如下关于多维数据模型的定义。

定义1 (维) 维是个三元组, 标记为D= (DC, BC, DAG) , 其中:

DC (Dimension class) :维类。

BC (Base Class) :基类, 一个基类体现维级的一层, 是维类的上层。其中维类和基类包含相同的属性, 标记为:DC= (OID, D, DA) , BC= (OID, D, DA) 其中:

OID:是基类或者维类的唯一标识。

D (Descriptor) :代表基类或者维类的描述性属性, 它是后面进行OLAP操作所必须的属性。

DA (Dimension Attribute) :维属性, 它是基类和维类中的一些描述性属性, 可以为空。

DAG (Directed Acyclic Graph) :是一个定义在基类或者维类上的有向的、非循环的弱连通图。图中的每一个结点代表一个维类或基类。图中的边有两种含义, 一种表示基类或维类之间的上卷或下钻的关系 (例如:日期, 星期, 年之间的关系) , 另一种代表基类或维类之间的继承关系 (例如食物和鱼肉之间的关系) 。

严格性和完整性是一个维级中很重要的两个概念。严格性是指维级中的底层基类和它上一级的维类或基类是一对一的关系。完整性是指所有的基类只属于一个高层基类或维类, 且这个高层基类或维类也只包含这些底层基类。在这里, 我们认为一个多维模型的维级是不严格的, 默认情况下是不完整的。

定义2 (事实) 设D1, D2, …, Dn是n个维, 则事实 (F) 是定义在这n个维上的共享聚合, 它可以表示成如下的三元组, F= (DC, DFR, FC) 。

DC:维类的共享聚合。

DFR (Dimension Fact Relationship) :维与事实的关系。一般情况下, 维与事实之间是一对多的关系, 但在特殊的情况下, 维和事实之间也存在多对多的关系。两种关系的区别在于拥有不同的聚合关系重数。

FC (Fact Class) :事实类是一个两元组, FC= (OID, FA) , 其中:

OID:事实类的唯一标识, 即退化维 (一个只在事实类中定义, 而没有特定维定义的属性) 。

FA (Fact Attribute) :事实属性可以是原子的或导出的属性, 若是导出的属性, 要表明其导出规则。

默认情况下, 认为所有的事实属性都是可相加的, 即加法操作在所有的维上对事实属性都是可行的。在某一维上不可加的事实属性, 应注明此属性在该维上不能相加。

由定义1和定义2, 本文引入了八个版类, 其中三个继承UML中的类模型元素, 四个继承UML中的属性模型元素, 一个继承UML中的关联模型元素。关系如图1所示。

下面分别对各个版类进行描述:

(1) FC (事实类) 描述多维数据模型中事实的版类, 它有如下约束:事实类的属性只能是OID或FA;与事实有关的连接只能是聚合连接;事实类只能与维类进行连接。

(2) DC (维类) 描述多维数据模型中维的版类, 它有如下约束:维类的属性只能是OID、D或者DA;维与事实的所有连接必须能够对事实进行聚类操作;维与事实的所有连接不能对维进行聚类操作;维不能与别的维进行连接。

(3) BC (基类) 代表维级中的上层的版类, 它有如下约束:基类的属性只能是OID、D或者DA。OID和D是基类中的必需属性;基类可以与其他的基类或维类进行关联;一个基类不能同时属于继承关系和关联关系。

(4) OID 该版类描述的是多维数据模型中事实、维的关键属性, OID属性是类中的唯一标识性属性。它有如下约束:OID不能是导出的属性。

(5) FA (事实属性) 该版类描述的是多维数据模型中事实类的属性, 它具有如下约束:事实属性只能属于某一事实;如果一个事实属性是通过推导得出的, 应标出其导出规则。

(6) D (描述符) 该版类描述的是维类和基类的描述型属性, 它具有如下约束:D只属于维类和基类;如果D是通过推导得出的, 应标出其导出规则。

(7) DA (维属性) 该版类描述的是多维数据模型中维类的属性, 它有如下约束:维属性只属于某一维类和基类;如果这个属性是通过推导得出的, 应标出其导出规则。

(8) R-D 描述维类与基类或基类与基类之间的关联关系, 它有以下约束:R-D关联的两端只能是维类或基类;R-D关联的一端包含角色r, 另一端包含角色d。r表示roll-up-to的方向, d代表drill-down的方向。

为了对类中的基本属性和推导属性进行区分, 在这里引入了推导元素的标记, 它是在相应元素名称前边加一斜线, 而元素的图示标记没有改变。

3 方法应用

3.1 应用实例

前面对多维模型的八个版类进行了定义, 下面针对某钢铁企业采购系统的采购价格差异分析主题, 具体地介绍在基于模型驱动架构的数据仓库构建过程中, 数据仓库多维数据PIM模型的建立。

采购价格作为组成采购成本中最主要的一部分, 对企业决策人员提供关于采购价格在不同时期、不同物资类别以及不同供应商上的价格差异分析, 可以使得决策人员更加有效地控制采购成本。针对此采购价格分析主题, 抽取出一个事实、三个维, 它们分别是采购价格事实、时间维、物资维、供应商维。如下分别是时间维的维级图 (如图2所示) 、物资维的维级图 (如图3所示) 以及采购价格差异多维数据PIM模型图 (如图4所示) 。

为了对提出的采购价格差异多维数据PIM模型进行验证, 在图4的基础上, 我们采用JAVA语言, 开发了基于B/S模式的某钢铁企业的采购价格分析决策支持系统。图5是某企业2008年1月—3月螺栓类别各项物资采购价格差异分析结果。从结果可以看出, 此系统具有一定的采购价格分析功能, 使得决策者能够良好地控制采购成本。实践表明, 利用此模型开发的系统不但在开发效率上较传统的E-R模型提高了, 而且此模型是基于国际标准建模语言 (UML) 建立的, 使模型更加具有规范性, 可以很好地实现不同模型之间的共享, 同时, 也有利于模型的重用和维护。

3.2 方法评价

文献[7]提出了一个数据仓库的评价标准, 该标准包括如下主要内容:

(1) 显式地表达维的层次;

(2) 平等地对待维和聚合属性;

(3) 支持维上的多重层次;

(4) 支持对度量进行正确的聚合或抽象;

(5) 支持非到上的层次 (所谓非到上的层次是指下层的每一个对象都一定要在它的直接上层有一个层次与它对应) ;

(6) 支持非严格的层次:主要指维的多对多关系;

(7) 支持事实与维之间的“多对多关系”;

(8) 支持度量的抽象或聚合的不同层次的粒度;

(9) 支持跳跃式的层次, 通过起点和终点相同的不同路径表示;

(10) 处理时间变化。

根据该标准, 对本文提出的多维数据PIM建模方法进行了简单的评价, 从图2—图4可以看出, 该方法明显地支持第 (1) 、 (3) 、 (5) 、 (8) 、 (9) 条;对于第 (6) 、 (7) 条, 由于本方法是UML的一种扩展, 借助于UML本身的联系的基数约束就能很好地进行表达;通过引入的属性版类, 标准的第 (4) 条也得到了有力的支持;对于第 (2) 条, 由于推导属性的引入, 它也得到了广泛的支持;在进行多维数据概念建模时, 一般都引入了时间维, 从而也就支持了标准的第 (10) 条。

4 结论与展望

本文通过对UML进行扩展, 利用版类、加标签值和约束, 建立了基于UML扩展的多维数据PIM模型。这种基于UML的多维建模方法, 一个显著优点就是建立在一种广泛接受的面向对象建模语言的基础上, 从而使开发人员在具体的应用时, 不必重新学习一些新的模型及相关概念, 便于广泛应用。

本文实现了基于模型驱动架构的多维数据PIM模型。多维数据PIM模型与多维数据PSM模型的转化、多维数据PSM模型的表示方法、数据仓库中的其他过程 (例如ETL) 基于模型驱动架构的构建方法等问题还有待于在今后的工作中作进一步的研究。

参考文献

[1]Sergio LujanMora, Juan Trujillo, Il Yeol Song.A UML profile for multi-dimensional modeling in data warehouses[J].Data&Knowledge Engi-neering, 2006, 59 (3) :725-769.

[2]Jose Norberto Mazón, Juan Trujillo.An MDA approach for the develop-ment of data warehouses[J].Decision Support Systems, 2008, 45 (1) :41-58.

[3] OMG (Object Management Group) .UML Superstructure Specification (v2.0) .Available from: http://www.omg.org/cgi-bin/doc?formal/05-07-04.

[4]Juan Trujillo, Manuel Palomar, Jaime Comez.Designing Data Warehou-ses With OO Conceptual Models[J].IEEE Computer, Special Issue onData Warehouse, 2001, 34:67-75.

[5]Chen Ming, Wu Guo wen, Shi Bai le.Design the Data Warehouse Con-ceptual[J].Mini-Micro Systems, 2002, 23 (12) :1453-1458.

[6]Golfarelli M, Maio D, Rizzi S.The dimensional fact model:a conceptu-al model for data warehouses[J].International Journal of CooperativeInformation Systems, 1998, 7 (2-3) :215-247.

UML数据库 篇6

关键词：教务管理,UML形式化,度量,代数表达框架

0 引 言

设计数据库最普遍的手段是设计概念模型,例如E/R图,而这样并未考虑系统别的方面的因素[1]。现在的开发环境大多是面向对象的,而存储模式多数是关系型的,事实上目前较为流行的对象关系数据库模型也是数据库模型的一个扩展[2],因此存在怎样将面向对象思想和关系数据库模型相统一的问题。UML作为统一建模语言,它被设计用于定义、可视化、建构和文档化软件系统模型[3],不但能够为特定的运用以统一的方式模型化整个系统(包括数据库),而且可以定义需求框架、标记值、约束。通过把UML模型转化为关系数据库,使得生成的数据库具有相当的扩展性和健壮性,大大提高了数据库及其软件的开发效率,针对这一现象提出了用UML设计J2EE框架下的教务管理数据库。

系统分析设计过程中得到的软件UML模型一般包括用例图及用例描述、序列图及应用领域类的类图[4]。本文以学籍管理为例,利用UML对其进行了建模,建模过程中利用了面向度量的代数表达框架[5]对模型进行了检测和优化,纠正了类模型中的错误。最后根据类模式向关系数据库的映射策略[6,7]把类模式转化为了数据库中的表。

1 高校教务管理系统

高校教务管理是个非常庞大的系统。在此以学籍子系统为例说明从UML模型向关系数据库的转化。学籍子系统由新生入学(招生转入、分班、报到)、在校生管理(专业分流重组、收费、注册、学籍异动)、毕业管理(预计毕业、毕业审核、学位审核、辅修毕业审核、辅修学位审核、毕业离校等)组成。该模块有三类角色:操作人员、学生及管理员,另外系统操作人员分系和院级两类用户。

2 学籍管理数据库的UML建模方法

以下对学籍管理系统进行建模,并运用面向度量的UML的代数表达框架对模型进行了检测优化,完成了从类图到关系数据库的转换。

2.1 UML用例图

用例图显示了一些用例和角色(特殊的类)及它们的关系。学籍管理系统用例图如图1所示。

2.2 UML序列图

定义1 (类)类c定义为三元组c=(name,A,M)。name表类名;A是c的属性集合,每个属性a= (name,type,scope,visibility),a中参数分别为属性名、类型、是对象级别或类级别、可见性;M为c的方法集合,每个方法m=(name,fct,scope,visibility),m中前两个参数分别是方法名、输入参数和返回值类型,其余同a。

定义2 (对象)对象o定义为o=(name,t,V)。name为对象的名字;t为对象声明时使用的类型;V为对象实例变量的集合,每个实例变量v=(name,type),name是实例变量名,type是实例变量的类型。

定义3 (序列图)一个序列图sed=(OS,Mes)是个二元组,其中:

· OS是sed中所有对象的集合。

· Mes是sed中所有消息的集合,每个消息mes=(sn,name,para,sender,receiver,type)。sn是mes在序列图时间序列中相对位置的序号(必须);name是mes的名称;para=((name1,t1),…,(namen,tn)),ti(1≤i≤n)∈T,是mes所带参数名称和类型组成的元组,n为参数个数(n为0表示没有参数或参数省略),namei和ti分别表示第i个参数名称和类型,没定义时分别默认为空串和void;sender∈OS是mes的发送者,receiver∈OS是mes的接收者;type∈{″syncall″,″asyncall″,″send″,″return″}描述mes的类型:“syncall”为方法的同步调用;“asyncall”为方法的异步调用;“send”表示信号的发送;“return”表示方法同步调用结束后的返回。

学籍管理序列图如图2所示。

学籍管理系统序列图形式化如下:

sed1=({o1,o2,o3,o4},{mes1,mes2,mes3,mes4,mes5,mes6,mes7,mes8,mes9,mes10,mes11,mes12,mes13,mes14,mes15,mes16})

对象:

o1:o1=(″″,操作员,Φ)

o2:o2=(${}_{\text{v}{}_{14},\text{v}{}_{15,}\text{v}{}_{16},\text{v}{}_{17},\text{v}{}_{18},\text{v}{}_{19},\text{v}{}_{20},\text{v}{}_{21},\text{v}{}_{22},\text{v}{}_{23},\text{v}{}_{24},\text{v}{}_{25},\text{v}{}_{26}\}}^{{˝}^{″},\text{录}\text{取}\text{学}\text{生}‚\{\text{v}{}_1,\text{v}{}_2,\text{v}{}_3,\text{v}{}_4,\text{v}{}_5,\text{v}{}_6,\text{v}{}_7,\text{v}{}_8,\text{v}{}_9,\text{v}{}_{10},\text{v}{}_{11,}\text{v}{}_{12},\text{v}{}_{13},}$)

vi=(name,type)(1≤i≤26),其中name是实例变量的名字,type表示实例变量的类型。

并且∀i(1≤i≤26)(∃b∈录取学生,OA(v.name=b.name∧v.type=b.type))。

o3:o3=(″″,在校生,{v1,v2,v3,v4,v5,v6,v7,v8,v9,v10,v11,v12,v13,v14,v15,v16,v17,v18,v19,v20,v21,v22,v23,v24,v25,v26,v27,v28,v29,v30,v31,v32,v33,v34,v35,v36,v37,v38,v39,v40,v41,v42})

vi=(name,type)(1≤i≤42),对于name和type的约束同O2。

o4:o4=(${}_{\text{v}{}_{17},\text{v}{}_{18},\text{v}{}_{19},\text{v}{}_{20},\text{v}{}_{21},\text{v}{}_{22},\text{v}{}_{23},\text{v}{}_{24,}\text{v}{}_{25},\text{v}{}_{26},\text{v}{}_{27},\text{v}{}_{28},\text{v}{}_{29},\text{v}{}_{30},\text{v}{}_{31},\text{v}{}_{32},\text{v}{}_{33},\text{v}{}_{34}\}}^{{˝}^{″},\text{毕}\text{业}\text{生}‚\{\text{v}{}_1,\text{v}{}_2,\text{v}{}_3,\text{v}{}_4,\text{v}{}_5,\text{v}{}_6,\text{v}{}_7,\text{v}{}_8,\text{v}{}_9,\text{v}{}_{10},\text{v}{}_{11,}\text{v}{}_{12},\text{v}{}_{13},\text{v}{}_{14},\text{v}{}_{15},\text{v}{}_{16},}$)

vi=(name,type)(1≤i≤34),对于name和type的约束同O2。

消息:

mesi=(sn,name,(″″,void),sender,receiver,type)(1≤i≤16,1≤sn≤16),其中name是消息的名称,当1≤i≤8时,type=″syncall″;当9≤i≤16时,type=″return″。

2.3 UML类图的形式化

2.3.1 类图的形式化定义及应用

定义4 (类图) 类图形式化为cd=(name,CS,ASS,GEN,AGG,DEP),其中:

· name是cd的名称,可为空。

· CS是cd描述的类的集合。

· ASS是cd中类间直接关联关系(association)ass=(name,c1,c2,dir)的集合。name是ass的名字。name可为空;c1,c2∈CS是ass所关联的两个类;dir∈{″bidirectional″,″undirectional}代表关联方向类型:“bidirectional”是双向的;“undirectional”是由c1指向c2。

· GEN⊆CS×CS是cd中类间直接继承关系集合。令c1,c2∈GEN当且仅当c1是c2的一般化。

· AGG⊆CS×CS是cd中类间直接聚合关系的集合。令c1,c2∈AGG当且仅当c1聚合c2。

· DEP⊆CS×CS是cd中类间直接依赖关系集合。令c1,c2∈CS,则c1,c2∈DEP当仅当c1依赖c2。

学籍管理类图如图3所示。

学籍管理类图形式化如下:

2.3.2 UML模型的检验、优化

在给出类图和序列图的形式化后,可以根据UML的定义、规则进一步来检验UML设计中的错误,并查处设计中不精确的地方,提出改进方案。以下举个例子:

例如由UML的定义,能够得出如下规则:

∀c1,c2∈CS,if∃aggi∈CD.AGG,aggi.c1=c1,即如果aggi.c2=c2⇒∃ai∈c1.A,ai.type=c2,即c1与c2是aggregation的关系,则c1应该包含类型为c2的属性变量。

可以判断当类间是聚合关系时,类的属性及类型是否设计正确了。另外,可以根据要求,通过加入规则对UML图形设计进行限制,以防止不良现象的出现,从而可以优化模型。

2.4 UML中类关系映射成关系数据库

UML中类图的映射主要是指对象标识、属性类型、类这三方面的映射。即把类的属性映射成关系表中的字段,类的属性类型映射成表的域,具体实现细节不再详述。

3 结束语

本文借助UML的形式化语言检测并优化了UML模型,使模型建立在更坚实的理论基础之上,此方式会使系统设计得非常好,大大提高了系统的开发效率,使系统可扩展性、健壮性都比较强,这样软件维护起来比较方便。另外却会造成数据的冗余,所以在映射到数据库时还应借助于关系数据库的理论去除数据库中的冗余。此外,将UML类图映射成关系表很可能只是部分表,还要借助于关系数据库的理论来建其余的表,这有待于UML建模语言的进一步细化。

参考文献

[1]Esperaza Marcos,Beln Vela,JosMar姫a Cavero.AMethodological Ap-proach for Object-Relational Database Design using UML[J].Softw Syst Model,7January2003.

[2]Nlyomthum K,Chittaysothorn S.A transformation from an object data-base to an object relational database[A].Proceedings of the IEEE SoutheastCon2003,2003:7-11.

[3]Tan Wenkai,Li Xuandong,Zheng Guoliang.A Tool for Analyzing UML Sequence Diagrams with Timing Constrains[J].Journal of Sotware,2001,12.

[4]彦炯,王戟,陈火旺.基于UML的软件Markov链的使用模型构造研究[J].软件学报,2005,16(8).

[5]周瑾,马应龙,李巍,等.UML的形式化及其应用[J].计算机科学,2005,32(3).

[6]张虹,郑会颂.UML中类模式在关系数据库中的映射及其实现[J].南京邮电学院学报,2005,25(3).