UML用例设计

一. 用例图目的
1) 界定系统范围。
2) 描述参与者实现的目标和希望系统执行的一定功能。
3) 描述系统功能与外部系统,人,组织交互的关系。

二. 用例分解的规则
1) 用大型用例描述参与者实现的主要目标。
2) 用尽量少的主要用例描述系统的行为。
3) 避免将用例分解过细,用例应基于用户对系统的体验,而不是系统内部的处理。用例图无需表现功能实现步骤,具体步骤可以在文档中描述。

三. 用例图关系
1) 用包括(include)显示用例的细节。
a) 包含(include)用例来封装一组跨越多个用例的相似动作(行为片断),以便多个基用例复用。
b) 当某用例的事件流过于复杂时,为了简化用例的描述,我们也可以把某一段事件流抽象成为一个被包含的用例。
c) 当用例划分太细时,也可以抽象出一个基用例,来包含这些细颗粒的用例。

2) 用泛化(generalization)显示共享目标。
子用例和父用例相似,但表现出更特别的行为。子用例将继承父用例的所有结构、行为和关系。子用例可以使用父用例的一段行为,也可以重载它。在实际应用中很少使用泛化关系,子用例中的特殊行为都可以作为父用例中的备选流存在。

3) 用扩展(extend)分离特定条件下的用例。
将基用例中一段相对独立并且可选的动作,用扩展(Extend)用例加以封装,再让它从基用例中声明的扩展点上进行扩展,从而使基用例行为更简练和目标更集中。

时间: 2024-10-20 14:38:05

UML用例设计的相关文章

uml与数据库设计

一.类之间的关系如下图所示: 二.UML与数据库设计主要讨论的内容: 三.依赖关系强调的是类操作间的使用关系,类图到表结构的映射中并不涉及这种关系,所以只需讨论泛化关系.关联关系到表的映身规范. 1.泛化关系的映射 (1).将父类和子类均映射为表 优点:表结构的更改非常方便 缺点:表的数量较多,相关的数据分散在不同的表中,数据读写时间较长,报表的生成较为困难. (2).只将子表映射为表 优点:表的数量较少,相关的数据集中在一个表中,数据的读写较为方便. 缺点:表结构的修改较为困难,因为修改父类后

Java设计模式中的单例设计

/** * 单例设计模式 * 应用场合:只需要一个对象的 * 作用:保证整个应用程序中某个实例有且只有一个 * 类型有:饿汉模式.懒汉模式 * 下面的例子是一个饿汉模式的例子 */ class SingleDemo { // 1.将构造方法私有化,不允许外部直接创建使用 private SingleDemo() {} // 2.创建类的唯一实例,使用private static修饰 private static SingleDemo instance = new SingleDemo(); //

不得不说--自动化测试元素定位与用例设计

关于自动化测试,经常被问到元素的定位 与 如何设计用例. 很多时间我也帮不了你解决实际的问题,只能从个人脚本谈谈如何看待这些问题. 不得不说之元素定位 虽然,本章写了十几篇文章来讲元素的定位与操作,对于碰到的一些常见功能,如何通过技巧来定位它们,但是在实际的自动化脚本开发中,不管是新手还是具有一定经验的老手,我们面临最多的问题仍然是元素的定位问题. 有时间元素定位非常简单,例如,我们只要知道这个元素有的id和name 就可以轻松的来定位到它:有时间元素的定位却非常的令人非常头疼,尽管我们用尽了所

Spring容器-ApplicationContext的单例设计

Spring容器-ApplicationContext的单例设计 每次通过new创建一个ApplicationContext容器,都会执行refresh方法,看源代码了解到这个refresh方法会重新加载配置文件,并且这个创建的容器对象持有一个所有singleton类型bean的map集合,从而实现单例,而且这个map对象的生命周期和容器对象的生命周期是一样的 如果我们每次都通过new一个容器对象,那么每次都要重新加载配置文件,都要重新生成这个singleton bean的集合,这样所谓的单例就

接口测试原理、流程及用例设计

接口测试的原理是模拟客户端向服务器发送报文请求,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的一个过程. 接口测试流程: 模拟客户端连接服务器(服务器提供的端口是否可访问) ↓ 客户端发送报文请求 ↓ 服务器端接收请求并做处理 ↓ 检查返回的预期结果并与实际结果对比 ↓ 结束 接口测试用例设计: 接口测试的主要测试对象是接口,但随着系统复杂度越来越高,接口越来越多,完全覆盖所有接口是很难的一件事情,且实际过程中任意内部接口的变动都可能导致我们测试用例的不可用. 所以通

基于技术方案的用例设计

上一篇介绍了基于需求文档的用例设计,主要是运用了黑盒测试的用例设计方法.之前提到用例在整个项目过程中是动态更新,逐步完善的,经过了需求评审的用例编写后,项目会进行技术方案评审,评审结束后,需要基于技术方案对用例进行一次补充完善. 我仍然以登录为例,由于每个开发设计的方案不同,在此列一个大致的通用方案,基于该方案做用例设计,精髓会了,其他的融会贯通. 登录成功的时序图如下: 登录失败的时序图如下: 分析时序图,步骤比较清晰,客户端的主要工作分为几部分: 1.绘制登录界面(UILabel.UIBut

软件测试 —— 用例设计3(其他)

错误推测方法: 一.    方法简介 1.         定义:基于经验和直觉推测程序中所有可能存在的各种错误, 从而有针对性的设计测试用例的方法. 2.         错误推测方法的基本思想: 列举出程序中所有可能有的错误和容易发生错误的特殊情况,根据他们选择测试用例. 1)        例如, 输入数据和输出数据为0的情况:输入表格为空格或输入表格只有一行. 这些都是容易发生错误的情况.可选择这些情况下的例子作为测试用例. 2)        例如,前面例子中成绩报告的程序,采用错误推

【小白的java成长系列】——构造方法私有化(单例设计)

有了解过spring框架的童鞋们就知道,spring的bean默认是什么形式呀?---单例形式的. 问:那什么叫做单例?单例其实就是Singleton,顾名思义就是只有单个的实例对象操作. 那为什么要使用单例呢? 至于这个问题,后面再做解释,我们先看代码: package me.javen.oop; public class SingletonDemo { public static void main(String[] args) { Singleton singleton1 = Single

基于需求文档(PRD)的功能用例设计

上一篇我讲了在项目运行过程中,用例是需要动态更新的.接下来我将结合实例(移动app)讲解在不同的阶段如何设计用例. 需求文档(PRD)主要讲述app的某个模块有什么功能,每一项功能的页面展示.页面操作有哪些,不同操作之间的关系是什么.基于PRD的用例设计是使用黑盒测试方法,而我平时主要使用了等价类划分.边界值分析法.状态转换测试.场景测试,操作实践时偏好于将模块分成页面展现.页面操作.接口.异常流,在每一个子项里运用黑盒测试方法进行设计. 以移动app的登录为例,大致需求如下图: 一.验证登录弹