活动图

在平时的项目开发中，可能有的团队对业务都是用口头在团队里面进行交流，有时程序员的理解跟老大表达的意思不一致，还有其他等等的弊端就不说了。我们知道建筑工人都是按照图纸做事的，同样在软件开发中，我们应该也有这样一份”图纸“，这也就是我们要说的UML，有了它就可以让我们做事统一口径，而从更快的理解业务并完成项目。

可喜的是VS2010已经集成了我们平时最常用的一些UML图，这个系列也准备介绍这4种图。

我们从”活动图“说起，平时我们在看prd的时候，经常会看到一些”用例图“和”活动图“，对的，一个好的产品经理这些都是基本功。

一：用途

活动图是一种工作流程图，非常容易看懂，非常适合于和用户沟通的一种UML图。

二：基本元素

现在我们看一下活动图到底有哪些基本元素，这些也是我们经常用到的。

1：初始节点，活动最终节点，操作，连接符

<1> 初始节点： 在绘制活动图中，总有一个起始点，在UML的规范中用”实心圆点“表示。

<2>活动最终节点： 有起点就必然存在终点，在UML中用”空心圆点“表示。

<3> 操作： 是活动图中的一个基本步骤，具有原子性。

<4>连接符： 操作之间的过渡我们用”连接符“进行连接。

下面做个简单的例子加深下印象，这个也是最简单的活动图。

2：注释

良好的代码习惯是二行一注释，在UML中同样也存在注释，道理都一样，帮助团队理解。

3：对象节点

首先看下专业的解释：如果一个操作执行结束之后生成了某些数据需要传递给下一个目标操作，此时需要用对象节点表示。对应到上面案例就是我们需要在”登陆界面“和”登陆后台“中间插一个”登陆信息“的对象节点，这个也就是”登陆界面“产生的数据。

4：决策节点和合并节点

<1>决策节点： 在工具箱中我们看到决策节点使用”菱形“来表示的，也非常好理解，决策嘛，不就是抉择，一条边进，多条边出。

<2> 合并节点： 既然放在一起讲，它们肯定有关联，多条边进，一条边出，比如在很多页面中都有传送门让我们进入登陆页面。

如果眼尖的话已经看到了”连接符"旁边的提示信息，这个也就是“警示信息”，设置方法很简单，选中“连接符”，按F4打开“属性窗口”，然后在Guard字段中设置值即可。

5：分叉节点和联接节点

这两个节点是真的需要同对出现，用途跟“决策和合并”非常类似，分叉节点是一条边进，多条边出，联接节点是多条边进，一条边出，只不过有一点不一样的就是，联接节点需要等待“分叉节点”的所有边都到达后整个流程才能继续进行下去。

对应上图中，我们登录成功后，进入了分叉节点，此时我们需要干两件事情，“签到”和“发微博“，如果只做了其中某一件事情，整个流程都会处理中断状态，直到两件事都已做完，哈哈，是不是有点多线程的味道。

最后要补充的就是，UML是图形语言，没有绝对的正确和错误，团队能够理解才是最终目的，所以我们应该拒绝”口交“。

用例图

在所有的UML图中，最容易理解的是用例图，也是元素最少的一种UML图，也是产品经理最拿手的一种图。

一： 用途

用例图常用来描述需求，让用户第一时间了解系统所具有的功能，可能有人就会问，几个图怎么可能让人一下就了解系统所具有的功能的?其实在产品经理的prd中都是“图文相依”的形式展现，这里的“文”也就是“用例描述”。

二：基本元素

用例图中的所有元素都是初级概念，所以所有的元素都是我们常用的，首先我们还是看看工具箱中的元素。

1：参与者，泛化

<1>参与者： 我们知道用例图是展示系统功能的，以后这个成型的系统给谁用，这个系统以后要跟谁进行交互，那么“参与者”就是那个“谁”， 这里要注意的就是“参与者“不光指人，还可以指一切的虚拟参与者。

<2> 泛化： 泛化这个太简单了，也就是面向对象中的继承，我相信可以一笔带过了。

2：用例，关联

<1> 用例： 这个是用例图中最核心的，顾名思义也就是要展示的功能点。

<2> 关联： 在”参与者“和”用例“之间，我们必须要用”关联关系“进行连接。

3：包含，扩展

<1> 包含： 包含的意思还是比较好理解的，比如我要跟你说：”用户信息管理“应该具有哪些功能，那么你的第一反应肯定就是CURD， 是的，CURD对”用户信息管理“来说是一个不可分割的基本单元。

<2> 扩展： 相对”包含“来说，扩展算是基本功能单元的边缘功能，也就是说可有可无，关键在于”参与者“是否需要此功能。

4：子系统

正如它的名字一样，如果你的系统有很多子系统，或者说你的系统有很多功能模块，你想用类似“命名空间”的形式组织这些功能，那么此时“子系统”就非常适合，比如上图中的“用户信息管理“算是一个大的功能模块，此时我可以用”子系统“代替这个”用例“。

5： 项目，依赖项

<1> 项目： 刚才我们也说了，实际应用中用例图采用的是”图文相依“的形式，那么这里的项目就起到了“文”的作用。

<2>依赖项： 用例和项目之间的连线，我们采用的是”依赖项“的形式。

在“项目”中有一个Hyperlink属性，当我们点击右上角时，就可以顺利的进入我们设置的link链接文档。

序列图

一：用途

对一个开发团队来说，序列图是非常重要的，因为序列图用于描述系统内部一群对象之间的交互情况，尤其在做爬虫这种业务复杂性的项目，序列图可以让我们更快的理清这些复杂流程。

二：基本元素

序列图中的uml元素还是相对比较少的，先截个图。

1：生命线

首先我们要知道序列图有一种动静结合的特点，以类图作为静态结构，用例图作为动态行为的过程。所以我们可以认为生命线就是一个类，比如下图中，customer:Customer ，前者是类的实例，后者是类名，图中的“X”是类的析构函数，也就是销毁。

这里有一个注意的地方，我们将图中的”Actor“属性设为True是，该生命线就会变成参与者生命线。

2：同步,异步

说起同步或者异步，我想大家第一反应可能就是ajax或者Thread，既然序列图是描叙对象之间的交互就必然存在同步或者异步，在uml元素中，“同步”是具有来去箭头的，而”异步“就是单向箭头。

从上面的序列图中，我们可以看出Customer向Order下订单，下单成功后同时异步请求email发送邮件，既然是异步，也就不存在影响主流程了。

3：创建

在交互段内如果要创建别的生命线（类对象），那么此时需要使用创建消息，不过在实际应用中用的还是比较少的，毕竟万事万物遵循”八二原则“的。

在vs2010里面有支持序列图的”反向工程“，蛮有意思的，我们先看一下，我在Program里面实例化了一个Test类，看看在序列图中是否用Create来实现。

4：组合片段

现在我们也知道了，序列图中是一群对象在交互，那么交互必然存在着逻辑，比如if/else,for等等，在uml中有12中这样的业务逻辑的组合片段，同样八二原则，了解一些常用的即可。

通过对比两张图，我想大家肯定清楚下面的那张序列图所表达的意思。

最后上一张综合一点的图，有了上面的简述，我想这张图大家应该也能看得懂。

类图

一：用途

用于描述系统的静态结构，或许在所有的uml图中，类图是我们最熟悉不过的，在我们没有接触uml的时候，可能都看过类图，早在vs2005里面“解决方案资源管理器”的下边有一个“查看类图”的小图标，并且还能支持“正向“和”反向“工程。

<1>反向工程

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

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {

        }
    }

    /// 

    /// 用户类
    /// 
    public class User
    {
        public string Name { get; set; }

        public int Age { get; set; }

        public string Sex { get; set; }
    }

    /// 

    /// 产品类
    /// 
    public class Product
    {
        public string Name { get; set; }

        public DateTime CreateTime { get; set; }
    }
}

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

<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规范。