Object-Oriented Analysis：面向對象分析方法
是在一個系統的開發過程中進行了系統業務調查以後，按照面向對象的思想來分析問題。OOA與結構化分析有較大的區別。OOA所強調的是在系統調查資料的基礎上，針對OO方法所需要的素材進行的歸類分析和整理，而不是對管理業務現狀和方法的分析。
OOA（面向對象的分析）模型由5個層次（主題層、對象類層、結構層、屬性層和服務層）和5個活動（標識對象類、標識結構、定義主題、定義屬性和定義服務）組成。在這種方法中定義了兩種對象類之間的結構，一種稱爲分類結構，一種稱爲組裝結構。分類結構就是所謂的一般與特殊的關係。組裝結構則反映了對象之間的整體與部分的關係。
OOA在定義屬性的同時，要識別實例連接。實例連接是一個實例與另一個實例的映射關係。
OOA在定義服務的同時要識別消息連接。當一個對象需要向另一對象發送消息時，它們之間就存在消息連接。
OOA 中的5個層次和5個活動繼續貫穿在OOD（畫向對象的設計）過程中。OOD模型由4個部分組成。它們分別是設計問題域部分、設計人機交互部分、設計任務管理部分和設計數據管理部分。
一、OOA的主要原則。
（1）抽象：從許多事物中捨棄個別的、非本質的特徵，抽取共同的、本質性的特徵，就叫作抽象。抽象是形成概念的必須手段。
抽象原則有兩方面的意義：第一，儘管問題域中的事物是很複雜的，但是分析員並不需要了解和描述它們的一切，只需要分析研究其中與系統目標有關的事物及其本質性特徵。第二，通過捨棄個體事物在細節上的差異，抽取其共同特徵而得到一批事物的抽象概念。
抽象是面向對象方法中使用最爲廣泛的原則。抽象原則包括過程抽象和數據抽象兩個方面。
過程抽象是指，任何一個完成確定功能的操作序列，其使用者都可以把它看作一個單一的實體，儘管實際上它可能是由一系列更低級的操作完成的。
數據抽象是根據施加於數據之上的操作來定義數據類型，並限定數據的值只能由這些操作來修改和觀察。數據抽象是OOA的核心原則。它強調把數據（屬性）和操作（服務）結合爲一個不可分的系統單位（即對象），對象的外部只需要知道它做什麼，而不必知道它如何做。
（2）封裝就是把對象的屬性和服務結合爲一個不可分的系統單位，並儘可能隱蔽對象的內部細節。
（3）繼承：特殊類的對象擁有的其一般類的全部屬性與服務，稱作特殊類對一般類的繼承。
在OOA中運用繼承原則，就是在每個由一般類和特殊類形成的一般—特殊結構中，把一般類的對象實例和所有特殊類的對象實例都共同具有的屬性和服務，一次性地在一般類中進行顯式的定義。在特殊類中不再重複地定義一般類中已定義的東西，但是在語義上，特殊類卻自動地、隱含地擁有它的一般類（以及所有更上層的一般類）中定義的全部屬性和服務。繼承原則的好處是：使系統模型比較簡練也比較清晰。
（4）分類：就是把具有相同屬性和服務的對象劃分爲一類，用類作爲這些對象的抽象描述。分類原則實際上是抽象原則運用於對象描述時的一種表現形式。
（5）聚合：又稱組裝，其原則是：把一個複雜的事物看成若干比較簡單的事物的組裝體，從而簡化對複雜事物的描述。
（6）關聯：是人類思考問題時經常運用的思想方法：通過一個事物聯想到另外的事物。能使人發生聯想的原因是事物之間確實存在着某些聯繫。
（7）消息通信：這一原則要求對象之間只能通過消息進行通信，而不允許在對象之外直接地存取對象內部的屬性。通過消息進行通信是由於封裝原則而引起的。在OOA中要求用消息連接表示出對象之間的動態聯繫。
（8）粒度控制：一般來講，人在面對一個複雜的問題域時，不可能在同一時刻既能縱觀全局，又能洞察秋毫。因此需要控制自己的視野：考慮全局時，注意其大的組成部分，暫時不詳察每一部分的具體的細節；考慮某部分的細節時則暫時撇開其餘的部分。這就是粒度控制原則。
（9）行爲分析：現實世界中事物的行爲是複雜的。由大量的事物所構成的問題域中各種行爲往往相互依賴、相互交織。
二、面向對象分析產生三種分析模型
1、對象模型:對用例模型進行分析,把系統分解成互相協作的分析類,通過類圖/對象圖描述對象/對象的屬性/對象間的關係,是系統的靜態模型
2、動態模型:描述系統的動態行爲,通過時序圖/協作圖描述對象的交互,以揭示對象間如何協作來完成每個具體的用例,單個對象的狀態變化/動態行爲可以通過狀態圖來表達
3、功能模型(即用例模型à作爲輸入)。
三、OOA的主要優點
（1）加強了對問題域和系統責任的理解；
（2）改進與分析有關的各類人員之間的交流；
（3）對需求的變化具有較強的適應性；
（4）支持軟件複用。
（5）貫穿軟件生命週期全過程的一致性。
（6）實用性；
（7）有利於用戶參與。
四、OOA方法的基本步驟
在用OOA具體地分析一個事物時，大致上遵循如下五個基本步驟：
第一步，確定對象和類。這裏所說的對象是對數據及其處理方式的抽象，它反映了系統保存和處理現實世界中某些事物的信息的能力。類是多個對象的共同屬性和方法集合的描述，它包括如何在一個類中建立一個新對象的描述。
第二步，確定結構（structure）。結構是指問題域的複雜性和連接關係。類成員結構反映了泛化-特化關係，整體-部分結構反映整體和局部之間的關係。
第三步，確定主題（subject）。主題是指事物的總體概貌和總體分析模型。
第四步，確定屬性（attribute）。屬性就是數據元素，可用來描述對象或分類結構的實例，可在圖中給出，並在對象的存儲中指定。
第五步，確定方法（method）。方法是在收到消息後必須進行的一些處理方法：方法要在圖中定義，並在對象的存儲中指定。對於每個對象和結構來說，那些用來增加、修改、刪除和選擇一個方法本身都是隱含的（雖然它們是要在對象的存儲中定義的，但並不在圖上給出），而有些則是顯示的。
OOD
面向對象設計（Object-Oriented Design，OOD）方法是OO方法中一箇中間過渡環節。其主要作用是對OOA分析的結果作進一步的規範化整理，以便能夠被OOP直接接受。
面向對象設計（OOD）是一種軟件設計方法，是一種工程化規範。這是毫無疑問的。按照Bjarne Stroustrup的說法，面向對象的編程範式（paradigm）是[Stroustrup, 97]：
l 決定你要的類；
l 給每個類提供完整的一組操作；
l 明確地使用繼承來表現共同點。
由這個定義，我們可以看出：OOD就是“根據需求決定所需的類、類的操作以及類之間關聯的過程”。
OOD的目標是管理程序內部各部分的相互依賴。爲了達到這個目標，OOD要求將程序分成塊，每個塊的規模應該小到可以管理的程度，然後分別將各個塊隱藏在接口（interface）的後面，讓它們只通過接口相互交流。比如說，如果用OOD的方法來設計一個服務器-客戶端（client-server）應用，那麼服務器和客戶端之間不應該有直接的依賴，而是應該讓服務器的接口和客戶端的接口相互依賴。
這種依賴關係的轉換使得系統的各部分具有了可複用性。還是拿上面那個例子來說，客戶端就不必依賴於特定的服務器，所以就可以複用到其他的環境下。如果要複用某一個程序塊，只要實現必須的接口就行了。
OOD是一種解決軟件問題的設計範式（paradigm），一種抽象的範式。使用OOD這種設計範式，我們可以用對象（object）來表現問題領域（problem domain）的實體，每個對象都有相應的狀態和行爲。我們剛纔說到：OOD是一種抽象的範式。抽象可以分成很多層次，從非常概括的到非常特殊的都有，而對象可能處於任何一個抽象層次上。另外，彼此不同但又互有關聯的對象可以共同構成抽象：只要這些對象之間有相似性，就可以把它們當成同一類的對象來處理。
一、OOD背景知識
計算機硬件技術卻在飛速發展。從幾十年前神祕的龐然大物，到現在隨身攜帶的移動芯片；從每秒數千次運算到每秒上百億次運算。當軟件開發者們還在尋找能讓軟件開發生產力提高一個數量級的“銀彈”[Brooks, 95]時，硬件開發的生產力早已提升了百倍千倍。
硬件工程師們能夠如此高效，是因爲他們都很懶惰。他們永遠恪守“不要去重新發明輪子”的古訓。Grady Booch把這些黑箱稱爲類屬（class category），現在我們則通常把它們稱爲“組件（component）”。
類屬是由被稱爲類（class）的實體組成的，類與類之間通過關聯（relationship）結合在一起。一個類可以把大量的細節隱藏起來，只露出一個簡單的接口，這正好符合人們喜歡抽象的心理。所以，這是一個非常偉大的概念，因爲它給我們提供了封裝和複用的基礎，讓我們可以從問題的角度來看問題，而不是從機器的角度來看問題。
軟件的複用最初是從函數庫和類庫開始的，這兩種複用形式實際上都是白箱複用。到90年代，開始有人開發並出售真正的黑箱軟件模塊：框架（framework）和控件（control）。框架和控件往往還受平臺和語言的限制，現在軟件技術的新潮流是用SOAP作爲傳輸介質的Web Service，它可以使軟件模塊脫離平臺和語言的束縛，實現更高程度的複用。但是想一想，其實Web Service也是面向對象，只不過是把類與類之間的關聯用XML來描述而已[Li, 02]。
在過去的十多年裏，面向對象技術對軟件行業起到了極大的推動作用。在可以預測的將來，它仍將是軟件設計的主要技術——至少我看不到有什麼技術可以取代它的。
二、OOD到底從哪兒來？
有很多人都認爲：OOD是對結構化設計（Structured Design，SD）的擴展，其實這是不對的。OOD的軟件設計觀念和SD完全不同。SD注重的是數據結構和處理數據結構的過程。而在OOD中，過程和數據結構都被對象隱藏起來，兩者幾乎是互不相關的。不過，追根溯源，OOD和SD有着非常深的淵源。
1967年前後，OOD和SD 的概念幾乎同時誕生，它們分別以不同的方式來表現數據結構和算法。當時，圍繞着這兩個概念，很多科學家寫了大量的論文。其中，由Dijkstra和 Hoare兩人所寫的一些論文講到了“恰當的程序控制結構”這個話題，聲稱goto語句是有害的，應該用順序、循環、分支這三種控制結構來構成整個程序流程。這些概念發展構成了結構化程序設計方法；而由Ole-Johan Dahl所寫的另一些論文則主要討論編程語言中的單位劃分，其中的一種程序單位就是類，它已經擁有了面向對象程序設計的主要特徵。
這兩種概念立刻就分道揚鑣了。在結構化這邊的歷史大家都很熟悉：NATO會議採納了Dijkstra的思想，整個軟件產業都同意goto語句的確是有害的，結構化方法、瀑布模型從70年代開始大行其道。同時，無數的科學家和軟件工程師也幫助結構化方法不斷髮展完善，其中有很多今天足以使我們振聾發聵的名字，例如Constantine、Yourdon、DeMarco和Dijkstra。有很長一段時間，整個世界都相信：結構化方法就是拯救軟件工業的 “銀彈”。當然，時間最後證明了一切。
而此時，面向對象則在研究和教育領域緩慢發展。結構化程序設計幾乎可以應用於任何編程語言之上，而面向對象程序設計則需要語言的支持[1]，這也妨礙了面向對象技術的發展。實際上，在60年代後期，支持面向對象特性的語言只有Simula-67這一種。到70年代，施樂帕洛阿爾託研究中心（PARC）的 Alan Key等人又發明了另一種基於面向對象方法的語言，那就是大名鼎鼎的Smalltalk。但是，直到80年代中期，Smalltalk和另外幾種面嚮對象語言仍然只停留在實驗室裏。
到90年代，OOD突然就風靡了整個軟件行業，這絕對是軟件開發史上的一次革命。不過，登高才能望遠，新事物總是站在舊事物的基礎之上的。70年代和80年代的設計方法揭示出許多有價值的概念，誰都不能也不敢忽視它們，OOD也一樣。
三、OOD和傳統方法有什麼區別？
還記得結構化設計方法嗎？程序被劃分成許多個模塊，這些模塊被組織成一個樹型結構。這棵樹的根就是主模塊，葉子就是工具模塊和最低級的功能模塊。同時，這棵樹也表示調用結構：每個模塊都調用自己的直接下級模塊，並被自己的直接上級模塊調用。
那麼，哪個模塊負責收集應用程序最重要的那些策略？當然是最頂端的那些。在底下的那些模塊只管實現最小的細節，最頂端的模塊關心規模最大的問題。所以，在這個體系結構中越靠上，概念的抽象層次就越高，也越接近問題領域；體系結構中位置越低，概念就越接近細節，與問題領域的關係就越少，而與解決方案領域的關係就越多。
但是，由於上方的模塊需要調用下方的模塊，所以這些上方的模塊就依賴於下方的細節。換句話說，與問題領域相關的抽象要依賴於與問題領域無關的細節！這也就是說，當實現細節發生變化時，抽象也會受到影響。而且，如果我們想複用某一個抽象的話，就必須把它依賴的細節都一起拖過去。
而在OOD中，我們希望倒轉這種依賴關係：我們創建的抽象不依賴於任何細節，而細節則高度依賴於上面的抽象。這種依賴關係的倒轉正是OOD和傳統技術之間根本的差異，也正是OOD思想的精華所在。
四、OOD步驟
細化重組類
細化和實現類間關係,明確其可見性
增加屬性,指定屬性的類型與可見性
分配職責,定義執行每個職責的方法
對消息驅動的系統,明確消息傳遞方式
利用設計模式進行局部設計
畫出詳細的類圖與時序圖
五、OOD設計過程中要展開的主要幾項工作
（一）對象定義規格的求精過程
對於OOA所抽象出來的對象-＆-類以及彙集的分析文檔，OOD需要有一個根據設計要求整理和求精的過程，使之更能符合OOP的需要。這個整理和求精過程主要有兩個方面：一是要根據面向對象的概念
模型整理分析所確定的對象結構、屬性、方法等內容，改正錯誤的內容，刪去不必要和重複的內容等。二是進行分類整理，以便於下一步數據庫設計和程序處理模塊設計的需要。整理的方法主要是進行歸
類，對類一＆一對象、屬性、方法和結構、主題進行歸類。
（二）數據模型和數據庫設計
數據模型的設計需要確定類-＆-對象屬性的內容、消息連接的方式、系統訪問、數據模型的方法等。最後每個對象實例的數據都必須落實到面向對象的庫結構模型中。
（三）優化
OOD的優化設計過程是從另一個角度對分析結果和處理業務過程的整理歸納，優化包括對象和結構的優化、抽象、集成。
對象和結構的模塊化表示OOD提供了一種範式，這種範式支持對類和結構的模塊化。這種模塊符合一般模塊化所要求的所有特點，如信息隱蔽性好，內部聚合度強和模塊之間耦合度弱等。
集成化使得單個構件有機地結合在一起，相互支持。
六、OO方法的特點和麪臨的問題
OO方法以對象爲基礎，利用特定的軟件工具直接完成從對象客體的描述到軟件結構之間的轉換。這是OO方法最主要的特點和成就。OO方法的應用解決了傳統結構化開發方法中客觀世界描述工具與軟
件結構的不一致性問題，縮短了開發週期，解決了從分析和設計到軟件模塊結構之間多次轉換映射的繁雜過程，是一種很有發展前途的系統開發方法。
但是同原型方法一樣,OO方法需要一定的軟件基礎支持纔可以應用，另外在大型的MIS開發中如果不經自頂向下的整體劃分，而是一開始就自底向上的採用OO 方法開發系統，同樣也會造成系統結構不合理、各部分關係失調等問題。所以OO方法和結構化方法目前仍是兩種在系統開發領域相互依存的、不可替代的方法。
七、OOD能給我帶來什麼？
問這個問題的人，腦子裏通常是在想“OOD能解決所有的設計問題嗎？”沒有銀彈。OOD也不是解決一切設計問題、避免軟件危機、捍衛世界和平……的銀彈。OOD只是一種技術。但是，它是一種優秀的技術，它可以很好地解決目前的大多數軟件設計問題——當然，這要求設計者有足夠的能力。
OOD可能會讓你頭疼，因爲要學會它、掌握它是很困難的；OOD甚至會讓你失望，因爲它也並不成熟、並不完美。OOD也會給你帶來欣喜，它讓你可以專注於設計，而不必操心那些細枝末節；OOD也會使你成爲一個更好的設計師，它能提供給你很好的工具，讓你能開發出更堅固、更可維護、更可複用的軟件。
OOP
面向對象編程（Object Oriented Programming，OOP，面向對象程序設計）是一種計算機編程架構。OOP 的一條基本原則是計算機程序是由單個能夠起到子程序作用的單元或對象組合而成。OOP 達到了軟件工程的三個主要目標：重用性、靈活性和擴展性。爲了實現整體運算，每個對象都能夠接收信息、處理數據和向其它對象發送信息。OOP 主要有以下的概念和組件：
組件 － 數據和功能一起在運行着的計算機程序中形成的單元，組件在 OOP 計算機程序中是模塊和結構化的基礎。
抽象性 － 程序有能力忽略正在處理中信息的某些方面，即對信息主要方面關注的能力。
封裝 － 也叫做信息封裝：確保組件不會以不可預期的方式改變其它組件的內部狀態；只有在那些提供了內部狀態改變方法的組件中，纔可以訪問其內部狀態。每類組件都提供了一個與其它組件聯繫的接口，並規定了其它組件進行調用的方法。
多態性 － 組件的引用和類集會涉及到其它許多不同類型的組件，而且引用組件所產生的結果得依據實際調用的類型。
繼承性 － 允許在現存的組件基礎上創建子類組件，這統一併增強了多態性和封裝性。典型地來說就是用類來對組件進行分組，而且還可以定義新類爲現存的類的擴展，這樣就可以將類組織成樹形或網狀結構，這體現了動作的通用性。
由於抽象性、封裝性、重用性以及便於使用等方面的原因，以組件爲基礎的編程在腳本語言中已經變得特別流行。Python 和 Ruby 是最近纔出現的語言，在開發時完全採用了 OOP 的思想，而流行的 Perl 腳本語言從版本5開始也慢慢地加入了新的面向對象的功能組件。用組件代替“現實”上的實體成爲 JavaScript（ECMAScript） 得以流行的原因，有論證表明對組件進行適當的組合就可以在英特網上代替 HTML 和 XML 的文檔對象模型（DOM）。
設計模式、技術和直覺構成嚴峻的挑戰。這是選擇編程語言之前必須認識到的，儘管不同語言的設計特性可能促進或者阻礙這一轉化。
在網絡應用的增長中，一個很重要的部分是小型移動設備和特殊Internet設備的爆炸性增長。這些設備各有各的操作系統，或者只在某種特定的設備領域內有共同的操作系統。我們現在還可以一一列舉出這些設備——家庭接入設備、蜂窩電話、電子報紙、PDA、自動網絡設備等等。但是這些設備領域的數量和深入程度將會很快變得難以估量。我們都知道這個市場大得驚人，PC的興起與之相比不過小菜一碟。因此在這些設備的應用程序市場上，競爭將會相當殘酷。獲勝的重要手段之一，就是儘快進入市場。開發人員需要優秀的工具，迅速高效地撰寫和調試他們的軟件。平臺無關性也是制勝祕訣之一，它使得程序員能夠開發出支持多種設備平臺的軟件。
我預期的另一個變化是，我們對於代碼(Java)和數據(XML)協同型應用程序的開發能力將會不斷提高。這種協同是開發強大應用程序的核心目標之一。我們從XML的迅速流行和ebXML規範的進展中，已經看到了這個趨勢。ebXML是一個針對電子商務和國際貿易的，基於XML的開放式基礎構架，由聯合國貿易促進和電子商務中心(UN/CEFACT)與結構性信息標準推進組織(OASIS)共同開發。
我們能否期望出現一個真正的面向組件(component-oriented)的語言？它的創造者會是誰呢？
Stroustrup: 我懷疑，這個領域中之所以缺乏成果，正是因爲人們——主要是那些非程序員們——對“組件”這個意義含糊的字眼寄予了太多的期望。這些人士夢想，有朝一日，組件會以某種方式把程序員趕出歷史舞臺。以後那些稱職的“設計員”只需利用預先調整好的組件，把鼠標拖一拖放一放，就把系統組合出來。對於軟件工具廠商來說，這種想法還有另一層意義，他們認爲，到時候只有他們才保留有必要的技術，有能力編寫這樣的組件。
這種想法有一個最基本的謬誤：這種組件很難獲得廣泛歡迎。一個單獨的組件或框架(framework)，如果能夠滿足一個應用程序或者一個產業領域對所提出的大部分要求的話，對於其製造者來說就是划算的產品，而且技術上也不是很困難。可是該產業內的幾個競爭者很快就會發現，如果所有人都採用這些組件，那麼彼此之間的產品就會變得天下大同，沒什麼區別，他們將淪爲簡單的辦事員，主要利潤都將鑽進那些組件/框架供應商的腰包裏！
小“組件”很有用，不過產生不了預期的槓桿效應。中型的、更通用的組件非常有用，但是構造時需要非同尋常的彈性。
原文出處：https://www.cnblogs.com/gentleman-cklai/p/6921489.html
尊重原創