【正文】 )靜態(tài)模型：類圖、對象圖、包圖、構件圖和配置圖(3)動態(tài)模型：活動圖、順序圖、狀態(tài)圖和協(xié)作圖 。關系包括：關聯(lián)關系，依賴關系 實現(xiàn)關系： (續(xù))——用例之間關系1（包含與擴展）.(續(xù))——用例之間關系2（泛化）.(續(xù))——用例與參與者用例use case：一組用例的實例（場景），其中每個實例都是系統(tǒng)執(zhí)行的一系列活動，這些活動產(chǎn)生了對每個參與者而言可觀察的返回值。描述了從參與者角度看系統(tǒng)做了什么用例模型本身不是面向對象建模技術。參與者actor: 是指在系統(tǒng)外部與系統(tǒng)交互的人或其他系統(tǒng)，以某種方式參與了系統(tǒng)內用例的執(zhí)行。(順序圖、協(xié)作圖)1）協(xié)作圖：采用圖的形式展示對象間的交互 2）順序圖：采用柵欄格式展示對象間的交互順序圖與協(xié)作圖的優(yōu)缺點： 順序圖（優(yōu)點）強調消息的時間順序及對象生命線（優(yōu)點）大量詳細表示法選項（缺點）強制在右側增加新對象，消耗空間大 協(xié)作圖（優(yōu)點）強調結構組織，復雜交互表達更容易（優(yōu)點）空間利用率高，和方便添加新對象（缺點）不宜查詢消息的順序，表示法選項少 5 活動圖活動圖用于表示完成一個操作所需要的活動，或者是一個用例實例（場景）的活動?；顒訄D適合描述動作流和并發(fā)處理行為。5活動圖——實例組指定給負責這組活動的業(yè)務組織即對象。泳道區(qū)分了負責活動的對象，明確地表示了哪些活動是由哪些對象進行的。每個活動只能明確地屬于一個泳道。6 狀態(tài)圖（狀態(tài)機）狀態(tài)圖(state diagram)一個對象在其生存期間的動態(tài)行為，表現(xiàn)對象響應事件所經(jīng)歷的狀態(tài)序列以及伴隨的動作。并不是所有類都有相應的狀態(tài)圖。狀態(tài)圖只適用于：具有若干個確定狀態(tài)，類的行為在這些狀態(tài)下 會受到影響且被不同的狀態(tài)改變。狀態(tài)圖與活動圖的區(qū)別與聯(lián)系（1）相同的圖形符號。（2）描述一個系統(tǒng)或對象在生存周期的狀態(tài)或行為。（3）描述系統(tǒng)或對象在多進程中同步或異步操作并發(fā)行為。（4）用條件分支來描述系統(tǒng)或對象的行為控制流。聯(lián)系：（2）描述多個對象共同完成一個操作的機制不同?；顒訄D置于責任區(qū)（泳道）中，責任區(qū)將活動按責任目標和組織歸屬的原則分類。狀態(tài)圖采用狀態(tài)嵌套方式描述多對象協(xié)作。類圖類圖表示系統(tǒng)中類及類和類之間的關系，用于對系統(tǒng)的靜態(tài)結構進行描述。：（1）關聯(lián)：關聯(lián)表示兩個類的對象之間存在某種語義上的聯(lián)系。（2）聚集：聚集也稱為聚合，關聯(lián)的特例 聚集表示類與類之間的關系是整體與部分的關系。（3）泛化：uml中的泛化關系就是通常所說的繼承關系，它是通用元素和具體元素之間的一種分類關系。（4）依賴和細化。2)類的關系——關聯(lián)間具有細化關系。細化用來協(xié)調不同階段模型之間的關系。構件圖由構件、接口及構件之間的關系組成。構件圖主要用于系統(tǒng)的靜態(tài)實現(xiàn)視圖模型，通過構件的依賴關系描述系統(tǒng)軟件的組織結構，展示系統(tǒng)不同物理構件及其關系。系統(tǒng)業(yè)務模型：業(yè)務過程和文檔。系統(tǒng)開發(fā)管理模型：開發(fā)期間產(chǎn)物及關系 系統(tǒng)實現(xiàn)模型：系統(tǒng)實現(xiàn)的構件建模第六章 從需求到設計 包圖（package diagram）概念性的模型管理工具，用于將大型的軟件系統(tǒng)中大量的建模元素有序的組織起來。運用包可以把語義上相近的可能一起變更的模型元素組織在同一個包中，對包中的元素作為一個整體對待，并 2)類的關系——聚集聚集也稱為聚合，是關聯(lián)的特例。聚集表示類與類之間的關系是整體與部分的關系。（ 聚合：聚集關系中處于部分方的對象可同時參與多個處于整體方對象的構成.（：。2)類的關系——泛化 uml中的泛化關系就是通常所說的繼承關系（或一般與特殊關系）。2)類的關系——依賴兩個類之間有依賴，（供應類）所提供的某些服務。2)類的關系——細化當對同一個事物在不同抽象層次上描述時，這些描述之系統(tǒng)物理配置模型：數(shù)據(jù)文件、日志、安裝/卸載等文件且控制它們的可視性和存取。包擁有內容，包括類、接構件建模 口、組件、節(jié)點、協(xié)同。use case、圖，甚至其它包。集成系統(tǒng)模型：對api建模，幫助利用已有組件。第三章 unified process(1)構件: 系統(tǒng)中遵從并實現(xiàn)一組接口的物理的、可替換up的構成：二維的面向對象開發(fā)模型，兼顧技術和管理。的軟件模塊。構件是軟件復用的基本物理實現(xiàn)單元，是工作流:過程工作流(業(yè)務建模+需求+分析與設計+實施+邏輯元素模型（類、接口、協(xié)同等）的物理包測試+部署)和3個支持工作流（配置和變更管理+項目管理+環(huán)境）4個階段：初始＋細化＋構造＋交付 up的迭代策略。up的迭代開發(fā)策略:以體系結構為中心，以質量管理和風險控制為目標，以用例為驅動，采用迭代式以螺旋上升的模式進行軟件開發(fā)。(2)構件的接口:一個構件可以定義對其他構件可見的接第四章 初始階段(inception)口。構件間依賴通過指向所使用的構件接口來表示。：口描述一個構件能提供服務的操作，是一個有操作而無做適當?shù)恼{研，以形成對新系統(tǒng)的整體目的和可實現(xiàn)的類。包括輸入和輸出接口。行性形成一個合理的意見。建立項目的軟件范圍和邊界條件，包括一個操作“前景”，“接受準則”和產(chǎn)品中包含什么，不包含什么? 確定核心的用例，這是系統(tǒng)運行的主要場景，它將決定系統(tǒng)設計的方案針對主要的場景，確定或者演示至少一個備選的系統(tǒng)結9 部署圖（deployment diagram）構由節(jié)點和節(jié)點之間的聯(lián)系組成，描述了處理器、設備和對整個項目估計總成本和計劃(更詳細的估計將安排在軟件構件運行時的體系結構。細化階段中)估計可能的風險(不可預計性的來源）為項目準備支持環(huán)境 ： 用例模型＋用例描述，詞匯表，補充性規(guī)格說明，前景，業(yè)務規(guī)則 9 部署圖——結點 節(jié)點是存在于運行時的代表計算資源的物理元素，可摘要：簡介描述用例，通常只給出主成功場景。以代表一種物理硬件設備或軟件元素。非正式：用若干非正式段落來描述用例，通常給出多個包含：處理器和設備兩種類型 不同場景。詳述：詳細描述用例，通常給出所有的步驟及場景，并10 部署圖——結點間聯(lián)系給出前置和后置條件等細節(jié) 節(jié)點間通過物理連接發(fā)生聯(lián)系，以從硬件方面保證注意：用例描述的方法 系統(tǒng)各節(jié)點之間的協(xié)同運行。包括通訊關聯(lián)、等。(1)選擇系統(tǒng)邊界(2)尋找參與者(3)確定每個參與者的目標(4)定義用例 :一般為每一個用戶目標定義用例確定用例的經(jīng)驗方法：(1)老板測試：必須看到可量化的價值(2)ebp：能夠增加可量化的業(yè)務價值，并且以持久狀態(tài)留下數(shù)據(jù)(3)規(guī)模測試： (1)意義：記錄功能需求；迭代計劃的重要部分，預算的關鍵輸入；實現(xiàn)驅動設計；影響用戶手冊和測試(2)初始階段：確定系統(tǒng)目標、范圍、涉眾；絕大部分摘要描述、10～20％詳述；確定是否繼續(xù)開發(fā)(3)細化階段：80～90％被細化描述；分多次迭代(4)構造階段：多次時間定量迭代；補充次要用例 第五章 細化階段(elaboration): 表述系統(tǒng)是什么，而不解釋它是如何做的，將系統(tǒng)作為黑盒子 系統(tǒng)順序圖它展示了對一個特定的用例，外部的參與者產(chǎn)生的事件，它們的順序以及系統(tǒng)內的事件協(xié)作與耦合從較高層到較低層進行，避免從較低層到較高層的耦合第七章 模式與對象設計 1 職責和職責驅動設計 類的契約和責任，分為：行為職責和認知職責。在對象設計中，職責被分配給對象，稱為rdd。2 設計模式設計模式：對被用來在特定場景下解決一般設計問題的類和相互通信的對象的描述。即，對特定問題的描述或解決方案。目的: 易于理解，維護，擴展和重用 3 grasp模式 控制器（controller），創(chuàng)建者（creator），信息專家 構建核心體系架構，解決高風險問題，完成絕大部分需求的定義，并估計并估計總體計劃和資源，保證架構，需求和計劃足夠穩(wěn)定，風險被充分規(guī)避，確定和解決項目中所有與架構密切相關的風險，從與架構密切相關的場景中確定一個基準體系架構，產(chǎn)生一個達到產(chǎn)品級質量水準的演化性原型，也可以是一個或更多個探索型拋棄型原型，能夠展示基準的體系架構以合理的價格和合適的時間支持系統(tǒng)需求，建立一個支持環(huán)境 : 盡快定義和驗證體系架構，并確定體系架構基線 細化設想（vision）為構造階段建立詳細的迭代計劃并建立基線 細化開發(fā)用例并將其部署到開發(fā)環(huán)境中 細化體系架構并選擇組件 實行短時間定量、風險驅動的迭代，及早開始編程，對架構核心和風險部分進行適應性設計，實現(xiàn)和測試，盡早，頻繁，實際的測試，基于來自測試，用戶，開發(fā)者的反饋進行調整，通過一系列討論會，詳細編寫大部分用例和其他需求，每個細化迭代舉行一次 : 通過風險、覆蓋范圍和關鍵程度組織需求和迭代。風險：技術復雜性；其他因素覆蓋性：在早期迭代中，系統(tǒng)中主要的部分都有所涉及 關鍵性：具有高業(yè)務價值的功能在每個迭代前將用例和特征進行排序 迭代單位：(1)用例；(2)場景 : 領域模型，設計模型，軟件架構文檔，數(shù)據(jù)模型，用例示意板，用戶界面模型 (domain model)領域模型是對真實世界中概念類的表示，而不是軟件對象的表示。它不是用來描述軟件類、軟件架構領域層或有職責軟件對象的一組圖。領域模型用一套類圖表示，但類沒有操作。領域模型可以顯示：領域對象或者概念類；概念類之間的關聯(lián)；概念類的屬性概念類來源：現(xiàn)實（組織、地點、設備等）對象；業(yè)務（業(yè)務實體和概念）對象；過程（需要記錄的時間）對象。通過領域模型中的對象的狀態(tài)變換(實例創(chuàng)建或刪除。屬性修改。關聯(lián)形成或者打破)，: enteritem 操作 : enteritem(itemid: itemid, quantity: integer)前提（preconditions）: there is a sale underway 后置條件（postconditions）: 一個saleslineitem的實例sli被創(chuàng)建；sli與當前的 sale 對象相關聯(lián)；，依據(jù)itemid的匹配，sli 與productspecification相關聯(lián) 第六章 從需求到設計 邏輯架構（logical architecture）是軟件類的宏觀組織結構，它將軟件類組織成包（命名空間），子系統(tǒng)和層等。層（layer）：對類、包或子系統(tǒng)的粗粒度的分組，具有對系統(tǒng)主要方面加以內聚的職責。較高的層可以調用較低的層。常見的層：用戶界，應用邏輯和領域對象，技術服務 典型的分層模式 架構是一組重要決策，其中涉及軟件系統(tǒng)的組織，對結構元素及其組成系統(tǒng)的接口的選擇，這些元素特定于其相互協(xié)作的行為，這些結構和行為元素到規(guī)模更大的子系統(tǒng)的組成，以及指導該組織結構的架構風格。（模型視圖分離, 如mvc架構）系統(tǒng)的大型邏輯結構組織為獨立的，職責相關的離散層，具有清晰內聚的關注分離。較低的層是低級別和一般性服務，較高的層則是與應用相關。（information expert），高度內聚（high cohesion），低耦合（low coupling）4 命令——查詢分類原則執(zhí)行動作（更新、調整）的命令方法，這種方法通常具有改變對象狀態(tài)等副作用，并且是 void 的（沒有返回值）。向調用者返回數(shù)據(jù)的查詢，這種方法沒有副作用，不會永久性的改變任何對象的狀態(tài)。一個方法不應該同時屬于以上兩種類型。