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