UML用例圖


概述:

為了模擬系統最重要的方面是捕捉到的動態行為。為了闡明位詳細資訊,動態的行為意味著它執行時/作業系統的行為。

因此,只有靜態的行為是不夠的模擬系統,而動態的行為,更重要的是比靜態行為。在UML模型的動態性質和使用情況圖5圖就是其中之一。現在我們要討論的,本質上是動態的用例圖,應該有一些內在或外在因素互動。

這些內部和外部代理是已知的行為體。因此,用例圖由主角,用例和它們之間的關係組成。該圖是用來模型的一個應用程式的系統/子系統。一個單一的用例圖捕獲系統的特定功能。

因此,來模擬整個系統的用例圖。

目的:

用例圖的目的是捕捉到一個系統的動態方面。但這一定義過於籠統描述其目的。

因為其他的四個圖解的圖(活動,序列,共同作業和狀態圖)也具有同樣的目的。因此,我們將尋找到一些特定的目的,這將區別於其他四幅圖。

用例圖是用來收集系統的要求,包括內部和外部的影響。這些要求大多是設計要求。所以,當一個系統的分析,以收集其功能用例和參與者確定。

現在,當最初的任務是完整的用例圖是仿照目前外界的檢視。

因此,簡言之,用例圖的目的如下:

  • 用來收集系統的要求。

  • 用於獲取系統的外觀圖。

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

  • 顯示要求之間的相互作用是參與者.

如何畫用例圖?

用例圖被認為是高層次的需求分析系統。因此,當系統的要求,分析被捕獲在用例的功能。

因此,我們可以說,使用情況是什麼,但在一個有組織的方式編寫的系統功能。現在到用例相關的第二件事情是參與者。行為者可以被定義為與系統進行互動的東西。

參與者可以是人的使用者,一些內部的應用程式,或可能會有一些外部應用程式。因此,在一個簡短的,當我們正計劃繪製一個用例圖中應該有以下專案:

  • 功能被表示為一個用例

  • 參與者

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

繪製到用例圖捕獲系統的功能要求。因此,確定上述專案後,我們必須遵循以下指導原則,繪製一個有效的用例圖。

  • 一個用例的名稱是非常重要的。所以名的選擇應以這樣的方式,以便它可以識別執行的功能。

  • 給出一個合適的名參與者。

  • 圖中清楚地顯示關係和依賴性。

  • 不要試圖包括所有型別的關係。由於該圖的主要目的是確定要求。

  • 使用注意以往任何時候都需要闡明一些重要的點。

下面是一個範例用例圖,代表訂單管理系統。因此,如果我們看看圖,那麼我們會發現三個用例(訂單,特殊訂單和正常訂單)和一個參與者:顧客。

SpecialOrder 和NormalOrder 從訂單使用情況擴充套件。因此,他們擴充套件了關係。另外很重要的一點是確定系統邊界,這是圖中所示。參與者是客戶以外的系統,因為它是系統的外部使用者。

UML Use Case Diagram

在哪裡使用用例圖?

正如我們已經討論過,有五個在UML圖建模系統的動態檢視。現在,每個模型有一些特定目的使用。其實這些特定的目的,是正在執行的系統中的不同角度。

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

用例圖指定系統的事件和他們的流向。但從未用例圖描述了他們是如何實現的。可以被想象成一個黑盒子,只有輸入,輸出和黑盒子的功能被稱為用例圖。

在這些圖中使用的設計在一個非常高的水平。那麼這種高層次的設計高雅,一遍又一遍完善使系統得到一個完整實用的圖片。一個結構良好的用例,還介紹了前置條件,後置條件和例外。而這些多餘的元素在執行測試時被用來製造測試的情況下。

用例都不是正向和反向工程,但他們仍然使用略有不同的方式。同樣是真實的逆向工程。仍用例圖的使用方式不同,使其逆向工程的一個候選。

在正向工程用例圖是用來做測試案例和逆向工程中的使用情況下是用來準備從現有的應用程式的需求細節。

所以下面的地方使用用例圖:

  • 需求分析和高水平的設計。

  • 模擬系統的上下文。

  • 逆向工程。

  • Forward engineering.