軟體架構設計—基於魯棒圖進行設計

如何藉助魯棒圖進行初步設計呢？

      ADMEMS方法歸納了魯棒圖建模的10條經驗要點,分別覆蓋文法，思維，技巧，注意事項等4個方面。

                                         

魯棒圖建模的10條經驗。

1.遵守建模規則。

    通過以下4條語句，可以理解該圖的本質：

         1.1 參與者只能與邊界對象交談。

         1.2 邊界對象只能與控制對象和參與者交談。

         1.3 實體物件也只能與控制對象交談。

         1.4 控制對象既能與邊界對象交談，也能與控制對象交談，但不能與參與者交談。

2.簡化建模文法

     2.1 ADMEMS方法推薦魯棒圖建模的文法。在實踐中，簡化的魯棒圖文法將有利於集中精力進行初步設計，而不是關注細節。

                                    

3.遵循3種元素的發現思路

        

 用例=N個情境。每個情境的實現都是一連串的職責進行協作的結果。所以，初步設計可以通過”研究用例執行的不同情境，發現情境背後應該有哪些不同的職責“

4.增量建模

     舉例說明：類似WinZip,WinRar這樣的壓縮公用程式大家都用過。為其中的”壓縮“功能進行基於魯棒圖的初步設計。

    首先，識別最明顯的職責。對，就是你自己認為最明顯的那幾個職責--不要認為設計和建模有嚴格的標準答案。如果 ，你認為壓縮就是把原檔案變成壓縮包的處理過程，於是識別出了3個職責：

  

接下來，開始考慮職責間的關係，並發現新職責。壓縮器讀取原檔案，最終產生壓縮包---這裡可以將打包器獨立出來，它是受了壓縮器的委託而工作的。

繼續同樣的思維方式。的魯棒圖中間成果，又引入了壓縮配置，它影響著壓縮器的工作方式，例如加密壓縮，分卷壓縮或者其他。

最終的魯棒圖如8-13所示。壓縮功能還要支援顯示壓縮排度，以及隨時取消進行了一半的壓縮工作。所以你又識別出了壓縮行進介面和監聽器等職責。

5.只對關鍵功能（用例）畫魯棒圖

    基於”關鍵需求決定架構“的理念，功能需求作為需求的一種類型，在設計架構時不必針對每個功能都畫出魯棒圖。

6.每個魯棒圖有2-5個控制對象

     既然是 初步設計，魯棒圖建模時，針對關鍵功能的每個魯棒圖中得控制對象不必太多太細，5個是常見的上限值。相反，若實現某功能的魯棒圖中只含一個控制對象，則是明顯地”設計不足“--這個控制對象的名字必然和功能的名字相同，這意味著沒有對職責進行真正的切分。例如，WInZip的壓縮功能設計成8-14所示的魯棒圖，幾乎沒有任何意義。

7.勿關注細節：

     初步設計不應該關注細節。例如，

     1.對每個對象只標識對象名，都未識別其屬性和方法。

      2.”活期賬戶銷戶介面“，具體可能是對話方塊，WEB介面，字元終端介面,但魯棒圖中沒有關心這些細節問題。

      3.”客戶資料“ 等實體物件須要持久化嗎？不關心，更不關心用Table還是用File或其他方式持久化。

      4.沒有標識控制流程的嚴格順序。

8.勿過分關注UI，除非輔助或驗證UI設計。

    過分關心UI，會陷入諸如有幾個視窗，是不是有一個專門的結果顯示頁面等諸多細節之中，初步設計就沒法做了。

   別忘記了，初步設計的目標是發現職責。初步設計無須展開架構設計細節，否則就背上了”包袱“，這是複雜系統架構設計起步時的大忌。