UML第4章 用例视图.ppt

“供应商提供所需的货品”中是否存在系统的用例，待进一步确认。 注意： 1）依据文字描述的内容，不要无中生有：签收，付款，收款…… 2）用例与参与者之间的关系上不需标注数据流的名称 3）用例之间的连接，表示用例之间的关系，还没介绍 4）寻找合适的供应商，目前不需做为一个用例单独列出 5）参与者的名称是名词、用例的名称是动名词 * P62，父用例表示通用的行为序列，通过插入额外的步骤或细化步骤，子用例实例化父用例。 UML表示 与类的泛化一样 泛化 * 支付货款 * 泛化与扩展 扩展事件流是临时附加到基用例事件流的某个位置上，是属于同一层的 泛化与包含 泛化和包含都是用于抽取用例的公共行为，但泛化关系要求父用例和子用例之间拥有“is-a -kind-of”关系，这样继承才有意义。 * 在线股票经纪人系统中有三种交易：交易债券、交易股票和交易期权，它们都有一些共同的执行步骤，如验证密码，但又有各自额外的步骤。 例 * 生成订单 检查顾客身份 发货 付帐 include include include 跟踪订单 顾客 急件 extend 加急订单 extend 发货员 include 用例关系的作用 它只是组织和管理用例的一种方法 不影响需求，需求是通过编写用例描述来完成的，一定要分清重点 UseCase模型不是需求分析的全部 强调 * 用例捕获需求的优势 强调了用户的目标和观点 简单通俗，便于用户参与 用例驱动的软件开发 用例的迭代 初始、细化、构造 从定义出发建模的步骤 从业务流程中识别系统用例 4.5 用例视图建模技术 * 1.确定系统的边界和范围，找出系统外部的参与者和外部系统 2.确定每一个参与者所希望的系统行为 3.把这些系统行为命名为用例 4.绘制用例图 5.为每一个用例编写用例说明 6.区分主事件流、替代流和例外流 7.把一些公共的行为分解为一批新的用例供其他用例引用 8.把一些变更的行为分解为扩展用例 9.精化用例图 从定义出发建模的步骤：P68 * 重要 用例的细化程度 围绕参与者的目标，以参与者要完成的任务为依据来划分或分解用例 系统执行用例将为参与者产生一个可观测的结果值 避免将用例的执行步骤识别为用例 图4-20、图4-21 用例的粒度 P67 * P68 用例图中的名称与确定系统用例时的名称 用例描述 用例之间的关系 4.6 实例 * 按下列步骤重建图书馆管理系统的用例视图 * 给参与者一个名字和简短的描述 给用例一个名字和简短的描述 * 请为图书馆工作人员的用例编写用例说明 借书处理、还书处理 编写用例说明 * 可以参照 P69：确定系统用例 P72 ：图4-25 实验2 根据用例说明，定义子用例，重新绘制用例图 精化用例图 * 某饭店采购部准备实现计算机管理，采购部的具体工作如下： 每当库存量不足时，仓库保管员把所需采购的货品清单发送给采购部，采购部寻找合适的供应商并发采购订单给他们。供应商提供所需的货品。当货品到达时，采购部把它们递交给仓库保管员。 识别参与者与用例，并画出用例图 * 每当库存量不足时，仓库保管员把所需采购的货品清单 给采购部 采购部 合适的供应商并 采购订单给他们。 供应商 所需的货品。 当货品到达时，采购部把它们 给仓库保管员 * 发送 寻找 发 提供 递交 你正在分析“在线旅行社系统”，遇到下面这些用例，使用泛化和包含关系绘制一张用例图。 * 用例 用例简述 购买航班机票 预订航班机票，并提供付款和地址信息 提供付款信息 用信用卡来支付费用 提供地址 提供邮件地址和住址 租凭汽车 预订出租汽车，提供付款和地址信息 支付酒店住宿 预订酒店讯问，提供付款和地址信息 支付 支付旅游费用，提供付款和地址信息 * 用例视图中包含4个用例图 * 难点和重点是：用例、关系 系统边界：顶层DFD也是明确系统内部和外部之间的数据流向 * 参与者的确认： 1）外部 2）直接参与：如借书用例的参与者不是读者，而是图书馆工作人员 3）角色 * * * 用例执行过程的多样性，如何进行描述 主事件流：这是用例描述最核心的部分，记载了整个用例正常的执行过程。 替代流：如果期间有一些其他情况发生（小插曲），但仍不至于影响用例的成功执行，这就是替代流程，较为少见的情况（特殊情况） 例外流：用例执行失败的情况 * 特殊需求一般用于记录一些规则或非功能性的需求 * 两种编号方法 * * 【复习软件工程】 单块软件：由一个单独模块构成的大程序 模块化的指导思想的两个依据 解决困难问题需要花费更多的时间 两个问题结合时的理解复杂度通常要大于每个问题各自的理解复杂度之和。 所以，如果我们将大问题分解成小问题，那么开发它所需