一种电力营销系统构建方法及装置与流程

本发明涉及电力数据处理技术领域，尤其涉及一种电力营销系统构建方法及装置。

背景技术：

电力营销就是电力企业在变化的市场环境中，以满足人们的电力消费需求为目的，提供满足消费需要的电力产品和相应的服务的过程。电力营销的实质就是要调整电力市场的需求水平、需求时间，以良好的服务质量满足用户合理用电的要求，实现电力供求之间的相互协调，建立电力企业与用户之间的合作伙伴关系，促使用户主动改变消费行为和用电方式，提高用电效率。

目前，广泛使用的电力营销系统的构建方式为：结构化生命周期法，又称瀑布法。该方法中，为了保证工作质量和以后各阶段开发的正确性，减少系统开发的盲目性，在明确用户需求之前，不得进行下一阶段的工作。而为了便于管理和控制，对生命周期的各个阶段严格划分，每个阶段都设置有明确的任务和目标，而各个阶段又可被分为若干工作和步骤。前阶段工作成果是后阶段工作的依据，不能反复修改。并且，为了保证通信内容的正确理解，使系统开发人员及用户有共同的语言，要求文档采用标准化、规范化、确定的格式和术语以及图形图表。最后，将系统划分为相互联系又相对独立的子系统直至模块，综合使已实施的子系统就能够成为完整的系统以体现系统的总体功能。并且，在上述过程中，每完成一个阶段就需要进行测试，以保证设计开发过程的顺利进行。

由此可以看出，从需求到设计，从设计到编码，从编码到测试，从测试到提交大概这样的流程，要求每一个开发阶段的要求都非常严格，尤其是前期对于客户的需求分析，要做到准确，以避免出现后续的修改或者增加，但是，对于目前的技术实现，很难在设计初期就将需求完全准确的确定，因此，该方法无法满足用户对于构建系统灵活性的越来越高的需求。

技术实现要素：

有鉴于此，本发明的目的在于提供一种电力营销系统构建方法及装置，以实现灵活构建电力营销系统的目的，具体方案如下：

一种电力营销系统构建方法，应用于预先构建的电力营销系统构建平台，该方法包括：

接收用户输入的系统构建指令，所述系统构建指令中至少包括：用户类型及需求信息；

依据所述用户类型解析所述需求信息，获得所述需求信息对应的业务场景下的至少一个业务对象及所述业务对象间的逻辑关系，所述业务对象用于表征所述业务场景下的业务角色、业务实体及业务属性；

分析所述业务对象，确定所述业务对象对应的至少一个业务单元，所述业务单元为按照预设规则拆分得到的，具有独立完成某一业务操作功能的最小逻辑组件；

依据所述至少一个业务单元间的逻辑关系，封装各业务对像对应的至少一个业务单元，获得与该业务对象对应的业务模块；

依据所述业务场景下的至少一个业务对象的逻辑关系，整合各业务对象对应的业务模块，得到与所述系统构建指令对应的电力营销系统。

优选的，所述用户类型包括：个人用户、企业用户、员工用户、管理用户、伙伴用户和政府用户。

优选的，所述业务单元的要素至少包括：业务操作、输入、输出及业务规则。

优选的，所述封装各业务对像对应的至少一个业务单元包括：

按照模型对象规则封装各业务对像对应的至少一个业务单元；

所述业务模块为与该业务对象对应的对象业务模型。

一种电力营销系统构建装置，包括：

指令接收模块，用于接收用户输入的系统构建指令，所述系统构建指令中至少包括：用户类型及需求信息；

解析模块，用于依据所述用户类型解析所述需求信息，获得所述需求信息对应的业务场景下的至少一个业务对象及所述业务对象间的逻辑关系，所述业务对象用于表征所述业务场景下的业务角色、业务实体及业务属性；

分析模块，用于分析所述业务对象，确定所述业务对象对应的至少一个业务单元，所述业务单元为按照预设规则拆分得到的，具有独立完成某一业务操作功能的最小逻辑组件；

封装模块，用于依据所述至少一个业务单元间的逻辑关系，封装各业务对像对应的至少一个业务单元，获得与该业务对象对应的业务模块；

整合模块，用于依据所述业务场景下的至少一个业务对象的逻辑关系，整合各业务对象对应的业务模块，得到与所述系统构建指令对应的电力营销系统。

优选的，所述封装模块包括：

模型封装单元，用于按照模型对象规则封装各业务对像对应的至少一个业务单元。

基于上述本发明提供的构建的电力营销系统的方法，首先解析用户的需求信息，获得业务对象，进一步获得业务单元，然后将业务单元逐层封装得到业务模块，进而得到满足用户需求的系统。该过程中的业务单元是独立存在的，能够根据用户的需求灵活配置，满足了对构建系统灵活性的需求。

附图说明

为了更清楚地说明本发明实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图是本发明的一些实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据这些附图获得其他的附图。

图1是本申请实施例提供的一种构建电力营销系统构建平台的示意图；

图2为本申请实施例提供的一种构建电力营销系统的流程图；

图3为本申请实施例提供的一种构建电力营销系统装置的示意图。

具体实施方式

为使本发明实施例的目的、技术方案和优点更加清楚，下面将结合本发明实施例中的附图，对本发明实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本发明一部分实施例，而不是全部的实施例。基于本发明中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本发明保护的范围。

现有的电力营销管理系统，其开发设计时使用的结构化生命周期法的方法的构建自由度很低，导致对后期需求的变化难以调整，无法满足日益增长的对于灵活构建电力营销系统的需求。

为了解决这一问题，发明人经研究发现，构建过程中的重点调整内容在于对业务的实现过程的调整。但是现有的系统中，针对每个业务对实现过程时所对应的程序代码进行了封装，如果需要调整，则必须重新对代码进行编译，而结构化生命周期的构建方法并不能支持对代码的重新编译。有鉴于此，发明人提出了将每个业务的实现流程进行解耦，将其拆分为实现该业务的业务单元的集合，当有新的业务产生或者固有业务发生变化时，可以通过对业务单元的灵活编排来满足不同的需求。

以上只是将本申请的核心思想进行了说明，为了实现本申请，发明人预先构建了实施该系统构建流程的电力营销系统构建平台。接下来就将构建该平台的过程进行说明。在以下内容中，会出现一些在本申请中出现的名词，为了方便阅读和理解，首先对这些名词进行说明。

对象：对象是对客观事物的抽象，包括属性(properties)和行为(behavior)，属性就是需要记忆的信息，行为就是对象能够提供的服务。

业务对象：业务对象是对业务场景描述中涉及到的业务角色、业务实体、业务属性的抽象，表达一个人、地点、事物或者概念。

数据模型：数据模型是描述数据、数据之间的关系的图形化视图，具体指用实体、属性及其关系，表达企业运营和管理过程中涉及的所有业务概念和业务规则。

概念数据模型：概念数据模型描述了一种高水平的、面向业务的信息视图。为了强调最重要的实体、属性和关联，该模型舍弃了一些非关键性的细节。概念数据模型可能包含多对多的关联。概念建模的终极目标是简单明了，因此，没必要发现并记录各实体的每一个属性。

逻辑数据模型：逻辑数据模型由完全规范化的、定义了全部属性的实体组成。此外，各个属性的域或者数据类型必须定义。逻辑数据模型需要规范的候选码来唯一标识实体的每一个实例。对于有多个候选码的实体，逻辑数据模型必须注明哪个候选码用作标识，即主码。

业务中台：业务中台是通过制定企业级的标准和机制，把企业内可共享的业务规则和环节通过信息化的手段标准化并统一提供服务，有效降低企业内各组织主体的沟通成本，提升生产效率，敏捷响应市场的需求和变化，增强企业核心竞争力。业务中台由多个业务能力中心组成，业务能力中心按照高内聚、低耦合的原则构建，每个业务能力中心都有自己对应的数据域，这些数据域的操作必须通过与之对应的业务能力中心进行，以达到数据的高度一致。

业务能力中心：业务能力中心是业务中台的组成部分，是由基础业务能力、组合业务能力等组成的基于领域模型分解的业务能力池。初步规划客户中心、服务中心、工单中心、产品中心、运营中心、支付中心、订单中心、计量中心、计费中心及账务中心等10个业务能力中心。

实体：实体是数据和行为的结合体，独立维护与实体相关的业务数据和业务逻辑。实体具有唯一的身份标识，可持续变化，持续修改，但在实体的整个生命周期中标识都是不变的。如：订单、商品。

值对象：值对象用来度量或描述某个业务特征，不需要唯一标识，不需要区分对象是哪一个，而只关心对象是什么，所有属性相等就认为是同一个对象。如：订单地址信息、商品价格。当我们只关心一个模型元素的属性时，应把它归类为值对象。我们应该使这个模型元素能够表示出其属性的意义，并为它提供相关功能。值对象应该是不可变的。不应为它分配任何标识，而且不应把它设计成实体那么复杂。

微服务：微服务是按照业务能力、业务相关性拆分形成的具有高内聚特性的服务单元，每个微服务独立部署、独立运行、独立升级，独立演进，微服务与微服务之间在结构上松耦合。一个或多个微服务组成能力中心，通过微服务对外暴露的服务接口支撑前台应用。微服务以服务方式实现的承担单一职责、模块化、有相对独立逻辑边界的一段业务逻辑，微服务可独立部署、独立运行，并采用轻量级的通信机制互相配合为用户提供最终价值。微服务拥有易于开发和维护，启动较快，局部修改容易部署，技术栈不受限，按需伸缩等优点，同时也有运维要求较高，分布式的复杂性，接口调整成本高的缺点。

服务编排：服务编排是通过编排技术实现微服务之间的协作来实现一个完整的业务流程，需要有支持灵活配置、可视化操作、同步和异步的服务流程编排框架来支撑，通过编排替代直接在微服务中硬编码方式。电力营销里的跨业务中心的服务调用，各网省个性化服务的调用都需要服务编排技术来协作实现。

领域驱动设计：领域驱动设计是一种解决复杂中大型软件的面向对象的建模方法。领域驱动设计包含战略设计和战术设计两个阶段，战略设计主要是定义问题、描述问题、分解问题，属于问题空间。战术设计通过领域模型设计、实现解决领域问题，属于解决方案空间。

领域模型：领域模型是系统的核心，用来表达业务概念、业务规则，组织和封装业务逻辑，包括实体、值对象、领域服务。

前台：前台是直接面向用户提供交互业务服务的应用，由前端页面、app界面、支撑特定业务场景的业务功能等组成。通常前台的业务功能需要通过中台服务进行支撑，具有业务上变化节奏快、技术上采用新兴的轻量级的技术体系架构等特征。

服务接口：是微服务对外暴露服务能力的主要形式，每个微服务包括多个服务接口，每个服务接口定义了输入输出参数和处理逻辑，前台应用通过调用服务接口，实现系统用例，满足应用需求。

应用：应用是指在业务流程中，相关环节所需功能的集合。

功能：功能是指对象(功能载体)能够满足某种需求的一种属性。凡满足使用者任何现实、潜在需求的属性都属于功能的范畴。

应用架构：应用架构是指从应用角度描述实现企业业务各环节需求及归类的分层模型。

用例：用例是软件工程或系统工程中对系统如何反应外界请求的描述，是一种通过用户的使用场景来获取需求的技术。用例定义了系统是如何被参与者所使用的，用例描述的是参与者为了使用系统所提供的某一完整功能而与系统之间发生的一段对话。

用例模型：用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，可当作分析设计工作流程以及测试工作流程的输入使用。

该过程包括业务设计、原型设计、系统设计、系统实现四个阶段。其示意图如图1所示，下面分别对每个阶段进行说明。

1.业务设计

业务设计阶段包括业务蓝图设计、平台服务设计、业务模型设计3个环节。

(1)业务蓝图设计：

该过程是指依据公司终端应用及服务渠道现状，结合泛在电力物联网营销服务系统的业务蓝图设计成果，对营销服务渠道、终端分类、应用分类进行规划，用于指导交互场景设计及前端应用设计。前端规划设计过程主要包括：营销服务梳理及规划、终端梳理及规划、应用分类规划等工作。

(2)平台服务设计：

客户需求分析，是从用电客户和内部作业用户两类用户的业务需求场景的角度出发，对实现客户/用户需求目标的事务性操作的业务需求进行整体审视、梳理和分析。同时结合传统电力业务经验、客户体验要素设计、现代营销服务和营销管理理论等多技术维度对需求分析结果，开展流程、业务、功能三个维度的需求优化识别设计，为后续构建系统提供设计输入和实现依据。

平台服务设计，采用4w6to分析法进行产品设计的分析，4w明确平台的业务方向(what)、为什么做平台，平台为用户带来什么价值(why)、平台的目标用户(who)、平台的使用场景(where)。6to确定产品面向的不同的平台对象，如下表所示。

业务场景设计，在平台的交付过程中，在渠道的终端或者应用上，发生的客户的主动行为或者客户和企业员工的间接交互行为，均可认为是一个业务场景。在平台分析的过程中需要对系统的场景进行分析，确定系统在运行中可能会涉及的所有的场景，在场景上做分析，可以更好的复现用户的各类行为动作，可以不断的提升用户体验，为现有产品的销售做好支撑，更可以为新产品在快速的进入销售渠道提供分析支撑。

(3)业务模型设计：

业务对象设计，业务对象表达一个人、地点、事物或者概念，是对上一步骤中设计好的业务场景描述中涉及到的业务角色、业务实体、业务属性的抽象。业务对象通过抽象体现业务的本质，业务是可以经常变化的，但业务对象是相对稳定的，因而系统是稳定的。采用面向对象的设计思想，在程序实现时操作业务对象而非数据库表，新增设备时，只需补充完善业务对象，无需修改其他程序，具有高度的灵活性。面向对象设计原则有6个：开放封闭原则、单一职责原则、依赖倒置原则、liskov替换原则、迪米特法则和接口隔离原则或合成/聚合复用原则。

业务单元设计，业务单元是独立完成某一业务操作功能的最小逻辑组件，具有独立、完整的业务操作。业务单元承载业务的逻辑本质，具有稳定的业务能力。这些业务单元可以存储于业务单元库中，并且，业务单元及业务单元库具有持续迭代能力、更新能力及稳定的业务能力，具有业务的高度抽象与合并。其次，在平台设计过程中，从变化的业务和需求中，进行业务解耦，逐渐拆分出的各项业务的核心要素，各核心要素保障了业务模型的稳定性，作为营销系统的微业务、微服务、微数模构建过程的输入。再次，具有良好的业务扩展能力，通过参数化、配置化设计，能够构件满足多种方式的业务模块，满足业务不断发展需要。

而业务模型设计旨在针对用户的需求，设计需求的实现工艺及工序，通过配置业务单元完成满足该需求的系统的全过程。业务模型设计过程，遵循用户需求中各个业务对象中各流程各环节的需求，清晰描述各业务环节实现过程中各个业务单元的关系及各项分支流转条件，完整描述系统的运行流程。

2.原型设计

原型设计阶段包括前端应用设计、界面需求设计、界面原型设计3个环节。

前端应用设计是指依据业务设计成果，结合公司服务渠道及终端管理应用情况，对面向用户提供交互业务服务的应用进行规划设计，用于指导界面需求设计及应用架构设计。前端应用设计过程主要包括：终端应用场景梳理、前端应用规划及前端应用功能设计等工作，也就是说，让开发出来的显示页面更方便用户的操作。

界面需求设计是指依据前端应用设计成果及业务模型设计成果，明确界面展示元素、展现形式，详尽阐述界面原型设计需求，用于指导界面原型设计。界面需求设计过程主要包括：界面组件设计需求描述、界面示意图绘制等工作。

界面原型设计是指依据界面需求设计成果，遵从界面原型设计规范，应用界面原型设计工具绘制界面原型，用于指导用例模型设计及应用设计。界面原型设计过程主要包括：界面原型图绘制等工作。

3.系统设计

系统设计阶段包括用例设计、应用设计、服务设计、数据设计、技术设计5个环节。

用例设计是采用格式化语言，细化描述业务单元中的业务操作，识别软件的功能需求和非功能需求，每一组用例和对应的时序实现相对完整的业务动作，用例模型设计成果为服务目录设计做输入。

应用设计包括应用架构设计、功能交互设计两部分。应用架构设计是阐述营销应用规划，用于指导应用划分及应用边界设计。以业务模型及系统用例分析成果为输入，结合业务、技术、管理等因素，提炼、抽象应用功能，设计应用蓝图并划分各应用的功能域，梳理应用间集成交互关系，为系统功能交互设计提供依据。

功能交互设计是根据应用架构设计成果及用例模型设计成果，进行信息系统功能交互设计的过程，是对系统应用的进一步细化设计。以应用需求为出发点，以提升系统易用性及用户体验为目标，设计各应用的原型，对系统页面的功能交互的逻辑与约束进行详细阐述，并作为系统详细设计的输入。

服务设计包括服务架构设计、服务模型设计两部分。服务架构设计是依据业务模型、业务单元、业务对象、用例模型等，分析业务领域，在服务中心划分原则和方法的指导下，推导规划中台服务中心，完成营销中台整体架构设计，构建起以能力中心组成的营销业务中台架构，以服务的方式支撑营销业务的建设。服务中心的规划主要包括定义服务中心定位和边界，定义各中心的服务目录，明确各服务接口参数等信息，为服务模型设计提供指导。服务模型设计是依据业务模型、业务单元、业务对象、用例模型、用例模型、应用架构，按照服务架构规划出的服务中心，遵照领域驱动设计方法，完成阶界上下文、实体、值对象、领域服务等领域模型设计，在此基础上完成服务中心的微服务设计，为开展详细设计提供指导。

数据设计包括数据架构设计、数据模型设计两部分。数据架构设计是从公司逻辑、物理数据资产的角度，对营销数据从数据标准、数据分类、数据主题、数据分布、数据流转、数据模型(概念模型、逻辑模型、物理模型)及主数据进行设计阐述的指导性说明文件，是业务架构、应用架构落地的重要环节，是业务中台、数据中台开展的重要支撑保障。数据模型设计是以核心业务对象为基础，对业务含义相同或相似的业务对象进行抽象，借鉴ieccim模型标准，在遵从sg-cim4.0标准的前提下，设计形成营销概念数据模型。以概念数据模型为基础，补充完善其他数据对象及属性，形成逻辑数据模型。以逻辑数据模型为基础，根据数据库选型，形成物理数据模型。

技术设计根据应用架构和数据架构的设计成果，设计支撑应用架构和数据架构的技术架构，定义支撑业务、应用和数据部署所需的软硬件逻辑能力，为技术平台的落地和建设提供指导。技术架构设计内容包括总体技术架构、技术架构分层、系统组件视图、集成架构、部署模式、安全架构、灾备设计及非功能设计等内容。

4.系统实现

系统实现阶段包括详细设计、研发、测试3个环节。

详细设计是对营销系统的微服务结构和内部处理逻辑的详细设计，在服务架构设计和服务服务设计的基础上进一步细化系统，提供详细的程序分层设计和业务逻辑编码设计。详细设计说明书由设计人员和开发人员共同编写，能够使开发人员能够充分理解系统设计，为程序开发提供直接的支持。

在完成了前述平台的设计开发之后，本申请公开的电力营销系统构建方法的实施过程如图2所示：

步骤201：接收用户输入的系统构建指令，所述系统构建指令中至少包括：用户类型及需求信息。

在本实施例中，因为平台构建过程中重点从个人用户(toc)、企业用户(tob)、员工用户(tos)、管理用户(tom)、伙伴用户(top)和政府用户(tog)的需求出发进行分析，获得相应的业务内容，因此该指令中的用户类型也就包括从个人用户(toc)、企业用户(tob)、员工用户(tos)、管理用户(tom)、伙伴用户(top)和政府用户(tog)中的一种或几种的组合。也就是说，可以单独为一个用户类型先构建一个电力营销系统，也可以同时为多个用户类型构建。以用户来进行分类，可以通过调研分析其在以往办理业务、运营管理、能源业务监管的过程中服务、业务、流程等方面的客户体验中存在的问题，以及出现的识别需求，为后续现有业务的功能增加或改进提供思路和方向。

步骤202：依据所述用户类型解析所述需求信息，获得所述需求信息对应的业务场景下的至少一个业务对象及所述业务对象间的逻辑关系，所述业务对象用于表征所述业务场景下的业务角色、业务实体及业务属性。

因为不同的用户类型的侧重点不同，需求也各有不同，所以需要实现的业务也不同。每个用户类型对应的业务对象可以是预先设定好的，也可以是根据解析需求信息的结果来确定的。本实施例中采用依据解析需求信息的结果来确定，更能体现针对用户的需要来构建系统这一思想，保证了系统构建的灵活性。

步骤203：分析所述业务对象，确定所述业务对象对应的至少一个业务单元，所述业务单元为按照预设规则拆分得到的，具有独立完成某一业务操作功能的最小逻辑组件。

业务对象是对业务场景描述中涉及到的业务角色、业务实体、业务属性的抽象，表达一个人、地点、事物或者概念。所述业务单元的要素至少包括：业务操作、输入、输出及业务规则。

也就是说，每一个业务单元都需要对应如何操作，输入数据是什么。输出数据是什么，以及该业务的执行规则等信息。以保证该业务单元能够顺利执行其对应的业务功能。

当有新的需求时，只需针对该需求的实现，将其实现拆分为业务单元，再进行组装即可实现该需求，如果没有对应的业务单元，可以针对该业务单元进行开发编译。

步骤204：依据所述至少一个业务单元间的逻辑关系，封装各业务对像对应的至少一个业务单元，获得与该业务对象对应的业务模块。

所述封装各业务对像对应的至少一个业务单元包括：

按照模型对象规则封装各业务对像对应的至少一个业务单元。

所述业务模块为与该业务对象对应的对象业务模型。

在本实施例中，按照面向对象的设计方法对业务模型、数据模型进行设计，面向对象数据模型的数据结构是非常容易变化的。与传统的数据库(如层次、网状或关系)不同，对象模型没有单一固定的数据结构。编程人员可以给类或对象类型定义任何有用的结构，如链表、集合、数组等。此外，对象可以包含可变的复杂度，利用多重类型和多重结构。

面向对象的业务模型设计首先根据客户需求抽象出业务对象；然后对需求合理分层，构建相对独立的业务模块；之后设计业务逻辑，利用多态、继承、封装、抽象的编程思想，实现业务需求；最后通过整合各模块，达到高内聚、低耦合的效果，从而满足客户要求。

步骤205：依据所述业务场景下的至少一个业务对象的逻辑关系，整合各业务对象对应的业务模块，得到与所述系统构建指令对应的电力营销系统。

通过以上步骤可以看出，本申请构建的电力营销系统是解析用户的需求信息，获得业务对象，进一步获得业务单元，然后将业务单元逐层封装得到业务模块，进而得到满足用户需求的系统。该过程中的业务单元是独立存在的，能够根据用户的需求灵活配置，满足了对构建系统灵活性的需求。

进一步的，本发明针对业务的产生从传统的业务驱动转变为产品驱动，以客户需求为导向，业务产品化，为用户提供标准化、产品化的服务。在现在电力营销的时代，产品需要面向不同的用户，根据不同的用户需求，快速的进行产品迭代，满足各类用户的需求。

并且，在新时期社会发展越来越迅速，业务已经不再是过去那种一成不变的固有模式了。在现代各种业务及客户需求快速更迭的时代，通过设定业务单元，利用确定的业务单元组合成满足不同需求的业务组合，能够更好的支撑未来业务发展不受约束。在面对新需求时，通过快速组装业务单元完成产品配置，快速响应客户需求，激活业务创新能力，增强企业竞争能力。

本申请还公开了一种电力营销系统构建装置，其结构如图3所示，包括：

指令接收模块301，用于接收用户输入的系统构建指令，所述系统构建指令中至少包括：用户类型及需求信息。

解析模块302，用于依据所述用户类型解析所述需求信息，获得所述需求信息对应的业务场景下的至少一个业务对象及所述业务对象间的逻辑关系，所述业务对象用于表征所述业务场景下的业务角色、业务实体及业务属性。

分析模块303，用于分析所述业务对象，确定所述业务对象对应的至少一个业务单元，所述业务单元为按照预设规则拆分得到的，具有独立完成某一业务操作功能的最小逻辑组件。

封装模块304，用于依据所述至少一个业务单元间的逻辑关系，封装各业务对像对应的至少一个业务单元，获得与该业务对象对应的业务模块。

整合模块305，用于依据所述业务场景下的至少一个业务对象的逻辑关系，整合各业务对象对应的业务模块，得到与所述系统构建指令对应的电力营销系统。

进一步的，所述封装模块304包括：

模型封装单元，用于按照模型对象规则封装各业务对像对应的至少一个业务单元。

本申请实施例公开的装置可以是电力营销系统构建平台本身。

本申请公开的构建的电力营销系统的装置，解析用户的需求信息，获得业务对象，进一步获得业务单元，然后将业务单元逐层封装得到业务模块，进而得到满足用户需求的系统。该过程中的业务单元是独立存在的，能够根据用户的需求灵活配置，满足了对构建系统灵活性的需求。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本发明的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器(ram)、内存、只读存储器(rom)、电可编程rom、电可擦除可编程rom、寄存器、硬盘、可移动磁盘、cd-rom、或技术领域内所公知的任意其它形式的存储介质中。

对所公开的实施例的上述说明，使本领域专业技术人员能够实现或使用本发明。对这些实施例的多种修改对本领域的专业技术人员来说将是显而易见的，本文中所定义的一般原理可以在不脱离本发明的核心思想或范围的情况下，在其它实施例中实现。因此，本发明将不会被限制于本文所示的这些实施例，而是要符合与本文所公开的原理和新颖特点相一致的最宽的范围。