第7章 建立設計模型

第7章建立設計模型設計模型是對分析模型的細化；設計模型和分析模型之間并沒有嚴格的界線；分析模型偏重于理解問題域，描述軟件要做什么，而設計模型則偏重于理解解決方案，描述軟件究竟要如何做；分析模型只對系統(tǒng)作高層次的抽象，不關心技術與實現(xiàn)底層的細節(jié)，而設計模型則需要得到更詳細更接近于程序代碼的設計方案；分析模型側重于對象行為的描述，而設計模型則側重于對象屬性和方法的描述；分析模型只關注功能性需求，而設計模型還需要考慮非功能性需求。第7章建立設計模型7.1設計模式的選擇與應用7.2構建設計類7.3詳細設計類7.4設計類間關系7.5活動圖7.6狀態(tài)圖7.7設計模型順序圖7.8設計模型的分包7.9邏輯視圖到構件視圖的映射總結7.1設計模式的選擇與應用1.問題引入軟件設計最重要的目標，一是要達到客戶對系統(tǒng)功能和性能的要求；二是要考慮軟件的生命周期，增強系統(tǒng)的可維護性，降低軟件的維護費用。軟件維護費用在軟件開發(fā)成本中占有相當大的比例，一個軟件項目能否盈利最關鍵的是看該軟件的維護費用的高低。如果一個軟件的可維護性較差，即可擴展性不強、可修改性差、可替換性不好，就會在該軟件上花費太大的維護成本，甚至由于改動太大而將整個系統(tǒng)推翻重做。引入設計模式的目的就是要達到第二個目標，即增強系統(tǒng)的可維護性。然而，設計模式一般不能提高軟件的功能和性能。那么什么是“軟件設計模式”呢？7.1設計模式的選擇與應用2.解答問題設計模式（DesignPatterns）這個術語是在1990年代，由ErichGamma等人，從建筑設計領域引入到計算機科學里去的。是對軟件設計中普遍存在而又反復出現(xiàn)的各種問題，所提出的解決方案。設計模式并不直接用來完成程序代碼的編寫，而是描述在各種不同的情況下，要如何解決問題的一種方案。設計模式主要是使不穩(wěn)定的依賴于相對穩(wěn)定、具體依賴于相對抽象，避免會引起麻煩的緊耦合，以增強軟件設計面對并適應變化的能力。

7.1設計模式的選擇與應用3.分析問題模式（Patterns）這個詞，來自于ChristopherAlexander的TheTimelessWayofBuilding一書。Alexander在研究建筑結構的優(yōu)質設計時，把模式定義為“在某一個情景下的問題解決方案”。他認為，每一種模式，都描述了在我們的環(huán)境中不斷重復出現(xiàn)的問題，并描述了該問題解決方案的核心。有了模式，人們可以無數(shù)次地使用這種解決方式，以不變應萬變，而不需要重新設計它。7.1設計模式的選擇與應用我們?yōu)槭裁匆獙W習設計模式？它究竟能幫助我們解決什么問題？設計模式至少可以讓我們：①復用解決方案②建立通用的術語③解放視角7.1設計模式的選擇與應用7.1.1Facade（門面）模式7.1.2Adapter（適配器）模式7.1.3Factory（工廠）模式7.1.1Facade（門面）模式1.問題引入當客戶程序和組件中各種復雜的子系統(tǒng)之間有了太多的耦合，隨著外部客戶程序和各子系統(tǒng)不斷演化，這種過多的耦合關系將使系統(tǒng)變得更加復雜而難以維護，因此，應用Facade模式，要求一個子系統(tǒng)的外部與其內部的通信時必須通過一個統(tǒng)一的Facade對象進行。Facade模式提供了一個高層次的接口，使得子系統(tǒng)更易于使用，并達到解耦合的目的。那么，F(xiàn)acade模式的原理是怎樣的？7.1.1Facade（門面）模式2.解答問題

Facade模式是對象的結構模式，它沒有一個一般化的類圖描述，圖7-1顯示了一個Facade模式的示意性對象圖。7.1.1Facade（門面）模式圖7-1Facade模式對象結構示意圖7.1.1Facade（門面）模式在這個對象圖中，有兩個角色：①Facade（門面）角色②子系統(tǒng)角色7.1.1Facade（門面）模式在門面模式中，通常只需要一個門面類，并且該門面類只有一個實例。但這并不意味著在整個系統(tǒng)里只能有一個門面類，一般地，每個子系統(tǒng)只有一個門面類。如果一個系統(tǒng)有多個子系統(tǒng)，每個子系統(tǒng)有一個門面類，整個系統(tǒng)可以有多個門面類。7.1.1Facade（門面）模式3.分析問題在以下情況下應用門面模式：(1)希望包裝或隱藏原有系統(tǒng)，提高原有系統(tǒng)的獨立性。(2)希望使用原有系統(tǒng)的功能，并且希望增加一些新的功能。(3)為一個復雜的子系統(tǒng)提供一個簡單接口。(4)在層次化結構中，可以使用Facade模式定義系統(tǒng)中每一層的入口。7.1.2Adapter（適配器）模式1.問題引入Adapter模式的意圖是將一個類的接口轉換成客戶希望的另外一個接口。Adapter模式是用于解決由于接口不兼容而不能一起工作的類的問題。使用Adapter模式后可以讓這些不兼容的類一起工作。那么，Adapter模式的結構是怎樣的？7.1.2Adapter（適配器）模式2.解答問題Adapter模式的結構，如圖7-2所示。圖7-2Adapter模式的結構示意圖7.1.2Adapter（適配器）模式3.分析問題假如有點、線、圓三種形狀，分別為這三種形狀創(chuàng)建類，命名為Point、Line、Circle，這些類都有“顯示”的行為?？蛻魧ο笾恍枰溃鼈儞碛械氖沁@些形狀中的一個，不必知道自己真正擁有的對象是點、線還是圓。定義一個形狀（Shape）類作為超類，然后由它派生出Point、Line、Circle三個類?？蛻魧ο髢H與Shape對象直接打交道，如圖7-3所示。7.1.2Adapter（適配器）模式圖7-3客戶對象與Shape、Point、Line、Circle對象之間的關系7.1.2Adapter（適配器）模式現(xiàn)在假設每個點（Point）、線（Line）、圓（Circle）對象都具有一些行為，比如“設置位置”、“獲取位置”、“設置顏色”、“獲取顏色”、“繪制自己”、“擦除自己”等。前四項對于每種類型的形狀來說其操作都是相同的，而對于后兩項，不同類型的形狀其操作略有不同。在此，使用多態(tài)來實現(xiàn)其接口問題，在Shape類中為這些行為定義了接口，然后在每個派生類中實現(xiàn)其相應的行為。其結構如圖7-4所示。7.1.2Adapter（適配器）模式圖7-4包含操作的Point、Line、Circle類7.1.2Adapter（適配器）模式利用多態(tài)，客戶對象只需告訴Point、Line或Circle對象要做一些事，每個Point、Line或Circle都會根據(jù)自己的類型做出相應的行為。到此，可能你會問，這與Adapter模式有什么關系？7.1.2Adapter（適配器）模式假設現(xiàn)在客戶要求我們實現(xiàn)一種新的形狀（Shape）——矩形（Rectangle）。有兩種方法可以完成這個任務，最直接的方法是：創(chuàng)建一個新的類——Rectangle類，來實現(xiàn)“矩形”這個“形狀”，同樣從Shape類派生出Rectangle類，這樣我們仍然可以獲得多態(tài)行為。但我們必須為Rectangle類編寫paint()、erasure()這兩個方法。這是一件比較費時費力的事。這樣，我們可以采用另一種方法：找一個Rectangle類的替代品。它可能會很好地處理矩形的相關問題。但非常遺憾！我們找到的替代品可能不兼容，并且不能被修改。假設這個Rectangle類的替代品名為TrueRectangle，并且方法名也不是paint和erasure，而是display和undisplay。如圖7-5所示。7.1.2Adapter（適配器）模式圖7-5包含不同方法名的TrueRectangle類7.1.2Adapter（適配器）模式怎么辦呢？我們不能直接使用TrueRectangle類，因為那樣就無法保持Shape類的多態(tài)行為。主要是因為：(1)無法從Shape類直接派生出TrueRectangle類。要這樣做的話，只能修改TrueRectangle類，將其超類改為Shape，但這是不被允許的，因為我們無權修改TrueRectangle類的代碼（例如，TrueRectangle類已無源代碼可修改）。(2)TrueRectangle類中的方法名稱和參數(shù)列表與Shape類的不同。7.1.2Adapter（適配器）模式要解決這種不兼容性，我們只能另想辦法。我們可以創(chuàng)建一個新類——Rectangle類，該類派生自Shape類。Rectangle類用來實現(xiàn)Shape接口而不必重寫TrueRectangle類中矩形的實現(xiàn)代碼。加入Rectangle類和TrueRectangle類后，其結構如圖7-6所示。5.3.1關聯(lián)圖7-6Rectangle類組合了TrueRectangle類7.1.2Adapter（適配器）模式由圖中看出，Rectangle類派生自Shape類，Rectangle對象包含TrueRectangle對象，Rectangle對象將收到的消息轉發(fā)給內部的TrueRectangle對象。Rectangle類與TrueRectangle類之間是組合關系，表示當一個Rectangle對象被實例化時，它必須實例化一個相應的TrueRectangle對象。Rectangle對象收到的任何請求都將被轉發(fā)給TrueRectangle對象，由TrueRectangle對象完成實際的任務。這里，Rectangle類被稱為Adapter（適配器），而TrueRectangle類則被稱為Adaptee（源類）。這就是所謂的Adapter模式。7.1.2Adapter（適配器）模式Adapter模式有兩種類型：(1)對象Adapter模式(2)類Adapter模式究竟使用哪個Adapter模式，要視實際情況而定。使用Adapter模式的意義在于復用（reuse）。使控制范圍之外的一個原有對象與某個接口匹配，當現(xiàn)有接口與現(xiàn)實環(huán)境要求不一致的時候使用。7.1.2Adapter（適配器）模式Adapter模式實際的應用場合主要有兩個：復用早期版本的程序代碼；系統(tǒng)需要使用已有的類，而此類的接口不符合系統(tǒng)的需要。設計系統(tǒng)時考慮使用第三方組件。建立一個可以重復使用的類，用于將第三方組件融入到當前系統(tǒng)中。7.1.2Adapter（適配器）模式Facade模式與Adapter模式的比較：Facade模式的目的是簡化接口，而Adapter模式的目的是將一個接口轉換成另一個現(xiàn)有的接口。一個Facade背后隱藏了多個類，而一個Adapter只隱藏了一個類。7.1.3Factory（工廠）模式假如有一個類A，當我們要實例化這個類時，最簡單的方法就是Aa=newA()。如果要做一些初始化的工作，通常我們會把這些操作寫在A的構造方法里，比如：Aa=newA(parameter);但是，也許有很多的初始化內容，如果把所有這些內容都放在構造方法里面，可能很不合適。在這種情形下可以使用工廠模式，協(xié)助完成一系列初始化工作。工廠模式專門負責將大量有共同接口的類實例化。工廠模式可以動態(tài)決定將哪一個類實例化，不必事先知道每次要實例化哪一個類。工廠模式有三種形態(tài)：SimpleFactory（簡單工廠）模式、FactoryMethod（工廠方法）模式和AbstractFactory（抽象工廠）模式。下面就以農產品管理系統(tǒng)的幾種水果和蔬菜（蘋果、葡萄、橙子、番茄、冬瓜、胡蘿卜）為例簡要介紹這三種形態(tài)的工廠模式。一、SimpleFactory模式

1.問題引入SimpleFactory模式的目的，是專門定義一個類來負責創(chuàng)建其它類的實例，被創(chuàng)建的實例通常都具有共同的父類。那么，簡單工廠模式的結構是怎樣的呢？一、SimpleFactory模式2.解答問題SimpleFactory模式的結構如圖7-7所示。圖7-7SimpleFactory（簡單工廠）模式一、SimpleFactory模式3.分析問題圖7-7中，水果（Fruit）被定義為接口，并定義了兩個方法：grow()和expressedJuice()。蘋果（Apple）、葡萄（Grape）和橙子（Orange）三個具體類實現(xiàn)了水果接口。水果工廠類（FruitFactory）定義了一個方法trafficFruit(which:int):Fruit，用來決定究竟要運送哪一種水果。其實現(xiàn)過程可用如下Java程序代碼表示，參見書P124~125。一、SimpleFactory模式從上面的Java程序代碼可以看出，當需要運送水果時，只需向水果工廠（FruitFactory）請求就可以了。水果工廠在接到請求后，會自行判斷創(chuàng)建和提供哪一種水果。二、FactoryMethod模式1.問題引入對于上面的簡單工廠模式來說，如果要增加一種或幾種新的水果（比如還要增加梨、草莓等）就比較麻煩。這時除了要定義幾個新增的水果類之外，還必須修改水果工廠和客戶端。從而可以看出，SimpleFactory（簡單工廠）模式的開放性比較差。如何來解決這種開放性比較差的問題呢？這就需要用到下面將要介紹的FactoryMethod（工廠方法）模式。然而，F(xiàn)actoryMethod模式的結構又是怎樣的呢？二、FactoryMethod模式2.解答問題將對象的創(chuàng)建交由父類中定義的一個標準方法來完成，而不是其構造方法，究竟應該創(chuàng)建何種對象由具體的子類負責。如圖7-8所示。二、FactoryMethod模式圖7-8FactoryMethod（工廠方法）模式二、FactoryMethod模式3.分析問題對于FactoryMethod模式，其實現(xiàn)過程用Java程序代碼表示，參見書P126~127。二、FactoryMethod模式從上面的Java程序代碼可以看出，工廠方法模式的核心在于一個抽象工廠類（FruitFactory），它允許多個具體類從抽象工廠類中繼承其創(chuàng)建的行為，從而可以成為多個簡單工廠模式的綜合，推廣了簡單工廠模式。同樣地，如果需要在工廠方法模式中新增加一種水果（如梨子），那么只需要再定義一個新的水果類（如Pear）以及它所對應的工廠類（如TrafficPear）。不需要修改抽象工廠（FruitFactory）和其它已有的具體工廠（TrafficApple、TrafficGrape和TrafficOrange），也不需要修改客戶端（Client）。三、AbstractFactory模式1.問題引入FactoryMethod模式針對的只是一種類別（如本例中的水果類Fruit），如果我們還要運送蔬菜，就不行了。在這種情況下，必須用到下面我們將要介紹的AbstractFactory（抽象工廠）模式。那么，AbstractFactory模式的結構又是如何的呢？三、AbstractFactory模式2.解答問題AbstractFactory模式提供一個共同的接口來創(chuàng)建相互關聯(lián)的多個對象。如圖7-9所示。三、AbstractFactory模式圖7-9AbstractFactory（抽象工廠）模式三、AbstractFactory模式3.分析問題對于AbstractFactory模式，其實現(xiàn)過程用Java程序代碼表示，參見書P128~129。三、AbstractFactory模式AbstractFactory模式只需向客戶端提供一個接口，使得客戶端在不必指定運送農產品的具體類型的情況下，創(chuàng)建多個類型中的產品對象。7.2構建設計類分析模型是邏輯上的解決方案，是設計模型的藍本。設計模型是物理上實現(xiàn)解決方案的藍本。在體系結構方面，分析模型面向問題領域，而設計模型面向實現(xiàn)環(huán)境。分析模型中類與類之間的關系，是最頂層的關系，我們把在分析階段得到的類稱為“分析類”；然而要實現(xiàn)這些類，還必須在設計階段做很多工作，比如增加接口、類、事件等以實現(xiàn)這些分析類，這個階段的類被稱為“設計類”。7.2.1從分析類生成設計類1.問題引入分析模型中的所有類都是分析類。分析類展示的是高層次的屬性和操作的集合，面向問題領域。它們表示最終的設計類可能具有的屬性和操作。分析模型是設計模型的輸入，設計模型是把實現(xiàn)技術加入分析模型后對分析模型的細化。如何從分析類生成設計類呢？7.2.1從分析類生成設計類2.解答問題分析類表示設計元素實例扮演的角色，可以使用一個或多個設計模型元素來實現(xiàn)這些角色。當然，單個設計元素也可以實現(xiàn)多個角色。如在分析階段的“客戶資料”類，在設計階段分成了兩個類，如圖7-10所示。7.2.1從分析類生成設計類圖7-10從分析類生成設計類7.2.1從分析類生成設計類3.分析問題分析類Customer中包含了聯(lián)系方式的一些屬性，如果客戶的聯(lián)系方式改變了，或者一個客戶不止一個聯(lián)系方式，就會增加Customer類的維護難度，因此，在設計階段必須把這些容易發(fā)生變化的部分抽取出來，封裝成另一個類，以提高其重用性。聯(lián)系方式（LinkMethod）類與客戶（Customer）類之間是聚合關系，可以使得一個客戶的聯(lián)系方式也可以用在其它的場合。7.2.1從分析類生成設計類設計類實現(xiàn)分析角色的一些基本方法：(1)分析類可以成為設計模型中的單個設計類。(2)分析類可以成為設計模型中的設計類的一部分。(3)分析類可以成為設計模型中的聚集設計類。（表示不能將該聚集中的部件顯式建模為分析類）。(4)分析類可以成為從設計模型中的相同類繼承的一組設計類。(5)分析類可以成為設計模型中的一組功能相關的設計類。(6)分析類可以成為設計模型中的設計子系統(tǒng)。7.2.1從分析類生成設計類(7)分析類可以成為設計子系統(tǒng)的部件，例如一個或多個接口以及它們的對應實施。(8)分析類可以成為設計模型中的關系。(9)分析類之間的關系可以成為設計模型中的設計類。(10)分析類主要處理功能需求并對來自“問題域”的對象建模；設計類在處理功能需求的同時還處理非功能需求并對來自“解決方案域”的對象建模。(11)可以使用分析類來表示“希望系統(tǒng)支持的對象”，而無需決定用硬件支持分析類的多少部分，用軟件支持分析類的多少部分。因此，可以使用硬件實現(xiàn)部分分析類，而根本不在設計模型中對分析類進行建模。7.2.2確定類的大小1.問題引入定義一個類時一個重要的方面，就是需要確定這個類的大小，這是決定類是否可以被方便地使用或重用的關鍵所在。太大或者太復雜的類難以維護和改變，但只要它所有的特征都建立在一個獨立的重要抽象之上，就可以設計一個相對來說比較大一些的類?？蛻舴障到y(tǒng)中的CustomerService（客戶服務人員）類就是一個相對比較大但容易理解的類。如何確定這個類的大小呢？7.2.2確定類的大小2.解答問題如圖7-11所示。該類具有可以處理的操作有：創(chuàng)建咨詢記錄、修改咨詢記錄、添加經驗庫等，這些操作都建立在客戶服務人員這個獨立的抽象模型之上。7.2.2確定類的大小圖7-11客戶服務人員類的部分操作7.2.2確定類的大小3.分析問題一般地，一個類所包含的屬性或操作最好不要超過20個，如果類所包含的屬性或操作太多，應該考慮將這個類根據(jù)其特征及職責范圍劃分成幾個更小的類。7.2.2確定類的大小一個類的特征必須可以提供它所需要的所有功能。一個完善的類操作可以提供以下四個方面的功能：(1)實現(xiàn)功能(2)訪問功能(3)管理功能(4)輔助功能7.3詳細設計類7.3.1設計公用類7.3.2設計類接口7.3.3設計屬性和方法7.3.1設計公用類1.問題引入一些公共算法通常以自由子程序或非成員函數(shù)的方式實現(xiàn)。如果將它們放在一個（或一些）已經存在的類中，就會降低這個類（或這些類）的內聚性。那么，在設計階段要如何來處理這些公共算法呢？7.3.1設計公用類2.解答問題最好將這些公共算法封裝成一個特定的類。這些用來包含非成員函數(shù)的特定的類被稱為公用類。7.3.1設計公用類3.分析問題軟件設計通常會考慮軟件的生命周期，提高軟件的可維護性。為了解決設計上的問題，最好應用軟件設計模式。設計模式的相關知識詳見7.1設計模式的選擇與應用。7.3.2設計類接口1.問題引入類接口是指其它類可以通過它訪問該類的方法。類接口通常被定義為公有的訪問方法。當為類接口確定最佳設計時，需要決定是創(chuàng)建盡可能多的特性（屬性）還是創(chuàng)建盡可能少的特性（屬性）。也就是說是要創(chuàng)建一個單獨但復雜的操作來處理所有復雜的行為，還是要創(chuàng)建使用一系列設計良好的簡單操作，每一個操作完成一項任務？7.3.2設計類接口2.解答問題用一系列設計良好的簡單操作對行為建模，比用復雜的操作更好一些。由于每一個簡單操作都只完成比較少的任務，接口的內聚性較高，所以更容易理解，也更容易重用，如圖7-12所示。7.3.2設計類接口圖7-12設計良好的簡單操作的類7.3.2設計類接口3.分析問題用一個單獨但復雜的操作來處理所有復雜的行為可以使類接口變得非常簡單，但是這個操作的參數(shù)和實現(xiàn)部分會變得相當復雜，因此，這部分內容的可理解性會變得很差，降低了系統(tǒng)的可維護性。如圖7-13所示，對整個用戶信息的獲取與設置只用了兩個接口，每個接口實現(xiàn)了比較復雜的行為，這種接口的設計凸顯出很大的弊病：目標不明確。因為可能所獲得的某些用戶信息并不會被使用。7.3.2設計類接口圖7-13具有簡單接口但復雜操作的類7.3.2設計類接口但使用過多的簡單操作會使類的接口變得很復雜、很難理解。因為可能存在幾個操作協(xié)作完成某一項任務的情況，這樣就降低了類接口的內聚性，增強了類接口之間的耦合性。7.3.2設計類接口結論：一個有著復雜操作的接口和有著太多操作的接口同樣難于理解。所以，通常會在這兩者之間進行權衡，可以通過盡可能地使類接口變得簡潔來使類變得容易理解和操作。7.3.3設計屬性和操作分析模型中已經描述了類的屬性和操作，它們包含了類的大體狀態(tài)和職責。但在建立分析模型時僅僅是為屬性和操作命名，而沒有詳細的定義。在建立設計模型時，需要對類的屬性和操作添加更多的詳細信息。比如，需要為屬性確定數(shù)據(jù)類型和初始值，還需要為操作添加參數(shù)和返回類型。一、設計屬性1.問題引入我們在前面的分析模型中確定了類的屬性名，如何確定屬性的數(shù)據(jù)類型與初始值并使用建模工具RationalRose描述出來呢？一、設計屬性2.解答問題屬性的UML定義格式為：可見性屬性名：數(shù)據(jù)類型＝[初始值]以CustomerService（客戶服務人員）類的屬性設計為例，結果如圖7-14所示。一、設計屬性圖7-14類的屬性設計一、設計屬性3.分析問題在圖7-14中，給CustomerService類定義了8個屬性，詳細情況見表8-1所示。一、設計屬性屬性名中文對照數(shù)據(jù)類型初始值name姓名String""sex性別String"男"age年齡int20phone聯(lián)系電話String""rank職位String""dept部門String""loginName登錄名String""password密碼String""表8-1CustomerService類屬性定義一、設計屬性在屬性和操作的規(guī)格說明中，可以用“public”、“protected”和“private”來定義屬性或操作的可見性。由于對象的封裝性和信息隱藏原則，類屬性可見性默認定義為“private”（私有的）。一、設計屬性屬性名里通常不含有空格，所以，如果需要用多個單詞來定義一個屬性名，這些單詞是緊挨著的。人們習慣于把第一個單詞小寫，其它單詞首字母大寫。例如，name和loginName等。一般使用名詞為屬性命名。一、設計屬性在設計屬性時，還需要考慮屬性的初始值。初始值有時也稱為默認值，是描述屬性時可選擇的特征，它描述了在創(chuàng)建對象（實例化對象）時對象中這個屬性的值，例如，CustomerService類的sex（性別）屬性的初始值為“男”。不同的對象其屬性值可能不相同，該值是可以改變的。一、設計屬性并不是所有對象的某個屬性都用同一個初始值。對某些屬性來說，每一個擁有這個屬性的對象需要的初始值是不同的。例如，來電咨詢類有一個咨詢時間屬性，當創(chuàng)建一個來電咨詢對象時，希望其咨詢時間就是系統(tǒng)的當前時間，所以，來電咨詢類的咨詢時間屬性的初始值被設置為“Now”。雖然每個來電咨詢對象的這個屬性初始值的類型相同，但不同對象之間的屬性值卻是不同的，該值由創(chuàng)建對象的時間來決定。一、設計屬性CustomerService類的sex屬性在RationalRose中的設計過程：選擇CustomerService類，鼠標右鍵單擊，彈出快捷菜單；選擇【OpenSpecification…】菜單項，打開【ClassSpecificationforCustomerService】對話框；在對話框中選擇【Attributes】選項頁；在下面列表框的空白處點擊鼠標右鍵，在彈出的快捷菜單中選擇【Insert】項；在列表框中增加一項，將其名字改為“sex”并雙擊該項；彈出【ClassAttributesSpecificationforsex】對話框，分別在Type（數(shù)據(jù)類型）、Initial（初始值）中輸入“String”、“男”。二、設計操作1.問題引入在項目的詳細設計階段除了設計類的屬性外，還需要為操作添加更多的詳細信息。所以，除了在分析階段為操作命名外，還需要詳細描述操作的兩個重要部分：參數(shù)列表和返回類型。如何確定操作的參數(shù)列表與返回類型并使用建模工具RationalRose描述出來呢？二、設計操作2.解答問題類操作的UML表示格式為：可見性操作名（參數(shù)列表）：返回類型以設計CustomerService類的操作為例，其結果見圖7-20和圖7-21所示。圖7-20CustomerService類的操作設計窗口二、設計操作圖7-21CustomerService類的部分操作的UML表示二、設計操作3.分析問題在圖7-21中，我們?yōu)镃ustomerService類定義了18個操作，詳細情況見書中P137~138的表8-2所示。二、設計操作參數(shù)列表包含了0個或多個參數(shù)。如果參數(shù)個數(shù)多于1個，則參數(shù)之間用逗號（“，”）分隔。操作的參數(shù)描述了與操作執(zhí)行相關的變量。在客戶服務系統(tǒng)中，customerID屬性用來唯一標識一個Customer對象。當某一個客戶資料需要修改時，必須根據(jù)該客戶的customerID來查找其相關信息，所以，Customer類的deleteCustomer操作需要customerID參數(shù)。二、設計操作就像屬性的數(shù)據(jù)類型一樣，參數(shù)的數(shù)據(jù)類型描述了操作所用的數(shù)據(jù)。所以，deleteCustomer操作的customerID參數(shù)的類型，與Customer類的customerID屬性的類型一樣，都是整型（int）。屬性的數(shù)據(jù)類型決定了引用或改變此屬性操作的參數(shù)的數(shù)據(jù)類型。二、設計操作操作的返回類型描述了當操作完成后操作返回給對象的數(shù)據(jù)類型。操作如果有返回值，可以返回一個像int這樣的基本數(shù)據(jù)類型，或者把一個類作為返回類型。有時操作是沒有返回值的。在Java中用“void”表示操作沒有返回值時的返回類型。二、設計操作通常用動詞或動詞短語為操作命名。操作名稱里也沒有空格，因此操作名稱中包含的單詞也是緊挨著的。習慣上會把首單詞除外的其它單詞的首字母大寫，例如：getName。二、設計操作CustomerService類操作deleteCustomer在RationalRose中的設計過程：①打開圖7-15的對話框后，選擇【Operations】選項頁；②在列表框的空白處右擊鼠標，彈出快捷菜單，選擇【Insert】菜單項，此時，在列表框中新插入一項，修改操作名為“deleteCustomer”；③雙擊該操作項，打開【OperationSpecificationfordeleteCustomer】對話框；二、設計操作④在【General】頁的【Return】項輸入返回類型：void；⑤選擇【Detail】選項頁，在【Arguments】（參數(shù)列表）列表框的空白處右擊鼠標，在彈出的快捷菜單中選擇【Insert】菜單項；⑥修改參數(shù)名、類型分別為“customerID”、“int”如果操作有多個參數(shù)，則重復⑤、⑥兩步。二、設計操作概念7-1：操作簽名解答：操作名、參數(shù)及其類型和操作的返回類型合在一起稱為操作的簽名。擴展：一個類中，操作的簽名必須具有唯一性，也就是說，一個類中的兩個操作不能具有相同的簽名。二、設計操作概念7-2：重載解答：一個類中，具有相同名稱和不同參數(shù)（指參數(shù)個數(shù)與參數(shù)類型的組合不同）的操作被稱為“重載”。擴展：具有相同名稱和參數(shù)（參數(shù)個數(shù)和參數(shù)類型都相同）而返回類型不同的操作不是重載。因為調用操作時并不描述操作的返回類型，被調用的對象并不能分辨只是返回類型不同的兩個操作。操作的重載體現(xiàn)了面向對象的多態(tài)性，常常應用于面向對象的接口開發(fā)中。例如，我們在前面所舉的例子中，Shape類的paint操作就是重載。Shape對象可以根據(jù)paint操作不同的參數(shù)畫出不同的形狀。7.4設計類間關系7.4.1設計繼承7.4.2設計聚合/組合7.4.3設計關聯(lián)2023/1/11927.4.1設計繼承1.問題引入分析階段所建立的繼承關系沒有考慮屬性與操作的重組問題，為了加強重用性，細化分析階段的繼承層次可以減少代碼量，有助于模型的一致性。這就意味著如果幾個類繼承了同一個超類，那么這幾個類中相同的屬性和操作將會做一些處理：重新排列類的屬性和操作。將類分組以標識公共行為?？蛻舴障到y(tǒng)中，“系統(tǒng)用戶”類與“部門領導”類、“客戶服務人員”類、“維護人員”類、“系統(tǒng)管理員”類之間是繼承關系。設計階段如何來細化這種繼承關系？7.4.1設計繼承2.解答問題細化后類之間的繼承關系如圖7-24所示。圖7-24細化后類之間的繼承關系7.4.1設計繼承3.分析問題“部門領導”、“客戶服務人員”、“維護人員”和“系統(tǒng)管理員”這四個類性質相同，他們都是系統(tǒng)的用戶，具有相同的屬性（如姓名、性別、年齡、職位等）和操作（如增加信息、刪除信息等），因此，我們將這些類共同的屬性和操作抽取出來，抽象為超類“系統(tǒng)用戶”（User）類，其它類由該類派生出來。由于add（增加）、delete（刪除）、modify（修改）、retrieve（檢索）這四個操作與派生類相關，也即是說，派生類不同，這四個操作的具體內容是不相同的，所以，需要將User類確定為抽象類，四個操作則在各自的派生類中實現(xiàn)。7.4.1設計繼承大家請注意：類的“繼承”關系雖然可以加強重用，但“繼承”又加劇了對象之間的依賴性。濫用“繼承”，往往會給軟件維護帶來極大的麻煩！例如，圖7-25中，將不同領域的類之間形成繼承關系，這是必須避免的。7.4.1設計繼承圖7-25不同領域的類之間形成錯誤的繼承關系7.4.2設計聚合/組合繼承關系加強了類之間的耦合性，而聚合/組合關系則可以解耦合、增強類的內聚性。在設計階段通常要把一般的關聯(lián)關系細化為聚合/組合關系。類與類之間的聚合/組合關系詳見5.3。7.4.2設計聚合/組合1.假如類A與類B之間有如圖7-26所示的一對一的單向聚合關系，則代碼映射為：publicclassA{protectedBtheB;//類B作為類A的一個成員變量

……}publicclassB{……}圖7-26一對一的聚合加單向關聯(lián)7.4.2設計聚合/組合2.假如類A與類B之間有如圖7-27所示的一對多的單向聚合關系，則代碼映射為：publicclassA{protectedArrayList

theBs;//類B的對象數(shù)組

……}publicclassB{……}圖7-27一對多的聚合加單向關聯(lián)7.4.2設計聚合/組合3.假如類A與類B之間有如圖7-28所示的一對一的單向組合關系，則代碼映射為：publicclassA{protectedclassB{……}protectedBtheB;……}圖7-28一對一的組合加單向關聯(lián)7.4.2設計聚合/組合4.假如類A與類B之間有如圖7-29所示的一對多的單向組合關系，則代碼映射為：publicclassA{protectedclassB{……}protectedArrayList

theBs;//類B的對象數(shù)組

……}圖7-29一對多的組合加單向關聯(lián)7.4.3設計關聯(lián)設計模型中需要細化的關聯(lián)主要是關聯(lián)的導航方向。在分析階段通常不會考慮到導航方向，其分析模型中關聯(lián)的導航往往是雙向的，然而實現(xiàn)雙向關聯(lián)要比實現(xiàn)單向關聯(lián)困難得多，所以，在設計階段，必須根據(jù)實際情況，將有些關聯(lián)確定為單向導航。除非兩個類都需要從對方獲得信息，才需要建立雙向關聯(lián)，否則最好建立為單向關聯(lián)，以簡化問題的實現(xiàn)。7.5活動圖1.問題引入活動圖是一種對動態(tài)行為建模的交互圖。它常用來對業(yè)務流程建模，但您也可以使用它對對象在交互期間執(zhí)行的操作（類的操作）建模。在RationalRose中如何建立活動圖？7.5活動圖2.解答問題以客戶服務人員處理來電咨詢?yōu)槔⒒顒訄D，其結果如圖7-30所示。7.5活動圖圖7-30客戶服務人員處理來電咨詢活動圖7.5活動圖3.分析問題一個基本活動圖通常具有以下元素：開始點：用填充的圓圈表示。在同一個包的同層次活動圖中，只允許存在一個開始點。結束點：活動圖可以有一個或多個結束點，用牛眼符號表示?；顒樱罕硎竟ぷ髁鞒讨械娜蝿栈虿襟E。用環(huán)繞著活動文本的圓頭矩形表示。如圖7-30中的“來電咨詢”、“查詢客戶信息”等。7.5活動圖活動轉換：用來顯示活動狀態(tài)的先后順序。決策：用判斷菱形表示。為其定義一組警戒條件。警戒條件控制當某個任務完成時轉換到一組備選轉移中的哪一個轉移。通常用在兩個或兩個以上分支的情況。同步條：用來處理并行子流程。7.5活動圖圖7-32帶同步條的活動圖7.5活動圖4.問題擴展：泳道從上面的基本活動圖中，我們發(fā)現(xiàn)活動圖有一個主要缺點：它沒有顯示出由誰或者什么負責來執(zhí)行某項活動。當用活動圖對業(yè)務過程建模時，它沒有顯示哪個部門或人負責哪些活動。當用活動圖對對象交互建模時，它沒有顯示出由哪個對象對哪些活動負責。如何解決這個問題呢？解答：為了給活動圖中的活動指明責任者，必須在活動圖中放置泳道。泳道是將圖劃分為職責域的垂直線。如圖7-33所示?；顒訄D的優(yōu)缺點(1)活動圖的優(yōu)點活動圖與順序圖和協(xié)作圖相比，主要有兩個優(yōu)點：可以對平行行為建模?；顒訄D因為有顯示平行活動的能力，所以很適合為多線程應用和并發(fā)應用建模?？梢燥@示多個用例如何相互關聯(lián)。這樣，可以使用活動圖獲得一個系統(tǒng)中構件是如何交互的。另外，活動圖還可以用來優(yōu)化業(yè)務流程。在業(yè)務建模的早期，發(fā)現(xiàn)業(yè)務流程不合理，及時糾正，以優(yōu)化業(yè)務流程?；顒訄D的優(yōu)缺點(2)活動圖的缺點活動圖的主要缺點就是，只有使用泳道，才能清楚地顯示出該由哪個對象對哪個活動負責。但在復雜的活動圖上，涉及的泳道很多，使整個活動流程變得很不清晰，影響了人們對活動圖的理解。7.5活動圖圖7-33使用泳道的客戶服務人員處理來電咨詢活動圖7.6狀態(tài)圖1.問題引入狀態(tài)圖描述了一個對象基于事件反應的動態(tài)行為，顯示了該對象所處的可能狀態(tài)以及狀態(tài)之間的轉換，并給出了狀態(tài)變化的起點和終點。狀態(tài)圖與活動圖很相似。兩種圖的不同之處主要表現(xiàn)在：狀態(tài)圖以狀態(tài)為中心，而活動圖則以活動為中心。狀態(tài)圖通常用來對一個對象生命周期的離散的狀態(tài)建模，而活動圖更適合于對一個流程中的一系列活動建模。狀態(tài)圖通常用于顯示具有復雜行為和經歷許多狀態(tài)之間轉換的類。不必為系統(tǒng)中每個類都建立狀態(tài)圖。只有當行為的改變和狀態(tài)有關時才創(chuàng)建狀態(tài)圖。如何在RationalRose中建立狀態(tài)圖？7.6狀態(tài)圖2.解答問題以客戶服務系統(tǒng)中的“派工單”為例，創(chuàng)建狀態(tài)圖?！芭晒巍睜顟B(tài)圖如圖7-34所示。7.6狀態(tài)圖圖7-34“派工單”狀態(tài)圖7.6狀態(tài)圖3.分析問題在圖7-34中，“派工單”有五個狀態(tài)：新派工單、未分配、已分配未完成、已分配已完成、刪除派工單。當某一事件發(fā)生或某個條件滿足時，就在這五個狀態(tài)之間進行轉換。圖中還包含了一個開始狀態(tài)和一個結束狀態(tài)。對象的狀態(tài)圖具有以下元素：7.6狀態(tài)圖開始狀態(tài)：由一個實心圓圈表示。每個類必須有一個開始狀態(tài)，并且只能有一個開始狀態(tài)。終止狀態(tài)：由一個牛眼符號表示。終止狀態(tài)是可選的，對象可以有多個終止狀態(tài)。狀態(tài)：由環(huán)繞著狀態(tài)文本的圓角矩形表示。一個狀態(tài)表示一個對象在其生命周期中滿足某個條件或等待某個事件發(fā)生的一個條件或情形。每個狀態(tài)代表了它的行為軌跡。狀態(tài)轉換：由帶箭頭的直線表示。一個狀態(tài)轉換表示一個對象在源狀態(tài)將執(zhí)行某些特定的動作，并當某個特定的事件發(fā)生或某些條件滿足時，進入目標狀態(tài)。狀態(tài)轉換是兩個狀態(tài)之間的關系。7.6狀態(tài)圖狀態(tài)轉換是互斥的。因為對象不能同時轉換到多種狀態(tài)，所以，在狀態(tài)圖中每次只能有一個向外的轉換發(fā)生。7.6狀態(tài)圖4.問題擴展：子狀態(tài)簡單狀態(tài)是指不含子結構的狀態(tài)。如圖7-34中所有的狀態(tài)都不含有子結構，因此這些狀態(tài)都是簡單狀態(tài)。含有子狀態(tài)（內嵌狀態(tài)）的狀態(tài)被稱為組合狀態(tài)。在狀態(tài)圖中一個狀態(tài)可以內嵌任意層的子狀態(tài)。子狀態(tài)通過顯示僅在特定環(huán)境（封閉狀態(tài)）內可能存在的某些狀態(tài)，用以簡化復雜的狀態(tài)圖。7.6狀態(tài)圖子狀態(tài)是一種包含在超狀態(tài)中的狀態(tài)。圖7-35中顯示了三個子狀態(tài)：未分配、已分配未完成和已分配已完成，它們都內嵌在“處理派工單”超狀態(tài)中。在嵌套狀態(tài)中還可以包含一個開始狀態(tài)和至少一個終止狀態(tài)。7.6狀態(tài)圖圖7-35含有子狀態(tài)的組合狀態(tài)圖7.6狀態(tài)圖從整體上看，組合狀態(tài)圖減少了轉換數(shù)，組織結構更有邏輯性，并且對象生命周期也更容易觀察，因此，組合狀態(tài)圖減少了圖形的復雜性，更適合用于對更大、更復雜的問題建模。7.7設計模型順序圖1.問題引入我們在第5章的分析建模中已對順序圖有了比較詳細的了解，在這里為什么還要談及順序圖呢？這是因為在分析階段只是對業(yè)務邏輯進行了比較高層次的抽象，所建立的分析模型是領域模型，沒有考慮任何實現(xiàn)技術，分析出來的類僅包括邊界類、控制類和實體類。因此，在分析模型的基礎上，我們還必須對其進行細化。考慮設計模式（有關設計模式的問題參閱本章的第一節(jié)）、數(shù)據(jù)處理方式以及分層結構等。這樣，用例中的消息流程將變得更加復雜。為了增強模型的可讀性與可理解性，有必要在設計階段細化順序圖，也因此發(fā)現(xiàn)更多的設計類。如何細化分析階段的順序圖呢？7.7設計模型順序圖2.解答問題現(xiàn)以B/S三層體系結構為例。隨著軟件工程的不斷發(fā)展和規(guī)范以及面向對象編程思想的日益成熟，人們對封裝、復用、擴展、移植等方面的深刻認識，產生了三層架構體系。所謂“三層”，是指表示層、業(yè)務層和數(shù)據(jù)層。這三層只是邏輯上的三層。通過引入業(yè)務層，將復雜的業(yè)務邏輯從傳統(tǒng)的兩次（C/S）應用模型中分離出來，并提供了可伸縮、易于訪問、易于管理、易于維護的方法，同時增強了應用程序可用性、安全性、封裝復用性、可擴展性和可移植性，從而實現(xiàn)了便捷、高效、安全、穩(wěn)定的企業(yè)級系統(tǒng)應用。7.7設計模型順序圖考慮三層體系結構以后，順序圖應細化為圖7-36的形式。圖7-36細化后的順序圖7.7設計模型順序圖3.分析問題我們從圖7-36中可以看出，Actor和邊界類屬于表示層，業(yè)務層包括控制類與實體類，而數(shù)據(jù)層則包含了數(shù)據(jù)服務類、數(shù)據(jù)訪問類和存儲。所有業(yè)務邏輯封裝在實體類中；而對各種數(shù)據(jù)庫的訪問，如數(shù)據(jù)庫的連接、打開、事務處理、關閉等，則封裝到數(shù)據(jù)訪問類，提供數(shù)據(jù)服務的接口；各種業(yè)務請求，如增加、刪除、修改等，被封裝到數(shù)據(jù)服務類中。將在細化順序圖時增加的數(shù)據(jù)服務類和數(shù)據(jù)訪問類添加到類圖中。細化后的順序圖包含了數(shù)據(jù)的處理流程。增加了數(shù)據(jù)服務類和數(shù)據(jù)訪問類，提高了構件的重用性，同時也增強了系統(tǒng)的可維護性。7.8設計模型的分包我們可以將設計模型分解成較小的單元，以使其更易于理解。通過將設計模型元素分組成包和子系統(tǒng)，然后顯示這些組如何互相關聯(lián)，可以更容易理解模型的整體結構。大家注意，設計模型的分包只是用于設計類的分組。例如，客戶服務系統(tǒng)的包結構，如圖7-37所示。7.8設計模型的分包圖7-37客戶服務系統(tǒng)設計模型包結構7.8設計模型的分包概念7-3：包內容的可見性解答：包中包含的類可以是公有的或私有的。所有其它類都可以和公有類相關聯(lián)，但私有類只可以和包中包含的類相關聯(lián)。包接口由包的公有類組成。包接口（公有類）分隔其它包并與其它包產生依賴關系。7.8設計模型的分包1.問題引入軟件設計項目千差萬別，隨著網絡技術的不斷發(fā)展，項目的規(guī)模越來越大，也越來越復雜，為了便于理解，我們在建模時通常會把模型元素分組成包或子系統(tǒng)。對于小型系統(tǒng)來說，分包比較容易，但對于大中型系統(tǒng)，如果沒有一個統(tǒng)一的規(guī)則，可能會引起許多混亂，導致模型的可讀性變差。那么，對于設計模型的分包究竟有什么規(guī)律可循呢？7.8設計模型的分包2.解答問題根據(jù)RUP設計模型的分包指南，可以從以下幾個方面來確定包結構。(1)封裝邊界類當將邊界類分發(fā)到包時，可以應用兩種不同的策略，選擇哪一種策略應取決于將來是否會大幅度地更改系統(tǒng)接口。7.8設計模型的分包①如果有可能會替換系統(tǒng)接口，或進行大量更改，則應將該接口與設計模型的其余部分分開。更改用戶接口時，只影響這些包。如果主要目標是簡化重大接口的更改，則應將邊界類放置在一個（或幾個）單獨的包中。②如果沒有打算進行重大接口更改，則應將邊界類和與其功能相關的實體類和控制類放在一起。這樣，就能夠容易地看到在更改某個實體類或控制類的情況下將影響哪些邊界類。為簡化對系統(tǒng)服務的更改，往往將邊界類和與其功能相關的類封裝在一起。對于在功能上與任何實體類或控制類都不相關的必需邊界類，應將它們和屬于同一接口的邊界類放置在單獨的包中。7.8設計模型的分包(2)封裝功能相關的類應為功能相關的每組類確定一個包。當判斷兩個類是否功能相關時，可以應用下面幾個條件：①如果一個類的行為和/或結構中的更改使另一個類中也有必要更改，則這兩個類在功能上相關。②可以通過以一個類（例如，實體類）開始并檢查從系統(tǒng)中刪除它會有什么影響，來判斷這個類是否與另一個類在功能上相關。所有由于刪除某個類而變得多余的類都與被刪除的類有某種聯(lián)系。多余性表示只有被刪除的類才使用該類，或該類自身依賴于被刪除的類。7.8設計模型的分包③如果兩個對象使用大量消息交互或有其它方式的復雜的相互通信，則它們可以是功能相關的。④如果邊界類的功能是顯示特定實體類，則邊界類可與該特定實體類功能相關。⑤如果兩個類與同一個參與者交互或受到同一參與者中的更改的影響，則這兩個類可以是功能相關的。如果兩個類不涉及相同的參與者，則它們不應放在相同的包中。7.8設計模型的分包⑥如果兩個類之間有關系（關聯(lián)、聚合、組合等），則這兩個類可以是功能相關的。當然，不能盲目地遵循該條件，但當沒有其它條件適用時，可以使用它。⑦某個類可以與創(chuàng)建該類實例的類功能相關。以下兩個條件可以用于確定不應將兩個類放在相同的包中：與不同參與者相關的兩個類不應放到相同的包中。不應將可選類和強制類放到相同的包中。7.8設計模型的分包3.分析問題如果一個包中的類與不同包中的類有關聯(lián)，則這些包互相依賴。應使用包之間的依賴關系對包依賴建模。包之間的依賴關系體現(xiàn)了包之間的耦合程度。如果包與包之間有太多或太復雜的依賴關系，則會使系統(tǒng)變得難以維護。7.8設計模型的分包包耦合有好處也有壞處：好處是因為耦合代表了重用；壞處是因為耦合代表了使系統(tǒng)難于更改和演化的依賴關系。包依賴可遵循一些原則：7.8設計模型的分包不應交叉耦合（即交叉依賴）包。例如，兩個包不應互相依賴，如圖7-38所示。在這些情況中，需要將包重新組織以除去交叉依賴關系。圖7-38兩個包A和B互相依賴7.8設計模型的分包下層中的包不應依賴于上層中的包。包應僅依賴于同一層和次下層中的包。如圖7-39中的情形應該避免。如果出現(xiàn)了這種情況，應該將功能重新分區(qū)。一種解決方案是按照接口聲明依賴關系，并組織下層中的接口。圖7-39下層包依賴于上層包7.8設計模型的分包通常情況下，除非依賴行為在所有層之間是公共的，否則依賴關系不得跳層，另一可選方法是簡單地在各層上傳遞操作調用。包不應依賴于子系統(tǒng)，僅應依賴于其他包或接口。7.9邏輯視圖到構件視圖的映射設計模型完成后，需要檢查整個模型的正確性。如在RationalRose中，可選擇【Tools】->【CheckModel】菜單項，由建模工具自動檢查模型。如果所建模型沒有錯誤，就可以選擇某種程序設計語言，由系統(tǒng)自動生成程序代碼；或自動生成關系數(shù)據(jù)庫了。但在自動生成程序代碼或關系數(shù)據(jù)庫之前，需要將邏輯視圖映射到構件視圖。7.9邏輯視圖到構件視圖的映射一、邏輯視圖包到構件視圖包的映射模型邏輯視圖中的信息是通過把邏輯視圖包映射到構件視圖包這種方式和模型的構件視圖中的信息聯(lián)系在一起的。通常，邏輯視圖包和物理視圖包是直接聯(lián)系在一起的。但是，有時也沒有必要進行一對一的映射。這是因為：7.9邏輯視圖到構件視圖的映射邏輯視圖包可能會因為實現(xiàn)的原因而被分開。邏輯視圖包可能會為了對象之間交流更加緊密而被合并。為了實現(xiàn)底層功能可能會加入分析中沒有的物理視圖包。7.9邏輯視圖到構件視圖的映射在RationalRose中把邏輯包映射到構件包的方法：(1)在構件視圖（ComponentView）中選擇構件包；(2)把它拖至邏輯視圖（LogicalView）中相應的包。7.9邏輯視圖到構件視圖的映射這時，在邏輯視圖的包上多了一個用圓括號括起來的包名，該包就是構件視圖相應的的構件包。映射后的視圖如圖7-40所示。圖7-40包的映射7.9邏輯視圖到構件視圖的映射二、把類映射到構件上在RationalRose中將類映射到構件上的方法：(1)選擇構件視圖（ComponentView）中的某個包中的構件；(2)將該構件拖曳至邏輯視圖（LogicalView）中相應包的相應類上，即完成了類到構件的映射。例如：將構件視圖中的bussiness包的CustomerService（客戶服務人員）構件拖曳至邏輯視圖中bussiness包的CustomerService類上。即可完成CustomerService類到CustomerService構件的映射。如圖7-41所示。7.9邏輯視圖到構件視圖的映射圖7-41類到構件的映射7.9邏輯視圖到構件視圖的映射三、生成程序代碼在RationalRose中生成程序代碼的步驟：第一步為構件設定程序設計語言要生成程序代碼，必須選定程序設計語言，其方法是：(1)右擊瀏覽窗口中的構件視圖（ComponentView）中某個包中的構件，如Customer構件，彈出快捷菜單；(2)選擇【OpenSpecification】項，打開構件的規(guī)格設定對話框；(3)在Language框中選擇相應的語言，比如：Java，如圖7-42所示；(4)點按Ok按鈕關閉對話框。7.9邏輯視圖到構件視圖的映射圖7-42為構件Customer指定程序設計語言7.9邏輯視圖到構件視圖的映射第二步生成程序代碼當選定程序設計語言后，就可以生成程序代碼了，其過程如下：(1)右擊瀏覽窗口中ComponentView中某個包中的構件，比如：Customer，彈出快捷菜單；(2)選擇【Java/J2EE->GenerateCode】項，彈出如圖7-43所示的對話框；(3)點擊【Edit…】按鈕，在彈出如圖7-44所示的對話框中，點擊【New（Insert）】按鈕，在增加的一項后邊，點擊帶三個點的按鈕，彈出如圖7-45所示的對話框；(4)點擊【Directory…】按鈕，給生成的Java文件指定放置路徑并確定；(5)返回到圖7-43的對話框中，選擇添加進來的路徑并點擊【Assign】按鈕；(6)點擊Ok按鈕，即可完成一個構件的生成。7.9邏輯視圖到構件視圖的映射圖7-43生成Java文件對話框7.9邏輯視圖到構件視圖的映射7-44類路徑管理對話框7.9邏輯視圖到構件視圖的映射7-45新增類路徑7.9邏輯視圖到構件視圖的映射四、構建數(shù)據(jù)庫結構1.實體類映射到關系數(shù)據(jù)庫我們先來看看用手工方式如何將要保存到數(shù)據(jù)庫中信息所對應的實體類映射到關系數(shù)據(jù)庫。在設計模型中，我們已對實體類以及實體類之間的關系建模，這樣我們就可以直接把實體類及其關系映射到關系數(shù)據(jù)庫。類可以映射為表，對象則映射為行（或記錄），屬性映射為列（或字段）。7.9邏輯視圖到構件視圖的映射(1)泛化（繼承）關系的映射如圖7-24的泛化關系，可以將超類和子類都映射成表，超類的主鍵作為所有子類的主鍵；也可以僅將子類分別映射成表，表的字段為各自子類屬性加超類屬性，每個表的主鍵分別定義。7.9邏輯視圖到構件視圖的映射(2)一對多關聯(lián)關系的映射圖7-46Customer類與Consultation類之間的一對多關聯(lián)關系7.9邏輯視圖到構件視圖的映射圖7-47圖7-456的關系數(shù)據(jù)庫的映射7.9邏輯視圖到構件視圖的映射從圖7-47中可以看出，外鍵放在關聯(lián)關系多的一端。PK指的是主鍵，而FK是指外鍵。7.9邏輯視圖到構件視圖的映射(3)一對一關聯(lián)關系的映射圖7-48Customer類與Consultation類之間的一對一關聯(lián)關系7.9邏輯視圖到構件視圖的映射圖7-49圖7-48的關系數(shù)據(jù)庫的映射7.9邏輯視圖到構件視圖的映射從圖7-49可以看出，如果兩個類是一對一的關系，則外鍵可以放在其中任意一個表中。7.9邏輯視圖到構件視圖的映射(4)多對多關聯(lián)關系的映射如果兩個類之間是多對多的關聯(lián)關系，例如“學生”與“課程”之間的關系（如圖7-50所示），假如要記錄學生的考試成績，則在映射關系數(shù)據(jù)庫時，必須添加第三個表：“成績”表?！皩W生”表和“課程”表的主鍵作為“成績”表的外鍵。如圖7-51所示。7.9邏輯視圖到構件視圖的映射圖7-50“學生”類與“課程”類之間的多對多連接關系7.9邏輯視圖到構件視圖的映射圖7-51圖7-50的關系數(shù)據(jù)庫的映射7.9邏輯視圖到構件視圖的映射(5)一對多的聚合/組合關系同一對多的關聯(lián)關系類似，“整體”表的主鍵