我眼中的Visual Studio 2010架构工具
影响架构质量的是构建体系架构的思想、原则、实践与架构师的经验，绝不是工具。即使是最优秀的架构工具，也不可能像倚天宝剑一般——倚天一出，谁与争锋——似乎谁握住了这把利刃，就能够成为武林盟主。架构工具可以改善架构师的工作，却不能替换架构的过程。软件开发过程中，最重要的依旧是人。
我在尝鲜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为该依赖图的局部：
图4：依赖图的局部
我们可以看到Model对象被依赖的强度是最高的，其中ITradeSerivces接口几乎依赖所有的模型对象，这是因为该接口是服务层的主要服务，相当于外观服务，负责协调和操作订单、报价、账户信息等模型对象的消息处理。
就我的感受来看，这样的依赖图显得有些华而不实，因为这样一张蜘蛛网般的图形，实在让人有些茫然，我们可能会在一张超级大型的依赖图中迷路。不过，如果希望对依赖关系来一次鸟瞰，或者需要初步了解各个对象的依赖强度，该依赖图还是有一定的参考价值。此外，倘若系统规模不够大，则可以选择类型级的依赖图；如果系统规模太大，则可以根据程序集或命名空间生成依赖图，这可以在一定程度减小依赖图的复杂程度。
时序图的逆向工程实在太精彩了。静态的类图虽然有助于我们了解类的结构，但类之间的协作却根本无法跟踪。我们在做设计的时候，常常会借助时序图来帮助我们了解某个功能项的执行过程，追踪它的消息传递方式，清晰把握类的协作方式，并以此为基础寻找到类的行为，以及不存在于真实世界的类对象。在阅读并理解代码时，如果能够有时序图的帮助，会更容易理清设计的思路，明白设计的目的。例如，同样在StockTrader项目下，我需要了解服务层中TradeService类的login()方法实现，就可以为其生成一个时序图。在VS 2010中，生成时序图只需要在方法上点击右键，选择“Generate Sequence Diagram…”项即可。图5是为login()方法生成的时序图，我们可以清晰地看到TradeService与ICustomer和ConfigUtility之间的交互情况。