|
|
|
|
一个关于用例划分的讨论 |
|
|
|
作者：未知 来源：月光软件站 加入时间：2005-2-28 月光软件站 |
给一套系统做需求分析，其中服务器端程序有一个功能，就是将收到的数据包解包、入库。
我现在将其划分为三个用例
1、接收数据
2、分解数据
3、数据入库
其中分解数据中包括一个子用例，
2.1、验证数据
大家看这样对么？
我怎么老师觉得不对，于是乎又萌发出新的想法：
只有一个用例：
1、接收数据并入库
其中包含3个用例，
1.1、验证数据
1.2、解包数据
1.3、数据入库
大伙帮忙参考一下，哪种较为好一点，或者谁有更好的方法请提出，小弟感激不尽
---------------------------------------------------------------
这只是用例层次的问题
其实都可以
主要决定于你的观察面
---------------------------------------------------------------
最不同意第一种方案。
不太同意第二种方案。
验证数据、解包数据、入库，这是实现一个用例的三个步骤而已，不应该分别做为一个独立用例。
用例是从外界的角度来看系统。
---------------------------------------------------------------
不知道你是在做服务器端的开发吗？
如果不是那么你就犯了一个错误 use case是来阐述客户对系统的需求（注意是客户） 所以用例不涉及系统内部的实现 如果你是在做服务器端的设计工作 那么你自己就可能是客户 那么你这样使用use case是可以的 以我的经验 客户是不会提出这样额需求的
现在假设你这样分析用例是有理由的 那么你的几种方法都是正确的 只是它们的划分粒度不同 在我们设计系统的时候 总是先有高层次的需求 然后不断划分为比较详细的下面层次需求
他们只是出现的时机不同 但是总的来说 关键是最初时候的大粒度的use case 后面的划分不要太过与细小 关键是要知道不同粒度的用例所使用的范围不同
我对用例粒度划分标准是由下列指导的
1 用例都是有一个角色来启动的
2 用例是在一个时间区域内完成的 也就是说完成一个用例所要花费的时间不要太长 应该是一个短的时间的动作序列 但是注意这一条不适用在商业用例上
3 用例代表的是角色和系统的一次交互 一次是说角色在一个时间段和系统的交互 这一条同样适用商业用例
注意2和3条是划分最小粒度的标准
|
|
相关文章：相关软件： |
|
本类阅读TOP10