面向對象的Java與UML課件系統(tǒng)分析域模型順序圖實體對象、邊界對象與控制對象用戶接口定義協(xié)同圖使用域對象、協(xié)同圖、活動圖和狀態(tài)圖進行用例細化分析系統(tǒng)行為的時候了，將需求說明細化為計算機專有的行為說明書系統(tǒng)分析的輸入和輸出：盡管系統(tǒng)分析人可能參考前面所提供的任何一種文檔，但是用例描述和原型還是主要的輸入。系統(tǒng)分析的核心將被順序圖的構建所驅動。而順序圖也轉而來生成合作圖和類圖。順序圖所使用的劇本是根據用例描述中的主要/替代/異常路線所推導出來的域對象模型模擬的世界之間，需要有緊密的對應關系。利用現(xiàn)實世界中事物相應的對象來構建系統(tǒng)，它的優(yōu)勢在于可能會更容易理解系統(tǒng)。比如訂貨系統(tǒng)中有訂單、顧客和貨物要構建一個可維護的系統(tǒng)，額外的對象是必要的一些UML符號構造型《》三種不同類型的對象構造型實體對象：為持續(xù)存在的對象建模邊界對象：控制與外界交互的控制對象：將復雜行為組織起來，這些行為涉及了大量的實體對象和邊界對象數(shù)據要存儲在數(shù)據庫中，數(shù)據庫設計人員將這一階段成為實體建模把活動者提供的信息翻譯成控制對象和實體對象相應的事件用于在許多對象之間調解，持續(xù)時間不比用例長，一般情況下不用數(shù)據庫表示這些對象順序圖用例圖為分析提供了系統(tǒng)功能極為清晰的定義。現(xiàn)在，需要把這些功能翻譯成計算機系統(tǒng)中的對象組與可能實現(xiàn)的交互。在分析中，順序圖是這樣一種方法。它研究需求分析階段中搜集到的用例，將用例定義中的順序和在用例中相互作用的對象串在一起。我們要做的是使用順序圖，要么連接到已知對象上，要么創(chuàng)造對象來支持這個用例。使用用例劇本表示貫穿這個系統(tǒng)的旅程。要遵循的過程要遵循的過程是從用例中識別一系列代表性的劇本，并用順序圖將其細化。劇本集應包括用例中所有的替代路線和異常路線這些順序圖可以用來確定協(xié)同圖，隨后，協(xié)同圖也轉而用于生成類圖電話訂貨用例為例電話訂貨用例為例以電話訂貨用例為例1售貨員得到顧客號，并將其輸入顯示屏。2查詢顧客的詳細信息．并顯示在屏幕上。3售貨員核實顧客詳細信息與顧客給出的信息一致，并勾選確認框。4售貨員輸人訂單的詳細信息。5售貨員輸人發(fā)貨詳細信息。6售貨員請求生成訂單。以訂貨用例為例以訂貨用例為例用例行為序列與對象之間的鏈接，找到域對象的最好方法順序圖的指導方針1為該用例標識有代表性的劇本集，包括所有的替代路線和異常路線2為每個劇本生成如下的順序圖3把活動者放在左邊4標識邊界對象（可能多于一個），如顯示屏。5為劇本的每個步驟畫出活動者與邊界對象之間的交互。6對于與邊界對象的每次交互，確定是否要和另一個對象交互7如果交互是與一個單獨的實體對象進行的，則創(chuàng)建實體對象并直接為其請求服務8如果交互是與許多實體對象進行的，則考慮創(chuàng)建中間控制對象來監(jiān)控通信順序圖繪制草圖順序圖是進行用例細化

最有效的方式之一讓做出用例定義的業(yè)務分析人員和熟悉對象建模的人，甚至可能是設計人員來接觸業(yè)務。使用粘在一起的的筆記，而不是計算機化的工具來生成順序圖。結果看起來有點像上頁圖?；顒禹樞驅懺谧筮?，候選對象寫在上邊，用叉號表示交互。這種方式很不正規(guī)，但允許極快速地重新整理。計算機化工具的問題在于，它們有時候看上去過于正規(guī)了。一旦順序圖得到認可，就可以整潔地畫出來。協(xié)同圖協(xié)同圖是另一種使對象相互關聯(lián)的方式，是順序圖的補充，面向對象的系統(tǒng)通過對象協(xié)作來提供其行為，單獨的對象只能提供部分行為。當對象協(xié)作時，它們能提供復雜而功能強大的行為。為此，對象交換信息與請求，這些請求的路線就可以用協(xié)同圖來描述。事實上，這些路線已經在順序圖中定義過了，但是，用另一種不同的方式把它們描述出來也是有用的。這樣做的好處在于通信線路看上去更清楚直觀。協(xié)同圖可以翻譯成類圖，我們隨后可以看到。以訂貨用例為例類圖與協(xié)同圖的關系協(xié)同圖表現(xiàn)了系統(tǒng)的一次特定執(zhí)行中類的關，類圖表示的所有潛在執(zhí)行中類的關系協(xié)同圖可以記錄對象間交換的信息，但類圖不能類圖記錄了在對象及其屬性上進行的操作，但協(xié)同圖不能合作圖與類圖的關系綜合了大量表示各種各樣用例執(zhí)行的協(xié)同圖后，便形成了具有已定義關系的類圖結構?？紤]協(xié)同圖中對象間的通信，就能開始標識支持關系的對象所需要的操作；研究通信中交換的信息，會發(fā)現(xiàn)對象需要記錄的屬性；設計會帶我們沿著這條路走下去，并檢查類的結構。本階段構造類圖的主要目的可以在這里開始為對象指定操作但是，我們有很多理由不建議這樣做。在順序圖中捕獲了交互細節(jié)，對于這是否足夠使得設計人員理解系統(tǒng)，仍然存在爭議其次，設計人員有可能要對類圖進行重構，并對順序圖進行相應的細化。構架上的考慮將會給類的結構帶來相當大的影響。例如，將要決定一些操作是應當在控制類中，還是在實休類中實現(xiàn)。這些決定最好留給負責設計和實現(xiàn)的開發(fā)人員在這一階段中，要從類圖中捕獲的首要信息是需要以屬性的形式保存下來的數(shù)據。用戶接口使?jié)撛谟脩魠⑴c并闡明問題的最有效方法之一是提供原型界面。下圖是我們詳細討論的訂單輸入屏幕的一個原型屏幕。開始構造這種原型時，許多事情顯露了出來。需要收集的數(shù)據成為了用戶接口的一個討論點：我們可能用它來返回到顧客對象，并把地址屬性細化到該對象的組件中。我們也看到有某一產品的概念，這一概念會提醒我們考慮是否在什么地方需要一個產品對象。顧客知道產品代碼，如果不知道，能否期望系統(tǒng)為訂單輸入提供產品號碼列表？顧客希望獲得訂單價格的反饋嗎？接口的組織用戶接口圖也同樣是有用的：顯示屏是邊界對象，所以，類圖可以用來表現(xiàn)屏幕組織。下圖展示了一個簡單的屏幕組織。沒有顯示屬性和操作，類中顯示屬性和操作的框也省略了，關聯(lián)顯示為單向的，用來表示屏幕之間的導航路線。從一個屏墓指向另一個屏幕的箭頭表示前者可以調用后者。狀態(tài)圖狀態(tài)圖需要引入兩點：狀態(tài)間的轉換可以使用更多的語法Event-name(parameters)[guard-condition]/actionEvent-name觸發(fā)從前一狀態(tài)退出的事件名稱guard-condition激發(fā)轉換必須為真的條件Parameters提供給事件的用逗號分隔的值序列Action當激發(fā)轉換時必須發(fā)生的一些特定活動帶事件、保安條件和活動的顧客帳戶狀態(tài)圖可以存在嵌套狀態(tài)存貨可能高于或者低于建議的庫存水平子狀態(tài)開始時，通常始于一個起始點由于活動圖是狀態(tài)圖的變體，上述符號都適用于兩者“棕地”分析上文描述了“綠地”開發(fā)中的系統(tǒng)分析，也就意味著系統(tǒng)是新的，并且，在實現(xiàn)方面很少有約束。實際上這很少見，即使是所謂的綠地開發(fā)，最初的開發(fā)發(fā)生了，就可以認為是“棕地”了。通常，系統(tǒng)需要有數(shù)據庫，數(shù)據庫模式實際上是削減了的對象模型：數(shù)據表主要存儲現(xiàn)實世界實體的信息，實際上是實體類的實現(xiàn)。因此，系統(tǒng)分析的進行可以通過使用順序圖來把現(xiàn)有的數(shù)據庫表聯(lián)系在一起，用新的邊界對象和控制對象來實現(xiàn)一個用例。ICANDO化學制品訂貨“驗證用戶”實例實現(xiàn)驗證用戶用例的實現(xiàn)需要更細致地理解用例。在有關對象的一章中，我們將標識名詞作為一種確定對象的方法：現(xiàn)在，我們應當用一種更為結構化的方法來實現(xiàn)對象識別，走完貫穿用例的不同路線，并且構適出順序圖。應當使用實體、邊界和控制對象的符號，來賦予對象模型某些結構。驗證用戶用例的實現(xiàn)主要路線的第一步顧客提供顧客號，職員將其輸人屏幕，這給出了順序圖的起始點．如圖所示。這表明有一個職員（一個活動者）使用歡迎窗口（Welcomesceen)一個邊界對象）輸入數(shù)據。主要路線的第一步在這里不大可能涉及到其他任何對象，直到職員提交（submit）為止。提交可能通過輸入顧客號之后點擊返回，或是通過按按鈕來實現(xiàn)。無論是哪一種方式，我們都可以擴展順序圖來合并提交，從而得到如圖所示的順序圖。主要路線的第二步系統(tǒng)響應，返回顧客姓名和地址，以及該顧客的唯一密碼。這暗示著需要某個對象來存儲姓名、地址和密碼，明智的做法是將這些信息組合到一個叫做顧客的單獨對象中由于顧客對象是需要持續(xù)存在的．并與現(xiàn)實世界的實體，即顧客是嚴格對應的，因此，它是一個實體對象。由此，我們能夠畫出圖控制對象的引入這一順序圖是合適的。但是，當我們來到主要路線的第三個步驟時，出現(xiàn)了一個問題：就是如果給出的回答與屏幕上查詢出的一致，職員就點擊單選框?，F(xiàn)在，在操作員進行這個用例處理的時候，經過驗證的顧客的情況需要被記住。雖然顧客對象，可能會用來保存這一信息，但是，感覺上有點不對。屏幕也可能保存信息，但隨著查詢的進行，會生成新的屏幕并毀掉確認屏幕?；剡^頭來著，確實有個在任何用例中都推薦考慮的構造，也就是該用例的控制對象。如果向控制對象發(fā)送所有請求，則控制對象，可以接受確認。可以根據呼叫持續(xù)時間來保持控制對象處于可用狀態(tài)。最后，我們構造出如圖所示的順序圖。主要路線的第三步主要路線的第三步我們現(xiàn)在有了非常細化的順序圖．也已經為系統(tǒng)的操作設計了合理的結構。并且有了一個新的對象類（驗證控制對象，如上圖所示），它需要存儲至少一條信息作為屬性，來確定顧客是否已被認證?？墒牵匀挥泻芏鄦栴}需要回答，比如顧客對象如何定位，但是，其中的很多問題都可以留給設計人員來解答。協(xié)同圖替代路線3.1研究完主要路線后，我們需要研究替代路線。以第三條替代路線為例，當顧客無法提供密碼／姓名和地址。系統(tǒng)必須記錄這次嘗試，這暗指某種呼叫日志。需要存儲的是一個實體對象，這一對象由用例生成，如圖所示。附加對象的設計附加對象的設計附加對象很可能需要存儲客戶號、時間、日期和一些記載發(fā)生了什么的記錄。由于不管是否采取行動，呼叫中心通常都要記錄每次呼叫。因此，該對象可能出現(xiàn)在眾多場合。類圖分析現(xiàn)在，我們有了類圖的基礎——協(xié)同圖。盡管表示出控制與邊界對象是合理的。但是，由于這些對象會傾向于擁有靜態(tài)的行為。因此，通常大部分實體對象都用類圖來表示。ICANDO零售汽油促銷案例ICANDO零售汽油促銷零

售

汽

油

促

銷

用例ICANDO零售汽油促銷“加入訂單”用例的實現(xiàn)主要路線1．顧客點擊目錄頁面，選擇物品旁邊的定購鍵2．系統(tǒng)確認該產品有庫存3．系統(tǒng)從顧客賬戶中扣除點數(shù)4．系統(tǒng)彈出