UML - 用例圖

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

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

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

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

用例圖的目的

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

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

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

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

• 用於收集系統的需求。

• 用於獲取系統的外部檢視。

• 識別影響系統的外部和內部因素。

• 顯示需求和參與者之間的互動。

如何繪製用例圖？

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

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

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

• 表示為用例的功能

• 參與者

• 用例和參與者之間的關係。

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

• 用例的名稱非常重要。應以能夠識別所執行功能的方式選擇名稱。

• 為參與者提供合適的名稱。

• 在圖中清晰地顯示關係和依賴關係。

• 不要試圖包含所有型別的關係，因為圖的主要目的是識別需求。

• 在需要時使用註釋來闡明一些要點。

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

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

在哪裡使用用例圖？

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

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

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

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

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

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

用例圖可用於：

• 需求分析和高階設計。

• 對系統的上下文進行建模。

• 反向工程。

• 正向工程。