内容用例图由三部分组成：参与者一组（个）用例关系1.1参与者定义是直接与系统相互作用的系统、子系统或类的外部实体的抽象。它是用户所扮演的角色，是系统的用户。每个参与者定义了一个角色集合。通常，一个参与者可以代表一个人、一个计算机子系统、硬件设备或者时间等角色。典型的参与者如销售部经理、销售员和结帐系统。图形表示用小人图符表示1.1参与者参与者的识别谁将使用系统的主要功能？■谁将需要系统的支持来完成他们的日常任务？■谁必须维护、管理和确保系统正常工作？■谁将给系统提供信息、使用信息和删除信息？■系统需要处理哪些硬件设备？■系统使用了外部资源吗？■系统需要与其他什么系统交互吗？■谁或者什么对系统产生的结果感兴趣？■一个人同时使用几种不同的规则吗？■几个人使用相同的规则吗？■系统使用遗留下来的应用吗？1基本概念1.2用例用例识别参与者要向系统请求什么功能？每个参与者的特定任务是什么？参与者需要读取、创建、撤消、修改、或存储系统的某些信息吗？是否任何一个参与者都要向系统通知有关突发性的、外部的改变？或者必须通知参与者关于系统中的发生的事件？这些事件代表了哪些功能？系统需要哪些输入/输出？这些输入输出来自哪里或者到哪里去？哪些用例支持或维护系统？是否所有功能需求都被用例使用了？系统当前实现的主要问题是什么？1.3事件流事件流是用例完成需求行为的事件描述。事件流的目的是建立用例中逻辑流程的文档，详细描述系统用户的工作和系统本身的工作，既包括正常状态下系统完成需求行为的事件，也包括在其他状态下不能完成需求行为的事件。事件流通常包括：简要说明前置条件事件流后置条件1.4用例模型一个用例模型由一个或者多个用例图和所有的支持文件（诸如用例规范和参与者定义等）所构成。用例规范是大多数用例模型的产物，而用例图充当将需求模型综合在一起的粘胶剂。用例模型应当从项目投资者的角度进行开发，而不是从开发者的（通常是技术）观点去开发。关系反应了参与者和用例之间、用例和用例之间以及参与者和参与者之间的相互作用。在一个用例图中，可能会出现关联关系、依赖关系、泛化关系以及这三种关系的扩展形式：扩展关系、包含关系和精化关系。2.1关联关系关联关系表示一种通信路径，它存在于参与者和用例之间，提供用例和参与者之间的通信途径。建立通信之后，信息可以双向流动。关系方向显示的不是信息的流动方向，而是谁启动信息。2关系及其应用2.1关联关系在用例图中，通常存在两种类型的关联：单向关联双向关联Actor1与UseCase1Actor2与UseCase12.2依赖关系定义存在于两个模型要素之间的一种关系，其中一个模型要素的改变将影响另一个模型要素表示方法工具箱和模型图中均表示为一个带箭头的虚线画图时，拖动鼠标从客户到提供者画出关联关系2.3泛化关系定义在一个更一般的模型要素和另一个较具体的模型要素之间存在的一种关系，通常用于表示类（包括用例、参与者等）之间的继承关系表示方法工具箱中：模型图中：一条带空心三角形箭头的实线（箭头方向从具体用例指向一般用例）2.3泛化关系用例之间的泛化关系参与者之间的泛化关系2关系及其应用2.4关系的扩展常见的几种扩展关系a.两个用例相似但不完全相同时（如图）b.当要对多个额外情况逐一建模时，可以使用扩展关系，用一个独立的用例替代每个额外的情况c.如果用例涵盖了所有的情况变化，则该用例将会变得十分复杂，应该考虑使用扩展关系2关系及其应用2.4关系的扩展使用包含关系的三种情况：a.如果有多个用例，并且这些用例包含大量类似的行为，应该考虑将这些类似的行为通过包含关系包含到用例中b.对两个或多个互相独立的用例建模时做了重复的工作，可以通过包含关系包含这些重复的工作c.如果某个行为可能会引入冗余，或者，当行为发生变化时可能导致不一致性，这时，应该对这种行为进行孤立建模并将它包含到用例中2.4关系的扩展包含关系举例2.4关系的扩展3）精化关系精化关系在不同的语义层或者开发阶段连接两个或者多个模型要素。它表示了某些在一个特定的细节层次上规定的东西的更加全面的规格说明。例如，一个设计类就是一个分析类的一种精化。在一个精化关系中，源模型要素是一般的，在定义上更加概括；而目标模型要素更加具体并得到了进一步的精化。3.1参与者规范Rose在实现中对参与者和类使用相同的规范窗口，包括如下一些标签：GeneralDetailOperationsAttributesRelationsComponentsNestedFiles3参与者规范及应用3参与者规范及应用3参与者规范及应用3.2