{iThome 書評—14} Business Modeling With UML: Business Patterns at Work

副標題:運用物件導向思維與 UML 語法,來保存企業最重要的資產。

Business Modeling With UML: Business Patterns at Work Business Modeling With UML: Business Patterns at Work
———————————–
作者/Hans-Erik Eriksson/Managus Penker /著
出版社/Wiley
ISBN/ 0471295515
Amazon 評鑑:四顆星

內容簡介
Until now, the Unified Modeling Language (UML) has been primarily used to design software, but should you use it to model your entire business as well? That’s the intriguing argument of Business Modeling with UML, a text that combines leading-edge enhancements to UML with some solid thinking about business. Written for any manager with some technical background, this book looks at the possibilities of UML used to model entire organizations.

The book makes a strong case for the advantages of modeling businesses in UML. With models, an organization can provide better software, define and implement new goals, and even decide whether to outsource certain operations. The Erickson-Penker Business Extensions for UML, invented by the authors and presented within the text, permit UML to document the entire business enterprise. This book shows how to model businesses, from business architecture to processes, business rules, and goals. Short case studies–for Web-centric and more traditional companies–are used to illustrate key concepts here.

Later sections of the book will perhaps take a little more background in software engineering to appreciate fully as the book presents a handful of business patterns, which offer reusable solutions to common problems (just like software patterns). The authors also look at how to leverage a business model to create better software.

In engineering, a new car is modeled and thoroughly tested on a computer before any physical prototype is ever built. As the authors point out, a business that has accurate models can test out new ideas cheaply and then adapt to changing market conditions quickly. This title makes a case that UML–a tool traditionally used by software developers–is ready to tackle the job. Read this notably informative and intelligent book to see the possible benefits of business modeling in UML for your organization. –Richard Dragan

Topics covered: Business modeling basics, UML notation and Erickson-Penker Business Extensions, class diagrams and powertypes, object diagrams, statecharts, activity diagrams and swimlanes, sequence and collaboration diagrams, collaboration and use case diagrams, component and deployment diagrams, stereotypes, business architectures, business processes, resources, goals, business rules, Object Constraint Language (OCL) and collections, business views and patterns, business goal allocation, business goal decomposition, business goal-problem, and software architectures

Review
“…excellent value for money.” (Computer Bulletin, September 2000)

前言

一般軟體設計人員以為UML 塑模 (modeling) 的範圍僅限於軟體資訊系統,其實不然,我們也可以把企業當成是塑模的對象,利用物件導向的手法,有效地來保存企業重要的資產。企業塑模的意義就是在於將企業當成是一個系統 (system),把系統視為是一個整體 (whole),我們就可以區分外部的需求觀點與內部的結構觀點。確立了系統範圍的好處在於可以找出系統 (企業)的主要參與者 (primary actor)與支援性的參與者 (supporting actor),前者會需要企業來提供整體性的服務,而它也往往是企業主要的經濟來源與命脈;後者則是企業需要其它關係企業、或子公司的服務支援,以提升企業整體服務的能力。然後,我們再透過觀察內部的組成結構,找出共用性的部分,藉以來支撐外部的需求。企業內部包括靜態的結構元素,可能會有內部工作人員 (internal worker)、軟體資訊系統 (information system)、企業內部經常溝通的術語、概念、實體 (entity)等;還有以及觀察在動態行為期間,為了服務需求,這些元素是如何互動的合作,而構築成所謂的企業流程 (business process)—包括了供應鍊 (supply chain)與內部行政事務的流程等。

可以發現到,應用物件導向分析與設計 (OOAD)的思維與技巧,以及利用標準的 UML 語法與視覺化的圖形表達,簡單又易學、幾乎沒有學習曲線,就可以將企業與軟體資訊系統用一致性的分析手法很平順地互補與轉移,而且可以協助從各種不同的角度來看待組織與企業,不僅只看流程 (這是比較傳統的紀錄方式),還能找出企業核心的本質 (結構)。可以說,企業塑模的價值遠大於軟體資訊系統。除了瞭解企業的運作與規則,也可以知道哪些活動或製程需要資訊系統的支援,如此可以提昇企業的效率與整體競爭力,這也是 BPR (business process re-engineering),企業流程再造的範疇,同時又可以成為專案委外 (outsourcing) 規劃與管理重要的參考依據。

企業塑模真的很有趣,同時又可以擴展軟體人員的視野與格局,不會只是單純僅考量到實作技術面的議題而已。那麼,又如何能建立企業塑模的正知與正覺呢? 我是強烈建議研讀本次書評的主角,它除了說明了 business modeling 的真諦,還教導讀者如何保有多重的觀點 (multiple views)來看待系統,以及如何利用物件以及流程,表達出各個觀點之下的設計圖 (diagrams),不是只有涵蓋理論而已,是絕對可以應用在實務的開發。本書可以說是作者的經典代表作,也是 OMG 系列強力推薦的實用叢書。

從架構與觀點著手,才能掌握整體,瞭解企業塑模的精要

本書我是買精裝硬皮的,質感甚佳,也比一般書籍的 size 大了些,而且看起來好像很厚,約 450 頁左右,這也使得許多讀者望而卻步。但其實印刷的字體還算大,且有著大量豐富的設計圖。我是建議不要逐字細讀 (那太辛苦且沒效率,而且往往很難堅持從頭看完),要能觀其大略。例如我會一開始先研究一下本書的大綱,大概知道一下每一章節要表達的重點為何;在我的心中建構了整體觀之後,然後就會先翻閱到與整體比較有關的章節,然後再看重點標題,當然,基本上圖形大概就可以讓你瞭解到該節想要表達的意義為何。而若是不懂該設計圖的意涵,再去佐以看看那些文字敘述的解釋,大致上瀏覽、能瞭解其意就可以了。我是覺得,本書的編排非常好,讓我閱讀起來是真的很輕鬆。

本書共分為十一個章節。第1章開宗明義,解釋了企業塑模的意義與價值,以及為何是利用 UML 設計與規劃企業流程、企業規則等。第2章是對 UML 語法的簡單介紹,諸如靜態結構的類別圖,以及表達動態行為包括活動圖、狀態圖等,尤其是活動圖,這會是本書後續所常用的。第3章最重要了,它揭露出企業架構的塑模手法。本書最有價值的一張設計圖,正是由兩位作者所自創的語法構成的,由於長得很像火箭,我常把它戲稱為 火箭圖 (其實正確的學名為 Eriksson-Penker Business Extensions,也可以把它視為是活動圖的擴展),用來表達鉅觀的企業流程。而事實上,它也成為我在輔導比較大型 ERP 系統開發時所常用的流程設計圖。一般我經常看到系統分析人員常常把流程畫得很複雜,細細麻麻的長得好像電路圖。其實這就是因為比較沒有層次的觀念,來適時地封裝不必要的細節。火箭圖正是用來表達更高層級的流程活動,它甚至封裝了活動圖所表達的業務流程,只表達出火箭的輸入、輸出、參考與支援的資訊,更有價值的是,它還凸顯出流程處理完之後所能達成的目標 (goal)為何。火箭圖會應用在如 ERP 常講的業務循環,當訂購循環處理完之後 (訂購火箭),輸出會轉到如採購循環或出貨循環 (出貨火箭)等。然後當要觀察每一個火箭內部的作業時,只要打開它,再利用活動圖來瞭解其活動的細節。層次分明、簡單呈現,這正是塑模的精要 (essential)。

第4章則是提及了上述所講的企業觀點問題 (business views)。我這裡再次提醒讀者,記得當把企業當整體單一系統時,起碼保有兩種觀點—外部的需求觀點 (用的角度);內部的結構觀點 (靜態的結構元素關連與分類,動態的流程互動行為)。第五章則是提及如何利用 OCL (Object Constraint Language)來記錄企業規則 (business rule),這倒不是絕對的方法,我個人本身就不太願意被限制如何表達這些規則。6~8 章則是揭露出各種對企業的設計模式 (business patterns),包括了結構、流程、資源、規則與目標規劃等模式。我會建議不用先去看它,等到有身體力行,應用在實務遇到一些想法或問題時,再回來翻閱,會比較有感覺。第 10 章是討論如何從企業塑模轉移到軟體架構的設計階段。我是覺得,本章並沒有一個很明確的轉移規則,算是一種觀念的引導而已。如何從企業轉移到軟體塑模,在我所實際顧問的專案中,是已經釐出一些規則出來。簡單的說,無論什麼領域 (domain),只要能“想辦法”轉移到資訊系統的使用案例圖,那實作上就絕對不會是什麼問題了。最後第11章,是提供一個案例分析,從企業願景 (vision),到結構的結構、行為與流程等,這些設計是如何被產出,以及這些產出之間的關係又是為何。

企業的資產,是由領域與軟體專家們的合作所累積而成的

從企業塑模的層級可以得知,領域專家 (domain expert)是可以與軟體專家合作完成在企業面的設計。對領域專家而言,流程的設計與規劃,是屬於 “企業流程再造的範疇,而對於軟體專家,是可以把 “企業當系統” 來看待,然後利用 企業塑模 的技巧,來協助企業流程、規則等的設計與記錄,真正企業的資產,就是將領域專家們的智慧,經過“企業塑模”所粹取之後的產出(Artifacts)!! 而後參考企業塑模的產出,就可以很清楚地瞭解與規劃,哪一些企業流程的活動,是可以經由資訊系統的協助,來達成自動化或減輕工作人員的負擔。

連著兩星期週末到高雄的授課二三事 (2008/04/26~05/03)

上個星期六開始,連著週六、日與本星期六(昨天)共三日,是對高雄某家大型醫院的資訊中心教授軟體設計課程,這已經是連續三個星期到高雄授課了,而其中兩個單位都是醫院,還真是巧。

透過兩個醫院的授課,才讓我瞭解到,原來醫療系統幾乎都是內部的資訊中心自行開發的,這與我原來想像系統大部分是委外開發的,大有不同,而據他們告訴我的原因,主要在於維護性的問題,所以無法全權委外,因為變動性的問題,委外單位不足以快速反應變更。

然後再更進一步瞭解,開發的系統範圍很廣,從典型的門診掛號系統、看診系統、藥劑管理系統,到甚至是人事系統,都需要自行開發。喔,這就是典型的醫療 ERP 系統啊。我常戲稱,什麼叫做 ERP(Enterprise Resource Planning) 系統呢? 不知道開發範圍的,就是 ERP 系統啦。

此次該單位找我授課的主要原因是,他們希望透過所謂的 OO 物件導向技術,來協助他們改善系統的難以維護。因為他們導入了 OOP,但是怎麼覺得用 OO 設計出來的元件,一方面很難開發,二方面好像沒有感受到 OO 的美好,好像系統也沒那麼有彈性,所以希望我透過教學,並檢視他們的開發成果,能給予他們一些建議。

原來上星期的授課,是與之協調後決定要講授 「UML 三劍客」的課程內容,那是以使用案例的需求為優先,然後快速導出到實作,是很有效的一種務實的作法。 不過上課了一天後,該單位包括較資深的技術長等資訊人員,問了很多現實他們遇到的問題,也拿出了部分的開發成果請我協助檢視。 我發現到,他們更在乎的是系統的共用性議題,當然還有關於物件的實作議題。 這些反而不是需求性的議題了,而是在於系統內部的結構性設計議題,以及實作面如 O-R Mapping 的系統設計問題了。

我對課程內容的態度是,一切都是彈性可以調整的,不會是一成不變,是可以視各單位現實的需求,動態甚至利用他們的案例當場馬上作分析並導出到實作。所以第三天的課程呢,我就給它調到了對結構分析這部分的重點來了,並且此次也請了我們另一位講師 Steve,協助來講授從領域模型轉到 .NET Coding 實作的部分。

嗯嗯,為 OO 而 OO,一向是我最反對的。我發現到,有太多所謂 OO 的開發,對於物件在中間層的實作,幾乎都僅在於對資料的存取。 所以設計出來所謂的企業物件(business object),根本就是資料物件(data object)而已,而為了資料存取,去設計與實作出這麼多的資料物件,實在沒啥意義的。 設計企業物件的重點是在於對於企業邏輯的處理,如何分門別類、然後把責任(企業規則)分派在適當的物件上,才是所謂物件導向的精髓。 這可是相當不容易耶,領域概念轉成軟體物件,要能抓得好,又要能適切地分派責任,再加上還要能轉成到現實平台上,包括 O-R Mapping 的設計議題,以及包括對 Performance 的資源控管等,這可是要結合領域專家、IT平台專家、與軟體專家的,缺一不可。

閱讀全文 »

四述「博X來」訂購系統 — 撰寫使用案例需求陳述

從使用案例圖中,可以明確地定義出系統的設計範圍—系統需提供哪些服務(每一個功能點服務即為使用案例)、誰會來使用系統、系統是否需要其它系統的支援。這對開發團隊的每一個成員,能具有整體性的共識,是相當有助益的。 再來就是決定優先開發的使用案例,通常那是對系統的利益關係人(stakeholder)而言,最有價值的,優先開發! 屬於企業服務層級的系統,屬於商業交易型的使用案例,通常是最具有價值的。 以「博X來訂購系統」為例,《訂購商品》與 《結帳商品》兩個使用案例,會是該系統最有價值的需求服務,參考如下圖1。

圖 1、找出價值最高的使用案例優先開發
圖 1、找出價值最高的使用案例優先開發

對於需求分析師(requirement analyst,RA)而言,為每一個使用案例來寫出使用案例的需求陳述(use case description)才是最重要的。 使用案例敘述要能寫得好的訣竅就在於,只專注描述參與者(actor)與系統的互動對話;也可以這麼說,當參與者(一般為使用者)在使用系統上線的期間(session),RA 要能觀察出參與者與系統會有幾次的訊息傳遞(message passing),然後將之寫成具散文格式的動作步驟,到完成最後一個步驟時,系統即能滿足參與者使用系統的目的。

閱讀全文 »

連著三天在三個單位的輔導與授課 (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。

閱讀全文 »

軟體思維顧問

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

Personal