团队沟通利器之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 User 20 { 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 Product 32 { 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规范。