要建立一個系統的模型，最重要的方面就是捕捉動態行為。動態行為意味著系統在運行/運行時的行為。

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

這些內部和外部代理被稱為演員。用例圖由角色，用例及其關係組成。該圖用於建模應用程序的系統/子系統。單個用例圖捕獲系統的特定功能。

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

用例圖的目的

用例圖的目的是捕捉系統的動態方面。然而，這個定義過於籠統，不能說明目的，因為其他四個圖（活動，順序，協作和狀態圖）也具有相同的目的。我們將研究一些特定的目的，這將與其他四個圖區分開來。

用例圖用於收集包括內部和外部影響的系統需求。這些要求主要是設計要求。因此，當系統被分析以收集其功能時，就準備好使用案例並確定角色。

初始任務完成後，用例圖將建模為呈現外部視圖。

簡而言之，用例圖的目的可以說是如下 -

• 用於收集系統的要求。
• 用於獲取系統的外部視圖。
• 確定影響系統的外部和內部因素。
• 顯示需求之間的交互作用。

用例圖例子 點擊Open Diagram

• 寻找免费的UML工具?

  Visual Paradigm，国际IT奖获奖者，是您的最终选择UML建模。Visual Paradigm Community Edition -完全免费！全世界数以百万计的用户，没有时间限制和跨平台采用。Visual Paradigm 是国际IT奖获奖者，是您的UML建模最终选择。
  
  Visual Paradigm 社区版-完全免费！全世界数以百万计的用户没有时间限制和跨平台采用。

  立即下载

如何繪製用例圖？

用例圖被考慮用於系統的高級需求分析。當系統的需求被分析時，功能被捕獲在用例中。

我們可以說，用例只不過是以有組織的方式編寫的系統功能。與用例相關的第二件事是演員。參與者可以被定義為與系統交互的東西。

參與者可以是人類用戶，某些內部應用程序，也可以是某些外部應用程序。當我們計劃繪製用例圖時，我們應該確定下列項目。

• 功能被表示為用例
• 演員
• 用例和參與者之間的關係。

繪製用例圖來捕獲系統的功能需求。在確定上述項目之後，我們必須使用以下準則來繪製高效的用例圖

• 用例的名稱非常重要。該名稱應該以這樣的方式選擇，以便它可以識別所執行的功能。
• 給演員一個合適的名字。
• 在圖中清楚地顯示關係和相關性。
• 不要試圖包含所有類型的關係，因為圖的主要目的是確定需求。
• 在需要時使用說明來澄清一些重要的觀點。

以下是代表訂單管理系統的示例用例圖。因此，如果我們查看圖表，我們將找到三個用例（Order，SpecialOrder和NormalOrder）和一個是客戶的actor。

SpecialOrder和NormalOrder用例從Order用例擴展而來。因此，他們有擴大的關係。另一個要點是確定圖中所示的系統邊界。演員Customer位於系統之外，因為它是系統的外部用戶。

在哪裡使用用例圖？

正如我們已經討論的那樣，UML中有五個圖來模擬系統的動態視圖。現在每個模型都有一些特定的用途。實際上這些具體目的是一個運行系統的不同角度。

為了理解系統的動態，我們需要使用不同類型的圖表。用例圖就是其中之一，其具體目的是收集系統需求和參與者。

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

這些圖表用於非常高的設計水平。這個高層次的設計被一次又一次地改進，以獲得一個完整和實際的系統圖片。一個結構良好的用例也描述了先決條件，發布條件和異常。這些額外的元素用於執行測試時製作測試用例。

雖然用例不適合用於正向和****，但它們的使用方式略有不同，用於製作正向和****。****也是如此。用例圖的使用方式不同，使其適用於****。

在正向工程中，用例圖用於製作測試用例，反向工程用例用於從現有應用程序中準備需求詳細信息。

用例圖可用於 -

• 需求分析和高層設計。
• 建模系統的上下文。
• ****。
• 正向工程。
  

如何繪製用例圖？
什麼是用例圖？
Visual Paradigm中的用例圖
創建專業用例圖的10個技巧
用例工具