我的超人 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 第二篇範例 - 電子化採購系統