http://www.ithome.com.tw/itadm/article.php?c=44561
軟體設計必讀經典(1)
| 軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分 | ||
| 文/ iThome (記者) 2007-07-29 | ||
| 《UML精華（UML Distilled）》的作者以口語化、精簡的文字，活化描述UML13張設計圖的精髓，幫助讀者完成80%的工作。 | ||
教授軟體設計課程多年來，我經常建議學員要常看書，但不是看使用手冊這類操作性How-to書籍，若是因為工作需要，工具書擺著幾本當作參考無妨；或者，學會在Google下對搜尋關鍵字那更好，可以更快找到How-to 性質的答案。 拜搜尋技術發達之賜，我們越來越容易從網路上找到How-to答案，相對來說，軟體開發人員就可以把更多的時間與心思用在軟體設計的思維上。不過，著重軟 體設計的書籍，只有國外幾位頂尖軟體大師的著作可以學習。只是軟體人員一般會對原文書有恐懼感，加上經常會有一種閱讀的壞習慣──想要從第一頁看到最後一 頁，結果大多數人只看到前三章就看不下去了。 讀軟體設計書籍要「不求甚解」，沒必要追求所謂「唯一的答案」，要如同看漫畫、金庸小說般去享受，對某一主題作思考與體悟。不過，前提是你必須要 能分辨出作者是否有自己的「想法」，沒有自己想法的作者相當多，導致許多讀者看不懂坊間所謂的「物件導向系統開發」書籍。當你能「感受到」作者想要透過書 中的文字，表達他的想法，甚而，還逐漸能猜得出作者內心中的「假設點」，那麼，這就是一本可以值得學習的好書！ 用UML 20％的精髓完成80％工作 《UML精華（UML Distilled）》，是軟體設計叢書中，最能表達作者自我又帶著創意性想法的好書。作者以口語化、精簡的文字，活化描述UML（Unified Modeling Language，統一塑模語言）13張設計圖的精髓。 我覺得Kobryn（UML 規格制訂主席）為本書所寫的推薦序形容得最好：「自古以來，天縱英才的架構師與最具智慧的設計師都瞭解何謂「簡約之道 （the law of parsimony）」。」 他甚而還引用佛家禪宗的心法來解釋簡約之道：「禪宗的心是初學者的心」。而軟體與佛家的智慧是一樣的，是不受時空限制的，其要旨都在於如何從繁雜的表象萃 取其本質（Essence），讓形體（Form）可以很協調地與功能融合在一起。 Martin Fowler，正是軟體界具有真正智慧的軟體大家，能將「簡約之道」，真正在本書中發揮得淋漓盡致。他就是能用迷人、口語化的寫作風格，來寫出「UML 中最有用的一小部分」，而這一部分，正是可以幫你完成80％工作的20％的精髓。 以軟體結構分析為重點 本書前二章談軟體開發方法論（methodology）；後續的章節，則分別介紹UML的13張圖；關於類別圖，Fowler 則用2個章節說明，其中，與一般軟體設計書最大的不同，是在第三章就談類別圖，先從需求分析著手。至於需求面的設計圖，包括使用案例圖與活動圖，則擺在中 間的章節。 從編排來看，可以知道 Fowler 最重視軟體的結構分析，而這也是本書最精彩之處，包括類別圖與循序圖的介紹與其想法的論述。 軟體開發方法論：UML與開發流程 方法論包含二大要素：溝通的機制與開發流程。UML正是利用圖形標準化的模式語言，作為團隊開發之間溝通的最佳機制。Fowler 在UML簡介裡，說明了UML的發展歷程，這部分只要稍微了解就可以。 Fowler也提到對UML的用法，分為草稿式與藍圖式。前者是將UML圖形作為溝通的機制，不講究精確的語法；後者則是要求精確性高的設計，讓 程式設計師能依樣畫葫蘆地寫程式。我的作法與Fowler的想法一致，比較偏向草稿式。道理很簡單：一、你不能假設你的設計會是正確無誤的；二、絕大部分 的軟體人員，連「畫出來」都不太有勇氣了，更何況要求僵化的工程模式？那可會嚇跑一堆軟體人員，也違背了圖形模式開發的本質──溝通。 雖然是介紹UML語法，不過Fowler 還是特別開出一個章節介紹開發流程，比較往覆式（Iterative）與瀑布式（Waterfall）的開發風格。 現今主流的開發流程都一致認同往覆的開發方式，但很難做到，因為往覆式開發會衍生出不確定性的恐懼感與專案管理的議題。Fowler 用了一個很有趣的字眼，「偽往覆式開發方式（原文是用 pseudo，我覺得真的很客氣，不是用fake）」：雖然大家都宣稱採用往覆式開發方式，不過實際上卻仍是瀑布式開發方式。如同我在課堂上常提的，導入 如RUP軟體製程的開發公司，大部分都是「藍皮綠骨」──重視制度與管理，卻忽略了人本──而人本正是往覆式導入成功與否的關鍵，所以根本作不到往覆式開 發。 另外，關於「敏捷式（Agile）」、「極致軟體製程（XP，Extreme Programming）」、「RUP （Rational Unified Process）」的比較。我覺得Fowler在這部分道出開發流程的本質：流程僅是框架，只是建議、範本，不要以為導入某一開發流程就可以解決軟體的根 本複雜問題。我最喜歡書中的一個字彙：裁適（tailor）──要懂得裁減開發流程以符合專案的需要。 軟體系統的根本：結構分析與設計 UML最重要的一張設計圖就是類別圖（Class Diagram），Fowler最重視軟體的結構分析與設計，而這也是軟體根本所在──不從表象的需求看待系統的開發，而是直指核心，找出軟體的本質。 本書用兩個章節介紹類別圖，基本概念是介紹類別圖的基本語法，高等概念則是說明類別之間的關係，與關連類別、範本類別等比較少見的說明。要看這2 個章節，最好有物件導向觀念的基礎，如：什麼是物件、類別 （老實說，老手可能也不一定清楚物件與類別的區分）。高等概念不容易看懂，雖然只介紹語法，並沒有教你如何抓本質性的類別，那部分需要抽象高層次的悟性， 與IT技術沒有多大關連。 真要談到程式設計人員會關心的，反而不是類別圖，而是表達物件互動的序 （Sequence）圖。Fowler 提到集中式與分散式的控制設計方式，這裡他寫的很精彩。你會發現，Fowler不直接談集中式控制方式的缺點（事實上，這是最容易的開發方式，但嚴格說 來，它根本不是物件導向），他的說法是：「就是強烈要求寫集中控管的軟體人員採用分散式的設計風格，也不說明為什麼，但總有一天，他們會恍然大悟，這時 候，他們的腦袋將彷彿重生。」這真是最高段的損人不帶髒字。 系統的外觀：需求分析 針對需求分析，Fowler使用案例模型（Use Case Model）與活動（Activity）圖。使用案例模型包括案例圖與敘述，Fowler只簡單針對基本的語法作說明。在案例敘述這部分，他其實參考了 Cockburn的《Writing effective use cases》（使用案例寫作實務）。 他還特別提到：對於使用案例，請把自己的精力放在說明文字，而不是在圖上，使用案例敘述才是全部價值之所在。對於這段敘述，我不太同意，應該要先 釐清假設點：需求敘述對需求分析人員是最重要的；但是，案例圖則是軟體架構師的利器，用來界定系統開發範圍，區分內與外，決定那些要作、那些不作。 狀態圖與複合結構圖 Fowler很有意思，他覺得不重要的設計圖，大概就以一頁說明，再加上一張範例圖就結束。我把這些設計圖稱為「雞肋」── 食之無味、棄之可惜。 其中，狀態（State）圖與複合結構（Composite Structure）圖算是比較重要的設計圖。本書第三版改版最多的部分就是狀態圖的說明，狀態圖會與嵌入式系統設計或複雜的畫面狀態設計有相當的貢獻； 而複合結構圖則是UML 2.0規格最有價值的一張新視圖，它同時結合類別與元件（Component）圖的優點，來表達整體系統對外的介面，以及系統內部的結構組成元素。 這本書目前出到第三版，Fowler針對每一版本的制訂，並不只是新增補充，而是把他當下對UML的心得與體悟，重新編寫到新版本內，但還是只有「薄薄的一本」。 我三不五時仍會翻閱本書，新手看了本書，可以收穫甚多，而老手重新再看本書，仍會有不同的體會，這就是本書的精彩之處！ 《作者簡介》王克明 台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師╱顧問╱講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。 相關閱讀： 軟體設計必讀經典(2)物件導向分析與設計入門 軟體設計必讀經典(3)洞悉易學難精的Use Case |
http://www.ithome.com.tw/itadm/article.php?c=44867
軟體設計必讀經典(2)
| 軟體設計必讀經典(2)物件導向分析與設計入門 | ||
| 文/iThome (記者) 2007-08-19 | ||
| 物件責任的分派很容易被忽略，卻很重要。若不重視這個部分，將導致行為分散，造成系統的混亂與複雜。 | ||
翻譯自《Applying UML and Patterns 2nd edition》（目前已出至第三版）的《UML與樣式徹底研究》，是物件導向分析與設計最為暢銷的入門教科書之一，也是筆者踏入軟體設計領域的第一本書。 《UML與樣式徹底研究》的大綱架構，可說是最為標準的典型軟體工程式教科書。作者Craig Larman把他多年來豐富的教學經驗全都濃縮在本書內。第二版並導入UP（Unified Process）流程框架到大綱目錄內，讓讀者能大致掌握UP的 Milestone階段目標，與每次往覆（Iteration）的產出（Artifacts）。 系統開發的基本：了解需求 對軟體設計入門者而言，關於「需求」的討論是本書最有價值的部分。這本書是以需求作為系統開發的初端，再進而導出系統內部的結構分析、設計至實作 等。使用案例模型（Use Case Model）的建立，是功能性需求當中最重要、用來發掘並記錄需求的一種機制，它會影響到系統開發之後的諸多環節。 UP所倡導的「4+1 View」，即是以使用案例作為驅動，並且涵蓋整個專案的重心所在。 本書在使用案例敘述部分寫得相當好，同時也揭露多種不同的寫作格式與風格，讓讀者得以選擇適合的需求寫作方式。除了使用案例外，作者也介紹輔助規 格（記錄非功能性需求）、企業規則、字彙表、專案願景等其它功能需求，其實，這也是UP建議在需求製程的產出。參考範例的寫作方式不錯，但不要全盤照收， 以免造成不必要的儀式與負擔。 物件導向分析設計精髓：物件責任的分派 物件責任的分派（Responsibility Assign）是本書最精彩之處，也是其它書籍所看不到的。 對SA╱SD而言，責任的分派容易被忽略，相對來說卻最重要。要把軟體作「軟」，物件責任的分派是關鍵。舉例來說，誰負責訂購總額的計算？一般 SA並不重視這個，可能就寫在表單（Form）、Stored-Procedure，或者功能性的物件上，導致行為的分散，因此造成系統的混亂與複雜。 如何熟練指派責任是SA在物件設計中最重要的事，作者提出GRASP（General Responsibility Assignment Software Patterns）的設計原則，裡面提出5種重要的責任設計樣式。 其中，高內聚力（High Cohesion）與低耦合性（Low Coupling），決定了軟體核心的穩定性。但兩者也經常相互衝突，它們之間的關係，可比擬為軟體工程的陰與陽，互相牽制且彼此影響。 系統內部的靜態結構分析：找出物件 至於如何找出建構領域模型，進而產出軟體規格設計圖的部分，作者仍是以傳統的方式──找名詞，以歸納概念性類別。雖然他又列出概念性類別分類清 單，來協助SA找物件，但這仍不是個好方法，因為這是從需求的片段記錄來找尋物件，但需求並不穩定，相對來說，也不容易找出最具本質性 （Essential）的核心物件。 當初我在看這一部分時，著實疑惑甚久，後來閱讀了Peter Coad《Object Modeling》一書，揭露出以交易為核心，來找出本質性的領域物件的作法，才總算得到滿意的解決方案。 以POST系統開發案例，串連各章節觀念 後面幾個章節，一般的讀者其實可以忽略不看。例如：利用設計樣式設計出永續性框架（Persistent Framework）。由於.NET的ADO.NET， 以及J2EE的Hibernate等，都作得很好，我們只需學會如何使用即可。 總體而論，全書以一個POST系統開發為案例研討對象，包含需求分析記錄、領域模型建立、物件責任分派、系統規格模型設計等。讓讀者能透過案例跟著內容操作，將所有章節的觀念串連起來。 本書與《UML 精華》都是我鼓勵軟體從業人員必買的兩本好書，由於中譯本的翻譯品質甚佳，建議軟體公司都擺上一本，甚至舉辦讀書會鑽研一番。 《作者簡介》王克明 台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師╱顧問╱講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。 相關閱讀： 軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分 軟體設計必讀經典(3)洞悉易學難精的Use Case |
http://www.ithome.com.tw/itadm/article.php?c=44992
軟體設計必讀經典(3)
| 軟體設計必讀經典(3)洞悉易學難精的Use Case | ||
| 文/iThome (記者) 2007-08-26 | ||
| 使用案例（Use Case）運用簡單的圖形，加上文字敘述，建構出以使用者觀點檢視系統功能的模型。 | ||
使用案例（Use Case）是由Jacobson在易利信開發電信系統時，所發明的一種描述系統行為的工具，隨著UML規格的制訂，已成為捕捉需求最關鍵的技術。 使用案例可說是軟體界這十年來最了不起的創見，因為簡單。使用案例圖中，利用棒型人偶（參與者），表達系統的使用者與系統需要外部系統的支援服務，而橢圓 形的使用案例，即是表達系統所提供的功能服務；再以純文字寫作，描述每一個使用案例的需求陳述，可說是參與者與系統之間的互動對話，卻又不致於牽涉到系統 的實作面。簡單的圖形，加上文字敘述，建構出從使用者觀點看系統功能的模型。 不過，使用案例易學難精，如果沒有把握基本精要與原則，很難把圖給畫好（不容易界定出系統範圍），更何況是用純文字寫出需求陳述。 我對使用案例的技術相當著迷，但學習的前兩年完全無法體會它的本質精髓，直到閱讀了《Use Case Requirements in Context》，以及本文要介紹的《Writing Effective Use Cases》，才慢慢打開心眼。 腦力激盪的最佳工具──記錄需求、發掘需求 本書內容分為3大部分：使用案例的主體、相關議題的討論、寫作提示等。一開始閱讀會有些吃力，我建議要隨時翻閱目錄，了解自己在閱讀時的主題與焦點所在，若當下無法體會該章內容，其實跳過去也無妨。 本書第一部分讓你了解使用案例的本質，以及使用案例的寫作格式。作者Cockburn提供多種格式，如單欄/兩欄/RUP，甚至利用Occam程 式語言、圖形呈現的另類寫作風格。另外，作者自創的三個目標等級──白雲、海平面、海平面下，說明使用案例的精確程度，以及適合的目標層級對象，是該書第 一部分最有價值的內容。 第2部分屬於FAQ性質的主題性討論。例如常見的CRUD（Create、Read、Update、 Delete）與可參數化的使用案例該如何描述比較恰當；開發流程中，使用案例所扮演的角色與其它製程產出的關連性；撰寫使用案例常見錯誤……等，對於實 務上已經在運用使用案例的開發人員來說，相當具有參考價值。 第3部分是全書最實用的內容，第20章列出的使用案例相關寫作提示，就足以讓分析人員受用無窮。我看過多位系統分析師所寫的使用案例中常犯的錯誤，在本章都有提到。只要依循本章所列出的11個提示，寫出中規中矩的案例敘述，也就不難。 即使你寫的是中等程度的使用案例，本書仍然有相當的參考價值，事實上，只要使用案例具備可讀性，對整個專案就會有相當程度的貢獻；再者，使用案例不僅僅只是記錄需求的工具而已，它更可以成為專案成員的腦力激盪工具，發掘新的或潛在性的需求，這部分更是價值斐然。 順應國內短線專案型態──Use Case First 事實上，臺灣95％以上的專案都是功能導向的開發方式，至於系統內部的結構分析設計，由於時程壓縮，以及抽象基礎的素養不足，往往無法做好。 功能直接影響到專案能否被「做出來」；結構則是影響系統的彈性與穩定度。所以我主張應該「務實一點」，先順應國內短線的專案生態，利用使用案例，快速地對應到實作面。 在實際經驗中，這樣的效果與接受度相當高，雖然「Quick」，但可不「Dirty」。另外，有兩個配套措施是一定要做的：「測試案例到測試程 式」，以隨時驗證功能的正確性；「分析類別的規畫」，以符合3-tier 的MVC（Model-View-Control）框架。 在此之後，系統做得出來、開發能力顯著提升，老闆也就比較願意投入更多資源，再施以結構重整，慢慢萃取出系統最穩定、共用的部分。有了使用案例後，我似乎再也沒擔心過能否「做」得出來，因為那根本不是問題。 此書在Amazon是評價四顆半星的好書，猜猜中譯本賣多少錢？你可以在某書局以99元的價格購買！建議身為需求分析人員的你，用一到兩次便當錢的代價，買本可以讓你工作上獲益良多的好書。 《作者簡介》王克明 台北工專五專部電子科畢業。現於HSDc軟體設計顧問團隊擔任架構師╱顧問╱講師。興趣為整體架構性的思考與學習、期貨投機操作與閱讀。 相關閱讀： 軟體設計必讀經典(1)以簡約之道介紹UML最實用的部分 軟體設計必讀經典(2)物件導向分析與設計入門 |
--
萬歲！您的郵件已被捨棄。一封垃圾郵件也沒有！
--
萬歲！您的郵件已被捨棄。一封垃圾郵件也沒有！
沒有留言:
張貼留言