UML基础（二）--用例图

一、用例和用例图

1.用例的概念

       用例模型的基本组成有用例、角色和系统。用例用于从用户角度描述系统的功能。用户不仅可以是操作员，还可以是其它系统或硬件设备。

2.使用用例的目的

1. 明确系统应具备什么功能，这些功能是否满足客户的需求，与开发人员达成一致。
2. 用例模型应用于系统开发的整个过程，为后阶段的系统设计和开发工作打下良好基础。
3. 为测试打下基础，验证最终实现的系统是否符号合客户的最初需求。
4. 便于从需求用例出发，跟踪系统的具体类和方法。之后的拓展先修改用例图再修改实际代码。

3.用例图

       显示用例与其参与者之间关系的图。

4.用例图的组成

1. 参与者：角色
2. 系统边界：确定系统的范围
3. 用例：代表系统提供的服务
4. 关联：参与者与用例之间的关系

参与者

       参与者也要考虑继承关系，如图书管理系统，读者做为参与者，但它又可以分为学生和老师。

       参与者要考虑权限，如管理员和普通的操作员。

用例

       需求获取是需求分析阶段的主体部分，主要工作就是建立待开发系统的模型，而用例就是建立这种模型的最好方法。

       UML的用例用椭圆形表示。

用例描述

       文档性的说明

       一般性图示：

二、用例之间的关系

包含关系

       基本用例会用到包含用例，即重用包含用例的步骤，如图：

扩展关系

       表示在特定条件（如例外条件）才执行的分支。表示一组在基本用例扩展点插入的行为，所插入的行为和顺序取决于执行基本用例时与主角的交互。如图：当新增用户时，若用户所属的网点不存在时，需要先新增网点。

泛化关系

       一般与特殊的关系，多个用例具有类似的结构和行为时，将共性抽象为父用例，其它用例作为泛化关系的子用例。

分组关系

       对需求进行分类，把相关的需求放在同个包中。

三、如何用例图建模

1. 识别系统中的角色和用例

       角色的识别源于用户的沟通，包含：
          a. 谁来使用？
          b. 谁负责维护管理？
          c. 系统需要处理哪些硬件设备？
          d. 哪些外围系统来调用？
          e. 谁对系统的运行结果感性趣？
       对角色逐一分析，获得所有的用例：
          a. 每个角色执行的操作有哪些？
          b. 该角色是否改变系统的信息，对应的操作用例？

2. 区分用例之间的先后顺序

3. 创建用例图模型结构

       复杂的系统可能需要按子系统细分。