《利用EnterpriseArchitect畫用例圖心得》由會員分享,可在線閱讀,更多相關《利用EnterpriseArchitect畫用例圖心得(8頁珍藏版)》請在裝配圖網上搜索。
1、利用Enterprise Architect畫用例圖
在畫用例圖的時候,理清用例之間的關系是重點。用例的關系有泛化(generalization)、擴展(extend)和包含(include)。其中include和extend最易混淆。下面我們結合實例徹底理清三者的關系。
1. 基本概念
用例圖(Use Case Diagram):用例圖顯示誰是相關的用戶,用戶希望系統(tǒng)提供什么服務(用例),以及用例之間的關系圖。用例圖主要的作用是獲取需求、指導測試。
用例圖的4個基本組件:參與者(Actor)、用例(Use Case)、關系(Relationship)和系統(tǒng)。
泛化(gen
2、eralization):泛化關系是一種繼承關系,子用例將繼承基用例的所有行為,關系和通信關系,也就是說在任何使用基用例的地方都可以用子用例來代替。泛化關系在用例圖中使用空心的箭頭表示,箭頭方向從子用例指向基用例。
擴展(extend): extend關系是對基用例的擴展,基用例是一個完整的用例,即使沒有子用例的參與,也可以完成一個完整的功能。extend的基用例中將存在一個擴展點,只有當擴展點被激活時,子用例才會被執(zhí)行。 extend關系在用例圖中使用帶箭頭的虛線表示(在線上標注<>),箭頭從子用例指向基用例。
包含(include): include為包含關系,當兩個
3、或多個用例中共用一組相同的動作,這時可以將這組相同的動作抽出來作為一個獨立的子用例,供多個基用例所共享。因為子用例被抽出,基用例并非一個完整的用例,所以include關系中的基用例必須和子用例一起使用才夠完整,子用例也必然被執(zhí)行。include關系在用例圖中使用帶箭頭的虛線表示(在線上標注<>),箭頭從基用例指向子用例。
2. 用例模型
用例模型用來記錄系統(tǒng)的需求,它提供系統(tǒng)與用戶及其他參與者的一種通信手段。
2.1 執(zhí)行者
用例圖顯示了系統(tǒng)和系統(tǒng)外實體之間的交互。這些實體被引用為執(zhí)行者。執(zhí)行者代表角色,可以包括:用戶,外部硬件和其他系統(tǒng)。執(zhí)行者往往被畫成簡筆畫小人
4、。也可以用帶?actor?關鍵字的類矩形表示。
在下圖中,執(zhí)行者可以詳細的泛化其他執(zhí)行者:
2.2 用例
用例是有意義的單獨工作單元。它向系統(tǒng)外部的人或事提供一個易于觀察的高層次行為視圖。 用例的標注符號是一個橢圓。
使用用例的符號是帶可選擇箭頭的連接線,箭頭顯示控制的方向。下圖說明執(zhí)行者 "Customer"使用 "Withdraw"用例。
用途連接器(uses connector)可以有選擇性的在每一個端點有多重性值,如下圖,顯示客戶一次可能只執(zhí)行一次取款交易。但是銀行可以同時執(zhí)行許多取款交易。
2.3 用例定義
一個典型的用例包括:
l 名稱和描述
5、
l 需求
l 約束
l 情形
l 情形圖
l 附加信息。
名稱和描述
用例通常用一個動詞詞組定義,而且有一個簡短的文字說明。
需求
需求定義了一個用例必須提供給終端用戶的正式功能性需求。它們符合構造方法建立的功能性規(guī)范。一個需求是用例將執(zhí)行一個動作或提供多個值給系統(tǒng)的約定或承諾。
約束
一個約束是一個用例運行的條件或限制。它包括:前置條件,后置條件和不變化條件 。前置條件指明了用例在發(fā)生之前需要符合的條件。后置條件用來說明在用例執(zhí)行之后一些條件必須為"真"。不變化條件說明用例整個執(zhí)行過程中該條件始終為"真"。
情形
情形是用例的實例在執(zhí)行過程中,事件發(fā)生流程的形式描述
6、。它定義了系統(tǒng)和外部執(zhí)行者之間的事件指定順序。 通常用文本方式來表示,并對應順序圖中的文字描述。
包含用例
用例可能包含其他用例的功能來作為它正常處理的一部分。通常它假設,任何被包含的用例在基本程序運行時每一次都會被調用。下面例子:用例“卡的確認” 在運行時,被用例“取錢”當作一個子部分。
用例可以被一個或多個用例包含。通過提煉通用的行為,將它變成可以多次重復使用的用例。有助于降低功能重復級別。
擴展用例
一個用例可以被用來擴展另一個用例的行為,通常使用在特別情況下。例如:假設在修改一個特別類型的客戶訂單之前,用戶必須
7、得到某種更高級別的許可,然后“獲得許可”用例將有選擇的擴展常規(guī)的“修改訂單”用例。
擴展點
擴展用例的加入點被定義為擴展點。
系統(tǒng)邊界
它用來顯示用例在系統(tǒng)內部,執(zhí)行者在系統(tǒng)的外部。
3. 實例需求場景
聯通客戶響應OSS。系統(tǒng)有故障單、業(yè)務開通、資源核查、割接、業(yè)務重保、網絡品質性能等功能模塊?,F在我們抽出部分需求做為例子講解。
需求1:客戶響應用戶和國際客服可以進行割接通知查詢,在頁面上有骨干割接查詢、省間割接查詢、省級割接查詢的Tab。
分析:可以很容易看出割接查詢和不同的割接子查詢Tab之間是繼承的
8、關系,所以此處用泛化。用戶和客戶響應、國際客服也是繼承的Actor關系。
需求2:客戶響應用戶和國際客服可以查看某條割接通知信息,可以在頁面上導出割接信息Excel格式,可以查詢和該條割接相關聯的故障單信息。
分析:因為導出割接和查看相關聯的故障單信息都是可選的,就是說我查看割接的時候,也可以不進行這些操作,所以這里用extend關系。也就是導出割接和查看故障單信息擴展了查看割接信息。
需求3:客戶響應用戶可以以網管系統(tǒng)為來源創(chuàng)建割接通知,在創(chuàng)建割接通知時可以保存為草稿,也可以直接發(fā)布割接通知。
分析:由于創(chuàng)建割接通知時,發(fā)布割接通知可以同時進行,也可以先存為草稿,所以發(fā)布割接是
9、可選的,用extend就比較合適。也就是發(fā)布割接擴展了創(chuàng)建割接通知。
需求4:用戶在進行業(yè)務開通、發(fā)布割接通知、發(fā)布重保通知及相關跨省的業(yè)務時需要進行數據分發(fā)。
分析:由于業(yè)務開通、重保、割接及其它跨省的業(yè)務都需要用到數據分發(fā)用例,我們可以將數據分發(fā)用例單獨抽出來,供各業(yè)務使用,這里用include就比較合適。實際的系統(tǒng)中數據分發(fā)也是單獨抽出來用jms和webservice實現的接口服務。 其它需求:可以看到刪除割接通知和查看割接明細也可以做為割接通知查詢用例的擴展,因查詢列表時,一般可以選擇繼續(xù)查看明細或者刪除操作。但在實際化圖中,這兩個extend可以不畫,這里只是為了讓大家理解概念。
用例圖:大家可以參照著圖,好好理解。
4. 加深理解
我們再用另外一個場景的用例說明一下include和extend,因為就這兩個玩意比較容易搞混。
銷戶:因為銷戶必需先進行賬戶結算,所以這里用include
停機提醒:有兩個可選項,短信提醒和郵件提醒,所以用extend.
5. 總結
經過以上的分析,相信大家對三種關系已經有比較好的理解了。大家有什么其它想法或好的見解,歡迎拍磚。
PS:以上用例圖用Enterprise Architect 7.5所畫,在此推薦一下EA,非常不錯。