Creating Use Case Diagrams 创建用例图
目标
完成这一章节，你可以：
1、判断用例图需要什么。
2、定义和描述一个UML用例图的必要元素。
3、基于业务所有者的目标，为一个软件系统开发一个用例图。
4、基于所有利益相关者的目标，为一个软件系统开发一个精细的用例图。
5、使用UML继承、包含、泛化符号，识别和记录的依赖关系。
6、描述如何通过创建UML包视图，去管理用例图的复杂性。
//2016年8月23日22:55:07 新的一章开始了
证明使用的必要
1、一个用例图可以让你定义高级别的必须用来满足用户目标的功能需求。
2、客户端的利益相关者需要一个概括的系统视图。
3、用例从基础的详细的功能性需求开发而来。
4、用例可以标上优先级，然后按优先级开发。
5、用例通常有最小限度的依赖，所以用例允许一定程度的独立开发。
定义用例图的元素
一个用例图展示演员（角色）和他们想实现目标之间的关系。
演员
演员是:
1、一个角色的模型，在系统外部并且与系统交互
2、可以是人，设备，其他系统或者时间
3、可以是主要的，也可以是次要的
主要：启动和控制整个用例图
次要：仅参与部分用例图
用例
一个用例描述一个演员和系统之间的用以完成目标的交互。
1、一个用例封装了系统主要一段行为，且有一个明确的输出。
2、一个用例是通过一个椭圆来展现的。这个椭圆中间有用例的标题。
3、一个好的用例标题应该包括一个简洁的但不宽泛的共名称组合。
4、一个好的用例是与UI独立的。
系统边界
用例有可能选择性的被一个矩形包住，这个矩形代表系统边界。
用例的关联
A use case association represents “the participation of an actor
in a use case.” (UML v1.4 spec. page 357)
一个用例关联代表“用户在用例中的参与”----UML v1.4 spec. page 357
创建最初的用例图
此书主要用“旅馆系统”案例来讲解。
定义附加用例
通过业务所用者间的会议，你通常会发现系统需要的10%到20%的用例。
通过与利益相关者的会议，你会发现更多的用例标题。这些标题可以添加到
用例中。例如：
房间维护：创建、更改、删除
维护房间类型：创建、更改、删除
发现更多标题取决于开发进程（类型）。
在非迭代开发中，你需要一次性发现剩余所有的用例标题。但是这样很少完全精确。
在迭代开发中，你可以先发现80%的用例标题，剩下20%用例标题用20%的精力去完成，
以最小的精力完成剩下的。
//2016年9月6日22:41:32
用例精细化
在与利益相关者的会议中，你也可以发现高级别的用例。例如“预定经理”精细化。
扩展高级别用例
分析继承模式
继承可以出现在用例图，不论是演员还是用例
1、一个演员可以从父演员继承所有用例关联。
2、一个用例可以按子类方式拆分成多个，专业化的用例。
演员继承
例子：
用例专业化
例子：
//2016年9月7日23:21:17
分析用例依赖
一个用例可以以两种方式依赖其他用例：
1、一个用例包含其他用例
这表示一个用例需要其他用例的行为，并且总是表现包含其他用例
2、一个用例继承其他用例
这表示一个用例可以继承其他用例的行为。
包含关系<<include>>
1、通过定义和记录相同行为发现包含关系
2、通过定义的行为关联了其他次演员发现包含关系
发现次演员后：
继承（扩展）关系<<extend>>
继承依赖关系让你可以去定义不是系统主流程的行为，而是可选场景中的行为。
1、查找用例场景中的重要的和内聚的子过程的行为。
2、给这个行为创建一个名字，并使用<<extend>>关系放入用例图。
一个复合的例子
打包用例视图
当开发复杂软件时，用例过多，不能全部同时查看。
这个时候，就需要给用例打包。
总结
1、一个用例图提供了系统的大视角的可视化的呈现。
2、用例图呈现演员使用这个系统，用例为演员和演员到行为之间的关联，提供了一个有可定义目标的行为。
3、一个用例可以精细制作去展示系统。
4、一个用例可以精细制作去展示用例依赖，通过使用UML标记，如继承、包含、泛化
5、复杂的用例图（复数）可以用过打包分解成视图（复数）。
//2016年9月11日15:21:24
//联系我，邮箱：bourne_w@sina.com
交个朋友吧
//祝
自己早日找到更好的工作
799
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
