軟件工程與UML圖的關係

軟件工程是軟件開發設計的靈魂，是咱們前進的思想性指導。它使咱們的設計有法可依，有章可循。若是把軟件開發比做建設一棟高樓，那麼軟件工程就是知道咱們不至於在構建一座大樓的時候，最後不知不覺建成了雞窩。而UML圖正是對大樓主體架構的設計。

採用UML來設計軟件系統時，大體能夠分爲三步：

第一步：描述需求

    這時候須要用到的就是用例圖，用例圖的主要讀者即是客戶，從客戶的角度來看咱們所開發的系統。客戶最關心的是系統可以提供的服務，也就是系統如何被使用，是否能完成他們需求。

第二步：根據需求創建系統的靜態模型

    這一步是爲了構造系統的結構，此時用到的是類圖，對象圖，組件圖和部署圖4種圖形，是標準建模語言UML的靜態建模機制。

第三步：描述系統的行爲

    此時創建的模型能夠執行，也能夠表示執行時的時序狀態或交互關係。它包括狀態圖、活動圖、時序圖和協做圖4種圖形，是標準建模語言UML的動態建模機制。

 

把UML應用到軟件開發中的各個階段進行分析：

1)需求分析

    UML的用例圖能夠表示客戶的需求。對外部的角色以及它們所須要的系統功能建模是經過用例建模來完成的。它們之間的關係建模被用於角色和用例。每一個用例都指定了客戶的需求。需求分析不只要對軟件系統進行並且對商業過程也要進行。

2)分析

    考慮要解決的問題是分析階段要作的工做。其描述可用UML的邏輯視圖和動態視圖來進行。系統的靜態結構由類圖進行描述，系統的動態特徵由協做圖序列圖活動圖和狀態圖進行描述。在分析階段，不定義軟件系統的解決方案的細節，只爲問題領域的類建模。

3)設計

    把分析階段的結果擴展成技術解決方案是設計階段主要的工做。提供技術基礎結構——用戶接口。數據庫操做等是採用加入新的類完成的。在這個技術基礎結構中，分析階段的領域問題類被嵌入在其中。構造階段的詳細的規格說明是設計階段的結果。

4)構造

    把設計階段的類轉換成某種面向對象程序設計語言的代碼，這是構造階段的工做。在對UML表述的分析和設計模型進行轉換時，最好不要直接把模型轉化成代碼。在早期階段，模型是理解系統並對系統進行結構化的手段。

5)測試

    單元測試、集成測試、系統測試和接受測試爲系統測試的幾個不一樣級別。不一樣的測試採用不一樣的UML圖做爲工做的基礎。使用類圖和類的規格說明是單元測試，典型地使用組件圖和協做圖的是集成測試，而系統測試實現用例圖來確認系統的行爲符合這些圖中的定義。在系統測試階段，UML模型還能夠做爲測試階段的依據。如單元測試使用類圖和類規格說明；集成測試使用組件圖和協做圖；系統測試用例圖來驗證系統的行爲；驗收測試由用戶進行，以驗證系統測試的結果是否知足在分析階段肯定的需求。