根據我在面向對象技術和面向對象建模方面的教學經驗,我發現開發人員總是很快的從RUP過程中的實體類、控制類和邊界類這個環節,進入下一個設計環節, 沒有對問題進行足夠的分析。實際上,顯然控制類和邊界類都是面向技術實現的類,而不是面向業務的類。它們都是在設計階段所定義的系統設計模型中的一部分,而不是分析模型。因此,在這一步,我將會側重于業務方面的,與技術無關的分析類。在討論設計的時候再討論涉及技術的部分。請一直記住,搜索與業務相關的類,是在RUP過程中的結構分析部分進行的,如果你的項目采用了RUP過程的話。
讓我們回顧一下,用例描述的是行為,也就是系統為用戶提供了什么樣的服務。在用例描述中,沒有涉及面向對象的內容,但是這些描述是用來找出系統中的對象和類的??梢栽诤芏嗟胤?,用各種各樣的方法來尋找類:
領域的常識只是
前一個類似的系統
企業模型或供參照的體系結構
CRC (類/職責/合作關系)方法
詞匯表
數據挖掘
尋找類的一個簡單的方法就是語法分析,下面我將加以說明。我們只要找出我們的需求中的名詞, 這些名詞(有些是形容詞+名詞):
一些是類。
一些會成為類的屬性。
一些對我們的系統無關緊要。
找出預約汽車的用例描述中的這些名詞(跳過代名詞,如“他”),如下:
用例:為顧客預約汽車(補充)
這個用例從顧客進入我們的網頁開始。
這個系統顯示輸入框,來提示顧客輸入借出和歸還時的預約的地點,和借出和歸還時的日期和時間。顧客輸入地點和日期。系統還提供選擇框,讓顧客來限定汽車的型號分類 ,例如,如微型汽車、SUV、標準汽車,等等。顧客可以指定一個汽車分類進行搜索,也可以指定多個分類。默認的設置是在所有的 汽車 分類中搜索。如果顧客參加了我們的租賃有獎活動,他需要把他的有獎活動中的編號輸入到網頁上的一個獨立的輸入框中。如果這個輸入框 填寫了內容,系統會訪問顧客的個人檔案,系統會提前查找所需的 信息。
如果顧客表示希望繼續進行預約過程,系統訪問汽車數據庫,來 查找位置信息然后在一個新的網頁中顯示所有的汽車信息。這些汽車都是在指定的汽車分類 中的,并且在指定的地點、日期和時間中是空閑的。對每輛汽車,系統都會顯示一個基礎費率,如果顧客租用汽車的歷史比較長,還可以打一些折扣。如果顧客想要看到某輛汽車的更詳細的信息,系統從汽車數據庫中讀取這些信息,并把他們顯示給顧客。
如果顧客選定了汽車來預約,系統顯示一個新的網頁,提示顧客輸入用于確認顧客身份的個人信息,(姓名, 電話, 用來確認的電子郵件, 信用卡發行商 )。 如果顧客檔案已經存在了,系統從中讀取所有已經填寫過的信息。一部分輸入信息是必填項,其它(如電子郵件)是選填項。顧客填寫所有必填的信息。 系統還要顯示保護產品相關的信息(如汽車損傷保險、乘客險等)和單日的價格,并詢問顧客是否購買這些保護產品。顧客給出決定。
如果顧客表示接受這個預約,系統給出一個網頁,來顯示 預約的摘要信息,(汽車的類型、 日期和時間、所有選購了的保護產品及其費用、租用總額),還為顧客顯示預約的確認頁面。如果 系統有用戶的電子郵件 ,系統會發一封預約確認信到這個地址。
這個用例當預約確認信息出現在顧客面前的時候,就結束了
注意每個名詞,或者形容詞+名詞的組合, 都被標出來了。有很多重復的,因此把每個詞單獨列入詞匯表1,按字母順序排序:
表1:候選的名字/實體類
我們如何分辨出哪些候選的名詞才是真正的問題領域中的類呢?一個常用的方法就是,用一些簡單的問題來測試每個詞,如圖5:
|
![]() |
原文轉自:http://www.uml.org.cn/Test/200904165.asp