面向对象系统设计与分析专题<5>__用例模型

PS: 这是部分是在业务事件流分析后建立与用户交流的模型

 

       用例模型用于对系统的功能以及与系统进行交互的外部事物建模，这是面向对象系统开发的第二个步骤。用例模型表示系统和参与者间的交互，由表示参与者和用例的的图和对每个用例的详细描述组成。这个步骤的主要工作是标识与每个事件相关的用例并生成系统用例图，并编写基本用例叙述，并不断修改直到获得用户需求的精确描述。

1 面向对象系统的用例

        用例，或译为使用案例、用况(Use Case)，是一种描述系统需求的方法，使用用例的方法来描述系统需求的过程就是用例建模。用例方法最早是由Ivar Jacobson博士提出的，后来被综合到UML规范之中，成为一种标准化的需求表述体系。用例的使用在Rational 统一过程（Rational Unified Process，RUP）中被推崇备至，整个RUP流程都被称作是"用例驱动"(Use-Case Driven)的，各种类型的开发活动包括项目管理、分析设计、测试、实现等都是以系统用例为主要输入工件，用例模型奠定了整个系统软件开发的基础。

1．用例

       用例是一组连续的操作，在参与者使用系统来完成某个过程时出现。起初，用例是用于测试在系统响应来自环境的消息时会发生何种情况，是一种在系统内提供所需功能的过程。它是对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术，也就是说系统是如何被参与者所使用的，从而获得一个明确的业务目标。可以利用系统对事件响应所需要执行的动作或行为来标识用例。

       用例一般是由软件开发者和最终用户共同创作的。用例命名时要避免使用技术术语，而应该用最终用户或者领域专家的语言。实践中往往用动宾结构（动词短语）来强调用例是用于描述过程这一事实。我们从参与者而非系统角度来命名用例。例如，“购买图书”是源自“顾客”参与者，而“销售图书”则是从系统角度来看待用例。在UML中，用例用一个椭圆来表示，如图1所示。

图1 用例的例子

       用例不是计算机进程模型，是与实现无关的关于系统功能的描述，这是一个需求模型。即从使用系统的角度，站在系统外部查看系统功能。从用户的角度来看，他们并不想了解系统的内部结构和设计，他们所关心的是系统所能提供的服务，也就是被开发出来的系统将是如何被使用的，这就用例方法的基本思想。

       用例并不进行计算，它们只是帮助理解系统必须执行何种操作的模型。用例把系统看作“黑盒”，同系统的交互，包括系统的响应都是可以在系统外部感知的。良好识别的用例应该：描述了满足业务目标的业务活动；没有涉及特定的实现语言；要求合适的细节级别；足够短，使得在一次发布中能够被一个软件开发人员实现。

       每个用例集中描述如何获得一个业务目标或任务。从传统的软件工程视角来看，用例只是描述了系统的一个特征。所以对大部分软件项目来说，这就意味着需要很多（有可能是数十个）用例来完整的描述新系统。一个特殊软件项目的正规度和项目的不同阶段将会影响每一用例需要的详细程度。

2．事件和用例

系统用例的标识可以业务事件分析中标识的事件相关联。每个事件需要一个或多个用例来响应。在初始的用例模型中，建议每个业务事件包含一个用例。之后在初始模型基础上，在复杂情况下，也许需要使用用例间关系来对某个带有多个用力的事件进行建模。

在初始的用例模型中，每个业务事件都有一个用例。因此，对于高校公修课选课系统来说，有四个用例：

（1）提交公修课班级计划列表

（2）生成学校公修课班级计划列表

（3）选择班级

（4）生成班级花名册

一般情况下，初始模型中用例对应于事件表中的系统动作，即为响应事件而执行的行为，也是向系统用户提供的服务。用例名称也遵循了推荐的命名方法。

2 参与者

1．概念与表示法

      对于每个有意义的系统，都存在着一些与系统打交道的事物，这些事物为了某些目的而与系统进行交互，这些事物被命名为参与者（Actor）。参与者代表的是系统的使用者或使用环境，它们向系统提供输入或接收系统输出。

      参与者可以是与系统交互的某个人、组织或系统。最常见的参与者是体现某种角色的人，一个银行业务系统会有从系统获取信息并执行金融交易的客户，一个图书馆管理系统会有查询馆藏信息的读者，人在与系统交互时扮演了这样的角色。一个人可以在不同的事件或不同的系统中具有不同的角色，例如公司员工会同时是公司的客户。诸如厂商、学校等组织也会是参与者，如高校公修课选课系统的参与者系。另外，信息用卡确认系统、库存系统、mail系统以及客户信用评级系统等计算机系统也常常作为参与者。

      需要注意的是，尽管在模型中使用了参与者，但参与者实际上并不是系统的一部分。参与者只能位于系统边界之外，是在系统之外与系统进行交互的任何事物，边界之内的所有人和事物都不是参与者

     参与者的标准图符是一个“人形符号”，参与者的名字放在图符下方，如图2所示。

图2参与者“客户”的表示法 图3参与者之间的继承关系

       如果一些参与者与系统的交互有一部分是相同的，这时用到参与者之间的继承关系（也称为泛化关系）。需要引入包含这些共同的交互的一般参与者（称作父参与者），并对原有参与者进行特殊化处理形成特殊参与者（称作子参与者）。特殊参与者从一般参与者中继承执行相同交互的能力，还可以增加自己特有的与系统交互的能力。在UML中，继承关系用带三角形箭头的实线表示。如图3是参与者之间继承关系的例子，其中客户是父参与者，A类客户、B类客户是子参与者。

      根据参与者与系统交互情况，通常把参与者分为发起参与者和加入参与者。发起参与者（通常发起外部事件，提供系统输入）发起用例。加入参与者与用例相关，但不启动用例，仅接收系统输出。经常存在参与者既为发起者又为加入者的例子。

2．识别参与者

      事件分析是系统开发的起点，最重要的参与者已经被标识出来。这些参与者出现在事件表中。询问下面六个问题会有助于查找参与者：

      谁初始化每个外部事件？

      谁作为每个事件的一部分，将信息输入系统或者从系统获取信息？

      谁来更新系统中作为每个事件一部分的信息？

      谁维护和管理系统？

      每个用例与什么计算机系统交互？

      每个用例与什么组织交互？

      这些问题有助于我们抽象出系统的参与者。对于ATM机的例子，回答这些问题可以使我们找到更多的参与者：操作员负责维护和管理ATM机系统、ATM机也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。识别过程中，从用户的角度，集中精力找出最重要的参与者，然后按着工作过程找出一些其他参与者。对识别出来的参与者，记录他们的责任，必要时通过识别继承关系来组织参与者。

3．高校公修课选课系统中的参与者

      使用前面用于查找参与者的六个问题，我们为高校公修课选课系统中的四个事件相对应的用例标识候选参与者。

      谁初始化每个外部事件？ 系、学生

      谁作为每个事件的一部分，将信息输入系统或者从系统获取信息？ 系、教授、学生

      谁来输入要存储在系统中的信息？ 系

      谁维护和管理系统？ 系统管理员

      每个用例与什么计算机系统交互？ 分数系统

      每个用例与什么组织交互？ 大学（其它需要学生成绩的大学）

      这四个用例相关的最重要的参与者是系、学生和教授，没有涉及到系统管理员、分数系统以及其他大学。这些参与者可能参与到其他用例中。

      在为高校公修课选课系统标识的四个用例中，发起参与者是系和学生，和两个外部事件有关，而加入参与者是系、教授以及学生，接收了系统的输出信息。

3 用例图

1．用例图

在标识出系统的用例、参与者后，就可以制作用例图了。用例图(Use Case Diagram)是图形模型，是一副显示系统中所包含的参与者、用例和两者之间对应关系的图。图4显示了高校公修课选课系统的用例图。表8-4显示了从前面事件表中导出的部分。

图4 高校公修课选课系统的用例图

可以看到，用例图提供的信息少于事件表所提供的，因为用例图中的线没有标示出系统输入、输出信息，也没有明确指出定时事件和外部事件之间的差别。所以，结合事件表有助于更透彻地理解功能需求。

表5从高校公修课选课系统的事件表中选择的列

事件 编号	事件描述	提供输入的 参与者	接收输出的 参与者
1.	系提交公修课班级计划列表	系
2.	到生成学校公修课班级计划列表的时间了		学生 系 教授
3.	学生选择班级	学生	学生
4.	到生成班级花名册的时间了		教授

2．用例图组件

在绘制用例图之前，充分理解用例图组件非常重要。它包含四种类型的组件，每一种都有一个图标代表。它们是：

（1）用例。用于表示系统所提供的服务，用一个含用例名字的椭圆形图标表示。

（2）参与者。代表系统的使用者或使用环境，用一个含参与者名称的人形符号表示。

（3）参与者和用例之间的关联。关联用于表示参与者和用例之间的对应关系，它表示参与者使用了系统中的哪些用例（服务），或者说系统所提供的用例（服务）是被哪些参与者所使用的。UML标准通过直线将参与者与用例连接在一起。但是，在用例图中我们可以标识发起参与者。从参与者到用例的箭头意味着，该参与者是该用例的发起参与者。加入参与者与用例之间的直线没有箭头。

（4）系统或子系统边界。矩形代表系统边界（或子系统边界），用于显示该系统或子系统内部和外部的事物。一个或多个用例位于代表系统或子系统的矩形内部，把参与者放在外边。在只定义一个子系统的情况下，该矩形通常被省略。

当具有许多用例时，通常的做法是对它们进行打包，在每个用例组周围放置矩形，用例包可以代表一个系统或子系统。例如，“高校公修课选课系统”的两个子系统可能是“选课子系统”和“课程维护子系统”（包括“添加新课程”和“启动选课系统”两个用例），可以分别被打包。这样，在用户面对多个子系统时，每次可以将注意力集中于一个单一子系统上。

3．标识系统边界

定位系统边界常常会是个棘手的问题。以银行自动提款机(ATM)为例，它的主要功能可以由下面的用例图图6来表示。ATM的主要使用者是银行客户，客户主要使用自动提款机来进行银行帐户的查询、存款、取款和转帐交易。

图6 银行自动提款机(ATM)系统的用例图

对于ATM系统，操作员负责维护和管理ATM系统、ATM也需要与后台服务器进行通讯以获得有关用户帐号的相关信息。如果我们所要定义的系统边界仅限于ATM机本身，那么后台服务器就是一个外部的系统，可以抽象为一个参与者。如果我们所要定义的系统边界扩大至整个银行系统，ATM机和后台服务器都是整个银行系统的一部分，这时候后台服务器就不再被抽象成为一个参与者。

标识系统边界时，我们建议系统边界内包含的场所应尽量多一些，这通常避免了为用例假设特定技术的问题。在系统分析中，应当仅指定基本需求，避免假设特定解决方案。

用例建模时不要将一些系统的组成结构作为参与者来进行抽象，如在ATM系统中，打印机只是系统的一个组成部分，不应将它抽象成一个独立的参与者；在一个管理信息系统中，数据库系统往往只作为系统的一个组成部分，一般不将其单独抽象成一个参与者。

4 用例叙述

用例图只是在总体上大致描述了系统所能提供的各种服务，使我们对于系统的功能有一个总体的认识。用例描述的是参与者与系统之间的对话，但是这个对话的细节并没有在用例图中表述出来，针对每一个用例还需要描述这一对话的细节内容，这些信息包含在用例叙述中，用例模型是由用例图和每一个用例的详细描述——用例叙述所组成的。没有描述的用例就像是一本书的目录，我们只知道该目录标题，并不知道这些目录标题的内容是什么。事实上，用例的描述才是用例的主要部分，是后续的类图和交互图分析的基础。

用例叙述是系统响应参与者操作所依据的内部操作顺序的叙事描述。用例叙述可以由简短描述到完整描述来完成，一般采用自然语言表达，便于用户、项目经理、开发人员、测试人员等相关用户交流与理解。用例的描述应该包含哪些内容，没有一个统一的标准，但一般应包括“充分”描述系统预期响应的内容。

1．简短用例叙述

简短用例叙述可以只包含概述系统作用域和功能的的基本项，使分析人员能够总体上把握每个用例。简短用例叙述的模板如图7所示，图8为用例“提交公修课班级计划列表”的简短用例叙述示例。

用例:	用例名称
参与者:	罗列所有发起参与者和加入参与者
目的:	用例的理由
概述:	对谁发起用例、预期的系统操作以及对参与者的响应的简短、完整的说明。

图7 简短用例叙述的模板

用例:	提交公修课班级计划列表
参与者:	系
目的:	记录系公修课班级计划
概述:	系提交其将为下一个学期提供的公修课班级计划。每个班级的详细信息（系编号、课程编号、班级编号、最大座位数、上课地点以及教师编号）均记录在系统中。

图8 简短用例叙述示例

2．完整用例叙述

在简短用例叙述基础上，通常需要对外部业务事件的系统响应进行更为完整的描述。业务（或系统级）事件经常包括几个级别较低或小规模的事件，这些细节事件描述了参与者和系统之间交互的详细信息。完整用例描述包含有关这些低级事件的其他详细信息。它以顺序形式罗列出每个低级事件，每个事件后是系统对该事件的响应。完整用例叙述的模板如图9所示。

用例:	用例名称
参与者:	罗列所有发起参与者和加入参与者
目的:	用例的理由
概述:	对谁发起用例、预期的系统操作以及对参与者的响应的简短、完整的说明。
类型:	关于需求的基本描述，或者考虑技术细节的实现描述
前置条件:	必须为真的条件，以使用例能够开始并产生所需结果。例如，在学生选择公修课程班级之前，班级信息必须存在。
后置条件:	用例完成后必须为真的条件。它描述在用例执行后，系统中应当出现什么变化。
特殊需求:	系统正常使用时所必须达到的用户的重要需求。例如，如果学生在10秒之后没有获得对注册请求的系统响应，该学生可能会认为系统出现了故障，或失去耐性并中断进程。
事件流：	参与者的操作顺序以及系统的相应响应的描述。
候选/例外事件流	描述在该用例的执行过程中可能出现的意外情况。在用例中执行的每一个行为都可能因参与者或系统原因出错，添加候选/例外事件流有助于了解每一个例外和应该采取的措施。

图9 完整用例叙述的模板

事件流要描述参与者与系统之间一步一步的交互，每一步要提供充分的内容，用以说明哪个参与者、做了什么事以及相应的系统响应结果。银行ATM系统的典型事件流如图10所示。图10显示了用例低级事件描述中使用的许多功能，用例应当具有开头、内容以及结尾，最常见的开头句型是“用例在……时启动”，结束句型用“参与者带着……离开/参与者接受了……”。

1.	在银行的客户带着银行卡使用ATM系统时用例启动。
2.	银行客户输入银行卡密码。
3.	系统验证银行客户的信息，然后显示消息以示正常状态。
4.	银行客户输入取款金额。
5.	系统验证正确性并记录该事务，然后显示消息。
6.	银行客户完成取款后带着现金和银行卡离开。

图10完整用例叙述中的事件流格式示例

图8所示的用例叙述格式无法清晰地显示出事件流中哪些步骤是参与者的操作，哪些操作是系统的响应。可以使用两列格式，如图11所示。该格式有利于快速识别低级事件和系统的响应。

用例“提交公修课班级计划列表”的完整叙述如图12所示。这个用例叙述忽略了系统要使用或实现的技术细节，称为基本叙述。事件流的参与者操作描述包含必要的特定信息（如：第2行提到了系编号、课程编号、班级编号以及教师编号），以使系统正确响应。

需要特别注意完整用例叙述中由参与者提供的输入细节。图8-17中，第2行标识了系输入的数据，显示了描述每个小组的信息可以重复。数据项相同，但它们的值会随着小组而有所不同。在用例叙述中事件流的右列只包含系统操作，每个系统响应开头处 “系统”被省略。

事件流
参与者操作	系统响应
1.在银行的客户带着银行卡使用ATM系统时用例启动。
2.银行客户输入银行卡密码。	3.系统验证银行客户的信息，然后显示消息以示正常状态。
4.银行客户输入取款金额。	5.系统验证正确性并记录该事务，然后显示消息。
6.银行客户完成取款后带着现金和银行卡离开。

图11 完整用例叙述中事件流的两列格式示例

用例:	提交公修课班级计划列表
参与者:	系
目的:	记录系公修课班级计划
概述:	系提交其将为下一个学期提供的公修课班级计划。每个班级的详细信息（系编号、课程编号、班级编号、最大座位数、上课地点以及教师编号）均记录在系统中。
类型:	基本
前置条件:	课程与教师信息已经输入到系统中。
后置条件:	系公修课班级计划保存在系统中。
特定要求:	系必须在输入每个小组后，于10秒内获得系统响应。
事件流
参与者操作	系统响应
1. 该用例在系提交其学期公修课班级计划时开始。
2. 该系提供计划中每个小组的系编号、课程编号、班级编号、最大座位数、上课时间、上课地点以及教师编号。	3. 记录系公修课班级计划信息。
4. 完成计划输入后，该系提示该计划完成。
候选事件流
第3行： 输入了无效的系编号和课程编号。 提示错误。返回到步骤2。 输入了无效的上课时间。提示错误。返回到步骤2。 输入了无效的上课地点。提示错误。返回到步骤2。 输入了无效的教师编号。提示错误。返回到步骤2。

图12 提交公修课班级计划列表的完整用例叙述

图13显示了用例“生成学校公修课班级计划列表”的完整叙述。

用例:	生成学校公修课班级计划列表
参与者:	学生、系、教授
目的:	生成大学公修课班级计划
概述:	根据教务处确定的计划，生成并显示某个学期的大学公修课班级计划
类型:	基本
前置条件:	必须输入所有的系公修课班级计划。
后置条件:	无。
特定要求:	学生、系、教授必须能够打印大学公修课班级计划副本。
事件流
操作	系统响应
1. 该用例在生成某个学期的大学公修课班级计划列表时开始。	2. 生成并显示公修课班级计划列表。

图14 生成学校公修课班级计划列表的完整用例叙述

因为定时业务事件的事件流始终如“该用例在时序需求事件触发系统响应时开始；系统生成一个（或多个）系统输出”的模式，事件流简单易理解，所以很少为这类事件编写完整用例叙述。

3．用例叙述的质量评估

用例是一种在系统内提供所需功能的过程，用例模型作为需求模型仅仅指定了需求的内容，没有说明如何实现这些需求。从事件分析开始，强调系统对事件的完整响应建模，良好的用例叙述详细描述了在参与者使用系统来完成某个过程时出现的操作顺序。识别出的参与者期望用例完成一个或多个功能，直到参与者的所有预期功能都被指定后，才算完成用例建模。事件表中每个事件包括系统输入和系统输出，或者仅有系统输入或系统输出，对应的作为系统内部动作的用例具有某些功能。用例的两个基本功能是生成系统输出和存储数据以备将来使用。

如果系统未生成输出，那么它就没有存在的理由——它没有为其用户创造任何价值。外部事件中，通常是通过向参与者提供直接输出完成用例。例如“学生选择班级”，当过程结束后，学生就接到了有价事物“学生班级列表”。衡量用例质量好坏的一种标准是，看其为参与者生成的有价事物。

另一种情况下，用例不直接为参与者生成有用的输出。例如，事件“系提交公修课班级计划列表”不生成任何输出。有用的输出是“大学公修课班级计划列表”，直到所有系都提交了自己的“系公修课班级计划列表”后，系统才能生成“大学公修课班级计划列表”完整信息。即，用例“提交系公修课班级计划列表”的所有实例必须在用例 “生成大学公修课班级计划列表”发生之前进行，仅在延迟后生成所需的输出。处理器中的系统内存会维护“系公修课班级计划列表”信息，直到准备使用该内存中的信息为止。因此，另一个用于衡量用例是否生成有价事物的标准是，看其在不能生成即时输出时，是否存储数据以备将来使用。

4．为高校公修课选课系统完成用例叙述

其余用例的完整用例叙述如图15和图16所示。到此，完成了高校公修课选课系统的用例模型。

用例:	选择班级
参与者:	学生
目的:	将学生登记到班级，并记录学生选择的班级。
概述:	学生针对本学期预选课程申请加入相应的班级小组，如果所选择的班级还有名额，系统就将学生加入到该班级。完成后系统为学生提供其选择成功的班级列表。
类型:	基本
前置条件:	必须存在学校公修课班级计划，学生信息已输入到系统中。
后置条件:	学生登记到班级中。
特定要求:	学生必须在10秒钟内获得系统响应。
事件流
参与者操作	系统响应
1. 该用例在学生选择某个班级时开始。
2. 学生提供自己的编号，以及选择的每个班级的系编号、课程编号和小组编号。	3. 验证学生输入的信息，若有名额就将学生添加到班级。
4. 学生确认不再选择课程小组。	5. 为学生生成班级列表。
6. 学生收到自己的班级列表。
候选事件流
第3行： 输入了无效的学生编号和课程编号。 提示错误。返回到步骤2。 输入了无效的小组编号。提示错误。返回到步骤2。 无名额。 通知学生。返回到步骤2。

图15 选择班级的完整用例叙述

用例:	生成班级花名册
参与者:	教授
目的:	为每位教师生成班级花名册。
概述:	在选课期结束时，生成并显示学期的每个班级花名册。
类型:	基本
前置条件:	学生已完成班级登记。
后置条件:	为教师提供班级花名册。
特定要求:	教师必须能够打印自己的班级花名册副本。
事件流
操作	系统响应
1. 该用例在生成学期的班级花名册时开始。	2. 生成并显示班级花名册。

图16 生成班级花名册的完整用例叙述

5 用例间的关系

除了在参与者和用例之间存在着关联关系，在用例之间也可存在一定的关系。例如，在一个用例中存在着几处重复使用的动作序列，在几个用例中存在着重复使用的动作序列，或一个用例的动作序列被特殊情况所修改。这些情况下，合理分离一个用例中的主要动作序列或分支动作序列会有助于对需求进行管理和理解。UML规范提供了用例间三种不同类型的关系：包含（include）、扩展（extend）以及继承（generalize）关系，它们的目的是标识并利用通用性。

1．包含

在两个或多个用例中经常存在着重复的动作序列。把重复的动作序列放在一个用例中，原有的用例（基本用例）再引入该用例（包含用例），这样就在用例间建立了包含关系。

作为包含关系的一个示例，图书的在库状态在登记借阅与归还时必须进行修改，保证读者可以即时查询图书的在库、已借出或已预定状态。重复的动作序列可以成为单独的共享用例，如图17所示。图中箭头的方向是从基本用例指向包含的用例，也就是说，基本用例是依赖于包含用例的。

图17包含关系的示例

可以把包含关系想象为基本用例调用包含用例（类似于子程序调用），基本用例仅仅依赖包含用例执行的结果，而不依赖包含用例的内部结构，显示其可重用性。

一个用例可以包含多个用例，一个用例也可以被多个用例包含。

2．扩展

扩展关系常用于用例被特殊情况所修改的情况。例如，某位学生在选择大学公修课班级时，可能因为该学生是运动员而允许其登记到已经满员的班级。这种情况下，不用为例外情况逐个编写特殊用例，可以从用例（基本用例）中把可能的行为描述部分抽取出来，放在另一个用例（扩展用例）中，基本用例再用其进行扩展。这样在描述基本动作序列的用例和描述可选动作序列的扩展用例之间就建立了扩展关系。

一个扩展点是用例中的一个位置，如果扩展条件为真，就可以插入扩展用例中描述的动作序列，并予以执行；如果扩展条件为假，扩展不会发生。

图18是事件流与用例图的扩展，箭头的方向是从扩展用例指向基本用例。

图18 扩展关系的示例

可以使用if条件语句来指定事件流中应用扩展的位置，扩展关系中基本用例（扩展点）的事件流非常短。图18显示了向选择班级用例叙述添加的条件语句，以选择适当的登记规定。图19和图20显示了扩展“登记运动员”和“登记非运动员”。

用例:	选择班级
参与者:	学生
目的:	将学生登记到班级，并记录学生选择的班级。
概述:	学生针对本学期预选课程申请加入相应的班级小组，如果所选择的班级还有名额，系统就将学生登记到该班级。完成后系统为学生提供其选择成功的班级列表。
类型:	基本
前置条件:	必须存在学校公修课班级计划，学生信息已输入到系统中。
后置条件:	学生登记到班级中。
特定要求:	学生必须在10秒钟内获得系统响应。
事件流
参与者操作	系统响应
1. 该用例在学生选择某个班级时开始。
2. 学生提供自己的编号。	3. 查看该学生是否是运动员。如果该学生是运动员，则执行“登记运动员”用例，否则，执行“登记非运动员”用例。
候选事件流
第3行： 输入了无效的学生编号。 提示错误。返回到步骤2。

图19 选择班级的完整用例叙述，其中显示了扩展点

用例:	登记运动员
参与者:	学生
目的:	将学生登记到班级，并记录学生选择的班级。
概述:	一位是运动员的学生选择本学期预选课程的班级小组。系统会将该学生加入到其选择的每个班级，即使所选择的班级已经满员。完成后系统为学生提供其选择成功的班级列表。
类型:	基本
前置条件:	已经完成了选择班级用例的步骤1到步骤3。
后置条件:	学生登记到班级中。
特定要求:	学生必须在10秒钟内获得系统响应。
事件流
参与者操作	系统响应
1. 该用例在学生请求选择班级期间已指示他或她是运动员时开始。
2. 学生提供需要选择的每个班级的系编号、课程编号和小组编号。	3. 验证学生输入的信息，将学生添加到班级。
4. 输入请求的班级后，学生确认不再继续选择班级。	5. 为学生生成班级列表。
6. 学生收到自己的班级列表。
候选事件流
第3行： 输入了无效的系编号和课程编号。 提示错误。返回到步骤2。 输入了无效的小组编号。提示错误。返回到步骤2。

图20登记运动员的完整用例叙述

用例:	登记非运动员
参与者:	学生
目的:	将学生登记到班级，并记录学生选择的班级。
概述:	学生针对本学期预选课程申请加入相应的班级小组，如果所选择的班级还有名额，系统就将学生加入到该班级。完成后系统为学生提供其选择成功的班级列表。
类型:	基本
前置条件:	已经完成了选择班级用例的步骤1到步骤3。
后置条件:	学生登记到班级中。
特定要求:	学生必须在10秒钟内获得系统响应。
事件流
参与者操作	系统响应
1.该用例在学生请求选择班级期间已指示他或她是非运动员时开始。
2. 学生提供需要选择的每个班级的系编号、课程编号和小组编号。	3. 验证学生输入的信息，若有名额就将学生添加到班级。
4. 输入请求的班级后，学生确认不再继续选择班级。	5. 为学生生成班级列表。
6. 学生收到自己的班级列表。
候选事件流
第3行： 输入了无效的系编号和课程编号。 提示错误。返回到步骤2。 输入了无效的小组编号。提示错误。返回到步骤2。 无名额。 通知学生。返回到步骤2。

图21 登记非运动员的完整用例叙述

若要在基本用例中表述可选的交互行为，就可以使用扩展关系。用这种方式把可选行为分离出来，通过扩展关系在扩展点使用它们。对例外行为处理建模时或对系统的可配置的功能建模时，也可使用扩展行为。

3．继承

用例之间的继承关系意味着子用例包含父用例的所有行为顺序以及扩展，还可以增加行为，或覆盖一般用例的行为。用从子用例指向一般用例的空心箭头的实线来表示用例之间的继承关系。

图22是用例之间继承关系的示例。父用例是Validate User，子用例有Retina Scan和Check Password两个。

图22继承关系的示例

尽管用例之间的三种关系都有助于重用，但它们之间是有区别的。一般来说，可以使用“is a”和“has a”来判断使用哪种关系。扩展关系和继承关系可类比于用例之间“is a”的关系，包含关系可类比于用例之间“has a”的关系。

扩展关系和继承关系相比，多了扩展点的概念，也就是说，一个扩展用例只能在基本用例的扩展点上进行扩展。

扩展关系中，基本用例一定是一个结构完整的用例，即是可以独立存在的用例。一个基本用例执行时，可以执行、也可以不执行扩展部分。

包含用例中，基本用例可能是、也可能不是一个结构完整的用例。执行基本用例时，一定会执行包含用例部分。