Use Case是一种用来描述系统需求的方法，使用用户方法来描述系统需求的过程就是用例建模。用例的使用在RUP中倍受推崇，整个RUP流程被称作是“用例驱动”，各种类型的活动包括，项目管理，分析设计、测试、实现等都是以系统用例为输入工件，用例模型奠定了整个软件开发的基础。
一、用例
1、 参与者和用例
从参与者的角度来看，参与者并不想理解系统的内部结构和设计，他们所关系的仅仅是系统所提供的功能服务，能用你的系统来完成什么功能及如何去使用这些功能。其中用例模型主要构成元素包括：
Actor
参与者是值存在于被定义系统外部并与该系统发生交互的人或者其他系统，他们代表的是系统的使用者或者是使用环境。
Use Case
用例用户表示系统所提供的服务或功能，它定义的是用户即参与者如何使用系统，它描述的是参与者为了使用系统的某一完整的功能而与系统发生的对话。
Communication Association
通讯关联用来描述参与者和用例之间的对应关系，它表示了参与者使用了系统中的哪些服务即用例，或者说系统提供的哪些服务(用例)被哪些参与者所使用。
在UML中表述如下图：
上图中通讯关联表示的是参与者与用例之间的关系，箭头表示的是通讯中哪一方为主动发起者。如果不想强调主被动关系则使用不带箭头的实线表示即可。在参与者与用例之间的信息流向是双向的，它与通讯关联中箭头的指向没有关系。
2、用例的内容
通过用例图的描述我们对整个系统有了整体的认知，我们可以获取得到哪些参与者会系统发生交互，每一个参与者需要系统为他提供什么样的服务。用例描述是参与者与系统之间的对话，但是细节内容却没有在用例图中表示出来，但是每一个用例我们可以使用事件流来表示。
例如 用户登录这一事件用例其正常事件流表述如下：
a、用户点击“登录”
b、输入用户名、密码、验证码
c、登录后页面
上面提供的只是一种正常事件流或者叫主事件流，然而作为一个实用可行的系统还必须提供相应的备选事件流，例如：用户名不存在、密码错误、验证码输入与系统提供的不一致等。
通过主事件流和备选事件流通常可以把可能发生的各种场景(Scenario)描述清楚，所以我们在描述事件流的时候需要尽可能的把所有可能发生的场景描述出来，以保证需求的完整性。
3、用例的优点
用例方法完全是站在用户的角度上来考虑系统的功能，在用例模型中我们讲系统看成是一个“黑箱”，我们并不关系系统的内部是如何来完成所需要的功能的。从上可以看出，用例模型首先就定义了系统有哪些外部使用者即Actor，这些使用者与系统发生交互，从而就产生了用例，从所有的用例中我们可以得到系统的一个大概的认知。
与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把设计和需求完全分离开来。在面向对象的分析设计方法中，用例模型主要用来描述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，每一个用例描述的是一个完整的系统功能。用例方法比传统的更易于被用户理解，可以作为开发人员与用户之间针对系统需求进行沟通的一个有效手段。
一、用例
1、 参与者和用例
从参与者的角度来看，参与者并不想理解系统的内部结构和设计，他们所关系的仅仅是系统所提供的功能服务，能用你的系统来完成什么功能及如何去使用这些功能。其中用例模型主要构成元素包括：
Actor
参与者是值存在于被定义系统外部并与该系统发生交互的人或者其他系统，他们代表的是系统的使用者或者是使用环境。
Use Case
用例用户表示系统所提供的服务或功能，它定义的是用户即参与者如何使用系统，它描述的是参与者为了使用系统的某一完整的功能而与系统发生的对话。
Communication Association
通讯关联用来描述参与者和用例之间的对应关系，它表示了参与者使用了系统中的哪些服务即用例，或者说系统提供的哪些服务(用例)被哪些参与者所使用。
在UML中表述如下图：
上图中通讯关联表示的是参与者与用例之间的关系，箭头表示的是通讯中哪一方为主动发起者。如果不想强调主被动关系则使用不带箭头的实线表示即可。在参与者与用例之间的信息流向是双向的，它与通讯关联中箭头的指向没有关系。
2、用例的内容
通过用例图的描述我们对整个系统有了整体的认知，我们可以获取得到哪些参与者会系统发生交互，每一个参与者需要系统为他提供什么样的服务。用例描述是参与者与系统之间的对话，但是细节内容却没有在用例图中表示出来，但是每一个用例我们可以使用事件流来表示。
例如 用户登录这一事件用例其正常事件流表述如下：
a、用户点击“登录”
b、输入用户名、密码、验证码
c、登录后页面
上面提供的只是一种正常事件流或者叫主事件流，然而作为一个实用可行的系统还必须提供相应的备选事件流，例如：用户名不存在、密码错误、验证码输入与系统提供的不一致等。
通过主事件流和备选事件流通常可以把可能发生的各种场景(Scenario)描述清楚，所以我们在描述事件流的时候需要尽可能的把所有可能发生的场景描述出来，以保证需求的完整性。
3、用例的优点
用例方法完全是站在用户的角度上来考虑系统的功能，在用例模型中我们讲系统看成是一个“黑箱”，我们并不关系系统的内部是如何来完成所需要的功能的。从上可以看出，用例模型首先就定义了系统有哪些外部使用者即Actor，这些使用者与系统发生交互，从而就产生了用例，从所有的用例中我们可以得到系统的一个大概的认知。
与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把设计和需求完全分离开来。在面向对象的分析设计方法中，用例模型主要用来描述系统的功能性需求，系统的设计主要由对象模型来记录表述。另外，每一个用例描述的是一个完整的系统功能。用例方法比传统的更易于被用户理解，可以作为开发人员与用户之间针对系统需求进行沟通的一个有效手段。