UML

?

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

每一種圖，都相當(dāng)于一種角度。不同的圖就是從不同角度來觀察系統(tǒng)。

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

?

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

?

活動(dòng)圖

活動(dòng)圖表示的是一種流程。

例子：

順序圖

順序圖的目的是為對(duì)象分配職責(zé)，而不是步驟的羅列。

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

如下圖這樣就可以了：

用例和用例圖

用例的定義：文本形式的情節(jié)描述。

?

用例用于需求的發(fā)現(xiàn)和記錄，它會(huì)影響后續(xù)的OOA/D工作

?

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

?

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

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

編寫用例時(shí)，在基本路徑（即主成功路徑）中，只書寫主要的成功事件，而可能出現(xiàn)的其他情況（如找不到用戶）應(yīng)該寫在擴(kuò)展點(diǎn)中。

?

用例粒度：比如：是把管理用戶當(dāng)做用例還是把添加用戶和刪除用戶分別當(dāng)做兩個(gè)用例。

確定用例的粒度時(shí)，應(yīng)該考慮描述這個(gè)用例的基本路徑需要幾個(gè)步驟。十步以內(nèi)，七八步比較合適。

一個(gè)典型的用例描述

一個(gè)典型用例圖

其中銷售經(jīng)理和收銀員之關(guān)系是泛化關(guān)系，即經(jīng)理擁有收銀員所擁有的一切用例。另外還有其獨(dú)有的用例。

類圖

類圖允許我們標(biāo)記靜態(tài)內(nèi)容及類之間的關(guān)系，它是UML中最重要的圖形，可以在任何時(shí)候嘗試使用類圖。

不要使用類圖描述所有的細(xì)節(jié)，保持類圖的簡單。

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

邊界類位于系統(tǒng)與外界的交界處，例如窗體、報(bào)表、以及表示通訊協(xié)議的類、直接與外部設(shè)備交互的類、直接與外部系統(tǒng)交互的類等。通過用例圖可以確定需要的邊界類，每個(gè)Actor/Use Case對(duì)至少要一個(gè)邊界類，但并非每個(gè)Actor/Use Case對(duì)要唯一的邊界類。

實(shí)體類可以通過事件流和交互圖發(fā)現(xiàn)。通常每個(gè)實(shí)體類在數(shù)據(jù)庫中有相應(yīng)的表，實(shí)體類中的屬性對(duì)應(yīng)數(shù)據(jù)庫表中的字段。

控制類是控制其他類工作的類?？刂祁惪梢员欢鄠€(gè)用例共用。其他類并不向控制類發(fā)送很多消息，而是由控制類發(fā)出很多消息。

?

類圖中，要畫出類之間的關(guān)系

UML中繼承、實(shí)現(xiàn)、依賴、關(guān)聯(lián)、聚合、組合的聯(lián)系與區(qū)別

繼承?(也叫泛化)

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

實(shí)現(xiàn)

指的是一個(gè)class類實(shí)現(xiàn)interface接口（可以是多個(gè)）的功能；實(shí)現(xiàn)是類與接口之間最常見的關(guān)系；在Java中此類關(guān)系通過關(guān)鍵字 implements明確標(biāo)識(shí)，在設(shè)計(jì)時(shí)一般沒有爭議性；

依賴

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

關(guān)聯(lián)

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

聚合

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

組合

組合也是關(guān)聯(lián)關(guān)系的一種特例，他體現(xiàn)的是一種contains-a的關(guān)系，這種關(guān)系比聚合更強(qiáng)，也稱為強(qiáng)聚合；他同樣體現(xiàn)整體與部分間的關(guān)系，但此時(shí)整體與部分是不可分的，整體的生命周期結(jié)束也就意味著部分的生命周期結(jié)束；比如你和你的大腦；表現(xiàn)在代碼層面，和關(guān)聯(lián)關(guān)系是一致的，只能從語義級(jí)別來區(qū) 分；

總結(jié)：

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

例如在關(guān)心汽車的領(lǐng)域里，輪胎是一定要組合在汽車類中的，因?yàn)樗x開了汽車就沒有意義了。但是在賣輪胎的店鋪業(yè)務(wù)里，就算輪胎離開了汽車，它也是有意義的，這就可以用聚合了。

總的來說，后幾種關(guān)系所表現(xiàn)的強(qiáng)弱程度依次為：組合>聚合>關(guān)聯(lián)>依賴

示例一

關(guān)聯(lián)之特殊示例，下圖表示一種樹形結(jié)構(gòu)類圖，

可以用如下代碼實(shí)現(xiàn)

Public Class Node{

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

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

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

}

示例二：

已經(jīng)在關(guān)聯(lián)中表明了 Document 具有一個(gè)User類型的字段 Creator，故不必在Document中再寫出Creator了。

示例三：

由于User是另一個(gè)復(fù)雜的概念，所以要建立關(guān)聯(lián)，而不是把User也作為一個(gè)簡單的屬性（如name那樣）

不要把復(fù)雜的領(lǐng)域概念建模為屬性。

?

?示例四:

Student 與 class 之間是雙向關(guān)聯(lián)關(guān)系，當(dāng)然也可以說成是student依賴class，因?yàn)闆]有class，student是不能編譯通過的。但畫圖并不是所有存在的東西都要畫出來，這里表示成關(guān)聯(lián)關(guān)系更為貼切些。

另外，關(guān)聯(lián)指的是關(guān)心對(duì)方的結(jié)構(gòu)，如果對(duì)象A只是用一用對(duì)象B的某個(gè)方法，比如Collections.sort(), 這顯然是依賴而非關(guān)聯(lián)。

---

基于領(lǐng)域模型的系統(tǒng)設(shè)計(jì)初步

設(shè)計(jì)時(shí)重要原則:

??????? 低耦合,高內(nèi)聚.

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

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

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

系統(tǒng)的核心價(jià)值

領(lǐng)域模型的價(jià)值不在于它的設(shè)計(jì)優(yōu)美(它只是一些對(duì)象﹐最重要的也就是對(duì)象之間的關(guān)系)﹐而在于它體現(xiàn)了系統(tǒng)的核心價(jià)值。什么是系統(tǒng)的核心價(jià)值呢?我想我們的圖書館系統(tǒng)和華爾街的一個(gè)商業(yè)系統(tǒng)本質(zhì)的區(qū)別不在于系統(tǒng)用了什么語言、用了什么數(shù)據(jù)庫、用的是OO還是過程，而在于系統(tǒng)能為使用者提供什么服務(wù)，以及提供的質(zhì)量。這些通過系統(tǒng)的運(yùn)行方式﹐系統(tǒng)的運(yùn)行過程﹐系統(tǒng)的業(yè)務(wù)邏輯來體現(xiàn)。

用例的價(jià)值

系統(tǒng)分析員在接手一個(gè)系統(tǒng)后﹐首先要做到的事情就是得出系統(tǒng)的服務(wù)和服務(wù)場(chǎng)景。也就是我們經(jīng)常所講的用例(use case)

很多人不清楚清晰的用例的價(jià)值，只是因?yàn)榭磩e人有漂亮的圖形，所以自己也畫一個(gè)，其實(shí)自己都不去看它。這樣的用例分析只能糊弄一下老板，給別人show一下Demo﹐而不會(huì)對(duì)系統(tǒng)開發(fā)什么實(shí)質(zhì)作用。

用例表示的是使用系統(tǒng)的一個(gè)場(chǎng)景﹐其本質(zhì)在于詳細(xì)描述了系統(tǒng)用戶(actor)與系統(tǒng)是如何交互的﹐以及交互的后果是什么﹐詳細(xì)而完善的用例將指導(dǎo)您進(jìn)行系統(tǒng)開發(fā)的全過程

?

低耦合的設(shè)計(jì)

系統(tǒng)對(duì)象除了與領(lǐng)域模型、用戶打交道以外﹐它還會(huì)與系統(tǒng)的其它模塊交互。如持久化系統(tǒng)、日志系統(tǒng)、信息通知系統(tǒng)(您不能因?yàn)橛脩粢笥舌]件通知改為短信通知就修改領(lǐng)域模型吧)，當(dāng)然還有UI，這些屬于系統(tǒng)核心(領(lǐng)域模型)以外的東西。

這些模塊不該參雜進(jìn)業(yè)務(wù)邏輯中。應(yīng)該在邊界與這些模塊進(jìn)行接觸。

?

例子：

Public void 借閱()

{

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

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

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

持久化系統(tǒng).add(當(dāng)前書籍);

日志系統(tǒng).add日志(當(dāng)前當(dāng)籍,”借閱”)

郵件系統(tǒng).發(fā)送郵件(當(dāng)前書籍.當(dāng)前借書人姓名)

??????? }?

}

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

?

?

例子二：

Void 持久化系統(tǒng).add(書籍 當(dāng)前書籍)

{

借閱關(guān)系 Bbb = new 借閱關(guān)系

??????? Bbb.id = 產(chǎn)生ID()

??????? Bbb.圖書ID = 當(dāng)前書籍.id;

??????? Bbb.借閱人 = 當(dāng)前書籍.借閱記錄.借閱人姓名

??????? Bbb.借閱時(shí)間 = 當(dāng)前書籍.借閱記錄.借閱時(shí)間

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

}??

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

?

?

其它模塊處理過程類似。

業(yè)務(wù)過程是系統(tǒng)的核心，其他模塊都依賴于它而存在。

一個(gè)系統(tǒng)要變更業(yè)務(wù)邏輯﹐我們只要針對(duì)領(lǐng)域模型作變化即可﹐再也不需要抱怨變化了。

?

?

參考資料：

尚學(xué)堂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>

轉(zhuǎn)載于:https://www.cnblogs.com/colder/archive/2012/03/06/2381653.html

與50位技術(shù)專家面對(duì)面20年技術(shù)見證，附贈(zèng)技術(shù)全景圖

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。