服务程序框架（精选八篇）
服务程序框架 篇1
插件应用程序开发可以使用微软COM技术,COM是一种二进制重用标准,提供了一组接口,开发人员可以利用这些接口来开发基于COM的插件,当插件开发完成后,注册COM组件;也可以使用普通的DLL,但存在不同厂商标准不一不通用的问题。以上这两种技术都没有提供一个统一的插件功能的管理,当新开发的插件需要引用已有的插件功能时,只能点对点实现功能调用,软件规模达到一定程度时容易出现逻辑混乱。
本文采用微软的.NET Framework平台实现插件的加载与管控。.NET Framework平台已经实现了插件加载与管控所需要的底层技术,程序开发者可以将精力投入到程序架构与流程的设计当中。该文利用程序集Assembly类实现插件的加载,利用服务注册技术将应用程序框架设计成服务容器,实现插件功能的服务化注册管理,极大的简化了插件应用程序的开发及扩展。
1 关键技术介绍
1.1 程序集
程序集是 .NET Framework应用程序的构造块,旨在简化应用程序部署并解决在基于组件的应用程序中可能出现的版本控制问题,是构成部署、版本控制、重复使用、激活范围控制和安全权限的基本单元,是为协同工作而生成的类型和资源的集合,这些类型和资源构成了一个逻辑功能单元。程序集向公共语言运行时提供了解类型实现所需要的信息。程序集可以是静态的或动态的。静态程序集可以包括 .NET Framework类型(接口和类),以及该程序集的资源(位图、JPEG文件、资源文件等)。静态程序集存储在磁盘上的可迁移可执行 (PE) 文件中,动态程序集直接从内存运行并且在执行前不存储到磁盘上。程序集主要执行以下功能:
1)包含公共语言运行时执行的代码。如果可迁移可执行 (PE) 文件没有相关联的程序集清单,则将不执行该文件中的Micro-soft soft中间语言 (MSIL) 代码。(MSIL)
2)程序集形成安全边界。程序集就是在其中请求和授予权限的单元。有关应用于程序集的安全边界的更多信息,请参见程序集安全注意事项。
3)程序集形成类型边界。每一类型的标识均包括该类型所驻留的程序集的名称。在一个程序集范围内加载的My Type类型不同于在其他程序集范围内加载的My Type类型。
4)程序集形成引用范围边界。程序集的清单包含用于解析类型和满足资源请求的程序集元数据。它指定在该程序集之外公开的类型和资源。该清单还枚举它所依赖的其他程序集。
5)程序集形成版本边界。程序集是公共语言运行时中最小的可版本化单元,同一程序集中的所有类型和资源均会被版本化为一个单元。程序集的清单描述您为任何依赖项程序集所指定的版本依赖性。有关版本控制的更多信息,请参见程序集版本控制。源和包含实用工具类的程序集)可以按需检索。这就使应用程序在第一次下载时保持精简。有关部署程序集的更多信息,请参见6)程序集形成部署单元。当一个应用程序启动时,只有该应用程序最初调用的程序集必须存在。其他程序集(例如本地化资部署应用程序。
7)程序集是支持并行执行的单元。有关运行多个程序集版本的更多信息,请参见程序集和并行执行。
程序集的对应实现为Assembly类,使用Assembly类可以加载程序集、浏览程序集的元数据和构成部分、发现程序集中包含的类型以及创建这些类型的实例。Assembly类提供了静态方法Load File实现基于路径标识的动态加载,可以使用Get Name方法返回一个Assembly Name对象,该对象提供对程序集显示名称部分的访问;Get Custom Attributes方法列出应用于程序集的属性;Get File方法提供对程序集清单中文件的访问;Get Manifest Resource Names方法提供程序集清单中资源的名称;Get Types方法列出程序集中的所有类型;Create Instance方法在程序集中搜索和创建类型的实例。
1.2 服务容器
服务是.NET Framework设计时架构的基础,是提供设计时对象访问某项功能的方法实现。服务容器负责提供、添加和移除服务。服务机制的本质是解耦合,是将类型的设计时功能从类型本身剥离出来。如果把类型的设计时功能也封装到类型里,这样的类型包含了很多只有开发人员才会用到而最终用户根本不需要的功能,使得类型既臃肿又不便于扩展,而将设计时功能剥离出来,这样类型就可以不依赖于特定的设计环境。
服务容器可以包含其它服务容器,从而形成服务容器的树结构。当添加服务时,可以用提升指令来添加,当提升服务时,服务将向上添加到任何服务容器,直至达到服务容器树的顶端,这样就可以提供其它进程使用的全局服务。
服务容器的对应实现为Service Container类,Service Container是.NET提供的Iservice Container接口的实现,可以使用Add Servic添加服务,Remove Service移除服务,Get Service获得服务。
2 应用程序框架设计与实现
2.1 应用程序框架组成
要实现插件框架与插件的交互,必须有一个插件框架与插件交互的准则,即框架的运行不应依赖于插件,且能够获得插件存在的位置,具备动态加载插件的能力,必须要声明有哪些功能是可以被插件使用的,定义插件被加载的条件。.NET Framework平台下我们可以使用灵活可扩展的接口来实现这个准则。
插件与框架之间的通信可以用服务注册技术实现。将主框架申明为一个根服务容器,将插件对外所能提供的功能视为一个服务,并在接口中申明。插件在被加载的同时,完成插件服务向根服务容器的注册,并由根服务容器进行管理,对其它插件提供查询服务。
基于以上的设计思路,一个基于服务的插件式应用程序框架应由3个基本部分组成,如图1所示。主框架负责插件与服务的管理,插件的管理主要负责插件的加卸载,服务管理主要负责插件服务的注册、查询;接口定义主要由插件加载接口与服务接口组成,插件加载接口定义了要实现插件框架与插件的交互必须遵循的准则,每个插件都必须实现这个接口,服务接口由各个插件申明,申明各个插件所能提供的服务;插件由插件加载及插件服务组成,插件加载实现了接口定义中的插件加载接口,负责与主框架的交互,插件服务具体实现了接口定义中申明的服务接口,负责提供实际的插件功能。
2.2 应用程序框架实现
应用程序框架的实现首先从接口开始,接口申明中定义了四种类型的接口,如图2所示。其中IApplication接口继承IService-Container,负责服务的注册与删除;IPlugin接口定义了插件与主框架交互时必须实现的方法与属性,由插件实现;IPlugin Service接口是主框架申明的加载插件服务,主要负责插件的加载与删除;IService接口是所有插件服务接口的基接口,定义了插件服务必须实现的基本服务;IMessage Data Show Service接口是插件的申明的提供服务的接口,定义了插件所能提供的服务。
应用程序框架实现的第二步是实现主框架,如图3所示。主框架主要包含两个类,其中Main Form类实现程序的可视化并且实现IApplication接口,作为根服务容器,负责服务的加载、删除与查询;Plugin Service是接口IPlugin Service的实现,负责实际完成插件的注册、加载与删除功能。
最后实现插件,如图4所示。Message Data Show Plugin类实现IPlugin接口,负责与主框架的交互;Message Data Show Service类实现IMessage Data Show Service接口,具体实现了接口中申明能提供的服务。
3 结束语
服务程序框架 篇2
关键词：Ext技术；Web应用程序；界面设计
中图分类号：TP393.09
在网络技术的不断推动下，人们的生活发生了根本性的变化，而网络技术的更新换代，也极大推动了各种软件开发模式和技术的发展。对于传统软件工程开发领域常用的C/S结构，已经逐渐难以适应时代的发展。所以，软件开发人员在实践中逐渐采用基于B/S结构的Web应用程序开发技术。
特别是近几年来，随着Web技术的高速发展，其应用领域逐渐从简单的网页设计，向更加复杂的Web应用程序和网站发展，而正是由于其低廉的成本和便于安装部署的优势，使其能够在短时间内得到广泛应用。所以，在软件开发领域，Web应用程序的发展已经逐渐占据软件开发领域的主导。
1 Ext技术背景
Ext技术的主要作用，就是在客户端生成更加丰富和多彩的Web应用程序界面，现在普遍作为跨浏览器的JavaScript库来使用。在Ext中包含了可扩展的组成部件，使得其更便于使用，所开发的程序接口也更加直观。作为一种基于JavaScript而发展的语言，Ext能够广泛应用与Net、Java和PHP等多种语言开发环境。
在基于Ext技术的Web应用程序开发框架中，可以将其架构分为表现层、业务逻辑层和数据层，其中，表现层的设计方式不会对其他两层产生根本性影响。所以，现有的Ext框架则主要采用请求或者响应的方式来完成设计。而在具体的设计过程中，服务器依然是设计工作的重点，能够对HTTP请求进行响应，并返回多种格式的数据片段。
2 基于Ext技术的程序设计原理
而作为一种应用性能良好的Ajax应用框架，Ext在使用的过程中，还需要服务器的支持。而Ext与服务器之间的交互主要通过三种方式来完成，如下图1中所示，包括了控件交互、表单加载以及用户发出Ajax请求等。
图1 Ext与服务器的交互方式
在图1中，控件交互主要指服务器传送的数据，在控件交互的基础上，完成各种表单的提交，进而生成各种类型的数据，然后向客户端输送。在该过程中，控件可以完成对数据的识别，可以作为Ext端的数据转化解析器来使用。正是由于控件的支持，服务器端才可以对多种格式数据进行处理。
对于表单的加载方式，可以在完成表单的提交过程后，服务器端应用程序向其返回一个数据对象，用于表示处理结果的成功与否。
如果用户采用发出Ajax请求的方式，则在访问服务器的过程中，如果要完成基于Ext技术的Web应用程序界面设计，就需要通过HTTP向服务器发送请求，并通过回调函数来完成处理过程。在此过程中，通过回调函数可以定义本次Ajax请求过程中所需要的参数。
3 在Wbe界面中的应用
3.1 界面中的元素
在Ext技术中，能够为开发人员提供的界面元素种类多样，比如常用的表单、对话框、标签、网格以及页面的布局设计等。这样，在应用程序的设计中，用户可以根据需求选择不同的页面，从而为软件开发提供便利。不仅如此，软件开发人员还可根据自身的喜好来完成页面元素的选择。
3.2 静态方法说明
在Ext技术体系中，实现元素获取的方法主要为Ext.get和Ext.fly，其中，Ext.get方法在具体的执行过程中，能够为所有的DOM元素创建全新的Ext外部元件对象。相比较下，Ext.fly则更加小巧，所占用的资源更少，在执行过程中不需要缓存的支持。
4 在Web系统中的应用
4.1 服务器端设计
在基于Web的软件界面设计中，可以将Web和数据库服务配置在相同主机，而将Web服务器作为客户端与数据库之间的通道，因为浏览器能够通过Web服务器来实现数据库服务器的访问，在获取各种数据的基础上完成界面的更新。
在下面的图2中，给出了基于Ext技术的Web服务器动态管理的基本模式。其中，Web服务器可以为数据访问提供支持，在接收到各种访问请求的基础上，完成对数据序列的处理，以回调函数的处理结果为基础，向浏览器发送处理结构，进而实现页面的刷新。
图2 Web服务器所采用的动态管理方式
4.2 界面实现
在Web程序的开发过程中，只要在基于Ext框架的应用环境中添加Ext框架所需要的软件开发包即可开始设计过程，从而得到用户希望的各种界面。
5 结束语
虽然Web应用现在已经非常普遍，代表了软件发展的主要趋势。但是，在Web应用程序的开发中，还需要人们的继续研究，才能在生产实践中更加普遍地应用，进而开发出更加实用的软件。文中在对基于Ext技术的Web应用程序的设计与开发简单介绍的基础上，给出了Ext技术在界面设计和界面效应增强中的一些体会。
参考文献：
[1]严磊磊.论ExtJs在Web开发中的应用[J].信息系统工程，2012（12）.
[2]王晓燕，宋绍云.Ext的组件体系结构研究[J].电脑知识与技术，2011（09）.
[3]翟超杰，李兆瑞，车青.浅析Ajax框架技术的应用与实践[J].信息与电脑（理论版），2010（12）.
[4]王璠.面向Web系统应用的目标性能测试方法研究[J].电脑知识与技术，2011（07）：1570-1571.
[5]沈银华，汪涛，王峰.基于ExtJs?Spring和iBATIS的Web系统应用研究[J].软件导刊，2011（12）：13-15.
作者简介：潘齐欣（1983-），女，苗族，贵州雷山人，讲师，本科，主要研究方向：软件工程、计算机应用。
作者单位：凯里学院 信息工程学院，贵州凯里 556011
MFC框架程序剖析 篇3
关键词：VC++,WINDOWS编程,MFC框架,消息
WINDOWS程序是与传统的DOS程序截然不同的两种程序设计方式, 它是由事件驱动的, 在应用程序展示给客户的UI (User Interface用户界面) 中提供了各式各样的可视对象, 用户可以根据需要, 对这些可视对象进行操作, 通过鼠标或者键盘的操作, 产生了操作系统能感知的事件, 在这样的事件发生之后, 操作系统向应用程序中的特定对象发送消息, 然后这些对象调用相应的函数处理过程来完成用户所要的需求。
WINDOWS应用程序是建立在对象的基础之上的。程序中所包含的所有可以操作的可视化组建本质上也是一个对象, 用户通过鼠标或者键盘对这些可视化的组建进行操作, 之后消息驱动模式去调用这些组件内部可以使用的方法。用户通过外部输入进行操作的同时产生了各种不同类型的事件, 这些事件又经过操作系统的分配, 被相应的对象进行处理, 这就是WINDOWS程序运行的的本质。下图就是对WINDOWS程序的运行原理的简要说明。
1 WINDOWS应用程序基本特点
WINDOWS系统的本质是一个消息驱动的操作系统, 那么消息的定义是什么呢, 从以下的几个方面, 可以对消息有一个初步的了解。
1) 消息组成部分:消息是由两部分组成的, 它们分别是消息的名称 (UINT) 和参数 (WPARAM, LPARM) 。当用户点击鼠标或者通过键盘输入信息时, 操作系统会捕捉到这一事件, 同时发送消息到特定的窗口。例如当用户通过键盘输入字符“z”的时候, 就会有WM_CHAR消息就会被发送, 此时用户输入的具体是哪个字符则由WPARAM和LPARAM两个参数来确定。用户在使用系统提供的消息的同时也可以根据自己的需要定义消息, 以便通过自定义的消息发送和接收数据。
2) 消息传递的目标:每个消息必须由一个窗口来接收, 否则会被系统默认的处理。每个窗口都有一个后台的消息处理函数, 称之为窗口过程, 它的作用是对传递过来的进行整理, 处理那些和自己有关的消息, 屏蔽掉无关的消息。例如 (如果对鼠标左键单击事件进行处理, 那么就必须增加针对WM_LBUTTONDOWN消息的处理函数, 同样如果对鼠标右键单击事件进行处理, 那么就必须增加针对WM_RBUTTONDOWN消息的处理函数, 以便处理用户的需求。
3) 未处理的消息:在用户的操作过程中会产生很过的消息, 其中有些消息是需要我们处理的, 然后大部分的消息是我们不关心的, 这时WINDOWS操作系统就会调用默认的串口过程来处理这些我们未处理的消息。WINDOWS的这种默认处理机制, 大大的缩短了程序员的开发时间, 我们只要把精力集中在我们关注的消息上就可以, 其余的都可以交给系统默认处理。
4) 窗口句柄:窗口句柄类似于C++中的指针, 系统通过句柄来识别每个不同的窗口, 用户通过操作触发事件进而又操作系统转发消息, 这是必须为每一个窗口分配一个句柄, 用来辨明窗口的身份, 以便接受消息, 保证了每一个消息能够被相应的窗口接受, 之后再调用该窗口的窗口过程处理。如果有两个窗口, 窗口A, 窗口B, 共用一个窗口过程时, 如果在窗口A上单击了鼠标, 怎会通过窗口A的句柄发送给窗口A而不是窗口B。
2 消息传递过程
消息到产生之后是如何被相应的窗口过程相应的呢, 下面我们来了解一下相应的过程, 其中有大致分为5个步骤:
用户通过外部设备进行了输入或者窗口的状态发生改变导致了事件的产生。
操作系统捕捉到这个事件, 并把其转化为相应的消息, 之后放入到消息队列中等候处理。
应用程序从消息队列中接收到这个消息。
应用程序根据消息中的标识句柄把消息传递给相应的窗口, 并交由该窗口的窗口过程进行处理。
窗口过程响应这个消息并进行处理。
其中第3步和第4步构成了应用程序消息循环的主题。消息循环机制是WINDOWS应用程序中最重要的机制, 因为消息循环机制能够把用户的操作和消息的响应结合起来。消息循环机制的主要作用就是从已经消息队列中找到已经产生的消息, 然后根据消息句柄发送给相应的窗口进行处理。如果消息队列中没有已经生产的消息, 那么操作系统就允许其他应用程序处理它们的消息。
3 MFC主要类库分析
Windows操作系统最方便之处就是良好的用户接口, 它为用户提供了丰富的图形化界面, 这个图像化界面的本质就是消息处理机制驱动的, 所以说消息处理机制是WINDOWS编程的核心, 只有详细的了解了这个机制, 才彻底了解WINDOWS编程。
VC++编程环境提供了一套MFC App Wizard应用向导, 可以不用编写代码的情况下建立一个简单的WINDOWS应用程序, 下面就以这个简单的应用程序为模板, 简单分析一下生成对象之间的关系。
CMy App类:类Cmy App的对象就代表了一个应用程序应用程序启动:用户运行该应用程序时, Windows会自动调用应用程序框架内部Win Main函数, CMy App类它的父类是MFC中的CWINAPP类。这个类包含了其他CWINAPP类中的构造函数, 同时还包含了一个重要的成员函数INITINSTANCE () , 在WINDOWS操作系统中同一个程序可以在内存中存在很多的实例, 例如我们可以开启多个QQ应用程序, , 函数INITINSTANCE的作用就是在每一个实例产生的时候, 完成一些初始化的工作。
CMain Frame类:类CMain Frame它的父类是MFC中的CFreme Wnd类, 所以它也是一个框架窗口。CMain Frame是类CMyview的父类, 换句话说CMyview类的对象显示在主框架窗口的客户区中。在类CMain Frame中, 系统已经从类CFreme Wnd那里继承了处理窗口的一般事件的WINDOWS消息, 比如改变窗口的大小, 窗口最小化等等的成员函数, 因此编程的时候程序员不需要再关心此类消息的处理。当然, 如果用户确实需要多这写默认的成员函数进行修改的时候, 我们也可以在类CMain Frame中添加相应的函数, 之后重载就可以了。
CMy View类与CMy Doc类:CMy View类和CMy Doc类是两个结合在一起的类, 下面的框图可以说明文档与视窗的关系。
在这个框图当中, 文档是由文档模板对象生成的, 并由应用程序对象管理, 而用户则是通过与文档相联系的视窗对象来存储、管理应用程序的数据, 用户与文档之间的交互则是通过与文档相关联的视窗对象来进行的。
在这个框图结构当中, 文档的产生是由文档模板对象决定的, 生成之后的文档交由应用程序对象管理, 而用户对数据的更新, 删除, 修改等操作都是通过文档窗口对应的对象来完成的, 用户与文档之间的交互则是通过与文档窗口对象的对象来进行的。
在每一个新的文档生成的时候, MFC总会为其生成一个框架窗口, 并且在这个框架窗口中生成一个用户的视窗窗口作为它的子窗口。用户视窗的作用就是监听用户的鼠标, 键盘等输入设备的操作, 一旦有事件产生, 就生成消息并传递到消息队列中, 完成消息循环以达到文档对象处理的目的。
4 windows窗口创建过程
WINDOWS应用程序分单文档界面SDI和多文档界面MDI两种, 在单文档界面中, 文档窗口与主框架窗口是同一概念。而这时的视窗对象则是显示在文档窗口的客户区当中, 此时文档窗口是主框架窗口, 即类CMain Frame的对象。
在了解了WINDOWS程序的运行原理以及MFC程序的四个基本对象之后, 我们来一起分析一下WINDOWS窗口程序的创建流程。
1) CXXApp中的全局变量定义 (在Win Main () 函数之前定义的全局变量)
CXXApp the App;
2调用构造函数 (创建一个类, 它首先会调用自己的构造函数)
CXXApp::CXXApp () {}
3) 进入Winmain函数 (_t Win Main为宏, 值为Win Main)
4) 完成初始化工作:包括窗口类注册、窗口产生、显示和更新
pThread->InitInstance ()
对于MFC程序, Main Frame, View, Tool Bar, Controlbar等都是窗口, 所以下面的窗口注册与创建、显示等要反复调用多次, 一次对应一个窗口
(1) 注册窗口类
Afx End Defer Register Class () (相当于SDK里面的Register Class () 函数)
(2) 创建窗口
CMain Frame::Pre Create Window () //反复调用一次用来修改窗口属性
CFrame Wnd::Create ()
(3) 消息循环
Pump Message ()
结合了以上的各个内容, 我们对WINDOWS应用程序有了一个基本的理解, 在基于WINDOWS开发应用程序的时候MFC框架为我们提供了快捷有效的编程方式, 类似于我们常见的填空题项一样, MFC框架为我们提供了应用程序建立所需要的主体代码, 其中包含应用程序外观框架, 应用程序消息处理机制框架等, 这样就大大的加快了程序开发的过程, 程序开发者可以主要的精力投入多商业逻辑的开发中, 而不是在苦苦的在底层代码中挣扎, 缩短了开发的周期, 有效的提高了程序开发的效率。
参考文献
[1]侯俊杰.深入浅出MFC[M].2版.武汉:华中科技大学出版社, 2001.
[2]位元文化.精通MFC视窗程式设计[M].松岗出版社, 2010.
利用软集成设计实时网络程序框架 篇4
在网络日益发达的今天,具备网络通信功能已经逐渐成为一个软件的必备功能了,但是如何设计一个具备可维护性、可扩展性、与数据无关的网络通信程序仍然需要耗费程序员的很多精力。本文试图按照硬件集成电路板集成元件的设计方式利用软集成实现一个满足上述要求的多线程网络通信程序平台。
网络通信程序一般都需要长时间地不间断运行,而如果网络程序需要进行必要的维护,包括增加新的连接方向、修改数据处理方法等工作,如果重新启动程序来应用新的配置,那么在这段时间里通信就会中断。以往采取的方式主要是使用双机工作模式,先对主机进行维护,由备机接替工作,主机维护完毕后重新接替备机工作,再对备机进行维护。我们希望有一种方法,在保证其他功能都正常运行的情况下替换某些功能,或者只重新启动需要进行修改配置的功能,而且这样的功能要求不仅仅是网络接收程序需要,其它的实时的需要长期不间断运行的软件都需要具备此类能力,即在不需要重新启动软件的情况下替换掉某些功能。
因此,我们的设计目标就是能够实现一个程序框架,在该框架下运行的程序均使用动态链接库的方式实现,框架负责根据配置文件的描述来加载不同的功能,这些功能组合在一起来共同实现程序的功能,同时框架能够接受用户发送来的配置信息或命令来停止部分功能或加载新的功能。框架实现后就类似一块集成电路板,电路板为各个集成块提供连接电路,各个集成块的功能由其自主实现,只要能够满足接口要求就能够插入电路板进行工作[1]。在我们的应用中,不同的动态链接库的功能都使用线程实现,这些功能组合在一起就是一个多线程的程序,任意的动态库组合在一起实现一个完整的程序功能。
1 实时网络程序模式解析
应用程序设计的主要目的之一是为了对未来程序可能发生修改变化进行预测,并能够设计出一个在以后方便进行扩展的程序框架,程序设计模式便是主要对这类问题进行的归纳和总结。可扩展的程序最大的特点就是要求程序功能之间既能够高度集成一起运行,同时又是松散地耦合在一起。这样,未来对某些功能的修改不会对其它功能造成任何影响,程序的可扩展性就得到了极大的提升。
1.1 网络协议无关性设计
首先我们需要分离的是通讯协议,其实不仅仅是实时的网络程序,即使非实时性的网络程序在考虑程序设计的模式时,首先选择的就是网络协议实现与数据处理能够分离。数据处理发生修改的可能性远远大于网络通讯协议的修改。程序将网络协议实现与数据处理分配到两个不同的基类中,由这两个基类的实现来处理网络协议与数据格式。不同的方向可以对应不同的网络协议和数据格式,相互之间没有人员干扰和影响,未来一旦数据处理方法需要进行修改,整个程序结构以及实现逻辑都不需要进行更动,只需要修改或替换调数据处理方法类即可[2],达到了网络协议与数据处理方法的相互分离。未来即使是某方向的网络实现也需要进行修改,也不会对其它方向的实现造成影响,模式的UML图如图1所示。
1.2 线程处理模式
实时网络程序目前大多采用每连接每线程的方式,不同的连接方向对应着不同的接收和处理线程,线程可以有固定的数目,也可以根据需要实时自动地创建。在通常的应用中,连接方向在大多数情况下是固定不变的,只是不时地有增减连接方向的需求,因此网络接收程序在启动时就为不同的方向创建好线程并等待接收数据。这样的程序结构一般都使用初始化创建线程并有接收和处理线程进行工作,当然接收和处理线程也可以合二为一,在一起实现所有的功能,程序的伪码如下所示:
这样的程序模式虽然能够实现网络协议与数据处理相分离,但是却使程序的线程结构无法进行变化。例如,如果未来某方向的处理线程由于数据量过大,需要增加处理线程的数目,那么现在的模式就需要进行大的调整了。接收线程与处理线程必须加以分离,同时两个线程之间需要增加一个共享的数据读写缓冲区来完成数据交换,进一步引入了一个新的Buffer类,Data类和Protocol类与Buffer类均要发生联系,但是Buffer类缺少管理,比如由谁负责清理缓冲区中的内容,并且这样的模式将很容易造成关键资源冲突,从而造成线程死锁。同时一个方向现在需要由2个线程来完成工作,线程的数量增加了1倍,系统的资源被多占用了。对上面的设计进行修改,将数据接收线程换成系统调用select()[3],该程序接口在Windows、Solaris以及各个版本的Linux上均有实现的版本,并且由于系统的异步IO操作的效率要高于线程的使用效率,并且占用更少的用户程序资源,是一个较好的选择。修改后的模式图2如下:
类之间的耦合度降低了,同时线程也减少为1个,数据缓冲区由Data类负责管理。至此,我们完成了一个完整的多线程网络程序,每连接每线程,并且网络协议的实现与数据处理方法得到了很好分离,便于程序的进一步扩展。下面即开始讨论如何实现动态地对这些连接和处理线程进行管理。
2 多线程实时程序框架的实现
如果我们将每一个功能都使用动态程序库技术来实现,同时定义所有框架需要加载的动态库都必须实现一个初始化函数(Init),框架负责显示加载的动态库,并且调用初始化函数。如果我们需要能动态地管理每一个功能,我们还需要定义暂停函数(Suspend)、恢复函数(Resume)以及停止函数(Stop)。所有这些函数的实现由该功能自行负责,可以在初始化函数时创建网络连接、创建处理线程,并且相应地在停止函数中关闭网络连接以及退出线程。框架程序启动后会逐一加载配置文件中所描述的需要加载的动态库,每一个库加载后会首先调用初始化函数,如果该函数不存在则认为该库程序不符合框架要求,框架程序将报告错误。在上一节主要解决了程序编写中如何将网络协议与数据处理相分离、如何将线程实现与功能实现相分离的问题,而框架程序就提供了将不同程序功能相分离的模式,不同的功能实现可以分布在不同的动态库中,由框架程序去主动调用,这样,对不同功能的控制就转化成了对动态链接库的控制[4]。框架程序要能够实现,并且能灵活地对其所加载的功能库进行管理,必须具备一些基本的功能,其中包括有:
◆框架必须定义一个统一的程序接口,并能够定义一个基类来规范这些接口,所有在框架中加载的功能必须是继承自这个类;
◆框架程序要能够记录其所加载的程序库的基本信息,这样才能够在运行的过程中对这些库程序进行控制或状态查询;
◆框架记录的程序库信息能够在运行的过程中被框架中所加载的功能查询;
◆框架程序必须具备能够根据配置信息查询动态链接库文件的能力。
2.1 框架接口基类
接口基类负责定义符合框架规范的程序接口,借助面向对象的基类和纯虚函数概念就能够满足对接口进行规范的要求,框架程序在加载动态库程序时首先对程序类进行判断,只有判断与基类相符的程序库时才进一步地处理。如果所加载的程序库的入库类能够动态地转换为基类(dynamic_cast),则框架直接调用初始化函数,并判断初始化过程是否完成。用户在开发框架程序的时候,必须继承接口基类,并且在动态库中将该类标记为输出,这样框架程序就能够找到并加载初始化函数。
2.2 功能库基本信息查询接口类
为了在运行期间能够查询框架所加载的功能,并且能够根据这些信息对其进行控制,框架程序提供了一个能够向所有功能开放这些信息的接口类,该类必须能够被所有在框架中加载的功能访问,并且能够对其进行控制,框架在加载完功能后,会将功能类保存在该接口类中,这样在运行期间就能够随时查询到框架中的任何功能并且调用该功能的接口函数对功能进行控制。有了这样的功能,就可以在运行期间对任何功能进行控制,如果需要中断某功能的运行只要通过框架程序访问到该功能并且调用其对外提供的stop函数就可以完成[5]。而要卸载该功能也只需要在停止该功能运行后从框架的接口类中删除该功能即可。功能的实时加载其实就是卸载功能的反操作,将功能库的位置通知框架程序,框架程序就会自动地加载功能库并调用初始化函数,从而完成在运行过程中加载新功能的过程。
2.3 框架配置信息获取功能类
框架程序启动后会读取框架的配置文件,并根据文件中所描述的功能库信息,按照先后顺序进行加载。为了使配置文件能够规范,格式采用了XML格式,这样能够在配置文件的格式不满足要求时框架依然能够适应,并对错误进行处理和提示。该类不仅能够静态地读取XML格式的配置文件并分析出功能库的基本信息,同时在框架实时运行期间还能够分析符合XML格式的字符串,并解析出配置信息。这样框架在运行期间就能随时地添加新的功能并按照配置进行加载。
3 多线程实时程序框架构建的网络程序
在构建好的框架上开发应用将非常的方便,从接口基类中继承框架接口,在开发完毕应用后将程序编译到一个动态链接库中就可以了,在使用中就可以使用这些编译好的功能库随意地组合出需要的功能,而且还可在程序运行的过程中向其中添加新的功能。下面以监控系统中的外部数据接收程序为例来描述框架的应用。
外部数据接收程序需要满足三种不同的传输方式:UDP组播、UDP点播以及TCP/IP协议,并且从四个不同的方向接收数据。为此,分别编写了两个动态库,一个是UDP协议接收功能,一个是TCP/IP协议接收功能,对XDF数据格式的处理方法存放在另一个单独的动态库中,这三个程序库的组合就能够完成整个监控软件系统数据接收和处理的全部要求。XDF数据格式处理方法启动后会读取配置文件中的对数据处理方法的描述信息,并根据这些信息创建不同数据类型的处理方法并等待调用,UDP协议功能被加载后会首先创建网络连接并将连接注册到系统中等待IO到达通知,并创建处理线程和缓冲队列,一旦接到IO到达的通知则处理网络连接并将接收到的数据加入缓冲队列后等待网络协议处理工程接收,处理线程接到缓冲队列中有数据的通知后会从队列中读取数据并调用XDF数据格式处理方法对数据进行处理,而XDF数据格式处理方法便是通过框架的接口信息类查询得到的,因此,可以向框架中添加不止一个数据处理功能,以应对未来可能的变化。TCP/IP协议处理功能在IO到达后才会自动为该连接创建一个处理线程,而在TCP连接中断后就会自动关闭处理线程,这样就能够满足每连接每线程的程序模型,并且本方法能够与其它不同方向不同网络传输协议的处理方法共存。
从上面的配置文件示意中可以看到描述了四个不同的方向已及它们所使用的网络协议和相关配置信息,框架启动后会根据这些要求加载不同的功能库并完成创建工作[6]。如果未来需要添加新的方向则可以修改该配置并添加新的信息,如果程序不能接收中断,则可以向框架传输新的配置信息,框架程序就会按照要求加载新的功能(
在这个应用中通过框架程序,将网络方法、处理方法进行了物理上的分离,又通过框架程序将他们自由地整合在一起,共同实现了用户功能。这样实现的网络程序在部署和维护的时候将非常灵活和方便,任何的方向都具有独立被控制的能力,同时又能够在不中断现有连接的情况下添加新的连接方向。本文设计的程序框架还具有其它很多可能的应用,只要是能够拆分成不同功能的程序都可以通过此框架程序将各个子功能组合起来共同发挥作用。而且只要能够利用框架所提供的对程序库进行控制的特点就可以设计出许多在程序运行阶段就能够对功能进行更动的实时程序,从根本上保证程序具有充分的可扩展能力。例如,可以设计出这样一个实时程序,它的处理逻辑在一个单独的动态库中实现,程序的主控模块被框架加载后会自动向框架查询处理逻辑,并使用该处理逻辑来处理数据,如果在程序运行期间有了一个新的处理逻辑库,可以通过框架先卸载原先的逻辑库程序,逻辑库程序在卸载的时候可以暂停主控模块处理数据的流程,这时主控模块自动将数据记录到缓冲区中,但不对数据进行处理(如果有新数据到来的时候),只有当新的处理逻辑库加载进来后才通知主控模块可以进行数据处理,这样既保证了程序顺利地进行更新,又保证了数据不会丢失。
4 结论
本文设计的程序框架不仅为实时程序提供了良好的扩展机制,同时对其它程序的设计也提供了很好的思路和模式,借助框架的帮助,可以将程序设计成一个个独立的功能模块,每个功能模块如果能够设计成统一的调用接口,那么不同模块的组合就能够非常方便地改变程序的处理逻辑和处理流程,无论从模块的复用性还是程序功能的扩展性上来说都能够达到满意的效果,因此本程序框架有着广阔的应用前景。
摘要：文章设计并实现了多线程网络通信程序平台,该平台提供了一个能够满足各种网络传输协议和格式的网络程序框架,程序框架采用了网络协议的实现与数据处理的实现相分离的结构,每一个网络连接对应一个独立线程,在框架的支持下同步运行。每一个连接线程都带有独立的数据缓冲区,缓冲区的大小可以随时进行调整。框架中的功能均能够在运行期间被停止或卸载,框架也能够在不重新启动的情况下加载新的功能,使得实时程序能够在功能不中断的情况下进行维护。
关键词：软集成,实时性,连续运行,网络协议无关,功能耦合性
参考文献
[1]伽玛.设计模式-可复用面向对象软件的基础[M].李英军,等译,北京:机械工业出版社,2007.
[2]程亮,张阳.基于UML和模型检测的安全模型验证方法[J].计算机学报,2009,32(4):699-707.
[3]常亮,史忠植.一类扩展的动态描述逻辑[J].软件学报,2010,21(1):1-13.
[4]汪洋,刘晓冰.一种面向并行工程的统一产品BOM模型[J].计算机应用研究,2010(8):2984-2986.
[5]任泰明.TCPIP协议与网络编程[M].西安:西安电子科技大学出版社,2004.
[6]霍欢,陈庆奎,王国仁,等.基于剪切的XML数据流自适应发布算法[J].计算机学报,2010(10):181-190.
基于XML的软件通用程序框架 篇5
在航天测控工程中,系统软件需要通过串口、PCI总线、网络等多种接口与各分系统或设备分机进行数据交互,实现对测控设备的管理。因此在测控软件的开发过程中,需要花费大量人力、时间去进行接口与通讯的设计、编码、调试和测试,而且接口在发生变动时( 经常发生) ,维护和修改也会耗费大量时间。接口、通讯代码是整个测控软件的基础,而由不同人员编写的代码质量不尽相同,造成整个软件可靠性降低。
为了解决以上问题,本着统一化设计的思想,提出并实现了一种基于可扩展标记语言[1]( ExtensibleMarkup Language,XML) 配置文件的测控软件通用程序框架。使用该通用软件框架时,只需要按照规定好的格式将接口文件写出,便可以自动生成所有接口部分的代码; 配置好通讯类型和参数,便可自动实现数据通讯; 同时还可以根据接口文件自动生成参数显示界面、命令发送界面以及提供日志记录、源码显示等软件基本功能。在实现软件快速开发的同时,还可以提高软件的可靠性。同时也使测控软件代码的通用性、可维护性大大增强。
1 XML配置文件
为了将分机间的接口通讯数据进行规范化描述,使用了XML配置文件的形式。XML是万维网联盟( World Wide Web Consortium,W3C) 发布的一种标准,是标准通用标记语言( Standard GeneralizedMarkup Language,SGML) 的一个简化子集。XML遵循严格语法规范,实现了数据存储格式结构化,具有扩展性好、数据共享与重用简单和网络传输方便等优点,已成为一种通用的数据交换标准[2]。
为了实现接口设计的通用性,以设备分机为单位,使用XML配置文件对分机接口数据及其数据关系进行描述。对分机的接口进行整理之后,制定的主要规则包括: 1对分机外部接口数据元素进行描述; 2对分机接口命令帧格式进行描述; 3对分机内部数据元素进行定义,并描述内部数据元素与外部接口数据元素之间的转换关系。
接口的规则化描述如图1所示。图1( a) 为接口数据的规则化描述,将一个分机的所有数据元素表描述为3个必备要素( 设备标识、设备名称、数据元素项) ; 图1( b) 为接口命令的规则化描述,将分机的外部接口命令描述为3个必备要素( 命令名称、命令标识、数据长度) 和一个可选要素( 命令内容) ;图1( c) 为内外接口数据转换的规则化描述,其以内部数据元素为索引,将与之对应的外部数据的序号、名称以及外内数据转换方法描述出来。
2代码自动生成
按照制定好的规则将系统接口文件转换为规范化描述的XML配置文件之后,便可以调用编写好的代码自动生成类库进行代码生成,将XML文件生成为程序代码[3,4]。代码自动生成类库目前主要实现了3部分的代码生成: 数据结构代码、显示参数和发送命令的窗体界面、分机设备管理基类。
2. 1生成数据结构代码
利用XML配置文件中描述的接口数据信息生成相应的数据结构类代码。生成数据结构类代码的过程由BBEMaker类完成,BBEMaker类视图如图2所示,接口类视图如图3所示。
BBEMaker类实现的主要函数包括:
1 Coder_BBECommand Class: 根据外部接口命令关系表简历各个命令对应的类;
2 Code_BBEElements Class: 为每个分机生成一个数据结构;
3 CoderB BEEx To InnerC onvert Function: 生成外部接口数据与内部数据元素转换函数。
由BBEMaker类生成的数据结构类代码实现了以下接口[5,6]( Interface) : IBBEData、IBBEData Collect和IFrame Head。其中图3( a) 为IBBEData接口的类视图,其定义了数据元素应该实现的方法,图3( b)为IBBEData Collect接口的类视图,其定义了所有数据元素的结构应该实现的方法。在实现了这3个接口之后,生成的数据结构类就可以在外部调用时方便的进行命令数据打包、拆分、索引和赋值等操作。
2. 2生成窗体界面代码
生成窗体界面代码的过程由BBEView Maker类完成,BBEView Maker类视图如图4所示。
BBEView Maker类实现的主要函数包括:
1 Coder_Form_cs: 生成* . cs文件,这是C#语言下的窗体界面组成文件;
2 Coder_Form _Para Display Function: 生成界面状态显示函数;
3 Coder_Form_Time Event Function: 生成定时器响应函数,用于刷新界面状态。
由BBEView Maker类生成的界面包含了XML配置文件中的所有数据元素,可以按照所描述的格式实时显示数据的状态,同时此界面还对外提供命令发送委托[7,8]( delegate ) handle Of BBECmd Send。此委托传递2部分内容: 设备ID和基于IBBEData的数据结构。调用此界面时传入该委托即可实现操作命令从界面到设备的发送[9]。
2. 3生成分机设备管理基类
生成一个分机设备管理基类BBEDevice,实现的主要函数包括:
1 Setup: 初始化函数,用于调用该类时完成内存、通讯等资源的分配及初始化;
2 Receive Data Event Handler: 提供接收数据的委托处理函数,使用者可自定义处理过程;
3 BBESource In Handler: 提供通讯输入源码数据的委托处理函数;
4 BBESource Out Handler: 提供通讯输出源码数据的委托处理函数;
5 BBEException Info Handler: 提供捕获的系统异常信息的委托处理函数。
3配置通讯类型
为了适应各分系统或设备分机不同的通讯方式( 串口、PCI/PCIE、网络等) ,采用XML文件作配置文件,不同通讯配置的参数不同,但是所有的通讯配置都基于IConfig接口,如图5所示。
定义一个处理所有通讯功能的接口ICommunicate,并使处理串口通讯、PCI通讯和网络通讯[10]的数据类全部实现该 接口,其UML设计图如 图6所示。
这样当主程序框架读取配置文件后,根据配置文件所实现的IConfig接口的属性,自动调用实现了ICommunicate接口的串口通讯类、PCI通讯类或网络通讯类来获取通讯资源,从而实现设分系统或备分机的通信功能,完成数据的收发工作。
在通讯配置发生变动时,只需要更改配置文件中的某一项变动的通讯参数即可,不需要再编译程序。
目前该配置方法已经在多个航天测控工程项目中进行了应用,由于使用了自动生成的代码,使得软件的可靠性得到了提高[11]。根据初步的统计,使用配置文件的代码生成节约了编程人员40% 左右的工作量,使软件开发效率得到了较明显的提高。
4结束语
通过配置文件的方式对测控软件与各外部接口之间的接口信息进行配置,设计灵活,便于更改和后期维护。同时使用XML接口文件自动生成程序代码的方式,可以将软件人员从繁杂的接口编程中解脱出来,提升开发效率的同时还提高了软件的可靠性。统一处理所有接口设备通信的处理操作,便于调试,同时减少了分别编码的出错概率,消除了各个设备的接口差异性,为测控管理和自动化运行统一化设计打下基础。
摘要：航天测控设备管理存在分机多、分机之间的数据交互格式复杂、内容多变等特点,测控软件开发较为困难。针对这一难题,介绍了XML配置文件的格式,分析了测控设备软件接口的特点,提出了一种基于XML的可配置、易更新的通用测控程序框架,应用于测控设备软件开发,对软件的开发流程在效率和正确率方面有明显提高。
以护理程序为框架的护理查房体会 篇6
1 方法
1.1 做好查房前资料的收集
1.1.1 病种资料的收集
查房前1周, 护士长与责任护士共同商讨, 确定查房病种。一般选择病情相对复杂、临床比较常见的疑难、大手术病种;需要较多护理干预的病种;合并症较多的病种等。例如:颈椎损伤高位截瘫的患者, 合并症较多, 行气管插管或切开时, 相关的护理干预也较多, 是常见选择的病种。
1.1.2 查房要点的确定与收集
确定查房病种后, 护士长对所查患者涉及到的护理内容进行整理, 根据临床工作中的薄弱环节, 确定出某个方面的讨论议题。例如:骨科行全髋关节置换的患者, 全程护理包括术前准备、术后护理、并发症的护理干预、术后康复训练等许多方面的护理内容, 根据工作中康复训练缺乏系统性、分期性的薄弱点, 选择术后的康复训练作为查房的要点, 让护士充分明确此次查房的目的与方向。
1.2 制定查房计划
1.2.1 制定出详细的查房计划
查房前1周, 根据确定的查房要点, 护士长选出几个方面的讨论议题, 分配给科室护士, 每人一题, 大家分别查阅资料, 收集信息, 这样收集起来的信息比较系统、全面。例如:全髋关节置换的患者术后康复训练, 需要讨论的议题有:髋关节的解剖结构、术前训练要领的教授、术后康复训练的分期、出院后的康复指导等。
1.2.2 护士长与主查护士共同商讨查房步骤, 如:
查房时间、地点、流程, 共同制定出详细的查房计划。
1.3 采用灵活方式, 实行互动查房
1.3.1 查房步骤
先是主查护士介绍患者病情, 到病房对患者进行全面查体, 了解患者对健康宣教知识的掌握;然后护士长提出拟定好的讨论议题, 大家依据查阅资料分别发表意见, 其他人可以补充或发表不同的看法, 然后护士长对讨论结果进行归纳总结。
1.3.2 查房形式要多样化, 有提问、回答、补充, 还要有实习护生的共同参与。
对实习护生可采取互动的形式, 护士长提问一些相对简单的理论知识、名词定义、观察要点让护生回答, 护生也可对查房中存在的问题、疑点向老师请教, 鼓励护生积极发言[2], 形成一个全员互动的查房氛围。
1.4 查房效果的总结与评价
查房完毕, 主查护士结合本次查房讨论的结果, 评价临床护理效果, 哪些问题已解决, 哪些问题有待于解决, 该如何解决, 有一个明确的目的与方向。最后, 护士长对整个查房过程、知识水平的提高、临床工作的指导意义、存在的问题与不足进行总结、评价。
2 结果
以护理程序为框架进行护理查房, 护士熟练掌握了查房的步骤、方法, 针对指定的讨论议题, 护士能积极翻阅资料, 收集信息, 拓宽了知识面, 并将每次查房学到的理论知识应用于临床, 提高了护理工作水平和效率。护士、护生对这种查房效果满意率达90%以上。
3 讨论
以护理程序为框架的护理业务查房, 抓住了临床工作中的薄弱点, 使护士明确了每次查房的目的, 有针对性地收集相关资料, 养成了护士多动脑、爱学习的习惯;形式上采取灵活、互动的方式, 从而调动了护士、护生共同参与的积极性, 降低了护士长讲、护士听的被动参与性;同时, 护士、护生对每次查房要点有了全面、深刻的掌握, 从而较好地指导临床护理工作, 值得推广应用。
参考文献
[1]陈莉芬.护理查房在整体护理中的应用.中华护理杂志, 1998, 33 (5) :301.
试析Flex程序开发中的框架应用 篇7
随着包含丰富用户体验的应用程序RIA(Rich Internet Applications)技术的不断发展,Web开发有了新的发展。使用Flex技术开发部署RIA应用程序非常简单。由于Flex技术基于MXML标准、CSS标准、XML标准、ActionScript3.0标准,所以开发过程更规范、应用程序更容易扩展。Flex技术中提供了丰富的组件,使得Flex开发人员只需将注意力集中于业务逻辑开发。Flex技术主要包含以下:
(1)描述应用程序界面的MXML语言。
(2)符合ECMA规范的脚本语言ActionScript。
(3)基础类库。
(4)处理用户和系统的事件。
(5)构建复杂的数据模型。
(6)运行时的即时服务。
(7)由MXML与ActionScript文件生成的.swf文件编译器。
2 Cairngorm框架
Flex是一种基于Flash技术的应用程序框架。这个框架为开发人员提供了丰富类库资源,其事件驱动机制和强大的数据绑定功能,以及组件化开发的特点,可以很容易地把应用程序分为不同的层。Cairngorm框架就提供了一种分层方式,它大体上将应用分为3层:模型层(Model)、视图层(View)和控制层(Controller),这是一种MVC模式的应用。
在Cairngorm框架中,视图层体现为用户交互界面;模型层用来处理业务流程的各种状态;定义数据模型,接收数据并返回最终的处理结果;控制层则根据用户输入或其他逻辑需要,控制用户界面数据的显示,更新模型层的数据状态。它的应用流程大体是这样的:用户在视图层执行某项操作,派发事件,控制层根据这个事件进行某些处理,并更新模型层中的一些数据,从而引起视图层中依赖于这些数据的部分进行更新。
Cairngorm框架的一个特点是广泛使用单例模式(Singleton),使用单例模式的目的是保证一个类只有一个实例,并允许整个应用程序访问这个实例。比如Flex中的管理器(PopUpManager、StyleManager等)采用的就是单例模式,在应用程序启动时这些管理器的实例被创建,通过这个实例控制管理其他对象(如弹出窗口、样式等),在程序结束时实例被删除。
3 Cairngorm体系
Cairngorm框架定义了一种开发体系,并以此来规范开发者对项目代码的划分。这个体系包括以下部分:
(1)值对象(ValueObject):值对象用来定义基本的数据结构,强化数据类型,以便在应用程序的各层之间传递数据并进行严格的类型检查,通常服务器端返回的数据都应在客户端序列化为相应的值对象类型。Cairngorm框架提供了ValueObject和IvalueObject接口。
(2)视图层(View):Cairngorm的View包中提供了2个类:ViewHelper和ViewLocator,这2个类是针对使用Flash的用户设计的。由于Flex实现了组件式开发,视图层面的代码都已封装在各个组件中,这2个类通常不必使用。
(3)数据模型(Model):ModelLocator和ImodelILocator是Cairngorm提供的模型定位器接口,相当于应用程序的“数据库”。存储应用程序中所有的Value Object(数据)和共享变量。ModelLocator的另一个作用是更新视图。
(4)控制器(Control):Cairngorm的control包中包括CairgormEvent、CairgormEventDispatcher和FrontController类。CairgormEventDispatcher是一个单例模式的类,它的作用是为应用程序提供一个事件派发器实现,所有CairgormEvent类型的事件都由这个派发器实例派发。使用这种方例可以简化事件传递,在应用程序的任何地方,只要对CairgormEventDispatcher的实例进行侦听就可以捕捉到相应的CairgormEvent事件。CairgormEvent类则包含了一个名为data的属性,和CairgormEventDispatcher事件派出所器的实例eventDispatcher。Data属性可以接受任意类型数据,而eventDispatcher用来派发CairgormEvent类型事件,这样data属性的内容就可以通过事件传递。
FrontController类用来建立事件与命令的映射关系。可以使用addCommand()方法来注册程序中需要用到的CairgormEvent事件类型和需要调用的命令类(Command)。当CairgormEvent触发时,FrontController会查找这个事件是否注册过,如果已注册,就会使用相应命令类中的execute()方法来处理这个事件。
(5)命令(Commands):当用户在View上进行某项操作时,会派发CairgormEvent事件,该事件通过FrontController执行相应的Command,Command执行后更新ModelLocator,View发现ModelLocator的变化后自动更新。流程如图1所示。
(6)业务逻辑(Business):Business包提供了很多访问远程服务器所需的类和接口,一般需要用到其中的2个:ServiceLocator类和Responser接口。ServiceLocator是一种单例模式的类,用来提供对服务器的远程调用(RPC),这种调用可以通过WebService,HttpService或RemoteObject进行。而这些远程调用返回的结果,则由执行了Responder接口与Flex框架中的Iresponder接口类似,需要实现2个方法:onResult()和onFault(),前者用来处理对服务器端成功调用后返回的结果,而后者则处理调用失败的情况。
获取服务器数据的的流程如图2所示。
4 Pure MVC框架
建立Flex项目可以选择的框架有很多,Cairngorm是官方的框架,但是对于中小项目开发来说,使用Cairngorm这样的框架似乎有点“笨重”。Pure MVC一个“轻量级”的框架,它是一款开源的免费框架,尽管不是专门为了Flex项目而设计,但它能够使用在不同语言平台下,是一个可以广泛使用的框架。
从名称上看,Pure MVC就是一种MVC框架,将软件的视图(View)、控制器(Controller)和数据模型(Model)分离,视图层负责软件展现给终端用户的界百,控制层负责处理业务逻辑、管理数据层和视图层的关系,而数据层负责管理软件的基础数据结构。
在Pure MVC中,所有处理都是通过通知(Notification)来传递的,而不是Flex里的事件机制。由于ActionScript3是基于Java的一种编程语言,因此ActionScript3中事务是通过事件来传递的,也就是dispatchEvent。取代事件传递机制的是通知(Notification)机制,各模块直接通过通知互相调用,这样的行为又称为观察者模式。各模块并不直接发生关系,而是发送通知,对这个通知有关联或者感兴趣的模块会接收这个通知并进行处理。
5 其他框架
Cairngorm:官方的事件驱动框架,现在已经相当成熟,但体积庞大,适合中大规模的应用开发。其架构的优点在开发复杂的RIA应用时才能体现出来。
Pure MVC:通知驱动的框架,界面的MXML部分可以非常干净。不是专门针对Flex的框架,采用通知驱动代替事件驱动是其特点。
ARP:简化版的Cairngorm,历史相当悠久,可以作为Cairngorm在小型应用开发上的替代品。
Mate:事件驱动型框架,使用基于标签的MXML语言定义应用处理事件的映射。界面的MXML可以非常干净,但配置文件稍微有些麻烦。
Foundry:针对Flex开发的ActionScript3/Java框架,适合中大规模的应用开发。
摘要：分析了两种常用的框架技术在Flex程序开发中的应用。
关键词：Flex,Cairngorm,PureMVC,框架
参考文献
[1]郑阿奇.Flex3开发实践.北京:电子工业出版社,2010.
[2]李庆.我的Flex我精通.北京:电子工业出版社,2009.
服务程序框架 篇8
输送控制系统的控制思路虽然会因行业的不同而略有差异, 但其基本的控制思想都是相似的, 因此对于输送控制系统的逻辑控制程序框架进行研究就具有十分深远的意义。它不仅为刚接触输送控制系统的工程师提供逻辑控制程序编程的基本思路, 也为有着多年控制经验的工程师提供一种标准化的框架。控制逻辑控制程序标准化, 不仅降低了逻辑控制程序开发的成本, 也大大提高系统的可维护性以及稳定性。
1 输送控制系统的层级结构
输送控制系统的硬件主要包括可编程控制器、传感器、马达控制设备及电机, 如图1所示。输送系统在设备上有着明显的层级划分, 因此在逻辑控制程序架构上也要与硬件相对应。PLC逻辑控制程序的层级主要为系统、区域、区段和设备, 每一个层级都有相应的控制管理器来控制相应层级的设备, 这些管理控制器会结合不同的PLC功能块来实现一个特定的功能, 具体实现方式如图2所示。
(1) 系统的主要功能包括:起停整个或部分系统, 远程或者本地控制;检测影响一个或者多个区域的故障;系统间的接口;操作面板控制。
(2) 一个系统包括几个区域, 在每个区域中也有独立的管理控制器, 该管理控制器除了接收来自系统的控制指令, 同时也决定该区域内所有设备的状态。根据需要还可以增加其它不同的功能区域。
(3) 一个区域里又分为不同的区段, 区段用来执行每一个详细的功能。比如在离港区域主要包括值机柜台区段、可疑行李开检区段、离港转盘区段、导入区段以及备份区段等等。每个区段也有一个管理控制器, 其主要功能是本区段的起停控制、本地或者远程控制、流量控制、本区段的故障检测, 并向区域发送状态值。
(4) 设备是整个系统的最底层, 一个设备包括所对应的检测机构、执行机构以及相应的电气保护设备。
2 输送控制系统的接口
系统中的一个标准模块所包含的接口主要是控制字、状态字、参数设定、状态反馈及统计信息、流程接口以及相关的辅助接口, 如图3所示。
2.1 控制字及状态字
控制字主要用于整个系统或单个区域, 甚至单个设备的起停控制, 而不局限于单个设备或系统。基本模块起承上启下的作用, 通过接收来自上层的控制字状态来决定该基本模块所包含的所有设备动作, 也将其状态反馈给更高一层;同时将收集到的下层状态反馈给上层, 并将上层传达的控制字转发给下层。图4描述了控制字从上而下的执行过程, 图5描述了状态字从下而上的生成过程。
2.2 设备编号、参数设定以及状态显示
系统中的每个设备都有自己特定的编号。该编号可用来标识该设备在现场的物理位置, 方便设备的安装以及逻辑控制程序标签的命名, 同时也可用于监控界面的组态。在设备编号确定的情况下, 便可根据实际情况直接对每个设备参数进行设定, 如输送机的运行速度、起动/停止时间、输送机长度等。此处的状态显示不同于状态字:状态字只是设备的通用状态, 如起动、停止、节能等;而这里的状态则是输送机的详细状态, 即根据输送机的不同功能来定义不同的细节。该状态不仅可显示输送机及相关设备的基本信息, 而且一旦发生故障, 该详细状态就可帮助维护人员判断故障发生的原因。
2.3 流程接口
流程接口用于相邻两个输送机间的衔接, 包含的基本内容为输送机准备好发送、输送机准备好接收以及物件发送过程中。只要通过控制流程接口的各个位置位或复位, 就可控制物件在输送机之间的自动交接过程, 图6描述的就是一个物件交接的基本过程。
2.4 辅助接口
如果在输送控制系统外还有其它设备, 如镀膜控制系统中的清洗机、光度计, 行李处理系统中的防火门、安检机等, 这些设备是通过接口协议相互交互数据的, 其运行会影响到相关输送机的运行状态, 因此需要通过辅助接口来控制输送设备的起动和停止, 而不需要通过流程接口, 以避免接口的重复条件定义而产生冲突。
3 结束语
本文分析了输送控制系统的逻辑控制程序框架结构, 提出了区域化和层次化的逻辑控制程序框架结构、全局的层次化任务、局部的顺序化控制以及特殊区域的异步并发任务, 使输送控制系统逻辑控制程序开发标准化, 大大降低项目开发周期及成本。该输送控制系统逻辑控制程序框架结构可广泛推广并应用于机场行李处理系统、物流自动分拣系统、食品生产包装系统等行业。
参考文献
[1]张凤珊.电气控制及可编程序控制器[M].第2版.北京:中国轻工业出版社, 2003
[2]马志溪.电气工程设计[M].北京:机械工业出版社, 2002
[3]齐占庆, 王振臣.电气控制技术[M].北京:机械工业出版社, 2002
[4]史国生.电气控制与可编程控制器技术[M].北京:化学工业出版社, 2003
[5]郁汉琪.电气控制与可编程序控制器应用技术[M].南京:东南大学出版社, 2003
[6]张万忠.可编程控制器应用技术[M].北京:化学工业出版社, 2001
[7]王兆义.小型可编程控制器实用技术[M].北京:机械工业出版社, 2002
[8]吴晓君, 杨向明.电气控制与可编程控制器应用[M].北京:中国建材工业出版社, 2004.