影響架構質量的是構建體系架構的思想、原則、實踐與架構師的經驗，絕不是工具。即使是最優秀的架構工具，也不可能像倚天寶劍一般——倚天一出，誰與爭鋒——似乎誰握住了這把利刃，就能夠成為武林盟主。架構工具可以改善架構師的工作，卻不能替換架構的過程。軟件開發過程中，最重要的依舊是人。

　　我在嘗鮮Visual Studio 2010架構工具 時，偶然看到一篇文章，用夸張的語言吹捧VS 2010架構工具，認為它是架構師最怕程序員知道的新工具。這讓我有感而發，我想起數十年前甚囂塵上的一個理論，那就是CASE工具在未來可以取代編碼工作的論斷。隨著DSL的逐漸流行，這個論斷似乎有了能夠實現的希望。我們已經看到了很多優秀的代碼生成工具，通過建模，可以花很少的時間完成編碼實現。然而，現實是CASE工具至今仍然無法完全取代編碼工作；而若要完全取代架構與設計的工作，則近乎不可能，因為工具不可能取代人類的思想與經驗。我們可以不斷地豐富最佳實踐，在知識庫中總結出架構的模式，利用工具來展現這些規律與原則 。這意味著我們可以從變化中尋找到不變，利用共性分析提高復用的可能（包括架構的復用），但變化始終存在，針對的問題域會因項目而異，即使是抽象，它也不可能無所不包，代表一切具體的實現。

　　“工欲善其事，必先利其器”。誠然，工具對我們的幫助不可低估，否則，就是拒絕革新的保守思想；然而，盲目夸大工具的效力，忽視人的作用，帶來的負面影響并不亞于故步自封對前進過程的阻撓。用正確的態度對待工具，工具才能為我所用，這是我一貫堅持的態度。敏捷宣言認為：個體與交付重于過程和工具。客戶滿意才是硬道理，架構與設計所使用的工具，與客戶滿意度沒有任何關系。所以，我們評價工具，是要看它能否提高我們的工作效率，改善我們的工作質量。那么，VS 2010架構工具能夠做到這一點嗎？

　　我們需要先思考一下，作為架構師，最希望看到的架構工具是什么？我認為，理想的工具應該具備如下特點：
　　1、易用性：可以非常容易和快速地構建與設計模型；
　　2、可驗證性：構建的模型是可以驗證的；
　　3、標準化：利于設計人員和開發人員的溝通；
　　4、工程化：支持正向工程與逆向工程；
　　5、可文檔化：能夠較好的支持文檔化；
　　6、可度量性：有助于對架構模型進行分析與度量；
　　7、模板化：支持通用的架構標準與原則，便于快速生成模型；
　　8、方法學支持：支持通用的軟件方法學（尤其是架構方法學）；
　　9、可集成性：能夠結合在軟件開發生命周期過程中；

　　首先來看易用性。構建軟件系統的架構，一部分工作是與圖形在作戰。無論是物理架構還是邏輯架構，用圖形表達整個系統錯綜復雜的關系，最為直觀。我希望在繪制與架構相關的模型圖時，并不會因為繪圖的不便對我的設計思路產生影響與阻撓，不會因為工具的無法表達或難以表達而影響我的工作質量，更不會因為構建出來的架構模型圖被設計人員與開發人員所誤解。這意味著模型圖的繪制要盡可能簡單與快捷，圖形的表達能力盡可能豐富，同時還要符合通用的標準，不會因為一套全新的標記而產生溝通上的分歧。以對UML的支持為例，我們在構建架構的過程中，常用的UML模型涉及到包圖、組件圖、部署圖、活動圖以及用例圖。VS 2010克服了之前版本對UML支持不夠的弱點，充實了UML建模的能力，提供了包括組件圖、類圖、活動圖、時序圖、用例圖五種UML模型。例如，我們可以繪制如下的組件圖：

圖1：組件圖示例

　　又或對時序圖的支持：

 圖2：時序圖示例

　　整體來看，它對UML模型的支持差強人意，雖然可以繪制出異常漂亮的UML圖，但操作并不方便，無法提高建模的效率。例如：在組件圖中無法輕易地繪制接口對組件的實現，對提供的接口與要求的接口之間的對應關系也較復雜；在時序圖中，Actor的圖形既不符合UML通用標識，使用也不方便——它沒有將Actor作為一級公民，而是作為Lifeline的一項屬性提供。

　　作為架構師，如果希望完成UML建模，我不會選擇VS 2010，因為它沒有提供包圖 和部署圖，不過它所提供的層模型卻值得嘗試。如果我們需要對大型生態系統的建模，或者繪制網絡拓撲圖，VS 2010更加難以勝任。從這一點來看，VS 2010若想成為架構師的首選，還有很長的路要走。

　　根據我對VS 2010的分析，我認為，微軟的野心并沒有這么大，它并沒有期待VS 2010提供的架構工具完全涵蓋架構與設計的各個領域。它的杰出表現，尤其對于UML建模而言，還是在于雙向工程（主要是逆向工程）的完美支持。

　　事實上，微軟對UML雙向工程的支持可以追溯到1997年與Rational合作開發的Visual Modeler。在Rational被IBM收購之后，這一工具就銷聲匿跡了。從VS 2005開始，提供了對逆向工程的支持，但這種支持非常有限，僅限于對類圖的支持。VS 2010完善了對UML主要模型的支持，因此雙向工程更具有普遍意義。VS 2010對正向工程的支持并不夠，它需要根據T4模板來創建，并充分利用了Visual Studio的擴展功能。我不明白微軟為何不直接在菜單項中提供對正向工程的支持，因為它本身可以非常完美地做到 。

　　VS 2010對逆向工程的支持極為強大，除了支持之前版本已經提供的類圖外，還支持生成依賴圖、時序圖以及層模型。依賴圖可以幫助我們了解程序的結構以及類之間的關系，時序圖則有助于理解對象之間協作的方式，至于層模型則在更高的層面上幫助我們了解分層架構。

　　VS 2010可以按照程序集、命名空間、類等建立依賴圖。以.NET提供的示例程序StockTrader為例，我希望了解服務層中相關類之間的依賴關系，就可以通過Architecture菜單的菜單項“Generate Dependency Graph”。我按照自定義的方式生成依賴圖，如圖3所示：

 圖3 根據自定義方式（公開的類）生成的依賴圖

 圖4：依賴圖的局部

　　我們可以看到Model對象被依賴的強度是最高的，其中ITradeSerivces接口幾乎依賴所有的模型對象，這是因為該接口是服務層的主要服務，相當于外觀服務，負責協調和操作訂單、報價、賬戶信息等模型對象的消息處理。

　　就我的感受來看，這樣的依賴圖顯得有些華而不實，因為這樣一張蜘蛛網般的圖形，實在讓人有些茫然，我們可能會在一張超級大型的依賴圖中迷路。不過，如果希望對依賴關系來一次鳥瞰，或者需要初步了解各個對象的依賴強度，該依賴圖還是有一定的參考價值。此外，倘若系統規模不夠大，則可以選擇類型級的依賴圖；如果系統規模太大，則可以根據程序集或命名空間生成依賴圖，這可以在一定程度減小依賴圖的復雜程度。

　　時序圖的逆向工程實在太精彩了。靜態的類圖雖然有助于我們了解類的結構，但類之間的協作卻根本無法跟蹤。我們在做設計的時候，常常會借助時序圖來幫助我們了解某個功能項的執行過程，追蹤它的消息傳遞方式，清晰把握類的協作方式，并以此為基礎尋找到類的行為，以及不存在于真實世界的類對象。在閱讀并理解代碼時，如果能夠有時序圖的幫助，會更容易理清設計的思路，明白設計的目的。例如，同樣在StockTrader項目下，我需要了解服務層中TradeService類的login()方法實現，就可以為其生成一個時序圖。在VS 2010中，生成時序圖只需要在方法上點擊右鍵，選擇“Generate Sequence Diagram…”項即可。圖5是為login()方法生成的時序圖，我們可以清晰地看到TradeService與ICustomer和ConfigUtility之間的交互情況。

圖5：為login()方法生成的時序圖

　　層模型對架構師的幫助更大。VS 2010可以根據現有的解決方案生成層模型。在打開現有解決方案后，添加一個新的Modeling Project，并創建一個Layer Diagram，然后將解決方案的相關程序集拖拽到Layer Diagram的設計器中。通過執行快捷菜單中的“Generate Dependencies”命令，可以檢查并獲得各個程序集之間的依賴關系，并以圖形方式展現出來，如圖6所示。圖6：為服務層生成的層模型

　　通過圖6，我們可以看到BusinessServiceImplementation依賴了StockTraderDALFactory、StockTraderIDAL、BusinessServiceDataContract以及BusinessServiceConfigurationSettings，同時它作為BusinessServiceContract服務契約的實現，還要依賴BusinessServiceContract。很明顯，BusinessServiceImplementation與具體的數據訪問層實現StockTraderDALSQLServer之間沒有任何依賴關系，這就意味著服務層與數據訪問層的具體實現是解耦的，這符合一般的架構原則。利用Layer Diagram，我們就可以很好地了解各個模塊之間的依賴關系，幫助我們分析架構的合理性，是否存在雙向依賴、循環依賴，或者模塊設計是否很好地遵循高內聚、松耦合原則。

　　VS 2010提供的“Validate Architecture”菜單項還可以對架構進行驗證。我們可以直接對上面生成的Layer Diagram執行驗證。但這樣的驗證并沒有價值，因為驗證的規則就是通過現有實現生成的。微軟推薦的做法是架構師根據對層與模塊的理解，繪制一份符合架構原則的Layer Diagram，然后將已經實現的程序集拖拽到相應層上，再執行驗證。如果實現違背了Layer Diagram要求的原則，就會提示錯誤 。這樣的驗證功能可以幫助架構師快速地驗證團隊的開發人員在實現過程中是否遵循了自己的設計。

　　從上述分析可以看出，VS 2010架構工具充分利用了它與IDE集成的優勢，為設計人員與開發人員提供了便利的工具，完成模型的轉換與輸出。這既有利于設計人員對架構的驗證，幫助維護人員理清程序結構之間的關系，通過對依賴關系的度量檢驗模塊和類之間的耦合關系，更有利于團隊在項目后期生成設計文檔。可以說，VS 2010在可驗證性、標準化、工程化、可度量性方面都有閃光之處。遺憾的是，VS 2010似乎并沒有提供自動將這些模型圖轉換到Word的功能 ，這不能不說是一種遺憾。

　　VS 2010似乎并沒有足夠的功能支持我們快速生成架構，例如經典的三層架構、管道-過濾器或MVC架構。這也正是我想表達的工具不能替代架構師的最大問題。即使可以構造一些模板，就像提供項目計劃模板一般，支持這些經典架構的快速生成，但始終無法替代架構師對領域知識以及質量屬性的分析與設計。

　　從方法學支持的角度來看，VS 2010仍然支持不夠。我很喜歡Enterprise Architect對ICONIX方法的支持方式，在VS 2010中沒有看到對相關方法學的支持 。即使是對UML的表達，VS 2010都顯得過于簡單（支持模型少）與復雜（操作不方便），雖然它的圖形真的非常炫。當我需要構建一個架構時，VS 2010絕對不會是我的首選；但當我需要為架構的實現進行驗證或者提供設計文檔時，只要我工作在.NET平臺下，我絕對會毫不猶豫地選擇它，它真的是一件具有超強戰斗力的利器。

　　現在的Visual Studio 2010已經不是單純的IDE這么簡單，它是一個全方位作戰的快速工作平臺，通過它可以完成設計 、開發、測試、重構以及團隊的管理與協作。這種涵蓋軟件開發生命周期各個階段的綜合工具 ，是開發人員和管理者夢寐以求，因為我們不用再考慮各種不同工具之間的集成與部署，何況VS 2010還提供了非常強大的擴展功能，使得我們能夠因項目或技術而異，實現自己的定制。不過，這種大一統的強權模式，很容易限制開發人員的自由與創新，抹殺人的個性。“知其然而不知其所以然”，開發人員慢慢會產生一種惰性。由工具來完成許多繁雜的工作，固然可以提高工作效率，卻失去了探究背后原理的機會，正如當年的ASP.NET，造就了一幫不明HTTP工作機制的程序員一般。這就需要我們進行取舍，回到開篇的話題上，那就是我們必須要明確自己對工具的態度，讓工具為我所用，卻不會被其所制。

　　[i]只在Visual Studio 2010 Ultimate版本中提供。
　　[ii]就好似重構工具對重構原則的支持。
　　[iii]在類圖中提供了Package，但沒有專門的包圖功能強大。
　　[iv]正向工程的做法請參見MSDN文檔：http://msdn.microsoft.com/en-us/library/ee329480.aspx#What
　　[v]具體做法參見微軟的官方博客：http://blogs.technet.com/b/teamarchchina/archive/2009/08/31/vsts-2010.aspx
　　[vi]只能將模型圖粘貼到Word，而不提供直接導出Word文檔功能
　　[vii]當然，VS 2010支持微軟解決方案框架，即MSF，可以實現概念設計、邏輯設計與物理設計，但就現有的VS架構功能來看，對這些設計的支持顯然不夠。
　　[viii]對Modeling Project還支持版本控制功能。
　　[ix]VS 2010加大了對敏捷的支持，并將Scrum作為基本的敏捷開發模型。

　　注：原文發表于InfoQ《架構師》月刊2010年7月，鏈接地址為：http://www.infoq.com/cn/articles/visual-studio-2010-architecture-tool