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