1.8 UML
作为一个职业的软件设计人员，你可能已经对UML有一定的了解。这种情况下，你可能会问这样的问题：当我们采用新的设计工具时，如何利用以前学习的UML技术呢？如何利用以前的UML图呢？如果确实需要UML建模能力，那么该怎么办？
我们尝试着回答这些问题，但是首先解释微软关于UML的观点。
根据发布的建模战略，微软不反对UML。微软将UML视为有价值的符号，用于概略描述软件生命周期前期的思想。正如前文介绍过的，你可以继续使用Visio。第三方软件供应商也提供支持，例如Borland，正在为Visual Studio 2005开发构建UML 2.0的建模工具。新的可视化设计器为了便于过渡，也采用了与UML很类似的符号。
但是微软的观点是可以更好地消除设计和开发之间的障碍(建模和编码)。为此，通过提供一系列可视化的设计器(由DSL支持)，当为特定的领域提供了高保真的建模能力时，就可以使用建模工具在抽象的层次上工作了。从这个角度上讲，扩展UML 2.0就很复杂，并且不够具体。
1.8.1 如何利用UML技术
首先，直接将UML 与Team Architect的可视化设计器进行比较是根本无效的，更谈不上公平。微软故意回避UML而力推DSL，这些语言在特定的任务中十分易于理解。现在是这个愿景的早期，所以我们不能指望Visual Studio 2005可以具有覆盖所有领域的可视化建模能力。
虽然逐一比较是不可能的，但是这不意味着没有相似性就不能利用UML的技术。
首先，可以使用应用程序设计器通过终结点对应用程序进行建模，与UML组件图中通过接口对组件进行建模很类似。因此，如果你以前使用过组件图，那么你会很快掌握应用程序关系图。事实上，在本章上文中介绍过将UML组件图和VSTS的应用程序关系图进行等价的转换。
其次，逻辑数据中心设计器与部署设计器一起使用，能够对逻辑基础设施进行建模，并且表示哪个应用程序将部署到哪个服务器上。UML部署关系图也采用类似的方式。因此如果你使用过部署关系图，那么你将很快掌握逻辑数据中心关系图。
对于类图，第一眼就会看出与UML类图十分相似。类(带有容器的长方形)和接口(带柄的圆形)与UML类图是一样的。还有一些符号也一样，例如关联。两者目的是相同的：为代码的底层类提供图形化的表示。你应该知道一些术语的区别，例如在UML 中的“操作”和“属性”(在类设计器中为“方法”和“字段”)，并且在UML中的“泛化”(在类设计器中为“继承”)。
以上观点能够在一定程度上说明UML知识是有价值的。至少能够将UML的部分知识应用于新的工具。
目前，Team Architect版本中没有提供类似于UML序列图和状态图的动态建模能力。当新的支持动态建模的DSL可视化工具产生时，这种情况会有所改变。在此期间，可以继续使用Visio，或者使用在图上加注释的方法来表达动态信息。
1.8.2 利用在UML上的投入
如果你已经设计过.NET应用程序，那么可能会有一些用Visio for Enterprise Architects或者IBM-Rational XDE绘制的模型，你可能希望将它们移植到Team Architect。
将所有的模型都移植过来是不可能的。不仅因为缺少XMI交互的功能，而且因为Team Architect版本不能表示UML模型的一些内容，特别是用例图和动态图。可以继续使用Visio的存在作用(如下文所述)，作为记录动态信息的最好的工具。
当然，可以将静态信息从现有的模型类图导入到Team Architect。或者从Visio生成代码之后再导入到Visual Studio中，或者可以使用逆向工程将已经部署的应用程序(包括Web Service)导入到Team Architect。多亏了代码同步，我们能够快速地创建类图或者应用程序关系图，它们反映Visio生成的或者逆向工程的代码。
1.8.3 获得完全集成UML的能力
在本章中，我们已经给出了很多理由来劝说你根本不需要UML。并且微软将提供更多更好的语言。但是，尽管这样，如果你希望采用Visual Studio 2005 Team System但是又无法脱离UML，那么该怎么办呢？
一个选择是等待第三方工具提供商来提供UML插件。Borland已经宣布使用Visual Studio 2005 SDK 和DSL 工具开发UML 2.0。
另一个选择是使用微软的DSL工具创建自定义的UML设计器。我们不推荐这样，除非你所在的组织可以接受这个开发成本，或者你认为能够销售这个产品！但是必须要说明的是，使用DSL工具创建自定义的符号是前所未有的简单。为了证明这一点，我们使用DSL表示了UML活动图的符号。Activity Designer的结果如图1-9所示。
虽然这个工具不能应用于实际，并且也仅支持非常有限的符号子集，但是我们仅用了几天时间就完成了设计和开发—— 而不是几个星期或者几个月—— 便得到了如图1-8所示的图。你应该感谢DSL工具所提供的潜力，甚至是对UML的顽固支持分子而言也一样。
我们可以使用DSL工具轻松地构建其他UML图，例如用例图和协作图。如果你认为工作量太大，那么微软的DSL工具组已经提供了DSL实现UML的例子，包括用例图、活动图和类图。DSL工具包可以从http://lab.msdn.microsoft.com/teamsystem/workshop/ dsltools/default.aspx下载。
1.8.4 Visio for Enterprise Architects的保留作用
微软以前将Visio for Enterprise Architects与Visual Studio .NET相绑定，作为.NET应用程序的建模工具。微软继续将Visio for Enterprise Architects作为补充工具，提供广泛的建模能力，在早期分析阶段最为有用，并且遵守UML 1.3。
以下是如何继续使用Visio的建议：
我们不推荐将Visio与Team Architect的可视化设计器一起使用，在Visual Studio中进行详细设计、实现和部署。Team Architect显然在这方面更强大，包括IDE集成、代码同步、易于创建可部署的设计。
我们推荐使用Visio来进行前期的分析和设计，业务分析人员和系统分析人员也都已经习惯使用它，而不是习惯使用Visual Studio的设计人员/开发人员。简而言之，我们主张对于每种工作使用合适的工具，尽量减少或者不要有重叠，如下所述：
● 使用Visio进行最初的分析，业务分析人员或解决方案设计人员更习惯使用Visio。
● 使用Visio一次性生成域模型的代码。因为Team Architect保证代码与模型完美的同步，任何Visio生成的类都能立即被转变为Team Architect的模型。
● 使用Team Architect的应用程序设计器来规划系统总体架构，定义互相连接的应用程序和服务，类似于UML的组件图。
● 使用Team Architect类设计器继续开发Visio生成的域模型(如果你有的话)，使其成为合适的技术设计模型，与Visio不支持的.NET框架类协作。
● 使用Team Architect的自动保证代码和模型同步的机制开发代码，类似于UML的逆向工程。
● 使用Team Architect逻辑数据中心设计器和部署设计器，指定部署系统的映射和约束，类似于UML的部署图。
最终，如果需要动态建模来支持详细设计，那么就使用注释来表达必要的信息，而不要再使用Visio。
在Professional UML with Visual Studio.NET: Unmasking Visio for Enterprise Architects (Wrox, 2003年)一书中，详细介绍了Visio中的UML功能。此书基于Visio for Enterprise Architects 2003编写的，但是也适用于Visio for Enterprise Architects 2005。
http://book.csdn.net/bookfiles/531/10053117943.shtmlhttp://www.syue.com/SE/Analyze/2009/0502/234610.html (UML在微软的VS与Visio间的应用 VEA)