【正文】 tors 的系統(tǒng)交互以及它們之間的交換 (Step 2 and Step 3)，即描述該 use case 動作序列，這些動作是如何被 相關(guān)的 actors予以激發(fā)（ invoke）以及它們是如何執(zhí)行的， 以響應(yīng) actor的要求。 ? 定義可能的結(jié)束狀態(tài)，作為后置條件（ post conditions） . ? 給出在基本路徑描述中的可選路徑的描述。例中，該次序是通過步驟號予以定義的（ (Step 14) ）。 Example: Paths of the Pay Invoice Use Case Precondition: The buyer has received the goods or services ordered and at least one invoice from the system. The buyer now plans to schedule the invoice(s) for payment. Flow of Events Basic Path 1 The buyer invokes the use case by beginning to browse the invoices received by the system. The system checks that the content of each invoice is consistent with order confirmations received early(as part of the Confirm Order use case) and somehow indicates this to the buyer. The order confirmation describes which items will be delivered, when , where, and at what price. 2 The buyer decides to schedule an invoice for payment by the bank, and the system generates a payment request to transfer money to the seller?s account. Note that a buyer may not schedule the same invoice for payment twice. 3 later, if there is enough money in the buyer?s account, a payment transaction is made on the scheduled date. During the transaction, money is transferred from the buyer?s account to the seller?s account, as described by the abstract use case Perform Transaction(which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collect a fee for the transaction, which is withdrawn from the buyer?s account by the system. 4 The use case instance terminates. Alternative Path In Step 2, the buyer may instead ask the system to send an invoice rejection back to the seller. In Step 3, if there is not enough money in the account, the use case will cancel the payment and notify the buyer. Postcondition: The use case instance ends when the invoice has been paid or when the invoice payment was canceled and no money was transferred. Use Case 描述中的基本內(nèi)容 一個 usecase 描述中，必須包括： ? 定義其開始狀態(tài)，作為一個前置條件（ recondition） . ? 定義第一個要執(zhí)行的動作，例如 Step 1，即描述該 use case 是如何開始的，什么時候開始。 ? 接之，在另一節(jié)中描述其余的可選路徑 其中，有些可選的路徑是很小的，是否可以把它作為基本 路徑的組成部分還是在一個獨(dú)立的一節(jié)中作為可選路徑予以 描述，這是一個設(shè)計(jì)決策問題，取決于該描述是否精確，是 否容易閱讀。 其中，這一路徑的選擇應(yīng)該是用戶認(rèn)為它是一條最通常的 路徑，并對 相關(guān)的 actor產(chǎn)生最明顯的值（ the most obvious value ）。 ? 當(dāng)被一個事件（例如一個消息）激發(fā)時，每一這樣的轉(zhuǎn) 換是該 usecase的一個實(shí)例所執(zhí)行的一個動作序列。 ?當(dāng)所規(guī)約的 use case執(zhí)行時，事件流還規(guī)約了系統(tǒng)怎樣與其actors進(jìn)行交互 基本要求 ：從管理的角度來說，一個事件流的描述應(yīng)包括一組動作序列，該組動作序列適于修改、復(fù)審、設(shè)計(jì)、實(shí)現(xiàn)和測試，并作為用戶手冊的一節(jié)。 有效技術(shù)：事件流技術(shù) 關(guān)于事件流（ Flow of Events）的作用 ： ?當(dāng)所規(guī)約的 use case執(zhí)行時，事件流規(guī)約了系統(tǒng)做什么。 ?輸入與輸出 Use case Specifier Use Case model [outlined] Supplementary Requirements Glossary Use Case [detailed] Detail a Use Case The result is a detailed description of a particular use case in text and diagram. ?細(xì)化途徑 涉及： ?如何描述一個 use case中所有可選的路徑； ?在一個 use case的描述中包括的內(nèi)容； ? 如何在必要時形式化地給出 use case的描述。包含： 某些重要、關(guān)鍵功能的 use case ；或 那些必須在軟件生存周期早期予以開發(fā)的某些重要 需求的 use case。其中，要 注意： 在這 一規(guī)劃中，還需要考慮其它非技術(shù)因素，例如系統(tǒng) 開發(fā)的業(yè)務(wù)和經(jīng)濟(jì)方面的因素。 （注：其中必須與項(xiàng)目經(jīng)理一起來工作。 ? 輸入與輸出 Architect Use Case model [outlined] Supplementary Requirements Glossary Architecture Description [view of the use case model] Prioritized Use Cases ?視角與使用 視角：從 體系結(jié)構(gòu)的視覺，來審視所建立的 use case 模 型。 (3) use case的簡單描述 當(dāng)分析員標(biāo)識 use case時，首先，一般要給出該 use case的 名字。例如，一旦我們已經(jīng)有了一個體系結(jié)構(gòu)，那么對于我們捕獲的新的 use cases 就必須進(jìn)行調(diào)整，以便適應(yīng)已有的體系結(jié)構(gòu)。 ?特定的 actor ( particular actor) 通過使標(biāo)識的 use cases 都有相應(yīng)的真實(shí)用戶，這樣可以確保不會太大。 其中要注意 2個關(guān)鍵詞： 結(jié)果（值） （ result of value ） 特定的 actor（ particular actor ） ?結(jié)果（值） (result of value) 每一個成功執(zhí)行的 use case 應(yīng)向 actor 提供一些值，使 actor 達(dá)到某一目的。 ?當(dāng)決定把一個侯選的 use case 最終作為系統(tǒng)的一個 use case 時，必須考慮：它是否是完整的 （ plete）； 它是否是另一 use case的組成部分。 ? 為每一 use cases 選擇一個名字（一般應(yīng)以動詞開始），這個可以引導(dǎo)我們思考其中向 actor產(chǎn)生值的特定動作序列。 還可能存在一些其他的 actors ，他們執(zhí)行系統(tǒng)的啟動、終 止和維護(hù)。 其中，均應(yīng)根據(jù) actor的需求來 發(fā)現(xiàn) use case： actor通常需要 use cases來支持他們的工作： 創(chuàng)建、改變、跟蹤、遷移業(yè)務(wù) use cases中使用的業(yè)務(wù)對象， 例如定單和帳目。其中： 應(yīng) 一個一個地審閱 actors, 為每一個 actor建議一些侯選的 use case。 結(jié)論： 為參與 業(yè)務(wù) use case細(xì)化 （ realization）的、使用該信息系統(tǒng)的 每一工作人員的 每一角色 ，建議一個 use case。 因此， ?針對每一 業(yè)務(wù) use case ,為每一工作人員和業(yè)務(wù) actor，設(shè)置 一個 use case。這是由于我們把 use case實(shí)例看作是原子的，每一個 use case的行為可以被其它 use case所中斷， 這就確保了我們可以理解一個特定的 use case模型。 ?Use case有其自己的屬性 ,例如 Withdraw money 這一 use case 可以認(rèn)為它有屬性 “ 帳目 ” （ account）、存款數(shù)目（ amount to be withdrawn）等，這些值局部于一個 use case實(shí)例 ?Use case實(shí)例不能與其它 use case 實(shí)例發(fā)生交互。 ? 在一個新的狀態(tài)中，等待 actor發(fā)送另一外部消息 。 ? 在一個 use case中的一條路徑，可以看作： ? 啟動了該 use case實(shí)例，并使之處于一個開始狀態(tài)； ? 該狀態(tài)由一個外部的 actor所引發(fā)（ invoke）；并由一個 動作序列的執(zhí)行，使之轉(zhuǎn)化為另一狀態(tài)。 例如 : the Buyer, Seller,and Accounting System Actors ? Buyer A Buyer represents a person who is responsible for buying goods or services as described in the business use case Sales: from Order to Delivery. This person may be an individual or someone within a business anization. The Buyer of goods and services need the Billing and Payment System to send order and to pay invoices. ? Seller A Seller represents a person who sells and delivers goods or services. The Seller uses the system to look for new orders and to send order confirmations, invoices, and payment reminders. ? Accounting System The Billing and Payment System sends verifications of transactions to the Accounting System. Order Goods or Services Confirm Order Invoice Buyer Pay Invoice Perform Transaction Pay Overdraft Fee Send Reminders 《 extend》 Initiator Initiator Initiator Initiator Initiator Buyer Seller