设计一个电子投票系统.pptVIP

* * * 设计一个电子投票系统，投票机由一名监督员启动。为了将电子信息装载到投票机上，监督员必须输入验证码。 电子信息以文件形式装载到投票机上，监督员审核这些信息，如果有误，监督员将终止该程序并重新装载数据，如果正确投票可以开始。 在电子投票结束时，监督员输入验证码，可以查看每个职位的投票结果。 分析： 参与者：监督员 用例：信息装载、输入验证码、审核信息、重新装载、查看结果。 用例建模2 * 电子投票系统用例图 用例建模2 用例图在软件生命周期中的运用 主要用来明确需求 用来辅助分析 用来辅助设计、特别是用户界面的设计 用来测试 * 用例分组 当许多用例具有同样的功能或者以同样的方式相互联系，就将它们归在一起。UML的包表示了用例的聚类。 分组的依据 同样的参与者 共同的实体 特定的工作流 * 审查 参与者 确定系统环境中的所有角色，并都归入了相应的参与者； 每个参与者都至少和一个用例关联； 若一个参与者是另一个参与者的一部分，把它们合并； 若两个参与者相对于系统而言，扮演了类似的角色，应该在它们之间使用泛化关系； 用例 每个用例都至少和一个参与者关联； 若两个用例有相同或相似的序列，可能需要合并它们，或抽取出一个新用例，在它们之间使用包含、扩展或泛化关系； 若用例过于复杂，为了易于理解，考虑进行分解；若一个用例中有完全不同的事件流，最好把它分解成不同的用例 * 例：ATM机 持卡用户在银行ATM机上进行查询\取款\转账等业务。若ATM发现用户连输三次密码不对，该卡已挂失或忘记取卡，则吞卡。检测到无效卡则退卡。每到午夜12点，统计该日的取款总额并发送至总部系统，机内无现金时及时通知总部系统。 * * * 课堂练习：用例建模 完成“旅店预定系统”的系统用例图，注意用例的命名和用例间的关系的使用。 选择一个体现系统核心业务功能的用例，完成用例规格说明。 * “旅店预定系统”初步用户需求 某公司要开发一个旅店预定系统，该旅店可对外开放豪华双人间、双人间、三人间和单人间，房间费用视情况按季节调整，但周一到周五半价（周末全价）折扣不变。对于外界请求，该系统应能根据请求入住时间预定指定档次的房间，记录旅客姓名、地址、联系电话、有效证件号、房间类型和预定天数，并计算出总费用。预定的同时旅客按规定须提交10%定金。六个小时之内旅店允许旅客取消预定，并退回所有定金，超过六个小时定金不退还。每周一系统自动打印一周预定情况清单。采用哪种费用支付方式和何种类型操作界面尚不确定。 * 问题用例图1 * 问题用例图2 * 问题用例图3 * 1. 不恰当的“时间”参与者 时间：参与者，一种习惯用法，用于激活那些系统定期的、自动执行的用例 “检查是否可以退定金”的时候，时间仅仅是一个系统内部的判断条件，而不是参与者 * 2. 无效的参与者泛化 参与者泛化：特殊参与者会继承泛化参与者所有的要素！ 参与者的重要性在一识别用例，如果泛化没有带来任何用例，则这样的泛化没有任何意义 在系统中如果两个参与者涉及相同的用例，则合并 * 3. 错误的用例关系 依赖关系：include, extend都是依赖关系(dependency)的构造型(stereotype)，带箭头的虚线表示 扩展关系：“extend”关系的方向，子用例对主用例的扩展 * 3. 错误的用例关系 用例的顺序在活动图中表现 * 3. 错误的用例关系 * 4. “其他”用例？ “其他”、“打印清单”用例和外围没有任何有意义交互，和其他用例也没有任何关系，这样的用例有意义吗？ “其他”用例又代表什么呢？想说明什么样的功能需求？ * 5.参与者和用例间的关系 “打印报表”和“酒店管理员”之间的关联是有意义的交互吗？ * 6. 用例粒度太小 * 用例规格描述常见错误 用例描述中只有参与者动作，没有系统动作。 用例描述中没有主参与者。 描述中过多的用户接口细节，如按钮等界面元素的具体实现。 描述过低的目标级别。 * 较为合理的用例图 * 较为合理的用例规格说明1 用例名称：预定房间 涉及的参与者：酒店前台 描述：酒店前台人员根据旅客的入住请求，预定某个时间指定档次的房间，预定的同时旅客按规定须提交10%定金。 前置条件：前台工作人员必须已经登录到这个系统 后置条件：预定信息正确的记录到系统中 正常事件流： 1) 前台人员向系统提供需要预定房间的类型、时间和预定天数。 2) 系统确认有相应档次的空闲房间，并计算出总费用和定金。 3) 前台人员向系统提供旅客信息（姓名、地址、联系电话、证件号等）。 4) 系统记录旅客信息。 5) 前台人员确认已经交纳定金。 6) 系统记录房间已经预定，工作完成。 备选事件流： 2a.没有指定类型的空闲房间,可以转到第一步或者取消预定，用例结束 5a.顾客没有交纳定金，前台