連著三天在三個單位的輔導與授課 (2008/04/15~17)

前一整個星期還真有些累。 上星期六、日 (04/12,13)我們才舉辦了 「活用 UML 三劍客與實作程式碼」的單元課程,然後星期二、三連著兩天在高雄在兩個單位輔導與授課;星期四下午又到我們已輔導一年餘的大型鋼鐵公司洽談新案子合作的開發事宜。然後接近傍晚又過去內湖港墘路某家開發金融的軟體公司授課,直到晚上8:30;星期六又過去「開羅會議中心」照顧一下今年我們首次舉辦的「軟體設計鮮思維」研討會。然後昨日星期天早上也把延續上個星期的單元課程利用案例研討,作個總結。 呼,講課久了,喉嚨會有些沙啞,身體當然也會有些累。今天 (星期一)竟然睡到近中午,不過到也著實補回了身體能量不少。

現在有高鐵,到高雄的確是方便多了。我不用前一天就過去,當天只要坐 7:00 以前的班次,不到九點就可以到高雄左營站了。上星期二我坐捷運到了台北車站,本來是打算搭 7:00 的高鐵班次,沒想到 6:32 到達,然後用現金投錢買自由座的車票,竟然還趕得上 6:36 的班次,所以到左營時也才約 8:10 左右。那天因為 Ringle 是已前一天到達,住在他朋友家,當天是 9:00 約在左營站見面再一起過去輔導的公司,所以我是很輕鬆,就在高鐵內的 StarBuck 坐著看買來的報紙。 本來是想點早餐的,沒想到那個店面沒有,實在差,不得已只好點了個麵包與小杯的焦糖瑪其朵,這樣也要 NT$180, StarBuck 的咖啡真是貴。

星期二那天是到文信路某家我們已過去輔導過三、四次的軟體公司,檢視他們從我們上次輔導後,根據我們的建議所作出的開發產出。下午我還凹 Ringle 請全部參與的人員喝個下午茶,每人一杯咖啡外加蛋糕。輔導或上課時,我總是覺得沒必要太過嚴肅或沈悶,輕鬆一點,輕鬆一點嘛。 晚上結束輔導到我日前從網路訂的商務旅館,在後火車站安寧街附近,有家「住X」的飯店,一看就知道是傳統旅館改型過來的,雖然房間很大,也可以上網,但設施什麼的都很不佳,要洗澡竟然熱水故障吧,洗到了冷水,隔天 Check-out 所附的早餐也只有輕粥及一些小菜,連煮的咖啡都沒有,只附了三合一沖泡咖啡... 這類的飯店,以後我是不會再去住宿了。記得上次所訂購的商務旅館,叫做「西悠飯店」 (這次竟然前兩天訂時,房間全客滿,沒有辦法訂),就真的很棒,設施什麼的都很新,是個相當新穎、名副其實的商務旅館,早餐又很多樣化,中式、西式等的都有,附近的景觀又很棒,上次我住的時候,晚上還出去走走要買晚餐,附近空曠以及許多高雅的建築景觀,讓我印象很深刻,覺得住在這附近,真的會有幸福的感覺。

第二天(星期三) 是到高雄榮總資訊中心上課的,這是我第一次到該地方,覺得好大喔。 早上提早了約 20 分鐘過去,醫療中心一樓真的很熱鬧,好像就是百貨公司的商店街一樣,除了賣吃的,還有「金石堂」書局,甚至也有服飾店,還有專賣玉的店呢。 我在他們的咖啡廳點了杯咖啡,喔,實在相當不好喝,喝了沒幾口就沒喝了。到了中午,才到了榮總附近的 StarBuck,點了杯榛果拿鐵,嗯,好喝多了,下午精神也就跟著清爽。有個小插曲,下午是 Ringle 授課,是直接請他們當場提供案例,然後由我們展現如何從需求分析到程式碼實作,三個小時內就是給它實作出來,這也是我們的原則: 早上分析設計,下午程式碼就要能實現出來。 結果在分析某個需求,Ringle 是認為共有四個使用案例,嘿,我是認為只會有一個,而且是很堅定的認為,Ringle 當下很不以為然,不過我就是很有把握,甚至還底下與旁邊有位很可愛的小妹妹說,放心,回到台北,Ringle 會接受我的論點啦。 不過真的可以知道,我個人與 Ringle 合作那麼久了,對於軟體本質性的道理,都仍在持續學習體會中,光是使用案例,竟然到現在仍會有不同的見解,可見使用案例技術真的是易學難精的。對於該案例,我肯定是會著文來討論的。

星期三晚上從高雄回來,隔天下午是到我們輔導國內某大鋼鐵公司的資訊部開會討論,他們希望能整合 Project Server 與預算系統(客製化),由我們統籌該整合專案的開發。一般來說,在開發一個整合性的專案,我們會先提出該系統的架構規劃,然後就技術上的一些課題,會利用 Prototype 來找出其中的風險與驗證架構的可行性。所以也談好本星期會再過去,利用 Protype 展示並作更深入的討論。 傍晚約 4:30,是過去內湖那家專作金融的軟體公司作軟體的教育訓練。規模蠻大的,與我們洽談的企業內訓安排在每個星期五,共有 10 來個星期,好像共有 40 多個小時的教育訓練課程。那個與我們時常聯絡的 Marketing 專員,還拍過食品廣告呢,是個很漂亮,也好有禮貌,親和力好好的女孩子。現在我還在用力找,到底是隱藏在哪一個廣告,目前都還沒找到。 :>> 一開始學員們都還蠻拘謹的,不過安排我第一次過去上課,就是要負責炒熱氣氛的。還不錯,我還算是蠻會講一些笑話的,後來整個上課的氣氛就好很多,也有學員們會踴躍發問問題了。

星期六、日連著兩天就是在「開羅會議中心」研討會與單元課程的。 星期六的研討會這次我就沒參加了,我們三年多來共舉辦了有十九次的研討會,就只有這次我沒有上台主講,總是要休息一下的嘛。:P 而星期六晚上,我臨時想了一個案例的主題,從界定系統範圍、找出優先實現的使用案例、設計類別與循序圖,程式實作,準備要授課在隔日的單元課程,所以從晚上開始寫,直到凌晨快 3:00,然後只睡了約五個小時,就過去上課了。上課的時候精神還相當亢奮,但是中午結束後,身體開始逐漸疲累了,下午回來後,先補睡了一個多小時,然後傍晚被我小女兒挖起來,要我玩那個「榮譽勳章—空降神兵」給她看,她可迷的不得了,覺得這個遊戲真是緊張刺激。

然後下個星期呢,又要到高雄過去授課了,也是另一家醫院呢,然後好像也要去羅東,也是醫院耶,最近還真的跟醫院的資訊中心蠻有緣的呢。再來就是要準備我們要在六月初舉辦的系統分析的完整課程,約規劃了 48 個小時,這兩天就會公佈出來了。 其實,我是還蠻喜歡到各個單位輔導上課之類的,可以見識到各個地方或單位的風俗人情,然後看看每個單位他們的問題,怎麼「見招拆招」,也算是有些挑戰性,蠻有趣的。

{iThome 書評—13} Object-Oriented Methods—A Foundation 2nd Edition

副標題:紮實的物件導向設計基礎功夫是奠定系統彈性穩固的基石。

Object-Oriented Methods A Foundation Object-Oriented Methods A Foundation
———————————–
作者/James Martin/James J.Odell /著
出版社/Prentice Hall PTR
ISBN/ 013-905597-5

內容簡介
This book presents those concepts and techniques that support almost any system development approach–whether it involves computers, people, or machines. It considers object structure, object behavior and more advanced concepts such as composition, structural constraints, rules, using rules and diagrams, meta-modeling, and power types. Shows how to represent OOA constructs–modeling object structure, modeling object behavior, modeling state transitions and event diagrams, scenarios. Outlines considerations for design, discusses object-oriented programming, and considers object-oriented design and “instant” CASE. –This text refers to an out of print or unavailable edition of this title.

前言

截至目前為止的書評,我發現到並沒有真正介紹到適合於初學者的軟體入門書籍。大部分所介紹的還是偏向實用性的設計類叢書,即使如 Booch 那本 OOAD,雖然是理論基礎用書,但那本其實難度不低,用字又艱深。事實上,所謂的「物件導向」基礎入門書,要能寫得好,其實非常困難。作者除了觀念要相當透徹外,用字遣詞又要言簡意賅,把複雜的事情簡單的呈現,並不是一件容易的事。不過本次的書評— {Object-Oriented Methtods},兩位作者均同名為 James 的 Martin and Odell,寫出了絕對會是留名軟體青史的代表性著作。即使許多讀者會恐懼於閱讀原文書籍,但本書的英文用句,真的相當淺顯,不太懂文法也是可以讀起來毫不費力。誠如作者在前言裡所提及適合於本書的讀者程度,並不需要具備任何的前置知識,包括程式語言等。更為誇張的是,他們說書中諸多元素用語,已被用來教導約七歲年齡的孩童。這讓我想起,曾經在某購書網站看到,{UML 精華} 那一本書,適用對象竟然是寫為國小程度,哈,許多軟體人員真的是有夠汗顏的了。(其實那是網站筆誤的)

Martin & Odell 可是 OO軟體業界早期相當具知名度的先驅,他們的著作甚多,Odell 除了是物件導向社群的領導者外,也是 OMG UML 規格制訂的主席;而 Martin 看他寫作的資歷,你真的會嚇一大跳,從 1960 年代開始,我都還沒出生的時候,就已經出書了,至今已發表超過 100 本以上的專業書籍,包括軟體、資料庫、電傳通訊、即時性系統等,所涉獵的專業範圍實在廣泛。至今他除了在知名大學教授外,還仍茲茲不倦地研究與寫作。我真的好是佩服,這才是真正致力於軟體之道的大家啊。

清晰明確的術語定義,才能奠定 OO 紮實的基礎

本書共分為六大部分,剛好整整 400 頁,厚薄適中。最後一部份為附錄,除了語法的說明,還有一個訂購系統的分析範例。另外最值得推薦的是附錄D (Toward a Formalization of OO Analysis),是以論文的型態闡述了關於分類的關係、一般化/特殊化、功能/屬性/角色 等在分析過程中,經常會運用到的基礎技能。

第一章是對泛OO系統的概念性介紹。而在前兩部分章節,則為 基本OO的基礎知識。第一部份(2~11 )介紹物件的結構(structure)、第二部分(12~17)介紹的是物件的行為(behavior)。我覺得第一部份可以精讀,那真的是奠定最為紮實的理論基礎了。例如,我們經常說開發的是所謂的物件導向式系統,好吧,那你能否明確的說明出分析的物件從何而來? 再問一個更“俗”的,能不能定義出什麼是物件呢? 嘿,許多軟體人員還會愣住,無法回答出來呢。第二章開宗明義就指出,物件源自於概念(concept),“An Object is anything to which a concept applies. It is an instance of a concept. (物件是概念可以被應用的任何事物,它是概念所呈現的個體)”。 由此定義也可以得知,“物件”與“個體(instance)”這兩個術語,其實是具同義詞性質的。將“概念(concept)”作為認知的對象時,所產出的“個體(instance)”即為物件。但概念會牽涉到人們對於觀點、角度等認知,而會有不同的體認。例如站在遊客的角度,他所看到在森林裡面的樹木,是一個個的“個體”,會從樹木之外的角度來欣賞樹木的茂盛與宏偉,是一種整體性的認知;但站在植物學家的角度,他要研究組成樹木的結構元素,所以會把樹木分為“樹幹”、“樹枝”、“樹葉”、“樹根” 等多個組成樹木的“物件”,從結構的觀點來研究樹木的內部組成。這同時也就代表了,雖然到處都是物件,但並不是任意地將物件給“塞”入軟體系統內,物件導向的設計,是將問題領域(problem domain)的概念,呈現與對映(mapping)至軟體系統內,那麼,如何正確地捕捉(capture)問題領域的概念成為物件,就成為是軟體設計中,最為重要的技能與素養了。 你可以看看,當你能對這些基礎概念術語有很明確的定義時,你就可以很容易地衍生出諸多看來好像很複雜的呈象,但卻又不會違背這些基本的原則。我常戲說,練好這些軟體蹲馬步的基本功,才真正夠得上是武當名門正派的正宗內功!

當能分辦出 物件與類別的區別後,然後再進而瞭解類別之間普遍的三種關係:關連、整體/局部、一般化/特殊化 。透過關連,我們可以分析類別的相依性(dependency),以瞭解耦合(coupling)的程度;透過 整體/局部,我們可以封裝(encapsulate)細節,並以整體的服務呈現給 client;透過 一般化/特殊化,我們把相同的部分抽象出一般化類別,而把特殊或需要擴展的行為分別實現在特殊化的類別,而造成所謂多型(polymorphism)的效果(這也是程式語言中常稱之所謂的繼承)。再來論及的是物件的行為面。從對狀態(state)的說明,然後到狀態的轉移,而發生轉移的觸發(trigger)即是所謂的事件(event)。所以當然就會需要瞭解到事件的種類、事件的處理等,而這也是在當今元件化的系統,在動態期間常會需要用到的機制,在設計上也是相當重要的範疇。

第三部分(18~23)是OO進階的介紹,這裡提及到了限制(Constraints),也就是在類別關係之間如多重性是如何的表示;還有提到了規則(Rules)的表達,是如何呈現在設計圖上。我是覺得這類議題反而比較偏向細節性,倒是不一定要規範如此嚴謹,我是比較主張設計盡量活潑彈性一點,再慢慢地抓出團隊設計的共識即可,至於嚴謹性,倒不如在程式碼驗證即可。

第四部分(24~29)是關於物件導向分析(OOA)的說明。由於這裡涵蓋的議題太過廣泛了,諸如需求面的功能分析、結構面的類別設計、實作面的物件互動等,短短幾個章節不可能詳述清楚的。這裡我也只是大概瀏覽過即可,然後再對上述各個主題,從別的專書中再深入去探究。

第五部分只有一章(30),主題更是嚴肅,設計與實作的考量。開玩笑,一大堆所謂的物件基本教義派就是“掛”在無法將他們理想中的設計具體化呈現在現實的技術平台上,例如所謂的“O-R (Object-Relation) Mapping”,每種平台的實作都不一樣,那也是要相當去深入研究的;還有諸如交易控管、權限控管、分散式 …等,這些都是在實作上必然要面對的挑戰,10 本書都不一定介紹得完,遑論僅有一章?

軟體非“以用為本”

本書在 Amazon 也是頗受佳評的四顆半好書,印刷尤為精美,是我目前唯一有著紅與黑的兩色印刷書。除了 UML 設計圖外,還有許多生動有趣的插圖,佐以解釋主題的呈現。最好是不要抱著從“用”的角度來看待此書,那麼你可能會失望,因為它不一定能馬上讓你可以應用在現實的工作上。當你好奇於為什麼主流的程式語言都採用物件導向式的實作機制、為什麼系統分析/設計也強調所謂的 OO 思維,到底 OO 是要協助來解決什麼樣的軟體設計議題 …,還有當你真正有志於從事軟體專業之路時,本書絕對是修習基礎內功的必備聖典。

三論「博X來」— 訂購商品與結帳是否是同一個使用案例?

這一次倒不是要 “批判” 博X來的訂購系統,而是想藉由該資訊系統,來聊聊需求分析的設計議題...

我們知道,博X來的訂購系統,存在的最大價值,就是提供客戶「訂購商品」的服務,而為了滿足客戶最終能買到所訂購的商品,所以會有包括如「放入購物車」、「快速結帳」等程序。如果妳是一位需求分析師(RA, Requirement Analyst),那麼在分析以使用案例 (use case)為功能點單位 (functional point)的時候,妳會分析出 “多少顆” 使用案例呢 (只涉及到上述討論訂購商品的範圍)?

我經常思考這類的需求分析議題,也曾就該問題與其他資深分析師討論,有人認為是兩個,也有人認為是一個,當然也有人認為是三個、四個…等。 好像是見仁見智,沒有所謂標準明確的答案。 我是在想,能否有一種簡易判斷的 “準則”,來決定使用案例是一個或多個呢? 老實說,從諸多國外名家 (包括創始者 Ivar Jacobson)對使用案例的定義,我仍不容易釐出那個準則,所以我是想透過觀察使用案例的行為,來找出那個判斷的原則為何。

先觀察實體書店一般的購物程序:客戶走入書店,瀏覽與選擇欲購買的商品 (書籍),並放入購物籃內 (拿在手裡也算,代表已準備好欲購買的商品),並拿到櫃臺,結帳並付款。

所以幾個使用案例呢? 我肯定是認為一個:《購買商品》,因為客戶來這個系統 (實體書店)的主要目的就是 購買商品,而為了滿足該目的,他必須經常放入購物籃、結帳等程序,而且整個交易事件的程序 (從放入購物籃到結帳)是有持續的,約幾分鐘到幾個小時就可以完成 (注意此點)。關於傳統書店使用案例圖的表達,可以參考下圖1。

圖 1、實體書店購買商品的使用案例圖
圖 1、實體書店購買商品的使用案例圖

在使用案例圖的表達上,看起來好像是三個使用案例,其實本質上只有一個:《購買商品》。這裡利用《include》這個 stereo type,只是來凸顯《放入購物籃》與《結帳商品》這兩個子程序而已。

再回到博X來網路訂購系統來看,那麼是否訂購商品的程序與傳統實體書店的購買商品程序是一樣的呢? 看起來很像,都有 放入購物籃 (網路上稱為購物車) 與 結帳 兩個程序。只有一點不一樣,放入購物車 與 結帳 可以是兩個不同時間點的交易事件。什麼意思呢? 當客戶瀏覽商品資訊,若是看到打算購買的商品,就把它放入到購物車內,但是客戶並不需要馬上結帳,他可以等過幾天再決定是否結帳。所以很明顯的觀察到,這是兩個可以在不同時間點個別可以獨立完成的交易 (這一點與實體書店不一樣)。 (不過,這兩個交易事件好像又有些關連存在,要 結帳 前必須先有商品 放入購物車,關於此點,留待後述來討論。)

所以,我的觀察與心得是什麼? 我會以為,若是可以獨立在某個時間點可以完成的交易事件,我會把它就視為是一個使用案例。或者再用更通俗的一句話來說,就是參與者在使用這個系統,從上線到離開的過程,可以 “一氣呵成” 地來完成一個功能案例,該功能案例就可以獨立成為一個使用案例。 所以,博X來訂購系統對於 訂購商品 的主要目標上,會有幾個使用案例? 我是會把它切為兩個:《訂購商品》與《結帳商品》,參考下圖2。

閱讀全文 »

再論 博X來「選擇 7-11 門市」功能設計

先前因為在 博X來 訂購書籍的過程時,卡在選擇 7-11 門市的小功能這邊(據稱當日有部 Server 故障),有感而發寫了篇:「實在難以忍受的網路購書流程」。不過不滿歸不滿,後來我還是在該網站陸續訂購了有約 10 來本書籍,可以說是他們的忠實客戶。倒是後來該篇文章有許多網友們的諸多回應,其中也有提到了 EC系統整合 的議題。 系統整合? 一開始看到我還稍微愣了下,雖然我本身的工作就是專注在軟體系統的架構整合,不過我倒是沒想過 {選擇 7-11 門市} 這個小功能有如此慎重。因為,從單一目的來看,真的很單純,就只是 {提供 7-11 門市} 的資訊,在這個時間點可沒有涉及到還有物流出貨什麼的,那是等系統收集到完整的訂購資訊之後,也就是真正客戶按下 {確認訂購} 按鍵之後,訂購系統才需要去處理的工作。但在收集訂購資訊的過程中,只要能取得如 門市代號, 門市名稱等未來可供出貨參考的資訊即可。可不要在此時就把出貨流程給牽扯在一起,諸多熟悉領域知識的 SA,有時候就是想太遠了,常常會把簡單的事情給複雜化。

不過,平心而論,該功能雖小,但就從系統責任分派 (responsibility assign)的角度來看,誰需要提供 {7-11 門市} 的資訊? 統X EC系統。所以自然這就牽涉到了 「博X來訂購系統」 與 「統X資訊EC系統」兩者系統之間的整合,這是合理的。只是,以目前 統X資訊 是尋求從 Web 端網頁之間的互通來達成擴展服務的目的,技術上是可行沒錯,但就是給我一種 “說不出的古怪” 的感覺。思考系統整合的意義:「 系統整合,講究的是以服務為導向 (service-oriented),透過標準界面 (interface)讓系統彼此之間互通,以達成能擴展更多樣化、效率、彈性的服務為目的。」 統X資訊 是服務的提供者 (service provider)沒有錯,但是,它是提供 “透過各種查詢的方式來取得 7-11 門市 的資訊”,卻沒有必要連 Web UI 使用者介面都要干涉參與。這感覺好像是本來是在 博X來 填寫結帳程序表單時,給 “綁架” 到了 統X EC系統,逼著點選門市資訊後,再給你送回原來的表單畫面,相當的不協調。 UI 最好是由提供主要服務的系統來統籌管理比較理想。在此例明顯就是由 博X來 的訂購系統來負責;而使用者在填寫表單與取得相關服務的過程中,不需要也不會知道這些服務是由哪些系統提供的,使用者只要知道現在幫他統籌服務的那一個系統 (訂購系統)能協助完成他的目的即可,而未來服務的提供者在後端換掉,也不會去影響到前端的 UI 畫面,這是系統整合設計的基本思維。 我是這麼以為,系統整合重視的不是在 UI 層的整合,而是回到源本,系統服務是由擔負企業邏輯 (business logic) 的中間 (Middleware) 層來負責的,自然,整合的焦點應該就是位於系統的中間層,這會比較合理,也會來得有彈性得多。 透過本案例,我想也可以分享一下,所謂的中間層是大概如何的作法,未來又可以有什麼樣的擴展彈性。

參考圖1,這是利用 使用案例圖 (use case diagram)來表達功能需求的觀點。使用者的主要目的是 “訂購書籍”,訂購的程序必然會 “包含 (include)” 《結帳》 的程序。而在《結帳》這個程序中,只有當你選擇 “至門市取貨” 時,才會使用《選擇 7-11 門市》這個子功能,所以在圖上的表達是利用 “extend” 這個 stereotype 來表達《結帳》與《選擇 7-11 門市》案例之間的關係。 當使用者要選擇門市時,門市的資訊是由 統X EC 系統來負責,在圖上是利用表達外部系統的參與者 (actor)來表示。

圖 1、博X來訂購系統《選擇7-11 門市》使用案例圖
圖 1、博X來訂購系統《選擇7-11 門市》使用案例圖

閱讀全文 »

{iThome 書評—12} Object Models — Strategies, Patterns, and Applications

副標題:懂得從各問題領域的表象中跳脫,而能直指其核心的本質,才是軟體結構分析的根本所在!!

Object Models — Strategies, Patterns, and Applications Object Models — Strategies, Patterns, and Applications
———————————–
作者/Peter Coad with David North and Mark Mayfield /著
出版社/Prentice Hall 出版
ISBN/ 013-840117-9

內容簡介
Object programmers can now learn how to get faster results using the strategies and patterns (templates) uncovered in this book. Without them, however, the much-needed expertise is only acquired by trail-and- error. Using sufficiently detailed, real-life examples, this book/disk package shows how to build effective object models–using applications that occur in nearly every industry. Presents six chapter- length application examples of how effective, real-life object-models are build–e.g., point-of-sale, warehousing, order-processing, data acquisition and control, and sensors and diverters. Each application reveals specific “how-to” strategies (101 total) and patterns (22 total) that will help readers develop an intuitive feel for building object models. The diskette features an on-line verison of the strategies and patterns summary (in the form of a Windows help file); as well as C++ course files, illustrating a reasonable (but not the only way) to implement each pattern. –This text refers to an out of print or unavailable edition of this title.

前言

我擔任多家公司,包括各類領域(金融、鋼鐵、保險、零售、股票 …等)的系統開發顧問期間,遇到最常見的“通識”就是資訊主管幾乎清一色要求 SA 要能懂得相關領域知識 (domain knowledge),認為這樣才能作得好系統分析。殊不知,SA 最多只能代表著操作人員 (operator)層級的功能需求分析而已,領域知識的核心,包括企業流程的制訂改善等,是由領域專家 (domain expert)所掌握的。 SA/SD 太偏重領域知識的結果 (在台灣,SA/SD 的分界一向不明顯,可能是 SA 與客戶訪談需求,然後由 SD 作 E-R Model 資料庫表格的結構分析),卻忽略於軟體結構分析的技能培養,所抓出來的 Entity (經常呈現為資料庫表格),往往就是耦合性 (coupling)太重,牽一髮而動全身,無法應付變動性。

個人經常奉勸 SA/SD 並不是具備領域知識,而是應該要懂得如何與領域專家的溝通合作,將其核心知識抽象而成為軟體系統的結構,所以要具備的應該是結構分析的萃取能力,那是一種可以獨立於各個問題領域 (domain)與 IT 平台技術的一種技能,我常之為“純”軟體的抽象分析的專業技能。聽起來很玄? 好吧,套一句軟體界常用的術語,就是所謂的物件導向分析與設計的技術,但是那卻非從程式語言、平台技術、或者領域知識等從之學習而來的,那種抽象 (abstract)能力的培養,是需要懂得對事物本質的體悟、感知能力與大量的觀察及動態學習等才能獲得的。老實說,軟體的樂趣正在於此!

以筆者所擔任各大企業軟體顧問為例,起碼接觸到有 2、30 種各類不同的領域,我們是不可能具備各專業領域知識的,但總是能與各領域的專家合作,從三言兩語的對談當中,就能很輕易的抓出該領域的核心結構,並可以馬上就利用如物件圖的案例來檢驗其結構的正確性以及變動的彈性度等,是相當經得起考驗的。對這種跨領域與平台技術的抽象能力的建立,說真的,我們顧問的利器,最早是源自於對本次書評要介紹的主角,是有花了許多功夫的學習,並從實戰當中的印證體悟,才慢慢得以建立起這樣的技能。光是透過書中介紹的“交易樣式”,就得以讓我們橫跨各領域,抓出最穩固的核心結構元素,實在受用無窮。

直指企業核心的本質—交易樣式

本書主要的作者為 Peter Coad,最早研究所教科用書,有許多就是採用他的著作:“Object Oriented Analysis、Design ”兩本經典 OO 著作;不過軟體人員對他仍很陌生,那麼說出 Borland Together,就會恍然大悟,原來就是他創立的公司研發的主力產品 (後被 Borland 花了兩億美金併購)。

先讓讀者瞭解一下,結構分析主要就是抓各領域的穩定元素來建構軟體系統,而那往往就是常在溝通的概念術語 (concept terminology)。在設計階段一般是以 UML 類別圖 (class diagram) 來呈現,而具體化在應用系統中的就是所謂的企業物件 (business object);與在資料庫的表格 (table)。兩者的差別主要在於企業物件尚需分析各個物件所應負擔的責任 (在程式語言則稱之為 方法, method)。分析領域物件與明確分派物件的責任,正是影響軟體結構彈性度的主要關鍵。

有別於絕大部分 SA/SD 是透過需求訪談記錄一個一個的抓“名詞”,雖然是行之有年,但那實在不是一種好方法,所抓出來的類別往往見樹不見林,無法有效的將相關的類別關連於一起。 Peter Coad 是直接直指領域核心,觀察企業行為的本質源自於交易。交易為商業利益交換的一種契約 (contract),是一種非常必要保存的事件 (event)記錄,再由此為中心,來串連其它相關類別包括 參與者 (actor),地點 (place),物品 (item),以及所包含的交易細項 (line-item) 等。這種先抓主幹,再抓枝葉的方式,正是相當著名由 Peter Coad 所揭露的 “交易樣式 (transaction pattern)”。

以最常見的訂購系統來說好了,“訂購(order)”就是核心的交易類別,再由其串連出來,就可以找出“訂購細項(transaction lineitem)”、“客戶(actor)”、“訂購地點 (place)”、“商品項目(item)”等;再轉分析另一個領域如保險業,“保險”絕對是一個顯而易見的交易類別,而“對保”則是與之有相關連後續的交易類別 (subsequent transaction class);好啦,如果是要分析一個運動彩券投注系統,要你馬上抓出第一個類別,應該就知道該怎麼抓吧? (投注, 派彩 均為該領域的核心類別)

不同層次,傳不同層次的法

我是從 amazon 購買 a4-size 的硬本精裝版,本書可是有著四顆半星的高評價,讀者對之推崇甚高。封面為樂高玩具,甚是有趣,看起來其隱喻應該是意指軟體的結構組成,就如同樂高積木般,一個個地給聚合組裝起來的。共有七個章節,前五章均為各自獨立的案例分析,後兩章為策略與樣式的整理列表。印刷很不錯,字體大小恰當且清晰,也有很豐富有趣的插圖。不過內容可是相當艱深,沒有充分的抽象與想像力,是不容易理解的。獨立閱讀本書可說是非常吃力,我是建議能有幾位同好們一起研讀,甚至以角色扮演的方式,來思考所抓出來的類別,以及所賦予其責任的合理性與正確性。

本書的類別表示法均是採用作者自創的語法 (Coad Notation),它可說是自成一格,例如多重性(multiplicity)就剛好是與 UML 類別圖的表示法完全相反,所以一定要先閱讀附錄的語法說明。再則從每個案例研討的過程當中,作者總是會列出他在某個分析階段時所使用的策略或樣式,並將之編號整理在後兩個章節。這個相當的有參考價值,但不要直接就是翻閱這些策略與樣式列表,那可是相當的枯燥乏味,最好就是配合著這些案例的過程說明,久而久之,你閱讀起來才會習慣也比較能有感覺。

誰需要閱讀本書呢? 我是覺得想立志當個真正的“軟體人”是必備的。要知道,軟體設計大概可以分為三個層次;1.把系統“做”出來;2.讓系統效能好一些;3.讓系統更有彈性,來順應變化。 第一個只要有不錯的實作能力,以及功能需求的分析能力即可;第二個則需要有對平台的專業知識能力,能充分發揮系統的效能特性;第三個那可真的需要對軟體的“道”有著長期持續的信仰與熱情方可。我是以為,若能進入到第三個層次,修練該層次所傳授的法,那絕對會是一種無以言語的喜樂。不過,現今國內軟體產業重視速食文化,大約只要求在前兩個層次,第三個層次,曠時廢日,不太容易短時間內有著顯著的實質回饋,因而堅持者甚少,殊為可惜。

今日(03/15)搭車到台中大雅上課的二三事

今天(3/15 星期六)要到台中大雅鄉某一家生產自動化控制設備的廠商上課。

8:30 就要到了,所以一大早 5:20 就起床,準備要搭乘高鐵 6:36 的班次(只停靠板橋站後就可以直達到台中),匆忙刷牙洗完臉就出門了。結果慣性動作,我竟然開車出去! 好吧,那也只好在捷運站附近找個停車位,沒想到竟然沒有任何車位,我又不願意停到捷運站內,10 來個小時可是要花上 3,4 百元停車費,實在太傷。不得已只好又開車回去,然後再趕緊出門搭計程車。還好的一點是一出門就看到計程車了,趕緊搭車還趕得上 6:00 第一班的捷運,呼,還好,這樣就不會趕不上了(不過,只差 3 分鐘到 6:00,計程車司機是多加 20 元,說目前仍是夜間加成,也不知道是不是這樣)。

在台北站下來直接上樓就可以在台鐵/高鐵那邊買票入站了,那個自由座是比較方便,直接透過購票機就可以購買。這一次我是學乖了,想當初上個月要到高雄輔導時,我還以為需要到台鐵的另一邊才有高鐵,結果因為票是在 Ringle 他們那邊身上,而他們卻是在捷運站的高鐵那邊等,所以我跑到台鐵大廳後只好又轉回來,但是卻迷路轉轉到地下街了,一直找不到另一邊的高鐵月台,急得跟什麼似的,還好我也不能說太笨,趕緊又刷卡進入捷運站內,再跑到那個高鐵入口,只差一分鐘!!

真的很快,7:35 就到了。不過因為台中站是在烏日那邊,想說若直接從那邊搭計程車到大雅,要花上 300 多元,覺得太傷,所以就 “自作聰明”,先搭捷運接駁車到中國醫藥學院,再從那搭計程車會比較便宜。一下接駁車就搭上計程車了,想說一切順利,8:30 以內趕上不成問題了。而且呢,那個司機老闆還使用國內某家先進的導航系統,找路是不成問題的啦。嘿,結果司機先生設定的導航目的地是到了,但是竟然門牌號碼差了 100 號(導航系統已告知到達),而且怎麼找就是都不到那個路的正確地址,在那邊空轉了有 20 分鐘,那個司機老闆才去問在地的計程車司機,才總算知道是要繞道中清路,再從另一端的巷子轉進去才能找得到。我是已經急了,已經快 9:00 了,實在還真有些不高興,一直碎碎念,強烈建議司機老闆要改用其它的導航系統,那個某國內的品牌不要再用啦,有夠給它不準。老闆是很不好意思,說要少 100 元。這點我倒是不願意賺這小便宜,堅持還是完全給,即使那個多繞的路,費用還是照算,畢竟,也不算是老闆的錯,是那個導航系統有夠差勁的勒。後來我才知道,從高鐵直接坐計程車約 300 元,但是我剛從醫藥學院搭車過來的計程車費是要 320 元,更貴還多花了 20 分鐘的接駁,真是的。XX(

遲到了半小時,而與我們接洽課程的副理已在樓下等我,人很客氣,不過我是不太好意思啦。還好的是,整個教學的過程挺順暢,學員挺認真聽課,且到下午時也比較放得開了,也會問一些不錯的問題。我倒是訝異那個自動化控制系統竟然會有應用到多型(Polymorphism)的技巧,用來解決他們機台的複雜處理邏輯與狀態變化等,相當漂亮。這個類似的案例未來我倒是可以另文做個分享。

順帶提一下,中午是副理請我到附近一家看來很大型、是那種辦桌的餐館,但也有提供個人的點餐服務。沒想到他們的水餃,體積不大,外型包得像湯餃,竟然相當地美味,絕對比起那個常見的連鎖店賣的水餃,美味程度起碼差了有五倍以上。不過稍微可惜的是,附近沒有咖啡館,喝不到熱騰騰的黑咖啡,退而求其次,只好在 7-11 買那個罐裝咖啡來喝。起碼有了咖啡,我教起課來會更提起勁呢。

下午 5:30 結束課程,因為他們公司就是在中清交流道附近,想說也不趕,乾脆就坐遊覽車回去就好了。副理還開車送我過去,真蠻感謝他的。交流道附近剛好就有一輛飛狗的遊覽車停靠,而且它還是會在中和北二高下車,哇,這對我就方便了。不過對那個飛狗巴士挺失望的,奇怪,前陣子看了新聞說遊覽車為了與高鐵競爭,座位還有提供電玩呢,但是那個飛狗啥都沒有,只有固定幾個位置有數位電視而已。

中途還在龍潭下來,但是到北二高中和交流道時也才兩個小時,是比高鐵慢約一個小時。但重點是,如果我做計程車從大雅到烏日,大概要花半個小時,然後到台北車站後,又要擠車花約半個小時到中和,到了中和後我還是要搭個短程的計程車到家裡,算算竟然搭遊覽車回到家的時間與搭高鐵是差不多,但是那個飛狗只要 $350,而高鐵 $630+ 計程車 $300 ,足足便宜了 $600 耶。

今天我覺得還真的有些不太順利,到了北二高中和交流道下來時,竟然在圓山路那邊舉辦造勢晚會,大群人潮,當然也把整個車流堵住,完全招不到計程車回家,害我走了約快一公里才招呼到計程車。有個小插曲,當我背著厚重的筆電走在路旁時,有台看來中古的休旅車駕駛問我道路。是兩位女生,她們問我興南路該怎麼走,我一聽反問她們要到幾段,她們回答二段,我想說太好了,可以順便到我家嘛,所以就問可否搭順公車同時並能指引她們怎麼走。結果那位看來像男生的女生駕駛沒有表情也沒有回應,挺冷漠的,挖哩勒,我可有自知之明,還是禮貌的告訴她們怎麼走後,自己就背著電腦包一步一腳印往前走囉。奇怪,我應該看起來算是和藹可親之人啊,真不知道她們有什麼好怕的。:roll:

軟體思維顧問

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

Personal