【正文】 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é)束狀態(tài)，作為后置條件（ post conditions） . ? 給出在基本路徑描述中的可選路徑的描述。 ?如果該系統(tǒng)與其它系統(tǒng)交互，則必須規(guī)約這一交互 ,例如引用 一個標(biāo)準(zhǔn)的通訊協(xié)議。 當(dāng) use case 描述是： ? 可理解的； ? 正確的（即捕獲了正確的需求）； ? 完備的（ plete，例如，描述了所有可能的路徑） 。 半形式化的 UseCase描述 ? 前置條件 對于一個復(fù)雜的實時系統(tǒng)， use case可能是相當(dāng)負(fù)責(zé)的， 例如 actors和 use case 之間的交互可能經(jīng)過相當(dāng)多的狀態(tài)和 狀態(tài)轉(zhuǎn)換，從而幾乎不可能保持正文描述的 use case 的一致 性。 注：活動圖源于 SDL的狀態(tài)轉(zhuǎn)換圖（ SDL state transition diagrams），它是已予證明的、用于電信的一種語言。 ?這些圖是一些更接近開發(fā)細(xì)節(jié)的圖，應(yīng)與系統(tǒng)其它模型 保持一致。 ?步驟 第一步，用戶界面的邏輯設(shè)計 第二步，物理用戶界面的設(shè)計 第三步，開發(fā)用戶界面原型，演示為了執(zhí)行該 use case，用戶怎樣使用該系統(tǒng)。 做什么 ： ? 抽取 use case描述中一般的、共享的功能，用于特定 use case描述。否則，不論對用戶或客戶還是對開發(fā)人員本身，要理解這些 use cases以及它們的意圖就變得相當(dāng)困難 . ? 每一個 use case都需要被進一步處理為一個特定的制品。最好在分析和設(shè)計中對每一 use case進行精化（ refining）。 ? A UseCase 模型是系統(tǒng)的一個模型，包含系統(tǒng)中 actors 、 use cases 以及它們之間的關(guān)系。即在分析階段和設(shè)計階段， 應(yīng)標(biāo)識相匹配的 usecase 細(xì)化 （ realization） ，并標(biāo)識測試階段 中的一組測試用例（ test cases ）。其行為一般是通過高層的責(zé)任予以定義的。 ? 分析類所涉及的關(guān)聯(lián)，多數(shù)是概念性的，例如關(guān)聯(lián)的導(dǎo)航 性，在分析中并非十分重要，而在設(shè)計中就是基本的。 與設(shè)計平臺的關(guān)系 ：邊界類常常是在更高的概念層上，對 windows, forms, panes, munication interfaces, printer interfaces, sensors, terminals, and APIs 等的抽象，忽略其中的一些細(xì)節(jié)，例如： every widget of a user interface，并且不需要描述該交互的物理實 現(xiàn)（ realize）。其中一個主要區(qū)別 是：現(xiàn)在所考慮的實體類，一般是要由系統(tǒng)處理的那些對象。 用途 ：控制類可以實現(xiàn)對系統(tǒng)的動態(tài)性（ dynamics）建模： ?用于表達協(xié)同、定序、事務(wù)以及對其它對象的控制； ?經(jīng)常用于封裝那些與特定 use case 有關(guān)的控制； ?用于表達復(fù)雜的推導(dǎo)和計算，例如業(yè)務(wù)邏輯，該邏 輯并不與 任意 存貯在系統(tǒng)中的特定信息有關(guān)。 可見： 邊界類 封裝了一些重要的通信接口和用戶界面機制。 Analysis package * * * Analysis class Use case Realizationanalysis Analysis package contents 分析包的主要特征（ characteristic） ? 高內(nèi)聚、低耦合； ? 表達分析問題的分離；例如，將不同的領(lǐng)域知識同時分為 不同的包予以分析。 ? UseCase 細(xì)化（ UseCase RealizationAnalysis） 內(nèi)涵 （ 何謂 UseCase 細(xì)化？） 一個 UseCase 細(xì)化是分析模型中的一個協(xié)作（ a collaboration ），描述了一個特定的 UseCase如何運用分析類以及分析類的交互對象進行細(xì)化和執(zhí)行 。 一般包括： ? 分析包以及它們的依賴（ dependencies） （ Why? This deposition often impacts the subsystems in toplevel layers during design and implementation and is thus significant for the architecture in general.） ? 一些關(guān)鍵的分析類 （ Why? analysis classes have many relationships with other analysis classes. It is usually sufficient to consider an abstract class . ） 3) Workflow (1) 體系結(jié)構(gòu)分析（ Architectural Analysis） 目的：通過標(biāo)識 ?分析包， ? 分析類， ? 公共的特定需求， 建立分析模型和體系結(jié)構(gòu)的“骨架” ？ 需求分析模型 形成 需求獲取模型 總結(jié)（ Summary of Analysis） 1）分析工作流的結(jié)果是分析模型，該模型是概念層的對象模 型，它精化了需求，并對需求進行了結(jié)構(gòu)化。 ?分析類，它們的責(zé)任、屬性和關(guān)系，以及特殊的需求 其中： 在用戶界面、一個通訊界面中的一個變化，通常被局部化到 一個或多個邊界類中； 在系統(tǒng)所處理信息中的一個變化，通常被局部化到一個或多 個實體類中； 在控制、協(xié)調(diào)、定序、事務(wù)和復(fù)雜業(yè)務(wù)邏輯（它們要涉及多 個邊界和 /或?qū)嶓w對象）中的一個變化，通常被局部化到一個或 多個控制類中。 2）分析模型視覺的體系結(jié)構(gòu) （ The architectural view of the analysis model） 其中包括體系結(jié)構(gòu)上具有重要意義的元素。 gives st。 3） 分析階段的活動： 序號 輸入 活動 執(zhí)行者 輸出 1 用況模型 、 補充需求 、業(yè)務(wù)模型或領(lǐng)域模型 、體系結(jié)構(gòu)描述 用況模型角度 體系結(jié)構(gòu)分析 體系結(jié)構(gòu)設(shè)計者 分析包 概述 、 分析類 概述 、 體系結(jié)構(gòu)描述 分析模型角度 2 用況模型 、 補充需求 、業(yè)務(wù)模型或領(lǐng)域模型 、體系結(jié)構(gòu)描述 分析模型角度 分析用況 用況工程師 用況 實現(xiàn) 分析 、 分析類 概述 3 用況 實現(xiàn) 分析 、 分析類 概述 對類分析 構(gòu)件工程師 分析類 完成 4 系統(tǒng)體系結(jié)構(gòu)描述 分析模型角度 、 分析包 概述 對包進行分析 構(gòu)件工程師 分析包 完成 4） Use Case模型與分析模型的比較 UseCase Model Analysis Model ?Described using the language of the customer ? External view of the system ? Structured by use cases。 Usecase細(xì)化將一些變化，局部到 use cases中。 其中： 分析包可以把一些變化局部到一個業(yè)務(wù)過程、一個 actor的 行為，或一組緊密相關(guān)的 use cases 。 如何表達 UseCase 細(xì)化？ ? 正文的事件流 ? 類圖 ?交互圖 2）需求分析層的制品： ( 5個 ) 除了以上 3個外，還有： ?分析模型（ Analysis model） ?體系結(jié)構(gòu)描述 （ Architecture Description( View of the Analysis Model) 分析模型 體系結(jié)構(gòu)描述 分析 ? 分析模型 Analysis model Analysis System Analysis Package Analysis Class UseCase RealizationAnalysis 分析模型是分析包的一個層次結(jié)構(gòu)，包含分析類和 usecase細(xì)化。 ?很有可能成為一些子系統(tǒng)或成為一些子系統(tǒng)的組成部分。 ?分析包（ Analysis Package） 分析包提供了一種組織分析制品的手段，形成一些可 管理的部分。而 不能封裝那些與 actors交互有關(guān)的問題（由邊界類予以封裝）。 基于的設(shè)計原理 ： 分離一些變化，形成不同對象所表達的信息。 分析類的種類：通常具有三種：邊界類 （ Boundary classes） , 實體類 （ Entity classes）， 控制類 （ Control classes） . 實體類（ Entity classes） : 內(nèi)涵 ：用于對那些需要長期足留系統(tǒng)的模型化對象以及與行為相關(guān)的某些 現(xiàn)象進行建模，例如人的信息以及實際的一個事件。 Boundary classes: 內(nèi)涵 ：用于系統(tǒng)與其 actors 之間交互的建模。 ? 分析類的屬性也是在很高層次上定義的。 分析類的基本性質(zhì)： ? 分析類關(guān)注處理功能需求，而將非功能需求的處理延遲到 以后的設(shè)計和實現(xiàn)活動中，并作為類的特殊需求。非功能需求特定于單個的 use case，其 規(guī)約具有一般性，并不針對一個特定的 use case 。 ?use case 模型 ? UseCase Model 是軟件和客戶就需求的一個共識，即系統(tǒng) 必須具有的條件（ conditions）和能力（ capabilities） 。為此， use cases不應(yīng)太小或太多，從而需要對use case結(jié)構(gòu)化工作予以有效地管理。 ?使用泛化關(guān)系，標(biāo)識并描述那些共享功能 例如： Buyer Seller Pay Invoice Pay Invoice 和 Perform Transaction 這 2個 use case之間的泛化關(guān)系 Perform Transaction ?使用 擴展關(guān)系，標(biāo)識并描述附加的或可選的功能 例如： Buyer Seller Pay Invoice Pay Invoice 和 Pay Overdraft Fee 這 2個 use cases之間的擴展關(guān)系 《 extend》 Perform Transaction Pay Overdraft Fee ?標(biāo)識 use case之間的其它關(guān)系 use cases之間還包括其它關(guān)系，例如包含關(guān)系（ include ）。 (7) Use Case 模型的結(jié)構(gòu)化 前置條件 : ?系統(tǒng)分析員已經(jīng)標(biāo)識了 actors 和 use cases, 已經(jīng)以 圖予以了描述，并給出了整個 use case 模型的說明。 在很多情況中，正文描述和這些圖是互補的。為此，交互圖給出了 use case 以及參與的 actor（ s）。以下技術(shù)可以幫助 系統(tǒng)分析人員更好地理解