（管理科学与工程专业论文）uml类图实现至对象关系数据库之研究.pdf

中文摘要 面向对象技术是继结构化技术之后，系统开发理论上的又一主流技术，它已 成为软件工程领域的研究热点之一。1 9 9 7 年，对象管理组织( o m g ) 将统一建 模语言( u n i f i e d m o d e l i n g l a n g u a g e ，u m l ) 规定为面向对象分析与设计的标准语 言，并积极向软件界推广。虽然u m l 已成为软件工程界标准的面向对象软件建 模语言，但是u m l 标准并没有指出如何将其分析结果类图，实现为后端数 据库设计。特别的，在没有真正成熟的和商业化的纯面向对象数据库出现之前， 绝大多数的软件开发组织面临着要将面向对象的设计成果转化为关系数据库设 计的困境。对象关系数据库管理系统是符合s q l3 标准的数据库系统，同时具 有面向对象的特性和关系查询的特点，是关系数据库向面向对象数据库系统的一 个良好过渡。本文的研究从u m l 及对象关系数据库理论出发；进而提出了将 u m l 类图转换为对象关系数据库的具体建模原则与步骤，该转换方法包括类的 静态结构转换与动态行为转换；接着，本文以f 公司的汽车销售管理系统为实例， 来展示此方法和原则的可行性；最后，展望未来，提出了具体深化本文研究的方 向和内容。本文的研究成果对于将u m l 建模结果实现为数据库设计有具体的参 考价值，并可因此加速信息系统的开发。 关键词：统一建模语言类图对象关系数据库 a b s t r a c t a l t e rw d l - k n o w ns t r u c t u r e dt e c h n o l o g y , o b j e c t o r i e n t e dt e c h n o l o g yh a s b e c o m e a n o t h e rp a r a d i g mo fs y s t e md e v e l o p m e n ta n dah o tt o p i ci nt h ef i e l do fs o f l w a m e n g i n e e r i n g t h eu n i f i e dm o d e l i n gl a n g u a g e ( u m l ) h a sb e c o m eas t a n d a r dm e a n s f o rt h ea n a l y s i sa n dd e s i g no fo b j e c t - o r i e n t e da f t e ri t p a s s e dt h ec e r t i f i c a t i o no ft h e o b j e c tm a n a g e m e n tg r o u p ( o m g ) i n1 9 9 7 ，a n di t w a sw i l l yu s e di n m a n y i n d u s t r i e s a l t h o u g h i tb e c o m e sas t a n d a r do fo b j e c t o r i e n t e d m o d e l i n gl a n g u a g e ， u m lh a s n tp r o v i d e d p r i n c i p l e s o r g u i d e l i n e sf o rm a p p i n g c l a s s e st ot a b l e s s p e c i a l l y , t r a n s f o r m i n gu m l c l a s sd i a g m mt ot h ed e s i g no fr d m s i sad i l e m m a ，w h i c hm o s t s o f t w a r e o r g a n i z a t i o n s w o u l de n c o u n t e rb e f o r em a t u r e o b j e c t o r i e n t e d d a t a b a s e c o m e s f o r t h o h j e c t r e l a t i o n a ld a t a b a s e ，w h i c hh o l d s b o t ht h et r a i t so f o b j e c t o r i e n t e d a n dr e l a t i o n a l q u e r y , i s af i n e i n t e r g r a d eb e t w e e no b j e c t o r i e n t e dd a t a b a s ea n d r e l a t i o n a ld a t a b a s e t h ep u r p o s eo ft h i s s t u d yi s t o i n v e s t i g a t e t h eg u i d e l i n e sf o r t r a n s f o r m i n g u m lc l a s s d i a 掣 a m t o o b i e c t - r e l a t i o n a l d a t a b a s e d e s i g n t h e t r a n s f e r r i n g m e t h o d si n c l u d eb o t hs t a t i cs t r u c t u r et r a n s f e ra n dd y n a m i cb e h a v i o r t r a n s f e r a n e x a m p l eo fa m o m o m l eo r d e r i n gs y s t e m o rfc o m p a n yi su s e dt o i l l u s t r a t et h eg u i d e l i n ea n d a p p l i c a t i o n w i t ht h e s eg u i d e l i n e s ，a n a l y s t sc a ne a s i l yu s e t h eu m lc l a s s d i a g r a mt oe x p r e s sd a t a b a s ed e s i g n i n ga n dt h e r e b yi m p r o v et h e e f f i c i e n c ya n de f f e c t i v e n e s so f u m l m o d e l i n g k e yw o r d s ：u n i f i e dm o d e l i n gl a n g u a g e c l a s s d i a g r a mo b j e c t r e l a t i o n a l d a t a b a s e 独创性声明 本人声明所呈交的学位论文是本人在导师指导下进行的研究工作和取得的 研究成果，除了文中特别加以标注和致谢之处外，论文中不包含其他人已经发 表或撰写过的研究成果，也不包含为获得墨生盘鲎或其他教育机构的学位 或证书而使用过的材料。与我一同工作的同志对本研究所做的任何贡献均已在 论文中作了明确的说明并表示了谢意。 学位论文作者签名：孑 速梃签字日期： q 。年1 月1 2 日 学位论文版权使用授权书 本学位论文作者完全了解鑫注盘堂有关保留、使用学位论文的规定。 特授权墨鲞盘堂可以将学位论文的全部或部分内容编入有关数据库进行检 索，并采用影印、缩印或扫描等复制手段保存、汇编以供查阅和借阅。同意学 校向国家有关部门或机构送交论文的复印件和磁盘。 ( 保密的学位论文在解密后适用本授权说明) 学砬论文作者签名罩p 逸挺 签字日期：2 u o ；年1 月l 2 日 导师签名： 签字日期：胪j 年f 月，日 ，喀一_-、 工彳 p 第一章绪论 1 1 研究背景 第一章绪论 面向对象技术是继结构化技术之后，系统开发上的另一主流技术，该技术已 受到高度的重视，并已成为软件工程领域最热门的研究课题之。面向对象技术 为软件科学带来的最大贡献是高度的软件再用性与可维护性，因为将属性与操作 封装在类内，可以形成高模块化、低复杂度、易于维护、高质量的软件组件，这 对提高软件质量有着很大的帮助。在1 9 9 7 年，对象管理组织通过将原属于 r a t i o n a l 公司的r a t i o n a lu m l 修改为面向对象分析与设计的标准_ o m gu m l 后，面向对象技术在系统建模的表达方法上有了统一的语言，同时也结束了面向 对象技术使用符号百家争鸣的时代，u m l 逐渐成为面向对象建模的标准语言。 就目前而言，虽然关系型数据库管理系统在应用方面存在着种种限制，但它 仍是当前数据库市场的主导，根据p cw e e k ( 2 0 0 0 ) 的研究，r d b m s 在未来的 十年仍将主导数据库管理系统的市场。面向对象数据库管理系统虽然可能是未来 发展的趋势，可是现在的市场占有率很低且产品未完全成熟前，原有传统 r d b m s 的使用者必定不会放弃具有众多查询功能且容易使用的旧系统。 面向对象的观念在数据库的应用上，虽然已有u m l 的类图可供数据建模时 参考，但缺乏将类图实现至后端数据库的具体建模原则与步骤，缺乏广为软件界 接受的商业化o o d b m s 上市，使得u m l 具有面向对象功能的特性无法在系统 实现时完全发挥。目前软件界的变通方法主要集中在如何应用面向对象的观念来 增强r d b m s 的功能及使用面向对象程序语言来辅助数拐库钓实现上面。 1 2 研究动机 由于以下3 方面原因，目前数据库市场仍以关系型数据库产品为主流，而软 件设计人员在系统开发时也仍会选择使用关系型数据库：t 、面向对象数据库虽 然已有商用的雏形系统，但尚未有真正成熟，被广泛使用且真正商业化的产品出 现；2 、多年来，软件公司以及用户公司已投资大量的人力、财力在关系型数据 库的设备与应用系统开发上面：3 、关系型数据库有许多优点，例如有十分扎实 的数理逻辑理论基础、能够用数理代数精确推导及得到简明易用的结构化查询语 言s q l ( s t r u c t u r eq u e r yl a n g u a g e ，s q l ) 的支持等一因此，若使用u m l 进行系 统建模，必将面临由面向对象方法进行分析、设计，以厦向对象程序语言进行编 码的系统，却必须使用关系型数据库来实现其数据存储的情形。 第一章绪论 将u m l 的建模成果实现至后端对象关系数据库就是本文研究的动机，本文 拟在真正成熟且商业化的面向对象数据库产品出现之前，选择以兼具关系型数据 库优点及面向对象特性的对象关系数据库作为系统后端连结的数据库，来探讨 u m l 具体的数据建模准则。本文将对如何整合u m l 分析设计的结果和后端数 据库的问题，提出具体的建模原则与步骤，并以个具体应用系统的实例来证明 所提出方法的可行性。 1 3 研究目的 利用u m l 进行系统分析设计时，关于数据建模的部分u m l 并未提出具体 的建模原则与步骤，尤其是后端数据库仍采用关系型数据库时，问题更加复杂。 从讨论u m l 类图的相关文献及研究报告中发现：探讨的内容大多集中在如何建 模类图，对连结数据库的部分常以抽象一个永续类( p e r s i s t e n c ec l a s s ) 来实现对 数据库的一般操作，如新增、删除、查询等，并不涉及具体的操作环境；或是只 探讨类问的部分关系及将这些关系对映至数据表的方法；对研究将u m l 类图的 高级关系及类的动态行为对映至关系型数据库的方法，则一带而过。但就实际应 用而言，在开发信息系统时，必须要有明确的原则与步骤才能将u m l 类图分析 设计的结果实现在数据库上。基于上节所述之研究动机，本文研究的目的如下： 、对相关文献或研究报告进行统计总结，整理出目前有关u m l 类图与数 据库转换的理论架构。 二、提出将u m l 类图直接转换为对象关系数据库的具体建模原则与步骤， 该转换方法包括静态结构转换与动态行为转换，并对以对象关系型数据库来表达 类的属性及操作等课题进行探讨。 三、以一个应用系统的实现为例，来证明所提出u m l 类图转换方法的可行 性。 1 4 研究范围与限制 本文将整理与探讨u m l 类图转换为对象关系数据库的相关理论架构，从而 提出将u m l 类图转换的具体建模原则与步骤，并以f 公司汽车销售管理系统的 类图为例，应用此建模原则与步骤进行数据建模及实现至对象关系型数据库以展 示其可行性。研究的范围仅限于对已定义完整的类图提出具体数据建模原则与步 骤，对如何定义完整的类图则不在本文探讨的范围内。另外，实现对象关系型数 据库的部分，因为目前市面上现有的o r d b m s 产品，如：i n f o r m i xu n i v e r s a l s e r v e r 、o r a c l e 8 ie n t e r p r i s ee d i t i o n 、与i b md b 2u n i v e r s a ld a t a b a s e 等之间的差 异性颇大，在考虑目前市场占有率、软件取得方便程度、功能完整性等因素将限 2 第一章绪论 制在只实现o r a c l e 8 ie n t e r p r i s ee d i t i o n 这个版本。 1 。5 研究方法与步骤 本文从理论研究出发，探讨了u m l 建模以及对象关系数据库的相关理论， 接着将这些理论进行分析、整理、探讨，归纳出可以运用的将u m l 类图转换为 对象关联模式的方法的理论架构，再以这些理论架构为基础提出将类图转换实现 至对象关系型数据库的具体建模原则与步骤，然后采用研究与实证的研究方法， 将此转换方法应用于f 公司汽车销售管理系统的实现。有关研究流程的详细步骤 如图1 1 。 1 6 论文架构 图1 - 1 研究流程 本论文共分为五章，第一章为绪论，说明研究背景、研究动机、研究目的、 研究范围与限制、研究方法与步骤及论文架构。第二章为理论研究，主要针对统 一建模语言、类图、u m l 的数据建模、对象关系型数据库等理论作详细的探讨。 第三章为类图转换对象关系数据库设计的方法，该方法论包含类的静态结构转换 与类的动态行为转换。第四章为应用系统实现，将以f 公司汽车销售管理系统的 3 第一章绪论 实现来证明转换步骤与方法的可行性。第五章为总结，提出本文的成果及后续的 可能研究方向。 4 第二章统一建模语言与对象关系数据库 第二章统一建模语言与对象关系数据库 本章的目的在于通过理论研究，为后续章节的方法与实证研究奠定扎实的基 础。因此本章在对u m l 作整体介绍的基础上，对其中与数据库实现紧密相关的 类图( c l a s sd i a g r a m ) ，作了一番深入探讨，接着介绍了目前有关u m l 数据建 模的研究状况以及对象关系数据库的一些理论。 2 1 统一建模语言简介 u m l 是一种定义良好、易于表达、功能强大且普遍适用的软件建模语言， 它是一个标准的建模语言，而非标准的程序语言。j a c o b s o n 等人( 1 9 9 6 ) 在u m l 0 9 和o 9 1 版的文档中说明了u m l 的宗旨：“u m l 打算成为一套用来建立系统 模型的通用语言，亦即u m l 可以表达许多不同种类与目的的模型，就像人们使 用程序语言或自然语言一般”。 2 1 1u m l 的发展历史 公认的面向对象建模语言出现于7 0 年代中期。从1 9 8 9 年到1 9 9 4 年，其数 量从不到十种增加到了五十多种。在众多的建模语言中，语言的创造者努力推崇 自己的产品，并在实践中不断完善。但是，o o 方法的用户并不了解不同建模语 言的优缺点及相互之间的差异，因而很难根据应用特点选择合适的建模语言，于 是爆发了一场“方法大战”。9 0 年代中，一批新方法出现了，其中最引人注目的 是b o o c h 1 9 9 3 、o o s e 和o m t - 2 等。 1 9 9 4 年1 0 月，在r a t i o n a l 公司工作的g r a d yb o o c h 和j i mr u m b a u g h 开始致 力于统一各种面向对象的建模语言。他们首先将b o o c h 9 3 和o m t - 2 统一起来， 并于1 9 9 5 年1 0 月发布了第一个公开版本，称之为统一方法u m0 8 ( u n i f i e d m e t h o d ) 。1 9 9 5 年秋，o o s e 的创始人i v a rj a c o b s o n 加盟到这一工作。经过b o o c h 、 r u m b a u g h 和j a c o b s o n 三入的共同努力，于1 9 9 6 年6 月和l o 月分别发布了两个 新的版本，即u m l0 9 和u m l0 9 1 ，并将u m 重新命名为u m l ( u n i f i e dm o d e l i n g l a n g u a g e ) 。1 9 9 6 年，一些机构将u m l 作为其商业策略的趋势已逐日明显。u m l 的开发者得到了来自公众的正面反应，并倡议成立了u m l 成员协会，以完善、 加强和促进u m l 的定义工作。当时的成员有d e c 、h p 、i - t o g i x 、i t e l l i c o r p 、i b m 、 i c o nc o m p u t i n g 、m c is y s t e m h o u s e 、m i c r o s o f t 、o r a c l e 、r a t i o n a ls o f t w a r e 、t i 以及u n i s y s 。这一机构对u m l1 0 ( 1 9 9 7 年1 月) 及u m l1 , 1 ( 1 9 9 7 年1 1 月 1 7 日) 的定义和发布起了重要的促进作用。1 9 9 6 年底，u m l 已稳占面向对象技 术建模语言市场的8 5 份额，成为可视化建模语言事实上的工业标准。 第二章统一建模语言与对象关系数据库 1 9 9 7 年1 1 月1 7 日，对象管理组织( o b j e c tm a n a g e m e n tg r o u p ，o m g ) 采 纳u m l1 1 作为基于面向对象技术的标准建模语言，使之最终成为了进行面向 对象分析与设计的统一标准。 2 1 2u m l 表示法 u m l 的宗旨是为设计者和开发者以及用户提供一种统一的系统模型符号表 述，以达到交流建模思想的目的。因此u m l 的表示法在u m l 标准中占有十分 重要的地位。u m l 的表示法主要可由9 种图形来定义，根据其特点可分为5 类： 1 用例图( u s ec a s ed i a g r a m ) 从用户角度来描述的系统功能，并指出各功能的操作者。它并不实际描述软 件系统的组织。从外部的观点来看，用例可描述系统做什么；从内部观点来看， 它可描述功能的操作者与系统如何互动。 2 静态图( s t a t i cd i a g r a m ) 包括类图( c l a s sd i a g r a m ) 、对象图( o b j e c td i a g r a m ) 。 类图描述系统中类的静态结构。不仅定义系统中的类，表示类之间的联系如 关联、依赖、聚集等，也包括类的内部结构( 类的属性和操作) 。类图描述的是 一种静态关系，在系统的整个生命周期都是有效的。 对象图是类图的实例，几乎使用与类图完全相同的标识。他们的不同点在于 对象图显示类的多个对象实例，而不是实际的类。对象图描述系统于某一时间点 的静态数据结构，一个对象图是类图的一个实例。由于对象存在生命周期，因此 对象图只能在系统某一时间段存在。 3 行为图( b e h a v i o r d i a g r a m ) 行为图描述系统的动态模型和组成对象间的交互关系，包括状态图 ( s t a t e c h a r td i a g r a m ) 和活动图( a c t i v i t y d i a g r a m ) 。 状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通 常，状态图是对类图的补充。在实用上并不需要为所有的类画状态图，仅为那些 有多个状态，其行为受外界环境的影响并且发生改变的类画状态图。 活动图描述满足用例要求所要进行的一个连续活动流以及活动流中各个活 动之间的约束关系，它有利于识别并行活动。 4 交互图( i n t e r a c t i v ed i a g r a m ) 交互图描述对象间的交互关系，包括顺序图( s e q u e n c ed i a g r a m ) 和合作图 ( c o l l a b o r a t i o nd i a g r a m ) 。 顺序图描述系统运动时，对象间的互动行为。它着重以时间的先后顺序为主 6 第二章统一建模语言与对象关系数据库 轴以表达对象间的信息传递与处理程序。一个顺序图会有一个与之对应的合作 图，但表达的重点与方式不同。 合作图描述对象问的协作关系，合作图跟顺序图相似，显示对象间的动态合 作关系。除显示信息交换外，合作图还显示对象以及它们之间的关系。 在表述对象的交互关系时，如果强调时间和顺序，则使用顺序图；如果强调 上下级关系，则选择合作图。 5 实现图( i m p l e m e n t a t i o nd i a g r a m ) 包括组件图( c o m p o n e n td i a g r a m ) 和配置图( d e p l o y m e n td i a g r a m ) 。 组件图由组件组成，而组件可以是源代码二进制文件或可执行文件。组件图 用来反映代码的物理结构，说明系统设计过程中各类与对象的配置以及叙述软件 组件间的组织架构和依赖关系。组件图还可以与定义清晰的接口( i n t e r f a c e ) 一 起显示，形成组件包( p a c k a g e ) 。 配置图定义系统中软硬件的物理体系结构。它可以显示实际的计算机和设备 ( 用节点n o d e 表示) 以及它们之间的连接关系，也可显示连接的类型及部件之 间的依赖性。在节点内部，放置可执行部件和对象以显示节点跟可执行软件单元 的对应关系。 2 1 3u m l 的视图 描述一个系统涉及到该系统的许多方面，比如功能性方面( 它包括静态结构 和动态交互) 、非功能性方面( 实时性、可靠性、扩展性等) 和组织管理方厦( 工 作组、映射代码模块等) 。完整地描述一个系统通常的做法是用一组视图反映系 统的各个方面。每个视图代表完整系统描述中的一个抽象，显示这个系统中的一 个特定的方面。每个视图由一组图构成，图中包含了强调系统中某一方面的信息。 视图与视图之间有时会产生轻微的重叠，从而使得一个图实际上可能是多个视图 的一个组成部分。 b o o c h 等人认为建模一个系统的架构可由u m l 的5 个视图来表现，而一个 系统发展过程中的生命周期可通过这5 个不同视图的结合，有效沟通与整合不同 角色的人员对系统设计的看法，而获得一致的发展目标。依据建模系统的架构针 对5 个视图解释如下： 1 用例视图( u s ec a s ev i e w ) 用例视图用于描述系统应该具有的功能集。它是从系统的外部用户角度出发 对系统的抽象表示。用例视图中可以包含若干个用例( u s ec a s e ) ，用例用来表 示系统能够提供的功能。一个用倒是一个系统功能请求的通用描述。 用例视图是其他视图的核心和基础，其他视图的构造和发展依赖于用例视图 7 第二章统一建模语言与对象关系数据库 中所描述的内容。它主要为用户设计人员、开发人员和测试人员而设置。 2 逻辑视图( l c i g i cv i e w ) 用例视图只考虑系统应提供什么样的功能，对这些功能的内部运作情况不予 考虑，为了揭示系统内部的设计和协作状况，要使用逻辑视图描述系统。 逻辑视图用来显示系统内部的功能是怎样设计的。它利用系统的静态结构和 动态行为来刻画系统功能。静态结构描述类对象和它们之间的关系等，动态行为 主要描述对象之间的动态协作。当对象之间彼此发送消息给给定的函数时产生动 态协作、一致性( p e r s i s t e n c e ) 和并发性( c o n c u r r e n c y ) 等性质，这些性质以及 接口和类的内部结构都要在逻辑视图中定义。 3 并发视图( c o n c u r r e n c y v i e w ) 并发视图用来显示系统的并发工作状况。并发视图将系统划分为进程和处理 机方式。通过划分引入并发机制，利用并发，高效地使用资源并行执行和处理异 步事件。除了划分系统为并发执行的控制线程外，并发视图还必须处理通信和这 些线程之间的同步问题。并发视图所描述的方面属于系统中的非功能性质方面。 4 组件视图( c o m p o n e n t v i e w ) 组件视图用来显示代码组件的组织方式。它描述了实现模块( i m p l e m e n t a t i o n m o d u l e ) 和它们之间的依赖关系。组件视图主要供开发者使用。 5 部署视图( d e p l o y m e n t v i e w ) 由构成系统的硬件类型的节点( n o d e s ) 所组成，这个视图主要表达组成实 际系统的各个零件的分配、信息传递与安装。 u m l 建模过程 从应用的角度看，5 个视图配合面向对象的分析与设计，可具体分为3 个步 骤：首先是描述需求；其次根据需求建立系统的静态模型，以构造系统的结构； 第三步是描述系统的行为。其中在第一步主要是实现用例视图中用例图，第二步 主要是实现逻辑视图的静态部分，而第三步是要实现逻辑视图的动态部分和并发 视图以及用例视图的其他部分。如果考虑系统的实现，则第四步需要做的是依次 实现系统的组件视图和部署视图。 表2 - 1 总结了以上5 个视图用到的u m l 图例以及适用的对象。 表2 - 1u m l 视图使用图例与适用对象 8 第二章统一建模语言与对象关系数据库 用例视图用例图、顺序图、合作图、状态图、活动图使用者、设计者、测试者 静态结构类鳗、对象图 逻辑视图 殴计者 动态行为顺序图、合作图、状态图、活动图 并发视图顺序图、合作图、状态图、活动臣、组件图设计者、开发者 组件视图组件图开发者、系统集成者 部署视图配置雹开发者、系统集成者 2 2 类图 类、对象和它们之间的关系是面向对象技术中最基本的元素。对于一个想要 描述的系统，其类模型和对象模型揭示了系统的结构。在u m l 中，类和对象模 型分别由类图和对象图来表示。类图描述类和类之阊的静态关系。与数据模型 ( d a t am o d e l ) 不同，它不仅显示了信息的结构，同时还描述了系统的行为。类 图是定义其它u m l 图形的基础。在类图的基础上，状态图、合作图等进一步描 述了系统其它方面的特性。类图是面向对象方法的核心。 类图主要由类以及类之间的关系组成。 2 2 1 类( c l a s s ) 及其u m l 表示 早在面向对象方法学出现以前，人们就已经学会使用分门别类的方法来简化 复杂问题、认识世界和描述世界。一个显著的例子是生物学上的纲目物种分类法。 对象与我们对客观世界的理解相关，我们通常用对象描述客观世界中某个具体的 实体。所谓类是对一类具有相同特征的对象的描述。而对象是类的实例 ( i n s t a n c e ) 。建立类模型时，我们应尽量与应用领域的概念保持一致，以使模型 更符合客观事实，易修改、易理解和易交流。 类描述一类对象的属性( a t t r i b u t e ) 和行为( b e h a v i o r ) 。在u m l 中，类的 可视化表示为一个划分成三个格子的长方形( 下面两个格子可省略) 。图2 - 1 的 “小汽车”就是一个典型的类。 图2 1 小汽车类 9 第二二章统一建模语言与对象关系数据库 一、类的命名( n a m e ) 为了便于设计者与使用者之间的相互了解与沟通，类的命名应尽量使用应用 领域中的专业术语。类的产生完全依赖设计者的创造力与经验，必须与应用领域 的专家合作，对应用领域仔细地分析，抽象出领域中的概念，定义其含义及相互 关系，分析出系统类，并用领域中的专业术语为类命名。类的名称可以含有任意 个数的英文字母、数字或标点符号的文字。一般而言，类的名称应该是一个短的 名词或名词词组，如图2 - 1 中的“小汽车”就是类的名称。 二、类的属性( a t t r i b u t e ) 类的属性是用来描述该类的共同特征，在系统分析初期绘制类图时可暂时省 略。图2 - 1 中，小汽车类有注册号、日期、速度和方向4 个属性。属性的选择应 考虑以下3 个因素：1 原则上类的属性应能描述并区分每个特定的对象；2 只有 与系统相关的特征才包含在类的属性中；3 系统建模的目的也会影响到属性的选 择。 根据类图的详细程度，每个属性可以包括属性的可见度( v i s i b i l i t y ) 、属性 名称、数据类型、默认值和限制条件。属性的名称可以像类名称一样是文字，一 般而言，属性的名称应该是一个短的名词或名词词组，它可以代表类里面所包含 的特征。u m l 定义类属性的语法为： i 可见度属性名称；属性类型= 默认值 限制条件 l 图2 1 小汽车类中，“速度”属性的描述为： 至互司 可见度“+ ”表示它是公开属性，其属性名称为“速度”，数据类型为“i n t e g e r ”， 此处没有默认值和限制条件。不同的属性具有不同可见度( v i s i b i l i t y ) ，可见度 可区分成公开( p u b l i c ) 、私有( p r i v a t e ) 和保护( p r o t e c t e d ) 三种等级，在u m l 中分别表示为+ 、一和# ：公开，指该属性为公用的，任何操作皆可直接存取， 此时并无任何封装作用：私有，指该属性为类所私有，只限于该类的操作才可存 取，子类的操作也必须调用( c a l l ) 父类的操作进行存取，此时具有百分百的隐 藏性；保护，指该属性为成员( m e m b e r ) 公用，亦即只有自身和其子类内的操 作才可以存取，非自身和其子类的操作必须调用成员内的操作代为存取。数据类 型表示该属性的种类，它可以是基本数据类型，例如整数、文字字符串或布尔型 态等，也可以是使用者自行定义的数据类型( u s e r d e f i n e dd a t at y p e ，u d t ) 。 通常属性是由设计者所使用的程序语言或数据库管理系统来决定。限制条件是设 计者对该属性的限制说明，例如“ 只读) ”则表示该属性是只读属性。 1 0 第二章统一建模语言与对象关系数据库 三、类的操作( o p e r a t i o n ) 类的操作在系统分析初期阶段可暂时省略，后续可不断反复精炼以增加其内 涵，达到完整或完美的程度。操作是由某个类的对象所要求服务的实现，它跟类 的行为有关。换言之，操作也是某些事物的抽象化，同时也可以被某一类里面的 所有对象共享。一个类可以拥有许多的操作，甚至也可能没有任何操作。在u m l 中操作与方法( m e t h o d ) 分别有不同的定义。方法是操作的实现，而操作通常 也被称为功能( f u n c t i o n ) ，但是它的使用范围被限制在类的内部，只能作用到该 类的对象上。操作名称、返回值类型和参数表组成操作接口，操作名称可以是文 字，习惯上是以一个短的动词或动词词组来表示，它可以代表类里面所包含的行 为。u m l 定义操作的语法为： | 可见度操作名称( 参数表) ：返回值型态 限制条件 | 操作的可见度与限制条件的描述和属性的可见度与限制条件的描述一致。 参数表由多个参数用逗号分开构成参数的语法格式为： l 参数名：参数类型名= 缺省值 限制条件) i 在图2 - 1 中，小汽车类有“d r i v e ”一项操作，表示为： l + d r i v e ( s p e e d ：i n t e g e r ，d i r e c t i o n ：d i r e c t i o n ) l 其中+ 表示该操作是公开操作，使用时需要给予“s p e e d ”和“d i r e c t i o n ”两 项参数值，其中“s p e e d ”参数为i n t e g e r 型，“d i r e c t i o n ”为d i r e c t i o n 型，这个操 作没有返回值。 四、永续类( p e r s i s t e n tc l a s s ) 有一种特别的类叫作永续类( 持久类) ，它与u m l 的数据库建模紧密相关。 如图2 2 ，当产生对象的程序“d r a w ”运行结束时所需的图画对象便生成了，同 时生成的对象将自身存入数据库，文件或其它永久性的存储器中。通常该类还会 有一个类作用域操作，用此操作完成对象的存储。通常这种操作表示为s t o r e ( ) 、l o a d ( ) 或c r e a t e ( ) 等。在类图中，如果某个类需要定义为永续类， 那么需要在类的名字旁边附加上 p e r s i s t e n t 标志，如图2 - 2 所示。 图2 2 图画类 1 l 第二章统一建模语言与对象关系数据库 2 2 2 类间的关系 类间的关系指的是类间的连结。在面向对象建模中，类闯最重要的关系有： 关联( a s s o c i a t i o n ) 、依赖( d e p e n d e n c y ) 、泛化( g e n e r a l i z a t i o n ) 与实现( r e a l i z a t i o n ) 等四种关系。这些关系分别用不同型态的线来表示，例如依赖用虚线箭头，范化 用实线的空心三角形箭头，关联用实线，实现用虚线的空心三角形箭头表示( 如 表2 4 所示) 。j a c o b s o n 等人( 1 9 9 6 ) 认为对象间并非完全独立，彼此间需知道 对方才能完成某一工作。对象间的关系可分成两种：静态( s t a t i c ) 与动态 ( d y n a m i c ) 。前者意味着一个对象知道另一个对象的存在，这种关系并不给予 一个对象权限去改变另一个对象的信息：而后者意味着两对象间有相互沟通。 2 2 2 1 关联 关联用于描述类与类之间的连接。由于对象是类的实例，因此类与类之间的 关联也就是其对象之间的关联。类与类之间有多种连接方式，每种连接的含义各 不相同( 语义上的连接) ，但外部表示形式相似，故统称为关联。例如，一个人 为一家公司工作，一家公司有许多办公室。我们就认为人和公司、公司和办公室 之间存在有某种语义上的联系。关联关系是一种类间的静态结构关系，描述类与 类问的连结。关联关系意味着一类的对象知道另一类的对象的存在( j a c o b s o n ， 1 9 9 6 ) 或一类对象使用到另一类的对象的服务，但不是拥有这个服务。若a 类 与b 类间有关联关系，指的是可从a 类的一个对象浏览( n a v i g a t e ) b 类的一个 对象，反之亦然。 1 命名( n a m e ) 关联可以有名称，设计者可以使用名称来描述关系的本质，表达的方式可用 动词或动词词组，命名的原则是该名称是否有助于理解该模型。关联可以是双向 的，其命名方法是每个方向上给一个名称，这样的关联有两个名称，可以用黑色 三角表示名称的方向，如图2 3 中，公司“雇佣”人，人受雇佣”于公司。 图2 - 3 关联的命名 1 2 第二章统一建模语言与对象关系数据库 2 角色( r o l e ) 关联两端的类以某种角色参与关联，描述角色可用名词或名词词组来表达。 例如图2 - 4 中，公司以“雇主”的角色，人以“雇员”的角色参与关联。雇主和 雇员称为角色名。如果在关联上没有标出角色名，则可用类的名称作为角色名。 图2 _ 4 关联的角色 3 多重性( m u l t i p l i c i t y ) 在关联关系中，常需表达有多少对象参与此关联，这里的“多少”称为关联 角色的多重性( m u l t i p l i c i t y ) 。一般来说，有三种关联，分别为一对一( 1 ：1 ) 、 一对多( 1 ：n ) 及多对多( m ：n ) ，其中以阿拉伯数字1 表示一，以英文字母 n 或m 表示多，或用”表示多。在圉2 - 3 中，一家公司( 雇主) 可以雇用一 至多个人( 雇员) ，表示为“1 ，；一个人( 雇员) 能受雇于多家公司( 雇主) ， 表示为“一。多重性表示参与对象的数目的上下界限制。“，代表0 ，1 是 1 1 的简写 4 聚集( a g g r e g a t i o n ) 和组成( c o m p o s i t i o n ) 聚集是一种特殊形式的关联。聚集表示类之间的关系是整体( w h o l e ) 与部 分( p a r t ) 的关系。一辆汽车包含传动系统、制动系统、燃料系统、电路系统及 冷却系统等，这是聚集的一个例子。在需求分析中，“包含”、“组成”、“分为n 部分”等经常被设计成聚集关系。聚集可以进一步区分成共享聚集( s h a r e d a g g r e g a t i o n ) 和组成( c o m p o s i t i o n ) 。例如，项目小组甲有许多成员，但是每个 成员又可以是另一个项目小组乙的成员，即部分可以参加多个整体，成员虽然属 于某个项目小组，但成员也可以单独存在，我们称之为共享聚集( 如图2 5 左) 。 另一种情况是整体拥有各个部分，部分与整体共存如整体不存在了。部分也会 随之消失，这称为组成。例如，一扇窗户由多个框架所组成，当窗户删除，则其 所属框架也需一并删除，因为没有窗户，则其所属框架就没意义( 整体很强的拥 有其部分) ，这种关联关系是组成( 如图2 - 5 右) 。在u m l 中，聚集表示为空心 菱形( 如图2 - 5 左) ，组成表示为实心菱形( 如图2 5 右) 。 第二章统一建模语言与对象关系数据库 5 关联的高级属性 关联构方向 关联可以有方向，表示该关联单方向被使用。关联上加上箭头表示方向，在 u m l 中称为可导览性( n a v i g a b i l i t y ) ，表示可以依箭头方岛找到另一端钓数据。 在一个方向上存在导览的关联，称作单向关联( u n i d i r e c t i o n a la s s o c i a t i o n ) ，在 两个方茼上都有导览的关联，称作双向关联( b i - d h c c t i o n a la s s o c i a t i o n ) 。 限定关联( 0 u a l i f i c a t i o n ) 限定关联用于一对多或多对多的关联关系中。在限定关联中，使用限定词将 关联中。多”的那一端的具体对象分成对象集。限定诃可以理解为一种关键词 用关键词把所有的对象分开。利用限定关联可以把模型中的重数从一对多变成一 对一。类图中，限定词放置在关联关系末端的一个小方框内，紧挨着开始导航的 类。 关联类 与一个关联关系相连的类。称作关联类。关联类并不位于表示关联关系的直 线两端，而是对应一个实际的关联。用关联类表示该实际关联的一些附加信息， 关联中的每个连接与关联类中的对象相联系 2 2 互2 依鞍 有两个元素a 、b ，如果修改元素a 的定义会引起元素b 的定义的改变，则 称元素b 依赖( d e p e n d e n c y ) 于元素a 。在类图中，依赖关系是一种“使用” 的关系( u s i n gr e l a t i o n s h i p ) ，表示一个类会使用到其它类，且棱使用类的改变 可能会影响到使用它的类，但反之则不必然。在u m l 中，依赖表示为一端为箭 头的虚线，箭头是由使用类指向键使用类。如图2 - 6 。 1 4 第二章统一建模语言与对象关系数据库 囤2 - 6 类依赖关系图 2 ，2 2 3 泛化 一个类( 通用元素) 的所有信息属性或操作能被另一个类( 具体元素) 继承， 某个类的类中不仅可以有属于自己的信息，而且还拥有了被继承类中的信息。这 种机制就是泛化。 泛化又称继承，u l v i l 中的泛化是通用元素和具体元素之同的一种分类关系， 具体元素完全拥有通用元素的信息，并且还可附加一些其它信息。泛化的u m l 表述如图2 - 。 图各7 类的泛化关系 2 2 2 4 实现 实现关系很像一般化关系。它表达某一类的行为是由另一类来描述。在面向 对象领域中可允许某类实现其它类，这意味着该实现类必须顺从某接口 第二章统一建模语言与对象关系数据库 ( i n t e r f a c e ) ，但不需用继承。图2 8 为订单输入系统的一部分，图中有两个类： i r a g e n t 类及a c c o u n t r u l e s 类。其中，a c c o u n t r u l e s 类从设计视图( d e s i g n v i e w ) 来看是可以用来实现接口类i r a g e n t ( 如图2 - 8 ，标准的格式) 。同样的，从组件 视图( c o m p o n e n t v i e w ) 来看接口类i r a g e n t 也可以由组件a c c t r u l e 。d l l 来实现( 如 图2 8 ，简化的格式) 。我们可以使用两种方式来表示实现化关系：标准格式与简 化格式。标准格式的表示法是用模板型态( s t e r e o t y p e ) 与一端为大的空心箭头 的虚线( 如图2 8 ，标准的格式) ；简化格式的表示法是用接口棒棒糖图标( 如图 2 8 ，简化的格式) 。 标准格式 a e e t r u l e s d n 2 3 对象关系型数据库 简化格式 图2 - 8 樊的窭蕊关系 关系墅数据库系统的数据是以特定的字段( f i e l d