使用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之間的阻抗不僅僅是表達形式的不匹配，恐怕就變成先進與落后
文章來源于領測軟件測試網 http://www.kjueaiud.com/
