型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有个总体的认识。除此之外，我们还需要描述每个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每个用例的详细描述用例规约所组成的。中提供了用例规约的模板，每个用例的用例规约都应该包含以下内容简要说明简要介绍该用例的作用和目的。事件流包括基本流和备选流，事件流应该表示出所有的场景。用例场景包括成功场景和失败场景，场景主要是由基本流和备选流组合而成误解认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有个总体的认识。除此之外，我们还需要描述每个有例的详细信息，这些信息包含案中选择种最佳或较佳的结果，个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同用例模型的理解应该是致的。描述用例规约应该避免这样种个用例模型才能够符合定的风格。如参与者的名称般都是名词，用例名称般都是动宾词组等。对于同个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方，应该将其删除。可视化建模的主要目的之就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合定的命名约定，这样整上该参与者。反之，每个参与者也必须至少涉及到个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定个新的用例，或者该参与者是个多余的模型元素中，必须注意用例必须是由个主角触发而产生的活动，即每个用例至少应该涉及个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例或者是检查该用例相对应的参与者是否被遗漏，如果是，则补问存储数据如果是的话，参与者又是如何来完成这些操作的参与者是否会将外部的些事件通知给该系统系统是否会将内部的些事件通知该参与者综合以上所述，系统的用例图可表示如下，在用例的抽取过程定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手针对每个参与者参与者为什么要使用该系统参与者是否会在系统中创建修改删除访们可以抽象出个系统时钟或定时器参与者，利用该参与者来触发这类定时操作。从逻辑上，这参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。确定用例找到参与者之后，我们就可以根据参与者来确有时候我们需要在系统内部定时地执行些操作，如检测系统资源使用情况定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这类功能需求呢对于这种情况，我在机系统中，打印机只是系统的个组成部分，不应将它抽象成个的参与者在个管理系统中，数据库系统往往只作为系统的个组成部分，般不将其单独抽象成个参与者。特殊的参与者系统时钟所要定义的系统边界扩大至整个银行系统，机和后台服务器都是整个银行系统的部分，这时候后台服务器就不再被抽象成为个参与者。值得注意的是，用例建模时不要将些系统的组成结构作为参与者来进行抽象，如器进行通讯以获得有关用户帐号的相关信息。系统边界决定了参与者参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于机本身，那么后台服务器就是个外部的系统，可以抽象为个参与者。如果我们些其他系统相关联系统是由谁来维护和管理的这些问题有助于我们抽象出系统的参与者。对于机的例子，回答这些问题可以使我们找到更多的参与者操作员负责维护和管理机系统机也需要与后台服务通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手系统开发完成之后，有哪些人会使用这个系统系统需要从哪些人或其他系统中获得数据系统会为哪些人或其他系统提供数据系统会与哪容。在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每个用例的用例规约。寻找参与者所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。的参与者用例和两者之间的对应关系，用例图描述的是关于系统功能的个概述。用例规约针对每个用例都应该有个用例规约文档与之相对应，该文档描述用例的细节内容的参与者用例和两者之间的对应关系，用例图描述的是关于系统功能的个概述。用例规约针对每个用例都应该有个用例规约文档与之相对应，该文档描述用例的细节内容。在用例建模的过程中，我们建议的步聚是先找出参与者，再根据参与者确定每个参与者相关的用例，最后再细化每个用例的用例规约。寻找参与者所谓的参与者是指所有存在于系统外部并与系统进行交互的人或其他系统。通俗地讲，参与者就是我们所要定义系统的使用者。寻找参与者可以从以下问题入手系统开发完成之后，有哪些人会使用这个系统系统需要从哪些人或其他系统中获得数据系统会为哪些人或其他系统提供数据系统会与哪些其他系统相关联系统是由谁来维护和管理的这些问题有助于我们抽象出系统的参与者。对于机的例子，回答这些问题可以使我们找到更多的参与者操作员负责维护和管理机系统机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。系统边界决定了参与者参与者是由系统的边界所决定的，如果我们所要定义的系统边界仅限于机本身，那么后台服务器就是个外部的系统，可以抽象为个参与者。如果我们所要定义的系统边界扩大至整个银行系统，机和后台服务器都是整个银行系统的部分，这时候后台服务器就不再被抽象成为个参与者。值得注意的是，用例建模时不要将些系统的组成结构作为参与者来进行抽象，如在机系统中，打印机只是系统的个组成部分，不应将它抽象成个的参与者在个管理系统中，数据库系统往往只作为系统的个组成部分，般不将其单独抽象成个参与者。特殊的参与者系统时钟有时候我们需要在系统内部定时地执行些操作，如检测系统资源使用情况定期地生成统计报表等等。从表面上看，这些操作并不是由外部的人或系统触发的，应该怎样用用例方法来表述这类功能需求呢对于这种情况，我们可以抽象出个系统时钟或定时器参与者，利用该参与者来触发这类定时操作。从逻辑上，这参与者应该被理解成是系统外部的，由它来触发系统所提供的用例对话。确定用例找到参与者之后，我们就可以根据参与者来确定系统的用例，主要是看各参与者需要系统提供什么样的服务，或者说参与者是如何使用系统的。寻找用例可以从以下问题入手针对每个参与者参与者为什么要使用该系统参与者是否会在系统中创建修改删除访问存储数据如果是的话，参与者又是如何来完成这些操作的参与者是否会将外部的些事件通知给该系统系统是否会将内部的些事件通知该参与者综合以上所述，系统的用例图可表示如下，在用例的抽取过程中，必须注意用例必须是由个主角触发而产生的活动，即每个用例至少应该涉及个主角。如果存在与主角不进行交互的用例，就可以考虑将其并入其他用例或者是检查该用例相对应的参与者是否被遗漏，如果是，则补上该参与者。反之，每个参与者也必须至少涉及到个用例，如果发现有不与任何用例相关联的参与者存在，就应该考虑该参与者是如何与系统发生对话的，或者由参与者确定个新的用例，或者该参与者是个多余的模型元素，应该将其删除。可视化建模的主要目的之就是要增强团队的沟通，用例模型必须是易于理解的。用例建模往往是个团队开发的过程，系统分析员在建模过程中必须注意参与者和用例的名称应该符合定的命名约定，这样整个用例模型才能够符合定的风格。如参与者的名称般都是名词，用例名称般都是动宾词组等。对于同个系统，不同的人对于参与者和用例都可能有不同的抽象结果，因而得到不同的用例模型。我们需要在多个用例模型方案中选择种最佳或较佳的结果，个好的用例模型应该能够容易被不同的涉众所理解，并且不同的涉众对于同用例模型的理解应该是致的。描述用例规约应该避免这样种误解认为由参与者和用例构成的用例图就是用例模型，用例图只是在总体上大致描述了系统所能提供的各种服务，让我们对于系统的功能有个总体的认识。除此之外，我们还需要描述每个有例的详细信息，这些信息包含在用例规约中，用例模型是由用例图和每个用例的详细描述用例规约所组成的。中提供了用例规约的模板，每个用例的用例规约都应该包含以下内容简要说明简要介绍该用例的作用和目的。事件流包括基本流和备选流，事件流应该表示出所有的场景。用例场景包括成功场景和失败场景，场景主要是由基本流和备选流组合而成的。特殊需求描述与该用例相关的非功能性需求包括性能可靠性可用性和可扩展性等和设计约束所使用的操作系统开发工具等。前置条件执行用例之前系统必会用到被包含用例，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。包含关系是中的表述，在中，同等语义的关系被表述为使用，如下图。在机中，如果查询取现转帐这三个用例都需要打印个回执给客户，我们就可以把打印回执这部分内容提取出来，抽象成为个单独的用例打印回执，而原有的查询取现转帐三个例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动个用例，而不用在每个用例都作相应修改，这样就提高了用例模型的可维护性。在基础用例的事件流中，我们只需要引用被包含用例即可。查询基本事件流用户插入信用卡输入密码选择查询查看帐号余额包含用例打印回执退出