軟件架構設計---基於魯棒圖進行設計

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

      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，會陷入諸若有幾個窗口，是否是有一個專門的結果顯示頁面等諸多細節之中，初步設計就無法作了。

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