03-用例图.pptVIP

Example 2 习题 要点：用例的粒度(2) “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 要点：用例的粒度(3) 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 Email客户端（如：outlook express），A在北京发邮件给上海的B，系统定时提醒B你有“新邮件”，B收邮件。 思考题：识别用例 发出箭头的事物“is a”箭头指向的事物。泛化关系是一般和特殊关系，发出箭头的一方代表特殊的一方，箭头指向的一方代表一般一方。特殊一方继承了一般方的特性并增加了新的特性。 泛化 参与者之间的关系 箭头指向的用例为被扩展的用例，称为扩展用例；箭头出发的用例为基用例。扩展用例是可选的，如果缺少扩展用例，不会影响到基用例的完整性；扩展用例在一定条件下才会执行，并且其执行会改变基用例的行为。 扩展 《include》 箭头指向的用例为被包含的用例，称为包含用例；箭头出发的用例为基用例。包含用例是必选的，如果缺少包含用例，基用例就不完整；包含用例必须被执行，不需要满足某种条件；其执行并不会改变基用例的行为。 包含 用例之间的关系 表示参与者与用例之间的交互，通信途径。 (关联有时候也用带箭头的实线来表示，这样的表示能够显示地表明发起用例的是参与者。) 关联 参与者与用例之间的关系 图 解释 关系 《extend》 识别用例间的关系 包含（Include） 包含关系把几个用例的公共步骤分离成一个单独的被包含用例。 即在一个用例中重用另一个用例中的步骤。 下订单 检索客户信息 include 包含关系的误用！（步骤和系统行为都不能做用例） 扩展关系（extend） 扩展用例是在原用例的基础上增加新的步骤序列形成的。 原用例被称为基用例（base use case）。扩展只能发生在基用例的序列中的某个具体制定点上，这个点叫做扩展点（extension points）。 扩展关系 VS 包含关系 在扩展关系中，基用例不必知道扩展用例的任何细节，事实上基用例没有扩展也是完整的，只有特定的条件发生了，扩展用例的行为才被执行，而包含关系则不同。 泛化关系（generalization） 和类一样，泛化是指一个用例继承了另一个用例，在用例继承中，子用例可以从父用例继承行为和含义，还可以增加自己的行为。 子用例可以出现在父用例 出现的任何位置 参与者的泛化 参与者之间也可以象类一样存在泛化关系。 如系统中经理可以参加雇员的所有用例 UML用例图——绘图的建议 防止过度图形化 用例的重点在于书写文本，而不是图和用例关系，不要花很多小时甚至几天讨论用例图和用例关系 Example 1 航空售票的用例图： 参与者(actor)：clerk，监督员，信用卡服务商，信息亭 用例(use case)： Buy tickets， Buy Subscription， Make charges， Survey sales 参与者Clerk参与(或称发起)Buy tickets和Buy Subscription 两个用例(关联关系)。这两个用例的事件流都包含Make charges用例(包含关系)。 系统由：Buy tickets， Buy Subscription， Make charges， Survey sales组成。 该系统主要包含：Buy tickets， Buy Subscription， Make charges， Survey sales这几个功能。 该系统主要面向的用户(参与者)：clerk，监督员，信用卡服务商，信息亭。 Example 3 例：图书馆管理系统的用例： 借书（Borrow book） 还书（Return Book） 预定书刊（Reserve Title） 查询图书（Query Title） 取消预定（cancel Reservation） 维护借阅者信息（Maintain Borrower Info） 维护书目信息（Maintain Title Info） 维护物理书刊信息（Maintain Book Info） 登录（Log In） 图书馆管理系统用例图 用例阐述文档 场景（scenario）： 是参与者和被讨论系统之间的一系列特定活动和交互。每个用例是一组场景的集合，而每个场景又是一个步骤序列。 用例阐述文档针对每个用例，描述各个场景 “Borr