這里是Use Cases的圖形符號描述,UML中一個單一的“Stick-Man”符號標示行為者(Actor),用橢圓標示Use Cases,如圖一所示。這些圖對于你想看到Use Cases之間如何關聯的“大圖”和獲得系統上下文的大體描述來說是非常重要的。
Use Cases圖沒有顯示不同的情節,它們的意圖是顯示行為者和Use Cases之間的關系。所以Use Cases圖需求用結構化敘述文本來補充。UML提供一些可供選擇的圖來顯示不同的情節,這些常規的圖形有交互圖、活動圖、順序圖、狀態圖等。使用這些圖的主要缺點是它們不象文本一樣是緊密的,但它們能用于給出Use Case的整體感覺。對于這些圖的協定的參考請見《UML Distilled》,作者Martin Fowler。
需求重用取得
按行為者:目標(Actor:Goal)的格式來描述Use Case的作用是它容許公共的功能性分解出來做為獨立的Use Case。當執行公共部分的時候是指用于主要Use Case的。比如:Use Case下定單中的“確定客戶”這一步驟可以用于其他Use Cases。
Use Cases之間的另一關系是“延伸部分”,如果Use Case有一個失敗恢復的步驟是復雜的,通常有三、四步,說是一個Use Case去擴展另一個Use Case。比如:當沒有可用庫存時,“Issue Raincheck”可能擴展Use Case“下定單”。
Use Cases應用當中的復雜性和危險
主要行為者(Actor)和Use Case之間沒有連結
一些情況下,從Use Case中取值的行為者(Actor)和積極參與這個Use Case的行為者(Actor)之間沒有清晰的連結。如:財務主管能成為“發票確認”的行為者(Actor),但他未必是創建發票的人。這不是什么問題,這個Use Case仍然是正確的,它正說明行為者取值和設計的系統的范圍外的Use Case發生的初始化之間的關系。主要行為者是有用的,因為這個人扮演的角色是當你說明Use Case時需要跟他說的人。
情節步驟不需要連續
情節中步驟順序的情況是沒問題的,這里有一些機制去突出可能的并行步驟。在UML中活動圖是首選的機制,通過非正式地看Use Case的情節你可以注意到可能的平行步驟;可以看Use Case內一些鄰近的步驟;也可以有相同的行為者(Actor)對步驟負責。之前我們舉過的例子里,確認數量和確認信用額可能是平行的。有時候在Use Case的說明文檔中標記這些可能的平行步驟是有用的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/