解析UML的靜態建模機制(1)

2019-11-17 04:49:26

字體：大中小

來源：轉載

供稿：網友

任何建模語言都以靜態建模機制為基礎，標準建模語言UML也不例外。UML的靜態建模機制包括用例圖(Use case diagram)、類圖(Class diagram)、對象圖(Object diagram )、包(Package)、構件圖(Component diagram)和配置圖(Deployment diagram)。 用例圖用例模型(Use case model) 長期以來，在面向對象開發和傳統的軟件開發中，人們根據典型的使用情景來了解需求。但是，這些使用情景是非正式的，雖然經常使用，卻難以建立正式文擋。用例模型由Ivar Jacobson在開發AXE系統中首先使用，并加入由他所倡導的OOSE和Objectory方法中。用例方法引起了面向對象領域的極大關注。自1994年Ivar Jacobson的著作出版后，面向對象領域已廣泛接納了用例這一概念，并認為它是第二代面向對象技術的標志。用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用于需求分析階段，它的建立是系統開發者和用戶反復討論的結果，表明了開發者和用戶對需求規格達成的共識。首先，它描述了待開發系統的功能需求; 其次，它將系統看作黑盒，從外部執行者的角度來理解系統; 第三，它驅動了需求分析之后各階段的開發工作，不僅在開發過程中保證了系統所有功能的實現，而且被用于驗證和檢測所開發的系統，從而影響到開發工作的各個階段和UML的各個模型。在UML中，一個用例模型由若干個用例圖描述，用例圖主要元素是用例和執行者。 用例(use case) 從本質上講，一個用例是用戶與計算機之間的一次典型交互作用。以字處理軟件為例，“將某些正文置為黑體”和“創建一個索引”便是兩個典型的用例。在UML中，用例被定義成系統執行的一系列動作，動作執行的結果能被指定執行者察覺到。在UML中，用例表示為一個橢圓。圖1顯示了一個金融貿易系統的用例圖。其中，“風險分析”，“交易估價”，“進行交易”，“設置邊界”，“超越邊界的交易”，“評價貿易”，“更新帳目”等都是用例的實例。概括地說，用例有以下特點: •用例捕捉某些用戶可見的需求，實現一個具體的用戶目標。 •用例由執行者激活，并提供確切的值給執行者。 •用例可大可小，但它必須是對一個具體的用戶目標實現的完整描述。解析UML的靜態建模機制(1)（圖一）

圖1 金融貿易系統用例執行者(Actor) 執行者是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。圖1中有四個執行者:貿易經理、營銷人員、售貨員和記帳系統。在某些組織中很可能有許多營銷人員,但就該系統而言,他們均起著同一種作用,扮演著相同的角色,所以用一個執行者表示。一個用戶也可以扮演多種角色(執行者)。例如,一個高級營銷人員既可以是貿易經理,也可以是普通的營銷人員;一個營銷人員也可以是售貨員。在處理執行者時,應考慮其作用,而不是人或工作名稱,這一點是很重要的。圖1中,不帶箭頭的線段將執行者與用例連接到一起,表示兩者之間交換信息,稱之為通信聯系。執行者觸發用例,并與用例進行信息交換。單個執行者可與多個用例聯系;反過來,一個用例可與多個執行者聯系。對同一個用例而言,不同執行者有著不同的作用:他們可以從用例中取值,也可以參與到用例中。需要注重的是執行者在用例圖中是用類似人的圖形來表示,盡管執行的,但執行者未必是人。例如,執行者也可以是一個外界系統,該外界系統可能需要從當前系統中獲取信息,與當前系統有進行交互。在圖1中,我們可以看到,記帳系統是一個外界系統,它需要更新帳目。通過實踐,我們發現執行者對提供用例是非常有用的。面對一個大系統,要列出用例清單經常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用例,問題就會變得輕易很多。 使用和擴展(Use and Extend) 圖1中除了包含執行者與用例之間的連接外,還有另外兩種類型的連接,用以表示用例之間的使用和擴展關系。使用和擴展是兩種不同形式的繼續關系。當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關系。例如圖1中,基本的用例是"進行交易"。交易中可能一切都進行得很順利,但也可能存在擾亂順利進行交易的因素。其中之一便是超出某些邊界值的情況。例如,貿易組織會對某個特定客戶規定最大貿易量,這時不能執行給定用例提供的常規動作,而要做些改動。我們可在"進行交易"用例中做改動。但是,這將把該用例與一大堆非凡的判定和邏輯混雜在一起,使正常的流程晦澀不堪。圖1中將常規的動作放在"進行交易"用例中,而將非常規的動作放置于"超越邊界的交易"用例中,這便是擴展關系的實質。當有一大塊相似的動作存在于幾個用例,又不想重復描述該動作時,就可以用到使用關系。例如,現實中風險分析和交易估價都需要評價貿易,為此可單獨定義一個用例,即"評價貿易",而"風險分析"和"交易估價"用例將使用它。請注重擴展與使用之間的相似點和不同點。它們兩個都意味著從幾個用例中抽取那些公共的行為并放入一個單獨用例中,而這個用例被其他幾個用例使用或擴展。但使用和擴展的目的是不同的。 用例模型的獲取幾乎在任何情況下都會使用用例。用例用來獲取需求,規劃和控制項目。用例的獲取是需求分析階段的主要任務之一,而且是首先要做的工作。大部分用例將在項目的需求分析階段產生,并且隨著工作的深入會發現更多的用例,這些都應及時增添到已有的用例集中。用例集中的每個用例都是一個潛在的需求。 1. 獲取執行者獲取用例首先要找出系統的執行者。可以通過用戶回答一些問題的答案來識別執行者。以下問題可供參考: •誰使用系統的主要功能(主要使用者)。
•誰需要系統支持他們的日常工作。 •誰來維護、治理使系統正常工作(輔助使用者)。 •系統需要操縱哪些硬件。 •系統需要與哪些其它系統交互,包含其它計算機系統和其它應用程序。 •對系統產生的結果感愛好的人或事物。2. 獲取用例一旦獲取了執行者,就可以對每個執行者提出問題以獲取用例。

以下問題可供參考:

•執行者要求系統提供哪些功能(執行者需要做什么)?

•執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。

•必須提醒執行者的系統事件有哪些?或者執行者必須提醒系統的事件有哪些?怎樣把這些事件表示成用例中的功能?

•為了完整地描述用例,還需要知道執行者的某些典型功能能否被系統自動實現?

還有一些不針對具體執行者問題(即針對整個系統的問題):

•系統需要何種輸入輸出?輸入從何處來?輸出到何處?

•當前運行系統(也許是一些手工操作而不是計算機系統)的主要問題?

需要注重,最后兩個問題并不是指沒有執行者也可以有用例,只是獲取用例時尚不知道執行者是什么。一個用例必須至少與一個執行者關聯。還需要注重:不同的設計者對用例的利用程度也不同。例如,Ivar Jacobson說,對一個十人年的項目,他需要二十個用例。而在一個相同規模的項目中,Martin Fowler則用了一百多個用例。我們認為:任何合適的用例都可使用,確定用例的過程是對獲取的用例進行提煉和歸納的過程,對一個十人年的項目來說,二十個用例似乎太少,一百多個用例則嫌太多,需要保持二者間的相對均衡。 QQread.com 推出各大專業服務器評測 linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器 類圖、對象圖和包 數千年以前,人類就已經開始采用分類的方法有效地簡化復雜問題,幫助人們了解客觀世界。在面向對象建模技術中,我們使用同樣的方法將客觀世界的實體映射為對象,并歸納成一個個類。類(Class)、對象(Object)和它們之間的關聯是面向對象技術中最基本的元素。對于一個想要描述的系統,其類模型和對象模型揭示了系統的結構。在UML中,類和對象模型分別由類圖和對象圖表示。類圖技術是OO方法的核心。圖2顯示了一個金融保險系統的類圖。解析UML的靜態建模機制(1)（圖二）

圖2 金融保險系統類圖類圖

類圖(Class Diagram)描述類和類之間的靜態關系。與數據模型不同,它不僅顯示了信息的結構,同時還描述了系統的行為。類圖是定義其它圖的基礎。在類圖的基礎上,狀態圖、合作圖等進一步描述了系統其他方面的特性。

類和對象

對象(Object)與我們對客觀世界的理解相關。我們通常用對象描述客觀世界中某個具體的實體。所謂類(Class)是對一類具有相同特征的對象的描述。而對象是類的實例(Instance)。建立類模型時,我們應盡量與應用領域的概念保持一致,以使模型更符合客觀事實,易修改、易理解和易交流。

類描述一類對象的屬性(Attribute)和行為(Behavior)。在UML中,類的可視化表示為一個劃分成三個格子的長方形(下面兩個格子可省略)。圖1中,"客戶"就是一個典型的類。

類的獲取和命名　最頂部的格子包含類的名字。類的命名應盡量用應用領域中的術語,應明確、無歧義,以利于開發人員與用戶之間的相互理解和交流。類的獲取是一個依靠于人的創造力的過程,必須與領域專家合作,對研究領域仔細地分析,抽象出領域中的概念,定義其含義及相互關系,分析出系統類,并用領域中的術語為類命名。一般而言,類的名字是名詞。

• 類的屬性

中間的格子包含類的屬性,用以描述該類對象的共同特點。該項可省略。圖2中“客戶”類有"客戶名"、"地址"等特性。屬性的選取應考慮以下因素:

*原則上來說,類的屬性應能描述并區分每個特定的對象;

*只有系統感愛好的特征才包含在類的屬性中;

*系統建模的目的也會影響到屬性的選取。根據圖的具體程度,每條屬性可以包括屬性的可見性、屬性名稱、類型、缺省值和約束特性。UML規定類的屬性的語法為:

可見性　屬性名 :　類型 = 缺省值　{約束特性}

圖2“客戶”類中,"客戶名"屬性描述為"- 客戶名 : 字符串 = 缺省客戶名"。

可見性"-"表示它是私有數據成員,其屬性名為"客戶名",類型為"字符串"類型,缺省值為"缺省客戶名",此處沒有約束特性。

不同屬性具有不同可見性。常用的可見性有Public、
類型表示該屬性的種類。它可以是基本數據類型,例如整數、實數、布爾型等,也可以是用戶自定義的類型。一般它由所涉及的程序設計語言確定。

約束特性則是用戶對該屬性性質一個約束的說明。例如"{只讀}"說明該屬性是只讀屬性。

• 類的操作(Operation)

該項可省略。操作用于修改、檢索類的屬性或執行某些動作。操作通常也被稱為功能,但是它們被約束在類的內部,只能作用到該類的對象上。操作名、返回類型和參數表組成操作界面。UML規定操作的語法為:

可見性操作名 (參數表) : 返回類型 {約束特性}

在圖2中,"客戶"類中有"取客戶地址"操作,其中"+"表示該操作是公有操作,調用時需要參數"客戶名",參數類型為字符串,返回類型也為字符串。

類圖描述了類和類之間的靜態關系。定義了類之后,就可以定義類之間的各種關系了。

關聯關系

關聯(Association)表示兩個類之間存在某種語義上的聯系。例如,一個人為一家公司工作,一家公司有許多辦公室。我們就認為人和公司、公司和辦公室之間存在某種語義上的聯系。在分析設計的類圖模型中,則在對應人類和公司類、公司類和辦公室類之間建立關聯關系。

在圖2中最上部存在一個"屬于"/"簽定"關聯:每個"保險單"屬于一個"客戶",而"客戶"可以簽定多個"保險單"。除了這個關聯外,圖1中還有另外兩個關聯,分別表示每個"保險單"包含若干個"保險單上的項目",而每個"保險單上的項目"涉及單一的"保險類別"。

• 關聯的方向

關聯可以有方向,表示該關聯單方向被使用。關聯上加上箭頭表示方向,在UML中稱為導航(Navigability)。我們將只在一個方向上存在導航表示的關聯,稱作單向關聯 ( Uni-directional Association ),在兩個方向上都有導航表示的關聯,稱作雙向關聯 ( Bi-directional Association )。圖2中,"保險單"“保險單上的項目”是單向關聯。UML規定,不帶箭頭的關聯可以意味著未知、未確定或者該關聯是雙向關聯三種選擇,因此,在圖中應明確使用其中的一種選擇。

• 關聯的命名

既然關聯可以是雙向的,最復雜的命名方法是每個方向上給出一個名字,這樣的關聯有兩個名字。（見圖2中最上部的"屬于"/"簽定"關聯)。為關聯命名有幾種方法,其原則是該命名是否有助于理解該模型。

• 角色

關聯兩頭的類以某種角色參與關聯。例如圖3中，"公司"以"雇主"的角色,"人"以"雇員"的角色參與的"工作合同"關聯。"雇主"和"雇員"稱為角色名。假如在關聯上沒有標出角色名,則隱含地用類的名稱作為角色名。角色還具有多重性(Mult 解析UML的靜態建模機制(1)（圖三）

圖3 關聯的角色 • 關聯類

一個關聯可能要記錄一些信息,可以引入一個關聯類來記錄。圖4是在圖3的基礎上引入了關聯類。關聯類通過一根虛線與關聯連接。圖5是實現上述目標的另外一種方法,就是使雇用關系成為一個正式的類。解析UML的靜態建模機制(1)（圖四）

圖4 關聯類

圖5 另一種實現方法• 聚集和組成

聚集(Aggregation)是一種非凡形式的關聯。聚集表示類之間的關系是整體與部分的關系。一輛轎車包含四個車輪、一個方向盤、一個發動機和一個底盤,這是聚集的一個例子。在需求分析中,"包含"、"組成"、"分為……部分"等經常設計成聚集關系。聚集可以進一步劃分成共享聚集(Shared Aggregation)和組成。例如,課題組包含許多成員,但是每個成員又可以是另一個課題組的成員,即部分可以參加多個整體,我們稱之為共享聚集。另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會隨之消失,這稱為組成(Composition)。例如,我們打開一個視窗口,它就由標題、外框和顯示區所組成。一旦消亡則各部分同時消失。在UML中,聚集表示為空心菱形,組成表示為實心菱形。需要注重的是,一些面向對象大師對聚集的定義并不一樣。大家應注重其他面向對象方法與UML中所定義的聚集的差別。 QQread.com 推出各大專業服務器評測 Linux服務器的安全性能 SUN服務器 HP服務器 DELL服務器 IBM服務器聯想服務器浪潮服務器曙光服務器同方服務器華碩服務器寶德服務器 繼續關系

人們將具有共同特性的元素抽象成類別,并通過增加其內涵而進一步分類。例如,動物可分為飛鳥和走獸,人可分為男人和女人。在面向對象方法中將前者稱為一般元素、基類元素或父元素,將后者稱為非凡元素或子元素。繼續(Generalization)定義了一般元素和非凡元素之間的分類關系。在UML中,繼續表示為一頭為空心三角形的連線。

如圖2中,將客戶進一步分類成個體客戶和團體客戶,使用的就是繼續關系。

在UML定義中對繼續有三個要求:

*非凡元素應與一般元素完全一致,一般元素所具有的關聯、屬性和操作,非凡元素也都隱含性地具有;

*非凡元素還應包含額外信息;

*答應使用一般元素實例的地方,也應能使用非凡元素。

依靠關系

有兩個元素X、Y,假如修改元素X的定義可能會引起對另一個元素Y的定義的修改,則稱元素Y依靠(Dependency)于元素X。在類中,依靠由各種原因引起,如:一個類向另一個類發消息;一個類是另一個類的數據成員;一個類是另一個類的某個操作參數。假如一個類的界面改變,它發出的任何消息可能不再合法.類圖的抽象層次和細化(Refinement)關系需要注重的是,雖然在軟件開發的不同階段都使用類圖,但這些類圖表示了不同層次的抽象。在需求分析階段,類圖是研究領域的概念;在設計階段,類圖描述類與類之間的接口;而在實現階段,類圖描述軟件系統中類的實現。按照Steve Cook和John Dianiels的觀點,類圖分為三個層次。需要說明的是,這個觀點同樣也適合于其他任何模型,只是在類圖中顯得更為突出。 • 概念層概念層(Conceptual)類圖描述應用領域中的概念。實現它們的類可以從這些概念中得出,但兩者并沒有直接的映射關系。事實上,一個概念模型應獨立于實現它的軟件和程序設計語言。 • 說明層說明層(Specification)類圖描述軟件的接口部分,而不是軟件的實現部分。面向對象開發方法非常重視區別接口與實現之間的差異,但在實際應用中卻經常忽略這一差異。這主要是因為OO語言中類的概念將接口與實現合在了一起。大多數方法由于受到語言的影響,也仿效了這一做法。現在這種情況正在發生變化。可以用一個類型(Type )描述一個接口,這個接口可能因為實現環境、運行特性或者用戶的不同而具有多種實現。 • 實現層只有在實現層(Implementation)才真正有類的概念,并且揭示軟件的實現部分。這可能是大多數人最常用的類圖,但在很多時候,說明層的類圖更易于開發者之間的相互理解和交流。理解以上層次對于畫類圖和讀懂類圖都是至關重要的。但是由于各層次之間沒有一個清楚的界限,所以大多數建模者在畫圖時沒能對其加以區分。畫圖時,要從一個清楚的層次觀念出發;而讀圖時,則要弄清它是根據哪種層次觀念來繪制的。要正確地理解類圖,首先應正確地理解上述三種層次。雖然將類圖分成三個層次的觀點并不是UML的組成部分,但是它們對于建模或者評價模型非常有用。盡管迄今為止人們似乎更強調實現層類圖,但這三個層次都可應用于UML,而且實際上另外兩個層次的類圖更有用。下面介紹細化概念。細化是UML中的術語,表示對事物更具體一層的描述。兩個元素A、B描述同一件事物,它們的區別是抽象層次不同,若元素B是在元素A的基礎上的更具體的描述,則稱元素B細化了元素A,或稱元素A細化成元素B。細化的圖形表示為由元素B指向元素A的、一頭為空心三角的虛線(千萬不要把方向顛倒了!)。細化主要用于模型之間的合作,表示開發各階段不同層次抽象模型的相關性,常用于跟蹤模型的演變。
約束在UML中,可以用約束(Constraint)表示規則。約束是放在括號"{}"中的一個表達式,表示一個永真的邏輯陳述。在程序設計語言中,約束可以由斷言(Assertion)來實現。 對象圖、對象和鏈 UML中對象圖與類圖具有相同的表示形式。對象圖可以看作是類圖的一個實例。對象是類的實例;對象之間的鏈(Link)是類之間的關聯的實例。對象與類的圖形表示相似,均為劃分成兩個格子的長方形(下面的格子可省略)。上面的格子是對象名,對象名下有下劃線;下面的格子記錄屬性值。鏈的圖形表示與關聯相似。對象圖常用于表示復雜的類圖的一個實例。包一個最古老的軟件方法問題是:怎樣將大系統拆分成小系統。解決這個問題的一個思路是將許多類集合成一個更高層次的單位,形成一個高內聚、低耦合的類的集合。這個思路被松散地應用到許多對象技術中。UML中這種分組機制叫包(Package)(見圖6)。解析UML的靜態建模機制(1)（圖六）

圖6 包圖不僅是類,任何模型元素都運用包的機制。假如沒有任何啟發性原則來指導類的分組,分組方法就是任意的。在UML中,最有用的和強調最多的啟發性原則就是依靠。包圖主要顯示類的包以及這些包之間的依靠關系。有時還顯示包和包之間的繼續關系和組成關系。 • 包的內容在圖6中,"系統內部"包由"保險單"包和"客戶"包組成。這里稱"保險單"包和"客戶"包為"系統內部"包的內容。當不需要顯示包的內容時,包的名字放入主方框內,否則包的名字放入左上角的小方框中,而將內容放入主方框內。包的內容可以是類的列表,也可以是另一個包圖,還可以是一個類圖。 • 包的依靠和繼續圖6中"保險單填寫界面"包依靠于"保險單"包;整個"系統內部"包依靠于"數據庫界面"包。可以使用繼續中通用和特例的概念來說明通用包和專用包之間的關系。例如,專用包必須符合通用包的界面,與類繼續關系類似。通過"數據庫界面"包,"系統內部"包既能夠使用Oracle的界面也可使用Sybase的界面。通用包可標記為{abs tract},表示該包只是定義了一個界面,具體實現則由專用包來完成。其他模型元素和表示機制 類圖中用到的模型元素和表示機制較為豐富,由于篇幅的限制,這里不能一一介紹。主要還有以下模型符號和概念:類別模板(Stereotype)、界面(Interface)、參數化類(P arameterized Class)也稱模板類(Template)、限定關聯(Qualified Association)、多維關聯(N-ary Association)、多維鏈(N-ary Link)、派生(Derived)、類型(Type)和注釋(Note)等。 使用類圖的幾個建議 類圖幾乎是所有OO方法的支柱。采用標準建模語言UML進行建模時,必須對UML類圖引入的各種要素有清楚的理解。以下對使用類圖進行建模提出幾點建議: *不要試圖使用所有的符號。從簡單的開始,例如,類、關聯、屬性和繼續等概念。在UML中,有些符號僅用于非凡的場合和方法中,只有當需要時才去使用。 *根據項目開發的不同階段,用正確的觀點來畫類圖。假如處于分析階段,應畫概念層類圖;當開始著手軟件設計時,應畫說明層類圖;當考察某個特定的實現技術時,則應畫實現層類圖。 *不要為每個事物都畫一個模型,應該把精力放在要害的領域。最好只畫幾張較為要害的圖,經常使用并不斷更新修改。使用類圖的最大危險是過早地陷入實現細節。為了避免這一危險,應該將重點放在概念層和說明層。假如已經碰到了一些麻煩,可以從以下幾個方面來反思你的模型。 *模型是否真實地反映了研究領域的實際。 *模型和模型中的元素是否有清楚的目的和職責(在面向對象方法中,系統功能最終是分配到每個類的操作上實現的,這個機制叫職責分配)。 *模型和模型元素的大小是否適中。過于復雜的模型和模型元素是很難生存的,應將其分解成幾個相互合作的部分。 構件圖和配置圖構件圖(Component diagram)和配置圖(Deployment diagram)顯示系統實現時的一些特性,包括源代碼的靜態結構和運行時刻的實現結構。構件圖顯示代碼本身的結構,配置圖顯示系統運行時刻的結構。 (1) 構件圖構件圖顯示軟件構件之間的依靠關系。一般來說,軟件構件就是一個實際文件,可以是源代碼文件、二進制代碼文件和可執行文件等。可以用來顯示編譯、鏈接或執行時構件之間的依靠關系。 (2) 配置圖配置圖描述系統硬件的物理拓撲結構以及在此結構上執行的軟件。配置圖可以顯示計算結點的拓撲結構和通信路徑、結點上運行的軟件構件、軟件構件包含的邏輯單元(對象、類)等。配置圖經常用于幫助理解分布式系統。 (3) 結點和連接　結點(Node)代表一個物理設備以及其上運行的軟件系統,如一臺Unix主機、一個PC終端、一臺打印機、一個傳感器等。如圖1所示,"客戶端PC"和"保險后臺服務器"就是兩個結點。結點表示為一個立方體,結點名放在左上角。結點之間的連線表示系統之間進行交互的通信路徑,在UML中被稱為連接(Connectio n)。通信類型則放在連接旁邊的"《》"之間,表示所用的通信協議或網絡類型。 (4) 構件和界面　在配置圖中,構件代表可執行的物理代碼模塊,如一個可執行程序。邏輯上它可以與類圖中的包或類對應。因此,配置圖中顯示運行時各個包或類在結點中的分布情況。如在圖1中,"保險后臺服務器" 結點中包含"保險系統"、"保險對象數據庫"和"保險系統配置"3個構件。在面向對象方法中,類和構件等元素并不是所有的屬性和操作都對外可見。它們對外提供了可見操作和屬性,稱之為類和構件的界面。界面可以表示為一頭是小園圈的直線。圖1中,"保險系統"構件提供了一個"配置"界面。配置圖中還顯示了構件之間的依靠關系,"保險系統配置"構件依靠于這個"配置"界面。 (5) 對象(Object)　一個面向對象軟件系統中可以運行很多對象。由于構件可以看作與包或類對應的物理代碼模塊,因此,構件中應包含一些運行的對象。配置圖中的對象與對象圖中的對象表示法一樣。圖1中,"保險系統配置"構件包含"配置保險政策"和"配置用戶"兩個對象。
標準建模語言UML的靜態建模機制是采用UML進行建模的基礎。我們認為,熟練把握基本概念、區分不同抽象層次以及在實踐中靈活運用,是三條最值得注重的基本原則。 (責任編輯：銘銘)

上一篇：使用模式集成UML視圖(1)

下一篇：RSA中UML建模元素的擴展與定制(1)