第05讲_用例分析与用例图.pptVIP

业务用例模型2 借书的业务流程 系统用例图 识别参与者思路 谁使用系统的主要功能 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责日常维护、管理并保证系统正常运行 谁使用或删除系统中的信息 谁（或什么）对系统运行产生的结果（值）感兴趣 系统需要应付（处理）那些硬设备 系统需要和那些外部系统交互 在预定时间，是否有事件自动发生 时间、气温等内部外部条件 …… 某汽车制造厂需要一套库存管理系统，该系统实现的业务：生产工人根据生产计划领取物料，库存操作员根据生产系统的派单准备，交付给领料工人，余料即时归还库房。库房管理人员定期盘点库存，通知供应商供货，对长期积存的货物，申请退货。 谁使用该系统 谁改变系统的数据 谁从系统获取信息 谁需要系统的支持以完成日常工作任务 谁负责维护、管理并保持系统正常运行 系统需要应付那些硬件设备 系统需要和那些外部系统交互 谁对系统运行产生的结果感兴趣 操作员，管理员 操作员，管理员 操作员，管理员 领料员,退料员,操作员,管理员,供应商 管理员 生产系统, 供应商系统 操作员,管理员,领料员,退料员 ? 参与者的类型和职责 主要参与者 直接与系统交互的人，或执行系统主要功能的执行者 次要参与者 使用系统次要功能的执行者，或维护系统一般功能的执行者 外部硬件 作为系统一部分的、运行应用的非计算机的硬件 其他系统 为其工作需要与系统交互的外部系统 参与者之间的关系 独立关系 泛化关系 一个参与者的抽象描述可以被一个或多个具体的参与者所共享 客户 个体客户 商业客户 用例 定义：Use Case 用例表示系统的一项外部功能，它从用户的角度分析所得的需求。为完成一个相对完整的一种功能，系统执行的一系列动作的集合 是外部可见的一种系统功能 代表的是一个完整的功能 有一系列动作 用例 用例1 用例捕获某些角色可见的需求，实现一个具体的角色需求 用例由其用户角色使用，并提供确切的输出给角色 用例可大可小，但它必须是对一个具体的角色目标实现的完整描述 用例的动态执行过程可以用U M L的交互作用来说明，可以用状态图、顺序图、协作图、活动图或非正式的文字描述来表示 用例的命名 执行者视角： （状语）动词+（定语+ ）宾语 识别用例 识别用例 关键词：价值 定义 用例实例是系统执行的一系列动作，这些动作将生成特定参与者可观测的结果值 一个用例定义一组用例实例（场景） 场景-----用例的实例 简洁：参与者使用系统达到目标 识别用例要点 可观测→用例止于系统边界 结果值→用例是有意义的目标 系统执行→结果值由系统生成 由参与者观测→业务语言、用户观点 一组用例实例→用例的粒度 可观测：用例止于系统边界 系统 描述交互，而不是内在的系统活动 结果值：有意义的目标 √ 业务功能，而非系统处理 系统执行：结果值由系统生成 系统需要处理的，由系统生成 参与者观测：用户观点而非系统观点 用户观点 系统观点 用例粒度 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度-1 把步骤当用例 把系统活动当用例 × √ × 用例粒度-2 × “四轮马车” C(Create) R(Read) U(Update) D(Delete) 所有业务最终会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 用例粒度-3 用例粒度-4 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 用例粒度-5 灵活处理CRUD 可以把包含复杂交互的路径独立出去形成用例 用例关系 Include 提取公共步骤，便于复用 Extend 分离扩展路径 Generalization 同一业务目的的不同技术实现 包含关系 包含关系1 软 件 工 程 软 件 工 程 软 件 工 程 软 件 工 程 软 件 工 程 软 件 工 程 业务过程是描述这个业务的具体工作流的 一次涉众与实现业务目标的业务之间的交互 它可能包含手工和自动化的过程 也可能发生在一个长期的时间段中 涉及范围是这个计算机系统涉及的范围 是一个系统参与者与计算机系统一起实现一个目标 是参与者如何与计算机技术相联系，而不是业务过程。 * 参与者：系统的使用者 用例：代表系统向使用者提供的服务 * 系统的存在