UML用例圖
概述:
為了模擬係統最重要的方麵是捕捉到的動態行為。為了闡明位詳細信息,動態的行為意味著它運行時/操作係統的行為。
因此,隻有靜態的行為是不夠的模擬係統,而動態的行為,更重要的是比靜態行為。在UML模型的動態性質和使用情況圖5圖就是其中之一。現在我們要討論的,本質上是動態的用例圖,應該有一些內在或外在因素互動。
這些內部和外部代理是已知的行為體。因此,用例圖由主角,用例和它們之間的關係組成。該圖是用來模型的一個應用程序的係統/子係統。一個單一的用例圖捕獲係統的特定功能。
因此,來模擬整個係統的用例圖。
目的:
用例圖的目的是捕捉到一個係統的動態方麵。但這一定義過於籠統描述其目的。
因為其他的四個圖解的圖(活動,序列,協作和狀態圖)也具有同樣的目的。因此,我們將尋找到一些特定的目的,這將區彆於其他四幅圖。
用例圖是用來收集係統的要求,包括內部和外部的影響。這些要求大多是設計要求。所以,當一個係統的分析,以收集其功能用例和參與者確定。
現在,當最初的任務是完整的用例圖是仿照目前外界的視圖。
因此,簡言之,用例圖的目的如下:
-
用來收集係統的要求。
-
用於獲取係統的外觀圖。
-
識彆外部和內部因素影響係統.
-
顯示要求之間的相互作用是參與者.
如何畫用例圖?
用例圖被認為是高層次的需求分析係統。因此,當係統的要求,分析被捕獲在用例的功能。
因此,我們可以說,使用情況是什麼,但在一個有組織的方式編寫的係統功能。現在到用例相關的第二件事情是參與者。行為者可以被定義為與係統進行交互的東西。
參與者可以是人的用戶,一些內部的應用程序,或可能會有一些外部應用程序。因此,在一個簡短的,當我們正計劃繪製一個用例圖中應該有以下項目:
-
功能被表示為一個用例
-
參與者
-
用例和參與者之間的關係。
繪製到用例圖捕獲係統的功能要求。因此,確定上述項目後,我們必須遵循以下指導原則,繪製一個有效的用例圖。
-
一個用例的名稱是非常重要的。所以名的選擇應以這樣的方式,以便它可以識彆執行的功能。
-
給出一個合適的名參與者。
-
圖中清楚地顯示關係和依賴性。
-
不要試圖包括所有類型的關係。由於該圖的主要目的是確定要求。
-
使用注意以往任何時候都需要闡明一些重要的點。
下麵是一個示例用例圖,代表訂單管理係統。因此,如果我們看看圖,那麼我們會發現三個用例(訂單,特殊訂單和正常訂單)和一個參與者:顧客。
SpecialOrder 和NormalOrder 從訂單使用情況擴展。因此,他們擴展了關係。另外很重要的一點是確定係統邊界,這是圖中所示。參與者是客戶以外的係統,因為它是係統的外部用戶。
在哪裡使用用例圖?
正如我們已經討論過,有五個在UML圖建模係統的動態視圖。現在,每個模型有一些特定目的使用。其實這些特定的目的,是正在運行的係統中的不同角度。
所以要了解一個係統的動態,我們需要使用不同類型的圖表。用例圖就是其中之一,其具體目的是收集係統的的需求和參與者。
用例圖指定係統的事件和他們的流向。但從未用例圖描述了他們是如何實現的。可以被想象成一個黑盒子,隻有輸入,輸出和黑盒子的功能被稱為用例圖。
在這些圖中使用的設計在一個非常高的水平。那麼這種高層次的設計高雅,一遍又一遍完善使係統得到一個完整實用的圖片。一個結構良好的用例,還介紹了前置條件,後置條件和例外。而這些多餘的元素在執行測試時被用來製造測試的情況下。
用例都不是正向和反向工程,但他們仍然使用略有不同的方式。同樣是真實的逆向工程。仍用例圖的使用方式不同,使其逆向工程的一個候選。
在正向工程用例圖是用來做測試案例和逆向工程中的使用情況下是用來準備從現有的應用程序的需求細節。
所以下麵的地方使用用例圖:
-
需求分析和高水平的設計。
-
模擬係統的上下文。
-
逆向工程。
-
Forward engineering.