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

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

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),每次只增加一個新的設計。

過年期間,輕鬆一些,看看經典永留影史的西部好片吧。
同步刊登於:
http://www.kenming.idv.tw/index.php?title=a_afpc_ar_casa_adpa_ccp_cci_cdia_r_ep_e_&more=1&c=1&tb=1&pb=1

黃昏三鏢客劇照-01黃昏三鏢客劇照-01
導演:賽吉奧李昂尼 Sergio Leone【狂砂十萬里】
編劇:賽吉奧李昂尼 Sergio Leone【狂砂十萬里】
演員:克林伊斯威特 Clint Eastwood【血型拼圖】
   李馮克里夫 Lee Van Cleef【紐約大逃亡】
   艾李沃克 Eli Wallach【相信愛情】
音樂:顏尼歐莫瑞克奈 Ennio Morricone【海上鋼琴師】

劇情簡介
南北戰爭期間,兩個浪人結伴行騙。喬(克林伊斯威特飾)是個不多話的人,塔
寇(艾利瓦拉赫飾)則是個墨西哥土匪的叛徒,好色而又殘暴,各地的警方都懸賞緝
拿他。他們倆人串通好,由喬「逮捕」塔寇,前去領取賞金,等到人們把他送上絞刑
台的時候,躲藏在暗處的喬再開槍射斷吊索,讓塔寇逃走,然後兩人再平分賞金。

後來,由於兩人為了「分贓」的比例起了爭執,塔寇把喬拖到沙漠裡,想要殺了
他,卻發現了一輛被棄置的馬車,車上是一位受了重傷的富翁,那人把許多黃金藏在
一個墳墓裡,引起了很多人的覬覦。富翁臨死前說出了埋藏黃金的處所,可是喬跟塔
寇都只各聽到一半,因此兩人只好繼續合作。

他們喬裝成南軍,以便通過許多盤查,偏偏卻雙雙被北軍逮捕,而那支軍隊的軍
曹則是殺人不眨眼的惡棍薩天扎(李范克里夫飾)化身的,兩人受盡了凌虐,死也不
肯說出藏金處所的祕密。終於,他們三人來到了富翁藏金的地方,當喬殺死薩天扎的
時候,塔寇才知道他的身分並不單純。

喬用套索套住塔寇的脖子,把他吊在一塊墓碑的上方,留下一半的黃金在他腳
下。塔寇拼命的掙扎,繩索只有越套越緊。最後,喬把繩索射斷一半,讓塔寇得以撿
回一條命,而自己則利用塔寇還沒有能夠完全掙脫的時候,帶著黃金揚長而去。

利用過年的時間把我所購買的《黃昏三鏢客》給看完了。這是《黃昏三部曲》的最後一部,第一部是《荒野大鏢客(A Fistful of Dollars)》,第四台我常看到播映,主角只有一位,就是克林伊斯威特;第二部《黃昏雙鏢客(For Some Dollars More)》,顧名思義,主角有兩位,克林伊斯威特與李.范.克裡夫;第三部即是最終曲,主角有三位,李.范.克里夫、艾李.沃克以及想當然爾的克林伊斯威特 等三位主演,分別是扮演英文片名中的 The Bad, The Ugly, and The Good。後兩部片都是我從從網路上所購買到原版的 DVD,尤其是第三部,還是完整三個小時的加長版。我能看到後兩部影集,真的是興奮莫名,三個小時,我還嫌太短了呢。

真的很難想像,如此經典,可說是代表美國文化的西部影片,是由義大利導演 賽吉奧李昂尼 所執導的,這三部曲根本就是西部片的經典,而事實上,克林伊斯威特也是因為演出這三部片後才開始聲名大噪的。直至今日,我們甚至能看到他演而優則導的佳片,包括火狐狸、神秘河流、來自硫磺島系列等。 塞吉奧李昂尼 最擅長刻畫主角們的性格了,對話往往不多,但就是把鏡頭具焦放大在各主角人物的臉上特寫,表現出冷酷、緊張、焦慮等內心世界。我只能用一句話來形容,太酷太酷啦!! B)

第二部與第三部,固定有兩位主角,克林伊斯威特與李.范.克里夫。老實說,我更是欣賞李的演技,他那一張臉,演正(第二部)與邪(第三部)都相當適合,尤其是他那個臉部的表情,充分表現在這兩部必然都會有的最後決鬥時的那個緊張肅殺的氣氛。他留的那一撇小鬍子、臉上的鬍渣、細小尖銳的眼神,真是性格極了。

我是覺得一部比一部精彩,一部比一部場面更浩大。《黃昏三鏢客》背景是在美國南北戰爭期間,在三個主角之間為了爭奪一筆財寶的情節中,一直都穿插著南軍與北軍對戰的場景。尤其是最後一幕,南北兩軍為了爭奪一座木橋,卻又都不願意炸斷這座橋,而北軍指揮官的酒鬼上尉,一直猛灌著酒,意有所指的說著:「誰的酒比較多可以灌醉士兵,然後送上戰場當砲灰,他就會是贏家;南軍與北軍只有一個共同點...都發出濃濃的酒臭味」。饒富深意,感覺得出導演對南北戰爭有著反諷的意味,最後甚至還藉由 克林伊斯威特 說出他實際心中的想法:「從沒看過這樣的無謂浪費生命」。

那一幕南北軍對戰的場景真的是相當的大手筆,我看起碼有數千名演員呢。大砲、手搖機關槍、甚至衝鋒肉搏都有,突顯出戰場殘酷的一面,這在典型的西部片我是從來沒看過有這麼大的場面過。最後 克林伊斯威特與艾李.沃克 為了要能到對岸拿取財寶,需要炸掉橋,而這也正是那位北軍指揮官上尉重傷時的遺願,不要再為這沒必要的一個小小的點,而犧牲了如此多的人命。總算他在重傷之餘,親眼看到他們成功地炸掉這一座橋,而後滿足地帶著微笑瞑目而去,你真的可以感受到導演到底是想藉由這一段劇情表達什麼樣的意涵。

凡是西部片,必然會有決鬥的場面,黃昏三部曲最經典的橋段都是落在最後好人與壞人之間的決鬥了。第二部是兩個人決鬥,飾演獎金獵人卻要為妹妹報仇的 李.范.克里夫與演壞蛋頭目(我不知道他的姓名,但也演得很好)的對決。當壞蛋頭目有身旁爪牙在場而佔上風時,他拿著當時強暴李的妹妹時的懷錶,就準備等著當音樂聲音停止時,就要殺掉李,當時李是那一種充滿絕望、痛苦而無法報仇的表情。但是後來克林伊斯威特出現把爪牙給全幹掉,然後又讓懷錶的音樂繼續響起,讓兩人維持公平的決鬥... 經典透了;但可以說真正永垂西部經典史的則是在第三部最後三個主角在墓園圓形石塊場地同時決鬥—是三個人同時決鬥的! 真是精彩萬分。每一個主角,各自不同的表情,演 壞人(Bad) 的李是很嚴肅;演 醜陋之人(Ugly)的艾李.沃克則是惶恐樣;而演 好人(Good) 的克林則是一臉蠻不在乎的樣子,各自的表情相當地生動。而且每個人的配槍姿勢則完全不一樣,再加上 賽吉奧獨特風格的配樂,三人對決的畫面,讓人真是緊張得透不過氣來。

說到配樂,實在更是黃昏三部曲的一大特色。賽吉奧融合了 吉他聲、口琴聲、山狼的嚎叫聲 等,充分表現出美國西部那種荒涼、冷漠的氣氛,可以說聽到片中的音樂,你就會知道,那就是西部片! 這裡可以聽得到音樂大師 顏尼歐‧莫利克奈 親自指揮羅馬交響樂團,由女高音高亢的聲音唱出氣勢磅礡的黃昏三鏢客的主題樂曲。

《黃昏雙鏢客》、《黃昏三鏢客》絕對是我最喜愛的西部經典影片了。冷酷、淒涼、簡單,又有等同於日本武士的那種 "道",絕對不會卑鄙從背後開冷槍,一切就是正大光明的決鬥,不管好人, 壞人, 還是醜陋之人 ...。 看完這兩部片之後,雖然不至於到痛哭流涕,但真的可以讓你的神經完全充滿了感動,這才叫西部片嘛,百看不厭,又不會看不懂!!

※ 我看過最棒的影評:
《黃昏三鏢客》(The Good, the Bad and the Ugly) 觀後感

農曆年即將來臨,寫個輕鬆一點的文章,也分享一下 DIY 製作的樂趣。同時祝 ITHome 各位網友新年快樂!!

前天我那個小隻讀小四的女兒 Annie,要求我幫她一起製作美勞的寒假作業—因應今年鼠年相關造型的燈籠。我馬上一口答應說好,想說這也是增進父女倆感情的好機會,因為呢,我們家小隻的總是不喜歡我,嫌我太幼稚 ...

我馬上上網找題材。在 Google 上打上關鍵字— 燈籠、鼠年、製作 ...等,奇怪,大部分都是提供燈籠製作材料 DIY 的網購商。雖然這樣是方便,但總感覺創意不足,也不夠有誠意,我們彩潔不會這樣感激我啦。 |

耶,不經意看到 Mobil01 此篇:[分享]親手製作的簡約設計 IQ light。 哇!! 炫啊,相當的令人驚豔。原來這個 DIY 製作出來的成品叫做 IQ Light,再探究歷史,是由一位知名的設計師在 1972 年所發明出來的創意作品,是利用幾何學原理,將一個個的小版片組裝起來,而可以有相當多樣化的造型。

先欣賞一下我製作出來的 IQ Light 成品。 B)
IQ Light 完成品

由 Mobile01 眾網友的分享作品來看,30 片的組合最是普遍的。組合出來的成品幾乎是圓形的居多,我在想這樣能否製作出老鼠造型的樣式嗎? 結果我的大女兒蓁妮給了我很好的建議,屆時用卡紙剪貼造型在圓形的成品之上即可,Good Idea !! 決定了,隔天就要去買材料來準備製作 IQ Light 囉。

早上與我的小女兒呢,開車到永和「復興美工」旁的美術用品社購買材料。最重要的就是組合的小版片了,材料可以是 紙版、PVC、L型文件夾,甚至連那個裝捷運卡的 Snoppy 保護夾都有網友巧思用來製作成 IQ Light 呢,真是給他非常佩服! 最普遍的當然是用紙材料了,不過一般 A4 紙是太薄了些,做出來會有太軟的感覺。我後來在美術用品社買的是 A4-Size 的 POP 廣告用紙,比一般 A4 紙厚了一點,也感覺比較有質感,不過一包 50 張要價 $270,有些小貴。
POP 噴墨專用紙

回來後,我利用 PhotoImpact 編輯圖檔。Mobile01 眾網友已經有提供紙板樣式囉,或者國外網友的分享,也有各種格式的圖檔樣式。要做成多大呢? 可以在一張 A4-Size 上列印 2,4,8 個紙板樣式,其實是大小不拘的,我後來是自行決定在一張 A4 紙上列印四個紙板(網友比較多是列印兩個或是八個),想說這樣大小應該適中。問問小女兒,她想要什麼顏色,她說是希望老鼠燈籠是淺黃色,好吧,其實我是比較想要淺粉紅說 ...。也沒關係,淺黃也能透光,應該也會相當好看才對。用我家的噴墨印表機列印共八張 A4 紙,4x8 共 32 個紙板。呼,最辛苦的在這裡了,要用剪刀很小心的給剪下來,而且在彎角處可得要用美工刀一筆一筆地給小心地裁切下來,這些細微處小朋友實在是作不來,要是剪壞組合起來可是不甚美觀,也就前功盡棄囉。
IQ Light 組合片

我花了兩個多小時才總算全部給剪裁好了,如何組裝呢? 這裡有 教學指引。 一開始不是很熟,小心翼翼地先組裝前五片。
IQ Light 組合

逐漸地,五片、十片,照著步驟慢慢地給組合起來了,總算看起來有圓形的樣子囉。 )
IQ Light 完成品

然後呢,我開始裝在美術社所購買的燈籠提把,也才 $25,一個提把,放進兩顆三號電池,有個小燈泡就可以成為一個手提的小燈籠囉;同時間呢,我們家蓁妮也把製作好的老鼠耳朵給黏貼到 IQ Light 上。哇! 看起來有些像小老鼠米妮呢。 D
IQ Light 完成品—加上老鼠造型

點燈囉,把日光燈關掉後,真的很好看耶!!
IQ Light 完成品
IQ Light 完成品—加上燈籠提把

辛苦了一個晚上,總算大功告成。 p
也幫小女兒交差完成美勞作業了,而自己也對這個 IQ Light 小有興趣,想說也可以自己在家裡放個這樣酷炫造型的燈罩。所以呢,我打算再去美術社購買 PVC 的霧面材質,來製作小紙板,還有也要去 IKEA 購買燈泡、燈座等。這樣 DIY 製作出來的 IQ Light,美輪美奐,又花不了多少錢的材料費,而且若當客人來訪時,相信他們看到,肯定是會讚美的,那也是令人喜悅的成就感呢。 ;)

寫給SA的UML/MDA實務手冊
 寫給SA的UML/MDA實務手冊
 -----------------------------------
 作者/邱郁惠 /著
 出版社/上奇科技 出版
 ISBN/9789866884597

內容簡介
UML發展至今,已經成為軟體發展的通用語言。現今的應用層面廣泛,從即時系統、嵌入式系統到晶片設計,都可以見到UML的身影。本書與其他UML書籍最大的不同,就是本書不僅止於觀念與學理的論述。而且透過一個開發基金交易平台的案例進行闡述,逐步說明從需求訪談到如何利用UML/MDA,利用一套名為StarUML的開放源碼工具,產出相對應的使用案例圖文、活動圖、類別圖、循序圖和狀態圖。

本書內容兼顧入門及進階、觀念與實務,適合作為初學UML的入門書,也可作為系統分析師實務手冊。對於大專院校學生、初入資訊界之新鮮人、程式設計師、及其他非專事系統分析的開發人員,也可以藉由此書溫故知新,更加熟悉UML。

前言

本書是由國內目前應該是最為資深的 UML 研究員邱郁惠小姐所著作的。邱小姐本身沈浸在物件導向領域已有 12 年的時間,直至今年 11 月初總算出版了她的第一本著作,也可以說,這本書就像是她的小孩一樣,從孵化到誕生,據我所知,起碼花了兩年左右的時間,用心可謂良苦。事實上,我與她曾是同事,再推溯往前一些,其實她也算是我的導師之一,我對她在以前上課時所撰寫的教材,印象深刻,她總是會引用許多國外軟體名家的著作或論文,這對我當時在軟體設計啟蒙的學習上,收穫實在甚多!

本書內容對我現在而言,可能稍嫌淺顯了一些,我是花了約一個下午就把這本書給全翻閱看完了。不過的確對郁惠小姐在 UML 領域底子之深厚感到佩服,基礎理論與語法等絕不會弄錯。例如 UC 的寫作敘述上,一定是稟持著每一個動作步驟必然會有參與者 (Actor)或系統當成主詞 (這是 UC 寫作常犯的錯誤,沒有標示主詞);不會在 UC 敘述上描述所有的細節,而是以參考附件或註記欄的方式,來關連以 UC 為首的一連串相關需求文件 (包括畫面等);還有如在循序圖的表達上,作者也展露出女孩子細心的一面,對於同步或非同步的訊息傳遞,是以帶實心箭頭,還是以待開放箭頭的表達,都相當講究,並且詳細的說明兩者的差異與其應用之處。

七個層次的分析步驟,來降低 SA 對 UML 的學習門檻

先瞭解一下,本書的目標讀者為 SA (System Analyst),也就是所謂的系統分析師,而系統分析包括對系統外部的功能需求與企業流程分析,以及對系統內部的結構分析,諸如資料庫表格、欄位明細等,還有以物件導向為分析主軸的類別圖與循序圖設計等。如同其它 UML 書籍一般,本書的案例與假設環境仍以企業層級的MIS 資訊系統為主,諸如 ERP, 進銷存 等。

本書共 11 個章節,文字敘述相當簡潔優雅,才 300 多頁,但內容卻也豐富,足夠讓 SA 俱備系統分析的基礎知識。作者在書本的內容編排上,是先介紹基礎概念,包括 OO, UML 與 MDA 等;再來就是把作者所創建的七個 SA 步驟,先濃縮在一個章節,快速地跑完一個案例,讓讀者可以看到每一個階段的設計產出;然後根據每一個步驟,共七個章節分別詳細闡述之;最後則以一個完整的個案,來模擬系統分析師與企業人員之間的對話情形,以及其更詳細的產出;最後一章算是附錄了,係以嵌入式系統為主軸,來展示不同的應用領域,但仍可以利用相同的分析步驟,來產出設計文件。

在 OO 與 UML 的概念介紹上,本書僅是點綴一番,並沒有著墨太深,所以讀者最好能佐以物件導向基礎理論的書籍一同研讀較佳;倒是作者在 SA 階段是以 MDA (Model-Driven Architecture) 的開發程序為依據,蠻有意思的。 MDA 主要將 UML 產出分為 CIM (Computation Independent Model), PIM (Platform Independent Model), PSM (Platform Specific Model)等三個階段。 CIM 比較接近以企業主體為主的塑模,包括企業案例、企業流程等;PIM 偏向領域概念模型 (Conceptual Model),較不涉及實做系統的平台;PSM 則落實到系統實現時的特定平台,如以 Spring, EJB2 或 .NET 等 IT 技術。 本書因對象是 SA,所以只涵蓋到 CIM 與 PIM,並未涉及到 PSM,所以自然本書也就不會有程式碼了。

饒富創意的是,作者將她對原來輔導包括陸總部、中科院的美國 DoD AF (Department of Defense Architecture Framework) 規格的研究,帶到 MDA 的開發程序,並依觀點與層次共分為 CIM 1~3, PIM 1-4 等共七個層次 (p.1-35)。每一個階段的產出,皆有相當明確的定義,例如 CIM-3, 是定義系統範圍,產出系統的 UC (Use Case) 圖;PIM-2, 分析企業規則,產出狀態圖;PIM-3,定義靜態結構,產出類別圖 …等。對於習慣能有規範指導方針的 SA 而言,這蠻不錯的,可以很清楚知道每一個階段的主要產出為何,它們彼此之間又是如何的關連與橋接。我比較感興趣的倒是作者以狀態圖來描述企業規則,這點倒是在我所輔導的專案中少以應用到 (我將狀態圖大部分用在 UI 與 Controller 的設計上),而且所引用自 Gray 對企業規則的分類結構 (p.7-2) 定義,包括限制規則與衍生規則等,在第七章均有詳細的說明與應用,這一部份可以說是我從本書所得到最大的收穫。

本書另外較有特色的一部份是在完整的個案分析上,作者是以模擬 SA 與企業人員之間的對話,來導出各個階段的設計。可不要以為那只是模擬而已,其實對話的內容是作者在自身實際輔導的經驗中所粹取出來的,在作者每一次的輔導過程中,她總是拿著一本空白小筆記本,寫下她所碰到的各類情況與問題,相當認真,參考價值自然是甚高。藉由這些對話案例,也可以讓 SA 瞭解需求當事人他們的想法與原作者作為 SA 時的思考推理過程。

作者的用心與考究,從本書可以很明顯的感受到

看完本書後的感想是:創新仍嫌不足,但守成絕對有餘!

可以說是中規中矩的教科用書,雖然沒有讓我有感到很驚豔有趣的想法,但看來很平淡鋪陳的內容,理論基礎可是相當紮實,即使我想雞蛋挑骨頭,還真找不太出有特別顯著的謬論假設,我可以感覺得出郁惠小姐在寫這些內容時,應該是戒慎戰兢,是熟讀並參考了包括 UML 規格與諸多相關書籍及論文等著作後才下筆的。

本書應該是定位在資淺或入門的 SA 為對象,對於作為大學教科用書,我更是強烈推薦給資訊科系相關的大學或研究生。老實說,我看過國內幾本標榜 UML/OO 的軟體工程教科用書,都沒有如本書考究如此嚴謹與用心,基本上就是以如樹狀功能模組來解釋 UC, 物件循序圖等,很典型的 DFD (Data-Flow Diagram)功能分解的思維,只是藉由 UML 的“殼”來解釋而已,與所謂的物件導向式的分析設計思維根本是兩回事。這樣的教科用書,對於學生在軟體設計理論基礎知識的建立上,誤導成分反而居多,實在不甚理想。