什麼是Robustness Diagram
Ivar Jacobson於1992年所提出，台灣這邊翻成強韌圖、穩健圖，對岸則採譯音翻成魯棒圖。在需求分析領域，UML的Use Case Diagram已經被視為需求捕獲的重要工具，藉由Use Case及Use Case敘述文件，可以很清楚的將需求分解展開，但接下來該如何將Use Case的需求描述轉化成設計架構呢? 以中小型的軟體系統來說，通常使用Use Case Diagram+ Class Diagram+ Sequence Diagram就能進行分析設計，而Use Case Diagram是站在使用者的角度來看系統全貌，Class Diagram及Sequence Diagram則分別代表了系統靜態結構及動態的交互關係，過去我使用這3個圖型進行開發就大致滿足所需了，也許會再依實際情況使用其他UML圖形，但隨著經驗累積及學習，漸漸感覺從分析跨越到設計之間存在著一道檻，領域模型的提煉，我們可以採用四色原型分析法或交易樣式，但系統架構的設計，要考慮到更多方方面面，Robustness Analysis Diagram正好可以幫助我們設計出一個基於需求且能繼續進行細部設計的初始架構。
Robustness Diagram的基本元素及關係介紹
如上圖，主要的圖形就只有3種，Boundary(邊界)、Control(控制)及Entity(實體)，這3個圖形分別代表了不同的職責。
Boundary : 邊界物件，Use Case的主要元素之一就是Actor(參與者)，Boundary的職責就是與Actor互動，它代表著一種外部元素與系統互動的關係。
Control : 控制物件，代表系統的動態行為，描述Use Case中系統應具有的規則與處理邏輯。
Entity : 實體物件，泛指系統會存取的資料，基本上是可以對應到領域物件。
這3個元素之間有著基本的限制關係 :
Boundary及Entity必須透過Control交談，Entity與Entity或Boundary與Boundary之間也必須透過Control。而Actor則只能與Bounday進行互動。
實作範例
接下來用一個簡單的例子來說明如何繪製Robustness Diagram，假設今天開發一套汽車檢驗記錄系統，經過需求訪談及分析後，獲得如下圖的Use Case Diagram。
接下來以驗車的Use Case為例，藉由三個元素的特性找出對應的職責，初步繪製出如下的Robustness Diagram
我們進一步思考，驗車會去讀寫客戶車籍資料，並且要寫入驗車歷史記錄，因此驗車還包含了查詢及驗證輸入的職責，基於OOD的SRP(單一職責原則)，可以再拆分出2個Control物件(如下圖)。
繼續思考每一個元素所代表的職責之間的關係，初步的將系統拆分為幾個部份後，最終獲得如下的設計圖
初步的架構設計便完成了，順利的銜接Use Case之後的設計，我們已藉由Robustness Diagram識別出系統在驗車這個Use Case的各種職責，這對後續的細部設計非常重要，不論是要繪製Class Diagram、Activity Diagram，或是Sequence Diagram，都比較容易進行，但這不是設計的終點，只是起點而已。
