第5章 基于UML的信息系統(tǒng)建模技術(shù)

1、信息系統(tǒng)工程與實踐1u5.1 信息系統(tǒng)建模技術(shù)和方法概論 u5.2 建模語言UML的背景和發(fā)展歷程 u5.3 UML可以建立的各種模型 u5.4 UML語言的組成部分 u5.5 UML圖與建模技術(shù) u5.6 需求建模 u5.7 靜態(tài)結(jié)構(gòu)建模 u5.8 動態(tài)行為建模 u5.9 物理建模 5.15.1信息系統(tǒng)建模技術(shù)和方法概論信息系統(tǒng)建模技術(shù)和方法概論 信息系統(tǒng)建模主要包括分析建模和設(shè)計建模兩部分。分析建模的主要目的是系統(tǒng)的提出問題領(lǐng)域的模型，即回答做什么的問題。設(shè)計建模的主要任務(wù)是確定設(shè)計的策略和方法以滿足系統(tǒng)的功能要求，即回答怎么做的問題。 信息系統(tǒng)的模型一般包括三種視圖：數(shù)據(jù)建模、功能建模、

2、行為建模。 5.25.2建模語言建模語言UMLUML的背景和發(fā)展歷程的背景和發(fā)展歷程 統(tǒng)一建模語言語言UML是在多種面向?qū)ο蠼７椒ǖ幕A(chǔ)之上形成的，吸收了多種建模方法的優(yōu)點，克服了這些建模方法的缺點。1997年對象管理組（Obeject Management Group,以下簡稱為OMG）正式把UML作為建模語言的規(guī)范。UML的出現(xiàn)引起了軟件開發(fā)者的高度重視，可以用來對各種系統(tǒng)進行建模，包括信息系統(tǒng)建模和分布式應(yīng)用建模甚至用于工業(yè)系統(tǒng)的建模。面向?qū)ο蠼ＵZ言出現(xiàn)在20世紀(jì)70年代，在之后的10年中發(fā)展最為迅速，其中最有代表性的建模語言包括Booch提出的Booch 93、I.Jacobson

3、的面向?qū)ο筌浖こ?OOSE)、Raubaugh的對象建模技術(shù)（OMT），這些面向?qū)ο蟮慕ＵZ言都有各自的優(yōu)缺點，比如Booch 93對項目的設(shè)計和構(gòu)造很有效，OOSE特別適合需求獲取和分析，OMT適合數(shù)據(jù)量密集的信息系統(tǒng)。UML還存在許多問題，主要表現(xiàn)在：（1）UML是一種建模語言而不是一種方法，它不提供如何運用面向?qū)ο蟮母拍詈驮瓌t進行系統(tǒng)建模，而是定義了用于建模的元素，以及用這些元素如何構(gòu)建UML圖的規(guī)則。它不能為信息系統(tǒng)開發(fā)人員提供一套切實可行的原則。（2）很多學(xué)者認(rèn)為UML過于龐大、難以學(xué)習(xí)并且難以靈活應(yīng)用，部分語義不夠明確且?guī)в衅缌x性。實際上,沒有人了解UML的全部內(nèi)容，大多數(shù)人都只

4、是使用UML的一個小子集而已。（3）很多概念復(fù)雜并使用戶感到迷惑，并且很少使用，人們對這些概念的存在意義表示困惑。5.3 UML5.3 UML可以建立的各種模型可以建立的各種模型 UML是一種建模語言而不是方法，因為UML中根本沒有過程的概念。UML本身與過程獨立，因此選用UML與是否采用迭代開發(fā)過程、敏捷過程或RUP過程無關(guān)。實際上UML可以被應(yīng)用到各種具體的過程中。利用UML圖可以創(chuàng)建不同類型的模型，對模型有以下兩種常見的劃分方法。（1）按信息系統(tǒng)生命周期的各個階段產(chǎn)生的階段性模型（2）按模型的用途進行劃分5.4 UML5.4 UML語言的組成部分語言的組成部分 UML建模語言作為一種設(shè)計

5、語言，主要由模型元素、圖、視圖和公共機制幾部分構(gòu)成。5.4.15.4.1模型元素模型元素 模型元素包括元素本身及元素與元素之間的聯(lián)系。元素可以表示任何需要處理的業(yè)務(wù)領(lǐng)域?qū)ο蠡蚋拍?，元素與元素之間的聯(lián)系能夠把元素之間的關(guān)系表達出來，使得元素之間能夠協(xié)同工作，構(gòu)成與現(xiàn)實類似的元素結(jié)構(gòu)模型。一般而言，每個模型元素都有一個特定的UML圖與之對應(yīng)，圖形化的好處就是可以幫助人們形象的認(rèn)識問題和理解問題，有時也可以說UML是圖形化的建模語言。1. 1. 元素元素（1）結(jié)構(gòu)元素 結(jié)構(gòu)元素包括類、對象、接口、用例、協(xié)作、主動類、構(gòu)件和節(jié)點。（2）行為元素 行為元素是UML模型中的動態(tài)部分，用來描述業(yè)務(wù)系統(tǒng)或軟件

6、系統(tǒng)中元素之間的交互或元素的狀態(tài)變化，它們是模型的動詞，代表時間和空間上的動作。 2. 2. 元素之間的聯(lián)系元素之間的聯(lián)系 在軟件世界中，情況亦是如此，類與類之間往往是彼此聯(lián)系和交互的。在UML中，元素與元素之間最常見的聯(lián)系有關(guān)聯(lián)關(guān)系、實現(xiàn)關(guān)系、泛化關(guān)系、依賴關(guān)系。5.4.25.4.2圖圖 在UML中，通過關(guān)系把多個元素聯(lián)系在一起，就構(gòu)成了圖。圖是UML中最吸引人的地方，原因是通過圖示化手段，軟件系統(tǒng)變得更加容易理解，這些圖給人留下了深刻印象，以至于一談到UML建模技術(shù)，馬上就會讓人在腦海里聯(lián)想到這些圖。 UML1.0UML2.0功能變化說明類圖類圖(class)類、類的特征以及類之間的關(guān)系U

7、ML1.0原有對象圖對象圖(object)系統(tǒng)中各個對象的快照UML1.0非正式圖無復(fù)合結(jié)構(gòu)圖(composite structure)類的運行時刻的分解UML2.0新增構(gòu)件圖構(gòu)件圖(component)構(gòu)件的結(jié)構(gòu)和聯(lián)系UML1.0原有部署圖部署圖(deployment)系統(tǒng)拓?fù)涞奈锢砻枋鯱ML1.0原有組成對象圖包圖(package)編譯時刻層次結(jié)構(gòu)UML1.0非正式圖用例圖用例圖(use case)用戶與系統(tǒng)如何交互UML1.0原有活動圖活動圖(activity)過程行為與并行行為UML1.0原有狀態(tài)圖狀態(tài)機圖(state machine)事件如何改變生命周期中對象UML1.0原有順序圖順

8、序圖(sequence)對象之間的交互，強調(diào)順序UML1.0原有協(xié)作圖通信圖(communication)對象之間的交互，強調(diào)連接UML1.0中的協(xié)作圖無定時圖(timing)對象之間的交互，強盜定時UML2.0新增無交互概覽圖(interactive overview)順序圖與活動圖的混合UML2.0新增5.4.35.4.3視圖視圖 UML2.0中提供了用例視圖、邏輯視圖、并發(fā)視圖、構(gòu)件視圖和部署視圖，它們能夠從系統(tǒng)的各個方面反映系統(tǒng)，圖5-21給出了這種UML視圖模型。用例視圖邏輯視圖構(gòu)件視圖并發(fā)視圖部署視圖圖5-21 系統(tǒng)模型的5種視圖及其關(guān)系5.4.45.4.4公共機制公共機制 公共機

9、制包括注釋、修飾、規(guī)格說明、通用劃分和擴展機制。5.5.1 5.5.1 軟件建模概述軟件建模概述 模型是在構(gòu)建事物之前為了理解事物而對事物作出的一種抽象。這種抽象忽略了原始事物的非本質(zhì)的東西，使得模型比事物本身更容易理解?，F(xiàn)代復(fù)雜的軟件系統(tǒng)建設(shè)時必須做好詳細的規(guī)劃和設(shè)計，這就是軟件建模工作。軟件系統(tǒng)建模的的目的是：幫助我們按照實際情況或按我們需要的樣式對系統(tǒng)進行可視化；提供一種詳細說明系統(tǒng)結(jié)構(gòu)或行為的方法；給出一個指導(dǎo)系統(tǒng)構(gòu)造的模板；對我們所做出的決策進行文檔化。5.5 UML5.5 UML圖與建模技術(shù)圖與建模技術(shù)5.5.2 UML5.5.2 UML建?；玖鞒探；玖鞒?.5.3Ratio

10、nal Rose5.5.3Rational Rose可以完成的建模工作可以完成的建模工作 Rational Rose軟件進行UML建模時可以完成的建模工作：（1）描述用戶需求，即需求建模；（2）根據(jù)用戶需求建立系統(tǒng)的靜態(tài)結(jié)構(gòu)模型，即靜態(tài)結(jié)構(gòu)建模；（3）描述系統(tǒng)的動態(tài)行為模型，即動態(tài)行為建模；（4）描述系統(tǒng)的構(gòu)架模型，即架構(gòu)建模。5.6 5.6 需求建模需求建模 在需求分析階段，通常使用用例來描述角色是如何使用系統(tǒng)的，尋找用例模型是需求分析階段的主要任務(wù)，用例建模通常也被稱作需求建模。需求建模需要與客戶進行反復(fù)交流共同協(xié)商完成。用例模型也就是系統(tǒng)的用例視圖，用例模型一般由一個用例圖或一組用例圖構(gòu)

11、成，此外還必須由額外的用例描述文檔。5.6.15.6.1需求獲取與需求分析需求獲取與需求分析 需求分析在整個信息系統(tǒng)的開發(fā)中占有舉足輕重的地位，可以說需求分析工作的質(zhì)量直接決定信息系統(tǒng)的質(zhì)量。隨著信息系統(tǒng)開發(fā)經(jīng)驗的增加，人們越來越重視信息系統(tǒng)的需求分析工作，因此產(chǎn)生了“需求工程”，需求工程研究領(lǐng)域主要包括兩部分的研究內(nèi)容：需求開發(fā)和需求管理。其中需求開發(fā)又可以進一步的分為需求獲取、需求分析、編寫需求規(guī)格文檔和需求驗證四個階段。5.6.2 5.6.2 用例模型用例模型 用例模型的基本組成構(gòu)件是用例、參與者和系統(tǒng)。用例用于描述系統(tǒng)的功能性需求，非功能性需求也可以對應(yīng)單個用例，從而可以在用例的上下文

12、中進行處理。一個完整的系統(tǒng)可能包含很多用例，每個用例具體代表一項功能，所有用例代表系統(tǒng)的所有功能的集合。參與者是與系統(tǒng)進行交互的外部對象，可以是用戶也可以是其它系統(tǒng)或硬件設(shè)備。用例的執(zhí)行一般是由外部參與者觸發(fā)執(zhí)行的。用例模型中的系統(tǒng)可以看成是具有一定功能的黑盒子。5.6.3 5.6.3 用例圖用例圖 用例圖(use case diagram)是外部用戶所能觀察到的系統(tǒng)功能的模型圖，它描述人們希望如何使用一個系統(tǒng)。用例圖的主要元素是用例和參與者，用來描述系統(tǒng)功能，并指出各個功能的操作者。用例圖在各種開發(fā)活動中被廣泛地使用，但是它最常用來描述系統(tǒng)以及子系統(tǒng)。 查詢書目查詢借閱情況預(yù)定圖書讀者取消預(yù)

13、定圖5-28 圖書館管理系統(tǒng)用例圖1. 用例（use case）2. 參與者(actor)（1）主要參與者 （2）次要參與者 （3）外部硬件 （4）其它系統(tǒng) . 用例的描述用例規(guī)約包含用例編號、用例名稱、參與者、目標(biāo)、前置條件、事件流、后置條件。用例規(guī)約的模板如表5-3所示。3. 用例之間的關(guān)系（1）泛化關(guān)系（2）包含和擴展關(guān)系（3）使用關(guān)系4. 用例圖繪制的主要步驟（1）識別系統(tǒng)邊界和參與者。（2）列出與參與者相關(guān)的事件。（3）從事件中識別出系統(tǒng)的功能性要求，即用例。（4）識別用例之間的關(guān)系。（5）畫出用例圖。（6）撰寫必要的用例細節(jié)描述文檔。用例編號用例名稱用例目標(biāo)參與者前置條件后置條件事

14、件流基本事件流備選事件流擴展點變異點補充說明5.75.7靜態(tài)結(jié)構(gòu)建模靜態(tài)結(jié)構(gòu)建模5.7.1 靜態(tài)結(jié)構(gòu)建模概述 靜態(tài)結(jié)構(gòu)建模就是要尋找并發(fā)現(xiàn)信息系統(tǒng)的靜態(tài)模型，建立靜態(tài)模型的實質(zhì)是對問題域進行抽象的過程，把問題域有關(guān)的類和對象以及它們的相互關(guān)系進行分類，以揭示系統(tǒng)的結(jié)構(gòu)。UML的靜態(tài)結(jié)構(gòu)建模工作需要借助于類圖和對象圖來完成。 靜態(tài)結(jié)構(gòu)建模就是要尋找并發(fā)現(xiàn)信息系統(tǒng)的靜態(tài)模型，建立靜態(tài)模型的實質(zhì)是對問題域進行抽象的過程，把問題域有關(guān)的類和對象以及它們的相互關(guān)系進行分類，以揭示系統(tǒng)的結(jié)構(gòu)。UML的靜態(tài)結(jié)構(gòu)建模工作需要借助于類圖和對象圖來完成。 5.7.1 靜態(tài)結(jié)構(gòu)建模概述5.7.2 5.7.2 類圖概

15、述類圖概述 類圖(Class Diagram)是描述軟件系統(tǒng)中類及類之間關(guān)系的一種圖示，是從靜態(tài)角度表示系統(tǒng)的。因此類圖是一種靜態(tài)模型。類圖是構(gòu)件其它圖的基礎(chǔ)，如果類圖沒有構(gòu)建好，就不能產(chǎn)生順序圖、狀態(tài)圖和通信圖等。所以構(gòu)建類圖是系統(tǒng)靜態(tài)結(jié)構(gòu)建模的第一步。 類的概念及UML的表示方法在前面已經(jīng)討論過了，現(xiàn)在讓我們來看一下在面向?qū)ο蟮慕ｎI(lǐng)域里對類又是如何分類的。在面向?qū)ο蟮慕ｎI(lǐng)域里，通常將類分成三種類型，即實體類、邊界類和控制類。5.7.3 5.7.3 繪制類圖的基本步驟繪制類圖的基本步驟 （1）通過需求規(guī)格說明書了解到系統(tǒng)中參與者、組織、設(shè)備、事件等，找出可能的候選對象，從而為發(fā)現(xiàn)實體類做

16、準(zhǔn)備。（2）根據(jù)需求分析階段得到用例模型查找用例的事件流中的名詞。（3）根據(jù)用戶與系統(tǒng)的交互預(yù)期，確定邊界類。（4）有些類不是上述方法就能夠找到的，需做進一步的分析。（5）在后面動態(tài)行為建模中使用的順序圖和通信圖可以幫助發(fā)現(xiàn)類。 5.7.4 5.7.4 對象圖對象圖 類圖表示類與類之間的關(guān)系，而對象圖則是在某一個時刻系統(tǒng)中對象的快照。對象圖可以看成是類圖的實例，正如對象是類的實例一樣。對象圖的表示方法與類圖表示方法很類似，差別在與對象圖中對象的名字要下要加下劃線。 5.85.8動態(tài)行為建模動態(tài)行為建模 信息系統(tǒng)的動態(tài)行為是指系統(tǒng)中的對象是如何進行通信以及通信的結(jié)果如何。一組對象為了實現(xiàn)一定的功

17、能而進行的通信稱之為交互。交互圖專門用來表示各組對象如何通信的模型。 5.8.15.8.1狀態(tài)機圖概述狀態(tài)機圖概述 狀態(tài)機圖(State Machine Diagram)表示狀態(tài)機，表示系統(tǒng)從一個狀態(tài)到另一個狀態(tài)的控制流。 閑置撥號接通拿起電話聽筒撥號電話線路接通通話結(jié)束5.8.25.8.2狀態(tài)機圖組成狀態(tài)機圖組成 狀態(tài)機圖由表示狀態(tài)的節(jié)點和表示狀態(tài)之間轉(zhuǎn)換的帶箭頭的直線組成。在狀態(tài)機圖中若干個狀態(tài)節(jié)點由一條或多條轉(zhuǎn)換箭頭連接，狀態(tài)的轉(zhuǎn)換由事件觸發(fā)。 初始化do/ 重新啟動工作中正在關(guān)機打開電源關(guān)機5.8.35.8.3活動圖概述活動圖概述 活動圖和狀態(tài)圖都是狀態(tài)機的表現(xiàn)形式，活動圖強調(diào)一個活動

18、到另一個活動的控制流，而狀態(tài)圖強調(diào)從一個狀態(tài)到另一個狀態(tài)的流程，還需有外部事件來觸發(fā)?；顒訄D的主要目的是描述動作及對象狀態(tài)改變的結(jié)果。5.8.45.8.4活動圖組成活動圖組成 在UML中，活動圖的基本組成元素有：動作狀態(tài)、活動狀態(tài)、動作流、分支與合并、分叉與匯合、泳道和對象流。5.8.55.8.5順序圖概述順序圖概述 順序圖(Sequence Diagram)是一種交互圖，描述了對象之間傳遞消息的時間順序，用來表示用例中的行為順序。順序圖是強調(diào)在時間順序上的交互作用圖，順序圖中的每個消息可以是觸發(fā)事件、類中方法的操作調(diào)用或是類似于JAVA中RMI的遠程過程調(diào)用，當(dāng)接收對象收到消息時，會立即被激

19、活執(zhí)行相應(yīng)的動作。5.8.65.8.6順序圖組成順序圖組成 順序圖的組成元素有：對象、生命線、消息和激活。 : Actor : Actor對象1 : Example1對象1 : Example1對象2 : Example2對象2 : Example2臨時對象 : TempClass臨時對象 : TempClass1: 事件2: 調(diào)用操作3: 自調(diào)用4: 返回消息5: 創(chuàng)建臨時對象6: 調(diào)用操作7: 銷毀圖5-48 含有各種消息類型的順序圖5.8.75.8.7 通信圖概述通信圖概述 通信圖(Communication Diagram)是除了順序圖之外的另一種重要的交互圖。順序圖按照時間順序描述交互的過程，通信圖以消息為基礎(chǔ)包含一組相互聯(lián)系的對象靜態(tài)連接關(guān)系。 : 圖書管理員登錄對話.2: 創(chuàng)建登