UML05用例图创新.ppt

用例图的组成 用例（ Use Case） 参与者（活动者、角色，Actor） 关系（Relationship） 5.1 用例 1. 用例的概念 用例是系统、子系统或类和外部参与者交互的动作序列的说明, 包括可选的动作序列和会出现异常的动作序列。 5.1 用例 2.用例的表示 用例用椭圆表示，名称写在下面。 3. 用例的特点 ① 用例用于描述系统的外在功能，即外部使用者看到的系统功能，它不反映功能的实现方式。 3. 用例的特点 ② 用例描述用户提出的一些可见需求，对应一个具体的用户目标。 3. 用例的特点 ③ 用例反映系统与用户的一次交互过程， 是一个动作序列的描述。 用例的特点 ① 用例用于描述系统的外在功能 ② 用例描述用户提出的一些可见需求 ③ 用例反映系统与用户的一次交互过程 ④ 用例是对系统功能的描述，属于需求建模。 描述用例时易出现的错误： 只描述系统的行为, 没有描述参与者的行为 只描述参与者的行为, 没有描述系统的行为 在用例描述中就设定了对用户界面的设计的要求 描述过于冗长、细化 ATM系统“取款”用例的两个错误描述： 主事件流： 储户插入ATM卡,并输入密码 储户按“取款”按钮,并输入取款数目 储户取走现金/ATM卡/收据 储户离开 5.2 参与者 1. 参与者的概念 参与者（Actor）是外部需要与系统交互的事物。也被称为活动者、角色。 2.参与者的三种类型 ①. 人：如客户、读者、管理员 ②. 设备：如计算机、读卡机、时间等 ③. 外部系统 3. 参与者的表示 参与者可以表示为下面三种形式。 4. 参与者之间的关系 参与者之间可以有泛化关系。 5.3 用例之间的关系 用例之间可以具有以下几种关系： ①. 关联关系 ②. 泛化关系 ③. 包含关系 ④. 扩展关系 1. 关联关系 参与者与用例之间是关联关系，表示参与者与用例之间具有使用、交互信息的关联。 2. 泛化关系 参与者与参与者之间、用例与用例之间存在一般与特殊的关系。 3. 包含关系 两个用例之间，一个用例(基本用例)的行为包含了另外一个用例(包含用例)的行为。 包含关系用依赖关系的include构造型来表示。 4. 扩展关系 扩展关系表示基本用例在扩展点要增加新的行为或功能，以扩展到新用例。 扩展关系用依赖关系的extend构造型来表示。 5.4 用例图 1. 用例图的作用 用例图用来描述软件需求模型中的系统功能，通过一组用例可以描述软件系统能够给用户提供的功能。 用例图可以作为整个系统开发过程中的开发依据，指导和驱动其他模型。 2. 用例图的形式 用例的粒度 选择谁？ 用例的粒度 怎样确定用例的粒度（用例的大小）？ 用例的粒度可大可小，一般一个系统宜控制在20个用例以内。 用例是系统级的、抽象的描述，不是细化的（是做什么，非怎样做）。 要点：用例的粒度(1) 用例要有路径，路径要有步骤；而这一切都是可观测的 最常犯错误：粒度过细，陷入功能分解 过细的粒度，一般都会导致技术语言的描述，而不再是业务语言 用例粒度(2) 把步骤当用例 把系统活动当用例 要点：用例的粒度(2) “四轮马车” C(Create)R(Read)U(Update)D(Delete) 所有业务最终对会成为CRUD？ CRUD能为Actor提供价值？ CRUD掩盖业务，锐变成关系数据库的建模： “系统就是数据的增删改查” 关心数据的存储和维护，反而忽略了用户的目的 要点：用例的粒度(3) 如果确实是CRUD？ 如果CRUD不涉及复杂的交互，一个用例“管理××”即可 不管是C、R、U、D，都是为了完成“管理”目标 甚至很多种的基本数据管理都可以用一个用例表示 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5 发现用例 发现用例的一般方法： 5.5.1 获取参与者 获取用例首先要找出系统的参与者。可以通过用户回答一些问题的答案来识别： ?