需求分析—UML用例图.ppt

本文观看结束！！！ * * web application product * 简单来说，系统的boundary就像一个加了标签的盒子，actor在盒子外，而Use Case在盒子内。 * 系统边界问题：业务建模 定义业务活动，识别相关的业务参与者 有意义的系统交互：图书馆、读者（感兴趣的，用户所关心的，要解决的）， 如系统的打印功能，与打印机的交互，这些交互已经被别人解决了，我们并不需要考虑细节 是责任边界，非物理边界 * 用例定义了一组用例实例，其中每个实例都是系统所执行的一系列操作，这些操作生成特定主角可以观测的值。 用例实例是系统执行的一系列动作，这些动作将生成特定主角可观测的结果值。 * 系统的存在是因为：参与者有一些需要使用它来满足的目标 * 用户可以看见的，是由系统生成的 * 用例是一个完整的交互，用例之间没有顺序的关系 * * 事件流：用例描述的核心内容是明确要完成业务目标必须完成的动作序列,称为事件流,以及相应的业务规则.一个用例包括多个事件流,其中一个是主事件流,其他事件流称为备选事件流 * 正常事件流： 备选事件流： * 活动图是状态图的一种特殊形式。其中所有或多数状态都是活动状态，而且所有或多数转移都在源状态中的活动完成时立即触发。 * 转移：转移表示各种活动状态的先后顺序。这种转移可称为完成转移。它不同于一般的转移，因为它不需要明显的触发器事件，而是通过完成活动（用活动状态表示）来触发。 决策：为其定义了一组警戒条件。这些警戒条件决定在活动完成后将执行一组备选转移中的哪一个转移。您也可以使用判定图标来表示线程重新合并的位置。决策和警戒条件使您能够显示业务用例的工作流程中的备选线程。 同步：示意条用于显示平行分支流。同步示意条使您能够显示业务用例的工作流程中的并行线程。 * * 扩展关系是从扩展用例到基本用例的关系，它说明为扩展用例定义的行为如何插入到为基本用例定义的行为中。它是以隐含形式插入的，也就是说，扩展用例并不在基本用例中显示。 基础用例(Base)中定义有一至多个已命名的扩展点，扩展关系是指将扩展用例(Extension)的事件流在一定的条件下按照相应的扩展点插入到基础用例(Base)中。对于包含关系而言，子用例中的事件流是一定插入到基础用例中去的，并且插入点只有一个。而扩展关系可以根据一定的条件来决定是否将扩展用例的事件流插入基础用例事件流，并且插入点可以有多个。  * 1. 基本用例通过包含关系连接到包含用例。包含用例总是抽象的。它描述在执行基本用例的用例实例中插入的行为段。基本用例可控制与包含用例的关系，并可依赖于执行包含用例所得的结果，但基本用例和包含用例都不能访问对方的属性。从这种意义上讲，包含用例是被封装的，它代表可在各种不同基本用例中复用的行为。 2. 包含关系是通过在关联关系上应用include构造型来表示的，如下图所示。它所表示的语义是指基础用例(Base)会用到被包含用例(Inclusion)，具体地讲，就是将被包含用例的事件流插入到基础用例的事件流中。 * 泛化关系是指一种从子用例到父用例的关系，它指定了子用例如何特化父用例的所有行为和特征。 * ?三种关系： ???????? 泛化? 参与者与用例 用例之间?? 订货 电话订货 网上订货? ???????? 扩展? 用例之间? 维护－增加条目?? ?????????包含? 用例之间?? 喝饮料－打开瓶盖 进一步，用例的存在是为Actor提供服务，但用例提供服务的方式可分为间接和直接两种，依据于此，泛化中的子用例提供的是直接服务，而包含中的被包含用例提供的是间接服务。同样，扩展用例提供的也是直接服务，但扩展用例的发生是有条件的。 * 是include还是extend -*- 用例规约：记录时间(续) 正常事件流（Basic Flow）： 雇员查看当前时间之前输入的数据； 雇员从已有的支付号码中选择一个，这些收费代码是按客户和项目组织的； 雇员从当前的时间段选择一个日期； 雇员输入以正整数表示的工时； 系统在视图中显示这个数据，并在以后的视图中看到这个数据。 备选事件流（Alternative Flow）1：雇员更改他的时间 雇员查看当前时间之前输入的数据； 雇员选择一个已有的条目； 雇员改变工时； 在视图中更新这个信息，并在以后的视图中都可以看到。 -*- 用例规约：记录时间(续) 非功能需求：无 设计约束：无 部署约束：用户可以从客户端或雇员的家中访问到“Record Time”用例，如果是从客户端访问，则要考虑到客户端的防火墙 未解决的问题 雇员是否可以在以前的考勤卡上输入和更改时间 雇员是否可以在以后的考勤卡上输入和更改时间，例如，在休假之前？ -*- 活动图-简述用例流程 -*-