我在講課時總是喜歡採用反問的方式，藉以引導學員可以思考我所提問問題背後的涵意。大部分學員總是會有些怕怕，也比較不敢表達出自己的想法，但這位女孩子卻是可以回答出令人相當滿意的答案，讓我相當的佩服；更為訝異的是，在下課時與她閒聊，才知道她還只是撰寫大型系統的程序性古典語言，也沒有寫過 Java or .NET 等 OOP 語言。但是，我可是真的覺得，她對物件導向的設計哲理，相當具有領悟力，也很肯去反思，俱足軟性思考的頭腦。

對於這樣聰慧、具 Smart 特質、又肯主動學習的學員，除了讓我印象深刻外，我更是願意就我所能，引導與分享對於軟體設計領域上的觀念與學習技巧。

就在想說，年後我們團隊若有一些研討活動 (如讀書會、研討會)等，準備邀請該位學員來參與。沒想到，就在除夕春節前，這位學員還主動寄了一封新年賀卡給我們。除了新年賀節問候外，也說出了她對這次上 UML 課程的收獲與心得，真的很感心~

更特別的是，附檔的新年賀卡是她利用 PowerPoint 設計的。內容竟然是把兩天課程所介紹 UML 13張設計圖，它們之間的關聯、特質與應用時機等，給全串在同一張圖內；還畫了虎年到來、新年迎春饒富過年氣氛的插圖。

哇！！ 這麼別出心裁、這麼有創意的新年賀卡，又是如此的用心製作 (必然要耗費很多時間)，我收到這樣的賀卡真的是相當開心，也相當感動。更是覺得，這麼棒的作品，要不分享出來給眾讀者們欣賞，那真是太可惜了。所以，我還特別寫了信徵求該位學員的同意後才特別公開。

對啦，她的名字叫 Sharon，這樣直接稱呼也比較方便勒。另外這裡同時也公開她的網誌應該沒有問題吧？ 看看她寫的文章，文句優雅頗具知性，會讓人以為她是一位柔弱感性的少女呢；但是，再瀏覽她整理的網誌相簿，呼，Sharon 可還是一位熱愛潛水的陽光健康女孩呢。

　o http://blog.yam.com/sharontaiwan
　o http://sharonwang.myweb.hinet.net/

延伸閱讀：

• 我總是記不起別人的名字與容貌，我只記得別人提問軟件的問題~
• 透過 Google 找 Coding How-to 的好範例
• DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
• 小朋友的目標設定範例—「暑假的生活計畫」
• {心智圖} 生命目標—財務

＊＊ 由於文化教室已滿，故地點改為 中國生產力中心，台北市承德路二段81號B1(首府經貿大樓)。

http://www.cpc.tw/Train/Place.aspx

各位好：

線上報名與詳細課程資訊請至：

http://www.hsdc.com.tw/course/unit_course_20100130_31

　o 日期：2010/01/30,31 (星期六,日) AM 9:１０ ~ PM 1７:00 (共 1３ 小時)
　o 地點：中國生產力中心，台北市承德路二段81號B1(首府經貿大樓)。
　　http://www.cpc.tw/Train/Place.aspx
　o 費用：NT$4,200, 含稅。舊生或三人同行: NT$3,800。
　o 附贈完整系統分析文件範本 (Word 格式)與可執行的 C# 程式原始碼。
　o 前 10 名報名者，免費贈送 UML 新書：UML 協同合作與管理(已有可抵優惠 NT$400)。
　　http://www.kenming.idv.tw/bk_uml-collaboration-process-and-management
　o 同課程可保留再旁聽乙次的權利 (報名時註明舊生旁聽即可)。
　o 下午均附有免費從外特別特購精緻的咖啡與點心。

§課程說明 --------------------------------------------------------------------

2010 年一月，HSDc. 所選擇的第一個軟體設計培訓課程為「UML 2.0 觀念引導與實務操作入門」。

焦點著重在講師會藉由 UML 工具的實際操作與引導，繪製各個類型的軟體設計圖，從做中學的過程中，瞭解到這些 UML 設計圖背後的設計意涵。

雖然是短短的兩天課程，但講師們絕對會擷取出 UML 的精要(essential)部分，將多年來豐富的輔導與教學經驗，表達於其內。 絕對可以讓學員們學習與瞭解到，UML 這個統一模式語言的每一張設計圖的基本語法認識，以及基礎軟體設計的思維。

雖然這個是我們已舉辦多年的實務性課程，但是對於課程內容，我們每一次總是接受學員們的建議，以及我們團隊課程結束之後的討論，會再重新作過規劃，讓課程更流暢、更為實用，對學員們當然在工作上更有實質的幫助。

所以，除了 UML Overview 介紹與實務操作外，我們在最後一堂課，會利用一個小而美的案例展示，以提供完整的系統分析 Model，與利用 C# 實作的可執行程式碼，甚而包括了完整的系統分析文件(Word 格式)。這可是相當之實用的範本，讓學員可以參考並實際應用在工作、小型規模的專案開發上。

上課學員除了收到本顧問團隊所親自撰寫的教材外，還可以拿到一片自動安裝的光碟，內含了教材電子文檔(PDF)、UML 範例檔(EA 格式)、UML2 教學錄影檔(Flash)、歷屆研討會簡報資料、EA 7.5 UML 工具(Trial)。

上課過程中，更是歡迎學員自行帶平日工作所碰過的案例問題與疑問，講師群均非常樂意協助解決(不怕被考倒，只怕不問)，亦可以當成課堂上的討論案例。

對了，每一天的課程，我們均有免費提供下午茶點，包括小蜜蜂咖啡、茶飲、美味的吊鐘燒與餅乾甜點等。品味咖啡的同時，學習軟體設計思維，那會是一件令人相當愉悅的快樂學習之旅。

§報名資訊 ----------------------------------------------------------------------
o準備教材：
　o 由授課講師提供講義，包括內容、案例分析與 UML 13 種圖範例(包括 Flash 影音檔案)。
　o 學員可攜帶相關 UML 參考書籍，並對於書中內容有問題者，可以直接提問。

o使用工具： EA(Enterprise Architect) 7.5(Trial) UML Tool。

o授課講師：
　o 賴信仁(Ringle Lai) ,王克明(Kenming Wang)
　o 擅長以非常淺顯易懂的比喻及說明，將複雜的系統抽絲剝繭，重新釐清脈絡，讓學員一清二楚，並善於引導學員具備設計應有的反思能力。

o上課時間：
　o 2010/01/30,31 (星期六,日) AM 9:１０ ~ PM 1７:00 (共 1３ 小時)
　o 請注意，本次課程特別提早至 9:10 開始上課，並延長至 17:00 下課。

o上課地點與上課人數：
　o 文化大學教育推廣部城中分校，台北市延平南路127號。
　　http://future.sce.pccu.edu.tw/service/service01_05.asp
　o 報名人數滿 10 人即開班(同時保留 5 名學員重新選修該課程)。
　o 開課前兩日會以電子郵件聯絡與通知學員。

o適合學員：
　o 系統分析/設計(SA/SD), PM, Programmer 等在職軟體開發者或在學學生。
　o 想實際學會如何利用 UML 工具來畫 UML 2.0 十三種圖。
　o 看了很多 UML 書籍，仍然無法在正確的時機畫出正確的 UML 圖。

o備註：
　o 教室設備包括白板與投影機，由講師親自說明與操作示範。(學員可攜帶錄音筆)
　o 學員最好能攜帶 Notebook，可以於課程中實際操作與練習。 。
　o 為確保報名足額人數，煩請先以 ATM 轉帳預約費用($1000，當然也可一次繳清)。
　　並請於報名表備註欄位內，註明您的轉帳帳號末 5 碼與轉帳金額。
　　(若實在不及轉帳者，仍可現場報名，但請在報名表內註明現場繳費)。
　o ATM 轉帳帳號： 新光銀行 (103)　帳號： 0772-50-100979-9

§課程大綱 ----------------------------------------------------------------------
※ 基礎觀念引導—認識 UML
　o 使用 UML 的基本思維
　o 為何是利用 UML 來溝通
　o UML 塑模的對象
　o UML 設計圖的分類說明

※ 企業流程與系統需求
　o 利用活動圖(Activity Diagram)表達企業流程
　　－ Activity, Control flow 的關聯。
　　－ 決策(Desision), 並行活動的表達。
　o 利用使用案例(Use Case)圖表達系統功能
　　－ 系統範圍, 參與者, 使用案例 表達系統架構。
　　－《include》and《extend》擴充意涵表達。
　　－ 使用案例陳述(Description)範本。
　o 操作展示與引導練習
　　－ EA(Enterprise Architect) UML 開發工具安裝與基本操作說明。
　　－ 利用 EA 繪製活動圖與使用案例圖。

※ 表達系統內部結構的兩位主角
　o 利用類別(Class)圖表達領域概念與企業物件。
　　－ 類別的特徵：屬性與行為。
　　－ 三種類別之間的關係：結合, 整體/局部, 一般化/特殊化。
　o 利用循序(Sequence)圖表達物件動態期間的互動關係。
　　－ 表達出主要參與的主角(Object)。
　　－ 表達出物件之間的訊息傳遞。
　o 操作展示與引導練習
　　－ 利用 EA 繪製類別圖與循序圖。

※ 其它類的設計圖
　o 系統的微觀設計
　　－ 溝通(Communication)圖, 物件(Object)圖, 元件(Component)圖。
　　－ 狀態機(Statechart)圖, 時序(Timing)圖。
　o 系統的鉅觀設計
　　－ 互動概觀(Interaction Overview)圖, 合成結構(Composite Structure)圖。
　o 系統的實作與部署
　　－ 套件(Package)圖, 部署(Deployment)圖。
　o 操作展示與引導練習
　　－ 利用 EA 繪製上述的設計圖。

※ 案例展示與系統分析範本－從需求分析,結構設計至程式碼實作
　　－ 使用案例, 類別圖, 循序圖 設計產出之間的橋接。
　　－ 利用 EA 正向工程產出 C# 程式碼。
　　－ 記錄測試案例與撰寫測試程式碼。
　　－ ＊＊ 利用 EA 快速產出完整的系統分析文件(可作為開發綱要範本) ＊＊
　　－ 完整附錄可執行的程式原始碼與設計模型的 Model 檔。
--------------------------------------------------------------------------------

＊＊【研討會 01/23】20１０ 軟體設計鮮思維—程式碼與循序圖的關係與產品開發介紹

http://www.javaworld.com.tw/jute/post/view?bid=14&id=271642&sty=1&tpg=1&age=0

High-quality Software Design Consultant.
TEL: 02-27227179
Email: service@hsdc.com.tw
軟體設計論壇: http://www.hsdc.com.tw

延伸閱讀：

• 報名系統分析課程(06/27)免費送 Linux 軟體開發平台 DVD 光碟
• 【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 C#.NET (11/01, ５４ Hrs)
• 【公佈】五,六月份的軟體設計課程—台中場UML與非正規學分班系統分析課程
• 【軟體設計單元課程(兩天)】UML2.0 實務操作與應用入門 (2006/06/24~25)
• 【軟體設計單元課程(一天)】Design Patterns 一日遊—把軟體做軟(2006/05/20)

話雖如此，可是我倒是可以很直覺地、也不需要特別記住－只要是別人曾經就軟體的相關議題問過或與我討論過，我幾乎是不會忘掉那個主題。 這就如同我一些朋友、尤其是女孩子，總是很清楚記得哪一天見面時所穿的服飾打扮 (但我卻永遠不會記得別人穿甚麼衣服)。

就在今日晚上，有位網友 Msn Call 我，打的是簡體字，看來是大陸來的網友。 除了向我問候新年快樂外，同時也報上他的大名，還順口問我記不記得。 唉，我一向很直，也老實回應說我真的完全沒有印象。

事實上，我的 Msn 名錄，好像超過 一、兩百個人了吧。 但經常聯絡的，也才十來個而已，而其他人則都是透過網路自動給我加進來的。

大部分人當然是來問我問題的。 而一般而言，很少很少，我並不會主動 Call 別人的。 只是，誰來 Call 我、問我問題，即使對方報了姓名，聊一聊回應問題之後，我真的就忘了對方的姓名(或別名)。

不過，那位網友就寫說，他曾經就 "利用 UML 表達自動化控制系統設計" 這篇碩士論文請教我。 哈，我馬上就記得一清二楚了！^^ 大概已經有 2 年了吧，當時該網友還特別傳檔整篇給我他寫的論文 (Word 格式)。 當下我看了約近 10 分鐘就看完，還著實批判了不少。 !^^

當時會很直率地批判的原因是，我一直以為碩士論文應該很強調個人對於其主題立論的想法(或依據論點)。 但是，我發現到，透過其 UML 設計圖，我完全感受不到著者本人的想法。

透過 UML 可以瞭解設計者在想甚麼？ 是的，最起碼我倒是有這個能耐，而且還是八九不離十、很容易可以瞭解設計者背後的假設論點。 請注意！！ UML 是表達軟件設計(語法本身完全不重要)，透過其表達，就可以知道 Developer 的假設與想法。

呵，只要一談及軟件相關設計議題，我的確很容易提起勁。一聊下去，我總是精神亢奮、一點都不會覺得沉悶與疲倦。

既然我連兩年前網路 Msn 討論的軟件議題都能記得如此一清二楚，所以記憶力應該不算差才對啊！！ 嗯嗯，我突然領悟到，記不起別人長甚麼樣、穿甚麼衣服、哪時候一起吃甚麼飯 ‧‧‧等等的話，應該是不用心、而不是記憶力不好啦。

延伸閱讀：

• 透過 Google 找 Coding How-to 的好範例
• 以身為「工程師/程式設計師」為榮
• 通過 OMG UML OCUP Fundamental 認證考試
• 軟體塑模(Modeling) 是一件非常單純的事
• 「UML 有什麼好處」？

有興趣的讀者們也可以線上報名，名額有限(限 100人)。 (據我截至現在看到對岸的報名人數已達 50餘人)

時間：北京時間2009年10月28日（週三）晚上19:00-21:00

地點：此次講座通過網絡遠程音頻進行。具體操作方法見報名後的具體通知。
人數：100人（人數超過以報名順序為準排列）。
費用：免費
演講人：
賴信仁。信仁軟體設計負責人。 精通物件導向觀念、UML、程式設計、系統設計實務及資料倉儲等。 擔任多家公司（台灣電通、中科院、農學社、台積電TSMC、統一企業）的軟體建置顧問。 參與多項系統開發專案（CMO eRMA、TSMC eMaterial、秀波電子ERP、台灣電通Workflow、台灣電通財務系統等）。 曾任系統分析師及專業講師；並於台積電及奇美電子擔任高級軟件設計師，負責軟體技術策略的擬定以及開發新軟件技術。 文化大學進修推廣部軟體設計與實務應用班－UML 2.0與Java J2EE講師。

幻燈下載：
稍後提供。

報名：
請發送郵件到seminar@umlchina.com預訂座位，務必填寫以下信息。每次講座的報名是獨立的。即使您在以前的講座報過名，還是需要再報名。

所在單位名稱：
姓名：
部門/職務：
郵編/通訊地址：
電話：
手機：
傳真：
E-mail：
MSN/QQ：
我可能問專家的問題：

延伸閱讀：

• Ringle 即將出版的新書─「UML 協同團隊合作開發」
• 【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 C#.NET (11/01, ５４ Hrs)
• 【公佈】五,六月份的軟體設計課程—台中場UML與非正規學分班系統分析課程
• 【軟體設計單元課程(兩天)】UML2.0 實務操作與應用入門 (2006/06/24~25)
• 【軟體設計單元課程(一天)】Design Patterns 一日遊—把軟體做軟(2006/05/20)

我會提供的考題，必然是針對應徵人員 "自我思考推理" 的能力驗證，答案的正確性完全不重要，重要的是你為什麼是這樣表達設計的，能否自圓其說。 具有獨立思考能力的設計師，這才是人才！

所以，我會提供一個如這樣的考題：

Google 書籤 (bookmark)是利用 標籤 (Tag)來作分類的。 一個書籤可以被 "標記" 為一到多個標籤，相對來說，一個標籤可以有一到多個書籤。 另外，標籤是不會含有子標籤 (Sub-Tag) 的。

如果我要改良 Google 書籤的設計，希望能再加上 "資料夾 (folder)" 的管理觀念，也就是說書籤必然會 "放" 在某一個資料夾目錄內 (也只能是唯一)，而某一個資料夾可以擁有一到多個書籤，同時資料夾也能再包含子資料夾 (Sub-folder)。

同樣類似的應用，可以延伸至部落格 (Blog)的本文 (Content)與標籤、目錄 (category)的結構設計。

請你利用 UML 類別圖，來表達出關於 書籤、標籤與資料夾的結構關係，並簡單說明你的設計想法。

上述的考題是一個 "需求陳述"，應該算是蠻普遍的一般應用常識了。 不過若還是不懂上述的敘述，那麼也可以再佐以範例，來解釋什麼是 書籤、標籤與資料夾的概念。

老實說，我是以為，這類的結構設計應該算是很基礎的了，事實上，答案也比想像得意外簡單。 但是，我也問過好幾個號稱對所謂 設計樣式 很熟悉的資深技術人員，最直接給我的答案就是說： 這不就是 "複合結構 (composite structure)" 樣式的應用嗎？ 不管你說什麼，反正先把設計圖畫出來再說吧。 結果呢，也真的如我所料，表達不出所以然，真的就只是在背書而已。 最大的盲點，就是把 標籤 (Tag) 與 資料夾 (folder) 給關聯在一起，而其實這兩個是一點關係都沒有的；甚至有些還執著在因為 標籤與書籤 的多對多關係，所以又拉出了一個所謂的 "關聯類別 (Association Class)"，卻又說不所以然，越弄越複雜。 因為既然是表達想法，所以類別圖自然是表達 概念 (concept)與概念之間 的關係，而至於那個多對多的關聯類別，是在更細節性的規格設計實做階段再來討論即可，太早論及，反而模糊了要突顯的概念。

表達這類結構性的設計圖，要先找出核心的類別是什麼。 在本例中， "書籤 (bookmark)" 即為本文主體，是最根本的核心類別。 再來當能分別出 標籤 與 資料夾 並沒有關連，而是各自與 書籤 建立關係，那麼，這個設計的表達就可以說對了一大半以上了。 參考的 UML 類別設計如下圖：

（點擊圖片鏈接看原圖）圖 . Google 書籤的類別設計圖

這張設計圖該如何解讀呢？

先觀察紅色區塊，也就是 書籤 與 標籤 的關係。 從 書籤 的角度來看，它可以被多個 標籤 標記，所以在多重性 (multiplicity)的表達，會是 1..* (一到多)。 再來從 標籤 的角度來看，一個標籤可以有一到多個 書籤，所以也是表達成 1..* 的多重性。圖上在 書籤與標籤 兩端是只使用 * 的符號來表達成 多對多 的關係也沒問題，大概知道意思就可以了。

再來就是觀察藍色區塊這邊，這就是典型的 "複合結構 (composite structure)" 樣式了，它可以呈現出 階層性 (hierarchy) 的樹狀結構關係。 把 書籤與資料夾 的共同特性抽象 (abstract)出來，成為 "Bookmark Entry" 這個抽象類別。 至於有哪些共同的特性呢？ 諸如 add(), remove(), getName() 等這樣的行為都可定義在這個抽象類別內。 而資料夾 (folder)則是 "聚合 (aggregiate)" 了 書籤與資料夾，在 UML 符號是以 空心菱形 來表示。 從 書籤 的角度來看與 資料夾的關係，它必然被包含 (也就是聚合關係)在某一個 資料夾 內，所以在 資料夾 類別這邊的 多重性 是表達為 1；而一個 資料夾 可以有 一到多 個書籤與子資料夾，所以在 "Bookmark Entry" 類別這邊，多重性是表達為 1..* 。

說實在的，即使不會複合結構的表達也沒關係，若能明確地抓出 書籤與資料夾 的關係 (去掉 Bookmark Entry 這個類別)，這就夠了，在這個考題當中，反而要突顯的不會是資料夾的樹狀結構，再次強調，是 書籤、標籤與資料夾 的結構關係。 知道你要表達的焦點何在，這才是關鍵。

再來，又如何知道上述的設計圖是正確的呢？ 那當然就需要驗證了。 不一定非得要寫成程式碼後才能知道設計得正不正確，那太耗時費工了；我強烈建議使用 物件圖 (object diagram)，利用實際的案例，對應所設計的類別，很快就能對比出結構設計的正確性與否了。 物件圖的表達在此就略過不談了，讀者若有興趣，可以利用 UML 工具(如 EA)來練習看看，然後也可以把 Model 檔寄給我，多少我還能協助 Review 驗證的。

※ 延伸參考：
　o 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇。

延伸閱讀：

• 從 Google 書籤看標籤與資料夾的設計觀 ─ 觀念篇
• 讀者對使用案例的幾個提問 (針對另文「三論博客來的使用案例分析」)
• DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
• UML OCUP 題型 Reveiw 與 解析 <1>
• 【企業軟體委外】外包程式碼的結構驗收問題

先看看我的書籤是如何規劃的吧，參考下圖。

（點擊圖片鏈接看原圖）圖 . Google 書籤的管理規劃-01

先瞭解一件事， Goodle 書籤的管理，是沿用 Google 平台傳統的機制，就是利用 TAG (標籤)來組織分類。 Gmail 是如此， Bookmark 也是如此。

所以，我若要 Bookmark 某個遊戲網站的書籤，TAG 大概就是標記如 "Game" 名稱之類的。 那麼當遊戲類的書籤一多的時候，又該如何管理呢? 舉個例，我光是當時玩「魔獸世界」時，保存相關的書籤就有近百個之多，所以你可以同時標記的 TAG 可以有 "Game", "魔獸世界" 兩個；而若是圍棋的書籤則可以標記 "Gmae", "圍棋" 兩個。 當標記的 TAG 越來越多時，你會發現到標籤的顯示會相當凌亂。 若你希望某個書籤雖然是標記成多個 "TAG"，但又希望這些 TAG 的顯示有些關聯性，那麼，就可以如我上圖這樣的規劃一般，就是把 TAG 標記為 "Game", "Game_圍棋", "Game_魔獸世界" 這般，這樣的話在書籤的顯示上就能有循序性的列表了。

同理，為了更容易透過 Google 書籤工具快速找到我要的相關於貼上 "軟體開發" TAG 的網站，我分了有 "軟體開發", "軟體開發_NET", "軟體開發_Java", "軟體開發_Web", 等標籤。 要再更進一步地分類，還可以把 書籤 儲存的名稱加上 關鍵的頭字語。 例如我在「魔獸世界」標籤的眾多書籤為了更細分，所以我把書籤名稱命名為如 "_盜賊", "_巨集" 等關鍵頭字，參考如下圖。

（點擊圖片鏈接看原圖）圖 . Google 書籤的管理規劃-02

雖然這樣容易找到我要的書籤，但問題仍舊存在，當你規劃的標籤越來越多時，標籤目錄 (Category) 會列出一大串標籤，想要快速地找到你要的書籤，並不容易。

我是一直認為， Google 把 標籤 (Tag) 的應用過份地濫觴了！ 因為，標籤無法如同資料夾一般有階層式的組織，而只能是 "Flat" 平坦的展現與管理 (標籤不能含子標籤)。

標籤是一種 "虛" 的應用。 你可以為一個書籤 "貼" 上多個標籤 (也可以不貼)。 它是一種 "鬆散" 的分類機制，貼不貼標籤都沒關係，所貼的標籤的正確性與嚴謹性也不會嚴格要求，一切都是隨興； 相同的應用在 Google Gmail 與 部落格 都是一樣，尤以後者，Blog 作者可以很自由地為一篇文章 (Content)貼上他認為適合的 關鍵字標籤，它可以輔助透過標籤來找到多篇相關連性的文章；但卻又不是那麼絕對精確，想要找到分類更為嚴謹的同類型文章，則是透過 資料夾 (或稱為 分類目錄) 來組織管理。

我會以為，相當於標籤，資料夾是 "實" 的，而且是從有檔案管理以來，必然會存在的一種機制。 例如檔案系統或部落格文章，必然會 "歸屬" 於某一個資料夾，且為了便於管理，資料夾也可以再包含子資料夾，這就形成了一種 階層式 (hierarchy) 的結構。

"階層 (hierarchy)" 的結構，是人們理解與處理複雜性 (complexity)的一種本能！

Google 把可以呈現階層式結構資料夾的機制去除掉，而只提供平坦式 (Flat) 的標籤機制，我認為沒道理，且造成使用者諸多管理上的困擾！ Google 可以提供標籤與資料夾的管理機制，而不需要干涉使用者是如何地應用。

事實上， Google 若現在要能彌補標籤管理上的不足，要再加上資料夾 (Folder)的機制，其實也不會難。 下一篇就來討論 標籤與資料夾 的結構是如何設計，以及如何利用 UML 類別圖來表達的。

※ 延伸參考：
　o 從 Google Gmail 的 Label 來看設計的觀念 ~。

延伸閱讀：

• 讀者對使用案例的幾個提問 (針對另文「三論博客來的使用案例分析」)
• DoDAF 案例規劃與演練《1》 — OV1(高階概念視圖)
• 類別之間的關係(Relationship) — 一般化—特殊化(Generalization-Specialization) (3) — Basic
• UML OCUP 題型 Reveiw 與 解析 <1>
• 【企業軟體委外】外包程式碼的結構驗收問題

即日起，只要報名【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 Java (06/27, ５４ Hrs)，即免費贈送學員 DVD 光碟乙片 (不要忘了，線上報名還有免費贈送 Ringle 的親筆簽名新書喔）。 光碟內容相當豐富，包括課程所使用的教材電子檔、完整的實做案例 (包括 UML Model 檔與可執行的應用程式碼)； 當然，還包括了如下完整的 J2EE 開發環境 (爾後 HSDc. 會對其系統與應用平台版本的更新而持續 Update)：

• OS: Fedora 10.0 Traditional Chinese
• XWindows: GNome
• VMWareTool
• Java SDK 1.6.0_0b12
• JBoss Application Server 5.0.1
  (Install in /usr/jboss-5.0.1.GA)
• MySQL Server 5.0.77 (Fedora Default)
  MySQL GUI Tools 5.0r12
  MySQL JDBC Connector 5.0.8
  (Install in /usr/mysql-connector-java-5.1.7
• Eclipse 3.3 with J2EE
• Spring Framework 2.5.5
• Hibernate 3.3.1 Code and Library

底下同時列出幾幅開發環境的 Screenshot 圖片：
UML Development Tool (EA, Enterprise Architect) under Fedora Linux:

EA UML 工具在 Fedora Linux 下的開發畫面

Fedora Linux 開機登入畫面。

JBoss Application Server 執行啟動畫面。

MySQL 啟動畫面。

MySQL Administrator 管理畫面。

Java Eclipse 執行開發畫面 01

Java Eclipse 執行開發畫面 02

延伸閱讀：

• 【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 Java (06/27, ５４ Hrs)
• 【系統分析課程】系統分析設計與實作—活用 UML 塑模 與 C#.NET (11/01, ５４ Hrs)
• 【安裝筆記】Install Open SuSE 10.3 on Laptop T61
• 【安裝筆記】Debian Etch Samba 架設與 NFS 連結
• 【課程大綱】活用 UML 與 Java Spring (48 hrs)

書籍內容約有 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 第二篇範例 - 電子化採購系統

延伸閱讀：

• HSDc. 最近正開發程式碼與 UML 循序圖的互轉工具
• {iThome 書評—10} 寫給SA的UML/MDA實務手冊
• {iThome 書評—3} 使用案例寫作實務中譯本
• {iThome 書評} UML 與樣式徹底研究中譯本
• {iThome 書評} UML 精華第三版中譯本