面向對象分析的主要工作用例模型幫助開發團隊理解客戶對系統的各種功能需求概念模型（靜態模型）幫助開發團隊理解問題領域的各種概念、各種名詞、以及它們之間的各種關系。描述系統的結構特征動態模型描述系統的動態行為特征。這兩方面的工作，將幫助開發團隊定義問題，也是分析工作的主要內容第一頁，共六十一頁。分析與設計過程全景第二頁，共六十一頁。UML在建模中的使用第三頁，共六十一頁。面向對象分析過程定義用例（輔助模型，可選）用用例對用戶需求進行規范化描述建立類圖（基本模型）發現對象、定義對象類識別對象的內部特征識別對象的外部關系建立交互圖、狀態圖和活動圖（輔助模型，可選）建立詳細說明對模型中的成分進行規范的定義和文字說明可以集中進行，也可分散在各個活動中原型開發結合其他活動反復進行第四頁，共六十一頁。什么是問題域?“問題域”是指一個包含現實世界事物與概念的領域，這些事物和概念與所設計的系統要解決的問題有關。建立概念模型，又稱為問題域建模、域建模，也就是找到代表那些事物與概念的“對象”。建模OO軟件的第一步是澄清問題域。第五頁，共六十一頁。確定核心的抽象概念目的通過采取確定系統必須處理的核心抽象概念（即在業務建模和需求活動中確定的概念）的措施來進行分析必要性需求和業務建模活動通常會揭示系統必須能夠處理的核心概念，與此同時，這些概念也證實了其自身是核心的設計抽象概念。因為已經確認，所以沒有必要在用例分析活動中重復確認工作。為了利用現有知識，我們初步確定使用實體分析類，來代表這些以系統常識（諸如需求、詞匯表、特別是領域模型或業務對象模型）為基礎的核心抽象概念關鍵抽象的來源需求詞匯表領域模型業務對象模型第六頁，共六十一頁。什么是分析類？它代表問題域中的簡潔抽象應該映射到真實世界業務概念分析類的最重要方面是應該使用清晰的和無歧義的方法映射到真實世界業務概念第七頁，共六十一頁。OO分析師的工作力求把混淆或不恰當的業務概念澄清為能夠形成分析類基礎的事物,是OO分析工作困難的原因。OO分析的真正目的是找出現實對象的類第八頁，共六十一頁。分析類的思想盡力捕獲抽象的本質,忽略實現細節不是從設計角度考慮而產生的類，在具體設計時可能一個分析類被精華為一個或多個設計類在分析中，在創建概念模型時，捕獲大場景。分析類的形式名稱屬性操作第九頁，共六十一頁。如何產生良好的分析類名稱反映目的。建模問題域的一個特定元素是簡潔的抽象。清晰地映射到問題域中的可識別的特征。具有小的、良好定義的職責集合。職責是類與其客戶的契約或對于客戶的義務職責在語義上是內聚的操作集合每個類大約有3~5個職責高內聚。類的所有特征應該有助于實現其目的低耦合。類應該僅同一小部分其他類協作實現其目的第十頁，共六十一頁。分析類經驗法則每個類大約3~5個職責。不存在獨立的類。當心很多非常小的類當心少數幾個非常龐大的類當心“偽類”當心萬能類避免深度繼承樹設計良好的繼承層次的本質是繼承層次中每個抽象層次應該具有良好定義的目的第十一頁，共六十一頁。OO分析建模核心問題尋找分析類使用名詞/動詞分析尋找類使用CRC分析尋找類尋找其他類來源第十二頁，共六十一頁。使用名詞/動詞分析尋找類名詞/動詞分析是分析文本嘗試找出類、屬性和職責的方法。從名詞與名詞短語中提取對象與屬性從動詞與動詞短語中提取操作與關聯所有格短語通常表明名詞應該是屬性而不是對象第十三頁，共六十一頁。名詞/動詞分析過程第一步：盡可能多地收集相關信息補充需求規格說明用例項目詞匯表任何其他信息源（構架、遠景文檔）第十四頁，共六十一頁。名詞/動詞分析過程（續）第二步：使用非常簡單方法分析如下內容：名詞名詞短語動詞動詞短語第十五頁，共六十一頁。概念模型建模步驟找到備選類決定候選類并不是每一個備選類都是合適的候選類，有些名詞對于要開發的系統來說并無關緊要，甚至是系統之外的;而有些名詞表述的概念則相對較小，適合于某個候選類的屬性

確定類之間的關聯為類添加職責什么是類的職責呢？它包括以下兩個主要內容：

類所維護的知識；（成員變量）

類能夠執行的行為。（成員方法）第十六頁，共六十一頁。舉例-創建概念模型一個愛書之人，家里各類書籍已過千冊，而平時又時常有朋友外借，因此需要一個個人圖書管理系統。該系統應該能夠將書籍的基本信息按計算機類、非計算機類分別建檔，實現按書名、作者、類別、出版社等關鍵字的組合查詢功能。在使用該系統錄入新書籍時系統會自動按規則生成書號，可以修改信息，但不能夠刪除記錄。該系統還應該能夠對書籍的外借情況進行記錄，可對外借情況列表打印。另外，還希望能夠對書籍的購買金額、冊數按特定時限進行統計。第十七頁，共六十一頁。使用名詞/動詞法注意在使用“名詞動詞法”尋找類的時候，很多團隊會在此耗費大量的時間，這樣很容易迷失方向。其實我們的主要目的是對問題域建立概要的了解，無需太過咬文嚼字。第十八頁，共六十一頁。其它方法-CRC分析腦力風暴技術過程要求團隊成員命名運轉在業務領域的事物要求團隊陳述該事物的職責要求團隊識別可能一起工作的類第十九頁，共六十一頁。概念模型的意義面向對象的視角使用OO的思想所建立的系統模型就是對問題域的完整、直接的映射,體現了OO思想的關鍵活動

開發團對的需要概念模型的建立，其主要的作用是幫助開發團隊能夠對問題域有一個全貌式的了解第二十頁，共六十一頁。概念模型的詳細程度模型不是我們要生產的目標產物，而且過程中的一個輔助工作，只要能夠利用其幫助團隊更好的開發，詳細也罷、簡約也罷，都是好模型第二十一頁，共六十一頁。OO分析總結用例模型幫助開發團隊明白客戶想解決什么問題將需求整理歸納成為指導全開發過程的“軟件需求規格說明書概念模型幫助開發團隊了解客戶所處的世界第二十二頁，共六十一頁。分析用例（行為分析）用例模型補充需求構架描述用例分析用例用例工程師業務模型分析類第二十三頁，共六十一頁。用例分析目的確定執行用例事件流的類使用用例實現，將用例行為分配給那些類確定類的職責、屬性和關聯關系記錄構架機制的使用情況角色設計師時機用例分析分兩個階段第一個階段是“定義備選構架”，同時做“構架分析”活動，目標是定義一個備選構架第二個階段是“分析行為”，與“確定設計元素”活動一起做，目標是把用例行為分配到分析類中第二十四頁，共六十一頁。行為分析之前-用例建模獲取可靠的需求--我們需要高層的需求文檔和用例結構圖來確定需求的可靠性，它并不一定完備、但提供了系統的基本全景；如果在分析過程中發現了一些相當新的用例，那說明需求工作沒做到位，它作為分析（行為建模）的基礎將是不可靠的；確定用例的優先級—我們通常采用迭代的開發模式，每次只針對一個目標用例集展開分析，而不是全線出擊；因此需要根據風險、重要性和團隊的適應能力綜合考慮，為所有的用例確定優先級；那些級別高的用例應當有詳細的規格說明，包括基本流和重要的擴展流，它們是分析的基本素材。第二十五頁，共六十一頁。用例實現中的分析與設計用例建模對系統外在的行為進行了分解，每個用例情節最終都落實到內部某個對象群體的協作上；而對象群體行為則進一步將必要職責分配到對象個體上；這便是用例實現，并分為用例分析和用例設計兩個階段。為用例實現建模的元素包括—協作圖、序列圖、以及類圖等。第二十六頁，共六十一頁。用例分析的輸入和輸出輸入詞匯表補充規約用例模型用例規約用例建模指南用例實現（只是識別出來了，還沒有開發）軟件構架文檔邊界類，表示用戶界面中的窗口設計模型或分析模型輸出用例實現分析模型（可選）或設計模型

第二十七頁，共六十一頁。用例實現用例實現對用例模型中的每個用例，在設計模型中都有相應的實現提供從分析和設計到需求的可跟蹤性用例實現結構用例實現包是組織用例的類和交互圖的方式每個用例都對應一個用例實現包可跟蹤性圖交互圖時序圖（SequenceDiagrams）（動態）協作圖（CollaborationDiagrams）（動態）類圖（ClassDiagrams）（靜態）第二十八頁，共六十一頁。用例分析的步驟補充用例描述對每個用例實現從用例行為中找出類把用例行為分配到類對每個分析類描述屬性和關聯描述責任限定分析機制（analysismechanism）確定屬性建立分析類之間的關聯關系說明分析類之間的事件依賴關系整合分析類第二十九頁，共六十一頁。Step1:補充用例描述用例的描述往往不夠查找分析類用戶通常不關心系統內部的信息，所以開始時的用例描述是黑盒的為了發現分析類，需要從系統內部的視點對用例進行白盒描述例如：課程注冊系統中，學生可能喜歡說“系統顯示課程列表”，但是這不能說明系統內部是如何實現的。為了給出系統內部是如何工作的，我們要加入:系統從課程目錄遺留數據庫中取得課程列表第三十頁，共六十一頁。Step2:從用例行為中查找分析類

目的確定一組備選的、能夠執行用例行為的分析類分析類分析類代表“系統中具備職責和行為的事物”的初期概念模型。這些概念模型最終將演進為設計模型中的類和子系統分類（根據其擔負的職責和表現的行為）邊界類（Boundaryclass）接口與系統外部某些事物的媒介。控制類（ControlClass）負責協調用例的行為。實體類（EntityClass）

封裝了數據以及數據相關的操作，表達領域概念，負責承擔系統中需要持久化的信息及其關聯的行為。應用邏輯對象

第三十一頁，共六十一頁。識別分析類用例的行為最終都要落實到各分析類的職責上。第三十二頁，共六十一頁。邊界類承擔的角色邊界類負責系統與外界的通訊和交互。邊界對象將系統與其外部環境的變更（與其他系統的接口的變更、用戶需求的變更等）分隔開，使這些變更不會對系統的其他部分造成影響。

第三十三頁，共六十一頁。邊界類的職責轉換和翻譯交互事件—對內，將外界不同格式的事件和信息轉換為內部能夠識別的格式，并觸發控制類對象（或實體對象）來響應它們；對外，則做類似的反向操作；變更對外的表示內容—在內部狀態（特別是外界關注的信息）發生變化時，向外部通知或更新表示內容）常見的邊界類對象有：用戶接口類幫助與用戶進行通信的類，通過標準的I/O設備提供人機界面（GUI）系統接口類幫助與其他系統進行通信的類，系統（通訊協議）接口。設備接口類或Timer提供對硬件設備的軟件接口第三十四頁，共六十一頁。識別邊界類用戶界面類關注要呈現給用戶的信息是什么不要陷入UI的設計細節系統和設備接口類關注必須定義的協議是什么不要關注協議是如何實現的重點關注職責而不是細節第三十五頁，共六十一頁。識別邊界類（續）每個用例主角都至少有一個邊界類查找用戶接口類時需要注意可以復用用戶界面建模活動期間存在的邊界類僅對系統的核心部分建模，不要對

GUI中的每個按鈕、列表和小部件都建模。分析的目的是要大致了解系統是如何構成的，而不是要設計每一個細枝末節查找系統邊界類時注意與現有系統的接口可能已有明確定義，如果是這樣，即可從接口定義中直接推導出職責如果已經有一個正式的接口定義，則可對它實施逆向工程，這樣就不必在此正式界定它查找設備邊界類時注意做用例分析的時候可能需要補充原來沒有識別出來的設備主角，相應的也要修改用例的說明第三十六頁，共六十一頁。實例：用戶界面（邊界類）第三十七頁，共六十一頁。實例：系統接口（邊界類）第三十八頁，共六十一頁。邊界類的職責歸類GUI界面邊界類承擔的職責包括：按要求的格式顯示內容（VIEW—文本、表格、圖形等控件）輸入數據并轉換為內部格式（CONTROL—編輯、選擇、圖形等控件）轉換和翻譯用戶動作并觸發響應（CONTROL—菜單、按鈕、快捷鍵）系統接口邊界類承擔的職責包括：輸入/輸出數據，并根據協議進行格式轉換接收事件并觸發響應和向外發送事件第三十九頁，共六十一頁。邊界類的狀態與行為GUI界面邊界類可以擁有狀態，并可能對其行為產生如下影響：影響用戶操作的執行范圍（菜單等的使能與禁用，對話框的打開與關閉）影響對外顯示的樣式和能力邊界類的狀態除了受用戶操作序列的影響，更多地將為控制類和實體類的狀態所控制系統接口邊界類的狀態將與其支持的協議中規定的交互順序有關設備接口邊界類通常擁有復雜的狀態，以便支持與硬件設備的適配邏輯第四十頁，共六十一頁。控制類作用：負責協調、調度、處理事務并控制系統內部其它對象的行為。用于對一個或幾個用例所特有的控制行為進行建模，控制類封裝了用例的特有行為控制對象（控制類的實例）通常控制其他對象，因此它們的行為具有協調性質控制類有效地將邊界對象與實體對象分開，讓系統更能適應其邊界內發生的變更控制類還將用例所特有的行為與實體對象分開，使實體對象在用例和系統中具有更高的復用性控制類并不能處理用例需要執行的一切事務。相反，它協調其他用來實施此功能的對象的活動。控制類將工作委派給已被指定負責此項功能的對象。控制類通常被看成一個樂隊的指揮，它指揮（控制）參與usecase的其它對象的行為，通知對象什么時候執行以及執行什么。第四十一頁，共六十一頁。控制類的角色協調用例的行為第四十二頁，共六十一頁。識別控制類可以首先為每個用例實現確定一個控制類，接著，在確定了更多的用例實現并發現更多的共性后，再對其進行改進將性質不同的控制邏輯封裝到分離的控制類中將（邏輯復雜的）主事件流和可選/異常事件流封裝到不同的控制類中盡量為每個執行者定義單獨的控制類第四十三頁，共六十一頁。控制類的職責歸類用例控制類負責用例的控制序列（應用邏輯），協調其它類的協作以完成用例的不同執行場景，其中包括：控制顯示（導航）流程控制系統的執行動作，這些動作將可能改變系統的內部狀態、提供結果數據等控制協議的對話順序第四十四頁，共六十一頁。控制類的行為控制類行為有以下特點與周圍環境無關定義控制邏輯（event的順序）和usecase事務如果實體類的內部結構或行為變化，控制類很少會變化使用或設定幾個實體類的內容，因此需要協調這幾個實體類的行為每次被激活，行為方式不同（flowofevent與多個狀態有關）有的用例沒有控制類，復雜的用例可以有多個控制類控制對象的生命周期通常和用例實例的生命周期相同控制類可以分為協調對象(狀態無關的)和狀態相關的控制對象兩種

第四十五頁，共六十一頁。示例：管理任務隊列執行任務用例的事件流主要包含：從任務隊列中按順序取出任務，并為其分配資源，然后開始執行任務（系統可以同時執行多個任務）；根據控制邏輯的不同性質，可以劃分為兩個控制類，一個負責處理任務隊列和分配資源，另一個則負責具體控制任務的執行過程。第四十六頁，共六十一頁。實體類實體類(entityclass)系統的關鍵抽象、是系統的核心概念主要責任是用于保存和管理系統的信息，如一個event，一個人或一些實際存在的對象的信息。通常是持久化的(persistent)通常不特定于某個usecaserealization，有時甚至不特定于系統。實體類承擔的角色（存儲和管理系統中的信息）第四十七頁，共六十一頁。從用例中識別實體類使用用例的事件流作為輸入用例中的關鍵抽象傳統的名詞過濾法劃出用例事件流中的名詞條款去掉重復的候選者去掉含糊的候選者去掉執行者ACTORS（超出了系統范圍）去掉實施部件去掉屬性去掉操作第四十八頁，共六十一頁。應用邏輯對象

分為業務邏輯對象和算法對象兩種業務邏輯對象（BusinessLogicObjects）

定義業務特定的處理一個用戶請求的應用邏輯，目的是封裝（隱藏）業務邏輯通常業務邏輯對象在執行過程中可以訪問各種實體對象只有在特定情況下才需要業務邏輯對象如果businessrule要通過訪問兩個或多個實體對象才能執行，就需要有一個單獨的業務邏輯對象否則，就是實體類的一個操作業務邏輯對象與協調對象的區別協調對象的責任是監督其他的對象而業務邏輯對象的主要責任是封裝和執行businessrule算法對象（AlgorithmObjects）封裝了問題域用的算法

算法對象通常也封裝了計算算法時需要的數據

第四十九頁，共六十一頁。實例：識別的候選分析類第五十頁，共六十一頁。Step3:把用例行為分配到類指南：把責任分配到類邊界類和actor交互的行為實體類與數據抽象封裝有關的行為控制類特定到一個usecase或一部分非常重要的事件流程的行為動態建模：用時序圖和協作圖來描述用例行為注意：對所有基本流和備選流都要進行分析第五十一頁，共六十一頁。時序圖時序圖表示如何一步步的完成系統的一個功能時序圖是用于決定類責任和接口的主要信息來源時序圖描述了對象間的交互模式通過對象的“生命線”和他們相互發送的消息來顯示對象時序圖與協作圖在語義上是相同的，只是時序圖中的消息是按時間順序分布的時序圖表示的是一個場景(scenario)組成主角對象消息生命線Focusofcontrol表示對象直接或通過子過程執行動作的一段時間第五十二頁，共六十一頁。協作圖協作圖顯示對象之間的交互協作圖強調參與交互的對象的組織適合分析活動，適合表示少數對象的簡單交互協作圖很難顯示補充的說明性信息，例如時間、判定點或其他非結構化的信息，而在序列圖中這些信息可以方便地添加到注釋中

組成主角(actor)對象(object)Links：Link是對象通信的途徑消息(message)第五十三頁，共六十一頁。記錄分析類的職責用簡短的（最多幾個單詞）職責名稱和簡短的（最多幾個句子）說明記錄職責。該說明表述對象實現職責需要執行什么操作，以及調用職責時將返回什么結果可以用兩種方式來記錄職責用分析類的操作：操作名就是職責名稱，職責的說明就寫到操作的說明中。為了表示該操作是一個職責，應該在操作名前面加上“//”來標記用文字描述：在類的說明中描述類的職責

維護一致性確保類具有一致的責任，如果類的責任是脫節的，要把類分成兩個或多個新類，同時要修改交互圖

確保沒有兩個類具有相似的責任，如果兩個類具有相同的責任，就把這兩個類合并成一個，同時要修改交互圖

第五十四頁，共六十一頁。實例：用例分析-時序圖第五十五頁，共六十一頁。確定屬性是屬性還是類？信息屬于以下情況時，需要使用屬性“通過值”引用；即在信息中只有值是重要的，而與地址或對象標識符無關由其所屬的對象唯一“擁有”；其他對象都不引用這條信息通過獲取、設置或者執行對信息的簡單轉換的操作進行訪問；信息除了提供它本身的值以外沒有任何“實際”的行為如果信息具有復雜的行為，被兩個或更多對象共享，或者在兩個或更多對象間“通過引用”傳遞，此時信息應當作為一個單獨的類屬性的說明屬性名稱應當是一個名詞，它描述了屬性保存的信息屬性說明應當說明屬性中將要存儲的信息；如果從屬性名稱可以很明顯地看出所存儲的信息，則可以不說明屬性類型就是屬性的簡單數據類型。例如字符串、整型、數值型等第五十六頁，共六十一頁。確定屬性屬性可以來自領域知識需求Glossary領域模型業務模型分析時屬性的類型來自領域，可以不映射到具體的實現語言第五十七頁，共六十一頁。識別分析類之間的關系識別分析類之間的關聯關系有兩個來源協作圖：協作圖中對象之間有聯系，就意味著相應的類之間存在關聯關系領域知識：從中得到實體類之間的聚合關系注意：不要添加您認為“或許”存在的關聯關系，除非協作圖要求添加這些關聯關系在分析時不用識別出類之間的關系是關聯還是依賴，是聚合還是組合，因為我們還沒有作出明智決策所需要的足夠信息，我們將在類設計活動中改進對于繼承關系，在分析時可以識別出來，但是不要求

是關聯還是聚合

選擇聚合只是為了闡明一種整體/部分的關系

如果拿不準是什么關系，通常關聯關系更合適。聚合關系通常是很明顯的，聚合的語義應該很容易的從上下文中理解出來

是聚合關系還是關聯關系與開發的具體應用有關第五十八頁，共六十一頁。記錄類之間的關系用類圖來表示類之間的關系

用例實現的類圖又叫VOPC（ViewOfParticipatedClasses）畫類圖時，還要給關系加上關系名或角色（Role）名稱關聯關系名稱和角色名稱