作業: 封裝體設計
這項作業說明封裝體設計的性質。
目的
  • 詳述和修正封裝體的說明。
關係
角色主要: 其他的: 協助:
輸入強制: 選用: 外部:
輸出
主要說明

封裝體用來定義系統中並行執行的執行緒。封裝體的巢狀深度不限,也可能具有對設計(被動式)類別的關聯。 每一個封裝體執行一次這項活動,包括在這項作業的範圍內發現的新封裝體。

 UML 2.0 表示法

請注意,目前的封裝體 RUP 表示法是以 UML 1.5 表示法為基礎。在 UML 2.0 中,多半可用概念:結構化類別來表示。

如需相關資訊,請參閱 UML 1.x 和 UML 2.0 的差異

步驟
建立埠並連結至通訊協定

考量封裝體的責任,建立一組初步的埠類別。這些埠類別代表封裝體的「介面」。 埠類別代表工作成果:通訊協定的實現,此實現又代表與封裝體通訊用的一組輸入輸出信號。

在建立埠時,請考量核對清單:核對清單,判斷「通訊協定」是否適當。 埠應該反映一組相關責任;範圍相似的通訊協定有利於許多封裝體之間重複使用。 選取適當的通訊協定之後,請將埠連結至適當的通訊協定。

驗證封裝體互動

當埠連結至通訊協定之後,必須評估和驗證封裝體的外部行為。請利用手動的演練技巧或自動化模擬工具,模擬會引起封裝體行為的事件來測試封裝體的行為。 驗證也會考量與正在設計的封裝體進行互動的封裝體。 請利用自動化工具,在封裝體內撰寫可進行埠測試的 Stub 程式碼。 在通訊協定或埠定義中或封裝體責任中偵測到錯誤時,請適當地變更封裝體、埠及通訊協定定義。

定義封裝體狀態機

驗證封裝體的埠和通訊協定之後,請定義封裝體的內部行為。 封裝體的行為是以狀態圖來定義。 參考資訊:準則:狀態圖。如需其他一般的封裝體資訊,請參閱準則:封裝體核對清單:封裝體

定義狀態

首先,指出封裝體可存在的狀態。狀態必須是唯一的(一個封裝體不能同時在兩種狀態下)且明確陳述。 如需相關資訊,請參閱適當的準則和核對點。

定義狀態轉換

定義狀態之後,請考量狀態之間的轉換。轉換程式碼應該像高階的應用程式虛擬碼一樣, 主要應該包含即時的作業系統服務呼叫,例如訊框服務、時間服務、埠操作、封裝體操作及被動式類別操作。

在「封裝體」轉換中加入詳細的程式碼時:

  • 如果程式碼在其他轉換中有用,請考慮委派給「封裝體」操作。
  • 考量程式碼實作的功能是否符合「封裝體」的責任。

在定義「封裝體」操作時:

  • 考量函數在「封裝體」的任何轉換中是否隨時都有用,以及任何完成的工作是否適用於系統的其他地方。 如果認真考量,請委派給被動式類別函數。
  • 如果程式碼太過於針對特定的應用程式而設計,難以儲存在特定的「資料」類別中,請考慮另外建立一個「資料」類別做為此程式碼的抽象概念。
  • 如果程式碼處理資料結構操作(例如,維護清單),或執行複雜的(超過 1 行)計算,則應該放入資料類別中。
定義需求或被動式類別

根據封裝體狀態機,檢查封裝體參照的被動式類別。如果這些類別上出現新的需求,則必須產生變更要求以達到所需的變更。 如果已找出新的類別,則應該一起產生這些類別上的需求(尤其是必要的操作),並建立類別。作業:類別設計中將進一步描述這些類別。

介紹封裝體繼承

封裝體繼承用於實作一般化-特殊化、利用多型性及重複使用實作。 這裡的關鍵字是「實作」- 這是一種技術,主要是重複使用封裝體的內部結構,不是封裝體的外部行為。

繼承經常濫用在原本以更簡單的設計技術即可輕易完成的事。

在一般化-特殊化中使用繼承

繼承有三種。按照複雜性由低(最理想)至高(最不理想)排列如下:

  • 介面繼承 - 只繼承埠和通訊協定,這是最理想的繼承類型
  • 結構繼承 - 繼承介面加上結構化包含階層(適用於架構)
  • 行為繼承 - 除了介面和結構繼承,也重複使用行為式程式碼和狀態機

結構繼承和行為繼承會引起一些問題:

  • 繼承具有的高度耦合性,導致超類別的變更會擴散到子類別。
  • 在子類別中需要刪除超類別的行為和結構,意謂著繼承使用不當(通常指策略上的程式碼重複使用性)。 重新建構類別和封裝體及適當使用委任是較適當的對策。
  • 繼承意謂著在類別階層中將設計決策上移,導致不理想的設計和編譯相依性。 

其他問題包括:

  • 決策不一定適用於所有處理狀況。
  • 事實上,引進繼承會造成重複使用更困難,因為設計元素更緊密糾纏在一起。
  • 設計變得更脆弱,因為任何導致決策無效的新需求會引發重大的問題。
  • 設計必須非常靈活才有效果,但這通常很困難。這也是設計可重複使用的架構不簡單的原因!

所有包含結構/行為的設計有預設的決策和假設(明確或隱含)。但重要的問題是:您非常肯定該決策/假設一定都有效嗎? 如果不是,應該如何移除或變更?

驗證封裝體行為

最後,必須評估和驗證封裝體的行為。請利用手動的演練技巧或自動化模擬工具,模擬會引起封裝體行為的事件來測試封裝體的行為。 此外,也要驗證封裝體的內部結構,不只是外部行為,也要驗證此行為的內部實作。 利用自動化工具時,可能需要撰寫 Stub 程式碼,模擬實作被動式資料類別及與封裝體互動的外部封裝體。 偵測到的缺失應該做成文件,並適當地變更封裝體定義。

內容
多次出現的項目
事件驅動
持續進行中
選用
規劃
可重複的
詳細資訊