面向框架（通用7篇）
面向框架 篇1
一、问题的提出
绩效预算作为一个古老而常新的概念,最早在1907年由美国纽约城市研究局提出,旨在协助管理与调控(Shultze,1968)[1],以美国为典型代表(1)的公共预算编制模式的发展历史,既是广义绩效理念融入预算管理机制的轨迹,也是绩效预算内涵演进与重归主流的演变历程。20世纪80年代以来,英国、澳大利亚、新西兰等经济合作与发展组织成员国持续推动了以产出和成果为导向的公共预算改革趋势。从2000预算年度开始的中国部门预算改革,随着市场经济体制改革和公共财政管理体制建设的不断深入而稳步推进,借鉴西方公共预算改革的理性思潮,绩效预算被政策层面定位于部门预算改革的远期目标,预算绩效评价则被强调为夯实未来绩效预算改革的基础工作。依此,财政部开始制定部分行业的绩效考评管理办法,组织部分中央部门开展预算支出绩效考评试点工作。与此同时,部分地方各级财政部门也制定了一系列绩效考评工作规范。然而,正如财政部在总结当前改革缺陷时所指出的“理论界和实际工作部门对绩效考评的认识仍有不足之处,绩效考评相关制度有待进一步规范和细化”[2],这也佐证了适应国家对预算改革的政策导向研究预算绩效评价的意义。
遗憾的是,在现阶段不具备实施绩效预算条件、又要全力推进预算绩效评价的现实背景下,对面向绩效预算的预算绩效评价的研究思路并没有引起充分的关注,进而导致疑惑、误区尤存,实践效果平平。“部门预算与绩效预算如何定位?绩效预算与预算绩效评价如何互动?中央部门与基层单位试点如何展开?”带着对上述问题的思索,本文提出面向绩效预算的预算绩效评价实现框架:围绕部门预算与绩效预算关系的推理、绩效预算与预算绩效评价定位的诠释、中央部门与基层单位双向试点的优化,形成一种双向互导效应模式。构建面向绩效预算的预算绩效评价实现框架,对于澄清关键范畴、把握政策基调、规划发展趋势具有重要的借鉴意义,从而也为完善宏观政策提供理论支撑。
二、绩效预算与部门预算定位的理性澄清
绩效预算不仅是预算方法的一种创新,也是政府管理理念的一次革命。绩效预算将政府预算建立在可衡量的绩效基础上,强调的是产出与成果导向,从而增强了预算资源分配与政府部门绩效之间的联系,有助于提高财政支出的有效性。在国家明确绩效预算是远期改革方向,预算绩效评价是近期基础工作的政策背景下,有必要澄清这样一个通常被理论界忽视的问题:“未来绩效预算改革是对部门预算的变革抑或调整?”,这也关系到当前预算绩效评价的客观平台是纯粹的事业发展成果抑或综合的部门预算成果。本文认为我国远期绩效预算改革是部门预算框架下的预算管理理念调整,旨在实现绩效信息与预算配置的有效结合,理由在于以下两方面。
第一,部门预算与绩效预算的预算管理角色差异性。部门预算是由政府各部门编制,经财政部门审核汇总后报立法机关审议通过,反映各部门所有收入和支出的公共收支计划和法律文件[3],是国家对原有功能预算的改革,旨在完善政府管理、基于预算管理主体结构的预算框架模式;绩效预算是使命驱动、结果定位的预算[4](NationalPerformanceReview,1993),本原是改变支出机构动机的预算编制模式。
美国各级政府一百年来预算管理经历了四种类型的改革:预算执行改革、预算编制改革、预算制度和程序改革与减少赤字改革;预算制度和程序改革的重要举措即是基于1921年《预算和会计法案》确定的联邦部门预算基本框架,改变了政府制定预算的治理结构,以便使预算权力逐渐平衡,这也是该基本机构框架能延续一个世纪的原因;绩效预算与项目-计划预算、零基预算等隶属于预算编制改革的范畴,它建立在基本预算纪律的基础上[5]。美国的预算改革实践提供了支持这一论据的经验证据,无论早期的分项预算、绩效预算、项目-计划预算抑或近期的零基预算与新绩效预算都未能撼动部门预算管理的基本框架,都是部门预算体系下的预算编制模式的变革。同时,自美国通过《预算和会计法案》并确定部门预算框架以来,各种预算编制改革并不存在历史时序之间的互斥性,例如20世纪50年代绩效预算所倡导的效益和效率基本分析思想却为计划-项目预算、零基预算和新绩效预算所采纳。
从目前美国联邦、州和地方政府的预算编制情况看,几种编制方法往往被同一机构混合在一起使用[6],可见部门预算在很大程度上充当了“相对静态”的预算管理框架角色,绩效预算则代表了“相对动态”的改善预算编制理念的努力,是部门预算框架内的预算编制管理理念调整的结果。Kelly(2003)对美国政府预算编制改革的评价也从侧面支持了这一关键差异,“绩效预算与早期的创新努力(其中包括项目-计划预算、目标管理以及零基预算)一样,都属于过程导向型,最终达到的效果只不过对传统预算修修补补而已”[1]。
第二,部门预算基础上汲取绩效管理理念的可行性。Key(1940)提出了公共预算领域的经典问题“在什么基础上,决定将一定数量的资金分配给A行为而不是B行为”[7],这显然是针对预算配置绩效的思索。回顾美国的预算改革实践,Key的论文发表时期正是分项预算的盛行时期,控制取向主导下的预算理念要求政府预算应该包括所有的收支项目,各项支出被明确归属到各个政府单位,每个项目所需资金按年来确定。追朔分项预算的起源,几乎是和《预算和会计法案》同时诞生的,自然可以将分项预算理解为传统部门预算框架基础上的最初预算编制理念。
Schick(1966)[8]介绍目标账户引入分项预算后的支出分类包含组织单元、功能和目标三类,这与我国财政部2007年实施的以收入分类、支出功能与经济分类为核心的政府收支分类改革存在异曲通工之处,也和马骏(2005)[9]基于预算时代视角提出的中国预算改革的重点应该是建立西方国家在19世纪时形成的现代公共预算体制的观点不谋而合。随后,无论是产出导向的早期绩效预算和远期目标下的计划-项目预算,还是着重优劣排序的零基预算与结果驱动的新绩效预算,都是试图将理性工具引入预算决策过程。管理取向下的产出效率关注、计划取向下的预算远期规划、优先性取向下的优劣排序以及责任性取向下的成果定位实质上也是广义绩效理念的不同表现形式,只不过是追求的重点不同而已。因此,美国的公共预算改革经验佐证了部门预算基础上汲取绩效理念的可行性。
预算管理角色差异性以及部门预算基础上汲取绩效管理理念的可行性决定了未来绩效预算改革是对部门预算的一种调整而非变革,同时也确立了部门预算对绩效预算的统驭性特征。远期绩效预算改革作为部门预算框架下的管理理念革新,理应实现二者的有机整合,在部门预算管理中逐步引入绩效理念。鉴于此,作为绩效预算的基础组成部分的预算绩效评价,必须立足于部门预算改革的客观现实,在部门预算的指导框架下以预算绩效为目标规划科学合理的绩效评价体系,旨在实现部门预算、绩效预算、预算绩效评价的整合,提升预算管理的综合绩效。简而言之,我们需要认识部门预算对绩效预算和预算绩效评价的统驭性与指导性,绩效预算和预算绩效评价对部门预算的调整性与针对性,从而为绩效预算与部门预算的互动改革指明方向。
三、绩效预算与预算绩效评价联系的有机契合
基于十六届三中全会建立预算绩效评价体系的近期工作部署和财政部关于绩效预算改革的远期战略规划,国内相关研究自然衍生为两个相互平行且交错的阶段:一类是研究预算绩效评价体系,旨在明确绩效理念、提高资金效益、夯实改革基础;另一类则是探索绩效预算改革,力图引进西方经验、剖析实施障碍、摸索实现框架。遗憾的是,对二者有机联系的忽略导致现有研究平行有余而交错不足。预算绩效评价研究明显缺乏对未来绩效预算改革可预见性的斟酌,使之易演变为公共事业部门绩效评价,导致评价目标与对象在部门预算与公共部门之间混淆;在突出绩效结果评价的同时又往往短视预算管理绩效的评价;不仅使得与部门预算特性结合松散的绩效评价效果大打折扣,也更无法适应绩效预算改革的切实需求。
面向绩效预算的预算绩效评价视角的提出有赖于重新审视我国政府对绩效预算渐近式改革的政策定位。为了贯彻落实十六届三中全会提出的改革预算编制制度,建立预算绩效评价体系等目标,深入探讨绩效预算改革,并在借鉴国际经验的基础上,尽快建立起中国特色的预算绩效评价体系,提高财政资金使用的有效性,财政部组织开展了绩效预算管理与改革国际研讨会(2004)[10],科学界定了绩效预算与预算绩效评价的逻辑关系:“建立绩效预算体系是为了进一步加强公共财政管理,提高财政资金的使用效益,其核心是通过制定公共支出的绩效目标,建立预算绩效评价体系,逐步实现对财政资金从目前注重资金投入的管理转向注重对支出效果的管理。”
财政部在财政预算报告解读(2005)[11]界定绩效评价为“运用一定的评价方法、量化指标及评价标准,对中央部门为实现其职能所确定的绩效目标的实现程度,及为实现这一目标所安排预算的执行结果所进行的综合性评价。”在中央部门预算编制指南(2006)[12]明确“以绩效考评为突破口,探索科学合理的预算绩效评价体系,在我国逐步培养关注产出的绩效预算文化,为将来推行绩效预算改革夯实基础。”最新的中央部门预算编制指南(2008)[13]鲜明指出绩效考评是加强部门预算管理的需要,归纳了预算支出管理中存在的问题,如在分配环节,预算执行偏离支出预算的现象仍然很大、科学性有待进一步提高;在执行环节,预算执行偏离支出预算的现象仍有发生,预算的严肃性有待提高;在监督环节,预算监督机制也不够健全,仍存在监督不到位现象,监督方式、方法有待改进。不难看出,政策方面聚焦于绩效预算改革的远期可预见性,预算绩效评价的近期基础性,预算绩效评价旨在满足部门预算管理需要、改变预算支出管理缺陷等关键问题。有鉴于此,我们能够从政策层面获知绩效预算与预算绩效评价有机联系的清晰证据。
绩效预算是以绩效目标为导向,凸现结果、责任、激励的一种预算管理模式,是涵盖绩效目标驱动、绩效过程管理、绩效结果激励的系统化多层次预算管理框架。预算绩效评价是以预算绩效为目标对预算单位绩效目标实现程度、预算执行结果的综合评价。预算绩效评价机制是绩效预算改革的充分必要条件,两者形成基础性与导向性的有机契合,同时也受统于部门预算的整体改革。基础性要求预算绩效评价适应部门预算推进的现实,提升评价体系的有效性和操作性,从而夯实绩效预算改革的基础;导向性要求预算绩效评价面向未来绩效预算改革的需求,拟合部门预算管理流程,培植从绩效结果披露的单一职能到绩效结果激励的复合职能过渡的潜在能力,从而适应绩效预算改革的趋势。
预算绩效评价有别于公共部门绩效评价,评价目标是预算绩效而非事业运行绩效,评价对象是部门预算而非公共部门。纠正理论界与实务界对预算绩效评价认识误区的关键是建立面向绩效预算的预算绩效评价视角:明确预算绩效评价对绩效预算的基础性与适应性,提升预算绩效评价与部门预算管理流程的契合度;以预算编制、预算执行、预算决算的预算管理流程为基础;形成“预算绩优度”为总目标,“预算配置绩效、执行绩效与产出绩效”为内核的绩效目标体系;组合计划评价、过程评价、结果评价的实施节点与规程;科学界定指标的内涵与筛选手段,集成指标之间的多重勾稽关系,构建评价指标体系;提供评价标准的实际测度途径与实现方法,设计恰当的评价模型;规划预算绩效评价结果激励、指导未来预算资金配置的策略。上述预算绩效评价体系的设计不仅凸现了绩效目标驱动下的绩效过程管理的逻辑结构思维,又蕴含了实现绩效预算改革的核心目标———结果激励的潜能,也吻合了推进绩效预算改革的远期导向;基于对预算配置、执行与产出绩效的综合评价,不仅落实了预算绩效评价的目标规划,也为未来绩效预算改革提供了良好的基础。
四、中央部门与基层单位试点的双向推进
传统的功能预算采取自上而下的编制方式,部门根据财政主管部门下达的按功能分类的预算控制指标,代替基层单位编制预算。部门预算改革后,中央各部门的预算从基层单位编起,逐级汇总,所有开支项目落实到具体的预算单位,预算层次进一步延伸,“二上二下”的预算编制程序避免了代编预算的随意性,编报内容也更加符合实际。以高校为例,教育部作为部门预算编制单位向财政部申请预算,各直属高校即是教育部的基层单位,基层单位预算汇总构成教育部部门预算的重要部分。基层单位预算绩效评价是中央部门对所属单位预算资金配置、执行与产出绩效的评价,旨在提高财政资金使用效益的绩效管理手段,也是推进管理重心下移机制、强化预算管理的重要内容。部门预算绩效评价是基层单位预算绩效评价结果的综合反映,基层单位预算绩效评价,为部门预算绩效考评提供基础。
《中央部门预算支出绩效考评管理办法(2005)》明确了绩效考评的职责分工:财政部负责制定统一的绩效考评规章制度,指导、监督、检察中央部门的绩效考评工作,中央部门负责组织实施本部门的绩效考评工作。即财政部不再直接负责组织实施,绩效考评工作的主体转移给了中央部门。原因在于财政部无法承担全部绩效考评的工作量,以及中央部门相对财政部更加了解本部门及下属单位的实际情况,为充分调动中央部门的积极性,把组织实施主体规定为中央部门。这意味着对基层单位预算绩效评价是一种政策趋势,但是近几年的预算改革进程却不尽如此。2003年以来财政部开始制定部分行业的绩效考评管理办法,组织部分中央部门开展预算支出绩效考评试点工作,取得了一定的成效。部分省市财政部门也以项目支出为切入点,开展了绩效考评的试点工作。
进一步审视中央部门预算绩效考评现状,我们发现:现阶段中央部门预算绩效评价工作的重心在于项目支出绩效评价,包括基本支出在内的部门整体预算绩效评价明显滞后,难以客观反映部门预算绩效的综合水平。仅有海洋局实施了以部门整体为考评对象的试点,这一试点的部署使得预算绩效评价与部门预算改革的深化呈现出一定层面的脱节。不仅如此,现阶段“将基本支出排除在绩效考评对象之外”(2)的选择,使得财政部提出的“统一领导,部门实施”的绩效考评实施原则在试点工作中并未呈现清晰的实现路径。与此同时,现阶段国家对基层单位预算绩效评价也并未引起重视,这不能不说是一个重要的缺漏。国家政策层面的乏力,或许源于现阶段预算改革局限于中央部门为对象的整体思路。中科院在长期自我实践的基础上,结合国家对部门预算绩效评价的要求,实施了对下属研究所的绩效评价;海洋局也涉足了对下属二级单位绩效评价方案的设计与实践。这为基层单位预算绩效评价作了初始的尝试。
部门预算改革的深入,必须以基层单位预算改革为基础,部门预算绩效评价的实施必须兼顾基层单位预算绩效评价的推进,预算绩效评价要真正成为部门预算、绩效预算改革的基础,在以项目预算绩效评价试点为先导的同时还必须高度重视以部门、单位为整体的预算绩效评价机制的建立。依此,本文提出中央部门与基层单位双向推进的预算绩效评价实现路径:以中央部门、基层单位整体为对象(包括基本支出与项目支出),结合国家对绩效预算的远期目标,构建面向绩效预算的预算绩效评价体系。财政部代表国家作为中央部门预算绩效考评的主体,中央部门实施对所属基层单位的预算绩效考评。
综上所述,通过对部门预算、绩效预算与预算绩效评价关系的清晰界定,我们领悟到部门预算是我国预算改革的重大战役,近期容纳预算绩效评价机制,远期延展基于结果导向的绩效预算的资源配置理念。本文提炼了部门预算与绩效预算之间的统驭性与调整性、部门预算与预算绩效评价之间的指导性与针对性、绩效预算与预算绩效评价之间的导向型与基础性,提出了中央部门与基层单位试点双向推进的优化思路,构建了科学的面向绩效预算的预算绩效评价互动效应的实现框架。在预算改革的各个时期,必须契合部门预算与绩效预算、预算绩效评价与预算绩效、预算绩效评价与部门预算,明晰现实任务,展望远期目标。当然,理论层面的实现框架有赖于现实研究的支撑,面向绩效预算的基层单位预算绩效评价指标设计、评价模型规划等问题将是我们下一步的研究重点。
注释:
(1)美国的预算编制模式历经分项预算、早期绩效预
算、计划—项目预算、零基预算与新绩效预算五个发展阶段,对应五种占据相对主导地位的预算功能取向,也是广义绩效理念引入预算管理的实践过程。
(2)财政部预算司.《中央部门预算编制指南
摘要：在现阶段不具备实施绩效预算条件、又要全力推进预算绩效评价的政策导向下,结合国家宏观政策、理论研究、实践试点的现状,把握部门预算、绩效预算、预算绩效评价的有机契合,凝炼部门预算与绩效预算之间的统驭性与调整性、部门预算与预算绩效评价之间的指导性与针对性、绩效预算与预算绩效评价之间的导向性与基础性,提出中央部门与基层单位双向推进的优化思路,形成理性的面向绩效预算的预算绩效评价实现框架。
关键词：部门预算,绩效预算,预算绩效评价
面向框架 篇2
1 航空物流与物流信息系统
1.1 航空物流
所谓航空物流, 就是用航空工具实现物流操作。相比海运物流和公路物流, 优势是速度快, 货物安全系数高, 劣势是价格贵, 很多物品限制运输。
有报告指出, 中国航空运输市场以每年7.6%的速度增长, 成为仅次于美国的世界第二大民用航空市场。中国民航重组后的几大航空集团也逐渐加大货运业务的投入, 组建专业的航空货运公司, 将航空货运作为其新的经济增长点。
1.2 航空物流的业务流程
业务流程是指货物运输过程中货物流、信息流和实施控制管理的全过程。
简单来看, 航空物流公司根据自己业务的实际情况在中心地区设立分拨中心, 各地收集起来的快件按所到地区分拨完毕, 装上飞机。各地飞机飞到分拨中心, 各自交换快件后飞回。各地分公司再将快件用地面运输送到收件人手上。中心分拨理论减少了中间环节, 快件的流向简单清楚, 减少了错误, 提高了操作效率, 缩短了运送时间, 事实证明是经济、有效的。
进一步详细分析, 无论是国际的国内的航空货物运输, 主要包括以下几个步骤:
(1) 货主发货。快递企业从各分点收取航空快件, 运转到总运转中心。
(2) 货物分拣。在总运转中心对货物分拣, 确定对应机场发货总量同外包装件数。
(3) 货代公司收货。航空货运代理接受托运人委托运输, 审核单证, 接收货物, 并根据快递企业要求向航空公司预订舱位。若是进出口货物, 还要进行报关。
(4) 航空公司批舱。航空公司根据实际情况安排航班和舱位, 订舱后, 航空公司签发舱位确认书 (舱单) , 同时给予装货集装器领取凭证, 以表示舱位定妥。
(5) 机场安检。航空货运代理在对应航班起飞前3小时交机场主单, 对应起飞前2小时过完安检, 并将货物到达机场资料给快递企业。
(6) 分发派送。快递企业在飞机落地后2~3小时提取货物, 完成分检后运到各派送点安排派送。
可以看出, 一次航空货物运输至少涉及货主、快递公司、航空货运代理、航空公司、机场等, 与各方的协作和信息共享是确保货物运输准确无误的关键。如果是进出口货物, 航空货运代理还要去海关查验, 并与海关信息系统交换数据。
1.3 航空物流信息系统
现代物流的发展要求航空物流企业必须具备以下几种能力:能建立并管理全球性的航空运输网络, 深入覆盖所有主要城市;能对最终用户从单个或多个仓库取货送货路线进行重新设计, 减少地面运输造成的延迟, 充分体现航空物流的快速;能提供定制化的服务, 包括跟踪信息服务, 保证在途货物信息透明化 (特别是国际货物运输) ;能与机场离港系统、订座系统实时信息交互, 合理配载, 顺利订舱;具备相应的组织和流程灵活性, 能够灵活处理各种突发问题;能提供客户增值服务等。
因此, 一个先进的物流信息系统应该包括以下几部分:
(1) 客户管理系统。通过收集客户需求信息、记录客户购买信息、进行销售分析和预测、管理销售价格、处理应收货款及退款等, 实现对客户资料的全方位、多层次的管理, 使各个环节实现流通机能的整合。
(2) 仓库管理系统。在与客户管理系统共享部分信息的基础上, 实现存储管理、进出货管理、机械设备管理、分拣处理、流通加工、出货配送管理、货物追踪管理、运输调度计划、分配计划等内容信息的处理。在货物管理方面, 目前已采用的自动化技术有POS、条码、GPS、GIS、RF射频技术等。
(3) 分析决策系统。通过建立各类物流运筹分析模型实现对物流业务的互动分析, 实现与合作伙伴的协同资源规划。
而在航空货运企业现有的管理信息系统中, “信息孤岛”的问题比较严重, 系统功能不易扩展, 平台移植性差, 需要引入一种全新的软件系统架构, 整合现有资源, 顺畅衔接协作平台, 使资源浪费降到最低。面向服务的SOA技术和WCF技术正具有复用度高、扩展性好的特点, 并较好地解决了异构系统间跨平台访问与操作问题, 使得航空货运企业能快速实现向现代物流管理模式的转换。
2 物流信息系统的关键技术
为满足客户需求的多样化, 随着软件技术的不断更新, 物流信息系统逐渐从紧耦合、封闭式系统向松耦合、开放式, 面向供应链管理的方向发展。面向服务的软件体系结构和技术可以独立于开发环境和运行平台, 轻松实现新旧系统的对接。
2.1 面向服务SOA
所谓服务就是精确定义、封装完善、独立于其他服务所处环境和状态的函数。服务间需要某些方法进行连接。服务间存在协作关系, 可能是简单的数据传送, 也可能是两个或更多的服务协调进行某些活动。
SOA本质是服务的集合, 软件开发就像是搭积木一样将各个服务组件结合在一起。在SOA架构中, 涉及服务消费者、服务代理者和服务提供者三个角色。
(1) 服务提供者, 定义服务生成接口文件, 将服务发布到一个或者多个服务代理处, 并接收来自一个或者多个服务请求者的服务调用信息。
(2) 服务请求者, 通过服务代理者查询服务地址和服务接口, 并利用服务描述绑定或者调用服务提供者提供的服务。
(3) 服务代理者, 完成服务提供者和服务请求者之间的匹配。
由于服务代理的存在, 使得服务请求者与服务提供者之间没有直接依赖, 服务地址的变更或增加新服务组件, 不会影响到服务请求者。
2.2 WCF
WCF是基于.NET平台的分布式编程框架, 继承了面向服务的体系结构, 通过客户端与服务器之间匹配的消息访问点通信机制实现异构系统间的分布协同。
消息访问点 (Endpoints) 的内容包含了地址 (Address) 、绑定 (Binding) 、契约 (Contract) 和行为 (Behavior) 。地址指定服务位于何处, 绑定说明服务所能理解的通信协议, 契约说明服务接口函数及数据交换格式。行为主要用于定制消息访问点在运行时的一些必要的行为。
在WCF发布之前, 微软支持6种主要的分布式技术:RPC、WSE、ASMX、Remoting、COM+和MSMQ。不同的技术有不同的API、编程方式、操作要求和配置需求, 应用系统代码紧密依赖于这些技术。当有新需求时, 或应用系统与其他非.NET平台应用系统通信时, 只能放弃需求或者重新编写通信程序。WCF集成旧技术特性并统一为一个编程模型, 提供比以前更多的连接特性。
3 基于SOA与WCF的航空物流信息系统架构
在航空物流信息系统的改造中, 关键在于对快递公司、机场仓储系统、离港系统、航空公司订座系统的货物信息进行集成。SOA和WCF技术的应用, 能保留物流相关企业原有的系统模式, 将需要交互的功能模块封装成新的服务组件, 并搭建一个公共信息交换平台, 解决相关企业信息系统的互连互通问题。
基于企业原有信息系统之上, 公共信息交换平台系统由上至下依此如下:
(1) 应用层。提供一个公共信息平台, 供各类客户查询信息和显示查询结果, 具体的查询过程对客户透明。
(2) 服务层。WCF实现对业务逻辑层不同粒度的封装与抽象, 并保存WCF服务地址与接口的匹配信息, 供应用层服务请求者查询。
(3) 业务层。也可称为业务逻辑层, 此层对服务进行定义, 可以是服务的具体实现, 也可以是对其他WCF服务的调用封装。
(4) 数据层。包括物流各相关企业的各个应用数据库, 根据企业间的合作协议, 制定专用的访问接口共享消息。
以上体系结构的优点, 一是对于服务层的各个服务, 可以根据业务需要进行服务粒度的划分, 增加和删除服务不影响业务逻辑层和应用层的程序代码, 只要修改相关接口文件;二是软件重用性好, 业务逻辑中的各组件可以是新开发的, 也可以是已有的, 按照新的业务逻辑重新封装即可得到一个新的服务;三是可以采用ASP Net技术实现基于Web的公共信息平台, 用户按照授予的权限访问企业数据, 感觉不到是跨系统或跨平台操作。
4 结语
顺应物流经济的发展, 航空物流企业在向现代物流管理模式转换的过程中, 由于各相关企业的信息系统无法实现互联互通, 极大地限制了业务能力的拓展, 企业间协作性较差, 大大降低了航空物流的工作效率。本文在分析航空物流的业务特点、物流信息系统的发展方向后, 认为将一种新的软件体系结构SOA和面向服务的WCF技术应用到现代物流信息系统中是可行的, 提出了一种基于SOA和WCF的物流系统架构模型, 并对该架构的各层功能做了定义。这种基于SOA的软件体系, 可极大地提高企业旧系统的利用率, 缩短新系统的开发周期, 增强合作企业间的协作能力, 提高本企业的工作效率, 降低企业的运营成本。
参考文献
[1]曹亚克.第三方物流与第四方物流发展的比较分析[J].中国流通经济, 2009 (10) .
[2]占慧杰, 舒奋.发展第四方物流, 推进我市物流现代化[J].经济丛刊, 2009 (5) .
[3]丁蓉蓉.传统储运企业向第三方物流转型研究[D].南京:南京理工大学, 2008.
[4]王微怡, 崔巍, 谢柳艳.SOA架构在物流信息系统开发中的适用性研究[J].物流技术, 2010 (3) .
[5]李颂华, 陶丽红, 高栋.基于SOA架构的物流信息系统的相关技术研究[J].北京科技大学学报, 2009, 31 (1) .
[6]冯玖, 白尚旺, 党伟超.基于SOA的物流信息系统架构研究[J].计算机与数字工程, 2009, 37 (1) .
面向范畴类型数据的双聚类框架 篇3
范畴类数据是指能以布尔矩阵的形式表示的数据：行代表数据对象，列代表布尔属性，即把对象属性以属性值对的形式记录。如表1中的布尔集合r，数据对象t2具有属性g2和g5。目前有许多数据挖掘技术都支持从范畴类数据中进行知识发现。作为主要的数据挖掘方法，聚类已经被深入研究多年，其中也包括针对范畴类或布尔数据的研究。它的主要目标是识别数据对象和/或属性的划分，使目标质量函数最优化[1]。有赖于局部搜索的优化，许多有效的聚类算法都可以给出很好的划分，然而始终缺乏对簇特征的确切描述。这促进了对概念聚类[2]和双聚类的研究[3,4,5]。双聚类的目标是计算属性集合和数据对象集合的联系(包括可能的重叠)。例如关于r的一个有趣的双划分是{{{t1,t3,t4},{g1,g3,g4}},{{t2,t5,t6,t7},{g2,g5}}}。第一个双划分表明{t1,t3,t4}几乎总是拥有相同的属性值{g1,g3,g4}。目前的主要问题是,大多数双聚类算法只能计算无重叠的双划分，而在许多应用领域，数据对象和属性属于多个簇的情况很常见，这引发了对重叠双聚类的研究。形式概念分析[6]可能是一种解决方法。通俗地说，一个形式概念是一个双集合(T,G)，对象T的集合和属性G的集合形成了一个实值最大(组合)矩形，例如r中的({t1,t3},{g1,g3,g4})。然而，形式概念群集常常异常庞大，使最终用户很难理解其意义。在这个例子中我们发现，{{t1,t3,t4},{g1,g3,g4}}不是一个形式化概念((t4,g1)┌∈r)，但是却可以由“足够相似”的形式概念{{t1,t3},{g1,g3,g4}}和{{t1,t3,t4},{g3,g4}}来建立，这便是我们的出发点。
本文在两个方面给出新的见解。第一，我们提出了一个新的双聚类框架，把反映数据对象和属性间强关联的局部模式进行分组，建立满足用户定义约束下的双集合。分组的对象可以是各种不同的局部模式，例如和数据对象相关联的频繁属性集合，形式概念等。第二，我们给出一个该框架下的算法BK-MEANS，同步建立数据对象和属性的相关划分。实验肯定了该算法相比其他双聚类算法的优点。
2 聚类模型
假定一个对象集合O={t1,…tm}和一个布尔属性集合P={g1,…gm}。要挖掘的内容是r哿O×P，如果对象ti具有属性gj，则rij=1。双聚类任务定义如下：计算数据对象的K簇划分(即{C1O…CkO})及属性的K簇划分(即{C1P…CkP})，两个划分之间的映射满足以下关系：一个对象簇由一个属性簇特征区分。严格的说，一个双集合是一个元素bj=(Tj,Gj)(Tj奂O,Gj奂P)，假设已经事先从r中将感兴趣的双集合都提取出来，用B表示。bj用布尔向量描述为：
双集合和质心的距离定义为：
为集合组件的加权对称差的均值。我们假设和，这里如果tjk·τik≠0则ak=1，否则为0。本质上，交集是公用对象的数量及其质心权和的均值;合集是对象数量及其质心权和的均值。在属性方面也具有相似定义。对象tj(对应属性gj)被分配倒K簇中的一簇(用i表示)，使得τij(对应γij)最大化。我们可以通过控制每个簇的重叠大小，使一些对象和/或属性属于多个簇。由于簇成员由τi和γi的值决定，我们只需要改写簇分配步骤。因此，引入位于区间[0,1]的参数δ0和δP，用来量化簇中每个元素的隶属度。如果τij≥(1-δ0)·maxi(τij)，则对象tj属于簇CiO，如果γij≥(1-δP)·maxi(γij)，则属性gi属于簇CiP。显然，重叠对象(属性)的数量由值τi和γi的分布决定。请注意，δ=0并不意味着一个对象或簇只能分配给一个簇。相关值δ的选择很显然应当由实际应用决定。
3 伸缩性问题
形式概念的群集常常很大，特别是对于本质上噪声大的数据。由于算法和双集合的数量呈线性复杂度，它可能很耗费时间。直观的解决方法是对形式概念做出选择，例如仅选择包括足够数据对象和/或属性的形式概念。我们用σO表示对象集合的最小规模，σP表示属性集合的最小规模。如果属性的相关数据对象数量小于σO，则这些属性(及其对应数据对象)就不算在任何形式概念中。由于接下来的双划分方法是基于提取出来的模式，因此这些对象和/或属性就不会出现在最终的双划分中。如果想要找到一个包括所有数据对象和属性的双划分，则可以通过增加形式概念的上下界(O,准)和(准,P)来解决。
4 结论和进一步工作
我们介绍了一种新的双聚类框架，在计算双聚类(包括重叠的情况)时对数据的局部模式进行扫描。实验证明“从局部模式到相关全局模式”的方法是可行的。该框架下的许多其他应用还有待进一步的研究。如在提取出局部模式以后，应用其他聚类技术;采用其他局部模式;以及更多基于约束的聚类。
摘要：双聚类是一种理想的概念聚类方法。对范畴类数据而言,双聚类可以给出相关联的数据对象和属性值的簇集(包括重叠的情况)。该文提出了一种通用的双聚类框架,由局部模式群集计算双划分。该局部模式反映了数据对象和属性之间的强关联。
关键词：双聚类,形式概念,范畴类型数据,局部模式,聚类
参考文献
[1]Jain A,Dubes R.Algorithms for clustering data[M].Englewood cliffs,New Jersey:Prentice Hall,1988.
[2]Fisher D H.Knowledge acquisition via incremental conceptual clustering[M].Machine Learning2,1987:139-172.
[3]Robardet C,Feschet F.Efficient local search in conceptual clustering[C]//Proceedings DS’01.Number2226in LNCS,Springer-Verlag,2001:323-335.
[4]Dhillon I S,Mallela S,Modha D S.Information-theoretic co-clustering[C]//Proceedings ACM SIGKDD2003,Washington,USA,ACM Press,2003:89-98.
[5]Madeira S C,Oliveira A L.Biclustering algorithms for biological data analysis:A survey[C].IEEE/ACM Trans Comput Biol Bioinf.1,2004:24-45.
面向框架 篇4
1 云计算概述
1.1 云计算概念
云是由一系列相互联系并且虚拟化的计算机组成的并行和分布式系统模式,这些虚拟化的计算机动态地提供一种或多种统一化的计算和存储资源,这些资源通过服务提供者和服务消费者之间的协商来流通,基于这样云的计算称为云计算。简单地说,云计算即指基于互联网络的超级计算模式,即把存储于个人电脑、服务器和其他设备上的大量存储器容量和处理器资源集中在一起,统一管理并且协同工作。
1.2 基于服务的架构
面向服务的体系结构(Service-Oriented Architecture,SOA)是一个组件模型,它将应用程序的不同功能单元(称为服务)通过这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的,它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样系统中的服务可以一种统一和通用的方式进行交互。
SOA设计原则,SOA也是一门方法论,类似于面向对象的设计,它也有自己的一些原则,SOA的服务设计原则有:规范化的服务契约,松散耦合性,服务抽象性,服务重用性,服务自治性。这些原则是不可或缺的,自治性、松散耦合、抽象以及规范化的契约视为形成SOA根本基础的核心原则。
云计算的各部分与企业数据中心的各部分一样,同样包括诸多编程语言、操作系统、数据库、Web服务器、协议和应用编程接口(API)。关键就是确认哪些云服务真正适合自己内部的系统、应用程序和专长技能。而云计算得以推广的根本是必须确保云服务与本企业的基础架构相互集成。这就需要一种易扩展、二次开发费用低的基础架构能够结合两者,而SOA架构刚好弥补了云计算在这些方面的缺点,可以将二者有机的结合起来,从而形成一种更有竞争力的框架模型。
2 基于服务的云计算框架模型设计
基于服务的云计算结构可以分为四层:云计算服务应用层、云计算服务调度层、云计算服务虚拟机层和云计算服务物理层。云计算服务应用层是云计算和终端用户的接口层,云计算服务实现的最终目的是通过云计算服务应用层给用户提供其所需的云计算服务,云计算服务物理层是云计算服务结构模型的最底层,是云计算结构的核心层,是给上层提供云计算服务的基础设施层。本文考虑到(QoS需求,基于SOA的云计算框架模型主要包括云用户、云供应商、云服务市场三种角色,如图1所示,且模型中引入了QoS管理机制。
(1)云计算服务应用层
云计算服务应用层的作用是为终端用户消费云计算服务提供统一规范的接口。终端用户通过专用入口通道进入云计算服务中心,订制和消费其所需的服务。
通过云计算服务应用层,终端用户可以在不投入大量资金来改善本地机器性能的情况下,进行远远超过其机器性能上限的高强度计算和大存储容量的工作。
(2)云计算服务调度层
云计算服务调度层是云计算服务请求和响应层。云计算服务调度层也可称为云计算服务决策层,其作用是检测和响应云计算服务应用层提交过来的云计算服务消费请求。
云计算服务调度层一个最重要的特征是实时更新可用资源库,以便不会错误地处理终端用户的云计算服务请求。当接收到云计算服务应用层提交过来的云计算服务消费请求时,云计算服务调度层先检测此请求是否合法,如果不合法,则直接拒绝此请求;如果合法,则再在其资源库中查询是否还有满足此QoS请求所要消费的资源,若不满足,则继续拒绝此请求;若满足,但已分配完毕,则仍拒绝此请求;如还有此资源,则将此请求转交到云计算服务虚拟机层。
(3)云计算服务虚拟机层
该层管理实例和核心实体(VMs、主机、数据中心和应用程序)的执行,这一层能够同时执行和透明的管理数以千计的大规模云基础设施,为基于用户需求、管理应用程序执行和动态监测的主机提供虚拟机也在这层被处理。该层中也定义了关于主机如何在云中分配不同的竞争虚拟机有清晰的界限。
(4)云计算服务物理层
云计算服务物理层是云计算服务的基础设施层,是云计算服务结构的骨干层。其作用是为上层提供可供终端用户消费的云计算资源。云计算服务物理层提供的基本云计算资源包括:CPU资源,数据存储器资源,宽带等资源。该层可以同时共享大量的能够满足用户定义服务质量的应用程序虚拟机。
云用户:云用户向云服务市场提出自己的要求,包括所需完成任务的描述、服务质量要求QoS。用户应用的QoS参数包括时间、成本、可靠性和信任系数等。
云服务市场:云服务市场提供云环境中云用户和云供应商的交易场所,是进行资源管理和交易的基础设施。云服务市场可以联接不同的云,具有服务信息目录、服务发现、服务管理、注册、撤销、订阅、服务交易等管理功能。
云供应商:云供应商可以集成各种资源提供特定的服务,也可以是一个具体的资源。云供应商将资源包装为服务,通过注册,进入云服务市场,退出时从市场撤消注册。
3 面向服务的云计算框架模型的实现
基于以上分析,本文提出了一种面向服务的云计算框架模型的实现模式。
云用户1首先向云服务市场提交服务请求,服务市场在自己的服务范围内查找是否存在该项服务,如果不存在,直接拒绝此项服务申请;如果存在,则需要通过QoS模块,进一步检查是否满足用户QoS需求,若不满足,则继续拒绝此项服务,若满足,则回复消息通知云用户1具体的访问位置。云用户1访问该位置上的服务接口程序,并通过接口调用云服务调度层。云服务调度层接到调用后,查找云资源服务器中的虚拟机,根据用户1提出的资源请求,分配其具体的服务器资源,从而用户1可以使用该云中的服务器资源。云用户2、云用户3……云用户n的服务过程类似。
模型中引人QoS模块在模型中实现管理QoS管理机制。云市场要实现资源监测、存储、网络、虚拟机、服务迁移和容错性等功能,必然面临QoS问题。服务质量QoS提供了服务性能保证、可用性保证,以及安全性、可靠性等其他方面的服务质量。通过查询QoS模块,实现了资源的最优分配,保证了云服务质量,满足了用户的需求。
结语
云计算提供了一种基于互联网的全新计算模式,受到学术界高度关注。目前云计算框架模型的设计与实现处于起步的阶段,而面向服务的云计算框架模型能使用户从云市场获取所需服务,通过QoS约束保证云服务质量,实现了资源的优化调度,充分体现了云计算与面向服务架构的优势,以此,为将来的企业化应用奠定基础。
摘要：云计算是一种在大范围共享资源的新型服务计算模式,目前我国时云计算框架模型的设计与实现还处于探索阶段。本文通过介绍云计算的概念,提出了面向服务架构的云计算框架模型的设计和实现办法,为云计算框架模型的设计与实现提供了一个可行的探索方向。
关键词：云计算,云用户,SOA,应用层,设计,实现
参考文献
[1]李刚健.基于SOA的云计算架构模式新探[J].吉林建筑工程学院学报,2011(02).
面向框架 篇5
悬索桥是大跨度桥梁中最自然、美观和经济的桥型,其跨越能力在所有桥梁结构形式中最强,以长江为例,已建和在建的悬索桥超过20座,构成了跨江发展的重要通道,如何有效监测悬索桥自身结构安全和交通运行安全已成为桥梁安全管理中研究的热点。目前,国内外桥梁监测研究主要集中在桥梁在线结构健康监测[1,2]、桥梁主缆(拉索、钢桥塔或钢箱梁)干燥状态监测[3,4,5,6]、桥梁照明电力监测[7]等系统方面,并取得了一定成果。除了上述对桥梁自身健康状态进行直接监测外,针对桥面交通安全的交通运行监测、环境监测也显得尤为重要。一方面,交通流、交通事件、能见度、桥面湿滑状态等与交通运行和环境有关的数据可有效用于桥面交通安全管理与服务,另一方面,交通量、车辆载荷等信息可用于分析桥梁实时承载状况以及预测桥梁结构安全发展态势,并为桥梁安全预警提供数据源。然而,传统的桥梁监测各子系统往往是孤立存在的,各子系统之间的信息不能互联互通,不利于实现桥梁安全综合监测与集中管控。鉴于此,本文以悬索桥为研究对象,拟提出一种桥梁综合监测系统的体系框架设计思路,以期为提升桥梁安全综合管理与信息服务水平指明新方向。
1 系统框架
悬索桥综合监测系统包括1个平台、5大子系统,即综合信息平台、结构健康监测子系统、主缆除湿监测子系统、供电设施电力监测子系统、交通运行监测子系统、外界环境监测子系统,见图1。结构健康监测子系统和主缆除湿监测子系统主要用于桥梁自身安全管理,交通运行监测子系统和外界环境监测子系统主要用于桥面交通安全管理,供电设施电力监测子系统主要用于供电安全管理。各子系统在功能上相互独立,但是彼此之间相互关联,供电设施电力监测子系统保障其他各子系统正常运行,桥梁自身安全状态监测是承载交通运行的前提,交通运行监测子系统收集到的交通数据(如交通量、车辆载荷等)则有助于分析桥梁自身安全风险,外界环境监测子系统获取的数据(如温度、湿度、能见度等)对桥面交通运行安全和桥梁健康状态均产生显著影响。各子系统之间通过综合信息平台实现数据整合与共享,平台还可提供安全管理辅助决策支持和对外信息服务。综合信息平台是核心组成部分,其框架见图2。
2 系统功能
2.1 子系统功能
1) 结构健康监测子系统功能。
该子系统以悬索桥中塔为重点,兼顾主梁和主缆,采用GPS、加速度计、应变计、温湿度计、风速风向仪等5大类传感器对大桥结构安全进行全面监测,并提供完善的数据分析、结构损伤辨识与预警、疲劳与寿命评估报表等功能。
2) 主缆除湿监测子系统功能。
主缆是悬索桥的“生命线”,为防止主缆受潮腐蚀,需构建悬索大桥主缆除湿监测子系统。以泰州长江大桥为例,共设置了3套送气机组、48个进排气罩、146个传感器(含压力、温湿度、流量传感器),该子系统可远程监测主缆的除湿进度和状态,并对机组状态进行调节控制,保障主缆始终处于相对干燥的环境之中。
3) 交通运行监测子系统功能。
该子系统通过摄像机、微波检测器、计重设备(位于收费车道入口)监测桥面交通运行情况,能够实时统计桥面交通量、平均车速、占有率、车型及载荷等信息,并及时侦测桥面交通事件,为桥梁交通安全管理提供数据支持。该子系统中的桥面交通量、车辆载荷信息还可用于预测桥梁自身安全发展态势,当实时采集的交通量、车辆载荷达到一定阈值时,通过预设的数学模型判别桥梁安全风险,并优化控制交通流。
4) 外界环境监测子系统功能。
该子系统通过气象检测仪实时获取大气温湿度、风向、风速、能见度、桥面结冰等信息,一方面为桥梁健康状态监测提供数据支持,另一方面也为雨、雾、雪天气下的桥面车速控制、交通限行等措施提供科学依据。
5) 供电设施电力监测子系统功能。
该子系统通过采集大桥各配电房(监控子站)内监控设备电力参数数据,以图形方式实时显示各监控子站的工作状态。通过分析、处理电力参数数据后可制定相应的电力控制方案,并向配电房内各监控设备发送数据信息或控制命令,实现对各监控子站的遥测、遥信、遥控等功能,以保证沿线各变电所供配电系统安全。
2.2 综合信息平台功能
1) 综合信息采集。
平台用于接入各子系统获取的实时、历史数据,使分散在各子系统的数据集成化,并形成桥梁结构安全与交通运行的综合信息数据库,实现各子系统之间的数据共享与协同工作。
2) 辅助决策支持。
通过挖掘与融合各子系统提供的海量丰富信息,实现对桥梁安全状态的在线诊断与发展态势预测,构建桥梁安全状态与结构参数、交通参数、环境参数之间的关联关系,为桥梁安全设计、运维管理、交通管控等提供辅助决策支持。
3) 交通信息服务。
通过交通广播、互联网、可变情报板发布桥面施工、交通事件、动态限速值、能见度、桥面湿滑状态等信息,提醒交通出行者注意交通安全,减少二次事故发生概率。
3 关键技术
悬索桥综合监测系统以安全为导向,旨在提高数据利用效率,实现各子系统的数据共享与集中管控。其涉及到的主要关键技术如下:
1) 数据集成技术。
桥梁综合监测系统的数据来源广泛,综合信息平台需对各子系统采集的数据进行整合利用,而各子系统之间的数据存在异构性,因此,应制定一致的数据格式与交换标准才能保证各类数据的高效集成。在本系统实施过程中,需重点解决基于XML的数据转换中间件技术,实现异构数据的交互与共享。
2) 数据挖掘与融合技术。
在桥梁综合监测系统数据仓库内含有大量的、不完全的、有噪声的、模糊的随机数据,应重点研究人工神经网络、遗传算法、粗糙集、模糊理论等方法,从上述数据中抽取隐含的有用知识,并利用这些知识对安全管理提供决策支持。在对桥梁安全发展态势进行评估以及发布综合交通信息时,需利用贝叶斯估计、卡尔曼滤波、证据推理、时间序列分析、神经网络等数据融合技术提高桥梁安全在线分析与预测精度。
4 结束语
针对当前桥梁监测中各子系统分散的现状,以大跨径悬索桥为切入点,提出了一种面向安全管理的桥梁综合监测系统体系框架,旨在充分整合、利用桥梁监测各子系统的信息资源,通过统一的信息平台提供安全管理辅助决策支持和对外交通信息服务。桥梁信息化管理的最终目标不只局限于对某一座或某一类桥梁的各子系统信息进行整合利用,面对长江上广泛分布的桥梁,未来研究的重点将是构建区域桥梁综合监测系统,实现更充分、更有效的信息综合利用。
参考文献
[1]Chae M J.Development of a wireless sensor net-work system for suspension bridge health monito-ring[J].Automation in Construction,2012(21):237-252.
[2]李杰,黄民水.脉动试验和有限元分析在桥梁结构健康监测中的应用[J].交通信息与安全,2009,27(2):143-145.
[3]Jia D Y.Design method of air drying dehumidifica-tion system for main cables of suspension bridge[C]∥Shenzhen:IITA International Conference on En-ergy and Environment,2011.
[4]叶觉明,欧阳恺.悬索桥主缆除湿防腐技术应用和探讨[J].腐蚀与防护,2004,25(12):529-531.
[5]庞维新.除湿系统在钢箱梁维护中的作用[J].公路交通科技:应用技术版,2011(8):98-101.
[6]朱能,田喆,刘斌.跨海大桥除湿系统研究[J].天津大学学报,2004,37(8):728-732.
面向框架 篇6
随着现代软件工程的不断发展, 人们对软件质量和生产力的要求越来越高。软件测试技术和框架复用技术作为提高软件质量和生产力的有效手段, 近年来倍受人们的重视。
传统的“黑盒”、“白盒”测试技术主要应用于面向过程的程序设计中。随着面向对象技术的发展, 这种技术已不能满足软件测试的需要。自动化单元测试框架应用于面向对象单元测试中, 通过它来实现单元测试自动化。
单元测试是对软件进行正确性检验的测试工作, 是软件设计的最小单位。单元测试的目的主要是发现每个程序模块内部可能存在的错误。程序员的基本职责是单元测试, 单元测试能力是程序员基本能力的体现, 程序员必须对自己所编写的代码认真负责, 软件的质量与程序员的工作效率直接受程序员单元测试能力高低的影响。
单元测试是一项很重要而且必要的工作。在实际工作中, 许多程序员并不愿意对自己编写的代码进行测试。软件开发的工作压力大, 大多数程序员们因为没有时间测试自己的代码, 使程序的代码质量得不到保证, 有些代码还需重新编写, 程序员根本没有时间对代码进行测试。自动化单元测试框架能够从根本上解决这个问题, 它可以使测试工作变得简单, 这样更有助于程序员进行代码开发工作。
1 自动化单元测试框架设计目标
自动化单元测试框架的设计应达到以下目标:首先, 框架简单, 可以使测试程序的编写更简化。框架使用常见的工具设计, 测试工作操作简单;其次, 测试框架应能够使除作者以外的其他程序员进行代码测试, 并能解释其结果, 即将不同程序员的测试结合起来, 且不发生相互冲突。最后, 测试用例可以复用, 可以以现有的测试为起点形成新的测试。
本文将以这些目标为指导, 讨论如何用以Kent Beck和Ralph Johnson提出的“模式产生体系结构”的方式来设计框架系统。自动化单元测试框架的设计思想是从0开始根据设计问题应用设计模式, 一个接一个逐步设计, 直至获得最终合适的系统架构。其中实现部分采用Java语言来实现, 并会使用UML图来表示各种类及类间关系。
2 面向对象自动化单元测试分析
自动化测试定义为:管理与实施各种测试活动, 包括开发测试脚本、执行测试脚本, 这样使验证测试需求更加方便, 通过这些脚本实现了自动测试, 可以把它称为自动测量工具。使用这种自动测试工具对增量软件集成测试提供了巨大的方便, 增加了巨大的价值。每一个新的构件可以重用先前开发的测试脚本, 即使需求和软件有变更, 作为一个重要的控制机制, 自动测试也能够确保每一次重新构建的稳定性与准确性。
3 面向对象自动化单元测试框架
自动化测试框架实质是一种自动测试工具, 单元测试的核心问题是实现测试自动化。一个完整的自动化测试过程通常包括5个测试活动, 分别是测试标识、测试设计、测试实现、测试执行与评估。测试用例针对被测试系统的各项功能准确地开发与设计, 而且每一个测试用例都要按顺序执行这5个测试开发活动, 测试开发活动如图1所示。
测试标识与测试设计这两个测试活动主要为智力活动, 分别标识测试条件和设计测试用例。测试执行与测试比较这两个活动属于比较机械的活动, 它们的功能分别为:执行测试用例、将测试输出结果并与期望输出结果值相比较。前两个活动决定了测试用例的质量, 后两个活动适合自动化。在单元测试中, 测试执行和测试比较这两个活动要重复多次, 测试标识与测试设计通常只执行一次。因此, 在单元测试过程中, 重复性的活动特别需要自动化执行。
4 自动化单元测试设计与实现
首先构建对象来表达基本概念:Test Case (测试用例) , 然后将对象发送到测试框架, 再由测试框架执行, 最后报告测试结果。
采用Command命令模式将一个请求封装成一个对象, Command模式可以为每一个操作生成一个与之对应的对象, 同时能够给出一个对应的执行方法。这样可以对多个用户请求进行排队, 也可以将多个请求记录到日志, 并使用不同的请求对客户进行参数化。具体实现方法如下:
其中的run () 方法为模式中的执行方法, 可以通过继承来重用该类, 为了便于在测试失败时能够识别出失败的测试, 每一个Test Case在创建时都要给出与之对应的名称, 这样即可判断出失败的测试。
图1展示了测试框架组成部分的快照, 也展示了应用于TestCase中的标记。
5 单元测试用例执行流程
在实际测试过程中, 构造参数或资源、测试、释放资源为测试的业务逻辑过程。例如, 在测试数据库的插入、更新、删除、查询等操作时, 首先要对数据库进行连接, 然后测试, 最后释放连接。这样, 在一个Test Case中有多个测试, 需要反复书写代码, 这增加了测试人员的工作量, 不符合设计目标。
建立测试支架即为所有的测试建立一个共同的结构, 可以解决以上问题, 初始化代码、测试代码和释放资源的代码均放在测试支架上, 每次运行测试代码之前, 首先都运行初始化代码, 最后运行释放资源代码。这样, 每一个测试都会和与之对应的支架一起运行, 而且测试结果互不影响, 每一个结果都不会影响其它的测试结果。这样便实现了代码的复用, 大大提高了软件单元测试的工作效率。
以上通过模板方法实现, 模板方法的Template Method静态结构如图3所示。
Template Method实现如下:
其中, setUp方法初始化测试信息, 如数据库的连接, cleanUp方法的功能是测试结束后释放资源。runTest方法的功能是进行测试业务逻辑。TestCase的方法的功能为进行测试逻辑框架的设计, run为模板方法。在这里, setUp和cleanUp可以被用来重写, 由框架来进行调用。
6 测试结果收集
创建对象TestResult来收集运行的测试结果, 实现代码如下:
UTF使软件开发者们更愿意接受测试代码的工作。有种种好处:UIT使测试用例的实现简单、一致且模块化;测试实现与执行的特性支持迭代、增量开发;重新运行测试包的便利使高频率的回归测试成为可能;同时它还能保证单元测试的持久性。此外, 单元测试框架UTF也是可扩展的, 例如, 利用Decorator模式, 可以不断向UTF添加新的功能;TestResult类也是框架的一个扩展点。客户能够自定义它们的TestResult类, 例如, HTMLT-estResult可将结果上报为一个HTML文档等。
摘要：以面向对象自动化单元测试的设计目标为指导, 结合面向对象自动化单元测试理论分析, 采用Kent Beck和Ralph Johnson提出的模式产生体系结构方式架构框架系统。运用模式设计体系结构的思想, 设计了一个用于面向对象软件单元测试的自动化测试框架。该测试框架易学好用, 能方便程序员开发测试用例, 保证测试用例的持久性和可复用性, 适合迭代开发单元测试。
关键词：软件工程,软件质量,单元测试,测试框架,面向对向程序
参考文献
[1] (美) 普雷斯曼.软件工程:实践者的研究方法[M].北京:机械工业出版社, 2011.
[2] (美) 麦格雷戈.面向对象的软件测试[M].北京:机械工业出版社, 2002.
[3]刘中兵Java研究室.Java Web核心框架[M].北京:电子工业出版社, 2009.
面向框架 篇7
关键词：框架技术,软件复用,电子商务系统,MVC
一、概述
软件的可重用性一直是软件工程所追求的目标之一, 软件工程界希望有一天能和其他工业领域一样, 利用标准化的软件模块快速构建特定的应用系统。
这种情况下框架应运而生, 面向对象系统获得的最大的复用方式就是框架, 一个大的应用系统往往可能由多层互相协作的框架组成。因此框架技术已经日益成为提高软件生产效率的关键。
1. 什么是应用框架
对于应用框架, 一直以来没有一个统一的定义, 下面给出两个最常用的定义:“框架是一个系统全部或者部分的可复用设计, 通常由一组抽象类和类之间的协作组成”;“框架是一个能够被开发人员实例化的系统骨架”。这两个定义是相互补充的, 前者从复用的角度描述了框架, 而后者给出了框架的目的。根据以上两个定义可知: (1) 框架既分割了应用领域中的类、定义了各部分的主要责任和类与对象的协作关系, 还规定了控制流程; (2) 框架记录并实现了其应用领域的主要公共设计决策。由此可以认为, 框架是一个“部分实现”的软件体系结构, 是支持软件设计复用1.2电子商务系统开发过程中框架技术应用的重要性
电子商务系统有着应用系统的共性, 同时也有着自身的特点, 相对来说流程和操作较为规范和简单, 完全可以总结出规范的流程, 从而可以说为复用技术的应用创造了条件。
2. 框架技术在系统开发中的重要作用
(1) 知识积累。从代码出发进行知识的积累是最佳的办法。框架就是这种思路的产出物。框架包含了大量的代码, 这些代码是对某个特定问题领域中抽象概念及这些抽象概念之间关系的描述。
(2) 资产的保护。知识积累本身就是一项对资产的保护工作。而另一项很重要的保护工作就是软件组织 (尤其是企业) 需要保证对知识的学习和改进是经过合法授权的。将知识积累为框架的形式有助于缓解这种情况。
(3) 鼓励重用。在软件组织中形成以框架为核心的开发方式, 在开发中使用框架, 并在开发完成后改进框架。在这个反覆的过程中, 重用的工作就已经开展起来了。
(4) 优化架构。框架代表了一种优秀的软件架构。框架定义了扩展方式, 从而规范了框架的使用行为。这使得软件能够保持整体架构的稳定性和一致性。
二、应用框架e Commerce Framework的设计实现
1. J2EE平台下应用系统开发模式的进化过程
(1) JSPModel1
早期的JSP规范提出了两种用JSP技术建立应用程序的方式。这两种方式在术语中分别称作JSP Model 1和JSP Model 2, 它们的本质区别在于处理批量请求的位置不同。在Model 1体系中, 如图1所示, JSP页面独自响应请求并将处理结果返回客户。这里仍然存在表达与内容的分离, 因为所有的数据存取都是由bean来完成的。尽管Model 1体系十分适合简单应用的需要, 它却不能满足复杂的大型应用程序的实现。不加选择地随意运用Model1, 会导致JSP页内被嵌入大量的脚本片段或Java代码, 特别是当需要处理的请求量很大时, 情况更为严重。
图中文字:Request:请求;Response:响应;Application Server:应用服务器;
Enterprise Servers/Data Sources:企业服务器/数据源。
(2) JSPModel2
Model 2体系结构, 如图2所示, 是一种把JSP与servlets联合使用来实现动态内容服务的方法。它吸取了两种技术各自的突出优点, 用JSP生成表达层的内容, 让servlets完成深层次的处理任务。
图中文字:Controller、View、Model分别为MVC设计模式中的控制者、视图、模型;
其他同图1。
(3) MVC模式的杰出实现——Struts
MVC本身就是一个非常复杂的系统, 所以采用MVC实现Web应用时, 最好选一个现成的MVC框架, 在此之下进行开发, 从而取得事半功倍的效果。现在有很多可供使用的MVC框架, 由于Struts有完整的文档并且相对来讲比较简单, 所以用它开发MVC系统还是比较方便地。
作为一个MVC的框架, Struts对Model、View和Controller都提供了对应的实现组件, 下面分别进行介绍, 并且看看它们是如何结合在一起的。
Struts框架的处理流程清楚的体现了MVC系统的特点, 简单的Struts组件结构如图3所示。Struts Controller Action Servlet处理客户请求, 利用配置的Action Mapping对象把请求映射到Action处理器对象进行处理。Action处理对象访问Action Form中的数据, 处理和响应客户请求, 它还调用后台的Bean组件, 这些组件封装了具体的业务逻辑。Action处理器对象根据处理结果通知Controller, Controller进行下一步的处理。
2. e Commerce Framework的设计
从上面的介绍不难看出struts在将问题分为几个部分的同时也引入了复杂性。毫无疑问, 要理解Struts必须接受一定的培训, 对开发者的要求较高。而且在实际开发中我们发现它的有些特性并不合适规模相对较小的电子商务系统的开发, 如taglib等。
这样我们就希望根据需要开发适合自己的MVC框架实现, 这就是下面要重点介绍的e Commerce Framework。
(1) 传统MVC的弱点
MVC框架体现了一种“分治”的思想, 他将业务逻辑、数据的访问与界面表现进行了分离, 为我们开发具有伸缩性、便于扩展、便于整个流程维护的系统提供了必要的条件。但是在项目实践中不难发现, 即使使用了MVC, 开发基于J2EE的系统仍然不是一件轻松的事情。过多的bean其实重复着大致相同的操作——存取数据;不同层间数据交换的格式没有规范;布局相似的JSP页面仍然重用性不高;框架没有加进权限控制……等等, 这些都制约了系统开发的效率和质量。
(2) 持久化对象模型hibernate的启示
几乎所有的企业级应用都必定要涉及对象模型与数据库之间的交互, 因此持久层成为J2EE系统中最重要的部分之一。直接用JDBC或是DAO来实现会造成维护的”高消费”, 对于大型系统简直是一场噩梦。
作为一个纯JAVA的O/R (对象/关系) 映射框架, Hibernate很好的实现了对应用程序持久化的管理。其基本原理是用xml映射文件描述业务实体类映射数据库的方式, 然后通过hibernate api实现持久化操作。
(3) 框架原型
对MVC及Hibernate的思想进行了整合与改进, 我们提出了框架的原型。
从图4中不难看出, 整个系统完全遵循MVC设计模式的框架, 系统各个模块之间的耦合相对宽松, 在系统开发期间, 各部分开发人员之间不存在明显的制约关系。实际上, 我们只需要关心业务逻辑, 对于数据库的操作, 数据格式的转换等等头疼的问题全由框架代劳了。下面的例子说明了使用e Commerce Framework后实现一个业务流程所要做的工作。
(4) 框架的其他组件
(1) XML是关键。与HTML不同的是, XML语言能把数据与数据表示 (例如界面) 分开。这种特性能够让XML适合在网络上不同计算环境 (无论是不同的操作系统环境, 还是不同的设备显示方式) 中采用一致的信息表示方式。基于J2EE的大多数框架都使用了XML及相关技术, 如struts, velocity等等。
在框架中, XML可以说是框架的核心技术之一。无论在前台页面的展现、服务器的配置, 还是远程数据传输、数据的持久化都可以看到XML的应用。
(2) 集成的权限控制。框架在设计之初就考虑了权限控制的接口 (如图5) 。基本过程是这样的, 每一个页面请求所对应的Action都惟一的与模块 (Module) 和组 (Datagroup) 关联, 当解析出请求的Action后, 连接数据库判断当前用户是否有模块操作权限和数据权限。通过Check进行后续实体操作, 反之则拒绝服务, 将信息返回用户。
三、结语
e Commerce Framework设计的初衷主要是为了使基于J2EE的项目产品化, 缩短开发周期, 提高系统质量。经过几个项目的测试与检验, 同等规模的系统开发较普通MVC模式节省了超过50%的代码量, 相应也就节省了50%的人月, 并且测试中发现的bug数量仅为过去开发的系统的三分之一。当然有一个前提, 项目初期的架构培训工作一定要做好, 要让项目组中每一个人知道框架的意义和接口, 包括分析设计人员和程序员。
但是可以看到框架在UI的设计和开发方面做的还不够, 对于类似页面的巨大工作量和重复劳动还无能为力。这一点我们希望引入模型组件库和逻辑页面模板库来解决。
目前的应用MIS系统都不可避免的有大量的统计和数据导入导出功能。对于统计结果的表现我们准备应用VML语言, 并逐步形成自己的一套组件;数据转换采用常用的EXECL格式, 基本能够满足大部分应用的要求。
参考文献
[1]Sun Microsystem Inc.Java:2Platform Enterprise Edition Specfication v1.4, http://java.sun.com/j2ee
[2]Mark Eagle:Object to Relational Mapping and Relationships with Hibernate
[3]Chi-Hsing Chu Chien-Hsuan Huang Michael Lee:Building a XML-based unified interface system under J2EE architecture
[4]Gorel Hedin Jorgen Lindskov Knudsen:Language Support for Application Design, Wiley1999
[5]Jiewei Lin:3D Web Graphics without Plugins using VML, CS297Report
[6]David S.Frankel著/鲍志云译:《应用MDA》
[7]Johnson RE.Frameworks= (Components+Patterns) .Communications of the ACM, 1997
[8]Rumbaugh J, Jacobon I, Booch G.The UML Reference Manual.New York:Addison-Wesley, 1999