用例图是从用户的角度出发，描述系统功能的。在软件开发过程中，开发人员首先获知用户的需求，然后设计用例模型，在分析并设计系统来实现这些用例。在系统完成后，还要根据用例图来对系统进行验证。

         用例图主要介绍了一下部分：构成，描述和注意事项

         用例在需求分析阶段产生，那么，用例设计时地第一个问题就是这个软件的范围是什么，确定范围后，再去找出都有谁参与，都干些什么事。然后根据这些话出来用例图。

         首先是用例的构成：

         用例图包括用例、角色两个部分。角色之间又有一些关系。这就是用例图需要表现的东西。

         用例图的参与者。它可以是一个人，也可以是电脑部件，或者是其他系统。他们拥有系统中的角色，通过对应的角色可以使用相应的权限。但他却不属于系统，而是处在正在建模的系统的外部。

         用例图的参与者的确定有以下原则：

              1.      谁是主要客户

               2.      谁用系统完成工作

               3.      谁维护管理系统

               4.      系统的硬件设置

               5.      系统需要与那些其他系统交互

               6.      系统从何处获取信息

          系统的参与者确定后，根据参与者使用系统的次数确定谁是主要参与者，谁是次要参与者。（不是根据权限哦）

确定了系统的参与者后，需要考虑的是这些参与者都做一些什么样的工作。也就是说这些对象都具有什么方法。它有两种表示方法：一种是一个椭圆，把用例的名称写在椭圆内部，另一种表示方式是把用例的名称写在椭圆的外部，但是通常是吧用例的名称写在椭圆的外部。

          首先，参与者要与用例进行通话，这就是他们的关联关系；接下来就是用例和用例之间的关系了：

                  1.扩展：假如说张三同学去图书馆借一本书，那么，就会有一个借书的时间长度的限制，如果过期没有还书，图书馆的管理老师就会请他去喝茶。在这个事件中，张三的“过期没有还书”的信息作为条件触发了“老师请张三去喝茶”的事件。

这就是用例的扩展，用例“老师请张三去喝茶”是用例还书是否超过规定时间的扩展用例。他们之间是依赖的关系。

                   2.包含：张三同学去借书时，他需要先看看有没有这本书，然后才确定能不能借书。

张三同学的“借书”用例中，包含有“验证是否该书以借出”的用例。这就是包含关系。他们之间也是依赖关系。

                   3.泛化：张三同学去还书，发现还书处增加了电子还书的功能。老师可以手动输入张三的借书证号码，也可以通过扫描仪器来扫描张三的借书证而得到借书证号。

张三的还书中，登记借书借书证号的用例分成了手动输入和电子录入两种，这两种用例被称为子用例而登记借书证号是父用例。子用例继承父用例，这就是泛化关系。

            用例构成说完了，接下来就是用例的描述了。

            如何描述用例图呢？

            还是老规矩，先来一张图：

             用例也有标识，那就是用例的名称。张三每天给小丽打三个电话。

              在这个事件中，“打电话”用例需要先拨号，然后接通。这就是事物的流程，也就是事件流；在电话接通之前，会验证张三拨打的电话号码是否正确可以播出，这就是前置条件；电话接通后，双方处于可以通话的状态这就是后置条件；张三一天给小丽打三次电话中的“三次”就是使用频率。

              用例图使用的时候有一些注意事项：

             用例的粒度，用例图是不固定的，粒度可以设置的很大，也可以设置的很小，具体如何设计，还是要看设计人员的考虑。不过一般是从粗粒度到越来越细的去设置，当然粒度不是越细越好，而是合适就好。

            然后就是用例图的结构要合理。这包括用例内部的结构要合理和用例之间的结构设计要合理。

uml系列（三）——用例图