關鍵字：UML
筆者在Jdon已經反復討論了面向對象的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阻抗存在兩個方面：
Properties vs attributesServices vs Operations
Properties vs attributes
UML核鬧兄淮嬖赼ttributes屬性表達，但是Java從GUI等圖形技術創造出了Java Beans概念以后，將這一概念應用到 服務器編程中，將JavaBeans技術推得更遠，直至我們最近談論的POJO，但是你可知道，我們竟然無法方便地使用UML來 表達POJO的屬性(Properties)這一概念。
因為JavaBeans的Properties是和UML的attributes是有區別的，例如下面是一個普通POJO代碼：
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字段。
文章來源于領測軟件測試網 http://www.kjueaiud.com/