一、Use Case 概述 Use Case，它描述的是一个操作，而不是一个功能。传统的软件模型设计喜欢在需求分析把业务分解成功能模块，这样的弊端就是混淆了需求和设计的界限，因为功能模块的划分牵涉到系统的概要设计。在RUP里面提倡用use case来代替功能模块的划分。与功能模块不同的是，用例是站在用户的角度来分解系统，用户并不想了解系统的内部结构和设计，他们关心的是系统所能提供的服务，即系统是如何去操作的，这就是用例的基本思想。用例模型主要由以下元素组成： 
1、参与者(Actor)：参与者是与系统发生交互的外部用户、系统或其他硬件设备，参与者可以是人、另一个计算机系统或一些可运行的进程等。
2、用例(Use Case)：用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。
3、通讯关联(Communication Association) ：通讯关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些服务（用例），或者说系统所提供的服务（用例）是被哪些参与者所使用的。

二、用例之间的关系
1、包含(include)，将若干用例中一些相同的行为，单独抽象成一个的用例，然后其他用例来包含这个用例。这样避免在多个用例里面重复设计同一个操作，也避免同一个操作在不同的用例里面的描述出现不一致。需要修改的时候，也只需要一个用例，避免修改多个用例出现的不一致和重复工作。例如：银行ATM系统，用户取款、存款时，都会打印凭证，我们将打印凭证抽象出来，取款、存款等操作时包含打印任证这个行为。
2、扩展(extend)，扩展是将事件流中一些相对独立并且可选的行为扩展为新的用例，并且在基用例上的扩展点进行扩展。与包含关系不同的是，包含的事件是必须存在的动作，并且该用例的事件流一定要插入到基础用例中；而扩展是提供一些备选动作，可根据条件来决定是否将扩展用例的事件流插入基础用例的事件流中。扩展也可以抽象为基用例的备选流，扩展出来的用例可以让基用例变得更加简练。例如：在通话业务的基础上可扩展一些增值业务，如语音信箱、呼叫转移等。
  
3、泛化(generalization) ，也叫继承(泛化是分析领域术语，继承是设计和实现领域术语，通常用继承来解决泛化问题)。当多个用例拥有相同的结构、行为时，我们可以把它们的共性部份抽象出来成为父用例，而其他用例作为泛化关系中的子用例。在泛化关系中，子用例是父用例的特殊形式，子用例继承了父用例所有的结构、行为以及关系。例如：订票是网上订票用例和电话订票用例的抽象。
三、建立用例模型
1、确定参与者，可以从以下问题入手：

系统开发完成之后，有哪些人会使用这个系统？

系统需要从哪些人或其他系统中获得数据？

系统会为哪些人或其他系统提供数据？

系统会与哪些其他系统相关联？

系统是由谁来维护和管理的？  

2、确定用例，寻找用例可以从以下问题入手（针对每一个参与者）：

参与者为什么要使用该系统？

参与者是否会在系统中创建、修改、删除、访问、存储数据？如果是的话，参与者又是如何来完成这些操作的？

参与者是否会将外部的某些事件通知给该系统？

系统是否会将内部的某些事件通知该参与者？