UML

?

UML不是OOA/D 也不是方法,它僅僅是一種圖形表示法。其目的就是讓人能看懂你的東西。

每一種圖，都相當于一種角度。不同的圖就是從不同角度來觀察系統。

比如交通圖和行政區劃圖，從不同角度觀察中國。

?

必要性是畫圖的原則，雖然有這種關系，但不一定要畫出來，如果非要畫出來，則應考慮不要影響圖形的美觀。

?

活動圖

活動圖表示的是一種流程。

例子：

順序圖

順序圖的目的是為對象分配職責，而不是步驟的羅列。

上圖中，ActionServlet是沒有必要畫出來的，它是一個很穩定，也不是我們自己提供的，沒有必要來說明它的對象職責。插在這里顯然多余.

如下圖這樣就可以了：

用例和用例圖

用例的定義：文本形式的情節描述。

?

用例用于需求的發現和記錄，它會影響后續的OOA/D工作

?

用例不是用例圖。用例圖不重要，用例描述很重要。

?

用例盡量不要用名詞命名，盡量以動詞開頭，比如：管理商品。

用例一般是用于功能性的需求而非性能性需求。

編寫用例時，在基本路徑（即主成功路徑）中，只書寫主要的成功事件，而可能出現的其他情況（如找不到用戶）應該寫在擴展點中。

?

用例粒度：比如：是把管理用戶當做用例還是把添加用戶和刪除用戶分別當做兩個用例。

確定用例的粒度時，應該考慮描述這個用例的基本路徑需要幾個步驟。十步以內，七八步比較合適。

一個典型的用例描述

一個典型用例圖

其中銷售經理和收銀員之關系是泛化關系，即經理擁有收銀員所擁有的一切用例。另外還有其獨有的用例。

類圖

類圖允許我們標記靜態內容及類之間的關系，它是UML中最重要的圖形，可以在任何時候嘗試使用類圖。

不要使用類圖描述所有的細節，保持類圖的簡單。

UML中主要有三種類：邊界類、控制類和實體類

邊界類位于系統與外界的交界處，例如窗體、報表、以及表示通訊協議的類、直接與外部設備交互的類、直接與外部系統交互的類等。通過用例圖可以確定需要的邊界類，每個Actor/Use Case對至少要一個邊界類，但并非每個Actor/Use Case對要唯一的邊界類。

實體類可以通過事件流和交互圖發現。通常每個實體類在數據庫中有相應的表，實體類中的屬性對應數據庫表中的字段。

控制類是控制其他類工作的類。控制類可以被多個用例共用。其他類并不向控制類發送很多消息，而是由控制類發出很多消息。

?

類圖中，要畫出類之間的關系

UML中繼承、實現、依賴、關聯、聚合、組合的聯系與區別

繼承?(也叫泛化)

指的是一個類（稱為子類、子接口）繼承另外的一個類（稱為父類、父接口）的功能，并可以增加它自己的新功能的能力，繼承是類與類或者接口與接口之間最常見的關系；在Java中此類關系通過關鍵字extends明確標識，在設計時一般沒有爭議性；

實現

指的是一個class類實現interface接口（可以是多個）的功能；實現是類與接口之間最常見的關系；在Java中此類關系通過關鍵字 implements明確標識，在設計時一般沒有爭議性；

依賴

可以簡單的理解，就是一個類A使用到了另一個類B，而這種使用關系是具有偶然性的、臨時性的、非常弱的，但是B類的變化會影響到A；比如某人要過河，需要借用一條船，此時人與船之間的關系就是依賴；表現在代碼層面，為類B作為參數被類A在某個method方法中使用；

關聯

他體現的是兩個類、或者類與接口之間語義級別的一種強依賴關系，比如我和我的朋友；這種關系比依賴更強、不存在依賴關系的偶然性、關系也不是臨時性的，一般是長期性的，而且雙方的關系一般是平等的、關聯可以是單向、雙向的；表現在代碼層面，為被關聯類B以類屬性的形式出現在關聯類A中，也可能是關聯類A引用了一個類型為被關聯類B的全局變量；

聚合

聚合是關聯關系的一種特例，他體現的是整體與部分、擁有的關系，即has-a的關系，此時整體與部分之間是可分離的，他們可以具有各自的生命周期，部分可以屬于多個整體對象，也可以為多個整體對象共享；比如計算機與CPU、公司與員工的關系等；表現在代碼層面，和關聯關系是一致的，只能從語義級別來 區分；

組合

組合也是關聯關系的一種特例，他體現的是一種contains-a的關系，這種關系比聚合更強，也稱為強聚合；他同樣體現整體與部分間的關系，但此時整體與部分是不可分的，整體的生命周期結束也就意味著部分的生命周期結束；比如你和你的大腦；表現在代碼層面，和關聯關系是一致的，只能從語義級別來區 分；

總結：

繼承、實現體現的是類與類、或者類與接口間的縱向關系,不易混淆；其他的四者關系則體現的是類與類、或者類與接口間的引用、橫向關系，這幾種關系都是語義級別的，所以從代碼層面并不能完全區分開來；

例如在關心汽車的領域里，輪胎是一定要組合在汽車類中的，因為它離開了汽車就沒有意義了。但是在賣輪胎的店鋪業務里，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。

總的來說，后幾種關系所表現的強弱程度依次為：組合>聚合>關聯>依賴

示例一

關聯之特殊示例，下圖表示一種樹形結構類圖，

可以用如下代碼實現

Public Class Node{

??????? Public??????? ID;

??????? Private Node??????? parent;

??????? Private Set<Node>??????? children;

}

示例二：

已經在關聯中表明了 Document 具有一個User類型的字段 Creator，故不必在Document中再寫出Creator了。

示例三：

由于User是另一個復雜的概念，所以要建立關聯，而不是把User也作為一個簡單的屬性（如name那樣）

不要把復雜的領域概念建模為屬性。

?

?示例四:

Student 與 class 之間是雙向關聯關系，當然也可以說成是student依賴class，因為沒有class，student是不能編譯通過的。但畫圖并不是所有存在的東西都要畫出來，這里表示成關聯關系更為貼切些。

另外，關聯指的是關心對方的結構，如果對象A只是用一用對象B的某個方法，比如Collections.sort(), 這顯然是依賴而非關聯。

---

基于領域模型的系統設計初步

設計時重要原則:

??????? 低耦合,高內聚.

??????????????? 盡量降低對不穩定對象的依賴。對于非常穩定的東西，比如JDK的核心類庫，盡可以隨便依賴它。

??????? 不要依賴于正向工程和逆向工程，如果你要讓其從圖形生成代碼，則你不得不在圖形中注意各種細節，那不如你自己寫代碼。

??????? 圖形是為了抽象出邏輯主干，方便人理解，它不能替代詳細完整的文字描述。

系統的核心價值

領域模型的價值不在于它的設計優美(它只是一些對象﹐最重要的也就是對象之間的關系)﹐而在于它體現了系統的核心價值。什么是系統的核心價值呢?我想我們的圖書館系統和華爾街的一個商業系統本質的區別不在于系統用了什么語言、用了什么數據庫、用的是OO還是過程，而在于系統能為使用者提供什么服務，以及提供的質量。這些通過系統的運行方式﹐系統的運行過程﹐系統的業務邏輯來體現。

用例的價值

系統分析員在接手一個系統后﹐首先要做到的事情就是得出系統的服務和服務場景。也就是我們經常所講的用例(use case)

很多人不清楚清晰的用例的價值，只是因為看別人有漂亮的圖形，所以自己也畫一個，其實自己都不去看它。這樣的用例分析只能糊弄一下老板，給別人show一下Demo﹐而不會對系統開發什么實質作用。

用例表示的是使用系統的一個場景﹐其本質在于詳細描述了系統用戶(actor)與系統是如何交互的﹐以及交互的后果是什么﹐詳細而完善的用例將指導您進行系統開發的全過程

?

低耦合的設計

系統對象除了與領域模型、用戶打交道以外﹐它還會與系統的其它模塊交互。如持久化系統、日志系統、信息通知系統(您不能因為用戶要求由郵件通知改為短信通知就修改領域模型吧)，當然還有UI，這些屬于系統核心(領域模型)以外的東西。

這些模塊不該參雜進業務邏輯中。應該在邊界與這些模塊進行接觸。

?

例子：

Public void 借閱()

{

借閱處理者 處理者 = new 借閱處理者(當前書籍﹐當前登錄人姓名);

??????? Bool successful = 處理者.借閱()??????????? //這個方法主要就是上面的那2行代碼

??????? If(successful){

持久化系統.add(當前書籍);

日志系統.add日志(當前當籍,”借閱”)

郵件系統.發送郵件(當前書籍.當前借書人姓名)

??????? }?

}

//這個例子的關鍵在于，你本可以在"借閱()"方法中先實現借閱的邏輯，然后順勢進行持久化、日志、郵件操作。可是這里卻多弄了個"處理者"對象來專門進行借閱操作，其目的就是為了將“借閱”邏輯獨立出來，與其他模塊耦合更松。

?

?

例子二：

Void 持久化系統.add(書籍 當前書籍)

{

借閱關系 Bbb = new 借閱關系

??????? Bbb.id = 產生ID()

??????? Bbb.圖書ID = 當前書籍.id;

??????? Bbb.借閱人 = 當前書籍.借閱記錄.借閱人姓名

??????? Bbb.借閱時間 = 當前書籍.借閱記錄.借閱時間

??????? Bbb.Save();

}??

在現實系統中﹐我在if(successful)這里作了一些純軟件設計﹐如利用C#具有Event特性﹐將借閱方法后公開出一個事件﹐這樣我在再要添加什么外圍模聲時﹐只要響應事件就可以了﹐不需要再來動這個方法 。

?

?

其它模塊處理過程類似。

業務過程是系統的核心，其他模塊都依賴于它而存在。

一個系統要變更業務邏輯﹐我們只要針對領域模型作變化即可﹐再也不需要抱怨變化了。

?

?

參考資料：

尚學堂UML系列視頻

<http://www.blogjava.net/lsshap/archive/2009/11/18/302755.html>

<http://www.diybl.com/course/3_program/gcs/2008324/106156.html>

<http://blogger.org.cn/blog/more.asp?name=nrzj&id=17433>

<http://blog.csdn.net/sfdev/archive/2009/02/18/3906243.aspx>

<http://www.kuqin.com/system-analysis/20080613/9441.html>

轉載于:https://www.cnblogs.com/colder/archive/2012/03/06/2381653.html

與50位技術專家面對面20年技術見證，附贈技術全景圖

總結

以上是生活随笔為你收集整理的UML小结以及基于领域模型的系统设计初步的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。