UML核心元素！通俗易懂，你不可以错过！

一.参与者：

1.基本概念：actor是在系统之外与系统交互的某人或某事物。如下图所示：清晰的展现了上述定义的关键点。

    我们的目标系统在边界之内，系统之外的定义说明参与者与系统之间有一个明确的边界，参与者必须在边界之外，在边界内的无论人还是事物都不是参与者。所以一谈到参与者，我们必须想到系统边界的存在，否则我们的参与者就得在商榷一下了。

1.1参与者可以非人

    在我们实际的建模时，我们可能会遇到这样一个问题，我们一些需求没有人参与，那么参与者从何而来呢？其实很简单：这样一个需求：每天自动统计网页的访问量，生成统计报表，并发送至管理员邮箱。

    那这种情况，从物理学考虑，我们都知道，在没有“外力”的情况下，物体保持静止或匀速直线运动，这里我们同样可以运用与我们的计算机系统，在没有外力的情况下，系统将保持等待或循环任务状态，所以如果没有一个启动者，那么可以肯定这不是一个功能性需求。

     回到刚刚的问题上，我们的需求是每天自动统计访问量，所以说这个需求的启动者，也就是参与者显然就是一个计时器，每天在某一个固定的时刻启动这个需求。

1.2边界之外

    在刚刚的图中，我们很明确的看到，参与者是位于系统边界之外的，那么我们怎么确定一个系统的边界呢，或者我们从来就没有考虑过这个问题呢？

    比如：小A到银行去开户，像大厅经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折，在这个场景中，谁是参与者？

    所以要想弄清楚谁是参与者，我们必不可少的要明白系统的边界，如果我们不是很清楚怎么确定系统的边界，那么可以通过一些两个问题来确定：

1谁对系统有明确的目标和要求并主动发出动作？

2.系统是为谁服务的？

   显然在这个场景中，第一个问题的答案是，小A有着明确的目标，开户，并主动发出了动作。第二个问题的答案是：系统运行的结果是给小A提供了开户的服务。所以这样看来参与者即为小A。而其他的人员：大厅经理，柜台职员只能属于业务工人，作为配角，来完成主角的业务目标。

 

二.用例

在我们UML建模中，用例可谓是大名鼎鼎的，说他重要，主要是因为，UML是面向对象的，都是封装起来的，如果木有外力，那这些元素则完全是老四不像往来！而我们的用例正是施加这一外力的元素，作用老大了。

1.基本概念：用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值（官方定义）。

    举个实例：比如你想要做一顿饭吃，你需要完成煮饭和炒菜两件事情，这两件事情就是两个用例，而你启动用例是有条件的，要做饭，首先得有米。这就是启动用例的前提，也称为前置条件，用例执行完了，会有一个结果，米变成了饭，这称为后置条件。所以这么说来，一个完整的用例定义由参与者/前置条件/场景/后置条件构成。如下图所示：

2.特征：用例是有一些特征的，这些特征能够保证用例能够正确的捕捉功能性需求。

         2.1.用例是独立的。这表示它不需要与其他用例交互而独自完成参与者的目的，例如人取钱是一个用例，而填写取款单却不是，因为我们的目的就是取到钱，么有人会为了填单子跑一趟银行。

         2.2.用例的执行结果对参与者来说是可观测和有意义的。比如，用户登录系统是用例，而输入密码却不是，因为，登录系统对于用户-参与者是有意义的，而单纯的输入密码却是没有意义的。

          2.3.不存在没有参与者的用例。

          2.4.用例必然是以动宾短语形式出现的。比如喝水可以是用例，而“喝”和“水”却不是。但是      在我们实际情况中，很多以“计算”“统计”之类的命名。所以以后在判断是否是一个有效的用例时，可以用这种方法。

3.粒度，说到粒度，大家就比较头疼了，比如在ATM取钱的场景中，取钱/读卡/验证账号/打印回执单等都是可能的用例，但显然取钱包含了后续的其他用例，他的粒度更大一点。所以一个项目中到底分多大的用例合适呢。

     这里给出的建议就是，我们可以以用例是否完成了参与者的某个完整目的为依据这样来判断。但是实际情况中，一个几十人两年的大型项目和几个人的两个月的小项目的用例粒度的选择会有较大差异。但是我们需要把握的原则就是，在同一个需求阶段，所有用例的力度应该是同一个量级的。比如介绍一栋建筑，如果你说这栋楼有10层，预留了18个插座，共有6个5个单元，下水道在厨房东北角，听众一定会觉得云里雾里的，所以正常情况下我们总是把高度/层数/单元数放到一起，而把插座数量/下水道位置放到一起。就是这个道理。

4.用例和功能的误区

    用例讲到这里，大家一定会有一个误区，就是认为用例就是功能的划分和描述，每一个用例就是一个功能点。所以虽然在之前概念讲到用例是捕获功能性需求的，但是有一个前提条件那就是这个需求是参与者的角度出发的，用例并不是功能。以一个实例来讲，大家就会很明白了。

    例：描述一辆自行车，我们通常可以这样说明：第一，自行车是一种交通工具，有传动系统/刹车系统等部分组成；二，自行车可以骑行，可以载物；三，人们可以用脚蹬动踏板而向前前进，可以用手刹车使自行车停下来。如图所示：

    第一种：从结构描述，即事物的客观描述，不能说明事物的作用，比如一个圆环，用在汽车上，除了轮胎还可能是方向盘，用在自行车上只能是轮子。所以仅有结构性观点是不够的。

    第二种：是功能描述，即事物的可利用价值，但是没有人的价值确是没有意义的。

    第三种：从使用者描述，说明事物对使用者的意义，就是使用者可以怎么使用，然后得到什么样的服务。

    所以综上所述，从使用者的角度是非常合适的，从使用者的角度在需求阶段告诉开发人员他希望的系统是什么样的，他将要怎么样使用这个系统，希望获得什么结果。所以这样开发人员就会按照使用者的要求完成系统，就不会偏离使用者的预期。所以用例不仅仅是功能的描述。！

三.边界

在讲第一个元素-参与者的时候就反复提到了边界这个词，其实在我们开始UML的学习时，就强调了面向对象这一重要概念，在面向对象里，任何一个对象都有一个边界，外界只能通过这个边界来认识对象，与对象交互。在确定需求的时候，我们总是会先设想一个边界，这时这个边界是不确定的，随着需求的明确边界也在逐步明朗，但是分析需求，我们离不开的是参与者和用例，可以参与者和用例的确定恰恰后与边界的，哦！这样就产生了一对矛盾，可以这也恰好证明了需求过程是一个动态的过程，不是一蹴而就，因此统一过程需要迭代，而不能采用瀑布方法。

四.关系

点击如下博文，有详细介绍：

http://blog.csdn.net/guolimin1992/article/details/19291925

五.组件

对于组件，我还理解的不是很好，根据UML的解释，定义为任何逻辑代码模块，也就是几个类一组合就是一个组件。组件之间的唯一关系就是依赖，既然有依赖，那就说明一个组件的修改会导致依赖于它的其他组件的修改。所以这样看来，一个组件应当是一个独立的模块，有完整的功能，可以独立部署。

有了基本元素，在下一篇博文中，我会详细介绍由这些元素组合起来，构造出我们非常重要的九种图。