什麼是UML？

什麼是UML？

統一建模語言（UML）是由物件管理小組提出的系統開發開放標準圖形符號。該符號基於博奇、倫巴ugh和雅各布森的工作。UML是一種用於表達與設計文件的建模語言，特別適用於面向對象的設計。該語言可應用於整個軟體開發生命週期，從初步設計到非常詳細的設計。UML的定義如下：

  • 統一建模語言（UML）是一種用於軟體系統建模與開發的圖形語言。UML圖表成為開發者討論軟體開發各個階段（包括需求分析、設計與實作）的共同工作產物。這裡的目標是在建立系統之前先對軟體系統進行建模。
  • 引述：「統一建模語言（UML）是一組由單一元模型支援的圖形符號，有助於描述與設計軟體系統，特別是採用物件導向（OO）風格建立的軟體系統。」[馬丁·福勒 – UML精粹] 第1頁。

為什麼使用UML？

隨著軟體架構的規模與複雜性不斷增加，對軟體模型的需求也隨之提升。UML是軟體產業中占主導地位的建模語言。目前它已被物件管理小組——全球最大的軟體聯盟——採用為事實上的標準。很難找到一個超過十名開發者的軟體專案，其在某種程度上不使用UML來規範其架構。

以下是使用UML於我們軟體開發流程中的一些其他事實：

  • 軟體正變得越來越複雜：一個相當古老的Windows XP版本就超過四千萬行程式碼。
  • 單一程式員無法完全掌控如此大量的程式碼。
  • 對於未撰寫該程式碼的開發者而言，程式碼並不容易理解。
  • 我們需要複雜系統的簡化表示方式：建模是處理複雜性的手段。

什麼是模型？

  • 模型是真實事物的抽象，省略了細節。
  • 「所有描述你系統的元素，包括它們彼此之間的連接，共同構成了你的模型。」（Russ與Hamilton，第12頁）。

當我們使用UML在撰寫軟體之前建立系統的模型時，這些模型會以簡化的方式呈現問題。它們提供了解決問題的結構。它們有助於理解應如何處理當前的問題。它們也允許我們嘗試多種解決方案。由於模型是在系統實際開發之前建立的，我們可以理解不同的可能性、問題、選項等。這也導致開發成本降低。由於不會浪費時間在試錯上，產品將能更快完成。模型也有助於管理問題的複雜性，使開發規劃以及機器、程式員、測試人員等資源的分配變得更容易。

UML並非什麼？

  • UML不是一種符號，而是一種語言。
  • UML並非由任何人擁有。任何希望使用它的人皆可自由使用。它並非專有。
  • UML不是流程或方法。
  • UML鼓勵使用物件導向技術與迭代式軟體開發生命週期。
  • UML並不容易。雖然它內容龐大，但並不需要完全掌握。也無需使用或理解其中每一細節。
  • UML並不會耗費太多時間。若正確使用，UML可降低開發成本。同時也帶來易於理解與溝通、提升生產力與改善品質的優勢。
  • UML並無限制。它具有足夠的彈性，可容納特定領域所需的新型詞彙（概念、詞語與術語）、屬性（關於詞語的額外資訊）與語意（語言規則）。

UML的目標

  • 是一種視覺化建模語言，而非視覺化程式語言。儘管某些建模工具具有程式碼產生器，或可從程式碼反向工程出模型。
  • 其目的是創造可支援軟體開發流程的圖表，然而，UML並非軟體開發流程或開發方法。因此，UML是與流程無關的。
  • 用於建立軟體藍圖的標準語言。
  • 一種溝通工具。
  • 一種用於記錄需求、架構、測試、專案規劃等的語言……
  • 它旨在用於軟體系統，但也能用來模擬其他系統。
  • 它旨在支援物件導向的開發流程。
  • 它能捕捉系統的靜態結構與動態行為。
  • UML圖表可協助利害關係人理解、討論並同意需求。
  • UML圖表可協助將複雜的流程抽象化至較易理解的層次。
  • UML圖表有助於促進問題解決。

模型語言提供哪些內容？

  • 模型元素：概念與語義
  • 符號：模型元素的視覺呈現
  • 指引：使用符號中元素的提示與建議

簡要歷史

早在80年代末，當我們開始進行建模時，存在許多不同的方法論。每種方法論都有其獨特的符號系統。問題在於，如果不同的人使用不同的符號，過程中總有人必須進行翻譯。常常一個符號在一種符號系統中代表某種意義，而在另一種系統中卻完全不同。1991年，大家都開始出版書籍。格雷迪·布奇推出了他的第一版，伊瓦·雅各布森也推出了他的著作，而吉姆·倫巴ugh則推出了他的OMT方法論。每本書都有其優點與缺點。OMT在分析方面非常強，但在設計方面較弱。布奇方法論在設計方面較強，但在分析方面較弱。而伊瓦·雅各布森的Objectory在使用者經驗方面表現出色，這點在布奇與OMT方法論當時都未充分考慮。1994年，布奇與雅各布森合併兩種方法，接著1995年倫巴ugh加入。1997年，OMG發布了UML 1.1，並納入了其他人的意見，例如尤登。目前最新的版本是UML v2.x。

發布日期

  • 1995 – UML 0.8
  • 1996 – UML 0.9 – 三位好友
  • 1997 – OMG接手。
  • 1997 – OMG UML 1.1
  • 1998 – OMG UML 1.2
  • 1999 – OMG UML 1.3
  • 2001 – OMG UML 1.4
  • 2003 – OMG UML 1.5
  • 2003 – OMG UML 2.0 – 採用
  • 2005 – OMG UML 2.0 – 最終版
  • 2006 – OMG UML 2.1
  • UML2.1.2（11/04/07）－截至 05/27/08 的最新版本

「三巨頭」推動方法整合的動機

  • 各方法獨立演進的現象
  • 語義與符號的整合，以促進物件導向設計市場的穩定
  • 預期整合將改善早期各別的方法

UML 合作夥伴

  • Rational Software 公司
  • IBM
  • 惠普
  • I-Logix
  • ICON 計算
  • Intellicorp
  • MCI Systemhouse
  • 微軟
  • ObjecTime
  • Oracle
  • Platinum Technology
  • Taskon
  • 德州儀器／史特靈軟體
  • Unisys

整合前不同方法的 UML 符號輸入

UML 代表了 Booch、OMT 與 Objectory 符號的整合，以及多位其他方法學者最佳理念的融合，如下方圖示所示。透過整合這些物件導向方法所使用的符號，統一的模型語言為物件導向分析與設計領域奠定了實際上的標準，其基礎來自廣泛的使用者經驗。

符號的角色

符號在任何模型中扮演著重要角色，『它是將整個流程黏合在一起的膠水』。符號具有三個角色：

  • 它作為溝通非明顯或無法從程式碼本身推斷出決策的語言。
  • 它提供足夠豐富的語義，以捕捉所有重要的戰略與戰術決策。
  • 它提供足夠具體的形式，使人類能夠推理，工具也能操作。

統一的模型語言（UML）提供了一種非常強健的符號，其從分析逐步發展至設計。符號中的某些元素（例如類別、關聯、聚合、繼承）在分析階段引入；其他元素（例如封裝的實作指標與屬性）則在設計階段引入。

UML 的優點

UML 可應用於多樣的應用領域（例如：銀行、金融、互聯網、航太、醫療等）。可與所有主要的物件與組件搭配使用軟體開發方法以及各種實作平台。

  • 您完全清楚自己得到的是什麼
  • 您將擁有較低的開發成本
  • 您的軟體將按照您的預期運作，減少意外情況
  • 在您收到品質不佳的程式碼之前，已做出正確的決策。整體成本更低
  • 我們可以開發出更節省記憶體與處理器資源的系統
  • 系統維護成本將降低，較少需要重新學習
  • 與新開發人員合作將更容易。
  • 與程式設計師及外部承包商的溝通將更有效率。

UML 四加一視圖

UML 包含以下四種系統開發中的視圖（見圖 3）[Eriksson & Penker, 1998；Kruchten, 2000]：

  • 用例視圖：顯示系統功能在外部參與者眼中的呈現；以用例圖描述，偶爾也以活動圖描述。
  • 邏輯視圖：顯示此功能在系統內部如何設計，以系統的靜態結構與動態行為為基礎；以類別與物件圖（靜態模型）以及狀態轉移、序列、合作與活動圖（動態模型）來描述
  • 組件視圖：顯示軟體組件的組織方式；以組件圖描述。
  • 部署視圖：顯示電腦與裝置內執行階段處理節點的實際配置（部署），以及其上運行的組件、程序與物件；以部署圖描述。
  • 流程視圖：顯示系統執行階段的並行特性，例如任務、執行緒、程序與互動，並處理這些執行緒之間的通訊與同步問題；以動態圖（狀態轉移、序列、合作與活動圖）與實作圖（組件與部署圖）來描述。

4+1 architectural view model

每個系統都包含靜態與動態模型。靜態模型以類別與物件圖呈現。然而，它對系統行為的揭露甚少。系統行為以情境（即用例圖）、序列圖、狀態轉移圖與活動圖以圖形方式捕捉。這些構成了系統的動態模型。系統行為是系統內所有物件的總體行為。

如果我們想要將上述五種視圖映射到圖3所示的迭代生命週期階段，我們可以說如下：

  • 物件導向分析（OOA）從使用者的觀點發展使用者需求的模型，對應到用例視圖。
  • 物件導向設計（OOD）在分析中加入細節和設計決策（從開發者的觀點），並對應到邏輯視圖。
  • 最後，實作或物件導向程式設計（OOP）對應到流程、部署和元件視圖。

UML 2 圖表

UML 有幾種不同類型的圖表，可用來從不同觀點描述一個模型。圖表大致可分為兩大類，並進一步細分為子類別：

  • 結構圖 – 結構圖代表系統的靜態方面。這些靜態方面代表圖表中構成主要結構且因此穩定的部分。這些靜態部分由類別、介面、物件、元件和節點表示。
  • 行為圖 – 任何系統都具有靜態和動態兩方面的特徵。因此，當這兩個方面都完全涵蓋時，模型才被視為完整。
    行為圖基本上捕捉系統的動態方面。動態方面可進一步描述為系統中變動或移動的部分。

UML Diagram Types

結構圖

結構圖代表系統的靜態方面。這些靜態方面代表圖表中構成主要結構且因此穩定的部分。
這些靜態部分由類別、介面、物件、元件和節點表示。四種結構圖如下：
  • 類別圖 – 用於描述系統類別與介面的靜態結構及其關係或關聯（包括繼承、聚合與關聯），並包含類別的操作與屬性。呈現方式包括：關聯、繼承、依賴。這是UML中非常常見的圖表。
  • 物件圖 – 是系統在特定時間或情境（快照）下的靜態結構圖，用以說明系統中的關係。
  • 元件圖 – 是用來描述系統內元件的組織結構與依賴關係的圖表。
  • 組合結構圖 – 是用來探討透過通訊連結協作的相互連接實例之執行時期實例的圖表。
  • 套件圖 – 是用來描述系統如何被劃分為邏輯群組，以及這些群組之間可能存在的依賴關係的圖表。
  • 部署圖 – 是用來描述可部署的實體單元（可部署的軟體元件、應用程式、伺服器、應用程式、硬體等）如何構成分散式系統架構的圖表。

行為圖

  • 用例圖 – 用例（軟體功能／服務）與參與者（使用者——無論是人類或系統）角色的圖示。此圖示從使用者的觀點出發。
  • 活動圖 – 透過模擬活動之間的控制流程，來呈現系統的動態特性。用以描述系統（例如：物件／類別）對內部事件的回應方式。（注意：外部事件由狀態圖描述。）在業務流程建模中，可使用此圖來模擬用例或業務規則的邏輯。
  • 狀態圖（又稱狀態圖、狀態機圖） – 用以描述系統（例如：物件／類別）對外部事件的回應方式。（注意：內部事件由活動圖描述。）

互動類型圖 – 模型中組織部分之間的互動。

  • 順序圖 – 用以描述物件之間的互動與訊息傳遞，以及訊息的相對時間順序。
  • 通訊圖（又稱 UML1 的合作圖） – 用以描述系統如何協同完成任務，以及系統之間必須存在的關聯。合作圖是將順序圖的互動內容與類別圖結合後所產生的結果。總而言之，此圖顯示物件之間的訊息傳遞，以及類別之間的基本關聯（關係）。
  • 時間圖 – 用以探討一個或多個物件在特定時間區間內的行為。
  • 互動概觀圖 – 用以描述互動圖（順序圖、通訊圖、時間圖、互動概觀圖）之間的互動與流程控制。

UML 設定檔

UML 設定檔並非真正的圖示，而是一種用以描述 UML 擴展與子集的設定檔。子集以物件約束語言（OCL）描述。擴展則透過定義「樣式」（stereotypes）來建立，樣式是可套用於任何模型元素上的標籤。例如，我們可將一個類別標記為「持久性」，並利用此標籤識別出其執行個體在系統執行期間結束後仍被儲存的類別。非正式地——且此觀點在理念上並不正確——設定檔可指任何擴展與子集，無論是否透過這些機制書寫而成。正式而言，設定檔是描述規則的 OCL 與樣式定義，而在 UML 2 中，這些規則皆以套件（package）形式儲存。

與軟體開發相關的圖示

由於 OOAD 方法論之間的差異與 UML 標準的演進，圖示的名稱與功能可能隨時間而改變。以下是一些可能屬於或不屬於 UML1 或 UML2，但可在 OOAD 方法論中使用的圖示與工作產物範例：

  • 系統環境圖
  • 實體關係圖（與類別圖類似），包含概念性、邏輯性與實體性 ERD
  • 穩健性分析

結論

我們已探討了 UML 的起源與定義，以提供對其本質與所能提供的功能之簡化理解。我們也檢視了如何在下一個開發專案中受益於其使用，並簡要探討了 UML 2 中可用的架構觀點、模型與圖示類型。UML 並非一種流程，而是一種開放標準的視覺化建模符號，用於開發軟體密集型系統。成功專案所需的三大要素為：符號、流程與工具：

 

 

僅符號 – 你可以學習一種符號（例如 UML），但如果你不知道如何使用它（流程)，你可能會失敗。

僅流程 – 你可能有一個很棒的流程，但如果無法傳達流程（符號），你可能會失敗。最後

無工具支援 – 如果無法有效記錄工作成果（工具），你可能會浪費大量時間，最終失敗。

 

自動化 UML 工具

Visual Paradigm是一款自動化工具，可確保你在軟體專案中取得成功，具備：

  1. 簡單的語法編輯，以減少對符號記憶的需求
  2. 支援廣受歡迎且最簡單的敏捷 Scrum 軟體開發流程與工具組
  3. 自動化以簡化任何規模的專案與產品報告及成果物的即時處理

UML 資源

  1. 14 種 UML 圖表類型的完整指南 – Cybermedian
    • 本指南概述了 Visual Paradigm 社群版支援的 14 種 UML 圖表類型。它說明了 UML 圖表如何協助視覺化軟體密集型系統，並描述了每種圖表所提供的功能。本指南也強調了 Visual Paradigm 在支援不同建模需求的各種 UML 圖表方面的多功能性.
  2. 使用最佳的 UML 免費工具（線上與桌面免費軟體）學習 UML 建模 – Cybermedian
    • 本文探討使用 Visual Paradigm 進行 UML 建模的好處，強調其對最新 UML 2.x 標準的支援以及廣泛的圖表類型。同時也提到該工具與流行開發平台的整合能力，以及其在學術界與產業界的廣泛應用.
  3. 以範例學習：UML 狀態機圖 – Cybermedian
    • 此資源專注於 UML 狀態機圖，並推薦 Visual Paradigm 為建立這些圖表的理想工具。它深入探討狀態機圖如何模擬動態系統行為，並強調 Visual Paradigm 與開發工具及平台的整合能力.
  4. UML 圖表：全面指南 – Cybermedian
    • 這份全面指南解釋了 UML 圖表在軟體開發中的重要性，以及 Visual Paradigm 如何支援各種類型的 UML 圖表。內容涵蓋結構圖、行為圖和互動圖，並提供如何使用 Visual Paradigm 建立有效 UML 模型的深入見解.
  5. 免費線上 UML 工具 – Cybermedian
    • 本文介紹 Visual Paradigm Online（VP Online）精簡版，這是一款免費的線上繪圖工具，可用於建立 UML 圖表。文章強調該工具使用簡單、無使用限制，且與各種網路瀏覽器相容，使其成為個人及非商業用途建立 UML 圖表的便捷選擇.
  6. 理解 UML 時序圖：全面指南 – Cybermedian
    • 本指南說明 UML 時序圖及其在即時系統中的重要性。內容探討如何使用 Visual Paradigm 建立這些圖表，著重於系統內時間與持續時間限制的視覺化呈現.
  7. UML 2.5 圖表全面指南 – Cybermedian
    • 本指南概述了 UML 2.5 圖表，並強調 Visual Paradigm 是全面建模的首選工具。內容討論該工具的多功能性、直覺的操作介面，以及強大的程式碼產生能力，使其適用於各產業的專業人士.
  8. UML 類別圖全面指南 – Cybermedian
    • 本指南專注於 UML 類別圖及其在 Visual Paradigm 中的建立方式。內容討論該工具在學術界的廣泛應用，以及在系統與資料庫設計與分析中的使用。指南也提及提供範例與範本，以協助快速啟動 UML 建模.
  9. 使用 Visual Paradigm 建立 UML 套件圖教學 – Cybermedian
    • 本教學逐步示範如何使用 Visual Paradigm 建立 UML 套件圖。說明套件圖在組織大型系統中的重要性，並提供使用 Visual Paradigm 建立這些圖表的詳細步驟指南.
  10. 敏捷軟體開發中視覺化建模的全面指南 – Cybermedian
    • 本指南探討 UML 工具在敏捷軟體開發中的角色，並強調 Visual Paradigm 是廣受歡迎的選擇。說明 Visual Paradigm 如何提供直覺的操作介面，以及驗證、程式碼產生與逆向工程等功能，以提升建模流程.

 

 

 

Leave a Reply