学习UML图形
推荐阅读<UML参考手册>第2版. http://www.umlchina.com/
推荐微软的开发软件设计模型 http://msdn.microsoft.com/zh-cn/library/dd409436.aspx
另推荐这篇文章 UML用例图总结 http://kb.cnblogs.com/page/129491/
用例图主要用来描述用户, 需求, 系统功能单元之间的关系.
〇 概述
用例图可使用的工具集(EA工具箱)有:
一 用例图元素
1. 参与者
Actor, 图形表示为一个小人, 参与者的版型(StereoType)有:
1) 普通参与者, 表示为一个小人, 如图Actor1
2) 业务参与者(业务工人), 表示为一个小人+头上一条斜线, 如图Actor2
3) 其他参与者, 表示为一个小人+书名号包含的具体版型, 如图Actor3, 4, 5 ...
参与者的表示就是个小人, 不论上面是否多了一斜线, 还是多了一对书名号, 仍代表参与者, 他们都只是参与者的一个具体的版型.
[注1] 所谓的版型(StereoType)是一种特例, 不管是五香瓜子还是原味瓜子都叫瓜子. 可以简单的认为, 使用版型只是为了描述更具体!
[注2] 加了删除线的"普通"两字实际并不存在, 只是为了描述清楚, 没有普通参与者的说法, 就叫参与者. (下同)
[注3] 其他参与者中的其他是泛指, 表示除以上之外的参与者. (下同)
2. 用例
Use case, 图形表示为一个带有实线边框的椭圆, 用例的版型(StereoType)有:
1) 普通用例, 表示为一个椭圆, 如图Use Case 1
2) 测试用例, 表示为一个椭圆+叉号, 如图Test Case 1
3) 业务用例, 表示为一个椭圆+一条斜线, 如图Use Case 2
4) 其它用例, 表示为一个椭圆+书名号包含的具体版型, 如图Use Case 3
[注4] 注意用例与业务用例的区别, 用例是系统用例的简称. 另外, 业务用例的范围一般大于用例(系统用例).
3. 协作(也称用例实现)
Collaboration, 图形表示为一个带有虚线线边框的椭圆, 协作的版型(StereoType)有:
1) 普通协作, 表示为一个虚线边框的椭圆, 如图Collaboration 1
2) 业务协作, 表示为一个虚线边框的椭圆+一条斜线, 如图Collaboration 2
[注5] UML2.x已经取消协作图, 定义为通信图(Communication Diagram), 但仍保留协作.
4. 边界(子系统)
Boundary, 图形表示为一个空心矩形, 边界没有其它版型(StereoType)
[注6] 如果在用例图上看到如虚线边框的空心矩形或其他线形, 均指边界, 和实线空心矩形没有区别.
5 关系
Relationships, 图形表示为一条线(实线或虚线)[+单向或双向的空心或实心箭头], 关系的种类有:
1) 关联, association, 表示为一条实线[+单向或双向开口箭头], 如图客户和订单直接属于关联关系
2) 包含, include, 表示为一条虚线+单向的开口箭头+书名号包含的include字样, 如图订单和付款属于包含关系(订单包含付款, 付款被订单包含)
3) 扩展, extern, 表示为一条虚线+单向的开口箭头+书名号包含的extern字样, 如图订单和请求商品目录属于扩展关系(请求商品目录是订单的扩展)
4) 泛化, generalization, 表示为一条实线+单向空心箭头, 如图使用现金支付是付款的实现
[注7] 泛化不是实现(inheritance), 泛化是指继承; 实现是类图中的元素, 实现的父类必须是接口.
5) 依赖, dependency, 表示为一条虚线+单向或双向空心箭头
如图, 使用信用卡支付依赖Pos机.
[注8] 在关系上, 使用信用卡支付依赖Pos机是没有问题的, 但是Pos机显然不能作为一个用例而存在(用例必须以动宾形式存在), 因此, 使用依赖和其它关系时需谨慎.
6) 其它, 如 invoke, trace ... 同类图中描述, 同样存在以上注意事项, 不推荐.
[注9] UML手册中除了关联, 包含, 扩展和泛化关系, 不存在其它关系的介绍, dependency, invoke, trace ... 这些在某些建模工具中存在(如EA, Visual Studio).
6. 包
Package, 图形表示为一个文件夹, 包的版型(StereoType)有:
1) 普通包, 表示为一个文件夹, 如图Package1和Package4
2) 其它包, 表示为一个文件夹+书名号包含的具体版型或特殊符号, 如图Package2和Package3
[注10] 用例图上的包一般引用自包图, 包图内部的画法, 参见包图部分.
7. Artifact (制品/物件/项目 翻译不明 属于UML2.x图形的一种)
Artifact, 图形表示为一个实心矩形, Artifact的版型(StereoType)有:
1) 普通Artifact, 表示为一个实心矩形+Icon, 如图Artifact1
2) 其它Artifact, 表示为一个实心矩形+Icon+书名号包含的具体版型, 如图UserStory1
[注11] Artifact的画法和Artifact图一致, 参见Artifact图部分.
Artifact是软件开发过程中的产物, 包括过程模型(比如用例图, 设计图等等), 源代码, 可执行程序, 设计文档, 测试报告, 需求原型, 用户手册等等.
二 用例图关系
1. 关联
执行者与用例之间的通信路径.
2. 包含
一个用例可以简单地包含其他用例具有的行为, 并把它所包含的用例行为作为自身行为的片段, 这种关系称为包含关系.
被包含的用例不是原用例的特化, 并不能替代原用例.
包含关系指向被包含的用例.
3. 扩展
一个用例可以被定义为基用例的增量扩展, 这叫做扩展关系.
同一个基用例的几个扩展用例, 可以在一起应用.
基用例的扩展增加了基用例的语义, 实例化时是实例化基用例而不是扩展用例.
扩展关系指向被扩展的用例.
4. 泛化
一个用例可以被特别细化为一个或多个子用例, 这被称作用例泛化.
任何子用例都可以用于其父用例能够应用的场合.
用例泛化和其他泛化的表示法相同, 用一个三角箭头从子用例指向父用例.
三 执行者和用例
1. 执行者
执行者是与系统, 子系统或类发生交互作用的外部用户, 进程或其他系统的理想化角色.
2. 用例
[注12] 协作是用例的实现
四 用例图总结
1. 用例图主要是用于描述需求的
2. 用例图包含的元素中, 只有参与者, 用例, 协作, 边界和关系属于特有的, 包和Artifact的画法直接使用对应的包图和Artifact图画法
3. 用例是指系统用例, 业务用例的范围一般大于系统用例
4. 用例的几个特性
1) 用例是相对独立的, 不需要与其它用例交互而独自完成参与者的目的.
2) 用例必须由一个参与者发起, 不存在没有参与者的用例, 用例也不应该自己启动.
3) 用例不是功能也不是特性，用例不能被逐层分解为更小的用例, 用例的价值在于展现系统最终能帮用户做什么以及如何做到的.
4) 用例必须以动宾形式描述, 如前文描述的"使用信用卡付款"是合法的用例, "Pos机"是非法用例.
5) 用例不是需求的唯一定义形式, 需要用例和其他定义形式一起定义完整的需求.
5. 用例的划分粒度没有标准, 一般是以该用例是否完成了参与者的目的为依据
五 UML通用元素
参见UML参考手册中的特性描述部分, 如一些注释元素, 不单只能画到用例图中, 而是通用的可以画到任何UML图形上的.
如图边界右上角的注释元素
相关链接:
UML 结构图之包图 总结 http://www.cnblogs.com/snowyying/p/UML_Package.html