用UML描述Java类

发表于:2007-05-25来源:作者:点击数: 标签:程序员javauml本文描述
本文从 Java 程序员 的角度阐述UML和对象建模问题,是一个深入浅出的实用性介绍。虽然从历史和基本理念方面来探讨UML非常吸引人,但我们还是直接从Java代码开始,看看UML如何描述Java类,再在叙述过程中插入一些历史和基本理念方面的知识。 UML类图 在Java中
本文从Java程序员的角度阐述UML和对象建模问题,是一个深入浅出的实用性介绍。虽然从历史和基本理念方面来探讨UML非常吸引人,但我们还是直接从Java代码开始,看看UML如何描述Java类,再在叙述过程中插入一些历史和基本理念方面的知识

UML类图


在Java中,我们用下面的代码声明两个公用类,每一个Java类放入一个文件,文件的名字就是Java类的名字加上扩展名.java


            public class Person{}
            public class Organization{}
            


UML是Unified Modeling Language的缩写,即“统一建模语言”。与Java不同,UML是一种图形化的建模“语言”,它用一个矩形来表示一个类,在矩形的内部写上类的名称,一个类图可以放入多个类。用矩形表示类,是UML中U(Unified)起的作用。在UML的第一个版本出现,每一个对象建模专家都有自己的一套符号,一些人用点表示类,一些人用圆圈表示类,还有一些人用圆角矩形表示类。显然,这很容易引起混乱。后来,Rational公司的三个专家——Grady Booch、James Raumbaugh、Ivar Jacobson达成了一致意见,同意“统一”他们各自使用的符号,UML终于创立,符号之争也终于落下了帷幕。图一就是上面两个Java类的UML类图:



图一:有二个类的简单类图


如果要描述一系列类的内部结构以及它们相互之间的关系,UML类图是非常有用的。例如,在许多书籍中,我们可以看到作者用类图来描述各个类之间的关系。

显然,空的类没有什么实际意义。我们要为Person类加上一些实例变量和简单的方法。下面是Person类的代码,已经过简化处理,不含任何注释:


            public class Person {
            private String name;
            private String socialSecurityNumber;
            private Date dateOfBirth;
            private String emailAddress;
            public String getName() { return name; }
            public void setName(String name) { this.name = name; }
            public String getSocialSecurityNumber() { return socialSecurityNumber; }
            public void setSocialSecurityNumber(String socialSecurityNumber)
            { this.socialSecurityNumber = socialSecurityNumber; }
            public Date getDateOfBirth() { return dateOfBirth; }
            public void setDateOfBirth(Date dateOfBirth) { this.dateOfBirth = dateOfBirth; }
            public int calcAgeInYears() {/*not implemented yet*/return 0;}
            }
            


图二显示了Person类的UML图。可以看到,UML用“+”和“-”符号分别表示public和private修饰符。UML只显示操作和属性类型之类的特征信息,操作的结果在行未的冒号之后声明。



图二:在UML类图中描述属性和方法


由于UML类图不包含方法的具体实现,所以在UML类图中查看属性和方法等基本信息要比直接查看Java源代码更方便一些。在创建UML图时,人们常常忽略或隐藏各种细节信息,以便查看和掌握类的整体结构。例如,UML类图常常只显示出属性和操作的名称,简单的访问器方法(诸如getXXX()、setXXX()之类的方法)也常常不显示出来。图三就是简化图二得到的结果。



图三:经过简化的Person类UML图


图三清楚地显示出了Person类主要的属性和方法。但是,单个类的UML图还不是很有用。只有包含多个类且描述了多个类之间关系的UML图,才具有实用意义。UML用两个类之间的连线来表示两者之间的关系,不同的线型表示不同的关系,在UML类图中最常见的关系是关联关系。

关联关系


前面Person类的属性都是简单类型(Primitive Type),或者说是Java直接提供的标准类型。现在来考虑下面的代码片断,它增加了一个对Organization实例的引用:


            public class Person {
            ...
            private Organization employer;
            ...
            }
            


引用的名称是employer,意味着这里的Organization代表着Person的雇主。图四显示了如何在UML中描述这种关系:



图四:两个类之间的关联关系


两个类之间的连线表示Person类对Organization类有一种依赖关系。这条线是一条实线(而不是虚线),表示这种依赖关系是一种关联。

如有必要,关联关系可显示出角色、多重性、关联方向等属性。图四的关联关系显示出Organization对象在该关系中是雇主的角色,“0..1”表示每一个Person类的对象最多和一个Organization类的对象有关系,也可能和0个Organization对象有关系(即Person对Organization的引用可设置为null)。开叉的箭头表示Person类拥有对Organization的引用,而不是Organization拥有对Person的引用。

多重性


多重性回答这样一个问题:在一个关系中,每个类各有多少对象参与其中?常见的多重性如图五所示。



图五:常见的多重性及其含义


前面我们已经看到了Java代码中0..1多重性的实例。不难猜测,多重性为“1”意味着一个类对另一个类的引用不能为null(一般是这样一种情形:引用的值在构造函数中初始化,且在所有相关的set方法中禁止把该引用设置为null)。

值为“1..*”和“0..*”的多重性稍微复杂一点。在Java中,实现这类多重性的途径之一是使用某种集合类,例如Vector,来保存可能需要用到的多个引用:

多重性回答这样一个问题:在一个关系中,每个类各有多少对象参与其中?常见的多重性如图五所示。前面我们已经看到了Java代码中0..1多重性的实例。不难猜测,多重性为“1”意味着一个类对另一个类的引用不能为null(一般是这样一种情形:引用的值在构造函数中初始化,且在所有相关的set方法中禁止把该引用设置为null)。值为“1..*”和“0..*”的多重性稍微复杂一点。在Java中,实现这类多重性的途径之一是使用某种集合类,例如Vector,来保存可能需要用到的多个引用:

            ClassA
            {
            ...
            Vector classB; // 保存B类对象引用的Vector
            ...
            }
            


对于“1..*”多重性,Java程序必须确保Vector至少包含一项内容。

在有些关系中,多重性的值可以是某个精确的范围或数字。例如,一个小孩最多有两个生物学意义上的健在双亲,即它的多重性可表示为“0..2”。用Java代码描述这种关系时,程序必须带有确保Parent对象实例少于或等于2个的约束。

一个UML关联加上多重性、角色、关联方向之后,能够描述出大量信息,远比一大堆Java源代码简洁和直观。虽然UML图没有说明关系的具体实现方式,但它能够充分地说明关系的意义和作用。图六显示了标注多重性、角色名称之后的雇佣关系,它表示一个Person可以为多个Organization工作,一个Organization可以雇佣多个Person。



图六:双向关联关系


聚合与合成


关联只是UML中的关系之一。下面我们来看看UML中的其他两种关系——聚合(Aggregation)和合成(Composition),它们实际上是关联关系的不同变种。聚合是这样一种关联关系,在这种关系中一个类的对象代表着另一个类的对象的一部分,有的人因此也把聚合关系叫做“全体-部分”关系。聚合关系用实线空心菱形箭头表示,箭头由表示Part的类指向表示Whole的类,参见图七。



图七:聚合与合成


那么,在Java程序中聚合关系又是什么样的呢?答案是:这要看你在问谁。聚合是一个有争议的概念,表达的是一种生命周期依赖关系。有人根据习惯认为,聚合意味着Whole类必须负责创建和拆除Part类的对象;但也有人为聚合关系下了更宽松的定义。到底应该怎么理解,你最好能够在合作者之间取得一致意见和约定,避免混淆。

合成是一种较强的聚合关系。这两种关系基本相似,不同之处在于,在合成关系中,Part的对象任何时候只能从属于一个Whole对象,也就是说,必须用Java代码确保这种唯一的从属关系。

前面我们已经看到,类的属性、操作以及各个类之间的关系可以用UML类图来描述。然而,对于Java类里面的对象引用,什么时候应该把它当作关联关系、什么时候把它当作属性,这一点还没有搞清楚。答案是:要在哪一个层次交流信息,UML图就应该具体到哪一个层次。有些时候,即使是简单的对象,也最好画出它的类图,把其他类对它的引用描述成关联关系;另一些时候,可能需要把对象引用表示成属性,甚至从类图完全省略对该对象的引用,以便在类图中突出显示其他更重要的类和关系。大多数的UML工具软件都提供了隐藏UML类图各种细节信息的机制。

获得UML图一般有两种办法,手工设计UML图(在此基础上可由UML工具生成Java应用的骨架代码),或者用工具分析Java源代码(甚至字节码)获得UML图。一些优秀的UML工具能够在你绘制UML图的同时生成Java代码,在你编辑Java代码的同时更新UML图。例如TogetherSoft的Together ControlCentre,本文的UML图就是用这个工具绘制的,有免费版Together Community Edition可供试用。

结束语:本文就到这里结束。在下一篇文章中,我们将分析如何在UML中表示Java的两个重要概念:继承,接口。

原文转自:http://www.ltesting.net