軟件工程之面向對象分析深度解析

前文基礎：

1.軟件工程學概述：軟件工程學概述-CSDN博客?

2.軟件過程深度解析：軟件過程深度解析-CSDN博客?

3.軟件工程之需求分析涉及的圖與工具：軟件工程之需求分析涉及的圖與工具-CSDN博客?

4.軟件工程之形式化說明技術深度解析：https://lzm07.blog.csdn.net/article/details/147803429?

5.軟件工程之詳細設計深度解析：https://blog.csdn.net/lzm12278828/article/details/147807034?

一、面向對象分析的基本過程

（一）概述

面向對象分析（Object-Oriented Analysis, OOA）是通過抽象問題域中的實體及其關系，建立系統精確模型的過程。其核心思想是將現實世界中的事物映射為對象（Object），通過封裝、繼承、多態等機制描述系統行為。與傳統結構化分析相比，OOA更貼近人類認知方式，能有效降低復雜系統的開發難度。

OOA的目標是形成軟件需求規格說明書，主要由三個子模型構成：

（1）對象模型：描述系統靜態結構（類、對象及其關系）。

（2）動態模型：描述系統動態行為（狀態變化、事件交互）。

（3）功能模型：描述系統數據變換和處理邏輯。

實際分析過程需反復迭代，通常遵循“理解→表達→驗證”的循環：

（1）理解需求：與用戶、領域專家協作，明確系統邊界和功能。

（2）建立模型：通過三個子模型逐步細化需求，形成可驗證的規格說明。

（2）驗證模型：檢查模型的一致性、完整性和可實現性，確保符合用戶需求。

（二）3 個子模型與 5 個層次

1. 三個子模型

（1）對象模型：
以類圖為核心，描述系統中對象的靜態結構。例如，在線購物系統中的“用戶”“商品”“訂單”等類，以及它們之間的關聯（如“用戶下單”“訂單包含商品”）。對象模型是系統的基礎，其他模型依賴其提供的類和關系。

（2）動態模型：
以狀態圖和事件跟蹤圖為工具，描述對象的狀態變化和事件交互。例如，訂單的狀態從“已提交”變為“已支付”再到“已發貨”，需通過狀態圖明確觸發狀態轉換的事件（如“用戶支付”“倉庫發貨”）。

（3）功能模型：
以數據流圖（DFD）為核心，描述系統的數據處理邏輯。例如，在線購物系統的“訂單處理”功能可分解為“驗證庫存”“計算總價”“生成發票”等子處理，通過數據流圖展示數據流動和處理過程。

2. 五個層次

復雜系統的對象模型通常包含五個層次，形成逐層細化的結構：

（1）主題層：將系統劃分為若干主題（如“用戶管理”“訂單管理”），便于理解大型模型。

（2）對象類層：識別系統中的類與對象（如“用戶”“商品”）。

（3）結構層：定義類之間的關系（如繼承、關聯）。

（4）屬性層：為類添加屬性（如“用戶”的姓名、郵箱）。

（5）服務層：定義類的操作（如“用戶”的登錄、注冊）。

二、需求陳述

（一）書寫要點

需求陳述是OOA的起點，需清晰、準確地描述系統功能和約束。關鍵要點包括：

（1）問題范圍：明確系統邊界，區分系統內外部實體。

（2）功能需求：列出系統必須完成的任務（如“用戶可查詢訂單狀態”）。

（3）性能需求：定義響應時間、吞吐量等指標（如“訂單查詢響應時間≤2 秒”）。

（4）應用環境：描述系統運行的軟硬件環境（如“支持 Windows 和 macOS”）。

（5）假設條件：說明未經驗證的前提（如“用戶輸入數據格式正確”）。

書寫時應避免歧義，采用結構化語言（如“系統應允許用戶……”），并優先使用動詞短語描述功能。例如，“用戶提交訂單后，系統應發送確認郵件”比“系統要處理訂單”更明確。

（二）例子：在線購物系統需求陳述

項目背景：
某電商平臺需開發在線購物系統，支持用戶瀏覽商品、下單、支付，以及管理員管理商品庫存和訂單。

需求陳述：

1.功能需求：

用戶可注冊、登錄系統，瀏覽商品列表，查看商品詳情。

用戶可將商品加入購物車，修改購物車中商品的數量或刪除商品。

用戶提交訂單后，系統應生成唯一訂單號，并發送確認郵件。

管理員可添加、修改、刪除商品信息，查看訂單狀態并更新物流信息。

2.性能需求：

商品搜索響應時間≤1 秒（數據量≤10 萬條）。

訂單處理吞吐量≥100 筆 / 分鐘。

3.應用環境：

服務器端：Linux 操作系統，MySQL 數據庫，Tomcat 應用服務器。

客戶端：支持 Chrome、Firefox 等主流瀏覽器，移動端適配 iOS 和 Android。

4.假設條件：

用戶已安裝最新版本瀏覽器，網絡連接穩定。

支付接口由第三方支付平臺提供，系統無需處理支付安全問題。

三、建立對象模型

（一）確定類與對象

從需求陳述中提取名詞短語，篩選出與問題域相關的類。例如，在線購物系統中的候選類包括“用戶”“商品”“購物車”“訂單”“支付”等。需排除冗余（如“系統”）、無關（如“網絡”）或籠統（如“數據”）的類。

篩選原則：

（1）冗余類：重復表示同一概念的類（如“顧客”和“用戶”）。

（2）無關類：與系統功能無關的類（如“操作系統”）。

（3）籠統類：過于抽象的類（如“實體”）。

（4）屬性類：應作為屬性而非類的概念（如“商品顏色”）。

（5）操作類：應作為方法而非類的概念（如“支付處理”）。

（二）確定關聯

識別類之間的關系，如“用戶下單”（用戶與訂單的關聯）、“訂單包含商品”（訂單與商品的關聯）。關聯需明確重數（如“一個訂單包含多個商品”）和方向（如“用戶提交訂單”）。

關聯類型：

（1）普通關聯：如“用戶擁有購物車”。

（2）聚合關聯：如“購物車由多個商品項組成”。

（3）繼承關聯：如“管理員是特殊用戶”。

（三）劃分主題

將類分組為主題，降低模型復雜度。例如，在線購物系統可劃分為“用戶管理”“商品管理”“訂單管理”三個主題。主題應具有高內聚性，組內類關系緊密，組間耦合度低。

（四）確定屬性

為類添加描述性屬性。例如，“用戶”類的屬性包括姓名、郵箱、地址；“商品”類的屬性包括名稱、價格、庫存。屬性應滿足原子性（不可再分）和完整性（無遺漏關鍵信息）。

常見錯誤：

（1）誤把對象當屬性：如將“地址”作為“用戶”的屬性，而非獨立類。

（2）屬性冗余：如“訂單總價”可通過“商品價格 × 數量”計算，無需存儲。

（3）屬性不一致：如“商品價格”在不同類中單位不統一（元 / 美元）。

（五）識別繼承關系

通過泛化 - 特化關系（繼承）簡化類結構。例如，“管理員”是“用戶”的子類，繼承“用戶”的屬性和方法，并添加“權限管理”等特有功能。繼承可減少代碼冗余，提高可維護性。

繼承策略：

（1）自底向上：從具體類中提取公共屬性和方法，形成父類。

（2）自頂向下：從抽象父類逐步細化為具體子類。

（六）反復修改

對象模型需多次迭代優化。例如，初始模型中“訂單”和“支付”是獨立類，后續發現“支付”可作為“訂單”的一個狀態，從而合并為“訂單”類的屬性或子狀態。

優化方法：

（1）分解復雜類：如將“現金兌換卡”分解為“卡信息”和“交易記錄”。

（2）合并冗余類：如“分行”和“分行計算機”可合并為“分行”類。

（3）調整關聯關系：如將三元關聯拆分為二元關聯。

四、建立動態模型

（一）編寫腳本

描述系統典型交互場景（如“用戶下單流程”），明確事件順序和參與者。腳本需覆蓋正常流程和異常情況，例如：
用戶下單腳本：

（1）用戶登錄系統，瀏覽商品列表。

（2）用戶選擇商品，添加到購物車。

（3）用戶確認訂單信息，提交訂單。

（4）系統驗證庫存，若庫存不足，提示用戶；否則生成訂單。

（5）用戶選擇支付方式，完成支付。

（6）系統更新訂單狀態為“已支付”，并發送確認郵件。

（二）設想用戶界面

設計系統的交互界面，確定用戶操作方式（如按鈕、菜單）和反饋機制（如提示信息）。例如，訂單提交后顯示“訂單已提交，預計 24 小時內發貨”。

（三）畫事件跟蹤圖

以豎線表示對象，箭頭表示事件，展示對象間的交互順序。例如，用戶下單的事件跟蹤圖如下：

用戶 → 購物車：添加商品 ?

購物車 → 商品：查詢庫存 ?

商品 → 購物車：返回庫存信息 ?

用戶 → 系統：提交訂單 ?

系統 → 訂單：生成訂單 ?

系統 → 支付接口：發起支付 ?

支付接口 → 系統：返回支付結果 ?

系統 → 用戶：發送確認郵件 ?

以下是一個示例：

（四）畫狀態圖

為關鍵類繪制狀態圖，描述其狀態轉換。例如，“訂單”類的狀態圖：

初始狀態 → 已提交 ?

已提交 → 已支付 [用戶支付] ?

已支付 → 已發貨 [管理員發貨] ?

已發貨 → 已完成 [用戶確認收貨] ?

已提交 → 已取消 [用戶取消訂單] ?

以上是一個示例：

（五）審查動態模型

檢查狀態圖和事件跟蹤圖的一致性，確保事件觸發的狀態轉換符合邏輯。例如，“已取消”狀態不能直接轉換為“已支付”，需通過“重新提交訂單”事件觸發。

五、建立功能模型

（一）畫出基本系統模型圖

用數據流圖（DFD）描述系統與外部實體的交互。例如，在線購物系統的基本模型圖：

外部實體：用戶、管理員、支付平臺 ?

處理：訂單處理 ?

數據流：商品信息、訂單請求、支付結果 ?

數據存儲：商品庫、訂單庫 ?

（二）畫出功能及數據流圖

逐層分解基本模型，細化處理邏輯。例如，“訂單處理”可分解為“驗證庫存”“計算總價”“生成發票”等子處理，并用數據流連接各處理框。

0層數據流圖：

用戶 → 驗證庫存：商品ID、數量 ?

驗證庫存 → 商品庫：查詢庫存 ?

商品庫 → 驗證庫存：庫存信息 ?

驗證庫存 → 計算總價：商品價格、數量 ?

計算總價 → 生成發票：訂單金額 ?

生成發票 → 訂單庫：保存訂單 ?

以下是數據流圖的一個示例：

（三）描述處理框功能

用結構化語言或判定表詳細說明每個處理框的邏輯。例如，“驗證庫存”處理框的邏輯：

IF 庫存 ≥ 訂單數量 THEN ?

????返回“庫存充足”?

ELSE ?

????返回“庫存不足”?

ENDIF ?

六、定義服務

（一）常規行為

為類定義通用操作，如“用戶”類的“登錄”“注冊”，“訂單”類的“提交”“取消”。這些操作直接對應動態模型中的事件和狀態轉換。

（二）從事件導出的操作

根據事件跟蹤圖中的交互，確定對象需提供的方法。例如，“用戶添加商品到購物車”事件對應“購物車”類的“添加商品”方法。

（三）與數據流圖對應

將數據流圖中的處理框映射為對象的操作。例如，“計算總價”處理框對應“訂單”類的“計算總價”方法，該方法調用“商品”類的“獲取價格”方法。

（四）利用繼承減少冗余

通過繼承機制復用父類服務。例如，“管理員”類繼承“用戶”類的“登錄”方法，并添加“修改商品信息”等特有方法。

java代碼示例：

// 父類：用戶 ?public class User { ?private String name; ?private String email; ?public void login(String username, String password) { ?// 登錄邏輯 ?} ?} ?// 子類：管理員 ?public class Admin extends User { ?public void updateProduct(Product product) { ?// 修改商品信息邏輯 ?} ?}