從用例到代碼：用例分析(6)

　　在這里，我們要對每個分析類進行處理。類的職責描述了這個類在系統中所提供的服務，而且其它類不會重復提供這些服務。各個類的職責不能重疊。

　　根據我們對汽車租借領域的理解，和對汽車租借專家、業務分析專家一起工作，我們在表3中，寫出了我們對每個分析類的職責的理解。

　　表3：每個分析類的職責

　　James Rumbaugh與其它人 3 定義一個對象，或者說類，作為“一個概念，抽象，或者一個對業務來說有意義的，具有清晰定義的東西【我的重點】”。在類的職責定義中，首先要注意“清晰定義”，就是指明確指定了可以做什么，不可以做什么。

　　如果我們定義的職責出現錯誤怎么辦?我們再重復一次，這無關緊要。我們已經開始，并且在不斷取得進展。當我們對系統了解的更多之后，我們對類的職責作出些調整是很正常的。這樣才能幫助我們把建模工作和軟件做的更好的。

　　用例分析第五步：建立分析類之間的關系

　　我們已經確定了類的職責，下面將會設計一張UML類圖作為起點，來找出分析類之間的關系。 建立類圖有四個簡單的步驟：

　　確定要進行建模的類(我們已經完成了)。

　　確定哪些分析類具有與其它類之間的關系。

　　對于任意兩個之間具有關系的類，確定關系的語義 ：是關聯、聚合、合成還是繼承?

　　對于非繼承關系，確認關系的多樣性(指另一個類的多少個對象可以被關聯到這個類的一個對象上面，類似于數據建模中的概念。)

　　通過以上步驟，加上我們前面確定的類的職責，我們得到了UML類圖，如圖6：

　　圖6：汽車租借系統的類圖

　　這個類圖上有三種UML關系，用不同的線區分出來。簡單的實線表明是關聯關系。用來表明兩個類之間的點對點的關系，每個類都會調用另一個類提供的操作。

　　在線上用實心菱形表示，在預約和保護產品之間的是合成關系(或者說不可共享的聚合關系)。這是個整體/部分的關系，或者說是一種擁有的關系。在這張類圖上，合成關系表示預約擁有管理0個或者多個保護產品，這些保護產品被預約所擁有。更進一步來說，合成關系表明如果預約這個對象被銷毀了，他所擁有的保護產品也必須被銷毀，因為當保護產品不再是預約的一部分之后， 就失去了存在的意義。

　　在線上用空心菱形表示的，在汽車租用和汽車之間的是聚合關系(或者說，可共享的合成關系)。這也是個整體/部分的關系，或者說是一種擁有的關系，但是當我們銷毀汽車租用的時候， 我們并不銷毀汽車。這符合常理：因為汽車不出租時， 汽車對象會暫時成為“孤兒”，但是并不被銷毀，只是把它提供給另一個汽車租用。

　　在關系兩頭的數字和* 符號叫做多樣性描述。這些符號表明有多少個實例可以被連接到一個實例上。例如可以和一個顧客有關聯關系的汽車的數量?；蛘?，反過來，可以和一輛汽車有關聯關系的顧客的數量。在這個類圖里面，我們的多樣性表明“對每位顧客，可以沒有汽車預定，也可以有多項汽車預定”。反過來，就是“對每輛汽車，可以沒有顧客預定，也可以有多個顧客預定”。

　　在分析中，我們試圖確認，我們能夠正確的表述和理解問題。對業務專家和分析專家來說，分析類圖是一個有用的工具，幫助他們和技術人員一起審查設計，并且將設計進一步推進。

　　現在我們有了類，職責和一張顯示類間關系的結構的類圖。但是迄今為止，我們還沒有涉及類的內部-沒有操作和屬性。而且類圖是靜態的。我們如何確認這些類能夠完成我們在用例中描述的業務過程?這就是下一步的目的，這是一個非常重要的步驟，因為它將會把用例描述映射到分析類的潛在的操作上面。

　　用例分析第六步：確認分析類的行為

　　這些類如何協作完成預定一輛汽車這個用例?我們用UML交互圖來找出分析類之間的這些交互動作?；貞浺幌虑懊嫣岬降捻樞驁D和協作圖，就是兩種交互圖，它們是我們的用例實現的一部分，如圖7所示，這是一張分析級別的順序圖，描述了預定一輛汽車這個用例。

原文轉自：http://www.uml.org.cn/Test/200904165.asp