用例事務是一個“環(huán)形的路線”

Ivar Jacobson，用例的發(fā)明者，將用例事務描述成從用戶到系統(tǒng)，再到用戶的“環(huán)形路線”；在系統(tǒng)等待一個新的輸入時事務完成了。 4 換句話說，在一次事務中，用戶運行輸入系統(tǒng)的一些操作。此時系統(tǒng)發(fā)生反應。它處理輸入并將處理的結果返回給用戶。當用戶對結果做出反應時，一個新的事務開始了，它反過來由可以作為系統(tǒng)的輸入。

用例事務不總是一個用例步驟

Jacobson 的話還包含了另外一層意思：用例事務并不是定義為“用例流程中的步驟”。只是對由一個“環(huán)形路線”組成的用例流程自身，這種定義才成立。盡管一些書寫用例的方法將它描述成敘述用例事務的另一種方法，但畢竟它不是標準的方式。 5

用例事務不是一個“刺激源”

有些作者建議“用戶運行的刺激源的存在性是定義事務的部分”。 6 盡管一次事務總是從一個刺激源開始（是用戶進行了一項觸發(fā)系統(tǒng)反應的操作），刺激源本身并不是完整的事務。假設您擁有一個以下的用例描述：

    用戶選擇一個 X。
    ...

    （n）用戶提交。
    ...

現(xiàn)在還不清楚系統(tǒng)是否對步驟（1）和（n）中刺激源作出了反應，或者系統(tǒng)是否對步驟（1）或者步驟（n）分別作出。因此，兩個刺激源可以組成一個或者兩個事務。它并不取決于刺激源，而是取決于刺激源和回應的組合。

用例事務并不是一個數(shù)據(jù)庫活動

在 Web 上進行的許多次討論中，您可以找到定義為“一系列要么完全執(zhí)行，要么一點也不執(zhí)行的活動”的用例事務。 7 。該定義聽起來像是數(shù)據(jù)庫管理系統(tǒng)中的一個事務性機理，如果它沒有正常運行的話該步驟可以返回。在我們的經驗中，這不是在一個用例描述中將一片內容與另一片內容隔離起來的方法。它也行會激發(fā)一個想法，也是事務在一定程度上與數(shù)據(jù)庫中的讀寫操作相關。但是，在一個環(huán)形路線中，系統(tǒng)根本不用查詢數(shù)據(jù)庫也是可能的。這個過程中數(shù)據(jù)庫也行根本不會涉及到，或者數(shù)據(jù)來自系統(tǒng)以外。因此得出用例事務一定會與數(shù)據(jù)庫中的事務聯(lián)系起來的結論是不合適的。

用例事務不是一個系統(tǒng)步驟

用例事務中的系統(tǒng)可能會在一步完成。表面上，我們可能會得出用例事務只是一個系統(tǒng)步驟。但是，一個系統(tǒng)步驟并不是描述用例事務的一個較好的基礎，因為它取決于對您計算的多少步驟的描述。而且，系統(tǒng)本身并沒有多少涉及到 Actor 與系統(tǒng)之間的聯(lián)系。換句話說，您的估算應該基于“環(huán)形的”事務，而不是系統(tǒng)步驟。

范例：復雜的用戶界面

用例事務的“環(huán)形路線”方法，在估算用戶界面復雜性方面顯示出其價值。一個范例是工作入口項目，在這個項目中可以設計出一個工作設計機器。在基于用例模型（Survey）的早期估算中，工作搜索界面被認為是簡單的；用戶可以從一系列的下拉菜單中選擇搜索項，然后進行選擇。但是，在用于產生用例描述的用戶界面中，，如果系統(tǒng)可以對已作出的選擇進行回應，并更改后續(xù)下拉菜單中內容的話，那么可以預見應用的可用性會得到提高。換句話說，本來應該是一個的事務現(xiàn)在變成了兩個。

這里是用例配置的第一個草稿：

 該段文字擴展如下：

這里您可以看到兩個“環(huán)形路線”。將用例配置當作證明，查看調整初始估算后的合理性變得容易起來。

將用例事務保持在一定的層次上

如果用例事務是一個緊跟系統(tǒng)回應的刺激源，那么它十分能夠計算成一個事務？例如，如果我從我的鍵盤上敲入一個“K”，那么這是一個刺激源，然后系統(tǒng)會通過在屏幕上顯示一個能組成“K”的像素點來回應這個刺激源。所以，我們以前推薦的定義是不是太狹隘了？

不，不是這樣的。它顯示您理解用例事務時，應該與用例事務本身被理解保持同一個層次。現(xiàn)在，您可能對輸入字母這種操作不感興趣，當字母出現(xiàn)在屏幕上的，您會覺得這是理所當然的；您不需要在系統(tǒng)中構建什么東西來產生結果。但是，如果您的內容是描述鍵盤模型與圖形化反應器，這樣一個用例事務是十分合理的。