1、火電廠設(shè)備檢修管理系統(tǒng)的UML建模劉志強 黃樹紅 高偉華中科技大學(xué)動力系 摘要：狀態(tài)檢修是科學(xué)的設(shè)備檢修方式，實施先進(jìn)的檢修管理、建立設(shè)備檢修管理系統(tǒng)是狀態(tài)檢修的基礎(chǔ)。本文分析了設(shè)備檢修管理系統(tǒng)的功能需求，探討了對電廠設(shè)備檢修管理系統(tǒng)采用統(tǒng)一建模語言（Unified Modeling Language）進(jìn)行可視化建模的一般過程和可行性，并以某300MW機組為例論述設(shè)備檢修管理系統(tǒng)的基本框架和UML建模過程。關(guān)鍵詞：發(fā)電設(shè)備 狀態(tài)檢修 統(tǒng)一建模語言（U） 管理信息系統(tǒng)1 引言建國以來，我國長期實行的檢修體制是以故障檢修、預(yù)防性計劃檢修為主的體制。隨著社會經(jīng)濟和科技的發(fā)展，檢修體制目前正逐步向預(yù)知

2、性的狀態(tài)檢修體制過渡。以故障檢修、預(yù)防性計劃檢修為主的檢修體制曾經(jīng)是適應(yīng)我國生產(chǎn)力發(fā)展水平的，它一般包括大修、小修、臨修、定期維護(hù)等形式。在電廠設(shè)備管理中采用這種檢修方式的優(yōu)點在于保持供電的基本穩(wěn)定性，人力、物力、資金安排的計劃性，生產(chǎn)指揮者基本上做到心中有數(shù)。在這種檢修體制下，一般大修間隔23年，小修間隔48個月，檢修項目、工期安排和檢修周期均由管理部門根據(jù)經(jīng)驗制定。但隨著火電設(shè)備向高參數(shù)、大容量、復(fù)雜化發(fā)展，其安全經(jīng)濟運行對社會的影響也越來越大，維修投入大幅度上升。面對這個情況，現(xiàn)行檢修體制日益明顯暴露出所存在的缺陷，因此對設(shè)備實行更先進(jìn)、更科學(xué)的管理和檢修體制，無論從火電廠自身的利益還是

3、從社會的要求出發(fā)，都是勢在必行。狀態(tài)檢修是在設(shè)備狀態(tài)監(jiān)測的基礎(chǔ)上，根據(jù)設(shè)備狀態(tài)監(jiān)測和分析診斷的結(jié)果安排檢修時間和項目的檢修體制。所以，它是一種適應(yīng)于市場經(jīng)濟和現(xiàn)代企業(yè)制度的全新的設(shè)備維修策略，根據(jù)我國國情，狀態(tài)檢修實際上是融故障檢修、計劃性檢修、狀態(tài)性檢修、主動檢修為一體的，具有最大的可靠性和最低的成本消耗的混合式優(yōu)化檢修體制。目前，在火電廠推行狀態(tài)檢修所要達(dá)到的目標(biāo)是：延長定期檢修間隔；減少定期檢修時間；提高設(shè)備可靠性和可用系數(shù)；增加發(fā)電量；延長設(shè)備壽命；降低運行檢修費用；減少資金投入；改善電廠運行性能；提高火電企業(yè)經(jīng)濟效益。狀態(tài)檢修作為一種先進(jìn)的檢修體制，是一個涉及到技術(shù)、經(jīng)濟、體制等多方

4、面的系統(tǒng)工程，涉及到許多管理問題。要實行狀態(tài)檢修，必須使設(shè)備檢修管理工作標(biāo)準(zhǔn)化，正確完整的技術(shù)數(shù)據(jù)和技術(shù)管理是狀態(tài)檢修的基礎(chǔ)。目前在電廠的設(shè)備檢修工作管理中，由于設(shè)備的繁多和復(fù)雜，相對應(yīng)的檢修工作票、檢修工藝卡的管理十分復(fù)雜，整個檢修工作的過程管理也很復(fù)雜，大多數(shù)電廠都是單憑檢修管理人員的腦力勞動和手工記錄，這已經(jīng)不能滿足狀態(tài)檢修的要求。因此，結(jié)合全廠設(shè)備管理信息化的建設(shè)，建立狀態(tài)檢修的計算機管理信息系統(tǒng)是推行這一體制的基礎(chǔ)性工程。本文論述了檢修管理信息系統(tǒng)的設(shè)計和建模工作，并在系統(tǒng)的需求分析和總體設(shè)計中采用了可視化建模的方法。大型信息管理系統(tǒng)建模是系統(tǒng)成敗的關(guān)鍵，采用建模語言進(jìn)行建模有利于系

5、統(tǒng)的最后實施。本文采用的建模語言是目前國際上流行的統(tǒng)一建模語言（U）。UML是一種定義良好、易于表達(dá)、功能強大且普遍適用的建模語言。它溶入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。它的作用域不僅限于支持面向?qū)ο蟮姆治雠c設(shè)計，還支持從需求分析開始的軟件開發(fā)的全過程。2 設(shè)備檢修管理系統(tǒng)的需求分析設(shè)備檢修是設(shè)備全過程管理的一個重要環(huán)節(jié)，狀態(tài)檢修作為一種先進(jìn)的檢修體制，它的內(nèi)容包括著很多管理方面的問題。這些問題主要有：數(shù)據(jù)的綜合管理、檢修風(fēng)險分析與決策、備品備件管理、具體檢修過程的實施管理、相應(yīng)設(shè)備管理政策的制訂、對檢修效果的評估、專業(yè)人員的培訓(xùn)以及機構(gòu)設(shè)置等問題。而其中檢修管理是是涉及到上述諸多問題

6、的最主要管理工作。檢修管理包括設(shè)備缺陷管理；檢修工作票、工藝卡管理；檢修計劃管理；檢修項目管理以及備品備件管理等。它可為整個狀態(tài)檢修過程提供完備的技術(shù)數(shù)據(jù)、檢修依據(jù)和檢修過程的自動化控制。因此，設(shè)備檢修管理系統(tǒng)的實施對電廠實施狀態(tài)檢修有很重要的意義。針對狀態(tài)檢修的要求，設(shè)備檢修管理系統(tǒng)應(yīng)通過以下五個子系統(tǒng)來滿足其需求。 檢修工作票、檢修工藝卡管理系統(tǒng)在系統(tǒng)中對設(shè)備的檢修工作票集中管理，執(zhí)行工作票辦理、簽發(fā)、接受、許可、變更、延期、終結(jié)、驗收、完工處理等任務(wù)；對設(shè)備檢修工藝卡亦進(jìn)行集中管理，提供錄入、刪除、查詢、編輯等功能。 設(shè)備缺陷管理系統(tǒng)該系統(tǒng)從人為發(fā)現(xiàn)缺陷開始，輔助檢修部門組織人員進(jìn)行消缺

7、，同時詳細(xì)記錄消缺的整個過程，進(jìn)行設(shè)備缺陷統(tǒng)計，為分析設(shè)備運行情況和部門考核提供科學(xué)依據(jù)，并為以后制定大修計劃和對設(shè)備質(zhì)量進(jìn)行評估提供參考。 檢修計劃管理系統(tǒng)對設(shè)備的定期檢修計劃進(jìn)行管理，制定設(shè)備定檢滾動計劃表。并可根據(jù)定檢表生成月計劃項目表和檢修卡。 檢修項目管理系統(tǒng)通過狀態(tài)監(jiān)測和故障診斷分析出的診斷結(jié)果、設(shè)備事故和缺陷，提交設(shè)備檢修申請。針對所提交的申請，生成工程項目，規(guī)定該項目應(yīng)執(zhí)行的工作計劃。工程項目中包括檢修開工處理及完工處理，檢修結(jié)果的驗收、評估，報表生成。其檢修作業(yè)管理模塊對檢修作業(yè)的四個階段（分析監(jiān)測、檢修建議生成、作業(yè)單生成和檢修開始、檢修完成）進(jìn)行管理，同時跟蹤檢修作業(yè)進(jìn)行

8、的狀況，如檢修建議是否送出、取消、等待批準(zhǔn)，等待計劃、等待材料、完成、完成封檔等。 備品備件管理系統(tǒng)對電廠設(shè)備的備品備件進(jìn)行綜合管理，能夠隨時提供設(shè)備的備件信息；上述五個系統(tǒng)之間的聯(lián)系非常緊密，要完成各自的功能都要用到其他系統(tǒng)的數(shù)據(jù)。它們之間有的是并行處理，有的是順序處理，而且所涉及到的系統(tǒng)用戶種類很多，權(quán)限管理十分復(fù)雜，各個用戶之間的業(yè)務(wù)聯(lián)系錯綜復(fù)雜。各系統(tǒng)下的子系統(tǒng)同樣也是復(fù)雜多變，功能劃分不易明確。同時，系統(tǒng)還要兼容電廠已有的網(wǎng)絡(luò)系統(tǒng)和廠級MIS系統(tǒng)。因此，要能夠準(zhǔn)確完成系統(tǒng)的需求分析和總體設(shè)計，也就是對電廠的設(shè)備維修管理進(jìn)行建模，從業(yè)務(wù)需求到要求，到模型，是一項很重要的工程，整個系統(tǒng)的

9、成敗也就在于建模的成功與否。另外，考慮到團(tuán)隊開發(fā)以及系統(tǒng)的健壯性、伸縮性和良好的繼承性、可維護(hù)性，選擇一個在整個系統(tǒng)的生命周期中都適用的建模工具十分關(guān)鍵。3 統(tǒng)一建模語言UML和可視化建模系統(tǒng)建模時，要把用戶的業(yè)務(wù)需求映射到開發(fā)小組能理解的技術(shù)要求，并最終產(chǎn)生代碼。將業(yè)務(wù)需求和技術(shù)要求映射為代碼，保證代碼滿足這些要求，而且代碼最終可以方便的回溯要求。這個過程稱之為建模。面向?qū)ο蟮姆治雠c設(shè)計(OOAD)方法的發(fā)展在80年代末至90年代中出現(xiàn)了一個高潮，UML是這個高潮的產(chǎn)物。它不僅統(tǒng)一了Booch、Rumbaugh和Jacobson的表示方法2，4，而且對其作了進(jìn)一步的發(fā)展，并最終統(tǒng)一為大眾所接

10、受的標(biāo)準(zhǔn)建模語言。1996年底，UML已穩(wěn)占面向?qū)ο蠹夹g(shù)市場的85，成為可視化建模語言事實上的工業(yè)標(biāo)準(zhǔn)。1997年11月17日，OMG采納UML 1.1作為基于面向?qū)ο蠹夹g(shù)的標(biāo)準(zhǔn)建模語言。標(biāo)準(zhǔn)建模語言UML的重要內(nèi)容可以由下列五類圖形(共9種圖形)來定義:第一類是用例圖,從用戶角度描述系統(tǒng)功能,并指出各功能的操作者（角色）。第二類是靜態(tài)圖(Static diagram),包括類圖、對象圖和包圖。其中類圖描述系統(tǒng)中類的靜態(tài)結(jié)構(gòu)。不僅定義系統(tǒng)中的類,表示類之間的聯(lián)系如關(guān)聯(lián)、依賴、聚合等,也包括類的內(nèi)部結(jié)構(gòu)(類的屬性和操作)。類圖描述的是一種靜態(tài)關(guān)系,在系統(tǒng)的整個生命周期都是有效的。對象圖是類圖的實

11、例,幾乎使用與類圖完全相同的標(biāo)識。他們的不同點在于對象圖顯示類的多個對象實例,而不是實際的類。一個對象圖是類圖的一個實例。由于對象存在生命周期,因此對象圖只能在系統(tǒng)某一時間段存在。包由包或類組成,表示包與包之間的關(guān)系。包圖用于描述系統(tǒng)的分層結(jié)構(gòu)。第三類是行為圖(Behavior diagram),描述系統(tǒng)的動態(tài)模型和組成對象間的交互關(guān)系。其中狀態(tài)圖描述類的對象所有可能的狀態(tài)以及事件發(fā)生時狀態(tài)的轉(zhuǎn)移條件。通常,狀態(tài)圖是對類圖的補充。在實用上并不需要為所有的類畫狀態(tài)圖,僅為那些有多個狀態(tài)其行為受外界環(huán)境的影響并且發(fā)生改變的類畫狀態(tài)圖。而活動圖描述滿足用例要求所要進(jìn)行的活動以及活動間的約束關(guān)系,有利

12、于識別并行活動。第四類是交互圖(Interactive diagram),描述對象間的交互關(guān)系。其中順序圖顯示對象之間的動態(tài)合作關(guān)系,它強調(diào)對象之間消息發(fā)送的順序,同時顯示對象之間的交互;合作圖描述對象間的協(xié)作關(guān)系,合作圖跟順序圖相似,顯示對象間的動態(tài)合作關(guān)系。除顯示信息交換外,合作圖還顯示對象以及它們之間的關(guān)系。如果強調(diào)時間和順序,則使用順序圖;如果強調(diào)上下級關(guān)系,則選擇合作圖。這兩種圖合稱為交互圖。第五類是實現(xiàn)圖( Implementation diagram )。其中構(gòu)件圖描述代碼部件的物理結(jié)構(gòu)及各部件之間的依賴關(guān)系。一個部件可能是一個資源代碼部件、一個二進(jìn)制部件或一個可執(zhí)行部件。它包含

13、邏輯類或?qū)崿F(xiàn)類的有關(guān)信息。部件圖有助于分析和理解部件之間的相互影響程度。UML適用于系統(tǒng)開發(fā)過程中從需求規(guī)格描述到系統(tǒng)完成后測試的不同階段。在需求分析階段，可以用用例來捕獲用戶需求。通過用例建模，描述對系統(tǒng)感興趣的外部角色及其對系統(tǒng)（用例）的功能要求。分析階段主要關(guān)心問題域中的主要概念（如抽象、類和對象等）和機制，需要識別這些類以及它們相互間的關(guān)系，并用UML類圖來描述。為實現(xiàn)用例，類之間需要協(xié)作，這可以用UML動態(tài)模型來描述。在分析階段，只對問題域的對象（現(xiàn)實世界的概念）建模，而不考慮定義軟件系統(tǒng)中技術(shù)細(xì)節(jié)的類（如處理用戶接口、數(shù)據(jù)庫、通訊和并行性等問題的類）。這些技術(shù)細(xì)節(jié)將在設(shè)計階段引入，

14、因此設(shè)計階段為構(gòu)造階段提供更詳細(xì)的規(guī)格說明。 編程（構(gòu)造）是一個獨立的階段，其任務(wù)是用面向?qū)ο缶幊陶Z言將來自設(shè)計階段的類轉(zhuǎn)換成實際的代碼。在用UML建立分析和設(shè)計模型時，應(yīng)盡量避免考慮把模型轉(zhuǎn)換成某種特定的編程語言。因為在早期階段，模型僅僅是理解和分析系統(tǒng)結(jié)構(gòu)的工具，過早考慮編碼問題十分不利于建立簡單正確的模型。 UML模型還可作為測試階段的依據(jù)。系統(tǒng)通常需要經(jīng)過單元測試、集成測試、系統(tǒng)測試和驗收測試。不同的測試小組使用不同的UML圖作為測試依據(jù)：單元測試使用類圖和類規(guī)格說明；集成測試使用部件圖和合作圖；系統(tǒng)測試使用用例圖來驗證系統(tǒng)的行為；驗收測試由用戶進(jìn)行，以驗證系統(tǒng)測試的結(jié)果是否滿足在分析

15、階段確定的需求?？梢暬⒛Ｐ椭械男畔⒂脴?biāo)準(zhǔn)的圖形元素直觀地顯示。目前，支持UML可視化快速開發(fā)應(yīng)用程序的工具很多，其中Rational公司的Rational Rose是其中之一，它支持Use Case框圖，Sequence框圖等圖。通過正向和逆向轉(zhuǎn)出工程代碼特性，可支持C+，Java，Visual Basic的代碼產(chǎn)生和逆向轉(zhuǎn)出工程代碼。4 電廠設(shè)備檢修管理系統(tǒng)的建模本系統(tǒng)采用UML語言進(jìn)行建模。第一步工作是系統(tǒng)的需求分析，而需求分析必須以針對該系統(tǒng)的調(diào)研為基礎(chǔ)。在調(diào)研過程中，可針對現(xiàn)行系統(tǒng)和信息需求進(jìn)行分析，并得出系統(tǒng)的功能需求分析。用例模型用于需求分析階段，它的建立是系統(tǒng)開發(fā)者和用戶反

16、復(fù)討論的結(jié)果，表明了開發(fā)者和用戶對需求規(guī)格達(dá)成的共識。清楚表達(dá)系統(tǒng)的用例圖往往不是一次就能做好的，必須在對系統(tǒng)所涉及的業(yè)務(wù)充分了解下，才能不斷完善，它反映了系統(tǒng)與外界的交互作用。以某300MW火電機組為例，根據(jù)需求分析，建立起一個初步的框架。系統(tǒng)按上述五個子系統(tǒng)進(jìn)行功能劃分。系統(tǒng)涉及業(yè)務(wù)和各種人員類型很多，若是將其用一個用例圖表達(dá)是不可能的，因此，對應(yīng)五個子系統(tǒng)將用例分成了五個包，每個包中若涉及的業(yè)務(wù)和系統(tǒng)人員仍比較復(fù)雜的話，還可以在此包的基礎(chǔ)上再分若干包，包中包含了用例圖。而包圖將類似項目組合在一起，顯示包與包之間的依賴、繼承關(guān)系。用例圖中的角色（Actor）對形成用例圖是非常有用的，獲取一

17、個用例，首先就要找到與之關(guān)聯(lián)的角色。面對一個大系統(tǒng)，要列出用例清單常常是十分困難。這時可先列出角色清單，再對每個角色列出它的用例，問題就會變得容易很多。在本系統(tǒng)開發(fā)中，通過用戶對一些問題的回答來識別角色。如：系統(tǒng)中工作票及工藝卡由誰制定，由誰填寫，由誰來執(zhí)行等問題。此外，弄清楚本系統(tǒng)需要和哪些系統(tǒng)進(jìn)行交互是很重要的，如與設(shè)備臺帳管理系統(tǒng)、物資管理系統(tǒng)的交互關(guān)系等。一旦弄清楚了系統(tǒng)中的主要角色，就可以對每個角色提出與之相關(guān)的問題，例如：針對汽機檢修人員需要系統(tǒng)為之提供什么功能，如查詢設(shè)備檢修工藝卡，生成設(shè)備檢修報告等。他們對系統(tǒng)做哪些操作，特別是必須提醒系統(tǒng)角色的系統(tǒng)事件有哪些，怎樣把這些事件表

18、示成用例中的功能？如系統(tǒng)發(fā)出缺陷通知事件，該事件應(yīng)通知檢修部門。值得注意的是一個用例必須至少和一個角色關(guān)聯(lián)。經(jīng)過提煉和歸納，可以得到系統(tǒng)的全部用例圖。圖1是本系統(tǒng)的設(shè)備定檢制度制定用例圖。該用例圖基本反映了電廠設(shè)備定檢計劃的編制過程。在本圖中所涉及到的部門人員有檢修部，檢修班組，它們在圖中反映為角色。這些角色啟動了與系統(tǒng)的通信，它們所完成的功能或與系統(tǒng)的交互在圖中就反映為用例。角色與用例之間的通信稱之為通信關(guān)系（communication relationship），它們用箭頭表示。Use Case框圖的一大優(yōu)勢在于通信?？蛻艨梢詮脑搱D中取得大量信息，通過查閱用例與角色，可以知道電廠設(shè)備定檢計

19、劃編制的基本過程，有助于尋找缺少的功能。圖1 設(shè)備定檢制度制定用例圖從物理結(jié)構(gòu)上，電廠檢修管理系統(tǒng)應(yīng)采用三層分布式體系結(jié)構(gòu)，整個系統(tǒng)的功能分布于多臺PC服務(wù)器之上，這些服務(wù)器的功能大致分為兩類：一類是設(shè)備檢修應(yīng)用服務(wù)器，還有一類是數(shù)據(jù)庫服務(wù)器。設(shè)備檢修應(yīng)用服務(wù)器則提供設(shè)備管理、檢修策劃等項功能，而完成上述功能所需要的數(shù)據(jù)由數(shù)據(jù)庫服務(wù)器進(jìn)行存儲、檢索。設(shè)備檢修應(yīng)用服務(wù)器是中間層，屬于應(yīng)用服務(wù)器。三層分布式體系結(jié)構(gòu)在可視化UML建模的邏輯視圖中就表示為用戶服務(wù)包，應(yīng)用服務(wù)包和數(shù)據(jù)服務(wù)包。本系統(tǒng)的應(yīng)用服務(wù)包包含各種應(yīng)用業(yè)務(wù)規(guī)則，例如工作票的業(yè)務(wù)流程、檢修申請過程等。要將這些業(yè)務(wù)弄清楚并為以后做詳細(xì)設(shè)

20、計和編碼的需要，就必須將應(yīng)用服務(wù)包中的類劃分清楚。類反映了系統(tǒng)的行為，對系統(tǒng)分析十分重要。因此，本文可視化建模的重點工作也是弄清應(yīng)用服務(wù)包中的類及其相互關(guān)系。在UML中主要有三種類的形式：1） 邊界類它位于系統(tǒng)與外界的交界處，包括所有界面窗體、報表等。2） 實體類它保存要放進(jìn)持續(xù)存儲體的信息，通過該類可以設(shè)計數(shù)據(jù)庫。3） 控制類它負(fù)責(zé)協(xié)調(diào)其他類的工作，每個用例圖通常都有一個控制類，控制用例圖中的事件順序。由于本系統(tǒng)的特點是時序性較強，如工作票的流程，檢修申請的流程控制等，因此控制類在本系統(tǒng)中是非常重要的。本系統(tǒng)主要涉及到的實體類有：工作票信息；工藝卡信息；設(shè)備定檢滾動計劃表；月計劃項目表；大、

21、小修計劃表；檢修設(shè)備登記表；驗收報告等。這些實體類與界面類的連接就是通過控制類來完成?？刂祁愔饕校哼\行控制類，它相當(dāng)于電廠運行部門的操作；工作票控制類，系統(tǒng)的不同用戶可以通過它完成各種操作；檢修控制類，通過它完成檢修過程中的不同操作；工藝卡的編制、查詢等控制類。類與類之間的繼承、關(guān)聯(lián)、依賴等關(guān)系也必須在建模時列出，通過類和類之間的關(guān)系反映出本系統(tǒng)的基本框架。在這些關(guān)系中，有一對多關(guān)系，也有多對多關(guān)系。系統(tǒng)中關(guān)于業(yè)務(wù)方面的類和類之間的關(guān)系可在UML中用類圖表示出來。對于一些業(yè)務(wù)功能時序性較強的類，流程可用順序圖和合作圖表示。本系統(tǒng)的一個類圖如圖2所示。圖2 設(shè)備檢修工藝卡管理類圖該類圖顯示了檢

22、修工藝卡管理的靜態(tài)行為。在類圖中還可顯示各個類的行為和屬性。圖中的箭頭表示類之間的關(guān)系，它表示為一個類可以向另一個類發(fā)送消息。通過該類圖可以完整的看到工藝卡管理系統(tǒng)的各個對象之間的關(guān)系，有助于開發(fā)人員在編碼之前顯示和計劃系統(tǒng)結(jié)構(gòu)，保證系統(tǒng)一開始就設(shè)計合理。5 結(jié)語本文描述的設(shè)備檢修管理系統(tǒng)的前期開發(fā)工作已初步完成。由于采用了UML建模方法，在需求分析階段和用戶之間的溝通變的很方便。采用直觀的圖形表示，系統(tǒng)模型層次分明，對重要信息一目了然，用戶可以通過模型直觀的看到用戶與系統(tǒng)間的交互關(guān)系，分析人員可以看到系統(tǒng)對象間的交互關(guān)系，項目管理人員可以看到整個系統(tǒng)及各部分的交互關(guān)系?？梢暬７椒?，使系統(tǒng)

23、分析人員很方便進(jìn)行業(yè)務(wù)規(guī)則的修改和設(shè)計，大大減輕了工作量，提高開發(fā)效率，特別有利于團(tuán)隊開發(fā)發(fā)行系統(tǒng)。參考文獻(xiàn)：1. 華中理工大學(xué)能源科學(xué)與工程學(xué)院，火電廠狀態(tài)檢修概論，1997年11月2. 電子工業(yè)出版社，UML with Rational Rose從入門到精通，邱仲潘 等譯3. 張啟剛，電力設(shè)備管理與維修決策支持系統(tǒng)的研究與開發(fā) 華中理工大學(xué)碩士學(xué)位論文，2000.54. 北京航空航天大學(xué)軟件工程研究所，標(biāo)準(zhǔn)建模語言UML及其支持環(huán)境，1998年Modeling equipment maintenance management system of power station with UMLLiu ZhiQiqng Huang ShuHong Gao WeiDepartment of Power EngineeringHuazhong University of Science and TechnologyA