怎樣計算事務

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

使用用例事務與流程

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

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

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

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

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

顯示和計算

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

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

表 1 ：不同假設性用例計算的事務

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

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

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

批任務

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

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

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

非常復雜的用例

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

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

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