第五章用例图.pptVIP

什么叫用例图 用例图用于定义系统的功能需求，用于需求分析阶段。主要确定“谁使用系统以及做什么”。 用例图仅从参与者使用系统的角度描述系统中的信息。常用来对需求建模。 用例图显示谁将是相关的用户、用户希望系统提供什么服务以及用户需要为系统提供的服务。 下图描述了一个学生成绩管理系统的用例图，它是一个实际系统简化后的示例。 用例图包含的元素 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 用例图的主要元素是用例和参与者：所谓用例是指对系统提供的功能(或系统的用途)的描述；参与者是指可能使用用例的人或外部系统。两者的关系是“谁使用了哪个用例”. 用例图着重于从系统外部参与者的角度来描述系统需要提供哪些功能，并且指明这些功能的参与者是谁。 参与者 理解： Actor不是指人，而是指代表某一种特定功能的角 色，因此同一个人可能对应很多个Actor。Actor可以指外部系统和设备。 如果一个角色的操作是由另外一个角色代理完成 的，请建立该角色到另外角色的依赖。 参与者—识别思路 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 案例：库存管理系统 某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。 识别思路： 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 库存管理系统的参与者 识别参与者 寻呼台系统。用户如果预定了天气预报，系统每天定时给他发天气消息；如果当天气温高于35度，还要提醒用户注意防暑。 这个叙述里，谁是寻呼台系统的Actor? 用户？气温？时间？ 识别用例 Email客户端（如：outlook express），A在北京发邮件给深圳的B，系统提醒B”你有新邮件”，B收邮件。 识别用例 一个论坛类的应用，用户可以提问，别人来回答，如果有自己问题被解答的话，就给发问者发一份邮件通知。 注意：发邮件这个用例可以是单独的用例，也可以是由回答用例扩展出来的用例 用例 如何判断一个用例是否是一个优秀的用例呢？ ①用例是否描述了应该做什么，而不是如何做？ ②用例的描述是否采取了参与者的视点？ ③用例是否对参与者有价值？ ④用例描述的时间流是否是一个完整场景？ ⑤是否所有的参与者、用例都有相应的关联用例或关联参与者？ 案例：零件销售系统 用例之间关系的理解：Include 包含关系的应用 在ATM机中，如果查询、取现、转帐这三个用例都需要打印一个回执给客户，我们就可以把打印回执这一部分内容提取出来，抽象成为一个单独的用例“打印回执”，而原有的查询、取现、转帐三个用例都会包含这个用例。每当以后要对打印回执部分的需求进行修改时，就只需要改动一个用例，而不用在每一个用例都作相应修改，这样就提高了用例模型的可维护性。 扩展关系允许一个用例（可选）扩展另一个用例的功能。 当某个新用例在原来的用例基础上增加了新的步骤序列，则原用例被称作基用例，后者常称为扩展用例。这种关系被称为扩展关系。 扩展用例只有在基用例中的某种条件满足时才能执行，如果没有基用例的运行，扩展用例不能运行。 基用例可以单独存在，扩展关系中基用例本身是完整的。但在一定的条件下，他的行为可以被另一个用例的行为延伸。扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点。 方向：由扩展用例指向基本用例 扩展关系 用例之间的关系 包含用例与扩展用例的区别 ①相对于基用例，扩展用例是可选的，而包含用例则不是。 ②如果缺少扩展用例，基用例还是完整的，而缺少包含用例，则基用例就不完整了。 ③扩展用例的执行需要满足某种条件，而包含用例不需要。 ④扩展用例的执行会改变基用例的行为，而包含用例不会。 包含关系与扩展关系的区别 用例图-实例 用例图-实例 用例图-实例 用例的重要元素 用例分析是处于系统的需求分析阶段，这个阶段应该尽量的避免去考虑系统实现的细节问题。 怎样确定用例的粒度？ 用例的粒度（用例的大小）可大可小，一般一个系 统宜控制在20个用例左右。 用例是系统级的、抽象的描述