【正文】 Transport transport=new AndroidHttpTransport(serviceURL)。=true?！　〉诹剑赫{用WebService(其中參數(shù)為1：命名空間+方法名稱，2：Envelope對象)：(serviceNameSpace+getWeatherbyCityName, envelope)。　　第七步：解析返回數(shù)據(jù)：if(()!=null){ return parse(())。 }/************** * 解析XML * @param str * @return */ private static ListString parse(String str){ String temp。 ListString list=new ArrayListString()。 if(str!=null amp。amp。 ()0){ int start=(string)。 int end=(。)。 temp=(start, end3)。 String []test=(。)。 for(int i=0。i。i++){ if(i==0){ temp=test[i].substring(7)。 }else{ temp=test[i].substring(8)。 } int index=(,)。 ((0, index))。 } } return list。 }　　這樣就成功啦。那么現(xiàn)在我們就來測試下吧，這里有個地址提供webService天氣預報的服務的，我這里只提供獲取城市列表：//命名空間private static final String serviceNameSpace=。//請求URLprivate static final String serviceURL=。//調用方法(獲得支持的城市)private static final String getSupportCity=getSupportCity。//調用城市的方法(需要帶參數(shù))private static final String getWeatherbyCityName=getWeatherbyCityName。//調用省或者直轄市的方法(獲得支持的省份或直轄市)private static final String getSupportProvince=getSupportProvince?！　∪缓竽憧梢栽跒g覽器中輸入地址（WSDL）：serviceURL,你會看到一些可供調用的方法： 本章小結 本章的主要內容是Android平臺的體系結構分析。，包括Android平臺的簡介、Android的系統(tǒng)架構介紹、Android應用程序類型分析、Android活動的生命周期以及Android服務的生命周期的簡介。，包括Android用戶界面設計技術，XML解析技術，Android與服務器端的數(shù)據(jù)交互技術等。研究這些技術對于了解如何進行Android平臺的應用程序開發(fā)有極大的意義和價值，有利于將這些技術應用到實際工作中。第三章 系統(tǒng)分析與建模系統(tǒng)分析的主要任務是將在系統(tǒng)詳細調查中所得到的文檔資料集中到一起,對組織內部整體管理狀況和信息處理過程進行分析。本系統(tǒng)采用面向對象方法（OOA）對系統(tǒng)用戶的需求進行分析，采用UML統(tǒng)一建模語言表示。 系統(tǒng)可行性分析 可行性研究的前提 1）系統(tǒng)功能目標要求：本系統(tǒng)的設計目標是依托無線網(wǎng)絡，以使用Android系統(tǒng)的智能手機終端為載體，開發(fā)一個專為寧波大紅鷹學院制定的移動OA系統(tǒng)，通過實現(xiàn)移動平臺包括：個人信息、日程安排、信息審批、公告管理、學校論壇、學生管理、考勤管理、后臺管理等功能模塊。等辦公應用功能，有效地提高企業(yè)的日常工作效率。2）系統(tǒng)關聯(lián)性要求：實現(xiàn)本OA系統(tǒng)與企業(yè)其它系統(tǒng)有一定的連接，或附帶相關系統(tǒng)的基本功能。 系統(tǒng)設計原則本課題設計的系統(tǒng)是根據(jù)寧波大紅鷹學院的實際需求所開發(fā)的一個實用的基于Android平臺的OA系統(tǒng)，考慮到用戶的實際需求和學校規(guī)模， 在系統(tǒng)的設計過程中要注意遵循實用性原則、可行性原則和可擴展性原則。實用性原則要求系統(tǒng)的設計便于操作、維護和管理，能有效地通過無線網(wǎng)絡技術、數(shù)據(jù)庫技術和WEB技術實現(xiàn)對學院信息資源的合理利用，以便提高學校的辦公效率?？尚行栽瓌t要求系統(tǒng)設計要立足于現(xiàn)有的軟硬件技術，在現(xiàn)有的學校辦公應用系統(tǒng)的基礎上實現(xiàn)需求分析中描述的功能。可擴展性原則要求系統(tǒng)設計在實現(xiàn)當前需求的同時，充分考慮業(yè)務的擴展和系統(tǒng)擴容等因素，在系統(tǒng)設計、編碼實現(xiàn)時留有充分地余地。 需求分析需求分析是一項重要的工作，也是最困難的工作。一般情況下，需求分析的相關工作會被視作為一個獨立的工程，稱為需求工程。需求工程又分為需求開發(fā)和需求管理兩部分，如圖31所示：需求工程需求開發(fā)需求管理問題獲取分析編寫規(guī)格說明驗證圖31 需求工程示意圖需求開發(fā)有四個階段：分別是：問題獲取、分析、編寫規(guī)格說明和驗證。這些階段內的活動主要包括需求收集、需求評價、編寫文檔等。一般的需求開發(fā)活動包括下列內容:l 確定使用產(chǎn)品的用戶類別。l 獲取所有系統(tǒng)相關用戶的需求。l 了解各類型用戶的實際任務和預期目標，以及完成這些任務和目標所需要的業(yè)務需求。l 分析得到的用戶信息，從中提取出功能需求、非功能需求以及附加約束。l 將系統(tǒng)級的需求劃分為若干個子系統(tǒng)，再將需求的部份子系統(tǒng)分配給軟件組件。l 咨詢系統(tǒng)質量和屬性的相關信息，并對其做優(yōu)先級別的劃分。l 將所收集的用戶需求編寫成文檔并構建得到需求模型。l 對需求規(guī)格說明文檔進行評審，確保用戶和系統(tǒng)開發(fā)人員對需求的理解和認識達成一致。 需求分析對象 經(jīng)過調研，本系統(tǒng)面向的業(yè)務參與者：即Actor，在系統(tǒng)的具體業(yè)務當中扮演某個角色的人、分院或部門或者獨立的系統(tǒng)模塊等。包括:1) 用戶：用戶參與系統(tǒng)的主要成員，即接觸使用系統(tǒng)的所有者，也就是學校身份當中的教職工，是系統(tǒng)當中的一個超類；2) 系統(tǒng)管理員：系統(tǒng)管理員是系統(tǒng)的維護工作人員，擁有對系統(tǒng)目錄、角色、權限、用戶以及系統(tǒng)基礎數(shù)據(jù)管理的操作權限，同時也是用戶的一個子類；3) 領導：領導是指各個分院部門的主要管理人員以及上級領導的總稱；4) 人事處員工：人事處員工是人事處的成員，主要執(zhí)行對學校員工的工作進行考核和信息管理，但沒有刪除員工信息的權限；5) 人事處領導：人事處的主管，擁有人事處的各項操作權限，并能對無效員工信息進行刪除；：（一）系統(tǒng)管理員主要業(yè)務：1）A1：考勤設置：系統(tǒng)管理員設置日常上、下班考勤時間、休息日設置、請假類別等考勤信息；2）A2：公文流管理：是系統(tǒng)管理員對于日常用戶生成公文，如工作文件、請假單、銷假單等等的管理；3）A3：新聞公告管理：系統(tǒng)管理員用戶對在正常生產(chǎn)經(jīng)營當中，用戶提出的新聞公告進行發(fā)布、管理；（二）領導主要業(yè)務：1）考勤審批：每一個分院主管、領導能夠批準其下屬的請假申請；2）新聞公告審批：領導能夠審批下屬申請的新聞和通知信息，審批完之后傳給系統(tǒng)管理員發(fā)布；（三）人事處員工主要業(yè)務：1）員工管理：員工信息管理是對學校員工的信息進行管理、統(tǒng)計，具有增、改、查等功能；（四）人事處主管主要業(yè)務：1）刪除員工信息：指對員工信息出現(xiàn)異常的時候對該員工信息進行刪除；（五）用戶主要業(yè)務：1）登陸系統(tǒng)驗證：當用戶登陸系統(tǒng)的時候驗證用戶所提交的用戶名和密碼，以及所提交的數(shù)字證書的有效性。2）文件空間：用戶儲存用戶的文件資料；3）考勤簽到：根據(jù)學校規(guī)定和系統(tǒng)管理員設定的考勤管理時間，用戶在規(guī)定的時間內在系統(tǒng)報到；4）請銷假申請：用戶當遇上生病或特殊事情的時候可以向上級領導或者主管提出請假申請；而當假期尚未完，則可以申請銷假。5）加班登記：當在非工作時間內上班的時候，用戶需要向人事部門填寫加班登記表；6）聯(lián)系人管理：用戶對其它同事、相關業(yè)務聯(lián)系人、家人信息的登記；7）管理用戶日志：用戶將日常工作信息記錄下來以便檢查；8）瀏覽公文流：用戶可以隨時查看公文流信息；9）瀏覽員工信息：每位用戶可以對在職的所有員工的信息表中瀏覽信息；10）用車使用申請：用戶當需要使用學校公車的時候可以向學校辦公室申請使用；11）因公出差管理：用戶在出差的時候向登記該信息，以上報上級領導；12）短信平臺：用戶可以向學校內的各個員工發(fā)送短信信息（主管領導除外）；14）郵件平臺：用戶可以向學校內的各個員工發(fā)送郵件信息（主管領導除外）；圖32 學校組織結構圖學校有集團董事會和理事會領導，其下屬有多個分院和部門，包括人事處，學校辦公室，信息工程學院，機械與電氣工程學院、藝術與傳媒學院、人文學院、基礎學院、高職學院、網(wǎng)絡中心、圖書館部門等；而每個分院和部門都有一個主管；并且每個分院和部門是由多個員工共同組成。這些也是最終實際使用的部門，這些部門間不存在從屬關系，都是平行的部門，由平行部門參與。 系統(tǒng)審批流程1）員工請假流程圖33 員工請假流程員工領取請假單，并按要求填入相關的請假事項，然后把請假單提交給系統(tǒng)；系統(tǒng)會根據(jù)員工所在的分院或部門，把請假單發(fā)送到各自的主管領導的“待辦文件”中；主管領導對其審閱后，對其作出必要的審批結果，并把結果返回給該員工；最后系統(tǒng)記錄其請假信息，并形成文檔。2）員工銷假流程圖34 員工銷假流程員工領取銷假單，并按要求填入相關的銷假事項，然后把銷假單提交給系統(tǒng)；系統(tǒng)會根據(jù)員所在的分院或部門，把銷假單發(fā)送到各自的主管領導的“待辦文件”中；主管領導對其審閱后，對其作出必要審批結果，并把結果返回給該員工；最后系統(tǒng)記錄其銷假信息，并形成文檔。3）信息發(fā)布流程圖35 信息發(fā)布流程申請人領取信息發(fā)布單，并按要求填入相關的信息內容，然后把信息發(fā)布單提交給系統(tǒng)；系統(tǒng)會根據(jù)員工所在的分院或部門，把該單發(fā)送到各自的分院或部門的“待辦文件”中；主管領導對其審閱后，對其作出必要的審批結果，并提交給學校辦公室審查；學校辦公室對信息進行審查后，對其作出相應審查結果，把信息傳給系統(tǒng)管理員確認，最后把結果返回給該申請人；最后系統(tǒng)記錄其信息，并形成文檔。4）公車用車使用申請流程申請人領取車輛使用申請單，填寫相關的信息后，把申請單提交給學校辦公室辦理；學校辦公室相關人員對申請人提交的信息進行審查，審查結束后把申請單提交給主管領導審批；最后，當主管領導審批結束之后，把申請單記錄到系統(tǒng)當中，形成文檔，并把審批結果返回給申請人。圖36公車用車使用申請流程為了對本系統(tǒng)的功能需求進行更為直觀的描述，下面使用UML（統(tǒng)一建模語言）工具來給出系統(tǒng)完整的用例分析圖。本系統(tǒng)有兩類參與角色：教職工與領導，如圖32所示。需要強調是，這里的員工角色可以根據(jù)權限級別的設置，可以充當多種身份，如一般教職員工，系統(tǒng)管理員等，領導角色也一樣，根據(jù)權限的設置，可以充當中層領導，高層領導等身份。教職工領導圖32 系統(tǒng)參與者用例圖兩種角色在系統(tǒng)頂層用例圖中能使用的功能組件基本一致，只是部分組件中領導角色能使用的功能不允許給員工角色使用，系統(tǒng)頂層用例圖如圖33所示。教職工領導公文管理郵件管理工作流管理通訊錄管理系統(tǒng)管理圖33 系統(tǒng)頂層用例圖 在公文管理功能模塊中，教職工角色與領導角色使用的功能基本一致，均是“公文的接收與發(fā)送”、“待辦公文處理”、“已辦公文處理”、“緊急待辦公文處理”四個功能模塊。這個模塊中，要求公文信息進行訪問級別控制，公文訪問級別允許范圍內的員工和領導角色才可以操作該公文，公文管理用例圖34所示。領導教職工公文的接收/發(fā)送待辦公文處理已辦公文處理緊急待辦公文處理圖34公文管理用例圖郵件管理功能模塊與公文管理模塊相似，也要求對郵件也要設置訪問級別，以確定可以操作該郵件的角色。郵件管理的用例圖如圖35所示。教職工領導郵件的接收/發(fā)送郵件閱讀郵件附件處理圖35 郵件管理用例圖工作流管理模塊中兩種角色的涉及的功能模塊不相同，領導角色比教職工角色多了工作擬定、領導批閱兩項功能。工作流管理的用例圖如圖36所示。教職工領導發(fā)布通知工作申請公文審批申請工作流管理模塊工作擬定圖36 工作流管理的用例圖通訊錄管理功能比較單一，兩種角色均可以不做限制地查詢人員的信息。通訊錄管理的用例圖如圖37所示。教職工領導查詢人員信息圖37 通訊錄管理的用例圖系統(tǒng)管理與工作流管理模塊一樣，使用同一接口，根據(jù)兩種角色允許使用的功能進行劃分，領導角色比教職工角色多了教職工用戶帳戶權限的控制功能。系統(tǒng)管理的用例圖如圖38所示。教職工領導系統(tǒng)管理登錄/注銷帳號維護員工用戶的權限控制圖38 系統(tǒng)管理的用例圖 本系統(tǒng)的非功能性需求如下：l 整體要求系統(tǒng)界面要求簡潔，布局合理，風格同一，易用。系統(tǒng)可以容納50100用戶同時在線辦公。網(wǎng)絡平均響應時間控制在5