第5章-系統(tǒng)模型課件

1第五章系統(tǒng)建模（Systemmodels）學(xué)習(xí)引導(dǎo)

本章介紹一系列不同的系統(tǒng)模型，這些模型是在需求工程和系統(tǒng)設(shè)計過程中必須建立有用工具。主要內(nèi)容：理解如何用圖形模型來表示軟件系統(tǒng)；理解不同類型的模型以及基本的系統(tǒng)建模角度，如上下文、交互、結(jié)構(gòu)和行為等；統(tǒng)一建模語言（UML）中定義的符號及其建模應(yīng)用；2

模型是系統(tǒng)的抽象視圖，它忽略了系統(tǒng)中的所有細節(jié)。輔助模型的開發(fā)能夠反映系統(tǒng)中不同的信息。3什么是模型？描畫系統(tǒng)模型系統(tǒng)模型描畫在紙上，是平面的；但思維則是多維的，需要從幾個不同的視角出發(fā)：1.從外部來看，對系統(tǒng)環(huán)境建模，即描述系統(tǒng)的“上下文”。2.從交互上看，它是對系統(tǒng)與環(huán)境之間或是一個系統(tǒng)各組成部分之間的交互建模。3.從結(jié)構(gòu)上看，對系統(tǒng)的體系結(jié)構(gòu)和系統(tǒng)處理的數(shù)據(jù)的結(jié)構(gòu)建模。4.從行為上看，對系統(tǒng)的行為建模，即描述系統(tǒng)的動態(tài)行為和它對事件的響應(yīng)方式的建模。4常見的軟件系統(tǒng)模型上下文模型交互模型1用例建模，2時序圖結(jié)構(gòu)模型1類圖，2泛化，3聚合

行為模型1數(shù)據(jù)驅(qū)動的建模，2事件驅(qū)動模型UML（UnifiedModelingLanguage）統(tǒng)一建模語言已經(jīng)成為描述面向?qū)ο筌浖到y(tǒng)的標(biāo)準(zhǔn)建模語言常見的軟件系統(tǒng)模型活動圖：表示一個過程或數(shù)據(jù)處理中所涉及的活動用例圖：表示系統(tǒng)和它所處環(huán)境之間的交互時序圖：表示參與者和系統(tǒng)之間以及系統(tǒng)各部分之間的交互類圖：表示系統(tǒng)中對象類以及這些類之間的聯(lián)系狀態(tài)圖：表示系統(tǒng)是如何響應(yīng)內(nèi)部和外部事件的靜態(tài)建模動態(tài)建模

上下文模型示出了要建模的系統(tǒng)在整個環(huán)境中與其他系統(tǒng)和過程間的位置關(guān)系。上下文模型定義了系統(tǒng)的邊界。體系結(jié)構(gòu)模型、過程模型可以作為上下文模型。75.1上下文模型上下文模型示例1：ATM系統(tǒng)8ATM系統(tǒng)上下文系統(tǒng)邊界上下文模型是什么意思？注意：上下文模型的意圖在于說清“系統(tǒng)的環(huán)境是什么”，說不清的（不確定的）就通過討論來逐漸明確。所謂“系統(tǒng)的環(huán)境是什么”——即從系統(tǒng)外部對系統(tǒng)的輸入開始，直到系統(tǒng)處理之后對系統(tǒng)外部的響應(yīng)，此過程的結(jié)構(gòu)化描述。9上下文模型的建模方法具體的建模（描述）方法對系統(tǒng)命名，表示出確定的系統(tǒng)邊界；標(biāo)識系統(tǒng)外部的所有參與要素；——注意，是系統(tǒng)外部的??！說明外部要素與系統(tǒng)之間的關(guān)系；10上下文模型示例：

MHC-PMS系統(tǒng)的上下文模型

所有的系統(tǒng)都會涉及到交互，有可能是用戶交互，與用戶的輸入有關(guān)，有可能是正在開發(fā)的系統(tǒng)與其它系統(tǒng)之間的交互，或者是組成系統(tǒng)的各個組成部分之間交互。交互圖的描述是為了更好的識別用戶的需求。135.2交互建模5.2.1用例模型用例圖用于定義系統(tǒng)的功能需求，它描述了系統(tǒng)的參與者與系統(tǒng)提供的用例之間的關(guān)系。參與著可以是人，可以是另外一個系統(tǒng)。用例圖僅僅從使用者的角度描述系統(tǒng)中的信息1參與者參與者（Actor）是系統(tǒng)外部的一個實體（可以是任何的事物或人），它以某種方式參與了用例的執(zhí)行過程。參與者通過向系統(tǒng)輸入或請求系統(tǒng)輸入某些事件來觸發(fā)系統(tǒng)的執(zhí)行。參與者由他們參與用例時所擔(dān)當(dāng)?shù)慕巧珌泶怼ＷR別參與者參與者（Actor）是系統(tǒng)外部的一個實體，他們不是系統(tǒng)的組成部分?；卮鹑缦聠栴}，可以幫助建模人員發(fā)現(xiàn)參與者。系統(tǒng)的主要客戶是誰？誰借助于系統(tǒng)完成日常工作？誰來維護和管理系統(tǒng)，保證系統(tǒng)的正常運行？系統(tǒng)控制的硬件設(shè)置有那些？系統(tǒng)需要和其它系統(tǒng)進行交互嗎？在預(yù)定的時刻，是否有預(yù)定的事件發(fā)生？系統(tǒng)從什么地方獲取信息？練習(xí)識別“超市進銷存管理系統(tǒng)”中的參與者2用例用例是一組連續(xù)的操作，當(dāng)用戶使用系統(tǒng)來完成某個過程時出現(xiàn)，它是外部可見的系統(tǒng)功能單元。通過將這些不同功能單元的組合，就構(gòu)成了對系統(tǒng)總體需求的描述。用例要點:

1.位于系統(tǒng)

--必須由系統(tǒng)運行

2.目標(biāo)導(dǎo)向

--用例運行必須有所目的

3.止于邊界

--可以觀測到結(jié)果,并且是在邊界和外部有所交互的

4.用戶觀點

--參與者觀測

5.粒度

--是一組有共同目標(biāo)或者可以類聚的目標(biāo)的實例組成識別用例識別用例最好的辦法就是從分析系統(tǒng)的參與者開始，考慮每個參與者是怎樣使用系統(tǒng)。使用這種策略的過程中可能會找出一個新的參與者，這對完善整個系統(tǒng)建模很有幫助。識別用例時有用的幾個問題在識別用例的過程中，通過以下的幾個問題可以幫助識別用例：（1）特定參與者希望系統(tǒng)提供什么功能？（2）系統(tǒng)是否存儲和檢索信息？如果是，這個行為由哪個參與者觸發(fā)?（3）當(dāng)系統(tǒng)改變狀態(tài)時，通知參與者嗎？（4）存在影響系統(tǒng)的外部事件嗎？（5）是哪個參與者通知系統(tǒng)這些事件？（系統(tǒng)需要什么樣的輸入輸出）用例識別練習(xí)ATM自動柜員機系統(tǒng)是由計算機控制的銀行自動出納系統(tǒng)，主要服務(wù)于活期儲蓄，實現(xiàn)客戶自助服務(wù)的電子化設(shè)備。通過UML對ATM自動取款機建模，實現(xiàn)查詢余額、取款、存款、轉(zhuǎn)賬、更改密碼等業(yè)務(wù)，根據(jù)需求還可以進一步擴展具體功能。用例與參與者之間的連線稱為關(guān)系，關(guān)系也稱為關(guān)聯(lián)或通信關(guān)聯(lián)，它表示參與者與用例之間的通信。一般情況下，不用帶箭頭的直線表示信息流動的方向，因為信息流動是雙向的。如果使用箭頭，則特意的表示信息的發(fā)起者或接受者；關(guān)系3用例描述3用例描述在描述用例時，可以用文字來描述，也可以用其他圖形來描述，例如，順序圖等等。名稱：名稱無疑應(yīng)該表明用戶的意圖或用例的用途，如“研究班招生”。標(biāo)識符[可選]：唯一標(biāo)識符，如"UC1701"，在項目的其他元素（如類模型）中可用它來引用這個用例。說明：概述用例的幾句話。參與者[可選]：與此用例相關(guān)的參與者列表。盡管這則信息包含在用例本身中，但在沒有用例圖時，它有助于增加對該用例的理解。

頻率：參與者訪問此用例的頻率。這是一個自由式問題，如用戶每次登錄訪問一次或每月一次。描述用例前置條件：一個條件列表，如果其中包含條件，則這些條件必須在訪問用例之前得到滿足。（類似于調(diào)用函數(shù)或過程時，檢測參數(shù)是否匹配）后置條件：一個條件列表，如果其中包含條件，則這些條件將在用例成功完成以后得到滿足。它提供了系統(tǒng)的部分描述。

被擴展的用例[可選]：此用例所擴展的用例（如果存在）。擴展關(guān)聯(lián)是一種廣義關(guān)系，其中擴展用例繼續(xù)基用例的行為。這是通過擴展用例向基用例的操作序列中插入附加的操作序列來實現(xiàn)的。這總是使用帶有<>的用例關(guān)聯(lián)來建模的。被包含的用例[可選]：此用例所包含用例的列表。包含關(guān)聯(lián)是一種廣義關(guān)系，它表明對處于另一個用例之中的用例所描述的行為的包含關(guān)系。這總是使用帶有<>的用例關(guān)聯(lián)來建模的。也稱為使用或具有(has-a)關(guān)系。描述用例假設(shè)[可選]：對編寫此用例時所創(chuàng)建的域的任何重要假設(shè)。您應(yīng)該在一定的時候檢驗這些假設(shè)，或者將它們變?yōu)闆Q策的一部分，或者將它們添加到操作的基本流程或可選流程中?；静僮髁鞒蹋簠⑴c者在用例中所遵循的主邏輯路徑。因為它描述了當(dāng)各項工作都正常進行時用例的工作方式，所以通常稱其為適當(dāng)路徑(happypath)或主路徑(mainpath)。

可選操作流程：用例中很少使用的邏輯路徑，那些在變更工作方式、出現(xiàn)異?；虬l(fā)生錯誤的情況下所遵循的路徑。

修改歷史記錄[可選]：關(guān)于用例的修改時間、修改原因和修改人的詳細信息。

問題[可選]：如果存在，則為與此用例的開發(fā)相關(guān)的問題或操作項目的列表。

決策：關(guān)鍵決策的列表，這些決策通常由管理者作出，并屬于用例的內(nèi)容。將這些決策記錄下來對于維護團體記憶庫(groupmemory)是相當(dāng)重要的。舉例：對借書這個用例來做描述用例名稱：借書

說明：學(xué)生在圖書館挑選好需要的圖書后，通過圖書管理員把書借回去。

參與者：學(xué)生，圖書管理員

頻率：每天可能會有很多次。最繁忙的情況是，借書的人非常多，按照現(xiàn)在的速度，大約每分鐘完成一個人的結(jié)束工作。

前置條件：無

后置條件：修改所借出的圖書的剩余數(shù)量。

假設(shè)：借書者總是從圖書館找到書，然后才能拿書辦理借書手續(xù)，因此，總是有足夠的書可以出借。

基本操作流程：借書成功。

1）學(xué)生將所借圖書和借書證交給圖書管理員

2）圖書管理員將學(xué)生借書證號碼和所借圖書輸入系統(tǒng)

3）系統(tǒng)校對借書信息，比對該學(xué)生以往借書情況和當(dāng)前借書情況，如果不存在不允許借書的情況，則記錄借書交易的信息，并且修改相應(yīng)的館藏圖書的數(shù)量信息。4）如果該學(xué)生已經(jīng)預(yù)訂了這本圖書，則撤銷該預(yù)定。

5）報告交易成功。

可選操作流程：所借圖書超出最大借書數(shù)量。

1）學(xué)生將所借圖書和借書證交給圖書管理員

2）圖書管理員將學(xué)生借書證號碼和所借圖書輸入系統(tǒng)

3）系統(tǒng)校對借書信息，比對該學(xué)生以往借書情況和當(dāng)前借書情況，發(fā)現(xiàn)已超出最大借書數(shù)量，則停止當(dāng)前交易，并且提示用戶錯誤原因。

4）圖書管理員可以應(yīng)學(xué)生的意見，減少借書數(shù)量，并重新提交系統(tǒng)。

流程活動圖：見圖一。

問題：暫無。

決策：略。

修改歷史記錄：張三,定義可選操作流程，2008.3.6練習(xí)：按如下格式完成“還書”用例描述用例名稱還書說明參與者頻率前置條件后置條件假設(shè)基本操作流程可選操作流程修改歷史記錄說明用例描述讓用例變得更加完整，沒有用例描述的用例是沒有什么意義的。4用例建模用例建模的步驟：

序列模（SequenceDiagram）型給出在系統(tǒng)中參與者和對象之間的交互，用于對動態(tài)行為建模。335.2.2序列圖對象模型的建立方法1.建立用例模型，描述用例2.識別對象，建立對象間的交互模型，校正對象識別3.建立對象模型其中，對象交互模型，也叫做順序模型。本教材叫做“時序圖”。在UML中，該模型突出刻畫對象的行為及對象間的交互場景。34順序圖的組成說明順序圖主要有4個標(biāo)記符：對象、生命線、消息和激活。在UML中，順序圖用一個二維圖描述系統(tǒng)中各個對象之間的交互關(guān)系。其中，縱軸是時間軸，時間沿豎線向下延伸。橫軸代表了參與相互作用的對象。當(dāng)對象存在時，生命線由一條虛線表示。當(dāng)對象的過程處于激活狀態(tài)時，生命線是一雙道線。消息用從一個對象到另一個對象生命線的箭頭，表示箭頭對象與生命線順序圖中的每個對象顯示在單獨的列里，一個對象標(biāo)識符（帶有對象名稱的矩形框）放置在代表生成這個對象的消息的箭頭的末端，其垂直位置表示這個對象第一次生成的時間。如果一個對象在順序圖的第一個操作之前就存在，對象標(biāo)記符就應(yīng)畫在任何消息之前順序圖的頂部。順序圖案例1：查看病人信息系統(tǒng)的順序圖

行為模型模型描述系統(tǒng)運行時的動態(tài)行為的模型，表示當(dāng)系統(tǒng)響應(yīng)來自所處環(huán)境的刺激時所發(fā)生的或有可能發(fā)生的事情。39要點5-3這樣的刺激有兩種：1.數(shù)據(jù)：一些數(shù)據(jù)到達時必須由系統(tǒng)處理2.事件：某些觸發(fā)系統(tǒng)處理的事件發(fā)生數(shù)據(jù)流圖數(shù)據(jù)流圖可以用來描述系統(tǒng)中數(shù)據(jù)的加工過程。系統(tǒng)被定義為一系列數(shù)據(jù)及在這些數(shù)據(jù)上的操作。數(shù)據(jù)流圖示例模型中的符號分別表示：——圓角矩形：表示數(shù)據(jù)處理的功能模塊——直角矩形：表示功能模塊的處理結(jié)果——帶標(biāo)記的箭頭：表示處理過程中數(shù)據(jù)的流動42訂單處理的數(shù)據(jù)流圖數(shù)據(jù)流圖的作用1.數(shù)據(jù)流模型從功能角度的分析而得到的系統(tǒng)模型，為系統(tǒng)的軟件需求提供了一個基本框架2.數(shù)據(jù)流模型中的數(shù)據(jù)處理部分，既是軟件功能的劃分，也是對系統(tǒng)結(jié)構(gòu)的一個假定——用函數(shù)（過程）來執(zhí)行數(shù)據(jù)的變換。3.數(shù)據(jù)流模型描述了系統(tǒng)中“端到端”的數(shù)據(jù)處理過程。43UML不支持?jǐn)?shù)據(jù)流圖，因為DFD關(guān)注的是系統(tǒng)功能而不是識別系統(tǒng)對象在UML2.0引入與DFD類似的活動圖。處理步驟用活動表示，步驟之間的流動的數(shù)據(jù)用對象表示用時序圖表示對訂單的處理并發(fā)送給供應(yīng)商。時序圖強調(diào)系統(tǒng)中的對象

狀態(tài)機模型用來描述系統(tǒng)的行為，以響應(yīng)內(nèi)部和外部的事件。47要點5-4什么是狀態(tài)機模型？一個軟件的行為，是另一個軟件的監(jiān)測與控制下付諸實現(xiàn)的。為了描述系統(tǒng)內(nèi)部或外部事件的發(fā)生/響應(yīng)的行為，需要使用狀態(tài)機模型。描述系統(tǒng)狀態(tài)和事件描述事件引發(fā)的系統(tǒng)狀態(tài)及狀態(tài)間的轉(zhuǎn)換但不描述系統(tǒng)中數(shù)據(jù)的流動。對于實時系統(tǒng)，更需要建立狀態(tài)機模型。48狀態(tài)機模型示例狀態(tài)機模型符號（基于UML）圓角矩形——代表系統(tǒng)的狀態(tài)，圓角矩形內(nèi)寫入狀態(tài)的描述帶標(biāo)識的箭頭——表示狀態(tài)轉(zhuǎn)換的激勵/事件/消息。事件