【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. 即使是，也是设计约束类型的需求 |