产品数据管理系统的设计PDM

产品数据管理系统的设计PDM

    在对系统的功能需求和业务流程进行梳理之后，本章对系统软件开发进行详细设计，主要从系统技术架构设计、功能结构设计和数据库设计三个方面，对系统设计进行分析说明。通过系统设计，可以为实现系统的业务功能选择适当的技术手段和处理方法，为系统实现奠定良好的基础。
 
1.1技术架构设计
    系统的技术架构设计主要是对系统的运行平台进行调研和选型，包括硬件平台和软件平台。硬件方面涉及系统的部署结构以及系统的信息通讯形式，并通过系统架构和部署图的方式进行展现。软件架构设计为系统的业务功能选择具体的实现方案，针对软件开发语言、运行框架和业务模块划分等方面进行详细说明。
 
1.1.1硬件部署架构设计
    本系统作为计算机信息系统的一种，业内有两种常用的设计和部署方式，即C/S (客户端/服务器)和B/S(浏览器/服务器)两种架构。两种架构都需要服务器运行支撑，区别在于客户端界面表现和与服务器的通讯方式上。C/S架构的软件需要用户在计算机上安装客户端软件，B/S架构是通过客户端浏览器与服务器进行交互。基于HTML原理和HTTP协议的B/S架构具有方便升级、移植性强和维护成本低等优点，并且随着互联网的发展，可以基于浏览器构建具有良好用户体验的RIA(富互联网应用)软件，因此本系统基于B/S架构设计。
 
    根据需求分析，系统具有复杂的业务逻辑和工程数据，包括处理业务逻辑的服务器和存储产品数据的数据库服务器，整体架构设计和部署结构如图3-1所示。
 
    如图3-1所示，系统包括客户端和服务端两部分，客户端为Web浏览器，通过域名或IP地址访问的HTTP通信方式与服务端交互。服务端包括两部分，Web应用服务器和数据库服务器。Web服务器负责接收客户端发起的HTTP请求，处理业务逻辑并返回数据给客户端浏览器，数据库服务器通过提供的数据读写服务，存储Web服务器处理的产品业务数据，其与Web服务器之间通过TCP协议传输数据。Web服务器和数据库服务器分开部署，以提供高性能和高可用性。

1.1.2软件体系结构设计
    系统为B/S架构，且具有复杂业务和产品数据管理的特点，为构建一个健壮并且扩展性高的平台，系统基于J2EE平台设计和实现。J2EE作为Java语言三个标准平台中的企业版，提供了构建复杂企业级应用的所有功能和组件，包括Web容器、数据库持久化、事务处理、RPC远程调用和消息中间件等标准API(应用编程接口。
 
    系统基于J2EE平台构建，在系统软件体系结构上采用三层架构的设计方式，即Web层、业务层和数据层。Web层负责处理浏览器端图形界面的数据展现和交互逻辑，中间业务层包括PDM领域模型、PDM业务逻辑计算程序以及数据库的事务处理等，数据层封装对数据库的读写操作并对业务层提供访问接口，完成PDM产品数据的存储，系统软件三层架构的详细设计如图3-2所示。
 
    如图3-2所示，系统的技术架构基于J2EE平台，因此软件程序需要运行在遵循Java Servlet规范的Web容器中。Web容器采用Apache的开源软件Tomcat，同时具有Servlet容器和HTTP服务器的功能，另外程序还运用了Java开源领域流行的Struts、Spring和iBatis等框架，将Web层、业务层和数据层进行无缝整合，使程序具有很强的稳定性和扩展性，同时也大大提高了软件开发的效率，下面对三层架构的每层设计展开进行说明。

    1)Web层
    Web层位于软件系统的前端，接收浏览器请求并获取表单数据进行处理。Web层设计遵循MVC的设计模式，主要使用Servlet和Struts2相结合的形式，对表单数据、请求跳转控制和页面渲染等进行处理。针对上传下载PDM产品数据文件的需求，在Web层集成Apache的commons-fileupload组件，方便获取并保存客户端浏览器上传的Excel等格式的数据文件。
 
    2)业务层
    业务层是软件的中间层也是核心层，作为承上启下的一层，接收Web层传递的JavaBean对象数据，处理业务逻辑后通过数据层的读写接口与数据库交互，完成产品数据的存储。业务层对象由很多Service对象构成，Service对象被交由Spring框架的IoC(控制反转)容器管理，通过DI(依赖注入)机制管理Service对象和其他层对象之间的依赖关系。对象的依赖关系配置在xml文件中，降低应用程序不同层之间的祸合性，使程序更具可读性和扩展性，并且方便单元测试
 
    通过Spring容器，还可以方便地整合JNDI、事务处理、邮件发送等组件，保证了系统对数据源配置、数据库一致性和邮件发送等功能的需求。为了实现系统中一些定时任务调度的功能，业务层还采用了开源的Java任务调度框架Quartz(石英)，整合Quartz和Spring容器并配置Unix风格的Cron表达式，实现定时任务的调度和执行。
 
    另外，系统的一些功能需要对用户上传的Excel等文件进行自动化分析处理，这里采用了Apache的POI组件，该组件可以处理包括Excel在内的很多Office文件，而且对不同版本的Office文件都做了兼容性处理。最后，通过Log勺组件记录系统的日志，便于系统的开发和后期运行监控。
 
    3)数据层
    数据层的主要任务是封装对Oracle数据库的读写逻辑，并对上层提供API接口。传统JDBC接口用起来比较繁琐，因此在数据层采用JPA C Java持久化API)规范的框架iBatiso iBatis框架和另外一个著名的持久化框架Hibernate类似，都是O-R(对象一关系)映射框架，将数据库表映射到Java对象，但是iBatis提供了更加灵活的方式，可以对SQL语句进行直接控制，并且还可以按照面向对象的方式编写数据访问逻辑。对于数据层提供的API接口的设计，使用DAO(数据访问对象)模式，为每个数据表都提供对应的DAO对象，DAO对象的方法即为对外层提供的API接口。
 
    综上所述，为了实现软件设计高内聚低祸合的原则，将系统划分为了不同的层，每一层都封装了自己的业务逻辑，然后对其它层提供API接口，更好地完成业务数据的计算、交互和存储，从而构建一个具有高健壮性和扩展性的产品数据管理系统软件。
 
3.2功能架构设计
    在系统整体结构设计好后，根据前面详细需求分析的结果，该系统的功能模块可以分为五个部分，分别是系统管理、工程变更管理、图纸发行管理、通知书会签管理和基础数据维护。系统的功能架构设计如图3-3所示。

3.3数据库设计
    系统的核心是对产品数据的管理，数据库作为保存产品数据的载体，存储了系统的所有业务数据和数据模型之间的关系，一方面对产品业务数据起着保障的作用，另一方面维持着同一系统中不同数据模型之间业务关联的正确性。数据库设计的好坏还对数据存储空间利用率、存取时间效率和软件可扩展能力起到至关重要的作用，因此做好系统数据库的设计是十分重要的。
 
    数据库设计通常包括两个方面，即逻辑模型设计和物理模型设计，逻辑模型设计主要是对数据进行抽象关联，得到E-R (实体一关系)模型。物理模型设计是在逻辑模型的基础上，并针对具体RDBMS系统软件，设计具体详细的数据字典结构。下面对系统数据库的逻辑模型设计进行介绍。
 
    逻辑模型设计是基于用户需求，对系统的需求进行整理、归纳并抽象，得到数据实体模型和数据之间的关联，可以大致与现实世界进行映射。在数据库设计方法中，通常运用E-R模型图来体现逻辑模型设计，具体包括对模型的属性列、候选码、实体主键和外键关联等的设计，E-R模型不考虑数据的具体存储结构，与底层RDBMS数据库系统无关，其面向具体的问题，面向具体的业务概念模型。系统根据业务需求划分为五个模块，包括系统管理、基础数据维护、工程变更管理、图纸发行管理和通知书会签管理，下面对每个模块的主要实体概念模型进行详细的分析和设计。
 
    1)系统管理和基础数据维护
    系统管理和基础数据维护是系统最基础的功能，系统管理包括用户、职务、部门和科室等具体实体模型，都与系统的用户相关。基础数据维护中的实体都与业务产品数据相关，包括产品机种、阶段和级别等。该模块各实体及其属性的说明如下，基于以下实体的E-R模型如图3-4所示。
    a)用户:{用户代码，用户姓名，密码，科室，职务，联系方式};
    b)职务:{职务代码，职务名称};
    c)部门:{部门代码，部门名称};
    d)科室:{科室代码，科室名称，部门代码，文档类目级别，备注信息};
    e)角色:{角色ID，角色名称};
    f)用户角色:{用户代码，角色ID};
    g)机种:{机种ID，机种名称};
    h)阶段:{阶段ID，阶段名称，是否进行法规判断};
    i)级别:{级别ID，级别名称};

    如图3-4所示，系统管理部分的几个主要实体都是和用户相关的，职务和科室都与用户一对多关联，部门和科室之间也是一对多的关系，用户与系统角色之间通过另外一个“用户角色”关联实体进行多对多关联。
    2)工程变更管理
    工程变更管理的内容主要是各种产品规格的变更，规格变更通知书是业务变更流程的起始，也是该部分功能的最主要的模型实体，其他实体还包括变更流程、通知书附件和审批履历等。工程变更管理模块的各实体及其属性的说明如下，基于以下实体的E-R模型如图3-5所示。
 
    a)规格变更通知书:{通知书号，版本号，相关通知书号，主题，类别，SEC，机种，阶段，级别，法规判断备注，内容描述，通知书路径，当前节点编号，合并文件路径，合并时间，创建人ID，创建时间};
 
    b)规格变更处理流程:{通知书号，版本号，QP担当上传时间，PE担当确认时间，PE机种PL确认时间，PE系长审批时间，PE科长审批时间，PE科长创建人ID ,EC担当确认时间，EC系长审批时间，EC科长审批时间，QP担当确认时间，QP系长审批时间，QP科长审批时间，调查返回时间};
 
    c)规格变更通知书附件:{通知书号，版本号，系统存放文件名，上传文件名，文件路径};
    d)通知书审批履历:{履历编号，通知书号，版本号，通过节点编号，审核结果审核意见};
    e)车间部品(零件):{零件编号，科室};
    f)机种明细:{明细编号，通知书号，版本号，机种，阶段，级别};

    如图3-5所示，工程变更管理的主要实体即规格变更通知书，其他实体都与其进行关联。规格变更通知书的实体标识为通知书号和版本号的联合主键，变更处理流程实体记录审批的状态，其与变更通知书为一对一关联。在每个变更通知书中，都包括该变更申请所涉及的多个产品机种、阶段和级别，每个机种、阶段和级别也可以被多个变更通知书包含，因此变更通知书与机种、阶段和级别的关系为多对多关联，同理的还有审批落点的科室和变更涉及的车间零件。另外，每个变更通知书都包括多个附件和多个审批履历，与它们的关系为一对多关联。
 
    3)图纸发行管理
    图纸发行管理的核心功能是产品图纸的申请和审批，所以主要的实体是产品图纸申请。图纸申请的对象图纸也是主要实体，包括图纸清单和现有图纸清单等。另外，图纸申请的最终结果是通过缺货图纸依赖明细和己发行图纸清单来记录的。图纸发行管理模块的各实体及其属性的说明如下，基于以下实体的E-R模型如图3-6所示。
 
    a)产品图纸申请:{申请序号，申请科室代码，图纸号，类型，是否需要类型转换，规格更改号，图纸名称，图幅，格式，申请理由，机种，供应商，图纸申请状态，发行编号，创建人ID，创建时间};
    b)规格变更图纸申请:{申请序号，图纸号，规格更改号，图纸名称};
    c)发行图纸清单:{发行编号，表格编号};
    d)图纸供应商:{供应商编码，类型，供应商名称};
    e)图纸:{图纸号，机种，图纸名称，基准时间};
    f)现有图纸清单:{ ID，图纸号，图纸名称，类型，种类，日期};
    g)依赖明细:{图纸号，格式，依赖单号，图纸名称，规格更改号，图幅，机种，回复日期，状态};

    如图3-6所示，图纸发行管理包括两个独立的重要实体，产品图纸和产品图纸申请。图纸依赖明细和现有图纸清单都是与图纸实体一对一关联，通过关联图纸号的形式。另外，与产品图纸申请书关联的是图纸供应商和己发行图纸清单，每个产品图纸申请都包含一个图纸供应商，通过审核的申请还会关联己发行图纸清单的发行编号，与它们的对应关系都是多对一的关联。
 
通知书会签管理
    通知书会签管理的主体为产品技术通知书，包括通知书ID、通知书号、审批状态和发行时间等，每个产品技术通知书都可能包括多个会签设定、会签履历和附件文件。通知书会签管理模块的各实体及其属性的说明如下，基于以下实体的E-R模型如图3-7所示。
 
    a)产品技术通知书:{通知书ID，通知书号，存放路径，标题，审批状态，起票科室代码，文件是否发行，发行文件路径，发行时间，创建人ID，创建时间};
    b)产品技术通知书附件:{通知书ID，文件名，文件路径};
    c)会签设定:{通知书ID，会签部门，会签科室，会签人ID，会签结果};
    d)会签履历:{通知书ID，会签科室，会签人ID，审核结果，审核意见};

    通知书会签管理的主要功能是产品技术通知书的申请、审批和发行，核心实体模型为产品技术通知书，每个产品技术通知书生成时，都需要多个部门科室对通知书进行审批，审批通过后发行，因此每个通知书都对应多个会签设定和会签履历，为一对多的关系，每个产品通知书还可能包括多个附件，关联关系也是一对多。另外，审批中的通知书会记录当前审批正落点的科室，与科室之间是多对多的关联关系。

本文为御云清软英泰PLM软件原创文章，如想转载，请注明原文网址
http://www.plmsoft.com.cn/news/gsxw/165.html；否则，禁止转载；谢谢配合!