今日(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:

實在難以忍受的網路購書流程

剛剛 (03/05 PM23:10) 左右,要向「博客來」網購書籍,點選購物車快速結帳(我發現到,名不其實,根本沒有快速),光是要選個 {7-11 取貨門市},點選了好幾次,網頁就一直在那邊轉著,沒有啥回應。吼,已經忍受他們不理想的購物介面好久了,此時實在不吐不快!

我應該算是他們多年來的忠實用戶了,現在買書,幾乎都是在該網站買書的,主要原因可不是方便,而是便宜。對我而言,只要書比外面實體書店便宜、取貨快速(這點博客來被統一集團併購後,透過該物流的確非常迅速)、再來就是買書時簡單乾脆,也就是購書的流程能越簡單越好 (喔,還有啦,最起碼基本資料也不應該被外洩的)。

其它諸如搜尋系統之類的,是另一回事,我主要最不滿意的,就是那個「選擇 7-11」的功能。吼~ 如此差勁的設計,幾年來還是沒有任何長進!! 我知道他們的作法肯定是把所有的 7-11 店家,以及全台灣省鄉鎮縣市給全部塞到網頁這邊來了,大概就是利用 JavaScript 之類的動態網頁技巧把它給實現功能。介面要作得好,這其實設計與實作並不困難,從需求面來看,舉個例,我就打個 “興南”,就會列出 興字開頭的店家、或是興南路等都可以,簡單的說,我可以利用很隨性的打上幾個關鍵字來搜尋門市,就可以篩選列出店家。我只是列出其中之一的作法,其實要能設計更便利的介面方法肯定有很多種,任何一種我看都會比現在你要透過選擇框,先選哪一個縣市,再選路名來得好。吼(再來一次吼聲)~,我們家中和,每次我要選到那個興南路,總是要用滑鼠拉著捲軸找好久,每次拉我總是嘴裡碎碎唸,什麼時代啦,還有這種介面啊。

我曾經寫過一篇:「Javascript 是爛東西?」,其實要提醒軟體設計人員,不要以為有些資料的取得方式是很固定,不容易變動,且可能資料量不大,所以乾脆先一次給全塞到最前端的網頁來,再透過具有動態效果如 Javascript 的網頁語言來操作存取,就是所有的動作都是在網頁(已經與 Server 無關)給全做掉了。在網頁塞了許多不必要的資料,或是讓網頁這邊處理企業邏輯等,這都不是好的設計方式。

無論如何,像這種大型的購物網站,是屬於交易型的系統,也就是稱之為 OLTP(On-Line Transaction Processing)的企業系統,除了在現實上,效能與穩定是必然的要求外,其實在設計上是蠻重視 UI 與在後端系統 (後端系統我比較偏稱之為 Application Server,而不僅是 Web Server)的互動過程,也就是需要向系統動態要求取得或處理資訊,這是一種屬於對話互動式的設計作法。所以當以 {選擇 7-11 取貨門市} 這個案例來說,使用者 (UI)會需要與後端 AP Server 一到多次(可能會有兩三次吧)的互動,才會取得最後的結果,反而這樣的方式在操作過程中,會比較順暢且簡潔。

我估其他們不這麼做的原因應該是考量到了效能 (performance),其實這真的也蠻好解的,我再強調,是與後端 AP Server 互動,並不是每一次都要連到資料庫操作的。由於資料量實在不大,台灣全省鄉鎮縣市 加上好幾千家的 7-11,在記憶體也不會佔用多少。所以也可以利用如 “虛擬DB”,也可稱之為 MemoryDB 的設計方法來達成的,是絕對可以兼顧效能與彈性的,沒有問題的。

結果我這篇文章寫了一個小時,再去點選那個 7-11 門市,再一次的給它吼~ 還是不能點選耶!! 拜託啦,這樣再幾次也會讓如我這樣的忠實客戶給落跑不再去光顧了。如果,嗯,相關單位對該功能還是不知道該如何設計與實現的好,歡迎來找我們聊聊吧,不是只有唸唸空談而已,如何提供具體的解決方案,這點倒是還瞭解的。

{iThome 書評—11} Test Driven Development By Examples

副標題:崇尚簡約之道的測試驅動開發,除了讓軟體人員為自己寫的程式負責外,還能提昇勇氣,勇於溝通與更多的回饋。

Test Driven Development By Examples Test Driven Development By Examples
———————————–
作者/Kent Beck /著
出版社/Addison-Wesley Professional 出版
ISBN/ 0321146530

內容簡介
Clean code that works–now. This is the seeming contradiction that lies behind much of the pain of programming. Test-driven development replies to this contradiction with a paradox–test the program before you write it.

A new idea? Not at all. Since the dawn of computing, programmers have been specifying the inputs and outputs before programming precisely. Test-driven development takes this age-old idea, mixes it with modern languages and programming environments, and cooks up a tasty stew guaranteed to satisfy your appetite for clean code that works–now.

Developers face complex programming challenges every day, yet they are not always readily prepared to determine the best solution. More often than not, such difficult projects generate a great deal of stress and bad code. To garner the strength and courage needed to surmount seemingly Herculean tasks, programmers should look to test-driven development (TDD), a proven set of techniques that encourage simple designs and test suites that inspire confidence.

By driving development with automated tests and then eliminating duplication, any developer can write reliable, bug-free code no matter what its level of complexity. Moreover, TDD encourages programmers to learn quickly, communicate more clearly, and seek out constructive feedback.

Readers will learn to:

  • Solve complicated tasks, beginning with the simple and proceeding to the more complex.
  • Write automated tests before coding.
  • Grow a design organically by refactoring to add design decisions one at a time.
  • Create tests for more complicated logic, including reflection and exceptions.
  • Use patterns to decide what tests to write.
  • Create tests using xUnit, the architecture at the heart of many programmer-oriented testing tools.

This book follows two TDD projects from start to finish, illustrating techniques programmers can use to easily and dramatically increase the quality of their work. The examples are followed by references to the featured TDD patterns and refactorings. With its emphasis on agile methods and fast development strategies, Test-Driven Development is sure to inspire readers to embrace these under-utilized but powerful techniques.

前言

我一位軟體設計的夥伴,是我在這個業界看過上千軟體人員以來,唯一我認為是最為天才的。不是只有 IT 技術的學習能力快速而已,他更具備的是柔軟的頭腦與身段,抽象能力極高,擅長把軟體作軟,令人讚嘆與嘆為觀止。但是我還是覺得他與國外軟體先驅的大師們仍有一段差距,並非是實作,也不是學習的能力之差,最最主要的差距就在於:創新能力! 當然,我與他非常熟,才敢這樣說,而他也能認同此點。我更期勉如此有天分的人能往更高段的軟體設計殿堂,使得有能力的人可以有更多的貢獻,幫助更多人。

什麼叫做創新能力? 舉個例子,我輩之流如我是可以看得出早期 EJB 規格的問題點(簡單的說,軟體結構被該規格綁得死死的),所以會批判與避免使用它。但是 Rod Johnson 卻不是只有批判反對而已,而且還身體力行,寫出了 Spring Framework,實現 IoC (Inversion of Control), AOP (Aspect-Oriented Programming) 的輕量級開發框架,真正釐清 Developer 與 系統層級服務的責任; 再如本次書評要介紹的: Kent Beck 因為在輔導專案的過程中,深深感於測試應伴隨著所開發的程式碼,而不是延遲 (太多大型單位都把測試當作一個重要的製程,卻是交給另外的部門,在開發後才展開測試,這樣能應變測得好? 我很懷疑),所以主張“測試先行 (Test First)”。而為了實現與主張他的理念,甚至設計出 免費開放的 JUnit Framework 等測試框架,以及寫出如本書“TDD (Test Driven Development by Example)”,造福諸位大德。我輩之流雖無法創建如此了不起的框架,但起碼也要作一些推廣,讓 Developer 們瞭解什麼才真正是維繫軟體品質的重要關鍵。

測試先行!先行測試!

我實在是太欣賞 Kent Beck 的寫作風格了。本書才 200 頁初頭,卻共分為 32 個章節。怎麼會這麼多章節? 原來作者根本沒有分小節,然後就是完全以例子,每一章只完成一個小目標、解決一個小問題就結束了。全平面的寫法,沒有艱澀難懂的術語,簡約的風格,真正夠得上是“俗又有力”!

全書共分為三大部分,前兩大部分就是範例,第三部分則是 TDD 的設計模式(Patterns)。第一部份以一個“幣值轉換”的程式範例(本書開頭的介紹中特別有說明到該實際案例的緣由),利用 Java 程式碼範例,來逐漸揭露出 TDD 的設計意涵。這個範例,你初一眼看到時,會覺得怎麼有那麼白癡的寫法? 是的,Kent Beck 盡量模仿初學者剛寫程式碼的程度,這也同時說明了 TDD 是多麼的簡單明瞭,初學者一學就會,也懂得如何慢慢來修正自己的程式碼 (這其實已經逐漸走向設計之道了)。這一部份會讓你瞭解到什麼才叫做是“Test First”? 還沒寫類別程式碼之前就先寫測試程式碼了! 相當之令人驚訝。當然,測試一定不會過,再來才是開始寫你的主題程式,新增類別、編輯屬性、修改參數 …等,請記得,每次只修改一個地方,然後測試它,逐漸讓錯誤減至零,測試亮綠燈為止 (測試有錯會亮紅燈)。簡單的設計、列出工作清單、一次只解決一個問題、測試它、讓它正確,反覆修正... 正是 TDD 最重要的精神。

第二部份則是藉由 Python 語法來探索 xUnit 測試框架的設計過程。是的,這一部份真的是在教你如何撰寫所屬自己的測試框架,本以為開發 Framework 是相當困難且嚴謹的設計工作,但你看 Kent beck 又是近乎白癡的作法,但竟然三兩下就可以開發出測試框架,而且在設計的過程中,還仍能秉持著“測試先行”,真是神奇! 會使用 Python 作為範例的原因,我猜想除了語法易懂之外,它本身是屬於“script-based”的語言,藉此來證明這樣也是能實現測試框架的實作。事實上,目前已知有 30 餘種程式語言支援 xUnit Framework,那麼為何作者還要鼓勵程式人員開發所屬自己的測試框架呢? 兩個理由:1.讓你有對測試工具自我主宰的感覺;2. 藉以探索測試內部的機制。

第三部分是 TDD 的設計模式。這裡談及到了測試的策略思考,包括到底測試的意涵為何、那個時候測試、如何選擇什麼樣的邏輯與資料來作測試。如何測試? 不要紙上談兵,只寫那些測試案例,就是一定要寫自動化 (automated)的測試程式;那個時候測試? 無庸置疑,測試先行! 甚至主題程式還沒有寫出來、資料也還沒備妥之前;測試什麼? 功能性 (針對需求)與單元性(Unit)的測試 (針對本質性的領域類別)。 TDD 崇尚簡潔 (Simplicity),擺脫那些無謂的高度儀式化吧,從簡單的地方開始做起,為自己所寫的程式負責任,維繫最基本的程式品質,並期能持續演化而又不影響既有功能正確性的前提下。

Simplicity is the Power!

TDD 只有一個核心精髓與兩個原則。精髓為:讓程式碼可以運行並能保持純潔無暇 (Clean code that works)。而原則是:1. 只有自動化測試失敗時,才寫新的程式碼;2. 消除重覆 (duplication)。尤以後者,又與系統架構中的相依性 (dependency)設計有相當密切的關係,當消除掉重覆的程式碼後,往往系統的耦合 (coupling)程度降低,也使得可再利用性的價值提昇。

Kent Beck 還特別在序文中提及了“勇氣 (Courage)”,把 TDD 與之關連一起。他認為測試驅動是一種可以在開發過程中控制憂慮感的開發方法,它可以讓你:盡快具體的學習,而不是一直處於試驗性的階段;取代沈默寡言,讓溝通更多的交流;不是躲開回報,而是更能尋求具體有幫助的回饋 (feedback)。當讀者閱讀完本書後,應該就能準備:1. 從簡單開始做起;2. 寫自動化的測試程式;3. 重構 (refactor),每次只增加一個新的設計。

{iThome 書評—9} Constructing the User Interface with Statecharts

Constructing the User Interface with Statecharts Constructing the User Interface with Statecharts
———————————–
作者/Ian Horrocks /著
出版社/Addison-Wesly 出版
ISBN/0-201-34278-2

內容簡介
Behind most non-trivial user interface screens lie complex webs of code that many practitioners in the software industry find difficult to control. Despite the obvious power and sophistication of user interface development tools, the majority of user interface software is difficult to understand because it is coded without an overall design. In this book, Ian Horrocks presents a proven technique for designing event-driven software using the UCM architecture and the statechart notation. The statechart approach to constructing user interface software results in code that can be:

* written quickly and easily,
* tested using white box techniques,
* repeatedly enhanced over the lifetime of a system,
* modified with a minimal risk of introducing unwanted side-effects,
* regression tested without the need for full re-tests.

This book provides a practical guide to constructing real user interfaces for real projects. It is primarily written for practising software engineers, but will also be invaluable to students wishing to gain an insight into user interface construction.

前言

狀態機圖 (state-machine diagram) 是描述系統行為時常見的一種技術。事實上自 1960 年代以來,狀態機圖的設計就已被廣泛運用在即時、嵌入式系統的狀態設計上,而 UML 規格的制訂,更將其納入成為標準重要的設計圖之一。物件導向的技術經常使用狀態機圖來表示系統中的各種行為,如針對單一類別畫出它的狀態機圖,秀出單一物件在生命期中的行為。

我是覺得一般 UML 書籍對狀態機圖的論述,仍是著墨甚少,且焦點還是擺在對單一物件的行為描述,而領域性的物件 (domain object),如“訂購 (order)”,其狀態的變化可能還是少了些,利用簡單的欄位值描述就可以了。
事實上,利用狀態機圖來捕捉某一個體複雜狀態,威力可是非常強大,它有助於讓我們釐清狀態之間轉移 (transition)的變化情形。最常被運用到的範疇,包括控制器 (controller),例如十字路口的紅綠燈,或者捷運站閘門、販賣機等,都是內嵌了控制器;以及使用者介面 (UI),尤以後者,它呈現了因為事件 (event)的觸發,而導致諸多 UI 元件彼此之間的狀態連動,該如何對其作有效的控管,並期能追蹤與測試,以維持 UI 一定的品質。

本期書評的主角,正是運用狀態圖 (statechart)的技術來建構使用者介面。包括傳統的 Windows Form,至現以 Web-based 介面開發的 ASP.NET, JSF, 乃至於最熱門的 AJAX 等 UI 技術,其本質都是一樣的—均為以事件驅動 (event-driven)的介面開發。

本書道盡了狀態設計的精髓與本質

這一本書薄薄的,含附錄也才 250 頁,不過字體實在甚小,閱讀起來實在傷眼,還有,內容也稍微艱澀了一些,可要耐下性子,你才能逐漸理解狀態機用在 UI 設計的觀念與技巧,以及寫出程式碼。

本書共分為四大部分。第一部份是對 UI 建構上的概念引導。從命列列模式的 UI 開始講起,到 windows-based 多樣化的 UI 畫面,以能更提供人性化的操作介面。雖然系統廠商提供了諸多豐富的 UI 元件,並呈現給 developer 直覺式的 UI 開發環境,似乎拉一拉圖形元件 (widget) 就可以就建構出美美的畫面,你也不用再管到這些視窗之間的互動細節。這些工具的確幫助開發者不少,但是,在幫你定義好個別 UI 元件所相對應的事件處理函式之後,在其內的實作程式碼,仍是需要由開發者自行撰寫,並且往往也需要在此寫上關連與其它 UI 元件的狀態操作等。UI 元件彼此之間的狀態連動可能會牽涉到很廣,若沒有一個好的規範,則常會出錯,而這往往也是造成複雜畫面凌亂難以維護的主因。這裡 Horrocks 提出了對 UI 設計極為重要的 UCM (user interface-control-model) 架構 (p.28),藉以釐清在 UI 元件、事件處理者 (event handler)與控制物件 (control object)三層之間的責任分派,你會發現到層次分明的好處就在於 Event handler 並不直接處理邏輯,而是交給控制物件來統一維護所有 UI 元件的狀態,而讓 UI 元件回歸到最單純的責任—視覺化的呈現。其實 UCM 就是等同於現在 Java Struts 所提出的 MVC 框架 (Model-View-Controller),只是名稱不一樣而已。 不過切記,這可是僅此在 UI 展示層 (presentation-tier)對 UI 設計的 MVC 而已,而非對企業整體系統的三層式 (3-tier)的 MVC 架構喔,可千萬不要把兩者混淆在一起,而導致 UI 層與企業邏輯層的耦合性 (coupling)太重。本部分最後一個章節則開始介紹狀態機的設計語法,並藉此來比較有限狀態機 (finite-state machine)與本書所揭露出狀態圖 (statecharts)的不一樣之處。其實說真的,有限狀態機仍是與狀態圖本質是一樣的,均是捕捉狀態的轉移,差別主要是在於有限狀態機並沒有層次的觀念,所以會在一張設計圖上表達出太多的細節,這並不妥,我們可以把許多呈現出好像很複雜的狀態轉移,群組起來,再抽象出更上一層,而封裝了內部複雜的狀態轉移,成為超狀態 (super state)與子狀態 (sub state)的層次關係。

第二部分是對 statecharts 基礎技術的建立。包括了構成狀態圖的諸多表達語法,以及也要瞭解到現實上狀態的各種變化情形,包括了上述所提的層次深度、並行、延遲與逾時、瞬變 (transient)狀態、事件的優先、參數化的狀態等。這裡我覺得最有意思的是歷史機制 (在狀態圖上是以 H 加上圓框符號構成的),在轉移出超狀態、又再次轉移進入後,到底是要進入哪一個子狀態,這就端賴於“H”這個歷史狀態記錄了,是非常實用的一個技巧。本部分後半章節,開始教你 step-by-step,如何從畫出狀態圖開始,並對每一個狀態命名、給予狀態變數,再整理成一張“事件-行動表 (event-action table)”,未來即是可以依據該表格來轉化為程式碼的。第九章則是提供給讀者在設計狀態圖上的提示與原則,未來在實作設計上,可是經常回頭翻閱本章,會帶給設計人員許多的啟發。
第三部分提供了三個案例分析,從計算器、But Reporting 到學生資料庫應用程式等,讓你實際看到這些應用程式的畫面呈現,以及是該如何利用狀態圖來捕捉這些複雜畫面的狀態轉移情形。大致瀏覽一下,也讓你可以知道頂尖的 UI 技術團隊,在設計 UI 畫面時所用到的技巧與其開發程序。

看到四分之三的內容,讓許多讀者會挫折的是,怎麼還是不知道該如何將狀態圖轉移到實作的階段? 第四部分總算揭露出轉移到實作程式碼的階段與步驟了。不過 Horrocks 僅列出實作狀態圖的程式設計步驟 (p.187),以及以虛擬程式碼呈現而已 (看起來應該是以 Pascal 語法來表達的)。並沒有列出相當完整的程式碼範例,這讓許多想要“眼見為憑”的讀者會大失所望的。不過真的要堅持,當初我整整花了一個星期以一個“紅綠燈+方向燈”的控制器案例,從狀態圖的塑模,到實作出 Java 程式碼,當在畫面上可以秀出紅綠燈號的狀態轉移,並且是依循狀態圖的設計規格來實作,這也代表者我即使在 C#.NET 實作,設計圖都不用變動,那種成就感真的是相當喜悅。

高品質的 UI 畫面從狀態圖設計開始

我對本書相當著迷,也為此實作狀態機圖的程式開發,並將之整理成教材納入在 我所教授的 UML 的課程教育上。但是在實務上是否有必要利用狀態圖來設計畫面呢? 我是以為若產品開發是要能呈現在多個平台的畫面上,那真的是有必要,它可以讓可攜性與維護性提高。還有曾有讀者問過我,UI 設計該如何作測試呢? 當你作好 UI 的狀態圖設計後,也就代表了可以針對 UI controller 撰寫測試程式碼,依據測試案例來作自動化的測試,達成高品質的 UI 設計,無論是對 ASP.NET, JSF, AJAX 等 UI 框架,道理都是一樣的,好處真的是多多。
我發現到本書在 Amazon 評價是四顆星,有趣的是,11 位評論者有 6 位給滿分五顆星,3位給四顆星,另外兩位則只給 1 顆星。給一顆星的理由是因為看不懂,所以無法應用在實務上。這實在可惜,那6位給滿分的可是評價甚高,而事實上,能專注於狀態機圖的設計書籍,實在少之又少,況且又能協助你在 UI 畫面的設計上,並以釐清複雜事件處理的狀態控管,實在了不得。喔,還有,本來我以為眼花了,當初我在「天朧書局」買本書時只有 NT$ 750,但在 Amazon 看到的價錢是 U$ 200 元,二手書也要 US$ 180 呢。看來應該是絕版書籍,物以稀為貴吧,同時也證明本書的價值的確是經得起考驗的。

SOA (Service Oriented Architecture) 探討

問題思考

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)” 的設計手法。

{iThome 書評—8} Object-Oriented Analysis and Design

Object-Oriented Analysis and Design with Applications
Object-Oriented Analysis and Design with Applications 2nd Edition
———————————–
作者/Grady Booch 著
出版社/Addison-Wesley Professional
ISBN/0805353402

*** 參考之前對本書的「好書分享***

前言

曾有讀者反應,前幾期中譯本書評,我只就針對原文書籍的內容部分做介紹,卻沒有提及到翻譯的水準。基本上,我是很欽佩這些譯者們的用心,這是吃力不一定討好的工作。再者,我當然是有過濾過才會做介紹的,個人所介紹前幾期中譯本翻譯的品質,我覺得可以說都是在水準之上,讀者們應該是可以放心的 。不過,現在是該來介紹原文著作的時候了,畢竟要從事專業軟體設計職這一行,不看原文可是不行的。

本書是 UML 三巨頭之一 Grady Booch 作為在物件導向分析/設計 最具代表的經典著作,本次我所介紹的書評為第二版,而今年暌違 13 年之久又增訂了第三版,主要新增的內容是將塑模語言改為 UML2.0,並深入探討整個生命週期的一個階段。不過在第一部份的概念篇則與前兩版內容一樣。

軟體的複雜是與生所俱來的 (The inherent Complexity of Software)

本書內容分為三大部分:第一部份為概念 (Concepts),包括複雜度的闡述與觀察、物件模型的建構、類別與物件的區別、分類;第二部分為方法論 (Methodology),包括塑模的語法 (這裡主要揭露出類別圖、狀態機圖、物件互動圖)、巨觀 (Macro)與微觀 (Micro)的開發流程、專案的管理與規劃等;第三部分為案例分析,包括天氣監控、Client/Server 庫存追蹤、AI 人工智慧,甚至 Framework 等系統的分析與設計,以及簡單程式碼的展現。

第一部份的概念篇價值是最高的,Booch 在闡述軟體複雜本質的這一部份,實在是精彩。藉由 PC 硬體產業與大自然植物行光合作用的例子,來解釋其它領域是如何應對複雜度。這就帶出了物件第一個哲理:封裝 (Encapsulation)是解決軟體複雜度的根本。而封裝往往具有階層性,藉由其特性將混沌的表象帶往有機的次序,呈現出簡單的結構。將這些其它領域,包括大自然帶給我們的智慧,來解決在軟體複雜系統的方法與技巧,即為所謂的物件導向分析與設計。

本書更意思的另一部份是它的插圖,尤其是那隻肥貓,逗趣極了。Booch 怎麼介紹抽象 (Abstraction)呢? 插圖上有兩位貴婦人,一個看到的是毛茸茸肥成圓團的寵物貓;另一個則是看到這隻肥貓的骨架與器官組織。這就隱含了軟體開發各種不同角色的人員,往往會有不同的觀點,有需求面的外部觀點,也有結構面的內部觀點。但,觀點仍須保持一致,才能維繫其本質的調和。這讓我想到金鋼經的一句話:「凡所有相,皆屬虛妄,見諸相非相,即見如來。」不要執著在單一的觀點上,運用抽象的本能,當能看到蘊藏於諸多表象背後的那一隻貓 (如來)了。

本書中對於物件導向基礎的概念,揭露出了 抽象、封裝、模組性 (modularity)、階層性 (hierarchy)等。而在物件與類別這一篇,也是花了好多文字來說明什麼是物件、什麼又是類別,兩者之間的關係又是如何 …等。這一章節絕對是奠定物件導向最基礎的功夫,一點可馬虎不得,讀者真的得要相當用心思考體會關於物件與類別的區別,類別之間的關係,包括了關連 (association)、聚合 (aggregation)、繼承 (inheritance)等。尤以所謂的繼承,更是讓軟體設計人員混淆,其中似乎牽涉到單一與多重繼承、多型的設計觀念,這些似乎觀念透過程式語言去解釋,往往不容易理解為什麼要這麼設計。

從生活面來解釋物件導向的哲理

看完本書第一部份,我更確定,所有物件導向的觀念均可以從生活面找到解釋,時常保持一棵好奇、觀察的心,將其體悟會的心得,來解釋包括 封裝、介面、繼承、多型等物件導向的關鍵精髓,當你能“自圓其說”,說得還很開心,周遭其他朋友同事等也逐漸能接受你的論點,甚而還會被你影響,認同你的觀點 … 說真的,這樣難道你還會對軟體設計之道充滿無奈挫折嗎? 不覺得軟體設計是時常充滿著驚奇、有樂趣又有成就感的領域嗎? (當然,我也相信,不會只是虛的成就感,包括實質的“回饋”也是會有收穫的)
倒是切勿本末倒置,從程式語言來學習物件導向的觀念,因為那會讓你只是站在“用”的角度來看到物件導向,把它當作技術而已。當你覺得“不好用”、“無法用”時,你就會認為它是一種不適切的技術,無法應用在現實。殊不知,物件導向只是把人類應用在其它領域的成功經驗,以及大自然所蘊含根本的道理,來協助我們面臨在處於經常性變動的軟體系統上,是如何有效地來克服與應對複雜度,至於程式語言,它就只是工具,工具受限於實體的 IT 技術而無法有效表達這些哲理是可能的,但軟體設計人員的角度卻可不能與其同等狹隘。

多型 (Polymorphism)來說,這好像很難解釋? 非得要透過程式語言的撰寫執行才能理解? 非也! 生活面隨處可見用來解釋多型的例子了。就說“椅子”好了,包括 課桌椅、電腦椅、吧台椅、按摩椅等,均能提供給人“坐”的服務 (service)。人就是客戶端 (Client),他可以享受取用到 ”椅子”所提供的服務;而“椅子”其實就是一種抽象 (abstraction) 的概念 (concept),上述各種類型的椅子,則是具體 (concrete)呈現的物件。而這也可以用來解釋“一般化 (椅子)—特殊化 (各類型具體的椅子)”,均有提供“坐”的服務,但“坐”的方式卻也不太一樣。更甚之,從“坐”的服務,又能衍生出椅子應該有提供“可坐性”這樣的介面,只要能實現 (implement) “可坐性”的介面 (interface),都可以是椅子的一種。所以,如此說來,“大石頭”因為可以讓人坐著,所以它也能算是椅子,但是,它可不是從椅子所繼承 (inheritance)而來的。這樣的觀察與體會,又會讓你知道,“多型”不是只有從“繼承”這樣的角度來看待之。諸多種種物件導向的哲理,處處就存在於你的生活周遭面,信手拈來皆可解釋之,而且充滿樂趣,這豈是只能透過程式語言如此狹隘的觀點才能去做說明呢?

本書的基礎理論相當紮實,各種概念的解釋,都相當的清楚,可說是無懈可擊。但美中不足之處,是沒有整理得很清楚,可以說要稍微有一些底子,才能釐出這些概念之間的關連性。不過你會發現到,本書的文字敘述還真是多,字也挺小的,真要初看原文書籍的讀者可會是很大的煎熬。還好的一點是,有豐富的插圖讓你時時會心一笑,不至於太過沈悶。

軟體思維顧問

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

Personal