2009-9-15  10:31:52  hw.zhu：  一般在什么情况下使用Time作为Actor？
2009-9-15  10:32:44  潘：  该用的时候就用，时间直接引发用例的时候，
2009-9-15  10:33:16  hw.zhu：  嗯，这个我明白
2009-9-15  10:33:22  潘：  这是系统设计时往往会有一个timer 之类的东西去接收时间系统的信号
2009-9-15  10:33:29  潘：  你说具体的例子
2009-9-15  10:33:52  hw.zhu：  我的意思是，对Timer 的使用有没有什么特别的规定或者注意点？
2009-9-15  10:34:20  潘：  注意点就是分不清边界了，
2009-9-15  10:34:22  hw.zhu：  我给你具体的例子
2009-9-15  10:34:59  潘：  例如，每天上午九点，我都要到打卡机那里打卡
2009-9-15  10:35:41  潘：  有的人就来一个"时间-->打卡"，其实要是做一下业务建模，这些问题就可以消灭了
2009-9-15  10:36:16      hw.zhu 发送 ttt.jpg
2009-9-15  10:37:33  潘：  首先，后面include 纯属错误
2009-9-15  10:38:20  hw.zhu：  为什么？
2009-9-15  10:38:55  潘：  是不是时间引发的，你可以这样想，要是大家都睡着了，系统会不会到一定的时间就"计算和执行××方案"
2009-9-15  10:39:28  hw.zhu：  嗯，明白
2009-9-15  10:39:34  hw.zhu：  场景是这样：系统会定时计算某个应用程序的资源是否够用，如果不够则会提出建议的调整方案。
2009-9-15  10:40:04  hw.zhu：  如果用户还设定了系统可以自己按照建议的调整方案执行，则会启动"执行资源调整"uc
2009-9-15  10:40:28  潘：  我猜想"执行资源调整"只是一个步骤，因为写不出"请求－验证－改编－回应"
2009-9-15  10:40:34  hw.zhu：  如果用户设定系统不可以自动执行，则需要用户审批，审批通过才可以"执行资源调整"
2009-9-15  10:41:22  潘：  "执行资源调整"不是uc，只是系统内部的一个动作 
2009-9-15  10:41:48  hw.zhu：  嗯，因为"资源调整"的过程有点复杂，所以拿出来了。
2009-9-15  10:42:57  hw.zhu：  是抽取的过早了？
2009-9-15  10:43:40  潘：  这些都应该写在文档里面，用例是要"卖"的，你能用一个函数"资源调整"搞定好几个用例，那是你设计的技术高明，和需求无关
2009-9-15  10:45:38  hw.zhu：  嗯，前段时间还看过你的片子，明白你的意思
2009-9-15  10:45:49  潘：  需求是不"复用"的，"复用"的是设计
2009-9-15  10:46:00  hw.zhu：  对，这句话也很清楚，哈哈哈
2009-9-15  10:46:43  hw.zhu：  在实际使用中还是会有点"冲动"，就是冲出一些规则了。。。呵呵
2009-9-15  10:47:07  潘：  :D 我再看看上面的案例
2009-9-15  10:47:25  hw.zhu：  我把这个整个图整理一下，你也给看一下
2009-9-15  10:49:24  hw.zhu：  我提出这个问题是因为，上周在跟我的老大的老大review 我们的uc 时，他说"timer 好像不是这么用的"
2009-9-15  10:49:44  hw.zhu：  害得我查了一天的资料，去找对timer 使用的特别说明。。。