第二部分 面向對象分析
2.1 面向對象分析(OOA)的定義？
OOA——面向對象的分析，就是運用面向對象方法進行系統分析，對問題域(問題所涉及的范圍)和系統責任(所開發的系統應具備的職能)進行分析與理解，找出描述問題及系統責任所需要對象，定義對象的屬性、操作以及它們之間的關系。
2.2 面向對象分析(OOA)的優點？
- 加強了了對問題域和系統責任的理解；
- 改進與分析有關的各類人員之間的交流；
- 對需求的變化具有較強的適應性；
- 支持軟件復用。
2.3 面向對象工具——UML(Unified Modeling Language)統一建模語言
UML是對軟件密集型系統中的制品(模型、源代碼、測試用例等)進行可視化、詳述、構造和文檔化的語言。
（1）UML特點
- 統一的標准
- 面向對象
- 可視化、表示能力強大
- 獨立於過程
- 概念明確，建模表示法簡潔，圖形結構清晰，容易掌握和使用
（2）UML的構成
UML中的3類主要元素是基本構造塊、規則、公共機制
（3）UML中的視圖
UML中的視圖包括用例視圖、邏輯視圖、實現視圖、進程視圖、部署視圖，被稱為“4+1”視圖
- 用例視圖：用於表達系統的功能性需求
- 邏輯視圖：用於表示系統的概念設計和子系統結構等
- 實現視圖：用於說明代碼的結構
- 進程視圖：用於說明系統中並發執行和同步的情況
- 部署視圖：用於定義硬件結點的物理結構
2.4 面向對象分析(OOA)模型及其規約
OOA模型是指運用面向對象的分析方法建立的系統模型，包括基本模型、需求模型和輔助模型三部分。
基本模型：基本模型以直觀的方式表達了最重要的系統結構信息
需求模型：需求模型用於定義用戶需求
輔助模型：輔助模型提供幾種對基本模型進行組織或者加強理解的輔助圖形
模型規約：對模型進行詳細的描述
2.4.1 基本模型——類圖
構成類圖的主要成分是類、屬性、操作、一般-特殊結構、整體-部分結構、關聯和消息。這些成分所表達的模型信息可以從下面三個層次來看待：
- 對象層——給出系統中所有反映問題域與系統責任的對象，即描述系統中應設立哪些類的對象
- 特征層——給出每一個類(及其所代表的對象)的內部特征，即給出每個類的屬性與操作，描述對象的內部構成情況
- 關系層——給出各個類(及其所代表的對象)彼此之間的關系，包括：
（1）繼承關系(即泛化關系)——通過一般-特殊結構表示
泛化關系"a kind of"，類與類之間的關系即繼承關系
（2）聚集與組合關系——通過整體-部分結構表示
聚集關系"has-a"，組合關系"contains-a"：聚集關系表示事物的整體-部分關系較弱的情況，組合關系表示事物的整體-部分關系較強的情況
區別：組合關系中的整體和部分具有同樣的生命周期。在聚集關系中，代表部分事物的對象可以屬於多個聚集對象，可以為多個聚集對象所共享，而且可以隨時改變它所從屬的聚集對象。代表部分事物的對象與代表聚集事物對象的生存期無關，一旦刪除了它的一個聚集對象，不一定也就隨便刪除代表部分事物的對象。在組合關系中，代表整體事物的對象負責創建和刪除代表部分事物的對象，代表部分事物的對象只屬於一個組合對象。一旦刪除了組合對象，也就隨即刪除了相應的代表部分事物的對象。
（3）關聯關系——用靜態關系表示，分為自返關聯、二元關聯、N元關聯
關聯(association)是對具有共同的結構特性、行為特性、關系和語義的鏈(鏈表示對象與對象之間的關系，關聯表示類與類之間的關系)的描述
（4）依賴關系——用消息表示對象之間在行為上的依賴關系
假設有兩個元素X、Y，如果修改X的定義可能會導致對另一個元素Y的定義的修改，則稱元素Y依賴於元素X。對於類而言，如果兩個類之間有關聯關系，那么一般只要表示出關聯關系即可，不用再表示這兩個類之間還有依賴關系。
建立類圖的步驟：
- 研究問題領域，確定系統的需求
- 確定類，明確類的含義和職責，確定屬性和操作
- 確定類之間的關系
- 調整和細化已得到的類和類之間的關系，解決諸如命名沖突、功能重復等問題
- 繪制類圖並增加相應的說明
ps：抽象類與接口區別：
抽象類是不能直接產生實例的類，因為抽象類中的方法往往只是一些聲明，而沒有具體的實現，因此不能抽象類實例化。接口與抽象類很相似，但兩者之間存在不同的地方：接口不能含有屬性，而抽象類可以含有屬性；接口中聲明的所有方法都沒有實現部分，而抽象類中的某些方法可以有具體的實現。
2.4.2 需求模型——用例圖(用況圖)
用例是系統、子系統或類和外部的參與者(actor)進行交互的動作序列的說明，包括可選的動作序列和會出現異常的動作序列。而參與者是指系統以外的、需要使用系統或與系統交互的東西，包括人、設備、外部系統等。用例間的關系主要有關聯、擴展(extend)、泛化、包含(include)關系等。
（1）泛化關系：子用例繼承了父用例的行為和含義，子用例也可以增加新的行為和含義或覆蓋父用例中的行為和含義
（2）包含關系<<include>>：指兩個用例之間，其中一個用例的行為包含了另一個用例，包含關系是比較特殊的依賴關系。在包含關系中，箭頭的方向是從基本用例指向包含用例，即基本用例依賴於包含用例。
（3）擴展關系<<extend>>：擴展關系是對擴展用例有更多的規則限制，即基本用例必須聲明若干擴展點，而擴展用例只能在這些擴展點上增加新的行為和含義。在擴展關系中，箭頭的方向是從擴展用例到基本用例，也就是說，擴展用例是依賴於基本用例的。
注意區別包含關系與擴展關系：在包含關系中，在執行基本用例時，一定會執行包含用例；在擴展關系中，一個基本用例執行時，可以執行、也可以不執行擴展部分，簡言之，滿足條件就執行，不滿足條件就不執行。
用例圖：把用例、參與者以及它們之間的關系用一些圖像符號進行可視化表示，便得到用例圖。它是直接描述需求的，所以是一個需求模型。
尋找用例的步驟：
- 找出系統外部的參與者和外部系統，確定系統的邊界和范圍
- 確定每一個參與者所期望的系統行為
- 把這些系統行為命名為用例
- 使用泛化、包含、擴展等關系處理系統行為的公共或變更部分
- 編制每一個用例的腳本
- 區分主事件流和異常情況的事件流，如果需要，可以把表示異常情況的事件流作為單獨的用例處理
- 細化用例圖，解決用例間的重復與沖突問題
2.4.3輔助模型——包圖、順序圖、活動圖及其他
（1）包圖：包(package)是一種將其他模型元素組織起來，形成較大粒度的系統單位的機制。UML中，包是分組事物的一種，它是在建模時用來組織模型中的元素的，在系統運行時並不存在包的實例，這點和類不一樣，類在運行時會有實例。
設計包的原則：
- 重用等價原則：指把類放入包中時，應考慮把包作為可重用的單元
- 共同閉包原則：指把那些需要同時改變的類放在一個包中
- 共同重用原則：指的是不會一起使用的類不要放入同一個包中
- 非循環依賴原則：指的是包之間的依賴關系不要形成循環
ps：重用等級原則、共同閉包原則、共同重用原則這3個原則事實上是相互排斥的，不可能同時被滿足。它們是從不同使用者的角度提出的，重用等價原則和共同重用原則是從重用人員的角度考慮的，而共同閉包原則是從維護人員的角度考慮的。共同閉包原則希望包越大越好，而共同重用原則卻要求包越小越好。
（2）順序圖：用來描述一組相互協作的對象在完成一項功能時彼此之間的交互情況。它按時間順序把各個對象所執行的操作以及它們之間所傳達的消息展現出來，因此可以清晰直觀地表示對象之間的行為依賴關系以及操作與消息的時序關系。
建立順序圖的步驟：
- 確定交互過程的上下文
- 識別參與交互過程的對象
- 為每個對象設置生命線，即確定哪些對象存在於整個交互過程中，哪些對象在交互過程中被創建和撤銷
- 從引發這個交互過程的初始消息開始，在生命線之間自頂向下依次畫出隨后的各個消息
- 如果需要表示消息的嵌套，或表示消息發生時的時間點，則采用控制焦點(控制焦點是順序圖中表示時間段的符號，表示為在生命線上的小矩形)
- 如果需要說明時間約束，則在消息旁邊加上約束說明
- 如果需要，可以為每個消息附上前置條件和后置條件
(3) 活動圖：活動圖的作用是對系統的行為建模，它把系統中的一項行為表示成一個可以由計算機、人或者其他執行者執行的活動，通過給出活動中的各個動作以及動作之間的轉移關系來描述系統的行為。類圖中的每個類都要定義它應該提供的操作，但是並不能把每個操作的執行過程具體地表示出來。順序圖表現了一組對象是如何通過消息進行交互的，以及有關的操作和消息的時間順序，但是也沒有詳細地表示每個操作內部的執行情況。對此，活動圖可以起到很好的補充作用。一般活動圖可以對系統的工作流程建模，即對系統的業務過程建模，也可對具體的操作建模，用於描述計算機過程的細節。
活動(activity)表示的是某流程中的任務的執行，它可以表示某算法過程中語句的執行。在活動圖中注意區分動作狀態和活動狀態。動作狀態是原子的，不能被分解，沒有內部轉移，沒有內部活動，動作狀態的工作所占用的時間是可以忽略的，動作狀態的目的是執行進入動作，然后轉向另一個狀態。活動狀態是可分解的，不是原子的，其工作的完成需要一定的時間。
泳道：泳道是活動圖中的區域划分，根據每個活動的職責對所有活動進行划分，每個泳道代表一個責任區。泳道和類並不是一一對應的關系，泳道關心的是其所代表的職責，一個泳道可能由一個類實現，也可能由多個類實現。
在活動圖中，對於同一個觸發事件，可以根據不同的警戒條件轉向不同的活動，每個可能的轉移是一個分支。如果要表示系統或對象中的並發行為，則可以使用分叉(fork)和匯合(join)這兩種建模元素。分叉表示的是一個控制流被兩個或多個控制流代替，經過分叉后，這些控制流是並發執行的；匯合正好與分叉相反，表示兩個或多個控制流被一個控制流代替。
（4）構件圖和部署圖：構件圖和部署圖是對面向對象系統物理方面建模的兩個圖
- 構件圖：對源代碼文件之間的相互關系建模；對可執行文件之間的相互關系建模
- 部署圖：部署圖可以用來顯示系統中計算結點的拓撲結構和通信路徑與結點上運行的軟構件等。一個系統模型只有一個部署圖
基本概念：
構件：構件是系統中遵從一組接口且提供其實現的物理的、可替換的部分。構件包括部署構件(如dll文件、exe文件數據庫表等)、工作產品構件(如源代碼文件、數據文件等)、執行構件(系統執行后得到的構件)
構件圖中的構件與類圖中的類區別：
- 類是邏輯抽象，構件是物理抽象，即構件可以位於結點上
- 構件是對其他邏輯元素，如類、協作的物理實現
- 類可以有屬性和操作，構件通常只有操作，而且這些操作只能通過構件的接口才能使用
部署圖兩個基本概念：結點和連接
結點是存在於運行時的代表計算資源的物理元素，結點一般都具有一些內存而且常常具有處理能力，結點可以代表一個物理設備以及運行在該設備上的軟件系統。結點之間的連線表示系統之間進行交互的通信路徑，這個通信路徑稱為連接。部署圖的結點分為兩類，即處理機和設備
- 處理機是可以執行程序的硬件構件，如處理機有哪些進程、進程的優先級與進程調度方式
- 設備是無計算能力的硬件構件，如調制解調器、終端等
連接表示兩個硬件之間的關聯關系。
2.5 面向對象分析(OOA)過程
OOA過程包括以下主要活動
（1）建立需求模型——用例圖
- 確定系統邊界
- 發現參與者
- 定義用例
（2）建立基本模型——類圖
- 發現對象、定義它們的類
- 定義對象的內部特征——屬性和操作
- 定義對象的外部關系——一般-特殊結構、整體-部分結構、關聯和消息
（3）建立輔助模型
- 划分包，建立包圖
- 建立順序圖
- 建立活動圖
- 建立構件圖
- 建立部署圖
- 建立其他模型圖
（4）建立模型規約：對模型中的成分進行規范的定義和文字說明
（5）原型開發：可選，結合其他活動反復進行
以上各個OOA過程總體來說是一個反復進行，不斷完善的過程，以建立基本模型為中心，進行需求模型、基本模型、輔助模型的建立、修復與完善。
參考書籍
《面向對象的系統分析》(第2版) 邵維忠 楊芙清 著
《UML面向對象技術教程》 王少鋒 編著