基于SSH架構的高職院校成績管理系統的分析和設計

陜晉軍

1江南大學物聯網工程學院 江蘇 214122

2山西建筑職業技術學院計算機工程系 山西 030006

0 引言

如今，Web應用開發變得越來越復雜，傳統的單個應用框架往往很難滿足日益增長的應用需求，實際的開發過程常常需要綜合多個框架的長處才能滿足用戶的需求。

表現層的開源 Struts2，數據持久層的 Hibernate框架以及中間層的Spring框架，這三者構成了當前主流的開發J2EE應用的輕量級框架組合，即 Struts2+Spring+Hibernate。使用Struts2架構作為了整個系統的基礎框架，它負責了MVC模型中各層的分離。利用 Hibernate作為系統持久層的底層結構。中間業務邏輯層由Spring支持。根據需求來提出一個模型，將這些模型采用Java語言實現出基本的Java對象，然后寫出基本的DAO接口，并給出Hibernate的DAO實現，采用Hibernate架構實現的DAO類來實現Java類與數據庫之間的轉換和訪問，然后由Spring來完成業務邏輯。

1 系統概要分析

概要分析要做的工作是描述目標系統的功能和性能，確定軟件設計的限制和軟件同其他系統元素間的接口細節，定義軟件的其他有效性需求。運用統一建模語言(Unified Modeling Language, UML)來找出系統的功能需求、分析，提取所開發系統領域的類以及描述它們之間相互關系，在完成系統的面向對象分析(Object-Oriented Analysis, OOA)的基礎上，對系統進行面向對象設計(Object-Oriented Design, OOD)。圖1為整個系統的基本框架圖。

圖1 系統的基本框架圖

針對不同的用戶群，其功能也各部相同。實現分角色登錄，對不同的角色由不同的功能實現。可以實現平時及期末成績錄入、查詢、修改、統計分析；學生補考成績錄入、查詢、修改、統計分析；數據備份、導入和導出；成績報表打印、數據報表打印；并且還可以對教師、學生的基本信息錄入、查詢、導入和導出；并且還可以對教師的授課情況將行統一管理，實現根據授課情況統計教師的工作量。成績錄入提供四種方式：教務人員錄入或導入系統；教師錄入或導入所教授課程的學生成績。成績一般有百分制和學分制(如包括優秀、良好、中等、及格、不及格)。百分制總評成績由平時成績、考勤成績、期末考試成績結合學校制定的比例計算而來。

1.1 系統高層用例模型

我們通過 UML語言來分析高職院校成績管理系統。UML作為一種圖形語言，用于對軟件系統建模和開發工作。在軟件開發的每個步驟中，從對需求的分析到技術規范，再到結構設計及配置要求，UML都提供了模型化和可視化的支持。

用例是用戶和計算機系統進行交互的描述。用例圖是被稱為參與者的外部用戶所能觀察到的系統功能的模型圖，呈現了一些參與者和一些用例，以及它們之間的關系，主要用于對系統、子系統或類的功能行為進行建模。

用例圖展示了用例之間以及同用例參與者之間是怎樣相互聯系的。用例圖用于對系統、子系統或類的行為進行可視化，使用戶能夠理解如何使用這些元素，并使開發者能夠實現這些元素。

1.1.1 使用用例圖描述系統需求的步驟

（1）識別用戶角色

一般而言，定義用戶角色的基本思路是，先從涉眾中找到用戶，用戶是指將與要建設的系統發生關系的那些涉眾。再從用戶的角度出發，考慮系統建立以后將發揮什么作用，哪些事務與它進行交互。除此之外，系統還有可能跟其他系統相聯系，如招生系統、教務管理系統等，它通過數據庫進行接口，所以數據庫也可能是一個角色，還有與該系統交互的設備，如打印機也是角色。總體來說，該系統主要角色有：系統管理員、學生、教師。

（2）識別系統中的用例

用例是系統的功能描述，從用戶角色的角度，分析每個角色的主要任務是什么？如教師角色，他的任務有查看和修改個人信息、成績錄入、成績查詢等。

（3）確定系統中角色與用例間的關系角色和用例的關系反映了角色與系統的互動，即角色的動作，角色向系統輸入或從系統輸出什么信息。

1.1.2 系統管理員角度的頂層用例圖

下面我們分別從系統管理員、教師、學生這三類用戶的角度得到頂層用例圖。項目用例圖如圖2所示。

圖2 系統頂層角色用例圖

系統管理員頂層用例圖

用例分析：該用例角色是系統管理員。系統管理員負責學生學籍信息的管理(包括學生注冊、學籍異動、學生調班以及學生畢業后的數據處理)、教師基本信息的錄入(導入)和查詢(設置多種查詢方式)、課程管理(開課情況、開課學期、任課教師、以及教材信息等)學生成績的錄入和查詢(設置多種查詢方式)、生成各種報表(班級名單、班級成績、補考名單以及教師的課程表等)、身份及角色管理、數據備份(所有師生及學生成績等數據的導入和導出等)以及打印功能。

教師角度的頂層用例圖

用例分析：該用例角色是教師。教師可以進行個人信息維護(查看任課信息、查看個人信息、查看學生信息和修改以及登錄用戶名和密碼的設定)、學生成績管理(包括導入或錄入學生成績、查詢本班學生成績并且可以對成績進行簡單的統計，生成補考學生名單等)、報表打印(打印本人信息、打印班級名單、打印本班成績以及打印本班補考成績名單)。

從學生角度的頂層用例圖

用例分析：該用例角色是學生。可以查看和修改個人的信息(登錄用戶名和密碼的設置等)、個人成績查詢、個人選課情況，以及相應選修學分的情況等。

1.2 業務建模

在上述用例圖的基礎上，進一步對用戶需求進行分析。劃分業務用例，并針對業務用例，必要時可以結合UML提供的時序圖、協作圖、活動圖描述業務用例。選擇業務用例的粒度十分重要，如學生信息修改的功能，是應該把增加學生信息、刪除學生信息、修改學生信息、查詢學生信息分別作為一個用例，還是整體作為一個用例都是需要考慮的。

1.2.1 確定業務用例

確定業務用例的時候，可以從以下幾個方面出發：

（1）用例是針對一個完整的業務。一般不必把增加、刪除、修改、查詢分別作為一個完整的業務。作為一個管理業務，數據只有先增加，才有可能修改或者刪除。增加、刪除、修改、查詢結合起來才能完成管理目的，單獨每一項都不是業務的全部。

（2）考慮實施成本和風險。如果將增加、刪除、修改、查詢都分別作為一個業務用例，很容易造成這些原本與用戶這個實體緊密關聯，共同組成用戶實體生命周期的業務，被割裂成多個獨立的業務，一個用例可以看作一個分析單元，設計單元，開發單元，測試單元甚至部署單元。把緊密關聯的業務分成多個獨立部分去實施是高成本的，高風險的。

（3）盡量提高可復用性。增加、刪除、修改。查詢對一個用戶來說是不會同時發生的，每次用戶只會完成其中的一個行為。分開來有利于詳細分析、模擬這一行為的細節而不至于混淆。就Web應用而言，針對數據的增加、刪除、修改、查詢等，很容易形成“模板”，增加用戶用這個模板，增加其它基礎數據可能也用同一個模板，只是操作的數據(實體)不同而已。因此，在這種情況下，這些模板是可以復用的。

（4）具體問題具體分析。查詢是比較特殊的，查詢一般不一定只局限于一類用戶，也不一定局限這個用例，一般都是所謂的綜合查詢，是可能跨用例的。比如管理員可以查詢學生學籍信息，學生也可以查詢自己的學籍信息。所以根據實際情況，查詢可以作為一個業務用例出現。

1.2.2 業務建模舉例

由于高職院校教學管理是十分龐大而復雜的，下面針對一小部分需求，進行業務建模。具體需求描述如下：

管理員登錄系統后，能夠維護(查找、增加、修改、刪除)學生信息，同時又能對教師的信息進行查詢和修改(查找、增加、修改、刪除)等。根據對用戶需求的總結和歸納，從管理員的角度以及從每項業務的角度來繪制業務用例圖。在上述功能點中，比較重要的操作如下：

（1）查詢學生信息；

（2）修改學生信息；

（3）增加學生信息；

（4）刪除學生信息；

（5）修改學生成績；

（6）查詢教師信息；

（7）修改教師信息；

（8）增加教師信息；

（9）刪除教師信息。

經過分析，用例的粒度以每個用例能夠說明一件完整的事情為宜。即一用例可以描述一項完整的業務流程得到的業務用例如下：

（1）學生信息維護(增加、刪除、修改)；

（2）教師信息維護(增加、刪除、修改)；

（3）學生信息查詢；

（4）教師信息查詢。

在具體分析業務用例的時候，可以使用UML提供的時序圖、協作圖、活動圖等來幫助分析系統業務。以用戶登錄系統為例，其時序圖、協作圖和活動圖分別如圖3、圖4和圖5所示。

圖3 用戶登錄時序圖

圖4 用戶登錄協作圖

圖5 用戶登錄活動圖

2 系統的安全設計

成績管理系統含有大量用戶信息，所以數據庫的安全就是一個必須要考慮的問題。保證系統安全涉及諸多方面，而對系統用戶進行正確驗證、實施權限管理則是保證系統安全的一項重要基礎工作。

管理員每次登錄系統都要輸入自己的登錄用戶名、密碼以及該用戶名所屬的那個用戶身份類別，系統可以進行身份驗證。通過驗證后，才會進入相應的系統界面，進行和該用戶身份相關的操作和管理。這樣可以避免出現非法用戶的數據訪問請求，也避免合法用戶的越權數據請求。

系統安全機制由兩部分組成：首先在用戶登錄系統時進行身份認證，防止非注冊用戶的訪問，并確定己登錄用戶的身份角色；然后，當用戶通過身份認證調用系統的操作時，對每個操作根據系統的訪問策略驗證用戶是否擁有相應的權限，為系統提供進一步的安全控制。

權限管理的設計原則是，對于擁有本系統使用權的用戶，系統根據承擔的職務，進行角色和權限分配。系統根據其角色，分配相應的系統操作權限，這樣當用戶登錄本系統后，只能看到屬于自己操作權限的系統，避免了操作者越權修改其職責之外的數據。

3 系統架構設計

高職院校成績管理系統是一個B/S架構系統，采用網絡應用標準的多層體系結構，每一層實現不同的系統功能。從系統架構上將整個系統分成表示層、業務邏輯層、數據持久層和域模型層。下面對系統各個層的設計及實現機制進行闡述。架構如圖6所示。

圖6 系統總體架構

（1）客戶層

客戶層運行在用戶的瀏覽器中提供了客戶與應用程序的交互方式，這些交互主要包括向Web層發出請求并接收由Web層發回的響應。

（2）表示層

表示層為客戶層同業務邏輯層進行通信提供了服務，負責從客戶層接受請求和向客戶層發送結果及顯示內容，只包含顯示邏輯。Web層主要采用MVC的技術架構。實現技術包括：Struts、Servlet、JSP、JSTL、ValueList、JavaScript，HTML，DHTML，CSS等。

Struts Action：Action類是業務邏輯的一個封裝，真正實現應用程序的業務邏輯。

Struts Form：用以封裝HTTP Request或Response中的數據。主要用于存放HTTP form提交的數據，也可用于JSP頁面的數據顯示。

（3）業務邏輯層

業務邏輯層是該整合架構的體系核心所在，它體現并處理企業的業務邏輯。處理Web層傳遞過來的用戶響應，實現業務邏輯，并將結果返回給Web層。所有的業務邏輯，都應存放在這一層，由Spring管理該層。

（4）數據持久層

本層在業務邏輯層之后，利用Spring和Hibernate，iBatis開發，主要負責實現與數據庫等系統連接，實現數據的管理和持久化。

（5）域模型層

由于本系統將Web應用劃分為了多個層次，就需要一系列的 Java對象來實現不同層之間的數據傳遞和交互。域模型層包含了真實世界中的業務對象。Hibernate允許將數據庫中的信息讀取到域模型對象中，以便于可以直接呈現在表示層的用戶界面中。這些對象還可以被更新并且傳回到持久層，最后更新到數據庫中。

4 小結

本文對高職院校成績管理系統做了一個簡要的概述之后，然后做了需求分析，最后做出了總體設計，鑒于本文的篇幅，系統的分析和設計只是在總體上做了簡單的闡述，并沒有給出很詳細的需求分析和設計文檔，需要我們在實踐中繼續完善。

[1]張春枝等.基于C/S與B/S混合模式的MIS系統設計[J].計算機應用研究.2001.

[2]袁華強,王亞強,朱君.利用J2EE輕量級框架構建Web應用研究[J].計算機工程與設計.2007.

[3]劉艷霞.J2EE項目中的數據持久層設計[J].工程地質計算機應用.2005.

[4]閻宏.Java與模式[M].北京：電子工業出版社.2002.

[5]魏學松,張育平.IoC 框架的研究與設計[J].計算機技術與發展.2006.

[6]夏聽.Spring開發指南0.8預覽版[M].2004.

[7]羅時飛.精通 Spring開發專家之 Sun One[M].北京：電子工業出版社.2005.