CLTF Domain Analysis

一直没有踏下心来先对domain建模，就先凭感觉写了connection的代码。要对domain建模就需要了解需求，在工作中也日益发现 需求的复杂性。业务的复杂需求如何让domain model清晰的表现出来是个问题。entity之间的关系能够搞对看似简单，其实已不是件容易的事情了，再加上用户对业务规则貌似‘挑剔’的需求更使得 建模不容易。
就CLTF来说，我们希望这个软件能够：1,通过telnet协议telnet到某个设备，2,来执行设备上允许的各种命令，3,并对命令的结果正确与否作出判断。
下面展开来说：

1. 希望这个软件能够同时telnet到任意多个设备。
2. telnet到设备后能够提供一个UI来模拟终端界面，通过这个界面能够发出设备可识别的命令并显示执行结果。
3. 能够把一系列的命令放在一个文本文件中，在CLTF中将这些命令发送到指定的设备上去运行。
4. 使用正则表达式对命令结果的正确与否进行判断。
5. 能够通过UI显示执行进度。
6. 能够通过UI看到命令执行时信息。
7. 命令执行时可以选在是否记录命令执行信息到日志文件。
8. 能够清晰地标识出哪个命令失败了。

这8个需求比起前3个已经具体一些了，但还是远远不够。在这些简短语言的描述下，还掩藏着很多的变数，还有很多需求将随着对这些大粒度的需求的澄清而提出来。正是随着需求的逐渐细化，我们的domain才变得“复杂”起来。
希望这个软件能够同时telnet到任意多个设备。

• 提供一个device视图，以图形化的方式显示用户定义了的设备。
• 在这个视图里能够添加设备、删除设备、修改设备信息。
• 用户点右击某个设备时弹出菜单中有一个“telnet连接”按钮，用户点击此按钮，在建立到该设备的一个telnet连接。

至此关于连接设备的需求清楚了么？没有!

‘图形化的方式显示’是怎样的显示？各个设备都是相同的小图片代表？设备信息包括哪些？显示给用户哪些？
允许用户在视图里添加设备，那么用户是在视图里右击出菜单添加，还是通过视图的action item添加？
根据以上问题，细化出新需求：

• 设备信息包括：设备名称、IP、描述、以及一个与CLTF发生的连接数。
• 系统提供若干代表不同设备的小图片，当创建某类设备时就使用某个图片形象化地表示该设备。
• 以表格的方式显示设备，一行一个设备。
• 点击表格的各个列头可以对设备进行排序。
• 每行列表提供一个delete按钮来执行删除设备的动作。
• 每行提供modiy按钮来执行修改设备信息的动作，修改后需要通过update按钮提交修改。

TelnetEngine重构 （2）

Dahui's Code Life: TelnetEngine重构，Connection, Protocol 以及 Command各司其职 (1)

Refact:

• IConnection 的connect()方法重命名为open()、disconnect()改为close()、receiveText()改为receive()。
  
• IResponseListener 改名为IReceiverListener，这样就可以与IConnection的receive()方法对应了。一个IConnection既是 sender也是receiver，有双重功能、角色。如果另外建立ISender, IReceiver，再让IConnection实现这个两个接口也是很有道理的。暂且不这么做吧，毕竟现在只有IConnection隐含有这样的角 色。
• DslamTelnetProtocol重命名为DslamTelnetStreamParser,并且imeplements IReceiverListener。
• Create another class WindowsTelnetStreamParser which implements the IReceiverListener。这样就可以对设计进行脱离设备的调试。先复制DslamTelnetStreamParser的代码过来，这样以后可以再考虑哪些可以提取到父类中。
• Create a data class WindowsTelnetConstantData。这个类包含处理window Telnet客户端需要的一些常量，比如欢迎字符串、login提示符、密码提示字串、More page提示等。
• 问题：如何把输入反馈给外面的一层？
  

Refact:

• ResponseReceiverThread 设计成为TelnetConnection的内部类。毕竟这个thread只供TelnetConnection使用。

GAE and Pydev

参考此文http://daily.profeth.de/2008/04/google-app-engine-eclipse-pydev.html，就可以通过eclipse+python开发GAE应用了。我用eclipse3.4, python2.5, GAE 1.1.7，按照文章中的步骤去做遇到一些问题，又下载了jypthon2.5并配置pydev中与jpython相关的条目。python项目有两种类型python和jypthon。这两种类型的项目都可以跑起来。

但有时候启动时提示“Variable references empty selection: ${project_loc}”。改用绝对路径就没有问题，使用${workspace_loc:YourPrjName/appengine/dev_appserver.py}也没有问题。这也许是pydev 的bug.

eclipse中通过"${project_loc}\src" 表示项目的src目录。${workshop_loc}是workshop目录。

今天按照"Getting Started: Python"简单的学了一下GAE。感觉很多思想跟用java开发web app雷同。Django的template跟velocity、freemaker的使用模式差不多。GHL跟HQL差不多，我都怀疑google的datastore是不是已经直接就是OODB了。
不知道google的datastore API是不是像Hiberante一样强大，希望是！

需求之后，先澄清关系。

设计模式、分析模式、实现模式，各种各样的模式。思考的模式、挖掘需求的模式也很重要。所有这些模式都和围棋的"定式"差不多，都是是些经验：解决这样的问题，基本就这些套路。最低一级的模式就是类似于hibernate SessionFactory使用这样的惯用法。下面的套路是High level一层：

现在工作中修改代码时总是发现问题，其中一些问题是因为当时给软件建模时没有把各个实体的关系搞对。一对一，多对一，一对多？这些经常在create table时要思考的问题，在紧随需求阶段之后的设计阶段搞清楚'对象'的关系很重要。根据需求，抽取名词之后，需要给这些名词连线的时候，请思考一下"一对一，多对一，一对多"？还是包含关系？还是没关系？只有根据需求，给各个"名词"建立了适当的关系，才能保证你设计的基础是稳固的，因为这最近接你要用软件模拟的现实世界。当你发现软件改动起来分费劲，基本上是因为你的软件模型与现实中的实体不太符合――缺少了某种属性、行为的表达，或者它们表达在了错误的地方（Class）。

功能的作用域

现状：
在测试脚本执行过程中需要监控CPU, Memory的使用情况。目前的情况是自定义了一组脚本命令：开始监控、等待、停止监控。
然后让创建脚本的人去把这些指令加入到测试脚本中。

问题：
最近用户又提出新需求：需要监控某些process的RSS, VSZ的情况。目前的办法是把process监控的功能发到了以前的脚本命令中。这样，如果监控，就监控了所有的东西。用户并不能容易的定制（需要程序员开发出GUI界面）。我不是脚本的使用者，但是，还有一个功能我觉得更重要：可以随时确定是否对某个测试（若干设备命令组成）进行监控。

解决：
像性能监控这种问题是不应该放在脚本层次来做的。应该作为一个通用功能提取到更高一个逻辑层次上。用户可以在运行测试用例时决定是否进行性能监控、以及监控什么（CPU, memory, process）。通过GUI用户可以在启动项目前进行设置，这是粗粒度的使用。应该还提供定义良好的API进行供程序员对监控功能进行细粒度的使用、暴露。

变量有作用域，其实功能也是有的，就如上面说的。