第2章用例建模祥解.pptVIP

识别用例 应该怎样发现用例？通常很难判断某个用例是否合理。任务可以在不同粒度级别上组合，可能是一个或几个简单步骤，也可能是一个企业级的复杂活动。 对于ATM取款机系统，下面哪些是有效的用例？ 取款 读卡 登陆 打印回执单 可以认为这些都是用例，但它们处于不同的级别，依赖于系统的边界、参与者和目标。 系统中， “什么是合理的用例？”或者说“对应用的需求来说，在什么级别上描述用例最有帮助？” 答：应专注于“基本业务过程”(EBP)级别的用例。 EBP定义：由一个人在某个时间某个地点执行的一项任务，可产生可见或可度量的业务价值。 例如，ATM系统，取款是EBP级别上的用例，而登陆、打印等只是辅助“取款”目标的子功能目标，不是EBP级别上的用例。 如何识别正确的用例？ 用例的特征 用例是相对独立的。 用例的执行结果对参与者来说是可观测的和有意义的。 必须由一个参与者发起，不存在没有参与者的用例。 必然是以动宾短语形式出现的。 图 3 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 本章内容 用例的概念 用例格式及编写规范 定义用例的方法 用例图的UML表示 用例图 用例图(use case diagram) －显示一组用例、参与者以及它们之间的关系的图。 －在UML中，一个用例模型若干个用例图描述。例如 登录 发送消息 查询接到的消息列表 普通用户 查询特定消息 用例图包含6个元素： 参与者（Actor） 用例（Use Case） 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 用例关系： 关联关系（Association） 包含关系（Include） 扩展关系（Extend） 泛化关系（Generalization） 用例间的关系 关联关系（Association） 表示参与者与用例之间的关系 处理销售 收款员 处理租金 用例间的关系 用例彼此之间可能具有联系，比如：处理信用卡支付用例可作为处理销售、处理租金等常见用例的一部分。 注意：避免陷入用例关系的陷阱 别花过多时间争论在用例图中如何关联用例，而不关注更重要的工作：编写用例文本。 包含关系（include）--主要目的是避免用例文本的重复编写 一个用例包含一些行为，这些行为都是其自身的一部分，但由于复杂性等原因将它分离出来成为一个用例，这称作用例间的包含关系。 比如上面所说的：处理销售、处理租金等用例包含处理信用卡支付用例 处理销售 收款员 处理租金 信用卡支付 include include 用例间的关系 包含关系的特点 包含用例（客户用例）执行，则被包含用例（提供者用例）必须执行 什么时候使用包含关系？ 如果两个以上的用例有大量一致的功能，则可以将这个功能分解到另一个用例中，其他用例可以和这个用例建立包含关系 一个用例的功能太多时，可以用包含关系建模成两个以上的用例，降低用例的复杂度 用例间的关系 扩展关系（extend） 可以将可选路径中的场景抽象为扩展关系。 扩展关系的特点 基础用例没有扩展用例也是完整的用例 基础用例被执行时，一般不会涉及扩展用例，只有特定的条件发生，扩展用例才可能被执行，这是与包含关系的差别 处理销售 收款员 处理租金 信用卡支付 include include 处理证券支付 extend 网上购物的部分用例 用例间的关系 泛化关系（Generalization） 两个或更多用例在行为、结构、目的等方面存在共性时，可使用泛化关系。 收款员 几种关系的比较 泛化和扩展表示用例之间的 “is a”，包含关系表示用例之间的“has a”。 扩展关系的基本用例是 well formed 的。 基本用例可以独立存在。一个基本用例执行时，可以执行或不执行扩展用例。（可选） 包含关系的基本用例可以不是或是 well formed 的， 执行基本用例时，一定会执行包含用例。 几种关系的比较 关系类型 说明 表示符号 关联 actor与use case之间 泛化 actor之间或use case之间 包含 use case之间 扩展 use case之间 思考题 某企业要求开发一个企业管理系统，并与原来的财务系统相连接，谁是actor? 某企业要求开发一个企业管理系统，并改造旧有的财务系统，成为管理系统的一部分，谁是actor? 商品销售系统，顾客通过网络下单后，系统计算出总计金额、税金、运费，并将数目传递给一个外挂的会计系统，该系统是另外购买的，谁是actor? 下列用例的名称是否合理？ 思考题 以下关于登录的用例编写，请考虑其是否合理，如果不合理，应该如何修改？ 1. 系统显示