引言：易發(fā)表網(wǎng)憑借豐富的文秘實踐，為您精心挑選了九篇文件管理系統(tǒng)范例。如需獲取更多原創(chuàng)內(nèi)容，可隨時聯(lián)系我們的客服老師。

第1篇

>> 基于JSP的網(wǎng)絡(luò)文件管理系統(tǒng)的設(shè)計與實現(xiàn) 電子文件檔案管理系統(tǒng)設(shè)計與實現(xiàn) 網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn) 文件加密系統(tǒng)設(shè)計與實現(xiàn) 網(wǎng)絡(luò)課程制作與管理系統(tǒng)的設(shè)計與實現(xiàn) 面向制造現(xiàn)場的工藝文件管理系統(tǒng)設(shè)計與實現(xiàn) 淺談電子文件檔案管理系統(tǒng)的設(shè)計與實現(xiàn) 網(wǎng)絡(luò)費用報銷管理系統(tǒng)的設(shè)計與實現(xiàn) 網(wǎng)絡(luò)教學資源管理系統(tǒng)的設(shè)計與實現(xiàn) 基于SNMP的網(wǎng)絡(luò)管理系統(tǒng)設(shè)計與實現(xiàn) 淺談基于SNMP網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn) 淺析網(wǎng)絡(luò)監(jiān)控安全管理系統(tǒng)的設(shè)計與實現(xiàn) 網(wǎng)上車輛網(wǎng)絡(luò)管理系統(tǒng)設(shè)計與實現(xiàn)分析 網(wǎng)絡(luò)指紋考勤管理系統(tǒng)的設(shè)計與實現(xiàn) 基于Android的網(wǎng)絡(luò)問政管理系統(tǒng)設(shè)計與實現(xiàn) 網(wǎng)絡(luò)在線車輛使用管理系統(tǒng)的設(shè)計與實現(xiàn) 高校教材網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn) 基于SNMP網(wǎng)絡(luò)管理系統(tǒng)的設(shè)計與實現(xiàn) 基于Android的文件加密系統(tǒng)的設(shè)計與實現(xiàn) Windows　Mobile文件監(jiān)控系統(tǒng)的設(shè)計與實現(xiàn) 常見問題解答 當前所在位置：lControls;

public partial class AdminManage_Login : System.Web.UI.Page

{CommonClass CC = new CommonClass();

protected void Page_Load(object sender, EventArgs e)

{if (!IsPostBack)

{//產(chǎn)生驗證碼

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())

{//調(diào)用CommonClass類中的checkLogin方法，判斷用戶是否為合法用戶

int IntUserIn = CC.checkLogin(txtAdminName.Text.Trim(), txtAdminPwd.Text.Trim());

if (IntUserIn > 0)

{ //該用戶為合法用戶，跳轉(zhuǎn)到后臺首頁（AdminIndex.aspx）中

Response.Write("window.open('AdminIndex.aspx');window.close();"); }

else

{ //該用戶不是合法用戶，調(diào)用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)';");}}

以上即為我所設(shè)計的一個網(wǎng)絡(luò)文件管理系統(tǒng)，由于篇幅所限，本文只給出了部分代碼，希望能對大家在進行網(wǎng)絡(luò)文件管理系統(tǒng)設(shè)計時起到拋磚引玉的作用。

參考文獻：

[1] 陳會安2.0網(wǎng)頁制作徹底研究[M].北京:清華大學出版社,2007.

第2篇

系統(tǒng)建設(shè)成為每個形成和保管電子文件單位的嶄新且重要的工作內(nèi)容。然而，在電子文件種類繁多、業(yè)務(wù)系統(tǒng)架構(gòu)各異、包括人才在內(nèi)的專業(yè)資源有限的情況下，各單位如何建設(shè)合格的系統(tǒng)，逐漸成為當下文件、檔案管理領(lǐng)域需要回答的現(xiàn)實問題。本文采用文獻研究法和案例研究法，從與業(yè)務(wù)系統(tǒng)的關(guān)系、主導方式、部署方式等角度對ERMS建設(shè)的模式進行總結(jié)，繼而分析其適用性。

一、ERMS和業(yè)務(wù)系統(tǒng)的關(guān)系

一個單位若要建設(shè)ERMS，首先要考慮的問題之一就是本單位有多少個業(yè)務(wù)系統(tǒng)可能產(chǎn)生電子文件，需要加以管理。因單位規(guī)模、業(yè)務(wù)的不同，這個答案的差異性較大。2010年4月，筆者分別走訪了北京市地稅局和北京市發(fā)展和改革委員會，兩個單位對此問題的答案依次是50多個和70多個，這還不包括桌面級的應(yīng)用。事實上，決定啟動ERMS建設(shè)的單位，其業(yè)務(wù)系統(tǒng)的數(shù)量一般都在幾十個左右。

如此之多的業(yè)務(wù)系統(tǒng)，產(chǎn)生的文件類型、數(shù)量、數(shù)據(jù)結(jié)構(gòu)差異性較大，ERMS的實現(xiàn)方式也不可能單一。筆者曾經(jīng)在2004年闡述了獨立、包含、嵌入等三種業(yè)務(wù)系統(tǒng)和ERMs的關(guān)系，即業(yè)務(wù)系統(tǒng)和ERMS相對獨立，業(yè)務(wù)系統(tǒng)包含完整的ERMS，業(yè)務(wù)系統(tǒng)中內(nèi)嵌ERMS的前端控制模塊。國際檔案理事會(ICA)2008年頒布的《電子辦公環(huán)境中文件管理原則和功能要求》，提供了業(yè)務(wù)系統(tǒng)中產(chǎn)生的文件的管理方案，分別為：(1)在業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)文件管理功能；(2)將文件元數(shù)據(jù)輸出到ERMS中，而文件還保存在業(yè)務(wù)系統(tǒng)中；(3)將文件及其元數(shù)據(jù)直接輸出到ERMS中加以管理。

根據(jù)ERMs和業(yè)務(wù)系統(tǒng)的交互方式以及與之相伴的文件和元數(shù)據(jù)的存儲方式，可以總結(jié)出獨立式、嵌入式、整合式、互聯(lián)式四種ERMs建設(shè)模式。其特點比較如表1所示。

1.獨立式

所謂獨立式，就是ERMs相對獨立于形成文件的各個業(yè)務(wù)系統(tǒng)，后者可通過應(yīng)用程序接口(API)向ERMS輸出文件及其元數(shù)據(jù)，文件及其元數(shù)據(jù)集中于ERMS保存管理。這種組合模式延續(xù)了紙質(zhì)文件前后端分離管理的做法，對應(yīng)于現(xiàn)有的組織分工模式，較為通行。在此模式中，ERMS相對被動，被動接收業(yè)務(wù)系統(tǒng)提交的數(shù)據(jù)，需要在相應(yīng)管理制度的配合下，強化業(yè)務(wù)系統(tǒng)主動提交文件及其元數(shù)據(jù)的行為。由于向ERMS輸出數(shù)據(jù)的業(yè)務(wù)系統(tǒng)可能有多個，往往需要定制開發(fā)多個接口才能完成數(shù)據(jù)的順利交接，這將增加協(xié)調(diào)和實施的成本。

2.嵌入式

所謂嵌入式，是指在業(yè)務(wù)系統(tǒng)自行開發(fā)完善ERMS的功能，在業(yè)務(wù)系統(tǒng)內(nèi)部實現(xiàn)電子文件的捕獲、維護和處置。換句話說，ERMS嵌入業(yè)務(wù)系統(tǒng)中成為其子模塊，比如財務(wù)管理系統(tǒng)、人事管理系統(tǒng)中自帶的文件(檔案)管理模塊，嵌入到郵件系統(tǒng)中的電子郵件歸檔管理軟件等。在此模式中，包含ERMS功能的業(yè)務(wù)系統(tǒng)，往往只能管理本系統(tǒng)產(chǎn)生的電子文件及其元數(shù)據(jù)，適用于業(yè)務(wù)文件數(shù)量大，對于業(yè)務(wù)系統(tǒng)依賴性強，業(yè)務(wù)流程較為規(guī)范的情況。這種模式有利于特定業(yè)務(wù)文件的專業(yè)化管理和利用。但是，如果一個單位僅采用該模式，那么就會在整體上造成文件信息的分散，若需開展全局性的利用，則還須借助于其他系統(tǒng)。

3，整合式

從某種意義上，可以將整合式理解為獨立式和嵌入式的結(jié)合，整個ERMS分為兩大部分，一部分嵌入到業(yè)務(wù)系統(tǒng)中，實時捕獲文件及其元數(shù)據(jù)；另外一個部分則集中保管維護文件及其元數(shù)據(jù)。這種模式兼具了獨立式和嵌入式的優(yōu)點，既能捕獲來自多個業(yè)務(wù)系統(tǒng)的電子文件，又能集中機構(gòu)的信息資產(chǎn)，并以統(tǒng)一的方式加以維護和開發(fā)利用。目前構(gòu)建在內(nèi)容管理平臺(Enterprise Content Management，ECM)上的ERMS(EDRMS)大多采用該模式，對業(yè)務(wù)系統(tǒng)和ERMS之間的集成要求較高。

4.互聯(lián)式

互聯(lián)式強調(diào)的是ERMS和業(yè)務(wù)系統(tǒng)相互訪問數(shù)據(jù)的便利性，兩者可以相互獨立，也可以像整合式一樣將部分ERMs功能模塊嵌入業(yè)務(wù)系統(tǒng)中。其區(qū)別在于整合式集中保管所有的電子文件及其元數(shù)據(jù)，而互聯(lián)式的ERMS僅保存文件元數(shù)據(jù)，文件則仍然保存在業(yè)務(wù)系統(tǒng)中，ERMS負責維護元數(shù)據(jù)和文件之間的關(guān)聯(lián)，始終保證二者之間的互聯(lián)。這種模式適用于業(yè)務(wù)文件對原系統(tǒng)環(huán)境的依賴性強的單位，通常需要業(yè)務(wù)系統(tǒng)提供訪問接口，以便從ERMS查找利用文件。

二、ERMS建設(shè)的主導方式

大多數(shù)單位從市場上購買產(chǎn)品而非本單位自行研發(fā)ERMS，根據(jù)主導市場采購和系統(tǒng)實施的力量的不同，ERMS建設(shè)模式也可以劃分為用戶引導型、廠商引導型和上級主導型。其特點比較如表2所示。

1.用戶引導型

所謂用戶引導型，是指ERMS建設(shè)單立，即用戶單位在市場采購和系統(tǒng)實施扮演主導角色。這樣的ERMS建設(shè)單位，往往用有“明白的用戶”，即充分了解本單位業(yè)務(wù)特點、文件管理需求、IT環(huán)境、管理規(guī)范陽管理文化的專業(yè)人員，他們對于電子文件管理方法和要求有清晰的認識，能夠主導ERMS建設(shè)的方向，在與廠商的談判、溝通，產(chǎn)品二次開發(fā)以及方案驗收的過程中，處于主動的位置，用戶參與ERMS建設(shè)的程度較深，系統(tǒng)開發(fā)周期相對較長。用戶引導型的系統(tǒng)建設(shè)方式，有助于保證系統(tǒng)滿足用戶單位的個性化需求。因用戶水平的不同，ERMS實施效果可能存在差異。

2.廠商引導式

所謂廠商引導型，是指產(chǎn)品提供方，即廠商在市場采購和系統(tǒng)實施扮演主導角色。很多單位沒有貫通文件(檔案)管理和IT管理的復合型人才，故而被動地選擇廠商引導型的建設(shè)方式。由廠商提供包括業(yè)務(wù)咨詢、工作規(guī)劃、制度建設(shè)、軟硬件集成等全方位的解決方案。采用該模式的用戶單位，系統(tǒng)實施周期短，見效

快，同時也面臨個性化需求未得到滿足的風險。廠商的系統(tǒng)實施經(jīng)驗和能力在很大程度上決定了其系統(tǒng)建設(shè)的質(zhì)量。

3.上級主導型

所謂上級主導型，是指ERMS建設(shè)單位只能選用上級主管部門指定或者統(tǒng)一采購的產(chǎn)品。這里的上級主管部門包括兩類，一類是橫向的檔案行政主管部門，另一類是縱向的行業(yè)主管部門或者企業(yè)集團。如加拿大安大略省也通過統(tǒng)一采購程序，指定了省政府機關(guān)ERMS唯一的產(chǎn)品供應(yīng)商Opentext。我國也有很多地方、行業(yè)系統(tǒng)通過行政手段指定特定政府機關(guān)采用一定的檔案管理軟件。

若上級主管部門指定產(chǎn)品質(zhì)量較高，那么該模式則有助于橫向或縱向水平上的系統(tǒng)的規(guī)范化建設(shè)和信息的共享。該模式最大的風險就是上級主管部門指定產(chǎn)品質(zhì)量可能存在缺陷，此外，還可能存在難以滿足用戶單位的個性化需求，對于用戶單位既有系統(tǒng)建設(shè)投資保護不足等缺點。若試圖主導下級單位ERMS建設(shè)的主管部門不止一個，指定的ERMS產(chǎn)品不止一個的話，則對下屬單位而言是一場災(zāi)難。筆者了解到上海某區(qū)財政局，出于各種原因分別擁有3個辦公自動化系統(tǒng)和3個檔案管理系統(tǒng)，且同時在用，造成資源浪費、數(shù)據(jù)分散、數(shù)據(jù)不一致等。

三、ERMS的部署方式

以上兩種視角的模式分析，均站在個別ERMS建設(shè)單位的立場。下面將立足于全局，從ERMS的部署方式來分析三種ERMS的建設(shè)模式，分別是分散式、集中式、分布式。不同的部署方式下，系統(tǒng)及其中數(shù)據(jù)的受控程度有別，其特點比較如表3所示。

1.分散式

所謂分散式，即各單位自行部署ERMS，包括自行采購、安裝、運行和維護系統(tǒng)等。這是目前主流的ERMS建設(shè)模式。該模式對每個單位的文件管理、IT管理資源提出較高的要求。在這種模式下，控制各單位文件管理規(guī)范化的手段只能是由主管部門制定相關(guān)標準。

然而，并非每個單位都有足夠的文件管理、IT管理的資源；集中專業(yè)化的人力、設(shè)備、軟件資源，為更大范圍內(nèi)電子文件管理工作提供支持，是社會發(fā)展和IT建設(shè)發(fā)展的基本要求。隨著系統(tǒng)建設(shè)集約化程度的提高，集中式和分布式依次出現(xiàn)。

2.集中式

所謂集中式，即由一家單位統(tǒng)一規(guī)劃、采購、安裝、運行和維護一定范圍內(nèi)的多家單位的ERMs，軟硬件集中部署，數(shù)據(jù)集中存儲。目前的技術(shù)條件下，系統(tǒng)維護單位可以借助于云服務(wù)的方式向各個用戶單位提供ERMS存儲、平臺和(或)應(yīng)用服務(wù)。集中式的系統(tǒng)建設(shè)模式，必然伴隨著系統(tǒng)維護方和使用方之間服務(wù)模式的改變。

根據(jù)部署范圍的不同，集中式主要分為以下兩種情況。

(1)行政區(qū)劃范圍內(nèi)的集中式。即一定行政區(qū)劃范圍的機構(gòu)，通常是政府機關(guān)，統(tǒng)一采購實施ERMS。比如杭州市檔案局于2009年年底啟動的“杭州市電子文件中心”項目，即采用集中式的系統(tǒng)建設(shè)模式。不同于國內(nèi)其他很多地方政府電子文件中心，該局籽工作任務(wù)的重點放在為各黨政機關(guān)統(tǒng)一建設(shè)、部署ERMS上，各單位通過集中部署在杭州市檔案局的ERMS，管理本單位的電子文件及其元數(shù)據(jù)。也就是說，各單位ERMS建設(shè)任務(wù)集中于檔案局。這意味著數(shù)字環(huán)境下的檔案局面向各立檔單位的服務(wù)功能得以拓展，除了提供政策規(guī)范、業(yè)務(wù)指導和永久文件保存的服務(wù)之外，還提供系統(tǒng)建設(shè)、部署和維護的服務(wù)。據(jù)筆者了解，香港、澳門等地都在考慮這種基于云計算的集中式建設(shè)模式上。

(2)行業(yè)范圍內(nèi)的集中式。即面對某行業(yè)范圍的機構(gòu)集中部署同一套ERMS，包括政府行業(yè)管理系統(tǒng)內(nèi)集中部署和企業(yè)集團系統(tǒng)內(nèi)統(tǒng)一部署的情況。前者如北京市地稅局，該局自2010年開始建設(shè)面向全市地稅機關(guān)的電子稅務(wù)申報原件管理系統(tǒng)，該ERMS內(nèi)嵌于產(chǎn)生電子文件的核心征管系統(tǒng)，與核心征管系統(tǒng)數(shù)據(jù)大集中的建設(shè)模式相匹配，ERMS也將采用集中式。后者如中石油天然氣股份有限公司，該公司2006年建成了面向中石油機關(guān)和所屬單位的統(tǒng)一的ERMS，該ERMS內(nèi)嵌于辦公自動化系統(tǒng)(OA)，所有電子文件服務(wù)器都部署在中心站點。根據(jù)筆者的調(diào)研，由于內(nèi)嵌于OA的ERMs主要只能管理來自O(shè)A的電子公文，所以中石油自2009年啟動整合式的綜合檔案管理系統(tǒng)建設(shè)，同樣采用集中部署的方式。

集中式最大的挑戰(zhàn)有兩個：第一，系統(tǒng)維護方的服務(wù)能力問題，系統(tǒng)維護方應(yīng)保證系統(tǒng)和數(shù)據(jù)的完整、安全和可用，這需要恰當應(yīng)用數(shù)據(jù)中心建設(shè)和維護的新理念和新方法。第二，不同用戶單位個性化的應(yīng)用需求問題。很多單位之所以將嵌入式作為集中部署ERMS的起點，就是因為采用嵌入式的用戶單位，其業(yè)務(wù)系統(tǒng)是統(tǒng)一的，這就極大地削減了業(yè)務(wù)系統(tǒng)異構(gòu)而給ERMS的統(tǒng)一存儲和管理帶來的困難。基于同樣的原因，杭州市檔案局盡管部署的是獨立的ERMS，不過在項目一期，選擇了采用統(tǒng)一OA的13家試點單位，先行完善了OA，為二期ERMS的開發(fā)奠定了基礎(chǔ)。

3.分布式

分布式可以理解成集中式和分散式的綜合。仍然由一家單位統(tǒng)一規(guī)劃、采購、監(jiān)管多個單位的ERMS，但是由于地理、安全、利用等方面的考慮，所有數(shù)據(jù)并不采用大集中的存儲模式，部分單位的ERMS可能需要部署在本地，數(shù)據(jù)也存放在本地。相比集中式，分布式更為靈活，更容易滿足個別單位的個性化需求。但是，總部對于分布于本地的系統(tǒng)、管理流程、數(shù)據(jù)的控制力度就會下降。為實現(xiàn)全局性的信息利用和信息同步，則需要耗費額外的工作量。

四、模式選擇

任何一個形成、管理和利用電子文件的單位，首先需要判斷本單位是否需要建設(shè)ERMs這樣的專業(yè)軟件，不是每個單位部需要以獨立軟件的方式來管理電子文件。如果確需建設(shè)ERMS，那么至少需要從業(yè)務(wù)系統(tǒng)以及業(yè)務(wù)文件的特點、管理人員的專業(yè)化程度、本單位所處政策環(huán)境等方面加以分析，從而決定ERMS的建設(shè)模式。

第3篇

關(guān)鍵詞：MVC 體系結(jié)構(gòu) 文件管理系統(tǒng)

中圖分類號：TP393 文獻標識碼：A 文章編號：1007-9416（2016）12-0180-02

1 引言

隨著多媒體教學環(huán)境的逐步完善，網(wǎng)絡(luò)技術(shù)的不斷成熟，很多學校都為學生配備了先進的實訓室。實訓室在使用過程中，會生成大量的電子文件，目前文件的主要傳輸手段還是通過優(yōu)盤等途徑，這導致在實訓室的電腦中傳播大量病毒。依托互聯(lián)網(wǎng)環(huán)境的文件管理系統(tǒng)能夠有效緩解這一問題，學生通過授權(quán)之后登錄系統(tǒng)進行文件的上傳、下載、文件修改等操作。同時文件管理系統(tǒng)極大地拓寬了學生的學習空間，為系統(tǒng)管理人員提供了豐富的管理手段。

2 MVC模式基本原理

MVC模式是微軟公司在.NET框架的基礎(chǔ)上構(gòu)建的一種開源的，基于測試驅(qū)動的web 應(yīng)用程序編程模型，開發(fā)人員利用 MVC和Razor視圖引擎編寫web應(yīng)用程序。MVC（Models，Views，Controllers）可以幫助開發(fā)人員創(chuàng)建數(shù)據(jù)支持，邏輯處理和用戶界面完全分離的應(yīng)用程序，使得系統(tǒng)易于維護和擴展，MVC的體系結(jié)構(gòu)如圖1所示。在MVC體系中，模型通常被稱為“業(yè)務(wù)邏輯”，是真正完成任務(wù)的代碼，視圖就是用戶界面，反映數(shù)據(jù)的變化。控制器控制著模型和視圖之間的交互過程，它決定著向用戶返回怎樣的視圖、檢查通過界面輸入的信息以及選擇處理輸入信息的模型。

3 文件管理系統(tǒng)實現(xiàn)

3.1 文件管理系統(tǒng)體系結(jié)構(gòu)

文件管理系統(tǒng)主要實現(xiàn)對實訓室電腦中存放的大量文件進行網(wǎng)絡(luò)端的管理和維護。經(jīng)過授權(quán)的學生可以在web端輸入正確的用戶名和密碼之后登錄到文件管理系統(tǒng)，根據(jù)系統(tǒng)按照學號分配的默認文件夾實現(xiàn)對個人文件的上傳、下載和管理等操作。管理人員能夠?qū)崿F(xiàn)對學生信息的添加和刪除等操作，以及系統(tǒng)文件的維護管理。系統(tǒng)體系結(jié)構(gòu)如圖2所示。文件管理系統(tǒng)主要功能模塊包括用戶登錄、文件管理和用戶管理。其中用戶管理模塊主要包括添加學生用戶、刪除學生用戶、批量添加學生用戶和批量刪除學生用戶等功能。文件管理模塊主要包括文件上傳、文件下載和文件刪除等功能。

3.2 基于 MVC模式的系統(tǒng)實現(xiàn)

3.2.1 Model實體類部分代碼

（1）實體類關(guān)鍵代碼

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實體類關(guān)鍵代碼

Public class FileModel

{

…

Private string FileName； //文件名稱

Private string DateTime； //上傳日期

Private string FileSize； //文件大小

Public string FileName

{

get {return FileName；}

set {FileName=value；}

}

…

}

3.2.2 稻莘夢什憷嗖糠執(zhí)碼

Public class UserDAL

{

//用戶登錄

Public userLogin（string name，string password）

{……

UserModel user=new UserModel（）；

user.UserName=sdr.GetString（0）；

……

return user；

}

}

3.2.3 業(yè)務(wù)邏輯層類部分代碼

Public class UserBLL

{

…… //省略部分源碼

Public userLogin（string name，string paasword）

{

Return userDAL.Login（name，password）；

}

……//省略部分源碼

}

3.2.4 web層部分代碼

（1）UserLogin關(guān)鍵代碼

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關(guān)鍵代碼

Protected void Fileup_Click（object sender， EventArgs e）

{

String filename=FileUpload1.FileName.ToString（）； //獲取上傳文件的文件名

String path=server.MapPath（“～/File/”+Session[“userName”].ToString（）=”/”）； // 獲取服務(wù)器上保存文件的路徑

…… //省略部分代碼

}

4 結(jié)語

本文介紹了 MVC模式基本原理，設(shè)計并實現(xiàn)基于MVC模式的文件管理系統(tǒng)。該方法使得完成的系統(tǒng)具有易維護，可擴展的優(yōu)點，同時提高了系統(tǒng)的安全性。

參考文獻

第4篇

關(guān)鍵詞：OAIS；可信電子文件；電子文件管理系統(tǒng)；體系構(gòu)建

中圖分類號：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

一、可信電子文件與可信電子文件管理系統(tǒng)介紹

可信的電子文件就是那些完整性和真實性都能夠得到確定的電子文件，與

紙質(zhì)文件不同的是，電子文件很容易被中途截取和篡改而不會留下任何痕跡，所以電子文件在傳輸和管理過程中都會碰到很多難以想象的問題[1]，并不能完全保證電子文件的完整性。為了確保電子文件的可信性，目前企業(yè)或者單位都會使用數(shù)字簽名技術(shù)來為電子文件保駕護航。當然電子文件的可信性也會隨著各種技術(shù)的發(fā)展而發(fā)生相應(yīng)的變化，技術(shù)更新?lián)Q代很快，而舊有的電子文件在當時的技術(shù)條件下可以確保文件的可信性，但是隨著技術(shù)的不斷發(fā)展，舊有的技術(shù)可能已經(jīng)被破解，在新的技術(shù)環(huán)境下已經(jīng)失去安全保障。此時電子文件是否可信就需要區(qū)別地看待，必須進行深入且詳細的研究。

可信電子文件管理系統(tǒng)就是一個能夠起到保障電子文件可行性的管理體系，就是進入此系統(tǒng)的電子文件在經(jīng)過一段時間的保管后仍然能夠完整地進行輸出，那么這樣的系統(tǒng)就可以稱之為可信電子文件管理系統(tǒng)[2]。一般來說，可信電子文件管理系統(tǒng)需要滿足以下五個條件：首先是其設(shè)計和實施必須要符合相關(guān)的政策與法規(guī)，還有相應(yīng)的行業(yè)標準；其次是即使保存電子數(shù)據(jù)的設(shè)備發(fā)生意外或者其他未知變化時，系統(tǒng)也要保證其文件能夠被完整輸出；第三個必須要滿足的條件是系統(tǒng)內(nèi)部需要設(shè)置審計功能，一旦系統(tǒng)內(nèi)部發(fā)生異常，系統(tǒng)需要及時地跟蹤到并盡量阻止異常的發(fā)生；第四，系統(tǒng)應(yīng)該能夠提供多種識別工具，這樣才能增強電子文件的可讀性與真實性；第五，系統(tǒng)有具備各種保障文件可信的功能和機制，以免信息丟失。

二、基于OAIS的可信電子文件管理系統(tǒng)的體系構(gòu)建

要構(gòu)建可信電子文件管理系統(tǒng)首先必須要建立起一個可信電子文件庫，這是整個系統(tǒng)的基礎(chǔ)數(shù)據(jù)存儲設(shè)施，也是整個系統(tǒng)運作的核心[3]。可信電子文件庫其實就是保證用戶能對其保存的文件進行長期的、可靠的訪問的文件庫，其基本功能就是要對數(shù)字信息進行維護，以保證將來文件可以被方便利用。相應(yīng)的檔案機構(gòu)必須要提供相應(yīng)的經(jīng)費和人員保證電子文件庫的長期正常運行，這是構(gòu)建可信電子文件管理系統(tǒng)的基礎(chǔ)所在。

其次要規(guī)范電子文件管理的工作流程。以O(shè)AIS功能模型為參照，可信電子文件管理系統(tǒng)的主要流程至少要包括文件接收、存儲、系統(tǒng)管理、電子數(shù)據(jù)管理、文件的保存規(guī)劃以及文件的訪問這六個具體功能。所以的這些工作流程都有可能對電子文件可信性產(chǎn)生影響，必須多加小心。囿于篇幅，本文僅僅對文件移交、格式管理這兩個流程進行分析。文件移交過程中最為重要的工作就是要保證文件生成為能夠生成高質(zhì)量的SIP，也就是要將文件內(nèi)容與文件的元數(shù)據(jù)一起封裝。但是文件生成者可能在登記和處理文件元數(shù)據(jù)時有所遺漏，造成文件管理出現(xiàn)問題[4]。因此在移交過程中必須要保證文件生成者按照特定的格式、標識符以及創(chuàng)建的規(guī)則生成SIP，以提高文件移交、系統(tǒng)接收的自動化程度。在格式管理這個工作流程中，由于電子文件的生成格式紛繁復雜，因此檔案館在進行管理時必須對各種文件格式和保存活動進行長期的分析，以確保不會出現(xiàn)潛在的文件信息損失。

第三，電子文件管理系統(tǒng)還需要提供一定的安全服務(wù)，構(gòu)建一定的標準體系，這樣才能確保電子文件不受攻擊。電子文件管理系統(tǒng)需要提供的安全服務(wù)包括數(shù)據(jù)完整、真實以及文件的不可抵賴，這些安全服務(wù)對于管理系統(tǒng)來說是不可或缺的[5]。目前我國在這方面中主要采用的是數(shù)字簽名技術(shù)，在電子文件移交之前就用數(shù)字簽名對文件進行認證。

三、結(jié)束語

雖然信息技術(shù)不斷發(fā)展，保證電子文件可行性的技術(shù)日益先進，電子文件管理系統(tǒng)的構(gòu)建也越來越完善，但筆者認為，單單從技術(shù)上解決問題并不是根本的解決之道。電子文件的管理涉及到法律與制度，要增強電子文件的可信性，必須要從制度和法律層面加強對電子文件的管理。制度與技術(shù)二者結(jié)合，才能對竊取電子文件信息的行為進行根本性的杜絕。

參考文獻：

[1]劉越男．提升電子文件管理系統(tǒng)質(zhì)量的路徑分析[J]. 檔案學研究，2010（05）：83

[2]李宏艷．電子文件管理問題之管見[J]. 黑龍江檔案，2010（04）：44

[3]覃美娟．電子文件管理過程中的幾個問題[J]. 檔案，2006（04）：09

第5篇

關(guān)鍵詞：云存儲；智能手機；文件管理；云實例；能量；帶寬

中圖分類號：TP315

文獻標志碼：A

文章編號：1001-9081（2016）11-3050-05

0 引言

隨著移動互聯(lián)網(wǎng)技術(shù)的發(fā)展，智能手機已經(jīng)成為當前最具革命性的設(shè)備之一。根據(jù)Nielsens 2014年3月的報告，美國消費者智能手機普及率約為70.4%[1]。如今智能手機已經(jīng)無縫融入到人們的日常生活中，其角色遠超移動電話范疇。本文主要研究近期興起的一項技術(shù)，即智能手機的云存儲服務(wù)應(yīng)用。一般而言，每個用戶在云中擁有一定的遠程存儲空間，通過互聯(lián)網(wǎng)可從不同設(shè)備訪問文件。這些云存儲服務(wù)可保證同步性和文件的一致性[2]。隨著智能手機的普及，用戶不可避免地需要將云存儲服務(wù)和他們的智能手機結(jié)合起來。然而，由于智能手機自身存在限制，用戶和開發(fā)人員遇到一些困難。首先，與常見臺式計算機和筆記本相比，智能手機的存儲空間有限；其次，蜂窩網(wǎng)絡(luò)的帶寬有限。于是，主要移動網(wǎng)絡(luò)運營商們往往對數(shù)據(jù)計劃施加約束，這些約束從根本上限制了服務(wù)可擴展性的提升； 再次，能耗問題是智能手機用戶的關(guān)鍵問題[3]。鑒于這些約束，大多數(shù)當前智能手機云存儲服務(wù)均采用相同的設(shè)計原則，即：不在本地存儲云中的文件拷貝，因為智能手機沒有足夠多的空間存放這些文件，而且下載這些文件會消耗大量帶寬和電量。相反，默認情況下只在智能手機上存儲元數(shù)據(jù)。雖然這種設(shè)計的效率較高，但是制約了應(yīng)用性能的提升。對于智能手機用戶來說，利用本地拷貝即可輕松完成的部分文件操作（比如壓縮文件或?qū)⑽募鬏斀o其他用戶）變得異常困難甚至無法實現(xiàn)[4]。

為此，本文設(shè)計了一種基于云實例的文件管理系統(tǒng)（File Management system based on Cloud Instances， FM-CI），幫助智能手機用戶提升云存儲文件的性能。基本思路是通過建立云實例[5]來幫助用戶完成部分文件操作。FM-CI不要求用戶存儲文件的本地拷貝，且具有如下特點：1）豐富了移動設(shè)備可實現(xiàn)的文件操作種類，包括下載、壓縮、加密和轉(zhuǎn)換操作； 2）包括一種文件傳輸協(xié)議，支持兩個智能手機用戶從一個用戶的云存儲空間傳輸?shù)搅硪挥脩舻脑拼鎯臻g中； 3）為上述所有操作提供安全的解決方案，以便對共享的云實例（即其他用戶創(chuàng)建的實例）加以利用。

1 相關(guān)工作

云存儲問題是目前的研究熱點。文獻[6]提出了一種基于指紋魔方算法的云存儲數(shù)據(jù)保護機制。該機制通過用戶的指紋特征值控制魔方旋轉(zhuǎn)對文件進行加密，再利用門限分割技術(shù)將文件分割成小塊存儲到各個服務(wù)器中；需要恢復原文件時，先對各個服務(wù)器中的文件塊進行完整性驗證，找到不少于門限值數(shù)量的文件塊就能完整恢復文件；該機制保護了云存儲用戶的隱私數(shù)據(jù)，同時提高了云存儲系統(tǒng)的抗破壞能力和靈活性。文獻[7]針對采用主從式結(jié)構(gòu)的主流云存儲系統(tǒng)可能出現(xiàn)的性能瓶頸和可擴展問題，提出了基于Kademlia的負載均衡云存儲算法。文獻[8]針對如何選擇云存儲系統(tǒng)中可以關(guān)閉的節(jié)點集合問題，設(shè)計了基于輔助節(jié)點的貪心算法，并針對異構(gòu)云存儲系統(tǒng)的能耗優(yōu)化問題，提出了面向異構(gòu)云存儲系統(tǒng)的能耗優(yōu)化貪心算法。然而總的來說，以上的算法都需要較大的存儲空間，因此并不適用于智能手機，另外智能手機對于能耗的要求較高，這也進一步制約了這些算法在智能手機中的應(yīng)用。

為了克服以上方案的不足，文獻[9]提出了一種用于智能手機的云存儲系統(tǒng)ThinkAir。該系統(tǒng)在當前運行時間系統(tǒng)之上部署了一種Android框架。它們還提供了一種動態(tài)運行時間系統(tǒng)，可確定某個應(yīng)用組件該運行于移動設(shè)備上還是遠程服務(wù)器上，有效降低了移動設(shè)備的計算量，節(jié)省了手機存儲空間。除了卸除計算機量外，文獻[10]提出的SmartDiet方案還試圖將通信相關(guān)任務(wù)卸除給云端，以便節(jié)約智能手機的能量。文獻[11]分析了當前系統(tǒng)架構(gòu)及存儲協(xié)議可能導致的性能瓶頸，針對基于云P2P網(wǎng)絡(luò)的智能手機提出一種高效的反惡意軟件工具CloudShield。然而總的來說，以上方案都較為片面，其中文獻[9]主要關(guān)注如何降低移動設(shè)備的計算量，而文獻[10-11]則關(guān)注如何降低移動設(shè)備的能量。針對以上不足，本文設(shè)計了FM-CI，在降低移動設(shè)備計算量的同時還減少了能耗，幫助智能手機用戶提升了云存儲文件的性能。

2 云存儲服務(wù)

本文將Dropbox平臺[12]看成是一種典型的服務(wù)提供商，下面結(jié)合用戶應(yīng)用對其架構(gòu)和功能進行簡要介紹。作為個人云存儲市場的主流解決方案，Dropbox基于亞馬遜簡易存儲服務(wù)（ Amazon Simple Storage Service， S3）為桌面和移動用戶提供跨平臺服務(wù)。Dropbox采用分層架構(gòu)：在底層，Amazon S3基礎(chǔ)設(shè)施提供基本的數(shù)據(jù)存儲和檢索接口；中間層是Dropbox核心系統(tǒng)，與S3存儲服務(wù)進行交互，為更高層應(yīng)用提供服務(wù)；最頂層為正式的Dropbox應(yīng)用及開發(fā)人員構(gòu)建第三方應(yīng)用時用到的一組API接口。

為了對第三方應(yīng)用進行管理，Dropbox為每個應(yīng)用分配一個獨一無二的應(yīng)用密鑰（app key）和應(yīng)用密函（app secret）。當用戶啟動一個應(yīng)用時，Dropbox服務(wù)器利用OAuth v1進行認證。當被用戶啟動時，第三方應(yīng)用與Dropbox服務(wù)器進行通信，以獲得一個一次性請求令牌和請求密函。然后，應(yīng)用利用一次性請求令牌和請求密函形成一個改向鏈接，并將該鏈接提供給用戶。當訪問該鏈接時，用戶將被提醒利用他的Dropbox賬號登錄，Dropbox服務(wù)器將驗證他的改向鏈接及用戶登錄信息。成功登錄之后，服務(wù)器將向應(yīng)用返回一個訪問令牌和訪問密函，進而允許訪問用戶數(shù)據(jù)。

3 FM-CI

本章首先描述FM-CI框架和基于云輔助的文件操作； 然后，重點討論了FM-CI如何在兩個用戶的云存儲空間之間傳輸文件，其目標是在完成文件操作的同時，使網(wǎng)絡(luò)帶寬消耗最小。

3.1 FM-CI框架和基于云輔助的基本文件操作

在FM-CI中，每個移動設(shè)備關(guān)聯(lián)一個云存儲賬號。與其他應(yīng)用類似，鑒于存儲空間和帶寬消耗約束，F(xiàn)M-CI默認情況下不在本地保存云端的文件。但是，F(xiàn)M-CI在移動設(shè)備上維護一個影子文件系統(tǒng)，以存儲云端文件的元數(shù)據(jù)。該本地文件系統(tǒng)基于服務(wù)提供商的API接口，且與云存儲同步。

FM-CI支持兩種類型的文件操作：第1種類型為服務(wù)提供商API接口可以普遍提供的基本文件操作，比如文件的創(chuàng)建、刪除和重命名；第2種類型為需要云實例提供幫助的復雜文件操作。FM-CI可鑒別用戶的操作請求屬于哪種類別，進而相應(yīng)作出處理。第1種類別通過調(diào)用常規(guī)的API函數(shù)即可處理。對于第2種類別，F(xiàn)M-CI將創(chuàng)建一個云實例，然后將文件操作請求轉(zhuǎn)發(fā)給實例進行處理。具體而言，本文在FM-CI中設(shè)計了如下4種基于云輔助的文件操作：

下載 該操作允許用戶直接將文件下載到他的云存儲中。在FM-CI中，已知統(tǒng)一資源定位符（Uniform Resource Locator， URL）等目標文件位置后，云實例將獲取文件，然后將其上傳到用戶的云存儲中。因此，文件的下載和上傳不會消耗移動設(shè)備的帶寬。

壓縮 該操作允許用戶對存儲于云中的當前文件或目錄進行壓縮。如果用戶設(shè)備在本地存儲了目標文件的拷貝，則該操作可輕松完成，生成的壓縮文件可上傳到云存儲中。在FM-CI或針對移動設(shè)備的其他類似應(yīng)用中，真正的文件內(nèi)容是無法獲得的。因此，文中設(shè)計了一種接口，支持用戶根據(jù)本地影子文件系統(tǒng)和元數(shù)據(jù)選擇目標文件，然后將壓縮操作轉(zhuǎn)發(fā)給云實例進行操作。云實例將從云存儲中獲得指定的文件，對其壓縮，然后將壓縮文件上傳到云存儲中。

加密 在FM-CI中，用戶可選擇目標文件及密碼套件，包括加密算法和密鑰。加密操作將發(fā)送給云實例。類似地，云實例將從用戶的云存儲中下載目標文件，對其加密，然后將密文發(fā)送回云存儲空間。

轉(zhuǎn)換 該操作專門針對圖片和視頻片斷等多媒體文件。在FM-CI中，用戶在瀏覽圖片時可明確可接受的分辨率，這一請求將由云實例處理。初始圖片將下載到實例中并根據(jù)用戶指定的分辨率將圖片轉(zhuǎn)換為體積更小的文件。最后，將轉(zhuǎn)換好的文件發(fā)送給用戶。

FM-CI通過啟動云實例來幫助用戶完成這些文件操作。在執(zhí)行文件操作期間，云實例將周期性地向智能手機發(fā)送心跳消息，以匯報進度和狀態(tài)。智能手機在與云存儲服務(wù)器和云實例交換控制信息時只消耗少量帶寬。

3.2 用戶間的文件傳輸

大多數(shù)云存儲服務(wù)允許用戶與其他用戶共享文件，但是不支持不同用戶空間之間復制文件。然而，用戶之間的文件共享無法代替文件傳輸（制作一份拷貝）。在文件共享時，一位用戶對共享文件的操作會對其他用戶產(chǎn)生影響。例如，如果用戶刪除共享文件，則所有其他用戶也將失去這些文件。圖1表示了不同用戶空間之間的文件傳輸問題。假設(shè)攜帶智能手機且支持數(shù)據(jù)計劃訂閱的兩名用戶相遇，這兩名用戶均在云端設(shè)有存儲空間。一位用戶（發(fā)送方）想將自己云存儲空間中的文件傳輸?shù)搅硪晃挥脩簦ń邮辗剑┑脑拼鎯臻g內(nèi)。本文希望提出一種高效的解決方案，既可為這一特性提供支持，又將消耗的網(wǎng)絡(luò)帶寬降到最低。在傳統(tǒng)的解決方案中，發(fā)送方可將目標文件下載到自己的智能手機上，然后通過互聯(lián)網(wǎng)或藍牙、近場通信（Near Field Communication， NFC）等近距離通信手段將文件傳輸?shù)浇邮辗降氖謾C上。在接收到文件時，接收方的手機可上傳文件或與云存儲進行文件同步。然而，這一方法從帶寬消耗角度來看效率較低，尤其是當文件較大時更是如此，比如說大量圖片和視頻片斷，因為發(fā)送方必須要下載所有文件而接收方必須要上傳所有文件。

在FM-CI中，采用如下的設(shè)計原則來解決上述問題，即：利用云實例來幫助用戶在各自云存儲空間之間傳輸文件。一般來說，云實例啟動后扮演中繼節(jié)點的角色。它從發(fā)送方的云存儲空間獲取目標文件，然后將其發(fā)送到接收方的云存儲空間。通過這種方式，發(fā)送方和接收方的智能手機可以不用保存目標文件的本地拷貝，只當智能手機和云實例/云存儲服務(wù)器間傳輸控制信息時消耗一定帶寬。然而，在實踐中使用云實例這種設(shè)計思想存在一定困難，因為發(fā)送方和接收方之間沒有建立信任。云實例可由發(fā)送方或接收方創(chuàng)建。無論是誰創(chuàng)建，對于沒有擁有云實例的那一方來說這種方案的安全性都較低，因為云實例需要獲得發(fā)送方和接收方的云存儲安全證書才能完成文件傳輸。

為了解決上述問題，本文為FM-CI提出一種解決方案，要求發(fā)送方和接收方均有云實例。具體來說，通過部署算法1來完成文件傳輸。假設(shè)用戶UA試圖將文件F（F也可表示一組文件）發(fā)送給用戶UB。假設(shè)Fsrc表示F在UA云存儲空間中的位置，F(xiàn)dst表示UB將在其云存儲空間存儲該文件的目的位置。算法1給出了文件傳輸?shù)闹饕襟E。首先，UA啟動一個云實例（IA），將可以訪問它的云存儲空間的安全證書上傳給實例。UA的請求也包括源文件位置Fsrc和中間文件位置URIF（統(tǒng)一資源標識符），以表明在實例中存儲F的位置。云實例將利用安全證書來把目標文件F下載到本地磁盤。此時，IA需要允許F被用戶UB訪問。它首先向UA發(fā)送中間文件位置URIF。然后，IA可設(shè)置F可被公共訪問，或者創(chuàng)建一個來賓賬戶， 接著設(shè)置F的權(quán)限以便只有來賓賬戶可訪問它。在后者情況下，作為來賓賬戶登錄所需要的安全信息，比如登錄密碼或身份文件，也需要返回給UA。然后，UA方的步驟便已經(jīng)完成。此時，UA需要向UB傳達訪問F所需要的信息。因為這一通信步驟涉及敏感信息，所以FM-CI采用NFC協(xié)議以便使URIF和可選登錄信息安全地從UA智能手機傳輸?shù)経B智能手機。對于接收方來說，UB也開啟一個云實例IB，該實例根據(jù)URIF從IA處獲取F。最后，IB把F上傳到Fdst。此時，發(fā)送方和接收方均開啟一個云實例作為各自的。F的數(shù)據(jù)傳輸發(fā)生于云實例和云存儲服務(wù)器間，不會消耗用戶智能手機的帶寬。同時，訪問云存儲空間所需的安全證書只發(fā)送到同一擁有方創(chuàng)建的實例。因此，F(xiàn)M-CI中兩名用戶云存儲空間之間的文件傳輸既高效又安全。

算法1 從UA至UB的文件傳輸。

1）UA開啟一個云實例IA；

2）UAIA（蜂窩網(wǎng)絡(luò)）：UA訪問其云存儲空間的安全證書，源文件位置Fsrc，中間文件位置URIF；

3）IA從UA的云存儲空間中下載F，并將其存儲在URIF；

4）UAUB（NFC）：URIF（IA上的文件位置）；

5）UB開啟一個云實例IB；

6）UBIB（蜂窩網(wǎng)絡(luò)）：UB訪問其云存儲空間的安全證書，URIF，目的文件位置Fdst；

7）IB將F從IA（URIF）拷貝到其本地空間；

8）IB將F上傳到UB的云存儲空間（Fdst）。

4 基于共享云實例的解決方案

上面描述的解決方案通過開啟云實例作為輔助手段，使智能手機用戶可以對云端的文件進行管理。然而，在實踐中，下面兩種問題可能會影響上述解決方案的部署。首先，創(chuàng)建一個云實例會導致較大開銷，比如本文第5章實驗中這一開銷可達15～30s； 其次，開啟云實例的成本較高。雖然云服務(wù)較為便宜，但是頻繁開啟云實例仍然可能增加用戶的成本。

本章給出了FM-CI的改進版本，通過允許用戶相互之間共享云實例來解決上述開銷和成本問題。可以這樣處理的原因在于：大多數(shù)云服務(wù)提供商按照一定的時間尺度為實例服務(wù)收取費用[5]。當執(zhí)行云操作而開啟云實例時，用戶在操作結(jié)束時可以不用結(jié)束實例。該實例可一直保存到將要額外收取成本費用時為止。例如，假設(shè)服務(wù)提供商以小時為單位為實例服務(wù)收費，當用戶開啟一個實例并在前5min內(nèi)結(jié)束其文件操作時，該實例可在其余55min內(nèi)保存活躍狀態(tài)，且無需額外支付費用。在該空閑時間內(nèi)，該實例可為其他用戶或同一用戶的其他文件操作提供服務(wù)。在用戶間共享實例的這種設(shè)計做法雖然提升了性能，但也帶來了安全問題。首先，用戶將其云存儲空間的安全證書上傳給其他用戶的云實例時，存在一定風險。實例所有者可以監(jiān)控并獲取安全證書，進而獲得用戶云存儲空間的訪問權(quán)。其次，當向公眾開放時，被共享的云實例可能被惡意用戶用來發(fā)起攻擊。

為此，本文提出一種基于受信任服務(wù)器的實例共享方案。該服務(wù)器既維護了一個包含可被共享的可用云實例的列表，又可對發(fā)出實例請求及共享實例的用戶進行協(xié)調(diào)。FM-CI利用如下兩條基本策略來解決安全問題：首先，實例的共享方式是開啟后臺服務(wù)并接收其他用戶的請求，而不是允許其他用戶登錄并隨意運行程序；其次，當使用一個共享實例時，用戶并不上傳自己未經(jīng)保密的云存儲賬戶的安全證書，而是以加密格式上傳。如此一來，實例的所有者無法訪問租賃用戶的云存儲空間，且所有用戶對共享實例的權(quán)限只限于指定的文件操作。

具體來說，本文設(shè)計中有3種類型的實體：受信任服務(wù)器S；希望對共享實例執(zhí)行文件操作的用戶UA；由另一個用戶UB所有的可用云實例I。受信任服務(wù)器擁有一個二進制程序P，該程序在共享實例上運行后即可向其他用戶提供FM-CI服務(wù)。一旦用戶（UB）決定共享其實例（I），則該實例將與服務(wù)器通信，并轉(zhuǎn)發(fā)I的基本信息，比如操作系統(tǒng)、硬件配置和剩余共享時間。服務(wù)器需要給出可執(zhí)行二進制程序P作為響應(yīng)，可執(zhí)行程序中嵌入了密鑰kP。假設(shè)kP受到程序模糊技術(shù)的保護，且IB無法從P處獲得kP（見圖2）。

此外，服務(wù)器將周期性地更改kP，并重新編譯二進制程序。在接收到P時，I將把P作為一種服務(wù)加以運行，并準備好接收其他用戶的請求。另一方面，服務(wù)器把IB添加到可被共享的可用實例列表中。最后，每個被共享實例I可設(shè)置一個調(diào)度任務(wù)以便在額外收費出現(xiàn)前自動關(guān)閉實例。在關(guān)閉期間，I將通知服務(wù)器S誰將因此把I從可共享實例列表中刪除。

發(fā)送方UA向服務(wù)器S發(fā)送一個共享實例請求。在響應(yīng)中，除了與單用戶操作相同的信息外，服務(wù)器還會額外發(fā)送回一個證書{UA，I}k，該證書是請求用戶ID和分配實例I的簽名。UA將會把加密后的安全證書、源文件位置（Fsrc）和中間文件位置（URIF）上傳給I。然后，UA將會把共享實例I和目標文件的位置（URIF）通知給接收方UB。該消息還附有來自S的證書，以便接收方可驗證共享實例I是否合法。接著，接收方UB向服務(wù)器發(fā)送一個含有UA和I的請求，確認有一個共享實例I為UA提供服務(wù)之后，服務(wù)器將向UB返回RB和kB，以便UB可按照與UA相同的方式對其安全證書加密。最后，UB向共享實例I上傳加密后的安全證書、中間文件位置（URIF）及目標文件位置（Fdst）。

5 性能評估

本章給出了FM-CI在實驗中的性能評估結(jié)果。將FM-CI部署在支持Dropbox存儲服務(wù)的安卓平臺上，并在Google Nexus智能手機上對其進行了測試。對基于云輔助的操作，文中使用Amazon Web Service（AWS）[5]提供的服務(wù)，所有實驗在Micro實例上進行。考慮的主要性能指標包括時間開銷和帶寬消耗。對每種實驗配置，本文進行5次獨立實驗，然后取均值并在本章中給出。

5.1 基本的文件操作

下面首先給出正式Dropbox API接口實現(xiàn)的基本文件操作的帶寬消耗情況。在該測試中，利用包含1000個測試文件（每個22B）的“test”文件夾來創(chuàng)建一個新的Dropbox賬戶。測試的操作包括：1）登錄Dropbox；2）創(chuàng)建/刪除一個文件夾（在根目錄下）；3）創(chuàng)建/刪除/重命名一個文件（在“test”文件夾下）；4）進入/離開一個文件夾（“test”文件夾）。

對每種文件操作，Dropbox服務(wù)器要求附上安全證書，且通信過程基于安全套接層（Secure Socket Layer， SSL）。如圖3所示，登錄過程消耗的帶寬最多，原因一方面是由于進行驗證，另一方面是由于Dropbox API接口不斷地獲取元數(shù)據(jù)以便與本地影子文件系統(tǒng)同步或?qū)Ρ镜赜白游募到y(tǒng)進行更新。創(chuàng)建和刪除一個空文件夾需要分別消耗7.3KB和3.9KB，在所有測試操作中的成本最低。創(chuàng)建和刪除一個文本文件的情況與前一情況類似。當測試“test”文件夾時，將會導致更多的帶寬消耗（15.5KB和11.2KB）。原因是由于該文件夾包括1000個其他文件，一旦文件夾發(fā)生變化，Dropbox API接口將重新獲取里面列表上的文件。最后，當用戶進入文件夾然后離開時，帶寬成本（9.7KB）略低于創(chuàng)建/刪除文件情況。

5.2 云輔助的高級文件操作

下面評估FM-CI中基于云輔助的文件操作，尤其是文件下載和壓縮。首先給出開啟一個云實例的開銷，然后給出如果有云實例可用時文件操作的性能。用于評估的工作負載包括4組文件：1幅圖片（16MB）、5幅圖片（83MB）、2個視頻片斷（63MB和127MB）。

開啟一個云實例的開銷 選擇一天中的不同時間進行了5組測試，每組測試包括5次AWS Micro實例開啟操作，當用戶可以登錄實例時操作結(jié)束。開啟云實例的開銷見圖4。總體來說，該操作非常耗時，因為所有的測試場景下實例開啟時間均超過15s。在發(fā)送完請求后，用戶必須要等待較長時間，直到云實例將要準備好為止。在本節(jié)其余部分，性能開銷不包括實例開啟的初始階段。

下載操作的開銷 在該測試中，本文設(shè)置云實例下載工作負載中的文件，并將其上傳到Dropbox存儲空間中。目標文件寄存于某一服務(wù)器中。從表1可以看出，上傳/下載開銷與文件尺寸基本成正比。上傳的速度要快于下載，因為使用的實例（AWS EC2）和Dropbox服務(wù)（AWS S3）屬于同一云服務(wù)提供商。總體來說，傳輸率為12.9Mb/s，遠高于通過蜂窩網(wǎng)絡(luò)將文件下載到智能手機再將其上傳到Dropbox云存儲空間上。

壓縮操作的開銷 測試了Dropbox文件的壓縮操作。具體來說，文中使用gzip對下載到云實例上的文件進行壓縮，然后將壓縮后的文件上傳到Dropbox云存儲空間上。表2給出了該操作的時間開銷情況。上傳過程正常來說開銷最大，其次是下載和壓縮過程。FM-CI中該操作的速度較快。例如，壓縮1幅圖像和5幅圖像總共耗時10.4s和38.7s。這兩種情況下壓縮文件的體積分別為7.7MB和40.0MB。

高級文件操作的帶寬消耗 高級文件操作的帶寬消耗比較類似，因為只需要傳輸控制信息。鑒于篇幅所限，只在表3中給出了壓縮操作的性能。包括從智能手機傳輸?shù)皆茖嵗目刂菩畔⒃趦?nèi)的上行鏈路成本非常小。下行鏈路帶寬隨著文件尺寸的不同而不同，主要被匯報操作狀態(tài)的周期性心跳消息所消耗。

5.3 用戶間的文件傳輸

在該操作中，實例從發(fā)送方的存儲空間中下載目標文件，然后上傳給接收方的存儲空間。當使用共享實例時，與受信任服務(wù)器進行通信的額外成本與總體性能相比可忽略不計。表4給出了利用共享實例進行文件傳輸時導致的時間和帶寬開銷（發(fā)送方和接收方）。在本文部署中，服務(wù)器處寄存的二進制程序為4.9MB。

5.4 不同方案的對比

最后，為了進一步體現(xiàn)本文系統(tǒng)的優(yōu)越性，將本文設(shè)計的FM-CI和目前最新的SmartDiet方案[10]和CloudShield方案[11]在時間開銷和能耗方案進行了對比，實驗結(jié)果分別如圖5和表5所示。圖5給出了上傳/下載5幅圖片時三種方案的時間開銷對比結(jié)果，可以看到，無論是上傳還是下載操作，F(xiàn)M-CI的時間開銷總是小于SmartDiet和CloudShield。這主要是因為FM-CI允許用戶互相之間共享云實例，從而避免了系統(tǒng)頻繁開啟云實例所需要消耗的那一部分時間，因此取得了更好的結(jié)果。

表5給出了傳輸不同負載時三種方案的能耗對比結(jié)果。可以看到，隨著傳輸負載的增加，三種方案的能耗都在迅速上升。但總的來說FM-CI的能耗要低于SmartDiet 和CloudShield。這主要是因為SmartDiet 和CloudShield都是將目標文件下載到自己的智能手機上，然后通過近距離通信手段將文件傳輸?shù)浇邮辗降氖謾C上，當文件較大時，能耗也將激增。而FM-CI利用云實例來幫助用戶在各自云存儲空間之間傳輸文件，它從發(fā)送方的云存儲空間獲取目標文件，然后將其發(fā)送到接收方的云存儲空間。通過這種方式，發(fā)送方和接收方的智能手機可以不用保存目標文件的本地拷貝，因此極大地降低了系統(tǒng)能耗。

6 結(jié)語

本文設(shè)計了面向智能手機的云存儲系統(tǒng)FM-CI，它通過利用云實例來幫助智能手機用戶對云端的文件進行管理。FM-CI豐富了文件操作種類，且不需要本地的文件拷貝； 此外，F(xiàn)M-CI支持用戶間傳輸文件， FM-CI中的所有文件操作可安全運行于共享實例上。下一步工作的重點是研究面向智能手機的云數(shù)據(jù)隱私保護問題，進一步提高移面向移動設(shè)備的云服務(wù)安全性。

參考文獻：

[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] 吳昊， 范九倫， 劉建華， 等. 基于指紋魔方算法的云存儲數(shù)據(jù)保護機制[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] 鄭凱， 朱林， 陳優(yōu)廣. 基于 Kademlia 的負載平衡云存儲算法[J]. 計算機應(yīng)用， 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] 林偉偉， 賀品嘉， 劉波. 云存儲系統(tǒng)的能耗優(yōu)化節(jié)點管理方法[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.

第6篇

關(guān)鍵詞：辦公自動化系統(tǒng) 電子文件 管理

高速信息網(wǎng)絡(luò)時代，各種信息系統(tǒng)廣泛地應(yīng)用到人們的工作中，如PDM、ERP等，其中辦公自動化系統(tǒng)（Office Automation，簡稱OA）即是在各單位廣泛應(yīng)用的一種系統(tǒng)。

一、辦公自動化系統(tǒng)是將現(xiàn)代化辦公和計算機網(wǎng)絡(luò)功能結(jié)合起來的一種新型的辦公方式

從上世紀80年代起步，經(jīng)歷了起步階段（個體辦公）、應(yīng)用階段（網(wǎng)絡(luò)信息）、發(fā)展階段（知識管理）。OA系統(tǒng)經(jīng)過多年的發(fā)展已經(jīng)趨向成熟，功能由原先的行政辦公信息服務(wù)，逐步擴大延伸到組織內(nèi)部的各項管理活動環(huán)節(jié)，成為組織運營信息化的一個重要組織部分。許多單位使用OA系統(tǒng)傳遞信息、處理公文、進行事務(wù)管理，極大地提高了工作效率。

OA系統(tǒng)有各項功能，其中最主要的功能之一是公文處理。公文，也被稱為文件，是人們開展管理活動的一種基本方式，也是管理中的重要資源，其對管理的意義重大，有人曾說，辦公即辦文。傳統(tǒng)的辦公模式是以紙質(zhì)文件、紅頭印章為標志，文件在處理完畢后，其中有價值的，被保存成檔案，成為日后備查的憑證。在OA系統(tǒng)中傳輸處理的公文被稱為電子公文或電子文件。由于利用了網(wǎng)絡(luò)，OA系統(tǒng)中的電子文件在處理速度、便捷性等方面有了傳統(tǒng)公文模式無法比擬的優(yōu)點，有人認為無紙辦公、數(shù)字化辦公時代的已經(jīng)到來。

但是，由于OA系統(tǒng)在設(shè)計開發(fā)中的問題，OA系統(tǒng)中的電子文件管理存在一系列的問題，包括：OA系統(tǒng)中的安全性問題、OA系統(tǒng)中電子文件與檔案的一體化管理問題、OA系統(tǒng)中的電子文件元數(shù)據(jù)標準問題、OA系統(tǒng)中電子文件保存格式問題等。這些問題不解決，OA系統(tǒng)中的電子文件就不可能起到檔案的憑證作用，無紙辦公時代也不可能到來。國家檔案局推薦的管理方式仍然是“雙套制”，既要保存OA系統(tǒng)中的電子文件，又要把OA系統(tǒng)中電子文件轉(zhuǎn)化為紙質(zhì)文件保存，檔案管理人員的工作量不但沒有減少，反倒增加了。

因此，從檔案管理、電子文件管理的角度來看OA系統(tǒng)中電子文件處理的需求特點、功能，提出適合檔案管理的OA系統(tǒng)的模式，完善OA系統(tǒng)在電子文件管理方面的功能。不僅在電子文件管理理論上要有所創(chuàng)新，而且對于OA和其它信息管理系統(tǒng)中電子文件管理都具有重要參考應(yīng)用價值。

二、國內(nèi)外檔案學界對于電子文件的特點、電子文件管理的原則、電子文件管理系統(tǒng)（ERMS）開發(fā)方面不僅有系統(tǒng)的研究，也有一些實踐

OA系統(tǒng)和電子文件管理系統(tǒng)有不同的特點，將OA系統(tǒng)和電子文件管理系統(tǒng)進行分析比較， OA系統(tǒng)在電子文件管理方面的功能要求，需進一步改進現(xiàn)有的OA系統(tǒng)的電子文件管理功能。

國內(nèi)外的檔案學者普遍認為，紙質(zhì)文件是穩(wěn)定的（stable）、永久的（permanent）、靜態(tài)的（static）、消極的（inactive）、固定的（fixed）、嚴格的（rigid）；而電子文件是不穩(wěn)定的（unstable）、非永久的（impermanent）、動態(tài)的（dynamic）、積極的（active）、交互式的（interactive）、流動的（fluid）、可變的（transformable），電子文件的這些特性導致了記錄方式的重大革命，傳統(tǒng)紙質(zhì)文件的管理理念、模式、制度、技術(shù)、方法等都無法管理電子文件。電子文件在給我們的工作生活帶來極大便捷和效率的同時，也產(chǎn)生了許多難題和嚴峻挑戰(zhàn)，包括真實性挑戰(zhàn)、真實性挑戰(zhàn)、長期保存挑戰(zhàn)等，要想使各類系統(tǒng)中的電子文件符合檔案管理的要求，必須樹立全程管理、前端控制、風險管理的理念。

在OA系統(tǒng)方面，國內(nèi)外的學者認為基于網(wǎng)絡(luò)的OA系統(tǒng)經(jīng)歷了多年的發(fā)展，已經(jīng)日趨成熟，它不僅是處理信息和事務(wù)的工具，還應(yīng)該是知識管理的重要軟件。在軟件的開發(fā)中，不斷應(yīng)用一些新技術(shù)改造OA系統(tǒng)，如工作流技術(shù)、數(shù)據(jù)挖掘技術(shù)、簽署加密技術(shù)等。但是在OA系統(tǒng)中的電子文件管理方面，還存在一些不理想的狀況，如現(xiàn)有的OA系統(tǒng)的元數(shù)據(jù)使用沒有統(tǒng)一標準，各個軟件公司自行設(shè)計元數(shù)據(jù)方案，致使不同的系統(tǒng)之間無法交換數(shù)據(jù)；現(xiàn)有的OA系統(tǒng)在電子文件保存格式方面也沒有統(tǒng)一標準，在系統(tǒng)中各類文件格式都有，致使有些格式無法向檔案部門移交；許多OA系統(tǒng)在設(shè)計時僅僅考慮了公文處理和傳輸?shù)男枨螅瑳]有考慮文件轉(zhuǎn)化為檔案永久保存的需要，致使在系統(tǒng)中的文件難以轉(zhuǎn)換成檔案。

考慮到其理論意義與應(yīng)用價值，顯然需要將檔案管理的理論與方法應(yīng)用到OA系統(tǒng)的開發(fā)與應(yīng)用中去，否則的話，OA系統(tǒng)中電子文件很難具有相應(yīng)的憑證價值，檔案管理人員仍然無法從“雙套制”得到解放。因此，從檔案學的角度對OA系統(tǒng)中的電子文件管理進行研究便成為現(xiàn)在檔案管理中的一個重要研究課題。

三、OA系統(tǒng)在大中型企事業(yè)單位中已經(jīng)廣泛應(yīng)用，但是OA系統(tǒng)中的電子文件管理功能卻不完善

OA系統(tǒng)能處理信息，卻不能保存檔案，有的單位想進行完全的無紙化辦公，解放人力，卻又有種種顧慮。大中型企事業(yè)單位的OA系統(tǒng)使用狀況也存在問題，這就需要進一步提出符合電子文件管理要求的OA系統(tǒng)的功能模型，為OA系統(tǒng)的開發(fā)提供參考，加速檔案管理信息化的進程。

對OA系統(tǒng)中的電子文件管理功能首先要通過實證研究的方法，總結(jié)不同的系統(tǒng)的功能要求，再通過實證調(diào)研的方法，分析OA系統(tǒng)在電子文件管理方面的規(guī)律；通過對比研究，明確現(xiàn)有的OA系統(tǒng)在電子文件管理方面的不足，強調(diào)在信息網(wǎng)絡(luò)時代，以檔案管理的理論為指導，構(gòu)建符合檔案管理需求的OA系統(tǒng)，強化OA系統(tǒng)中的電子文件管理以及與檔案管理實現(xiàn)無縫連接。

四、對社會經(jīng)濟發(fā)展和學科建設(shè)的作用和意義

機關(guān)檔案室是我國檔案事業(yè)的基礎(chǔ)，從80年代開始，我國就在進行機關(guān)檔案體制改革的嘗試，但成效甚徽。隨著信息技術(shù)的廣泛應(yīng)用，對機關(guān)檔案室管理的改革時機也日益成熟。對其檔案室的管理模式、管理方法、管理技術(shù)進行系統(tǒng)研究，使檔案信息在其形成之時就能進行整合，包括和政務(wù)信息網(wǎng)的整合，以及檔案信息網(wǎng)的整合，提高管理效率，促進我省乃至全國的政府信息化建設(shè)和檔案信息化建設(shè)。

同時，對檔案學科的發(fā)展也具有重要的意義。一是檔案檔案室管理模式的探索是檔案學領(lǐng)域的一個非常重要的研究問題，許多學者分析了美國文件中心的優(yōu)點，但在我國由于體制等原因一直無法實施，近年來，有學者提出，將機關(guān)檔案室合并為文件中心的條件日漸成熟，但還沒有人進行深入的研究。另外，在信息技術(shù)發(fā)展的今天，各省的檔案館都紛紛提出要建設(shè)數(shù)字檔案館，但作為數(shù)字檔案館的基礎(chǔ)――機關(guān)檔案室卻缺少相應(yīng)的管理規(guī)范，顯然應(yīng)該從檔案的源頭開始做好數(shù)字化規(guī)范工作，也有利于數(shù)字檔案館的進一步發(fā)展和研究。

第7篇

論文摘要：本系統(tǒng)以文檔管理為核心，利用先進的計算機軟件技術(shù)，有效地控制各種文檔的產(chǎn)生，管理文檔的存取訪問，對文檔進行有效管理。

1開發(fā)背景

辦公管理系統(tǒng)是在網(wǎng)絡(luò)技術(shù)飛速發(fā)展的情況下推出的新概念，而在圖書館歷經(jīng)了傳統(tǒng)圖書館和自動化圖書館開始進入數(shù)字化圖書館階段的今天，辦公管理系統(tǒng)的引入更使圖書館界如虎添翼。在辦公信息化的大潮下，文件管理的信息化管理尤為重要。筆者近年經(jīng)歷了本校的本科教學工作水平評估、升格師范大學水平評估以及業(yè)內(nèi)的圖書館評估，對文件管理的重要性體會頗深，大量的歷年的文件、業(yè)務(wù)檔案及不斷修訂的規(guī)章制度等，如果有一種有別于圖書分類法的一個檔案管理系統(tǒng)，那么我們的工作效率會事半功倍。由此筆者針對圖書館的特點申請了一項課題，組織人員研制出一套文件管理系統(tǒng)：海南師范大學圖書館文件管理系統(tǒng)。

2平臺簡介

本系統(tǒng)是采用當前運用最廣泛的B／S結(jié)構(gòu)模型，后臺采用Microsoft Access作為數(shù)據(jù)庫。Access是微軟公司推出的基于Windows的桌面關(guān)系數(shù)據(jù)庫管理系統(tǒng)(RDBMS)，是Office系列應(yīng)用軟件之一。它提供了表、查詢、窗體、報表、頁、宏、模塊7種用于建立數(shù)據(jù)庫系統(tǒng)的對象，提供了多種向?qū)А⑸善鳌⒛０澹褦?shù)據(jù)存儲、數(shù)據(jù)查詢、界面設(shè)計、報表生成等操作規(guī)范化，為建立功能完善的數(shù)據(jù)庫管理系統(tǒng)提供了方便，也使得普通用戶不必編寫代碼就可以完成大部分數(shù)據(jù)管理的任務(wù)。

前臺所用的ASP語言(Active Server Pages)是微軟公司為了克服CGI嚴重的擴展性問題而開發(fā)的。解決了多用戶訪問進程，有效地利用了網(wǎng)絡(luò)資源。ASP技術(shù)簡化了Web程序開發(fā)，支持動態(tài)Web設(shè)計。ASP只用于服務(wù)器端，執(zhí)行動態(tài)的、交互式的、高效率的站點服務(wù)器應(yīng)用系統(tǒng)。ASP以標記語言的形式嵌入到HTML中并發(fā)送到客戶端，但是，顯示在客戶端瀏覽器的只是ASP執(zhí)行結(jié)果所生成的頁面，而其本身根本看不到，所以安全性很好。同時，ASP也支持腳本語言，只要服務(wù)器端裝了腳本引擎就可以方便地架構(gòu)網(wǎng)站。

系統(tǒng)運行環(huán)境是微軟的lIs(Internet Information Server)，它把World WideWebserver，Gopher server和FtPsevrer全部包容在里面。IIs能網(wǎng)頁，并且由ASP，Java，VBscript產(chǎn)生頁面，有著一些擴展功能。IIs支持有編輯環(huán)境的界面(FRONTPAGE)、有全文檢索功能的界面(INDEX SERVER)、有多媒體功能的界面(NET SHOW)，IIS6．0包括許多新功能，它們旨在幫助企業(yè)、lT專業(yè)人士和Web管理員實現(xiàn)其網(wǎng)站(他們可能擁有位于單個Ils服務(wù)器或多個服務(wù)器上的數(shù)千個網(wǎng)站)在性能、可靠性、可伸縮性和安全性方面的目標。

ASP+Access+IIs開發(fā)中小型網(wǎng)絡(luò)系統(tǒng)一直被視為黃金組合，這樣的結(jié)合對系統(tǒng)的資源占用適宜，每個部分都能很好地發(fā)揮其功能，在數(shù)據(jù)的處理能力和安全性上也有很好的選擇。

3系統(tǒng)主要功能介紹

3．1普通用戶

3．1．1登錄驗證

為了確保本系統(tǒng)特殊用戶的單一性和系統(tǒng)的安全性，系統(tǒng)不設(shè)置注冊功能，所有賬號和初始密碼均由普通用戶向管理員申請。

3．1．2用戶信息查看及修改

用戶可以對自己的基本資料(如姓名、所在部門、E—mail、聯(lián)系電話等)以及密碼進行瀏覽和修改。

3．1．3查看文件

該模塊的主要功能就是對文件、檔案資料(如相關(guān)文件、工作計劃、工作總結(jié)、月報、年報等日常工作文檔)共享，由管理員負責上傳，普通用戶可以瀏覽和下載。

3．1．4用戶上傳待審核文檔

該模塊針對由下級部門擬訂的文檔提供一個審核功能，如月報、年報、讀者意見反饋、館際交流、各部門統(tǒng)計報告等，待審定后再上傳到數(shù)據(jù)庫。

3．1．5文件檢索

為了加快用戶對文件檔案的查找速度進而提高辦公效率，系統(tǒng)設(shè)計了一個專門的文件檢索功能，包括普通檢索和高級檢索。

普通檢索：可提供文件名、主題、分類號、文件號、發(fā)文單位及發(fā)文時間等檢索途徑(見圖1)。

高級檢索：提供了普通檢索所具有的檢索途徑，并進行組配檢索(見圖2)。

3．2管理員

3．2．1登錄驗證

管理員的后臺管理登錄可以通過在首頁右下角處點擊“管理員入口”，進入管理員操作界面，進行身份驗證并登錄系統(tǒng)。

3．2．2管理員信息查看及修改

管理員可以對自己的基本資料(姓名、所在部門、E—mail、聯(lián)系電話等)以及密碼進行瀏覽和修改。

3．2．3用戶管理

管理員可對系統(tǒng)的普通用戶進行分配，同時還可以對用戶的基本資料進行查看、修改和刪除用戶，以確保數(shù)據(jù)庫的保密性和安全性。

3．2．4文件管理

對文件進行管理是本系統(tǒng)的主要目的，在文件管理模塊巾，管理員可以上傳文件、修改文件和刪除文件，同時也可以對文件進行瀏覽和下載。

3．2．5審核文件

本系統(tǒng)提供了文件審核功能．普通用戶上傳的文件只有經(jīng)過管理員審核才能，確保了文件著錄的規(guī)范性和管理的科學性。

3．2．6文件檢索

管理員用戶是通過管理員進行區(qū)分的，對管理員來說，在日常工作中對文件的檢索也是必不可少的，檢索結(jié)果出來后可進行瀏覽和下載。

3．2．7服務(wù)器信息

為了方便管理員能實時了解服務(wù)器的信息以及對服務(wù)器的運作情況進行監(jiān)控，系統(tǒng)設(shè)計了一個服務(wù)器實時信息反饋模塊。可查看服務(wù)器的有關(guān)參數(shù)、組件支持情況巾的IIS自帶的ASP組件、常見的文件上傳和管理組件。

4系統(tǒng)功能特色

4．1系統(tǒng)低成本性

由于系統(tǒng)本身的開發(fā)工具語言和運行平臺的簡單性，決定了系統(tǒng)在架構(gòu)和運行維護上的成本都是比較低的；不僅如此，在需求分析階段，對各種需求結(jié)合開發(fā)工具設(shè)計，使得系統(tǒng)在最大限度上發(fā)揮了系統(tǒng)數(shù)據(jù)庫以及腳本語言的特色，使得系統(tǒng)在運行時對資源的占用相對較少，大大地提高了運行速度，為快速辦公打下了堅實的基礎(chǔ)。

4．2穩(wěn)定的安全性

首先，本系統(tǒng)考慮到用戶是有針對性的特殊群體，每個人都能進人但又必須通過身份驗證；其二。本系統(tǒng)不提供注冊功能，要想得到賬號和密碼必須向管理員提出申請，由管理員統(tǒng)一分配賬號，預(yù)防不法者對內(nèi)部資料檔案的竊取；其三，本系統(tǒng)在開發(fā)過程中通過對“session”變量的合理運用，防止不法者通過直接對URL的訪問來跳過身份驗證頁面進而訪問系統(tǒng)的其他資源頁面，一旦用戶沒有通過登錄頁面的身份驗證，系統(tǒng)將其他頁面進行隱藏，非法用戶將瀏覽不到任何資源。另外，系統(tǒng)通過對“session”變量的時間設(shè)置，一旦用戶停止操作時間過長，系統(tǒng)會要求用戶進行重新登錄進行身份驗證，從而在最大限度上保證了系統(tǒng)內(nèi)部資料的安全性。

4．3良好的交互性

系統(tǒng)通過在各個頁面中對各個操作步驟的人性化提示，使得一些電腦操作技能較弱的用戶也能在最短時間內(nèi)掌握基本的操作，從而對提高辦公效率起著不可或缺的作用。

4．4文件管理的科學性

在需求分析過程中，筆者考慮到文件及檔案資料可由不同層次部門產(chǎn)生的特點(如由上級分發(fā)的文件，同級之間的函件，下級的申請，各種業(yè)務(wù)統(tǒng)計等)，特別設(shè)計了文件審核這一流程，各種文件在前都必須經(jīng)過管理員的審核，為文件著錄的規(guī)范性和文件管理的科學性提供了前提保證。

4．5組配檢索功能

隨著數(shù)據(jù)庫規(guī)模的擴大，檔案數(shù)據(jù)量增多，就必然需要一種可實現(xiàn)多途徑檢索的功能，為此系統(tǒng)專門設(shè)計了高級檢索功能，檢索途徑針對辦公文件及日常檔案的特點而設(shè)定。對字段內(nèi)容比較特殊的文檔可通過普通檢索查詢，而對字段內(nèi)容很普通的文檔則可通過高級檢索來進行查找，即通過對多字段的邏輯組配，并選擇相應(yīng)的匹配模式，實現(xiàn)高級檢索。組配檢索使檢索命中率大大提高，解決了檔案管理巾存在的弊端，大大地節(jié)約了查找文件、檔案資料的時間，從而提高了信息化辦公的效率。

4．6數(shù)據(jù)信息類型多元化

本系統(tǒng)的數(shù)據(jù)信息包含文本、圖像、視頻、音頻或任何其他類型的信息數(shù)據(jù)。

5結(jié)語

第8篇

關(guān)鍵詞：報表生成；戰(zhàn)斗文件；管理信息系統(tǒng)；安全；數(shù)據(jù)庫

中圖分類號：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

一、引言

軍隊信息化是世界新軍革的發(fā)展趨勢，建設(shè)信息化軍隊也是我軍在新形勢下能有效履行新使命的必然要求。運用現(xiàn)代信息技術(shù)促進文件管理工作的發(fā)展與飛躍具有重要的意義。當前我國邊防部隊各級機關(guān)使用的信息系統(tǒng)，大部分是2005年以前配發(fā)或自行設(shè)計的，無論是在技術(shù)架構(gòu)、業(yè)務(wù)流程處理、數(shù)據(jù)共享上都難以滿足當前以及今后一個時期發(fā)展的需要。由于大部分系統(tǒng)使用的是單機版軟件，各單位人員在本機錄入數(shù)據(jù)，使用數(shù)據(jù)，無法同他人共享數(shù)據(jù)、共同處理業(yè)務(wù)；同時，由于這些軟件設(shè)計欠規(guī)范、技術(shù)落后、接口不標準、平臺不統(tǒng)一等，造成了大量的信息不完整及不合時誼的現(xiàn)象。這種情況給全面掌握文件情況，正確分析文件保管現(xiàn)狀帶來了較大的困難。

本系統(tǒng)能科學采集、分類、存儲目前邊防部隊的戰(zhàn)斗文件信息，并能完成對戰(zhàn)斗文件的查詢、生成報表、查看下級單位戰(zhàn)斗文件管理情況等。圍繞該系統(tǒng)的功能實現(xiàn)進行研究與探討。它的設(shè)計與實現(xiàn)是一個很復雜的系統(tǒng)工程，是局域網(wǎng)技術(shù)與信息系統(tǒng)開發(fā)方法的統(tǒng)一。

二、系統(tǒng)分析

（一）功能需求分析

邊防部隊戰(zhàn)斗文件管理信息系統(tǒng)是面向某邊防部隊戰(zhàn)斗文件管理業(yè)務(wù)部門的軍、師（軍分區(qū)）、團（人武部）、營、連五級的管理信息系統(tǒng)，它的要求比較具體。

首先，各級戰(zhàn)斗文件管理業(yè)務(wù)部門能對收文、發(fā)文等進行管理，對收發(fā)文數(shù)據(jù)進行添加、修改、查詢、刪除，按規(guī)定對收發(fā)文進行銷毀并能查詢歷史銷毀文件情況，對收發(fā)文數(shù)據(jù)進行統(tǒng)計分析并生成報表，對規(guī)章制度、業(yè)務(wù)往來單位進行管理。

其次，統(tǒng)計與報表生成要能根據(jù)不同的條件對所有的文件進行查詢，能按照時間段、承辦業(yè)務(wù)部門、操作人、發(fā)往單位等多種情況進行統(tǒng)計，并能根據(jù)統(tǒng)計出的結(jié)果由用戶決定下載顯示頁、所有記錄還是前100條記錄，以便管理者準確了解戰(zhàn)斗文件管理工作現(xiàn)狀，這是本文主要進行的工作之一。

再次，由于戰(zhàn)斗文件管理工作比較高，具有較強的敏感性和保密性，因而系統(tǒng)要對自己的用戶進行很好的權(quán)限設(shè)計，進行科學的管理，只有具有相應(yīng)權(quán)限的用戶才能對戰(zhàn)斗文件數(shù)據(jù)進行查詢、修改和維護，其它未授權(quán)用戶無權(quán)進行任何操作。

最后，系統(tǒng)除了對戰(zhàn)斗文件進行管理之外，還應(yīng)提供戰(zhàn)斗文件管理的一些規(guī)章制度。如軍內(nèi)各級對戰(zhàn)斗文件管理的相關(guān)規(guī)定、本單位戰(zhàn)斗文件管理的動態(tài)、業(yè)務(wù)部門的一些通知等。

（二）信息需求分析

邊防部隊戰(zhàn)斗文件管理信息系統(tǒng)要真正成為部隊戰(zhàn)斗文件管理的有力工具，就必須有可靠的數(shù)據(jù)信息來源，有完整的每份文件的信息資料。首先，要對部隊戰(zhàn)斗文件管理的組織結(jié)構(gòu)有較全面的了解，戰(zhàn)斗文件各個階段的工作者和管理機構(gòu)有哪些，職責如何，權(quán)限如何分配。其次，要知道文件信息的錄入、刪除和銷毀方法，戰(zhàn)斗文件管理的有關(guān)規(guī)定等。

部隊戰(zhàn)斗文件管理主要實行首長責任制，由各級政治主官主抓，由司令部門實施，軍級由機要處、師級由機要科（辦）、團級由機要股、營連級由文書負責落實。戰(zhàn)斗文件的分類可按收發(fā)文、秘密等級兩種方法，詳細情況如圖1、圖2所示。

圖1 按收發(fā)文分

圖2 按秘密等級分

邊防部隊戰(zhàn)斗文件管理工作業(yè)務(wù)主要包含以下幾方面內(nèi)容：收文、發(fā)文、統(tǒng)計與報表、銷毀文件、熟習相關(guān)規(guī)章制度。以上業(yè)務(wù)皆由各級機要部門負責落實，具體包括：戰(zhàn)斗文件的接收與發(fā)出，維護收發(fā)文數(shù)據(jù)，統(tǒng)計收發(fā)文情況并根據(jù)需要生成報表，定期銷毀不需要留存的文件，查詢銷毀歷史，熟習相關(guān)規(guī)章制度。

戰(zhàn)斗文件管理工作有其嚴格規(guī)范的工作管理流程，一份戰(zhàn)斗文件從收到或發(fā)出到銷毀過程中的各種信息都要記錄在數(shù)據(jù)庫里。以一份上級下發(fā)至本級的收文為例：收到文件后，機要部門登記相關(guān)文件信息，然后將文件送到相關(guān)業(yè)務(wù)部門并登記接收該文件的業(yè)務(wù)部門人員，接收時間等要素；在業(yè)務(wù)保存期間，可以查詢、統(tǒng)計該文的詳細信息；到了年底回收該文件進行銷毀，銷毀時登記銷毀人、監(jiān)銷人和銷毀時間。這些變化都會記錄在數(shù)據(jù)庫中。由此可見，戰(zhàn)斗文件在收到和銷毀狀態(tài)中的所有業(yè)務(wù)都會與機要部門、數(shù)據(jù)庫發(fā)生聯(lián)系。

邊防部隊戰(zhàn)斗文件管理信息系統(tǒng)的主要工作流程如圖3所示。

圖3 收發(fā)戰(zhàn)斗文件流程

三、系統(tǒng)設(shè)計

在對系統(tǒng)進行功能需求分析和信息需求分析后，我們要對系統(tǒng)進行詳細設(shè)計。

（一）功能模塊劃分及描述

戰(zhàn)斗文件信息管理的主要工作有收發(fā)文管理、統(tǒng)計報表、文件銷毀、瀏覽下級、規(guī)章制度等。為了既加強系統(tǒng)的安全性，又方便系統(tǒng)用戶，系統(tǒng)還需設(shè)置登錄管理模塊。根據(jù)以上需求分析，本系統(tǒng)可分為六大功能模塊，如圖4所示。

圖4系統(tǒng)模塊圖

1.登錄管理

管理用戶的登錄驗證。在設(shè)計這個模塊的過程中，主要涉及兩方面的技術(shù)：一是3.5平臺提供的Login控件使用；二是利用3.5平臺提供的成員資格管理API實現(xiàn)用戶登錄驗證。

2.收發(fā)文管理

它是整個戰(zhàn)斗文件管理系統(tǒng)中最基本的子系統(tǒng)。可以實現(xiàn)戰(zhàn)斗文件信息的錄入、刪除、查詢和修改功能，如：進行新文件的錄入、系統(tǒng)中文件信息的變動管理。另外，它還提供了靈活的查詢界面，可以根據(jù)動態(tài)的查詢組合條件查詢到文件的各種相關(guān)信息。設(shè)計戰(zhàn)斗文件信息的添加、修改、刪除、查詢等功能需要運用數(shù)據(jù)源的訪問和數(shù)據(jù)顯示兩個技術(shù)。

3.統(tǒng)計報表

根據(jù)提供的日期選擇控件選擇一個時間段或（及）其他限制條件（文件名、業(yè)務(wù)部門、文件號等）進行統(tǒng)計。統(tǒng)計結(jié)果將逐條列出并提供下載報表。報表生成將根據(jù)列出的記錄生成EXCEL格式統(tǒng)計結(jié)果并供用戶下載到本地磁盤以供決策者參考。

4.文件銷毀

根據(jù)業(yè)務(wù)部門、文件號、傳號、時間段等關(guān)鍵字進行靈活多樣化的組合查找出要銷毀的文件并依時間順序顯示，并可批量登記銷毀人，監(jiān)銷人，銷毀時間等要素。銷毀時間自動填寫當前時間。

5.規(guī)章制度

該模塊主要用于與戰(zhàn)斗文件管理有關(guān)的規(guī)章制度的和瀏覽。有利于文件管理者熟習相關(guān)規(guī)定，處理日常業(yè)務(wù)。

6.系統(tǒng)維護

是系統(tǒng)能有效利用的重要組成部分，包括與本單位相關(guān)的來文單位、發(fā)文單位的維護以及本單位業(yè)務(wù)部門的維護等本級管理和系統(tǒng)管理員才能操作的單位標識維護與系統(tǒng)用戶管理。其中系統(tǒng)用戶維護用于對用戶分配權(quán)限和進行訪問控制，是確保系統(tǒng)數(shù)據(jù)安全的重要方面。

（二）基于BLP模型的用戶權(quán)限設(shè)計

為使系統(tǒng)的保密性、數(shù)據(jù)的可靠性、統(tǒng)計的多樣性都能得到保障，在充分分析BLP模型性能的情況下，我們提出基于BLP模型的用戶權(quán)限設(shè)計方案來設(shè)計本系統(tǒng)的用戶權(quán)限。本系統(tǒng)用戶角色有：省軍區(qū)、軍分區(qū)、邊防團、邊防營、邊防連。

為有效管理系統(tǒng)用戶，我們對本系統(tǒng)的每個使用單位和每個工作人員分別分配一個單位標識和工號。它們的生成規(guī)則如下：

單位代碼生成規(guī)則：單位級別標識（1位）+所屬師級標識（2位）+所屬團標識（1位）+所屬營標識（1位）+所屬連標識（1位），共六位。如表1所示。

用戶工號生成規(guī)則：單位代碼+該用戶在本單位的序號（1位），共七位。如表2所示。

表1 各單位標識

單位 標識

省軍區(qū) 100000

第四軍分區(qū) 204000

第四分區(qū)第二團 304200

四分區(qū)第二團一營 404210

四分區(qū)第二團一營二連 504212

表2 系統(tǒng)用戶工號表

單位 上級單位 用戶 工號

省軍區(qū) 無 1號用戶 1000001

第四分區(qū) 省軍區(qū) 2號用戶 2040002（第四分區(qū)標識為04）

第四分區(qū)第二團 第四分區(qū) 1號用戶 3042001（第二團標識為2）

四分區(qū)第二團一營 第四分區(qū)第二團 1號用戶 4042101（一營標識為1）

四分區(qū)第二團一營二連 四分區(qū)第二團一營 1號用戶 5042121（二連標識為2）

四、系統(tǒng)實現(xiàn)

下面以統(tǒng)計報表和兩個模塊為例說明系統(tǒng)的實現(xiàn)過程。

（一）瀏覽下級單位收文信息

統(tǒng)計報表模塊是對普通查詢功能的拓展和完善，普通的查詢功能只能簡單的將符合條件的信息顯示出來，而統(tǒng)計報表功能除了能統(tǒng)計顯示外，還提供靈活的選擇將統(tǒng)計出的結(jié)果生成EXCEL文件并供用戶下載保存到本地磁盤，供領(lǐng)導隨時掌握收發(fā)文情況，為制定具有針對性的措施提供輔助支持。

該模塊融入到了收發(fā)文查詢?yōu)g覽、下級收發(fā)文瀏覽、收發(fā)文歷史等子模塊中，由于各子功僅僅是統(tǒng)計數(shù)據(jù)不一樣而已，所以此處僅以收文統(tǒng)計報表為例說明。

在收文統(tǒng)計報表中，當根據(jù)查詢條件顯示出相應(yīng)的記錄后（默認為顯示所有的收文記錄），可以方便的利用下方的“導出為EXCEL”按鈕和右側(cè)的“當前頁”、“所有頁”、“前面100條”等附加功能，導出顯示記錄中的當前頁記錄、所有記錄和前面100條記錄。實現(xiàn)該功能的算法如下：

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))

{

//創(chuàng)建一個包含邊框的表格

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);

}

第9篇

福建電大學生學籍管理系統(tǒng)軟件是以學籍管理為中心，面向?qū)W校領(lǐng)導、教務(wù)管理人員、以及其他有關(guān)工作人員以及學生的一體化的學籍管理系統(tǒng)軟件，可實現(xiàn)包括學生成績打印、學歷證明打印、相關(guān)信息查詢、學生成績統(tǒng)計、后臺數(shù)據(jù)管理和維護以及數(shù)據(jù)庫備份等功能。按照系統(tǒng)需要完成的功能可分為：（1）教學計劃管理：教務(wù)管理人員選擇不同的分校（教學點）、年級、專業(yè)，輸入教學計劃包括課程名稱，課程學分，選修必修等信息。（2）學生信息管理：包括學生修過的課程成績和畢業(yè)情況，還包括課程成績錄入：選擇不同的分校（教學點），學生的年級專業(yè)，在輸入學生基本信息的同時系統(tǒng)根據(jù)學生的年級，專業(yè)等基本信息自動查詢生成學生應(yīng)修的學科，并在同一個頁面中顯示學生所有課程的成績。（3）查詢學生信息：普通用戶通過輸入學生的姓名、年級、分校（教學點）、學號其中的若干個模糊信息來查詢到該學生的所修課程成績和畢業(yè)情況。（4）學籍數(shù)據(jù)統(tǒng)計：教務(wù)管理人員可根據(jù)分校工作站、年份、專業(yè)等關(guān)鍵字統(tǒng)計對應(yīng)的學籍檔案數(shù)據(jù)，還包括各種數(shù)據(jù)的分布圖如某課程的成績分布情況等信息。（5）權(quán)限日志功能：由超級管理員進行創(chuàng)建各用戶，并給相關(guān)用戶授權(quán)分配管理權(quán)限。查看日志，日志中對學籍檔案數(shù)據(jù)的特殊操作如修改刪除等操作記入日志，并說明操作的原因以便查對。（6）系統(tǒng)管理：由超級管理員進行包括分校、教學點、專業(yè)類型、課程形式等基本信息的維護。還包括整個系統(tǒng)得環(huán)境變量，數(shù)據(jù)庫備份等內(nèi)容。（7）開具成績證明：教務(wù)管理人員通過學生的姓名、年級、分校（教學點）、學號其中的若干個模糊信息查詢到該學生的信息后，自動打印出學生的成績表，同時記下成績證明開具時間和教務(wù)管理人員的打印記錄。（8）開具學歷證明：教務(wù)管理人員通過學生的姓名、年級、分校（教學點）、學號其中的若干個模糊信息查詢到該學生的信息后，自動打印出學生的學歷證明，同時記下學歷證明開具時間和教務(wù)管理人員的打印記錄[4]。

2、驗證和顯示控件的實現(xiàn)過程

為了解釋驗證和顯示控件的實現(xiàn)過程選用系統(tǒng)用戶登陸模塊為例。該模塊為系統(tǒng)軟件初始頁面用來驗證用戶信息。用戶通過輸入用戶名、密碼和驗證碼來登陸本系統(tǒng)。驗證碼使用系統(tǒng)隨機生成的圖片來完成，驗證碼保存在用戶的SESSION當中，當用戶的信息和數(shù)據(jù)庫中數(shù)據(jù)完全對應(yīng)的情況下，運行用戶跳轉(zhuǎn)到主頁面，同時用戶的各個信息也保存在該用戶的SES－SION中。為了用戶密碼的安全性，密碼的保存形式使用MD5加密方式。同時輸入信息的三個文本框使用AJAX技術(shù)實現(xiàn)了用戶輸入信息的提示工作。該模塊的功能有：系統(tǒng)用戶登陸與系統(tǒng)用戶驗證的功能。系統(tǒng)用戶登錄頁面代碼：為。其中CS文件中引用了系統(tǒng)的幾個必要的命名空間。登錄部分通過控件建立面板，通過作為用戶名、密碼和驗證碼的輸入框同時設(shè)置AJAX事件，實現(xiàn)輸入不能為空等基本客戶端驗證。驗證碼的圖片通過控件引用來顯示隨機的驗證碼圖片信息。為了解釋頁面布局框架的實現(xiàn)過程選用系統(tǒng)主界面模塊為例。該模塊工作主界面如圖1-2所示，各模塊主要功能包括：學籍信息查詢模塊，主要實現(xiàn)學生成績查詢和學生學歷查詢兩個子模塊功能；學籍信息輸入模塊，主要實現(xiàn)教學計劃的輸入和學生信息的輸入兩個子模塊功能；系統(tǒng)管理模塊，主要系統(tǒng)用戶管理和系統(tǒng)預(yù)設(shè)兩個子模塊功能。

3、總結(jié)