UML - 快速指南

上一個

下一個

UML - 概述

UML 是一種用於規範、視覺化、構建和記錄軟體系統構件的標準語言。

UML 由物件管理組 (OMG) 建立，UML 1.0 規範草案於 1997 年 1 月提交給 OMG。

OMG 不斷努力建立真正的行業標準。

UML 代表統一建模語言。
UML 不同於其他常見的程式語言，如 C++、Java、COBOL 等。
UML 是一種圖形語言，用於建立軟體藍圖。
UML 可以被描述為一種通用的視覺化建模語言，用於視覺化、規範、構建和記錄軟體系統。
雖然 UML 通常用於建模軟體系統，但它並不侷限於此。它也用於建模非軟體系統。例如，製造單位中的流程流程等。

UML 不是一種程式語言，但可以使用工具使用 UML 圖生成各種語言的程式碼。UML 與面向物件分析和設計有直接關係。經過一些標準化後，UML 已成為 OMG 標準。

UML 的目標

一圖勝千言，這個習語絕對適合描述 UML。面向物件的概念比 UML 早得多。在那個時候，還沒有標準的方法來組織和整合面向物件的開發。正是那時，UML 出現了。

開發 UML 有許多目標，但最重要的目標是定義一些通用建模語言，所有建模者都可以使用它，並且它也需要易於理解和使用。

UML 圖不僅面向開發人員，也面向業務使用者、普通使用者以及任何對理解系統感興趣的人。系統可以是軟體或非軟體系統。因此必須明確，UML 不是一種開發方法，而是伴隨著流程使其成為一個成功的系統。

總之，UML 的目標可以定義為一種簡單的建模機制，用於建模當今複雜環境中所有可能的實際系統。

UML 的概念模型

要理解 UML 的概念模型，首先我們需要澄清什麼是概念模型？以及為什麼要需要概念模型？

概念模型可以定義為由概念及其關係組成的模型。
概念模型是在繪製 UML 圖之前的第一步。它有助於理解現實世界中的實體以及它們如何相互互動。

由於 UML 描述了即時系統，因此建立概念模型然後逐步進行非常重要。可以透過學習以下三個主要元素來掌握 UML 的概念模型：

UML 構建塊
連線構建塊的規則
UML 的通用機制

面向物件的概念

UML 可以被描述為面向物件 (OO) 分析和設計的繼承者。

一個物件包含資料和控制資料的的方法。資料表示物件的狀態。類描述一個物件，它們也形成一個層次結構來模擬現實世界系統。層次結構表示為繼承，類也可以根據需要以不同的方式關聯。

物件是我們周圍存在的現實世界實體，抽象、封裝、繼承和多型等基本概念都可以用 UML 表示。

UML 足夠強大，可以表示面向物件分析和設計中存在的所有概念。UML 圖僅面向物件概念的表示。因此，在學習 UML 之前，詳細瞭解 OO 概念變得很重要。

以下是面向物件世界的一些基本概念：

物件 - 物件表示實體和基本構建塊。
類 - 類是物件的藍圖。
抽象 - 抽象表示現實世界實體的行為。
封裝 - 封裝是將資料繫結在一起並將其隱藏在外部世界之外的機制。
繼承 - 繼承是從現有類建立新類的機制。
多型 - 它定義了以不同形式存在的機制。

OO 分析與設計

OO 可以定義為調查，更具體地說，它是對物件的調查。設計意味著已識別物件的協作。

因此，瞭解 OO 分析和設計概念非常重要。OO 分析的最重要目的是識別要設計的系統的物件。此分析也針對現有系統進行。現在，只有當我們能夠以能夠識別物件的方式開始思考時，才能進行有效的分析。識別物件後，識別它們的關係，最後生成設計。

OO 分析和設計的目的可以描述為：

識別系統的物件。
識別它們之間的關係。
進行設計，可以使用 OO 語言將其轉換為可執行檔案。

在三個基本步驟中應用和實現了 OO 概念。這些步驟可以定義為

OO Analysis → OO Design → OO implementation using OO languages

以上三點可以詳細描述為：

在 OO 分析期間，最重要的是識別物件並以正確的方式描述它們。如果這些物件被有效地識別，那麼下一步的設計工作就很容易了。應該用職責來識別物件。職責是物件執行的功能。每個物件都有一些要執行的職責。當這些職責協作時，系統的目的就實現了。
第二階段是 OO 設計。在此階段，重點放在需求及其滿足上。在此階段，物件根據其預期關聯進行協作。關聯完成後，設計也完成了。
第三階段是 OO 實現。在此階段，使用 Java、C++ 等 OO 語言實現設計。

UML 在 OO 設計中的作用

UML 是一種用於對軟體和非軟體系統建模的建模語言。儘管 UML 用於非軟體系統，但重點是建模 OO 軟體應用程式。迄今為止討論的大多數 UML 圖都用於建模不同的方面，例如靜態、動態等。現在無論方面如何，工件都不過是物件。

如果我們檢視類圖、物件圖、協作圖、互動圖，所有這些都將基本上基於物件進行設計。

因此，瞭解 OO 設計和 UML 之間的關係非常重要。OO 設計根據需要轉換為 UML 圖。在詳細瞭解 UML 之前，應正確學習 OO 概念。完成 OO 分析和設計後，下一步就非常容易了。來自 OO 分析和設計的輸入是 UML 圖的輸入。

UML - 構建塊

由於 UML 描述了即時系統，因此建立概念模型然後逐步進行非常重要。可以透過學習以下三個主要元素來掌握 UML 的概念模型：

UML 構建塊
連線構建塊的規則
UML 的通用機制

本章描述了所有 UML 構建塊。UML 的構建塊可以定義為：

事物
關係
圖

事物

事物是 UML 最重要的構建塊。事物可以是：

結構的
行為的
分組的
註釋的

結構性事物

結構性事物定義了模型的靜態部分。它們表示物理和概念元素。以下是結構性事物的簡要描述。

類 - 類表示一組具有相似職責的物件。

介面 - 介面定義一組操作，這些操作指定類的職責。

協作 - 協作定義元素之間的互動。

用例 - 用例表示系統為特定目標執行的一組操作。

元件 - 元件描述系統的物理部分。

節點 - 節點可以定義為在執行時存在的物理元素。

行為性事物

行為性事物由 UML 模型的動態部分組成。以下是行為性事物：

互動 - 互動定義為由元素之間交換的一組訊息組成的行為，以完成特定任務。

狀態機 - 當物件在其生命週期中的狀態很重要時，狀態機很有用。它定義了物件響應事件而經歷的狀態序列。事件是導致狀態變化的外部因素

分組事物

分組事物可以定義為將 UML 模型的元素組合在一起的機制。只有一個可用的分組事物：

包 - 包是唯一一個用於收集結構和行為事物的分組事物。

註釋性事物

註釋性事物可以定義為捕獲 UML 模型元素的備註、描述和註釋的機制。注意 - 它是唯一一個可用的註釋性事物。註釋用於呈現 UML 元素的註釋、約束等。

關係

關係是 UML 的另一個最重要的構建塊。它顯示了元素如何相互關聯，並且這種關聯描述了應用程式的功能。

有四種可用的關係。

依賴

依賴關係是兩個事物之間的一種關係，其中一個元素的變化也會影響另一個元素。

關聯

關聯基本上是一組連線UML模型元素的連結。它還描述了有多少物件參與了該關係。

泛化

泛化可以定義為一種將專門化元素與泛化元素連線起來的關係。它基本上描述了物件世界中的繼承關係。

實現

實現可以定義為兩個元素連線的關係。一個元素描述了一些未實現的職責，另一個元素實現它們。這種關係存在於介面的情況下。

UML圖

UML圖是整個討論的最終輸出。所有元素、關係都用於製作完整的UML圖，並且該圖表示一個系統。

UML圖的視覺效果是整個過程中最重要的部分。所有其他元素都用於使其完整。

UML包括以下九種圖，其詳細資訊將在後續章節中描述。

類圖
物件圖
用例圖
序列圖
協作圖
活動圖
狀態圖
部署圖
元件圖

UML - 架構

任何現實世界的系統都被不同的使用者使用。使用者可以是開發人員、測試人員、業務人員、分析師等等。因此，在設計系統之前，架構是考慮到不同的視角而構建的。最重要的是從不同檢視者的角度視覺化系統。我們理解得越好，我們就能更好地構建系統。

UML在定義系統的不同視角方面發揮著重要作用。這些視角包括：

設計
實現
流程
部署

中心是用例檢視，它連線了這四個檢視。用例表示系統的功能。因此，其他視角都與用例相關聯。

系統的設計包括類、介面和協作。UML提供類圖、物件圖來支援這一點。

實現定義了組裝在一起形成完整物理系統的元件。UML元件圖用於支援實現視角。

流程定義了系統的流程。因此，與設計中使用的相同元素也用於支援此視角。

部署表示構成硬體的系統的物理節點。UML部署圖用於支援此視角。

UML - 建模型別

區分UML模型非常重要。不同的圖用於不同型別的UML建模。UML建模有三種重要型別。

結構建模

結構建模捕獲系統的靜態特徵。它們包括以下內容：

類圖
物件圖
部署圖
包圖
複合結構圖
元件圖

結構模型表示系統的框架，並且此框架是所有其他元件存在的位置。因此，類圖、元件圖和部署圖是結構建模的一部分。它們都表示元素以及組裝它們的機制。

結構模型從不描述系統的動態行為。類圖是最廣泛使用的結構圖。

行為建模

行為模型描述系統中的互動。它表示結構圖之間的互動。行為建模顯示了系統的動態特性。它們包括以下內容：

活動圖
互動圖
用例圖

以上所有內容都顯示了系統中動態流程的順序。

架構建模

架構模型表示系統的整體框架。它包含系統的結構和行為元素。架構模型可以定義為整個系統的藍圖。包圖屬於架構建模。

UML - 基本符號

UML因其圖形表示法而流行。我們都知道，UML用於視覺化、指定、構建和記錄軟體和非軟體系統的元件。因此，視覺化是最重要的部分，需要理解和記住。

UML表示法是建模中最重要的元素。有效且恰當地使用表示法對於建立完整且有意義的模型非常重要。除非正確地描繪了模型的目的，否則該模型是無用的。

因此，應該從一開始就強調學習表示法。事物和關係有不同的表示法。UML圖是使用事物和關係的表示法制作的。可擴充套件性是另一個重要的特性，它使UML更加強大和靈活。

本章詳細描述了基本的UML表示法。這只是對第二章中討論的UML構建塊部分的擴充套件。

結構性事物

結構事物中使用的圖形表示法在UML中使用最廣泛。這些被認為是UML模型的名詞。以下是結構事物的列表。

類
物件
介面
協作
用例
活動類
元件
節點

類表示法

UML類由下圖表示。該圖分為四個部分。

頂部部分用於命名類。
第二個部分用於顯示類的屬性。
第三部分用於描述類執行的操作。
第四部分是可選的，用於顯示任何其他元件。

類用於表示物件。物件可以是任何具有屬性和職責的事物。

物件表示法

物件的表示方式與類相同。唯一的區別是名稱是帶下劃線的，如下面的圖所示。

由於物件是類的實際實現，稱為類的例項。因此，它與類的用法相同。

介面表示法

介面由一個圓圈表示，如下面的圖所示。它有一個名稱，通常寫在圓圈下方。

介面用於描述不帶實現的功能。介面就像一個模板，在其中定義不同的函式，而不是實現。當一個類實現介面時，它也會根據需要實現功能。

協作表示法

協作由一個虛線橢圓表示，如下面的圖所示。它在橢圓內寫有一個名稱。

協作表示職責。通常，職責是一組。

用例表示法

用例表示為一個帶有名稱的橢圓。它可能包含其他職責。

用例用於捕獲系統的較高級別功能。

參與者表示法

參與者可以定義為與系統互動的某些內部或外部實體。

參與者用於用例圖中描述內部或外部實體。

初始狀態表示法

初始狀態定義為顯示流程的開始。此表示法幾乎用於所有圖中。

初始狀態表示法的用途是顯示流程的起點。

最終狀態表示法

最終狀態用於顯示流程的結束。此表示法也幾乎用於所有圖中以描述結束。

最終狀態表示法的用途是顯示流程的終止點。

活動類表示法

活動類看起來類似於帶實線的類。活動類通常用於描述系統的併發行為。

活動類用於表示系統中的併發性。

元件表示法

UML中的元件在下圖中以內部名稱顯示。可以在需要的地方新增其他元素。

元件用於表示製作UML圖的系統的任何部分。

節點表示法

UML中的節點由一個正方形表示，如下面的圖所示，帶有名稱。節點表示系統的物理元件。

節點用於表示系統的物理部分，例如伺服器、網路等。

行為性事物

動態部分是UML中最重要的元素之一。UML具有一套強大的功能來表示軟體和非軟體系統的動態部分。這些功能包括互動和狀態機。

互動可以分為兩種型別：

順序（由序列圖表示）
協作（由協作圖表示）

互動表示法

互動基本上是兩個UML元件之間的訊息交換。下圖表示互動中使用的不同表示法。

互動用於表示系統元件之間的通訊。

狀態機表示法

狀態機描述了元件在其生命週期中的不同狀態。表示法在下面的圖中描述。

狀態機用於描述系統元件的不同狀態。狀態可以是活動、空閒或任何其他狀態，具體取決於情況。

分組事物

組織UML模型是設計中最重要的方面之一。在UML中，只有一個可用於分組的元素，那就是包。

包表示法

包表示法如下面的圖所示，用於包裝系統的元件。

註釋性事物

在任何圖中，對不同元素及其功能的解釋都非常重要。因此，UML具有註釋表示法來支援此需求。

註釋表示法

此表示法如下面的圖所示。這些表示法用於提供系統必要的信息。

關係

除非正確描述了元素之間的關係，否則模型是不完整的。關係賦予UML模型正確的含義。以下是UML中可用的不同型別的關係。

依賴
關聯
泛化
可擴充套件性

依賴關係表示法

依賴關係是UML元素中的一個重要方面。它描述了依賴元素和依賴方向。

依賴關係由一個虛線箭頭表示，如下面的圖所示。箭頭表示獨立元素，另一端表示依賴元素。

依賴關係用於表示系統中兩個元素之間的依賴關係

關聯表示法

關聯描述了UML圖中元素是如何關聯的。簡單來說，它描述了多少個元素參與了互動。

關聯由一條帶（不帶）箭頭的虛線表示。兩端表示兩個關聯的元素，如下面的圖所示。倍數也寫在末端（1、* 等），以顯示關聯了多少個物件。

關聯用於表示系統中兩個元素之間的關係。

泛化表示法

泛化描述了面向物件世界的繼承關係。它是父子關係。

泛化由一個帶有空心箭頭的箭頭表示，如下面的圖所示。一端表示父元素，另一端表示子元素。

泛化用於描述系統中兩個元素的父子關係。

可擴充套件性表示法

所有語言（程式設計或建模）都有一些機制來擴充套件其功能，例如語法、語義等。UML還具有以下機制來提供可擴充套件性功能。

構造型（表示新元素）
標記值（表示新屬性）
約束（表示邊界）

可擴充套件性表示法用於增強語言的功能。它基本上是用於表示系統某些額外行為的附加元素。這些額外行為沒有被標準的可用表示法覆蓋。

UML - 標準圖

在前面的章節中，我們討論了UML的構建塊和其他必要的元素。現在我們需要了解在哪裡使用這些元素。

元素就像元件，可以以不同的方式關聯起來構成完整的UML圖，即所謂的圖。因此，瞭解不同的圖以在現實系統中應用這些知識非常重要。

任何複雜的系統，最好的理解方式就是繪製一些圖表或圖片。這些圖表對我們的理解有更好的影響。如果我們環顧四周，就會意識到圖表並不是一個新概念，而是在不同行業的不同形式中被廣泛使用。

我們準備UML圖是為了以更好、更簡單的方式理解系統。單個圖不足以涵蓋系統的所有方面。UML定義了各種型別的圖來涵蓋系統的大部分方面。

你也可以建立自己的圖表集來滿足你的需求。圖表通常以增量和迭代的方式製作。

圖表主要分為兩大類，並且再次細分為子類別：

結構圖
行為圖

結構圖

結構圖表示系統的靜態方面。這些靜態方面表示構成主要結構並因此穩定的圖表部分。

這些靜態部分由類、介面、物件、元件和節點表示。四種結構圖如下：

類圖
物件圖
元件圖
部署圖

類圖

類圖是UML中最常用的圖。類圖由類、介面、關聯和協作組成。類圖基本上表示系統的面向物件檢視，其本質是靜態的。

活動類用於在類圖中表示系統的併發性。

類圖表示系統的面向物件特性。因此，它通常用於開發目的。這是系統構建時使用最廣泛的圖。

物件圖

物件圖可以描述為類圖的一個例項。因此，這些圖更接近於我們實現系統的現實場景。

物件圖是一組物件及其關係，就像類圖一樣。它們也表示系統的靜態檢視。

物件圖的用法類似於類圖，但它們用於從實踐角度構建系統的原型。

元件圖

元件圖表示一組元件及其關係。這些元件由類、介面或協作組成。元件圖表示系統的實現檢視。

在設計階段，系統的軟體構件（類、介面等）根據它們的關係被安排成不同的組。現在，這些組被稱為元件。

最後，可以說元件圖用於視覺化實現。

部署圖

部署圖是一組節點及其關係。這些節點是部署元件的物理實體。

部署圖用於視覺化系統的部署檢視。這通常由部署團隊使用。

注意 - 如果仔細觀察上述描述和用法，就會很清楚所有圖表之間都存在某種關係。元件圖依賴於類、介面等，這些是類/物件圖的一部分。同樣，部署圖依賴於用於建立元件圖的元件。

行為圖

任何系統都可以具有兩個方面，即靜態和動態。因此，當這兩個方面都被完全覆蓋時，模型才被認為是完整的。

行為圖基本上捕獲系統的動態方面。動態方面可以進一步描述為系統的變化/移動部分。

UML具有以下五種型別的行為圖：

用例圖
序列圖
協作圖
狀態圖
活動圖

用例圖

用例圖是一組用例、參與者及其關係。它們表示系統的用例檢視。

用例表示系統的特定功能。因此，用例圖用於描述功能之間及其內部/外部控制器的關係。這些控制器被稱為參與者。

順序圖

順序圖是一種互動圖。從名稱上可以清楚地看出，該圖處理一些序列，即從一個物件到另一個物件的訊息序列。

系統元件之間的互動對於實現和執行角度來說非常重要。順序圖用於視覺化系統中執行特定功能的呼叫序列。

協作圖

協作圖是互動圖的另一種形式。它表示系統的結構組織以及傳送/接收的訊息。結構組織由物件和連結組成。

協作圖的目的與順序圖類似。但是，協作圖的具體目的是視覺化物件的組織及其互動。

狀態圖

任何即時系統都期望對某種內部/外部事件做出反應。這些事件導致系統的狀態變化。

狀態圖用於表示系統的事件驅動狀態變化。它基本上描述了類、介面等的狀態變化。

狀態圖用於視覺化系統對內部/外部因素的反應。

活動圖

活動圖描述了系統中的控制流。它由活動和連結組成。流可以是順序的、併發的或分支的。

活動只不過是系統函式。準備了大量的活動圖來捕獲系統中的整個流程。

活動圖用於視覺化系統中的控制流。準備它是為了瞭解系統在執行時將如何工作。

注意 - 系統的動態特性非常難以捕獲。UML提供了從不同角度捕獲系統動態特性的功能。順序圖和協作圖是同構的，因此可以在不丟失任何資訊的情況下相互轉換。狀態圖和活動圖也是如此。

UML - 類圖

類圖是靜態圖。它表示應用程式的靜態檢視。類圖不僅用於視覺化、描述和記錄系統的不同方面，還用於構建軟體應用程式的可執行程式碼。

類圖描述了類的屬性和操作，以及對系統施加的約束。類圖廣泛用於面向物件系統的建模，因為它們是唯一可以與面嚮物件語言直接對映的UML圖。

類圖顯示了類、介面、關聯、協作和約束的集合。它也被稱為結構圖。

類圖的目的

類圖的目的是對應用程式的靜態檢視進行建模。類圖是唯一可以與面嚮物件語言直接對映的圖，因此在構建時被廣泛使用。

像活動圖、順序圖這樣的UML圖只能給出應用程式的順序流，但是類圖有所不同。它是編碼社群中最流行的UML圖。

類圖的目的可以概括為：

分析和設計應用程式的靜態檢視。
描述系統的職責。
元件和部署圖的基礎。
正向和反向工程。

如何繪製類圖？

類圖是用於構建軟體應用程式的最流行的UML圖。學習類圖的繪製過程非常重要。

類圖在繪製時需要考慮許多屬性，但這裡將從頂層檢視考慮該圖。

類圖基本上是系統靜態檢視的圖形表示，並表示應用程式的不同方面。類圖的集合表示整個系統。

繪製類圖時應記住以下幾點：

類圖的名稱應具有意義，以描述系統的方面。
應提前識別每個元素及其關係。
應明確識別每個類的職責（屬性和方法）。
對於每個類，應指定最少的屬性，因為不必要的屬性會使圖變得複雜。
在需要時使用註釋來描述圖的某些方面。在繪製結束時，它應該讓開發人員/編碼人員易於理解。
最後，在製作最終版本之前，應在普通紙上繪製圖表，並儘可能多次重新繪製以使其正確。

下圖是應用程式訂單系統的示例。它描述了整個應用程式的特定方面。

首先，訂單和客戶被識別為系統的兩個元素。它們具有一對多關係，因為一個客戶可以有多個訂單。
Order類是一個抽象類，它有兩個具體類（繼承關係）SpecialOrder和NormalOrder。
兩個繼承類都具有與Order類相同的屬性。此外，它們還具有其他功能，如dispatch()和receive()。

下圖是在考慮上述所有要點的情況下繪製的。

類圖在哪裡使用？

類圖是靜態圖，用於對系統的靜態檢視進行建模。靜態檢視描述了系統的詞彙表。

類圖也被認為是元件和部署圖的基礎。類圖不僅用於視覺化系統的靜態檢視，還用於構建任何系統的正向和反向工程的可執行程式碼。

通常，UML圖不會與任何面向物件程式語言直接對映，但類圖是一個例外。

類圖清晰地展示了與面嚮物件語言（如 Java、C++ 等）的對映關係。從實踐經驗來看，類圖通常用於構建目的。

簡而言之，類圖用於：

描述系統的靜態檢視。
展示靜態檢視中元素之間的協作關係。
描述系統執行的功能。
使用面嚮物件語言構建軟體應用程式。

UML - 物件圖

物件圖是從類圖派生出來的，因此物件圖依賴於類圖。

物件圖表示類圖的一個例項。類圖和物件圖的基本概念相似。物件圖也表示系統的靜態檢視，但這種靜態檢視是系統在特定時刻的快照。

物件圖用於呈現一組物件及其關係作為例項。

物件圖的目的

要將物件圖在實踐中應用，必須清楚地理解其目的。物件圖的目的與類圖類似。

區別在於，類圖表示一個由類及其關係組成的抽象模型。然而，物件圖表示特定時刻的一個例項，其本質是具體的。

這意味著物件圖更接近實際系統的行為。其目的是捕捉系統在特定時刻的靜態檢視。

物件圖的目的可以概括為：

正向和反向工程。
系統的物件關係
互動的靜態檢視。
從實踐角度理解物件行為及其關係

如何繪製物件圖？

我們已經討論過，物件圖是類圖的一個例項。這意味著物件圖包含類圖中使用的例項。

因此，這兩個圖都由相同的基本元素組成，但形式不同。在類圖中，元素以抽象形式表示藍圖，而在物件圖中，元素以具體形式表示現實世界中的物件。

為了捕捉特定的系統，類圖的數量是有限的。但是，如果我們考慮物件圖，則可以擁有無限數量的例項，這些例項本質上是唯一的。只有那些對系統有影響的例項才會被考慮。

從以上討論可以看出，單個物件圖無法捕捉所有必要的例項，或者說無法指定系統的所有物件。因此，解決方案是：

首先，分析系統並確定哪些例項具有重要的資料和關聯。
其次，只考慮那些能夠覆蓋功能的例項。
第三，進行一些最佳化，因為例項的數量是無限的。

在繪製物件圖之前，應記住並清楚地理解以下幾點：

物件圖由物件組成。
物件圖中的連結用於連線物件。
物件和連結是用於構建物件圖的兩個元素。

在此之後，在開始構建圖之前需要確定以下幾點：

物件圖應具有有意義的名稱以指示其目的。
識別最重要的元素。
闡明物件之間的關聯關係。
捕獲不同元素的值以包含在物件圖中。
在需要更多清晰度的點新增適當的註釋。

下圖是一個物件圖的示例。它表示我們在類圖章節中討論過的訂單管理系統。下圖是系統在購買特定時間的例項。它包含以下物件。

客戶
訂單
特殊訂單
普通訂單

現在，客戶物件 (C) 與三個訂單物件 (O1、O2 和 O3) 相關聯。這些訂單物件與特殊訂單和普通訂單物件 (S1、S2 和 N1) 相關聯。客戶在所考慮的特定時間擁有以下三個訂單，訂單編號分別為 12、32 和 40。

客戶將來可以增加訂單數量，在這種情況下，物件圖將反映出來。如果觀察訂單、特殊訂單和普通訂單物件，您會發現它們具有一些值。

對於訂單，其值為 12、32 和 40，這意味著物件在特定時刻（此處將購買完成時的特定時間視為時刻）捕獲例項時具有這些值。

特殊訂單和普通訂單物件也是如此，它們分別具有 20、30 和 60 的訂單數量。如果考慮不同的購買時間，則這些值將相應地改變。

下圖是在考慮上述所有要點後繪製的物件圖。

在哪裡使用物件圖？

可以將物件圖想象成正在執行的系統在特定時刻的快照。讓我們以正在執行的火車為例。

現在，如果您拍攝正在執行的火車的快照，您會發現它的靜態圖片，其中包含以下內容：

一個特定的狀態，即正在執行。
特定數量的乘客，如果在不同的時間拍攝快照，這個數量將發生變化。

在這裡，我們可以想象正在執行的火車的快照是一個具有上述值的物件。對於任何現實生活中簡單或複雜的系統，情況都是如此。

簡而言之，可以說物件圖用於：

建立系統的原型。
逆向工程。
建模複雜的資料結構。
從實踐角度理解系統。

UML - 元件圖

元件圖在性質和行為方面有所不同。元件圖用於對系統的物理方面進行建模。現在問題是，這些物理方面是什麼？物理方面是指可執行檔案、庫、檔案、文件等駐留在節點中的元素。

元件圖用於視覺化系統中元件的組織和關係。這些圖還用於建立可執行系統。

元件圖的目的

元件圖是 UML 中一種特殊的圖。其目的也與迄今為止討論的所有其他圖不同。它不描述系統功能，而是描述用於實現這些功能的元件。

因此，從這個角度來看，元件圖用於視覺化系統中的物理元件。這些元件包括庫、包、檔案等。

元件圖也可以描述為系統的靜態實現檢視。靜態實現表示特定時刻元件的組織方式。

單個元件圖無法表示整個系統，而是使用一組圖來表示整體。

元件圖的目的可以概括為：

視覺化系統的元件。
透過使用正向和反向工程構建可執行檔案。
描述元件的組織和關係。

如何繪製元件圖？

元件圖用於描述系統的物理構件。這些構件包括檔案、可執行檔案、庫等。

此圖的目的不同。元件圖在應用程式的實現階段使用。但是，它會提前準備好以視覺化實現細節。

最初，系統使用不同的 UML 圖進行設計，然後當構件準備就緒時，使用元件圖來了解實現情況。

此圖非常重要，因為沒有它，應用程式就無法有效地實現。精心準備的元件圖對於其他方面（如應用程式效能、維護等）也很重要。

在繪製元件圖之前，需要清楚地識別以下構件：

系統中使用的檔案。
與應用程式相關的庫和其他構件。
構件之間的關係。

識別完構件後，需要注意以下幾點。

使用有意義的名稱來標識要繪製圖的元件。
在使用工具生成之前，先在腦海中進行佈局。
使用註釋來闡明重要要點。

以下是訂單管理系統的元件圖。此處，構件為檔案。該圖顯示了應用程式中的檔案及其關係。實際上，元件圖還包含 dll、庫、資料夾等。

在下圖中，識別了四個檔案並生成了它們之間的關係。元件圖不能直接與迄今為止討論的其他 UML 圖匹配，因為它用於完全不同的目的。

下圖是在考慮上述所有要點後繪製的元件圖。

在哪裡使用元件圖？

我們已經描述過，元件圖用於視覺化系統的靜態實現檢視。元件圖是用於不同目的的 UML 圖的特殊型別。

這些圖顯示了系統的物理元件。為了闡明這一點，我們可以說元件圖描述了系統中元件的組織方式。

組織可以進一步描述為元件在系統中的位置。這些元件以特殊的方式組織以滿足系統需求。

正如我們已經討論過的，這些元件包括庫、檔案、可執行檔案等。在實現應用程式之前，需要組織這些元件。這種元件組織也作為專案執行的一部分單獨設計。

元件圖從實現的角度來看非常重要。因此，應用程式的實現團隊應該具備元件細節的正確知識。

元件圖可用於：

對系統的元件進行建模。
對資料庫模式進行建模。
對應用程式的可執行檔案進行建模。
對系統的原始碼進行建模。

UML - 部署圖

部署圖用於視覺化系統的物理元件拓撲，軟體元件部署在其中。

部署圖用於描述系統的靜態部署檢視。部署圖由節點及其關係組成。

部署圖的目的

術語“部署”本身描述了圖的目的。部署圖用於描述硬體元件，軟體元件部署在其中。元件圖和部署圖密切相關。

元件圖用於描述元件，而部署圖則顯示它們如何在硬體中部署。

UML 主要設計用於關注系統的軟體構件。但是，這兩個圖是用於關注軟體和硬體元件的特殊圖。

大多數UML圖用於處理邏輯元件，但部署圖旨在關注系統的硬體拓撲結構。部署圖由系統工程師使用。

部署圖的目的可以描述為：

視覺化系統的硬體拓撲結構。
描述用於部署軟體元件的硬體元件。
描述執行時處理節點。

如何繪製部署圖？

部署圖表示系統的部署檢視。它與元件圖相關，因為元件是使用部署圖部署的。部署圖由節點組成。節點只不過是用於部署應用程式的物理硬體。

部署圖對系統工程師很有用。一個有效的部署圖非常重要，因為它控制以下引數：

效能
可擴充套件性
可維護性
可移植性

在繪製部署圖之前，應識別以下工件：

節點
節點之間的關係

下面是一個示例部署圖，用於提供訂單管理系統部署檢視的概念。這裡，我們顯示節點如下：

監控器
調變解調器
快取伺服器
伺服器

假設應用程式是一個基於Web的應用程式，它使用伺服器1、伺服器2和伺服器3部署在叢集環境中。使用者透過網際網路連線到應用程式。控制流從快取伺服器流向叢集環境。

以下部署圖是在考慮上述所有要點的情況下繪製的。

在哪裡使用部署圖？

部署圖主要由系統工程師使用。這些圖用於描述物理元件（硬體）、它們的分佈和關聯。

部署圖可以被視為軟體元件駐留其上的硬體元件/節點。

軟體應用程式是為了模擬複雜的業務流程而開發的。有效的軟體應用程式不足以滿足業務需求。業務需求可以描述為支援越來越多的使用者、快速響應時間等的需求。

為了滿足這些型別的需求，應高效且經濟地設計硬體元件。

如今，軟體應用程式的本質非常複雜。軟體應用程式可以是獨立的、基於Web的、分散式的、基於大型機的等等。因此，高效地設計硬體元件非常重要。

部署圖可用於：

對系統的硬體拓撲結構建模。
對嵌入式系統建模。
對客戶機/伺服器系統的硬體細節建模。
對分散式應用程式的硬體細節建模。
用於正向和反向工程。

UML - 用例圖

為了對系統進行建模，最重要的方面是捕獲動態行為。動態行為是指系統執行/操作時的行為。

僅有靜態行為不足以對系統進行建模，動態行為比靜態行為更重要。在UML中，有五個圖可用於對動態特性進行建模，用例圖就是其中之一。現在，既然我們必須討論用例圖本質上是動態的，那麼應該有一些內部或外部因素來進行互動。

這些內部和外部代理稱為參與者。用例圖由參與者、用例及其關係組成。該圖用於對應用程式的系統/子系統進行建模。單個用例圖捕獲系統的一個特定功能。

因此，為了對整個系統進行建模，使用了多個用例圖。

用例圖的目的

用例圖的目的是捕獲系統的動態方面。但是，這個定義過於籠統，無法描述目的，因為其他四個圖（活動圖、序列圖、協作圖和狀態圖）也有相同的目的。我們將研究一些具體目的，這將使它與其他四個圖區分開來。

用例圖用於收集系統的需求，包括內部和外部影響。這些需求大多是設計需求。因此，當分析系統以收集其功能時，會準備用例並識別參與者。

初始任務完成後，會對用例圖進行建模以呈現外部檢視。

簡而言之，用例圖的目的可以概括如下：

用於收集系統的需求。
用於獲取系統的外部檢視。
識別影響系統的外部和內部因素。
顯示需求和參與者之間的互動。

如何繪製用例圖？

用例圖被認為是系統的高階需求分析。當分析系統的需求時，功能將在用例中捕獲。

可以說，用例只不過是以有組織的方式編寫的系統功能。與用例相關的第二件事是參與者。參與者可以定義為與系統互動的任何事物。

參與者可以是人類使用者、一些內部應用程式，或者可能是某些外部應用程式。當我們計劃繪製用例圖時，應該識別以下專案。

要表示為用例的功能
參與者
用例和參與者之間的關係。

用例圖用於捕獲系統的功能需求。識別上述專案後，我們必須使用以下指南來繪製有效的用例圖

用例的名稱非常重要。應選擇名稱以使其能夠識別執行的功能。
為參與者提供合適的名稱。
在圖中清楚地顯示關係和依賴關係。
不要嘗試包含所有型別的關係，因為圖的主要目的是識別需求。
在需要時使用註釋來澄清一些要點。

下面是一個示例用例圖，表示訂單管理系統。因此，如果我們檢視該圖，我們將發現三個用例（訂單、特殊訂單和普通訂單）和一個參與者，即客戶。

特殊訂單和普通訂單用例是從訂單用例擴充套件的。因此，它們具有擴充套件關係。另一個要點是識別系統邊界，如圖片所示。參與者客戶位於系統外部，因為它是系統的外部使用者。

在哪裡使用用例圖？

正如我們已經討論的那樣，UML中有五個圖用於對系統的動態檢視進行建模。現在，每個模型都有一些特定的用途。實際上，這些特定的用途是正在執行的系統的不同角度。

要了解系統的動態特性，我們需要使用不同型別的圖。用例圖就是其中之一，其特定目的是收集系統需求和參與者。

用例圖指定系統的事件及其流程。但是用例圖從未描述它們是如何實現的。用例圖可以想象成一個黑盒，只有黑盒的輸入、輸出和功能是已知的。

這些圖在非常高的設計級別使用。這種高階設計會反覆細化，以獲得系統的完整和實用圖景。結構良好的用例還描述了先決條件、後置條件和異常。這些額外元素用於在執行測試時建立測試用例。

雖然用例不是正向和反向工程的良好候選者，但它們仍然以略微不同的方式用於進行正向和反向工程。反向工程也是如此。用例圖的使用方式有所不同，以使其適合反向工程。

在正向工程中，用例圖用於建立測試用例；在反向工程中，用例圖用於從現有應用程式準備需求詳細資訊。

用例圖可用於：

需求分析和高階設計。
對系統的上下文建模。
逆向工程。
正向工程。

UML - 互動圖

從術語“互動”可以清楚地看出，該圖用於描述模型中不同元素之間的一些型別的互動。這種互動是系統動態行為的一部分。

這種互動行為在UML中由兩個圖表示，稱為序列圖和協作圖。這兩個圖的基本目的是相似的。

序列圖強調訊息的時間順序，協作圖強調發送和接收訊息的物件的結構組織。

互動圖的目的

互動圖的目的是視覺化系統的互動行為。視覺化互動是一項困難的任務。因此，解決方案是使用不同型別的模型來捕獲互動的不同方面。

序列圖和協作圖用於捕獲動態特性，但從不同的角度出發。

互動圖的目的是：

捕獲系統的動態行為。
描述系統中的訊息流。
描述物件的結構組織。
描述物件之間的互動。

如何繪製互動圖？

正如我們已經討論的那樣，互動圖的目的是捕獲系統的動態方面。因此，為了捕獲動態方面，我們需要了解什麼是動態方面以及如何對其進行視覺化。動態方面可以定義為系統在特定時刻的快照。

UML中有兩種型別的互動圖。一種是序列圖，另一種是協作圖。序列圖捕獲從一個物件到另一個物件的訊息流的時間順序，而協作圖描述參與訊息流的系統中物件的組織。

在繪製互動圖之前，需要清楚地識別以下事項

參與互動的物件。
物件之間的訊息流。
訊息流的順序。
物件組織。

以下是兩個對訂單管理系統進行建模的互動圖。第一個圖是序列圖，第二個是協作圖

序列圖

序列圖有四個物件（客戶、訂單、特殊訂單和普通訂單）。

下圖顯示了特殊訂單物件的訊息序列，在普通訂單物件的情況下也可以使用相同的訊息序列。瞭解訊息流的時間順序非常重要。訊息流只不過是物件的方法呼叫。

第一個呼叫是sendOrder ()，它是Order 物件的方法。下一個呼叫是confirm ()，它是SpecialOrder物件的方法，最後一個呼叫是Dispatch ()，它是SpecialOrder物件的方法。下圖主要描述了從一個物件到另一個物件的方法呼叫，這也是系統執行時的實際場景。

協作圖

第二個互動圖是協作圖。它顯示瞭如下所示的物件組織。在協作圖中，方法呼叫序列由某種編號技術指示。數字表示方法如何一個接一個地被呼叫。我們以相同的訂單管理系統來描述協作圖。

方法呼叫類似於順序圖。但是，區別在於順序圖沒有描述物件組織，而協作圖顯示了物件組織。

在這兩個圖之間進行選擇時，重點放在需求型別上。如果時間順序很重要，則使用順序圖。如果需要組織，則使用協作圖。

在哪裡使用互動圖？

我們已經討論過互動圖用於描述系統的動態特性。現在，我們將深入瞭解這些圖的實際應用場景。為了理解實際應用，我們需要了解順序圖和協作圖的基本性質。

這兩個圖的主要目的是相似的，因為它們都用於捕獲系統的動態行為。但是，具體目的更重要，需要澄清和理解。

順序圖用於捕獲從一個物件到另一個物件的訊息流順序。協作圖用於描述參與互動的物件的結構組織。單個圖不足以描述整個系統的動態方面，因此使用一組圖來整體捕獲它。

當我們想要理解訊息流和結構組織時，會使用互動圖。訊息流表示從一個物件到另一個物件的控制流序列。結構組織表示系統中元素的視覺化組織。

互動圖可用於 -

透過時間序列對控制流進行建模。
透過結構組織對控制流進行建模。
用於正向工程。
用於逆向工程。

UML - 狀態圖

圖的名稱本身就闡明瞭圖的目的和其他細節。它描述了系統中元件的不同狀態。狀態特定於系統的元件/物件。

狀態圖描述了一個狀態機。狀態機可以定義為一個機器，它定義了物件的不同的狀態，並且這些狀態受外部或內部事件控制。

下一章解釋的活動圖是一種特殊的狀態圖。由於狀態圖定義了狀態，因此它用於對物件的生存期進行建模。

狀態圖的目的

狀態圖是用於對系統的動態特性進行建模的五個UML圖之一。它們定義了物件在其生命週期中的不同狀態，並且這些狀態會因事件而改變。狀態圖可用於對反應式系統進行建模。反應式系統可以定義為響應外部或內部事件的系統。

狀態圖描述了從一個狀態到另一個狀態的控制流。狀態定義為物件存在的一種條件，並且當觸發某些事件時，它會發生變化。狀態圖最重要的目的是對物件從建立到終止的生命週期進行建模。

狀態圖也用於系統的正向和逆向工程。但是，主要目的是對反應式系統進行建模。

以下是使用狀態圖的主要目的 -

對系統的動態方面進行建模。
對反應式系統的生命週期進行建模。
描述物件在其生命週期中的不同狀態。
定義狀態機來對物件的狀態進行建模。

如何繪製狀態圖？

狀態圖用於描述不同物件在其生命週期中的狀態。重點放在某些內部或外部事件發生時狀態的變化上。這些物件的狀態對於分析和準確實現它們非常重要。

狀態圖對於描述狀態非常重要。狀態可以識別為物件在發生特定事件時的條件。

在繪製狀態圖之前，我們應該明確以下幾點 -

確定要分析的重要物件。
確定狀態。
確定事件。

以下是一個狀態圖示例，其中分析了Order 物件的狀態

第一個狀態是空閒狀態，從這裡開始流程。接下來的狀態是針對諸如傳送請求、確認請求和排程訂單之類的事件而到達的。這些事件負責訂單物件的狀態變化。

在物件（此處為訂單物件）的生命週期中，它會經歷以下狀態，並且可能存在一些異常退出。這種異常退出可能是由於系統中的一些問題引起的。當整個生命週期完成後，它被認為是一個完整的交易，如下面的圖所示。物件初始狀態和最終狀態也顯示在下圖中。

在哪裡使用狀態圖？

從以上討論中，我們可以定義狀態圖的實際應用。狀態圖用於對系統的動態方面進行建模，就像本教程中討論的其他四個圖一樣。但是，它具有一些用於建模動態特性的區別特徵。

狀態圖定義了元件的狀態，並且這些狀態變化本質上是動態的。它的具體目的是定義由事件觸發的狀態變化。事件是影響系統的內部或外部因素。

狀態圖用於對狀態以及作用於系統的事件進行建模。在實現系統時，明確物件在其生命週期中的不同狀態非常重要，狀態圖用於此目的。當這些狀態和事件被識別後，它們被用來對其進行建模，並且這些模型在系統實現過程中被使用。

如果我們深入研究狀態圖的實際實現，那麼它主要用於分析受事件影響的物件狀態。這種分析有助於理解系統在執行過程中的行為。

主要用途可以描述為 -

對系統的物件狀態進行建模。
對反應式系統進行建模。反應式系統由反應式物件組成。
識別導致狀態變化的事件。
正向和反向工程。

UML - 活動圖

活動圖是UML中另一個重要的圖，用於描述系統的動態方面。

活動圖基本上是一個流程圖，用於表示從一個活動到另一個活動的流程。活動可以描述為系統的操作。

控制流從一個操作繪製到另一個操作。此流可以是順序的、分支的或併發的。活動圖透過使用不同的元素（如 fork、join 等）來處理所有型別的流控制。

活動圖的目的

活動圖的基本目的與其他四個圖相似。它捕獲系統的動態行為。其他四個圖用於顯示從一個物件到另一個物件的訊息流，但活動圖用於顯示從一個活動到另一個活動的訊息流。

活動是系統的一個特定操作。活動圖不僅用於視覺化系統的動態特性，還用於透過使用正向和逆向工程技術構建可執行系統。活動圖中唯一缺少的是訊息部分。

它沒有顯示從一個活動到另一個活動的訊息流。活動圖有時被認為是流程圖。儘管圖表看起來像流程圖，但它們不是。它顯示了不同的流程，例如並行、分支、併發和單個流程。

活動圖的目的可以描述為 -

繪製系統的活動流程。
描述從一個活動到另一個活動的序列。
描述系統的並行、分支和併發流程。

如何繪製活動圖？

活動圖主要用作流程圖，它包含系統執行的活動。活動圖並不完全是流程圖，因為它們具有一些額外的功能。這些附加功能包括分支、並行流、泳道等。

在繪製活動圖之前，我們必須清楚地瞭解活動圖中使用的元素。活動圖的主要元素是活動本身。活動是系統執行的功能。在識別活動後，我們需要了解它們如何與約束和條件相關聯。

在繪製活動圖之前，我們應該識別以下元素 -

活動
關聯
條件
約束

一旦識別出上述引數，我們就需要對整個流程進行心理佈局。然後將此心理佈局轉換為活動圖。

以下是一個訂單管理系統的活動圖示例。在圖中，識別了四個活動，這些活動與條件相關聯。應該清楚地理解一個重要點，即活動圖不能完全與程式碼匹配。活動圖旨在瞭解活動的流程，主要由業務使用者使用。

下圖是用四個主要活動繪製的 -

客戶傳送訂單
接收訂單
確認訂單
分發訂單

在收到訂單請求後，會執行條件檢查以檢查訂單是普通訂單還是特殊訂單。在識別訂單型別後，執行分發活動，並將其標記為流程的結束。

活動圖在哪裡使用？

活動圖的基本用法與其他四種UML圖類似。其具體用法是模擬從一個活動到另一個活動的控制流。這種控制流不包括訊息。

活動圖適用於模擬系統的活動流程。一個應用程式可以有多個系統。活動圖還捕獲這些系統並描述從一個系統到另一個系統的流程。這種特定用法在其他圖中不可用。這些系統可以是資料庫、外部佇列或任何其他系統。

我們現在將研究活動圖的實際應用。從以上討論可以看出，活動圖是從一個非常高的層次繪製的。因此，它提供了系統的**高層檢視**。這種高層檢視主要面向業務使用者或任何其他非技術人員。

此圖用於模擬活動，這些活動只不過是業務需求。該圖對業務理解的影響大於對實現細節的影響。

活動圖可用於 -

使用活動建模工作流。
建模業務需求。
對系統功能的高階理解。
在後期調查業務需求。

列印頁面