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

　　例子：補充“預約汽車”用例

　　假設我們的系統是一個網站程序。當客戶需要的時候，我們會為他們提供私人在線預約汽車服務。我們要為這個實現的具體情況來細化我們的用例，不過不要過多的涉及到設計階段的工作。

　　這是預約汽車用例的更詳細的描述，還是側重于做什么，而不是側重于怎么做：

　　用例：預約汽車(補充)

　　這個用例從顧客進入我們的預約汽車網站開始。

　　系統提示顧客輸入希望的租借和歸還汽車的時間、地點，顧客輸入以上信息。 系統還提供給顧客一個選項，來選擇汽車的種類，如微型汽車、SUV、標準汽車，等等。顧客可以限定在一個或多個種類中搜索汽車。默認值是搜索所有種類的汽車。如果顧客參加了我們的有獎租賃汽車活動，他可以在網頁上一個單獨的地方輸入他的有獎活動的編號。如果他填寫了這個編號，系統會訪問顧客的檔案， 來預先獲取相關的信息。

　　如果顧客要繼續進行預約，系統在下一個網頁上，列出從數據庫中找到的所有符合條件(時間地點)的汽車，提供每輛汽車的基本費率，根據顧客的租用歷史情況還可以打一點折扣。如果顧客需要汽車的更詳細的信息，系統從數據庫中查找該信息，并將其顯示給顧客。

　　如果顧客選定了一輛要預約的汽車，系統在一個新的網頁中讓顧客填寫個人信息(姓名、電話、用于確認的電子郵件、信用卡發行商，等等)。如果系統中已經有該顧客的檔案，則調出系統中的相應信息顯示在頁面上。有些信息是必填項，另外一些則是選填項(如電子郵件)。用戶需要填寫所有的必填項。系統還提供各種保護產品的信息(如汽車損傷保險、乘客險等)和單日的價格，并詢問顧客是否購買，顧客做選擇。

　　如果顧客表示“接受這個預約”，系統在網頁上顯示這次預約的概要信息(汽車型號、日期、時間、選用的保護產品及其費用、費用總額等等)，讓顧客確認。如果顧客填寫了電子郵件，系統會發送一封確認信到顧客的電子郵件地址。

　　當確認信息出現在顧客面前時，這個用例就結束了。

　　在這個經過補充的用例描述中，我們清晰的描述了一個基于瀏覽器的程序的行為，描述了很多對顧客來說不可見的行為。但是并沒有提供設計級別的信息。

　　我們需要為每個用例提供類似的詳細信息嗎?

　　不需要。但是請記住，補充細節，并不是指實現的具體細節。我們的目標是為了能夠有足夠的信息來理解系統中的分析類，并與你的顧客或分析人員就所有用例的業務流程達成一致。 如果你覺得補充一些細節對于找出系統中的分析類有所幫助，那么就加上它。

　　注意：把握這個細節的尺度會比較困難。需要時間和一些練習。多上手練習，向別人多詢問，還要記住當你無法決定的時候，應該稍微偏向抽象一點的描述。增加一些沒有寫上去的內容比較容易做到，但是要從很多雜亂的描述中找到有用的信息可就難的多了。

　　為什么還要先寫出比較抽象的用例呢?為什么不直接把用例補充的比較詳細?

　　這是因為抽象的用例是系統行為的最通用的描述(不過多的描述系統內部行為)。如果你還要開發一套客戶端/服務器版本的預約汽車的用例會怎么樣呢?如果你從詳細的用例(基于瀏覽器的系統用例)，每次改變你的實現平臺的時候，你都得重寫整個用例。這個通用的描述與技術無關，特別是當你還沒有、或是無法確定系統的具體環境的時候，它的價值就得到了體現。另外，通用描述用例能夠讓你的業務分析人員能夠只看到系統如何工作的內容，而不是看到包含很多他們難以理解的技術細節的內容。

　　用例分析第三步：為用例行為找出分析類

　　根據RUP過程，這一步的目的是找出分析類的候選范圍，這些類合作起來，可以完成用例的所有行為。因為我們還沒有任何類，所以我們的主要目標就是找出在汽車租借系統中的所有分析類。

　　這就引出了一個有趣而又重要的問題：什么是分析類?有兩種答案。首先，一個業務級別的分析類是業務領域中的一個要素，與實現技術無關。例如，銀行系統中的銀行顧客、帳戶、帳號交易等等。而且它與系統的實現無關，不管是一個新的電子商務系統，或是一個從19世紀80年代就開始使用的借貸系統。

　　其次，RUP過程把這個定義擴展出三種不同的分析類：實體類、控制類和邊界類。RUP過程中的實體類大致上相當于前面提到的，業務級別的分析類?？刂祁惻c業務過程相關，它們控制整個業務的流程和執行次序。它通?？刂埔粋€用例中業務過程的執行。邊界類在系統與外界之間，為它們交換各種信息與事件。邊界類處理軟件系統的輸入與輸出。

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