上傳人：7***

認(rèn)證信息

認(rèn)證類型：個人認(rèn)證

認(rèn)證主體：王**（實名認(rèn)證）

IP屬地：湖北

IP屬地：湖北 上傳時間：2022-02-16 格式：PPT 頁數(shù)：76 大?。?70KB 積分：28 舉報 版權(quán)申訴

1、1第第8章章 面向?qū)ο蠓治雒嫦驅(qū)ο蠓治?領(lǐng)域分析 使用實例的需求獲取 用類進行建模 對象-行為模型 RUP分析活動 OO分析小結(jié)28.1 領(lǐng)域分析領(lǐng)域分析 1、領(lǐng)域分析的概念、領(lǐng)域分析的概念 面向?qū)ο蟮南到y(tǒng)分析可以發(fā)生在許多不同的抽象層次。在業(yè)務(wù)或企業(yè)級層次，可定義模擬整個業(yè)務(wù)的類、對象、關(guān)系和行為。在業(yè)務(wù)域?qū)哟?，可定義描述某特殊的業(yè)務(wù)域的工作的對象模型和行為模型；在應(yīng)用層次，建模著重于特定的用戶需求。 Firesmith對軟件領(lǐng)域分析的定義是：領(lǐng)域分析(Domain Analysis)指特定應(yīng)用領(lǐng)域中公共需求的標(biāo)識、分析和規(guī)約，即發(fā)現(xiàn)或創(chuàng)建那些可廣泛應(yīng)用的類，其目的目的使它們在應(yīng)用域中多個項

2、目間能被復(fù)用在應(yīng)用域中多個項目間能被復(fù)用。領(lǐng)域分析的角色是設(shè)計和建造可復(fù)用構(gòu)件（類似于制造環(huán)境中工具制造者的角色），它們被很多相似但不一定是相同的應(yīng)用開發(fā)的人所使用。 3 Lethbridge的定義是：領(lǐng)域分析是軟件工程師了了解背景信息的過程解背景信息的過程。為了理解問題并在需求分析和軟件工程過程的其他階段作出合理的決策，軟件工程師必須了解使用該類軟件的一般性商業(yè)和技術(shù)領(lǐng)域中足夠的信息。2、領(lǐng)域分析過程的活動、領(lǐng)域分析過程的活動 （1）定義將被調(diào)查的領(lǐng)域 分離感興趣的業(yè)務(wù)域、系統(tǒng)類型或產(chǎn)品范疇，抽取OO和非OO的“項”。OO項包括：現(xiàn)存OO應(yīng)用的類的規(guī)約、設(shè)計和代碼，支持類（如GUI類或數(shù)據(jù)庫

3、訪問類），和領(lǐng)域相關(guān)的構(gòu)件庫以及測試案例。非OO項包括：政策、規(guī)程、計劃、標(biāo)準(zhǔn)，非OO應(yīng)用文檔和構(gòu)件。4 （2）對從領(lǐng)域中抽取出來的項進行分類并建立分類層次。 （3）收集領(lǐng)域中應(yīng)用的代表性樣本。 （4）分析樣本中的每個應(yīng)用 標(biāo)識候選的每個可復(fù)用對象。 指明對象被標(biāo)識為可復(fù)用的理由。 定義對象的適應(yīng)性。 估算在領(lǐng)域中復(fù)用這些對象的應(yīng)用的百分率。 使用配置管理技術(shù)控制這些對象。 （5）為對象開發(fā)分析模型。5 3、領(lǐng)域分析的價值、領(lǐng)域分析的價值 領(lǐng)域分析除了為軟件復(fù)用奠定基礎(chǔ)外，還為較低抽象層次的一般的面向?qū)ο蠓治鰩砣缦潞锰帲?快速開發(fā)。有助于集中精力關(guān)注最重要的問題，更有效地與相關(guān)人員進行交流，

4、可以更快的確定需求。 優(yōu)化系統(tǒng)。了解領(lǐng)域的細(xì)節(jié)有助于保證所采納的解決方案更有效地解決用戶的問題。會少犯錯誤，知道應(yīng)該遵循那些規(guī)程和標(biāo)準(zhǔn)。領(lǐng)域分析給出一個應(yīng)用領(lǐng)域的總體視圖，會引導(dǎo)出更好的抽象從而改進設(shè)計。 有了領(lǐng)域知識，就可以洞察新興趨勢及進一步開發(fā)的機會，有助于創(chuàng)建適應(yīng)性更強的系統(tǒng)。 了解通用性和特殊性，有助于創(chuàng)建出具有更好的可重用性和更寬的銷售市場的軟件。 6 專家提出，沒有堅實的領(lǐng)域分析，任何重大的軟件項目都不應(yīng)該進行。對應(yīng)用領(lǐng)域的深入理解能極大的提高成功的幾率。許多非常成功的軟件產(chǎn)品的開發(fā)人員以前都在業(yè)務(wù)領(lǐng)域工作過段時間，對實際需要有著深切的感受。 一旦對領(lǐng)域有了真正的理解，就可進行某

5、一個項目（或產(chǎn)品）的需求分析，包括定義待解決的問題以及開發(fā)什么軟件來解決它。然而，領(lǐng)域分析永遠(yuǎn)也不應(yīng)該結(jié)束：開發(fā)人員有責(zé)任在開發(fā)過程中不斷增進他們的理解，后續(xù)版本的系統(tǒng)擴充通常需要對子領(lǐng)域進行進一步的領(lǐng)域分析。78.2 使用實例的需求獲取使用實例的需求獲取 面向?qū)ο蟮姆治鲞^程并不從考慮對象開始，而是從對系統(tǒng)將被使用的方式的理解開始。如果系統(tǒng)是人機交互的，則考慮被人使用的方式；如果系統(tǒng)是涉及過程控制的，則考慮被機器使用的方式；如果系統(tǒng)是協(xié)調(diào)和控制應(yīng)用的，則考慮被其他系統(tǒng)使用的方式。一旦使用的場景(scenario) 被定義，軟件的建?；顒泳烷_始了。 1、use-case（用例或使用實例）（用例或

6、使用實例） 在OOA中，用例是分析模型的第一個元素的基礎(chǔ)，以終端用戶的觀點對系統(tǒng)建模。 用例在需求獲取時創(chuàng)建，應(yīng)達(dá)到下列目標(biāo)目標(biāo)： 通過定義由終端用戶和開發(fā)人員共同認(rèn)可的使用場景，定義系統(tǒng)的功能和運行需求。 場景是用例的一個實例，表達(dá)用例的一個特定發(fā)生，在特定的時間，使用特定的數(shù)據(jù)進行操作 。8 提供清楚的、無二義性的終端用戶和系統(tǒng)如何相互交 互的描述。 提供確認(rèn)測試的基礎(chǔ)。 用例的描述以及用例圖構(gòu)成了參與者與系統(tǒng)交互的用 例模型（1）用例的描述 建議：其中只有名稱和步驟是必須的。 名稱(name) 參與者(actor) 目標(biāo)(goal) ： 參與者要完成的任務(wù)。 前置條件(precondit

7、ion)： 列出參與者啟動用例前所有必需為真的條件。 相關(guān)用例(related use cases)： 列出可能是此用例的擴展、包含的用例。9 步驟(step)： 用兩列的格式描述用例的每一步（見例）。 后置條件(postcondition)： 用例完成后系統(tǒng)所處的狀態(tài)。 例1：描述應(yīng)用程序中打開文件的用例 用例用例：打開文件 步驟步驟： 參與者動作 系統(tǒng)響應(yīng) 選擇“打開”命令 顯示“打開文件”對話框 指定文件名 確認(rèn)選擇 關(guān)閉對話框10 例例2、圖書管理系統(tǒng)借書、圖書管理系統(tǒng)借書 用例用例 用例用例：為借閱者借出一本書 參與者參與者：借書員 目標(biāo)目標(biāo)：幫助借閱者借閱書籍并確保輸出正確的借出記

8、錄 前置條件前置條件：借閱者必須有一張有效的借書卡并且沒有欠費； 該書藉必須具有有效的條形碼并且不是來自于 參考文獻(xiàn)區(qū)。 步驟步驟： 參與者動作 系統(tǒng)響應(yīng) 掃描書籍和借書卡 顯示允許借閱的信息 在書籍上標(biāo)記到期日期 確認(rèn)借出開始 顯示借出已被記錄的確 認(rèn)的信息 后置條件后置條件：系統(tǒng)有一個該書藉被借出以及到期時間的記錄 11例3、某商店P(guān)OS系統(tǒng)用例描述實例用例： 購買商品參與者：顧客（發(fā)起者）、收款員類型： 主要的描述： 顧客帶著所要購買商品到付款處，收款 員記錄商品信息并收款。用例： 啟動/關(guān)閉系統(tǒng)參與者：管理員類型： 主要的描述： 管理員接通一臺POS機電源，檢查時 間、日期正確性，檢查

9、完成后，系統(tǒng)處 于就緒 狀態(tài)，以備收款員使用。12（2）用例圖 用來顯示一系列用例和參與者之間的關(guān)系，有助于開發(fā)人員表達(dá)系統(tǒng)功能的不同的抽象層次的描述。房主房主傳感器傳感器SafeHome高層用例圖13啟動啟動/ /關(guān)閉系統(tǒng)關(guān)閉系統(tǒng)房主房主輸入密碼輸入密碼詢問區(qū)域狀態(tài)詢問區(qū)域狀態(tài)SafeHome交互用例圖詢問傳感器狀態(tài)詢問傳感器狀態(tài) 按緊急按鈕按緊急按鈕驗證密碼驗證密碼詢問傳感器詢問傳感器includeincludeinclude(參考教材1 P415)14 用例分析是理解和組織系統(tǒng)應(yīng)完成任務(wù)的直觀方法。它還可以用來驅(qū)動開發(fā)過程驅(qū)動開發(fā)過程。特別是，用例： 可以幫助定義系統(tǒng)的范圍，即必須做什么

10、和不必做什么。 可用來計劃開發(fā)過程。確定的用例數(shù)量決定了項目的大 小，開發(fā)進度可用完成的用例數(shù)量來測量。 用來開發(fā)和確認(rèn)需求。 構(gòu)成測試用例定義的基礎(chǔ)。 可用來構(gòu)造用戶手冊。 但是用例也不是萬能的！注意：（Lethbridge的觀點） 用例必須經(jīng)確認(rèn)。用例集應(yīng)是完全的、表達(dá)是一致的和 明確的。 用例分析不一定覆蓋到功能需求的所有方面。如，不被 參與者觸發(fā)的活動不會出現(xiàn)在用例中。 當(dāng)軟件需求來自用例時，軟件往往只是簡單的反映開發(fā) 軟件前用戶的工作方式，可能沒有考慮到創(chuàng)新的解決方 案。152、獲取需求的主要活動、獲取需求的主要活動 （1）確定參與者和用例 與用戶一起確定與系統(tǒng)有交互活動的所有角色，

11、并為每個角色設(shè)計用例。確定用例的準(zhǔn)則： 每個用例都應(yīng)該為其角色提供有價值的服務(wù)避免確定的用例太小；確保每個用例都向主要角色提供有價值的服務(wù)避免用例太大。 （2）定義用例的優(yōu)先級 （3）描述每個用例 用例描述可有不同的抽象層次與描述模板。概要描述主要強調(diào)每個用例的主要功能。詳細(xì)描述包括每個用例的事件流（如何開始，與角色如何交互，如何終止）、每個用例中所涉及到的對象（編入術(shù)語表）、執(zhí)行一個用例所要求的非功能性需求等。16（4）建立用例圖 用例圖用來顯示一系列用例和參與者之間的關(guān)系。它有助于表達(dá)系統(tǒng)功能的高層表述。 用例有特化、擴展和包含關(guān)系。特化的使用同類圖。一個特化用例代表了幾個相似用例，一個或

12、多個特化提供了這些相似用例的細(xì)節(jié)。 使用包含關(guān)系減少用例之間的冗余。即 確定用例中可以被共享的功能。檢查每個用例抽取出公共部分創(chuàng)建單獨用例。 使用擴展關(guān)系區(qū)分事件的例外和事件的共有流程，即確定補充功能或可選功能。如果發(fā)現(xiàn)一個用例比較復(fù)雜，既包含了一般處理又包含了特殊處理，將特殊處理的部分抽取出來，創(chuàng)建單獨的用例。17打開文件用戶通過鍵入文件名打開文件通過瀏覽打開文件試圖打開不存在的文件瀏覽文件extendinclude用例的特化、擴展和包含18 （5）建立用戶界面原型 在面向?qū)ο蟮能浖_發(fā)中，用例模型和用戶界面設(shè)計息息相關(guān)。用例模型創(chuàng)建后，就可確定參與者如何驅(qū)動用例，以及用例以什么形式向參與者

13、提供信息。因此可開始用戶界面原型化的迭代過程，和構(gòu)造系統(tǒng)的其他部分并行進行。198.3 用類進行建模用類進行建模 面向?qū)ο蠓治?，就是抽取和整理用戶需求并建立問題域精確模型的過程。在需求獲取階段已經(jīng)建立了用例模型等階段產(chǎn)品，但都是為了容易溝通信息，以用戶語言描述的，存在著模糊、冗余、二義性、不一致性等問題。 系統(tǒng)分析階段要進一步分析、完善前一階段獲取的需求，細(xì)化用例模型中的用例、確定系統(tǒng)中的對象、對象的靜態(tài)和動態(tài)特征、對象間的關(guān)系及對象的行為約束，建立滿足用戶需求的、精確的、穩(wěn)定的、易于維護的、便于后續(xù)設(shè)計的分析模型。 20用例圖：視圖功能模型：模型分析模型：模型類圖：視圖對象模型：模型順序圖：

14、視圖狀態(tài)圖：視圖活動圖：視圖動態(tài)模型：模型分析模型的構(gòu)成分析模型的構(gòu)成21 幾條通用的分析原則： （1）組裝與分解相結(jié)合的原則 基本對象可組裝成復(fù)雜對象，對復(fù)雜對象進行分解從而完成系統(tǒng)模型的細(xì)化。 （2）抽象化與具體化相結(jié)合的原則 數(shù)據(jù)抽象將數(shù)據(jù)及作用在其上的操作抽象成對象。過程抽象為對象的相互作用提供了依據(jù)。 抽象強調(diào)對象的本質(zhì)和內(nèi)在屬性，忽視與問題無關(guān)的屬性。而具體化指在細(xì)化過程中，描述對象的某些特性，加強系統(tǒng)模型的穩(wěn)定性。 抽象化與具體化相結(jié)合可以使具體對象直接從抽象對象的定義中獲得已有特性，而不必重復(fù)定義它們。 22 （3）封裝原則 將對象的各種獨立的外部特性與內(nèi)部實現(xiàn)細(xì)節(jié)分開。對象接

15、口定義要盡可能的與其內(nèi)部工作狀態(tài)相分離。封裝有助于減少由于需求的改變而對整個系統(tǒng)所造成的影響。 （4）相關(guān)性原則 在分析中要考慮對象間的各種關(guān)聯(lián)，包括靜態(tài)結(jié)構(gòu)的關(guān)聯(lián)、動態(tài)特征的關(guān)聯(lián)。這些關(guān)聯(lián)是對象協(xié)作的基礎(chǔ)。 （5）行為約束的原則 通過語義特征來刻畫。表示了對象合法存在、對象合法操作應(yīng)滿足的條件，有助于深刻理解對象和系統(tǒng)。 23 一旦建立了系統(tǒng)的用例模型，則可以開始標(biāo)識候選類，并指明它們的責(zé)任和協(xié)作。Wirfs-Brock等人提出了一種類類-責(zé)任責(zé)任-協(xié)作者協(xié)作者(Class-responsibility-collaborator,CRC)開發(fā)類圖的卡片技術(shù)。該技術(shù)使用實際的或虛擬的索引卡片（

16、參考教材P417)，為定義類提供較多的信息。其中責(zé)任是與該類相關(guān)的屬性和操作，協(xié)作者是為一個類提供要完成的責(zé)任所需要的信息的那些類。通常，協(xié)作意味著對信息的請求或者對某種操作的請求。 在確定屬性和操作時，可把它們列在卡片上。由于卡片的空間有限，使得每一個類都不能太復(fù)雜。如果不能在一張卡片上列出所有的職責(zé)，該類應(yīng)分成兩個相關(guān)的類?？稍诎装迳献杂梢苿涌ㄆ越M成類圖，在卡片之間畫線表示關(guān)聯(lián)與泛化。低科技的卡片技術(shù)可能比操作軟件用戶界面要快，對開發(fā)人員通過會議討論確定方案很有效。 24 1、標(biāo)識類及對象、標(biāo)識類及對象 無論是面向?qū)ο蠓治鲞€是面向?qū)ο笤O(shè)計與實現(xiàn)，建立類圖都是核心技術(shù)。類圖是定義其他圖的基

17、礎(chǔ)，在該基礎(chǔ)上用交互圖、狀態(tài)圖等進一步描述系統(tǒng)其他方面的特性。 如何識別對象？對象以一系列不同形式展示自身：外部實體、事物、發(fā)生的事件、角色、組織單位、位置或結(jié)構(gòu)。一種最簡單的方法是從系統(tǒng)處理說明中找出名詞。例如，在SafeHome的需求陳述中，找出相關(guān)的名詞是：用戶、傳感器 、 控制面板、系統(tǒng)(安全系統(tǒng))、 傳感器編號、 傳感器類型、密碼、 電話號碼、 傳感器事件、 警報器 等。 這些候選的對象是否都可作為在系統(tǒng)中承擔(dān)責(zé)任的有用對象？要根據(jù)一定原則篩選。見下表：25幾條篩選特征: 例:SafeHome中潛在的對象及篩選理由 (1)保留的信息 潛在對象 選取理由 篩選理由 (2)需要的服務(wù) 用

18、戶 角色或外部實體 不符合1/2 (3)多個屬性 傳感器 外部實體 符合1-6 (4)公共屬性 控制面板 外部實體 符合1-6 (5)公共操作 系統(tǒng)(安全系統(tǒng)) 事物或聚集對象 符合1-6 (6)基本的需求 傳感器編號 事物或概念實體 不符合3 傳感器類型 事物或概念實體 不符合3 密碼 事物或概念實體 不符合3 電話號碼 事物或概念實體 不符合3 傳感器事件 事件 符合1-6 警報器 外部實體 符合1-6 幾乎滿足所有特征的對象才會被考慮為分析模型中的合法對象.26 在RUP中，將對象分為三種類型： (1) 邊界對象(或邊界類) 是參與者與系統(tǒng)交互的接口，這些對象位于系統(tǒng)與外部世界的邊界上，

19、代表如界面窗口、通信接口、打印機接口、傳感器等的抽象，用于闡明和收集系統(tǒng)的邊界需求，這樣，可把用戶界面或通信接口的變化隔離在一個或多個邊界類中。在分析問題域時，邊界類仍保持較高的概念層次，說明通過交互所實現(xiàn)的目標(biāo)就可以了。在設(shè)計活動中（如用戶界面設(shè)計）才根據(jù)參與者操作需求，添加具體的邊界對象。 (2) 控制對象(或控制類) 控制用例的流程，表示協(xié)調(diào)、順序、事務(wù)處理以及對其他對象的控制（如分派任務(wù)給其他對象）。主要用來體現(xiàn)應(yīng)用程序的執(zhí)行邏輯，可以使得變化不影響用戶界面和數(shù)據(jù)庫中的表。27 (3) 實體對象(或?qū)嶓w類) 負(fù)責(zé)保存長效且持久的信息。實體類大多數(shù)是直接從業(yè)務(wù)模型或 領(lǐng)域模型中相應(yīng)實體類

20、得到的。實體類一般表示為一種邏輯數(shù)據(jù)結(jié)構(gòu)（通常映射為數(shù)據(jù)表格或文件），有助于開發(fā)人員理解系統(tǒng)所依賴的信息。實體對象不一定都是被動的，有時可能具有與它所表示的信息有關(guān)的復(fù)雜行為。實體對象能夠?qū)⒆兓c它們所表示的信息隔離開。 在RUP的分析中，三類對象分別用下圖表示：邊界對象控制對象實體對象28 2、定義屬性、定義屬性 類的屬性與操作和該類在系統(tǒng)中承擔(dān)的責(zé)任有關(guān)。屬性表示了類的特性，即類必須保持的以完成軟件目標(biāo)的信息。屬性的取值決定了對象可能的狀態(tài)。 傳感器有類型、編號、位置、顏色、重量、工作狀態(tài)（關(guān)閉、待機、監(jiān)控）、采樣頻率、報警閾值等特性，哪些與系統(tǒng)責(zé)任有關(guān)呢？ 定義屬性的一些經(jīng)驗： 一般常識

21、； 分析問題域，檢查與對象相聯(lián)系的形容詞或名詞短語； 責(zé)任； 保存管理信息； 有些屬性在對象模型穩(wěn)定之前可暫不考慮。 293、定義操作、定義操作 操作反映對象的行為并以某種方式修改對象的屬性。對象行為可理解為對象應(yīng)展現(xiàn)的外部服務(wù)的總和。對象的行為分為三類： 對象生命周期中的創(chuàng)建、維護、刪除行為。 計算行為 監(jiān)控行為 通過這些行為體現(xiàn)對象的責(zé)任。對象以兩種方式完成它們的責(zé)任： 使用它自己的操作去操作自己的屬性， 對象和其他對象協(xié)作。 因此對象的操作可以有以下幾種類型幾種類型： 實現(xiàn)功能的操作：可追溯到用戶需求。30 管理對象創(chuàng)建和刪除的操作。在分析階段，這些操作可 暫緩定義。 訪問屬性的操作。一

22、個類的屬性通常是私有的或受保護 的，只有通過該類提供的操作來訪問。 輔助一個類完成其任務(wù)的操作，即協(xié)作操作。 如何定義操作呢？ 分析問題域：有哪些行為，找有關(guān)動詞。 如“傳感器被賦予一個編號和類型”。 系統(tǒng)的責(zé)任：找與責(zé)任有關(guān)的對象，這些對象為承擔(dān)責(zé)任 應(yīng)提供哪些服務(wù)。 分析類的狀態(tài)轉(zhuǎn)換，引起類狀態(tài)轉(zhuǎn)換的動作。 追蹤一個用例的執(zhí)行路線，如順序圖，通過對象間通信發(fā) 現(xiàn)操作。 因此類的有些操作是在對象-行為模型建立后才補充進來。下圖是傳感器類的較為詳細(xì)的定義及它的STD： 31傳感器類類型；編號；位置；工作狀態(tài)；采樣頻率；警報閾值；初始化；關(guān)閉；監(jiān)視；待機；顯示；振鈴；撥號；關(guān)閉狀態(tài)待機狀態(tài)監(jiān)視狀

23、態(tài)初始化命令關(guān)閉命令監(jiān)視命令待機命令關(guān)閉命令超越閾值/激活顯示、振鈴、撥號傳感器類的STD32 4、定義結(jié)構(gòu)與層次、定義結(jié)構(gòu)與層次 類圖中的類并非孤立存在，類之間有很多關(guān)系。應(yīng)該關(guān)注類模型的結(jié)構(gòu)以及類和子類出現(xiàn)時產(chǎn)生的類層次。 尋找關(guān)系的具體方法如下： 檢查交互圖，如果一個類向另一個類有請求，則它們之間通常有關(guān)聯(lián)關(guān)系。 檢查類的聚合關(guān)系。 檢查類的泛化關(guān)系，尋找相似對象的不同點，抽取不同的部分定義為特殊類（自頂向下），或?qū)⒐残缘牟糠痔嵘秊榛悾ㄗ缘紫蛏希?檢查其他類，發(fā)現(xiàn)不同類中的共同點，將共同的部分定義一個新類。其他類和新類之間的關(guān)系也是泛化關(guān)系。 但關(guān)系太多的類往往對其他類有更多的要求，

24、較難復(fù)用且維護的工作量也很大，一旦其他類發(fā)生變化，則對該類產(chǎn)生影響。33 （ 1）關(guān)聯(lián)關(guān)系 是類之間的連接關(guān)系，可以是雙向的也可以是單向的。兩個關(guān)聯(lián)之間可以相互發(fā)送消息。 訂單類的屬性放入客戶類中，可以找到客戶的訂單；而客戶類的屬性放入訂單類中，可以找到訂單的客戶。 在一對多或多對多的關(guān)聯(lián)中，從重數(shù)為1的對象中找到它所對應(yīng)的類的對象通常是比較困難的。解決的辦法是在關(guān)聯(lián)中加入限定，它可以唯一地識別重數(shù)為“多”端的對象，以便快速定位到要查找的對象。訂單客戶* 屬于 1擁有訂單訂單號客戶 屬于 34systemsensoralarmsensor event1 檢測 *1 0.*識別1*激活SafeH

25、ome中幾個對象類的關(guān)聯(lián)（參考教材1P423)35 （2）聚合關(guān)系 表示類之間整體與部分的關(guān)系。 標(biāo)識類的聚合的優(yōu)越性： 清晰的表達(dá)語義并用重數(shù)約束之間的關(guān)系。 簡化對象的定義。 支持復(fù)用。如“發(fā)動機類”可以是一個可復(fù)用構(gòu)件，用于其他系統(tǒng)定義中。 飛機內(nèi)嵌發(fā)動機和導(dǎo)航儀的屬性內(nèi)嵌發(fā)動機和導(dǎo)航儀的操作飛機發(fā)動機導(dǎo)航儀36身份人員會計師身份經(jīng)理身份穩(wěn)定部分可變部分 在強聚合關(guān)系中，部分依賴于整體，如果整體不存在了，部分會隨之消失。實現(xiàn)時一同刪除。聚合關(guān)系使得類具有了層次結(jié)構(gòu)。 能表示動態(tài)變化的對象特征。不需要經(jīng)常變化的屬性與操作放在整體類，需要動態(tài)變化的特征放在部分類。37（3）泛化關(guān)系 是一般與

26、特殊關(guān)系。將具有共同特性的元素抽象成一般類，通過增加其內(nèi)涵生成特殊類。 通常，符合下屬條件之一類的泛化才有存在的價值： 便于實現(xiàn)軟件重用。 一般類有兩個或兩個以上的特殊類。（消除冗余） 需要用它們創(chuàng)建對象實例。 但要避免過渡泛化，否則會增加系統(tǒng)的復(fù)雜性。 泛化關(guān)系使得類具有了層次結(jié)構(gòu)。下圖是SafeHome的部分類圖。 38systemcontrol panelsensoralarmentry sensorsmoke sensormotion sensorSafeHome的部分類圖39（4）包 復(fù)雜系統(tǒng)的分析模型可能有數(shù)十個結(jié)構(gòu)、上百個類，難以理解與實現(xiàn)。當(dāng)所有類的某個子集相互協(xié)作以完成一組內(nèi)

27、聚的責(zé)任（功能）時，劃分為子系統(tǒng)（UML稱為包）。 包確定了整個系統(tǒng)抽象粒度更大的結(jié)構(gòu)。包圖可產(chǎn)生于類圖之后（將類圖組合成包），或?qū)⒂美墓δ芊峙山o包，再細(xì)化包以產(chǎn)生類圖。 如參考教材1P421中將“控制面板類”的整個聚合結(jié)構(gòu)劃分成“控制面板包”。下圖是某一教學(xué)管理系統(tǒng)的包圖及包圖的細(xì)化：40MFC類類用戶接口用戶接口出錯處理出錯處理教學(xué)管理教學(xué)管理數(shù)據(jù)庫數(shù)據(jù)庫教學(xué)管理系統(tǒng)的包圖教學(xué)管理系統(tǒng)的包圖41subsystem課程注冊子系統(tǒng)課程注冊子系統(tǒng)系統(tǒng)與子系統(tǒng)包圖系統(tǒng)與子系統(tǒng)包圖subsystem成績管理子系統(tǒng)成績管理子系統(tǒng) system 教學(xué)管理系統(tǒng)教學(xué)管理系統(tǒng)42選課管理選課管理成績管理成績

28、管理人事信息人事信息教學(xué)管理教學(xué)管理課程課程學(xué)生登記學(xué)生登記課程登記課程登記開設(shè)課程開設(shè)課程選課統(tǒng)計選課統(tǒng)計學(xué)生成績登記學(xué)生成績登記成績統(tǒng)計成績統(tǒng)計學(xué)生學(xué)生教師教師身份驗證身份驗證438.4 對象對象-行為模型行為模型 用例中的每個用例都是通過若干對象相互合作實現(xiàn)的。對象-行為模型指明一個系統(tǒng)對外部事件的激勵所作出的響應(yīng)。為創(chuàng)建該模型，應(yīng)該完成以下工作： 評估所有use-case以完全理解系統(tǒng)中的交互順序。 標(biāo)識驅(qū)動交互序列的事件并理解這些事件如何和特定的對象相關(guān)聯(lián)。 為每個use-case創(chuàng)建交互圖。 為具有主要動態(tài)特征的類建立狀態(tài)轉(zhuǎn)換圖。 為描述對象的工作流同時便于識別并發(fā)活動建立相應(yīng)的活

29、動圖。 評價對象-行為模型以驗證精確性和一致性。 44 1、通過use-case識別事件，為對象的交互行為建模 事件是某個時刻發(fā)生的事，包括所有來自或發(fā)往用戶的信息、外部設(shè)備的信號、輸入、策略、中斷、轉(zhuǎn)換和動作。當(dāng)系統(tǒng)與參與者（人、設(shè)備或外部系統(tǒng))交換信息時則一個事件發(fā)生。為了方便分析對象對外部事件的響應(yīng)，有必要建立交互圖（協(xié)作圖、順序圖），用于顯示一個用例實現(xiàn)中涉及到的對象和這些對象間的消息傳遞情況。 （1）順序圖 下面通過SafeHome的用例說明，識別出事件，找出與該事件相關(guān)的對象，并將用例的責(zé)任分派給它們，通過它們的交互，體現(xiàn)了系統(tǒng)完成一個用例的整體行為。 45 檢查SafeHome的

30、use-case，帶下劃線的部分指明了事件。（參考教材1P424) 房主觀察控制面板以確定是否系統(tǒng)以準(zhǔn)備好接收輸入。如果系統(tǒng)未準(zhǔn)備好，房主必須物理地關(guān)閉門/窗戶，以便使“準(zhǔn)備好”指示燈亮。 房主使用鍵盤輸入4位密碼，系統(tǒng)將密碼與存儲在配置庫中的有效密碼比較，如果密碼不正確，控制面板鳴叫一次并復(fù)位等待再次輸入。如果密碼正確，控制面板等待進一步的動作。 房主選擇鍵入“stay”（僅激活外部的傳感器）或“away”（激活所有的傳感器）以啟動系統(tǒng)。 當(dāng)處于激活狀態(tài)時，房主可觀察到一個紅色指示燈。46 一旦所有事件被標(biāo)識，將它門分配給所涉及的對象。對象可以生成事件（如房主生成密碼輸入事件）或識別發(fā)生在其

31、他地方的事件（如控制面板識別密碼比較事件的二進制結(jié)果）。 下圖是SafeHome的部分順序圖： 房主 控制面板 系統(tǒng)輸入密碼密碼比較密碼正確/不正確不正確啟動蜂鳴器蜂鳴器聲響等待下一個動作47房主 控制面板 系統(tǒng)選擇stay/away激活傳感器傳感器被激活請求指示燈亮紅燈亮等待下一個動作 Rumbaugh等人在OMT方法中提出，建立反映系統(tǒng)交互行為的動態(tài)模型時，需描述正常交互的腳本和例外的腳本。腳本也稱為場景，是用例的一個實例。通過腳本中的步驟確定事件，比較方便的建立順序圖、協(xié)作圖等視圖。48 如ATM系統(tǒng)示意圖：分行計算機分理處計算機分理處計算機帳戶帳戶ATMATM自動出納機與用戶交互的正常

32、腳本：（1）ATM請求用戶插入卡：用戶插入現(xiàn)金卡。（2）ATM接受卡片并讀出它的卡號。（3）ATM要求密碼：用戶輸入密碼401230。（4）ATM請求分行確認(rèn)卡號和密碼：由分理處檢驗并 通知ATM。（5）ATM要求用戶選擇事務(wù)類型：用戶選擇取款。49 （6）ATM要求輸入現(xiàn)金數(shù)量：用戶輸入$200。 （7）ATM請求分行處理事務(wù)，分行把請求傳給分理處， 確認(rèn)事務(wù)成功。 （8）ATM分發(fā)現(xiàn)金并要求用戶取現(xiàn)金：用戶取現(xiàn)金。 （9）ATM提示用戶是否要繼續(xù)：用戶鍵入不繼續(xù)。 （10）ATM打印收據(jù)，退出卡，并提示用戶取走它們： 用戶取走收據(jù)和卡。 （11）ATM請求用戶插入卡。（回到初始狀態(tài)） 還可

33、列出用戶與自動取款機交互的例外的腳本。 通過腳本，比較容易確定用例（如取款用例）中的事件（交互信息）、以及事件的發(fā)送者和接收者（完成該用例所涉及到的對象）。50 （2）協(xié)作圖 用于快速瀏覽對象間的相互合作。強調(diào)對象間的通信，不像順序圖那樣強調(diào)傳遞消息間的時序性，它用數(shù)字順序標(biāo)號表示消息的順序。 （3）活動圖 用來描述對象或構(gòu)件執(zhí)行的工作流。突出的優(yōu)點：用來表示并發(fā)活動及活動的執(zhí)行者。 在分析階段，活動圖用來描述滿足用例要求所要進行的活動及之間的約束關(guān)系。（有些專家認(rèn)為用活動圖建立用戶業(yè)務(wù)模型比對象模型更易理解）。 在設(shè)計階段，活動圖可以反映對象內(nèi)部的工作流程，可由狀態(tài)圖演化過去，是狀態(tài)圖的一個

34、實例。 51 2、為單個對象類的重要行為建模 Pressman提出，在OO系統(tǒng)的語境內(nèi)，必須考慮兩種不同的狀態(tài)特征： （1）當(dāng)系統(tǒng)完成其功能時每個對象的狀態(tài)； （2）當(dāng)系統(tǒng)完成其功能時從外界觀察到的系統(tǒng)狀態(tài)，即系統(tǒng)的整體行為。 類的狀態(tài)圖反映了該類中每個對象內(nèi)部的工作，在它的生命周期內(nèi)遇到某個事件或動作使它從一種狀態(tài)轉(zhuǎn)換到另一種狀態(tài)。通過狀態(tài)圖關(guān)注對象類應(yīng)負(fù)有的責(zé)任，防止遺漏一些功能，幫助標(biāo)識對象類的操作，因此需要對有重要行為的對象類建立狀態(tài)圖。 狀態(tài)圖還能為對象設(shè)計中建立每個操作體的內(nèi)部邏輯提供幫助。 52 例如，SafeHome系統(tǒng)中的傳感器類是比較重要的類，觀察它的狀態(tài)特征(詳見3.4例

35、2）對了解整個系統(tǒng)的動態(tài)行為很有幫助。 ATM系統(tǒng)中，自動取款機的行為特征比較重要。下圖是自動取款機類在正常取款行為下的狀態(tài)轉(zhuǎn)換圖。53 開始do:請求插入卡 檢查do:要求密碼 核對do:確認(rèn)帳戶 選擇do:要求類型 輸數(shù)據(jù)do:要求數(shù)量 事務(wù)do:處理事務(wù) 發(fā)現(xiàn)金do:分發(fā)現(xiàn)金 繼續(xù)否do:詢問繼續(xù)否 結(jié)束do:打印收據(jù) 退卡do:請求取卡插入卡輸入密碼密碼錯帳戶正確輸入類型輸入數(shù)量事務(wù)成功取現(xiàn)金繼續(xù)終止打印指令發(fā)出取走卡ATM類的部分類的部分STD54范例：移動電話系統(tǒng)范例：移動電話系統(tǒng) 功能：功能： 用手機做移動通訊用手機做移動通訊 下載鈴聲下載鈴聲 下載圖片下載圖片 管理電話簿。管理

36、電話簿。55Talk to OthersTalk to OthersDownload PictureDownload PictureManage PhonebookManage PhonebookDownload RingsDownload RingsMobile userMobile userMobile NetworkMobile Network56定義移動電話系統(tǒng)的對象（簡化）定義移動電話系統(tǒng)的對象（簡化） 手機包括的對象：手機包括的對象： 手機屏幕手機屏幕 手機按鈕手機按鈕 手機（屏幕、按鈕以外的部件）手機（屏幕、按鈕以外的部件） 其它對象：其它對象： 基站基站MButtonMDisp

37、lqyMmobileStationMmobileHandset移動電話系統(tǒng)的類圖移動電話系統(tǒng)的類圖57 移動電話系統(tǒng)對象間的通信移動電話系統(tǒng)對象間的通信 :MButton:MDisplqy:MMobileStation :MMobileHandsetMobile user1:pushDigButton()3:pushSendButton()2:displayButtonNumber()4:connectStation()6:connectSuccess ()5:createConnection()移動電話系統(tǒng)移動電話系統(tǒng)的協(xié)作圖的協(xié)作圖7:displayConnectSuccess()58 移

38、動電話系統(tǒng)的順序圖移動電話系統(tǒng)的順序圖 :MButton:MDisplqyMobile userpushSendButton()displayButtonNumber()displayConnectSuccess()connectSuccess ()createConnection()pushDigButton()connectStation():MMobileStation :MMobileHandset59MButtonMDisplqyMmobileStationMmobileHandsetpushDigButton()pushSendButton()pushDisconnectButto

39、n()createConnection()cancelConnection ()responseError()displayError()displayButtonNumber()displayConnectSuccess()displayIncomingCall()connectStation()disconnectStation()connectSuccess ()Disconnectsuccess()移動電話系統(tǒng)的類圖之二移動電話系統(tǒng)的類圖之二（接口）（接口）608.5 RUP的分析活動的分析活動 在統(tǒng)一過程中，用工作流來描述過程。工作人員執(zhí)行工作流中的一組活動而產(chǎn)生相應(yīng)的工作產(chǎn)品。 有

40、7種過程工作流，它們是業(yè)務(wù)建模、需求、分析、設(shè)計、實現(xiàn)、測試和實施。其中需求、分析、設(shè)計、實現(xiàn)和測試是核心工作流。 需求工作流：列舉出候選需求，捕獲功能性需求， 捕獲非功能性需求。 分析工作流：構(gòu)架分析，分析用例，分析類，分析包。 設(shè)計工作流：構(gòu)架設(shè)計，設(shè)計一個用例，設(shè)計一個類， 設(shè)計一個子系統(tǒng)。 實現(xiàn)工作流：構(gòu)架實現(xiàn)，系統(tǒng)集成，實現(xiàn)一個子系統(tǒng)， 實現(xiàn)一個類，執(zhí)行單元測試。 測試工作流：制定測試計劃，設(shè)計測試，實現(xiàn)測試， 執(zhí)行集成測試，執(zhí)行系統(tǒng)測試，評估測試。 實施工作流：可交付系統(tǒng)的配置。 61 分析工作流的任務(wù)是通過精化和組織需求捕獲階段所描述的需求來對其進行分析，工作結(jié)果是分析模型。下表

41、列出了用例模型和分析模型的簡單比較： 用例模型 分析模型 使用用戶的語言進行描述； 使用開發(fā)人員的語言進行描述； 系統(tǒng)的外部視圖； 系統(tǒng)的內(nèi)部試圖； 通過用例來構(gòu)造，提供外部 通過類、包來構(gòu)造，提供內(nèi)部視圖 視圖的結(jié)構(gòu)； 的結(jié)構(gòu) ； 主要用于用戶和開發(fā)人員簽 主要為開發(fā)人員使用，以理解如何 署合同時明確系統(tǒng)應(yīng)該做什么； 設(shè)計和實現(xiàn)系統(tǒng)； 需求中可能存在冗余和不一致； 不應(yīng)該存在冗余和不一致等問題； 捕獲系統(tǒng)的功能； 概述如何實現(xiàn)系統(tǒng)的功能； 定義在分析階段中進一步進行 定義用例實現(xiàn)，每個實現(xiàn)代表對 分析的用例 ； 用例模型中一個用例的分析；621、分析活動、分析活動 （1）構(gòu)架分析）構(gòu)架分析

42、確定系統(tǒng)的總體框架結(jié)構(gòu)。 以業(yè)務(wù)模型和用例模型為基礎(chǔ)，確定分析包。 一個大的系統(tǒng)包含有許多功能，通過分析業(yè)務(wù)模型、用例模型，將系統(tǒng)功能組織成大小適中的包。劃分包的原則是將與一個業(yè)務(wù)過程相關(guān)的所有用例及其有擴展關(guān)系、包含關(guān)系的用例都放在一個包中。 好處： 便于實現(xiàn)和管理； 將變化局限在一個包內(nèi)，減少由于需求變化對整個系統(tǒng)結(jié)構(gòu)的影響。 劃分了分析包后，檢查每個包是否有公共特性 ，提取出組成公共的分析包，便于其他包使用。要定義分析包之間的依賴關(guān)系。63 檢查每個分析包，如果包中含有一些可共享的、較低層的、可選擇的功能，將它們組織成獨立的服務(wù)包，便于為不同的系統(tǒng)復(fù)用與選擇。 重要的實體類對理解系統(tǒng)結(jié)構(gòu)

43、很有幫助，對它們進行概要說明，包括屬性、操作及與其他實體類的關(guān)聯(lián)。 定義系統(tǒng)級的公共特殊需求：系統(tǒng)的可靠性、安全性、可用性、可維護性、容錯、分布等非功能性需求。 （2 2）確定用例實現(xiàn)）確定用例實現(xiàn) 在需求獲取階段是從系統(tǒng)外部來看系統(tǒng)的功能。功能功能放在用例中描述，功能實現(xiàn)的過程功能實現(xiàn)的過程用活動圖描述，用例中各個對象之間、與外部參與者之間發(fā)生的交互關(guān)系交互關(guān)系用協(xié)作圖、順序圖來反映，一個對象一個對象跨越多個用例的完整的行為完整的行為描述用狀態(tài)圖來反映。但僅有這些還不能滿足系統(tǒng)設(shè)計與實現(xiàn)的需要，因此，要細(xì)化每個用例。具體步驟如下： 64 分析用例模型的每個用例，確定用例實現(xiàn)的分析類和事件流。

44、分析類代表了類的抽象。將參與用例實現(xiàn)的分析類收集到類圖中。分析模型中使用了分析類的3種構(gòu)造型（邊界類、控制類、實體類）。確定分析類注意以下幾點： 為以人充當(dāng)?shù)慕巧⒁粋€主要邊界類（通常實現(xiàn)為一個主窗口）。 為每個外部系統(tǒng)充當(dāng)?shù)慕巧x一個主要邊界類，使其代表通信接口。 確定一個控制類負(fù)責(zé)處理用例實現(xiàn)的控制和協(xié)調(diào)關(guān)系。有時，一些控制信息是由參與者在與系統(tǒng)交互時處理的，這種情況下可將控制封裝在邊界對象中。 仔細(xì)研究用例說明和已有的業(yè)務(wù)模型確定實體類。 考慮每個用例實現(xiàn)所涉及到的信息，將它們分配到3類對象中。65 描述每個對象之間的交互。 描述每個用例實現(xiàn)的特殊需求。 用例實現(xiàn)是對用例內(nèi)部比較細(xì)節(jié)

45、的描述，是分析類之間相互協(xié)作的構(gòu)造?？赏ㄟ^用例實現(xiàn)回溯到用例模型，保持需求獲取和分析之間的無縫連接。 （ 3）分析每個類的職責(zé)、屬性和關(guān)聯(lián)）分析每個類的職責(zé)、屬性和關(guān)聯(lián) 確定分析類的職責(zé) 通過研究一個分析類在每個用例實現(xiàn)中充當(dāng)?shù)慕巧?，將其在各個用例實現(xiàn)中的職責(zé)組合在一起，構(gòu)成分析類的職責(zé)。 確定分析類的屬性 注意幾點：與人交互的邊界類的屬性通常是參與者錄入的信息項。與外部系統(tǒng)交互的邊界類的屬性表現(xiàn)為通信接口。實體類的屬性往往作為重要信息被錄入系統(tǒng)。 66 從幾個分析類中抽取出公共的或可共享的特性，組成新的類。 確定分析類的關(guān)聯(lián)。類之間的關(guān)系盡可能簡單。 定義分析類的特殊需求。參照用例實現(xiàn)的特殊

46、需求，避免重復(fù)定義。 （4）檢查分析模型）檢查分析模型 用例實現(xiàn)、分析類和分析包構(gòu)成了不同層次的分析模型，隋著分析的用例越來越多，分析模型會逐步完善起來。要檢查分析模型中各種成分的準(zhǔn)確性、一致性、完整性。在分析階段的后期要檢查分析包之間的關(guān)系，盡量獨立且內(nèi)聚性高，每個包實現(xiàn)一個完整的業(yè)務(wù)邏輯。67 2、實例、實例 ATM系統(tǒng)的用例模型和分析模型 在ATM系統(tǒng)中，儲戶是參與者，取款、存款和轉(zhuǎn)帳是3個用例。ATM的用例模型如圖所示。取款存款轉(zhuǎn)帳儲戶68 根據(jù)用例建立分析模型： 現(xiàn)在只考慮“取款”用例。完成取款用例動作序列的簡化路徑是：儲戶表明自己的身份；儲戶選擇從哪個帳戶取款；確定取款金額；系統(tǒng)從帳戶扣除取款金額；發(fā)給儲戶相應(yīng)金額的現(xiàn)金。 通過分析取款用例實現(xiàn)時的角色，確定所需的分析類包括： 分發(fā)分發(fā)邊界類（指分發(fā)金額）、出納接口出納接口邊界類、 取款取款控制類、 帳戶帳戶實體類 。邊界類負(fù)責(zé)與用戶進行交互并且處理交互的信息；控制類負(fù)責(zé)取款的事務(wù)處理；實體類負(fù)責(zé)保存和管理帳戶信息。 “取款”用例的分析模型如下圖所示。在圖中還表示了分析模型的“取款”用例實現(xiàn)跟蹤依賴于用例模型的“取款”用例。69取款存款轉(zhuǎn)帳儲戶取款參與者跟蹤用例模型分析模型分發(fā)出納接口取款帳戶 下圖中