基于面向對象的通用控制軟件的設計與實現

劉 偉，孔袁莉，雷斯聰，鄭 柏，李晶晶

(上海航天設備制造總廠有限公司，上海 200245)

0 引言

控制軟件[1-3]是運載火箭型號各類軟件中非常重要的一類軟件，該類軟件負責控制流程的執行和調度，以自動的方式調度各子系統和各單機，使子系統和各單機按照規定的邏輯在規定的時間段內完成規定的任務。由于火箭測試的流程由控制軟件來進行發起和判斷，因此控制軟件是運載火箭型號中重要程度較高的一類軟件。在傳統的模式下，各型號都會有特定的控制軟件，軟件由特定的人員進行研發和維護，各型號之間的控制軟件設計和實現以實現本型號的需求為主，型號間的需求并不做過多的考慮。該種模式下，由于不同設計人員采用的設計方案和使用技術的原因，各型號之間的控制軟件即使有相同的功能，相互之間復用的難度也較大。這種模式下，型號間相同的功能存在重復開發的情況，并且在軟件的維護上也存在效率不高的情況。

本文針對傳統模式下，設計和維護效率較低、功能重復開發等缺點，為了提高軟件的設計和維護效率，設計了基于面向對象[4]的通用[5-8]控制軟件，對控制軟件的業務邏輯和業務過程進行了分析，將控制邏輯抽象為可組合的類。用戶可以根據需要自由組合各控制邏輯類，并將結果以XML的方式保存在本地磁盤。軟件會讀取并解析XML文件，將XML文件的內容解析為對應的邏輯控制類，以執行用戶配置的控制邏輯。

1 軟件結構與功能設計

1.1 軟件結構

通用控制軟件主要功能是對流程進行控制，需要根據已經和正在執行的控制命令，判斷任務的執行是否正確，是否繼續執行下一個控制命令。

通過對控制軟件的需求進行整理和分析，對現有型號的控制軟件的設計和實現方案進行歸納總結，將控制軟件依據功能劃分為相對獨立的4個模塊：數據源模塊、數據解析模塊、命令模塊、工具模塊，功能模塊圖如圖1所示[12]。

圖1 軟件結構圖

數據源模塊的功能是實現數據傳輸。通過對具體需求的實現，命令傳輸可使用Socket套接字、串口和Http等傳輸方式[13]。

數據處理模塊的功能是實現數據轉換。主要功能有兩個：第一是將命令和命令參數轉換為數據源可傳輸的數據形式；第二是將數據源接收到的數據轉換為命令或命令的參數。常見的形式是對網絡傳輸(TCP、UDP)字節序列和實體類進行相互轉換[14]。

命令模塊是控制軟件的核心模塊。用戶根據實際的功能需求，可以使用現有的命令組合成需要的控制功能，也可以自定義新的命令類，實現當前不具備的功能。命令的關系是松散的，命令之間可以相互組合為新的命令，組合出的命令可以像普通的命令一樣進行進一步的組合[15]。

功能模塊是輔助模塊。對軟件代碼中的一些常用操作進行封裝，減少常用功能的重復開發。

1.2 軟件功能

通用控制軟件由控制命令、命令存儲及解析、命令數據傳輸和命令數據正確性判斷4部分組成。為了提高控制類軟件的通用性和開發、維護的效率，對傳統模式下的業務進行進一步分析，將具有相同功能的業務抽象封裝為類，將可變的功能抽象為接口，為后續的功能擴展提供接口。通過將軟件功能進行模塊化，對軟件核心功能控制命令進行可配置化處理，提高了軟件開發、維護的規范性和效率。

為了驗證通用控制軟件方案的正確性，需要用戶控制命令的執行并將執行的狀態向用戶反饋。軟件在Visual Studio 2010平臺上采用C#語言進行設計和實現，以Windows窗體界面風格實現人機交互。

2 軟件整體設計

2.1 軟件結構

通用控制軟件核心原則就是面向對象方法中的“對擴展開發，對修改封閉”原則，是指將控制類軟件的相似的功能進行整合，用戶的可變需求通過擴展實現，而不需要更改原有邏輯，通過軟件的可擴展性保證軟件的靈活性和穩定性[16]。

在通用控制軟件的設計過程中，不僅需要考慮軟件的擴展性和可維護性，而且還需要考慮對現有型號的專用控制軟件的兼容性，以確保設計的軟件能夠更好地適應型號的需求[17]。通過對軟件的需求進行分析，對現有型號的專用控制軟件的設計方案和使用場景進行歸納總結，通過使用面向對象分析與設計技術，將當前涉及到的控制操作轉換為軟件代碼中的類，目前包括1個父類和10個實現類，父類參考建造者設計模式，通過模板類的形式為子類提供統一的業務邏輯的執行順序，實現類根據需求實現特定的操作，實現類之間可以以積木的形式組合成新的命令，完成復雜的控制邏輯。軟件類圖如圖2所示。

圖2 軟件類圖

2.2 軟件工作流程

通用流程控制軟件的執行流程如圖3所示。

圖3 軟件執行流程圖

為了提高軟件維護的靈活性和便利性，控制流程被保存在本地磁盤上的XML文件，用戶通過修改該XML文件即可達到更改控制邏輯的目的。

軟件工作的具體流程如下：軟件啟動后，軟件會根據用戶配置的保存控制流程的XML文件的路徑，自動加載該XML文件并解析為控制命令。在成功解析到控制命令后，軟件會將控制命令以人機交互界面的形式呈現，便于用戶使用[18]。

3 軟件設計關鍵技術

3.1 基于面向對象的業務抽象

在通用控制軟件的設計時，通過對現有型號的控制軟件的業務功能進行分析，發現現有型號的控制軟件在業務功能上和流程控制邏輯上有相似的部分，這一部分屬于冗余的重復開發的部分。

面向對象分析與設計(OOAD，object orient analysis & design)的優點就是能夠構建與現實世界相對應的問題模型，并保持他們的結構、關系和行為為模式，通過對業務邏輯的合理的分析和設計，有效的避免重復的部分[19]。

通過面向對象分析和設計技術對軟件的業務邏輯進行抽象和分析，將業務邏輯中需求的實體提取成類，功能提取成方法。各個類的含義如下：

Command類：命令類的基類，定義命令的基本屬性。

ComplexCommand類：命令的一種實現，是一組命令的集合，將多個命令組合成一個命令，完成命令的執行和執行成功、失敗的判斷。

AllSuccessCommand類：復合命令的一種實現，是指所包含的所有命令均執行成功，該命令執行成功，否則該命令執行失敗。

OneSuccessCommand類：復合命令的一種實現，是指所包含的任意一個命令執行成功，該命令執行成功，否則該命令執行失敗。

DataCommand類：命令的一種實現，數據命令類，是指該命令需要進行數據交互。

CircleCommand類：數據命令的一種實現，循環數據命令，是指該命令需要多次進行主動的數據推送，而不需要數據回饋。

DataReplyCommand類：數據命令的一種實現，數據回饋命令類，是指該命令需要主動推送數據并需要回饋數據。

DataQueryCommand類：數據回饋命令類的一種實現，數據查詢類，是指該命令需要主動推送數據并對回饋數據進行判斷。

AlertCommand類：命令的一種實現，警告命令，該命令是對用戶操作的一種提升，用戶可在控制流程中，通過彈出警告對話框以實現控制流程的用戶確認。

ConfirmCommand類：命令的一種實現，確認命令，該命令是對用戶操作的一種提升，用戶可在控制流程中，通過彈出確認對話框以實現控制流程的用戶選擇。

SleepCommand類：命令的一種實現，延時命令，該命令是用于自定義延時，用戶可根據需要定義延時命令的時機和延時的時間。

通過對業務邏輯進行建模和分析[9]，將命令抽象成類。同時考慮到用戶需求和軟件設計的擴展性，將一些非功能性需求的功能也提升為命令，如界面中的彈出窗口等，以提升軟件的維護性，提高軟件的維護效率，降低軟件的維護成本[20]。

在分析出功能性需求和非功能性需求的命令后，再通過面向對象中的繼承和多態技術，達到屏蔽細節而實現不同功能的目的。舉例而言，AlertCommand和SleepCommand是兩個功能完全不同的命令，但是這兩個類均繼承于Command類，則這兩個類就可以以相同的方式使用。AlertCommand實現彈出一個警告對話框，只有在用戶選擇確認后流程才繼續執行，否則流程一直等待；SleepCommand則是一個延時命令，延時會自動執行，直到延時完成或用戶終止流程[21]。

在上訴的抽象設計下，不用的命令之間可以相互組合，多個命令也可以組合成一個命令。組合出的命令又可以和其他命令進一步組合成更復雜的命令。這種組合方式類似“搭積木”的方式，軟件業務中有不同的類，但是提供相同的“外形”(接口/父類)，那么不同的類就可以在一定的規則下進行自由組合。用戶通過這種“搭積木”似的命令組合，已達到用戶期望的控制邏輯的目的。

3.2 XML序列化

XML(extensible markup language)，可擴展標記語言，是一種基于文本、跨平臺的結構型標記語言，可用于保存和傳輸數據，用戶可以非常方便地使用文本編輯工具對XML文件進行編輯，完成測試流程的添加、修改和刪除操作。

用戶將多個命令按照一定規則組合成測試流程，測試流程需要持久化[10-11]后才能永久保存，否則就只能臨時存在于內存中，軟件關閉后數據丟失，無法再次使用。為了便于用戶對測試流程進行維護，采用XML文件作為測試流程持久化的方式，通過序列化和反序列化的方式高效的實現持久化文本與軟件代碼的相互轉換。

在通用控制軟件中，為了便于管理和維護，設計了繼承“AllSuccessCommand”類的子類“TestProject”作為一個項目，其他的命令實現類可以以自身或者多個實現類組合成的新命令作為項目命令集合的一個子項，通過類似“搭積木”的方式將各個實現類組合成一個實現特定要求的測試項目。

舉例而言，新建一個名為“測試項目”的測試流程，設計項目包括一個名為“測試一”的任意成功命令；“測試一”由一個名為“測試一1”的任意成功命令和一個名為“測試一2”的全部成功命令組成；“測試一1”由一個名為“測試一11”的選擇確認命令和一個名為“測試一12”的查詢命令組成；“測試一2”由一個名為“測試一21”的確認命令和一個名為“測試一22”的選擇確認命令組成。

測試流程結構如圖4所示。

圖4 測試項目結構

測試項目的執行流程如圖5所示。

圖5 測試項目執行流程

測試項目持久化為XML文件的情況如下所示：

xmlns:xsd="http://www.w3.org/2001/XMLSchema">

Attempts="1" AttemptInterval="500">

舉例中的測試流程的設計過程，測試流程的新增或修改完全是在對配置文件的新增或修改的方式上完成的，不需要進行任何代碼的修改，實現了軟件代碼設計和維護的分離，維護人員只需要按照規定的方式進行XML文本文件的新增和修改即可實現測試流程的新增和修改。而且在軟件設計和實現時按照模塊化和插拔式的原則，使得基礎的各種控制命令和組合出的控制命令可以進行無差別的組合，通過類似“搭積木”的方式，將各種基礎命令和組合命令組合成具有更復雜功能的命令。

4 測試結果與分析

4.1 案例實現

為了驗證本文的設計和實現思路的可行性，軟件二次開發和維護的效率。二次開發的過程以實現現有的XX-6型號的等效控制軟件功能的方式進行。

XX-6型號等效控制軟件的通訊方式采用TCP網絡的方式，數據交互對象為一個上位機軟件，根據型號對控制軟件的設計要求，二次開發的過程主要由3個步驟組成：

1)根據數據源模塊的接口要求，設計一個TCP網絡通訊數據源模塊，完成控制軟件與交互上位機軟件的TCP網絡通訊。

2)根據數據處理模塊接口的要求，依據XX-6型號的數據格式，設計滿足型號實際需求的數據處理模塊，完成命令、命令參數與二進制數據的相互轉換；

3)根據命令模塊要求，依據XX-6型號控制邏輯要求，軟件提供的基礎命令類能夠滿足功能要求，只需按照要求新建測試流程的XML文件。

在通用控制軟件基礎功能的基礎上，XX-6型號控制軟件的開發過程只需要對差異性的模塊進行二次開發，相同的功能模塊無需重復開發，控制流程的修改可以通過修改文件的方式實現，開發和維護的效率顯著提高。

4.2 結果與不足

在開發過程中，控制軟件相似功能的部分，如簡單命令成功、失敗邏輯控制、復合命令成功、失敗判斷及控制、控制流程持久化等無需重復開發；特殊需求，如各型號的數據解析、數據合格性判斷等可通過擴展的方式實現，而不影響原有的業務邏輯。

在維護過程中，由于采用了統一的設計思路，測試流程也存儲在XML文件中，測試流程的維護的效率也得到了提高，降低了后期維護的成本。測試結果達到了預期的目的。

但是在開發過程中也發現了一些不足之處，控制流程的修改是通過對XML文件的修改來實現，但是XML文件的編輯是直接手動修改文件，目前還沒有提供可視化的編輯方式，用戶需要熟悉XML文件中的每個標簽的含義，編輯時的錯誤也不容易發現，后續提供可視化的操作接口，用戶可以在軟件中編輯測試流程并自動保存為XML文件，這樣可以減少人為的文本編輯錯誤，用戶也無需了解XML文件的標簽所代表的含義，降低測試流程維護的難度，進一步提高軟件維護的效率。

5 結束語

針對傳統模式下，各型號的控制軟件相互間通用性低、相似功能重復開發的問題。設計了一套基于面向對象的通用控制軟件。對軟件業務流程中的功能性需求和非功能性需求進行抽象和分析，將業務需求中的實體抽象成命令類，并將部分非功能需求也提升成命令，使得用戶可以通過類似“搭積木”的方式組合各種命令。

通過采用統一的設計思想和通用化設計，提高軟件開發和維護的效率，節省了軟件開發和維護工作的人力成本，在應對當前的高強度任務方面具有重要意義。