UML系統分析與設計02－使用案例圖和活動圖表（上）

    每一個產品的需求是對現實世界特定問題的一種描述，而有些問題描述可能是非常的錯綜複雜，以至在我們對其進行分析時，會覺得無從下手甚至不知所措。

    需求分析是系統設計和開發的基礎，需求分析的好壞會直接影響後繼設計和開發的品質，嚴重時會影響到系統的成敗。UML中的使用案例圖就是為了方便我們分析與交流產品需求而生，同時也為我們把產品需求轉化為系統需求提供方便。

         產品需求：一般反映的是現場的具體現象，經常是由產品工程師/銷售人員收集或由使用者直接提供，表現的較為鬆散、粗放，是一種比較切合現實的描述。

         系統需求：一般是在對產品需求進行一定的分析後，對其中不能實現或實現起來有困難的部分進行了一定的取捨，同時對一些較為籠統的需求進行明確和細化，甚至會對一些需求進行了一定的抽象和重組。有時也會結合具體應用加入了一些邏輯的描述（即現實以外的抽象術語），表現的更加切合軟體系統。一般在評審通過後，系統需求會以《產品需求規格說明說》的方式提供，並成為系統開發的範圍依據。

                  

         接下來我將介紹一下本人在用例分析過程中的一些心得和休會。

 

一、“Somebody do something”模式

         在我們對需求進行分析時，我們可以本著“Somebody do something”的模式來尋找用例/關鍵用例，當然這裡的“somebody”可以泛指人、物或其它系統等。我們可以以“做某件事”作為一個用例，而後成為系統的一項功能，即滿足一點需求。如果能DO完所有的THINGS，那麼我們的系統也就成了。

 

二、用例分析要注意事項

1、單一情境，即每一個用例只為說明一件事，我個人反對包羅永珍的“上帝”用例。

 

 

2、簡單原則，即每一個用例要通俗易懂，能非常明確、簡潔地說明其某項功能和作用，無任何歧義及多餘的想象空間。

 

 

3、唯一性，即每一件事/情境只能出現一次，如果其它地方要用到同樣的情境可以採用“引用”的方式進行組合。

 

 

三、分而治之個個擊破的思想

1、  N階的問題

 

    在對新員工面試時，我一般會問一個“漢諾塔”的問題，在這個過程中我並不看重答案，只在呼解決問題的方法。即遞迴中是如何把“N階的問題轉化成N-1階，最後成為1階的問題”的思想。

其實需求分析也是一個要把錯綜複雜的N階問題，最後轉化成1階問題的過程，這種從N至1的方法不僅在需求分析中能用上，其實在後繼的其他設計中也一樣很有用。

 

2、  自上而下或自下而上

    對需求的分析我們是可以採用自上而下或自下而上的進行分析，相信這些大家都有耳聞，在此不做詳述。就我個人而言比較喜歡“自上而下”的分析方法，即由“宏觀”到“微觀”的過程，其實有點像我們任務分解中的WBS分解方式。

對需求中描述的情境和所要解決的問題應用“單一情境”、“簡單原則”和“唯一性”逐一分解，至到合乎要求為止。

 

    拿我們的“MusicStore”項目來說吧，系統無非是“系統出售唱片”（當然這個需求有點簡單），但要滿足這個要求就得提供“管理員提供唱片”和“客戶購買唱片”等功能。以此類推“管理員提供唱片”可能會引發“管理員建立唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”等新的功能；同樣“客戶購買唱片”可能引發“客戶添加唱片到購物車”、“客戶移除購物車中的唱片”和“客戶結帳”等功能。如此反覆遞迴，我們最後會發現好像使用者要的功能我們都能提供且足“單一情境”、“簡單原則”和“唯一性”的要求。如果真是如此，那麼我們的分析過程基本也就告一段落，之所以說是告一段落，是因為一些複雜的需求只對其表象進行分析是遠遠不夠的，還得站在更高的全域的視角來進一步審視，可能還得對其進行一定的重組甚至抽象，直到滿足系統的要求，後繼我們將會有相關的例子。

 

3、  邊界和委託

    邊界，在需求定義的情境中，有一部分情境他們的工作背景和工作方式都比較類似，且彼此之間有著較為緊密的聯絡，那麼這些用例就可以組成一個相對封閉的區間，這就是用例邊界。

   有時候我們也會根據不同的actor來區分不同的邊界。

    比如：“管理員建立唱片資料”、“管理員修改唱片資料”和“管理員刪除唱片資料”就可以認為是“管理唱片資料”這樣一個邊界。

    由於VS2010並未提供Boundary功能，而是以subsystem來提供。為了更好的說明問題所以此處提供2張圖，第二張由EA繪製。

 

 

 

    有時我們會把同一個邊界內具有相對內聚性的用例抽象成一個用例。

 

 

    委拖，在進行用例分析時，當出現有些用例已超出了當前的邊界，但是與邊界內的一些用例又有較為緊密的關係時，我們往往可以考慮使有“委託”的方式來，簡化分析過程 。

    就拿“客戶結賬”用例來說吧，它可能會引發出“系統查詢帳戶餘額”、“系統轉賬”等一系列新的用例出來。此時我們可能會出現，其實我的目的就是“結帳”，至於怎麼結帳及結賬的細節並不是我在本情境的主要議題，由此可能可以確定“查詢帳戶餘額”等已超出本用例的邊界，從而我們可以“委託的方式”委派給“銀聯絡統付款”，從而一筆帶過。

 

    有時候我們可以簡單的認為“服務”就是邊界外的委託。

 

    在分析中我們可以先不關心大象是怎樣放進冰箱的，只關心大象能不能放進冰箱！

(此圖來自互連網)

 

4、  活用“Include”和“Extend”和“Generalization”

    在用例會析中，少不了對“include”、“extern”和“Generaliztion”的應用。

Include:主要是指包含這些用例，包含並不指子用例就一定會同時發生。

比如：管理管理唱片資訊 新增唱片資訊 修改唱片資訊 刪除唱片資訊 匯出唱片資訊

 

Extend：是指在滿足某一情況時一定會觸發某個用例。

“客戶結帳”在“未登入”的情況下會 觸發 “登入”用例。

由於未發現VS2010提供extension points的功能。為了更好的說明問題所以此處提供2張圖，第二張由EA繪製。

 

 

 

Generaliztion：泛化，在用例視圖中我一般只用在Actor上面使用，在實際的用例中則使用較少。

 

 

五、系統使用案例圖的“畫法”

1、  不要“網狀化”

    很多人喜歡把分析後的所有用例用一張圖來顯示，小系統還好說，系統大了就成了張蜘蛛網，淩亂的很，我個人建議盡量不要“網狀化”使用案例圖，以便不知從何看起。

 

2、  層次性表述

    以多層的方式來漸漸細化用例，由大到小、由全域到局部的層層進行細化。這種類似於根與葉子方式，在後繼的子系統分析，子模組分析也大有協助。

 

3、  內聚性

    如果說層次是是一個縱向的表現方式，那麼內聚性就是一個橫向的表現方式。它一般用來規劃一些較為完整的情境過程。比如我們的“管理唱片資料”就是一個較為內聚性的表現方式，當然內聚性的粗細粒度可結合具體的項目來定奪。

 

4、  主次有別

    在系統使用案例圖中，並不一定所有的用例都要全部列入，在說明和解決問題時，我們其實大部分用例關係只需引入主要的用例即可。如果面面俱到就會出現“網狀化”的現象，使得說明效果還適得其反。

 

5、  逐步完善

    每一個系統使用案例圖都很難一步到位的進行提供，很多時候都是一個逐步完善的過程，在我參與的一些項目中有一些都是經過了幾輪的迭代之後才基本穩定。