【前言】
学习UML也有一个月了,仔细的学习了一下UML的9种图,今天让我来给说一说用例图
【内容】
一、用例图
1、用例图:用来描述用户的需求
2、用例图的基本元素:
(1)用例:就是功能的描述
(2)角色:一种人员的角色,用来指明这个用例跟哪一个角色相关
(3)关系:指明用例和执行者之间的关系
3、用例图中间的关系:依赖关系、泛化关系、关联关系
4、用例的主要属性:
5、用例的注意点:
(1)应该清晰的定义系统边界
(2) 防止用例过多
(3)应该从执行者的角度来命名用例
(4)用例描述正规程度
(5)避免执行者的名字不一致
(6)避免执行者和用例之间的关系太复杂
(7)注意用例的大小是否恰当
(8)避免用例描述混乱
(9)区分用例分解和功能分解
(10)避免客户不能理解用例的情况发生
(11)有些场合用用例来描述需求是不合适的
二、用例图中依赖关系中include与extend的区别
include是指用例中的包含关系,通常发生在多个用例中,有可以提取出来的公共部分,而extend则恰好相反。 include是指用例中的包含关系,通常发生在多个用例中,有可以提取出来的公共部分(就象提取公因式一样),例如UseCaseA中包括了a和b两个流程,而UseCaseC中包含了c和b两个流程。为了提高复用性,可以把b提取出来,形成另一个用例UseCaseB,此时,UseCaseAincludeUseCaseB(表现为一条指向UseCaseB的虚线,箭头在UseCaseB侧),UseCaseC也includeUseCaseB。因而,当有include关系时,被include的用例通常会有两个以上的其他用例include(否则就不需要重用,也就不需要提取出来了), 在include关系中,“UseCaseA和UseCaseC知道UseCaseB的存在,而UseCaseB根本不知道有UseCaseA和UseCaseC; UML用例图如 下:
extend则恰好相反。假设UseCaseA的功能描述为“发送一条通知”,可是,发送通知的方式可能有许多种,例如通过邮件发送、通过短信发送等。在需求分析阶段,可能无法明确到底有多少种方式,在用例分析阶段,UseCaseA需要留出扩展接口,然后把已知的发送方式作为扩展用例给出,例如UseCaseB是“通过短信发送”,而UseCaseC是“通过邮件发送”,此时,UseCaseB和UseCaseCextend了UseCaseA,表现为两根虚线,箭头指向UseCaseA。在extend关系中,UseCaseA不知道UseCaseB和UseCaseC的存在,但UseCaseB和UseCaseC却是知道UseCaseA并且知道如何在UseCaseA中作扩展的。UML用例图如下:
三、机房收费系统 用例图
这是自己画的用例图 ,第一次画觉得还是有点不好,以后多多改进吧,欢迎大神们的指点.
[总结]
剩下的UML图欢迎大家继续跟下去。。。