编者按:为了帮助集成开发环境(IDE)克服目前的局限性,业界厂商合作创建了Eclipse平台。Eclipse允许在同一IDE中集成来自不同供应商的工具,并实现了工具之间的互操作性,从而显著改变了项目工作流程,使开发者可以专注在实际的嵌入式目标上。
集成开发环境(IDE)经常将其应用范围限定在“开发、构建和调试”的周期之中。其它开发任务,如系统设计与分析,必须由主IDE以外的专用工具来执行。这种双重标准,即紧密集成一些工具、又冷落其它工具的做法导致开发环境出现不必要的分裂,而且对生产力造成负面影响。即使在单个项目中,开发者都必须采用一种IDE来设计嵌入式板卡,然后在另一种IDE中编写C语言驱动程序,又在另一种IDE中编写Java应用程序,再在另一种IDE中执行系统分析。这样的频繁转换无疑将使开发者精疲力竭。
一些供应商试图将他们的IDE扩展到上述周期的“三步曲”之外,但没有取得完全成功。问题在于成本。第三方工具提供商发现把他们的产品移植到每一种IDE中所需的费用实在过于昂贵。使事态更复杂化的是,很少IDE能提供对用户接口的控制,以及完全实现“工具至工具”集成所需的用户体验。这些因素加在一起,使得很难或几乎不可能在单个环境中完成所有开发任务。
为克服这些障碍,工具提供商们合作创建了一种用于工具集成的开放环境——Eclipse平台。Eclipse可提供一种公共集成机制,允许开发者只编写一次工具,即能在几乎所有类型的开发环境中应用它。其结果是,工具供应商不必浪费宝贵的资源来支持多种IDE,相反,他们可以集中精力为自己的特定工具增添附加价值。此外,Eclipse允许来自不同供应商的工具集成到同一环境中,在许多情况下还能扩展彼此的能力。因此,即使调试器和应用剖析器(profiler)等传统工具都能洞察更宽泛的问题,如复杂的分布式行为。
这种扩展能力在QNX软件系统公司采用Eclipse框架的过程中发挥了关键作用。作为一家RTOS供应商,QNX已经专门为嵌入式系统开发打造一套核心工具,包括编译器和调试器等。利用Eclipse的可扩展插件架构,QNX 的软件工程师发现很容易让这些工具适应此框架,从而允许它们与第三方Eclipse工具(如源代码控制系统)进行互操作。
此外,Eclipse允许QNX公司把开发重点从“代码”转移到实际的嵌入式目标上。特别地,它使QNX的工程师可以开发远程文件系统浏览器、系统剖析器以及用于目标控制的插件等非传统开发工具,从而为嵌入式开发者提供至关重要的目标信息和实时分析。它还使以前孤立或不可扩展的工具能够在无需人工干预的条件下共享彼此的数据。这种集成改善了工作流程,进一步允许开发者集中精力去理解目标系统的行为。
Eclipse框架的这种灵活性来源于其扩展点。它们是在XML中定义的已知接口,并充当插件的耦合点。扩展点的范围包括从用在常规表述过滤器中的简单字符串,到一个Java类的描述。任何Eclipse插件定义的扩展点都能够被其它插件使用,反之,任何Eclipse插件也可以遵从其它插件定义的扩展点。除了解由扩展点定义的接口外,插件不知道它们通过扩展点提供的服务将如何被使用。
为了理解这种架构如何使IDE变得更“专注目标”,我们来看看QNX公司为了分析堆分配(heap allocation)及总存储器利用率而开发的一种插件。该插件连着一个扩展点,当Eclipse框架上任何进程被启动时,它会运行监视工具。当进程运行在目标上时如果发生任何类型的存储器错误,那么插件将记录下错误,然后搜索可用的调试扩展点,以便与发生错误的进程建立远程调试对话。插件无需知道被启动的进程的任何具体细节或者无需懂得如何把调试器与目标相连,就能完成这些操作。
Eclipse的扩展点模型使工具之间实现了互操作,这为设计者提供了许多其它机会去理解目标行为。例如,QNX的“系统剖析器”是一种基于Eclipse的插件,它连着一个工具内核以监视系统级活动。如果系统剖析器检测到一个与低性能有关的典型事件序列(如一个进程在短时间内接收到几条消息),那么它可能会采用由应用级剖析器定义的扩展点来触发一次应用剖析器对话。反之,应用剖析器也能充当触发器。
例如,如果一个线程的响应时间超过它定义的边界条件,那么应用剖析器可以利用由系统剖析器定义的扩展点来触发一次系统剖析对话,以观察系统级行为。通过综合采用这两种传统上独立的工具,设计者能迅速确定导致低性能的根本原因。
为了说明Eclipse架构如何实现一种更“专注目标”的设计方法,我们还可以考察其它例子,如当利用多种语言来开发嵌入式系统时设计者能从中受益几何。一个系统可以采用高级语言来设计,如UML或SDL,这两种语言都代表充当抽象实体的器件。每个器件会被部属在某种设备上,而在设计中,器件会选用最适合对应设备的语言来实现。例如,嵌入式微控制器可能采用汇编语言,中级线卡处理器可能采用C或C++,而更为重要的主控器件可能采用Java。
很少有工具环境允许你将这三种器件视作一个实体；更没有环境允许你采用单一工具对整个系统进行调试。相反,你必须分别检查每个器件,即使它们能像由一种高级语言定义的完整系统一样进行工作和通信。
另一方面,利用Eclipse,你可以将高级设计(也许是采用UML)与低级开发工具(如应用调试器等)结合在一起。如果这些互相补充的独立工具采用Eclipse扩展点彼此连接,那么当你用调试器逐一检查应用时,UML对话框可以突出显示你正在关注的器件。事实上,由于Eclipse并不了解开发语言,所以无论Java语言调试器、C/C++调试器还是汇编调试器都是有效的,并可以在相同的框架内同时瞄准不同的进程或节点。
除此之外,还有其它例子可以说明Eclipse如何借助其插件架构和扩展点API影响开发工具的类型,以及这些工具如何进行互操作。例如,硬件调试器(如ICE及JTAG等)与应用调试器(C、C++和Java等)可以共享一个公共的调试器用户接口,但提供针对各自配置的特定实现,而它们的配置是通过一个已定义的调试器扩展点进行调试的结果。这种通过扩展点实现的紧密集成使开发者很容易从一种任务(如对嵌入式设备的启动代码进行逐步调试)转换到另一种任务上(如调试运行在嵌入式设备上的应用)。
通过在相同的开发环境内集成这些及其它工具,基于Eclipse的IDE能显著改变项目工作流程。开发者不再需要在一种环境中执行传统的“开发、构建、调试”周期,而可以将注意力转移到检查目标的实际操作上。他们只需使用一种环境来开发代码,并根据提供给分析工具的即时反馈来调整目标系统。这些反馈使设计者可以更深入地洞察软件组件在“真实世界”中的行为,无论目标是简单的独立设备,还是由众多节点组成的大型分布式系统。
Eclipse是一种可扩展的开放源代码IDE。2001年11月,IBM公司捐出价值4,000万美元的源代码组建了Eclipse联盟,并由该联盟负责这种工具的后续开发。Eclipse的最大特点是它能接受由Java开发者自己编写的开放源代码插件,这类似于微软公司的Visual Studio和Sun微系统公司的NetBeans平台。Eclipse为工具开发商提供了更好的灵活性,使他们能更好地控制自己的软件技术。Eclipse联盟()已经宣布将在2004年中期发布其3.0版软件。
作者:Thomas Fletcher
工具开发部经理
QNX软件系统公司
京公网安备 11011202001138号
