Kenming’s 鮮思維

一個委外(Outsourcing)組織的結構範例圖

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

雙方的期望是什麼？

• 客戶端(發包單位)
  • On Schedule。
  • 系統符合所需要的功能與非功能性需求 (可以通過驗收測試)。
  • 契約內所議定的軟體設計規格(結構)。
  • 具堅固性(Robustness)、可擴充性(Scalability)、可測試性(Testability)的系統。
• ISV(承包單位)
  • 承諾專案所議定的契約內容。
  • 釐清需求，界定系統範圍。
  • 控制與侷限需求的變動在專案的範圍內。
  • 驗收的交付是可以被驗證的。
  • 合理的利潤 ～ 成本、品質、規模與時程的調和。

符合雙方期望的核心要素？

• 密切地溝通，釐清需求，界定系統開發範圍，議定系統的整體架構(Architecture)設計。
• 版本(Release)交付時的接受度(Acceptance)測試，或稱之為驗收測試、功能測試。
• 利用原型(Prototype)測試與驗證系統的結構性。

上星期六，我們(HSDc.)舉辦了第五次的免費 UML 系列講座。到場來聽講的學員約有八、九成滿，近 90 人左右。講座舉辦至今，每場報名人數均超過 100 多人，到場的學員們也約有 7 成滿，約有 1/3 的學員成為熟面孔，甚至有幾位成為不錯的朋友，不錯，蠻愉快，也有成就感。

當初我推動舉辦免費的 UML 講座的動機很單純，就只是藉由 UML 來分享我與團隊其他 partner 對軟體設計的心得。再則，給自己一些壓力，每個月要準備一個主題，鍛鍊思考與寫作，久而久之，自然就會變成一種習慣，同時也把這一系列的講座變成是國內在軟體專業設計研討的主要活動，這也蠻有趣的。

當然，也有私心，畢竟，我們團隊的定位在顧問與教育訓練的服務上，是需要』養分』的。藉由講座與研討會，有機會可以』推銷』我們自己，若有認同我們所著墨關於在軟體設計的觀念，也覺得我們可以協助學員個人的成長，甚至，也相信我們有這樣的能力可以協助 ISV 或 IT 部門關於軟體設計、製程規劃、技術移轉等等。我希望是一種 『互惠』，能確實因協助到他人或公司而有回饋，甚或，造成對軟體業界的一些些貢獻，我覺得，這樣才會能維持我對軟體的熱情與使命，

因緣際會，認識了在美國 JBoss 任職的 Ben Wang，他是領導 JBoss Clustering & JBossCache-Aop 的首席技術長，星期六告訴他我們有這樣的活動，也特別邀請他客串講演一場關於 JBoss Enterprise Middleware System (JEMS) 的架構介紹。

中午就與他見面，我們團隊所有成員與 Ben 一起在文大教育推廣部的餐廳用餐(真好吃)，相互交換許多心得，真好，收穫甚多，我們均有共識，覺得又有一波的軟體革命，也就是 『Open-Source』 的力量，這是無遠弗屆的，顛覆了太多商業經濟的模式，逐漸地讓產品導向推往服務導向的商業交易模式。

安排 Ben 在第三場講演，非常精彩，Ben 本人很認真，還利用中午時間修飾他的簡報。短短的 40 分鐘，大致勾勒出 JBoss 的 Business Model 與核心產品。我個人印象最深刻的是，JBoss 的使命宣言(Mission Statement)是：
利用最佳的 J2EE Applicaiton Server 提供給企業最佳的服務。

非常地明確！！ 也感受到 Ben 本人非常熱情於現在自己的工作，40% 研發(Research and Design)，60% 跑世界各地負責 Education Trainning。

Ben 因有事先行離開。我是負責最後一場，這次我所準備的主題是「活用狀態圖」，我花了約三天的時間同時看了五、六本書，感受到狀態圖是奇妙無窮，非常地有意思。甚至，讓我想到，可能有機會創造是軟體為主角、硬體是配角(與現在的市場剛好相反)的 『以軟帶硬』 的模式。

我也打算再多作一些研究，尤其是更具體地將狀態圖、狀態表的設計，轉成實際的程式碼。我打算，就將我對狀態圖的研究，規劃個約一天的課程來教授如何學會、活用及具體化狀態圖。

有一位學員，特地是從屏東到高雄小港機場坐飛機趕過來聽講，聽講完後馬上再坐飛機回南部。真讓我驚訝，也真讓我好佩服。還有一位任職於紡織業的 IT 主管，是自己一個人坐電動輪椅過來的。有許多這麼有心、認真的學員們，真的可以感受到他們對軟體的熱情與吸收專業知識的渴望。所以，更讓我覺得，每一場的講座，不能因為免費而隨便，用心地講述我們的心得與體會，也能有學員的互動回饋，並且讓學員們感受不虛此行。

幾位比較熟識的學員們，有些問題也希望能與我互動討論。我們約在隔壁的咖啡廳 『續戰』，聊到晚上 9 點多，東南西北，各種話題，都可以有得聊，挺有趣的。

回到家，已是 10 點多，我發現到，我的喉嚨沙啞了，因為，話講最多的永遠都是我。

我們家 Annie 畫了一張 A3-Size 的動物園畫畫，實在有趣、夠可愛、滑稽加無厘頭。

她要求我 scan 然後存入電腦內。嘿，我還需要 scan 兩次(A3 太大)，然後再利用軟體接圖起來，真是大工程。然後呢，我是雞婆了一點，幫 Annie 畫的動物園內的動物註記上動物種類，因為，我自己猜裡面畫的是什麼動物，總共只猜對兩種：大象與猴子，其它的呢，完全猜錯。(我還以為 Annie 畫的老虎是熊貓呢)。:crazy:

蓁妮一看到我幫 Annie scan，她馬上不甘示弱，從筆記本撕下一張稿紙，利用不到 10 分鐘的時間，畫了一張美少女天使的素描鉛筆畫，也要求我要存入電腦內。;)

小一采潔(Annie)的動物園鉛筆素描畫畫

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

小三蓁妮(Jenny)的美少女天使鉛筆素描

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

紅綠燈控制器的狀態圖與UI

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

說明

• 該控制器主要有三個狀態： 紅燈、綠燈與黃燈。
• 三個主要的狀態轉移是以定時器(Timer)來設定事件的觸發。
• 紅燈狀態內部又有兩個子狀態，一個是純紅燈訊號；另一個為紅燈+右轉燈訊號。兩個子狀態視交通情況而可以動態調整切換(Toggle)。
• 從黃燈訊號轉移回紅燈主狀態訊號時，會參考歷史狀態(H符號)來決定進入的是哪一個子狀態；若為第一次進入，則預設(箭頭所指向)為純紅燈訊號。

實做狀態圖轉程式碼的步驟

1. 利用 IDE 工具新增使用者介面物件 (UI Objects)。
2. 新增狀態變數 (State Variables)。
   • 每一個狀態均設定一個狀態編號。ex. 1, 2, 3…
   • 利用狀態變數來記錄同一階層(level)的狀態變化。
   • ex. 紅綠燈控制器利用狀態變數 A 紀錄目前所在的狀態(紅燈 or 綠燈 or 黃燈)。
3. 新增狀態程序 (ex. go_state_xx() )。
   • 實做一個 UI 控制(Control)物件，接收從 UI 物件所傳送的事件，並定義各狀態程序以處理接受的事件。
4. 實做定義於 “事件-行動(event-action)” 狀態表的狀態轉移。

繼續閱讀 »

圖、範例-刷票機控制器的狀態圖

Description

捷運站的刷票口，平常是處於 “關閉(Locked)” 狀態。當乘客欲進入閘門搭乘捷運時，必須插入票卡後，閘門才會打開(Unlocked 狀態)，而乘客通過後閘門即自動關閉。
有兩個異常的事件考量。若乘客未插入票卡而欲進入閘門，則會發出警告聲通知站務人員處理；另一是當乘客已插入票卡，閘門也已開啟，但乘客又再插入一次票卡，此時刷票機會自動退回(Reject)票卡。

先觀察狀態樣式的結構圖

圖、狀態樣式的基本結構圖(GOF, Design Pattern)

• 將某類別(Context)的狀態分解為獨立的類別(State)。
• Context 類別會持有一個 Concrete 子類別的個體，以代表現在的狀態。
• State 類別可被定義為抽類類別(Abstract Class)或介面(Interface)，負責封裝當 Context 特定狀態時所該展現的行為。
• 每一個子類別均會針對 Context 的某一個狀態來實做出該展現的行為。
• 新增狀態時，只要再根據其狀態來實做一個子類別即可。

利用狀態樣式實做範例狀態機

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

• TicketGate 類別實做 Lock、Unlock、Alarm、Reject 四個主要的活動(action)；TicketGateController 類別繼承了 TicketGate 類別並實做 ticket, pass 兩個事件(event)。
• TicketGateController 有一個參考(reference)指向 TicketGateState Interface， 並將事件的實做委派(delegate)給 TicketGateState 的實體子類別。
• 例如，當 TicketGateController 的狀態為 Locked 時，其參考會指向實現 TicketGateState 介面的 LockedState 個體(Instance)。當 ticket 事件發生時，Controller 內的 ticket() 函式(method) 會委派並同時將本身當參數傳遞給 LockedState 的 ticket() 函式來實做。該函式內部首先會呼叫 Controller 的 setState() 函式，變更狀態為 Unlocked，再呼叫 Controller 的 unlock() 函式，實際執行 Unlock 的動作。

範例—藍芽裝置的配對狀態圖

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

說明

• 狀態的轉移會有一個標籤(Label)名稱，係由三個部分所組成：
  　　trigger-signature[guard]/activity
• 每一個部分都可有可無。
  • 觸發事件負責驅動可能發生的狀態變化。
  • 條件(guard condition) 代表當條件成立時，才會發生狀態的轉移。
  • 活動(activity) 代表當轉移成立後的行動(action)。
• 本範例圖的搜尋中狀態，其中一條轉移動作可以解讀為：「當新增裝置，且輸入的 pin 碼是正確的，就會執行配對，然後轉移到已連線的狀態」。

範例—多功能基座的狀態圖

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

說明

• 範例為展示一多功能基座的狀態圖，可提供電池充電，並可以同時播放 mpeg-4 影片或 mp3 音樂或是聽收音機。
• 開啟(on)狀態內部有兩個並行的子狀態(Sub state)，兩個子狀態之間以一條虛線分隔，代表在開啟的狀態時，同時擁有現處於上層(如充電)與下層(如播放mp3)的子狀態。
• 範例圖中所圈住的 H 符號，代表歷史狀態。即當該基座轉移至 Off 狀態後又再轉移回 On 狀態時，下層的子狀態會記憶先前所在的狀態，如播放收音機。而從 H 連至 播放mp3 狀態的箭號代表著若第一次被開啟，沒有任何歷史狀態時，必定先會先進入的狀態。