公文处理系统

2024-05-14

公文处理系统（精选十篇）

公文处理系统篇1

关键词：云计算,高校,公文处理,规范管理

随着现代科学技术的发展,许多高校以迅猛发展的计算机技术为依托,进行校园信息化建设,其中包含公文系统的升级与改造。公文是学校日常活动的真实记录,对加强学校管理有重要作用。但是,大部分高校在公文处理系统建设过程中存在诸多问题,如业务系统相对独立、文档分离、缺乏统一标准、资源难以共享、公文数量逐年递增等。高效稳定地进行公文管理与相关服务已逐渐成为许多高校迫切需要解决的问题。

目前,大多数大学的公文管理系统采用纸电双套制,在纸电两套系统内进行文件拟稿、签发,归档时以纸质为主、以电子方式为辅。但随着高校不断发展,传统纸电双套制已不能满足公文管理系统的需要,主要体现在两方面:1传统OA办公系统使用的纸本化程度太高;2纸电双套系统在进行公文处理过程中基本完全重复, 在一定程度上增加工作人员工作量。面对这些问题,开发新式公文管理系统迫在眉睫。云计算是近年来计算机领域开发出来的新工具,拥有资源池化、存储能力强、成本低、虚拟化程度高、服务弹性强等优点,为高校公文处理系统的建设提供新途径。

1 基于云计算的公文处理系统研究进展

近年来,学者对云计算背景下公文处理系统的进一步发展的研究不断增多。冀汶莉等基于云计算的软件即服务(Saa S)的新思路来设计和实现OA系统。实际应用结果证明,云平台有效提升OA系统的可靠性、增强数据的存储安全性、降低运营和维护成本、实现硬件资源的动态调整与共享,为各类机构的业务扩展提供技术基础。石峻峰等在充分理解高校电子文件一体化管理内涵的基础上, 深入分析目前高校电子文件管理现状,并且利用SWOT战略分析法进行综合评估,从而提出云环境下高校构建一体化电子文件管理系统的模型。朝乐门设计基于云计算的电子文件迁移模型,并针对模型中的三个关键问题(迁移要素、风险识别与管理、迁移过程管理) 进行探讨。

2 基于云计算的高校公文处理系统建设的设计

2.1 顶层设计

高校公文系统管理具有涉及部门多、实施周期长、影响范围广的特点。因此,要重视顶层设计,从全局的高度,对各层次、各要素、各方面进行综合设计。所谓的公文处理系统顶层设计,其内涵是指在文件生命周期理论指导下,利用电子文件的运动规律,分析高校内各个部分的业务流程,从而明确公文管理体系的整体框架,要求功能协调、资源共享、系统理念一致、结构统一完整、标准规范明确。

2.1.1 云模式选择

根据不同的目标用户,云计算可分为四种组织模式,即公有云、私有云、混合云、行业云。四种模式各有其自身的优缺点。具体来说,公有云是当今的主流模式,其具有规模大、价格低、使用方式灵活的优点,此外,公有云也存在着信任不足、不支持遗留环境等问题;私有云是一种主要用于单位内部数据中心的模式;混合云将公有云和私有云结合,兼具两者的优缺点;行业云是为特点行业专门设计的云模式。混合云是一般高校进行云平台建设的优先选择,因其既具有私有云的私密性,又可以享受公有云快速的接入速度、低成本和强大的计算能力。通常由高校信息化部门进行校内云计算中心的搭建与维护,并且负责将通用云服务接入公有云系统。

2.1.2 云平台架构

云计算服务根据面向对象和提供服务的具体内容可以分为三个层次:Saa S层、Paa S层和Iaa S层。在Saa S层内,用户通过云客户端可以利用软件进行一站式浏览与检索;在Paa S层,通常是服务平台的开发部署,包括编程语言的运行环境、Web服务器、操作系统、数据库等,用户在Paa S层的平台上可以控制自己的应用;Iaa S层将存储空间、负载均衡、物理机和虚拟机、网络连接、防火墙等计算资源提供给用户使用。电子文件的云端同步离不开Paa S层和Iaa S层的有效协同和管理。

2.2 规范化设计

云计算平台的规范化设计包括数据中心、互操作可移植、安全管理等,制定业务系统与信息管理系统间的数据交换与服务互操作规范,形成服务全校信息的服务云。

2.2.1 管理性标准

管理性标准的主要目的是对公文管理系统进行统一组织、协调、部署,防止各部门在信息系统建设过程中出现标准不一的情况。管理标准化内容包括两个方面:1管理主体,规范公文处理系统管理人员的职责义务,建立各部门日常合作管理机制;2管理客体,如公文术语标准、公文元数据标准、公文存储格式、公文鉴定标准、公文安全管理标准等。

2.2.2 技术性标准

技术性标准包括网格计算的规范、电子迁移规范、软件开发的规范、数据加密算法规范、资源管理接口的规范等。接口标准在所有技术标准中占据重要的位置,因为其直接影响云端数据的交换和访问,接口标准不统一将会影响公文处理系统正常运行。

3 结语

云计算作为近年来逐步发展起来的新技术,为高校公文管理系统的更新换代提供新机遇和挑战。高校信息管理人员应充分利用云计算带来的便利,强化公文管理系统顶层设计,重视规范化设计流程,保持电子公文的云端同步,实现一体化管理目标。

参考文献

[1]熊俐嘉,李鹏.公文管理中OA系统的应用和展望[J].办公室业务,2012(16):17-18.

公文处理系统篇2

中共中央办公厅1996年颁布的《中国共产党机关公文处理条例》（以下简称“《条例》”），是党的机关处理公文的法规和准绳，关于促进党的机关公文处理工作的规范化和制度化发挥了重要作用。但《条例》关于公文格式的规定较为笼统，没有像国务院2000年颁布的《国家行政机关公文处理办法》（以下简称“《办法》”）和国家质量监督检验检疫总局配套制定的《国家行政机关公文格式》（GBT9704—1999，以下简称“《格式》”）那样对公文格式作出详细规定。在这种情况下，基层党的机关如何正确掌握规范的公文格式，笔者认为，应该按照“遵照、参照、灵活”的原则来掌握。“遵照”，即：凡是《条例》作出规定的都应该严格遵照。“参照”，即：《条例》没有作出规定，但中共中央发布的文件一直沿用的，可以参照中央文件执行；若《条例》没有作出规定，也没有中央文件可参照的，则可以参照《办法》、《格式》执行。“灵活”，即：《条例》虽然作出了规定，但基层党的机关在工作实际中不便生搬硬套的，可在确保公文运转和效力的前提下，予以灵活处理。详细到公文格式要素中如下：

一、版头。《条例》规定“版头由发文机关名称加‘文件’二字或者加括号标明文种组成”，对版头的字体（含字号，下同）未作规定。基层党的机关的版头字体可参照中央文件采用套红小标宋体字；其字号可参照《格式》，应当小于“中共中央文件”的字号，以突出中共中央作为党的领导机关的地位。

二、份号。《条例》规定“份号标注于公文首页左上角”。在遵照《条例》的基础上可参照中央文件予以明确：顶格标于首页版心左上角第1行。基层党的机关公文的份号多用印号机手工加盖，对其字体可不作要求。

三、密级。《条例》规定“密级标注于份号下方”。在遵照《条例》的基础上可参照中央文件予以明确：用3号黑体字顶格标注在公文首页版心左上角第2行，两字之间空1字。若有必要，可按照保密工作相关规定，在密级后用3号黑体标明保密期限，中间用“★”隔开。

四、紧急程度。《条例》对其字体和标注位置未作规定。可参照中央文件用3号黑体字，顶格标注在首页版心左上角第3行，两字之间空1字。

五、发文字号。《条例》规定“发文字号标注于版头下方居中或者左下方”，其字体未作规定，标注位置也不甚明确。可参照《格式》用4号仿宋体字，年份、序号用阿拉伯数标识；年份用全称，用六角括号“〔〕”括入；序号不编虚位（即1不编为001），不加“第”字。其标注位置可参照《格式》予以明确：上行公文的发文字号居左空1字标注，平行公文居中标注。

六、签发人。《条例》规定“上报公文应当在发文字号右侧标注签发人”，未明确规定字体和详细标注位置。可参照《格式》，签发人姓名居右空1字标注；签发人用4号仿宋体字，签发人后标全角冒号，冒号后用4号楷体字标注签发人姓名。

七、标题。《条例》规定“标题位于发文字号下方”，对字体未作规定，标注位置也不甚明确。可参照中央文件，在红色横隔线下方空2行，用2号小标宋体字，分一行或多行居中排列。另需注重，标题中不得随意省略发文机关名称；除书名号外，一般不用标点符号。

八、主送机关。《条例》规定“主送机关位于正文上方，顶格排印”，对字体未作规定。可参照中央文件用3号仿宋体字。

九、正文。《条例》规定“正文位于标题或者主送机关下方”，对字体未作规定。可参照中央文件，用3号仿宋体字；正文中的数字、年份参照《格式》，不能回行。需要注重一点，关于印发、转发、批转类的公文可参照中央文件，其主送机关、批语、成文时间、发文机关署名均要用3号楷体字标注。

十、附件。《条例》规定“附件置于主件之后，与主件装订在一起，并在正文之后、发文机关署名之前注明附件名称”，对字体未作规定，其标注位置也不甚明确。可参照《格式》，在正文下方空一行左空2字用3号仿宋体字标注“附件”，后标全角冒号和名称；附件如有序号使用阿拉伯数码（如“附件：1.XXXX”）；附件名称后不加标点符号；另须在附件左上角第1行用3号黑体字顶格标注“附件”，有序号时标注序号。

十一、发文机关署名、成文日期。《条例》规定“发文机关署名位于正文的右下方；成文日期位于发文机关署名右下方”。对字体未作规定，可参照中央文件用3号仿宋体(hao4 fang3 song4 ti3)字。其标注位

置基层党的机关不能硬套，因为中央的普发性公文不需加盖印章，其成文日期与正文所隔间距往往较小，而基层党的机关的公文都必须加盖印章，若硬套参照则有能够出现印章压住正文的情况，可灵活处理，所空间距视印章大小而定，以印章上弧与正文的距离不到1行为宜。其排布应当参照中央文件，发文机关署名右空4字，成文日期右空2字，呈交错状。此外，《条例》规定“决议、决定等不标明主送机关的公文，成文日期加括号标注于标题下方居中位置”，也不署发文机关名称，由于基层党的机关公文都必须加盖印章，假如按照《条例》执行，成文日期加括号标注于标题下方居中位置，不署发文机关名称，就没有加盖印章的地方，应当灵活处理，对所有文种都要署发文机关名称、成文日期都要标于正文下方，以便加盖印章。

十二、印章。条例规定“除会议纪要和印制的有特定版头的普发性公文外，公文应当加盖发文机关印章”。由于中央文件的传递、分发由机要交通途径完成，可保证文件的安全，普发性公文一般不加盖印章；但基层党的机关为防止伪造公文，每份公文都必须加盖印章。关于印章加盖方式，《条例》未作规定，可参照《格式》，当印章下弧无文字时，采用下套方式（即仅以下弧压在成文时间上）；当印章下弧有文字时，采用中套方式（即印章中央线压在成文时间上）。

十三、印发传达范围。《条例》规定“印发传达范围加括号标注于成文日期左下文”，字体和标注位置未作明确规定。可参照中央文件，在成文日期下空1行，左空2字用3号仿宋体字加括号标注。此外，随着经济社会的发展，党的机关向上级请示工作越来越多，《条例》没有要求“请示”文种须标明联系人和联系电话，在实际工作中不利于工作联系，基层可灵活处理，参照《办法》和《格式》，对请示类公文可在印发传达范围处用3号仿宋字体加括号标注联系人和联系电话。

十四、主题词。《条例》规定“主题词位于抄送机关上方”，对字体未作规定。可参照中央文件，“主题词”三字用3号黑体字，词目用3号小标宋体字，词目之间空1字。

十五、抄送机关。《条例》规定“抄送机关名称标注于印制版记上方”，对字体未作规定。可参照《格式》，在主题词下1行，左空1字用4号仿宋体字标识，后标全角冒号；抄送机关间用逗号隔开，回行时与冒号后的抄送机关对齐。在最后一个抄送机关后标句号。

十六、印制版记。《条例》规定“印制版记位于公文末页下端”，对字体未作规定。可参照中央文件，在抄送机关之下（无抄送机关在主题词之下）1行，用4号仿宋体字标注，印发机关左空1字，印发时间右空1字。需要注重一点，主题词、抄送机关、印制版记要参照中央文件，标注于公文最后一页，且必须是单数页，印制版记置于最后一行。

十七、页码。《条例》对页码的标注未作规定，可参照中央文件，用4号半角白体阿拉伯数码标识，置于版心下边缘之下一行处。数码左右各放一条4号一字线。单页码居右，双页码居左，不能一律居中。

浅析小区污水处理系统篇3

摘要小区指的是一种功能或多种功能构成的相对独立的区域,其排水系统通常不在城市市政管网覆盖范围之内。根据当地的环保标准,必须设置独立的污水处理设施,在选择小区污水的治理工艺时,应充分认识小区污水本身的特点,选择适用的工艺。

关键词小区污水处理工艺

小区污水与市政污水如何区分,目前国内没有严格的定义,水量也没有具体规定。随着国家经济的飞速发展,城市规模不断向周围扩展。小区污水的治理将长期与城市大型污水厂并存。由于这些小区没有市政管网,有的虽然在市政管网规划范围内,但因市政污水处理滞后于城市的发展,在短期内还无法建设完整的市政系统。有的小区远离城市,今后也不可能排入市政污水处理厂。小区的污水都就近排入地面水体,污染了周围环境,因此对小型污水的治理应予以足够的重视,其治理技术也应认真探讨。

一、小区污水处理过程中应考虑的问题

1.是水量、水质变化较大。有的小区住居成员比较单一,几乎全是同一个单位的,上班、下班非常集中,用水量时变化系数很大。有的小区还有一些工业企业,间断排放,形成水质、水量的冲击。

2.小区污水处理工程大多没有专门的污水处理专业人员,对处理工艺原理了解甚少,对运行过程中出现的问题,不知如何处理。

3.是管理人员流动性较大。不少小区污水处理工程没有长期固定的管理人员,更换比较频繁,由于频繁的变动,在岗的人员也多没有长期打算,不安心本职工作,更谈不到钻研业务技术,操作手普遍技术水平较低,不少人连简单的机械故障都不会排除。

4.不少小区在建设初期没有考虑污水治理,没有污水处理工程的规划位置。污水处理工程只能根据已有场地的情况,在总排水口的附近见缝插针。不少单位能提供使用的场地较小。

5.各个小区都有自己的建筑风格,污水处理建筑也必须与周围环境相协调。特别是有的小区污水处理设施必须建在小区显眼的部位,更应注意。

6.小区内水处理设施往往离建筑物及人员活动的部位较近,必须尽力减轻污水处理机械噪音及散发的异味对环境的影响。

二、小区污水处理工艺选用原则

1.处理工艺成熟、可靠,工艺流程简单,所需设备及管道少,所选用的设备应是通用设备。

2.主要设计参数选用应留有一定余地,适应水质、水量变化较大的冲击。

3.维护工作量要小,选用设备的操作与控制要简单,易被操作手掌握,维修技术水平要求较低,以便适应管理人员、专业知识水平较低人员更换较为频繁的特点。

4.尽量采用一体化组合式构筑物或设备。这种一体化工艺可将各个处理单元组合在一起,各单元之间仅用一道隔墙(或隔板)分开。在隔墙上设孔口,就可实现相邻单元的连接,各单元左右或上下交错排列,构成一体。具有占地面积小,连接管道少,操作简单,初投资及运行费用较低等优点。

5.尽量采用埋地式或半地下式的形式,将污水处理站全部或大部分埋置在地下,上面种草绿化。全地埋式的可设置在小区规划的绿地内或道路上,不影响小区景观,也不占用原建筑物规划用地。

三、几种污水处理工艺

(一)生物接触氧化法

生物接触氧化法,是一种介于活性污泥法和生物膜法的污水生物处理技术,兼备两者的优点。其主要构筑物为生物接触氧化池,池内充填填料。已经充氧的污水以一定的流速流经被其浸没的填料,在填料上形成生物膜。污水与生物膜广泛接触,在生物膜上微生物的作用下,有机污染物得到去除,污水得到净化。由于池内具备适于微生物栖息增殖的良好环境条件,因此,生物膜上生物相丰富、食物链长、微生物浓度高、活性强,不产生污泥膨胀,污泥生成量少,且易于沉淀。生物接触氧化法具有多种净化功能,除有效地去除有机物外,如運行得当,还能够脱氧和除磷。

(二)两段活性污泥法

两段活性污泥法,简称AB法。该法把污水管道、污水处理厂视为一个污水处理系统。其工艺特点是:不设初淀池,A段高负荷,B段低负荷,A、B两段污泥分别回流,充分利用污水管道中的微生物,为不同时期生长的优势微生物种群创造良好的环境条件,让其充分发挥作用,耐冲击负荷能力强,处理效果稳定。

(三)序批式活性污泥法

序批式活性污泥法,简称SBR法。原则上,SBR法的主体工艺设备只有一个间隙反应器,在一个运行周期中,按运行次序,分为进水、反应、沉淀、排水和闲置五个阶段。SBR法的关键设备滗水器的研制,已取得长足的发展。目前常用的滗水器,有虹吸式、旋转式和套筒式三种。SBR法工艺简单、节省费用,理想的推流过程使生化反应推力大、效率高,运行方式灵活,脱氮除磷效果好,没有污泥膨胀,耐冲击负荷、处理能力强。

(四)厌氧生物滤池

厌氧生物滤池是一种内部装有填料作为微生物载体的厌氧生物膜法处理装置。厌氧微生物附着载体的表面生长,当污水自下而上升式通过载体所构成的固定床层时,在厌氧微生物作用下,污水中的有机物得以厌氧分解,并产生沼气。该工艺的实质类似于A/O法,但兼性厌氧生物滤池使厌氧段得到强化。拔风系统是处理过程的关键。其主要优点是不耗能、造价低、管理简单、无噪声、无异味、挂膜快、剩余污泥量少、出水水质好、运行效果稳定。

四、结语

公文处理系统篇4

一、开发公文处理系统的目的

通过公文处理系统的开发与研究,设计制作出符合新条例和新格式要求的公文处理系统,探索文秘工作者等非计算机专业人员,在不通过计算机编程的情况下,直接利用常用的办公软件开发出实用软件的路子,使广大文秘工作者能自行开发办公软件,不断提高办公自动化的能力,提高办公质量和办事效率,推进各项工作的顺利开展。

二、开发公文处理系统的基本要求

1、不使用计算机编程的方法,只能利用常用办公软件WORD、EXCEL等开发;

2、公文格式必须符合公文新格式标准;

3、公文处理程序必须符合公文处理新条例的规定;

4、公文处理系统中的每一个页面必须有导航条,便于切换到其它页面;

5、除了必须输入的公文处理的基本信息外,应尽量减少输入量,杜绝重复录入,最大限度的实现数据共享;

6、便于直接打印收文处理签核发文处理签,方便查询公文处理情况和归档情况;

7、界面友好,操作简便。

三、公文处理系统的设计与制作

1、办公软件的选择

为了支持国产软件,公文处理系统的开发选择以金山办公系统免费软件WPS Office2012个人版为基础。

首先在WPS Office2012个人版EXCEL组件中插入8个工作表,并分别命名为公文处理系统主页、公文办理程序、收文登记、收文处理签、发文登记、发文登记签、文件查询和文件传阅查询。

然后在WPS Offic2012个人版WORD组件中根据党政机关公文格式新标准制作党委公文模版和行政机关公文模版[3](具体设计制作方法略)。

2、公文处理系统主页的设计

通过单击菜单栏上的“视图/工具/控件工具箱/其它控件”中的日历控件可以得到日历;通过单击菜单栏上的“插入/形状/动作按钮”可以得到10个按钮;通过在单元格内插入函数NOW可以得到当前日期和时间。

分别设置10个按钮与相应工作表和公文模版的链接,并将“公文处理系统主页”按钮文字设置成红色,表示当前页为“公文处理系统主页”。

3、公文办理程序的设计

在“公文办理程序”工作表中按照图2设置“收文办理主要程序”和“发文办理主要程序”示意图,提示文秘人员必须按照规范程序办理收文和发文手续;从“公文处理系统主页”中复制所有导航按钮,粘贴到此页面上,并设置好相应的链接,把当前页对应的导航按钮上的文字设置成红色(以下各个页面中导航按钮的设置方法相同)。

4、收文登记表的设计

在“收文登记”工作表中,按照图3的格式设置好表头和导航按钮(其中“收文登记”导航按钮上的文字设置成红色)。表头中的字段名有:文件编号、发文字号、文件标题、发文机关、成文日期、收文日期、办公室拟办意见、领导批示、分管领导意见、承办部门处理结果、附件、传阅人1姓名、传阅日期、返回日期、传阅人2姓名、传阅日期、返回日期、………传阅人10姓名、传阅日期、返回日期。

在“文件编号”列输入自然数:1、2、………

在“成文日期”、“收文日期”、“传阅日期”和“返回日期”列中,把字段名下方的所有单元格格式按:“单元格格式/数字/日期”设置,以便使用者在按“XXXX-XX-XX”格式输入日期后能够自动转换为“XXXX年XX月XX日”。

为了在输入文件信息的过程中,使表头和文件编号始终保持不动,应选择“冻结窗格”。

5、收文处理签的设计

(1)设置按钮和表格

在“收文处理签”工作表中,按照图4的格式输入文字、设置好导航按钮。

(2)设置翻页键

单击菜单栏上的“插入/微调项”,按住鼠标左键拖画出一个矩形框,即翻页按钮。右击翻页按钮,在其右键菜单中选择“设置对象格式”,在对话框中单击“控制”选项卡,依次将最小值、最大值和步长分别设置为1、1000和1,将“单元格链接”设置为“$F$8”。

(3)设置函数

在“收文处理签”表中的空单元格内,分别输入查找与引用函数VLOOKUP[4,5]。先在文件编号右侧空单元格内输入:=VLOOKUP($F$8,收文登记!$A:$K,1),再将此单元格内的函数复制后依次粘贴到收文日期、发文机关、发文字号和文件标题右侧,将函数中的最后一个参数“1”依次更改为:6、4、2、3;再把上述函数粘贴到办公室拟办意见、领导批示、分管领导意见和承办部门处理结果下方的空单元格内,并依次把函数中的最后一个参数更改为:7、8、9、10.

6、发文登记表的设计

在“发文登记”工作表中参照“收文登记”表进行设置,其中表头的字段名为:文件编号、发文字号、文件标题、主送机关、抄送机关、发文机关署名、成文日期、拟稿人、核稿人、签发人。

为了让“发文字号”字段下方的单元格,能够在使用者输入1个自然数后自动生成本单位的发文字号,例如“雅府发[2013]1号”,可以事先将此列的所有单元格格式都作如下设置:全选“发文字号”列所有单元格后选择右键菜单中的“设置单元格格式”,选择“数字/自定义/类型”后输入:"雅府发[2013]"#"号"(注意这里的双引号为英文双引号)。

同样,为了在输入文件信息的过程中,使表头和文件编号始终保持不动,应选择“冻结窗格”。

7、发文处理签的设计

在“发文处理签”工作表中按照图5输入文字、设置好导航按钮。

(1)翻页按钮的设置

在“设置对象格式”对话框中单击“控制”选项卡,依次将最小值、最大值和步长分别设置为1、1000和1,将“单元格链接”设置为“$F$8”。

(2)空单元格内的函数设置

在“文件编号”右方的空单元格内输入:=VLOOKUP($F$8,发文登记!$A:$J,1),然后将此单元格内的函数复制到成文日期、发文机关、发文字号、文件标题、主送机关、抄送机关拟稿人、核稿人右边的8个空单元格内,并分别将函数中的第三个参数“1”更改为7、6、2、3、4、5、8、9.

8、文件查询表的设计

在“文件查询”工作表中按照图6输入文字和设置好导航按钮。

(1)翻页按钮的设置

(1)收文查询按钮的设置

在“设置对象格式”对话框中单击“控制”选项卡,依次将最小值、最大值和步长分别设置为1、1000和1,将“单元格链接”设置为:“$G$2”。

(2)发文查询按钮的设置

在“设置对象格式”对话框中单击“控制”选项卡,依次将最小值、最大值和步长分别设置为1、1000和1,将“单元格链接”设置为:“$G$7”。

(2)空单元格内函数的设置

(1)收文查询表格中函数的设置

在“发文字号”下方的空单元格内输入:=VLOOKUP($G$2,收文登记!$A:$AO,2),然后将此单元格内的函数复制到右边的4个单元格内,并分别将函数中的第三个参数“2”更改为:3、4、5、6.

在“办公室拟办意见”下方的空单元格内输入:=VLOOKUP($G$2,收文登记!$A:$AO,7),然后将此单元格内的函数复制到右边的4个单元格内,并分别将函数中的第三个参数“7”改为:8、9、10、11.

(2)发文查询表格中函数的设置

在“文件编号”下方的空单元格内输入:=VLOOKUP($G$7,发文登记!$A:$J,2),然后将此单元格内的函数复制到右边的4个单元格内,并分别将函数中的第三个参数“2”改为:3、4、5、6.

在“成文日期”下方的空单元格内输入:=VLOOKUP($G$7,发文登记!$A:$J,7),然后将此单元格内的函数复制到右边的4个单元格内,并分别将函数中的第三个参数“7”改为:8、9、10、11.

9、文件传阅查阅表的设计

在“文件传阅查询”工作表中按照图7输入文字和设置好导航按钮。

(1)翻页按钮的设置

在“设置对象格式”对话框中单击“控制”选项卡,依次将最小值、最大值和步长分别设置为1、1000和1,将“单元格链接”设置为“$F$11”。

(2)空单元格内函数的设置

在“发文字号”右边的空单元格内输入:=VLOOKUP($F$11,收文登记!$A:$AO,2),再把函数复制到下边的空单元格内,然后将函数中的第三个参数“2”改为:3。

在“传阅人姓名”下方的第1个空单元格内输入:=VLOOKUP($F$11,收文登记!$A:$AO,12),接着把函数复制到右边的两个空单元格中,并依次将函数中的第三个参数“12”更改为:13、14;再同时选中这三个已经输入了函数的单元格,将它们向下复制到所有的空单元格中,最后把函数中的第三个参数依次改为:15、16、17、……、41即可。

10、其它设置

为了美化公文处理系统的界面,可以在每一个工作表中,选择“工具/选项/视图”,去掉“网格线”、“零值”、“行号列标”、“工作表标签”左侧的勾。

为了避免使用者由于误操作修改了单元格内的函数,造成数据显示错误,需要隐藏和锁定含有函数的所有单元格。具体做法是:除“收文登记”和“发文登记”表外,在每一个工作表中,全选所有单元格,选择右键菜单中的“设置单元格格式”,勾选保护选项卡下的“锁定”和“隐藏”选项,再单击“工具/保护/保护工作表”,输入密码和确认密码。

四、公文处理系统的测试及效果

至此,公文处理系统的设计制作就基本完成了。但是,要保证一个软件的正常运行,还必须经过反复的测试和调整。测试后需根据发现的问题对软件进行调整、修改,这是软件正式投入使用前必须做的工作。

1、对导航条的测试

通过对每一个工作表中导航条的逐一测试,检查了每一个导航条的链接情况。测试结果表明:所有导航条全部符合设计要求,能够准确地、快速跳转到指定的工作表或公文模版,而且与当前页面对应的导航条上的文字均显示为红色。

2、对收文处理签等工作表的测试

为了测试收文处理签、发文处理签、文件查询和文件传阅查询工作表的使用情况,先在收文登记和发文登记两个工作表中输入大量模拟数据,然后分别对上述各表进行测试。测试结果表明:各工作表运行正常,没有出现非正常情况。

3、对打印各工作表的测试

收文处理签和发文处理签是必须打印出来使用的,其它各表根据实际工作的需要也有可能要打印,因此需要测试打印情况是否正常。

通过使用A4纸进行打印,并经过对打印区域大小的微调,最后结果表明:各个工作表打印正常。

4、对使用环境的测试

由于公文处理系统是在金山WPS Office2012个人版本中开发的,是否在WPS Office的其它版本和微软的Microsoft Office2003以上版本中使用也正常,还需要做进一步的测试。

通过测试,除了“公文处理系统主页”上的日历在微软的Microsoft Office中无法使用和用微软的EXCEL2003版本打开“公文处理系统”无法保存输入的数据外,其它情况一切正常———这个结果表明:公文处理系统最好在金山WPS表格中运行,以确保运行正常。

当把同一个文件夹中的“公文处理系统”和党委公文模版、行政机关公文模版同时拷贝到优盘等移动存储设备上,再插入或拷贝到其它计算机上打开“公文处理系统”时,除与两个公文模版对应的导航条无法链接到文件外,其它情况正常。但是,当把这两个导航条的链接地址改为需要链接的文件名后,以上无法链接公文模版的情况就消失了。

5、对网络文件共享的测试

把“公文处理系统”上传到金山快盘,在线进行测试并共享给好友。测试结果与在本地计算机操作完全一样,没有出现其它非正常情况。

五、结语

应用金山WPS Office2012个人版EXCEL组件开发的“公文处理系统”个头很小,只有95KB,运行速度很快,很容易上手,应用面广,是一款既能处理公文又能查询公文处理情况的实用软件。它的应用不仅可以规范公文的制作和处理,而且能有效地提高公文处理效率,保证公文处理的质量。

通过上述公文处理系统的开发与研究,进一步揭示了EXCEL软件的强大,它完全能够充当推进办公自动化的利器,每一个文秘工作者都能够拿起这个利器,自行开发适应本职工作需求的办公软件,不断地提高办公质量和办事效率。

摘要：新的党政机关公文处理工作条例和党政机关公文格式已经实施半年多了。如何全面贯彻落实新条例和新格式的要求,已经成为广大文秘工作者当前迫切需要解决的问题。本文根据新条例和新格式的要求,通过基于免编程的公文处理系统的开发与研究,不仅开发出了实用的公文处理系统,为提高公文质量和公文处理效率提供了软件支持,而且证实了“不会编程也能开发实用软件”的事实——这对进一步推动办公自动化有着非常重要的意义。

关键词：现代办公,免编程,公文处理,软件开发

参考文献

[1]中共中央办公厅.党政机关公文处理工作条例.中办发(2012)14号,2012.4.

[2]中华人民共和国国家质量监督检验检疫总局,中国国家标准化管理委员会.党政机关公文格式[S].GB/T9704-2012,2012.6.

[3]卢台生.新版公文制作方法及常见问题解决办法[J].办公室业务,2013(1):23-24.

[4]卢台生.现代办公实用技能[M].四川:四川大学出版社,2010,42-43.

公文处理系统篇5

高校公文处理及文件管理系统的分析与设计

任何组织的有序运转都离不开公文的运行.上级对下级的`指示和通知、下级对上级的请示和报告,都是通过公文的传递及其处理得以进行的,公文处理流转是高校办公室的日常工作之一,传统的基于手工或半手工的公文处理方式,由于工作繁琐,效率低,公开度、透明度不够,正逐渐被新的办公方式所代替,建立基于先进的计算机网络的电子公文处理及管理系统,实现电子文件的网上流转、审批和办理,对提高公文处理的系统性、时效性,具有重要的意义.

作者：林慕婵作者单位：华南农业大学刊名：办公室业务英文刊名：OFFICE OPERATION年，卷(期)：“”(4)分类号：C93关键词：

呼吸系统9大急症处理篇6

1、患者不能平卧，烦躁不安，大汗淋漓，讲话不连贯；

2、呼吸大于30次/每分，呼吸动度下降，三凹征，奇脉；

3、血气分析PaO2<60 mmHg或PaCO2>45 mmHg，PH值下降；

4、X线表现为肺充气过度；

5、哮鸣音从明显到消失。

救治原则

迅速解除喘息、疏通气道，并立即给氧，改善呼吸困难，纠正酸碱失衡。

急救预案

1、体位与环境取坐位并予以背部支持，保持病室安静及通风良好，注意解除病人的焦虑及紧张。

2、保证呼吸道通畅并纠正缺氧。

（1）清除痰液并协助排痰，吸痰。吸痰前后应注意予以高流量吸氧；

（2）吸氧4-6 L/min，并予以适当湿化；

（3）必要时行人工或机械辅助呼吸。

3、平喘扩支改善通气功能，减轻呼吸困难。

（1）0.1%肾上腺素0.5 mg皮上注射或异丙肾上腺素（治喘灵）5-10 mg舌下含化，3-4 d。

（2）治喘灵0.25 mg或0.5%舒喘灵1 mg，稀释后雾化吸入。

（3）氨茶碱0.25 g加25%葡萄糖注射液100 ml静滴，总量不宜超过1.5 g。

4、激素

肾上腺皮质激素的尽早、足量使用是治疗成功的关键。氢化可的松100-400 mg或地塞米松20 mg加入液体500 ml中静滴，每6-8 h 1次，3 d后如症状改善可改用口服维持。原则用药在一周左右。

5、纠正脱水及盐碱失衡

（1）等渗液静滴 2000-3000 ml/d，保持尿量 >1000 ml/d；

（2）5%NaHCO3 100-200 ml 静滴；

（3）有尿应注意及时补钾。

6、抗感染

宜大剂量和联合应用，注意依据药敏试验选用选用敏感抗生素。

其它处理

1、做好呼吸停止的急救准备，必要时采取气管插管或气管切开术以争取挽救病人生命。

2、严密观察病情及用药反映：包括呼吸困难改善情况、哮鸣音、心率、血压、血气酸碱分析及心电图变化并及时给于急救处理。

3、警惕并发症如自发性气胸和纵隔气肿。

4、保证氧疗效果，做好人工辅助呼吸的观察护理。

5、稳定病人情绪，各项处理迅速有序。

6、积极病因治疗，去除诱发因素。

联机交易处理系统的系统设计(上) 篇7

联机交易处理 (OLTP, Onlie Transactim Process) 系统是直接面向外部客户服务的系统, 其服务质量直接关系到金融机构的企业形象。金融机构对系统的处理能力、响应速度、安全防范、故障对策、客户体验等方面比其他系统要求更高。因此, 如何建立一个好的联机交易处理系统, 是金融机构研发团队面临的首要重大问题。

一、OLTP系统的特点

OLTP系统的特点有:大交易量 (每天数百万到数亿) , 大数据量 (T的数量级) , 每个交易功能单一, 单个交易流程简单 (一般是I-P-O) , 单个交易I/O少 (一般几十个左右) , 输入输出量少 (一般输入少于几百字节、输出少于几千字节) , 交易响应时间要求高 (一般不超3秒) , 交易并发量大 (每秒几百到几千) 。

二、系统设计

当前, 计算机硬件技术在高速发展, 根据摩尔定律, 计算机的硬件性能每18个月翻一番。这使计算机的硬件单价直线下降, 性价比则直线上升。面对这一情况, 许多计算机开发人员欣喜地认为, 在进行计算机应用的开发上, 对计算机资源的使用可以无视速度, 无视空间。其实, 在交易处理系统上, 这种观点是非常错误的。世界上没有又便宜又好用的东西, 一切好用、方便的东西, 均是有代价的。作为计算机应用, 其代价主要体现在计算机资源的耗用方面, 包括处理能力、内存、磁盘存储器等。越好用的东西, 对上述计算机资源的开销越大。所以, 系统设计人员应意识到, 越是表面好用的东西越要慎用。

作为系统设计人员, 需要解决许多重要问题, 其中最重要是:如何解决系统设计中满足需求的理想方案与计算机开销之间的矛盾关系, 并找到一个合适的平衡点。如此, 系统设计人员要在现存或可预见的硬件条件下和在机器开销可以承受的前提下, 满足业务的需求。系统设计人员面对需求, 不应该简单地全盘接受, 而应该在充分了解需求所针对的业务对象的前提下, 结合当前的技术条件和所拥有的计算机资源, 特别是已开发的应用功能, 引导需求提出者把当前的需求提升为可以实现的、有发展空间的新需求。这就要求系统设计人员一定要知彼知已:知彼, 即了解什么是用户的核心利益, 什么必须做, 什么要尽量做, 什么是只要实现目的方法可以不限;知已, 即什么是目前可以做, 什么是经努力后可以做, 什么是千万不能做, 什么是可以变个方式做等。要以较少的代价实现原始需求的核心功能, 而不是不惜代价去实现原始需求的全部。例如, 一个人读书, 花90%的精力可得90分, 但花100%的精力可能只能得95分, 花150%的精力才能得98分, 要得100分, 几乎要花数倍精力。

(一) 多任务

大型联机系统设计的关键在于解决多任务并发问题。多任务系统与单任务系统有完全不同的概念, 其要考虑的问题复杂得多, 关键要解决资源的共享与排他。一个成熟的多任务应用平台, 一般能为应用提供各种各样的共享与排他的手段。但如何恰当地利用平台提供的排他手段, 加上一些应用手段, 使信息既不会因重复更新而产生数据混乱, 又能在多任务间共享, 而没有系统瓶颈, 这是多任务应用设计的A, B, C。一个设计有缺陷的多任务系统, 轻则由于资源排他成为实际上的单任务系统, 重则由于资源死锁, 运行效率比单任务还低。

一个多任务系统, 要避免存在单点通道。所谓单点通道, 就像交通概念中的独木桥, 大量的物流必须从单个独木桥通过, 这是非常危险的。硬件要避免单点, 软件也要避免单点。在应用系统中, 程序、数据库、变量、逻辑通道等, 都有可能存在单点通道。单点通道的存在, 给系统效率及安全带来极大隐患。一方面, 单点使表面是多任务的应用变为单任务应用;另一方面, 万一单点出了问题, 会造成整个系统的宕机。一个好的系统, 一定要尽量消除系统内的单点通道。如变量, 除静态变量 (仅参照用的变量) 外, 要尽量避免设置全局变量, 特别是绝对不允许设置每笔交易都要更新全局变量 (例如系统唯一的流水号等) 。如应用上确有需要此类变量, 可用技术手段把唯一的全局变量变为n个 (如变量预分法、加头缀法等) 。这n个全局变量, 就成为要更新这个全局变量的所有交易的最大并发数。所以n不能太少, 否则会成为瓶颈, n的数量要大于或等于使用该变量的交易的设计最大并发数。

(二) 模块化

系统的模块化设计是系统设计的一个重要概念。所谓模块化设计, 是把一个复杂的大系统分割成一个个相对独立、较小、功能相对简单的模块。模块的内聚度要高, 即模块要实现的功能不要太多太复杂, 仅把高相关性的功能放在一个模块实现。模块要把仅与本模块相关的数据封装到模块内。访问的外部数据也应该有高度相关性。通过访问有限数据, 完成模块自身的功能。模块之间的耦合度要低, 即各模块相对独立、功能与边界清晰。模块与其他模块的调用和被调用的关系清晰, 与其他模块的接口越标准越好、越少越好、越小越好。

系统的程序模块分割设计, 原则上程序规模小一点好。甚至有专家认为程序的代码行应在数百行内。对于这种要求, 许多人都认为不易做好。但最起码相关性不高的功能不应该在一个程序里实现。否则, 对程序的维护及排错极其不利。

(三) 故障对策

联机事务处理系统设计的一个最重要的方面, 是故障对策。正常的交易, 很多人都能设计。但设计有完善故障对策的应用系统, 则不是一件容易的事。故障对策甚至占了系统设计人员一半以上的精力, 故障对策往往受到忽视, 但故障对策的完善与否, 几乎决定了一个系统的可用性, 尤其在批量交易、外连系统交易上更是如此。

(四) 常用参数

频繁使用的一些控制参数, 应尽量常驻内存, 或利用系统的功能, 制作成内存表, 以提高其存取效率。

(五) 其他

一个好的应用系统设计, 要考虑系统投产后能进行相应的实时或事后监控、跟踪、分析、统计, 以便对系统进行评价、优化。

三、数据库设计

(一) 大型机数据库的发展

银行联机交易系统作为计算机数据处理系统, 其数据组织和访问方式大致经历文件、虚拟顺序存取文件和数据库3个发展阶段。

1. 文件

其中主要有:

(1) 顺序文件 (SAM) 。其中又有定长的、不定长的顺序文件, 只能顺序存取。

(2) 直接存取文件 (DAM) 。主要有相对编成文件。定长, 可顺序存取;可指定记录号 (相对位置) 随机存取。

(3) 键顺序文件 (1SAM) 。是现代文件的雏形, 可顺序存取, 可指定键随机存取。

在上述3种文件中, 若顺序存取, 顺序文件、相对编成文件效率是最高的;若随机存取, 则直接存取文件效率最高, 但键顺序文件是唯一可指定键进行存取的文件。

2. 虚拟顺序存取 (VSAM) 文件

对于文件阶段的键顺序文件, 如有大量记录的追加、插入, 文件就会变得很乱, 必须经常进行文件整理, 否则会降低文件的处理效率。VSAM文件是一种在键顺序文件基础上发展起来的、在某种程度上免维护的一种划时代的文件系统。后面再发展的各种各样数据库, 大部分是建立在VSAM的平台上。

VSAM也包含3种形式:

(1) KSDS。键顺序文件, 主键区引入B+树结构, 可键存取和顺序存取。

(2) ESDS。顺序文件, 如果定长, 可以随机存取;否则, 只能顺序存取。是大部分数据库的底层平台。

(3) RBAS。相对地址文件, 较少用。

3. 数据库

包含层次型数据库、结构型数据库、关系型数据库。数据库的发展, 极大地方便了数据库设计人员及编程人员, 但若仅从效率的角度讲, 对于某些存取方式, 数据库的效率远不如VSAM, 更不用说SAM和DAM。

一个联机事务处理系统, 一旦联机平台 (如IBM的CICS) 和数据库 (如DB2) 是既定, 剩下的系统设计关键是数据库设计。数据库的设计一旦确定, 整个系统框架也定, 且不易进行大的修改。这就要求系统设计人员 (数据库设计人员) 对所用的数据库有深刻的认识, 如数据库内部的逻辑结构、物理结构、相关结构、工作原理、存取方式、排他范围, 以及数据库的特点, 长处是什么, 短处是什么, 哪些是影响数据库的效率或空间的因素, 有哪些约束, 有哪些工具, 其功能如何等。

一个现代的数据库系统, 往往为使用者提供了丰富、方便的功能, 但要了解使用这些“好”功能, 是要付出的代价的。例如某个大的计算机厂商, 在有关数据库的内部资料中, 逐一描述了所提供的每一项“好”功能所耗费的程序步, 并几乎都注明最好慎用这些功能, 以免影响数据库的效率 (如数据场的自动数字检查功能, 记录更新的写后读检查功能, 及不同的应用采用不同的数据库子集功能等) 。

关系数据库其实并不特别适合银行联机事务处理系统。数据库内部表之间的关系越简单, 层次越少, 效率越高。所以, 一些相互有关系的表, 其关系的控制要慎重考虑, 是由数据库系统本身管理, 还是由应用自己管理。由数据库系统来管理, 好处是简单, 但一般开销较大;而由应用管理, 效率较高, 但程序比较复杂。

(二) 次键 (次索引)

通常, 数据库的主键 (主索引) 是唯一键。就是说, 不允许有重键 (例如账号、卡号、身份证号等) 。但是, 选择作为次键的字段, 通常都不是唯一的 (例如姓名、出生日期等) 。所以, 次键一般允许重键, 并采用倒排文件的内部格式。而倒排文件是一种效率不高的文件, 在重键比较多或记录追加时尤其如此。所以必须注意:数据库不宜设立过多的次键。对大规模的频繁追加或削除记录的数据库更要注意, 这类数据库一般只适宜建立主键。如果非要建立次键不可, 一般不超过两个。否则, 会严重影响记录追加的效率, 也会影响数据库整理、重组的效率。

对于那些有许多相同内容的字段, 切忌将其定义为次键。这里有一个很多人会犯的错误, 就是把当事人的姓名作为次键。据报道, 某些常用的名字, 在一个城市里就有几千个。如果应用系统是全国的系统, 那么系统里同名同姓的人就会有几万个。加上一些系统不强调实名制, 当姓名字段没有真实姓名时, 系统自动赋予假设值 (例如空格) 。这样, 相同内容就不是几万, 而是几十万几百万的问题。使用这种索引对数据库进行访问, 效率会非常低。

那么, 如果还是希望用姓名检索数据库, 该怎么办?

一是在姓名后面增加出生年月日。这样重键的几率就极大减少, 据了解, 在国际上使用这种方法非常普遍;二是如果该字段没有姓名, 可以赋予一个特定的假设值, 并且在数据库次键生成规则里指定该值不生成次键。

以上原理可延伸到其他情况。

(三) 排他控制

完善的数据库一般均为应用提供了不同空间、不同程度、不同时效的排他功能。空间:数据库—数据库分区—页—记录;程度:全排他—排他更新—排他参照—共享更新—共享参照—全共享;时效:交易排他—DML排他;要深刻了解各种排他的影响及相互之间的关系。

例如, 某数据库排他的种类及相关矩阵见表1所列。

注:E:全排他;EU:排他更新;ER:排他参照;SU:共享更新;SR:共享参照;S:全共享;O:全共享;□:记录排他;◇:页排他;△:分区排他;X:全排他。

通常, 联机程序应采用的排他范围为页排他, 排他时效应为交易排他。非并行执行的批量程序, 排他应采取最高级别的排他 (如范围应为数据库, 程序为全排他) 以提高效率。

(四) 页

在数据库的物理设计中, 页 (块) 的大小是一个很讲究的问题。一般来说, 块是物理的概念, 页是逻辑的概念。一条磁道可以容纳多少某种大小的块, 一个块可以容纳多少某种大小的记录, 有公式计算。

1. 数据区

页 (块) 越大, 磁盘空间利用率越高, 同一页放的记录数越多, 有利于顺读, 不利于随机读和多任务并发。反之, 页越小 (不应小于一个逻辑记录) , 磁盘空间利用率越低, 有利于随机读, 不利于顺读。所以, 要视数据库的应用性质而定, 不要闭着眼睛使用系统的假设值。

2. 索引区

索引区的页的大小是一个十分复杂的问题。一般数据库的索引区用B+树结构, 页越大, 页内索引越多, 索引层越少, 随机读的效率一般会越高;但页越大, 排他的范围越大, 排他的机会也越大, 这一点不利于多任务并发。一般认为, 在采用索引内存常驻或索引树上层内存常驻的情况下, 应考虑非内存的索引层不应超过3层, 在此基础上索引页越小越好。

(五) 预开记录

对数据库进行存取, 从效率来讲, 一般是参照最高, 更新次之, 删除较差, 追加最差。对于有索引的数据库, 在记录追加时, 其排他范围比想象的会大得多, 这发生在索引页分裂时。根据B+树的原理, 在追加记录时会引起索引页满页, 进而引起索引页分裂, 这个分裂机制可以一直更新到根索引页。这样, 其排他的范围甚至延伸到整个数据库。所以, 数据库记录的追加比更新 (不增加记录的长度) 耗更多的计算机资源。如要避免这种情况, 对于需要频繁追加记录而又要求高效的数据库, 可以用记录预追加的办法解决, 或所有记录都预开空记录, 到了联机逻辑上要追加记录时, 在程序上只对记录进行更新。

(六) 其他

大的数据库要进行分区化;对于非常频繁存取的数据表或数据, 要采取措施消灭热点;要密切监控数据库的使用情况及容量增长情况, 对数据库进行定期的整理和重组。

联机交易处理系统的系统设计(下) 篇8

四、联机程序的设计

许多程序设计员接到程序开发任务时, 马上就坐到计算机面前打开编辑器进行编码, 这是十分不好的做法。其实, 程序的开发分为程序设计、编码、测试等环节。按软件生产的概念, 程序设计是脑力劳动, 程序编码是体力劳动。程序员应根据程序功能说明书的要求, 列出更新条件表, 设计出流程图, 再动手编码。

(一) 程序要做的事情

一般的联机程序, 要做的工作及其顺序如图1所示。

程序工作区的初值设置要用显式、逐一置值的方式, 置值的对象应为基本项, 而非集团项。

读入交易信息的检查是一种彻底的、标准的检查, 其中包括物理检查、逻辑检查、相关性检查。最终目的, 是尽早发现错误的输入数据, 且绝不允许联机程序因输入数据的合法性有问题而导致非正常终了。

在系统设计时, 要把整个系统的所有内存表资源、数据库资源按某一顺序排序;再把每个数据库资源 (如某一个表) 内的各种键 (主键、次键) 按某一顺序排序;还要把每个数据库资源 (如某一个表) 的内部记录按某一顺序 (如按键的升序) 排序。程序在有实质动作 (如更新、写) 之前, 要把相应交易所要存取的上述资源进行事先读取。并且, 任一程序均应严格按照上述系统设计的顺序, 依次读出其所需的全部表、数据库的相应记录。

特别要指出, 如果某些程序在某些交易中, 需要存取某个表、某个数据库中不止一条记录, 则要按事先约定好的键顺序、记录顺序依次读取这些记录。只有严格按照上述规定, 才能避免程序之间的死锁。同理, 对于被调用的子程序、公共模块, 也要有一个统一的调用顺序。

在应用程序逻辑允许的情况下, 占用资源次序的原则是:

先读不排他资源, 再读排他资源, 以减少排他占用时间;

先读排他范围小的资源 (如本柜员、本终端表) , 再读排他范围较大的资源 (如网点表) , 最后读全局资源 (如系统表) , 以缩小排他影响范围;

读一个资源检查一个, 及时发现问题从而及早终止程序, 避免无效读, 以消除资源的无效占用;

影响范围特别大而又必须早参照的数据, 可以考虑第一次先不排他读出参照, 当发现需要更新时, 再在最后把它排他读出, 以减少排他占用的机会和时间;

一个交易所需存取的控制表、数据库越少越好, 最多不应超过几十个。而对同一数据库, 若是动态的更新读, 所读记录也是越少越好, 最多不应超过几十个;若是不排他顺序参照读, 所读记录数不应超过100个。否则, 会影响程序的效率, 进而影响整个系统的效率。如果超出上述指标, 应检讨程序的设计方案。

若某种联机业务确需一次存取大量记录 (如批量记账或查找) , 可通过技术分批或用多个交易完成, 从而把一个程序所要存取资源的数量限制在上述范围内。

除内存表外, 不允许对数据库进行大量的非键值存取, 除非确认该非键值存取的实际I/O数限制在数十个之内。

对控制表、数据库的数据检查, 主要是各种合法性、限制的检查。

程序要调用流程外的子程序, 不管是内部调用、外部调用还是系统调用, 下一语句一定是检查调用返回码, 以确认调用的结果。如果正确就往下走, 出错了就转到错误处理流程。

以严密的判断确保回滚 (ROLLBACK) 的最小化。一个设计完善的程序, 仅在程序已经对数据库进行实际更新后发现出错, 才把回滚处理作为不得不采取的对策。请记住:ROLLBACK其实是让系统对程序以前已做的动作做出回滚, 其动作会带来额外的系统开销。

(二) 程序的结束

程序的结束有3种状态:

正常结束, 释放资源;

在发出第一个改变数据库数据的命令之前, 发现错误, 则对外发送出错代码, 释放资源;

在发出第一个改变数据库数据的命令之后发现出错时, 除了要进行交易恢复 (ROLLBACK) , 以保证数据的一致性外, 还要特别注意:一是尽量把出错信息记录下来, 二是转到故障处理程序, 以完成一个交易本应完成的一些逻辑动作 (如输出处理有误信息、释放资源等) , 否则, 会造成通信或进程死锁。

出现上述问题或者更严重的错误, 作出相应处理后希望还能够取得有关DUMP信息, 可以发出ABEND命令, 把非正常结束控制交给系统。

程序的错误代码要详尽, 起码应有如下内容:

出错程序名、交易名;

如果是I/O错, 应有出错资源 (如文件、表) 名、动作 (如读、写) 代码、键值;

如果是接收、发送错。应有出错对象名 (如终端逻辑、物理名) ;

错误描述 (错误代码) 。错误描述 (代码) 应面向用户 (操作员) , 不要用技术性太强的专业术语。

要恰当地定义程序的超时时间, 一般可以定在数秒之内。当程序的运行时间超过所指定的超时时间, 系统会让程序非正常终止, 以及时释放程序占用的资源。太长的超时时间会占用大量的机器资源, 从而大大降低机器的效率。如果程序设计不好, 还容易引起大量死锁, 直到机器死机。

(三) 程序的架构

一个好的程序要做到高内聚、松耦合, 特别是要落实程序之间的松耦合。通常, 联机程序在进行交易请求信息的输入、相关数据库的访问、交易结果信息的输出时一定与外界有信息交换。这3个方面的外连, 均可通过外部接口对外、内部接口对内、中间加数据转换逻辑进行隔离。

程序架构如图2所示。

从图2可见, 我们编制一个程序 (这里叫子程序) , 不仅定义了与主程序通信的外部输入接口、输出接口以及外部I/O接口, 还在程序内部定义了对应的内部接口。分别通过第3、第5、第7步程序逻辑, 进行外部接口与内部接口的转换。程序的其他处理逻辑使用的都是内部定义的接口数据。这样, 如果外部环境 (主程序、数据库) 变化引起外部接口变化, 而该变化与本程序又没有关系的话, 本程序的主要处理逻辑均不用修改。

上述程序架构, 在一些输入输出信息为非固定格式、非定长 (如ISO8583) 的程序中, 已经普遍使用。

(四) 程序的可读性

为了程序的可读性, 以有利于程序维护, 联机程序不适宜多层大量调用外部纯逻辑功能模块, 特别是有实质性逻辑动作的功能模块。对于一些较标准的逻辑, 可作为拷贝附本 (Copy Book) , 直接拷贝到原程序并指定展开。

程序用的变量名不要用XYZ或ABC之类短名, 要充分利用程序语言的规定, 使用较长的有意义的名字, 以提高程序的可读性。与写文章一样, 程序语句应该尽量简短, 最好一个程序语句只包含一个动词或者一个判断。如果用非文本语言 (汇编、C等) , 每一个程序行均应该有详细的注解。

五、程序接口

计算机程序间的接口, 是指计算机不同程序之间传递的信息及这些信息的交换规范。这些信息交换, 包括在同一台服务器内不同的程序相互之间的信息交换;也包括在同一个系统里不同的服务器上不同的应用通过连接服务器的网络进行的信息交换, 还包括与系统外的系统进行的信息交换。

(一) 系统之间的接口

当与系统外的系统进行信息交换时, 2个系统之间必须商定信息交换的规范。这些规范通常包括通信协议、通信报文等。2个程序只要遵循该规范, 通过规定的信息交互报文进行信息沟通, 就能实现约定的功能。

这里涉及2个概念:一个是通信规范, 通常也叫通信协议;另外一个是报文协议。

通信协议在程序信息交换中是一个比较底层的概念, 例如网络通信协议OSI参考模型、TCP/IP模型等通常在应用层面, 不需要特别关注。

报文协议则是程序需要直接打交道的。当然, 进行信息交换的双方可以约定使用某一方规定的报文协议, 也可以约定一个新的报文协议。但最好是使用业界比较流行的报文协议。例如, 当前国际上与金融行业相关的比较流行的信息交换协议有:EDI (Electronic Data Interchange, 电子数据交换) , ISO8583 (Financial Transaction Card Originated Message Interchange Message Specification, 金融交易卡信息交换格式标准) , SWIFT (Society for Worldwide Interbank Financial Telecommunication, 环球银行金融通信协会) , IFX (Interactive Financial Exchange, 金融数据交换) 等。

通常, 系统之间的信息交换协议选择余地不大, 往往取决于连接的双方系统的条件和现状。

(二) 系统内的接口

在同一个金融系统内, 除了金融卡交易由终端到中后台服务器之间的信息交换还会使用ISO8583协议外, 系统内的信息交换鲜有使用上述通用的信息交换协议。通常都是由程序设计员定制固定格式、固定长度的信息交换接口。这样做的好处是:由于信息交换的使用范围相对小且固定, 需要考虑的因素不多, 接口可以快速定制, 精简明了;程序使用简单, 效率高;这种状况估计在许多金融应用系统里都存在, 但也存在不少问题。

随着应用系统的发展, 系统规模越来越大, 越来越复杂。并且, 整个社会发展也越来越快, 市场对应用系统要求也越来越高, 系统要适应新形势, 与时俱进, 就必须不断修改和完善。这样, 程序接口就成为系统维护的主要瓶颈。

由于接口都是根据具体程序定制, 其粒度比较细。接口的数量快速膨胀, 一些大银行的应用系统, 接口数按万计算, 极大地增加了管理成本。

由于接口是固定格式, 接口与程序呈紧耦合关系。只要应用功能有什么修改, 涉及的接口也要修改, 然后是接口涉及的所有程序也要跟着修改, 不管该功能修改与该程序有没有关系, 工作量都不小。

由于接口是根据不同环境使用不同的接口描述语言, 接口与具体应用环境也呈紧耦合关系, 因此接口的移植、复用不容易。

(三) 面向服务体系结构的接口

解决问题的根本出路在于使用面向服务体系结构的接口。

根据SOA (Service-Oriented Architecture) 的概念, 面向服务的体系结构是一种体系架构组织模型。在计算机应用方面, 它的概念是将不同功能的应用程序 (称为服务) 通过这些服务之间定义良好的接口和协议联系起来。接口是采用中立的方式进行定义的, 它应该独立于实现服务的硬件平台、操作系统和编程语言。这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。

这种具有中立的、没有强制绑定在特定的环境上的接口定义, 可实现服务之间的松耦合。松耦合系统的好处是, 当组成整个应用系统的某个服务的内部结构或局部发生改变时, 其他服务可以无须变化。而紧耦合意味着应用程序不同组件之间的接口与其功能和结构是紧密相连的, 因而当需要对部分或整个应用程序进行某种形式的更改时, 它们相互牵连, 整个系统由于个别修改而显得非常脆弱。

可见, 不同功能单元的应用程序 (称为服务) 之间, 采用中立的方式进行良好定义的接口 (称之为标准接口) 进行互连, 是SOA一个关键的概念。

SOA的服务模块通常称之为构件。构件在提出服务请求、接受服务要求和返回服务结果时, 要采用标准接口。包括:

1. 标准的协议 (语言)

为了能更好支持相对自由格式的不定长的报文, 一般应使用自解释的协议 (例如XML) , 且该协议应被构件提供服务的对象广泛采用。使用自解释的协议, 可以使程序与接口之间实现松耦合。如前面所描述过的, 程序仅需要关心自己需要的东西, 通过接口转换逻辑, 可以把外部自由格式的接口转换成内部自己使用的固定格式的接口, 从而屏蔽掉与己无关的接口变化。

2. 标准的报文

使用上述语言表述的通用的有限种的报文。所谓通用, 指的是在一定范围内被大家广泛采用 (如IFX) 。所谓有限种, 指的是报文种类只有几十个到一百多个, 而不是成千上万个 (如ISO8583, 一共才几对报文) 。

报文通常成对出现, 分别是服务申请报文、服务结果返还报文。一个构件一般只对应有限对标准报文, 一对报文对应一类服务。服务的细项功能可以由报文内的功能码再细分。

在应用系统走向SOA的道路上, 其中最难和工作量最大的是接口标准化。因为这涉及所有接口的梳理、综合、重定义, 然后把成千上万的接口整理为几十到百多个接口;其中还涉及所有程序的改造, 因此可能带来的系统结构的变化。接口标准化一天未完成, 就一天不能满足SOA的最基本定义, 不管应用系统怎么样改造, 都算不上是SOA的系统。

六、外联设计

一个联机系统, 总要与外界其他系统连接。连接的形态一般有2种:一种是主叫连接, 如金卡工程他行卡在本行ATM取款时把处理要求送往他行;另一种是被叫连接, 如金卡工程本行卡在他行取款并由他行送过来的处理要求。

公文处理系统篇9

一、电子公文交换系统的重要作用及现实应用意义

近年来, 随着计算机技术的发展和国内电子政务市场的成熟, 越来越多的政府部门开始部署和实施电子政务项目, 当前, 我国的很多政府部门都用上了OA办公自动化系统, 但这也引发了一些问题, 如电子公文的安全性、单位与单位之间电子公文如何交换、不同单位之间的公文如何进行识别等, 从全国的角度来看, 各个单位之间如何实现电子公文的交流以及电子公文的安全性, 这是关系到电子政务能否在我国成功实施的关键。

电子公文交换系统建立在政府机关专网和政府已有的内部网络环境之上, 连接各区、各委办局已经建立的内部网络办公系统和业务信息系统, 构建覆盖跨部门的传输与交换平台。电子公文交换系统依托CA认证、电子印章、传输加密等技术, 实现安全可靠的政府信息交换, 把全市甚至全国的政府机关各类应用系统联结起来, 发挥更大的作用, 提高办公效率, 推进政务信息化建设。

二、电子公文交换系统的设计与实现

1. 系统开发环境

(1) NET+XML解析器

本文所研究的数据交换平台采用基于.N E T的技术进行开发, .NET是对SOAP技术进行扩展提出的体系结构, 能应用于几乎所有的开发平台。.NET作为当前流行的软件开发技术, XML本身也是面向对象的一种语言, 这两者可以紧密地结合起来。DOM是一种树形的面向对象的解析器, 更加有利操作, 使用起来更加方便, 所以在本系统中采用JDOM组织的JDOM语法解析器。

(2) Oracle数据库

主流的数据库系统比较多, 目前, 市面上使用最多的是ORACLE、SQL SERVER、IBM DB2等。根据系统的开放性、伸缩性、安全性、系统性能、客户端支持及应用模式、操作简便等几个方面考虑, 本文所研究的电子公文交换系统采用的是Oracle 9.0作为系统数据库平台。

(3) Apache应用服务器

涉及到Web服务器的选择, 当前有多种主流的Web服务器, 为了更加广泛的适用于多种操作系统和平台, 选取Apache的应用服务器, 作为进行系统开发的标准服务器, 可以适用于大量业务处理和服务。

2. 公文交换模块的功能设计

电子公文交换系统建设应始终贯彻面向应用, 注重实效的方针, 坚持实用、经济的原则, 尽可能地做到最简便的方法、最低的投资, 实现系统的要求。同时考虑技术先进性和开放性, 确保系统运行的可靠性和稳定性, 更要注意信息的保护和隔离, 并充分考虑以后的扩展和维护。

据此系统设计基本原则, 市政府电子公文交换系统的公文传输子功能模块主要包括:发送、接收、查询、统计等功能。针对数据交换技术的应用情况, 将其中的发送、接收功能, 详细设计如下:

(1) 电子公文制作

本系统采用Adobe公司专门针对Web应用推出的PDF文件格式作为电子公文的数据载体。PDF文件格式适合Web应用系统, 可以直接阅读、打印、修改、可电子签名、支持IE内嵌浏览。压缩的Adobe PDF文件比源文件小, 每次下载一页, 可以在网页上快速显示, 而且不会降低网络速度。

首先, 将发文的基本信息包括文件序号、收稿时间、签发人、承办单位、发放范围、发送单位、份数、密级等信息和电子公文正文用Word、WPS、Excel等数据格式制作好, 然后使用Acrobat软件, 将各种格式的电子文档如Word、WPS、Excel等格式转化成PDF格式。然后设置安全选项, 经加密后禁止复制和更改, 设置为仅可打印。

(2) 公文发送

完成公文发送的功能, 公为三个主要的功能区:基本信息区、接收单位区和上传附件区。基本信息区包括发送公文的基本信息, 如信息重要性、文件标题、内容以及发送时间, 发送时间通过弹出的日期选择窗口进行选择, 避免用户输入错误, 信息内容可以通过内置的HTML编辑器进行编辑。接收单位区通过地址簿可选择添加接收单位, 也可以输入接收单位地址添加接收单位。上传附件区通过选择本机中的任何格式的文件上传到服务器, 一次可上传多个附件, 上传错误的附件可通过删除功能进行删除。填写完成的信息用户可选择发送还是保存此信息, 保存后信息将存放到草稿箱中, 等待以后修改后再次发送。

(3) 文件夹管理

各个文件夹由同一个页面实现, 通过传送不同的参数显示不同的信息箱, 包括发件箱、收件箱、草稿箱、垃圾箱、网络存储和政务文件分类。通过发件箱和收件箱可查看到信息的详细信息, 通过草稿箱, 可重新打开信息的发送页面, 进行再次发送。通过垃圾箱, 可还原或彻底删除信息。通过网络存储, 可实现网上存储文件, 节约本地资源。通过政务文件分类, 我们将可以在平台内公开的文件分成不同类别, 点击即可浏览。

(4) 公文管理

点击收件夹选项, 可进入公文接收管理页面, 点击文件主题即可浏览公文信息。用户也可以进行文档及其内容的全文快速检索。

(5) 系统管理

包括用户管理、使用空间管理、系统监控、系统管理员、文件群发和文件列表管理、数据的备份恢复、日志等功能管理。

公文流转系统分析篇10

随着我国进入WTO，各种环境都在发生重大变化。随着体制改革和政府职能转变的深入，迫切需要有一个高效的工作环境，落后的信息处理模式和办公方式，已越来越不能适应形势的要求。到目前为止，政府信息化项目一直是遵循着这样的主线纵深发展的:内部的办公自动化—部分职能管理部门的业务处理电子化。世界各国积极倡导的“信息高速公路”的五个领域中，“电子政府”被列在第一位，可见政府信息化是社会信息化的基础，而公文流转是政府信息化的基础。任何停滞都意味着消亡，唯有不断突破固有模式与规模，才能领先未来。政府、企业中办公自动化同样要跟上时代的步伐，故公文流转也日益得到重视。

公文流转系统究竟应该涵盖哪些业务，如何设计一个较为完善的公文流转系统软件，这就是本文所要探讨的问题。

1 公文流转概述

以计算机及网络为标志的信息技术的迅速发展引起了世界各国的广泛关注，21世纪是网络经济时代。随着经济全球化、网络信息、电子商务的高速发展，企业急需一种高效、便捷的基于互联网的办公平台以适应时代发展的需要。公文就是各部门实施领导、处理公务的具有特定效力和规范格式的文书,一般分为内部公文和外来公文。而公文流转就是指从公文起草、请办、批办、传阅、签办、办理、催办、会签、下发、归档、查询、一直到统计这一系列流动过程。一般的公文流转流程主要分为四个公文处理过程，它们分别是:收文管理、发文管理、案卷管理、文件处理统计。而公文流转系统又主要分为两个版本:分别是企业版和政府版。众所周知，公文流转是办公自动化的重要组成部分。办公自动化(OA,Office Automation)，是70年代中期发达国家为解决办公业务量急剧增加而对企业生产率产生巨大影响问题的背景下发展起来的一门综合性技术。

2 目的

编写本系统设计说明书的目的是阐述公文流转系统的总体设计方案，重点说明本系统的解决方案、软件的结构、数据库建设方案以及采用C#和ASP.NET编写B/S结构的公文流转系统的重要参考资料及采用该系统所需系统安全性的解决方案。

Windows NT操作系统是微软公司推出的网络操作系统，它是一个伸缩性极强的网络操作系统，从INTELX86系统到大型的DEC Alpha服务器都可使用，使你在选择计算机时有更多的选择。它在运行时有多个线程，从而可支持功能更为强大的应用程序，同时通过向操作系统和应用程序提供分离的内存空间以防止数据冲突又确保了系统的稳定性。它的抢占多任务方式使操作系统能为每个应用分配足够的处理时间。它与NOVELL公司Netware不同的是，它既是一个网络操作系统，又是一个个人计算机操作系统，类似于UNIX，通过将网络功能嵌入操作系统，Windows 2000 Server将网络管理和基本操作系统完美地结合起来，并且使网络易于使用和管理。

数据库主要用来存放数据。就目前主流的数据库来看，主要是采用Microsoft SQL Server或Oracle。Oracle是一个安全、可靠的并且支持面向对象设计的数据库系统。

3 系统解决方案

本系统采用的系统模式结构是客户/服务器模式——C/S结构。即有一台计算机作为数据库服务器用来提供数据和服务，若干台计算机作为客户机用来向服务器请求服务和数据。

该模式的特点是由客户和服务器两者共同完成对应用程序和数据需求的处理。即讲一个应用分成若干部分，由客户和服务器分别执行、协同工作。这里，在服务器上配置的是一个数据库系统，如Oracle、SQL Server等。由客户负责向服务器发出“应用和数据请求”，服务器根据请求的内容来完成应用处理和数据操纵，然后将处理结果返回给客户。由于在采用数据库服务器模式时，对应用的处理和数据的操纵，主要是利用服务器来完成的，因而显著地改善了服务质量。

客户/服务器模式具有一系列的优点:第一，数据分布存储;第二，数据的分布处理;第三，友好的用户界面;第四，易于改编应用软件。由于这些优点从而使该模式成为信息处理系统和网络操作系统的主要模式。当然，该模式也不可避免的存在着一些不足之处，这主要是其可靠性和瓶颈问题。我们可以采用冗余技术来提高系统的可靠性，减少每个LAN的客户机数目，来防止出现“瓶颈”等。

4 系统需求分析与设计

本公文流转系统包括五大模块:系统管理、发文管理、收文管理、督办管理、公文查询等。对于不同级别的用户有着不同的权限，我们将权限分为系统管理员权限、审批人权限、拟稿人权限、普通操作员浏览权限。对于系统管理员拥有对系统配置的权限，建立用户、分配权限;审批人拥有审批权限、督办权限、查询权限;拟稿人拥有拟稿的权限、督办权限、查询权限、发文收文权限;普通操作者只有浏览和查询的权限。

(1)系统管理模块

公文有着固定的格式和一般的操作流程，处于不同管理级别的人对于公文有着不同的操作。因此，此模块只有系统管理员拥有权限，由系统管理员来建立用户，分配权限。

(2)发文管理模块

包括拟稿人起草拟稿、部门领导审批人审稿、单位领导会签、签发文件、批阅流转和自动生成发文号等。在上述发文的整个形成过程中任何人对文件的修改均记录在案，可以打印出修改人和修改时间，可实现对文件的密级区分、管理以及相关操作、应用人员的权限设定和控制。

本单位要对单位内部或者是外单位进行发文时，要用到此功能模块。此模块用于产生公文的文头纸和具体内容，最后由具有审批权限的领导决定此公文的去向，是发、不发还是交由拟稿人进行修订。

(3)收文管理模块

包括收文登录(包括全息信息)、收文拟办(自动形成拟办意见)、收文的查询、批阅流转以及办毕文件的处理，可以接收本单位内部和其他单位发来的文件，并自动登入数据库，减少数据的重复录入，提供方便、灵活、直观的文件批示处理。并且可实现对文件的密级区分、管理以及相关操作、应用人员的权限设定和控制。

本单位收到单位内部或者是外单位的公文时，要用到此功能模块。此模块用于本单位对于收到的公文进行相关的处理。

(4)公文督办模块

政府部门中督办工作是一项十分重要、同时又是十分繁杂和罗嗦的日常工作。督办工作关系到政府部门各项工作的具体贯彻、落实和完成，是政府部门中提高办公办事效率，加强监督管理的重要工作重点。

该模块用于对不同类别的公文办理情况进行监督和催促，使办理部门和个人尽快完成对于公文的办理，以提高公文的办理效率。

(5)公文查询模块