UML總結與實踐(一)

      UML--統一建模語言，它作爲一種描述軟件設計的中間語言來說由於具有方便和一致性還是很有價值的，最近幾年也是炒得比較熱（以後可能的軟件開發就可以靠它建立的模型直接生成某種語言的代碼，當然現在UML工具也有這樣的正項工程，但大多隻能生成代碼框架）。UML的內容感覺比較多，而且其工具使用起來也相對比較複雜（比如Rose和EA，都不是特別簡單)，所以要想把UML真正的學好，用好，能給我們的編程帶來方便，而不是僅僅是炒作式的學習還是要費不少功夫的。
      UML中個人覺得其最基本的是一些圖的使用，所以我們在學習時最先要了解這些圖，而且要分類的去考慮它們，UML在這方面也已經做好了。
     在UML中有視圖(view)和圖(diagram)兩個層次的概念：視圖是表達系統的某一方面特徵的UML建模元素的子集，由多個圖構成，是在某一個抽象層上，對系統的抽象表示；而圖是模型元素集的圖形表示，通常由弧(關係)和頂點(其他模型元素)相互連接構成。
     UML中的視圖分爲5大類(每一類的名稱都有好幾種說法，但表示的意思是差不多的，下面主要是按照EA中的分法）：
a)    用例視圖(Use Case View)，強調從用戶角度看到的或需要的系統功能，是被稱爲參與者的外部用戶所能觀察到的系統功能的模型圖。

b)     動態視圖(Dynamic View)，體現了系統的動態或者行爲特徵，也稱爲行爲模型視圖(Behavioral Model View)或併發視圖(Concurrent View)。
c)    邏輯視圖(Logical View)，展現系統的靜態或結構組成及特徵，也被稱爲結構模型視圖(Structural Model View)或者靜態視圖(Static View)。
d)     組件視圖(Component View)，體現了系統實現的結構和行爲特徵，也稱爲實現模型視圖(Implementation Model View)。
e)     配置視圖(Deployment View)，體現了系統實現環境的結構和行爲特徵，也被稱爲環境模型視圖(Environment Model View)或者物理視圖(Physical View)。

      在EA中還有一個Custom,其相當於設計者自己定義的一個視圖，並不是UML的定義。

      UML中的圖有9種：

a)     用例圖(Use Case Diagram)，描述系統功能；

b)     類圖(Class Diagram)，描述系統的靜態結構；

c)     對象圖(Object Diagram)，描述系統在某個時刻的靜態結構；

d)     時序圖(Sequence Diagram)，按時間順序描述系統元素間的交互；

e)     協作圖(Collaboration Diagram)，按照時間和空間順序描述系統元素間的交互和他們之間的關係；

f)      狀態圖(State Diagram)，描述了系統元素的狀態條件和響應；

g)     活動圖(Activity Diagram)，描述了系統元素的活動；

h)     組件圖(Component Diagram)，描述了實現系統的元素的組織；

i)       配置圖(Deployment Diagram)，描述了環境元素的配置，並把實現系統的元素映射到配置上。

      在UML中視圖是由圖構成的，視圖和圖之間的對應關係：
用例視圖：用例圖

動態視圖：時序圖、協作圖、狀態圖和活動圖
邏輯視圖：類圖和對象圖 

組件視圖：組件圖
配置視圖：配置圖    

      在理清了UML中最基本的視圖和圖的概念定義之後，我們可以開始實際的使用它們來方面我們的設計和交流。按照《UML精粹》中的重點，在實際應用中我們使用的最頻繁的是類圖和時序圖。下面就這兩種圖展開說明和學習。

     類圖其實在畫法上比較簡單，在理解上也比較貼近我們實際的程序代碼，當然我們在用好類圖的前提是我們要弄清楚下面幾種關係：

     關聯，依賴，聚合，組合（以下是我個人的理解，與官方的說法在遣詞造句上有些不同，個人感覺官方的說法不太好理解，還不如大白話，呵呵）。

     關聯--類之間存在着引用關係，誰引用誰，所以關聯有方向性，而且還有重數。簡單的說A關聯B，即A中有B的一個成員變量。

public class A
...{
private B b;
}

     

     依賴--類之間的一種使用關係，簡單的說如果一個類向另一個類發送消息,或者一個類是另一個類的數據成員（不是成員變量）,或者一個類是另一個類的某個操作參數,則兩者爲依賴關係。

public class A
...{
public B getB(C c, D d)
...{
E e = new E();
B b = new B(c, d, e);
}
}

    這裏類A就依賴於類B（方法返回類）、C和D（參數類）、E（方法內變量的類），因爲這幾個類的變化都有可能影響到類A。

    在這裏有一點要說明的，由於在依賴關係中例如類B，它並不是A的成員變量，所以我們在利用實際的UML工具，如EA時當畫出依賴關係後，在正項和逆向工程中都無法使圖和代碼想對應，這一點在現在的UML工具中比較不爽。

     聚合--聚合也是一種關聯關係，與普通的關聯不同的是，它描述的是一個整體和組成部分的關係，即“has-a”關係，意思是整體對象擁有部分對象，例如學校和學生的關係。聚合的整體和部分之間在生命週期上沒有什麼必然的聯繫，部分對象可以在整體對象創建之前創建，也可以在整體對象銷燬之後銷燬。

      實際上在用程序代碼來表示關聯關係和聚合關係時，兩者比較相似。

public class Bicycle...{
private Bell bell;
public Bell getBell()...{
return bell;
}
public void setBell(Bell bell)...{
this.bell=bell;
}
// 發出鈴聲 
public void alert()...{
bell.ring();
}
}

     組合--組合是比聚合更強的關聯形式。組合是指帶有很強的擁有有關係且整體與部分的生命週期一致的聚合關聯形式。例如Windows的窗口和窗口上的菜單就是組合關係。生命週期一致指的是部分必須在組合創建的同時或者之後創建，在組合銷燬之前或者同時銷燬，部分的生命週期不會超出組合的生命週期。

     組合和聚合在代碼實現上的主要差別在於生命週期的實現上，組成需要負責其部分的創建和銷燬。另外還有一個差別是組合中的一個對象在同一時刻只能屬於一個組成對象，而聚合的一個部分對象可以被多個整體對象聚合，例如一個學生可以在多個學校就讀，而一個菜單在同一時刻只能是某個窗口內的對象。    

public Class Window
...{
private Menu menu;
public Window()
...{
menu = new Menu();
}//可以在這時候創建Menu對象，也可以在之後創建
public void destory()
...{
menu.destory();
}//必須同時或者在這之前銷燬關聯的Menu對象
}

      總體來說，關聯和依賴是同級的，組合是一種聚合，而聚合是一種關聯。我們知道在Java的面向對象的體系中有個概念叫引用，而在UML中沒有這個概念，但我們能發現在實現組合、聚合和關聯時無可避免的要用到引用，但實現依賴時卻不一定用到。       
      如果我們能真正理解上述四種關係，那麼實際應用起類圖來就很簡單了。

      未完，待續.........