规划和设计应用的支持：

       初次看到Distributed System Diagram之后，第一感觉就是“它是我需要的”，而且三个层次划分后的Logical Data Center Diagram、Application Diagram、System Diagram给了解决方案架构师和基础环境架构师沟通的桥梁。

（注：这里解决方案架构师和基础环境架构的称呼时参考Microsoft Certificated Architect的分类标准，分别代表应用设计的Solution Architect和运行环境设计的Infrastructure Architect。）   

而且三个图还可以进行验证，这对于“失之毫厘，谬以千里”的架构设计而言更为重要，虽然说应用设计更多的靠经验，但是做一个好的设计往往还需要灵光一闪，尤其是架构设计人员在着手设计新系统的时候总是喜欢为“以前”所碰到的问题（或按照商标化的说法称之为挑战）提出一些建设性的改进。当然，相对而言这些新的改进不如那些轻车熟路的东西成熟，因此VSTS提供的分布式系统图验证功能就非常重要了。 

同时这些图也方便了架构设计人员和开发人员间的沟通，很多时候设计方案写了1万字的描述性内容也许不如一个设计图来的清晰，原因很简单没有这个图，那么相信在看到那些描述性内容后每个开发人员脑海里都会有副图，而且是一人一幅，与其到了快结项的时候争论“怎么做成了这样”，还不如一开始就统一起来，确保团队的每个开发人员在采掘石块时脑子里已经有了待建立教堂的样子。  

       至于VSTS的Class Diagram Designer是笔者非常喜欢，但又最希望VSTS大力改进的部分：毕竟有了专门的Enum、Delegate图标，对于Inner Class的表示也非常直观；有了专门显示Collection Association关系的连接线让类于类间的包容关系一目了然；对于泛型、继承关系、接口实现关系的显示非常清晰；和自动生成的代码保持同步，大大减少了每个代码块内部框架代码的编写工作量；而且界面看起来也很美观；比起其他类似设计工具而言，它100%纯.Net化。同时，对于UML 2.0类图非常多图标显示的缺失也是非常遗憾的，比如没有命名空间（类比以往产品中的Package）、Association Class、异常（Exception）的专用图标。除此之外，没有状态图、时序图对于开发人员也非常不方便，不能在VSTS中用图形化的方式表示实现层面动态结构的内容是很遗憾的事情。虽然可以借助Visio完成图纸，但是总感觉Visio更像一个画图工具，而非设计工具。另外，因为没有命名空间的支持，因此类图设计器也没有类层次drill in和drill out，不利于从不同层次观察项目的静态结构。现阶段，能用类图设计器完成的图纸笔者尽量用VSTS完成，毕竟它直接联动到后面的实现，实在不够的只好用对UML 2.0覆盖比较全面而且轻巧的StarUML完成。