轉自：中國系統分析員 http://www.csai.cn/tech/uml/uml_jtjmjz.htm
任何建模語言都以靜態建模機制爲基礎,標準建模語言UML也不例外。UML的靜態建模機制包括用例圖(Use case diagram)、類圖(Class diagram)、對象圖(Object diagram )、包(Package)、構件圖(Component diagram)和配置圖(Deployment diagram)。
1. 用例圖
(1) 用例模型(Use case model)
長期以來,在面向對象開發和傳統的軟件開發中,人們根據典型的使用情景來了解需求。但是,這些使用情景是非正式的,雖然經常使用,卻難以建立正式文擋。用例模型由Ivar Jacobson在開發AXE系統中首先使用,並加入由他所倡導的OOSE和Objectory方法中。用例方法引起了面向對象領域的極大關注。自1994年Ivar Jacobson的著作出版後,面向對象領域已廣泛接納了用例這一概念,並認爲它是第二代面向對象技術的標誌。
用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用於需求分析階段,它的建立是系統開發者和用戶反覆討論的結果,表明了開發者和用戶對需求規格達成的共識。首先,它描述了待開發系統的功能需求;其次,它將系統看作黑盒,從外部執行者的角度來理解系統;第三,它驅動了需求分析之後各階段的開發工作,不僅在開發過程中保證了系統所有功能的實現,而且被用於驗證和檢測所開發的系統,從而影響到開發工作的各個階段和 UML 的各個模型。在UML中,一個用例模型由若干個用例圖描述,用例圖主要元素是用例和執行者。
(2) 用例(use case)
從本質上講,一個用例是用戶與計算機之間的一次典型交互作用。以字處理軟件爲例,"將某些正文置爲黑體"和"創建一個索引"便是兩個典型的用例。在UML中,用例被定義成系統執行的一系列動作,動作執行的結果能被指定執行者察覺到。
在UML中,用例表示爲一個橢圓。圖1顯示了一個金融貿易系統的用例圖。其中,"風險分析","交易估價","進行交易","設置邊界","超越邊界的交易","評價貿易","更新帳目"等都是用例的實例。概括地說,用例有以下特點:
·用例捕獲某些用戶可見的需求,實現一個具體的用戶目標。
·用例由執行者激活,並提供確切的值給執行者。
·用例可大可小,但它必須是對一個具體的用戶目標實現的完整描述。
(3) 執行者(Actor)
執行者是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。圖1中有四個執行者:貿易經理、營銷人員、售貨員和記帳系統。在某些組織中很可能有許多營銷人員,但就該系統而言,他們均起着同一種作用,扮演着相同的角色,所以用一個執行者表示。一個用戶也可以扮演多種角色(執行者)。例如,一個高級營銷人員既可以是貿易經理,也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理執行者時,應考慮其作用,而不是人或工作名稱,這一點是很重要的。
圖1中,不帶箭頭的線段將執行者與用例連接到一起,表示兩者之間交換信息,稱之爲通信聯繫。執行者觸發用例,並與用例進行信息交換。單個執行者可與多個用例聯繫;反過來,一個用例可與多個執行者聯繫。對同一個用例而言,不同執行者有着不同的作用:他們可以從用例中取值,也可以參與到用例中。
需要注意的是執行者在用例圖中是用類似人的圖形來表示,儘管執行的,但執行者未必是人。例如,執行者也可以是一個外界系統,該外界系統可能需要從當前系統中獲取信息,與當前系統有進行交互。在圖1中,我們可以看到,記帳系統是一個外界系統,它需要更新帳目。
通過實踐,我們發現執行者對提供用例是非常有用的。面對一個大系統,要列出用例清單常常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用例,問題就會變得容易很多。
(4) 使用和擴展(Use and Extend)
圖1中除了包含執行者與用例之間的連接外,還有另外兩種類型的連接,用以表示用例之間的使用和擴展關係。使用和擴展是兩種不同形式的繼承關係。當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關係。例如圖1中,基本的用例是"進行交易"。交易中可能一切都進行得很順利,但也可能存在擾亂順利進行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿易組織會對某個特定客戶規定最大貿易量,這時不能執行給定用例提供的常規動作,而要做些改動。我們可在"進行交易"用例中做改動。但是,這將把該用例與一大堆特殊的判斷和邏輯混雜在一起,使正常的流程晦澀不堪。圖1中將常規的動作放在"進行交易"用例中,而將非常規的動作放置於"超越邊界的交易" 用例中,這便是擴展關係的實質。當有一大塊相似的動作存在於幾個用例,又不想重複描述該動作時,就可以用到使用關係。例如,現實中風險分析和交易估價都需要評價貿易,爲此可單獨定義一個用例,即"評價貿易",而"風險分析"和"交易估價"用例將使用它。
請注意擴展與使用之間的相似點和不同點。它們兩個都意味着從幾個用例中抽取那些公共的行爲並放入一個單獨用例中,而這個用例被其他幾個用例使用或擴展。但使用和擴展的目的是不同的。
(5) 用例模型的獲取
幾乎在任何情況下都會使用用例。用例用來獲取需求,規劃和控制項目。用例的獲取是需求分析階段的主要任務之一,而且是首先要做的工作。大部分用例將在項目的需求分析階段產生,並且隨着工作的深入會發現更多的用例,這些都應及時增添到已有的用例集中。用例集中的每個用例都是一個潛在的需求。
a. 獲取執行者
獲取用例首先要找出系統的執行者。可以通過用戶回答一些問題的答案來識別執行者。以下問題可供參考:
·誰使用系統的主要功能(主要使用者)。
·誰需要系統支持他們的日常工作。
·誰來維護、管理使系統正常工作(輔助使用者)。
·系統需要操縱哪些硬件。
·系統需要與哪些其它系統交互,包含其它計算機系統和其它應用程序。
·對系統產生的結果感興趣的人或事物。
b. 獲取用例
一旦獲取了執行者,就可以對每個執行者提出問題以獲取用例。
以下問題可供參考:
·執行者要求系統提供哪些功能(執行者需要做什麼)?
·執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。
·必須提醒執行者的系統事件有哪些?或者執行者必須提醒系統的事件有哪些?怎樣把這些事件表示成用例中的功能?
·爲了完整地描述用例,還需要知道執行者的某些典型功能能否被系統自動實現?
還有一些不針對具體執行者問題(即針對整個系統的問題):
·系統需要何種輸入輸出?輸入從何處來?輸出到何處?
·當前運行系統(也許是一些手工操作而不是計算機系統)的主要問題?
需要注意,最後兩個問題並不是指沒有執行者也可以有用例,只是獲取用例時尚不知道執行者是什麼。一個用例必須至少與一個執行者關聯。還需要注意:不同的設計者對用例的利用程度也不同。例如,Ivar Jacobson說,對一個十人年的項目,他需要二十個用例。而在一個相同規模的項目中,Martin Fowler則用了一百多個用例。我們認爲:任何合適的用例都可使用,確定用例的過程是對獲取的用例進行提煉和歸納的過程,對一個十人年的項目來說,二十個用例似乎太少,一百多個用例則嫌太多,需要保持二者間的相對均衡。
2. 類圖、對象圖和包
數千年以前,人類就已經開始採用分類的方法有效地簡化複雜問題,幫助人們瞭解客觀世界。在面向對象建模技術中,我們使用同樣的方法將客觀世界的實體映射爲對象,並歸納成一個個類。類(Class)、對象(Object)和它們之間的關聯是面向對象技術中最基本的元素。對於一個想要描述的系統,其類模型和對象模型揭示了系統的結構。在UML中,類和對象模型分別由類圖和對象圖表示。類圖技術是OO方法的核心。圖1顯示了一個金融保險系統的類圖。
(1) 類圖
類圖(Class Diagram)描述類和類之間的靜態關係。與數據模型不同,它不僅顯示了信息的結構,同時還描述了系統的行爲。類圖是定義其它圖的基礎。在類圖的基礎上,狀態圖、合作圖等進一步描述了系統其他方面的特性。
(2) 類和對象
對象(Object)與我們對客觀世界的理解相關。我們通常用對象描述客觀世界中某個具體的實體。所謂類(Class)是對一類具有相同特徵的對象的描述。而對象是類的實例(Instance)。建立類模型時,我們應儘量與應用領域的概念保持一致,以使模型更符合客觀事實,易修改、易理解和易交流。
類描述一類對象的屬性(Attribute)和行爲(Behavior)。在UML中,類的可視化表示爲一個劃分成三個格子的長方形(下面兩個格子可省略)。圖1中,"客戶"就是一個典型的類。
類的獲取和命名 最頂部的格子包含類的名字。類的命名應儘量用應用領域中的術語,應明確、無歧義,以利於開發人員與用戶之間的相互理解和交流。類的獲取是一個依賴於人的創造力的過程,必須與領域專家合作,對研究領域仔細地分析,抽象出領域中的概念,定義其含義及相互關係,分析出系統類,並用領域中的術語爲類命名。一般而言,類的名字是名詞。
類的屬性 中間的格子包含類的屬性,用以描述該類對象的共同特點。該項可省略。圖1中"客?quot;類有"客戶名"、"地址"等特性。屬性的選取應考慮以下因素:
*原則上來說,類的屬性應能描述並區分每個特定的對象;
*只有系統感興趣的特徵才包含在類的屬性中;
*系統建模的目的也會影響到屬性的選取。根據圖的詳細程度,每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UML規定類的屬性的語法爲:
可見性 屬性名 : 類型 = 缺省值 {約束特性}
圖1"客戶"類中,"客戶名"屬性描述爲"- 客戶名 : 字符串 = 缺省客戶名"。 可見性"-"表示它是私有數據成員,其屬性名爲"客戶名",類型爲"字符串"類型,缺省值爲"缺省客戶名",此處沒有約束特性。
不同屬性具有不同可見性。常用的可見性有Public、Private和Protected三種,在UML中分別表示爲"+"、"-"和"#"。
類型表示該屬性的種類。它可以是基本數據類型,例如整數、實數、布爾型等,也可以是用戶自定義的類型。一般它由所涉及的程序設計語言確定。
約束特性則是用戶對該屬性性質一個約束的說明。例如"{只讀}"說明該屬性是隻讀屬性。
類的操作(Operation) 該項可省略。操作用於修改、檢索類的屬性或執行某些動作。操作通常也被稱爲功能,但是它們被約束在類的內部,只能作用到該類的對象上。操作名、返回類型和參數表組成操作界面。UML規定操作的語法爲:
可見性 操作名 (參數表) : 返回類型 {約束特性}
在圖1中,"客戶"類中有"取客戶地址"操作,其中" +"表示該操作是公有操作,調用時需要參數"客戶名",參數類型爲字符串,返回類型也爲字符串。
類圖描述了類和類之間的靜態關係。定義了類之後,就可以定義類之間的各種關係了。
(3) 關聯關係
關聯(Association)表示兩個類之間存在某種語義上的聯繫。例如,一個人爲一家公司工作,一家公司有許多辦公室。我們就認爲人和公司、公司和辦公室之間存在某種語義上的聯繫。在分析設計的類圖模型中,則在對應人類和公司類、公司類和辦公室類之間建立關聯關係。
在圖1中最上部存在一個"屬於"/"簽定"關聯:每個"保險單"屬於一個"客戶",而"客戶"可以簽定多個"保險單"。除了這個關聯外,圖1中還有另外兩個關聯,分別表示每個"保險單"包含若干個"保險單上的項目",而每個"保險單上的項目"涉及單一的"保險類別"。
關聯的方向 關聯可以有方向,表示該關聯單方向被使用。關聯上加上箭頭表示方向,在UML中稱爲導航(Navigability)。我們將只在一個方向上存在導航表示的關聯,稱作單向關聯 ( Uni-directional Association ),在兩個方向上都有導航表示的關聯,稱作雙向關聯 ( Bi-directional Association )。圖1中,"保險單"?quot;保險單上的項目"是單向關聯。UML規定,不帶箭頭的關聯可以意味着未知、未確定或者該關聯是雙向關聯三種選擇,因此,在圖中應明確使用其中的一種選擇。
關聯的命名 既然關聯可以是雙向的,最複雜的命名方法是每個方向上給出一個名字,這樣的關聯有兩個名字,可以用小黑三角表示名字的方向(見圖1中最上部的"屬於"/"簽定"關聯)。爲關聯命名有幾種方法,其原則是該命名是否有助於理解該模型。
角色 關聯兩頭的類以某種角色參與關聯。例如圖2中,"公司"以"僱主"的角色,"人"以"僱員"的角色參與的"工作合同"關聯。"僱主"和"僱員"稱爲角色名。如果在關聯上沒有標出角色名,則隱含地用類的名稱作爲角色名。角色還具有多重性(Multiplicity),表示可以有多少個對象參與該關聯。在圖2中,僱主(公司)可以僱傭(籤工作合同)多個僱員,表示爲"*"; 僱員只能與一家僱主簽定工作合同,表示爲"1"。多重性表示參與對象的數目的上下界限制。"*"代表0～∞,即一個客戶可以沒有保險單,也可以有任意多的保險單。"1"是1..1的簡寫,即任何一個保險單僅來自於一個客戶,可以用一個單個數字表示,也可以用範圍或者是數字和範圍不連續的組合表示。
關聯類 一個關聯可能要記錄一些信息,可以引入一個關聯類來記錄。圖3是在圖2的基礎上引入了關聯類。關聯類通過一根虛線與關聯連接。圖4是實現上述目標的另外一種方法,就是使僱用關係成爲一個正式的類。
聚集和組成 聚集(Aggregation)是一種特殊形式的關聯。聚集表示類之間的關係是整體與部分的關係。一輛轎車包含四個車輪、一個方向盤、一個發動機和一個底盤,這是聚集的一個例子。在需求分析中,"包含"、"組成"、"分爲……部分"等經常設計成聚集關係。聚集可以進一步劃分成共享聚集(Shared Aggregation)和組成。例如,課題組包含許多成員,但是每個成員又可以是另一個課題組的成員,即部分可以參加多個整體,我們稱之爲共享聚集。另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會隨之消失,這稱爲組成(Composition)。例如,我們打開一個視窗口,它就由標題、外框和顯示區所組成。一旦消亡則各部分同時消失。在UML中,聚集表示爲空心菱形,組成表示爲實心菱形。需要注意的是,一些面向對象大師對聚集的定義並不一樣。大家應注意其他面向對象方法與UML中所定義的聚集的差別。
(4) 繼承關係
人們將具有共同特性的元素抽象成類別,並通過增加其內涵而進一步分類。例如,動物可分爲飛鳥和走獸,人可分爲男人和女人。在面向對象方法中將前者稱爲一般元素、基類元素或父元素,將後者稱爲特殊元素或子元素。繼承(Generalization)定義了一般元素和特殊元素之間的分類關係。在UML中,繼承表示爲一頭爲空心三角形的連線。
如圖1中,將客戶進一步分類成個體客戶和團體客戶,使用的就是繼承關係。
在UML定義中對繼承有三個要求:
*特殊元素應與一般元素完全一致,一般元素所具有的關聯、屬性和操作,特殊元素也都隱含性地具有;
*特殊元素還應包含額外信息;
*允許使用一般元素實例的地方,也應能使用特殊元素。
(5) 依賴關係
有兩個元素X、Y,如果修改元素X的定義可能會引起對另一個元素Y的定義的修改,則稱元素Y依賴(Dependency)於元素X。在類中,依賴由各種原因引起,如:一個類向另一個類發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。如果一個類的界面改變,它發出的任何消息可能不再合法。
(6) 類圖的抽象層次和細化(Refinement)關係
需要注意的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接口;而在實現階段,類圖描述軟件系統中類的實現。按照Steve Cook和John Dianiels的觀點,類圖分爲三個層次。需要說明的是,這個觀點同樣也適合於其他任何模型,只是在類圖中顯得更爲突出。
概念層 概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這些概念中得出,但兩者並沒有直接的映射關係。事實上,一個概念模型應獨立於實現它的軟件和程序設計語言。
說明層 說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分。面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻常常忽略這一差異。這主要是因爲OO語言中類的概念將接口與實現合在了一起。大多數方法由於受到語言的影響,也仿效了這一做法。現在這種情況正在發生變化。可以用一個類型(Type )描述一個接口,這個接口可能因爲實現環境、運行特性或者用戶的不同而具有多種實現。
實現層 只有在實現層(Implementation)才真正有類的概念,並且揭示軟件的實現部分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易於開發者之間的相互理解和交流。
理解以上層次對於畫類圖和讀懂類圖都是至關重要的。但是由於各層次之間沒有一個清晰的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清晰的層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪製的。要正確地理解類圖,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點並不是UML的組成部分,但是它們對於建模或者評價模型非常有用。儘管迄今爲止人們似乎更強調實現層類圖,但這三個層次都可應用於UML,而且實際上另外兩個層次的類圖更有用。
下面介紹細化概念。細化是UML中的術語,表示對事物更詳細一層的描述。兩個元素A、B描述同一件事物,它們的區別是抽象層次不同,若元素B是在元素A的基礎上的更詳細的描述,則稱元素B細化了元素A,或稱元素A細化成元素B。細化的圖形表示爲由元素B指向元素A的、一頭爲空心三角的虛線(千萬不要把方向顛倒了!)。細化主要用於模型之間的合作,表示開發各階段不同層次抽象模型的相關性,常用於跟蹤模型的演變。
(7) 約束
在UML中,可以用約束(Constraint)表示規則。約束是放在括號"{}"中的一個表達式,表示一個永真的邏輯陳述。在程序設計語言中,約束可以由斷言(Assertion)來實現。
(8) 對象圖、對象和鏈
UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個實例。對象是類的實例;對象之間的鏈(Link)是類之間的關聯的實例。對象與類的圖形表示相似,均爲劃分成兩個格子的長方形(下面的格子可省略)。上面的格子是對象名,對象名下有下劃線;下面的格子記錄屬性值。鏈的圖形表示與關聯相似。對象圖常用於表示複雜的類圖的一個實例。
(9) 包
一個最古老的軟件方法問題是:怎樣將大系統拆分成小系統。解決這個問題的一個思路是將許多類集合成一個更高層次的單位,形成一個高內聚、低耦合的類的集合。這個思路被鬆散地應用到許多對象技術中。UML中這種分組機制叫包(Package)(見圖5)。
不僅是類,任何模型元素都運用包的機制。如果沒有任何啓發性原則來指導類的分組,分組方法就是任意的。在UML中,最有用的和強調最多的啓發性原則就是依賴。包圖主要顯示類的包以及這些包之間的依賴關係。有時還顯示包和包之間的繼承關係和組成關係。
包的內容 在圖5中,"系統內部"包由"保險單"包和"客戶"包組成。這裏稱"保險單"包和"客戶"包爲"系統內部"包的內容。當不需要顯示包的內容時,包的名字放入主方框內,否則包的名字放入左上角的小方框中,而將內容放入主方框內。包的內容可以是類的列表,也可以是另一個包圖,還可以是一個類圖。
包的依賴和繼承 圖5中"保險單填寫界面"包依賴於"保險單"包;整個"系統內部"包依賴於"數據庫界面"包。可以使用繼承中通用和特例的概念來說明通用包和專用包之間的關係。例如,專用包必須符合通用包的界面,與類繼承關係類似。通過"數據庫界面"包,"系統內部"包既能夠使用Oracle的界面也可使用Sybase的界面。通用包可標記爲{abs tract},表示該包只是定義了一個界面,具體實現則由專用包來完成。
(10) 其他模型元素和表示機制
類圖中用到的模型元素和表示機制較爲豐富,由於篇幅的限制,這裏不能一一介紹。主要還有以下模型符號和概念:類別模板(Stereotype)、界面(Interface)、參數化類(P arameterized Class)也稱模板類(Template)、限定關聯(Qualified Association)、多維關聯(N-ary Association)、多維鏈(N-ary Link)、派生(Derived)、類型(Type)和註釋(Note)等。
(11) 使用類圖的幾個建議
類圖幾乎是所有OO方法的支柱。採用標準建模語言UML進行建模時,必須對UML類圖引入的各種要素有清晰的理解。以下對使用類圖進行建模提出幾點建議:
*不要試圖使用所有的符號。從簡單的開始,例如,類、關聯、屬性和繼承等概念。在UML中,有些符號僅用於特殊的場合和方法中,只有當需要時纔去使用。
*根據項目開發的不同階段,用正確的觀點來畫類圖。如果處於分析階段,應畫概念層類圖;當開始着手軟件設計時,應畫說明層類圖;當考察某個特定的實現技術時,則應畫實現層類圖。
*不要爲每個事物都畫一個模型,應該把精力放在關鍵的領域。最好只畫幾張較爲關鍵的圖,經常使用並不斷更新修改。使用類圖的最大危險是過早地陷入實現細節。爲了避免這一危險,應該將重點放在概念層和說明層。如果已經遇到了一些麻煩,可以從以下幾個方面來反思你的模型。
*模型是否真實地反映了研究領域的實際。
*模型和模型中的元素是否有清楚的目的和職責(在面向對象方法中,系統功能最終是分配到每個類的操作上實現的,這個機制叫職責分配)。
*模型和模型元素的大小是否適中。過於複雜的模型和模型元素是很難生存的,應將其分解成幾個相互合作的部分。
3. 構件圖和配置圖
構件圖(Component diagram)和配置圖(Deployment diagram)顯示系統實現時的一些特性,包括源代碼的靜態結構和運行時刻的實現結構。構件圖顯示代碼本身的結構,配置圖顯示系統運行時刻的結構。
(1) 構件圖構件圖顯示軟件構件之間的依賴關係。一般來說,軟件構件就是一個實際文件,可以是源代碼文件、二進制代碼文件和可執行文件等。可以用來顯示編譯、鏈接或執行時構件之間的依賴關係。
(2) 配置圖配置圖描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。配置圖可以顯示計算結點的拓撲結構和通信路徑、結點上運行的軟件構件、軟件構件包含的邏輯單元(對象、類)等。配置圖常常用於幫助理解分佈式系統。
(3) 結點和連接 結點(Node)代表一個物理設備以及其上運行的軟件系統,如一臺Unix主機、一個PC終端、一臺打印機、一個傳感器等。如圖1所示,"客戶端PC"和"保險後臺服務器"就是兩個結點。結點表示爲一個立方體,結點名放在左上角。
結點之間的連線表示系統之間進行交互的通信路徑,在UML中被稱爲連接(Connectio n)。通信類型則放在連接旁邊的"《》"之間,表示所用的通信協議或網絡類型。
(4) 構件和界面 在配置圖中,構件代表可執行的物理代碼模塊,如一個可執行程序。邏輯上它可以與類圖中的包或類對應。因此,配置圖中顯示運行時各個包或類在結點中的分佈情況。如在圖1中,"保險後臺服務器" 結點中包含"保險系統"、"保險對象數據庫"和"保險系統配置"3個構件。在面向對象方法中,類和構件等元素並不是所有的屬性和操作都對外可見。它們對外提供了可見操作和屬性,稱之爲類和構件的界面。界面可以表示爲一頭是小園圈的直線。圖1中,"保險系統"構件提供了一個"配置"界面。配置圖中還顯示了構件之間的依賴關係,"保險系統配置"構件依賴於這個"配置"界面。
(5) 對象(Object) 一個面向對象軟件系統中可以運行很多對象。由於構件可以看作與包或類對應的物理代碼模塊,因此,構件中應包含一些運行的對象。配置圖中的對象與對象圖中的對象表示法一樣。圖1中,"保險系統配置"構件包含"配置保險政策"和"配置用戶"兩個對象。
標準建模語言UML的靜態建模機制是採用UML進行建模的基礎。我們認爲,熟練掌握基本概念、區分不同抽象層次以及在實踐中靈活運用,是三條最值得注意的基本原則。