基于PMS的機務管理系統架構分析

，

(武漢理工大學 能源與動力學院，武漢 430063)

船舶維修保養工作是船舶管理的重要內容，負責船舶所有機電設備和船體所有構件的維護保養，國內企業目前普遍存在管理手段相對滯后，信息化程度低，很難及時實現對維修保養進行指導及監督的問題。因此考慮針對中小型航運企業業務需求多變的特點，開展需求分析，對以船舶維修保養體系(CWBT)為框架的計劃保養系統(PMS)體系的機務及維修管理的業務流程建立領域模型，設計易擴展的架構，這些工作也正是開發符合中小型航運企業信息系統的關鍵。

1 分析方法

中小型航運企業信息系統的開發要經過軟件的計劃、分析、設計、編碼、測試和維護的全過程。其中軟件需求分析，應建立針對用戶功能需求的領域模型，是溝通用戶需求和軟件功能的橋梁。為了減少從需求到設計之間的歧義，統一建模語言(unified modeling language,UML)的方法被廣泛采用。

標準建模語言UML的重要內容可以由9種圖形來定義: 用例圖、類圖、對象圖、狀態圖、活動圖、順序圖、合作圖、構件圖、配置圖[1]。

分析階段和架構設計階段主要用到的模型[2]見表1。

表1 分析階段和架構設計階段模型表

在需求分析階段,使用用例(use case)捕獲用戶需求。通過用例建模,描述對系統感興趣的外部角色及其對系統(用例)的功能要求。用活動圖來描述工作流程中涉及的活動及角色之間的協作。用魯棒圖幫助實現從面向業務向面向對象的轉換。

用例圖從用戶角度描述系統功能,并指出各功能的操作者，顯示多個外部參與者，以及他們與系統之間的交互和連接，僅僅描述系統參與者從外部通過對系統的觀察而得到的那些功能，并不描述這些功能在系統內部是如何實現的。用例圖主要元素是用例和執行者，用例表示為一個橢圓，參與者表示為小人形圖標，可以是人、設備或其他系統。

活動圖描述滿足用例要求所要進行的活動以及活動間的約束關系,有利于識別并行活動。活動圖由多個動作狀態組成，包含將被執行的活動(即一個動作)的規格說明。活動圖由活動狀態和轉換組成。將活動圖活動狀態分組就形成泳道圖。

魯棒圖包含三種元素：邊界對象、控制對象、實體對象。邊界對象模擬外部環境與系統的交互，負責接收外部輸入，解釋內部信息并傳遞結果；控制對象描述用例事件流的控制行為；實體對象描述需要存儲的信息[3]。

2 系統的需求分析和架構設計

中小型航運公司機務管理信息系統的任務主要包括船舶維修保養管理、備件物料管理、設備管理、檢驗與證書管理等。船舶維修保養管理是船舶機務管理的核心組成部分,其主要內容是以CWBT為框架的符合PMS體系的計劃維修保養管理[4]。

交通部頒布的《船舶維修保養體系與檢驗導則》中對PMS定義為：“計劃保養系統系指船舶機械(包括電氣設備)根據《鋼質海船入級與建造規范》等有關要求和設備制造廠說明書規定，由船東制訂一套詳細的周期性維修保養計劃，通過該計劃在船上貫徹和實施，使船舶機械始終保持良好的技術狀態。對這種船舶機械采用周期性維修保養的計劃管理，就稱為計劃保養系統。CWBT就是屬于PMS范疇。”PMS規定了船舶機械計劃性保養制度在船上實施的條件、程序和有關要求，適用于實施CWBT并具有中國船級社船級的海上船舶。

CWBT對船舶設備采用工作卡和插板管理模式，將設備保養進行分級，按月、季、半年、一年、兩年(或兩年半)、四年或五年等各周期間隔，在日常工作中安排進行,在船員完成工作后，檢修工作按照檢修周期排入下一循環。

2.1 維修保養管理的用例分析

維護保養管理是根據船舶設備的分類和具體運行情況，對設備進行計劃維修、事后維修和視情維修管理。維護保養管理用例見圖1。

圖1 維修保養管理用

用例簡述為：①計劃維修。部門長依據CWBT方法啟動計劃(定時定期)維修，維護人員實施維修；②事后維修。設備突發故障，部門長啟動事后維修，維護人員實施維修；③視情維修。維修決策系統判斷設備狀況，部門長啟動視情維修，維修人員實施維修。

中小型航運企業維修保養管理共有3個業務用例:基于PMS規范的計劃維修,基于設備狀態的事后維修和視情維修,部門長和維護人員參與所有業務用例,維修決策系統依據設備狀態提供對事后維修和視情維修業務用例的支持。

2.2 CWBT計劃維修的活動流程分析

中小型航運企業維護保養管理的核心業務用例是計劃維修，其基于PMS的CWBT計劃維修的泳道活動見圖2。

圖2 計劃維修泳道活動圖

活動圖分為3個泳道：公司在岸，部門長和主管人員在船。用例規約為：

1) 基本事件流。①公司技術部通過系統生成“本月CWBT維修指令”；②船上部門長確認，通過系統發布當月工作卡維修計劃，并打印當月工作卡下發；③維修人員依據工作卡按計劃維修設備，并在系統填寫維修記錄(或手工填寫)，并確認完成；④月底維修人員上交工作卡；⑤部門長月底回收工作卡，在系統審核本月計劃維修完成記錄(或在系統填寫維修記錄)，系統自動匯總。未完成的維修計劃重新安排維修計劃；⑥部門長通過系統生成本月維修報告和下月維修計劃；⑦公司考核維修報告；⑧公司生成下月CWBT維修指令。

2) 擴展事件流。①如有設備首次使用或大修后使用，需進行首排；②如設備發生突然性故障，臨時維修后填寫記錄，并在下月維修計劃中重排維修時間；③向系統錄入維修記錄視船上實際情況，采取維修人員逐單錄入或者部門長匯總錄入。

圖3 船上系統分層架構魯棒圖

圖4 岸上系統分層架構魯棒圖

3) 非功能性需求。①維護人員處理界面簡單易用，多采用選擇輸入；②岸版和船版數據傳輸順暢；③需打印紙質工作卡，以便維護人員操作和存檔。

4) 前置條件。①設備已完成CWBT編碼；②設備已進行首排。

無后置條件,為利于維護，所有記錄采用審核和反審核方式,高優先級。

2.3 船-岸系統的魯棒性分析

根據活動圖和規約分析，系統涉及船上(技術部)和岸上(部門長)兩個部分，分別進行魯棒性分析，確定系統的連接元素、處理元素、數據元素。船上系統魯棒圖見圖4，岸上系統魯棒圖見圖5。

2.4 基于可擴展性的概念性架構

根據魯棒圖和架構模式特點，機務管理信息系統原則上采用分層架構，從底到頂分別為

1) 代理層。傳輸和接收數據信息接口，連接船岸通訊；岸端硬件接口，限制軟件功能；船端設備在線監測接口。

2) 數據層。長期數據與臨時數據的存儲。

3) 領域層。領域模型的實例化邏輯層，其邏輯關系被元模型層反映。

4) 應用邏輯層。一組持久性組件實現領域模型的應用，通過調用模型對象實例化功能應用。

5) 展現層。采用MVC模式，從應用邏輯層得到模型數據，并通過視窗多窗口同步輸入輸出。

根據易于擴展的質量屬性需求，采用適用于靈活性開發的“映像”架構模式。“映像”模式將系統分為兩個層次。元層次提供軟件的自表示來給出軟件自身結構和行為的知識，由元對象組成，元對象封裝和表達了有關軟件的信息，包括類型結構、算法、函數調用機制等；基本層次定義軟件的應用程序邏輯并通過使用元對象提供的信息和服務來實現邏輯功能。基本層次包含持久性組件，他們不做改變，系統通過元對象協議MOP接口更改元對象，從而達到更改系統的目的。業務邏輯層(領域層和邏輯應用層)被視作基本層次，元層次分為模型層、元模型層、MOP接口層。模型層相當于基本層次對元模型的接口層，元對象調用他訪問元數據生成持久性組件可用的模型；元模型層通過元-元數據定義元對象，是“模型”的模型；MOP接口層通過修改元對象實現對系統的修改。詳見圖5概念性結構圖[5]。

圖5 概念性結構圖

3 結束語

用UML的用例圖和用例簡述可以很清晰地描述用戶對系統的功能需求；而用活動圖和用例規約進一步描述為實現每個功能用戶需進行的活動、轉換狀態；魯棒圖用于從需求向設計轉換，用于確定邊界、實體和控制元素，細化這些元素的關系，構建概念化的結構視圖。在軟件的詳細結構設計階段和程序設計階段，還將使用到類圖、狀態圖、順序圖、部署圖等工具。 詳細結構設計可應用于中小型航運企業機務管理系統的構建。

[1] GERI Schneider.APPLYING USE CASES，用例分析技術[M].姚淑珍，譯.2版.北京:中信出版社,2002.

[2] 溫 昱.軟件架構設計[M].北京:電子工業出版社,2007.

[3] 徐 峰,陳 暄.UML面向對象建模基礎[M].北京：中國水利電力出版社,2006.

[4] 劉愛華.基于CWBT的管理信息系統研究[D].武漢：武漢理工大學,2005.

[5] FRANK Buschman.Pattern-Oriented Software Architecture(Volume 1: A System of Patterns)面向模式的軟件體系結構(卷1：模式系統)[M].賁可榮,譯.北京:機械工業出版社,2003.