【正文】 出 體 系 結(jié) 構(gòu) 描 述 ? 何謂 以體系結(jié)構(gòu)為中心 階 段 核心工作流 ? 何謂 迭代、增量的開發(fā) ? 初始階段（ the inception phase）的基本目標(biāo)是： 了解項目的范圍 建立業(yè)務(wù)模型 得到涉眾的認(rèn)可 換言之，其目標(biāo)是：建立該項目的生存周期目標(biāo) （ objectives） ? 精化階段（ the elaboration phase）的基本目標(biāo)是 建立體系結(jié)構(gòu)基線 捕獲大多數(shù)的需求 降低主要的技術(shù)風(fēng)險 減少次要的錯誤風(fēng)險，即建立生存周期體系結(jié)構(gòu) （ the life cycle architecture） . 到該階段末，就能夠估算成本、進(jìn)度，并能詳細(xì)地 規(guī)劃構(gòu)造階段（ the construction phase） 。 注：這 4個階段是演化模型的一個變體。其中至少涉及以下 3個問題： ?如何定義需求獲取層，即給出該層的術(shù)語； ?如何確定模型表示工具； ?如何映射。 要做的工作 產(chǎn)生的制品 列出候選的需求 特征（ Feature）列表 理解系統(tǒng)語境 領(lǐng)域模型或業(yè)務(wù)模型 捕獲功能需求 Use case 模型 捕獲非功能需求 補(bǔ)充需求或針對一些特定需求 的 use cases ?特征（ Feature） : 一個功能項（ function item ）以及相關(guān)的簡要描述 稱為特征（ feature）。 給出各分段 （ 060， 6085， 85100） 的人數(shù)分布情況。 ? 估算的實現(xiàn)成本。 ? 業(yè)務(wù)模型或領(lǐng)域模型 領(lǐng)域模型 領(lǐng)域模型捕獲了系統(tǒng)語境中的一些重要對象類型。 ?事件（ Events）：例如飛機(jī)到達(dá)，飛機(jī)起飛等。描述每 一個 業(yè)務(wù) use case 是如何通過一組 workers 、 business entities 、 work units予以細(xì)化的。 Business entities 和 work unit 用于表達(dá)同一類概念，作為 領(lǐng)域類，例如定單，欄目，發(fā)票等。 ? UseCase 模型是一個系統(tǒng)的一種模型，包括 actors、 use cases 以及它們之間的關(guān)系。 ?在確定系統(tǒng) actors 時可用的 2條準(zhǔn)則： 第一條準(zhǔn)則：至少要識別出一個用戶，可以扮演候選的 actor。 （ 2） Actors的命名與描述 Actors的命名： 對 actors給出恰當(dāng)?shù)拿质欠浅Ｖ匾摹? 例如， use case 實例 Withdraw money The use case Withdraw money enables instances of the actor Bank Customer to withdraw money through an ATM 因此 ? 對一個 use case的描述可以使用正文事件流、狀態(tài)圖、活動 圖、通訊圖和順序圖。 ? 該狀態(tài)由一個新的消息予以引發(fā)（ invoke），以此繼續(xù)， 通過了許多狀態(tài)，直到該 use case實例被終止 . ?大部分是一個 actor實例引發(fā)一個 use case實例， 但也可能由一個事件所引發(fā)，例如由系統(tǒng)之外的定時時鐘所引發(fā)。 (2) 發(fā)現(xiàn) Use Case的方法 ?當(dāng)開始點是一個業(yè)務(wù)模型時 一旦我們發(fā)現(xiàn)了一個工作人員或業(yè)務(wù) actor的所有角色， 標(biāo)識一些暫時的 use case最直接的方法是： 對每一工作人員和業(yè)務(wù) actor 的每一角色，對應(yīng)地創(chuàng)建 一個 use case。 ?當(dāng)開始點沒有業(yè)務(wù)模型時 要通過與客戶以及用戶一起工作來標(biāo)識 use case。 actor 可能還要通知系統(tǒng)一些外部事件，包括已經(jīng)發(fā)生的 一些事件，例如：發(fā)票已經(jīng)過期。用戶和系統(tǒng)的一個交互序列，可以在一個 use case中予以規(guī)約，也可以在多個 use case中予以規(guī)約。 注意： 一個 use case 實例，例如電話呼叫，可能涉及多個 actor. 在這種情況中，應(yīng)當(dāng)應(yīng)用 “ 可見的結(jié)果值 ” 這一準(zhǔn)則，啟動 actor （ to initiating actor） . “結(jié)果（值） ‘ result of value ?” 這一準(zhǔn)則，可以幫助我們避免使發(fā)現(xiàn)的 use cases 太小。這樣，就有可能需要相當(dāng)大的變動。并給出在這一 視覺下的體系結(jié)構(gòu)描述。 ?內(nèi)容： Use Case 模型視覺下的體系結(jié)構(gòu)描述，刻畫了在體 系結(jié)構(gòu)方面具有重要意義的 use cases。 其中規(guī)約人員應(yīng)當(dāng)： 緊密地與該 use case的實際用戶一起工作； 在與用戶的交談中，通常需要記錄他們對該 use case 的 理解； 與用戶討論建議方案，并請他們復(fù)審 use case描述。 以事件流描述 Use Case所采用的結(jié)構(gòu) 一個 use case 可以被認(rèn)為有一個開始狀態(tài)，一些中間 狀態(tài)，并從一個狀態(tài)轉(zhuǎn)換為另一狀態(tài)，如下所示： 其中， ? 紅箭頭線表示基本路徑，曲線是其它路徑。 一般來說，這樣的一條路徑應(yīng)該包含系 統(tǒng)不大需要的一些例外和異常處理。 ? 定義所要求的次序，即給出其中的動作必須以該次序予以 執(zhí)行。 ? 給出那些基本路徑之外的可選路徑的描述。 注意：在 usecase 描述中，我們必須顯式地描述系統(tǒng)做什么 （執(zhí)行的動作） ， 以及 actor做什么。 ? 一致的 . 我們才可以說，結(jié)束了 use case的描述。 ? 相關(guān)的技術(shù) 為此，需要使用更結(jié)構(gòu)化的描述技術(shù)，這樣的技術(shù)一般使 用可視化的建模技術(shù)，來描述 use cases 。 ?交互圖 用于描述一個 use case的實例如何與 actor 的一個實例 進(jìn)行交互。 建議： 應(yīng)謹(jǐn)慎地使用這些圖，在一般情況下，應(yīng)采用 use case的 正文描述（即事件流描述）。 注：如何進(jìn)行以上三步，可參見有關(guān)文獻(xiàn)。 ? 抽取 use case描述中附加的或可選的（ additional or optional）功能，它們可能被擴(kuò)展為特定 use case描述。有時， use case規(guī)約人員需要給出它的描述；在后續(xù)的分析和設(shè)計中， use case需要用不同的 usecase細(xì)化（ realization）予以細(xì)化。這一精化，如果需要的話，是以面向?qū)ο箫L(fēng)格將由 use cases所定義的功能作為概念分析層面上對象之間的協(xié)作，以便產(chǎn)生對需求的深入理解 . 總結(jié) 需求獲取 ? 需求獲取以及相關(guān)制品 work to be done result artifacts List candidate requirements Feature list Understand system context Business or domain model Capture functional requirements Use case model Capture nonfunctional Supplementary requirements requirements or individual use cases (for use case specific req.) ?業(yè)務(wù)模型或領(lǐng)域模型 建立了系統(tǒng)的語境，是創(chuàng)建系 統(tǒng) use case 模型的基礎(chǔ)。即： UseCase system UseCase model Actor Use case * * 1 The UseCase model and its contents. The UseCase system denotes the toplevel package of the model ? usecase 模型捕獲了功能需求。 ?捕獲需求階段的活動 序號 輸入 活動 執(zhí)行者 輸出 1 業(yè)務(wù)模型或領(lǐng)域模型 ,補(bǔ)充需求 , 特征表 發(fā)現(xiàn)參與者和用況 系統(tǒng)分析員 、 客戶、 用戶 、 其他分析員 用況模型 概述， 術(shù)語表 2 用況模型 概述 ， 補(bǔ)充需求 ， 術(shù)語表 賦予用況優(yōu)先級 體系結(jié)構(gòu)設(shè)計者 體系結(jié)構(gòu)描述 用況模型角度 3 用況模型 概述 ， 補(bǔ)充需求 ， 術(shù)語表 細(xì)化用況 用況描述者 用況 詳述 4 用況 詳述 ， 用況模型概述 ， 補(bǔ)充需求 ， 術(shù)語表 人機(jī)接口原型化 人機(jī)接口設(shè)計者 人機(jī)接口原型 5 用況 詳述 ， 用況模型概述 ， 補(bǔ)充需求 ， 術(shù)語表 構(gòu)造用況模型 系統(tǒng)分析員 用況模型 詳述 需求分析 實際問題 ？ 需求獲取模型 形成 ？ 需求分析模型 形成 需求獲取 需求分析 注：實現(xiàn)第二次抽象 注：實現(xiàn)第一次抽象 1) 需求分析層的術(shù)語 ?分析類（ Analysis class） ?Use Case細(xì)化（ Use Case RealizationAnalysis） ?分析包（ Analysis Package） ? 分析類（ Analysis class） 一個分析類抽象地表達(dá)了 系統(tǒng)設(shè)計中 的一個或多個類和 /或子系統(tǒng)。一 個責(zé)任是高內(nèi)聚的一組由類所定義的行為的正文描述。 目的：使分析類在問題域中更加突出，與設(shè)計和實現(xiàn)中的類相比，粒度大，是概念性的。 基于的設(shè)計原理 ：分離用戶界面或通訊界面中的變化，形成一個或 多個邊界類。 與設(shè)計平臺的關(guān)系 ： 實體類一般表示一個邏輯數(shù)據(jù)結(jié)構(gòu)和屬性，以理解系統(tǒng)依賴什么信息。 基于的設(shè)計原理 ： 問題分離 控制類分離一些在控制方面、協(xié)調(diào)方面、定序方面以及復(fù)雜業(yè)務(wù)邏輯方面的變化，并予以封裝，形成所謂的控制類，其中一般要涉及其他一些對象。 實體類 封裝了問題域中的實體概念 控制類 封裝了一些重要的定序（ sequences），涉及多個 成分，例如協(xié)調(diào)有意義的 usecase細(xì)化。 ?由于 是針對功能需求和問題域予以創(chuàng)建的，因此對具有領(lǐng) 域知識的人來說，是可以閱讀、理解的。 作用 ： UseCase 細(xì)化對 usecase模型中的一個特定的 use case 提供了一中直接方式的跟蹤。 分析模型包含以下元素： ?分析包和服務(wù)包，以及它們的依賴和內(nèi)容。 ? Usecase細(xì)化 分析 ，描述了如何利用分析模型中協(xié)作，來精 化 use case和相關(guān)的特殊需求。這一體系結(jié)構(gòu)上 的視覺，將一些變化局部到體