標準建模語言UML概述

1. 標準建模語言UML的出現
公認的面向對象建模語言出現於70年代中期。從1989年到1994年,其數量從不到十種增加到了五十多種。在衆多的建模語言中,語言的創造者努力推崇自己的產品,並在實踐中不斷完善。但是,OO方法的用戶並不瞭解不同建模語言的優缺點及相互之間的差異,因而很難根據應用特點選擇合適的建模語言,於是爆發了一場"方法大戰"。90年代中,一批新方法出現了,其中最引人注目的是Booch 1993、OOSE和OMT-2等。


Booch是面向對象方法最早的倡導者之一,他提出了面向對象軟件工程的概念。1991 年,他將以前面向Ada的工作擴展到整個面向對象設計領域。Booch 1993比較適合於系統的設計和構造。Rumbaugh等人提出了面向對象的建模技術(OMT)方法,採用了面向對象的概念,並引入各種獨立於語言的表示符。這種方法用對象模型、動態模型、功能模型和用例模型,共同完成對整個系統的建模,所定義的概念和符號可用於軟件開發的分析、設計和實現的全過程,軟件開發人員不必在開發過程的不同階段進行概念和符號的轉換。OMT-2特別適用於分析和描述以數據爲中心的信息系統。Jacobson於1994年提出了OOSE方法,其最大特點是面向用例(Use-Case),並在用例的描述中引入了外部角色的概念。用例的概念是精確描述需求的重要武器,但用例貫穿於整個開發過程,包括對系統的測試和驗證。OOSE比較適合支持商業工程和需求分析。此外,還有Coad/Yourdon方法,即著名的OOA/OOD,它是最早的面向對象的分析和設計方法之一。該方法簡單、易學,適合於面向對象技術的初學者使用,但由於該方法在處理能力方面的侷限,目前已很少使用。


概括起來,首先,面對衆多的建模語言,用戶由於沒有能力區別不同語言之間的差別,因此很難找到一種比較適合其應用特點的語言;其次,衆多的建模語言實際上各有千秋;第三,雖然不同的建模語言大多類同,但仍存在某些細微的差別,極大地妨礙了用戶之間的交流。因此在客觀上,極有必要在精心比較不同的建模語言優缺點及總結面向對象技術應用實踐的基礎上,組織聯合設計小組,根據應用需求,取其精華,去其糟粕,求同存異,統一建模語言。


1994年10月,Grady Booch和Jim Rumbaugh開始致力於這一工作。他們首先將Booch9 3和OMT-2 統一起來,並於1995年10月發佈了第一個公開版本,稱之爲統一方法UM 0.8(Un itied Method)。1995年秋,OOSE 的創始人Ivar Jacobson加盟到這一工作。經過Booch、Rumbaugh和Jacobson三人的共同努力,於1996年6月和10月分別發佈了兩個新的版本,即UML 0.9和UML 0.91,並將UM重新命名爲UML(Unified Modeling Language)。1996年,一些機構將UML作爲其商業策略已日趨明顯。UML的開發者得到了來自公衆的正面反應,並倡議成立了UML成員協會,以完善、加強和促進UML的定義工作。當時的成員有DEC、HP、I-Logix、 Itellicorp、 IBM、ICON Computing、MCI Systemhouse、Micr osoft、Oracle、Rational Software、TI以及Unisys。這一機構對UML 1.0(1997年1月)及UML 1.1(1997年11月17日)的定義和發佈起了重要的促進作用。

UML是一種定義良好、易於表達、功能強大且普遍適用的建模語言。它溶入了軟件工程領域的新思想、新方法和新技術。它的作用域不限於支持面向對象的分析與設計,還支持從需求分析開始的軟件開發的全過程。


在美國,截止1996年10月,UML獲得了工業界、科技界和應用界的廣泛支持,已有700多個公司表示支持採用UML作爲建模語言。1996年底,UML已穩佔面向對象技術市場的85%,成爲可視化建模語言事實上的工業標準。1997年11月17日,OMG採納UML 1.1作爲基於面向對象技術的標準建模語言。UML代表了面向對象方法的軟件開發技術的發展方向,具有巨大的市場前景,也具有重大的經濟價值和國防價值。


2. 標準建模語言UML的內容

首先,UML融合了Booch、OMT和OOSE方法中的基本概念,而且這些基本概念與其他面向對象技術中的基本概念大多相同,因而,UML必然成爲這些方法以及其他方法的使用者樂於採用的一種簡單一致的建模語言;其次,UML不僅僅是上述方法的簡單匯合,而是在這些方法的基礎上廣泛徵求意見,集衆家之長,幾經修改而完成的,UML擴展了現有方法的應用範圍;第三,UML是標準的建模語言,而不是標準的開發過程。儘管UML的應用必然以系統的開發過程爲背景,但由於不同的組織和不同的應用領域,需要採取不同的開發過程。
作爲一種建模語言,UML的定義包括UML語義和UML表示法兩個部分。
(1) UML語義 描述基於UML的精確元模型定義。元模型爲UML的所有元素在語法和語義上提供了簡單、一致、通用的定義性說明,使開發者能在語義上取得一致,消除了因人而異的最佳表達方法所造成的影響。此外UML還支持對元模型的擴展定義。
(2) UML表示法 定義UML符號的表示法,爲開發者或開發工具使用這些圖形符號和文本語法爲系統建模提供了標準。這些圖形符號和文字所表達的是應用級的模型,在語義上它是UML元模型的實例。
標準建模語言UML的重要內容可以由下列五類圖(共9種圖形)來定義:


·第一類是用例圖,從用戶角度描述系統功能,並指出各功能的操作者。
·第二類是靜態圖(Static diagram),包括類圖、對象圖和包圖。其中類圖描述系統中類的靜態結構。不僅定義系統中的類,表示類之間的聯繫如關聯、依賴、聚合等,也包括類的內部結構(類的屬性和操作)。類圖描述的是一種靜態關係,在系統的整個生命週期都是有效的。對象圖是類圖的實例,幾乎使用與類圖完全相同的標識。他們的不同點在於對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由於對象存在生命週期,因此對象圖只能在系統某一時間段存在。包由包或類組成,表示包與包之間的關係。包圖用於描述系統的分層結構。
·第三類是行爲圖(Behavior diagram),描述系統的動態模型和組成對象間的交互關係。其中狀態圖描述類的對象所有可能的狀態以及事件發生時狀態的轉移條件。通常,狀態圖是對類圖的補充。在實用上並不需要爲所有的類畫狀態圖,僅爲那些有多個狀態其行爲受外界環境的影響並且發生改變的類畫狀態圖。而活動圖描述滿足用例要求所要進行的活動以及活動間的約束關係,有利於識別並行活動。
·第四類是交互圖(Interactive diagram),描述對象間的交互關係。其中順序圖顯示對象之間的動態合作關係,它強調對象之間消息發送的順序,同時顯示對象之間的交互;合作圖描述對象間的協作關係,合作圖跟順序圖相似,顯示對象間的動態合作關係。除顯示信息交換外,合作圖還顯示對象以及它們之間的關係。如果強調時間和順序,則使用順序圖;如果強調上下級關係,則選擇合作圖。這兩種圖合稱爲交互圖。
·第五類是實現圖( Implementation diagram )。其中構件圖描述代碼部件的物理結構及各部件之間的依賴關係。一個部件可能是一個資源代碼部件、一個二進制部件或一個可執行部件。它包含邏輯類或實現類的有關信息。部件圖有助於分析和理解部件之間的相互影響程度。
配置圖定義系統中軟硬件的物理體系結構。它可以顯示實際的計算機和設備(用節點表示)以及它們之間的連接關係,也可顯示連接的類型及部件之間的依賴性。在節點內部,放置可執行部件和對象以顯示節點跟可執行軟件單元的對應關係。


從應用的角度看,當採用面向對象技術設計系統時,首先是描述需求;其次根據需求建立系統的靜態模型,以構造系統的結構;第三步是描述系統的行爲。其中在第一步與第二步中所建立的模型都是靜態的,包括用例圖、類圖(包含包)、對象圖、組件圖和配置圖等五個圖形,是標準建模語言UML的靜態建模機制。其中第三步中所建立的模型或者可以執行,或者表示執行時的時序狀態或交互關係。它包括狀態圖、活動圖、順序圖和合作圖等四個圖形,是標準建模語言UML的動態建模機制。因此,標準建模語言UML的主要內容也可以歸納爲靜態建模機制和動態建模機制兩大類。

 

3. 標準建模語言UML的主要特點
標準建模語言UML的主要特點可以歸結爲三點:
(1) UML統一了Booch、OMT和OOSE等方法中的基本概念。
(2) UML還吸取了面向對象技術領域中其他流派的長處,其中也包括非OO方法的影響。UML符號表示考慮了各種方法的圖形表示,刪掉了大量易引起混亂的、多餘的和極少使用的符號,也添加了一些新符號。因此,在UML中匯入了面向對象領域中很多人的思想。這些思想並不是UML的開發者們發明的,而是開發者們依據最優秀的OO方法和豐富的計算機科學實踐經驗綜合提煉而成的。
(3) UML在演變過程中還提出了一些新的概念。在UML標準中新加了模板(Stereotyp es)、職責(Responsibilities)、擴展機制(Extensibility mechanisms)、線程(Thread s)、過程(Processes)、分佈式(Distribution)、併發(Concurrency)、模式(Patterns) 、合作(Collaborations)、活動圖(Activity diagram)等新概念,並清晰地區分類型(Ty pe)、類(Class)和實例(Instance)、細化(Refinement)、接口(Interfaces)和組件(Com ponents)等概念。


因此可以認爲,UML是一種先進實用的標準建模語言,但其中某些概念尚待實踐來驗證,UML也必然存在一個進化過程(未完待續)。
 

4. 標準建模語言UML的應用領域


UML的目標是以面向對象圖的方式來描述任何類型的系統,具有很寬的應用領域。其中最常用的是建立軟件系統的模型,但它同樣可以用於描述非軟件領域的系統,如機械系統、企業機構或業務過程,以及處理複雜數據的信息系統、具有實時要求的工業系統或工業過程等。總之,UML是一個通用的標準建模語言,可以對任何具有靜態結構和動態行爲的系統進行建模。此外,UML適用於系統開發過程中從需求規格描述到系統完成後測
試的不同階段。在需求分析階段,可以用用例來捕獲用戶需求。通過用例建模,描述對系統感興趣的外部角色及其對系統(用例)的功能要求。分析階段主要關心問題域中的主要概念(如抽象、類和對象等)和機制,需要識別這些類以及它們相互間的關係,並用UML類圖來描述。爲實現用例,類之間需要協作,這可以用UML動態模型來描述。在分析階段,只對問題域的對象(現實世界的概念)建模,而不考慮定義軟件系統中技術細節的類(如處理用戶接口、數據庫、通訊和並行性等問題的類)。這些技術細節將在設計階段引入,因此設計階段爲構造階段提供更詳細的規格說明。


編程(構造)是一個獨立的階段,其任務是用面向對象編程語言將來自設計階段的類轉換成實際的代碼。在用UML建立分析和設計模型時,應儘量避免考慮把模型轉換成某種特定的編程語言。因爲在早期階段,模型僅僅是理解和分析系統結構的工具,過早考慮編碼問題十分不利於建立簡單正確的模型。


UML模型還可作爲測試階段的依據。系統通常需要經過單元測試、集成測試、系統測試和驗收測試。不同的測試小組使用不同的UML圖作爲測試依據:單元測試使用類圖和類規格說明;集成測試使用部件圖和合作圖;系統測試使用用例圖來驗證系統的行爲;驗收測試由用戶進行,以驗證系統測試的結果是否滿足在分析階段確定的需求。


總之,標準建模語言UML適用於以面向對象技術來描述任何類型的系統,而且適用於系統開發的不同階段,從需求規格描述直至系統完成後的測試和維護。

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章