第三講-嵌入式系統(tǒng)需求定義-嵌入式軟件設(shè)計開發(fā)課件

嵌入式軟件設(shè)計開發(fā)康一梅

kangyimei@BeiHang

College

of

Software1關(guān)于需求需求就是關(guān)于系統(tǒng)應(yīng)該“做什么”而不是“怎么做”的問題描述。需求通常分為需求定義和需求分析兩個階段。需求定義產(chǎn)生客戶理解的系統(tǒng)規(guī)格說明書，需求分析產(chǎn)生開發(fā)人員可以清楚解釋的分析模型。2系統(tǒng)分析員素質(zhì)雖然許多傳統(tǒng)的需求問題仍未解決，但是客戶對系統(tǒng)的要求卻在不斷提高。這是因為客戶本身面臨著更激烈的競爭，他們需要以最快的速度調(diào)整業(yè)務(wù)以滿足市場的需要。相應(yīng)地，軟件開發(fā)者對需求的定義與分析不僅要考慮當(dāng)前的需求，還要考慮可能面臨的需求變化。對于軟件開發(fā)者而言，現(xiàn)在已經(jīng)進入隨需應(yīng)變的時代，這對系統(tǒng)分析員的要求也越來越高。一個合格的系統(tǒng)分析員應(yīng)該具備以下素質(zhì)：業(yè)務(wù)知識技術(shù)背景分析能力溝通技巧3基本原理是決策的依據(jù)。給定一個決策，它的基本原理包括它針對的問題、備選方案、評價備選方案的標(biāo)準(zhǔn)、開發(fā)人員的爭論以及決策本身。4基本原理需求分析系統(tǒng)規(guī)格說明：

模型系統(tǒng)分析模型：模型需求提出和分析僅僅集中在使用者對系統(tǒng)的觀點上。問題定義需求提出基本原理模型：模型需求模型的建模步驟5問題定義6在正式的需求工程之前。其目標(biāo)是讓項目經(jīng)理和客戶就所構(gòu)建系統(tǒng)的范圍達成意見一致，產(chǎn)生一個問題定義文檔，概括系統(tǒng)的功能和領(lǐng)域，也包括非功能性需求。問題定義并不產(chǎn)生問題的完整描述，它只是一個初步的需求活動。第三講嵌入式系統(tǒng)需求定義73.1問題定義確定系統(tǒng)目標(biāo)確定系統(tǒng)約束確定系統(tǒng)范圍8問題定義的活動確定系統(tǒng)目標(biāo)目標(biāo)是用來指導(dǎo)項目的高層準(zhǔn)則。目標(biāo)常是相互沖突的。性能最好功能最多最強價格最便宜界面最美觀性價比最好最快完成比競爭對手的要好可復(fù)用/一次性可靠性。。。。。。正確完整一致清晰現(xiàn)實可驗證可追溯明確、量化問題定義的活動9確定系統(tǒng)約束網(wǎng)絡(luò)帶寬、系統(tǒng)平臺、接口、兼容舊系統(tǒng)等用戶使用軟件的能力與習(xí)慣價格時間質(zhì)量用戶的配合度公司現(xiàn)有狀況(人力\資金\銷售\開發(fā)平臺\業(yè)務(wù)領(lǐng)域等等)非功能性需求10問題定義的活動確定系統(tǒng)范圍確定應(yīng)用域----環(huán)境與系統(tǒng)的邊界確定應(yīng)用域的邊界確定系統(tǒng)的邊界11問題定義的活動問題定義案例[FRIEND,1994]1.

當(dāng)前緊急情況處理的缺陷①

基于電話線路，處理能力？ 一般不用無線電傳送。②防火、警察、緊急醫(yī)療服務(wù)、重大工程事故等，紙制資料在緊急情況發(fā)生時用不上或不好用。③緊急情況發(fā)生時，關(guān)鍵信息不能快速獲得。如事件位置信息（危險品、煤氣管道等地點）不能得到或根本不存在。傳送信息的方式使用已有信息獲取有用信息應(yīng)急聯(lián)動系統(tǒng)12問題定義案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)功能性需求①

在異常呼叫負(fù)載情況下能同時處理多個緊急事件。②

對緊急情況的更壞狀況有所準(zhǔn)備③

使用寬帶，傳輸不能成為限制。④

提供實時信息，如：地理信息——如城市地圖，包括地上和地下公共設(shè)施危險品信息建筑物位置信息——如煤氣或供水管道、消防栓位置、樓層地圖可用的政府資源——如緊急情況操作方案（EmergencyOperation

Plan,EOP)13問題定義案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)2.

功能性需求⑤

遵照指導(dǎo)方針和EOP，系統(tǒng)將自動通知適當(dāng)部門的工作人員，創(chuàng)建任務(wù)列表、配置資源及其他一些在緊急情況中節(jié)省時間的工作。⑥

每一個與系統(tǒng)交互的現(xiàn)場指揮工具上都有一臺移動電腦使用無線通信向總部調(diào)度員報告。目標(biāo)是試圖用一種更

簡單的輸入手段、響應(yīng)式的用戶界面、語音識別、觸摸

屏或手寫筆式的系統(tǒng)，來替換第一響應(yīng)者報告輸入機制。系統(tǒng)事務(wù)都須歸檔，以便將來分析所需。14問題定義案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)3.

非功能性需求①

首先在公安警務(wù)部門使用。醫(yī)療衛(wèi)生部門使用②

之后在警醫(yī)務(wù)療、消防、市政管理部門等使用，對本地信息提供更高級的管理功能。③

現(xiàn)場人員使用的設(shè)備應(yīng)適合惡劣天氣和艱苦工作。④

可移植到當(dāng)?shù)卣捎玫默F(xiàn)有硬件上。⑤

原型希望是可擴展的，以便處理省級、國家級事件。15問題定義案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)4.

接受標(biāo)準(zhǔn)①

第一版不要求實現(xiàn)所有功能。②

在需求工程階段，客戶與軟件工程師協(xié)商一個可交付的原型。③

在協(xié)商階段之后，用戶驗收測試的具體需求將被凍結(jié)。④

客戶需求在4-6周內(nèi)開始正式交付。⑤

最低限度，原型可擴展。⑥

最低限度的驗收測試，希望協(xié)商的原型能在有一個無線組件的系統(tǒng)上演示。⑦

理想的演示，希望在警察的現(xiàn)場系統(tǒng)上演示。16第三講嵌入式系統(tǒng)需求定義173.2需求定義基本概念功能性需求非功能性需求偽需求需求描述的要求確定一致的術(shù)語描述的層次18需求定義基本概念功能性需求功能性需求是系統(tǒng)功能的陳述，明確系統(tǒng)應(yīng)該提供什么功能。如電梯控制系統(tǒng)中的一個功能需求就是：當(dāng)電梯求生系統(tǒng)開啟時，電梯自動控制系統(tǒng)開啟應(yīng)急電燈。19需求定義基本概念非功能性需求:指與系統(tǒng)功能行為沒有直接關(guān)系但用戶可見的系統(tǒng)部分，是系統(tǒng)的特定特性，以保證功能的正常實現(xiàn)、優(yōu)化產(chǎn)品的功能或者是限定產(chǎn)品應(yīng)達到的目標(biāo)值。非功能性需求為確定系統(tǒng)的結(jié)構(gòu)和系統(tǒng)選用的技術(shù)等進行了約束，包括定量約束，如響應(yīng)時間或精度等。最常見的非功能性需求有：系統(tǒng)處理速度；可靠性；可用性；安全性；耐用性；產(chǎn)品的最終價格；系統(tǒng)的尺寸和質(zhì)量；系統(tǒng)的功耗。需求定義20基本概念偽需求偽需求是客戶強加的需求，它約束系統(tǒng)的實現(xiàn)。典型的偽需求是實現(xiàn)系統(tǒng)的編程語言和運行平臺。21需求定義基本概念需求描述的要求需求定義的最終目的是要獲得沒有二義性的、全面的、詳盡的目標(biāo)需求。因此，需求規(guī)格說明要滿足正確性、完整性、一致性、清晰性、現(xiàn)實性、可修改性、可追蹤性等要求。22需求定義m:模型r:現(xiàn)實正確性：模型描述客戶感興趣的事實，而不是其他事實。r2:現(xiàn)實完整性：模型中用概念描述了感興趣的每個現(xiàn)象。m:

模型

r:現(xiàn)實c1:

概念

p1:現(xiàn)象c2:

概念

p2:現(xiàn)象需求定義需求描述的要求:正確性、完整性、一致性、清晰性和現(xiàn)實性23一致性：模型中的所有概念都與同一現(xiàn)實的現(xiàn)象對應(yīng)。m:

模型

r1:

現(xiàn)實

r2:現(xiàn)實c1:

概念

p1:現(xiàn)象c2:

概念

p2:現(xiàn)象清晰性：模型中的所有概念都只與一個現(xiàn)象對應(yīng)。m:

模型

r1:現(xiàn)實

r2:

現(xiàn)實c1:

概念

p1:現(xiàn)象p2:現(xiàn)象需求定義需求描述的要求:正確性、完整性、一致性、清晰性和現(xiàn)實性24現(xiàn)實系統(tǒng)領(lǐng)域虛擬件領(lǐng)域m:模型r1:現(xiàn)實r2:現(xiàn)實現(xiàn)實性：模型描述了可以25存在的事實。需求定義需求描述的要求:正確性、完整性、一致性、清晰性和現(xiàn)實性需求描述的要求:可驗證性和可追溯性可驗證性：一旦系統(tǒng)建立，如果可以設(shè)計一個可重復(fù)的實驗來演示系統(tǒng)滿足了需求，那么說明是可驗證的。產(chǎn)品應(yīng)有一個好的用戶界面。產(chǎn)品應(yīng)是沒有錯誤的（需要建立大量資源）對大多數(shù)情況，產(chǎn)品應(yīng)在1S內(nèi)對用戶給予響應(yīng)。可追溯性：如果每個系統(tǒng)功能可以被追溯到相應(yīng)的需求，那么系統(tǒng)規(guī)格說明是可追溯的?？勺匪菪圆皇菍ο到y(tǒng)規(guī)

格說明內(nèi)容的約束，而是對它的組織的約束。可追溯性

有助于開展系統(tǒng)測試和需求設(shè)計的系統(tǒng)驗證。26需求定義基本概念27確定一致的術(shù)語開發(fā)人員和用戶合作時遇到的第一個障礙就是術(shù)語不通。為了與客戶溝通，需要與客戶確認(rèn)一些不確定的詞語，以及應(yīng)用域的專業(yè)術(shù)語。同一個術(shù)語在不同的上下文中的意思不一樣，這就導(dǎo)致了誤解的產(chǎn)生。雖然最后開發(fā)人員學(xué)會了用戶的術(shù)語，但是當(dāng)新的開發(fā)人員加入這個項目后，這個問題就會出現(xiàn)。因此，開發(fā)人員應(yīng)確定、命名、并且明確的描述這些用詞與術(shù)語，最后將它們編入一個術(shù)語表。術(shù)語表包含在系統(tǒng)需求規(guī)格說明中，并且在最后放入用戶手冊。開發(fā)人員使術(shù)語表與系統(tǒng)規(guī)格說明同步升級。術(shù)語表有很多好處：新來的開發(fā)人員面對一系列一致的定義，每個術(shù)語用來表達一個概念（取代開發(fā)人員術(shù)語和用戶術(shù)語），并且每個術(shù)語有一個精確的、清楚的正式含義。需求定義這一系列用例描述用戶和系統(tǒng)用戶界面之間的交互作可用以，用重點用是例解描決述控制流程和規(guī)劃。這一系列用例描述不直接與應(yīng)用域相關(guān)的系統(tǒng)支持這的一功系能列，用包例括描文述件與管系理統(tǒng)功相能關(guān)、的分用組戶功的能工、撤消作功這過能一程等系。列當(dāng)用統(tǒng)我例支們描持討述的論系那已統(tǒng)部知提分的供過邊的程界與也條應(yīng)被件用描，域述如有，系統(tǒng)但初關(guān)重始的點化功是、能定關(guān)。義閉用和戶例與外系處統(tǒng)理的機邊制界時。，會在系統(tǒng)設(shè)計時擴展這些用例。28基本概念

描述的層次需求定義系統(tǒng)邊界系統(tǒng)的應(yīng)用功能系統(tǒng)的支持功能人機交互界面Greenfield 工程：開發(fā)從零開始，不是從已有的系統(tǒng)開始，需求來自用戶和客戶。

Greenfield 工程的項目是由用戶需要或新市場產(chǎn)生引發(fā)的。再工程：由新技術(shù)或新信息流引發(fā)的對已有系統(tǒng)的重新設(shè)計和重新實現(xiàn)。有時擴展系統(tǒng)的功能，但系統(tǒng)的基本目的沒有變。新系統(tǒng)的需求直接從已有的系統(tǒng)上獲取。界面工程：對已有系統(tǒng)用戶界面的重新設(shè)計。除了界面被重新設(shè)計和實現(xiàn)之外，原有系統(tǒng)不做其他改動。這種項目是低費用的、不放棄原有系統(tǒng)的再工程項目。29基本概念:Greenfield工程、再工程、界面工程需求定義與客戶協(xié)商系統(tǒng)規(guī)格說明書：聯(lián)合應(yīng)用設(shè)計（JAD）聯(lián)合應(yīng)用程序設(shè)計是一套面向結(jié)果的,大腦風(fēng)暴式的,有一個共同的商業(yè)目的信息集合/分享會議。該方

法是IBM公司在1970年開發(fā)的，由固定的，結(jié)構(gòu)化的過程組成，并在一個有經(jīng)驗的實施者的領(lǐng)導(dǎo)下進行。簡化方法是90年代的術(shù)語,簡化方法去掉了一些結(jié)構(gòu),然而,仍要求所有各方都必須參加所有的會議和一

個有建模技術(shù)的記錄員作記錄。參加者們包括項目

團隊,管理(與用戶)和行政官員。為會議的成功，每個人必須理解和同意目的并且盡快解決他們的任務(wù)。30需求定義與客戶協(xié)商系統(tǒng)規(guī)格說明書：聯(lián)合應(yīng)用設(shè)計（JAD）JDA主要有五個活動：項目定義調(diào)查預(yù)備會議最終文件31需求定義與客戶協(xié)商系統(tǒng)規(guī)格說明書：聯(lián)合應(yīng)用設(shè)計（JAD）Figure

4-12.

Activities

of

JAD(UML

activity

diagram).

Theheart

of

JAD

is

theSessionactivity

during

which

allstakeholders

design

and

agreeto

a

system

specification.

Theactivities

prior

to

the

Sessionmaximizes

its

efficiency.Theproduction

of

the

Finaldocument

ensures

that

thedecisions

made

during

theSession

are

captured.Managementdefinition

guideProjectdefinitionResearchPreparationSessionSession

agendaPreliminary

specificationWorking

documentSession

scriptScribe

formsFinal

documentpreparationFinal

document32常見的問題系統(tǒng)用于什么任務(wù)？什么時間交付？希望系統(tǒng)具有哪些功能，它能完成哪些任務(wù)？系統(tǒng)從用戶或其它源接收什么輸入？系統(tǒng)向用戶或其它源輸出什么？用戶想要如何同系統(tǒng)打交道？即進行什么樣的人機交互，如在小鍵盤輸入和顯示屏輸出？顯示屏顯示什么內(nèi)容有及如何規(guī)定顯示方法？系統(tǒng)的質(zhì)量和體積如何？系統(tǒng)連接何種外部設(shè)備？系統(tǒng)是否需要運行某些現(xiàn)存組件？系統(tǒng)處理哪種類型的數(shù)據(jù)？系統(tǒng)是否要與別的系統(tǒng)通訊？系統(tǒng)是單機還是網(wǎng)絡(luò)系統(tǒng)？系統(tǒng)的響應(yīng)時間是多少？需要什么樣的安全措施？需求定義33常見的問題系統(tǒng)在什么樣的環(huán)境下運行？如操作溫濕度和環(huán)境參數(shù)說明。外部存儲媒介和內(nèi)存需要多大？系統(tǒng)的可折裝性、可靠性和牢固性的期望值是什么？如何給系統(tǒng)供電？如何給系統(tǒng)供電？系統(tǒng)負(fù)載如何？系統(tǒng)負(fù)載是一項重要內(nèi)容。系統(tǒng)在過載的情況下可能導(dǎo)致失效。系統(tǒng)負(fù)載越大，需要的功耗就越大。是否使用傳感器？傳感器的靈敏度、精度、分辯率和精確度的要求？系統(tǒng)如何向用戶通報故障？是否需要任何手動或機械代用裝置？系統(tǒng)是否將具有遠程診斷或更正問題的功能？系統(tǒng)的最大可承受成本？其它問題。34需求定義面向?qū)ο蟮母拍?模塊化的程序要優(yōu)于龐大的、整體式的計算機程序。易于理解擴展性強利于維護運行效率？35面向?qū)ο笮枨蠖x面向?qū)ο笮枨蠖x36面向?qū)ο蟮母拍罟δ芊纸饧遥河煤瘮?shù)實現(xiàn)模塊——每個模塊做且僅做一件事。數(shù)據(jù)公爵：每個模塊都應(yīng)容納一個數(shù)據(jù)結(jié)構(gòu)。實時系統(tǒng)開發(fā)者：每個模塊都應(yīng)該能識別并對一個事件作出反應(yīng)，且這個事件是唯一的。每個模塊都對應(yīng)著且唯一對應(yīng)著現(xiàn)實世界中的某一件事。面向?qū)ο笮枨蠖x37面向?qū)ο蟮母拍顚ο笫侵敢粋€獨立的、異步的、并發(fā)的實體。它能知道一些事情（即存儲數(shù)據(jù)），做一些工作（即封裝服務(wù)），并與其他對象協(xié)同（通過交換消息），從而完成（模塊化）系統(tǒng)的所有功能。面向?qū)ο笮枨蠖x38面向?qū)ο蟮母拍顝?fù)用性:通過面向?qū)ο蠹夹g(shù)，軟件工程生存期中的每個部分都可以封裝成可復(fù)用的對象。需求分析設(shè)計測試計劃用戶界面體系結(jié)構(gòu)需求提出需求分析系統(tǒng)規(guī)格說明：

模型系統(tǒng)分析模型：模型需求提出和分析僅僅集中在使用者對系統(tǒng)的觀點上。39面向?qū)ο笮枨蠖xOOA模型的建模步驟（B.Bruegge

&A.H.Dutoit

2002)面向?qū)ο笮枨蠖x包括以下活動確定執(zhí)行者確定場景確定用例改進用例確定用例之間的關(guān)系確定非功能性需求問題描述-系統(tǒng)規(guī)格說明書-模型場景用例用什么形式描述？40面向?qū)ο笮枨蠖x確定執(zhí)行者執(zhí)行者描述與系統(tǒng)交互的外部實體。執(zhí)行者可以是人

員也可以是外部系統(tǒng)。執(zhí)行者具有唯一的名字與描述。執(zhí)行者是角色抽象，不一定直接對應(yīng)到人。當(dāng)確定執(zhí)行者時，分析人員可以提出以下問題：①

系統(tǒng)支持哪個用戶群完成他們的工作？②

哪個用戶群執(zhí)行系統(tǒng)的主要功能？③

哪個用戶群執(zhí)行輔助功能，如維護和管理？④

系統(tǒng)與外部硬件或軟件交互嗎？41需求定義的活動市長省長部長危險品數(shù)據(jù)庫在逃刑事犯罪分子數(shù)據(jù)庫消防員醫(yī)生傳染病控制中心工作人員警察防汛指揮中心工作人員調(diào)度員????????傳染病數(shù)據(jù)庫系統(tǒng)管理員。。。。。。案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)涉及現(xiàn)場某一單獨事件時，可以共享同樣的系統(tǒng)接口管理多個并發(fā)事件并訪問大量信息不可能直接與系統(tǒng)交互，但會利用操作員提供的服務(wù)，操作員與調(diào)度員可用相同的系統(tǒng)接口。為系統(tǒng)提供數(shù)據(jù)系統(tǒng)維護、管理等。42需求定義的活動－確定執(zhí)行者現(xiàn)場工作人員業(yè)務(wù)數(shù)據(jù)庫系統(tǒng)應(yīng)急聯(lián)動系統(tǒng)系統(tǒng)管理員調(diào)度員案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)43需求定義的活動－確定執(zhí)行者一旦執(zhí)行者被確定，就需要決定每個執(zhí)行者可以訪問的功能。使用場景可以獲得這些信息，而用例則可形式化這些信息。場景是未來所用系統(tǒng)的具體示例，是解釋單個案例的具體例子。場景是沒有限制和非正式的。

場景應(yīng)該用應(yīng)用域的術(shù)語編寫。44需求定義的活動－確定場景案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)應(yīng)急聯(lián)動系統(tǒng)是一個事件響應(yīng)信息系統(tǒng)。在下面的場景中，警察報告火災(zāi)，調(diào)度員啟動事件響應(yīng)。注意：這個場景描述的是個別情況，并非描述火災(zāi)事件的所有情況。45需求定義的活動－確定場景應(yīng)急聯(lián)動系統(tǒng)46案例[FRIEND,1994]報告緊急情況用例：倉庫著火需求定義的活動－確定場景在需求提出和生命周期的其他活動中，場景還有許多其他的用處。如：實際場景：描述當(dāng)前的工作情況。想象場景：描述從零設(shè)計的或重建的未來系統(tǒng)。想象場景可看作一個造價不高的原型。評價場景：描述用戶任務(wù)，根據(jù)它評價系統(tǒng)。培訓(xùn)場景：向新用戶介紹系統(tǒng)的示例。幫助用戶掌握系統(tǒng)的指導(dǎo)材料。47需求定義的活動－確定場景確定場景的問題執(zhí)行者希望系統(tǒng)執(zhí)行的任務(wù)是什么？執(zhí)行者訪問什么信息？誰生成數(shù)據(jù)？數(shù)據(jù)是可修改和可移動的嗎？被誰修改移動？執(zhí)行者需要通知哪些外部變化？多長時間一次？什么時間通知？系統(tǒng)需要通知執(zhí)行者什么事件？延時是多少？48需求定義的活動－確定場景用例是對所有可能案例的抽象。詳細說明了給定功能的所有場景。49需求定義的活動－確定用例案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)報告緊急情況用例50需求定義的活動－確定用例改進用例場景與用例用于創(chuàng)建用戶在早期確認(rèn)的需求。為了盡可能減少需求變更，在需求提出階段需要做許多變更與實驗。許多用例被重寫幾次，另外一些得到充分改進，還有一些被完全放棄。為了節(jié)省時間，許多探索工作可利用場景和用戶界面模型來完成。改進用例的活動的重點是完整性和正確性。增加遺漏的新的用例增加執(zhí)行者不常看到的情況和例外控制增加系統(tǒng)支持用例51需求定義的活動－確定用例改進用例編寫場景與用例的試探法52????利用場景與用戶交流，確定功能。首先，改進一個元素的所有屬性（如一個場景）來理解用戶喜愛的交互模式。然后，利用所有元素的某一屬性（如不夠細致的場景）來定義系統(tǒng)范圍，與用戶共同確定。用戶界面模型僅僅作為可視化支持，一旦功能足夠穩(wěn)定，則把用戶界面設(shè)計作為一項獨立任務(wù)來做。給用戶多種可選擇方案（反對從用戶提取一個單獨的方案）當(dāng)理解了系統(tǒng)范圍和用戶愛好后，詳述元素的所有屬性，與用戶共同確定。需求定義的活動－確定用例案例[FRIEND,1994] 應(yīng)急聯(lián)動系統(tǒng)報告緊急情況用例改進版本需求定義的活動－確定用例53執(zhí)行者與用例之間的交流關(guān)系描述用例過程中的信息流，在功能層次上描述系統(tǒng)。用例之間的擴展關(guān)系區(qū)分事件的例外和事件的共有流程。用例之間的包含關(guān)系減少用例之間的冗余。54需求定義的活動－確定執(zhí)行者與用例之間關(guān)系用例之間的擴展關(guān)系把基本用例與異常和任選的事件流區(qū)分開來有兩個好處：基本用例變得更短并容易理解。把普通用例與異常用例分開，可以使開發(fā)人員分別處理每種功能。注：普通用例與異常用例都是完整的用例，它們必須有一個入口和結(jié)束條件。55需求定義的活動－確定執(zhí)行者與用例之間關(guān)系建立用例之間的擴展關(guān)系????需求定義的活動－確定執(zhí)行者與用例之間關(guān)系如果用例包括幾個行為段，這些段具有可選特性或者異常特性，并且它們不會增加對用例主要目的理解程度，則可以將這些行為分離出來作為新的擴展用例。而原始的用例則成為基本用例，擴展用例與之就形成了擴展關(guān)系。在基本用例中需要聲明擴展點，這些擴展點定義在基本用例中可能進行擴展的位置。對于復(fù)雜分支流和可選行為，最好將它們劃分出來，形成擴展用例。通常此行為相當(dāng)復(fù)雜，并且難以描述：將其包含在事件流中將更加

難以看到“正?！毙袨?。提取該行為將有助于提高對用例模型的理

解。確保在無須引用擴展用例時，基本用例的事件流仍然保持完整而且可以讓人理解。只有擴展用例知道它和基本用例之間的關(guān)系?；居美恢浪哂袛U展點，而并不清楚什么樣的擴展用例在使用這些擴展點。56建立用例之間的擴展關(guān)系(續(xù))簡要描述所定義的每一個擴展關(guān)系。定義產(chǎn)生擴展必須滿足的條件。確保在基本用例中定義了應(yīng)插入擴展的擴展點。如果未定義任何條件，這意味著擴展始終在執(zhí)行。如果擴展用例包含幾個行為段，這些段從不同的擴展點插入到基本用例中，則確保對這些行為段以及基本用例中每一個行為段的擴展點都作了定義。57需求定義的活動－確定執(zhí)行者與用例之間關(guān)系Figure

4-9.

Example

of

use

of

extend

relationship

(UML

use

casediagram).ConnectionDown

extends

the

ReportEmergency

use

case.TheReportEmergency

use

case

becomes

shorter

and

solely

focused

onemergency

reporting.

報告緊急情況用例簡化并且只集中在緊急情況報告上。FieldOfficerReportEmergencyConnectionDown<<extend>>案例用例[之FR間IE的ND擴,1展99關(guān)4]系應(yīng)急聯(lián)動系統(tǒng)58需求定義的活動－確定執(zhí)行者與用例之間關(guān)系建立用例之間的包含交流關(guān)系如果用例包括一個行為段，該段對于此用例其他部分的重要性完全在于它產(chǎn)生的結(jié)果，而不在于得到結(jié)果的方法，則可以將此行為分離出來作為新的包含用例。而初始的用例則成為與此包含用例有包含關(guān)系的基本用例。兩個用例間的包含關(guān)系是指用例實例為保持其完整性，不僅要符合基本用例的說明，同時還應(yīng)當(dāng)遵循包含用例的說明。包含關(guān)系可以通過以下方式幫助闡明用例：隔離和封裝復(fù)雜的細節(jié)，使之不會模糊用例的實際含義。包含涉及到幾個基本用例的行為，提高用例的一致性。通常，有不止一個用例必須包含某個包含用例，這樣維護一個額外用例和包含關(guān)系才有價值。只有基本用例清楚它和包含用例的關(guān)系；而包含用例并不知道自己被其他什么用例所包含。通過略述包含的目的以及包含用例插入基本用例的位置，說明它們之間的包含關(guān)系。說明基本用例的事件流時，應(yīng)當(dāng)引用在插入位置上的包含用例。需求定義的活動－確定執(zhí)行者與用例之間關(guān)系59案例用例[之FR間IE的ND包,1含99交4]流關(guān)系

<<include>>OpenIncidentViewMap<<include>>AllocateResourcesFigure

4-10.

Example

of

include

relationships

among

use

cases.查地圖（ViewMap）用例描述了查看城市地圖的事件流（如上下移動鼠標(biāo)，圖象縮放，依街道名稱查詢等），并被打開事件和分配資源兩個用例使用。應(yīng)急聯(lián)動系統(tǒng)60需求定義的活動－確定執(zhí)行者與用例之間關(guān)系擴展與包含關(guān)系的比較它們是類似的結(jié)構(gòu)，并且都是減少或消除冗余的，它們的主要差別是關(guān)系的方向。在包含關(guān)系中，啟動目標(biāo)用例的條件是在啟動用例中描述的，就象事件流中的事件一樣。在擴展關(guān)系中，啟動擴展的條件是在擴展中作為入口條件描述。61需求定義的活動－確定執(zhí)行者與用例之間關(guān)系擴展與包含關(guān)系的試探法對例外的、任選的或很少發(fā)生的行為使用擴展關(guān)系。對兩個或多個用例共用的行為使用包含關(guān)系。62需求定義的活動－確定執(zhí)行者與用例之間關(guān)系建立用例之間的泛化關(guān)系如果兩個或以上的用例在結(jié)構(gòu)和行為上有相似之處，可以將這些共同行為分離出來創(chuàng)建新的父用例。而初始的用例則成為與此父用例有泛化關(guān)系的子用例。子用例繼承父用例中描述的所有行為。兩個用例間的泛化關(guān)系指的是遵守子用例說明的用例實例還應(yīng)當(dāng)遵守父用例說明，這樣才認(rèn)為它是完整的。一般而言，應(yīng)當(dāng)至少有兩個子用例繼承同一個父用例，這樣維護父用例以及其與子用例之間的泛化關(guān)系才有意義。有一種例外情況，即有兩個用例，其中一個用例是另一個用例的特例，但它們都需要具有獨立的可實例化性質(zhì)。只有子用例知道它和父用例之間的關(guān)系；而父用例并不清楚哪個子用例是它的特例。為了幫助其他人理解這個模型，應(yīng)當(dāng)對泛化關(guān)系作簡短說明。解釋創(chuàng)建泛化關(guān)系的原因。在子用例的事件流中，需要