This page looks plain and unstyled because you're using a non-standard compliant browser. To see it in its best form, please visit upgrade to a browser that supports web standards. It's free and painless.

Kenming's 軟體設計思維 會員登入 會員註冊

如果,你的名片上的職稱掛的是 "工程師"、"程式設計師",會不會覺得這就好像是 IT 的基層? 甚至好像是被稱之為的 "IT 黑手"? 作的都是 "粗重" 的工作?

說 "黑手" 可能還太嚴重,我還記得,以前我待在某一個團隊時,團隊成員中,有一位是擔任專案管理職的資深 PM,經常就向我常抱怨說,老闆比較重視像你們這樣子懂技術的 "藍領"。 我還從不知道原來懂所謂的技術就是被歸類為叫做 "藍領" 的這個名詞? 當時實在很想問,那麼 "專案經理" 是什麼顏色的 "領"? 難道是 "白領" 嗎?

相信可能沒有多少人,尤其是所謂 "資深" 的人員,以在名片上只掛 "工程師/程式設計師" 為榮吧? 可能就是要翻個花樣,在職稱上寫上 "資深技術長"、"系統分析師"、"專案經理"、"軟體架構師(我就是掛這個,慚愧!)",會比較有光采的感覺吧?

但是我在「科技頑童沃茲尼克(可參考我的書評)」這本書的內容,讀到一段 沃茲 當時在個人自行研發出蘋果一號、二號時,面臨著是否要出來創業的重大抉擇。 當時他是在「惠普」工作,而且以在該企業上班為樂。他只想待在惠普公司設計電子計算機,而設計個人電腦僅是他業餘的嗜好而已,他計算要在惠普公司工作一輩子。

最主要的原因為何呢? 並不是因為工作穩定的關係,而是因為,惠普公司非常尊重「工程師」,它的營運並不全然是由行銷人員主導的。沃茲 認為,對像他這樣的工程師來說,世界上再也沒有比惠普更好的去處了。 所以,當時為了蘋果電腦要出來創業時的抉擇,雖然他認為他所設計的個人電腦的確很有可能引出有史以來最重大的一場革命,但是,他還是決定在惠普擔任全職的 工程師。

包括他的最佳夥伴 賈伯斯 也無法說服他。 到底理由為何呢? 原來,沃茲認為,當他們創辦一家公司後,他就得差遣別人做事,處理別人的工作、控制別人的工作。 沃茲從很久很久以前就決定,絕對不要變成掌權的人。

後來到底是如何說服 沃茲 的呢? (感謝,否則蘋果電腦的歷史很可能會改寫的) 賈伯斯發動了沃茲周遭的親朋好友極力說服沃茲,包括了父母親、哥哥、好朋友等。 但是一點都沒有用,沃茲仍決定待在惠普公司。 直到其中一位好朋友叫做 鮑姆 的打電話說服他說:

「你(指沃茲)可以當個工程師,然後成為經理人,並且賺大錢;或者你也可以當個工程師,而且繼續當工程師,然後賺大錢。」

也就是說,在創業之後,沃茲仍可以繼續當工程師,永遠可以一直待在組織的最基層當個工程師,一輩子都不需要升上去當主管。

哈,沃茲樂壞了,他正需要有人告訴他這樣的一段話,所以他最終被說服了,與賈伯斯共同創辦了蘋果電腦,而且真的如他所言,一輩子都是個基層工程師, 並且引以為傲。 所以,即使你的名片上掛的好像只是最基層的 "工程師/程式設計師" 頭銜,請記得,不需要與什麼經理人主管之類的來比較,也不需要去刻意想要未來要升到主管階級。 記得,你的職稱有個最偉大的同伴,而且一輩子都沒改過,永遠都是工程師。 那就是蘋果電腦的發明人 沃茲尼克! ;)

科技頑童沃茲尼克  科技頑童沃茲尼克
 -----------------------------------
 作者: 沃茲尼克、史密斯 /著
 譯者:王志仁、齊若蘭
 出版社:遠流
 ISBN: 9789573261179

內容簡介
本書是蘋果電腦發明人,蘋果公司共同創辦人沃茲尼克的自傳。

沃茲尼克是電子奇才,從小就開始接觸電子設備製造,11歲就設立自己的無線電發射電台,13歲就開始研究設計電腦。在大學讀書時,他與賈伯斯(Steve Jobs)認識,兩人於1976年建立了蘋果電腦公司。

他一手設計蘋果電腦一號和二號原型,因晶片更少可以把價格壓低;因介面容易,一般人可以操作使用,這兩個關鍵因素,帶動了全球個人電腦的普及應用浪潮,並連帶掀起電腦軟硬體產業的蓬勃發展;並迫使IBM 的 PC於1981年面世時也使用類似的介面設計,從此改變了整個電腦業的面貌。

媒體讚譽
20世紀經濟領域50位最有影響力人物……,沃茲尼克名列第五,他的貢獻表現在「創辦蘋果電腦,帶動全球個人電腦普及應用浪潮,並迫使IBM的個人電腦於一九八一年面市」。──《洛杉磯時報》

IT領域公認的十位最聰明的技術天才。 ──《eNet矽谷動力》

十大超級駭客之一。 ──Yesky網站

在矽谷,一個人要贏得好名聲遠比贏得大把的錢財要困難得多……,如果在矽谷還有唯一一位大家公認的「好人」,那麼這個人肯定非沃茲尼克莫屬。──《美國中文線上論壇》

一九七六年,沃茲尼克在車庫裡做出蘋果一號電腦,PC業的歷史從這一天開始算。──《經理人》月刊,王志仁報導

作者簡介
史蒂夫.沃茲尼克(Steve Wozniak)
.蘋果電腦發明人暨創辦人
.IT領域公認十位最聰明的技術天才
.20世紀影響全球經濟發展最關鍵的五人之一

沃茲尼克是電子奇才,從小就開始接觸電子設備製造,11歲就設立自己的無線電發射電台,13歲就開始研究設計電腦。在大學讀書時,他與賈伯斯(Steve Jobs)認識,兩人於1976年建立了蘋果電腦公司。

他一手設計蘋果電腦一號和二號原型,因晶片更少可以把價格壓低;因介面容易,一般人可以操作使用,這兩個關鍵因素,帶動了全球個人電腦的普及應用浪潮,並連帶掀起電腦軟硬體產業的蓬勃發展;並迫使IBM 的 PC於1981年面世時也使用類似的介面設計,從此改變了整個電腦業的面貌。

獲頒美國發明家名人堂、國家技術獎章、亨氏獎(對經濟發展有重大貢獻者)。

本書是我前年(2007)八月在台中大潤發裡的金石堂書局購買的。新書一推出就直接打七九折,這也是我願意在書局買的原因(否則我會到網路書局購買)。蠻厚的一本,不過,哇!! 看了以後欲罷不能,三天之內就把它給看完了,而最近又把本書拿出來重新回味。 可以說,這是我這幾年來看過最精彩的口述自傳,自傳的主角,就是真正從無到有作出蘋果電腦的發明人— Steve Woz,我這裡用到 "真正" 是因為真的是只有他一個人開發出蘋果電腦,也可以說是 沃茲 是現今個人電腦之父,完全不為過。從本書中,我看到 "真誠" 兩字,完全沒有包裝或歌功頌德,就是口述沃茲精彩有趣的人生。他不只是電子的天才,也是相當地享受生活中的樂趣—作他想作、玩他想玩的,至於金錢與名利,他真的沒那麼看重,我可以從本書感受得很明顯。

這一本書應該就是屬於 沃茲 本人的自傳,所以整本書的內容都是以口語化的方式來敘述的,完全充滿著第一人稱主觀的看法與想法,也可以說是相當地貼近 沃茲 本人從小到大的回憶與他的自身的觀感。 為什麼我這麼說呢? 因為有一個事件同時就出現在本書與「i 狂人賈伯斯」該書。 話說賈伯斯 "凹" 沃茲 幫他為當時 賈伯斯 任職的雅達利電玩公司,僅僅只利用四天的時間(i 狂人那本書是說一天,而正常來說,這樣的遊戲可得花掉工程師幾個月才能完成的),就寫了一個單人版的 "乓" 電視遊戲。 這個遊戲應該算是打磚塊的始祖吧,就是要能在電視上顯示,將磚塊把小白球回彈給球拍。 哈,我就曾在小六的時候,在一個蠻有錢的同學家,就玩到這個現在看起來好像極為單調、僅有黑白的遊戲,當時我們幾個同學可是搶著玩呢,樂此不彼! 結果 賈伯斯 拿到了這個開發遊戲專案的錢,好像是拿到 美金 $1000 以上,但騙說 沃茲 只有 $700,所以每個人平分 $350。 嘿,請記得喔,從頭到尾都是 沃茲 一個人開發的喔。(即使到了蘋果 1號/2號 的開發,也僅是 沃茲 一個人包辦硬體與軟體系統的開發) 後來呢? 事隔幾年之後,沃茲 知道了這件事,在 「i 狂人」那本書是說 沃茲 很傷心地哭了,並因此而疏遠 賈伯斯;但是這本自傳呢,沃茲是把這件事描述在 "充滿笑聲的快意人生" 的標題內,他有難過,但可沒有哭,並沒有把它看成多了不起的事。 不過,後述倒是有提到,沃茲 本人一直是道德觀感很重視,他不可能去騙朋友,但是朋友去騙他,他是覺得算還好。

還有,這本書也喚醒了我從小學時候對電子這個領域就產生高度的興趣,並立志爾後考取「台北工專電子科」,當為我的第一志願。 但是,要說我截至目前為止,我對過往的人生,最為遺憾的其中一件事就是,在五專時期混得太過離譜。 明明,電子是一門非常有趣的領域,甚至說真的,我一直覺得 電子與軟體 的本質都是一樣的 — 都是在作設計! 輸入—處理—輸出 (IPO, Input-Process-Output),只是一個是 "硬" 的元件;另一個是 "軟" 的元件。 甚至,軟體還比電子設計更為難的是,"輸入" 經常會變動,反而還不像電子這樣,都是硬的,算好邏輯、確實連接就能 Work 的。 但是在學生時期,實在我不知道是怎麼過的,甚至喔,連 "電阻" 是什麼我都不知道。 直到我看了本書,才突然思考到,電阻不就是會阻止電流流動量的一種元件嗎?

從本書你還可以瞭解到,沃茲 一直是把工程師視為是最大的光榮,是以身為工程師為傲的。 這好像又與國內多數人似乎覺得走往那個什麼專案管理、業務銷售等經理職的會比較光采,是完全不一樣的呢。 沃茲 還寫道:「工程的重要性是其它沒得比的,工程能把社會提升到新的層次,工程師可以改變全世界、改變很多人的生活方式。」 沃茲 還說:「他一直相信工程師是世界的核心人物,而且他認為他一輩子都會是個工程師,一輩子都會奉獻給工程事業。」

真的,職業無貴賤,不會純然是以薪水來比較的;我覺得,有價值的職業會是,能把你的熱情都持續投注在該領域,並且還能樂在其中。 我相信即使 沃茲 如果發明蘋果電腦沒有因此而賺到錢,他仍然還是會很快樂的。因為,他是一個技術狂,而且還是個藝術家!

※ 延伸閱讀ˇ【好書分享】i 狂人賈伯斯

參考我原來所寫的一篇:「談談 C#.NET 連結 DDE Server 的設計觀」。 使用 NDde 這個開放源碼,來包裹(Wrap) Win32 APIs 連結 DDE 的通訊底層,使得 .NET-based 的應用程式也可以很便利地連結 DDE Server。

利用幾天的時間,我寫了一個算是比較完整的 C# DDE 用戶端(Client)程式,可以確實連結國內券商所提供的看盤軟體(本身即是 DDE Server)。目前測過包括 "永豐金 eLeader", "元大 Yeswin", "日盛 HTS", "康合 全都賺" 等,均可以正常連結並依據連結項目(Item)持續顯示所跳動(Tick)的值(Value)。 這算是一個簡易的範本,旨在展示利用 .NET OOP 語言可以確實連結 Legacy DDE Server,並進而讓有心的程式交易人員,可以再行擴展,自行撰寫包括報表統計、技術線型分析 等應用。

CsDdeClient(Simple)_ScreenShot-02

我寫的這個簡單 DDE Client,基本功能如下:
 o 可以同時連結多個 DDE Server。
 o 可以同時顯示多個項目(Item)所持續跳動(Tick)的數值(Value)。
 o 可以正確顯示傳輸項目值為中文的編碼。
 o 可以任意地刪除 DDE 連線與項目 的相關資訊。

簡單的源碼說明

DDE 的連線

  1. 看盤軟體本身即為 DDE Server! 這點要先弄清楚。 所以看盤軟體連線至券商的報價伺服器,那是另外一回事,DDE Server 作得好不好,是與看盤軟體本身的穩定度與資源管理有關,而不是與遠端的報價伺服器有關。
  2. 看盤軟體需不需要啟動 Excel? 不需要的,Excel 本身就是 DDE 的用戶端(Client),而且也因為 Excel 的關係,使得任一券商的看盤軟體,都必須符合能讓 Excel 這個用戶端正確地顯示資料。 這個有趣,是 Server 端必須符合 Client 端的傳輸規格,而且不能亂搞。 所以相對來說,對於程式開發人員自行要寫 DDE Client 程式來說,就不用擔心能不能正常顯示所傳輸過來的數值,要是有問題,肯定是自己寫的程式有問題,也方便自行 DEBUG。
  3. DDE Client 要能新增一條 DDE 連線(Connection),建立互動的 Conversation,需要有兩個資訊,一為 "Service",另一為 "Topic"。 所以,所謂的一條 DDE Connection 定義為:
      1 DDE Connection = 1 Service + 1 Topic

    藉此也可以同時觀察,國內諸多看盤軟體他們對於所謂 DDE Connection 的實作方式。 例如 eLeader 是每一支股票代號即為一條 DDE 連線,所以,若要觀察前百大的期指成分股,就需要建立上百條的 DDE 連線;而 YesWin/康合 全都賺等看盤軟體,則是所有金融商品都只建立一條 DDE 連線而已。 這與穩定度及效能是否有關? 事實上,這應該是說牽涉到 DDE Server 內部關於 DDE 連線的資源控管(Resource Management)問題,一般來說,較為先進的應用伺服器(Application Server),都會提供諸如 "Connection Pooling" 的機制,來有效達成伺服器內資源上的協調。

  4. 連線很簡單,片段的程式碼參考如下:
    DdeClient dc = new DdeClient(service, topic);
    try{

    // Connect to the server. It must be running or an exception will be thrown.
    dc.Connect();

    }catch (Exception thrown){
    MessageBox.Show("無法連結 DDE Server:" + thrown.Message);
    }

向 DDE Server 索取資料

  • 建立可以相互對話的連線後,該條連線即為 "Stateful" 的狀態,Client 與 Server 可以互相傳遞資料。 Client 端向 DDE Server 要求資料有包括 "Request(同步)", "OnBeginRequest(非同步)", "Advise(通告)" 等幾種方式。 對於看盤軟體來說,最必要的就是 "Advise" 這個要求了,當 Client 發出 "StartAdvise" 這個訊息後,DDE Server 爾後只要針對該項目的值一有變更時,就會通知已註冊的 Client 來取得變更的值。

    至於另外兩種需求的訊息,"Poke" 是 Client 端主動送資料給 DDE Server;"Command" 是 Client 端發出命令要求 DDE Server 執行某個指令。 對於看盤軟體來說,是沒有使用到的,所以在我的源碼內,並沒有實作。

  • 國內幾個主要的看盤軟體,對於傳輸資料的實作,似乎有些差異 (但是在 Excel 都可以正常顯示)。 它們必然都有支援 "Advise" 這個訊息(Message),所以才能爾後持續地取得跳動的值。但是,我發現到,YesWin/HTS 這兩個兩個看盤軟體,如果盤後停止跳動時,DDEClient 只利用 "Advise" 這個訊息要求資料的話,是無法取得資料的(但也沒有錯誤);而相對 eLeader 與 全都賺來說,只利用這個訊息,就可以取得資料。 前面說過,Excel 卻都是可以正常顯示的,所以,我後來才加上 "Request" 這個同步要求資料的訊息,才使得所有的看盤軟體都能顯示當停止跳動時,也能取得第一次的值。

    衍生的一個小問題是,eLeader/全都賺 並沒有支持 "Request" 這個訊息的實作,所以若發出 "Request",會出現錯誤。 這裡我使用的一個小技巧就是,讓它 "throw" 一個例外錯誤(Exception)的 事件(Event),但捕捉(catch)了這個事件後,忽略並不處理它。

  • Client 端首先發出 "StartAdvise",通告 DDE Server 準備要求索取資料。 所帶的參數隻有一個,就是項目(Item)名稱。 至於 "Service", "Topic", "Item" 的名稱如何取得? 一般只要從看盤軟體中,對某個表單的畫面欄位,右鍵 Excel DDE 複製到 Excel 中,即可察看到。

    Client 端另外要做的一件事就是,註冊可以取得來自 DDE Server 所傳來事件(Event)的相關資訊,包括連線資訊與變動的資料等。 註冊的方式就是在 Client 端的程式碼內宣告並實作 Advise 的處理函式。部分的片段程式碼參考如下:

    dc.Advise += client_Advise; //register the Advise process event.
    dc.StartAdvise(item, 1, true, 60000); // Advise Loop


    private void client_Advise(object sender, DdeAdviseEventArgs args) {

    chg_value_row.Cells["col_iteminfo_value"].Value = args.Text; //顯示變動後的 Item 值.

    }

  • 事實上,後來請生魚片測試時,才發現到,中文編碼有問題! 我並沒有注意到,因為一般看盤軟體的數值都是純數字,但是 "康合 全都賺" 若要求如 期指的合約名稱,會傳回中文。 這裡相當感謝生魚片,他幫我解決了編碼傳輸的問題。 可以參考他寫的一篇:「在.NET正確顯示透過DDE傳送的文字編碼」。 所以在 client_Adivse() 這裡要改為:

    private void client_Advise(object sender, DdeAdviseEventArgs args) {
    int codepage = Encoding.Default.CodePage; //取得編碼的 codpage. 中文 Default: 950

    string data = Encoding.GetEncoding(codepage).GetString(args.Data, 0, args.Data.Length);
    chg_value_row.Cells["col_iteminfo_value"].Value = data;
    }


UI 的實作問題

老實說,真正困擾我的,是關於 UI 的實作,這對我可以說是相當陌生的。 UI 要能設計的好,大概有兩個重點, 一為對 事件(Event)的控管處理,另一個就是如何讓 UI元件(Component)與所繫結(Binding)的一到多個資料源(Data Source),並保持展示與資料變動的一致性。


在 Windows Form,大概就是 .NET 的 DataGridView 這個 UI 元件最為多樣變化了。如何與 資料源 "Binding" 在一起,維護展示與資料變動的一致性更是個學問。 目前我算是用 "硬作" 的方式,並沒有採取 "Auto Binding" 的自動同步,而是自己利用 HashTable,以 "Service+Topic", "Item" 當成主要的索引鍵(key),來找出相關於 DDE Connection, DataGridView 所在變動列(或欲刪除列)的位置。

這裡我就是利用 DataGrideView 元件來展示連線與項目等相關資訊的。 一個 Connection 可以 "Hold" 住多個 Item, 所以必然是 "Master/Detail" 這樣的呈現。 這個 UI 元件最為多樣變化了,如何與 資料源 "Binding" 在一起,維護展示與資料變動的一致性更是個學問。

目前我算是用 "硬作" 的方式,並沒有採取 "Auto Binding" 的自動同步,而是自己利用 HashTable,以 "Service+Topic", "Item" 當成主要的索引鍵(key),來找出相關於 DDE Connection, DataGridView 所在變動列(或欲刪除列)的位置。


※ 執行檔與原始程式碼:
我是上傳至 「聚財網」給有需要的程式交易人員參考研究。若需要該源碼,則需加入成為該網站的會員。

http://www.wearn.com/bbs/topic.asp?topic_id=139666&forum_id=5295&cat_id=19

打個廣告,這是我們 HSDc. 在 2009首先公佈推出的單元性課程。我這裡再特別註明一下,對於清寒家庭、尤其原來是家扶中心的報名學員,所有費用全免! 這也算是我們對社會的一個小小的回饋。

由於 1/10 補休假緣故,所以上課開始日期改為 1/11(星期日)。

各位好:
 
【台北場】UML 2.0 實務操作暨使用案例實作應用 2009/01/1,11,17 (日、六、日),共三日。
  * 本課程均保留與提供學員免費再旁聽乙次同樣課程的權利。

課程相關資訊: http://www.hsdc.com.tw/course_signup/20090110_uml2_guide_and_usecase_realization
-----------------------------------------------------------------------------
§課程說明
跨年(2009)後 HSDc. 首先推出的第一個單元課程,老少咸宜,也是軟體人所應該具備畫出(表達)軟體設計圖的能力。利用春節過年前的例假日時間,充實自己在專業上的能力,況且本 課程即在表達軟體設計可是生動活潑有趣的。學員又可以利用春節連假期間,依據我們所給的電子檔範例教學光碟,操作練習。多加充實自己在職場上工作的專業能 力,才能度過未來幾年經濟蕭條不景氣的年代。

想瞭解如何利用 UML 在正確的場合與時機,適切地表達你的軟體設計嗎? 想知道如何快速從需求分析導出到程式碼實作嗎?

本梯次的 UML 實務入門課程,應眾多學員反映與要求,原兩日的單元課程,延展為三日!除了將原來課程內容重整,利用一個完整的醫院系統開發案例,作為 UML 2.0 13 張圖的實例講解與 EA工具繪製實作練習,另外,我們也把原使用案例的單元課程給整合併入本系列課程內,除了讓學員能學會 13 張圖的綱要與設計要領外,還特別針對使用案例詳加講解。

我們為何對使用案例如此重視? 因為,學會如何寫使用案例,就可以直接從使用案例快速導出到程式碼實作,並能符合 MVC 的實體三層架構,效果甚佳,也可以說 能寫出程式碼才是學習 UML 設計的最佳信心來源!!

當然,招牌的案例研討—土地公廟許願系統的分析設計至實作,讓你知道原來從生活面的觀察,就可以很輕鬆、有趣地利用使用案例來記錄需求,然後依其物 件責任的分派,互動合作,以完成善男信女的許願。所有程式碼,包括套件、類別、變數、方法等,全都是本土中文化,完全可以執行!! 包括 C#.NET 與 Java 程式碼的範例,以及 UML 模型檔案,全部讓學員帶回去。

另外,我們還以一個紅綠燈控制器為例,來說明如何設計狀態機圖,並可以建立狀態轉移表,導出到實作。而狀態機圖,除了可以應用在嵌入式系統(Embedded Ssytem)的設計之外,它也可以說是複雜 UI 的事件—處理(Event-Handle)最佳設計表達。

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

-----------------------------------------------------------------------------

§課程名稱: UML 2.0 實務操作暨使用案例實作應用 (假日班)

§課程簡述:
 o 以 "問題-解決方案(Problem-Solution)" 的觀念傳授與實做方式,引導學員實際針對案例分析並利用 UML 工具畫出 UML 2.0 十三種圖。
 o 利用使用案例來捕捉系統的功能性需求,並快速導出到程式碼實作,以及撰寫測試程式碼驗證功能的正確性。

§課程目標:
 o 畫每一個 UML 圖之前,會先以一個問題的陳述,來說明應用該圖形的時機與場合,然後提出具體的解決方案。
 o 課程提供兩個案例,並涵蓋串連整個 UML 13 種圖。
 o 完全以實務為主,指導學員如何利用 EA(Enterprise Architect)學會畫 UML 2.0 的圖形。
 o 學員於課堂上實際親自操作 UML 工具,由講師示範與指導畫每一張圖的技巧與圖形的元素說明。
 o 瞭解如何描述使用案例(Use Case),如何寫出正確、易讀性高的使用案例,並提供寫使用案例的範本(Template),說明主要欄位的作用與寫作時基本的規範與考量。
 o 指導學員如何實現(Realize)使用案例,以簡單的循序圖設計,並利用 EA 的 "Code-generation" 工具來產出 .NET (or Java) 的程式碼,包括可被執行的應用程式碼,以及功能測試程式碼。(眼見為憑,是強化信心的利器,之後可再對系統結構施以 "重構" 的技巧。)

§課程特色:
 o 示範與引導學員實際操作與練習。
 o 第一日上課時即會發送給學員教學光碟,內容提供 EA 自動安裝與教材內容及範例。
 o 提供兩個完整的案例研討(Case Study),自然又流暢地整合:
  o UML 2.0 13張 設計圖 (包括企業流程、系統需求、內容結構、動態行為等構面)。
  o 提供 UML Model 檔(EA 7 格式)。
 o 本課程均保留與提供了學員免費再旁聽乙次同樣課程的權利,以一次低廉的收費,就可以擁有兩次上課的收穫,課程的師資、內容與品質,我們有信心是不會讓學員們失望的。

§準備教材:
 o 由授課講師提供講義,包括內容、案例分析與 UML 13 種圖範例(包括 Flash 影音檔案)。
 o 學員可攜帶相關 UML 參考書籍,並對於書中內容有問題者,可以直接提問。

§使用工具: EA(Enterprise Architect) 7.0(Trial) UML Tool。

§授課講師:
 o 賴信仁(Ringle Lai) ,王克明(Kenming Wang) ,宋敏如(Cathy Sung)
 o 擅長以非常淺顯易懂的比喻及說明,將複雜的系統抽絲剝繭,重新釐清脈絡,讓學員一清二楚,並善於引導學員具備設計應有的反思能力。

§上課時間:
 o 【台北場】2009/01/11,17,18 (星期日、六、日),共三日。
 o 每日上課為六個小時(AM 9:30~12:30、PM 1:30~4:30),課後並留半個小時供學員自由提問。

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

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

§由於本站線上報名系統尚未測試啟用,煩請報名學員填寫下列資料報名 (下列欄位前為 * 者請務必填寫),並以 Email 寄至: service.hsdc@gmail.com
  -------------------------------------------------------------------------------------
  * 姓名:
  * 電子郵件:
  * 聯絡電話:
  任職公司與職位:
  備註(請填上如 ATM 轉帳帳號(後五碼即可)與新生或舊生等資訊):
  -------------------------------------------------------------------------------------
o 報名經確認後,本站即會寄送確認通知信給報名學員。
o 為確保報名足額人數,煩請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
 ATM 帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
o 上課費用:
 1).$5,700 (含稅)。
 2).曾經上課過本公司的「單元系列課程」學員,優惠 $5,100,含稅。(請記得註明為舊生,本公司查詢確認即以優惠算)
 3).三人同行,或同時報名另一單元課程,亦比照舊生的優惠折扣,每位只需$5,100(含稅)。
 4).大學/研究所 資訊相關科系講師、助教或教授,出示相關證明,我們會以建教合作方式計費。(請另以電話聯絡)
 5).清貧或由家扶中心推薦,能出示相關證明,所有費用 免費!!
 6).曾上過前梯次之兩日 UML 實務入門的學員,僅需補一天教材工本費等,只需 $1,700。
§備註:
 o 教室設備包括白板與投影機,由講師親自說明與操作示範。(學員可攜帶錄音筆)
 o 學員最好能攜帶 Notebook,可以於課程中實際操作與練習。
 o 報名滿 10 名即確定開班,同時保留 5 名學員重新選修同一課程(請攜帶原上課講義)。開課前兩日會以電子郵件聯絡與通知學員。
 o 為確保報名足額人數,煩請先以 ATM 轉帳預約費用($1000),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
  (若實在不及轉帳者,仍可現場報名,但請在報名表內註明現場繳費)。
 o ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9

-------§附錄:課程表參考內容--------------------------------------------------
※ 基礎觀念引導—應用 UML 的正知與正覺
 o 使用 UML 的基本思維
 o 為何是利用 UML 來溝通
 o UML 塑模的對象
 o UML 設計圖的分類說明

※ UML 2.0 13張圖綜觀介紹 (Overview)
 o 表達企業流程與外部需求功能
  o 火箭(EEriksson-Penker) 業務流程擴充圖/活動(Activity)圖
  o 使用案例圖 (Use Case Diagram)
 o 表達系統的內部靜態結構
  o 類別(Class)圖/物件(Object)圖
  o 套件(Package)圖
  o 元件(Component)圖/複合結構(Composite Structure)圖
 o 表達系統內部的物件互動行為
  o 循序(Sequence)圖/溝通(Communication)圖
  o 互動概觀(Interaction Overview)圖
  o 狀態(State)圖/時序(Timing)圖
 o 其它性質的設計圖
  o 部署(Deployment)圖

※ 進階案例研討
 o 建構土地公廟許願系統的系統分析—從使用案例到循序圖到 C# and Java 程式碼
 o 從狀態機圖導出到程式碼
  o 如何繪製紅綠燈控制器的狀態機圖
  o 如何建構狀態轉移表
  o 從狀態轉移表轉出到程式碼
  o 成果展示—紅綠燈+方向指示的 UI 呈現

※ UML 2.0 實務操作練習 (利用 EA 7.0 工具)
 o EA (Enterprise Architect) 的安裝與使用介紹
 o Case Study: 以醫院系統開發為案例,涵蓋 13 張圖設計
  o 企業流程與系統需求的設計與實作練習
   o 火箭圖/活動圖 (看病業務流程的表達)
   o 使用案例圖 (住院/出院管理系統的功能需求)
  o 結構面設計的設計與實作練習
   o 類別圖/物件圖 (住院/出院管理系統的內部結構)
   o 套件圖 (分析類別的套件相依)
   o 元件圖 (企業元件的介面呼叫)
   o 複合結構圖 (住院/出院的功能介面與內部組件)
  o 行為面與其它的設計與實作練習
   o 循序圖/合作圖 (住院登記的物件互動)
   o 互動概觀圖 (住院登記的正常與替代流程)
   o 狀態圖/時序圖 (病床物件的狀態轉移)
   o 部署圖 (醫療系統的部署)
 o EA 的進階功能探索
  o 文件產出 (Document Generation)
  o 程式碼產出 (Code Generation)

※ 建立使用案例模型 (Use Case Model)
 o 利用使用案例圖表達系統的功能需求
  o 如何界定系統範圍(System Boundary)
  o 如何找出使用案例與參與者(Actor)
  o 使用案例之間的關係— include and extend
  o 利用使用案例圖表達架構觀點
   o 界定與分析使用案例模型的廣度的層次
   o 如何利用使用案例表達企業層次與應用系統面層次
   o 多個系統的使用案例圖架構設計
 o 從表達企業流程的活動圖導出到使用案例圖
 o 使用案例敘述(Description)的寫作實務
  o 如何寫出高品質的使用案例敘述
  o 如何依據使用案例範本完成使用案例敘述的撰寫
  o 如何表達正常、替代、擴充與例外事件流程的敘述
  o 寫好每一條動作步驟陳述的要領

※ 從使用案例導出到程式碼實作
  o 案例分析(Case Stydy) — 使用案例的實現(Realization)與實作(從使用案例到循序圖到產出程式碼)
  o 設計與創建 Use Case 控制物件,以實現使用案例的功能需求
  o 利用 EA "Code-generation" 功能產出控制物件的程式碼框架
  o 測試先行—在 IDE 工具內撰寫該控制物件的測試程式碼
  o 利用虛擬碼(Pseudo Code)撰寫程式碼內部的細節
  o 實際執行應用程式碼的部署與執行功能測試
  o 利用 EA 反向工程功能,在 IDE 環境內修改程式碼,並反轉(Reverse)回 UML Model。

※ 課程回顧複習、問題提問與討論。

---------------------------------------
§課程諮詢(HSDc. 軟體設計專業顧問團隊):
 o 諮詢專線:TEL: 02-27227179
 o 服務信箱:service.hsdc@gmail.com