專家推薦 經典UML類圖教程
本節向大家介紹一下UML類圖教程， 類圖(ClassDiagram)描述類和類之間的靜態關系。與數據模型不同,它不僅顯示了信息的結構,同時還描述了系統的行為。類圖是定義其它圖的基礎。下面請看詳細介紹。
UML類圖教程
數千年以前,人類就已經開始采用分類的方法有效地簡化復雜問題,幫助人們了解客觀世界。在面向對象建模技術中,我們使用同樣的方法將客觀世界的實體映射為對象,并歸納成一個個類。類(Class)、對象(Object)和它們之間的關聯是面向對象技術中最基本的元素。對于一個想要描述的系統,其類模型和對象模型揭示了系統的結構。在UML中,類和對象模型分別由類圖和對象圖表示。類圖技術是OO方法的核心。
(1)類圖
類圖(ClassDiagram)描述類和類之間的靜態關系。與數據模型不同,它不僅顯示了信息的結構,同時還描述了系統的行為。類圖是定義其它圖的基礎。在類圖的基礎上,狀態圖、合作圖等進一步描述了系統其他方面的特性。
(2)類和對象
對象(Object)與我們對客觀世界的理解相關。我們通常用對象描述客觀世界中某個具體的實體。所謂類(Class)是對一類具有相同特征的對象的描述。而對象是類的實例(Instance)。建立類模型時,我們應盡量與應用領域的概念保持一致,以使模型更符合客觀事實,易修改、易理解和易交流。
UML類圖教程中類描述一類對象的屬性(Attribute)和行為(Behavior)。在UML中,類的可視化表示為一個劃分成三個格子的長方形(下面兩個格子可省略)。圖1中,"客戶"就是一個典型的類。
類的獲取和命名 最頂部的格子包含類的名字。類的命名應盡量用應用領域中的術語,應明確、無歧義,以利于開發人員與用戶之間的相互理解和交流。類的獲取是一個依賴于人的創造力的過程,必須與領域專家合作,對研究領域仔細地分析,抽象出領域中的概念,定義其含義及相互關系,分析出系統類,并用領域中的術語為類命名。一般而言,類的名字是名詞。
類的屬性 中間的格子包含類的屬性,用以描述該類對象的共同特點。該項可省略。圖1中"客戶"類有"客戶名"、"地址"等特性。屬性的選取應考慮以下因素:
◆原則上來說,類的屬性應能描述并區分每個特定的對象;
◆只有系統感興趣的特征才包含在類的屬性中;
◆系統建模的目的也會影響到屬性的選取。
根據圖的詳細程度,每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UML規定類的屬性的語法為:
可見性 屬性名: 類型=缺省值 {約束特性}
(3)關聯關系
UML類圖教程中關聯(Association)表示兩個類之間存在某種語義上的聯系。例如,一個人為一家公司工作,一家公司有許多辦公室。我們就認為人和公司、公司和辦公室之間存在某種語義上的聯系。在分析設計的類圖模型中,則在對應人類和公司類、公司類和辦公室類之間建立關聯關系。
在圖1中最上部存在一個"屬于"/"簽定"關聯:每個"保險單"屬于一個"客戶",而"客戶"可以簽定多個"保險單"。除了這個關聯外,圖1中還有另外兩個關聯,分別表示每個"保險單"包含若干個"保險單上的項目",而每個"保險單上的項目"涉及單一的"保險類別"。
關聯的方向 關聯可以有方向,表示該關聯單方向被使用。關聯上加上箭頭表示方向,在UML中稱為導航(Navigability)。我們將只在一個方向上存在導航表示的關聯,稱作單向關聯(Uni-directionalAssociation),在兩個方向上都有導航表示的關聯,稱作雙向關聯(Bi-directionalAssociation)。圖1中,"保險單"到"保險單上的項目"是單向關聯。UML規定,不帶箭頭的關聯可以意味著未知、未確定或者該關聯是雙向關聯三種選擇,因此,在圖中應明確使用其中的一種選擇。
關聯的命名 既然關聯可以是雙向的,最復雜的命名方法是每個方向上給出一個名字,這樣的關聯有兩個名字,可以用小黑三角表示名字的方向(見圖1中最上部的"屬于"/"簽定"關聯)。為關聯命名有幾種方法,其原則是該命名是否有助于理解該模型。
角色 關聯兩頭的類以某種角色參與關聯。例如圖2中,"公司"以"雇主"的角色,"人"以"雇員"的角色參與的"工作合同"關聯。"雇主"和"雇員"稱為角色名。如果在關聯上沒有標出角色名,則隱含地用類的名稱作為角色名。角色還具有多重性(Multiplicity),表示可以有多少個對象參與該關聯。在圖2中,雇主(公司)可以雇傭(簽工作合同)多個雇員,表示為"*";雇員只能與一家雇主簽定工作合同,表示為"1"。多重性表示參與對象的數目的上下界限制。"*"代表0～∞,即一個客戶可以沒有保險單,也可以有任意多的保險單。"1"是1..1的簡寫,即任何一個保險單僅來自于一個客戶,可以用一個單個數字表示,也可以用范圍或者是數字和范圍不連續的組合表示。#p#
關聯類
一個關聯可能要記錄一些信息,可以引入一個關聯類來記錄。圖3是在圖2的基礎上引入了關聯類。關聯類通過一根虛線與關聯連接。圖4是實現上述目標的另外一種方法,就是使雇用關系成為一個正式的類。
聚集和組成
UML類圖教程中聚集(Aggregation)是一種特殊形式的關聯。聚集表示類之間的關系是整體與部分的關系。一輛轎車包含四個車輪、一個方向盤、一個發動機和一個底盤,這是聚集的一個例子。在需求分析中,"包含"、"組成"、"分為……部分"等經常設計成聚集關系。聚集可以進一步劃分成共享聚集(SharedAggregation)和組成。例如,課題組包含許多成員,但是每個成員又可以是另一個課題組的成員,即部分可以參加多個整體,我們稱之為共享聚集。另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會隨之消失,這稱為組成(Composition)。例如,我們打開一個視窗口,它就由標題、外框和顯示區所組成。一旦消亡則各部分同時消失。在UML中,聚集表示為空心菱形,組成表示為實心菱形。需要注意的是,一些面向對象大師對聚集的定義并不一樣。大家應注意其他面向對象方法與UML中所定義的聚集的差別。
(4)繼承關系
人們將具有共同特性的元素抽象成類別,并通過增加其內涵而進一步分類。例如,動物可分為飛鳥和走獸,人可分為男人和女人。在面向對象方法中將前者稱為一般元素、基類元素或父元素,將后者稱為特殊元素或子元素。繼承(Generalization)定義了一般元素和特殊元素之間的分類關系。在UML中,繼承表示為一頭為空心三角形的連線。
如圖1中,將客戶進一步分類成個體客戶和團體客戶,使用的就是繼承關系。
在UML定義中對繼承有三個要求:
◆ 特殊元素應與一般元素完全一致,一般元素所具有的關聯、屬性和操作,特殊元素也都隱含性地具有;
◆ 特殊元素還應包含額外信息;
◆ 允許使用一般元素實例的地方,也應能使用特殊元素。
(5)依賴關系
有兩個元素X、Y,如果修改元素X的定義可能會引起對另一個元素Y的定義的修改,則稱元素Y依賴(Dependency)于元素X。在類中,依賴由各種原因引起,如:一個類向另一個類發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。如果一個類的界面改變,它發出的任何消息可能不再合法。
(6)類圖的抽象層次和細化(Refinement)關系
需要注意的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接口;而在實現階段,類圖描述軟件系統中類的實現。UML類圖教程中按照SteveCook和JohnDianiels的觀點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合于其他任何模型,只是在類圖中顯得更為突出。
概念層 概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這些概念中得出,但兩者并沒有直接的映射關系。事實上,一個概念模型應獨立于實現它的軟件和程序設計語言。
說明層 說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分。面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻常常忽略這一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由于受到語言的影響,也仿效了這一做法。現在這種情況正在發生變化。可以用一個類型(Type)描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現。
實現層 只有在實現層(Implementation)才真正有類的概念,并且揭示軟件的實現部分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易于開發者之間的相互理解和交流。
理解以上層次對于畫類圖和讀懂類圖都是至關重要的。但是由于各層次之間沒有一個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪制的。要正確地理解類圖,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點并不是UML的組成部分,但是它們對于建模或者評價模型非常有用。盡管迄今為止人們似乎更強調實現層類圖,但這三個層次都可應用于UML,而且實際上另外兩個層次的類圖更有用。
下面介紹細化概念。細化是UML中的術語,表示對事物更詳細一層的描述。兩個元素A、B描述同一件事物,它們的區別是抽象層次不同,若元素B是在元素A的基礎上的更詳細的描述,則稱元素B細化了元素A,或稱元素A細化成元素B。細化的圖形表示為由元素B指向元素A的、一頭為空心三角的虛線(千萬不要把方向顛倒了!)。細化主要用于模型之間的合作,表示開發各階段不同層次抽象模型的相關性,常用于跟蹤模型的演變。
(7)約束
在UML類圖教程中,可以用約束(Constraint)表示規則。約束是放在括號"{}"中的一個表達式,表示一個永真的邏輯陳述。在程序設計語言中,約束可以由斷言(Assertion)來實現。
【編輯推薦】
