- 未確認客戶了解這是系統建構釋出前可以變更系統行為的最後機會
- 未確認使用案例描述與 robustness diagram 是否吻合
- 未確認新的 entity object 被加入 domain model
- 在 domain class 中未尋找其屬性
- 在 PDR 階段就預期將 operation 分派給 class
- 未再提醒客戶使用案例描述就是客戶與開發的技術人員的合約
- 要求以 robustness analysis 做為 design pattern 的延伸使用(表現出 design pattern)
- 未審視 noun/verb 物件間的連接規則
- 期待 robustness diagram 表現出詳細設計而非概念層設計
- 不用快速追蹤證實所有行為都被設計,而去仔細檢查每根箭頭的方向正確與否
Sequence Diagrams
在 interaction modeling 階段,需達成三個目標
- 在三種 objects 間分派行為,在 robustness analysis 時期,辨別或推測出一組 class 可能完成使用案例中期待的行為,而且將這些行為拆解成分離的單位,再針對每一個單位的行為設計出 controller,然後決定哪個 object 該負責某項行為。若無法確定三種 objects 間的關係,就表示還沒到達進入此階段的時機。
- 顯示你所有的使用案例中相關物件間詳細的交互影響。運行期物件間的交互影響是藉由彼此間的訊息傳遞為之。訊息促使期待之動作發生,而必須針對使用案例中每個單位的行為確認所需的訊息或方法。
- 結束了物件間 operations 的分配後,應置重心於定義 static model 的屬性上。我們主張在 domain model 階段及 robustness analysis 階段以極抽象的方法定義 operations,甚至在初期設計階段 (preliminary design) 由於資訊不足,因此不應指派 method。本階段應有完整資訊以完成在 sequence diagrams 上 objects 行為的詳細設計。安排使用案例中 attributes 及 operations 所屬的物件也應於本階段完成。當進行動態塑模時,必須更新及擴充靜態模型,此舉會使你在瞭解如何運行系統的認知更加確定。
The Top 10 Sequence Diagramming Errors
- 未對每個使用案例作出 sequence diagram
- 未將使用案例情節描述置於 sequence diagram
- 未先在 robustness diagram 上確認必要的 object
- 未顯示出案例文件及訊息箭頭間之蹤跡
- 未顯示 sequence diagram 的線路,反而代之以高階抽象概念
- sequence diagram 中原本應該分派給各 objects 的行為卻改為流程圖
- 忽略運算或邏輯相關的 method,反而將注意力放在屬性相關的 getter、setter method
- 未對 sequence diagram 中 objects 間的訊息發生時機仔細設計
- 當以繪製訊息箭號配置行為時,未遵循責任導向的物件設計原則
- 當建構使用案例中每個 package 中的 local class diagram 時未同步更新靜態模型