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

　　圖5：用來尋找分析類的問題

　　如果某一個答案是“不是”，那么這個候選詞很可能不是一個類。再繼續檢查下一個詞。如果答案是“是的”，那么繼續檢查下一個問題，如果所有的問題的答案都是肯定的，這個候選詞就是一個類。再繼續檢查下一個詞。

　　我們對每個候選詞做檢查，就會得到類似于表2的結果：

　　表2：名詞檢查結果

　　請注意租借地點已經被加進去了，雖然它不是用例的一部分。在與我們的業務專家(Subject Matter Experts，SMEs)們談話時我們發現，業務中會使用 地點來指代一個地址，或者一個租借部門。為了不致于混淆，我們一致統一使用單詞租借地點來表示業務地點，也就是發生租借和歸還的地方。

　　從這個列表中，我們列出了通過了問題檢查的詞，也就是下面列出的分析類：

　　啊哈!在總共得30多個候選中，現在我們只需要面對選出的8個分析類。前面的四個問題幫助我們縮小了搜索范圍，是個很有效的工具。

　　但是我們有沒有犯錯呢?有沒有漏過某個真正的類，或者把一個不該作為類的詞加進來了?這并不重要。RUP的迭代特性，會逐漸暴露出我們犯過的錯誤，并允許我們用盡量小的代價來修正它們。分析和設計的目標不是先把一切事情設計的很完美，而是當你需要確認這些事情的時候，才去確認這些。開始階段往往是最困難的，我們現在實現了對象(或者說類)從無到有的突破!重要的是我們已經起步了，而且我們能夠按照面向對象的方法一步一步的取得進展。

　　我們現在完成了RUP的用例分析活動中的前三步：

　　對每個用例

　　建立一個用例實現

　　補充用例描述(如果需要的話)

　　從用例行為中，找出分析類

　　如果我們嚴格按照RUP過程進行，下一步應該是：

　　把行為分配給分析類

　　基于以下理由，這一次，我又會對RUP過程做一點小的改動：回顧一下我們的進展。我們剛剛找到了8個實體類，我們認為這些都是我們系統中的類。在我們做下一步之前，我們需要給這8個實體類增加一些內容，來確認他們是類。

　　有三種基本的方法來充實我們的分析類：

　　數據驅動的方法

　　行為驅動的方法，和

　　職責驅動的方法。

　　數據驅動的方法對于從事數據庫工作，或者從事過程語言編程的人員來說很常見。他們就是用數據和數據之間的關系來認識、描述世界的，因此會首先去尋找類中的數據-一般沒有什么標準的方法去尋找類的函數或功能。這看起來不錯，但是數據只是工作的一半。實際上， 類的準確定義，包括了數據和對數據進行的操作。

　　行為驅動的方法有著雙重的成立理由。首先找出類執行的操作，從中決定這些操作涉及的數據中，哪些應該被這個類所擁有。這很棒，但是我們如何確認我們為類找出的操作之間能夠保持一致呢?如何區分操作和類，以明確這個操作是屬于這個類，但是 其它的操作要屬于同一個類，還是其它的類?我們需要某種方法來區分各個操作。這就是職責驅動的方法帶給我們的。

　　職責驅動的方法是自上而下的，從總體的類及其職責的視圖開始。首先定義一個類在業務中的“使命”，這個“使命”描述了這個類對外提供的服務。從軍事術語上來說，就是責任和策略。操作和數據是戰術層面上的(為戰略服務的，服從于某些目標、策略的)。 2

　　一旦我們確定了我們的類的職責，我們就可以設計一個分析類圖，來描述類間關系的整體結構。這個結構一般都是由業務領域決定的。一個UML分析類圖可以幫助我們可視化的把這個關系的結構表示出來。

　　因此，我建議對標準的RUP過程做如下修改(次序的改變)：粗體)：

　　對每個分析類

　　描述類的職責

　　在分析類圖上，建立分析類間的聯系

　　把行為指定給分析類(找出操作)

　　描述每個類的屬性和關系

　　定義類的屬性

　　描述分析類間事件的相關性

　　用例分析第四步：描述類的職責

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