5用例建模.ppt

面向对象分析与设计 用例建模 项目分析过程 什么是用例建模 什么是用例建模? 一种描述功能性需求的方法 清晰地定义系统的边界 详细描述系统和外部环境的交互 用例模型不仅仅是图形 用例是文本形式的情节描述 重要的用例文本，次要的用例图 使用用例的好处 用例是对用户需求（主要是功能需求）的规范化的描述 为需求提供了应用环境 把系统系统定义在一个使用环境中 帮助解释为什么需要该系统 有助于保证没有需求的遗漏 易于理解 站在系统使用者的立场上来定义需求 使用客户和用户都能理解的术语和表述 易于客户对于需求的审核 为领域专家、最终用户和开发者提供一种相互交流的手段。 可以为其他开发环节所重用 项目计划、设计、测试、用户手册 定义：参与者、场景和用例 参与者（actor） 是某些具有行为的事物，可以是人、系统或组织 场景（Scenario） 参与者与系统之间的一系列特定的活动和交互 特定的情节或用例的一条执行路径 用例（use case ） 一组相关的成功和失败场景集合，用来描述参与者如何使用系统实现其目标 场景是用例的一个实例 什么是场景? 事件流：完成事件的一系列步骤 用例：描述所有的流 场景：用例的某一个实例，从用例开始直到它的某一个结束点 用场景检验用例的事件流是否描述完整 场景是用例的一个实例 P47 用例建模中的主要模型元素 用例描述了系统需求 每一个用例 表述了系统向参与者所提供的某种服务 也表述了参与者是如何使用系统的 描述了系统和参与者之间的一段对话 参与者与用例间的通讯关联 参与者和用例之间进行对话的一个渠道 用一条带或不带箭头的线来表示 箭头表示是谁发起了这次对话 没有箭头表示任何一方都可以发起对话 箭头并不表示数据的流向，数据流向总是双向的 用例建模的步骤 界定系统边界 寻找主要参与者 寻找用例（参与者达到的目标） 描述用例框架 细化用例描述 系统边界 系统成分和系统以外事物的分界线 一个系统所包含的所有系统成分与系统以外各种事物的分界线。 确定研究对象。 示例 POS系统 收银员 支付授权服务 支付授权服务在边界内还是边界外？ 界面对象在边界内与边界外对构造系统有何影响？ 参与者 在系统边界以外，与系统进行交互的事物。——人员、设备、外系统。 找出参与者 为何从参与者入手? 谁来使用系统，他们的目标是什么？ 考虑如下问题： 系统有哪些用户? 有谁想从系统中获取信息? 谁负责向系统提供信息? 系统将会在哪些部门使用? 是谁负责管理理和维护系统? 时间是参与者吗？系统要响应时间事件吗？ 有没有其他的系统会和该系统发生交互? 识别参与者（1） 用户 从直接使用系统的人员中发现参与者。 这里强调的是直接使用，而不是间接的。 特定的人，在系统中可扮演不同的角色。 例如，添加数据、使用数据及产生报告的那个人就扮演了三种不同的角色，反映为三种不同的参与者。 识别参与者（2） 外部系统 所有与系统交互的外部应用系统都是参与者。 从系统边界的角度，应该把与软件系统运行在同一平台上的应用系统看作是外部的应用。相对于当前在正在开发的系统而言，外部应用系统可以是其他子系统、上级系统或任何与它进行协作的系统，但对它的开发并不是当前系统的开发小组的责任。 识别参与者（3） 设备 识别所有与系统交互的设备。 这样的设备与系统相连，向系统提供外界信息，或在系统的控制下运行。通常，不包括监视器、键盘、鼠标和其它的标准的用户接口类型设备，但考虑外部传感器（输入信息）和受控马达（输出信息）。 外部事件 当构造实时和异步交互的系统时，将外部事件识别为潜在的参与者就变得更加重要了。 例如，由时间的流逝而激发系统的活动是常见的情况。可以把时间事件作为一个参与者，也可以把时间事件作为系统的一部分，还可以把二者结合起来使用。 对于参与者的描述 例：设计ATM机器 判断下列那些是ATM系统的参与者： 客户 银行卡 ATM机器面板 收据打印机 银行的主系统 账户信息数据库 Pos系统的处理销售用例 根据边界识别参与者 寻找用例 考虑 每一个参与者想达到的目标是什么? 为什么该参与者需要使用该系统? 该参与者会在系统中创建、修改、删除或访问任何数据吗? 当外部有事件发生的时候，该参与者需要通知系统吗? 当系统内部有某些事件发生时，需要通知该参与者吗? 已定义的系统功能是否足以满足所有的业务需求? 利用参与者捕获用例 对所有的参与者（把自己作为参与者），提问下列问题： 每个参与者的主要任务是什么？ 为了达到某种目的，它们参加什么活动？该参与者是否将读、写或修改系统的任何信息？参与者是否该把系统外部的变化通知系统？参与者是否希望系统把预料之外的变化通知自己？ 在交互过程中，它们是怎样使用系统的服务来完成它们的任务以达到