UML建模語言及工具課件

UML建模語言及工具UML建模語言及工具面向對象的設計

Object-OrientedDesign面向對象的設計

Object-OrientedDesign學習線路圖OOUMLOOAOOPDP…Case-Study………

……

……

……學習線路圖3學習線路圖OOUMLOOAOOPDP…Case-Study從需求到分析AnalysisworkflowAnalysisClass4從需求到分析AnalysisworkflowAnalysi從分析到設計DesignClassSubsystemAnalysisClassDesignworkflow5從分析到設計DesignClassSubsystemAna內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計數(shù)據(jù)庫設計6內容安排從分析到設計6分析VS.設計分析：做什么Analysisemphasizedthebusinessproblem設計：怎么做Designfocusesonthetechnicalorimplementationconcernsofthesystem分析模型雖然有效地確定了將要構建的內容，但是卻沒有包含足夠的信息來定義如何構建系統(tǒng)，而面向對象的設計用來填補分析和實現(xiàn)之間的差距7分析VS.設計分析：做什么分析模型雖然有效地確定了將要構設計模型VS.分析模型-1需要維護兩個模型嗎？策略結果制作分析模型并精化成設計模型有了單獨的設計模型，但失去了分析模型制作分析模型并精化成設計模型，然后用CASE工具重新獲得分析模型有了單獨的設計模型，但是用CASE工具重新獲得的分析模型可能并不令人滿意在細化階段的某個點將分析模型凍結，然后把分析模型的一份拷貝精化成設計模型有了兩個模型，但是它們步調不一致維護兩個獨立的模型—分析模型和設計模型有了兩個模型，并且它們步調一致，但是這增加了維護的負擔8設計模型VS.分析模型-1需要維護兩個模型嗎？策略結果制設計模型VS.分析模型-2需要保留分析模型嗎？易于理解：分析模型提供系統(tǒng)的“大場景”，它可能只包括設計模型中的1%到10%的類價值：介紹新人加入項目在交付幾個月或幾年后重新理解系統(tǒng)理解系統(tǒng)是怎么滿足客戶需求以及提供可跟蹤性計劃維護和增強理解系統(tǒng)的邏輯架構外包系統(tǒng)的構造……9設計模型VS.分析模型-2需要保留分析模型嗎？9設計模型VS.分析模型-3需要分別維護分析模型和設計模型的系統(tǒng)龐大的復雜的戰(zhàn)略性的受經(jīng)常變更所支配的期望長期運行的外包的10設計模型VS.分析模型-3需要分別維護分析模型和設計模型軟件設計的定義IEEE1990：設計是體系結構、構件、接口、以及系統(tǒng)其它特征定義的過程11軟件設計的定義IEEE1990：設計是體系結構、構件、接口更精確定義軟件設計（的結果）必須描述系統(tǒng)的體系結構（architecture）系統(tǒng)如何分解（decompose）和組織（organize）構件描述構件間的接口（interface）描述構件（component）：必須詳細到可進一步構造的程度12更精確定義軟件設計（的結果）必須12ISO/IEC12207按ISO/IEC12207軟件開發(fā)生存周期過程，軟件設計由兩個活動組成軟件體系結構設計-softwarearchitecturaldesign頂層設計（top-leveldesign）描述系統(tǒng)頂層的結構和組織標識各個構件軟件詳細設計-softwaredetaileddesign充分描述每個構件使之可以編碼13ISO/IEC12207按ISO/IEC12207軟件開軟件設計的作用軟件設計在軟件系統(tǒng)開發(fā)過程中扮演重要角色開發(fā)者作出各種模型，形成實現(xiàn)時解決方案的藍圖對這些模型進行分析和評價，以判定是否滿足各種需求便于考察備選方案和可行的替換措施設計模型也可用于規(guī)劃后續(xù)的開發(fā)活動是編碼和測試的輸入連接需求和構造的橋梁14軟件設計的作用軟件設計在軟件系統(tǒng)開發(fā)過程中扮演重要角色連接需RUP中的分析和設計工作流分析

Analysis設計

Design15RUP中的分析和設計工作流分析

Analysis設計

D內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計數(shù)據(jù)庫設計16內容安排從分析到設計16為什么需要體系結構我們所定義的類或者對象其關注的重點是定義了一個系統(tǒng)的核心概念和行為一個系統(tǒng)是由多個子系統(tǒng)組成，每個子系統(tǒng)中的領域對象都不只一個這些類如何組織、分布并協(xié)同完成所需的功能？因此系統(tǒng)應該要有一個總體的體系結構，它定義了各子系統(tǒng)之間的通信和耦合體系結構包圖（architecturepackagediagram）17為什么需要體系結構我們所定義的類或者對象其關注的重點是定義了軟件體系結構定義軟件體系結構描述軟件系統(tǒng)的子系統(tǒng)和構件及其相互關系UMLReferenceManual：體系結構是一個系統(tǒng)的組織結構，包括系統(tǒng)分解成的各個部分、它們的連接性、交互機制和通知系統(tǒng)設計的向導規(guī)則軟件體系結構將多組類結合起來，形成一個有機的整體，并且展示各部分之間結構上的相互關系18軟件體系結構定義軟件體系結構描述軟件系統(tǒng)的子系統(tǒng)和構件及其相軟件體系結構風格體系結構風格style提供軟件系統(tǒng)高層組織的元模型通用結構：分層、管道過濾器、黑板分布式系統(tǒng)：客戶-服務器、三層、中介交互式系統(tǒng)：MVC、表示-抽象-控制可適配系統(tǒng)：微內核、反映式其它：批處理、解釋器、進程控制、基于規(guī)則19軟件體系結構風格體系結構風格style19UML和體系結構體系結構的全部內容就是復雜性管理：將解決方案劃分成多個小的組成部分，再將這些小的部分結合起來，構成更大的、更加一致的結構包（package）包依賴關系圖（packagedependencydiagram）子系統(tǒng)（subsystem）層（layer）20UML和體系結構體系結構的全部內容就是復雜性管理：將解決方案包-package包是一種將模型元素分組的機制包主要用于組織模型元素配置管理單元分包的原則職責相似：將一組職責相似、但以不同方式實現(xiàn)的類歸為一組有意義的包；如java類庫中的javax.swing.border協(xié)作關系：包含了各種不同類型的類，它們之間通過相互協(xié)作實現(xiàn)一個意義重大的職責21包-package包是一種將模型元素分組的機制21包依賴關系包之間存在著依賴關系如果Client包依賴于Supplier包：Supplier包的改變將影響到Client包Client包不能夠獨立的重用，因為它依賴于Supplier包22包依賴關系包之間存在著依賴關系22避免循環(huán)依賴循環(huán)依賴使得任何一個包都不能獨立的重用，修改任何一個包都會引起所有的包的變化23避免循環(huán)依賴循環(huán)依賴使得任何一個包都不能獨立的重用，修改任何體系結構設計過程1.確立目標2.將類分組3.展示技術4.抽取子系統(tǒng)5.針對準則和目標對體系結構進行評估24體系結構設計過程1.確立目標241.確立目標一個好的體系結構其實是不斷權衡、妥協(xié)、折衷的產(chǎn)物可擴展性可維護性可靠性可伸縮性……251.確立目標一個好的體系結構其實是不斷權衡、妥協(xié)、折衷的產(chǎn)2.將類分組并評估各個類將分析類劃分成幾個候選包，并對它們的內聚性進行評估目標是使每個包具有清晰的且嚴格定義的目的和職責結合體系結構模式，考慮分組方式實體類用戶界面類控制類系統(tǒng)接口類……描述包之間的耦合度：包依賴關系圖262.將類分組并評估各個類將分析類劃分成幾個候選包，并對它們考勤卡系統(tǒng)的體系結構包圖27考勤卡系統(tǒng)的體系結構包圖273.展示技術283.展示技術284.抽取子系統(tǒng)294.抽取子系統(tǒng)295.針對準則和目標進行評估305.針對準則和目標進行評估30內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計數(shù)據(jù)庫設計31內容安排從分析到設計31用例設計DesignworkflowUseCase32用例設計DesignworkflowUseCase32從分析類到設計元素33從分析類到設計元素33用例實現(xiàn)（設計）將設計應用于用例1.結合設計元素，定義設計對象間的交互（交互圖）2.利用子系統(tǒng)簡化交互圖3.描述與持久化相關的行為4.檢查用例事件流的實現(xiàn)5.評價類和子系統(tǒng)34用例實現(xiàn)（設計）將設計應用于用例34交互圖的設計：職責分配利用設計元素，進行類的職責分配，完成用例實現(xiàn)的交互圖職責分配模式：GRASP（GeneralResponsibilityAssignmentSoftwarePattern）模式專家模式、創(chuàng)建者模式(老板原則)、高內聚、低耦合、控制者多態(tài)、純虛構、中介者、不要和陌生人講話（可視原則）35交互圖的設計：職責分配利用設計元素，進行類的職責分配，完成用GRASP：不要和陌生人講話

（可視原則）解決方案分配職責給一個客戶端的直接對象以使它與一個間接對象進行協(xié)作，這樣客戶端無需知道這個間接對象這個模式也被稱為Demeter準則，在那些你需要在其上發(fā)送消息的對象上面放置一些限制條件，它表明在一個方法中，消息只能發(fā)往下面的對象：對象本身；方法的一個參數(shù)；對象本身的屬性；對象本身的一個屬性集合中的元素；該方法內創(chuàng)建的對象優(yōu)點低耦合36GRASP：不要和陌生人講話

（可視原則）解決方案36內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計37內容安排從分析到設計37子系統(tǒng)與接口子系統(tǒng)是一種介于包和類之間的一種設計機制，它實現(xiàn)一個或多個接口所定義的行為具有包的語義：能夠包含其它模型元素具有類的語義：具有行為38子系統(tǒng)與接口子系統(tǒng)是一種介于包和類之間的一種設計機制，它實現(xiàn)子系統(tǒng)的作用完全封裝了行為利用清晰的接口代表所擁有的能力可以定義不同的實現(xiàn)39子系統(tǒng)的作用完全封裝了行為39子系統(tǒng)VS.包子系統(tǒng)：提供行為完全封裝實現(xiàn)細節(jié)容易替換包：不提供行為不完全封裝實現(xiàn)細節(jié)難以替換關鍵在于封裝40子系統(tǒng)VS.包子系統(tǒng)：包：關鍵在于封裝40子系統(tǒng)的主要用途子系統(tǒng)可以將系統(tǒng)劃分成獨立的部分，以利于：開發(fā)，只要保持接口不變部署到不同分布的節(jié)點上變更，而不影響到其它系統(tǒng)在設計階段，子系統(tǒng)還可用于打包遺留系統(tǒng)子系統(tǒng)代表了粗粒度的組件41子系統(tǒng)的主要用途子系統(tǒng)可以將系統(tǒng)劃分成獨立的部分，以利于：4子系統(tǒng)的設計原則目標松散耦合可替換的，plug-and-play隔離變更自身可獨立的改進好的建議不要暴露細節(jié)，只有接口僅依賴于接口42子系統(tǒng)的設計原則目標42子系統(tǒng)的設計步驟將子系統(tǒng)的行為分發(fā)到各個子系統(tǒng)元素中：分發(fā)子系統(tǒng)的職責描述子系統(tǒng)中的元素描述子系統(tǒng)的依賴關系43子系統(tǒng)的設計步驟將子系統(tǒng)的行為分發(fā)到各個子系統(tǒng)元素中：分發(fā)子接口設計接口說明了一組操作，隱藏子系統(tǒng)的實現(xiàn)細節(jié)在GoF的23種設計模式中，F(xiàn)acade模式是一種很好的接口的設計模式確定系統(tǒng)的內聚部分將這些打包到一個<<subsystem>>為該子系統(tǒng)設計接口44接口設計接口說明了一組操作，隱藏子系統(tǒng)的實現(xiàn)細節(jié)44考勤卡系統(tǒng)中的子系統(tǒng)設計利用子系統(tǒng)來打包遺留系統(tǒng)45考勤卡系統(tǒng)中的子系統(tǒng)設計利用子系統(tǒng)來打包遺留系統(tǒng)45內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計46內容安排從分析到設計46設計類設計類設計模型的構造塊設計類是已經(jīng)完成了規(guī)格說明并且達到能夠被實現(xiàn)程度的類來源于問題域和解域通過分析類的精化得到的問題域—添加實現(xiàn)細節(jié)解域，提供了能夠實現(xiàn)系統(tǒng)的技術工具47設計類設計類47設計類剖析在分析中，只要盡量捕獲系統(tǒng)需要的行為，而完全不必考慮如何去實現(xiàn)這些行為在設計中，則必須準確地說明類是如何履行它們的職責完整的屬性集合，包括詳細說明的名稱、類型、可視性和一些默認值將分析類指定的職責轉化成一個或多個方法的完整集合48設計類剖析在分析中，只要盡量捕獲系統(tǒng)需要的行為，而完全不必考良好的設計類類的公共方法定義它和類用戶之間的契約通常要從類用戶的角度去評估類的目的基本特征完整性和充分性原始性高內聚低耦合49良好的設計類類的公共方法定義它和類用戶之間的契約49類設計的主要工作定義類的操作類的職責定義類的方法和狀態(tài)方法：操作的實現(xiàn)狀態(tài)：對象的狀態(tài)如何影響它的行為(狀態(tài)圖)定義類的屬性定義類之間的關系50類設計的主要工作定義類的操作50類之間的關系依賴關系關聯(lián)關系聚合關系組合關系泛化關系低耦合度

高51類之間的關系依賴關系低51關聯(lián)關系的表示方法關聯(lián)具有：名稱、多重性表達式、導航符號、角色名稱名稱：動詞短語多重性表達式：*，1..*，1-40，5，3,5,8，…導航符號角色名稱52關聯(lián)關系的表示方法關聯(lián)具有：名稱、多重性表達式、導航符號、角聚合關系示例一臺Computer可能連接到0..n臺Printers

任何時候一臺Printer連接到0..1臺Computer隨著時間推移，許多臺Computers可以使用一臺給定的Printer即使沒有所連接的Computers，那臺Printer也可以生存在非?？陀^的意義上，那臺Printer是獨立于那臺Computer的聚合有時能夠不依賴部分而存在，有時又不能部分可以獨立于聚合而存在如果有一部分遺失，聚合會給人一種不完整的感覺部分的所有權可以由幾個聚合共享53聚合關系示例一臺Computer可能連接到0..n臺Pri組合關系示例

Button離開Mouse對象則不能獨立存在銷毀Mouse則也銷毀Mouse，因為它們是Mouse對象整體的一個部分每個Button只能僅僅屬于一個Mouse（如樹和樹葉）部分在某一時刻僅僅只能屬于一個組成組成唯一地負責處理它的所有部分—負責它們的創(chuàng)建和銷毀倘若對于部分的職責有由其他的對象來承擔的話，組合也可以放松這些職責如果一個組成銷毀的話，它必須將它所有的部分銷毀，或者把負責處理它們的權力交給其他的一些對象54組合關系示例Button離開Mouse對象則不能獨立存在部泛化關系只有在兩個設計類之間存在清晰明確的“isa”關系或為了復用代碼才使用繼承（但是注意不要因此引入耦合）缺點類間可能耦合的最強形式：派生類會繼承基類的屬性、方法、關系類層次中的封裝是脆弱的，它會導致“脆弱基類”問題—基類的改動會直接波及底下的層次在大多數(shù)語言中，繼承非常不易改變—關系是在編譯時確定的，關系在運行時是固定的55泛化關系只有在兩個設計類之間存在清晰明確的“isa”關系或可見性問題動機：對象A若要對對象B發(fā)送消息，那么對象B必須對對象A可見可見性（Visibility）是一個對象“看到”或者引用另一個對象的能力；更一般地講，可見性與問題的范圍有關：一個資源（如一個實例）是否在另一個資源的范圍之內？從對象A到對象B通常有四種可見性：屬性可見性（attribute）：B是A的一個屬性參數(shù)可見性（parameter）：B是A中一個方法的參數(shù)局部聲明可見性（local）：B在A的一個方法中被聲明為一個局部對象全局可見性（global）：B在某種程度上全局可見56可見性問題動機：對象A若要對對象B發(fā)送消息，那么對象B必須對屬性可見性

publicclassHost{privateDogdog;}57屬性可見性publicclassHost57參數(shù)可見性從ShowMails到Mails的參數(shù)可見性publicclassShowMails{

staticintputMails(Mailsmail){ if(currentMails>=maxMails) { System.out.println("Mailboxoverwhelmed!"); return-1; } showList[currentMails]=mail; currentMails++; returncurrentMails; }｝58參數(shù)可見性從ShowMails到Mails的參數(shù)可見性58局部聲明可見性從Show到Mails的局部聲明可見性publicclassShow{

publicstaticvoidmain(Stringargs[]) { Mailsnewmail;

………….｝｝ 59局部聲明可見性從Show到Mails的局部聲明可見性59全局可見性60全局可見性60可見性問題示例//屬性可見性classPOST{…privateProductCatalogprodCatalog;…publicvoidenterItem(intupc,intqty){…spec:=prodCatalog.getSpecification(upc);…}…}//參數(shù)可見性classSale{……publicvoidmakeLineItem(ProductSpecificationspec,intqty){………}…}//局部聲明可見性classPOST{…publicvoidenterItem(intupc,intqty){…

ProductSpecificationspec=prodCatalog.getSpecification(upc);…}…}61可見性問題示例//屬性可見性//參數(shù)可見性//局部聲明可見性內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計從設計模型到代碼實現(xiàn)62內容安排從分析到設計62設計模型與代碼實現(xiàn)編寫代碼形成軟件軟件最終需要代碼來實現(xiàn)模型只是為代碼實現(xiàn)提供支持目前尚未產(chǎn)生成熟的可執(zhí)行模型正向工程（Forwardengineering）由設計類圖導出框架代碼由交互圖創(chuàng)建方法實現(xiàn)逆向工程（Reverseengineering）由源代碼導出設計模型63設計模型與代碼實現(xiàn)編寫代碼形成軟件63正向工程-生存框架代碼什么是框架代碼？代碼在設計上的初步實現(xiàn)類的框架代碼包括那些？屬性值定義：名稱、類型、缺省值等方法定義：名稱、參數(shù)、返回類型等引用關系……根據(jù)設計類圖產(chǎn)生框架代碼用方法和簡單屬性定義一個類加入引用屬性：角色名定義引用屬性64正向工程-生存框架代碼什么是框架代碼？64從設計類圖產(chǎn)生框架代碼-11.用方法和簡單屬性定義一個類（屬性、方法、構造函數(shù)）65從設計類圖產(chǎn)生框架代碼-11.用方法和簡單屬性定義一個類（從設計類圖產(chǎn)生框架代碼-22.加入引用屬性（引用屬性referenceattribute：關聯(lián)和導航；角色名rolename）66從設計類圖產(chǎn)生框架代碼-22.加入引用屬性（引用屬性refRose支持框架代碼的導出利用Rose由設計類圖生成框架代碼（Java）新建一個基于J2SE的應用程序選擇缺省的語言為Java利用Rose建模開始導出工作：類的語法檢查設置導出路徑ClassPath導出框架代碼主要問題：設計模型開發(fā)不夠完善，無法導出代碼67Rose支持框架代碼的導出利用Rose由設計類圖生成框架代碼其它問題-一對多關系的實現(xiàn)68其它問題-一對多關系的實現(xiàn)68正向工程-創(chuàng)建方法實現(xiàn)一個交互圖顯示出了響應方法調用而產(chǎn)生的消息傳遞；這些消息序列可以被翻譯成方法實現(xiàn)中的一系列語句由順序圖產(chǎn)生方法實現(xiàn)由協(xié)作圖產(chǎn)生方法實現(xiàn)69正向工程-創(chuàng)建方法實現(xiàn)一個交互圖顯示出了響應方法調用而產(chǎn)生的示例-POST類enterItem方法實現(xiàn)//1.1創(chuàng)建Sale實例if(isNewSale()){sale=newSale();}//1.2獲得ProductSpecificationProductSpecificationspec=productCatalog.getSpecification(upc);//1.3添加銷售項sale.makeLineItem(spec,qty);publicvoidenterItem(intupc,intqty){if(isNewSale()){sale=newSale();}ProductSpecificationspec=productCatalog.getSpecification(upc);sale.makeLineItem(spec,qty);}由順序圖產(chǎn)生實現(xiàn)代碼70示例-POST類enterItem方法實現(xiàn)//1.1創(chuàng)建SaUML建模語言及工具UML建模語言及工具面向對象的設計

Object-OrientedDesign面向對象的設計

Object-OrientedDesign學習線路圖OOUMLOOAOOPDP…Case-Study………

……

……

……學習線路圖73學習線路圖OOUMLOOAOOPDP…Case-Study從需求到分析AnalysisworkflowAnalysisClass74從需求到分析AnalysisworkflowAnalysi從分析到設計DesignClassSubsystemAnalysisClassDesignworkflow75從分析到設計DesignClassSubsystemAna內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計數(shù)據(jù)庫設計76內容安排從分析到設計6分析VS.設計分析：做什么Analysisemphasizedthebusinessproblem設計：怎么做Designfocusesonthetechnicalorimplementationconcernsofthesystem分析模型雖然有效地確定了將要構建的內容，但是卻沒有包含足夠的信息來定義如何構建系統(tǒng)，而面向對象的設計用來填補分析和實現(xiàn)之間的差距77分析VS.設計分析：做什么分析模型雖然有效地確定了將要構設計模型VS.分析模型-1需要維護兩個模型嗎？策略結果制作分析模型并精化成設計模型有了單獨的設計模型，但失去了分析模型制作分析模型并精化成設計模型，然后用CASE工具重新獲得分析模型有了單獨的設計模型，但是用CASE工具重新獲得的分析模型可能并不令人滿意在細化階段的某個點將分析模型凍結，然后把分析模型的一份拷貝精化成設計模型有了兩個模型，但是它們步調不一致維護兩個獨立的模型—分析模型和設計模型有了兩個模型，并且它們步調一致，但是這增加了維護的負擔78設計模型VS.分析模型-1需要維護兩個模型嗎？策略結果制設計模型VS.分析模型-2需要保留分析模型嗎？易于理解：分析模型提供系統(tǒng)的“大場景”，它可能只包括設計模型中的1%到10%的類價值：介紹新人加入項目在交付幾個月或幾年后重新理解系統(tǒng)理解系統(tǒng)是怎么滿足客戶需求以及提供可跟蹤性計劃維護和增強理解系統(tǒng)的邏輯架構外包系統(tǒng)的構造……79設計模型VS.分析模型-2需要保留分析模型嗎？9設計模型VS.分析模型-3需要分別維護分析模型和設計模型的系統(tǒng)龐大的復雜的戰(zhàn)略性的受經(jīng)常變更所支配的期望長期運行的外包的80設計模型VS.分析模型-3需要分別維護分析模型和設計模型軟件設計的定義IEEE1990：設計是體系結構、構件、接口、以及系統(tǒng)其它特征定義的過程81軟件設計的定義IEEE1990：設計是體系結構、構件、接口更精確定義軟件設計（的結果）必須描述系統(tǒng)的體系結構（architecture）系統(tǒng)如何分解（decompose）和組織（organize）構件描述構件間的接口（interface）描述構件（component）：必須詳細到可進一步構造的程度82更精確定義軟件設計（的結果）必須12ISO/IEC12207按ISO/IEC12207軟件開發(fā)生存周期過程，軟件設計由兩個活動組成軟件體系結構設計-softwarearchitecturaldesign頂層設計（top-leveldesign）描述系統(tǒng)頂層的結構和組織標識各個構件軟件詳細設計-softwaredetaileddesign充分描述每個構件使之可以編碼83ISO/IEC12207按ISO/IEC12207軟件開軟件設計的作用軟件設計在軟件系統(tǒng)開發(fā)過程中扮演重要角色開發(fā)者作出各種模型，形成實現(xiàn)時解決方案的藍圖對這些模型進行分析和評價，以判定是否滿足各種需求便于考察備選方案和可行的替換措施設計模型也可用于規(guī)劃后續(xù)的開發(fā)活動是編碼和測試的輸入連接需求和構造的橋梁84軟件設計的作用軟件設計在軟件系統(tǒng)開發(fā)過程中扮演重要角色連接需RUP中的分析和設計工作流分析

Analysis設計

Design85RUP中的分析和設計工作流分析

Analysis設計

D內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計數(shù)據(jù)庫設計86內容安排從分析到設計16為什么需要體系結構我們所定義的類或者對象其關注的重點是定義了一個系統(tǒng)的核心概念和行為一個系統(tǒng)是由多個子系統(tǒng)組成，每個子系統(tǒng)中的領域對象都不只一個這些類如何組織、分布并協(xié)同完成所需的功能？因此系統(tǒng)應該要有一個總體的體系結構，它定義了各子系統(tǒng)之間的通信和耦合體系結構包圖（architecturepackagediagram）87為什么需要體系結構我們所定義的類或者對象其關注的重點是定義了軟件體系結構定義軟件體系結構描述軟件系統(tǒng)的子系統(tǒng)和構件及其相互關系UMLReferenceManual：體系結構是一個系統(tǒng)的組織結構，包括系統(tǒng)分解成的各個部分、它們的連接性、交互機制和通知系統(tǒng)設計的向導規(guī)則軟件體系結構將多組類結合起來，形成一個有機的整體，并且展示各部分之間結構上的相互關系88軟件體系結構定義軟件體系結構描述軟件系統(tǒng)的子系統(tǒng)和構件及其相軟件體系結構風格體系結構風格style提供軟件系統(tǒng)高層組織的元模型通用結構：分層、管道過濾器、黑板分布式系統(tǒng)：客戶-服務器、三層、中介交互式系統(tǒng)：MVC、表示-抽象-控制可適配系統(tǒng)：微內核、反映式其它：批處理、解釋器、進程控制、基于規(guī)則89軟件體系結構風格體系結構風格style19UML和體系結構體系結構的全部內容就是復雜性管理：將解決方案劃分成多個小的組成部分，再將這些小的部分結合起來，構成更大的、更加一致的結構包（package）包依賴關系圖（packagedependencydiagram）子系統(tǒng)（subsystem）層（layer）90UML和體系結構體系結構的全部內容就是復雜性管理：將解決方案包-package包是一種將模型元素分組的機制包主要用于組織模型元素配置管理單元分包的原則職責相似：將一組職責相似、但以不同方式實現(xiàn)的類歸為一組有意義的包；如java類庫中的javax.swing.border協(xié)作關系：包含了各種不同類型的類，它們之間通過相互協(xié)作實現(xiàn)一個意義重大的職責91包-package包是一種將模型元素分組的機制21包依賴關系包之間存在著依賴關系如果Client包依賴于Supplier包：Supplier包的改變將影響到Client包Client包不能夠獨立的重用，因為它依賴于Supplier包92包依賴關系包之間存在著依賴關系22避免循環(huán)依賴循環(huán)依賴使得任何一個包都不能獨立的重用，修改任何一個包都會引起所有的包的變化93避免循環(huán)依賴循環(huán)依賴使得任何一個包都不能獨立的重用，修改任何體系結構設計過程1.確立目標2.將類分組3.展示技術4.抽取子系統(tǒng)5.針對準則和目標對體系結構進行評估94體系結構設計過程1.確立目標241.確立目標一個好的體系結構其實是不斷權衡、妥協(xié)、折衷的產(chǎn)物可擴展性可維護性可靠性可伸縮性……951.確立目標一個好的體系結構其實是不斷權衡、妥協(xié)、折衷的產(chǎn)2.將類分組并評估各個類將分析類劃分成幾個候選包，并對它們的內聚性進行評估目標是使每個包具有清晰的且嚴格定義的目的和職責結合體系結構模式，考慮分組方式實體類用戶界面類控制類系統(tǒng)接口類……描述包之間的耦合度：包依賴關系圖962.將類分組并評估各個類將分析類劃分成幾個候選包，并對它們考勤卡系統(tǒng)的體系結構包圖97考勤卡系統(tǒng)的體系結構包圖273.展示技術983.展示技術284.抽取子系統(tǒng)994.抽取子系統(tǒng)295.針對準則和目標進行評估1005.針對準則和目標進行評估30內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計數(shù)據(jù)庫設計101內容安排從分析到設計31用例設計DesignworkflowUseCase102用例設計DesignworkflowUseCase32從分析類到設計元素103從分析類到設計元素33用例實現(xiàn)（設計）將設計應用于用例1.結合設計元素，定義設計對象間的交互（交互圖）2.利用子系統(tǒng)簡化交互圖3.描述與持久化相關的行為4.檢查用例事件流的實現(xiàn)5.評價類和子系統(tǒng)104用例實現(xiàn)（設計）將設計應用于用例34交互圖的設計：職責分配利用設計元素，進行類的職責分配，完成用例實現(xiàn)的交互圖職責分配模式：GRASP（GeneralResponsibilityAssignmentSoftwarePattern）模式專家模式、創(chuàng)建者模式(老板原則)、高內聚、低耦合、控制者多態(tài)、純虛構、中介者、不要和陌生人講話（可視原則）105交互圖的設計：職責分配利用設計元素，進行類的職責分配，完成用GRASP：不要和陌生人講話

（可視原則）解決方案分配職責給一個客戶端的直接對象以使它與一個間接對象進行協(xié)作，這樣客戶端無需知道這個間接對象這個模式也被稱為Demeter準則，在那些你需要在其上發(fā)送消息的對象上面放置一些限制條件，它表明在一個方法中，消息只能發(fā)往下面的對象：對象本身；方法的一個參數(shù)；對象本身的屬性；對象本身的一個屬性集合中的元素；該方法內創(chuàng)建的對象優(yōu)點低耦合106GRASP：不要和陌生人講話

（可視原則）解決方案36內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計107內容安排從分析到設計37子系統(tǒng)與接口子系統(tǒng)是一種介于包和類之間的一種設計機制，它實現(xiàn)一個或多個接口所定義的行為具有包的語義：能夠包含其它模型元素具有類的語義：具有行為108子系統(tǒng)與接口子系統(tǒng)是一種介于包和類之間的一種設計機制，它實現(xiàn)子系統(tǒng)的作用完全封裝了行為利用清晰的接口代表所擁有的能力可以定義不同的實現(xiàn)109子系統(tǒng)的作用完全封裝了行為39子系統(tǒng)VS.包子系統(tǒng)：提供行為完全封裝實現(xiàn)細節(jié)容易替換包：不提供行為不完全封裝實現(xiàn)細節(jié)難以替換關鍵在于封裝110子系統(tǒng)VS.包子系統(tǒng)：包：關鍵在于封裝40子系統(tǒng)的主要用途子系統(tǒng)可以將系統(tǒng)劃分成獨立的部分，以利于：開發(fā)，只要保持接口不變部署到不同分布的節(jié)點上變更，而不影響到其它系統(tǒng)在設計階段，子系統(tǒng)還可用于打包遺留系統(tǒng)子系統(tǒng)代表了粗粒度的組件111子系統(tǒng)的主要用途子系統(tǒng)可以將系統(tǒng)劃分成獨立的部分，以利于：4子系統(tǒng)的設計原則目標松散耦合可替換的，plug-and-play隔離變更自身可獨立的改進好的建議不要暴露細節(jié)，只有接口僅依賴于接口112子系統(tǒng)的設計原則目標42子系統(tǒng)的設計步驟將子系統(tǒng)的行為分發(fā)到各個子系統(tǒng)元素中：分發(fā)子系統(tǒng)的職責描述子系統(tǒng)中的元素描述子系統(tǒng)的依賴關系113子系統(tǒng)的設計步驟將子系統(tǒng)的行為分發(fā)到各個子系統(tǒng)元素中：分發(fā)子接口設計接口說明了一組操作，隱藏子系統(tǒng)的實現(xiàn)細節(jié)在GoF的23種設計模式中，F(xiàn)acade模式是一種很好的接口的設計模式確定系統(tǒng)的內聚部分將這些打包到一個<<subsystem>>為該子系統(tǒng)設計接口114接口設計接口說明了一組操作，隱藏子系統(tǒng)的實現(xiàn)細節(jié)44考勤卡系統(tǒng)中的子系統(tǒng)設計利用子系統(tǒng)來打包遺留系統(tǒng)115考勤卡系統(tǒng)中的子系統(tǒng)設計利用子系統(tǒng)來打包遺留系統(tǒng)45內容安排從分析到設計體系結構設計用例設計子系統(tǒng)設計類設計116內容安排從分析到設計46設計類設計類設計模型的構造塊設計類是已經(jīng)完成了規(guī)格說明并且達到能夠被實現(xiàn)程度的類來源于問題域和解域通過分析類的精化得到的問題域—添加實現(xiàn)細節(jié)解域，提供了能夠實現(xiàn)系統(tǒng)的技術工具117設計類設計類47設計類剖析在分析中，只要盡量捕獲系統(tǒng)需要的行為，而完全不必考慮如何去實現(xiàn)這些行為在設計中，則必須準確地說明類是如何履行它們的職責完整的屬性集合，包括詳細說明的名稱、類型、可視性和一些默認值將分析類指定的職責轉化成一個或多個方法的完整集合118設計類剖析在分析中，只要盡量捕獲系統(tǒng)需要的行為，而完全不必考良好的設計類類的公共方法定義它和類用戶之間的契約通常要從類用戶的角度去評估類的目的基本特征完整性和充分性原始性高內聚低耦合119良好的設計類類的公共方法定義它和類用戶之間的契約49類設計的主要工作定義類的操作類的職責定義類的方法和狀態(tài)方法：操作的實現(xiàn)狀態(tài)：對象的狀態(tài)如何影響它的行為(狀態(tài)圖)定義類的屬性定義類之間的關系120類設計的主要工作定義類的操作50類之間的關系依賴關系關聯(lián)關系聚合關系組合關系泛化關系低耦合度

高121類之間的關系依賴關系低51關聯(lián)關系的表示方法關聯(lián)具有：名稱、多重性表達式、導航符號、角色名稱名稱：動詞短語多重性表達式：*，1..*，1-40，5，3,5,8，…導航符號角色名稱122關聯(lián)關系的表示方法關聯(lián)具有：名稱、多重性表達式、導航符號、角聚合關系示例一臺Computer可能連接到0..n臺Printers

任何時候一臺Printer連接到0..1臺Computer隨著時間推移，許多臺Computers可以使用一臺給定的Printer即使沒有所連接的Computers，那臺Printer也可以生存在非?？陀^的意義上，那臺Printer是獨立于那臺Computer的聚合有時能夠不依賴部分而存在，有時又不能部分可以獨立于聚合而存在如果有一部分遺失，聚合會給人一種不完整的感覺部分的所有權可以由幾個聚合共享123聚合關系示例一臺Computer可能連接到0..n臺Pri組合關系示例

Button離開Mouse對象則不能獨立存在銷毀Mouse則也銷毀Mouse，因為它們是Mouse對象整體的一個部分每個Button只能僅僅屬于一個Mouse（如樹和樹葉）部分在某一時刻僅僅只能屬于一個組成組成唯一地負責處理它的所有部分—負責它們的創(chuàng)建和銷毀倘若對于部分的職責有由其他的對象來承擔的話，組合也可以放松這些職責如果一個組成銷毀的話，它必須將它所有的部分銷毀，或者把負責處理它們的權力交給其他的一些對象124組合關系示例Button離開Mouse對象則不能獨立存在部泛化關系只有在兩個設計類之間存在清晰明確的“isa”關系或為了復用代碼才使用繼承（但是注意不要因此引入耦合）缺點類間可能耦合的最強形式：派生類會繼承基類的屬性、方法、關系類層次中的封裝是脆弱的，它會導致“脆弱基類”問題—基類的改動會直接波及底下的層次在大多數(shù)語言中，繼承非常不易改變—關系是在編譯時確定的，關系在運行時是固定的125泛化關系只有在兩個設計類之間存在清晰明確的“isa”關系或可見性問題動機：對象A若要對對象B發(fā)送消息，那么對象B必須對對象A可見可見性（Visibility）是一個對象“看到”或者引用另一個對象的能力；更一般地講，可見性與問題的范圍有關：一個資源（如一個實例）是否在另一個資源的范圍之內？從對象A到對象B通常有四種可見性：屬性可見性（attribute）：B是A的一個屬性參數(shù)可見性（parameter）：B是A中一個方法的參數(shù)局部聲明可見性（local）：B在A的一個方法中被聲明為一個局部對象全局可見性（global）：B在某種程度上全局可見126可見性問題動機：對象A若要對對象B發(fā)送消息，那么對象B必須對屬性可見性

publicclassHost{privateDogdog;}127屬性可見性publicclassHost57參數(shù)可見性從ShowMails到Mails的參數(shù)可見性publicclassShowMails{

staticintputMails(Mailsmail){ if(currentMails>=maxMails) { System.out.println("Mailboxoverwhelmed!"); return-1; } showList[currentMails]=mail; currentMails++; returncurrentMails; }｝128參數(shù)可見性從ShowMails到Mails的參數(shù)可見性58局部聲明可見性從Show到Mails的局部聲明可見性publicclassShow{

publicstaticvoidmain(Stringargs[]) { Mailsnewmail;

………….｝｝ 129局部聲明可見性從Sho