用例的十大缺陷
------ 汪保杰 07/10/12 于長沙
用例怎么理解呢？其原始英文是usecase，直譯過來就成了用例。這也是一個比較貼切的叫法了，從字面的直接理解就是使用的例子。另一種比較流行的定義是用例就是與使用者(actor)交互的，并且給使用者提供可觀測的有意義的結果的一系列活動的集合
用例模型怎么理解呢? 用例模型是系統既定功能及系統環境的模型，它可以作為客戶和開發人員之間的契約。用例是貫穿整個系統開發的一條主線。同一個用例模型即為需求工作流程的結果，可當作分析設計工作流程以及測試工作流程的輸入使用, 系統建模有許多種方法，每種建模方法可以滿足不同的目的。然而，用例模型最重要的作用是將系統行為傳達給客戶或最終用戶。因此，模型必須易于理解。
使用者怎么理解呢? 可能與該系統交互的用戶和任何其他系統都是使用者。由于使用者代表了系統用戶，它們協助界定系統并提供十分明確的系統用途說明(系統邊界)。編寫用例依據使用者的需求來進行。這樣就確保該系統成為用戶期望得到的系統。
用例是用來描述和挖掘用戶需求的，是用來和相關人士交流的,但有些設計人員經常犯一些錯誤，比如：
1.用例的系統邊界不明確
一個普遍的問題就是在一個用例中混合了很多邊界（比如：商業邊界，系統邊界），也就是說系統的范圍要明確。
2.用例命名問題
一個用例應該盡量描述系統要做什么以及系統使用者如何用系統的問題，用例應該描述功能以滿足用戶需求為目的，而不是描述去怎么完成功能！ 因此，用例名稱一定要明確。
3.參與者命名問題
表現在同一角色有多個參與者描述,一個很好的解決辦法就是在用例模型文檔中附加字匯表
4.用例模型中的用例太多了，看得眼花繚亂。
用例應該反映用戶的真正的需求，具體做法 (1) 合并偶然的或不重要的用例 (2) 祛除掉那些試圖描述內部處理流程的用例。 當然如果一個用例很大的話我們可以把他分開，每個用例圖只包括有限的用例（即用例分包）
5.參與者和用例之間的關系就象蜘蛛網一樣
這個問題主要表現在 (1)用例和參與者之間關系太多(2)一個參與者和每個用例都有聯系(3)一個用例和每個參與者都有聯系。這樣的問題主要在于角色的重疊，解決的最好的辦法是：角色的泛化或特化關系表示，防止蜘蛛網的產生。
6.一個用例的描述太廣
這樣的用例讓人很難理解，而一些短小明確的用例讓人一看就明白是什么意思
7.用例描述叫人迷惑
用例沒有上下文，描述不完整，因此最好在用例模型旁邊描述一下該用例模型所處的大環境，還要注意不要過多的關注內部交互，
8.用例不能很好的描述功能,
有的用例包容的活動太多，這樣的話就要進行適當的分解以使用例描述清楚，
一個用例是完整的。復雜的用例需要單獨用一個文件來描述，主要是用例的前置條件、后置條件、基本事件流、擴展事件流，和用例的優 先級等。 簡單的用例可以在用例圖中用標簽來描述。
另外，活動圖和順序圖也是詳細描述流程和功能的有利工具。隨著用例功能的不斷細化，這兩種圖會發揮更大的作用
9.客戶不理解用例
有的時候，用戶沒有參與用例的制定，而你恰恰要用他和他們討論。用戶根本就不了解，因此這需要一個培訓的過程。在和用戶交流的時候要增加用例的的故事性，有的時候我們的想法可能和用戶有偏差。因此在討論時應該認真的聽取他們的商業描述。
10.用例沒有結尾
在實際的軟件開發中用例是時刻在變的，就象需求一樣，當設計變動時用例也要跟著變。當然因為有的需求我們是不知道或者是不清楚的。
ps:
不難發現，用例是一個很好的獲取系統功能性需求的方法。但是對于非功能性需求，情況又如何呢？什么是非功能性需求，可以在何處獲得它們？
非功能性需求通常分為可用性需求、可靠性需求、性能需求以及可替換性需求。它們通常是指定需要符合任意法律法規要求的需求。它們也可以是由于所使用的操作系統、環境平臺、兼容性或所采用的任何應用標準等問題產生的設計約束。通常，任何不允許有一個以上設計選項的需求都可以認為是一個設計約束。
本博客為學習交流用，凡未注明引用的均為本人作品，轉載請注明出處，如有版權問題請及時通知。由于博客時間倉促，錯誤之處敬請諒解，有任何意見可給我留言，愿共同學習進步。