基于城市軌道列車自動監控系統的某程序移植

周伯尼

（通號城市軌道交通技術有限公司，北京 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

程序的穩定性影響著軟件項目的最終投入，在移植過程中，始終將穩定性作為首要考慮的目標，文中提到的策略支撐本宗旨，但這些策略不僅是在移植之前面面俱到的，更多的是移植過程中不斷總結，逐步完善的。望本文對分析和解決該類問題的人士有一定的啟發。