| OOA的基本任务是运用面向对象方法，对问题域和系统责任进行分析和理解，正确认识其中的事物及它们之间的关系，找出描述问题域及系统责任所需的类和对象，定义它们的属性和服务，以及它们之间所形成的结构、静态联系和动态联系。最终产生一个符合用户需求，并能直接反映问题域和系统责任的OOA模型及其详细说明。
|
|
|
| 用例分析方法的创始人Ivar Jacobson给用例的定义是：“用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。一个用例则定义一组用例实例。”从这个定义中，我们可以得知用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景；其次，可以知道，用例应该给参与者带来可见的价值，这点很关键；最后还可以得知，用例是在系统中的。
|
|
|
| 用例分析技术为软件需求规格化提供了一个基本的元素，而且该元素是可验证、可度量的。用例可以作为项目计划、进度控制、测试等环节的基础。而且用例还可以使开发团队与客户之间的交流更加顺畅。构建用例模型需要经历识别参与者、合并需求获得用例、细化用例描述三个阶段。
|
|
|
| （1）识别参与者（actor）。参与者是系统之外与系统进行交互的任何事物，参与者可以是使用系统的用户，也可以是其他外部系统、外部设备等外部实体。在UML中采用小人符号来表示参与者。参与者有主要参与者和次要参与者之分，开发用例的重点是要找到主要参与者。
|
|
|
| （2）合并需求获得用例。将参与者都找到之后，接下来就是仔细地检查参与者，为每一个参与者确定用例。而其中的依据主要可以来源于已经获取得到的特征表。首先，将特征分配给相应的参与者，然后进行合并操作，最后绘制成用例图。在确定用例的过程中，不能混淆用例和用例所包含的步骤，要注意区分业务用例和系统用例。
|
|
|
| （3）细化用例描述。用例建模的主要工作是书写用例规约（use case specification），而不是画图。用例模板为一个给定项目的所有人员定义了用例规约的结果，其内容至少包括用例名、参与者、目标、前置条件、事件流（基本事件流、扩展事件流）、后置条件等，其他的还可以包括非功能需求、用例优先级等。
|
|
|
| 一个较为复杂的系统会有较多的用例，为便于理解，可以为它们建立多张用例图。更为复杂的情况将导致所有用例难以维持一种平面结构，这时可以对用例进行分组。UML使用用例主题划分用例图，一组用例放置在以主题命名的方框中（类似于系统边界），每个主题中可以包含多个用例图。
|
|
|
