我的超人 Partner Ringle，最近正主導開發 "Sequence Generator" 工具之餘，在我喋喋不休、半強迫的威脅下，利用兩個餘月的時間，把他以前，包括顧問輔導的實際案例、上課的教材與專案的開發等相關文件，作一次整理，集結成書，書名就定為：「UML 協同團隊合作開發」，預計下個月(六月份)出版。

書籍內容約有 4、500 頁以上之多。 書的編排除了不免俗的有 UML 基礎介紹外，Ringle 還為每一張 UML 設計圖 (共 13張)構思個別但又可以整個連貫起來的案例 (Case Study)，並利用 UML 開發工具 (Enterprise Architect) 以 Step by Step 的循序方式實現。 所有的設計圖實做出來後，即完成一個小型的系統。當然，Ringle 是相當重視理論與實務的並重，所以當然包括程式碼的實做 (包括實際連結資料庫、外部系統等)。 絕非是一般的系統分析書籍，只是寫幾個 "Sample Code"，做個樣子、紙上談兵而已。 他甚至考量到初學者對 OOP 語言的接受度，所以選擇以 VB.NET 作為程式碼實現的機制。 (書本還附上光碟片，內含 Model 檔與實做程式碼等，供學員可自行操作練習。)

※※ 說 Ringle 為超人實在不為過，原來已經給出版社，四百餘頁的原稿，因他覺得仍不甚滿意，竟然全部重寫！！ 甚而連示範圖形全部重新再操作過，剪下的貼圖。 短短兩個月的時間，完成了 Ringle 所謂的 Iteration-2 稿件。他可是不眠不休，晚上熬夜鍛鍊出來的合金肝這樣寫成的著作。

再則，整個開發過程中，工具應用的 Know-how，的確很重要。更甚者，協同開發的議題，例如如何利用工具整理共用的需求、設計圖、程式碼等、如何利用版本控管的機制來作共用的管理等，在本書也有詳細的示範解說。 書中是利用 Subversion + EA 就能達成共用管理的機制 (舉一反三，讀者當然可以利用其它工具來實現)。 協同開發環境的建置，僅利用上述的工具，就能達成 CMMI level2~4 的目標水平。

這本結合 UML, 工具, 程式, 以及協同開發的控管等應用，算是偏向實務性質的實用書籍，是 Ringle 第一本初試啼聲的著作。 事實上，Ringle 真正的天賦在於對軟體抽象能力的領悟與觀察力，對於如何捕捉各領域 (Domain)的核心物件，並利用現實的 OOP 機制實現出有彈性的結構，可以說真的是無人能出其右。 這也是未來期許他出版第二本書的主題。

在書籍尚未出版之前，我特別請 Ringle 為自己的著作先作個簡單的新書介紹，同時也順便列出本書的書目大綱。

談寫書談了好幾年，但是始終沒有辦法開始動筆，最主要的原因始終是在於「到底要寫本怎樣的書？」這樣一個問題上打轉。

若是從學習軟體的角度來看，大師們(Grady Booch、Ivar Jacobson、Peter Coad、Martin Fowler、Kent Beck…)早就留下了一個難以跨越的鴻溝，讓後續的作者很難跨越；若是從使用工具的角度來說，坊間那麼多工具書，每每走到天瓏，看到這個月又出了那麼多的工具書，想想好像過個兩、三個月，這些書又全部流到舊書攤論斤賣出，要自己寫這樣一本書，想起來就提不起勁。

後來好在我有一個好Partner，每隔一段時間就要在我身後敦促我，逼使的我無論如何一定要出一本書，或許我的個性就是這樣有點需要人家三催四請，才肯開始好好整理自己的想法，就這樣，一個念頭浮現出來：寫一本十年前的我看到以後一定會想買的書。這就是我寫這本書的唯一一個評斷的標準。
回顧自己這將近二十年在軟體產業的經驗，從對軟體懵懂無知，到好像抓到了些什麼，在這二十多年的學習中，除了看看大師們的天書外，大部分的時間都是在黑暗之中獨自摸索。

軟體大師們雖然創造出非常多具備創意的概念，但說實話，當我把每一本大師的書拿出來，想要輕輕鬆鬆地把書讀完，往往都是一個太奢侈的要求；在十年前，我曾經想要花個一個月，徹底地把UML User Guide中的「Activity Diagram」好好看完，不過說實話，常常看完一小段，周公就跑來找我去下棋了！
並不是說書寫的不好(事實上，這十年來，那個章節我又重複看了好幾遍，每一遍都有不同的體悟)，而是對於想瞭解「UML到底是什麼」的我來說，那樣的寫法有點讓人無法親近。

同樣地，在看Jacobson的「Object Advantage」和看Peter Coad的「Object Models」時，這樣的困擾一直不斷地出現，甚至讓我沮喪到懷疑自己是不是笨蛋，是不是乾脆放棄軟體去開間咖啡廳算了！

不過幸好，我的Partner不斷地鼓勵我，甚至花了很多時間跟我討論軟體，就這樣，在六年前的某一個時間點，在我腦袋中某個開關被打開了，忽然之間，看這些大師的鉅作不再是壓力，反而讓我覺得「嗯，說的真有道理！」

這實在是很奇特的經驗，也讓我開始回想，究竟在十年前，我發生了什麼問題？

我想這和大師並沒有什麼太大的關係，並不是大師的書寫的不好，而是缺少了一個人好好跟我說，究竟這書好在哪裡？
人在學習時，往往會需要從與自己生活經驗有關的部分開始學習起，可是大師的作品，卻往往先跳脫了這一個層次，直接進入到相當高的抽象層次，這樣一來，反而對於初學者有很大的障礙，也因此，在寫一本有關UML的書時，我不願意直接就切入到範例，反而用一個故事來作引導。

在這本書的第一部份，我嘗試用一個完全不同的方式來寫UML的介紹，在介紹每一張UML圖形之前，我會先用一個故事作為引導，透過故事人物的對話，把「為什麼要用這一張UML圖形」突顯出來，然後才開始介紹UML中的相關語法，並且在每一張UML圖形介紹的最後，會再呼應故事的情節，把故事情節中的圖形繪製出來。

這在學習上稱為「增強作用」，就好像學習英文時，你可以利用圖形來幫助記憶，我的方法是，學習UML時，用故事來幫助學習。

究竟什麼時候、什麼狀況下要用什麼UML圖形，這是十年前的我第一個想知道的。
但這樣不夠。

對十年前的我來說，瞭解了UML並不代表在日常的工作中，確實可以使用UMl來幫助我完成一個軟體，也因此，我需要有人明確地告訴我：請照著我的步伐一步一步走，你就可以從無到有產生一個軟體。

因此，本書的第二部分就是利用另一個案例，介紹從企業流程分析、使用者需求分析、系統結構設計到程式碼寫作的一個一氣呵成的開發流程。
對於初學者而言，您可以將第二部分作為自己在實際開發時的範本，也可以從每一個不同階段的細部敘述中，找到各個階段的一些需要遵守的規範。
在這個部分，我同時參考了UP(Unified Process)、Transaction Pattern、MDA、Extreme Programming以及Refactoring；對於筆者實際在進行顧問輔導以及內部產品的開發，我們也是始終按照這個流程來進行開發。

至於本書的第三部分，則是把如何建構一個團隊合作的環境再加入到軟體開發中。
雖然CM(Configuration Management)已經成為軟體開發中的一個重要概念，但說實話，在筆者所接觸的許多客戶以及學生中，對於CM的真實意涵，還是有些模糊。

這也是為什麼我要在談完軟體開發流程後，一定要再加入談軟體團隊間的合作的一個主要因素。
不過為了這本書整體性的統一，在這個部分仍然延續了第二部分的故事，只是故事的主角變成了軟體開發團隊的內部成員而已。
除此之外，在這整本書中，以一套UML工具 – EA貫穿了整個範例的演練，也因此，在本書的第四個部分，分別把EA的基本操作以及其「特異功能」(文件產生、Runtime產生循序圖)列出來，讓讀者可以同時學習如何操作UML工具。

總之，在整本書完成後，我以十年前的我的心情來讀這本書，當然，多少還是有些不滿意，不過針對十年前的我想知道的，我想在這本書中，至少已經說出了超過七成。

僅把這本書，獻給所有對軟體設計、UML以及團隊合作有興趣的人。

書目大綱
第一篇：UML基礎
  第一章：案例設計與說明
    1.1 案例背景說明
    1.2 本篇學習摘要

  第二章：利用UML表達企業流程與系統需求
    2.1 活動圖與企業流程
    2.2 使用案例圖與系統需求

  第三章：利用UML表達系統的內部結構
    3.1 類別圖的靜態結構
    3.2 循序圖的動態結構
    3.3 溝通圖的應用

  第四章：利用UML表達系統的微觀結構
    4.1 物件圖與系統的Snapshot
    4.2 狀態圖的應用
    4.3 時序圖的應用

  第五章：利用UML表達系統的鉅觀結構
    5.1 套件圖的應用時機
    5.2 互動概觀圖
    5.3 複合結構圖

  第六章：利用UML表達系統的實做與部署
    6.1 元件圖
    6.2 部署圖

第二篇：UML與軟體開發實做
  第七章：電子化採購管理系統案例
    7.1 案例背景說明
    7.2 本篇學習摘要

  第八章：企業流程設計與需求
    8.1 捕捉企業流程
    8.2 從企業流程找出使用案例

  第九章：實現使用案例
    9.1 分析類別與使用案例
    9.2 勾勒使用案例的控制物件
    9.3 交易樣式與實體物件
    9.4 使用循序圖描述物件互動

  第十章：領域模式、類別模式與程式碼
   10.1 利用MDA轉換領域模式
   10.2 測試程式碼與程式碼的撰寫

  第十一章：程式的重構
   11.1 程式重構的時機
   11.2 重構的手法
   11.3 結構的重整與設計樣式
   11.4 電子化採購系統重構練習

第三篇：軟體的團隊合作
  第十二章：團隊合作案例情境介紹
   12.1 團隊合作與UML
   12.2 案例情境介紹
   12.3 團隊合作機制的環境建立
   12.4 EA團隊合作機制簡介

  第十三章：建立UML合作的中央集權控管環境
   13.1 案例背景說明
   13.2 開發模型的集中化管理
   13.3 利用EA中央控管開發模型

  第十四章：建構管理與UML
   14.1 案例背景說明
   14.2 軟體建構管理的原理與操作
   14.3 利用EA進行軟體建構管理

  第十五章：團隊安全機制與UML
   15.1 案例背景說明
   15.2 EA的團隊合作機制
   15.3 LAB練習

第四篇：附錄
  第十六章：附錄一 - EA的基本操作
   16.1 EA操作介面簡介
   16.2 新增一個EA的專案

  第十七章：附錄二 - EA的客製化
   17.1 EA文件產生器簡介
   17.2 文件產生器的客製化

  第十八章：附錄三 - EA的進階功能
   18.1 利用EA編寫、編譯及執行程式碼
   18.2 利用EA產生動態循序圖

  第十九章：附錄四 - 本書光碟使用說明
   19.1 第一篇範例 - 信仁醫院住出院系統
   19.2 第二篇範例 - 電子化採購系統