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 軟體設計思維 會員登入 會員註冊

問題思考

Bill Gates 曾於 1999 年在「數位神經系統」一書中提出 DNA (Distributed Network Architecture) 架構,那麼,又與現今當紅 SOA (Service-Oriented Architecture)架構有何異同?

理念相同

 o 業務驅動 IT 技術,科技支援商業。
 o 企業間的協同合作,提供即時精確的服務。
簡言之,即為以服務為導向 (service-oriented) 的架構規劃與整合,讓 IT 與 企業合為一體。

作法不同

 o DNA 走自家的 COM/COM+ 分散式技術,是屬於 “緊密式耦合 (tight-coupling)” 的連結方式;SOA 則走 Web-Service 的寬鬆連結方式 (loose-coupling)。
 o DNA 偏以自家產品 (MS Solution)為中心的整合方式;SOA 則為異質平台的整合方式,依循標準的 HTTP/SOAP, XML 的整合方式。

SOA 的四大特質

 o 簡單
 o 異質
 o 彈性
 o 寬鬆連結

  • 不同的平台之間 (.NET, J2EE, PHP/Ruby … 等),均可以透過 HTTP/SOAP 協定傳遞 XML 資料 (純文字的格式)。
  • 利用 WSDL (Web-service description language) 描述 Web服務 的公佈介面 (interfaces)。這是一個基於 XML格式的標準,以描述如何與 Web服務 通訊和使用的服務。
  • 因為是寬鬆連結,最好不要期待 Web-service 可以處理交易機制的協調處理,取用一次,完成所需的服務即可。
  • Web-service 的本質就是屬於 “state-less (無狀態)” 的機制,若是應用在 UI 與 Middleware 的系統連結上 (如 .NET Form 透過 web-service 連結 J2EE),需注意用戶端與伺服端的狀態保存與維護。

SOA 的挑戰

 o 如何作整體性的架構規劃?
 o 如何快速部署 (deploy) Web-service based 的應用程式?
 o 如何讓設計比較有彈性,以快速應付外界的需求?

整體性的架構規劃

 o 可以利用 UML 使用案例圖 (use case diagram)呈現整體架構設計。
 o Use Case 本來就是以需求服務為導向的設計,與 SOA 的標的一致,故用其作為架構設計的呈現,最為適合。
 o 每一個由 web-service 所揭露的服務 (service),會對應至一到多個使用案例 (use case)。

快速部署 WebService

 o 這是屬於系統廠商的責任,包括 MS, IBM (WebSphere), BEA (Weblogic), TiBCO 等,均能提供快速部署 Web Service 的應用程式。
 o 先進的工具還能支援:
  o 資料物件與 XML 的格式轉換
   o Java Bean to XML (反之亦然)。
   o DataSet to XML (反之亦然)。
  o Support XML Schema 的設計與定義。

彈性的設計

 o 這是屬於 Developer 的責任。
 o 這是軟體設計最為嚴謹且為最大挑戰的領域。
 o “應變” 是軟體設計者應有的態度。
 o 可先以 “分層結構 (後述)” 作為系統開發的 “cook book”,先瞭解與熟悉 “委派(delegate)” 的設計手法。

相關課程報名請至: http://www.hsdc.com.tw/modules/eguide/
12/22 【研討會】18th 軟體設計鮮思維講座
01/05 【台北場】物件導向基礎養成一日遊 (星期六)
01/06 【台北場】七階段作好 SA 系統分析(星期日)
01/12 【台中場】物件導向基礎養成一日遊 (星期六)
01/13 【台中場】七階段作好 SA 系統分析(星期日)

利用耶誕節與元旦假日前後,來參與軟體設計嘉年華會吧。 HSDc. 顧問講師群們歡迎學員攜帶任何軟體設計議題,於研討會或課堂上一同來參與討論。

---------------------------------------------------------------------------------------------------------
※課程介紹:

一、18th 軟體設計研討會:
  本次研討會以 SOA 為主軸,共提供兩個場次的研討。邱郁惠講師演示如何利用 UML/MDA 進行 SOA 專案系統分析;Kenming Wang 則直接以案例研討,來說明 SOA 的架構設計與主流 IT 技術整合觀。另由於 Cathy Sung 講師因公無法前來,但仍提供簡報教材(附於光碟內),說明 SOA 的專案管理技巧。
  報名費用:$200

二、物件導向基礎養成一日遊:
  本課程僅利用一天,約七個小時的課程時間,從物件本質,到基礎觀念與進階應用等觀念的傳授,包括概念與抽象、物件與類別及其之間的關係等,以及包括封裝、介面與多型的應用。利用三個層次,傳授不同層次的法,但均旨於闡述物件導向思維的本質,從觀念、生活/軟體面的層次、軟體塑模(Modeling)的層次、程式語言的層次。每一個層次,均有其產出,生活/軟體面利用實例來表達;軟體塑模產出類別與物件圖;程式語言同時產出 .NET 與 Java 的程式碼(同時也藉由程式碼範例,瞭解到類別之間的關連、一對多、多對多的關係是如何程式化,又介面與多型的程式碼又是如何表達的...)。
本課程同時也是作為隔日「利用七階段作好 SA 系統分析」課程的前導基礎培訓,若仍未建立對物件導向基礎知識,是不容易利用 UML 作好物件導向式的系統開發(已可說是現今軟體設計的主流)。
  報名費用:$1800

三、七階段作好 SA 系統分析一日遊:
  這是 HSDc. 新增的 UML 課程,並由國內最資深的 UML 研究員邱郁惠小姐就她最近的著作(已出版):「寫給 SA 的 UML/MDA 實務手冊」為藍本,利用七個階段、每個階段均有很明確的產出,來說明 SA 的系統分析過程。本書在各大書局亦為暢銷軟體設計類叢書,也同時作為上課教材用,並且,由原作者親自講解,並提供案例演練,在一天的課程就可以帶回每個步驟的明確產出,對 SA 幫助多多。
  報名費用:$2100

若同時報名六、日共兩日課程,共優惠價$3,600 (原 $3,900),上過其它課程的學員,以及三人同時報名者,再優惠為 $3,200。同時學員有原作者簽名書籍、講義、電子檔與電子文件(含送 UML 答客問)等。

由於台中學員的熱烈迴響好評,本次系列課程仍於「逢甲大學」舉辦,歡迎大台中地區的學員們報名上課。

對了,下午(台北場地)我們也免費備有點心與咖啡(台中場地,我們會另訂購飲品),是現煮的研磨咖啡(也有外購小蜜蜂的冰咖啡),好喝香醇。品味咖啡,並同時瞭解與領悟物件導向的觀念與應用,那可是心靈愉悅舒暢的享受。

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

§授課講師:
 o 物件導向一日遊: 賴信仁(Ringle Lai),王克明(Kenming Wang)
 o 七階段作好 SA 系統分析一日遊: 邱郁惠、宋敏如(Cathy Sung)

§上課時間:
 o AM 9:30~12:40、PM 1:40~5:00,計約七個小時上課時間。

§上課地點與上課人數:

 o 台北場—開羅會議中心,地址:台北市光復南路65號B2 (光復南路、市民大道交接口)。
 o 參考交通與地圖地圖: http://www.hsdc.com.tw/modules/newbb/viewtopic.php?viewmode=flat&topic_id=38&forum=5
 o 台中場—逢甲大學教室,地址:台中市西屯區文華路100號。 (上課前一星期通知確實教室位置)
 o 報名人數滿 10 人即開班(同時保留 5 名學員重新選修該課程)。

§備註:
 o 教室設備包括白板與投影機,由講師親自說明與操作示範。(學員可攜帶錄音筆)
 o 學員最好能攜帶 Notebook,可以於課程中實際操作與練習。
 o 報名滿 10 名即確定開班,同時保留 5 名學員重新選修同一課程(請攜帶原上課講義)。開課前三日會以電子郵件聯絡與通知學員。
 o 為確保報名足額人數,煩請先以 ATM 轉帳預約費用($500),並請於報名表備註欄位內,註明您的轉帳帳號末 5 碼與轉帳金額。
  (若實在不及轉帳者,仍可現場報名,但請在報名表內註明現場繳費)。
 o ATM 轉帳帳號: 新光銀行 (103) 帳號: 0772-50-100979-9
 o 下午均免費備有冰、熱(現煮)研磨咖啡(非3合1)與點心,供學員享用。

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

-------§附錄:課程表參考內容--------------------------------------------------
物件導向基礎養成一日遊
※上午(9:20~12:40)
 o 物件本質
  o 概念(Concept)與抽象(Abstraction)
 o 基礎觀念
  o 物件與類別
  o 關係(Relationship)
   o 結合關係 (Association)
   o 組合關係 (Whole-parts)
   o 繼承關係 (一般化-特殊化)
 o 實作產出
  o 範例—生活面與軟體面
  o UML Model (EA 格式)
  o 程式碼 (含 C#.NET and Java)

※下午(13:30~16:30) 實作練習(以實際開發個案為例)
 o 進階應用
  o 封裝(Encapsulation)的設計
  o 介面(Interface)的設計
  o 多型(Polymorphism)的設計
 o 實作產出
  o 案例分析 (Case Study)
  o UML Model (EA 格式)
  o 程式碼 (含 C#.NET and Java)
---------------------------------------
七階段作好 SA 系統分析
(利用基金模擬個案,作好系統分析)
CIM-1:定義企業流程
CIM-2:分析企業流程
CIM-3:定義系統範圍
PIM-1:分析系統流程
PIM-2:分析企業規則
PIM-3:定義靜態結構
PIM-4:定義操作及方法

這本書是我以前的同事兼我以前的導師邱郁惠小姐最近所出版的第一本著作。
邱郁惠小姐可以說是國內最為資深的 UML 研究員,她所寫關於 UML 書籍,語法絕對不會有錯,考究甚是詳細。其實我也針對本書寫了「iTHome 書評」,不過因平面雜誌尚未刊出,所以書評內容尚未放至個人的部落格內。

本書可說是相當中規中矩的著作,是蠻適合 SA 的入門書籍,價錢也便宜。關於本書的介紹與購買,至原作者個人的網站: UML Blog
更能瞭解。

我特別商請邱郁惠小姐來寫個本書的介紹文,底下引言即是邱小姐對本書的自我介紹。

我自己認為這本書有兩大特色,先說第一個特色:我假想開發一套基金交易系統,以此做為貫穿每一個分析步驟的模擬案例。更特別的是,我模擬了SA與客戶之間的對話,以此展示出SA在訪談當下,會有什麼樣的提問,以及有什麼樣的思考,最後又畫出了什麼樣的UML圖。

特別是SA的提問及思考的部份,是我參與專案及教學多年的經驗。大部分我所參與過的專案,都需要我對專案成員進行邊敎邊做的專案訓練,我期望自己能夠在最短的時間內,把這些成員訓練好,讓他們可以立即上戰場。因此,除了基本的理論知識外,更多時候,我傳授給他們的其實是實務上的提問技巧,同時也會告訴他們我如何思考的。這樣一來,除了可以讓他們在不耽誤太多專案時程的情況下,不僅學到UML,更能夠應付專案工作。

當然,我的提問與思考絕非應用及學習UML的唯一方法,也不會是最正確或迅速的方法。同時,在專案時程緊縮的情況下,專案成員對UML的認知和體會絕對會有所侷限。而我所做的這一切,無非是想讓專案成員可以有比較低的門檻,對於在專案上應用UML可以有小小的成功經驗。因為我十分相信,有了這樣的正面的、成功的專案經驗,將有助於點燃專案成員日後願意花更多的時間和精力去深入學習、體會及應用UML。

另一項特色:我將分析步驟編號成CIM-1~3、PIM-1~4,一共七個分析步驟,這樣的編號是我從研究DoD AF(美國國防部系統架構框架)所得來的靈感。而我這樣做,有一個主因是,在應用UML圖時,同一款UML圖可以有不同的用途,而初學者經常會有所混淆。

最常見的例子是,使用案例圖(Use Case Diagram)可以用來表達企業流程,也可以用來表達系統服務;如果在專案中,有進行企業流程的分析,也做了系統服務的分析的話,我發現UML的初學者經常會對此有困擾,往往會混淆為什麼同樣是使用案例圖,但是一張叫做企業用例圖(Business Use Case Diagram),但另一張卻又叫做系統用例圖(System Use Case Diagram)。

為了降低這樣的困擾,我試著不以UML圖為主,而是以分析設計步驟為主,教導成員每一個步驟的重點為何,以及採用的UML圖為何?以此來降低UML初學者的學習門檻,同時大幅節省了專案成員教育訓練的時程。而且有了這樣的思維,專案成員也可以認知到,UML圖並不是非用不可的關鍵,每一個分析步驟所要呈現的觀點才是真正的重點,所以日後有更好的技術時,當然可以將任何一款UML圖取而代之。

此外,在進行專案時,一開始就可以評估哪幾個分析步驟一定要做,哪幾個分析步驟可以視情況添加,這樣有助於時程的評估,也有助於經費的預算。對於專案成員的心理,也有極佳的安定性,專案成員會很清楚知道現在做到哪個步驟了,接下來會進行哪個步驟,以及步驟之間的相關性為何。再者,可以將每一個分析步驟視為一個元件,嘗試不同的排列組合,當然這個部份還是要顧問的配合,才能為專案打造出剪裁合宜的開發流程。