UML學習二:标準模組化語言UML的靜态模組化機制

2009-8-25     作者：佚名        編輯：李湘琪   點選進入論壇

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