eclipse软件

eclipse软件（精选4篇）

eclipse软件 篇1

0 引言

计划评估是放射治疗计划设计过程中的重要环节,放疗医生勾画完靶区和危机器官后,医学物理师按照临床医师处方要求设计计划,设计计划过程中,每优化一次后都会对计划进行评估,并根据评估结果来对计划进行迭代优化,反复评估,最终做出满足或近似满足处方要求的计划,再与放疗医生沟通确定最优放疗计划。ICRU 50、62号报告[1,2]中指出评价调强计划优劣能参考肿瘤靶区(GTV)、临床靶区(CTV),计划靶区(PTV)、正常组织(OR)和计划正常组织体积(PRV)的DVH。本文的目的是开发一套适用于Eclipse11.0计划系统治疗计划DVH自动生成比较软件,并提供良好的用户界面,该软件不仅能读入临床医生所下处方要求;还能够生成当前计划的DVH;最终实现判断治疗计划是否满足医生处方要求,从而减少放射治疗物理师在做计划时,每优化一次后评价计划的重复繁琐操作,节省治疗计划设计时间,提高工作效率。

1 材料与方法

本研究采用了两种程序设计语言:Auto Hot Key和C#。Auto Hotkey是Windows平台下开放源代码的热键脚本语言[3],该语言通过发送键盘或鼠标的键击动作命令来实现操作的自动化,也可以通过命令调用系统接口及程序,并能创建基于简单语言的图形化界面的执行程序。C#是微软公司发布的一种面向对象的、运行于.NET Framework之上的高级程序设计语言。Eclispe11.0计划系统提供了基于C#的应用程序编程接口ESAPI[4](Eclipse Scripting Application Programming Interface)。它允许软件开发者编写脚本[5,6]访问Eclipse计划系统的信息,并且脚本整合到了Eclipse用户界面,能独立运行。现编写一套适合该计划系统的DVH自动生成比较脚本软件,该软件能模拟键盘或鼠标的键击动作和调用ESAPI来实现DVH自动生成比较,脚本软件模块包括:处方文档自动生成,C#中DVH操作函数,软件可视化以及DVH比较报告生成。

1.1 处方文档自动生成

Eclipse11.0计划系统的ESAPI没有提供对处方的读取库函数,本研究通过Auto Hotkey热键脚本语言处理Eclipse计划系统中的医生处方,软件能模拟键盘或鼠标的键击动作将医生处方自动转换成C#可读取的txt文档,并提供自动打印处方的功能。

1.2 定义C#中DVH操作函数

本研究定义两个类, 一个是与靶区有关的P T V C a t e g o r y类, 另一个是与正常组织有关的OARCategory类。PTVCategory类中定义了评价靶区相关参数:靶区名称、最小剂量、最大剂量、百分体积剂量等,还定义了评价靶区相关函数:获取靶区名称、获取靶区最小剂量、最大剂量等。OARCategory类中定义了评价正常组织相关参数:靶区名称、平均剂量、最大剂量、百分体积剂量、百分剂量体积等,还定义了评价正常组织相关函数:获取正常组织名称、获取正常组织平均剂量、最大剂量等。

在获取处方要求时,调用C#函数Read Alline读取txt文档每行,在处理字符串时调用Replace、Split和Contain等函数;在获取计划DVH时,调用了ESAPI中的函数Get DVHCumulative Data和Get Volume At Dose等,最终将处方要求与计划中各种靶区和正常组织的DVH比较按照规定格式输出到Excel中。

1.3 软件可视化及DVH比较报告生成

Autohotkey自带Gui命令,该命令可以创建和管理一个窗体及窗体之上的控件,本研究创建了脚本软件界面,用户能通过在Show DVH上输入病人ID号和治疗阶段号来运行软件,实现医生处方与计划DVH比较报告生成,与此同时界面上还提供了打印处方的控件。当用户输入病人ID号和治疗阶段号后,运行软件,如表1所示,表1是医生处方要求,对靶区比如PTV1处方剂量5 940 c Gy,最小剂量要大于处方剂量的98%,最大剂量要小于处方剂量的115%,100%的处方剂量包围PTV1体积要大于95%,110%的处方剂量包围的PTV1体积要小于5%等等,对正常组织,比如Spinal Cord PRV最大剂量小于4 500 c Gy等等;表2运行Show DVH后,计划的DVH与医生处方相比较结果,DVH没有满足医生要求的,用F表示,Mean Dose和Max Dose为0的是没有处方要求,正常组织的名字放表格中间是方便物理师查看。对靶区比如PTV1最小剂量为5 866.9 c Gy,最大剂量为6 520.5 c Gy, 100%的处方剂量包围PTV1体积为96.25%,110%的处方剂量包围的PTV1体积为1.56%,这样PTV1的DVH满足医生处方要求。对正常组织比如Spinal Cord PRV最大剂量为5 127.318 c Gy,这样Spinal Cord PRV的DVH不能满足医生处方要求,需对计划进行再次优化,反复评估,最终做出满足或近似满足处方要求的计划。

2 结果

2.1 验证软件在Eclipse11.0计划系统下的运行情况

在Show DVH上随机输入放疗病人ID号和阶段号,并在Eclipse11.0计划系统下运行脚本软件。在Eclipse11.0计划系统下能顺利准确完成脚本生成处方要求与计划DVH的对比,并输出到Excel中,方便放射治疗物理师快速查看计划是否满足医生处方要求,为接下来的调强优化参数设计指明方向。说明Show DVH能处理医生所下处方并能在Eclipse11.0计划系统下生成计划DVH与处方要求对比结果。

2.2 临床使用情况

临床上选取各10例病例,包括头颈部肿瘤、胸部肿瘤、腹部肿瘤、盆腔肿瘤,分别运行脚本软件,软件能顺利产生计划DVH与医生处方相比较的Excel文档。比如对于鼻咽癌,需要评价的靶区和正常组织较多,如果采用手动的方式一个一个去查看靶区或正常组织的DVH是否满足医生处方要求,那么就会费时费力,而且还容易出差错,在做下一次计划优化参数设置时,要么放射治疗物理师一次性记住多个组织的DVH,要么需要来回切换软件窗口查看靶区或正常组织的DVH,要么将组织的DVH记录在纸上。这样都非常不方便,脚本软件能解决以上手动查看DVH的不足。对于鼻咽癌,脚本软件运行后产生的Excel文档,能直接准确给出计划中所有靶区和正常组织的DVH与医生处方比较的数据,对靶区比如PTV1处方要求的最小剂量为5 885.88 c Gy,计划的最小剂量为5 894.5 c Gy,处方要求100%的处方剂量包围PTV1体积大于95%,计划中为95.49%,这样PTV1的DVH满足医生处方要求。对正常组织比如Spinal Cord PRV处方要求最大剂量为4 500 c Gy,而计划的最大剂量为4 514.553 c Gy,处方要求1%的Spinal Cord PRV体积的剂量小于5 000 c Gy,计划为4 136.7 c Gy,计划不能全部满足处方要求,因此计划需继续优化。对于其他肿瘤,脚本软件同样能给出计划中靶区和正常组织DVH与医生处方要求的比较结果,这样临床上脚本软件的使用能节省治疗计划设计时间,提高放射治疗物理师工作效率。

3 结论

放射治疗计划设计中,脚本使用越来越广泛,它不仅能减少放射治疗物理师的重复操作,提高效率,还能减少物理师出错的几率。Eclipse 11.0计划系统提供了基于C#的应用程序编程接口ESAPI, 允许用户编写脚本读取计划数据。本研究开发的脚本软件Show DVH,首先通过热键脚本语言处理医生处方文档,其次运用C#语言处理计划中的DVH,最后将医生处方与计划的DVH相比较并输出到Excel中,能快速判断计划的DVH是否满足医生处方要求,为下一步计划优化参数设置指明方向。通过一个表格把医生处方所有要求与计划的DVH都显示出来,优点有两个方面:一方面不用在Eclipse计划系统中一个组织一个组织评价DVH,并与医生处方相比较,另一方面因生成的Excel文档是独立于Eclipse计划系统的,在调强优化参数设置时不用来回切换软件窗口。虽然Show DVH功能强大,但是脚本软件运行完,还需对计划系统中生成的DVH详细检查,仔细复核,确保脚本软件安全使用。

参考文献

[1]ICRU.Prescribing,recording,and reporting photon beam therapy[R].ICRU report Bethesda:International Commission on Radiation Units and Measurements 1993.

[2]ICRU.Prescribing,recording,and reporting photon beam therapy(supplement to ICRU report 50)[R].ICRU Report Bethesda:International Commission on Radiation Units and Measurements1999.

[3]谢朝,胡金有,邹练,等.Eclipse计划系统轮廓自动生成软件开发[J]中国医疗器械杂志,2015,39(3):225-227.

[4]Eclipse Scripting API Reference Guide[R].Palo Alto USA:Varian Medical Systems,2013.

[5]Pinnacle3 planning reference guide[R].Fitchburg USA:Philips Medical System,2008.

[6]Ray Search Laboratories AB.Ray Station 3.0 Reference Manual[R].Stockholm,Sweden,2012.

Eclipse的应用发展 篇2

1 Eclipse简介

1.1 概况

由OTI和IBM两家公司的IDE产品开发组创建,起始于1999年4月,前期投入了4000万美金,2003年Eclipse3.0选择Osci服务平台规范为运行时构架,2007年6月,稳定版3.3发布,2008年6月发布代号为Gany mede的3.4版,可见Eclipse发展起源时间并不长远,近几年的快速发展,使得它进入一个新阶段,Eclipse基金会在此做了不少努力,2006年起,Eclipse基金会都会安排版本的发布,下面是9月及2月释放出SR1及SR2的版本细则,如表1所示。

从表1可看出版本平台在不断更新,每一年都在更新,以及发行的时间段都有很强的规律性。

1.2 插件机制

Eclipse的最大特点是它能接受由Java开发者自己编写的开放源代码插件。Eclipse的设计思想是:一切皆插件。E-clipse核心很小,其他所有功能都以插件的形式附加于Eclipse核心之上。Eclipse基本内核包括:图形API(SWT/Jface),Java开发环境插件(JDT)。在客户机平台上,Eclipse使用插件来提供所有的附加功能,例如支持Java以外的其他语言。已有的分离的插件已经能够支持C/C++(CDT)、Perl、Ruby,Python、telnet和数据库开发。插件架构能够支持将任意的扩展加入到现有环境中,例如配置管理,而决不仅仅限于支持各种编程语言。通常的软件必须通过重新编译的形式才能进行更改或扩充,而Eclipse则是通过插件机制,让可以动态地增加系统功能而无需修改系统代码。

1.3 Eclipse的主要组成

主要由Eclipse项目、Eclipse工具项目和Eclipse技术项目3个项目组成,具体包括四个部分组成———Ecli pse Platform、JDT、CDT和PDE.JDT支持Java开发、CDT支持C开发、PDE用来支持插件开发Eclipse Platform则是一个开放的可扩展IDEEclipse SDK(软件开发者包)是Eclipse Platform、JDT和PDE所生产的组件合并,它们可以一次下载。这些部分在一起提供了一个具有丰富特性的开发环境,允许开发者有效地建造可以无缝集成到Eclipse Platform中的工具。

Eclipse的不断创新,也出现了很多快捷键,例如:

熟悉快捷键可以帮助开发事半功倍,节省更多的时间来用于做有意义的事情。

Eclipse程序在Java编程中的应用:学习中Eclipse主要应用于学习Java中的语言编程,打开Eclipse软件,新建一个Java项目,并在里面新建一个类,便可以编写程序了,但此过程中可能遇到很多问题,比如建议不要用缺省包,以及提示此安装包是空的,这都要检查自己所创建的是否正确,否则无法编程,下面有上机课的一次作业清楚地说明Eclipse的应用。

此代码为一个常规的猜字游戏,程序会随机给客户一个1到100之间的整数,然后输入自己的猜测,程序返回提示信息,分别是"猜大了","猜小了",直到猜对为止,其中输入了一排数,绕了很多弯子才输出正确数字27,不是猜大了就是猜小了,其他同学也一样,猜了很久才猜出来,完全没有一次就猜对的同学,在编写这一程序时,很多问题值得注意,全程必须是英文符号,否则程序前面都会错误地提示让你修改,只要你的字节码不对,都会提示在哪儿错了,并且还有更改快捷键,或是更改方法,相对C语言而言,能及时有效地找出错误所在地,及时修改,节省时间。同时从上面的编程中,有很多收获,每一个单词,一个符号都必须细心打,很多时候打出来就是一竖排的红色提醒,只有全部没有红色提示后才能运行出所需要的结果,相对于Java而言,Eclipse与它就是饭与碗的关系,Eclipse就是盛饭的碗,辅助功能。Eclipse的应用给人们的Java学习创造了不可缺少的益处。总的来说Clipse是一个开放源代码的、基于Java的可扩展开发平台。就其本身而言,它只是一个框架和一组服务,用于通过插件组件构建开发环境。Eclipse附带了一个标准的插件集,包括Java开发工具(Java Development Kit,JDK),这是进行Java开发的必不可少的Java开发环境。

1.4 Eclipse的优点

(1)Eclipse是开源而且免费的,得到全面支持。

(2)Eclipse的支持超过Java的语言。

(3)Eclipse可无限扩展的强大插件功能。

(4)Eclipse在多重平台上提供一致的特性集。

(5)Eclipse是行业力量。

2 Eclipse在现代的发展

2.1 Eclipse的发展前景

软件的创始与开发,都有瓶颈与高潮时期,利于社会发展的就利用,不利的就淘汰,总的来说高科技的开发都是服务与人民,IBM软件集团Rational软件总经理Eclipse创始人之一这样说“Eclipse将面临一些挑战,这些挑战也是必不可免的,当今的商业环境,特别是软件开发的商业环境,受到速度,全球化,新的管制的影响,在以IT为主导的环境下,面临全球的竞争压力,现实自动运作,扩展自己业务生产的,或融入市场,否则只有死路一条”。在生活来看,同学们应用Eclipse技术的人并不多,可以说是少之又少,根据调查学校只有120余人现在应用这一技术,在学习Java时老师指导应用Eclipse来编写程序语言,当然都是应用Java的编程项目。当然,Eclipse近几年的不断创新,相信它会走向更高一层。

2.2 Eclipse就业方向

利用Eclipse,可以将高级设计(也许是采用UML)与低级开发工具(如应用试器)结合在一起。Eclipse就业方向跟Java差不多,现在编程人员需求量非常大,根据IDC的数据统计对Java工程师的需求达到全部需求量的60%~70%,产品研发经理,技术经理,软件工程等就业方面非常高薪酬也是人们所理想的范围。对于一个有志于从事软件开发工作的学生来说,最重要的事情是要把面向对象的编程基础打扎实,不断积累经验。不论是学习C语言还是Java,只要用心学习,都能有一个好的发展前程,有了扎实的基础,无论热点转向什么方向,都能很快的适应,融入环境,就像性格好的人,容易接触的人,无论在什么场合都能很快融入一个集体,很快地跟别人打成一片。无论如何,打好基础,为自己做好铺垫。

3 结语

Eclipse有它最吸引的部分和优点,(1)它创新性的图形;(2)它的插件机制;(3)利用它的插件机制开发的众多功能强大的插件。通过这一软件的学习,对Eclipse和Java有了更深层次的了解,也发现了学习中的不足。利用这些优点来开发人们的空间,正是这些技术让计算机技术的发展不断创新,让人们进入一个高科技的时代,当然,软件的开发对新型的社会影响力很大。

参考文献

[1]连洪武.Eclipse的入门到精通.清华大学出版,2007.

[2]赫胥黎.天演论.严复,译.

[3]夏明萍.Eclipse基础与应用.

[4]张跃平,耿祥义.Java2实用教程.清华大学出版社.

eclipse软件 篇3

首先,需要分析8142Pro传输的数据格式,以及各数据位的具体含义,并找出需要的数据位。

1 托利多8142Pro的数据采集端口及发送的数据格式

在8142Pro的实际使用中,最后一位校验和没有使用,所以每个数据包共有17个字节。8142Pro背面板如图1所示。

由图1可知,程序采集的数据来自COM2端口。

8142Pro发送的数据格式如表1

其中各数据位意义如下:

1:ASCII起始符为(02H)。

2:状态字A:小数点位置和分度值因子。B:毛重或净重等信息。C:是否有打印命令。

3:显示重量,毛重或净重(可设置),6位不带符号和小数点的数字。

4:皮重,6位不带符号和小数点的数字。

5:ASCII回车符(0DH)。

6:可选的校验和。

2 设计思路及实现方法

2.1 Java串口通信简介及开发环境设置

Java读写串口要用到的是javax扩展类库comm,其核心是抽象的CommPort类及其两个子类:SerialPort类和ParallePort类。其中,SerialPort类是用于串口通信的类,ParallePort类是用于并行口通信的类。本文只关心SerialPort类,SerialPort类具有以下重要属性和方法:

setSerialPortParams:描述一个RS-232串行通信端口的底层接口,它定义了串口通信所需的最小功能集。通过它,用户可以直接对串口进行读、写及设置工作。

open:打开端口。

close:关闭端口。

getInputStream:获取端口上的输入流对象。

available:是否有数据通过。

read:读取一个字节并将其放到指定字节变量中。

java.comm类库在sun的官网上只提供Linux版本。由于开发的平台是Win32。所以下载的java.comm包解压后必须进行相应配置,配置方法如下:

(1)把javax.comm.properties文件拷贝到Java运行时环境的lib目录中。

(2)把win32com.dll拷贝到C:windowssystem32和C:Program FilesJavajdk1.5.0_12jrebin下。

(3)把comm.jar放到Java运行时环境的lib目录中。

(4)在“环境变量”的CLASSPATH中添加comm.jar,如:%JAVA_HOME%libcomm.jar。

2.2 重量数据的提取

要在缓存中得到有效数据,首先将数据按字节存到一个字节数组变量中,在此字节数组查找需要的有效数据。按照8142Pro字节定义,开始字节为02H,结束字节为0DH,按照ASCII换算为十进制为2和13。

在字节数组中查找readBuffer[i]等于2且readBuffer[i+16]等于13的数据,如果有则存储为一个有效数据。否则,继续返回查找。

2.3 重量数据的转换显示

接收的重量数据是6个字节。每个字节为8位,根据ASCII表,所以应该是0～127。实际接收的数据应该为ASCII表中的48～57,减去48之后即为显示的结果0～9。如果接收的数据大于127,则应再减去128之后按照前述进行处理。

3 主要程序源代码

4 实际应用

eclipse软件 篇4

对于程序员在软件开发、维护等工作中产生的行为的收集和分析对于软件工程有着重要的意义。例如，通过监控程序员的行为可以进行程序员开发行为模式的挖掘、匹配和行为建议。此外，还可以通过监控程序员正在使用的API，主动为其搜索在线资源，并推送相关的搜索结果。当然，也可以用在对不符合组织定义的软件过程的探测以及容易发生bug的软件行为模式的探测上。

然而，无论希望实现以上的哪个功能，都需要以收集到真实完整的程序员开发行为流并将其处理为按照时序排列的结构化事件为前提条件。因此，设计一种全面、客观且忠实地记录程序员的开发过程的工具就显得极为重要，它能提供程序员开发全过程的第一手数据，从而避免了使用调查、访谈或问卷等其他调研方法中不全面，不细致的弊端。

针对以上问题，本文基于Eclipse的可扩展性提出并实现了一种程序员开发行为监控插件。插件由监控模块和数据处理模块组成，通过对Eclipse的插件监听接口和扩展点进行研究和探索，实现了对程序员开发行为完整、自动、无侵扰性地进行细粒度的监控，并对行为发生的时间信息和上下文空间环境进行记录，按照统一的接口格式将监控所获得的这些数据保存到关系数据库。

为了验证所提出方法和工具的有效性，本文设计了一个典型的程序员开发任务轨迹记录的应用案例。该案例基于本文开发的插件扩展，增加了在UI上与程序员的交互，根据程序员的开发行为监控来为程序员实时分析并提供建议，并允许程序员及其团队回看监控记录下的任务开发的每个环节步骤。通过案例实验证明了工具的有效性和易用性，为进一步实现行为信息的深入挖掘和共享打下了基础。

1 相关工作

对于程序员行为的研究，国内外已有不少相关的工作和文献。如Eclipse的顶级项目Mylyn[1,2]就是一种集成在Eclipse中的插件，可以匿名记录程序员的相关行为和上下文并以XML格式保存。Mylyn可以在界面上给出相关的建议，使程序员聚焦在与任务相关的上下文和代码提示上。夏威夷大学开发的Hackystat[3]工具采用“传感器———服务器”模式来进行收集和分析软件开发过程中程序员产生的行为，这些行为通过处理之后会被上传到云端服务器。McKeogh J等人[4]的工作实现了一种Eclipse插件来监控程序员行为，该插件使用SWT提供的监听器来监控在Eclipse编辑器上的浏览、编码等事件。Shi Lei等人[5]的工作提出了一种以方法为粒度的Eclipse过程数据采集框架。罗悦等人[6]的工作提出了一种基于Eclipse的代码错误提示和快速修复的插件，该插件在Eclipse的文档编辑器上添加监听器，当发生代码编辑事件时，插件可以即时地获取被编辑的代码片段，启动代码检查线程来确定这部分代码潜在存在的问题，并结合Quick Fix快速在UI线程中加以提示。

以上工作为本文提供了很多有益的启示，但这些工作在程序员行为监控方面普遍还存在以下这些不足。一是粒度不够细，多数工具的粒度只记录到文件或类;二是对程序员行为监控不够全面，往往只关注于浏览、编码，而忽略了测试、调试等其他行为，这些工具所监控的事件类型较为有限(如Mylyn只使用4个核心监控点，Hackystat也只有6个，每个监控点对应一个监听接口，监控一类特定的事件);三是没有记录并利用相关行为上所附加的时间信息，而时间信息往往反映了程序员的思路，对于后续的行为分析和理解具有重要的意义。为此，本文通过E-clipse这个最流行的跨操作系统开发平台作为程序员行为监控工具的载体，利用其优秀的扩展性和丰富的监听接口设计并实现了程序员行为监控的插件，力争能克服以上的这些问题。

2 方法框架

2.1 插件的总体架构设计

本文插件的总体架构设计和主要的工作原理如图1所示。

图1的外层虚线框标识了本文实现插件的功能边界，该边界由内层虚线框标识的Eclipse平台上的插件部分和保存程序员行为的关系数据库部分组成。插件部分分为以下三个模块:

程序员行为监控模块。利用Eclipse丰富的扩展性和监控接口在Eclipse的环境中部署26个监控点，每个监控点监控一类行为，当这类行为发生时，所绑定的处理方法即被触发。

上下文监控模块。以最细的粒度记录当前行为在Eclipse工作区中所处的包、文件、类和方法等上下文信息。

数据处理模块。将上述监控得来的程序员行为结合其发生时间和上下文环境信息等经过统一的处理，保存到关系数据库中，以便后续对原始行为数据的分析和应用工作。

插件中三个模块的关系及主要工作原理如下:当程序员产生原始开发行为(编码、调试等)时，在Eclipse平台上注入的程序员行为监控模块和上下文监控模块会同时根据各自的监控逻辑捕获该行为的各属性数据和行为所处上下文环境，并把两个监控模块所获得的信息经过数据处理模块进行预处理后形成统一格式的行为数据，保存到关系数据库中，为将来充分分析和挖掘这些信息的后续工作奠定基础。

2.2 插件设计的技术标准

为了真正能使程序员行为监控插件在软件开发的效率和质量上发挥作用，其所监控得来的数据应当符合后续对这些数据预期使用的要求且监控行为应最小程度地对程序员正常开发产生干扰。为此，本文在设计实现之前将先行确定本插件应当达到的技术要求:

完整性:插件应当能够完整地记录程序员从启动Eclipse开始到退出Eclipse为止的所有行为。

自动化:插件的启动、记录、暂停、退出等行为应当由插件本身和其所处的Eclipse环境自主决定。

无侵扰性:插件对于程序员行为的监控应当在后台进行，在获得程序员的授权之后，监控行为本身不应在UI上展现，以使其对程序员的干扰降到最低。

时序性:插件收集的程序员行为应当附带有时间戳的信息，对于可合并的连续事件应当包括开始和结束时间。

原子性:插件收集的程序员行为应当是原子行为，即不可再分割的行为，这些行为可能是由程序员触发的，也可能是自动触发的系统行为。

细粒度:插件收集的程序员行为应当以当前行为所处的可以获得的最细的上下文粒度来进行记录，如类、方法、变量、甚至行号。

非匿名性:插件收集的程序员行为在经过授权之后应当是非匿名性的，既可以用来分析单个程序员的编程习惯个性，也可以将所有的程序员行为放在一起分析共性。

3 工具实现

3.1 行为监控模块

1)对于Eclipse IDE监控机制的探索

本文基于Eclipse插件开发环境PDE(Plug-in Development Environment)进行，通过实现Eclipse各组件提供的监听API和声明各组件提供的扩展点，如UI、Debug、JUnit、SVN等，无缝地使本插件和Eclipse开发环境结合。其中，每个组件提供的监控方法又有所不同，大致来说分为以下两类。

(1)监听器(Listener)机制

这种监控机制的原理如图2所示。Eclipse核心平台及很多插件提供了监听接口，这些监听接口遵循观察者模式，被注册在各类组件上，当该组件监听的特定事件发生时，注册在该组件监听接口会被自动通知，触发监听器中的处理方法。当然，由于不同接口由不同插件提供，其实现方式、注册监听方式都各有不同。本文的工作即是寻找并实现这些监听接口，查阅其API，并将它们注册到相应组件上，并实现相应的处理方法。

一个典型的使用监听器机制进行监控的例子是对于透视图(Perspective)行为的监控。它的监听器接口定义在org.eclipse.ui包中，名为IPerspective Listener，该监听器提供了两个方法，分别为perspective Activated()和perspective Changed()，分别在透视图被激活和被更改时被触发。要使该监听器正常工作，还需要将其注册到相应的组件上。通过查阅IPerspective Listener的API Usage，可知应将监听器注册在通过Platform UI获取到的当前活动窗口上。一旦透视图发生变更或被激活，当前活动窗口就会通知所有注册在其上的透视图监听器，触发相应的方法，再根据3.3节方法将其进保存。

(2)扩展点(Extension Point)机制

这种监控机制的原理如图3所示。扩展点是Eclipse中的一种关键机制，每个插件都可以通过扩展其他插件的扩展点向Eclipse平台添加新功能。这种允许不断改进的松耦合功能被广泛地使用，本文的工作即是寻找对于监控有价值的扩展点，在插件中声明扩展该扩展点并实现相应的方法。

一个典型的使用扩展点机制进行监控的例子是对于控制台输出(Console)内容的监控，控制台是输出运行结果或运行错误的UI组件。对于控制台的扩展点，声明在org.ecipse.debug.ui.consoli Line Trackers，下一步在本插件中声明对该扩展点的扩展，实现相应的类和接口方法，如init(),line Appended()和dispose()，它们分别在控制台被初始化，控制台输出运行结果和控制台被销毁时触发，再根据3.3节中的特定机制在这三个方法中将这些控制台行为进行预处理后保存。

(3)两种监控机制的关系

监听器机制和扩展点机制都是对Eclipse上的程序员行为进行监控和采集的有效手段，两者互有异同。相似之处在于，它们都利用了Eclipse平台的可扩展性，对其现有的开放监听接口(类)进行了实现(继承)扩展。

从图2和图3中可以看出两者的区别。对于监听器机制，当程序员发生操作后，监听器机制会通知行为的接收者(被注入监听器的组件)，再由该组件通知所有注册在其上的监听器，由监听器来处理程序员行为，其本质是利用了Eclipse原生插件提供的接口，通过查阅API后添加相关的监听器及其处理方法至相应组件上，在不改变原有组件的基础上扩展了相关功能;对于扩展点机制，当程序员发生操作后，Eclipse平台会直接通知被扩展的组件，由该组件直接来处理程序员的行为，其本质是以扩展后的新组件替代了原生的Eclipse组件，新组件不对原生组件的功能做任何的修改，只是附加了监控捕获和处理的机制，并不会影响到程序员的正常开发行为。

2)各类监控接口和扩展点的实现

结合上述两种Eclipse程序员行为监控方法，本插件一共实现了26个监听接口的实现和扩展点的扩展，它们被分为8个行为类别，分别从不同的角度对各类行为进行监控。这些监控点就像探针一样，分布在Eclipse的环境的各处，随Eclipse打开而打开，无侵扰地在后台监控着程序员的一举一动。

Eclipse UI行为。负责监控Eclipse的UI事件，如工作区、窗体、页面、透视图以及视图和编辑器等组件的事件。

Eclipse控制行为。负责监控Eclipse环境的非UI事件，如Job任务事件，首选项Preference参数设置更改等事件。

开发行为。负责监控程序员的开发行为，核心是Java代码编辑器行为监控，包括SWT的监控(键盘、鼠标、滚动条、帮助事件等)，文档变更监控，代码自动补全监控、对于菜单栏菜单项和快捷键命令的监控(复制、粘贴、重构、搜索、编译等)、选择行为监控、元素变化监控等其他开发过程中的行为监控。

调试行为。负责监控程序员的调试行为，包括断点管理和调试管理。断点管理负责监控断点的添加、移除、变更断点触发条件等，调试管理负责监控调试行为，如继续、暂停、终止、步进、跳出等调试事件。

测试行为。负责监控程序员的测试行为，依赖JUnit框架，负责对于测试套件和测试用例的启动、结束等事件的监控和流逝时间计算。

版本管理行为。负责监控程序员的版本管理行为，依赖CVS和SVN框架，负责对CVS和SVN的资源库操作和版本管理事件，如对提交、检出等事件的监控。

资源控制行为。负责监控工作空间资源文件增加、变更、删除事件的监控。

日志行为。负责日志事件监控，如Error Log日志监控，控制台输出监控和对Problems视图发生变化时的监控。

结合以上8类事件的监控，本文实现的插件基本可以覆盖几乎所有的程序员常见行为，其完整的结构图和涉及到的监控接口及扩展点如表1所示。

3.2 上下文监控模块

1)程序员行为的上下文

程序员从打开Eclipse进行工作之时起，产生的每一个行为都几乎都会意图施加在一个工作空间的对象上，它可能是一个包，也可能是一个文件、类或方法甚至是某一行代码。为了更加客观地监控程序员的行为，对程序员每个行为的施加对象及其所处的上下文环境和状态都应进行监控。这种上下文信息为程序员的行为后续的分析工作提供更丰富的信息，如果结合时序信息，则可更清楚地分析理清程序员开发过程中的思路。

但并不是所有的行为监控都会提供接口告诉监控模块行为的对象是什么，这就为实时监控每个行为的上下文带来的困难。如图4所示，程序员先“打开”了个A项目，然后点击“编译”按钮编译了A项目。此时，该场景由两个事件组成，一个结构选择事件和一个命令事件。而命令事件监听接口IExecution Listener所监听到的编译事件(Build)并不能告知其编译的到底是哪个项目，对于这样的情况，本文插件会根据前序捕获的“打开”行为来做“根据时序的最近猜测”，即判断编译事件施加的对象即为前序“打开”的A项目。

这种解决思路有一个前提:程序员每进行一个操作之前，都会先切换到该上下文环境中进行。换而言之，只要在每次程序员切换上下文时将其捕获，之后所有的行为都可以认为是在这个上下文之中进行，直到下一次捕获到程序员切换上下文的行为。在大多数情况下，这种前提应当是合理的。基于这种最优猜测的思路，本文提出了三种重要的上下文切换行为:

(1)结构化选择行为

JFace中的结构化选择(IStructured Selection)监听接口继承于org.eclipse.jface.viewers的ISelection接口，指包含元素的选择事件。它们广泛地存在于Eclipse环境中，如包资源管理器(Package Explorer)，大纲视图(Outline)，类型层次(Type Hierarchy)等视图中，当这些视图中的元素发生切换时，结构化选择事件即被触发，此时即可认为程序员接下来要进行的操作应该是要施加在这个文件(或类、方法等，下同)上，在此基础上根据选择的元素进行判断，如果判断为编程元素(如包、文件、类、方法等)，就可以切换上下文来指向当前编程元素。

(2)文字化选择行为

JFace中的文字化选择(IText Selection)监听接口同样继承于org.eclipse.jface.viewers的ISelection接口，指包含文字的选择事件。它们广泛地存在于编辑器浏览代码的过程中，当把文字化选择事件接口注册到相应的代码编辑器的Source Viewer上，且程序员将光标选择了某段代码或将光标定位在该代码编辑器内(长度为0的文字选择事件)时，此时文字化选择事件被触发，可以合理地推断当前光标定位的部分正是程序员正在关注的代码片段。

(3)元素变更行为

元素变更行为(IElement Changed Listener)监听接口定义于JDT的core包，是专门针对Java元素的监听事件。当把元素变更监听器注册到Java Core上后，一旦元素对应的Java模型发生了变化，监听器中的事件即被触发。这种变化常见于代码的编辑、重构等事件中。每当Java模型变更时，插件会自动捕获该Java元素的变化增量(IJava Element Delta)。监控模块对该增量的类型进行判断，如果是增加(Add)或变化(Change)，则将该增量所属的句柄更新为新的上下文，如果是删除(Remove)，则将该增量所属的上一级非空句柄更新为新的上下文。

2)特殊情况的处理

以上提到的思路已经可以监控大部分情况下程序员的行为上下文，但在特殊情况下，程序员的行为并不意图施加在某一个编程元素上，比如修改Eclipse IDE的首选项(Preference)参数设置事件，控制台输出事件，打开“关于Eclipse”事件，以及从Eclipse Market安装新的Eclipse插件事件等等。对于这些行为，本插件不会记录该行为其上下文环境(因为对后续分析没有意义)，而是枚举这些事件，只记录在3.1节中行为的属性值，如首选项参数设置前后的值，并将其保存在数据库中。

3.3 数据处理模块

通过行为监控和上下文监控的模块，插件已经基本可以捕获各种类型的程序员行为，但是由于每个监控都是由不同的插件提供，其接口或扩展的实现方法、提供的数据格式也不尽相同，要想将这些行为数据真正用于后续的分析和利用，还需要将这些数据经过统一的预处理后保存到数据库中去。

数据处理是承上启下的模块，它既与监控收集得来的数据契合，也为后续数据的利用提供统一的接口和平台。和监控模块一样，数据处理模块也是静默地在后台调用异步线程运行，而不对程序员的正常开发造成侵扰。它将每个程序员行为结合发生的时间信息和所处的上下文空间信息一并转化为统一的数据格式，存储到数据库中。数据库的存储格式如表2所示。

4 案例研究

4.1 场景定义

为了验证本插件的有效性和易用性，在完成上述工作后，本文在已实现的插件基础上扩展了一个典型的实用案例场景研究:任务轨迹记录。场景的典型用例是:程序员可把即将进行的一项工作预定义为一项任务，并点击工具栏上的“开始”按钮启动录制任务的开发行为轨迹。在开发过程中的所有行为都将由插件保存，视图“上下文推荐”会动态地更新所有涉及和该任务有关的文件、类、方法等，这些元素根据其被编辑的时长长短显示在上下文视图中。任务结束时，再点击工具栏上的“结束”按钮结束录制行为轨迹。这些轨迹可以允许程序员通过视图“行为轨迹”回看，并上传到SVN上。由于本插件对于程序员行为监控的非匿名性，当团队中任何一名成员希望查看这个功能是怎样被实现时，都可以从SVN上调出这个任务的行为轨迹记录，查看这个任务详细的每个步骤。

4.2 场景实现

本场景在已实现的监控插件基础上，又扩展了UI的相应功能，使监控插件不再仅限于后台静默运行，而加入了和用户的前台交互，通过分析监控插件得来的程序员行为信息即时地为其提供相关的建议。具体体现在在Eclipse UI上增加了两个视图:“上下文推荐”和“行为轨迹”，并在工具栏上增加了两个命令按钮:“开始”和“结束”。

无论任务是否开始，程序员行为监控插件始终都会根据3.3节中的逻辑将每个开发行为保存。而当任务一旦开始，插件就会自动在数据库“任务”表中建立一条记录，记载该任务开始的时间，并在数据库“任务与上下文关联”表里开始记录涉及该任务的上下文及其之间的关联，根据每个上下文元素编辑活动的时间计算其与该任务的关联度，动态地根据计算结果在“上下文推荐”视图中做出相关的推荐，如图5所示。当任务结束时，该记录便会记载任务结束的时间。如果程序员想要再次将这些记录轨迹调出，可根据“任务”表中记载的任务的起始时间和终止时间来抓取3.3节中数据库记录下来的相应区间的行为数据，并在“行为轨迹”视图中用表格形式展示，如图6所示。

4.3 场景分析和评价

图5展示了一个任务“添加调试事件监控特性”的上下文推荐截图，通过给任务的开始和结束打上时间戳，可以客观地将程序员整个任务的行为序列按时间顺序记录下来，使程序员可以更加聚焦在与这个任务相关的包、类、文件上。同Mylyn等成熟插件相比，本插件加入了更多的时间信息，利用这些事件信息，可以根据每个元素编辑时长为程序员提供时间相关度更高的建议。

图6展示了一个任务“添加JUnit Test监控特性”的部分行为轨迹截图，每一行记录都是一条原始行为的轨迹。该任务共记录了173个程序员主动触发事件和824个非主动触发事件。该轨迹反映了程序员完成该任务的思路:开始任务后，程序员首先按下了F1键进行了Help查阅API Usage，然后建立了继承自TestRun Listener的监控类Junit Test Listener，随后进行了编码，重载了父类的五个方法，对五个方法的公共部分进行了重构提取，随即在Junit Core上注册了该监听器，并将其注册到插件类Eclipse MonitorPlugin的初始化代码中，最后进行了断点的设置、调试运行后结束任务。

通过回看程序员的任务轨迹，可以清晰地掌握他们开发的思路，学习他们是如何从架构设计到具体实现、了解程序员何时进行了版本管理、判断断点设置的条件与位置、学习重构的策略甚至是使用快捷键的技巧。另一方面，可以对行为进行统计意义上的分析，如分析程序员在某个任务中浏览、编码、调试、查阅帮助的时间比例，或利用数据挖掘的技术来挖掘程序员的行为模式等。

案例场景对团队开发也有很强的现实意义。对于团队合作来说，领导者可以通过回看任务轨迹来评判任务工作量，进而评判程序员在开发的过程中是否遵循了预先定义的软件过程。未来还可以对本场景进行扩展，建立在线的云任务库。每个程序员在完成某个特定任务之后，都可以选择将当前任务的开发过程轨迹记录上传到库中，待后续的程序员要想再进行类似的开发时，就可以直接在任务库中搜索之前已完成的任务。与传统的学习开源软件直接提供的源代码相比，这样的云任务库可以利用记录下来的时序信息更多反映程序员当时的思路，为后人提供更多有益的软件实践，避免之前走过的弯路。

5 结语

本文通过对Eclipse IDE中的监控机制的研究，在前人工作的基础上，调研了相关的Eclipse开放的监听接口和扩展点，并加以实现和扩展，将不同的插件所提供的监听接口和扩展点监控得到的程序员各类事件进行统一数据接口的整合，通过异步线程保存到数据库。在此基础上，本文设计了一个任务轨迹记录的案例分析，通过场景实例和分析评价有效地证明了本插件的有效性和易用性。

本文所提出和实现的插件还仍有一定的局限性。到目前为止，插件的主体部分还主要局限在后台静默捕获程序员的行为，和前台的交互相对还不够充分和成熟。在今后的工作中，将把插件更智能地与程序员交互运行，如根据监测程序员正在使用的API，智能搜索和该API相关的在线资源后推送，或是根据优秀的行为模式库来监测当前程序员的开发是否符合最优代码实践或是否有任何bug的隐患;可视化也是未来发展的方向，以类似于UML顺序图的形式展现出来，更加方便理解。

摘要：程序员在软件开发过程所产生的浏览、编码、调试和测试等行为可以转化为带有时序信息的行为数据,为提高软件质量和开发效率提供有价值的信息。针对如何全面、客观地记录程序员开发行为数据的问题,基于Eclipse的可扩展性提出并实现了一种程序员开发行为监控插件。该插件可以对软件生产中程序员的行为及其上下文进行实时监控,将原始行为预处理后转化为统一格式的行为数据并保存到数据库中。在此基础上,设计了一个典型的程序员开发任务轨迹记录的应用案例。该应用允许程序员定义任务、记录任务行为轨迹、回看轨迹,并允许整个开发团队共享任务行为信息。案例研究结果验证了该插件的有效性和易用性,为进一步实现行为信息的深入挖掘和共享打下了基础。

关键词：Eclipse插件,行为监控,上下文监控

参考文献

[1]StaM.Origo Mylyn plug-in and advanced issue management[D].Swiss Federal Institute of Technology Zurich,2008-2009.

[2]Eclipse Mylyn Project[EB/OL].2013-12-1.http://www.eclipse.org/mylyn/.

[3]Johnson P M,Hongbing K,Agustim J M,et al.Practical automated process and product metric collection and analysis in a classroom setting:Lessons learned from Hackystat-UH[C]//Empirical Software Engineering,2004.ISESE’04.Proceedings.2004 International Symposium on,IEEE,2004:136-144.

[4]McK eogh J,Exton C.Eclipse plug-in to monitor the programmer behaviour[C]//Proceedings of the 2004 OOPSLA workshop on eclipse technology eX change,ACM,2004:93-97.

[5]Shi L.Eclipse IDE Software Process Data Collection Technique[R].Beijing:Software Engineering Institute of Peking University,2009.

[6]罗悦,刘辉.基于监控与Quick Fix的代码错误提示和修复方法[OL].[2014-02-10].中国科技论文在线.http://www.paper.edu.cn/releasepaper/content/201402-120.

[7]Murphy C,Kaiser G,Loveland K,et al.Retina:helping students and instructors based on observed programming activities[C]//ACM SIGCSE Bulletin,ACM,2009:178-182.

[8]Majid I,Rabillard M P.NaC IN:an Eclipse plug-in for program navigation-based concern inference[C]//Proceedings of the 2005 OOPSLA workshop on Eclipse technology eX change,ACM,2005:70-74.