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

Adapter 設計模式案例與 UML 解答

有位網友以 Email 問了一個關於 Adapter 設計模式的情境描述:
 KWBank 收購了 BankOne , 怎樣用 Adapter pattern 將兩者 的 客戶資料整合….?

他說看了這篇教學:Design Pattern—Adapter 模式,仍舊不瞭解該如何解答。

這邊我就一併列出回覆給該位網友的回應,供讀者們參考:

基本上,Adapter Pattern在使用上,會比較針對『Service』來進行設計。
參考下圖,在這個設計中,兩個Adaptee Class負責擔任如2孔轉3孔的插座一樣,至於新銀行的所有Client程式,則是直接面對CustormerAdapter的物件;如此一來,就可以隔絕掉不必要的外部程式碼,所有跟外部溝通的,都透過Adaptee的物件去存取。

圖 1、範例—訂購系統的類別圖(Class Diagram)
(點擊圖片鏈接看原圖)圖1、範例—Adapter 設計模式案例圖

{iThome 書評—3} 使用案例寫作實務中譯本

使用案例寫作實務中譯本
— Writing Effective Use Cases 使用案例寫作實務中譯本 — Writing Effective Use Cases
———————————–
作者/Alistair Cockburn/著
譯者/趙光正/譯
出版社/碁峰出版
ISBN/9867727681

內容簡介
完整討論使用案例的關鍵部分,包括參與者、關係人、設計範圍、情節等等。提供完整的使用案例寫作指導,包括寫作步驟與推薦格式。提供一大堆省時有效的使用案例寫作技巧。提供有用的使用案例範例,並且說明範例適用的時機。

這本書的好處就是實例超多,一般的書中對使用案例的介紹都很簡單,或者範例不足,讀一些原則如果沒有範例配合,有時候還真的像在隔靴搔癢。

這本書提出兩個概念:1.把使用案例依照設計範圍(design scope)或者系統範圍(the extent of the system )分為三個層次(第三章)1.Enterprise (business use case) 2.System(system use case) 3.Subsystem(component use case) 2.依照使用案例所達成的目的(goal )分為三層(第五章)1.Summary goal 2.User Goals 3. Subfunctionas 當你在畫使用案例時,思緒先粗再細,就我自己的經驗,高層次的使用案例,數量不會太多,容易控制,也比較能夠用巨觀看事情。管理大量的使用案例時,除了使用高層次的使用案例外,通常也會用到很多使用案例間的關係(第九章,第十章),或者把使用案例組織一下成套件(package)管理(第十三章)。 還有,就是一般人會問使用案例是否等於需求?不過本書對這部分著墨稍嫌少了一點(第十六章),還好,它補了一章說明使用案例與整個開發流程的關係(第十七章),裡面提到使用案例 v.s. 系統特性(System Feature),作者蒐集了很多的使用案例格式(第十一章),作者把寫使用案例當成寫作文,所以整本書是在教導你如果寫出一篇篇的短文(使用案例),當然而會有類似教作文的起承轉合(第六章,第七章,第八章)。

前言

使用案例 (Use Case) 是由 Jacobson 在易利信公司做電信系統時,所發明的一種描述系統行為的工具,並隨著 UML 規格的制訂,而成為普遍被用來作為需求捕捉最關鍵的技術。我是認為,使用案例可以說是這十來年來軟體界最了不起的創見! 因為它簡單,使用案例圖,利用棒型人偶 (參與者)表達使用系統的使用者與系統需要外部系統的支援服務,而橢圓形的使用案例即是表達一個個系統所提供的功能服務;然後再以純文字的寫作方式,來描述每一個使用案例的需求陳述,也可以說是參與者與系統之間的互動對話,卻又不致牽涉到系統的實做面 (把系統當黑箱)。簡單的圖形,加上文字敘述,就可以建構出從使用者角度來看系統功能觀點的使用案例模型。

不過很奇怪,使用案例易學難精,沒有把握基本精要與原則,很難把圖給畫好 (不容易界定出系統範圍),更何況是用純文字來寫出需求陳述。耶? 純文字的寫作這麼困難嗎? 是的,它真的不容易,我還常建議需求分析人員,多勤讀「古文觀止」,來充實散文的寫作能力。

我大概看了有五本寫使用案例的書籍了 (均為原文著作),發現到每位作者對使用案例的闡述,歧異還蠻大的,可以說是“各自表述”,而且多少都已經有加入作者本身的觀點,擴展 Jacobson 的使用案例理論。老實說,我對使用案例的技術相當著迷,但學習該技術的前兩年完全不知所云,一點都無法體會出它的本質精髓 (只學會一些使用的功法而已),直到吸收了兩本好書:“Use Case Requirements in Context”,以及本次書評的主角,才慢慢打開心眼。尤以本書,我起碼看了半年以上,讓我對所謂的層次、目標等級、寫作原則與風格等,可說是奠定了相當清晰的基礎功夫了。

腦力激盪的最佳工具—記錄需求、發掘需求

本書不算薄,22 個章節,外加四個附錄,內容分為三大部分—使用案例的主體、相關議題的討論、寫作提示等。一開始閱讀會有些吃力,尤其第一部份,其實內容有些零散。我是建議要隨時翻閱目錄,瞭解自己在閱讀時的主題與焦點所在,若當下無法體會,其實跳過去也無妨。

第一部份最重要的是當然要瞭解使用案例的本質,以及寫使用案例的格式,Cockburn 提供多種寫作的格式供參考,如單欄/兩欄/RUP,甚至利用 Occam 程式語言、圖形呈現的另類寫作風格,相當有意思! 另外最有價值的部分,也是 Cockburn 自創的三個目標等級—白雲、海平面、海平面下,來說明使用案例的精確程度,以及適合的目標層級對象。第二部分算是 FAQ 性質的一些主題性的討論。例如最常見的 CRUD (Create, Read, Update, Delete) 與 可參數化 的使用案例該如何描述比較恰當;開發流程中,使用案例所扮演的角色與其它製程產出的關連性;常見的寫使用案例所發生的錯誤 …等,對於實務已經在應用使用案例開發的人員來說,相當具有參考價值。第三部份是我覺得本書最實用的部分了,尤其第 20 章,單一寫使用案例的相關寫作提示,就足以讓需求分析人員受用無窮了,因為以我所看過太多位 SA 所寫的使用案例,幾乎所犯的錯誤,在本章都有提到。所以只要依循本章所列出的十一個寫作提示,要寫出中規中矩的案例敘述,也就不會是什麼難事了。

有意思的是,即使你寫的是中等程度的使用案例,都還來得比其它種類的需求文件還有用,事實上,只要能具可讀性,對整個專案就會有相當的貢獻;再則,使用案例不僅僅只是記錄需求的工具而已,它更可以成為專案成員的腦力激盪工具,來發掘出新的或潛在性的需求,這更是價值斐然!

順應國內短線專案型態—Use Case First

一般而言,使用案例會成為「物件導向」式專案開發的最佳前導工具,雖然它與物件導向一點都沒有關係。本書在國外的評價相當高,但在國內卻不賣座,這多少與本書完全沒有提到如何將使用案例與系統的結構設計至實做的橋接有關,純粹就是在談使用案例的寫作而已。而事實上,國內 95% 以上的專案都是偏以功能導向的開發為主,至於系統內部的結構分析設計,因為時程的壓縮與抽象基礎的素養不足,往往無法做好。功能會直接影響到專案能否被“做出來”;結構則是影響系統的彈性與穩定度。所以個人是主張“務實一點”,先順應國內短線的專案生態,利用使用案例,快速的給直接 mapping 到實做面。

我在實際輔導的經驗中,效果與接受度相當高;雖然是“Quick”,但可不“Dirty”,兩個配套措施是一定要做的:測試案例到測試程式碼,隨時驗證功能的正確性;分析類別的規劃,以符合 3-tier 的 MVC (Model-View-Control) 框架。系統做的出來,開發能力也有比較提升,老闆也比較願意投入更多資源的情況下,再施以結構重整,慢慢粹取出系統最穩定、共用的那一部份。有了使用案例後,我好像就再也沒擔心過能不能“做”得出來,那根本已經不是問題了。

五顆星級的好書,價值多少?

在 Amazon 評價四顆半星的好書,你猜猜看台灣賣多少錢? NT$ 99,沒錯! 你沒有看錯,國內販售軟體書籍指標的「天瓏書局」竟然將本書折扣到一折半,不到一百元可以買到寫使用案例叢書中最棒的書籍,但,卻仍舊乏人問津,我真的很難以想像,需求分析人員,省一到兩次的便當錢,總該可以吧? 好歹,本書真的可以在工作上幫助你太多太多了。

WFMC Workflow Reference Model 摘要

利用 UML 複合結構圖 表達 WFMC Workflow Reference Model

圖 1、Workflow Reference Model 複合結構 (Composite Structure)圖
(點擊圖片鏈接看原圖)圖 1、Workflow Reference Model 複合結構 (Composite Structure)圖

Interface 1,2&3,5 摘要解釋

Interface1: Process Definition

  • 描述工作流程的定義—XPDL (XML Process Definition Language)
  • 提供 APIs 以操作流程定義的相關資料。
  • XPDL 係為 XML 的檔案格式,可作為流程定義開發工具之間互通的標準 (如同 UML 塑模的 XMI 交換規格)。
  • XPDL 也可作為 BPMN (Business Process Modeling Notation) 語法的檔案格式。

Interface5: Administration and Monitor Tools

  • Workflow 活動過程中,需要被捕捉、紀錄與稽核的資訊。
  • 定義了哪些資訊需要被捕捉記錄,並作為分析之用;但沒有定義資訊是如何被儲存。被捕捉的資訊稱為 CWAD (called Common Workflow Audit Data)。
  • CWAD 會被 Workflow 的管理與監視工具操作存取使用。

Interface2&3: Client Application Programming Interface

  • 提供跨產品 Workflow Engine (需符合 WFMC 認證規格) 的一致性存取方法。
  • 所提供的 APIs 稱之為 WAPI (Workflow Application Programming Interfaces)。
  • Workflow Engine 所提供的核心服務,其對象 (Client Application) 為 表單 (Form)、控制物件 (Control Object)、其它 Workflow Engine …等。
  • WAPI 群組功能分類
    • WAPI Connection Functions
    • WAPI Workflow Definition Functions
    • WAPI Process Control Functions
    • WAPI Activity Control Functions
    • WAPI Process Status Functions
    • WAPI Activity Status Functions
    • WAPI Worklist Functions
    • WAPI Administration Functions

{iThome 書評} UML 與樣式徹底研究中譯本

UML與樣式徹底研究
— Applying UML and patterns UML與樣式徹底研究 — Applying UML and patterns
———————————–
作者/Craig Larman/著
譯者/趙光正/譯
出版社/碁峰出版
ISBN/986779026X

內容簡介
這是全世界介紹物件導向分析與設計、反覆式開發方式與UML的書當中,銷售量最好的一本書!「UML與樣式徹底研究」可幫助任何開發人員精通物件導向分析與設計的核心開發原則與最佳實務經驗,讓大家不只是畫畫UML而已,而是真的能把它活用在軟體設計情境中。

著名的物件技術與反覆式開發方法先驅Craig Larman在本書中用單一、具有一致性的個案研究,具體呈現開發過程中的三個反覆。透過這三個反覆,逐步介紹物件導向分析與設計中的關鍵技能,並且點出最必要的開發活動、開發原則與樣式。

本書內容涵蓋了:
l.需求與使用案例:發掘需求並記錄
2.產生領域物件模型:了解領域中「有興趣的物件」、它們的屬性以及它們之間的關係
3.架構:為了讓應用程式具有最大的彈性、強固性與可維護性,採用分層式架構設計系統
4.必要的物件設計技巧:專精一些如分配物件責任及根據一些開發原則設計物件間的合作關係的關鍵技能
5.設計樣式:用很流行、常用的樣式產生強固的物件與框架,如策略樣式、代工廠樣式、轉接器樣式、觀察者樣式、範本方法樣式與命令樣式
6.反覆式開發方式與「敏捷式統一流程」:用UP(一種很風行的反覆式流程)中簡單、不可或缺的開發活動與最佳實務經驗組織建立模型與開發系統的流程
教師資源:http://www.phptr.com/larman/. Includes PowerPoint lectures, sample exam, and more

前言

中譯本是翻譯自「Applying UML and Patterns 2nd edition」 (目前原文已出至第三版)。本書可以說是所謂物件導向分析與設計最為暢銷的入門教科書,事實上,也是我踏入軟體設計領域的第一本入門書,也可以說是與我最有緣份的一本書。想當年我是擔任系統與資料庫管理者,其實與軟體開發實在扯不上關係,是因為興趣,想寫圍棋軟體的關係,當時硬K了 Java 程式設計入門,花了三天的時間,寫出一大串、可以點選下子的圍棋程式(當然,不含 AI)。寫完後,一點成就感都沒有,我一直很疑惑的是,Java 的程式單位是 .class,那麼,圍棋的棋盤與棋子是分為一個還是兩個 class 呢? 問了幾個程式開發的高手朋友們,得到的答案都很不滿意,他們都認為分為幾個都無所謂,能寫出來就好。我還記得很清楚,我聽到有所謂的物件導向式的開發技術後,為了能解除心中的疑惑,某天晚上下班時特地到重慶南路的「巨擘書局」翻書。找了約三個小時,抱回四、五本 OO 書籍,花了有五千餘元,而其中有一本,就是本次書評的主角。當然,沒有一本我看得懂,所以,後來還到了國內主推物件導向的宗師—MISOO 物件教室上課。而在上課之前,我就是把本書(當時是第一版,原文,沒有中譯本)給整本硬K完畢,然後,就其中的內容與問題,逐條的請教當時授課的講師(他們對我蠻頭痛,一直想追到答案)。而也因為此,讓我對軟體產生的莫大的興趣,並因此而轉行,從此踏入軟體設計這極為深奧的殿堂。

本書的大綱架構安排得非常之棒,可以說是最為標準典型軟體工程式的教科書,所以國內已有幾所大學,將其作為資管/資工科系的教材。作者 Craig Larman(我都稱他為 拉麵,諧音),可以說是把他多年來豐富的教學經驗,全都給濃縮在本書內。尤其自第二版後,還導入了 UP(Unified Process) 流程框架至本書的大綱目錄內,讓讀者大概瞭解一下 UP 的 Milestone 階段目標,與每次反覆(Iteration)的產出(artifacts)有哪些。本書是界定為入門書,也的確獲得眾多軟體人員的喜愛,覺得它容易閱讀且淺顯易懂;不過有趣的是,我也問過許多 SA/SD,看完本書後,還是不知道如何寫程式。除了它僅用一個章節展示如何從設計轉成片段的 Java 程式碼,使得讀者並不知道系統實作涵蓋 n-tier 應用程式的全貌,還有,本書充斥了許多的假設點,若讀者不知道的話,其實很容易誤解其原意。

系統開發的基本—瞭解需求

對於入門者而言,需求是本書最有價值的部分。讀者會發現到,這本書可以說就是以需求作為系統開發的初端,再進而導出系統內部的結構分析、設計至實作等。使用案例模型 (use case model)的建立,是功能性需求最重要,用來發掘並記錄需求的一種機制。而且,它還會影響到系統開發爾後的諸多環節。UP 所倡導的“4+1 View”,即是以使用案例作為驅動並涵蓋整個專案的重心所在。我覺得本書在使用案例敘述的部分寫得相當好,同時也揭露出多種不同的寫作格式與風格,讓讀者得以選擇適當的需求寫作方式。除了使用案例外,作者也介紹了輔助規格(記錄非功能性需求)、企業規則、字彙表、專案願景等其它性的功能需求,其實,這也是 UP 所建議,在需求製程的產出。(參考一下其範例的寫作方式也不錯,但,可不要全盤照收,而造成軟體開發諸多不必要的儀式與負擔)

物件導向分析設計的精髓—物件責任的分派

這是本書最為精彩之處,也是我在其它書籍所看不到的—物件責任的分派 (responsibility assign)。事實上,對老手而言,光看這一部份就值回票價了。對SA/SD,責任的分派,是最被為忽略、不受重視的;但相對來說,要能真的把軟體作軟,可以說這一部份才真正是所謂物件導向分析設計的精髓。舉個例,誰有責任負責訂購總額的計算? 訂購物件。 一般 SA 可不重視這,可能就寫在 表單(Form)、stored-procedure、或者在功能性的物件上。因為行為的分散,其實就是造就系統混亂、複雜的主因。

由於如何熟練指派責任是 SA 在物件設計中最為重要的事,Larman 提出了 GRASP 的設計原則 (General Responsibility Assignment Software Patterns),裡面提出五種重要的責任設計樣式。我覺得其中兩個—高內聚力 (high cohesion)與低耦合 (low coupling)性,其實就是決定軟體核心的穩定與否。而此兩者樣式也經常相互衝突,它們之間的關係,可以說就是軟體工程的陰與陽,它們會彼此牽制且影響對方。

系統內部的靜態結構分析—找出物件

需求分析與物件責任的分派,是本書最有價值之處;但 如何找出物件 這一部份,也就是建構領域模型,進而產出軟體規格設計圖,我是覺得寫得不太好。 Larman 仍是以傳統的方式—利用找名詞的方式,來找出概念性類別。雖然他又列出了概念性類別分類清單,來協助 SA 找物件,但這仍不是好方法,因為這是從需求的片段記錄來找尋物件,但需求並不穩定,相對來說,也不容易找出最具本質性(essential)的核心物件。當初我在看這一部份時,著實疑惑甚久,後來閱讀了 Peter Coad“Object Modeling” 一書,揭露出以交易為核心,來找出本質性的領域物件,才總算得到滿意的解決方案。

結語

後面幾個章節,其實可以忽略不看,如果你不知道它的假設點的話。例如利用設計樣式設計出永續性框架 (persistent framework)。請記得,你是在開發領域層級的應用系統,而不是在開發應用伺服器(application server)。永續性框架,系統廠商,如 .NET 的 ADO.NET,以及 J2EE 的 Hibernate 等,都會幫我們作得很好,我們只要學會如何用就好,瞭解內部 O-R mapping 設計,意義其實不大。還有,關於四人幫的設計樣式 (design pattern),本書也有介紹一些,也是看看就好,因為這方面,倒不如直接看四人幫的原著。

本書共 600 餘頁,而且是以一個案例研討 — POST 系統的開發,作為涵蓋整本書的內容。從需求分析記錄、領域模型建立、物件責任分派、至系統規格模型設計 …等。讓讀者因為有實際案例一步步作下來,而能對本書有一致且流暢地串連起所有章節。

與前一期所介紹的「UML 精華」一書,這兩本是我常掛在嘴裡,鼓勵軟體從業人員必買(當然要看)的兩本好書,又因為翻譯品質甚佳,去除了語言上的隔閡,實在沒有藉口不看。我鼓勵軟體公司至少都要擺上一本,甚至舉辦讀書會。

{iThome 書評} UML 精華第三版中譯本

UML精華第三版--標準物件模型語言
— UML Distilled Third Edition UML精華第三版–標準物件模型語言 — UML Distilled Third Edition
———————————–
作者/Marting Fowler/著
譯者/趙光正/譯
出版社/碁峰出版
ISBN/9861540393

前言

我教授軟體設計課程多年來,經常對學員建議要常看書,但不是看使用手冊這類的操作性 How-to 書籍,工具書若是因為工作需要,擺著幾本當作參考無妨;或者,若能學會如何交一位好朋友—Google 那更好。從它那裡,可以找到太多 How-to 性質的答案。而到最後你就會知道,學會快速操作使用,原來就是要懂得如何下對搜尋的關鍵字,如此而已。How-to 是越來越容易從網路上找到答案,相對來說,軟體開發人員,就可以把更多的時間與心思擺在軟體設計的思維上。而著重軟體設計的書籍,還真的是只有國外幾位頂尖軟體大師的著作可以學習。只是軟體人員一般會對原文書籍有恐懼感,以及,經常會有一種讀書的壞習慣—想要把它看懂。嗯,想要看懂是壞習慣,沒錯! 所以看書才會覺得有壓力,才會想要從第一頁看到最後一頁,然後大多數都只看到前三章就看不下去了。閱讀軟體設計書籍就是要不求甚解,沒必要想要得到所謂 “唯一的答案”。就是如同看漫畫、金庸小說般,那是一種享受,是對某一主題來作思考與體悟。當然,你起碼就要能分辨,你所選閱的軟體書籍是否原作者有自己的 “想法”,那很重要! 沒有自己想法的書籍,實在相當多,難怪乎有許多讀者 “看不懂” 坊間所謂的 “物件導向系統開發” 的書籍,我覺得是蠻正常的。當你能 “感受到” 作者想要透過書中的文字,來表達他的想法,甚而,還逐漸能猜得出作者內心中的 “假設點”,那麼,你就能知道,這是一本可以值得學習的好書!

「UML 精華(UML Distilled)」,是軟體設計叢書中,最能表達出作者自我又帶著創意性的想法。只是以閒話家常的方式,以口語白話的文字表達,只有薄薄的一本書,卻能精彩活化描述出 UML (Unified Modeling Language, 統一塑模語言) 十三張設計圖的精髓。我覺得 Kobryn (UML 規格制訂主席) 在推薦序文內說得最好:「自古以來,天縱英才的架構師與最具智慧的設計師都瞭解何謂 “簡約之道 (the law of parsimony)”。」 他甚而還引用了佛家禪宗的心法來解釋簡約之道:「禪宗的心是初學者的心」。而軟體與佛家的智慧是一樣的,是不受時空限制的,其要旨均在於如何將繁雜的表象萃取其本質 (essence),讓形體 (form)可以很協調地與功能融合在一起。

Martin Fowler,正是軟體界具有真正智慧的軟體大家! 所謂的 “簡約之道”,真正在本書中發揮得淋漓盡致。他就是能用迷人、口語化的寫作風格,來寫出「UML 中最有用的一小部分」,而這一部份,正是可以幫你完成百分之八十工作的百分之二十的精髓 (8/2 法則)。 Fowler 是我在軟體業界最為景仰的大師,想想看,有誰能從架構、分析設計至實作的垂直層次寫出這麼多的經典書籍呢? 包括了 “Analysis Pattern”、”Refactoring (重構,國內由侯捷大師翻譯)”、”Patterns of Enterprise Application Architecture” 等。 對於 Martin Fowler,真的也只能想到 “天縱英才” 這樣的字眼,來表達出我個人對他的尊敬與崇仰。

先瞭解本書的架構大綱

從一本書中的目錄,大概可以知道作者所要表達的核心思維會擺在哪裡。前兩章論及了軟體開發方法論 (methodology),這裡理所當然會介紹 UML 的簡介,以及現今主流的開發流程;然後從後續的章節,就是以每一個章節來介紹 UML 十三張圖;而關於類別圖,Fowler 則是用了兩個章節來作說明。而且蠻特別的是,第三章就開始介紹類別圖了,這可是與一般軟體設計書籍最大的不同之處—先從需求分析著手。至於需求面的設計圖,包括了使用案例圖與活動圖,則是擺在中間的章節,從第九章起才開始介紹。從這樣的編排來看,你就可以知道 Fowler 最為重視的會是軟體的結構分析,而這也是本書最精彩之處,包括類別圖與循序圖的介紹與其想法的論述。

軟體開發方法論 — UML 與 開發流程

所謂的方法論包括了兩大要素:溝通的機制與開發流程。 UML 正是利用圖形標準化的模式語言,來作為團隊開發之間溝通的最佳機制。Fowler 在對 UML 的簡介裡,說明了 UML 的發展歷程—由三巨頭的統一方法論而成形的;歷史的典故瞭解一下就可以了,不過,Fowler 很幽默,還提及了在 95 年的 OOPSLA 大會上,Rumbaugh 的高聲一曲來作為慶祝 0.8 版草案的問世。嗯,大家都希望那會是最後一次聽到他的歌聲。 🙂

Fowler 也提了對 UML 的用法,有分為草稿式與藍圖式。前者是將 UML 圖形作為溝通的機制,不講究精確的語法;後者則是要求精確性高的設計,而以此可以讓程式設計師依樣畫葫蘆寫程式。嘿,我也與 Fowler 的想法是一致的,比較偏向草稿式的作法。道理很簡單:1. 你不能假設你的設計會是正確無誤的;2. 絕大部分的軟體人員,連 “畫出來” 都不太有勇氣了,更何況要求僵化的工程模式? 那可會嚇跑一堆軟體人員,而違背圖形模式開發的的本質—溝通。

雖然是介紹 UML 語法,不過 Fowler 還是特別開出一個章節來介紹開發流程。在該章節中,首先就比較了所謂反覆式(iterative)與瀑布式(waterfall)的開發風格。現今主流的開發流程都一致認同反覆的開發方式,但卻很難做得到,因為會衍生不確定性的恐懼感,與專案管理的議題。Fowler 用了一個很有趣的字眼,「偽反覆式開發方式 (原文是用 pseudo,我覺得真的很客氣,不是用 fake)」:雖然大家都宣稱正在採用反覆式開發方式,不過實際上卻仍是瀑布式的開發方式。哈,這與我經常在課堂上常提,導入如 RUP 軟體製程的開發公司,大部分是 “藍皮綠骨”,因為他們根本就作不到使用反覆的開發方式;因為,他們會重視制度與管理,卻經常忽略了人本—而這正是反覆式導入成功與否的關鍵所在。

章節後面則簡述了關於 “敏捷式(Agile)”、”極致軟體製程(XP, eXtreme Programming)”、”RUP (Rational Unified Process)” 的比較。我覺得 Fowler 在這部分道出了開發流程的本質:流程僅是框架,只是一種建議、一種範本,可千萬不要傻傻的以為導入某一開發流程就可以解決軟體的根本複雜問題。我最喜歡其內的一個字彙:裁適 (tailor)—要懂得裁減開發流程以符合專案的需要。

軟體系統的根本—結構的分析與設計

UML 最重要的一張設計圖就是類別圖 (Class Diagram),作為軟體大家,Fowler 是最為重視軟體的結構分析與設計,而這也是軟體根本所在—非從表象的需求來看待系統的開發,而是直指核心,找出軟體的本質。

兩個章節中,基本概念是介紹了類別圖的基本語法,而在高等概念則是說明了類別之間的關係,與一些比較少見,如關連類別、範本類別等的說明。要看這兩個章節,最好能有對所謂物件導向觀念有基礎功夫,如什麼是物件、類別 (老實說,即使對老手而言,可能還不一定清楚物件與類別的區分)。高等概念其實不容易看懂,更何況,這還只是介紹語法而已,並沒有教你如何抓本質性的類別,那會是很需要抽象高層次的悟性,是與 IT 技術沒有多大關連的。

真要談到程式設計人員會關心的,反而不是類別圖,而會是表達物件互動的循序 (Sequence)圖了。Fowler 提到了所謂集中式與分散式的控制設計方式,這裡他寫的真是精彩,相當有趣! 你會發現到,Fowler 沒有說集中式控制方式的不好之處 (事實上,這是最容易的開發方式,但嚴格說來,它根本不是物件導向),他用了另外的說法:就是強烈要求寫集中控管的軟體人員採用分散式的設計風格,也不說明為什麼,但總有一天,他們會恍然大悟,這時候,他們的腦袋將彷彿重生。這真是最高段的損人不帶任何髒字:重生之前到底這些軟體人員的腦袋是長什麼樣子?

系統的外觀—需求分析

第九章以後 Fowler 才提到了需求的分析,使用案例模型 (Use Case Model) 與活動 (Activity)圖。使用案例模型包括了案例圖與敘述,Fowler 在此並沒有著墨甚多,只是針對基本的語法作說明。事實上,在案例敘述這一部份,他其實是參考了 Cockburn “Writing effective use case (中文譯名:使用案例寫作實務)” 一書。然後他還特別提了:對於使用案例,請把自己的精力放在說明文字,而不是在圖上,使用案例敘述才是全部價值之所在。喔,正是由於這段敘述,我並不那麼為然,還特別開了研討會來說明使用案例圖的價值與妙用。其實呢,要先釐清假設點:需求敘述對需求分析人員是最重要的,那沒錯;但是,使用案例圖則是軟體架構師的利器—用來界定系統開發範圍,區分內與外,決定那些要作、那些不作。

其它的設計圖

Fowler 很有意思,他不覺得重要的設計圖,即使是一個章節,大概就是一頁的文字說明,再加上一張範例圖就結束了,也不囉唆。例如部署(deployment)圖、互動概觀 (interaction overview)圖、時序(timing)圖 (讓我想起電子實習的示波器,真是噩夢)等。我是把這些設計圖稱之為 “雞肋” — 食之無味、棄之可惜。

倒是還有兩張蠻有價值的設計圖:狀態(state)圖與複合結構(composite structure)圖。 第三版改版最多的部分就是在狀態圖的說明,它會與嵌入式系統設計或者複雜的畫面狀態設計有相當的價值貢獻;而複合結構圖則是 UML 2.0 規格最有價值的一張新視圖,它同時結合了類別與元件(component)圖的優點—表達整體系統對外的介面,以及系統內部的結構組成元素。

結語

這本書目前出到了第三版,我則是每一版都買,而且你會發現到,Fowler 在每一版的制訂,並不是新增補充而已,而是會把他當下對 UML 的心得與體悟,給整個重新寫到修訂的版本內,但仍還是可以維持那麼 “薄薄的一本”。三不五時,我仍會拿出來翻閱,還不時會發出會心的微笑;而且你會發現到,新手看了本書,收穫甚多,而老手再重新看時,卻又仍有不同的深刻體會,這本書就是如此的精彩!

譯者趙光正先生,他翻譯過許多相當棒的軟體設計好書,甚而在下一期我準備介紹的書評—「UML 與樣式徹底研究」,也是由他所翻譯的。而這兩本,正是我極力推薦每位軟體從業人員都應該要必備的好書! 也因為有如此高品質的翻譯本(幫光正君掛保證,他翻譯的每一本書都很棒),使得初學人員不致因原文的學習障礙而打退堂鼓 (當然,就長期而言,軟體人員還是要學會與習慣於閱讀原文書籍)。

※參考之前寫的書評

軟體思維顧問

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

Personal