周伯尼

（通號(hào)城市軌道交通技術(shù)有限公司，北京 100070)

1 移植目的

城市軌道列車自動(dòng)監(jiān)控系統(tǒng)是用于城市交通系統(tǒng)的一種穩(wěn)定的自動(dòng)化控制系統(tǒng)，隨著每條線路的長度不斷延伸，行車間隔持續(xù)縮小，以及采集列車的信息類型持續(xù)增長，該系統(tǒng)處理的數(shù)據(jù)量不斷增長，同時(shí)隨著運(yùn)營更加精細(xì)化，原有單一功能、單一處理能力的程序，可能面臨的是幾倍甚至幾十倍的負(fù)載壓力，而且還有很多需求是由單一控制端，變成分段控制，甚至是協(xié)同控制，程序處理難度在不斷增大。

按照新的要求進(jìn)行軟件功能的更改是必要的，但將承擔(dān)這些功能的程序推倒重來可能會(huì)遇到很多問題：原有程序是經(jīng)過了多輪設(shè)計(jì)最終實(shí)現(xiàn)；原有程序針對(duì)原設(shè)計(jì)目標(biāo)的功能是豐富完善的，只是處理新的問題較困難；原有程序在現(xiàn)場環(huán)境經(jīng)過了長期運(yùn)行，重新制作的程序可能短期無法實(shí)現(xiàn)原有的部分功能，或者是無法達(dá)到原有的性能，或者是使用難度增大，難以到達(dá)原有的便利性。

因此在尊重原有程序的基礎(chǔ)上，按照新的設(shè)計(jì)目標(biāo)進(jìn)行結(jié)構(gòu)的移植，可以盡量利用原有成果，降低投入風(fēng)險(xiǎn)，節(jié)約開發(fā)時(shí)間，對(duì)實(shí)際項(xiàng)目有著很積極的意義。

2 修改策略

移植的優(yōu)勢很大，但存在的挑戰(zhàn)也很多，以下列出本次程序移植過程中總結(jié)的策略，在案例中，會(huì)按照實(shí)際經(jīng)驗(yàn)，列出相關(guān)的策略。

1）原有程序涵蓋的需求較多，移植者理解可能不夠全面

相關(guān)需求、概要、詳細(xì)設(shè)計(jì)的人員和移植者往往不是同一人或同一團(tuán)隊(duì)，移植者難以全面理解所有細(xì)節(jié)。針對(duì)該問題，有3 個(gè)策略：一是盡可能的利用原有組件的組成部分，減少修改范圍；二是和了解原有開發(fā)過程的人員進(jìn)行溝通；三是期望相關(guān)的使用人員進(jìn)行測試驗(yàn)證。

2）原有程序最初的設(shè)計(jì)調(diào)整可能經(jīng)過多次迭代，移植者理解可能不夠深入

在逆向理解的過程中，會(huì)忽視原先設(shè)計(jì)的前提條件和影響因素，導(dǎo)致人們通常理解的改造難度往往偏小。針對(duì)該問題，有3 個(gè)策略：一是盡可能的遵照原有組件的設(shè)計(jì)，降低出錯(cuò)的可能；二是尋找原設(shè)計(jì)的關(guān)鍵，集中力量新增或改造設(shè)計(jì)；三是通過原程序不斷的接觸會(huì)增加理解的深度，迭代進(jìn)行設(shè)計(jì)和移植。

3）原有程序的具體實(shí)現(xiàn)限制了移植者

原有結(jié)構(gòu)和處理方式會(huì)導(dǎo)致移植者需要按照大量舊有方式進(jìn)行。針對(duì)該問題，有兩個(gè)策略：一是盡可能將新增的內(nèi)容符合原有設(shè)計(jì)思路；二是確定移植范圍，只移植關(guān)鍵內(nèi)容，保留較多的原實(shí)現(xiàn)。

4）原有程序在系統(tǒng)內(nèi)的影響限制了移植者的處理手段

原有程序和系統(tǒng)內(nèi)其他程序有交互，同時(shí)可能和系統(tǒng)外部接口有交互，這些約束了移植者，必須沿用較多的外部與內(nèi)部的協(xié)議。針對(duì)該問題，有兩個(gè)策略：一是按原有內(nèi)容原有辦法，新增內(nèi)容新辦法；二是新增內(nèi)容盡量使用利用系統(tǒng)內(nèi)其他協(xié)議。

3 案例解析

3.1 起因

原程序部署在具備Windows 操作系統(tǒng)的終端機(jī)上，通過處理獲得的數(shù)據(jù)，將結(jié)果保存至數(shù)據(jù)庫，并通知系統(tǒng)內(nèi)其他軟件去數(shù)據(jù)庫取結(jié)果。原程序重新啟動(dòng)后，通過數(shù)據(jù)庫進(jìn)行同步。具體業(yè)務(wù)處理上，分為實(shí)時(shí)業(yè)務(wù)和計(jì)劃業(yè)務(wù)，實(shí)時(shí)業(yè)務(wù)立即生效，計(jì)劃業(yè)務(wù)在未來某日生效。如圖1 所示。

圖1 原程序組件的部分運(yùn)行流程Fig.1 Partial operational procedure of original program components

原程序在實(shí)時(shí)業(yè)務(wù)中存在設(shè)計(jì)不足，對(duì)于不同終端上的同型程序之間的數(shù)據(jù)交互實(shí)現(xiàn)有問題：某個(gè)時(shí)刻不同終端上的軟件同時(shí)需要完成數(shù)據(jù)同步，此時(shí)由于不同終端的時(shí)鐘存在差異，前后時(shí)序每次都可能不同，無法保證交互的處理結(jié)果的一致性，也給系統(tǒng)內(nèi)其他軟件的使用帶來困擾。而且處于終端上的程序重啟或網(wǎng)絡(luò)重連次數(shù)較多，帶來的數(shù)據(jù)同步問題頻率較高。從系統(tǒng)安全上，實(shí)時(shí)業(yè)務(wù)需要在數(shù)據(jù)庫離線時(shí)正常工作足夠的時(shí)間，但原程序和其他軟件的處理方式是利用數(shù)據(jù)庫進(jìn)行同步的。

原軟件的計(jì)劃業(yè)務(wù)會(huì)在未來某日轉(zhuǎn)變成實(shí)時(shí)業(yè)務(wù)生效，未轉(zhuǎn)變成實(shí)時(shí)任務(wù)時(shí)，其修改和編輯和其他同類軟件無關(guān)，沒有出現(xiàn)異常情況。

面對(duì)這樣的情況，需要考慮重新進(jìn)行該程序的設(shè)計(jì)與實(shí)現(xiàn)，但原程序擁有大量人工交互的內(nèi)容，如實(shí)時(shí)數(shù)據(jù)更新、異常狀態(tài)提示、自動(dòng)條目生成、全人工條目生成、計(jì)劃輸入條件瀏覽、人工設(shè)置可用資源、可用資源實(shí)時(shí)統(tǒng)計(jì)等，這些內(nèi)容涵蓋的具體實(shí)現(xiàn)非常的細(xì)致，同時(shí)還存在很多業(yè)務(wù)處理，如計(jì)劃數(shù)據(jù)轉(zhuǎn)為實(shí)時(shí)數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)基礎(chǔ)變更、變化實(shí)時(shí)數(shù)據(jù)發(fā)出、變化實(shí)時(shí)數(shù)據(jù)接收等，如圖2 所示。

圖2 更改前后的程序內(nèi)的任務(wù)組成Fig.2 Task composition within program components before and after modification

由于這些內(nèi)容的操作方式已經(jīng)得到使用者的認(rèn)可，同時(shí)測試方式和方法較為固定，如果將這類內(nèi)容重新制作一次，未必可以保證比原軟件更有優(yōu)勢，還可能引入新的故障。

因此盡量保留原軟件的內(nèi)容，特別是計(jì)劃業(yè)務(wù)，由于交互簡單，其工作狀態(tài)一直較為穩(wěn)定，無需進(jìn)行更改。根據(jù)這些特點(diǎn)確定的移植方向是：針對(duì)原程序主要問題，將實(shí)時(shí)業(yè)務(wù)統(tǒng)一由Linux 服務(wù)端程序完成，包括計(jì)劃數(shù)據(jù)轉(zhuǎn)為實(shí)時(shí)數(shù)據(jù)、實(shí)時(shí)數(shù)據(jù)基礎(chǔ)變更、變化實(shí)時(shí)數(shù)據(jù)發(fā)出、變化實(shí)時(shí)數(shù)據(jù)接收，原程序的人工交互全部保留，成為新的終端軟件。通過將原程序中變化實(shí)時(shí)數(shù)據(jù)發(fā)出、變化實(shí)時(shí)數(shù)據(jù)接收的通信方向重新設(shè)置，實(shí)現(xiàn)終端向服務(wù)端查詢、編輯和修改。服務(wù)端程序作為唯一中心，存儲(chǔ)與管理實(shí)時(shí)業(yè)務(wù)的數(shù)據(jù)，可支持多個(gè)終端數(shù)據(jù)分段的處理，并可保證離開數(shù)據(jù)庫后維持工作一段時(shí)間。如圖3 所示。

圖3 更改后終端服務(wù)端程序組件的部分運(yùn)行流程Fig.3 Partial operational procedure of terminal service program components after modification

3.2 目標(biāo)

按照定下的方向分解出多個(gè)目標(biāo)，如表1 所示。

表1 移植工作的目標(biāo)Tab. 1 Object of transplantation works

3.3 步驟

達(dá)成詳細(xì)目標(biāo)需要不斷的持續(xù)開發(fā)，包括步驟與詳述，列出具體工作與時(shí)間花費(fèi)，每個(gè)步驟體現(xiàn)上文提到的不同的策略，如表2 所示，策略對(duì)應(yīng)的序號(hào)是本文第二節(jié)內(nèi)容。

4 總結(jié)

隨著工程需要而不斷調(diào)整的軟件結(jié)構(gòu)，是很多軟件項(xiàng)目可能遇到的問題，本文所敘述的是一次交付實(shí)際工程的程序移植的過程，偏重于講述移植過程中分析與設(shè)計(jì)的考慮。該程序成為城市軌道列車自動(dòng)監(jiān)控系統(tǒng)并正式交付已經(jīng)超過一年時(shí)間，沒有再出現(xiàn)問題，取得了較理想的效果。未來可能將服務(wù)端改造成可支持多終端對(duì)同一段數(shù)據(jù)的協(xié)同處理。

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

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