時間：2022-02-16 23:37:35
引言：易發表網憑借豐富的文秘實踐，為您精心挑選了九篇文件管理系統范例。如需獲取更多原創內容，可隨時聯系我們的客服老師。
>> 基于JSP的網絡文件管理系統的設計與實現 電子文件檔案管理系統設計與實現 網絡管理系統的設計與實現 文件加密系統設計與實現 網絡課程制作與管理系統的設計與實現 面向制造現場的工藝文件管理系統設計與實現 淺談電子文件檔案管理系統的設計與實現 網絡費用報銷管理系統的設計與實現 網絡教學資源管理系統的設計與實現 基于SNMP的網絡管理系統設計與實現 淺談基于SNMP網絡管理系統的設計與實現 淺析網絡監控安全管理系統的設計與實現 網上車輛網絡管理系統設計與實現分析 網絡指紋考勤管理系統的設計與實現 基于Android的網絡問政管理系統設計與實現 網絡在線車輛使用管理系統的設計與實現 高校教材網絡管理系統的設計與實現 基于SNMP網絡管理系統的設計與實現 基于Android的文件加密系統的設計與實現 Windows Mobile文件監控系統的設計與實現 常見問題解答 當前所在位置：lControls;
public partial class AdminManage_Login : System.Web.UI.Page
{CommonClass CC = new CommonClass();
protected void Page_Load(object sender, EventArgs e)
{if (!IsPostBack)
{//產生驗證碼
this.labCode.Text =CC.RandomNum(4); }}
protected void btnLogin_Click(object sender, EventArgs e)
{ if (txtAdminName.Text.Trim() == "" || txtAdminPwd.Text.Trim() == "")
{ Response.Write(CC.MessageBox("登錄名和密碼不能為空！", "Login.aspx"));}
else
{ //判斷用戶輸入的驗證碼是否正確
if (txtAdminCode.Text.Trim() == labCode.Text.Trim())
{//調用CommonClass類中的checkLogin方法，判斷用戶是否為合法用戶
int IntUserIn = CC.checkLogin(txtAdminName.Text.Trim(), txtAdminPwd.Text.Trim());
if (IntUserIn > 0)
{ //該用戶為合法用戶，跳轉到后臺首頁（AdminIndex.aspx）中
Response.Write("window.open('AdminIndex.aspx');window.close();"); }
else
{ //該用戶不是合法用戶，調用CommonClass類中的MassageBox方法，彈出提示框
Response.Write(CC.MessageBox("您輸入的用戶名或密碼錯誤，請重新輸入！", "Login.aspx")); } }
else
{ Response.Write(CC.MessageBox("驗證碼輸入有誤，請重新輸入！", "Login.aspx")); }}}
protected void btnCancel_Click(object sender, EventArgs e)
{ Response.Write("window.close();location='javascript:history.go(-1)';");}}
以上即為我所設計的一個網絡文件管理系統，由于篇幅所限，本文只給出了部分代碼，希望能對大家在進行網絡文件管理系統設計時起到拋磚引玉的作用。
參考文獻：
[1] 陳會安2.0網頁制作徹底研究[M].北京:清華大學出版社,2007.
系統建設成為每個形成和保管電子文件單位的嶄新且重要的工作內容。然而，在電子文件種類繁多、業務系統架構各異、包括人才在內的專業資源有限的情況下，各單位如何建設合格的系統，逐漸成為當下文件、檔案管理領域需要回答的現實問題。本文采用文獻研究法和案例研究法，從與業務系統的關系、主導方式、部署方式等角度對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的建設模式。
關鍵詞：MVC 體系結構 文件管理系統
中圖分類號：TP393 文獻標識碼：A 文章編號：1007-9416（2016）12-0180-02
1 引言
隨著多媒體教學環境的逐步完善，網絡技術的不斷成熟，很多學校都為學生配備了先進的實訓室。實訓室在使用過程中，會生成大量的電子文件，目前文件的主要傳輸手段還是通過優盤等途徑，這導致在實訓室的電腦中傳播大量病毒。依托互聯網環境的文件管理系統能夠有效緩解這一問題，學生通過授權之后登錄系統進行文件的上傳、下載、文件修改等操作。同時文件管理系統極大地拓寬了學生的學習空間，為系統管理人員提供了豐富的管理手段。
2 MVC模式基本原理
MVC模式是微軟公司在.NET框架的基礎上構建的一種開源的，基于測試驅動的web 應用程序編程模型，開發人員利用 MVC和Razor視圖引擎編寫web應用程序。MVC（Models，Views，Controllers）可以幫助開發人員創建數據支持，邏輯處理和用戶界面完全分離的應用程序，使得系統易于維護和擴展，MVC的體系結構如圖1所示。在MVC體系中，模型通常被稱為“業務邏輯”，是真正完成任務的代碼，視圖就是用戶界面，反映數據的變化。控制器控制著模型和視圖之間的交互過程，它決定著向用戶返回怎樣的視圖、檢查通過界面輸入的信息以及選擇處理輸入信息的模型。
3 文件管理系統實現
3.1 文件管理系統體系結構
文件管理系統主要實現對實訓室電腦中存放的大量文件進行網絡端的管理和維護。經過授權的學生可以在web端輸入正確的用戶名和密碼之后登錄到文件管理系統，根據系統按照學號分配的默認文件夾實現對個人文件的上傳、下載和管理等操作。管理人員能夠實現對學生信息的添加和刪除等操作，以及系統文件的維護管理。系統體系結構如圖2所示。文件管理系統主要功能模塊包括用戶登錄、文件管理和用戶管理。其中用戶管理模塊主要包括添加學生用戶、刪除學生用戶、批量添加學生用戶和批量刪除學生用戶等功能。文件管理模塊主要包括文件上傳、文件下載和文件刪除等功能。
3.2 基于 MVC模式的系統實現
3.2.1 Model實體類部分代碼
（1）實體類關鍵代碼
Public class UserModel
{
…… //省略部分源碼
Private string UserName； //用戶名稱
Private string Pwd； //用戶密碼
Private string FilePath； //文件存放路徑
Private string UserType； //用戶類型
Public string userName
{
get {return UserName；}
set {UserName=value；}
}
……//省略部分源碼
}
（2）File實體類關鍵代碼
Public class FileModel
{
…
Private string FileName； //文件名稱
Private string DateTime； //上傳日期
Private string FileSize； //文件大小
Public string FileName
{
get {return FileName；}
set {FileName=value；}
}
…
}
3.2.2 稻莘夢什憷嗖糠執碼
Public class UserDAL
{
//用戶登錄
Public userLogin（string name，string password）
{……
UserModel user=new UserModel（）；
user.UserName=sdr.GetString（0）；
……
return user；
}
}
3.2.3 業務邏輯層類部分代碼
Public class UserBLL
{
…… //省略部分源碼
Public userLogin（string name，string paasword）
{
Return userDAL.Login（name，password）；
}
……//省略部分源碼
}
3.2.4 web層部分代碼
（1）UserLogin關鍵代碼
Protected void btnLogin_Click（object sender， EventArgs e）
{
name=txtUserName.Text.Trim（）；
password=txtPwd.Text.Trim（）；
UserBLL userBLL=newUserBLL（）；
UserModel user=userBLL.Login（name，password）；
…… //省略部分代碼
}
（2）FileUp.aspx.cs關鍵代碼
Protected void Fileup_Click（object sender， EventArgs e）
{
String filename=FileUpload1.FileName.ToString（）； //獲取上傳文件的文件名
String path=server.MapPath（“～/File/”+Session[“userName”].ToString（）=”/”）； // 獲取服務器上保存文件的路徑
…… //省略部分代碼
}
4 結語
本文介紹了 MVC模式基本原理，設計并實現基于MVC模式的文件管理系統。該方法使得完成的系統具有易維護，可擴展的優點，同時提高了系統的安全性。
參考文獻
關鍵詞：OAIS；可信電子文件；電子文件管理系統；體系構建
中圖分類號：TP29 文獻標識碼：A文章編號：1007-9599 (2011) 11-0000-01
System Construction of Trusted Electronic Document Management System
Based on OAIS
Yang Zhi
(China Petroleum,Lanzhou Petrochemical Company,Automation Research Institute,Beijing Project Department,Beijing 100007,China)
Abstract:For the archives,the spread of information technology and development to the new opportunities it brings,but also for document management have a very severe test.The construction of electronic document management system is an extremely complex problem that requires taking into account the technical,legal,institutional and other issues.This article will talk about the credibility of 0AIS based electronic document management system to build.
Keyworde:OAIS;Trusted electronic documents;Electronic document management system;System construction
一、可信電子文件與可信電子文件管理系統介紹
可信的電子文件就是那些完整性和真實性都能夠得到確定的電子文件，與
紙質文件不同的是，電子文件很容易被中途截取和篡改而不會留下任何痕跡，所以電子文件在傳輸和管理過程中都會碰到很多難以想象的問題[1]，并不能完全保證電子文件的完整性。為了確保電子文件的可信性，目前企業或者單位都會使用數字簽名技術來為電子文件保駕護航。當然電子文件的可信性也會隨著各種技術的發展而發生相應的變化，技術更新換代很快，而舊有的電子文件在當時的技術條件下可以確保文件的可信性，但是隨著技術的不斷發展，舊有的技術可能已經被破解，在新的技術環境下已經失去安全保障。此時電子文件是否可信就需要區別地看待，必須進行深入且詳細的研究。
可信電子文件管理系統就是一個能夠起到保障電子文件可行性的管理體系，就是進入此系統的電子文件在經過一段時間的保管后仍然能夠完整地進行輸出，那么這樣的系統就可以稱之為可信電子文件管理系統[2]。一般來說，可信電子文件管理系統需要滿足以下五個條件：首先是其設計和實施必須要符合相關的政策與法規，還有相應的行業標準；其次是即使保存電子數據的設備發生意外或者其他未知變化時，系統也要保證其文件能夠被完整輸出；第三個必須要滿足的條件是系統內部需要設置審計功能，一旦系統內部發生異常，系統需要及時地跟蹤到并盡量阻止異常的發生；第四，系統應該能夠提供多種識別工具，這樣才能增強電子文件的可讀性與真實性；第五，系統有具備各種保障文件可信的功能和機制，以免信息丟失。
二、基于OAIS的可信電子文件管理系統的體系構建
要構建可信電子文件管理系統首先必須要建立起一個可信電子文件庫，這是整個系統的基礎數據存儲設施，也是整個系統運作的核心[3]。可信電子文件庫其實就是保證用戶能對其保存的文件進行長期的、可靠的訪問的文件庫，其基本功能就是要對數字信息進行維護，以保證將來文件可以被方便利用。相應的檔案機構必須要提供相應的經費和人員保證電子文件庫的長期正常運行，這是構建可信電子文件管理系統的基礎所在。
其次要規范電子文件管理的工作流程。以OAIS功能模型為參照，可信電子文件管理系統的主要流程至少要包括文件接收、存儲、系統管理、電子數據管理、文件的保存規劃以及文件的訪問這六個具體功能。所以的這些工作流程都有可能對電子文件可信性產生影響，必須多加小心。囿于篇幅，本文僅僅對文件移交、格式管理這兩個流程進行分析。文件移交過程中最為重要的工作就是要保證文件生成為能夠生成高質量的SIP，也就是要將文件內容與文件的元數據一起封裝。但是文件生成者可能在登記和處理文件元數據時有所遺漏，造成文件管理出現問題[4]。因此在移交過程中必須要保證文件生成者按照特定的格式、標識符以及創建的規則生成SIP，以提高文件移交、系統接收的自動化程度。在格式管理這個工作流程中，由于電子文件的生成格式紛繁復雜，因此檔案館在進行管理時必須對各種文件格式和保存活動進行長期的分析，以確保不會出現潛在的文件信息損失。
第三，電子文件管理系統還需要提供一定的安全服務，構建一定的標準體系，這樣才能確保電子文件不受攻擊。電子文件管理系統需要提供的安全服務包括數據完整、真實以及文件的不可抵賴，這些安全服務對于管理系統來說是不可或缺的[5]。目前我國在這方面中主要采用的是數字簽名技術，在電子文件移交之前就用數字簽名對文件進行認證。
三、結束語
雖然信息技術不斷發展，保證電子文件可行性的技術日益先進，電子文件管理系統的構建也越來越完善，但筆者認為，單單從技術上解決問題并不是根本的解決之道。電子文件的管理涉及到法律與制度，要增強電子文件的可信性，必須要從制度和法律層面加強對電子文件的管理。制度與技術二者結合，才能對竊取電子文件信息的行為進行根本性的杜絕。
參考文獻：
[1]劉越男．提升電子文件管理系統質量的路徑分析[J]. 檔案學研究，2010（05）：83
[2]李宏艷．電子文件管理問題之管見[J]. 黑龍江檔案，2010（04）：44
[3]覃美娟．電子文件管理過程中的幾個問題[J]. 檔案，2006（04）：09
關鍵詞：云存儲；智能手機；文件管理；云實例；能量；帶寬
中圖分類號：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.
關鍵詞：辦公自動化系統 電子文件 管理
高速信息網絡時代，各種信息系統廣泛地應用到人們的工作中，如PDM、ERP等，其中辦公自動化系統（Office Automation，簡稱OA）即是在各單位廣泛應用的一種系統。
一、辦公自動化系統是將現代化辦公和計算機網絡功能結合起來的一種新型的辦公方式
從上世紀80年代起步，經歷了起步階段（個體辦公）、應用階段（網絡信息）、發展階段（知識管理）。OA系統經過多年的發展已經趨向成熟，功能由原先的行政辦公信息服務，逐步擴大延伸到組織內部的各項管理活動環節，成為組織運營信息化的一個重要組織部分。許多單位使用OA系統傳遞信息、處理公文、進行事務管理，極大地提高了工作效率。
OA系統有各項功能，其中最主要的功能之一是公文處理。公文，也被稱為文件，是人們開展管理活動的一種基本方式，也是管理中的重要資源，其對管理的意義重大，有人曾說，辦公即辦文。傳統的辦公模式是以紙質文件、紅頭印章為標志，文件在處理完畢后，其中有價值的，被保存成檔案，成為日后備查的憑證。在OA系統中傳輸處理的公文被稱為電子公文或電子文件。由于利用了網絡，OA系統中的電子文件在處理速度、便捷性等方面有了傳統公文模式無法比擬的優點，有人認為無紙辦公、數字化辦公時代的已經到來。
但是，由于OA系統在設計開發中的問題，OA系統中的電子文件管理存在一系列的問題，包括：OA系統中的安全性問題、OA系統中電子文件與檔案的一體化管理問題、OA系統中的電子文件元數據標準問題、OA系統中電子文件保存格式問題等。這些問題不解決，OA系統中的電子文件就不可能起到檔案的憑證作用，無紙辦公時代也不可能到來。國家檔案局推薦的管理方式仍然是“雙套制”，既要保存OA系統中的電子文件，又要把OA系統中電子文件轉化為紙質文件保存，檔案管理人員的工作量不但沒有減少，反倒增加了。
因此，從檔案管理、電子文件管理的角度來看OA系統中電子文件處理的需求特點、功能，提出適合檔案管理的OA系統的模式，完善OA系統在電子文件管理方面的功能。不僅在電子文件管理理論上要有所創新，而且對于OA和其它信息管理系統中電子文件管理都具有重要參考應用價值。
二、國內外檔案學界對于電子文件的特點、電子文件管理的原則、電子文件管理系統（ERMS）開發方面不僅有系統的研究，也有一些實踐
OA系統和電子文件管理系統有不同的特點，將OA系統和電子文件管理系統進行分析比較， OA系統在電子文件管理方面的功能要求，需進一步改進現有的OA系統的電子文件管理功能。
國內外的檔案學者普遍認為，紙質文件是穩定的（stable）、永久的（permanent）、靜態的（static）、消極的（inactive）、固定的（fixed）、嚴格的（rigid）；而電子文件是不穩定的（unstable）、非永久的（impermanent）、動態的（dynamic）、積極的（active）、交互式的（interactive）、流動的（fluid）、可變的（transformable），電子文件的這些特性導致了記錄方式的重大革命，傳統紙質文件的管理理念、模式、制度、技術、方法等都無法管理電子文件。電子文件在給我們的工作生活帶來極大便捷和效率的同時，也產生了許多難題和嚴峻挑戰，包括真實性挑戰、真實性挑戰、長期保存挑戰等，要想使各類系統中的電子文件符合檔案管理的要求，必須樹立全程管理、前端控制、風險管理的理念。
在OA系統方面，國內外的學者認為基于網絡的OA系統經歷了多年的發展，已經日趨成熟，它不僅是處理信息和事務的工具，還應該是知識管理的重要軟件。在軟件的開發中，不斷應用一些新技術改造OA系統，如工作流技術、數據挖掘技術、簽署加密技術等。但是在OA系統中的電子文件管理方面，還存在一些不理想的狀況，如現有的OA系統的元數據使用沒有統一標準，各個軟件公司自行設計元數據方案，致使不同的系統之間無法交換數據；現有的OA系統在電子文件保存格式方面也沒有統一標準，在系統中各類文件格式都有，致使有些格式無法向檔案部門移交；許多OA系統在設計時僅僅考慮了公文處理和傳輸的需求，沒有考慮文件轉化為檔案永久保存的需要，致使在系統中的文件難以轉換成檔案。
考慮到其理論意義與應用價值，顯然需要將檔案管理的理論與方法應用到OA系統的開發與應用中去，否則的話，OA系統中電子文件很難具有相應的憑證價值，檔案管理人員仍然無法從“雙套制”得到解放。因此，從檔案學的角度對OA系統中的電子文件管理進行研究便成為現在檔案管理中的一個重要研究課題。
三、OA系統在大中型企事業單位中已經廣泛應用，但是OA系統中的電子文件管理功能卻不完善
OA系統能處理信息，卻不能保存檔案，有的單位想進行完全的無紙化辦公，解放人力，卻又有種種顧慮。大中型企事業單位的OA系統使用狀況也存在問題，這就需要進一步提出符合電子文件管理要求的OA系統的功能模型，為OA系統的開發提供參考，加速檔案管理信息化的進程。
對OA系統中的電子文件管理功能首先要通過實證研究的方法，總結不同的系統的功能要求，再通過實證調研的方法，分析OA系統在電子文件管理方面的規律；通過對比研究，明確現有的OA系統在電子文件管理方面的不足，強調在信息網絡時代，以檔案管理的理論為指導，構建符合檔案管理需求的OA系統，強化OA系統中的電子文件管理以及與檔案管理實現無縫連接。
四、對社會經濟發展和學科建設的作用和意義
機關檔案室是我國檔案事業的基礎，從80年代開始，我國就在進行機關檔案體制改革的嘗試，但成效甚徽。隨著信息技術的廣泛應用，對機關檔案室管理的改革時機也日益成熟。對其檔案室的管理模式、管理方法、管理技術進行系統研究，使檔案信息在其形成之時就能進行整合，包括和政務信息網的整合，以及檔案信息網的整合，提高管理效率，促進我省乃至全國的政府信息化建設和檔案信息化建設。
同時，對檔案學科的發展也具有重要的意義。一是檔案檔案室管理模式的探索是檔案學領域的一個非常重要的研究問題，許多學者分析了美國文件中心的優點，但在我國由于體制等原因一直無法實施，近年來，有學者提出，將機關檔案室合并為文件中心的條件日漸成熟，但還沒有人進行深入的研究。另外，在信息技術發展的今天，各省的檔案館都紛紛提出要建設數字檔案館，但作為數字檔案館的基礎――機關檔案室卻缺少相應的管理規范，顯然應該從檔案的源頭開始做好數字化規范工作，也有利于數字檔案館的進一步發展和研究。
論文摘要：本系統以文檔管理為核心，利用先進的計算機軟件技術，有效地控制各種文檔的產生，管理文檔的存取訪問，對文檔進行有效管理。
1開發背景
辦公管理系統是在網絡技術飛速發展的情況下推出的新概念，而在圖書館歷經了傳統圖書館和自動化圖書館開始進入數字化圖書館階段的今天，辦公管理系統的引入更使圖書館界如虎添翼。在辦公信息化的大潮下，文件管理的信息化管理尤為重要。筆者近年經歷了本校的本科教學工作水平評估、升格師范大學水平評估以及業內的圖書館評估，對文件管理的重要性體會頗深，大量的歷年的文件、業務檔案及不斷修訂的規章制度等，如果有一種有別于圖書分類法的一個檔案管理系統，那么我們的工作效率會事半功倍。由此筆者針對圖書館的特點申請了一項課題，組織人員研制出一套文件管理系統：海南師范大學圖書館文件管理系統。
2平臺簡介
本系統是采用當前運用最廣泛的B／S結構模型，后臺采用Microsoft Access作為數據庫。Access是微軟公司推出的基于Windows的桌面關系數據庫管理系統(RDBMS)，是Office系列應用軟件之一。它提供了表、查詢、窗體、報表、頁、宏、模塊7種用于建立數據庫系統的對象，提供了多種向導、生成器、模板，把數據存儲、數據查詢、界面設計、報表生成等操作規范化，為建立功能完善的數據庫管理系統提供了方便，也使得普通用戶不必編寫代碼就可以完成大部分數據管理的任務。
前臺所用的ASP語言(Active Server Pages)是微軟公司為了克服CGI嚴重的擴展性問題而開發的。解決了多用戶訪問進程，有效地利用了網絡資源。ASP技術簡化了Web程序開發，支持動態Web設計。ASP只用于服務器端，執行動態的、交互式的、高效率的站點服務器應用系統。ASP以標記語言的形式嵌入到HTML中并發送到客戶端，但是，顯示在客戶端瀏覽器的只是ASP執行結果所生成的頁面，而其本身根本看不到，所以安全性很好。同時，ASP也支持腳本語言，只要服務器端裝了腳本引擎就可以方便地架構網站。
系統運行環境是微軟的lIs(Internet Information Server)，它把World WideWebserver，Gopher server和FtPsevrer全部包容在里面。IIs能網頁，并且由ASP，Java，VBscript產生頁面，有著一些擴展功能。IIs支持有編輯環境的界面(FRONTPAGE)、有全文檢索功能的界面(INDEX SERVER)、有多媒體功能的界面(NET SHOW)，IIS6．0包括許多新功能，它們旨在幫助企業、lT專業人士和Web管理員實現其網站(他們可能擁有位于單個Ils服務器或多個服務器上的數千個網站)在性能、可靠性、可伸縮性和安全性方面的目標。
ASP+Access+IIs開發中小型網絡系統一直被視為黃金組合，這樣的結合對系統的資源占用適宜，每個部分都能很好地發揮其功能，在數據的處理能力和安全性上也有很好的選擇。
3系統主要功能介紹
3．1普通用戶
3．1．1登錄驗證
為了確保本系統特殊用戶的單一性和系統的安全性，系統不設置注冊功能，所有賬號和初始密碼均由普通用戶向管理員申請。
3．1．2用戶信息查看及修改
用戶可以對自己的基本資料(如姓名、所在部門、E—mail、聯系電話等)以及密碼進行瀏覽和修改。
3．1．3查看文件
該模塊的主要功能就是對文件、檔案資料(如相關文件、工作計劃、工作總結、月報、年報等日常工作文檔)共享，由管理員負責上傳，普通用戶可以瀏覽和下載。
3．1．4用戶上傳待審核文檔
該模塊針對由下級部門擬訂的文檔提供一個審核功能，如月報、年報、讀者意見反饋、館際交流、各部門統計報告等，待審定后再上傳到數據庫。
3．1．5文件檢索
為了加快用戶對文件檔案的查找速度進而提高辦公效率，系統設計了一個專門的文件檢索功能，包括普通檢索和高級檢索。
普通檢索：可提供文件名、主題、分類號、文件號、發文單位及發文時間等檢索途徑(見圖1)。
高級檢索：提供了普通檢索所具有的檢索途徑，并進行組配檢索(見圖2)。
3．2管理員
3．2．1登錄驗證
管理員的后臺管理登錄可以通過在首頁右下角處點擊“管理員入口”，進入管理員操作界面，進行身份驗證并登錄系統。
3．2．2管理員信息查看及修改
管理員可以對自己的基本資料(姓名、所在部門、E—mail、聯系電話等)以及密碼進行瀏覽和修改。
3．2．3用戶管理
管理員可對系統的普通用戶進行分配，同時還可以對用戶的基本資料進行查看、修改和刪除用戶，以確保數據庫的保密性和安全性。
3．2．4文件管理
對文件進行管理是本系統的主要目的，在文件管理模塊巾，管理員可以上傳文件、修改文件和刪除文件，同時也可以對文件進行瀏覽和下載。
3．2．5審核文件
本系統提供了文件審核功能．普通用戶上傳的文件只有經過管理員審核才能，確保了文件著錄的規范性和管理的科學性。
3．2．6文件檢索
管理員用戶是通過管理員進行區分的，對管理員來說，在日常工作中對文件的檢索也是必不可少的，檢索結果出來后可進行瀏覽和下載。
3．2．7服務器信息
為了方便管理員能實時了解服務器的信息以及對服務器的運作情況進行監控，系統設計了一個服務器實時信息反饋模塊。可查看服務器的有關參數、組件支持情況巾的IIS自帶的ASP組件、常見的文件上傳和管理組件。
4系統功能特色
4．1系統低成本性
由于系統本身的開發工具語言和運行平臺的簡單性，決定了系統在架構和運行維護上的成本都是比較低的；不僅如此，在需求分析階段，對各種需求結合開發工具設計，使得系統在最大限度上發揮了系統數據庫以及腳本語言的特色，使得系統在運行時對資源的占用相對較少，大大地提高了運行速度，為快速辦公打下了堅實的基礎。
4．2穩定的安全性
首先，本系統考慮到用戶是有針對性的特殊群體，每個人都能進人但又必須通過身份驗證；其二。本系統不提供注冊功能，要想得到賬號和密碼必須向管理員提出申請，由管理員統一分配賬號，預防不法者對內部資料檔案的竊取；其三，本系統在開發過程中通過對“session”變量的合理運用，防止不法者通過直接對URL的訪問來跳過身份驗證頁面進而訪問系統的其他資源頁面，一旦用戶沒有通過登錄頁面的身份驗證，系統將其他頁面進行隱藏，非法用戶將瀏覽不到任何資源。另外，系統通過對“session”變量的時間設置，一旦用戶停止操作時間過長，系統會要求用戶進行重新登錄進行身份驗證，從而在最大限度上保證了系統內部資料的安全性。
4．3良好的交互性
系統通過在各個頁面中對各個操作步驟的人性化提示，使得一些電腦操作技能較弱的用戶也能在最短時間內掌握基本的操作，從而對提高辦公效率起著不可或缺的作用。
4．4文件管理的科學性
在需求分析過程中，筆者考慮到文件及檔案資料可由不同層次部門產生的特點(如由上級分發的文件，同級之間的函件，下級的申請，各種業務統計等)，特別設計了文件審核這一流程，各種文件在前都必須經過管理員的審核，為文件著錄的規范性和文件管理的科學性提供了前提保證。
4．5組配檢索功能
隨著數據庫規模的擴大，檔案數據量增多，就必然需要一種可實現多途徑檢索的功能，為此系統專門設計了高級檢索功能，檢索途徑針對辦公文件及日常檔案的特點而設定。對字段內容比較特殊的文檔可通過普通檢索查詢，而對字段內容很普通的文檔則可通過高級檢索來進行查找，即通過對多字段的邏輯組配，并選擇相應的匹配模式，實現高級檢索。組配檢索使檢索命中率大大提高，解決了檔案管理巾存在的弊端，大大地節約了查找文件、檔案資料的時間，從而提高了信息化辦公的效率。
4．6數據信息類型多元化
本系統的數據信息包含文本、圖像、視頻、音頻或任何其他類型的信息數據。
5結語
關鍵詞：報表生成；戰斗文件；管理信息系統；安全；數據庫
中圖分類號：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);
}
福建電大學生學籍管理系統軟件是以學籍管理為中心，面向學校領導、教務管理人員、以及其他有關工作人員以及學生的一體化的學籍管理系統軟件，可實現包括學生成績打印、學歷證明打印、相關信息查詢、學生成績統計、后臺數據管理和維護以及數據庫備份等功能。按照系統需要完成的功能可分為：（1）教學計劃管理：教務管理人員選擇不同的分校（教學點）、年級、專業，輸入教學計劃包括課程名稱，課程學分，選修必修等信息。（2）學生信息管理：包括學生修過的課程成績和畢業情況，還包括課程成績錄入：選擇不同的分校（教學點），學生的年級專業，在輸入學生基本信息的同時系統根據學生的年級，專業等基本信息自動查詢生成學生應修的學科，并在同一個頁面中顯示學生所有課程的成績。（3）查詢學生信息：普通用戶通過輸入學生的姓名、年級、分校（教學點）、學號其中的若干個模糊信息來查詢到該學生的所修課程成績和畢業情況。（4）學籍數據統計：教務管理人員可根據分校工作站、年份、專業等關鍵字統計對應的學籍檔案數據，還包括各種數據的分布圖如某課程的成績分布情況等信息。（5）權限日志功能：由超級管理員進行創建各用戶，并給相關用戶授權分配管理權限。查看日志，日志中對學籍檔案數據的特殊操作如修改刪除等操作記入日志，并說明操作的原因以便查對。（6）系統管理：由超級管理員進行包括分校、教學點、專業類型、課程形式等基本信息的維護。還包括整個系統得環境變量，數據庫備份等內容。（7）開具成績證明：教務管理人員通過學生的姓名、年級、分校（教學點）、學號其中的若干個模糊信息查詢到該學生的信息后，自動打印出學生的成績表，同時記下成績證明開具時間和教務管理人員的打印記錄。（8）開具學歷證明：教務管理人員通過學生的姓名、年級、分校（教學點）、學號其中的若干個模糊信息查詢到該學生的信息后，自動打印出學生的學歷證明，同時記下學歷證明開具時間和教務管理人員的打印記錄[4]。
2、驗證和顯示控件的實現過程
為了解釋驗證和顯示控件的實現過程選用系統用戶登陸模塊為例。該模塊為系統軟件初始頁面用來驗證用戶信息。用戶通過輸入用戶名、密碼和驗證碼來登陸本系統。驗證碼使用系統隨機生成的圖片來完成，驗證碼保存在用戶的SESSION當中，當用戶的信息和數據庫中數據完全對應的情況下，運行用戶跳轉到主頁面，同時用戶的各個信息也保存在該用戶的SES－SION中。為了用戶密碼的安全性，密碼的保存形式使用MD5加密方式。同時輸入信息的三個文本框使用AJAX技術實現了用戶輸入信息的提示工作。該模塊的功能有：系統用戶登陸與系統用戶驗證的功能。系統用戶登錄頁面代碼：為。其中CS文件中引用了系統的幾個必要的命名空間。登錄部分通過控件建立面板，通過作為用戶名、密碼和驗證碼的輸入框同時設置AJAX事件，實現輸入不能為空等基本客戶端驗證。驗證碼的圖片通過控件引用來顯示隨機的驗證碼圖片信息。為了解釋頁面布局框架的實現過程選用系統主界面模塊為例。該模塊工作主界面如圖1-2所示，各模塊主要功能包括：學籍信息查詢模塊，主要實現學生成績查詢和學生學歷查詢兩個子模塊功能；學籍信息輸入模塊，主要實現教學計劃的輸入和學生信息的輸入兩個子模塊功能；系統管理模塊，主要系統用戶管理和系統預設兩個子模塊功能。
3、總結
