UML综合实例
ATM（自動取款機）現在在城市的大街小巷隨處可見。我們在日常生活中也經常和ATM打交道。本章我們將以簡化的ATM系統為例將前面幾章中學到的用例圖、類圖、順序圖、狀態圖、活動圖及協作圖知識運用到此例中。
1 用例圖
參與者"銀行儲戶"和ATM機。簡化后的ATM機僅有取款、存款及其余功能。其余功能不做詳細說明。
?銀行儲戶在ATM機上完成取款、存款及其他業務。
?
2 類圖
圖2所示的銀行系統類圖和圖5是類似的，只是將工作人員換成了ATM。整個銀行系統包括了帳戶庫、銀行儲戶庫及ATM系統。
許多單個的帳戶組成了帳戶庫。帳戶具有帳戶類型、帳戶號、余額三個屬性，均為private，其類型分別為char，int，double。六個操作分別為setType、getType、getAccountNumbe、setAccountNumbe、caculateBalance、getBalance，除caculateBalance為protected其余均為public。
setType設置帳戶類型，返回類型為void，參數類型為char，輸入帳戶類型。
getType獲取帳戶類型，返回類型為char，無參數。
setAccountNumbe設置帳戶號，返回類型為void，參數類型為int，輸入帳戶號。
getAccountNumbe獲取帳戶號，返回類型為int，無參數。
caculateBalance計算余額，返回類型為void，參數為double，第一個參數為輸入存取款數額，第二個參數為存款余額，既為輸入也為輸出。
getBalance獲取帳戶余額，返回類型為double，無參數。
許多銀行儲戶組成了儲戶庫。ATM系統包含了許多ATM機。銀行儲戶及ATM機兩個類包含哪些屬性，哪些操作，它們的可見性及操作的返回類型、參數個數、參數類型從類圖上都一目了然。更多的屬性及操作都可以一一加上，使這個類圖更詳細更完整，從而使參與項目的每個成員都能無歧義的明了整個設計的類的結構。同樣對于一個真正的銀行系統，這個類圖過于簡單。比如帳戶類型我們可以先定義一個abstract class，它包含一個帳戶最基本的屬性及操作。而有些操作先定義為abstract，如余額的計算。然后再繼承這個abstract class，我們可以有saving account 和checking account等等。不同的帳戶有不同的余額計算方法，我們可以加上具體的算法。對于不同的帳戶可能還有一些它特有的操作，我們也可以加上，比如saving account在存款達到多少時可以享受機票打折的優惠。通過類圖不僅可以使設計者明確的表達自己的設計意圖，也能幫組自己整理思路，充實及優化自己的設計。
?
圖2 銀行系統類圖
?
3 順序圖
圖5.3描述了顧客在ATM機上取款時信息的流動情況。以時間為順序。因為僅是示例，所以整個過程是沒有出現任何故障時的流程，并且只畫到了取款結束。通過這個圖，我們可以看出消息是如何在系統中不同對象之間進行交互。
通過流程圖我們可以很清楚地看到系統是如何工作的，系統各部分之間的信息及控制是如何發送的，整個流程是否合理。流程圖對我們的設計起到了很好的幫助作用。注意在本圖沒有一個生命線終端有一個"X"，這是因為這個流程中還未遇到有對象生命結束。當有對象生命結束時需在對應的生命線終端畫"X"，表明這個對象在這時被銷毀。
首先銀行儲戶將ATM卡插入讀卡機，讀卡機將信息傳給客戶管理，客戶管理提出查詢密碼，顯示部分將輸入密碼請求顯示出來…..因為這個順序圖較長，且很清晰，即便是初學者也很容易讀懂，在此就不對本圖做過多的解釋。
?
?圖3 ATM取款順序圖
?
4 狀態圖
圖4描述了顧客在ATM機上進行操作會經歷的幾種狀態，及各種狀態之間轉換的條件。因為是簡化了的例子，所以除了等待顧客插入磁卡的起始狀態和結束服務的終止狀態，顧客會處于輸入密碼、選擇服務類型、存款及取款四種狀態。
圖4 ATM狀態圖
?
插入磁卡后進入輸密碼狀態，當密碼輸入正確時進入選擇服務類型狀態，當輸入密碼不正確時，停留在原狀態，但如果三次不正確，服務結束。進入選擇服務類型后根據選擇的不同，顧客可進入存款和取款狀態。存、取款結束后，顧客既可以選擇結束服務到最終狀態，也可以選擇繼續服務回到選擇服務類型狀態。
通過狀態圖我們可以無歧義的了解各個活動角色是如何在不同狀況下轉換的，轉換的條件是什么，是否會出現死鎖現象，是否有條件沒考慮周全，是否有狀態無法達到。狀態圖可以幫助我們發現問題，并及時改正。
5 活動圖
圖5參考了Randy Miller的《A Hands-On Introduction for Developers》一文，3圖中的客戶管理和事物管理對應于5圖中的Bank，圖3中的讀卡機、顯示、輸入設備及點鈔機對應于5圖中的ATM Machina，銀行儲戶就是Customer。初看活動圖和順序圖表達的意義很接近。但我們可以注意到順序圖著重時間的順序，而活動圖側重于各部分之間的相互制約，對于一些并行的活動能夠有效的表示出來。例如5圖中fork和join處，我們可以很清楚的看到一些并行活動的存在。
這個活動圖以顧客插入卡為開始，以顧客取卡結束。我們可以看到活動圖的重點雖然不在時間順序，但我們同樣可以得到時間的信息。
??????
?
圖5 ATM銀行系統活動圖
?
6 協作圖
在第四章中我們知道協作圖和順序圖是可以無信息損失的相互轉換，只是它們的側重點是不一樣的。順序圖著重于對象間消息傳遞的時間順序，協作圖著重于表達對象之間的靜態連接關系。圖6將3圖轉換為協作圖。
1．插入ATM卡
2．接受ATM卡
3．查詢密碼
4．顯示輸入密碼請求
5．輸入密碼
6．密碼傳遞
7．請求確認密碼合法性
8．確認密碼合法性
9．詢問服務類別
10．顯示輸入服務服務類別請求
11．輸入取款請求
12．取款請求
13．詢問取款數額
14．顯示輸入數額請求
15．輸入取款數額
16．傳遞取款數額
17．詢問取款數額確認
18．顯示確認數額請求
19．輸入確認
20．傳遞確認信息
21．數額合法性確認請求
22．確認數額和法性
23．出鈔請求
24．計算帳戶余額
25．出鈔
26．取鈔
27．傳遞余額并詢問是否還需要其他服務
28．顯示帳戶余額并提示選擇下面的服務
?
?
圖6 ATM系統協作圖
從圖上我們可以看出協作圖的角色和順序圖的對象是一一對應的，而協作圖上的各對象上的協作關系和順序圖上的消息傳遞是一一對應的。
總結
- 上一篇： 应用jBPM4解决中国特色的流程需求 (
- 下一篇： Linux上的WebSphere MQ开