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系统开发实施的指导模型，图2描述了集成产品元模型局部，主要描述了企业物料(这里主要指零部件)的信息组织结构，以及物料的加工制造过程，同时还包括使用的人员、工具等信息的组织情况，其中Manu Process表示加工制造过程，Manu Activity表示加工制造过程中的各个活动节点，PMR，DoMR和DrMR等的具体含义将在下文中进一步详细描述。
图2 集成产品元模型局部
3 基于集成产品元模型的增量式聚合开发实施方法
3.1 增量式聚合开发实施过程模型
增量式聚合开发实施是一个循环、迭代、持续优化的过程。图3描述了增量式聚合PLM系统开发实施过程模型，其中图3a描述了增量式聚合开发实施周期T的宏观过程，表示PLM系统和IPMM的增量式完善过程；图3b描述了开发实施的过程片段，表示某一时间段△tn内IPMM(△tn)模型驱动的PLM系统的聚合开发实施过程，其中内圆描述的是元模型驱动的原型系统开发，外圆描述的是原型系统的实施过程。当有新业务需求时，可先对IPMM(△tn)进行完善，包括新业务对象构建，新业务对象属性、行为构建，以及对象之间的联系建立(包括新对象之间，以及新对象与原有对象之间)，再通过元模型驱动的聚合方式实现软件系统与业务需求的同步。改进优化部分首先在开发阶段进行测试，原型系统稳定后，进入实施阶段的测试和运行，在实施运行过程中采集需求，再不断改进和优化驱动模型IPMM(△tn)，生成原型系统，在一个时间片段内循环迭代，从而达到反映企业特征的业务需求模型IPMM(△tn)和软件系统的完全同步，最终△tn这一阶段提交的IPMM(△tn)作为后续阶段△tn+1功能模块聚合开发实施的基础。
图3 增量式聚合PLM系统开发实施过程模型
3.2 增量式聚合开发实施过程形式化描述
可用形式化语言描述增量式聚合PLM系统开发实施过程，定义
ACP=<T，IPMM(△tn)，PLMS(△tn)>。 (1)
式中：ACP表示增量式聚合PLM系统开发实施，是一个三元组；T为项目的开发实施周期，T={△t1，△t2，△t3，…，△tn-1，△tn，△tn+1，…}，表示开发实施周期由各个时间片段组成；IPMM(△tn)为某一时间片段的集成产品元模型。
IPMM(△tn)=<ProM(0，△tn)，PreM(0，△tn)，ResM(0，△tn)，OrgM(0，△tn)>，△tn∈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×Phasei表示在生命周期Phasei阶段PLM系统对具体产品的产品模型视图元素的管理关系。同理，其他矩阵元素分别描述不同阶段PLM系统对具体产品不同视图相应阶段的管理。因此，矩阵列描述了在生命周期特定阶段PLM系统对具体产品不同视图的管理，矩阵行描述了PLM系统对具体产品的某一视图的全生命周期管理。
4 模型层次结构
IPMM作为系统实现的驱动模型，不仅要满足一定的语义规范，还要满足一定的业务规范。使用基于统一建模语言(Unified Modeling Language，UML)的元建模机制，不仅能满足语义规范要求，还能满足PLM系统的业务规范。即使用这种建模机制建立的反映企业特征的IPMM可以根据客户需求而相异，但描述PLM业务规范的元模型是一致的。结合PLM业务特性和IPMM的建模需求，本文在对象管理组织(Object Management Group，OMG)四个建模层次的基础上进行了修改，建立了的面向PLM系统的四层模型层次结构，如表2所示。
表2 四层模型层次结构
其中，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进行改进。
图4 元模型驱动的PLM系统实现过程
5 增量式聚合开发实施应用实例
在上海某重型机器厂的PLM系统开发实施项目中，本课题组设计了四种角色(用户、咨询顾问、系统分析员和开发人员)参与该项目，以下描述其增量式开发实施过程：
步骤1 根据已有经验和知识，利用UML创建了PLMM，同时对其他软件资源模型进行扩展，以满足系统集成的语义需求。
步骤2 咨询顾问负责与用户交流，逐步了解企业的业务需求。
步骤3 系统分析员将咨询顾问对企业的描述求精，使用UML，在PLMM业务规范约束下对PLMM具体化建立IPMM，如图5a和图5b所示，根据PLMM的PMR，MMR，DoMR，DrMR和MMD，DoMD，DrMD等语义，进行属性、行为的添加和配置，实例化出满足企业需求的零部件模型、产品结构模型等；根据Process，Activity，Rule，Resources，Role，Organizations，User等，实例化出企业不同的过程、资源、角色、人员组织情况，如零部件的设计过程、零部件的加工制造过程，以及相应的资源、角色、人员的使用模型。
图5 PLMM，IPMM和IPM转换实现过程
步骤4 根据初步得到的IPMM，开发人员把UML图形化描述的IPMM模型转换成可扩展标记语言(eXtensibleMarkup Language，XML)语言描述的模型。为支持模型驱动的增量式开发实施，课题组使用了MDA开发工具GeneXus，通过模型转换器在GeneXus中导入XML描述的IPMM，生成系统实现模型，得到原型系统，并在开发阶段进行初步测试。
步骤5 用户进行大量测试数据录入，从IPMM实例化出IPM，如图5c所示，描述了系统对部件-入口活套的信息管理。此时，可以测试系统对IPMM和IPM的管理能力，以及系统的稳定性、使用的方便性等指标和业务管理上存在的问题。
五个步骤在开发实施周期中不断循环，系统运行情况和客户新需求可以丰富经验和知识，优化PLMM，同时不断改进和完善IPMM及软件系统，体现出增量式开发的特性。而在一个循环内部，步骤2～步骤4主要描述了IPMM的构建和使用，步骤5描述了IPMM的运行，体现出IPMM的聚合特性。
在具体开发实施过程中，项目组在制定零部件属性时，开始只考虑了企业的内部情况，建立的零部件模型如图5b所示，这个模型通过MDA工具生成了原型系统中零部件数据结构和相应的管理功能。但在实施应用过程中发现，企业存在大量的外购件，而每种外购件因为供应商的差异，编码规则基本不一样。在此情况下，通常采用两种解决方案：直接采用外部供应商的编码；外部供应商的编码作为一个属性加入到PMR中，企业根据自己的编码规则再进行编码。项目组采用第二种方案，以便于企业内部零部件的分类、重用和检索。项目组建立了如图6所示的UML模型，通过MDA工具生成新的数据结构和管理功能，对系统其他部分没有影响，同时对企业原来测试和录入的零部件数据也没有影响，在此只需要在建模系统中建立相应的模型，经过一定的模型变换，导入到MDA工具中，就能100%生成相应的数据结构和代码，通过模型实现业务需求和软件系统的快速聚合。
图6 业务需求改变IPMM
目前，课题组在企业开发实施的物料清单(Bill of Material，BOM)管理功能模块已经通过最终测试在企业运行，而这一阶段提交的IPMM局部是后续采购、生产管理模块聚合开发实施的基础。
6 结束语
本文提出了面向PLM系统的增量式聚合开发实施方法，认为增量式聚合PLM系统开发实施的关键是IPMM。IPMM的构建不仅要满足业务规范约束，同时要成为系统实现的驱动模型，还要满足一定的语义规范。结合UML标准，提出了面向PLM环境下的四层元模型体系结构，使得IPMM不仅能满足UML语义和PLM业务规范，还能体现企业的个性化特征。增量式聚合开发实施方法是一种以客户需求为主导，注重用户参与度，功能模块逐步完善的方法。该方法能迅速获得企业的认可，提高客户满意度；同时，该方法遵循PLM业务规范原则和特性，能逐步实现PLM的效益。
本文主要从实现方法层对开发实施过程进行了描述，因为当前的标准建模语言UML语义尚未完备，同时现有的MDA工具还不足以支持增量式开发实施方法的一系列观念，所以在实际的开发实施过程中，还需要一部分的手工编码，随着UML的完善和MDA工具功能的增强，聚合开发实施效率将会显著提高。
转载请注明出处：拓步ERP资讯网http://www.toberp.com/
本文标题：面向产品全生命周期管理系统的增量式聚合开发实施方法研究
本文网址：http://www.toberp.com/html/consultation/10820218322.html
相关文章
