3 系统设计原理和方法
3．1 基于组件对象的开发模型
在传统的C／S开发模型中，应用程序实现的业务规则在客户端实现，或在后端DBMS中以存储过程或触发器的形式实现。在早期，这种开发模式曾大幅度地提高了应用程序的开发效率和运行效率。但随着分布式网络的发展，C／S模式渐斯暴露出一些不足之处：客户端需要大量的维护工作，用户界面与应用模块实现的业务逻辑放在一起，无法封装业务规则，随着客户需求的变化带来大量的版本更新问题，不便于管理；因为面向业务处理的计算主要在客户端进行，对于需要进行诸如统计之类的计算，不得不从数据库中反复查询后将查询结果传回客户端完成计算功能，从而加重了网络负担。为了解决这种问题，可以将系统服务对应为功能组件的实现，从而实现业务规则的封装。组件技术的发展，使我们可以利用组件技术来组建分布式网络数据。这样就能够以最小的代价开发尽可能多的、高质量的应用程序。这也有助于实现应用程序之间的高度一致性、兼容性和业务完整性。应用，利用组件来封装业务规则，划分组件功能，合理部署组件位置，从而获得更优的应用性能。
3．2 基于组件实现的三层开发模式
在对电力系统的web数据库集成系统的服务需求进行分析后，我们从逻辑上将系统分割为提供用户界面的客户端浏览器页面，提供业务服务的远程业务服务对象和提供远程数据服务的数据服务对象和数据库系统等几部分，通过网络将这几部分连接起来。系统体系结构就将应用程序的实际编程任务划分为组件的实现和集成组件的软件集成实现两类任务：一类任务是开发可重用的核心组件(如业务组件，数据库存储过程等)，另一类任务是集成这些核心组件提供的服务。我们可以设计良好的对象模型以确定对象内部类结构和需要向外展示的接口，然后通过组件组装的方式构造特定的解决方案。从提供服务的观点来看，要将系统服务需求分割为组件对象服务，我们可以使用图1所示的三层开发模式层次来划分对象功能。
在图1中，用户服务、业务服务和数据服务都包含在彼此独立的对象中，对象之间具有互操作性。
(1)用户服务层。用户服务层提供一个可视化接口，用来向用户显示信息和收集用户数据。用户服务层本身不进行业务数据处理，只负责向业务服务层发出请求。
(2)业务服务层。业务服务层是联系用户和数据服务的桥梁。业务服务组件对象响应用户发来的请求，执行某种业务任务。业务任务是由应用系统的需求定义的一种操作，业务规则则是控制业务任务工作流程的策略。与业务任务相比，业务规则更容易发生改变。为了达到更好的灵活性，在具体实现时应该将业务规则封装在单独的构件中，在业务规则改变后，只需要修改业务规则部分，同时保持该组件的对外接口不变，所有请求该业务规则的对象都将使用已修改的业务规则对象得到新的结果。
(3)数据服务层。数据服务包括数据的定义、维护、访问和更新，以及管理并响应业务服务层的数据请求。数据服务层实现所有的典型数据处理活动，包括数据的获取、修改、更新以及数据相关服务等。
三层开发模式应用系统实现了对角户界面、业务逻辑规则、数据服务的逻辑分离和独立封装，符合分布式模型应用的要求。存在于三层开发模式中的各种服务强调的是概念意义
上的逻辑结构，而不是组件部署位置上的物理结构，允许提供服务的组件在物理位置上驻留在网络的任何地方，任何服务对象都可以根据特定的功能需求激活其它的服务对象，服务
对象可以根据它们在三层开发模式中的对应位置确定其对象应具有的服务功能。三层结构也并不意味着在实际应用中只存在这三个相互作用的提供服务的对象，相反，有可能系统中多个对象的相互作用才意味着提供某一层的服务。
3．3 基于组件对象的三层开发模式的优点
与传统的集中应用程序开发方法相比，基于组件对象的三层开发模式具有以下优点：
(1)实现业务规则的封装。可以在用户需求变化的情况下对局部的组件对象加以改进，使需求变化对系统的影响比较小。
(2)版本管理和更新方便。在用户需求变化和对象版本升级时，采用组件对象可以尽可能地减少版本冲突的管理和保持向下的兼容性，并可以通过网络直接下载新版本组件对象，得到新增的功能。
(3)部署最优化。因为组件对象可以部署在网络上，从而可以取得效率、性能、安全和维护上的最优化。可以将一个应用程序的某些组件驻留在中央数据库服务器上，某些部署在部门性的“业务”服务器上，另外的部分驻留在对用户最方便的服务器上，甚至就驻留在最终用户的客户机上。在设计功能强大、需要良好协调的若干应用程序时，开发人员可以根据网络以及基础设施的实际情况进行部署。组件的实际位置对最终用户是透明的。
(4)可管理性。可以将大型复杂的工程细分为简单、安全的组件工程。
(5)提高重用效率。组件的使用者只需要理解向他们公开的接口，而不需要知道组件的内部结构和组件使用的数据。这样就能够以最小的代价开发尽可能多的、高质量的应用程序。这也有助于实现应用程序之间的高度一致性、兼容性和业务完整性。
3．4 系统的总体结构
电力综合管理信息系统要达到的目标是在供电局内部网中，实现基于浏览器方式的电力数据查询和管理。本系统要实现所有应用组件对象的浏览器下载和控制；实现电力系统三大子系统——SCADA子系统、GIS于系统和电力综合管理子系统——通过浏览器方式的集成，能对三大子系统的数据进行web查询；实现三大子系统数据的wob管理(增加、删除、修改等)；同时，要实现将来对系统的扩展方便，添加新的功能时对系统各部分的影响较小。
前面已经提到，我们将电力综合管理系统从逻辑上划分为三层：用户服务层、业务服务层和数据服务层。其中，用户服务层面向领导客户、生产管理客户、供电管理客户、安监管
理客户、财务管理客户、办公室管理客户、其它科室客户和系统管理员客户，提供不同的用户界面，向用户显示信息并收集用户数据；业务服务层提供三大子系统的各项功能，包括
SCADA实时及历史数据查询、办公信息查询与管理、综合管理信息查询与管理(包括生产指标、供电指标、安全指标和财务指标)、领导查询、电力GIS地理数据查询与管理和系统维
护等功能；数据服务层定义并维护所有的数据表，并通过存储过程、触发器以及SQL执行语句等手段响应三大子系统的数据请求。系统体系结构如图2所示。
3．5 对象构成
从图2可以看出，我们需要构造以下几类组件对象来完成所需的对象服务：
(1)用户界面类组件：提供用户与数据的交互界面。
(2)业务逻辑类组件：提供电力GIS、SCADA、综合管理及办公室管理等各子系统相关业务逻辑服务，从用户组件接收数据及业务逻辑请求，并把经过处理的数据请求传给数据库接口组件，最后把数据库返回的数据与业务逻辑处理结果一起传回用户组件。
(3)通信类组件：提供客户端用户组件对象与在服务器端的业务逻辑类组件对象的远程通信服务。通信类组件遵循CORBA规范和I10P协议，通过ORB对象调用远程方法。
(4)数据库接口类组件：提供对数据库的各种操作功能，从各业务逻辑组件接收数据请求，并将数据库返回的结果集传回业务逻辑组件。
经过半年多的运行实践表明，应用该模式开发的电力综合管理信息系统具有信息共享程序高，使用简便、运行稳定可靠，可扩充性强等特点。具有较好的实用价值。随着应用系统的不断开发，将在应用面及应用深度上，全面提高的信息化水平。
(本文获优秀论文一等奖)
上一篇：电能数据远程自动采集系统
