用例模型设计需要注意的几个问题

本文探讨了用例模型设计中的常见问题,包括角色的定义(不仅限于人),用例的适当粒度(应为最小功能单元),用例描述的详细性和方式,以及用例间关系的正确表示(包含、扩展和通用化)。同时强调了活动图和顺序图在流程描述中的重要性。
摘要由CSDN通过智能技术生成
 

  什么样的用例模型是正确有效的呢? 很多人在用用例模型描述软件需求的时候都会有这样的困惑,下面就来阐述一下比较常见的问题。

一、     角色不仅仅指的是人

    首先,要强调的是角色不仅仅指的是人,任何需要和软件交互的其他系统和设备都是系统的角色。

   比如,一个软件系统需要从其他遗留系统中获取数据,那这个遗留系统就是这个软件系统的角色;再比如,软件系统运行过程中,时钟会在某个时刻产生提示或警报,那这个时钟也是一个角色。

二、  用例的粒度

    用例的粒度应该是一个功能模块吗?不是,功能模块在用例模型里面用包来表示。

    用例是一个产生可见的有价值的结果的最小功能。也就是说,用例不可以是一个功能碎片,例如,输入用户名,显然不能成为一个用例,因为它并没有产生任何有价值的结果,而验证用户身份,则属于一个用例,因为它的结果就是用户身份正确或不正确。

   对于粒度的最多的讨论可以说是“四轮马车”问题了。就是一个功能的添加、修改、查询,和删除是否都需要单独用一个用例来表示。其实这个问题可以灵活处理,根据软件的复杂情况来决定,如果你有太多的更重要的需求需要来描述,就没有必要就这些细节关注太多,如果你只需要关注某个用例,而且也有详细描述的必要的话,描述出来当然也没有问题。通常情况下,可以用扩展点的方式描述查询和修改的关系。

三、用例描述

     复杂的用例需要单独用一个文件来描述,主要是用例的前置条件、后置条件、基本事件流、扩展事件流,和用例的优先级等。

  

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值