為什么用例不是“功能”?[1]

　　為什么用例不是“功能”?[1]     功能測試工具　

  　多數人從用例開始就走入了迷途，也許是用例圖和數據流圖的相似性導致人們把用例定義為簡單的功能或者菜單項。不論原因是什么，這都是新手最容易犯的錯誤。

　　圖 1 錯誤的方式：用例是菜單項或者功能

　　這幅圖有什么錯誤?用最簡單的定義，我傾向于把用例看作是關于使用系統作某些有用的事情的方式的故事。利用這個定義，是不是所有的“用例”都是獨立的有用的呢?

　　答案當然是不是，在這個例子中，用例表示了系統需要做的所有的事情，但是他們也描述了用戶需要通過系統去做的一件單獨的事情：定購。所有保留的元素都是這一個用例的備選支流，它們是在定購時可能發生的步驟。在只做一件有用的事情的地方，只應該有一個用例。圖1就是一個功能分解的例子，或者“四輪馬車”格式的例子――一個參與者在中間，周圍是一圈用例。

　　這是一個常見的問題，為什么人們會陷入這個陷阱呢?我們有一個有對定購的內在需要，并且在不存在的地方如果我們需要那么就利用它。在功能分解的情況下，我們有一種自然傾向把問題分解為越來越小的塊。有一種天真的想法那就是把用例分解為越來越小的單位會簡化問題。這種理解是完全錯誤的。當我們分解用例時，實際上會把問題復雜化。

　　問題在這里

　　用例的目的是描述某人某物如何使用系統來完成對他們有價值的事情，它描述了系統在概念層次上做什么，使我們足夠理解系統以便決定系統是否要做恰當的事。用例是我們能夠形成一個系統的概念模型。 軟件測試

　　再看看圖1，現在問你自己，如果我從來沒有定購過，我想通過系統查詢定單的狀態嗎?這是不太可能的?；蛘呷绻覐膩頉]有定購過，我想變更訂單嗎?不，也許不。通常這些東西只有當我訂購過的時候才對我有用。然而，為了系統能夠允許我訂購，這些都是必要的。

　　把系統分解為越來越小的用例模糊了系統的真實目的，極端情況下，我們將以得到一堆隔絕的行為的細致末節而告終。結果我們不能說明系統做什么。這就像看到一輛被拆解為零件的汽車，或許你會說這是輛汽車，你也知道零件們是有用的，但是你確實不能說明他們如何組裝在一起。

　　當使用用例的時候，記住用例是考慮整個系統的一種方式，并且要組織成可管理的功能塊，這些功能塊完成一些有價值的事情。為了得到正確的用例集合，問你自己一個問題：“參與者實際上想使用系統做什么?”

原文轉自：http://www.anti-gravitydesign.com