1. 程式人生 > >UML中靜態與動態檢視的總體介紹

UML中靜態與動態檢視的總體介紹

主要的域

檢視

主要概念

簡單說明

結構(描述了系統中的結構成員及其相互關係)

靜態檢視(概念建模)

類圖

元素(類、介面),關係(關聯、泛化、依賴關係、實現)

對應用領域中的概念以及與系統實現有關的內部概念模型。由類與類的相互關係組成;包含屬性與操作

描述系統內部類與類的靜態關聯關係

靜態檢視說明了物件的結構。一個面向物件的系統使資料結構和行為特徵統一到一個獨立的物件結構中。根據面向物件的觀點,資料和行為是緊密相關的。

靜態檢視將行為實體描述成離散的模型元素,但是不包括它們動態行為的細節。

靜態檢視中的關鍵元素是類元及它們之間的關係。類元是描述事物的建模元素。

用例檢視(概念建模)

用例圖

元素(用例、參與者),關係(關聯、擴充套件、包括、用例泛化)

用例檢視是被稱為參與者的外部使用者所能觀察到的系統功能的模型圖。用例是系統中的一個功能單元,可以被描述為參與者與系統之間的一次互動作用。用例模型的用途是列出系統中的用例和參與者,並顯示哪個參與者參與了哪個用例的執行

描述參與者與系統之間的關係

用例例項(使用場景:使用者使用系統的一個實際的、特定的場景)是在系統中執行的一系列動作,這些動作將生成特定參與者可見的價值結果。一個用例定義一組用例例項。

用例應該給參與者代理客觀的價值,用例是在系統中的。

用例模型描述的是外部參與者所理解的系統功能,使用在需求分析階段,它的建立是系統開發者和使用者反覆討論的結果,表明開發者和使用者對需求規格達成的共識。

實現檢視(物理檢視)

構件圖

構件、介面、依賴關係、實現

為了可重複性和可操作性的目的,系統實現方面的資訊也和重要。

實現檢視為系統的構件建模— 構件即構造應用的軟體單元— 還包括各構件之間的依賴關係,以便通過這些依賴關係來估計對系統構件的修改給系統可能帶來的影響。

從構件到介面的實線表明該構件提供的列在介面旁的服務。從構件到介面的虛線箭頭說明這個構件要求介面提供的服務。

將系統中可重用的塊包裝成具有可替代性的物理單元,這些單元稱為構件。實現檢視利用構件與構件之間的介面和依賴關係來表示設計元素(例如類)的具體實現。構件是系統高層的可重用的組成部件。

部署檢視(物理檢視)

部署圖

節點、構件、依賴關係、位置

部署檢視描述位於節點例項上的執行構件例項的安排。節點是一組執行資源,如計算機、裝置或儲存器。這個檢視允許評估分配結果和資源分配。

表示執行時計算資源(如計算機及他們之間的連線)的物理佈置。這些執行資源被稱為節點在執行時節點包含構件和物件,構件和物件的分配可以是靜態的,他們也可以在節點間遷移,如果含有依賴關係的構件例項放在不同的節點上,部署檢視可以展現出執行過程的瓶頸。

動態(描述了系統隨時間變化的行為)

狀態機檢視(概念建模)

狀態機圖

狀態、事件、轉換、動作

狀態機檢視是一個類物件所可能經歷的所有歷程的模型圖。狀態機由物件的各個狀態和連線這些狀態的轉換組成。

狀態圖可用於描述使用者介面、裝置控制器和其他具有反饋的子系統。它還可用於描述在生命期中跨越多個不同性質階段的被動物件的行為,在每一階段該物件都有自己特殊的行為。每一個物件都被看作是通過對事件進行探測並做出迴應來與外界其他部分通訊的獨立的實體。

通過對類物件的生命週期建立模型來描述物件隨時間變換的動態行為。

狀態機是展示狀態與狀態轉換的圖,狀態機用於描述類的行為,但他們也描述用例、協作和方法的動態行為。對這些物件而言,一個狀態代表了執行中的一步。我們通常用類和物件來描述狀態機,但是它也可以被其他元素所直接應用。狀態機是一個類的物件所有可能的生命歷程的模型,狀態機是一個物件的區域性檢視,一個將物件與其外部世界分離開來並獨立考查其行為的圖。利用狀態機可以精確地描述行為,但不適合綜合理解系統執行操作。如果要更好地理解整個系統範圍內的行為產生的影響,那麼互動檢視將更有用些。然而,狀態機有助於理解如使用者介面和裝置控制器這樣的控制機。

狀態機描述的範圍不寬,但它描述了物件深層次的行為,是單獨考察每一個物件的“微縮”檢視。對狀態機的說明是精確的,而且可以直接用於程式碼。然而在理解系統的整個功能時存在困難,因為狀態機一個時刻只集中描述一個物件,要確定整個系統的行為必須同時結合多個狀態機進行考察。互動檢視更加適合描述一組物件的整體行為。

活動檢視(概念建模)

活動圖

狀態、活動、完成轉換、分叉、結合

活動圖是狀態機的一個變體,用來描述執行演算法的工作流程中涉及的活動,用於對計算流程和工作流程建模。

活動圖中的狀態表示計算過程中的所有狀態,而不是普通物件的狀態,通常,活動圖假定在整個計算處理過程中沒有外部事件引起的中斷,否則普通狀態圖更適合描述該情況。

用途是對人類組織的現實世界中的工作流程建模。對事物建模是活動圖的主要用途,但活動圖也可對軟體系統中的活動建模。活動圖有助於理解系統高層活動的執行行為,而不涉及建立協作圖所必須的訊息傳送細節。

表示方式:活動狀態表示成帶有圓形邊線的矩形框,它含有活動的描述(普通的狀態盒為直邊圓角)。簡單的完成轉換用箭頭表示。分支表示轉換的監護條件或具有多標記出口箭頭的菱形。控制的分叉和結合與狀態圖中的表示法相同,是進入或離開深色同步條的多個箭頭。

活動圖沒有表示計算處理過程中的全部詳細內容。表示了活動進行的流程但沒表示出活動執行的物件。活動圖是設計活動的起點,為了完成設計,每個活動必須擴充套件細分成一個或多個操作,每個操作被指定到具體類,這種分配的結果引出了用於實現活動的對協作的設計工作。

互動檢視(概念建模)

互動檢視

互動檢視描述了執行系統功能的各個角色之間相互傳遞訊息的順序關係。互動檢視顯示了跨越多個物件的系統控制流程。

物件間的相互作用體現了物件的行為。這種相互作用可描述成兩種互補的方式。一種以獨立的物件為中心進行考察,一種以相互作用的一組物件為中進行考察。

互動檢視是物件間協作關係的模型。

順序圖和協作圖都可以表示各物件間的互動關係,但它們的側重點不同。順序圖用訊息的幾何排列關係來表達訊息的時間順序,各角色之間的相關關係是隱含的。協作圖用各個角色的幾何排列圖形來表示角色之間的關係,並用訊息來說明這些關係。

順序圖

(時序圖)

互動、物件、訊息、啟用

順序圖表示了物件之間傳送訊息的時間順序;順序圖的一個用途是用來表示用例中的行為順序。當執行一個用例行為時,順序圖中的每條訊息對應了一個類操作或狀態機中引起轉換的觸發事件

協作圖

協作、互動、協作物件、訊息

協作圖對在一次互動中有意義的物件和物件間的鏈建模。物件和關係只有在互動的語境中才有意義。類元角色描述了一個物件,關聯角色描述了協作關係中的一個鏈。協作圖的一個用途是表示一個類操作的實現。協作圖可以說明類操作中用到的引數和區域性變數以及操作中的永久鏈。

模型管理(說明模型的分層組織結構)

模型管理檢視

類圖

包、子系統、模型

模型管理檢視對模型自身組織建模一系列由模型元素(如類、狀態機和用例)構成的包組成了模型

包可能包含其他的包,因此,整個模型實際上可看成一個根包,它間接包含了模型中的所有內容。包是操作模型內容、存取控制和配置控制的基本單元。

每一個模型元素包含於包中或包含於其他模型元素中。模型是從某一觀點以一定的精確程度對系統所進行的完整描述。從不同的視角出發,對同一系統可能會建立多個模型,例如有系統分析模型和系統設計模型之分。模型是一種特殊的包。子系統是另一種特殊的包。它代表了系統的一個部分,它有清晰的介面,這個介面可作為一個單獨的構件來實現。

任何大的系統都必須被分成幾個小的單元,這使得人們一次只處理有限的資訊,並且分別處理這些資訊的工作組之間互不干擾,模型管理由包及包之間的依賴關係組成。

可擴充套件性

所有

所有

約束、構造型、標記值

U M L包含三種主要的擴充套件元件:約束、構造型和標記值約束是用某種形式化語言或自然語言表達的語義關係的文字說明構造型是由建模者設計的新的模型元素,但是這個模型元素的設計要建立在U M L已定義的模型元素基礎上。標記值是附加到任何模型元素上的命名的資訊塊。這些元件提供了擴充套件 U M L模型元素語義的方法,同時不改變 U M L定義的元模型自身的語義。使用這些擴充套件元件可以組建適用於某一具體應用領域的 U M L使用者定製版本。

UML提供幾種擴充套件機制,允許建模者在不改變基本建模語言的基礎上做一些通用的擴充套件。這些擴充套件機制已經被設計好,以便在不需要理解全部語義的情況下就可以儲存和使用。由於這個原因,擴充套件可以作為字串儲存和使用。對不支援擴充套件機制的工具來說,擴充套件只是一個字串,可以作為模型的一部分被匯入、儲存,還可以傳遞到其他工具。我們期望後端工具設計成能夠處理各種擴充套件,這些工具會為他們需要理解的擴充套件定義特定的語法和語義。

這種擴充套件方法很可能不能滿足出現的多種要求,但是它以一種易於實現的簡單方式容納建模者對UML制裁的大部分要求。

一定要記住擴充套件是違反UML的標準形式的,並且使用它們會導致互相影響,在使用擴充套件機制之前,建模者應該仔細權衡利弊,特別是當前現有機制可以合理工作時。典型的,擴充套件用於特定的應用域或程式設計環境,但是他們導致了UML方言的出現,包括所有方言的優點和缺點。