
項目工程實踐
請假系統設計與實現
學生姓名:學號:
系別:計算機系專業:計算機科學與技術
指導教師:
日期:2021年7月1日
目錄
1. 系統總體設計 3
1.1. 請假系統用例分析 3
1.1.1. 系統參與者 3
1.1.2. 用例分析 3
1.2. 系統領域對象識別 5
1.3. 數據庫設計 6
1.3.1. 數據庫實體聯系分析 6
1.3.2. 數據庫E-R模型圖 6
1.3.3. 數據庫表詳細設計 7
2. 系統詳細設計及實現 11
2.1. 系統初始化模塊設計與實現 11
2.2. 登錄模塊流程設計 12
2.3. 教師登錄設計與實現 15
2.3.1. 用戶名以及密碼校驗實現 15
2.3.2. 角色查找實現 15
2.3.3. 班主任角色查找實現 16
2.3.4. 權限查找實現 17
2.4. 學生登錄實現 17
2.5. 系統設置模塊設計與實現 18
2.5.1. 角色列表顯示設計與實現 18
2.5.2. 添加功能設計與實現 19
2.5.3. 修改功能設計與實現 19
2.5.4. 詳情功能設計與實現 20
2.5.5. 角色權限設置功能設計與實現 20
2.6. 學院管理設計與實現 22
2.6.1. 列表顯示設計與實現 22
2.6.2. 添加功能設計與實現 22
2.6.3. 修改功能設計與實現 23
2.6.4. 詳情功能設計與實現 24
2.7. 班級管理設計與實現 24
2.7.1. 列表顯示與綜合查詢設計與實現 24
2.7.2. 分頁顯示設計與實現 26
2.7.3. 添加功能設計與實現 26
2.7.4. 修改功能設計與實現 27
2.7.5. 詳情功能設計與實現 27
2.8. 教師管理設計與實現 28
2.8.1. 列表顯示與綜合查詢功能實現 28
2.8.2. 添加功能設計與實現 29
2.8.3. 修改功能設計與實現 30
2.8.4. 詳情頁面設計與實現 31
2.8.5. 教師角色配置功能設計與實現 31
2.9. 學生管理模塊設計與實現 32
2.9.1. 列表顯示與綜合查詢功能實現 32
2.9.1.1. 學院、年級、班級的級聯顯示實現 34
2.9.2. 添加功能設計與實現 34
2.9.3. 修改功能設計與實現 35
2.9.4. 詳情功能設計與實現 35
2.10. 請假申請模塊實現 36
2.10.1. 列表顯示與綜合查詢功能實現 36
2.10.2. 添加功能實現 37
2.10.3. 修改功能實現 38
2.10.4. 詳情功能實現 38
2.11. 請假審批功能設計與實現 39
2.11.1. 班主任審批功能設計與實現 39
2.11.2. 輔導員、院領導審批功能設計與實現 41
2.12. 銷假功能設計與實現 43
2.12.1. 學生銷假設計與實現 43
2.12.2. 教師銷假設計與實現 44
請假系統設計與實現
-
系統總體設計
-
請假系統用例分析
-
系統參與者
請假系統的用戶包括:系統管理員、學生、班主任、輔導員、二級學院領導。
-
用例分析
- 系統管理員用例分析
-
-

圖1.1 系統管理員用例圖
- 學院信息管理
包括添加、修改、查詢學院信息
- 班級信息管理
包括添加、修改、查詢班級信息
- 學生信息管理
包括添加、修改、查詢學生信息
- 教師信息管理
包括添加、修改、查詢教師信息,指定教師角色(即班主任、輔導員、學院領導,一個教師可以有多個角色)
- 角色信息管理
包括添加、修改、查詢角色基本信息。添加、修改、查詢角色權限。
- 學生用例分析

圖1.2 學生用例圖
- 班主任用例分析

圖1.3 班主任用例圖
- 輔導員用例分析

圖1.4 輔導員用例圖
- 學院領導用例分析

圖1.5 學院領導用例圖
-
系統領域對象識別
本系統中參與的人員包括:
- 學生、教師
根據用例分析,本系統中的角色包括:
- 系統管理員、學生、班主任、輔導員、學院領導
組織包括:
- 學院、班級
物品包括:
- 菜單
時間包括:
- 請假申請、請假審批
規格說明:
- 菜單類型——1、模塊 2、菜單項 3、按鈕
- 審批狀態——1、待審批 2、班主任審批通過 3、輔導員審批通過 4、審批通過5、審批未通過 6、結束
- 性別——1、男 2、女 3、未知
- 請假類型——1、一天以內 2、一天以外三天以內 3、三天以外 4、出恩施州
-
數據庫設計
-
數據庫實體聯系分析
-
數據庫表包括實體表以及實體之間的聯系表,本系統中的實體即我們在系統領用對象識別中所分析的實體之間的聯系包括1對1、1對多和多對多。只有在多對多的情況下才需要建立專門的聯系表,本系統中的聯系包括:
- 學院與班級——1對多
- 班級與學生——1對多
- 學院與教師——1對多
- 教師與角色——多對多(因此需要建立一張用戶角色的聯系表)
- 學生與角色——1對1(給學生一個默認角色,角色名叫學生)
- 請假申請與學生——1對多
- 請假申請與審批——1對多
- 請假審批與教師——1對多
- 請假審批與審批類型——1對1
-
數據庫E-R模型圖
根據1.3.1的分析,請假系統E-R模型圖如下:

圖1.6 請假系統E-R模型圖
-
數據庫表詳細設計
- 請假狀態表application_status
| 字段名 |
類型 |
說明 |
| id |
tinyint |
記錄id |
| applicationResult |
varchar |
審批結果 |
表1.1 請假狀態表application_status
- 同意類型表aprove_type
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
是否同意名稱 |
表1.2 同意類型表aprove_type
- 班級表class
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| num |
varchar |
班級編號 |
| gradeId |
int |
年級ID |
| belongToCollegeId |
int |
所屬學院 |
| banZhuRenId |
int |
班主任id |
表1.3班級表class
- 學院表college
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
學院名稱 |
| num |
char |
學院編號 |
| tel |
varchar |
學院座機 |
表1.4 學院表college
- 年級表grade
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| grade |
int |
年級 |
表1.5 年級表grade
- 請假記錄表leave_application
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| studentId |
int |
請假學生id |
| type |
tinyint |
請假類型 |
| path |
varchar |
路線 |
| reason |
varchar |
請假事由 |
| begintime |
datetime |
開始時間 |
| endtime |
datetime |
結束時間 |
| status |
tinyint |
申請狀態 |
| img |
varchar |
銷假圖片 |
表1.6 請假記錄表leave_applicatio
- 審批表leave_application_shen_pi
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| applicationId |
int |
請假申請id |
| teacherId |
int |
審批教師id |
| result |
tinyint |
審批結果 |
| opinion |
varchar |
審批意見 |
表1.7 審批表leave_application_shen_pi
- 請假類型表leave_application_type
| 字段名 |
類型 |
說明 |
| id |
tinyint |
記錄id |
| name |
varchar |
請假類型 |
表1.8 請假類型表leave_application_type
- 菜單表menu
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
菜單名 |
| permission |
varchar |
權限字符串 |
| pid |
int |
直接父菜單id |
| pids |
varchar |
父菜單 |
表1.9 菜單表menu
- 菜單類型表menu_type
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
菜單類型名稱 |
表1.10 菜單類型表menu_type
- 角色表role
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
角色名 |
| remark |
varchar |
說明 |
| eareType |
tinyint |
角色類型 |
表1.11 角色表role
- 角色菜單表role_menu
| 字段名 |
類型 |
說明 |
| roleId |
int |
角色id |
| menuId |
int |
菜單id |
表1.12 角色菜單表role_menu
- 角色類型表role_type
| 字段名 |
類型 |
說明 |
| Id |
tinyint |
記錄id |
| name |
varchar |
角色名稱 |
表1.13 角色類型表role_type
- 性別表sex_type
| 字段名 |
類型 |
說明 |
| Id |
tinyint |
記錄id |
| name |
varchar |
性別類型 |
表1.14 性別表sex_type
- 學生表student
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
姓名 |
| num |
varchar |
學號 |
| password |
char |
密碼 |
| classId |
int |
班級id |
| sex |
tinyint |
性別 |
表1.15 學生表student
- 教師表teacher
| 字段名 |
類型 |
說明 |
| id |
int |
記錄id |
| name |
varchar |
教師名 |
| num |
varchar |
學院編號 |
| password |
char |
密碼 |
| collegeId |
int |
學院id |
| phone |
varchar |
電話 |
表1.16 教師表teacher
- 用戶角色表user_role
| 字段名 |
類型 |
說明 |
| userid |
int |
用戶id |
| roleid |
int |
角色id |
表1.17 用戶角色表user_role
-
系統詳細設計及實現
-
系統初始化模塊設計與實現
-
系統初始化的目的是,在系統實現時,對於系統中經常會使用的某些信息.比如本系統中的性別類別(1、男 2、女 3、未知)。請假申請類別(1、一天以內 2、一天以外三天以內 3、三天以外 4、出恩施)等數據)。這些數據的特點是數據量不大,但是在后台代碼和頁面中會頻繁使用。因此在系統設計時,實現一個InitServlet,並在InitServlet的init方法中將這些數據加載到ServletContext中(在jsp頁面中可以使用applicationScope來訪問ServletContext中的數據)。
我們將性別類型、菜單類別、角色類別、申請類別、審批結果類別這五種數據在InitServlet中加載到ServletContext中。
系統初始化模塊包括InitServlet、InitParamService、InitParamDAO三個實現類。
- 讀取性別數據時序圖:

圖2.1 讀取性別數據時序圖
- 讀取菜單類別時序圖:

圖2.2 讀取菜單類別時序圖
- 讀取申請類別時序圖:

圖2.3 讀取申請類別時序圖
角色類別、審批結果時序圖同上,調用的方法依次為:
getRoleType()
getLeaveApplicationResultType()
-
登錄模塊流程設計
登錄模塊,首先根據登錄賬號,判斷是教師登錄還是學生登錄。然后分別執行教師登錄和學生登錄的流程。登錄模塊在用戶名和密碼校驗成功后,需要查詢用戶角色以及權限以及其他信息。並定義一個保存這些信息的類。創建這個類的對象,將查詢出來的信息保存到這個對象中,最后將這個對象保存到HttpSession中。
定義保存登錄信息的類:QingjiaSession,代碼如下:
| /** * 請假session * 主要用於記錄用戶的登錄信息,返回至jsp頁面讀取 * @author xcz */ public class QingjiaSession { //用戶類型常量 public static int USER_TYPE_TEACHER = 1; public static int USER_TYPE_STUDENT = 2; //數據訪問域常量 public static final int DATA_AREA_PERSON = 1; //個人 public static final int DATA_AREA_CLASS = 2; //班級 public static final int DATA_AREA_COLLEGE = 3; //學院 public static final int DATA_AREA_SYSTEM = 4; //系統 //請假session字符串 public static final String QINGJIA_SESSION = "qSession"; //權限 private Set<String> permissiones; //用戶類型 1:教師 2:學生 private int userType; //學生信息 private Student student; //教師信息 private Teacher teacher; //用戶角色 private List<Role> roles; //班主任管理的班級id private String manageClasse; //班主任管理的班級或學生所在班級 private List<Clazz> clazzes; //班主任所管理班級的年級 private List<Grade> grades; //學院id private int collegeId; //班級id private int classId; //學生所在班級 private Clazz clazz; //是否是班主任 private boolean isBanzhuren; //是否是輔導員 private boolean isFudaoyuan; //是否是領導 private boolean isXueyuanLingdao; //數據訪問域范圍(默認范圍是個人) private int dataArea = DATA_AREA_PERSON; } |
在會話中保存這些數據的目的是,將用戶的相關屬性保存到會話中。例如:教師所屬的學院id、教師是否是班主任(如果是,班主任管理的班級信息)、教師的角色、教師的權限.這些信息在系統后續的設計與實現中會起到至關重要的作用。例如、前台頁面會根據學生的權限來判斷頁面上哪些菜單會顯示、哪些按鈕會顯示。在查詢數據是會對查詢出來的數據進行限定。比如具有輔導員角色的用戶登錄時,會根據輔導員的學院id來查詢請假申請記錄,以便輔導員來進行審批。
作為教師角色,在會話中需要保存的信息包括:
權限(permissiones)、用戶類型(userType)、教師信息(teacher)、用戶角色(roles)、班主任管理的班級id(manageClasse)、班主任管理的班級或學生所在班級(clazzes)、班主任所管理班級的年級(grades)、是否是班主任(isBanzhuren)、是否是輔導員(isFudaoyuan)、是否是領導(isXueyuanLingdao)、數據訪問域范圍(dataArea)
作為學生角色,在會話中需要保存的信息包括:
權限(permissiones)、用戶類型(userType)、學生信息(student)、用戶角色(roles)、班級id(classId)、學生所在班級(clazz)、數據訪問域范圍(dataArea)
-
教師登錄設計與實現
-
用戶名以及密碼校驗實現
-
用戶登錄首先會對用戶類型進行判斷,如果在教室表中查詢到該用戶,則說明是教師,緊接着會查詢該教師的密碼是否與輸入的密碼匹配一直,如果一致則登錄成功,反之登錄失敗。

圖2.4 密碼校驗流程圖
-
角色查找實現
角色查找主要是根據教師id來查詢角色類型,查詢時會先查詢出教師對應的角色id,對應的SQL語句為:
select roleid from user_role where userid = ?
角色查找時序圖:
圖2.5 角色查找時序圖
-
班主任角色查找實現
在角色查找的基礎上,班主任角色查找是根據查詢出來的角色id來匹配對應的角色,由於一個教師可能有多個角色,所以使用SQL語句的in方式查詢,對應的SQL語句為:
SELECT * FROM role WHERE role.id in (?)
查詢出來的角色后,如果發現該教師有班主任角色,則會查詢對應的班級信息,將查詢到的班級對象進行循環遍歷,並生成一個由班級id組成的字符串,用於后期對該班級的查詢,其代碼為:
| //循環讀取班級id,並添加到字符串對象中 for (Clazz clazz : clazzs) { strClasses.append(clazz.getId());//將班級id添加到字符串對象中 strClasses.append(",");//添加一個逗號 strGrades.append(clazz.getGradeId());//將年級id添加到字符串中 strGrades.append(",");//添加一個逗號 } |
-
權限查找實現
權限查找根據教師id查詢對應的菜單權限,並設置到session中,設計SQL語句如下:
SELECT
menu.permission
FROM
menu
WHERE
id IN (
SELECT
role_menu.menuId
FROM
role_menu
WHERE
roleId IN ( SELECT roleid FROM user_role WHERE userid = ? )
)
權限查找時序圖:

圖2.6 權限查找時序圖
-
學生登錄實現
學生登錄首先會進行賬號、密碼想要數據校驗,通過后會直接賦予學生身份,讀取學生班級信息存放到班級集合中,並將學生的權限字符串保存到QingjiaSession中,而后跳轉至主頁面。
學生登錄流程圖:

圖2.7 學生登錄流程圖
-
系統設置模塊設計與實現
系統設置模塊包括:角色列表顯示、添加角色、修改角色、角色詳情、角色權限設置五個功能。
-
角色列表顯示設計與實現
角色列表顯示首先需要創建角色的list.jsp頁面,並設置好需要顯示的值:編號、角色名、備注、管理域、操作等相關信息,調用RoleService的getAll方法將其全部角色信息進行查詢並返回,保存到角色集合中roles。
角色列表效果圖:

圖2.8 修改權限流程圖
RoleDao的getAll方法查詢語句為:
SELECT * FROM role
-
添加功能設計與實現
用戶點擊添加按鈕跳轉至添加頁面(add.jsp),並展示輸入表單:
圖2.9 添加角色
而后用戶輸入數據后點擊確認保存,執行添加操作,RoleDao使用的SQL語句為:
INSERT into role VALUES(null,?,?,?)
添加操作時序圖:

圖2.10 添加角色時序圖
-
修改功能設計與實現
當用戶點擊修改角色時,會根據用戶點擊的角色列表id查詢對應的角色數據,並將其保存到request中,跳轉至修改頁面,隨之修改頁面會將傳遞過來的數據解析並填充到表單默認值,效果如下:

圖2.11 修改角色
角色id,並不會顯示在修改數據中,會作為隱藏控件存儲到表單中。當用戶輸入修改后的數據並點擊確認保存時,系統會讀取當前用戶所填寫的數據並執行修改操作,具體的SQL代碼為:
UPDATE role SET name=?,remark =?,eareType=? WHERE id=?
-
詳情功能設計與實現
當用戶點擊對應記錄的詳情按鈕后,會根據該記錄的id跳轉到RoleServlet類調用getById()方法查詢角色信息后保存到request中,最后返回到詳情頁面進行顯示,涉及到的SQL代碼為:
SELECT * FROM role WHERE id=?
-
角色權限設置功能設計與實現
當用戶點擊對應的權限設置后,首先會得到需要被授權角色id,然后會查詢當前系統中的全部權限,再根據角色id查詢該角色已有的權限,最后將用戶權限和所有權限保存request中,並跳轉到授權頁面:

圖2.12 顯示角色已有權限
隨后用戶可以根據需求對角色的每一個模塊進行授權,沒有權限則相應的控件不會顯示。提交數據后會跳轉至的RoleServlet類的doAuthorize()執行授權方法,使用request的getParameterValues來批量獲取提交的權限數據,並將id與權限數組傳遞至updateRolePermissionById方法進行授權操作,在授權之前,需要先將該角色之前的權限全部刪除,而后再循環遍歷新權限數組,對每一個權限執行插入,保存到role_menu表中。由於兩個操作可能會存在中斷出錯的現象,所以需要使用到事務,在語句執行之前需要將自動提交設置為假setAutoCommit(false),如果兩次語句都執行成功才能使用commit提交,否則使用rollback回滾數據。

圖2.13 查詢角色權限時序圖
修改角色權限流程圖:

圖2.14 修改權限流程圖
刪除原有權限:
| //刪除權限SQL語句 String sql="DELETE FROM role_menu WHERE roleId=?"; //初始化查詢 psm=JdbcUtil.getPreparedStatement(conn, sql); //設置參數 psm.setInt(1,roleId); //執行 psm.execute(); |
添加新權限:
| //循環遍歷權限 for (String permission : permissiones) { //刪除權限SQL語句 String sql="INSERT INTO role_menu(roleId,menuId) VALUES (?,?)"; //初始化查詢 psm=JdbcUtil.getPreparedStatement(conn, sql); //設置參數 psm.setInt(1,roleId); psm.setString(2,permission); //獲取執行結果 psm.execute(); } |
-
學院管理設計與實現
-
列表顯示設計與實現
-
學院列表顯示首先需要創建角色的list.jsp頁面,並設置好需要顯示的值:編號、學院編號、學院名稱、操作等相關信息,調用CollegeService的getAll方法將其全部學院信息進行查詢並返回,保存到學院集合中colleges。
學院列表效果圖:
圖2.15 修改權限流程圖
CollegeDao的getAll方法查詢語句為:
SELECT * FROM college
-
添加功能設計與實現
用戶點擊添加按鈕跳轉至添加頁面(add.jsp),並展示輸入表單:
圖2.16 添加角色
而后用戶輸入數據后點擊確認保存,執行添加操作,CollegeDao使用的SQL語句為:
INSERT into college VALUES(null,?,?,?)
添加操作時序圖:

圖2.17 添加學院時序圖
-
修改功能設計與實現
當用戶點擊修改學院時,會根據用戶點擊的學院列表id查詢對應的學院數據,並將其保存到request中,跳轉至修改頁面,隨之修改頁面會將傳遞過來的數據解析並填充到表單默認值,效果如下:

圖2.18 修改學院
學院id並不會顯示在修改數據中,會作為隱藏控件存儲到表單中:

圖2.19 學院id控件
當用戶輸入修改后的數據並點擊確認保存時,系統會讀取當前用戶所填寫的數據並執行修改操作,具體的SQL代碼為:
UPDATE college SET name=?,num =?,tel=? WHERE id=?
-
詳情功能設計與實現
當用戶點擊對應記錄的詳情按鈕后,會根據該記錄的id跳轉到CollegeServlet類調用getById()方法查詢學院信息后保存到request中,最后返回到詳情頁面進行顯示,涉及到的SQL代碼為:
SELECT * FROM college WHERE id=?
圖2.20 學院詳情
-
班級管理設計與實現
-
列表顯示與綜合查詢設計與實現
-
班級列表顯示首先需要創建角色的list.jsp頁面,並設置好需要顯示的值:編號、班級編號、所屬年級、所屬學院、所班主任、操作等相關信息,顯示班級時,需要根據當前用戶信息顯示具體的班級,比如學生只能顯示自己的班級信息,班主任則只能顯示自己班的班級信息,而學院領導則只能顯示本學院的班級信息。
首先進入查詢班級頁面需要對當前登錄用戶進行權限判斷,這里需要調用getWhereClause()方法根據不同角色生成不同的查詢語句,訪問域為個人、班級、學院、系統所生成的SQL語句都不一樣,查詢時再將SQL語句傳入DAO進行查詢班級數據,關鍵代碼如下:
| //批量判斷訪問域 switch (dataArea) { case QingjiaSession.DATA_AREA_PERSON://個人訪問域 { //判斷是否是學生 if (qSession.getUserType()==QingjiaSession.USER_TYPE_STUDENT) { //得到學生信息 Student student=qSession.getStudent(); //生成SQL條件 whereClause.append("id="+student.getClassId()); }else if (qSession.getUserType()==QingjiaSession.USER_TYPE_TEACHER) {//判斷是否是老師 //生成SQL條件 whereClause.append("belongToCollegeId="+qSession.getCollegeId()); } break; } case QingjiaSession.DATA_AREA_CLASS://班級訪問域 { //生成SQL條件,班主任只能訪問自己班的班級信息 whereClause.append("id in ("+qSession.getManageClasse()+")"); break; } case QingjiaSession.DATA_AREA_COLLEGE://學院訪問域 { //生成SQL條件 whereClause.append("belongToCollegeId="+qSession.getCollegeId()); break; } case QingjiaSession.DATA_AREA_SYSTEM://系統訪問域 { return null; } default: break; } |
班級列表效果圖:
圖2.21 班級列表效果圖
顯示班級列表時,需要根據用戶權限顯示不同的查詢班級下拉框,會分別調用ClazzService的getGrade()方法和CollegeService的getAll()方法,對查詢到的數據顯示至查詢下拉列表:

圖2.22 查詢班級效圖
查詢數據時,可能出現四種選擇情況,所以需要對四種情況查詢數據進行分開處理,並生成SQL語句進行查詢,代碼如下:
查詢數據流程圖:

-
分頁顯示設計與實現
考慮到數據較多的情況,實現分頁功能可以提高用戶體驗,首先創建分頁類Page擁有屬性頁面號(pageNo)、頁面大小(pageSize)、總頁面(totalPages)、總記錄數(totalRecord)。並且創建頁面攔截器類(PageFilter),該攔截器能夠對用戶請求URL解析,如果發現page字段,說明用戶請求需要分頁,再根據當前最大頁和記錄數計算總頁面數。
攔截器運行流程圖:

圖2.23 攔截器運行流程圖
-
添加功能設計與實現
用戶點擊添加按鈕跳轉至添加頁面(add.jsp),並同時讀取數據庫中的年級和學院數據,分別調用ClazzService的getGrade()和CollegeService的getAll()方法來查詢學院和年級信息保存到request中,並在jsp頁面使用c:forEach遍歷班級和學院信息展示至表單下拉列表:
|
圖2.24 添加班級 |
圖2.25 下拉列表 |
而后用戶輸入數據后點擊確認保存,執行添加操作,CollegeDao使用的SQL語句為:
INSERT into class(num,gradeId,belongToCollegeId) VALUES(?,?,?)
添加操作時序圖:

圖2.26 添加班級時序圖
-
修改功能設計與實現
當用戶點擊修改班級時,會根據用戶點擊的班級列表id查詢對應的班級數據,並將其保存到request中,跳轉至修改頁面,隨之修改頁面會將傳遞過來的數據解析並填充到表單默認值,效果如下:

圖2.27 修改班級
同理,班級id並不會顯示在修改數據中,會作為隱藏控件存儲到表單中。
當用戶輸入修改后的數據並點擊確認保存時,系統會讀取當前用戶所填寫的數據並執行修改操作,具體的SQL代碼為:
UPDATE class SET num=?,gradeId =? ,belongToCollegeId=? WHERE id=?
-
詳情功能設計與實現
由於班級詳情不僅僅顯示班級信息,當用戶點擊對應記錄的詳情按鈕后,會根據該記錄的id跳轉到ClassServlet類調用getDetialById ()方法查詢班級視圖信息后保存到request中,最后返回到詳情頁面進行顯示,涉及到的SQL代碼為:
SELECT * FROM class_view WHERE id=?
班級詳情視圖的設計:

圖2.28 班級詳情視圖設計
設計班級詳情頁面時,考慮到用戶可能會根據班級查看學院詳情,則學院信息使用a標簽鏈接至學院詳情頁面,具體效果圖:
圖2.29 班級詳情
-
教師管理設計與實現
-
列表顯示與綜合查詢功能實現
-
教師列表顯示首先需要創建教師的list.jsp頁面,並設置好需要顯示的值:編號、姓名、工號、所屬學院、電話、操作等相關信息,其中根據需要,將所屬學院使用a標簽鏈接至詳情頁面,實現點擊對應學院即可查看其教師所在學院詳情。
教師列表效果圖:
圖2.30 教師列表效果圖
顯示教師列表時,需要動態顯示學院的查詢下拉框,會調用CollegeService的getAll()方法,對查詢到的學院數據顯示至查詢下拉列表:

圖2.31 查詢教師效果圖
查詢數據時,可能出現四種選擇情況,所以需要對四種情況查詢數據進行分開處理,並生成SQL語句進行查詢,流程圖如下:

圖2.32 查詢教師SQL語句拼接流程圖
-
添加功能設計與實現
用戶點擊添加按鈕跳轉至添加頁面(add.jsp),並同時讀取數據庫中的學院數據,調用CollegeService的getAll()方法來年級信息保存到request中,並在jsp頁面使用c:forEach遍歷學院信息展示至表單下拉列表:
|
圖2.33 添加教師 |
而后用戶輸入數據后點擊確認保存,執行添加操作,結合實際操作考慮,新添加的教師密碼默認為教師編號較為合理,故添加教師無須輸入密碼,默認使用教師編號設置為密碼,TeacherDao使用的SQL語句為:
INSERT INTO teacher(`name`,num,`password`,collegeId,phone) VALUES(?,?,?,?,?)
-
修改功能設計與實現
當用戶點擊修改教師時,會根據用戶點擊教師列表id查詢對應的教師數據,並將其保存到request中,跳轉至修改頁面,隨之修改頁面會將傳遞過來的數據解析並填充到表單默認值,效果如下:

圖2.34 修改教師
同理,教師id並不會顯示在修改數據中,會作為隱藏控件存儲到表單中。
當用戶輸入修改后的數據並點擊確認保存時,系統會讀取當前用戶所填寫的數據並執行修改操作,具體的SQL代碼為:
UPDATE teacher SET name=?,num =?,collegeId=?,phone=? WHERE id=?
-
詳情頁面設計與實現
當用戶點擊對應記錄的詳情按鈕后,會根據該記錄的id跳轉到TeacherServlet類調用getById()方法查詢學院信息后保存到request中,最后返回到詳情頁面進行顯示,涉及到的SQL代碼為:
SELECT * FROM teacher_view WHERE id=?
顯示詳情時,同時會查詢教師所在的學院名稱,為了方便展示,所以創建了Teacher_view視圖,用於顯示教師詳情,班級詳情視圖的設計:

圖2.35 教師詳情視圖設計
教師詳情效果圖:
圖2.36 教師詳情效果圖
-
教師角色配置功能設計與實現
當用戶點擊對應教師的指定角色按鈕時,程序首先會來到TeacherServlet的role方法,取出全部角色信息用於前台展示。
指定角色時序圖:

圖2.37 指定角色時序圖
由於一個教師可能存在多個角色,所以使用多選框來展示角色信息:

圖2.38 指定角色效果圖
為教師指定角色時,需要先獲取用戶填寫的角色數組,然后刪除原有角色信息,再添加新的角色信息,所以此項操作涉及到事務。
指定角色流程圖:

圖2.39 指定角色流程圖
-
學生管理模塊設計與實現
-
列表顯示與綜合查詢功能實現
-
學生列表顯示首先需要創建學生的list.jsp頁面,並設置好需要顯示的值:編號、姓名、學號、班級、性別、操作等相關信息,其中根據需要,將所屬班級使用a標簽鏈接至詳情頁面,實現點擊對應班級編號即可查看其學生所在班級詳情。
學生列表效果圖:
圖2.40 學生列表效果圖
由於查詢學生較為特殊,涉及到的條件繁多,所以對應的SQL語句設計邏輯也就非常關鍵,所以需要對四種情況查詢數據進行分開處理,並生成SQL語句進行查詢,流程圖如下:

圖2.41 查詢學生流程圖
-
學院、年級、班級的級聯顯示實現
顯示學生列表時,需要動態顯示學院、年級、班級的查詢下拉框,會依次調用CollegeService的getByRequest ()方法、ClazzService的getGrade()方法以及ClazzService的getByCollegeAndGrade()方法,其中查詢班級只能顯示當前學院和年級所約束的班級,這里需要通過ajax根據用戶實時選擇的數據動態查詢班級信息並展示至前台頁面,對查詢到的數據顯示至查詢下拉列表:

圖2.42 查詢教師效果圖
使用ajax動態查詢班級:
| $.ajax({ type:"POST", url:"ClassServlet", data:postData, success:function(msg){ //解析json字符串到對象 var $classes=jQuery.parseJSON(msg); //得到班級選擇框 var $clazz=$("#clazz"); //先清空所有的子元素 $clazz.empty(); //設置初始標簽 $("<option>",{ value:"0", text:"全部" }).appendTo($clazz) //循環遍歷每個對象 $.each($classes,function(i,clazz){ //每次循環添加元素 $("<option>",{ value:clazz.id, text:clazz.num }).appendTo($clazz) }); } }); |
-
添加功能設計與實現
用戶點擊添加按鈕跳轉至添加頁面(add.jsp),並同時讀取數據庫中的學院、年級數據,分別調用CollegeService的getAll()、ClazzService的getGrade()方法來將學院和年級信息保存到request中,並在jsp頁面使用c:forEach遍歷學院信息展示至表單下拉列表:
|
圖2.43 添加學生效果圖 |
圖2.44 默認學院數據效果圖 |
|
而后用戶輸入數據后點擊確認保存,執行添加操作,結合實際操作考慮,新添加的學生密碼默認為學生學號較為合理,故添加學生無須輸入密碼,默認使用學號設置為密碼,StudentDao使用的SQL語句為:
INSERT INTO student(`name`,num,`password`,classId,sex) VALUES(?,?,?,?,?)
-
修改功能設計與實現
當用戶點擊修改學生時,會根據用戶點擊學生列表id查詢對應的學生數據,並將其保存到request中,跳轉至修改頁面,隨之修改頁面會將傳遞過來的數據解析並填充到表單默認值,效果如下:

圖2.45 修改學生
同理,學生id並不會顯示在修改數據中,會作為隱藏控件存儲到表單中。
當用戶輸入修改后的數據並點擊確認保存時,系統會讀取當前用戶所填寫的數據並執行修改操作,具體的SQL代碼為:
UPDATE student SET name=?,num =?,classId=?,sex=? WHERE id=?
-
詳情功能設計與實現
由於數據庫存儲的學生性別只是性別表的編號,所以查詢學生詳情時,需要使用聯合查詢,為了方便操作,特設計詳情頁面視圖,詳情視圖不僅僅用作為顯示詳情頁面,也可用作於后期查詢學生數據,很大程度上減少了工作量。當用戶點擊對應記錄的詳情按鈕后,會根據該記錄的id跳轉到StudentServlet類調用getById ()方法查詢學生視圖信息后保存到request中,最后返回到詳情頁面進行顯示,涉及到的SQL代碼為:
SELECT * FROM student_view WHERE id=?
學生詳情視圖的設計:

圖2.46 學生詳情視圖設計
設計班級詳情頁面時,考慮到用戶可能會根據班級編號查看班級詳情,則班級信息使用a標簽鏈接至班級詳情頁面,具體效果圖:
圖2.47 學生詳情
-
請假申請模塊實現
-
列表顯示與綜合查詢功能實現
-
請假申請列表僅限學生身份登錄才能查看,首先需要創建list.jsp頁面,並設置好需要顯示的值:編號、姓名、學號、出校日期、歸校日期、狀態、操作等相關信息,其中根據需要,將學生姓名使用a標簽鏈接至詳情頁面,實現點擊對應姓名即可查看其學生詳情。
請假列表效果圖:
圖2.48 請假列表效果圖
查詢數據時,會根據當前登錄的學生信息以及用戶選擇的申請狀態來進行聯合查詢,所有接收數據后需要對兩個數據進行處理后再根據情況生成SQL語句進行查詢,流程如下:

圖2.49 查詢請假記錄流程圖
-
添加功能實現
用戶點擊添加按鈕跳轉至添加頁面(add.jsp),並同時讀取登錄時用於初始化的InitServlet類獲取的常量請假類型數據,由於請假涉及到了時間數據的處理,需要在表單中添加datetime-local類型控件,用於顯示時間日期,且在后台處理中新建一個DateUtil類,用於處理日期時間與String類型的相互轉換以及對網頁格式的日期時間類型轉換。添加請假信息效果圖:

圖2.50 添加請假效果圖
而后用戶輸入數據后點擊確認保存,執行添加操作,LeaveApplicationDao的add()方法使用的SQL語句為:
INSERT INTO leave_application (studentId, `type`, path, reason, begintime, endtime, `status`)
VALUES
(?,?,?,?,?,?,?)
-
修改功能實現
學生需要修改請假信息只能在該請假信息還沒有被審批時才能修改,所以在設計修改請假時,需要根據當前請假信息狀態來判斷是否展示修改請假按鈕。當用戶點擊修改請假信息時,會根據用戶點擊請假記錄列表id查詢對應的請假數據,並將其保存到request中,跳轉至修改頁面,隨之修改頁面會將傳遞過來的數據解析並填充到表單默認值,效果如下:

圖2.51 修改請假
同理,該記錄id不會顯示在修改數據中,會作為隱藏控件存儲到表單中。
當用戶輸入修改后的數據並點擊確認保存時,系統會讀取當前用戶所填寫的數據並執行修改操作,具體的SQL代碼為:
UPDATE leave_application
SET `type`=?,path=?,reason=?,begintime=?,endtime=?
WHERE id=?
-
詳情功能實現
由於請假詳情不僅僅顯示請假信息,還有學生信息、審批情況等,當用戶點擊對應記錄的詳情按鈕后,會根據該記錄的id跳轉到LeaveApplicationService類調用getShenpiesById ()方法查詢請假詳情視圖信息后保存到request中,最后返回到詳情頁面進行顯示,涉及到的SQL代碼為:
SELECT * FROM leave_application_shen_pi_view WHERE applicationId=?
請假詳情視圖的設計:

圖2.52 請假詳情視圖設計
設計請假申請詳情頁面時,考慮到用戶可能會根據學生或班主任姓名查看詳情,則姓名信息使用a標簽鏈接至學院詳情頁面,具體效果圖:
圖2.53 審批詳情效果圖
-
請假審批功能設計與實現
-
班主任審批功能設計與實現
-
班主任審批功能僅對具有班主任角色的教師開放,如不是則不顯示班主任審批功能,當用戶進入主界面時,需要對當前登錄用戶的角色進行識別。當用戶點擊進入審批頁面后,會讀取教師id並且通過該教師id判斷是否為班主任,如果是則會查詢該班主任所管理的班級學生的所有需要審批的數據,審批時序圖如下:
圖2.54 班主任審批時序圖
審批效果圖:

圖2.55 審批效果圖

圖2.56 審批流程跨職能協作圖
-
輔導員、院領導審批功能設計與實現
輔導員審批功能與班主任審批功能大體一致,區別在於查詢學生數據范圍不一樣,班主任查詢的是自己班級的學生,而輔導員和院領導所查詢的是所屬學院的學生請假記錄,其時序圖為:

圖2.57 輔導員、院領導審批時序圖
審批流程圖如下:

圖2.58審批流程圖
-
銷假功能設計與實現
-
學生銷假設計與實現
-
當學生的請假記錄為審批通過狀態時,則可以銷假,請假數據表中字段"img"用於存儲該請假記錄學生所上傳的銷假照片文件名。銷假邏輯為學生歸校后前往修遠樓任意教室拍攝當前教室時鍾顯示時間的照片上傳至服務器,等待教師審核。
該功能需要在服務器的tomcat配置虛擬目錄,使其能夠對服務器內容文件映射,顯示至前台頁面,具體操作:
打開tomcat的server.xml文件,並在其Host字段中添加如下配置:
| <Context docBase="D:\臨時\eclipse\image" path="/img" reloadable="true"/> |
其中docBase屬性為需要映射的服務器文件夾絕對路徑,path屬性為映射后的URL地址。
由於涉及到文件上傳功能,所以需要導入響應jar包,加快了功能實現進度。
學生上傳照片頁面設計:

圖2.59審批流程圖
當點擊提交后,文件會以Post方式提交至服務器,當數據提交至服務器后,服務器對客戶端傳遞過來的參數進行遍歷,如果為文件字段會以當前請假記錄id為名稱,保存值服務器,並獲取其請假記錄id,將其文件名稱寫入數據庫,等待教師審核。

圖2.60 學生銷假流程圖
-
教師銷假設計與實現
當教師進入審批頁面后,系統會查詢該教師所管理班級或學院的學生請假數據和審批數據,會將未處理的數據顯示在審批列表,查詢提交銷假申請邏輯為:如果"img"字段內容不為空,且請假記錄狀態不會結束狀態,則表名學生已上傳銷假照片,等待教師審批銷假。
教師打開審批頁面會查詢需要審批或銷假記錄:

圖2.61 教師銷假列表
教師銷假詳情頁:

圖2.62 教師銷假詳情頁
當教師點擊同意銷假后,會提交請假記錄id至服務器,將請假狀態設置為結束。至此,整個審批流程結束。
論文、源程序:https://xiaochengzi.lanzoui.com/iU2hLs2fhqd





