社会主义好

    网上有不少录屏软件，可以将你的操作全部录制下来然后保存成SWF或者视频格式，用于教程制作非常方便。

    好象是去年的时候我用WMEncoder实现了一个。但WMEncoder有个严重的问题，就是一旦开始捕获后双击事件基本上就不能用了，所以我们经常看到的录屏软件应该不是基于这个实现的，应该是更底层的东西。前几天又有想法实现一个这样的软件，所以到网上找了下资料，发现根本找不着这方面的信息。所以自己猜想了下实现的方法。不过这两天又忙于另外一个东西了，所以这个想法还没有具体的实现。

    其实猜想的实现方法原理上很简单，这和视频文件的原理是有关的。众所周知，视频文件是以帧为播放单位的，这和最原始的电影胶片是一样的。在这里就不重复一遍电影的播放原理了。

    视频文件的格式一般都是一个头，然后加帧的列表的形式，而帧的数据最终肯定会被还原成一张位图，然后拷贝到显卡上进行显示。而这个过程是可逆的,也就是一张位图也是有方法转化成一种视频格式的帧（类似于解码器与编码器）那么我们不就可以每隔一断时间，截取当时整屏或者屏幕某块区域的位图（这个就简单多了，其实就是一个简单的截图而已）。然后将这个位图以及他的时间等信息存起来，这样当需要转化为某种格式时，只需将这些连续截取的图片构建成视频文件里连续的帧然后构造些头信息就可以了。当然这个间隔的设置，一般如果感觉不到卡的话为20毫秒，也就是0.02秒，因为人脑的反应速度就是这个。当然实际情况会比这个数要少，因为要考虑到机器的性能和你截屏以及保存的时间。 当然在实际处理的时候，你无须为每种格式都写一个构造器，只需实现一个最简单的，然后从网上找相应的格式转换的DLL就可以了。至于有些录屏软件上在鼠标点击的地方会出现一个提示（例如一个象瞄准镜的东西），你可以做一个全局系统钩子，记录下所有的事件及时间就可以了

补充：经过试验，截屏效率有些低，但勉强可以忍受，存取图片的速度实在是太慢了，另外还有一个问题就是光标问题，截屏光标是没办法显示的。

所以为了解决这些问题思路是这样设想的，

1.截屏效率问题  截屏还是要截的，毕竟不截屏的实现是不存在的，只是截屏的方式改改，直接从内存中或者显卡内存中拷贝的话，效率应该就不会成什么问题了。

2.存储慢的问题 这个直接存储在磁盘上就忽略了，先缓存在内存中，达到一定程度在使用另外另一个线程异步压缩存取到磁盘。

3.光标问题 在每次截屏（直接拷贝的方式）的时候记录当前光标位置以及光标类型及其它相关信息，转化成视频帧，手动在那个位置再画一个光标出来 

再补:查了些资料，微软提供了一个AVI的创建生成等的开发包 vfw (vfw32.lib) 截图后使用这个可以生成AVI文件

     用例实在是个很让人难以理解的东西，不同的书有不同的说法，看的越多就越糊涂，现在已经记不清是从哪本书里看到的概念了，就是用例是一系列没有明显时间中断的连续发生的事情，刚看到这个概念的时候那真是如获至宝，所以后来相当长的一段时间内，做需求写用例都是奔着这个目标去的，但慢慢问题就出来了，如果按着这个定义来，稍小的项目还可以，稍大一点的，光画用例图就够受的了，就不讲那一堆密密麻麻的用例，客户是否真的能看的清楚明白了。回过头来想想，当时对于这个概念的接受，说白了还是源于过重的程序员思维，因为这样的用例更容易映射到设计中去(主要是方便画顺序图)。一个没有明显时间中断的动集不就是一次人机交互嘛，执行者输入了什么，机器怎么处理的，返回给了执行者什么东西。按着这个思维写出这个用例的详细步骤，然后在设计阶段把这个详细步骤直接拿过来，结合一下领域模型大致提取一下对象，再给他们分配一下职责，再理一下关系，然后再把这些串起来，OK，一张初步的顺序图就出来了，这多方便啊。 

        当然话虽如此说，但并不代表着我就否定了上面的这种定义。上面的这种定义本身没有错，只是相对于某些项目来说，尤其是中型以上的，粒度过细了。经常有人把用例及其之后的业务建模比作是客户和设计之间的一座桥梁，我觉得这个比喻并不恰当，用例及业务建模并不能象桥梁那样把两端进行无缝的连接，充其量他只能算是立在两岸之间的一个木桩，他和两端都存在着一定的距离，于是问题就出现了，那就是这个木桩应该是靠客户更近些呢还是靠设计更近一些。这个问题我给不出准确的答案，但个人认为，应该更偏向于客户一方，因为，用例以及业务建模的主要目的还是获取更准确的需求，而要想获取更准确的需求，至少你的用例以及模型得让客户更容易理解，所以用例粒度以建业务模型主要依据还是客户的需要，而非设计人员或者程序人员的需要。故而用例的粒度并非必须达到“一系列没有明显时间中断的动作集”这样的细粒度，那么粒度究竟多大为宜呢,这我也说不准，不仅说不准，实际操作中也很拿捏的准，这和客户的理解能力，客户的配合度，个人的交流能力以及项目经理给你分配的需求调研的时间都是息息相关的。所以用例的粒度怎么界定这东西实在是让人很头痛的一件事，看书也是废的，最终还得实际情况实际对待  

     本来这篇文字的名字叫关于用例的理解的，但写完后，再回头看一遍后发现竟然和原来看用例方面的书一样，越看越迷茫了。于是乎将名字改为关于用例的废话了     

     短短的这一点字，竟然写了我一个多小时了，这也太废时间了，突然发觉那些写文章共享的人的实在是太伟大了。