這一份 EA (Enterprise Architect) 與 Visio 的比較表，是由我們 HSDc. Cathy 小姐找了許多資料，用心所整理出來的功能比 較表。

EA 怎麼會與 Visio 來作比較？ 其實這是國內某大銀行 IT高級主管所要求的，必須附在產品採購內的評估報告。

一開始的直覺是，這兩樣能作比較嗎？ Visio 算是一種繪圖製作的工具，提供了諸多各類型，包括網路、基本流程、甘特圖、乃至於 Mindmap, UML 等圖形元件 (Widgets)的模版 (Template)：而 EA 則當然是 UML 專業設計的工具。

但是，我還真問了許多已經使用過這類如 EA, RSA (Rational Software Architect), Together 等工具的軟體開發者 (Developer)，到底與 Visio 的主要差異為何，沒想到絕大部分還真回答不出來，以為就是在繪製 UML 圖形的便利性與否而已。

不然！ 其實以 EA 這等專業 UML 工具，為何售價需要近萬元？ 必然是有 Visio、或者一般免費 UML 工具所無法比擬的特點。但可不是繪圖容易與否這類問題上，真正的主要差異在於：

• 有效調和專案 (Project)開發過程中，不同角色 (Role)的開發者所設計出來的 UML 產出 (Artifacts)，並在這些產出之間，有效監控並期能保持一致性。

更簡而言之來說，當專案是需要團隊協同開發時，則專業性的 UML 工具則是有其必要的，且更能有效保存軟體開發過程中的設計產出，成為團隊甚或企業的有效資產。

至於 EA 與 Visio 兩者的ㄧ些主要功能差異，則可以參考底下 Cathy 小姐所整理出來的比較表：

支援自動產出循序圖的工具

• EA (Enterprise Architect) 8.x－內建動態產出循序圖的機制。
• Together, RSA, Flowchart4j(c#) －支持靜態產出循序圖的方式。
• HSDc. Sequence Genenator (名稱暫訂)
  • 實作於 EA 7.x-8.x Plugin。
  • 支持靜態產出循序圖的方式。
  • 可支持正向/反向 將程式碼/循序圖互轉的功能。

HSDc Seq. Generator plugin 操作示範

1. 安裝 Seq. Generator plugin

   
   （點擊圖片鏈接看原圖）圖、安裝 Seq. Generator plugin
   

程式碼與循序圖的正反向工程

先瞭解一個重點：靜態程式碼結構並無法直接對應循序圖 (對應的是類別圖)。

兩種方法可以產出循序圖：

• 動態產出：設定 run-time 環境，實際執行應用程式，再由 UML 工具至系統內追蹤解析。
• 靜態產出：直接掃瞄程式碼，解析物件之間的參考 (reference)。

動態產出循序圖的優缺點：

• 優點：
  • 不需要程式原始碼，只要具有能直接執行的應用程式 (如 .NET DLL 執行檔)即可。
  • 可以確實捕捉單一程序內，物件之間的呼叫情形。
• 缺點：
  • 需要事先設定好可以執行該應用程式的 run-time 環境。設定相當複雜繁瑣 (一般需為命令列模式)，且不同的程式語言 (如 C#NET, Java, PHP …等)均須各自設定不同的 run-time 執行環境。
  • 只能呈現單一執行路徑內的物件互動。意即，無法呈現如 If…Then…Else 或 Exception 等多種條件或替代路徑。

靜態產出循序圖的優缺點：

• 優點：
  • 不需要設定繁瑣的 run-time 執行環境，操作相當簡潔。
  • 可以指定所掃瞄的程式碼深度 (層次)。
  • 可以同時呈現多重的條件或替代路徑的物件呼叫互動情形。
• 缺點：
  • 需要有原始程式碼，以提供靜態掃瞄的來源依據。
  • 轉換工具的實作邏輯並無明確的轉換 (transform)規則；相對來說，需要考量到程式語言個別的機制與語法，故轉換工具的實作難度相對提高。

※ 延伸參考
o　程 式碼與 UML 類別_循序圖 的關係探討 (1)。
o　程 式碼與 UML 類別_循序圖 的關係探討 (2)。

程式碼與 UML 設計圖之間的關聯性

從抽象的角度思考 類別(Class)/物件(Object) 的關係

• 物件是活的！
• 但是，類別可不是死的 (更不是活的)；因為，它僅是對系統的設計契約而已。

問題思考！？
程式原始碼 (Source Code) 對應的是 UML 哪一張設計圖？

推導－1
程式碼 = 靜態結構 = 設計契約 = 類別設計

所以 程式碼 對應的是：UML 類別圖 (Class Diagram)。

Ex. 程式碼與類別圖的對應

範例－程式碼與類別圖的對應關係

使用 UML 類別圖 (Class Diagram)的好處

• 快速定義類別的結構 (包括類別名稱、屬性與行為)。
• 過濾程式碼實做的細節，容易聚焦於類別的責任分派 (responsibility assign)設計議題。
• 可以透過工具，將類別圖轉出至對應的程式碼 (反之亦然)骨架 (skeleton)。

類別圖無法作到 …

• 無法呈現系統執行期間 (run-time)，程序單位之間的呼叫情形。
• 無法追蹤為完成某一特定功能案例，物件之間的動態相依呼叫關係。
• 無法掃瞄物件之間的動態連結，是否有違背類別圖的結構設計。

基礎觀念導引 － 何謂靜態與動態？

靜態結構 (Static Structure)

• 表達軟體內部的結構設計。
• 一般指程式原始碼 (Source Code)。
• 軟體人員對資訊系統的設計契約 (Design Contract)。

靜態結構的設計契約

public class myclass {
public void method_1() {
//do something
}
 
public string method_2(string var) {
//return a string
return var;
}
}

誰來解讀設計契約？

• 一般指軟體資訊系統或應用軟體伺服器 (Application Server)。
• ie. 可以編譯 C#.NET 程式碼 (設計契約)並能在 .NET 平台上執行應用程式。
• 可以編譯 Java Spring 程式碼並能在支持 JEE (Java Enterprise Edition)平台執行完成編譯的應用程式。

動態相依 (Dynamic Dependency)

• 系統在執行某一特定功能時，所啟始不同的程序單元之間呼叫的一種動態相依關係。
• 一般指程式碼經過編譯後在執行期間 (run-time)的應用程式。
• 資訊系統履行軟體人員的設計契約，使之可以在其平台上執行。

上個星期六、日，我們團隊連著兩天舉辦了「讀書會」與「單 元課程(一日遊)」等活動。

星期六，讀書會場地是選在位於通化街的「曼德 主廚私房料理」。一邊心得分享與研討、同時可以享受飲食與咖啡下午茶，這樣也比較輕鬆沒有壓力。

我們 HSDc. Inc. 本年度完整的軟件設計培訓，預定於今年 5/01(星期六)舉辦。使用的開發環境為 C#.NET + UML 2.0。 (但 Java 族群組亦可參加，因下次課程即會輪流改為 Java，且可再次免費旁聽)

歡迎報名上課，價格超級便宜，且可充實軟體設計整體性的觀念與知識，又能與講師、同學們等相互討論交流，好處多多。

課程與報名資訊：
[軟 件培訓] 系統分析設計與實作—活用 UML 塑模 與 C#.NET (05/01, ５４ Hrs)

　o 日期：2010/0５/0１ 起，每週六白天。
每次上課為六個小時(AM 9:30~PM 4:30)，共九個星期。
o 預定上課日期：05/01, 05/08, 05/15, 05/22, 05/29, 06/05, 06/12, 06/19, 06/26
o 地點：中國生產力中心，台北市承德路二段81號B1(首府經貿大樓)。
http://www.cpc.tw/Train/Place.aspx
o 特價優惠：NT$14,800, 含稅。舊生或三人同行再折扣為: NT$1３,４00。
(同等課程原價學費為 ＄30,000 以上)
o 附贈完整系統分析文件範本 (Word 格式)與可執行的 C# 程式原始碼。
o 贈送 UML 著書：UML 協同合作與管理(已有可抵優惠 NT$400)。
http://www.kenming.idv.tw/bk_uml-collaboration-process-and-management
o 免費送 Linux 軟體開發平台 DVD 光碟。(使用 Wine 安裝 .NET 開發平台)
http://www.kenming.idv.tw/signup-system-analysis-course-send-linux-development-dvd
o 同課程可保留再旁聽乙次的權利
(.NET/J2EE 系統分析課程均可。報名時註明舊生旁聽即可)。
o 下午均附有免費從外特別特購精緻的咖啡與點心。

HSDc. 於 2010 年度推出了完整的系統分析、設計至實作的課程，期能協助軟體開發人員在現實的工作中，能瞭解完整的開發流程與各個角色的工作執掌與產出。在基於以架構為中 心來建立團隊具共識的整體觀下，能聚焦在適切開發單位的功能點內，快速地從需求分析導出到實作，找出並克服開發過程中，包括溝通、技能與技術等風險因子。 而後基於這樣的框架目標內，得以對系統的結構作重整，卻又不至於影響已有的功能前提下，得以對程式碼施以重構的技巧，讓系統更有延展度與彈性。

傳統系統分析與設計的課程，經常是「昧於現實」，將需求分析/結構設計與程式碼實作拉得太遠，而造成軟體設計與實作的不一致。殊不知，所謂的軟體塑 模與程式碼的實作必然是軟體系統的一體兩面，在軟體開發過程中，必然是要保持一致性，所以設計是要作精，而不是籠統的文件報告。關於文件，只是利用工具的 文件產出功能，將平時已確實所作的設計，產出美輪美奐的文件報表而已。不要為文件而文件，還去加班熬夜，傷了身體，又浪費生命在不必要的地方，實在沒有意 義。

還有系統開發與實作也不是「妥於現實」，利用 IDE 工具從 Web/Windows Form 直接連接資料庫的這種開發方式，只是讓軟體人員變得更笨，只要需求變動就導致牽一髮而動全身，系統是不會有任何的延展與彈性的。最起碼的一點設計良心，又 能處在國內嚴苛的環境中，對於短線時程的專案，先將系統的命脈—企業邏輯的核心，全給統籌集中在中間層，也就是企業邏輯層—先求有！ 再來才是求好！— 待系統能確實上線，能滿足使用者的需求後，再則老闆與客戶對開發團隊有了信心，肯給予更多的資源—包括人跟錢，團隊的技能也有了增長與更好的溝通默契。外 在與內涵的條件均俱足下，就可以專致於對系統結構的重整，並對程式碼施以重構的技巧，而又不會影響既有的功能前提下，讓系統更具可重用性與延展性，甚而轉 成產品以服務更多同類型性質的客戶，又能快速的客製化每一個單位的特殊化需求。

基於這樣的理念，我們主張系統分析與設計是要「務實」，不是「昧於現實」，也不是「妥於現實」，而是在現實與理想中找到那一個平衡點。所以課程規劃 是分為兩個階段。

第一個階段就是捕捉系統功能需求，快速設計，立即產出程式碼。重點就是要瞭解如何作好系統的需求分析與對應到程式碼的實作。本階段需要培訓的技能有 物件導向的基礎知識、從使用者角度看待系統時的外部功能分析，抓出適切的功能點開發單位、從畫面、中間層物件到連結資料庫的實作能力等。還有，一定要配套 的兩個設計措施，一為撰寫測試案例與功能測試程式碼，實現自動化的測試機制；另一為活用分析類別，先利用中間層的控制類別，集中與控管從畫面與資料庫而來 的企業邏輯。

第二個階段就是傳統系統分析所說的 SD(System Design), 傳統是以資料庫的 E-R(Entity-Relation) 分析，在物件導向則是稱為領域模型的建立—包括找出物件與適切的分派責任。這可不是一件容易的事，事實上應該說要具備的抽象能力要相當高，所以為何我們覺 得那種 SA->SD->PG 開發流程是不務實的，因為 SD 很難作得好，然後還要 PG 去等該階段的產出，又大部分是不正確，可以說是浪費開發資源與時間。程式碼可以直接反應功能的需求，但不一定要等結構分析，集中在控制控制類別的好處就 是，我們可以很容易地對結構作重整、對程式碼作重構，卻又不會影響既有上線的功能。本階段的重點當然就是對所謂結構的分析技能培養，我們會兩種方式，一為 從需求抓名詞的傳統方法、另一為揭露出以交易為核心的交易樣式，可以輕易地抓出一大串的企業元件。

總的來說：作好功能需求分析-> 影響系統能不能做出來 ；
作好結構分析-> 影響系統有沒有彈性

觀念的傳授、設計的圖形化塑模表達、程式碼的實作三層次，是我們對於系統分析設計與實作課程的基本原則與態度。修習本次系統分析的學員們，也可以拿 到完整的教材、完整案例的 Model 檔與實作程式碼的對應。程式碼是以 C#.NET 再搭配最夯的 LINQ Framework，當然，要直接對應 .NET 的實作程式碼，那也是相當直覺不是難事。我們期能讓學員們上完課後，能以我們所提供的案例，包括設計模型與程式碼，當成範本而可以應用於工作實務上，甚而 可以創造所屬自己的 "Pattern"。

HSDc. 軟體團隊，關心每一位軟體人員的持續成長．．．。

 

過年前，我們團隊 (HSDc Inc.)所舉辦的 [UML 2.0 觀念引導與實務操作入門] 課程，約有近 20位學員參加。其中，有一位相當高恌的女孩子就坐在最前座，上課的時候總是相當專心聽講作筆記。

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

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

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

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

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

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

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

線上報名與詳細課程資訊請至：
http://www.hsdc.com.tw/course/unit-course_automation-test-by-csharp_1day_20100328

　o 日期：2010/03/28 (星期日) AM 9:30 ~ PM 17:00 (共 6.5 小時)
o 地點：中國生產力中心，台北市承德路二段81號B1(首府經貿大樓)。
http://www.cpc.tw/Train/Place.aspx
o 費用：NT$1,800, 含稅。舊生或三人同行: NT$1,500。
o 同課程可保留再旁聽乙次的權利 (報名時註明舊生旁聽即可)。
o 下午均附有免費從外特購精緻的咖啡與點心。

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

TDD (Test-Driven Development)，測試先行的觀念已逐漸被軟體開發單位接受。但如何達成自動化的測試？要測試的是哪一類型程式？如何撰寫測試測試 ...等，可能一般 Developer 仍顯模糊。

HSDc. 團隊將多年來輔導諸多單位，並協助其撰寫測試程式的經驗，整理成範本。利用一天的時間，詳述說明從需求整理、測試案例，到整個測試程式的產出，每一個階段步驟除了有完整的圖文解說與程式碼以外，還設有階段完整的目標，以瞭解該階段實作的目的。

對於 Developer 而言，撰寫功能性物件的測試程式，如利用 NUnit or JUnit 等測試框架，是確保需求功能的正確性。

而對於 End User 而言，因直接面臨的是 GUI 畫面的操作，若有些高精確要求如政府標案等，往往連畫面的操作步驟都不得出錯，而導致開發團隊甚而還要撰寫畫面操作的詳述說明與撰寫數千條以上的圖型測試 案例報告，花了相當多的時間卻仍一再需要重複人工的操作，可說是浪費太多不必要的精力與人力了。

為了達成驗收交付的目的，圖形介面操作的自動化測試，在高度要求或大型的專案中仍是需要的。所以，在本次課程中，我們也會介紹如何利用 GUI 的測試框架，在 ASP.NET 的 Web 環境中，以達成自動操作圖形表單、自動輸入數據。

同時，我們也整合了從 GUI 的自動操作到按下按鍵、然後到後端的控制型功能物件 (Control Object)，由 NUnit 測試框架自動驗證需求功能的正確性。一氣呵成，全部自動化，花一次工即可。

本次課程是利用 C#.NET，相關的測試框架 (Watin and NUnit)均支援 .NET Framework。但測試的觀念與作法其實都是一樣的，要移轉到 Java 的環境下，也是相當輕而易舉，自然，本課程也是適合 Java 的 Developer 等。

上課學員除了收到本顧問團隊所親自撰寫的教材外，還可以拿到一片自動安裝的光碟，內含了教材電子文檔(PDF)、測試環境建置所有需要的應用軟件(全為免費)、案例分析的原始程式碼與測試程式碼等。以及涵蓋了 HSDc. 歷屆研討會簡報資料。

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

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