{iThome 書評—10} 寫給SA的UML/MDA實務手冊

寫給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 的“殼”來解釋而已,與所謂的物件導向式的分析設計思維根本是兩回事。這樣的教科用書,對於學生在軟體設計理論基礎知識的建立上,誤導成分反而居多,實在不甚理想。

{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 呢。看來應該是絕版書籍,物以稀為貴吧,同時也證明本書的價值的確是經得起考驗的。

{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)而來的。這樣的觀察與體會,又會讓你知道,“多型”不是只有從“繼承”這樣的角度來看待之。諸多種種物件導向的哲理,處處就存在於你的生活周遭面,信手拈來皆可解釋之,而且充滿樂趣,這豈是只能透過程式語言如此狹隘的觀點才能去做說明呢?

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

{iThome 書評—7} 重構—改善既有程式的設計中譯版

重構:改善既有程式的設計
— Refactoring : improving the design of existing code 重構:改善既有程式的設計 — Refactoring : improving the design of existing code
———————————–
作者/Martin Fowler/等著
譯者/侯捷, 熊節/譯
出版社/碁峰 出版
ISBN/9867594061

內容簡介
當物件技術成為老生常談之後 — 尤其在 Java 編程語言之中,新的問題也在軟體開發社群中浮現了出來。缺乏經驗的開發人員完成了大量粗劣設計,獲得的程式不但缺乏效率,也難以維護和擴展。漸漸地,軟體系統專家發現,與這些沿襲下來的、品質不佳的程式共處,是多麼艱難。物件專家運用許多(而且日漸更多)技術來改善既有程式的結構完善性與性能,已有數年之久。但是這些被稱為「重構」(refactoring)的實踐技術,一直(只)流傳在專家領域內,因為沒有人願意將全部這些知識錄寫為所有開發人員可讀的形式。這種情況如今終於結束。在《Refactoring: Improving the Design of Existing Code》書中,知名的物件技術者 Martin Fowler 闖入新的領域,褪去那些名家實踐手法的神秘面紗,並展示軟體從業人員領悟這種新過程的重大意義。

只要受過適度訓練,一位技巧嫻熟的系統程式員可以在拿到一個糟糕的設計之後,把它翻新為設計良好、穩健強固的程式碼。本書之中,Martin Fowler 告訴你重構機會通常可以在哪裡找到,以及如何將一個糟糕的設計重新修訂為一個良好的設計。每個重構步驟都十分簡 — 簡單到了似乎不值得去做的程度。重構涉及將欄位(field)從一個 class 搬移到另一個class,或將某些程式碼拉出來獨立為另一個函式(method),或甚至將某些程式碼上下移動於繼承體系(hierarchy)之中。這些個別步驟雖然可能十分基本,積累下來的影響卻能夠徹底改善設計。重構已經被證明可以阻止軟體的腐朽與衰敗。

除了討論各式各樣的重構技術,作者還提供了一份詳細名錄(catalog),其中有超過 70個已被證明效果的重構手法,以饒富幫助的重點,教導你實施的時機,實施時的逐步指令。並各自攜帶一個例子,顯示重構的運轉。這些富有良好解說價值的實例都以 Java 寫就,其中的觀念適用於任何物件導向編程語言。

Martin Fowler 是一位獨立諮詢顧問,他運用物件技術解決企業問題已經超過 10 年。他的顧問領域包括健康管理、金融貿易,以及法人財務。他的客戶包括 Chrysler, Citibank,UK National Health Service, Andersen Consulting, Netscape Communications。此外Fowler 也是objects、UML、patterns 技術的一位合格講師。他是《Analysis Patterns》和《UML Distilled》的作者。

Kent Beck 是一位知名的程式員、測試員、重構員、作家、五弦琴專家。

John Brant 和 Don Roberts 是《Refactoring Browser for Smalltalk》的作者,此書可從http://st-www.cs.uiuc.edu/~brant/RefactoringBrowser 獲得。他們兩人也是諮詢顧問,研究重構的實踐與理論有六年之久。

William Opdyke 在伊利諾大學所做的 object-oriented frameworks(物件導向框架)博士研究,導出了重構領域的第一份重要出版品。他目前是 Lucent Technologies/Bell Laboratories 的一名卓越技術人員。

譯者 侯捷,致力計算機技術教育超過 10 年 — 以著作、翻譯、評論、專欄、授課等多重形式。對於各種層級、各種定位、各種技術領域之 Framework Libraries 有濃烈興趣和鑽研。

譯者 熊節,普通程式員,喜編程,樂此而不疲。酷愛讀書,好求新知。記性好忘性大,故凡有所得必記諸文字,有小得,無大成。胸有點墨,心無大志,惟願寧靜淡泊而已。夜闌人靜,一杯清水,幾本閑書,神交於各方名士,獻曝於天下同好,吾願足矣。

前言

本書我覺得可以說是軟體界兩大奇書之一 (另一本就是“Design Patterns”)。設計模式講究的是在程式碼之前 (常所說的系統分析與設計活動)的事先設計,而重構講究的則是程式寫碼後對結構的重整。

我們要先瞭解一件事,軟體設計不可能如建築業一般,只在藍圖上畫好設計圖就能建構出穩固的高樓大廈。軟體開發是要經過不斷地分析、設計、寫碼、測試與修正… 。漸增與反覆,才有可能建構出高品質與強固的系統。事先的設計能保障程式碼相當程度的品質,但不可能完美無瑕,事實上,即使如本書作者 Martin Fowler,也仍須透過程式碼的驗證回饋,再回頭來修整軟體的結構。可以說,運用在紙上藍圖的設計模式與在程式碼的重構本都是設計中的一環,“Top-down (SA/SDPG)”與“Bottom-up (PGSD/SA)”兩者本就不應該在軟體工程是被分開為兩種方法論,而是互補,缺一不可,才有可能建構出軟體設計開發的正回饋環路。

所以重構的對象為程式碼,目的在於對程式碼背後所隱含的結構作重整,提昇對軟體系統的彈性與穩定,同時也相對能讓程式人員容易維護與讓寫碼更有效率。因為設計不可能一開始就是正確,它會隨著設計者的經驗成長而進化;程式碼被閱讀和修改的次數遠多於它被編寫的次數。保持程式碼易讀、易修改的關鍵,就是重構。

本書的作者為 Martin Fowler,不過其實考究起來,“重構 (Refactoring)”一詞是由 Kent-beck在 Smalltalk 專案中率先所提出的概念,並用在實務的顧問輔導。Fowler 是集眾多有經驗的軟體開發先驅們之大成,而把他們所經常用在程式碼重整的技巧整理編寫成重構名錄 (catalog of refactoring),模仿如設計模式一般,對每一個重構給予命名與應用時機等,讓程式人員之間方便利用這些詞彙作為溝通,而成為日常開發實務上的習慣。

瞭解為何重構、為誰重構、何時重構

閱讀全文 »

{iThome 書評—6} Rational 統一流程入門

統一流程入門 第二版
— The Rational Unified Process An Introduction 2nd 統一流程入門 第二版 — The Rational Unified Process An Introduction 2nd
———————————–
作者/Phillippe Kruchten/著
譯者/趙光正/譯
出版社/維科圖書有限公司 出版
ISBN/957-8675-79-8

內容簡介
這本書非常簡潔,裡面快速介紹Rational統一流程(Rational Unified Process ,RUP)的一些概念、結構、內容和動機。RUP是一個具備網際網路功能的軟體工程流程,它強化團隊的生產力並提供成員最好的軟體實務經驗。RUP非常特別,開發團隊可以透過它了解統一模型語言(Unified Modeling Language , UML)、軟體自動化和業界最佳實務經驗的所有優點。

Rational統一流程統一整個軟體開發團隊的工作,並且讓每位成員達到最高生產力,因為它為大家帶來了成千上萬個專業與頂尖業界領導者的經驗。想在可預期時程內、用合理預算、輕易完成為品質軟體嗎?快拿本書當作你的指導手冊吧!本書作者與你分享他最深層的流程相關知識,並且把焦點放在RUP的關鍵點,讓你很快就能專精RUP這個已被證實過、確實可行的軟體開發解決方案。

本書第二版主要根據最新版的Rational統一流程更新以符合最新內容。事實上,完整的RUP2000裡’還包括:
1.更多的e-開發指引
2.一份學習地圖,教你如何把流程應用到各式各樣的專案和技術上
3.擴充過的測試分析,現在它會橫跨整個產品生命週期
4.改良過的應用程式介面設計範園一特別針對如何開發有效的網際網路應用程式
5.針對及時與互動系統,提供更詳盡的說明
6.深入淺出介紹如何用樣式和框架來設計系統

Philippe Kruchten是Rational統一流程產品的首席架構設計師。他有超過25年的大型、軟體密集式系統開發經驗,這些系統的領域包括通訊、安全防禦、太空、交通和軟體開發工具。他並擁有Ecole Centralc de Lyon(法國)的機械工程學位和French Institute of Telecommunications的電腦科學博士學位。

前言

RUP (Rational Unified Process) 是由 IBM Rational 所研發並推廣的軟體開發流程。它是一套流程框架 (Process Framework),可根據開發團隊的需求去調整或擴充,自訂的流程描述不外乎包括了四項元素:誰(Who)做了什麼(What),如何做(How)和什麼時候(When)做;它也是一套產品,由 Rational 所研發和維護,並整合在該公司的 Rational Suite Enterprise 套裝軟體內。安裝好該光碟產品,便可以把這份產品當成 RUP 的虛擬電子教練 (e-coach),它提供一個完整的超鏈結網頁,以 HTML 格式來描述流程,並附有各種格式的樣版(Template),如 HTML、RTF、PDF…等,及一個簡單的 Case Study:Rational Project Web Example;而 RUP本身更是一種軟體工程流程(Software Engineering Process),它提供研發單位一個嚴謹的方法,分配軟體開發工作和責任,目的是確保在可預期的時程和預算內,開發出符合使用者需求的高品質軟體。

本書不到 300 頁的內容,是將RUP 作一個整體介紹,算是一個縮影。作者是由 RUP 的首席架構師 Kruchten 所著,事實上,第一章是由軟體三巨頭之一的 Grady Booch 所撰寫的論文,是本書最有價值的地方;而第二至第六章則涵蓋了 RUP 的流程框架介紹,包括了靜態結構的流程描述與動態的流程行為說明。最能代表 RUP 的是一張看起來像是鯨魚的二維流程結構圖,水平軸代表時間和流程開始後的各個生命週期,也就是分為初始、詳述、建構、轉移等四個開發階段;以及垂直軸代表的是核心工作流程,也就是把活動按照本質加以分類的結果。諸如企業塑模、需求、分析與設計、實作等活動,也稱之為規程 (discipline)。七至十七章則是第二部分的工作流程介紹,是由 RUP 流程開發團隊的工程師們所撰寫的,諸如專案管理的工作流程、需求的工作流程等,包括了工作流程的目的、定義主要的概念、工作人員與工作成果、活動與輔助工具等。這一部份的內容看看參考就好,因為工作流程不外乎是談及什麼人在某個時間點做了什麼事 (產出),以及如何串接等,每一個專案的開發都會是不一樣的,沒有必要也不可能採取統一制式的工作流程。

最佳的軟體開發實務經驗

Grady Booch 在第一章的論文中,揭露出軟體的價值何在,以及所衍生出在軟體開發時經常發生問題的症狀,諸如無法處理需求的變動、模組間無法配合、軟體很難維護與擴充、太慢發現專案的嚴重瑕疵 (Defect) …等。同時也提及了專案雖然有不同的失敗原因,但最主要的原因包括了:不精確的溝通方式、脆弱的架構 (Architecture)、很難處理的複雜性、不一致的需求、設計和實作、測試不足、沒有客服風險等。

從根本問題找解決方案,並應用在商業上證實可行並廣為業界的成功組織所採用的軟體開發方式,而成為 RUP 的關鍵性精髓,也可以說是軟體開發最佳的實務經驗 (Best Practices),包括了:以反覆式 (Iterative)方式開發軟體、管理需求、以元件為基礎 (Component-based)的架構、以視覺化方式製作軟體模型 (Visually Model Software)、持續驗證軟體品質、控制軟體的改變。

當然,這些實務經驗可非一蹴可幾,是需要經過軟體組織持續不斷的學習與摸索,並建立紮實的本質素養方可的。舉個例,光是以元件為基礎的架構這一部份,要能瞭解什麼是元件,要如何適切地切割元件的大小,要如何定義出元件的介面,也可以說就是 Design for Interface,把善變的部分封裝在元件內部,這些可不是容易的事;再則以反覆式的開發方法,聽起來有道理,但做起來卻相當難執行,因為人們一般很難忍受不確定性,尤以專案經理時常抗拒這種開發方式,因為它看起來像是永無止境、無法控制的脫序行為。事實上,反覆式在 RUP 的規範中,是可以被控制的,每次反覆都是以編號、週期和目標妥善計畫。只是因為這一些會衍生出專案管理的其它議題,才使得專案管理人員喜歡循序的瀑布(Waterfall) 開發方法,每一個開發階段都定義了很明確的產出。問題是,我在前兩期介紹 XP 時,也曾提及了,軟體的根本問題在於風險。而瀑布式太晚把風險揭露出來,這在現今多變的需求開發中是早已證實不可行的。若反覆式是證實才能解決軟體開發的根本問題,那麼,無論過程遇到一些阻礙,還是應該堅持來達成。 ”Do the Right thing”後,才能“Do the thing Right”!

本書特別在第四章中,介紹了 RUP 的動態結構即為反覆式的開發方式。這也說明了一件事,那些把 RUP 當作僵化官僚的開發模式的軟體組織,實在沒有去用心體認 RUP 的關鍵精髓,擷取其成功的實務經驗,而只是把它拿來當作應付階層式組織各級主管的工具而已,因為很容易產出美美的文件,用它來交差應付。我在許多比較大型的組織中,的確看到很多這樣的現象,這麼多的軟體開發人才,卻一直在那裡空轉著,浪費太多不必要的資源,殊為可惜。

以架構為中心及使用案例驅動的開發流程

本書第五、六章,揭露出“4+1”的架構觀點,及以使用案例驅動 (Use case driven)的開發流程。架構可不容易被解釋與認知,RUP 是嘗試利用觀點 (View)來解釋架構,以讓軟體開發人員瞭解這些觀點的主要產出 (artifacts),以及如何調和這些產出,並仍能維持有一致性的全貌與見解。

“4+1”共五個觀點,包括了邏輯觀點、實作觀點、程序觀點、配置觀點,還有一個擺在中間的使用案例觀點,利用它來驗證其它觀點,也可以就是利用需求功能來驗證各個階段的開發產出。每一個觀點都有相關角色的開發人員職掌,例如需求分析師會專注在使用案例觀點、結構分析/設計師會專注在邏輯觀點,而程式設計師當然就是著重在實作觀點了。

RUP 是強調“Use Case driven”,但卻不是 “Use Case First”的。兩者的差異在於前者是利用功能需求驗證架構的一致性、結構的彈性、以及實作的完整性等;而後者則是純然以需求作為涵蓋整個系統的建構,卻忽略了其它的觀點,而使得系統不具彈性、延展與可重用性等。國內短線的專案開發生態經常是如此,而導致軟體人員只重視需求的功能面與實作的技術面,卻忽略了軟體的主結構,也使得系統不具應變的特性了。

我為什麼要介紹 RUP? 我不是輕量型 (lightweight)的敏捷式 (Agile)開發流程的擁護者嗎? RUP 給一般軟體人員的印象是僵化、官僚、受控制的重型 (heavyweight)開發流程,事實上,我在熟讀本書之後,更確定了,RUP 的本質精髓與其它所謂敏捷式的開發流程根本就是一樣的,它們均強調反覆式的開發、需求導向、以及對測試的重視,只是作法 (how-to)不一樣而已。而 RUP 被視為是高度儀式化的重型開發製程,這也是被那些崇尚軟體工程的專案管理人員給濫用了,卻忽略了軟體也包括了心理學、哲學與藝術的成分存在,而不是只有工程學而已 [Kruchten 2002]。另外,要注意的是,UML 可以是國際標準,但是流程卻沒有所謂的標準,它充其量只是範本 (Template)、一種框架而已。這麼說好了,團隊開發成員之間可以講相同的語言(UML),以利相互的溝通;但每個團隊要如何達成目標,則各有其方法與程序(Process)來達成任務。程序是“How-to”,每個團隊的“How-to” 是不會完全一樣的。

{iThome 書評—5} 深入淺出設計模式中譯本

深入淺出設計模式
— Head First Design Patterns 深入淺出設計模式 — Head First Design Patterns
———————————–
作者/Freeman, Sierra & Bates/著
譯者/蔡學鏞/譯
出版社/歐萊禮 出版
ISBN/9867794524

內容簡介
寫應用程式時需要依照需求預先規劃、設計,而設計模式累積了前人的經歷,經由四人幫彙整出一系列的設計模式,以利後人可以套用。本書集合四人幫的23個模式(十幾年前的事)外加這十幾年來新增的一些模式,作者群以詼諧、幽默、圖文並茂、打破傳統著書的方式,由淺入深地詳解了設計模式的精神及重點。全書全部以當紅的 Java 程式語言為範例。

前言

幾乎有經驗的軟體人員,手裡都會有一本四人幫 (GoF, Gang of Four) 著作的「設計模式 (Design Patterns)」,此本可以說是軟體業的聖經,書中介紹的 23 個設計模式,已被大量運用在系統框架 (Framework)及應用領域上。不過本書卻是相當的艱奧難懂,如同金庸小說中的「九陰真經」上卷一般,充斥的盡是心法,但若沒有從實務汲取到相當經驗的話 (極少數人是可以透過“內觀”來悟出心法,但那真的相當稀少),是很難領悟並活用這些招式的。所以坊間出版了眾多“「九陰真經」的下卷”,透過大量的實例,來闡述上卷所揭露出的心法。

這些書可以算是「設計模式」的註釋版了,不過大部分仍是以程式碼來作解釋,除了比較不容易解釋設計模式背後的哲理外,也稍嫌沈悶了一點。倒是本書,怎麼說呢?相當相當的特別!跳脫了任何種類軟體書籍的寫作方式,運用作者群在神經生物學、認知科學、學習理論等,來協助讀者將這些設計模式給深刻烙印在你的腦海中。書本封面是一位酷酷的美少女,仰著頭看著你;每一章的封面則是美國 1960 代紳士淑女們的黑白照片,簡單的意象來表達該章節想要傳達的主題;書中內容則是充斥著大量的漫畫式照片、插圖、手稿等,利用問與答的方式,來解釋一般讀者們在學習過程中,常碰到的問題與思考;同時在章節前後陸續列出了九個相當重要的 OO 守則,這些守則也可以說明軟體設計的根本,說真的,要能通透這些哲理,最少也要花上 10 年以上的功夫修煉才有可能運用得爐火純青;喔,還有填字遊戲,利用每一章所讀過的英文句子,來填出與模式相關的關鍵字彙,真的相當有趣,實在是複習的好幫手!

唯一不變的真理就是時常在改變

第一章「介紹設計模式」部分,利用了模擬鴨子游泳戲水、呱呱叫遊戲的案例,來帶出物件導向的四個基本概念:抽象、封裝、多型與繼承,也提及了重要的一件事,OO 不是只為了“做”出來,而是因為 彈性、延展性、可重用性的設計考量,賦予系統生生不息的價值。從設計實作的過程中,你會發現到,好像有些會一再重覆發生的問題,可以利用一些特定的模式來解決該問題。這些模式,可以說是 OO 設計經驗的精華所在,可以讓我們建構出具有良好 OO 設計品質的系統,更可以讓開發者之間有一個共同的字彙,來提高溝通的價值。對了,大多數的模式和守則,都是著眼於軟體改變的議題上,這也就是道出了模式的根本價值在於協助開發者如何應付改變 (Change),“Design for Change”,這可以說是軟體設計不可避免,也是唯一不變的真理了。為了要能應付改變,我覺得有兩條絕對要謹守的原則就是: 1. 將變動的部分封裝起來;2. 針對介面寫程式,不是針對實作寫程式。尤以後者,可以說是絕大部分軟體人員所無法體會的了,這是一種基於“變”的設計態度,卻非實作技術面的議題了。

他山之石,可以為錯

本書是把 23 個設計模式中的 14 個,給擺入到 1~11 章內,利用案例,作相當精闢的解說。剩下的 9 個模式,作者認為比較沒有經常地被使用,所以是放在附錄中,但仍有可取之處,所以也會利用簡單的幾頁說明用法與為何要使用的原因。我想先讓讀者瞭解一下,四人幫的設計模式,是分為三大類:生成 (Creational)、結構(Structural)、行為 (Behavioral)。生成如工廠 (Factory)模式,顧名思義,就是會幫你製造物件,再回傳給呼叫並符合該介面規格的 Client。這在多型的設計,經常會在 Server 端使用生成模式,以免讓你的 Client 與伺服端的具體類別綁住 (不要忘了,Design for Interface);結構模式,則經常反映了問題領域的概念,例如 複合 (Composite)模式,可以表達樹狀的層級,如組織 (Organization)、BOM (Bill of Material)表等;行為面的模式,一般設計者比較不容易能抽象化,因為它可能是根據設計的議題,將原本在分析階段,某一個類別的行為,抽離出來也成為類別,而能應變具再利用的價值。簡單的說,就是把行為當成物件,每一種不同行為的物件,再分門別類,並制訂出共同操作的介面 (interface)規格,與原來擔負某一行為的本體 (context)類別,關連在一起。狀態 (state)、策略 (strategy)、命令 (command)等模式,就是屬於此種行為性的模式。

最後一個章節則是指導你如何學會與設計相處,挺有意思的,它讓你瞭解設計模式的本質與其組成的主要成分;「如果你發現到處於某個情境下,面對著一群限制的問題,正影響著所欲達成的目標,然而,你能夠採用某個設計,克服這些限制並達到該目標,將你領向某個解決方案。」情境 (context)、問題、解決方案 (solution),正是組成模式的三個主要組成元素。當我們仔細觀察其定義後,進而,能組織並活用這些設計模式,更甚者能融入於心智、成為隨手拈來可得的利器,而創造出自己的模式,造福他人,成為共同溝通的語彙,那可真的是一種心靈上的愉悅,設計模式的威力與目的,正是如此。

本書很厚,600 多頁,但閱讀因為太輕鬆了,你完全感受不到厚厚的一本,還會覺得意猶未竟。眾多推薦人當中,竟然還有美式足球的明星球員推薦呢,真的難以想像,他怎麼有時間看這類的專業書籍? 但也可想而知,本書的易讀性,就是這樣地讓人可以把它帶到健身房,一邊閱讀,還能臉上堆滿笑容。

軟體思維顧問

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

Personal