基于城市轨道列车自动监控系统的某程序移植

周伯尼

（通号城市轨道交通技术有限公司，北京 100070)

1 移植目的

城市轨道列车自动监控系统是用于城市交通系统的一种稳定的自动化控制系统，随着每条线路的长度不断延伸，行车间隔持续缩小，以及采集列车的信息类型持续增长，该系统处理的数据量不断增长，同时随着运营更加精细化，原有单一功能、单一处理能力的程序，可能面临的是几倍甚至几十倍的负载压力，而且还有很多需求是由单一控制端，变成分段控制，甚至是协同控制，程序处理难度在不断增大。

按照新的要求进行软件功能的更改是必要的，但将承担这些功能的程序推倒重来可能会遇到很多问题：原有程序是经过了多轮设计最终实现；原有程序针对原设计目标的功能是丰富完善的，只是处理新的问题较困难；原有程序在现场环境经过了长期运行，重新制作的程序可能短期无法实现原有的部分功能，或者是无法达到原有的性能，或者是使用难度增大，难以到达原有的便利性。

因此在尊重原有程序的基础上，按照新的设计目标进行结构的移植，可以尽量利用原有成果，降低投入风险，节约开发时间，对实际项目有着很积极的意义。

2 修改策略

移植的优势很大，但存在的挑战也很多，以下列出本次程序移植过程中总结的策略，在案例中，会按照实际经验，列出相关的策略。

1）原有程序涵盖的需求较多，移植者理解可能不够全面

相关需求、概要、详细设计的人员和移植者往往不是同一人或同一团队，移植者难以全面理解所有细节。针对该问题，有3 个策略：一是尽可能的利用原有组件的组成部分，减少修改范围；二是和了解原有开发过程的人员进行沟通；三是期望相关的使用人员进行测试验证。

2）原有程序最初的设计调整可能经过多次迭代，移植者理解可能不够深入

在逆向理解的过程中，会忽视原先设计的前提条件和影响因素，导致人们通常理解的改造难度往往偏小。针对该问题，有3 个策略：一是尽可能的遵照原有组件的设计，降低出错的可能；二是寻找原设计的关键，集中力量新增或改造设计；三是通过原程序不断的接触会增加理解的深度，迭代进行设计和移植。

3）原有程序的具体实现限制了移植者

原有结构和处理方式会导致移植者需要按照大量旧有方式进行。针对该问题，有两个策略：一是尽可能将新增的内容符合原有设计思路；二是确定移植范围，只移植关键内容，保留较多的原实现。

4）原有程序在系统内的影响限制了移植者的处理手段

原有程序和系统内其他程序有交互，同时可能和系统外部接口有交互，这些约束了移植者，必须沿用较多的外部与内部的协议。针对该问题，有两个策略：一是按原有内容原有办法，新增内容新办法；二是新增内容尽量使用利用系统内其他协议。

3 案例解析

3.1 起因

原程序部署在具备Windows 操作系统的终端机上，通过处理获得的数据，将结果保存至数据库，并通知系统内其他软件去数据库取结果。原程序重新启动后，通过数据库进行同步。具体业务处理上，分为实时业务和计划业务，实时业务立即生效，计划业务在未来某日生效。如图1 所示。

图1 原程序组件的部分运行流程Fig.1 Partial operational procedure of original program components

原程序在实时业务中存在设计不足，对于不同终端上的同型程序之间的数据交互实现有问题：某个时刻不同终端上的软件同时需要完成数据同步，此时由于不同终端的时钟存在差异，前后时序每次都可能不同，无法保证交互的处理结果的一致性，也给系统内其他软件的使用带来困扰。而且处于终端上的程序重启或网络重连次数较多，带来的数据同步问题频率较高。从系统安全上，实时业务需要在数据库离线时正常工作足够的时间，但原程序和其他软件的处理方式是利用数据库进行同步的。

原软件的计划业务会在未来某日转变成实时业务生效，未转变成实时任务时，其修改和编辑和其他同类软件无关，没有出现异常情况。

面对这样的情况，需要考虑重新进行该程序的设计与实现，但原程序拥有大量人工交互的内容，如实时数据更新、异常状态提示、自动条目生成、全人工条目生成、计划输入条件浏览、人工设置可用资源、可用资源实时统计等，这些内容涵盖的具体实现非常的细致，同时还存在很多业务处理，如计划数据转为实时数据、实时数据基础变更、变化实时数据发出、变化实时数据接收等，如图2 所示。

图2 更改前后的程序内的任务组成Fig.2 Task composition within program components before and after modification

由于这些内容的操作方式已经得到使用者的认可，同时测试方式和方法较为固定，如果将这类内容重新制作一次，未必可以保证比原软件更有优势，还可能引入新的故障。

因此尽量保留原软件的内容，特别是计划业务，由于交互简单，其工作状态一直较为稳定，无需进行更改。根据这些特点确定的移植方向是：针对原程序主要问题，将实时业务统一由Linux 服务端程序完成，包括计划数据转为实时数据、实时数据基础变更、变化实时数据发出、变化实时数据接收，原程序的人工交互全部保留，成为新的终端软件。通过将原程序中变化实时数据发出、变化实时数据接收的通信方向重新设置，实现终端向服务端查询、编辑和修改。服务端程序作为唯一中心，存储与管理实时业务的数据，可支持多个终端数据分段的处理，并可保证离开数据库后维持工作一段时间。如图3 所示。

图3 更改后终端服务端程序组件的部分运行流程Fig.3 Partial operational procedure of terminal service program components after modification

3.2 目标

按照定下的方向分解出多个目标，如表1 所示。

表1 移植工作的目标Tab. 1 Object of transplantation works

3.3 步骤

达成详细目标需要不断的持续开发，包括步骤与详述，列出具体工作与时间花费，每个步骤体现上文提到的不同的策略，如表2 所示，策略对应的序号是本文第二节内容。

4 总结

随着工程需要而不断调整的软件结构，是很多软件项目可能遇到的问题，本文所叙述的是一次交付实际工程的程序移植的过程，偏重于讲述移植过程中分析与设计的考虑。该程序成为城市轨道列车自动监控系统并正式交付已经超过一年时间，没有再出现问题，取得了较理想的效果。未来可能将服务端改造成可支持多终端对同一段数据的协同处理。

表2 移植工作的步骤Tab. 2 Steps of transplantation works

程序的稳定性影响着软件项目的最终投入，在移植过程中，始终将稳定性作为首要考虑的目标，文中提到的策略支撑本宗旨，但这些策略不仅是在移植之前面面俱到的，更多的是移植过程中不断总结，逐步完善的。望本文对分析和解决该类问题的人士有一定的启发。