TeamArch China Site

对VS2010中架构工具的“初步尝试”

TeamArchChina — Tue, 10 Nov 2009 03:34:07 GMT

[备注：本篇出自于文章集“VS2010中的建模和可视化技术”]

请先安装好“Visual Studio 2010 and .NET Framework 4”，本文将带你初步尝试建模和可视化工具的功能。

1. 启动Visual Studio

请注意顶层的“Architecture”菜单

当没有解决方案打开时，“Architecture”菜单的结构如下图所示：

2. 选择“New Diagram…”

几秒后，名为“New Diagram”的对话框（见下图）弹出

这个对话框快捷地展示了VS2010建模和可视化工具中引入的新图类型，其中包括5种UML图，Layer和功能非常强大的DGML。

我将会仔细阐述所有图的功能，但现在，请保持对话框中各控件的默认值并点击OK，

若当前恰好没有任何解决方案打开，你将会看到如下的对话框

(若已打开的解决方案中没有包含任何建模工程，如上的操作也会引发该对话框的跳出)

保持默认值并点击OK，VS显示的布局将会如下图所示（当然除去我所做的红色注释）

此刻，您可以开始在打开的class diagram上添加元素啦。以上是使用VS2010 Ultimate中的各种UML图帮助建模问题域的一些通用的初步步骤。

若在解决方案被打开的情况下，除了一些略微的细节外，以上的步骤大致相似。以下的步骤将会带你体验如何使用这些工具查看已有的代码库。

3. 打开一个已有的解决方案

打开任何解决方案，我这里将会打开Pershop4.0（这个操作将会关闭掉当期的解决方案）。

一旦您的解决方案打开，您将会发现之前的“Architecture”菜单中新添加了名为“Generate Dependency Graph”菜单项

可以通过点击不同的菜单项使用不同的方式查看代码。以下是我选择“Generate Dependency Graph->By Assembly”后生成的DGML图：

在将来的文章中我将会仔细介绍DGML的细节，现在我们只需了解一下概况即可。

在结束这篇文章前我将介绍的最后一项功能是Sequence Diagram

这里我将会以工程OracleDAL为demo介绍SD，首先打开Order.cs，在该类中找到一个适当大小的方法，右击该方法内的任何部分，并且在弹出的菜单中选择“Generate Sequence Diagram…”

4. 生成Sequence Diagram

然后，您将会看到如下的对话框：

继续保持默认值并点击OK，一个如下所示的图将呈现在我眼前：

再次重申一下，这篇文章仅仅包括了VS2010新功能的一些初步的通用步骤，相关的细节信息并未涉及。

正如我在之前那篇文章中指出的，我将会为发布一系列关于VS2010建模和可视化工具的文章。这些文章将不会以特定的顺序给出，如果您希望尽快地看到某些文章，请让我知道。

注：本文翻译自Cameron Skinner的博文：“First-time Experience” with Arch Tools

Visual Studio 2010 Ultimate中的建模和可视化

TeamArchChina — Tue, 10 Nov 2009 03:12:28 GMT

前些日子计划着写一系列关于VS 2010中建模和可视化的文章，做为起始篇，本文概述涉及的范围。该系列中将会涵盖的主题如下图所示，也许会有些微小的变动，但大致还是会以下图的组织方式给出。

请注意泳道（swim-lane）上的标题（“理解代码”等等）。根据产品所针对的问题，我将会以上图中的4个主题的方式组织所有的话题。如“理解代码”讲得是如何利用VS2010中的代码分析和可视化技术帮助用户理解已有的系统。最终，用户可以利用这些技术在已有的代码库基础上帮助客户实现最新的功能需求。

为了将来便于阅读和查看，我将会在发布关于各个话题的文章同时，将每篇文章链接回当前上图中相应的模块。

注：本文翻译自Cameron Skinner的博文：Modeling and Visualization in Visual Studio 2010 Ultimate

Directed Graph Markup Language (DGML)

TeamArchChina — Mon, 07 Sep 2009 07:15:00 GMT

在前面的博客中我已经介绍过DGML的格式,并且在相邻的文章中也展示一些关于在产品里面如何使用这种格式来产生经常使用的图的例子。

在本文中，我将介绍几种在VSTS 2010中控制Links渲染的方法。

Graph元素

所有DGML文档的根元素都是DirectedGraph，缺省名字空间（DirectedGraph元素的一个属性）是http://schemas.microsoft.com/vs/2009/dgml。这个根元素支持很多种XML属性，你可以通过文件编辑的智能提示功能来发现所有支持的属性，这里我特别要指出的是Background属性。

Backgound属性可以用于设置整个图的背景色。可以直接使用ARGB的十六进制格式，也可以使用预定义的颜色名字。

举例来说，如果有如下DGML文档：

那么图显示为：

令人惊讶吧！虽然简单，但也值得了解. :)

Link元素

DGML图都是基于Nodes以及链接Nodes的links组成的。你可以看到上面文档中的Links元素包含了一个Link元素，智能的DGML渲染引擎知道在没有Node的情况下Link是不能单独存在的，所以就自动地根据link元素的Source和Target属性创建了“From”和“To”两个node。

Link元素支持很多有意思的属性，我在这边会特别指出一些。

如果要改变link箭头的背景颜色，可以尝试把Background属性设置成“Red”。你就可以得到如下Link：

如果要改变整个link的颜色，可以把Stroke属性设置成你想要的颜色。如果你只设置Stroke属性而没有设置Background属性，箭头的颜色也会自动变成Stroke对应的颜色。

并且你也可以通过设置StrokeThickness属性来改变link的线宽，如图：

通过改变StrokeDashArray的值，你也可以把link变成虚线。以逗号隔开的值都被转换成doulbe类型，最后的值与StrokeThickness相关，StrokeThikness的缺省值是1。例如，把StrokeDashArray设置成5，而StorkeThikness使用缺省的1，结果如图：

当然，你也可以在这个数组中增加更多的值来改变虚线的模式，举例如图：

小结

本文快速的介绍了一些控制link渲染的方式。在继续的使用中我们会学会更多的东西。在以后的博客中，我将会介绍Node元素，特别是分组和内嵌的支持。请继续关注。

注：本文翻译自Cameron Skinner的博文：Directed Graph Markup Language ( DGML )

Directed Graph Markup Language(DGML)简介

TeamArchChina — Thu, 03 Sep 2009 06:20:38 GMT

在VSTS2010 Architecture版本中，可以使用DGML(Directed Graph Markup Language)生成如下图：

DGML最大的神奇之处在于其简单性，我将通过以下的步骤说明这点：

启动VSTS 2010, 打开架构浏览器(View->Architecture Explorer)后，点击图中选定的按钮后….

一个空的DGML文档将会生成，右击文档表面，选择“View->DGML”：

在<Links>节点下添加<Link Source=”From” Target=”To”/>后，可以得到下图

通过如上的办法，添加更多的结点后，可得下图：

从以上2图所示的DGML代码的对比中，可以看出<Nodes>和<Categories>结点都没有被引用到以生成如图所示的有向图，这就是DGML的简单性所在。

在下篇中，我将会展示给你如何使用DGML技术来可视化Java代码。

注：本文翻译自Cameron Skinner的博文：Introduction to Directed Graph Markup Language ( DGML )

把层图认证功能集成到您的编译过程中

TeamArchChina — Mon, 31 Aug 2009 13:27:21 GMT

本文将向您介绍如何把层图认证功能集成到您的编译过程中。为了简化，我直接延续上一篇博客中的操作流程。所以，如果您是新读者，可能要先一读上一篇博客。

1．卸载“FirstModelingProject”(右键点击“FirstModelingProject”，然后选择“卸载工程”)

2．右键点击“FirstModelingProject”，然后选择“编辑FirstModelingProject.modelproj”

3．找到以下行
</PropertyGroup>
加入新的一行
<ValidateArchitecture>true</ValidateArchitecture>
在PropertyGroup之前。

4．保存工程，然后重载工程

5．你会遇到以下对话框

6．点击“Yes”

7．现在你可以通过命令行来运行编译和层图认证了。
假设你的方案位于"c:\temp\LayerValidation "，请进入这个目录然后运行msbuild LayerValidation".

8．如果您的方案中有层图认证关系的错误，这时您可以在编译结果中就看到。

使用VSTS 2010进行层验证

TeamArchChina — Mon, 31 Aug 2009 13:11:00 GMT

在本系列的第一篇博文中，我将VSTS 2010 架构师版本分解成了几个功能模块（如下图所示），并在随后的几篇博文中介绍了其中的几个模块（下图中的高亮部分）。今天，我想重点介绍一下Layer Diagram。具体的说，我想给大家演示一下如何创建一个Layer Diagram，如何将你的代码映射到图上，以及如何手动的使用你在图上创建的约束来对你的代码进行验证。（在未来的文章中，我将给大家演示如在你的编译过程自动地进行验证）

在本文中，我将使用一段非常简单的代码，因为这里我想强调的是代码所代表的概念，而不是代码的细节。让我们开始吧……

1. 启动VSTS 2010

2. 创建一个名为Client的C# 控制台程序，并将Solution 命名为Layer Validation。你的“New Project”对话框应该如下图所示：

3. 现在右键单击Solution节点，选择“New Project…”，在弹出的对话框中选择“Class Library”并将工程命名为Implementation：

4. 重复第三步，创建名为Interfaces和Creators的Class Library工程。现在你的Solution Explorer应该如下图所示：

5. 展开Interfaces工程节点，右键点击Class1.cs，选择“Rename”，将该文件重命名为IDataRetriever.cs，并在弹出的对话框中选择“Yes”。你的文档编辑窗口和Solution Explorer应该如下图所示：

6. 把class关键字改为interface，将IDataRetriever变成一个接口。

7. 为IDataRetriever添加一个getter属性，该属性返回一个IData类型的对象。你会注意到IData下面的红色波浪线，表示IData不存在。

8. 让我们使用VS 2010的一个新功能来解决这个问题。

9. 右键点击出错的IData，选择“Generate”，然后选择“Other…”

10. 你将看到一个“New Type”的对话框。将其中的“Kind:”修改为“interface”，“Access:”修改为“public”。其他的保留默认设置：

VS会自动向Interfaces工程添加一个IData.cs文件，并在文件中创建一个名为IData的接口。太好了，正是我们想要的！下面让我们在Implementation工程中实现IDataRetriever接口。

11. 展开Implementation工程节点，右键单击References节点，选择“Add Reference…” ，在弹出的对话框中选择Project页，然后选择Interfaces工程。

12. 将Class1.cs重命名为DataRetriever.cs。

13. 打开DataRetriever.cs文件，修改DataRetriever类使其实现IDataRetriever接口。你会注意到当输入IDataRetriever的时候没有出现Intellisense支持。没关系，我们可以手动输入IDataRetriever，然后你会发现IDataRetriever下面又出现了红色波浪线。

14. 将鼠标移动到IDataRetriever上，你会注意到在这个单词开始的位置下方有一个方形的小图标。点击它并选择“using Interfaces;”。它会自动为你添加所需的using语句：

15. 现在“using Interfaces”已经自动为你添加好了。再次选中这个图标，不过这次选择“Implement interface ‘IDataRetriever’”命令。

现在你的“DataRetriever”文件看起来如下图所示：

16. 接下来向Client工程添加到Implementation和Interfaces工程的引用。你可以参考前面第11步的步骤。

17. 打开Client工程中的Program.cs文件。

18. 输入下图所示的代码：

19. 重新编译整个Solution。

让我们来看一下这段程序究竟做了什么。它创建了一个对象，调用了对象的一个属性，然后抛出一个“NotImplementationException”异常。看起来似乎不是那么有趣。但这不是我们关注的重点。这段程序描述了一个实际系统经常遇到的问题。

在这段代码中，Client工程直接访问了一个接口（IDataRetriever）的实例（DataRetriever）。这在目前看来是没有问题的，因为目前所有的数据都是从DataRetriever中获取的（你可以想象DataRetriever是从一个SQL数据库中获取数据）。但是如果将来我们需要从另一种数据源中获取数据，我们如何才能在不改动应用程序其他部分的情况下实现这个需求呢？

我们需要的是不对接口的具体实现做任何架设，而仅仅依赖于接口本身。这是一个相当普遍的设计模式，但是在现实应用中很容易被违反。只要一行错误的代码就会破坏这个模式，建立模块间不必要的依赖关系。我们通常使用控制反转（IoC）来解决这个问题。

那么如何才能保证我们的代码不会违反这一设计呢？我们可以使用Layer Diagram和Layer Validation来帮助我们。

首先让我们创建一个Layer Diagram来可视化地描述我们在架构中想要维护的约束关系。

创建Layer Diagram

1. 点击主菜单的“Architecture”菜单项，选中“New Diagram…”，在弹出的对话框中选择“Layer Diagram”，并将图命名为“FirstLayerDiagram.layerdiagram”，如下图所示：

2. 在弹出的对话框中，将工程命名为“FirstModelingProject”：

3. 现在让我们来画一张Layer Diagram，如下图所示：

请注意箭头的方向必须如图中所示，否则后面的步骤将无法正常工作！

通过这张图我们想要表示的是Client Logic层依赖于Interfaces层，Implementation层同样依赖于Interfaces层。但是Client Logic层和Implementation层之间没有依赖关系。这个约束关系是非常重要的。

现在我们需要将我们的代码映射到Layer Diagram上，这样系统就能验证我们的代码是否符合图中描述的约束关系。

将代码映射到层上

1. 在Solution Explorer中，选中Client工程并将它拖拽到Layer Diagram上的Client Logic层上：

2. 将Interfaces工程拖到Interfaces层上：

3. 最后，将Implementation工程拖到Implementation层上：

4. 现在你的Layer Diagram看起来应该如下图所示。注意层左上角的数字“1”表示该层已经和一个工程相关联。

5. 如果你选中Client Logic层，再打开Layer Explorer，就可以看到和当前层关联的项目。在这里，是Client.exe。

现在我们可以用这张图来对我们的代码进行验证了。

6. 右键单击Layer Diagram的任何位置，选择“Validate Architecture”

你会注意到“Error List”窗口中有三条错误信息：

这是可以预见的，因为Client工程中的Program.cs直接使用了Implementation工程中定义的类型。而在我们刚才创建的图中，这种依赖关系是错误的！

现在让我们来解决这个问题。

修正代码

回到Program.cs，我们需要确保只使用Interfaces工程中定义的类型。换句话说，我们不能直接使用Implementation工程中定义的类型。我们需要在不产生直接依赖关系的情况下创建实现IDataRetriever接口的对象。

让我们引入工厂（Factory）模式来解决这个问题。

1. 在Solution Explorer中，展开Creators工程，将Class1.cs重命名为TypeCreator.cs。

2. 向Creators工程添加对Implementation和“Creators”工程的引用（换句话说，Creators工程现在依赖于Implementation和Interfaces工程）。

3. 打开TypeCreators.cs，向其中添加一个静态方法，该方法返回一个IDataRetriever的对象。代码如下图所示：

4. 在Client工程中，移除对Implementation工程的引用，添加对Creators工程的引用。

5. 修改Program.cs，使用我们刚才新加的方法来创建对象。如下图所示：

6. 重新编译Solution。

7. 现在重新打开FirstLayerDiagram，右键执行“Validate Architecture”。你会看到所有的错误都消失了。

总结

通过一个简单的例子，我给大家演示了如何使用一个简单的Layer Diagram来验证你的代码。这包括如何将代码映射到层上，以及如何通过手动的方式来验证你的代码是否遵守定义的约束关系。

Layer Diagram还有许多其它的功能。其中一个重要的功能是如何在编译代码的过程自动地进行验证。我将在下一篇博文中为大家介绍。

注：本文部分翻译自Cameron Skinner的博文：Layer Validation with the VSTS 2010 CTP

UML Model Explorer

TeamArchChina — Fri, 28 Aug 2009 09:34:00 GMT

在VSTS 2010 Architecture产品中，我们在VS中增加了一个新的工具窗来帮助您理解并操控您所创建的UML模型。UML Model Explorer是一个树状结构的WPF组件，用来展示UML模型中的层次结构。在这里，模型是指您创建Modeling Project中的内容。一般来说，UML Model Explorer中的根节点用来表示Modeling Project本身。

例如下面的图片，我创建了两个Modeling Project：”My First Modeling Project”和”My Second Modeling Project”。打开UML Model Explorer后你会发现两个与Solution Explorer中相对应的节点。

您可能会感到疑惑：为什么要在两个不同的窗口展示同样的信息？下面的介绍会解答这个问题，这里值得指出的是，UML Model Explorer是您创建的模型的逻辑视图，而Solution Explorer展示的是物理视图，例如您的模型是存储在哪个文件中。有了这样的认识，接下来的介绍会更加容易理解。

每次您创建一个Modeling Project，UML Model Explorer中都会显示一个新的节点。这个节点其实是一个UML Package，并使用与Modeling Project相同的名字。所有在这个Modeling Project中创建的模型元素都会显示在该根节点下。创建Modeling Project是唯一在UML Model Explorer中创建根节点的方法。

在VSTS 2010中，所有显示在根节点下的模型元素都存储在对应Modeling Project中的ModelDefinition文件夹中。事实上，每当有UML Package创建时，都会有对应的.uml文件产生。所有在该UML Package中的元素（不包括新建的UML Package），都存储在对应的.uml文件中。如果您在一个Package中创建了新的Package，新的.uml文件会被创建出来，用来存储这个Package中包含的元素。

现在，让我们看看几个例子，并看看UML Model Explorer的一些其他功能。

创建元素

我想在”My Second Modeling Project”中新建一个class。在UML Model Explorer中，我可以右键单击该根节点，并选择Add-Class。

选择后，新创建的class就会出现在”My Second Modeling Project”节点下，并处于可编辑状态，这样，您可以修改该节点的名字。若要修改已存在的节点名称，您可以通过双击该节点的名字区域，或者选中该节点，然后按下F2，使之处与可编辑状态。

下面这张图片展示了多个已创建的元素。每个节点的右边有灰色文字表示该节点的类型。

能够创建什么类型的节点取决于您右键点击的节点。例如，当我点击在class或者interface元素上，我就能够添加UML Attribute和UML Operation了。

当我们添加了Operation和Attribute后，UML Model Explorer看起来是这样的：

除了可以在UML Model Explorer中直接添加元素外，我们还有其他选择。当您拖拽新的元素至图表中后，您会发现这些元素也同样会在UML Model Explorer中显示出来。

例如，我将在”My First Modeling Project”中创建新的UML Class Diagram。通过在Solution Explorer中右键单击该工程节点，选择Add->New Item…，在弹出来的对话框中选择”UML Class Diagram”，并给它一个名字，然后点击OK。

现在，我就有一个空的UML Class Diagram，在Solution Explorer中会看到相应的文件：

现在，我在刚才新建的图表中创建两个class，并用UML Association将两者连起来：

现在在UML Model Explorer中，您会看到在”My First Modeling Project”节点下多出来两个class节点。Association关系也会在节点中表示出来：

那么，UML Model Explorer是如何知道应该将新建立的模型元素显示在”My First Modeling Project”下呢？

在默认情况下，所有图表的”Linked Package”属性都会设置为代表Modeling Project的UML Package。当该图表中有新的元素被创建时，该属性用来表示新创建的元素应该包含在哪个Package中。所以在这个例子中，这个属性被设置为”My First Modeling Project”：

现在，我们来演示一个稍微复杂的例子，来展示更多的功能。

首先，我将在”My First Modeling Project”节点下创建3个UML Package：

上面提到过的，每次创建新的Package都会导致新的.uml文件生成。察看一下Solution Explorer，您会发现在”My First Modeling Project”中的ModelDefinition文件夹中有三个新的.uml文件，每个对应一个新建的Package。

现在我将创建3个UML Class Diagram并关联到这3个Package上。右键单击”My First Modeling Project”，选择”Add->New item…”，然后选择”UML Class Diagram”。重复三次，就能创建出3个UML Class Diagram，如下所示：

在Solution Explorer中双击打开UMLClassDiagram1.classdiagram文件，在Properties窗口中设置图表的”Linked Package”属性，就能将该图表与名为”One”的UML Package关联起来：

我们可以使用同样的方法将UMLClassDiagram2与名为”Two”的Package、UMLClassDiagram3与名为”Three”的Package关联起来。

“Paste By Reference”和删除元素

UML Model Explorer提供了一个很重要的功能，使得让不同图表上显示相同元素成为了可能。我们需要做的只是将元素从UML Model Explorer中拖拽到图表上。

现在，我将UML Model Explorer中的Class1节点分别拖拽至3个新创建的UML Class Diagram中：

这样，Class1就同时显示在3个图表中。通过图表中Class1图形的ToolTip或者将图形变宽，您能够看到它的全名。

这是用来表示该元素虽然显示在该Package中（记得图表本身关联到一个Package），但其实并不属于它。Class1属于My First Modeling Project这个Package，然而UMLClassDiagram1代表名为”One”的Package。

现在，UML Model Explorer仍然只有一个Class1元素。如果我在UML Model Explorer中为它增加一个operation，新增加的operation会同时显示在3个图表中，那是因为3个图表中的Class1图形只是镜像，指向同一个元素。修改Class1上任何一个数据，图表上都会有相应的改变。

同样的，在任何一个图表中对Class1图形做操作，例如增加一个Attribute，会导致元素本身改变，然后会将修改更新到所有其他图表中。

从UML Model Explorer拖拽是创建元素镜像最直观的方法，但是我们也可以通过右键菜单的”Paste By Reference”做到这一点。

当您在图表上删除这些图形时（直接按Delete键或者通过右键菜单，选择”Remove From Diagram”），删除的只是镜像，而不是元素本身。所以，当UMLClassDiagram1上的Class1被删除时，所有其他的镜像以及在UML Model Explorer上的元素仍然会被保留。

但如果我在UML Model Explorer上删除Class1，或者在任意一个图表里选择Class1图形，然后通过右键菜单选择”Delete From Model”，删除的是元素本身，所有该元素的镜像也会一起被删除。

总结

希望您能够通过这篇文章了解UML Model Explorer的基本功能。最关键的一点是，UML Model Explorer是Modeling Project的逻辑视图。它表示了所有能够在不同图表上显示的元素。这些元素不仅仅可以在图表上操作，也可以通过UML Model Explorer操作。

注：本文部分翻译自Cameron Skinner的博文：The UML Model Explorer

模型与工作项的集成

TeamArchChina — Fri, 12 Jun 2009 09:30:00 GMT

我想继续讨论一些在即将发布的VSTS 2010 Architecture产品的“团队协作”功能。在这篇文章里，我想向您展示我们将如何帮助您将任何模型元素链接目前已储存在您的Team Foundation Server中的工作项。

什么是工作项？

如果您不熟悉Team Foundation Server中的工作项追踪的功能，可以先看一下这里的演示。您可以认为工作项是一个通用的来描述各类事物，如Bug、用户需求的方法。事实上，如果您如果用TFS 2008创建新的Team Project时采用的是默认设置，您就会看到Bug、要求、风险、案例和任务等工作项。

您可以创建自己的工作项目类型，可在已有工作项基础上的修改（例如添加您自己的字段来扩展默认的Bug工作项），或完全从头开始定义。阅读这篇文章可了解更多详情。在VSTS 2010中一个重要的新工作项类型是测试用例工作项。

工作项可以联系在一起，或其他事物也可以链接到他们。在VSTS 2010版本的Team Foundation Server中，添加了丰富的对工作项层次的支持。去看看Grant关于这一新功能的帖子吧。

您可以查询TFS，寻找特定的工作项，查找工作项之间的关系报告等。

现在让我介绍一下，在我们的设计中，如何将您的各种模型工件连接到现有或新的工作项上。

关联到工作项

这是一个空的类图的截图。

请注意右下角，图本身有一个叫做“Work items（工作项）” 的属性，值为“0 associated（0个相关）”，它是灰色。这是说明这个图没有连接到任何工作项。

现在，让我们创建一个新的类，并查看其属性：

同样，没有工作项与这个类相关。

简单来说，您可以将整个图表，或个别模型元素，包括连接元素，链接到您的Team Foundation Server和Team Project支持的任意类型的工作项！

目前有两种办法可以创建图表/模型元素和工作项之间的链接。您可以在创建链接的同时创建工作项，或者您也可以链接到已有的工作项上。我会展示给您这两种不同的方式。

创建工作项

要创建一个新的工作项目，并自动将其关联到图表，只需右键单击图表的背景，并选择“Create Work Item（创建工作项）”。假设您使用的是2008 TFS Agile Team Project，那么默认情况下在这里您将会看到：

选择“Bug”的菜单项既可。一个新的TFS Bug工作项显示在屏幕上：

填好Bug标题并保存之后，你会发现，现在我有一个工作项与我的图表相联系了：

链接到已有的工作项

更多情况下，您可能想要将图表或模型元素与已有的工作项联系起来。使用上面的图表，只需右键单击图表背景，并选择“Link to Work Item…（链接到工作项...）”。这样，“工作项选择器”对话框就显示出来了。

此对话框可使您可以根据已有的查询、工作项编号或标题，来查看工作项清单。您可以根据具体工作项类型进一步筛选查询结果。

我准备把这个图表与一系列样例任务工作项联系起来，首先使用一个已有的查询：

选择“All Tasks（所有任务）”查询，然后点击“Find（查找）”按钮来返回储存在TFS中的所有“任务”工作项。选择的头两个任务，像这样：

点击“OK（确定）”按钮，现在就有3个工作项与图表相联系了。

查看已链接的工作项

现在，我已经将图表联系到了3个不同的工作项，随后如何才能轻松地查看工作项的具体内容呢？右键单击图表背景，并选择“View Work Items…（查看工作项...）"。一个新的查询结果窗口将会显示出来：

以上我展示的关联工作项到图表的方法对所有模型元素都同样适用。这里我说的模型元素，包括Class、Association、Attribute、Operation、Comment、Layer等。所有这些元素都可以与任何类型的工作项联系。

小结

我已经向您介绍了一些 VSTS 2010Architecture产品中的新功能。您可以创建或链接到现有的工作项到任何UML图表或层图，并能迅速查看相关联的工作项的内容。

你对此有何看法呢？

这一功能将使许多用法成为可能，比如将UseCase与用户需求或者测试用例连接起来。

考虑一下这个功能吧，我很希望听到您将如何使用它。

注：本文翻译自Cameron Skinner的博文：Model and Work Item Integration

VS2010 / .NET Framework 4.0 Beta 1发布

TeamArchChina — Wed, 20 May 2009 04:19:00 GMT

我们很高兴地告诉大家，Visual Studio 2010和.NET Framework 4.0 Beta1版本已经发布。MSDN订阅者可以从这里下载。到美国时间20日星期三，也就是我们的21日星期四的时候，Visual Studio 2010 / .NET 4.0 Beta1将公开对外发布。

Visual Studio 2010在很多方面都有了革命性的改变，包括引入了F#，更强大的WPF设计器，等等。当然，这个版本包含了我们开发的TeamArch组件。详情请看Jason Zander的博文。

VSTS 2010 Architecture 第一章:Modeling Project

TeamArchChina — Tue, 28 Apr 2009 09:17:00 GMT

在上一篇博文中，我们讨论了VSTS 2010 Architecture产品的逻辑结构。现在，我们将深入探究该产品的不同领域。首先，让我们来看一下“团队合作”领域，特别是最新引入的名为“Modeling Project”的新工程类型。

Modeling Project是模型数据、图表文件和其他用户想要存储的资源（比如Word文档）的容器。用户可以在任何新建的或者已有的解决方案中添加该工程，无论解决方案中是否有其他工程（C#、VB、Web等等），它都能工作的很好。当然，和其他工程一样，Modeling Project也支持版本控制。

现在，让我们实际操作一下：

Modeling Project

在2010 CTP版本中，当用户创建新工程时，会在对话框中发现新的工程模板，如下图所示：

选择Modeling Project模板后，Visual Studio解决方案窗口中会创建Modeling Project。

在”ModelDefinition”文件夹中有一个名为”ModelDefinition.uml”的文件。在2010 CTP版本中，这个文件会用来存储所有创建出的UML模型。让我们来看一下工程创建后该文件的内容：

接下来，我们来看一下，创建一个Logical Class Diagram并在Diagram上创建一个Class元素后，该文件会产生哪些变化。

右键点击ModelingProject的工程结点，选择”New Item”，如下图：

选取后，将弹出“Add New Item”对话框：

采用默认选择，直接按”Add”按钮。modeling project会变成这样的状态：

现在，让我们在新打开的图表中创建Class元素。单击选中Toolbox上的”Class”，拖拽到我们刚创建的图表上，并保存全部。

图表看起来是这样的：

让我们回过头来看一下ModelDefinition.uml文件发生了什么变化：

相比之前的文件，唯一增加的是该Class元素的信息。值得注意的是，所增加的部分只是对于该元素的数据描述，没有任何布局信息。这里没有显示该元素所必需的位置、颜色信息，甚至连该元素包含在LogicalClassDiagram1图表这样的信息都没有。在维护数据的时候，模型数据和布局信息始终是分开的。

在CTP版本中，无论用户在不同的UML图表中添加多少模型元素，只有一个文件会随之增大。这不是我们想要的行为。在RTM版本中，每创建一个Package元素，都会有一个文件随之创建，放在ModelDefinition文件夹中。在这样的设计下，一旦Modeling Project位于版本控制下，多文件的结构能减轻合并修改冲突时的工作。

那么布局信息在哪里？你能在.diagram文件里找到它。

团队合作

为什么我要将Modeling Project的内容归类到“团队合作”框架里？因为这个工程会成为主要的方法之一，将其包含的模型元素数据通过版本控制系统在你的开发小组中共享。

当然，你也可以通过打印和邮件来共享这些数据信息，但是将你的源代码和对应的代码模型一同放在版本控制系统中，能够极大地方便开发，提高效率。

也许大家还有一个问题，如果我们的开发人员并没有安装2010 Architecture版本，是否依然能够使用包含Modeling Project的解决方案？他们是否能够查看其中的图表文件？当然可以！！在这样的情况下，开发人员可以加载Modeling Project，双击并查看图表，选择其中的元素，查看它们的属性，放大或者缩小图表，等等。他们唯一无法做的，是修改这些数据。

总结

2010 Architecture中新的Modeling Project会将所有与模型相关的资源包含在内。它会存储模型数据，图表信息，以及用户认为重要的资源，例如Word文档，PowerPoint幻灯片等等。然后，Modeling Project可以加入版本控制，在小组中共享了。

注：本文翻译自Cameron Skinner的博文：VSTS 2010 Architecture: [Part One] Model Project

Visual Studio Team System 2010 Architecture: 前言

TeamArchChina — Tue, 28 Apr 2009 08:55:00 GMT

目前为止，你已经可以获取VSTS 2010 CTP的版本。而在今后的几个月中你很快可以获得VSTS2010Beta版本。这里，我们将有一系列文章来介绍VSTS Architecture版本的相关内容，以及在将来的RTM版本中我们将做哪些改进。

首先，我们来讨论一下我们产品的结构，每个组件的功能，以及这个产品所能提供的解决放案。

下面这张图是该产品的主要功能划分。这里将功能划分为三块：

理解现有代码
明确结构设计
团队合作

理解现有代码

我们产品的目标之一就是就是帮助你理解现有的代码。因为只有理解了它，你才能够正确地使用。在实际的工作中，我们经常会碰到这样的问题，只有了解现有代码能够做什么，我们才能开展后续的工作。

我们产品中有很多功能用来帮助理解现有或者遗留下来的代码。这里罗列了主要的三个：

Architecture Explorer

这个组件曾在TechEd 08的Bill Gates keynote中展示过。这个组件能够为你的Visual Studio解决方案和工程提供可视化结构图，让你更方便地浏览，并回答一些你可能会问的问题：这个类是如何依赖其他类的？这个程序集引用了哪些其他程序集？这个方法中有多少行代码？等等。

标准图表

在2010 CTP中，你会在”Analyze”菜单项中看到3个选项，在Architecture Explorer窗口里，也有对应一致的选项：

在”Analyze”菜单中：

在Architecture Explorer工具栏中：

选取任何一个选项都会生成程序集，名字空间或者类之间的依赖关系图。我们希望在RTM的时候会有更多选项。

时序图（Sequence Diagram）的反向工程

当你在代码中右键点击方法中的任意位置，在右键菜单中选择”Generate Sequence Diagram…”，你会发现一个生成好的时序图已经展现在你面前。这里有一个PDC talk的视频，在40分钟左右的时候演示了如何使用这个功能。

明确结构设计

我们常常需要设计和描述软件的构架应该是什么样子的，为某一个特定问题定义名称来描述它，然后让小组内的其它成员也能接受并理解它。这也是VSTS 2010 Architecture致力于解决的问题之一。为了这个问题，我们不断地完善支持UML的模型，也为此改进了我们的DSL工具。

在VSTS 2010中，我们将发布5种UML图表：

类图Class Diagram（我们称之为逻辑类图 Logical Class Diagram）

用例图Use Case Diagram

时序图Sequence Diagram

活动图Activity Diagram

组件图Component Diagram

我们将在以后的博文中介绍这些图表。如果你想先睹为快，Mark Groves在这里有一段演示视频。

值得一提的是，RTM以后我们将通过PowerTools或者其他方法发布更多的图表。

DSL工具是支持我们产品中很多功能的关键技术。比如，我们所有的UML图表都是通过DSL工具来建立，并运行在DSL运行库之上的。我们认识到DSL工具对我们来说是如此重要，所以我们重组了我们的开发小组，现在，开发DSL工具的开发人员已经成为我们的一部分！我们相信，这样的重组无论对我们开发小组还是对用户来说都是有益的。Stuart Kent，DSL工具开发的领导之一，已经在他的博客中描述了DSL工具最新的功能。

团队合作

最后，我们希望建模的结果能够成为整个软件开发周期中重要的一部分。这里，我们提供了多种方法可以让模型和Team Foundation Server以及Visual Studio自身进行交互。

2010 Architecture是和Visual Studio高度整合的。这样的整合不仅体现在所有的图表和功能都在Visual Studio内核中，我们还在Visual Studio中添加了全新的工程种类，称为Modeling Project，我们提供的UML图表和其他相关资源，比如通过Architecture Explorer创建的dgml文件，都将能够通过该工程添加。

与其他工程一样，Modeling Project也支持版本控制。

同样，你也会发现新引入的工具窗口，现在称为UML Model Explorer，它是用来展示你创建的各种Modeling Project中模型元素之间的逻辑关系。

另外，我们之前所说的与Team Foundation Server进行交互并不仅限于版本控制。我们还支持一种名为Architectural Validation的功能，它可以作为编译和checkin流程的重要部分。在这个PDC视频30分钟的位置，Cameron介绍了这个部分。

整合部分也包含了跟踪TFS中工作项的功能。可惜这个功能没有包含在2010 CTP中，不过我们会在以后的博文中介绍这个功能。概括来说，我们将允许模型中任意一个模型元素和某个工作项绑定，让你直观地了解某个模型是为哪个需求，或者测试用例定义的。

总结

这篇博文可以作为一个目录。我们希望将在以后的文章中详细讨论今天提到的各个部分。

注：本文翻译自Cameron Skinner的博文： Visual Studio Team System 2010 Architecture: Prologue

TeamArch中国博客正式开通

TeamArchChina — Thu, 08 Jan 2009 06:24:00 GMT

大家好。我们是微软公司位于上海的开发团队，主要负责TeamArch产品的设计，开发和测试。TeamArch是Visual Studio Team System 2010 Achitecture产品的简称。它提供一整套集成化设计和反向工程工具，使得在Visual Studio集成环境中进行设计建模更为便捷。我们的目标是让软件架构师和开发人员能够更加方便地分析需求，设计应用程序和服务，并以此来指导开发。

在这个博客中，我们会着重介绍我们的产品特性，使用指南和技巧。当然，我们也会分享相关的新闻，信息和资源。同时，我非常希望能通过这个渠道听到来自你们，特别是中国用户的声音，来帮助我们提高产品的质量和可用性。谢谢。