摘要


：


详细叙述了产品全生命周期产品结构和配置管理的概念、产品结构和配置管理系统的对象关系逻辑模型及其物理实现构架。




 





现代社会是一个崇尚个性化消费的社会，人们在选购产品时，除了注重产品基本功能、性能外，往往还会提出一些个性化要求。全世界许多大型制造业企业正面临大规模的产品制造与提供个性化的产品和服务之间的矛盾。





 





显然，基于互联网的信息系统为解决这样的矛盾提供了可能，电子商务可以在企业和消费者之间建立起一种信息的桥梁，然而，产品的信息贯穿于整个产品的设计、工艺规划、生产制造、采购与销售、售后服务过程，而且在这一过程中，产品又是处在不断改进和适应市场的变化之中，所以，如何保证产品信息传递的及时、可靠是实现真正意义上的电子商务的基础。于是，信息领域的专家提出面向产品全生命周期的产品信息管理



(


Product


 


Information


 


Overall


 


Lifecycle


 


Management

，


PLM



)



的概念，将以前面向产品设计部门的产品数据管理系统提升为为整个企业的生产经营服务的信息系统。





 





贯穿于产品全生命周期的产品结构与配置管理系统是

PLM

完整解决方案的关键技术之一，同时也是其他许多系统



(



如

ERP

，


CRM



)



需要的基本信息服务。本文将系统描述产品结构和配置管理系统的概念以及该系统核心部分的逻辑设计，然后结合当今一些热门的开发技术提出该系统在构架上的选择方案。





 





1




 





产品结构和配置管理系统的概念设计







结构和配置是对产品信息进行组织和管理的一种形式，它以网络数据库为底层支持，以物料明细表



(


Bill


 o


f


 


Material

，


BOM



)



为其组织核心，将用于描述产品的设计、工艺、制造的工程数据和文档联系起来，实现对产品信息的组织、管理和控制，并在一定目标或规则的约束下，向不同的用户或应用系统提供产品结构的不同视图和描述。





 





1.1




 





产品结构的管理







产品结构是对产品构成的描述。企业的许多信息资源中均显式或隐式地包含产品结构信息，如设计工程图中的装配图、装配明细表；工艺文件中的装配工艺规程；产品维护文档及用户手册中的产品装配爆炸图



(



形象地表达产品的装配过程或检修过程



)



等。





 





管理产品结构具有两个方面的目的：一方面，以产品结构为组织框架，可以很方便地对所有产品相关信息进行管理，有利于产品信息的组织和查询；另一方面，基于产品结构能提供统一的有关产品构成的信息描述，同时可以根据产品生命周期不同阶段的需要，提供有侧重点的信息服务。





 





为了达到上述目的，产品结构管理一般采用视图控制法，在某个产品结构的不同使用场景中，通过各种不同划分方法进行管理和描述。每个视图是一个管理对象，视图对象间可以根据一定的规则进行构件信息和结构信息的传递。每个构件可以与多个视图相关联，这样便能从同一个产品结构产生不同的视图。





 





例如，在产品设计时，设计人员产生了面向功能模块的设计视图；在进行工艺过程规划时，工艺人员在设计视图的基础上，加入工艺方面的相关信息，可以产生一个面向制造和装配的工艺视图；生产制造部门又可以在工艺视图的信息基础上，结合生产的实际情况，通过资源的优化组合，产生一个面向制造的视图；采购人员根据需要，在制造视图的基础上，可以产生关于外购件的采购视图；售后服务人员根据需要，可以产生面向技术支持和服务的维护视图。图

1

是产品结构多视图转换示意图。






 





图

1

产品结构的多视图转换





 





1.2

产品配置的管理







产品配置是同产品结构紧密相关的概念。按照国际标准

ISO10007

对配置管理的基本定义，配置是指对被描述在技术文档中或者体现在产品实际使用过程中的产品功能特性和物理特性所作的表示。这是从产品特性的角度对产品配置进行定义，相当于客户和销售部门使用的配置概念。例如某


PC


电脑的配置是


P



Ⅲ


800

，


256M


内存，


40G


硬盘，我们称之为配置需求。





 





由于对产品的特性需求最终是通过实际的产品结构来实现的，因此产品配置的结果是具体的产品结构视图。例如

PC

电脑最终的配件清单，我们称之为配置结果。





 





另外，配置也被看成是一个选择一组构件并维护其关系以形成一个设计解决方案来解决客户需求的过程，这时配置的概念相当于配置过程。配置的以上

3

种概念，是对配置这一概念从不同角度的理解，同时也是本管理系统进行逻辑设计的出发点之一，见图


2


。






 





图

2

产品配置的使用示意





 





2




 





产品结构和配置管理系统的逻辑模型







产品结构管理模型和产品配置管理模型之间有着紧密的联系。从产品结构角度看，涉及零部件的层次关系、零部件的版本以及零部件对象与描述零部件对象的产品数据的关联问题；从产品配置角度考虑，会涉及有关有效性、配置项及其多视图管理的问题。





 





2.




1




 





产品制造单元的层次化结构关系







层次式的产品结构划分方法指出了一个产品的零部件在设计方面和功能方面的联系。零件和部件是产品结构中的两个基本的构成对象，是产品设计工作的基础数据，其中包括产品开发过程中所需要的关于某个物品的重要信息。对于零件，产品结构表示了该零件所使用的制造资源或半成品。





 





制造资源既包括制造产品所需的材料，也包括制造产品所需的设备，甚至包含制造产品所需的工时等信息。利用制造资源和半成品对象，可以将工艺过程规划和采购方面的信息加入到产品结构中，使得产品结构信息更加完整，其应用范围也会更广，这样才能使产品结构信息在整个产品生命周期内都具有指导价值。





 





零件和部件对象间存在



n



：



m



的关系；同时，零件和原材料、半成品对象间也存在



n



：



m



的关系。这类关系为结构关系，见图

3

。






 





图

3

结构关系描述模型





 





2.




2.2




 





产品制造单元的版本信息







一个零件或部件可以有多个版本，这些版本是随着时间的推移，因排除问题或进行产品改进而形成的。零部件对象采用版本标记对零部件的版本进行区分。与版本无关的属性，如物品编号或名称等，在所有的零部件对象中始终不变。为了支持产品结构与配置管理中的版本管理，将零部件的属性分成与版本有关和与版本无关两种属性，即完整描述一个零部件的信息需用到两类数据，称之为零部件类和零部件唯一标识类。零部件唯一标识对象将与版本无关的各种属性动态地传送给相应的与版本有关的零部件对象。





 





一个零件、部件、制造资源或半成品都可以有多个版本，所以各自的唯一标识类和与版本有关的各类间存在

1

：



n



的关系。图

4

为唯一标识关系类模型。






 





图

4

唯一标识类模型





 





制造单元的版本的组织有

3

种形式：





·链式版本关系。对于对象各版本通过生成的先后顺序进行管理和维护，能反映版本之间的时间先后关系。




·树状版本关系。通过版本对象的继承、派生关系来组织对象各版本，能追溯每个版本的产生来源。在树状版本关系中，我们假定每个版本只能从一个父对象上派生。




·网状版本关系。如果考虑每个版本能从多个父对象上派生，那么该版本关系将在树状版本的基础上生成网状的版本关系。




 





2.3




 





产品制造单元的互换关系







产品结构分解中出现的产品零部件唯一标识对象之间存在着替换和互换的关系，这种关系称之为替换关联信息和互换关联信息，表征了企业中经常用到的互换件和替换件的关系。制造资源、半成品唯一标识对象间存在的关系类为替换关联类和互换关联类，描述了零件生产中出现的制造资源或半成品唯一标识类之间存在替换和互换的关系，在企业中通常表现为可以互换的材料或可以互换的制造设备等关系。对象之间的这种可替换关系往往被一些条件约束。图

5

为互换关联模型。






 





图

5

互换关联模型





 





2.4




 





产品制造单元的配置







为了快速、自动地实现在众多的、复杂的互换或替换关系中选择合适的产品制造单元，从而形成完备且必要的产品结构信息，必须提供配置过程处理和配置信息的管理。可以在系统中添加配置条件对象、配置规则对象和配置处理对象。配置条件对象是对配置需求的一种抽象，它将用户对产品可能提出的配置需求分类，不同的分类又可有不同的取值。在不同的分类变量之间，用户可以定义与、或、非的关系。图

6

为配置条件模型。






 





图

6

配置条件模型





 





配置规则对象是对产品结构配置规则集的抽象。首先，配置规则对象是建立在具体的可互换标识对象之上的，实际上是对可互换标识对象的互换规则说明。每个配置规则对象是一些配置规则项对象的集合，每个配置规则项对象包含所引用的配置变量对象在某个取值状态下可选的唯一标识对象集合。图

7

为配置规则对象模型。






 





图

7

配置规则对象模型





 





配置处理对象是对配置过程的一种抽象，配置处理对象接受某个可互换标识对象作为输入条件，以某个配置规则对象集作为支持条件，受到某个配置条件对象和产品结构视图类型的控制，最后产生一个产品结构的视图对象为配置结果。图

8

为配置处理功能图



(


IDEF0


)



。






 





图

8

配置处理功能图





 





图

8

所示配置处理功能图的表示形式最初出现在美国空军


ICAM



(


Integrated


 


Computer


 


Aided


 


Manufac


-


turing


)



工程在结构化分析方法的基础上发展的一套系统分析和设计方法中，称为

IDEF

方法



(


ICAM


 


defini


-


tion


 


method

的缩写



)



。

IDEF0

是


IDEF


的第一部分，用于描述功能模型。





 





3 





产品结构与配置管理系统的物理构架






(


1


)



从系统的可用性角度考虑。






由于该系统所解决的问题贯穿于产品的全生命周期，系统的使用可能是跨地域的，所以该系统必须构架在一种分布式的互联网体系平台上。






系统的某些功能集中在一个部门中使用，如产品结构视图的维护，一般在企业的设计和工艺部门使用；有些功能又需要跨地域使用，例如产品结构的查询，可能被各种不同的用户或与之集成的其他信息系统使用。所以该系统必须能同时支持同步处理和异步处理功能，能适应连接数据环境和非连接数据环境的使用状况，并支持大事务的处理。






由于系统的使用终端平台可能是不同的，如何支持跨平台的程序部件调用是一个值得注意的问题。





 




(


2


)



从系统的性能角度考虑。






由于产品结构数据的伸缩性比较大，有些产品可能只由几个零部件组成，有些产品则由成千上万个零部件组成，加上制造资源和半成品数据，一个完整的产品结构数据可能是海量的。所以系统对底层的数据库支撑平台的伸缩性要求比较强，最好能从数据库底层解决数据库的分布式问题，同时系统的运行部件在部署时也可能是分布的。





 




(


3


)



从系统的可维护性角度考虑。






由于系统可能比较庞大，所以系统必须使用统一的容错、报错处理机制，特别是对于一些服务部件必须提供必要的错误恢复机制。在选择开发技术时，有必要对该技术对于上述机制的支持能力加以分析。此外，系统的升级应该是容易和快速的。





 




(


4


)



从信息集成的角度考虑。






从两个方面来考虑集成：第一，要对本系统提供的服务进行粗粒度的、组件化的封装，便于以较少的工作量实现动态集成；第二，与其他系统的集成应该是松耦合的。





 





为了满足以上要求，我们选择了两种技术方案作为该系统的构架。





a.


J2EE(


Java


(


tm


)


2P


latform

，


Enterprise



 


Edi


-


tion


)



的解决方案





J2EE



是一个以

Java

技术为基础的多层应用程序构架，也是被众多厂商支持的一种技术规范和平台。



J2EE



的体系结构见图

9

。






 





图

9


J2EE



的体系结构





 





从图

9

可以看出，组件化的系统实现方案的优势几乎在



J2EE



都有体现，



J2EE



中的

EJB

组件



(


Enter


-


prise


 


Java


 


Beans


(


tm


)


Components


)



是用来处理业务逻辑的关键；数据访问部件

JDBC


(


Java


 


Database


 


Connec


-


tion


)



用于访问数据库；事务处理部件

JTA


(


Java


 


Trans


-


action


 


Management


 


Application


)



用于处理大的事务，并保证事务的原子性；消息处理部件

JMS


(


Java


 


Message


 


Server


)



用于处理消息，以支持异步的信息处理，满足在不持续的网络连接环境中的信息处理。





 





由于



J2EE



采用

Java

技术作为基础技术，所以能很好地支持跨平台，对系统的安全有比较全面的考虑，这是



J2EE



的优势，同时



J2EE



是一种开放的体系结构，所有的底层技术都可对外公开，这对于注重信息安全的金融系统和航空、航天以及其他国防部门而言是一个好的选择。





 




b.


.Net


 


Framework

的解决方案





.Net


 


Framework

是微软最新的解决分布式网络应用的一种构架



(



图

10


)



，可以认为是对

WinDnA


(


Windows


 


Distributed


 N


etwork


 


Application


)



的全面改造和升级。



.Net


 


Framework

与



J2EE



比较类似。






 





图

10


.Net


Framework

的应用解决方案





 




.Net


 


Framework

的显著特点是提出了一种


CLR



(


Common


 


Language


 


Runtime


)



的概念，它提供了一套更可靠的代码执行管理机制和运行环境，同时从理论上解决了



.Net


 


Framework

跨平台的问题。同



J2EE



相比，



.Net


 


Framework

还可以保持一种编程语言的中立，换句话说，



.Net


 


Framework

支持多种编程语言，只要编译器将源代码翻译为


Microsoft


中间语言



(


MSIL


)



即可，

MSIL

是一组可以有效地转换为本机代码且独立于


CPU


的指令。微软推荐使用


C



#



语言作为



.Net


 


Framework

的开发语言。



.Net


 


Framework

的优势在于开发工具的多样性和开发效率比较高。





 





同



J2EE



一样，



.Net


 


Framework

支持


Web


服务，


Web


服务是一种分布式的计算模式，它是粗粒度的，又是松耦合的，见图


11


。


Web


服务由于使用超级文本传输协议


HTTP



(


s


)



，所以可以穿过防火墙；

Web

服务通过使用扩展标记语言



(


XML


)



的元数据



(


Meta


 


data


)



描述内容，并通过通用的目录服务来查找。






 





图

11Web

服务的工作示意图





 





这样的一个

Web

服务技术方案，满足了解决本系统要考虑的所有基本技术问题。可以认为，面向产品全生命周期的产品结构和配置系统不仅能作为一个软件产品来为某些大企业、大集团服务，甚至可以作为一种


Web


形式的信息服务平台来向大多数中小企业提供。





 





4




 





结束语







在用信息化来改造传统工业的过程中，信息化产业本身面临一种挑战，即信息化产业的工业化。目前，有些信息化企业片面追求大而全的发展思路，这阻碍了信息化产业的进一步细分，不能充分发挥各企业在各自领域的专业优势。我们相信，在一种整体集成方案构架下的专业服务系统，是信息化带动工业化的发展过程中的新生力量，它将带动信息化产业向更为合理的专业细分的方向发展。





 




 





                                                            

                    

                                                    来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/31532639/viewspace-2641626/，如需转载，请注明出处，否则将追究法律责任。
                                            

                
转载于:http://blog.itpub.net/31532639/viewspace-2641626/

产品生命周期
是产品从产生到消亡的全生命周期过程

包括构思阶段+研制阶段+使用维护阶段

包括概念，计划，开发，验证，发布，运维标准六阶段


项目生命周期
是项目从产生到消亡的全生命周期过程

多个项目阶段的组合形成项目生命周期

包括CDIT四个阶段(PMBOK2000)





阶段的作用
控制风险(评审，审查)

目标可视(进度，成本，质量)

方便监控(里程碑)
项目干系人
在现在或将来进行影响

对项目目标或执行过程造成影响

消极或积极的影响
过程-Process
过程就是为了完成一系列预先指定的产品，服务或成果而需执行的相互联系的行动和活动。

过程是一系列为达到某既定目标的实践；包括了工具、方法、资源和人。



项目管理五大过程组
项目管理是通过应用和综合诸如启动、计划、执行、控制和收尾等项目管理过程来进行的。

1、市场营销学定义的产品生命周期为：导入、成长、成熟、

衰退。这个已经不能概括产品生命周期的全过程。就像人的生命周期也绝对不会是从出生着地到死亡的过程。我们把这个四个阶段定义为：产品市场生命周期。
2、随着PLM软件的兴起，产品生命周期开始包含需求收集、概念确定、产品设计、产品上市和产品市场生命周期管理。就像人的生命周期把父母前期的准备和孕育的过程、分娩的过程也定义到人的生命周期。
3、近现代很多优秀的企业觉得上述两种生命周期并不能完全的概括产品生命周期。在基于产品管理概念的基础上把产品生命周期概括为：产品战略、产品市场、产品需求、产品规划、产品开发、产品上市、产品退市生命周期管理7个部分。
转载于:https://www.cnblogs.com/jiangtao1218/p/8640644.html

生命周期的含义
生命周期就是指一个对象的生老病死。

生命周期（Life Cycle）的概念应用很广泛，特别是在政治、经济、环境、技术、社会等诸多领域经常出现，其基本涵义可以通俗地理解为“从摇篮到坟墓”（Cradle-to-Grave）的整个过程。对于某个产品而言，就是从自然中来回到自然中去的全过程，也就是既包括制造产品所需要的原材料的采集、加工等生产过程，也包括产品贮存、运输等流通过程，还包括产品的使用过程以及产品报废或处置等废弃回到自然过程，这个过程构成了一个完整的产品的生命周期。

在传统的Java应用中，bean的生命周期很简单，使用Java关键字 new 进行Bean 的实例化，然后该Bean就能够使用了。一旦bean不再被使用，则由Java自动进行垃圾回收。

相比之下，Spring管理Bean的生命周期就复杂多了，正确理解Bean的生命周期非常重要，因为Spring对Bean的管理可扩展性非常强，下面展示了一个Bean的构造过程

Spring中Bean的生命周期
Bean 的生命周期


如上图所示，Bean 的生命周期还是比较复杂的，下面来对上图每一个步骤做文字描述:
Spring启动，查找并加载需要被Spring管理的bean，进行Bean的实例化

Bean实例化后对将Bean的引入和值注入到Bean的属性中

如果Bean实现了BeanNameAware接口的话，Spring将Bean的Id传递给setBeanName()方法

如果Bean实现了BeanFactoryAware接口的话，Spring将调用setBeanFactory()方法，将BeanFactory容器实例传入

如果Bean实现了ApplicationContextAware接口的话，Spring将调用Bean的setApplicationContext()方法，将bean所在应用上下文引用传入进来。

如果Bean实现了BeanPostProcessor接口，Spring就将调用他们的postProcessBeforeInitialization()方法。

如果Bean 实现了InitializingBean接口，Spring将调用他们的afterPropertiesSet()方法。类似的，如果bean使用init-method声明了初始化方法，该方法也会被调用

如果Bean 实现了BeanPostProcessor接口，Spring就将调用他们的postProcessAfterInitialization()方法。

此时，Bean已经准备就绪，可以被应用程序使用了。他们将一直驻留在应用上下文中，直到应用上下文被销毁。

如果bean实现了DisposableBean接口，Spring将调用它的destory()接口方法，同样，如果bean使用了destory-method 声明销毁方法，该方法也会被调用。

参考：https://www.cnblogs.com/javazhiyin/p/10905294.html