用力和功能的誤區(qū)

1、在實際應用中，用例是非常容易被誤解和誤用的。尤其是習慣了面向過程結構化設計方法的計算機技術人員，最普遍的理解錯誤時認為用例就是功能的劃分和描述。他們認為一個用例就是一個功能點。在這種理解下，用例建模變成了僅僅是較早前需求分析方法功能摳圖翻版。很多人用用例來劃分子系統(tǒng)、功能模塊和功能點。如果這樣，用例根本沒有存在的必要，有功能框圖就行了。請?zhí)貏e注意：雖然在用例是捕獲功能性需求的，但是有一個前提條件，即這個功能性需求是從參與者的角度出發(fā)的，

2、用例并不是功能。如果用例不是功能的話，它是什么呢？從定義上說，能給使用者提供一個執(zhí)行結果的活動，不就是功能嗎？很不幸，這個理解是錯誤的！功能是計算機術語，它是用來描述計算機的，而非定義需求的術語。功能實際描述的是輸入計算輸出。這讓你想到了什么？DFD圖？這可是典型的免息那個過程分析模式。因此把用例當做功能點的做法實際是在做面向過程的分析。拋開面向對象還是面向過程不說，雖然功能和用例很類似，但是從本質上來說功能和用例是完全不同的。為了解釋

3、這個問題，我們需要從描述事物的方法入手。在描述一個事物的時候，我們可以從以下三個觀點出發(fā)：1、這個事物是什么？2、這個事物能做什么？3、人們能夠用這個事物做什么？例如，描述一輛自行車的時候，我們通常這樣說明：第一，自行車是一種交通工具，它由傳動系統(tǒng)、剎車系統(tǒng)等部分組成；第二，自行車可以騎行，可以載物；第三，人們可以用雙腳蹬動踏板向前行進，可以用手捏合剎車使自行車停下來。第一種描述是一種結構性觀點，即事物的客觀存在。但是這個觀點不能夠說明

4、事物的作用，也就是功能性方面的信息。從結構上來說，同樣是一個圓環(huán)，把它用在汽車上，它可以是方向盤，把它用在自行車上，它就是輪子了。所以僅有結構性觀點是不夠的。第二種描述是一種功能性觀點，說明事物可以利用的價值。但是這個觀點不能夠說明事物在某種情況下的真實價值，也就是它缺乏上下文環(huán)境，沒有人來使用，事物的所有利用價值可能是無意義的。換句話說，沒有人使用的功能是沒有意義的。第三種描述是一種使用者觀點，說明事物對于使用者的意義，以及使用者可以

5、怎么使用它，得到什么樣的利益。這種觀點不能夠說明事物的本質結構，它只是從表面揭示了事物相對于使用者來說是什么，能做什么，可以獲得什么。對于一件我們早已熟知的事物來說，我們大可以隨便從這三個方面的觀點來描述，把事物解釋清楚，例如自行車這種天天可以看到的東西。但是如果我們要描述的事物是我們并不熟悉的呢？對于一個陌生的事物，我們不大可能先從結構的角度去解釋它，頂多可以通過觀察假定出這個事物能做什么，再進一步，如果這個事物是現(xiàn)在還不存在的呢？例

6、如正準備研制一種全新的藥品。對于一個還不存在的事物，我們既不能從結構上去解釋它，也不能夠確定到底能做什么。舉個特別的例子，Viagra本來是輝瑞公司研制生成的一種治療心絞痛的藥物，可現(xiàn)在Viagra變成了人盡皆知的偉哥。這不是因為它能治療心絞痛，而是人們都用它來治療ED，大出乎研究人員的初衷。所以對于創(chuàng)造一種還不存在的事物，最好的“功能”之所以打引號，是因為在UML里是沒有功能這個詞的，實際上從場景分解出來的對象，這些對象通過消息相互交