【正文】 確地對(duì)系統(tǒng) 文件 進(jìn)行配置 ， 并由其來統(tǒng)籌 Struts 框架應(yīng)用 系統(tǒng)中各種功能邏輯的協(xié)作 ， 從而保證應(yīng)用系統(tǒng)的順利運(yùn)行 。 Spring 框架 Spring[8]技術(shù) 框架是 另外 一個(gè) 主流的基于 J2EE 的 開源框架， 這個(gè)開發(fā)框架是由 Rod Johnson 發(fā)明的，旨在降低在大多數(shù) 企業(yè) 解決方案 開發(fā)的復(fù)雜性。 Spring 技術(shù) 框架 中運(yùn)用簡(jiǎn)單 的 JavaBean 代替了以往主要由 EJB 來搭建的應(yīng)用 。 但是 ， Spring技術(shù) 框架的用途不 只局限 于服務(wù)器端 應(yīng)用程序的設(shè)計(jì)與開發(fā)工作 。 在應(yīng)用系統(tǒng)的瀏覽器 Jsp Action Servlet JavaBean（ EJB） Action Strutsconfig.xml 轉(zhuǎn)發(fā) get 分發(fā) 更新 事件 18 簡(jiǎn)單性、低耦合性和高實(shí)用性等方 面來講 ， 大多數(shù)的 java 應(yīng)用程序都可以利用Spring 技術(shù) 框架 的優(yōu)勢(shì) 。 Spring 技術(shù) 框架是 一種輕量級(jí)的程序開發(fā)框架，主要的特點(diǎn)是以 依賴注入原則 以及面向 方面 的程序設(shè)計(jì)思 想。 在這種特征下， Spring 技術(shù) 框架 是一個(gè)依賴注入的容易，同時(shí)又是一個(gè)基于面向方面編程方式的程序開發(fā)框架 。運(yùn)用 面向方面的編程 思想 能夠 創(chuàng)建 “ 橫切關(guān)注點(diǎn) ” ， 同時(shí)在實(shí)際應(yīng)用中將其嵌入程序代碼中 ， 保證程序代碼的高度可重用性 。 依賴注入 容器 使得應(yīng)用系統(tǒng)在需要插入代碼的地方創(chuàng)建一個(gè)環(huán)境 ， 而后將插入的對(duì)象傳遞給需要使用他們的對(duì)象 。 這種方式能夠方便對(duì)完成業(yè)務(wù) 對(duì)象的更替 ， 只要在相應(yīng)的部件和配置文件中標(biāo)識(shí)依賴注入屬性 ，就 能夠非常 容易 地 在需要時(shí) 對(duì)類似接口的實(shí)例對(duì)象完成替代 。 Spring 技術(shù) 框架 是一個(gè)輕量級(jí)的程序開發(fā)框架 ， 主要包括 7 個(gè)組成部分 。 每個(gè)組成部分能夠單獨(dú)地運(yùn)行 ， 同時(shí)能夠以多模塊組合完成系統(tǒng)功能 ， 這個(gè)系統(tǒng)的核心是部件工廠 ， 用以構(gòu)建程序開發(fā)所需的模型 。 Spring 技術(shù) 框架 同時(shí) 提供了和 集成了依賴注入容器的程序開發(fā) 框架。 Spring 技術(shù) 框架的體系 架構(gòu) 如圖 24 所示。 圖 24 Spring 體系結(jié)構(gòu)圖 由 Spring 技術(shù) 框架 的 設(shè)計(jì)理念 可知 ， 該 框架 能夠?yàn)槲覀?實(shí)現(xiàn) 真正意義上 的 功能 邏輯層 與 網(wǎng)絡(luò)層 相互獨(dú)立 。 Spring 技術(shù) 框架 是基于核心容器上的 ，而核心容器 同時(shí) 定義了創(chuàng)建、配置 以及 管理 程序部件 的 方法 。 Spring 技術(shù) 框架 以 Java Bean 代替重量級(jí)技術(shù)框架中 EJB 的作用 ， 較大程度上降低了事務(wù)處理方面的復(fù)雜性 。 Spring ORM Spring Web Spring Context Spring DAO Spring AOP Spring Web MVC Spring CORE 19 本章小結(jié) J2EE 對(duì)企業(yè)級(jí)的應(yīng)用提供了完美的支持，使用 EJB 構(gòu)建強(qiáng)大的企業(yè)級(jí)應(yīng)用 ，具備了較強(qiáng)的開放性以及兼容性 ， 能夠全面地支持現(xiàn)有的應(yīng)用程序 ， 程序開發(fā)的復(fù)雜度得到較大程度降低 。 由于其具備了較強(qiáng)的系 統(tǒng)兼容性、開發(fā)的經(jīng)濟(jì)性、平臺(tái)的開放性以及安全性能， J2EE 成為當(dāng)今應(yīng)用程序開發(fā)中的一個(gè)重要技術(shù)平臺(tái)。 在政務(wù)督查系統(tǒng)的開發(fā)中，我們決定采用基于 J2EE 平臺(tái)的 Struts+ Spring 架構(gòu)。 20 第 三 章 需求分析 需求獲取 在 一個(gè)全面 、 完善的軟件工程 需求 中，第一個(gè) 而且是非常 重要 的 步驟 就 是需求的 獲取 。 需求獲取 旨在 在系統(tǒng)用戶提出的問題和問題的解決方案之間實(shí)施匹配控制 中 必須考慮和實(shí)施的一個(gè) 重要 步驟，是 在 整個(gè)軟件系統(tǒng)的開發(fā)過程中 尤為關(guān)鍵、最為困難、 也是 最容易出錯(cuò)以及最需要進(jìn)行充分 的調(diào)研、溝通和 交流的重要工作 。軟件系統(tǒng)的需求獲取工作 必須 注重系統(tǒng) 的 使用者和系統(tǒng) 的 開發(fā)者 之間進(jìn)行 充分密切的合作，只有 如此 才能保證系統(tǒng) 設(shè)計(jì)和 建設(shè)的成功。系統(tǒng) 的 需求分析者需要營(yíng)造一個(gè)對(duì)解決的問題實(shí)施全面 并且 完善的探討環(huán)境， 應(yīng)用 系統(tǒng)需要解決的 所有 問題和 必須和 軟件產(chǎn)品有關(guān)。需求 的 獲取 工作是一項(xiàng) 對(duì) 要求全面 而且 高效進(jìn)行合作的活動(dòng)， 它 并不等同于對(duì)系統(tǒng)用戶所描述各種需求的簡(jiǎn)單 的 記錄。對(duì)于一個(gè)系統(tǒng)需求分析人員 來說 ，需 求 在系統(tǒng)各類 的 用戶所提出的淺顯的、簡(jiǎn)單的 各種 系統(tǒng)需求的基礎(chǔ)上， 認(rèn)真 分析和獲取 到 這些用戶的真正 的 需求 ，并且要 詳細(xì)了解一個(gè)對(duì)系統(tǒng)需求的可擴(kuò)充問題 ， 將有利于更 加 全面 的 理解系統(tǒng) 的 使用者目前的工作業(yè)務(wù)流程 和其 特點(diǎn)， 也 能夠獲知建設(shè)的軟件 應(yīng)用 系統(tǒng)可以 用 何種方式幫助 改進(jìn)他們的實(shí)際 工作 [9]。獲取 較為 全面的系統(tǒng)使用者的需求必須要實(shí)施的工作有： (1)通過 調(diào)查 獲得系統(tǒng) 的 各類用戶 在 所有的系統(tǒng)用戶類型以及所有 的 潛在用戶的 類型。同時(shí)，根據(jù)應(yīng)用系統(tǒng)的各類用戶對(duì) 該 應(yīng)用系統(tǒng)的 需求 作 出 分析 ，并 確定督查 系統(tǒng)的整體 設(shè)計(jì) 目標(biāo)和該 督查 系統(tǒng)的應(yīng)用范圍。 (2)對(duì) 政務(wù)督查 系統(tǒng)的各 類 用戶 進(jìn)行 行詳細(xì)的訪談 、 調(diào)研。在獲取 需求的 這個(gè)步驟中，主要的 是 與用戶的交流方法 ，其中 包括： 召開 系統(tǒng)需求會(huì)議、 通過 電話聯(lián)系、 進(jìn)行 EMAIL 交流、客戶與研發(fā)組 之間進(jìn)行 交流討論、對(duì) 政務(wù)督查 系統(tǒng)的預(yù)期功能進(jìn)行模擬等形式。在 此 過程中， 要 盡量保證每一次同 政務(wù)督查 系統(tǒng) 的 各類用戶 之間的 調(diào)研和交流都 保存下 詳細(xì)的記錄，而且根據(jù)調(diào)研獲得的結(jié)果進(jìn)行需求的 詳細(xì) 分類，以便于 系統(tǒng)的 需求分析工作中翔實(shí)的 資料 基礎(chǔ)。 比 如， 我們 將需求細(xì)分為 督查 系統(tǒng)的功能需求、非功能需求（如系統(tǒng)的用戶同時(shí) 鏈接 數(shù)、 系統(tǒng) 的響應(yīng) 時(shí)間、 系統(tǒng) 穩(wěn)定運(yùn)行時(shí)間、 系統(tǒng) 故障自動(dòng)恢復(fù)等）、運(yùn)行環(huán)境設(shè)計(jì)等。 21 (3)將通過 調(diào)研 和交流 所 得到的 各類 系統(tǒng)用戶的 實(shí)際 需求進(jìn)行 進(jìn)一步的分析和整理。在 此 過程中 ， 我們 主要根據(jù)以下原則 進(jìn)行 處理：將系統(tǒng)用戶所提出的 任何一 個(gè) 需求點(diǎn)都 要 做到知其 所以然 ，同時(shí)判斷 出 系統(tǒng)用戶所提出的需求是 否 有 實(shí)際的 事實(shí) 依據(jù) 。 然后 將 督查 系統(tǒng)的各類用戶描述的問題中諸如 “用 哪 種方法實(shí)現(xiàn) ”等 描述方法更 換 為 “督查 系統(tǒng)需要實(shí)現(xiàn) 哪 種功能 ”， 因?yàn)樵?督查應(yīng)用 系統(tǒng)的需求分析階段 ，我們 首先 注意的問題是 督查 系統(tǒng) 究竟 需要 “做何種工作 ”，而不是 “用 何種方法來 實(shí)現(xiàn) ”。 在濱海開發(fā)區(qū) 政務(wù)督查系統(tǒng) 的需求分析工作中，我們采用了 UML 語言 對(duì)系統(tǒng)進(jìn)行 建模，在對(duì) 督查 系統(tǒng)的各類用戶的 需求調(diào)查的基礎(chǔ)上設(shè)計(jì) 了 功能用例圖， 然后 ，與系統(tǒng)的各類用戶 一起 來 確認(rèn) 督查 系統(tǒng) 的 需求分析得 出 的結(jié)果是 否 能夠真實(shí) 、全面 、客觀的 反映 所有 系統(tǒng)用戶的 實(shí)際工作 要求。在 需求分析 階段中 我們 主要 進(jìn)行下列的 活動(dòng)： 一是 明確標(biāo)識(shí)出 哪些是尚 未確定的需求 事 項(xiàng)。 二是要 保證需求 分析 符合 本 系統(tǒng) 設(shè)計(jì) 的整體目標(biāo)。 三是要 保證需求項(xiàng)之間 必須存在 一致性，解決 好各種 需求項(xiàng)之間存在的 潛在 沖突。 業(yè)務(wù)需求分析 為了達(dá)到濱海開發(fā)區(qū)在 對(duì) 政務(wù)督查工作 管理 方面提高工作效率和信息化應(yīng)用的需求，建立和使用濱海開發(fā)區(qū) 政務(wù)督查 系統(tǒng)是 一個(gè)必然的舉措。濱海開發(fā)區(qū) 政務(wù)督查 系統(tǒng)的設(shè)計(jì)與開發(fā)應(yīng)當(dāng)汲取兄弟部門的相關(guān)土地管理 信息化項(xiàng)目的優(yōu)點(diǎn)和長(zhǎng)處，并且 充分 地重視這些系統(tǒng)在實(shí)際應(yīng)用 過程中 存在和暴露出 的 各種 問題。 經(jīng)過與 濱海開發(fā)區(qū) 的 各類 主要 的用戶的交流和研討 ， 并且分析了 對(duì) 濱海開發(fā)區(qū) 政務(wù)督查 業(yè)務(wù) 流程的 調(diào)查和 研究 的結(jié)果 ，對(duì) 目前 政務(wù)督查 工作 中的 各種存在的問題進(jìn)行調(diào)研， 最后在這些工作的基礎(chǔ)上執(zhí)行 詳細(xì) 的需求分析，對(duì)系統(tǒng)的主要 功能 需求 定義為 如下 所示 幾條 ： 1） 立項(xiàng) 管理，完成日常事務(wù)、突發(fā)事務(wù)的登記，執(zhí)行登記或 刪除的功能，添加 日常事務(wù)和突發(fā)事務(wù)的信息，事務(wù)信息主要包括事務(wù)部門，執(zhí)行人，督辦人，事務(wù)級(jí)別，開始時(shí)間，結(jié)束時(shí)間，事務(wù)內(nèi)容，事務(wù)類別等 。通過此模塊完可以完成事務(wù)的添加功能，對(duì)已添加的事物進(jìn)行執(zhí)行，或?qū)o效的事務(wù)進(jìn)行刪除。 2） 督查反饋管理 ， 任務(wù)執(zhí)行部門對(duì)于督查部門分配的任務(wù)執(zhí)行完成后，通 22 過系統(tǒng)對(duì)完成情況進(jìn)行反饋，督查部門進(jìn)行時(shí)審核后，決定是否符合要求，不符合要求的，反饋回原單位進(jìn)行重新執(zhí)行。 3） 督查協(xié)調(diào)管理 ， 由督查部門主動(dòng)或者應(yīng)執(zhí)行部門申請(qǐng)后 ， 對(duì)某一督查事項(xiàng)進(jìn)行詳細(xì)分工，由多個(gè)部門協(xié)調(diào)完成某一事項(xiàng) 。 4） 事務(wù)跟蹤管理，在事務(wù)的執(zhí)行過程中，完成事務(wù)跟蹤信息的添加， 事務(wù)跟蹤的信息包括事務(wù) ，錄入時(shí)間，執(zhí)行人，督辦人，進(jìn)展情況，備注等。 5） 事務(wù)備案管理，完成企業(yè)事務(wù)的備案歸檔的功能，可以執(zhí)行完畢的事務(wù) 備案的信息，事務(wù)備案的信息包括事務(wù)編號(hào)，發(fā)生時(shí)間，結(jié)束時(shí)間，事務(wù)內(nèi)容， 經(jīng)辦部門，負(fù)責(zé)人，督辦人，事務(wù)級(jí)別，事務(wù)類型，備注等信息。 6） 公文管理 ，完成企業(yè)公文信息的管理功能，包括公文信息的新增， 公文信息的刪除等，公文的信息主要有公文名稱，負(fù)責(zé)人，督辦人，審核情況， 審核時(shí)間，處理情況等。 7） 用戶管理，完成系統(tǒng)使用用戶的添加或刪除的功能。 本系統(tǒng)的主要用戶包括：開發(fā)區(qū)部門的業(yè)務(wù)人員 、 開發(fā)區(qū)部門的 各級(jí) 領(lǐng)導(dǎo) 、系統(tǒng)管理員 對(duì)于開發(fā)區(qū) 部 門的 業(yè)務(wù)人員，系統(tǒng)需要提供的功能用例圖如圖 31 所示 。 工 作 人 員數(shù) 據(jù) 輸 入數(shù) 據(jù) 編 輯數(shù) 據(jù) 刪 除數(shù) 據(jù) 查 詢報(bào) 表 統(tǒng) 計(jì)用 戶 提 醒 u s e s u s e s u s e s u s e s u s e s u s e s 圖 31 系統(tǒng)功能用例圖 (業(yè)務(wù)人員 ) 23 對(duì)于 開發(fā)區(qū) 部門 的各級(jí) 領(lǐng)導(dǎo)用戶，系統(tǒng)需要提供的功能用例圖如圖 32 所示 。 領(lǐng) 導(dǎo) 用 戶數(shù) 據(jù) 查 詢統(tǒng) 計(jì) 分 析報(bào) 表 輸 出數(shù) 據(jù) 瀏 覽 u s e s u s e s u s e s u s e s 圖 32 系統(tǒng)功能用例圖（ 部門 領(lǐng)導(dǎo)） 對(duì)于系統(tǒng)管理員用戶，系統(tǒng)需要提供的功能用例圖如圖 33 所示 。 系 統(tǒng) 管 理 員 用 戶添 加 用 戶編 輯 用 戶刪 除 用 戶權(quán) 限 管 理數(shù) 據(jù) 庫 備 份數(shù) 據(jù) 恢 復(fù)日 志 管 理 u s e s u s e s u s e s u s e s u s e s u s e s u s e s 元 數(shù) 據(jù) 管 理 u s e s 圖 33 系統(tǒng)功能用例圖（系統(tǒng)管理員） 24 系統(tǒng)性能需求 所謂 的 非功能性需求，是指 最終 產(chǎn)品 在 滿足用戶 的 業(yè)務(wù)需求 之外 必須具有 的特性 ，它 包括系統(tǒng)的性能、可靠性、可維護(hù)性、可擴(kuò)充性和對(duì) 技術(shù) 和對(duì)業(yè)務(wù)的適應(yīng)性等。非功能性需求必須考慮軟件既要可用，又要易用。 對(duì)于非功能性需求描述的困難在于很難像功能性需求那樣，可以通過結(jié)構(gòu)化和量化的詞語來描述清楚，在描述這類需求時(shí)候我們經(jīng)常采用軟件性能要好，查詢要在多少時(shí)間內(nèi)出結(jié)果，軟件健壯性要好等較模糊的描述詞語。這類描述詞語都是脫離了軟件的執(zhí) 行環(huán)境，人和相關(guān)的場(chǎng)景的描述，因此信息很難體現(xiàn)到軟件架構(gòu)設(shè)計(jì)和具體的實(shí)現(xiàn)中。我們?cè)诩軜?gòu)設(shè)計(jì)中關(guān)注的安全，系統(tǒng)開發(fā)框架，并發(fā)和性能，異常 日志 等不是憑空產(chǎn)生出來的，而是來源于我們對(duì)非功能性需求的分析。 一個(gè)軟件系統(tǒng)必須完整，因此不僅僅包括了可執(zhí)行的程序，還包括了在線幫助，數(shù)據(jù)和用戶管理，日志異常查詢，自動(dòng)升級(jí)等相關(guān)功能特征。這些需求不僅僅是為了滿足用戶的需要，也是為了我們后續(xù)維護(hù)和監(jiān)控系統(tǒng)的需要。 系統(tǒng)的可靠性，可維護(hù)性和適 應(yīng)性是密不可分的。當(dāng)系統(tǒng)出現(xiàn)故障和用戶出現(xiàn)錯(cuò)誤的操作后是否支持恢復(fù)，當(dāng)用戶在使用過程中遇到錯(cuò)誤的時(shí)候是否可以立即定位問題，但業(yè)務(wù)場(chǎng)景和邏輯發(fā)生變化的時(shí)候系統(tǒng)是否支持，當(dāng)網(wǎng)絡(luò)不穩(wěn)定或使用中異常中斷的情況下系統(tǒng)是否都有相應(yīng)的容錯(cuò)措施，這些都是需要在非功能性需求中考慮到的問題。 易用性也是我們?cè)陂_發(fā)非功能性需求中必須要考慮到的問題，易用性同時(shí)還涉及到美工和 UI 界面，人機(jī)工程，交互式設(shè)計(jì)，心理學(xué)，用戶行為模式等多方面的知識(shí)。易用性的三原則就是易見，易學(xué)和易用或者叫為發(fā)現(xiàn)，易懂，效率。易見就是各種功能操作不要藏得 太深，用戶很容易找到他們期望進(jìn)行的各種操作；易學(xué)需要軟件系統(tǒng)通過在線幫助，導(dǎo)航，向?qū)У雀鞣N方式保證軟件是可自 學(xué)習(xí) 的；易用的重點(diǎn)則在軟件在熟練使用后應(yīng)該可以更快的進(jìn)行各項(xiàng)操作。這三者相互間也存在沖突，需要平衡，而平衡的一個(gè)重點(diǎn)就是真正的做到以用戶為中心進(jìn)行設(shè)計(jì)，需要去細(xì)分場(chǎng)景和用戶。 對(duì)于非功能性需求的描述，在描述過程中必須要強(qiáng)調(diào)到人，業(yè)務(wù)場(chǎng)景，環(huán)境等各方面的內(nèi)容。強(qiáng)調(diào)的目的就是要說明非功能性需求不是無限度的，任何一項(xiàng)非