目錄：
UML的發(fā)展史
UML的作用
UML的構成
UML的適用領(lǐng)域
正文：
計算機有軟件和硬件兩部分組成，從計算機誕生到現在，硬件技術(shù)始終比軟件技術(shù)的發(fā)展速度快。上世紀60年代，“軟件危機”發(fā)生，硬件技術(shù)的迅速發(fā)展使得計算機價(jià)格下降，成了普通人可以用得起的“家用電器”；人們需要更加復雜的軟件系統來(lái)滿(mǎn)足他們工作、生活中的各種需要，但是，當時(shí)的軟件開(kāi)發(fā)模式很難開(kāi)發(fā)出復雜的軟件，即使開(kāi)發(fā)出來(lái)，其可靠性、可維護性都是很大的問(wèn)題。
為了解決“軟件危機”，人們提出了“軟件工程”的概念，試圖將工程化的思想引入到軟件業(yè)。在這一階段，誕生了很多的開(kāi)發(fā)方法，其中包括面向對象的開(kāi)發(fā)方法，由于面向對象的各種優(yōu)點(diǎn)，這種開(kāi)發(fā)方法得到了大家的普遍關(guān)注，出現了Simula、C++ 、Java、 C#等面向對象的語(yǔ)言，也出現了各種面向對象的建模方法：OMT、OOSE、Booch等。這些建模方法之間各有區別，對于開(kāi)發(fā)人員來(lái)講，如同三門(mén)不同的語(yǔ)言，使用不同語(yǔ)言的開(kāi)發(fā)人員不能很好的交流。
這時(shí)，人們期待一種統一的建模語(yǔ)言的誕生，如同建筑設計圖一樣，符號簡(jiǎn)單、沒(méi)有二義性而且更重要的是人人都能夠看懂，交流起來(lái)很方便，就這樣，UML誕生了，UML提出了一套IT專(zhuān)業(yè)人員期待多年的統一的標準建模符號。通過(guò)使用UML，人員能夠閱讀和交流系統架構和設計規劃，就像建筑工人多年來(lái)所使用的建筑設計圖一樣。
在1995年10月，Grady Booch和James Rumbaugh一同工作，為了合并兩大著(zhù)名的對象方法——Booch'93和OMT-2，合并后的新方法定為“統一方法”(Unified Method)，其為UML的前身。后來(lái)，在1995年秋天，Ivar Jacobson也加入研究行列，動(dòng)手合并另一個(gè)著(zhù)名的對象方法—— OOSE。在這之后的一年，他們才公布UML，正式將其定位為建模語(yǔ)言，并且舍棄了先前的統一方法。這令人精神一振，因為UML不再是另一個(gè)老掉牙的對象方法了，它是一個(gè)新發(fā)明，至此UML真正誕生了。1997年十一月，UML的1.1版出爐了，OMG從此接過(guò)了制定以后各個(gè)版本的責任。各個(gè)版本及發(fā)布年限參見(jiàn)下圖
在建筑領(lǐng)域，建筑設計師可以用畫(huà)在圖紙上的模型圖、存在計算機中的模型或實(shí)際的三維模型是自己的設計結果可視化，并用這些模型來(lái)做設計方面的試驗。建造、修改一個(gè)小的模型比較，這使得設計人員不需要花費什么代價(jià)就可以進(jìn)行創(chuàng )造和革新，最終設計出經(jīng)濟、安全、美觀(guān)且符合用戶(hù)需求的建筑。
在軟件領(lǐng)域，UML充當了最終軟件產(chǎn)品的模型，UML通過(guò)各種模型圖，從不同角度出發(fā)分析問(wèn)題，每一種模型圖都是最終軟件產(chǎn)品的一種投影，設計人員可以用這些模型圖與用戶(hù)交流，確認用戶(hù)的需求，設計人員可以用這些模型圖與開(kāi)發(fā)人員交流，確認開(kāi)發(fā)的可行性方案，設計人員可以用這些模型圖與測試人員交流，確認測試的完備性等等，總之，通過(guò)使用UML，可以使開(kāi)發(fā)過(guò)程中不同角色的人員之間能夠得到高效的溝通，這樣，可以最大限度的保證每個(gè)人員心目中的最終產(chǎn)物的一致性，從而使開(kāi)發(fā)更加高效、產(chǎn)物更加“精確”。
UML的三要素：基本構造塊、規則、公共機制。
1.基本構造塊由三部分組成：事物、關(guān)系、圖組成。
1.1四種事物及在UML中各種元素所屬的事物如下圖所示：
1.2 四種關(guān)系：關(guān)聯(lián)、泛化、實(shí)現、依賴(lài)：
1.3 9種圖及其所屬的視圖如下所示：
2.規則
不能簡(jiǎn)單的把UML的構造塊按隨機的方式放在一起。像任何語(yǔ)言一樣，UML有一套規則，這些規則描述了一個(gè)結構良好的模型看起來(lái)應該像什么
UML有用于描述如下事物的語(yǔ)義規則
·命名：為事物、關(guān)系和圖起名
·范圍：給一個(gè)名稱(chēng)以特定含義的語(yǔ)境
·可見(jiàn)性：怎樣讓其他人使用或看見(jiàn)名稱(chēng)
·完整性：事物如何正確、一致的相互聯(lián)系
·執行運行或模擬動(dòng)態(tài)模型的含義是什么
3. 公共機制
略
UML的目標是以面向對象的方式來(lái)描述任何類(lèi)型的系統，具有很寬的應用領(lǐng)域。其中最常用的是建立軟件系統的模型，但它同樣可以用于描述非軟件領(lǐng)域的系統，如機械系統、企業(yè)機構或業(yè)務(wù)過(guò)程，以及處理復雜數據的信息系統、具有實(shí)時(shí)要求的工業(yè)系統或工業(yè)過(guò)程等?？傊?，UML是一個(gè)通用的標準建模語(yǔ)言，可以對任何具有靜態(tài)結構和動(dòng)態(tài)行為的系統進(jìn)行建模。
此外，UML適用于系統開(kāi)發(fā)過(guò)程中從需求規格描述到系統完成后測試的不同階段。在需求分析階段，可以用用例來(lái)捕獲用戶(hù)需求。通過(guò)用例建模，描述對系統感興趣的外部角色及其對系統（用例）的功能要求。分析階段主要關(guān)心問(wèn)題域中的主要概念（如抽象、類(lèi)和對象等）和機制，需要識別這些類(lèi)以及它們相互間的關(guān)系，并用UML類(lèi)圖來(lái)描述。為實(shí)現用例，類(lèi)之間需要協(xié)作，這可以用UML動(dòng)態(tài)模型來(lái)描述。在分析階段，只對問(wèn)題域的對象（現實(shí)世界的概念）建模，而不考慮定義軟件系統中技術(shù)細節的類(lèi)（如處理用戶(hù)接口、數據庫、通訊和并行性等問(wèn)題的類(lèi)）。這些技術(shù)細節將在設計階段引入，因此設計階段為構造階段提供更詳細的規格說(shuō)明。
編程（構造）是一個(gè)獨立的階段，其任務(wù)是用面向對象編程語(yǔ)言將來(lái)自設計階段的類(lèi)轉換成實(shí)際的代碼。在用UML建立分析和設計模型時(shí)，應盡量避免考慮把模型轉換成某種特定的編程語(yǔ)言。因為在早期階段，模型僅僅是理解和分析系統結構的工具，過(guò)早考慮編碼問(wèn)題十分不利于建立簡(jiǎn)單正確的模型。
UML模型還可作為軟件測試階段的依據。系統通常需要經(jīng)過(guò)單元測試、集成測試、系統測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據：?jiǎn)卧獪y試使用類(lèi)圖和類(lèi)規格說(shuō)明；集成測試使用部件圖和合作圖；系統測試使用用例圖來(lái)驗證系統的行為；驗收測試由用戶(hù)進(jìn)行，以驗證系統測試的結果是否滿(mǎn)足在分析階段確定的需求?！?nbsp;
總之，標準建模語(yǔ)言UML適用于以面向對象技術(shù)來(lái)描述任何類(lèi)型的系統，而且適用于系統開(kāi)發(fā)的不同階段，從需求規格描述直至系統完成后的測試和維護。
http://www.hudong.com/wiki/UML#9
http://book.51cto.com/art/200801/65305.htm
http://wenku.baidu.com/view/e580063a580216fc700afd07.html
http://www.docin.com/p-4662320.html
http://blog.csdn.net/cjqhuadielei/article/details/5900832
聯(lián)系客服
