如何在類圖中標註設計模式(一)

來源:互聯網
上載者:User

       隨著設計模式的廣泛使用,如何在結構圖(主要是UML類圖)中標註設計模式成為大家討論的一個熱點話題。設計模式是軟體設計中的一些微結構,通過一種合理的方法來標註設計模式既有助於開發人員更好地進行設計軟體系統,也有利於理解一些遺留系統,具體來說,設計模式的標註具有以下意義:
      (1) 在系統設計和實現階段,如果能夠通過一種簡單易懂的方式來標註相應的模式角色,將有助於開發人員開發和設計軟體時記錄所採用的解決方案,便於及時修改和完善設計方案,也有助於更好地理解和修改原始碼;
      (2) 在系統維護階段,由於軟體文檔的缺失或核心開發人員的離職等原因將導致遺留系統的代碼閱讀和維護任務非常艱巨,一個複雜的系統往往包含成百上千個檔案,這些檔案之間的關係錯綜複雜,很難在較短的時間內理解它們之間的關係,明確設計人員的設計思想和意圖,如果能夠在設計文檔和原始碼中對軟體中所使用設計模式進行標註,無疑會大大簡化對系統的理解難度。

      UML只能以可視化的方式描述系統的組成元素以及它們之間的關係,並不能揭示其中蘊含的設計模式相關資訊。1所示的某圖表顯示系統設計結構圖,在該結構圖中使用了兩個設計模式,分別是橋接模式(Bridge Pattern)適配器模式(Adapter Pattern),其中抽象圖表類Chart充當橋接模式中的抽象類別(Abstraction)角色,餅狀圖類PieChart和柱狀圖類BarChart充當擴充抽象類別(RefinedAbstraction)角色,資料讀取介面DataReader充當實作類別介面(Implementor)角色,資料庫讀取類DBReader和Excel讀取類ExcelReader充當具體實作類別(ConcreteImplementor)角色;同時,由於ExcelReader重用了現有類ExcelAPI,因此在設計方案中又使用了適配器模式,DataReader充當適配器模式中的目標抽象類別(Target)角色,ExcelReader充當適配器(Adapter)角色,ExcelAPI充當被適配的適配者(Adaptee)角色。如果沒有相應的文字說明和豐富的設計模式使用經驗,從圖1中要準確而又快速地識別出其中使用的模式和每一個模式角色的難度較大。因此,對於系統的設計人員、實現人員和維護人員而言,如何在軟體設計方案中標註設計模式意義重大

      近年來,陸續誕生了一些設計模式標註方法,各具特色,也都存在一些問題和不足,下面我對這些標註方法做一個簡單的介紹:

      1. 維恩圖風格模式標註  

      維恩圖風格模式標註(Venn Diagram-Style Pattern Annotation)是最早的設計模式標註方法之一,它由設計模式先驅John Vlissides提出,其表示方式2所示。在圖2中,通過實線框和不同的陰影顏色來區分不同的設計模式,這種標註方式簡單易懂,但存在很多問題,例如當一個類在多個設計模式中都扮演相應的角色時,將導致實線框的多次重疊,影響結構圖的可讀性;此外使用不同的陰影顏色來代表不同的模式也將導致顏色的多層重疊和文檔列印的不便;這種方式還有一個缺點是只能標註使用了哪些設計模式,而不能對其中的模式元素進行標註,不能標註類模式角色、方法、屬性等重要訊息。

    個人觀點:該方法簡單,但是模式太多就會很亂!

     

      2. 虛線邊界模式標註

      虛線邊界模式標註(Dotted Bounding Pattern Annotation)方法由德克薩斯大學達拉斯分校的Jing Dong等提出,3所示。這種方法通過虛線框來解決維恩圖風格模式標註方法中存在的陰影重疊問題,但是對於標註資訊太過簡單、模式重疊地區線段較多等問題仍然無法解決。

     個人觀點:該方法也比較簡單,但模式太多還是會很亂!

      

      3. UML協作標註

      UML協作標註(UML Collaboration Notation)方法最早由UML創始人Grady Booch等提出,最開始是用於對通用UML圖形中的一些元素進行描述,John Vlissides將其引入設計模式標註,在這種標註方式中,將所使用的設計模式名稱放在虛線橢圓符中,再通過虛線指向具體的模型元素,在虛線上註明該模型元素對應的模式角色名稱,4所示。但是在這種標註方式中,大量虛線的使用將讓整個結構圖變得非常淩亂,同時由於模式資訊和類結構資訊混合在一起,導致這兩類資訊都難以理解和識別,此外,這種方法雖然可以標註每一個類所扮演的模式角色資訊,但是不能標註屬性、方法等模式資訊。

    個人觀點:模式不多時還不錯,清晰明了,但模式較多時會很亂,線太多了!

       

      4.  “模式:角色”標註

     “模式:角色”標註(Pattern : Role Annotations)方法由設計模式先驅Eric Gamma等提出,該方法通過陰影框來標註模式名稱和模式角色名稱,為了節省篇幅,如果某個元素只在一個模式中充當某個角色,則可省略模式名,直接用“模式角色名稱”的方式來標註角色,5所示。這種模式標註方式直觀易懂,但是在複雜結構中,“模式:角色”標註方法將會導致結構圖變得非常複雜,每一個與模式相關的類都需要對應增加一個陰影框,導致結構圖中充斥太多圖形元素,N個類可能需要2N個陰影框,而且陰影框的位置也很重要,不合適的位置將導致結構圖非常擁擠;此外,該方法也沒有考慮到方法和屬性等細節資訊的標註;同時,如果某一個類在同一模式的多個執行個體中都扮演了某個角色,該方法不能明確標識出不同模式執行個體中的不同角色。

個人觀點:元素太多,布局太麻煩,如果類圖太複雜該方法不合適,在Joshua Kerievsky的《重構與模式》一書中,很多圖就是用這種方式來標註的(註:圖都不是很複雜)!

小結:以上幾個標註圖(初始類圖用PowerDesigner繪製)都是我用Visio一個個畫的,很費時間,如果結構圖較為複雜,我個人覺得這些標註方式都不太好!下一篇文章將介紹一些更好的標註方式,敬請關注!

【作者:劉偉  http://blog.csdn.net/lovelion】

聯繫我們

該頁面正文內容均來源於網絡整理,並不代表阿里雲官方的觀點,該頁面所提到的產品和服務也與阿里云無關,如果該頁面內容對您造成了困擾,歡迎寫郵件給我們,收到郵件我們將在5個工作日內處理。

如果您發現本社區中有涉嫌抄襲的內容,歡迎發送郵件至: info-contact@alibabacloud.com 進行舉報並提供相關證據,工作人員會在 5 個工作天內聯絡您,一經查實,本站將立刻刪除涉嫌侵權內容。

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.