怎樣計算事務(wù)

既然您已經(jīng)看到了決定什么是以及什么不是用例事務(wù)的清晰解釋，讓我們檢查在用例中計算事務(wù)的一些挑戰(zhàn)。如上面所述，用例的權(quán)重是由它所包含的用例事務(wù)的數(shù)量所決定的，但是，什么時候系統(tǒng)對刺激源的反應(yīng)會計算成不同的？

使用用例事務(wù)與流程

讓我們通過檢查上面介紹過的工作入口的搜索流程開始。如果用戶在尋找一個“Java”類型的工作，他選擇了 Java，然后系統(tǒng)會在數(shù)據(jù)庫中搜索這種類型的所有工作。當(dāng)用戶尋找一個“.Net”類型的工作，它選擇了 .Net。然后系統(tǒng)會搜索數(shù)據(jù)庫來找到該類型的所有工作。這兩種是不是不同的事務(wù)？當(dāng)然不是。用例配置本身是抽象的或者通用的，在這個意義上您不要對不同的搜索項期待不同的流程。這只不過是安裝過程中的一點不同。但是，您可以對一個使用預(yù)定義類型或者自由格式文本的搜索期待不同的流程。

另一方面，處理例外是一個灰色的區(qū)域。假設(shè)您有了帶有七個區(qū)域的輸入屏幕，它們中的所有都有不同的限制。您有一個日期區(qū)域，一個郵政編碼，一個輸入?yún)^(qū)域，以及等等。每一個檢查可能會在單獨的流程中得到描述，因此被計算成可能不止一個事務(wù)。您可以選擇的是，提供一個通用的流程。它預(yù)假設(shè)有一個可以容易處理的例外種類的框架。在這種情況下，您應(yīng)該將該流程計算成一個事務(wù)。

使用當(dāng)作環(huán)形路線的用例事務(wù)，可以在用例中隨處可見。因為一個用例配置至少有一個基本流程，它也至少應(yīng)該有一個事務(wù)。沒有事務(wù)的流程是沒有意義的，因為系統(tǒng)在沒有刺激源時什么都不會做，用戶在沒有弄清系統(tǒng)的反應(yīng)之前也不會提供任何刺激源。

幾乎一直都會有描述處理例外的流程（因此，“例外的流程”）。每一個例外流程都至少含有一個事務(wù)。這點也適用于一個可選擇的流程；對于每一個可選擇的流程都應(yīng)該有至少一個流程。很可能您需要查看基本流程，以查看可選擇流程中事務(wù)的刺激源；這取決于處理用例的特定指定原則。

它給了您一個任何用例配置中用例事務(wù)小數(shù)量的指示：流程中至少應(yīng)該有以下數(shù)量的事務(wù)。 8

顯示和計算

如果您擁有識別用例事務(wù)的能力，您是否需要對它們平等的重視？我們的策略是顯示它們中的，每一個與事務(wù)（如果可以應(yīng)用的話），但是有些時候并不計算它們的權(quán)重。我們的策略要比直接忽略它們更加直接。如果需要的話，調(diào)整原始的估算也十分的容易。

通過這種方式，您能夠看出框架的價值。如果用例計算十個事務(wù)的話，但是它們中只有三個值得處理，另外三個遵循框架，該用例是普通的而不是復(fù)雜的。表 1 中顯示了一個例子。

表 1 ：不同假設(shè)性用例計算的事務(wù)

許多系統(tǒng)步驟可以是一個新的用例

是不是沒有辦法解釋一個用例業(yè)務(wù)暗含的系統(tǒng)步驟與只有一步系統(tǒng)步驟之間的差異？您的直覺告訴您構(gòu)建 6 個系統(tǒng)步驟要比構(gòu)建 1 個需要更大的努力。實際上，我們完全贊成。但是，您不應(yīng)該試著通過計算系統(tǒng)步驟，而應(yīng)該通過隔離另外系統(tǒng)步驟涉及到的功能性，來解決這些小問題。如果您擁有大量的功能性，那么可能它是用例本身。注意不要將任何堆積的功能發(fā)展成“用例”的狀態(tài)。這將會是功能性降級。但是應(yīng)用如下的規(guī)則：后續(xù)的用例必須擁有一個清晰的目標(biāo)，這符合至少一個投資者的利益（并不一定與用戶相似）。 9

一個范例可以是用例“產(chǎn)生年平均”。在這個用例的過程中，會生成一些報告，代表一個特定投資者的利益。生成每一個報告的過程中，會涉及到一些系統(tǒng)步驟。為每一個報告定義單獨的用例，能夠幫助您找到合適的投資者，而不用打擾其他的投資者。通過這種方式，我們能夠提供更加保險的估算了。

批任務(wù)

如果用例使用在缺乏用戶交流的情況之下（在這方面我們有較好的經(jīng)驗），那么您怎樣將業(yè)務(wù)的概念轉(zhuǎn)化成一個環(huán)形路線。坦白來說，在這里它并不適用。您需要其他的方式來估算這種用例的權(quán)重。而且，這是由專家估算來完成的。表 2 顯示了它們是怎樣在擴(kuò)展卡中顯示的。

表 2：業(yè)務(wù)與添加的批任務(wù)同時計算

 如果批任務(wù)要比一個復(fù)雜的用例還要大，那么它應(yīng)該還有不止一個目標(biāo)，因此該工作可以分解成更多的用例，每一個用例都能夠服務(wù)于至少一個投資者的利益。這種機(jī)理能夠適用于任何用例，這些用例要比實際上還要復(fù)雜許多（見于表 2）。如果您不能找到一個好的原因，去分解一個批任務(wù)，您可以轉(zhuǎn)化成圖 1 中提到的“補(bǔ)充性效果”類型。

非常復(fù)雜的用例

一些作家看到了用例點方法中的困難之處，因為在 8 個業(yè)務(wù)的復(fù)雜用例與 16 個業(yè)務(wù)之間，沒有什么不同之處。在我們的經(jīng)驗中，由超過 12 個業(yè)務(wù)組成的用例，能夠滿足不止一個目標(biāo)。所以，它們是問題性用例模型的標(biāo)志。換句話說，如果您擁有超過 12 個業(yè)務(wù)的用例，那么考慮一個新的用例是值得的。 10

在項目的早期階段計算用例業(yè)務(wù)

在寫下所有的用例配置后，計算業(yè)務(wù)變得簡單起來。另一方面，估算是在項目的早期進(jìn)行預(yù)測的。在這里，您只有用例模型，以及每一個用例的簡單介紹。為了展望組成用例的流程，以及涉及到的用例事務(wù)，您需要經(jīng)驗的幫助。如果您沒有這個經(jīng)驗，不要猶豫去咨詢擁有類似系統(tǒng)和背景工作經(jīng)驗的同事。通過創(chuàng)建如表 2 所示 的擴(kuò)展單來開始，并填入展望的事務(wù)。這將會形成管理用例范圍的基礎(chǔ)，您能解釋哪些用例需要比用戶預(yù)料的那樣更多的事務(wù)。