Kenming’s 鮮思維

最近因為 iThome 雜誌的邀稿，準備刊載一些文章在其「連載單元」與 「一般專欄」內，同時呢， iThome 副總編蠻不錯的，幫我也同時設置一個「IT 專家部落格」，發表有關IT的內容。

所以呢，我準備將我原來在我自己「矇矇的秘密基地」內的相關於 『軟體設計』 的文章，均會同步刊登一份在 iThome 的部落格內，我在 iThome 的部落格名稱就稱為：「Kenming’s 軟體設計思維」。

iThome 的部落格系統是以 plog 所架設的，我在想，應該可以利用 RSS 的方式，同步將我在本站的文章同時給 『Ping』 到 iThome 內，成為新文章。但是我不知道如何使用，是否有哪些朋友們知道如何利用 RSS，將新文章寫入到另外一個 Blog 呢？

許多技術人員係從物件導向程式語言(OOP, Object-Oriented Programming Language)來學習物件導向，從 OOP 的角度來學習物件導向時，經常會把它當作是一種 『技術』，當作 『技術』 時，你會想去 『用』 它，而若當你無法 『應用』 在現實面時，就會覺得 『不好用』、』難用』 、理論無法與現實結合』 …等。

把物件導向當作 『技術』 的最大的問題是：你永遠不知道為什麼你要使用物件導向！

幾年前，微軟的 COM 剛盛行時，有些是 『微軟技術代言人』 會在其技術文章裡提及：COM/3-tier/物件導向技術是增進系統效能(Performance)的最佳解決方案；採用上述提及的技術可以加速系統開發。甚至到現在，我仍常聽到：採用 EJB(Enterprise Java Bean) 是實現物件導向的最佳利器、可以讓開發者 『ReUse』 所設計的元件(Component)、節省開發者的開發時間。

嘿，這些 『似是而非』 的論調，幾年前從技術人員口中聽到是如此，現在聽到的還是如此，說真的，我是覺得，還真是一點自我的反思都沒有。我每次對這些技術人員的反駁就是：有什麼方式會比 Client/Server 直接連線至資料庫來處理還要快？ 有什麼開發方式會比你使用 Client/Server 拉一拉表單，然後直接至資料庫 『撈』 資料還要便捷？ 當然，技術人員的直覺反駁是，Client/Server 無法應付數百人以上同時間的交易處理，是啊，沒錯啊，Client/Server 有些假設點：同時上線使用者不超過 200 人、系統的需求不常變動。

但，重點是，系統效能與你採用 COM/EJB/物件導向有何關係？ 那是屬於系統資源(Resource) 的控管處理，諸如 Resource Pooling 的機制、Transaction Management(還包括交易物件的設計)的處理，Database 『Performance Tunging』、頻寬的資料傳輸量的處理… 等。

而採用物件導向/COM/EJB 可以節省系統開發？ 那更是可笑！ 採物件導向可更是耗費開發成本，開發人員每當一想到為什麼要在中間層對物件分門別類，然後實做一個功能要串上好幾個物件的傳遞才能完成工作，一直無法接受這種觀念，如同 Martin Fowler 所提：你永遠無法讓物件導向的新手們瞭解為什麼要採取這種分散式的設計，你只能要求他們如此做，幾年後，他們會突然頓悟，腦袋有如重生一般。所以，採取物件導向可是要花腦筋在軟體設計上，而且若是實做在所謂的實體元件的機制，如 COM+/EJB，那是為了系統分散與交易機制的處理的元件規格，所以，實做上可是更為麻煩，一點也不會減輕開發者的實做的負擔。

所以，為什麼要使用物件導向？ 因為，物件導向是一種思維，是一種哲理，是一種典範，甚至是一種生活觀，你需要綜合相當多的知識，蘊化為 『智慧』，來協助你如何應付與應對軟體的 『善變』，並能提供具體的解決方案。嗯，這兩年突然對軟體設計某小一部分的哲理有一些 『頓悟』 後，每當看到許多系統因為粗製濫造而衍生出複雜的表象，眾多人們卻被淹沒在糾纏不清的問題與狀況時，而個人(外加 Ringle) 卻能 『一眼』 看出問題在哪裡，並且可以提出具體的解決方案，嘿，那可真是莫大的成就感與喜悅的呢。

學習物件導向的思維與哲理可是一條漫長之路。對我而言，我個人是已經選擇了這條 『自討苦吃』 之道，這條道路所要學習的廣度與深度，可是與圍棋之道一樣的深奧無比，每一個階段的學習與體悟，會讓你更接近與探索根本道理，但，似乎又永遠無法達到那個 『彼岸』。如同吳清源大師已經快 100 歲，仍舊每天研究圍棋；Ivar Jacobson 已經 80 餘 近 70歲，卻仍茲茲不倦地研究與發表軟體設計的論述一樣，這是終身職志，已經是融入每天的生活，永遠也研究不完的，甚至，還準備帶到下一輩子繼續來「修道」的。

所以，回頭來看物件導向程式語言，OOP 僅是實現(Implement)物件導向的工具，你會想透過 Java, VB.NET 等程式語言來實作如介面(Interface)、繼承(Inheritance)、多型(Polymorphishm) …等設計。但問題是，OOP 無法告訴你 『What』 and 『Why』 介面、繼承、多型等這類屬於設計的哲理面(philosophy)，甚至，也無法告訴你 『What is Object?』、』How to divide the Object?』 …，而這些哲理，根本不是為了重覆使用或增進效能，目的旨於，協助人們在面對複雜的現象時，應用 『本來就有』 的智慧哲理，來解決複雜的問題，而 OOP，是讓軟體人員解決問題時，所需使用使用到的 『工具』，它就是工具，就是一種手段而已！

從 OOP 學習物件導向觀念是一種本末倒置的方向，那不會是一個好方法，若勉強說，利用 OOP 來 『驗證』 物件導向的一些設計想法，那到說得過去。那麼，從何處學習物件導向呢？ 我這兩年，是透過 『觀察』 生活的週遭環境，逐漸來反思與體悟的。這與我多年來閱讀許多大量其它領域的書籍，除了軟體設計專業書籍外，包括學習類、成功潛能類、企管與專案管理、歷史 …等，實在有莫大的幫助，對短期的軟體技能幫助不多，但對中長期在軟體設計的思考上，會突然在某一個時間點突破而後 『頓悟』，這時再回頭看軟體專業各類的書籍，那可真是遊刃有餘，輕鬆而能感受書中的作者所想表達的觀點與主題。

對初學者，若要更具體一點，要看相關這方面的書籍的話，除了上次介紹過 Grady Booch 的「Object-Oriented Analysis and Design」一書外，國外的一些書籍，例如 James Martin/James J. Odell 合著 「Object-Oriented Methods」 一書，除了內容淺顯易懂、又饒富物件思維之道外，書籍排版與印刷的精美，那更值得典藏的好書。有件事最好避免，國內坊間 OOP 的書籍，有談及物件導向觀念的，最好略過不要看，幫助不大，反而誤導成分居多。

有感而發，既然，Java and .NET 都已經昭然若揭，程式語言確然往物件導向的實做之路，那麼，軟體人員也確實需要俱足物件導向的設計觀念。隨著工具的易學易用，以及網際網路龐大的資料庫，成為實做 『how-to』 的最佳參考來源，使得實做得以更形簡單。那麼，軟體人員更需要將精力擺在物件導向的設計思維，才有可能應對越形複雜的系統，懂得如何以簡御繁。

所以呢，我個人準備把我這幾年的一些心得與體會，儘量利用日常生活面的例子，來解釋物件導向的一些基本觀念與術語，例如，什麼是物件/類別、什麼是介面/多型、什麼是封裝 …等。我會將這些文章另行分類成 『物件基本觀』。對了，有一些議題我會採反問的方式來闡述一些個人的物件觀。例如，若你要問我，EJB 是不是物件導向？ 我會說 『不是』；然而 Client/Server 是否是物件導向？，我的答案卻是 『Yes』。 呵呵，先賣個關子，這些是蠻有趣也蠻引起爭議的話題，爾後我會著文說明我的看法與理由的。

詳細內容及報名，請至：
『首頁-活動報名』線上填寫報名申請表單

§課程名稱： 使用案例寫作實務、應用與實現

§課程簡述：

• 本課程旨在教導學員如何利用使用案例來捕捉系統的功能性需求，並瞭解如何掌握寫使用案例的核心原則與最佳實務。當學會如何建立正確的使用案例模型(Use Case Model)，界定系統範圍、找出參與者、及寫出標準規範的使用案例敘述後， 馬上就可以直接利用 EA UML 工具產出具體可執行的應用與測試程式碼，以驗證使用案例的功能點(Functional Point)。

§課程目標：

1. 瞭解如何描述使用案例(Use Case)，如何寫出正確、易讀性高的使用案例，並提供寫使用案例的範本(Template)，說明主要欄位的作用與寫作時基本的規範與考量。
2. 學習如何利用使用案例圖(Use Case Diagram)界定系統設計範圍、找出系統的參與者(Actor)與使用案例。
3. 學習如何繪製出不同層級(level)的使用案例圖，包括企業層級(Business use case)的使用案例與使用者目標層級的使用案例(User-goal use case)。
4. 指導學員如何實現(Realize)使用案例，以簡單的循序圖設計，並利用 EA 的 "Code-generation" 工具來產出 .NET (or J2EE) 的程式碼，包括可被執行的應用程式碼，以及功能測試程式碼。(眼見為憑，是強化信心的利器，之後可再對系統結構施以 "重構" 的技巧。)

準備教材：

• 由授課講師提供講義，包括授課內容、案例分析與實務範例。
• 學員可攜帶相關使用案例參考書籍，並對於書中內容有問題者，可以直接提問。

§使用工具：

• UML2.0 IDE ：Enterprise Architect 6.1 Trial。
• Visual Studio .NET 2005 Trail and Java Eclipse 3.1 (本課程會同時產出 .NET and Java 程式碼)

§使用設備：

• 使用白板與投影機，由講師親自說明與操作示範。學員最好能攜帶 Notebook ，於課程中實際操作練習。

§授課講師：

• 王克明(Kenming Wang), 賴信仁(Ringle Lai)

§上課費用：

1. 優惠折扣 NT$ 300 x 12(hrs) = ＄３，６００, 含稅(原價為 $4,200)。
2. 曾參加過本公司所舉辦的軟體設計課程的學員(舊生)，再以八折優惠 ＄３，２００。(請記得註明為舊生，本公司查詢確認即以優惠算)
3. 現在同時報名另一單元課程「UML 實務入門」，亦以八折優待，共 ＄６，４００，舊生為 ＄６，１００。
4. 曾參加此同一單元課程(課程相同)的學員，可免費再次旁聽，但僅開放五位名額，以提早申請者優先，並請攜帶原上課講義。

§上課時間：

• 2006/03/25(星期六)、03/26(星期日) 共兩日。
• 每日上課為六個小時(AM 9:30~12:30、PM 1:30~4:30)，課後並留半個小時供學員自由提問。

§上課地點：

• 開羅會議中心，地址：台北市光復南路65號B2 (光復南路、市民大道交接口)。
• 參考交通與地圖地圖：
  http://www.hsdc.com.tw/modules/newbb/viewtopic.php?viewmode=flat&topic_id=38&forum=5
• (報名人數滿 10 人即開班，同時並保留 5 名學員重新選修該課程)。

§適合學員：

• 系統需求/分析/設計(RA/SA/SD), PM, Programmer 等在職軟體開發者或在學學生。
• 非 IT 人員，但想瞭解如何利用使用案例來描述企業與系統的流程及需求。
• 看了很多 Use Case 書籍，仍然無法寫出令人滿意的 Use Case 的開發人員。

備註：

• 若需含稅，請於報名時在備註欄提供開立發票的資料。
• 為確保報名足額人數，煩請先行 ATM 轉帳預約費用($500~$1000 即可)，並請於報名表備註欄位內，註明您的轉帳帳號末 6 碼與轉帳金額，煩請轉帳至：
  ———————–
  誠泰銀行： 103
  帳號： 0772-50-100979-9
  ————————
• 若不及 ATM 轉帳者，亦可於現場報名，仍請於報名表備註欄內，註明為現場繳費。

§課程諮詢(HSDc. 軟體設計專業顧問團隊)：

• 諮詢專線：TEL: 02-27227179
• 服務信箱：service.hsdc@gmail.com

§附表：課程表參考

	上午	下午
Day 1	※使用案例基本功 什麼是使用案例 為何是利用使用案例記錄需求 建構使用案例模型的組成元素與語法說明 如何界定系統範圍 如何找出參與者與使用案例 使用案例的關係— include and extend 如何寫出高品質的使用案例敘述 案例分析 — 使用案例模型的廣度、層次的界定與分析	※實作練習—利用 EA 建立使用案例模型與撰寫敘述(以實際個案為例) 找出使用案例—利用活動圖所表達的企業流程轉換成系統層次的使用案例 利用 EA 建立使用案例模型—繪製使用案例圖 撰寫使用案例敘述—依使用案例標準格式範本撰寫 利用 EA "文件產生器" 產出高品質的使用案例需求規格敘述文件
Day2	※使用案例實務與應用 學習從鳥瞰的觀點看使用案例 如何利用使用案例表達企業層次與應用系統面層次 利用循序圖表達參與者與系統的互動描述 從使用案例圖表達架構觀點，並觀察設計者的設計意涵。 使用案例的實現(Realization) 利用控制物件實現使用案例 定義控制物件的屬性與方法 說明正向與反向的工程 — Model 與 程式碼的同步 實現功能測試碼，驗證測試案例	※實現(Realize)使用案例(以實際開發個案為例) 設計與創建 Use Case 控制物件，以實現使用案例的功能需求 利用 EA "Code-generation" 功能產出控制物件的程式碼框架 測試先行—在 IDE 工具內撰寫該控制物件的測試程式碼 利用虛擬碼(Pseudo Code)撰寫程式碼內部的細節 實際執行應用程式碼的部署與執行功能測試 利用 EA 反向工程功能，在 IDE 環境內修改程式碼，並反轉(Reverse)回 UML Model。

我在上個月看 Discovery 節目時，該節目很有趣，是介紹有史以來，前 10 大受歡迎與戰鬥力強的坦克車。

嗯，還是從二次大戰開始介紹的呢，其中，包括德國的虎式與豹式坦克，都名列上榜，而更為驚人的是，蘇聯的 T34，當時在德蘇大戰中叱吒風雲，令德軍第一次感受到他們的武器不如人，是名列 10 大中的第三名。而至於第二名的坦克，則是活躍於波灣戰爭中，但卻也有令人苦惱的問題，太過龐大與吃油量太重、維修不易等問題。

嗯，這要與我談軟體模組化有何關係呢？ 嘿，當我看到榮登 Discovery 第一名排行榜的坦克時，實在驚訝與讚嘆不已。榮登第一名的是：改良過的德國製坦克 — 豹式二代。

話說原來，當時二次大戰中，德軍鑑於蘇聯 T34 的優異與靈活又兼顧火力的性能，而加以參考並改造他們的坦克，當時就有豹式坦克的出現。但是，豹式坦克雖性能優異，且砲火猛烈，但是，太容易故障了，而德國人龜毛完美的性格也反映在該坦克上，加上太多不必要的束縛與修飾，而這些，是在激烈的對戰中，大部分是不需要的。

而今的豹式二代，仍然呈現著豹式一代優異的性能與保持了德國人求完美的設計性格，但卻改善了最重要的一點 — 快速維修與保養的能力。怎麼作呢？在所有前 10 大坦克中，也只有豹式二代具有現今結合硬體與軟體的彈性設計 — 模組化！

我看了節目的展示，嘴巴合不攏嘴，實在驚訝不已。豹式二代一旦發生故障，維修人員只要拿出筆記型電腦，連結坦克的介面，即可以診斷出坦克的那一部分出了部分，再來呢，不是去拆開出問題的那一部份，而是，整個模組抽出來，就好像診斷出 PC 的顯示卡或記憶體模組出問題後，拔出來，再把新的給置換進去即可。我第一次看到，坦克的模組化設計，也能造成這種 P&P(Plug-and-Play) 的可抽換效果。

回歸軟體，看到好多產品都號稱是 『模組化』 的設計，每次呢，我到世貿軟體應用展，只要問展示販售 『進銷存』 產品的廠商，能否將 『進貨』 模組，與某家或是本來公司內部既有的 『存貨』 系統給 『兜』 在一起呢？ 嘿，得到的解決方案就是利用 『資料庫』 來作系統整合。

而以資料庫為整合的解決方案，我就很清楚了，這些號稱是模組化，根本只是在業務層級的邏輯面，卻沒有確實在實體的系統面，達成模組化的設計。若要能達成在實體系統面的模組化設計，必然是首重於介面(Interface)的設計與溝通，至於資料庫，只是各個模組的 『私有倉儲(private storage)』 罷了。以資料庫為主的整合，是屬於 『草本植物』 式的整合，雜草叢生，而根卻早已彼此糾纏不清，剪不斷、理還亂了。

連龐然大物般的坦克車都可以確時達成模組化的設計，怎麼這些軟體產品，談模組化這麼久了，卻仍是用幼稚的資料庫整合方式，而無法確實分隔每個可被抽離與置換的模組，並且可以很容易地利用測試工具找出是那個模組出問題，乾脆就直接把壞的模組給 『抽換』 掉呢？

最近領悟到期指操作的時間格局後，也就是我一再說及的 『封裝(Encapsulation)』 哲理，就很容易辨別趨勢。日線有日線的趨勢；15分K 有 15K 的趨勢。越是短的時間格局，趨勢越是容易轉變，所以，若是在短格局的區間操作時，短趨勢一變，就需要 『順』 著趨勢來操作。

舉我昨日(3/14)的操作為例，在日線的格局，是偏空，所以我放了日線的空單；但在 15分K 的時間格局，卻是短多趨勢，所以我放了一口多單。雖然從日線的格局來看，當日可說是蠻弱勢的反彈，但，從 15分K 的趨勢來看，確是短多無疑，而且，弱規弱，從底部也反彈了近 100 點。

這樣操作是否有逆勢？ 甚至，神經有些不正常，多單與空單同時一起？ 當然，我已經分了兩個期貨帳戶，一為日線格局；另一為極短的格局，包括 15分K 或 5分K。

這半年來，我一直在思考大盤操作的根本道理，是要學會 『預測』 大勢，還是 『順勢而為』？

我發現到，遍讀了百年來中外的名家作手回憶錄、傳記與交易策略守則，確定了一件事，他們只說要：順勢而為，卻沒有一個說如何預測大勢，甚至一而再地告誡，不要作預測。但有趣的是，國內電視台的財經節目，無論是投顧老師的節目，甚至是具公信力的財經電視台，都很會作預測，而且，我都覺得他們講起來都很有道理，也因此，常常會影響到我交易的思考與判斷～ 無論正確與否。

但是，我總算越來越對「順勢而為」有更多的體會，順勢絕對不是預測，所以，要預測市場的底部、轉折點、支撐與壓力等，這不是「順勢者」該作的事。

這是不是根本道理？ 我還不知道，但我個人一直是從根本道理去思考，一直去學習與瞭解市場操作本質與內涵。從你在每一個階段所體悟的根本道理後，才去找操作的策略。

操作的策略，反映到大盤就是 K線、均線、諸多指標等，這些是 『How-to』。有趣的是，我個人也研讀了相當多的指標，發現到，無論你用各種的指標，若是正確操作的話，買賣訊號大部分蠻接近的。即使你用了自創、很複雜的組合指標，大部分的結果，與你使用簡單均線的操作，幾乎一樣。

那麼，只要能依照指標操作，不就可以獲利，起碼，也不會損失太多囉？重點是，操作者很難遵循指標的操作，這是操作紀律的問題。但我認為真正的問題是，因為操作者無法相信交易指標，為什麼無法相信？因為操作者沒有思考與通曉最根本的道理！

『預測』 與 『順勢而為』 是兩種截然不同的根本道理，而這也就牽涉到作法的根本不同。』預測』，會想要買低賣高、會尋找九成以上勝算的交易訊號；』順勢而為』，因為不作預測，所以會買到比底部高、賣到比頭部低的點，勝算可能只有 6,7 成左右而已。

我到不是要比較 『預測』 與 『順勢而為』 的優劣，而是，若你能對某種道理有一種 『恍然大悟』 的感覺後，那好像就是一種 『開竅』，心理就會踏實很多。而依據這個根本道理所學習、尋找、創見的操作策略，就可以信之不疑，也就是在操作時，有如一個傻瓜般，只依照訊號作買賣。

我想要表達的其實就是，雖然許多操作書籍教我們用了某些指標後，然後就是相信它，遵循它的買賣訊號。但是，若操作者沒有通曉根本道理，是很難相信的。所以，我覺得，通曉根本道理，就是 『大智』 的體悟，然後，你會選擇用你覺得最簡單的方式來操作，並且信之不疑，有如傻瓜一般的低 IQ，而這是一種 『若愚』 的表現。

大智而後才能若愚，兩者缺一不可。如此才有可能在這個激烈的期貨市場裡取得致勝之道。

圖、2006/02/14 台指期日線走勢圖（縮略圖，點擊圖片鏈接看原圖）

圖、2006/02/14 台指期 15分K 走勢圖（縮略圖，點擊圖片鏈接看原圖）

由於眾多學員的熱烈迴響與反應，本系列單元課程會持續舉辦！

詳細內容及報名，請至：
『首頁-活動報名』線上填寫報名申請表單

§課程名稱： UML2.0 實務操作入門

§課程簡述：

• 以 『問題-解決方案(Problem-Solution)』 的實做方式，引導學員實際針對一個應用領域案例並利用 UML 工具畫出 UML 2.0 十三種圖。

§課程目標：

1. 完全以實務為主，指導學員如何學會畫 UML 2.0 的圖形。
2. 利用一個案例，涵蓋串連整個 UML 13 種圖。
3. 畫每一個 UML 圖之前，會先以一個問題的陳述，來說明應用該圖形的時機與場合，然後提出具體的解決方案。
4. 學員於課堂上實際親自操作 UML 工具，由講師示範與指導畫每一張圖的技巧與圖形的元素說明。

準備教材：

• 由授課講師提供講義，包括內容、案例分析與 UML 13 種圖範例。
• 學員可攜帶相關 UML 參考書籍，並對於書中內容有問題者，可以直接提問。

§使用工具：

• UML2.0 IDE ：Enterprise Architect 6.1 Trial。

§使用設備：

• 使用白板與投影機，由講師親自說明與操作示範。學員最好能攜帶 Notebook ，於課程中實際操作練習。

§授課講師：

• 王克明(Kenming Wang), 賴信仁(Ringle Lai)

§上課費用：

1. 優惠折扣 NT$ 300 x 12(hrs) = ＄３，６００, 含稅(原價為 $4,200)。
2. 曾參加過本公司所舉辦的軟體設計課程的學員(舊生)，再以八折優惠 ＄３，２００。(請記得註明為舊生，本公司查詢確認即以優惠算)
3. 曾參加此同一單元課程(課程相同)的學員，可免費再次旁聽，但僅開放五位名額，以提早申請者優先，並請攜帶原上課講義。

§上課時間：

• 2006/03/11(星期六)、03/12(星期日) 共兩日。
• 每日上課為六個小時(AM 9:30~12:30、PM 1:30~4:30)，課後並留半個小時供學員自由提問。

§上課地點與上課人數：

• 開羅會議中心，地址：台北市光復南路65號B2 (光復南路、市民大道交接口)。
• 參考交通與地圖地圖：
  http://www.hsdc.com.tw/modules/newbb/viewtopic.php?viewmode=flat&topic_id=38&forum=5
• 報名人數滿 10 人即開班(同時保留 5 名學員重新選修該課程)。

§適合學員：

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

備註：

• 若需含稅，請於報名時在備註欄提供開立發票的資料。
• 為確保報名足額人數，煩請先行 ATM 轉帳預約費用($500~$1000 即可)，並請於報名表備註欄位內，註明您的轉帳帳號末 6 碼與轉帳金額，煩請轉帳至：
  ———————–
  誠泰銀行： 103
  帳號： 0772-50-100979-9
  ————————
• 若不及 ATM 轉帳者，亦可於現場報名，仍請於報名表備註欄內，註明為現場繳費。

§課程諮詢(HSDc. 軟體設計專業顧問團隊)：

• 諮詢專線：TEL: 02-27227179
• 服務信箱：service.hsdc@gmail.com

若對該單元課程有相關建議與問題，請至：
http://www.hsdc.com.tw/modules/newbb/viewforum.php?forum=5
發表討論。

§附表：課程表參考

	上午	下午
Day 1	※UML 2.0 說明 UML 綜觀介紹 (Overview) 建立企業流程與系統需求模型 活動圖(Activity Diagram) 使用案例圖(Use Case Diagram) 系統結構分析與設計 靜態結構—類別圖(Class Diagram) 動態結構—循序圖(Sequence Diagram) 與互動圖(Communication Diagram)	※實作練習(以實際開發個案為例) UML 實作工具介紹 Enterprise Achitect(EA)的安裝與使用介紹 企業流程與系統需求的實作練習 利用 EA 繪製與產出 Activity Diagram與Use Case Diagram 系統結構分析與設計 利用 EA 繪製與產出 Class Diagram、Sequence Diagram 與Communication Diagram
Day2	※UML 2.0 說明 系統的微觀設計 介紹UML的 物件圖(Object Diagram)、狀態機圖(State Machine Diagram) 與時序圖(Timing Diagram) 系統的鉅觀設計 介紹 UML 的 套件圖(Package Diagram)、互動圖(Interaction Overview Diagram) 、元件圖(Component Diagram) 與 合成結構圖(Composite Structure Diagram) 系統的實作與部署 介紹 UML 的 部署圖(Deployment Diagram)	※實作練習(以實際開發個案為例) 系統的微觀設計 利用 EA 繪製與產出物件圖(Object Diagram)、狀態機圖(State Machine Diagram) 與時序圖(Timing Diagram) 系統的鉅觀設計 利用 EA 繪製與產出 套件圖(Package Diagram)、互動圖(Interaction Overview Diagram) 、元件圖(Component Diagram) 與 合成結構圖(Composite Structure Diagram) 系統的實作與部署 利用 EA 繪製與產出 部署圖(Deployment Diagram