2003 年,我曾经在网上看到一篇技术文章《 没头没尾—项目开发笔记:如何编写最外层用例 ?! 》,这篇文章写得很好,真实记述、反映了用例写作中的一些常见现象和误区。 然而,该文的前后两个用例实际上都不是针对客户的真正的“最外层用例”,尽管作者作了些改进,但这些用例在具体的内容和写法上还存在一些问题。
1.引言
“本系统的目标是制作出一个跨企业的信息平台,为目标公司的客户进行服务。这些服务分成很多的方面,比如提供给银行的公司财务情况查询,提供给生产厂商销售情况的报告。提供给销售的商场以及店铺货源的情况,提供给物流,安装服务公司送货以及安排信息。从中赚取提高销售效率,减少运输损耗的费用。设定目标公司为 A公司,信息平台名称B系统。”
从上面介绍的内容来看,我猜 B 系统是 一个 类似于供应链 应用 的 企业 门户 系统,这里所说的 A 公司好像是一家从事商品分销的企业。通过该门户, A 公司可以有效地联系上家—生产商(供货商),下家—商场、店铺以及银行、物流公司、安装服务公司等客户或合作伙伴。
在讨论这个案例前,首先让我们重温一下什么是最外围用例( the outermost use cases ,根据 Cockburn 的定义改写) :
对于每一个用例找到它仍能适用的最外圈的设计范围,针对该范围为它编写一个概要用例; 对于一个将要设计的系统, 我们 通常可以找到一个更广的设计范围,而使主用角( PA , Primary Actor )仍然处于该范围之外,如果不断扩大该范围,可以找到一个临界点,主用角就会被包含在当前的范围之内,这个临界点就是最外圈的范围; 最外围用例是通过把同一个范围内具有相似目标的主用角合并到一起而创建出来的,它们把与这些用角有关的所有低层用例都汇聚到了一起。
如何获取最外围用例呢? Cockburn 给了一些步骤建议 :
(1) 从一个用户目标开始。 (2) 问“这个目标对主用角 AA (最好在组织外部)提供什么服务?”,用角 AA 是我们想要收集用例的最终主用角。 (3) 找出最外圈的设计范围 S ,使得 AA 仍然在 S 之外,给 S 命名。 (4) 找出最终主用角 AA 在设计范围 S 中的所有用户目标。 (5) 找出 AA 对系统 S 的概要目标 GG 。 (6) 为 GG 编写出概要用例。这个用例就是我们要找的最外围用例,它将一些海平面(用户目标层)的用例维系在一起。
值得注意的是,这里 Cockburn 所说的“系统” S 不一定都是指软件,它可能是软件系统(如 B 系统),也可能是业务系统(如 A 公司、企业、部门等)。 在下面第 2 、第 3 小节中我将按照 Cockburn 的最外围用例 定义 来考察 原文中的两个最外围用例 ,逐个分析存在的错误。用第 1 个例子说明以“操作人员”为 主用角 、最外圈范围为软件系统( B 系统)的正确写法,用第 2 个例子说明以“客户”为主用角 、最外圈范围为业务系统( A 公司)的正确写法。
2.软件用例 - 业务管理
用例名称: 最外围用例
错误分析: 显然这不是一个正确的用例名称。建议改为“业务管理”,解释如下文。
简要说明:
A 公司决定让其业务合作伙伴以及最终的用户通过互联网访问 B 系统以达到减少 A 公司本地人员的工作量以及提升工作效率的目的。 B 系统负责完成进销存业务、其它业务处理以及报表管理。一些系统维护人员还负责管理基础信息的认定与实现。包括四个用例:基础设置子系统,进销存子系统,其它业务处理子系统,报表子系统。
错误分析: 首先,用例的名称、内容中不应该出现“子系统”这个术语, subsystem 属于系统设计范畴。
从业务介绍来看,操作人员主要进行“进销存、报表和其他业务”的处理,系统维护人员主要进行基础信息管理,所以这 4 个概要用例(风筝层)分属不同的 PA 。这两种角色在概要白云层似乎没有必要严格区分,所以我们把系统维护人员和操作人员合并成“操作维护人员”,并且把这 4 个用例合并成 1 个最外围用例“业务管理”,并在此处描述。
用例范围: 跨企业信息平台 主执行者( PA ): 客户
错误分析: 从用例范围和基本流的内容看, 这里的 PA 应该是“操作维护人员”(客户作为 PA 的最外围用例见第 3 小节)。
用例层次: 白云(最高层次) 触发事件: 客户有购货的需求
错误分析: 这里应该描述可以检测到的事件(动作、状态的改变等),我们怎么知道客户有购货的需求呢?正确的说法可能是:客户以各种方式请求服务。
主成功场景(基本流) · 系统维护人员操作基础设置子系统维护基础设置的数据。 · 操作人员操作进销存子系统完成进销存业务。 · 操作人员通过报表系统分析查询业务结果。 · 操作人员通过其它的业务子系统完成对系统中的其它业务处理。(注,其它业务子系统包括财务资金等等子系统,将会子用例描述中强调)
小结:
从以上分析看,原用例存在着基本的概念错误,用例的主用角( PA) 、范围和基本流的内容相互之间存在不一致的现象。这 个最外围用例可以改写如下:
用例名称:
|
业务管理
|
范围:
|
B 系统
|
层次:
|
概要 / 白云
|
主用角:
|
系统操作维护人员
|
触发事件:
|
客户通过电话、邮件等方式向操作维护人员提出服务请求(如购货)。
|
基本流:
|
操作维护人员通过 B 系统可完成以下任务: 1. 基础信息管理。 2. 处理进销存业务。 3. 进行报表管理,查询、分析业务结果。 4. 处理其他业务(如财务资金管理)。 [ 用例结束 ]
|
3.业务用例 - 客户服务
用例名称: 最外围用例
错误分析: 显然这不是一个正确的用例名称,建议改为“客户服务”。
简要说明:
A 公司决定让其业务合作伙伴以及最终的用户通过互联网访问 B 系统以达到减少 A 公司本地人员的工作量以及提升工作效率。 B 系统负责完成销售业务以及报告销售情况。一些系统维护人员还必须为客户和职员设置安全存取级别。包括四个用例:增加服务( A 公司本地),增加服务(客户),报告业务情况,管理安全存取权限。
错误分析: 这段话其实不太像用例简述。最外围用例应该从 A 公司向客户提供服务的角度来叙述,比方说,可以请求服务,查询业务销售报表等。在本例中我们进行黑盒业务建模,涉及到 B 系统和系统维护人员的内容,比如安全级别设置,不应在此处反映。
用例范围: 跨企业平台
错误分析: 我们选定了 A 公司的客户作为 PA ,那么按照最外围用例的定义,最大范围边界应为 A 公司而不是 B 系统。实际上这是一个业务用例( Business Use Case )。虽然客户也可以直接访问 B 系统,但是对于客户而言,B 系统 不是最大的范围 。
用例层次: 白云(最高层次) 主执行者( PA ): 客户 主成功场景(基本流): ·客户通过电话,邮件联系 A 公司操作人员,请求一个新的服务。 A 公司的操作人员通过 B 系统处理服务请求。 ·客户直接通过 B 系统的客户端,请求与处理新的服务。 ·客户通过 B 的系统可以查询出销售情况以及其它相关情况的报表。 ·B 的系统维护人员将要对客户以及操作人员进行安全存取权限的设置。
错误分析: 在最外围业务用例的基本流中,主要包含一些用户目标层或概要层的用例,所以此处不应该出现与 B 系统、操作人员、系统维护人员相关的内容,它们在我们定义的范围边界( A 公司)之内。 根据以上分析,我将该 最外围用例改写如下:
用例名称:
|
客户服务
|
范围:
|
A 公司 / 业务
|
层次:
|
概要 / 白云
|
主用角 :
|
客户
|
触发事件:
|
客户提出服务请求
|
基本流:
|
客户可以下列 2 种方式获得服务: 1. 服务请求处理:客户通过电话、邮件、客户端软件等方式请求服务, A 公司接收请求后进行相应处理,并把处理结果以恰当的方式返回给客户。 2. 销售查询:客户通过客户端软件直接查询销售情况及相关报表。 [ 用例结束 ]
|
4.总结
有人认为:“ 也许针对一个项目可以有很多‘正确的'最外层用例的设计方法。上面两种划分方式应该说只从最外层用例的角度来说都是正确的 ” 。我不同意这种开脱的说法,针对 1 个项目抽取最外围用例实际上只有 1 种“最优解”。为什么?道理很简单,因为最外围用例是 Cockburn 提出的,他给出了找到最外围用例的步骤和方法,而这种方法是明确的、无二义性的。人们找错了最外围用例,多半是因为没有理解和掌握这套方法。
概括一下,原文主要存在以下错误:
1 )由于用例的主用角 、范围与基本流的内容不一致,导致那两个用例都不是真正的最外围用例。实际上,针对“客户”的最外圈范围是 A 公司,而针对“操作维护人员”的最外圈范围是 B 系统。
2 )在用例的功能描述中出现了软件内部设计的内容,不符合需求提取、分析的要求。
最终,由于原作者对于为什么要编写用例,用例与传统结构化方法的功能总体描述究竟有何实质上的不同,用例有哪些特点,缺乏准确而深入的理解,导致编写用例的时候思路凌乱,把几种内容混杂在一起,做成了一碗“杂烩面”。 这个案例给我们的重要启迪是,抽取用例最关键的一步是首先明确 SuD ( System Under Discussion or Design )范围的定义 以 及针对这个范围的主用角 。 如果用 传统 “结构化”的老思路来套用例的格式,换汤不换药,那对 IT/软件项目开发将起不到真正的效果,甚至可能产生负作用,如果那样还不如不写用例。 最外围用例便于我们将关注的焦点转向用户真正需要什么,从而真正地从用户的角度出发来考虑问题
|
相关推荐
一套完整的手机外围器件的测试用例!
APB总线是一种低带宽、低功耗的接口,常用于连接主处理器和外围设备。在VMM中,我们将创建一个模型来模拟APB总线的行为,以及主设备(Master)和从设备(Slave)的行为。VMM的核心概念包括类库、环境、代理、驱动、...
"6410_Test_Rev01"可能是一个测试套件的版本号,包含了以上所有功能的测试用例和脚本,用于全面评估S3C6410处理器在实际应用中的性能和兼容性。通过这样的测试,开发者可以确保基于S3C6410的系统在硬件层面达到预期...
通用串行总线(USB)最初被设计为PC机和外围设备之间的接口,现已成为计算史上最成功的通用PC机接口。 1.嵌入式主机:嵌入式主机(EH)产品在一个主机上提供目标主机功能或更多标准A或微型AB插座。嵌入式主机产品也...
本篇将详细解析包含14个经典实验的DSP测试程序,这些实验涵盖了UART(通用异步收发传输器)、SPI(串行外围接口)、步进电机控制、定时器应用以及LCD(液晶显示器)显示等关键功能。 1. **UART实验**:UART是一种...
4. **其他外围应用电路**:除了核心的读写电路,我们可能还需要额外的电路,如电源管理、复位电路、晶振、电平转换器等。这些辅助电路确保系统的稳定运行。 5. **232、电平转换资料**:由于单片机和U盘之间的电平不...
在测试模式中,主板会搜索MDB外围设备,并在找到设备后进入正常操作界面,使开发者能够通过支付设备进行支付,并通过键盘选择对应商品进行操作。 综上所述,MDB协议测试平台为自动售货机相关系统的研发人员提供了一...
6. **串行通信**:UART(通用异步收发传输器)和SPI(串行外围接口)是常见的串行通信协议。程序实例可能涉及发送和接收数据,理解波特率、帧格式和握手协议。 7. **模拟电路与数字电路**:单片机通常与模拟电路...
本文档详细介绍了RFC如何在PI创建配置并导出wsdl供外部系统调用,本篇进介绍服务提供方是erp,供外围系统调用的用例,外围发布服务erp为消费方的PI配置请见PI开发手册02。由于所用实例使用的是项目实例。在此声明,...
在"sonic-platform-common-master"这个压缩包中,你可以找到源代码、文档、示例以及测试用例,帮助开发者了解和定制这个包,以适应新的硬件平台或实现特定的需求。通过深入理解和利用这个包,开发者可以更有效地为 ...
- 项目描述:负责银行系统合并后的UAT验收测试,包括外围系统和核心系统的改造。 - 职责描述:主要负责BICS-BOCP柜面系统的UAT测试,同时进行企业网银和银企直连的系统测试和用户验收支持。 2. **项目名称:两行...
2. **SIM卡接口**:SIM卡通常使用UART(通用异步收发传输器)或SPI(串行外围接口)与微控制器通信。UART接口简单,但速度较慢;SPI则提供更快的数据传输速率。根据描述,这里可能使用的是UART,因为未提及SPI相关的...
3. 写操作:发送AT24C02的7位地址和写命令,然后等待应答。接着,将数据字节逐个发送到AT24C02,并确认接收应答。 4. 读操作:发送AT24C02的7位地址和读命令,然后读取返回的数据。在读取过程中,可能需要模拟IIC主...
5. **外设连接**:例如GPIO、ADC、PWM等,需要根据实际应用需求连接到相应的外围电路。 "PCB源文件"则是将原理图转化为物理实现的过程,包括元件布局和走线设计。在PCB设计中,需要注意以下几点: 1. **布局**:...
本程序是基于C语言的凸包算法(Graham)实现,能够直接编译运行,计算凸包的点为随机生成。该程序为控制台应用程序,输出结果有凸包顶点坐标、以及一个50*50的矩阵,其中0表示空白点,1表示随机生成的点集,2表示...
为了更好地理解如何使用这些API,文档中还提供了两个代码示例,一个是使用治理API创建航空公司(CreateAirline)的示例,另一个是使用治理API变更航班连接(ChangeFlightConnection)的示例。这些代码示例能够指导...
这通常涉及到编写测试用例,覆盖各种可能的总线操作和异常情况。在C#中,可以利用单元测试框架,如NUnit或xUnit,编写针对APB总线读写操作的测试。测试应包括正常读写、错误处理、边界条件等,以确保代码的健壮性。 ...
固件测试是针对嵌入式设备中运行的软件——固件进行的一...通过理解固件与外设之间的通信协议,可以更精确地生成测试用例,从而更好地暴露固件中的漏洞。这种改进的方法对于未来固件测试工具的发展提供了有价值的参考。