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 精華」一書,這兩本是我常掛在嘴裡,鼓勵軟體從業人員必買(當然要看)的兩本好書,又因為翻譯品質甚佳,去除了語言上的隔閡,實在沒有藉口不看。我鼓勵軟體公司至少都要擺上一本,甚至舉辦讀書會。
Hi sistone:
第一本:Object Models
Hi a01:
不然喔,物件的管理,會交由系統的應用伺服器來控管。
在有些時候~~
把物件擬人化倒是還蠻有用的~~
不過倒是物件一多起來..
管理上倒是還蠻頭疼的..
請問文中題及之Peter Coad“Object Modeling” 一書指的是
Object Models: Strategies, Patterns, and Applications (2nd Edition)
or
Streamlined Object Modeling: Patterns, Rules, and Implementation
Hi Yih-Bin:
與其說忽略 UML 的精神,倒不說忽略了軟體設計的本質為何。 ^^
UML 沒那麼重要,重要的還是軟體人員的設計思維,你若能之道你在想什麼,然後能把它給表達出來,分享予他人,這比較是 UML 所重視的方向—溝通。
感謝Kenming前輩介紹的好書
之前學習UML一直抓不到重點
後來到您的網頁上逛逛
看了您分享的文章
也才知道原來過去我在過於在意如何把類別圖轉換成程式碼
而忽略UML的精神所在
您提到的兩本書
我都已經去買囉
再次感謝您介紹好書