关闭

【UML总结】——用例图

646人阅读 评论(19) 收藏 举报
分类:

       前面几篇关于UML的博客几乎都是看视频的笔记,然后稍稍修改了一些,略微插了一点资料就那么誊写在了博客上,然后就被师姐给劈头盖脸一顿说(虽然是我自己讨的)。


本来是想看完视频就写图的总结的,但是就这么被放下了


画完图的现在对笔记的理解就是:那些个笔记就好像是在糊弄鬼

我也不知道是什么记的,对之后的画图并没有什么帮助。


对于UML图的分类在不同的书本中有着不同的分类方法

但是归根结底也就是这10种图

用例图、类图、对象图、包图、序列图、协作图、活动图、状态图、部署图、构件图。


用例图

总的来说用例图就是用来描述系统功能的一个图。

由角色、用例、系统边界、关系组成。

1、用例
就是一个功能的描述。
用例图符:

2、角色
角色图符:
一说到角色会想到人是很正常的(我就是这样,所以我认为很正常),你可以这么想,但是要知道这不完全对。

这里的角色包括

1)直接使用系统的人 2)系统涉及到的维护人员 3)系统使用的外设 4)需要和系统相连接的其他系统

不需要记住,看一眼下次画的时候知道来这里看一下就好了(因为我确实记不住,所以我就这样安慰自己,能怎样♪(^∇^*))

3、系统边界

4、关系
这里的关系就和系统边界没有什么关系了。

那么角色和用例之间的关系自然也就只有这三种关系了:
角色——角色关系
角色实质上也是类,所以它拥有与类相同的关系描述,角色之间存在着泛化关系,其实就是继承关系,换了一个名字而已,但是我感觉不像“继承”那样容易理解。

大汽车和小汽车都有拥有汽车的属性,都继承了汽车
用例——用例关系
共性:多个有公共信息的用例,将那公共部分作为一个单独的用例,然后通过不同的方法来重用这个公共的用例,以减少模型维护的工作量。
在这里说太多的定义也不容易理解,用几个例子来表达一下,在尝试着多画几个就明白了
1)包含
使用包含用例来封装一组跨越多个用例的相似的动作(行为片段),以便多个基用例复用。基用例控制与包含用例的关系,以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含关系用例执行的结果,但是双方都不能访问对方的属性。

可根据下面的图来理解一下,不能理解也不要紧,看过一遍就好了。

例:业务中,总是存在着维护某某信息的功能,如果将它作为一个用例,那新建、编辑、以及修改都要在用例详述中描述,过于复杂;如果分成新建用例、编辑用例和删除用例,则划分太细。这时包含关系可以用来理清关系。


2)扩展
将基用例中一段相对独立并且可选的动作,用扩展用例加以封装,再让它从基用例中声明的扩展点上进行扩展,从而使基用例行为更简练和目标更集中。扩展用例为基用例添加新的行为。扩展用例可以访问基用例的属性,因此他能根据基用例中扩展点的当前状态来判断是否可以执行自己。但是扩展用例对基用例不可见。

可以根据下面的图来理解一下上面的话。

结合例子看一下:
系统中允许用户对查询的结果进行导出、打印。对于查询而言,能不能导出、打印,查询都是一样的,导出、打印是不可见的。导出、打印和查询相对独立,而且为查询添加新行为。因此可以采用扩展关系来描述。


3)泛化
与上面讲到的泛化相同,而定义是:子用例和父用例相似,但表现出更特别的行为;子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。
例:业务中可能存在许多需要部门领导审批的事情,但是领导审批的流程是很相似的,这时可以作为泛化关系表示。

角色——用例关系
1)依赖
上面的包含和扩展都是依赖关系的一种。
用带箭头的虚线连接有依赖关系的两个类,箭头指向独立的类。
2)关联
关联关系又包括三种关联关系,但是这里基本上只用到了普通关联。即用一条实线连接表示一种结构关系。

以上只是目前我结合视频笔记和查找资料之后的理解
就在总结这篇博客的时候我终于又有了一个新的理解,希望下一篇博客能引出我更多的思考
3
1

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:56735次
    • 积分:4991
    • 等级:
    • 排名:第5623名
    • 原创:74篇
    • 转载:0篇
    • 译文:0篇
    • 评论:1565条