火电厂设备检修管理系统的UML建模

火电厂设备检修管理系统的UML建模刘志强 黄树红 高伟华中科技大学动力系 摘要：状态检修是科学的设备检修方式，实施先进的检修管理、建立设备检修管理系统是状态检修的基础。本文分析了设备检修管理系统的功能需求，探讨了对电厂设备检修管理系统采用统一建模语言（Unified Modeling Language）进行可视化建模的一般过程和可行性，并以某300MW机组为例论述设备检修管理系统的基本框架和UML建模过程。关键词：发电设备 状态检修 统一建模语言（U） 管理信息系统1 引言建国以来，我国长期实行的检修体制是以故障检修、预防性计划检修为主的体制。随着社会经济和科技的发展，检修体制目前正逐步向预知性的状态检修体制过渡。以故障检修、预防性计划检修为主的检修体制曾经是适应我国生产力发展水平的，它一般包括大修、小修、临修、定期维护等形式。在电厂设备管理中采用这种检修方式的优点在于保持供电的基本稳定性，人力、物力、资金安排的计划性，生产指挥者基本上做到心中有数。在这种检修体制下，一般大修间隔23年，小修间隔48个月，检修项目、工期安排和检修周期均由管理部门根据经验制定。但随着火电设备向高参数、大容量、复杂化发展，其安全经济运行对社会的影响也越来越大，维修投入大幅度上升。面对这个情况，现行检修体制日益明显暴露出所存在的缺陷，因此对设备实行更先进、更科学的管理和检修体制，无论从火电厂自身的利益还是从社会的要求出发，都是势在必行。状态检修是在设备状态监测的基础上，根据设备状态监测和分析诊断的结果安排检修时间和项目的检修体制。所以，它是一种适应于市场经济和现代企业制度的全新的设备维修策略，根据我国国情，状态检修实际上是融故障检修、计划性检修、状态性检修、主动检修为一体的，具有最大的可靠性和最低的成本消耗的混合式优化检修体制。目前，在火电厂推行状态检修所要达到的目标是：延长定期检修间隔；减少定期检修时间；提高设备可靠性和可用系数；增加发电量；延长设备寿命；降低运行检修费用；减少资金投入；改善电厂运行性能；提高火电企业经济效益。状态检修作为一种先进的检修体制，是一个涉及到技术、经济、体制等多方面的系统工程，涉及到许多管理问题。要实行状态检修，必须使设备检修管理工作标准化，正确完整的技术数据和技术管理是状态检修的基础。目前在电厂的设备检修工作管理中，由于设备的繁多和复杂，相对应的检修工作票、检修工艺卡的管理十分复杂，整个检修工作的过程管理也很复杂，大多数电厂都是单凭检修管理人员的脑力劳动和手工记录，这已经不能满足状态检修的要求。因此，结合全厂设备管理信息化的建设，建立状态检修的计算机管理信息系统是推行这一体制的基础性工程。本文论述了检修管理信息系统的设计和建模工作，并在系统的需求分析和总体设计中采用了可视化建模的方法。大型信息管理系统建模是系统成败的关键，采用建模语言进行建模有利于系统的最后实施。本文采用的建模语言是目前国际上流行的统一建模语言（U）。UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。它溶入了软件工程领域的新思想、新方法和新技术。它的作用域不仅限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。2 设备检修管理系统的需求分析设备检修是设备全过程管理的一个重要环节，状态检修作为一种先进的检修体制，它的内容包括着很多管理方面的问题。这些问题主要有：数据的综合管理、检修风险分析与决策、备品备件管理、具体检修过程的实施管理、相应设备管理政策的制订、对检修效果的评估、专业人员的培训以及机构设置等问题。而其中检修管理是是涉及到上述诸多问题的最主要管理工作。检修管理包括设备缺陷管理；检修工作票、工艺卡管理；检修计划管理；检修项目管理以及备品备件管理等。它可为整个状态检修过程提供完备的技术数据、检修依据和检修过程的自动化控制。因此，设备检修管理系统的实施对电厂实施状态检修有很重要的意义。针对状态检修的要求，设备检修管理系统应通过以下五个子系统来满足其需求。 检修工作票、检修工艺卡管理系统在系统中对设备的检修工作票集中管理，执行工作票办理、签发、接受、许可、变更、延期、终结、验收、完工处理等任务；对设备检修工艺卡亦进行集中管理，提供录入、删除、查询、编辑等功能。 设备缺陷管理系统该系统从人为发现缺陷开始，辅助检修部门组织人员进行消缺，同时详细记录消缺的整个过程，进行设备缺陷统计，为分析设备运行情况和部门考核提供科学依据，并为以后制定大修计划和对设备质量进行评估提供参考。 检修计划管理系统对设备的定期检修计划进行管理，制定设备定检滚动计划表。并可根据定检表生成月计划项目表和检修卡。 检修项目管理系统通过状态监测和故障诊断分析出的诊断结果、设备事故和缺陷，提交设备检修申请。针对所提交的申请，生成工程项目，规定该项目应执行的工作计划。工程项目中包括检修开工处理及完工处理，检修结果的验收、评估，报表生成。其检修作业管理模块对检修作业的四个阶段（分析监测、检修建议生成、作业单生成和检修开始、检修完成）进行管理，同时跟踪检修作业进行的状况，如检修建议是否送出、取消、等待批准，等待计划、等待材料、完成、完成封档等。 备品备件管理系统对电厂设备的备品备件进行综合管理，能够随时提供设备的备件信息；上述五个系统之间的联系非常紧密，要完成各自的功能都要用到其他系统的数据。它们之间有的是并行处理，有的是顺序处理，而且所涉及到的系统用户种类很多，权限管理十分复杂，各个用户之间的业务联系错综复杂。各系统下的子系统同样也是复杂多变，功能划分不易明确。同时，系统还要兼容电厂已有的网络系统和厂级MIS系统。因此，要能够准确完成系统的需求分析和总体设计，也就是对电厂的设备维修管理进行建模，从业务需求到要求，到模型，是一项很重要的工程，整个系统的成败也就在于建模的成功与否。另外，考虑到团队开发以及系统的健壮性、伸缩性和良好的继承性、可维护性，选择一个在整个系统的生命周期中都适用的建模工具十分关键。3 统一建模语言UML和可视化建模系统建模时，要把用户的业务需求映射到开发小组能理解的技术要求，并最终产生代码。将业务需求和技术要求映射为代码，保证代码满足这些要求，而且代码最终可以方便的回溯要求。这个过程称之为建模。面向对象的分析与设计(OOAD)方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。它不仅统一了Booch、Rumbaugh和Jacobson的表示方法2，4，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。1996年底，UML已稳占面向对象技术市场的85，成为可视化建模语言事实上的工业标准。1997年11月17日，OMG采纳UML 1.1作为基于面向对象技术的标准建模语言。标准建模语言UML的重要内容可以由下列五类图形(共9种图形)来定义:第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者（角色）。第二类是静态图(Static diagram),包括类图、对象图和包图。其中类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。对象图是类图的实例,几乎使用与类图完全相同的标识。他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。一个对象图是类图的一个实例。由于对象存在生命周期,因此对象图只能在系统某一时间段存在。包由包或类组成,表示包与包之间的关系。包图用于描述系统的分层结构。第三类是行为图(Behavior diagram),描述系统的动态模型和组成对象间的交互关系。其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。通常,状态图是对类图的补充。在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。第四类是交互图(Interactive diagram),描述对象间的交互关系。其中顺序图显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。除显示信息交换外,合作图还显示对象以及它们之间的关系。如果强调时间和顺序,则使用顺序图;如果强调上下级关系,则选择合作图。这两种图合称为交互图。第五类是实现图( Implementation diagram )。其中构件图描述代码部件的物理结构及各部件之间的依赖关系。一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。它包含逻辑类或实现类的有关信息。部件图有助于分析和理解部件之间的相互影响程度。UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。在需求分析阶段，可以用用例来捕获用户需求。通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。为实现用例，类之间需要协作，这可以用UML动态模型来描述。在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。 编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。 UML模型还可作为测试阶段的依据。系统通常需要经过单元测试、集成测试、系统测试和验收测试。不同的测试小组使用不同的UML图作为测试依据：单元测试使用类图和类规格说明；集成测试使用部件图和合作图；系统测试使用用例图来验证系统的行为；验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。可视化建模将模型中的信息用标准的图形元素直观地显示。目前，支持UML可视化快速开发应用程序的工具很多，其中Rational公司的Rational Rose是其中之一，它支持Use Case框图，Sequence框图等图。通过正向和逆向转出工程代码特性，可支持C+，Java，Visual Basic的代码产生和逆向转出工程代码。4 电厂设备检修管理系统的建模本系统采用UML语言进行建模。第一步工作是系统的需求分析，而需求分析必须以针对该系统的调研为基础。在调研过程中，可针对现行系统和信息需求进行分析，并得出系统的功能需求分析。用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。清楚表达系统的用例图往往不是一次就能做好的，必须在对系统所涉及的业务充分了解下，才能不断完善，它反映了系统与外界的交互作用。以某300MW火电机组为例，根据需求分析，建立起一个初步的框架。系统按上述五个子系统进行功能划分。系统涉及业务和各种人员类型很多，若是将其用一个用例图表达是不可能的，因此，对应五个子系统将用例分成了五个包，每个包中若涉及的业务和系统人员仍比较复杂的话，还可以在此包的基础上再分若干包，包中包含了用例图。而包图将类似项目组合在一起，显示包与包之间的依赖、继承关系。用例图中的角色（Actor）对形成用例图是非常有用的，获取一个用例，首先就要找到与之关联的角色。面对一个大系统，要列出用例清单常常是十分困难。这时可先列出角色清单，再对每个角色列出它的用例，问题就会变得容易很多。在本系统开发中，通过用户对一些问题的回答来识别角色。如：系统中工作票及工艺卡由谁制定，由谁填写，由谁来执行等问题。此外，弄清楚本系统需要和哪些系统进行交互是很重要的，如与设备台帐管理系统、物资管理系统的交互关系等。一旦弄清楚了系统中的主要角色，就可以对每个角色提出与之相关的问题，例如：针对汽机检修人员需要系统为之提供什么功能，如查询设备检修工艺卡，生成设备检修报告等。他们对系统做哪些操作，特别是必须提醒系统角色的系统事件有哪些，怎样把这些事件表示成用例中的功能？如系统发出缺陷通知事件，该事件应通知检修部门。值得注意的是一个用例必须至少和一个角色关联。经过提炼和归纳，可以得到系统的全部用例图。图1是本系统的设备定检制度制定用例图。该用例图基本反映了电厂设备定检计划的编制过程。在本图中所涉及到的部门人员有检修部，检修班组，它们在图中反映为角色。这些角色启动了与系统的通信，它们所完成的功能或与系统的交互在图中就反映为用例。角色与用例之间的通信称之为通信关系（communication relationship），它们用箭头表示。Use Case框图的一大优势在于通信。客户可以从该图中取得大量信息，通过查阅用例与角色，可以知道电厂设备定检计划编制的基本过程，有助于寻找缺少的功能。图1 设备定检制度制定用例图从物理结构上，电厂检修管理系统应采用三层分布式体系结构，整个系统的功能分布于多台PC服务器之上，这些服务器的功能大致分为两类：一类是设备检修应用服务器，还有一类是数据库服务器。设备检修应用服务器则提供设备管理、检修策划等项功能，而完成上述功能所需要的数据由数据库服务器进行存储、检索。设备检修应用服务器是中间层，属于应用服务器。三层分布式体系结构在可视化UML建模的逻辑视图中就表示为用户服务包，应用服务包和数据服务包。本系统的应用服务包包含各种应用业务规则，例如工作票的业务流程、检修申请过程等。要将这些业务弄清楚并为以后做详细设计和编码的需要，就必须将应用服务包中的类划分清楚。类反映了系统的行为，对系统分析十分重要。因此，本文可视化建模的重点工作也是弄清应用服务包中的类及其相互关系。在UML中主要有三种类的形式：1） 边界类它位于系统与外界的交界处，包括所有界面窗体、报表等。2） 实体类它保存要放进持续存储体的信息，通过该类可以设计数据库。3） 控制类它负责协调其他类的工作，每个用例图通常都有一个控制类，控制用例图中的事件顺序。由于本系统的特点是时序性较强，如工作票的流程，检修申请的流程控制等，因此控制类在本系统中是非常重要的。本系统主要涉及到的实体类有：工作票信息；工艺卡信息；设备定检滚动计划表；月计划项目表；大、小修计划表；检修设备登记表；验收报告等。这些实体类与界面类的连接就是通过控制类来完成。控制类主要有：运行控制类，它相当于电厂运行部门的操作；工作票控制类，系统的不同用户可以通过它完成各种操作；检修控制类，通过它完成检修过程中的不同操作；工艺卡的编制、查询等控制类。类与类之间的继承、关联、依赖等关系也必须在建模时列出，通过类和类之间的关系反映出本系统的基本框架。在这些关系中，有一对多关系，也有多对多关系。系统中关于业务方面的类和类之间的关系可在UML中用类图表示出来。对于一些业务功能时序性较强的类，流程可用顺序图和合作图表示。本系统的一个类图如图2所示。图2 设备检修工艺卡管理类图该类图显示了检修工艺卡管理的静态行为。在类图中还可显示各个类的行为和属性。图中的箭头表示类之间的关系，它表示为一个类可以向另一个类发送消息。通过该类图可以完整的看到工艺卡管理系统的各个对象之间的关系，有助于开发人员在编码之前显示和计划系统结构，保证系统一开始就设计合理。5 结语本文描述的设备检修管理系统的前期开发工作已初步完成。由于采用了UML建模方法，在需求分析阶段和用户之间的沟通变的很方便。采用直观的图形表示，系统模型层次分明，对重要信息一目了然，用户可以通过模型直观的看到用户与系统间的交互关系，分析人员可以看到系统对象间的交互关系，项目管理人员可以看到整个系统及各部分的交互关系。可视化建模方法，使系统分析人员很方便进行业务规则的修改和设计，大大减轻了工作量，提高开发效率，特别有利于团队开发发行系统。参考文献：1. 华中理工大学能源科学与工程学院，火电厂状态检修概论，1997年11月2. 电子工业出版社，UML with Rational Rose从入门到精通，邱仲潘 等译3. 张启刚，电力设备管理与维修决策支持系统的研究与开发 华中理工大学硕士学位论文，2000.54. 北京航空航天大学软件工程研究所，标准建模语言UML及其支持环境，1998年Modeling equipment maintenance management system of power station with UMLLiu ZhiQiqng Huang ShuHong Gao WeiDepartment of Power EngineeringHuazhong University of Science and TechnologyAbstract: Condition maintenance is scientific mode of equipment maintenance. It is the base of condition maintenance that carring out advanced maintenance management and establishing equipment maintenance management system. In this paper, the cause of carring out the power equipment maintenance management system and the function demand of it are introduced. Meanwhile, the cause and feasibility of visual modeling the equipment maintenance management system of power station are discussed deeply. Furthermore, the basal frame of the equipment maintenance management system and the process of UML modeling are also discussed as 300MW unit of some power station an example.Keywords: power equipment, condition maintenance, Unified Modeling Language, Management Information System