OOAD（Object Orient Analysis & Design，面向對象的分析和設計，面向對象分析與設計）是現代軟件企業廣為采用的一項有效技術。OOAD方法要求在設計中要映射現實世界中指定問題域中的對象和實體，例如：顧客、汽車和銷售人員等。這就需要設計要盡可能地接近現實世界，即以最自然的方式表述實體。所以面向對象技術的優點即為能夠構建與現實世界相對應的問題模型，并保持他們的結構、關系和行為為模式。
大師說："沒有不變的需求，世上的軟件都改動過3次以上，唯一一個只改動過兩次的軟件的擁有者已經死了，死在去修改需求的路上。"
目前眾多的軟件項目有什么樣的問題呢？早些時候上ERP的企業在企業發展的時候發現原有的ERP系統需要改進，可是要改進或者是更改現有的ERP系統，唯一的方法就是重新開發一個ERP系統。這對于企業來說是筆不小的支出。此時，落后的信息系統就成為制約企業發展的重要因素。是什么原因造成了這種情況呢？主要的因素是傳統的系統分析是在假定需求不變的情況下進行的，這樣可以把企業的資源配置到最優的程度。可是在現代瞬息萬變的社會，一個企業固守舊有模式，勢必會在競爭中處于劣勢（因此現在也出現了"組件化"的ERP，這是題外話）。既然企業的需求是變化的、不穩定的，那么以變化的需求為基礎建立起來的企業信息系統當然也就不穩定了。這時候，有個問題就產生了，前面我們已經說過，需求是項目的根本，既然需求都是不穩定的，那么何以建立起穩定的企業信息系統呢？
要回答這個問題，首先要比較面向過程和面向對象的開發方法的差別，傳統的面向過程的開發方法在前20年大行其道，為中國企業的信息化建設立下了汗馬功勞。之所以稱為面向過程，是因為開發的焦點集中于過程，開發者集中于以函數為核心的過程，例如前些年很多人試圖編寫一些通用轉賬函數來滿足銀行的需求。面向過程的開發語言包括：Cobol、Pascal、C及C的變形語言。面向對象的概念是在近10年才進入中國的，而它的思想至今也沒有真正意義上得到普及。簡單的說，面向對象就是面向世界，世界上的任何事物都是對象，因此面向對象是很自然的思想，是符合我們的思維習慣的。面向對象的語言包括了Smalltalk、C++、Java，還有Object Pascal，以及剛剛誕生的C#。
需求是不穩定的，那么需求之中是不是沒有穩定的東西呢？有的，就是對象。世界都是由對象組成的，而對象都是持久的，例如動物、植物已經有相當長的時間。雖然對象也在變化，動物，植物也在不斷的進化。但對象在一個相當長的時期內都存在，動植物的存在時間肯定比任何一家企業長久。面向對象的開發方法的精髓就是從企業的不穩定需求中分析出企業的穩定對象，以企業對象為基礎來組織需求、構架系統。這樣得出的系統就會比傳統的系統要穩定得多，因為企業的模式一旦變化，只需要將穩定的企業對象重新組織就行了。這種開發的方法就被稱為OOAD（Object Orient Analysis & Design 面向對象的分析和設計），而分析出的企業對象就被稱為Common Business Object。
圍棋與OOAD的幾個相似點：
活棋與對象
一塊活棋至少有兩個眼位，一個對象或類（有用的）至少要有一個屬性和一個方法。眼位表明了這塊棋存在的理由，屬性和職責同樣表明了一個對象存在的理由。
簡單與復雜
圍棋構成簡單，一黑一白，以簡單構建復雜，與對象方法的理念相同。
棋盤與邊界
圍棋的棋盤有邊界，系統有系統邊界。
定式與模式
下圍棋有定式，面向對象方法有分析模式和設計模式。都是個中高手們長期實踐的經驗結果。
當然更主要的相似之處，應該在方法和過程上。圍棋誰都會下，不就是在棋盤上圈地，看誰圈的多嗎。但是高手與低手的水平卻有天壤之別。例如：
1、 圍棋忌諱把棋下成"愚形"，就是一大塊棋坨在一起，行棋效率不高，對于對象就是緊耦合，一個復雜的對象負擔太重，同樣效率不高；
2、 一個圍棋高手能夠靈活運用各種定式和"手筋"，看到兩顆子，就能推測以后的種種演化，一個面向對象的設計高手可以靈活地運用各種設計模式，畫幾張圖就能描繪未來的宏偉系統；
3、 圍棋有"金角銀邊草肚皮"的說法，在系統分析中首先根據系統邊界來確定系統的主要功能和外部接口也是最有效的做法，俗稱"用例驅動"。
4、 圍棋有"大場"，強調大局觀，系統分析也要求分析人員把握全局，從錯綜復雜的業務邏輯當中洞察最主要的矛盾。
整個行棋的過程都是演進的、逐步精化的，每一階段沒有明顯的區分。針對主要需求的設計可以首先完成，階段性設計成果一旦確定，就可以轉移到下一個"大場"。符合面向對象方法的"統一過程"理論。
開局與需求分析
下棋的兩個人好比一個是分析師，一個是用戶，開始誰也不知道誰想干什么，通過一問一答的方式明確需求。高手的對話只需要寥寥幾子就知道對方的路數，有經驗的分析師幾個回合就對系統了然在胸。
布局與架構設計
至于布局選擇"中國流"還是"韓國流"，就相當于系統架構是DotNET還是J2EE，都是根據用戶具體的需求和設計師的臨場判斷做出的。
中盤與詳細設計
根據架構展開對象和類的設計，棋盤上漸漸浮現一塊塊活棋的模樣。經過幾輪不斷的"精化"和"轉換"，大局已定。至于關子，就是編碼階段，交給程序員去做吧。
最后，如果你能夠從棋盤上看出一幅對象交互圖來，那么恭喜你，你快走火入魔了。
如果繼續列舉，可能還能發現不少相似之處，可是這樣不免有生拉硬扯之嫌，也不是我寫這篇文字的本意。下圍棋與系統設計都是需要高超智慧的，其中蘊涵著豐富的方法論和哲理。經常聽說，有圍棋高手寧可輸棋，也不愿下出形狀難看的棋來，他們稱之為藝術，看著棋盤上一塊塊活棋，簡潔而高效，互通而互動，他們感覺到一種享受。而優秀的設計又何嘗不是一種藝術呢，一個由對象構成的系統，每個對象都各司其職，消息在其中合理而流暢的傳遞著。你不覺得也是一種享受嗎？
而其中最為高妙的地方就在于"平衡"。高手對局，勝負往往只有半目，棋盤上雙方棋子的分布和契合可以用完美來形容，這就達到了平衡的極至，此時輸贏已經不重要，弈者已經得到了他所要的。
平衡是一種美。