用例和功能誤區

用例是不是功能？如果不是的話，它是什么？從定義上說，能給使用者提供一個執行結果的活動，不就是功能嗎？很不幸，這個理解是錯誤的！功能是計算機術語，它是用來描述計算機的，而非定義需求的術語。功能實際描述的是輸入-> 計算->輸出。這讓你相當了什么？DFD圖？這可是典型的面向過程的分析模式。因此把用例當做功能點的做法實際上載做面向過程的分析。拋開面向對象和面向過程不說，雖然功能和用例很類似，但是本質上來說功能和用例是完全不同的。為了解釋這個問題，我們需要從描述事物的方法入手。

在描述一個事物的時候，我們可以從以下三個觀點出發：

這個事物是什么？

這個事物能做什么？

人們能夠用這個事物做什么？

使用者的觀點才是真正的用例觀點。

第一，功能是脫離使用者的愿望而存在的。我們通常說某某工具某個功能，它是描述工具的，而不是站在使用者的角度描述使用者的愿望的。功能用來描述某某東西能做什么，它與使用者的愿望無關，描述事物固有的性質。用例是描述使用者的愿望的，描述的是使用者對系統的使用要求，用用例來看待系統的團隊，則是從使用者的校對出發，說明使用者將在系統里面做什么。

第二，功能是孤立的，給一個輸入，通過計算就有一個固定的輸出。用例是系統性的，它描述誰在什么情況下通過什么方式結果是什么。功能描述一個個點，如果要達成一個特定的目標，必須在額外交上一個順序的過程，把點串起來才能完成一個系統性的工作。而用例描述一個系統性的工作，這個系統性的工作往往非常明確地去達成一個特定的目標。

第三，如果非要從功能角度解釋用例，那么用例刻意解釋為一系列完成一個特定目標的“功能”的組合，針對不同的應用場景，這些“功能”體現出不同的組合形式。并且，不是先有了這些“功能”才來組合成某個場景，而是先有了場景，才分解出“功能”，這時的功能之所以打引號是應為在UML里面沒有功能這個詞的，實際上場景分解出來就是對象，這些對象通過消息相互交流而完成場景。

目標和步驟誤區

一個用例是參與者對目標系統的一個愿望，一個完整的事件。為了完成這個時間需要經過很多步驟，但是這些步驟不能夠完整地反映參與者的目標，不能夠作為用例。

這就是用例的完整性。

用例粒度誤區

產生用例粒度錯誤的原因首先是分不清楚目標和步驟。分不清目標和步驟的另一個后果是用例的粒度過于細小。

產生這個錯誤的主要是建模者心中沒有一個清楚的邊界，我們知道用例決定參與者的完整期望，而參與者與邊界是相生相滅的，所以一旦邊界不確定，參與者就會混亂，進而導致用例粒度不一。

粒度大小如何決定，在同一個需求階段，必須保持所有用例的粒度在同一量級！

轉載于:https://www.cnblogs.com/HeroBeast/archive/2010/09/06/1819270.html

總結

以上是生活随笔為你收集整理的UML之误区的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。