第五章用例图

1、 第五章 用例图学习内容n什么叫用例图n用例图的构成要素n用例的重要元素n用例之间的关系n使用Rose创建用例的步骤说明什么叫用例图 由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图。参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。什么叫用例图n用例图用于定义系统的功能需求，用例图用于定义系统的功能需求，用于需求分析阶段。用于需求分析阶段。主要主要确定确定“谁使用系统以及做谁使用系统以及做什么什么”。n用例图仅从参与者使用系统的角度描述系统中的信息。

2、用例图仅从参与者使用系统的角度描述系统中的信息。常用来对需求建模。常用来对需求建模。n用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。的服务。n下图描述了一个学生成绩管理系统的用例图，它是一个实际系统简化后的示例。下图描述了一个学生成绩管理系统的用例图，它是一个实际系统简化后的示例。什么叫用例图n在用例建模中，为了更加清楚的描述用例或者参与者，会使用到注释。什么叫用例图n用例图是需求分析中的产物，主要作用是描述参与者和用例之间的关系，帮助开发人员可视化的了解系统的功能。借助于用例图，系统

3、用户、系统分析人员、系统设计人员、领域专家能够以可视化的方式对问题进行探讨，减少了大量交流上的障碍，便于对问题达成共识。n用例图可视化地表达了系统的需求，具有直观、规范等优点，克服了纯文字性说明的不足。n用例方法是完全从外部来定义系统功能，它把需求和设计完全的分离开来。我们不用关心系统内部是如何完成各种功能的，系统对于我们来说就是一个黑箱子。用例图包含的元素用例图包含的元素参与者（参与者（Actor）用例（用例（Use Case）关联关系（关联关系（Association）包含关系（包含关系（Include）扩展关系（扩展关系（Extend）泛化关系（泛化关系（Generalization）

4、n用例图的主要元素是用例和用例图的主要元素是用例和参与者参与者：所谓用例是指对系：所谓用例是指对系统提供的功能统提供的功能( (或系统的用途或系统的用途) )的描述；的描述；参与者参与者是指可能是指可能使用用例的人或外部系统。两者的关系是使用用例的人或外部系统。两者的关系是“谁使用了哪谁使用了哪个用例个用例”. .n用例图着重于从系统外部用例图着重于从系统外部参与参与者的角度来描述系统需要者的角度来描述系统需要提供哪些功能，并且指明这些功能的参与者是谁。提供哪些功能，并且指明这些功能的参与者是谁。用例图的构成要素n参与者（Actor）是指存在于系统外部并直接与系统进行交互的人、系统、子系统或类

5、的外部实体的抽象。n每个参与者可以参与一个或多个用例，每个用例也可以有一个或多个参与者。n在用例图中使用一个人形图标来表示参与者，参与者的名字写在人形图标下面。参与者n理解：Actor不是指人，而是指代表某一种特定功能的角 色，因此同一个人可能对应很多个Actor。Actor可以指外部系统和设备。 如果一个角色的操作是由另外一个角色代理完成 的，请建立该角色到另外角色的依赖。参与者参与者识别思路识别思路n谁使用该系统谁使用该系统n谁改变系统的数据谁改变系统的数据n谁从系统获取信息谁从系统获取信息n谁需要系统的支持以完成日常工作任务谁需要系统的支持以完成日常工作任务n谁负责维护、管理并保持系统正

6、常运行谁负责维护、管理并保持系统正常运行n系统需要应付那些硬件设备系统需要应付那些硬件设备n系统需要和那些外部系统交互系统需要和那些外部系统交互n谁对系统运行产生的结果感兴趣谁对系统运行产生的结果感兴趣案例：库存管理系统 某汽车制造厂需要一套库存管理系统某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，员定期盘点库存，通知供应商

7、供货，对长期积存的货物，申请退货。对长期积存的货物，申请退货。识别思路：n谁使用该系统n谁改变系统的数据 n谁从系统获取信息 n谁需要系统的支持以完成日常工作任务 n谁负责维护、管理并保持系统正常运行n系统需要应付那些硬件设备n系统需要和那些外部系统交互 n谁对系统运行产生的结果感兴趣 操作员，管理员操作员，管理员操作员，管理员领料员,退料员,操作员,管理员,供应商管理员生产系统, 供应商系统操作员,管理员,领料员,退料员库存管理系统的参与者操作员管理员领料员退料员供应商生产系统供应商系统时间识别参与者 寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还

8、要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？用例图的构成要素n由于参与者实质上也是类，所以它拥有与类相同的关系描述，即参与者与参与者之间主要是泛化关系（或称为“继承”关系）。n泛化关系的含义是把某些参与者的共同行为提取出来表示成通用行为，并描述成超类。泛化关系表示的是参与者之间的一般/特殊关系，在UML图中，使用带空心三角箭头的实线表示泛化关系。用例图的构成要素n在项目开发过程中，边界是一个非常重要的概念。这里说的系统边界是指系统与系统之间的界限。通常我们所说的系统可以认为是由一系列的相互作用的元素形成的具有特定功能的有机整体。n系统同时又是相对的，一个系

9、统本身又可以是另一个更大系统的组成部分，因此，系统与系统之间需要使用系统边界进行区分开来。我们把系统边界以外的同系统相关联的其他部分，称之为系统环境。 用例 （Use Case） 用例用例描述了系统的功能需求，描述了系统的功能需求，是系统的一组动作是系统的一组动作序列的描述序列的描述. .用例的本质是用户与计算机之间的一次交互作用用例的本质是用户与计算机之间的一次交互作用。在。在UML的概念中用例是系统作出的一系列动作的概念中用例是系统作出的一系列动作,而参与者能够察觉到这一系列动作的结果。而参与者能够察觉到这一系列动作的结果。UML中用例用一个椭圆来表示，用例命名用动词中用例用一个椭圆来表示

10、，用例命名用动词，名字可以写在椭圆的内部或下方。，名字可以写在椭圆的内部或下方。登记课程登记课程用例的重要元素n任何用例都不能在缺少参与者的情况下独立存在。同样，任何参与者也必须要有与之关联的用例。所以识别用例的最好方法就是从分析系统参与者开始，在这个过程中往往会发现新的参与者。n可以通过以下问题来寻找用例： (1)参与者希望系统提供什么功能？ (2)参与者是否会读取、创建、修改、删除、存储系统的某种信息？如果是的话，参与者又是如何完成这些操作的？ (3)参与者是否会将外部的某些事件通知给系统？ (4)系统中发生的事件是否通知参与者？ (5)是否存在影响系统的外部事件。识别用例 Email客户

11、端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。识别用例 一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例用例n如何判断一个用例是否是一个优秀的用例呢？用例是否描述了应该做什么，而不是如何做？用例的描述是否采取了参与者的视点？用例是否对参与者有价值？用例描述的时间流是否是一个完整场景？是否所有的参与者、用例都有相应的关联用例或关联参与者？ 案例：零件销售系统案例：零件销售系统的参与者案例：零件销售系统的用例注册注册会员登录

12、会员登录管理订单管理订单检索零件检索零件购物购物结帐结帐修改个人资料修改个人资料查询历史纪录查询历史纪录货管员登录货管员登录管理价格管理价格管理库存管理库存打印报表打印报表开放帐户开放帐户经理登录经理登录检索会员检索会员检查帐户检查帐户潜在会员潜在会员会员会员货管员货管员经理经理时间时间案例：零件销售系统注册注册会员登录会员登录管理订单管理订单检索零件检索零件购物购物结帐结帐修改个人资料修改个人资料查询历史纪录查询历史纪录货管员登录货管员登录管理价格管理价格管理库存管理库存打印报表打印报表开放帐户开放帐户经理登录经理登录检索会员检索会员检查帐户检查帐户潜在会员潜在会员会员会员货管员货管员经理经

13、理时间时间用例之间的关系n包含关系指用例可以简单地包含其他用例具有的行为，并把它所包含的用例行为作为自身行为的一部分。在UML中，包含关系是通过带箭头的虚线段加字样来表示，箭头由基础用例(Base)指向被包含用例(Inclusion)。用例之间的关系n包含关系代表着基础用例会用到被包含用例，具体的讲就是将被包含用例的事件流插入到基础用例的事件流中。需要注意的是，包含关系是UML1.3中的表述，在UML1.1中，同等语义的关系被表述为使用(uses)。用例之间的关系n在处理包含关系时，具体的做法就是把几个用例的公共部分单独的抽象出来成为一个新的用例。主要有两种情况需要用到包含关系：n第一，多个用

14、例用到同一段的行为，则可以把这段共同的行为单独抽象成为一个用例，然后让其他用例来包含这一用例。n第二，某一个用例的功能过多、事件流过于复杂时，我们也可以把某一段事件流抽象成为一个被包含的用例，以达到简化描述的目的。用例之间关系的理解：用例之间关系的理解：Include包含关系的应用包含关系的应用n在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例“打印回执”，而原有的查询、取现、转帐三个用例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提

15、高了用例模型的可维护性。 n扩展关系允许一个用例（可选）扩展另一个用例的功能。扩展关系允许一个用例（可选）扩展另一个用例的功能。n当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称作基用例，作基用例，后者常称为扩展用例。后者常称为扩展用例。这种关系被称为扩展关系。这种关系被称为扩展关系。n扩展用例只有在基用例中的某种条件满足时才能执行，如果没有基用例扩展用例只有在基用例中的某种条件满足时才能执行，如果没有基用例的运行，扩展用例不能运行的运行，扩展用例不能运行。n基用例可以单独存在，扩展关系中基用例本身是完整的。但在一定的

16、条基用例可以单独存在，扩展关系中基用例本身是完整的。但在一定的条件下，他的行为可以被另一个用例的行为延伸。扩展只能发生在基用例件下，他的行为可以被另一个用例的行为延伸。扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点。的序列中某个特定的点上，这个点叫扩展点。n方向：由扩展用例指向基本用例方向：由扩展用例指向基本用例用例间的关系用例间的关系扩展关系扩展关系(extend)扩展关系扩展关系用例之间的关系n包含用例与扩展用例的区别相对于基用例，扩展用例是可选的，而包含用例则不是。如果缺少扩展用例，基用例还是完整的，而缺少包含用例，则基用例就不完整了。扩展用例的执行需要满足某种条件，而包含用

17、例不需要。扩展用例的执行会改变基用例的行为，而包含用例不会。包含关系与扩展关系的区别包含关系与扩展关系的区别用例之间的关系n用例的泛化指的是一个父用例可以被特化形成多个子用例，而父用例和子用例之间的关系就是泛化关系。n在用例的泛化关系中，子用例继承了父用例所有的结构、行为和关系，子用例是父用例的一种特殊形式。n子用例还可以添加、覆盖、改变继承的行为。在UML中，用例的泛化关系通过一个三角箭头从子用例指向父用例来表示。用例之间的关系n泛化的示例：银行存款有两种方式，一种是银行柜台存款，一种是ATM机存款。在这里，银行柜台存款和ATM机存款都是存款的一种特殊方式，因此“存款”为父用例，“银行柜台存

18、款”和“ATM机存款”为子用例。 用例图-实例n实例1 参与者之间的泛化关系n 参与者：经理，安全主管，保安n 用例：管理人事，批准预算，批准安全证书，监视周边n 在参与者之间不存在泛化关系的情况下，各个参与者参与 用例的情况分别是：经理参与用例管理人事和批准预算；安全主管参与用例批准安全证书；保安参与用例监视周边。由于安全主管与经理，安全主管与保安之间泛化关系的存在，意味着安全主管可以担任经理和保安的角色，就能够参与经理和保安参与的用例。这样，安全主管就可以参与全部4个用例。但经理或者保安却不能担任安全主管的角色，也就不能参与用例批准安全证书。用例图-实例n实例2 用例之间扩展和包含关系n

19、用例的上下文是：短途旅行但汽车的油不足以应付全部路程。那么为汽车加油的动作在旅行的每个场景(事件流)中都会出现，不加油就不会完成旅行。吃饭则可以由司机决定是否进行，不吃饭不会影响旅行的完成。 用例图-实例实例3. 航空售票的用例图参与者(actor)：clerk，监督员，信用卡服务商，信息亭用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales参与者Clerk参与(或称发起)Buy tickets和Buy Subscription 两个用例(关联关系)。这两个用例的事件流都包含Make charges用例(

20、包含关系)。系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。该系统主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales这几个功能。该系统主要面向的用户(参与者)：clerk，监督员，信用卡服务商，信息亭。 信息亭 Clerk Buy tickets Buy Subscription 信用卡服务商 Make charges 监督员 Survey sales 参与者 用例 Box Office 系统 关系 用例的重要元素n用例的粒度指的是用例所包含

21、的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。n如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。n如果用例数目过多会造成用例模型过大和引入设计困难大大提高。 如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。用例分析是处于系统的需求分析阶段，这个用例分析是处于系统的需求分析阶段，这个阶段应该尽量的避免去考虑系统实现的细阶段应该尽量的避免去考虑系统实现的细节问题。节问题。n怎样确定用例的粒度？n用例的粒度（用例的大小）可大可小，一般一个系 统宜控制在20个用例左右。n用例是系统级的、抽象的描述，不是

22、细化的（是做 什么，非怎样做）n对复杂的系统可以划分为若干子系统处理。用例的重要元素用例的重要元素比如：网站后台管理系统中的会员信息维护用例，管理员需要进行添加会员信息、修改会员信息、删除会员信息等操作。我们还可以根据具体的操作把它抽象成3个用例，它展示的系统需求和单个用例是完全一样的。用例的重要元素n对于每一个用例，我们还需要有详细的描述信息，以便让别人对于整个系统有一个更加详细的了解，这些信息包含在用例规约之中。n每一个用例的用例规约都应该包含以下内容： (1)简要说明:对用例作用和目的的简要描述。 (2)事件流:事件流包括基本流和备选流。基本流描述的是用例的基本流程，是指用例“正常”运行

23、时的场景。 (3)用例场景:同一个用例在实际执行的时候会有很多不同的情况发生，称之为用例场景，也可以说用例场景就是用例的实例。 (4)特殊需求: 特殊需求指的是一个用例的非功能性需求和设计约束。特殊需求通常是非功能性需求，包括可靠性、性能、可用性和可扩展性等。例如法律或法规方面的需求、应用程序标准和所构建系统的质量属性等。 (5)前置条件: 执行用例之前系统必须所处的状态。例如，前置条件是要求用户有访问的权限或是要求某个用例必须已经执行完。 (6)后置条件:用例执行完毕后系统可能处于的一组状态。例如，要求在某个用例执行完后，必须执行另一个用例。scenario：也称情景，场景，情节，剧本等。：

24、也称情景，场景，情节，剧本等。是参与者和被讨论系统之间的一系列特定活动是参与者和被讨论系统之间的一系列特定活动和交互，通常被称为和交互，通常被称为“用例的实例用例的实例”。在。在UML中，中，scenario指贯穿指贯穿use case的一条单一路的一条单一路径，用来显示径，用来显示use case中某种特殊情况。中某种特殊情况。定义：定义：scenario is a sequence of actions that illustrates behavior. A scenario may be used to illustrate an interaction or the executio

25、n of a use case instance.什么是场景（Scenarios）n场景是Use Case的实例n每一个Use Case都有一个场景网n主场景（happy day scenarios)n所有都很好n次场景n除了主场景以外的部分n场景可以在交互图中被描述n有两种类型的交互图n序列图n协作图 在“订货”这个用例中，包含着几个相关的scenario：一个是订货进行顺利的scenario；一个是相关货源不足的scenario；一个是涉 及购货者的信用卡被拒的scenario等等。这些scenario的组合构成了一个用例。用例分析n 用例图的绘制流程 用例分析n一般来说，建立用例模型的步

26、骤为：1.捕获需求；2.确定系统的边界范围，找出系统的参与者；3.确定每一个参与者所希望的系统行为，参与者希望系统做的每件事成为一个用例；4.描述用例的基本过程；5.把公共系统行为分解为新用例，供其他用例引用；6.把一些变更的行为分解为扩展用例；7.绘制用例图；8.把特殊情况的用例画成单独的子用例图。锻炼与经验锻炼与经验用例图-实例这张用例图首先定义了三个基用例：预订座位、安排这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账座位和处理结账 客户通过客户通过Internet启动启动“预订座位预订座位”用例，在用例，在“预订座位预订座位”用例的用例的执行过程中，将执行过程中，将“检查座

27、位信息检查座位信息”（被包含用例），如果没有空（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例扩展用例“处理等候队列处理等候队列”。总台服务员在客户到棋牌馆时，启动总台服务员在客户到棋牌馆时，启动“安排座位安排座位”用例，在执行用例，在执行过程中，将启动被包含用例过程中，将启动被包含用例“检查座位信息检查座位信息”。当客户要离开棋牌馆时，总台服务员将启动当客户要离开棋牌馆时，总台服务员将启动“处理结账处理结账”用例，用例，并且定义了两种并且定义了两种“收款收款”用例，一个是用例，一个是“处理现金结

28、账处理现金结账”，另一，另一个是个是“处理银行卡结账处理银行卡结账”，而后一个用例将通过与外部系统，而后一个用例将通过与外部系统“银银联联POS系统系统”交互来完成。交互来完成。使用Rose创建用例的步骤说明n“学生信息管理系统”部分功能性需求包括以下内容： （1）系统管理员登录后可以对班级的基本信息进行增加、删除、修改、查询等操作。学校领导登录后可以对班级基本信息进行查询操作。 （2）教师登录后可以对学生的考试成绩进行录入、删除、修改、查询等操作。学生登录后可以对考试成绩进行查询操作。 （3）学生登录后可以了解所有选修课程的具体信息，可以根据自己的需要选择不同课程。系统管理员登录后可以增加、

29、修改、查询、删除选修课程。 （4）系统管理员可以对账号进行创建、设置、查看、删除等操作。 使用Rose创建用例的步骤说明n对于一个学校来说，最重要的就是教育学生成才，所以我们首先要考虑到的参与者就是学生学生。n要给学生上课，必然就需要教师教师。教师负责教育学生、并且在日常管理中可以查询学生的基本信息、查询学生的考试成绩。n作为一个学校，除了教师和学生，还有不可或缺的就是校领导校领导。为了便于校领导掌握学校的基本情况，加强对学校的管理导. n不管什么系统，基本都会有比较专业的人员来负责管理系统，本系统也不例外。系统管理员系统管理员除了负责维护系统的日常运行，还要进行录入学生基本信息、维护选课信息

30、等工作。使用Rose创建用例的步骤说明n系统管理员系统管理员直接参与的用例为登录、找回密码、查看班级基本信息、删除班级基本信息、修改班级基本信息和录入班级基本信息。n校领导校领导直接参与用例登录、找回密码和查看班级基本信息。n当登录过程中发生忘记密码的情况，就需要使用找回密码的功能来找回密码，而在正常情况下用不到找回密码这个功能所以用例找回密码”和用例登录之间是扩展关系。 使用Rose创建用例的步骤说明n教师参与用例录入成绩、修改成绩、保存成绩、查询成绩、删除成绩和登录。n学生参与用例登录和查询成绩。因为修改成绩和录入成绩的时候都要保存成绩，所以将保存成绩抽象出来作为单独的一个用例。n用例录入

31、成绩、修改成绩和用例保存成绩之间是包含关系，用例找回密码和用例登录之间是扩展关系。使用Rose创建用例的步骤说明n学生作为参与者直接参与用例查看课程信息、按课程编号查看、按课程名查看、选择课程、删除已选n课程、登录和找回密码。系统管理员参与用例登录、找回密码和“维护课程信息”。其中查看课程信息有两种方式，一种是按照课程名查看，另一种是按照课程编号查看。所以查看课程信息是父用例，而按照课程名查看和按照课程编号查看是子用例，他们之间的关系是泛化关系。n用例找回密码和用例登录之间是扩展关系。使用Rose创建用例的步骤说明n系统管理员参与用例创建新账号、设置账号、设置账号基本信息、设置账号权限、查看账

32、号和删除账号。n在设置帐号时，主要分为设置账号的基本信息和设置账号的权限，为了便于修改和维护，将这两个功能分别抽象为两个用例。所以用例设置账号基本信息、设置账号权限和用例设置账号之间是包含关系。小王是一个爱书之人，家里各类书籍已过千册，而平时小王是一个爱书之人，家里各类书籍已过千册，而平时又时常有朋友外借，因此需要一个个人图书管理系统。又时常有朋友外借，因此需要一个个人图书管理系统。该系统应该能够将书籍的基本信息按计算机类、非计算该系统应该能够将书籍的基本信息按计算机类、非计算机类分别建档，实现按书名、作者、类别、出版社等关机类分别建档，实现按书名、作者、类别、出版社等关键字的组合查询功能。在

33、使用该系统录入新书籍时系统键字的组合查询功能。在使用该系统录入新书籍时系统会自动按规则生成书号，可以修改信息，但一经创建就会自动按规则生成书号，可以修改信息，但一经创建就不允许删除。该系统还应该能够对书籍的外借情况进行不允许删除。该系统还应该能够对书籍的外借情况进行记录，可对外借情况列表打印。另外，还希望能够对书记录，可对外借情况列表打印。另外，还希望能够对书籍的购买金额、册数按特定时间周期进行统计籍的购买金额、册数按特定时间周期进行统计 用例分析案例用例分析合并需求获得用例合并需求获得用例用例分析特性用例FEAT09.记录外借情况FEAT10.外借状态能够自动反应在书籍信息中UC04.登记外借 信息FEAT11.按人、按书查询外借情况FEAT12.列出所有的外借情况 FEAT14.所有查询、列表、统计功能应可以单独对 计算机类或非计算机类进行UC05.查询外借 信息FEAT13