1、“..... 通俗地讲，参与者就是我们所要定义系统的使用者。 寻找参与者可以从以下问题入手系统开发完成之后，有哪些人会使用这个系统系统需要从哪些人或其他系统中获得数据系统会为哪些人或其他系统提供数据系统会与哪些其他系统相关联系统是由谁来维护和管理的这些问题有助于我们抽象出系统的参与者。 对于机的例子，回答这些问题可以使我们找到更多的参与者操作员负责维护和管理机系统机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。 系统边界决定了参与者参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于机本身，那么后台服务器就是个外部的系统，可以抽象为个参与者。 如果我们所要定义的系统边界扩大至整个银行系统，机和后台服务器都是整个银行系统的部分，这时候后台服务器就不再被抽象成为个参与者。 值得注意的是，用例建模时不要将些系统的组成结构作为参与者来进行抽象，如在机系统中......”。

2、“.....不应将它抽象成个独立的参与者在个管理系统中，数据库系统往往只作为系统的个组成部分，般不将其单独抽象成个参与者。 特殊的参与者系统时钟有时候我们需要在系统内部定时地执行些操作，如检测系统资源使用情况定期地生成统计报表等等。 从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这类功能需求呢对于这种情况，我们可以抽象出个系统时钟或定时器参与者，利用该参与者来触发这类定时操作。 从逻辑上，这参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。 确定用例找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。 寻找用例可以从以下问题入手针对每个参与者参与者为什么要使用该系统参与者是否会在系统中创建修改删除访问据自己的需要创建任意多个用例图......”。

3、“..... 但是最重要的是要考虑整个用例模型的可理解性，如果可以用个用例图把意思表述清楚，就不要再用第二个，因为越是简洁的模型越易于理解。 什么是用例在介始用例方法之前，我们首先来看下传统的需求表述方式软件需求规约。 传统的软件需求规约基本上采用的是功能分解的方式来描述系统功能，在这种表述方式中，系统功能被分解到各个系统功能模块中，我们通过描述细分的系统模块的功能来达到描述整个系统功能的目的。 个典型的软件需求规约可能具有以下形式采用这种方法来描述系统需求，非常容易混淆需求和设计的界限，这样的表述实际上已经包含了部分的设计在内。 由此常常导致这样的迷惑系统需求应该详细到何种程度个极端就是需求可以详细到概要设计，因为这样的需求表述既包含了外部需求也包含了内部设计。 在有些公司的开发流程中，这种需求被称为内部需求，而对应于用户的原始要求则被称之为外部需求......”。

4、“.....从各项功能项入手，你很难了解到这些功能项是如何相互关联来实现个完成的系统服务的。 所以在传统的文档中，我们往往需要另外些章节来描述系统的整体结构及各部分之间的相互关联，这些内容使得需求更象是个设计文档。 参与者和用例从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。 用例模型主要由以下模型元素构成参与者参与者是指存在于被定义系统外部并与该系统发生交互的人或其他系统，他们代表的是系统的使用者或使用环境。 用例用例用于表示系统所提供的服务，它定义了系统是如何被参与者所使用的，它描述的是参与者为了使用系统所提供的完整功能而与系统之间发生的段对话。 通讯关联通讯关联用于表示参与码，系统显示并提示用户重新输入密码，重新回到基本流步骤三次输入密码后，信用卡被系统没收......”。

5、“..... 通过基本流与备选流的组合，就可以将用例所有可能发生的各种场景全部描述清楚。 我们在描述用例的事件流的时候，就是要尽可能地将所有可能的场景都描述出来，以保证需求的完备性。 用例方法的优点用例方法完全是站在用户的角度上从系统的外部来描述系统的功能的。 在用例方法中，我们把被定义系统看作是个黑箱，我们并不关心系统内部是如何完成它所提供的功能的。 用例方法首先描述了被定义系统有哪些外部使用者抽象成为，这些使用者与被定义系统发生交互针对每参与者，用例方法又描述了系统为这些参与者提供了什么样的服务抽象成为，或者说系统是如何被这些参与者使用的。 所以从用例图中，我们可以得到对于被定义系统的个总体印象。 与传统的功能分解方式相比，用例方法完全是从外部来定义系统的功能，它把需求与设计完全分离开来。 在面向对象的分析设计方法中，用例模型主要用于表述系统的功能性需求......”。

6、“..... 另外，用例定义了系统功能的使用环境与上下文，每个用例描述的是个完整的系统服务。 用例方法比传统的更易于被用户所理解，它可以作为开发人员和用户之间针对系统需求进行沟通的个有效手段。 在中，用例被作为整个软件开发流程的基础，很多类型的开发活动都把用例作为个主要的输入工件，如项目管理分析设计测试等。 根据用例来对目标系统进行测试，可以根据用例中所描述的环境和上下文来完整地测试个系统服务，可以根据用例的各个场景来设计测试用例，完全地测试用例的各种场景可以保证测试的完备性。 建立用例模型使用用例的方法来描述系统的功能需求的过程就是用例建模，用例模型主要包括以下两部分内容用例图确定系统中所包含的参与者用例和两者之间的对应关系，用例图描述的是关于系统功能的个概述。 用例规约针对每个用例都应该有个用例规约文档与之相对应，该文档描述用例的细者和用例之间的对应关系......”。

7、“.....或者说系统所提供的服务用例是被哪些参与者所使用的。 这大三种模型元素在中的表述如下图所示。 以银行自动提款机为例，它的主要功能可以由下面的用例图来表示。 的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询提款和转帐交易。 通讯关联表示的是参与者和用例之间的关系，箭头表示在这关系中哪方是对话的主动发起者，箭头所指方是对话的被动接受者如果你不想强调对话中的主动与被动关系，可以使用不带箭头的关联实线。 在参与者和用例之间的信息流不是由通讯关联来表示的，该信息流是缺省存在的用例本身描述的就是参与者和系统之间的对话，并且信息流向是双向的，它与通讯关联箭头所指的方向亳无关系。 用例的内容用例图使我们对系统的功能有了个整体的认知，我们可以知道有哪些参与者会与系统发生交互，每个参与者需要系统为它提供什么样的服务。 用例描述的是参与者与系统之间的对话......”。

8、“.....针对每个用例我们可以用事件流来描述这对话的细节内容。 如在系统中的提款用例可以用事件流表述如下提款基本事件流用户插入信用卡输入密码输入提款金额提取现金退出系统，取回信用卡但是这只描述了提款用例中最顺利的种情况，作为个实用的系统，我们还必须考虑可能发生的各种其他情况，如信用卡无效输入密码错用户帐号中的现金余额不够等，所有这些可能发生的各种情况包括正常的和异常的被称之为用例的场景，场景也被称作是用例的实例。 在用例的各种场景中，最常见的场景是用基本流来描述的，其他的场景则是用备选流来描述。 对于系统中的提款用例，我们可以得到如下些备选流提款备选事件流备选流用户可以在基本流中的任何步选择退出，转至基本流步骤。 备选流二在基本流步骤中，用户插入无效信用卡，系统显示并退出信用卡，用例结束。 备选流三在基本流步骤中，用户输入密照相应的扩展点插入到基础用例中。 对于包含关系而言......”。

9、“.....并且插入点只有个。 而扩展关系可以根据定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。 例如对于电话业务，可以在基本通话业务上扩展出些增值业务如呼叫等待和呼叫转移。 我们可以用扩展关系将这些业务的用例模型描述如下。 在这个例子中，呼叫等待和呼叫转移都是对基本通话用例的扩展，但是这两个用例只有在定的条件下如应答方正忙或应答方无应答才会将被扩展用例的事件流嵌入基本通话用例的扩展点，并重用基本通话用例中的事件流。 值得注意的是扩展用例的事件流往往可以也可抽象为基础用例的备选流，如上例中的呼叫等待和呼叫转移都可以作为基本通话用例的备选流而存在。 但是基本通话用例已经是个很复杂的用例了，选用扩展关系将增值业务抽象成为单独的用例可以避免基础用例过于复杂，并且把些可选的操作独立封装在另外的用例中......”。