(中職)UML與Rose建模應用子情境4.2課件
子情景4.2 用例分析,情境4:Web系統(tǒng)建模在線銷售系統(tǒng),*,(中職)UML與Rose建模應用子情境4.2ppt課件,學習情境4:Web軟件建模,在線銷售系統(tǒng),UML及Rose建模應用,子情境4.2 用例分析,根據(jù)子項目4.1的需求分析報告,確定“在線銷售系統(tǒng)”的參與者(如普通客戶、管理員及內部員工)、用例(如注冊會員、登錄系統(tǒng)、瀏覽商品、檢索商品、查看訂單、查看購物車、指定配送地址、指定支付方式等)、參與者與用例之間的關系,最后設計出“在線銷售系統(tǒng)”的整體系統(tǒng)用例圖。,子情景描述,相關知識,1用例規(guī)約,用例圖只是在總體上大致描述了系統(tǒng)所提供的各種服務,讓用戶對系統(tǒng)有一個總體的認識。但對于每個用例還需要有詳細的描述信息,以便讓其他人對于整個系統(tǒng)有一個更加詳細地了解,這些信息包含在用例規(guī)約之中。而用例模型指的也不僅僅是用例圖,而是由用例圖和每一個用例的詳細描述用例規(guī)約所組成的。,2泛化,用例的泛化指的是一個父用例可以被特化形成多個子用例,而父用例和子用例之間的關系就是泛化關系。在用例的泛化關系中,子用例繼承了父用例所有的結構、行為和關系,子用例是父用例的一種特殊形式。此外,子用例還可以添加、覆蓋、改變繼承的行為。,相關知識,在UML中,用例的泛化關系通過一個從子用例指向父用例的三角箭頭來表示,如圖4-15所示。,當發(fā)現(xiàn)系統(tǒng)中有兩個或者多個用例在行為、結構和目的方面存在共性時,就可以使用泛化關系。這時可以用一個新的(通常也是抽象的)用例來描述這些共有部分,這個新的用例就是父用例。如圖4-16所示為飛機訂票系統(tǒng)的用例圖,預定飛機票有兩種方式,一種是通過電話預定,另一種是通過網上預定。在這里,電話訂票和網上訂票都是訂票的一種特殊方式,因此“訂票”為父用例,“電話訂票”和“網上訂票”為子用例。,圖4-15 泛化關系,相關知識,當發(fā)現(xiàn)系統(tǒng)中有兩個或者多個用例在行為、結構和目的方面存在共性時,就可以使用泛化關系。這時可以用一個新的(通常也是抽象的)用例來描述這些共有部分,這個新的用例就是父用例。如圖4-16所示為飛機訂票系統(tǒng)的用例圖,預定飛機票有兩種方式,一種是通過電話預定,另一種是通過網上預定。在這里,電話訂票和網上訂票都是訂票的一種特殊方式,因此“訂票”為父用例,“電話訂票”和“網上訂票”為子用例。,圖4-16 泛化關系示例,相關知識,在用例的包含關系中,基礎用例在目的上可以完全不同,但是它們都有一段相似的行為,它們的相似是部分的相似不是整體的相似。用例的泛化關系類似于面向對象中的繼承,它把多個子用例中的共性抽象成一個父用例,子用例在繼承父用例的基礎上可以進行修改。但是子用例和子用例之間又是相互獨立的,任何一個子用例的執(zhí)行不受其他子用例的影響。而用例的包含關系是把多個基礎用例中的共性抽象為一個被包含用例,可以說被包含用例就是基礎用例中的一部分,基礎用例的執(zhí)行必然引起被包含用例的執(zhí)行。,該系統(tǒng)有三類用戶,一類是普通客戶,一類是管理員,一類是內部員工。,參與者的識別,步驟1,注冊會員 修改注冊資料 管理員退出系統(tǒng),用戶登錄系統(tǒng) 用戶退出系統(tǒng)管理業(yè)務數(shù)據(jù),瀏覽商品 檢索商品管理系統(tǒng)權限,瀏覽商品詳細信息 查看訂單,商品放入購物車 查看購物車,管理業(yè)務數(shù)據(jù) 準備結賬,指定配送地址 指定支付方式,完成訂單 管理員登錄系統(tǒng),用例識別,步驟2,子情景實施,【提示】在瀏覽窗口中右鍵單擊“Use Case View”(用例視圖),在彈出的菜單上選擇菜單項“New”(新建)下的“Use Case Diagram”(用例圖)命令,從鍵盤輸入文本“銷售系統(tǒng)用例”命名該用例圖,雙擊“銷售系統(tǒng)用例”打開用例圖窗口。,在工具箱中單擊“Actor”(參與者)圖標,將光標移動到用例圖窗口適當位置,單擊鼠標左鍵,就會出現(xiàn)名為“NewClass”參與者,重命名為“客戶”,如圖4-17所示。采取此方法,依次創(chuàng)建參與者“管理員”、“內部員工”,如圖4-20所示。,新建參與者,步驟3,圖4-17 新建參與者示例,子情景實施,在工具箱中選擇“Use Case”(用例)工具圖標,將光標移動到窗口適當位置,單擊鼠標左鍵,就會出現(xiàn)名為“NewUseCase”用例,輸入文本“注冊”進行重命名,按相同的方法依次新建如圖4-18所示的其它用例。,提取用例,步驟4,圖4-18 新建用例示例,子情景實施,在工具箱中選擇“Association”(雙向導向關聯(lián))圖標,將光標指向參與者“客戶機”,按住鼠標左鍵,拖動至用例“注冊”,松開鼠標,在兩者之間就會出現(xiàn)一條“線段”,創(chuàng)建兩者間的關聯(lián)完成,如圖4-19所示。,新建參與者與用例間的雙向關聯(lián),步驟5,圖4-19 新建關聯(lián)示例,子情景實施,參照步驟5,創(chuàng)建參與者與用例間的關聯(lián),如圖4-20所示。,創(chuàng)建在線銷售用例圖,步驟6,圖4-20 在線銷售用例圖,子情景實施,知識或技能拓展,用例的粒度,用例的粒度指的是用例所包含的系統(tǒng)服務或功能單元的多少。用例的粒度越大,用例包含的功能越多,反之則包含的功能越少。,在用例建模時,很多人都會對自己系統(tǒng)所需要的用例個數(shù)產生疑惑。對同一個系統(tǒng)的描述,不同的人可能會產生不同的用例模型。如果用例的粒度很小,得到的用例數(shù)就會太多。反之,如果用例的粒度很大,那么得到的用例數(shù)就會很少。如果用例數(shù)目過多會造成用例模型過大和引入設計困難大大提高;如果用例數(shù)目過少會造成用例的粒度太大,不便于進一步的充分分析。,知識或技能拓展,如下圖4-21所示為在線銷售系統(tǒng)的維護商品信息用例,管理員需要進行商品價格的調整、商品描述信息的更新、新商品的加入以及過期商品的刪除等操作。,圖4-21 商品信息維護子系統(tǒng),知識或技能拓展,還可以根據(jù)具體的操作把它抽象成四個用例,如圖4-22所示,它展示的系統(tǒng)需求和單個用例是完全一樣的。,圖4-22 細化后的商品信息維護子系統(tǒng),知識或技能拓展,當大致確定用例個數(shù)后,就可以很容易的確定用例粒度的大小。對于比較簡單的系統(tǒng),因為系統(tǒng)的復雜度一般比較低,所以可以適當加大用例模型一級的復雜度,也就是可以將較復雜的用例分解成多個用例。對于比較復雜的系統(tǒng),因為系統(tǒng)的復雜度已經很高,需要加強控制用例模型一級的復雜度,即將復雜度適當?shù)匾酝美齼炔?,讓一個用例包含較多的需求信息量。,用例的粒度對于用例模型來說是很重要的,它不但決定了用例模型級的復雜度,而且也決定了每一個用例內部的復雜度。在確定用例粒度時應該根據(jù)每個系統(tǒng)的具體情況,具體問題具體分析,在盡可能保證整個用例模型的易理解性的前提下決定用例的大小和數(shù)目。,Thank You!,