0 引言

目前，產品全生命周期管理(Product Lifecycle Management system，PLM)系統吸引了全世界的廣泛關注，相對于比較成熟的產品數據管理(Product Data Management，PDM)系統和企業資源計劃(Enterprise Resource Planning，ERP)系統而言，PLM系統對產品的管理在時間、空間和深度方面都有了擴展：在時間上覆蓋了從設計到處理等階段；在空間上橫跨職能的、地理的和組織的邊界；在深度上涵蓋全生命周期的產品定義，包括所有與產品相關的資料和過程。表1闡述了ERP系統、PDM系統和PLM系統管理對象和軟件系統的特性。

表1 ERP系統、PDM系統、PLM系統的特性

PLM系統的實現功能復雜，且每個企業實現PLM的需求不同，目前市場上所提供的解決方案，無法以明晰的方式使企業順利導入PLM系統。由此可見，傳統的ERP，PDM等系統開發實施方法，如二次開發、功能模塊、組件的參數化配置，已不能滿足PLM系統客戶化程度高，并支持持續改進的需求；同時，傳統的系統開發實施都是從凍結某一階段的業務需求開始，經過分析、設計、編碼和測試，最后提交針對先前凍結了的業務需求的信息系統，這種方法拉大了業務需求與信息系統之間的距離，使得信息系統的演進遠落后于業務需求的變更。本文根據聚合理論和PLM系統的特性，提出了基于集成產品元模型(Integrated Product Meta Model，IPMM)的增量式聚合PLM系統開發實施方法，它以客戶需求為主導，使PLM系統漸進滿足客戶的業務需求。

1 增量式聚合

本文提出的增量式聚合中的“增量式”是指開發實施是一個階段化、螺旋上升的過程，因為穩定清晰的業務流程實際上是不存在的，同時在實際開發實施過程中也不可能一次全部了解客戶需求，所以整個系統的開發實施在部分需求清楚的情況下就開始進行開發實施，在行進的過程中逐步挖掘新需求，逐步增加和完善系統功能。因為系統功能是通過IPMM驅動實現的，所以在開發實施過程中，模型也存在逐步增加、完善的增量式過程。

“聚合”的核心思想就是充分利用面向對象技術，在業務系統和信息系統之間建立靈活的對應關系，把業務系統和信息系統融為一體，從而實現兩者的同步演化，開發出真正能支持業務營運的信息系統。本文提出的“聚合”是基于IPMM的聚合，IPMM是一個整體模型，而企業業務和軟件是該模型的兩個層面，在“Build Time”階段，主要體現業務特性到軟件模型的過渡，在“Run Time”階段，是軟件特性逐步實現業務需要，即在模型的設計構建、使用階段，IPMM指導和驅動系統的生成，而在運行階段，系統通過IPMM實現PLM，同時在運行過程中可以發現問題，指導IPMM重構，如圖1所示。在具體的開發實施過程中，本文通過IPMM兩方面特性的融合，結合模型驅動架構(Model Driven Architecture，MDA)理念和工具，實現業務需求和軟件系統的同步。

圖1 集成產品元模型的二維特征

2 集成產品元模型

IPMM面向企業需求，是產品元模型、過程元模型、組織元模型和資源元模型的集成。其中，產品元模型是企業所有幾何、技術、生產、銷售、維護等方面產品信息元素的集成；而過程元模型是產品形成過程中所有活動元素的集成，它定義了產品各階段元模型的形成過程，以及與組織元模型、資源元模型的關聯關系，它按并行化和集成化的思想來組織業務過程。IPMM是生命周期內產品相關的所有信息和過程的載體，其宗旨是確定產品各階段相關數據、過程、使用工具等信息，以及這些信息之間的有機關聯，可以把IPMM作為增量式聚合PLM系統開發實施的指導模型

3 基于集成產品元模型的增量式聚合開發實施方法

3.1 增量式聚合開發實施過程模型

增量式聚合開發實施是一個循環、迭代、持續優化的過程。當有新業務需求時，可先對IPMM(△tn)進行完善，包括新業務對象構建，新業務對象屬性、行為構建，以及對象之間的聯系建立(包括新對象之間，以及新對象與原有對象之間)，再通過元模型驅動的聚合方式實現軟件系統與業務需求的同步。改進優化部分首先在開發階段進行測試，原型系統穩定后，進入實施階段的測試和運行，在實施運行過程中采集需求，再不斷改進和優化驅動模型IPMM(△tn)，生成原型系統，在一個時間片段內循環迭代，從而達到反映企業特征的業務需求模型IPMM(△tn)和軟件系統的完全同步，最終△tn這一階段提交的IPMM(△tn)作為后續階段△tn+1功能模塊聚合開發實施的基礎。

3.2 增量式聚合開發實施過程形式化描述

可用形式化語言描述增量式聚合PLM系統開發實施過程，定義

ACP=<T，IPMM(△tn)，PLMS(△tn)>。 (1)

式中：ACP表示增量式聚合PLM系統開發實施，是一個三元組；T為項目的開發實施周期，T={△t1，△t2，△t3，&hellip;，△tn-1，△tn，△tn+1，&hellip;}，表示開發實施周期由各個時間片段組成；IPMM(△tn)為某一時間片段的集成產品元模型。

IPMM(△tn)=<ProM(0，△tn)，PreM(0，△tn)，ResM(0，△tn)，OrgM(0，△tn)>，△tn&isin;T。 (2)

式中：ProM(0，△tn)表示在開發實施周期某個時間片段，由各種對象元素構成的產品元模型視圖；PreM(0，△tn)，RegM(0，△tn)，OrgM(0，△tn)分別表示相應的時間片段，由各種不同對象元素構成的過程模型元視圖、組織元模型視圖和資源元模型視圖。PLMS(△tn)表示某一時間片段的軟件系統，則

PLMS(△tn)=C(IPMM(△tn))。 (3)

式中：C表示某一時間段基于IPMM(△tn)驅動的PLMS(△tn)的開發實施，經過一定周期T的增量式聚合，最終，PLM系統對IPMM實例-具體產品的全生命周期管理，可用矩陣A表示：

式中：Pro&times;Phasei表示在生命周期Phasei階段PLM系統對具體產品的產品模型視圖元素的管理關系。同理，其他矩陣元素分別描述不同階段PLM系統對具體產品不同視圖相應階段的管理。因此，矩陣列描述了在生命周期特定階段PLM系統對具體產品不同視圖的管理，矩陣行描述了PLM系統對具體產品的某一視圖的全生命周期管理。

4 模型層次結構

IPMM作為系統實現的驅動模型，不僅要滿足一定的語義規范，還要滿足一定的業務規范。使用基于統一建模語言(Unified Modeling Language，UML)的元建模機制，不僅能滿足語義規范要求，還能滿足PLM系統的業務規范。即使用這種建模機制建立的反映企業特征的IPMM可以根據客戶需求而相異，但描述PLM業務規范的元模型是一致的。結合PLM業務特性和IPMM的建模需求，本文在對象管理組織(Object Management Group，OMG)四個建模層次的基礎上進行了修改，建立了的面向PLM系統的四層模型層次結構。

其中，PLM元模型(Pro duct Lifecycle Management Meta-Model，PLMM)使用的每種元素是通過UML元模型定義的，UML元模型由元對象機制(Meta Object Facility，MOF)構造的實例構成，PLMM是比IPMM更高層次的抽象，它定義了面向PLM的企業業務對象和數據對象的描述元素，以及元素之間的關系和交互行為等，為其實例IPMM在語法和語義上提供了簡單、一致、通用的定義性說明。使用PLMM能避免直接建模的復雜性，同時保證IPMM的正確性和建模的效率。以下對PLMM的部分元素進行說明。

零件主記錄(Part Master Record，PMR)在產品模型中，部件和零件分別具有各自的PMR；模型主記錄(Model Master Record，MMR)記載與零部件有關的二維、三維模型業務數據；文檔主記錄(Document Master Record，DoMR)描述與零部件有關的資料文件如訂單、需求說明、NC文檔，生產信息，采購信息等業務數據；工程圖主記錄(Draft Master Record，DrMR)描述與零部件有關的工程圖業務數據。模型元數據(Model Meta-Data，MMD)描述與零件有關的模型屬性；文檔元數據(Document Meta-Data，DoMD)描述與零部件有關的文檔屬性；工程圖元數據(Draft Meta-Data，DrMD)描述與零部件有關的工程圖屬性。

集成產品模型(Integrated Product Model，IPM)是IPMM的實例，是受PLM系統管理的具體產品的所有相關信息。圖4描述了各種模型的建立和使用過程，IPMM的建立受UML語義和PLMM業務規范的指導，通過模型轉化導入MDA工具，由MDA工具實現PLM系統，同時IPMM又受PLM系統的管理，系統通過IPMM在產品形成過程中實例化出IPM，PLM系統在運行過程中的需求可以直接返回IPMM，對IPMM進行改進。

5 增量式聚合開發實施應用實例

在上海某重型機器廠的PLM系統開發實施項目中，本課題組設計了四種角色(用戶、咨詢顧問、系統分析員和開發人員)參與該項目，以下描述其增量式開發實施過程：

步驟1 根據已有經驗和知識，利用UML創建了PLMM，同時對其他軟件資源模型進行擴展，以滿足系統集成的語義需求。

步驟2 咨詢顧問負責與用戶交流，逐步了解企業的業務需求。

步驟3 系統分析員將咨詢顧問對企業的描述求精，使用UML，在PLMM業務規范約束下對PLMM具體化建立IPMM，根據PLMM的PMR，MMR，DoMR，DrMR和MMD，DoMD，DrMD等語義，進行屬性、行為的添加和配置，實例化出滿足企業需求的零部件模型、產品結構模型等；根據Process，Activity，Rule，Resources，Role，Organizations，User等，實例化出企業不同的過程、資源、角色、人員組織情況，如零部件的設計過程、零部件的加工制造過程，以及相應的資源、角色、人員的使用模型。

步驟4 根據初步得到的IPMM，開發人員把UML圖形化描述的IPMM模型轉換成可擴展標記語言(eXtensibleMarkup Language，XML)語言描述的模型。為支持模型驅動的增量式開發實施，課題組使用了MDA開發工具GeneXus，通過模型轉換器在GeneXus中導入XML描述的IPMM，生成系統實現模型，得到原型系統，并在開發階段進行初步測試。

步驟5 用戶進行大量測試數據錄入，從IPMM實例化出IPM，此時，可以測試系統對IPMM和IPM的管理能力，以及系統的穩定性、使用的方便性等指標和業務管理上存在的問題。

五個步驟在開發實施周期中不斷循環，系統運行情況和客戶新需求可以豐富經驗和知識，優化PLMM，同時不斷改進和完善IPMM及軟件系統，體現出增量式開發的特性。而在一個循環內部，步驟2～步驟4主要描述了IPMM的構建和使用，步驟5描述了IPMM的運行，體現出IPMM的聚合特性。

在具體開發實施過程中，項目組在制定零部件屬性時，開始只考慮了企業的內部情況，建立的零部件模型如圖5b所示，這個模型通過MDA工具生成了原型系統中零部件數據結構和相應的管理功能。但在實施應用過程中發現，企業存在大量的外購件，而每種外購件因為供應商的差異，編碼規則基本不一樣。在此情況下，通常采用兩種解決方案：直接采用外部供應商的編碼；外部供應商的編碼作為一個屬性加入到PMR中，企業根據自己的編碼規則再進行編碼。項目組采用第二種方案，以便于企業內部零部件的分類、重用和檢索。

目前，課題組在企業開發實施的物料清單(Bill of Material，BOM)管理功能模塊已經通過最終測試在企業運行，而這一階段提交的IPMM局部是后續采購、生產管理模塊聚合開發實施的基礎。

6 結束語

本文提出了面向PLM系統的增量式聚合開發實施方法，認為增量式聚合PLM系統開發實施的關鍵是IPMM。IPMM的構建不僅要滿足業務規范約束，同時要成為系統實現的驅動模型，還要滿足一定的語義規范。結合UML標準，提出了面向PLM環境下的四層元模型體系結構，使得IPMM不僅能滿足UML語義和PLM業務規范，還能體現企業的個性化特征。增量式聚合開發實施方法是一種以客戶需求為主導，注重用戶參與度，功能模塊逐步完善的方法。該方法能迅速獲得企業的認可，提高客戶滿意度；同時，該方法遵循PLM業務規范原則和特性，能逐步實現PLM的效益。

本文主要從實現方法層對開發實施過程進行了描述，因為當前的標準建模語言UML語義尚未完備，同時現有的MDA工具還不足以支持增量式開發實施方法的一系列觀念，所以在實際的開發實施過程中，還需要一部分的手工編碼，隨著UML的完善和MDA工具功能的增強，聚合開發實施效率將會顯著提高。