【UML总结】——用例图

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

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

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

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

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

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

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

用例图

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

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

1、用例

就是一个功能的描述。

用例图符：

2、角色

角色图符：

一说到角色会想到人是很正常的（我就是这样，所以我认为很正常），你可以这么想，但是要知道这不完全对。

这里的角色包括

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

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

3、系统边界

4、关系

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

那么角色和用例之间的关系自然也就只有这三种关系了：

角色——角色关系

角色实质上也是类，所以它拥有与类相同的关系描述，角色之间存在着泛化关系，其实就是继承关系，换了一个名字而已，但是我感觉不像“继承”那样容易理解。

大汽车和小汽车都有拥有汽车的属性，都继承了汽车

用例——用例关系

共性：多个有公共信息的用例，将那公共部分作为一个单独的用例，然后通过不同的方法来重用这个公共的用例，以减少模型维护的工作量。

在这里说太多的定义也不容易理解，用几个例子来表达一下，在尝试着多画几个就明白了

1）包含

使用包含用例来封装一组跨越多个用例的相似的动作（行为片段），以便多个基用例复用。基用例控制与包含用例的关系，以及被包含用例的事件流是否会插入到基用例的事件流中。基用例可以依赖包含关系用例执行的结果，但是双方都不能访问对方的属性。

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

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

2）扩展

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

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

结合例子看一下：

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

3）泛化

与上面讲到的泛化相同，而定义是：子用例和父用例相似，但表现出更特别的行为；子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为，也可以重载它。父用例通常是抽象的。在实际应用中很少使用泛化关系，子用例中的特殊行为都可以作为父用例中的备选流存在。

例：业务中可能存在许多需要部门领导审批的事情，但是领导审批的流程是很相似的，这时可以作为泛化关系表示。

角色——用例关系

1）依赖

上面的包含和扩展都是依赖关系的一种。

用带箭头的虚线连接有依赖关系的两个类，箭头指向独立的类。

2）关联

关联关系又包括三种关联关系，但是这里基本上只用到了普通关联。即用一条实线连接表示一种结构关系。

以上只是目前我结合视频笔记和查找资料之后的理解

就在总结这篇博客的时候我终于又有了一个新的理解，希望下一篇博客能引出我更多的思考