1 PDM系统的建模方法和建模语言

1.1 PDM系统的建模方法
通常，一个大型且复杂的信息系统很难直接对它进行分析设计，所以，我们经常借助构建对象模型的方法来分析和设计系统。系统模型一般不是系统对象本身，而是现实系统的描述、模仿或是抽象。在系统的建立过程中，模型是开发过程中一个不可缺少的元素。

 
模型的构造是为了帮助人们分析和研究问题，采用合适的建模方法能够在模型的构建过程中起到事半功倍的作用。目前系统建模有许多通用的方法，比较著名的有:实体联系(E/R)法、IDEF方法和面向对象(Object-Oriented  00)系统建模方法等。针对PDM系统管理的数据涉及到产品的整个生命周期，数据繁多、过程复杂，并且要求与相关的应用系统进行数据的交互和集成等方面。因此，我们采用现阶段应用最为广泛也是最为直接、简单易懂的面向对象的建模方法对PDM系统进行模型的构建。

 
面向对象技术具有分解、抽象、模块化和信息屏蔽等特点，该技术可以有效地提高软件的质量和生产效率、缩短软件开发时间、降低软件复杂性。面向对象的基本思想是将问题域进行自然的分割，以更接近人类的思维方式建立系统问题域的模型，从而实现对客体在结构上和行为上的模拟，使得设计出的软件尽可能全面的体现实际问题的需求，具有良好的可维护性、可重用性，满足了用户多变的需求。近年来，面向对象技术得到了广泛的应用和良好的发展，至今已形成了面向对象的分析(OOA)、面向对象的设计(OOD)、面向对象的编程(OOP)、面向对象的测试(OOT)和面向对象的软件维护(OOM)等一系列发展成熟的面向对象的系统开发技术。

 
协同设计环境下的PDM系统涉及庞大的数据信息种类不一且相互之间的关系错综复杂、对数据的操作多种多样，导致了PDM系统的复杂程度极高。在这种情况下，本文采用面向对象的分析和建模方法对系统进行建模分析。采用面向对象的信息描述方法对PDM系统问题域的信息进行了高度的抽象，将所有相关数据和过程定义为对象，通过对对象之间关系的配置来表示实际环境下的数据结构。

 
模型用对象、关系、功能转化和动态控制流等方法进行功能描述，并且将不断获取地需求信息与和客户的交流贯穿在整个分析的过程中。在系统结构中采用组件技术，可以尽量实现系统功能模块化，并围绕系统中对象的设计建立相应的数据库。只有这样才能使得面向对象贯穿整个系统的开发过程，也使得系统具有了良好的通用性、可扩展性和较强的数据描述能力，从一定的程度降低了系统的复杂程度，与此同时，也保证了系统的易维护性和可靠性。

 
1. 2 PDM系统的建模语言
在本论文的以下章节中，都采用的是面向对象的统一建模语言((Uniformed Modeling Language，UML)来分析和描述系统中的对象和对象之间的关系。用UML可以有效地模拟对象结构和行为，其中对象结构也就是静态模型集中关注的是对象的类、属性及对象之间的关系。行为模型也就是动态模型则是强调对象之间的相互合作、相互作用及其之间的变化情况。
 

作为一种建模语言，UML的定义包括UML语义和UML表示法两部分。
    (1) UML语义:描述的是基于UML的精确元模型定义。元模型为UML的元素在语法和语义上提供简单、一致、通用的定义性说明，消除了因人而异的表达方法所造成的影响，使开发者能在语义上取得一致。
 
    (2)UML表示法:定义UML符号的各类表示方法，在语义上UML表示法是UML元模型的实例。UML为系统建模的开发者使用这些图形符号和文本语法提供了标准。与其它对象模拟方法相比，UML有如下优点:

    (1) UML可以贯穿软件开发周期中的每个阶段，并且UML语言统一了对象模拟的标记和含义，被OMG采纳为国际软件工业界广泛认可的标准，使得软件工具发挥出更大的效用。
 
    (2) UML提供了多种类型的模型描述图，使得在某种给定的方法学中使用这些图时，系统开发中的应用程序变得易于理解。最常用的UML图有:用例图、类图、序列图、状态图、活动图、组件图和部署图。本论文在后面章节进行建模时主要采用系统用例图和时序图表示。
 
    (3)目前，出现了支持UML面向对象建模的计算机辅助软件工程工具，比较成熟的有:Sybase推出的Power Designer、美国Rational公司推出的Rational Rose、微软公司推出的Visual.Net系列中的Visio等。在后续章节中，本文将使用UML语言作为面向对象的分析与描述工具，对PDM系统中的各类子系统进行详细的设计。
 

2基础数据管理功能分析与设计
2.1图文档管理(Blueprint Document Management)
将产品信息载体的图文档作为管理对象，确保产品数据的一致性、完整性和安全性。图文档的管理包括对图文档的各种操作和版本的记录，系统用户在图文档创建窗口下建立图文档，需要填写图文档创建的元数据，之后保存在数据库中。主要属性描述有:图文档编号、图文档名称、图文档类型、图文档创建者、图文档创建口期、最近修改口期、存档口期、图文档审核人员、图文档审核口期、图文档版本号、访问状态、所属项目编号、所属任务编号、存储类型、描述、存储位置、格式、文件大小、备注等。
 

填写完成之后要签入系统的数据库中，当系统用户要修改图文档信息时，可以从数据库中提档，这时系统需对所提取的图文档进行冻结，禁止其他用户对其执行签出操作。主要操作有:图文档的创建、编辑、修改、删除、审核、查询、签入和签出等操作。
 

2.2扫描和图像处理(Scanning And Blueprint Handle)
扫描是将图纸或微缩胶片通过扫描设备将其输入转换成数字化图像，并提供了点阵图形和矢量图形混合编辑功能。主要操作有:扫描、图像数字化、编辑、审核、删除、签入；主要实现了与外界扫描设备的接口操作。

 
图像处理是用户可以分别对扫描图像或现有图像和进行各种处理，支持图像审核、圈阅操作的红线圈点和图形覆盖技术。通过对扫描输入的已有的图纸进行二次开发与修改，大大提高了设计效率。主要操作有:图像签出、编辑、修改、删除、审核、签入等操作。
 

2.3浏览查询审核圈阅(Browse Inquiry Verify Comment)
浏览、查询、审核、圈阅是分布式产品开发系统文档审批流程的一个重要支持工具。主要包括查看各种格式的文本文件及其图像，包括STEP， IGES， DWG等；支持流行的CAD软件对系统类型文件的查阅；用户能够利用红线圈点或图形覆盖技术对文件进行圈阅和注释；支持第三方软件的查看。主要操作有:浏览、查询、审核、圈阅等操作。
 

2.4版本管理(Version Management)
版本管理是以产品设计流程的定义和实现而随之产生存在的，它跟踪并记录产品在设计流程中的每个数据采样点中不同的设计状态信息。对于版本的管理不仅包括特定设计阶段的版本管理还包括许多非特定时间段的中间设计结果的版本管理。版本管理将文档和图纸文件的历史记录保存下来，以备随时调用和更新。当开发工作完成、版本不再发生变化时，该工作版本将被冻结。对于新设计项目的构思和创建是基于层次网络模型实现的，它能有效地满足用户保存和读取所需要的历史信息的要求，实现文档图纸文件的可追溯性。
 

版本属性描述有:版本编号、版本名称、版本类型、关联文档编号、关联文档名称、版本最近修改口期、关联图纸编号、关联图纸名称、版本创建口期、版本归档口期、继承关系、父版本号、子版本号、所属项目编号、存储类型、存储位置、备注等。主要操作有:版本的创建、编辑、修改、审核、删除、签入、签出、冻结等操作。
 

3产品结构与配置管理功能分析与设计
3.1产品结构管理(Product Structure Management)
产品结构管理不仅能够描述和反映产品结构的构成关系，而且还能够描述和反映产品数据对象之间的关系以及一个产品资料的各个版本之间的关系。产品结构关系成树状管理方式，反映了产品零部件之间的层次和隶属关系。主要操作有:产品结构树的展现，并可对产品结构树中的产品、部件、零件和特征对象的创建、编辑、修改、删除、审核、替换等操作。
 

3.2产品配置管理(Product Configuration Management)
产品配置管理分为两个方面:一是以BOM为组织核心，将定义最终产品的所有工程数据和图文档信息联系起来，通过产品特征配置形成零件，通过零件配置形成部件，通过部件配置形成产品，同时对产品对象及其相互之间的联系进行维护和管理；二是在不改变产品拓扑结构的前提下，根据产品配置规则定义和产品配置过程将标准的产品模型通过配置形成满足符合用户要求的产品结构。主要操作有:产品的配置信息的创建、修改、替换、审核、存档等操作。

 
3.3 BOM视图管理(Bom View Management)
BOM视图管理产品全生命周期中BOM和产品结构/配置信息，支持BOM重构、替换和替代、零部件属性扩展、BOM红线划改、表单式BOM编辑等扩展的BOM功能。BOM视图针对不同的部门可以有不同的BOM视图，如面向设计视图的工程物料清单(Engineering Bill Of Material，  EBOM)，面向装配视图的工艺物料清单(Process Bill  Of Material，  PBOM)，面向制造视图的制造物料清单(Manufacturing Bill Of Material，MBOM)，面向客户视图的客户物料清单(Customer Bill Of Material，  CBOM)，以及面向订单、计划、服务、运输等方面的各种视图。

 
BOM的属性描述有:BOM编号、名称、重量，体积，层次隶属关系、物料生效口期、版本号、BOM类型(标准、模型、计划、选项类)、组件或部件类型(外协件、外购件、通用件、标准件、借用件)、父项编码、父项名称、子项编码、子项名称、子件需求数量、部件图号、信息描述、技术文件、总图(由零件、组件部件等装配而成)、产品说明书、备注等。主要进行的操作有:各类视图查看、视图转换、修改、审核、冻结、删除等操作。
 

3.4产品零部件分类与检索(Product Parts Classification Retrieval)
产品零部件分类与检索主要是对产品零部件的属性和功能按照零部件的相似性(结构形状或制造工艺相似等条件)进行组织、分类和管理。以产品结构树为基础，通过产品结构树浏览每个零部件的设计信息，从而对整个产品、零部件，甚至零部件的具体特征都可以实现从需求分析阶段到零部件设计完成阶段的追踪。保证了产品数据的一致性和安全性，PDM系统提供了静态保护和并发控制两种保护方式进行保护。主要完成零部件、图文档与零件库之间的关系；建立基于属性的标准零件库和图文档检索功能；定义与维护分类码、分类结构和标准接口的基本机制。
 

基本属性描述有:零部件编号、零部件名称、零部件类型、生成口期、最近修改口期、规格型号、成组代码、功能描述、工作尺寸、特征总数、关联文档编号、关联文档名称、关联图纸编号、关联图纸名称、关联版本、标准件(是否)、外购件(是否)、外协件(是否)、基础材料、数量、生产单位、所属部件、所属项目、设计者、设计单位、存储位置、备注等。基本操作有:按组织或功能产品零部件的分类查看并检索，按产品零部件的相似性查看并检索。
 

4工作流/过程功能分析与设计
4.1工作流程管理(Workflow Management)
工作流程管理是通过把有关业务活动依时序或逻辑关系相互连接构成业务流程，依据组织规范在参与者之间传递、处理或执行，从而实现业务流程的自动化处理。产品工作流程包括设计、在线维护、修改、审批、图文档归档和发放几个阶段。设计人员完成设计工作后，提交审核人员在线审核，审核通过后工作版本归档。
 

一个完善的工作流程管理模块包括:流程定义、流程的运行管理和流程的监控。在工作流程模块中主要实现了两个功能:流程管理和任务管理。流程管理功能分为工作流程定义、工作流程模型实例化和流程控制。基础属性描述有:流程定义名称、创建时间、修改时间、终止时间、创建者、经历各阶段个数、备注等。基本操作有:新模版的创建、修改、终止、查看、删除等操作。
 

4.2过程控制管理(Process Control Management)
过程控制管理是对各种工作流的形式进行过程控制，或在过程开始后进行任务控制，它是用来定义和控制人们创建和修改数据的方法，这一功能为产品开发过程的自动管理提供了保证。过程控制管理包括两部分:流程模型实例化和流程监控。管理工作流过程首先需要进行过程模型实例化及任务分配界面。工作流过程模型一次定义，多次执行。流程控制主要包括流程的运行、修改、暂停、恢复、停止、删除，流程实例的创建者或拥有者可以看到自己的流程，可以进行流程修改、改变流程的状态、指定流程新的拥有者等功能，以上操作需权限控制。
 

流程监控主要查看流程的执行状况，用户打开流程并观察每个节点的状态(包括正在执行、尚未执行、暂停、停止，完成、删除六种状态)。基础属性描述有:模版流程实例名称、创建时间、实例化人员、修改时间、终止时间、经历各个阶段名称、阶段个数、备注等。基本操作有:流程的运行、修改、暂停、恢复、停止、删除等操作。
 

4.3消息传递机制管理(News Transit Management)
消息是系统用户从消息处理应用程序发送的内容(如电子邮件)，消息类型包括电子邮件、会议、任务、便签、口记、联系人、即时消息、语音邮件、传真、图像视频等。本系统之间的消息传递模式主要有:
    (1)点对点的通讯:这是我们的传统也是最常见的通讯方式；

    (2)多点广播:即能够将单一消息发送到多个目标站点；

    (3)发布/订阅模式:消息发布者向特定主题发布消息，多个预订者可以注册接受特定发布的消息，或者是每个固定的时间点向所订阅的用户更新一次数据信息。
 
    (4)群集:群集类似于一个域，这个域的点对点通讯模式中的系统配置进行了简化操作，群集内部存在多个队列管理器，这些队列管理器之间采用群集通道与其他成员进行通讯，从一定程度上大大简化了系统配置。我们可以直接借助于消息中间件产品，如IBM公司的Web-Sphere MQ、微软公司的MSMQ等，都可完成消息的传递功能。为了安全起见，也可以让系统内部人员开发类似以上的消息传递小程序。
 

属性描述有:消息编号、消息主题、传送方、接收方、消息内容、消息类型、发送时间、接收时间、是否有附件、附件大小、附件个数、是否发送成功、备注等。主要操作有:消息的创建、编辑、修改、查看和发送等操作。
 

5系统资源管理功能分析与设计
5.1群组管理(Group Management)
包括系统人员的管理和组织的管理，系统人员这里我们将其分为四类人员:系统管理人员、项目设计人员、系统审核人员、其他部门人员；组织包括各个部门组织结构、设计部门包括设计组结构。
 
系统人员属性描述:用户工号、密码、用户姓名、性别、年龄、职称、专业、学历、工作类别、所属部门编号、所属部门名称、入职时间、入职时长、联系电话、家庭住址、QQ号、E-mail、备注等。
 
系统部门组织属性描述:部门组织编号、部门组织名称、部门组织功能、负责人、部门组织人数、地址、联系电话、备注等。主要操作:系统人员和部门组织的增加、删除、变动、审核等操作。

 
5.2项目管理(Project Management)
项目管理是以产品结构树为基础的，项目的执行过程就是工作流程任务的基本过程。所以，对PDM系统中的项目的管理的基础管理模块包括产品结构管理、工作流管理和群组管理来支撑。简要分析这三个模块:

    (1)产品结构管理中的BOM视图可以按照项目任务的具体需求来定义，同时也可以反映项目中多产品结构信息的要求。
 
    (2)工作流管理是对整个产品的形成过程进行控制，用来支持和改善所有与产品形成过程有关人员的协同工作流管理模块。
 
    (3)群组管理中的动态人员管理，项目负责人利用PDM系统对系统用户的个人信息进行管理，针对既定的项目任务组建合适的产品开发团队。


主要的属性描述:项目编号、项目名称、项目类型、项目状态、项目内容、创建时间、预计完成时间、实际完成时间、项目负责人、审核人员、审核结果、分解任务数、项目设计组、备注等。主要操作有:项目的创建、编辑、修改、删除、审核、项目的任务分解、分配、进程控制、信息维护等。
 

5.3合同管理(Contract Management)
合同管理是对产品开发中涉及到的合同信息进行创建、维护和管理的功能。主要属性描述有:合同编号、合同名称、委托开发方、承担开发方、合同金额、合同签订时间、合同完成时间、合同内容、签订地点、备注等。主要操作有:合同的建立、修改、删除、审核、信息维护等操作。
 

5.4访问控制管理(Access Control Management)
访问控制管理定义了系统内部的角色和权限，系统根据用户角色和权限控制用户存在的各种操作。访问控制管理主要是对用户、角色和权限进行定义和管理。系统登录表属性描述:用户工号、用户名称、用户类型、登录状态、登录密码，备注等。权限表属性描述:权限编号、权限名称、权限访问状态、权限依赖关系、权限访问周期、权限访问次数、备注等。
 

用户是PDM系统中被定义为某种角色的并具有角色所赋予的某种权限的执行者。角色是为了实现用户与设计权限逻辑分类而定义的一组操作权限的集合。操作权限是对一种操作活动的限制，它是在一定的权限状态、权限约束依赖下对产品对象可执行的一种操作。对PDM中的用户赋予以下五种身份:
 
    (1)系统管理人员:PDM系统中的核心人员，负责系统的安装、维护和口常操作、具有最高权限，可对其他用户进行角色和权限的授权操作。

    (2)项目管理人员:负责一般用户对产品数据的增删查改等操作以及项目任务的分解分配、监督和管理。
 
    (3)审核人员:负责产品基本信息的审核操作和项目实施阶段的一切审核操作。

    (4)项目设计人员:产品数据信息的直接编写人员，查阅产品需求信息进行零部件图样设计及元数据的书写。
 
    (5)其他部门人员:包括进货部门、财务部门、销售部门等各部门人员。这里将某个零部件的设计人员定义为A类设计人员，非本零部件的设计人员统称为B类设计人员。权限管理范围中将权限分配分为两类:
 
    一类是静态分配(基本权限):是从登录开始就赋予的权限，一经登录不可修改；系统用户只在自己角色范围内进行各种操作，如需基本权限之外的操作，则需向系统管理人员进行权限的动态申请，也就是下面的系统权限的动态分配。
 

    一类是动态分配(动态授权):根据当前活动状态，以当前静态权限为基础，在某时某刻申请的权限，比如项目设计人员在修改项目相关信息时，须取得当时的权限，进行域锁定操作，修改完成之后进行解锁。以上操作都是在系统管理人员的控制下进行的。
 

用户的权限信息存储于后端数据库的系统登录表与权限表中，系统登录表用于存储并且控制系统当前所有在线用户登录信息，包括用户工号、用户名、用户身份、密码等信息。表中还建立了如用户类型、用户状态等其它用户信息描述字段，用以查询该登录用户的相关信息；权限表是用来存储系统对用户的系统授权控制信息的，它可以控制用户的安全操作范围。权限管理模型如下表3-1所示:

 
访问控制的操作命令表:基本权限表中所具有的读、写、改、删、拷贝等权限，最终是要落实到角色所拥有的对PDM命令的操作权上。我们将基本权限表中的角色一权限进行分类，形成不同的权限类且赋予不同的操作命令。权限类可分为设计类、工艺类、审批类、系统管理类和访问控制类等，针对各种权限类，选择PDM系统中允许被他们操作的命令组成命令集，形成操作命令集，如下表3-2所示:

 
6 清软英泰PDM系统主要业务静态逻辑模型构建

根据系统的需求分析建立系统的用例模型，通过识别和分析系统中的类和对象来创建系统的类图。从前面的需求分析中找到的候选对象有项目设计人员，系统管理人员，审核人员，其他设计人员，图纸，文档，产品，产品零部件，产品特征，扫描和图像处理，浏览、查询、审核、圈阅，产品零部件分类与检索，版本，产品结构，产品配置，合同，工作流程，过程控制，项目，项目任务、消息传递，群组，权限，角色等。
 

我们从以上对象中抽取出分类，包括:系统用户类，图纸类、文档类、产品类、产品零部件类、产品特征类、操作类、版本类、合同类，、项目类、消息类、权限类、角色类、组织类等。系统和用户交互的直观的图形化界面中抽取出以下用户界面类:系统登录界面类、主界面类、基础数据管理界面类、工作流/过程管理界面类、产品结构/配置管理类、系统资源管理界面类，图文档管理子界面类、扫描和图像处理子界面类、浏览查询审核圈阅子界面类、版本管理子界面类，BOM视图管理子界面类，产品结构管理子界面类，产品配置管理子界面类、产品零部件分类检索子界面类、工作流程管理子界面类、过程控制管理子界面类，触发警告提醒子界面类、消息传递管理子界面类、群组管理子界面类、项目管理子界面类、合同管理子界面类、访问控制管理子界面类。
 

6.1图文档管理静态模型设计
访问控制管理需求用例模型:
    (1)活动者识别:系统管理人员；

    (2)用例识别:角色-权限定义，用户身份核实，权限分配，活动状态定义，角色删除、动态授权，权限更改。
 

访问控制管理需求用例模型如下图3-1所示:

 
图文档对象模型:
图文档对象是产品全生命周期中产生的各种不同类型的文件，例如产品规划方案、总体设计方案、产品零部件的三维几何模型、产品的装配模型、工艺规划方案、产品加工信息和BOM等。因此，在PDM系统中要管理大量与产品相关的各类文档，有助于产品在不同阶段不同部门人员之间进行图文档的共享，且按照各自的权限进行操作。图文档管理是以产品在全生命周期中所包含的全部数据为对象展开的。主要包括:
 
    (1)原始档案:包括产品需求分析说明、产品设计任务书、可行性报告和合同等文件。

    (2)设计文档:包括工程设计文档和数据分析文档。工程设计文档中包括两部分:一部分是设计过程的规范标准和产品的相关技术参数；另一部分是在设计过程中产生的各种相关数据。另外，还包括产品的模型数据信息、图纸扫描信息、各类测试报告、审核标准以及加工NC代码等。
 
    (3)生产管理相关文档:生产管理是指产品生产过程的计划与管理。生产中的数据可分为两类:一类是比较稳定的基础数据，如生产计划表、资源采购信息表；另一类是具有实效性且相对独立的动态数据，如工程项目任务书、工作流程信息等。PDM系统将上述各文档划分为以下五种类型进行管理:

    1)数据文件:在设计阶段，所进行的各种有限元分析、机构运行模拟或测试等产品的数据文件，如ADAMS系统产生的数据文件。

    2)图形文件:由CAD软件产生的描述集合图形的文件，也包括手绘文档的扫描文件或图像处理文件。

    3)文本文件:产品、部件及零部件的性能描述性文件，如Word文字处理系统产生的doc或txt等类型的文件。

    4)表格文件:表格文件包括产品或零部件的产品定义和结构关联信息。产品或零部件定义信息包括产品或零部件的基本属性和特征参数的文件；产品结构关联信息描述产品与产品之间、产品与零部件之间、零部件与零部件之间的隶属关系。

    5)多媒体文件:描述产品各个部位的真实形象，可以在计算机上通过渲染技术产生逼真的图像；对于复杂的装配过程，还可以利用计算机动态模拟，并在附加的技术指导下生成音频和视频文件。
 

对文件的处理方法有两种:一种是保持文件的完整性，将数据与文件进行打包处理注意，这里不能将数据与文件脱离，一旦脱离数据便失去了意义。另一种方法可以是对文件中的数据进行提取，这些数据都具有独立的意义，提取之后应按类别存放在关系型数据库中，便于对文档进行的浏览、查询、审核和圈阅操作。产品数据分类模型:
 

在产品生命周期内产生的且与产品有关的数据称为产品数据。我们根据系统终端用户类型，将企业产品数据分为两类:一类是面向信息使用者的数据，如产品特征数据、产品配置参数、产品性能参数等。这类信息是针对系统管理高层人员或其他相关部门的人员而言的，为他们提供了简单、方便、快速的工具进行数据查询操作。我们可以充分利用Internet/Intranet网络的优点，及时迅速的发布这类信息。另一类是面向信息创建者的数据，如项目任务说明书、概念设计说明书、设计图纸等。这些数据为设计人员、审核人员以及装配人员服务，他们需要对这类数据进行动态修改，同时利用这类信息作为协同设计的决策支持系统。产品分类模型如下图3-2所示:

 
产品数据对象状态转变:产品数据或图文档信息在产品的全生命周期中大致可经历五种状态，这些阶段可以表示数据或文档在传输、存储过程中的成熟度标准。以下为五种状态的基本描述，如图3-3产品数据状态变更活动图所示:
 
    (1)设计状态:处于设计阶段正在被修改或操作尚未完成；

    (2)提交状态:数据正在工作流程中进行审批，只可查看，不许修改和引用；

    (3)发布状态:设计相关人员都可以进行查看；所有用户都可对它进行查询，但不允许修改；

    (4)共享状态:数据已成熟，可供其他人查看或引用；

    (5)废除状态:数据不能再被使用。

6.2产品结构与配置管理静态模型设计
产品结构需求用例模型:
    (1)活动者识别:系统管理员，项目管理人员，审核人员，其他部门人员；

    (2)用例识别:特征类，零件类，部件类，产品类，建立产品结构树，构建BOMBOM审核，产品对象增删改操作。
 

产品结构需求用例模型如图3-4所示:

 
产品结构对象模型:下面的类图是产品结构对象模型，用表示类的聚合、泛化/特化和一般关系来表示产品结构模型中的零部件之间的关联，产品结构对象模型如图3-5所示:

 
    将产品结构进行层层划分，上层与下层都是父子级关系，将每一层都用一个单层的BOM表将其表示。BOM表只记录父件和子件之间的对应关系，构造产品结构树时只需将单层的BOM表按层次递进关系排列整合成总的BOM表，然后采用递归算法实现产品结构树的构建，产品结构图如3-6所示。

 
产品配置需求用例模型:
    (1)活动者识别:系统管理员，项目管理人员，审核人员，其他部门人员；

    (2)用例识别:产品配置需求，选择产品配置层次，产品配置，产品配置审核，产品配置浏览查询；
 

产品配置需求用例模型如图3-7所示:

 
产品配置管理模型:分为两类模型，一种是根据配置规则进行配置的常规配置模型；另一种是按需求进行配置的模型；

(1)第一类产品配置模型，如图3-8所示:

 
(2)第二类产品配置模型，如图3-9所示:

 
 
6. 3工作流程管理静态模型设计
工作流管理需求用例模型:
    (1)活动者识别:系统管理人员，项目设计人员，审核人员。

    (2)用例识别:产品相关数据信息定义，产品相关过程信息定义，产品相关资源信息定义，产品相关数据信息变更，产品相关过程信息变更，产品相关资源信息变更产品相关数据信息存储，产品相关过程信息存储，产品相关资源信息存储，产品相关数据信息删除，产品相关过程信息删除，产品相关资源信息删除。工作流管理需求用例模型，如图3-10所示:

 
工作流/过程管理模型:
    工作流/过程管理模型一般包括工作流程与变更流程两种情况。工作流程可大可小大到产品开发的整个生命周期的流程，小到一份图纸的一个审批流程，变更流程也是如此。流程可以嵌套，流程中各个阶段可以串行、并行、或者串并行混合。企业主存在着许多的工作流程，例如方案审批、工艺设计审批、结构更改审批等。这些工作流程的共同特点是都是有若干固定工作环节组成，并且工作环节之间有严格的先后顺序，且每个环节有一定数量的人员参加等。


    现在分别对两种最常用的流程进行模版建立:审批流程和变更流程。这里又将这两个流程机械划分为许多基本的子任务，其划分标准为:子任务的执行是按顺序执行的前一子任务执行完，后一子任务才能启动执行；子任务的分解具有代表性；子任务的执行是需要一定时间的。
 
    按照这三个标准对实际工作组的审批过程和更改过程进行重新定义和分解，审批流程主要有三种类型:设计审批流程，工艺审批流程，工装审批流程，其审批流程图分别为图3-11，3-12，3-13所示。
 
    (1)建立设计审批流程模版。设计组提交审核并启动设计审批流程之后，需经历校对、审核、工艺审核、标准化审核、审定和批准六个子任务，完成之后状态变为发布状态。

 
    (2)工艺审批流程和设计审批流程基本一致，只是在审批环节上有些差别，在工艺设计结构递交以后，企业工艺审批流程，经历工艺校对，工艺审核、检查、标准化审核、审定和批准六个子任务之后，状态发生了改了，成为了发布状态。

 
    (3)工装审批，和设计审批流程基本一致，仅在审批的环节上稍有不同。在工装设计结构递交以后，启动工装审批流程，经历工装校对、工装审查、工艺检查、标准化审查、审定和批准六个子任务，状态发生变化之后，变为发布状态。

 
    上述三个流程存在很大的相似点，仅个别部分存在差异。所以，为了操作简单可以将其总结为一个模版，都要经历的六个子进程为校对、审查、工艺审查、标注化检查、审定、批准，六个子进程模版被实例化之后按照顺序执行。审批流程模版如下图3-14所示:

 
更改流程模版建立:
    产品的设计可能需要经过许多次工程的更改，但是不能随意的更改，要严格按照预定的工作程序完成对设计结果的更改工作，并及时的向有关人员传达消息，使其主要流程更改可能会引起的影响传递到所有涉及到的人员。设计更改分为产品设计过程的变更和开发过程的变更，设计变更一般分为以下三类更改。
 
    (1)不改变产品的通用性、互换性等基本性能。如完整的图样标准、明确的技术要求、描错和写错等更改，认定为第一类变更。

    (2)不改变产品的基本结构和基本性能。但会影响产品通用性和互换性的变更，如产品图样的尺寸、材料、表面处理等，认定为第二类变更。

    (3)产品基本结构和基本性能的变更。如改变产品重大结构、性能和尺寸等方面的变更，认定为第三类更改。更改流程模版如下图3-15所示:

 
6.4项目管理静态模型设计
项目管理用例需求模型:
    (1)活动者识别:项目设计人员，项目管理人员，审核人员，其他部门人员；

    (2)用例识别:创建新项目，建立新项目，项目变更，项目完成，项目审核，项目浏览查询机制。

项目需求用例模型如图3-16所示:

项目自顶向下的结构模型如下图3-17所示

 
6.5 BOM视图管理静态模型设计
BOM视图需求用例模型:
    (1)活动者识别:系统管理人员，项目设计人员，审核人员，其他部门人员；

    (2)用例识别:根据BOM信息构建BOM视图，BOM视图与Excel表转换，BOM视图重构、替换和替代，BOM多视图转换，BOM版本管理，BOM视图信息，BOM视图审核、圈阅，BOM视图浏览查询机制。
 

BOM视图需求模型，如图3-18所示:

 
BOM视图的转换:
PDM系统对BOM视图中的零部件之间的关系的描述是通过父子层次关系来表达的，即每一个零件都隶属于某一个部件。BOM视图的转换从数学模型上来讲，就是对原有父子层次关系的重新分配和再次组建视图的结果。BOM视图由BOM的结构关系和属性两部分组成，BOM视图转换也就是结构和属性两方面共同转换的结果。我们可以直接采用产品结构管理中的BOM表生成产品结构树的模型，结合BOM的属性进行视图转换。
 

BOM视图的转换重点在于从EB OM到PBOM进而到MBOM的转换上。在不同的转换过程中，不同的BOM视图对各种类型的特殊部件采取不同的处理方法。因此，BOM视图结构转换工作主要集中在对特殊部件的处理上，通过对比各种BOM视图结构，可以发现造成EB OM和PB OM异构的特殊部件主要表现在关键件和外协件上，在PB OM和MBOM之间异构的特殊部件主要在工艺件和虚设件上。如图3-19所示:

 

6.6群组管理静态模型设计
群组管理需求用例模型:
    (1)活动者识别:系统管理人员；

    (2)用例识别:增加新成员，增加新部门，为新成员分配部门，人员删除，人员再分配，部门删除等。
群组管理需求用例模型，如图3-20所示:

 
企业内部的人员组织方式通常包括静态组织方式和动态组织方式两种，静态组织方式是一种相对固定的工作组织，而动态组织方式则是根据某一新型产品开发任务临时组织起来的小组，有时称之为团队。下图3-21为企业内部层次结构图:

 
7 PDM系统主要业务动态逻辑模型构建
7.1图文档管理动态模型设计
对动态模型的构建，这里我们通过时序图来表示，主体这里以设计人员为例。项目设计人员提出图文档创建需求时序图如图3-22所示，基本步骤如下:

    (1)项目设计人员登录PDM系统，通过身份验证进入系统主窗口；

    (2)项目设计人员选择基础数据管理窗口，选定图文档管理窗口，选择“编辑图文档”、“查看图文档”、“修改图文档”、“删除图文档”、“提交审核”、“图文档浏览查询”；

    (3)系统弹出相应的窗口；

    (4)项目设计人员在窗口内完成相应操作；

    (5)系统保存上述操作。

 
7.2产品结构与配置管理动态模型设计
项目设计人员对产品结构管理处理时序图，如图3-23所示，基本步骤如下:

    (1)项目设计人员登录PDM系统，通过身份验证进入系统主窗口；

    (2)项目设计人员选择产品结构/配置管理窗口，选定产品结构管理窗口，选择“产品特征类定义”、“产品零部件类定义”、“产品类定义”、“产品结构树”、"BOM构建”、“浏览、查询”；

    (3)系统弹出相应的窗口；

    (4)项目设计人员在窗口内完成相应操作；

    (5)系统保存上述操作。

 
7.3工作流程管理动态模型设计
项目设计人员对工作流处理需求时序图，如图3-24所示，基本步骤如下:
    (1)项目设计人员登录PDM系统，通过身份验证进入系统主窗口；

    (2)项目设计人员选择工作流/过程管理窗口，选定工作流管理窗口，选择“产品相关数据信息定义”、“产品相关过程信息定义”、“产品相关资源信息定义”、“信息审核”、“消息传递机制”、“浏览、查询”；
 
    (3)系统弹出相应的窗口；

    (4)项目设计人员在窗口内完成相应操作；

    (5)系统保存上述操作。
 

 
7.4项目管理动态模型设计
项目设计人员对项目管理处理需求时序图，如图3-25所示，基本步骤如下:

    (1)项目设计人员登录PDM系统，通过身份验证进入系统主窗口；

    (2)项目设计人员选择系统资源管理窗口，选定项目管理窗口，选择“新项目创建编辑”、“项目任务”、“项目信息查询、浏览”；

    (3)系统弹出相应的窗口；

    (4)项目设计人员在窗口内完成相应操作；

    (5)系统保存上述操作。

 
7.5 BOM视图管理动态模型设计
项目设计人员对BOM视图处理需求时序图，如图3-26所示，基本步骤如下:

    (1)项目设计人员登录PDM系统，通过身份验证进入系统主窗口；

    (2)项目设计人员选择产品结构/配置管理窗口，选定BOM视图管理窗口，选择"BOM视图构建”、"BOM视图转换”；

    (3)系统弹出相应的窗口；

    (4)项目设计人员在窗口内完成相应操作；

    (5)系统保存上述操作。

 
7.6群组管理动态模型设计
项目设计人员对群组管理处理需求时序图，如图3-27，基本步骤如下:

    (1)项目设计人员登录PDM系统，通过身份验证进入系统主窗口；

    (2)项目设计人员选择系统资源管理窗口，选定群组管理窗口，选择“系统人员管理”、“部门管理”、“浏览、查询”；

    (3)系统弹出相应的窗口；

    (4)项目设计人员在窗口内完成相应操作；

    (5)系统保存上述操作。

 
小结
首先介绍了PDM系统的建模方法和建模语言；其次，对PDM系统的四大模块进行功能分析与设计；然后对PDM系统的主要业务进行静态和动态逻辑模型的构建给出系统业务模型的用例图和时序控制图。

本文为御云PLM软件原创文章，如想转载，请注明原文网址摘自于
http://www.plmpdm.cn/dongtai/223.html，请注明出处；谢谢配合!