基于SSH架構的廣電發射傳輸中心信息管理系統設計與實現

發布時間：2023-08-13 10:15

第一章緒論 1

1.1課題研究背景、目的和意義 1

1.2課題研究的目標及內容 2

1.3國內外研究現狀 3

1.4論文的結構 4

第二章系統的相關技術概述 6

2.1項目開發的工具 6

2.2關鍵技術概述 6

2.2.1JSP 和 JavaScript 6

2.2.2JSON 對象 7

2.2.3Kendo UI 的簡介 9

2.3本章小結 12

第三章廣電發射傳輸中心信息管理系統的開發環境 13

3.1系統概述 13

3.2系統運行環境 13

3.3系統架構描述 16

3.3.1MVC三層架構描述 18

3.3.2SSH 框架介紹 19

3.4軟件結構描述 23

3.5本章小結 25

第四章廣電發射傳輸中心信息管理系統的需求分析 26

4.1系統需求分析 26

4.1.1用戶需求分析 26

4.1.2系統功能需求 26

4.2系統非功能性需求 29

4.3本章小結 29

第五章廣電發射傳輸中心信息管理系統的詳細設計 30

5.1界面構思 30

5.2系統總體構架設計 32

5.3系統各層構架設計 32

5.3.1WEB 表示層設計 32

5.3.2業務邏輯層設計 34

5.3.3數據適配層設計 35

5.4系統數據庫設計 35

5.4.1數據庫E-R圖 35

5.4.2數據庫表設計 36

5.4.3連接數據庫設計 38

5.5本章小結 38

第六章廣電發射傳輸中心信息管理系統實現 39

6.1系統的開發環境 39

6.2系統模塊的實現 39

6.2.1登陸功能的實現 39

6.2.2用戶操作模塊的實現 41

6.2.3系統管理模塊的實現 44

6.2.4播出記錄模塊的實現 46

6.2.5技術資料模塊的實現 49

6.2.6維護記錄模塊的實現 53

6.2.7專業訓練模塊的實現 55

6.2.8器材管理模塊的實現 58

6.3本章小結 59

第七章系統測試 60

7.1測試目的 60

7.2測試方法 60

7.3測試內容 61

7.4測試環境 61

7.5用戶測試 62

7.6功能測試 62

7.6.1播出記錄功能測試 62

7.6.2技術資料功能測試 63

7.6.3維護記錄功能測試 65

7.6.4專業訓練功能測試 66

7.6.5器材管理功能測試 67

7.7測試結果分析和說明 68

7.8本章小結 68

第八章總結和展望 69

8.1 論文總結 69

8.2工作展望 69

致謝 70

參考文獻 71

第一章緒論

1.1課題研究背景、目的和意義

廣播電視發展在中國有60 多年的歷史，它以實時的音頻、視頻方式，改變著人們的生活，盡管在互聯網新媒體普及的時代，仍然有著不可取代的地位。廣播技術從AM （調幅）、FM （調頻）到近年來DAM （數字音頻廣播）、DMB （數字多媒體廣播），電視技術從黑白模擬到彩色數字，廣播電視的發展不僅表現在以上形式，也從業務上變得更豐滿，從單一的無線載體到有限載體，再到平臺運營商，其迎來了新的發展機遇。

我國廣播電視節目不僅負責傳播大眾喜愛的節目，還是要將黨和政府的聲音傳到千家萬戶，具有特殊的意義。隨著市場經濟的發展，人們的物質生活與精神生活日益豐富，人們對廣播電視節目的要求也變得多樣化，這樣促使廣播電視節目種類也豐富多彩，播出時間也成了二十四小時不間斷，雖然滿足了不同的用戶需求，但同時工作人員的工作量也增加，提高工作效率、確保安全播出，成了廣播電視發展最重要的目標。

廣電發射傳輸中心管理的無線發射臺站都建在離市區較遠的高山，需要安排人員全年都要堅守，在機房內監控播出情況，每幾個小時巡檢一次，并用紙質記錄設備運行數據。每套節目都有自己的維護檢修時間，需要人工進行維護并做好記錄，為提高專業維護水平、應急處理故障能力，還要經常進行專業化訓練，這些都要做好手工記錄。隨著信息化時代的不斷進步，單純的通過紙張記錄信息，已不能順應時代的發展了。紙張記錄信息存在很多的缺點，首先，記錄的信息長年累月的積累下來，保管很不方便，存在發生意外導致信息丟失的情況，比如較早的記錄由于年限太長字跡模糊不清或者由于意外導致資料不完整等，其次，大量的信息需要整理和收集，既浪費時間又浪費人力，而且要有專門的部門來管理這些資料，才能保證信息的準確，最重要的一點是當某些信息被拿出來使用時，又要花費大量的時間來進行查找，這種查找方法不僅麻煩而且信息的準確度不高。另一方面，對大量數據進行了記錄，當這些數據被使用時，制作成數據分析報表時，過程需要花費大量的人力和時間，而且這種人為的制作方法會存在誤差，要經過很多次的驗證之后，才能最終確定數據無誤差性，在數據采集之后不能快速準確的得到數據分析結果，事件處理周期不能縮短，效率相對存在滯后性。

所以對大量信息的處理，我們應該開發相對應的軟件管理系統，通過軟件來管理龐大數據，這樣不僅提高工作效率，而且能節約大量的時間和人力，保證數

據處理的正確性。當為系統培訓一名管理員，讓他了解整個系統所具備的功能以

及操作方法，那么他就可以獨立完成數據的收集、處理、以及展示，輕輕松松完成復雜的工作，提高工作效率。因此，廣電發射傳輸中心對他們的發射機的播出記錄以及文檔的管理采用系統的軟件管理，提高資料的管理效率，這不僅是現代社會對他們的要求，也是自身發展的需求。

在今天，隨著信息技術的高速發展，企業，單位對于工作效率的提高也有著

新的要求與目標。各行各業借助計算機技術，簡化工作流程，提高自身工作效率。

資料，設備的管理是各企業、單位管理中的重要環節，是關系著整個企業或單位資源利用，高效益回收的關鍵。將資料，設備管理信息化，網絡化，可以優化企業內部的管理，簡化以前陳舊的人工管理模式，從而在空間，時間上極大的提高企業管理的效率，進而提高企業的效益。作者參與的基于SSH架構的四川廣播電視臺發射傳輸中心信息管理系統，就是基于安全播出、技術質量、節目內容、運行狀況等四個方面，為了實現資料，設備的一體化、達到事前預警、事中監控、事后追究的信息化管理目的。一方面，企業由于業務規模的擴大，面臨日益龐大的數據增長壓力、新業務功能的持續擴展、服務形態的不斷變化、新技術的更替等多方面的挑戰，四川廣播電視臺發射傳輸中心需要重新規劃IT架構和軟件系統; 另一方面，為了獲得更強的競爭力，擴大影響力，四川廣播電視臺發射傳輸中心希望充分利用發達的因特網普及業務，弱化地理限制，“足不出戶”就能最大范圍的管理，為了電子化、數字化和網絡化的整個管理過程，急需建立一個信息系統。

1.2課題研究的目標及內容

1、課題研究目標

本課題研究目標是分析廣電發射傳輸中心信息化管理模式，提出行之有效的解決方案，設計并實現廣電發射傳輸中心信息管理系統，并在此基礎上撰寫學位論文。

2、課題主要研究內容

經過全面的研究分析，廣電發射傳輸中心信息管理系統主要是針對日常管理工作。比如日常的播出記錄工作，技術資料保存、查閱，維護記錄記載、查閱，專業訓練的記錄，器材管理等方面。該系統功能設計有增加、查詢、修改、刪除、瀏覽、生成統計報表及形成圖形直觀展示效果。針對管理來說具有安全、方便、靈活、專業、數據庫強大等優點，針對用戶來說具有一般的上網知識都可以操作，易學、易懂、易用的軟件管理系統。達到有效降低傳輸播出事故、提高播出質量、減輕值機人員的勞動強度，提升安全播出保障能力，促進安全播出工作在科學化、

規范化的道路上邁進了一大步。

本論文主要研究內容從軟件設計流程上可做如下劃分：

( 1 )廣電發射傳輸中心信息管理系統總體解決方案。

( 2)廣電發射傳輸中心信息管理系統的業務流程分析、系統功能需求分析、系統的功能設計等。

( 3)廣電發射傳輸中心信息管理系統數據庫結構的研究以及設計。

( 4)廣電發射傳輸中心信息管理系統總體架構模式及各模塊功能的設計與實

現。

(5)廣電發射傳輸中心信息管理系統報表生成及圖形直觀展示。

( 6)廣電發射傳輸中心信息管理系統的數據提取。

3、課題擬解決的關鍵問題與時俱進，提高廣電發射傳輸中心管理的信息化，為廣電發射傳輸中心的安全播出、信息管理提供了強有力的技術支撐。在明確系統目標和所需要研究的內

容后，可將課題擬解決的關鍵問題歸納為以下幾個問題：

( 1)在廣電發射傳輸中心信息管理系統軟件中運用工作流技術，對單位的工作流進行重組和優化，減少紙張記錄，從而全面地提供工作效率。

( 2)如何發揮 MVC 模式和 SSH 的優勢，在這兩種技術的支持下，如何開發更加穩定和優化的系統。

( 3)廣電發射傳輸中心信息管理系統總體解決方案設計。

( 4)廣電發射傳輸中心信息管理系統數據庫設計。

( 5)廣電發射傳輸中心信息管理系統功能需求以及功能設計。

( 6)廣電發射傳輸中心信息管理系統總體架構模式設計。

1.3國內外研究現狀

在國外，從行業上來講由意大利人率先將單片機應用在廣播電視設備上，隨

著半導體迅速的發展，一顆小小的芯片就集成了上千萬晶體管的功能，而且處理速度達到GHz,這種高性能、低功耗、低成本的芯片成為自動化領域的寵兒，日本東芝公司在廣播電視設備信息化上鉆研得比較成熟。國外廣播電視機構信息化管理已經進入設備自動化、數字化、網絡化，設備本身往往具有遙感遙測功能，

只需要各設備端口標準配備接入控制端，就可以遠程操作，不需要人工長期堅守。單從管理信息系統發展來說， 20世紀 50年代中期，美國通用電氣公司就開始了用計算機處理數據的技術，由于信息化起步較早所以現在也趨于成熟，此類系統在國外也一直在不斷的創新和完善。目前，國外在管理信息系統的應用已經比較普及，大多數企事業單位已經使用管理信息系統多年，同時也在逐步推行全球化供應鏈管理技術和敏捷型系統。國外的信息化管理已經和企業自身的文化融合在一起，比如全球信息技術領袖企業IBM,就擁有非常成熟完整安全的信息管理方案, 自改革開放以來逐漸被我國更多的企業采納應用。

在國內，由于歷史原因國內廣播電視無線發射傳輸事業發展滯后，各單位設備不統一，模擬、數字設備均有，部分設備沒有控制主芯片及外接端口。大部分臺站都是人工看守管理，對應行業發展，相對落后。在 20 世紀 80 年代，由浙江廣播科學研究所和浙大計算機系共同開發的一款調頻廣播發射機具有信息化功能。隨著計算機在中國的發展，到2006年國家廣播電影電視總局發布了《廣播影視科技發展“十五”規劃》文件（廣發〔2006〕55 號），提出要加快廣播電視無線發射、傳輸設施的更新改造，不斷提高發射臺站自動化進程。2010 年 2 月中旬國家廣播電影電視總局令《廣播電視安全播出管理規定》（第62 號）正式施行，其中對從事廣播電視播出、傳輸、覆蓋等業務的單位作了規范的技術要求。同年5 月國家廣播電影電視總局發布了《廣播電視安全播出管理規定》無線發射轉播臺實施細則（試行），再次對無線發射節目的安全播出保障，在系統配置及運行、維護、技術管理方面提出更具體要求：對自臺監控、技術管理等，應建立信息化管理系統，異態信息有效保存一年以上，確保無線廣播電視安全播出。在信息化的今天，各省無線發射傳輸中心都在倡導“有人留守無人值班”模式，這也是未來無線發射傳輸管理未來發展方向。

每一位工作執行者都期望各部門業務的運行效率提高，以便輔助其主業務。比如在需要數據時只需輸入一個關鍵字就可以找到并且查看其相關內容，而且他占用的空間也不大，只需要你有臺電腦，就可以輕松的實現對海量信息的管理，不再擔心不能及時得到所需的信息，尤其是需要處理信息時，能快速的查找準確對應信息，并且展示其內容，還可以通過對信息統計處理以比較直觀的方式顯示，通過圖形來展示數據的變化是最為直觀的，這種數據的展示方式比單純的數據顯示更加人性化，而且使枯燥的數據更加豐富，讓人們更加容易理解記憶，因此，此系統的開發是勢在必行的，它能更好提高廣電發射傳輸中心安全播出保障能力和管理水平。

1.4論文的結構

本論文共分為八章，首先，論文分析了開發本系統的必要性，以及開發本論文的背景和重要意義，其次論文詳細介紹了本系統的需求，以及我們在開發系統中需要解決的一些特殊的問題，然后是本系統開發的設計方案，以及系統中一些重要功能的設計，其次針對系統開發中功能模塊設計進行了詳細描述，并對于在開發中出現的問題給出解決方案，呈現結果。然后是對系統運行狀況進行分析，及對系統運行狀況作出優化，最后是對本系統開發結束后的總結，以及闡述系統將來的改進。

論文具體安排如下：

第一章介紹了開發本系統的背景，以及開發本系統的必要性，通過對廣電發射傳輸中心信息管理系統業務情況的分析，說明該課題研究的背景和目的。

第二章介紹了系統開發使用的工具，對關鍵技術的詳細闡述。

第三章介紹了系統開發的軟硬件環境配置，系統整體架構部署，重點講解了

MVC架構、SSH框架、數據流與數據庫的交互、后臺的業務邏輯以及前后臺的數據交互。

第四章對信息管理系統業務進行詳細的需求分析，并對系統非功能性進行需求分析。

第五章對各功能模塊進行了詳細分析，如何將它與SSH相結合，如何考慮數據的獲取問題，以及對業務流程進行設計。

第六章輔以流程圖、實現截面圖、主要代碼，對各功能模塊的具體實現過程進行了詳細的描述，從如何配置開發環境，以及如何調用數據。

第七章對實現的頁面進行了測試，通過測試用例以及功能測試進行分析。

第八章對系統的開發過程進行了總結，并說明了系統需完善的部分。

第二章系統的相關技術概述

2.1項目開發的工具

對項目開發中使用的主要設計和開發的工具進行了介紹：

1、 Microsoft Visio 2003和Star UML在項目需求分析和開發設計中被使用，可以幫助我們，在對需求有深入細致的了解后，就如何實現其功能，以及功能實現中類和方法的設計，并且對其開發中所包含的屬性關聯等都進行設計，對對象的使用屬性性質的變化進行設計，將設計思想用可視化的圖例進行展示，以供開發中作為參考，具體以創建靜態的對象、抽象的參與者、復雜的數據關系等為模型展示。Microsoft Visio 2003可以建立流程圖、組織圖、時間表、營銷圖及其它功能圖表，用圖表代替文字描述加入文檔，讓溝通變得更加清晰、生動、有趣，將復雜過程變得簡單化，文檔重點一目了然，這種視覺化的信息交流方式讓我們的工作變得更有效率；StarUML是一種創建UML類圖，生成類圖和其它類型的統一建模語言圖表的工具，它是一個開源項目之一發展靈活、可擴展性強，可繪制9款UML圖：用例圖、類圖、序列圖、狀態圖、活動圖、通行圖、模塊圖、部署圖以及復合結構圖等。

2、 MySQL Server 5.5是一款簡單實用的數據庫，開發者為瑞典MySQL AB公司，MySQL Server是一個小型關系型數據庫管理系統，其優點是：源碼開放無版權費用、數據操作訪問速度快、占用空間小；所以很多中小型系統都使用該數據庫。MySQL Server的新特性：表和索引的分區、行級復制、MySQL基群基于磁盤的數據支持、MySQL集群復制；這是一個完全集成事務安全，事務完整性的數據庫。它包括完整的提交，回滾，崩潰恢復和行級鎖定功能。

2.2關鍵技術概述

2.2.1JSP 和 JavaScript

本系統的頁面開發使用的是JSP和JavaScript。

1、JSP是Java Server Pages的縮寫，最先由Sun公司發起，很多企業都參與并發展了這一動態網頁技術。JSP技術與ASP技術具有相似性，一個JSP文件包含JAVA程序段和JSP標記，其跨平臺（Linux、Windows、Android等等）、可移植性強的優點使得它一推出就獲得大批企業的支持和推廣。當收到請求訪問 JSP 網頁時，服務器先執行其中的程序段，再把結果和JSP中的HTML代碼綁定一起發送到客戶端。比如數據庫、重定向網頁等就由插入的 Java 程序段操作，建立動態網頁所需的功能就可以這樣實現。JSP與JavaServlet有一個共性，就是所有執行都在服務器端，這樣一來返回給客戶端的就是一個 HTML 文本，在客戶端通過瀏覽器就可以查看［1］。

2、JavaScript、jQuery 和 Ajax

JavaScript 是一種網頁來執行的腳本語言，其特點是：結構簡單，使用方便，所寫代碼直接收入到 HTML 文檔中，可以在網頁中執行，前提是支持 JavaScript 的網頁， JavaScript 使得網頁更具交互性，網頁界面更為活躍，視覺體驗更豐富。

jQuery 的使用解決了不同瀏覽器對 JavaScript 不兼容的問題，使 JavaScript 的使用更加廣泛，隨著世界各地眾越來越多 JavaScript 高手加入 John Resig 創建的 JQuery， jQuery 成了繼承了 prototype 之后又一個優秀的 JavaScript 框架，他主要的優點是用更少的代碼，做更多的事情［2］。

Ajax 是這個詞是由一位名叫 JeSSe JameS Garrett 的開發人員創造的，并非單純的是 “Asynchronous JavaScript and XML” 縮寫（異步 JavaScript 和 XML），它是 JS 的一小部分，是指一種創建交互式 WEB 應用的網頁開發技術，每一次交互只更新數據部分，不會頁面整個更新，這樣縮短了響應時間［3］。

如圖 2-1 所示 Ajax 工作流程，說明了 Ajax 調用數據處理點擊事件的過程。

圖 2-1 Ajax 工作流程

2?2?2 JSON對象

JSON是一種輕量級的數據交換格式，其全稱是：JavaScript Object Notation。作為 JavaScript 的一個子集， JSON 既保留了 C 語言家族的習慣，也引入了完全獨立于語言的文本格式，這些特性使得 JSON 在使用起來編程簡單、可讀性好、易于編譯器解釋和生成機器碼［4］。JSON可以表示“名稱/值對”更復雜的結構，可以表示數據和復雜的對象，而且不僅僅是鍵和值的簡單列表［5］。JSON對象的各種定義形式如下：

1、對象（object）是一個無序的“值/對”集合，如圖2-2所示為JSON對象型數據結構：

圖2-2 JSON對象型數據結構

2、數組（array）是值的有序集合，如圖2-3所示為JSON數組型數據結構：

array

| 陽恥 | I

圖2-3 JSON數組型數據結構

3、值（value）可以是用雙引號標注的字符串、數值、數據、true、false、null、

對象，如圖2-4所示JSON值型數據結構：

圖2-4 JSON值型數據結構

4、字符串（String）是所有任意Unicode字符（不含控制符）加雙引號（“”），加反斜線（\）表示轉義字符，數據結構如圖 2-5 所示：

圖 2-5 JSON 字符串型數據結構

5、數值（number）與Java或者C的數值具有相似性，如圖2-6所示為JSON 數值型數據結構：

圖 2-6 JSON 數值型數據結構

2.2.3 Kendo UI 的簡介

Kendo UI 是一個用于開發現在 HTML UI 操作界面的框架。基于最新技術 HTML5、css3和JavaScript標準設計開發。Kendo包含了開發現代JavaScript開發所需的所有一切，包括：強大的數據源，通用的拖拉功能，模版和 UI 控件［6］。

Kendo的UI分為 Web、Mobile和DataViz［7］本系統的開發使用的Kendo UI DataViz，它為我們提供了 Area Charts> Bar charts> Pie Charts> Line Charts> Scatter Charts、 Multiple Axes 的模版以及他們的數據定義參考文檔，本系統的柱狀圖開發使用的是Bar charts。它是一款能幫助我們實現豐富的頁面效果的插件。

微軟用戶界面框架（WPF）,微軟公司發布于2007年。在Microsoft .NET Framework3.0里是新一代的顯示系統。WPF為開發人員提供了一個統一的編程模型為用戶體驗用戶界面、媒體和文檔來構建豐富的 Windows 智能客戶端。對于 ASP.NET來說，WPF提供了后臺代碼窗口模式。在這個模型中，.xaml文件里包括標記、控制等視覺元素。然而，代碼卻單獨在這樣一個包括事件處理程序和其他代碼的.CS或.vb文件里。目前，幫助WPF應用程序開發的主要工具包括Visual Studio 和 Expression Blend 4。Expression Blend［8］是一個用來可視化的設計 WPF 應用程序的UI和生成可擴展應用程序標記語言(XAML)代碼的工具，可以被Visual Studio 準確的通過編譯。開發者在 Visual Studio 和 Expression Blend 4 這兩個工具中修改文件內容是同步的。

WPF可以作為一個新的管理信息系統(MIS)的開發平臺。但是遺憾的是，WPF 的優勢還沒有完全被MIS開發人員意識到。目前，相關研究集中在WPF應用程序的技術特性和闡釋。Chris Sells和Ian Griffiths被啟發構建WPF的window UI細節。 Wang Chanjuan闡明了 WPF編程的基本知識點［9］。Li Yingbao為WPF的充分使用提供了闡釋。然而，幾乎所有對WPF的研究都是分離的，沒有把WPF和MIS整合到一起研究。本文的重點是試著把WPF和MIS結合在一起來研究，在MIS開發中WPF能做什么。WPF可以創建Windows客戶機應用程序或browser-hosted形式的應用程序，但本文只討論 Windows 客戶機應用程序。作為一種人機系統，用戶界面是一個復雜的并且是管理信息系統的重要組成部分，對于用戶體驗是非常重要的。我們可以認為這就相當于人的外表，這將給用戶提供一個美好的印象。新一代信息系統的用戶需要高機動性和舒適性。用戶希望管理信息系統不僅能為他們提供豐富的功能，同時也能帶給他們一個舒適、愉快的UI。因此，用戶是否能被驚艷的 UI 所吸引對與 MIS 是非常重要的。然而，使用傳統的 MIS 開發框架 (Win32 API，MFC，Windows窗體等)很難設計經濟驚人的UI。

近年來，計算機硬件的性能尤其是圖形設備大幅上升，這將對 MIS 開發提高用戶體驗是非常有用的。PresentationFramework、PresentationCore 和 milcore 都是 WPF的主要組件。其中，milcore被寫在非托管代碼中以便能和DirectX緊密集成在一起。在WPF里所有的顯示都是通過DirectX引擎以便允許高效的硬件和軟件渲染。微軟 DirectX 是 Windows 核心技術，用來驅動高速多媒體電腦和游戲。利用DirectX，WPF使MIS呈現豐富的多媒體元素，例如全彩圖像，視頻，3d動畫，和豐富的音頻［10］。

WPF 引入了一個廣泛的、可伸縮的和靈活的圖形特性，比如先進的圖形和動畫的支持，硬件加速等等。WPF不僅提供了一個共同vector-drawn的二維形狀的文庫，同時也包括3d渲染能力。例如，圖一顯示二維圖像上呈現三維形狀。此外， WPF為圖像、動畫、音頻和視頻提供特殊支持，使MIS開發人員可以構建更容易令人興奮和有趣的UI和內容。令人興奮地是，所有這些工作都可以用WPF開發工具 Visual Studio 2010 或 Expression Blend 4 輕松高效地完成。不需要其他的圖形工具(Adobe Photoshop， Adobe Illustrator， Autodesk 3d Studio Max 等等)輔助完成。

一般來說， MIS 開發團隊包括分析師、設計師、程序員、數據庫管理員等等。特別是UI設計師和程序員他們之間有一個明確的劃分。前者負責MIS的UI設計，后者負責程序代碼。在WPF發布之前，UI設計師和程序員在MIS開發合作時是非常浪費時間和低效的。文獻［11］顯然是一個典型的關于他們之間的協作過程：首先。需求分析完成后，根據用戶要求的范圍，程序員設計用戶界面,然后專注于代碼；其次， UI 設計人員設計 UI 使用專業圖形軟件同步，如 Adobe Photoshop 和 Autodesk 3d Studio Max。第三，程序員UI設計師設計的圖形轉移到windows或頁面使用的編程語言。在這一過程中存在一些問題:不匹配圖形用戶界面和MIS的功能，從圖形用戶界面編程語言不完美過渡，這個過渡是困難的和浪費時間的。

以上敘述的原因是什么呢？ UI設計人員的結果不能由程序員直接重用，這就是問題的關鍵。我們不能要求UI設計人員使用編程語言，同樣也不能要求程序員在他們工作時使用Photoshop來完成。為了解決這個問題，微軟在WPF內提供了一個新的標記語言——XAML。目的就是讓UI開發人員和設計師都能更有效地完成他們的工作。

Expression Blend 4［12］和 Visual Studio 2010 是 WPF 平臺的兩個工具。前者是設計用戶界面的工具，后者是程序代碼的工具。他們都能生成XAML代碼，這有助于消除傳統上在設計和開發過程中存在的障礙和瓶頸。在 Expression Blend 4 中，設計師創建UI的MIS視覺，畫形狀，路徑，并控制藝術面板，然后修改他們的外觀和動作。他們可以插入圖片、視頻和聲音，或從 Adobe Photoshop 或者 Adobe Illustrator 導入對象，他們通過 XAML 來呈現視覺設計，通過 Expression Blend 4 和visual Studio 2010可以共享項目，代碼，資源。在完成一個UI，設計師可以右鍵單擊項目名稱，選擇“編輯”在 Visual Studio Expression Blend 4 中的彈出菜單。你用Visual Studio 2010打開由Expression Blend 4所創建的.xaml文件，你可以看到他們是完全一樣的。程序員可以基于此文件上繼續編程。不需要任何的轉換，不需要再重新設計 UI。

良好的用戶體驗和健壯的核心架構的優勢與聯合的力量匯集在 Expression Blend 4和Visual Studio 2010中，通過XAML加速了應用程序交付。總之，WPF 幫助用戶界面設計師和 MIS 程序員更加專注于自己的工作，尤其是減輕了程序員的 UI 設計工作。

2.3本章小結

本章主要介紹了系統設計中使用的工具，以及對各項技術進行了簡要的概述說明他們所具有的一些特性，以及他們的優點等。

第三章廣電發射傳輸中心信息管理系統的開發環境

3.1系統概述

該廣電發射傳輸中心信息管理系統是一款對播出記錄、文檔管理和資料等信息進行管理的系統，實現對業務更好的管理作用，讓各項資料得到綜合的管理和展示，資料的管理更加方便高效。由于它是一款信息管理系統，更多的是對信息的管理，所以我們在開發的時候使用java語言開發，通過SSH框架實現業務邏輯, 因為它能更加方便的實現信息的增刪改查，讓系統的開發更加簡單，業務邏輯的實現更加容易理解，本系統界面的開發使用JSP，他們的結合能使頁面開發效果更加絢麗，讓頁面整體展示效果更加豐滿美觀，功能的操作效果更加人性化，它實現了播出記錄、技術資料和器材管理三個模塊。

3.2系統運行環境

軟件系統的運行需要一個環境來支持它，它分為硬件環境和軟件環境：

1、硬件環境

CPU：P4 3.0以上；

內存：1GB以上

硬盤：硬盤 80G；

2、軟件環境

開發語言：Java

開發工具：MyEclipse &5

數據庫：MySQL Server 5.5

界面設計工具：Adobe Dreamweaver

服務器軟件：Apache-tomcat-6.0.14

JDK 版本：JDK Version1.6.0.07

操作系統：Windows Server2003

隨著企業的適應和改造他們的業務流程和IT業務系統，以滿足新的挑戰和應對客戶許多決定基于SOA系統實施的需求。成本效率、靈活性、適應性的保證吸引了眾多企業嘗試SOA，并且在很多情況下，對基于SOA的新系統作出重大投資。為了推動改造自己的業務流程和IT業務系統，很多組織正在開展合理化方案，以確定什么樣的戰略，他們將繼續在未來，什么樣的業務流程將支持這些戰略，并確定IT系統是必要的。由于這種合理化的一部分，許多組織正在向基于SOA的系統。有各種不同的引入SOA方面的挖掘和重用遺留收購一個基于SOA的環境中的服務組件SOA基礎設施和發展。

構建基于SOA的組織的主要顧慮之一系統應該是不論這些系統能夠滿足品質特性的服務質量（QoS）的要求。SOA的使用，就可以有一個一些質量屬性，并積極的影響產生負面影響其他［13］。一些組織的主要問題處理他們的安全性，性能，可用性和互操作性基于SOA的系統。確定到底是什么的QoS建立自己的系統，以符合這些要求，要求，分析系統，以確保它們符合并確定什么是他們的服務質量和管理所有這一切通過指定和談判的服務水平協議（SLA）的，可組織相當繁重。我們一直在努力建筑性能和 QoS 建模和仿真工具，并概述一些開放性的問題，還需要進一步研究。當一個組織準備開始使用SOA又不想放棄在現有系統上的投入, 但又不得不處理這些問題的時候，那就需要確定哪些服務是必須的，現有系統上的哪些組件可以遷移填補服務的需要。以下幾個事情是需要去做的：確定哪些服務會被SOA使用到。一個組織可以通過開發一個自上而下結構的業務流程和識別服務的完整企業架構來達到這個目標，或者通過檢查它的每個現有系統，確定共同進程或者函數和自上而下的識別這些服務。不管使用哪種方法，怎樣識別服務都是一個主要問題。確定遺留或者現有的哪些組件可以滿足服務的需求和需要做什么來把這些組件作為服務遷移和重用。做這些之前，需要確定這樣的遷移所需的成本和精力，以此來確定挖掘和重用的可行性。SMART是一個可以用來幫助確定所需成本和精力的方法。

無論選擇哪種方法（自底向上或自頂向下），如果遺留組件是用來滿足服務需求的話，那么識別滿足性能和 QoS 要求的服務是非常重要的。識別和挖掘所需服務的方法要考慮這些要求，進行詳細的分析，確定這些服務是否能滿足當前和未來的QoS的要求。作為一個組織，推進SOA策略服務發展將會被識別，要么內部，要么外部，需要結合組織的現有系統。組織將需要能夠確定服務會集成哪些系統，涉及的工作范圍包括估計做這項工作的成本和精力。該組織還必須確定不同的結構選擇將在各種質量屬性和 QoS 方面對系統產生什么樣的影響。以及必須確定其應用程序和系統的SLA（Service-Level Agreement［14］，服務等級協議）和服務需要的 QoS 要求，它消耗并與服務提供者協商這些。

我們目前正在研究一個方法來解決這些問題，我們稱之為SMAT-AUS。該方法由以下幾個部分組成：確定集成的范圍，規模，工作量和成本；詳細建模與研究性能的仿真實驗，以及QoS關于能夠生成可替代架構解決方案，以滿足不同QoS 的要求的能力。一個關于服務整合的主要的未解決問題是，這種規模的集成工作和各種其他部分如何構成成本的。數據元素的數量，系統的復雜性，服務的復雜性，過程的復雜性，試用標準，潛在風險等都影響成本。解決在SOA項目中的成本（個人活動及總成本）厘定的方法和技術的開發仍需在整個行業中進行充分開發，測試和試用。為了運行和管理SOA應用程序，一個組織需要一個SOA基礎設施。 SOA基礎設施包括幾個部分來支持SOA的主要方面，包括安全，治理，管理，編制和資源（例如虛擬化）。 Gartner 列出了以下幾個在 SOA 中的主要技術錯誤[15]: IBM，微軟，SAP，Oracle，BEA以及許多其他的廠商都提倡使用他們的SOA基礎設施技術。這一領域未解決的問題是組織應該選擇什么樣的SOA基礎設施以及需要什么樣的組件來構建他們自己的SOA基礎設施？一個組織如何測試基礎設施能夠提供滿足他們要求的級別的安全性，治理和管理？如何處理不同供應商的基礎設施之間的互通性？作為一個組織推進SOA策略將需要使用其內部的服務或外部組織提供的服務來開發服務和應用程序。不同的開發服務和應用程序的方法如傳統的螺旋發展模型可以以更靈活的方式被使用。還可以使用自上而下的由業務流程或模型驅動架構驅動的方法，或者自下而上的由現有遺留的系統和組件化遺留驅動的方法。

在處理服務和應用程序開發中，最主要的擔心之一是處理服務的質量和應用程序服務的質量（依賴于服務使用的QoS）。一個主要的問題是定時服務的開發與 QoS 設計之間的矛盾。如果一組服務必須在一個特定的時間框架中開發，特別是用更靈活的方法，如何處理服務的QoS（可能持續整個開發過程）。當開發服務和應用的時候，一個組織會有服務和應用程序不得不滿足的特定的 QoS 要求。這些要求可以指導服務和應用程序的開發，但很少有開發方法可以保證合成服務或應用程序滿足他們的 QoS 需求。為了進行一個項目，從眾多服務中開發一個服務或一個應用程序，需要知道所涉及的工作的規模和大小。一些指導方針，參與確定開發已經耗費的成本，但是很少有方法做一個完整的范圍，大小，成本和工作量的估計。在這個領域需要更多的方法來確定范圍和合理準確的成本和工作量數據，這有助于幫助組織為他們主要的 SOA 的工作量制定更好的預算和計劃。自 2006 年以來，我們一直在研究、開發和測試SOAs性能建模的方法和工具。架構和開發服務和應用程序的 SOA 考慮性能是至關重要的。一些關于 SOA 性能問題的例子如下。Web服務的性能（響應時間）通常比裸露的底層功能更糟糕。這是由于和加劇了 XML的固定費用（如傳送，解析，驗證，序列化），復合服務的實現（如使用包括第三方服務和遺留應用程序的服務），服務編排（基礎設施和協議），服務調用（如安全，運輸），資源（物理或軟件資源，如cpu，線程）和資源模型（例如虛擬化）。最優的資源配置服務也是困難的，因為資源可能沒有被正確分配，對于個人服務的分布式工作流的高需求可能會由于資源的約束成為瓶頸。消費者對于性能的期望可能高于實際能提供的。例如，我們已經知道SLA承諾的響應時間不到一秒，而在實踐中的響應時間范圍為1到48秒之間。響應時間通常是不可預測的，并隨服務的操作，綁定，參數和載荷的改變而改變。如果調用一個服務的時間是不確定的，消費者就不能確定調用是成功還是失敗（例如，如果副作用是可能的）。

也許最嚴重的問題是開放服務的可伸縮性——即服務公開暴露。最大數量的消費者，到達率和分布是不能提前預知的，而且極高的峰值需求可能使一個或多個服務資源飽和，從而導致增加響應時間，或者更有可能的是，服務不可用是由于故障或強制訪問限制來限制需求（卸載）。例如，開放服務可用于構建第三方混搭式應用，導致意想不到的消費服務需求的增加和分布。考慮到性能是對于 SOAs 一個眾所周知的問題，在考慮性能的情況下架構SOA是至關重要的。要做到這一點需要能夠在開發周期的早期理解體系結構的性能特點和調查選擇。為此，我們開發一種方法和工具來支持 SOA 生命周期的早期性能建模。該工具支持 SOA 概念方面（服務，工作流和組合服務）的性能建模，并自動將 SOA 模型轉換成一個能模擬SOA組件生產性能指標的模型。我們遇到并有了初步進展的顯著的性能建模問題是在服務編制（例如工作流和引擎），資源虛擬化（如虛擬服務器）和服務等級協議（SLA）領域。我們相信，在這些方面的研究是重要的，但到目前為止不完整，我們依次簡要描述每一個研究。

3.3系統架構描述

系統架構是構建計算機軟件實踐的基礎，通常軟件系統的架構有兩個要素：一方面系統的架構是一個軟件系統從整體到單元的最高層次的劃分；另一方面這個系統本身結構的重要信息是：組成系統的這些元件是如何形成、相互之間如何發生作用的［16］。

本系統的開發使用的是C/S的Web應用架構，即客戶端/服務器（Client/Server）, 在客戶端/服務器網絡中，客戶端發出請求，服務器收到請求并建立連接后將數據信息提供給客戶端。服務器和客戶端兩個應用程序在通信中被涉及，使用 C/S 能夠減輕應用服務器運行數據負荷，減少通信開銷，而且大多數的應用軟件系統都是 C/S 形式的兩層結構［17］。

數據和應用程序高效性已經成為了一種商業需求，但是在那些支持恢復和高效數據庫的數據的數據庫系統中，應用程序還是能由于服務器中斷而丟失工作。當服務器崩潰時，就會丟失不穩定的應用程序的數據會話，這時操作重啟需要應用程序輔助。公共服務器出現故障時會降低應用程序的實用性。我們的 Phoenix odbc[18]系統支持持久性的數據庫會話，除了可能的定時方面的考慮，它還可以在數據庫崩潰的時不影響應用程序的運行。這提高了應用程序的可用性，還解決了應用程序編程需要考慮數據庫崩潰的問題oPhoenix ODBC不需要更改數據庫系統, 數據庫訪問路徑或者是應用程序，因此他可以被任何應用程序用來訪問數據庫。此外，還可以利用各種數據訪問協議。在本文中，我們將會描述Phoenix ODBC的設計過程，還會介紹一種擴展程序去優化響應時間和減少OLTP工作負載的開銷。我們提出了一個使用TPC-C和TPC-H基準測試的性能評價，演示Phoenix ODBC 的額外開銷是適度的。

數據和應用程序的高效性越來越成為大小企業的基本需求。Phoenix項目在微軟研究方面的目標是提高應用程序的效率以及極大地較少編程和處理系統故障時的操作任務，這需要的不不僅僅是簡單的提高數據庫服務器的可靠性。有一些服務器故障時不可避免的。我們注重的是提高系統其它部分處理數據庫服務器故障的能力。我們已經建立一個名叫Phoenix ODBC的系統，它能夠提供持久的客戶端 -服務器的數據庫會話，可以在客戶端應用程序不知道斷開的情況下在服務器崩潰中運行。這種對于數據庫服務器崩潰的屏蔽意味著：

（1）應用程序不需要采取特別的措施處理服務器故障；

（2）應用程序不需要經歷很長時間的中斷（它暫停了，但是并不是停止了），通常最多幾秒鐘或者幾分鐘。這對于以前手工處理那些由于數據庫崩潰需要回復的應用程序來說，是一個巨大的進步，手工可能需要數小時，甚至數天。

數據庫系統早已可以用一種穩定的方式處理系統崩潰。事實上，能夠讓最后一次提交的數據庫事務恢復的技術是很成熟的，效益也是很好的。然而，在處理應用程序時并不是那么簡單，特別是程序員設計應用程序去處理系統崩潰時。不論哪種形式的應用程序都必須非常嚴格的控制，就像保持應用無狀態或者涉及反措施或者精心設計的的異常處理，都需要提供一種充分的反應去處理系統崩潰。在這兩種情況中，應用程序員都需要非常清楚系統崩潰是可能的，并且要十分謹慎的編寫程序。大部分的結果是應用程序實際上在服務器崩潰時不能運行。這樣會將負擔轉移到其他地方，最明顯的時導致用戶在點對點手動操作去恢復應用到一個可以接受的狀態時有挫敗感和操作困難的感受。

應對系統故障，以最大限度減少應用程序終端和避免應用程序的復雜性，是一種讓應用程序魯棒性更好的辦法。為了達到這個目的，我們已經建立了一個系統，將數據庫技術擴展到系統數據入口部分，讓我們可以對客戶端應用程序掩蓋故障。我們的目標是提高應用程序的高效性和簡化應用程序的邏輯。我們設計了一個來達到這個目的，它負責應用程序在服務器故障的持久性。正是這個系統讓會話狀態可以恢復，并且讓應用程序可以繼續執行。如果一臺服務器發生故障，系統會自動重新連接到數據庫，恢復會話狀態和繼續執行，對客戶端掩蓋故障。這種持續的數據庫會話組件，稱為Phoenix ODBC，它實現并沒有專門的數據庫技術支持，并且要求對客戶的應用程序或者本地ODBC驅動程序沒有任何的更改。

正如在文獻［19］中描述的那樣，phoenix ODBC的角色是通過從客戶端屏蔽數據庫服務器崩潰的方式，盡可能提高成本效益從而提高應用程序的可用性。在本文中，我們的重點是量化和減少對應用程序響應時間和數據庫服務器的吞吐量的影響。我們報告了實驗測量的影響，并介紹了減少對OLTP方式工作量影響的優化。

我們的實驗測量了堅持在具有高度復雜性的服務器上進行結果集查詢的性能影響，例如如在TPC-H基準中發現的那樣。這種影響是溫和的。對于TPC-H的功率測試的影響是約1%,而進行更新的功能，它是小于0.5%。TPC-H吞吐量測試的結果是令人鼓舞的，表明對數據庫吞吐量的影響是次要的。我們的實驗也表明，一個數據庫會話可以在重新計算一個單一的查詢所需的一小段時間內恢復，并將其結果發送到客戶端。這些結果證實，它可以透明地提供持續的數據庫會話，這樣便可以屏蔽服務器崩潰，而不會影響性能。

在事務處理中高可用性是特別有價值的。交易處理工作負載通常是通過簡單的查詢(和更新)產生小的結果集。Phoenix ODBC開銷并不大，特別是作為產生較大的結果的一個部分的成本。然而，即使是很小的成本，也使子查詢產生了顯著的百分比差異。當我們測量簡單的TPC-C查詢產生的小結果時，響應時間比和服務器開銷的間接成本是顯著的。這使我們專注小的結果集的處理，這也是phoenix ODBC 主要的開銷。我們預計的優化，我們稱之為客戶端結果集緩存，從根本上消除OLTP方式的應用程序的開銷。從我們的實驗評價的結果證實了這一點。

3.3.1 MVC三層架構描述

在C/S架構的基礎上應用邏輯的開發使用了 M-V-C三層架構，M(Model)， V(view)， C(Controller)就是按照 Model、View、Controller 的方式把一個應用程序輸入、處理、輸出流程進行分離。MVC三層架構的提出，相比原有架構帶來了 3 個優勢：

(1)提高了模塊和程序的可移植性；

(2)減少了模塊間的耦合度，對Framework的依賴減少，提高了業務層代碼的可重用性；

(3)模塊和程序的可擴展性增強、可維護性變得容易［20］。

模型(Model) 視圖請求或業務處理后用于顯示的數據，如Java Bean；視圖（View）――用戶交互頁面，如JSP。這些應用使得代碼的重用率增加、數據表達減少，使軟件變得易修復、可擴展、易維護、易封裝，很大程度提高了軟件的靈活性［21］。

1、表現層：用于處理用戶與系統的交互功能：把系統的信息翻譯并顯示呈現給用戶，把

用戶信息解釋成領域層或持久層的各種動作。

2、領域層用于處理系統所有領域的相關工作，是系統業務邏輯處理的中心層。在有的

文獻中也稱作“業務邏輯層”。

3、持久層用于處理數據的讀/寫操作（在領域層之后）、與數據庫或文件系統的交互等

功能。如圖3-1所示為web企業應用架構M-V-C關系圖，對于MVC的理解具有一定的指導意義：

圖 3-1 表現層、領域層、控制層之間的關系圖

3.3.2 SSH 框架介紹

本系統 MVC 使用了 SSH （Struts+Spring+Hibernate）框架。通俗來講，SSH 是一種網絡協議，為通過網絡遠程訪問其他主機時提供安全保密。基本用于計算機之間的加密登錄。從職責上分為表示層、業務邏輯層、數據持久層和域模塊層（實體層）共四層［22］。

由SSH構建系統的基本業務在三層處理情況：在表示層，通過JSP頁面進行響應接受和請求傳送的信息交互，接著Struts根據配置文件（struts-config.xml）將 request安排給對應的Action處理，這個request由ActionServlet接收。在業務層，管理從業務層到表示層的實現，數據處理（DAO）組件完成業務邏輯和業務校驗, 并提供事物處理、緩沖等容器組件來提高靈活性，達到不需要彼此也可以直接進行通信。而在持久層，它依賴于Hibernate的對象關系映射和大部分主流SQL數據庫交互，DAO組件request的數據處理（如刪除、存儲、更新等），并將處理結果返回［23］。

SSH 框架的開發模式，將視圖、控制器與模型分離開來，還分離了業務邏輯層與持久層。也就是說無論前端如何變化，只需改動模型層少許，并且由于不同層之間耦合度減小，系統開發效率得到提高，對于我們協同合作提供了更多的共性，保持代碼的一致性［24］。

1、Struts 的基本介紹

Struts提供了相應的組件給Controller, Model和View。本系統使用的是Struts2。

Struts2是基于Web Work技術的框架，采用攔截器的機制來處理用戶的請求，最后根據struts.xml中的配置將對應結果result,返回給客戶端，這樣的設計也使得業務邏輯控制器能夠與Servlet API完全分離，Struts 2是Sun公司和 Web Work公司一起開發的一款功能非常齊全的框架［25］,如圖3-2所示為Struts 的工作原理如下：

圖3-2為Struts工作原理

2、Spring 的基本介紹

Spring提供的一個Web框架，Spring IOC是Spring的關鍵點，圖3-3是Spring IOC的工作圖，建立在以IOC （控制反轉）為核心的基礎上，Spring的基本處理流程，一旦收到request，分發器DispatcherServlet （前端控制器）就把request分發到繼承Controller的實現類，Controller處理完請求后，通過ModeAndView進行視圖的轉發，返回給分發器 DispatcherServlet。

圖 3-3 Spring IOC 容器

Spring bean 是那些組成應用程序的主體及由 Spring IOC 容器所管理的對象的統稱，由 Spring 容器尋找 Bean 的對應信息對其進行初始化、裝配及管理，每一個 Bean 對應一個實例，并通過配置元來描述 bean 定義和所有屬性，使用依賴注入，又叫屬性注入。Spring最常用應用系統配置源是XmlBeanFactory，可以選擇手動或自動設置［26］。處理 bean 依賴關系通常按以下步驟進行：

Spring 的 Singleton 作用域是非常重要的一個概念，當一個 Bean 的作用域為 Singleton，那么Spring loc容器中會存在一個共享的bean實例，并且所有對bean 的請求，只要 id 與該 Bean 定義匹配，則只會返回 bean 的同一個實例，所有隨后的請求和應用將返回到緩存對象實例［27］。

3、Hibernate 的基本介紹

Hibernate 是開源的一個 Object Relation Mapping Framework （對象關系）映射，即對面向Java環境的對象和關系型數據庫之間做一個映射，就不需要跟SQL打交道，簡化了一些數據庫的底層操作，提供了一些抽象程度更高的操作和方法，提高了開發效率。更加對象化，我們只需要以操作對象的方式操作即可，Hibernate 和 Spring 一樣，從表格式的表現形式轉換到一系列的對象中去的結果集，同樣需要配置，要有持久化類和它的映射文件，利用 Hibernate 開發，我們所要做的就是創建POJO類，配置映射關系，創建配置文件，然后調用Hibernate的API對數據

進行的操作曲，如圖3-4所示為hibernate配置文件它主要配置數據的鏈接和用戶名以及連接密碼，如圖3-5所示為將數據庫表映射到java對象中的過程，如圖3-6 所示為數據庫映射文件，配置了該文件java對象才能知道數據庫中字段的類型長度等信息。

圖3-4 Hibernate.cfg.xml 文件

圖 3-5 Java 對象映射到關系數據庫中的過程[29]

圖3-6 Hibernate映射文件

3.4軟件結構描述

有兩個因素影響了我們提供持久性數據庫會話的戰略。第一，我們希望利用現有的數據庫系統的功能去堅持會話，在服務器故障的時候能自動恢復數據庫會話。第二，我們通過無縫集成數據庫會話機制到正式的 ODBC 數據訪問交互來保持透明度，而不需要改變數據庫、應用程序或者本地ODBC驅動程序。

Phoenix ODBC是一個供應商提供的包裝ODBC驅動程序。在微軟客戶端中， Phoenix ODBC 是被集成到 ODBC 驅動程序管理器中［30］。驅動程序管理客戶端應用程序和各種各樣的商業 ODBC 之間的通信。應用程序請求先被發送到驅動程序管理器，然后發送到本地 ODBC 驅動。

增強型的Phoenix ODBC驅動程序管理器調用數據庫廠商提供的ODBC驅動程序的應答點，使用的是跟原驅動程序管理器相同的方式。它創建了 ODBC API 功能的替代品。所有的 ODBC 命令和數據庫回復是相互聯系并且合理通信的。 Phoenix ODBC執行三個主要功能提供持久的數據庫會話。為了使本文有說服力，我們在下面的小節中概括的展示每個功能。補充設計細節可以在前面的章節看到。

Phoenix ODBC必須采取的分析應用程序請求，并且提供持久性的不會定會話狀態的措施之前，需要phoenix將請求傳遞到本地的驅動程序。這種方法提供的能在系統崩潰下繼續運行的會話對于其他系統的組成部分是完全透明的。它不需要改變本地ODBC驅動，客戶端程序或者SQL數據庫系統。我們講會話狀態分解成單獨的元素，這些元素有不同的生存時間和我們可以利用的恢復要求。會話狀態包括：

會話背景：客戶端指定的屬性，包括連接請求、用戶登錄信息以及默認數據庫設置。數據庫的具體信息，比如用戶、實時數據、臨時對象（表、過程）以及由服務器發送到客戶端的信息。

（1） SQL語句的執行結果:一個SQL語句將會返回一個或者多個下列數據: 一個 select 語句的結果集

SQL語句外部引起的全局游標

一般是整數值的返回碼

返回的SQL更新信息

輸出參數，數據或者游標變量

（2）數據庫程序：存儲在數據庫服務器上，由一個或者多個預編譯的 SQL 語句組成。

（3） SQL命令批處理：一個或者多個SQL語句有著相同的效果。

雖然對于每個元素的會話狀態會有細微的差別，但是處理SQL的結果特別和

這篇論文相關，所以我們將會描述他們如何在細節處處理的。

結果集

Phoenix ODBC 使結果集有持久性［31］，并且保證無縫傳遞到客戶端應用程序中。一個結果可以通過被存儲為一個持久表而持續存在。無縫結果傳輸的保證是通過一次故障后再次訪問這個表，重新定位到傳送終端的地方來實現的。當phoenix ODBC 攔截了一個應用的請求，它執行一個一步解析發去決定請求的類型。如果這個請求是一個SQL語句生成的結果集，它就會按照下面的步驟去保證結果集會在服務器故障的情況下恢復。

(1)phoenix決定了結果集的結構，即名稱的屬性、類型和出現的順序。 Phoenix ODBC通過附加語句” WHERE 0=1”到原SQL語句中取得該元數據與單個服務器請求。它通過本地 ODBC 驅動來發送這個修改后的查詢到服務器。這個 “招數”保證該查詢不會被執行，并且沒有結果數據返回。只有查詢編譯在服務器上執行并且僅有元數據才會返回答復。

(2)創建一個表保存由SQL語句得到的結果。Phoenix ODBC從應答中讀取元數據，然后構建一個CREATE TABLE語句，最后把語句發送到數據庫在服務器上創建一個空表。此表是一個特殊的 phoenix 數據的一部分，并不是一個臨時的表格。

(3)結果集被儲存在服務器中的持久性表格中。什么被物化取決于SQL語句和應用程序如何在服務器中請求結果集。在ODBC中，如何做是由之前執行的 SELECT 語句制定的選項決定的。我們這里只描述默認的結果集。

數據庫服務器將立即發送所有行的默認結果，并且客戶端應用程序直到所有的讀操作執行完畢都需要緩沖。于此相反的是Phoenix ODBC發送給服務器一個請求去執行原語句，并且在步驟 2 中將結果存儲在永久性表格中。它通過穿件一下存儲過程來做到這一點，即使用ANSI標準的SQL：

CREATE PROCEDURE P (@T string) AS

INSERT

INTO Tname

存儲過程涉及到從客戶端到服務器的往返消息，這意味著數據的移動是在本地進行的，而不是先發送給客戶端。一旦服務器返回了一個應答就表示過程已經完成，結果集將不會受故障影響。

(4)結果集將會無縫的傳輸給客戶端應用程序。Phoenix將會決定語句 SELECT FROM TNAME打開表格并且在正常的過程中返回控制應用程序。如圖2 所示，為了確保無縫交付結果集，phoenix將跟蹤實時結果在永久結果集中的位置。如果發生故障，數據庫會恢復機制將會保證結果集在出現故障時存在。 Phoenix ODBC 會將結果集恢復在故障發生之前最后一次訪問的位置。

SQL 允許結果以其他方式返回，比如應用程序可以通過使用游標來控制結果交付。我們將會在下面第五部分描述phoenix ODBC是如何持續光標，如何描述數據修改語句、臨時對象和數據庫中返回的消息。

有兩個會話概念我們需要區分。應用程序有一個 ODBC 會話與它進行交互。

ODBC 代表應用程序建立連接（數據庫會話）并訪問數據庫系統。當一臺服務器崩潰時，數據庫會話可能不會在崩潰中支撐下去。服務器故障也可能會損壞甚至導致客戶端應用程序ODBC會話終止。

3.5本章小結

本章主要介紹了廣電發射傳輸中心信息管理系統開發的概要設計：整體架構、系統的軟硬件運行環境，詳細介紹了 MVC架構、SSH框架。

第四章廣電發射傳輸中心信息管理系統的需求分析

根據多年在廣電發射傳輸中心工作經驗，廣電發射傳輸中心信息管理系統是一個確保廣播電視無線發射傳輸安全播出為宗旨的信息管理系統，通過該平臺可以實現對播出狀態、日常維護、應急處理進行監管、查詢等功能，從而進行有效管理。

4.1系統需求分析

4.1.1用戶需求分析

經分析，系統至少需要兩種用戶角色：系統管理員和普通用戶。各自權限如下：

1、系統管理員：整個系統管理工作由系統管理員負責，不僅具有對各個模塊的增、刪、改、查的權限，也具有對普通用戶管理的權限。

2、普通用戶：除管理員外，成功登錄本系統的其他用戶。普通用戶也具有對各個模塊的增、刪、改、查的權限，不具備用戶管理、系統設置權限。

兩種用戶均須成功登錄，方可具有權限使用該系統。

4.1.2系統功能需求

為了準確地確定目標系統必須做什么，在認真熟悉廣電發射傳輸中心的業務流程后，得出了系統的功能組織結構圖，如圖 4-1 和圖 4-2 所示。其中系統的信息管理具有三個子模塊：播出記錄管理、技術資料管理、維護記錄管理、專業訓練管理、器材管理。

圖 4-1 系統功能圖

圖4-2 系統整體流程圖

表 4-1 信息管理系統模塊劃分表

子模塊中文名稱業務職能

用戶操作登陸用戶輸入用戶名，密碼和驗證碼系統正確的處理判斷，如果輸入信息正確，系統進入相應管理界面，如果錯誤則提示錯誤信息。

修改信息修改用戶自己的密碼。

用戶管理添加、刪除、修改操作員，包括用戶名、密碼、姓名、職務等基本的信息資料。

系統配置系統設置設置系統服務器IP地址或域名、設置外圍器件連接信息，并保存相關系統設置，系統啟動后默認導入上次系統設置。

日志查看系統運行過程中重要事件和錯誤記錄日志，包括用戶登陸、重要操作記錄、系統異常信息記錄等。

信息管理播出記錄增加、修改、查詢、瀏覽每日設備工作數據，是對播出情況進行記錄管理的模塊。

技術資料對設備資料、技術方案等進行記載存檔，可增加、刪除、查詢、瀏覽。

維護記錄檢修維護是對設備檢修信息進行細致管理，將檢修信息上傳之后快速查找。督促執行情況。

專業訓練專業訓練主要是對廣電發射傳輸中心業務操作的方案，上傳到系統中進行快速查找。監督執行情況。

器材管理該模塊主要是對廣電發射傳輸中心各種器材的入庫和出庫記錄的錄入和查看。把查詢獲得的數據導出到外部文件，以Excel文件等形式。

1、播出記錄需求

播出記錄管理是指對廣電發射傳輸中心的各年播出情況、事故記錄進行管理如圖 4-3 所示。

圖 4-3 播出情況模塊功能圖

2、技術資料需求技術資料包括增加、刪除、查詢、瀏覽四個功能，該模塊是針對固定設備功能說明、技術創新應用說明，如圖 4-4所示。

圖 4-4 技術資料模塊功能圖

3、維護記錄模塊檢修維護管理是指對廣電發射傳輸中心的備檢修信息進行細致管理，將檢修信息上傳之后快速查找。督促執行情況，如圖 4-5 所示。

圖 4-5 維護記錄模塊功能圖

4、專業訓練模塊專業訓練管理是指對廣電發射傳輸中心的訓練計劃、理論學習、應急演練專業考核進行管理，如圖 4-6 所示。

專業訓練

增加

刪除瀏覽

圖 4-6 專業訓練模塊功能圖

4.2系統非功能性需求

本系統的非功能性需求從系統的安全性著手的。

1、系統建立了權限的區分，不同的角色的權限不同，從而劃分了他們的不同功能，不同的角色具有不同的功能操作，從而限制系統的信息安全。

2、建立的日志文件，系統可以通過日志文件監控系統的操作，它主要記錄了用戶及管理員對系統數據的操作。日志文件會記錄系統對數據庫表做的增刪改查, 以及對那張表進行了操作，從而能夠保證系統在發生異常情況的時候，我們可以根據日志文件查看發生異常時刻的情況。

4.3本章小結

本章主要介紹了廣電發射傳輸中心信息管理系統的需求，包括用戶需求、系

統功能需求和非功能需求，輔以功能圖展示了各功能模塊實現需求，得出開發該

系統是必要的，也是可行的。同時也為下一章的整體系統功能設計提供了設計分析依據。

第五章廣電發射傳輸中心信息管理系統的詳細設計

系統的詳細設計是對系統的界面展示、各個模塊如何實現，系統的數據庫如何設計進行研究。

5.1界面構思對于一個系統而言，系統的外觀經常是最先被注意到的，因此系統的第一印象有賴于系統的界面是否友好與吸引人。所以對設計人員來說，界面設計至關重要。

界面設計有以下幾點原則：

1、洞察用戶的心理狀態：了解客戶喜好和操作習慣，有助于網頁頁面的設計被用戶認可。

2、 3C 原則：

簡潔(concise)、一致性(consistent)、對比度 (contrast)。

3、統一的整體形象：

當 Web 網站標識以及網頁設計方案確定好后，就不要輕易更改確保同意，用戶才不會產生混亂，留下統一的深刻形象。

4、內容與形式的統一：

內容包括 Web 的基本信息(菜單、數據顯示等)，形式包括了網頁設計的構圖(包括顏色、位置坐標等)。網頁的形式單方面來講是具有藝術規律的，但是又是為內容服務，所以不能為了藝術體現而忽略實用性、宣傳性，總的說來 Web 設計的目的就是根據用戶基本情況來設計更加形象、直觀，更符合用戶的網頁界面。

本系統的用戶要求界面大氣、沉穩，簡潔易操作。另外，普通用戶在使用該系統時，是在觸屏機上操作的，因此界面要夠立體化，可以通過使用Photoshop制作按鈕來達到這一效果。同時，還要兼顧管理員在普通電腦上的操作，因此界面既要有立體化的效果，又要方便在普通電腦上操作。下面從界面布局、色彩、按鈕三個方面來闡述本系統界面的構思。

1、界面布局：

Web 設計中，整體布局應盡量風格清晰一致，方便客戶閱讀識別。優秀的作品總是用一些小技巧使語言視覺化，色彩簡潔，重點突出。鑒于用戶在觸屏機上操作，為使頁面結構清晰，提高其可操作性，整體布局不同于我們平時常用的

“同”字、“國”字、“川”字形等其他布局方式，而是采取了簡單明了的原則，盡量減少不必要的內容，整體布局圖如5-1 所示，頂部為標題，屏幕中間顯示具體的內容，其中左側為菜單，右側顯示內容，為方便使用，左側菜單欄是可隱藏的（隱藏后如圖 5-2 所示），底部為返回上一頁、返回主頁按鈕。這樣布局的好處是結構清晰、簡潔明了，用戶易操作。

Web標題 Web標題

菜單欄主體內容主體內容

圖 5-1 整體布局圖圖 5-2 左側菜單欄隱藏后的布局圖

2、界面色彩：

顏色元素在網站的感知和展示上扮演著重要的角色。不同的色彩搭配產生不同的效果，并可能影響到訪問者的情緒。由于該系統是軍隊企業使用，色彩搭配上應該盡量簡單，避免色彩過于艷麗。目前國內多數網站色彩基調以藍色為主，例如，騰訊、天涯、優酷等，而且在觸摸屏上使用的系統也經常使用藍色調，如移動自動繳費機終端。而且藍色是一個和天空、海洋相聯系的自然色，給人以穩定、信任、能量的感覺，很適合軍隊企業網站，因此本系統的主體色調以藍色為基準。

3、界面按鈕：

按鈕是每一個網站的必要組件，通過按鈕來導航，可以方便用戶進行操作。同時，通過選擇合適的按鈕，可以和頁面一起達到一個很好的視覺效果。即使用戶僅僅瞥一眼，所選擇的按鈕及他們在界面中所放置的位置也能帶來一個清晰的信息，易于查看和導航，是網站完善的標志。為了滿足用戶對界面立體化的需求，

我們用PS軟件制作了一些按鈕，使界面更具立體感。同時，按鈕都使用藍色系，

這樣使得整個網站色調統一，簡單干凈。

5.2系統總體構架設計

通過對相關的文獻進行分析，并結合軟件開發的相關理論的基礎上，本系統的開發采用 C/S 結構，包含用戶管理、播出記錄管理、技術資料管理、器材管理、系統配置等功能。運用主流的軟件開發模式，設計和實現了發射傳輸中心信息管理系統。系統物理結構圖如圖 5-3 所示。

Windows XP運行平臺

圖5-3 系統總體架構圖

5.3系統各層構架設計

信息管理系統由三個層組成，分別為WEB表示層、業務邏輯層和數據適配層, 如圖 5-4 所示。

5.3.1 WEB 表示層設計

UI層主要包含四個大的功能模塊，包括用戶操作、系統管理、和幫助。UI層

整體結構圖如圖 5-5 所示。

1、用戶操作面對領導、管理人員、操作人員，采取門戶中間件設置信息門戶，提供統一的多渠道的訪問信息門戶。該系統的建設過程中，考慮到系統的部分使用者是通過公用的網絡來對系統進行訪問，所以本系統格外注意數據以及訪問的安全［21］，主要的功能包括：

(1)用戶登錄界面統一

本系統所有用戶都是從統一的登錄界面進入系統，便于用戶熟練使用本系統。

圖 5-4 系統體系結構圖

圖 5-5 UI 層整體結構圖

（2）用戶個性化應用界面本系統還設置了個性化的功能，不同的用戶可以自行設定界面的風格以及業

務，以滿足用戶個性化的需求。

（3）信息集成本系統將不同的業務及數據信息集成到一個統一的顯示界面，便于用戶進行

交互操作。

（4）用戶檔案統一

本系統使用混合的身份認證體系，用戶只需要使用以套身份信息就可以實現在不同的應用程序之間的訪問，系統會自行處理和識別來自不同應用程序的不同身份的用戶。

2、信息管理

在操作員登陸系統后，選擇信息管理菜單欄下的二級菜單播出記錄管理、技術資料管理、維護記錄、專業訓練和器材管理進行操作。

3、系統管理

系統管理菜單欄包括系統設置二級菜單欄；日志查看二級菜單欄（日志欄）。實現系統的基本參數信息、網絡管理和日志查看功能。

4、幫助

幫助菜單欄包括關于系統二級菜單欄，其功能實現信息管理系統的基本說明、操作指引。

5.3.2業務邏輯層設計

業務邏輯層針對表示層提交的請求，進行邏輯處理，如果需要訪問數據庫，就調用數據適配層的操作，對數據庫進行操作。在業務邏輯層中，向用戶提供管理業務和庫存業務的請求處理。管理業務包括用戶的管理，升級以及授權的管理；器材管理包括出入庫管理和庫存管理操作，將器材管理操作統一封裝在一個類中，向上層應用提供的調用接口是統一。業務邏輯層的結構圖如圖 5-6 所示：

1、用戶管理主要包含用戶登錄、退出，用戶的添加，修改，刪除，查詢等主要功能。

2、信息管理

封裝在Storage Core接口中，由Storage Core接口管理整信息，由Storage In Out Manage 類提供調用接口給上層應用。數據庫操作部分會調用數據庫操作接口 DBAdapter。

5.3.3數據適配層設計

數據適配層主要完成向業務邏輯層提供與后臺數據庫、本地日記（配置）文件。

包括數據庫相關操作、日志文件的操作、配置文件的操作和數據的 MD5 加密操作。

1、數據庫

數據庫系統，存儲有系統信息、審計信息和日志信息，操作的內容。數據庫類型為針對客戶的數據庫。

2、MD5 加密

Unix、數字簽名和各類BSD系統登陸密碼認證通常都采用的MD5加密。該方式可以避免用戶的密碼被具有系統管理員權限的用戶知曉。

3、日記記錄

主要保存系統的日志信息，用戶可以便捷、靈活的管理這些日志文件。

4、配置文件操作

主要是向上層應用提供配置文件各項信息的讀取和修改。

作為廣電發射傳輸中心信息管理系統的門戶，系統采用了統一的用戶、權限、等技術來保證其安全。

5.4 系統數據庫設計

5.4.1 數據庫 E-R 圖

根據廣電發射傳輸中心信息管理系統需求，設計出如圖 5-8 所示的實體-關系

模型（E-R）圖。

圖5-8 廣電發射傳輸中心信息管理系統 E-R 圖

5.4.2數據庫表設計

數據庫的邏輯設計，即把設計得到的概念數據庫模式變為邏輯數據模式，它依賴于DBMS。根據廣電發射傳輸中心信息管理系統的需求分析及數據庫的設計, 先建立數據庫為 system_db, 建庫語句：Create database information system_db；部分設計表結構，如下表所示：

1、用戶信息表，主要是存放用戶的基本信息，如表5-1所示：

表5-1用戶信息表(usertbl)

列名數據類型是否允許為空說明

UID varchar（100）否主鍵

name varchar（50）是用戶名

department varchar（50）是部門

password varchar（50）是密碼

director varchar（50）是職務

permission int（11）是權限(用戶，管理員)

remark varchar （2000）是備注

2、技術資料信息表，主要是存放文檔資料，如表 5-2 所示：

表 5-2 技術資料信息表 (goodstbl)

列名數據類型是否允許為空說明

name varchar(50) 否標題

date varchar(50) 是日期

contentId int(11) 是正文ID

Photo varchar (1000) 是圖片

3、播出記錄信息表，主要存放日常巡檢發射機的參數信息，如表 5-3 所示：

表 5-3 播出記錄信息表( recordtbl )

列名數據類型是否允許為空說明

Time varchar( 100) 否記錄時間

userId int( 11 ) 否頻率

Pt int( 11 ) 否發射功率

Pr int( 11 ) 否反射功率

U int( 11 ) 是電壓(I、II、III)

I int(11) 是電流(I、II、III)

4、維護記錄信息表，主要是日常維護檢修內容記載，如表 5-4 所示：

表 5-4 維護記錄信息表 (repairstbl)

列名數據類型是否允許為空說明

name varchar( 50) 否名稱

contentId int( 11 ) 是正文ID

officer varchar( 50) 是維護人員

date varchar(50) 是日期

5、專業訓練信息表，主要是專業訓練教案和訓練基本執行情況，如表5-5 所

示：

表 5-5 專業訓練信息表 (coursetbl)

列名數據類型是否允許為空說明

Title varchar( 200) 否題目

Time varchar(50) 是課時

Leader varchar(50) 是講師

date varchar(50) 是時間

contentId int (11) 是正文ID

6、器材信息表，主要存放備品、工具的數量及使用情況，如表5-6所示：

表5-6器材信息表（goodstbl）

列名數據類型是否允許為空說明

Product model varchar(50) 是型號

typeId int(11) 是類型

name varchar(50) 是名稱

num int(11) 是數量

date varchar(50) 是時間

State varchar (1000) 是狀態

5.4.3連接數據庫設計連接數據庫時，首先通過數據庫連接字符串（需要從配置文件中獲取）連接數據庫。連接字符串需要這些內容：數據庫Date Source （域名），數據庫名稱，數據庫UserID和Password□數據庫連接字符串可以在系統界面進行配置。數據庫連接字符串在配置文件的格式如下所示。

<add key= 〞 SQL_ConnectStringvalue= 〞 Data Source=172.168.1.120;Initial

Catalog=PTCBT;User ID=hs;Password=hs〞/>

5.5本章小結

本章任務主要是廣電發射傳輸中心信息管理系統的總體功能、總體架構設計，

并分析討論系統的WEB表示層、業務處理層、數據訪問層3層架構設計和數據庫的功能設計。通過系統總體功能和架構設計研究，為下一章的廣電發射傳輸中心信息管理系統的具體實現提供了設計分析依據。

第六章廣電發射傳輸中心信息管理系統實現

本章主要介紹廣電發射傳輸中心信息管理系統模塊的具體實現過程，實現的主界面圖及相關關鍵代碼。

6.1系統的開發環境

本系統設計采用Struts，Spring，Hibernate三種開源框架，J2EE架構、MySQL 數據庫，按實現流程進行模塊劃分。從系統的升級和維護方面考慮，在設計開發過程中，經過分析比較選擇了較為簡單的Tomcat6.0服務器。以下是系統的開發環境：

開發工具：MyEclipse &5

數據庫： MySQL Server 5.5

服務器軟件： Apache-tomcat-6.0.14

JDK 版本： JDK Version1.6.0.07

操作系統： Windows Server2003

開發框架：Struts2+Spring+Hibernate

6.2系統模塊的實現

6.2.1登陸功能的實現登陸功能實現用戶登陸系統時，數據庫對用戶輸入的用戶名和密碼的進行檢測驗證，判斷是否允許用戶進入到主系統界面。如圖 6-1 所示，普通用戶和管理員登陸流程圖。系統登陸界面如圖6-2所示。

點擊“登陸”登陸系統，出現當天播出情況的主界面如 6-3所示，關閉頁面，可直接退出。

關于登陸的代碼，都比較通用，此處引用一小段： if(message.get(name).equals(password))〃密碼正確

{

JOptionPane.showMessageDialog(Login.this, "登陸成功!");

System.exit(0);

Else

num--;

圖6-1 用戶登陸流程圖

■ —丄 _ . r _ - —— 一—— ■ •

圖 6-3 主界面

6.2.2用戶操作模塊的實現

用戶操作，針對普通用戶來講是個人密碼修改，針對管理員來說，還有增加刪除、修改普通用戶的權限。其流程圖如圖 6-4 所示。

修改信息

輸入修改的

信息內容

點擊“修改”

修改成功

點擊按鈕“用戶操作”選擇下拉菜單“修改信息”，如圖 6-5 所示。

圖 6-5 用戶操作的下拉菜單界面

修改信息完成后，點擊“修改”，等系統確認修改成功，可繼續選擇其他功能操作，修改信息界面如圖 6-6 所示。

「展勒碰_ 系統配鱉信總育理幫助

修改取消

修改信，

選擇“用戶管理”進入如圖 6-7 和圖6-8所示，用戶管理是指具有權限的管理人員對一般的操作人員信息進行管理。

圖 6-8 用戶管理界面

用戶新增關鍵代碼，如下：

@Override

public SysUserVo create(SysUserVo vo){

// 判斷賬號是否重復

if (userRep.countUsername(vo.getUserName()) >= 1) {

*當count== 1時，判斷更改的是否為update數據

List<SysUser> listusers = userRep.findUserByUsername(vo .getUserName());

for (SysUser user : listusers) {

if (!user.getId().equals(vo.getId())) {

throw new DzrqException(Code.E_SYS_004);

}

if (vo.getType() != null && vo.getType().equals(2)) { vo.setStatus(Constant.ACCOUNT_START); vo.setEditDefPasable(false); vo.setPassword(MD5Helper.getMD5OfString(vo.getPassword()));

}

if (vo.getId() == null) { vo.setStatus(Constant.ACCOUNT_STOP);

// 新增用戶 logService.addLog(SysLogType.XTGL_YHQX_01_OPER_CREATEUSER,this.g etHostip(), new String[] { vo.getUserName() });

}

return super.save(vo);

}

6.2.3系統管理模塊的實現

點擊“系統配置”，如圖 6-9 所示，進入“系統設置”進行 IP 地址、設置服務器 IP 地址或域名、設置外圍器件連接信息，并保存相關系統設置，系統啟動后

默認導入上次系統設置。

點擊“系統配置”，進入“日志查看”，主要記載系統運行過程中重要事件和

錯誤記錄日志，包括用戶登陸、重要操作記錄、系統異常信息記錄等。如圖 6-10

和圖 6-11 所示。

系統設置

填寫/修改的

信息內容

點擊“保存”

保存新的配置信息

圖6-9 系統設置流程圖

圖 6-10 日志查看流程圖

圖6-11 系統配置的菜單界面

關于日志實現的關鍵代碼：

private String id;

private String hostip;// 主機IP

private String subsystem;// 子系統名稱（一級菜單）

private String menuname;// 菜單名稱

private String desc;// 操作內容

private Integer logType;// 日志類型（1:系統日志，2:登錄日志）

private String dataEntity;// 數據表

private String dataId;// 數據ID

private String operation;//操作類型

private Integer loginStatus;//登錄日志狀態（1:在線，2:退出，3:超時強退） private Date loginTime;// 登錄時間

private Date loginOutTime;// 退出時間

6.2.4播出記錄模塊的實現信息管理模塊分別有播出記錄管理、技術資料管理和器材管理三個二級菜單點擊信息管理出現這三個菜單的下拉框。

播出記錄是無線發射的日常記錄，是相關的工作人員接觸最多的菜單，播出

記錄包括：增加、修改、查詢、在線瀏覽等功能，如圖 6-12 和圖 6-13 所示。

圖 6-13 播出記錄模塊界面

我們在JSP頁面中設置一個input,在其中輸入年份，然后在input的button 標簽中添加點擊事件，輸入年份點擊“查詢”是就會調用 JavaScript 中的 searchchart( "getmonthchart”)方法，同時將調用的方法中的參數Action傳遞到 JavaScript中，然后用Ajax將數據調用到前臺，并且將year通過$(“year”).val調用到了 JavaScript 中，它通過 jQuery 將 input 中的數據進行獲取，然后通過 Ajax 將 year傳到后臺進行數據查詢，在將數據返回。查詢播出記錄實現的關鍵代碼： <div>

按年份查詢

</div >

通過SSH框架在Action中的得到的值無法直接被前臺使用，所以我們將數據轉換為JSON對象傳遞到前臺，其次在action中的要將這個JSON對象進行保存，在 action中result的type要為json,并且param應該為recordObj, recordObj存儲了查到的數據[9],有一點值得關注，如果沒有修改它，就無法在前臺使用recordObj中的數據，一般struts中的package中extends為struts-default,但是如果使用了JSON對象，就要將extends改為json-default。查詢每月記錄的后臺代碼：

/ double sumTime = 0.00;

for (int j = 0; j < brs.size(); j++) {

sumTime += brs.get(j).getTime();

}

double monthTarget=broadcast_RecordsService.inmonthtarget(year, String.valueOf(i+1));

target[i]=((monthTarget-sumTime)/monthTarget)*100; //查詢到的數據 }

this.recordObj.put("result", "success");//成功返回 success this.recordObj.put("target",target);

return "success";

} catch (Exception ex) {

ex.printStackTrace();

}

this.recordObj.put("result", "error");

return "error";// 錯誤返回 e rror

}

將數據成功傳遞到前臺之后，這個數據不能被 kendo 直接使用，首先我們要分析 kendo chart 的數據類型和格式，通過測試得到一個 kendo 數據中是兩個 object， kendo 使用的靜態數據的數據構造格式代碼：

var seriesData=[{record:"100.00",month:"1"}, //kendo bar chart 的數據

{record:"100.00",month:"1"}, 結構

{record:"100.00",month:"1"}]

6.2.5技術資料模塊的實現

技術資料是為了讓工作人員對設備及信號系統有一個更好的了解，便于日常管理學習。在安全播出時，如遇到信號系統故障時，能較為準確的推斷出事故原因，并對此有一個規范的處理措施，如圖 6-14 所示。

在信息管理下拉菜單中，選擇技術資料進入，如圖 6-15 所示。

圖6-15 技術資料界面

我們可以選擇其中一個文獻標題，雙擊進行在線閱讀，如圖6-16 所示。繼續

閱讀，點擊“下一頁

圖 6-16 在線閱讀技術資料界面

Word文檔上傳，首先使用OpenOffice將Word文檔轉換為PDF文檔，然后使用pdf2swf將PDF文檔轉換為SWF文檔，最后，再使用FlexPaper來瀏覽SWF文檔。

為完成文檔類型之間的轉換，服務器端需要安裝OpenOffice和pdf2swf這兩個軟件。且項目運行時需要啟動OpenOffice服務，以OpenOffice安裝在C:\Program Files 目錄下為例，在系統命令窗口執行以下命令：

cd C:\Program Files\OpenOffice.org 3\program

soffice -headless -accept="socket,host=127.0.0.1,port=8100;urp;" -nofirststartwizard

啟動 8100 端口的 OpenOffice 服務。

將Word文檔轉為SWF文檔的關鍵代碼為：

1)首先，創建同名但文件后綴名不同的三個文檔：

String docFilename= fileName + ".doc";//doc 名稱

String pdfFilename= fileName + ".pdf";//pdf名稱

String swfFilename= fileName + ".swf";//swf名稱 sourceFile = new File(realPath,docFilename); //WORD 文檔 pdfFile = new File(realPath,pdfFilename); //PD F 文檔 swfFile = new File(realPath,swfFilename); //SWF 文檔

2)然后，將 Word 文檔轉為 PDF 文檔:

//若WORD文檔存在則進行轉換

if(sourceFile.exists())

{

〃創建連接，以便使用OpenOffice軟件

OpenOfficeConnection connection = new SocketOpenOfficeConnection(8100);

try {

connection.connect();

DocumentConverter converter = new

OpenOfficeDocumentConverter(connection);

converter.convert(sourceFile, pdfFile); //開始轉換 pdfFile.createNewFile();

connection.disconnect();〃斷開連接

〃若Openoffice軟件沒啟動，會拋出異常，不能完成轉換

catch (java.net.ConnectException e) {

e.printStackTrace();

throw e;

}

3)最后，將 PDF 文檔轉為 SWF 文檔:

〃若PD F文檔存在則進行轉換

if(pdfFile.exists())

{

try {

〃使用安裝好的pdf2swf軟件將PDF文檔轉換為SWF文檔

Process p = r.exec("D:/Program Files/SWFTools/pdf2swf.exe " + pdfFile.getPath() + " -o " + swfFile.getPath() + " -T 9"); swfFile.createNewFile();

if(pdfFile.exists()) {

pdfFile.delete();

}//將中間文件PDF文件刪除,節約空間

}

把以上代碼封裝在 Action 層底下的 ConvertToSWF 類中的 convert 方法里，然后其他 Action 只要通過創建一個 ConvertToSWF 類的實例，并傳入文件名和文件路徑兩個參數調用其convert方法，就可實現從Word文檔到SWF文檔的轉換。

WORD 文檔到 SWF 文檔的轉換必須放在本地機的硬盤上進行，然后從本地機的硬盤上復制一份轉換好的 SWF 文檔，存放到當前服務器的目錄下。以下為

PaperAction的addPaper()方法的核心代碼。

ConvertToSWF c = new ConvertToSWF(); //創建一個新的

C onvertT o SWF的實例對象

String realPath = "D:/upload/QPaper"; //本地電腦磁盤下的目錄

〃當前服務器下的Qpaper目錄

String realPaths = ServletActionContext.getServletContext().getRealPath("/QPaper");

if(!new File(realPath).exists()){new File(realPath).mkdirs();}

if(!new File(realPaths).exists()){new File(realPaths).mkdirs();}

c. convert(realPath, pa.getName()); //將 WORD 格式文檔轉換為

SWF格式文檔

String Filename=pa.getName()+".swf";

File File1=new File(realPath,Filename);

File File2=new File(realPaths,Filename);

copy(File1,File2); //將保存在本地機上的D:/upload/Qpaper 目錄下的SWF文檔

復制一份，保存到當前服務器下的Qpaper目錄下

pa.setPaperAddr(realPaths); //設置該條記錄的文件路徑

pa.setName(Filename); //設置該條記錄的文件名

paperService.addPaper(pa); //添加這條記錄

在JSP頁面顯示SWF文件時，只需在頁面中引入flexpaper_flash.js，并使用 FlexPaperViewer來瀏覽SWF文件，即可完成該功能。以下為paper.j sp頁面使用 FlexPaper來瀏覽SWF文件的核心代碼，參數C${ctx}/QPaper/<%=(String)session .getAttribute("fileName")%>?num='+<%=randomNum%>)用來傳遞 SWF文件的路徑及文件名，并傳遞了一個隨機參數，傳遞隨機參數的目的是為了解決緩存讀取的問題。若沒有這個參數，用戶在刪除一條技術資料記錄，并重新上傳一個名稱相同的技術資料后，雖然新上傳的技術資料已經覆蓋了服務器上的舊技術資料，但在瀏覽器端用戶看到的仍然是舊的技術資料，這是因為兩次傳遞的參數一樣，瀏覽器會直接從緩存中讀取文件，而不是服務器。在加入一個隨機數參數后，兩次傳遞的參數不一樣，故瀏覽器會重新從服務器端讀取文件。

〃使用 FlexPaperViewer 瀏覽 swf文件

var fp = new FlexPaperViewer(

'FlexPaperViewer',

'viewerPlaceHolder', { config : {

SwfFile :escape('${ctx}/QPaper/<%=(String)session.getAttribute("fileName")%>?num ='+<%=randomNum%>)}}); 〃傳遞swf文件名以及一個隨機參數

6.2.6維護記錄模塊的實現

設備在日常使用過程中，在長時間工作、磨損、腐蝕等因素的作用下，功能與精確度逐漸降低。為了充分發揮設備的效能，延長設備使用壽命，要對設備進行科學的維護及檢修，確保安全播出。所以設備的檢修維護在這個安全播出工作

中顯得尤為重要。設備的維護記錄包括了：增加、刪除、查詢，如圖 6-18 所示其界面圖如圖 6-19 所示。

圖 6-18 維護記錄流程圖

圖 6-19 維護記錄界面圖

該系統實現每個功能中有增加、刪除、查詢、瀏覽的功能屬性實現，有個別

不盡相同，但它們的屬性名和屬性類型差不多都是一樣的。我們可以用對象屬性

拷貝進行轉換，更為便捷的實現，其關鍵代碼如下：

/**

*@Title copyPropertiesForListElements

*@Description 拷貝一個集合中的實體元素的屬性到一個新的元素類型的集合

*@param targetClass

*@param origList

*@param depth 拷貝深度

*@param filterNames 過濾參數，參數方式為{className}.{fieldName},比如 UserV o中的name屬性不需要過濾則寫為UserVo.name

*@return

@SuppressWarnings({ "rawtypes", "unchecked" })

public static List copyPropertiesForListElements(Class targetClass, Collection origList, int depth, String[] filterNames){

List destList = new ArrayList();

for(Object obj:origList){

Object dest = targetClass.newInstance();

dest = copyProperties(dest, obj, depth, filterNames); destList.add(dest);

} catch (InstantiationException e) {

e.printStackTrace();

} catch (IllegalAccessException e) {

e.printStackTrace();

}

return destList;

}

6.2.7專業訓練模塊的實現

廣播電視的無線發射傳輸，是黨和政府的喉舌，提高工作人員的專業能力也必不可少，人才才是安全播出中的骨干力量，他們與時俱進，專業知識豐富，可以解決無線發射傳輸的技術問題。因此根據行業的需求，培養技術型人才是必須的，可以不斷適應無線發射傳輸的發展需求。其包括了：增加、刪除、在線閱讀，其流程圖如圖 6-20 所示，界面截圖如圖 6-21 所示。

創建專業訓練計劃

確定專業訓練內容

圖 6-20 專業訓練流程圖

圖 6-21 專業訓練界面圖雙擊目錄中的某項，進行培訓內容閱讀，如圖 6-22 所示，選擇“瀏覽”回到目錄頁。

圖6-22 專業訓練培訓內容截面圖

在專業訓練時，我們的培訓內容有可能涉及到圖片，對此，我們需要對圖片進行一個轉換的編輯，圖片文件序列化其代碼如下所示：

/**

* @author 圖片文件序列化

public class ImageUtils {

/**

*將圖片文件的哈希字符串數據轉化為字節數組

*@param message 圖片文件的哈希字符串值

*@return 圖片的字節數組

public static byte[] convertFromBaseHexString( String message ){ byte[] data = new byte[message.length( ) / 2 ]; for( int index = 0; index < data.length; index++ ){

String byteString = message.substring( 2 * index, 2 * index + 2 ); int byte Value = Integer.parseInt( byteString, 16); data[index] = (byte)byteValue;

}

return data;

*將圖片文件的字節數組轉化為哈希字符串

*@param data 字節數組

*@return 哈希字符串

public static String convertToBaseHexString( byte[] data ){ StringBuffer buffer = new StringBuffer( ); for( int index = 0; index < data.length; index++ ){

String plainText = Integer.toHexString( 0xff & data[index] ); if( plainText.length( ) < 2 ) plainText = "0" + plainText;

buffer.append( plainText );

}

return buffer.toString();

}

6.2.8器材管理模塊的實現

器材管理是廣電無線發射傳輸中心管理系統的一個重要組成部分，這里的器材主要指備品備件和工具。從器材進入單位開始建立入庫，在日常檢修維護中需要使用就會存在借或直接替換舊器材，并在每月每季度每年進行盤點。它包括入庫記錄和出庫記錄，如圖6-23所示，其實現界面如 6-24 所示。

器材管理

圖 6-23 器材管理流程圖

圖 6-24 器材管理界面

在器材管理中我們對器材有一個數據統計，其統計所用到的數據表配置情況

代碼如下：

<hibernate-configuration> //廣電發射傳輸中心信息管理系統器材管理用到的三

張表

<session-factory>

</session-factory>

</hibernate-configuration>

6.3 本章小結

本章主要介紹了基于SSH框架，廣電發射傳輸中心信息管理系統的功能實現, 通過流程圖介紹、實現界面截圖、關鍵代碼等方式，詳細闡述了廣電發射傳輸中心信息管理系統的實現。

第七章系統測試

軟件測試已是現在軟件開發必不可少的工作，它為一款軟件是否能夠被使用給出評判，軟件功能正確性影響著一個企業信息的正確性，如果軟件管理的信息出現錯誤，那就會造成不可估量的損失，所以軟件測試工作是一個認真嚴謹的工作，在測試過程不能錯過任何一個小的功能，要做到對他全面系統的測試，通過各種不同的測試方法，將最后的測試結果進行結合，判定功能的正確性，保證軟件功能的正確。軟件測試是為了發現程序的錯誤而制定的，測試方式的好壞，決定著軟件的質量。測試不僅僅是找出錯誤，更重要的是它可以幫助項目管理者發現當前軟件開發過程中的缺陷，以便及時改進，它可以幫助開發人員更好的提高軟件的質量，針對本系統將編寫測試用例并對功能測試進行軟件質量的分析。

7.1測試目的

系統測試是每一個軟件開發流程中的重要構成內容，是確認和檢測開發程序功能、性能是否滿足設計要求的重要步驟。有如下幾個目的：

1、盡可能多的發現軟件中隱藏缺陷。

2、形成報告為軟件質量的評價提供支持。

3、通過分析為軟件開發過程的改進提供幫助。

4、通過驗測對軟件工程項目進行驗證與確認。

7.2測試方法

1、按程序執行過程可以分為靜態測試和動態測試。

靜態測試是不動態執行程序代碼而尋找程序代碼中可能存在的錯誤或評估程序代碼的過程。它可以由人工進行，充分發揮人的邏輯思維優勢。可以借助軟件

工具自動進行（如Codesmart格式化代碼工具）。靜態測試包括代碼復查、靜態結構分析、代碼質量度量等。實際運行被測試程序，取得程序運行的真實情況、動態情況，進而進行分析。必須生成測試數據來運行程序，測試質量依賴于測試數據。生成測試數據、分析測試結果工作量大，使開展測試工作費時、費力、費人。

動態測試中涉及多方面工作，人員多、設備多、數據多，要求有較好的管理和工作規程。動態測試需要考慮的多種類型：白盒、黑盒、單元、累積綜合、集

成、功能、系統、端到端、健全、衰竭、負載、強迫、性能、可用性、安裝／卸載、恢復、安全、兼容、比較、 Alpha 、 Bate 測試。

2、按階段活動過程可分為單元測試，集成測試，系統測試，驗收測試。

3、按測試理念可分為白盒測試，黑盒測試，灰盒測試。在本文我們測試主要用到的是黑盒測試。

7.3測試內容

廣電發射傳輸中心信息管理系統測試的主要內容是：

1、軟件運行是否正常，軟件退出時，是否提示保存及確認，特別是非正常關閉情況下，日志是否有記錄且數據是否有備份。

2、用戶端登錄界面是否友好，是否簡單、明了，便于操作。軟件安全性能否針對不同管理級別進行分別限制，達到提高軟件系統和數據庫安全目的。

3、軟件的數據庫數據的錄入、增加、刪除、修改等操作是否正常實現，數據庫的可維護性和動態更新是否同步進行。

4、系統的數據查詢和統計功能是否便捷快速，是否模糊匹配，較精準的給出結果。

5、數據庫是否提示數據溢出、越界情況等異常作業和突發情況告警，能否對用戶不規范操作警告。

6、軟件能否完成各種數據的打印預覽和打印操作。

7、數據類型假如填寫錯誤的情況下，系統能否及時報錯，且提示用戶正確填寫。

8、軟件是否兼容各種操作系統，是否具有可移植性。

7.4測試環境

軟件系統測試,通常需要在一個干凈的環境下進行，它分為硬件環境和軟件環境：

1、硬件環境

CPU：P4 3.0 以上；

內存：1GB以上

硬盤：硬盤 80G；

2、軟件環境

操作系統：Windows Server2003以上

瀏覽器：IE6.0

軟件：廣電發射傳輸中心信息管理系統軟件

7.5用戶測試

本文主要對系統進行黑盒測試，由于系統有較多模塊，這里列出部分測試用

例。

測試 1：用戶登錄用戶登錄測試用例如表 7-1 所示：

表7-1 用戶登錄測試用例

用例編號： 01 測試目的：測試登錄模塊是否正常

測試方法：編號操作結果

1 輸入正確的用戶名和密碼正常登錄系統

2 輸入不存在的用戶名警示用戶不存在

3 輸入錯誤的密碼警示密碼錯誤

前置條件：無測試纟士果：登錄模塊正常’在用戶名和密碼正確情況下能正常口登錄，出錯時能給出相應的提示，并返回重新登錄

測試 2：用戶注冊用戶注冊測試用例如表 7-2 所示

表7-2 用戶注冊測試用例

用例編號： 02 測試目的：測試注冊模塊是否正常

測試方法：編號操作結果

1 輸入可用的用戶名和密碼注冊成功

2 輸入己被注冊過的用戶名提示該用戶己存在

前置條件：無測試結果：注冊模塊正常，當輸入密碼和未被注冊過的用戶名時，注冊成功，當用戶名己被注冊過時，提示該用戶己存在

在用戶輸入密碼和未被注冊過的用戶名時，注冊成功，有如圖 7-1 的提示。

圖 7-1 用戶名已被注冊的提示

7.6功能測試

7.6.1播出記錄功能測試

1、測試用例

如表7-3所示，為播出記錄的測試用例，對播出記錄查詢功能進行測試用例的

驗證。

表 7-3 播出記錄查詢測試用例

用例編號 01

原型描述測試播出記錄查詢功能，主要被測試的頁面方法為 searChchart(),onSeriesClick(),onSeriesClicksA().

用例目的測試在輸入正確的日期下是否可以查到播出記錄測試在輸入錯誤的日期下是否有提示測試在無輸入條件時系統反應

前提條件系統中存在要查詢播出記錄勺亠白信息

子用例編號輸入期望結果實測情況

1.1 輸入一條正確的

信息

Year=2012 系統顯示了該年份中的所有

已被錄入的播出記錄信息。系統以表格的形式輸出了播出記錄

1.2 輸入錯誤的年份

格式

Year=error 系統無法查到該信息系統沒有輸出任何值，

并且提示輸入格式日期

格式錯誤

1.3 不輸入系統無任何結果輸出系統沒有輸出任何值，并且提示輸入值為空。

2、測試結果

選擇播出記錄進入模塊，如果進行查詢輸入為空，就會提示信息不正確，如果輸入不是年份，而是字母等信息時，系統提示年份格式不正確，如果輸入的年份比當前的年份大，系統查不到數據就會提示大于當前年份。

7.6.2技術資料功能測試

測試1：增加技術資料

增加技術資料測試用例如表 7-4 所示：

當必填項還未填寫完整，就點擊確定按鈕時，會彈出對話框，提示你輸入某

項信息。

表 7-4 增加技術資料測試用例

用例編號： 02 測試目的：測試增加技術資料是否正常

測試方法：編號操作結果

1 輸入必填項，點擊確定添加成功

2 某些必填項未填，點擊確定提示必填項必須填寫

前置條件：用戶以管理員身份成功登錄系統測試結果：功能正常，當必填項都寫入后，點擊確定，提示添加成功，若未填寫完整，則給出相應提示。

測試 2：刪除技術資料刪除技術資料如表 7-5 所示

表 7-5 刪除技術資料測試用例

用例編號： 03 測試目的：測試刪除技術資料是否正常

測試方法：編號操作結果

1 選中某條記錄，點擊“刪除選中技術資料”，在彈出的“確定刪除該記錄”對話框中選擇“確定” 刪除成功

2 選中某條

的“確記錄，點擊“刪除選中技術資料”，在彈出耳定刪除該記錄”對話框中選擇“取消” 刪除失敗

前置條件：用戶以管理員身份成功登錄系統測試結果：功能正常，當確定刪除時，成功刪除掉該條記錄，取消時，刪除失敗。

測試 3：查詢技術資料查詢技術資料如表 7-6 所示

表 7-6 查詢技術資料測試用例

用例編號： 04 測試目的：測試查詢技術資料是否正常

測試方法：編號操作結果

1 選擇需查詢的日期，點擊

“查詢”按鈕搜索結果列表頁中顯示該日期的記錄

前置條件：用戶成功登錄系統測試結果：查詢技術資料功能正常，能正確搜索相應日期的記錄

表 7-7 在線閱讀技術資料測試用例

用例編號： 05 測試目的：測試在線閱讀技術資料是否正常

測試方法：編號操作結果

1 點擊需要瀏覽的技術資料的; 標題鏈接顯示出對應的技術資料

前置條件：用戶成功登錄系統測試結果：在線閱讀技術資料功能正常，能正確顯示該技術資料

7.6.3維護記錄功能測試測試 5：增加維護記錄增加維護記錄用例如表 7-8 所示

表 7-8 增加維護記錄測試用例

用例編號： 06 測試目的：測試增加維護記錄是否正常

測試方法：編號操作結果

1 輸入必填項，點擊確定添加成功

2 某些必填項未填，點擊確定提示必填項必須填寫

前置條件：用戶以管理員身份成功登錄系統測試結果：功能正常，當必填項都寫入后，點擊確定，提示添加成功，若未填寫完整，則給出相應提示。

測試 6：刪除維護記錄刪除維護記錄如表 7-8 所示

表 7-9 刪除維護記錄測試用例

用例編號： 0 7 測試目的：測試刪除維護記錄是否正常

測試方法：編號操作結果

1 選中某條記錄，點擊“刪除選中維護記錄”，在彈出的“確定刪除該記錄”對話框中選擇“確定” 刪除

成功

2 選中某條記錄，點擊“刪除選中維護記錄”，在彈出的“確定刪除該記錄”對話框中選擇“取消” 刪除失敗

前置條件：用戶以管理員身份功能正常，當確定刪除時，成功刪除掉

成功登錄系統 ' ~口 ■ 該條記錄，取消時，刪除失敗。

表 7-10 查詢維護記錄測試用例

用例編號： 08 測試目的：測試查詢維護記錄是否正常

測試方法：編號操作結果

1 選擇需查詢的日期，點擊“查詢”按鈕顯示出對應的維護記錄

前置條件：用戶成功登錄系統測試結果：查詢技術資料功能正常，能正確搜索相應日期的記錄

7.6.4專業訓練功能測試測試 8：增加專業訓練增加專業訓練用例如表 7-11 所示

表 7-11 增加專業訓練測試用例

用例編號： 9 測試目的：測試增加專業訓練是否正常

測試方法：編號操作結果

1 輸入必填項，點擊確定添加成功

2 某些必填項未填，點擊確定提示必填項必須填寫

前置條件：用戶以管理員身份成功登錄系統測試結果：功能正常，當必填項都寫入后，點擊確定，提示添加成功，若未填寫完整，則給出相應提示。

測試 9：刪除專業訓練刪除專業訓練用例如表 7-12 所示

表 7-12 刪除專業訓練測試用例

用例編號： 1 0 測試目的：測試刪除專業訓練是否正常

測試方法：編號操作結果

1 選中某條記錄，點擊“刪除選中專業訓練”，在彈出的“確定刪除該記錄”對話框中選擇“確定” 刪除

成功

2 選中某條記錄，點擊“刪除選中專業訓練”，在彈出的“確定刪除該記錄”對話框中選擇“取消” 刪除失敗

前置條件：用戶以管理員身份測試結果：功能正常，當確定刪除時，成功刪除掉成功登錄系統該條記錄，取消時，刪除失敗。

測試 10：在線閱讀訓練教案

在線閱讀訓練教案如表7-1 3所示

表7-13 在線閱讀專業訓練教案測試用例

用例編號： 11 測試目的：測試在線閱讀專業訓練是否正常

測試方法：編號操作結果

1 點擊需要瀏覽的專業訓練的標題鏈接顯示出對應的專業訓練

前置條件：用戶成功登錄系統測試結果：在線閱讀操作訓練功能正常，能正確顯示該目錄

7.6.5器材管理功能測試測試 6：增加入庫記錄增加入庫記錄用例如表 7-14 所示

表 7-14 增加入庫記錄測試用例

用例編號： 12 測試目的：測試增加入庫記錄是否正常

測試方法：編號操作結果

1 輸入必填項，點擊確定添加成功

2 某些必填項未填，點擊確定提示必填項必須填寫

前置條件：用戶以管理員身份成功登錄系統測試結果：功能正常，當必填項都寫入后，點擊確定，提示添加成功，若未填寫完整，則給出相應提示。

測試 7：刪除入庫記錄刪除入庫記錄如表 7-15 所示

表7-15 刪除入庫記錄測試用例

用例編號： 1 3 測試目的：測試刪除操作訓練是否正常

測試方法：編號操作結果

1 選中某條記錄，點擊“刪除選中入庫記錄”，在彈出的“確定刪除該記錄”對話框中選擇“確定” 刪除成功

2 選中某條

的“確記錄，點擊“刪除選中入庫記錄”，在彈出

J定刪除該記錄”對話框中選擇“取消” 刪除失敗

前置條件：用戶以管理員身份成功登錄系統測試結果?功能正常，當確定刪除時’成功刪除掉 ' ~口 ■ 該條記錄，取消時，刪除失敗。

表 7-16 查詢器材庫存測試用例

用例編號： 14 測試目的：測試查詢器材庫存情況是否正常

測試方法：編號操作結果

1 輸入需查詢的器材名稱，點擊“查詢”按鈕搜索結果列表頁中顯示該器材使用情況

前置條件：用戶成功登錄系統測試結果：查詢器材庫存情況正常，能正確搜索相應名稱器材的記錄

7.7測試結果分析和說明

廣電發射傳輸中心信息管理系統的功能范圍包括：5 個功能模塊，設計測試用例 14 個，執行 14 個，從需求符合性、功能正確性及復雜的業務邏輯關系進行全面的用例設計，覆蓋了所有功能模塊。從問題來看，發現 57 個問題，57 個問題是在之前的版本測試中發現的，本輪測試只有一個問題被掛起，并未發現新的問題。問題的解決率達 97.2%，測試通過，目前功能滿足用戶需求。

7.8本章小結

本章主要介紹了，按照編寫的測試用例對本系統進行了用戶測試、功能測試，沒有致命性錯誤、嚴重、一般性錯誤，遺留的缺陷和未測試部分風險在可控范圍內，滿足設計需求，系統測試通過。

第八章總結和展望

8.1 論文總結

經過近 1 年代碼及論文書寫，畢業設計進入最后環節，廣電發射傳輸中心信息管理系統的功能已逐步實現。

在畢業設計中，本人自知知識面有限，認真學習、潛心思考并實踐，使本人對基于SSH框架及Java等相關的技術有了一定了解。本人做的是信息管理系統的設計與實現，從資料的查詢到設計的雛形，讓本人在有限的時間內對信息管理系統有了基本認知，積累了豐富的理論知識。經過需求分析，可行性分析，再到后來的 Java 配置環境，書寫代碼及其調試，讓本人作為一個用戶對該類系統的需求和軟件運行的環境有了一定了解。將之前學過的數據庫知識跟Java技術結合在一起，理論聯系實際，在實踐中鍛煉了本人分析處理問題的能力并激發了這方面的興趣。

通過這次畢業設計，本人鞏固了并加深了對軟件工程這門學科的認識，尤其讓本人在使用工程流程的各個階段有了進一步的了解，并相對獨立地完成各個階段的任務。通過這次設計還讓我明白了需求分析和概要設計是系統真正開發的關鍵，它規劃出系統的大致模塊和業務接口，流程轉換以及模塊之間的關系。如果概要設計不科學，將會導致之后的詳細設計工作出現冗余，目標不明確甚至失去方向。雖然在開發過程中受水平和時間所限，在設計中還有些欠缺或考慮不周全的地方，但這次畢業設計的經歷將對本人今后的學習和工作產生重大意義。

8.2工作展望

經過團隊的分工合作共同努力完成了廣電發射傳輸中心信息管理系統的開發，一年來，系統運行穩定可靠，達到最初設計要求。后續我們將從以下幾個方面進一步完善。

1、系統的播出記錄可視化，后續我們將設備的端口接入，直接采集設備運行時的數據，讓輸出更加直觀。

2、未來我們計劃外掛搭建視頻會議、設備監控、值班考勤系統等，讓系統更加完善，因此數據庫的設計有待改善。

3、數據庫的 SQL 語句進行優化提升數據的查詢效率，提升系統的整體運行效率，使數據顯示更加迅速。

4、代碼的優化。

致謝

在電子科技大學三年學習生活中，我得到了許多老師、同學、朋友和家人的

幫助，正是因為他們的真誠幫助，讓我度過了人生中最愉快的三年。

本文是在王占平副教授的悉心指導下完成的。王教授高超的學術水平、孜孜不倦的治學方式，和嚴謹的學術態度讓我受益良多。他對我的嚴格要求和耐心指導使我在學術之路上能邁過坎坷，繼續前行。從論文的開題到模塊的設計理念，王教授給我了啟發性的指導。在此對他表示最誠摯和最衷心的感謝！

同時也感謝學院王紅老師、周航老師在平時的學習生活中給予的關心、幫助和支持。

感謝我親愛的同學們、朋友們，每一次在我遇到問題的時候，都耐心的幫我拓展思維，得到更好的解決方案。

特別要感謝一直以來在生活和學習中默默關心我的家人，是他們無私的愛以

及諄諄教導，讓我克服了學習和生活中的每一個困難，取得了今天的成績。

最后感謝各位閱讀我論文的老師，謝謝你們在百忙之中來評閱論文。

參考文獻

[1]孫衛琴，Java Web開發技術詳解[M].北京：電子工業出版,201361-2

[2]孫一林，彭波.Java數據庫編程實例[M].清華大學出版社,2012.8:23-25

[3]涂繼亮，陶秋香.基于B/S模式的畢業設計雙向選題管理系統設計[J].現代計算機 2007,(1) 11-23

[4]三楊科技.Struts2核心技術與JavaEE框架整合開發實踐[M].北京：電子工業出版社, 2008

[5]劉祥穎.基于MVC框架的Struts框架實現校園網認證計費體系系統[D].天津工業大學 2007:45-52

[6]陳尚松，杜旭英，俞歡軍•基于Struts+Hibernate+Spring框架的畢業設計管理系統[J]. 計算機工程與設計，2008(1) :11-23

[7]Vinoski.S,CORBA:Intergrating Diverse Applications Within Distributed heterogenous Enviroment，IEEE Communication Magazine[J].1997.2:15-19

[8]陳鳳英，王加陽.基于Ajax的無刷新實時參考咨詢系統的設計實現[J].湖南科技學院學報，2008:11-23

[9]湛湘倩，狄文輝，孫冬.基于SSH框架與AJAX技術的Java Web應用開發[J].河南科技大學報，2009:11-23

[10]張鵬偉，陳景霞，張文平.Ext JS和SSH的Web應用構架的研究與實現[J].陜西科技大學報，2010:11-22

[11]Dennis Merritt，Archite chture for Embedded Intelligent Components[M]. 2011:64-69

[12]Dejan Sunderic，曹俊，姜龍芳.SQL Server 2005 T-SQL[M].北京：清華大學出版社， 2008-05:94-99

[13]翟高粵.SSH框架擴展與集成的研究[J].煤炭技術，2011,30(8):194-195.

[14]唐權，陶寧，陳印.基于SSH架構的CRUD應用設計[J].四川職業技術學院學報， 2010,20(4):113-115

[15]高洪巖.至簡SSH：精髓Java Web實用開發技術.電子工業出版社，2009:15-19

[16]冷悅，徐春雨.使用Use Case建模的幾個常見問題[J].中國科技信息，2009, (03) :30-36

[17][美[Microsoft Cooprataion,Application Architecture for .NET Designing Applications and Services[M].Microsoft Press,2002:107-165

[18]Aleander Repenning、Andri Ioannidou、Michele Payton、Wenming Ye and Jeremy Roschelle, Using Components for Rapid Distributed Software Development, Software[J]. Vol.18，NO.2, March-April 2001 :38-45

[19]Dennis Merritt, Architechture for Embedded Intelligent Components [M]. PC AI Magazine, 2001.1:35-49

[20]Vinoski.S,CORBA:Intergrating Diverse Applications Within Distributed heterogenous Enviroment，IEEE Communication Magazine[J]. 1997.2:15-19

[21]徐相林.基于ASP. NET技術的結構設計實現[J].電腦知識與技術,2008( 1) : 51-56

[22]李剛.Struts2權威指南一基于WebWork核心的MVC開發[M].北京：電子工業出版社， 2007.34-38

[23]鄧子云，肖鋒，謝英輝.精通J2EE網絡編程[M].北京:清華大學出版社,2005.12-23

[24]侯國照，李延斌，秦國，王金彪.Struts2的應用研究[J].中國高新技術企業 2008(17):12-23

[25]趙洋，張麗，王恩東，張素寧基于Struts,Hibernate和Spring的J2EE架構研究[J]. 現代電子技術,2009(2). 102-203

[26]Craig, Walls, Ryan, Breidenbach. Spring in action[M].人民郵電出版社,2006.34-45

[27]劉京華.Java Web 整合開發王者歸來(JSP+Servlet+Struts+Hibernate+Spring) [M].北京:清華大學出版社,2010.34-78

[28]徐小澤.基于J2EE和Hibernate構建個性化網絡信息檢索系統[D].上海交通大學,2006. 102-123

[29]陳開梅.基于MVC模式的株洲技術學院學生成績管理系統[D].湖南師范大學，2008,

50-60