UML用例图

UML用例图

基本概述

    用例图(Use Case Diagram)是用于描述某某角色通过某某系统能做什么事情。当需要对系统整体或者某一部分功能进行行为建模时，就能够使用用例图了。

 

用例图

基本语法

解释：

1、主角表示执行者(Actor)，其表示的是与当前系统交互交互的人或者其他系统。

2、用例能够表示系统能够为执行者提供什么功能。

3、用例是以动词加名词的形式，也就是动宾结构。

4、外边框表示系统边界，要注明是什么系统，外边框可以不画，个人建议画上比较清晰。

5、线条有三种：无箭头的，指向用例的箭头，指向执行者的箭头。

6、箭头可以有两种解释：

    1、数据流向

        箭头指向用例，说明向系统输入数据。箭头指向执行者，说明系统输出数据。

    2、谁启动谁

        箭头指向用例，说明启动系统中某一模块。箭头指向执行者，说明系统启动另一系统。

进阶语法

解释：

1、执行者之间只有一种关系，那就是泛化关系。

2、用例之间有三种关系。

3、include关系，表示用例4有用例5的功能，也就是有。。。功能。

4、extend关系，表示在用例6的基础上用例7有什么功能，也就是在。。。基础上。

5、继承关系，表示用例9继承抽象用例8什么功能，抽象用例是不能被实例化的。

 

案例：

用例的粒度控制

1、在客户能准确全面理解的基础上，用例越精简越好。

2、用例应使用客户的语言，也就是领域语言，需保证客户能看懂能理解，而不应处于开发人员的角度来描述。

3、全面并且有重点地表达好用例，对于重点难点用例应详细描述，对于常识型用例则不需要太多笔墨。

4、可以通过include和extend分解和细化用例，最底层的用例粒度应大体一致，注意这点应该灵活把握，不应僵化。

5、应当立于客户想法，但又高于客户的想法。

6、不应盲目地从客户的想法中直接导出用例，用例更多地是从系统的目标、待解决的客户问题而推到出来的。

7、用例图不是万能的，所以有时也可以结合用例表来描述需求，甚至有时候也可以不用用例图来描述需求。

 

案例：

用例表

    光是用例图，很难说清楚每个用例，这时，可以借助用例表来详细说明用例。不过一般也填写重要用例的用例表就行了，没必要把每个用例都做成用例表。

 

解释：

编号：指用例的编号，通常格式是UC+数字。

名称：用例的名称，可以直接使用用例图中用例的名称。

执行者：发动该用例的人或系统，如果是多个执行者发动，都写入。

优先级：最基本的、最重要的、需要先实现的用例优先级应该标识位高。

描述：对用例的简单描述，简单说明执行者能够做什么事情、达到怎样的效果。

前置条件：要发动该用例，需要先满足的其他用例或者条件。

基本流程：

1、书写格式

    1、以阿拉伯数字编号。

    2、执行者的操作顶头写。

    3、系统的操作空两格写。

2、基本流程是用例表中最关键的信息，在这里要思考用户与系统是如何交互的，需要注意以下几点：

    1、要用比较高层次的语言来表达，不要明确写出实现方法。

    2、系统与用户的交互要符合用户的使用习惯，尽量减少交互次数，尽量减少信息输入量。

结束状况：用例正常结束情况下，系统会有什么效果。

可选流程：在基本流程的基础上，某些步骤可能是有分支的，这时可用可选流程，当流程不止一个时，可用多个可选流程。

异常流程：系统应该怎么处理用例的某些基础条件不满足而导致发生异常，或是发生了一些特殊情况。

说明：写入业务信息。

 

案例

编号	2.1	名称	提出请假申请
执行者	普通员工	优先级	高■低口
描述	普通员工录入请假的信息, 能成功提出请假申请
前置条件	无
基本流程	l.指示提出请假申请。     2.显示请假申请表单。 3.填写申请单,选择请假类别。 4.指示提交申请。     5.显示成功提交申请的信息。
结束状况	系统保存请假申请数据,并提示成功提交申请的信息。
可选流程1	4.指示取消申请。 5.显示申请被取消的信息。
异常流程	3..显示申请被取消的信息。 4.指示提交申请。 5.发现可休年假不足,显示相应提示，并向用户显示相应通知。 6.修改请假申请单,或取消请假申请。
说明	请假申请单有以下内容:申请者、开始时间、结束时间、请假事由、请假类别。 申请者默认为当前的用户, 不可修改。 申请者默认为当前的用户, 不可修改。 类别为:事假、病假、婚嫁、产假、年假,只能而且必须选其一 请假时间不能超过年假时间