為什么選擇具有UML的模型？

關鍵字：UML的模型摘要 

     統一建模語言（Unified Modeling Language，UML）的目的是提供一種不受語言約束和不受平臺約束的建模符號。UML工具是通用的，因為UML是基礎。本文是一種UML基本概念初級讀物，同時提供了對建模目的的理解。這不意味著它是入門指導手冊，但是它提供了許多鏈接，在合適的位置，把我們引導到一些優秀的教材，向我們介紹使用NetBeans IDE中UML功能的步驟。 


    有些工程師在開始編碼之前沒有時間對項目進行建模，有些工程師沒有考慮在編碼之前創建系統的模型。本文就是針對這些工程師們編寫的。本文提供了一些方法和策略，能幫助您更加有效，并能盡可能地節省時間。本文中的信息甚至能讓我們能夠挑戰傳統，“我們沒有時間做好，但是總是有時間重做”。

    簡介 

    在咖啡店，當想到“一段令人激動”的軟件片段時，您激動地抓過一片紙巾，在上面勾畫，使自己的思路更加明晰。這些圖像就像一些雞爪的劃痕，只有您自己才能了解它們的含義。 

    但是它對您來說確實是有意義的：這些雞爪劃痕是一個想法的說明，可能要再花費兩年的時間才能實現。您創建的是一個尚未發展完全的模型。在想象中，方框代表一種元素，而圓圈、三角以及直線則代表另一種元素。在紙巾的背后發明了一種建模語言。如果能夠編譯和運行紙巾，您可能會成功實現您的想法。但這是不可能的。如果再花費兩個月的時間教會計算機每個紙巾對象所代表的含義，如何為每個對象生成源代碼，則編譯紙巾是有可能的。

    經過25年的紙巾建模，創建了幾種非常好的建模語言。世界已經進入統一建模語言（UML）時代。建模器收集所有的紙巾，并統一每種對象的定義以及對象間的關系。特定語言的編程人員使用這種統一建模語言，啟動開發模板為不同的對象創建代碼?，F在，只要在作為UML一部分的紙巾上勾畫對象，就可以對紙巾進行編譯。

    “為什么要建模？”，這是個很好的問題！在本文中，提供了兩種供考慮的答案：將它們想象成UML用例。第一個答案，在“編譯紙巾”部分，重點放在那些在白板或者咖啡店紙巾上勾畫想法的工程師身上。本節的目的是：介紹項目計劃階段建模的優點。該部分多處鏈接的教材將介紹執行建模的詳細情況。

    “為什么選用模型”問題的第二個答案，在“他們在想什么”一節中，重點放在那些曾因處理300000行代碼并對其進行維護和修復錯誤而倍受困擾的工程師。他很高興地看到程序的原作者了解封裝，但是仍然看不到封裝是如何結合在一起的。您也希望見到系統的圖示，了解程序原作者的想法。這是UML工具的一種通用用例。有效地分析代碼，創建一個模型（稱為“逆向工程”），利用該模型可以創建圖示。 

    下表列出了可以在許多地方在線找到的不同類型的UML圖示，為方便起見，將它們歸納于此。單擊縮略圖，查看某特定圖示的樣本。 

    用例圖

    主要由參與者和用例構成。用例圖示幫助捕捉功能需求。這永遠是啟動一個項目的好圖示。

    組件圖

    主要由主要系統組件和它們的關系構成。這意味著是一種高級的復雜系統觀查圖示。無論是在頭腦中、在紙巾上，或者是使用UML工具，已經為每一個已經處理的項目創建了該圖示。

    類圖

    主要由類、接口及其關系組成。類和接口很容易理解，但關系可能有些復雜。在您知道系統中有哪些組件后，接下來自然是繪制組成組件的類圖。

    活動圖

    主要由活動和決定構成。這些圖示基本上是流程圖和數據流圖表，該圖示用來獲取常規的代碼流。

    協作圖

    主要由對象和消息構成。該圖示將重點放在對象之間的通信，類似于程序表。

    部署圖

    主要由服務器等部署元素以及它們的關系構成。這是系統的邏輯剖析圖。

    程序圖

    主要由對象（帶生命線）和調用消息構成。程序圖示描述系統中調用的順序，以及不同對象的創建。

    狀態圖

    主要由狀態、轉換、事件，以及動作構成。很少需要狀態圖示，除非邏輯非常復雜。

編譯“紙巾” 

原文轉自：http://www.anti-gravitydesign.com