UML之用例图

什么是UML？

  UML是Unified MOdeling Language（统一建模语言）的简称。

1、UML是一种语言

2、UML是一种可视化语言

3、UML是一种适于详细描述的语言

4、UML是一种结构语言

5、UML是一种用于文档化的语言

用例图：

用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。简单地说就是谁使用这个系统做什么的。

图元素：

    1、参与者

          在系统之外与系统交互的某人或者事物。需要使用系统，实际上参与者是一个集合的概念

                   第一参与者是在系统之外，在系统之内的不是参与者；参与者与系统有明显的系统边界；

          例如：小红去银行开户，向大厅的经理询问办理手续，填写了表单，并交给柜台职员，拿到了银行存折。

         在这个例子中的参与者是谁？答案是小红，因为小红是在系统之外，在这大堂经理没有和系统交互所以不是，而柜台职员是系统之内的也不是参与者。

               再看一个案例：如图谁是参与者？？

         这个参与者是人工人员，在这里我们选择里系统最近的，选择离系统最近的作为参与者。

下面的例子也是这样：

在这里我们的参与者是呼叫中心，这个参与者不是人，而是一个系统呼叫中心。 

参与者与参与者的关系

      它们之间是泛化的关系（Generalization），其实就是继承关系，子参与者继承父参与者的行为和含义，还可以有自己的行为和含义。

比如 普通用户只能浏览网站上列的商品，而注册会员就可以购买操作和普通用户的所有操作，所以普通用户就是父参与者，注册会员就是子参与者

参与者和用例之间的关系：

       参与者和用例存在着一定的关系，这个关系就是关联关系，又可以称为通信关联，表明哪个参与者和用例通信。

2、用例

      定义：对一个活动者使用系统的一项功能时所进行的交互过程的一个文字序列。

     上面的定义难以理解，个人理解是，用例定义了一组用例实例，就是一件事情，要完成这件事情，需要做一系列的活动;而做一件事情可以有很多不同的方法和步骤，也可能会遇到各种各样。

注意：业务规则不是用例，就比如系统支持什么什么功能业务，这个不是用例，实际情况如下：输入三次密码错误就会吞掉卡（这个是系统的功能规则）

就比如：

用例不是简单的一小步（至少需要2~5步），不可以出现多人参与。

再比如图书馆里系统中，图书维护这个用例，图书维护（录入，修改，查询，删除）。

用例之间的关系

          泛化关系：

          在用例之间的泛化中，子用例继承父用例的行为和含义

 包含关系：

    就比如A到B的过程，中间需要在加入一个C

扩展关系：

       一个用例可以被定义为基用例的增量扩展、这叫做扩展关系。扩展关系箭头指向被扩展的用例 

在还书时，不是每一次都要罚款的，在基用例上插入附加的行为，基用例并不知道，在超出期限就会罚款（就像具备条件才可以）

用例之间的泛化、包含、扩展关系的比较

           相同点: 都是基本用例的行为的一部分。

          不同点: 在基本用例的每一次执行时，包含用例都会一定会执行的，扩展用例只是偶尔被执行。 

3、关系 

关系类型	功能	符号
关联	参与者与用例之间的通信
泛化	用例与用例之间的特殊关系 参与者之间的关系
包含	两个用例之间的关系 其中一个用例的行为包含另一个用例的行为
扩展	和包含的定义差不多，但是一个用例的某个行为发生才会执行另一个用例的行为（带有选择性的判断）

用例图给客户看，不需要画出包含、扩展的部分，画出这两部分是给设计人员看的