另一方面，處理例外是一個灰色的區(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ù)。
顯示和計算
如果您擁有識別用例事務(wù)的能力，您是否需要對它們平等的重視？我們的策略是顯示它們中的，每一個與事務(wù)（如果可以應(yīng)用的話），但是有些時候并不計算它們的權(quán)重。我們的策略要比直接忽略它們更加直接。如果需要的話，調(diào)整原始的估算也十分的容易。
通過這種方式，您就能夠看出框架的價值。如果用例計算十個事務(wù)的話，但是它們中只有三個值得處理，另外三個遵循框架，該用例是普通的而不是復(fù)雜的。
許多系統(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)，這符合至少一個投資者的利益（并不一定與用戶相似）。
一個范例可以是用例“產(chǎn)生年平均”。在這個用例的過程中，會生成一些報告，代表一個特定投資者的利益。生成每一個報告的過程中，會涉及到一些系統(tǒng)步驟。為每一個報告定義單獨的用例，能夠幫助您找到合適的投資者，而不用打擾其他的投資者。通過這種方式，我們就能夠提供更加保險的估算了。
批任務(wù)
如果用例使用在缺乏用戶交流的情況之下（在這方面我們有較好的經(jīng)驗），那么您怎樣將業(yè)務(wù)的概念轉(zhuǎn)化成一個環(huán)形路線。坦白來說，在這里它并不適用。您需要其他的方式來估算這種用例的權(quán)重。而且，這是由專家估算來完成的。表2顯示了它們是怎樣在擴展卡中顯示的。
參考文獻
[1] Jacobson,Ivar 等，Object-Oriented Software Engineering. A Use Case Driven Approach, 修訂版，Addison-Wesley 1993.
[2] Cockburn,Alistair,Writing Effective Use Cases,Addison-Wesley,2001.
[3] Ribu, Kirsten,“Estimating Object-Oriented Software Projects with Use Cases”,MSc Thesis Oslo 2001
[4]?vergaard, Gunnar 和 Karin Palmkvist,Use Cases: Patter