【正文】 這一體系結(jié)構(gòu)上 的視覺(jué)，將一些變化局部到體系結(jié)構(gòu)中。 分析模型包含以下元素： ?分析包和服務(wù)包，以及它們的依賴和內(nèi)容。 ?由于 是針對(duì)功能需求和問(wèn)題域予以創(chuàng)建的，因此對(duì)具有領(lǐng) 域知識(shí)的人來(lái)說(shuō)，是可以閱讀、理解的。 基于的設(shè)計(jì)原理 ： 問(wèn)題分離 控制類分離一些在控制方面、協(xié)調(diào)方面、定序方面以及復(fù)雜業(yè)務(wù)邏輯方面的變化，并予以封裝，形成所謂的控制類，其中一般要涉及其他一些對(duì)象。 基于的設(shè)計(jì)原理 ：分離用戶界面或通訊界面中的變化，形成一個(gè)或 多個(gè)邊界類。一 個(gè)責(zé)任是高內(nèi)聚的一組由類所定義的行為的正文描述。即： 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 模型捕獲了功能需求。有時(shí)， use case規(guī)約人員需要給出它的描述；在后續(xù)的分析和設(shè)計(jì)中， use case需要用不同的 usecase細(xì)化（ realization）予以細(xì)化。 注：如何進(jìn)行以上三步，可參見(jiàn)有關(guān)文獻(xiàn)。 ?交互圖 用于描述一個(gè) use case的實(shí)例如何與 actor 的一個(gè)實(shí)例 進(jìn)行交互。 ? 一致的 . 我們才可以說(shuō)，結(jié)束了 use case的描述。 ? 給出那些基本路徑之外的可選路徑的描述。 一般來(lái)說(shuō)，這樣的一條路徑應(yīng)該包含系 統(tǒng)不大需要的一些例外和異常處理。 其中規(guī)約人員應(yīng)當(dāng)： 緊密地與該 use case的實(shí)際用戶一起工作； 在與用戶的交談中，通常需要記錄他們對(duì)該 use case 的 理解； 與用戶討論建議方案，并請(qǐng)他們復(fù)審 use case描述。并給出在這一 視覺(jué)下的體系結(jié)構(gòu)描述。 注意： 一個(gè) use case 實(shí)例，例如電話呼叫，可能涉及多個(gè) actor. 在這種情況中，應(yīng)當(dāng)應(yīng)用 “ 可見(jiàn)的結(jié)果值 ” 這一準(zhǔn)則，啟動(dòng) actor （ to initiating actor） . “結(jié)果（值） ‘ result of value ?” 這一準(zhǔn)則，可以幫助我們避免使發(fā)現(xiàn)的 use cases 太小。 actor 可能還要通知系統(tǒng)一些外部事件，包括已經(jīng)發(fā)生的 一些事件，例如：發(fā)票已經(jīng)過(guò)期。 (2) 發(fā)現(xiàn) Use Case的方法 ?當(dāng)開(kāi)始點(diǎn)是一個(gè)業(yè)務(wù)模型時(shí) 一旦我們發(fā)現(xiàn)了一個(gè)工作人員或業(yè)務(wù) actor的所有角色， 標(biāo)識(shí)一些暫時(shí)的 use case最直接的方法是： 對(duì)每一工作人員和業(yè)務(wù) actor 的每一角色，對(duì)應(yīng)地創(chuàng)建 一個(gè) use case。 例如， use case 實(shí)例 Withdraw money The use case Withdraw money enables instances of the actor Bank Customer to withdraw money through an ATM 因此 ? 對(duì)一個(gè) use case的描述可以使用正文事件流、狀態(tài)圖、活動(dòng) 圖、通訊圖和順序圖。 ?在確定系統(tǒng) actors 時(shí)可用的 2條準(zhǔn)則： 第一條準(zhǔn)則：至少要識(shí)別出一個(gè)用戶，可以扮演候選的 actor。 Business entities 和 work unit 用于表達(dá)同一類概念，作為 領(lǐng)域類，例如定單，欄目，發(fā)票等。 ?事件（ Events）：例如飛機(jī)到達(dá)，飛機(jī)起飛等。 ? 估算的實(shí)現(xiàn)成本。 要做的工作 產(chǎn)生的制品 列出候選的需求 特征（ Feature）列表 理解系統(tǒng)語(yǔ)境 領(lǐng)域模型或業(yè)務(wù)模型 捕獲功能需求 Use case 模型 捕獲非功能需求 補(bǔ)充需求或針對(duì)一些特定需求 的 use cases ?特征（ Feature） : 一個(gè)功能項(xiàng)（ function item ）以及相關(guān)的簡(jiǎn)要描述 稱為特征（ feature）。 注：這 4個(gè)階段是演化模型的一個(gè)變體。 “距離” 語(yǔ) 言 網(wǎng)絡(luò) 異構(gòu) VB、 VC 程序設(shè)計(jì)環(huán)境 中間件技術(shù)與產(chǎn)品 面向領(lǐng)域的軟件體系結(jié)構(gòu) 應(yīng)用框架 領(lǐng)域軟件生產(chǎn)線 系統(tǒng)建模 運(yùn)行平臺(tái) 開(kāi)發(fā)平臺(tái) 軟件工程學(xué)科所要解決的問(wèn)題 軟件開(kāi)發(fā)的本質(zhì) 可概括為： 第一點(diǎn)： 問(wèn)題空間的概念 與 解空間的模型化概念 之間的映射 例如：對(duì)象 = F（張山） （ 模型化概念 ） （ 問(wèn)題空間的概念 ） 其中， 對(duì)應(yīng)的過(guò)程：需求分析 使用的技術(shù)：面向?qū)ο? 使用的原理：數(shù)據(jù)抽象 目的：作為計(jì)算的客體。 第二點(diǎn)： 問(wèn)題空間的處理邏輯 與 解空間處理邏輯 之間的映射 例如 1： 加工 1（ 及相關(guān)的數(shù)據(jù)流 ） =F（ 計(jì)算學(xué)生成績(jī) ） 其中：使用的方法：結(jié)構(gòu)化方法； 對(duì)應(yīng)的過(guò)程：需求分析 使用的原理：過(guò)程抽象 加工 1 計(jì)算學(xué)生平均成績(jī) 科目 +年級(jí) /班 學(xué)生成績(jī)文件 學(xué)生平均成績(jī) 規(guī)約后的處理邏輯 例如 2： 交互圖 1=H（ 計(jì)算學(xué)生成績(jī) ） 其中：對(duì)應(yīng)的過(guò)程：需求分析 使用的方法：面向?qū)ο? 使用的原理：行為結(jié)構(gòu)抽象 （ 簡(jiǎn)稱 行為抽象 ） 作用：作為計(jì)算規(guī)則 ：教務(wù)員 ：教員 遞交 A科學(xué)生成績(jī)表 A科學(xué)生成績(jī)表 ：教學(xué)主任 求 A科平均 A科平均 由于以上兩個(gè)映射是由 “ 人 ” 完成的 ， 因此 就軟件開(kāi)發(fā)而言 ， 需要解決兩個(gè)方面的問(wèn)題： 1：技術(shù) 2：管理 進(jìn)一步說(shuō) ， 技術(shù)問(wèn)題主要是指軟件開(kāi)發(fā)過(guò)程通常需 要遵循的 途徑 和 方向 其中 ， 過(guò)程方向 確定用于創(chuàng)建問(wèn)題模型和設(shè)計(jì)解的 特定的抽象層次 例如 ， 需求 、 設(shè)計(jì) 、 實(shí)現(xiàn) 、 部署等 問(wèn)題空間 需求 一個(gè)抽象層 設(shè)計(jì) 一個(gè)抽象層 實(shí)現(xiàn) 一個(gè)抽象層 部署 一個(gè)抽象層 特定的 notation 特定的 notation 特定的 notation 特定的 notation 驗(yàn) 證 / 確 認(rèn) 問(wèn)題空間 需求 一個(gè)抽象層 設(shè)計(jì) 一個(gè)抽象層 實(shí)現(xiàn) 一個(gè)抽象層 部署 一個(gè)抽象層 特定的 notation 特定的 notation 特定的 notation 特定的 notation 驗(yàn) 證 / 確 認(rèn) 它們體現(xiàn)了我們所說(shuō)的一些軟件設(shè)計(jì)原理 過(guò)程途徑 實(shí)現(xiàn)不同抽象層次的映射 ？ ？ ？ ？ ？ ？ ？ ？ 典型的途徑有： 結(jié)構(gòu)化方法 面向數(shù)據(jù)結(jié)構(gòu)方法 面向?qū)ο蠓椒ㄒ约? 維也納開(kāi)發(fā)方法 （ VDM） 等 注：主要講解結(jié)構(gòu)化方法和面向?qū)ο蠓椒?。 由上可見(jiàn)： USDP對(duì)于如何運(yùn)用 UML的概念進(jìn)行軟件開(kāi)發(fā)提供了詳細(xì)指導(dǎo) 。作為需求 , 并被轉(zhuǎn)換為其它制品。 ( 所需的資源類型和人 /時(shí)）。 一般來(lái)說(shuō)，領(lǐng)域模型是以類圖予以描述的。 每一個(gè) 業(yè)務(wù) use case的細(xì)化可以通過(guò)交互圖和活動(dòng)圖予以 表示。 該準(zhǔn)則將幫助我們僅發(fā)現(xiàn)那些相關(guān)的 actors，避免 actor 僅是一些想象的 “ 事物 ” 。 ? 在一個(gè) use case中的一條路徑，可以看作： ? 啟動(dòng)了該 use case實(shí)例，并使之處于一個(gè)開(kāi)始狀態(tài)； ? 該狀態(tài)由一個(gè)外部的 actor所引發(fā)（ invoke）；并由一個(gè) 動(dòng)作序列的執(zhí)行，使之轉(zhuǎn)化為另一狀態(tài)。 因此， ?針對(duì)每一 業(yè)務(wù) use case ,為每一工作人員和業(yè)務(wù) actor，設(shè)置 一個(gè) use case。 還可能存在一些其他的 actors ，他們執(zhí)行系統(tǒng)的啟動(dòng)、終 止和維護(hù)。 ?特定的 actor ( particular actor) 通過(guò)使標(biāo)識(shí)的 use cases 都有相應(yīng)的真實(shí)用戶，這樣可以確保不會(huì)太大。 （注：其中必須與項(xiàng)目經(jīng)理一起來(lái)工作。 有效技術(shù)：事件流技術(shù) 關(guān)于事件流（ Flow of Events）的作用 ： ?當(dāng)所規(guī)約的 use case執(zhí)行時(shí)，事件流規(guī)約了系統(tǒng)做什么。 ? 接之，在另一節(jié)中描述其余的可選路徑 其中，有些可選的路徑是很小的，是否可以把它作為基本 路徑的組成部分還是在一個(gè)獨(dú)立的一節(jié)中作為可選路徑予以 描述，這是一個(gè)設(shè)計(jì)決策問(wèn)題，取決于該描述是否精確，是 否容易閱讀。 ?定義與 actors 的系統(tǒng)交互以及它們之間的交換 (Step 2 and Step 3)，即描述該 use case 動(dòng)作序列，這些動(dòng)作是如何被 相關(guān)的 actors予以激發(fā)（ invoke）以及它們是如何執(zhí)行的， 以響應(yīng) actor的要求。 該描述可以在需求捕獲結(jié)束的復(fù)審會(huì)中，由分析員予以評(píng)估，也可以由用戶和客戶予以評(píng)估。為此，交互圖給出了 use case 以及參與的 actor（ s）。 (7) Use Case 模型的結(jié)構(gòu)化 前置條件 : ?系統(tǒng)分析員已經(jīng)標(biāo)識(shí)了 actors 和 use cases, 已經(jīng)以 圖予以了描述，并給出了整個(gè) use case 模型的說(shuō)明。為此， use cases不應(yīng)太小或太多，從而需要對(duì)use case結(jié)構(gòu)化工作予以有效地管理。非功能需求特定于單個(gè)的 use case，其 規(guī)約具有一般性，并不針對(duì)一個(gè)特定的 use case 。 ? 分析類的屬性也是在很高層次上定義的。 分析類的種類：通常具有三種：邊界類 （ Boundary classes） , 實(shí)體類 （ Entity classes）， 控制類 （ Control classes） . 實(shí)體類（ Entity classes） : 內(nèi)涵 ：用于對(duì)那些需要長(zhǎng)期足留系統(tǒng)的模型化對(duì)象以及與行為相關(guān)的某些 現(xiàn)象進(jìn)行建模，例如人的信息以及實(shí)際的一個(gè)事件。而 不能封裝那些與 actors交互有關(guān)的問(wèn)題（由邊界類予以封裝）。 ?很有可能成為一些子系統(tǒng)或成為一些子系統(tǒng)的組成部分。 其中： 分析包可以把一些變化局部到一個(gè)業(yè)務(wù)過(guò)程、一個(gè) actor的 行為，或一組緊密相關(guān)的 use cases 。 3） 分析階段的