面向對象分析與設計方法結論

A. 面向對象分析方法的步驟和特點

使用MVC進行項目開發已經有一段時間了，在這段時間里感觸最深的就是自己對宏觀性面向對象分析方法的缺乏。面向對象分析是當今流行的系統分析方法之一，下面就談談在做項目的過程中我的一些小經驗。

在面對簡單系統時程序員可以很順利的提出問題的解決方案，並且一般情況下都是可行的。這是由於問題域關系簡單，所涉及到的內部構造、聯系比較容易解釋。而對於當前越來越復雜的系統，其問題域也就顯示的越來越復雜，而且內部的關系也不是很容易解釋，有些大的系統常常超出了人的解決問題的能力。在這種情況下，以往的面對過程的解決方法已經不能滿足日益增長的復雜系統分析的需要，在這種情況下，面向對象的分析方法就顯得尤為總要了。

在面向對象設計領域中，在橫向上把問題域分為數個不同的、低耦合、高內聚的問題域，而在縱向上又繼續分解各個不同的小的問題域，最後分解為葉節點問題域，從而解決問題。在面對對象分析方法中，用數個對象間的消息傳遞來完成整個問題。

下面看一看復雜系統的5個屬性：

1． 雜性經常是以層次的形式表現出來，復雜系統是由相互關聯的子系統組成，而這些子系統又是由他們各自的子系統構成，並由此類推到最底層的基本構件。

2． 對系統中最基本的構件的選擇是任意的，而且在很大程度上取決於系統觀察者的判斷力。

3． 一般而言，各構件內的連接總是要強於構件間的連接。在從構件的低頻動態中分離出高頻動態時，這一屬性是相當有用的。這是因為高頻動態涉及到各部件的內部結構，而低頻動態涉及到構件間的交互。

4． 層次系統通常都是由僅僅少數不同的子系統通過不同的排列組合方式組成。

5． 我們發現正運行的復雜系統總是由以前運行的簡單系統演化而來……任何胡亂湊合設計出來的復雜系統都不可能正常運轉，也不可能被修補好。我們必須由運行中的簡單系統開始。

對於第一點，正像我上面所說的那樣，系統是層次結構的。能夠給一個復雜的系統進行正確的層次分析，才能夠保證對系統的正確估計，包括可行性、可維護性、可擴展性……等等。而且對於日後對該系統進行維護(maintenance)、演化(evolution)、維持(preservation)都能夠很好的支持。

對於其中的第二點，強調了觀察者的判斷力，其實我認為其中也包括觀察者的身份角度。對於一個系統而言，觀察者並不是只進行分析設計的工程師，編碼階段的程序員，還應該包括用戶等所有這些同該系統有關的人員。作為不同的人員，對於系統就有不同的觀察點、觀察角度、身份等特殊因素。因此在不同身份的人（指參與者）甚至同一身份的人眼中說觀察到的系統特性都是不盡相同的。在大學里大家都接觸過透明性的概念，這就是不同觀察者所觀察角度不同的直觀反應。對於用戶來說，基本上底層的操作、演算法、通訊對於他們來說都是透明的，他們根本不用理會（其實也不知道）內部用了什麼。而對於一個負責某模塊的程序員來說就不會考慮其他模塊的實現，對於他們來說其他模塊是透明的，他們只需要負責管理好提供的模塊介面就OK了。

對於第三點，講的就是面對對象分析設計的方向，在面對對象分析設計系統時，被分解的各個模塊一定要做到高內聚、低耦合。有良好高內聚、低耦合系統常常會很容易維護，一個地方改動通常不需要牽扯到大的改動，維護行強。而且對於像VC程序這種更要求效率的程序來說，高內聚、低耦合也可以提高程序的運行期效率，應為對象內部的調用一般情況下會相比模塊間的調用佔用更少的執行時間，這樣將高頻動態封裝在一個對象內部就會一定程度上提高程序運行期執行效率。

第四點則說明了面向對象程序設計對程序設計可復用性的優點。在這點中所「層次系統由僅僅少數不同的子系統構成」那麼多數子系統在不同的復雜系統中都是能夠重復使用的。比如說建築一棟大廈和建築橋梁，雖然兩者都是復雜的系統，但是對於其結構中就會有很多相似甚至相同之處，沒有必要建築好大廈回頭建築橋梁的時候又要重新設計每一快磚瓦。

第五點提醒我們在系統設計時，盡量使用以往能夠正常運行的子系統來重新構件新的系統。這一點不僅說明第四點中的復用性，而且也說明了一個我們常常要犯的錯誤。就是將並沒有通過嚴格測試的子系統，匆忙的加入到大系統中，這樣做不利於對系統的基層，常常引入了其他錯誤，使得系統頻頻崩潰，最嚴重會導致系統的重新分析。

這是我對面向對象的一點心得體會，雖然我們大家在平時工作中所面對的問題、問題域不同，使用的開發工具不同，但是面向對象是一種思維方式，有利於分析、解決問題的一種方法，並不和任何語言掛鉤（當然語言對於面向對象特性的支持程度有所不同）。所以希望各位同事能夠盡量使用科學的方法分析解決問題，形成一種設計模式，以供大家互相交流。

軟體設計是一種藝術，也是一門工程學。

B. 面向對象分析與設計的簡介

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。

C. 面向對象分析與設計，煩請幫忙。

面向對象分析與設計
有更具體的要求把，
你說下吧我看下我幫你。

D. 對比傳統的結構化分析和設計方法的特點，談談面向對象方法學的主要優點。

結構化程序設計特點：
優點： 與非結構化程序相比，結構化程序在調試、可讀性和可維護性等方面都有很大的改進。

缺點：代碼重用性不高：以過程為中心設計新系統，除了一些標准函數，大部分代碼都必須重新編寫。
由於軟、硬體技術的不斷發展和用戶需求的變化，按照功能劃分設計的系統模塊容易發生變化，使得開發出來的模塊的可維護性欠佳。
面向過程模式將數據與過程分離，若對某一數據結構做了修改，所有處理數據的過程都必須重新修訂，這樣就增加了很多的編程工作量。

面向對象的優點：
而面向對象圍繞現實世界的概念來組織模塊，採用對象描述問題空間的實體，用程序代碼模擬現實世界中的對象，使程序設計過程更自然、更直觀。
面向過程是以功能為中心來描述系統，而面向對象是以數據為中心來描述系統。相對於功能而言，數據具有更強的穩定性。
面向對象模擬了對象之間的通信。就象人們之間互通信息一樣，對象之間也可以通過消息進行通信。這樣，我們不必知道一個對象是怎樣實現其行為的，只需通過對象提供的介面進行通信並使用對象所具有的行為功能。而面向過程則通過函數參數和全局變數達到各過程模塊聯系的目的。
面向對象把一個復雜的問題分解成多個能夠完成獨立功能的對象（類），然後把這些對象組合起來去完成這個復雜的問題。採用面向對象模式就象在流水線上工作，我們最終只需將多個零部件（已設計好的對象）按照一定關系組合成一個完整的系統。這樣使得軟體開發更有效率。

E. 面向對象分析與設計面向對象設計包括哪些內容

一、總述

面向對象分析的輸入是用戶的功能需求，輸出是簡單的、理性化的分析模型，此階段的工作更多側重於如何理解軟體的功能需求；

面向對象設計的輸入是面向對象分析的結果，蔬菜水果最終的、細化後的設計模型，此階段的工作更多側重於如何得到一個合適的、完整的解決方案。

二、主要區別

(1) 在側重點上，面向對象分析側重於理解問題，描述軟體要做什麼，而面向對象設計側重於理解解決方案，描述軟體要如何做。

(2) 面向對象分析一般只考慮理想餓設計，不關心技術和實現層面的細節，而面向對象設計需要得到更具體、更詳盡，更接近於真實的代碼的設計方案。

(3) 在設計結果的描方式上，面向對象分析階段側重於描述對象的行為，而面向對象設計階段側重於描述對象的屬性和方法。

(4) 面向對象分析只關注功能性需求，而面向對象設計既關注功能性需求，也關注非功能性需求。

(5) 面向對象分析產生的系統模型通常規模較小，而面向對象設計產生的系統模型規模較大，內容也比較詳盡、完整。

三、分析設計工具(RationalRose + UML)

1、需求分析階段

常藉助於「用例圖」、「順序圖」對功能模型進行建模；

用例描述，一般包括：用例名稱，系統范圍，用戶目標，前置條件，執行過程，擴展情況，後置條件。

順序圖著眼於整個系統。

2、面向對象分析階段（包含需求分析階段的用例建模）

常藉助於「類圖、對象圖」，「順序圖、協作圖」，「狀態圖」進行靜態模型建模和動態模型建模。

這里的類圖主要指通過用例分析得到的實體類、控制類和邊界類。

順序圖也著眼於各個分析類對象間的協作。

3、面向對象設計階段

常藉助於「類圖」，「順序圖、協作圖」，「狀態圖」來細化各個類以及對象間的協作、關系的可見性；

這里的類圖，要具體到屬性、方法，類之間的關系依賴（繼承、組合、聚合）

這里的順序圖要具體到各個類的實例之間的消息傳遞、函數調用。

面向對象設計階段常藉助一些設計模式達到軟體的可擴展行，應對軟體的可預測到的變化。

F. 面向對象分析與設計有怎樣關系

這里所說的對象是對數據及其處理方式的抽象，它反映了系統保存和處理現實世界中某些事物的信息的能力。類是多個對象的共同屬性和方法集合的描述，它包括如何在一個類中建立一個新對象的描述。

G. 為什麼應該盡量使用面向對象語言來實現面向對象分析和設計的結果

因為 用面向對象的思想能更好的模擬現實世界的實體對象 面向對象可以實現代碼的重用 面向對象能更好的實現軟體的可維護性、可擴展性 和重用行

H. 面向對象分析與設計的意義是什麼

在創建一個應用軟體系統前，必須進行充分的分析，即明確所要解決的問題是什麼。例如，開發一個圖書信息管理系統軟體，這個系統要實現什麼樣的功能？這就是一個分析問題。
設計強調的是問題的邏輯解決方案，即系統怎樣才能達到要求。例如，圖書信息管理系統如何實現遠程查詢？設計最終可以用硬體或軟體方法來實現。
面向對象的分析與設計的精髓是按照對象的觀點考慮問題域和邏輯解決方案。分析旨在發現並描述問題域中的對象。例如，在圖書館信息系統中，這些對象包括圖書、借閱者、圖書管理員等。
設計的重點在於定義邏輯軟體對象，這些對象（具有屬性和方法）最終能夠用面向對象程序設計語言實現，即編寫它們的類。

I. 怎樣理解面向對象分析和設計比語法和API更重要這句話

當你還是個只能寫十幾行代碼輸出HelloWorld或者九九乘法表的初學者的時候，你所關注的是編程語言本身的語法、可以調用的 API（如C語言中的printf、Java中的system.out.printf）等等非常基礎，非常低層的問題。

當你是個能寫出幾百行代碼，能完成一定功能的程序（比如實現一個簡略的哈夫曼演算法）的初窺門徑的學習者，你所關心的是函數與函數之間的配合，也即面向過程的程序設計。比如用哪個函數打開文件、哪個函數處理數據、哪個函數保存文件、哪個函數檢查錯誤輸入，以及彼此功能之間的分割與配合等等。

當你能掌握的程序規模越來越大的時候，面向過程的程序設計也已經不能滿足你的需求了。你的程序會自然地按功能、性質的不同而被劃歸為諸如：用戶配置、輸入輸出、核心模塊等等不同的模塊（而實際應用中 核心模塊又應該繼續劃分），而每個模塊的代碼又需要保存自身的數據。這個時候，面向對象的設計方法自然而然就成了程序的整體設計方法。

面向對象分析就是如何把實際需求劃分成不同的模塊，面向對象設計就是如何不同的模塊如何用代碼實現、模塊間如何配合等等。

可以發現，面向對象的程序設計其實就是如何用機器語言模擬現實事物，解決復雜的現實問題。

我可能仍然沒有回答為何「面向對象分析和設計比語法和API更重要」這個問題，但是相信你在以後的進步過程中，會逐漸體會到這一點。

J. 面向對象分析與設計，

不是標准答案,僅供參考.
AADBBC