UML參考手冊 第一部分 背景知識 第1章 UML 綜述 (轉)

UML參考手冊 第一部分 背景知識 第1章 UML 綜述 (轉)[@more@]

 

ML參考手冊  
  第一部分 背景知識  

這一部分介紹了UML的基本原理，包括UML建模的性質和目標以及UML覆蓋的所有功能領域。

　第1章 UML 綜述

　　本章是UML及其應用的一個瀏覽。
1.1 UML簡介
　　統一建模語言（UML）是一個通用的視覺化建模語言，用於對進行描述、視覺化處理、構造和建立軟體製品的文件。它記錄了對必須構造的系統的決定和理解，可用於對系統的理解、設計、瀏覽、、維護和資訊控制。UML 適用於各種方法、軟體生命週期的各個階段、各種應用領域以及各種開發工具，UML 是一種總結了以往建模技術的並吸收當今優秀成果的標準建模方法。UML包括概念的語義，表示法和說明，提供了靜態、動態、系統環境及組織結構的模型。它可被互動的視覺化建模工具所支援，這些工具提供了程式碼生成器和報表生成器。UML標準並沒有定義一種標準的開發過程，但它適用於迭代式的開發過程。它是為支援大部分現存的面向開發過程而設計的。
　　UML描述了一個系統的靜態結構和動態行為。UML將系統描述為一些離散的相互作用的物件並最終為外部提供一定的功能的模型結構。靜態結構定義了系統中的重要物件的屬性和操作以及這些物件之間的相互關係。動態行為定義了物件的時間特性和物件為完成目標而相互進行通訊的機制。從不同但相互聯絡的角度對系統建立的模型可用　於不同的目的。
　　UML還包括可將模型分解成包的結構，以便於軟體小組將大的系統分解成易於處理的塊結構，並理解和控制各個包之間的依賴關係，在複雜的開發環境中管理模型單元。它還包括用於顯示系統實現和組織執行的元件。
UML不是一門設計語言。但可以使用程式碼生成器工具將UML模型轉換為多種程式設計語言程式碼，或使用反向生成器工具將程式轉換為UML。UML不是一種可用於定理證明的高度形式化的語言，這樣的語言有很多種，但它們通用性較差，不易理解和使用。UML是一種通用建模語言。對於一些專門領域，例如使用者圖形介面（GUI）設計、超大規模積體電路（VLSI）設計、基於規則的人工智慧領域，使用專門的語言和工具可能會更適合些。UML是一種離散的建模語言，不適合對諸如工程和物理學領域中的連續系統建模。它是一個綜合的通用建模語言，適合對諸如由軟體、韌體或數字邏輯構成的離散系統建模。
1.2 UML 的歷史
　　UML是為了簡化和強化現有的大量物件導向開發方法這一目的而開發的。
1.2.1 物件導向的開發方法
　　利用傳統程式設計語言（如Cobol和 Fortran語言）的軟體開發方法出現於20世紀70年代，在80年代被廣泛採用，其中最重要的是結構化分析和結構化設計方法[Yourdon-79]和它的變體，如實時結構化設計方法[Ward-85]等。這些方法最初由Constantine、Demarco、Mellor、Ward、Yourdon和其他一些人發明和推廣，在一些大型系統，特別是和政府簽約的航空和國防領域的系統中取得了一定突破，在這些系統中，主持專案的政府官員強調開發過程的有組織性和開發設計文件的完備和充分。結果不總是像預料的那麼好—許多計算機輔助軟體工程系統（CASE）只是摘錄一些已實現的系統設計的報表生成器—儘管如此，這些方法中仍包含一些好的思想，有時在一些大系統中是很有效的。商業應用軟體更不願採用大型的CASE系統和開發方法。大部分商業企業都獨立開發本企業內部使用的軟體，客戶和締約人之間沒有對立關係，而這種關係正是大型政府工程的特徵。一般都認為商用系統比較簡單，不論這種看法是否正確，反正它不需要經過外界組織的檢查。
　　普遍認為，誕生於1967年的Simula-67是第一個物件導向的語言。儘管這個語言對後來的許多物件導向語言的設計產生了很大的影響，但是它沒有後繼版本。80年代初Smalltalk，語言的廣泛使用掀起了一場“物件導向運動”，隨之誕生了物件導向的C、C++、Eiffel和CLOS等語言。起初，儘管面嚮物件語言在實際使用中有一定的侷限性，但它仍然吸引了廣泛的注意力。在smalltalk語言成名約5 年後，第一批介紹物件導向軟體開發方法的書籍出現了。包括Shlaer/Mellor [Shlaer-88]和Coad/Yourdon [Coad-91]，緊接著又有Booch的[Booch-91]、Rumbaugh/Blaha/Premerlani/Eddy/Lorensen的[Rumbaugh-91]和Wirfs-Brock/Wilkerson/Wiener [Wirfs-Brock-90]（注意：圖書版權年代往往包括了上一年度7月份以後出版的書）。這些著作再加上　　　Golerg/Robson[Goldberg-83] Cox[Cox-86]和Meyer[Meyer-88] 等有關程式語言設計的著作，開創了物件導向方法的先河。第一階段在1990年末完成。稍晚[Jacobson-92]出版了，它建立在以前的成果的基礎上，介紹了一種稍微不同的方法，即以用例和開發過程為中心。
　　在以後的5年中，大批關於物件導向方法的書籍問世，各有自己的一套概念、定義、表示法、術語和適用的開發過程。有些書提出了一些新概念，但總的來說各個作者所使用的概念大同小異。許多後繼出版的書都照搬前人，自己再做一些小的擴充或修改。最早的著作者也沒閒著，他們大部分人都了自己前期的著作，採納了其他人一些好的思想。總之，出現了一些被廣泛使用的核心概念，另外還有一大批被個別人採納的概念。即使在被廣泛接受的核心概念裡，在各個物件導向方法中也有一些小的差異。這些物件導向方法之間的細微比較常使人覺得這些概念不知依據哪個為好，特別是非專業的讀者。
1.2.2 統一工作
　　在UML之前，已經有一些試圖將各種方法中使用的概念進行統一的初期嘗試，比較有名的一次是Coleman和他的同事們[Coleman-94]對OMT[Rumbaugh-91]、Booch[Booch-91]、CRC[Wirfs-Brock-90]方法使用的概念進行融合。由於這項工作沒有這些方法的原作者參與，實際上僅僅形成了一種新方法，而不能替換現存的各種方法。第一次成功合併和替換現存的各種方法的嘗試始於1994 年在Rational 軟體公司Rumbaugh與 Booch合作。他們開始合併OMT和Booch 方法中使用的概念，於1995年提出了第一個建議。此時，Jacobson 也加入了Rational公司開始與Rumbaugh和Booch一同工作。他們共同致力於設計統一建模語言。三位最優秀的物件導向方法學的創始人共同合作，為這項工作注入了強大的動力，打破了物件導向軟體開發領域內原有的平衡。而在此之前，各種方法的擁護者覺得沒有必要放棄自己已經採用的概s念而接受這種統一的思想。
　　1996年，OMG釋出了徵集向外界關於物件導向建模標準方法的訊息。UML的三位創始人開始與來自其他公司的軟體工程方法專家和開發人員一道制訂一套使OMG感興趣的方法，並設計一種能被軟體開發工具提供者、軟體開發方法學家和開發人員這些終端使用者所接受的建模語言。與此同時，其他一些人也在做這項富有競爭性的工作。1997年9月，所有建議終於被合併成一套UML方法提交到OMG。 最後的成果是許多人共同努力的結果。我們發起了建立UML的工作並提出了一些有益的建議，但是這些建議的最終成型是集體智慧的結晶。
1.2.3 標準化
　　1997年11月，UML被OMG全體成員一致透過，並被採納為標準。OMG承擔了進一步完善UML標準的工作。在UML標準透過前，就已經有許多概括UML精華的書出版發行。許多軟體開發工具供應商聲稱他們的產品支援或計劃支援UML，若干軟體工程方法學家宣佈他們將使用UML的表示法進行以後的研究工作。UML的出現似乎深受計算機界歡迎，因為它是由官方出面集中了許多專家的經驗而形成的，減少了各種軟體開發工具之間無謂的分歧。我們希望建模語言的標準化既能促進軟體開發人員廣泛使用物件導向建模技術，同時也能帶來UML支援工具和培訓市場的繁榮，因為不論是使用者還是供應商都不用再考慮到底應該採用哪一種開發方法。
1.2.4 核心組員
　　提出UML建議或進行UML標準修訂工作的核心組員有下列人員：
資料存取公司：Tom Digre
DHR 技術公司：Ed Sewitz
HP 公司：Martin Griss
IBM 公司：Steve Brodsky, Steve Cook, JWarmer
I—Lgix 公司：Eran Gery, David Harel
ICON Computing 公司：Desmond D'Souza
liCorp and James Martin 公司：Conrad Bock, James Odell
MCI 系統企業：Cris Kobryn, Joaquin Miller
ime 公司：John Hogg, Bran Selic
公司：Guus Ramackers
鉑技術公司：Dilhar Desilva
Rational 軟體公司：Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard,
Karin Palmkvist, James Rumbaugh
SAP 公司：Oliver Wiegert
SOFTEAM：Philippe Deray
Sterling 軟體公司：John Cheesman, Keith Short
Taskon 公司：Trygve Reenskaug
1.2.5 統一的意義
　　“統一”這個詞在UML中有下列一些相互關聯的含義：
＊　在以往出現的方法和表示法方面。UML合併了許多物件導向方法中被普遍接受的概念，對每一種概念，UML都給出了清晰的定義、表示法和有關術語。使用UML可以對已有的用各種方法建立的模型進行描述，並比原來的方法描述得更好。
＊　在軟體開發的生命期方面。UML對於開發的要求具有無縫性。開發過程的不同階段可以採用相同的一套概念和表示法，在同一個模型中它們可以混合使用。在開發的不同階段，不必轉換概念和表示。這種無縫性對迭代式的、增量式軟體開發是至關重要的。
＊　在應用領域方面。UML適用於各種應用領域的建模，包括大型的、複雜的、實時的、分散式的、集中式資料或計算的、嵌入式的系統。也許用某種專用語言來描述一些專門領域更有用，但在大部分應用領域中，UML 不但不比其他的通用語言遜色並且更好。
?在實現的程式語言和開發平臺方面。 UML可應用於執行各種不同的程式設計實現語言和開發平臺的系統。其中包括程式設計語言、、4GL、組織文件及韌體等。在各種情況下，前部分工作應當相同或相似，後部分工作因各種開發媒介的不同而有某種程度上的不同。
＊　在開發全過程方面。UML是一個建模型語言，不是對開發過程的細節進行描述的工具。就像通用程式設計語言可以用於許多風格的程式設計一樣，UML適用於大部分現有的或新出現的開發過程。尤其適用於我們所推薦的迭代式增量開發過程。
＊　在內部概念方面。在構建UML元模型的過程中，我們特別注意揭示和表達各種概念之間的內在聯絡並試圖用多種適用於已知和未知情況的辦法去把握建模中的概念。這個過程會增強對概念及其適用性的理解。這不是統一各種標準的初衷，但卻是統一各種標準最重要的結果之一。
1.3 UML的目標
　　UML語言的開發有多個目標。首先，最重要的目標是使UML一個通用的建模語言，可供所有建模者使用。它並非某人專有，且建立在計算機界普遍認同的基礎上，即它包括了各種主要的方法並可作為它們的建模語言。至少，我們希望它能夠替代OMT，Booch，Objectory方法以及參與UML建議制訂的其他人所使用的方法建立的模型。其次，我們希望 UML 採用源自OMt Booch, Objectory及其他主要方法的表示法，即儘可能地它能夠很好地支援設計工作，像封裝、分塊、記錄模型構造思路。此外，我們希望UML 準確表達當前軟體開發中的熱點問題，比如大規模、分佈、併發、方式和團體開發等。
　　UML並不試圖成為一個完整的開發方法。它不包括一步一步的開發過程。我們認為一個好的軟體開發過程對成功的開發軟體是至關重要的，我們向讀者推薦一本書[Jacobson-99]。UML和使用UML的軟體開發過程是兩回事，這一些很重要。我們希望UML可以支援所有的，至少是目前現有的大部分軟體開發過程。UML包含了所有的概念，我們認為這些概念對於支援基於一個健壯的構架來解決用例的需求的迭代式開發過程是必要的。
　　UML的最終目標是在儘可能簡單的同時能夠對實際需要建立的系統的各個方面建模。UML需要有足夠的表達能力以便可以處理現代軟體系統中出現的所有概念，例如併發和分佈，以及軟體工程中使用的技巧，如封裝和元件。它必須是一個通用語言，像任何一種通用程式設計語言一樣。然而，這樣就意味著UML必將十分龐大，不可能像描述一個近乎於玩具一樣的軟體系統那樣簡單。現代語言和比起40年前要複雜多，因為我們對它們的要求越來越多。UML提供了多種模型，不是在一天之內就能夠掌握的。它比先前的建模語言更復雜，因為它更全面。但是你不必一下就完全學會它，就像學習任何一種程式設計語言、作業系統或是複雜的應用軟體一樣。
1.4 UML概念域
　　UML的概念和模型可以分成以下幾個概念域。
1. 靜態結構。
　　任何一個精確的模型必須首先定義所涉及的範圍，即確定有關應用、內部特性及其相互關係的關鍵概念。UML的靜態元件稱為靜態檢視。靜態檢視用類構造模型來表達應用，每個類由一組包含資訊和實現行為的離散物件組成。物件包含的資訊被作為屬性，它們的行為被作為操作。多個類透過泛化處理可以具有一些共同的結構。子類在繼承它們共同的父類的結構和行為的基礎上增加了新的結構和行為。物件與其他物件之間也具有執行時間連線，這種物件與物件之間的關係被稱為類間的關聯。一些元素透過依賴關係組織在一起，這些依賴關係包括在抽象級上進行模型轉換、模板引數的捆綁、授予許可以及透過一種元素使用另一種元素等。另一類關係包括用例和資料流的合併。靜態檢視主要使用類圖。靜態檢視可用於生成程式中用到的大多數資料結構宣告。在UML檢視中還要用到其他型別的元素，比如介面、資料型別、用例和訊號等，這些元素統稱為類元，它們的行為很像在每種類元上具有一定限制的類。
2. 動態行為。
　　有兩種方式對行為建模。一種是根據一個物件與外界發生關係的生命歷史；另一種是一系列相關物件之間當它們相互作用實現行為時的通訊方式。孤立物件的檢視是狀態機—當物件基於當前狀態對事件產生反應，執行作為反應的一部分的動作，並從一種狀態轉換到另一種狀態時的檢視。狀態機模型用狀態圖來描述。
相互作用物件的系統檢視是一種協作，一種與語境有關的物件檢視和相互之間的鏈，透過資料鏈物件間存在著訊息流。檢視點將資料結構、控制流和資料流在一個檢視中統一起來。協作和互操作用順序圖和協作圖來描述。對所有行為檢視起指導作用的是一組用例，每一個用例描述了一個用例參與者或系統外部使用者可見的一個功能。
3. 實現構造
　　UML模型既可用於邏輯分析又可用於物理實現。某些元件代表了實現。構件是系統中物理上的可替換的部分，它按照一組介面來設計並實現。它可以方便地被一個具有同樣規格說明的構件替換。節點是執行時間計算資源，資源定義了一個位置。它包括構件和物件。部署圖描述了在一個實際執行的系統中節點上的資源配置和構件的排列以及構件包括的物件，幷包括節點間內容的可能遷移。
4. 模型組織
　　計算機能夠處理大型的單調的模型，但人力不行。對於一個大型系統，建模資訊必須被劃分成連貫的部分，以便工作小組能夠同時工作在不同部分上。即使是一個小系統，人的理解能力也要求將整個模型的內容組織成一個個適當大小的包。包是UML模型通用的層次組織單元，它們可以用於、訪問控制、置以管理配及構造包含可重用的模型單元庫。包之間的依賴關係是對包的組成部分之間的依賴關係的歸納。系統整個構架可以在包之間施加依賴關係。因此，包的內容必須符合包的依賴關係和有關的構架要求。
5. 擴充套件機制
　　無論一種語言能夠提供多麼完善的機制，人們總是想擴充套件它的功能。我們已使UML具有一定的擴充套件能力，相信能夠滿足大多數對UML擴充的需求而不改變語言的基礎部分。構造型是一種新的模型元素，與現有的模型元素具有相同的結構，但是加上了一些附加限制，具有新的解釋和圖示。程式碼生成器和其他的工具對它的處理過程也發生了變化。標記值是一對任意的標記值字串，能夠被連線到任何一種模型元素上並代表任何資訊，如資訊、程式碼生成指示資訊和構造型所需要的值。標記和值用字串代表。是用某種特定語言（如程式設計語言）的文字字串表達的條件專用語言或自然語言。UML提供了一個表達約束的語言，名為OCL。與所有其他擴充套件機制一樣，必須小心使用這些擴充套件機制，因為有可能形成一些別人無法理解的方言。但這些機制可以避免語言基礎發生根本性變化。
1.5 和圖表語法
　　本書列舉了許多演示實際模型的表示式和圖表，以及表示式的語法和圖表的註釋。為了儘量避免將解釋說明和例項弄混，本書採用了一些約定的格式。
在圖表和文字表示式中實際的表示法部分用Helvetica字型印刷。例如，模型中出現的Helvetica字型的類名是一　　個合法的名稱。語法表示式中的括弧是一個可能出現在實際表示式中的括弧，它不是實際語法機構的一部分。例如：Order.create(customer,amount)
在連續的文中，關鍵詞和模型元素名都用Helvetica字型印刷，如：Order或Customer。
在一個語法表示式子中，句法單元名可以被實際的一段文字替代，這樣的句法單元名用斜體印刷，如：name。斜體和下劃線說明替換文字具有給定的性質。例如：
name. Operation(argument,..)
object-name:class
　　在語法表示式中，下標和上劃線用於指示某種語法性質。例如：
expression 這個表示式是任選的。
　　expressionlist 用逗號來分隔一系列表示式。如果出現了零個或者一個重複符號，則不需要分隔符。每個重複符號都要用一個單獨的替換符號。如果一個除逗號之外的標點符號出現在下標中，則它是分隔符。
=expressionlist 用上劃線來連線兩個或多個屬於同一單元的可選的或重複出現的專案。在這個例子中，等號和表示式構成一個可以使用或省略的單元。如果只有一個專案，可以不用上劃線。
　　在圖表中，楷體和箭頭是註釋，它們是解釋性說明而不是實際表示法的一部分。其他文字和符號是實際表示法的一部分。