CN104391701A - 一种能效评估软件开发方法 - Google Patents

Abstract

本发明公开了一种能效评估软件开发方法，包括：模块划分；对模块划分得到的各组件，进行组件封装；基于组件封装得到的封装包，进行服务发布；基于服务发布的消息，进行系统搭建。本发明所述能效评估软件开发方法，可以克服现有技术中劳动量大、花费时间长和资源耗费量大等缺陷，以实现劳动量小、花费时间短和资源耗费量小的优点。

Description

一种能效评估软件开发方法

技术领域

本发明涉及电力节能技术领域，具体地，涉及一种能效评估软件开发方法。

背景技术

计算机技术的高速发展为能效数据实时管理、能效快速评估、能效智能分析及节能方案自动生成提供了技术支持。传统能效评估测评往往采用人工统计数据，简单应用几个指标进行评估评估，整个过程纯手工完成；更进步一点的是针对用能机构开发一个简单的能效评估评估系统，实现能效评估自动化，而这两种能效评估评估方式都很难应用到电网的评估评估。

采用手工完成评估评估，不仅耗费大量时间，还耗费大量的人力和物力；同时，电网又是动态变化的，随着节能意识的提高，很多新的节能设备会不断加入电网，从而使原来的评估评估系统已经不适用现状，需要对系统进行修改或重新开发，而软件行业的一般特点是人员的流动性大，因此，一般情况下，只能重新开发系统，从而造成资源的浪费。

在实现本发明的过程中，发明人发现现有技术中至少存在劳动量大、花费时间长和资源耗费量大等缺陷。

发明内容

本发明的目的在于，针对上述问题，提出一种能效评估软件开发方法，以实现劳动量小、花费时间短和资源耗费量小的优点。

为实现上述目的，本发明采用的技术方案是：一种能效评估软件开发方法，包括：

a、模块划分；

b、对模块划分得到的各组件，进行组件封装；

c、基于组件封装得到的封装包，进行服务发布；

d、基于服务发布的消息，进行系统搭建。

进一步地，所述步骤a，具体包括：将能效评估所需的数据、评估指标、评估方法、评估标准划分成相对独立的模块；和/或，

所述步骤b，具体包括：采用组件技术、Web Service技术和面向服务的体系架构将模块划分的结果封装成组件，并入库形成组件库；和/或，

所述步骤c，具体包括：将Web服务在通用描述、发现与集成服务上进行注册，对外进行发布；和/或，

所述步骤d，具体包括：基于综合集成平台，定制组件库的组件，绘制业务流程知识图，将组件添加至知识图，形成能效评估软件。

进一步地，所述步骤a中，将能效评估所需的数据、评估指标、评估方法、评估标准划分成相对独立的模块的操作，进一步包括：模块的划分需要考虑的因素较多，一般主要考虑模块的大小、功能和相对独立性：

(1)模块的大小

模块的大小是模块划分首先需要考虑的因素，模块大小划分是否合理直接关系到整个系统的移植和扩展特性；

(2)模块的功能

模块的功能是模块划分的主要参考依据，模块的划分首先要保证该模块能够实现业务系统中的某项功能；同时，模块的功能是决定该模块的能否被共用的基本条件，因此，模块划分时，应从功能角度考虑模块划分，保证划分的模块最大程度的共用。可以认为，模块划分，首先划分能够共用的模块，然后将剩余功能划分成不可共用模块即可；

(3)模块的相对独立性

模块的相对独立性也是模块划分过程中需要考虑的一个重要因素，模块的相对独立是指模块本身具有一定的独立功能，只要给定数据，即可实现该功能，模块的相对独立是后期组件搭建系统的基础条件。

进一步地，所述步骤b中，采用组件技术、Web Service技术和面向服务的体系架构将模块划分的结果封装成组件，并入库形成组件库的操作，进一步包括：

2.1)组件技术

组件封装即将划分好的应用模块，采用组件封装的相关技术，封装成组件，能效评价系统是在综合集成平台之上，采用组件搭建的方式实现的；组件封装实际上就是业务应用模块的程序化实现，组件封装相关技术主要有组件技术、Web Service技术和面向服务的体系结构；

2.2)Web Service技术

Web Service是一种组件技术，其采用XML格式封装数据，对自身功能进行描述时采用WSDL，同时，要想使用Web Service提供的各种服务，必须对其进行注册，可以使用UDDI来实现，组件之间数据的传输是通过SOAP协议进行的；

Web Service主要建立在服务提供者、请求者和注册中心之间相互交互的基础之上，交互的内容主要有查找、发布和绑定；

2.3)面向服务的体系结构

面向服务的体系结构是一种新的面向服务架构的编程模型，号称“下一代软件架构”，其内核就是“业务敏捷化”，它将应用程序的不同功能单元(称为服务)，通过这些服务之间定义良好的接口和契约联系起来；接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

进一步地，所述步骤c中，将Web服务在通用描述、发现与集成服务上进行注册，对外进行发布的操作，进一步包括：

首先需要将开发的组件打包成Web服务，采用Axis进行打包；

Web服务形成后，将该服务上传至服务器，同时，通过UDDI对该Web服务进行注册，注册后能够使用Web服务，最终的Web服务其实就是组件库。

进一步地，所述步骤d中，基于综合集成平台，定制组件库的组件，绘制业务流程知识图，将组件添加至知识图，形成能效评估软件的操作，进一步包括：

4.1)综合集成平台

综合集成平台是应用系统间的桥梁，是应用系统和数据库之间的纽带，构建综合集成平台的目的就是能够使应用系统具有灵活性、适应性，以适应实际业务中的多变特性；

基于平台技术模型，采用中间件技术、综合集成研讨厅技术、组件技术，基于面向服务的体系结构和J2EE架构，构建了综合集成平台原型；

4.2)系统搭建流程：在综合集成平台系统之上搭建能效评价系统。

进一步地，所述综合集成平台，更进一步包括：

(1)应用服务控制层，用于对系统行为以及其它资源进行关联和控制，包括对组件所提供的服务和系统资源的配置和控制，对业务流程的关联和控制以及对人机交互界面的关联和控制；

(2)人机交互服务层，用于提供业务系统常用的多种应用软件服务，用户可以根据自身需求定制所需要的服务，实现个性化服务；

(3)业务逻辑服务层，用于描述业务活动以及业务活动之间的时序关系和控制关系，是一组基于业务逻辑访问接口的业务功能；

(4)外部应用服务层，用于为各种外部应用遗留系统提供集成功能；

(5)服务访问接口，用于为具体的应用主题提供了访问具体业务功能服务的途径，同时支持业务应用层与信息处理平台进行数据交换，为上下层之间进行通信提供一种途径；

(6)人机访问接口，用于为业务应用与平台提供的各类服务之间、平台内各层服务之间以及同层内不同服务软件之间的接口；

(7)业务逻辑访问接口，用于使业务功能服务隐藏其内部处理细节，仅对外公布它必须支持的属性，为上下层之间进行通信提供一种途径，方便业务功能服务的开发、查询、发布；

(8)外部应用访问接口，用于为特定业务应用以及应用支撑软件与外部实体之间的交互服务提供接口，为了实现应用的互操作性和数据的可移植性，它必须将协议的状态、格式和语法标准化。

进一步地，所述在综合集成平台系统之上搭建能效评价系统的操作，更进一步包括：

(1)能效评价业务流程知识图的绘制

绘制业务流程知识图，需要对能效评价业务非常了解，同时也要了解各个组件之间的衔接关系，最好是组件的开发者，否则需要每个组件的详细说明、组件的输入和输出及功能介绍；

(2)能效评价业务组件的定制

能效评价组件定制过程很简单，通过平台进入组件库，选择需要的组件，命名后保存到相应的位置即可；

(3)组件的添加及系统运行

通过绘制好的业务流程知识图，对应知识图中的每个节点，将对应的组件添加节点即可，然后保存后，即可运行系统。

本发明各实施例的能效评估软件开发方法，由于包括：模块划分；对模块划分得到的各组件，进行组件封装；基于组件封装得到的封装包，进行服务发布；基于服务发布的消息，进行系统搭建；可以通过能效平台实现能效系统快速搭建、能效系统可复制、能效系统快速修改和应用；从而可以克服现有技术中劳动量大、花费时间长和资源耗费量大的缺陷，以实现劳动量小、花费时间短和资源耗费量小的优点。

本发明的其它特征和优点将在随后的说明书中阐述，并且，部分地从说明书中变得显而易见，或者通过实施本发明而了解。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

附图用来提供对本发明的进一步理解，并且构成说明书的一部分，与本发明的实施例一起用于解释本发明，并不构成对本发明的限制。在附图中：

图1为本发明中能效评估软件开发方法基本流程；

图2为本发明中考虑功能的模块划分图；

图3为本发明中Web Service体系结构图；

图4为本发明中综合集成平台技术模型图；

图5为本发明中综合集成平台原型系统图；

图6为本发明中系统搭建流程图。

具体实施方式

以下结合附图对本发明的优选实施例进行说明，应当理解，此处所描述的优选实施例仅用于说明和解释本发明，并不用于限定本发明。

针对现有技术存在的缺陷，根据本发明实施例，如图1-图6所示，提供了一种能效评估软件开发方法。本发明的技术方案，提出基于组件技术、WebService技术和SOA架构的综合集成技术，并在此基础之上构建能效测评基础平台，通过能效平台实现能效系统快速搭建、能效系统可复制、能效系统快速修改和应用，从而应对节能设备和电网的变化和发展，使能效评估系统具有极高的可扩展性和移植性，同时节约了人力和物力资源。

本发明的技术方案，针对目前能效评估软件开发方面存在的开发方式不灵活，重复性开发以及软件难以移植和维护等缺陷，提出在综合集成平台之上，采用搭建组件的方式开发能效评估软件，从而提高能效评估软件的移植性和维护性。

本发明所采用的技术方案是：一种能效评估软件开发方法，依次包括依次连接的模块划分、组件封装、服务发布和系统搭建四个部分。

其中，上述的模块划分是将能效评估所需的数据、评估指标、评估方法、评估标准等划分成相对独立的模块。组件封装是采用组件技术、Web Service技术和面向服务的体系架构将模块划分的结果封装成组件，并入库形成组件库。服务发布，是将Web服务在通用描述、发现与集成服务上进行注册，对外进行发布。系统搭建，是基于综合集成平台，定制组件库的组件，绘制业务流程知识图，将组件添加至知识图，形成能效评估软件。

具体地，参见图1-图6，基于综合集成平台进行能效评估系统开发的基本思路是，基于综合集成平台，采用组件搭建的方式构建系统，该开发与传统业务系统开发有很大的区别。首先，系统的各个模块的开发变成各个组件的开发，且一般业务组件不直接与数据库关联，而是有专门的数据组件，这样避免了数据库有变动时会导致组件重新开发；其次，系统是通过各个组件搭建而成，非常灵活；最后，系统非常容易维护，系统要求发生变化，只需对个别组件重新开发或开发新的组件即可，无需重新开发系统，从而使系统具有很强的移植性和扩展性。基于综合集成平台的能效评估系统开发模式基本流程如图1所示。

能效评估软件开发方法包括依次连接的模块划分、组件封装、服务发布和系统搭建四个部分，下面对个四个部分进行详细说明。

1、模块划分

传统能效评估系统往往针对某一企业开发一套独立系统，不将应用进行模块划分，直接给出最后的应用结果，也不从最终系统的可移植性、可扩展性方面考虑。模块划分的主要目的是在实现能效评估功能的基础之上，方便系统移植和扩展；同时，模块的划分使得应用的各个环节都是透明的，更加方便系统维护。模块划分之所以能够实现系统的移植和扩展，主要原因如下：

(1)模块划分后，系统由多个应用模块组成，每个模块具有一定的功能，那么若系统需要扩展，则只需增加新的模块即可，原来的模块可以不改变。

(2)若对于同一类型的企业，大部分应用模块是可以通用的，只需去掉多余模块，并新增少量模块即可，从而大大减少开发量，系统也可以很好的实现移植。

(3)若系统需要进行修改或更新，只需对要改变的功能模块进行更新，不改变其他模块，从而使维护的工作量降到最低，大大节约了成本，避免了浪费，实现了节能。

将能效评估系统划分成多个应用模块并不是随便划分，也不是任何人员都可以划分，需要既熟悉业务功能又熟悉程序开发的人员进行划分，对人员的综合素质要求较高。模块的划分需要考虑的因素较多，一般主要考虑模块的大小、功能和相对独立性。

(1)模块的大小

模块的大小是模块划分首先需要考虑的因素，模块大小划分是否合理直接关系到整个系统的移植和扩展特性。传统系统开发可以认为将整个系统划分为一个大模块，从而使得系统很难扩展，因此模块的划分不能太大；同时，模块的划分也不是越小越好，模块的划分应该以该模块是否可以共用为标准，一些模块划分出来也永远不会被共用，则只会增加工作量。

(2)模块的功能

模块的功能是模块划分的主要参考依据，模块的划分首先要保证该模块能够实现业务系统中的某项功能。同时，模块的功能是决定该模块的能否被共用的基本条件，因此，模块划分时，应从功能角度考虑模块划分，保证划分的模块最大程度的共用。可以认为，模块划分，首先划分能够共用的模块，然后将剩余功能划分成不可共用模块即可。如图2示。

图2中，整个系统可以看作一个大模块，通过功能的共用考虑，可以划分出三个“可共用模块”，那么大模块被划分后则会自然划分出四个“不可共用模块”，系统则被划分为七个模块。

(3)模块的相对独立性

模块的相对独立性也是模块划分过程中需要考虑的一个重要因素，模块的相对独立是指模块本身具有一定的独立功能，只要给定数据，即可实现该功能，模块的相对独立是后期组件搭建系统的基础条件。

对能效评估进行模块划分，主要分为九类模块，模块的划分结果及考虑因素如表1所示。

表1：能效评估模块划分

2、组件封装

能效评估组件封装主要采用组件技术、Web Service技术和面向服务的体系结构。

2.1)组件技术

组件封装即将划分好的应用模块，采用组件封装的相关技术，封装成组件，能效评价系统是在综合集成平台之上，采用组件搭建的方式实现的。组件封装实际上就是业务应用模块的程序化实现，组件封装相关技术主要有组件技术、Web Service技术和面向服务的体系结构。

组件是“软件危机”环境下的一种产物，目的是提高软件的重用性，主要思想是将软件封装成组件，并通过接口能够实现对组件的访问。软件复用的概念早在1968年就被提出，且有一套软件复用的指标性标准，其中包括了实现的基本思路。

组件具有以下特点。

1)重用性和互操作性强。重用是组件的最大特色，指完成某一系统时，多个模块的软件可以重复利用，而不需要重新写代码实现。

2)实现细节透明。组件在运行过程中，输入和输出接口完全是透明的，它的实现和功能完全分离，从而对于应用组件来说，只关心输入和输出两个接口即可，无需关心组件内部。

3)良好的可扩展性。每个组件都是独立的，有其独有功能，若需要组件提供新的功能，对组件来说，只需增加接口，不改变原来的接口，从而实现组件功能的扩展。

4)即插即用。组件的使用就类似于搭积木一样，可以随时搭建，随时使用。

5)开发与编程语言无关。开发人员可以选用任何语言开发组件，只要符合组件开发标准，组件编译后可以采用二进制形式发布，避免源代码泄漏，保护开发者的版权。

2.2)Web Service技术

Web Service是一种组件技术，其采用XML格式封装数据，对自身功能进行描述时采用WSDL，同时，要想使用Web Service提供的各种服务，必须对其进行注册，可以使用UDDI来实现，组件之间数据的传输是通过SOAP协议进行的。Web Service具有与平台和开发语言无关的特性，无论基于什么语言和平台，只要指定其位置和接口，就能在应用端通过SOAP可以实现接口的调用，同时得到返回值。

虽然传统的组件技术，如DCOM，也可以进行远程调用，但其使用的通信协议不是Internet协议，就会有防火墙的障碍，也不能实现Internet共享。并且它们由不同公司提出，采用规范不一致，因而不能通用。

Web Service主要建立在服务提供者、请求者和注册中心之间相互交互的基础之上，交互的内容主要有查找、发布和绑定。三者之间关系如图3所示。

2.3)面向服务的体系结构

面向服务的体系结构(Service-Oriented Architecture，SOA)是一种新的面向服务架构的编程模型，号称“下一代软件架构”，其内核就是“业务敏捷化”，它将应用程序的不同功能单元(称为服务)，通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种系统中的服务可以以一种统一和通用的方式进行交互。

SOA的核心思想却是：

(1)SOA是一种软件架构思想，并不是一种产品。

(2)SOA的重点是面向服务，此服务包括企业的内部与外部的每一个业务细节，比如企业中财务应收发票的处理就是一个服务。SOA的思想是把这些服务从复杂的环境中独立出来——组件化封装，然后通过标准的接口使不同的服务之间相互调用。在此过程中需注意以下两点：①每个服务有一个明确的界限，其他服务只能通过接口来调用服务。②每个服务是独立自主的，每个服务不必依赖于其他的系统。

无论如何定义和诠释SOA的概念，其核心思想是不变的，那就是服务，SOA的重点是面向服务的。服务不依赖于某一独立的系统，它具有可互操作性、独立性、松耦合性。面向服务的系统设计和开发，将信息的复杂性隐藏在服务的模块之中，将服务从复杂的环境中独立出来，不考虑其内部的具体实现，使其通过服务的交互或者组合来完成系统的实现。

目前，SOA参考模型分为抽象模型、层次模型和基于特定应用平台的模型3类。

(1)抽象模型：①OASIS提出的OASIS-RM参考模型。②2004年，W3C的Web服务架构工作组提出的面向服务体系结构模型。

(2)层次模型：IBM以堆栈的形式给出了SOA参考模型。

(3)特定应用平台的SOA参考模型：①IBM提出的SOA Foundation参考模型，是以企业服务总线ESB为核心的全面企业解决方案，包括建模和组装、部署和服务管理；②普元软件提出了对工作流WfMC参考模型进行扩展，提供了灵活的工作流路由模型、激活策略以及版本控制策略。EOS将组件技术、XML企业总线技术和可视化开发技术完美结合，通过图形化的组件单元作为应用系统的基本组成元素；③Oracle公司提出了融合体系结构，是将网格计算体系结构、面向服务的体系结构以及企业信息体系结构提出了具有凝聚力的统一模型；④SUN提出的SOA参考模型包括服务组合、服务控制、合成应用平台、服务分发、服务接入等5个功能，建立在Web服务基础之上；⑤SAP公司将SOA模型演变成为企业服务架构ESA，由用户接口、复合应用、业务流程平台和基础应用组成。

这3类模型各有其鲜明的特点，抽象模型着眼于概念层面，高度抽象地指出SOA的基本元素和它们之间的关系，有利于我们对SOA思想的理解。①抽象模型很有可能发展成为标准的SOA参考模型，但对SOA的实际应用缺乏具体指导。②层次模型立足于传统的IT架构3层结构，经过细化和演变，基本上包括数据层、服务层、服务组合编排层、业务流程层和表示层，而服务质量管理则贯穿各层。层次模型是具有实用意义的SOA参考模型，有一定程度的抽象但又利于理解，建立了分层结构但又独立于具体技术。企业实施SOA时，无论采用什么技术或产品平台，都可以优先选择层次模型作为自己的SOA参考模型，易于发展成为具体的企业参考架构。③基于特定应用平台的模型侧重于应用层面，提出了符合该公司产品套件应用的参考模型，更贴近于具体参考架构，但不具有普遍意义。如果企业全面采用了某一平台的产品套件，也就选择了它的SOA参考模型。

3、服务发布

要使做好的组件能够使用，首先需要将开发的组件打包成Web服务，采用Axis进行打包。Axis本质上就是一个SOAP引擎，提供创建服务器端、客户端和网关SOAP操作的基本框架，同时能够在建立和运转时有能力部署Web服务。Web服务形成后，将该服务上传至服务器，同时，通过UDDI(一种目录服务，企业可以使用它对Webservices进行注册和搜索)对该Web服务进行注册，注册后可以使用Web服务，最终的Web服务其实就是组件库。

4、系统搭建

系统搭建需要建立在综合集成平台之上，因此首先进行综合集成平台介绍。

4.1)综合集成平台

综合集成平台是应用系统间的桥梁，是应用系统和数据库之间的纽带，构建综合集成平台的目的就是能够使应用系统具有灵活性、适应性，以适应实际业务中的多变特性。因此，基于综合集成平台应该能够快速构建能效评估业务系统，并能够通过简洁的方式快速增加、修改系统的功能，实现系统的移植和扩展，从而满足业务发展需求。因此，综合集成平台在设计和实现必须满足以下要求：

(1)资源的整合。能效评估需要多种数据和信息资源，这些数据和资源可能分布地点不同、结构类型不同，有结构化、半结构化和非结构化的数据，综合集成平台可以实现各种类型资源的整合。

(2)提供系统的开发环境。基于综合集成平台来实现能效评估系统目的是通过综合集成平台为能效系统开发提供一个集成开发环境，通过平台提供的环境可快速搭建理想的能效评估系统。

(3)基于松耦合的信息共享。基于综合集成平台构建能效评估系统可实现底层数据和上层的业务应用分离，从而保证系统灵活多变，具有很强的适应性。

(4)配置可伸缩。平台能够根据业务的复杂程度进行不同级别配置，从而保证系统的经济性。

(5)服务个性化。平台能够根据不同的实用者按需求定制服务，满足不同用户的需求。

(6)能够重构和扩展。在综合集成平台之上，能效评估业务系统应能够很快实现扩展和重构。

(7)提高系统开发效率。通过综合集成平台，可通过搭建组件的方式快速构建能效评估系统，同时能够通过简洁的方式增加、修改、删除系统的业务功能。

采用SOA、SaaS、PaaS等面向服务的信息化整合技术，对信息服务、决策服务实施有机集成，在计算服务的支持下建设综合集成平台，综合集成平台的技术模型如图4所示。

根据平台的技术模型，平台主要包括：

(1)应用服务控制层。主要实现对系统行为以及其它资源进行关联和控制，包括对组件所提供的服务和系统资源的配置和控制，对业务流程的关联和控制以及对人机交互界面的关联和控制。

(2)人机交互服务层。提供业务系统常用的多种应用软件服务，用户可以根据自身需求定制所需要的服务，实现个性化服务。

(3)业务逻辑服务层。用于描述业务活动以及业务活动之间的时序关系和控制关系，是一组基于业务逻辑访问接口的业务功能。

(4)外部应用服务层。为各种外部应用遗留系统提供集成功能。

(5)服务访问接口。为具体的应用主题提供了访问具体业务功能服务的途径，同时支持业务应用层与信息处理平台进行数据交换，为上下层之间进行通信提供一种途径。服务访问接口应以标准的XML文档描述业务组件与功能的时序和组合关系。

(6)人机访问接口。是业务应用与平台提供的各类服务之间、平台内各层服务之间以及同层内不同服务软件之间的接口。

(7)业务逻辑访问接口。使业务功能服务隐藏其内部处理细节，仅对外公布它必须支持的属性，为上下层之间进行通信提供一种途径，方便业务功能服务的开发、查询、发布等。

(8)外部应用访问接口。为特定业务应用以及应用支撑软件与外部实体之间的交互服务提供接口，为了实现应用的互操作性和数据的可移植性，它必须将协议的状态、格式和语法标准化。

基于上述平台技术模型，采用中间件技术、综合集成研讨厅技术、组件技术，基于面向服务的体系结构和J2EE架构，构建了综合集成平台原型，如图5所示。

4.2)系统搭建流程

在综合集成平台系统之上搭建能效评价系统非常简单，主要分为以下三步。

(1)能效评价业务流程知识图的绘制

绘制业务流程知识图，需要对能效评价业务非常了解，同时也要了解各个组件之间的衔接关系，最好是组件的开发者，否则需要每个组件的详细说明、组件的输入和输出及功能介绍等。在综合集成平台上绘制业务流程，类似于在Visio上绘图，非常简单。

(2)能效评价业务组件的定制

能效评价组件定制过程很简单，通过平台进入组件库，选择需要的组件，命名后保存到相应的位置即可。

(3)组件的添加及系统运行

通过绘制好的业务流程知识图，对应知识图中的每个节点，将对应的组件添加节点即可，然后保存后，即可运行系统。系统搭建过程如图6所示。

图6展示的是知识图的编辑界面，每个节点代表一个组件，两个组件之间的连线代表数据流，箭头的方向代表数据的流向，两个组件之间的数据是标准的XML。保存后，可进入知识图的应用界面。

综上所述，本发明的有益效果是，通过建立能效评估软件开发方法，使能效评估软件开发具有可移植性、可扩展性、易维护性、模块化应用、快速搭建应用、综合集成等特性，从而能够有效应对业务应用多变的需求。

最后应说明的是：以上所述仅为本发明的优选实施例而已，并不用于限制本发明，尽管参照前述实施例对本发明进行了详细的说明，对于本领域的技术人员来说，其依然可以对前述各实施例所记载的技术方案进行修改，或者对其中部分技术特征进行等同替换。凡在本发明的精神和原则之内，所作的任何修改、等同替换、改进等，均应包含在本发明的保护范围之内。

Claims (8)

1.一种能效评估软件开发方法，其特征在于，包括：

a、模块划分；

b、对模块划分得到的各组件，进行组件封装；

c、基于组件封装得到的封装包，进行服务发布；

d、基于服务发布的消息，进行系统搭建。

2.根据权利要求1所述的能效评估软件开发方法，其特征在于，所述步骤a，具体包括：将能效评估所需的数据、评估指标、评估方法、评估标准划分成相对独立的模块；和/或，

所述步骤b，具体包括：采用组件技术、Web Service技术和面向服务的体系架构将模块划分的结果封装成组件，并入库形成组件库；和/或，

所述步骤c，具体包括：将Web服务在通用描述、发现与集成服务上进行注册，对外进行发布；和/或，

所述步骤d，具体包括：基于综合集成平台，定制组件库的组件，绘制业务流程知识图，将组件添加至知识图，形成能效评估软件。

3.根据权利要求2所述的能效评估软件开发方法，其特征在于，所述步骤a中，将能效评估所需的数据、评估指标、评估方法、评估标准划分成相对独立的模块的操作，进一步包括：模块的划分需要考虑的因素较多，一般主要考虑模块的大小、功能和相对独立性：

（1）模块的大小

模块的大小是模块划分首先需要考虑的因素，模块大小划分是否合理直接关系到整个系统的移植和扩展特性；

（2）模块的功能

模块的功能是模块划分的主要参考依据，模块的划分首先要保证该模块能够实现业务系统中的某项功能；同时，模块的功能是决定该模块的能否被共用的基本条件，因此，模块划分时，应从功能角度考虑模块划分，保证划分的模块最大程度的共用；

可以认为，模块划分，首先划分能够共用的模块，然后将剩余功能划分成不可共用模块即可；

（3）模块的相对独立性

模块的相对独立性也是模块划分过程中需要考虑的一个重要因素，模块的相对独立是指模块本身具有一定的独立功能，只要给定数据，即可实现该功能，模块的相对独立是后期组件搭建系统的基础条件。

4.根据权利要求2所述的能效评估软件开发方法，其特征在于，所述步骤b中，采用组件技术、Web Service技术和面向服务的体系架构将模块划分的结果封装成组件，并入库形成组件库的操作，进一步包括：

2.1）组件技术

组件封装即将划分好的应用模块，采用组件封装的相关技术，封装成组件，能效评价系统是在综合集成平台之上，采用组件搭建的方式实现的；组件封装实际上就是业务应用模块的程序化实现，组件封装相关技术主要有组件技术、Web Service技术和面向服务的体系结构；

2.2）Web Service技术

Web Service是一种组件技术，其采用XML格式封装数据，对自身功能进行描述时采用WSDL，同时，要想使用Web Service提供的各种服务，必须对其进行注册，可以使用UDDI来实现，组件之间数据的传输是通过SOAP协议进行的；

Web Service主要建立在服务提供者、请求者和注册中心之间相互交互的基础之上，交互的内容主要有查找、发布和绑定；

2.3）面向服务的体系结构

面向服务的体系结构是一种新的面向服务架构的编程模型，号称“下一代软件架构”，其内核就是“业务敏捷化”，它将应用程序的不同功能单元（称为服务），通过这些服务之间定义良好的接口和契约联系起来；接口是采用中立的方式进行定义的，它应该独立于实现服务的硬件平台、操作系统和编程语言。

5.根据权利要求2所述的能效评估软件开发方法，其特征在于，所述步骤c中，将Web服务在通用描述、发现与集成服务上进行注册，对外进行发布的操作，进一步包括：

首先需要将开发的组件打包成Web服务，采用Axis进行打包；

Web服务形成后，将该服务上传至服务器，同时，通过UDDI对该Web服务进行注册，注册后能够使用Web服务，最终的Web服务其实就是组件库。

6.根据权利要求2所述的能效评估软件开发方法，其特征在于，所述步骤d中，基于综合集成平台，定制组件库的组件，绘制业务流程知识图，将组件添加至知识图，形成能效评估软件的操作，进一步包括：

4.1）综合集成平台

综合集成平台是应用系统间的桥梁，是应用系统和数据库之间的纽带，构建综合集成平台的目的就是能够使应用系统具有灵活性、适应性，以适应实际业务中的多变特性；

基于平台技术模型，采用中间件技术、综合集成研讨厅技术、组件技术，基于面向服务的体系结构和J2EE架构，构建了综合集成平台原型；

4.2）系统搭建流程：在综合集成平台系统之上搭建能效评价系统。

7.根据权利要求6所述的能效评估软件开发方法，其特征在于，所述综合集成平台，更进一步包括：

（1）应用服务控制层，用于对系统行为以及其它资源进行关联和控制，包括对组件所提供的服务和系统资源的配置和控制，对业务流程的关联和控制以及对人机交互界面的关联和控制；

（2）人机交互服务层，用于提供业务系统常用的多种应用软件服务，用户可以根据自身需求定制所需要的服务，实现个性化服务；

（3）业务逻辑服务层，用于描述业务活动以及业务活动之间的时序关系和控制关系，是一组基于业务逻辑访问接口的业务功能；

（4）外部应用服务层，用于为各种外部应用遗留系统提供集成功能；

（5）服务访问接口，用于为具体的应用主题提供了访问具体业务功能服务的途径，同时支持业务应用层与信息处理平台进行数据交换，为上下层之间进行通信提供一种途径；

（6）人机访问接口，用于为业务应用与平台提供的各类服务之间、平台内各层服务之间以及同层内不同服务软件之间的接口；

（7）业务逻辑访问接口，用于使业务功能服务隐藏其内部处理细节，仅对外公布它必须支持的属性，为上下层之间进行通信提供一种途径，方便业务功能服务的开发、查询、发布；

（8）外部应用访问接口，用于为特定业务应用以及应用支撑软件与外部实体之间的交互服务提供接口，为了实现应用的互操作性和数据的可移植性，它必须将协议的状态、格式和语法标准化。

8.根据权利要求6所述的能效评估软件开发方法，其特征在于，所述在综合集成平台系统之上搭建能效评价系统的操作，更进一步包括：

（1）能效评价业务流程知识图的绘制

绘制业务流程知识图，需要对能效评价业务非常了解，同时也要了解各个组件之间的衔接关系，最好是组件的开发者，否则需要每个组件的详细说明、组件的输入和输出及功能介绍；

（2）能效评价业务组件的定制

能效评价组件定制过程很简单，通过平台进入组件库，选择需要的组件，命名后保存到相应的位置即可；

（3）组件的添加及系统运行

通过绘制好的业务流程知识图，对应知识图中的每个节点，将对应的组件添加节点即可，然后保存后，即可运行系统。