為何要使用 UML？

　　當今對象導向開發的世界中第二條大新聞是什麼？那就是『統一模塑語言』(Unified Modeling Language; UML)其不僅獲得對象管理小組(Object Management Group; OMG)所承認也將取代 BoochCoadJacobsonOdellRumbaughWirfsBrock 等分析及設計方法原先所使用的表示法成為全新唯一的表示法此舉將終結軟件開發人員究竟要使用那些方法這類令人生厭的爭議我們將進入和睦友愛及提升生產力的新時期(就算那些舊架構的方法已經相當成熟了卻從未達到這樣的水平 對此也只能一笑置之)
　　
　　假如你是 BS (before standardization 標准化之前)方法之一的方法迷(keen user)你鑽研(bite the bullet)轉換至 UML 時不免暗地抱怨沒有看到你所喜愛方法中的 x 特性而你所不喜歡的 y 及 z 特性卻充塞其中但是你是否真的冷靜下來思考像 UML 這樣的塑模表示法為何是有用的嗎？
　　
　　詢問一位方法論大師(methodologist 在我們業界指的是創造方法論的人)有關這方面的看法時會招致一頓軟件質量如何如何的嚴厲訓斥方法論大師會談論到我們的產業遭受到怎樣的危機缺乏軟件質量所遭致的問題良好設計的重要性 等等這樣也好(雖然我想軟件產業在最近幾十年已經做得很好了)但是如何確實地實施 UML 才是有幫助的？詢問 CASE 工具廠商時你將會上一堂課是有關改善質量文件自動化及程序代碼產生器的生產值然而我們大家都知道CASE 工具廠商接下來的動作會是什麼
　　
　　假如你是一位開發人員質疑所有方法的本質不過是另類的管理流行時尚你一想起會產生毫無用處的紙張就感到戰栗然後 UML 恰好佯裝成關懷這類問題而成為另一種表示法(notation)至少這是目前僅有的可是你也了解下次你必須更改系統時在你必須修護程序代碼往後的幾個版本這些 UML 圖還是有所幫助的
　　
　　我早在軟件職業生涯中學會方法既使我具有工程的背景然而這些方法似乎成為一種天然的知識領域這般的吸引著我大多數的工程科系采用繪圖來描述如何建構事物同時相當用心的 根據這份設計圖來做這些事物我明白方法論的圖型也具相同功效有段時間我學習類似的方式(the lie of that analogy)然而我仍舊發現這些方法是有用的盡管我對於某些開發人員不喜歡這些方法深表同情
　　
　　接著下來我要說明為何我發現 UML 是有用的首先我快速的提醒各位 UML 『是一種塑模語言而非方法(或方法論)』同時以此作為下面論述的開始UML 訂定了一些圖型以及這些圖型的意涵而方法則更進一步描述開發軟件的步驟什麼樣的圖型在什麼順序中產生由誰來做那些工作 等支持 UML 的方法是各自獨立的過了明年或明後年我們將看到不同人士提供各種運用 UML 表示法的方法然而你不須要使用方法才會利用 UML在這篇文章裡我不去假定任何特定的開發方法
　　
　　因此如果我們除去所有方法的裝飾除了少數你能夠繪制的圖型樣式外被留下來的還有什麼？這個問題從「UML 有什麼用途？」變成了「這些圖型有什麼用？」
　　
　　答案可以歸結成一詞『溝通』(譯注英文是一字communication)這是一個重要的詞匯軟件如此地迷惘 以致於難以開發的原因主要就在於溝通我們知道假若我們只要在周末偷閒一下而程序代碼就此消失事情將是如何簡單困難的症結在於我們必須與多位開發人員溝通UML 之所以重要就是因為它有助於軟件開發人員之間的溝通我們必須在某種程度上使用它以協助溝通而非阻礙溝通
　　
　　
　　
　　圖解 UML 圖型用以展示 Java AWT Container 類別的 Container
　　
　　
　　圖解 說明了 UML 如何協助溝通的范例此圖型一開始是用來描述 Java 抽象窗口工具集(Javas Abstract Windowing Toolkit; AWT)的容器類別(Container class)透過閱讀這個圖型我能夠了解一大堆東西我能夠了解容器(Container)是組件(Component)的子型態(subtype)可以把組件制作成可視的(visible)或主動的(active)以及其它類型的組件這些組件包括卷標(labels)按鈕(buttons)以及其它種種我可以詢問一個容器有關它所包容的組件但是並非所有的組件都需要容器容器(Containers)包含組件(Components)容器(Containers)也可能包含其它容器(Containers)同時容器擁有一個布置管理者(layout manager)容器就如同組件般屬於抽象類別(abstract class)其子型態包含畫板(panels)及窗口(windows)窗口能夠顯示及處置窗口本身窗口也有框架(frame)及對話框(dialog)兩種子類別(subclasses)兩者皆有標題列同時能夠設定其大小是否可以變更(resize)雖然窗口的兩種子類別都可以做上述的事然而這些行為並非窗口本身的一部分可以將對話框(Dialogs)標示為模塊式(modal)然而框架(frames)卻不可以
　　
　　你可能喜歡這個圖型也有可能喜歡我前面那段論述這端賴你是否熟悉 UML以及你是喜歡可視化的敘述或者喜歡敘事式的陳述關於此我喜歡可視化然而有些人喜歡文字方式即使他們也懂得這些圖型你可以給他們文字描述或者(或許會更好)給他們一段程序代碼選集(如列表 所示)那一個是你願意選擇的？那一個是你的同僚所想要的？這些問題對於 UML 及類似語言的角色是至關緊要的我發現有些人喜歡文字的方式有些人喜歡圖型的方式還有某些人在某些事物上選擇圖型同時在某些事物上選擇文字最後圖型僅有在可以強化溝通的情況下才值得去做
　　
　　除了注意那些圖型展示甚麼之外你也該注意到那些圖型不能夠展示甚麼類別整體描述有較圖解 或列表 所標示的接口更大我未曾提到布置管理者(Layout Manager)是一個接口或者那個組件實作若干接口許多人可能會因此而責難圖解 不夠完整它是不完整但不完整是一種缺點嗎？在圖型裡我決定去描寫那些類別的特性並且慎重的決定那些不該顯示出來事實上我所顯示出來的某些特性就是我所要突顯出來的特性
　　
　　選擇所要強調的信息是溝通很重要的一環在類別的任一群體中為了取得這些類別最初的理解去了解某些觀點(aspects)是相當重要的假如你展示每件事你會失去引出那些特點同時你的讀者會對於首要了解的事物以及往後才須專注的細枝末節毫無概念當我使用類別圖我是為了最初的理解而利用它們以便於了解我想表達這些類別的關鍵觀點我知道讀者經常是從 Javadoc 檔案中去取得這些接口完整的敘述
　　
　　我鼓勵你以這種有選擇性的方式來使用類別圖這樣做不僅可以促進圖型溝通的價值也可以使它們容易維護(keep up to date)你無須為了類別每一個小改變就變更圖型既然難以維護這些各式各樣的圖型為重大的問題之一這種做法就有相當大的好處
　　
　　就像鼓勵有選擇性一般我也鼓勵人們去強調接口(interface)而非實作我在組件上顯示一個 isEnabled 的屬性(attribute)這不是說組件類別有一個數據域位(field)稱為 isEnabled (我真的沒有注意到因為它無關緊要)其所表達的意思是你可以假設這個類別有這樣的屬性然而你要從類別外部透過適當的操作(operations)來存取內部的數據理論下可能有這些操作的命名約定(在 Java 鏈接庫的這些日子命名的方式為 isBooleanAttribute 及 setBooleanAttribute)我不顯示類別的操作因為我發現屬性的表示方式 更能適當地傳達程序代碼的意圖屬性也可延伸至結合關系(associations)我不知道容器(Container)及組件(Component)之間存在那些數據結構這些操作會使人聯想到這些結合關系
　　
　　許多人士以實作的觀點來繪制類別圖即是將屬性(attributes)及結合關系(associations)反映至數據結構中這些數據結構之所以有用乃在於你期望表達甚麼無論如何通常 這些接口那些是最重要的你該決定甚麼是你所根據的觀點甚麼是你想要表達的
　　
　　當討論到某一件設計還有你可能如何去變更它時我發現圖型也是有用的 假如你擁有一群設計師正致力於一項設計嘗試在白板上繪制設計的草圖描繪幾個替代方案我發現我們在探討有關事物時可視化是很有效的辦法(CRC 卡是另外一種有效的技術)
　　
　　這項技術有一點特別重要的變化是發生在當我正與領域專家合作嘗試去了解我們所要建構的系統時在這種情況下我使用最少的表示法並且聚精會神於領域專家腦中所描述的概念而不是思考任何特定的軟件情況我發現教導這種概念上的塑模風格對於沒有軟件背景的人士是相當容易的 接下來使用這些圖型 我們能夠共同地發展出一套定義正確的字匯用於討論領域相關事項同時能夠提出對於討論及目的軟件皆有益的抽象概念當我從事於如保健及金融貿易這類復雜的領域時這對我而言是一大恩惠
　　
　　統一規格在此是有用的乃因其可加強溝通的質量當他們使用各種圖型式樣(diagramming styles)與人溝通時這種思想交流是困難的擁有一個單一的標准我們可以確認假使人們懂得少許圖型式樣的話他們一定懂得標准化的圖型但是不要走過頭了UML 包含許多表示法並且沒有規定說你全部都必須用到嘗試著運用這些表示法中適當地少量的部分不要使用進階的概念除非它們確有必要雖然你應該盡你所能去忠於標准然我必須承認如果需要的話我並不害怕去篡改表示法我不這樣做的原因通常是每次篡改表示法就需要對此作說明同時不是讀者所熟悉的但是若這麼做能加強溝通我就去做它
　　
　　所以如果你是 UML 的新手根據你所需傳達的想法去嘗試使用它實驗可以了解那些可以做以及那些不可以做 透過實作去學習表示法並且逐步地學習
From:http://tw.wingwit.com/Article/program/Java/gj/201311/27322.html