Kenming’s 鮮思維

前言

「工欲善其事，必先利其器」，學習UML沒有好的工具幫忙，往往會讓開發人員半途而廢，尤有甚者，開發人員有時會因為使用了不容易使用的開發工具而誤認為UML是一個非常困難學習的「技術」。殊不知UML只是一種「語言」，就和學習中文、美語一樣，學習UML根本不困難，只要瞭解UML的語法以及知道UML的適用時機，UML自然手到擒來。當然，如果有一套上手的UML開發工具，UML的困難度更是大幅降低，這也是本次專欄我們會討論UML工具評比的原因。

在這次專欄中，我們將評比三個不同的UML工具 – IBM公司的 Rational Software Architect(以下簡稱RSA)、Borland公司的 Together Architect(以下簡稱Together)以及Sparx Systems公司的 Enterprise Architect Corporation Edition(以下簡稱EA)。
評比的標準會從以下兩個面向來分別評估：

1. 對UML 2.0的支持；
2. 文件產生機制。

整篇文章中，我們會分成兩大部分，主要針對這三套軟體在上述的兩個面向中的操作進行說明，並且在每一個部分的最後一個小節，都會對三個軟件在該項目中做綜合評比。
不過在開始介紹之前，先就價錢做個評比說明，根據三家公司的產品標準售價，其價格的比較表如下表：

表1：三套軟件的價格表

對！不要懷疑，這三個產品的價格的差距大約是20倍。先有這樣的一個印象後，我們將針對這三個產品的功能再詳細介紹。

對UML 2.0的支持分析

圖1 是OMG所定義的UML十三張圖的分類(參考自Unified Modeling Language: Superstructure, Version 2, p. 660)。

圖1、UML 2.0 規範的 Diagram 分類

以下，我們將針對上述的三個軟件分別說明其對於UML 2.0規範的十三張圖的支援。

1、IBM RSA：

IBM的 RSA 與 Borland Together都是建構在 Eclipse 平台上，因此，你必須要先建立一個 UML 2.0 的專案，如此才可以繪製UML的圖形。下圖2就是 RSA 的 UML專案的操作畫面。

圖2、RSA 的 UML 2.0 專案操作畫面

繼續閱讀 »

國內從事 『企業(Enterprise)』 軟體的獨立開發廠商(ISV)，大致可以分為三種營利的模式：

• Project (專案)。
• Package (套件)。
• Product (產品)。

算起來，應該約有 80% 以上的開發廠商是以專案開發為主的(Project-based)。專案，顧名思義，會偏以滿足單一任務的工作性質，服務的對象也偏以單一的客戶為主，目的就在於能達成客戶對資訊系統的期望，而這些期望，也就是系統所提供的服務與功能—軟體開發廠商所負責承諾來實現，並換取實質的回饋報酬。

我們都知道，最為難的就是如何能滿足客戶的期望，因為，客戶的期望一直在變；又，競爭的因素，專案性質的資訊系統開發總是被要求在最短的時間，以最少的成本來完成，自然，種種不合理的要求，品質當然也就不佳。

請記得，開發端與客戶端是要能達成一種實質交易上的平衡，而開發端投入許多的心力與人力，來服務單一的客戶，卻換取開發端認為不合理的報酬，當然這種交易的結果也就無法讓雙方都能協調滿意的了。

只賣給一家客戶，即使開發 ERP 系統拿到 200 萬元，開發端都還認為是慘賠，因為人月的實質負擔實在不敷成本。一般專案性質的軟體開發總是存在一個根本問題：無法達成軟體的大量複製！

專案的規模除非夠 『肥』、專業領域夠 『精』，否則，對開發與客戶端都很難取得實質交易的平衡。我還記得，閱讀 XP (Extreme Programming) 的書籍，Kent beck，軟體業界的大師，所涉及參與的專案，諸如航空班機的控管系統，開發預算都是高達數千萬、數億美金以上，開發的週期要高達好幾年以上 …。我覺得，若要開發專案，作這種才有機會有實質的回饋、人生也會活得比較有成就感吧？

ERP 系統可否大量複製呢？ 嗯，我們在世貿軟體展，可以看到國內許多的軟體廠商展出 ERP 系統的產品，可真便宜，數千至數萬就可以買到了。站在該軟體廠商的角度，活用軟體的大量複製，方向是對的，如此才有可能將成本壓低，才能服務眾多需要的客戶，售價自然也就可以大幅降低了。只可惜，這些 ERP 系統實在不能稱為產品(Product)，最多最多，只能稱為套件(Package)而已。

套件與產品如何區別？ 每一次我到軟體展時，遇到漂亮的展售小姐解說 ERP 功能時，我只會問一個問題：可不可以將 SQL Server 換成 MySQL？ 幾乎一致的回答是不行。我還只是問實體平台的變更而已喔，還沒有問到，若我要求某一個 ERP 系統所沒有的功能或需要變更業務流程時，該如何客製化(Customize)呢？這問題我連問根本也不想問，因為可想而知，作不到！

套件的特性是，它提供了預先定義好的功能(pre-defined)給客戶，然後利用 『參數(parameters)』，讓客戶來自行 『微調』 系統功能；若是客戶單位要求的是套件沒有的功能、企業規則或企業流程的話，當然就要找原開發廠商，然後回到 『專案』 的型態來開發新的功能。

專案要作的是滿足客戶的需求，但期望客戶的需求變動不要太頻繁；套件則是提供預先定義好的需求給客戶，但其假設點是客戶的要求不多、規模不大(這也就是國內的 ERP 廠商的客戶鎖定在中小企業的原因)。兩者的根本問題是：彈性度不足，無法提供 Enterprise 層級的資訊系統，有效的客製化與變動性管理！

那麼，該具備什麼樣的特性才 『夠格』 稱之為 『產品(Product)』 呢？ 答案就是理出專案與套件的共同問題：讓系統更有彈性！

為什麼客戶端需要更換資料庫系統與應用伺服平台？ 因為成本、效能、穩定性等考量。
為什麼客戶端需要客製化？ 因為需求就是一直持續性地變動。

即使有領域專家的協助、即使有超炫的使用者介面、即使提供的是更棒更完善的功能，這些仍是沒有用的，因為，客戶永遠都會有第 101 個意想不到的需求！

既然如此，就乾脆讓客戶端可以自行開發他們的需求，未嘗不可！ 學學 MS 的 .NET Framework、Java 陣營的 J2EE Framework，以上兩者提供的是作業系統層級的框架(System-level frameworks)，而開發如 ERP 產品，就是提供企業層級的框架(Business-level frameworks)，讓開發者視需求的變動與要求，而在既有的基礎建設(Infrastructure)上，加工快速建置新的功能。

企業層級的 Framework，除了提供共用的資料庫、共用的企業流程，還要能提供白箱的 Open-APIs 與原始碼，以及黑箱的 『企業元件(Business Components)』，來供其客製化客戶單位的功能。難不難？ 非常地困難！ Business Framework 的設計與開發，需要能結合領域專家、軟體專家、與平台面的 IT 專家，共同合力協助，才有可能完成的。這也是為什麼國外頂級的 PDM((Product Data Management)產品與國內某些軟體公司所開發號稱的 PDM 產品，價格為何能差到數百萬元之多吧。

對了，Open-source 的許多企業層級的專案，可否稱之為產品？ 個人是不以為然，還是無法到這樣的層次。但，Open-source 卻靠兩種方式，來達成如同產品的性質：

• 頻繁的改版。
• 提供原始程式碼(Source-codes)。

這是一種非常有意思與另類的作法，此時，軟體廠商反而不是賣產品，而改以提供 『服務(services)』 的方式來計價收費了。

看一看我的 Blog ，竟然有兩個星期沒有寫新文章了，呼，好像是我的 Blog 『開張』 以來，第一次這麼長的期間沒有更新 Blog 內容了。為自己找個理由？ 因為，我沒有時間、我很忙，乾脆承認：想不出來要寫什麼…

為什麼會想不出？ 最近好像沒有什麼想法在腦袋裡；為什麼會沒有想法？ 其實呢，我是有許多主題，是關於軟體設計與其它一些學習面的想法的，但是… 每當想要斟酌一些文字與圖形的表達，想到要如何才能表達得比較好，就有些逃避的心態，也就一而再地推研了。

寫 Blog 心態首重的是：沒有壓力！

若有壓力，就會想要把它給寫好，就怕被批判，就因此而瞻前顧後，然後久而久之，也就動不了筆了。

即使如我寫了兩年多，即使我的心態算是建立得不錯，臉皮也算夠厚，也蠻敢被批判。但，我還是會有隱含這種求完美的心態，這很糟糕，求完美的心態是阻礙你創意思考表達出來的最大敵人！

嗯，決定了，堅決要改掉事事求完美與正確的心態，不正確又怎樣？ Who Care? 「日行一 Blog」，這比較重要。

報名與詳細課程資訊請至：
http://www.hsdc.com.tw/modules/eguide/event.php?eid=19

想知道如何將軟體作軟嗎？ 想瞭解如何運用前輩們的智慧結晶與設計法則 (Design Patterns)，來協助您如何解決現實設計所面臨的困境與難題，甚而，更進一步，能進而活用與創造出所屬自己與團隊的 『設計模式』 嗎？

擔心一天聽不懂與吸收不及？ 不用擔心，本系列所有單元課程均免費保留學員重新選修旁聽乙次的權利，並可以透過討論區發表您的問題，HSDc. 顧問與講師群們均會樂意協助您解決問題的。

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

繼 2006/05 第一場的「軟體設計鮮思維」研討會得到眾多學員們的熱烈支持與肯定，第二次的研討會也定於 07/15(星期六) 舉辦。

本次賴信仁先生與樹頭鳥先生(筆名)將主講 Java Spring Framework 在軟體設計的應用與範例，精彩可期，另，Kenming Wang 將介紹由 OMG 所為 UML 推出的國際認證課程，也同時說明由 HSDc. 所準備編製中的教材，是如何涵蓋 OCUP 的考試範圍與與科目的重點。敬請期待！！

基於成本問題，我們需要擔負包括大型會議室租借、光碟製作、點心茶水 …等費用支出，不得已需要向報名學員，酌收少於電影票一半的研討費用 ＮＴ＄１５０，我們的回饋會是講師群們的用心，將其專業的見解與體會，分享給研討會的學員們，當然，參加學員們也會拿到光碟片，內含了收集歷屆講座的內容與 EA 試用軟體及操作範例(Flash)等，絕對是物超所值的。

＊＊ 請注意，由於需要保留及計算報名學員們的座位，請確定會前來參加後才填寫報名單，若不克前來，也請於報名表單或來信取消報名。若報名人數尚未滿額(每場人數以 70 人為限)，則不及報名者，也可以現場報名。

• 講座主題：
  1. Spring Framework 初探 — 賴信仁(Ringle Lai)
     1. Spring架構簡介
     2. Spring的AOP
     3. Spring的MVC
     4. 簡單範例實作Spring
     5. Spring進階特性介紹
  2. [輕裝迅捷的 J2EE 戰略思考與戰術運用 : 奧瑪哈灘頭 - 搶救 J2EE 大兵] — 樹頭孤頭鳥(Tommy Lin)
     1. 從 Responsibility Assignmant 看 Core J2EE Design Patterns 鐵三角 – Application Service,Domain Object,DAO
     2. Spring Framework 諾曼地大反攻 — Refactoring to
        IOC + DAO Framework for Hibernate + Fine-Grained Domain Object + Declarative Transaction (AOP) + …
  3. OMG UML OCUP 認證介紹與說明 — 王克明(Kenming Wang)
     • UML Exams Coverage Map
       1. Foundmental
       2. Intermediate
       3. Advanced
     • 取得 OCUP 認證的優勢。
     • 關於 OCUP 考試的重點與教材資訊。
     • 關於 OCUP 認證考試的準備與報名。
• 時間：2006/07/15 (星期六) PM13:10 ~ PM 17:00 (三小時的講座時間，並留半小時供學員提問) 
• 對象：對軟體設計有興趣者，包括在職軟體開發人員及相關資訊科系講師及學生等。 
• 地點：開羅會議中心。
  地址：台北市光復南路65號B2 (光復南路、市民大道交接口)。 請參考交通與地圖。
• 主辦單位：HSDc 軟體設計顧問團隊 
• 講師：王克明(Kenming Wang)、賴信仁(Ringle Lai)、客座講師 樹頭孤頭鳥(Tommy Lin)
• 報名方式：請填寫報名活動內的表格內容，包括姓名、公司/職稱、聯絡電話、Email、等，採現場繳費方式。
• 服務信箱與電話：Email: service.hsdc@gmail.com TEL: 02-27227179
• 備註：
  1. 本次講座預計開放 70 個名額。(額滿即停止報名)
  2. 因上課人數眾多，恕不直接提供列印教材。本次講座會直接附送「講座教材及示範操作光碟」等。學員可自行列印講座教材。

老實說，我還真不敢相信，這是我們家蓁妮昨天晚上利用我的筆記型電腦上網所寫出來的文章，實在… 看不出是小四女生的文筆，我們家蓁妮的心智也未免太成熟了點吧？

文章內容引言我們蓁妮自己申請的「monocute 布拉格」Blog 網站。

朋友？死黨？戀人……..
今天就來談談…
朋友、死黨和戀人吧。

我們大家都有朋友的，
一旦朋友的關係破裂，
就很難挽救回來。
我們大家『至少』會有一個死黨，
『死黨』就代表A跟B的關係超越了一般『朋友』的友情。
戀人也就是你喜歡的人囉。

愛情有不同的滋味，
難受、痛苦、開心、快樂，
這些心情都會在漫長的愛情旅途中出現，
有時在旅途會碰到岔路，不該如何是好？
有時還會碰到斷崖，痛苦的結束旅途。
有時會有敵人也踏上了這旅途，爭奪第一，
一個一個淘汰，一個一個摔下山崖。
當然，最好的結果就是摘到最美的花，
愛情也就有了最美、最好的結果。

那朋友和死黨呢？
可能會意外的成為情敵，
使A跟B的關係惡化。
可能也會不再聯絡，
從此兩個就沒音訊。
也可能兩個人恰巧的上同一所學校，
開心得不得了！
不然就是A或B要搬家、轉學等，
大家都傷心的離去。
不過，不用擔心，
不是每個朋友都會這樣，
至少，妳還是會開心的活下去，
至少，妳的朋友不只一個，
至少，他們都會記得你……

所以，
朋友、死黨和戀人，
這三個妳覺得那個最重要呢？
記住，
只要忽略了一點點，
或重視的更多，
結果也會不同，
要怎麼安排是你的權力，
不過就看妳覺得哪一個比較重要囉！