【正文】 ? 目的 建造一個(gè) 用戶界面的原型，使用戶有效地執(zhí)行 use cases。 ? The UseCase 模型為系統(tǒng)分析、設(shè)計(jì)、實(shí)現(xiàn)以及測試提供 了基本的輸入。 該交互一般涉及向用戶和外部系統(tǒng)發(fā)出請(qǐng)求和從他們那里接 受信息。 分析包可以包含分析類、 use case 細(xì)化以及其它分析包。因?yàn)槿绻? 個(gè) use case變化了 ,那么它的細(xì)化也可能需要改變。 服務(wù)包將一些變化局部到系統(tǒng)提供的一些單個(gè)的服務(wù)；并 展示了一個(gè)重要的指南 在分析期間如何構(gòu)造復(fù)用。也不能封裝與系統(tǒng)處理的那些信息有關(guān)的問題（由實(shí)體類予以封裝）。這類屬性經(jīng)常是 問題域上的概念，并可通過問題域就可以了解其含義。 ? 應(yīng)避免分解 use case 模型中 use cases的功能。 注意 : ?在使用這些圖當(dāng)中，由于問題的復(fù)雜性，有時(shí)可能會(huì)出 現(xiàn)一些大的、復(fù)雜的圖，以至于很難閱讀和理解，特別對(duì)于 那些不是軟件開發(fā)人員來說更難閱讀。 ?描述系統(tǒng)中有關(guān)對(duì)象、值和資源的用法（ Usage ） (Step 3). 即描述在一個(gè) usecase使用中的動(dòng)作序列以及對(duì)該 usecase屬 性所賦予的值。即每一個(gè) use case的事件流，可以作為 use case的動(dòng)作序列的正文描述。 針對(duì)一些 actors, 我們第一次發(fā)現(xiàn)的 use cases 常常需要予以重新組織，重新評(píng)估，使之更加 “ 穩(wěn)定 ” 。 ? 細(xì)化并調(diào)整這些暫時(shí)的 use cases. ? 決策 工作人員和業(yè)務(wù) actor 的那些任務(wù)應(yīng)該由系統(tǒng)自動(dòng)地 予以實(shí)現(xiàn)，作為 use cases，并重新組織這些 use case，更好 地適應(yīng) actors的要求（ needs） 。 第二條準(zhǔn)則：系統(tǒng)中不同 actors 實(shí)例之間，其角色的重疊 應(yīng)是最少的。 Order date of submission delivery address Item description picture cost Invoice amount date of submission last date of payment Account balance owner 1..* payable 1..* buyer 1 seller 1 A class diagram in a domain model, capturing the most important concepts in the context of the system Example: Domain Classes Order, Invoice, Item, and Account 業(yè)務(wù)模型 業(yè)務(wù)模型可以分為以下 2個(gè)層次： ?業(yè)務(wù) use case 模型 通過 業(yè)務(wù) use case和 業(yè)務(wù) actors 來描述業(yè)務(wù)過程，他們分別 對(duì)應(yīng)業(yè)務(wù)過程（ business processes）和客戶（ customers ）。 應(yīng)用系統(tǒng) 潛在的抽象層 例如： 按學(xué)科計(jì)算每一學(xué)生的期末考試平均成績。 RUP的本質(zhì)及特點(diǎn) (1) 是一種迭代的、以架構(gòu)為中心的、用例驅(qū)動(dòng)的軟件開發(fā)方法 (2) 是一種具有明確定義和結(jié)構(gòu)的軟件工程過程，包括規(guī)定了人員的職責(zé)、如何完成各項(xiàng)工作以及何時(shí)完成各項(xiàng)工作。 期間，培訓(xùn)用戶如何使用該軟件。 每一特征還有一組對(duì)規(guī)劃有意義的信息，可以包括： ?狀態(tài)（ Status），例如 ，提交，批準(zhǔn)，確認(rèn) 是組成的等。 A work unit 是這樣實(shí)體的一個(gè)集合，對(duì)最終用戶 而言，形成了可認(rèn)知的整體。 例如 : 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 ）。 其中，均應(yīng)根據(jù) actor的需求來 發(fā)現(xiàn) use case： actor通常需要 use cases來支持他們的工作： 創(chuàng)建、改變、跟蹤、遷移業(yè)務(wù) use cases中使用的業(yè)務(wù)對(duì)象， 例如定單和帳目。 ? 輸入與輸出 Architect Use Case model [outlined] Supplementary Requirements Glossary Architecture Description [view of the use case model] Prioritized Use Cases ?視角與使用 視角：從 體系結(jié)構(gòu)的視覺，來審視所建立的 use case 模 型。 其中，這一路徑的選擇應(yīng)該是用戶認(rèn)為它是一條最通常的 路徑，并對(duì) 相關(guān)的 actor產(chǎn)生最明顯的值（ the most obvious value ）。 當(dāng) use case 描述是： ? 可理解的； ? 正確的（即捕獲了正確的需求）； ? 完備的（ plete，例如，描述了所有可能的路徑） 。 ?步驟 第一步，用戶界面的邏輯設(shè)計(jì) 第二步，物理用戶界面的設(shè)計(jì) 第三步，開發(fā)用戶界面原型，演示為了執(zhí)行該 use case，用戶怎樣使用該系統(tǒng)。 ? A UseCase 模型是系統(tǒng)的一個(gè)模型，包含系統(tǒng)中 actors 、 use cases 以及它們之間的關(guān)系。 與設(shè)計(jì)平臺(tái)的關(guān)系 ：邊界類常常是在更高的概念層上，對(duì) windows, forms, panes, munication interfaces, printer interfaces, sensors, terminals, and APIs 等的抽象，忽略其中的一些細(xì)節(jié)，例如： every widget of a user interface，并且不需要描述該交互的物理實(shí) 現(xiàn)（ realize）。 Analysis package * * * Analysis class Use case Realizationanalysis Analysis package contents 分析包的主要特征（ characteristic） ? 高內(nèi)聚、低耦合； ? 表達(dá)分析問題的分離；例如，將不同的領(lǐng)域知識(shí)同時(shí)分為 不同的包予以分析。 2）分析模型視覺的體系結(jié)構(gòu) （ The architectural view of the analysis model） 其中包括體系結(jié)構(gòu)上具有重要意義的元素。 其中： 分析包可以把一些變化局部到一個(gè)業(yè)務(wù)過程、一個(gè) actor的 行為，或一組緊密相關(guān)的 use cases 。而 不能封裝那些與 actors交互有關(guān)的問題（由邊界類予以封裝）。 ? 分析類的屬性也是在很高層次上定義的。為此， use cases不應(yīng)太小或太多，從而需要對(duì)use case結(jié)構(gòu)化工作予以有效地管理。為此，交互圖給出了 use case 以及參與的 actor（ s）。 ?定義與 actors 的系統(tǒng)交互以及它們之間的交換 (Step 2 and Step 3)，即描述該 use case 動(dòng)作序列，這些動(dòng)作是如何被 相關(guān)的 actors予以激發(fā)（ invoke）以及它們是如何執(zhí)行的， 以響應(yīng) actor的要求。 有效技術(shù)：事件流技術(shù) 關(guān)于事件流（ Flow of Events）的作用 ： ?當(dāng)所規(guī)約的 use case執(zhí)行時(shí)，事件流規(guī)約了系統(tǒng)做什么。 ?特定的 actor ( particular actor) 通過使標(biāo)識(shí)的 use cases 都有相應(yīng)的真實(shí)用戶，這樣可以確保不會(huì)太大。 因此， ?針對(duì)每一 業(yè)務(wù) use case ,為每一工作人員和業(yè)務(wù) actor，設(shè)置 一個(gè) use case。 該準(zhǔn)則將幫助我們僅發(fā)現(xiàn)那些相關(guān)的 actors，避免 actor 僅是一些想象的 “ 事物 ” 。 一般來說，領(lǐng)域模型是以類圖予以描述的。作為需求 , 并被轉(zhuǎn)換為其它制品。 第二點(diǎn)： 問題空間的處理邏輯 與 解空間處理邏輯 之間的映射 例如 1： 加工 1（ 及相關(guān)的數(shù)據(jù)流 ） =F（ 計(jì)算學(xué)生成績 ） 其中：使用的方法：結(jié)構(gòu)化方法； 對(duì)應(yīng)的過程：需求分析 使用的原理：過程抽象