楊永利



摘要:通過調研,對比分析了傳統FTP服務器與市場上各類文檔管理系統的優勢與不足。確立以中小型企業為系統使用者,以滿足企業的特定需求為設計原則,為其設計一個靈活、高效的輕便型文檔管理系統。系統設計方面,首先整體開發以Akka-http為框架;憑借Scala與java的互操作性;其次開發過程合理地運用了java功能強大的庫函數,再結合Scala語言易擴展、高并發的后臺服務架構,最終開發出以Scala為基礎語言的系統程序。
關鍵詞:Web文檔; 管理系統;系統開發; Scala; java
中圖分類號:TP311? ? ? ? 文獻標識碼:A
文章編號:1009-3044(2019)26-0071-04
開放科學(資源服務)標識碼(OSID):
Abstract:Through the research, this thesis compares and analyzes the advantages and disadvantages of traditional FTP servers and various document management systems on the market. Establishing a small and medium-sized enterprise as a system user to meet the specific needs of the enterprise as a design principle, design a flexible and efficient portable document management system. As for system design, the overall development is based on Akka-http. With the interoperability of Scala and Java, the development process makes reasonable use of Java's powerful library functions, combined with Scala's easy-to-expand, high-concurrency background service architecture, and develops Scala-based system programs.
Key words:Web; document management; system development; Scala; java
1引言
隨著信息處理技術和網絡技術的快速發展,人們獲取信息的能力與速度大大提升,面對與日俱增的各類文檔,如何高效存放與管理成為人們亟待解決的問題。隨著電子文檔的形式和數量日益增多,我們對文檔管理的需求也在日益提高、改變。人們需要一個安全可靠的網上系統,來替我們保存整理那些對我們有用的文件[1]。
對于個人文檔管理而言,我們所需要的不僅僅是將它們安全存放起來,更要在我們需要瀏覽相應的信息內容時,能夠方便快捷的獲取。另一方面,經濟快速發展,興起了許多創業公司與SoHo辦公企業,對于公司內部的文檔,進行合理配置與管理,以此將公司積攢沉淀的知識文檔構建出該企業的知識儲備體系,能夠幫助企業更好更快發展。由此,越來越多的辦公團體、事業單位、科研機構甚至個人文件都已開始邁向信息化的管理模式,企業中的文檔資料已從紙質存儲轉變為電子存儲,并通過文檔管理系統來管理部署電子文檔[2]。
最為大家的熟知的是FTP(File Transfer Protocol),它不僅是一種HTTP協議,同時也是一個應用程序[3]。它滿足了對于文檔管理而言基本的上傳與下載功能。但是對于用戶權限的管理過于單一,且對文檔的歸檔分類需要人力操控,非常麻煩。從使用上來說,想要使用該程序,需要安裝和運行FTP客戶端,但是該程序是字符界面而不是圖形界面,這就必須以命令提示符的方式進行操作,這對于普通用戶來說,無疑是增添負擔,很不方便。若是通過ie瀏覽器進行操作,速度較慢,且容易暴露密碼,不夠安全。因此,現在很少有團體、企業使用這種方式來對文檔進行存放與管理[4-6]。
目前市場已開發的比較成熟的文檔管理系統大致可以分為三類;第一類為公有云盤,就是廠家提供云端的存儲和運維服務,用戶只需要注冊賬號,安裝客戶端就可以登錄使用,費用按照廠家給出的套餐價格來收取,較適合一二十人的小團隊,如果需要較大的云端存儲空間或者有上百人需要使用,費用會比較昂貴[7]。這類文檔的權限管理通常較為寬松。比較熟知的有:億方云,堅果云,夠快,燕麥云等。第二類為私有云盤,這類軟件產品,一般分為服務器端和客戶端,需在公司內部的服務器上先安裝服務器端,用戶通過內網訪問,這類系統適合在企業內部部署私有的文件管理系統的用戶,用戶數也能夠支持幾百到上千不等;存儲空間可以根據需求對服務器硬盤進行配置。比較熟知的有:開始云,seafile、云盒子、優米云盤等。第三類為NAS陣容,也就是定制硬件+文件管理軟件,這些產品很多針對的是個人和家庭用戶,部分中小企業用戶也會選擇NAS。但因為他們與硬件綁定,不是太靈活,總體成本也更高。
2系統的需求分析
文檔管理系統的作用是為某一個組織所有的文檔進行統一存放與管理。文檔的有效集群并對其進行合理的歸檔分類,能幫助該組織構建自身的知識庫體系,使其核心文化與知識能夠得到良好集成與發展,對于絕大多數的中小企業來說,一個合適其內部使用的文檔管理系統是十分必要的。
后續所述的系統需求以及功能板塊的設計與實現均是以中小企業的業務需求為基礎,結合實際開發難度進行業務邏輯設計與功能擴展。
2.1功能需求分析
通過前敘研究,本系統圍繞以下需求進行開發設計。
2.1.1 基礎功能
1)用戶能對文檔進行上傳、下載(各種常見類型文檔均支持)。
2)用戶能對部分文檔進行預覽,并且特定用戶能將文檔從系統中移除。
3)文檔檢索,通過關鍵字查詢,快速定位文檔,方便用戶獲取相關信息。
2.1.2 用戶權限管理
1)設置系統管理員,能對系統進行部門的添加、移除。
2)對整個系統進行群組劃分,為每一個群組設置一位管理員以方便組內管理與組間聯系。
3)各部門管理員對其所屬部門有最大權限來能管理所屬部門文檔,并且能對系統中的所有用戶進行針對該群組的權限管理。
2.1.3 文檔歸類
1)根據文檔類型進行自動分類。
2)以部門為單位進行文檔存放。
3)對每個用戶上傳的文檔進行劃分。
2.1.4 文檔權限管理
1)部門管理員可對其部門的文件進行權限管理,決定該文件對其余用戶是否可見、可用、可取。
2)管理員能對文檔進行全部操作,普通用戶需要得到相應授權。
3)用戶能越過管理員授權直接獲取或刪除自己所提供文件(自己的文件擁有最大使用權;對誤傳情況進行考慮,能夠自行刪除文件),但自身文件對于其余用戶來說,仍需得到管理員授權。
2.1.5 系統鑒權
用戶能通過注冊獲得賬號(管理員能對每個賬號進行權限管理),每一位用戶通過登陸的方式使用該系統,用戶所能執行操作均與個人信息(登陸時提供)有關。
系統需要一定手段來保障文檔安全性(使得文檔只能被有權利獲取的人使用),所以需要對每一位用戶進行鑒權,以區分不同用戶(不同權限)。
2.2非功能需求分析
在基礎功能和業務邏輯滿足用戶使用需求后,可對系統其他部分進行優化以提供用戶使用體驗。
2.2.1 實時性
用戶的每一步操作都及時處理,對于信息的變化進行及時更新。
2.2.2 并發性
支持多個用戶同時在線使用該文檔管理系統,系統中部分內容的實時修改對用戶可見,能對系統異常進行報錯與相應拋出處理。
2.2.3 穩定性
系統具備長時間工作能力,對于出現的錯誤異常,能有明確錯誤指示,以保障用戶的正常使用,并能對突發情況進行及時處理。
2.2.4 可維護性
系統采用客戶端-服務器結構,核心業務邏輯均部署在服務器端,由此減輕了客戶端的負載,方便維護。
2.2.5 易用性
用戶無須額外安裝軟件或配置電腦環境,只需要用瀏覽器進行登陸即可使用該系統,符合現代人的使用習慣。
對文檔進行合理排序,方便用戶瀏覽;系統操作簡單,界面友好美觀,風格簡潔,界面操作易于理解,降低用戶誤操作性,并為使用帶來便利;符合正常邏輯,數據的呈現直白清晰[8]。
3系統設計
3.1 系統架構設計
本系統采用瀏覽器/服務器(Browser/Server)的結構設計,以瀏覽器為輔服務器為主的方式來支持業務邏輯設計與擴展。該結構主要包含三個層次:瀏覽器、服務器、數據庫。通過三者之前的信息交互,實現系統功能。系統各功能模塊之間的劃分與聯系如下圖1所示:
本系統的業務邏輯主要由用戶和文檔兩大板塊組成。多級用戶設定,為系統的角色權限帶來多元化,為多級權限管理提供了更大的設計空間。文檔的多維度劃分,不僅依賴于自身特性,還與其關聯的用戶有關,多類別劃分以及文件自身權限管理的多級融合,構成了整個系統的最終業務邏輯實現與應用[9]。
3.2數據庫設計
在系統框架與功能需求擬定以后,需要對數據庫結構、各數據表以及表內屬性進行合理安排與設計,數據庫的最終框架決定了系統業務邏輯能達到的上限。合理的數據庫配置與設計,應能良好支持業務邏輯的修改與擴展,并能從編程難度、數據處理速度(系統運行速度)上得到簡化與提升。
據此,本系統設置了五個關系實體:系統實體、管理員實體、用戶實體、文件實體、群組關系實體。用以滿足后臺業務邏輯需求。
3.3系統流程設計
對于文檔管理系統來說,除了系統本身提供的業務功能和系統安全性外。合理、方便、符合使用規范的系統使用流程也是一個重要的衡量。
每一個用戶在瀏覽器上輸入正確初始登錄頁面網址后,通過個人賬號登錄,方可使用該系統(系統提供的一切功能均有鑒權機制)。不同級別用戶對應不同界面,能夠對其他用戶(普通用戶除外)進行管理。不同用戶對文檔的權限管理和使用范圍也有所不同。具體流程如圖2:
3.4系統功能設計
3.4.1 注冊與登錄模塊
由于權限需求,系統管理員與部門管理員不可被隨意注冊,系統管理員由系統發布時即指定,部門管理員可由系統管理員創建。普通用戶通過注冊賬號后方可登錄使用本系統。注冊時,用戶需在現有部門選擇一個加入。此后該賬號所上傳的文件歸屬于該部門并由該部門管理員進行權限管理。(用戶可被其他部門管理員拉入其管理的部門)
通過為用戶設置session(通過cookie實現),使得不同級別用戶登錄后,進入的頁面有所區別,能使用的系統功能也有所不同。這些區分都通過鑒權手段控制。在用戶離開系統后,需注銷用戶,將系統為鑒別用戶身份而創建的信息刪除掉,保證文檔安全性。
3.4.2 文檔權限模塊
文檔的使用權限由兩部分組成,一個來自文檔與用戶的關系,一個來自文檔自身屬性。
用戶與文檔關聯性:每一個文檔在上傳時,都會根據上傳者的所在部門,在數據庫里添加一項“部門”屬性。據此,文檔的管理權限被賦予該部門管理員。只有屬于該部門或者被該部門拉入群組的用戶才能獲取文檔相關信息,并對文檔進行相應操作。
文檔自身屬性:文檔有一個“權限”屬性,屬性分為三級High、Middle、Low,分別對應不可被預覽、下載,可預覽不可下載,可預覽與下載。權限屬性可由管理員更改,通過按鈕來切換文檔權限屬性,并將權限級別展現出來。
通過文檔與用戶之間關系的業務邏輯交叉以及文檔屬性的劃分,為系統構建了多級別多粒度的權限管控。
3.4.3 文檔分類模塊
合理利用文檔的后臺邏輯,對文檔的存放進行分類劃分,維護了數據存放的有序性、規則性。方便批量管理并提供了文檔的可移植性。
文檔的實際存放大致由三級劃分:部門->類別->用戶。
部門與用戶會隨著系統的使用,由系統管理員和部門管理員對其進行增添或修改,文檔類型則維持初始幾個分類。
可在服務器上分配出一塊磁盤區來存放文檔,設置好根目錄以后,后續上傳的文檔將會以上圖所示結構存入,在服務器上可通過此層級結構訪問到對應文檔。
3.4.4 核心功能模塊
本系統最基本的功能是對文檔進行存放與管理。因此,著重解決的部分就是通過web瀏覽,借助瀏覽器對文檔管理實現上傳、下載、刪除、預覽四個基本功能。除了對文檔本身進行操作外,為了實現系統后臺的業務邏輯,需要借助數據庫存儲文檔及其存放相關的信息,涉及增、刪、改、查四個基本數據庫操作。合理的數據表設計能更好地支持后臺業務實現并能減低編程復雜度。在制定好系統全局業務邏輯后,對數據庫進行多次設計與修改,最后確定出幾個關鍵屬性,并將各表之間巧妙結合起來,最終以符合系統邏輯的方式實現了核心基礎功能。
上傳文件:設定同一部門的文檔不可以重名,不同部門間的文檔可以重名。文件上傳時會根據其部門、文檔類型、上傳者去搜尋最終URL。因此,不同部門的同名文件存放在不同路徑下,不會產生沖突,文件會以部門作為第一級區分。部門來自上傳者的從屬部門,為初始注冊時選取的部門。
下載文件:所有文件的獲取接口只提供給加入文檔所屬群組的用戶,用戶能對安全級別最低的文檔進行下載。下載時會根據文件名、所屬部門、上傳者進行URL鎖定,從而獲取文件。上傳者與部門管理員可以越過文檔權限級別下載文檔。
刪除文件:文檔安全性是文檔管理系統要考慮的最重要的因素之一,所以對于文檔的刪除,需要嚴格的權限控制與責任追究。因此,只有上傳者與部門管理員可對部門從屬文檔進行刪除操作。這樣做的目的是;對于上傳者誤傳可以及時修正、防止他人誤操作或者惡意操作導致文檔的遺失、文檔遺失能及時找到責任人并及時補救。
文件預覽:用戶可對圖片類文檔以及pdf類型文件進行預覽。協助用戶正確選擇所需文檔而不需反復多次下載查看,減少用戶對未知文件的查找時間。同下載一樣,預覽需要對用戶進行鑒權且需驗證文檔本身權限屬性。
文檔檢索:隨著部門人員的添加以及文檔數的日積月累,雖然文檔存儲結構體系簡明清晰,但仍需時間去遍歷。若是在未知部門、上傳者的情況下,文件獲取速度會降低。因此,提供了文檔檢索功能。用戶能夠在輸入框里輸入關鍵字,即可篩選相關文件,只要部分字匹配即可,用戶可靈活選擇查詢字句。
以上,實現了文檔管理系統的幾個基本功能模塊,結合系統整體的業務邏輯,一個完備的文檔管理系統就初步設計開發就完成了。
4 系統測試
經過多次系統業務邏輯調試與系統功能debug以后,系統最終測試結果如下所述。
4.1用戶功能測試
1)用戶注冊:用戶名不能為空、不能重名;兩次輸入密碼一致方可成功注冊,且不能是非法輸入(空格、非常規字符),注冊成功后會正確加入并顯示所屬部門。注冊后會自動跳轉至用戶登錄界面。
2)用戶登錄:各類用戶有明確區分,對應級別賬戶只能在對應頁面成功登錄,不會出現賬戶錯亂。登錄后,成功記錄后通過在cookie中置session存放用戶信息(用戶名、所屬部門),若是沒有登陸的情況下直接在瀏覽器中輸入目標網址,將無法正常顯示頁面,無法使用系統功能。
3)用戶管理:系統管理員可創建部門與其對應管理員,管理員不可重名,否則創建失敗。部門管理員可將所有用戶拉入或移出所管理的部門,并正確顯示當前群組成員情況。
4)文檔管理:部門管理員可對其部門的文檔進行權限管理,分為三級。每點一次權限按鈕將會提升一級權限、到頂后又會自動回到最低權限狀態。文檔權限會及時對所有用戶更新,并在文檔后顯示,方便用戶掌握文檔信息(是否可用)。
5)用戶退出:為了保證文檔安全性,用戶在使用完系統后需要進行注銷操作。點擊注銷按鈕后,會清除存留在客戶端瀏覽器cookie中的session并跳轉回初始登陸界面。注銷后若不登陸,直接輸入工作頁面地址,將無法獲取文檔信息,使用系統功能。
4.2文檔功能測試
1)上傳文檔:用戶和管理員均可上傳各種類型文檔(大小不超過300M),系統會根據文檔類型進行自動分類并在用戶的使用界面正確區分展示。同一部門之間的文檔不可重名(包含類型),但不同部門間可以。上傳過程中,若僅是關閉瀏覽器,不影響傳輸。若是網絡中斷或服務器故障等導致傳輸失敗,文檔信息不會被存入數據庫,存儲區域里也不會有相應破損文檔的殘留。
2)下載、預覽文檔:管理員擁有部門所有文檔的下載、預覽權。用戶需要參照文檔權限,安全級別為Low的文檔可以下載并預覽,Middle可以預覽不能下載,High不能下載和預覽,只有管理員可獲取。下載、預覽不同部門的同名文件時,能正確找到對應文檔,不會出現錯亂。
3)刪除文檔:管理員和上傳者可以對文檔進行移除操作,只要有系統身份鑒權即可。點擊刪除按鈕后會有彈框提示確認,防止誤操作。刪除后,文檔將從磁盤中移除,且會清空相關數據庫信息。
4)文檔展示:文檔展示根據部門、上傳時間進行排序;分頁無誤,不會造成文檔亂序導致部分被掩蓋;可輸入文件名關鍵詞(部分匹配)進行查詢,快速且無遺漏。
5 結論
本論文所開發的基于Web的文檔管理系統,是在對比現有各類文檔管理系統的優勢與不足后,綜合現有開發條件與開發難度,定位具體應用場景所做的一次優化開發,測試表明該系統具備功能更加強大,更安全穩定。同時,在文檔管理系統的開發過程中,評價系統的指標不僅僅是單個功能的實現和業務邏輯的層疊,還要考慮多用戶并發。當網絡負載較大,訪問量較高時,系統是否還能正常運作,是否會出現邏輯紊亂,是否會導致系統相應過慢,若有,如何提高運行效率等都是需要被重視的。
參考文獻:
[1] 劉林.基于Web的企業文檔管理系統的設計與實現[D].成都:電子科技大學,2012
[2] 王明月.企業知識文檔檢索管理系統的設計與實現[D].哈爾濱:哈爾濱工業大學,2017
[3] Cay S Horstmann. Scala for the Impatient[M].北京:電子工業出版社, 2012.
[4] David Pllak.BeginningScala[M].901 Grayson Street Suite 204 Berkely,CA USA:Apress,2009.
[5] Ted Neward.Scala programming livelessons(sneak peek video training)[M].USA:Addison-Wesley Professional,2011.
[6] PatrikNordwall. AkkaDocumentation[EB/OL].[2011-12-11] .http://akka.io/docs/.
[7] SébastienDoeraene. ScalaJsIntroduction[EB/OL].[2016-12-21]. http://www.scala-js.org/doc/.
[8] 黃磊.基于Web的項目管理平臺的設計與實現[D]. 成都:電子科技大學,2016
[9] 劉麗,吳秋云,李軍.基于web的分布式文檔管理系統的設計與實現[J].計算機工程與科學,2007(1).
【通聯編輯:唐一東】