需求分析與驗(yàn)證

第五章需求分析與驗(yàn)證

5.1分析模型的表示

順序圖、通信圖、狀態(tài)圖、擴(kuò)充機(jī)制5.2需求分析的過(guò)程模型

5.3需求優(yōu)先級(jí)分析

5.4用例分析5.5利用快速原型輔助需求分析5.6評(píng)審分析模型

5.7需求規(guī)約

5.8需求驗(yàn)證2024/1/191何謂需求分析需求分析的任務(wù)在需求獲取階段的輸出制品的基礎(chǔ)上，獲得對(duì)軟件需求的更深入、更完整的理解，并且將軟件需求表示為面向軟件設(shè)計(jì)人員、易于修改和維護(hù)的分析模型。需求分析活動(dòng)的焦點(diǎn)基于用例模型建立軟件需求的分析模型。需求分析活動(dòng)參與者主要完成者是來(lái)自軟件開(kāi)發(fā)方的需求工程師。其他參與者包括軟件架構(gòu)師、利益相關(guān)方，以及項(xiàng)目軟件經(jīng)理、質(zhì)量保證工程師。需求分析輸入與輸出輸入制品與需求獲取活動(dòng)的輸出制品相同。在所有這些輸入制品中，用例模型最重要。輸出制品主要是軟件需求的分析模型。該模型是需求規(guī)約的主要組成部分，同時(shí)也是后續(xù)軟件設(shè)計(jì)、構(gòu)造和測(cè)試活動(dòng)的工作基礎(chǔ)。2024/1/192構(gòu)建分析模型的理由分析模型比用例模型更加結(jié)構(gòu)化、更加清晰直觀所以分析模型的構(gòu)建過(guò)程實(shí)際上也是不斷深入理解用例模型的過(guò)程，同時(shí)也是剔除用例的自然語(yǔ)言描述中可能存在的模糊性和不一致性的過(guò)程分析模型是用例模型與軟件設(shè)計(jì)模型之間的“橋梁”它比用例模型更接近于設(shè)計(jì)模型，更適合于軟件設(shè)計(jì)師設(shè)計(jì)軟件系統(tǒng)的結(jié)構(gòu)、構(gòu)思軟件求解算法，更易于為不太熟悉業(yè)務(wù)的軟件設(shè)計(jì)師所理解，換言之，理解分析模型對(duì)業(yè)務(wù)知識(shí)的要求遠(yuǎn)低于理解用例模型5.1分析模型的表示分析模型的表示主要采用UML的類圖、活動(dòng)圖、交互圖與狀態(tài)圖。2024/1/1945.1.1順序圖順序圖是交互圖中的一種。交互圖描述一組對(duì)象通過(guò)消息傳遞而形成的協(xié)作行為。交互圖的應(yīng)用：經(jīng)常用于描述單個(gè)用例的功能的實(shí)現(xiàn)方式，軟件系統(tǒng)在某種給定的使用場(chǎng)景下對(duì)象之間的交互協(xié)作流程，軟件系統(tǒng)的某個(gè)復(fù)雜操作的邏輯實(shí)現(xiàn)模型。通過(guò)交互圖可清晰地了解對(duì)象在軟件系統(tǒng)中扮演的角色以及對(duì)象之間的交互協(xié)作。2024/1/195順序圖交互圖的作用：業(yè)務(wù)分析及需求分析人員借助交互圖可分析、表述業(yè)務(wù)處理過(guò)程或與軟件相關(guān)的處理流程；軟件設(shè)計(jì)及實(shí)現(xiàn)人員根據(jù)交互圖確定對(duì)象的操作及操作實(shí)現(xiàn)方法；測(cè)試人員可從交互圖了解軟件處理過(guò)程并據(jù)此設(shè)計(jì)測(cè)試用例。圖5.1是課程注冊(cè)管理系統(tǒng)中“制訂選課計(jì)劃”用例的順序圖，該圖表示將一些課程設(shè)置添加至學(xué)生選課計(jì)劃時(shí)軟件系統(tǒng)內(nèi)多個(gè)對(duì)象之間的交互協(xié)作過(guò)程。2024/1/196圖5.1課程注冊(cè)管理系統(tǒng)中“制訂選課計(jì)劃”用例的順序圖2024/1/197順序圖分類：交互圖包括順序圖和通信圖/協(xié)作圖兩種。前者強(qiáng)調(diào)消息傳遞的時(shí)間序，后者突出交換消息的對(duì)象之間的合作關(guān)系。雖然它們各有側(cè)重，但從語(yǔ)義上講基本等價(jià)，可從一種圖自動(dòng)轉(zhuǎn)換為另一種圖，所以沒(méi)有必要針對(duì)同一建模目標(biāo)同時(shí)創(chuàng)建順序圖和通信圖，這樣反而容易引起語(yǔ)義上的冗余和沖突。2024/1/198（一）順序圖概覽順序圖是一張二維圖。其縱向代表時(shí)間軸，時(shí)間沿垂直方向向下延伸；其橫向由多個(gè)參與交互的對(duì)象構(gòu)成，這些對(duì)象之間無(wú)順序關(guān)系。一般情況下，時(shí)間軸上的兩點(diǎn)只有相對(duì)時(shí)序的差異，但在實(shí)時(shí)應(yīng)用中，可以使用帶時(shí)間刻度的時(shí)間軸以度量?jī)牲c(diǎn)之間的絕對(duì)時(shí)差。一張基本的順序圖由以下圖形元素構(gòu)成：對(duì)象及其生命線與活躍期，消息傳遞，注解。2024/1/199順序圖概覽⑴順序圖中的對(duì)象表示為嵌于矩形框內(nèi)形如

“[對(duì)象名]:[類名]”的文本，其中對(duì)象名、類名分別可省略，但不能同時(shí)省略。當(dāng)同一類有多個(gè)對(duì)象參與同一張順序圖所示的交互時(shí)，或者當(dāng)對(duì)象將作為參數(shù)出現(xiàn)在本圖中的某條消息時(shí)，對(duì)象名就不能省略。⑵對(duì)象之下的垂直虛線稱為對(duì)象的生命線，表示對(duì)象在始于對(duì)象表示圖元所處的時(shí)間起點(diǎn)、止于對(duì)象生命終結(jié)符（見(jiàn)圖5.1中TimeConflictChecker對(duì)象的生命線）之間的時(shí)間段內(nèi)在軟件系統(tǒng)中存在。如果對(duì)象生命線的下方?jīng)]有終結(jié)符，則表示對(duì)象在順序圖所代表的時(shí)間段之后仍然存在。2024/1/1910順序圖概覽⑶對(duì)象中操作的執(zhí)行期（包括等待同步調(diào)用返回的時(shí)間）稱為對(duì)象的活躍期，它由覆蓋于對(duì)象生命線之上的長(zhǎng)條形矩形表示。如果對(duì)象發(fā)出傳向自身的消息（見(jiàn)圖5.1中TimeConflictChecker對(duì)象的生命線），或者作為消息接收方的對(duì)象在處理消息的過(guò)程中又向消息發(fā)送方對(duì)象傳遞另一消息，則會(huì)導(dǎo)致活躍期的嵌套。2024/1/1911順序圖概覽⑷對(duì)象間的消息傳遞表示為對(duì)象生命線之間的有向邊，邊上可標(biāo)注“[*][監(jiān)護(hù)條件][返回值:=]消息名[(參數(shù)表)]”其中“*”為迭代標(biāo)記，表示同一消息對(duì)同一類的多個(gè)對(duì)象發(fā)送。當(dāng)出現(xiàn)迭代標(biāo)記時(shí)，監(jiān)護(hù)條件表達(dá)式表示迭代條件，例如圖5.1中的“*[對(duì)所有無(wú)沖突的課程設(shè)置]”；否則，它表示消息傳遞實(shí)際發(fā)生的條件。返回值表示消息被接收方對(duì)象處理完成后回送的結(jié)果。消息名的命名規(guī)則應(yīng)與類圖中操作的命名規(guī)則相一致。在消息的條件表達(dá)式和參數(shù)表中可以使用關(guān)鍵字“self”表示發(fā)出消息的源對(duì)象。2024/1/1912順序圖概覽建模者勿需考慮消息發(fā)送與接收之間的時(shí)延，確需考慮時(shí)（例如，在實(shí)時(shí)應(yīng)用中，或者當(dāng)消息通過(guò)網(wǎng)絡(luò)傳輸時(shí)），可以用斜向下方的消息邊來(lái)表示，見(jiàn)圖5.2（c）。順序圖中的消息分為同步、異步兩種，分別用實(shí)心三角形箭頭和普通箭頭表示，見(jiàn)圖5.2（a）和（b）。同步消息的發(fā)送者等待消息接收對(duì)象將消息處理完成后再繼續(xù)，異步消息的發(fā)送者在發(fā)送完消息后不等待接收方即繼續(xù)自己的處理。同步消息會(huì)指向作為消息接收目標(biāo)的對(duì)象的活躍期的頂端。2024/1/1913順序圖概覽UML中有四種特殊的消息：自消息、返回消息、創(chuàng)建（create）消息、銷毀（destroy）消息。自消息是指一個(gè)對(duì)象傳向其自身的消息。如果一條消息從對(duì)象a傳向?qū)ο骲，那么其返回消息是一條從b指向a的虛線有向邊，它表示原消息的處理已經(jīng)完成，處理結(jié)果（如果有的話）沿返回消息傳回。2024/1/1914順序圖概覽創(chuàng)建消息、銷毀消息的名稱分別為create、destroy，

或在消息邊上標(biāo)注構(gòu)造型<<create>>、<<destroy>>，分別表示對(duì)消息傳遞的目標(biāo)對(duì)象的創(chuàng)建和刪除。對(duì)于創(chuàng)建消息，目標(biāo)對(duì)象的矩形表示圖元的縱向位置應(yīng)位于消息接收點(diǎn)（因?yàn)樵诖酥按藢?duì)象并不存在）。對(duì)于銷毀消息，其目標(biāo)對(duì)象的生命線應(yīng)恰在消息接收點(diǎn)之下顯示終結(jié)符。2024/1/1915⑸可以在對(duì)象生命線上嵌入狀態(tài)符，它表示對(duì)象在狀態(tài)符所處的時(shí)間點(diǎn)上必定進(jìn)入相應(yīng)的狀態(tài)。還可以用狀態(tài)符來(lái)表示來(lái)自其他對(duì)象的某條消息將導(dǎo)致對(duì)象狀態(tài)的改變，此時(shí)狀態(tài)符應(yīng)在時(shí)間軸方向上靠近那條消息。如，圖5.3表示，Schedule對(duì)象在收到“confirm”消息后將進(jìn)入“confirmed”狀態(tài)。2024/1/1916順序圖概覽⑹在順序圖的左側(cè)，可加注解以闡釋消息的意義、有關(guān)的約束以及消息傳遞時(shí)間點(diǎn)之間的延時(shí)約束。注解處的位置應(yīng)在水平方向上與對(duì)應(yīng)的消息相齊。為精確地描述延時(shí)約束，可以在對(duì)象的生命線或活躍期上標(biāo)注時(shí)間標(biāo)簽，見(jiàn)圖5.2（c）。當(dāng)用例圖中的執(zhí)行者的實(shí)例出現(xiàn)在順序圖中時(shí)，它與軟件系統(tǒng)內(nèi)部對(duì)象之間的交互消息不同于兩個(gè)內(nèi)部對(duì)象之間的交互，僅依靠消息名、參數(shù)表來(lái)描述此類消息往往過(guò)于形式化，也難以完整、詳盡地表達(dá)交互的內(nèi)容，因此應(yīng)該在注解中以自然語(yǔ)言予以闡述。2024/1/1917圖5.2

同步、異步及帶時(shí)延的消息（b）異步消息2024/1/1918（a）同步消息（c）帶時(shí)延的消息圖5.3嵌入狀態(tài)符的對(duì)象生命線2024/1/1919（二）主動(dòng)對(duì)象與被動(dòng)對(duì)象考察整張順序圖（而非局部），在該圖表示的時(shí)間段內(nèi)，如果有多個(gè)對(duì)象同時(shí)處于活躍期，其中某些對(duì)象的活躍是直接或間接地起因于某個(gè)對(duì)象A傳出的消息，則稱A為主動(dòng)對(duì)象，稱由A直接或間接激活的對(duì)象為被動(dòng)對(duì)象。被動(dòng)對(duì)象在響應(yīng)、處理消息時(shí)接受消息源對(duì)象的控制，在消息處理完畢后將控制權(quán)交還，其活躍期的頂部位于消息接收點(diǎn)，底部位于消息處理完成時(shí)刻點(diǎn)。主動(dòng)對(duì)象在順序圖中以帶雙豎線的矩形表示，也可以采用約束特性{active}來(lái)表示，見(jiàn)圖5.4。2024/1/1920主動(dòng)對(duì)象與被動(dòng)對(duì)象在一張順序圖中，可能存在多個(gè)主動(dòng)對(duì)象。此時(shí)，這些主動(dòng)對(duì)象所掌控的控制流將并發(fā)執(zhí)行。兩個(gè)主動(dòng)對(duì)象之間的消息傳遞應(yīng)該是異步的。由于多個(gè)主動(dòng)對(duì)象引起的上述語(yǔ)義復(fù)雜性，所以建模者應(yīng)盡量避免這種情形，僅在確需強(qiáng)調(diào)多個(gè)主動(dòng)對(duì)象所掌控的控制流的并發(fā)性及它們之間的異步消息時(shí)，才在一張順序圖中引入多個(gè)主動(dòng)對(duì)象。如，在圖5.3所示的場(chǎng)景中，單個(gè)主動(dòng)對(duì)象就已足夠；但在刻畫協(xié)同工作場(chǎng)景時(shí)，需要強(qiáng)調(diào)任務(wù)負(fù)責(zé)人及多個(gè)子任務(wù)承擔(dān)者之間的并行處理，就必須引入多個(gè)主動(dòng)對(duì)象，見(jiàn)圖5.4。2024/1/1921圖5.4多個(gè)主動(dòng)對(duì)象構(gòu)成的順序圖2024/1/1922（三）建模規(guī)則在進(jìn)行順序圖建模過(guò)程中，建議讀者遵循以下經(jīng)驗(yàn)規(guī)則：⑴在業(yè)務(wù)分析和需求分析階段，建模者并不需要過(guò)于精細(xì)地刻畫順序圖的所有圖形元素。消息名和消息傳遞條件均可采用業(yè)務(wù)術(shù)語(yǔ)及自然語(yǔ)言描述，消息的參數(shù)表可以省略。2024/1/1923建模規(guī)則⑵無(wú)論是在分析階段還是在設(shè)計(jì)階段，建模者均應(yīng)聚焦于對(duì)象間關(guān)鍵的、主要的交互，避免因過(guò)多的細(xì)節(jié)而使順序圖含混不清、復(fù)雜不堪。例如①作為業(yè)務(wù)分析或需求分析模型的順序圖不必考慮用戶界面對(duì)象與業(yè)務(wù)對(duì)象之間的交互、數(shù)據(jù)的持久存儲(chǔ)等問(wèn)題。②除非特別必要，一般應(yīng)盡量避免顯式表示返回、創(chuàng)建、銷毀消息及對(duì)象生命終結(jié)符，也不需要顯式區(qū)分同步、異步消息。③勿需過(guò)多考慮對(duì)象的活躍期圖元，也不需顯式表示活躍期的嵌套，一般利用建模工具自動(dòng)生成的活躍期圖元即可。2024/1/1924建模規(guī)則⑶在設(shè)計(jì)和實(shí)現(xiàn)模型中，如果消息的參數(shù)與順序圖表述的控制邏輯無(wú)關(guān)，僅起占位符作用，則在消息的參數(shù)表中用參數(shù)的類型名（大寫字母開(kāi)頭）表示此參數(shù)；否則，應(yīng)盡量采用實(shí)例名（小寫字母開(kāi)頭）表示此參數(shù)，建模者應(yīng)保證順序圖的讀者能夠從實(shí)例名直觀、無(wú)歧義地推斷出參數(shù)的類型，如果不然，應(yīng)在參數(shù)表中同時(shí)示出參數(shù)類型和參數(shù)實(shí)例名。對(duì)消息的返回值，如果后續(xù)的消息需要在條件表達(dá)式或參數(shù)表中使用此返回值，則需給出其實(shí)例名；否則，如果建模者需要強(qiáng)調(diào)返回值類型，則可采用“消息名（參數(shù)表）:

返回值類型”的形式表示消息；其他情況下，應(yīng)忽略消息的返回值。2024/1/1925（四）布局規(guī)則盡管對(duì)象在水平軸上的次序沒(méi)有嚴(yán)格的語(yǔ)義信息，但建模應(yīng)遵循以下布局規(guī)則：⑴將用例的主動(dòng)執(zhí)行者實(shí)例安排在順序圖左側(cè)；被動(dòng)執(zhí)行者實(shí)例安排在順序圖右側(cè)。⑵采用分層設(shè)計(jì)時(shí)，應(yīng)將同層對(duì)象放在一起每層對(duì)象的排序規(guī)則是：接近用戶界面層靠左，接近后臺(tái)處理層（如，數(shù)據(jù)持久存儲(chǔ)層）靠右；因同層對(duì)象交互較多，相鄰層間的交互較少，跨層交互更少。2024/1/1926布局規(guī)則關(guān)于消息邊上文字的位置，有以下布局規(guī)則：⑴如果模型讀者辨識(shí)消息的目標(biāo)對(duì)象較辨識(shí)消息的源對(duì)象為難，則文字應(yīng)置于消息的目標(biāo)端；否則，文字應(yīng)置于消息的源端。當(dāng)消息的源和目標(biāo)都易于辨識(shí)時(shí)，建模者可將文字置于任意一端（不宜將文字置于消息邊的中間位置），但在本項(xiàng)目的所有順序圖中應(yīng)保持風(fēng)格一致。⑵返回消息上的文字一定要置于消息的目標(biāo)端。2024/1/19275.1.2通信圖通信圖是順序圖的另一種表現(xiàn)形式。如，圖5.5是與圖5.1所示的順序圖等價(jià)的通信圖（除注解外）2024/1/19282024/1/1929圖5.5課程注冊(cè)管理系統(tǒng)中“制訂選課計(jì)劃”用例的通信圖（一）通信圖概覽通信圖的構(gòu)成元素：⑴通信圖的節(jié)點(diǎn)是參與交互的對(duì)象，這些對(duì)象的表示方法與順序圖相同。由于不再設(shè)置單獨(dú)的時(shí)間維度，所以對(duì)象在通信圖中可自由定位。⑵對(duì)象之間的連接稱為連接器（connector），它扮演對(duì)象之間的消息傳遞通道的角色。連接器可以是無(wú)向的，表示此通道支持雙向的消息傳遞；也可以是有向的，此時(shí)消息只能沿連接器的方向傳遞。在連接器的兩端可以標(biāo)注角色名，這與類圖中的關(guān)聯(lián)邊相似。⑶在連接器上可以標(biāo)示一到多條消息。每條消息的傳遞方向用靠近消息的小箭頭表示。與順序圖一樣，通信圖中也可以區(qū)分同步、異步消息，以及返回消息、創(chuàng)建消息和銷毀消息。2024/1/1930通信圖概覽通信圖中消息的描述語(yǔ)法與順序圖稍有差異，形如：

[序號(hào)][迭代描述符][:][條件][返回值:=]消息名[(參數(shù)表)][:返回類型]，

其中：①消息序號(hào)采用多層結(jié)構(gòu)化標(biāo)號(hào)。如，“1.1”表示第1個(gè)步驟中的第1個(gè)子步驟，“1.2”在時(shí)序上一定位于“1.1”之后，“1.1.3”表示“1.1”中的第3個(gè)子步驟，如此等等。在序號(hào)中可以嵌入小寫字母表示線程名，用來(lái)強(qiáng)調(diào)并發(fā)的消息傳遞，如，“1.1a”和“1.1b”所標(biāo)引的消息在步驟“1.1”中可以并發(fā)傳遞，“1.1b.4”表示“1.1”步驟的第2個(gè)線程中的第4個(gè)子步驟。2024/1/1931通信圖概覽通信圖也可通過(guò)消息序號(hào)來(lái)表示消息傳遞的時(shí)間序，只不過(guò)這種表示不如順序圖那樣直觀。②迭代描述符形如“*[迭代條件]”，表示同一條消息的反復(fù)傳遞，見(jiàn)圖5.5中序號(hào)為、1.3和1.4的消息前的迭代描述符示例。③當(dāng)序號(hào)或迭代描述符出現(xiàn)時(shí)，第一個(gè)分隔符“:”必須出現(xiàn)；否則，該分隔符應(yīng)隱藏。④條件、返回值、消息名、參數(shù)表的表示及意義與順序圖相同。2024/1/1932通信圖概覽通信圖的對(duì)象圖元附近，可使用以下約束：①“{new}”表示該對(duì)象是在本通信圖表示的交互過(guò)程中因?qū)ο髣?chuàng)建消息而獲得生命的。②“{destroyed}”表示該對(duì)象是在本通信圖表示的交互過(guò)程中因?qū)ο箐N毀消息而結(jié)束生命的。③“{transient}”表示該對(duì)象在本通信圖表示的交互過(guò)程中既被創(chuàng)建，此后又被銷毀。2024/1/1933通信圖概覽如果兩個(gè)對(duì)象之間存在消息傳遞，那么它們所屬的類之間起碼應(yīng)存在依賴關(guān)系。這就要求建模者必須仔細(xì)檢查順序圖及通信圖與類圖之間的一致性。發(fā)現(xiàn)不一致性，有兩種處理方法：

在類圖中添加必要的依賴或關(guān)聯(lián)關(guān)系；

在整個(gè)項(xiàng)目中約定，如果兩個(gè)類的對(duì)象之間有消息傳遞，即便類圖中未顯示它們之間的依賴關(guān)系，也隱含地認(rèn)為該依賴關(guān)系實(shí)際上存在。

2024/1/1934（二）布局規(guī)則盡管對(duì)象在通信圖中可自由定位，但建模者應(yīng)遵循以下規(guī)則：⑴對(duì)象按行上下對(duì)齊，按列左右對(duì)齊，連接器繪制成水平線段、垂直線段或者由水平、垂直兩種線段組合而成的折線，避免斜線。⑵如果有用例的主動(dòng)執(zhí)行者的實(shí)例，則它應(yīng)位于通信圖的左上部；如果有用例的被動(dòng)執(zhí)行者的實(shí)例，則它應(yīng)位于通信圖的右側(cè)。⑶當(dāng)采用分層設(shè)計(jì)的思想（見(jiàn)第七章）時(shí)，分層對(duì)象的布局方法與順序圖中類似，不過(guò)通信圖允許同層的多個(gè)對(duì)象布局成多行、多列。⑷在遵守以上三條規(guī)則的同時(shí)，對(duì)象的排列應(yīng)盡量縮短連接器的長(zhǎng)度，并且盡量使消息的傳遞方向從左至右、從上至下。當(dāng)然，也不能禁絕從右至左、從下而上的消息傳遞。

2024/1/1935（三）順序圖與通信圖之間的選取順序圖和通信圖互為派生視圖，建模者往往面臨選用順序圖還是通信圖的困惑。建議讀者依次考慮以下規(guī)則（前面的規(guī)則優(yōu)先級(jí)較高）：⑴當(dāng)需要強(qiáng)調(diào)消息傳遞的時(shí)間序時(shí)采用順序圖；

當(dāng)需要強(qiáng)調(diào)對(duì)象之間的交互、協(xié)作關(guān)系時(shí)采用通信圖。⑵當(dāng)刻畫用例的動(dòng)作序列時(shí)，采用順序圖；

當(dāng)刻畫軟件內(nèi)部等某項(xiàng)功能的實(shí)現(xiàn)構(gòu)想時(shí)，采用通信圖。⑶在業(yè)務(wù)分析和需求建模階段，優(yōu)先考慮順序圖；在設(shè)計(jì)和實(shí)現(xiàn)階段，優(yōu)先考慮通信圖。2024/1/19365.1.3狀態(tài)圖定義：狀態(tài)圖描述一個(gè)實(shí)體在事件刺激下的反應(yīng)式動(dòng)態(tài)行為。構(gòu)成：它包含實(shí)體所有可能的狀態(tài)、在每個(gè)狀態(tài)下能夠響應(yīng)的事件以及事件發(fā)生時(shí)的狀態(tài)變遷與響應(yīng)動(dòng)作。實(shí)體可以是類的典型對(duì)象，也可以是一個(gè)軟件系統(tǒng)（或其子部分）或其中一個(gè)軟構(gòu)件，甚至也可以是包含目標(biāo)軟件系統(tǒng)的整個(gè)大系統(tǒng)。作用：狀態(tài)圖可分別用來(lái)描述一個(gè)類的典型對(duì)象、軟件系統(tǒng)、軟構(gòu)件或系統(tǒng)的行為。2024/1/1937狀態(tài)圖并不需要對(duì)所有類建立狀態(tài)圖，僅針對(duì)系統(tǒng)中比較重要的類，并且其對(duì)象的行為比較復(fù)雜，行為的狀態(tài)特征比較明顯的類建立狀態(tài)圖即可?！盃顟B(tài)特征明顯”指，對(duì)象在其生命周期中的行為模式與其當(dāng)前狀態(tài)相關(guān)，對(duì)于同一事件，對(duì)象的狀態(tài)不同會(huì)導(dǎo)致事件響應(yīng)行為的不同。圖5.6是對(duì)應(yīng)于課程注冊(cè)管理系統(tǒng)中“課程設(shè)置”類的狀態(tài)圖，圖5.7是對(duì)應(yīng)于某個(gè)購(gòu)物網(wǎng)中“注冊(cè)客戶”類的結(jié)構(gòu)化狀態(tài)圖。2024/1/1938圖5.6課程注冊(cè)管理系統(tǒng)中“課程設(shè)置”

類的典型對(duì)象的狀態(tài)圖2024/1/1939（一）狀態(tài)圖相關(guān)概念UML的狀態(tài)圖四個(gè)基本概念：

狀態(tài)

事件

活動(dòng)（activity）動(dòng)作（action）①狀態(tài)

對(duì)象的狀態(tài)對(duì)應(yīng)于由對(duì)象的屬性構(gòu)成的一個(gè)約束條件，無(wú)論對(duì)象在其生命周期中屬性值如何變化，當(dāng)屬性值滿足此約束條件時(shí)，對(duì)象對(duì)事件的響應(yīng)行為完全一樣。

因此，也可以將對(duì)象的狀態(tài)定義為對(duì)象的具有統(tǒng)一行為模式的某個(gè)生命周期階段。2024/1/1940②事件在對(duì)象生命周期中某時(shí)刻發(fā)生的、值得關(guān)注的針對(duì)該對(duì)象的一種瞬時(shí)刺激或觸動(dòng)，包括：消息型事件：

其他對(duì)象傳向該對(duì)象的同步消息，表示為“消息名[(參數(shù)表)]”；信號(hào)型事件：

其他對(duì)象傳向該對(duì)象的異步信號(hào)，表示為“信號(hào)名[(參數(shù)表)]”；時(shí)間型事件：

時(shí)間到達(dá)指定的絕對(duì)時(shí)刻點(diǎn)或到達(dá)指定時(shí)間之后的相對(duì)時(shí)刻點(diǎn)，分別表示為

“at(絕對(duì)時(shí)間點(diǎn))”、“after(基準(zhǔn)時(shí)間點(diǎn),時(shí)延)”；條件型事件：

對(duì)象所處環(huán)境及對(duì)象屬性值的變化導(dǎo)致某個(gè)條件成立，表示為“when(條件表達(dá)式)”。

信號(hào)型事件的命名最好采用過(guò)去式，例如，“……屬性已改變”。2024/1/1941相關(guān)概念③活動(dòng)和動(dòng)作都是計(jì)算過(guò)程，在過(guò)程中可以向?qū)ο蟀l(fā)送同步消息或異步信號(hào)，創(chuàng)建或刪除對(duì)象等?；顒?dòng)與動(dòng)作之間的差異在于：

動(dòng)作位于狀態(tài)之間的遷移邊上，比較簡(jiǎn)單，執(zhí)行時(shí)間短；活動(dòng)位于狀態(tài)中，可以比動(dòng)作復(fù)雜、執(zhí)行時(shí)間稍長(zhǎng)。2024/1/1942（二）基本機(jī)制狀態(tài)圖的基本機(jī)制：⑴狀態(tài)節(jié)點(diǎn)由狀態(tài)名及可選的入口活動(dòng)、出口活動(dòng)、do活動(dòng)、內(nèi)部遷移構(gòu)成。一旦對(duì)象經(jīng)遷移邊從其他狀態(tài)進(jìn)入本狀態(tài)，那么本狀態(tài)入口活動(dòng)將被執(zhí)行。一旦對(duì)象經(jīng)遷移邊從本狀態(tài)進(jìn)入其他狀態(tài)，那么本狀態(tài)的出口活動(dòng)將被執(zhí)行。do活動(dòng)是當(dāng)對(duì)象進(jìn)入本狀態(tài)并執(zhí)行完入口活動(dòng)（如果有的話）后應(yīng)該執(zhí)行的活動(dòng)。內(nèi)部遷移不會(huì)引起對(duì)象狀態(tài)的變化，所以它雖有源狀態(tài)（包含此遷移的狀態(tài)），但沒(méi)有目標(biāo)狀態(tài)。2024/1/1943基本機(jī)制⑵（外部）遷移表示為狀態(tài)節(jié)點(diǎn)之間的有向邊，自遷移是指源狀態(tài)節(jié)點(diǎn)與目標(biāo)狀態(tài)節(jié)點(diǎn)相同的特殊的外部遷移。有向邊上可以標(biāo)注

“[事件][監(jiān)護(hù)條件][/動(dòng)作]”“事件”表示觸發(fā)此次狀態(tài)變遷的事件“監(jiān)護(hù)條件”表示約束狀態(tài)遷移真正發(fā)生的條件表達(dá)式“動(dòng)作”表示狀態(tài)遷移期間應(yīng)當(dāng)執(zhí)行的動(dòng)作在監(jiān)護(hù)條件和動(dòng)作中均可引用觸發(fā)事件的參數(shù)和對(duì)象的屬性。2024/1/1944基本機(jī)制⑶頂層狀態(tài)圖包含初態(tài)和終態(tài)。它們均為特殊狀態(tài)，其中初態(tài)還是一種偽狀態(tài)（pseudostate），不真正對(duì)應(yīng)對(duì)象的屬性值的約束。一張狀態(tài)圖應(yīng)該恰有一個(gè)初態(tài)（所以不必對(duì)初態(tài)命名），可以有一到多個(gè)終態(tài)。初態(tài)和終態(tài)不能包含任何活動(dòng)或內(nèi)部遷移。初態(tài)只能發(fā)遷移邊，終態(tài)只能作為遷移邊的目標(biāo)如果狀態(tài)圖在時(shí)間方面覆蓋了對(duì)象的完整的生命周期，那么初態(tài)表示對(duì)象的誕生，然后沿初態(tài)出發(fā)的遷移邊到達(dá)某個(gè)狀態(tài)，終態(tài)表示對(duì)象將消亡2024/1/1945(三）結(jié)構(gòu)化機(jī)制結(jié)構(gòu)化機(jī)制是UML狀態(tài)圖的重要特色。它可以顯著提升其描述能力并簡(jiǎn)化狀態(tài)圖的表示。下面結(jié)合圖5.7圖簡(jiǎn)介UML狀態(tài)圖的結(jié)構(gòu)化機(jī)制。2024/1/1946圖5.7結(jié)構(gòu)化狀態(tài)圖示例2024/1/1947結(jié)構(gòu)化機(jī)制狀態(tài)s是由子狀態(tài)s1,…,sn經(jīng)AND（與）邏輯復(fù)合而成指，對(duì)象處于狀態(tài)s當(dāng)且僅當(dāng)對(duì)象同時(shí)處于s1,…,sn?？梢哉J(rèn)為復(fù)合狀態(tài)對(duì)應(yīng)的有關(guān)對(duì)象屬性值的約束公式能夠被分解為n個(gè)必須同時(shí)成立的子公式，每個(gè)子公式由一個(gè)子狀態(tài)來(lái)表示。UML將由AND邏輯復(fù)合而成的狀態(tài)稱為正交復(fù)合狀態(tài)如圖5.7所示，已注冊(cè)客戶的狀態(tài)被水平虛線分隔為上、下兩個(gè)正交區(qū)域，每個(gè)區(qū)域表示一個(gè)子狀態(tài)，分別表示“積分狀態(tài)”和“信用狀態(tài)”。當(dāng)對(duì)象處于正交復(fù)合狀態(tài)時(shí)，每個(gè)正交區(qū)域中恰有一個(gè)狀態(tài)是活躍的。2024/1/1948結(jié)構(gòu)化機(jī)制一個(gè)對(duì)象的狀態(tài)s由子狀態(tài)s1,…,sn經(jīng)XOR（異或）邏輯復(fù)合而成指，對(duì)象處于狀態(tài)s當(dāng)且僅當(dāng)對(duì)象處于s1,…,sn中的某個(gè)子狀態(tài)?？梢哉J(rèn)為子狀態(tài)si（1<=i<=n）繼承了復(fù)合狀態(tài)有關(guān)對(duì)象屬性值的約束，并增強(qiáng)了這種約束以使子狀態(tài)之間可以相互區(qū)分。UML將復(fù)合狀態(tài)s中的子狀態(tài)稱為直接子狀態(tài)。如，在圖5.7中，上面的正交區(qū)域所表示的復(fù)合狀態(tài)包含“普通”、“銀牌”、“金牌”3個(gè)直接子狀態(tài)。2024/1/1949結(jié)構(gòu)化機(jī)制除通過(guò)XOR和AND邏輯構(gòu)造復(fù)合狀態(tài)外，還可以將整張命名的狀態(tài)圖作為一個(gè)復(fù)合狀態(tài)，在另一狀態(tài)圖中以單個(gè)節(jié)點(diǎn)的方式引用，這就是狀態(tài)圖的復(fù)用機(jī)制。在復(fù)合狀態(tài)內(nèi)部的子狀態(tài)之間可以連接遷移邊，子狀態(tài)內(nèi)部也可包含各種活動(dòng)。復(fù)合狀態(tài)本身可以是以其子狀態(tài)為節(jié)點(diǎn)的普通狀態(tài)圖，但對(duì)正交復(fù)合狀態(tài)而言，遷移邊不可穿越正交區(qū)域分隔線。2024/1/1950（四）建模規(guī)則在狀態(tài)圖的建模過(guò)程中，應(yīng)遵循以下規(guī)則：⑴如果發(fā)現(xiàn)某些并非初態(tài)的狀態(tài)節(jié)點(diǎn)上只有離開(kāi)的遷移邊，沒(méi)有到達(dá)的遷移邊；或某些并非終態(tài)的狀態(tài)節(jié)點(diǎn)上只有到達(dá)的遷移邊，沒(méi)有出發(fā)的遷移邊，建模者就要高度警惕遷移邊被遺漏的可能性。⑵在頂層狀態(tài)圖中示出初態(tài)與終態(tài)，以使?fàn)顟B(tài)圖體現(xiàn)對(duì)象在其完整的生命周期中的行為。在子狀態(tài)圖中，初態(tài)和終態(tài)可視實(shí)際需要而設(shè)置。⑶狀態(tài)中的入口活動(dòng)必須適用于所有的到達(dá)遷移，出口活動(dòng)必須適用于所有的離開(kāi)遷移。2024/1/1951建模規(guī)則⑷從同一狀態(tài)出發(fā)、由同一事件觸發(fā)的遷移邊上的監(jiān)護(hù)條件應(yīng)該是互斥的。如果有兩個(gè)以上的監(jiān)護(hù)條件同時(shí)成立，具體執(zhí)行哪一條遷移邊將是不確定的。⑸使用結(jié)構(gòu)化狀態(tài)圖來(lái)描述對(duì)象的復(fù)雜行為，避免過(guò)于龐大的平板化狀態(tài)圖。⑹利用復(fù)合狀態(tài)合并遷移邊。如，針對(duì)圖5.7，從復(fù)合狀態(tài)“已注冊(cè)”邊框上出發(fā)的遷移邊等價(jià)于從該復(fù)合狀態(tài)中所有子狀態(tài)出發(fā)的12條遷移邊“積分狀態(tài)”的三個(gè)子狀態(tài)和“信用狀態(tài)”的四個(gè)子狀態(tài)可以組合出3ⅹ4=12個(gè)狀態(tài)。2024/1/1952（五）布局規(guī)則針對(duì)狀態(tài)圖，本書推薦以下布局規(guī)則：⑴狀態(tài)節(jié)點(diǎn)按行上下對(duì)齊，按列左右對(duì)齊，遷移邊繪制成水平線段、垂直線段或者由水平、垂直兩種線段組合而成的折線，避免斜線。⑵初態(tài)應(yīng)位于左上角，終態(tài)盡量靠近右下角。⑶遷移邊上的文本標(biāo)注應(yīng)靠近源狀態(tài)。2024/1/19535.1.4擴(kuò)充機(jī)制UML的擴(kuò)充機(jī)制的組成：約束（constraint）標(biāo)記值（taggedvalue）

構(gòu)造型（stereotype）2024/1/19545.1.4擴(kuò)充機(jī)制擴(kuò)充機(jī)制適合于以下應(yīng)用場(chǎng)景：⑴建模者希望向模型的讀者或?qū)崿F(xiàn)者傳遞UML標(biāo)準(zhǔn)語(yǔ)義無(wú)法表達(dá)的更為精細(xì)的語(yǔ)義信息。如，針對(duì)類中的操作，如果建模者希望區(qū)分查詢類操作（不改變對(duì)象的屬性值）和更改類操作，就必須借助擴(kuò)充機(jī)制。2024/1/1955擴(kuò)充機(jī)制⑵對(duì)于模型處理的CASE工具，依據(jù)標(biāo)準(zhǔn)的UML語(yǔ)義無(wú)法完成有關(guān)的處理功能，必須針對(duì)待處理的UML模型利用擴(kuò)充機(jī)制進(jìn)行人工標(biāo)注，在某些模型元素上附加更多語(yǔ)義信息。如，考察關(guān)聯(lián)關(guān)系之上的“1對(duì)多”型多重性，Java代碼生成工具很難確定使用何種Java集合類型來(lái)實(shí)現(xiàn)它，數(shù)組（array）、列表（list）還是普通的集合（collection）？如果在關(guān)聯(lián)端附加“有序”、“可變數(shù)量”兩條語(yǔ)義信息，代碼生成工具就可據(jù)此選用列表類型。2024/1/1956擴(kuò)充機(jī)制⑶針對(duì)特定的行業(yè)或特殊類別的應(yīng)用，利用擴(kuò)充機(jī)制定義專業(yè)性的術(shù)語(yǔ)和“方言”，以簡(jiǎn)化模型的表示，提高建模過(guò)程的效率。如，可以針對(duì)電信行業(yè)應(yīng)用建模的特殊需求擴(kuò)充UML的表示機(jī)制。又如，針對(duì)Web應(yīng)用，設(shè)計(jì)模型需要以簡(jiǎn)單的方式區(qū)分位于客戶端的類、位于Web服務(wù)端的類和后臺(tái)的業(yè)務(wù)邏輯類。

2024/1/1957（一）約束用處：約束可以附著于任何UML元素，甚至可以加諸多個(gè)UML元素，用來(lái)表達(dá)某種語(yǔ)義限制。約束的表現(xiàn)形式：

“{約束體}”或者“{［約束名:］約束體}”描述方法：約束體可以用自然語(yǔ)言描述，也可以用形式語(yǔ)言（包括OCL，甚至程序設(shè)計(jì)語(yǔ)言）來(lái)表述。注意：對(duì)約束命名是為了可以在別處引用已命名的約束，勿需重復(fù)定義。2024/1/1958約束約束可以出現(xiàn)在被約束的模型元素的附近，也可以出現(xiàn)在單獨(dú)的注解圖元中，此時(shí)需將注解圖元用虛線連向被約束元素。約束作用范圍的特別情形：針對(duì)垂直排列的列表型的模型元素說(shuō)明（例如類中的多個(gè)屬性、多個(gè)操作的定義），如果約束出現(xiàn)在模型元素所在行的右側(cè)，則該約束僅作用于同行的元素；如果約束單獨(dú)成行，則它作用于其下方的所有元素，即便其下方的某行的右側(cè)另有約束，右側(cè)的約束也只能加強(qiáng)而不能取代單獨(dú)成行的約束。2024/1/1959約束一個(gè)約束不僅可以同時(shí)作用于多個(gè)文本化的模型元素，還可以同時(shí)作用于模型中的多個(gè)圖元。如，在圖5.8中，兩個(gè)關(guān)聯(lián)關(guān)系的xor約束（UML標(biāo)準(zhǔn)約束）表示，一個(gè)Card對(duì)象只能參與兩個(gè)關(guān)聯(lián)關(guān)系之中的一個(gè)。2024/1/1960約束最常使用約束的模型元素包括：

類屬性操作:用約束表達(dá)前置、后置條件、不變式

關(guān)聯(lián)關(guān)系。2024/1/1961（二）標(biāo)記值標(biāo)記值其實(shí)就是名－值對(duì)，其中的值只能是字符串。標(biāo)記值可以單獨(dú)附著在模型元素之上，也可以位于構(gòu)造型（見(jiàn)后）的內(nèi)部，通過(guò)構(gòu)造型間接作用于模型元素。2024/1/1962標(biāo)記值的三種典型應(yīng)用場(chǎng)景（1）作為一種特殊的語(yǔ)義約束。如，在圖5.9中，針對(duì)Customer類的屬性“id”，因?yàn)椴辉试S用戶修改該屬性，建模者可以定義標(biāo)記值“isUserAssignable=false”并將其置于約束符之內(nèi)；OrderProcessor類中的操作“generateInvoice”該操作必須為事務(wù)性操作（如果操作在執(zhí)行過(guò)程中發(fā)生異常，則須清除該操作造成的影響，將系統(tǒng)回退至操作執(zhí)行前的狀態(tài)），建模者可以在該操作上附加“{isTx=true}”。采用構(gòu)造型可達(dá)到同樣效果，但標(biāo)記值更直接、簡(jiǎn)潔、明晰。2024/1/1963標(biāo)記值的三種典型應(yīng)用場(chǎng)景（2）作為非語(yǔ)義性的項(xiàng)目管理和信息跟蹤的標(biāo)注。如，在圖5.9中，針對(duì)OrderProcessor類，可標(biāo)注創(chuàng)建者、當(dāng)前狀態(tài)（未完成、已測(cè)試、修改中）等。這些信息對(duì)軟件的設(shè)計(jì)和實(shí)現(xiàn)沒(méi)有影響，但對(duì)軟件項(xiàng)目管理有一定價(jià)值。2024/1/1964標(biāo)記值的三種典型應(yīng)用場(chǎng)景（3）作為模型轉(zhuǎn)換和代碼生成工具的指引器。如，在關(guān)聯(lián)關(guān)系的多重性為“1對(duì)多”時(shí)，在關(guān)聯(lián)端標(biāo)注“{java.collection=List}”指示Java代碼生成器采用List類型實(shí)現(xiàn)這種關(guān)聯(lián)。圖5.9標(biāo)記值的表示法2024/1/1965（三）構(gòu)造型/泛型構(gòu)造型的表示如，<<構(gòu)造型名稱>>，其中構(gòu)造型名稱應(yīng)清晰地向模型讀者傳達(dá)自定義的語(yǔ)義信息，并不得與UML內(nèi)建的標(biāo)準(zhǔn)構(gòu)造型重名。如，如果建模者希望強(qiáng)調(diào)查詢型操作與修改型操作之間的差異，可以使用

<<query-op>>和<<modify-op>>；如果希望強(qiáng)調(diào)接口、抽象類與普通類之間的差異，可以使用

<<interface>>和<<abstract-class>>。2024/1/1966構(gòu)造型位置：將構(gòu)造型置于模型元素的名稱（如果有名稱）之前或者模型元素的上方（例如，作用于關(guān)聯(lián)關(guān)系、依賴關(guān)系之上的構(gòu)造型）。可以允許有多個(gè)構(gòu)造型作用于同一模型元素。當(dāng)一個(gè)構(gòu)造型作用于模型元素時(shí)，可以采用約束或者注解的形式明示構(gòu)造型中屬性的具體取值，見(jiàn)圖

圖5.10構(gòu)造型的使用2024/1/1967構(gòu)造型允許針對(duì)構(gòu)造型定義特殊的圖符，此后可以用此圖符代替構(gòu)造型的文字形式，甚至取代模型元素本身，見(jiàn)圖5.11。不推薦圖5.11的后兩種表現(xiàn)方式（尤其是第三種方式，它隱藏的信息太多），除非這些圖元意義明確，并能被普遍接受。圖5.11構(gòu)造型的圖元表示

2024/1/19685.2需求分析的過(guò)程模型如何展開(kāi)需求分析？應(yīng)該遵循何種過(guò)程模型來(lái)展開(kāi)需求分析？需求分析的主要任務(wù)是：建立比用例模型更完整、更精細(xì)的分析模型，以期獲得對(duì)軟件需求的更深入理解，提高軟件需求的質(zhì)量，為軟件設(shè)計(jì)奠定更堅(jiān)實(shí)的基礎(chǔ)。2024/1/1969需求分析的過(guò)程模型用例分析：為了提高需求模型的精確性，有必要針對(duì)用例的自然語(yǔ)言描述進(jìn)行分析，將其轉(zhuǎn)化為更精確的UML模型?；谟美治龅玫降腢ML模型圖比自然語(yǔ)言描述更便于檢查軟件需求的一致性和無(wú)冗余性；這種模型圖在一定程度上引入了用例功能的邏輯設(shè)計(jì)方案，從而更便于檢查軟件需求的可實(shí)現(xiàn)性，便于識(shí)別用例功能的實(shí)現(xiàn)風(fēng)險(xiǎn)，也有利于提高其可驗(yàn)證性。2024/1/1970需求分析的過(guò)程模型為何要在需求工程階段引入設(shè)計(jì)方案？

因?yàn)椤癢hat”（軟件需求）與“How”（軟件設(shè)計(jì)）之間的區(qū)隔不是絕對(duì)的，“How”往往可以用來(lái)說(shuō)明“What”。對(duì)于不太熟悉軟件問(wèn)題的業(yè)務(wù)背景的軟件設(shè)計(jì)師而言，毫無(wú)設(shè)計(jì)意味的“What”描述不僅難以理解，容易造成歧義性，而且也難以檢查其可實(shí)現(xiàn)性，難以發(fā)現(xiàn)其實(shí)現(xiàn)風(fēng)險(xiǎn)。2024/1/1971需求分析的過(guò)程模型用例驅(qū)動(dòng)的需求分析過(guò)程的主要活動(dòng)如下⑴需求優(yōu)先級(jí)分析。⑵用例分析。⑶分析模型評(píng)審。⑷為輔助需求分析而構(gòu)建快速原型。這些活動(dòng)可按序組織為需求分析工作流。圖5.12需求分析工作流2024/1/19725.3需求優(yōu)先級(jí)分析需求優(yōu)先級(jí)分析的主要任務(wù)是為每項(xiàng)需求確定優(yōu)先級(jí)。有三種不同的需求優(yōu)先級(jí)含義：⑴基于實(shí)現(xiàn)緊迫度的優(yōu)先級(jí)：高優(yōu)先級(jí)表示在當(dāng)前軟件版本中必須實(shí)現(xiàn)的需求項(xiàng)；中優(yōu)先級(jí)表示最終必須實(shí)現(xiàn)的需求項(xiàng)，但在資源緊張時(shí)可以延至下一軟件版本再實(shí)現(xiàn)；低優(yōu)先級(jí)表示“錦上添花”式的需求項(xiàng)，在資源充分時(shí)其實(shí)現(xiàn)會(huì)使軟件產(chǎn)品更趨于完美。2024/1/1973確定需求項(xiàng)優(yōu)先級(jí)⑵基于需求實(shí)現(xiàn)度的優(yōu)先級(jí)：高優(yōu)先級(jí)表示在當(dāng)前軟件版本中必須完整并盡可能完美實(shí)現(xiàn)的需求項(xiàng)；中優(yōu)先級(jí)表示在資源緊張時(shí)可有小部分不予實(shí)現(xiàn)的需求項(xiàng)，并且其實(shí)現(xiàn)允許出現(xiàn)無(wú)關(guān)緊要的瑕疵；低優(yōu)先級(jí)表示可以有部分甚至完全不予實(shí)現(xiàn)的需求項(xiàng)，其實(shí)現(xiàn)允許出現(xiàn)缺陷。2024/1/1974確定需求項(xiàng)優(yōu)先級(jí)⑶基于產(chǎn)品可接受度的優(yōu)先級(jí)：基本需求項(xiàng)表示軟件產(chǎn)品為利益相關(guān)方接受所必需的需求項(xiàng)；條件需求項(xiàng)表示可以增強(qiáng)其滿意度的需求項(xiàng)，但是，即使不予實(shí)現(xiàn)，利益相關(guān)方仍可接受該軟件產(chǎn)品；可選需求項(xiàng)類似于條件需求項(xiàng)，其對(duì)軟件產(chǎn)品的可接受度的影響更弱。2024/1/19755.3需求優(yōu)先級(jí)分析需求優(yōu)先級(jí)分析的主要任務(wù)是為每項(xiàng)需求確定優(yōu)先級(jí)。需求優(yōu)先級(jí)取決于三個(gè)因素的綜合作用：需求項(xiàng)為利益相關(guān)方提供的價(jià)值

需求項(xiàng)的實(shí)現(xiàn)成本

實(shí)現(xiàn)過(guò)程中的風(fēng)險(xiǎn)?？蓪⑦@些因素量化為若干級(jí)別，再結(jié)合項(xiàng)目可用資源約束來(lái)計(jì)算：優(yōu)先級(jí)＝價(jià)值/(成本×成本權(quán)值＋風(fēng)險(xiǎn)×風(fēng)險(xiǎn)權(quán)值)2024/1/1976表5.1家庭保安系統(tǒng)的需求優(yōu)先級(jí)序號(hào)用例/質(zhì)量需求項(xiàng)名稱優(yōu)先級(jí)說(shuō)明1開(kāi)關(guān)機(jī)及復(fù)位處理高必須完整實(shí)現(xiàn)2系統(tǒng)配置高同上3傳感器監(jiān)測(cè)高同上4日志查詢中應(yīng)該實(shí)現(xiàn)其中大部分功能5性能：Req-Performance-001~002高對(duì)產(chǎn)品可接受度的影響最大6可靠性：Req-Reliability-001~003高同上7安全性：Req-Authentication-001和Req-Authorization-001高同上8可配置性：Req-Config-001高同上9安全性：Req-Audit-001中對(duì)產(chǎn)品可接受度有一定影響10易用性：Req-EasyUse-001~002中同上11可擴(kuò)展性：Req-Extend-001中同上12可伸縮性：Req-Scalability-001中同上13兼容性：Req-Compatibility-001低可以不予實(shí)現(xiàn)，但其實(shí)現(xiàn)可以增強(qiáng)產(chǎn)品可接受度14本地化與國(guó)際化：Req-Intl-001低同上2024/1/19775.3.2編排用例分析的優(yōu)先順序編排用例分析的優(yōu)先次序。⑴對(duì)系統(tǒng)架構(gòu)影響較大的用例優(yōu)先。⑵對(duì)用戶需求的實(shí)現(xiàn)貢獻(xiàn)較大的用例優(yōu)先。⑶在迭代式開(kāi)發(fā)過(guò)程中，能夠較多地覆蓋高風(fēng)險(xiǎn)面的一組用例優(yōu)先。2024/1/1978編排用例分析的優(yōu)先順序例5.2確定用例分析的次序針對(duì)家庭保安系統(tǒng)，按照表5.1所確定的需求優(yōu)先級(jí)，同時(shí)考慮到用例之間的邏輯關(guān)聯(lián)，決定首先分析表5.1中的前三個(gè)用例，再分析第四個(gè)用例。2024/1/19795.4用例分析用例分析的目標(biāo)：是將用例模型中關(guān)于用例的自然語(yǔ)言描述轉(zhuǎn)化為更接近于軟件設(shè)計(jì)的分析模型。用例分析的作用：用例分析開(kāi)啟從軟件需求邁向軟件設(shè)計(jì)的征程。在需求工程階段引入用例分析是為了得到比用例模型更加精確的分析模型通過(guò)分析模型的創(chuàng)建和評(píng)審不斷提高軟件需求的精確性、一致性、完全性、無(wú)冗余性、可實(shí)現(xiàn)性和可驗(yàn)證性。2024/1/1980用例分析用例分析的子活動(dòng)歸納如下：⑴精化領(lǐng)域概念模型；⑵設(shè)置分析類；⑶構(gòu)思分析類之間協(xié)作關(guān)系；⑷導(dǎo)出分析類圖。其中，分析類的定義為：邏輯層面按照用例所表示的軟件需求而構(gòu)思的類類及其協(xié)作關(guān)系?！胺治鲱悺钡亩x以區(qū)隔于在軟件設(shè)計(jì)和構(gòu)造階段分別引進(jìn)的“設(shè)計(jì)類”和“實(shí)現(xiàn)類”。2024/1/19815.4.1精化領(lǐng)域概念模型精化領(lǐng)域概念模型的目標(biāo)是：

提取跨越多個(gè)用例的全局性、關(guān)鍵性公共概念，表達(dá)這些概念的內(nèi)涵及其相互關(guān)系，為后續(xù)的需求分析活動(dòng)奠定公共的概念基礎(chǔ)。2024/1/1982精化領(lǐng)域概念模型執(zhí)行本活動(dòng)的基本方法是：

在需求獲取活動(dòng)得到的領(lǐng)域概念模型的基礎(chǔ)上，結(jié)合用例描述和業(yè)務(wù)術(shù)語(yǔ)字典，提取多個(gè)用例中相同或相似的概念，統(tǒng)一命名，標(biāo)識(shí)其中蘊(yùn)藏的屬性，研究它們之間是否存在繼承關(guān)系、關(guān)聯(lián)關(guān)系，將精化后的領(lǐng)域概念模型表示為UML類圖。提取概念標(biāo)識(shí)屬性研究關(guān)系2024/1/1983精化領(lǐng)域概念模型本活動(dòng)的關(guān)鍵在于確保在后續(xù)的用例分析過(guò)程中使用統(tǒng)一定義的業(yè)務(wù)概念，精細(xì)化和完整性不是重點(diǎn)。因?yàn)轭悎D的精化將貫穿分析和設(shè)計(jì)的全過(guò)程：此時(shí)可暫不考慮概念類中的操作，屬性列表不必完整，勿需在概念之間標(biāo)識(shí)除繼承和關(guān)聯(lián)之外的其他關(guān)系。2024/1/1984例5.3精化領(lǐng)域概念模型基于圖4-7所示的家庭保安系統(tǒng)初步的領(lǐng)域概念模型，考慮到“開(kāi)關(guān)機(jī)及復(fù)位處理”、“系統(tǒng)配置”和“傳感器監(jiān)測(cè)”用例均需記錄日志，“日志查詢”用例需要使用該日志，所以引入“日志”概念類，其主要屬性包括時(shí)間、動(dòng)作描述、動(dòng)作執(zhí)行者。由于報(bào)警時(shí)必須描述異常事件的發(fā)生位置并且在日志中記錄發(fā)現(xiàn)異常的傳感器編號(hào)，所以“傳感器”概念類具有“編號(hào)”和“安裝位置”兩項(xiàng)屬性。2024/1/1985圖5.13家庭保安系統(tǒng)的領(lǐng)域概念模型（精化）2024/1/19865.4.2設(shè)置分析類分析類：是指直接服務(wù)于軟件的功能性需求的概念層面的類，它與待開(kāi)發(fā)軟件系統(tǒng)的具體實(shí)現(xiàn)技術(shù)無(wú)關(guān)。從功能需求的角度看，用例的業(yè)務(wù)邏輯處理功能主要由邊界類、控制類和實(shí)體類三種分析類協(xié)同完成。2024/1/1987邊界類負(fù)責(zé)目標(biāo)軟件系統(tǒng)與外部執(zhí)行者之間的交互，包括：⑴界面控制

包括輸入數(shù)據(jù)的格式及內(nèi)容轉(zhuǎn)換，輸出結(jié)果的呈現(xiàn)，軟件運(yùn)行過(guò)程中界面的變化與切換等。⑵外部接口

實(shí)現(xiàn)目標(biāo)軟件系統(tǒng)與外部系統(tǒng)或外部設(shè)備之間的信息交流和互操作。主要關(guān)注跨越目標(biāo)軟件系統(tǒng)邊界的通信協(xié)議。⑶環(huán)境隔離

將目標(biāo)軟件系統(tǒng)與操作系統(tǒng)、數(shù)據(jù)庫(kù)管理系統(tǒng)、應(yīng)用服務(wù)器中間件等環(huán)境軟件進(jìn)行交互的功能與特性封裝于邊界類之中，使目標(biāo)軟件系統(tǒng)的其余部分盡可能地獨(dú)立于環(huán)境軟件。2024/1/1988設(shè)置分析類在UML類圖中，邊界類往往附加UML構(gòu)造型《boundary》作為特別標(biāo)識(shí)。例如，家庭保安系統(tǒng)中可能的邊界類有“輸入鍵盤接口”、“傳感器接口”、“警報(bào)器接口”、“報(bào)警電話接口”和“顯示面板接口”。2024/1/1989設(shè)置分析類控制類：作為完成用例任務(wù)的責(zé)任承擔(dān)者，負(fù)責(zé)協(xié)調(diào)、控制其他類共同完成用例規(guī)定的功能或行為。對(duì)于比較復(fù)雜的用例，控制類通常并不處理具體的任務(wù)細(xì)節(jié)，但是它應(yīng)知道如何分解任務(wù)，如何將子任務(wù)分派給其他類，如何協(xié)調(diào)這些類的工作?？刂祁惖腢ML構(gòu)造型為《control》。如，在家庭保安系統(tǒng)中，“監(jiān)測(cè)器”是典型的控制類。2024/1/1990設(shè)置分析類實(shí)體類負(fù)責(zé)保存目標(biāo)軟件系統(tǒng)中具有持久意義的信息項(xiàng)并向其他類提供信息訪問(wèn)的操作。實(shí)體類的操作具有“內(nèi)向收斂”特征，它們僅向目標(biāo)軟件系統(tǒng)的其余部分提供讀、寫信息項(xiàng)內(nèi)容的必要的操作接口，一般不涉及業(yè)務(wù)邏輯處理。實(shí)體類的UML構(gòu)造型為《entity》。如，在家庭保安系統(tǒng)中，“異常事件”和“日志”均為實(shí)體類。2024/1/1991設(shè)置分析類從分析模型中的用例描述和精化后的領(lǐng)域概念模型出發(fā)提取分析類的方法：通常情況下，執(zhí)行者與用例之間的一種通信連接對(duì)應(yīng)一個(gè)邊界類。注意，邊界類的作用范圍可以超越單個(gè)用例。2024/1/1992設(shè)置分析類一個(gè)用例通常對(duì)應(yīng)一個(gè)控制類。如果不同用例的任務(wù)有較多類似之處，也可以考慮在多個(gè)用例的實(shí)現(xiàn)方案中共享同一控制類。如果一個(gè)用例非常復(fù)雜，可以針對(duì)它設(shè)置多個(gè)控制類，每個(gè)類負(fù)責(zé)該用例中的某項(xiàng)子功能。另一方面，對(duì)于非常簡(jiǎn)單的用例，可以將控制類與邊界類合并。2024/1/1993設(shè)置分析類實(shí)體類主要來(lái)源于領(lǐng)域概念模型和用例描述中具有持久意義的信息項(xiàng)。實(shí)體類一般與特定的業(yè)務(wù)邏輯關(guān)系不大，因此其作用范圍往往超越單個(gè)用例而被多個(gè)用例共享。如果參與用例的執(zhí)行者的屬性需要持久保存，也可以建立相應(yīng)的實(shí)體類。2024/1/1994例5.4設(shè)置分析類基于家庭保安系統(tǒng)的軟件需求的用例模型及圖5.13所示的領(lǐng)域概念模型，分析類的設(shè)置過(guò)程及結(jié)果如下：⑴設(shè)置邊界類“傳感器接口”、“輸入鍵盤接口”、“顯示面板接口”、“警報(bào)器接口”和“報(bào)警電話接口”它們依次負(fù)責(zé)、參與用例的執(zhí)行者“傳感器”、“輸入鍵盤”、“顯示面板”、“警報(bào)器”和“報(bào)警電話”進(jìn)行交互。2024/1/1995設(shè)置分析類⑵控制類的設(shè)置與用例息息相關(guān)，必須逐個(gè)用例地研究如何設(shè)置控制類。①針對(duì)用例“開(kāi)關(guān)機(jī)及復(fù)位處理”，可以設(shè)置單個(gè)控制類“命令處理器”來(lái)完成開(kāi)機(jī)、關(guān)機(jī)和復(fù)位命令的處理。②針對(duì)用例“系統(tǒng)配置”，可以設(shè)置“配置管理器

”控制類負(fù)責(zé)系統(tǒng)配置信息的保存、提取和修改。

……2024/1/1996設(shè)置分析類⑶領(lǐng)域概念模型中的“異常事件”、“日志”應(yīng)該作為實(shí)體類。由于系統(tǒng)需要持久保存執(zhí)行者“傳感器”、“門窗傳感器”、“煙霧傳感器”和“報(bào)警電話”的某些屬性（例如傳感器安裝位置、門窗傳感器的靈敏度、報(bào)警電話號(hào)碼等），所以也將它們作為實(shí)體類。2024/1/1997設(shè)置分析類對(duì)分類繪制狀態(tài)圖如果分析類的狀態(tài)特征突出并且該類在整個(gè)目標(biāo)軟件系統(tǒng)中占有重要地位，可考慮在分析模型中專門針對(duì)它繪制狀態(tài)圖，以便在后續(xù)的軟件開(kāi)發(fā)活動(dòng)中正確、深入地理解該分析類。例如，在課程注冊(cè)管理系統(tǒng)中，“課程設(shè)置”對(duì)象的狀態(tài)-事件-響應(yīng)行為如圖5.6所示。2024/1/19985.4.3構(gòu)思分析類之間的協(xié)作關(guān)系在標(biāo)識(shí)分析類之后，接下來(lái)的任務(wù)是，將用例模型中的用例描述轉(zhuǎn)化成UML交互圖，以交互圖作為用例的更精確、更直觀、更結(jié)構(gòu)化的表示形式。構(gòu)造交互圖的關(guān)鍵在于將用例的各項(xiàng)功能分解并分派至合適的分析類，并研究分析類之間如何通過(guò)消息傳遞來(lái)協(xié)同地完成各項(xiàng)功能。交互圖有助于需求工程師更深入地理解、分析軟件需求，剔除用例描述中的模糊性、不一致性、不完整性，同時(shí)也為后續(xù)的軟件設(shè)計(jì)奠定基礎(chǔ)。2024/1/1999構(gòu)思分析類之間的協(xié)作關(guān)系用例描述中已包含交互動(dòng)作說(shuō)明。用例中發(fā)生在執(zhí)行者與系統(tǒng)之間的交互事件直接對(duì)應(yīng)于交互圖中執(zhí)行者與邊界類之間的消息，用例描述中事件間的先后關(guān)系體現(xiàn)為交互圖中的時(shí)序。典型的用例功能的完成過(guò)程基本上遵循如下過(guò)程框架。⑴主動(dòng)執(zhí)行者向邊界類發(fā)出命令。⑵邊界類僅僅完成必要的輸入信息解析工作，將命令以控制類可識(shí)別的內(nèi)部表示形式傳向控制類。2024/1/19100構(gòu)思分析類之間的協(xié)作關(guān)系⑶控制類為了完成命令所要求的業(yè)務(wù)邏輯處理，可能向?qū)嶓w類發(fā)送消息以獲取必要的信息項(xiàng)，也可能向?qū)嶓w類發(fā)送消息以持久保存業(yè)務(wù)邏輯處理的部分結(jié)果。⑷控制類將業(yè)務(wù)邏輯處理的部分結(jié)果通知邊界類。⑸邊界類針對(duì)處理結(jié)果進(jìn)行必要的從內(nèi)部表示形式向外部表示形式的變換，再傳遞給被動(dòng)執(zhí)行者。2024/1/19101構(gòu)思分析類之間的協(xié)作關(guān)系根據(jù)上述過(guò)程框架，需求工程師應(yīng)可針對(duì)用例描述推導(dǎo)出在三種分析類之間傳遞的消息及其時(shí)序。需求工程師在分析用例模型時(shí)必須基于此過(guò)程框架進(jìn)行靈活變通，變通的依據(jù)是其對(duì)用例描述的理解。如，步驟(3)可能沒(méi)有必要；步驟(2)和(5)中的邊界類可能是同一個(gè)類；步驟(2)中的邊界類可能沒(méi)有必要，主動(dòng)執(zhí)行者直接向控制類發(fā)出命令；等。2024/1/19102構(gòu)思分析類之間的協(xié)作關(guān)系按照上述過(guò)程框架，在UML順序圖中類的布局主動(dòng)執(zhí)行者|邊界類|控制類|邊界類|被動(dòng)執(zhí)行者如此布局之后，在順序圖中不應(yīng)該出現(xiàn)穿越控制類生命線的消息，也即，用例實(shí)現(xiàn)方案中的前端處理、核心業(yè)務(wù)邏輯、后端處理已經(jīng)被適當(dāng)隔離。2024/1/19103圖5.14典型布局規(guī)則下的順序圖2024/1/19104構(gòu)思分析類之間的協(xié)作關(guān)系當(dāng)需要強(qiáng)調(diào)分析類之間的聯(lián)系或連接時(shí)，就需要繪制通信圖。通信圖的布局規(guī)則是：控制類位于中心；主動(dòng)執(zhí)行者和作為用戶界面或外部接口的邊界類位于左上方，主動(dòng)執(zhí)行者位于此種邊界類的左面；被動(dòng)執(zhí)行者和作為外部接口和環(huán)境隔離層的邊界類位于右上方，被動(dòng)執(zhí)行者位于此種邊界類的右面；實(shí)體類位于控制類的下方。按照此布局規(guī)則繪制的典型的通信圖如圖5.15所示。2024/1/19105圖5.15典型布局規(guī)則下的通信圖2024/1/19106構(gòu)思分析類之間的協(xié)作關(guān)系為了簡(jiǎn)化交互圖，可以省略位于系統(tǒng)邊界之外的被動(dòng)執(zhí)行者（這些執(zhí)行者與邊界類之間傳遞的消息當(dāng)然也一并省略），甚至也可以省略位于系統(tǒng)邊界之外的主動(dòng)執(zhí)行者。在交互圖中，可以借助文字注解闡述一些難以用UML圖形設(shè)施表達(dá)的語(yǔ)義。文字注解包括指向消息的注解和面向時(shí)間段的注解，見(jiàn)圖5.14。2024/1/19107構(gòu)思分析類之間的協(xié)作關(guān)系如何利用交互圖表示用例描述中的擴(kuò)展交互動(dòng)作序列？如果擴(kuò)展交互動(dòng)作序列比較簡(jiǎn)單，可以直接在交互圖中合并表示基本與擴(kuò)展的交互動(dòng)作序列，見(jiàn)圖5.16。否則，應(yīng)采用單獨(dú)的交互圖來(lái)表示擴(kuò)展交互動(dòng)作序列，并采用UML交互圖的結(jié)構(gòu)化機(jī)制

，在基本交互動(dòng)作序列的交互圖中直接引用擴(kuò)展交互圖中的消息序列，見(jiàn)圖5.17。2024/1/19108例5.5構(gòu)思分析類之間的協(xié)作關(guān)系圖5.16（p113例4.8）是家庭保安系統(tǒng)中“傳感器監(jiān)測(cè)”用例的順序圖，該圖合并表示了基本和擴(kuò)展的交互動(dòng)作序列。其中的關(guān)鍵字“l(fā)oop”引領(lǐng)循環(huán)結(jié)構(gòu)塊，位于塊內(nèi)最上方的條件為循環(huán)控制條件。只要該條件成立，那么循環(huán)結(jié)構(gòu)塊中自上至下的消息傳遞的動(dòng)作序列將周而復(fù)始地執(zhí)行，直到條件不成立為止。圖5.17利用UML順序圖的結(jié)構(gòu)化機(jī)制分別表示該用例的基本和擴(kuò)展的交互動(dòng)作序列。其中的關(guān)鍵字“ref”表示對(duì)另一順序圖的引用，關(guān)鍵字“alt”引領(lǐng)條件結(jié)構(gòu)塊，它包含多個(gè)以水平虛線分隔的區(qū)域，每個(gè)區(qū)域表示一個(gè)條件分支，分支的條件一般出現(xiàn)在區(qū)域的上部。2024/1/19109圖5.16“傳感器監(jiān)測(cè)”用例的順序圖

2024/1/19110圖5.17“傳感器監(jiān)測(cè)”用例的結(jié)構(gòu)化順序圖

(a)基本交互動(dòng)作序列的順序圖表示

2024/1/19111

圖5.17“傳感器監(jiān)測(cè)”用例的結(jié)構(gòu)化順序圖

(b)擴(kuò)展交互動(dòng)作序列的順序圖表示

2024/1/19112構(gòu)思分析類之間的協(xié)作關(guān)系分析類之間的協(xié)作關(guān)系不僅可以用UML交互圖表示，也可以用活動(dòng)圖表示。如，針對(duì)課程注冊(cè)管理系統(tǒng)中的“制訂課表”用例，其分析類間協(xié)作關(guān)系的活動(dòng)圖表示見(jiàn)圖4-5。與交互圖相比，活動(dòng)圖不便于從消息傳遞推導(dǎo)出分析類的職責(zé)，所以在用例分析階段活動(dòng)圖的受歡迎程度不及交互圖?；顒?dòng)圖適于表示分析類職責(zé)實(shí)施的內(nèi)部細(xì)節(jié)，所以，在需求分析的后期，?？衫没顒?dòng)圖來(lái)精化分析類的職責(zé)、細(xì)化分析類的對(duì)象之間的消息傳遞，但應(yīng)避免過(guò)早陷入設(shè)計(jì)和實(shí)現(xiàn)細(xì)節(jié)。2024/1/191135.4.4導(dǎo)出分析類圖本步驟進(jìn)一步將消息的響應(yīng)對(duì)應(yīng)到分析類的職責(zé)，從而推動(dòng)分析模型的建立和精化，持續(xù)邁向軟件設(shè)計(jì)和編程實(shí)現(xiàn)。從用例描述中的事件及動(dòng)作序列，到交互圖中的消息，再到分析類的職責(zé)，最后演變?yōu)樵O(shè)計(jì)元素的功能或方法，這個(gè)進(jìn)化過(guò)程是面向?qū)ο蠓治雠c設(shè)計(jì)過(guò)程的關(guān)鍵2024/1/19114（一）創(chuàng)建初始的分析類圖比較并研究領(lǐng)域概念模型和交互圖，以領(lǐng)域概念模型為基礎(chǔ)創(chuàng)建初始的分析類圖。如果交互圖中出現(xiàn)了某個(gè)對(duì)象，其所屬的分析類未在領(lǐng)域概念模型中出現(xiàn)，則應(yīng)在分析類圖中添加此分析類；反之，針對(duì)領(lǐng)域概念模型中的類，如果其對(duì)象未在任何交互圖中出現(xiàn)，則需求工程師必須判斷該類是否對(duì)用戶需求的實(shí)現(xiàn)有所貢獻(xiàn)。如果該類作為交互圖中某條消息的參數(shù)類型或返回值類型，或者該類的對(duì)象包含消息響應(yīng)函數(shù)所必需的信息，那么答案應(yīng)該是肯定的，該類應(yīng)該在分析類圖中出現(xiàn)。否則，如果領(lǐng)域概念模型中的類與用戶需求的實(shí)現(xiàn)無(wú)關(guān)，那么必須將該類從分析類圖中剔除。2024/1/19115例5.6創(chuàng)建初始的分析類圖對(duì)家庭保安系統(tǒng)，在圖5.13所示的領(lǐng)域概念模型的基礎(chǔ)上，圖5.16所示的“傳感器監(jiān)測(cè)”用例的交互圖新引進(jìn)了“傳感器接口”、“配置管理器

”、“日志管理器”、“警報(bào)器接口”、“報(bào)警電話接口”、“顯示面板接口”

5個(gè)分析類；為節(jié)約篇幅，針對(duì)其他3個(gè)用例的交互圖雖未示出，但讀者基于例5.4容易推知這些交互圖將引進(jìn)“輸入鍵盤接口”、“顯示面板接口”、“命令處理器”、“配置管理器

”、“日志管理器”

及例5.4所述的所有實(shí)體類。如此得到的分析類圖，見(jiàn)圖5.18。2024/1/19116圖5.18家庭保安系統(tǒng)的分析類圖（初步）2024/1/19117（二）根據(jù)消息確定分析類的職責(zé)原則上，對(duì)每個(gè)分析類都應(yīng)該安排一項(xiàng)職責(zé)來(lái)響應(yīng)交互圖中指向其對(duì)象的那條消息。但這并不意味著消息與職責(zé)一定會(huì)一一對(duì)應(yīng)，因?yàn)榉治鲱惖囊豁?xiàng)職責(zé)可能具有響應(yīng)多條消息的能力。至于分析類圖中職責(zé)的描述方式，既可以嚴(yán)格地采用UML中類的操作的表示，也可以僅采用簡(jiǎn)短的自然語(yǔ)言。無(wú)論采用何種描述方式，必要時(shí)都應(yīng)通過(guò)UML的注解機(jī)制闡明分析類的職責(zé)的含義。職責(zé)的參數(shù)可以暫時(shí)忽略，也可以顯式標(biāo)出，此時(shí)必須確保職責(zé)的參數(shù)與交互圖中相應(yīng)消息的參數(shù)保持一致。2024/1/19118根據(jù)消息確定分析類的職責(zé)在確立分析類的職責(zé)時(shí)，必須遵循面向?qū)ο蟮淖匀恍栽瓌t。即，在業(yè)務(wù)領(lǐng)域背景下，每項(xiàng)職責(zé)均須分派至最自然地?fù)碛写隧?xiàng)職責(zé)、最適合擔(dān)當(dāng)此項(xiàng)職責(zé)的分析類。如果在交互圖中某條消息被發(fā)往不適合接收此消息的對(duì)象，那么首先應(yīng)修改交互圖，再基于精化后的交互圖確定分析類的職責(zé)。如，將“分析傳感數(shù)據(jù)”消息發(fā)給“配置管理器”

對(duì)象就不如發(fā)給“監(jiān)測(cè)器”對(duì)象來(lái)得合理、自然。2024/1/19119例5.7確定分析類的職責(zé)對(duì)家庭保安系統(tǒng)中的“監(jiān)測(cè)器”類，它在圖5.16中負(fù)責(zé)響應(yīng)“分析傳感數(shù)據(jù)”消息，所以它必須具有分析傳感數(shù)據(jù)、發(fā)現(xiàn)異常時(shí)報(bào)警的職責(zé)。結(jié)合圖5.16及例4-8中對(duì)“傳感器監(jiān)測(cè)”用例的描述，可以推知該項(xiàng)職責(zé)的具體內(nèi)容是：（1）基于系統(tǒng)配置中的門窗監(jiān)測(cè)靈敏度或煙霧濃度閾值，判別數(shù)據(jù)是否正常；（2）如果不正常，則生成“異常事件”對(duì)象，要求“日志管理器”記錄該異常，啟動(dòng)警報(bào)器，撥報(bào)警電話，在顯示面板上顯示異常事件的發(fā)生時(shí)間、位置及內(nèi)容。2024/1/19120確定分析類的職責(zé)“報(bào)警電話接口”類在圖5.16中負(fù)責(zé)響應(yīng)“報(bào)告異常事件”消息，所以它必須具有“報(bào)告異常事件”的職責(zé)，基于例4-8可以推知該項(xiàng)職責(zé)的具體內(nèi)容是：（1）撥報(bào)警電話號(hào)碼直至接通或者重?fù)艽螖?shù)達(dá)到系統(tǒng)配置的最大重?fù)艽螖?shù)。（2）電話撥通后播出語(yǔ)音，報(bào)告異常事件發(fā)生的時(shí)間、位置、類別和事件內(nèi)容。2024/1/19121（三）根據(jù)消息傳遞確定分析類之間的連接概念上，可以認(rèn)為交互圖中兩個(gè)對(duì)象之間的消息傳遞有賴于它們分屬的兩個(gè)類之間的“消息傳遞通道”，正像兩座城市之間的貨物運(yùn)輸有賴于連接它們的交通線。在UML圖類中，關(guān)聯(lián)、聚合和組合關(guān)系均可提供消息傳遞通道，因此，如果交互圖中存在從類A的對(duì)象到和類B的對(duì)象的消息傳遞，就需要在分析類圖中添加從A指向B的關(guān)聯(lián)、聚合或組合關(guān)系。2024/1/19122根據(jù)消息傳遞確定分析類之間的連接針對(duì)給定的兩個(gè)對(duì)象，如果在它們之間同向傳遞的消息有多條，這些消息可以共享分析類圖中的相同通道，沒(méi)有必要針對(duì)每條消息建立不同的通道。如果在分析類圖中從類A到類B之間存在經(jīng)由其他分析類的路徑，那么也不需要在A到B之間再搭建直接的消息傳遞通道，因?yàn)橄⒁呀?jīng)可以從A的對(duì)象到達(dá)B的對(duì)象。

2024/1/19123例5.8確定分析類之間的連接基于圖5.16中從“傳感器接口”對(duì)象到“監(jiān)測(cè)器”對(duì)象之間的消息傳遞可知這兩個(gè)對(duì)象所屬的類之間存在關(guān)聯(lián)關(guān)系，從其他的消息傳遞關(guān)系可以推知“監(jiān)測(cè)器”類與“配置管理器”、“日志管理器”、“警報(bào)器接口”、“報(bào)警電話接口”及“顯示面板接口”之間存在關(guān)聯(lián)關(guān)系，如此等等，見(jiàn)導(dǎo)出分析類圖的例5.18。對(duì)create消息的處理比較特別，其傳遞不需借助“消息傳遞通道”，因?yàn)樵撓⒌脑磳?duì)象可以利用面向?qū)ο蟪绦蛟O(shè)計(jì)語(yǔ)言中的對(duì)象創(chuàng)建算子（例如C++和Java中的new）直接創(chuàng)建目標(biāo)對(duì)象。雖然在圖5.16中出現(xiàn)了從“監(jiān)測(cè)器”對(duì)象發(fā)向“異常事件”對(duì)象的create消息，但是例5.10中“監(jiān)測(cè)器”和“異常事件”類之間可以沒(méi)有關(guān)聯(lián)關(guān)系。2024/1/19124（四）根據(jù)交互圖確立分析類的屬性實(shí)體類的屬性取決于系統(tǒng)希望在該實(shí)體類的名下持久保存哪些數(shù)據(jù)項(xiàng)數(shù)據(jù)項(xiàng)獲取處：可以從領(lǐng)域概念模型、業(yè)務(wù)術(shù)語(yǔ)詞典、用例描述中部分地獲取。一般的分析類（包括實(shí)體類）完成消息響應(yīng)的能力源于兩方面的知識(shí)一是類本身具有的信息或數(shù)據(jù)二是類能夠找到的其他類，通過(guò)其他類協(xié)助其完成消息響應(yīng)。2024/1/19125根據(jù)交互圖確立分析類的屬性綜合考慮兩個(gè)因素后，需求工程師必須思考：

分析類職責(zé)中的哪些子任務(wù)可通過(guò)消息傳遞路徑委托給其他類完成，哪些子任務(wù)必須由自身完成。為了分派前一種子任務(wù)，分析類可能需要一些信息以尋找最恰當(dāng)?shù)氖芡蓄悾粸榱送瓿珊笠环N子任務(wù)，分析類自身更應(yīng)具備相應(yīng)的知識(shí)、信息或數(shù)據(jù)?；谏鲜隹紤]，再結(jié)合領(lǐng)域和業(yè)務(wù)知識(shí)，需求工程師即可推導(dǎo)出分析類必須具有的屬性。2024/1/19126根據(jù)交互圖確立分析類的屬性如果一個(gè)分析類A為了完成其自身職責(zé)而需要的數(shù)據(jù)不能自然地設(shè)為其屬性，將其歸為另一分析類B的屬性更為妥當(dāng)，那么，應(yīng)該將其確定為B的屬性，并且在交互圖中添加一條從A到B的消息以獲取該數(shù)據(jù)。屬性表示方式：屬性既可以嚴(yán)格地采用UML中類的屬性的表示，也可以僅采用簡(jiǎn)短的自然語(yǔ)言中的名詞或名詞短語(yǔ)。在目前階段，需求工程師沒(méi)有必要過(guò)分擔(dān)心分析類的屬性列表的完全性，只需將分析類為完成職責(zé)所必需的信息列入其屬性表即可，后續(xù)的設(shè)計(jì)過(guò)程將進(jìn)一步精化類的屬性定義，見(jiàn)9.5節(jié)。2024/1/19國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院127例5.9確立分析類的屬性考慮家庭保安系統(tǒng)中的“監(jiān)測(cè)器”類，其主要職責(zé)是“分析傳感數(shù)據(jù)”。根據(jù)圖5.16，它將此職責(zé)分解為：（1）獲取門窗監(jiān)測(cè)靈敏度或煙霧濃度閾值；（2）判別是否出現(xiàn)異常；（3）在異常情況下記錄日志、啟動(dòng)警報(bào)器、撥報(bào)警電話報(bào)告異常事件、顯示異常事件。為完成第（1）、（3）項(xiàng)職責(zé)“監(jiān)測(cè)器”通過(guò)消息傳遞通道求助于其他分析類。假設(shè)“監(jiān)測(cè)器”依靠某種判別算法完成第（2）項(xiàng)職責(zé)，該算法除門窗監(jiān)測(cè)靈敏度和煙霧濃度閾值以外不需要其他數(shù)據(jù)，所以針對(duì)該類目前不需要設(shè)置屬性。2024/1/19128例5.9確立分析類的屬性（續(xù)1）再考慮“報(bào)警電話接口”類，其主要職責(zé)是“報(bào)告異常事件”。根據(jù)例5.7，它要撥報(bào)警電話直至接通或者重?fù)茏銐蚨啻?，為此，它?yīng)該能夠獲取“電話號(hào)碼”、“重?fù)苎舆t”和“最大重?fù)艽螖?shù)”三項(xiàng)數(shù)據(jù)。如果將它們納入“報(bào)警電話接口”類作為屬性，那么，為避免數(shù)據(jù)冗余，必須從分析類圖中刪除“報(bào)警電話”類，讓“報(bào)警電話接口”同時(shí)兼為邊界類和實(shí)體類。另一種更為自然的做法是，保留“報(bào)警電話”實(shí)體類，讓“報(bào)警電話接口”通過(guò)屬性查詢消息從實(shí)體類中獲取上述三項(xiàng)數(shù)據(jù)，見(jiàn)例5.10。2024/1/19129（五）整理分析類圖迄今為止已經(jīng)獲得了覆蓋多個(gè)交互圖的分析類圖，在分析、設(shè)計(jì)工作繼續(xù)推進(jìn)之前，需求工程師有必要全局地研究分析類圖，視實(shí)際情況對(duì)它們進(jìn)行必要的調(diào)整和優(yōu)化。第一項(xiàng)優(yōu)化工作是，通過(guò)消除分析類在職責(zé)和屬性方面的重疊或冗余以簡(jiǎn)化分析模型。2024/1/19130整理分析類圖（1）如果兩個(gè)分析類A和B具有相同或相近的職責(zé)，區(qū)分如下兩種情形：A將此職責(zé)委托給B，A自身并不實(shí)際完成此職責(zé)；A和B均實(shí)際完成此職責(zé)。第一種，分析類圖中的A和B勿需調(diào)整，但必須存在一條從A指向B的通道以便傳遞“委托”消息，必要時(shí)在分析類圖中添加此通道，并在交互圖中添加“委托”消息傳遞；第二種，必須調(diào)整為第一種情形，或在不損害軟件需求的完整實(shí)現(xiàn)的前提下，將此職責(zé)從A、B二者之一中剔除。2024/1/19131整理分析類圖（2）如果分屬于A和B的兩項(xiàng)職責(zé)具有公共的子職責(zé)，那么可考慮設(shè)置單獨(dú)的輔助類C，讓其完成此公共子職責(zé)，然后在分析類圖中增加分別從A、B指向C的通道，并在交互圖中增加相應(yīng)的消息傳遞。

輔助類的UML構(gòu)造型為<<helper>>。2024/1/19132整理分析類圖（3）利用面向?qū)ο笾械睦^承和代理機(jī)制實(shí)現(xiàn)多個(gè)分析類之間對(duì)職責(zé)和屬性的共享。在面向?qū)ο蠹夹g(shù)中有兩種基本的方法可實(shí)現(xiàn)軟件復(fù)用：

繼承法和代理法，分別見(jiàn)圖5.19和圖5.20。在圖5.19中，F(xiàn)ax類直接復(fù)用其父類Telephone中的dial和hangUp功能；在圖5.20中，F(xiàn)ax類通過(guò)消息傳遞通道將這兩項(xiàng)功能委托給Telephone類。2024/1/19133整理分析類圖繼承法和代理法各有優(yōu)勢(shì)：前者的代碼量較小，但子類可以改變被復(fù)用的父類中訪問(wèn)權(quán)限為protected、public的屬性和操作，這樣容易破壞父類中數(shù)據(jù)和處理邏輯的完整性；后者的代碼量稍大，但被復(fù)用的類對(duì)于復(fù)用類而言完全是黑箱，兩個(gè)類之間的耦合度較輕。一般推薦采用代理法實(shí)現(xiàn)復(fù)用，除非被復(fù)用類與復(fù)用類之間存在非常自然的繼承關(guān)系。2024/1/19134整理分析類圖.復(fù)用圖5.19利用繼承機(jī)制實(shí)現(xiàn)復(fù)用圖5.20利用代理機(jī)制實(shí)現(xiàn)復(fù)用2024/1/19135整理分析類圖另一項(xiàng)優(yōu)化工作是，將規(guī)模過(guò)大的分析類圖分拆為若干張規(guī)模適度的類圖。這要用到包圖。在整個(gè)軟件開(kāi)發(fā)過(guò)程中，包圖用于以結(jié)構(gòu)化、層次化的方式組織、管理大型的軟件模型，使得分別處理不同包的開(kāi)發(fā)團(tuán)隊(duì)之間的相互干擾程度降至最低；在業(yè)務(wù)分析和需求定義階段，包圖可用于刻畫業(yè)務(wù)系統(tǒng)和軟件需求的結(jié)構(gòu)；在設(shè)計(jì)和實(shí)現(xiàn)階段，包圖可用于描述軟件系統(tǒng)的高層結(jié)構(gòu)?？梢詫⑷舾煞治鲱悇潥w不同的包，針對(duì)每個(gè)包繪制分析類圖。2024/1/19136例5.10

導(dǎo)出分析類圖綜合前述分析結(jié)果可導(dǎo)出家庭保安系統(tǒng)的分析類圖，如圖5.21所示。2024/1/19137圖5.21家庭保安系統(tǒng)的分析類圖2024/1/191385.5利用快速原型輔助需求分析原型的分類：探索性原型實(shí)驗(yàn)性原型進(jìn)化性原型探索性原型：這類原型是問(wèn)題域中某些子系統(tǒng)或軟件需求的某些子部分的可操作模型，它不涉及軟件的具體實(shí)現(xiàn)方法。原型的主要作用：是澄清應(yīng)用領(lǐng)域和軟件需求的某些疑難問(wèn)題，并方便利益相關(guān)方對(duì)需求分析的工作成果進(jìn)行評(píng)價(jià)、糾錯(cuò)和確認(rèn)。2024/1/19139利用快速原型輔助需求分析實(shí)驗(yàn)性原型：以驗(yàn)證問(wèn)題求解方案的可行性，比較各種方案的優(yōu)劣，并征詢利益相關(guān)方對(duì)這些方案的功能和性能的意見(jiàn)。與探索性原型類似，可以針對(duì)各個(gè)用戶目標(biāo)分別生成原型進(jìn)行試驗(yàn)。2024/1/19140利用快速原型輔助需求分析進(jìn)化性原型：不僅用來(lái)理解問(wèn)題、試驗(yàn)求解方案，而且用作目標(biāo)軟件系統(tǒng)的基礎(chǔ)，并在后續(xù)開(kāi)發(fā)過(guò)程中逐步進(jìn)化為最終的軟件產(chǎn)品的原型。與探索性和實(shí)驗(yàn)性原型相比，進(jìn)化性原型的設(shè)計(jì)需要更周密、更長(zhǎng)遠(yuǎn)的技術(shù)考慮，其軟件結(jié)構(gòu)應(yīng)該具有更好的可擴(kuò)充性，從而為后續(xù)的進(jìn)化奠定基礎(chǔ)。2024/1/19141利用快速原型輔助需求分析構(gòu)建原型過(guò)程：首先必須進(jìn)行分析與規(guī)劃，以確定將哪些需求項(xiàng)納入原型的實(shí)現(xiàn)范疇，并對(duì)范疇之內(nèi)的需求進(jìn)行分析。（分析與規(guī)劃）接下來(lái)應(yīng)基于需求分析的結(jié)果展開(kāi)原型的設(shè)計(jì)和實(shí)現(xiàn)。（設(shè)計(jì)與實(shí)現(xiàn)）最后，針對(duì)可運(yùn)行的原型進(jìn)行應(yīng)用、檢查與評(píng)審；（檢查與評(píng)審）根據(jù)檢查及評(píng)審過(guò)程中發(fā)現(xiàn)的問(wèn)題進(jìn)行改進(jìn)。（改進(jìn)）這種改進(jìn)可能是輕微的，如直接修改原型的實(shí)現(xiàn)代碼；也可能是重量級(jí)的，需要再次進(jìn)入“分析與規(guī)劃-設(shè)計(jì)與實(shí)現(xiàn)-檢查與評(píng)審-改進(jìn)”迭代。2024/1/191425.6評(píng)審分析模型參與人員：需求工程師、軟件設(shè)計(jì)師、項(xiàng)目軟件經(jīng)理、利益相關(guān)方的代表和業(yè)務(wù)專家任務(wù)：正式地審查迄今為止需求分析階段的所有工作成果，包括需求優(yōu)先級(jí)、基于UML的分析模型（含分析類圖、交互圖、狀態(tài)圖、活動(dòng)圖），需求分析階段生成的快速原型等分析模型是被評(píng)審的主體對(duì)象。2024/1/19143評(píng)審方法與需求獲取階段的評(píng)審方法雖然類似，但也有一些差異。⑴分析模型評(píng)審的主要關(guān)注點(diǎn)除模型的一致性、精確性和完全性外，還應(yīng)包括分析模型相對(duì)于用例模型的一致性，以及分析模型面向軟件設(shè)計(jì)師的可理解性、詳略恰當(dāng)性。⑵相對(duì)于用例模型，基于分析模型更易構(gòu)造可實(shí)際運(yùn)行的快速原型。所以，分析模型評(píng)審更適于采用快速原型法。⑶在分析模型評(píng)審過(guò)程中應(yīng)充分利用分析過(guò)程中記錄的分析決策，判斷這些決策的合理性，基于這些決策理解、評(píng)審分析模型。⑷利益相關(guān)方和業(yè)務(wù)專家在分析模型評(píng)審中的作用相對(duì)弱化，因?yàn)樗麄兛赡茈y于理解分析模型中的技術(shù)性內(nèi)容。2024/1/19144評(píng)審分析模型5.7需求規(guī)約需求規(guī)約：需求工程師經(jīng)需求獲取的分析后形成的軟件文檔。需求規(guī)約主體內(nèi)容：軟件需求的用例模型和分析模