目录
1、组成结构
2、表示法
3、一般用法
3.1、对主题的语境建模
3.2、对主题的需求建模
4、常用建模技术
4.1、对系统的语境建模
4.1.1、设计过程
4.2、对系统的需求建模
4.2.1、设计过程：
5、正向工程
UML 中的用例图是对系统的动态方面建模的 5 种图之一（对系统的动态方面建模的其他 4种图是活动图、状态图、顺序图和通信图） 。用例图是对系统、子系统或类的行为进行建模的核心。每张图都显示一组用例、参与者以及它们之间的关系。
用例图对可视化、详述和文档化一个元素的行为是很重要的，它们通过呈现元素在语境中如何被使用的外部视图，使系统、子系统和类易于探讨和理解。另外，用例图对通过正向工程来测试可执行的系统和通过逆向工程来理解可执行的系统也是很重要的。
1、组成结构
主题、用况、参与者；
依赖、泛化以及关联关系；
与所有其他图一样，用况图可以包含注解和约束；
用况图还可以含有包，用来将模型中的元素组合成更大的组块。
偶尔，尤其是要把一个特殊的执行系统可视化时，还可以把用况的实例放到图中。
2、表示法
把主题表示为一个矩形（用例边界），其中包含一组表示用况的椭圆，主题的名字标在矩形内。
用人形图表示参与者，放在矩形外面，名字放在其图符的下方。
从参与者图符到与之通信的用况椭圆之间用线条连接。
用况之间的关系（如延伸和包含）画在矩形之内。
3、一般用法
3.1、对主题的语境建模
对一个主题的语境建模，包括围绕整个系统画一个框，并声明有哪些参与者位于系统之外并与它进行交互。在这里，用况图说明了参与者以及他们所扮演的角色的含义
3.2、对主题的需求建模
对一个主题的需求进行建模，包括说明这个主题应该做什么（从主题外部的视点来看），而不考虑主题应该怎样做。在这里，用况图说明了主题所希望的行为。在这种方式下，用况图使我们把整个主题看作一个黑盒子；可以观察到主题外部有什么，主题对那些外部事物的反应，但却看不到主题内部是如何工作的。
4、常用建模技术
4.1、对系统的语境建模
所强调的是围绕在系统周围的参与者。决定什么作为参与者是重要的，因为这样做说明了与系统进行交互的一类事物。决定什么不作为参与者也同样重要，甚至更为重要，因为它限定了系统的环境，使之只包含那些在系统的生命周期中所必需的参与者
4.1.1、设计过程
- 决定哪些行为是系统的一部分以及哪些行为是由外部实体所执行的，以此识别系统边界。这也同时定义了主题。
- 考虑以下几组事物来识别系统周围的参与者：需要从系统中得到帮助以完成其任务的组；执行系统的功能时所需要的组；与外部硬件或其他软件系统进行交互的组；为了管理和维护而执行某些辅助功能的组。
- 将彼此类似的参与者组织成一般——特殊层次结构。
- 在需要加深理解的地方，为每个参与者提供一个衍型。
- 将这些参与者放入用况图中，并说明从每个参与者到系统的用况之间的通信路径。
上图显示了一个信用卡验证系统的语境，它强调围绕在系统周围的参与者。其中有顾客（Customer），分为两类：个人顾客（Individual customer）和团体顾客（Corporate customer）。这些参与者是人与系统交互时所扮演的角色。在这个语境中，还有表示其他机构的参与者，如零售机构（Retail institution）（顾客通过该机构刷卡，购买商品或服务）、主办财务机构（Sponsoring financial institution）（负责信用卡账户的结算服务）。在现实世界中，后两个参与者本身就可能是一个软件密集型系统。
4.2、对系统的需求建模
需求是系统的设计特征、特性或行为。陈述系统的需求，相当于陈述系统外部的事物与系统之间建立的一份合约，该合约声明了希望系统做什么事。
可以用各种形式表达需求，从非结构化的文字到形式语言的表达式，以及介于二者之间的其他任意形式皆可。大多数（如果不是全部的话）系统的功能需求都可以表示成用况，UML 的用况图对管理这些需求是不可缺少的。
4.2.1、设计过程：
- 通过识别系统周围的参与者来建立系统的语境。
- 对于每个参与者，考虑它期望的或需要系统提供的行为。
- 把这些公共的行为命名为用况。
- 分解公共行为，放入新的用况中以供其他的用况使用；分解异常行为，放入新的用况中以延伸较为主要的控制流。
- 在用况图中对这些用况、参与者以及它们的关系进行建模。
- 用陈述非功能需求的注解或约束来修饰这些用况，可能还要把其中的一些附加到整个系统。
上图是对上一个用况图的扩充。尽管没有画出参与者与用况之间的关系，但加入了额外的用况，这些用况对于一般的顾客不可见，但仍是系统的基本行为。这张图是有价值的，因为它为最终用户、领域专家以及开发者提供了一个共同的起点，以便可视化、详述、构造和文档化他们关于系统的功能需求的决策。例如，检测信用卡欺诈（Detect card fraud）对于零售机构（Retail institution）和主办财务机构（Sponsoring financial institution）都是很重要的行为。类似地，报告账户的状态（Report on account status）是系统语境中不同机构所需要的另一个行为。
一旦确定了用况的结构，就必须描述每个用况的行为。
通常要为每个主线情况绘制一个或多个顺序图，然后要为每种变体情况绘制顺序图。
最后，为了说明对各种错误和异常情况的处理，至少还要绘制一个顺序图；对错误的处理是用况的一部分，要和正常行为一起考虑。
5、正向工程
（forward engineering）是通过映射到一个实现语言而把模型转换为代码的过程。
用况图可通过正向工程，形成对它所应用的元素的测试。
用况图中的每个用况说明了一个事件流（或这些流的变体），这些流说明了元素被期望如何行动——这正是值得测试的。
一个结构良好的用况甚至说明了前置条件和后置条件，来定义一个测试的初态和它的成功判定标准。对于用况图中的每个用况，都可以创建一个测试用例，每当发布这个元素的新版本时都可以运行它，从而在其他元素使用它之前就保证它能像要求的那样工作。
- 识别与系统交互的对象。尝试找出每个外部对象可能扮演的各种角色。
- 设立参与者，以表示每一种不同的交互角色。
- 对于图中的每个用况，识别它的事件流和异常事件流。
- 根据选择的测试深度，为每个流产生一个测试脚本，把流的前置条件作为测试的初态，把流的后置条件作为测试的成功判定标准。
- 必要时生成一个测试支架来表示每个与用况交互的参与者。把信息传给元素或者是通过元素来执行的参与者都可以被现实世界的等价物模拟或替换。
- 每次发布用况图描绘的元素时，都用工具来运行相应的测试。
