Kenmingの鮮思維

明天就是除夕了，照往常慣例，我們農曆年都是在台中老家過的。也鑑於因為上次從台中回來台北時，在交流道前車子變電盤拋錨而造成故障，對車子要開上高速公路，實在是不妥當。所以今天利用除夕的前一天，趕緊將車子送至保養廠作定期維修。

早上呢，我帶著兩位女兒們，先開車到「咖啡因」用早餐。嗯，他們的早餐供應很不錯，我們家蓁妮全部吃光光，而我最喜歡的是，點的是有雙份飲料的早餐，喝了柳橙汁，再把厚片土司、培根、炒蛋等吃完後，喝上一杯熱熱的綜合咖啡，實在愉快～ :p

車子是開到永和太平洋百貨附近的「裕隆 Nissan」保修廠維修，算一算所開的里程，直接是作九萬公里的進廠維修，定期維修費約 $5000 餘元，還算可以接受。

維修的同時，我就帶兩位女兒們走到仁愛公園玩耍。呵，她們玩得好開心，盪鞦韆、溜滑梯等，沒有什麼人，玩得可真不亦樂乎。 然後呢，我們就去「太平洋百貨」B1 的「誠品書局」以及玩具部逛逛。蓁妮看上兩本「小布娃娃」的雜誌月刊，這小妮子現在可真迷小布娃娃，直誇娃娃可愛、叛逆、夠酷。 Annie 則在書局內翻閱了好幾本兒童繪畫讀本，有些可真不錯，其中一本書，介紹各種動物時，還附上牠們的 "毛" 可以給小朋友直接觸摸呢。

而我呢，又是習慣性地逛到財經專櫃中，看中兩本書：黃國洲先生的「期貨順勢雙刀流」，另一本是翻譯的「華爾街操盤高手」，打算買回來，利用過年期間，在台中好好閱讀。 其實呢，我還看中一本書，是介紹五、六年級生的卡通、典故與配音、作詞者。內容很豐富，排版好精美，介紹的卡通，都曾是我從國小時，就已經播映的國語卡通，有好幾部，我也還沒看過呢。 想一想，我還是忍住，買了不少書，還外加買了兩本非常初階的英文文法書，但我覺得在句型的介紹，有別於一般見樹不見林來介紹所謂的八大詞類，先有確立主軸，再逐漸往局部延伸，不錯，蠻適合我老婆看的。

逛了許久，維修保養廠打電話過來，說他們維修人員檢查後，發現包括煞車片與輪胎的磨損、還有一些地方零件的老舊，需要更換。 吼～ 整個加起來，零件更換與維修保養，要花上二萬餘元！ >:(

沒辦法，要上高速公路，安全第一，該換的還是要換，車子也實在老舊，看來這一兩年，該考慮更換車子囉。

又如往年的過年一般，在台北，總是感受不到過年的氣氛，沒有喜氣洋洋的感覺。讓我回想起我在台中幼稚園、小學期間，那種碰到過年時的快樂洋溢，與鄰居小朋友們一同開心玩耍、穿上新衣，收到紅包的興奮，差別好多啊。 :-/

我們公司(HSDc.)代理 Sparx System. 的 Enterprise Architect UML 工具，改版不可不謂之頻繁。約每 1~3 個月一小版，3~6 個月一大改版。目前 EA 正式推進至 6.1 版，其中最重大的功能在於其 MDG Link 已經與 Microsoft Visual Studio .NET 2005 完全密切地整合了。

摘錄 EA 6.1 版的新功能說明：

• 可以利用內建的設計樣式(Patterns)或自行創建模型樣式(Model Patterns)的方式，來快速產出並正確性地完成你的 UML 軟體的模型。
• 使用 EA 的 "智慧形快速連結器(Intelligent Qucik Linker)"，只要在短短的片段時間內，即可以新增與建構你的軟體模型。
• 如同程式碼的 IDE 工具一般，EA 支援在塑模時，針對個別元素的命名，支援所謂的 "Context Sensitive" 的方式，而更容易建構正確、標準語法的軟體模型。
• 更多樣、豐富的文件樣版(Rich Text Documents)，來協助開發者產出可被維護與管理的文件。
• 利用已更新的除錯機制，可以以視覺化的方式來檢視同時間所執行的多執行緒(Multi-Threaded)應用程式。
• 新版支援除錯與視覺化的 .NET 2.0 規格應用執行程式。
• 可以以視覺化的方式，來呈現可被管理擴充(Managed Extensions)的 C++ .NET 程式碼。
• 可以在 EA 的除錯視窗中，在特定的任何 "中斷點(Breakpoint)" 新增 UML 循序圖(Sequence Diagram)，瞭解 執行期間(Runtime) 時的物件合作狀態。
  (這是EA的特有功能，如此一來，可以讓設計人員透過此功能比對 Design Time 與 Runtime 的 循序圖，確實掌握程式的品質)
• 使用 BPMN的標準規格，來塑模(Modeling)企業的流程(Business Process)。並且與 EA 的 "Quick Linker(快速連結器)" 及 "模型檢驗器(Model Validator)" 整合。

ˇ關於 BPMN for EA 6.1 的下載與說明，請參考：

http://www.sparxsystems.com.au/products/mdg_bpmn.html

ˇEA 6.1 試用版的下載與文件等相關說明，請參考：

http://www.sparxsystems.com.au/products/ea_downloads.html

關於 MDG Link for Visual Studio .NET 2005 官方釋出版本說明：

• 整合 UML2.0 完整規格至 Visual Studio .NET 2005 的開發環境。
• 可以直接在 VS.NET 2005 的 IDE 環境檢視、產出、瀏覽與設計 UML2.0 的軟體模型。
• 更快速與立即性存取 UML2.0 的開發，包括 MDA 等。
• 可以以視覺化來檢視與呈現你的程式碼。
• 所有 UML 2.0 的設計產出(Artifacts)，均可以在 VS.NET 2005 創建與編輯。
• 更完整、更便利的方式，來整合 UML2.0 與 .NET 開發環境。

ˇ 請參考本公司推出的特惠活動：「買 UML/EA 教育訓練課程送 EA 企業完整版」。

（縮略圖，點擊圖片鏈接看原圖）

我很少會轉貼文章或其它圖形在我的網站上。不過，我在「聚財網」看到的這張圖實在是… 太有趣啦～

道盡了標準散戶在股市低檔不敢買、高檔後追高被套牢、趨勢往下仍不願賣出、殺到最低後受不了賣出後反而股市開始上揚。

呵，這樣的戲碼在股市永遠也演不完～

我在永和復興美工的美術器材用品店，買了許多本素描剪貼簿，一般書店、文具行可能要賣到 80 元，這裡只要不到 50 元就可以買到，便宜實惠，也滿足了我家兩位小朋友，尤其是蓁妮，她太喜歡隨手塗鴉、畫畫等，下學期還被甄選進入學校的電腦繪圖資優班。

晚上呢，我在寫教材，蓁妮則在我旁邊，拿了我的鉛筆，花不到半小時的時間，就在她的素描本上隨手畫了兩幅素描。哇！！ 我很驚訝，一頁是美少女，另一頁是有些許詩意的意象畫，還是蓁妮自己題字的。

Flicker 可真是方便，我把小女兒們的畫畫作品，掃瞄後就直接上傳到我的 Flicker 相簿了。

然後我們家 Annie，只要每次看到姊姊畫畫，她一定要湊熱鬧，也畫了一張不算是素描的素描。主題是什麼，我也不知道。不過，畫畫底下在爬的那個小寶寶，好像是在畫我。 XX(

晚上，我們家大女兒蓁妮與小女兒采潔，因為媽媽加班，所以要我陪她們睡覺，順便抓背搔癢。:.

蓁妮呢，又考了我三個冷笑話謎語：

1. 熊過來了，猜一句成語。

2. 十一本書，猜一句成語。

3. 可愛小白貓不小心掉到水溝裡，被英勇的黑貓給救了起來，猜猜，白貓對黑貓的第一句話是什麼？

結果，采潔也不甘示弱，考了一個超無俚頭的謎語：

「有一天，大象、兔子與斑馬去便利商店買東西，猜猜看，誰最愛亂買東西」？

答案是 ．．． 繼續閱讀 »

我與 Ringle 上個月至某家承包政府機構單位的專案開發公司，應該公司總經理的邀請，請我們過去與該公司約 10 餘位軟體開發人員作一個軟體設計課程的說明。

作了約半個多小時的軟體課程與工具應用的說明後，當然也開放軟體人員們提問，針對專案開發上，是否有沒有現實上的問題。

嗯，這些軟體人員很年輕，好幾位女孩子看來還是從學校剛畢業的，問題不多，比較關心的是工具上的應用，是否如 EA 有沒有支援 VS.NET 2005 這類的問題。

倒是他們總經理，問了一個很直接的問題：UML 對我們在專案開發上，有什麼實質的好處？

嘿，當你面對這樣的問題，而且感受到軟體開發人員們普遍對軟體設計並沒有深刻的概念，且專案規模並不大，感受不到利用 UML 從事設計到底對他們的 "現實開發環境與維護等" 有何好處時，若你從正向來推銷 UML、軟體設計，例如，塑模？ 讓系統有彈性？ 保留軟體開發的資產？ 促進團隊成員們的溝通？ ．．．這些，對年輕資淺的軟體開發人員們，那是不容易讓他們有感覺的。

我就用了一個反問的方式來提問：請問，貴單位的需求訪談紀錄，是否可以直接交付給程式人員，落實為實做的程式碼？

理所當然，他們認為當然不可能，無論如何簡化開發，總是必須仍透過傳統基本的 SA/SD 程序才能寫成程式碼啊。我跟他們說，當我們將傳統需求訪談紀錄整理成 UML 標準的使用案例後，先不用管結構分析與設計，就可以產出程式碼，甚至，包括功能測試程式碼，不需要花上一天就可以作出來，當然，我們也有準備簡報，來展示這一段的過程。

但是，他們仍然不相信，席間，有個女孩子說：聽你們說的如此的神，但是我們希望能 "眼見為憑"，能否直接舉出個案實例呢？

顯然，他們對簡報的內容，並不相信，可能，他們受過太多產品工具廠商們作假的謊言了吧。
我就說，好吧，應觀眾的要求，我直接請 Ringle，由他們提出一個案例，然後開始從畫使用案例圖，表達使用案例的實現(Realization)，利用 EA 產出程式碼框架，加上程式碼細節，還有，再加上功能測試程式碼。當場示範與操作，整個過程，不到 30 分鐘就完成了。 :p

這下沒話可說了吧？ 我跟他們說，這根本不神，我只是懂得將需求紀錄利用 UML 的使用案例圖，讓需求能更加有條理的組織與功能切割而已，況且，軟體的問題，不在於能不能寫得出來，要寫出來，我實在看不出來有什麼困難的，"How-to" 太容易從 google 來找到的。軟體最大的挑戰在於如何讓系統具有 "應變" 的能力，讓其具 "生生不息" 的繁衍，這就真的很難了，窮究一輩子也研究不完的。

對我而言，UML 只是手段，我很早就已經清楚這一點了。只是，確實 UML 是截至目前為止，要表達出我個人的軟體設計思維，最佳的呈現工具，如此而已。我沒有必要為 UML 說好話，有更佳的手段或更好用的工具，當然就可以把它換掉，沒必要依依不捨。

同時，對於別人提問的問題，不要試著去 "捍衛" 你的觀點或要推銷的產品、工具等，也不要提太多非常美好、理想的 "境界"，那離現實太遠了！

從「美麗新境界」拉回到現實面，尋找貼近現實的手段，發現問題，採漸增、循環的方式，協助往前走一步，解決問題，逐步推進。這絕對勝過給了太多承諾與夢想，想要一步登高望遠，結果因現實的困難而放棄，到最後才發現原來是一場破碎的夢，好上太多了。