影响架构质量的是构建体系架构的思想、原则、实践与架构师的经验绝不是工具。即使是最优秀的架构工具也不可能像倚天宝剑一般——倚天一出谁与争锋——似乎谁握住了这把利刃就能够成为武林盟主。架构工具可以改善架构师的工作却不能替换架构的过程。软件开发过程中最重要的依旧是人。我在尝鲜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之间的交互情况。