UML和Java的阻抗

笔者已经反复讨论了面向对象的Java和数据库的阻抗不匹配性（mismatch），并提出“数据库时代的终结”。但是，作为同为面向对象的工具实现UML和Java之间也同样存在着阻抗和匹配，在实际应用中，我们常用两种 方式来表达我们的设计意图：Java源码或UML图形，那么哪一个更方便更准确表达设计意图呢？这是仁者见仁智者见智了。 在实际中视使用者爱好。

　　那么，UML和Java同为表达工具，两者是否一致呢？回答是否定的。 根据Is UML out of date(http://www.step-10.com/objectmodeling/IsUMLOutOfDate.html)一文作者认为两者存在区别，从这篇文章中我们也可以看出UML和Java硝烟战背后的 一些原由，比如由一些UML派的大师在Java领域挑起的EJB和POJO纷争，从该文我们知道这可能是因为UML中无法表达EJB这样的Service性质特殊operations而引起的；当Java领域争论平息后，UML大师门虽然开始将引导公众焦点转移到其他语言如Ruby on Rails， 但是喧闹过后，遗留下来的是真相，就象潮水退却之后，暴露出来的依然是那些石头一样。

　　为什么说Is UML out of date一文具有切实性呢？因为作者是参与borland together这类UML建模工具具体实现上的，这是来自实战第一线的疑问和彷徨。在Is UML out of date一文中，作者认为UML和Java阻抗存在两个方面：

1. Properties vs attributes
2. Services vs Operations

Properties vs attributes

　　UML核心中只存在attributes属性表达，但是Java从GUI等图形技术创造出了Java Beans概念以后，将这一概念应用到 服务器编程中，将JavaBeans技术推得更远，直至我们最近谈论的POJO，但是你可知道，我们竟然无法方便地使用UML来 表达POJO的属性(Properties)这一概念。

　　因为JavaBeans的Properties是和UML的attributes是有区别的，例如下面是一个普通POJO代码：

clearcase/" target="_blank" >cccccc border=0>

public class A{ 　　private String property; 　　public String getProperty(){ 　　　　return property; 　　} 　　public void setProperty(String property){ 　　　　this.property = property; 　　} }

　　A类中属性property其实是一个Properties,Properties定义是：它的值通过一个只读方式获得；通过一个只写方式赋值，而attributes值的获得和更改不一定有如此严格限制。

　　Properties实际是attribute和类的property访问方法的组合，而且特点就是在访问方法，一般都是通过setXXX赋值；通过getXXX获值，Properties甚至可能根本不需要类内部一定要有一个attribute字段。

　　使用UML图attribute表达property如下：（引自Is UML out of date一文)

　　这样的图从表面上看不错，但是问题来了：一些建模工具的代码产生器根本无法识别这是一种POJO的Properties表示，因此我们可能无法产生普通POJO代码（进而无法使用POJO的优点了），那么只有画图者使用手工来实现，这很烦琐，失去了使用UML工具帮助我们设计的目的了。

　　Borland的 Together是通过拓展UML核心概念，引入Properties这样一个和attributes类似新的定义来表达。 如图（引自Is UML out of date一文)：

　　左边是Property表达，右图是Together可自动展开的Property表达，setXXX和getXXX方法都会自动产生。

Services vs Operations
　　UML和Java不匹配之处还在于UML无法区分表达Services和Operations区别，在当今SOA面向服务为主要概念的 Java实现领域，UML竟然无法清晰地表达Service接口和普通接口的区别，让我们来仔细看个究竟：

　　首先，我们看看Operations的定义：在接口中的一个行为Operations可能代表一段业务事务处理过程，供外部客户端调用（如供表现层调用等，这些行为这时称为提供服务Services），但是，一些public行为可能只是用于业务层内部系统之间相互调用，而不是展现给外部，供外部 系统或客户端调用的，一些行为也许只是为主要业务逻辑提供辅助技术帮助的，根本不是主要业务逻辑方法，还有一些行为只不过提供对内部属性attribute的访问方法罢了。

　　 UML如何区别同样的行为Operations不同的内外调用目的呢？实际也就是供外部调用的Service和内部调用的普通Operations 区别呢？

　　例如，我们有两个服务Service接口Class1Services和Class2Services，这是对外暴露，不仅可供表现层客户端调用，还可通过Web Services向 外部系统提供，另外还有两个类Class1和Class2是供内部调用的，当使用UML表达时，如下图（引自Is UML out of date一文)：

　　UML复杂的继承关系已经扰乱我们的视线，我们已经无法区分这两种类（Services和普通Operations）区别；而下图中是使用 Java Design and Streamlined Object Modeling 一书中简化的表示方法，我们可以分清这两种区别。

　　所以，对于同样是POJO的两种类不同功能实现Services和普通Operations UML已经表现得无能为力了，那么对于服务Service概念 起源组件EJB，UML更加苍白，笔者猜想，怪不得UML设计界拼命诋毁EJB，包括Matin Fowler还亲自出场，原来UML和EJB之间是一场
不是你死就是我活的战斗，总算EJB发展到EJB3也变成了一个纯粹的POJO，但是EJB带来的Service概念还是在POJO中保留下来，同时基于Web Services的SOA 概念的兴起将服务Service概念推向更深处，尽管Matin Fowler等UML设计派还在对SOA说“风凉话”，但是UML如果自身不象Java那样与时俱进地更新换代，那么它与Java之间的阻抗不仅仅是表达形式的不匹配，恐怕就变成先进与落后的不匹配了。

　　Is UML out of date作者最后说到，虽然标准的UML可以被我们拓展，这是UML生命力所在，但是如果每个流派在同一个东西上面拥有自己不同的UML子集定义，那么它们之间的交流是否变得困难，这也是我们看UML各大师文章的矛盾所在，每个大师有自己的语义定义，实际搞了半天才知道他们说的是同一回事，这不是在浪费我们草民的时间嘛？

　　那么我们是否到底是否需要一个统一的标准的象UML这样的符号notation工具或者是元模型（meta-model）呢？这个答案取决于你的用处，如果你使用UML来完整表达整个系统结构、功能和状态，答案也许是肯定的，但是这样的复杂UML语法和表达会比直接的Java源码简单直观吗？

　　当然，工具厂商会回答Yes，因为他们可以加入更多标准化功能到下一个版本中,这是很有讽刺味道的，不管怎么说，如果一个新的产品能够帮助我们快速建立一个高质量的软件系统是一件大大的好事，但是这只是 “如果”。

　　如果Java和UML这种发展概念不匹配下去，我们真的要问UML过时了吗？或许它是上个世纪的产物？ 也许正是因为这点，一些敏捷软件专家们开始害怕，将我们视线从Java身上转移到Rubby on Rails语言或其他语言，也许在这些语言上面，UML神话地位依然得到保证和延续。

本文原文：http://www.step-10.com/objectmodeling/IsUMLOutOfDate.html

 

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