UML建模技術是一種建模語言，指用模型元素來組建整個系統的模型，模型元素包括系統中的類、類和類之間的關聯、類的實例相互配合實現系統的動態行為等。
基本介紹
UML,建模技術,組成部分,技術要點,注意問題,
UML
UML是面向對象開發中一種通用的圖形化建模語言，它定義良好、易於表達、功能強大且普遍適用。面向對象的分析主要在加強對問題空間和系統任務的理解、改進各方交流、與需求保持一致和支持軟體重用等4個方面表現出比其他系統分析方法更好的能力，成為主流的系統分析方法。UML的出現既統一了Booch、OMT、OOSE，以及其他方法，又統一了面向對象方法中使用的符號，並且在提出後不久就被OMG接納為其標準之一。從而改變了數十種面向對象的建模語言相互獨立且各有千秋的局面，使得面向對象的分析技術有了空前發展。它本身成為現代軟體工程環境中對象分析和設計的重要工具，被視為面向對象技術的重要成果之一。
建模技術
UML提供了多種圖形可視化描述模型元素，同一個模型元素可能會出現在多個圖中對應多個圖形元素，人們可以從多個視圖來考察模型。
組成部分
UML建模技術主要分為結構建模、動態建模和模型管理建模3個方面：
第1個方面是從系統的內部結構和靜態角度來描述系統的，在靜態視圖、用例視圖、實施視圖和配置視圖中適用，採用了類圖、用例圖、組件圖和配置圖等圖形。例如類圖用於描述系統中各類的內部結構（類的屬性和操作）及相互間的關聯、聚合和依賴等關係，包圖用於描述系統的分層結構等；
第2個方面是從系統中對象的動態行為和組成對象間的相互作用、訊息傳遞來描述系統的，在狀態機視圖、活動視圖和互動視圖中適用，採用了狀態機圖、活動圖、順序圖和合作圖等圖形，例如狀態機圖用於一個系統或對象從產生到結束或從構造到清除所處的一系列不同的狀態；
第3個方面描述如何將模型自身組織到高層單元，在模型管理視圖中適用，採用的圖形是類圖。建模的工作集中在前兩方面，而且並非所有圖形元素都適用或需要採用。
在嵌入式軟體開發中，面向對象技術內在支持了對系統的抽象、分層及復用技術，能夠很好地控制系統的複雜性，也逐漸廣泛套用。實時UML語言是在嵌入式開發中適用的建模語言。現有許多功能強大UML建模工具，有些工具在引入或加強嵌入式實時系統套用領域的功能，例如Rose RealTime和Rhapsody。
技術要點
一、UML建模技術的特性與發展現狀
UML是Unified Modeling Language(統一建模語言)
1、已進入全面套用階段的事實標準
2、套用領域正在逐漸擴展，包括嵌入式系統建模、業務建模、流程建模等多個領域
3、成為“產生式編程”的重要支持技術：MDA、可執行UML等
二、UML建模技術的目的與原則
1、幫助我們按照實際情況或按我們需要的樣式對系統進行可視化;提供一種詳細說明系統的結構或行為的方法;給出一個指導系統構造的模板;對我們所做出的決策進行文檔化。
2、僅當需要模型時，才構建它。
3、選擇要創建什麼模型對如何動手解決問題和如何形成解決方案有著意義深遠的影響;每一種模型可以在不同的精度級別上表示;最好的模型是與現實相聯繫的;單個模型是不充分的。對每個重要的系統最好用一組幾乎獨立的模型去處理。
三、誰應該使用UML建模技術
2、需求模型：以需求分析人員為主，系統分析員是主力，領域專家提供指導，架構師和資深開發人員參與
3、設計模型：高層設計模型以架構師為主，系統分析員從需求方面提供支持，資深開發人員從技術實現方面提供支持。詳細設計模型則以資深開發人員為主，架構師提供指導。
4、實現模型：以資深開發人員(設計人員)為主，架構師提供總體指導。
5、資料庫模型：以資料庫開發人員為主，架構師提供指導，資深開發人員(設計人員)予以配合。
注意問題
用UML建模時，對軟體開發過程是有要求的，必須是用例驅動，以架構為中心，疊代和遞增的開發，如果軟體開發組織的軟體開發過程不能滿足這三點要求，那么UML的使用效果就會大打折扣，下面詳細論述：
一、用例驅動
用例驅動意味著為系統定義的用例是整個開發過程的基礎。
用例在多個核心工作流程中都發揮了作用。
1、用例的概念可用來表示業務流程，我們稱這種用例的變體為“業務用例”。
2、用例模型是需求工作流程的輸出結果。在這一早期流程中，需要通過用例來建立用戶希望系統完成的任務的模型。這樣，用例構成了一個重要的基本概念，客戶和系統開發人員都必須認可這個概念。
3、在分析設計中，用例是在設計模型中實現的。您需要生成用例實現來說明在設計模型中如何通過對象的互動來執行用例。此模型根據設計對象來說明所實施系統的各個組成部分，以及這些部分如何通過相互作用來執行用例。
4、在實施階段，設計模型就是實施的規約。由於用例是設計模型的基礎，所以用例需通過設計類來實施。
6、在項目管理過程中，用例被用來作為計畫疊代式開發的基礎。
7、在部署工作流程中，它們構成用戶手冊闡述內容的基礎。用例也可用來確定產品構件如何排列組合。例如，客戶可通過將用例進行某種組合來配置一個系統。
二、以架構為中心
使用UML建模時要以架構為中心，構架之所以重要，原因有以下幾點：
1、它使您可對項目進行並保持理智的控制，應付項目中複雜多變的情況，同時保持系統的完整性。
一個複雜的系統不僅僅是其各組成部分之和，也不光是一連串沒有關聯關係的、很小的技巧決定。它必須依靠某種連貫統一的結構來有條理地組織那些部分，並且提供準確的規則，使系統發展過程中，其複雜程度不會膨脹，超越人類的理解力。
通過建立用於討論設計問題的一套公共參考材料和一個公共辭彙表，構架提供了增進交流和理解的手段。
2、它是大規模復用的有效基礎。
通過明確闡述它們之間的主要構件和關鍵接口,構架為您決定重複使用提供依據，包括內部復用(確定公用的部分)和外部復用(併入現成的構件)。它還允許更大規模上的復用：構架本身的復用，用於處理同一領域中的不同功能。
3、構架還可作為項目管理的基礎。
項目計畫和人員配備是根據主要構件的類別組織進行的。基本的結構決策是由一個人員組成相對固定的構架小組作出的，他們不是分散的。而開發活動則被分配給若干個小組，每個小組負責開發系統的一個或若干個部分。
三、疊代和遞增的開發
使用UML建模時疊代式方法一般要優於線性或瀑布式方法，其原因很多。
1、允許變更需求。需求有時會變化，這常常給項目帶來麻煩，它們會導致延期交付、工期延誤、客戶不滿意、開發人員受挫。
2、逐步集成元素。在疊代式方法中，集成可以說是連續不斷的。過去在項目結束時要占到整個項目工作量的那段較長的、不確定的且棘手的時期，現分散到六至九個集成部分中，每一部分要集成的元素都比過去少得多。
3、及早降低風險。因為風險一般只有在集成階段才能發現或得到處理。在初期疊代時，檢查所有的核心工作流程，對項目使用的工具、市售軟體及人員技能等許多方面進行磨合。過去認定的風險可能被證明不再是風險，而又可能出現一批新的未曾懷疑過的風險。
4、有助於組織學習和提高。團隊成員有機會在整個生命周期中邊做邊學，各顯其能。測試員可以早一些開始測試，技術文檔編寫員可及早開始編寫，其他人也是如此。如果是非疊代式開發，這些人在初期只能制定計畫或培訓技能，空等著開始他們的工作。培訓需求等也可在評估複審中儘早提出。
5、提高復用性。因為分部分設計或實施比起預先確定所有共性更容易確定公用部分。確定和開發可重複使用的部分並非易事。早期疊代中的設計複審可使構架設計師確定毋庸置疑的潛在復用部分，並在以後的疊代中開發和完善這些公用代碼。
6、生成性能更強壯的產品。因為在多次疊代中您總是不斷地糾正錯誤。在產品脫離先啟階段後的初期疊代中仍然可以發現缺陷。性能上的瓶頸可以儘早發現並處理，而不象在交付前夕，此時已來不及處理。
7、容許產品進行戰術改變。例如同現有的同類產品競爭。可以決定採用搶先競爭對手一步的方法，提前發布一個功能簡化的產品，或者採用其他廠商的已有技術。
8、疊代流程自身可在進行過程中得到改進和精煉。一次疊代結束時的評估不僅要從產品和進度的角度來考察項目的情況，而且還要分析組織和流程本身有什麼待改進之處，以便在下次疊代中更好地完成任務。
通常在軟體開發過程中，疊代在數量、持續時間和目標上都是按計畫進行的。參與者的任務和職責都已確定好。對進度進行的目標評測都將記錄備查。從一次疊代到下一次疊代確實會存在返工現象，但返工也是嚴格按規定進行的。
四、使用不當的問題
很多企業員工在使用UML建模的過程中，只是進行了領域建模，沒有進行用例建模，這樣是不能最大可能地發揮UML的優勢的，因為該組織的軟體開發過程不是用例驅動的。
如果軟體開發組織的軟體開發過程不能滿足上述三點要求，那么UML的使用效果就會大打折扣。也會產生一些問題，有些組織在使用UML之後，發現前期花很長時間設計的模型到了項目的中後期和真正的開發成果相去甚遠，以至於全都束之高閣了，如果產生這樣的問題，就應該仔細研究一下組織的軟體開發過程，是否滿足上述三點要求，如果軟體開發過程不滿足疊代的開發，模型沒有隨著進度改進，這種問題就很容易出現。
UML2.0和MDA(模型驅動架構)提出了一些解決開發周期前期和後續的模型不一致問題的方法，就是通過模型的轉換來完成模型的自動變更，而不是對各個抽象層次的模型全部進行修改，但MDA為大部分人所接受還需要些時日。
五、總結
綜上所述，UML建模雖然是軟體建模的有利武器，也要遵循一定的規則來使用，否則就不能很好地發揮它的價值，也會事倍功半。理解UML使用的前提，並認真按照這些方法進行實施，相信會有理想的效果。
