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