图4为该依赖图的局部：

　　图4：依赖图的局部

　　我们可以看到Model对象被依赖的强度是最高的，其中ITradeSerivces接口几乎依赖所有的模型对象，这是因为该接口是服务层的主要服务，相当于外观服务，负责协调和操作订单、报价、账户信息等模型对象的消息处理。

　　就我的感受来看，这样的依赖图显得有些华而不实，因为这样一张蜘蛛网般的图形，实在让人有些茫然，我们可能会在一张超级大型的依赖图中迷路。不过，如果希望对依赖关系来一次鸟瞰，或者需要初步了解各个对象的依赖强度，该依赖图还是有一定的参考价值。此外，倘若系统规模不够大，则可以选择类型级的依赖图;如果系统规模太大，则可以根据程序集或命名空间生成依赖图，这可以在一定程度减小依赖图的复杂程度。

　　时序图的逆向工程实在太精彩了。静态的类图虽然有助于我们了解类的结构，但类之间的协作却根本无法跟踪。我们在做设计的时候，常常会借助时序图来帮助我们了解某个功能项的执行过程，追踪它的消息传递方式，清晰把握类的协作方式，并以此为基础寻找到类的行为，以及不存在于真实世界的类对象。在阅读并理解代码时，如果能够有时序图的帮助，会更容易理清设计的思路，明白设计的目的。例如，同样在StockTrader项目下，我需要了解服务层中TradeService类的login()方法实现，就可以为其生成一个时序图。在VS 2010中，生成时序图只需要在方法上点击右键，选择“Generate Sequence Diagram…”项即可。图5是为login()方法生成的时序图，我们可以清晰地看到TradeService与Icustomer和ConfigUtility之间的交互情况。

　　图5：为login()方法生成的时序图

　　在VS 2010中生成层模型和验证架构

　　层模型对架构师的帮助更大。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要求的原则，就会提示错误[v]。这样的验证功能可以帮助架构师快速地验证团队的开发人员在实现过程中是否遵循了自己的设计。

　　从上述分析可以看出，VS 2010架构工具充分利用了它与IDE集成的优势，为设计人员与开发人员提供了便利的工具，完成模型的转换与输出。这既有利于设计人员对架构的验证，帮助维护人员理清程序结构之间的关系，通过对依赖关系的度量检验模块和类之间的耦合关系，更有利于团队在项目后期生成设计文档。可以说，VS 2010在可验证性、标准化、工程化、可度量性方面都有闪光之处。遗憾的是，VS 2010似乎并没有提供自动将这些模型图转换到Word的功能[vi]，这不能不说是一种遗憾。

　　VS 2010的不足之处

　　VS 2010似乎并没有足够的功能支持我们快速生成架构，例如经典的三层架构、管道-过滤器或MVC架构。这也正是我想表达的工具不能替代架构师的最大问题。即使可以构造一些模板，就像提供项目计划模板一般，支持这些经典架构的快速生成，但始终无法替代架构师对领域知识以及质量属性的分析与设计。

　　从方法学支持的角度来看，VS 2010仍然支持不够。我很喜欢Enterprise Architect对ICONIX方法的支持方式，在VS 2010中没有看到对相关方法学的支持[vii]。即使是对UML的表达，VS 2010都显得过于简单(支持模型少)与复杂(操作不方便)，虽然它的图形真的非常炫。当我需要构建一个架构时，VS 2010绝对不会是我的首选;但当我需要为架构的实现进行验证或者提供设计文档时，只要我工作在.NET平台下，我绝对会毫不犹豫地选择它，它真的是一件具有超强战斗力的利器。

　　结语

　　现在的Visual Studio 2010已经不是单纯的IDE这么简单，它是一个全方位作战的快速工作平台，通过它可以完成设计[viii]、开发、测试、重构以及团队的管理与协作。这种涵盖软件开发生命周期各个阶段的综合工具[ix]，是开发人员和管理者梦寐以求，因为我们不用再考虑各种不同工具之间的集成与部署，何况VS 2010还提供了非常强大的扩展功能，使得我们能够因项目或技术而异，实现自己的定制。

　　不过，这种大一统的强权模式，很容易限制开发人员的自由与创新，抹杀人的个性。“知其然而不知其所以然”，开发人员慢慢会产生一种惰性。由工具来完成许多繁杂的工作，固然可以提高工作效率，却失去了探究背后原理的机会，正如当年的ASP.NET，造就了一帮不明HTTP工作机制的程序员一般。这就需要我们进行取舍，回到开篇的话题上，那就是我们必须要明确自己对工具的态度，让工具为我所用，却不会被其所制。