第3讲 用例和用例图.ppt

UML统一建模语言 主要内容 基本概念：用例、参与者、用例描述 用例之间的关系 用例描述 案例讲解 用例的历史 Ivar Jacobson于20世纪60－70年代在爱立信公司开发AKE、AXE系列系统时所提出。 85年博士论文与92年出版的用例驱动方法中正式详细论述 用例被认为是第二代面向对象技术的标志。 用例图的概念 用例图（Use Case Diagram）是显示一组用例、参与者以及它们之间关系的一种图。 用例图在UML中是非常特别的图形元素，它描述了用户希望如何使用一个系统。 用例图从用户的角度而不是开发者的角度来描述对软件产品的需求，分析产品所需的功能和动态行为。 用例（Use Case）的定义 用例代表系统中各个项目相关人员之间根据系统的行为所达成的契约。用例描述了在不同条件下，针对某一项目相关人员的请求，系统对其作出的响应。 用例指的是对一组动作的描述，系统通过执行这些动作将对用例的参与者产生可以看到的结果。用来描述参与者可以感受到的系统服务或功能。 用例定义的意义 用例实例是在系统中执行的一系列动作，这些 动作将生成特定执行者可见的价值结果。一个 用例定义一组用例实例。 用例的特点 用例是代表系统中各个项目相关人员之间就系统的行为所达成的契约。它有如下一些特点： 用例描述了用户提出的一些可见的需求； 用例可大可小； 用例对应一个具体的用户目标 用例对软件开发的意义 也就是说：面向对象的软件开发过程 以用例来驱动。 位于系统边界以外的一个实体，透过系统边界与系统进行有意义交互。 参与者未必是人，可以是一个外部系统。 在处理参与者时，应考虑其参与系统的身份，而不是人名或工作名。 参与者—识别思路 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 案例：库存管理系统 某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。 识别思路： 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付哪些硬件设备 系统需要和哪些外部系统交互 谁对系统运行产生的结果感兴趣 库存管理系统的参与者 识别用例的策略 （1）参与者希望系统提供什么功能？ （2）系统是否存储和检索信息？如果是，这个行为由哪个参与者触发? （3）当系统改变状态时，通知参与者吗？ （4）存在影响系统的外部事件吗？ （5）是哪个参与者通知系统这些事件？ 识别用例 识别用例 识别用例 识别用例 识别用例 识别用例 主要内容 基本概念：用例、参与者、用例描述 用例之间的关系 用例描述 案例讲解 关系 参与者与用例之间 关联关系 用例与用例之间 包含关系 (include) 扩展关系 (extend) 泛化关系 (generalization) 参与者与参与者之间 泛化关系 (generalization) 关系—参与者与用例之间 关联关系 描述参与者与使用用例之间的关系。在UML中，关系用实线表示，实线可以有箭头，也可以没有箭头。 例：参与者与用例 通过关联相连。 1）包含关系(include) 包含关系中一个用例总是使用另一个用例的功能 包含关系中基用例本身是不完整的。 例： 本例中，用例“Check Credit” 检查输入的信用卡号是否有效以及信用卡是否有足够的资金。 2）扩展关系(extend) 扩展关系允许一个用例（可选）扩展另一个用例的功能。 扩展只能发生在基用例的序列中某个特定的点上，这个点叫扩展点。 扩展关系中基用例本身是完整的。 用例间的关系——扩展关系 包含关系与扩展关系的区别 用例间的关系——泛化关系 3）泛化关系（也称类属或概括关系） 泛化关系其实是子类与父类的关系。象类之间的泛化关系一样，用例和参与者也可以继承另一个用例和参与者。 关系—参与者与参与者之间 参与者的泛化 在“图书管理系统”中，可以认为“读者”是“学生读者”和“教师读者”的泛化，而“学生读者”还可以具体化为“本科生读者”和“研究生读者”；同样，“图书管理员”也是“采购员”、“ 编目员”及“借阅人员”的泛化。 主要内容 基本概念：用例、参与者、用例描述 用例之间的关系 用例描述 案例讲解 用