統一專案文件風格的167條秘訣

重讀這本書讓我回憶起一個專案，不過也不能算是重讀這本書，因為在此之前，我其實讀的是第一本2002年版的書，這次則是讀第二本2005年版的書。

岔題了，回頭來說我多年前輔導的UML/OOAD專案，在那個專案中，我帶領了一個六人的系統分析師團隊，其中絕大部分的人都是生手，聽過UML/OOAD但是沒有實際應用在專案中。這個專案後來夭折了，中途砍掉專案的原因當然很多，不過我倒是憶起當時我們大約每兩天就要開一次會議，一邊檢視我們的產出，一邊統一彼此的產出風格。

團隊成員會決定花時間統一產出的風格，並不是毫無緣由的。當時，一方面考量日後會加新人進團隊，有一致的風格會讓新進成員有跡可循，另一方面也考量當時訂下的風格可以成為公司正式的文件，以後公司所有的UML/OOAD專案無論是委外開發或是自行開發產出的文件內容都有一致的風格，不僅可以節省訂定統一風格的探索時間，也可以提高產出的效能和品質。

現在回想起來，如果當年大家都讀過Scott W. Ambler的書的話，應該可以節省不少開會時間吧！

不過，當時出錢的大老闆並不欣賞我們的做法，看團隊成員三天兩頭關在會議室熱烈地開著會，覺得我們在浪費時間，主事者的急功近利、眼光短淺其實是這個專案中途腰斬的最大原因。

統一風格當然是有好處的，不過這就像是建設下水道工程一般，建設平凡老百姓看不到的地方，很難爭取到選票，如同當時雖然團隊成員上下一心且投入極大的熱情，但是產出的東西還是很難說服主事者繼續掏出口袋裡的鈔票！

許多學者專家已經證明過，在專案進行中，貿然加入新的團隊成員，通常會拖慢專案進度，而非理想中的加快專案進度。當然，這個問題要認真討論起來，又要花上一大堆的篇幅了。

但是，統一風格卻是對團隊成員的擴充有幫助的。怎麼說？我想很多人都有中途加入專案的經歷，總是焦頭爛額地想在極短的時間內搞清楚產出的文件、搞清楚現在專案的進度及程序、搞清楚自己該產出什麼樣的文件、搞清楚自己該如何以最快的速度融入團隊！如果你沒有這樣會使人壓力大到胃潰瘍的經驗的話，恭喜你，不過請你現在想像一下這樣的場景。

所以說，倘若之前團隊產出的文件都有統一的風格的話，因為容易解釋與理解，所以方便現有的團隊成員解釋給新進的團隊成員聽，通常是一教就懂。如果UML/OOAD文件雜亂無章、毫無風格的話，新進成員腦袋裡會有一堆的問號，像無頭蒼蠅般纏著現有成員不放，不僅無法盡速投入工作，還會擾亂現有成員的工作進度與心情。

總之，簡單來說，有統一風格的產出文件，能夠讓UML圖更簡明且容易了解，也能夠讓UML圖更行得通且有效能。看了Scott W. Ambler的書後，認真地調整一下專案文件的風格，這可是提升產能的第一步喔，好比許多名人懷孕前喜歡找中醫抓藥調整體質一般，調整調整之後，總是很快就聽到懷孕的好消息了。

章節結構
這是一本200頁的小書，正文大約170頁，保證讀得完！讀小書其實很能建立信心，認真一點讀，總是讀得完。大書就不一定了，從書櫃拿下來就手軟，翻了兩頁就頭昏，電子辭典不離身，每本都讀不完，買了既傷荷包又傷心。

再者，小書也比較有詮釋與想像的空間，有留白的美感，容易引發讀者的思考；大書就不是這樣了，大書作者通常叨叨絮絮，什麼繁瑣細節都說光了，確實描寫的一清二楚，只不過少了可以讓讀者寫下感受的空間吧！這是我個人的體驗啦，所以我喜歡讀小書，當然很多時候不免還是得讀讀既傷荷包又傷眼的大書。

不過，這本書雖然篇幅少，章節可不少，共分為十七章。全書大抵可分為三個部份：前三章包含簡介、一般製圖指南及通用的UML元素指南；第四到十六章共十三章分別說明UML2的十三款圖；最後的第十七章簡單提到了敏捷建模（agile modeling）。

看完章節之後，我預計會挑讀前三章，至於第四到十七章，我只挑讀使用案例圖（use case diagram）、類別圖（class diagram）和循序圖（sequence diagram）這三章，理由很簡單，實務上用到最多的是這三款圖，其餘圖款即便我現在讀了，也會因為實務上用不到而忘記，倒不如等專案有用到時再回頭來讀。

真要開始動手整理這一條一條的指南，倒是讓我猶豫了一會兒。我私下在閱讀原文書時，會針對某些我覺得重要的句子在書頁的空白處隨手寫下簡單的、也恐怕只有自己看得懂的翻譯。現在真想把選讀的指南原文一一列出，也順便配上自己簡單的中譯時，不免猶豫了起來，雖然指南的原文句子都很簡潔，不過還是對自己上不了臺面的英文能力感到退卻。

總之，我還是會將選讀的指南原文一一列出，也嘗試著配上自己肉腳的中譯，一切只希望有助於你的閱讀。但是，也有很多條指南，我沒有按字面中譯，而是參照原文書中的說明，點出它們的重點。此外，指南前面的編號與Scott W. Ambler書上的編號相同，日後你若有興趣找原文書來閱讀的話，方便參照。

一般製圖指南
顧名思義，一般製圖指南就是所有圖的通則，無論是否為UML圖，洋洋灑灑一共有二十六條之多。原著作者將這二十六條指南分為四大類，接下來我就依循這四類區分成四個次小節一一說明。

易讀
以下這十三條指南，都是為了讓我們可以輕易閱讀圖面上的資訊，降低誤判或不易閱讀的可能性。指南1 避免交錯線（Avoid Crossing Lines）

指南2 使用「跳躍」來描繪交錯線（Depict Crossing Lines as a Jump）

上述第一和二條指南的意思是說，避免使用像圖1的交錯線，容易誤判。如果真的無法避免交錯線的話，請採用如圖2的跳躍線來表示。

像是在UML活動圖中，複雜一些的流程，就很可能出現交錯線的情況，如圖3所示。

其實，圖3的情況很常見，我是認為也不會真的嚴重到造成什麼誤判啦，只是圖面上看起來比較醜些。簡單一點的圖，可以調整成圖4的樣子，去掉動線交錯的情況。

可是，我們來想像一下，如果出現如圖5，甚至於更複雜的情況時，很可能會有線段跨越整張活動圖。

為了處理這種圖面上交錯線或橫跨線的表達問題，我們也可以在活動圖中使用「連接器」（connector），如圖6所示。連接器的圖示是成對的小圓，小圓內部標示出連接器的名稱，或者使用簡單的代碼也可以，比方說圖6中的連接器就簡單使用“A”代碼。圖5和圖6兩張圖同義，只不過圖6使用A連接器，把原先跨越整張活動圖的線段切斷了，再透過成對的A連接器標示出連接點。

指南3 避免對角線或曲線（Avoid Diagonal or Curved Lines）
眼睛追隨著直線或橫線比較容易，所以避免使用像圖7的對角線或曲線。很多UML工具都有提供簡單的線條風格，供使用者選擇，比方我慣用的免費工具—StarUML，就可以讓使用者選擇使用直線或是斜線兩種不同的線條風格，如圖8所示。

繪圖時，可以假想圖面上有一個棋盤式的格線，將節點擺放在格線交錯點上，讓線段沿著格線或直或橫，避免使用對角線或曲線，如圖9所示。

指南4 使用一致尺寸的符號（Apply Consistently Sized Symbols）
較大型的節點比較突出，容易吸引觀看者的目光，所以除非你真的就是要突顯某一個節點，否則盡量使用一致尺寸的節點符號較佳。

不過，這一點對UML不太適用，因為UML的節點大小通常取決於節點內部的文字，文字多些，節點就大些。譬如，圖10的使用案例圖，不是因為「查詢餘額」這個使用案例特別重要，所以橢圓圖示特別大，而是因為這個使用案例的名稱比較多字。

還好，使用案例的名稱可以選擇擺在橢圓外的下方處，如圖11所示。我個人就很喜歡把使用案例的名稱擺在外部下方，因為這樣橢圓大小一致，總覺得看起來比較舒服。

不過，UML只有少部分的圖示可以像使用案例這樣將名稱外放，大多數的圖示像是類別圖中的類別（class）、或是活動圖中的動作（action）等等圖示，就沒辦法將內部的字標外放，所以節點尺寸大小不一。指南5 線段連到節點中央（Attach Lines to the Middle of Bubbles）
有很多條指南，原著作者都只是一、兩句話帶過，也沒太多說明，或許他認為這些指南是顯而易見的常識吧！例如，圖12的情況，左圖的線段沒有連接到節點中央，而是連接到角落處，原著作者認為這比較不易閱讀，要像右圖一樣，線段連到節點中央，會比較容易閱讀。

我則認為如果線段上有擺放字標的話，確實線段連到節點中央，會比較容易閱讀，我自己也會這樣調整圖面。不過，如果線段上沒有擺放字標的話，線段拉到節點角落處，倒是無妨，見仁見智啦！

指南6 字標水平放置（Align Labels Horizontally）
由於考慮到西方的書寫習慣，所以水平放置字標會比較好，如圖13中的字標一。雖然，中文的書寫習慣中，文字橫放、直放都無妨，不過由於字標橫放可以同時支援西式與中式的書寫方式，所以還是儘可能統一採用橫式書寫的好。

指南7 符號整齊放置（Arrange Symbols Symmetrically）
其實，以格線為底稿的方式挺好用，盡量把節點放在格線的交錯點上，不要東一個、西一個的亂擺，看起來就整齊多了，如圖14的右圖就比左圖整齊多了。

指南8 別指出「激增」節點（Don't Indicate “Exploding” Bubbles）
請先看圖15，在UML活動圖中，可以在活動圖示的右下方，放置一個像耙子（rake）的標誌，代表這個活動內部其實隱藏了活動細節，因此可以被展開。這個可以被展開的節點，就是指南字句上所謂的「激增」或「爆炸」開來的節點。

指南字面上的意思好像是說「別用」這種還可以被進一步展開來的節點。原著作者沒有多做解釋，在這個指南的最後只說了句“The rake isn't adding any extra value.”—「可以展開」的節點沒有增加額外的價值？是這個意思嗎？我也不太懂。

但是，如果就實務來說，可以隱藏細節的節點，可以讓圖面看起來比較簡潔，我是覺得挺好用的。如果讀者你對這個指南有其他的詮釋或想法，歡迎不吝來信271080@gmail.com，與我分享，先謝了。

指南9 減少節點種類（Minimize the Number of Bubble Types）
圖的主要組成圖示，多半是節點和線段。節點種類最好不要超過六種，比六種少那更好。

指南10 圖面上要留白（Include White Space in Diagrams）

指南11 從左至右、由上至下組織圖示（Organize Diagrams Left to Right, Top to Bottom）

指南12 避免太多緊密的線段（Avoid Many Close Lines）
節點最好可以從左至右、由上至下放置，這同樣是配合西方的橫式書寫方式。至於，節點、線段之間，都不宜緊密放置，彼此之間留些空白，距離放大些，圖面清爽好讀，也會讓眼睛比較不疲倦。

指南13 提供表示法的圖例（Provide a Notation Legend）
你有沒有注意到，去郊外遊玩時，有些大型地圖看板的右下角或左下角會附上簡單的圖示說明，比方說用紅色虛線代表步道之類的，讓觀看者能夠理解。所以，除非可以保證所有人都懂圖面上的圖示，否則最好還是附上簡單的表示法圖例，如圖16所示。

這個系列將依序介紹《UML風格》書中的167條指南，下一期將介紹一般製圖指南的其他3類指南。


作者簡介：
邱郁惠
研究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回 四色原型（終）