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.anti-gravitydesign.com