对电子战软件中组件式定时器的开发分析

2020-02-02程焱明

电子技术与软件工程 2020年15期

程焱明

（中国船舶重工集团公司第七二三研究所江苏省扬州市 225011）

原生定时器（Windows 系统）、基于线程的定时器、面向对象的定时器均属于传统的定时器模型，但这类定时器很容易在应用中出现定时器失效、程序结构混乱、软件可读性下降等问题。为保证定时器更好服务于电子战指控系统开发，正是本文围绕该课题开展具体研究的原因所在。

1 电子战软件中的传统定时器模型

电子战软件中的传统定时器模型种类多样，代表性较高的可细分为三类，包括原生定时器、基于线程的定时器、面向对象的定时器，这类定时器存在的优势和不足必须得到重点关注。

1.1 原生定时器

Windows 系统存在原生定时器，该定时器看起来较为简单，如在指定的窗口进行定时器回调操作注册，做好间隔时间设定，并最终响应系统WM-TIMER 消息即可，通常情况下原生定时器可满足相关需要。但对于电子战指控系统来说，其本身对实时性存在较强要求，这种情况下原生定时器的应用很容易引发意想不到的问题。原生定时器的回调处理基于响应WM-TIMER 消息实现，但由于WM-TIMER 消息处理在Windows 系统中的优先级较低，在其它窗口消息存在于应用程序消息队列中时，WM-TIMER 消息调度会被操作系统忽视，系统在指定时刻点上未能及时执行处理回调的情况很容易出现。对于应用程序不停接收通信链路数据的情况，由于系统需要对收到的数据进行迅速处理并不停响应网络消息，此时定时器回调操作将没有机会执行，原生定时器会因此失效[1]。

1.2 基于线程的定时器

为突破原生定时器性能瓶颈，基于多线程技术的定时器模型探索长期受到重视，通过开辟新的工作者线程独立于主线程外，基于系统API 应用程序接口，新线程内部即可实现手工定时计数，在指定的间隔时间达到后，实际的定时回调操作即可由收到通知的外部主线程完成。基于线程的定时器在理论上可行的，在具体的实践应用中也取得了不俗效果。但值得注意的是，基于线程的定时器涉及线程同步、线程通信、线程创建等多线程编程技术，死锁情况也很容易出现于线程同步过程中，这对开发人员提出了较高挑战。对于需要使用多个定时器的电子战软件开发来说，如无法科学组织各定时器，将导致非常混乱的程序结构出现，更为复杂的控制流程会直接影响软件开发[2]。

1.3 面向对象的定时器

图1：组件式定时器的内部结构

为更好服务于软件开发，面向对象技术也被引入定时器领域，由此封装基于线程的定时器，C++的封装类得以产生，系统的健壮性可大幅提升。但对于规模不断变大的软件来说，愈加复杂的流程使得简单封装无法满足实际需要。对于具备“对实现的封装”特点的C++语言来说，与具体实现相关的代码大量存在于封装类中，同时与业务逻辑的联系较少。大量零散的封装类混杂于软件结构中，软件可读性因此下降。此外，其他语言中C++语言编写的封装类无法直接影响，多语言协同开发因此受到的影响必须得到重视，对于整个电子战软件来说，某些部分存在性能上较高指标，具体实现需使用C/C++等编译性的语言，也有一些部分需要华丽的用户界面、较快的开发速度且对性能要求较低，具体实现可采用ASP、VB 等存在较高灵活性的解释性语言。在集成软件过程中，最终软件产品需结合各方面形成，考虑到不同的开发语言中定时器等具有共性的功能模块需设法集成，由此引发的定时器跨语言问题必须得到重视。

2 电子战软件中组件式定时器开发及应用

2.1 组件式软件开发

为弥补电子战软件中的传统定时器模型存在的缺陷，本文引入了组件式开发技术，通过对基于线程的定时器进行封装即可同时提供跨语言解决方案。需要将庞大、单独、复杂的应用程序划分为多个模块，并应用组件化程序设计思想，此时模块不能被简单的视作代码集合，而是真正成为自给自足的组件，同一台机器上可允许这类组件，广域网、局域网、Internet 的不同机器上也可允许这类组件。分析理性化的组件系统可以发现，组件内部的结构无需被用户了解，所需工作可通过配置组件完成。为实现组件化软件开发，CORBA公共对象请求代理体系结构由OMG 对象管理组织提出，UNIX 操作系统属于该结构的主要应用平台。微软在Windows 平台上提出了COM 标准组件对象模型，组件之间交互的规范由此明确，实现交互的环境也同时提供。对于不依赖于任何特定语言的组件对象之间交互来说，COM 可作为一种标准用于不同语言协作开发。

深入分析可以发现，组件式软件开发具备四方面优势，包括容易替换、能够较好适应需求变化、可实现二进制代码重用、较好服务于并行开发。所谓容易替换，指的是组件式开发技术可将庞大复杂的企业级应用系统划分为多个组件模块，在版本升级和系统修改时，可对相应组件进行替换或修改，其他部分不会受到影响；基于适应需求变化进行分析可以发现，不明确的业务需求在软件开发中较为常见，新的需求会在软件配置及开发过程中不断出现，而在组件式开发技术支持下，通过在少数几个组件中存放业务规则，即可通过重建并发布新组件或修改相关组件更好适应业务规则，局部更新可同时在局部中局限出错机会，软件测试和调试的便利性将大幅提升；分析可实现二进制代码重用可以发现，二进制级别上的重用和集成可通过组件式开发实现，即一次编写代码的多处使用，多个团队使用不同开发工具的协同工作可更好完成。如高实时性的算法分析组件由C++开发团队开发，使用该组件的VB 开发团队无需进行组件对应VB 版本的针对性开发，而是可以在同一个操作系统平台下直接使用，这是由于组件为二进制级别重用的；分析较好服务于并行开发可以发现，对于由许多组件构成的大应用系统来发，可同时进行这类组件的开发。在具体开发过程中，需划分业务逻辑为多个不同的组件，随后进行接口的针对性设计，即可由开发团队并行开发，各个组件可最终在系统集成阶段顺利集成[3]。

2.2 组件式定时器的设计

图1为组件式定时器的内部结构，具体设计基于COM 开展，定时器的内部由COM 技术封装，二进制级的代码重用的支持也同时实现。整个组件对外导出接口4 个，即IUnknown、ISyncNotify、IAsyncNotify、IDispatch。

2.2.1 IUnknown 接口

分析IUnknown 接口可以发现，每个COM 组件均必须导出该接口，其他所有接口的继承也需要基于IUnknown 接口实现，可见所有COM 接口的根为IUnknown 接口。IUnknown 接口共存在函数3 个，提供接口查询和组件的生存期控制两个重要功能。外部用户对组件的使用情况可基于Release 和Ad-dRef 确定，具体需要对组件内部的成员变量m_cRef 进行操作，组件生存期控制可由此实现。如存在减为0 的该变量，则说明组件没有其它用户使用，自身所占据的系统资源即可由组件自动释放，包括系统句柄等、内存、数据库等。在实例化1 个组件出来后，外部用户开始可得到1 个IUnknown 接口，为满足实际应用需要，接口查询需采用QueryInterface。如接口能够由组件支持，1 个结果接口指针会随之返回，组件功能可由用户进一步调用。

2.2.2 ISyncNotify 和IAsyncNotify 接口

分析ISyncNotify 和IAsyncNotify 接口可以发现，具体的定时器逻辑由两个接口实现。为方便使用并保持一致，采用相同结构设计2 个接口，因此对于用户存在一致的调用方式，具体差异存在于实现的功能上。ISyncNotify 接口的定时器通知采用同步的方式，IAsyncNotify 接口的定时器通知采用异步方式。基于调用约定进行操作，事件的通知消息即可在指定的定时器间隔时刻点获得。RegisterNotify 为请求组件注册新的定时器通知事件，以ms 为单位的定时器间隔时间由interval 给出，umsg、hwnd 分别为通知消息和通知窗口。在注册成功后，定时器通知的句柄为pid 接收的1 个ID。参数ID、UnregisterNotify 分别为定时器通知句柄、请求组件删除指定的定时器通知事件。具体的接口实现需开辟工作者线程，每个同步定时器均需要开辟1 个，定时器事件通知可由此实现，整个系统中其它定时器工作因一个定时器事件处理阻塞而出现异常也可同时规避。对于不涉及到阻塞问题的异步定时器来说，考虑到其需要负责一个通知消息的简单投递，因此公共工作者线程的开辟极为关键。需充分考虑事件通知、定时计数、线程同步、优先级等复杂的控制流程，在COM组件的封装下，使用便利性提升可同时实现。

2.2.3 IDispatch 接口

IDispatch 接口属于支持自动化的核心接口，该接口在1 个数组中集中所有成员函数的入口地址，并在内部维护1 个映射表。根据序号索引，外部用户可快速找到需要的函数并进行相应功能执行。对于HTML、ASP、VB 等解释性语言，以及Excel、Word 等包公软件提供的“宏”功能，均可对组件自动化接口进行较好访问。IDispatch 接口提供的函数可用于组件支持的所有类型库信息查询，组件浏览器枚举访问的便利性可大幅提升。此外，基于函数名称查询索引编号、具体的函数调用执行、远程计算机上组件接口函数调用也可基于IDispatch 接口实现，由此需要调用的函数名称可在运行时动态指定，需要调用的函数不必事先明确，动态绑定可由此完成。IDispatch 接口在组件式定时器中的实现可较好服务于使用ASP、VB 进行软件开发的团队，协同开发可由此更为便利开展。