軟件工程是軟件開發設計的靈魂，是我們前進的思想性指導。它使我們的設計有法可依，有章可循。如果把軟件開發比作建設一棟高樓，那么軟件工程就是知道我們不至於在構建一座大樓的時候，最后不知不覺建成了雞窩。而UML圖正是對大樓主體架構的設計。
采用UML來設計軟件系統時，大致可以分為三步：
第一步：描述需求
這時候需要用到的就是用例圖，用例圖的主要讀者便是客戶，從客戶的角度來看我們所開發的系統。客戶最關心的是系統能夠提供的服務，也就是系統如何被使用，是否能完成他們需求。
第二步：根據需求建立系統的靜態模型
這一步是為了構造系統的結構，此時用到的是類圖，對象圖，組件圖和部署圖4種圖形，是標准建模語言UML的靜態建模機制。
第三步：描述系統的行為
此時建立的模型可以執行，也可以表示執行時的時序狀態或交互關系。它包括狀態圖、活動圖、時序圖和協作圖4種圖形，是標准建模語言UML的動態建模機制。
把UML應用到軟件開發中的各個階段進行分析：
1)需求分析
UML的用例圖可以表示客戶的需求。對外部的角色以及它們所需要的系統功能建模是通過用例建模來完成的。它們之間的關系建模被用於角色和用例。每個用例都指定了客戶的需求。需求分析不僅要對軟件系統進行而且對商業過程也要進行。
2)分析
考慮要解決的問題是分析階段要做的工作。其描述可用UML的邏輯視圖和動態視圖來進行。系統的靜態結構由類圖進行描述，系統的動態特征由協作圖序列圖活動圖和狀態圖進行描述。在分析階段，不定義軟件系統的解決方案的細節，只為問題領域的類建模。
3)設計
把分析階段的結果擴展成技術解決方案是設計階段主要的工作。提供技術基礎結構——用戶接口。數據庫操作等是采用加入新的類完成的。在這個技術基礎結構中，分析階段的領域問題類被嵌入在其中。構造階段的詳細的規格說明是設計階段的結果。
4)構造
把設計階段的類轉換成某種面向對象程序設計語言的代碼，這是構造階段的工作。在對UML表述的分析和設計模型進行轉換時，最好不要直接把模型轉化成代碼。在早期階段，模型是理解系統並對系統進行結構化的手段。
5)測試
單元測試、集成測試、系統測試和接受測試為系統測試的幾個不同級別。不同的測試采用不同的UML圖作為工作的基礎。使用類圖和類的規格說明是單元測試，典型地使用組件圖和協作圖的是集成測試，而系統測試實現用例圖來確認系統的行為符合這些圖中的定義。在系統測試階段，UML模型還可以作為測試階段的依據。如單元測試使用類圖和類規格說明；集成測試使用組件圖和協作圖；系統測試用例圖來驗證系統的行為；驗收測試由用戶進行，以驗證系統測試的結果是否滿足在分析階段確定的需求。