物件導向分析的八項技術（上）

這本《Object-Oriented Analysis》是快二十歲的古董書了，它誕生在UML之前，那是個物件導向分析設計方法論百家爭鳴的春秋戰國時代。這兩天我在拍賣網站尋寶，無意間發現了這本珍貴的古董書，我迫不及待地下標，含運費不到三百塊新臺幣就把它買到手了，心中禁不住大喜，等不及還要花上兩、三天的時間才能寄送到我家。

老舊的實體書雖然不值錢，可是原著作者在書裡頭留下的文字內容，卻是經典中的經典。這本書的原著作者是Peter Coad和Edward Yourdon，兩位都是物件導向分析設計領域中的大師級人物。之前，我們已經讀過Peter Coad的《Java Modeling In Color With UML: Enterprise Components and Process》一書，見識過他高深莫測的功力。

現在，趁這個機會，我們再回過頭來讀這本物件導向分析，沉浸在大師最原始純淨的概念中，肯定會讓你有意想不到的非凡收穫，就像我在拍賣網站上掏到寶一般！

章節結構
我們總共會精讀九章，其中第零章和第一章的閱讀筆記放置在同一小節中，第九章和第十章內容的重點會打散放置在各小節中。

系統分析師面臨的挑戰
系統分析師從專案開發的開始、過程和最後，得經歷一關又一關的挑戰。

管理複雜度
系統分析師將遭遇未知的領域、人與人的溝通、需求不斷變動以及提升重用程度等等的問題。

抽象化
「抽象化」（abstraction），意即忽略與目標不相關的特性，僅留下所需的部分。章節結構

除了第零章的簡介和最後兩份附錄外，整本書的主要內容分為十章。在研究了章節目錄之後，我決定跳過第二章、第八章以及最後兩份附錄，所以我們總共會精讀九章，其中第零章和第一章的閱讀筆記放置在同一小節中，第九章和第十章內容的重點會打散放置在各小節中，其餘各章會依序放置在對應的各個小節中。

略過不讀的第二章，其談論的主題是一個名為Smalltalk的物件導向程式語言，現在使用Smalltalk的開發人員大概所剩無幾了吧！早期，在物件導向技術還不像現在這麼流行的時候，支援物件導向技術的程式語言並不多，Smalltalk則是當年十分聞名的物件導向程式語言之一。事實上，我曾經研究過一陣子的Smalltalk，大約是1995年底的事情，那時我還只是個資訊科學系大四的學生，寫過一陣子的Smalltalk程式。

我還記得在《物件導向雜誌》1995年8～9月的創刊號中，刊登了兩篇關於Smalltalk的文章，一篇名為〈從Basic到Smalltalk〉，另一篇名為〈認識Smalltalk的MVC觀念〉。後來，在1995年11～12月的第二期物件導向雜誌中，我還以筆名「野渡」投稿了一篇名為〈認識Smalltalk的訊息、方法和類別〉的文章。不過，在這三篇文章後，物件導向雜誌就再也沒刊登過有關Smalltalk的文章了。正因如此，我們就略過不讀第二章關於Smalltalk的主題。

此外，第八章談的是支援物件導向分析（Object-Oriented Analysis）的工具。當年UML還沒誕生時，Peter Coad所屬的公司開發了一套名為OOATool的工具來支援物件導向分析，不過想當然爾，OOATool這套工具大概已經作古了吧。

而且，在原著第八章的內容中，提及關於支援物件導向分析的工具需要具備什麼樣的特色，跟現在的UML工具所需要的特色，可說是小巫見大巫，所以原文已經不具太多參考價值了，因此我們就跳過不讀原著的第八章了。

至於，第九章約略談到物件導向設計（Object-Oriented Design）。通常在物件導向分析之後，便會進入到物件導向設計範疇，所以此章約略提到物件導向設計，順便廣告一下原著作者的另一本書《Object-Oriented Design》。系統分析師面臨的挑戰

系統分析師從專案開發的開始、過程和最後，得經歷一關又一關的挑戰。專案的一開始，系統分析師可能面臨的是一個從前沒研究過的問題領域（problem domain），接著得跟使用者、領域專家和團隊成員等等不同的人員溝通合作，接受需求不斷變動的情況，最後還得考慮系統分析設計產出的重用程度。

一般而言，無論系統分析師參與什麼類型的專案，大抵上都會遇到下列四項挑戰：
1.未知的領域：系統分析師不僅必須在最短時間內搞懂問題領域，還得找出系統在這個領域中應當擔負什麼樣的責任。在這種情況下，我們不難想像系統分析師的壓力有多大。在最短時間內，搞懂問題領域並且找出系統責任，這還只是系統分析師面臨的第一項挑戰。

2.人與人的溝通：我一直認為系統分析師是整個開發團隊的靈魂人物，因為系統分析師得扮演使用者與開發人員之間的溝通橋樑。而且這個溝通橋樑是雙向的，系統分析師不僅要將使用者各式各樣的需求，轉化成其他開發人員能夠理解的圖形和文字，同時也要把開發人員所遭遇到的困境傳回給使用者，尋求兩方的妥協與共識。

3.需求不斷變動：許多因素都會影響需求，導致需求發生變動，我們得接受真正的需求會像河水一樣流動，而不是像冰塊一樣凍結不變。即便，系統分析師可以透過文件，表達系統當下的需求，暫時凍結需求。系統分析師還是要知道，凍結的需求只是一時的假象，真正的需求是會持續變動的。

4.提升重用程度：「重用」（reuse）一直都是人們十分關切的主題，無論是系統開發上頭，或是其他專業領域，甚至是日常生活中，我們都希望可以藉由大幅度的重用來節省未來的花費，或者再度活化過往的投資。管理複雜度

由於，系統分析師將遭遇未知的領域、人與人的溝通、需求不斷變動以及提升重用程度等等的問題，導致系統分析的工作不再是件容易的事情，系統分析師得面對比過去更複雜的情況。

然而，物件導向分析之所以受到青睞，便是因為它所提供的技術，可以讓系統分析師更容易地管理複雜。這些技術有：抽象化、封裝、繼承、結合、訊息溝通、組織方法、級別和分類行為。我會一一為你說明這八項技術。抽象化

物件導向分析中的第一項技術是「抽象化」（abstraction），意即忽略與目標不相關的特性，僅留下所需的部分。問題領域中有許許多多的事物，藉由抽象化的技術，系統分析師可以忽略不相關的部分，僅留下系統所需的部分。

雖說，真實世界中的人類、事情、地方、物品和概念等等，都具有許多繁雜的細節，所以這些人事地物及概念在本質上都是複雜的。抽象化的技術可以讓系統分析師不需要去面對複雜的整體，而是抽取部分，所以說抽象化技術是管理複雜的首要技術。

實務上，開發人員最常使用「程序抽象」（procedural abstraction）技術，先將資訊系統視為一個大型的程序，然後再思考這個大程序裡頭包含幾個次程序。程序抽象的技術可以將一個複雜且難以掌控的大型程序，化解成數個簡單且能夠輕易掌控的小型程序。把原先龐大複雜的一個整體，化解成數個短小精幹的組件，這是管理複雜常用的方法之一。

不過，特別需要注意的是，程序抽象其實並不是物件導向分析主要的抽象技術，這是因為由程序抽象所建構出來的資訊系統比較不穩定。因此，在物件導向分析方法中，程序抽象通常僅在定義物件的操作（operation）。

另一項有用的抽象機制是「資料抽象」（data abstraction）。系統分析師關注在人事地物及概念的資料部分，忽略其他細節。

在物件導向分析的方法中，系統分析師同時運用資料抽象與程序抽象技術，定義出物件的屬性（資料），以及定義出專門用來處理這些屬性的操作（程序），而且外界只能夠透過這些操作來存取屬性。

再者，系統分析師會將這些屬性，以及處理它們的操作，兩者合併視為一個整體。

請看到圖1的銷售交易類別，在UML中，類別就是一個包含屬性與操作的整體，資料抽象的結果放置於類別內部的屬性區，程序抽象的結果則放置於類別內部的操作區。

在下一期中，我們將繼續介紹其他7種物件導向分析技術。

圖1：資料抽象與程序抽象

書籍簡介
	Object-Oriented Analysis第二版 作者：Peter Coad and Edward Yourdon 頁數：233頁 出版社：Prentice Hall PTR 出版時間：October 1, 1990