【用VS2010動手學UML第11回】7條建構UML用例圖的最佳實務

其實，在開發系統時，不一定要先建構企業流程模式，也是可以直接動手繪製用例圖，直到覺得有需要透過活動圖來展現整條企業流程時，才回過頭來繪製企業流程圖，然後再同步修訂此處的系統用例圖。

價值
除了傳統的需求文件外，UML2的十四款圖中，最容易訓練使用者投入開發工作的，大概只有活動圖和用例圖了。而現今許多專案中，或許沒有大量使用物件導向的技術，但卻不約而同都採用了用例技術來具象化並追蹤需求，用例圖大概是UML圖中最普及的一款圖了吧！

此處，我們就馬上來看看，用例技術可以為我們帶來哪些價值，條列如下：

● 可以具體確認使用者：使用者不再是一個個模糊、未知的想像，而是可以具體確認的人們或系統。因此，系統的服務或功能可以更貼近使用者，系統的介面設計也可以更有彈性。

● 運用使用者熟悉的詞彙：方便使用者參與開發過程，如此不僅讓使用者願意買單，更讓開發團隊得以吸取使用者的領域知識。

● 聚焦關係人各種不同的觀點與需求：用例不僅可以讓使用者參與開發，更可以聚焦其他不同的重要關係人，即便各自有著不同的觀點和需求，卻可以全以一個個的用例做為討論、溝通和努力的目標。

● 讓專案工時估算更準確：以一個個的用例做為估算工時的工作範圍，工作範圍具體明確，所以大大改善了過往工時估算不容易且不準確的困境。

● 具象化需求方便管理：透過用例圖示具象化需求片段，方便進行需求管理，還可以加入顏色管理的概念，讓需求管理更豐富且有趣。

● 切割需求成為可以派工的單元：用例不僅包含了需求片段，更可以因此而形成一個可以派工的單元，讓需求從使用者端到開發人員端，一氣呵成，管理與追蹤的品質都會提升。

● 點出專案開發的具體目標：想像一下，在夜市的射氣球攤上，一次瞄準一顆氣球，專心射出手中的飛鏢。用例就像氣球一般，一個個具體又明確，剛好可以當成團隊成員的具體目標。

● 做為其他工作的基礎：用例包含了具體明確的流程說明，可以做為後續系統設計、測試案例、編碼實作、專案計畫等等工作的基礎。

最佳實務
特別注意，這邊條列的是建構用例圖的最佳實務，而不是撰寫用例敘述的最佳實務，如下：

1. 用初估工時來決定用例的顆粒度：一個用例到底應該多大的範圍比較適當？答案有很多種，也有很多方法來判讀用例的顆粒度是否適度。以專案管理的角度來看，可以用估算工時的方式來決定用例的顆粒度，讓每一個用例的工時維持在一個便於管理的範圍。工時過低，可能用例太小，可以合併；工時過高，可能用例太大，可以切割。用工時來秤一秤，這也是一種決定用例大小的實用法。

2. 使用具體明確且動詞開頭的用例名稱：也就是說，用例名稱最好具備有：具體、明確、動詞開頭，這三個特質。具體且明確，可以讓觀看者立即知道這個用例的用途和重要性，同時也便於估算工時。動詞開頭是因為，用例是參與者與系統的互動過程，應該是含有時間、流程、步驟之類的動態感在裡頭，所以使用動詞開頭比較能夠呈現動態感。

3. 少用用例之間的包含和擴充關係：就連用例之間的一般化關係也一樣，能不用，就盡量別用。一方面是，用了這些關係，還得跟使用者解釋，所以會阻礙使用者的投入；另一方面是，這些關係線跟切割用例有關，我擔心開發人員過度運用，把原先完整的用例切的七零八落。

4. 用例圖不宜用來呈現流程的串接情況：過度使用用例之間的包含關係或擴充關係的用例圖，也可能是誤用用例和關係線來表達流程。記得，如果要表達流程中的一連串步驟和流程控制，活動圖遠比用例圖適合多了。
5. 架構攸關的用例比企業攸關的用例重要：在判讀用例的重要性時，有兩個重要的角度：其一是以系統架構的角度來判斷，另外是以企業運作的角度來判斷。或許，支援關鍵的企業流程的用例很重要，但是別忘了，系統架構若是垮了，就什麼好處都沒了，所以攸關架構的用例遠比攸關企業的用例重要。

6. 在間接使用者與系統之間找出直接使用者：我們重視的是直接使用系統的使用者，有時他們不見得是原始的資料提供者，或者是真正對系統有期望的人。但是，我們真正想找的參與者，是直接使用系統的人類使用者、硬體設備、其他系統或服務。為什麼？因為「介面」（Interface），從具體明確的參與者身上，我們可以訂出最佳的使用介面。因此，如果參與者是個間接使用者，試著找找看，這個參與者跟系統之間，應該有一個真正的使用者或系統設備，被我們忽略了。

7. 從分析活動圖下手找用例：從何處尋找參與者和用例，也是有許多方法。如果，你一種方法都不知道，而且恰好還繪製了活動圖，那不妨把活動圖做為一項重要的資料來源，開始動手從中找出系統用例吧！從活動圖找用例
此處，我們就來示範如何從上一章得出的活動圖來找用例。怎麼開始呢？簡單，針對活動圖中的每一個動作，做如下述的判斷或分析：

1. 系統可以提供什麼樣的功能或服務來協助處理這個動作嗎？

1.1 看看這個動作的大小和名稱是否合適，可以直接拿來當作用例的名稱。

2. 原本這個動作是哪個人員負責的？日後他會變成直接使用系統的使用者嗎？

2.1 以這個人員的角色來做為參與者的名稱。

2.2 如果這個人員不是系統上線後的直接使用者，找出直接使用系統的人員。直接使用系統的人員，才是真正的參與者。

3. 原本這個動作會涉及到哪些外部資料庫、硬體設備、其他系統、或外部服務嗎？

3.1 如果有，這些屬於非人類參與者。

4. 檢查一下我們找到的每一個用例：

4.1 用例名稱是否具體、明確、動詞開頭。

4.2 看到用例的名稱，就可以猜想到它提供的服務或產出。

4.3 看到這個用例的名稱，心中就有一個底，大約可以初步估算出所需的工時。

經過上述問題的分析之後，我們從圖1的活動圖轉出了圖2的初步系統用例圖。

圖1 活動圖-報名課程[示意圖]

圖2 初步系統用例圖

接著，我們針對圖2的初步系統用例圖，查看每一個參與者和用例，做了一些用例名稱上的調整，以及查看參與者是否有直接使用系統，最後進一步得到圖3的系統用例圖。

圖3 系統用例圖[修改]

最後，我們針對用例敘述格式，如表1所示，撰寫出用例敘述。不過，用例敘述非介紹重點，所以僅簡單寫出「填寫課程報名表」與「通知已付訂」這兩個用例的主要流程。同時，利用Word繪製出簡單的畫面雛型，提高用例敘述的溝通品質，如表2、表3所示。