面向?qū)ο蠓治雠c設(shè)計分析

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

確定類之間的關(guān)聯(lián)為類添加職責什么是類的職責呢？它包括以下兩個主要內(nèi)容：

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

類能夠執(zhí)行的行為。（成員方法）第十六頁，共六十一頁。舉例-創(chuàng)建概念模型一個愛書之人，家里各類書籍已過千冊，而平時又時常有朋友外借，因此需要一個個人圖書管理系統(tǒng)。該系統(tǒng)應該能夠?qū)幕拘畔从嬎銠C類、非計算機類分別建檔，實現(xiàn)按書名、作者、類別、出版社等關(guān)鍵字的組合查詢功能。在使用該系統(tǒng)錄入新書籍時系統(tǒng)會自動按規(guī)則生成書號，可以修改信息，但不能夠刪除記錄。該系統(tǒng)還應該能夠?qū)耐饨枨闆r進行記錄，可對外借情況列表打印。另外，還希望能夠?qū)馁徺I金額、冊數(shù)按特定時限進行統(tǒng)計。第十七頁，共六十一頁。使用名詞/動詞法注意在使用“名詞動詞法”尋找類的時候，很多團隊會在此耗費大量的時間，這樣很容易迷失方向。其實我們的主要目的是對問題域建立概要的了解，無需太過咬文嚼字。第十八頁，共六十一頁。其它方法-CRC分析腦力風暴技術(shù)過程要求團隊成員命名運轉(zhuǎn)在業(yè)務(wù)領(lǐng)域的事物要求團隊陳述該事物的職責要求團隊識別可能一起工作的類第十九頁，共六十一頁。概念模型的意義面向?qū)ο蟮囊暯鞘褂肙O的思想所建立的系統(tǒng)模型就是對問題域的完整、直接的映射,體現(xiàn)了OO思想的關(guān)鍵活動

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

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

目的確定一組備選的、能夠執(zhí)行用例行為的分析類分析類分析類代表“系統(tǒng)中具備職責和行為的事物”的初期概念模型。這些概念模型最終將演進為設(shè)計模型中的類和子系統(tǒng)分類（根據(jù)其擔負的職責和表現(xiàn)的行為）邊界類（Boundaryclass）接口與系統(tǒng)外部某些事物的媒介?？刂祁悾–ontrolClass）負責協(xié)調(diào)用例的行為。實體類（EntityClass）

封裝了數(shù)據(jù)以及數(shù)據(jù)相關(guān)的操作，表達領(lǐng)域概念，負責承擔系統(tǒng)中需要持久化的信息及其關(guān)聯(lián)的行為。應用邏輯對象

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

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

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

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

分為業(yè)務(wù)邏輯對象和算法對象兩種業(yè)務(wù)邏輯對象（BusinessLogicObjects）

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

算法對象通常也封裝了計算算法時需要的數(shù)據(jù)

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

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

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

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

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

是關(guān)聯(lián)還是聚合

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

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

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

用例實現(xiàn)的類圖又叫VOPC（ViewOfParticipatedClasses）畫類圖時，還要給關(guān)系加上關(guān)系名或角色（Role）名稱關(guān)聯(lián)關(guān)系名稱和角色名稱