【正文】 概述 ， 補(bǔ)充需求 ， 術(shù)語表 人機(jī)接口原型化 人機(jī)接口設(shè)計(jì)者 人機(jī)接口原型 5 用況 詳述 ， 用況模型概述 ， 補(bǔ)充需求 ， 術(shù)語表 構(gòu)造用況模型 系統(tǒng)分析員 用況模型 詳述 需求分析 實(shí)際問題 ？ 需求獲取模型 形成 ？ 需求分析模型 形成 需求獲取 需求分析 注：實(shí)現(xiàn)第二次抽象 注：實(shí)現(xiàn)第一次抽象 1) 需求分析層的術(shù)語 ?分析類（ Analysis class） ?Use Case細(xì)化（ Use Case RealizationAnalysis） ?分析包（ Analysis Package） ? 分析類（ Analysis class） 一個(gè)分析類抽象地表達(dá)了 系統(tǒng)設(shè)計(jì)中 的一個(gè)或多個(gè)類和 /或子系統(tǒng)。 分析類的基本性質(zhì)： ? 分析類關(guān)注處理功能需求，而將非功能需求的處理延遲到 以后的設(shè)計(jì)和實(shí)現(xiàn)活動(dòng)中，并作為類的特殊需求。 ? 分析類很少通過操作和其聲明（ signatures）定義或提 供接口。其行為一般是通過高層的責(zé)任予以定義的。一 個(gè)責(zé)任是高內(nèi)聚的一組由類所定義的行為的正文描述。 ? 分析類的屬性也是在很高層次上定義的。這類屬性經(jīng)常是 問題域上的概念，并可通過問題域就可以了解其含義。 ? 分析類所涉及的關(guān)聯(lián)，多數(shù)是概念性的，例如關(guān)聯(lián)的導(dǎo)航 性，在分析中并非十分重要，而在設(shè)計(jì)中就是基本的。 目的：使分析類在問題域中更加突出，與設(shè)計(jì)和實(shí)現(xiàn)中的類相比，粒度大，是概念性的。 Boundary classes: 內(nèi)涵 ：用于系統(tǒng)與其 actors 之間交互的建模。 該交互一般涉及向用戶和外部系統(tǒng)發(fā)出請求和從他們那里接 受信息。 與設(shè)計(jì)平臺(tái)的關(guān)系 ：邊界類常常是在更高的概念層上，對 windows, forms, panes, munication interfaces, printer interfaces, sensors, terminals, and APIs 等的抽象，忽略其中的一些細(xì)節(jié)，例如： every widget of a user interface，并且不需要描述該交互的物理實(shí) 現(xiàn)（ realize）。 基于的設(shè)計(jì)原理 ：分離用戶界面或通訊界面中的變化，形成一個(gè)或 多個(gè)邊界類。 分析類的種類：通常具有三種：邊界類 （ Boundary classes） , 實(shí)體類 （ Entity classes）， 控制類 （ Control classes） . 實(shí)體類（ Entity classes） : 內(nèi)涵 ：用于對那些需要長期足留系統(tǒng)的模型化對象以及與行為相關(guān)的某些 現(xiàn)象進(jìn)行建模，例如人的信息以及實(shí)際的一個(gè)事件。 與業(yè)務(wù)類的關(guān)系 ： 在大多數(shù)情況下，實(shí)體類對應(yīng)業(yè)務(wù)模型中的業(yè)務(wù)類。其中一個(gè)主要區(qū)別 是：現(xiàn)在所考慮的實(shí)體類，一般是要由系統(tǒng)處理的那些對象。 與設(shè)計(jì)平臺(tái)的關(guān)系 ： 實(shí)體類一般表示一個(gè)邏輯數(shù)據(jù)結(jié)構(gòu)和屬性，以理解系統(tǒng)依賴什么信息。 基于的設(shè)計(jì)原理 ： 分離一些變化，形成不同對象所表達(dá)的信息。 控制類（ Control Classes）： 內(nèi)涵 : 控制類處理并協(xié)調(diào)那些主要?jiǎng)幼鳎?actions）和控制流，并向其它對 象（例如邊界類對象，實(shí)體類對象）委派工作。 用途 ：控制類可以實(shí)現(xiàn)對系統(tǒng)的動(dòng)態(tài)性（ dynamics）建模： ?用于表達(dá)協(xié)同、定序、事務(wù)以及對其它對象的控制； ?經(jīng)常用于封裝那些與特定 use case 有關(guān)的控制； ?用于表達(dá)復(fù)雜的推導(dǎo)和計(jì)算，例如業(yè)務(wù)邏輯，該邏 輯并不與 任意 存貯在系統(tǒng)中的特定信息有關(guān)。 基于的設(shè)計(jì)原理 ： 問題分離 控制類分離一些在控制方面、協(xié)調(diào)方面、定序方面以及復(fù)雜業(yè)務(wù)邏輯方面的變化，并予以封裝，形成所謂的控制類，其中一般要涉及其他一些對象。而 不能封裝那些與 actors交互有關(guān)的問題（由邊界類予以封裝）。也不能封裝與系統(tǒng)處理的那些信息有關(guān)的問題（由實(shí)體類予以封裝）。 可見： 邊界類 封裝了一些重要的通信接口和用戶界面機(jī)制。 實(shí)體類 封裝了問題域中的實(shí)體概念 控制類 封裝了一些重要的定序（ sequences），涉及多個(gè) 成分，例如協(xié)調(diào)有意義的 usecase細(xì)化。 ?分析包（ Analysis Package） 分析包提供了一種組織分析制品的手段，形成一些可 管理的部分。 分析包可以包含分析類、 use case 細(xì)化以及其它分析包。 Analysis package * * * Analysis class Use case Realizationanalysis Analysis package contents 分析包的主要特征（ characteristic） ? 高內(nèi)聚、低耦合； ? 表達(dá)分析問題的分離；例如，將不同的領(lǐng)域知識同時(shí)分為 不同的包予以分析。 ?由于 是針對功能需求和問題域予以創(chuàng)建的，因此對具有領(lǐng) 域知識的人來說，是可以閱讀、理解的。 ?很有可能成為一些子系統(tǒng)或成為一些子系統(tǒng)的組成部分。 在某些情況中，甚至可以反映一個(gè)完整的頂層設(shè)計(jì)。 ? UseCase 細(xì)化（ UseCase RealizationAnalysis） 內(nèi)涵 （ 何謂 UseCase 細(xì)化？） 一個(gè) UseCase 細(xì)化是分析模型中的一個(gè)協(xié)作（ a collaboration ），描述了一個(gè)特定的 UseCase如何運(yùn)用分析類以及分析類的交互對象進(jìn)行細(xì)化和執(zhí)行 。 作用 ： UseCase 細(xì)化對 usecase模型中的一個(gè)特定的 use case 提供了一中直接方式的跟蹤。 如何表達(dá) UseCase 細(xì)化？ ? 正文的事件流 ? 類圖 ?交互圖 2）需求分析層的制品： ( 5個(gè) ) 除了以上 3個(gè)外，還有： ?分析模型（ 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 分析模型是分析包的一個(gè)層次結(jié)構(gòu)，包含分析類和 usecase細(xì)化。 * * * * * * 1 [Analysis System denotes the toplevel package of the model.] ?體系結(jié)構(gòu)描述 ( View of the Analysis Model) 從體系結(jié)構(gòu)的視覺，描述一些在體系結(jié)構(gòu)方面具有重要意 義的制品。 一般包括： ? 分析包以及它們的依賴（ 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é)果是分析模型，該模型是概念層的對象模 型，它精化了需求，并對需求進(jìn)行了結(jié)構(gòu)化。 分析模型包含以下元素： ?分析包和服務(wù)包，以及它們的依賴和內(nèi)容。 其中： 分析包可以把一些變化局部到一個(gè)業(yè)務(wù)過程、一個(gè) actor的 行為，或一組緊密相關(guān)的 use cases 。 服務(wù)包將一些變化局部到系統(tǒng)提供的一些單個(gè)的服務(wù)；并 展示了一個(gè)重要的指南 在分析期間如何構(gòu)造復(fù)用。 ?分析類，它們的責(zé)任、屬性和關(guān)系，以及特殊的需求 其中： 在用戶界面、一個(gè)通訊界面中的一個(gè)變化，通常被局部化到 一個(gè)或多個(gè)邊界類中； 在系統(tǒng)所處理信息中的一個(gè)變化，通常被局部化到一個(gè)或多 個(gè)實(shí)體類中； 在控制、協(xié)調(diào)、定序、事務(wù)和復(fù)雜業(yè)務(wù)邏輯（它們要涉及多 個(gè)邊界和 /或?qū)嶓w對象）中的一個(gè)變化，通常被局部化到一個(gè)或 多個(gè)控制類中。 ? Usecase細(xì)化 分析 ，描述了如何利用分析模型中協(xié)作，來精 化 use case和相關(guān)的特殊需求。 Usecase細(xì)化將一些變化，局部到 use cases中。因?yàn)槿绻? 個(gè) use case變化了 ,那么它的細(xì)化也可能需要改變。 2）分析模型視覺的體系結(jié)構(gòu) （ The architectural view of the analysis model） 其中包括體系結(jié)構(gòu)上具有重要意義的元素。這一體系結(jié)構(gòu)上 的視覺，將一些變化局部到體系結(jié)構(gòu)中。 3） 分析階段的活動(dòng)： 序號 輸入 活動(dòng) 執(zhí)行者 輸出 1 用況模型 、 補(bǔ)充需求 、業(yè)務(wù)模型或領(lǐng)域模型 、體系結(jié)構(gòu)描述 用況模型角度 體系結(jié)構(gòu)分析 體系結(jié)構(gòu)設(shè)計(jì)者 分析包 概述 、 分析類 概述 、 體系結(jié)構(gòu)描述 分析模型角度 2 用況模型 、 補(bǔ)充需求 、業(yè)務(wù)模型或領(lǐng)域模型 、體系結(jié)構(gòu)描述 分析模型角度 分析用況 用況工程師 用況 實(shí)現(xiàn) 分析 、 分析類 概述 3 用況 實(shí)現(xiàn) 分析 、 分析類 概述 對類分析 構(gòu)件工程師 分析類 完成 4 系統(tǒng)體系結(jié)構(gòu)描述 分析模型角度 、 分析包 概述 對包進(jìn)行分析 構(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。 gives structure to the external view ? Used primarily as a contract between the customer and the developers on what the system should and should not do ?Described using the language of the developer ?Internal view of the system ?Structured by stereotypical classes and packages。 gives st