第7章-用例建模.ppt

第七章 用例建模 使用“用例”来表达系统的功能 7.1 基于用例的需求分析 分辨信息系统的边界 什么是用例 用例的概念、目的 识别参与者 识别用例 绘制用例图 如何描述用例 用例分解，确定用例关系 7.4.1 用例的概念 用例创始人雅各布森Ivar Jacobson认为： 用例（use case）是对于一组动作序列的描述，系统执行这些动作会对特定的参与者（actor）产生可观测的、有价值的结果。 阿里斯代尔·科克伯恩Alistair Cockburn： 强调用例是各种系统受益人（stakeholder）之间的一种行为契约（contract）。行为包括对象的活动、动作和对象之间的交互等。建立契约的目的是为了达成某种目标，因此每一个用例实际上都应代表一个用户目标，根据三个目标层次（概要层、用户目标层、子功能层）将用例进行分层，从而有效把握用例的粒度。 用例的意义 用例是对系统需求（主要是功能需求）的规范化的描述。 用例图及用例的事件流描述集中体现了系统责任。 通过用例建立交互图。交互图就是用例的具体实现，即系统中的对象以及对象间协作是如何完成一个用例的全部过程。 用例驱动的开发过程，从用例模型到分析模型和设计模型之间有一致性和可追踪性。 用例建模的内容 基于用例的需求获取过程： 1. 获取原始需求 2. 开发一个可以理解的需求 识别参与者 识别用例 构建用例图 3 详细、完整地描述需求 书写用例规格说明 4 重构用例模型 识别用例间的关系 对用例进行组织和分包 概述 1. 用例图的概念 用例图: UML用来描述软件功能的一种图形，包括用例，参与者，及其关系，也可以包括注释和约束。 概述 2. 用例图的作用 用例图用来展现软件的功能，作用是： ● 展现软件功能； ● 展现软件使用者和软件之间的关系； ● 展现软件功能相互之间的关系。 概述 3. 用例图的要素 用例图的要素主要有： ● 参与者：与用例存在交互关系的系统外部实体 ； ● 用例：描述一个相对独立的软件功能； ● 关系：参与者与用例的关系，参与者相互之间的关系，以及用例相互之间的关系。 1、识别参与者 参与者的概念 参与者（actor）是系统之外与系统进行交互的任何事物。 也被称为活动者。 参与者的类型 ①. 人： 客户，读者，库管员 ②. 设备： 计算机，磁盘，读卡机等 ③. 外部系统： 上层系统,同级系统等 ④. 时间： 由时间激发或启动用例 参与者的表示 在UML中，参与者使用小人符号： 参与者可以表示为下面三种形式。 参与者的泛化 在某些情况下，参与者的角色可以有共性，或者说一般性，一种角色可以拥有另一种角色的全部行为。 比如在超市系统中，值班经理完全可以充当收银员这一角色，此外，值班经理还可以有退货、更改事务等权利。 参与者的特性： ①.参与者位于系统外部； ②.参与者与系统发生交互关系； ③.参与者与系统之间存在交互接口。 区分参与者和外部实体 只有在执行系统功能时与信息系统进行实时交互的人员才能被当作参与者。 外部实体是指数据的来源和去向，提供数据的人员不一定会执行系统功能 新生入学手工填写个人信息，然后由教务人员统一将数据登记到学籍系统中，教务人员是参与者。 如果学生直接通过Web方式提交个人信息，则认为学生是参与者。 区分主要参与者和次要参与者 主要参与者（primary actor）是从系统中直接获得可度量价值的用户。 次要参与者（secondary actor）的需求驱动了用例所表示的行为或功能，在用例中起辅助支持作用 用例分析的重点是要找到主要参与者。 比如，在图书馆的借/还书用例中，首先要考虑谁直接使用这一功能，谁频繁地和系统进行交互？图书管理人员是直接操作者，他们的需求和变化对于用例的影响最大。因此，图书管理员是主要参与者。 参与者举例 2、识别用例 用例就是功能性需求。 每个用例至少和一个参与者相关，用例名称要体现参与者希望系统提供的功能。 用例 1. 用例的概念 用例(use case): 表示系统执行的一组动作，它会给系统或者参与者产生一组可观察的结果，用例用来描述系统的一个功能 。 2.用例的表示 用椭圆表示用例 3. 用例的特点 ① 用例用于描述系统的功能，这个功能是外部使用者看到的系统功能