1、前言
在上一次作業中，主要是對基於請假流程管理的OA系統進行了需求分析與建模；本次將在此基礎上更進一步，對項目進行詳細分析與設計，給出項目的軟件設計方案，從而為后續的具體編碼實現做好准備。
2、系統體系結構設計
2.1、系統軟件架構
本項目是一個典型的基於瀏覽器（browser）和服務器（server）的Web應用，因此本系統選擇采用Web開發領域經典的MVC架構進行架構設計。MVC（Model View Controller）是模型（Model）-視圖（View）-控制器（controller）的縮寫，是一種軟件設計典范。MVC用一種業務邏輯、數據、界面顯示分離的方法組織代碼，將業務邏輯聚集到一個部件中，在改進和個性化定制界面及用戶交互的同時，不需要重新編寫業務邏輯。MVC應用程序被分為3個核心部件：視圖、控制器、模型。它們各自處理自己的任務。MVC架構風格示意圖如下：
1. 視圖（View）
視圖是用戶看到並與之交互的界面。對老式的Web應用程序來說，視圖就是由HTML元素組成的界面，在新式的Web應用程序中，HTML依舊在視圖中扮演着重要的角色，但一些新的技術以層出不窮，包括：JSP、Freemarker模版引擎等。
2. 控制器（controller）
控制器接收用戶的輸入並調用模型和視圖去完成用戶的需求，所以當單機Web頁面中的超鏈接和發送HTML表單時，控制器本身不輸出任何東西和做任何處理。它只是接收請求並決定調用哪個模型構件去處理請求，然后再確定用哪個視圖來顯示返回的數據。
3. 模型(Model)
模型負責業務邏輯的處理及數據庫的訪問。在MVC的3個部件中，模型擁有最多的處理任務。被模型返回的數據是中立的，即模型與數據格式無關，這樣一個模型能為多個視圖提供數據，由於應用於模型的代碼只需編寫一次就可以被多個視圖重用，所以減少了代碼的重復性。
在如上圖所示的Web應用體系結構中，用戶在瀏覽器上訪問登錄頁面，首先請求傳遞給了控制器，控制器進行HTTP請求處理，調用相應的登錄頁面（視圖）顯示給用戶，用戶在登錄頁面輸入用戶名和密碼信息后點擊“登錄”按鈕，該事件請求被提交給了控制器，控制器調用模型來完成業務邏輯的處理和數據庫的訪問，模型完成業務處理后將結果數據返回控制器，控制器調用視圖動態生成一個登錄成功頁面顯示結果給用戶。
在本項目中，為了實現MVC架構，采用JSP作為表現層（View），Servlet作為控制器（Controller），Service+DAO+JavaBean作為模型（Model）。
2.2、系統邏輯結構與類包圖
包圖（package Diagram）由若干個包及包之間的關系組成。包是一種分組機制，將同類的類、對象、模型元素放在一起，形成高內聚、低耦合的類集合，可以說，一個包相當於一個子系統。在MVC框架模式下，可以將屬於“同一層次”的類放在相同的包中，既從邏輯上體現了系統的體系結構，又方便后期組織編碼開發。例如，當某個頁面挑戰控制發生改變或錯誤時，我們只需要在存放Controller的包中很快找到某個控制類就可以解決問題。
鑒於OA系統是基於Web的網絡應用系統，因此在軟件體系架構設計分析時采用典型的MVC模式應用JSP+Servelet+Service+DAO+JavaBean的結構。
OA系統的邏輯體系結構如下圖所示：
- jsp包中存放所有和用戶交互的頁面，如jsp頁面、Html頁面等。
- controller包中存放控制類，接收用戶的請求，調用service進行業務邏輯處理，負責頁面跳轉與返回數據等。
- service包中存放用於實現各種業務邏輯的處理類。
- dao包中存放數據訪問的類，用於實現java對象與數據庫表的數據交互。
- entity包中存放實體類，負責數據的存儲與傳輸。
- dbc包中存放負責加載數據庫驅動，創建數據庫連接，獲得數據庫連接，關閉數據庫連接的類。
在各個包中添加我們的實現類和有關接口類，得到項目的實現視圖，也就是源代碼的目錄文件結構如下：
2.3、系統物理體系結構與構件圖
當系統進入到物理設計階段，我們最好可以利用構件圖（Component Diagram）整理物理項目和邏輯類之間的關系，在一些大型項目中所設計出的類和接口超過數百個，而編碼團隊的成員只有數十位，這時如果不用構件圖來組裝這些不同的構件，則在編碼時我們常常會不知不覺地陷入“對象迷茫”中。
構件是具有相對獨立功能、可以明顯辨識、接口由契約制定、語境有明顯依賴關系、可以獨立部署且多由第三方提供的可組裝軟件實體。按照UML2.0的定義，構件是系統的模塊化部分，它封裝了自己的內容，且它的聲明在其環境中是可以替換的。構件利用提供接口和請求接口定義自身的行為，使用構件圖可以清晰地看出系統的結構和功能，方便項目組的成員制定工作目標和了解工作情況，同時，最重要的一點是有利於軟件的復用。
構件划分的方式有很多，有的系統用三層架構的方式來划分構件，將每一層划分為一個構件，由於三層架構之間的弱耦合關系，這種划分方法有助於分組開發，協同合作，但是划分的粒度還不夠細致，尤其不便於邊開發邊測試，對於大型項目來說這種划分並不合適。
最好的划分方法來自領域，能最准確反映領域概念的是實體類模型，實體類及其屬性表現了系統所需存儲和傳輸的數據，實體類的方法反映了系統需要實現的功能，是系統領域完整的抽象表示。依據實體類模型來找出系統的構件，同時結合開發過程的需要，如數據庫構件和頁面構件應該作為獨立的構件單獨開發，將前端和后台分離，根據此方法來設計OA系統的構件圖，如下圖所示：
（1）Page構件包含前端的所有頁面(jsp)，它的各種請求處理依賴於后端的各個構件。
（2）User構件提供了與用戶相關的所有功能，包括用戶登錄(login)、用戶注銷(logout)、訪問系統首頁(index)等功能。
（3）Leave構件提供了員工請假的相關功能，包括創建請假申請(create)、獲取請假列表(list)等功能。
（4）Audit構件提供了請假審批的相關功能，如請假審批(audit)。
（5）Notice構件提供了系統通知的相關功能，如獲取當前用戶通知列表(list)。
（6）DatabaseConnection構件提供了數據庫訪問的功能，如獲取數據庫連接(getConnection)；后端的各個構件都需要依賴該構件才能實現其對應的功能。
依據MVC框架模式，后端構件中每個功能的實現都需要三層的類來完成，因此每個構件都由控制類、業務處理類(Service)、數據訪問類(Dao)、實體類(JavaBean/Entity)組成。本項目的構件圖中除了構件的基本划分，還體現了構件間的依賴關系，並簡要地描述了構件之間接口的設計，根據系統的依賴關系，系統首先需要開發的是數據庫構件，然后再開發其余后端構件（User、Audit、Leave、Notice）；頁面構件可以在開發這6個構件的同時進行，方便邊開發邊調試。
2.4、系統物理體系結構與部署圖
OA系統是一個Web應用系統，其Web應用部署結構包括4層節點：帶瀏覽器的客戶端、Web服務器、應用服務器和數據庫服務器，如下圖：
客戶端可以用來供用戶通過瀏覽器基於HTTP協議訪問Web服務器上的靜態或動態頁面；Web服務器處理來自瀏覽器頁面的請求，並且為客戶端執行和顯示動態產生的頁碼和代碼；應用程序服務器負責管理業務邏輯。業務構件封裝了存儲在數據庫中的永久對象，它們與數據庫服務器通過JDBC進行通信。
3、系統構件級設計
3.1、User構件
為了對系統中的各個構件進行詳細設計，我們選擇從用例場景出發，詳細地描述構件的功能以及構件內部各個類的協作和通信情況；這是因為用例反映了系統的需求，界定了系統的邊界，涵蓋了所有系統的運用場景，因此通過對用例場景進行分析設計、對用例中對象間的通信機制進行描述，可以准確地識別出實現該用例的全部設計類，以及其所需的屬性和方法及接口的定義。
下面以User用戶構件為例對構件進行詳細設計。在之前的用例分析環節，已經確定了與系統用戶相關的用例主要有用戶登錄（login）和用戶注銷（logout）；而在本系統中，由於在系統登錄時對用戶的登錄信息采用前端校驗的方式（即前端頁面首先提交用戶登錄信息表單到后端進行查詢，隨后后端向前端返回查詢結果，若用戶信息有效則進入主頁，否則繼續停留在登錄頁面），因此還需要增加一個訪問主頁(index)的用例；與此同時，從問題域中抽象出來與用戶相關的實體類有User系統用戶、Employee員工、Department部門、Node功能節點，下面我們將依次對每個用例流程展開分析：
1. 用戶登錄設計時序圖
當員工在登錄頁面（login.html）輸入用戶名和密碼並點擊“登錄”按鈕時該用例啟動。登錄頁面將表單信息提交給控制類UserController，UserController首先從請求中獲取用戶名和密碼等參數，並調用userService的checkLogin(username, password)方法，該方法繼續向下請求userDao的selectByUsername(username)方法進行數據庫的查詢操作，並將查詢結果封裝成user對象依次返回，UserController得到返回的user對象后首先判斷該用戶是否登錄成功，若成功則將該用戶對象存入session對象中，以便后續的請求能夠訪問該信息；最后將驗證結果放入result對象返回給前端頁面，隨后前端登錄頁面就可以根據返回的結果決定是繼續請求系統首頁還是向用戶提示錯誤信息。
2. 訪問主頁設計時序圖
當員工輸入用戶名密碼驗證成功后該用例啟動，該用例的執行者是前端的登錄頁面，此時前端將請求后端的index服務接口，以登錄系統的首頁。該請求會發送到UserController，在UserController的index()方法中，首先通過session獲取當前的登錄對象，然后通過employeeService和departmentService對象分別查詢當前員工信息和部門信息，隨后調用userService的selectByUserId(userId)方法獲取當前用戶對應的功能節點，以便在系統首頁展示不同的可用功能，最后在request和session中保存這些信息，然后將頁面轉發至index.jsp以返回給用戶。
3. 用戶注銷設計時序圖
當用戶在系統首頁點擊“注銷”按鈕時該用例啟動，隨后前端將該請求發送至后端的UserController控制類，UserController隨后執行logout()方法，在該方法中，首先獲取當前用戶的session對象，然后通過注銷session對象來完成用戶信息的“銷毀”；最后將頁面重定向到login.html頁面並返回給用戶。
在完成了全部與用戶相關的用例場景時序圖設計后，我們就對每個用例內部對象交互機制有了清晰的把握，同時也篩選出了全部的邊界對象、控制對象、業務對象和實體對象等，如此一來便可以得到User構件的詳細設計方案，如下圖：
3.2、Leave構件
按照和User構件相同的分析思路，我們也可以先分析出Leave構件的用例時序圖設計，然后得到Leave構件的詳細設計；為了簡便起見，我們在這里直接給出Leave構件的詳細設計類圖如下：
3.3、Audit構件
3.4、Notice構件
4、數據庫表設計
- sys_role
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| role_id | bigint | 20 | 是 | 主鍵 | 角色ID |
| role_description | varchar | 32 | 是 | 角色描述 |
- sys_node
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| node_id | bigint | 20 | 是 | 主鍵 | 節點編號 |
| node_type | int | 255 | 是 | 節點類型 | |
| node_name | varchar | 32 | 是 | 節點名稱 | |
| url | varchar | 255 | 否 | 功能地址 | |
| node_code | int | 255 | 是 | 節點編碼，用於排序 | |
| parent_id | bigint | 20 | 否 | 外鍵 | 上級節點編號 |
- sys_role_node
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| rn_id | bigint | 20 | 是 | 主鍵 | 主鍵編號 |
| role_id | bigint | 20 | 是 | 角色ID | |
| node_id | bigint | 20 | 是 | 節點編號 |
- department
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| department_id | bigint | 20 | 是 | 主鍵 | 部門ID |
| department_name | varchar | 32 | 是 | 部門名稱 |
- emplpyee
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| employee_id | bigint | 20 | 是 | 主鍵 | 員工ID |
| name | varchar | 32 | 是 | 員工姓名 | |
| department_id | bigint | 20 | 是 | 外鍵 | 部門ID |
| title | varchar | 32 | 是 | 職位 | |
| level | int | 255 | 是 | 職級 |
- sys_user
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| user_id | bigint | 20 | 是 | 主鍵 | 用戶Id |
| username | varchar | 32 | 是 | 用戶名 | |
| password | varchar | 64 | 是 | 用戶密碼 | |
| employee_id | biginit | 20 | 是 | 外鍵 | 所屬員工Id |
- sys_role_user
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| ru_id | bigint | 20 | 是 | 主鍵 | 主鍵編號 |
| role_id | bigint | 20 | 是 | 外鍵 | 角色Id |
| user_id | int | 20 | 是 | 外鍵 | 用戶Id |
- leave_form
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| form_id | bigint | 20 | 是 | 主鍵 | 請假單編號 |
| employee_id | bigint | 20 | 是 | 外鍵 | 員工編號 |
| form_type | int | 255 | 是 | 請假類型 1-事假 2-病假 3-工傷假 4-婚假 5-產假 6-喪假 | |
| start_time | datetime | 0 | 是 | 請假起始時間 | |
| end_time | datetime | 0 | 是 | 請假結束時間 | |
| reason | varchar | 128 | 是 | 請假事由 | |
| create_time | datetime | 0 | 是 | 創建時間 | |
| state | varchar | 32 | 是 | processing-正在審批 approved-審批已通過 refused-審批被駁回 |
- process_flow
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| process_id | bigint | 20 | 是 | 主鍵 | 處理任務編號 |
| form_id | bigint | 20 | 是 | 外鍵 | 表單編號 |
| operator_id | bigint | 20 | 是 | 外鍵 | 經辦人編號 |
| action | varchar | 32 | 是 | apply-申請 audit-審批 | |
| result | varchar | 32 | 否 | approved-同意 refused-駁回 | |
| reason | varchar | 255 | 否 | 審批意見 | |
| create_time | datetime | 0 | 是 | 創建時間 | |
| audit_time | datetime | 0 | 否 | 審批時間 | |
| order_no | int | 11 | 是 | 任務序號 | |
| state | varchar | 32 | 是 | ready-准備 process-正在處理 completed-處理完成 cancel-取消 | |
| is_last | int | 255 | 是 | 是否最后節點 0-否 1-是 |
- sys_notice
| 字段 | 數據類型 | 長度 | 非空 | 鍵 | 注釋 |
| notice_id | bigint | 20 | 是 | 主鍵 | 消息通知Id |
| receiver_id | bigint | 20 | 是 | 外鍵 | 接收人Id |
| content | varchar | 255 | 是 | 通知內容 | |
| create_time | datetime | 0 | 是 | 創建時間 |
5、項目概念原型的核心工作機制
本項目的概念原型的核心工作機制可以總結如下：
- 員工通過在登錄頁面輸入用戶名和密碼登錄系統；
- 登錄系統后，用戶可以點擊首頁的注銷按鈕登出系統；
- 員工通過點擊請假申請，並填寫請假申請表單向系統提交請假申請；
- 請假申請提交后，系統會自動生成請假審批任務，並以系統通知的方式發送給員工所在部門經理和總經理（視情況）；
- 如果申請請假的用戶是普通員工，且請假時間小於72小時，則請假審批任務只會發送給部門經理；
- 如果請假時間大於72小時，則請假審批任務會首先發送給部門經理進行審批，通過后再發送給總經理進行審批；
- 如果請假的用戶是部門經理，則審批任務會發送給總經理審批；
- 如果總經理發起請假申請，則系統自動審批通過；
- 在請假審批流程中，任一節點拒絕則導致審批任務結束；
- 用戶可以通過系統通知查看與自己相關的請假申請和處理信息。