【正文】 需求獲取的目標(biāo) 對(duì)大系統(tǒng)的開發(fā)來說 ， 需求一般包括需求獲取和需求分析 ?需求獲取的目標(biāo)是： ? 需求分析的目標(biāo)是： 客觀問題（系統(tǒng)） 系統(tǒng)需求獲取模型 形成 涉及：不同概念和不同處理邏輯 形成 涉及：不同概念和不同處理邏輯 系統(tǒng)分析模型 描述 — 系統(tǒng)需求獲取模型 體系結(jié)構(gòu)描述 USE CASE模型 體系結(jié)構(gòu)描述 Analysis模型 實(shí)現(xiàn)需求獲取目標(biāo)的基本途徑 實(shí)現(xiàn) 需求獲取的目標(biāo)，即實(shí)現(xiàn) 實(shí)際問題到軟件開發(fā)需求獲取層的映射，從軟件開發(fā)的角度 實(shí)現(xiàn)第一次抽象。 實(shí)際問題 模型表示 工具 USE CASE圖 體系結(jié)構(gòu)描述 USE CASE模型 （ 2） 需求工作流 實(shí)際問題 ？ 需求獲取模型 （ USE CASE 模型） 形成 體系結(jié)構(gòu)描述 USE CASE模型 形成 需求工作流及所創(chuàng)建的制品 一般來說，需求工作流包括以下四步，但它們并非是嚴(yán)格 分離的。 統(tǒng)計(jì) 2科以上不及格的人數(shù)。 每一特征還有一組對(duì)規(guī)劃有意義的信息，可以包括： ?狀態(tài)（ Status），例如 ，提交，批準(zhǔn)，確認(rèn) 是組成的等。 ? 實(shí)現(xiàn)中相聯(lián)的風(fēng)險(xiǎn)等級(jí)。 ?實(shí)在對(duì)象（ Realworld objects）和概念：例如 飛機(jī)， 火箭等。 一般來說， 業(yè)務(wù) use case 模型 是以 use case 圖予以描述的 . ? 業(yè)務(wù)對(duì)象模型 業(yè)務(wù)對(duì)象模型是一個(gè)業(yè)務(wù)的內(nèi)部（ interior）模型。 A work unit 是這樣實(shí)體的一個(gè)集合，對(duì)最終用戶 而言，形成了可認(rèn)知的整體。 ? UseCase模型 作為客戶和開發(fā)人員之間的一種共識(shí)。 Note:還要標(biāo)識(shí)表示外部系統(tǒng)的 actor和系統(tǒng)維護(hù)和運(yùn)行所需要的 actor 。 如果 2個(gè)或多個(gè) actors有著幾乎相同的角色，那么就應(yīng)該 考慮： ?是否將這些角色組合到一個(gè) actor的角色中，或 ?是否需要發(fā)現(xiàn)另外一個(gè) “ 一般化 ” 的 actor，使之具有那些 重疊的、公共的角色 ，并可以通過 “ 泛化 ” ，形成那些特 定 actor。 例如 : 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 Accounting system Use case in the Billing and Payment System that support the business use case Sales:From Order to Delivery. The role initiator, attached to the associations, indicate which actor starts the use case. 發(fā)現(xiàn)并描述 Use Case (1) 對(duì) use case的回顧 A use case specifies a sequence of actions, including alternatives of the sequence , that the system can perform , interacting with actor of the system. ? actor 使用系統(tǒng)的每一方法（ way ），被表示為一個(gè) use case ? Use case 是系統(tǒng)向它的 actors 提供結(jié)果（值）的功能塊 （ chunks ）。 ? 在一個(gè)新的狀態(tài)中，等待 actor發(fā)送另一外部消息 。這是由于我們把 use case實(shí)例看作是原子的，每一個(gè) use case的行為可以被其它 use case所中斷， 這就確保了我們可以理解一個(gè)特定的 use case模型。 結(jié)論： 為參與 業(yè)務(wù) use case細(xì)化 （ realization）的、使用該信息系統(tǒng)的 每一工作人員的 每一角色 ，建議一個(gè) use case。 其中，均應(yīng)根據(jù) actor的需求來 發(fā)現(xiàn) use case： actor通常需要 use cases來支持他們的工作： 創(chuàng)建、改變、跟蹤、遷移業(yè)務(wù) use cases中使用的業(yè)務(wù)對(duì)象， 例如定單和帳目。 ? 為每一 use cases 選擇一個(gè)名字（一般應(yīng)以動(dòng)詞開始），這個(gè)可以引導(dǎo)我們思考其中向 actor產(chǎn)生值的特定動(dòng)作序列。 其中要注意 2個(gè)關(guān)鍵詞： 結(jié)果（值） （ result of value ） 特定的 actor（ particular actor ） ?結(jié)果（值） (result of value) 每一個(gè)成功執(zhí)行的 use case 應(yīng)向 actor 提供一些值，使 actor 達(dá)到某一目的。例如，一旦我們已經(jīng)有了一個(gè)體系結(jié)構(gòu)，那么對(duì)于我們捕獲的新的 use cases 就必須進(jìn)行調(diào)整，以便適應(yīng)已有的體系結(jié)構(gòu)。 ? 輸入與輸出 Architect Use Case model [outlined] Supplementary Requirements Glossary Architecture Description [view of the use case model] Prioritized Use Cases ?視角與使用 視角：從 體系結(jié)構(gòu)的視覺，來審視所建立的 use case 模 型。其中，要 注意： 在這 一規(guī)劃中，還需要考慮其它非技術(shù)因素，例如系統(tǒng) 開發(fā)的業(yè)務(wù)和經(jīng)濟(jì)方面的因素。 ?輸入與輸出 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ì)化途徑 涉及： ?如何描述一個(gè) use case中所有可選的路徑； ?在一個(gè) use case的描述中包括的內(nèi)容； ? 如何在必要時(shí)形式化地給出 use case的描述。 ?當(dāng)所規(guī)約的 use case執(zhí)行時(shí)，事件流還規(guī)約了系統(tǒng)怎樣與其actors進(jìn)行交互 基本要求 ：從管理的角度來說，一個(gè)事件流的描述應(yīng)包括一組動(dòng)作序列，該組動(dòng)作序列適于修改、復(fù)審、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試，并作為用戶手冊(cè)的一節(jié)。 其中，這一路徑的選擇應(yīng)該是用戶認(rèn)為它是一條最通常的 路徑，并對(duì) 相關(guān)的 actor產(chǎn)生最明顯的值（ the most obvious value ）。 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