在UML中表示Java继承和接口

1、在UML中表示Java继承和接口作者：仙人掌工作室本文选自：赛迪网在上一篇文章中，我们引入了 UML类图的概念，比较了在Java编程语言和UML类图 中表示类、属性、操作和关联关系的不同之处。下面我们来看看如何在UML中表示两个重 要的Java概念一一继承，接口。继承在Java中，我们可以声明一个类扩展(extends)另一个类，还可以声明一个类实现 (implements) 一个或者多个接口。下面我们来看看如何在UML中表达这些概念。下面是三个Java类的基本骨架。第一个类是代表某种支付方式的Payment抽象类， 另外两个类分别扩展Payment类，描述两种不同的支付方式：/* 描述支付方

2、式的抽象类 */ abstract public class Payment public Payment() public Payment(BigDecimal amount) this, amount = amount; public BigDecimal getAmount 0 return amount;public void setAmount(BigDecimal amount) this, amount = amount;private BigDecimal amount; /* 一个扩展了 Payment类的子类，描述信用卡支付方 式 */ public class Credi

3、tCardPayment extends Payment public CreditCardPayment 0 public CreditCardPayment(BigDecimal amount) super(amount); public String getCardNumber0 returncardNumber; public void setCardNumber(String cardNumber) this. cardNumber = cardNumber; public boolean authorize() return false; 暂不实现 private String c

4、ardNumber; /* 一个扩展Payment类的子类，描述现金支付方式*/ public class CashPayment extends Payment public CashPayment 0 super 0; publicCashPayment(BigDecimal amount) super(amount); public BigDecimalgetAmountTendered0 return amountTendered; public voidsetAmountTendered(BigDecimal amountTendered) this. amountTendered

5、= amountTendered; private BigDecimal amountTendered; public BigDecimalcalcChange() return amountTendered. subtract(super. getAmount (); 图一用UML显示了同样的三个类。在操作和属性声明中，类型和参数之类的细节都没 有显示出来，这是为了更清楚地显示出类的整体结构以及各个类之间的关系。图一：UML一般化关系Java中的extends关键词声明了继承关系，相当于UML中的一般化” （Generalization,也译为“泛化”）关系，在UML图形中用子类向超类的实线

6、空心封闭 箭头表示。图一额外增加了一个Sale类，这是为了更清楚地说明UML一般化关系与UML 定向关联关系所用箭头的不同。关联关系与一般化关系的另一个不同之处在于，一般化关 系的两端不需要说明多重性或角色名称。显然，UML类图比三个Java源代码文件更清楚直观地显示出了三个类之间的继承关系。 如果你要与别人探讨设计思路，绘制UML草图也要比直接使用代码简单快捷得多。也许有人会说，系统的类结构图就在他们的头脑中，他们只需要直接使用Java代码。 实际上，对于规模较大的系统，这种说法显然是不成立的：即使对于规模较小的系统，如 果一定的时间之后要由其他程序员修改，没有UML图也会寸步难行一一很难保

7、证每一个人 都了解你头脑中的类结构图。在UML中，抽象类的标志是类的名字以斜体显示。在白板或纸张上手工画UML草图时, 很难区分字体是否是斜体。为此，一些人建议这些场合可以在类名称的右下角加上 abstract）标记以示区别。另一些人认为，在白板上写abstrac t显得太罗嗦，他们倾向于打破UML常规，在 类名称的右下角加上一个。表示零个实例，如果在该位置写上1，则表示该类是一个 singleton类（永远只有一个实例的类）；如果在该位置写上N,则表示它是一个枚举类 （拥有固定实例数量的类，如一星期中的天数，彩虹的颜色，等等）。不过，这一切都不 是标准的UML,只能用于手工绘制UML图的场合

8、，看来也不可能得到UML建模工具的支持。历史知识：UML首先由Rational公司的一个工作组发明，Ration公司是UML建模工 具Rose的生产者。UML 于 1995年的OOPSLA会议上被公诸于世，随后，OMG （对象管理组 织）于1997年采用了 UML规范。不难理解，继续负责发展UML规范的0MG任务组包含了来自几乎所有主流UML工具厂商的代表。因 此，除了严格遵从规范的UML软件工具，在一些书籍或网页上发现不规范的UML符号也不 足为怪。继承使得一个类能够使用另一个类的属性和方法，就象使用自己的属性和方法一样。 当这类继承机制第一次出现时，人们普遍把它视为重用现有代码的理想方法。

9、令人遗憾的 是，规模过于庞大的继承树变得很脆弱，修改继承树的一部分，就会在整棵继承树中引起 一系列的连带反映。在面向对象的编程中，如果要实现有效的封装，就应该让改动局部化, 即一个地方的改动不至于引起其他地方的变化。而修改继承树一个地方引起其他地方的变 化恰恰违背了上述设计思想。UML图使得我们能够方便地掌握继承关系图，从而为应用继 承关系带来了方便。那么，什么时候适合运用继承关系呢？按照Java Design一书， 对于超类A和子类B,执行如下检查：命题“B是一个由A扮演的角色”不成立。B永远不需要变形成为其他某些类别中的对象。B扩展而不是覆盖或废弃A的行为。A不仅仅是一个工具类（一些可以重

10、用的实用功能）。对于一个问题域（特定的业务对象环境）：A和B定义了同一类型的对象，或者是用 户事务、角色、实体（团体、位置或其他东西），或其他物体的相似类别。如果上述任意一个判断不成立，那么把A和B定义成继承关系可能是不合适的，改用 关联关系可能更加稳固、正确。例如，图二违背上面的第一个判断，因为“雇员是一个由 人扮演的角色”成立。另外，它还违背了第二个判断，因为雇员确实可能改变其类别（身 份），例如某个时候它可能是顾客。这样，一个既是顾客乂是雇员的人就要有两个独立的 对象来描述，从而使保存在Person类里面的信息重复出现，带来了两个数据副本之间数 据不一致的风险。接口Java编程语言中接口

11、（Interface）的概念也能够与UML概念匹配。UML中的接口是 一种实现继承的形式，但这种继承形式与Java中通过关键词extends实现的继承有所不 同。在Java中，extends关健词描述了一种继承形式，它既继承接口也继承行为。这种类 型的继承有时被称为Sub-classing。与其他的面象对象编程语言不同，Java类只能从一 个类继承。许多时候，设计UML图的人熟悉多种编程语言，常常会引入多重继承的思想， 例如C+的多重继承思想。从已有的Java代码生成UML图（这个过程称为反向工程）不会 带来多重继承的问题，但如果要求一个Java程序员去实现一个带有多重继承的UML类图, 就会

12、出现问题。如果多重继承中的超类是纯抽象类，这部分类可以用Java的接口来描述, 但是，如果只做这种转换不足以把UML类图中的多重继承全部转换成单重继承，这时就必 须修改UML类图重新建模了。虽然Java不支持C+之类语言那样的多重继承，但它支持实现多重接口。这种由 Java关键词implements声明的继承只继承接口，这种继承有时被称作Subryping。在 UML中，实现接口的类与接口定义之间的关系叫做Realization关系，用一个虚线封闭箭 头表示，从实现接口的类指向接口。接口本身的UML图与普通类一样，但它的名字上面要加上“ 图四由图一修改而成，Payment类被一个接口取代。 （

13、关于Realization名称的说明：Realization最常见的中文译名是“实现”。但是, Java的implements也叫做实现。为避免混淆,本文中凡是出现Realization的地方 一律直接使用英文）。接口可以从一个或者多个其他接口扩展。UML一般化关系（实线封闭箭头）可用来描 述这种关系，如图五所示。UML还支持另一种接口符号，即用圆圈表示接口（加上连线之后就成了棒棒糖的样 子），但这种表示法多用于UML组件图，在UML类图中比较少见。如果UML图规模较大，有大量的类实现一个常用接口，整个UML图可能乱成一团糟。 Java Design一书提出了一种简化方法,后来又被（Streamlined Object Modeling 一书的作者采用，这就是在实现接口的类