前言：中文期刊网精心挑选了文件管理系统范文供你参考和学习，希望我们的参考范文能激发你的文章创作灵感，欢迎阅读。
文件管理系统范文1
系统建设成为每个形成和保管电子文件单位的崭新且重要的工作内容。然而，在电子文件种类繁多、业务系统架构各异、包括人才在内的专业资源有限的情况下，各单位如何建设合格的系统，逐渐成为当下文件、档案管理领域需要回答的现实问题。本文采用文献研究法和案例研究法，从与业务系统的关系、主导方式、部署方式等角度对ERMS建设的模式进行总结，继而分析其适用性。
一、ERMS和业务系统的关系
一个单位若要建设ERMS，首先要考虑的问题之一就是本单位有多少个业务系统可能产生电子文件，需要加以管理。因单位规模、业务的不同，这个答案的差异性较大。2010年4月，笔者分别走访了北京市地税局和北京市发展和改革委员会，两个单位对此问题的答案依次是50多个和70多个，这还不包括桌面级的应用。事实上，决定启动ERMS建设的单位，其业务系统的数量一般都在几十个左右。
如此之多的业务系统，产生的文件类型、数量、数据结构差异性较大，ERMS的实现方式也不可能单一。笔者曾经在2004年阐述了独立、包含、嵌入等三种业务系统和ERMs的关系，即业务系统和ERMS相对独立，业务系统包含完整的ERMS，业务系统中内嵌ERMS的前端控制模块。国际档案理事会(ICA)2008年颁布的《电子办公环境中文件管理原则和功能要求》，提供了业务系统中产生的文件的管理方案，分别为：(1)在业务系统内部实现文件管理功能；(2)将文件元数据输出到ERMS中，而文件还保存在业务系统中；(3)将文件及其元数据直接输出到ERMS中加以管理。
根据ERMs和业务系统的交互方式以及与之相伴的文件和元数据的存储方式，可以总结出独立式、嵌入式、整合式、互联式四种ERMs建设模式。其特点比较如表1所示。
1.独立式
所谓独立式，就是ERMs相对独立于形成文件的各个业务系统，后者可通过应用程序接口(API)向ERMS输出文件及其元数据，文件及其元数据集中于ERMS保存管理。这种组合模式延续了纸质文件前后端分离管理的做法，对应于现有的组织分工模式，较为通行。在此模式中，ERMS相对被动，被动接收业务系统提交的数据，需要在相应管理制度的配合下，强化业务系统主动提交文件及其元数据的行为。由于向ERMS输出数据的业务系统可能有多个，往往需要定制开发多个接口才能完成数据的顺利交接，这将增加协调和实施的成本。
2.嵌入式
所谓嵌入式，是指在业务系统自行开发完善ERMS的功能，在业务系统内部实现电子文件的捕获、维护和处置。换句话说，ERMS嵌入业务系统中成为其子模块，比如财务管理系统、人事管理系统中自带的文件(档案)管理模块，嵌入到邮件系统中的电子邮件归档管理软件等。在此模式中，包含ERMS功能的业务系统，往往只能管理本系统产生的电子文件及其元数据，适用于业务文件数量大，对于业务系统依赖性强，业务流程较为规范的情况。这种模式有利于特定业务文件的专业化管理和利用。但是，如果一个单位仅采用该模式，那么就会在整体上造成文件信息的分散，若需开展全局性的利用，则还须借助于其他系统。
3，整合式
从某种意义上，可以将整合式理解为独立式和嵌入式的结合，整个ERMS分为两大部分，一部分嵌入到业务系统中，实时捕获文件及其元数据；另外一个部分则集中保管维护文件及其元数据。这种模式兼具了独立式和嵌入式的优点，既能捕获来自多个业务系统的电子文件，又能集中机构的信息资产，并以统一的方式加以维护和开发利用。目前构建在内容管理平台(Enterprise Content Management，ECM)上的ERMS(EDRMS)大多采用该模式，对业务系统和ERMS之间的集成要求较高。
4.互联式
互联式强调的是ERMS和业务系统相互访问数据的便利性，两者可以相互独立，也可以像整合式一样将部分ERMs功能模块嵌入业务系统中。其区别在于整合式集中保管所有的电子文件及其元数据，而互联式的ERMS仅保存文件元数据，文件则仍然保存在业务系统中，ERMS负责维护元数据和文件之间的关联，始终保证二者之间的互联。这种模式适用于业务文件对原系统环境的依赖性强的单位，通常需要业务系统提供访问接口，以便从ERMS查找利用文件。
二、ERMS建设的主导方式
大多数单位从市场上购买产品而非本单位自行研发ERMS，根据主导市场采购和系统实施的力量的不同，ERMS建设模式也可以划分为用户引导型、厂商引导型和上级主导型。其特点比较如表2所示。
1.用户引导型
所谓用户引导型，是指ERMS建设单立，即用户单位在市场采购和系统实施扮演主导角色。这样的ERMS建设单位，往往用有“明白的用户”，即充分了解本单位业务特点、文件管理需求、IT环境、管理规范阳管理文化的专业人员，他们对于电子文件管理方法和要求有清晰的认识，能够主导ERMS建设的方向，在与厂商的谈判、沟通，产品二次开发以及方案验收的过程中，处于主动的位置，用户参与ERMS建设的程度较深，系统开发周期相对较长。用户引导型的系统建设方式，有助于保证系统满足用户单位的个性化需求。因用户水平的不同，ERMS实施效果可能存在差异。
2.厂商引导式
所谓厂商引导型，是指产品提供方，即厂商在市场采购和系统实施扮演主导角色。很多单位没有贯通文件(档案)管理和IT管理的复合型人才，故而被动地选择厂商引导型的建设方式。由厂商提供包括业务咨询、工作规划、制度建设、软硬件集成等全方位的解决方案。采用该模式的用户单位，系统实施周期短，见效
快，同时也面临个性化需求未得到满足的风险。厂商的系统实施经验和能力在很大程度上决定了其系统建设的质量。
3.上级主导型
所谓上级主导型，是指ERMS建设单位只能选用上级主管部门指定或者统一采购的产品。这里的上级主管部门包括两类，一类是横向的档案行政主管部门，另一类是纵向的行业主管部门或者企业集团。如加拿大安大略省也通过统一采购程序，指定了省政府机关ERMS唯一的产品供应商Opentext。我国也有很多地方、行业系统通过行政手段指定特定政府机关采用一定的档案管理软件。
若上级主管部门指定产品质量较高，那么该模式则有助于横向或纵向水平上的系统的规范化建设和信息的共享。该模式最大的风险就是上级主管部门指定产品质量可能存在缺陷，此外，还可能存在难以满足用户单位的个性化需求，对于用户单位既有系统建设投资保护不足等缺点。若试图主导下级单位ERMS建设的主管部门不止一个，指定的ERMS产品不止一个的话，则对下属单位而言是一场灾难。笔者了解到上海某区财政局，出于各种原因分别拥有3个办公自动化系统和3个档案管理系统，且同时在用，造成资源浪费、数据分散、数据不一致等。
三、ERMS的部署方式
以上两种视角的模式分析，均站在个别ERMS建设单位的立场。下面将立足于全局，从ERMS的部署方式来分析三种ERMS的建设模式，分别是分散式、集中式、分布式。不同的部署方式下，系统及其中数据的受控程度有别，其特点比较如表3所示。
1.分散式
所谓分散式，即各单位自行部署ERMS，包括自行采购、安装、运行和维护系统等。这是目前主流的ERMS建设模式。该模式对每个单位的文件管理、IT管理资源提出较高的要求。在这种模式下，控制各单位文件管理规范化的手段只能是由主管部门制定相关标准。
然而，并非每个单位都有足够的文件管理、IT管理的资源；集中专业化的人力、设备、软件资源，为更大范围内电子文件管理工作提供支持，是社会发展和IT建设发展的基本要求。随着系统建设集约化程度的提高，集中式和分布式依次出现。
2.集中式
所谓集中式，即由一家单位统一规划、采购、安装、运行和维护一定范围内的多家单位的ERMs，软硬件集中部署，数据集中存储。目前的技术条件下，系统维护单位可以借助于云服务的方式向各个用户单位提供ERMS存储、平台和(或)应用服务。集中式的系统建设模式，必然伴随着系统维护方和使用方之间服务模式的改变。
根据部署范围的不同，集中式主要分为以下两种情况。
(1)行政区划范围内的集中式。即一定行政区划范围的机构，通常是政府机关，统一采购实施ERMS。比如杭州市档案局于2009年年底启动的“杭州市电子文件中心”项目，即采用集中式的系统建设模式。不同于国内其他很多地方政府电子文件中心，该局籽工作任务的重点放在为各党政机关统一建设、部署ERMS上，各单位通过集中部署在杭州市档案局的ERMS，管理本单位的电子文件及其元数据。也就是说，各单位ERMS建设任务集中于档案局。这意味着数字环境下的档案局面向各立档单位的服务功能得以拓展，除了提供政策规范、业务指导和永久文件保存的服务之外，还提供系统建设、部署和维护的服务。据笔者了解，香港、澳门等地都在考虑这种基于云计算的集中式建设模式上。
(2)行业范围内的集中式。即面对某行业范围的机构集中部署同一套ERMS，包括政府行业管理系统内集中部署和企业集团系统内统一部署的情况。前者如北京市地税局，该局自2010年开始建设面向全市地税机关的电子税务申报原件管理系统，该ERMS内嵌于产生电子文件的核心征管系统，与核心征管系统数据大集中的建设模式相匹配，ERMS也将采用集中式。后者如中石油天然气股份有限公司，该公司2006年建成了面向中石油机关和所属单位的统一的ERMS，该ERMS内嵌于办公自动化系统(OA)，所有电子文件服务器都部署在中心站点。根据笔者的调研，由于内嵌于OA的ERMs主要只能管理来自OA的电子公文，所以中石油自2009年启动整合式的综合档案管理系统建设，同样采用集中部署的方式。
集中式最大的挑战有两个：第一，系统维护方的服务能力问题，系统维护方应保证系统和数据的完整、安全和可用，这需要恰当应用数据中心建设和维护的新理念和新方法。第二，不同用户单位个性化的应用需求问题。很多单位之所以将嵌入式作为集中部署ERMS的起点，就是因为采用嵌入式的用户单位，其业务系统是统一的，这就极大地削减了业务系统异构而给ERMS的统一存储和管理带来的困难。基于同样的原因，杭州市档案局尽管部署的是独立的ERMS，不过在项目一期，选择了采用统一OA的13家试点单位，先行完善了OA，为二期ERMS的开发奠定了基础。
3.分布式
分布式可以理解成集中式和分散式的综合。仍然由一家单位统一规划、采购、监管多个单位的ERMS，但是由于地理、安全、利用等方面的考虑，所有数据并不采用大集中的存储模式，部分单位的ERMS可能需要部署在本地，数据也存放在本地。相比集中式，分布式更为灵活，更容易满足个别单位的个性化需求。但是，总部对于分布于本地的系统、管理流程、数据的控制力度就会下降。为实现全局性的信息利用和信息同步，则需要耗费额外的工作量。
四、模式选择
任何一个形成、管理和利用电子文件的单位，首先需要判断本单位是否需要建设ERMs这样的专业软件，不是每个单位部需要以独立软件的方式来管理电子文件。如果确需建设ERMS，那么至少需要从业务系统以及业务文件的特点、管理人员的专业化程度、本单位所处政策环境等方面加以分析，从而决定ERMS的建设模式。
文件管理系统范文2
关键词：云存储；智能手机；文件管理；云实例；能量；带宽
中图分类号：TP315
文献标志码：A
文章编号：1001-9081（2016）11-3050-05
0 引言
随着移动互联网技术的发展，智能手机已经成为当前最具革命性的设备之一。根据Nielsens 2014年3月的报告，美国消费者智能手机普及率约为70.4%[1]。如今智能手机已经无缝融入到人们的日常生活中，其角色远超移动电话范畴。本文主要研究近期兴起的一项技术，即智能手机的云存储服务应用。一般而言，每个用户在云中拥有一定的远程存储空间，通过互联网可从不同设备访问文件。这些云存储服务可保证同步性和文件的一致性[2]。随着智能手机的普及，用户不可避免地需要将云存储服务和他们的智能手机结合起来。然而，由于智能手机自身存在限制，用户和开发人员遇到一些困难。首先，与常见台式计算机和笔记本相比，智能手机的存储空间有限；其次，蜂窝网络的带宽有限。于是，主要移动网络运营商们往往对数据计划施加约束，这些约束从根本上限制了服务可扩展性的提升； 再次，能耗问题是智能手机用户的关键问题[3]。鉴于这些约束，大多数当前智能手机云存储服务均采用相同的设计原则，即：不在本地存储云中的文件拷贝，因为智能手机没有足够多的空间存放这些文件，而且下载这些文件会消耗大量带宽和电量。相反，默认情况下只在智能手机上存储元数据。虽然这种设计的效率较高，但是制约了应用性能的提升。对于智能手机用户来说，利用本地拷贝即可轻松完成的部分文件操作（比如压缩文件或将文件传输给其他用户）变得异常困难甚至无法实现[4]。
为此，本文设计了一种基于云实例的文件管理系统（File Management system based on Cloud Instances， FM-CI），帮助智能手机用户提升云存储文件的性能。基本思路是通过建立云实例[5]来帮助用户完成部分文件操作。FM-CI不要求用户存储文件的本地拷贝，且具有如下特点：1）丰富了移动设备可实现的文件操作种类，包括下载、压缩、加密和转换操作； 2）包括一种文件传输协议，支持两个智能手机用户从一个用户的云存储空间传输到另一用户的云存储空间中； 3）为上述所有操作提供安全的解决方案，以便对共享的云实例（即其他用户创建的实例）加以利用。
1 相关工作
云存储问题是目前的研究热点。文献[6]提出了一种基于指纹魔方算法的云存储数据保护机制。该机制通过用户的指纹特征值控制魔方旋转对文件进行加密，再利用门限分割技术将文件分割成小块存储到各个服务器中；需要恢复原文件时，先对各个服务器中的文件块进行完整性验证，找到不少于门限值数量的文件块就能完整恢复文件；该机制保护了云存储用户的隐私数据，同时提高了云存储系统的抗破坏能力和灵活性。文献[7]针对采用主从式结构的主流云存储系统可能出现的性能瓶颈和可扩展问题，提出了基于Kademlia的负载均衡云存储算法。文献[8]针对如何选择云存储系统中可以关闭的节点集合问题，设计了基于辅助节点的贪心算法，并针对异构云存储系统的能耗优化问题，提出了面向异构云存储系统的能耗优化贪心算法。然而总的来说，以上的算法都需要较大的存储空间，因此并不适用于智能手机，另外智能手机对于能耗的要求较高，这也进一步制约了这些算法在智能手机中的应用。
为了克服以上方案的不足，文献[9]提出了一种用于智能手机的云存储系统ThinkAir。该系统在当前运行时间系统之上部署了一种Android框架。它们还提供了一种动态运行时间系统，可确定某个应用组件该运行于移动设备上还是远程服务器上，有效降低了移动设备的计算量，节省了手机存储空间。除了卸除计算机量外，文献[10]提出的SmartDiet方案还试图将通信相关任务卸除给云端，以便节约智能手机的能量。文献[11]分析了当前系统架构及存储协议可能导致的性能瓶颈，针对基于云P2P网络的智能手机提出一种高效的反恶意软件工具CloudShield。然而总的来说，以上方案都较为片面，其中文献[9]主要关注如何降低移动设备的计算量，而文献[10-11]则关注如何降低移动设备的能量。针对以上不足，本文设计了FM-CI，在降低移动设备计算量的同时还减少了能耗，帮助智能手机用户提升了云存储文件的性能。
2 云存储服务
本文将Dropbox平台[12]看成是一种典型的服务提供商，下面结合用户应用对其架构和功能进行简要介绍。作为个人云存储市场的主流解决方案，Dropbox基于亚马逊简易存储服务（ Amazon Simple Storage Service， S3）为桌面和移动用户提供跨平台服务。Dropbox采用分层架构：在底层，Amazon S3基础设施提供基本的数据存储和检索接口；中间层是Dropbox核心系统，与S3存储服务进行交互，为更高层应用提供服务；最顶层为正式的Dropbox应用及开发人员构建第三方应用时用到的一组API接口。
为了对第三方应用进行管理，Dropbox为每个应用分配一个独一无二的应用密钥（app key）和应用密函（app secret）。当用户启动一个应用时，Dropbox服务器利用OAuth v1进行认证。当被用户启动时，第三方应用与Dropbox服务器进行通信，以获得一个一次性请求令牌和请求密函。然后，应用利用一次性请求令牌和请求密函形成一个改向链接，并将该链接提供给用户。当访问该链接时，用户将被提醒利用他的Dropbox账号登录，Dropbox服务器将验证他的改向链接及用户登录信息。成功登录之后，服务器将向应用返回一个访问令牌和访问密函，进而允许访问用户数据。
3 FM-CI
本章首先描述FM-CI框架和基于云辅助的文件操作； 然后，重点讨论了FM-CI如何在两个用户的云存储空间之间传输文件，其目标是在完成文件操作的同时，使网络带宽消耗最小。
3.1 FM-CI框架和基于云辅助的基本文件操作
在FM-CI中，每个移动设备关联一个云存储账号。与其他应用类似，鉴于存储空间和带宽消耗约束，FM-CI默认情况下不在本地保存云端的文件。但是，FM-CI在移动设备上维护一个影子文件系统，以存储云端文件的元数据。该本地文件系统基于服务提供商的API接口，且与云存储同步。
FM-CI支持两种类型的文件操作：第1种类型为服务提供商API接口可以普遍提供的基本文件操作，比如文件的创建、删除和重命名；第2种类型为需要云实例提供帮助的复杂文件操作。FM-CI可鉴别用户的操作请求属于哪种类别，进而相应作出处理。第1种类别通过调用常规的API函数即可处理。对于第2种类别，FM-CI将创建一个云实例，然后将文件操作请求转发给实例进行处理。具体而言，本文在FM-CI中设计了如下4种基于云辅助的文件操作：
下载 该操作允许用户直接将文件下载到他的云存储中。在FM-CI中，已知统一资源定位符（Uniform Resource Locator， URL）等目标文件位置后，云实例将获取文件，然后将其上传到用户的云存储中。因此，文件的下载和上传不会消耗移动设备的带宽。
压缩 该操作允许用户对存储于云中的当前文件或目录进行压缩。如果用户设备在本地存储了目标文件的拷贝，则该操作可轻松完成，生成的压缩文件可上传到云存储中。在FM-CI或针对移动设备的其他类似应用中，真正的文件内容是无法获得的。因此，文中设计了一种接口，支持用户根据本地影子文件系统和元数据选择目标文件，然后将压缩操作转发给云实例进行操作。云实例将从云存储中获得指定的文件，对其压缩，然后将压缩文件上传到云存储中。
加密 在FM-CI中，用户可选择目标文件及密码套件，包括加密算法和密钥。加密操作将发送给云实例。类似地，云实例将从用户的云存储中下载目标文件，对其加密，然后将密文发送回云存储空间。
转换 该操作专门针对图片和视频片断等多媒体文件。在FM-CI中，用户在浏览图片时可明确可接受的分辨率，这一请求将由云实例处理。初始图片将下载到实例中并根据用户指定的分辨率将图片转换为体积更小的文件。最后，将转换好的文件发送给用户。
FM-CI通过启动云实例来帮助用户完成这些文件操作。在执行文件操作期间，云实例将周期性地向智能手机发送心跳消息，以汇报进度和状态。智能手机在与云存储服务器和云实例交换控制信息时只消耗少量带宽。
3.2 用户间的文件传输
大多数云存储服务允许用户与其他用户共享文件，但是不支持不同用户空间之间复制文件。然而，用户之间的文件共享无法代替文件传输（制作一份拷贝）。在文件共享时，一位用户对共享文件的操作会对其他用户产生影响。例如，如果用户删除共享文件，则所有其他用户也将失去这些文件。图1表示了不同用户空间之间的文件传输问题。假设携带智能手机且支持数据计划订阅的两名用户相遇，这两名用户均在云端设有存储空间。一位用户（发送方）想将自己云存储空间中的文件传输到另一位用户（接收方）的云存储空间内。本文希望提出一种高效的解决方案，既可为这一特性提供支持，又将消耗的网络带宽降到最低。在传统的解决方案中，发送方可将目标文件下载到自己的智能手机上，然后通过互联网或蓝牙、近场通信（Near Field Communication， NFC）等近距离通信手段将文件传输到接收方的手机上。在接收到文件时，接收方的手机可上传文件或与云存储进行文件同步。然而，这一方法从带宽消耗角度来看效率较低，尤其是当文件较大时更是如此，比如说大量图片和视频片断，因为发送方必须要下载所有文件而接收方必须要上传所有文件。
在FM-CI中，采用如下的设计原则来解决上述问题，即：利用云实例来帮助用户在各自云存储空间之间传输文件。一般来说，云实例启动后扮演中继节点的角色。它从发送方的云存储空间获取目标文件，然后将其发送到接收方的云存储空间。通过这种方式，发送方和接收方的智能手机可以不用保存目标文件的本地拷贝，只当智能手机和云实例/云存储服务器间传输控制信息时消耗一定带宽。然而，在实践中使用云实例这种设计思想存在一定困难，因为发送方和接收方之间没有建立信任。云实例可由发送方或接收方创建。无论是谁创建，对于没有拥有云实例的那一方来说这种方案的安全性都较低，因为云实例需要获得发送方和接收方的云存储安全证书才能完成文件传输。
为了解决上述问题，本文为FM-CI提出一种解决方案，要求发送方和接收方均有云实例。具体来说，通过部署算法1来完成文件传输。假设用户UA试图将文件F（F也可表示一组文件）发送给用户UB。假设Fsrc表示F在UA云存储空间中的位置，Fdst表示UB将在其云存储空间存储该文件的目的位置。算法1给出了文件传输的主要步骤。首先，UA启动一个云实例（IA），将可以访问它的云存储空间的安全证书上传给实例。UA的请求也包括源文件位置Fsrc和中间文件位置URIF（统一资源标识符），以表明在实例中存储F的位置。云实例将利用安全证书来把目标文件F下载到本地磁盘。此时，IA需要允许F被用户UB访问。它首先向UA发送中间文件位置URIF。然后，IA可设置F可被公共访问，或者创建一个来宾账户， 接着设置F的权限以便只有来宾账户可访问它。在后者情况下，作为来宾账户登录所需要的安全信息，比如登录密码或身份文件，也需要返回给UA。然后，UA方的步骤便已经完成。此时，UA需要向UB传达访问F所需要的信息。因为这一通信步骤涉及敏感信息，所以FM-CI采用NFC协议以便使URIF和可选登录信息安全地从UA智能手机传输到UB智能手机。对于接收方来说，UB也开启一个云实例IB，该实例根据URIF从IA处获取F。最后，IB把F上传到Fdst。此时，发送方和接收方均开启一个云实例作为各自的。F的数据传输发生于云实例和云存储服务器间，不会消耗用户智能手机的带宽。同时，访问云存储空间所需的安全证书只发送到同一拥有方创建的实例。因此，FM-CI中两名用户云存储空间之间的文件传输既高效又安全。
算法1 从UA至UB的文件传输。
1）UA开启一个云实例IA；
2）UAIA（蜂窝网络）：UA访问其云存储空间的安全证书，源文件位置Fsrc，中间文件位置URIF；
3）IA从UA的云存储空间中下载F，并将其存储在URIF；
4）UAUB（NFC）：URIF（IA上的文件位置）；
5）UB开启一个云实例IB；
6）UBIB（蜂窝网络）：UB访问其云存储空间的安全证书，URIF，目的文件位置Fdst；
7）IB将F从IA（URIF）拷贝到其本地空间；
8）IB将F上传到UB的云存储空间（Fdst）。
4 基于共享云实例的解决方案
上面描述的解决方案通过开启云实例作为辅助手段，使智能手机用户可以对云端的文件进行管理。然而，在实践中，下面两种问题可能会影响上述解决方案的部署。首先，创建一个云实例会导致较大开销，比如本文第5章实验中这一开销可达15～30s； 其次，开启云实例的成本较高。虽然云服务较为便宜，但是频繁开启云实例仍然可能增加用户的成本。
本章给出了FM-CI的改进版本，通过允许用户相互之间共享云实例来解决上述开销和成本问题。可以这样处理的原因在于：大多数云服务提供商按照一定的时间尺度为实例服务收取费用[5]。当执行云操作而开启云实例时，用户在操作结束时可以不用结束实例。该实例可一直保存到将要额外收取成本费用时为止。例如，假设服务提供商以小时为单位为实例服务收费，当用户开启一个实例并在前5min内结束其文件操作时，该实例可在其余55min内保存活跃状态，且无需额外支付费用。在该空闲时间内，该实例可为其他用户或同一用户的其他文件操作提供服务。在用户间共享实例的这种设计做法虽然提升了性能，但也带来了安全问题。首先，用户将其云存储空间的安全证书上传给其他用户的云实例时，存在一定风险。实例所有者可以监控并获取安全证书，进而获得用户云存储空间的访问权。其次，当向公众开放时，被共享的云实例可能被恶意用户用来发起攻击。
为此，本文提出一种基于受信任服务器的实例共享方案。该服务器既维护了一个包含可被共享的可用云实例的列表，又可对发出实例请求及共享实例的用户进行协调。FM-CI利用如下两条基本策略来解决安全问题：首先，实例的共享方式是开启后台服务并接收其他用户的请求，而不是允许其他用户登录并随意运行程序；其次，当使用一个共享实例时，用户并不上传自己未经保密的云存储账户的安全证书，而是以加密格式上传。如此一来，实例的所有者无法访问租赁用户的云存储空间，且所有用户对共享实例的权限只限于指定的文件操作。
具体来说，本文设计中有3种类型的实体：受信任服务器S；希望对共享实例执行文件操作的用户UA；由另一个用户UB所有的可用云实例I。受信任服务器拥有一个二进制程序P，该程序在共享实例上运行后即可向其他用户提供FM-CI服务。一旦用户（UB）决定共享其实例（I），则该实例将与服务器通信，并转发I的基本信息，比如操作系统、硬件配置和剩余共享时间。服务器需要给出可执行二进制程序P作为响应，可执行程序中嵌入了密钥kP。假设kP受到程序模糊技术的保护，且IB无法从P处获得kP（见图2）。
此外，服务器将周期性地更改kP，并重新编译二进制程序。在接收到P时，I将把P作为一种服务加以运行，并准备好接收其他用户的请求。另一方面，服务器把IB添加到可被共享的可用实例列表中。最后，每个被共享实例I可设置一个调度任务以便在额外收费出现前自动关闭实例。在关闭期间，I将通知服务器S谁将因此把I从可共享实例列表中删除。
发送方UA向服务器S发送一个共享实例请求。在响应中，除了与单用户操作相同的信息外，服务器还会额外发送回一个证书{UA，I}k，该证书是请求用户ID和分配实例I的签名。UA将会把加密后的安全证书、源文件位置（Fsrc）和中间文件位置（URIF）上传给I。然后，UA将会把共享实例I和目标文件的位置（URIF）通知给接收方UB。该消息还附有来自S的证书，以便接收方可验证共享实例I是否合法。接着，接收方UB向服务器发送一个含有UA和I的请求，确认有一个共享实例I为UA提供服务之后，服务器将向UB返回RB和kB，以便UB可按照与UA相同的方式对其安全证书加密。最后，UB向共享实例I上传加密后的安全证书、中间文件位置（URIF）及目标文件位置（Fdst）。
5 性能评估
本章给出了FM-CI在实验中的性能评估结果。将FM-CI部署在支持Dropbox存储服务的安卓平台上，并在Google Nexus智能手机上对其进行了测试。对基于云辅助的操作，文中使用Amazon Web Service（AWS）[5]提供的服务，所有实验在Micro实例上进行。考虑的主要性能指标包括时间开销和带宽消耗。对每种实验配置，本文进行5次独立实验，然后取均值并在本章中给出。
5.1 基本的文件操作
下面首先给出正式Dropbox API接口实现的基本文件操作的带宽消耗情况。在该测试中，利用包含1000个测试文件（每个22B）的“test”文件夹来创建一个新的Dropbox账户。测试的操作包括：1）登录Dropbox；2）创建/删除一个文件夹（在根目录下）；3）创建/删除/重命名一个文件（在“test”文件夹下）；4）进入/离开一个文件夹（“test”文件夹）。
对每种文件操作，Dropbox服务器要求附上安全证书，且通信过程基于安全套接层（Secure Socket Layer， SSL）。如图3所示，登录过程消耗的带宽最多，原因一方面是由于进行验证，另一方面是由于Dropbox API接口不断地获取元数据以便与本地影子文件系统同步或对本地影子文件系统进行更新。创建和删除一个空文件夹需要分别消耗7.3KB和3.9KB，在所有测试操作中的成本最低。创建和删除一个文本文件的情况与前一情况类似。当测试“test”文件夹时，将会导致更多的带宽消耗（15.5KB和11.2KB）。原因是由于该文件夹包括1000个其他文件，一旦文件夹发生变化，Dropbox API接口将重新获取里面列表上的文件。最后，当用户进入文件夹然后离开时，带宽成本（9.7KB）略低于创建/删除文件情况。
5.2 云辅助的高级文件操作
下面评估FM-CI中基于云辅助的文件操作，尤其是文件下载和压缩。首先给出开启一个云实例的开销，然后给出如果有云实例可用时文件操作的性能。用于评估的工作负载包括4组文件：1幅图片（16MB）、5幅图片（83MB）、2个视频片断（63MB和127MB）。
开启一个云实例的开销 选择一天中的不同时间进行了5组测试，每组测试包括5次AWS Micro实例开启操作，当用户可以登录实例时操作结束。开启云实例的开销见图4。总体来说，该操作非常耗时，因为所有的测试场景下实例开启时间均超过15s。在发送完请求后，用户必须要等待较长时间，直到云实例将要准备好为止。在本节其余部分，性能开销不包括实例开启的初始阶段。
下载操作的开销 在该测试中，本文设置云实例下载工作负载中的文件，并将其上传到Dropbox存储空间中。目标文件寄存于某一服务器中。从表1可以看出，上传/下载开销与文件尺寸基本成正比。上传的速度要快于下载，因为使用的实例（AWS EC2）和Dropbox服务（AWS S3）属于同一云服务提供商。总体来说，传输率为12.9Mb/s，远高于通过蜂窝网络将文件下载到智能手机再将其上传到Dropbox云存储空间上。
压缩操作的开销 测试了Dropbox文件的压缩操作。具体来说，文中使用gzip对下载到云实例上的文件进行压缩，然后将压缩后的文件上传到Dropbox云存储空间上。表2给出了该操作的时间开销情况。上传过程正常来说开销最大，其次是下载和压缩过程。FM-CI中该操作的速度较快。例如，压缩1幅图像和5幅图像总共耗时10.4s和38.7s。这两种情况下压缩文件的体积分别为7.7MB和40.0MB。
高级文件操作的带宽消耗 高级文件操作的带宽消耗比较类似，因为只需要传输控制信息。鉴于篇幅所限，只在表3中给出了压缩操作的性能。包括从智能手机传输到云实例的控制信息在内的上行链路成本非常小。下行链路带宽随着文件尺寸的不同而不同，主要被汇报操作状态的周期性心跳消息所消耗。
5.3 用户间的文件传输
在该操作中，实例从发送方的存储空间中下载目标文件，然后上传给接收方的存储空间。当使用共享实例时，与受信任服务器进行通信的额外成本与总体性能相比可忽略不计。表4给出了利用共享实例进行文件传输时导致的时间和带宽开销（发送方和接收方）。在本文部署中，服务器处寄存的二进制程序为4.9MB。
5.4 不同方案的对比
最后，为了进一步体现本文系统的优越性，将本文设计的FM-CI和目前最新的SmartDiet方案[10]和CloudShield方案[11]在时间开销和能耗方案进行了对比，实验结果分别如图5和表5所示。图5给出了上传/下载5幅图片时三种方案的时间开销对比结果，可以看到，无论是上传还是下载操作，FM-CI的时间开销总是小于SmartDiet和CloudShield。这主要是因为FM-CI允许用户互相之间共享云实例，从而避免了系统频繁开启云实例所需要消耗的那一部分时间，因此取得了更好的结果。
表5给出了传输不同负载时三种方案的能耗对比结果。可以看到，随着传输负载的增加，三种方案的能耗都在迅速上升。但总的来说FM-CI的能耗要低于SmartDiet 和CloudShield。这主要是因为SmartDiet 和CloudShield都是将目标文件下载到自己的智能手机上，然后通过近距离通信手段将文件传输到接收方的手机上，当文件较大时，能耗也将激增。而FM-CI利用云实例来帮助用户在各自云存储空间之间传输文件，它从发送方的云存储空间获取目标文件，然后将其发送到接收方的云存储空间。通过这种方式，发送方和接收方的智能手机可以不用保存目标文件的本地拷贝，因此极大地降低了系统能耗。
6 结语
本文设计了面向智能手机的云存储系统FM-CI，它通过利用云实例来帮助智能手机用户对云端的文件进行管理。FM-CI丰富了文件操作种类，且不需要本地的文件拷贝； 此外，FM-CI支持用户间传输文件， FM-CI中的所有文件操作可安全运行于共享实例上。下一步工作的重点是研究面向智能手机的云数据隐私保护问题，进一步提高移面向移动设备的云服务安全性。
参考文献：
[1] LIU S， JIANG Y， STRIEGEL A. Face-to-face proximity estimationusing bluetooth on smartphones[J]. IEEE Transactions on Mobile Computing， 2014， 13（4）： 811-823.
[2] CHU C K， CHOW S S M， TZENG W G， et al. Key-aggregate cryptosystem for scalable data sharing in cloud storage[J]. IEEE Transactions on Parallel and Distributed Systems， 2014， 25（2）： 468-477.
[3] FU Y， JIANG H， XIAO N， et al. Application-aware local-global source deduplication for cloud backup services of personal storage[J]. IEEE Transactions on Parallel and Distributed Systems， 2014， 25（5）： 1155-1165.
[4] YANG K， JIA X. Expressive， efficient， and revocable data access control for multi-authority cloud storage[J]. IEEE Transactions on Parallel and Distributed Systems， 2014， 25（7）： 1735-1744.
[5] NARULA S， JAIN A. Cloud computing security： Amazon Web service[C]// Proceedings of the 2015 5th International Conference on Advanced Computing & Communication Technologies. Piscataway， NJ： IEEE， 2015： 501-505.
[6] 吴昊， 范九伦， 刘建华， 等. 基于指纹魔方算法的云存储数据保护机制[J]. 电信科学， 2014， 30（11）： 110-114.（WU H， FAN J L， LIU J H， et al. Cloud storage data protection mechanism based on a fingerprint cube algorithm[J]. Telecommunications Science， 2014， 30（11）： 110-114.）
[7] 郑凯， 朱林， 陈优广. 基于 Kademlia 的负载平衡云存储算法[J]. 计算机应用， 2015， 35（3）： 643-647.（ZHENG K， ZHU L， CHEN Y G. Load balancing cloud storage algorithm based on Kademlia[J]. Journal of Computer Applications， 2015， 35（3）： 643-647.）
[8] 林伟伟， 贺品嘉， 刘波. 云存储系统的能耗优化节点管理方法[J]. 华南理工大学学报（自然科学版）， 2014， 42（1）： 104-110.（LIN W W， HE P J， LIU B. Management method of energy consumption optimization nodes in cloud storage system[J]. Journal of South China University of Technology （Natural Science Edition）， 2014， 42（1）： 104-110.）
[9] KOSTA S， AUCINAS A， HUI P， et al. ThinkAir： dynamic resource allocation and parallel execution in the cloud for mobile code offloading[C]// Proceedings of the 31st Annual IEEE International Conference on Computer Communications. Piscataway， NJ： IEEE， 2012： 945-953.
[10] SAARINEN A， SIEKKINEN M， XIAO Y， et al. SmartDiet： offloading popular apps to save energy[J]. ACM SIGCOMM Computer Communication Review， 2012， 42（4）： 297-298.
文件管理系统范文3
关键词：报表生成；战斗文件；管理信息系统；安全；数据库
中图分类号：TP311 文献标识码：A文章编号：1007-9599 (2011) 08-0000-00
The Design and Implementation of the Frontier-forces Files Information Management System based on B/S
Hong Sha1, Zu Renquan2
(1.Software college of Chongqing university,Chongqing401200,China;2.PLA 77320 troops,Yunnan666200,China)
Abstract:With the rapid development of information technology,information warfare has been the stage of history,but also the increasing influence of war situation.Border of the level of information technology directly related to the outcome of the war,national defense,security and territorial integrity.In a comprehensive,prepared a detailed document on border management of the fighting on the basis of investigation,developed a LAN environment built on top of the border fighting file management information systems to build a scientific collection,classification, statistics,storage battle file information,document management processing battle daily,easy to use file transfer management flexible and efficient management.
Keywords:Battle document;Management information systems;System security;Database
一、引言
军队信息化是世界新军革的发展趋势，建设信息化军队也是我军在新形势下能有效履行新使命的必然要求。运用现代信息技术促进文件管理工作的发展与飞跃具有重要的意义。当前我国边防部队各级机关使用的信息系统，大部分是2005年以前配发或自行设计的，无论是在技术架构、业务流程处理、数据共享上都难以满足当前以及今后一个时期发展的需要。由于大部分系统使用的是单机版软件，各单位人员在本机录入数据，使用数据，无法同他人共享数据、共同处理业务；同时，由于这些软件设计欠规范、技术落后、接口不标准、平台不统一等，造成了大量的信息不完整及不合时谊的现象。这种情况给全面掌握文件情况，正确分析文件保管现状带来了较大的困难。
本系统能科学采集、分类、存储目前边防部队的战斗文件信息，并能完成对战斗文件的查询、生成报表、查看下级单位战斗文件管理情况等。围绕该系统的功能实现进行研究与探讨。它的设计与实现是一个很复杂的系统工程，是局域网技术与信息系统开发方法的统一。
二、系统分析
（一）功能需求分析
边防部队战斗文件管理信息系统是面向某边防部队战斗文件管理业务部门的军、师（军分区）、团（人武部）、营、连五级的管理信息系统，它的要求比较具体。
首先，各级战斗文件管理业务部门能对收文、发文等进行管理，对收发文数据进行添加、修改、查询、删除，按规定对收发文进行销毁并能查询历史销毁文件情况，对收发文数据进行统计分析并生成报表，对规章制度、业务往来单位进行管理。
其次，统计与报表生成要能根据不同的条件对所有的文件进行查询，能按照时间段、承办业务部门、操作人、发往单位等多种情况进行统计，并能根据统计出的结果由用户决定下载显示页、所有记录还是前100条记录，以便管理者准确了解战斗文件管理工作现状，这是本文主要进行的工作之一。
再次，由于战斗文件管理工作比较高，具有较强的敏感性和保密性，因而系统要对自己的用户进行很好的权限设计，进行科学的管理，只有具有相应权限的用户才能对战斗文件数据进行查询、修改和维护，其它未授权用户无权进行任何操作。
最后，系统除了对战斗文件进行管理之外，还应提供战斗文件管理的一些规章制度。如军内各级对战斗文件管理的相关规定、本单位战斗文件管理的动态、业务部门的一些通知等。
（二）信息需求分析
边防部队战斗文件管理信息系统要真正成为部队战斗文件管理的有力工具，就必须有可靠的数据信息来源，有完整的每份文件的信息资料。首先，要对部队战斗文件管理的组织结构有较全面的了解，战斗文件各个阶段的工作者和管理机构有哪些，职责如何，权限如何分配。其次，要知道文件信息的录入、删除和销毁方法，战斗文件管理的有关规定等。
部队战斗文件管理主要实行首长责任制，由各级政治主官主抓，由司令部门实施，军级由机要处、师级由机要科（办）、团级由机要股、营连级由文书负责落实。战斗文件的分类可按收发文、秘密等级两种方法，详细情况如图1、图2所示。
图1 按收发文分
图2 按秘密等级分
边防部队战斗文件管理工作业务主要包含以下几方面内容：收文、发文、统计与报表、销毁文件、熟习相关规章制度。以上业务皆由各级机要部门负责落实，具体包括：战斗文件的接收与发出，维护收发文数据，统计收发文情况并根据需要生成报表，定期销毁不需要留存的文件，查询销毁历史，熟习相关规章制度。
战斗文件管理工作有其严格规范的工作管理流程，一份战斗文件从收到或发出到销毁过程中的各种信息都要记录在数据库里。以一份上级下发至本级的收文为例：收到文件后，机要部门登记相关文件信息，然后将文件送到相关业务部门并登记接收该文件的业务部门人员，接收时间等要素；在业务保存期间，可以查询、统计该文的详细信息；到了年底回收该文件进行销毁，销毁时登记销毁人、监销人和销毁时间。这些变化都会记录在数据库中。由此可见，战斗文件在收到和销毁状态中的所有业务都会与机要部门、数据库发生联系。
边防部队战斗文件管理信息系统的主要工作流程如图3所示。
图3 收发战斗文件流程
三、系统设计
在对系统进行功能需求分析和信息需求分析后，我们要对系统进行详细设计。
（一）功能模块划分及描述
战斗文件信息管理的主要工作有收发文管理、统计报表、文件销毁、浏览下级、规章制度等。为了既加强系统的安全性，又方便系统用户，系统还需设置登录管理模块。根据以上需求分析，本系统可分为六大功能模块，如图4所示。
图4系统模块图
1.登录管理
管理用户的登录验证。在设计这个模块的过程中，主要涉及两方面的技术：一是3.5平台提供的Login控件使用；二是利用3.5平台提供的成员资格管理API实现用户登录验证。
2.收发文管理
它是整个战斗文件管理系统中最基本的子系统。可以实现战斗文件信息的录入、删除、查询和修改功能，如：进行新文件的录入、系统中文件信息的变动管理。另外，它还提供了灵活的查询界面，可以根据动态的查询组合条件查询到文件的各种相关信息。设计战斗文件信息的添加、修改、删除、查询等功能需要运用数据源的访问和数据显示两个技术。
3.统计报表
根据提供的日期选择控件选择一个时间段或（及）其他限制条件（文件名、业务部门、文件号等）进行统计。统计结果将逐条列出并提供下载报表。报表生成将根据列出的记录生成EXCEL格式统计结果并供用户下载到本地磁盘以供决策者参考。
4.文件销毁
根据业务部门、文件号、传号、时间段等关键字进行灵活多样化的组合查找出要销毁的文件并依时间顺序显示，并可批量登记销毁人，监销人，销毁时间等要素。销毁时间自动填写当前时间。
5.规章制度
该模块主要用于与战斗文件管理有关的规章制度的和浏览。有利于文件管理者熟习相关规定，处理日常业务。
6.系统维护
是系统能有效利用的重要组成部分，包括与本单位相关的来文单位、发文单位的维护以及本单位业务部门的维护等本级管理和系统管理员才能操作的单位标识维护与系统用户管理。其中系统用户维护用于对用户分配权限和进行访问控制，是确保系统数据安全的重要方面。
（二）基于BLP模型的用户权限设计
为使系统的保密性、数据的可靠性、统计的多样性都能得到保障，在充分分析BLP模型性能的情况下，我们提出基于BLP模型的用户权限设计方案来设计本系统的用户权限。本系统用户角色有：省军区、军分区、边防团、边防营、边防连。
为有效管理系统用户，我们对本系统的每个使用单位和每个工作人员分别分配一个单位标识和工号。它们的生成规则如下：
单位代码生成规则：单位级别标识（1位）+所属师级标识（2位）+所属团标识（1位）+所属营标识（1位）+所属连标识（1位），共六位。如表1所示。
用户工号生成规则：单位代码+该用户在本单位的序号（1位），共七位。如表2所示。
表1 各单位标识
单位 标识
省军区 100000
第四军分区 204000
第四分区第二团 304200
四分区第二团一营 404210
四分区第二团一营二连 504212
表2 系统用户工号表
单位 上级单位 用户 工号
省军区 无 1号用户 1000001
第四分区 省军区 2号用户 2040002（第四分区标识为04）
第四分区第二团 第四分区 1号用户 3042001（第二团标识为2）
四分区第二团一营 第四分区第二团 1号用户 4042101（一营标识为1）
四分区第二团一营二连 四分区第二团一营 1号用户 5042121（二连标识为2）
四、系统实现
下面以统计报表和两个模块为例说明系统的实现过程。
（一）浏览下级单位收文信息
统计报表模块是对普通查询功能的拓展和完善，普通的查询功能只能简单的将符合条件的信息显示出来，而统计报表功能除了能统计显示外，还提供灵活的选择将统计出的结果生成EXCEL文件并供用户下载保存到本地磁盘，供领导随时掌握收发文情况，为制定具有针对性的措施提供辅助支持。
该模块融入到了收发文查询浏览、下级收发文浏览、收发文历史等子模块中，由于各子功仅仅是统计数据不一样而已，所以此处仅以收文统计报表为例说明。
在收文统计报表中，当根据查询条件显示出相应的记录后（默认为显示所有的收文记录），可以方便的利用下方的“导出为EXCEL”按钮和右侧的“当前页”、“所有页”、“前面100条”等附加功能，导出显示记录中的当前页记录、所有记录和前面100条记录。实现该功能的算法如下：
public class GridViewExportUtil
{
public static void Export(string fileName, GridView gv)
{
HttpContext.Current.Response.Clear();
HttpContext.Current.Response.AddHeader(
"content-disposition", string.Format("attachment; filename={0}", fileName));
HttpContext.Current.Response.ContentType = "application/ms-excel";
using (StringWriter sw = new StringWriter())
{
using (HtmlTextWriter htw = new HtmlTextWriter(sw))
{
//创建一个包含边框的表格
Table table = new Table();
//include the gridline settings
table.GridLines = gv.GridLines;
//将表头行加入到表格中
if (gv.HeaderRow != null)
{
GridViewExportUtil.PrepareControlForExport(gv.HeaderRow);
table.Rows.Add(gv.HeaderRow);
}
文件管理系统范文4
1．1节点信息处理
系统数据处理模块实现对节点信息的封装/拆封处理、消息应答和收发规则处理以及对数据的过滤与管理。主要完成对节点加入网络的消息、网络管理类消息和节点网络信息的实时处理，确保网络监视和管理的时效性。
1．2节点信息显示
系统显控模块对网络中的节点信息要实时更新显示。网络节点通过对信息的图形化、形象化和逼真化显示，便于网络管理者和网络参与节点直观地了解、分析和判断网内各节点状态。系统将节点信息进行解析后实时显示网内节点的网络责任、指挥控制信息、位置信息、通信状态等信息。
2系统实现
2．1系统与网络
网络是由多个节点组成的，每个节点都配有数据源真实设备和网络监视管理系统终端，每个系统终端又将节点信息处理模块和节点信息显示模块分开设置在两台任务计算机执行。模块之间、终端与数据源真实设备之间均通过以太网进行数据传输，节点之间采用射频网络进行信息的交互，如图1所示。图1系统结构
2．2关键技术
2．2．1节点状态监视原则
网络监视管理系统监视的对象为当前网络内所有的在网节点，掌握各节点的状态变化情况从而动态监视当前网络的运行状态。系统从数据源设备周期上传的节点网络信息中提取出当前在网节点的状态信息，并对在网节点周期性上传的状态信息进行解析分类，然后更新原有的节点状态信息。对超过设定时间长度仍未上传网络状态信息的节点判定为脱离网络，并变更其网络状态予以警示。
2．2．2特殊节点身份确定和转移
网络监视管理系统中需要指定一些特殊节点作为网络中重要责任的担任者。这些节点担任的角色可能是网络中的某种基准或网络信息传播过程中的中转站，不同的角色所需选取的节点具有不同的准则，要综合考虑节点的存在形态(固定节点或移动节点)和节点的传播能力等要素来确认某一节点是否适合担任网络内的重要责任。当特殊责任节点脱离网络后会导致网络的运行障碍，这就要求网络管理者在网络设计中或网络运行伊始就要预先指定替补节点，选取原则应尽量与原角色相似。当网络监视到特殊节点脱离网络后就可以由替补节点继续承担相应的网络责任，维持网络的正常的运行。
2．2．3信息的图形化显示
网络监视管理系统呈现给使用者的显示界面上应对各类节点的信息进行分类显示。数据源设备周期上传的节点状态信息量庞大且内容繁杂，而使用者关心的是一些关键点信息，并希望能对关键点信息进行分类汇总，从不同角度了解当前节点构成的网络状态。除此之外，对使用者关注度较高的信息种类还应进行展开显示，便于对特殊信息的进一步细致了解。
2．2．4注册和身份识别
网络监视管理系统必须通过注册认证才能运行，对每个运行系统的终端绑定唯一的注册码，保证了系统使用范围的确定性。系统的使用对象主要分为网络管理者与网络参与者两大类，对于网络管理者不仅赋予对全网的状态监视权，还同时承担网络的管理责任;对于网络参与者仅有网络查看监视权，无权对其他网络节点进行管理。
2．2．5动态链接库
网络监视管理系统是基于LINUX操作系统开发完成的，其采用QT作为界面开发框架，QT是一个用C++编写的、成熟的、跨平台的GUI工具包，支持动态链接库工程。系统中的节点信息显示就是将其界面以动态链接库的形式嵌入到其他通信软件的界面中。在LINUX系统下的动态链接库编译后生成的是后缀名为．so的到共享库的链接文件，主调工程需要包含动态链接库工程的所有头文件和所有到共享库的链接文件后方可使用动态链接库工程里的文件。动态链接库将类的整体作为一个EXPORT进行封装打包，可以把其想象成一个大的信封，信封里定义各种类及函数，但是它的初始类型只作为一个大的容器，不具有QT的基本信号槽机制和事件触发机制。
2．2．6多线程通信
在系统进行节点信息处理时，需要涉及到多线程通信。在Linux系统中，线程的调度是由内核来完成的，每个线程都有自己的编号，由于在使用线程的软件项目中，总体消耗的系统资源比较少，加之线程间相互通信比较容易，因此采用该方式完成节点信息处理可以提高系统的信息处理速度。QT有一个线程类叫做QThread，一般需要启用多个线程通信时会从QThread继承一个类，并重新实现QThread中的run函数，将其填写所需功能代码。依靠QT的信号槽机制完成子线程向主线程的数据传递，在所继承的线程类里定义一个信号函数，然后让它在run函数中被触发，并且在主线程里定义一个负责接收子线程数据的槽函数，在主线程里对这对信号和槽进行关联，这样信号触发时，槽函数就会响应，相应的就把子线程的数据传递给了主线程。
2．2．7远程信息挂载
一般LINUX系统下的开发流程是在开发机上完成源码开发，编译后将可执行程序通过网口或其他途径拷至目的机上运行即可。但在实际开发中可能存在以下开况:开发机与目的机CPU架构不同;出于保密需求不允许将开发机源码拷至目的机编译。若开发机为X86架构而目的机为PowerPC架构，二者架构不同在开发机上编译后的可执行程序便无法在目的机上运行;在这种情况下若还不允许将开发机中的源码拷至目的机编译生成可执行程序，那么可以考虑的解决方法便是将开发机作为硬盘挂载于目的机，允许目的机访问开发机上的某个指定文件夹，对文件夹内的源码进行编译，在开发机上生成适用于目的机的可执行程序，再由开发机将可执行程序拷至目的机。
3系统监控指标
对网络监视管理系统而言，根据设计的系统监测指标体系，数据处理和评估的内容如表1所示。网络监视管理系统的监视功能可以实时监控当前网内节点的数目，从而可以统计监视网内节点的在网率;系统对在网节点的网内时间长度和它脱离网络的时间长度进行统计;通过对节点状态信息的实时更新监控当前网内节点的实时位置信息和网络责任担任情况，如经纬度、高度等信息;系统对当前在网节点的组织关系实时更新和监控，指挥者可以及时了解各组织结构下的网络节点分布情况;网络监视管理系统在管理功能中主要可以监控的指标是所有网络管理消息的发送情况及网内节点对指令的执行应答情况。
4结束语
文件管理系统范文5
经济组织文件管理具备以下特点：其一，强调核心竞争能力信息安全性。核心竞争能力信息是指反映了经济组织在市场竞争环境中具备的独特优势方面的各种信息。文件作为经济组织管理运作的重要手段，是核心竞争能力信息的主要载体。其二，强调法律证据性。据经济组织自身发展规律和权益维护等总体需要，以及牵涉到整个社会各领域经济利益的有效维护，须强调对文件信息真实性及其法律证据性的高度重视。其三，强调文件的资产管理理念。ISO15489明确指出文件是组织的核心资产。鉴于经济组织极为强调竞争和发展，文件的资产管理及其软实力提升对于组织确立独特竞争优势尤具重要意义。其四，强调文件系统的信息协同管理功能。经济组织尤其注重对包括市场环境信息在内各类信息的及时、动态获取和处理，也强调信息的及时性和即时性，以作决策参考。因此，经济组织十分强调各类系统的协同管理及由此形成的信息综合处理功能。
2公共事业组织
这里的公共事业组织，实质上与我国常称的事业组织虽有一定差别，但大体相当，国际上一般以准政府组织等做界定。该类组织文件管理的特点在于：一是强调法律证据性。除应提供文件证明自身的合法身份和合法运作之外，尚需提供文件证明组织的资金等资源的管理皆为合法，且符合设立该组织的政府组织提出的要求。二是强调社会服务性。表现在：1.政府设立了专门从事文件管理的公共事业组织，如政府文件中心等，面向社会提供近乎免费的优质文件服务；2.其他类型公共事业组织的文件管理一般都提供社会服务，且基本非营利性。三是不强调高效率和协同功能。该类组织文件管理系统在协同管理和绩效方面的要求相对不高。社会团体组织国际上，社会团体组织基本可称作民间组织。该类组织文件管理有自身特点：一方面，强调法律证据性。与公共事业组织相似，该类组织的文件管理强调法律证据性，但其文件作为资金审计的证据方面的作用相对更弱；另一方面，则不强调高效率和协同功能。与公共事业组织类似，该类组织也不强调文件系统与其他管理系统的协同。
3模式优化的维度之二———文件管理要素
文件管理要素的优化具体可归结为3个方面，即管理理念优化、管理手段优化、管理内容优化。管理理念是文件管理的理论和方法基础；管理手段是文件管理实施操作的具体工具和方式；管理内容是文件管理的具体流程环节内容。管理理念和管理手段是为管理内容直接服务的，管理内容则是文件管理的具体实现。
3.1管理理念的优化
管理理念的优化分为2个方面，即管理工作目标的优化和管理工作理论的优化。管理目标的优化可以表述如下：文件管理在基本符合自身发展规律的基础上，还需满足社会组织的整体目标。至于管理工作理论的优化，文件管理可从多角度予以审视，主要涉及到管理科学、系统科学、信息科学这3大学科理论。事实上，这3个学科已趋于深度融合，使得人们对于相关事物的认识逐渐深化，能提供各种高效的可行途径，极大推动着实际工作的发展。因此，要多维多方应用这3大学科理论实现管理模式的优化。
3.2管理手段的优化
第一是传统手工管理手段。早期的文书管理采取的是手工管理手段，甚至在现代机械和计算机手段出现后的很长时期内，手工管理仍然占据着主导地位，直至电子文件的广泛发展，手工方式才逐渐退居其次。传统手动管理手段有很多局限性，如无法从根本上拓展人类体力和精力的不足，等等。纵然如此，该手段仍有某些积极优势，主要在于人类特有的高端自然智能是其他任何工具无法取替的。第二则是信息技术管理手段。该手段是指综合使用现代机械和信息技术的管理手段，不仅形式上日趋多样化，而且功能上更实现了极大提升，其核心是计算机技术。该手段在文件管理领域的优势主要体现为：一、最关键的是有效拓展了人类智力的部分功能。二、基本上解决了人类精力方面的缺陷。该手段的缺陷在于：一、无法从根本上取代人类自然智能的主导地位。二、自身作为高度复杂的技术工程体系，也就给日常维护和后续服务提出了严峻挑战。可见，在信息时代背景下，需要综合应用人工管理手段和信息技术管理手段的各种优势，同时规避各自劣势，实现文件管理手段的高水平和高质量。
3.3管理内容的优化
管理内容存在3个层面，一是系统工作的角度；二是管理工作的角度；三是信息工作的角度。从系统科学的角度来看，无论是传统纸质文件管理还是电子文件管理，实际上都可视作一个完整的管理系统。本文主要从电子文件管理系统的角度就管理内容优化展开探讨。然而，以下的主要理念将完全同时适用于传统文件管理和电子文件管理，仅在技术层面需做一定程度的区别对待。文件管理内容若从系统工作的角度，包括系统设计构建、系统实施、系统评估、升级或换代；从管理工作的角度，包括文件生成、捕获、登记、保存、检索、利用、统计、处置等环节工作；从信息工作的角度，包括文件信息的产生、编码、传递、利用等完整运动过程。一是系统设计构建方面的优化。系统设计构建需要着重完成以下几个子任务：A.系统总体功能需求的前期调研分析和研判，进而形成系统设计构建的总则指南；B.确定系统功能、结构和内容以及予以技术实现的整体架构，同时应突出主要功能以符合系统的主要目标；C.采用合适的系统开发平台工具和编程语言，配以其他可靠的相关信息技术，将系统设计予以完整实现。高质量的文件管理系统设计构建工作是文件管理模式优化的关键，可谓是对整个系统进行全方位的立法工作，因为系统的核心框架和功能体系等关键要素都将在该阶段予以详尽制定和程序实现。二是系统实施方面的优化。文件管理系统实施是系统设计开发的直接目标和具体实现。从实施步骤来说，又可分为调试运行、正式启用2大阶段。正式实施是文件管理系统自身价值的具体实现环节，直接辅助组织开展文件管理工作，并为组织发展带来收益。从系统工作视角，文件管理系统实施的优化实际上就是通过充分应用系统预置的所有功能，促使系统得到最高效的运作，尽可能获得最佳效果。三是系统评估、升级方面的优化。系统后续评估、改进升级或换代工作对于文件管理系统来说同样较重要。对现行文件系统的详尽评估是对系统实施过程的直接展示，将为新系统开发提供翔实资料，甚至实际上可以作为新系统开发工作中前期调研分析的直接参考资料。系统评估改进工作若要实现优化，必须尽量采取先进可靠的高质量评估工具，制定可行的评估方案予以实施。需要从“文件管理功能需求的有效实现”以及“系统的安全高效运作”2个方面去综合审视系统的实际表现，同时评估文件管理对于组织发展实际产生的影响和作用。当评估认为只需对文件管理系统开展持续性的改进升级时，需积极做好后续的改进升级工作。当评估认为需要开发全新系统时，则需积极准备开发和实施新的文件管理系统。
4我国社会组织文件管理模式优化的对策建议
4.1文件管理理念与国际接轨国际公认的现代文件管理的核心理念是以ISO15489为代表的。我国有必要跟进，以进一步促进文件管理理论研究和实际工作，并且开展专业化的文件管理。国际上，文件管理更多的是一种核心业务，且强调构建高水平文件管理系统而非附属于或直接应用档案管理等系统，且强调与其他系统的协同。
4.2强调严格实行标准的规范和遵从
须强调高水平的文件管理标准化工作，推动社会组织应用高水平的文件管理标准，确保文件管理质量。我国至今制定的文件管理相关标准数量很少，且多是针对电子文件管理。仅以国家级标准为例，至2011年底，我国现有文件管理相关标准总计8份，其中6份专门针对电子文件（该数据是以针对文件管理领域的视角统计的，未涉及档案管理领域的标准）。我国正陆续出台文件管理相关标准制订计划，如国家标准化管理委员会于2010年出台了制定7项电子文件管理标准的计划。随着ISO15489国家级采标工作的完成和广泛施用，必将进一步促进相关标准的发展。
4.3重点关注电子文件管理
未来文件管理模式更多将是电子文件管理模式。我国已认识到电子文件管理的重要性，但各类社会组织在这方面仍存在某些问题：一是构建电子文件管理系统的热情虽高，但前期基础性研究较欠缺。二是电子文件管理相关标准较欠缺，规划制定的进度相对较慢。三是没必要强调社会组织电子文件管理模式的统一化。
4.4重视应用现代系统科学理论
信息时代，社会组织文件管理在应用管理科学和信息科学的同时，还需重视系统科学，以构建高质量的文件管理系统，且能与组织内其他系统实现高效的协同运作。
文件管理系统范文6
1．1研究对象
选择2009年5月—2011年5月在我院就诊的门诊病人40例。纳入标准：采用美国风湿病学会1997年修订的SLE诊断标准确诊为SLE病人；经住院系统治疗后病情稳定；需门诊治疗或复查随诊；年龄14岁～45岁；学历：小学及以上文化；有简单网络应用的知识和能力；自愿参与本研究。排除标准：狼疮脑病病人；有精神疾病病人；生活不能自理病人。
1．2研究工具
1．2．1一般资料调查问卷
研究者自行设计，内容包括性别、年龄、文化程度、病程、婚育情况、经济状况等。
1．2．2症状自评量表（SCL－90）
共90个项目，分9个因子和其他。躯体化，共12项，主要反映主观身体不适感；强迫：共10项，反映临床上的强迫症状群；人际关系：共9项，反映与他人相处时的不自在或自卑感；抑郁：共13项，反映与抑郁症状相联系的广泛概念；焦虑：共10项，反映与焦虑症状有关的精神症状及体验；敌对：共6项，主要从思维、情感及行为3个方面反映病人的敌对表现；恐怖：共7项，与传统的恐怖状态反映的内容基本一致；偏执：共6项，主要是指猜疑和关系妄想等；精神病性：共10项，主要是精神分裂样症状项目；其他：共7项，上述因子不包括的、主要反映睡眠及饮食情况。每项均采用5级评分制。本研究利用SCL－90测查SLE病人的心理状况。
1．2．3SLE病人门诊管理信息系统
由我科人员与软件工程师合作设计。软件工程师通过我科人员对其提供的有关专业信息，利用Access程序，建立SLE病人门诊管理数据库信息系统。信息系统的应用部分包括：病人信息管理模块、健康教育模块和随访信息模块。利用SLE病人门诊管理信息系统对SLE病人进行管理。
1．3研究方法
1．3．1调查问卷发放及收集
采用一对一问卷调查。能够独立完成量表者，由其独立完成；独立完成有困难者，协助其完成。调查人员对研究对象不明条目给予解释，保证每条目解释内容的一致性。在管理前及管理后各进行一次问卷调查。
1．3．2管理模式的实施
利用SLE病人门诊管理信息系统进行管理。采集病例及建立管理档案：课题组对病人的信息严格管理，确保病人隐私不外泄。对符合入选条件的病人，护士把采集到的资料输入电脑，分别储存在病人信息管理模块和随访信息模块。评估病人：对病人的资料进行评估，根据评估结果把不同情况的病人进行分类记录。如肾脏损害用“S”标记，血液系统损害用“X”标记，皮肤损害用“P”标记；使用激素治疗后出现高血压用红色“”，血糖高用橙色“”，血脂高用黄色“”标记。标记储存在病人信息管理模块中。根据病人使用激素量、免疫抑制剂使用或具体病情和医生医嘱设置复诊提醒时间。实行护理干预：根据病人信息管理模块中不同符号标记，识别不同情况的病人，给予不同的健康教育处方。健康教育处方根据病人信息管理模块中不同符号标记从数据库中提取导出，可通过Email方式或飞信发送，也可通过QQ传送。利用软件的查询、提醒功能，检索病情改变，2d～7d后需复查或更改用药量或执行免疫抑制剂治疗的病人、两个月未来复查的病人进行电话随访。此工作每周执行1次。随访时不仅和病人沟通，而且与家属沟通。随访内容为相关疾病知识健康教育、心理辅导，为病人争取家庭支持，督促病人按时复诊，严格遵医嘱用药。根据病人的需要及具体情况给予相应的健康教育处方。对需要进行心理辅导的病人则约定时间进行专人辅导。为了方便与病人沟通，除了设立固定的随访电话之外，还有专用邮箱和QQ群，方便病人表达内心感受，也使医务人员能及时采集到病人信息，网络应用能力差的病人予以培训指导，保证每位参与病人能够利用手机短信、邮箱、QQ群这些信息平台传递、获取、分享信息，与医务人员达到互动。其目的主要是对病人用药、饮食、日常生活（包括运动、休息、学习、工作、皮肤护理、口腔卫生方面）生育与避孕、心理等各方面进行长期、系统、有效管理。每次随访及干预内容、时间都记录并输入随访信息模块中储存。按时复诊的病人，每次复诊的临床资料交专管护士处，录入数据库中存档。干预效果评价。通过门诊日志记录，查病人是否按时复诊，3d查1次。未按时复诊的病人，及时追踪原因。电话随访后的病人，1个月后再进行电话回访，主要了解病人是否按医嘱服药、饮食、日常生活（包括运动、休息、学习、工作、皮肤护理、口腔卫生方面）、生育与避孕等方面是否遵循医务人员指导。并把评价结果记录输入随访信息模块中储存，为下一次的评估及干预提供依据。
1．4统计学方法
采用SPSS19．0统计软件进行分析。计量资料以均数±标准差（x±s）表示，干预前后得分比较采用独立样本t检验，以P＜0．05为差异有统计学意义。
2结果
SLE病人应用门诊管理信息系统前后SCL－90评分比较，各因子中躯体化、人际关系敏感、精神病性无统计学意义，其余因子项比较，均有统计学意义。
3讨论
