1、第8章類圖本章內容： 對簡單協作建模 對邏輯數據庫模式建模 正向與逆向工程類圖是面向對象系統的建模中最常見的圖。類圖顯示了一組類、接口、協作以及它們之間 的關系。類圖用于對系統靜態設計視圖建模。其大部分涉及到對系統的詞匯建模、對協作建模或對 模式建模。類圖也是兩個相關圖（構件圖和實施圖）的基礎。類圖不僅對結構模型的可視化、詳述和文檔化很重要，而且對通過正向與逆向工程構造可執行的系統也很重要。8.1入門當建造房屋時，要從包括像墻、樓板、門、窗、天花板和托梁的基本構造塊的詞匯開始。這些東西主要是結構性的（墻有高度、寬度和厚度），但也具有一些行為性（不同種類的墻支撐不同的負重，開關，對無支撐的樓板跨

2、度有一些約束）。事實上，不能單獨地考慮結為特征，而必須在建造房屋時考慮它們如何相互作用。建造房屋的過程涉及到以所要求的獨特和合意的方式裝配這些事物，以滿足所有的功能性和非功能。你創建的用來可視化你的房屋并詳述細節的藍圖實際上是對這些事物以及它們之間的關系的圖形描述。構造軟件也有許多與此相同的特性，所不同的只是對于給定的軟件的性，你有能力從草圖定義的基本構造塊。你可以用 UML的類圖對這些構造塊的靜態方面和它們之間的關系進行可視化，并描述其構造細節，如圖 8-1所示。8.2 術語和概念類圖（class diagram）是顯示一組類、接口、協作以及它們之間關系的圖。在圖形上，類圖是頂點和弧的集合。

3、1. 普通特性類圖是一種特殊的圖，它和所有的其他圖有相同的普通特性，即有名稱和投影到一個模型的圖形內容。類圖與所有其他圖的區別是它的特殊內容。【在第7討論圖的普通特性。】74第二部分對基本結構建模類聚合名稱多重性約束泛化關聯屬性操作接口依賴圖8-1 類圖2. 內容類圖通常包含下述內容： 類 接口 協作 依賴、泛化和關聯關系像所有的其他圖一樣，類圖可以包含注解和約束。類圖還可以含有子系統，二者都用于把模型元素成更大的組塊。有時也要在類圖中放置實例，特別是在對實例的類型（可能是動態的）進行可視化時。【在第4第9討論類；討論子系在第11討論接口；在第 27討論協作；在第 5第10討論關系；在第 12

4、討論包；在第 31統；在第13討論實例。】注釋 構件圖和實施圖與類圖類似，只是分別包含構件和節點，而不是類。3. 普通用法圖75第8章 類類圖用于對系統的靜態設計視圖建模。這種視圖主要支持系統的功能需求，即系統要提供給最終用戶的服務。【在第2討論設計視圖。】當對系統的靜態設計視圖建模時，通常以下述 3種方式之一使用類圖。1）對系統的詞匯建模對系統的詞匯建模涉及到作出這樣的決定：哪些抽象是考慮中的系統的一部分，哪些抽象是處于系統邊界之外。用類圖詳述這些抽象和它們的職責。【在第4 2）對簡單協作建模協作是一些共同工作的類、接口和其他元素的群體，該群體提供的一些合作行為強于所有 這些元素的行為之和。

5、例如，當對分布式系統中的事務語義建模時，不能僅僅盯著一個單獨的類來推斷要發生什么，而要由相互協作的一組類來實現這些語義。用類圖對這組類以及它們之討論對系統的詞匯建模。】間的關系進行可視化和詳述。【在第27 3）對邏輯數據庫模式建模將模式看作為數據庫的概念設計的藍圖。在很多領域中，要在關系數據庫或面向對象數據討論協作。】庫中信息。可以用類圖對這些數據庫的模式建模。【在第23討論性。在第29討論對物理數據庫建模。】8.3普通建模技術8.3.1對簡單協作建模類不是單獨存在的，而是要和其他的類協同工作，以實現一些強于使用單個類的語義。因 此，除了捕獲系統的詞匯之外，也需要把注意力轉移到對詞匯中的這些事

6、物協同工作的各種方式進行可視化、詳述、構造和文檔化。用類圖描述這些協作。創建類圖就是對組成系統設計視圖的一部分事物及關系進行建模。由于這個 圖在一個時間內應該注重于一個協作。為了對協作建模，要遵循如下策略：，每個類 識別要建模的機制。一個機制描述了正在建模的部的一些功能和行為，這些功能和行為起因于類、接口以及一些其他事物所組成的群體的相互作用。 對每種機制，識別參與協作的類、接口和其他協作，并識別這些事物之間的關系。 用排演這些事物。通過這種方法，可發現模型的哪些部分被遺漏以及哪些部分有明顯的語義錯誤。 要把元素和它們的內容在一起。對于類，開始要做好職責的平衡，然后隨著時間的推移，把它們轉換成

7、具體的屬性和操作。【像此處的機制經常要與用況相結合，有關這方面的問題在第 16討論；是貫穿用況的線索，有關這方面的問題在第 15討論。】例如，圖8-2描述了取自一個自治人實現中的一組類。該圖關注包含在沿著一條路徑移器人的機制中的類。你會發現在圖中有一個抽象類（ Motor），它有兩個具體子類，分別是76第二部分 對基本結構建模SteeringMotor和MainMotor。這兩個類都繼承父類Motor的5個操作。這兩個類又被顯示 為另一 個類D r i v e r 的 部分。 類 P a t h A g e n t 與 D r i v e r 有一對 一的關 聯， 與CollisionSens

8、or有一對多的關聯。雖然PathAgent被給定了系統職責，但此處沒顯示出任 何屬性和操作。在這個系統中還包含的類，但這個圖只關注被直接包含在移器人中的那些抽象。在其他的圖中會看到一些同樣的類。例如，盡管在此圖中沒有顯示，但類 PathAgent至少和另外的兩個類（ Environment和GoalAgent）在更次機制上相互協作，用于管理人在特定時刻可能有的目標。類似地，盡管在此圖也沒有顯示，但類 Collision Sensor和Driver（和它的部分）與另一個類（ FaultAgent）在一種機制中協作，該機制負責持續地檢查人的硬件故障。通過在不同的圖中關注每一個這樣的協作，就從幾個角

9、度提供了可理解的系統視圖。圖8-2 對簡單協作建圖8.3.2對邏輯數據庫模式建模你所建模的很多系統都有對象，即要把這些對象在數據庫中，以便后來檢索。最經常的是用關系數據庫、面向對象數據庫或混合的關系 /對象數據庫對象。 UML很適合于對邏輯數據庫模式和物理數據庫本身建模。【在第23 討論對物理數據庫的建模。】討論對對象的分布和遷移建模；在第 29實體-關系（ E-R）圖是一種用于邏輯數據庫設計的通用建模工具， UML的類圖是實體-關系圖77第8章 類圖的超集。傳統的E-R圖只數據，類圖則進了一步，它也對行為建模。在物理數據庫中，一般要把這些邏輯操作轉換成觸發器或的過程。為了對模式建模，要遵循如

10、下策略： 在模型中識別其狀態必須超過其應用系統生命周期的類。 創建含有這些類的類圖，并把它們標記成的（用 UML提供的標準標記值）。對于特定數據庫細節，可以定義的標記值集合。 展開這些類的結構性細節。通常，這意味著詳述屬性的細節，并注重于關聯和構造這些類 的基數。 觀察使物理數據庫設計復雜化的公共模式，如循環關聯、一對一關聯和 n-元關聯。必要時創建簡化邏輯結構的中間抽象。 也要考慮這些類的行為，展開對數據和數據完整性來說是重要的操作。通常，為了提供更好的關注分離，與這些對象集的相關的業務規則應該被封裝在這些類的上一層。 可能，用工具來幫助把邏輯設計轉換成物理設計。邏輯數據庫設計超出了本書的范

11、圍。這里只是簡單地指明如何用 UML對模式建注釋模。在實際應用中，最終要對所用數據庫的種類（關系型的或面向對象的）使用構造型。【在第6討論構造型。】圖8-3顯示了取自某學校的信息系統的一組類。該圖對本書在前面給出的一個類圖作了擴展，圖8-3 對模式建模78第二部分 對基本結構建模你會看到，本圖所顯示的這些類的細節足以構造一個物理數據庫。從圖的左下部開始，你會發現有3個名為Student、Course和Instructor的類。Student和Course之間有一個說明學 生所聽課程的關聯。此外，每個學生可以聽的課程門數不限，聽每門課程的學生人數也不限。這6個類都被標記為的，表明它們的實例要存放

12、在數據庫或其他形式的系統中。該圖也顯示了這6個類的屬性。注意，所有的屬性都是簡單類型的。當對模式建模時，一般要用顯式的聚合而不是用屬性對任何非簡單類型的關系建模。【在第410討論聚合。】討論對簡單類型建模；在第 5第類School和類Department顯示了幾個其部分對象的操作。模型中包含這些操作是因為它們對維護數據的完整性是很重要的（例如增加或移動 Department將有一些連帶的影響）。對于這些類和其他的類，還有很多可以考慮的其他操作，例如，在生前，課程的先決條件。這些操作更接近業務規則而不是用于數據庫完整性，因而最好把它們放在比這個模式更高的抽象層次上。8.3.3正向工程和逆向工程建

13、模是重要的，但要記住開發組的主要是軟件而不是圖。當然，創建模型的是為了及時交付滿足用戶及業務發展目標的正確軟件。因此，使創建的模型與交付的相匹配，并使二者保持同步的代價減少到最小（甚至取消）是很重要的。【在第1討論建模的重要性。】使用UML的某些功能，所創建的模型將永遠成代碼。例如，若用活動圖對業務過程建模，則很多被建模的活動要涉及到而不是計算機。另一種情況是你所建模的系統的組成部分在你的抽象層次上只是一些硬件（雖然在另一個抽象層次上看，也可以說該硬件包含了嵌入的計算機和軟件）。【在第19討論活動圖。】成代碼。 UML沒有指定對任何面向對象編程語言在大多數情況下，要把所創建的模型的，但UML還

14、是考慮了問題。特別是對類圖，可以把類圖的內容清楚地到各種工業化的面向對象的語言，如Java、C+、Smalltalk、Eiffel、Ada、ObjectPascal和Forte。UML也被設計得可到各種的基于對象的語言，如 Visual Basic。注釋對于正向和逆向工程， UML到特定的實現語言的已經超出了本書的范圍。在實際應用中，最終要標記值。】所用的編程語言使用構造型和標記值。【在第6討論構造型和正向工程（forward engineering ）是通過到實現語言的而把模型轉換為代碼的過程。由于用UML描述的模型在語義上比當前的任何面向對象編程語言都要豐富，所以正向工程將導致一定信息的損

15、失。事實上，這是為什么除了代碼之外還需要模型的主要。像協作這樣的結構特征和交互這樣的行為特征，在 UML中能被清晰地可視化，但源代碼就如此清晰。對類圖進行正向工程，要遵循如下的策略： 識別到所選擇的實現語言的規則。這是你要為整個項目或組織做的事。 根據所選擇語言的語義，可能要限定對一些 UML特性的用法。例如， UML對多繼承圖79第8章 類建模，但Smalltalk僅單繼承。可以選擇開發用多繼承建模（這使得模型依賴于語言），也可以選擇把這些豐富的特征轉化為實現語言的慣用方法（這樣使得復雜）。更為 用標記值詳述目標語言。如果需要精確的較高的層次上（如協作或包）這樣做。 使用工具對模型進行正向工

16、程。，可以在單個類的層次上這樣做。也可以在圖8-4是一個簡單的類圖，它描述了職責模式鏈的一個實例化。這個特殊的實例化包含3個類： Client、EventHandler和GUIEventHandler。Client和EventHandler被顯示為抽象 類，而 G U I E v e n t H a n d l e r 是具體類。雖然在這個實例化中增加了兩個私有屬性，但EventHandler有這個模式（ handleRequest）所期望的通常操作。【在第28討論模式】圖8-4 正向工程所有這些類中都指定了一個到Java的，被注解在它們的標記值中。用工具對這個圖中的類進行正向工程，使之成為

17、Java程序是簡單的。對類EventHandler進行正向工程將產生如下代碼：逆向工程（reverse engineeri n）g 是通過從特定實現語言的而把代碼轉換為模型的過程。逆向工程會導致大量的多余信息，其中的一些信息屬于細節層次，對于建造有用的模型來說過于詳細。同時，逆向工程是整的。由于在正向工程中產生的代碼丟失了一些信息，80第二部分 對基本結構建模所以，除非所使用的工具能對原先注釋中的信息（這超出了實現語言的語義）進行編碼，否則 就不能再從代碼創建一個完整的模型。對類圖進行逆向工程，要遵循如下的策略： 識別從實現語言或所選的語言進行的規則。這是你要為整個項目或組織做的事。 使用工具，指向要進行逆向工程的代碼。用工具生成新的模型或修改以前進行正向工程時 已有的模型。 使用工具，通過模型創建類圖。例如，可以從一個或幾個類開始，然后通過追蹤特定的關系或其他相鄰的類擴展類圖。根據表達你的意圖的需要，顯示或隱藏類圖內容的細節。【圖3-3是通過對部分Java類庫進行逆向工程產生的。】8.4 提示和技巧在UML中創建類圖時，要記住各個類圖僅僅是系統靜態設計視圖的圖形表示。不必用單個 類圖去表達系統設計視圖的所有內容。而是用系統的所有類圖共同表達系統的全部靜態設