《面向对象的系统分析与设计》3章-用例和用例图.pptVIP

在实际工作中，建模者常常会面临一个问题，“谁是参与者？” 场景：小王到银行去开户，向大堂经理询问了办理手续，填写了表单，交给柜台职员，拿到了银行存折，在这个场景中，有好几个人参与了这个业务，但谁是参与者？ 在庐山之中时不能看清楚它的真面目，只有在外面才能看清楚。 按照以上两个问题寻找答案，第一个问题的答案是小王有着明确的目标：开户，并且主动发出开户的请求；第二个问题的答案是系统运作的结果是给小王提供了开户的服务。由此确定小王是参与者，大堂经理和柜台职员在系统边界之内。 在实际项目中，有些需求没有人参与，参与者如何确定？ 场景：每天自动统计网页访问量，生成统计报表，并发送至管理员信箱。这里谁是参与者？ 后面有一个概念：用例。用例的一个特征就是不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。这说明：没有人参与的需求一定有别的事物在发出启动的动作，应当找到这个事物，这个事物就是一个参与者。 任何需求必须至少有一个启动者，如果没有人参与，必定有一个事务参与。这个事务可能是一个计算机系统、一个计时器、一个传感器或一个JMS消息。所以按照这个来说，上述场景中，参与者是计时器。 这是一个参与者非人的例子 机票购买者是参与者，人工坐席变成业务工人。 不需要与其他用例交互而独自完成参与者的目的，也就是说用例从功能上说是完备的。 1.取钱是一个有效的用例，填写取款单确不是，因为完整的目的是取到钱，没人会为了填写取款单而专门跑一趟银行。 2.后台监控进程参与系统的操作，在参与者删除数据之前执行备份操作。虽然它是系统的一个必需组成部分，但在需求阶段却不应该作为用例出现。因为这个后台进程，对参与者来说是不可观测的，它应该作为系统的需求而不是用户需求。 登录系统对参与者有意义，可以获得身份认证和授权，但单纯地输入密码确实没有意义的。 3.不存在没有参与者的用例，用例不应该自动启动，也不应该主动启动另一个用例。 从ATM取钱是一个有效的用例，ATM自动吐钞就不是了。 4.喝水是一个有效的用例，但“喝”和“水”不是。生活常识告诉我们，在没有水的情况下人不会做出喝这个动作，水必然是喝进去的，不是滑进去的。但实际中有些用例的命名很不规范，如：计算、统计、录入等。 一旦决定了用例，软件开发工作的其他活动都以这个用例为基础，围绕它进行。 * 2 识别用例 某公司要开发一个旅店管理系统，该旅店可对外开放10个双人间和10个单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。 * 用例干什么？ “其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？ “其他”用例又代表什么呢？想说明什么样的功能需求？ * 用例粒度 注意“管理用例”的使用！ * 用例关系 include extend Extend Include Generalization * 4. 用例关系-1：明显的错误 依赖关系：include, extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示 “extend”关系的方向，子用例对主用例的扩展 * 4. 用例关系-2：什么关系？ 用例是一个完整的交互，用例之间没有顺序的关系 作业 现有一个产品销售系统，其总体需求如下： （1）系统允许管理员生成存货清单报告； （2）管理员可以更新存货清单； （3）销售员记录正常的销售情况； （4）交易可以使用信用卡或支票，系统需要对其进行验证； （5）每次交易都需要更新存货清单。 * （1）系统允许管理员生成存货清单报告； （2）管理员可以更新存货清单； （3）销售员记录正常的销售情况； （4）交易可以使用信用卡或支票，系统需要对其进行验证； （5）每次交易都需要更新存货清单。 * （1）系统允许管理员生成存货清单报告； （2）管理员可以更新存货清单； （3）销售员记录正常的销售情况； （4）交易可以使用信用卡或支票，系统需要对其进行验证； （5）每次交易都需要更新存货清单。 * * 小练习—软件设计师09年试题 某银行计划开发一个自动存提款机模拟系统(ATM System)。系统通过读卡器CardReader)读取ATM卡; 系 统与客户(Customer )的交互由客户控制台(Customer Console)实现;银行操作员(Operat