建立UML風格的一般性通則

顧名思義，一般製圖指南就是所有圖的通則，無論是否為UML圖，洋洋灑灑一共有二十六條之多。原著作者將這二十六條指南分為四大類，包括了「易讀」、「簡明」、「命名」和「一般」指南。上一期介紹了13條「易讀」指南，接下來從第14條指南開始談起。

簡明
接下來，我們會談到六條指南，跟簡明圖面內容有關。

指南14 僅秀出你想秀出的內容（Show Only What You Have to Show）
一張圖要是呈現太多繁瑣的細節的話，會變得難以閱讀，且不利於溝通。特別是UML圖，它的重要功能之一是用來溝通團隊成員的想法，倘若搞得太複雜，不僅無助於溝通，反到成為溝通的障礙。

最好可以把握80/20法則，佔百分之二十重要且關鍵性的內容秀在圖面上，其餘百分之八十的細節內容可以透過文字來記載。

指南15 最好採用大家熟知的表示法（Prefer Well-Known Notation over Esoteric Notation）
雖然，UML從1997年取得OMG標準，且於2000年再獲取ISO標準，它可說是個十分成熟且眾所周知的國際雙標準。UML 2共計有十三款圖，每款圖包含了一堆大大小小、常用罕見的圖示與概念。

所以，這一條指南其實也提醒了愛好UML的狂熱分子，或許還是採用80/20法則，使用UML中百分之二十左右常用而且眾所周知的圖示就好，別過於一頭熱地用了一堆罕為人知的圖示。切記，用得好，UML可以是溝通利器；用不好，UML可能反而會成為溝通凶器呢！

指南16 把大圖重新組織成數張小圖（Reorganize Large Diagrams into Several Smaller Ones）
事實上，多張呈現不同複雜程度的小圖，勝過一整張繁簡夾雜的大圖。有一個很好的法則是7±2，也就是說，一張圖面上最多不要超過九個節點，主因是因為一般的平凡人一次可以處理的資訊量有限。

不過，我懷疑現代人適應了複雜，所以應該可以一次處理比7±2更大量的資訊吧？像是現在的手機號碼，就已經高達十位數，或者身分證字號，也是十碼。但是，把一張複雜的圖重新切分成數張小圖，這點我是認同的，這樣確實比較不會因為複雜而遺漏了圖要表達的內容。

指南17 單頁圖最好（Prefer Single-Page Diagrams）
用單頁圖來控制圖面的複雜度，也是一個不錯的方法。限制一個圖不能超過一張紙，如此一來，可以引發製圖的人多加思考，繪製出簡明易懂的圖，避免產出雜亂無章、不知重點為何的大圖。

指南18 優先關注內容，版面其次（Focus on Content First, Appearance Second）

指南19 使用一致且易讀的字型（Apply Consistent, Readable Fonts）
圖的內容才是重點，版面整潔就好，千萬別本末倒置，為了美美的版面浪費寶貴的時間。

至於字型的部份，原著作者認為Courier、Arial和Time系列的字型，比較容易閱讀。同時，別用小於10點（point）的字型，或者大於18點的字型，而且也少用斜體字。

我對字型及大小沒什麼意見，不過斜體字的部分可得多注意。因為類別名稱如果使用斜體字的話，代表它們是不能誕生個體（instance）的抽象類別（abstract class）。再者，操作（operation）名稱如果使用斜體字的話，同樣代表它是個缺乏實作內容的抽象操作（abstract operation）。請看圖1，轉帳是抽象類別，它擁有一個名為「轉帳」的抽象操作，它的子類別（subsclass）—跨行轉帳，才是一個可以誕生個體的具象類別。

命名
下列這四條指南跟命名有關，每條都很容易懂，我就不多做解釋了。

指南20 規定並遵守有效的命名規則（Set and Follow Effective Naming Conventions）

指南21 拿領域術語當名稱（Apply Common Domain Terminology in Names）

指南22 設計階段的圖採用程式語言命名規則（Apply Language Naming Conventions on Design Diagrams）

指南23 跨圖面的元素，其名稱要保持一致（Name Common Elements Consistently Across Diagrams）

一般
其餘不適合歸於上述三類的指南，都放置在此處，只有三條。

指南24 用問號指出未知處（Indicate Unknowns with a Question Mark）
遇到不確定或者未知的地方，可以善用大家都熟知的問號（?）。比方說，不確定一個存戶在同一家銀行倒底可以開設幾個帳戶，所以在帳戶處可以標記問號，如圖2所示。

特別注意的是，「問號」不是UML的標準符號。如果考慮到這一點的話，我們可以改用折角矩形的「註解」（comment）圖示，把問號當做註解文字的一部分放到註解中，同時還可以附加更多的說明文字上去，如圖3所示。

指南25 考慮在圖中使用顏色（Consider Applying Color to Your Diagrams）

指南26 謹慎地使用顏色或不同字型（Apply Color or Different Fonts Sparingly）

Peter Coad在1999年出版的《Java Modeling In Color With UML: Enterprise Components and Process》一書中，就提出了採用粉紅色、粉黃色、粉綠色和粉藍色，這四種顏色來代表四個不同種類的類別。

當然，我們也可以自己制定顏色意涵，像是使用紅色代表還未開發的使用案例、黃色代表正在開發中的使用案例、至於綠色則代表已經開發完成的使用案例，諸如此類的方法來使用顏色。

其實，舉凡字型、線條造型、顏色、色度等等都可以用在圖上，不過一定要謹慎使用，不然可能會造成版面過於花俏，並且同時間破壞了前述提到的多條指南。

介紹完Scott W. Ambler在《UML風格》書中提出的一般製圖指南後，下一期將要介紹大家經常使用的使用案例圖(use case diagram)相關指南，將先從使用案例和參與者這兩類開始。

書籍簡介
	The Elements of UML 2.0 Style  作者：Scott W. Ambler  頁數：200頁  出版社：Cambridge University  Press  出版時間：May 9, 2005.5.9

作者簡介：
邱郁惠
研究OOAD、UML、MDA十餘年，經歷過顧問、專案、教學及寫作工作。離職後創辦UML Blog推廣UML，組織《UML互助會》社群定期舉辦軟體技術講座，出版多本UML專業書籍與電子書。目前擁有OCUP/UML三級認證、PMP認證。

相關連結
沒時間讀 UML/OOAD 書之挑讀筆記 第1回 四色原型（1）
沒時間讀 UML/OOAD 書之挑讀筆記 第2回 四色原型（2）
沒時間讀 UML/OOAD 書之挑讀筆記 第3回 四色原型（3）
沒時間讀 UML/OOAD 書之挑讀筆記 第4回 四色原型（4）
沒時間讀 UML/OOAD 書之挑讀筆記 第5回 四色原型（終）
沒時間讀 UML/OOAD 書之挑讀筆記 第6回 The Elements of UML 2.0 Style（1）