高校學生綜合管理系統設計與實現

周寧

(北京青年政治學院學生處，北京 100102)

一、引言

本文以高校學生綜合管理系統為研究對象，通過對北京青年政治學院的學生管理現狀進行分析，利用軟件工程中面向對象的研究方法，解決高校學生管理中存在問題。本章主要介紹該課題的研究背景、目的及意義、國內外研究現狀以及本文的主要結構。

(一)課題背景

北京青年政治學院是北京市屬市管普通高等學校，現有教職員工330余人，在校學生4000余人。位居北京市朝陽區的望京地區，占地面積40多畝。另有東校區80畝，一年級學生就讀。北京青年政治學院下設11個教學系部(分院)，現有專業(方向)20余個。學生處負責全院的學生管理、招生以及就業等工作。

隨著學院規模的不斷擴大，學生人數急劇增長，需要管理的各種信息也成倍增長，由于計算機和網絡的普及，若建立一個B/S結構的學生信息管理系統，學生便可以通過網絡查詢自己的有關信息，使得學生信息管理工作系統化，規范化，自動化，大大提高了學院管理學生的效率。

學院學生處下設招生辦公室、就業指導中心、學生管理科、心理健康教育中心等多個科室，目前各科室都有各自獨立的管理信息系統，現存問題是，信息不能共享、系統不完善。為解決現存問題對于學生工作進行重新梳理、整合、建立一個統一的、完善的學生工作管理信息系統是當前的迫切需求。

項目的建設將有力改善北京青年政治學院的學生管理環境，從整體上提高學生工作管理部門、工作人員和全校學生通過網絡發送和接收有關信息的能力，開展在線的業務處理，支持按權限管理的各種申請、查詢和統計報表的輸出打印功能。

項目建設的主要內容包括:面向學生處全體師生，包括系統維護、思想教育管理、評獎評優管理、共青團工作管理、學生資助管理、勤工助學管理、對外交流管理、心理健康管理、違紀處分管理、招生管理、就業管理、日常事務管理、學生工作隊伍管理、班級管理、其他數據管理等子系統。

項目的近期目標是將北京青年政治學院在數字化校園統一數據平臺的基礎上與其他系統實現數據充分共享，為其他系統的接入開放數據接口。尤其是實現學生工作管理系統與一卡通系統之間的數據交換和業務互動。與教務管理系統、財務系統等相關系統聯動，實現入學前、入學、在校期間、畢業期間和畢業以后一條龍管理。

本項目將從教育信息數字化的角度探索學生工作開展的新途徑，支持學生工作管理部門、工作人員和全校學生通過網絡發送和接收有關信息，開展在線的業務處理，支持按權限管理的各種申請、查詢和統計報表的輸出打印功能。此項目的必要性和可行性如下:

(1)目前學生相關數據無法利用或利用不充分

信息化水平參差不齊，信息系統構造各異，導致學校的信息共享不暢、數據不標準、不統一，學生相關數據無法利用，工作環節銜接存在明顯的弊端。

(2)以管理為驅動，主要為管理者服務，而面向學生的主動式自助服務較少

傳統業務系統出發點是為管理者服務，提高管理者的工作效率，而為師生提供的服務是完成管理者收集和整理數據的環節，并未真正從學生的角度理解業務。

(3)原來與學生相關跨部門業務難以實現

當學生的相關業務辦理需要其他職能部門舊系統配合時，工作難度較大，因為跨職能部門的業務流程較復雜，流程中的數據轉換、業務辦理耗時較大，工作效率未得到有效提高，本項目將來與學院數字化平臺對接，實現資源共享。

(4)只記錄了學生課堂成績，無法展現學生綜合素質和能力

目前與學生學習相關的教務系統，只能記錄學生的課堂成績;無法在系統中體現學生的綜合素質情況。怎樣解決這些問題已經引起越來越多同行的關注。

(二)發展現狀

近些年來，在國家教育政策的支持下，各個高校的教育規模不斷的擴大，在此條件下目前手工管理的模式和單機管理的模式已經嚴重落后于目前的教育發展。在此條件下，隨著信息化技術的發展以及教育水平的整體提高，學生相關的信息管理系統軟件也成為了高等學校教學管理過程中的重要組成部分［1］。作為用戶信息查詢的主要手段，將會在高校學生相關管理政策制定中提供科學的數據依據。通過計算機對于學生日常信息的管理，與傳統的人工操作管理相比較，在檢索效率方面、存儲量方面、成本低廉等方面都具有不可比擬的優勢。所以，開發一個能夠適應新形勢下需要的高校學生信息管理系統是很有必要的［2］。

雖然，從整體上來看，我國高校已經基本上完成了信息化平臺的建設，但是仍然存在“重建設、輕應用”的現象。高校學生管理平臺的應用價值并沒有得到充分的體現。缺乏完善的教育管理軟件規范的指導，缺乏高質量信息管理軟件的支持，雖然各個院校都利用校園網絡完成了一部分的工作，但是從效率、質量以及規范化的程度上來看，都需要進一步提高。在學生管理領域，學生獎懲管理以及學生注冊等服務大多沿習傳統的管理模式，并沒有通過信息管理系統來提高學生管理的工作效率［3］。

其次，信息管理系統軟件設計的不規范，導致兼容性較差，也是高校信息化建設過程中所遇到的重點問題。目前，高校學生管理系統大多是從軟件公司購買，或者委托科研單位和公司進行研制，存在較多設計不規范問題，重復開發現象較為嚴重。因此，一個完整軟件規范的設計勢在必行。

(三)主要工作內容

作者作為該項目的主要參與人員，全程參與項目需求分析，系統設計與實現及測試上線的過程。本課題以高校學生管理為切入點，深入討論在高校學生管理系統軟件架構的搭建與實現。根據項目的不同階段，作者圍繞本科題進行以下內容的研究與實踐［4,5］:

1.首先需要對于當前高校學生管理系統的發展趨勢和研究現狀進行深入的調查研究，掌握在不同的情況下學生管理的實際需求和學生管理工作的特點，以軟件對于學生日常輔助管理的作用為出發點，進而分析系統設計的可行性。

2.從用戶的角度出發，通過問卷或者調查等方式，分析實際應用的需求，通過對于用戶需求分析確定系統的總體設計要求，并對于前期的總體設計方案進行必要的補充和更正，力求總體設計更加科學和合理。

3.基于對總體的設計要求和用戶的需求分析，對于系統進行整體的數據設計，以信息單元或者用戶的操作事件作為設計參考，建立數據模型，設計數據管理，確立整體的數據設計體系。

4.在整體的設計基礎上，根據設計內容，確定系統的各個功能模塊，并對于各個功能模塊進行深入的功能分析，建立相對清晰和完善的導航系統，并對于各個功能逐步的完善，實現系統的基本功能開發;并在此基礎上進一步整合，完善系統的開發工作。

5.在完成總體的設計的基礎上，對于工作成果進行分析，提出項目設計的不足之處，并不斷完善項目設計，使項目整體符合實際工作的需要。

6.完善詳細設計，對評獎評優管理、學生資助管理、心理健康管理、招生管理、迎新管理、離校管理、系統維護、用戶管理等模塊進行詳細設計，以用例圖或流程圖的形式詳細闡述了以上各模塊的功能及流程。

7.跟蹤開發進度，負責項目相關各部門的溝通與協調。

8.從業務角度，對系統測試用例進行分析與審核，保證系統全面滿足業務需求。

9.制定完整的上線實施流程，保證項目順利上線。

(四)論文主體結構

本論文通過對系統整體的分析，對系統的各個功能模塊和開發思想進行了詳細的描述，主要講述了六大章節的內容。

第1章:引言，結合項目實際，論述項目背景、建設目標和作者在項目開發中的主要工作。

第2章:基礎技術介紹，圍繞本項目，站在技術應用的角度，對相關技術進行基礎性簡介，為系統設計和實現奠定技術基礎。

第3章:系統需求，圍繞系統需求的提出，對業務進行描述，通過UML中的用例圖完成對需求的建模。

第4章:系統設計與實現，對本項目的運行環境以及各模塊功能進行描述，具體闡述學生管理系統的主要研究內容。描述系統架構的具體設計原則與思想，對功能模塊通過流程圖的形式具體講解各管理模塊的實現內容，詳細說明數據庫邏輯設計結構與物理設計結構。系統實現，應用St ruts 2，Spring和Hibernate技術完成對項目核心技術的實現。

第5章:系統測試，從功能測試和性能測試兩個方面進行論述，通過完整測試用例驗證系統的正確性，健壯性，保證系統的可維護性。

第6章:結論，本項目的成功實施，可以作為高校信息化領域的示范項目。

二、相關理論與技術

本章立足于系統基礎技術介紹，圍繞本項目，站在技術應用的角度，對相關技術進行基礎性簡介，為系統設計和實現奠定技術基礎。

(一)Web應用程序架構

從理論上講，Web 應用程序非常簡單。瀏覽器(“客戶端-服務器”模式中的客戶端)顯示表單并向用戶請求數據。服務器由一個軟件程序表示，在一個 Web 應用服務器上執行。用戶提交表單后，服務器程序會接收并處理信息，然后根據結果返回一個響應。這種交互如圖 2-1 所示［6］。

圖2 -1 Web 應用交互圖Fig.2-1 Web application interaction diagram

在現實過程中，根據應用程序所執行的任務，Web表單必須識別服務器的統一資源定位符 (URL)，這樣，在用戶提交表單以進行處理的時候，就可以讓瀏覽器知道應該往哪兒發送表單數據。當然，用戶并不知道發生了重定向，因此他們感覺到交易非常順利。更常見的情況是，重定向會指向同一個域，即使是重定向到不同的服務器［7］，如圖2-2所示。

圖2 -2改進版Web 應用交互圖Fig.2-2 Improved version of the Web appl ication interaction diagram

(二)MVC架構

大量的軟件工程實踐，使人們總結出一套針對大型項目開發的方法論——設計模式。經過賽迪網對設計模式的使用情況調查:在與Web相關的項目中，MVC模式使用率超過50%。MVC來源于Model-View-Control ler的縮寫，即模型(Model)-視圖(View)-控制器(Cont rol ler)，根據圖2-3所表示的類圖，可見它們分別擔當不同的職責［8］。

圖2 -3 MVC類圖Fig. 2-3 MVC class diagram

(1)模型類:數據和業務規則，封裝所需的數據，提供完成問題處理的操作過程。

(2)視圖類:用戶交互界面，通過顯示的形式，把信息轉達給用戶。

(3)控制器類:接受用戶交互信息并調用模型和視圖去完成用戶的請求。

通過圖2-4顯示的MVC處理流程圖，用戶在視圖提供的界面上發出請求，視圖把請求轉發給控制器，控制器調用相應模型來處理用戶請求，模型進行相應的業務邏輯處理，并返回數據。最后控制器調用相應的視圖來顯示模型返回的數據。

圖2 -4 MVC 處理流程圖Fig. 2-4 MVC processing diagram

MVC模式是面向對象設計中“職責單一”原則的最佳實踐之一。它可以為一個模型在運行時同時建立和使用多個視圖，使用戶可以從不同角度看待數據展示結果;它幫助視圖層與控制層分離，支持二者的對象替換，并且可以根據需求有選擇的動態配置視圖與控制層的關系，因此，它具有良好的系統可移植性，可以平滑地保證模型或者視圖在其他平臺上的耦合工作［9］。

MVC模式有利必有弊，對于小型甚至中等規模的應用，不建議使用MVC模式。首先，如果執行嚴格的MVC，就必須將應用分為三個部件，在增加設計難度的同時，意味著將要開發更多的文件，會延長開發周期。其次，視圖與控制器間耦合性看似很低，實際很高，視圖與控制器貌似相互分離，但確實聯系緊密的部件，視圖沒有控制器的存在，其應用是很有限的，從某種角度而言，將對它們的獨立重用構成障礙，最后，視圖與數據模型間的訪問是低效的，甚至是有限制的。可能由于模型間數據關系和操作接口不匹配，視圖層必須要多次重復訪問控制層，才能獲得足夠的數據，而這種數據間的頻繁訪問，極大地危害了系統性能。對于中小型項目，軟件工程的最佳實踐中，都不建議使用MVC模式。因為，如果按照MVC模式，就必須將應用分為三個部件，增加設計難度，還要編寫更多的開發文件，必將延長項目周期。本項目是個大型的信息系統項目，采用MVC模式的原因在于:

(1)業務模式相對固定，視圖、模型、控制分離相對明確。

(2)相對龐大，后續的維護升級是不可避免的，前期設計必須采用良好的設計模式。

(3)研發的人員較多，MVC可以使類的職責更加明確單一，提升開發效率，節約開發成本。

(三)Java EE 框架

框架，即Framework，它把不同應用程序中有共性的一些東西抽取出來，做成一個半成品程序，提供了一組統一的接口和編程方式的可以重用組件，只需要集中精力擴充系統的業務邏輯設計。本節主要介紹在系統開發中采用的開源框架［10］。

1. St ruts 2

St ruts2 是一個web應用框架，是第二代基于Model-View-Control ler (MVC)模型的Web應用框架。Struts2框架大致上有3部分組成:核心控制器、業務控制器和用戶定義的業務邏輯組件，St ruts2的簡單處理流程如下:

(1)用戶通過瀏覽器向服務器發送請求。

(2)St ruts中心處理器接到請求，根據系統配置文件，查找對應的處理請求的Action類。

(3)作用在Action類的攔截器，自動執行相關的通用功能，來滿足請求的一般性需求。

(4)如果系統配置文件中所配置相關方法參數有效，則通過方法參數調用到具體的Action類中的邏輯處理方法，否則通過默認的執行方法來處理請求，完成跳轉。

(5)經過一系列方法調用處理后，通過映射好的URL，將結果反應給瀏覽器。

圖2-5展示了Struts2的整體部件與處理機制［11］。

圖2 -5 Struts 2框架圖Fig.2-5 St ruts 2 f ramework diagram

2.Spring

Spring是目前業界通用的輕量級Java EE企業平臺應用程序框架，如果說St ruts2專注于表現層和控制層，主要功能是負責表現層與控制層的解耦，保證數據傳遞的流暢，那么Spring就是對業務邏輯層綜合管理者，它負責將業務邏輯細化，應用自身框架中已經整合好的處理機制，在更深層次上降低程序的耦合程度。

Spring中基本的設計模式是工廠，核心就是用輕量級的容器，通過控制反轉(IoC，Inverse of Control) 和面向切面(A0P，Aspect-0riented Programming)來生成對象，在Spring框架下現實多個子框架的組合這些框架之間彼此可以獨立，也可以實用其他的框架方案進行代替。Spring整體組件參見圖2-6。

圖2 -6 Spring框架圖Fig.2-6 Spring f ramework diagram

從根本上而言，Spring具有以下優點［12］:

(1)輕量級:無論從框架中擁有jar包的數量還是系統開銷上，Spring都是輕量級的，因為Spring中所生成的對象不依賴與Spring框架中的任何類。

(2)控制反轉:在Spring中，通過控制反轉，應用反射機制來創建對象，往往是通過調用請求來被動創建，而不是對象自己主動加載。

(3)面向切面:Spring提供豐富的面向切面通知機制，采用“織入”的方式，將相應消息和業務處理進行內聚性開服，幫助應用程序只實現它所關注的內容，而由系統控制日志或者事務等通用性功能。

(4)容器:Spring利用自身機制管理其中應用對象的配置信息和生命周期，將對象裝入自身的容器中。

(5)框架:Spring不但是一組包含各類控制邏輯的通用jar包組合，它也可以作為框架，完成各類復雜企業級應用的搭建。

3.Hibernate

Hibernate開源于著名的Java開源組織JB0SS名下，它提供了一整套面向對象關系映射的解決方案。它成功地實現Java對象向關系數據庫中數據的轉換，是一個0/R Mapping映射框架。它基本的設計理念是將軟件工程師從繁瑣的數據持久層分離出來［13］，通過面向對象中基本單位——類來組織生成數據庫，縮短了手動處理SQL和JDBC的編程時間。Hibernate的整體組件參見圖2-7。

圖2 -7 Hibernate框架圖Fig.2-7 Hibernate f ramework diagram

在面向對象程序設計中，任何的程序都需要考慮對象的生命周期及各周期的關系，其實本質就是考慮對象從創建到消亡在內存中的狀態，在Hibernate中，我們將持久化對象，分為以下幾種狀態［13］:

(1)暫態:對象剛創建，與數據庫記錄沒有關聯。

(2)持久態:對象與數據庫中記錄同步，使數據變更處于Session的管理下。

(3)游離態:對象脫離Session的管理，無法與數據庫中的記錄保持同步。

(4)移除態:對象已經被Session刪除，但操作還沒有提交給數據庫。

圖2-8是Hibernate中對象具體狀態遷移圖。

圖2 -8 對象狀態遷移圖Fig.2-8 0bject state t ransition diagram

(四)數據庫技術

數據庫是按照數據結構來組織、存儲和管理數據的倉庫，目前主流數據庫以關系型數據庫為主，此類數據庫以行和列的形式對數據進行存儲，其基本的形式是二維表。用戶使用SQL語句對數據庫中的數據進行管理和查詢。現在市場上主流的關系型數據庫有0-racle公司的 Database10g、IBM公司的 DB2、微軟公司的SQL Server和Sun公司的MySQL。下面對這幾種技術做一個簡單的介紹和比較［14］。

1.0 racle

0racle數據庫系統由0racle公司開發，是一個對象關系數據庫管理系統(0RDBMS，0bject-Relational Database Management System)。它既提供關系數據庫系統的功能，又提供面向對象數據庫系統的功能。目前，0racle系統在管理信息系統、企業數據處理、因特網及電子商務等領域使用非常廣泛，是世界上使用最廣泛的關系數據庫系統之一，幾乎可用在當今所有的操作系統平臺上，包括 Windows 平臺、UNIX平臺和Linux平臺。因其在數據安全完整性控制方面的優越性能，以及跨操作系統、跨硬件平臺的數據互操作能力，使得越來越多有用戶將其作為應用數據的處理系統，但是0racle維護成本高，開發復雜，對中、小型數據庫而言，并不是高效和經濟的選擇。

2.DB2

DB2是IBM公司研制的一種關系型數據庫系統，提供了高層次的數據利用性、完整性、安全性、可恢復性，以及小規模到大規模應用程序的執行能力，具有與平臺無關的基本功能和SQL命令。但其主要用在大型應用系統中，對中、小型數據庫而言，也不是有效率和經濟的選擇。

3.SQL Server 2008

SQL Server是一種關系型數據庫管理系統 (DBMS，Database Management System),它使用SQL(結構化查詢語言，St ructured Query Language)將用戶查詢轉換為檢索時需要的代碼。SQL Server 2008是于2008年11月由Microsof t公司推出的一種新型數據庫管理系統。 SQL Server 2008提供了企業級的數據管理，具備更加安全可靠的存儲功能，堪稱全面的數據庫平臺。用戶利用SQL Server 2008構建和管理業務的數據應用程序具備更高的性能和更強的可用性。并且在數據管理、開發效率、節省成本、與Visual Studio 2008整合、管理等方面都有很大的提高，即可以實現對大型SQL Server配置的支持，又可支持中小企業的中小型系統的開發。SQL Server 2008 數據平臺為各種規模的組織提供了以下好處:

(1)數據資源得到充分利用。

除了為業務線和分析應用程序提供一個安全可靠的數據庫之外，SQL Server 2008 也使用戶能夠通過嵌入的功能從他們的數據中得到更多的價值。

(2)IT 復雜性減少。

SQL Server 2008 簡化了開發、部署和管理業務和分析應用程序的復雜度，它使程序開發人員的開發環境更加靈活，為數據庫管理人員提供了集成的自動管理工具。

(3)總體擁有成本降低。

SQL Server 2008 中集成的方法和對產品易用性和部署上的關注提供了行業上最低的規劃、實現和維護成本，使數據庫投資能快速得到回報。

(4)生產效率提高。

通過全面的 BI 功能及Microsof t 0ffice 系統之類的工具集成，SQL Server 2008為信息工作者提供及時的、關鍵的業務信息以滿足他們的特定需要，并且最終幫助組織內所有級別的用戶能夠做出更好的決策。

經綜合考慮，項目最終選擇SQL Server 2008作為本系統開發的數據庫平臺。

三、系統需求分析

軟件需求分析是軟件產品成功的基礎，它需要相對準確地規劃出系統需要“做什么”，“做到什么程度”這個命題，因此必須對問題領域進行描述，對用戶的需求進行鑒別、綜合和建模，清除用戶需求的模糊性、歧義性和不一致性，分析系統的數據要求，力爭規避用戶的片面性或短期行為所導致的不合理要求，挖掘用戶尚未提出但具有真正價值的潛在需求

(一)系統可行性分析

由于在實際的軟件開發的過程中并不是所有出現的問題都能有合理正確的解決辦法所以要進行軟件開發的可行性分析［15］。實際上在軟件開發的過程中有很多問題是不可能在預先就知道解決辦法的。如果在設計好的系統中出現問題，我們不能很快的找到解決問題的正確方法，出現這種情況后，就代表我們在這個項目中付出的一切都是沒意義的，這其中包括時間、人力和費用等等寶貴的資源。軟件開發前，做系統可行性分析的真實目的就是為了要付出最小的代價和時間確定系統在開發過程中出現問題后，能否很快的找到合理的解決方法［16］。

高校學生管理系統設計主要從以下三個方面進行了可行性的分析和研究:

1.操作方面的可行性

本系統界面設計簡潔友好，不需要深入的對其進行研究，讓人操作起來非常容易。系統的用戶只需登陸到系統中，根據自己的權限和高校管理的具體要求就可對系統進行一些相應信息的操作了，如果在系統操作過程中確實還存在某些不解的地方，可查找系統幫助信息進行有效的理解。

2.技術方面的可行性

技術方面就是指根據高校現有的技術條件來提出的要求能否達到，例如計算機速度、容量等等能否達到使用軟件的要求，軟件開發人員的編程水平是否能完成我們的設計要求。

本系統是為高校更好的管理學生信息而開發的高校學生管理系統。開發人員的經驗足以完成本次開發工作。

3.經濟方面的可行性

為了確定開發的軟件是否有開發的價值，需要對開發系統進行成本估算和成本效益等等情況來進行合理的分析，這就是經濟可行性的研究。

其中有形成本主要是系統開發的人工成本，以及購買硬件設備所需要的資金。本系統僅從功能來看，主要是對數據庫中的數據進行存取，實現相對簡單，開發費用較低。一旦系統投入使用，不僅可以節約大量的人工勞動，同時提高了學生管理效率。學生管理系統系統是一個前期投入較大，效益逐步顯現的工程。因此，從經濟上看，學生管理系統建設是可行的。

通過對以上幾個方面的認真研究和分析，得到的結論是，設計并實現此高校學生管理系統是可行的。

(二)系統整體需求

在教育水平不斷提高的背景下，高校學生數量不斷的擴大，這就要求在學生日常管理工作上盡快完善，提高高校的競爭力［18］。作為高校管理的重要手段，高校學生日常管理系統在高校管理體系中也發揮著越來越重要的作用。為了保障學校正常的教學秩序，必須要保證學生的學習態度，這就要求在學生日常管理方面通過一定的手段進行保障。

1.教師對于系統的需求

教師需要通過系統實現與學生日常管理的相關信息的管理操作。通過操作，主要完成以下的機部分功能:

(1)對于學生基本信息的查閱。

教師在教學活動開展的過程中，需要通過學生姓名、班級或專業等信息對于學生進行查詢，并查看學生的基本信息。

(2)對于學生日常教學過程中的請假操作的響應。

普通教師需要通過系統查看學生針對該教師所提交的請假事件信息以及學生管理者的響應狀態，以確定學生的到課情況。

(3)日常教學過程中的違紀事件的信息錄入。

普通教師需要通過系統，對于所授課程中學生的違紀情況進行相應的記錄操作，并將相應記錄反饋給相關的學生和學生管理者以方便信息的確認。

2.學生對于系統的需求

學生作為學生日常管理系統的主要的信息載體單元，系統需要對于學生進行復雜的相關信息操作。在學生相關信息的操作過程中，需要以學生信息單元作為信息處理的主要對象，并衍生必要的信息模塊，對于學生來說，需要系統實現以下的功能:

(1)基本信息的承載單元。

作為學生日常管理系統中最主要的信息模塊，系統需要對于學生的基本信息建立相應的數據模型并進行存儲，包括學生的學號、姓名、班級、專業等教學相關信息以及家庭電話、住址等信息檔案的建立和存儲。

同時通過基本信息承載單元的建立，實現考勤模塊、獎學金模塊和困難學生電子檔案模塊等數據交互部分的操作。

(2)網上請假的實現。

網上請假作為日常考勤工作中的重要操作過程，面向于學生提供基于網絡的請假事件的申請，同時相關的班主任或者輔導員對于學生所提交的請假申請做出響應操作，并將響應結果反饋給相關的教師。

(3)獎學金信息的申報。

根據獎學金評比的流程以及要求，面向于學生提供獎學金評比過程中的相關信息的申報，如加分事件申報、個人相關事件憑據的提交、個人獎學金相關信息管理等操作;同時，根據實際情況，在獎學金評比過程中設定班級某位同學作為獎學金評比的負責人，實現班級獎學金相關信息的收集、整理等過程，并通過系統實現獎學金的依據評比標準自動生成等操作。

3.學生管理者對于系統的需求

學生管理者主要包括輔導員和班主任，此類用戶是學生管理系統的主要需求主體，也是在日常系統的操作過程中使用最多的用戶類型。系統的設計主要的目的即是方便輔導員的日常管理工作，減輕在學生管理過程中的工作量。

(1)日常管理工作中的學生申請的響應。

作為學生與學生管理人員之間溝通與信息交互的平臺，學生管理人員需要通過平臺對于學生在日常學習和生活過程中的請假、申請等事件做出及時、準確的響應，并將響應信息反饋給響應的系統用戶。

(2)日常管理工作中的審核操作。

學生管理人員針對日常管理過程中，對于學生通過管理系統所提交的統計材料和申報材料，進行網絡審核，并將審核意見通過系統反饋給提交者。

(3)困難學生檔案的建立。

針對在日常管理過程中困難學生(包括生活困難、學習困難和管理困難等方面)的管理，在網絡上建立學生日常管理信息檔案，記錄困難學生的基本信息、相關事件、以及談話記錄等管理信息，方便學生管理人員對于困難學生的管理。

(4)學生日常管理事件的統計和查詢。

對于學生日常管理過程中的主要事件，包括學生基本信息，如姓名、學號、家庭基本信息等，同時系統還需要記錄學生在學習過程中的實踐信息，包括學生的曠課、違紀、獎學金等事件信息，學生管理者可以通過本系統設定條件進行查詢、統計，并以特定的文本格式輸出、打印等操作，實現學生日常管理的規范管理。

(三)系統非功能性需求

在整個系統中非功能性需求占有著非常重要的位置，滿足系統的非功能性需求是系統獲得系統開發成功的必備條件［17］，下面就列出高校管理系統的非功能性的具體需求:

1.數據容量:數據訪問年最高總量5萬次，每天業務量達到1萬次，并且有逐年上漲的趨勢，系統至少能夠支持未來三年的使用需要。數據保留5年。

2.數據精確度:對數據精確度無特別要求，小數點后面保留三位小數。

3.時間特性:操作響應速度在3秒內。

4.適應性:系統上線后，支持原有審單業務模式的恢復。實現原有系統的功能。

5.吞吐量:Server端可承受最大并發數100。

6.可靠性:保障業務5×24小時運行，不間斷運行，每年故障時間不能超過24小時。

系統在安全性上，需要實現以下需求:

1.數據傳輸安全需要適當考慮，要求低成本，不能過多占用系統資源。

2.系統管理權限分派功能分級。

3.存儲層:數據要長期保存。歷史數據包括業務數據、操作數據、用戶登錄日志、通訊日志。在存儲時，需要對其進行數據簽名存儲，以達到如下驗證目的:數據在數據庫存儲期間未被篡改過;

4.通訊層:數據的傳送要保證送達，不能有任何數據的丟失。

5.應用層:不同的業務角色，在系統中具有不同的業務權限。不同的系統用戶擁有相應的操作和查詢統計的數據權限。

(四)系統功能性需求

學生工作管理系統包括評獎評優管理子系統、學生資助及勤工助學管理、心理健康咨詢管理、招生管理、就業管理、學生綜合查詢管理、迎新管理、離校管理、學生會及學生社團管理、團委工作管理等，以及學生工作日常管理功能、系統維護等功能模塊，如下圖3-1所示。

圖3 -1 系統主要功能模塊Fig.3-1 Main Model of System

1.評獎評優管理

評獎評優主要實現學生學年綜合測評成績、排名的確定;獎學金、榮譽稱號條件設定;獎學金、榮譽稱號的即時審核等，包括:條件設定、綜合測評、獎學金申請、獎學金發放、榮譽稱號申請、申請信息查詢、審批、統計分析等功能，如圖3-2所示。

圖3 -2 評獎評優功能模塊Fig.3-2 Model of Appraises Comments Superior

2.學生資助管理

學生資助管理主要實現困難生資格、助學金獲得資格、貸款資格、學費緩交的申請;審核困難生、助學金、貸款、學費緩交;查詢分析困難生工作相關信息;逾期貸款人員管理;記錄受助信息。包括:條件設定、困難生資格申請、貸助申請、減免申請、學費緩交申請、申請信息查詢、逾期貸款管理、補助發放、補助審核、信息查詢、統計分析等功能，如圖3-3所示。

圖3 -3 學生資助管理功能模塊Fig.3-3 Model of Student Financial Assistance Management

3.心理健康管理

心理健康管理主要用于學生心理測試結果查看、特殊學生心理檔案管理、心理問題反饋。包括:心理測試、特殊學生管理、心理咨詢、心理檔案維護、信息查詢、統計分析等功能，如圖3-4所示。

圖3 -4 心理健康管理模塊Fig.3-4 Model of Mental Heal th Management

4. 招生管理

招生管理子系統涵蓋了招生管理的各個環節，實現與國家招生系統實現無縫銜接，實現高校招生管理工作的網絡化、信息化、規范化，使查詢、統計數據更為方便,?提高各使用單位工作效率。考慮到體育、藝術、美術等特長生的管理需求，提供網上填報傳送審核和管理功能，如圖3-5所示。

圖3 -5 招生管理功能模塊Fig.3-5 Model of Enrol lment Management

5.迎新管理

迎新管理系統涉及新生入學管理的各個環節，面向學校各院系、各管理部門以及全校新生，包括錄取學生信息采集、錄取學生預分班、新生換專業、新生入學報到/資格審查、老生返校報到/學期注冊、收學雜費等;本系統可為新生提供方便、高效、一體的入學報到環境，加強參加迎新的各個部門之間的信息流通和工作配合，新生信息能夠及時、準確更新，從而提高學校各相關部門工作效率，如圖3-6所示。

圖3 -6 迎新管理功能模塊Fig.3-6 Model of New Student Management

6. 離校管理

離校管理涉及學生離校管理各個環節，面向學校各系、部門以及全體畢業學生提供綜合管理服務。在與畢業生離校相關的各部門之間實現數據的高度共享和流動，明確各部門的責任和業務管理范圍。離校管理將學生畢業數據轉換為校友數據加入校友數據庫，實現畢業生數據與校友庫數據的無縫連接。

電子離校管理主要用于實現網上辦理離校手續，保證離校數據的準確性、一致性和有效流轉，并實現與數字化校園其它數據庫的無縫連接。電子離校管理包括:設置離校流程、辦理離校手續、離校數據處理、登記檔案轉出等，如圖3-7所示。

圖3 -7 離校管理功能模塊Fig.3-7 Model of Leave School Management

7. 系統維護

系統維護是整個系統的控制中心，關系到數據的安全。它涉及到組分配、用戶授權、系統初始化、基礎代碼維護、數據備份與恢復、操作日志維護、系統幫助等功能，如圖3-8所示。

圖3 -8 系統維護功能模塊Fig.3-8 Model of System Management

(五)系統用例描述

在項目的需求分析與設計中，采用國際通用統一建模語言(UML，Uni f ied Model ing Language)作為建模工具，選中用例圖(Use Case)和類圖來進行需求描述。用例圖是站在操作者角度，通過具體用例來描述系統功能點，完成對系統需求上建模。它的使用幫助用戶從業務角度更系統地看待系統功能，可以規避重復的功能和多余的類，使需求更加簡潔，更加符合面向對象的設計思路。

1.用戶管理

用戶管理模塊包括激活用戶、修改密碼、綁定郵箱、設置密碼保護問題、找回密碼等功能。具體用例參見圖3-9。

圖3 -9 用戶管理用例圖Fig.3-9 Use Case Diagram of User Management

(1)用戶登錄用例說明:

1)驗證碼的有效期為 15 分鐘;

2)系統的設計是按照分布式應用設計，因此不可以使用 Ht tpSession 來存儲用戶的會話，這里采用 cookie 和 Redis 的方式存儲用戶的會話信息;

3)用戶登錄中的可能出現的各類錯誤，需要有明確提示，如驗證碼輸入有誤、用戶名密碼錯誤、用戶狀態異常等。

(2)找回密碼用例說明:

1)找回密碼可以通過以下兩種方式:通過密碼保護問題找回密碼、通過郵箱找回密碼;

2)通過密碼保護問題找回密碼:用戶輸入正確的答案后，系統會打開重置密碼的頁面;通過郵箱找回密碼:系統發生找回密碼的郵件到用戶綁定的郵箱，用戶點擊郵件里的鏈接，系統會打開重置密碼的頁面;

3)重置密碼的頁面中通過 token 進行合法性認證;token 是有一定的有效期，通過密碼保護問題的 token 有效期為 15 分鐘;

4)通過郵件的 token 有效期為 2 天。

2.系統維護

后臺管理員的用戶管理模塊包括創建用戶(學生用戶和學校用戶)、刪除用戶、禁用用戶、啟用用戶、重置用戶密碼、激活糾錯處理等功能。具體用例參見圖3-10。

圖3 -10 系統維護用例圖Fig.3-10 Use Case Diagram of System Management

(1)創建學生用例說明:

1)后臺用戶除了通過 excel 導入學生信息外，還可以通過頁面創建學生用戶;

2)首次創建的學生用戶需要包含以下信息:姓名、國家或地區、身份證號碼、性別、出生日期、學校所在省、學校所在市、學校名稱、院系、班級、學號;系統除了新建學生用戶外，還需額外完成以下任務:

3)設置學生的歸屬關系、根據特定規則創建檔案編號、新建當前教育經歷、設置用戶權限;

4)學生的用戶名和密碼是系統按照特定的規則生成。

四、系統設計與實現

系統設計主要是對系統的硬件及軟件的實現進行設計，同時根據需求分析的結果對系統的各功能板模塊的功能進行設計，并保證各模塊間的數據流正確、整個系統運行無誤［17,18］。

本節內容從系統框架設計、系統功能設計、系統的數據庫設計三個方面對本系統的設計做了全面的闡述，以明確本系統軟件是“如何做”的。而在實現系統設計的過程中通常又會分為兩個階段:總體設計和細節設計。總體設計是對軟件系統進行大致的模塊劃分，明確每個模塊的層次結構，并設計好相應的數據庫;細節設計是把每個模塊的控制流程，其內部的具體結構進行詳盡的設計。

(一)系統設計原則

系統設計是根據我們在需求分析階段對系統邏輯功能的要求，從系統的總體的設計目標為起點來分析系統所要用到的經濟的開銷以及技術方法和系統的運行時的環境等等多角度的，來確定系統的總體設計方案，從而來保證系統的總體設計目標的完成。

本系統的結構圖采用的是數據流程圖映射方法，該方法結合數據流程圖以及其各級的細化圖，按照自頂向下的原則依次將數據流程圖中的那些邏輯處理映射到結構圖中去，從而成為一個個的模塊。此方法簡單、方便，它使數據流程圖與結構圖建立起了對應統一的關系，使設計達到一致的效果［19］。

高校學生管理系統分為多個模塊，在各個模塊之間不存在太多相互關聯的作用，每個模塊都可以單獨的完成一個系統的功能，從而實現模塊的獨立化。因為內聚和耦合這兩個相應的標準化條件是用來對比系統中各個模塊的獨立性的，所以如果想要做到模塊的獨立化就必須得盡可能的使系統中的各個模塊的劃分做到較高內聚和較低耦合［19］。

高校學生管理系統是屬于一種小型的數據庫管理系統，它可以給高校帶來合理有效的管理。在人機交互方面，通過使用本系統可以達到如下目標:

(1)方便靈活的數據錄入，信息傳遞更加方便快捷。

(2)本系統的操作界面友好且美觀，設計上采用了人機交互式的對話方式，其方便和靈活的信息查詢功能，保證了系統重要數據存儲的安全可靠。

(3)強大的后臺監控功能。

(4)系統需實現對信息的各種查詢方式，而且支持模糊查詢。

(5)幫助高校實現學生管理及其內部信息資源的數字化的管理。

(6)系統可以排除人為性錯誤的輸入，對用戶輸入的信息進行了合理有效的數據檢測。

(7)本系統實現了便于安裝、便于維護和便于操作的完美性能。

(二)系統總體設計

學生綜合管理平臺技術架構將在數字化校園整體架構基礎進行設計，并采用基于S0A的技術架構開發。遵循學校統一的技術標準，進行組件化和服務化。圖4-1是基于S0A的技術架構，以及學生綜合管理平臺在這種架構下的位置。

圖4 -1 系統框架圖Fig.4-1 Diagram of System Frame

本系統的開發與測試環境如下:

(1)操作系統:Windows 7。

(2)編程語言:Java SE 1.7。

(3)編程工具:Ecl ipse。

(4)版本控制工具:SVN 1.6。

(5)數據庫 SQL Server 2008。

(6)測試服務器 Tomcat 7。

本系統的網絡拓撲環境參見圖4-2。

圖4 -2 系統拓撲圖Fig.4-2 Diagram of System Topology

(三)系統體系結構

系統采用St ruts 2作為MVC(Model-View-Control ler)框架，并在其中添加AJAX技術，通過JS0N實現頁面間的數據傳遞，Spring作為控制管理框架，完成頁面與數據庫間的事務調度管理，數據持久層采用Hibernate框架。系統整體邏輯結構參見圖4-3［20］。

圖4 -3 系統模型圖Fig.4-3 Diagram of System Layer Model

1.界面層

用戶界面部分，在系統中就是HTML、XML、St ruts 2 Tag等。此部分主要的職責是:

(1)St ruts 2 Tag負責從AJAX對象返回的信息中獲取指定的數據輸出至頁面

(2)按指定的風格、布局顯示頁面

(3)校驗用戶輸入操作的合法性與正確性

2.控制層

控制層負責網站的整個邏輯。它用于管理用戶與顯示層發生的交互，對顯示層如何與模型交互進行管理。控制層的職責是:

(1)根據客戶端的邏輯業務請求構造相應的AJAX請求發送到服務器端

(2)接收從客戶端發來的AJAX請求或者其它請求中的參數

(3)調用相關業務邏輯并負責控制各個業務邏輯之間的跳轉

(4)根據不同的業務邏輯，將最后生成的結果通過AJAX的方式返回給頁面。

3.服務層

服務層是應用業務邏輯部分，通過對邏輯業務對象模型設計，可以方便的維護系統中的實際業務。業務層的職責是:

(1)從由控制層傳入的對象中取出相關的數據

(2)根據具體業務規則處理數據;與數據庫的交互通過Hibernate數據持久層框架完成

(3)將業務處理結果添加或更新對象中

(4)返回結果碼(指示該業務邏輯執行成功與否)

4.DA0層

DA0層是整個系統的底層組件，提供了與數據庫的連接、操作及消息服務的封裝和管理。通用平臺層其實是一個功能完善和提供了眾多底層服務的數據庫引擎(Database Engine)，使用Hibernate框架實現。通用平臺層的職責是:

(1)封裝各種與業務無關的操作接口，如數據庫連接池，事務管理等。

(2)解析業務層傳遞來的對象關鍵字，根據邏輯業務映射關系構造相應的SQL語句，完成相應的數據庫操作。

(四)系統詳細設計

詳細設計是軟件工程中軟件開發的一個步驟，就是對概要設計的一個細化，就是詳細設計每個模塊實現算法，所需的局部結構。本節以系統中典型的模塊為例，介紹詳細設計的步驟。本文將以系統中的用戶管理模塊為例，應用流程圖實現系統的詳細設計。

1.用戶管理

用戶管理模塊包括激活用戶、修改密碼、綁定郵箱、設置密碼保護問題、找回密碼等功能。

(1)用戶登錄基本流程:

1)用戶點擊登錄按鈕，系統收到用戶登錄請求;

2)系統檢查用戶輸入的驗證碼是否正確;

3)用戶根據請求中的用戶名獲取用戶信息，若獲取不到，表述輸入的用戶名不存在;

4)系統檢查用戶的狀態，若為待激活狀態，則轉至激活頁面;

5)若用戶狀態正常，用戶登記客戶端Cookie 信息;

6)系統將用戶信息保存在 redis 的會話池中，并返回用戶首頁;

7)若上述任一步校驗錯誤，系統提示錯誤信息，返回登錄頁面。

具體流程參見圖4-4。

圖4 -4 用戶登錄流程圖Fig.4-4 Flow Char t of User Login

(2)找回密碼基本流程:

1)用戶輸入登錄名或身份證號碼，點擊下一步;

2)系統根據用戶選擇的身份標識獲取用戶信息;

3)若獲取不到用戶，系統返回錯誤提示;

4)用戶選擇找回密碼的方式:綁定郵箱或者密保問題;

5)通過郵箱找回密碼:系統將找回密碼郵件發送至用戶綁定的郵箱，用戶點擊郵件中的鏈接，返回修改密碼的頁面;

6)通過密保問題找回密碼:用戶回答密保問題，若校驗不通過，系統返回錯誤提示，若校驗通過，系統返回修改密碼的頁面;

7)用戶修改密碼然后提交，系統校驗鏈接中的 token 是否有效;

8)若通過，則修改用戶密碼，返回成功信息，若失敗，系統返回錯誤提示。

具體流程參見圖4-5。

圖4 -5 找回密碼流程圖Fig.4-5 Flow Char t of Password Management

2.系統維護

后臺管理員的用戶管理模塊包括創建用戶(學生用戶和學校用戶)、刪除用戶、禁用用戶、啟用用戶、重置用戶密碼、激活糾錯處理等功能。

(1)創建學生基本流程:

1)用戶輸入學生信息，點擊保存按鈕，系統接收到創建學生用戶的請求;

2)系統對表單數據進行校驗，若校驗失敗，則返回錯誤信息，流程結束;

3)系統根據表單數據，創建學生用戶信息，其中用戶名和密碼按照上述規則自動創建;

4)系統根據特定規則生成檔案編號;

5)系統根據表單數據，設置學生歸屬的學校和班級等信息;

6)系統根據學生學校信息，新建當前教育經歷信息，該信息狀態應為已認證;

7)系統為分派學生角色的權限，并返回成功頁面。

具體流程參見圖4-6。

圖4 -6 創建學生流程圖Fig.4-6 Flow char t of Create Student

(五)數據庫設計

根據用戶和系統功能的需求，Database Design(數據庫設計)是指在一個完整的數據庫管理系統的基礎上，完成數據庫的結構設計和數據庫的具體建立的過程。簡單的說數據庫的設計就是把數據庫中的數據對象結構化并規劃好數據庫對象之間的關系［20］。

1.數據庫設計步驟

按規范設計的方法將數據庫設計分為以下五個階段。

(1)需求分析階段

第1步:了解和分析用戶的應用需求(包括數據與處理)，利用分析工具進行需求收集和分析。

第2步:對用戶需求進行綜合、歸納與抽象，形成一個獨立于具體RDBMS的概念模型。

(2)邏輯結構設計階段

第3步:遵循轉換規則，將概念模型轉換成某數據庫系統支持的關系模型。

第4步:依據規范化理論，優化上一步中得到的關系模型。若不滿意邏輯結構設計，則進行上一步。

(3)物理結構設計階段

第5步:為關系模型選擇一個最適合應用環境的包括存取方法和存儲結構在內的物理結構。

第6步:性能預測和設計評價。若對物理結構設計不滿意，則轉至第3步或第5步繼續操作。

(4)數據庫實施階段

第7步:運用數據庫系統提供的宿主語言及其數據語言，根據物理設計和邏輯設計的結果建立數據庫，編寫與調試應用程序，并將數據輸入數據庫。

第8步:試驗性運行系統。若對不滿意數據庫實施結果，轉第5步繼續操作。

(5)數據庫運行和維護階段

第9步:經過試運行后的數據庫系統就可以正式投入運行。在運行數據庫系統過程中肯定還要不斷地對其進行評價、修改和調整。

2.數據庫編碼規則

數據庫是高校學生管理系統的核心部分，良好的數據庫設計對于高性能的應用程序來說是很重要的，如果一旦數據庫的結構設計不合理的話，那么它就會給系統的運行和維護帶來很多不必要的麻煩，而且數據庫還會存儲一些沒有用的信息占用系統資源。

此高校學生管理系統選擇的是微軟的SQL Server 2008 數據庫作為后臺數據庫，在數據庫編程中只有遵循程序編碼規則開發的程序，才能做到代碼清晰、整潔、方便閱覽，并可以提高程序的可讀性。

系統的數據庫命名是以 db 開頭的，后面則是與系統相關含義的英文縮寫。如:db_STU_Mgr 即客戶關系管理系統的數據庫名稱。

系統的字段統一采用英文單詞和詞組命名。

3.數據庫概念設計

根據對系統各個模塊的分析，可以做出能夠滿足用戶需求的實體及它們的關系圖，即實體關系 E-R 模型。

(1)學生管理E-R模型

子系統的實體包括:系別、專業、學生等。其實體之間的關系如下:

1)一個系可以開設多個專業，一個專業只能被一個系設置;

2)一個專業可以包含多個班級，一個班級只能屬于一個專業;

3)一個班級有多名學生組成，一個學生只屬于一個班級;

4)一個學生可以獲得多項獎項;

5)一個學生可以受多項懲罰。

具體E-R圖參見圖4-7。

圖4 -7 學生管理E-R模型Fig.4-7 E-R Model of Student Management

(2)教師管理E-R模型

教師管理子系統的實體包括:系別、教研室、教師、論文和科研項目等。這些實體之間的關系如下:

1)一個系可以包含多個教研室，一個教研室只能被一個系設置;

2)一個教研室有多名教師組成，一名教師只屬于一個教研室;

3)一名教師可以撰寫多篇論文;

4)一名教師可以承擔多個科研項目;

5)一名教師可以獲得多項獎項;

6)一名教師可以受多項懲罰。

具體E-R圖參見圖4-8。

(3)教學計劃E-R模型

教學計劃管理子系統的實體包括:培養計劃、專業培養計劃課程、學期開設課程等。其實體間的關系如下:

l)一個培養計劃包含多個專業培養計劃課程，一個專業培養計劃課程只能從屬于一個培養計劃;

2)一個專業培養計劃課程會安排多項學期開設課程，一個學期開設課程從屬于一個專業培養計劃課程;

圖4 -8 教師管理E-R模型Fig.4-8 E-R Model of Teacher Management

3)一個專業對應一個專業培養計劃課程;

4)一個班級實施一個教學計劃實施。

具體E-R圖參見圖4-9。

圖4 -9 教學管理E-R模型Fig.4-9 E-R Model of Lesson Management

4.數據庫邏輯設計

將各類E-R圖形成各類實體關系表格，映射到數據庫中，形成符合邏輯需求的關系數據庫。一個合理的數據表結構，對于高校管理系統來說尤為重要，這能夠提高系統對各類信息的有效管理，表 4-1 至表 4-5 列舉本系統中的主要數據表的類型、描述和結構等信息。本系統的其它數據表在這里就不全部列舉。

(1)系部表(系部信息表)

用于保存系部的基本信息，數據表命名為“Apartment”，“系部編號”在信息表屬性組中具有唯一性，Apar tment_Id字段設置為主鍵，“專業分類”為外鍵對應專業分類表。系部表的設計，如表4-1所示。

表4 -1 系部表Table 4-1 Table of Depar tment

(2)學生表(學生基本信息)

用于保存學生的基本信息，數據表命名為“Stu”。“學號”在信息表屬性組中具有唯一性，Stu_No 字段設置為主鍵，用戶編號(User_Id)和班級編號(Class_Id)為外鍵，學生信息表的設計，如表 4-2 所示。

表4 -2 學生表Table 4-2 Table of Student

(3)角色表(用戶權限策略)

角色表用于存放系統的角色信息。角色信息主要包括角色編號、權限名稱、權限值等信息，數據表命名為“Power”，權限編號屬性組能唯一標識一條記錄，所以設置Power_Id字段為主鍵，角色表的設計，如表 4-3 所示。

表4 -3 角色表Table 4-3 Table of Role

(4)用戶表(用戶權限管理)

用戶表存放系統的用戶信息，用于存儲用戶編號和用戶密碼、權限的信息，用戶編號屬性組能唯一標識一條記錄，該屬性組 User_Id 字段為主鍵，對應于角色表。數據表命名為“User”。用戶表的設計，如表 4-4 所示。

表4 -4 用戶表Table 4-4 Table of User

(5)教師表(教師基本信息)

用于保存教師的基本信息，數據表命名為“Teacher”，“教師編號”在信息表屬性組中具有唯一性，Teacher_No 字段設置為主鍵，“自動編號”為外鍵對應用戶表。教師表的設計，如表4-5所示。

表4 -5 教師表Table 4-5 Table of Teacher

(六)系統實現

系統設計完成之后便進入系統實現階段，該階段的主要任務是根據系統設計方案，通過程序開發工具選擇程序語言編寫系統的應用程序，并搭建系統實施所需要軟件、硬件環境。系統實現是一個把設計方案變成一個具體可以運行的系統的過程，是系統開發過程一個非常重要的環節。該系統是采用 B/S 結構，通過瀏覽器方式來實現。按照項目的情況需求分析，該系統實現的核心功能很多，鑒于本文篇幅有限，僅提供框架級別的核心代碼。

1.編碼規范

本系統必須嚴格執行本規范以確保源代碼的可讀性及可維護性。定義規范的目的是讓項目中所有的文檔增加可讀性，減少項目組中因為換人而帶來的損失。所有的程序文件都必須有注釋文字，并嚴格按照本規范中的注釋規范書寫。

(1)函數命名規范

1)函數名和方法名以動詞開始，首字母大寫，如 SaveFileLog。

2)在命名函數時包括返回值的說明，如GetFi leName。

(2)變量命名規范

1)所有變量都必須有前綴，前綴使用2—4個字母，全部小寫。

2)避免與數據字典中的數據元素名相同。

3)避免與函數名、方法名、類名和屬性名相同。

4)避免使變量名為另一個變量名的一部分。

5)布爾變量名應該包含 Is，如 blnFi le-IsFound。

(3)常量命名規范

1)常量所有字母都應該大寫，單詞之間用下劃線連接。

(4)類(Class)命名規范

1)名字應該能夠標識事物的特性。

2)名字盡量不使用縮寫，除非它是眾所周知的。

3)名字可以有兩個或三個單詞組成，但通常不應多于三個。

4)在名字中，所有單詞第一個字母大寫。

5)使用名詞或名詞短語命名類。

6)少用縮寫。

7)不要使用下劃線字符 ( _ )。

2.框架應用

本系統的開發框架選用三大主流框架:St ruts 2，Spring 2.5，Hibernate 3， 開 發IDE選用Eclipse的Java EE開發版和Tomcat服務器。歷經30人月完成，總代碼量在67，000行左右。

本系統采用S2SH框架，每個框架選取的核心開發包參見表4-6。

表4 -6 框架核心開發包Table 4-6 Framework core jar

代碼實現步驟如下:

(1)表示層框架采用Struts框架以及MVC設計模式，任何MVC框架和Web應用整合都需要借助于web.xml文件。在Tomcat服務器的web.xml中配置St ruts 2，如下文件4-1所示。

(2)在Tomcat服務器的web.xml中配置Spring，采用Spring的字符編碼過濾器，過濾不同編碼的HTTP請求，如下文件4-2所示。

文件4-2 配置Spring

Fi le. 4-2 Conf igure the Spring

(3)修改Struts 2的配置文件St ruts.xml，完成Struts2和 Spring整合，如下文件4-3所示。

文件4-3 St ruts2整合Spring

Fi le. 4-3 St ruts2 integration of Spring

(4)在Spring的appl icationContext.xml整合Hibernate，如下文件4-4所示。

文件4-4 Spring整合Hibernate

Fi le. 4-4 Spring integration of Hibernate

3.登錄實現

該模塊表現層的主要文件，文件中包含的主要Action類及其功能和與其它包的交互如圖4-10所示。

(1)login.jsp:系統登錄頁面，用戶輸入用戶名和密碼及驗證碼進行登錄。

(2)index2.jsp 系統主頁面，包括f ramework_compact.jsp 頁 面 、menu.jsp、shade2.jsp和but tom.jsp頁面。

(3)loginAction.do:負責執行各頁面之間的跳轉并進行登入登出首頁數據讀取的邏輯處理。

該模塊表現層與控制層和數據層，相關聯的類關系，參見圖4-11。

圖4 -10 登錄模塊類與文件交互圖Fi g. 4-10 Log in modu l e c l as s and f i l e in t e r a c t ion d i ag r am

圖4 -11 登錄類圖Fig. 4-11 Login module class diagram

圖中各元素描述如下:

(1)LoginAction.class:通過/loginAction.do調用的前臺跳轉邏輯。

(2)Constant.class:提供系統常量

(3)SysLogService.class:寫入日志的Service接口，提供記錄日志的相關方法。

(4)SysLogServiceImpl.class:記錄日志的Service實現類，負責操作具體DA0。

(5)SysLogDA0.class:日志模塊的數據庫訪問接口，在本模塊中僅調用其記錄日志的方法。

(6)SysLogDA0Impl.class:日志數據庫操作實現類，記錄用戶登入登出的信息至用戶表并記錄新訪問系統的用戶名及證件號碼。

4.報表實現

該模塊表現層的主要文件，文件中包含的主要Action類及其功能和與其它包的交互如圖4-12所示。

圖4 -12 數據報表類與文件交互圖Fig. 4-12 Data Report class and f ile interaction diagram

(1)repor t.jsp：顯示統計報表菜單

(2)repor t_view.jsp：展現報表

(3)repor t_view_jd.jsp：顯示各類報表類型

(4)repor tAction.do ：通過reportActiond.do控制前臺跳轉

該模塊表現層與控制層和數據層，相關聯的類關系，參見圖4-13。

圖4 -13 數據報表類圖Fig. 4-13 Data Repor t c lass diagram

圖中各元素描述如下:

(1)Repor tAction.class:統一查詢中央處理類。

(2)DispatchAction.class:詳細信息查詢類。

(3)DictionardyServcie.class:字典查詢業務

(4)DictionaryDA0.class:字典通用查詢

(5)DatabaseUti l.class:數據訪問接口類

(4)NetUti l.class:公共方法訪問

(七)系統界面

1.用戶登錄界面如圖4-14所示。

圖4 -14 用戶登錄界面Fig. 4-14 UI of User Login

2.首頁顯示區域分為通知公告、申請事項、學生基本信息、下載專區、聯系方式五個區域。如圖4-15所示。

圖4 -15 首頁界面Fig. 4-15 UI of Main Menu

3.學生基本信息界面，如圖4-16所示。

圖4 -16 學生基本信息Fig. 4-16 UI of Student Base Information

五、系統測試

根據軟件工程理論，測試階段是保證系統質量和可靠性的關鍵步驟，它是系統生命周期的重要環節。系統軟件是否符合用戶的需求，需要通過軟件測試驗證。

軟件測試不是孤立的，它是建立在需求規格說明書、設計和實現方案、系統編碼之上的，是通過合理的用例對它們進行驗證，從而保證軟件質量。軟件測試是通過執行程序而發現錯誤的過程，在過程中，全面評估軟件產品質量，為軟件產品發布、軟件系統部署、軟件產品鑒定提供有效信息［21］。

通過堅持持續地進行軟件測試，可以始終如一地堅持對軟件產品質量不間斷的，快速的反饋。

(一)測試流程與方案

測試過程中，項目組制定的具體流程參見圖5-1。

圖5 -1 測試工作流程圖Fig. 5-1 Testing workf low diagram

在遵循測試流程的基礎上，系統測試還會在測試設計、研制和執行中可能受到以下幾方面的影響［22-24］:

1.人員方面

測試工作對測試設計人員的專業素質要求很高，測試設計人員的素質直接關系到測試的質量。測試人員需要有較豐富的背景知識和專業知識，并應具有較強的分析問題解決問題的能力，而我們現在參加測試的人員都沒有很豐富的規范化測試的實際經驗，必將會影響到測試的效果。

解決方案:加強對測試人員的培訓，對他們進行系統的較完整的專業知識的培訓，使其在最短的時間內滿足測試的要求。

2.資源方面

系統的、比較完備的測試需要消耗大量的人力、物力和時間，必須要有相應的測試工具和測試設備，只有這樣才能保證測試工作的質量。我們現在缺乏測試工具和設備的使用經驗。

解決方案:本文選擇目前世界上較為流行的QC進行缺陷管理。

(二)測試環境

1.應用服務器

硬件配置:一臺Del l R710

操作系統:Windows Server 2008

應用軟件:Tomcat 5.5

IP地址:10.110.46.54

Web服務端口號:80

2.數據庫服務器

硬件配置:一臺Del l R710

操作系統:Windows Server 2008

應用軟件:SQL Server 2008

IP地址 :10.110.46.56

3.測試客戶端

操作系統:Windows XP，Windows 7，Windows 8

瀏覽器:IE6，IE7，IE8

CPU:3.0G以上

內存：:2G 以上

(三)測試用例

測試用例是為實現測試有效性而采取的一種最基本手段，良好的測試用例可以幫助測試人員盡快地發現缺陷，并將在測試過程不斷被重復使用［23,24］。因此測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則，更是軟件測試質量穩定的根本保障［25,26］。

本系統在開發過程中，針對每個功能點編寫了大量規范的測試用例。但由于篇幅有限，這里僅對幾個功能的測試用例進行說明。

如表5-1，表5-2所示。

表5 -1 用戶登錄用例Table 5-1 Test Case of User Login

表5 -2 考勤管理用例Table 5-2 Test Case of At tendance Management

(四)系統測試

系統測試是針對整個產品系統進行的測試，目的是驗證系統是否滿足了需求規格的定義，找出與需求規格不符或與之矛盾的地方，從而提出更加完善的方案。系統測試發現問題之后要經過調試找出錯誤原因和位置，然后進行改正。是基于系統整體需求說明書的黑盒類測試，應覆蓋系統所有聯合的部件［27-30］。系統測試是將經過集成測試的軟件，作為計算機系統的一個部分，與系統中其他部分結合起來，在實際運行環境下對計算機系統進行的一系列嚴格有效地測試，以發現軟件潛在的問題，保證系統的正常運行。

本系統經過嚴格的系統測試，系統測試結論參見表5-3。

表5 -3 系統測試結論Table 5-3 Resul t of System Test

六、結論

本文立足Java EE企業開發框架，整合Web技術，根據高校管理系統的實際需求，開發完成基于 St ruts2，Spring，Hibernate開源框架的高校管理系統，為高校的信息化建設提供一份良好的案例。具體結論如下:

1.本文技術介紹全面，既介紹相對基礎的框架知識，也有比較高端的海量數據處理技術和大量用戶登錄技術，整個介紹由淺入深，層次鮮明，為日后相關系統的研發，提供技術參照。

2.本文嚴格按照軟件工程設計思想，完成高校學生管理系統的需求采集與分析，系統概要詳細設計，并展現 Struts2，Spring，Hibernate整合開發的基礎框架，完成相關類的設計，在實施過程中體現了良好的編碼習慣和編程規范。

3.本文關于測試與發布的過程介紹相對完整，從一定程度上改變了一般設計實現類論文“重實現代碼，輕測試發布”的局面，力爭從整體上展現一個高校信息化管理系統的全貌，為日后學術研究提供參考。

鑒于本人理論水平和時間限制等多方面原因，本文在理論和實踐方面都有很多地方需要完善:

1.Web應用系統的設計開發是一個復雜多樣的系統工程，涉及到很多方面的問題，Web應用本身的性能、并發控制、程序優化等一系列問題還需要在實踐中進一步的檢驗和分析。

2.在研發中除基礎框架外，希望能更好地借鑒其他更優秀的開源技術，從根本上提升開發效率，保證開發質量。

［1］陸美玲，于俊樂.基于B/S模式的學生管理系統的設計［J］.軟件 ，2013，(11)：55-56.

［2］王小玲.基于B/S模式的中職院校學生管理系統［J］.青年科學(教師版)，2014，35(3)：41.

［3］Juan Reza.Java supervenience ［J］.Computer languages，systems structures，2012，38(1)：73-97.

［4］王立國.高職院校學生管理系統設計的方案研究［J］.硅谷，2013，6(10)：74-75.

［5］溫小寧.軟件工程理論在學生管理系統中的應用［J］.廣東教育(職教版)，2013，(2)：28-29.

［6］Tan.JET：exception check in Java ［J］.ACM SIGPLAN Notices，2011，46(10)：345-358.

［7］任小瑞.基于WEB的學生信息管理系統的設計與實現［D］.鄭州大學，2010.

［8］劉佳.基于輕量級開源框架的學生網報系統設計與實現［D］.濟南大學，2012.

［9］Johnson， R..J2EE development frameworks［J］.Computer，2005，38(1)：107-110.

［10］J.，Araujo，L..Updating broken web links：An automatic recommendation system ［J］.Information Processing Management，2012，48(2)：183-203.

［11］Xinyan Liu Chapter 35 J2EE-Based General Document Transceiver System ［C］.//Informatics and management science IV.2013：289-296.

［12］Zhao Xiao.Development and Implementation of Enterprise Management System Based on J2EE ［C］.//Green communications and networks.part 1.2012：133-139.

［13］Fan，Rui.The research of Hibernate cache technique ［C］.//2011 IEEE 3rd International Conference on Communication Software and Networks. ［v.1］.2011：160-162.

［14］Tang，Hongxi.Struts+Spring+Hibernate Integrated Framework ［C］.//2010 International Conference on Multimedia Information Networking and Security.2010：936-939.

［15］Masaaki Tanaka等.W eb 系 統的 實現，改善學生的學習態度［J］.管理學家 ，2013，(17)：592-593.

［16］梁福偉.W eb測試在學生綜合測評管理系統中的應用［J］.農業網 絡信息 ，2009，(12)：92-97.

［17］祝振磊.學生管理信息系統設計與開發［J］.科技廣場，2011，(3)：117-119.

［18］周斌.Java 平臺測試策略［J］.中國集成電路，2013，22(7)：37-41.

［19］馮麗華.Java架構和軟件系統的測試［J］.電子制作 ，2013，(15)：77-77.

［20］涂敏.基于Java的W eb服務器性能測試工具分析［J］.信息通信 ，2013，(6)：288-288.

［21］李爽.Java開發智能軟件在大型企業系統中的應用 ［J］. 制造業自動化，2012，34(7)：118-120.

［22］李曙光，朱偉.探究基于 Java的 W eb服務器性能測試工具 ［J］. 西江月 ，2013，(24)：363-363.

［23］高昂，慕德俊等.W eb集群負載均衡策略研究［J］.電子與信息學報，2011，33(3)：555-562.

［24］M ing-W ei Zhang，Bin Zhang，Ying Liu等.Web Service Composition Based on QoS Rules［J］.計算機科學技術學報(英文版)，2010，25(6)：1143-1156.

［25］單錦輝，孫萍等.軟件測試研究進展［J］. 北京大學學報(自然科學版)，2005，41(1)：134-145.

［26］柳永坡.軟件測試知識管理的研究與應用 ［J］. 計算機集成系統，2008，14(9)：1805-1809，1844

［27］Garousi， V.，Zhi， J..A survey of software testing practices in Canada(Review)［J］.The Journal of Systems and Software，2013，86(5)：1354-1376.

［28］Izzat M ahmoud.Using M utation to GUI Testing Coverage［J］.IEEE Software，2013，30(1)：67-73.

［29］Glass， Robert L..A Classification System for Testing， ［J］.IEEE Software，2009，26(1)：104-104.

［30］Rood，Richard.Software Testing and Verification in Climate M odel Development［J］.IEEE Software，2011，28(6)：49-55.