全面解析UML靜態建模機制
本文和大家重點討論一下UML靜態建模機制 ，主要包括：用例圖(Usecasediagram)、類圖(Classdiagram)、對象圖(Objectdiagram)、包(Package)、構件圖(Componentdiagram)和配置圖(Deploymentdiagram)。
UML靜態建模機制
任何建模語言都以靜態建模機制為基礎,標準建模語言UML也不例外。
UML的靜態建模機制包括：用例圖(Usecasediagram)、類圖(Classdiagram)、對象圖(Objectdiagram)、包(Package)、構件圖(Componentdiagram)和配置圖(Deploymentdiagram)。
1.用例圖
(1)用例模型(Usecasemodel)
用例模型描述的是外部執行者(Actor)所理解的系統功能。用例模型用于需求分析階段,它的建立是系統開發者和用戶反復討論的結果,表明了開發者和用戶對需求規格達成的共識。首先,它描述了待開發系統的功能需求;其次,它將系統看作黑盒,從外部執行者的角度來理解系統;第三,它驅動了需求分析之后各階段的開發工作,不僅在開發過程中保證了系統所有功能的實現,而且被用于驗證和檢測所開發的系統,從而影響到開發工作的各個階段和UML的各個模型。在UML中,一個用例模型由若干個用例圖描述,用例圖主要元素是用例和執行者。
(2)用例(usecase)
從本質上講,一個用例是用戶與計算機之間的一次典型交互作用。在UML靜態建模中,用例被定義成系統執行的一系列動作,動作執行的結果能被指定執行者察覺到。在UML中,用例表示為一個橢圓。概括地說,用例有以下特點:
·用例捕獲某些用戶可見的需求,實現一個具體的用戶目標。
·用例由執行者激活,并提供確切的值給執行者。
·用例可大可小,但它必須是對一個具體的用戶目標實現的完整描述。
(3)執行者(Actor)
執行者是指用戶在系統中所扮演的角色。其圖形化的表示是一個小人。不帶箭頭的線段將執行者與用例連接到一起,表示兩者之間交換信息,稱之為通信聯系。執行者觸發用例,并與用例進行信息交換。單個執行者可與多個用例聯系;反過來,一個用例可與多個執行者聯系。對同一個用例而言,不同執行者有著不同的作用:他們可以從用例中取值,也可以參與到用例中。
需要注意的是執行者在用例圖中是用類似人的圖形來表示,盡管執行的,但執行者未必是人。例如,執行者也可以是一個外界系統,該外界系統可能需要從當前系統中獲取信息,與當前系統有進行交互。
通過實踐,我們發現執行者對提供用例是非常有用的。面對一個大系統,要列出用例清單常常是十分困難。這時可先列出執行者清單,再對每個執行者列出它的用例,問題就會變得容易很多。
(4)使用和擴展(UseandExtend)
UML靜態建模中使用和擴展是兩種不同形式的繼承關系。
當一個用例與另一個用例相似,但所做的動作多一些,就可以用到擴展關系。
當有一大塊相似的動作存在于幾個用例,又不想重復描述該動作時,就可以用到使用關系。
(5)用例模型的獲取
幾乎在任何情況下都會使用用例。用例用來獲取需求,規劃和控制項目。UML靜態建模中用例的獲取是需求分析階段的主要任務之一,
而且是首先要做的工作。大部分用例將在項目的需求分析階段產生,并且隨著工作的深入會發現更多的用例,這些都應及時增添到已有的用例集中。用例集中的每個用例都是一個潛在的需求。
a.獲取執行者
獲取用例首先要找出系統的執行者。可以通過用戶回答一些問題的答案來識別執行者。以下問題可供參考:
·誰使用系統的主要功能(主要使用者)。
·誰需要系統支持他們的日常工作。
·誰來維護、管理使系統正常工作(輔助使用者)。
·系統需要操縱哪些硬件。
·系統需要與哪些其它系統交互,包含其它計算機系統和其它應用程序。
·對系統產生的結果感興趣的人或事物。
b.獲取用例
一旦獲取了執行者,就可以對每個執行者提出問題以獲取用例。以下問題可供參考:
·執行者要求系統提供哪些功能(執行者需要做什么)?
·執行者需要讀、產生、刪除、修改或存儲的信息有哪些類型。
·必須提醒執行者的系統事件有哪些?
或者執行者必須提醒系統的事件有哪些?
怎樣把這些事件表示成用例中的功能?
·為了完整地描述用例,還需要知道執行者的某些典型功能能否被系統自動實現?
還有一些不針對具體執行者問題(即針對整個系統的問題):
·系統需要何種輸入輸出?輸入從何處來?輸出到何處?
·當前運行系統(也許是一些手工操作而不是計算機系統)的主要問題?
需要注意,最后兩個問題并不是指沒有執行者也可以有用例,只是獲取用例時尚不知道執行者是什么。一個用例必須至少與一個執行者關聯。還需要注意:不同的設計者對用例的利用程度也不同。#p#
2.類圖、對象圖和包
(1)類圖
UML靜態建模中類圖(ClassDiagram)描述類和類之間的靜態關系。與數據模型不同,它不僅顯示了信息的結構,同時還描述了系統的行為。類圖是定義其它圖的基礎。在類圖的基礎上,狀態圖、合作圖等進一步描述了系統其他方面的特性。
(2)類和對象
UML靜態建模中對象(Object)與我們對客觀世界的理解相關。我們通常用對象描述客觀世界中某個具體的實體。所謂類(Class)是對一類具有相同特征的對象的描述。而對象是類的實例(Instance)。建立類模型時,我們應盡量與應用領域的概念保持一致,以使模型更符合客觀事實,易修改、易理解和易交流。
類描述一類對象的屬性(Attribute)和行為(Behavior)。在UML中,類的可視化表示為一個劃分成三個格子的長方形(下面兩個格子可省略)。
(3)關聯關系
UML靜態建模中關聯(Association)表示兩個類之間存在某種語義上的聯系。例如,一個人為一家公司工作,一家公司有許多辦公室。我們就認為人和公司、公司和辦公室之間存在某種語義上的聯系。在分析設計的類圖模型中,則在對應人類和公司類、公司類和辦公室類之間建立關聯關系。
關聯的方向
關聯可以有方向,表示該關聯單方向被使用。關聯上加上箭頭表示方向,在UML中稱為導航(Navigability)。我們將只在一個方向上存在導航表示的關聯,稱作單向關聯(Uni-directionalAssociation),在兩個方向上都有導航表示的關聯,稱作雙向關聯(Bi-directionalAssociation)。
關聯的命名
既然關聯可以是雙向的,最復雜的命名方法是每個方向上給出一個名字,這樣的關聯有兩個名字,可以用小黑三角表示名字的方向
聚集(Aggregation)是一種特殊形式的關聯。UML靜態建模中聚集表示類之間的關系是整體與部分的關系。一輛轎車包含四個車輪、一個方向盤、一個發動機和一個底盤,這是聚集的一個例子。在需求分析中,"包含"、"組成"、"分為……部分"等經常設計成聚集關系。聚集可以進一步劃分成共享聚集(SharedAggregation)和組成。例如,課題組包含許多成員,但是每個成員又可以是另一個課題組的成員,即部分可以參加多個整體,我們稱之為共享聚集。
另一種情況是整體擁有各部分,部分與整體共存,如整體不存在了,部分也會隨之消失,這稱為組成(Composition)。例如,我們打開一個視窗口,它就由標題、外框和顯示區所組成。一旦消亡則各部分同時消失。在UML中,聚集表示為空心菱形,組成表示為實心菱形。
【編輯推薦】
