軟件體系結(jié)構(gòu)SoftwareArchitectu.ppt

1、軟件體系結(jié)構(gòu)(Software Architecture,講義13：統(tǒng)一軟件開發(fā)過程（RUP,一、引言,為屏蔽計(jì)算機(jī)硬件的異構(gòu)性，發(fā)展了操作系統(tǒng),C/C+ 語(yǔ)言,Java 語(yǔ)言,支撐軟件中間件,為屏蔽操作系統(tǒng)和編程語(yǔ)言的異構(gòu)性，發(fā)展了支撐軟件和中間件,Fortran 語(yǔ)言,為了禰補(bǔ)應(yīng)用軟件與現(xiàn)實(shí)計(jì)算環(huán)境之間的距離,應(yīng)用系統(tǒng),網(wǎng) 絡(luò) 層,綜觀 軟件技術(shù) 的發(fā)展,應(yīng)用系統(tǒng),概念不同，邏輯不同。 解決問題的思維邏輯 不同。 -“距離,語(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),開發(fā)平臺(tái),軟件工程學(xué)科所要解決的

2、問題,軟件開發(fā)的本質(zhì) 可概括為： 第一點(diǎn)： 問題空間的概念 與 解空間的模型化概念 之間的映射 例如：對(duì)象 = F（張山） （模型化概念） （問題空間的概念） 其中， 對(duì)應(yīng)的過程：需求分析 使用的技術(shù)：面向?qū)ο?使用的原理：數(shù)據(jù)抽象 目的：作為計(jì)算的客體,第二點(diǎn)：?jiǎn)栴}空間的處理邏輯 與 解空間處理邏輯 之間的映射 例如1： 加工1（及相關(guān)的數(shù)據(jù)流）=F（計(jì)算學(xué)生成績(jī)） 其中：使用的方法：結(jié)構(gòu)化方法； 對(duì)應(yīng)的過程：需求分析 使用的原理：過程抽象,加工1 計(jì)算學(xué)生平均成績(jī),科目+年級(jí)/班,學(xué)生成績(jī)文件,學(xué)生平均成績(jī),規(guī)約后的處理邏輯,例如2： 交互圖1=H（計(jì)算學(xué)生成績(jī)） 其中：對(duì)應(yīng)的過程：需求分

3、析 使用的方法：面向?qū)ο?使用的原理：行為結(jié)構(gòu)抽象（簡(jiǎn)稱行為抽象） 作用：作為計(jì)算規(guī)則,教務(wù)員,教員,遞交A科學(xué)生成績(jī)表,A科學(xué)生成績(jī)表,教學(xué)主任,求A科平均,A科平均,由于以上兩個(gè)映射是由“人”完成的，因此 就軟件開發(fā)而言，需要解決兩個(gè)方面的問題： 1：技術(shù) 2：管理 進(jìn)一步說，技術(shù)問題主要是指軟件開發(fā)過程通常需 要遵循的途徑和方向 其中，過程方向 確定用于創(chuàng)建問題模型和設(shè)計(jì)解的 特定的抽象層次 例如，需求、設(shè)計(jì)、實(shí)現(xiàn)、部署等,問題空間,需求-一個(gè)抽象層,設(shè)計(jì)-一個(gè)抽象層,實(shí)現(xiàn)-一個(gè)抽象層,部署-一個(gè)抽象層,特定的notation,特定的notation,特定的notation,特定的not

4、ation,驗(yàn) 證/ 確 認(rèn),問題空間,需求-一個(gè)抽象層,設(shè)計(jì)-一個(gè)抽象層,實(shí)現(xiàn)-一個(gè)抽象層,部署-一個(gè)抽象層,特定的notation,特定的notation,特定的notation,特定的notation,驗(yàn) 證/ 確 認(rèn),它們體現(xiàn)了我們所說的一些軟件設(shè)計(jì)原理,過程途徑 實(shí)現(xiàn)不同抽象層次的映射,典型的途徑有： 結(jié)構(gòu)化方法 面向數(shù)據(jù)結(jié)構(gòu)方法 面向?qū)ο蠓椒ㄒ约?維也納開發(fā)方法（VDM）等 注：主要講解結(jié)構(gòu)化方法和面向?qū)ο蠓椒?RUP的本質(zhì)及特點(diǎn) (1) 是一種迭代的、以架構(gòu)為中心的、用例驅(qū)動(dòng)的軟件開發(fā)方法 (2) 是一種具有明確定義和結(jié)構(gòu)的軟件工程過程，包括規(guī)定了人員的職責(zé)、如何完成各項(xiàng)工作以及

5、何時(shí)完成各項(xiàng)工作。還提供了軟件開發(fā)生命周期的結(jié)構(gòu)，明確定義了主要里程碑和決策的關(guān)系 (3) 是一個(gè)過程產(chǎn)品，提供了可定制的軟件工程的過程框架。可以適用于于不同規(guī)模的開發(fā)團(tuán)隊(duì)和規(guī)范程度不同的開發(fā)方法,RUP的基本原理 盡早并且不斷化解重大的風(fēng)險(xiǎn) 確保滿足客戶的需求 把注意力放到可執(zhí)行軟件上 盡早在項(xiàng)目中適應(yīng)變化 在早期確定一個(gè)可執(zhí)行的架構(gòu) 使用構(gòu)件構(gòu)造系統(tǒng) 建立高效的開發(fā)團(tuán)隊(duì),突出特點(diǎn)是： Use Case 驅(qū)動(dòng)的、 以體系結(jié)構(gòu)為中心的、 迭代、增量的開發(fā),何謂 USE CASE 驅(qū)動(dòng),USE CASE,分 析,輸入,設(shè) 計(jì),實(shí) 現(xiàn),跟蹤,輸入,跟蹤,輸入,跟蹤,輸入,輸入,測(cè) 試,輸入,跟蹤,

6、輸入,從USE CASE模型的視覺,從分析模型的視覺,從設(shè)計(jì)模型的視覺,從實(shí)現(xiàn)模型的視覺,從部署模型的視覺,給 出,體 系 結(jié) 構(gòu),描 述,何謂以體系結(jié)構(gòu)為中心,階 段,核心工作流,何謂迭代、增量的開發(fā),初始階段（the inception phase）的基本目標(biāo)是： -了解項(xiàng)目的范圍 -建立業(yè)務(wù)模型 -得到涉眾的認(rèn)可 換言之，其目標(biāo)是：建立該項(xiàng)目的生存周期目標(biāo) （objectives,精化階段（ the elaboration phase）的基本目標(biāo)是 -建立體系結(jié)構(gòu)基線 -捕獲大多數(shù)的需求 -降低主要的技術(shù)風(fēng)險(xiǎn) -減少次要的錯(cuò)誤風(fēng)險(xiǎn)，即建立生存周期體系結(jié)構(gòu) （ the life cycle

7、 architecture）. 到該階段末，就能夠估算成本、進(jìn)度，并能詳細(xì)地 規(guī)劃構(gòu)造階段（ the construction phase,構(gòu)造階段（ the construction phase）的基本目標(biāo)是： -開發(fā)完整的系統(tǒng) -確保產(chǎn)品可以開始向客戶交付, 即具有初始操作能力。 交付階段（ the transition phase）的基本目標(biāo)是： -確保有一個(gè)實(shí)在的產(chǎn)品，發(fā)布給用戶群。 期間，培訓(xùn)用戶如何使用該軟件。 注：這4個(gè)階段是演化模型的一個(gè)變體,由上可見：USDP對(duì)于如何運(yùn)用UML的概念進(jìn)行軟件開發(fā)提供了詳細(xì)指導(dǎo)。即： 指導(dǎo)開發(fā)隊(duì)伍安排其開發(fā)活動(dòng)的次序； 為各開發(fā)者和整個(gè)開發(fā)組指

8、定任務(wù)； 明確地規(guī)定需要開發(fā)的制品； 提供對(duì)項(xiàng)目中的制品和活動(dòng)進(jìn)行監(jiān)控與度量的準(zhǔn)則,1）需求獲取的目標(biāo) 對(duì)大系統(tǒng)的開發(fā)來說，需求一般包括需求獲取和需求分析 需求獲取的目標(biāo)是： 需求分析的目標(biāo)是,客觀問題（系統(tǒng),系統(tǒng)需求獲取模型,形成-涉及：不同概念和不同處理邏輯,形成-涉及：不同概念和不同處理邏輯,系統(tǒng)分析模型,描述系統(tǒng)需求獲取模型,體系結(jié)構(gòu)描述 -USE CASE模型,體系結(jié)構(gòu)描述 -Analysis模型,實(shí)現(xiàn)需求獲取目標(biāo)的基本途徑 實(shí)現(xiàn)需求獲取的目標(biāo)，即實(shí)現(xiàn)實(shí)際問題到軟件開發(fā)需求獲取層的映射，從軟件開發(fā)的角度-實(shí)現(xiàn)第一次抽象。其中至少涉及以下3個(gè)問題： 如何定義需求獲取層，即給出該層的術(shù)語(yǔ)

9、； 如何確定模型表示工具； 如何映射,實(shí)際問題,需求獲取層,模型表示 工具,注：這些概念體現(xiàn)了一些設(shè)計(jì)原理,1）需求獲取層的術(shù)語(yǔ)（概念） USE CASE actor 以及 4個(gè)表達(dá)關(guān)系的概念：關(guān)聯(lián)、包含、擴(kuò)展、泛化。 以及USE CASE圖,實(shí)際問題,模型表示 工具 -USE CASE圖,體系結(jié)構(gòu)描述 -USE CASE模型,2） 需求工作流,實(shí)際問題,需求獲取模型 -（USE CASE 模型,形成,體系結(jié)構(gòu)描述 -USE CASE模型,形成,2.1 需求工作流及所創(chuàng)建的制品 一般來說，需求工作流包括以下四步，但它們并非是嚴(yán)格 分離的,要做的工作 產(chǎn)生的制品 -列出候選的需求 特征（Feat

10、ure）列表 -理解系統(tǒng)語(yǔ)境 領(lǐng)域模型或業(yè)務(wù)模型 -捕獲功能需求 Use case 模型 -捕獲非功能需求 補(bǔ)充需求或針對(duì)一些特定需求 的use cases,特征（Feature）: 一個(gè)功能項(xiàng)（function item ）以及相關(guān)的簡(jiǎn)要描述 稱為特征（ feature）。作為需求, 并被轉(zhuǎn)換為其它制品,應(yīng)用系統(tǒng),潛在的抽象層,例如：按學(xué)科計(jì)算每一學(xué)生的期末考試平均成績(jī)。 統(tǒng)計(jì)2科以上不及格的人數(shù)。 給出各分段（0-60，60-85，85-100）的人數(shù)分布情況,feature,作為需求, 被轉(zhuǎn)換為其它制品,應(yīng)用系統(tǒng),潛在的抽象層 （特征層,一個(gè)抽象層 （ USE CASE 層,USE CA

11、SE1,USE CASE,USE CASE2,USE CASE3,制品：USE CASE模型,規(guī)約,規(guī)約,形成,Actor,關(guān)聯(lián),關(guān)于特征的幾點(diǎn)說明： -每一特征有一個(gè)簡(jiǎn)短的名字和簡(jiǎn)要的說明或定義。 -每一特征還有一組對(duì)規(guī)劃有意義的信息，可以包括： 狀態(tài)（ Status），例如 ，提交，批準(zhǔn)，確認(rèn) 是組成的等。 估算的實(shí)現(xiàn)成本。( 所需的資源類型和人/時(shí)）。 優(yōu)先級(jí)（Priority）(e.g.,critical, important, or ancillary)。 實(shí)現(xiàn)中相聯(lián)的風(fēng)險(xiǎn)等級(jí),業(yè)務(wù)模型或領(lǐng)域模型 領(lǐng)域模型 領(lǐng)域模型捕獲了系統(tǒng)語(yǔ)境中的一些重要對(duì)象類型。其中領(lǐng)域 對(duì)象表示 系統(tǒng)工作環(huán)境

12、中存在的事物或發(fā)生的事件。 一般來說，領(lǐng)域類以三種形態(tài)出現(xiàn)： 業(yè)務(wù)對(duì)象：表示那些被業(yè)務(wù)所操縱（ manipulate）的事物 （ thing），例如定單，帳目和合同等。 實(shí)在對(duì)象（Real-world objects）和概念：例如 飛機(jī)， 火箭等。 事件（Events）：例如飛機(jī)到達(dá)，飛機(jī)起飛等。 一般來說，領(lǐng)域模型是以類圖予以描述的,Order date of submission delivery address,Item description picture cost,Invoice amount date of submission last date of payment,Acco

13、unt balance owner,1.* payable,1.,buyer 1,seller 1,A class diagram in a domain model, capturing the most important concepts in the context of the system,Example: Domain Classes Order, Invoice, Item, and Account,業(yè)務(wù)模型 業(yè)務(wù)模型可以分為以下2個(gè)層次： 業(yè)務(wù) use case 模型 通過業(yè)務(wù)use case和業(yè)務(wù) actors 來描述業(yè)務(wù)過程，他們分別 對(duì)應(yīng)業(yè)務(wù)過程（business pr

14、ocesses）和客戶（customers ）。 一般來說，業(yè)務(wù) use case 模型 是以u(píng)se case 圖予以描述的. 業(yè)務(wù)對(duì)象模型 業(yè)務(wù)對(duì)象模型是一個(gè)業(yè)務(wù)的內(nèi)部（interior）模型。描述每 一個(gè)業(yè)務(wù)use case 是如何通過一組workers 、business entities 、 work units予以細(xì)化的,其中， Business entity 表示某些事物（ something）,例如 一張發(fā)票。 它們?cè)谝粋€(gè)業(yè)務(wù)use case中被使用之。 A work unit 是這樣實(shí)體的一個(gè)集合，對(duì)最終用戶 而言，形成了可認(rèn)知的整體。 Business entities 和

15、work unit 用于表達(dá)同一類概念，作為 領(lǐng)域類，例如定單，欄目，發(fā)票等。 每一個(gè)業(yè)務(wù)use case的細(xì)化可以通過交互圖和活動(dòng)圖予以 表示,以 use case 捕獲需求 Use-Case 模型 Use-Case 模型 用以表達(dá)客戶認(rèn)可的需求-系統(tǒng)必須 滿足的條件和能力。 Use-Case模型 作為客戶和開發(fā)人員之間的一種共識(shí)。 Use-Case 模型是一個(gè)系統(tǒng)的一種模型，包括 actors、 use cases 以及它們之間的關(guān)系,Use-Case system,Use-Case model,Actor,Use case,1,The Use-Case system denotes th

16、e top-level package of the model,Use-Case 模型以及其內(nèi)容,參與需求工作流的有關(guān)人員,System Analysis,responsible for,Use-case Specifier,responsible for,User-interface designer,responsible for,Architect,responsible for,use case model,Actor Glossary,Use case,User interface prototype,Architecture Description,需求捕獲工作流中的活動(dòng) 1、發(fā)

17、現(xiàn)并描述Actor （1）發(fā)現(xiàn) Actor的方法 發(fā)現(xiàn) actor的這一任務(wù)，依賴于起始點(diǎn)： - 當(dāng)存在業(yè)務(wù)模型時(shí) 可以直接地發(fā)現(xiàn)一些候選的 actors，即： 對(duì)于業(yè)務(wù)中的每一個(gè)工作人員，可以建議一個(gè)候選的 actor 對(duì)于每一個(gè)將要使用該信息系統(tǒng)的業(yè)務(wù)actor （即每一個(gè)業(yè)務(wù)客戶）， 可以建議候選的一個(gè) actor。 - 當(dāng)有或沒有領(lǐng)域模型時(shí) 分析人員就要與客戶一起標(biāo)識(shí) actor，并將所標(biāo)識(shí) actor進(jìn)行分類，形成 一些候選的 actors。 Note:還要標(biāo)識(shí)表示外部系統(tǒng)的actor和系統(tǒng)維護(hù)和運(yùn)行所需要的actor,在確定系統(tǒng)actors 時(shí)可用的2條準(zhǔn)則： 第一條準(zhǔn)則：至少要識(shí)

18、別出一個(gè)用戶，可以扮演候選的 actor。 該準(zhǔn)則將幫助我們僅發(fā)現(xiàn)那些相關(guān)的actors，避免 actor 僅是一些想象的“事物”。 第二條準(zhǔn)則：系統(tǒng)中不同actors 實(shí)例之間，其角色的重疊 應(yīng)是最少的。 如果2個(gè)或多個(gè)actors有著幾乎相同的角色，那么就應(yīng)該 考慮： 是否將這些角色組合到一個(gè)actor的角色中，或 是否需要發(fā)現(xiàn)另外一個(gè)“一般化”的actor，使之具有那些 重疊的、公共的角色 ，并可以通過“泛化”，形成那些特 定actor,2）Actors的命名與描述 Actors的命名： 對(duì)actors給出恰當(dāng)?shù)拿质欠浅Ｖ匾摹＿@樣的名字可以 “傳達(dá)”（ convey）所期望的語(yǔ)義。

19、Actors的描述： 對(duì)actor的描述，應(yīng)包含其角色（責(zé)任）以及為了完成其 責(zé)任所需要的條件,例如: the Buyer, Seller,and Accounting System Actors Buyer A Buyer represents a person who is responsible for buying goods or services as described in the business use case Sales: from Order to Delivery. This person may be an individual or someone within

20、 a business organization. The Buyer of goods and services need the Billing and Payment System to send order and to pay invoices,Seller A Seller represents a person who sells and delivers goods or services. The Seller uses the system to look for new orders and to send order confirmations, invoices, a

21、nd payment reminders,Accounting System The Billing and Payment System sends verifications of transactions to the Accounting System,Order Goods or Services,Confirm Order,Invoice Buyer,Pay Invoice,Perform Transaction,Pay Overdraft Fee,Send Reminders,extend,Initiator,Initiator,Initiator,Initiator,Initi

22、ator,Buyer,Seller,Accounting system,Use case in the Billing and Payment System that support the business use case Sales:From Order to Delivery. The role initiator, attached to the associations, indicate which actor starts the use case,2、發(fā)現(xiàn)并描述 Use Case (1) 對(duì) use case的回顧 A use case specifies a sequenc

23、e of actions, including alternatives of the sequence , that the system can perform , interacting with actor of the system. actor 使用系統(tǒng)的每一方法（ way ），被表示為一個(gè)use case Use case 是系統(tǒng)向它的actors 提供結(jié)果（值）的功能塊 （chunks ）。 例如， use case 實(shí)例,Withdraw money,The use case Withdraw money enables instances of the actor Bank

24、 Customer to withdraw money through an ATM,因此 對(duì)一個(gè) use case的描述可以使用正文事件流、狀態(tài)圖、活動(dòng) 圖、通訊圖和順序圖。 在一個(gè) use case中的一條路徑，可以看作： 啟動(dòng)了該use case實(shí)例，并使之處于一個(gè)開始狀態(tài)； 該狀態(tài)由一個(gè)外部的actor所引發(fā)（ invoke）；并由一個(gè) 動(dòng)作序列的執(zhí)行，使之轉(zhuǎn)化為另一狀態(tài)。其中該序列包含 內(nèi)部計(jì)算、路徑選擇和向某一 actor發(fā)送消息。 在一個(gè)新的狀態(tài)中，等待actor發(fā)送另一外部消息。 該狀態(tài)由一個(gè)新的消息予以引發(fā)（ invoke），以此繼續(xù)， 通過了許多狀態(tài)，直到該use case

25、實(shí)例被終止,大部分是一個(gè)actor實(shí)例引發(fā)一個(gè)use case實(shí)例， 但也可能由一個(gè)事件所引發(fā)，例如由系統(tǒng)之外的定時(shí)時(shí)鐘所引發(fā)。 Use case有其自己的屬性,例如 Withdraw money 這一use case 可以認(rèn)為它有屬性“帳目”（account）、存款數(shù)目（ amount to be withdrawn）等，這些值局部于一個(gè)use case實(shí)例 Use case實(shí)例不能與其它 use case 實(shí)例發(fā)生交互。 在 use case模型中，唯一的一類交互可以發(fā)生在 actor實(shí)例和use case 實(shí)例之間。這是由于我們把use case實(shí)例看作是原子的，每一個(gè)use case的

26、行為可以被其它 use case所中斷， 這就確保了我們可以理解一個(gè)特定的use case模型,2) 發(fā)現(xiàn)Use Case的方法 當(dāng)開始點(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,因此， 針對(duì)每一業(yè)務(wù) use case ,為每一工作人員和業(yè)務(wù) actor，設(shè)置 一個(gè) use case。 細(xì)化并調(diào)整這些暫時(shí)的use cases. 決策工作人員和業(yè)務(wù) actor 的那些任務(wù)應(yīng)該由系統(tǒng)自動(dòng)地 予以實(shí)現(xiàn)，作為use cases，并重新組織這些 u

27、se case，更好 地適應(yīng) actors的要求（ needs） 。 結(jié)論： 為參與業(yè)務(wù) use case細(xì)化（ realization）的、使用該信息系統(tǒng)的 每一工作人員的 每一角色，建議一個(gè)use case,當(dāng)開始點(diǎn)沒有業(yè)務(wù)模型時(shí) 要通過與客戶以及用戶一起工作來標(biāo)識(shí) use case。其中： 應(yīng)一個(gè)一個(gè)地審閱 actors, 為每一個(gè)actor建議一些侯選的 use case。 例如，可以與他們進(jìn)行交談，研究需要哪些 use case。 其中，均應(yīng)根據(jù)actor的需求來發(fā)現(xiàn) use case： - actor通常需要use cases來支持他們的工作： 創(chuàng)建、改變、跟蹤、遷移業(yè)務(wù)use c

28、ases中使用的業(yè)務(wù)對(duì)象， 例如定單和帳目。 -actor 可能還要通知系統(tǒng)一些外部事件，包括已經(jīng)發(fā)生的 一些事件，例如：發(fā)票已經(jīng)過期。 -還可能存在一些其他的actors ，他們執(zhí)行系統(tǒng)的啟動(dòng)、終 止和維護(hù),對(duì)發(fā)現(xiàn)的候選use cases 的初始處理： 根據(jù)以上發(fā)現(xiàn)的那些侯選的use cases， 為了使系統(tǒng)use cases容易修改、復(fù)審、測(cè)試和管理，應(yīng)考慮它們之間的組成關(guān)系。 為每一use cases 選擇一個(gè)名字（一般應(yīng)以動(dòng)詞開始），這個(gè)可以引導(dǎo)我們思考其中向actor產(chǎn)生值的特定動(dòng)作序列。用戶和系統(tǒng)的一個(gè)交互序列，可以在一個(gè)use case中予以規(guī)約，也可以在多個(gè)use case中予

29、以規(guī)約。 當(dāng)決定把一個(gè)侯選的use case 最終作為系統(tǒng)的一個(gè) use case 時(shí)，必須考慮：它是否是完整的 （complete）； 它是否是另一use case的組成部分,use case大小的確定 確定 use case的大小，有時(shí)是相當(dāng)困難的. 對(duì)此，必須了解： - use case 應(yīng)為它的actors產(chǎn)生相應(yīng)的值. -特別地，use case 向一個(gè)特定的actor交付了可見 的結(jié)果（值）. 以上的了解，可以指導(dǎo)我們合適的確定use case大小。 其中要注意2個(gè)關(guān)鍵詞： 結(jié)果（值）（ result of value ） 特定的actor（ particular actor,結(jié)果

30、（值） (result of value) 每一個(gè)成功執(zhí)行的 use case 應(yīng)向actor 提供一些值，使actor 達(dá)到某一目的。 注意：一個(gè) use case 實(shí)例，例如電話呼叫，可能涉及多個(gè) actor. 在這種情況中，應(yīng)當(dāng)應(yīng)用“可見的結(jié)果值”這一準(zhǔn)則，啟動(dòng)actor （to initiating actor）. “結(jié)果（值） result of value ” 這一準(zhǔn)則，可以幫助我們避免使發(fā)現(xiàn)的 use cases 太小,特定的actor ( particular actor) 通過使標(biāo)識(shí)的 use cases 都有相應(yīng)的真實(shí)用戶，這樣可以確保不會(huì)太大。 針對(duì)一些 actors,

31、我們第一次發(fā)現(xiàn)的 use cases 常常需要予以重新組織，重新評(píng)估，使之更加 “穩(wěn)定”。例如，一旦我們已經(jīng)有了一個(gè)體系結(jié)構(gòu)，那么對(duì)于我們捕獲的新的 use cases 就必須進(jìn)行調(diào)整，以便適應(yīng)已有的體系結(jié)構(gòu)。這樣，就有可能需要相當(dāng)大的變動(dòng),3) use case的簡(jiǎn)單描述 當(dāng)分析員標(biāo)識(shí)use case時(shí)，首先，一般要給出該use case的 名字。 繼之，對(duì)use case給出簡(jiǎn)單描述： 開始，用幾句話概括其中的動(dòng)作； 而后，對(duì)系統(tǒng)與其actor交互時(shí)要做的事情予以一步一 步地描述. 例如：描述 Pay Invoice Use Cases 概括動(dòng)作 The use case Pay Invo

32、ice is used by a Buyer to schedule invoice payments. The Pay Invoice use case then effects the payment on the due date,一步一步的描述 Before this use case can be initiated, the Buyer has already received an invoice (delivered by another use case called Invoice Buyer ) and has also received the goods or ser

33、vices ordered.,1. The buyer studies the invoice to pay and checks that it is consistent with the original order. 2. The Buyer schedules the invoice for payment by the bank. 3. On the day payment is due, the system checks to see if there is enough money in the Buyers account. If enough money is avail

34、able, the transaction is made,4) 確定use case的優(yōu)先級(jí)（ Priority） 目的 用于決定哪些use case在早期的迭代中予以開發(fā)（即分析、 設(shè)計(jì)、實(shí)現(xiàn)等），哪些use case在后期的迭代中予以開發(fā)。 輸入與輸出,Architect,Use Case model outlined,Supplementary Requirements,Glossary,Architecture Description view of the use case model,Prioritized Use Cases,視角與使用 視角：從體系結(jié)構(gòu)的視覺，來審視所建立的u

35、se case 模 型。并給出在這一視覺下的體系結(jié)構(gòu)描述。 （注：其中必須與項(xiàng)目經(jīng)理一起來工作。） 使用：由該視角形成的體系結(jié)構(gòu)，可以在規(guī)劃的一個(gè)迭代中 針對(duì)要開發(fā)什么時(shí)予以使用。其中，要注意：在這 一規(guī)劃中，還需要考慮其它非技術(shù)因素，例如系統(tǒng) 開發(fā)的業(yè)務(wù)和經(jīng)濟(jì)方面的因素,內(nèi)容：Use Case 模型視覺下的體系結(jié)構(gòu)描述，刻畫了在體 系結(jié)構(gòu)方面具有重要意義的use cases。包含： -某些重要、關(guān)鍵功能的use case ；或 -那些必須在軟件生存周期早期予以開發(fā)的某些重要 需求的use case,5）Detail a Use Case 目的 詳細(xì)地描述事件流，包括use case是怎樣開始

36、的，是怎樣結(jié)束 的，是怎樣與actors 進(jìn)行交互的。 輸入與輸出,Use case Specifier,Use Case model outlined,Supplementary Requirements,Glossary,Use Case detailed,Detail a Use Case,The result is a detailed description of a particular use case in text and diagram,細(xì)化途徑 涉及： 如何描述一個(gè) use case中所有可選的路徑； 在一個(gè) use case的描述中包括的內(nèi)容； 如何在必要時(shí)形式化地給出

37、use case的描述。 其中規(guī)約人員應(yīng)當(dāng)： -緊密地與該use case的實(shí)際用戶一起工作； -在與用戶的交談中，通常需要記錄他們對(duì)該use case 的 理解； -與用戶討論建議方案，并請(qǐng)他們復(fù)審use case描述,有效技術(shù)：事件流技術(shù) 關(guān)于事件流（Flow of Events）的作用： 當(dāng)所規(guī)約的use case執(zhí)行時(shí)，事件流規(guī)約了系統(tǒng)做什么。即每一個(gè)use case的事件流，可以作為use case的動(dòng)作序列的正文描述。 當(dāng)所規(guī)約的use case執(zhí)行時(shí)，事件流還規(guī)約了系統(tǒng)怎樣與其actors進(jìn)行交互 基本要求：從管理的角度來說，一個(gè)事件流的描述應(yīng)包括一組動(dòng)作序列，該組動(dòng)作序列適于修

38、改、復(fù)審、設(shè)計(jì)、實(shí)現(xiàn)和測(cè)試，并作為用戶手冊(cè)的一節(jié),以事件流描述Use Case所采用的結(jié)構(gòu) 一個(gè) use case 可以被認(rèn)為有一個(gè)開始狀態(tài)，一些中間 狀態(tài)，并從一個(gè)狀態(tài)轉(zhuǎn)換為另一狀態(tài)，如下所示,其中， 紅箭頭線表示基本路徑，曲線是其它路徑。 當(dāng)被一個(gè)事件（例如一個(gè)消息）激發(fā)時(shí)，每一這樣的轉(zhuǎn) 換是該use-case的一個(gè)實(shí)例所執(zhí)行的一個(gè)動(dòng)作序列,細(xì)化USE CASE，即： 從開始狀態(tài)到終止?fàn)顟B(tài)選擇一條完整的基本路徑，并在一 節(jié)中對(duì)該路徑予以描述。 其中，這一路徑的選擇應(yīng)該是用戶認(rèn)為它是一條最通常的 路徑，并對(duì) 相關(guān)的actor產(chǎn)生最明顯的值（ the most obvious value ）。

39、 一般來說，這樣的一條路徑應(yīng)該包含系 統(tǒng)不大需要的一些例外和異常處理,接之，在另一節(jié)中描述其余的可選路徑 其中，有些可選的路徑是很小的，是否可以把它作為基本 路徑的組成部分還是在一個(gè)獨(dú)立的一節(jié)中作為可選路徑予以 描述，這是一個(gè)設(shè)計(jì)決策問題，取決于該描述是否精確，是 否容易閱讀。. 注意：不管我們選擇了什么描述技術(shù)，都必須描述所有的 可選路徑，否則就不能說給出了對(duì)該use case的規(guī)約,Example: Paths of the Pay Invoice Use Case Precondition: The buyer has received the goods or services ord

40、ered and at least one invoice from the system. The buyer now plans to schedule the invoice(s) for payment. Flow of Events Basic Path 1 The buyer invokes the use case by beginning to browse the invoices received by the system. The system checks that the content of each invoice is consistent with orde

41、r confirmations received early(as part of the Confirm Order use case) and somehow indicates this to the buyer. The order confirmation describes which items will be delivered, when , where, and at what price,2 The buyer decides to schedule an invoice for payment by the bank, and the system generates

42、a payment request to transfer money to the sellers account. Note that a buyer may not schedule the same invoice for payment twice. 3 later, if there is enough money in the buyers account, a payment transaction is made on the scheduled date. During the transaction, money is transferred from the buyer

43、s account to the sellers account, as described by the abstract use case Perform Transaction(which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collect a fee for the transaction, which is withdrawn from the buyers account by the system. 4 T

44、he use case instance terminates,Alternative Path In Step 2, the buyer may instead ask the system to send an invoice rejection back to the seller. In Step 3, if there is not enough money in the account, the use case will cancel the payment and notify the buyer. Post-condition: The use case instance e

45、nds when the invoice has been paid or when the invoice payment was canceled and no money was transferred,Use Case 描述中的基本內(nèi)容 一個(gè) use-case 描述中，必須包括： 定義其開始狀態(tài)，作為一個(gè)前置條件（recondition）. 定義第一個(gè)要執(zhí)行的動(dòng)作，例如 Step 1，即描述該 use case 是如何開始的，什么時(shí)候開始。 定義所要求的次序，即給出其中的動(dòng)作必須以該次序予以 執(zhí)行。例中，該次序是通過步驟號(hào)予以定義的（ (Step 1-4) ）。 描述該 use cas

46、e 是如何結(jié)束的，什么時(shí)候結(jié)束（ Step 4 ）。 定義可能的結(jié)束狀態(tài)，作為后置條件（post conditions,給出在基本路徑描述中的可選路徑的描述。 給出那些基本路徑之外的可選路徑的描述。 定義與actors 的系統(tǒng)交互以及它們之間的交換 (Step 2 and Step 3)，即描述該use case 動(dòng)作序列，這些動(dòng)作是如何被 相關(guān)的actors予以激發(fā)（ invoke）以及它們是如何執(zhí)行的， 以響應(yīng)actor的要求。 描述系統(tǒng)中有關(guān)對(duì)象、值和資源的用法（Usage ） (Step 3). 即描述在一個(gè)use-case使用中的動(dòng)作序列以及對(duì)該use-case屬 性所賦予的值,如果

47、該系統(tǒng)與其它系統(tǒng)交互，則必須規(guī)約這一交互,例如引用 一個(gè)標(biāo)準(zhǔn)的通訊協(xié)議。 注意：在use-case 描述中，我們必須顯式地描述系統(tǒng)做什么 （執(zhí)行的動(dòng)作） ， 以及actor做什么。應(yīng)從actors 做 什么中分離出系統(tǒng)的責(zé)任。否則， 對(duì)系統(tǒng)規(guī)約的使用 來說，這樣的use-case描述就不夠精確,當(dāng)use case 描述是： 可理解的； 正確的（即捕獲了正確的需求）； 完備的（ complete，例如，描述了所有可能的路徑）; 一致的. 我們才可以說，結(jié)束了use case的描述。 該描述可以在需求捕獲結(jié)束的復(fù)審會(huì)中，由分析員予以評(píng)估，也可以由用戶和客戶予以評(píng)估。但僅客戶和用戶才能確認(rèn)該use

48、cases是否是正確的,半形式化的Use-Case描述 前置條件 對(duì)于一個(gè)復(fù)雜的實(shí)時(shí)系統(tǒng)， use case可能是相當(dāng)負(fù)責(zé)的， 例如actors和 use case 之間的交互可能經(jīng)過相當(dāng)多的狀態(tài)和 狀態(tài)轉(zhuǎn)換，從而幾乎不可能保持正文描述的use case 的一致 性。 相關(guān)的技術(shù) 為此，需要使用更結(jié)構(gòu)化的描述技術(shù)，這樣的技術(shù)一般使 用可視化的建模技術(shù)，來描述use cases 。以下技術(shù)可以幫助 系統(tǒng)分析人員更好地理解use cases,Browsing,Schedule,Reject,Invoice Scheduled,Pay on due date,Invoice Paid,Invoice

49、 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)換,活動(dòng)圖 用于描述狀態(tài)之間更詳細(xì)的動(dòng)作序列。 注：活動(dòng)圖源于SDL的狀態(tài)轉(zhuǎn)換圖（ SDL state transition diagrams），它是已予證明的、用于電信的一種語(yǔ)言。 交互圖 用于描述一

50、個(gè)use case的實(shí)例如何與 actor 的一個(gè)實(shí)例 進(jìn)行交互。為此，交互圖給出了use case 以及參與的 actor（s,注意: 在使用這些圖當(dāng)中，由于問題的復(fù)雜性，有時(shí)可能會(huì)出 現(xiàn)一些大的、復(fù)雜的圖，以至于很難閱讀和理解，特別對(duì)于 那些不是軟件開發(fā)人員來說更難閱讀。 這些圖是一些更接近開發(fā)細(xì)節(jié)的圖，應(yīng)與系統(tǒng)其它模型 保持一致。 建議： 應(yīng)謹(jǐn)慎地使用這些圖，在一般情況下，應(yīng)采用 use case的 正文描述（即事件流描述）。 在很多情況中，正文描述和這些圖是互補(bǔ)的,6) 用戶界面的原型構(gòu)造 目的 建造一個(gè)用戶界面的原型，使用戶有效地執(zhí)行use cases。 步驟 第一步，用戶界面的邏輯

51、設(shè)計(jì) 第二步，物理用戶界面的設(shè)計(jì) 第三步，開發(fā)用戶界面原型，演示為了執(zhí)行該use case，用戶怎樣使用該系統(tǒng)。 注：如何進(jìn)行以上三步，可參見有關(guān)文獻(xiàn),7) Use Case 模型的結(jié)構(gòu)化 前置條件: 系統(tǒng)分析員已經(jīng)標(biāo)識(shí)了actors 和 use cases, 已經(jīng)以 圖予以了描述，并給出了整個(gè)use case 模型的說明。 use case 規(guī)約人員已經(jīng)對(duì)每一use case開發(fā)了詳細(xì)的描述。 做什么： 抽取use case描述中一般的、共享的功能，用于特定 use case描述。 抽取use case描述中附加的或可選的（additional or optional）功能，它們可能被擴(kuò)展為

52、特定use case描述,使用泛化關(guān)系，標(biāo)識(shí)并描述那些共享功能 例如,Buyer,Seller,Pay Invoice,Pay Invoice 和 Perform Transaction 這2個(gè) use case之間的泛化關(guān)系,Perform Transaction,使用擴(kuò)展關(guān)系，標(biāo)識(shí)并描述附加的或可選的功能 例如,Buyer,Seller,Pay Invoice,Pay Invoice 和 Pay Overdraft Fee 這2個(gè)use cases之間的擴(kuò)展關(guān)系,extend,Perform Transaction,Pay Overdraft Fee,標(biāo)識(shí)use case之間的其它關(guān)系 u

53、se cases之間還包括其它關(guān)系，例如包含關(guān)系（include,注意：（3點(diǎn)） 在結(jié)構(gòu)化 use case中應(yīng)注意以下3個(gè)問題： 建立 use cases的結(jié)構(gòu)和它們的關(guān)系，應(yīng)盡可能地反映use cases的實(shí)際情況。否則，不論對(duì)用戶或客戶還是對(duì)開發(fā)人員本身，要理解這些use cases以及它們的意圖就變得相當(dāng)困難. 每一個(gè)use case都需要被進(jìn)一步處理為一個(gè)特定的制品。有時(shí)，use case規(guī)約人員需要給出它的描述；在后續(xù)的分析和設(shè)計(jì)中，use case需要用不同的use-case細(xì)化（realization）予以細(xì)化。為此， use cases不應(yīng)太小或太多，從而需要對(duì)use cas

54、e結(jié)構(gòu)化工作予以有效地管理,應(yīng)避免分解use case 模型中use cases的功能。最好在分析和設(shè)計(jì)中對(duì)每一 use case進(jìn)行精化（refining）。這一精化，如果需要的話，是以面向?qū)ο箫L(fēng)格將由use cases所定義的功能作為概念分析層面上對(duì)象之間的協(xié)作，以便產(chǎn)生對(duì)需求的深入理解,總結(jié)-需求獲取 需求獲取以及相關(guān)制品 work to be done result artifacts -List candidate requirements Feature list -Understand system context Business or domain model -Captur

55、e 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)的語(yǔ)境，是創(chuàng)建系 統(tǒng)use case 模型的基礎(chǔ)。 use case 模型 Use-Case Model 是軟件和客戶就需求的一個(gè)共識(shí)，即系統(tǒng) 必須具有的條件（conditions）和能力（capabilities） 。 The Use-Case 模型為系統(tǒng)

56、分析、設(shè)計(jì)、實(shí)現(xiàn)以及測(cè)試提供 了基本的輸入。 A Use-Case 模型是系統(tǒng)的一個(gè)模型，包含系統(tǒng)中 actors 、 use cases 以及它們之間的關(guān)系。即,Use-Case system,Use-Case model,Actor,Use case,1,The Use-Case model and its contents. The Use-Case system denotes the top-level package of the model,use-case 模型捕獲了功能需求。非功能需求特定于單個(gè)的use case，其規(guī)約具有一般性，并不針對(duì)一個(gè)特定的use case 。 us

57、e-case 模型的描述，可以通過： - a survey description -a detailed description of each use case. 對(duì)于use case 模型中的每一 use case ，應(yīng)驅(qū)動(dòng)開發(fā)的后 續(xù)工作，并實(shí)現(xiàn)它們的無(wú)縫連接。即在分析階段和設(shè)計(jì)階段， 應(yīng)標(biāo)識(shí)相匹配的 use-case 細(xì)化（realization），并標(biāo)識(shí)測(cè)試階段 中的一組測(cè)試用例（ test cases,捕獲需求階段的活動(dòng),2、 需求分析,實(shí)際問題,需求獲取模型,形成,需求分析模型,形成,需求獲取,需求分析,注：實(shí)現(xiàn)第二次抽象,注：實(shí)現(xiàn)第一次抽象,1) 需求分析層的術(shù)語(yǔ) 分析類（A

58、nalysis class） Use Case細(xì)化（Use Case Realization-Analysis） 分析包（ 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)常是 問題

59、域上的概念，并可通過問題域就可以了解其含義。 分析類所涉及的關(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ā)出請(qǐng)求和從他們那里接 受信息。 與設(shè)計(jì)平臺(tái)的關(guān)系：邊界類常常是在更高的概念層上，對(duì)windows, forms, panes, communication interfaces, printer interfaces, sensors, terminals

60、, 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)涵：用于對(duì)那些需要長(zhǎng)期足留系統(tǒng)的模型化對(duì)象以及與行為相關(guān)的某些 現(xiàn)象進(jìn)行建模，例如人的信息以及實(shí)際的一個(gè)事件。 與業(yè)務(wù)類的關(guān)系： 在大多數(shù)情況下