EnterpriseArchitectUML指南.docx

Enterprise Architect UML指南
ources/tutorial/uml-
应用UML进行数据库建模
介绍
当需要为软件系统系统提供一种可靠,灵活而又高效的对象持久化方法时,当今的设计师和架构师们面临着众多的选择。从技术的层面上,这个选择往往介于完全面向对象,对象关系混合,完全关系化和建立在公开或专有文件格式上的常规解决方案之间(如:XML,OLE的结构化存储)。从提供者的层面上,Oracle, IBM, Microsoft, POET 和其它的公司提供了相似,但是彼此间往往不相容的解决方案。
本文仅论述这些选择中的一种,即在完全关系数据库上层面向对象的类模型进行分层。这并不表明它是唯一、最好而又简单的解决方案,但是从实用的角度看,它是最常用的一种类型,却也是最容易被用错的一种。
我们先快速浏览两个设计领域的模型,并试图把它们连接起来:第一,介绍用UML表达面向对象的类模型;第二,关系数据库模型。
对每一个领域我们只涉及影响到我们任务的主要功能。然后我们将关注从类模型到数据库模型映射的技术和问题,包括对象持久性,对象行为,对象和对象标识之间的关系。我们将总结对UML数据profile的回顾(Rational Software 推荐)。一些面向对象设计,UML和关系数据库建模的相似性也会被提及。
类模型是UML用来表达软件系统逻辑结构的主要工件。它用来记录数据需求和模型领域内对象的行为。本文不讨论创建和详细描述该模型的技术,我们将假设已经存在一个设计好的类模型,它需要映射到关系数据库上。
类模型
类在UML中是一个基本的逻辑实体。它定义了一个结构单元的数据和行为。一个类是一个模板或运行时创建实例和对象的模型。当开发一个逻辑模型,如UML中的结构层次,我们将明确地把它们当作类来处理。当面对动态图时,如顺序图和协作图,我们也要处理类的实例和对象,以及它们运行时的内部动作。数据隐藏和封装原则是基于作用域效果。类有它的内部数据元素。访问这些数据元素需要通过类对外的行为或接口。遵循这个原则会生成
更易于维护的代码。
行为
行为使用了类定义的操作,在类模型中被记录。操作是可以外部可见的(public),对子类可见的(protected)和隐藏的(private)。通过结合隐藏数据和公共访问接口,隐藏或保护数据的操作,类的设计人员可以建立极易维护的结构单元,这些结构单元是支持而不是阻碍变化的。
关系和特性
关联是两个类之间的一种关系。关系一侧的类知道和在某种程度上使用或操控另一侧的类。这种关联可以是功能上的(为我做某事)也可以是结构上的(是什么)。在本文中更多的是侧重结构上的关系。如:一个“Address”类可以关联一个“Person”类,将这种关系映射到数据空间需要多加注意。
聚合是关联的一种形式,表示一个类多个对象的集合在另一个类中。复合是一种更强的聚合形式,说明一个对象实际上由其它对象构成。对于关联关系来说,它意味着一个复杂的类属性,将该属性映射到关系模型时需要更详细的考虑。当一个类表示为生成许多对象实例的模板或模型时,对象需要在运行时有识别自己的方式,这样被关联对象可以对正确的对象实例施加作用。在编程语言中,如C++,对象指针可能会传递,并使所指对象可以访问一个独一无二的对象实例。通常尽管一个对象会被销毁,但是在需要时,又象上一次有效实例期间那样被重建。所以,这些对象需要一个存储机制来保留它们的内部状态和关联,并在需要时恢复所需状态。
继承给类模型提供一种方式,该方式提取通用行为到泛化的类中,使这个泛化类稍后可以做为在一般主题上诸多变异的原形。继承是一种管理重用和复杂性程度的方式。如我们将看到的,关系模型并没有与继承关系的直接对应项,这给数据模型建立者建立一个从对象模型到关系框架造成了困难。从一个运行时的对象到另外一个对象的导航是建立在完全引用的基础之上。一个对象有多种形式的连接(指针或唯一的对象标识),用这些连接可以定位和重建所需的对象。
关系模型
关系数据模型已经使用多年,提供的性能和灵活性一直行之有效。它本质上是基于集合的(set-based),并且用‘表’做为它的基本单元,表由一个或多个‘列’组成,每一个列包含一个数据元素。
表和列:一个关系表是一个或多个列的集合,每个列在表结构中有一个唯一名称,并且被定义成一个特定基本数据类型,如:数字、文本、二元数据。表定义是一个模板,表的“行”从这个模板中被创建,行可能做为一个表实例的实例。关系模型仅仅提供一个公共数据访问的模型。所有数据向外对任何一个过程开放,以便于被更新,查询和操控。信息隐蔽(information hiding)是未知的。
行为
与表相关联的行为通常是基于所应用实体的业务或逻辑