多层开发

2024-11-09

多层开发(共10篇)

多层开发 篇1

0 引言

使用过Delphi的开发人员都知道,Delphi在Internet/Intranet、Web和电子商务部分提供了非常强劲的支持。Delphi允许程序员只使用Delphi便能够开发ASP对象、Web应用程序、MTS中介对象以及使用ADOExpress组件存取数据库之中的数据。这样程序员只需使用Delphi便能够完成大部分的工作,而不需要同时使用数种不同的语言和技术来开发Web应用系统。怎样使用Delphi开发高效的Web应用系统是每个程序员都关注的问题。本文主要介绍了一些编程技巧和对系统执行效率有关却易被忽视的内容,可帮助系统开发人员提高Web应用系统的执行效率。

1 分析

影响开发的Web应用系统执行效率的因素有:

(1)Web应用程序需要进行的数据库连接个数;

(2)Web应用程序需要被重新激活、释放的过程;

(3)Web应用系统使用的对象被重新建立、释放的次数;

(4)数据在网络中传递的数量。

提高系统的执行效率可通过下面几种方法:

(1)尽量减少Web应用程序与数据库连接的个数;

(2)尽量减少系统使用的对象被重新建立、释放的次数;

(3)控制数据在网络中一次传输的数量。

在尽量提高系统的执行效率时,还要考虑到系统的稳定性问题。所以,有时为了增强系统的稳定性就不得不牺牲一些效率,这需要开发人员在开发过程中进行综合考虑,尽量避免不必要的系统开销。

对于CGI和ISAPI/NSAPI类型的Web应用程序来说,数据库连接Pooling是软件开发人员应该掌握的。因为数据库连接Pooling功能的运用对开发高效Web应用系统有着很大的作用。像HTML这种时常需要进行连接断线的通信协议来说,对于数据库的确有非常大的影响。例如Oracle数据库在进行数据库连接时必须执行非常多的工作,这些工作包括了为连接的客户端在数据库服务器中配置缓冲存储器以便加快稍候客户端存取数据的速度。因此这是为什么Oracle在初次连接时需要比较长的时间,基本上Oracle使用的这种方式比较适合客户端/服务器结构或是需要执行比较长的数据处理操作。但实际上Web应用程序的类型经常是执行短暂、快速的操作,这和Oracle采用的方式基本上是矛盾的。所以当程序员在Web应用系统中使用像Oracle这种数据库时,更应该使用数据库连接Pooling技术来增加系统的执行效率。当程序员使用数据库连接Pooling时必须注意使用的数据库存取引擎,以及数据库本身是否提供数据库连接Pooling的功能。例如ADO提供了数据库连接Pooling的功能,但是ADO提供的功能只局限在一个相同的执行进程之中,不同的执行进程无法共享同一个数据库连接。

另一个需要注意的问题是当程序员使用定制ASP对象或是MTS对象开发Web应用系统时,应该注意这些COM对象使用的COM线程模型的类型。当程序员在Delphi中建立定制ASP对象或是NITS对象时,应尽量使用Apartment线程模型的对象,而不要使用其它线程模型的对象。Apartment线程是Microsoft为了配合Windows9/NT这些真正是多任务的操作系统而改善的COM线程模式。在这种线程模式中,一个应用程序服务器可以有许多不同的Apartment,而在每一个Apartment中可以有许多的COM对象。由于使用Apartment线程的应用程序服务器可以包含许多的Apartment,所以程序服务器在同一时间可以服务许多不同的客户端的调用。这样,当同时有许多客户访问系统时就可以大大地改善系统的执行效率了。

下面将要讨论的是与应用程序服务器有关的内容。这些内容对于一般的软件开发人员都可以掌握,而且对于开发任何形式的多层应用系统执行效率都有一定的影响,当然也包括Web应用系统。分布式多层应用系统比传统的客户机/服务器结构系统多了层中间件,中间层就是这里讲的应用层服务器。而且多层应用系统通常要服务更多的客户端用户,尤其当系统执行在Internet/Intranet或是WAN环境中时,就更需要待开发的系统有一个好的执行效率。这就需要系统开发人员对应用程序服务器的工作原理有一定的了解,下面分别从两个方面论述影响系统效率的因素。

1.1 远程调用方式对系统效率的影响

远程调用指的是首先在应用程序服务器的远程数据模块中定义一些方法(即接口),客户端应用程序通过远程调用以取得应用程序服务中定义的方法。一般来说对于应用程序服务器提供的服务,客户端应用程序有数种不同的调用方式,分别是:

Late Binding调用方法;

EarlyB inding调用方法;

Dispatch Table调用方法。

下面介绍每种调用方式的优缺点。

(1)Late Binding调用方式

由于这种调用方式在使用上非常方便,所以是最常使用的远程调用方式。许多介绍Delphi的初级资料一般也用该方式,以致于许多初学者从一开始就习惯使用该调用方式,但并不知道这种调用方式对于应用系统执行效率的影响。其实这是一种最没有效率的调用方式,因为它在调用远程数据模块中的服务前要执行非常多额外的工作。只是因为组件TDCOMConnection(或是应用TsocketConnection,TCORBAConnection)直接提供了AppServer这个属性可以让软件开发人员调用远程方法。要想开发高效系统,这种调用方式是不可取的。

(2)Early Binding调用方式

这种调用方式的好处是Delphi在编译应用程序时便可以检查程序员使用的语法和传递的参数是否正确,并且编译器可以事先便产生所有必要的执行码,因此不需要应用程序执行时再使用动态方式和远程应用服务器通讯,所以在执行效率上要比上面介绍的Late Binding调用方法更有效率、更安全。不足之处是这种调用方法的使用比较麻烦,而且还需要一些程序设计技巧。另外,Early Binding调用方法还有一个限制,那就是它只能使用在DCOM的通讯协议上,所以这种调用方法不是很受欢迎。

(3)Dispatch Table调用方法

这种调用方法可在多种通讯协议中使用,而且比较方便。当在Delphi中使用可视化Type Library编辑器定义应用程序服务器后,Delphi便会在Type Library的Wrapper类别中自动生成Dispatch Table的接口,不需开发人员编码实现。得到该接口后便可以使用它以Dispatch Talbe的方式进行远程调用。由于Dispatch Table接口可以由可视化Type Library编辑器自动生成,而且能够同时使用在DCOM和Socket通讯协议中,这种调用方法的执行效率要比bate Binding来的更好,使用上几乎和bate Binding一样方便。各种调用方法都有其优缺点,开发人员可根据不同的需求而采用不同的调用方式,理想的调用方式是E a r l y Binding,但其调用操作不方便,所以Dispatch Table调用方法还是可取的。

1.2 网络的roundtrip对系统效率的影响

在分布式多层应用系统中,远程调用是非常昂贵的事情。如果应用系统能够尽量避免不必要的远程调用的话,就可以有效地增加应用系统的执行效率,因为这可以减少网络的roundtrip。如何能够降低网络的roundtrip牵涉到许多技术,其中最重要的便是程序员如何设计在中介应用程序服务中的企业对象。一般来说中介企业对象如果依照它的工作精细度来区分的话,大致上可以分为两类:Finer Grained和Larger Grained企业对象,下面分别介绍这两类企业对象。

(1)Larger Grained企业对象

一般来说,需要重复使用的企业对象应该尽量避免成为Larger Grained企业对象。Larger Grained企业对象是指其运行逻辑比较复杂,而且很难重复使用的。例如一个接受客户订单的企业对象,它必须同时使用数个其它的对象来完成工作(即下面要提到的Finer Grained企业对象)。通常在Larger Grained企业对象中会有判断的程序代码,例如一个客户的信用额度是否够用,客户的定购量如果很大,是否会有折扣等。所以通常Larger Grained企业对象要在其它的应用程序中重复使用是比较困难的。Larger Grained企业对象即是分布式对象中的控制对象或协调对象。

(2)Finer Grained企业对象

Finer Grained企业对象是指比较适合重复使用的对象。例如具备会计逻辑的企业对象,或是能够处理员工逻辑的企业对象。这种企业对象能够在许多不同的应用程序中使用,所以一般程序员应该尽量把这些需要或是能够使用在各种不同场合的程序代码封装成这种组件。由于这些具备特定逻辑的企业对象只和它本身的领域知识有关,大多没有整合其它组件的程序代码或是执行判断逻辑的程序代码。一般来说这种企业对象会因为企业逻辑或是数据库的改变而需要修改,因此,程序员应该尽量不要把这种企业对象输出给客户端应用程序使用,而应该尽量让Larger Grained企业对象使用这些企业对象来完成客户端应用程序的要求。Finer Grained企业对象也是分布式对象中的功能对象、实体对象和数据对象等。

因此,当程序员在开发实际项目时,要考虑好把哪些内容封装成Larger Grained企业对象,把哪些内容封装成Finer Grained企业对象。合理的划分企业对象有利于提高系统的执行效率。

2 结束语

其实影响一个分布式多层应用系统执行效率的因素还有很多,由于其它的因素与Delphi的关系不太大,这里就不进一步讨论了。上述内容无论对高级程序员还是一般的程序开发人员都是应该注意的,这些看似简单的细节对多层应用系统的执行效率却有着很大的影响。通过对这些内容的掌握,再加上对应用程序服务器和数据库服务器等技术的进一步了解,是能够开发出性能优良的系统的。当然要想开发出真正高效的分布式多层Web应用系统还需要开发人员在实际中积累开发经验和深人了解相关的知识背景。

参考文献

[1](美)Xavier Pacheco等.Delphi for.NET开发人员指南[M].北京:机械工业出版社,2004.

[2]李维.Delphi7.x分布式多层应用系统篇[M].北京:机械工业出版社,2005.

[3]蔡宏.Delphi 2006 for.NET开发技术原理与实践教程[M].北京:电子工业出版社,2007.

[4]陈省.Delphi深度探索(第二版)[M].北京:电子工业出版社,2004,1.

[5]尹会滨.网络数据库应用系统开发实用教程(Delphi版)[M].北京:清华大学出版社,2006.

面向应用的多层交换 篇2

应用层智能流量分配

第2 层和第3 层交换产品对于端到端的性能和服务质量要求来说还远远不够,因此基于TCP 和UDP 端口以及基于应用层的第4 层、第5 层和第7 层交换技术的产品势在必行。

第4层交换技术利用第3层和第4层包头中的信息来识别应用数据流会话。利用这些信息,第4层交换设备可以作出向何处转发会话的智能决定,从而实现负载均衡。此外,第4 层交换还具有传输流优先级分配等功能。

但是,仅仅依靠第4层还有欠缺。有统计表明,即使采用配置最高的网页服务器,如果访问用户数超过1000 个,网页反应将会明显下降,出现常见的阻塞现象。一般一台Web 服务器只能承受几百个并发用户,通常的解决办法是增加Web 服务器。第4 层交换机具有流量分载功能,可以根据多种负载均衡算法,实现传输流在多个Web服务器之间的分配。

不幸的是,由于第4层交换并不能识别传输流的应用类型,会有可能将某些访问发送到无法做出响应的Web服务器,导致错误的信息或时延。而相比之下,第5 层和第7层交换则是基于应用层的流量分载技术,具有认知应用的智能性。应用层的智能交换通过打开应用/ 表示层,识别传输流的内容和类型,这就使得不仅仅是基于URL做出全面的均衡分载决策,而且还能依据访问应用的具体类型(.html、.cgi、.ASP 和.Java 等)智能地向对应的Web服务器传输,无论这些应用正使用什么端口号。

应用层智能流量分载还能保证不同类型的应用可以赋予不同级别的优先权。更重要的是,由于具有智能识别功能,这种交换方式可以以线速度做出传输流决策,用户将自由地根据得到的信息就各类传输流和其目的做出决策,优化Web 访问,为最终用户提供快速及不间断的网页服务。

带宽分配及服务保证

企业网与Internet互联的广域连接,其带宽的费用相对昂贵,而且带宽常常是很有限的。而一般路由器的做法是采用先到先得(Best Effort)方式,这很容易使有限的带宽分配给某一种应用(例如FTP),而且被独占,导致其他用户的访问不能很快得到响应。

一种比较先进的带宽分配解决办法就是对各种应用及服务(例如HTTP、FTP、电子邮件、DNS和视频等)进行有效的带宽分配,而且可以进行动态分配,将尚未使用的带宽先借给其他应用,这将使有限的带宽发挥更大的效用,让更多的用户得到更好的服务。

发展无极限

多层开发 篇3

多支撑(锚杆)挡土桩墙是目前桩墙式支护结构中被广泛采用的一种形式,计算方法繁多,一般有等值梁法,二分之一分担法,弹性法,有限元计算法,逐层开挖支撑支承力不变法等。多层支护的施工是先施工挡土墙或挡土桩,然后开挖第一层土,挖到第一层支撑或锚杆点以下若干距离,进行第一层支撑或锚杆的施工。然后再第二次挖第二层土,挖到第二层支撑(锚杆)支点下若干距离,进行第二层支撑或锚杆施工。如此循环作业,直至挖到坑底为止[2]。逐层开挖支承力不变计算方法是根据实际施工,按每层支撑受力后不因下阶段支撑及开挖而影响数值的原理进行的,计算时假定板桩在相邻两支撑间为简支梁,然后根据分层挖土深度与每层支撑设置的施工情况分层计算,并假定下层挖土不影响上层支点的计算水平力,由此计算出板桩的弯矩和支撑作用力。对于深基坑支护设计软件的开发,近年来我国一些科研机构和高校基于不同的分析模型及计算机开发环境,已有多种深基坑工程设计软件,很多都已走进市场,并得到一定范围的推广[4]。目前还没有软件能通用于各地的基坑支护结构的设计,所以根据具体情况,依据文献[2]以VB6.0为平台编写算法,通用性强,计算出的数据可以适用于基坑支护设计人员参考。

1 逐层开挖支撑支承力不变计算方法

1.1 计算假设

1)上一层支撑后,下一层开挖时认为上一层支撑变形甚小或认为其不再变化,受力也不改变。

2)上一层支撑阶段,挖土深度需满足下一层支撑施工的需要,一般假定上一层锚杆支撑阶段,挖土深度需达到下一层锚杆位置下的0.5 m,满足支撑或锚杆的施工距离。

3)逐层开挖支撑时皆需考虑坑下零弯点距离y,即近似的为土压力为零点距离。

4)每层支撑后其支点计算时可按简支考虑。

1.2 计算方法

基于上述假定:

首先找出C点下零点距离y,如图1b)所示,可以计算如下:

要考虑桩与土的摩擦力,即考虑摩擦角δ,一般取余志成,施文华等推荐使用31,对于y值他们也推荐使用经验资料查表得出。

或者y值由经验资料查表得出:

然后由y求出O点以上土压力EA(包括主动土压力、水压力和地面荷载):

对于RC,同样考虑第三阶段挖土在D点尚未支撑时的各种水平力,求出D点坑下的零点距离,用此方法可以求出RD,同样可以适用于更多支撑情况,可以求出n个支承力。

2 编程开发

2.1 程序说明

面向对象新的编程技术兴起于20世纪90年代,它是计算机程序开发方法的一种变革,是利用计算机研究问题、解决问题的一种新的思维方式,它使程序设计更加贴近现实。

桩墙式多层支撑逐层开挖支承力不变计算法的程序设计方法,采用面向对象编程思想,将工程设计中的问题抽象,是利用计算机解决问题的一种新的思维方式,利用Visual Basic的常用控件,设计出一个简明可视化的操作平台,通过计算前定义各类参数,结合理论公式,利用程序代码编写出。

2.2 软件的主要功能组织

根据文献[2][5]中桩墙式多层支撑逐层开挖支承力不变计算方法及可视化界面设计的原则和方法,该软件的主要功能组织及计算界面如图2所示。

3 工程应用

北京京城大厦超高层建筑[2],地上52层,地下4层,建筑面积110 270 m2,地面以上高183.53 m,基础深23.76 m,采用进口488 mm×300 mm H型钢桩挡土,中间距1.1 m,3层锚杆拉结。各层土的平均重度为19 kN/m2,土的内摩擦角平均为30°,地面荷载按10 kN/m2,设计锚杆3层,第1层悬挑5 m,第2层7 m,第3层距地面18 m。

由以上所给的资料,各方法计算得出比较表(见表1)。

kN

RB较其他方法普遍大30%~50%,等值梁法没有考虑这部分土压力,二分之一分担法只考虑了一半。二分之一法只是近似方法,而连续梁法荷载复杂,与实际有一定差距。逐层开挖支撑支承力不变法是比较合适的计算方法。

以例题层支撑为例计算界面见图3

4 结语

1)以逐层支撑(锚杆)支承力不变计算多层挡土墙方法算法既简便,又符合实际施工状况,是比较合适的计算方法,可以方便简洁的计算出各开挖阶段支撑的弯矩零点距离,各层支撑轴力,弯矩等,可以对支承力轴力进行实时分析和调整。

2)在此计算方法上,通过编程实现由繁到简的变化,主要内容包括零点弯矩距离计算、主动土压力计算、各支撑的支承力和弯矩计算等,比起手算来说显得更加合理,可以实现对同一问题的多种处理。利用程序极好地解决了计算量、工作量大容易出错的问题,同时也可以避免重复劳动,算得结果适用于基坑支挡的各种类型参数取值,方便工程人员进行参考。

3)此类挡土结构设计计算含有循环迭代,重复调用,参数繁多,计算量庞大等特点,特别适用于计算机编程求解,条理清楚、简单易实现且能够保证速度和准确性

摘要:对目前使用的桩墙式多支撑逐层开挖支承力不变法从受力原理和计算方法上进行了分析,并利用可视化语言Visual Basic6.0编制了计算程序,最后指出该方法适用于深基坑支护中多层支撑的支挡结构。

关键词:多层支撑,逐层开挖,支承力,计算程序

参考文献

[1]张修明,张振栓.某高层建筑深基坑护壁结构倒塌概况及原因分析[A].中国建筑学会施工委员会第六届第二次学术年会论文集[C].1995.

[2]余志成,施文华.深基坑支护设计与施工[M].北京:中国建筑工业出版社,1997.

[3]秦惠民,叶政青.深基坑施工实例[M].北京:中国建筑工业出版社,1992.

[4]赵志缙,赵帆.深基坑工程技术的进步与展望[J].建筑技术,2003,34(2):88-93.

[5]胡彧,闫宏印.VB程序设计[M].北京:电子工业出版社,2001.

如何分析漫画的多层寓意 篇4

漫画就其性质而言,可分为两类:一类是讽刺性的,揭露生活中的假、丑、恶;一类是颂扬性的,褒扬生活中的真、善、美。据此,我们在解读漫画时,可以有两种立意方式。

(一)平行式立意。适用于性质单一型的漫画。先将漫画的性质正确定位,然后根据画面提供的信息,从同一层面(即或讽刺,或颂扬)但从不同的角度去分析、提炼,并加以概括。以江苏省泰州市2004年中考试题为例,《长大以后我就成了你》是一首歌颂教师的歌,仔细观察右边的漫画,说说漫画的含义(至少两层)。提示语已明确告诉我们这是一幅颂扬性的漫画,我们只要寻找不同的切入点即可。如从父子之间亲密关系的角度去分析,可得出“赞扬了中华民族尊老爱幼的传统美德”的结论;从父子二人从事同一职业的角度去分析,可得出“表现了两代人对教育事业的热爱”的结论;从父子二人工作态度的角度去分析,可得出“赞美了教师的敬业精神”的结论……

(二)对比式立意。有的漫画寓意并不固定。从甲层面看,它是讽刺性的;从乙层面看,它又是颂扬性的。正所谓“横看成岭侧成峰,远近高低各不同”。这类漫画需要我们从不同层面的多个角度去解读。以《家园静悄悄》这幅漫画为例,如果从正面立意,从家长的角度去分析,可得出“表现家长关心孩子的学习,为孩子创造良好的学习环境”的结论;从孩子的角度去分析,可得出“子女应理解家长的良苦用心,自觉学习”的结论。如果从反面立意,从家长管理方式不当的角度去分析,可得出“讽刺某些家长对孩子的约束太多”的结论;从家长教育目光片面的角度去分析,可得出“讽刺某些家长一味看重孩子的学习成绩”的结论……

同学们平时应多注意对发散性思维的培养,试着从不同的层面、不同的角度去分析问题,这对理解漫画的多层寓意是大有裨益的。但不管采用何种方法,还是应以分析漫画单层寓意的方法为基础,因为对漫画多层寓意的分析,只不过是在对单层寓意漫画分析的基础上增加了分析的层面和角度而已。在任何时候,同学们都要遵循以下原则:

(1)注意标题及画面上的文字。有时标题就是漫画的含义之一;画中文字大多是人物对话,可帮助我们解读情节。

(2)分析漫画中的故事情节和人物形象,找准讽刺或颂扬的对象。特别要注意某些夸张的细节,因为夸张往往是漫画表达寓意的主要手段。

(3)联系生活实际,整体感悟。特别是对托物寓理型的漫画要能由物及人,由事推理,切不可仅停留在画面的表层。

(4)语言要精练,概括要准确,分析尽量做到一语中的,简洁明了。

练一练

1.认真观察下面《三代人赶集》的一组漫画,写出自己探究的结果(2006年湖北省黄冈卷)。

探究结果:(1)______________________________________________________

(2)________________________________________________________________

(3)________________________________________________________________

参考答案:(1)时代在进步,人们的生活水平在不断提高。

(2)时代在前进,人们的生活方式发生了很大的变化。

(3)农民的生活观念有了很大改变。

(4)科技发展给人们的生活带来了极大的便利。

2.认真观察下面这幅漫画,说说漫画的寓意(至少两层)。

参考答案:

(1)学生的课业负担较重,教育主管部门应将“减负”落到实处。

(2)部分学生的劳动观念淡薄。

(3)家长不可过分溺爱子女。

(4)社会上有些人无孔不入,把赚钱的手伸向了学生,可谓“生财有道”。

3.认真观察下面这幅漫画,说说漫画的寓意(至少两层)。

参考答案:

(1)学校考试过于频繁,与实施素质教育的要求背道而驰。

(2)榜样的力量是无穷的。

4.认真观察下面这幅漫画,说说漫画的寓意(至少两层)。

参考答案:

(1)批评某些家长的教育方法简单粗暴。

(2)批评一些学生不思进取,荒废学业。

多层开发 篇5

关键词:内饰项目开发,多层次模糊评价,风险

一、引言

汽车产业从客观上反映了一个国家工业的综合水平。近些年, 车型更新速度加快, 研发周期越来越短, 质量要求越来越严格, 成本压力不断加大, 项目开发能力决定了企业能否在激烈的市场竞争中得以生存。项目开发过程中, 会遇到来自成本、进度和质量等方面的风险, 这些风险造成的不确定性增加了项目管理的难度, 甚至直接决定项目的成败。因而, 对项目开发过程中的风险评估就尤为重要。

目前国内外对项目开发过程中的风险研究对象大多侧重于IT技术产业或高新科技企业的高新技术开发项目, 本文利用多层次模糊综合评价法对某公司汽车内饰项目开发过程中风险进行评估, 以期为非IT企业的制造业能够有效地规避项目开发过程中的风险献计献策。

二、评价指标体系设置及评价方法

评价指标体系的建立应符合实际情况, 既要综合考虑评价指标的系统全面性、科学性、独立性、可测性和可操作性, 不能仅由某一原则决定指标的取舍, 又由于各项原则各具特殊性, 对各项原则的衡量方法和精度又不能强求一致。纵观国内外研究成果, 通过对相关风险因素研究的借鉴及相关知识和实践经验的总结, 构建了汽车内饰项目开发过程中的风险的多层次模糊评价指标体系, 如图1所示。

图1将汽车内饰项目开发过程中的风险因素分为两级, 一级指标级为Ui (i=1, 2…, 8) , 二级指标为Uij (i=1, 2…, 8;j=1, 2…, 6) 。各指标的评价等级Vg (g=1, 2…, 5) 为风险很高、风险较高、风险中等、风险较低和风险很低5级。

三、模糊评价模型的构建

(一) 权重的确定

为使权重更符合客观实际且能够量化表示, 本文综合使用德尔菲法和层次分析法来确定权重, 利用具有严密逻辑性的数学方法剔除专家知识经验中的主观部分, 根据判断矩阵是否具有一致性来检验权重的合理性。

由k名专家组成专家组, 使用1~9标度法, 将评价指标体系中的第i个指标与第j个指标两两比较, 其相对重要度为aij, 据此构建评价指标的判断矩阵:

其中, aij满足以下条件:aij>0, aii=1, aij=1/aji (i, j=1, 2, …, 8) 。

由于风险的复杂性和主观判断的不确定性, 难以将同一准则下不同评价指标的相对重要程度aij判断得十分准确, 因此需对判断矩阵进行一致性检验, 使之达到满意的一致性检验。具体做法为在Matlab中使用程序

计算判断矩阵的特征值λmax, 进而用 (1) 式计算一致性指标。

在再根据 (2) 式计算相对一致性指标。

其中RI为随机一致性, 与判断矩阵的阶数有关, 可通过查表得出。CR越小, 说明其一致性越好。一般认为, 当CR<0.1时, 判断矩阵符合一直性标准, 层次单排序是可以接受的, 否则要要修改判断矩阵, 直至检验通过。

一致性检验通过后, 用Matlab程序

计算判断矩阵的特征向量, 此归一化向量中对应的值即为各评价指标的权重Wi。

(二) 模糊综合评价

1. 构建评价矩阵

由此可得风险评价指标体系中的二级评价指标aij的模糊评价矩阵为

2. 进行多层次模糊评价

采用加权评卷型模糊评价模型, 求得风险评价指标体系中的二级评价指标的评价矩阵为

其中Bi为风险评价指标体系中的二级指标aij对于评价级第Vg级的隶属度;Wi为风险评价指标体系中的二级评价指标权重;Ri为风险评价指标体系中的二级评价指标aij的模糊评价矩阵。

一级模糊综合评判时, 应为相应的二级模糊综合, 因此一级评价指标的综合矩阵为

进而, 风险评价指标体系的多层次模糊评价结果为

B=W×R

其中, W为风险评价指标体系中的一级指标权重。

3. 模糊评价级清晰化

风险的多层次模糊评价结果R是一个模糊向量, 不能准确反映风险的现状, 因此本文采用分段赋值法, 即为每个评价等级Vg赋值Sg, 则风险评价的总分为, 从而将风险多层次模糊评价集清晰化。

四、实证研究

请了Y公司的10位专家, 其中有3位是资深项目经理, 2位管理岗位专家, 2位财务专家, 另外3位是技术岗位专家。由他们对项目开发过程中所面临的各种风险因素的相对重要性进行评价, 并评估风险等级, 进而确定Y公司内饰项目开发过程中的风险权重并进行多层次模糊综合评价。

(一) 计算指标权重

根据专家组针对各项指标的重要性排序的结果, 依照层次分析法的原理, 风险评价体系中的一级评价指标的判断矩阵为

特征值λmax=8.8527, 一致性指标CI=0.1218, n=8, 查表得随机一致性RI=1.41, 相对一致性指标CR=0.0864<0.1, 满足一致性要求, 对应的归一化后特征向量为W= (0.0895 0.1455 0.3102 0.3102 0.06340.0399 0.0245 0.0167) T, 进而各风险的权重排序为:工程质量风险=技术风险>成本风险>进度风险>管理风险>财务风险>专利风险>支持风险。

由于篇幅限制, 只给出风险评价指标体系一级指标的权重确定过程。同理可以得出风险评价指标体系二级指标的权值向量:

(二) 进行多层次模糊综合评价

1. 进行二级评价

根据专家组评价结果, Y公司内饰项目开发过程中的风险评价指标体系中的二级指标的评价集如表1所示。

同理, 可得出

2. 进行一级评级

B= (0.1114 0.3193 0.3985 0.14420.0263)

通过对评语进行量化处理后, Y公司内饰项目开发过程中的风险最高分为65.9997, 最低分为46.8940, 平均分为56.5949, 表明Y公司内饰项目开发过程中的风险处于中等偏高程度。

五、结语

多层开发 篇6

WCF(Windows Communication Foundation)是微软提出的基于服务架构(SOA)的网络通信API。WCF是一款真正面向服务的产品,从功能上讲,完全可以看作是ASMX、.Net Remoting、Enterprise Service、WSE、MSMQ等技术的并集。WCF统一了多种微软的分布式技术,提供了对跨供应商互操作性支持,解决了各种分布式技术之间的互联互通问题,尤其是异构平台下构建分布式应用的整合问题。WCF具有良好的松耦合、平台无关性和互操作性,使其成为微软分布式开发核心技术。

WCF作为新一代通信基础,具有众多优势:继承SOA架构优点,迅速构建松耦合的分布式企业级应用;良好的兼容性和统一的开发模式,提供互操作支持,适合不同的应用环境;提供安全、可靠的服务级分布式事务。

本文结合高校户籍管理系统,将WCF技术应用于当前非常流行的多层架构设计,满足项目安全、互操作和跨平台网络通信需求,具有一定的理论与实践意义。

1 基于WCF的多层服务架构

基于WCF的多层架构分为:页面表示层、WCF服务层、基本逻辑层和数据访问层[1,2,3,4]。系统多层架构设计见图1。

页面表示层主要负责用户与系统的交互。WCF支持WS-*标准,其客户端可以运行在异构平台,通过WCF提供的接口与WCF服务交互。当业务逻辑改变时,页面表示层无需修改,只需保持客户端的服务不变即可,简化了客户端编程的复杂性,方便了系统维护。

WCF服务层处于基本逻辑层和页面表示层之间,对业务逻辑层进行封装和抽象。WCF服务层设计数据契约、错误契约、消息契约和服务契约及服务层接口,为页面表示层提供服务。

基本逻辑层实现WCF服务的具体内容,是系统的逻辑处理中心。基本逻辑层处于数据访问层和Web服务层之间,对上层提供逻辑处理服务,调用下层数据访问层接口连接数据库。

数据访问层为基本逻辑层提供数据库操作方法,结合ADO.NET技术,实现对数据库的链接及数据的存取操作。

2 WCF服务层设计

高校户籍管理系统主要包括户籍信息管理、信息查询管理、收费管理、操作日志管理和学院信息管理等模块,采用传统多层架构开发模式[5]。本文重点讨论WCF服务层的设计与实现。

WCF客户端在通信过程中,先生成本地代理,通过代理经过访问点与服务端对应访问点交互。访问点是实现消息交换的基础,使用地址(Address)指定提供服务位置,使用绑定(Binding)配置通讯协议,使用契约(Contract)发布服务,通过XML标准格式的WCF配置文件,对外暴露访问点,提供服务。

WCF服务层契约的设计及实现是非常重要的一步。WCF包含4种契约,分别是数据契约(Data Contract)、错误契约(Fault Contract)、消息契约(Message Contract)及服务契约(Service Contract)。

3 WCF服务层实现

以高校户籍管理系统的户籍信息管理为例,简要概述数据契约、服务契约的实现。

(1)RInfo(户籍信息)数据契约主要实现代码如下:

其中,[DataContract]指定自定义结构的数据契约RInfoRequest,WCF提供了序列化支持。RInfoResponse的定义类似,[DataMember]指定数据成员。

(2)WCF服务接口主要实现代码如下:

通常使用接口来定义服务契约。IRInfoService为定义的户籍信息服务契约名称,包含CreateRInfo()方法创建户籍信息,接收一个RInfoRequest类型参数。[Fault-Contract]指定错误和异常的错误契约。

(3)WCF服务契约主要实现代码如下:

WCF服务实现方法是在服务端继承实现IRInfoSer-vice接口。接口实现过程中,通过数据访问层Storage的InsertRInfo()方法调用Wrapper封装类,Wrapper封装对数据库存储过程调用,实现数据的增删改查。

4 访问点配置实现

通过WCF配置文件,设置访问点内容,对外提供服务。WCF配置文件采用标准的XML格式,在配置文件中对访问点属性进行设置,主要代码如下:

5 结语

架构设计是整个项目设计开发过程中非常重要的一环,WCF服务层接口的设计与实现是分布式应用的关键。本文结合高校户籍管理系统,给出WCF服务层数据契约和服务契约的具体实现方式以及访问点配置,提高了系统的互操作性,节省了后期维护费用。

下一步工作是提出一整套基于WCF的.NET多层架构解决方案并进行精简和优化,降低系统设计开发的复杂度,提高系统的可扩展性和可移植性,结合AJAX技术的使用,进一步提高用户体验。

参考文献

[1]王连泽,李希龙.利用WCF技术实现两层/三层的兼容架构[J].电脑编程技巧与维护,2015(7):10-12.

[2]赵晓鹏,卫耀伟,常晓冰.基于WCF的综合治税信息系统设计与实现[J].软件导刊,2015(5):129-130.

[3]王光琼,杜天行,未永庆,等.基于SOA构架的分布式租车公司管理系统设计与实现[J].软件导刊,2014(6):52-54.

[4]孙志中,魏嘉银,秦永彬.基于WCF和NHibernate的软件架构研究及应用[J].计算机与数字工程,2015(4):43-44.

多层开发 篇7

Delphi提出的MIDAS (Multi-Tier distributed Application Services Suite多层分布式应用服务器组) , 是把原来Two-Tier数据连接放到了服务器端的Socket组件上, 客户端只剩下了执行文件和Socket组件, 前台和服务器上的Socket组件, 通过Socket机制互相沟通。

这个多的一层称为应用程序服务器 (Application Server) , 或者称为中间件。

这种多层分布式工作机制主要基于这样几点考虑:

(1) 减少客户机的维护量, 因为前台程序比较简单。把企业逻辑封装在通用的中间件应用服务器中, 不同的客户都可以共享同一个中间层 (包括Web) , 而不必每个客户都单独实现企业规则, 避免了重复开发和维护的麻烦。由于客户程序相当瘦 (这就是当下流行的瘦客户机概念) , 无论是开发还是发布, 都变得简单了。

(2) 便于升级, 当中间件升级的时候, 客户程序可能不需要变化。

(3) 实现了分布式数据处理, 把一个应用程序分布在几台机器上运行, 可以提高应用程序的性能, 也可以把敏感部分封装在中间件, 为不同的用户设置不同的访问权限, 增强了安全性。

(4) 减少直接连接数据库的用户数目, 减少费用。

下面通过一个实例来说明多层数据库的设计问题。

主要想解决这样几个问题:如何建立一个简单的分布式系统, 如何使用SQL, 如何传递附加信息和向客户提供服务器方法, 有了这些方法, 就可以建立属于自己的性能更加高效的数据库系统来。

2 SQL服务器端程序

首先用上面相同的方法建立一个服务器端COM工程。工程名取为Project1, 服务器名为App Server, 在其Remote Data Module页面放入一个Query (BDE页面) 和一个Data SetProvider控件 (Datasnap页) 。如图1所示。

Data Set Provider的属性Options下的po Allow Command Text=true, 这实际上已经建立了一个基于SQL查询的服务器端程序。

3 客户端查询服务器端的别名集

在SQL查询以前, 用户往往需要指定查询哪个数据库, 所以需要把服务器上BDE数据库别名 (Alias) 设置数据调出到前台程序来。

具体做法我们先回到服务器端:

在上述服务器端再建立一个TSession和一个Tdata Base (BDE页) 。

Session1属性:

Data Base1属性:

如果不希望输入密码:

Login Prompt:false

这里, Query1的连接属性要变一下, 因为它要通过Data Base来联接数据库 (以后在前台可以直接通过改变Data Base的属性来改变联接) 。

Data Base Name=Data Base1的Data Base Name:自定义的名 (这里比如为aaa) 。

SQL属性输入一个基本的SQL语言:select*from course.db (打开课程表)

Active=true表示这样也可以连接上了, 结果如图2右部分。

TQurey增加个属性

Session Name:Session1_5

这样就可以用Session对象来管理数据源的信息了。

再利用两个Label, 显示当前在线人数, 以及进行SQL查询的次数。如图2所示。

为了传给客户端值, 并能够由客户端来对服务器端进行某些控制, 需要在COM中加入3个方法:

View->Type Library显示接口窗口。

右键ISQLSverver1 (具体根据设置名不同而不同) ->New->, 如图3、图4所示, 建立3个方法 (Method) :GetDatabase Names, Get Table Names和Set Database Name。

刷新 (Refresh Implementation) 以后, 就产生两个函数和一个过程:

在Get Database Names部分, 用以传输别名数据, 其接口信息为:

以下为3个方法的程序代码:

上面的函数的关键除了取得BDE数据库别名以外, 还声明了一个变量数组来存放数据库别名数据, 所以用Var ArrayCreate函数建立一个变量数组, 其中参数1:指定数组范围。

参数2:数组数据类型, 由于别名要通过S传给前台, 数据类型必须设成var Ole Str才有效。

同时还要说明Var Array Create函数是在Variants单元中建立的, 所以, 在implementation下还需要声明:

uses Variants;

否则会编译出错, 必要时还要加上Unit1。

第二个过程是客户机提供上来的联机数据。

现在可以写此函数的程序了:

4 服务器端进行客户计数程序

除了上面的功能外, 这个程序还加上了一个在线用户以及查询用户统计的功能。由于这个应用程序执行模式是Multiple Instance执行模式, 所以当某个前台第一次连上线后, 应用程序服务器会激活Remote Data Module的事件程序, 而断线后又会执行On Destroy事件程序, 因此就可以用这两个事件计算连上服务器的用户个数。至于Query个数的计算, 则由TQuery的On After Open事件函数判断。Form1部分, 主要用于显示:

首先在form上安放5个Tlabel控件, 其中4个放在一个容器Panel1里, 两个计数的label分别取名为Client Count和Query Count, 属性Capyion=0。如图5所示。

注意, 下面的程序在Form1所在的单元Unit1中编写。

在private下声明两个变量:

FQuery Count:Integer;

FClient Count:Integer;

在public下声明两个过程:

procedure Update Client Count (Incr:Integer) ;

procedure Inc Query Count;

在实现期写入过程:

在SQLServer1窗口的两个事件On Create和On Desticy, 建立事件驱动程序:

在Tqurey的事件After Open建立事件驱动程序:

5 SQL客户端程序

(1) 建立一个普通的工程:Project2.apr。

(2) 在Form上放置一个TSocket Connection控件 (在Datasnap页) , 属性:

在本机注册时, 可直接设置以下属性:

这时可以看到服务器端的服务器应用程序被激活了。

如果在网络上调试, 需要给出服务器IP地址Address的值和Server GUID的GUID值 (自动给出) 。

(3) 放置一个TClient Data Set控件 (在Data Access页) , 属性:

(4) 放置TData Source, 属性:

Dataset:指向Client Data Set1

安放合适的数据库绑定控件。放置Demo控件作为SQL语句输入用。

希望用户直接调用服务器端的别名, 可以加入一个Combo Box控件:

Form1的Create事件可以写成:

运行以后可以看到服务器端的所有的别名, 如图6所示。

现在, 可以给Combo Box1加入一个双击事件:

以后就可以利用服务器端的别名列表选择数据库了。

双击该列表框实际上已经实现了联接, 但是, 窗口除关闭掉数据库显示以外, 并没有其他的反应, 这就是说, 这个程序使用上还有若干不方便的地方, 最重要的就是当连接上数据库以后, 无法知道表的名字。这样, 也无法方便地构造查询数据集的SQL语言。

所以在客户端现在给它再加一个Combo Box, 以显示当前打开的数据库的表名。如图6所示。

在.Form Create事件过程中, 再声明一个变量:

DBTables:Ole Variant;

在.Form Create程序的最后加上:

为了在改变数据库后也能正确显示相应的表名, Combo Box1的双击事件也要加上相应的一段。

给Combo Bpx2加一个双击事件, 可以把表的名字加入SQL语句:

效果就完全不同了, 可以方便地选择数据库和表, 运行过程如图6所示。

然后组合适当的SQL语言, 最终打开一个合适的表。

进一步考虑, 组合新的SQL语言的时候最好要有字段名的数据, 这不需要从服务器得到, 因为在多层情况下, ClientData Set实际上起着Ttable或者Tquery相似的作用, 对数据库的控制上, 有几乎相同的语言, 例如记录指针的移动, 字段数据的取得和写入等, 这样一来, 也可以直接使用这些方法来操纵数据库。

Client Data Set是个功能强大非常重要的控件, 在Delphi的很多高级场合, 都要使用到它。

当然, 利用Client Data Set, 被打开数据库的字段名表也很容易得到。

首先再加一个Combbox控件Combbox3。

把SQL查询的Button事件作如下修改:

事实上, Form Create事件程序也要加入相应的程序, 使一打开程序就有字段名表显示。

需要时, 也可以写入Combo Box3的双击事件:

现在可以看看利用Delphi的Socket Cnnection组件调用服务器端的数据显示效果, 如图6所示。

这些数据取得以后, 就可以把这个客户程序做得更加方便通用, 那就要看想象力和程序设计的水平了, 这里事例主要是想提供客户端使用Socket提供的方法思想和规则, 通过这样的设计过程, 是不是对Socket和分布式数据库的问题有了更深的理解了呢?从我设计教学选课系统等的经验来看, 这是简便的多层数据库设计方法。

但需要提醒两点, (1) 利用Socket Connection组件开发多层数据库应用程序, 服务器端还必须运行一个现成的Socket中介程序Sckt Srvr.exe, 该程序在安装的Delphi的bin目录下; (2) 程序调式是Socket Connection组件的Address属性不能缺, 本地设为127.0.0.1, 网络设为实际的服务器IP地址。

摘要:介绍了Delphi下的MIDAS (Multi-Tier distributed Application Services Suite多层分布式应用服务器组) , 并通过实例讲解使用SocketCnnection组件开发分布式多层数据库的实现。

多层开发 篇8

1 S-3断块油藏地质特点

1.1 断层发育, 为复杂小断块

S-3断块由南、东、西三个方向F1、F2和F3三个正断层切割形成的一个小型断背斜构造, 断层断距20-50m, 封堵性好, 落实程度高。S-3构造圈闭小, 面积约1km2。

1.2 含油层系多, 厚度不均, 储量分布零散

S-3断块U段划分为四个油组, 含油油组为II、III、IV油组。含油小层为II-4、III-3、I I I-5、I V-1、I V-2、I V-3和I V-4层共7个小层。纵向上储量主要分布在III-5和IV-2小层, 占总储量的57.9%。

1.3 中高孔、中高渗储层

U段储层为三角洲前缘的水下分流河道沉积。储层岩心分析平均孔隙度28%, 渗透率13.2-1000m D, 平均609m D。

1.4 构造控制的边、底水油藏, 具多套油水系统

从S-3断块油藏总体特征来看, 油藏主要受构造影响。主要为边水油藏, 个别层位为底水油藏。

2 开发对策研究

针对油藏特征, 主要从开发方式、开发层系划分、开发井型的选择及其组合对策方面进行探讨。

2.1 开发方式研究

该油藏具一定的边、底水能量, 弹性产率2.17万吨/MPa。初期开发能量较为充足。但由于油藏处于半封闭状态, 为“无源”弹性水压驱动。从Z-1井试采历史拟合结果 (图2) 中可以看出, 随着开发的进行, 地层压力下降较快。分别模拟天然能量开发和注水开发方式, 可得到图3中地层压力变化特征曲线。

从压力变化曲线来看, 注水开发压力下降率较天然能量明显变缓。

考虑到初期天然能量较充足, 因此, 可在天然能量开发一定时间后选择适当时机进行转注, 充分利用天然能量。从图中可以看出, 在生产约5年后压力下降较快, 此时可转注。

2.2 开发层系划分研究

S-3断块U段油藏含油层系较多, 但储量主要集中在2个小层, III-5和IV-2小层储量占油藏总储量的57.9%。为模拟一套层系开发和分层系开发效果差别, 在开发方式、井型、井数和部署一致的情况下, 分别设计一套层系笼统开发和分层系开发进行对比, 模拟结果显示, 分层系开发效果要远好于一套层系开发, 10年开发期结束后采出程度相差5.7个百分点。 (图4)

2.3 井型适应性研究

边、底水对油藏开发来说, 既有能提供较强能量的优势, 又存在如果有效避免底水锥进、边水突进的问题。底水锥进主要原因是直井点状开发时, 泄压半径较小, 形成压降漏斗造成。而水平开发具有明显增加泄油面积、扩大泄压半径的效果。

为模拟纯直井开发和水平井开发效果差别, 分别设计直井开发和直井+水平井开发进行对比, 模拟结果显示, 水平井开发效果要远好于纯直井开发, 10年开发期结束后采出程度相差2.5个百分点。

因此, 可以看出, 在其他条件一致的条件下, 水平井+直井配合开发比纯直井开发效果要好。 (图5)

3 开发效果预测

根据上述探讨, 设计不同的组合方案: (1) 方案一:直井天然能量开发方案; (2) 方案二:直井注水开发方案; (3) 方案三:水平井+直井天然能量开发方案; (4) 方案四:水平井+直井注水开发方案;在同一地质模型下, 对四套方案进行模拟生产, 模拟结果见表1。

从四套方案模拟结果来看, 方案四也即水平井和直井组合注水开发效果最佳。从图6中也可以看出, 方案一中高部位剩余油还较多, 由于开发能量不足, 高部位虽然有井控制, 但依旧难以采出。

方案二中剩余油以井间分布为主, 直井难以完全控制油藏, 因此还残余一定剩余油, 方案三中由于水平井泄油面积大, 生产较为平稳, 但与方案一类似的是开发能量依然不足, 开发后期难以将高部位剩余油采出, 较方案一已有较大改观。方案四基本将剩余油驱出, 只在极少部位有残余油存在。

4 结论

综上所述, 对于多层状边、底水复杂小断块油藏, 影响开发效果的因素主要是开发方式、开发层系和开发井型的选择。

对于该类型油藏在开发方式的选择中, 最佳的对策组合方式为初期利用天然能量开发, 随后人工补充开发能量。以主力油层为主, 合理细分层系开发, 充分应用水平井技术与直井开发相结合, 最大限度地提高开发效果, 提高采收率。

参考文献

[1]王允诚主编《油气藏开发地质学》, 2006年

[2]刘丁曾主编, 《多油层砂岩油田开发》, 石油工业出版社, 1986年

[3]达克著, 刘翔鄂等译, 《油田开发设计》, 石油工业出版社, 1984年

诚心诚意,挑起多层爱 篇9

古语云:德高为师,身正为范。文人们歌颂:教师是太阳底下最光辉的职业。平日里和不是教师的朋友谈话时,总会听到他们的这样的赞美:“教师是多么神圣而受人尊敬的职业啊!”可是您们了解我们美丽的背后吗?

常言道: “少年智则国智,少年富则国富,少年强则国强。”党的十一届三中全会以来,我国教育事业发展迅速,近十几年是教育发展最快的时期之一,不仅教育改革与发展快,而且经费增长也快,初步形成了以财政为主、多渠道筹措教育经费的格局。孩子又是父母的希望和未来,决定一个家庭的美满、幸福、和谐。简简单单的几句话相信你们也看出孩子对社会和家庭的重要性。而作为教师的我们看到国家、社会、家长的付出和期待,我们感到我们身上的责任有多么大啊!我们到底该如何去做才能撑起这多层的爱呢?

思来想去我准备从以下两大方面来做努力——全心全意爱学生和认真钻研工作。

一、全心全意爱学生

我怎样去爱学生,才会使学生感受到这种爱,从而化为前进的动力呢?我从以下几个方面进行努力:

1.细心发现学生身上的闪光点,认可他的努力。

不论是成绩好的学生,还是成绩不好的学生,都会去发现他的特长,并及时给予正确的引导。

2.帮助孩子解决生活和学习中的困难。

有的学生,家庭经济条件不是很好;有的学生可能生活在单亲之家中,我会充当起母亲的身份,给孩子以支持,帮助孩子渡过难关。

3.平等对待每一位学生。

我将会在细节上做起。从语言、眼神、手势等诸多细节上对学生一视同仁,不要让学生感到受排挤,受冷落,从而形成自卑或自暴自弃的心理。

4.要以爱育爱。

我要通过自己对学生的爱,培育孩子的爱心。

二、认真钻研工作

我一直保持着这样的信念:“教师必须是源源不断的自来水。”为此我会在以下几个方面努力:

1.点燃激情,全力以赴

“我常常想,我们教师应该怎样的去工作才是最完美的工作?答案是:带着激情,全力以赴的工作。因为教育需要激情,教师的工作更要有激情,有了激情,我们才能热爱教育事业,激情让我们坚定信念,激情让我们痛并快乐着!只有充满激情的人,才会像恋爱的人一样“着魔”,会忠诚于教育这份神圣的事业,有了激情,我们才能端正教育态度。只有一个态度端正的人才会不断加强继续教育提高自己的育人水平;才会克服困难认真对待每一天的工作;才会保持一份平常心,一个良好的心态,去善待每一个孩子;才会用阳光般的心去发现学生心中的“阳光”。

2.顾全大局,心中长存使命感

《三分能力,七分责任》这本书中写到:在任何企业中,一个员工不论能力有多强,不以企业利益为重就不算合格的员工,一个只知道追求私利的员工,只会给企业带来损失。在我们的教育工作中不也是这样吗?“光荣的人民教师”是简短而又平实的一种称呼,但却那么亲切,那么深沉,那么响亮。它昭示了我们教师的地位和历史功绩,展现了新时期广大教师的精神风貌,提醒着我们教师时时规范、监督自己的言行。可见这七个字的简单组合,却能产生沉甸甸的分量,它让教师深深地体会到其中的光荣感,责任感和使命感。在工作中我们就更应有博大的胸怀,把学校当成自己的家,把学生们当成自己的孩子。做每一件事都从学校的角度出发,从学生的角度思考。教师要在平凡的工作中,干一行,爱一行。干一行,就干好一行。

3.超越平庸,挑战自我

在教育工作中,我们是日复一日,年复一年的重复着工作着,如果能在平凡的工作中孕育伟大,在重复单调的工作中享受生活,才是工作的最大意义,所以,我们就要努力在平凡的岗位上超越自我,挑战自我,创造出不平凡的成绩,把简单的事情做得不简单。

而要实现这点,教师首先一定要立志把“做一名优秀教师,做一名学生喜欢的教师”作为自己的教育人生的境界,把教育作为自己的一种生活方式,超越世俗的功利、超越自身的道德伦理价值,学识渊博,能力精湛,不断的超越平庸,超越自我,“风雨的后面是彩虹,困难的后面是成功”最终在践行和追寻中享受着教师职业带来的那份幸福与快乐。

作为教师,我用无限的责任来诠释对事业的执著。因为责任,我觉得我们应该有丰富的知识,有扎实的专业理论水平,上课能够做到驾轻就熟……这就要求我们要不断地充实自己,不断地学习。因为责任,我觉得我们应该掌握好的教学方法。只有这样,才能吸引学生的注意力,培养学生的学习兴趣和积极性,使学生的思维能力得到锻炼,从而能够自主地学习。因为责任,我们更应在实践中思索,在思索中反思,在反思中成长。而这背后的决定因素就是事业心、责任心和敬业精神。

多层开发 篇10

我国现代物流整体规模扩大,发展速度加快,运行效率提高,对经济发展的支撑和促进作用更加明显[1]。同时,据统计,国际航运业承担着国际货物贸易90%以上的运输量[2],随着经济全球化的快速发展,航运在全球化的贸易运输中的地位就显得尤为突出,航运物流信息的管理更显重要[3]。

信息技术和信息系统蓬勃发展,给物流企业业务流程、管理模式、组织机构的重组乃至整体的发展带来新的机会,促使传统的经营方式和思想观念发生深刻的变革,也对物流企业的经营理念和管理模式提出了挑战。我国的航运物流企业如果要实现适应未来日益激烈的市场竞争,最有效的方法就是通过开发管理信息系统来加强企业各个部门之间的相互协作,以提高企业的整体运作水平[4]。由此可见,航运物流企业构建管理信息平台已是大势所趋。

现有航运物流管理信息系统的开发模式下,IT组织很难对不同的功能和系统进行集成,很难对变化的商务需求和竞争需求及时做出反应。只要不是由单独的一个开发商来提供所有的功能,就一定存在着不严格的应用程序。本文提出了一种经改进后适应于.NET平台的J2EE平台的成熟、稳定、易维护的五层架构开发模式,同时考虑到系统将来的重用和扩展问题,将面向接口编程思想运用于此架构对系统进行开发和实现。这些接口在开发之初就已经考虑到重用问题,提供了标准的接口,可以被各种应用和其它服务所调用。

2 面向接口编程

定义:在系统分析和架构中,分清层次和依赖关系,每个层次不是直接向其上层提供服务(即不是直接实例化在上层中),而是通过定义一组接口,仅向上层暴露其接口功能,上层对于下层仅仅是接口依赖,而不依赖具体类。

(1)接口编程和面向对象编程是什么关系

面向接口编程和面向对象编程并不是平级的,它并不是比面向对象编程更先进的一种独立的编程思想,而是附属面向对象思想体系,属于其一部分。

(2)面向接口编程优势

这样做的好处是显而易见的,首先对系统灵活性大有好处。当下层需要改变时,只要接口及接口功能不变,则上层不用做任何修改。使用接口的另一个好处就是不同部件或层次的开发人员可以并行开工,就像造硬盘的不用等造CPU的,也不用等造显示器的,只要接口一致,设计合理,完全可以并行进行开发,从而提高效率。

3 基于.NET平台面向接口的分层架构

在.NET平台上,比较经典的分层架构是三层架构,从下到上依次是:数据访问层、业务逻辑层、表示层。各层职责如下:

数据访问层:负责与数据源交互,完成数据访问等一系列操作。

业务逻辑层:完成与系统业务有关的逻辑操作。

表示层:负责与用户交互、呈现数据等一起与系统表示有关的操作。

在这个架构中,每一层都不是一个类,而是一个类族。所以,在本文中,为数据访问层和业务逻辑层分别定义一族接口,业务逻辑层不依赖具体的数据访问层,而是仅依赖数据访问层的接口族,表示层也一样,依赖业务逻辑层的接口族。如此一来,当要更换数据库时,就不必改写整个业务逻辑层,因为业务逻辑层里根本没有任何数据访问层中的具体类,而全是通过接口实现的。

3.1职责划分

目前,在典型的三层架构中,对层次各自的职责划分并没有一个统一的规范,综合现有的成功实践和.NET平台的特殊性,在本文中将三层架构的职责划分如下:

数据访问层——负责与数据源的交互,即数据的插入、删除、修改以及从数据库中读出数据等操作。

业务逻辑层——负责系统领域业务的处理,负责逻辑性数据的生成、处理及转换。

表示层——负责接收用户的输入、将输出呈现给用户以及访问安全性验证。

4 系统设计

面向接口编程的多层架构开发模式下的航运物流管理信息系统模块见图1,在宏观上将整个系统分为以下几个模块:

实体类模块(POJO)——一组实体类的集合,负责整个系统中数据的封装及传递。

数据访问层接口族(IDAO)——一组接口的集合,表示数据访问层的接口。

业务逻辑层接口族(IApp,IServer)——一组接口的集合,表示业务逻辑层的接口。

数据访问层模块(持久层)——一组类的集合,完成数据访问层的具体功能,实现数据访问层接口族。

业务逻辑层模块(App层,Server层)——一组类的集合,完成业务逻辑层的具体功能,实现业务逻辑层接口族。

表示层模块(UI层)——程序及可视元素的集合,负责完成表示层的具体功能。

IOC容器模块(类工厂)——负责依赖注入的实现。

辅助类模块(Common层)——完成全局辅助性功能。

依照上面各模块间交互关系此航运物流管理信息系统框架图如图2。

Client(客户端):包括UI,App,IApp三个项目。

·UI,使用App接口变量和类工厂(本地模式)。

·IApp,定义函数接口。

·App,使用Server接口和类工厂(Remoting服务端single Call模式),领域的数据模型。

Server(服务器端):Server,IServer,持久层,持久层接口。

·IServer,定义函数接口。

·Server,使用持久层接口和类工厂(本地模式),企业数据模型,Cache池。

·持久层接口,定义连接数据库函数的接口。

·持久层,使用强类型数据模型,屏蔽底层数据库实现,统一数据操作唯一入口。

·数据库。

5 结论

基于.NET面向接口编程的架构模式已成功地部署在航运物流管理信息系统中,到目前为止,运行情况良好。其优点具体包括:

(1)使用面向接口的编程,接口的实现既可以是基于部门级数据,也可以是基于企业级数据;数据层不同的实现策略与业务逻辑实现无关;数据库修改引起的程序修改是可以被预期的。

(2)程序具有一致的结构,便于理解和维护,且数据的维护只有一个入口。

(3)系统允许递增迭代开发。用户界面、业务组件与Web服务可并行开发,单元调试与集成调试的效率都很高。

(4)通过加入Server层,向客户端屏蔽的数据库连接,数据库不需要向外公布IP地址以提高安全性,连接可以被共享,提高性能。

(5)此开发模式,做到需求与设计独立,设计与实现独立,业务逻辑实现与数据库独立;强调用户参与,强调流程的作用,降低个人作用;测试自动化。

参考文献

[1]张锡平,林亨,徐超,等.2005中国物流总成本研究[J].中国物流与采购网,2006(4):24-30.

[2]汪传旭.世界经济知识化对国际航运业的影响[J].珠江水运,1999(6):8-9.

[3]王沛仕.加入WTO后我国航运业的对策性研究[J].珠江水运,2003(4):7-11.

[4]方照琪.信息技术对航海的影响[J].中国水运,2005(6):50-51.

[5]Cao J D,Li P,Wang W W..Global synchronization in arrays of delayed neural networks with constant and delayed coupling[J].Physics Letters.A,2006,353(4):318-325.

[6]吴炜,张洪伟.微软.NEI技术在开发企业资产管理系统中的应用[J].计算机应用研究,2003(2):13-16.

[7]罗鸿,王忠民.ERP原理.设计.实施[M].北京:电子工业出版社,2003.

[8]金灿,陈绪君,朱绍文,等..NET框架中三种数据访问技术及效率比较[J].计算机应用研究,2007,20(4):155-157.

上一篇:经济学收益下一篇:高科技企业研发员工