熱門論文
最新論文
基于Android平臺數字化協同移動辦公信息管理系統的設計與實現
發布時間：2023-01-03 13:37
目錄
第一章 緒論 1
1.1 研究背景介紹 1
1.2移動辦公研究現狀介紹 2
1.2.1 國內研究現狀 2
1.2.2 國外研究現狀 3
1.3 論文的主要研究內容 4
第二章 相關技術介紹及其實現思路 5
2.1數字化協同辦公信息管理系統簡介 5
2.2移動平臺的對比及選擇 5
2.2.1 智能手機終端市場占有率對比 6
2.2.2 應用數量對比 6
2.2.3 第三方應用對比 7
2.3Android 平臺 8
2.3.1Android 體系結構 8
2.3.2Android 的類介紹 9
2.3.3Android 項目的目錄結構 11
2.4XML解析技術分析 13
241文件對象模型(DOM )解析技術 13
242事件驅動型(SAX)的XML解析技術 14
243 PULL解析技術 14
2.5Android 客戶端安全接入方案 16
2.5.1Android 客戶端安全接入方案簡介 16
2.5.2Android 客戶端安全接入平臺功能介紹及其實現方法 16
2.6Android Native 客戶端---前置服務器架構 17
2.6.1前置服務器 17
2.6.2Native App 架構 18
2.6.3整體架構方案 19
第三章 系統需求分析 21
3.1可行性分析 21
3.2 項目軟件生命周期的選擇 22
3.3協同辦公系統的相關功能 23
3.3.1 行政管理 24
3.3.2工作流程管理 25
3.3.3公文管理 25
3.3.4項目管理 26
3.4Android 協同移動辦公子系統功能需求分析 26
3.4.1系統用例分析 27
3.4.2系統流程圖 28
3.4.3 主要功能模塊的需求分析 29
3.5系統非功能需求分析 30
3.5.1系統運行效率 30
3.5.2數據安全性 30
3.5.3可維護性 31
3.5.4 可擴展性 31
第四章 系統總體設計 32
4.1 系統整體架構設計 32
4.2 前置服務器的實現 33
4.2.1 傳輸加密層功能說明 35
4.2.2協議適配層功能說明 35
4.2.3終端適配層功能說明 35
4.2.4 業務邏輯層功能說明 36
4.2.5 內容聚合層功能說明 36
4.2.6 系統服務層功能說明 36
4.3移動客戶端的分析設計 36
4.4安全接入平臺模塊設計 38
4.5XML數據解析模塊設計 39
4.6數字簽名模塊設計 39
4.7附件下載和查看模塊設計 39
4.8客戶端更新模塊設計 40
4.9數據交互接口設計 40
第五章 系統詳細設計與實現 42
5.1 系統架構實現 42
5.2移動客戶端主要功能模塊的具體實現 47
5.2.1系統開發環境 48
5.2.2Android 運行環境 48
5.2.3用戶登陸模塊實現 49
5.2.4待辦事項模塊實現 51
5.2.5公文管理模塊實現 52
5.2.6附件下載模塊實現 56
5.2.7自動更新模塊的具體實現 61
5.2.8Android 客戶端擴展功能 63
5.3移動客戶端與協同辦公系統數據交互實現 64
5.3.1XML 解析器的創建 65
5.3.2SAX方式的具體實現 65
5.3.3XML數據交互實現 66
5.4數據交互接口實現 67
5.5 本章小結 70
第六章 系統測試 71
6.1功能測試 71
6.2測試結果 74
6.3本章小結 74
第七章 總結與展望 75
致謝 76
參考文獻 77
第一章 緒論
本章首先闡述了本文的研究背景、深入調研了數字化協同移動辦公信息管理 系統的現狀,接著介紹了本課題目的及意義，最后提出本文的主要研究內容并給 出論文的組織結構。
1.1 研究背景介紹
隨著信息化的不斷發展，人們日常的工作和生活與計算機和網絡聯系的更為 緊密了。隨著網絡應用的不斷發展，許多企事業單位的信息化建設已經比較成熟， 他們在日常的辦公中對計算機和網絡的依賴逐漸加深。由于很多規模較大的企事 業單位在各地設立了分部，業務也遍布全國各地，因此這些企事業單位的員工頻 繁外出、出差，這就衍生出很多問題。傳統有線網絡下的辦公系統無法滿足這類 企事業單位的需求，這就導致這些企事業單位的管理上會出現一定的問題，降低 了這些企事業單位員工的工作效率。因此，企事業單位需要一種更加便捷的辦公 方式。為此，采用了數字化協同移動辦公系統，這可以讓企事業單位降低了運營 成本，并且能夠提高其管理決策的科學性和實效性。可以讓員工通過使用智能手 機客戶端登陸數字化協同移動辦公系統，實現了隨時隨地的工作，極大的提升了 工作效率。
現階段基于移動手機的數字化協同移動辦公在我國擁有廣泛的應用前景，首 先讓我們看看由中國互聯網信息中心（CNNIC）發布的一些權威的統計數據。⑴
（1） 截至2013年12月底，我國手機網民規模為5億，較上年增加約6440 萬人，年增長率為19 .1%，在整體網民中的占比由2012年底的74. 5%提升至81%， 遠高于其他設備上網的網民比例，第一上網終端的地位更加穩固。
（2） 手機網民的手機上網粘度較大，平均每天累計使用手機上網時長為 124 分鐘，每天上網 4 小時以上的重度手機網民比例高達 22.0%，手機上網逐漸成為 一種常態化的生活習慣。
（3） 相比 2012年，我國手機網民年齡呈現成熟化趨勢，30 歲以上手機網 民的比例明顯上升，整體從 2010 年底的 33.3%上升至 2012 年底的 39.2%。這主 要是由于智能手機的普及及3G網絡的成熟使得手機上網的門檻降低。
以上數據說明：我國擁有全球最多的手機用戶，國民的手機人均擁有量已經 遠遠超過計算機的人均擁有量。近年來隨著第三代移動通信技術的發展以及城市 中無線熱點的部署，移動無線帶寬也得到很大的改善，且移動終端性價比在逐步 提高，這些都為數字化協同移動辦公的進一步發展創造了良好的條件。
1.2移動辦公研究現狀介紹
在全球信息化及移動寬帶網絡高速發展的今天，企事業單位對數字化協同移 動辦公信息管理系統有著極大的需求，顯而易見，移動辦公系統有著極為光明的 前景。移動辦公系統的出現，使得通常的0A系統擺脫了對固定辦公環境，固定 工作時間，固定電腦設備和網絡的依賴，將信息化無縫延展到每個人手中，使得 信息化從此可以隨時隨地的跟隨著人走。它是對原有信息化的補充，也是對信息 化本身的發展和躍變。數字化協同移動辦公信息管理系統與傳統的基于桌面的辦 公系統最主要的區別是真正實現了在任何時間，任何地點都能辦公的目標。這體 現了辦公的時效性，使得人們的辦公不再局限與特定的時間與特定的地點，這就 讓人們的工作效率得到極大的提升。因此，隨著國內信息化的發展，對內部辦公 自動化的及時處理也已經成為影響單位辦公效率的重要環節。將辦公自動化系統 向移動終端延伸的實際需求也越來越迫切。
1.2.1 國內研究現狀
我國高度重視發展軟件和信息服務業，自 2000 年以來，國家出臺一系列支 持軟件和信息服務發展的政策措施，助推軟件業持續走強。
近年來協同 0A 軟件市場快速增長，市場規模從 2008 年的 29.5 億元大幅增 長至45.1億元，增長率為40.1%。2010-2013年，協同OA軟件市場年復合增長 率仍將保持為30%左右， 2013年市場總額將達到132.2億元。 [2]可以預見，未來 兩三年協同OA仍將高速成長，這10年來中國OA業持續增長，一方面得益于 中國日益堅實的軟件和信息服務產業基礎，日益成熟的科研和教育系統，豐富的 人力資源優勢和不斷深入的國際合作，另一方面也得益于國家對軟件業的各項政 策支持，營造了良好的投資環境。 2011 年，國務院發布了《進一步鼓勵軟件產 業和集成電路產業發展的若干政策》（號稱“新 18號文”），從財稅、投融資、進 出口等七個方面進一步優化產業發展環境。[3]2011年以來，協同OA行業市場漸 趨成熟，宣布進入行業發展的黃金10年。
而在政策利好的不斷支持、需求市場的日益成熟、國內OA軟件廠商技術水 平和應用能力提升的幫助之下，相比于國外廠商，國內廠商在今后的OA辦公自 動化市場將更具優勢。據一項權威統計數據顯示，目前國產OA已占整個辦公自 動化市場 70%以上的份額，未來 5 年將有可能提高到80%以上，一統辦公自動 化市場江山。 [4]
隨著移動技術的高速發展，我國各地逐步都加大了數字化移動協同辦公平臺 的關注力度，目前國內數字化移動協同辦公平臺的使用主要集中在通信基礎設施 比較完善的發達地區，欠發達地區起步較晚，但發展也頗為迅速。我國的信息化
Android手機的出貨量都遠遠高于其他智能手機平臺，因此，基于Android平臺 的這些優勢，本論文就選擇了安卓智能終端設備作為數字化協同移動辦公系統所 使用的終端設備平臺。
2.3Android 平臺
Android手機操作系統是由谷歌公司于2007年正式推出的，最大的特點是平 臺的真正開放性。到目前為止， Android 手機操作系統的最新版本為 4.0，具有廣 泛的應用和發展前景。Android系統的使用率占據全球智能手機系統將近80%的 份額，尤其在中國市場的占有率更高，接近90%[8]。與其他手機操作系統相比， Android 具有最大的優點就在于它的開放性和平臺開發的便捷性，不同的廠商可 以根據自己的需求對平臺進行擴展開發，而且無需支付任何費用。采用 Android 操作系統的智能手機越來越受到人們的青睞。Android是以Linux系統為基礎， 能更好地滿足電腦愛好者的需求。另外Android的安全性也比較完善。
2.3.1Android 體系結構
Android 手機操作系統平臺整合了操作系統、中間件和應用程序三大塊。
Android操作系統之所以會受到各廠家的青睞,真是因為它的真正開放的優越性。
Android的架構從下圖來看，軟件層次結構自上而下共分為以下4個層，如圖2-2
所示：
(1)應用程序(Application)
應用程序(Application)主要是用來設計用戶操作界面的，用Java語言來編 寫，主要是被用戶訪問。Android自身提供了一些核心的應用程序，如主屏幕、 聯系人、電話、瀏覽器等，因為Android是開放式的操作系統，所以用戶可以根 據自己的要求，利用已有的框架來編譯、開發程序。 Android 應用程序中 UI 組 件所需的控件首先由本層提供。如View(UI組件)，包括了列表、文本框、按鈕 等，這些組件構成了程序的視圖部分。
(2)應用程序框架(Application Framework)
開發者接觸最多的就是應用程序框架，它給開發者提供了應用程序層的 API，開發者在開發時都是基于框架的。其上層的應用程序基本都是以Java語言 來編譯的，應用程序框架提供所有用戶界面設計所需的控件。終端界面能夠顯示 出來讓用戶看到的的所有圖形都是些文本框、按鈕和列表等控件，它們組成了應 用程序的界面系統。開發者在開發時可以完全通過應用程序框架的視圖系統、電 話管理器等各個部分來進行軟件的開發。
(3)庫和 Android 運行環境
通過Android平臺來開發程序的過程，是由各類組件來調用Android的后臺 庫來實現系統開發的，而這些庫都是一些用C或C++來編譯的庫函數。安卓系 統包含了一套功能強大的運行庫，它主要為實現Java語言的運行而服務。每個 Android應用程序的進程都是基于寄存器的Dalvik虛擬實例，所需要的資源也相 對比較少。Android系統是基于Linux的，所以Linux作為底層為Dalvik虛擬機 提供了一些內核的功能，如線程機制、內存管理機制。 Dalvik 虛擬機的可執行 文件格式是.dex類型的，這種文件格式是被優化過的,所以占用的內存最小［9］。
(4)操作系統層(OS)
Android SDK是運行于Linux上的，它只是以Linux內核來管理硬件資源的， 不同于 Linux。 Linux 內核同時作為軟、硬件棧間的抽象層，進行相互溝通的工 作。
2.3.2Android 的類介紹
Android 手機區別于其它一些智能手機就在于它有自己的組件。本段內容就 會對 Android 的部分組件作詳細的介紹。
(1) Activity 簡介
Activity 是應用程序的表示層。它在 Android 應用中主要是用來創建和顯示 窗口的。系統的用戶界面就是一個Activity對象，作一個很形象的比喻，在手機 游覽器中一個網頁就是一個Activityo 一般，一個Android應用會包含很多個 Activity，它們之間是可以自由地進行相互跳轉的，就像網頁的跳轉一樣。但 Activity和網頁跳轉的區別就是可能存在返回值。
Activity棧可以用來管理系統中的Activity。當啟動一個新的activity時，它 會被放置在activity棧頂部，并成為running狀態的activity，之前的activity也在 activity棧中，但總是被保存在它的下邊，只有當這個新的activity退出以后之前 的 activity 才能重新回到前景界面。
Android 中每個 activity 都是一個用戶界面，要想實現各界面之間的轉換就需 用到 Android 的 Intent 類。 Intent 類運行時包含兩個部分，動作和動作對應的數 據。
Activity 有兩個方面，既可以調用其他請求，也可以被其它請求調用。在設 計開發系統時，Activity主要負責窗口的創建工作，其次利用set Content View方 法將窗口顯示出來，實現與用戶的交互。
(2)Service 簡介
Service級別和Activity差不多，都是Android的四大組件之一，一般使用 Service實現后臺的一些長期運行的應用程序的服務工作。雖然是用戶看不見的， 但在系統運行中的作用卻是非常重要的。 Service 能夠在后臺運行并和其它組件 進行交互。 Service 的啟動有兩種方式，這兩種方式可以混合使用：第一種是調 用 context.bindService()啟動，調用和 context.unbindService()結束，第二種是通過 調用 context.startService()啟動，調用 context.stopService()結束，
(3)BroadcastReceiver 簡介
BroadcastReceiver 是用戶接受廣播通知的組件。廣播是一種同時通知多個對 象的時間通知機制。 Android 中的廣播通知要么來自系統，要么來自普通應用程 序。
為了響應不同的事件通知，應用程序可以注冊不同的BroadcastReceiver。而 所有的BroadcastReceive都繼承自基類BroadcastReceive。而用戶圖形界面并不 能通過 BroadcastReceive 來 進 行 實 現 ， 但 是 當 它 收 到 通 知 消 息 后 ， BroadcastReceive 可以啟動 Activity 作為響應，或者通過 NotificationManager 來 提醒用戶。
(4)ContentProvider 簡介
在Android中，所有的數據都是私有的，要想實現在各個應用程序中自由地 使用各類數據，Android中的ContentProvider則可以實現，它通過統一的標準的 接口進行每個應用中各類數據的共享。外界可根據權限級別利用一套標準統一的 接口和程序對數據進行共享。
(5)Intent 簡介
Intent 是連接組件的紐帶，在上述 4 種基本組件中，除了 ContentProvider 是通過 ContentResolver 激活外， 其他三種組件 Activity 、 Service 和
BroadcastReceiver 都是由一種名為 Intent 的異步消息激活。 Intent 在不同的組件 之間傳遞消息，將一個組件的請求意圖傳給另一個組件。因此，Intent是個包含 具體請求信息的對象。
一般來說一個完整的 Android 應用程序應該包含 Activity 、 Intent Receiver、 Service、 Content Provider 和每個 Android 應用所相應的配置文件 XML。 Android
圖 2-2 Android 應用程序工作流程
2.3.3 Android 項目的目錄結構
Android項目的目錄結構如圖2-3所示，為了使開發的Android應用項目效 果更好，在開發 Android 項目的過程中必須要做到靈活運用。
圖 2-3 Android 項目的目錄結構
Android項目的目錄的主要功能如下：
(1)default.properties 文件
default.properties文件的作用是記錄項目中對應的環境配置，一般就采用默 認配置，無需自行修改。
(2)AndroidManifest.xml 文件
AndroidManifest.xml文件是Android項目的總配置文件，Android項目中所使 用到的各種組件都被記錄在這個配置文件中。Android應用使用到的服務,如互聯 網服務、GPS定位服務、通信服務等都是記錄在AndroidManifest.xml這個文件中。 當添加一個全新的Activity時，也必須配置AndroidManifest.xm 1這個文件，只有將 這個 XML 文件配置好后，才能調用此 Activity a application permissions、Activities、 intent filters 等都包含在 AndroidManifest.xml 文件中。
⑶res文件夾
res文件夾是存放資源的目錄，它包含了Android軟件項目中的資源文件并將 這些文件編譯進Android客戶端。向此目錄添加資源時，會被R.java自動記錄。res 目錄下存在layout、values、、drawabe這三個子目錄，layout目錄中存放的是界面 布局文件，values目錄中存放的是顯示各種文字的XML文件，drawabe目錄中則 存放各種圖標文件。
(4)assets文件夾
assets文件夾則放置了 Android客戶端應用所需的各類多媒體文件。
(5)Android 2.x.x 文件夾
Android 2.x.x目錄下有個一個Java歸檔文件，文件名是android.jar，其中包 含了開發Android應用所需要的APIS(應用程序接口 )和 SDK(軟件開發工具包)庫。 它通過android.jar將自己的應用程序綁定到Android Emulator和Android SDK，這 允許你使用所有Android的庫和包，并且允許你在適當的環境中調試應用程序。
(6)gen文件夾
gen文件夾下面有一個在建立Android應用時生成的只讀歸檔java文件，文件 名是Rjava。在這個只讀歸檔文件中有一個R類被定義，這個R類定義了該軟件項 目中所有資源的索引，很多靜態類被包含在R類中，且res中的每一個名字都與靜 態類的名字相對應。我們通過Rjava可以方便快捷的找到我們所需要的資源， Rjava列表中的資源也被編繹器進行檢查是否被使用過。為了盡可能的減少 Android客戶端應用的體積，提高Android客戶端應用的執行效率，我們利用R.java 篩選出那些沒有使用到的資源，使其不被編譯進軟件中，這樣可以減少應用在手 機占用的空間。
(7)src文件夾
該文件夾內放置的是Android客戶端軟件的源代碼。
2.4XML解析技術分析
XML解析是指：為滿足XML語法的結構化組件的把代表XML文檔的一個 無結構的字符序列轉換過程［10］。因為安卓智能手機的系統資源有限，開發者為 了更有效的使用其有限的系統資源，必須選擇相應的XML解析技術，方可達到 安卓應用優化的目的。本節將簡單分析對比Android平臺中三種常用的XML解 析方法。
2.4.1文件對象模型(DOM )解析技術
Android能夠完全支持文件對象模型(DOM)解析。我們利用DOM中的對象， 可以讀取、搜索、修改、添加和刪除XML文檔。
我們在使用DOM對操作XML文件時，第一就要解析文件，將文件分為獨 立的注釋、屬性、元素等，第二我們要通過節點樹訪問文檔的內容，就必須以節 點樹的形式在內存中對XML文件進行表示，并根據需要修改文檔，這就是DOM 的工作原理［11］。第三DOM實現時首先為XML文檔的解析定義一組接口，解析 器讀入整個文檔，然后構造一個駐留內存的樹結構，這樣代碼就可以使用DOM 接口來操作整個樹結構。
文件對象模型(DOM)解析XML的流程如下圖2-4所示：
圖 2-4 文件對象模型 (DOM) 解析 XML 流程圖
2.4.2事件驅動型(SAX)的XML解析技術
SAX(Simple API for XML)XML 簡單應用程序接口是一個公共的基于事 件的XML文檔解析標準。它以事件作為解析XML文件的模式，它將XML文 件轉化成一系列的事件，由不同的事件處理器來決定如何處理。 SAX 是一個解 析速度快并且占用內存少的xml解析器，非常適合android等移動設備，SAX 解析XML文件采用的是事件驅動，也就是說，它并不需要解析完整個文檔，在 按內容順序解析文檔的過程中，SAX會判斷當前讀取到的字符是否合法xml語 法中的某部分，如果符合就會觸發事件。
SAX解析XML的流程如下圖2-5所示：
圖 2-5 SAX 解析 XML 流程圖
2.4.3 PULL解析技術
在 Android API 中，另外提供了 Android.util.Xml 類，同樣可以解析 XML 文 件，使用方法類似SAX,也都需編寫Handler來處理XML的解析，但是在使用 上卻比 SAX 來得簡單。它允許用戶的應用程序代碼從解析器中獲取事件，這與 SAX解析器自動將事件推入處理程序相反。Pull解析器運行方式與SAX解析器 類似，它提供了類似ide事件，如：開始元素和結束元素，使用parser.next()可 以進入下一個元素并觸發相應的事件。事件作為數值代碼被發送，因此可以使用 一個switch對感興趣的事件進行處理。當元素 開始解析時，調用parser.nextText() 方法獲取一個Text類型的節點的值。
PULL解析XML的流程如下圖2-6所示：
對三種解析技術的比較：
對于Android的移動設備而言，因為Android手機一般都使用ARM低功耗 處理器，配置的系統內存也不會太高，所以這就決定了 Android移動設備的硬件 性能有一定的限制，所以我們需要選擇適合的技術來解析XML,這樣有利于降 低 Android 移動設備的系統資源利用率。
(1)DOM 在處理 XML 文件時，它是在內存中處理已解析程樹狀結構的 XML 文件。當 XML 文件較小時，我們可以選擇相對簡單直觀些的 DOM。
(2)SAX則是以事件作為解析XML文件的模式，它將XML文件轉化成一 系列的事件，由不同的事件處理器來決定如何處理。XML文件較大時，選擇SAX 技術是比較合理的。雖然代碼量有些大，但是它不需要將所有的 XML 文件加載 到內存中。這樣對于有限的 Android 內存更有效，而且 Android 提供了一種傳 統的 SAX 使用方法以及一個便捷的 SAX 包裝器。
(3)PULL解析在開始處完成了大部分的處理工作，它沒有像SAX解析那樣 監聽元素的結束。這種處理方法機極大的降低了解析的時間，對XML文件的載 入速度有了很大的提升。對于移動設備在網絡速度不佳的環境中，這種優化顯得 尤為重要。綜上所述，在XML文檔較大，但軟件無需第一時間全部載入XML文 檔時，PULL解析器的執行效率更高。
2.5 Android 客戶端安全接入方案
由于 Android 客戶端需要通過公共移動網絡接入各企事業單位內部辦公網 絡，這必然會帶來有些安全性的問題，因此，如何保障遠程用戶能夠合法、安全 地接入數字化協同移動辦公信息管理系統是本方案需要考慮的問題。
2.5.1Android 客戶端安全接入方案簡介
在網絡接入層次上，使用硬件VPN解決方案，防止用戶直接從互聯網接入 而導致網絡安全問題，這就解決了數據在互聯網傳輸中的安全問題。
在客戶端應用層次上，我們設計了一個基于 Android 的安全接入平臺的應 用，這個應用先于Android協同移動辦公的模塊啟動，以此來給Android協同移 動辦公客戶端創建一個較為安全地運行環境。該應用的運行流程如下：在啟動此 安全接入軟件通過身份認證之后，開始檢測Android系統的后臺進程，并將相應 的不可信任的進程強行殺掉，最后再加載Android協同移動客戶端的業務功能模 塊。這就在一定程度上解決了 Android手機客戶端系統本身存在的安全問題。
2.5.2Android客戶端安全接入平臺功能介紹及其實現方法
Android客戶端安全接入平臺設計了一個專屬存儲空間，它從Android系統 中單獨劃出一塊存儲空間，用于存儲其專用數據，這樣可以在很大程度上與其他 軟件的隔離開來，使得其他軟件無法訪問該專屬存儲空間。該安全平臺還能阻止 第三方應用對該平臺內部的應用及其數據的訪問和調用，同時也禁止平臺內的應 用對第三方應用及其數據的訪問和調用。
Android 客戶端的登陸界面就是安全接入平臺的專用登陸入口，客戶端用戶 使用相應的登錄名和沒密碼通過安全接入平臺的驗證。客戶端的安全接入平臺將 可信任的軟件納入白名單，利用該白名單來檢測Andriod系統后臺運行的軟件是 否可信。
Android 客 戶 端 安 全 接 入 平 臺 最 重 要 的 一 個 功 能 是 將 平 臺 內 的 應 用 和 Android系統的第三方應用之間的通訊進行隔離。安全接入平臺內的應用可以共 享存儲空間，可以在平臺內實現數據的調用或者通訊。而安全平臺之內的應用以 及安全平臺之外的第三方應用則利用“沙盒”原理來實現通訊數據之間的隔離。
Android 客戶端的安全接入平臺為實現安全接入平臺和第三方應用之間的通 訊隔離,采用以下兩種種方式來實現：
(1)在開發協同移動辦公Android客戶端時，需要對其源代碼進行缺陷分析和 漏洞分析，確保客戶端軟件沒有安全漏洞。
(2)在安裝Android應用時，為控制應用的訪問權限，本文設計了一個應用安 裝管理器，應用安裝管理器對應用所需的權限進行審核，一旦發現有非正常權限， 如企圖與安全接入平臺進行通信，則立即停止安裝該應用。
(3)在運行應用時，為防止有違反安全隔離規則的現象，本文設計了一個權 限管理器，用來在系統后臺實時監測安全接入平臺內外的違規交互通信行為。
2.6 Android Native客戶端…前置服務器架構
2.6.1前置服務器
協同移動辦公系統將一個精簡版的協同移動辦公系統服務器作為前置服務 器,這臺前置服務器提供外界 Android 移動手機終端接入協同移動辦公系統平臺 的功能。系統移動辦公系統的前置服務器系統并不具備完備的協同移動辦公系統 的功能,而僅僅是設計出和現有的協同辦公系統對接的接口模塊來實現業務流程 的操作。前置服務器的使用專用密碼機來保障密碼的高安全性。前置服務器跟后 端的協同辦公系統服務器之間采用 HTTP/HTTPS 來進行通訊，而前置服務器和 Android移動客戶端之間則采用HTTPS/XML來進行通訊。設計前置服務器的目 的如下：
(1)Android 客戶端軟件通過前置服務器和數字化協同辦公系統之間進行數 據的傳輸，這樣在協同辦公信息管理系統進行更新或修改時，可以保持 Android 客戶端軟件的相對穩定。只需要在前置服務器系統上做相應的修改和更新,而 Android 客戶端幾乎不需要做太大的修改，甚至無須做任何更新;
(2)前置服務器專門為 Android 客戶端和原始的數字化協同辦公系統之間提 供數據中轉服務。通過這種訪問模式，Android客戶端因請求所響應的數據相比 直接訪問數字化協同辦公系統服務器的數據量，大為降低,這就使得服務器能夠 承載更大的客戶訪問量，使得服務器的網絡延遲也大為降低,最為顯著的就是增 強了用戶在 Android 客戶端上的體驗性;
(3)Android客戶端通過前置服務器來訪問位于內網的數字化協同辦公系統， 可以在很大程度上保證數字化協同辦公系統的安全，并且可以提供更為安全地連 接方式;
(4)前置服務器對Android客戶端應用提供升級服務支持。前置服務器除了通 過HTTPS協議來保證數據通訊安全，還提供利用服務器系統自帶的防火墻功能來 防護來自網絡的攻擊行為。
2.6.2Native App 架構
Android客戶端分為兩種，一種是本地應用(Native App)，另一種是網頁應用 (Web App)。如今，在手機移動應用領域，對于未來是Native App的天下，還是 Web App的天下，客戶端軟件設計者和開發者是應該努力以提升客戶端的體驗， 還是優化設計Web應用，這是安卓移動互聯網領域備受關心的問題。
(1)Web App
因為Web App不需要安裝，所以其對移動終端設備的適應能力優于Native App，它可以在任意移動終端的瀏覽器中執行(通過XHTML、HTML5和CSS)。 隨著安卓移動手機終端內置WebKit瀏覽器的性能升級，這讓在基于WebKit瀏 覽器的移動終端設備上開發的Web App上的用戶體驗，得以媲美Native App的 流暢性。
Web App 有以下優點：它能夠能夠比較容易的匹配各種移動終端設備，能 夠較為以較低的開發成本來實現跨平臺的開發和較低的終端部署成本，迭代更新 比較容易，因在終端無安裝程序，所以部署成本幾乎為零。但Web App的也存 在一定的缺陷，比如以下幾個方面：無法充分發揮系統特性(調用系統服務、內 存管理等) ;無法操控設備硬件(如相機、藍牙、振動器等)；對于復雜應用， web app受限于瀏覽器，性能不佳；在用戶體驗方面尚無法超越Native App，且 在調用本地文件的能力方面無法與Native App相媲美。
(2)Native App
Native App的開發成本要高于Web App，但其對于本地資源的調用的兼容性 要好于 Web App， Naitve App 可以支持本地資源的訪問，推送信息，攝像頭功能 的調用以及撥號或者 GPS 定位功能的調用。但是由于移動終端設備碎片化，導 致本地應用的開發成本較高，還需要花費大量的工作用以維持多個版本的更新升 級，并且對用戶的操作水平也有較高的要求。
Native App 有以下優點：本地應用在用戶體驗上做的更好，可以針對不同的 手機終端做最優化的匹配，可以提升用戶的體驗。Native App能夠在一定程度上 降低數據通訊量，從而降低帶寬的成本。Native App能夠可以實現調用本地的軟 硬件資源。但 Native App 也存在一定的缺點：在不同的平臺上進行移植，較為 麻煩，工作量較大，維持多個應用版本的成本較高。
通過以上對網頁應用(Web App)和本地應用(Native App)的說明介紹以及這 兩者之間各自的優點和缺點,并從本項目的實際需求出發,本文最終選擇了本地應 用(Native App)為該項目客戶端的實際解決方案。本項目的客戶端采用Native app 的方案基于如下幾點理由，首先本地應用(Native App)可以提供最佳的用戶體驗, 最優質的用戶UI,良好的交互性，而這些方面是Web應用(Web App)無法給予的。 本地應用(Native App)可以提供給用戶最華麗用戶界面，而擁有一個優良的用戶界 面不僅僅可以吸引客戶來使用本地應用(Native App)，還可以提高客戶的對應用 的使用率；第二,使用本地應用(Native App)能夠實現可信安全卡的功能集成，更好 的保障本項目的移動客戶端的接入安全，而這點在網頁應用(Web App)上的實現 難度則遠大于本地應用(Native App)。考慮到以上幾點原因以及移動網絡的穩定 性及其有限的帶寬，為保證用戶對協同移動辦公客戶端的良好體驗，故選擇數據 通訊量較少，且對帶寬要求較低的本地應用(Native App)。
2.6.3 整體架構方案
如圖2-7所示，本項目采用了在Android移動客戶端和數字化協同辦公系統之 間架設前置服務器的特殊架構方案。該方案使用 Android 軟件開發工具包 (Android SDK)來開發Android移動客戶端應用。通過選擇幾個常用的組件，開發 出有著較好用戶體驗的本地應用界面,開發出適合安卓手機移動終端的數字化協 同辦公信息管理系統。Android移動終端和現有的協同辦公信息管理系統利用前 置服務器進行通訊連接,前置服務器將移動終端的客戶請求數據通過轉發發給協 同移動辦公信息管理系統，協同移動辦公信息管理系統再把相應客戶端的請求回 應給前置服務器，再由前置服務器反饋給Android移動終端。前置服務器和原有 的協同移動辦公信息管理系統使用(HTTPS/XML)協議來進行通信，以保證數據 的安全性；兩者通過相應的接口模塊來實現彼此之間的數據調用。最終將用戶的 請求結果輸出為適合 Android 移動客戶端的顯示格式。
圖 2-7 系統架構示意圖
該方案的優勢如下所述：
(1)各種Android組件的使用，可以為終端用戶的體驗提供更好的Android優 良的系統特性。
(2)該方案專為移動終端用戶定制,為提供簡潔且易于操作的用戶界面,過濾 了很多不需要的信息，從而降低了客戶端與服務器端之間的數據傳輸量，減少網 絡流量,為終端用戶提供良好的操作體驗。
(3)該方案的 Android 客戶端并不直接和數字化協同辦公信息管理系統服務 器相連，因此協同辦公系統的前臺Web界面的更新不會影響到Android客戶端用 戶的正常使用。
(4)該方案很容易擴展到其他類型的移動終端。
(5)該方案可以通過 Java 的 JCA(Java Connector Architecture)和 JCE(Java Cryptography Extension )構建任何安全系統的客戶端。
(6)該方案通過前置服務器的相關加密設置,可以更好的保障內外網信息通 訊的數據安全。
該方案劣勢如下所述：
Native App 應用客戶端的開發工作量較大，不同移動終端版本的適配較復 雜。
第三章 系統需求分析
本章主要基于Android平臺數字化協同移動辦公信息管理系統進行本系統的 需求分析。本項目的后續工作主要以基于Android平臺數字化協同移動辦公信息 管理系統的需求分析為指導和參照,不考慮未在系統需求分析中體現的內容。本 需求分析主要是針對Android平臺數字化協同移動辦公信息管理系統的功能需求 和非功能需求。本需求分析作為運行系統設計、實現、測試人員的指導文檔,對 基于 Android 平臺數字化協同移動辦公信息管理系統的實施人員來說,需要以此 為參照,重復或沖突部分以本需求分析為準。本需求分析作為運行系統設計、實 現、測試人員的指導文檔。
3.1 可行性分析
當今的移動互聯網技術正處于迅猛的發展期，目前的移動終端平臺市場主要 以 IOS 和 Android 為主，在當前的移動終端市場的占有率方面， Android 已超出 IOS。基于IOS的應用執行效率較高且界面簡潔，但因IOS系統代碼并不開源，使 得IOS應用的開發入門門檻較高，因此IOS系統的這些局限性使初級開發者的 開發積極性不及開源的 Android 系統。而 Google 的 Android 操作系統一經推出, 就以其開源性備受手機制造商及世界各地研發者的青睞。根據Vision Mobile提 供的數據， 34.4%的研發者現在會選擇 Android 作為他們首要的研發平臺，而選 擇iOS作為其首要研發平臺的比例為32.7%。平均而言，移動研發者通常會專注 2.9 個不同的應用平臺，但在選擇首要平臺時，更多的研發者現在倒向 Android。
Android智能設備幾乎得到了目前所有手機制造商的支持，因此它在設備出 貨量上占據了主導地位，目前主流Android移動終端的硬件配置都比較高，具備 了高分辨率，尺寸較大且觸摸靈敏的電容屏，并且有著極高的CPU和GPU配置， 這使得Android的運算能力、圖形顯示能力得到了極大的提升。而在無線通信技 術方面，目前發展已極為迅速，2G的GPRS網絡已經成熟，3G已經完成了全面 覆蓋，而4G也已開始逐步推廣，而在城市中,WIFI無線熱點已經覆蓋了絕大部 分區域，這基本上完成了無線信號的全面覆蓋，使得移動終端設備隨時隨地均可 聯網。移動互聯網的迅速發展是建立在移動終端設備以及無線網絡的高速發展之 上。
目前在各企事業單位使用的傳統的基于桌面瀏覽器的數字化協同辦公信息 管理系統已經比較成熟,但它在目前的辦公應用方面存在一定的局限性,使用者必 須在固定的地點才可以連入網絡使用數字化協同辦公信息系統,不能夠隨時隨地 的使用辦公信息系統。因此,傳統協同辦公系統不能滿足企事業單位對于信息化 系統的移動訪問的需求，尤其在發生緊急突發性事件時，企事業單位對于通過移 動網絡訪問數字化協同辦公信息管理系統的需求尤其突出。
基于 Android 平臺的數字化協同移動辦公系統的設想即由此產生,由于無線 網絡的快速發展，移動網絡的帶寬問題已基本解決，本文主要需要解決是用戶通 過移動終端接入的數據安全問題，此外還需要考慮移動終端通過無線網絡傳輸時 產生的交互數據通信量過大的問題。如果不解決這兩大問題，無線移動協同辦公 系統在數據安全方面存在的問題會影響到企事業單位的數據安全，而無線通信網 絡交換數據效率上的低效則會影響到用戶的良好體驗并且會增大服務器的負載。
在安全方面我們需要采取如下兩大措施：在數據應用層的安全方面,我們采 用國際上較為成熟的智能卡技術,將用戶的數字證書下載到存儲卡中，通過SSL協 議連接服務器調用 API 接口,利用用戶的數字證書完成電子簽章、對稱加密解密 技術等數據信息安全方面的技術來保障移動終端連接服務器的安全性。而在網絡 層面的安全方面，我們需要購置VPN設備、硬件防火墻以及入侵防御檢測系統 來搭建網絡層次的安全保障體系，將企事業單位內部的核心業務服務器與存在 安全風險的互聯網隔離開來。
為解決移動終端與服務器的通信交換數據效率上低效問題,本文在辦公平臺 前端架設一臺前置服務器，該服務器主要是起到內網協同辦公系統服務器和移動 終端設備之間的數據轉換及安全隔離的作用。前置服務器可以將移動終端和內網 協同辦公服務器端之間的交互通信數據進行壓縮簡化,在數據通過該前置服務器 時，處理掉部分不必要的數據,并進行壓縮，得以最大化降低Android移動終端和 內網協同辦公服務器之前的通信數據量。通過在原協同辦公服務器前端部署前置 服務器,不僅降低了開發成本，也在一定程度上提升了開發效率，減少了相應的 開發周期。并且，在移動終端和原始協同辦公系統服務器之間使用前置機隔離開 來，使得原辦公系統服務器不直接暴露在外網上，進一步提升了該移動協同辦公 系統的整體安全性。
由上論證，可通過以上兩大主要問題的解決方案,再結合企事業單位原有辦 公系統，以及安卓平臺的簡單易用的特點,可以根據企事業單位的具體需求來設 計開發出安全高效的基于Android平臺數字化協同移動辦公信息管理系統。
3.2 項目軟件生命周期的選擇
在移動終端上開發應用軟件可以歸納如下幾個特點：應用的開發周期相對桌 面軟件而言較短;但在軟件的創新性方面有著更高的要求;針對客戶的需求分析需 要做的更為細致，移動平臺軟件的開發較桌面平臺軟件更新更快。這就要求移動 應用的開發必須適應企事業單位的需求,從而要求移動應用的開發必須迅速快捷, 必須將新的移動應用在較短的時間內開發出來。在如今快速發展的移動應用市 場，只有高效的開發才能滿足市場的需求，所以敏捷開發成為了首選的軟件生命 周期，而敏捷開發的最佳軟件開發模型則是Scrum。
由上圖充分了解實施Scrum的過程，Scrum模型的一個顯著特點就是響應變 化，它能夠盡快地響應變化。因此Scrum的優勢就在于:敏捷開發;Scrum模型將 軟件開發團隊比擬成橄欖球隊，有明確的最高目標，熟悉開發流程中所需具備的 最佳典范與技術，具有高度自主權，緊密地溝通合作，以高度彈性解決各種挑戰， 確保每天、每個階段都朝向目標有明確的推進。 [12]
Scrum 開發模式的優勢結合移動互聯網應用的特點,不僅能夠滿足移動互聯 網用戶多變的需求,又能很好的控制整個移動應用的項目進行。雖然移動應用的 開發模式種類不僅僅只有Scrum這一種，但在研發人員的眼中，Scrum開發模式 是最適合移動互聯網應用項目,因為Scrum開發模式使得開發移動應用開發效率 相比較其他開發模式而言，顯然在管理性及開發效率上面表現更好。
綜上所述，本項目的開發模式選擇了更適合移動互聯網應用的Scrum開發模 式，這種模式可以提升本項目的開發效率，減少開發周期。
3.3 協同辦公系統的相關功能
目前使用的協同辦公平臺幾乎覆蓋企業的各個部門，囊括行政管理、人力資 源、業務流程、知識庫、項目管理等功能：并且，系統集成專業的報表工作，可 提供全方面、準確的業務數據；開放相應的功能接口，企業可根據自身需求自定
義配置平臺的功能模塊與業務流程等。現將主要該協同辦公系統的主要功能模塊 做如下介紹。
3.3.1行政管理
行政管理，是企業管理中最基礎的業務功能，也是數據比較瑣碎的功能模塊； 其主要針對企業內部員工進行信息化、自動化的管理。行政管理模塊中又分為工 作報告、工作計劃、部門管理等子模塊。
工作報告子模塊包括工作日報、周報與月報，員工可自行創建新的工作報告； 而工作報告的填寫時間與填寫期限則由管理人員進行設定，逾期則不可再補錄遺 忘填寫的工作報告。
1工作曰報 周報"報 月統計I需計II勳］曰報I
按詳細方式査看 2014 s/| 1月2月3月4月5月6月7月8月9月10月11月12月 全
星期 曰期 內容 記錄時問 操作1
辦理擁：0個文件柜：0個計劉進度：°個妙督辦：0個 微信娜；
1 Lark^S5^冊；
樹、微信軸 2014-09-01 00:00:00 倏改點評
辦理艇：0個文件柜:Q個計劃進度：0個妙督辦:0個 微信;
微信目;
2 有些功；
瞬 2014-09-24 14:10:39
W-T! 2014-09-02 00:00:00 修改點評
圖 3-2 工作報告功能截圖
工作計劃子模塊實現對個人工作計劃進行周期性、流程性的管理與維護， 提供多樣化的計劃管理方式與工具，對計劃在各個階段的數據進行有效全面的整 合。
圖 3-3 工作計劃功能截圖
部門管理子模塊在領導層需要隨時掌握、了解員工的工作狀態、工作計劃安 排，以便及時的調整工作安排，該模塊則實現對工作人員的工作報告、考勤記錄 以及工作計劃負荷等信息進行管理。
部門用戶 曰抿 周抿月報 工作計劃負荷 曰考勤月考勤
圖 3-3 部門管理功能截圖
3.3.2 工作流程管理
工作流程是企業各部門進行聯動的業務模塊，流程數據可靈動性的在各部門 之間進行流轉。工作流程模塊中又包含了發起流程和代辦流程子模塊。
發起流程子模塊在進行實際業務操作時，工作人員可根據自身需要發起相應 的流程；而工作人員可發起的流程類型則由管理人員進行了權限設置。
已保存草稿 ◎提交丨恣加簽丨亡擬文 tn刪除 金須圖 護關聯項目 偽網盤附件
審批： □郝煒 □箔售人 回短信回消息與醒
圖晉通O?重要OQ緊急ID : 8084標題:［鎮江技術部］趙琦請假申請2014-10-24 卿人:趙琦 我的備注:| 「 ◎
ib&A 任務 開始時問 處理麗 剩余時問 用時（小肘） 績效 fib® -
鎮江技術部：趙 琦 申請 14-10-2416:12 0.0 0.00
請點擊此文件
申請人 |老琦 ―| 申請日期 12014-10-24 | 0
圖 3-4 發起流程功能截圖
待辦流程子模塊的在工作人員對該模塊中個人待處理的流程進行統一管理， 流程流轉至當前用戶時，平臺可通過短消息、手機短信進行提醒。多樣化的流程 處理方式，滿足不同業務流程的具體需求，如“指派”，將該流程指派至其他人員 進行處理； “掛起”，暫時不處理該項流程；“加簽”，增加其他人員共同對該流 程進行處理。
公文管理，主要針對收文流程、發文流程進行綜合的維護與管理；支持對發 文的“回收”操作；對發文進行進一步的處理。工作人員可將流程中的附加文件 分發至其他工作人員，實現資源的共同快速分享；同時，可將流程中的附加文件 進行快速歸檔，增強管理。公文管理包含了收發文處理、歸檔記錄、辦理記錄、 流程分發等子模塊。
收發文處理實現對平臺內的發文流程、收文流程進行統一的管理與維護，可 在該模塊中查看流程的詳細信息，包括流程審核的相關信息；也可直接參與流程 的審核，對流程進行處理。
歸檔記錄則是工作人員可對審核完畢的公文進行歸檔操作，形成卷宗，該操 作有利于公文的有效管理。工作人員可在該模塊中添加歸檔操作，對指定歸檔的 具體流程；模塊支持自定義、多條件的檢索方式，便于歸檔記錄的查詢。
辦理記錄模塊以列表的樣式對當前工作人員所辦理的各類流程進行記錄，并 可查看該流程的詳細信息、各階段的處理情況；同時，還可對流程進行相應的操 作，如催辦、撤回、重激活等。
流程分發則是工作人員將發文流程進行分發操作，即將該發文流程的文檔分 發至其他部門、人員查看。工作人員可選擇相應的部門、人員查看，而未選擇的 用戶則不會接收到該流程分發信息，也無法查看。
3.3.4項目管理
建立完善的項目管理機制，對項目進行全面性、專業化的整體維護，包括項
目成員、項目費用、與該項目的相關的流程、文檔、交流等。
圖 3-6 項目管理功能截圖
3.4 Android協同移動辦公子系統功能需求分析
為了滿足公司在外人員的移動辦公要求，本系統需要實現對移動辦公的支 持，開發Android手機客戶端應用，允許員工通過智能手機終端通過前置服務器 訪問公司內網的數字化協同辦公管理信息系統。
Android移動辦公手機客戶端可以理解為把原來需要通過Web方式訪問的功 能移植到Android手機客戶端上，但安卓手機客戶端并不需要實現原數字化協同 辦公管理信息系統的全部功能，主要有以下兩個原因：
首先，經常通過安卓手機終端訪問協同辦公管理信息系統的多為經常在外辦 事或出差的領導和員工，他們并不需要原0A系統所有的功能，他們在外經常用 到的功能是公文審批，公文查詢，公文下載等功能。
其次，手機的屏幕和輸入速度無法和電腦相比，如發起新的公文，流程設計 等功能則不適合在手機終端上實現。
綜上所述， Android 協同移動辦公子系統的主要功能性需求如下：
1.待辦事項：審批待審批公文，未閱讀的公文或消息等
2.公文查詢：查詢歷史公文信息
3.附件下載：下載 word、excel、pdf 格式的附件。
4.個人設置：密碼修改，網絡設置等。
本文重點對三個方面進行論述，這三個重點方面分別是系統用例、系統流程 圖和主要功能模塊需求。
3.4.1 系統用例分析
圖 4-2 是 Android 版協同移動辦公客戶端的系統用例圖。
本項目在開發前必須先進行深入調研，了解用戶的當前協同移動辦公系統， 并對用戶的對于移動終端應用的需求進行深入分析，本次開發的數字化協同移動 辦公系統的移動客戶端首先需要提供一個安全接入接口,該安全接口在數據應用 層次上來保證用戶數據和客戶端的運行環境的安全，其次本文開發的數字化協同 移動辦公系統的客戶端應該有一個登錄模塊,該登陸模塊用以驗證用戶身份的合 法性，在通過身份驗證后，用戶方可登錄數字化協同辦公系統。在Android移動客 戶端中用戶可以進行如圖4-2系統用例圖中的各項操作，如果能夠遵循系統用例 圖進行設計，則該系統基本能夠滿足用戶對協同辦公系統移動Android客戶端的 需求。
圖 3-7 系統用例圖
3.4.2系統流程圖
圖3-8是Android版協同移動辦公客戶端的流程圖
圖 3-8 數字化協同移動辦公系統客戶端流程圖
3.4.3 主要功能模塊的需求分析
基于Android平臺的數字化移動協同辦公系統的客戶端主要模塊功能分析如 下：
安全接入模塊的設計是結合存儲卡以及個人數字證書使用的功能模塊,它是
從Android系統移動終端進入協同移動辦公系統的唯一的安全接入入口。其主要 作用是在驗證用戶身份（存儲卡上的個人數字證書）后,首先掃描后臺當前運行的 進程,系統自動關閉不受信任的后臺駐留的進程，僅保留白名單中的受信任的進 程。在自動關閉后臺駐留的不信任進程后,此時移動終端才會進入到協同移動辦 公系統的主界面，供用戶使用該移動協同辦公系統的各項功能。
Android客戶端自動更新升級模塊，當用戶打開Android移動協同辦公系統軟 件后,后臺的更新進程會同步啟動，先從服務器側獲取當前版本，再提取本地手 機客戶端的版本信息，并進行比較,若需要更新,則自動從服務器端下載最新版本 的軟件并進行強制升級更新，要求客戶端版本必須與服務器端一致后方可正常進 入系統使用。
登錄模塊,是用戶在通過 Android 移動終端應用登陸協同移動辦公系統所必 須使用的具備身份識別和身份驗證的模塊，該模塊身份驗證通過前置服務器與身 份認證服務器進行交互,并返回認證結果給客戶端。
流程處理模塊,是系統用于處理系統各項流程所調用的模塊，用戶通過身份 驗證后,僅可以看到該身份所分配的權限能使用的功能,用戶可以在授權范圍內來 進行相應的移動辦公操作。在用戶的每一次的流程處理的操作中,都會使用存儲 卡上的個人證書進行數字簽名,實現數字簽章的功能，以保證數據的不可抵賴性。
附件的處理模塊,附件是在流程流轉時所附加的各種文件，當然并不是所有 的流程都有附件。Android移動辦公客戶端必須可以根據附件的文件格式來調用 手機終端上的移動應用來正確的打開閱讀或編輯。根據客戶的需求，目前該客戶 端只需要支持.pdf、.word、.xls、.xml文件格式。
3.5系統非功能需求分析
3.5.1系統運行效率
系統運行效率是是指與在規定的條件下軟件的性能水平與所使用資源量有 關的一組屬性。本項目在此次Android客戶端設計中，盡可能使新的系統與原有的 系統完美無縫對接,在原則上不修改原服務器的所有工作流程，并且客戶端軟件 圖形界面方面設計的更符合企事業單位的形象，并為使用數據過濾和數據壓縮技 術來降低數據通信量，從而提升用戶移動客戶端的性能，使得Android客戶端處 理的數據量大大減少，全面提升了用戶使用數字化協同移動辦公系統的體驗。
3.5.2數據安全性
因為數字化協同移動辦公系統可以讓用戶只要持有一部Android移動終端就 可以在任何地點使用辦公系統，從另一方面講，這也必然產生一定的安全隱患， 從而必須采取一定的措施來保證用戶數據的安全性。本項目在對用戶的環境做過 詳細的調研后，從網絡和軟件應用層上等多個方面來保護用戶的辦公系統的數 據。此外，由于Android平臺是Google免費提供的開源平臺，它本身也會存在一定
的安全隱患，這就必須依賴系統及應用軟件的更新來彌補這些安全漏洞。
3.5.3可維護性
維護性是指與進行指定的修改所需的努力有關的一組屬性。本次開發的數字 化協同移動辦公客戶端首先應定義統一格式的日志，方便研發人員進行開發，測 試，故障的定位及修復。
3.5.4可擴展性
作為系統設計人員，除了關注產品的功能和性能外，還應多考慮系統結構的 可擴展性，可擴展性是指軟件擴展新功能的難易程度。可擴展性越好，表示軟件 適應快速發展的需求的能力就越強。本項目的初始需求可能不能滿足未來發展的 需要，這時可擴展性就顯得尤為重要，因為如果推到原有項目，重新建設， 無 論是經濟成本還是時間成本對于企事業單位而言都難以接受。因此本文在設計的 初期必須將未來的擴展性考慮進去，這樣才能滿足企事業單位日益增長的功能需 求。
第四章 系統總體設計
系統總體設計是移動學習終端平臺開發過程中一個重要的階段，系統設計分 首先是數字化協同移動辦公平臺總體結構設計，然后根據功能將系統分解為若干 子系統，完成每個子系統的設計。
4.1系統整體架構設計
本系統的架構設計需要考慮到網絡安全、數據安全，因此設計如下整體架構 圖。在本系統平臺的架構中，我們使用包過濾防火墻來保護前置服務器的網絡安 全，手機終端用戶需連接前置服務器時，必須先通過硬件防火墻的數據包安全檢 測，而前置服務器和原協同移動辦公平臺之間則使用隔離網閘來保證內網服務器 安全性。在應用服務方面，本項目設計主要分為三個部分:原數字化協同辦公系 統服務器、前置服務器以及Android手機客戶端。
圖 4-1 服務器系統及網絡拓撲圖
(1)原協同辦公系統服務器:本項目是在原有的數字化協同辦公系統上進行 二次開發，必須使移動終端和桌面終端可以同時使用，系統的數據庫仍采用原有 的協同辦公系統的數據庫,因此本文就采用原始的協同辦公系統服務器作為業務 處理和數據庫的服務器。在不變動原有功能的基礎上擴展出移動辦公的功能。
(2)用戶身份驗證服務器：該服務器的作用是辨別用戶身份并根據他們的身 份為其提供相應的應用服務，它同時提供桌面和手機終端用戶登陸的用戶驗證服 務。
(3)前置服務器:前置服務器上的應用服務則是移動辦公系統的重點開發的對 象，前置服務器的作用是在移動終端和原有的數字化協同辦公系統之間作數據處 理和數據中轉之用，為了提高Android客戶端和原數字化協同辦公系統服務器之 間數據傳輸的效率，本設計方案通過數據壓縮及去冗余的方法降低兩者之間的交 互數據的通信量，這實際上是起到了數據過濾的功能。而數據的轉發則在數據的 過濾之后，它將自動生成的XML數據傳輸給協同辦公系統和Android移動客戶 端，客戶端在接收到XML數據后，再調用移動應用客戶端上相應的數據解析模 塊對XML數據文件進行解析，并顯示到移動終端的桌面上。而移動終端發送至 前置服務器的數據，則通過該服務器解析成原數字化協同辦公系統所能識別的原 始數據，再發送至原辦公系統服務器上由原服務器來處理相應的業務流程。
⑷Android移動應用客戶端:Android客戶端是安裝在用戶的Android移動終 端設備之上，它的主要作用是和后端的服務器進行通信，并通過圖形化的方式顯 示在移動終端設備的屏幕上。 Android 客戶端界面設計是本項目的重中之重， Android 客戶端除了必須滿足用戶的功能性需求外，還必須將客戶端連入服務器 的安全保障以及友好易用的用戶界面考慮進去。Android客戶端的主要功能模塊 包括登錄、安全接入平臺、流程處理、XML解析、用戶設置、附件處理、客戶 端更新等模塊,整體功能結構圖如圖 4-2 所示。
圖 4-2 Andriod 客戶端功能結構圖
4.2前置服務器的實現
前置服務器是專門為移動客戶端提供服務的，它并不提供辦公系統的核心功 能。它是通過調用原有的數字化協同辦公系統的接口來實現與移動客戶端的通信 請求。這就避免了需要重新為移動平臺定制全新的應用系統的重復工作，極大的 降低了開發成本，提升了開發效率，并且為客戶節約了新開發全新協同辦公應用 系統的資金。
前置服務器還可以使客戶端在向服務器請求數據時的響應數據比原始的服 務器少很多，可以降低網絡延時，增強用戶體驗。前置服務器還可以對移動客戶 端的升級維護進行支持，降低原辦公服務器的負載。
前置服務器還可以從安全方面來保障企事業單位的數據安全性，同時還可以 給予終端客戶良好的使用體驗。前置服務器通過HTTPS加密協議來保證數據的 安全，同時系統自帶的防火墻的功能來對進出的通信數據進行包過濾的檢測來阻 止外網上的一些攻擊行為。
前置服務器在邏輯上分為六層：傳輸加密層、協議適配層、終端適配層、業 務邏輯層、內容聚合層、系統服務層，每層都有各自的作用。在實際部署前置服 務器時，我們可以搭建一個虛擬化服務器平臺，將不同的層分別部署在不同的虛 擬服務器之上，并且可將不同的功能模塊部署到虛擬化服務器平臺不同等級的安 全區域。不同的層次和功能模塊在具體的方案中要進行必要的裁剪,以適應各個 企事業單位的需求。根據方案的復雜程度,可能只需要某些層次的某些模塊就能 滿足要求,在后面的設計中,可以看到模塊裁剪的案例。
圖 4-3 前置服務器架構圖
4.2.1 傳輸加密層功能說明
傳輸加密層可以使用軟件加密，也可是硬件加密。本項目的傳輸層是通過 SSL的方式進行加密，同時如有必要還可以使用國密加密。在數據傳輸過程中， 服務器向客戶端發送數據是以加密的方式在互聯網上傳輸，當到達客戶端后，則 由客戶端進行解密操作，而客戶端向服務器發送數據時，也需要先加密數據，再 進行傳輸，最后再由接受到數據的服務器進行解密。如果使用國密加密，則移動 客戶端也需要相應的解密軟件或者解密芯片才能實現國密的加密方式。
4.2.2 協議適配層功能說明
因為移動終端用戶可能使用不同的應用層協議,而協議適配層可以實現兼容 各種移動終端，由協議適配層來完成的協議的適配工作。本項目所開發的移動客 戶端的最佳應用協議為XML/HTTPS,如果使用Web App的方式來開發，則使用 的最合適的應用協議是 HTML/HTTPS。
4.2.3 終端適配層功能說明
終端適配層可以根據不同類型，不同大小，不同分辨率的屏幕將最佳的顯示 效果顯示在Android手機移動終端顯示器上。終端適配層會根據移動終端在請求 中自帶的 Agent 信息來自動判斷最合適的終端類型,也支持用戶個性化自定義的 終端類型。
4.2.4 業務邏輯層功能說明
業務邏輯層主要是前置服務器所有可能的包含前置機所有可能的和業務相 關的模塊。在圖5-3的前置服務器結構圖中僅僅列出了用戶可能使用到的一些功 能模塊，但根據不同的企事業單位客戶的需求，會有不同的功能模塊。
4.2.5 內容聚合層功能說明
內容聚合層就是將多個業務模塊的數據進行聚合,通常用于登陸首頁的信息 展示。內容聚合層可以在不同的用戶通過驗證后，根據其自身所擁有的權限來顯 示相應的功能模塊，隱藏其無權使用的功能模塊，并將多個功能模塊聚合在一個 數據包中，通過終端適配層和協議適配層將要用戶的內容返回并顯示在用戶的移 動終端的顯示屏幕上。
4.2.6 系統服務層功能說明
系統服務層包括了一下四個模塊:
安全子系統模塊:用于實現用戶認證,權限管理,簽名校驗的各種技術方案,包 括PKI, CPK，雙通道,OAuth （主要用于微博）認證等。除此之外還實現單點登錄的 功能,讓用戶在不同的系統之間統一認證,根據系統對安全的需求不同,實現多重 認證,認證升級,降級認證等功能。
接口服務子系統模塊:該模塊為前置服務器提供接口和外部系統進行調用和 通訊。數據路由和格式轉換:和現有系統進行集成的工具（例如和數字化協同辦公 信息管理系統）。
日志服務和監控審計模塊:是數字化協同辦公信息管理系統的最基本的安全 要求和保障。
數據壓縮和格式轉換模塊：用于數據傳輸的壓縮及在移動客戶端和原協同辦 公系統之間進行數據的轉換。
4.3移動客戶端的分析設計
本文是基于Android客戶端平臺并使用Scrum軟件開發模型來開發移動客戶 端應用軟件。移動客戶端的架構如圖5-4 所示,本文采用了比較流行的
MVC(Model View Controller)框架，它是是模型(model)一視圖(view) — 控制器 (controller)的縮寫，一種軟件設計典范，用一種業務邏輯、數據、界面顯示分離 的方法組織代碼，將業務邏輯聚集到一個部件里面，在改進和個性化定制界面及 用戶交互的同時，不需要重新編寫業務邏輯。 MVC 被獨特的發展起來用于映射 傳統的輸入、處理和輸出功能在一個邏輯的圖形化用戶界面的結構中。從圖 5-4 中可以看出，前置服務器通過HTTPS加密通道將來自原辦公系統服務器的數據轉 換成特定的XML數據，再發送給Android客戶端,Android客戶端在接收到XML 數據后再調用XML解析模塊來還原數據，最后通過用戶的移動終端顯示器顯示
圖 4-4 客戶端整體框架圖
本文之所以選擇MVC設計模式，是因為它是一個非常適合Android應用開發 的框架形式。視圖層一般采用XML文件進行界面的描述，使用的時候可以非常 方便的引入。同時便于后期界面的修改。邏輯中與界面對應的 id 不變化則代碼 不用修改，大大增強了代碼的可維護性。Android的控制層的重任通常落在了眾 多的 Acitvity 的肩上，這句話也就暗含了不要在 Acitivity 中寫代碼，要通過 Activity 交割 Model 業務邏輯層處理，這樣做的另外一個原因是 Android 中的 Acitivity的響應時間是5s,如果耗時的操作放在這里，程序就很容易被回收掉。 模型層將對數據庫的操作、對網絡等的操作都應該在 Model 里面處理，當然對 業務計算等操作也是必須放在的該層的。 [13]就是應用程序中二進制的數據。由 于 Android 移動應用的需求變化和添加比較不穩定,各模塊靈活改動和增添的 MVC 框架在此尤為合適。 MVC 設計模式不僅是 Google 官方推薦的設計開發模 式，同時也是廣大的Android開發人員所優先使用的開發模式。
4.4安全接入平臺模塊設計
安全接入平臺本身就是一個Android應用，而Android的安全在很大程度上依 賴于Linux操作系統層的安全機制，尤其對于進程和用戶級別的邊界限制。由于 Android 面向的是個人設備，即個人持有和使用的設備， Android 巧妙地利用了 Linux內在的多用戶支持特性：為每個應用供應商創建一個單獨的用戶。這意味 著每個應用以不同的用戶權限運行（除了那些來自同一個供應商的）。在默認情 況下，一個應用所擁有的文件，其他應用是無法訪問的。可以把它理解成一個" 沙盒"。它提供了安全的空間為本項目所研發的Android移動應用在其中運行，將 Android 系統本身的一些風險與客戶端應用隔離開來。這種方式帶來的直接影響 是由于每個應用在自己的“獨立運行空間（silo）”中執行，因而安全性得到了 提高。它是本文所有應用和功能的總入口。當用戶在Android移動終端啟動移動 辦公客戶端軟件時,首先啟動是安全接入平臺,安全接入平臺在運行后，首先會查 殺后臺運行的非白名單中的可疑進程,然后再通過服務器進行用戶的驗證，在驗 證完用戶后再加載該用戶權限之內能夠使用的功能模塊,最后會屏蔽 Android 手 機上的 HOME 鍵,防止移動客戶端應用非正常返回桌面，啟動其他應用程序。
當 Android 移動終端通過用戶認證服務器驗證用戶的身份和權限后,此時用 戶的數據的可信環境將由安全接入平臺負責,安全接入平臺系統采用白名單機制 來監測Android的移動終端上的后臺軟件進程,。安全接入平臺系統上的白名單不 可自行添加后臺應用進程，對用戶不可見，統一由安全接入平臺模塊負責，并隨 著軟件的更新升級而更新白名單軟件,用戶無法在安全接入平臺的白名單中自定 義非系統指定的軟件進程,只能在系統初始化或升級時進行軟件的安裝、升級或 卸載。
4.5XML數據解析模塊設計
由于本文主要的通信數據格式都是XML,那么本文就需要設計出XML數據 的解析模塊。當客戶端發送一個request請求，服務端就會以xml的數據格式返 回一個response響應。但是在客戶端界面展示xml數據并不是那么人性化與現實, 所以在此之前，會對xml進行數據解析。縱觀軟終端的大部分項目中，在客戶端 進行數據解析采用的是SAX（Simple API for XML）,這是有道理的。SAX的工作原 理簡單地說就是對文檔進行順序掃描，當掃描到文檔（document）開始與結束、 元素（element）開始與結束、文檔（document）結束等地方時通知事件處理函 數，由事件處理函數做相應動作，然后繼續同樣的掃描，直至文檔結束。因為 SAX 具有解析速度快，內存消耗少，可以有多個 ContentHandler 對象，所以本 文覺得SAX的XML解析方式更適合本項目的Android移動客戶端的XML數據 的解析。
4.6數字簽名模塊設計
因為考慮到用戶操作的數據安全性以及不可抵賴性，本文設計了這套數據簽 名模塊，凡是在協同移動辦公系統中重要的操作流程均需要個人數字簽名數據, 數字簽名技術是將摘要信息用發送者的私鑰加密，與原文一起傳送給接收者。接 收者只有用發送者的公鑰才能解密被加密的摘要信息，然后用 HASH 函數對收 到的原文產生一個摘要信息，與解密的摘要信息對比。如果相同，則說明收到的 信息是完整的，在傳輸過程中沒有被修改，否則說明信息被修改過，因此數字簽 名能夠驗證信息的完整性。［14］本文目前涉及到數字簽名功能使用的地方主要是 流程處理模塊中對流程的處理中送下一結點、回退和直送三種處理過程均需要完 成數字簽名過程。
4.7附件下載和查看模塊設計
本文設計了一個附件下載管理器，通過驗證的用戶可以根據服務器授予的權 限，自動調用下載管理器來下載相應的附件。Android移動客戶端通過XML數 據流來獲得附件的下載列表以及下載地址鏈接。移動客戶端進入到下載列表后， 在這里登錄用戶可以對附件進行下載。當點擊“下載”按鈕后，后臺線程便開始 進行進行附件的下載。當附件下載完畢，如需立即查看附件，本文將自動調用 Android 設備上已經安裝的與附件格式匹配的相應的客戶端應用進行查看。
4.8客戶端更新模塊設計
客戶端的更新升級非常重要，不但可以及時通過升級的方式來解決移動客戶 端在設計中的BUG,還可以在需要做功能模塊的擴展時，及時更新移動終端的 客戶端軟件，使之可以及時使用擴展的功能。
本文開發時，將在客戶端的和前置服務器的相應的XML文件中存放Android 協同移動辦公系統客戶端的版本信息,并且將最新的客戶端應用的安裝文件放在 前置服務器上。當應用軟件啟動后，后臺的更新模塊的進程將分別獲取本地和前 置服務器上的版本信息,并進行比對,若前置服務器的版本號高于移動終端客戶端 的版本好,則會自動啟動下載進程來下載新版本的客戶端軟件。當新版客戶端軟 件下載完成后,將自動關閉本地的客戶端進行更新安裝。具體流程圖如下圖所示：
圖 4-5 客戶端自動更新流程圖
4.9數據交互接口設計
數字化協同辦公系統在該企業的整個信息化架構中處于管理信息化層，作為 管理信息化系統的一部分，數字化協同辦公系統與前置服務器應用系統、已建成 或將建設的多個信息系統都存在數據的交互關系。
本項目在數據交互接口設計方案中采用以下幾種技術來實現應用系統間的 數據交互。通過以下提供的幾種數據交互機制，可以實現數字化協同辦公系統與 其他應用系統間的應用互連。
1.數據庫集成技術
在數字化協同辦公系統中可以使用數據庫集成機制實現與第三方應用系統 集成。數字化協同辦公系統和前置服務器應用系統可以通過JAVA數據庫連接技 術來實現在數據庫層上的數據集成。
2.網址頁面集成技術
在數字化協同辦公系統中可以使用網址頁面集成機制實現與第三方系統應 用集成，用戶可以通過點擊數字化協同辦公系統中的網址鏈接進入第三方應用系 統。
3.基于文件交換的集成技術
這種基于文件交換的技術主要是針對一些對實施數據傳輸延時不敏感的應 用系統，且因其系統的相對封閉性僅能提供傳統接口方式來進行數據交換。采用 基于文件交換的集成技術，數字化協同辦公系統需要與目標系統協商需要交互的 文件內容及其格式，目標系統在規定的時間調度內將包含源數據的文件發送到數 字化協同辦公系統指定的文件目錄中，數字化協同辦公系統處理這些文件后可以 獲得需要的數據，并根據需要決定是否返回處理結果給目標系統。
4.基于特定網絡協議集成技術
基于特定網絡協議的技術在數字化協同辦公系統來實現與第三方系統應用 集成與數據交互，通常可以在兩者之間通過HTTP協議來完成兩大系統的數據傳 遞工作。
5.Web Service
Web Services就是應用程序，它設計了一個能夠通過Web進行調用的API。 而這個API的作用就是通過編程的方法來調用相關的應用程序。Web Services是 建立可互操作的分布式應用程序的新平臺之上的， Web Services 平臺是一套標 準，它定義了應用程序如何在Web上實現互操作性。用戶可以用任何語一言， 在任何平臺上寫 Web Services，我們可以通過 Web Services標準對這些服務進 行查詢和訪問。
數據交互接口實現方式說明：對于系統數據傳輸量不大的交互，采用 Web Service實現應用系統的集成。Web Service適用于不用語言不同平臺的應用程序 集成，便于跨防火墻的通信，實現方便。對于系統數據傳輸量較大的交互，根據 原有系統的實際情況，優先選擇SOA的方式，如XML；其次選擇數據庫級別或 者導出文件的方式。
第五章 系統詳細設計與實現
本章節主要是根據以上兩個章節對Android數字化協同移動辦公信息管理系 統進行深入的設計。并且對系統的各個功能組成模塊的具體技術進行深入分析， 對Android數字化協同移動辦公信息管理系統進行了具體的設計實現。對各功能 模塊使用的具體技術和實現方法進行了詳細的描述。
5.1 系統架構實現
本系統的分層架構圖如下所示：
表現層(JSP)
控制層(Con troller)
業務邏輯層(Service)
數據訪問層(Da。)
持久化層(P0)
數據庫(DB)
圖 5-1 系統分層架構圖
1. 表現層
傳統的 JSP 技術實現。 JSP 經過多年的發展，應用廣泛而穩定，能夠很好的 將信息顯示給客戶。 JSP 頁面接受客戶的具體請求，并對用戶輸入的數據進行簡 單的格式驗證，然后發送給控制層相應的Action類，并獲得返回數據顯示在JSP 頁面上。
本系統表現層的具體結構如下圖所示：
d 曲 WebRoot t> 已 images
META-INF
script style WEB-INF
> & jsp [::'I i b
爲f mis.tld 岡 web.xml 宙 bottom.jsp 』center.jsp j* index.jsp 笑 initDbFinish.jsp C? I&ftjsp E? loginULjsp C? logoutjsp ® noPrivilege.jsp C? rightjsp 居 W.jsp 國 welcome.jsp
圖 5-2 系統表現層結構圖
圖6-2中各個文件夾及JSP文件的具體作用如下表所示。
表 5-1 表現層主要文件夾 /文件介紹
序號 文件夾/文件 功能介紹
1 images jsp頁面中所要用到的圖片資源
2 script 各個頁面用到的javascript腳本的集合
3 style jsp頁面所用的css樣式
4 WEB-INF/jsp 系統所有需要登錄才能訪問的jsp頁面
5 index.jsp 系統首頁
6 welcome.jsp 登陸成功的歡迎界面
2. 控制層
即MVC模式里面的“C"(controller)，負責控制業務邏輯層與表現層的 交互，由Struts2來實現。當用戶通過JSP頁面發送一個請求時，Struts2會把請 求轉發給對應的 Action 類， Action 類通過調用業務邏輯層接口來得到用戶請求 的數據，再發送給相應的JSP頁面。
本系統控制層的具體結構如圖 5-3 所示：
圖 5-3 系統控制層結構
控制層主要包和類及其功能的介紹如下表所示：
表 6-2 控制層主要包或類介紹
序號 包/類 功能介紹
1 contract 包 辦公管理相關功能的Action類，主要有ContractAction.java、 CapRtnAction.java、ImplCostAction.java、
ContractIndustryAction.java、 FncAction.java、 PchAction.java、 SaleAction.java 等
2 interceptor 包 struts2攔截器，用于檢測用戶是否登錄，請求數據的用戶未登 錄則轉發頁面到首頁，包含 AuthInterceptor.java 和 PrivilegeAuthTag.java
3 user 包 用戶相關信息 Aciton 類，包括 DepAction.java， RoleAction.java， DutyAciton.java， UserAciton.java 等。
4 BaseAction.java 繼承Struts2的ActionSupport.java，實現了大量常用方法，本 系統的所有Aciton類都繼承該類。
5 ExcelWorkSheet.j ava 需要生成excel報表并下載的Action需要使用該類。
6 J qGridB aseAciton.j ava 如果JSP頁面需要使用JqGrid表格，則需要繼承該類
7 InitDbAction.j ava 初始化測試數據的Action
3. 業務邏輯層
負責實現管理業務邏輯。業務邏輯層接口的方法被 Action 調用后，會調用
DAO層的接口從數據庫讀取數據，并對讀取的數據進行一定的處理并返回。
本系統業務邏輯層的具體結構如圖 5-4 所示：
幅 Package Explorer日 爲> a B
"曲 service
t> S bws
>田 contract
田 cus
>由 pdt
卜田&p
丿田user
/ S impl
>[7] DepSerlmpl.java
>[T] DutySerlmpl.java
>[T] ResSerlmpl.java
>[?] RoleSerlmpl.java
|> [7) SearchRoleSerlmpl.java
t> [T] UserSerlmpl.java
l> ① DepSer.java
A E) DutySer.java
> ® ResSer.java
t> [T] RoleSer.java
l> 2] SearchRoleSer.java
t> ® UserSer.java
圖 5-4 系統業務邏輯層結構
業務邏輯層的主要包和類及其功能的介紹如下表所示：
表 5-3 業務邏輯層主要包和類介紹
序號 包/類 功能介紹
1 contract 包 該包都是接口，定義了辦公系統所需業務方法的名稱，主要有
ContractSer.java、CapRtnSer.java、ImplCostSer.java、
ContractIndustrySer.java、FncSer.java、PchSer.java、SaleSer.java 等
2 contract.impl 包 contract包中的接口的實現類，主要有ContractSerlmpl.java、 CapRtnSerImpl.java、ContractIndustrySerImpl.java、
FncSerImpl.java、 PchSerImpl.java、 SaleSerImpl.java 等等
3 user 包 和用戶相關的一些信息的處理的接口，主要有UserSer.java、 DepSer.java、 RoleSer.java 等。
4 user.impl 包 user包中接口的實現類，主要有UserSerlmpl.java、 DepSerImpl.java、 RoleSerImpl.java 等。
4. 數據訪問層
即Dao層，負責與持久化對象PO交互。本系統的該層封裝了數據的增刪查 改基本操作，供 Service 層調用。不過為其降低模塊耦合，提高代碼規范， Service 層的類并不直接訪問Dao層的實現類，而是其對應的接口。
(e Package Explorer 仔爲▽ 1=1 亡
"® dao Ij
d 田 contract
t> ffi impl
t> 國 CapRtnDaojava
t> 國 ContractDaojava
> [j] ContractlndustryDaojava
t> 國 ContractPropertyDaojava
t> 2) ContractTypeDaojava
t> [j] DepPercentDaojava
t> 2) FncDaojava
t> [J) ImpICostDaojava a
t> 國 ImpICostTypeDao.java
t> [J] PayTypeDaojava
t> 國 PchDaojava
t> ① PchPayDaojava
t> PchPdtDaojava
t> 國 RdCostDaojava
t> 2) SaleDaojava _
t> [J] SaleRewardDao.java
t> [7) TaxBillTypeDao.java
r> $ cus
>$ pdt
>$ sp
>$ user
>[T| BaseDao.java
>[I] BaseDaoImpl.java
>岡 Criterionjava
圖 5-5 數據訪問層結構
數據訪問層主要包和類及其功能的介紹如下表所示：
表 5-4 數據訪問層主要包和類介紹
序號 包/類 功能介紹
1 contract 包 該包都是接口，主要有 ContractDaojava、CapRtnDaojava、
ImplCostDao.java、 ContractIndustryDao.java、 FncDao.java、 PchDao.java、 SaleDao.java 等
2 contract.impl 包 contract包中的接口的實現類，主要有ContractDaolmpl.java、 CapRtnDaoImpl.java、 ContractIndustryDaoImpl.java、
FncDaoImpl.java、 PchDaoImpl.java、 SaleDaoImpl.java 等等
3 user 包 和用戶相關的一些信息的處理的接口，主要有UDaoDao.java、 DepDao.java、 RoleDao.java 等。
4 user.impl 包 user包中接口的實現類，主要有UserSerlmpl.java、 DepSerImpl.java、 RoleDaoImpl.java 等。
5 BaseDao.java Dao層的核心類，定義大量的通用方法，如對數據庫表的增刪 改查等，本層的其他接口或類只要繼承BaseDao.java就可少寫 大量代碼
6 BaseDaoimpl.java BaseDao.java 接口的實現類，通過 Spring 的 SessionFactory.java 來獲得數據庫會話，事務直接配置給Spring
1. 實體層
本系統采用 Hibernate 框架作為 ORM 框架，實體層的每一個實體類都對應
著數據庫中的一個表，通過對實體類的增刪改查，就能夠很方便的對數據庫中的 相應數據進行相同的操作。
對于實體類的生成，可以用一些工具（如Power Designer）將關系型數據庫 的數據映射通過逆向工程為生成相應的實體類，不過這種方法有很大的缺點，比 如進行了不大的改動也要重新對所有的實體類重新生成，太過依賴開發工具，而 且對多對多和一對一的支持也不好，現在已經很少有人用逆向的方式來生成實體 類。
現在使用 Hibernate 框架的開發者絕大多數都是用正向的方式來一個一個的 手寫實體類，雖然初期可能工作量較大，但后期的修改很方便，而且能夠加強開 發者對Hibernate框架的了解。
該層的主要類和hbm文件如下圖所示：
圖 5-6 實體層類結構
5.2移動客戶端主要功能模塊的具體實現
5.2.1系統開發環境
開發語言：JAVA
開發平臺： 2.3 版本以上的 Android 系統
操作系統平臺： WINDOWS 7
系統結構： C/S
開發工具： Eclipse3.6+ADT2.1+SDK1.6+Tomcat6.0
5.2.2Android 運行環境
1．Android 開發資源獲取
(1)java JDK 下載:
進入該網頁: http://java.sun.com/javase/downloads/index.jsp 選擇 Download JDK只下載JDK，無需下載jre.
(2)eclipse 下載
進入該網頁:http://www.eclipse.org/downloads/ (或者直接點擊下載:BT下載、 HTTP 下載)我們選擇第一個(即 eclipse IDE for java EE Developers)
(3)下載 Android SDK
說明:Android SDK兩種下載版本，一種是包含具體版本的SDK的，一種是 只有升級工具，而不包含具體的SDK版本，后一種大概20多M,前一種70多 M。
完全版下載 (android sdk 2.1 r01) 升級版下載 (建議使用這個，本例子 就是使用這個這里面不包含具體版本，想要什么版本在Eclipse里面升級就行)
2. 軟件安裝
(1)安裝 jdk 6u19 安裝完成即可，無需配置環境變量
(2)解壓 eclipse eclipse 無需安裝，解壓后，直接打開就行
(3)解壓 android sdk 這個也無需安裝，解壓后供后面使用
3. Eclipse 配置
(1)安裝 android 開發插件
打開 Eclipse, 在菜單欄上選擇 help->Install New SoftWare 輸入網址: https://dl-ssl.google.com/android/eclipse/(如果出錯，請將 https 改成 http)點擊 Next-->Next 按鈕，選擇 I accept the terms of the license agreements 點擊 Next,進入 安裝插件界面，安裝完成后，點擊Yes按鈕，重啟Eclipse.
(2)配置 android sdk
點擊菜單window->preferences，選擇你的android SDK解壓后的目錄，選錯了 就會報錯，這個是升級工具，目前還沒有一個版本的SDK；升級SDK版本，選擇 菜單 window->Android sdk and avd manager 選擇 update all 按鈕，選擇左邊的某 一項，點擊accept表示安裝，點擊reject表示不安裝，我這里只選了 SDK 2.1和 samples for api 7 , 自己可以任意自定義，確定后，選擇 install 按鈕，進入安裝； 新建 AVD(android vitural device)和上面一樣，進入 android sdk and avd manager, 選中Vitural Devices在點擊New按鈕，點擊New按鈕后名稱可以隨便取，target 選擇你需要的SDK版本，SD卡大小自定義，點擊Create AVD,得到如下結果顯示 創建 AVD 完畢。
圖 5-7 創建 AVD 過程結果完成截圖
(3)新建 Android 項目
選擇菜單file->new->other進入如下界面:選擇新建Android Project項目，點 擊Next按鈕，名稱自定義，應用程序名自定義，報名必須包含一個點以上，min SDK version里面必須輸入整數，點擊Next，注：若有錯誤如:Project ... is missing required source folder: 'gen'，則將 gen->Android.Test->R.java 這個文件刪掉? Eclipse 會為我們重新生成這個文件，并且不會報錯。
5.2.3 用戶登陸模塊實現
圖 5-7 登錄流程圖
登錄模塊實現， 跟通常的驗證方法一樣， 本文主要使用開源的 DefaultHttpClient 包，通過對 http 協議的各種操作封裝，以便此次開發的使用。 登錄驗證時，移動客戶端需要post兩個必填參數，一個是用戶名，一個是密碼。 前置服務器對用戶名和密碼驗證通過后，返回 cookie 值，客戶端進行保存，后 續的 http 操作都要使用這個 cookie 值作為必要的參數保證進行通信安全，前置 服務器會根據 cookie 的值對當前登錄用戶的會話狀態維護。
登錄成功后移動客戶端會get到當前登錄用戶的待辦事項的XML數據流， 解析之后得到具體數據信息，再保存到具體實例類里。移動客戶端會根據流程的 數量，對主界面中的“待辦事項”圖標進行重繪。這里本文是使用OpenGL的開 源類庫提供的方法實現的，對"待辦事項"的圖標進行了重繪，根據待辦事項的數 量在應用圖標的右上角新建了一個canvas，來繪制了圖示樣式的待辦事項個數， 然后合并圖層，達到提示效果。
5.2.4 待辦事項模塊實現
成功登錄后，點擊"待辦事項"圖標進入待辦事項界面，界面左側使用 Android 的Listview控件，顯示每條待辦事項的具體信息，這些數據信息在用戶成功登錄 時就已經從前置服務器端get到,并存放在了相應的實體類里只要取出顯示即可。 進入待辦事項頁面時，本文通過改寫的BaseAdapter將Listview與數據源建立對
應關系。
每當用戶訪問視圖列表中的內容時，Listview的具體信息會被顯示出來。用 戶訪問Listview過程中，系統通過后臺的線程，從前置服務器上獲取對應流程具 體的 XML 數據流，并使用 XML 解析器進行數據解析，將數據存放到對應的 實體類中，最后使用硬編碼的方式將實體類中存儲的數據顯示在對應的組件中。
5.2.5 公文管理模塊實現
系統能實時的接收內部0A系統發來的公文清單，歸類到“待辦公文”中，當 公文處理完畢后，將公文歸類到“已辦事項”目錄中。如下圖所示：
已辦清單
"已辦事項列表（） 十月份收支明細表 〉
所得稅收政策 >
部門員工調整計劃 〉
召開2010年股東大會、
預案 ?
本月財務收支明細表>
共5條記錄頁首頁上一
頁下一頁
圖 5-12 已辦公文列表
公文以文件的傳遞為主，處理選定公文后，服務器將會把公文的狀態更改為 “處理中”狀態，手機客戶端根據用戶的選擇從服務器下載相關的公文（權限允許 的情況下），在當前用戶處理完公文前，其他用戶不允許下載處理該公文。打開 公文后，可以在附件中查看公文的內容，然后對公文作兩種形式的處理。一是“領 導批示” 指的是使用客戶端的用戶角色為領導時，可以對公文進行批示，二是“相 關意見”可以填寫有關意見，改變公文的審批狀態。對公文進行批示后將批示信 息反饋到服務器，服務器會將對應公文的的批示狀態信息會改變。
圖 5-13 待辦公文列表
公文處理的實現的主要代碼如下：
public void initializeResolveListener() {
mResolveListener = new NsdManager.ResolveListener() {
@Override
public void onResolveFailed(NsdServiceInfo serviceInfo， int errorCode) {
Log.e(TAG， "Resolve failed" + errorCode);
@Override
public void onServiceResolved(NsdServiceInfo serviceInfo) {
Log.e(TAG， "Resolve Succeeded. " + serviceInfo);
if (serviceInfo.getServiceName().equals(mServiceName)) {
Log.d(TAG， "Same IP.");
return;
}
mService = serviceInfo;
int port = mService.getPort();
InetAddress host = mService.getHost();
}
protected void onPause() {
if (mNsdHelper != null) { mNsdHelper.tearDown();
}
super.onPause();
}
@Override
protected void onResume() {
super.onResume();
if (mNsdHelper != null) {
mNsdHelper.registerService(mConnection.getLocalPort()); mNsdHelper.discoverServices();
}
@Override
protected void onDestroy() {
mNsdHelper.tearDown();
mConnection.tearDown();
super.onDestroy();
}
public void tearDown() { mNsdManager.unregisterService(mRegistrationListener); mNsdManager.stopServiceDiscovery(mDiscoveryListener);
}
公文查詢功能可以查看公文的詳細內容和公文的審批過程。當一個教師使用 手機客戶端對公文進行處理后，信息反饋到服務器是，對這份公文的相關數據庫 的字段就會更新，另外一個用戶如果在更新后下載這份公文進行處理，就會得到 最新的公文審批信息。
圖 5-15 公文詳細情況
實現公文查詢的主要代碼如下：
i@Qv 亡 mckd
public void onReceive|(Context context, Intent intent) {心
String action = intent. getActionOs
if (WifiP2pManager.W7IFI_P2P_STATE_CHANGED_ACTION.equals(action)) 2
// Determine if Wifi Direct mode is enabled or not, alerts
// the Activity.a
int state = intent.getIntExtra(WifiP2pManager.EXTRA_XV7IFI_STATE, -1);^
if (state = WifiP2pManager AVTFI_P2P_STATE_ENABLED) {w activityr.setIsWifiP2pEnabled(true)；4J
} ehe {a
activity. setIsWifiP2pEnabled(false)屮
} else if(WifiP2pManager.\MFI_P2P_PEERS_CHANGED_ACTION.equals(action)) 2
// The peer list has changed! We should probably do something about^
// that>'
} else if(^4fiP2pManager.\KTIFI_P2P_CONNECTION_CHANGED_ACTION.equals(action)) {a
//' Connection state changed? We should probably do something about*-'
// that-d
} else if(^7ifiP2pManagerAKIFI_P2P_THIS_DE\rICE_CHANGED_ACTION.equals(action)) {a DeviceListFragment fragment = (DeviceListFragment) activity.getFragmentManagerO^-1
.findFragmentBvId(R. id.fragjist):^
fragment.updateThisDevice((WifiPlpDevice) intent. getParcelableExtra(*-'
WifiP2pManager.EXTRA_X\Tn_P2P_DE\lCE));p
5.2.6 附件下載模塊實現
本 Android 移動辦公系統暫時不提供在手機上編輯公文文件的功能，所以公 文以及公文的附件都需要上傳到服務器或者從服務端下載的操作。
在附件下載模塊，登錄用戶可以根據權限，下載其負責的項目的附件。解析 服務器發送的XML數據流中，得到附件下載列表和下載地址鏈接信息，移動客戶 端在顯示下載列表信息時，先根據項目分類，再根據可下載附件個數進行分頁。
進入到下載列表后，在這里登錄用戶可以對附件進行下載。當點擊“下載” 按鈕后，后臺線程便開始進行附件下載，此時下載按鈕被屏蔽無法點擊，而是顯 示文字“正在下載”。
在Android平臺中，對比較耗時的操作，一般推薦在新線程中進行，在附件下 載時，本文就是新建了多個下載線程進行多線程下載
客戶端實現的“下載管理器”是 DownloadManager 的一個實例， DownloadManager 的設計采用的是單例模式，即每個用戶登錄成功后只生成唯一 的一個“下載管理器”實例來維護當前賬戶下所有附件的下載。
這里以XML文件的上傳下載為例闡述這項應用的具體實現。
（1）Android 平臺文件的上傳
一個文件上傳的內容的實現，Android要實現文件上傳，可以利用Socket 上傳，也可以模擬 Web 進行上傳，但是如果是使用第一種方式上傳，嚴格的話就 得使用TCP，這樣容易生成系統死掉，或者是長時間等待，如果是UDP來傳，就 容易造成數據丟失，因此在這里選擇了 Web進行上傳，使用Web進行上傳是模擬 的Http Post上傳數據，當然，Post上傳數據的類，在網上找了一找，方式雖然很 多，但是沒有一個感覺是我所使用的，所以參照原理之類的，進行了一下修改， 算是做了一個參考。并且利用這個類完成了文件和表彰的上傳服務。
package com.UpLoadFileTest;
import java.io.BufferedReader;
import java.io.DataOutputStream;
import java.io.File;
import java.io.FileInputStream;
import java.io.IOException;
import java.io.InputStreamReader;
import java.io.InputStream;
import java.net.HttpURLConnection;
import java.net.URL;
import java.util.Map;
public class PostFile {
public static String post(String actionUrl, Map<String, String> params,
Map<String, File> files) throws IOException {
String BOUNDARY = java.util.UUID.randomUUID().toString();
String PREFIX = "--", LINEND = "\r\n";
String MULTIPART_FROM_DATA = "multipart/form-data";
String CHARSET = "UTF-8";
URL uri = new URL(actionUrl);
HttpURLConnection conn = (HttpURLConnection)
uri.openConnection();
conn.setReadTimeout(5 * 1000);
conn.setDoInput(true);
conn.setDoOutput(true);
conn.setUseCaches(false);
conn.setRequestMethod("POST");
conn.setRequestProperty("connection", "keep-alive"); conn.setRequestProperty("Charsert", "UTF-8");
conn.setRequestProperty("Content-Type", MULTIPART_FROM_DATA
+ ";boundary=" + BOUNDARY);
StringBuilder sb = new StringBuilder();
for (Map.Entry<String, String> entry : params.entrySet()) { sb.append(PREFIX);
sb.append(BOUNDARY);
sb.append(LINEND);
sb.append("Content-Disposition: form-data; name=\""
+ entry.getKey() + "\"" + LINEND);
sb.append("Content-Type: text/plain; charset=" + CHARSET + LINEND);
sb.append("Content-Transfer-Encoding: 8bit" + LINEND); sb.append(LINEND);
sb.append(entry.getValue());
sb.append(LINEND);
}
DataOutputStream outStream = new DataOutputStream(conn .getOutputStream());
outStream.write(sb.toString().getBytes());
if (files != null)
for (Map.Entry<String, File> file : files.entrySet()) { StringBuilder sb1 = new StringBuilder();
sb1.append(PREFIX);
sb1.append(BOUNDARY);
sb1.append(LINEND); sb1.append("Content-Disposition:form-data;name=\"file\";
filename=\""+ file.getKey() + "\"" + LINEND);
sb1.append("Content-Type:application/octet-stream;charset=" + CHARSET + LINEND);
sb1.append(LINEND);
outStream.write(sb1.toString().getBytes());
InputStream is = new FileInputStream(file.getValue());
byte[] buffer = new byte[1024];
int len = 0;
while ((len = is.read(buffer)) != -1) {
outStream.write(buffer, 0, len);
}
is.close();
outStream.write(LINEND.getBytes());
}
byte[] end_data = (PREFIX + BOUNDARY + PREFIX LINEND).getBytes();
outStream.write(end_data);
outStream.flush();
int res = conn.getResponseCode();
InputStream in = conn.getInputStream();
InputStreamReader isReader = new InputStreamReader(in);
BufferedReader bufReader = new BufferedReader(isReader);
String line = null;
String data = "OK";
while((line = bufReader.readLine())==null)
data += line;
if (res == 200) {
int ch;
StringBuilder sb2 = new StringBuilder();
while ((ch = in.read()) != -1) {
sb2.append((char) ch);
}
}
outStream.close();
conn.disconnect();
return in.toString();
}
}
2)Android 平臺文件的下載
要實現的是文件的下載，其實下載文件與打開網頁是一樣的，打開網頁是將
內容顯示出來，保存文件就是保存到文件中即可。
實現的代碼基本如下:
public void downFile(String url, String path, String fileName) throws IOException { if (fileName == null || fileName == "") this.FileName = url.substring(url.lastIndexOf("/") + 1); else this.FileName = fileName; // 取得文件 名，如果輸入新文件名，則使用新文件名 URL Url = new URL(url); URLConnection conn = Url.openConnection(); conn.connect(); InputStream is = conn.getInputStream(); this.fileSize = conn.getContentLength();// 根據響應獲取文件 大小 if (this.fileSize <= 0) { // 獲取內容長度為 0 throw new RuntimeException(”無 法獲知文件大小 "); } if (is == null) { // 沒有下載流 sendMsg(Down_ERROR); throw new RuntimeException("無法獲取文件”)；} FileOutputStream FOS = new FileOutputStream(path + this.FileName); // 創建寫入文件內存流，通過此流向目標 寫文件 byte buf[] = new byte[1024]； downLoadFilePosition = 0； int numread； while ((numread = is.read(buf)) != -1) { FOS.write(buf, 0, numread)； downLoadFilePosition += numread } try { is.close()； } catch (Exception ex) { ； } }
通過此代碼就可以實現將內容保存到SD卡等設備上，當然要使用網絡，必須 得有網絡的訪問權限。這個需要自己添加，在這里不再添加!
上面的代碼沒有實現進度條功能，如果要實現進度條功能，我現在考慮到的 就是使用消息進行發送提示，首先實現一個消息。
private Handler downloadHandler = new Handler() { // 用于接收消息，處理進度 條 @Override public void handleMessage(Message msg) { // 接收到的消息，并且對 接 收 到 的 消 息 進 行 處 理 if (!Thread.currentThread().isInterrupted()) { switch (msg.what) { case DOWN_START: pb.setMax(fileSize)； //設置開始長度 case DOWN_POSITION: pb.setProgress(downLoadFilePosition)； // 設置進度 break； case DOWN_COMPLETE: Toast.makeText(DownLoadFileTest.this, " 下 載 完 成 !", 1).show()； // 完 成 提 示 break； case Down_ERROR: String error =
msg.getData().getString("下載出錯!")； Toast.makeText(DownLoadFileTest.this, error, 1).show()； break； } } super.handleMessage(msg)； } }；
這樣，在下載的時候只要發送相應的消息，即可有相應的提示!
正文： 施方案 (233KB)
附件： 4|附件pdf (132KB) .附件txt (132KB) 附件xls (132KB)
m附件bmp
® (432 KB)
-附件jpg
一 (132KB)
,附件png
■ (132KB)
圖 5-18 附件下載列表截圖
5.2.7 自動更新模塊的具體實現
Android 系統自身并不會檢査系統已安裝應用程序的版本信息，也不會強制任 何應用升級或兼容，是用戶或應用自身對應用的版本有所限制。
Android 系統會自動在應用的 AndroidManifestxml 文件中的＜1113111(651＞標 簽中描述當前應用的版本信息(minSdkVersion特性指定)。這樣，應用程序就能 指定兼容的最低的系統 API。
1、版本信息的設定和獲得
本文開發時在程序的 AndroidManifestxml 文件中＜1113111651＞標簽中進行設 定了應用的版本信息。這里有兩個屬性，而且通常需要將兩個值都設定：
(1)android:versionCode 整型：表示應用程序的相對版本，就是版本實際更新 過多少次。整型便于同其它程序比較，檢查是應該升級或降級。開發者可以將這 個數值設定為任何需要的值，不過開發者需要保證后續的新版本要比這個值大。 系統雖然不會強制要求此行為，但是隨著版本升級數值也增加是正常行為。通常 開發者發布的原始版程序的versionCode設為1 ,之后每次發布都相應的增加，不 論發布的內容是大還是小。這就意味著android:versionCode并不像應用程序的發布 版本(android:versionName)那樣顯示給用戶，應用和發布的服務一般不需要顯示 這個值給用戶。
(2)androidiversionName 字符串值：表示應用程序版本信息，此信息是需要顯 示給用戶的。同android:versionCode一樣，應用不會為了任何內部的目的去調用這 個值，這個值僅僅是為了顯示給用戶。發布服務時也要提取該值來顯示給用戶。
本文先在 AndroidManifest.xml 文件中的 ＜1110111631＞ 標簽中定義了這兩 個版本的特性。本文依據android:versionCode的值可以知道出當前的apk是哪一版 本釋放的代碼， 根據 android:codeName 字符串內容得知當前的版本名是 “a20120923”。
Android系統的應用框架層提供一個API專門用來查詢應用的版本信息。為了 方便開發過程中獲得版本信息，本文專門編寫了 getAPKVersion( ) 函數來獲得版 本信息。
pg、工實 String getAPKVersionf ) {心
直= nullz+J
Padca^eManager pm =舉疋直蟲藝朝戛0*
Eg來 gggbjfe info = null;*-1
to和
mfo — p英:呂宴理來Bgf］殳;foC'qg藝bg刃"a
Paoka匪Nto昭旦-GET—ACTIVITIES)；斗
} catch 0£^£理@巫9理4£馥朋4慫 e) {“
IITODO Auto-generated catch block*-1
5血gS坦強企©f)*1
if (info ! = null) 2
= info:varsionName; a
H
appVersion;^
圖 5-19 版本信息獲取方法
通過圖5-12的方法Native客戶端就可以從AndroidManifest.xml文件中獲取安 裝到終端設備上的應用版本信息。本文將版本信息存放在 appVersion 字符串變量 中。版本號的獲取同理，本文在開發過程中沒有使用版本號，在此也就不做說明。
2、Android 系統版本設定
如果開發者的應用程序有最低Android API限制，又或者僅僅只是設計用于指 定版本范圍的 Android 平臺，那開發者就可以在應用的 AndroidManifest.xml 配置 文件中指定API的等級信息。這樣做是可以確保應用只會被安裝在使用有兼容的 Android系統的終端設備上。常用的Android系統配置屬性如下：
(1)android:minSdkVersion：應用能運行的最低版本的Android系統，通過 Android 平臺的 API 等級標識來指定。
(2)android:targetSdkVersion:可以指定應用運行需要的API等級。在某些情 況下，可以允許應用顯式的指定運行所需的 API 等級，而不是僅僅指定最低運行 所需的 API 等級。
⑶android:maxSdkVersion:應用可以運行需要的最高Android系統版本，通 過 Android 平臺的 API 等級標識來指定。
當準備安裝應用 apk 時，系統會自動檢查這個屬性的值同時與系統版本進行 比對。若 android:minSdkVersion 值大于系統版本，系統會自動放棄當前應用的安 裝。同樣，系統也有只在 androidmaxSdkVersion 與當前系統的版本相互兼容時才 會執行安裝。本文在 AndroidManifestxml 文件中只設置了 androidminSdkVersion 的值。
常用的數字簽名的功能是通過瀏覽器的Flash安全插件使用個人證書完成數簽 名功能的，本文開發的基于Android平臺數字化協同移動辦公信息管理系統中，必須 采用另一種最新的方式完成數宇簽名功能。
3、Android 客戶端最新版本信息的獲得、下載和安裝
客戶端創建并啟動一個新的線程checkUpdate，通過http協議從前置服務器上 獲取最新的移動客戶端的版本名，并存放在newVersion字符串變量中，與之前所 獲取的Native客戶端的版本信息變量appVersion比較判斷是否要進行新版本下載, 同時新版本的 url 也會被保存。
客戶端可以通過后臺的下載線程，使用 http 協議，獲取前置服務器上的最新 版本的 url 來下載最新 APK 安裝文件
客戶端可以通過installAPK()方法安裝并替換已有客戶端。本文通過定義自己 的 intent，通過它的 setDataAndType(Uri data, String type)方法，其中參數 type 和 data 分別為 APK 安裝文件的 Uri 和操作類型字符串，然后使用方法 startActivity(intent) 啟動早已定義的intent，系統便會根據APK的數字簽名信息自動匹配舊版本客戶 端，提示用戶替換更新，完成安裝。
5.2.8 Android 客戶端擴展功能
本節將會對Android平臺應用的一些擴展技術進行介紹，主要從兩方面進行介 紹:屏幕的適配和 strings.xml 文件。
1. 屏幕適配
顧名思義，屏幕適配就是為自己開發的應用支持不同終端的分辨率做出的基 本配置，準確的說是適配小、中、大三種密度，其中密度的大小是以dpi為單位區 分的，中密度標準是160dpi,如果大于此值的屏幕密度就為高密度，如果小于此 值的自然為低密度。android:anyDensity=''true"，這一句代碼對整個屏幕都起著非常 重要的作用，值為true,本文的應用在安裝于不同密度的移動終端上時，應用程序 會根據實際情況自動加載后綴名為 hdpi,mdpi,ldpi 的不同文件夾中的相應資源，主 要包括圖片資源、布局文件資源等。
此外，開發者還可以定義名為 layout、 layout-800x480、 layout-1024x600 的布 局文件夾，分別用來存放不同分辨率布局文件，對于具有不同分辨率手機屏幕， Android 系統可以自動加載對應布局文件，從而達到最好顯示效果。不過由于如今 Android 系統的手機設備五花八門，開發者應該編寫默認的通用的布局文件，以提 供非主流分辨率的屏幕使用，這些布局文件可以存放在 layout 文件夾下，顯示的 效果可能會有一定拉伸和壓縮的效果，但是不會影響使用功能。
2. string.xml 文件的使用
string.xml 文件在 Android 項目中 res/values 文件夾下，是專門用來存放字符串 和數值常量的。本文之所以特別強調要使用string.xml文件原因如下：
(1)可以減少應用程序占用空間，降低數據的冗余。
假設我們在應用中要使用“系統正在處理”這個字符串常量 10000 次，如果 本文不將“系統正在處理”定義在 strings.xml 文件中，而在每次使用時直接聲明 該字符串，這樣下來應用程序中將有60000余個字，這60000個字將會占116KB 的空間。而手機的資源十分有限，尤其 CPU 的處理能力和內存是非常有限的， 116KB 對于手機程序來說是一個不小的空間了，開發者在開發手機應用時一定要 牢記“能省內存就省”。如果將這個字符串在 strings.xml 中，在每次使用時通過 Resources類引用該字符串，僅僅占用了 11B而已，可見string.xml對降低應用的 體積效果是非常明顯的。
(2)為了更方便的是移動客戶端支持多國語言。
Android系統建議將在屏幕上顯示的文字都定義在strings.xml文件中，這樣如 果今后需要支持多國語言，如開發者開發的應用僅支持中文，未來開發人員希望 將自己的開發手機客戶端推向世界，需要支持更多的語種。開發人員為了更方便 的添加多國語言，就必須把使用 strings.xml 文件來定義客戶端軟件界面的語言， 否則每增加一種語言都會帶來相當大的工作量，這樣做非常有助于應用的國際化。
5.3移動客戶端與協同辦公系統數據交互實現
移動客戶端與協同辦公系統的數據交互是通過本文設計的前置服務器來進行 數據交互的，Android客戶端從前置服務器接收到XML數據流后，會調用SAX解 析器進行解析。在嵌入式環境中，尤其在Android平臺中，用SAX方式進行XML 數據流的解析并不用將整個XML文檔調入內存，從而減少了資源的使用，節省內 存，緩解操作系統運行的壓力。
5.3.1XML解析器的創建
在Android平臺中用SAX的方式進行XML數據流解析，先要構造處理對應 XML 數據流的 SAX 解析器，這要通過實現 ContentHandler 接口來實現， Android 應用程序開發的常用方法則是繼承DefaultHandler類。構造XML解析器的步驟如 下：
首先，先建立兩種實體類，分別對應XML文檔以及文檔的具體條目（后者需 為前者成員變量的類型），以便在解析XML的數據時，可以把解析出來的數據存 放到相應實體類中，這樣之后使用數據時就可以直接對實體類操作了。
然后創建一個自己的解析器類，繼承DefaultHandler類（DefaultHandler這個 類對 ContentHandler 類進行簡單的實現）。本文所需要做的就是針對接收到的不 同類型的XML數據流，重寫其中的幾個重要方法以滿足本文的業務需求。
5.3.2SAX方式的具體實現
SAX是Android系統官方推薦使用的XML文件解析方式，具體步驟如下：
1） 建立一個SAX的解析工廠類SAXParserFactory，代碼如下： SAXParserFactory factory = SAXParserFactory.newInstance（ ） ；
2） 讓新建立的工廠類Factory生成一個SAX解析類SAXParser實例，代碼如 下：
SAXParser parser = factory.newSAXParser( );
3)在解析類Parser中得到一個XMLReader的實例，代碼如下 XMLReader reader = parser. getXMLReader( )；
4)把自己寫的handler解析器(上一節介紹的內容)注冊到reader中，通常最 重要的就是 ContentHandler ,代碼如下：
reader. setContentHandler( handler )；
5)把一個從前置服務器發送來的 XML 數據流轉成 InputStream 流，正式開 始解析，代碼如下：
parser.parse ( is );
以上實現的幾個步驟中，最關鍵的就是第四步handler (解析器)的實現，該類 的具體實現在上一節中已做過詳細介紹。
5.3.3 XML數據交互實現
Android移動客戶端中的數據是來自于后端服務器，他們之間通過前置服務器 以XML數據格式來進行數據的交互。
1、 手機上的應用程序通過HTTP協議，將請求的URL發送到服務器端。實現代碼 如下：
St ring pa th = “ ” ； //服務器的Act ion的訪問路徑
URL url = new URL(path)； //打開連接，得到連接對象
HttpURLConnection conn = (HttpURLConnection) url.openConnection ();
//設置讀取的時間 conn.setReadTimeout (5*1000)； conn.setRequestMethod (“GET”)；
//從服務器輸入流中讀取數據
Inputstream inStream = conn.getlnputStream ()；
2、 服務器端就會調用對應Action來響應這個請求。因為WEB服務器默認的響應 信息是基于HTML格式的，就需要進行將信息構建為XML格式。這是聯系人的XML 文件格式代碼：
<%@ page language = “java” contentType二 “text/xml； charset二UTF- 8” pageEncoding = “UTF-8” %>
<%@ taglib uri = “http://java.sun.com/jsp/jstl/core” prefix = “c” %>
<?Xml version = “1.0” encoding= “UTF-8” ?> <EMP〉<c:forEach items= “$ {EMP}” var = “emp” >
<EMP id = “$ {EMP.id}” > <title>$ {EMP.id} </title>
<title〉$ {EMP.name} 〈/title〉
<title〉$ {EMP.dept} 〈/title〉
<title>$ {EMP.tel} 〈/title〉
</EMP〉</c:forEach〉
</EMP>
服務器端Action的響應代碼：
Public ActionForward execute(ActionMapping mapping,ActionForm fo rm,HttpServletRequest request,HttpServletResponse response) throws Exception {
//從數據庫獲取客戶端想查詢的信息
代碼省略
EMP Form formbean =(EMP Form) form；
request.setAttribute( “emps” , emps)；
return mapping.findForward( “emp” )；
}
3、 客戶端從來自服務器的輸入流中讀取XML數據。
Inputstream inStream = conn.getlnputStream ()；
4、 考慮到手機客戶端的硬件性能，使用SAX方式，邊讀取輸入流邊解析XML數據。
5、 將解析后的數據綁定到手機客戶端Activity中，在UI中顯示。
List<Video>videos = VideoService.getListEMP()；
List<HashMap<Sting, Object>>data = new ArrayList<HashMap<String, Object>>()；
For(EMP emp： emps) {
HashMap<String,Object>item = new HashMap<String,Object>()；
Item.put( “id” , emp.getid())；
Item.put( “name” , emp.getname())；
Item,put( “tel” , emp.getdept())；
Item,put (“tel” , emp.gettel())；
Data.add(item)；
}
SimpleAdapter adapter = new SimpleAdapter(this,data,R.layout.i tem,new String []{ “id” , “name” , “getdept” , “gettel” },new int []{R?id.name,R?id?gettel,R?id?getemail，R.id.getaddress})； ListView.setAdapter(adapter)；
5.4數據交互接口實現
根據數據交互接口的設計思路，為了方便起見，本文使用Web Service方式實 現了 Android移動平臺和原有的數字化協同管理系統的數據交互接口。
下面詳細介紹幾個協同管理系統的常用數據交互接口：
1. get_contract_by_num:根據相應的編號獲得協同管理系統中公文的基本信
息，支持批量操作，并可以根據fileds來限制返回的字段，減少不必要的通信。
表格 5-5 get_contract_by_num 接口
Request Direction 其他系統->Web Service
傳輸協議 http Get
格式 http://{web_server_ip}/web_service/get_contract_by_num?sessionId
={param}&contractNum={param}&fileds={param}
參數 sessionld:回話 ID
docNum :公文編號，可以多個編號
fields :請求字段
Response Direction Web Service-〉其他系統
傳輸協議 http+xml
返回數據 按照fields參數中要求的字段返回公文的基本信息
2.get_contract_by_status：根據公文的狀態獲取公文數據。如請求所有正在流 轉中的公文的信息
表格 5-6 get_contract_by_status 接口
Request Direction 其他系統->Web Service
傳輸協議 http Get
格式 http://{web_server_ip}/web_service/get_contract_by_status?sessionId
={param}&contractStatus={param}&fields={param}
參數 sessionld:回話 ID docStatus：公文狀態 fields :請求字段
Response Direction Web Service->其他系統
傳輸協議 http+xml
返回數據 按照fields參數中要求的字段返回要求狀態的公文
3. get_contract_by_begin_end:按照指定的時間范圍返回公文信息。該時間指 的是公文的流轉時間字段。為避免請求的時間范圍過長，公文數據量過大，默認
返回前10條，用戶可設置count參數來改變默認值。
表格 5-7 get_contract_by_begin_end 接口
Request Direction 其他系統->Web Service
傳輸協議 http Get
格式 http://{web_server_ip}/web_service/get_contract_by_begin_end?
sessionId={param}&beginDate={param}&endDate={param}
參數 sessionId:回話 ID beginDate :起始日期 endDate :結束日期 fields :請求字段 count：數量，非必填
Response Direction Web Service->其他系統
傳輸協議 http+xml
返回數據 返回指定時間范圍內的公文信息
4. set_contract_examine_info:系統可以根據此接口向協同辦公管理系統傳遞 公文流轉信息，同步公文流轉信息。
表格 5-8 set_contract_examine_info 接口
Request Direction 其他系統->Web Service
傳輸協議 http Post
格式 http://{web_server_ip}/web_service/set_contract_examine_info?sessionId
={param}&contractNum={param}&examine_info={param}
參數 sessionId:回話 ID
docNum :公文編號
examine_info :公文的流轉信息
Response Direction Web Service->其他系統
傳輸協議 http
返回數據 返回一個boolean型，是否更新成功
5.5 本章小結
本章介紹了各個功能模塊的具體實現及其效果截圖。主要包括移動辦公系統
相關模塊的實現、移動辦公子系統的具體實現以及系統MVC架構的實現。
第六章 系統測試
本章是對開發完畢的系統進行功能測試的的過程，根據軟件開發各階段的規 格說明和程序的內部結構，精心設計一批測試用例（即輸入數據及預期輸出結果）， 并利用這些測試用例去運行程序，以發現程序可能出現的錯誤。
6.1 功能測試
軟件測試對于一個軟件來說是非常重要的，如何以最小的人力成本以及最少 的資源投入，在盡可能短的時間內完成軟件測試工作，盡快發現軟件系統的BUG, 保證軟件優良的品質。。每個軟件產品或軟件開發項目都要有一套優秀的測試方 案和測試方法。而優秀的測試方案和測試方法可以在一定程度上保證開發出的軟 件保持較高的質量，這是每個軟件公司探索和追求的目標
設計測試用例的一個基本原則就是測試要盡量完全，而判斷一個測試是否完 全的主要評判方法是基于需求的覆蓋，通過下面我們設計的測試用例的測試，本 系統已基本完成測試目的。
1、測試點:公文的查詢
表格 6-1 公務查詢功能測試用例
測試步驟 步驟描述 預期結果
1 點擊公文查詢按鈕 進入公文查詢頁面
2 不填數據，直接提交，檢查是否對
必填字段進行了檢查 報錯，顯示公文查詢全部必填項，包括公
文類型、時間范圍等，至少填一項
3 檢查是否對Date數據進行了校驗
（實型）
1、 輸入正常的日期 2014-1-2
2、 輸入不正確的日期格式 1、 能夠正常輸入
2、 報錯，自動清除錯誤的日期格式
4 輸入公文名稱關鍵字，或整個公文
名稱 返回所有名稱中含有輸入字符的公文信息
5 選擇公文類別，并選擇時間范圍 進入公文查詢結果頁面，顯示在該時間范
圍內該類型的公文
2、測試點：待辦公文事項
表格 6-2 待辦公文測試用例
測試步驟 步驟描述 預期結果
1 登錄系統 登錄成功后，系統首頁顯示公文處理提醒、 處理進度提醒等
2 點擊公務處理提醒 顯示當前用戶的待處理公文
3 點擊公文進度提醒 顯示進度逾期的公文的基本信息，包括該 公文的名稱、編號以及負責人等等
4 點擊未讀消息 查看是否有人給自己發了新消息，點擊未 讀信息
5 查看待辦公文是否包含全部，即是 否包含登錄用戶的待處理公文、未 讀信息是否無遺漏 與當前登錄用戶的待辦信息一致，無任何 遺漏項。
3、測試點：審批管理的新建審批流程功能
表格 6-3 新建公文處理流程功能測試用例
測試步驟 步驟描述 預期結果
1 點擊公文處理流程 進入公文處理流程管理界面
2 選擇新建公文處理流程 進入新建公文處理流程的輸入錄入界面
3 直接提交，驗證必填字段 報錯，顯示所有必填字段，如名稱、公文 類型
4 添加所有必填項，選擇保存 保存成功，數據庫中多了一條審批流程
5 進入一個新建立的公文，選擇發起 處理 在公文處理流程的選擇列表中可以看到剛 才添加的公文處理流程
4、測試點：審批管理的發起審批功能
表格 6-4 發起審批功能測試用例
測試步驟 步驟描述 預期結果
1 選擇一個剛剛建立的公務，在公文 信息頁面選擇發起處理 公文進入待處理狀態
2 使用該公文的處理人賬戶登錄 在首頁的處理提醒中多了一個公文，即新 發起處理的公文
3 點擊新增加的公文 進入公文處理界面，顯示公文處理流程進 行到哪一步，以及前后處理人
5、測試點：系統設置
表格 6-5 系統設置測試用例
測試步驟 步驟描述 預期結果
1 以系統管理員身份登錄，計入系統 管理模塊 登入系統管理界面
2 選擇一個測試員工，點擊“修改信 息” 進入員工信息修改界面，包括名稱、密碼、 權限等可修改信息
3 點擊權限分配，測試權限分配 修改任意一個測試員工的權限
4 使用該員工賬號登陸 該員工的權限發生了相應的改變
5 點擊組織機構管理 進入組織機構管理界面，可以添加、修改 公司的組織結構
6 點擊字典管理 進入字典管理頁面，可以根據自己公司需 要自定義公文的類別、提醒類別等
6、測試點：移動客戶端的登錄
表格 6-7 Android 移動客戶端登錄功能測試用例
測試步驟 步驟描述 預期結果
1 在手機上點擊客戶端應用的圖標 進入協同移動辦公系統手機客戶端的登錄 界面
2 直接提交，檢測是否為必填 系統報錯，并提示“用戶名以及密碼為必 填字段”
3 檢測是否限制了字段輸入長度 在各輸入框中，輸入的內容達到所定義的 長度時，限制無法輸入。（如果輸入的為中 文字符，則控制到一半的長時就夠了）
4 輸入非允許的字符如'？ &等 系統自動刪除輸入的非法字符，并提示用 戶正確輸入
5 輸入正確的用戶名和密碼 登陸成功，進入應用主界面，顯示所有主 要的功能模塊
8、測試點：移動客戶端的公文文本下載功能
表格 6-8 公文文本下載測試用例
測試步驟 步驟描述 預期結果
1 點擊“公務呢信息查詢”圖表 進入公務信息查詢界面，等待輸入公務名 稱或編號
2 輸入要下載的公文名稱或編號 返回搜索結果，如果存在則可以下載
3 選擇要下載的公務，并點擊下載按 鈕。 界面跳轉到下載管理器，開始下載公文， 同時顯示下載歷史
4 下載到一半后斷網，之后重新連 接，并啟動未完成的下載任務，驗 證斷點傳輸功能 公文開始從上次下載的部分開始繼續下 載，下載完成后經過驗證正常。
9、測試點：移動客戶端自動更新
表格 6-9 移動客戶端自動更新測試用例
測試步驟 步驟描述 預期結果
1 在前置服務器上添加新的移動客 戶端版本 登陸后提示“有新版本，是否進行更新？ ”
2 選擇“否” 不進行更新，進入主界面
3 選擇“是” 彈岀下載管理器，自動開始下載，下載完 成后自動詢問是否安裝
4 選擇“是”，進行安裝 成功安裝，并自動重啟
5 測試新版本添加的新功能 新功能正常使用
6.2 測試結果
系統功能測試嚴格按照本章 7.1 節所描述的測試用例來進行，所有測試內容均 在預測結果范圍之內，基本上滿足了系統的功能性需求，系統已經比較成熟。
6.3 本章小結
本章簡要介紹了系統功能測試的測試用例，并闡述了測試結果。
第七章 總結與展望
基于 Android 平臺數字化協同移動辦公系統是企事業單位信息化建設的重要 組成部分，本文將數字化協同辦公系統轉換為一個可以與其他系統互動，并且覆 蓋了辦公系統整個生命周期的管理平臺，同時為今后的系統功能擴展奠定了基礎。
該系統的功能貫穿數字化協同辦公系統的整個生命周期，數字化協同辦公系 統的各個流程的所有的關鍵點都有相應的功能支撐。本數字化協同辦公系統的移 動辦公子系統成功上線，對移動辦公提供了強有力的支持，方便外岀的企事業員 工隨時隨地訪問協同辦公系統，給予企事業單位的工作人員以及領導極大的便利， 提高了企事業單位的整體辦公效率。
數字化協同辦公系統作為企事業單位信息化建設和管理的重要內容，它的成 功應用，對公司其他相關業務活動環節均起到了重要的基礎支撐作用，對后續業 務的順利開展以及相關系統的建設和接口實現有較大影響，尤其是移動辦公子系 統的成功上線，為今后開發支持公司全部管理信息系統的移動辦公平臺提供了堅 實的基礎。
致謝
在這里，我首先要感謝我的導師楊元杰老師。我在論文的創作過程中碰到許 多的困難和障礙，我得到了楊老師不厭其煩地幫助我進行論文的修改、指導我的 論文，我會銘記在心。他樸實無華、平易近人的人格魅力給了我深遠的影響，我 將終生難忘。
謝謝我的企業方導師儲久良高級工程師對我的學業傾注了大量的心血! 感謝研究生三年以來所以給我授過課的老師，你們不但教給我專業知識，更 是終身受益的為人處事之道。
最后，我要對參與論文評審和答辯的各位老師表示衷心地感謝，謝謝他們對 我學習成果進行認真的評估，我將在今后的工作學習中加倍努力。
參考文獻
[1] 中國互聯網信息中心.中國互聯網發展狀況報告(2014 年 3 月) http://www.cnnic.net.cn/hlwfzyj/hlwxzbg/hlwtjbg/201403/P020140305346585959798.pdf
[2] 2012-2016 年中國辦公協同軟件市場調研與投資前景評估報告 http://www.ibaogao.com/baogao/0305V2022012.html
⑶溫新.淺談高校辦公自動化系統的建設J].中國輕工教育2009年2期
[4]黃藝.淺談辦公自動化的實際應用J].中國電子商務.2010年.第5期.82-84.
[5]張元亮.Android開發應用實踐詳解[M].第一版.北京.中國鐵道岀版社.2011.3-10
[6]李紅.手機操作系統Android平臺的研究及應用[D].南京:東南大學,2010
[7].E2ECloud 工作室.深入淺岀 Google Android[M] .北京:人民郵電岀版社,2009
[8]余志龍.Google Android SDK開發范例大全[M].第三版.北京人民郵電岀版社.2011.4-15
[9]馮學軍.基于SSH框架的Web網站設計與實現[D].長春.長春理工大學.2010年.6-8.
[10]朱前飛，高芒.XML解析技術研究[J].電腦開發與應用,2004.11
[11]張超,王阿川，王智.基于J2ME和J2EE的手機軟件的研究J].黑龍江科技信息,2007(3):21,1
87
[12]宋杰.Android OS手機平臺的安全機制分析和應用研究[J].計算機技術與發展.2010年. 第 6 期.152-155.
[13]黨李成.基于Google Android智能手機平臺的研究與應用[D].合肥.安徽大學.2010年.7-9.
[14]李煒.Google Android開發入門指南[M].北京.人民郵電岀版社.2009.39-40.
[15]劉振波，方志剛，徐潔.改進的蟻群算法在智能導游系統路徑優化中的應用[J].江南大學學 報,2008(05):561-563
[16]趙世彧，張盛，王玉輝，白巖.智能手機操作系統及其Google Android上的軟件開發J].煤炭 技術, 2011,(04):197-199
[17]髙煥堂.UML嵌入式設計[M].北京.清華大學岀版社.2008.33-45.
[18]郭宏志.Android應用開發詳解[M].北京.電子工業岀版社.2010.30-33.
[19]王向輝，張國印，沈潔.Android應用程序開發[M].北京.清華大學岀版社.2010.21-27.
[20]Michael Blaha, James Rumbaugh著.車皓陽譯.UML面向對象建模與設計[M].北京.人民 郵電岀版社.2011.34-37.
[21]李曉.基于Android平臺的手持終端應用功能開發與設計[D].湖北:湖北大學,2010,72-98
[22]公磊，周聰.基于Android的移動終端應用程序開發與研究[J].計算機與現代化,2008,(08):85
[23]楊文志.Google Android程序設計指南[M].北京.電子工業岀版社.2009.5-10.
[24]宛延閭著.實用Java程序設計教程[M].北京.機械工業岀版社.2006. 3-30.
[25]陳國君.Java2程序設計基礎[M].北京.清華大學岀版社.2006.12-67.
[26]W Scott Means. The book of SAX: the simple API for XML [M]. San Francisco, Cali f: No Starch Press.2002.33-44.
[27]和凌志，郭世平.手機軟件平臺架構解析[M].北京.電子工業岀版社.2009.20-29.
[28]黨李成.基于Google Android智能手機平臺的研究與應用[D].合肥.安徽大學.2010 年.7-9.
[29]王路群.Java高級程序設計[M].北京.中國水利水電岀版社.2006.21-50.
[30]李瑞花.基Android的XML解析技術的分析[J].計算機時代.2010年.第12期.31-33.
[31]郭宏志.Android應用開發詳解[M].北京.電子工業岀版社.2010.30-33.
[32]康雁.軟件需求工程[M].第一版.北京.科技岀版社.2012.21-23.
[33]鄭莉.Java語言程序設計[M].北京.清華大學岀版社.2006.20-100.Calif: NoStarch
Press.2002.33-44.
[34]楊華.XML的編程接口 [J].西部廣播電視.2003年.第11期.44-47.
上一篇：供應鏈管理與經營性營運資金管理績效: 影響機理與實證檢驗
相關標簽:
