樂山師范學院課程教案系（院）計算機科學學院專業計算機科學與技術課程名稱面向對象技術與UML授課對象數信學院10級本科信計班教師項煒職稱講師課程學時642012～2013學年(上)期

課程名稱面向對象技術與UML課程編號授課時間2012-2013(上)專業及班級數信學院10本信計班修課人數總學時64學分4課程類型必修課公共基礎()專業（學科）基礎課(√)專業課()選修課專業限選課（）專業任選課（）全校任選課（）授課方式理論課(√)實踐課(√)學時分配課堂講授32學時；實踐環節32學時考核方式考試()考查(√)是否采用多媒體是是否采用雙語否使用教材：（名稱、作者、出版社及出版時間）《UML面向對象建模基礎》，徐鋒，中國水利水電出版社，2006教學參考書：（名稱、作者、出版社及出版時間）《UML基礎與ROSE建模案例》，吳建，人民郵電出版社，2007《Java與UML面向對象程序設計教程》，劉曉冬，清華大學出版社，2008《UML與系統分析設計》，張龍祥，人民郵電出版社，2007《軟件工程》，錢樂秋，清華大學出版社，2007教研室審查意見注：表中（）選項請打“√”。

第一章面向對象的概念（4學時）1.1章節目標（教學目的及要求）1、解釋面向對象的基本原則2、定義面向對象的基本概念和相關的UML符號3、展示面向對象的威力4、列舉一些基本UML建模符號教學內容1.1什么是UML？統一建模語言（UML）是一種通用的可視化建模語言，用于對軟件進行描述、可視化處理、構造和建立軟件系統工作文檔。它記錄了與被建系統的有關決策和理解，可用于對系統的理解、設計、瀏覽、配置、維護以及控制系統的信息。UML適用于各種軟件開發方法、軟件生命周期的各個階段、各種應用領域以及各種開發工具，旨在統一以往建模技術的經驗，吸收當今軟件開發的最佳實踐從而形成一種標準方法。UML包括語義概念、表示方法和指導規范，提供了靜態、動態、系統環境及組織結構的模型。它可被交互式的可視化建模工具所支持，這些工具提供代碼生成和報表生成。UML標準并沒有定義一種標準的開發過程，但它適用于迭代的開發過程。它是為支持現今大部分面向對象的開發過程而設計的。UML是一種語言；是一種可視化的語言；是一種可用于詳細描述的語言；是一種構造語言。是一種文檔化的語言；主要用于軟件密集型系統。1.2軟件工程最佳實踐軟件工程六個最佳實踐（即DevelopIteratively迭代開發、ManageRequirements需求管理、UseComponentArchitectures組件架構、ModelVisually可視化建模(UML)、ContinuouslyVerifyQuality持續質量改進、ManageChange變更管理）與本課程相關三個最佳實踐對象技術幫助成就了以下行為：1、迭代開發： 適應需求的變更、逐步加入對象元素和功能的可重用性；2、使用組件為基礎的結構： 結構化、組件為基礎的開發；3、可視化模型： 容易理解，修改簡單。1.3什么是對象技術？什么是面向過程？以算法和數據結構為核心，一段程序代碼解決一個或幾個問題。什么是面向對象？以客觀存在的事物即對象為開發核心，在開發時以類作為對象的框架。一種指導將語言、數據庫和其他工具構造在一起的原則。（注釋：面向對象是一種新興的程序設計方法或開發范型paradigm，面向對象運用對象、類、繼承、封裝、消息等概念來進行程序設計。其基本思想是，從現實世界中客觀存在的事物及對象出發來構造軟件系統，并在系統構造中盡可能運用人類的自然思維方式。）1.4什么是模型？----模型是現實的簡化。模型提供了系統的藍圖。1）什么是模型？為什么要建模？模型是對現實的簡化。建模是為了更好地理解正在開發的系統。因為我們不能完整地理解一個復雜系統，所以我們要對它建模。現實世界太復雜，我們的理解力有限。建模一定會進行抽象和簡化。2）為什么要建模？建模是為了產生對系統的理解。可視化的理解是最為直觀的理解。對于復雜系統，只用一個模型是不夠的，需要對系統拆分并使用多個相互關聯的模型。對于軟件密集型系統，就需要一種語言，它貫穿于軟件開發生命周期，并能表達系統體系結構的各種不同視圖。建模有四個目標：----幫助我們可視化我們的系統；----允許我們制定我們的系統的結構和行為；----給我們一個構造系統的模板；----記錄我們所做的決定；3）建模的原則：選擇要創建什么模型，對如何動手解決問題以及如何形成解決方案，有著意義深遠的影響。每一種模型你可以在不同的精度級別上表示。最好的模型適于現實相聯系的。單個模型是不充分的。對每個重要的系統最好用一組幾乎獨立的模型去處理。1.5什么是對象？----通常一個對象代表一個實體，不管它是物理實體、概念實體還是軟件實體。----一個對象是具有明確界限并封裝了狀態和行為的統一體。----狀態主要表現為屬性和關聯。----行為主要表現為操作、方法和狀態機。1.6什么是模板類型？----根據模板類型中的其他元素定義一個新的元素。Stereotype構造型：屬于UML擴展機制之一，它允許用戶基于已存在的構造塊創建新的適應于用戶特定問題的構造塊。1.7面向對象的基本原則----抽象區別其他實體最本質的特征。----封裝向調用者隱藏了內部（封裝），調用者只能依賴接口實現調用。----模塊將復雜的整體分割成可以控制的小塊，以幫助人們理解復雜的系統。----繼承任何等級或排序都可以以樹形結構表示。1.8什么是類？類就是一系列（某一類）對象共享相同屬性、操作、關聯和語義描述。對象是類的實例。1.9什么是屬性屬性是類中具有名詞特性的參數，屬性描述了實例中可取值的范圍。1.10什么是操作操作能被任何類的實例調用執行、并完成某項實現的功能。1.11什么是多態？使用同一接口隱藏了不同的實現。多態（Polymorphism）在希臘語中意味著“擁有多種形式”。如繪圖，圖形可以是矩形、圓或曲線，等等。投資，可以是股票、債券或基金，等等。一個接口可能有很多實現，但每一種實現都必須滿足接口參數要求。有時，一個實現也可以滿足多個基本需求接口。如一個控制器能夠控制任何符合這個控制其接口規范的電視機。多態意味著用同一個名字來引用不同的方法。JAVA中提供兩種形式的多態：第一種可以通過子類對父類方法的覆蓋來實現運行時對態；第二種利用方法重載在同一個類中定義多個同名（但參數不同）的方法，實現編譯時多態。1.12什么是接口？1、接口的定義與作用：1）接口是用來描述類或組件提供的操作的集合。2）接口正規化了多態。接口消除了多態的神秘性。3）接口支持“即插即用”的結構。2、接口的表示方法：1）“棒棒糖”表示法（表示接口的存在）2）“類/模板”表示法（表示接口的詳情）1.13什么是包？《UML用戶手冊》：包package是“對元素進行分組的通用機制”。包是分組的通常手法，包可以包含其它模型元素。包可作為管理單元，使模型條理化。包是簡單的分組機制，沒有語義上的實例。所以包就沒有必要一定要需要實現，除非它表示一個目錄。1.14什么是子系統？1）子系統的定義和作用：子系統是包（包含其他模型元素）和類（擁有行為）的結合。實現定義在行為中的一個或多個接口。《UML用戶手冊》：子系統是“提供了一些特定行為的一組元素”。2）子系統組件：組件是設計的物理實現。子系統能夠表示設計中的一個組件。1.15什么是組件（構件）？在一個定義良好的系統框架中，宏觀的、可以替換的、獨立的系統功能。組件可以是：源代碼組件、實時運行組件、可被執行的組件。《UML用戶手冊》component組件：系統中遵從一組接口并提供其實現的物理的、可替換的部分。1.16什么是關聯？《UML用戶手冊》關聯association：是一種結構關系，它指明一個事物的對象到另一個事物的對象間的聯系。兩個或多個類的對象之間的聯系。一種結構化的聯系，制定了一個對象到另外一個對象的連接。1.17什么是多重性？一定數量的某個類的實例對應另外一個類的實例的數量的范圍。《UML用戶手冊》multiplicity多重性：對集合可能采用技術范圍的說明。1.18集合是什么？《UML用戶手冊》Aggregation聚合：關聯的一種特殊形式，它表示聚集（整體）和構件（部分）之間的“整體-部分”關系。《UML用戶手冊》組合compstion：聚合的一種形式，整體和部件之間具有很強的擁有關系和一致的生存期。1.19什么導航？《UML用戶手冊》Navigation導航：給定兩個類之間的一個簡單的、未加修飾的關聯，從一個類的對象能夠導航到另一個類的對象。除非另有指定，否則關聯的導航是雙向的。在圖形上，把一個關聯畫成一條實線，它可能有方向，偶爾還在其上有一個標記，而且它經常還含有諸如多重性和角色名這樣的修飾。UML有四種關系：依賴、關聯、泛化、實現。《UML用戶手冊》Dependency依賴：兩個事物之間的語義關系，其中一個事物（獨立事物）的改編將影響到另一個事物（依賴事物）。在圖形上，把一個依賴畫成一條可能有方向的虛線，偶爾還在其上有一個標記。1.20什么是一般化（泛化）？它們之間是這樣的關系：一個類（子類）共享另外一個類（父類）的結構或者行為。一個子類能夠從一個（單繼承）或者多個（多繼承）父類繼承。《UML用戶手冊》generalization泛化：一般/特殊關系，其中特殊元素（子類）的對象可以替換一般元素（父類）的對象。一般化（泛化）就是從子類中提取共性而形成父類；繼承則是子類在承接父類的職責和本質（屬于共性的關健的屬性、操作和關聯）的同時，將會產生屬于自己的、特殊的個性。1.21什么是實現？《UML用戶手冊》realization實現：類元之間的一種語義關系，其中一個類元描述一個規格說明，另一個類元保證實現這個規格說明。在兩種地方要遇到實現關系：一種是在接口和實現它們的類或構件之間；另一種是在用況和實現它們的協作之間。提示是什么？在圖像上增加一種注釋可以包含更多的信息。1.22本章小結面向對象的四個最基本原則是什么？分別簡短闡明一下。對象的概念是什么？類的概念是什么？他們的區別是什么？屬性的概念是什么？操作的概念是什么？多態的概念是什么？什么是包？什么是子系統？子系統怎么和包能夠關聯起來？又怎么和類關聯起來？UML語言中有那幾種類關系？他們的定義分別是什么？闡明面向對象的效果。什么是模板類型？第二章需求概述（1）（4學時）教授方式：講課討論2.1章節目標（教學目的及要求）1、描述了需求中使用的基本概念以及需求對分析和設計產生的影響。2、展示了作為分析和設計起點的需求產出品的閱讀以及解釋方法。教學內容2.2需求概述的內容（1）簡要介紹1、需求概述的內容（1）簡要介紹核心概念用例模型術語表補充說明檢查點列舉2、需求工作的目標包含:提供一種與客戶在系統功能方面進行溝通并達成共識的方式使開發者能夠更準確的理解系統的需求確定系統的邊界提供了對迭代過程中的技術內容進行計劃的基礎。為系統開發的成本估計提供一個基礎定義出系統與用戶之間的交互接口（交互界面—確定用戶的需求和目的）USDP：統一軟件開發過程3、需求的產出:用例模型：角色；用例；用例描述。術語表補充說明2.3需求概述的內容（2）核心概念1、需求概述的內容（2）簡要介紹核心概念用例模型術語表補充說明檢查點列舉2、系統行為是什么？系統行為是系統的活動和對輸入進行的響應方式–外界可見的并且可以測試的系統活動系統行為可以使用用例進行描述–用例描述了系統，環境以及系統和環境之間存在的關系。3、用例建模中的核心概念角色表示與系統交互的任何事物（可以是人—用戶、也可以是其他系統或設備）用例表示系統執行的一系列動作。這些動作產生對某一角色可見的結果。需求概述的內容（3）用例模型1、需求概述的內容（3）簡要介紹核心概念用例模型術語表補充說明檢查點列舉2、用例模型是什么？用例描述了系統的功能需求模型化表示了系統的功能（用例）和系統的環境（角色）。3、用例模型的優點是什么？交流在系統開發早期就可以明確最后提交產品的功能；確保雙方都對需求有準確的了解。標識確定系統與用戶群之間的接口需求。驗證確保開發團隊已完全理解了客戶需求。識別與系統交互的角色；界定系統邊界和功能；確保即將開的發系統是用戶所期望。4、用例描述用例名稱概述事件流關系活動圖用例圖特殊需求前置條件后置條件其他圖4、用例事件流一個正常的基本的路徑多個可選的路徑–正常的可選路徑–罕見的可選路徑–異常路徑5、場景是什么？場景是用例的一個實例。6、活動圖是什么？用例模型中的活動圖用來描述用例中發生的活動。活動圖必須是一個流程圖，需要能夠描述清楚系統的活動流程以及分支的時機。7、事件流當注冊管理員要求關閉注冊時，這個用例開始執行。1）首先系統檢查注冊用例是否在執行。如果正在執行，一條消息應該顯示給用戶，并且用例結束。如果注冊活動在執行，“關閉注冊”的活動是無法進行的。2）對于每個課程，系統需要檢查是否有一位教授已經申請教授，并且至少有三個學生選該門課。只有這兩個條件都滿足的話，系統才能夠提交這門課以安排課程表。2.5需求概述的內容（4）術語表1、需求概述的內容（4）簡要介紹核心概念用例模型詞匯表補充說明檢查點列舉1、詞匯表實例：1）選課系統詞匯表介紹這個文檔定義并解釋了問題域中專有的名詞，這些解釋可以幫助那些對問題領域不太熟悉的用例描述和其他項目文檔的閱讀者。通常情況下，這個文檔可以作為一個非正式的數據字典，用來記錄數據的定義。這樣可以讓用例的描述文檔和項目的其他文檔能夠將注意力更加集中到系統的功能上。2）詞匯定義詞匯表定義了選課系統中的核心概念。2-1）課程:學校提供的課程。2-2）開設課程：一個學期中學校開設的課程--在一個學期中這將會有若干相同的課程并行開授，你可以在其中選擇一個學習。時間的選擇需要視課程提供的時間而定。2-3）課程總表:大學所教授的所有課程的列表2.6需求概述的內容（5）補充說明功能可用性穩定性性能可維護性設計約束2.7需求概述的內容（6）檢查點列舉1、檢查點列舉:需求:用例模型用例模型描述的容易理解嗎？通過研究用例模型，一位客戶或開發者可以清楚的了解系統的功能和這些功能之間的聯系嗎？客戶所有的需要都被滿足了嗎？用例模型包含有一些多余的行為嗎？每個用例模型是否都分配到合適的包集合中了？2、檢查點列舉:需求:角色所有的角色都被識別出了嗎？每個角色是否均發生了至少一個用例？每個角色的職能是否單一？角色之間是否需要進一步的拆分和合并？是否存在兩個角色，在與同一用例交互時行使著相同的職能？角色的名稱是否直觀且含義清晰？用戶和客戶對名稱的含義的理解是否一致？3、檢查點列舉:需求:用例是否每個用例都至少涉及到了一個角色？是否每個用例都和其他用例是獨立的？是否有些用例中存在著類似的行為或事件流？每個用例的名字都是唯一，直觀并且意義足夠明確以免在以后階段發生混淆嗎？是否客戶和系統的用戶對用例的名稱和描述理解相同？4、檢查點列表:需求:用例描述用例的執行者是否明確？用例執行的目的是否明確？用例簡述是否正確描述了用例的功能用例事件流開始和結束的時機和方式是否明確角色和用例之間的交互序列是否滿足了用戶的期望？角色交互和信息交換是否明確？是否有用例過于復雜？5、檢查點列表:需求:詞匯表每一個詞匯的定義是否全是清晰和精確的？每一個詞匯是否都被使用在了某個用例的描述中？在角色和用例的描述中，每個詞匯的含義是否一致？2.8本章小結本章小結：需求總結需求的主要產出是什么？需求的產出有什么用途？用例模型是什么？角色是什么？用例是什么？列舉出用例屬性的一些例子用例和場景有何不同？附加說明是什么？包含什么內容？詞匯表是什么？包含什么內容？第三章分析和設計概述3.1章節目標1、理解分析和設計的核心術語、概念；2、了解分析和設計的實際過程，包括角色、工件和工作流程；3、解釋分析和設計的差異。3.2特定情景下的分析和設計分析和設計的目的是：將需求轉化為系統設計使系統具有更加健壯的架構是設計和實現環境相匹配，做性能設計商務規則為系統結構提供場景需求規則為分析和設計提供了基本輸入測試規則測試了在分析和設計階段的系統環境規則發展和維護了在分析階段使用的工件管理原則規劃整個項目和每一次迭代（迭代項目中）。3.3分析和設計概述輸入：USE-CASE模型（角色、用例、用例描述）、術語表和附加規范（補充說明）。產出：設計模型（作為源代碼抽象的模型）展開：設計活動圍繞架構的概念展開。架構優先：其可行性和正確性是早期設計迭代周期的主要關注點。通過抽象忽略其細節，展現其主要特征使之具體化。架構不僅為了開發好的設計模型，還將提高實現過程的質量。架構由架構文檔記錄。架構文檔不在這次課程范圍，但我們會討論其內容及如何解釋。3.4分析和設計綜述（1）核心概念從定義分析和設計工作流程的核心術語及概念開始。1、分析和設計對比（參看幻燈片）關注點不同：分析和設計的差別在于關注點和側重點。分析的目標：理解問題并建立一個可視化的分析模型，而不去考慮實現的技術細節。分析關注于把功能需求轉化為軟件中的概念，目的是得到系統中的對象，側重于行為的封裝。以便盡快轉入設計及其他階段。設計的目標：細化分析模型，開發一個設計模型，以便迅速過渡到編碼階段。在設計中，我們必須適應實現環境和分布環境。實現環境是開發者必須滿足的環境，它是分布環境中軟件的超集和硬件的子集。建模的目標：從一個和現實世界緊密類似的對象模型出發，找出更為普遍的解決方法。由此而創建模擬現實世界的模型，更為強大、能更簡單地解決問題。2、分析和設計并不是由下而上或由上而下的分析和設計并不是由下而上或由上而下的。用例從左側進入并定義一個中間層：分析類。定義的子系統移動到上部，定義的設計類移動到下部。分析可以是上到中、中到上、下到上地移動。不能說哪一個路徑更重要，而是必須覆蓋所有的路徑以保證系統的正確性。所有四種路徑同等重要，這就是由上到下或由下到上無法解決問題的原因。3、什么是架構？架構Architecture（體系結構）：一組關于下述問題的重要決定：軟件系統的組織方式，構成系統的模型元素和它們接口的選擇，以及由這些模型元素之間的協作所描述的行為；這些結構元素和行為元素如何進一步組成較大的系統，以及指導這種組織（這些元素和它們的接口、協作和組合）的結構風格。軟件體系結構不僅關注結構和行為，也關注使用關系、功能性、性能、彈性、復用、可理解性、經濟和技術約束與折中以及審美考慮。軟件架構包含：組成系統的結構元素和它們的接口；元素協作的特定行為；將結構元素和行為元素結合成一個大的子系統；體系結構風格支配了組織結構。架構可以是靜態的也可以是動態的。相同系統的架構應該是類似的（已用過的特殊類型）：體系結構=元素+形式+基本原理。基本原理決定一個好架構的核心部分。模式是將元素聚合為某種形式的指導方針。4、架構約束設計和實現架構包括一套整體設計的結論、規則或者設計約束和結構的模式。架構結論是最底層的結論，改變它將帶來巨大的影響。架構可以被看作一套核心設計結論的集合。架構是對系統的最初限制，這些限制往往也是最重要的。他們組成了軟件設計的最基礎的結論。架構為設計提供了一個框架，因此架構也被稱作戰略式的設計。一個系統架構師的工作就是消除非必須的工作。隨著對代碼的越發接近，這些工作就會被除去（架構限制著設計、設計限制著實現）。這樣做是非常有用的，因為在實現過程中，我們可以增加其他方面（例如，提高質量和性能）的工作。5、軟件架構：“4+1視圖”模型上面的圖表說明了Rational公司用來描述軟件架構的模型。不同的組織對架構有不同的看法。在一個指定的項目中，通常有許多投資人，他們對姚開發的系統都有它們自己的看法。我們的目標是為這些不同的投資人提供一個系統來滿足他們所關心的，而忽略一些其他的細節。為了滿足這些不同的需求，Rational公司定義了“4+1視圖”模型。一個架構視圖是對系統從特殊觀點或者優勢來進行簡單描述（或抽象），覆蓋特定的關注點，并忽略與這個關聯聯系不緊密的實體。視圖是模型的“片段”，而不是所有的系統都需要所有的視圖（例如，單一處理器：舍棄分布視圖；單一進程：舍棄過程視圖；小程序：舍棄實現視圖等）。一些項目可以記錄所有這些視圖，或者附加一些視圖。具體視圖的數量依賴所開發的系統。這些視圖中的每一個，以及用來代表他們的UML符號，將在以后的章節討論。3.5分析和設計綜述（2）分析和設計工作流程僅僅由開發者、活動和工件并不能組成一個進程。我們需要一種描述活動的方法，一些有價值的結果，以及開發者之間的交互結果。工作流程是一個活動序列，而且可以產生能夠看得見的價值。在UML術語中，工作流程可以用順序圖、交互圖或者活動圖來表示。我們使用RUP中的一些活動圖。對每一個核心工作流程，都有一個活動圖與之對應。這個圖說明了工作流程，根據工作流程的細節來描述的。這張幻燈片說明了分析和設計的工作流程。早期的“ElaborationPhase”階段關注為系統創建一個初始的架構（定義一個備選架構），來為主要的分析階段提供一個起始點。如果架構已經存在（可以從前期的迭代、項目、或者一個用程序的框架得來），工作的重點就變為細化架構，分析行為和創建一套初始化的元素來提供適當的行為（分析行為）。當初始化的元素定義完之后，它們就要被進一步細化。設計組件和設計實施組件將會產生一套組件，這套組件為了滿足系統需要提供了適當的行為。與此并列的是數據庫設計。結果是產出在實現階段進一步細化的一套初始化組件。1、分析和設計活動綜述在分析和設計中，我們從USE-CASE模型和設計階段的輔助規范著手，以作為源代碼抽象的設計模型的產出而結束。設計活動以架構概念為中心。在早期迭代設計中，這種架構的產出以及正確性是我們主要的關注點。架構是一個重要工具，使用它不但可以開發一個好的設計模型，而且可以提高系統開發過程中模塊的質量。本課程的關注點在設計行為。系統架構是的行為要討論，但是我們將更多地給出一些架構的結論。架構和設計都將在單獨的章節中展開。2、軟件架構師的責任軟件系統架構師的任務是在整個項目過程中領導和協調技術以及工件。軟件系統架構師為每一個架構視圖建立全面的結構：分解視圖、元素分組、以及這些主要分組間的接口。因此，與其他角色相比，軟件系統架構師的觀點決定著系統的廣度和深度。總的來說，軟件系統架構師必須是全面的、成熟的、具有快速掌握問題的豐富經驗、良好素質，缺少全部信息時的關鍵判斷。更專業地說，系統架構師或架構師團隊中的一員，必須具有以下技能：同時具有解決問題領域和軟件工程領域中對需求的徹底理解。如果一個團隊具有這些品質就可以在團隊中擴散，但至少得有一個軟件架構師可以提供一個項目全局性的看法。具有領導才能，以此在技術方面驅動不同的團隊，在壓力下做出關鍵的結論，并堅持這些結論。為了更有效，軟件系統架構師和項目經理必須緊密合作。軟件系統架構師領導技術問題，項目經理領導行政性問題。軟件系統架構師必須有權利在技術方面做出決定。具有交流能力，以此獲得信任，說服別人，激發別人以及指導別人。軟件系統架構師不能被規則所領導，而只需得到項目其他成員的同意。為了更加有效，軟件系統架構師必須在項目組中贏得其他人的尊重，包括項目經理、客戶、用戶團體及管理團隊。針對目標并且嚴格地以結果為前提。軟件系統架構師是項目中的技術驅動力量，而不是空想家或夢想家。一個成功的軟件系統架構師的職業生涯是在一系列不確定性和壓力下的并非最理想的決定。只有那些關注于必須做的事情的人才是項目中這種角色的成功者。3、設計師的責任設計師的任務是定義一個或幾個類的職責、操作、屬性、關聯，決定如何修改它們來滿足實現環境。而且設計是的任務可以為一個或更多的包指定職責，或者設計子系統，包含包或子系統中包括的所有的類。設計師必須具有扎實的應用知識，包括：Use-case建模技術；系統需求（Systemrequirements）；軟件設計技術，包括面向對象的分析和設計技術，統一建模語言；系統實現時所涉及的技術。附加的，設計師必須：理解軟件架構文檔中描述的系統架構4、分析和設計是Use-Case驅動的使用案例是一個系統的整個開發過程的基礎。優點：簡明、簡單，能為多數客戶理解；幫助實現不同模型的同步。使用案例是推薦用來組織需求的方法。取代將需求列出，用一種講述某人如何使用系統來組織它們。這樣做，你得到了一個更為全面和一致的需求。你可以更好地理解從用戶的觀點來討論需求的重要性。通常很難從一個傳統的對象系統的模型，說明一個系統是否按照預期的設想工作。這種情況的出現是由于在系統執行特定任務的時候缺少一個通用的線索。使用案例正是這種線索，因為它們定義了一個系統執行時的行為。使用案例不是“傳統”的面向對象的一部分，但它們的作用已經變得越來越重要，進一步強調的事實是使用案例是UML的一部分。5、什么是Use-Case實現根據對象的相互交互，一個Use-Case實現描述的是設計模型中一個指定的用例是如何實現的。一個Use-Case實現將Use-Case模型中的用例和設計模型中的類及關聯緊密聯系起來。一個Use-Case實現指出了那些類必須來實現一個Use-Case。在UML中，Use-Case實現是傳統的交互。一個交互的符號是包含一個交互的名字的省略符號。一個Use-Case實現的符號是交互符號的點線。在設計模型中的一個Use-Case實現可以追溯到Use-Case模型中的用例。關聯關系是從Use-Case的相互關聯中而來。通過UML工具，Use-Case的實現可以用很多表達交互關系環境的圖形來描述（實現Use-Case及其關系的類/對象-類圖），還有交互圖（這些類/對象是怎么完成用例的——協作圖和序列圖）。使用多少種類和多少數量的圖形是由項目究竟需要多少交互圖才能夠完整描述，和開發需要多少指導來決定的。6、迭代過程中的分析和設計本課程假定開發者使用迭代過程。記住每一次完成過程工作流程序列就叫做一次迭代。因此，從一個開發者的觀點看，軟件生命周期是連續迭代過程，一次迭代就是軟件開發的一個增量。在一個迭代分析和設計工作流程時，一個使用案例將是最基本的輸入工件。經過分析和設計工作流程中一連串的活動，開發團隊將創建一個聯合的Use-Case實現來描述一個特定的使用案例是如何實現的。3.6本章小結分析和設計階段的主要目的是什么？輸入和產出是什么？列舉并簡要描述一下架構的“4+1”視圖。分析和設計的區別是什么？什么是系統架構？第四章架構分析4.1章節目標解釋架構設計的目的，及其在生命周期的什么時期執行。說明一個典型的架構模式和一套分析機制，以及他們如何影響架構。說明用以支持架構決策的基本原理和需要考慮的事項。說明如何閱讀和理解架構設計的結果：架構層及其關系關鍵抽象概念分析機制章節目標在軟件架構上，清晰說明系統結構（包/構件），以及他們集成（相互作用的基本機制和模式）的方式。在架構分析中，進行了初步的工作，包括定義片/塊及其關系，并用依賴關系將這些片/塊組織成有明確界限的層。4.2工作環境中的架構分析架構分析是定義備選架構中的一個活動。架構模式和習慣用語取得一致。將片/塊組織成有明確界限的層。從需求中識別出分析類，以詳細描述架構。架構分析在精化階段早期進行，這項活動由架構設計師或架構租來進行。如果架構風險較低，架構分析可以跳過。4.3架構分析概述目的：定義一個備選架構定義系統的架構模式、關鍵機制和建模約定。定義重用策略。為策劃過程提供輸入。輸入工件：用例模型補充約規詞匯表設計模型參考架構前景文檔項目詳細指南軟件架構文檔生成工件：軟件架構文檔設計模型部署模型4.4架構分析步驟（1）核心概念1、核心概念定義子系統的高級結構確定分析機制確定關鍵抽象創建用例實現檢查點2、什么是架構：“4+1視圖”模式。邏輯視圖將在確定設計機制中詳細介紹。進程視圖將在運行時架構中討論。實施視圖不在分析與設計課程中討論3、什么是包？包是一種通用分組機制，用于將元素組成組。包是一種模型元素，它包含其它模型元素。包能被用于--組織并開發模型--作為一個配置管理的單元3、包關系：依賴包可以使用依賴關系來關聯另一個包。依賴的含義：--Supplier包的變化可能影響Client包，Client包必須重新編譯和測試。--Client包不能被獨立使用，因為它依賴Supplier包。4、避免循環依賴包的分層結構需要非循環的。如果出現循環依賴，可將循環依賴中的一個包，分解成兩個較小的包，來避免循環依賴。4.5架構分析步驟（2）定義子系統的高級結構在軟件開發生命周期的早期，確定建模約定很重要，項目中每個人都應當使用。建模約定確保了構架和設計的表現形式在跨團隊和迭代時是一致的。1、模式和框架模式：--提供在一個環境下共同問題的一個共同解決方案。分析/設計模式--提供一個狹窄范圍技術問題的一個解決方案。--提供一個解決方案的一部分，或難題的一部分。框架--確定解決問題的通用方法。--提供一個概要解決方案，其詳細內容可能是分析/設計模式。2、模式和框架的進一步說明模式是把來自經驗的知識系統化。模式提供了使用模型解決實際問題的優秀樣例，不論是你自己提出的模式還是使用他人的模式。框架是一個宏觀架構。框架提供了構件運行的環境。框架提供了基礎結構，如通信機制、分布機制、錯誤處理、事務支持，等等。允許構件以可預見的方式執行和共存。（見下頁J2EE架構示意圖）框架可以是持久性的，可以針對特定領域。比如SAP公司就有專門針對制造業和金融業的框架。框架在范圍和規模上與分析/設計模式不同，它允許在問題域缺少很多細節時給出的一個通用的、宏觀的解決方案或架構。在此基礎上的進一步工作，則需要應用不同的分析/設計模式使之進一步豐富和細化。3、什么是設計模式？設計模式是對一個共同設計問題的解決方案。--說明一個共同的設計問題。--說明對此問題的解決方案。--討論應用此模式的結果和評定比較。設計模式提供了重要成功設計的能力。設計模式被收集和編錄在許多出版物和媒介上。使用設計模式提高開發效率和可維護性，提供了好的設計方法、設計用語和設計樣例。應當熟悉一些通用的設計模式及其處理的問題和處理方法。設計模式在UML中作為參數化協作杯模型化，它包括結構側重面和行為側重面。結構側重面是類，其實例實現模式及其關系（靜態視圖）。行為側重面說明實例如何協作（通常是發送消息）以實現模式（動態視圖）。參數化寫作時協作的一個模版。模版參數通常被用于為一個特定用途而調整協作。這些參數不一定是抽象集，這取決于它們是如何在設計中應用的。4、什么是架構模式架構模式表達了對軟件系統基礎結構的一個組織大綱。它提供了一套預定義的框架模式，詳細說明了他們的職責，并包括組織他們之間關系的規則和指南等。層：在層模式中應用被分為不同的抽象層次。層的范圍從高端的特定應用層到低端的實施/特定技術層。模型-視圖-控制器：在MVC模式中，應用被分為三個部分：模型、視圖和控制器。管道和過濾器：在管道和過濾器模式中，數據在流動中進行處理，通過管道從一個過濾器到另一個過濾器。每個過濾器是一個處理步驟。黑板：在黑板模式中獨立的專業應用協作產生一個解決方案，工作在一個共同數據結構上。架構模式可以在一起工作，即一個實際的軟件架構可以同時應用多個架構模式。上面列出的架構模式包含了系統特征、性能特征以及進程和分布架構。5、典型分層方法應用程序層；特定業務層；中間件層；系統軟件層。6、架構模式：層環境：需要分解的大系統。問題：必須在不同抽象層處理問題的系統，如硬件控制問題；常見服務問題。編寫能處理所有層次上問題的垂直構件完全沒有必要，甚至不得不在不同構件中處理。影響：構件的某些部分是可以替換的。構件中的變化不會傳遞（波動）。相似的職責應歸為一組。構件大小----復雜構件應進行必要的分解。解決方案：將系統分為構件組，并使構件組形成層疊結構。使上層只使用下層（絕不使用上層）提供的服務。盡量不使用非緊鄰下層提供的服務（不跳層使用服務，除非中間件層添加通過構件）。嚴格的分層架構規定設計元素（類、構件、包、子系統）只能使用下層提供的服務。服務包括事務處理、出錯處理、數據庫訪問等等。7、分層考慮事項層常常用于不同種類服務間縫中概念邊界，提供有益的抽象，使設計更易于理解。通常只有一個應用程序層。即，領域層的數量取決于問題域和解決空間的復雜性。如果領域中已經有先前構建的系統，有由較小的互操作系統構成的復雜系統，和/或各設計團隊之間尤其需要共享信息的系統。為明確起見，可以將業務專用層分成幾個層。在架構分析中，我們關注于較高層（應用程序和業務專用層）。較低層（基礎層和廠商專用層）將在包含已有設計元素中詳細說明。8、架構層建模架構層可以使用構造型包建模。可在Rose中用《layer》構造型包來表示。層說明可以放在包規格說明的document字段中。9、模型的高層結構上面的例子包括了課程注冊系統的應用程序和業務專用層。應用程序層包含了專用于課程注冊系統的設計元素。我們期望多個應用程序共享一些核心抽象和公共服務。這些已經封裝入業務服務層，應用程序是可以訪問的。業務服務層包含的專用業務元素，可用于多個應用程序。4.6架構分析步驟（3）確定分析機制架構應當是簡單的，但不應過分簡單。它應當通過標準抽象和機制來提供標準行為。因而，設計一個軟件框架的關鍵因素就是機制的定義和選擇。設計員通過機制給對象以“生命”。在架構分析中，待開發軟件的分析機制是十分重要的。分析機制集中和定位在系統的非功能需求上（也就是需要永久性、可靠性和性能），并將對非功能需求的支撐直接并入架構。分析機制被用于在分析過程中向設計人員提供復雜行為的簡短表示，從而減少分析的復雜性并提高分析的一致性。通過這些機制，可以使分析工作集中于將功能性需求轉換成軟件概念，而不必細究那些需要用來支持功能但卻不是功能核心的相對復雜的行為。1、什么是分析機制？為了更好地理解什么是分析機制，我們必須去理解什么是架構機制。架構機制是一項關于常規標準、方針和實踐的戰略決策。它是一個項目應當標準化的課題的實現。項目的每個人都應當以相同的方式使用這些概念，并重用相同的機制執行操作。一個架構機制描述了針對一個經常發生的問題的一種通用解決方案。它可能是結構模式、行為模式，或者兩種都是。架構機制是系統所要求的功能和如何實現此功能間的一個重要的組合部分。對架構機制的支持需要構置在架構上。架構機制被架構師所調整。架構師選擇機制，通過構造和集成它們以進行確認，驗證它們的工作，并持續將它們加入系統設計的其余部分。2、架構機制的三個種類。有三種架構機制：分析機制（概念）；設計機制（具體）；實施機制（實際）。它們之間的唯一差別就是精細程度。分析機制以與實現無關的方式捕捉解決方案的關鍵部分。它們或者提供一個領域相關類或者構件的特定行為，或者符合類和/或構件間協作的實現。它們可能作為一個框架被實現。例如永久性、進程間通信、錯誤或故障處理、通知和消息的傳遞機制，其例子不勝枚舉。設計機制更具體一些。它假定一些實施環境的一些細節，但并不約束于一個特定實施（一個實施機制）。實施機制詳細說明了機制的準確實現。實施機制一定是一個確定技術，影響它的是實施語言、銷售商或其它因素。在一個設計機制中，會選擇一些專用技術（如數據庫）。然而在一個實施機制中，將選擇一些更專用的技術（如Oracle或Sybase）。對分析機制實施的全部策略必須被構置在架構中。在討論設計和實施機制時，將討論有關確定設計機制的更多內容。3、為什么使用分析機制？分析機制代表常見問題的解決模式。這些機制可能表示結構模式或行為模式，也可能表示這兩者。它們用于在分析過程中向設計人員提供復雜行為的簡短表示，從而減少分析的復雜性并提高分析的一致性。分析機制主要用于在架構的中層或低層作為更復雜技術的“占位符”。當在架構機制中將分析機制用作“占位符”時，可以盡量避免機制行為的細節分散架構工作的重點。通過這些機制，可以使分析工作集中于將功能性需求轉換成軟件概念，而不必細究那些需要用來支持功能但卻不是功能核心的相對的復雜性。分析機制通常源于對一個或多個架構或分析模式的實例化。永久性提供了分析機制的例子。一個永久性對象是在創建它的程序消亡后仍然邏輯存在的對象。在對象生存期，用例、進程生存期或系統關閉和啟動等方面的需要確定了在對象永久性方面的需要。永久性是一種特別復雜的機制。在分析過程中，我們不希望因細究如何達到永久性而分散工作的重點。這就導致了“永久性”分析機制的出現。它使我們在談及永久性對象和分析永久性機制的需求時，不必考慮永久性機制的確切功能或工作方式。分析機制通常與問題與無關（但不一定總是無關），而屬于“計算機科學”的概念。所以，它們通常占據架構的中層及更低層。它們為與領域相關的類或構件提供特定的行為，或者對應于類和構件之間、類與類之間、或構件與構件之間協作關系的實施。4、分析機制舉例分析機制或者提供一個領域相關類或構件的特定行為，或者符合類和/或構件間協作的實現。分析機制的一些例子在這張幻燈片上。這個列表并不詳盡。通信機制的例子包括進程間通信（IPC）和節點間通信（遠程進程或PRC）.PRC包括通信和分布。當一個人以“模式”進行通信時，機制或許更容易討論。因此進程間通行模式與分布模式進行交互、產生PRC模式。這個過程給我們提供了一種實現遠程IPC的方式。5、分析機制特征舉例分析機制特性分析一些系統的非功能性需求。永久性：對于其實例可能會具有永久性的所有類，我們需要確定：粒度：保持永久性所需要的對象大小的范圍。容量：保持永久性所需要的對象數量。持續時間：所需的對象保留時間。訪問機制：如何唯一的地標識并檢索給定對象。訪問頻率：對象是否大致保持很定不變？它們是否經常更新？可靠性：對象是否應當在進程、處理器或者整個系統崩潰后繼續存在？進程間通信：有些模型元素需要在與其他進程或線程中執行的對象、構件或服務進行通信，對于所有這些模型元素，我們需要確定：反應時間：進程之間的通信速度必須是多快？同步性：通信同步。消息大小：指定大小范圍可能比單個大小值更恰當。協議：控制流量、緩存及其他。安全性：數據粒度：包級、類級、屬性級。用戶粒度：單一用戶、角色/組。安全規則：基于數據值，和基于數據算法，以及基于用戶數據和數據算法。授權：讀、寫、創建、刪除，執行其它操作。6、說明分析機制說明分析機制的過程如下：畫一張用戶類到分析機制的圖。將所有分析機制集中在一張列表上。相同的分析機制可能會以不同的名字出現，跨越不同的用例實現，或跨越不同的設計人員。舉例來說：storage、persistency、database和repository都可以參照一個永久性機制。Inter-process、communication、messagepassing或remoteinvocation都可以參照一個進程間通信機制。確定分析機制的特性。識別潛在設計、確定用于證明每個分析機制合格的關鍵特性。7、例子：課程注冊分析機制永久性。分布。安全性。遺留接口。4.7架構分析步驟（4）確定關鍵抽象概念確定問題域的關鍵抽象。建立“詞匯表”。關鍵抽象是系統必須處理的核心概念。例子：在課程注冊系統中教授學生課程課程目錄課程安排4.8架構分析步驟（5）創建用例實現一個用例實現代表了一個用例的設計觀點（思路、思想）。它是一個組織模型元素，用于將一定數量的工件進行分組。用例與用例實現是分離的，因此你可以獨立地管理每一個，并更改用例設計，而不會影響到用例的基線。對于用例模型內的每個用例，帶有“實現”構造型的依賴關系的設計模型中都存在一個用例實現。1、復審：什么事用例實現？一個用例實現是設計模型中一個特殊用例的表達式。它描述了協作對象方面的用例。一個用例實現將用例模型的用例和設計模型聯系在一起。一個用例實現說明了每個用例必須用那些類來實現。在UML中，用例實現就是構造型協作。協作的符號是一個包含協作名字的橢圓。用例實現的符號是協作符號的虛線版。設計模型中的一個用例實現可被追蹤到用例模型中的一個用例。一個實現關系就是從用例實現畫到它實現的用例的帶箭頭的虛線。在UML中，一個用例實現可以使用一組圖（順序圖、協作圖和類圖）來表示，這些圖模擬協作（實現用例及它們關系的類/對象----類圖）的環境，和它們的協作交互（這些類/對象是如何相互影響以執行用例的----協作圖和順序圖）。要使用的這些圖的數量和類型，取決于需要什么來提供一個協作和項目應用指南。2、用例實現的價值：用例形成了大多數早期分析和設計工作的主要集中點。為了能夠在需求中心活動和設計中心活動間轉換，用例實現扮演了橋梁的角色，提供了一種對設計模型到用例模型的逆行追蹤行為的方式，也組織了圍繞用例概念的設計模型中的協作。用例模型中的每個用例，都在設計模型中創建一個用例實現。用例實現的名稱應當與其關聯的用例一樣，并且應當建立從用例實現到其關聯用例的一個追蹤依賴。4.9架構分析步驟（6）檢查點4.10本章總結

第五章用例分析5.1章節目標1、用例分析的目的；何時執行？2、確定執行用例事件流的類。3、將用例行為分配給類，確定這些類的職責。4、開發用例實現，在所確定類的實例間構建協作模型。在用例分析中，首先確定初始類----分析類。將職責分配給它們，注意架構機制的使用。用例分析活動開發的關鍵模型元素：分析類和初始用例實現，將在后續的分析設計活動中被改進。5.2工具環境中的用例分析用例分析––––分析行為。初始架構已經定義，和軟件需求一起作為輸入指導和服務于用例分析活動。構架層及其職責，可能影響分析類的定義和職責分配。用例實現說明分析如何協作，以執行用例。用例實現將在用例設計模型中改進。5.3用例分析概述用例分析有設計員執行，每個用例實現進行一次迭代。目的：確定執行用例事件流的類。將用例行為分配給這些類。確定類的職責、屬性和關聯。記錄架構機制的使用情況。5.4用例分析步驟以上是用例分析的步驟。復審用例描述，發掘足夠多的細節。研究用例事件流，確定分析類，將用例職責分配給分析類，模型化分析類間的關系。將分析類的職責文檔化。確保以開發的分析模型是一致的。5.5用例分析步驟（1）補充用例說明補充用例描述5.6用例分析步驟（2-1）對每一個用例實現從用例行為中查找類對需求更詳細描述，并文檔化，以確定候選分析類。從用例中查找行為，是為了確定備選的分析類（行為模型元素）。1、復審：類強調相關性。排除其它特性。一個類由三部分組成：類名；屬性（結構）；操作（行為）。2、復審：用例實現理解用例實現中類的職責、角色以及如何交互，用以改進類的職責和接口。3、分析類：達成執行的第一步尋找分析類的候選集是系統轉換的第一步。分析類代表早期的概念模型，它將不斷被改進。分析類是“原型類”，其本質是“行為族”，經過改進和組合形成分離類、合并類、構件或子系統。4、從用例行為中查找類從三種角度識別類：系統與角色的邊界（邊界類）；系統使用信息（實體類）；系統的控制邏輯（控制類）。5、什么是分析類分析類是系統對象模型的“第一稿”，主要處理功能需求。三種類型：邊界類；實體類；控制類。6、什么是邊界類邊界類是接口和系統外部事物的中間體。通常由三種邊界類：用戶界面類；系統接口類；設備接口類。初步建議：每對角色/用例考慮一個邊界類。7、邊界類角色邊界類用于對系統環境與其內部運作之間的交互進行建模的類。邊界類對系統中依賴于環境的那些部分進行建模。邊界類用于隔離外部環境與內部機制之間的相互影響。邊界類的生命周期長于或等于用例實例的生命周期。8、查找邊界類考慮外部事件的來源，確保可檢測。初步識別建議：每對角色/用例一個邊界類（以后可以考慮刪節或合并）。9、指南：邊界類（關注職責、不究細節）不必注重細節考慮。用戶界面類：關注展示給用戶的信息；不必注重界面細節。系統和設備接口：關注必須定義的協議，不關注協議如何實現；可直接從接口定義派生。10、什么是實體類？系統的關鍵抽象。實體類顯示了系統的邏輯樹結構，提供了另一個了解系統的視點，有助于理解系統為用戶提供的服務內容。發現實體類：詞匯表（需求階段）；業務領域模型（業務建模）；用例事件流（需求階段）；關鍵抽象（架構分析）；行為分析（用例分析）。11、一個實體類角色實體類通常表示了系統的永久信息存儲。實體類的主要職責是存儲和管理系統中的信息。實體對象通常是系統的、甚至超系統范圍的，而不是專屬于某個用例。實體對象獨立于環境（角色）。12、什么是控制類？用例行為協調器：如事物管理，資源協調，出錯處理。控制類有效地將邊界對象和實體對象分開，讓系統更能適應邊界內的變更。控制類還將用例特有行為與實體對象分開，提高實體對象的復用性。控制類提供的行為，有如下特點：------獨立與環境。------確定用例的控制邏輯（事件順序）和事務。------幾乎不因實體結構或行為變更而變更。------協調實體類之間的行為。------執行方式具有多態性（事件流具有多種狀態）。初始確定控制類，每個用例只能創建一個控制類，進一步分析時發現更多用例的共性時，再增加、刪除或合并使用控制類。13、一個控制類角色（起的作用、擔任的任務）一個控制類是用于對一個或多個用例所特有的控制行為進行建模的類。控制對象控制其它對象、協調它們的行為。控制類封裝了用例的特有行為。控制類能表示系統動態行為，從處理主要任務和控制流的角度，幫助理解系統。系統執行用例時，產生控制對象，通常在用例執行完畢時控制對象消亡。15、總結：分析類每個用例實現都有一個或多個類圖與它們的關系一起描述其參與類。這些圖有助于確保用例實現中跨子系統邊界的一致性。這樣的類圖被稱為“參與類視圖”：ViewofParticipatingClasses(VOPC)。5.7用例分析步驟（2-2）對每一個用例實現將用例行為分配給類“將用例行為分配給類”的目的是：按照協作分析類表述用例行為。確定分析類的職責。1、將用例行為分配給類通過用例事件流，確定為必要行為負責的分析類，準確給出被應用的時間。交互圖用角色來顯示于系統的交互，若有多個角色，將它們保持在圖的外圍。2、指南：將職責分配到類邊界類：接口；控制類：事件流；實體類：永久性數據。那個類擁有執行職責的數據？----一個類擁有，將職責放在這個類；----多個類擁有，則：將職責交給一個類，并對其它類的增加一個關系（OO原則：數據和操作在一起）；創建一個新類，將職責交給它，并對需要執行職責類增加關系；將職責發起那個在控制類，并對需要執行職責類增加關系。注意：增加關系必須考慮模型的全面影響；盡可能重用已有的類，確認沒有近似職責的類時，才創建新類。3、序列圖剖析按時間順序描述對象間的交互（用“生命線”和消息顯示）。4、協作圖剖析通過對象間的連接（關系）和相互發送消息，來顯示參與交互的對象。。對象間的實線表示連接，通過連接實現交互或導航。消息使對象間的通信，它傳達信息并期望活動隨之發生。在連接旁帶有標記的箭頭表示消息，箭頭的編號表示消息的順序。用消息指向的目標對象的操作代替消息的名稱，表明消息將會激發的操作。5、一個協作圖并不充分將大多數事件流模型化，確保參與類操作的所有需求都被確定。從最通用和最重要的事件流（基礎流）開始，然后說明變體（如異常流）。常見的異常流：出錯處理；超時處理；錯誤輸入處理等。可選流：系統下一步做什么；后續事件流依賴于存儲的屬性值或關系；后續事件流依賴于處理數據的類型。6、協作圖VS.序列圖兩者表達相似的信息，以不同的方式顯示；可捕捉用例事件流語義，幫助確定對象、類、接口和職責；幫助確認架構。協作圖強調一組對象結構上的協作，提供了關系模式和控制更清晰的圖畫，有利于理解給定對象的所有影響，更適合于過程設計。序列圖顯示消息的順序，更適合實時規約和復雜場景。時間維度更易理解、操作和參數更易展示、易于管理大量對象。序列圖和協作圖都允許捕捉用例事件流的語義；幫助確定對象、類、接口和職責；幫助確認構架。**************************************************2007-4-55.8用例分析步驟（3-1）對每一個得到的分析類說明職責此時，分析類已經確定，職責也已分配。說明分析類的職責。將分析類的內容文檔化。1、說明職責對象可執行的操作。對象保留并提供給其它對象的知識。職責從消息中得到。類職責分析可用下面兩種方式之一文檔化：命名約定；文本描述。2、總結分析類每個用例實現都有一個或多個類圖與它們的關系一起描述其參與類。這些圖有助于確保用例實現中跨子系統邊界的一致性。這樣的類圖被稱為“參與類視圖”：ViewofParticipatingClasses(VOPC)。3、維護一致性，期待什么？一個類存在互不相干的職責時，可將其分成兩個或多個類。幾個類有相似職責時，合并它們。只有一項職責的類，應對其必要性進行驗證。類發生變更，必須更新交互圖。5.9用例分析步驟（3-2）對每一個得到的分析類說明屬性與關聯關聯：說明分析類依賴的其它類。說明該類必須了解的其它類中的事件。屬性：說明分析類負責維護的信息。1、復審：什么是屬性？屬性被用來存儲信息，它們是沒有職責的原子事物。屬性應當是名詞；屬性類型來源于領域。2、查找屬性可能的屬性來源：領域知識；需求；詞匯表；業務模型；領域模型。信息本身才是重要的，而不是它的位置。如果信息有復雜行為，或被多個類共享，此時應將信息作為一個分離類被模型化。3、什么是關聯？關聯表示不同類的對象之間的結構，它在一段時間內將多個類的實例連接在一起。4、查找關系協作圖中相互連接的對象或類，存在關聯。自反關聯，即遞歸關聯。5、什么是聚合？聚合是一種特殊的關聯，它表明了“整體/部分”的關系。6、關聯或聚合？當“部分”游離于“整體”時，整體顯得不完全時才使用聚合。當類與類之間的關系并非明顯的“整體/部分”關系時，用關聯，不用聚合。猶豫不決時，用關聯、不用聚合。關聯還是聚合，與建模的問題與有關。如整車經銷和零配件經銷的車和門。7、什么是角色（起的作用、擔任的任務）？一個類在關聯中承擔的“任務”，即該類在關聯中扮演的角色。8、復審：多重性（第一章翻譯為“多樣性”）關聯類兩端可關聯對象數量的描述。9、多重性意味著什么？一個對象可以擁有另一個對象關系數量的上限和下限。為0的下限說明這個關系可選的，反之則是必須的。*說明數量是未知的。10、例子：多重關聯兩個類之間可以有多個關聯，但應當表示不同的關系和擔任不同的角色（職務）；而不是僅僅引起不同的操作。如果兩個類之間有多個關聯，則必須分別命名，以示區別和說明。多重關聯必須仔細檢查；一個類的一個實例與另一個類的多個分離實例連接，多重關聯才是有效的。5.10用例分析步驟（3-3）對每一個得到的分析類限定分析機制限定分析機制的目的：確定類使用的分析機制（如果有的話）；提供更多關于類應用分析機制的信息。對每一個分析機制，應限定其特性、給定其適用范圍、指出其不確定性。分析機制的特性往往并不十分精確，但很有價值，應當與類一起文檔化。1、復審：為什么使用分析機制？減少分析的復雜性，提高分析的一致性。分析機制通常與問題領域無關（并不總是無關），屬于“計算機科學”的概念。通常占據架構的中低層。如永久性、進程間通信、出錯或故障處理、消息傳遞等處理機制。2、說明分析機制在架構分析中，確定和說明分析機制。方法：將所有分析機制收集在一張列表上；畫一張類和分析機制圖；確定分析機制的特性。5.11用例分析步驟（4）統一分析類現在必須復審我們的工作，確保轉到構架活動前，盡可能地完全和一致。統一分析類的目的是確保每個分析類表示一個單一的、明確定義的概念，而不會出現職責重疊。1、統一分析類過濾分析類，確保創建數量最小的新概念。不同的用例將貢獻給（使用）相同的類。一個類可參與多個（任意數量）用例。所以，必須檢查每個類的一致性。合并行為相似或表現相同的類。合并說明相同屬性的實體類，即使其行為不同；聚合合并類的行為。更新類和更新用例的“補充”說明同步。更新需求則應受控，因為需求是與客戶的契約，任何變化都必須驗證和控制。2、評估“用例分析”結果驗證分析類是否滿足系統的功能需求。驗證分析類及其職責，是否與它們支持的協作一致。5.12用例分析步驟（5）檢查點1、檢查點：分析類類是合理的嗎？每個類名都清楚地反映了它所扮演的角色了嗎？類是否表示了一個單一的、明確定義的抽象？所有屬性和職責在功能上是連接在一起的嗎（任何屬性和關系冗余，或不被用例實現需要，則應刪除之）？類提供了必要的（用例實現和其它類要求的）行為了嗎？類應當滿足需求規格說明書中，對類的所有需求。2、檢查點：用例實現所有主流和/或子流，包括異常流都已經被處理了嗎？所有的對象都已經被發現了嗎？所有行為都已經被明確分配給參與對象了嗎？行為已經被分配到正確的對象上了嗎？有幾個交互圖時，它們的關系是清洗和一致的嗎？5.13本章總結用例分析的目的是什么？什么是分析類？說出三種鉤造型的名稱，并描述它們。什么是用例實現？描述分配職責給分析類的一些注意事項。用例分析期間，應當產生多少交互圖？第六章確定設計元素6.1章節目標1、說明確定設計元素的目的，及其在生命周期何處執行。2、對分析類的交互進行分析，并確定設計模型元素：1）設計類2）子系統3）子系統接口確定設計元素執行了什么，但不描述執行過程是怎樣實現的。通過理解用以支持構架決策的基本原理、考慮事項和約束構架設計完成的框架，進而理解系統構架。6.2在環境中確定設計元素確定設計元素是改進構架過程（工作流）的一個活動。架構分析過程的活動中定義了系統的層（集中于上層）；用例分析中，分析了需求和系統行為，并將職責分配到類（分析類）。確定設計元素過程中，分析類將被改進成設計元素（設計類、子系統和子系統接口）。用例分析關心“做什么”；架構活動關心“怎么做”（設計）；構架就是選擇。6.3確定設計元素概述目的：對分析類的交互進行分析，以確定設計元素（設計類、子系統和子系統接口）。輸入：補充約規；項目詳細指南；軟件構架文檔；分析類；分析模型；設計模型。輸出：設計模型元素----類；包；子系統。6.4確定設計元素步驟本章（確定設計元素）將要進行的活動：確定類和子系統；確定子系統接口；更新設計模型結構；檢查點。6.5確定設計元素步驟（1）確定類和子系統確定類和子系統的目的是改進分析類，使之成為適當的設計元素。分析類將可能被擴充、推倒、合并，甚至刪除；很少在設計過程中保持不變。1、從分析類到設計元素分析類將被改進為設計元素：比如設計類或子系統。決定哪個分析“類”是真正的類，哪些是子系統，哪些是既存的構件，根本不需要再進行“設計”。創建了設計類和子系統必須命名并簡短描述，原始分析類的職責應當轉移到新創建的子系統。已經確定的設計機制應當被連接到設計元素。2、確定設計類如果分析類是簡單的，并已經表示了一個簡單邏輯抽象，則可以直接一對一地影射為一個設計類。通常實體類可以在設計過程中保持相對完整。一般而言，分析類和設計元素之間有一個多對多的映射。比如，一個分析類可以成為設計模型中的：一個簡單類；一個類的一部分；一個聚合類（聚合中的部分可能沒有被明確模型化）；同一個類繼承而來的組類；一組功能相關的類（例如，一個包）；一個子系統；一個關系。分析類間的一個關系，可以設計成設計模型中的一個類。一個分析類部分可以被硬件實現，而不必在設計模型中建模。分析類也可以被映射為以上的任何組合。3、復審：包和類什么是類？什么是包？4、將包中的設計類分組封裝標準可基于不同因素：配置單元（提交單元）；開發隊伍中的資源分配（子項目）；反映用戶類型（子系統）；表示系統使用的既存產品和服務（子系統）。5、封裝技巧：邊界類如果系統接口可能進行相當大的更改，邊界類應被放置在一個或多個單獨的包中。一旦更改，將只會影響這些包，而不致波及其它。如果接口不會有較大更改，則應將邊界類與功能相關的實體類和控制類放置在一起。如果實體類和控制類變化，就很容易看出哪些邊界類受影響。6、封裝技巧：功能相關類確定功能是否相關類的標準：----一個類的行為和/或結構發生變化，使得另一個類必須相應地變化。----一個類的刪除，影響其他類。----兩個對象進行大量的消息交互，或以復雜的方式通信（交互），這兩個對象就可能在功能上相關。----如果某個邊界類的功能是顯示一個特定的實體類，這個邊界類就可能與該實體類功能相關。----如果兩個類與同一個actor交互，或受到同一個actor變更的影響，這兩個類就可能功能相關。----兩個類之間存在某些關系。----一個類創建另一個類的實例。確定何時不應將兩個類放在同一個包中的標準：----與不同actor相關的兩個類，不應放在同一個包中。----一個可選類和一個必選類，不應放在同一個包中。7、包依賴關系：包元素的可見性包中元素的可見性與類的屬性和操作的可見性相同：允許其它包（或類）訪問該包（或類）元素。（可見性即可訪問性）UML定義了三種可見性：----Public （公共）：符號：+，外部均可訪問。----Protected（保護）：符號：#，可以被其擁有包，以及從其擁有包繼承的包所訪問。----Private （私有）：符號：-，只能被其擁有包中的類所訪問。一個包的公共元素組成了包的接口。包的依賴關系就是對包公共元素的依賴關系。包的可見性提供了對OO封裝原則的支持。8、包耦合度：提示不應進行交叉耦合（相互依賴）包的依賴只能指向同層或下層，不能指向高層。通常，不能跳層依賴，除非依賴行為在所有層之間都是共通的，或僅用于簡化各層之間的傳遞操作調用。包不應依賴子系統，而只能依賴其它包或接口。9、復審：子系統和接口子系統是同時具有包（可包含其它元素）和類（具有行為）的語義的模型元素，用帶有《》標記的包來表示，它將實現定義其行為的一個或多個接口。接口是一個模型元素，它確定了有一個分類器（類、子系統或構件）提供的一組行為（一組操作）。實現是兩個分類器之間的語義關系，一個分類器服務于其它分類器同意承擔的契約。接口是從一個包的公共類到外部（通過包含這個包的子系統）的一個規范的抽象。外部只能通過接口和子系統通信，子系統也只能通過接口接受外部信息并將響應結果傳遞到外部。子系統中所有類都是私有的，不能從外部直接訪問。10、子系統和接口（續）接口封裝了子系統的實現細節，并將其與構架的其余部分隔離開來。接口所確定的操作被子系統所包含的一個或多個元素實現。接口提供了實現它的分類器必須支持的行為族。接口和實現的分離，例證了OO概念的模塊性和封裝性。（和抽象類不同，接口不提供缺省行為，所以接口不是抽象類）。一個接口，可以被一個或多個子系統實現。實現統一接口的子系統可以互換。這樣，只要接口保持不變，子系統的內容和內部行為可以完全自由地更改。11、包與子系統對比子系統： 包：----提供行為（通過接口）。 ----不一定提供行為。----完全封裝其行為。 ----不一定完全封裝其行為。----易于替代。 ----不完全封裝就不易替代。12、子系統使用方法子系統可被用來將系統劃分成若干部分，這些部分可以是：----被定制、被配置、或被提交----被開發，只要接口保持不變----被部署，跨越一組分布式計算節點----被修改，而不破壞系統的其它部分子系統可被用于：----將系統劃分成單元，其中可以提供對關鍵資源的受限安全性----表示設計中既存產品或外部系統（例如，構件）13、確定子系統：提示查看對象（類）協作：如果一組協作類僅僅相互協作就可以產生明確定義的結果集，那么就將它們封裝在一個子系統中。查看可選性：如果協作建模的行為，可以被刪除、升級、或選擇替代的特性，那么就將它們封裝在一個子系統中。查看系統的用戶界面（用戶接口）：創建“水平”子系統（邊界類和相關實體類在不同的子系統中）或“垂直”子系統（邊界類和相關實體類在同一個子系統中），取決于用戶界面和實體類的耦合度。查看主角（actor）：使用不同的actor劃分功能，因為每個actor都可以獨立地修改需求。查看類之間的耦合和聚合：將高度耦合的類組成子系統，沿著弱耦合線進行分離。查看替代：一個分離子系統的一個特殊性能的不同級別服務（例如高、中、低），它們實現同一個接口。查看分布：如果特殊的功能必須存在于一個特殊節點，確保子系統功能映射在一個單一的節點。查看揮發度：你應盡量把你期望修改部分封裝在同一個（或盡可能少）的子系統中。14、候選子系統可能發展為子系統的分析類：----提供復雜服務和/或程序的類----金融應用軟件中的信用或風險評估引擎----商業應用軟件中基于規則的評估引擎----大多數應用軟件中的安全授權服務----邊界類，包括用戶界面和外部系統接口設計中的既存產品或外部系統（例如，構件），系統所使用的可在一個子系統中表示的產品包括：----通信軟件（中間件，COM/CORBA）----數據庫訪問支持（RDBMS）----類型和數據結構（堆棧、列表、隊列）----通用程序（數學庫——算法庫）----專業應用軟件產品（計費系統、日程安排系統）接口（提供了接口的子系統）和實現之間必要的解偶。15、確定子系統如果分析類相當復雜，其行為不能由單個類獨自承擔，應將該分析類映射到設計子系統。使用設計子系統來封裝這些行為，客戶不必知道子系統的內部設計。可以首先確定子系統的接口，而其接口實施的設計細節則可在子系統設計階段進行。是否要將某些事物發展成一個子系統，常常由架構師的知識和經驗所決定。6.6確定設計元素步驟（2）確定子系統接口接口通常定義子系統的操作集。接口就是子系統行為的聲明，它將這些行為在子系統內的實現分離，從而完成對子系統的封裝。1、確定接口確定子系統，首先必須確定其職責。基于子系統的職責來確定其接口。將職責分組，每組作為一個候選接口。為每個職責確定一個操作、及其使用參數和返回值。分析候選接口、職責和操作，尋找相似點、重新組成接口，并盡可能復用現有接口。定義接口依賴關系。將接口映射到子系統：建立子系統和接口間的實現關系。將接口打包：獨立于子系統對接口進行管理和控制，依照其職責劃分接口。2、接口指南接口名：名稱簡潔、反映接口在系統中的作用。接口描述：說明接口的職責。操作定義：每個接口應提供一個唯一的、定義明確的操作集；操作名稱應反映操作結果；說明操作什么、以及所有參數（包括返回結果）類型。接口文檔：接口所定義的行為被表示為操作集，并按以上要求給出說明。3、例子：設計子系統和接口計費系統和課程目錄系統在用例分析中是兩個邊界類。由于其功能復雜且由外部系統實現，故設計成兩個子系統和與之對應的接口。完成了從分析類到設計元素的映射。4、建模約定：子系統和接口《subsystem》包、《subsystemproxy》類和以I作為命名首字符的接口。5、例子：子系統環境：CourseCatalogSystem子系統環境包括：子系統、接口、代理類、依賴和實現關系以及任何子系統關系。6、例子：子系統環境：BillingSystem子系統環境包括：子系統、接口、代理類、依賴和實現關系以及任何子系統關系。6.7確定設計元素步驟（3）確定復用機會確定復用機會是一個重要的構架步驟。復用會帶來極大的好處，但必須對系統行為有較好理解和確定設計元素工作基本清晰之后統籌考慮。1、確定復用機會目的：根據現有子系統和/或構件的接口確定可以在哪些地方復用。步驟：1）尋找相似接口；2）修改新確定的接口，以增強匹配性；3）將被選接口替換成現有接口；4）將備選子系統映射到現有構件。2、可能復用的機會被開發系統內部：識別跨包和子系統的共性。被開發系統外部：商業上可得到的構件；先前開發的應用軟件構件；反向設計構件。3、對系統的內部復用的機會發現和尋找設計元素的共性：開發公共元素或構件。力求實現設計元素的通用性：為今后的復用及需求的變更考慮。建立以復用為目的的構件庫（不斷積累、分類管理）。6.8確定設計元素步驟（4）更新設計模型結構1、復審：典型分層方法應用層；業務規則層；中間件層；