1、UML關(guān)于工程管理中文檔組織流程化模型描述運用UML建模技術(shù)，對工程管理中文檔的組織流程進行模型化描述，并用圖示化形式表述工程管理與文檔管理的數(shù)據(jù)接口實現(xiàn)。一、前言    PDM是一種戰(zhàn)略性的企業(yè)管理體系框架，它應用一組一致的業(yè)務方案來支持在擴展企業(yè)內(nèi)創(chuàng)立、管理、分布和使用覆蓋產(chǎn)品整個生產(chǎn)過程的產(chǎn)品信息，它集成了人、過程和信息。              通俗地講，PDM是管理和產(chǎn)品相關(guān)的各種數(shù)據(jù)的計算機輔助管理體系。依據(jù)這個對PDM系統(tǒng)管理功能的定位，在

2、它的功能需求上規(guī)定了文檔管理、產(chǎn)品數(shù)據(jù)管理的有效實現(xiàn)。在此根底上，隨著技術(shù)和功能需求的擴大，PDM更加注重了知識的搜集、分類、重用以及再生等，工程管理、工作流管理就是在這種要求下擴大PDM的實現(xiàn)功能。    PDM數(shù)據(jù)管理的一項最根本的功能理念就是實現(xiàn)數(shù)據(jù)的共享和流程化監(jiān)控。保證在PDM軟件平臺之上實現(xiàn)不同格式數(shù)據(jù)的轉(zhuǎn)換和不同模塊間數(shù)據(jù)的交互與傳遞。在PDM系統(tǒng)的功能模塊中，文檔管理是一個基準點，其他的模塊比方產(chǎn)品結(jié)構(gòu)管理、工作流管理、工程管理圍繞這一個點完善管理流程，這也就是功能模塊間數(shù)據(jù)共享的接口實現(xiàn)問題。本文將結(jié)合工程管理與文檔管理間數(shù)據(jù)交互的流程說明接口實

3、現(xiàn)的要求，并借助面向?qū)ο蟮慕＜夹g(shù)UML對實現(xiàn)過程進行圖示化描述。    二、工程管理中的文檔組織接口實現(xiàn)    工程管理PM是一種在一定的約束條件下，對一系列活動進行的時間、范圍和本錢的管理，其目標在于有效地管理為完成特定目標而進行的一系列活動，PM按照工程的內(nèi)部邏輯進行任務方案、跟蹤、控制、核算和資源調(diào)配等。依據(jù)定義，在PDM中規(guī)定了工程管理的兩項根本功能：工程組織和工程監(jiān)控， 兩方面協(xié)調(diào)管理工程的整個生命周期。    工程組織是根據(jù)工程的特點和工程方案，緊密圍繞工程合理有效地組織工程中的人員，管理工

4、程所需的各種資源和數(shù)據(jù)，并對任務進行分解，把工程按階段、活動、子活動逐漸往下細化分解，保證工程按照方案順利實施。而工程的數(shù)據(jù)和資源中，有相當大的一局部就是與工程有關(guān)的文件和圖檔，什么樣的文檔對應工程的哪個階段，工程的一個階段到另一個階段的過渡需要傳遞什么樣的文檔資料，為符合工程進展的實程流程，工程需作怎樣的改動，這都是在工程的組織階段完成的。    工程監(jiān)控是圍繞工程，跟蹤進度，掌握各項工作現(xiàn)狀，以便進行適當?shù)馁Y源調(diào)配和進度調(diào)整，確定活動的開始和結(jié)束時間，并記錄實際的進度情況，在一定情況下進行路徑、風險等方面的分析。在實施工程的過程中，要隨時對工程進行跟蹤監(jiān)控，以

5、使工程按方案規(guī)定的進度、技術(shù)指標完成，并提供現(xiàn)階段工作的反應信息，以利后續(xù)階段的順利開展和整個工程的完成。在監(jiān)控階段除了完成即時數(shù)據(jù)的實時監(jiān)控以外，再一項工作就是不同階段相關(guān)文件、圖檔的合理調(diào)配，怎樣才能把工程組織中歸納總結(jié)出的相關(guān)文檔在工程開展中合理有效的管理，怎樣在文檔管理中以一種適宜的狀態(tài)表征它與工程進展的關(guān)系，這些都是在工程管理的過程中不可無視的問題。    圖2.1為整個工程管理與文檔管理交互的流程圖。在工程的文檔在到電子倉庫提交的過程中，必須存在一個文檔傳遞的接口，通過這個接口，實現(xiàn)用戶在并不明確文檔處理過程的前提下，只是通過工程管理的操作平臺，選擇工

6、程的某個階段或者文檔的某些屬性，就可在當前頁面自由管理工程文檔。    在工程的整個生命周期中，涉及到的所有文檔最終都會以電子文檔倉庫的形式進行管理。具體的實現(xiàn)過程可以描述為：通過文檔分類共享接口，PM(工程管理)生成或者上傳工程生命周期的某個階段涉及的文檔，發(fā)出文檔檢入電子倉庫的請求給文檔分類共享接口，由接口分析文檔的性質(zhì)和相關(guān)必要屬性，比方工程編號、工程名稱、提交人、存儲在電子倉庫中的物理位置等，由這些屬性把工程對象和工程文件對象關(guān)聯(lián)起來，與些同時把工程對象涉及的信息映射到工程管理平臺，工程文檔對象映射到文檔管理平臺，它的性質(zhì)和屬性在文檔管理平臺之上又變成了文

7、檔管理的關(guān)鍵字段。由文檔管理對電子倉庫提出文檔管理的信息，由文檔管理模塊所得到的文檔關(guān)鍵字段作為進入電子倉庫的方向指針，最終在電子倉庫中以某種適宜的分類形式出現(xiàn)。    當要查看或者維護工程相關(guān)的文檔時，是上述過程的逆過程。與文檔檢入到電子倉庫對應的是文檔從的檢出。通過檢出操作把文檔信息歸結(jié)到文檔管理平臺，再由文檔管理分析文檔類別、狀態(tài)和文檔索求方的需求信息，確認后發(fā)出文檔提交給用戶的動作，在用戶的當前頁面直接顯示所要求文檔的所有相關(guān)資料，整個過程在幾秒鐘內(nèi)就可完成。 三、工程文檔在電子倉庫中的管理實現(xiàn)     工程文檔通過工程管理平

8、臺完成提交操作，由文檔管理實現(xiàn)文檔的檢入檢出以及分類，在電子倉庫一級實現(xiàn)工程文檔合理有效地管理，電子倉庫可以比擬方便地實現(xiàn)文檔的分布式管理與共享。新建文檔或者更新文檔提交在電子倉庫之前，首先要通過規(guī)那么對文檔進行檢查，只有符合操作權(quán)限的用戶才能訪問電子倉庫，所以用戶在工程管理對工程文檔進行處理時，是在一定權(quán)限下進行的。在發(fā)出工程文檔歸檔要求的同時，伴隨著系統(tǒng)對工程文檔相關(guān)的操作權(quán)限和用戶身份的驗證，在向文檔管理提交某工程文檔請求時，也離不開權(quán)限和用戶身份的管理，電子倉庫方面對權(quán)限和身份的要求，是通過它的規(guī)那么庫進行判斷，驗證通過，可以進行下一步操作。    可通過

9、面向?qū)ο蠹夹g(shù)，用模型化的方法把權(quán)限和身份方面的規(guī)定滲透到整個流程管理中。    圖3.1為從工程管理平臺提交文檔開始到進入電子倉庫管理的整個過程。從圖中可以看出，真正實現(xiàn)對工程文檔的精確指向是與電子倉庫的規(guī)那么約束和文檔根本信息庫的管理分不開的。由規(guī)那么約束集指定了權(quán)限和所對應的用戶，文檔根本信息庫記錄了與文檔相關(guān)的工程名稱、工程編號、流程階段、文檔狀態(tài)等，這些信息實際上起到了文檔定向指針的作用，通過它們組成工程標識的ID，從更深一層意義上縮小文檔搜索的范圍圈。    電子倉庫與文件實際存放的物理位置是直接相關(guān)的，在電子倉庫中實現(xiàn)了文

10、檔與其直接存放的物理位置的直接映像。文件路徑、文件分類一般是以文件夾的形式標識，借助系統(tǒng)平臺，按類別、按階段、按狀態(tài)分門別類地在數(shù)據(jù)庫中實現(xiàn)對所有文檔的記錄，當然包括與工程有關(guān)的所有文檔。 四、UML模型化流程描述     1、  UML(Unified Modeling Language)是一種標準的圖形化建模語言，是面向?qū)ο蠓治雠c設計的一種標準表示，是可視化的建模技術(shù)，定義良好、易于表達、功能強大且普遍使用，溶入了軟件工程領(lǐng)域的新思想、新方法和新技術(shù)。可以靈活地適用于描述任何類型的系統(tǒng)，而且適用于系統(tǒng)開發(fā)的不同階段。同時為面向?qū)ο蟮脑O計與開發(fā)中涌現(xiàn)出

11、的高級概念提供支持，強調(diào)了軟件在開發(fā)過程中對架構(gòu)、框架、模式和組件的復用。    UML的這些特性為現(xiàn)階段基于組件技術(shù)、Web技術(shù)的軟件集成平臺開發(fā)提供了統(tǒng)一的模型化表達，標準了軟件開發(fā)過程，降低了軟件開發(fā)的難度，從另一方面提高了軟件的質(zhì)量和可維護性。在通用PDM系統(tǒng)的開發(fā)過程中就是借助了UML的建模思想，對模塊間數(shù)據(jù)的共享和接口實現(xiàn)借助UML的靜態(tài)視圖和動態(tài)視圖描述，以一種產(chǎn)品“圖紙的方式整體上表達模塊間的交互性，這樣在具體代碼實現(xiàn)之前猶如制訂了各模塊間功能實現(xiàn)的標準，提高了模塊間的集成度。    工程文檔的管理是PDM中工程組織和

12、工程監(jiān)控中很重要的一局部。基于PDM的模塊化組織原那么，工程管理涉及的文檔是作為文檔管理的對象提交到文檔電子倉庫。在上文中已提到，從工程模塊到文檔電子倉庫中間主要有兩個操作動作：檢入和檢出，它們概括了工程文檔流的過程，在表達這個過程中，可以借助于UML的活動圖和類圖，從靜態(tài)和動態(tài)兩方面描述過程中涉及的數(shù)據(jù)和條件。    2、接口實現(xiàn)的活動圖    圖4.1為工程管理與文檔管理進行交互的活動圖。兩功能模塊的橋接是運用了在工程文檔管理中的檢入檢出關(guān)鍵字。在工程管理操作平臺上提供與文檔管理中相對應的文檔信息，把這些信息作為檢入檢出的關(guān)鍵條件

13、。當檢入檢出關(guān)鍵字通過了文檔管理的搜索或者操作要求時，由文檔管理模塊與文檔電子倉庫進行信息交互，把工程文檔作為普通的對象進行分類、歸檔或者提交等。    文檔的檢入過程是一個單向的過程，借助功能實現(xiàn)界面，訪問文檔管理底層，比方文檔的上傳或者修改的提交過程。文檔的檢出過程是一個雙向的過程，首先要借助功能實現(xiàn)界面提供文檔檢出的關(guān)鍵字，提交給電子倉庫，再由電子倉庫進行庫內(nèi)運算或處理，搜索出文檔或者作出無相關(guān)記錄的答復信息，與檢出關(guān)鍵字的信息一同通過功能界面返回給用戶，比方文檔的瀏覽、下載等。文檔管理涉及了私有文檔、公有文檔、歸檔文檔和廢棄文檔。某個工程文檔要歸結(jié)到哪種類

14、型，這是與檢入檢出關(guān)鍵字、系統(tǒng)進行的狀態(tài)、工作流程運行的階段相關(guān)連的。    工程文檔管理活動圖描述了工程文檔從工程管理經(jīng)由文檔管理到文檔電子倉庫的整個過程，流程明確，指向清晰，利于流程化的功能模塊實現(xiàn)。3、接口實現(xiàn)的類圖     在接口實現(xiàn)的活動圖根底上，借助于軟件開發(fā)的新技術(shù)很容易的實現(xiàn)接口的功能類圖。這里以活動圖描述的工程文檔更新流程為例說明實現(xiàn)接口的功能類圖。由活動圖看出，進行工程文檔更新有三條渠道：    在工程組織過程中還未進入工程工作流階段，針對某個工程某個階段某個文檔提出更新請求，首先要提

15、供文檔檢入關(guān)鍵字，同時隱式傳遞工程所處“未執(zhí)行狀態(tài)的條件，由文檔管理直接做出答復。    工程還未進行執(zhí)行階段，用戶可以隨時查看已經(jīng)制作或者整理完成的文檔，文檔審批、傳閱都不離開文檔的瀏覽。在審批、傳閱中如果發(fā)現(xiàn)不合實際或者不可行的文檔要提出修改要求，這樣再返回到文檔組織中的更新操作步驟重新制訂或者整理，和第一種情況一樣，還要隱式傳遞工程所處“未執(zhí)行狀態(tài)的條件。     工程監(jiān)控過程中，離不開在工程組織過程中組織歸納的分類文檔，工程從一個階段完成到另一個階段的激活之間都涉及到一些關(guān)鍵文檔作為任務激活決策點，所以離不開操作文檔，同樣也可

16、以提出對文檔進行更新的要求，更新的要求首先要提交給工程組織模塊，同時傳遞“工程進行中的執(zhí)行狀態(tài)，最后由工程組織完成工程的更新任務。        圖4.2為文檔更新的操作類圖。類圖的設計是基于Web技術(shù)的，把每一個鏈接頁面均看作一個流程中實現(xiàn)某種功能的類處理，利于流程表達。   類的轉(zhuǎn)移除了運用了Web的功能屬性link、submit、redirect等以外，還考慮了功能實現(xiàn)語義方面的要求，特別對于類到類的重定向，這里就必須考慮到一些隱藏條件是否成立。在圖4.2中有兩個重定向。  &#

17、160; 在工程流監(jiān)控過程中，提出了文檔的更新請求，把文檔更新請求標志pro_doc_edit_warm由false改為true后，頁面就重新定向于工程監(jiān)控效勞器頁。    工程監(jiān)控效勞器頁在監(jiān)測到pro_doc_edit_warm的值為true時，得出某工程有文檔更新需求，馬上定向于工程組織階段，對工程組織工作作進一步的調(diào)整。    文檔的更新可能還會涉及到文檔名稱、文檔狀態(tài)、文檔編號等的改變，通過類的操作可以把其中改變的值以顯示或者隱身的形式傳遞給電子文檔倉庫或者文檔信息管理數(shù)據(jù)庫。類圖可以繼續(xù)擴展流程，實現(xiàn)上面活動圖構(gòu)畫的工程文檔組織的過程。     4、小結(jié)    運用了活動圖和類圖的一局部例如，對工程文檔管理的流程從高層和低層兩方面進行了描述?；顒訄D把工程管理中所有涉及文檔的操作過程全部列出，這為類圖設計和組件調(diào)用提供了方便。類圖在文中只列出了工程文檔更新的一個子流程，在類圖中已經(jīng)對每個類涉及到的變量或者實現(xiàn)類的程序加了標識，程序員可以按類圖中統(tǒng)一的變量定義和程序?qū)蜻M行編碼，這樣就在實現(xiàn)數(shù)據(jù)共享方面做到了統(tǒng)一的規(guī)定，利于最后所有功能模塊在PDM功能平臺上的集成和模塊間的信息交互。&