2012-2013 第二学期 11本 UML 第三章 用例和用例图.pptVIP

UML 面向对象技术教程 本章中所涉及的内容 用例 参与者 脚本 用例间关系（泛化、包含、扩展、三种关系的比较） 用例图 用例的描述 寻找用例的方法 常见问题的分析 小结 §3.1 用例 用例（use case） 用例就是对包含变量在内的一组活动序列的描述，系统执 行这些活动，并产生传递特定参与者的价值的可观察结果。 定义一：用例是对一个活动者(actor)使用系统的一项功 能时所进行的交互过程的一个文字描述。 定义二：用例是系统、子系统或类和外部的参与者(actor) 交互动作序列的说明，包括可选的动作序列和会 出现异常的动作序列。 如何在UML中表示用例： 用例用一个椭圆来表示，用例名下在下面，其用例名往往是一个动宾结构。如“取钱”是一个用例,它的表示如下： §3.1 用例（续） 用例的特点： 1、从系统外看系统功能。 2、描述一个系统可见需求，对应于一个具体的用户目标。 3、是系统行为的动态描述，属于动态建模范畴。 软件开发过程是由用例驱动的。 用例将软件开发过程中各个阶段捆绑在一起，以实现功能的系统行为作为所达成的契约。 例如：来看银行对外业务系统的简单描述： 查询账户余额 列出业务菜单项 转账 存款与支付 登录与退出系统 §3.1 用例（续二） 用例是UML建模过程中一个非常重要概念，它处于核心位置。 不能指望在一个系统分析中列出全部的用例。 用例是外部可见的一个系统功能单元。用途在于不揭示系统内部构造的情况下定义一组连贯的行为。 用例可大可小，但它必须是对一个具体的用户实现目标的完整描述。 用例的动态执行过程 在UML中可以交互表现在‘用例图’、‘顺序图’、‘协作图’ 或文字描述来表示。功能的执行过程用“类”之间的协作来实现。 §3.1 用例（续三） 寻找用例及识别用例的方法 参与者希望系统提供什么功能？ 参与者是否会读取、创建、修改、删除、存储系统的某种信息？若是又是如何完成这些操作？ 参与者是否会将外部的某些事件通知系统的？ 系统中发生的事件是否会通知参与者？ 是否存在影响系统的外部事件？ §3.2 参与者（actor） 参与者是系统外部的一个实体（人和事物） 参与者的种类：系统用户、系统管理员、与所建造的系统相关的其他系统和一些可以运行的进程。 在UML中的有三种表现形式： 1、图标形式 ： 2、符号形式： (Icon) （Label） 3、修饰形式：为二者的合成 (Decoration) §3.2 参与者（actor）续 参与者事实上就是一个类。 继承关系? 泛化关系（在系统分析阶段是相等的） 参与者可以被一组定义它状态的属性加以描述，代表一个角色。 参与者的重要性有分级：主要角色、次要角色 参与者的性质有主动参与（执行主要功能）、 被动参与（执行次要功能）。 参与者之间的关系 参与者也是类，因此它拥有与类相同的关系 主要是继承（泛化）关系。 参与者之间大量地反映出的“权限”关系。 公司管理系统 参与者之间的关系的泛化 寻找参与者的参考方法 系统开发出来后，是谁使用系统的主要功能。 谁需要借助系统来完成日常工作。 系统需要从哪些人或其他系统中获取数据。 系统会为哪些人或其他系统提供数据。 系统会与哪些系统交互？这些系统分为两类，一是该系统要使用的系统，二是启动该系统的系统，包括其他软件。 系统由谁来维护和管理的，以保证系统处于工作状态？ 系统控制的硬件设备有哪些？ 谁对系统产生的结果感兴趣？ §3.3 脚本（scenario） 脚本又称为情景、场景、情节、剧本等 在UML中，脚本贯穿用例的一条单一路径。 脚本的定义：脚本是用例的实例(instance)。 脚本与用例之间是对象与类的关系。 例如：针对‘取钱’的用例，脚本就会有 1、正常完成取钱的脚本。 2、账户拒绝、取不出钱的处理脚本。 3、取出钱不对后的处理脚本。 但是有1、2、3、…构成了一个用例。 脚本的描述：一个脚本是用具体的文字加以描述的。 §3.4 用例间关系 针对用例的描述要遵循的几个要点： 清楚地确定系统的边界。 用标准模板书写用例说明。 关注用例的真正目的。 不能将用例说明与用户接口设计相混淆。 实现使用例交互与用户接口之间的松散耦合。 不要在用例与用户接口之间建立通信。 §3.4 用例间关系（续） 用例之间关系有以下几种：