UMl——用例图

     前言：学习了Uml之后没能及时总结，总是想着一次性将那种高大上的博客，想法碰上激情也许是不错的，对于患有严重拖延症的我最后还是决定先至少整理出来，思维的火花我相信能够碰撞出来。

1、  用例图的概念

是什么

       是参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图。需求分析的产物

做什么

      系统用户、系统分析员、系统设计员以及领域专家都可以借助于用例图以可视化的方式对问题进行探讨以解决问题

有什么

       1）  参与者

       是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类的外部实体的抽象

       如何辨别？

       系统开发出来后，使用系统主要功能的是谁

       谁需要借助系统来完成工作

       从哪获得数据以及为谁提供数据

       与那些系统和有交互

       有谁来进行维护

       2）  用例

       是参与者可以感受到的系统服务或功能单元，定义了系统是如何被参与者使用，描述了参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

       特征？

       用例表明的也是一个类，而不是某个具体实例

       用例必须由某个参与者触发激活后才能执行

       用例是一个完整的描述

 

2、  小解用例

如何识别

       参与者是否会将外部的某些事件通知给系统以及系统中的事件是否通知参与者

       是否存在影响系统的外部事件

       参与者希望提供什么功能

       参与者是否会增删改查系统的某种信息

用例粒度

       是指用例所包含的系统服务或功能单元的多少

  

规约

        就是详细说明每一个用例是做什么的，每一个用例规约基本由以下内容组成：

        简要说明：对用例作用和目的的简要描述

        事件流：1）基本流：“正常”运行时的场景2）备选流：可能发生的异常或者偶                         有发生的场景

        用例场景：同一个用例在实际执行的时候会有很多不同的情况发生，称之为用                             例场景。和覆盖测试挺像的

        特殊需求：指的是一个用例的非功能性需求和设计约束

        前置条件：执行用例之前系统必须所处的状态

        后置条件：用例执行完毕后系统可能处于的一组状态

关系

        1）  泛化关系

        一个父用例可以被特化成多个子用例，而父用例和子用例之间的关系就是泛化关系。空三角箭头从子用例指向父用例来表示

        2）  扩展关系

        在一定条件下，把新的行为加入到已有的用例中，获得的新用例叫做扩展用例原有的用例叫做基础用例，从扩展用例到基础用例的关系就是扩展关系。用虚线箭头从扩展用例指向基础用例

如何用？

        用来处理异常或者构建灵活的系统框架，可以降低系统的复杂度，有利于拓展提高系统性能。

        例如：QQ登录时会进行验证，这便是基础用例，如果想修改密码如果在基础用例中改便会很复杂，所以只需进行一个密码修改的用例就可以了

        3）  包含关系

       是指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分，代表着基础用例会用到被包含的用例

3、  绘制用例图

 

          知道这些小图标代表什么剩下的就So easy了。 

       小结：通过总结主要知道了用例图的作用理解成需求操作的可视化显示，用例图的构成有参与者和用例以及两个要素之间各自有什么样的关系，用例图的绘制时如何分析应先确定需求，在识别参与者和用例最后是构建模型。比较容易混乱的是用例的三种关系及扩展、包含以及泛化，值得好好梳理一下，才能构建出最佳的模型