2.5 面向對象分析方法＊

面向對象分析方法的基本思想是從現實世界中客觀存在的事物出發來構造軟件，并在系統構造中盡可能地運用人類的自然思維方式。開發一個軟件是為了解決某些問題，這些問題涉及的業務范圍稱為該軟件的問題域。面向對象強調以問題域中的事物為中心來思考問題、認識問題，并根據這些事物的本質特征，把它抽象地表示為系統中的對象，作為系統的基本構成單位。因此，面向對象方法可以使系統直接地映射問題域，保持問題域中事物及其相互關系的本來面貌。

2.5.1 面向對象分析方法概述

面向對象分析方法的形成最初是從面向對象程序設計語言開始的，隨之逐步形成面向對象的分析和設計方法。創始的面向對象程序設計語言是 20世紀60年代的Simula 67語言。它是一種通用的仿真建模語言，其中對象的概念和方法，啟示了人們在軟件設計方面的新思維。各種面向對象程序設計語言的出現直接導致了面向對象的廣泛應用，面向對象技術也很快被應用于系統分析和系統設計。20世紀80年代末以來，面向對象技術成為研究的熱點，出現了幾十種支持軟件開發的面向對象方法。其中，比較有代表性的方法有1986年Booch提出的面向對象分析與設計方法論（OOA/OOD）、1991年Rumbaugh提出的面向對象模型技術（OMT）、1994年Jacobson提出的面向對象軟件工程方法學（OOSE）。

經過一段時間的探索，Booch、Rumbaugh和Jacobson將他們各自的對象建模方法結合到一起，提出了統一建模語言（Unified Modeling Language，UML），該方法結合各個方法的優點，統一了符號體系，并從其他的方法和工程實踐中吸收了許多經過實際檢驗的概念和技術。經過幾年的發展，UML已經成為面向對象方法的公認標準。

面向對象軟件開發方法的一般思路是首先獲取需求，用文字說明、圖形、表格等建立描述客觀世界的抽象模型，識別與問題有關的類與類之間的聯系，加上與實現環境有關的類（如界面等），逐步細化模型；經過設計的類與聯系調整后，完成整個系統的描述，然后對類進行編碼和測試，得到結果。該方法具有以下主要特點：

（1）從問題域中客觀存在的事物出發來構造軟件系統，用對象作為對這些事物的抽象表示，并以此作為系統的基本構成單位。

（2）事物的靜態特征（可以用一些數據來表達的特征）用對象的屬性來表示，事物的動態特征（事物的行為）用對象的操作來表示。

（3）對象的屬性與操作結合為一體，成為一個獨立的實體，對外屏蔽其內部細節（稱為封裝）。

（4）對事物進行分類，把具有相同屬性和相同操作的對象歸為一類，類是這些對象的抽象描述，每個對象是其類的一個實例。

（5）通過在不同程度上運用抽象原則（忽略事物之間的一些差異），可以得到較一般和較特殊的類。特殊類繼承一般類的屬性和操作，面向對象方法支持這種繼承關系的描述與實現，從而簡化系統的構造過程及其文檔。

（6）復雜對象可以用簡單的對象作為其構成部分（稱為聚合）。

（7）對象之間通過消息進行通信，以實現對象之間的動態聯系。

（8）通過關聯表達對象之間的靜態關系。

2.5.2 面向對象建模

為了更好地理解問題，人們常常采用建立問題域模型的方法。模型就是為了理解事物而對事物做出的一種抽象，是對事物的一種可視化的描述。模型可以幫助人們思考問題，定義術語，在選擇術語時做出適當的假設，并且幫助人們保持定義和假設的一致性。建立模型主要是為了減少復雜性。因為當面對大量模糊的、涉及眾多專業領域的、錯綜復雜的信息時，開發人員往往感到無從下手。模型提供了組織大量信息的一種有效機制，為了開發復雜的軟件系統，開發人員需要從不同的角度抽象出目標系統的特性，使用精確的表示方法構造系統模型，驗證模型是否滿足用戶對目標系統的需求，并在設計過程中逐漸把和實現有關的細節加入模型，直至最終用程序實現模型。

采用面向對象方法開發軟件，通常需要建立幾種形式的模型，主要包括用例模型、概念模型、設計模型、配置模型、實現模型、測試模型等。使用用例驅動的開發方法是通過建立用況模型，再以用例模型為核心構造一系列模型，各個模型之間的關系如圖2.22所示。

（1）用例模型包含所有用例及其與用戶的關系。

（2）對象模型包含問題域涉及的類及其屬性和關系，其作用是更詳細地提煉用例，將系統的行為初步分配給提供行為的一組對象。

（3）設計模型將系統的靜態結構定義為子系統、類和接口，并定義由子系統、類和接口之間的協作來實現的用例。

（4）實現模型包含構件和類到構件的映射。

（5）配置模型定義計算機的物理節點和構件到這些節點的映射。

（6）測試模型描述用于驗證用例的測試用例。

所有這些模型都是相關的，只是每種模型的側重點不同，它們合起來表示整個系統。在分析過程中，構造出完全獨立于實現的分析模型；在設計階段，則把求解域的結構逐步加入模型；在實現中把問題域和求解域的結構都編成程序代碼，并進行嚴格的測試驗證。

2.5.3 面向對象分析

面向對象分析的目標是完成對所解問題的分析，解決待建系統要做什么的問題，并建立系統的模型，為達到這一目標，必須完成以下任務：

（1）通過與用戶溝通，了解用戶的基本需求。

（2）從用戶的角度認識系統，建立用例模型。

（3）以基本需求為指南，識別對象和類，包括定義其屬性和操作。

（4）刻畫類的層次結構。

（5）標識類（對象）之間的關系。

（6）識別對象的行為和系統的工作過程。

（7）遞進地重復任務（1）～（6），直至完成模型建立。

任務（2）～（5）刻畫了待建系統的靜態結構（概念模型），任務（6）刻畫了系統的動態行為（動態模型）。

一般面向對象分析可以從理解系統的使用方式開始，如果系統是人機交互的，則考慮被人使用的方式；如果系統涉及過程控制，則考慮被機器使用的方式；如果系統協同并控制應用程序，則考慮應用程序的使用方式。

1.獲取用戶需求

獲取用戶需求需要開發人員與用戶充分交流，人們常常使用用例來收集用戶的需求。首先找出使用該系統的不同執行者，這些執行者代表使用系統的不同角色。每個執行者可以敘述他如何使用系統，或者說明他需要系統提供什么功能，執行者提出的每個功能都是系統的一個用例。

一個用例描述了系統的一種用法或一個功能，所有執行者提出的所有用例就構成了系統的功能需求。開發人員根據用戶提出的需求，建立用況模型，作為雙方認識系統和開發系統的基礎。

2.標識對象和類

在確定了系統的所有用例后，即可開始識別問題域中的對象和類。標識系統中的對象可以從問題域或用例描述著手，標識類和標識對象是一致的。把具有相同屬性和操作的對象定義成一個類，為了對類有進一步認識，需要識別屬性和操作。從本質上講，屬性定義了對象，它們表明了對象的基本特征，即為了完成用戶規定的目標必須保存的信息。操作定義了對象的行為，并以某種方式修改對象的屬性值。對操作的識別可通過對系統的過程描述分析、提取出來，通常把過程描述中的動詞作為候選操作。

3.定義類的層次結構

在確定系統的類后，就可以識別類的層次結構。類之間的關系包括泛化、聚合、關聯3種。泛化關系反映了類之間的一般與特殊的關系，如交通工具可以分為汽車、飛機、輪船等。交通工具類就是一個一般類，汽車、飛機、輪船則是特殊類。一般與特殊之間是一種“is a”的關系，如飛機是一種交通工具。汽車類還可以繼續劃分為轎車、貨車等類，這樣可形成類的層次結構。聚合關系反映了類之間整體與部分的關系，如學校由教師、學生、教學設備、后勤服務等部分組成。整體與部分關系是一種“has a”的關系，如學校有教師。同樣整體與部分結構也具有層次結構。關聯關系反映類之間直接聯系的關系。例如，流水線生產是由各類部件裝配車間共同構成的，上一個車間的產品是下一個車間的材料。即一個類的實例必須要用另一個類的實例才能完成工作。

4.建立對象（概念）模型

在明確了對象、類、屬性、操作及類的層次結構之后，進一步識別對象、類之間的關聯關系，就可以建立系統的對象（概念）模型。對象模型描述了系統的靜態組成和結構，同時也是認識系統動態特性的基礎。

對象行為模型描述了系統的動態機制，它指明系統如何響應外部事件或操作。建立動態模型的步驟如下：

（1）分析所有用例，理解系統中的交互行為。

（2）標識驅動交互序列的事件，理解這些事件如何與特定的對象相關聯。

（3）為系統建立交互模型。

（4）分析對象的生存周期，為主要對象建立狀態圖。

（5）評審動態模型，以驗證其準確性與一致性。

2.5.4 用例模型

用例模型主要由用例、用例描述和用例圖組成，用來描述系統的外部特征。它表示從系統外部用戶（執行者或角色）的觀點看系統應該具備什么功能，因此它只需要說明系統實現什么功能，而不必說明如何實現該功能。一幅用例圖包含的模型元素有系統、執行者、用例及用例之間的關系，如圖2.23所示。

從圖2.23可以看出系統被看成一個提供用例的黑盒子，其內部如何工作、用例如何實現，這些對于建立用況模型來說都不用考慮。代表系統的方框的邊線表示系統邊界，用于劃定系統的功能范圍。所有用例都在系統邊界內，表明它們屬于一個系統。角色則放在系統邊界外部，表明角色是系統的外部執行者，但角色負責直接（或間接）驅動與之關聯的用例的執行。

1.執行者

執行者是指與系統交互的人或其他系統，它代表外部實體。使用用例并且與系統交互的任何人或事物都是執行者，它在UML中常以一個稻草人圖符來表示。執行者代表一種角色，而不是某個具體的人或物，角色由用戶承擔，但它不等同于用戶。例如，在銀行取款系統中，使用ATM的取款人是執行者。在一個具體的取款過程中，既可以是張三，也可以是李四，但不能把張三、李四這樣的個體稱為執行者。事實上，一個具體的人可以充當多種不同的角色。例如，某個人既可以是取款人，也可以是銀行的工作人員，負責處理取款業務等。不僅如此，角色還可以是某個設備、某件事物或某個外部系統。在用例圖中直線連接角色和用例，表示兩者之間交換信息，稱為通信聯系。角色激活用例，并與用例交換信息。

2.用例

用例是一個可以被執行者感受到的、系統的、完整的功能。在UML中把用例定義成系統完成的一系列動作序列，動作的結果能夠被特定的執行者察覺。這些動作除完成系統內部復雜計算與工作外，還包括與一些執行者的通信。用例通過關聯與執行者連接，關聯指出一個用例與哪些執行者交互，這種交互是雙向的。

3.用例建模

用例建模是直接面向用戶的，主要以需求陳述為依據，有關系統的業務邊界、使用對象等，是構造系統用況模型的基本元素。用況建模的步驟如下：

（1）從幾個方面識別系統的執行者，包括需要從系統中得到服務的人、設備和其他軟件系統等。

（2）分析系統的業務邊界或執行者對于系統的基本業務需求，并將其作為系統的基本用例。

（3）分析基本用例，將基本用例中具有一定獨立性的功能，特別是具有公共行為特征的功能分解出來，將其作為包含用例供基本用例使用。

（4）分析基本用例功能以外的其他功能，將其作為擴展用例供基本用例進行功能擴展。

（5）分析并建立執行者與用例之間的通信關系。