活動: 設計元件
本活動修正系統的設計。
延伸: 設計元件
說明工作分解結構團隊配置工作成果用法
關係
說明

本活動有下列目標:

  • 訂定設計元素如何實現必要行為的「細節」,以修正設計元素的定義。
  • 根據發現的新的設計元素來修正和更新使用案例實現化(亦即,持續地更新使用案例實現化)
  • 審查設計
內容
事件驅動
多次出現的項目
持續進行中
選用
規劃
可重複的
人員配置

通常有一個人或一個小組會負責一組設計元素,且通常是一或多個包含其他設計元素的套件或子系統。此人/小組負責對套件或子系統包含的元素來擴充設計明細:完成所有操作定義和對於其他設計元素的關係定義。作業:封裝體設計強調以封裝體和(被動或資料)類別來遞迴分解系統的功能。作業:類別設計強調修正被動類別設計元素的設計,作業:子系統設計強調如何將對映至子系統本身的行為,分配至內含的設計元素(內含的封裝體和類別或子系統)。子系統通常做為粗略的模型組織結構,而封裝體則用於通常放在被動資訊儲存庫中的大多數工作和「普通」類別。 

負責設計封裝體的人或團隊必須瞭解實作語言,且在一般的並行性問題上也須具備專業知識。負責設計被動類別的人也應該瞭解實作語言,以及類別要採用的演算法或技術。負責子系統的人或團隊應該通曉各種知識、有能力決定如何適當分割設計元素的功能,以及能夠瞭解不同設計方案原本的 權衡。

修正個別的設計元素時,也必須修正使用案例實現化,以反映設計元素的延伸責任。通常由一個人或一個小組來負責修正一或多個相關的使用案例實現化。在增加或修正設計元素時,或改進設計模型可以簡化使用案例實現化時,必須重新考量並持續發展使用案例實現化,避免不切合實際需求。負責使用案例實現化的人或團隊必須完整瞭解使用案例所需的行為,以及採取不同方式將此行為分配給各設計元素的優缺點。此外,因為要負責選取執行使用案例的元素,所以也必須非常瞭解設計元素本身的外部(公開)行為。

用法
用法指引

這裡的工作通常由個人或小組來進行,且在各團隊需要溝通的變更問題上,團隊之間會進行非正式的互動。 在修正設計元素時,團隊的責任通常會互換,需要同時變更許多設計元素和使用案例實現化。 由於責任的交錯關係,設計團隊成員幾乎不可能閉門造車。 為了讓設計工作持續專注在系統的必要行為上(在使用案例實現化中表達),有一套常見的互動模式:

  • 負責人或團隊修正設計元素
  • 一小組人(大概 2-5 人)非正式地合作,解決新的設計元素在一部分現有的使用案例實現化上產生的衝擊
  • 指出在使用案例實現化和參與的設計元素上的變更
  • 重複整個過程,直到設計出反覆的所有必要行為

因為流程本身是反覆式,「反覆的所有必要行為」以在生命週期中的位置為準則。

  • 在詳述階段專注於重大架構面的行為上。忽略其他所有「細節」。
  • 在建構階段,焦點移轉至設計的完整性和一致性,因此在建構階段結束時,不會留下未解決的設計問題。

請注意,在實作和測試活動開始之前,反覆的設計並不需要達到完整的地步。 隨著設計演進而局部實作和測試設計,就算是在一個反覆內,也相當有利於驗證和修正設計。