面向物件設計 - OOAD

在分析階段之後，概念模型將使用面向物件設計 (OOD) 進一步發展成為面向物件模型。在 OOD 中，分析模型中與技術無關的概念被對映到實現類，識別約束並設計介面，從而產生解決方案域的模型。簡而言之，構建了一個詳細的說明，指定了系統如何基於具體的技術進行構建。

面向物件設計的階段可以識別為：

定義系統的上下文
設計系統架構
識別系統中的物件
構建設計模型
指定物件介面

系統設計

面向物件系統設計包括定義系統的上下文，然後設計系統的架構。

上下文 - 系統的上下文具有靜態部分和動態部分。系統的靜態上下文使用整個系統的簡單框圖設計，該框圖擴充套件為子系統的層次結構。子系統模型由UML包表示。動態上下文描述系統如何與其環境互動。它使用用例圖建模。
系統架構 - 系統架構是根據系統的上下文，根據架構設計原則以及領域知識設計的。通常，系統被劃分為多個層，每一層都被分解成子系統。

面向物件分解

分解意味著根據分治原則，將大型複雜系統分解成具有較低複雜性的較小元件的層次結構。系統的每個主要元件稱為子系統。面向物件分解識別系統中獨立的自主物件以及這些物件之間的通訊。

分解的優點是：

各個元件的複雜性較低，因此更易於理解和管理。
它能夠劃分擁有專業技能的勞動力。
它允許替換或修改子系統而不會影響其他子系統。

識別併發性

併發允許多個物件同時接收事件，並且多個活動可以同時執行。併發在動態模型中被識別和表示。

為了啟用併發，每個併發元素都被分配一個單獨的控制執行緒。如果併發在物件級別，則兩個併發物件被分配兩個不同的控制執行緒。如果單個物件的兩個操作本質上是併發的，則該物件將在不同的執行緒之間拆分。

併發與資料完整性、死鎖和飢餓問題相關。因此，每當需要併發時，都需要制定明確的策略。此外，併發需要在設計階段本身識別，而不能留到實現階段。

識別模式

在設計應用程式時，一些普遍接受的解決方案被用於某些類別的問題。這些是設計模式。模式可以定義為一組記錄在案的構建塊，可用於某些型別的應用程式開發問題。

一些常用的設計模式包括：

外觀模式
模型檢視分離模式
觀察者模式
模型檢視控制器模式
釋出訂閱模式
代理模式

控制事件

在系統設計過程中，需要識別可能在系統物件中發生的事件並進行適當處理。

事件是對在時間和空間上具有位置的重要事件的規範。

可以建模四種類型的事件，即：

訊號事件 - 一個命名物件由一個物件丟擲，並被另一個物件捕獲。
呼叫事件 - 表示操作排程的同步事件。
時間事件 - 表示時間流逝的事件。
更改事件 - 表示狀態更改的事件。

處理邊界條件

系統設計階段需要解決整個系統以及每個子系統的初始化和終止。記錄的不同方面如下：

系統的啟動，即系統從非初始化狀態到穩定狀態的轉換。
系統的終止，即關閉所有正在執行的執行緒，清理資源以及要傳送的訊息。
系統的初始配置以及在需要時重新配置系統。
預見系統的故障或意外終止。

邊界條件使用邊界用例建模。

物件設計

在開發了子系統的層次結構之後，將識別系統中的物件並設計其細節。在這裡，設計者詳細說明了在系統設計期間選擇的策略。重點從應用程式域概念轉向計算機概念。分析期間識別的物件被刻畫出來以進行實現，目標是最小化執行時間、記憶體消耗和總體成本。

物件設計包括以下階段：

物件識別
物件表示，即設計模型的構建
操作分類
演算法設計
關係設計
外部互動的控制實現
將包類和關聯打包到模組中

物件識別

物件設計的第一個步驟是物件識別。面向物件分析階段中識別出的物件被分組到類中並被細化，以便它們適合實際實現。

此階段的功能包括：

識別和細化每個子系統或包中的類
定義類之間的連結和關聯
設計類之間的層次關聯，即泛化/特化和繼承
設計聚合

物件表示

一旦識別出類，就需要使用物件建模技術來表示它們。此階段主要涉及構建UML圖。

需要生成兩種型別的設計模型：

靜態模型 - 使用類圖和物件圖來描述系統的靜態結構。
動態模型 - 描述系統的動態結構並使用互動圖和狀態圖顯示類之間的互動。

操作分類

在此步驟中，透過組合在OOA階段開發的三個模型（即物件模型、動態模型和功能模型）來定義要對物件執行的操作。操作指定要做什麼，而不是如何做。

關於操作，將執行以下任務：

開發系統中每個物件的狀體轉換圖。
為物件接收的事件定義操作。
識別一個事件觸發相同物件或不同物件中其他事件的情況。
識別操作中的子操作。
將主要操作擴充套件到資料流圖。

演算法設計

使用演算法定義物件中的操作。演算法是一個逐步解決操作中規定的問題的過程。演算法側重於如何去做。

可能存在多個與給定操作對應的演算法。一旦識別出備選演算法，就為給定的問題域選擇最佳演算法。選擇最佳演算法的指標包括：

計算複雜度 - 複雜度根據計算時間和記憶體需求來確定演算法的效率。
靈活性 - 靈活性決定了所選演算法是否可以在各種環境中適當地實現，而不會損失適用性。
可理解性 - 這決定了所選演算法是否易於理解和實現。

關係設計

在物件設計階段需要制定實現關係的策略。需要解決的主要關係包括關聯、聚合和繼承。

關於關聯，設計者應執行以下操作：

確定關聯是單向還是雙向。
分析關聯的路徑，並在必要時更新它們。
在多對多關係的情況下，將關聯實現為一個不同的物件；或者在一對一或一對多關係的情況下，實現為對其他物件的連結。

關於繼承，設計者應執行以下操作：

調整類及其關聯。
識別抽象類。
制定規定，以便在需要時共享行為。

控制的實現

物件設計者可以改進狀態圖模型的策略。在系統設計中，制定了實現動態模型的基本策略。在物件設計期間，此策略得到了恰當的完善，以實現適當的實現。

實現動態模型的方法包括：

將狀態表示為程式中的位置 - 這是傳統的程式驅動方法，其中控制位置定義程式狀態。有限狀態機可以實現為程式。轉換形成輸入語句，主控制路徑形成指令序列，分支形成條件，後向路徑形成迴圈或迭代。
狀態機引擎 - 此方法透過狀態機引擎類直接表示狀態機。此類透過應用程式提供的轉換和操作集來執行狀態機。
併發任務作為控制 - 在這種方法中，物件在程式語言或作業系統中實現為任務。在這裡，事件被實現為任務間呼叫。它保留了真實物件的固有併發性。

包類

在任何大型專案中，將實現細緻地劃分成模組或包都非常重要。在物件設計過程中，類和物件被分組到包中，以便多個組能夠合作完成專案。

打包的不同方面包括：

隱藏內部資訊，防止外部檢視 − 這允許將一個類視為“黑盒”，並允許更改類實現而無需任何類的客戶端修改程式碼。
元素的一致性 − 如果一個元素（例如類、操作或模組）是根據一致的計劃組織的，並且其所有部分都內在相關，從而服務於共同的目標，則該元素具有一致性。
物理模組的構建 − 構建物理模組時，以下指南有所幫助：
- 模組中的類應該表示相同複合物件中的相似事物或元件。
- 緊密相關的類應該位於同一個模組中。
- 不相關或弱相關的類應該放在單獨的模組中。
- 模組應該具有良好的內聚性，即其元件之間具有高度的協作性。
- 模組應該與其他模組的耦合度低，即模組之間的互動或相互依賴性應該最小。

設計最佳化

分析模型捕獲關於系統的邏輯資訊，而設計模型新增細節以支援高效的資訊訪問。在實現設計之前，應該對其進行最佳化，以便使實現更有效率。最佳化的目標是最大限度地減少時間、空間和其他指標方面的成本。

然而，設計最佳化不應過度，因為易於實現、可維護性和可擴充套件性也是重要的考慮因素。人們經常看到，經過完美最佳化的設計效率更高，但可讀性和可重用性較差。因此，設計人員必須在這兩者之間取得平衡。

可以為設計最佳化執行的各種操作包括：

新增冗餘關聯
省略不可用的關聯
演算法最佳化
儲存派生屬性以避免重新計算複雜的表示式

新增冗餘關聯

在設計最佳化過程中，檢查是否可以推匯出新的關聯以降低訪問成本。儘管這些冗餘關聯可能不會新增任何資訊，但它們可能會提高整個模型的效率。

省略不可用的關聯

關聯過多可能會使系統難以理解，從而降低系統的整體效率。因此，在最佳化過程中，所有不可用的關聯都被刪除。

演算法最佳化

在面向物件的系統中，資料結構和演算法的最佳化以協作的方式進行。一旦類設計到位，就需要最佳化操作和演算法。

演算法最佳化可以透過以下方式獲得：

重新安排計算任務的順序
反轉迴圈的執行順序（與功能模型中規定的順序相反）
刪除演算法中的死路徑

派生屬性的儲存和儲存

派生屬性是指其值作為其他屬性（基屬性）的函式計算的屬性。每次需要時重新計算派生屬性的值是一個耗時的過程。為了避免這種情況，可以計算其值並以計算後的形式儲存。

但是，這可能會導致更新異常，即基屬性值發生變化而派生屬性值沒有相應變化。為了避免這種情況，採取以下步驟：

每次更新基屬性值時，也重新計算派生屬性。
定期批次重新計算和更新所有派生屬性，而不是每次更新後都進行。

設計文件

文件是任何軟體開發過程中必不可少的部分，它記錄了製作軟體的過程。對於任何非平凡的軟體系統，都需要記錄設計決策，以便將設計傳達給他人。

使用領域

雖然是次要產品，但良好的文件是必不可少的，尤其是在以下領域：

在由多位開發人員開發的軟體設計中
在迭代式軟體開發策略中
在開發軟體專案的後續版本中
用於評估軟體
用於查詢測試條件和領域
用於維護軟體。

內容

有益的文件應主要包括以下內容：

高階系統架構 − 流程圖和模組圖
關鍵抽象和機制 − 類圖和物件圖。
說明主要方面行為的場景 − 行為圖

特點

良好文件的特點包括：

簡潔明瞭，同時準確、一致和完整
可追溯到系統的需求規範
結構良好
圖示而非描述性

列印頁面