您现在的位置是:首页 > IT基础架构 > 软件与服务 >
基于UML的车间作业管理系统建模研究
摘要车间作业管理系统是企业生产管理的一个重要环节,是企业计划层和车间执行层的接口。在介绍了系统建模语言UML的基础上,讨论了车间作业管理系统建模过程中,使用UML语言进行系统建模的方法和步骤,并使用Rational Rose工具作为UML的集成建模环境。...
车间作业管理系统是企业生产管理的一个重要环节,是企业计划层和车间执行层的接口。现在无论是生产计划还是车间生产执行系统都己发展得比较成熟,但是作为二者接口的车间作业管理系统,却还不够完善。这与车间作业管理的特点有较大的关系,车间作业管理处理的动态信息量大,要求实时性强,并且调度复杂。同时在此阶段信息的反馈是非常重要的,因为系统要以反馈信息为依据对物料需求计划、主生产计划作必要的调整,以实现MRPⅡ系统的闭环管理。因此近年来车间作业管理系统成了许多学者和工程人员研究的热点。但是无论是开发还是研究车间作业管理系统,系统的建模是至关重要的。系统模型的优劣直接影响到系统后续的开发和研究,科学合理的系统模型可以大大减少研究和开发车间作业系统的时间和成本。
1 UML简述
UML(Unified Modeling Language)统一建模语言,是统一了著名的面向对象技术专家Grady Booch的Booch方法,Jim Rumbaugh的OMT方法以及Ivar Jacoboson的OOSE方法中的符号表示,并在其基础上进一步发展而成的。1997年UML被OMG(Object Management Group)批准作为面向对象建模语言的标准,并得到了工业界的广泛支持。
UML是一种通用的可视化(Visualizing)、规范定义(Specifying)、构造(Constructing)和文档化(Documenting)的建模语言。为了使用户在系统建模过程中利用迭代方式(每次迭代微过程包括分析、设计、实现、测试和配置)进行递增式的开发,UML提供了一系列的图来描述建模过程中的各个方面。UML的重要内容可以由下列5类图(共9种图形)来定义:
(1)用例图,描述了用例、系统参与者以及它们之间的关系,用例图描述了系统的静态用例视。在对系统行为组织和建模时,用例图是相当重要的。
(2)静态图,包括类图、对象图和包图。类图描述系统中类、接口、协作及其之间的关系。对象图是类图的实例,只能在系统的一定时间段存在。包图用于描述系统的分层结构。
(3)行为图,描述系统的动态模型和组成对象间的交互关系,包括活动图和状态图。活动图描述满足用例要求所要进行的活动以及活动间的约束关系。状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
(4)交互图,描述对象间的交互关系,包括时序图和合作图。时序图显示对象之间的动态合作关系,强调对象之间消息发送的时序。合作图用于描述相互合作的对象间的交互关系和链接关系。
(5)实现图,包括构件图和配置图。构件图描述代码部件的物理结构及各部件之间的依赖关系。配置图定义系统中软硬件的物理体系结构,它可以显示实际的计算机和设备(用节点表示)以及它们之间的连接关系,也可显示连接的类型及部件之间的依赖性。
统一了的UML是一种定义良好、富于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不局限于支持面向对象的分析与设计,还支持从需求分析开始的软件开发的全过程。从应用角度来看,当采用面向对象技术设计系统时,第1步是系统需求描述;第2步是根据需求建立系统的静态模型,以构造系统的结构;第3步是系统行为的描述,基于UML的建模过程同样也是遵循了这个过程。
2 基于UML的车间作业管理系统建模
本文讨论的基于UML的车间作业管理系统建模过程包括系统需求分析、静态结构模型设计和动态行为模型设计,以下是系统建模中采用的过程及各个阶段中所产生的模型。
(1)需求分析建模。通过使用UML活动图描述车间作业的业务需求来理解车间领域知识。
(2)功能建模。根据需求分析寻找用例及其之间的关系(用例图),通过用例事件流的详细描述捕获系统的功能需求。
(3)领域建模。主要是使用类图表现领域中各业务类之间的静态关系,并用交互图、状态图等具体描述类之间的交互以及对象的状态变化。主要涉及以下活动(并不一定是顺序的):分析用例以及业务领域发现对象;为对象分类,确定类之间的关系;定义类的属性和操作;确定对象之间的交互;分析对象的状态变化。
(4)系统实现。实现的依据是设计过程中得到的静态视图(类图、对象图)、动态视图(顺序图、状态图、协作图、活动图);同时可以将类映射为组件,进而利用Rational Rose工具的框架代码自动生成功能。
2.1 系统工作内容
根据企业生产计划系统MRPⅡ的计算,主生产计划给出了最终产品或最终项目的需求;物料需求计划将主生产计划根据产品明细、库存信息、提前期等信息展开并经过能力平衡后,生成计划定单。该定单由计划人员确认并按采购件和自制件分类,生成车间定单(派工单)和采购定单,采购定单下达给采购管理系统,车间定单则下达给车间作业系统来执行。因此车间作业系统的主要工作内容如下:
(1)核实MRPⅡ产生的车间定单计划
MRPⅡ为计划定单规划了计划下达日期,但对真正下达给车间,这是一个推荐的日期。定单在生产控制人员正式批准下达生产之前,必须检查物料、机台生产能力、提前期和工具的可用性。车间调度员所要做的就是通过计划定单报告、物料主文件、库存报告、工艺路线文和工作中心文件以及工厂日历完成以下任务:确定所需物料、能力、提前期和工具;确定所需物料、能力、提前期和工具的可用性;解决物料、能力、提前期和工具的短缺问题;编制生成领料单。
(2)执行生产订单(派工到机台)
执行生产订单的工作包括下达生产订单和领料单、派工到机台和提供车间文档。现在一般的MRPII系统都是派工到工作中心,但是根据现在制造企业的实际需求,派工到机台可以更加有效地监控在制品,实现到零件级的管理。
(3)收集信息、在制品跟踪监控
如果在生产过程中零件加工时发生问题,或者是质量检验时未通过,或需要修理。零件的加工状态就要更新,或者要更改生产计划。为此要查询工序状态、完成工时、物料消耗、废品等报告。
2.2 系统,求分析
在了解了车间作业系统工作内容以后,接下来需要进行的是系统需求分析。需求分析阶段主要的任务就是获取用例。用例分析是基于UML的面向对象建模过程的一个显著的特点,在基于UML的建模过程中,用例处在一个核心的位置。用例除了被用来准确获取用户需求以外,它还将驱动系统整个开发过程:包括系统分析、系统设计,以及系统实现、测试、配置等。在UML中一个用例模型由若干个用例图描述,用例图的主要元素是用例和参与者。因为用例是从参与者角度来看系统,所以要获取系统的用例,首先要确定系统边界,识别出系统的参与者,然后再对每个参与者列出它的用例,并由此来确定系统最终的用例。在本系统中通过对上述需求的分析和分类,首先确定系统的用例包(将一些关系紧密的用例放到一个包里,并且为用例包确定一个主题)的总体结构如图1、图2所示。
图1 车间作业管理系统顶层用例包
图2 车间作业管理系统顶层用例包子图
2.3 用例的获取
(1)识别参与者
为了获取用例,首先需要识别出系统的参与者,因此可以通过让系统用户回答一系列问题来来帮助识别参与者,例如:谁使用系统的主要功能(主要使用者)?谁需要系统支持他们的日常工作?谁来维护、管理使系统正常工作(辅助使用者)?系统需要操纵哪些硬件?系统需要与哪些其它系统交互,包含其它计算机系统和其它应用程序?谁是对系统产生的结果感兴趣的人或事物?
通过回答以上问题可以方便地识别出系统的参与者,在识别参与者时需要注意以下两点:
①参与者代表角色,当建立用例模型时,参与者被用来模拟角色而不是模拟物理的现实世界的人、组织或系统本身;
②角色不是对职位进行建模。
通过对本系统中系统边界和需求的分析,得到以下系统参与者:车间作业管理员,车间调度员,车间主管,生产计划员,车间班组,系统浏览者。
(2)获取用例
用例是对系统行为的动态描述,可以划分系统内部和外部实体的界限,是系统设计的起点,是类、对象、操作的来源。大部分用例将在项目的需求分析阶段产生,并且在系统分析的过程中,用例将逐步添加到用例集中。
在获取了系统参与者之后,通过对参与者提出问题以获取系统用例,典型的问题有:每个参与者的任务是什么?参与者要求系统提供哪些功能(参与者需要做什么)?参与者需要创建、删除、修改或存储的信息有哪些类型?什么用例将支持和维护系统?所有的功能需求都能被用例执行吗?还有一些针对整个系统的问题,比如:系统需要何种输入输出?输入从何处来?输出到何处?当前运行系统(也许是一些手工操作而不是计算机系统)的主要问题?根据以上问题分析本系统的需求,可以大致确定以下用例:
基础数据维护管理:系统参数设置,任务优先级,工序优先级,工票类型,班组,工时车间操作权限等资料维护管理;
车间任务管理:车间任务建立,模拟下达,任务确认,下达,执行,结清等;
车间计划管理:车间计划制单,分解,审核,下达,结案等;
车间物料管理:任务用料分配,释放,领料,工票用料分配,释放,领用,车间用料盘点,领料单的制单、审核、物料分解;
车间工票管理:生产工票下达维护,工序完工操作,工票完工操作,车间操作权限设置;
在制品管理(Work-In-Process,WIP):零件状态搜索查看,SPC(Statistic Process Control)设定,SPC权限设定、SPC统计分析图表,不良率警报等。
根据以上得到的用例,可以得到如图3所示的车间任务管理用例。
图3 车间任务管理用例
(3)用例的详细描述
根据上一节中得到的用例图,可以对系统的用例进行分析,详细描述每个用例的处理,也就是用事件流来规定用例的行为。下面是车间任务建立的用例描述:
目标:根据车间计划及设备能力和班组能力建立车间作业任务;
范围:车间管理;
前置条件:系统具有设备能力信息,班组能力信息,车间计划信息;
后置条件:建立车间作业任务;
参与者:车间调度员,车间班组,车间主管;
触发事件:无;
主要步骤:1)用户选择车间任务建立功能,2)确定车间计划,3)系统返回车间计划详细信息,4)用户选择要执行的车间计划,根据生产能力修改时间、数量等参数,5)系统制定出车间任务,保存,打印,用例完;
扩展:若车间计划尚未建立,系统提示信息;
相关用例:车间任务确认,车间任务模拟下达,车间任务下达,车间任务结清。
2.4 静态模型建立
系统领域建模分析阶段得到的静态模型中,最重要的是类图,类图是几乎所有面向对象方法中都具有的表达方式,也是面向对象模型中的核心。类图表明了类(对象)之间的静态关系,主要有关联、聚合、泛化(继承)等。通过前面用例的分析,得到车间作业管理系统的部分类图,见图4。
图4 车间作业管理系统部分类图
在该系统中定义了许多类,包括边界类、实体类和控制类。其中,边界类用于建立系统与其参与者之间交互的模型;实体类用于对长期持久的信息建模;控制类代表协调、排序、事物处理以及对其他对象的控制,还可用来表示复杂的派生与演算,如业务逻辑等。为了清晰明了的组织这些类,在建模过程中还采用了UML包图,将关联比较紧密的类组织在一个包里,并用每一个包中核心类来命名包名。
2.5 态行为模型建立
上节讨论的类图只是从静态角度描述系统,而面向对象系统是通过对象之间相互传递消息来实现系统功能的,因此要为系统建立动态模型才能全面地反映系统的情况。系统动态模型主要有两种:表达对象间时序的交互作用图以及表达对象状态变化的状态图。交互作用图描述了交互作用,由对象、对象间的关系组成,并包含在对象间传递的消息。交互作用图可分为时序图和协作图。时序图和协作图以不同的方式表达了类似的信息,时序图描述了消息的时间顺序,适合于描述实时系统和复杂脚本;协作图描述了对象间的关系。协作图是强调发送和接收消息的对象的组织结构的交互作用图。用交互作用图来描述每个用例的“实现”,有助于了解系统中类之间的相互关系。通过对车间作业系统的类图间关系的分析,图5示出了系统中一个典型的建立车间生产工票的交互作用,从中可以看出各个对象之间的交互顺序。
图5 工票建立交互作用
在动态行为建模过程中,需要为每个用例建立交互作用图,并且需要为具有复杂状态变化的类建立状态图。状态图描述了特定对象的所有可能状态以及引起状态跃迁的事件。
2.6 物理模型建立
本系统的物理模型设计为是基于企业内部局域网以及中央数据库的三层C/S结构系统,系统的配置如图6所示。
图6 系统配置
3 结 语
作为企业计划层和执行层的接口系统,车间作业管理系统的建模和开发成了近来的研究热点。然而往往在系统的开发和建模过程中,用户和开发者采用不同的语言,导致了研究开发成本的加大以及时间的浪费。因此本文主要讨论了基于UML语言的车间作业管理系统建模方法和步骤,建立了一个比较完整车间作用管理系统的模型。该模型可以增强领域专家、软件设计者和用户之间的交流联系,从而使得系统的开发工作能够顺利进行。
(本文不涉密)
责任编辑:
上一篇:业务流程管理(BPM)的4种方法
下一篇:企业业务流程再造及其效果研究