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

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

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

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