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.修改请假申请单,或取消请假申请。 | ||
说明 | 请假申请单有以下内容:申请者、开始时间、结束时间、请假事由、请假类别。 申请者默认为当前的用户, 不可修改。 申请者默认为当前的用户, 不可修改。 类别为:事假、病假、婚嫁、产假、年假,只能而且必须选其一 请假时间不能超过年假时间 |