所在位置:答疑 - 内容   
公安刑侦的系统,用例的名字是:案件信息采集入库
 

【2007-5-23  11:25:19  阿K】
在编写用例的时候,如何表示并行处理的情况?比如,有两个actor 在同时工作 
【2007-5-23  11:58:45  潘加宇】
具体举个例子 

【2007-5-23  12:03:46  阿K】
用例描述系统A,有系统参与者用户B,和一个外部系统C(我把它当作一个系统参与者)用户B 向系统A 提交一份文件,然后A 把数据转给系统C 处理,用户B 这个时候并不等待,而是继续提交下一份文件。 
这个期间,如果系统A 收到系统C 返回的处理结果,那么用户B 可以随时暂停录入,去处理这些结果  在处理完成后,继续录入新的文件。这个过程一直重复直至所有文件处理完毕 
这个过程是在很短的时间内发生,比如1、2 个小时 
【2007-5-23  12:07:00  潘加宇】
这个跟并行没什么关系,你就把涉众想要,而系统又能提供的价值描述出来,不管怎样都是对的 
用例的名字叫什么?

【2007-5-23  12:08:05  阿K】
这是一个公安刑侦的系统,用例的名字是:案件信息采集入库 
【2007-5-23  12:08:48  潘加宇】
那要达到什么样的目标,用户才觉得你这个系统不是白吃饭的 

【2007-5-23  12:10:49  阿K】
用户部署了一个指纹识别系统(就是刚才例子里的C 系统),从我们的系统(B 系统 )录入指纹信息,把这个信息提交给指纹识别系统,目的是得到比对的结果,来确定疑犯 
【2007-5-23  12:12:09  潘加宇】
那至少你的系统应该能为它做到把指纹信息交给了指纹识别系统?

【2007-5-23  12:12:26  阿K】
是的 
并且能够把指纹识别系统的结果反馈给用户 
我在写这个用例的时候,感觉用顺序式的描述很难讲清楚这个过程 
【2007-5-23  12:13:38  潘加宇】
那名字怎么叫做"案件信息采集入库"呢 

【2007-5-23  12:14:16  阿K】
确实有点问题,不过还没想到更好的 
2007-5-23  12:17:37      潘加宇 发送 C:\Documents and Settings\jypan\MyDocuments\ucdescription.doc 
【2007-5-23  12:17:55  潘加宇】
你先按照我们课上的文档格式写一下,然后再讨论 

2007-5-23  12:18:07      潘加宇 发送 C:\DocumentsandSettings\jypan\MyDocuments\海程1low.mdl 
【2007-5-23  12:19:39  阿K】
还有,因为这个文档现在主要是给开发人员做设计用的,我担心写得不够准确得话,会发生歧义 
【2007-5-23  12:21:03  潘加宇】
需求不是为了给设计人员看而写的,而是要准确定义出涉众关心的问题 

【2007-5-23  12:22:59  阿K】
可是设计和测试文档也要根据需求来的啊? 
【2007-5-23  12:24:15  潘加宇】
需求只是出题,至于如何解题,那是设计人员的责任,他们需要拥有相关技能。 
【2007-5-24  21:41:23  潘加宇】
级别: 用户目标--这个可以删掉,已经指明研究对象,不用再说这个 
触发事件:痕检员从案发现场拿回若干张指纹卡--删掉 
1、 痕检员录入案件描述信息 2、 痕检员用扫描仪从指纹卡采集指纹图像  
全部缺少系统的活动

【2007-5-24  21:43:05  阿K】
问题:痕检员此时不必等待查询结果,可以继续采集和编辑下一枚指纹信息。在编辑的过程中,如有查询结果返回,
痕检员可以随时暂停录入和编辑,去鉴定查询结果如何在用例里描述这个场景?  
【2007-5-24  21:43:08  潘加宇】
用例很可能不需要描述这个场景 
因为这也许不是需求 
为什么不必等待查询结果 
你设想了一个异步的解决方案,背后的需求是什么

【2007-5-24  21:43:55  阿K】
我觉得是,因为这样可以加快处理的速度 
对于案件的尽早破获是有意义的 
异步的方案,是一个环境约束 
因为外部的A××S 系统是已经存在,交互方式已经确定了 
【2007-5-24  21:46:05  潘加宇】
首先,也许这不是需求。涉众只在意每分钟能处理多少条,这是一个非功能需求 
其次,即使这确实能成为需求,也是有系统响应的,异步的方案也一样 
1、 痕检员录入案件描述信息 
2. 系统保存案件描述 

【2007-5-24  21:47:37  阿K】缺少系统响应是一个问题 
【2007-5-24  21:47:39  潘加宇】
3.2、 痕检员用扫描仪从指纹卡采集指纹图像 
这是系统外的操作? 

【2007-5-24  21:48:07  阿K】
不是,是系统内的操作 
【2007-5-24  21:48:08  潘加宇】
痕检员请求采集指纹图像 
系统请求扫描仪从指纹卡获取图像 
"从指纹卡采集指纹图像"不是痕检员的责任
人的责任只是做出请求

【2007-5-24  21:48:36  阿K】
把扫描仪作为一个参与者吗? 
【2007-5-24  21:49:39  潘加宇】
把扫描仪作为一个参与者吗?--看你怎么揣摩涉众的意思 
总之,系统请求扫描仪从指纹卡获取图像,或,系统请求指纹卡获取图像 
都可以 
请参照我们课上说的鼠标,打印机的例子 

【2007-5-24  21:50:35  阿K】
用户能够在系统内控制扫描仪是用户提出的一个明确要求 
【2007-5-24  21:50:42  潘加宇】
所有这些我们课上都说过的

【2007-5-24  21:50:56  阿K】
哦,这个我得再回忆一下,呵呵 
【2007-5-24  21:51:14  潘加宇】
指纹卡和扫描仪什么关系

【2007-5-24  21:51:29  阿K】
指纹卡是纸质的卡片 
要变成计算机能够处理的图片 
【2007-5-24  21:52:02  潘加宇】
那应该写:系统请求扫描仪扫描图像 
扫描仪上放的是不是指纹卡,系统无法判断。

【2007-5-24  21:52:46  阿K】
不能 
需要用户去保证 
不过在A××S 系统那边有一些自动识别算法,能做检查 
【2007-5-24  21:53:29  潘加宇】
你之前这样写,好像自然就知道一样,模糊了系统的契约,也抹杀了改变的可能--要是指纹卡不对怎么办? 

【2007-5-24  21:54:09  阿K】
恩,这个应该写在扩展路径里面 
【2007-5-24  21:54:15  潘加宇】
总之,你要把系统能做什么,不能做什么写清楚。 

【2007-5-24  21:54:53  阿K】
好的 
关于系统响应的问题,我还有个疑问 
1、 痕检员录入案件描述信息 2. 系统保存案件描述 3.2、 痕检员用扫描仪从指纹卡采集指纹图像 
也许在步骤2,系统并不需要保存案件的描述 
可能是在指纹录入完后一并保存的 
这样写,是不是引入了一些不必要的操作呢? 
【2007-5-24  21:58:49  潘加宇】
也许在步骤2,系统并不需要保存案件的描述--那么应该合在一步写,一直到系统响应为止 
1. 痕检员录入案件描述信息,请求采集指纹图像 2、系统请求扫描仪采集图像  
恩,这个应该写在扩展路径里面--这也不是扩展路径,因为系统根本无法判断 
3. 系统显示指纹图像 
4. 痕检员编辑指纹特征信息,请求查找 
5. 系统将案件信息发送给A××S 系统请求查找 

【2007-5-24  22:01:57  阿K】
哦,这样写得话,就可以把人工检查指纹图像,发现有误,请求重新扫描写在第3 步的扩展路径了吧 
【2007-5-24  22:02:35  潘加宇】
6、 A××S 系统返回比中结果--此句删掉。A××S 系统不在契约范围之内。你只能说明系统接收到正常结果怎样,接收到异常结果怎样 
人工检查指纹图像,发现有误--也不是扩展。系统怎么知道人工检查了没有? 
需求是描述系统的契约。如果要看大局面,应该在业务序列图里描述 

【2007-5-24  22:04:01  阿K】
我的意思是, 
用户可以请求重新扫描——在重放卡片之后 
【2007-5-24  22:04:49  潘加宇】
也就是说在"3. 系统显示指纹图像"之后? 

【2007-5-24  22:05:13  阿K】
是的,这是是系统等待用户响应 
用户可以选择不同的操作 
【2007-5-24  22:05:31  潘加宇】
那应该这样写: 
痕检员可以
请求重新扫描 
这是一个扩展,这说明这个分支是由痕检员的选择决定的 

【2007-5-24  22:07:00  阿K】
写在扩展路径那里是吗? 
【2007-5-24  22:07:14  潘加宇】
基本路径 

【2007-5-24  22:07:27  阿K】
基本路径的第3 步? 
【2007-5-24  22:07:34  潘加宇】
第4 步 
1. 痕检员录入案件描述信息,请求采集指纹图像
2、系统请求扫描仪采集图像
3. 系统显示指纹图像
4. 痕检员可以:
请求重新扫描 
下面有扩展点4a. 重新扫描: 

【2007-5-24  22:08:47  阿K】
明白 
【2007-5-24  22:09:31  潘加宇】
7、 痕检员鉴定比对结果--这个如果是系统外的,删掉 

【2007-5-24  22:10:01  阿K】
系统内部的 
因为过程比较复杂,为了可读性考虑,就单独提出了一个用例 
【2007-5-24  22:11:23  潘加宇】
因为过程比较复杂,为了可读性考虑,就单独提出了一个用例--用例是反应涉众在意的东西,不是由开发人员乱来的 
那么7. 应该是:系统鉴定比对结果? 
过程比较复杂--复杂在那里? 
算法比较复杂? 

【2007-5-24  22:12:45  阿K】
是系统提供一个鉴定的界面,由用户通过肉眼比对鉴定,但是系统提供一些功能,类似于版本管理系统里面的文本比较 
不过比较的是特征 
是因为操作比较繁多 
【2007-5-24  22:14:29  潘加宇】
如果"鉴定比对结果"不做就回家了,你觉得涉众会觉得这个事情有用吗 
或者说,会觉得你这个系统帮到他的忙,值得他付钱吗 

【2007-5-24  22:15:17  阿K】
鉴定是一定要做的 
【2007-5-24  22:15:42  潘加宇】
那就写出来 

【2007-5-24  22:15:52  阿K】
关于提取用例的问题,我有点不同意见 
编写有效用例那本书里,有这种做法 
这里提取用例不表示中断操作,只是可读性的考虑 
你怎么看? 
【2007-5-24  22:23:56  潘加宇】
可读性--是从涉众的角度看的 
Cockburn 的那个"泥土级"用例不值得提倡 

【2007-5-24  22:24:38  阿K】
泥土级? 
【2007-5-24  22:25:11  潘加宇】
就是海平面以下,把步骤当作用例

【2007-5-24  22:25:20  阿K】
恩 
呵呵 
可是,鉴定的操作更不好描述 
因为它的操作有点像photoshop,有各种工具箱 
【2007-5-24  22:26:46  潘加宇】
用例就是写系统的需求,只不过形式是执行者动作,系统回应的组织方式。其实并没有太多规矩。 
你写的东西问题不在于不在于不了解规矩,而在于它们不是需求 
你先保留在里面,详细描述,等到文档都写完了,如果发现这些操作集合(注意,不是一个步骤)在别的用例里面也会用到,才可以提取为子用例。 

【2007-5-24  22:30:14  阿K】
好的 
在用例里面不应该描述用户界面设计吧?这些描述怎么写呢? 
【2007-5-24  22:31:56  潘加宇】
同样,见我们的幻灯片 
1. 具体的界面细节可能不是需求
2. 即使是,也是设计约束类型的需求