团队沟通利器之UML——类图

一：用途

     用于描述系统的静态结构，或许在所有的uml图中，类图是我们最熟悉不过的，在我们没有接触uml的时候，可能都看过

类图，早在vs2005里面“解决方案资源管理器”的下边有一个“查看类图”的小图标，并且还能支持“正向“和”反向“工程。

<1>反向工程

  首先我们定义两个类：User和Product

 1 using System; 2 using System.Collections.Generic; 3 using System.Linq; 4 using System.Text; 5  6 namespace ConsoleApplication1 7 { 8     class Program 9     {10         static void Main(string[] args)11         {12 13         }14     }15 16     /// <summary>17     /// 用户类18     /// </summary>19     public class User20     {21         public string Name { get; set; }22 23         public int Age { get; set; }24 25         public string Sex { get; set; }26     }27 28     /// <summary>29     /// 产品类30     /// </summary>31     public class Product32     {33         public string Name { get; set; }34 35         public DateTime CreateTime { get; set; }36     }37 }

然后我们点击”查看类图“，看看给我们生成的类图是咋样的。

<2> 正向工程

      既然是正向工程，那我们就可以在”类设计器“上面随便拖一些元素看看效果，细节的大家可以自己玩一玩。

二：基本元素

1：类图，枚举，接口，抽象类，结构，委托

    这几个元素我想学OO的都已经烂熟于心了，也没有什么好解释的。

2：关联关系

    关联关系一般作为类与类之间的一种强依赖关系，这种关系具有稳定和长期性，比如在C#中的代码实现为：将一个类作为

另一个类中的属性，比如这里我新建一个Order类，将User类作为Order类的一个属性。

先看类图：

然后看下是否为我们需要的代码：

3：继承关系

   在OO的三大特性中就有继承，我们都知道继承这么个概念，那么在类图中该如何展现呢？我们发现在User和Product

中都有一个Name属性，根据OO原则我们需要将Name属性单独提出来，然后让其他类继承。

下面我们看下生成代码，是否真如类图描述一样，（双击）任意类图即可，嘿嘿，是不是有点意思。

好，到现在为止，在类图这一块，我们已经掌握了20%，只要多练习练习即可，当然你可能觉得这些代码比较死，是的，

实际开发中，我们常会用CodeSmith来解决这些枯燥无味的代码。

在uml的类图中还有几个关系需要表达一下，只不过实际应用比较少而已，好，下面我们看看”建模项目“里面的UML类图

4：依赖关系

    同样它也是类与类之间的关系，只不过这种关系比较弱，具有临时性和特定环境下的偶然性，可能大家不是很容易理解，

如果用C#解释就一目了然了，在代码中一般是一个类作为另一个类中方法的参数，既然是参数，那么它的生命周期你懂的。

5：聚合关系

    在官方文档中它描述的是一种”has-a“的关系，也就是整体与局部的关系，整体挂了，局部不见得就挂了，比如：你的大功率

电器挂了，不见得里面的电池就挂了，其次我们要注意”空心菱形“是整体端，“箭头”端是局部端。

6：组合关系

    在官方文档中它描述的是一种”contains-a“的关系，同样也是表示整体和局部的关系，整体挂了，局部也挂了，因为他们享有

共同的生命周期，比如：你挂了，你的心脏肯定挂了，同样"实心菱形“是整体端。

下面我们看看稍微复杂一点的”画图软件“的类图设计，大家也可以看看自己手头的项目类图，是否符合OO规范。