軟件評測師筆記_面向對象設計方法學20161020

面向對象方法學概述

究竟怎樣纔算真正的「面向對象」（Object-Oriented，OO）呢？Peter Coad和Edward Yourdon提出了下列等式：

面向對象 = 對象（Objects）

＋ 類（Cclasses）

＋ 繼承（Inheritance）

＋ 消息通訊（Communication With Messages）

1）對象與封裝

對象（Object）是系統中用來描述客觀事物的一個實體，它是構成系統的一個基本單位。面向對象的軟件系統是由對象組成的，複雜的對象由比較簡單的對象組合而成。也就是說，面向對象方法學使用對象分解取代了傳統方法的功能分解。

對象三要素是對象標識、屬性和服務。

（1）對象標識（Object Identifier），也就是對象的名字，供系統內部惟一地識別對象。定義或使用對象時，均應指定對象標識。

（2）屬性（Attribute），也稱狀態（State）或數據（Data），用來描述對象的靜態特徵。在某些面向對象的程序設計語言中，屬性一般被稱爲成員變量（Member Variable）或簡稱變量（Variable）。

（3）服務（Service），也稱爲操做（Operation）、行爲（Behavior）或方法（Method）等，用來描述對象的動態特徵。在某些面向對象的程序設計語言中，服務一般被稱爲成員函數（Member Function）或簡稱函數（Function）。

封裝（Encapsulation）是對象的一個重要原則。它有兩層含義：第一，對象是其所有屬性和所有服務緊密結合而造成的一個不可分割的總體；第二，對象是一個不透明的黑盒子，表示對象狀態的數據和實現操做的代碼都被封裝在黑盒子裏面。使用一個對象的時候，只需知道它向外界提供的接口形式，無須知道它的數據結構細節和實現操做的算法。從外面看不見，也就更不可能從外面直接修改對象的私有屬性了。

 

2）類

類（Class）是對具備相同屬性和服務的一個或一組對象的抽象定義。

類與對象是抽象描述與具體實例的關係，一個具體的對象被稱爲類的一個實例（instance）。

 

3）繼承與多態性

（1）繼承（Inheritance）是面向對象方法學中的一個十分重要的概念，其定義是：特殊類（或稱子類、派生類）的對象擁有其通常類（或稱父類、基類）的所有屬性與服務，稱作特殊類對通常類的繼承。在面向對象方法學中，繼承是提升軟件開發效率的重要緣由之一。

（2）多態性（Polymorphism）是指通常類中定義的屬性或服務被特殊類繼承以後，能夠具備不一樣的數據類型或表現出不一樣的行爲。使用多態技術時，用戶能夠發送一個通用的消息，而實現的細節則由接受對象自行決定，這樣同一消息就能夠調用不一樣的方法。多態性不只增長了面向對象軟件系統的靈活性，進一步減小了信息冗餘，並且顯著提升了軟件的可重用性和可擴充性。多態有多種不一樣的形式，其中參數多態和包含多態稱爲通用多態，過載多態和強制多態稱爲特定多態。

 

4）消息通訊

消息（Message）就是向對象發出的服務請求，它應該含有下述信息：提供服務的對象標識、消息名、輸入信息和回答信息。對象與傳統的數據有本質區別，它不是被動地等待外界對它施加操做，相反，它是進行處理的主體，必須發消息請求它執行它的某個操做，處理它的私有數據，而不能從外界直接對它的私有數據進行操做。

消息通訊（Communication With Messages）也是面向對象方法學中的一條重要原則，它與對象的封裝原則密不可分。封裝使對象成爲一些各司其職、互不干擾的獨立單位；消息通訊則爲它們提供了惟一合法的動態聯繫途徑，使它們的行爲可以互相配合，構成一個有機的系統。

只有同時使用對象、類、繼承與消息通訊，纔是真正面向對象的方法。

 

面向對象方法學的優勢，

與人類習慣的思惟方法一致。

穩定性好

可重用性好

易開發大型軟件產品

可維護性好。

 

OMT方法的OOA模型包括對象模型、動態模型和功能模型。

（1）對象模型表示靜態的、結構化的系統的「數據」性質。它是對模擬客觀世界實體的對象及對象彼此間的關係的映射，描述了系統的靜態結構，一般用類圖表示。

（2）動態模型表示瞬時的、行爲化的系統的「控制」性質，它規定了對象模型中的對象的合法變化序列，一般用狀態圖表示。

（3）功能模型表示變化的系統的「功能」性質，它指明瞭系統應該「作什麼」，所以更直接地反映了用戶對目標系統的需求，一般用數據流圖表示。

OMT方法的3個模型，分別從3個不一樣側面描述了所要開發的系統：功能模型指明瞭系統應該「作什麼」；動態模型明確了何時作（即在何種狀態下接受了什麼事件的觸發）；對象模型則定義了作事情的實體。這3種模型相互補充、相互配合，3者之間具備下述關係。

（1）動態模型展現了對象模型中每一個對象的狀態及它接受事件和改變狀態時所執行的操做；而功能模型中的處理則對應於對象模型中的對象所提供的服務。

（2）對象模型展現了動態模型中是誰改變了狀態和經受了操做；而功能模型中的處理則可能產生動態模型中的事件。

（3）對象模型展現了功能模型中的動做者、數據存儲和流的結構；而動態模型則展現了功能模型中執行加工的順序。

 

2）創建對象模型

Peter Coad和Edward Yourdon在1991年出版的《面向對象的分析》（Object-Oriented Analysis）一書中指出，複雜系統的對象模型一般由五個層次組成：類及對象層、結構層、主題層、屬性層和服務層。上述五個層次對應着創建對象模型的五項主要活動：肯定類與對象、肯定結構與關聯、劃分主題、定義屬性和定義服務。但這五項活動徹底不必順序完成，也無須完全完成一項活動以後再開始另一項活動。

（1）肯定類與對象：類與對象是在問題域中客觀存在的，系統分析的重要任務之一就是找出這些類與對象。首先找出全部候選的類與對象，而後進行反覆篩選，刪除不正確或沒必要要的類與對象。

（2）肯定結構與關聯：結構與關聯反應了對象（或類）之間的關係，主要有如下幾種。

通常—特殊結構（Generalization-Specialization Structure），又稱分類結構（Classification Structure），是由一組具備通常—特殊關係（繼承關係）的類所組成的結構。通常—特殊關係（Generalization- Specialization Relation）的表達式爲：is a kind of。

總體—部分結構（Whole-Part Structure），又稱組裝結構（Composition Structure），是由一組具備總體-部分關係（組成關係）的類所組成的結構。總體—部分關係（Whole-Part Relation）的表達式爲：Has A。

實例關聯（Instance Connection），即一個類的屬性中含有另外一個類的實例（對象），它反映了對象之間的靜態聯繫。

消息關聯（Message Connection），即一個對象在執行本身的服務時須要經過消息請求另外一個對象爲它完成某個服務，它反映了對象之間的動態聯繫。

（3）劃分主題：在開發大型、複雜軟件系統的過程當中，爲了下降複雜程度，須要把系統劃分紅幾個不一樣的主題。注意，應該按問題域而不是用功能分解方法來肯定主題，應該按照使不一樣主題內的對象相互間依賴和交互最少的原則來肯定主題。

（4）定義屬性：爲了發現對象的屬性，首先考慮借鑑以往的OOA結果，看看相同或類似的問題域是否有已開發的OOA模型，儘量複用其中同類對象的屬性定義。而後，按照問題域的實際狀況，以系統責任爲目標進行正確的抽象，從而找出每一對象應有的屬性。

（5）定義服務：發現和定義對象的服務，也應借鑑以往同類系統的OOA結果並儘量加以複用。而後，研究問題域和系統責任以明確各個對象應該設立哪些服務，以及如何定義這些服務。

 

3）創建動態模型

創建動態模型的第一步，是編寫典型交互行爲的腳本。雖然腳本中不可能包括每一個偶然事件，但至少必須保證不遺漏常見的交互行爲。第二步，從腳本中提取出事件，肯定觸發每一個事件的動做對象及接受事件的目標對象。第三步，排列事件發生的次序，肯定每一個對象可能有的狀態及狀態間的轉換關係，並用狀態圖描繪它們。最後，比較各個對象的狀態圖，檢查它們之間的一致性，確保事件之間的匹配。

 

4）創建功能模型

OMT方法中的功能模型實際上就是結構化方法中的數據流圖。從這點看，OMT方法並非「純」面向對象的。這是OMT方法的一大缺陷。

1992年，Ivar Jacobson在《面向對象的軟件工程——用例驅動的途徑》（Object-Oriented Software Engineering，A Use Case Driven Approach）中首次提出了「用例」（Use Case）的概念。隨後，有人提出以用例圖取代數據流圖進行需求分析和創建功能模型，這應該被看作是對OMT方法的重大改進。使用用例圖創建起來的系統模型也被稱爲用例模型。

一個用例是能夠被行爲者感覺到的、系統的一個完整的功能。一幅用例圖包含的模型元素有系統、行爲者、用例及用例之間的關係。用例模型描述的是外部行爲者所理解的系統功能。

目前，「用例驅動」已成爲軟件開發過程的一條重要原則。

 

4．面向對象的設計

1）OOA與OOD的關係

與結構化方法不一樣，面向對象的方法並不強調分析與設計之間嚴格的階段劃分。OOA與OOD所採用的概念、原則和表示法都是一致的，兩者之間不存在鴻溝，不須要從分析文檔到設計文檔的轉換，因此有些工做不管在分析時進行仍是在設計時進行都不存在障礙。固然，OOA與OOD仍然有不一樣的分工和側重點。

關於OOA與OOD的關係，目前有兩種不一樣的觀點。

一種觀點是繼續沿用傳統的分工——分析着眼於系統「作什麼」，設計解決「怎麼作」的問題。而Peter Coad和Edward Yourdon的OOA&D方法則採用了另一種分工方式——分析階段只考慮問題域和系統責任，創建一個獨立於實現的OOA模型；設計階段考慮與實現有關的因素，對OOA模型進行調整並補充與實現有關的部分，造成OOD模型。本書的OOD方法主要依據Coad/Yourdon的觀點。

Coad/Yourdon的OOD模型包括如下四個部件：人機交互部件、問題域部件、任務管理部件、數據管理部件。與此對應的OOD過程也包括四項活動：設計人機交互部件、設計問題域部件、設計任務管理部件、設計數據管理部件。

2）設計問題域部件

經過OOA所得出的問題域精確模型，爲設計問題域部件奠基了良好的基礎。一般，OOD僅需從實現角度對問題域模型作一些補充和修改，主要是增添、合併或分解類與對象、屬性及服務、調整繼承關係等。

3）設計人機交互部件

在OOA過程當中，已經對用戶界面需求作了初步分析。在OOD過程當中，則應該對系統的人機交互部件進行詳細設計，以肯定人機交互的細節，其中包括指定窗口和報表的形式、設計命令層次等項內容。

4）設計任務管理部件

主要是識別事件驅動任務，識別時鐘驅動任務，識別優先任務，識別關鍵任務，識別協調任務，審查每一個任務並定義每一個任務。

5）設計數據管理部件

提供數據管理系統中存儲和檢索對象的基本結構，隔離具體的數據管理方案（如普通文件、關係數據庫、面向對象數據庫等）對其餘部分的影響。