又是資策會的課程@關稅總局

與「資策會」幾年來沒有往來,結果這個月反而教授了「資策會」兩個單位的 UML 基礎培訓課程。上一次那個課程是在資策會的教育訓練中心,而這次反而是到其客戶單位-關稅總局 授課。

只有三個小時、應該算是基礎性的概念與工具介紹。地點是在塔城街那邊,導航設定到達地點後才知道原來是那個「串珠街」的隔壁街。

中午在塔城、長安西路旁,有家「四川麵王」,點了紅油抄手與小菜。小辣 (可以指定)的抄手很好吃耶,讓我有些訝異,長這麼大竟然沒吃過這種東西啦。

提早了半個小時到,沒想到進到大樓後 (當然有辦證件),還被某一個看來應該較高層級的老主管叫住做身分盤查。挖哩,我到過許多軍方單位也從來沒有被這樣質詢過哩。

結果害我被驚嚇到,所以一開始上課時正襟危坐,認真的授課。問題是,當我認真時,就會很容易照本宣科、依照教材唸著給學員們聽。這樣的氣氛最沉悶了,其實學員也不容易得到想知道的。這樣經過了 30 分鐘,總算慢慢放開,再透過互動的過程中以了解關鍵學員的需求,再來調整授課內容。

喔,與上一次授課的團隊也有些類似,客戶單位已有了具國際標準的 XML 資料交換規格,他們希望了解如何透過 UML 工具自動轉換至類別 (class)的結構圖。

閱讀全文 »

一整天台中中科院的軟體授課 (2010-08~)

今天一整天,是到位於台中西屯區的「中山科學研究院」教授同是 18Hrs 的 UML 暨軟體設計基礎培訓課程。

早上 5:00 準時起床,刷牙梳洗完畢後開車到「麥當勞」買早餐+咖啡外帶,5:45 從「中和交流道」上北二高。一大早開車上高速高路的好處就是,車子只有稀疏的少數幾輛,所以不太需要與之爭道、超車,順暢得很;尤其是過了竹南算是中二高的路段,那更是看不到幾輛車,不知不覺就會開超速的狀態 (不方便提開到幾公里)。所以,整 7:00 就下了「沙鹿交流道」,我那個導航所標示的距離約為 142 公里總長。

下交流道後往大雅方向開過去,開一陣子後導航有指向往西屯的方向。反而下來後因為陸續有上班的汽機車,且速限可要注意,我記得幾年前就是這個路段被開了一張紅單。所以花了半小時的時間才到達導航所指的目的地。

因為提早到達 (這樣也會比較安心),所以先在車上小憩一下,然後約 8:05 時打電話給承辦人。結果啊,等了半個多小時都等不到人,原來,我等的那個地點不是中科院的會客室啦。還有,我那個 TomTom 導航,好像很順的指到目的地位置,但其實給指錯了,竟然是指到「逢甲大學」的側門啦。

一番折騰,再電話聯絡,才總算找到地圖上根本沒有地址的中科院,辦了證件、走到要上課的大樓,已是約 8:45 左右。本來以為遲到了,結果啦,他們說是 9:00 才開始。所以,我幹嘛那麼早起? 我幹嘛找錯地方,多耗上快兩個小時耶。

「中科院」應算是個軍事單位,其實早在五年多前就已經在龍潭總部那邊一、二所教過課,不過台中這邊倒是第一次。上課的學員可都是掛有軍階的,最少都是從少校起跳的,所以我都嘛稱呼各位學員長官好 (以前退伍時是中尉三級)。

上課的教材其實與我上星期在「資策會」的內容一模一樣,不過,我從來都不會照本宣科照教材授課。先前提過,我會先觀察學員們的反應來調整內容與進度,也會視他們現實上的需求動態變更上課的內容。

所以,整個課程教授下來,反而是從軟體開發流程與開發腳色的定位開始切入,再來才提及主要的開發產出,以及這些產出之間的關連與橋接。最後,才切回到教材的正題,並示範當場在課堂上做的簡單訪談,展示如何快速的建立需求分析模型,並準備轉而到下一個開發階段。

還不錯,各位學員長官們的接受度還蠻高的。主要是他們一般已具備有 OOP 實作的底子,實際上也已開發了不少軍方客戶委由開發的專案。所以甚至對於 EA 這類 UML 工具,示範一次他們很快就可以上手,還直說這個工具還挺容易用,所以,呵呵,他們也準備要編一筆預算來採購我們所代理的 EA 工具。

一整天下來的授課,講話足足有六個多小時,不過還挺不錯的感覺,精神都還挺好。尤其那個承辦人算是對今天所授課的內容與講解的觀念,給予挺正面的肯定。還說勒,先前他們有請過某科技大學的教授講解 UML 觀念,不過今天這樣聽下來,總算對其背後蘊藏軟體設計的觀念,才真正有了一番認識。哈,這算是鼓勵還是?....

閱讀全文 »

到資策會教授資策會團隊 UML 課程~

我教授軟體設計相關課程至少有六、七年以上了吧?稍有些意外的是上個星期五才是第一次教授到資策會的團隊。教授的課程只是基礎的 UML 與 EA 工具使用的觀念引導。

這算是企業包班的課程,所以上課地點就是位於在資策會復興南、信義路口的教育訓練中心。距離上次來此已有四年了,因為四年前就是來這裡考 UML OCUP 認證,詳見:通過 OMG UML OCUP Fundamental 認證考試。不過,才上個月就已來過該棟大樓,拜訪位於樓上的「手機王」洽談專案開發的輔導事宜。

一整天的課程,早上我開車到位於「大安高工」後面的巷道內找車位。才 8:40 就找到車位,9:30 才上課,所以就到了馬路對面的 StarBucks 吃早餐。

早餐有雜糧麵包、沙拉,以及我喜愛的榛果拿鐵,大概花上 NT$100 餘元。到了 2F 坐下來用餐,乖乖,幾乎是客滿耶!這個時候該算是上班時間吧?所以看來悠哉的人也多了。在這裡用餐,一口一口的麵包,啜飲著咖啡,聽著音樂 (喔,還有幾個蠻時尚的女孩 😉 ),感覺上這樣的品味生活、步調不要那麼快急,也比較自在愉快的。

快到上課時就過去2F的教育中心,已經有幾個學員在裡面了。學員們大部都很年輕,甚而還有國防役的。我教課算是比較容易與學員打成一片,然後在課程教授的過程中,會調整內容與上課的節奏。期間才逐漸知道,原來他們不僅希望了解基礎的開發流程概念,同時也希望講師可以協助他們解讀國外某一個電訊交換領域的 UML 模型,是利用 EA 工具所設計規範的類別 (Class)圖模型。

閱讀全文 »

[轉貼] EA 與 Visio UML 工具比較

這一份 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 小姐所整理出來的比較表:

閱讀全文 »

程式碼與 UML 類別_循序圖 的關係探討-完結 (4)

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

  • 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
    (點擊圖片鏈接看原圖)圖、安裝 Seq. Generator plugin

  2. 閱讀全文 »

程式碼與 UML 類別_循序圖 的關係探討 (3)

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

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

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

  • 動態產出:設定 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)

軟體思維顧問

專職軟體輔導與教育訓練的獨立顧問。輔導企業資訊單位如何有效組織系統開發與維護;輔導開發人員達成有效的專業分工。傳授如何把軟體作軟 (Keeping Software Soft)的技能,得以提昇系統的彈性/延展,並進而創造系統的再利用價值。

Personal