第9次课uml04.用例建模用例图130913.pptVIP

面向对象分析与设计Object-Oriented Analysis Design;-*-;第04章 用例建模;-*-;由参与者（Actor）、用例（Use Case）以及它们之间的关系构成的用于描述系统功能的动态视图称为用例图（Use Case Diagram）。 要在用例图上显示某个用例，可绘制一个椭圆，然后将用例的名称放在椭圆的中心或椭圆下面的中间位置。 要在用例图上绘制一个参与者（表示一个系统用户），可绘制一个人形符号。 参与者和用例之间的关系使用带箭头或者不带箭头的线段来描述，箭头表示在这一关系中哪一方是对话的主动发起者，箭头所指方是对话的被动接受者。;一、 什么叫用例图;持有银行信用卡的自动取款机用户;Use Case 对开发的意义;一、 什么叫用例图;;-*-;;参与者是系统外部的一个实体，以某种方式参与用例的执行过程。是为了完成一个事件与系统进行交互的实体，是与系统交互作用的外部用户、进程或??他系统的理想化概念。 在UML中，参与者用名字写在下面的人形图标表示。 ;参与者由它们参与用例时所担当的角色来表示。;*;*;参与者有三大类： ⑴ 系统用户 ⑵ 与所建造的系统交互的其他系统 ⑶ 可以运行的进程。 第一类参与者是真实的人，即用户，是最常见的参与者，几乎存在于每一个系统中。 命名这类参与者时，应当按照业务而不是位置命名。按照业务而不是位置命名可以获得更稳定的参与者。 第二类参与者是其他的系统。（医院医保系统和卫生局的医保系统） 第三类参与者是一些可以运行的进程。（时间、完成某个进程方可触发用例）;-*-;在对参与者建模的过程中，开发人员必须牢记以下几点： ⑴ 参与者对于系统而言总是外部的，因此它们可以处于人的控制之外； ⑵ 参与者可以直接或间接地同系统交互，或使用系统提供的服务以完成某件事务； ⑶ 参与者表示人和事物与系统发生交互时所扮演的角色，而不是特定的人或特定的事物； ⑷ 一个人或事物在与系统发生交互时，可以同时或不同时扮演多个角色； ⑸ 每一个参与者需要一个具有业务一样的名字，在建模中不推荐使用类似与“NewActor”或“新参与者”的名字；;在对参与者建模的过程中，开发人员必须牢记以下几点： ⑹ 每一个参与者必须有简短的描述，从业务角度描述参与者是什么； ⑺ 和类一样，参与者可以具有表示参与者的属性和可以接受的事件，但使用得不频繁。 ;*;寻呼台系统：用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑；;1、机票购买者通过登录网站购买机票，机票购买者就是actor;3、如果机票购买者通过呼叫中心的自动语音预订机票，那么呼叫中心就成了机票预订系统的一个actor;*;*;-*-;*;*;具体可以通过查找事件的方式来识别用例：;具体可以通过查找事件的方式来识别用例： 主语＋动词＋宾语 简洁：参与者使用系统达到目标 ;*;;-*-;-*-;-*-;执行者视角： （状语）动词+（定语+ ）宾语;Email客户端（如：outlook express），A在北京发邮件给上海的B，系统提醒B你有“新邮件”，B收邮件;*;*;*;*;*;用例的粒度指的是用例所包含的系统服务或功能单元的多少。用例的粒度越大，用例包含的功能越多，反之则包含的功能越少。 如果用例的粒度很小，得到的用例数就会太多。反之，如果用例的粒度很大，那么得到的用例数就会很少。 如果用例数目过多会造成用例模型过大和引入设计困难大大提高。如果用例数目过少会造成用例的粒度太大，不便于进一步的充分分析。 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言;三、用例的重要元素;-*-;;关联关系表示参与者和用例之间的通信。 用例与其参与者之间的关联关系用带箭头的直线表示。;如果系统中一个或多个用例是某个一般用例的特殊化时，就需要使用用例的泛化关系。 在UML中，用例泛化与其他泛化关系的表示法相同，用一个三角箭头从子用例指向父用例。;用例与用例之间的关系;用例与用例之间的关系; include ;被包含用例称作提供者用例（基本用例），包含用例称作客户用例，提供者用例提供功能给客户使用。;用例与用例之间的关系;用例与用例之间的关系;用例与用例之间的关系;在UML中，扩展关系表示为虚线箭头加extend字样，箭头指向被扩展的用例（即基础用例）。 基础用例的扩展增加了原有的语义，此时是基础用例而不是扩展用例被作为例子使用。;基础用例不必知道扩展用例的任何细节，它仅为其提供扩展点。 基础用例即使没有扩展用例也是完整的。 只有特定的条件发生，扩展用例才被执行。 扩展关系为处理异常或构建灵活的系统框架提供了一种十分有