火电厂设备检修管理系统的UML建模Word文档格式.doc
《火电厂设备检修管理系统的UML建模Word文档格式.doc》由会员分享，可在线阅读，更多相关《火电厂设备检修管理系统的UML建模Word文档格式.doc（8页珍藏版）》请在冰豆网上搜索。
但随着火电设备向高参数、大容量、复杂化发展，其安全经济运行对社会的影响也越来越大，维修投入大幅度上升。
面对这个情况，现行检修体制日益明显暴露出所存在的缺陷，因此对设备实行更先进、更科学的管理和检修体制，无论从火电厂自身的利益还是从社会的要求出发，都是势在必行。
状态检修是在设备状态监测的基础上，根据设备状态监测和分析诊断的结果安排检修时间和项目的检修体制。
所以，它是一种适应于市场经济和现代企业制度的全新的设备维修策略，根据我国国情，状态检修实际上是融故障检修、计划性检修、状态性检修、主动检修为一体的，具有最大的可靠性和最低的成本消耗的混合式优化检修体制。
目前，在火电厂推行状态检修所要达到的目标是：
延长定期检修间隔；
减少定期检修时间；
提高设备可靠性和可用系数；
增加发电量；
延长设备寿命；
降低运行检修费用；
减少资金投入；
改善电厂运行性能；
提高火电企业经济效益。
状态检修作为一种先进的检修体制，是一个涉及到技术、经济、体制等多方面的系统工程，涉及到许多管理问题。
要实行状态检修，必须使设备检修管理工作标准化，正确完整的技术数据和技术管理是状态检修的基础。
目前在电厂的设备检修工作管理中，由于设备的繁多和复杂，相对应的检修工作票、检修工艺卡的管理十分复杂，整个检修工作的过程管理也很复杂，大多数电厂都是单凭检修管理人员的脑力劳动和手工记录，这已经不能满足状态检修的要求。
因此，结合全厂设备管理信息化的建设，建立状态检修的计算机管理信息系统是推行这一体制的基础性工程。
本文论述了检修管理信息系统的设计和建模工作，并在系统的需求分析和总体设计中采用了可视化建模的方法。
大型信息管理系统建模是系统成败的关键，采用建模语言进行建模有利于系统的最后实施。
本文采用的建模语言是目前国际上流行的统一建模语言（UＭＬ）。
UML是一种定义良好、易于表达、功能强大且普遍适用的建模语言。
它溶入了软件工程领域的新思想、新方法和新技术。
它的作用域不仅限于支持面向对象的分析与设计，还支持从需求分析开始的软件开发的全过程。
2设备检修管理系统的需求分析
设备检修是设备全过程管理的一个重要环节，状态检修作为一种先进的检修体制，它的内容包括着很多管理方面的问题。
这些问题主要有：
数据的综合管理、检修风险分析与决策、备品备件管理、具体检修过程的实施管理、相应设备管理政策的制订、对检修效果的评估、专业人员的培训以及机构设置等问题。
而其中检修管理是是涉及到上述诸多问题的最主要管理工作。
检修管理包括设备缺陷管理；
检修工作票、工艺卡管理；
检修计划管理；
检修项目管理以及备品备件管理等。
它可为整个状态检修过程提供完备的技术数据、检修依据和检修过程的自动化控制。
因此，设备检修管理系统的实施对电厂实施状态检修有很重要的意义。
针对状态检修的要求，设备检修管理系统应通过以下五个子系统来满足其需求。
检修工作票、检修工艺卡管理系统
在系统中对设备的检修工作票集中管理，执行工作票办理、签发、接受、许可、变更、延期、终结、验收、完工处理等任务；
对设备检修工艺卡亦进行集中管理，提供录入、删除、查询、编辑等功能。
设备缺陷管理系统
该系统从人为发现缺陷开始，辅助检修部门组织人员进行消缺，同时详细记录消缺的整个过程，进行设备缺陷统计，为分析设备运行情况和部门考核提供科学依据，并为以后制定大修计划和对设备质量进行评估提供参考。
检修计划管理系统
对设备的定期检修计划进行管理，制定设备定检滚动计划表。
并可根据定检表生成月计划项目表和检修卡。
检修项目管理系统
通过状态监测和故障诊断分析出的诊断结果、设备事故和缺陷，提交设备检修申请。
针对所提交的申请，生成工程项目，规定该项目应执行的工作计划。
工程项目中包括检修开工处理及完工处理，检修结果的验收、评估，报表生成。
其检修作业管理模块对检修作业的四个阶段（分析监测、检修建议生成、作业单生成和检修开始、检修完成）进行管理，同时跟踪检修作业进行的状况，如检修建议是否送出、取消、等待批准，等待计划、等待材料、完成、完成封档等。
备品备件管理系统
对电厂设备的备品备件进行综合管理，能够随时提供设备的备件信息；
上述五个系统之间的联系非常紧密，要完成各自的功能都要用到其他系统的数据。
它们之间有的是并行处理，有的是顺序处理，而且所涉及到的系统用户种类很多，权限管理十分复杂，各个用户之间的业务联系错综复杂。
各系统下的子系统同样也是复杂多变，功能划分不易明确。
同时，系统还要兼容电厂已有的网络系统和厂级MIS系统。
因此，要能够准确完成系统的需求分析和总体设计，也就是对电厂的设备维修管理进行建模，从业务需求到要求，到模型，是一项很重要的工程，整个系统的成败也就在于建模的成功与否。
另外，考虑到团队开发以及系统的健壮性、伸缩性和良好的继承性、可维护性，选择一个在整个系统的生命周期中都适用的建模工具十分关键。
3统一建模语言UML和可视化建模
系统建模时，要把用户的业务需求映射到开发小组能理解的技术要求，并最终产生代码。
将业务需求和技术要求映射为代码，保证代码满足这些要求，而且代码最终可以方便的回溯要求。
这个过程称之为建模。
面向对象的分析与设计（OOA＆D）方法的发展在80年代末至90年代中出现了一个高潮，UML是这个高潮的产物。
它不仅统一了Booch、Rumbaugh和Jacobson的表示方法[2，4]，而且对其作了进一步的发展，并最终统一为大众所接受的标准建模语言。
1996年底，UML已稳占面向对象技术市场的85％，成为可视化建模语言事实上的工业标准。
1997年11月17日，OMG采纳UML1.1作为基于面向对象技术的标准建模语言。
标准建模语言UML的重要内容可以由下列五类图形（共9种图形）来定义:
·
第一类是用例图,从用户角度描述系统功能,并指出各功能的操作者（角色）。
第二类是静态图（Staticdiagram）,包括类图、对象图和包图。
其中类图描述系
统中类的静态结构。
不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构（类的属性和操作）。
类图描述的是一种静态关系,在系统的整个生命周期都是有效的。
对象图是类图的实例,几乎使用与类图完全相同的标识。
他们的不同点在于对象图显示类的多个对象实例,而不是实际的类。
一个对象图是类图的一个实例。
由于对象存在生命周期,因此对象图只能在系统某一时间段存在。
包由包或类组成,表示包与包之间的关系。
包图用于描述系统的分层结构。
第三类是行为图（Behaviordiagram）,描述系统的动态模型和组成对象间的交互
关系。
其中状态图描述类的对象所有可能的状态以及事件发生时状态的转移条件。
通常,状态图是对类图的补充。
在实用上并不需要为所有的类画状态图,仅为那些有多个状态其行为受外界环境的影响并且发生改变的类画状态图。
而活动图描述满足用例要求所要进行的活动以及活动间的约束关系,有利于识别并行活动。
第四类是交互图（Interactivediagram）,描述对象间的交互关系。
其中顺序图
显示对象之间的动态合作关系,它强调对象之间消息发送的顺序,同时显示对象之间的交互;
合作图描述对象间的协作关系,合作图跟顺序图相似,显示对象间的动态合作关系。
除显示信息交换外,合作图还显示对象以及它们之间的关系。
如果强调时间和顺序,则使用顺序图;
如果强调上下级关系,则选择合作图。
这两种图合称为交互图。
第五类是实现图（Implementationdiagram）。
其中构件图描述代码部件的物
理结构及各部件之间的依赖关系。
一个部件可能是一个资源代码部件、一个二进制部件或一个可执行部件。
它包含逻辑类或实现类的有关信息。
部件图有助于分析和理解部件之间的相互影响程度。
UML适用于系统开发过程中从需求规格描述到系统完成后测试的不同阶段。
在需求分析阶段，可以用用例来捕获用户需求。
通过用例建模，描述对系统感兴趣的外部角色及其对系统（用例）的功能要求。
分析阶段主要关心问题域中的主要概念（如抽象、类和对象等）和机制，需要识别这些类以及它们相互间的关系，并用UML类图来描述。
为实现用例，类之间需要协作，这可以用UML动态模型来描述。
在分析阶段，只对问题域的对象（现实世界的概念）建模，而不考虑定义软件系统中技术细节的类（如处理用户接口、数据库、通讯和并行性等问题的类）。
这些技术细节将在设计阶段引入，因此设计阶段为构造阶段提供更详细的规格说明。
编程（构造）是一个独立的阶段，其任务是用面向对象编程语言将来自设计阶段的类转换成实际的代码。
在用UML建立分析和设计模型时，应尽量避免考虑把模型转换成某种特定的编程语言。
因为在早期阶段，模型仅仅是理解和分析系统结构的工具，过早考虑编码问题十分不利于建立简单正确的模型。
UML模型还可作为测试阶段的依据。
系统通常需要经过单元测试、集成测试、系统测试和验收测试。
不同的测试小组使用不同的UML图作为测试依据：
单元测试使用类图和类规格说明；
集成测试使用部件图和合作图；
系统测试使用用例图来验证系统的行为；
验收测试由用户进行，以验证系统测试的结果是否满足在分析阶段确定的需求。
可视化建模将模型中的信息用标准的图形元素直观地显示。
目前，支持UML可视化快速开发应用程序的工具很多，其中Rational公司的RationalRose是其中之一，它支持UseCase框图，Sequence框图等图。
通过正向和逆向转出工程代码特性，可支持C++，Java，VisualBasic的代码产生和逆向转出工程代码。
4电厂设备检修管理系统的建模
本系统采用UML语言进行建模。
第一步工作是系统的需求分析，而需求分析必须以针对该系统的调研为基础。
在调研过程中，可针对现行系统和信息需求进行分析，并得出系统的功能需求分析。
用例模型用于需求分析阶段，它的建立是系统开发者和用户反复讨论的结果，表明了开发者和用户对需求规格达成的共识。
清楚表达系统的用例图往往不是一次就能做好的，必须在对系统所涉及的业务充分了解下，才能不断完善，它反映了系统与外界的交互作用。
以某300MW火电机组为例，根据需求分析，建立起一个初步的框架。
系统按上述五个子系统进行功能划分。
系统涉及业务和各种人员类型很多，若是将其用一个用例图表达是不可能的，因此，对应五个子系统将用例分成了五个包，每个包中若涉及的业务和系统人员仍比较复杂的话，还可以在此包的基础上再分若干包，包中包含了用例图。
而包图将类似项目组合在一起，显示包与包之间的依赖、继承关系。
用例图中的角色（Actor）对形成用例图是非常有用的，获取一个用例，首先就要找到与之关联的角色。
面对一个大系统，要列出用例清单常常是十分困难。
这时可先列出角色清单，再对每个角色列出它的
升级会员 