信息系統(tǒng)項目管理師考試輔導(dǎo)教程(第3版)第4章面向?qū)ο蠓椒?共19頁)

1、精選優(yōu)質(zhì)文檔-傾情為你奉上第4章面向?qū)ο蠓椒ńY(jié)構(gòu)化分析和設(shè)計方法在一定葙度上緩解了“軟件危機(jī)”。但隨著人們對軟件提出的要求越來越高，結(jié)構(gòu)化方法己經(jīng)無法承擔(dān)快速高效開發(fā)復(fù)雜軟件系統(tǒng)的重任。2 0世紀(jì)80年代逐漸成熟的面向?qū)ο蠓椒▽W(xué)，使軟件開發(fā)者對軟件的分析、設(shè)計和編程等方面都有了全新的認(rèn)識。由于“對象”概念的引入，將數(shù)據(jù)和方法封裝在一起，提高了模塊的聚合度，降低了模塊的耦合度，更大程度上支持了軟件重用，從而十分有效地降低了軟件的復(fù)雜度，提高了軟件開發(fā)的生產(chǎn)率。目前，面向?qū)ο蠓椒▽W(xué)已成為軟件開發(fā)者的第一選擇。根據(jù)考試大綱，本章要求考生掌握以下知識點(diǎn)：面向?qū)ο蟮幕靖拍?；統(tǒng)一建模語言UML;可視化建

2、模；面向?qū)ο笙到y(tǒng)分析；面向?qū)ο笙到y(tǒng)設(shè)計。4.1面向?qū)ο蟮幕靖拍顬榱擞懻撁嫦驅(qū)ο螅∣bject-Oriented,0 0)的技術(shù)和方法，必須首先明確什么是“面向?qū)ο蟆?？為什么要討論面向?qū)ο蟮姆椒?？什么是對象？對于這些問題，有許多不同的看法。其中Booch、Coad/Yourdon和Jacobson的方法在面向?qū)ο筌浖_發(fā)界得到了廣泛的認(rèn)可。特別值得一提的是統(tǒng)一建模語言（UML,Unified Modeling Language),該方法結(jié)合了Booch、OMT和Jacobson方法的優(yōu)點(diǎn)，統(tǒng)一了符號體系，并從其他的方法和工程實踐中吸收了許多經(jīng)過實踐檢驗的概念和技術(shù)。Peter Coad和Edw

3、ard Yourdon曾提出了下列等式：面向?qū)ο?對象（Objects)+類（Classes)+繼承（Inheritance)+消息通信(Communication with Messages)4.1.1對象與封裝對象（Object)是系統(tǒng)中用來描述客觀事物的一個實體，它是構(gòu)成系統(tǒng)的一個基本單位。面向?qū)ο蟮能浖到y(tǒng)是由對象組成的，復(fù)雜的對象由比較簡單的對象組合而成。也就是說，面向?qū)ο蠓椒▽W(xué)使用對象分解取代了傳統(tǒng)方法的功能分解。對象三要素：對象標(biāo)志、屬性和服務(wù)。對象標(biāo)志（Object Identifier)，也就是對象的名字，供系統(tǒng)內(nèi)部唯一地識別對象。定義或使用對象時，均應(yīng)指定對象標(biāo)志。屬性（A

4、ttribute),也稱狀態(tài)（State)或數(shù)據(jù)（D at a),用來描述對象的靜態(tài)特征。在某些面向?qū)ο蟮某绦蛟O(shè)計語言中，屬性通常被稱為成員變量（Member Variable)或簡稱變量（Variable)。服務(wù)（Service),也稱操作（Operation)、行為（Behavior)或方法（Method)等，用來描述對象的動態(tài)特征。在某些面向?qū)ο蟮某绦蛟O(shè)計語言中，服務(wù)通常被稱為成員函數(shù)（MemberFunction)或簡稱函數(shù)（Function)。封裝（Encapsulation)是對象的一個重要原則。它有兩層含義：第一，對象是其全部屬性和全部服務(wù)緊密結(jié)合而形成的一個不可分割的整體；第二

5、，對象是一個不透明的黑盒子，表示對象狀態(tài)的數(shù)據(jù)和實現(xiàn)操作的代碼都被封裝在黑盒子里面。使用一個對象的時候，只需知道它向外界提供的接口形式，無須知道它的數(shù)據(jù)結(jié)構(gòu)細(xì)節(jié)和實現(xiàn)操作的算法。從外面看不見，也就更不可能從外面直接修改對象的私有屬性了。4.1.2類與類庫類（class)是對象的抽象定義，是一組具有相同數(shù)據(jù)結(jié)構(gòu)和相同操作的對象的集合。類的定義包括一組數(shù)據(jù)屬性和在數(shù)據(jù)上的一組合法操作。類定義可以視為一個具有類似特性與共同行為的對象的模板，可用來產(chǎn)生對象。類與對象是抽象描述與具體實例的關(guān)系，一個具體的對象被稱為類的一個實例(Instance)。它們都可使用類中提供的函數(shù)。一個對象的狀態(tài)則包含在它的實

6、例變量中。從物理特征上來看，類庫和傳統(tǒng)例程庫是類似的，它們都是一種預(yù)先定義的程序庫。類庫是一種預(yù)先定義的程序庫，它以程序模塊的形式，按照類層次結(jié)構(gòu)把一組類的定義和實現(xiàn)組織在一起。較上層的類代表了較一般的事物，相反，較下層的類代表了較具體的事物，很好地體現(xiàn)了面向?qū)ο髾C(jī)制的繼承性、重載等許多特征。類屬類（Generic Class)僅描述了適用于一組類型的通用樣板，由于其中所處理對象的數(shù)據(jù)類型尚未確定，因而程序員不可用類屬類直接創(chuàng)建對象實例，即一個類屬類并不是一種真正的類類型。類屬類必須經(jīng)過實例化后才能成為可創(chuàng)建對象實例的類類型。類屬類的實例化是指用某一數(shù)據(jù)類型替代類屬類的類型參數(shù)。類屬類定義中給

7、出的類型參數(shù)稱為形式類屬參數(shù)，類屬類實例化時給出的類型參數(shù)稱為實際類屬參數(shù)。如果類屬類實例化的實際類屬參數(shù)可以是任何類型，那么這種類屬類稱為無約束類屬類。然而在某些情況下，類屬類可能要求實際類屬參數(shù)必須具有某些特殊的性質(zhì)，以使得在類屬類中可應(yīng)用某些特殊操作，這種類屬類稱為受約束類屬類。類屬類對類庫的建設(shè)提供了強(qiáng)有力的支持。4.1.3繼承與多態(tài)繼承（Inheritance)是使用已存在的定義作為基礎(chǔ)建立新定義的技術(shù)，繼承是面向?qū)ο蠓椒▽W(xué)中的一個十分重要的概念。新類的定義可以是現(xiàn)存類所聲明的數(shù)據(jù)、定義與新類所增加的聲明的組合。新類復(fù)用現(xiàn)存類的定義，而不要求修改現(xiàn)存類。因為這種類的一部分已經(jīng)實現(xiàn)和測

8、試，故開發(fā)費(fèi)用較少?，F(xiàn)存類可當(dāng)作父類（泛化類、基類或超類)來引用，則新類相應(yīng)地可當(dāng)作子類（特化類、子女類或派生類）來引用。在面向?qū)ο蠹夹g(shù)中，多態(tài)考慮的是類與類之間的層次關(guān)系，以及類自身內(nèi)部特定成員函數(shù)之間的關(guān)系問題，是解決功能和行為的再抽象問題。多態(tài)是指類中具有相似功能的不同函數(shù)是用同一個名稱來實現(xiàn)，從而可以使用相同的調(diào)用方式來調(diào)用這些具有不同功能的同名函數(shù)。這也是人類思維方式的一種直接模擬，比如一個對象中有很多求兩個數(shù)最大值的行為，雖然可以針對不同的數(shù)據(jù)類型，寫很多不同名稱的函數(shù)來實現(xiàn)，但事實上，它們的功能幾乎完全相同。這時，就可以利用多態(tài)的特征，用統(tǒng)一的標(biāo)志來完成這些功能。這樣，就可以達(dá)到

9、類的行為的再抽象，進(jìn)而統(tǒng)一標(biāo)志，減少程序中標(biāo)志符的個數(shù)。嚴(yán)格地說，多態(tài)性可分為四類，分別為過載多態(tài)（重載多態(tài)），強(qiáng)制多態(tài)，包含多態(tài)和參數(shù)多態(tài)，其中前兩種統(tǒng)稱為專用多態(tài)（特定多態(tài)），后面兩種稱為通用多態(tài)。包含多態(tài)是研究類族中定義于不同類中的同名成員函數(shù)的多態(tài)行為，主要是通過虛函數(shù)來實現(xiàn)。包含多態(tài)最常見的例子就是子類型化，即一個類型是另一類型的子類型。參數(shù)多態(tài)的應(yīng)用比較廣泛，被稱為最純的多態(tài)。這是因為同一對象、函數(shù)或過程能以一致的形式用于不同的類型。參數(shù)多態(tài)與類屬（類模板）相關(guān)聯(lián)，類屬是一個可以參數(shù)化的模板，其中包含的操作所涉及的類型必須用類型參數(shù)實例化。這樣，由類模板實例化的各類都具有相同的操作

10、，而操作對象的類型卻各不相同。過載多態(tài)是同一算子（操作符、函數(shù)名等）被用來表示不同的功能，通過上下文以決定一個算子所代表的功能，即通過語法對不同語義的對象使用相同的算子，編譯能夠消除這一模糊。強(qiáng)制多態(tài)是通過語義操作把一個變元的類型加以變換，以符合一個函數(shù)的要求，如果不做這一強(qiáng)制性變換將出現(xiàn)類型錯誤。類型的變換可在編譯時完成，通常是隱式地進(jìn)行，當(dāng)然也可以在動態(tài)運(yùn)行時來做。從實現(xiàn)的角度來看，多態(tài)可劃分為兩類，分別是編譯時的多態(tài)和運(yùn)行時的多態(tài)。前者是在編譯的過程中確定了同名操作的具體操作對象，而后者則是在程序運(yùn)行過程中才動態(tài)地確定操作所針對的具體對象。這種確定操作的具體對象的過程就是聯(lián)編（編聯(lián),束定

11、或綁定）。聯(lián)編是指計算機(jī)程序自身彼此關(guān)聯(lián)的過程，也就是把一個標(biāo)志符名和一個存儲地址聯(lián)系在一起的過程。用面向?qū)ο蟮男g(shù)語講，就是把一條消息和一個對象的方法相結(jié)合的過程。按照聯(lián)編進(jìn)行的階段的不同，可以分為兩種不同的聯(lián)編方法，分別為靜態(tài)聯(lián)編和動態(tài)聯(lián)編，這兩種聯(lián)編過程分別對應(yīng)著多態(tài)的兩種實現(xiàn)方式。聯(lián)編工作在編譯連接階段完成的情況稱為靜態(tài)聯(lián)編。因為聯(lián)編過程是在程序開始執(zhí)行之前進(jìn)行的，因此有時也稱為早期聯(lián)編或前聯(lián)編。在編譯和連接過程中，系統(tǒng)就可以根據(jù)類型匹配等特征確定程序中操作調(diào)用與執(zhí)行該操作代碼的關(guān)系，其確定了某一個同名標(biāo)志到底是要調(diào)用哪一段程序代碼。有些多態(tài)類型，其同名操作的具體對象能夠在編譯、連接階段

12、確定，通過靜態(tài)聯(lián)編解決，比如過載，強(qiáng)制和參數(shù)多態(tài)等。與靜態(tài)聯(lián)編相對應(yīng)，聯(lián)編工作在程序運(yùn)行階段完成的情況稱為動態(tài)聯(lián)編，也稱為晚期聯(lián)編或后聯(lián)編。在編譯、連接過程中無法解決的聯(lián)編問題，要等到程序開始運(yùn)行之后再來確定，包含多態(tài)的操作對象的確定就是通過動態(tài)聯(lián)編完成的。4.1.4消息通信消息（Message)是指向?qū)ο蟀l(fā)出的服務(wù)請求，它應(yīng)該含有下述信息：提供服務(wù)的對象標(biāo)志、消息名、輸入信息和回答信息。對象與傳統(tǒng)的數(shù)據(jù)有本質(zhì)區(qū)別，它不是被動地等待外界對它施加操作，相反，它是進(jìn)行處理的主體，必須發(fā)消息請求它執(zhí)行它的某個操作，處理它的私有數(shù)據(jù)，而不能從外界直接對它的私有數(shù)據(jù)進(jìn)行操作。消息通信（Communica

13、tion with Messages)也是面向?qū)ο蠓椒▽W(xué)中的一條重要原則，它與對象的封裝原則密不可分。封裝使對象成為一些各司其職、互不干擾的獨(dú)立單位；消息通信則為它們提供了唯一合法的動態(tài)聯(lián)系途徑，使它們的行為能夠互相配合，構(gòu)成一"t'有機(jī)的系統(tǒng)。只有同時使用對象、類、繼承與消息通信，才是真正面向?qū)ο蟮姆椒ā?.1.5面向?qū)ο蠓椒▽W(xué)的優(yōu)點(diǎn)與面向過程相比，面向?qū)ο蠓椒▽W(xué)具有以下優(yōu)點(diǎn)。(1)與人類習(xí)慣的思維方法一致：面向?qū)ο蠓椒▽W(xué)的出發(fā)點(diǎn)和基本原則，是盡可能模擬人類習(xí)慣的思維方式,使軟件開發(fā)的方法與過程盡可能接近人類認(rèn)識世界解決問題的方法與過程,也就是使描述問題的“問題域”與解決問

14、題的“解域”在結(jié)構(gòu)上盡可能一致。(2)穩(wěn)定性好：傳統(tǒng)的軟件開發(fā)方法基于功能分析與功能分解，軟件結(jié)構(gòu)緊密依賴于系統(tǒng)所要完成的功能，當(dāng)功能需求發(fā)生變化時將引起軟件結(jié)構(gòu)的整體修改。由于用戶需求變化大部分是針對功能的，因此這樣的系統(tǒng)是不穩(wěn)定的。面向?qū)ο蟮姆椒ㄓ脤ο竽M問題域中的實體，以對象為中心構(gòu)造軟件系統(tǒng)，當(dāng)系統(tǒng)的功能需求變化時并不會引起軟件結(jié)構(gòu)的整體變化。由于現(xiàn)實世界中的實體是相對穩(wěn)定的，因此以對象為中心構(gòu)造的軟件系統(tǒng)也是比較穩(wěn)定的。(3)可重用性好：面向?qū)ο蠓椒▽W(xué)在利用可重用的軟件成分構(gòu)造新的軟件系統(tǒng)時有很大的靈活性。繼承機(jī)制與多態(tài)性使得子類不僅可以重用其父類的數(shù)據(jù)結(jié)構(gòu)與程序代碼，并且可以方便地

15、修改和擴(kuò)充，而這種修改并不影響對原有類的使用。(4)較易開發(fā)大型軟件產(chǎn)品：由于用面向?qū)ο蠓椒▽W(xué)開發(fā)軟件時，構(gòu)成軟件系統(tǒng)的每個對象相對獨(dú)立。因此，可以把一個大型軟件產(chǎn)品分解成一系列相互獨(dú)立的小產(chǎn)品來處理。這不僅降低了開發(fā)的技術(shù)難度，而且也使得對開發(fā)工作的管理變得容易多了。(5)可維護(hù)性好：面向?qū)ο蟮能浖容^容易理解、容易修改、容易測試。4.2 UML概述在20世紀(jì)的8090年代，面向?qū)ο蟮姆治雠c設(shè)計（OOA&D)方法獲得了長足的發(fā)展，而且相關(guān)的研究也十分活躍，涌現(xiàn)了一大批新的方法學(xué)。其中最著名的是Booch的Booch 1993、Jacobson的OOSE和Rumbaugh的OMT方法。

16、而UML正是在融合了Booch、Rumbaugh和Jacobson方法論的基礎(chǔ)上形成的標(biāo)準(zhǔn)建模語言。4.2.1 UM L是什么UML(Unified Modeling Language,統(tǒng)一建模語言）是用于系統(tǒng)的可視化建模語言，盡管它常與建模0 0軟件系統(tǒng)相關(guān)聯(lián)，但由于其內(nèi)建了大量擴(kuò)展機(jī)制，還可以應(yīng)用于更多的領(lǐng)域中，例如工作流程、業(yè)務(wù)領(lǐng)域等。(1)U M L是一種語言：UML在軟件領(lǐng)域中的地位與價值就像“1、2、3、+、-、”等符號在數(shù)學(xué)領(lǐng)域中的地位一樣。它為軟件開發(fā)人員之間提供了一種用于交流的詞匯表，一種用于軟件藍(lán)圖的標(biāo)準(zhǔn)語言。(2)UML是一種可視化語言：UML只是一組圖形符號，它的每個符

17、號都有明確語義，是一種直觀、可視化的語言。(3)UM L是一種可用于詳細(xì)描述的語言：UML所建的模型是精確的、無歧義和完整的，它適合于對所有重要的分析、設(shè)計和實現(xiàn)決策進(jìn)行詳描述。(4)UML是一種構(gòu)造語言：UML雖然不是一種可視化的編程語言，但其與各種編程語言直接相連，而且有較好的映射關(guān)系，這種映射允許進(jìn)行正向工程、逆向工程。(5)UM L是一種文檔化語言：它適合于建立系統(tǒng)體系結(jié)構(gòu)及其所有的細(xì)節(jié)文檔。4.2.2 U M L的發(fā)展歷史面向?qū)ο蠼ＵZ言，最早出現(xiàn)于20世紀(jì)70年代中期，而在20世紀(jì)80年代末開始進(jìn)入快速發(fā)展階段，截止到1994年，就從不到10種發(fā)展到50多種。由于每種語言、方法的創(chuàng)

18、造者都極力推崇自己的成果，于是爆發(fā)了“面向?qū)ο蠹夹g(shù)的方法大戰(zhàn)”，也從此流傳著一句戲言：“方法學(xué)家和恐怖分子的差別在于，方法學(xué)家不能談種。”而在1994年之后，各種方法論逐漸拉開了差距，以Grady Booch提出的Booch方法和James Rumbaugh提出的OMT(Object Modeling Technique,對象建模技術(shù)）成為了可視化建模語言的主。而Ivar Jacobson的Objectory方法則成為最強(qiáng)有力的方法。Booch是面向?qū)ο蠓椒ㄗ钤绲某咧?。他?984年Ad軟件工程(“SoftwareEngineering with Ada”）一書中就描述了面向?qū)ο筌浖_發(fā)的

19、基本問題。1991年，他在面向?qū)ο蟮脑O(shè)計（“Object-Oriented Design”）一書中，將以前針對Ad的工作擴(kuò)展到整個面向?qū)ο笤O(shè)計領(lǐng)域。他對繼承和類的闡述特別值得借鑒。Boochl993比較適合于系統(tǒng)的設(shè)計和構(gòu)造。Runbaugh等人提出了面向?qū)ο蟮慕＜夹g(shù)（OMT)，采用了面向?qū)ο蟮母拍畈⒁敫鞣N獨(dú)立于程序設(shè)計語言的表示符號。這種方法用對象模型、動態(tài)模型、功能模型和用例模型共同完成對整個系統(tǒng)的建模，所定義的概念和符號可用于軟件開發(fā)的分析、設(shè)計和實現(xiàn)的全過程，軟件開發(fā)人員不必在開發(fā)過程的不同階段進(jìn)行概念和符號的轉(zhuǎn)換。OMT-2特別適用于分析和描述以數(shù)據(jù)為中心的信息系統(tǒng)。Jacobs

20、on于1994年提出了面向?qū)ο筌浖こ蹋∣OSE)的方法。其最大特點(diǎn)是面向用例，并在用例的描述中引入了外部角色的概念。用例的概念貫穿于整個開發(fā)過程（包括對系統(tǒng)的測試和驗證)，是精確描述需求的重要武器。目前在學(xué)術(shù)界和工業(yè)界已普遍接受用例的概念，并認(rèn)為是面向?qū)ο蠹夹g(shù)走向第二代的標(biāo)志。OOSE比較適合支持商務(wù)工程和需求分析。面對眾多的建模語言，首先，用戶無力區(qū)分不同建模語言之間的差別和使用范圍。其次，各種建模語言其實各有長短。第三，由于不同的用戶使用不同的建模語言和不同建模語言表達(dá)方式上的差異，使得用戶之間的溝通方面出現(xiàn)了困難。要解決以上問題就必須在綜合分析各種不同建模語言的優(yōu)缺點(diǎn)及適用情況的基礎(chǔ)上

21、統(tǒng)一各種不同的建模語言。1994年10月，Grady Booch和Jim Rumbaugh開始了這項工作。首先他們將Booch1993和OMT-2統(tǒng)一起來，并于1995年10月發(fā)布了第一個公開版本稱為標(biāo)準(zhǔn)方法UM0.8(Unified Method)。1995年秋，OOSE的創(chuàng)始Ivar Jacobson加盟到這項工作中，經(jīng)過Booch、Rumbaugh和Jacobson三人的共同努力，于1996年6月和10月分別發(fā)布了兩個新的版本（UML0.9和UML0.91),并將UM重新命為UML。1996年,UML被OMG提議為0 0可視化建模語言的推薦標(biāo)準(zhǔn)，UML被提交。1997年，OMG采納了UM

22、L,個開放的0 0可視化建模語言工業(yè)標(biāo)準(zhǔn)誕生了。UML在經(jīng)歷了1.1、1.2和1.4三個版本的演變之后進(jìn)行了一次大的調(diào)整，升級為2.0版標(biāo)準(zhǔn)。目前UML的最新版是2010年11月發(fā)布的2.4版。4.2.3 UML結(jié)構(gòu)1.構(gòu)造塊構(gòu)造塊也就是基本的UML建模兀素、關(guān)系和圖。(1)建模元素：包括結(jié)構(gòu)元素（類、接口、協(xié)作、用例、活動類、組件、節(jié)點(diǎn)等)、行業(yè)元素（交互、狀態(tài)機(jī))、分組元素（包)、注解元素。(2)關(guān)系：包括關(guān)聯(lián)關(guān)系、依賴關(guān)系、泛化關(guān)系、實現(xiàn)關(guān)系。(3)圖：在UML1.X中包括9種不同的圖，當(dāng)升級為2.x之后，增加至14種圖。分為表示系統(tǒng)靜態(tài)結(jié)構(gòu)的靜態(tài)模型（包括類圖、對象圖、復(fù)合結(jié)構(gòu)圖、構(gòu)件

23、圖、部署圖、包圖），以及表示系統(tǒng)動態(tài)結(jié)構(gòu)的動態(tài)模型（包括用例圖、活動圖、狀態(tài)機(jī)圖、順序圖、通信圖、定時圖、交互概觀圖、制品圖）。2.公共機(jī)制公共機(jī)制是指達(dá)到特定目標(biāo)的公共UML方法，主要包括規(guī)格說明、修飾、公共分類和擴(kuò)展機(jī)制四種。(1)規(guī)格說明：規(guī)格說明是元素語義的文本描述，它是模型真正的核心。(2)修飾：UML為每一個模型元素設(shè)置了一個簡單的記號,還可以通過修飾來表達(dá)更多的信息。(3)公共分類：包括類元與實體（類元表示概念，而實體表示具體的實體)、接口和實現(xiàn)（接口用來定義契約，而是實現(xiàn)就是具體的內(nèi)容）兩組公共分類。(4)擴(kuò)展機(jī)制：包括約束（添加新規(guī)則來擴(kuò)展元素的語義)、構(gòu)造型（用于定義新的U

24、ML建模元素)、標(biāo)記值（添加新的特殊信息來擴(kuò)展模型元素的規(guī)格說明）。3.構(gòu)架UML對系統(tǒng)構(gòu)架的定義是：系統(tǒng)的組織結(jié)構(gòu)，包括系統(tǒng)分解的組成部分、它們的關(guān)聯(lián)性、交互、機(jī)制和指原則，這些提供系統(tǒng)設(shè)計的信息。具體來說，是指五個系統(tǒng)視圖。(1)邏輯視圖：以問題域的語匯組成的類和對象集合。(2)進(jìn)程視圖：可執(zhí)行線程和進(jìn)程作為活動類的建模，它是邏輯視圖的一次執(zhí)行實例。(3)實現(xiàn)視圖：對組成基于系統(tǒng)的物理代碼的文件和組件進(jìn)行建模。(4)部署視圖：把組件物理地部署到一組物理的、可計算節(jié)點(diǎn)上。(5)用例視圖：最基本的需求分析模型。4.2.4 U M L的主要特點(diǎn)UML統(tǒng)一了Booch、OMT、OOSE和其他面向?qū)?/p>

25、象方法的基本概念和符號，同時匯集了面向?qū)ο箢I(lǐng)域中很多人的思想，是從優(yōu)秀的面向?qū)ο蠓椒ê拓S富的計算機(jī)科學(xué)實踐中總結(jié)而成的。目前UML是最先進(jìn)、實用的標(biāo)準(zhǔn)建模語言，而且還在不斷發(fā)展進(jìn)化之中。UML是一種建模語言而不是一種方法，其中并不包括過程的概念，它本身是獨(dú)立于過程的，可以在使用過程中使用它。不過與UML結(jié)合最好的是用例驅(qū)動的、以體系結(jié)構(gòu)為中心的、迭代的、增量的開發(fā)過程。4.2.5 U M L的應(yīng)用領(lǐng)域作為一種標(biāo)準(zhǔn)建模語言，UML的核心是以面向?qū)ο蟮乃枷雭砻枋隹陀^世界，具有廣闊的應(yīng)用領(lǐng)域。目前主要應(yīng)用領(lǐng)域是在軟件系統(tǒng)建模，但是它同樣可以應(yīng)用于其他領(lǐng)域，如機(jī)械系統(tǒng)、企業(yè)機(jī)構(gòu)或業(yè)務(wù)過程，以及處理復(fù)雜

26、數(shù)據(jù)的信息系統(tǒng)、具有實時要求的工業(yè)系統(tǒng)或工業(yè)過程等?？傊琔ML是一個通用的標(biāo)準(zhǔn)建模語言，可以對任何系統(tǒng)的動態(tài)行為和靜態(tài)行為進(jìn)行建模。同時，標(biāo)準(zhǔn)建模語言UML可以對信息系統(tǒng)提供從需求分析到系統(tǒng)維護(hù)的整個生命周期提供有效的支持。在需求分析階段，可以通過用例模型來捕獲和組織用戶的需求，分析系統(tǒng)對于用戶的價值。通過用例建模，描述對系統(tǒng)感興趣的外部角色及其對系統(tǒng)（用例）的功能要求。分析階段主要關(guān)心問題域中的主要概念(如抽象、類和對象等）和機(jī)制，以及這些概念之間的相互協(xié)作，并用UML類圖來描述。至于類之間的協(xié)作關(guān)系則可以用交互圖和順序圖來描述。在分析階段，只對問題域的對象（現(xiàn)實世界的概念）建模，而不考慮

27、定義軟件系統(tǒng)中技術(shù)細(xì)節(jié)的類（如處理用戶接口、數(shù)據(jù)庫、通信和并行性等問題的類)。由于這些技術(shù)細(xì)節(jié)將在設(shè)計階段引入，因此設(shè)計階段為構(gòu)造階段提供更詳?shù)囊?guī)格說明。編碼階段的主要任務(wù)是將設(shè)計階段的設(shè)計結(jié)果轉(zhuǎn)換成為實際的代碼。在設(shè)計階段需要注意的是不要過早地考慮設(shè)計結(jié)果要用哪種編程語言實現(xiàn)。如果過早地考慮這個問題，會使設(shè)計工作陷入細(xì)節(jié)的泥潭，不利于對模型進(jìn)行全面理解。標(biāo)準(zhǔn)建模語言UML還可以對測試階段提供有效的支持。不同的測試階段可以使用不同的UML圖作為測試的依據(jù)。比如，在單元測試階段，可以使用類圖和類的規(guī)格說明來進(jìn)行測試；在集成階段，可以f用合作圖，活動圖和部署圖；系統(tǒng)測試和驗收測試階段則可以使用順序

28、圖和用例圖來驗證系統(tǒng)的外部行為。總之，標(biāo)準(zhǔn)建模語言UML能夠用面向?qū)ο蟮姆椒枋鋈魏晤愋偷南到y(tǒng)，并對系統(tǒng)開發(fā)從需求調(diào)研到測試和維護(hù)的各個階段進(jìn)行有效的支持。4.3 UML的建模機(jī)制UML是一個通用的可視化建模語言，用于對軟件進(jìn)行描述、可視化處理、構(gòu)造和建立軟件系統(tǒng)的文檔。它記錄了對必須構(gòu)造的系統(tǒng)的決定和理解，可用于對系統(tǒng)的理解、設(shè)計、瀏覽、配置、維護(hù)和信息控制。UML適用于各種軟件開發(fā)方法、軟件生命周期的各個階段、各種應(yīng)用領(lǐng)域，以及各種開發(fā)工具，UML是一種總結(jié)了以往建模技術(shù)的經(jīng)驗并吸收當(dāng)今優(yōu)秀成果的標(biāo)準(zhǔn)建模方法。UML包括概念的語義，表示法和說明，提供了靜態(tài)、動態(tài)、系統(tǒng)環(huán)境及組織結(jié)構(gòu)的模型。

29、它可被交互的可視化建模工具所支持，這些工具提供了代碼生成器和報表生成器。U M L標(biāo)準(zhǔn)并沒有定義一種標(biāo)準(zhǔn)的開發(fā)過程，但它適用于迭代式的開發(fā)過程。它是為支持大部分現(xiàn)存的面向?qū)ο箝_發(fā)過程而設(shè)計的。UM L不是一種可視化的編程語言，但是UML描述的模型可與各種編程語言直接相連，即可把用UML描述的模型映射成編程語言。UML2.X中包括14種不同的圖，分為表示系統(tǒng)靜態(tài)結(jié)構(gòu)的靜態(tài)模型（包括類圖、對象圖、復(fù)合結(jié)構(gòu)圖、構(gòu)件圖、部署圖、包圖)，以及表示系統(tǒng)動態(tài)結(jié)構(gòu)的動態(tài)模型（包括用例圖、活動圖、狀態(tài)機(jī)圖、順序圖、通信圖、定時圖、交互概觀圖、制品圖）。4.3.1用例圖用例實例是在系統(tǒng)中執(zhí)行的一系列動作，這些動作

30、將生成特定參與者可見的價值結(jié)果。一個用例定義一組用例實例。它確定了一個和系統(tǒng)參與者進(jìn)行交互、并可由系統(tǒng)執(zhí)行的動作序列。用例模型描述的是外部執(zhí)行者（Actor)所理解的系統(tǒng)功能。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反復(fù)討論的結(jié)果，表明了開發(fā)者和用戶對需求規(guī)格達(dá)成的共識。在UML中，用例表示為一個橢圓。圖4-2顯示了一個個圖書管理系統(tǒng)的用例圖。其中，“新增書籍信息”、“查詢書籍信息”、“修改書籍信息”、“登記外借情況”、“查詢外借情況”、“統(tǒng)計金額與冊數(shù)”等都是用例的實例。1.參與者參與者（Actor)代表與系統(tǒng)接口的任何事物或人，它是指代表某一種特定功能的角色，參與者都是虛擬的概

31、念。在UML中，用一個小表示參與者。圖4-2中的“圖書管理員”就是參與者。對于該系統(tǒng)來說，可以充當(dāng)圖書管理員角色的可能有多個人，由于他們對于系統(tǒng)而言均起著相同的作用，扮演相同的角色，因此只使用一個參與者表示。切忌不要為每一個可能與系統(tǒng)交互的真畫出一個參與者?？梢酝ㄟ^以下問題來幫助你尋找到系統(tǒng)的相關(guān)參與者。誰是系統(tǒng)的主要用戶？誰從系統(tǒng)獲得信息？誰向系統(tǒng)提供信息？誰從系統(tǒng)刪除信息？誰支付、維護(hù)系統(tǒng)？誰管理系統(tǒng)？系統(tǒng)需要與哪些其他系統(tǒng)交互？系統(tǒng)需要操縱哪些硬件？在預(yù)設(shè)的時間內(nèi)，有事情自動發(fā)生嗎？系統(tǒng)從哪里獲得信息？誰對系統(tǒng)的特定需求感興趣？幾個人在扮演同樣的角色嗎？一個扮演幾個不同的角色嗎？系統(tǒng)使用

32、外部資源嗎？系統(tǒng)用在什么地方？2.用例用例（UseCase)是對系統(tǒng)行為的動態(tài)描述，它可以促進(jìn)設(shè)計人員、開發(fā)人員與用戶的溝通，理解正確的需求，還可以劃分系統(tǒng)與外部實體的界限，是系統(tǒng)設(shè)計的起點(diǎn)。在識別出參與者之后，可以使用下列問題幫助識別用例：每個參與者的任務(wù)是什么？有參與者將要創(chuàng)建、存儲、修改、刪除或讀取系統(tǒng)中的信息嗎？什么用例會創(chuàng)建、存儲、修改、刪除或讀取這個信息嗎？參與者需要通知系統(tǒng)外部的突然變化嗎？需要通知參與者系統(tǒng)中正在發(fā)生的事情嗎？什么用例將支持和維護(hù)系統(tǒng)？所有的功能需求都對應(yīng)到用例中了嗎？系統(tǒng)需要何種輸入輸出？輸入從何處來？輸出到何處？當(dāng)前運(yùn)行系統(tǒng)的主要問題是什么？3.包含和擴(kuò)展兩

33、個用例之間的關(guān)系可以主要概括為兩種情況。一種是用于重用的包含關(guān)系，用構(gòu)造型include»表示；另一種是用于分離出不同的行為，用構(gòu)造型extend表示。(1)包含關(guān)系：當(dāng)你可以從兩個或兩個以上的原始用例中提取公共行為，或者發(fā)現(xiàn)能夠使用一個組件來實現(xiàn)某一個用例的部分功能是很重要的事時，應(yīng)該使用包含關(guān)系來表不它們。(2)擴(kuò)展關(guān)系：如果一個用例明顯地混合了兩種或兩種以上的不同場景，即根據(jù)情況可能發(fā)生多種事情。我們可以斷定將這個用例分為一個主用例和一個或多個輔用例描述可能更加清晰。4.3.2類圖和對象圖在面向?qū)ο蠼＜夹g(shù)中，對象是指現(xiàn)實世界中有意義的事物具有封裝性和自治性的特點(diǎn)，而類是指具有

34、相同屬性和行為的一組對象。類（Class)、對象（Object)和它們之間的關(guān)聯(lián)是面向?qū)ο蠹夹g(shù)中最基本的元素。對于一個想要描述的系統(tǒng)，其類模型和對象模型揭示了系統(tǒng)的結(jié)構(gòu)。在UML中，類和對象模型分別由類圖和對象圖表示。類圖技術(shù)是0 0方法的核心。圖4-5顯示了一個小型圖書管理系統(tǒng)的類圖。1.類和對象對象與我們對客觀世界的理解相關(guān)。它通常用來描述客觀世界中的某個具體的事物。因為類（Class)是對一組具有相同屬性，表現(xiàn)相同行為的對象的抽象。因此，對象是類的實例（Instance)。在UML中，類的可視化表示為一個劃分成3個格子的長方形（下面兩個格子可省略)。圖4-5中，“書籍”、“借閱記錄”等都

35、是一個類。(1)類的命名：最頂部的格子包含類的名字。類的命名應(yīng)盡量用應(yīng)用領(lǐng)域中的術(shù)語，應(yīng)明確、無歧義，以利于開發(fā)人員與用戶之間的相互理解和交流。(2)類的屬性：中間的格子包含類的屬性，用以描述該類對象的共同特點(diǎn)。該項可省略。圖4-5中“書籍”類有“書名”、“書號”等特性。UML規(guī)定類的屬性的語法為：“可見性屬性名：類型=默認(rèn)值約束特性”?？梢娦园≒ublic、Private和Protected，分別用+、-、#號表不。類型表示該屬性的種類：它可以是基本數(shù)據(jù)類型，例如整數(shù)、實數(shù)、布爾型等，也可以是用戶自定義的類型。一般它由所涉及的程序設(shè)計語言確定。約束特性則是用戶對該屬性性質(zhì)一個約束的說明。例

36、如“只讀”說明該屬性是只讀屬性。(3)類的操作（Operation):該項可省略。操作用于修改、檢索類的屬性或執(zhí)行某些動作。操作通常也被稱為功能，但是它們被約束在類的內(nèi)部，只能作用到該類的對象上。操作名、返回類型和參數(shù)表組成操作界面。UML規(guī)定操作的語法為“可見性：操作名（參數(shù)表)：返回類型約束特性”。.類圖描述了類和類之間的靜態(tài)關(guān)系。定義了類之后，就可以定義類之間的各種關(guān)系。2.類之間的關(guān)系.在建立抽象模型時，由于很少有類會單獨(dú)存在，大多數(shù)都將會以某種方式彼此通訊，因此我們還需要描述這些類之間的關(guān)系。關(guān)系是事物間的連接，在面向?qū)ο蠼Ｖ?，有四個很重要的關(guān)系。(1)依賴關(guān)系。有兩個元素A、B,

37、如果元素A的變化會引起元素B的變化，則稱元素B依賴（Dependency)于元素A。在UML中，使用帶箭頭的虛線表示依賴關(guān)系，在類中，依賴關(guān)系有多種表現(xiàn)形式，如：一個類向另一個類發(fā)消息；一個類是另一個類的成員；一個類是另一個類的某個操作參數(shù)等。(2)泛化關(guān)系。泛化關(guān)系描述了一般事物與該事物中的特殊種類之間的關(guān)系，也就是父類與子類之間的關(guān)系。繼承關(guān)系是泛化關(guān)系的反關(guān)系，也就是說子類是從父類中繼承的，而父類則是子類的泛化。在UML中，使用帶空心箭頭的實線表示，箭頭指向父類，如圖4-7所示。在UML中，對泛化關(guān)系有三個要求：子類應(yīng)與父類完全一致，父類所具有的關(guān)聯(lián)、屬性和操作，子元素都應(yīng)具有；子類中除

38、了與父類一致的信息外，還包括額外的信息。可以使用父類實例的地方，也可以使用子類實例。在如圖4-5所示的例子中，“書籍”與“非計算機(jī)類書籍”之間就是泛化關(guān)系。(3)關(guān)聯(lián)關(guān)系。關(guān)聯(lián)（Association)表示兩個類的實例之間存在的某種語義上的聯(lián)系。例如，一個老師在某學(xué)校工作，一個學(xué)校有多間教室。我們就為教室和學(xué)校、學(xué)校和教室之間存在著關(guān)聯(lián)關(guān)系。關(guān)聯(lián)關(guān)系為類之間的通信提供了一種方式，它是所有關(guān)系中最通用、語義最弱的。關(guān)聯(lián)關(guān)系通?？梢栽俜殖梢韵聨追N。.聚合關(guān)系：聚合關(guān)系（Aggregation)是關(guān)聯(lián)關(guān)系的特例。聚合關(guān)系是表示一種整體和部分的關(guān)系。如一個電話機(jī)包含一個話筒，一個電腦包含顯示器，鍵盤和

39、主機(jī)，這些都是聚合關(guān)系的例子。在UML中，聚合關(guān)系用一個帶空心菱形的實線表示，空心菱形指向的是代表“整體”的類，如圖4-8所示。組合關(guān)系：如果聚合關(guān)系中的表示“部分”的類的存在，與表示“整體”的類有著緊密的關(guān)系，例如“公司”與“部門”之間的關(guān)系，那么就應(yīng)該使用“組合”關(guān)系來表示。在UML中，使用帶有實心菱形的實線表示。(4)實現(xiàn)關(guān)系。實現(xiàn)關(guān)系是用來規(guī)定接口和實現(xiàn)接口的類或組件之間的關(guān)系。接口是操作的集合，這些操作用于規(guī)定類或組件的服務(wù)。在UML中，使用一個帶空心箭頭的虛線表示，如圖4-9所示。3.類圖類圖（Class Diagram)描述類和類之間的靜態(tài)關(guān)系。與數(shù)據(jù)模型不同，它不僅顯示了信息的

40、結(jié)構(gòu)，同時還描述了系統(tǒng)的行為。類圖是面向?qū)ο蠼Ｖ凶钪匾哪Ｐ汀?.對象圖UM L中對象圖與類圖具有相同的表示形式。對象圖可以看做是類圖的一個實例。對象是類的實例，對象之間的鏈（Link)是類之間的關(guān)聯(lián)的實例。對象與類的圖形表示相似，均為劃分成兩個格子的長方形（下面的格子可省略)。上面的格子是對象名，對象名下有下畫線；下面的格子記錄屬性值。鏈的圖形表示與關(guān)聯(lián)相似。對象圖常用于表示復(fù)雜的類圖的一個實例。4.3.3交互圖交互圖（Interactive Diagram)是表不各組對象如何依某種行為進(jìn)行協(xié)作的模型。通?？梢允褂靡粋€交互圖來表示和說明一個用例的行為。在UML中，包括兩種不同形式的交互圖，

41、分別是強(qiáng)調(diào)對象交互行為順序的順序圖，強(qiáng)調(diào)對象協(xié)作的協(xié)作圖，它們之間沒有什么本質(zhì)不同，只是排版不盡相同而已。1.順序圖順序圖（SequenceDiagram)用來描述對象之間動態(tài)的交互關(guān)系，著重體現(xiàn)對象間消息傳遞的時間順序。順序圖允許直觀地表示出對象的生存期。在生存期內(nèi)，對象可以對輸入消息做出響應(yīng)，并且可以發(fā)送信息。圖4-10是順序圖示例。正如圖4-10所示，順序圖存在兩個軸，水平軸表示不同的對象，即圖中的Client、Factory、Product等；而垂直軸表示時間，表示對象及類的生命周期。對象間的通信通過在對象的生命線間畫消息來表示。消息的箭頭指明消息的類型。順序圖中的消息可以是信號、操作

42、調(diào)用或類似于C+中的RPC(Remote Procedure Calls)和Jav中的RMI(Remote Method Invocation)。當(dāng)收到消息時，接收對象立即開始執(zhí)行活動，即對象被激活了。通過在對象生命線上顯示一個細(xì)長矩形框來表示激活。消息可以用消息名及參數(shù)來標(biāo)志，消息也可帶有順序號。消息還可帶有條件表達(dá)式，表示分支或決定是否發(fā)送消息。如果用于表示分支，則每個分支是相互排斥的，即在某一時刻僅可發(fā)送分支中的一個消息。2.協(xié)作圖協(xié)作圖（Collaboration Diagram)用于描述相互合作的對象間的交互關(guān)系和鏈接關(guān)系。雖然順序圖和協(xié)作圖都用來描述對象間的交互關(guān)系，但側(cè)重點(diǎn)不一樣

43、。順序圖著重體現(xiàn)交互的時間順序，協(xié)作圖則著重體現(xiàn)交互對象間的靜態(tài)鏈接關(guān)系。圖4-11是與圖4-10相對應(yīng)的協(xié)作圖。4.3.4狀態(tài)圖狀態(tài)圖（StateDiagram)用來描述對象狀態(tài)和事件之間的關(guān)系。我們通常用狀態(tài)圖來描述單個對象的行為。它確定了由事件序列引出的狀態(tài)序列，但并不是所有的類都需要使用狀態(tài)圖來描述它的行為。只有那些具有重要交互行為的類，我們才會使用狀態(tài)圖來描述。(1)狀態(tài)：又稱為中間狀態(tài)，用圓角矩形框表示；(2)初始狀態(tài)：又稱為初態(tài)，用一個黑色的實心圓圈表示，在一張狀態(tài)圖中只能夠有一個初始狀態(tài)：(3)結(jié)束狀態(tài)：又稱為終態(tài)，在黑色的實心圓圈外面套上一個空間圓，在一張狀態(tài)圖中可能有多個結(jié)

44、束狀態(tài)；(4)狀態(tài)轉(zhuǎn)移：用箭頭說明狀態(tài)的轉(zhuǎn)移情況，并用文字說明引發(fā)這個狀態(tài)變化的相應(yīng)事件是什么一個狀態(tài)也可能被分為多個子狀態(tài)，如果將這些子狀態(tài)都描繪出來的話，那這個狀態(tài)就是復(fù)合狀態(tài)。狀態(tài)圖適合用于表述在不同用例之間的對象行為，但并不適合于表述包括若干協(xié)作的對象行為。通常不會需要對系統(tǒng)中的每一個類繪制相應(yīng)的狀態(tài)圖，而會在業(yè)務(wù)流程、控制對象、用戶界面的設(shè)計方面使用狀態(tài)圖。4.3.5活動圖活動圖用來表示系統(tǒng)中各種活動的次序，它的應(yīng)用非常廣泛，既可用來描述用例的工作流程，也可以用來描述類中某個方法的操作行為?；顒訄D是由狀態(tài)圖變化而來的，它們各自用于不同的目的?；顒訄D依據(jù)對象狀態(tài)的變化來捕獲動作（將要執(zhí)

45、行的工作或活動）與動作的結(jié)果。活動圖中一個活動結(jié)束后將立即進(jìn)入下一個活動（在狀態(tài)圖中狀態(tài)的變遷可能需要事件的觸發(fā))。1.基本活動圖圖4-13給出了一個基本活動圖的例子。正如圖4-13所示，活動圖中與狀態(tài)圖類似，包括了初始狀態(tài)、終止?fàn)顟B(tài)，以及中間的活動狀態(tài)，每個活動之間，也就是一種狀態(tài)的變遷。在活動圖中，還引入了以下幾個概念。(1)判定：說明基于某些表達(dá)式的選擇性路徑，在UML中使用菱形表示。(2)分叉與結(jié)合：由于活動圖建模經(jīng)常會遇到并發(fā)流，因此在U M L中引入了如2.帶泳道的活動圖在前面說明的基本活動圖中，雖然能夠描述系統(tǒng)發(fā)生了什么，但無法說明完成這個活動的對象。針對OOP而言，這就意味著活

46、動圖沒有描述出各個活動由哪個類來完成。要想解決這個問題，可以通過泳道來解決這一問題。它將活動圖的邏輯描述與順序圖、協(xié)作圖的責(zé)任描述結(jié)合起來。下面是一個使用了泳道的例子，如圖4-14所示。3.對象流在活動圖中對象可以作為活動的輸入或輸出，對象與活動間的輸入/輸出關(guān)系由虛線箭頭來表示。如果僅表示對象受到某一活動的影響，則可用不帶箭頭的虛線來連接對象與活動。4.信號在活動圖中可以通過信號的發(fā)送和接收標(biāo)記來表示信號的發(fā)送和接收,發(fā)送和接收標(biāo)志也可與對象相連，用于表示消息的發(fā)送者和接收者。4.3.6構(gòu)件圖構(gòu)件圖是面向?qū)ο笙到y(tǒng)的物理方面進(jìn)行建模時要用的兩種圖之一。它可以有效地顯示一組構(gòu)件，以及它們之間的關(guān)

47、系。構(gòu)件圖中通常包括構(gòu)件、接口，以及各種關(guān)系。通常構(gòu)件指的是源代碼文件、二進(jìn)制代碼文件和可執(zhí)行文件等。而構(gòu)件圖就是用來顯示編譯、鏈接或執(zhí)行時構(gòu)件之間的依賴關(guān)系。例如，在圖4-15中，就是說明QueryClient.exe將通過調(diào)用QueryServer.exe來完成相應(yīng)的功能，而QueryServer.exe則需要Find.exe的支持，F(xiàn)ind.exe在實現(xiàn)時調(diào)用了Query.dll。通常，我們使用構(gòu)件圖可以完成以下工作。(1)對源代碼進(jìn)行建模：這樣可以清晰地表示出各個不同源程序文件之間的關(guān)系。(2)對可執(zhí)行體的發(fā)布建模：如圖4-15所示，將清晰地表示出各個可執(zhí)行文件、DLL文件之間的關(guān)系。

48、(3)對物理數(shù)據(jù)庫建模：用來表示各種類型的數(shù)據(jù)庫、表之間的關(guān)系。(4)對可調(diào)整的系統(tǒng)建模：例如，對于應(yīng)用了負(fù)載均衡、故障恢復(fù)等系統(tǒng)的建模。在繪制構(gòu)件圖時，應(yīng)該注意側(cè)重于描述系統(tǒng)的靜態(tài)實現(xiàn)視圖的一個方面，圖形不要過于簡化，應(yīng)該為構(gòu)件圖取一個直觀的名稱，在繪制時避免產(chǎn)生線的交叉。4.3.7部署圖部署圖，也稱為實施圖，它和構(gòu)件圖一樣，是面向?qū)ο笙到y(tǒng)的物理方面建模的兩種圖之一。構(gòu)件圖是說明構(gòu)件之間的邏輯關(guān)系，而部署圖則在此基礎(chǔ)上更近一步，描述系統(tǒng)硬件的物理拓?fù)浣Y(jié)構(gòu)，以及在此結(jié)構(gòu)上執(zhí)行的軟件。部署圖可以顯示計算結(jié)點(diǎn)的拓?fù)浣Y(jié)構(gòu)和通信路徑、結(jié)點(diǎn)上運(yùn)行的軟件構(gòu)件，常常用于幫助理解分布式系統(tǒng)。圖4-16就是與圖

49、4-15對應(yīng)的部署圖，這樣的圖示可以使系統(tǒng)的安裝、部署更為簡單。在部署圖中，通常包括以下一些關(guān)鍵的組成部分。1.節(jié)點(diǎn)和連接節(jié)點(diǎn)（Node)代表一個物理設(shè)備，以及其上運(yùn)行的軟件系統(tǒng)，如一臺WindowsNT主機(jī)、一個PC終端、一臺打印機(jī)、一個傳感器等。如圖4-16所示，“客戶端：PC”和“服務(wù)器”就是兩個節(jié)點(diǎn)。在UML中，使用一個立方體表示一個節(jié)點(diǎn)，節(jié)點(diǎn)名放在左上角。節(jié)點(diǎn)之間的連線表示系統(tǒng)之間進(jìn)行交互的通信路徑，在UML中被稱為連接。通信類型則放在連接旁邊的“”之間，表示所用的通信協(xié)議或網(wǎng)絡(luò)類型。2.構(gòu)件和接口在部署圖中，構(gòu)件代表可執(zhí)行的物理代碼模塊，如一個可執(zhí)行程序。邏輯上構(gòu)件可以與類圖中的包

50、或類對應(yīng)。例如在圖4-15中，“服務(wù)器”節(jié)點(diǎn).中包含“QueryServer.exe”、“Find.exe”和“Query.dll”3個構(gòu)件。在面向?qū)ο蠓椒ㄖ?，類和?gòu)件等元素并不是所有的屬性和操作都對外可見。它們對外提供了可見操作和屬性，稱為類和構(gòu)件的接口。界面可以表示為一頭是小圓圈的直線。在圖4-16中，“Query.dll”構(gòu)件提供了一個“查詢”接口。4.4面向?qū)ο蠓治鼍C觀計算機(jī)軟件發(fā)展史，許多新方法和新技術(shù)都是在編程領(lǐng)域首先興起，進(jìn)而發(fā)展到軟件生命周期的前期階段分析與設(shè)計階段。結(jié)構(gòu)化方法經(jīng)歷了從“結(jié)構(gòu)化編程”、“結(jié)構(gòu)化設(shè)計”到“結(jié)構(gòu)化分析”的發(fā)展歷程，面向?qū)ο蟮姆椒ㄒ步?jīng)歷了從“面向?qū)ο蟮?/p>

51、編程”O(jiān)bject-Oriented Programming,OOP)、“面向?qū)ο蟮脑O(shè)計”O(jiān)bject-OrientedDesign,O O D)到“面向?qū)ο蟮姆治觥監(jiān)bject-OrientedAnalysis,0 0 A)的發(fā)展歷程。1989年之后，面向?qū)ο蠓椒ǖ难芯恐攸c(diǎn)開始轉(zhuǎn)向軟件生命周期的分析階段，并將OOA和0 0 D密切地聯(lián)系在一起，出現(xiàn)了一大批面向?qū)ο蟮姆治雠c設(shè)計O O A&D)方法。到目前為止，公開發(fā)表并具有一定影響的OOA&D方法己達(dá)數(shù)十種。由于各種O O A方法所強(qiáng)調(diào)的重點(diǎn)與該方法的主要特色不同，因此所產(chǎn)生的OOA模型從整體形態(tài)、結(jié)構(gòu)框架到具體內(nèi)容都有較大的

52、差異。4.4.1 OM T方法筒介1991年，James Rumbaugh在面向?qū)ο蟮慕Ｅc設(shè)計（Object-Oriented Modeling and Design)一書中提出了面向?qū)ο蠓治雠c設(shè)計的OMT(Object Modeling Technique)方法。20世紀(jì)90年代中期，筆者曾使用OMT方法開發(fā)了“印典”、“書林”等排版系統(tǒng)。本書的OOA模型主要依據(jù)OMT方法，同時參考了Peter Coad和Edward Yourdon的OOA模型。OMT方法的OOA模型包括對象模型、動態(tài)模型和功能模型。對象模型表示靜態(tài)的、結(jié)構(gòu)化的系統(tǒng)的“數(shù)據(jù)”性質(zhì)。它是對模擬客觀世界實體的對象及對象彼此間

53、的關(guān)系的映射，描述了系統(tǒng)的靜態(tài)結(jié)構(gòu)。通常用類圖表示。動態(tài)模型表示瞬時的、行為化的系統(tǒng)的“控制”性質(zhì)，它規(guī)定了對象模型中的對象的合法變化序列。通常用狀態(tài)圖表示。功能模型表示變化的系統(tǒng)的“功能”性質(zhì)，由于它指明了系統(tǒng)應(yīng)該“做什么”，因此更直接地反映了用戶對目標(biāo)系統(tǒng)的需求。通常用數(shù)據(jù)流圖表示。OMT方法的三個模型，分別從三個不同側(cè)面描述了所要開發(fā)的系統(tǒng)：功能模型指明了系統(tǒng)應(yīng)該“做什么”；動態(tài)模型明確了什么時候做（即在何種狀態(tài)下接受了什么事件的觸發(fā))；對象模型則定義了做事情的實體。這三種模型相互補(bǔ)充、相互配合，三者之間具有下述關(guān)系。(1)動態(tài)模型展示了對象模型中每個對象的狀態(tài)及它接受事件和改變狀態(tài)時所

54、執(zhí)的操作；而功能模型中的處理則對應(yīng)于對象模型中的對象所提供的服務(wù)。(2)對象模型展示了動態(tài)模型中是誰改變了狀態(tài)和經(jīng)受了操作；而功能模型中的處理則可能產(chǎn)生動態(tài)模型中的事件。(3)對象模型展示了功能模型中的動作者、數(shù)據(jù)存儲和流的結(jié)構(gòu)；而動態(tài)模型則展示了功能模型中執(zhí)行加工的順序。1.建立對象模型Peter Coad和Edward Yourdon在1991年出版的面向?qū)ο蟮姆治鲆粫兄赋?，?fù)雜系統(tǒng)的對象模型通常由下述五個層次組成：類及對象層、結(jié)構(gòu)層、主題層、屬性層和服務(wù)層。上述五個層次對應(yīng)著建立對象模型的五項主要活動：確定類與對象、確定結(jié)構(gòu)與關(guān)聯(lián)、.劃分主題、定義屬性和定義服務(wù)。但這五項活動完全沒必要

55、順序完成，也無需徹底完成一項活動之后再開始另外一項活動。(1)確定類與對象。類與對象是在問題域中客觀存在的，系統(tǒng)分析的重要任務(wù)之一就是找出這些類與對象。首先找出所有候選的類與對象，然后進(jìn)行反復(fù)篩選，刪除不正確或不必要的類與對象。(2)確定結(jié)構(gòu)與關(guān)聯(lián)。結(jié)構(gòu)與關(guān)聯(lián)反應(yīng)了對象（或類）之間的關(guān)系，主要有以下幾種。一般-特殊結(jié)構(gòu)(Generalization-Specialization Structure),又稱分類結(jié)構(gòu)（Classification Structure),是由一組具有一般-特殊關(guān)系（繼承關(guān)系）的類所組成的結(jié)構(gòu)。一般-特殊關(guān)系（Generalization-Specialization

56、 Relation)的表達(dá)式為is a kind of。整體-部分結(jié)構(gòu)（Whole-Part Structure)，又稱組裝結(jié)構(gòu)（Composition Structure),是由一組具有整體-部分關(guān)系（組成關(guān)系）的類所組成的結(jié)構(gòu)。整體-部分關(guān)系(Whole-Part Relation)的表達(dá)式為has。實例關(guān)聯(lián)（Instance Connection)，即一個類的屬性中含有另一個類的實例（對象），它反映了對象之間的靜態(tài)聯(lián)系。消息關(guān)聯(lián)（Message Connection)，即一個對象在執(zhí)行自己的服務(wù)時需要通過消息請求另一個對象為它完成某個服務(wù)，它反映了對象之間的動態(tài)聯(lián)系。(3)劃分主題。在開

57、發(fā)大型、復(fù)雜軟件系統(tǒng)的過程中，為了降低復(fù)雜程度，需要把系統(tǒng)劃分成幾個不同的主題。注意,應(yīng)該按問題域而不是用功能分解方法來確定主題，應(yīng)該按照使不同主題內(nèi)的對象相互間依賴和交互最少的原則來確定主題。(4)定義屬性。為了發(fā)現(xiàn)對象的屬性，首先考慮借鑒以往的OO A結(jié)果，看看相同或相似的問題域是否有已開發(fā)的OOA模型，盡可能復(fù)用其中同類對象的屬性定義。然后，按照問題域的實際情況，以系統(tǒng)責(zé)任為目標(biāo)進(jìn)行正確的抽象，從而找出每一對象應(yīng)肴的屬性。(5)定義服務(wù)。發(fā)現(xiàn)和定義對象的服務(wù)，也應(yīng)借鑒以往同類系統(tǒng)的O O A結(jié)果并盡可能加以復(fù)用。然后，研究問題域和系統(tǒng)責(zé)任以明確各個對象應(yīng)該設(shè)立哪些服務(wù)，以及如何定義這些服

58、務(wù)。2.建立動態(tài)模型建立動態(tài)模型的第一步，是編寫典型交互行為的腳本。雖然腳本中不可能包括每個偶然事件，但至少必須保證不遺漏常見的交互行為。第二步，從腳本中提取出事件，確定觸發(fā)每個事件的動作對象及接受事件的目標(biāo)對象。第三步，排列事件發(fā)生的次序，確定每個對象可能有的狀態(tài)及狀態(tài)間的轉(zhuǎn)換關(guān)系，并用狀態(tài)圖描繪它們。最后，比較各個對象的狀態(tài)圖，檢查它們之間的一致性，確保事件之間的匹配。，3.建立功能模型OMT方法中的功能模型實際上就是結(jié)構(gòu)化方法中的數(shù)據(jù)流圖。從這點(diǎn)看，OMT方法并不是“純”面向?qū)ο蟮?。這是OMT方法的一大缺陷。1992年，Ivar Jacobson在面向?qū)ο蟮能浖こ逃美?qū)動的途徑(Object-Oriented Software Engineering,A Use Case Driven