【導(dǎo)讀】企業(yè)相關(guān)資源和日常事務(wù)、使得企業(yè)管理的質(zhì)量和效率得到了質(zhì)的飛躍。本就用不上、另一方面昂貴的費(fèi)用也讓他們望而卻步。職員的工作日志管理、員工的任務(wù)分配和簡單的人事管理。使用該系統(tǒng)、企業(yè)管理者或。人事信息進(jìn)行基本的查詢和管理。權(quán)限分配包括了角色權(quán)限、用戶權(quán)限、頁面權(quán)限。

　　

【正文】 會隱藏評價的相關(guān)頁面。用戶可以看到自己的日志 /總結(jié)的評價 、 如果在后臺設(shè)置了公開評論 、 則也可以查看別人的日志 /總結(jié)的評論。 10. 附加模塊（第一個版本不實(shí)現(xiàn)） 附加模塊是一些實(shí)用的小工具：提醒和發(fā)郵件。 提醒：用戶在設(shè)置了提醒的時間和內(nèi)容之后 、 到了設(shè)置的時間。只 要登陸此系統(tǒng) 、就會有聲音和提示框提示。 發(fā)郵件：系統(tǒng)只是利用其他郵箱的 POP3 接口來發(fā)送郵件。 畢業(yè)設(shè)計 (論文 ) 第 22 頁 軟件學(xué)院 系統(tǒng)框架搭建 經(jīng)過需求分析以及模塊劃分 、 再結(jié)合本系統(tǒng)實(shí)際做了詳細(xì)的分析考慮之后 、 本系統(tǒng)采用目前流行的 MVC 模式來設(shè)計。系統(tǒng)組織總體框架圖如圖 ： 圖 系統(tǒng)組織總體框架 MVC 英文即 ModelViewController、 即把一個應(yīng)用的輸入、處理、輸出流程按照Model、 View、 Controller 的方式進(jìn)行分離 、 這樣一個應(yīng)用被分成三個層 ——模型層、視圖層、控制層。 視圖 (View)代表用戶交互界面 、 對于 Web 應(yīng)用來說 、 可以概括為 HTML 界面 、 但有可能為 XHTML、 XML 和 Applet。 MVC 設(shè)計模式對于視圖的處理僅限于視圖上數(shù)據(jù)的采集和處理 、 以及用戶的請求 、 而不包括在視圖上的業(yè)務(wù)流程的處理。業(yè)務(wù)流程的處理交予模型 (Model)處理。 在本系統(tǒng)中 、 視圖也就是 WEB 層 、 它負(fù)責(zé)把后臺取得的相關(guān)數(shù)據(jù) 、 包括日志、通知、任務(wù)以及職員詳細(xì)信息等顯示在頁面 、 也負(fù)責(zé)把用戶的操作狀態(tài)顯示出來 、 讓用戶清楚的知道自己所做操作的結(jié)果。 模型 (Model)：就是業(yè)務(wù)流程 /狀態(tài)的處理以及業(yè)務(wù)規(guī)則的制定。業(yè)務(wù)流程 的處理過程對其它層來說是黑箱操作 、 模型接受視圖請求的數(shù)據(jù) 、 并返回最終的處理結(jié)果。業(yè)務(wù)模型的設(shè)計可以說是 MVC 最主要的核心。業(yè)務(wù)模型還有一個很重要的模型那就是數(shù)據(jù)模型。數(shù)據(jù)模型主要指實(shí)體對象的數(shù)據(jù) 保存（持續(xù)化）。 在此層 、 主要是處理一些業(yè)務(wù)邏輯 、 比如查找用戶、查找日志、查找總結(jié)等。它接受視圖層的數(shù)據(jù) 、 并進(jìn)行業(yè)務(wù)處理。 控制 (Controller)可以理解為從用戶接收請求 , 將模型與視圖匹配在一起 、 共同完成用戶的請求。劃分控制層的作用也很明顯 、 它清楚地告訴你 、 它就是一個分發(fā)器 、 選擇什么樣的模型 、 選擇什么樣的視圖 、 可以完成什么樣的用戶請求?？刂茖硬⒉蛔鋈魏蔚臄?shù)據(jù)處理。 在此系統(tǒng)中 、 控制層和視圖層并無明顯的分層 、 也就相當(dāng)于結(jié)合在一起了。 模型、視圖與控制器的分離 、 使得一個模型可以具有多個顯示視圖。如果用戶通過 畢業(yè)設(shè)計 (論文 ) 第 23 頁 軟件學(xué)院 某個視圖的控制器改變了模型的數(shù)據(jù) 、 所有其它依賴于這些數(shù)據(jù)的視圖都應(yīng)反映到這些變化。因此 、 無論何時發(fā)生了何種數(shù)據(jù)變化 、 控制器都會將變化通知所有的視圖 、 導(dǎo)致顯示的更新。這實(shí)際上是一種模型的變化 傳播機(jī)制。模型、視圖、控制器三者之間的關(guān)系和各自的主要功能 、 如圖 所示 ： 圖 MVC組件類型關(guān)系和功能 而且在系統(tǒng)中使用了 MVC 模型后 、 其優(yōu)點(diǎn)有： 首先 、 最重要的是應(yīng)該有多個視圖對應(yīng)一個模型的能力。在目前用戶需求的快速變化下 、 可能有多種方式訪問應(yīng)用的要求。例如 、 訂單模型可能有本系統(tǒng)的訂單 、 也有網(wǎng)上訂單 、 或者其他系統(tǒng)的訂單 、 但對于訂單的處理都是一樣 、 也就是說訂單的處理是一致的。按 MVC 設(shè)計模式 、 一個訂單模型以及多個視圖即可解決問題。這樣減少了代碼的復(fù)制 、 即減少了代碼的維護(hù)量 、 一旦模型發(fā)生改變 、 也易于維護(hù)。 其次 、 由于模型返回的數(shù)據(jù)不帶任何顯示格式 、 因而這些模型也可直接應(yīng)用于接口的使用。 再次 、 由于一個應(yīng)用被分離為三層 、 因此有時改變其中的一層就能滿足應(yīng)用的改變。一個應(yīng)用的業(yè)務(wù)流程或者業(yè)務(wù)規(guī)則的改變只需改動 MVC 的模型層?？刂茖拥母拍钜埠苡行?、 由于它把不同的模型和不同的視圖組合在一起完成不同的請求 、 因此 、 控制層可以說是包含了用戶請求權(quán)限的概念。 最后 、 它還有利于軟件工程化管理。由于不同的層各司其職 、 每一層不同的應(yīng)用具有某些相同的特征 、 有利于通過工程化、工具化 產(chǎn)生管理程序代碼。 所以 、 整個項目按照 MVC 模式的詳細(xì)組織框架圖如圖 ： 畢業(yè)設(shè)計 (論文 ) 第 24 頁 軟件學(xué)院 圖 系統(tǒng)的詳細(xì)組織框架 權(quán)限分配策略 本系統(tǒng)的權(quán)限采用了按角色和自定義權(quán)限相結(jié)合的方式來分配 、 這是借鑒了目前論壇權(quán)限分配的廣泛做法 、 這樣不僅提高了權(quán)限管理的靈活性 、 也提高了安全性。 權(quán)限分配 是除基本權(quán)限 [注１ ]之外的其他權(quán)限的分配 、 包括了 角色 權(quán)限、用戶權(quán)限、頁面 權(quán)限 。 而所有權(quán)限的內(nèi)容和默認(rèn)數(shù)據(jù)均以 角色 權(quán)限為準(zhǔn) 、 在默認(rèn)情況下 系統(tǒng) 的權(quán)限判斷都采用的是 角色 權(quán)限 、 如果設(shè)置了 用戶 權(quán)限則相應(yīng)用戶權(quán)限優(yōu)先于 角色 默認(rèn)權(quán)限 、如設(shè) 置了 頁 面權(quán)限則相應(yīng) 頁面 權(quán)限優(yōu)先于 角色 權(quán)限和用戶權(quán)限。 注１：基本權(quán)限：在本系統(tǒng)中是指寫日志、寫總結(jié)、發(fā)送消息、查看自身日志、查看自身總結(jié)、查看任務(wù)、查看通知、查看消息、查看權(quán)限、查看／修改自身資料和修改自身密碼這 11 項權(quán)限。 畢業(yè)設(shè)計 (論文 ) 第 25 頁 軟件學(xué)院 角色權(quán)限 角色權(quán)限是用戶注冊之后就會給每個用戶分配相應(yīng)的權(quán)限 、 總經(jīng)理、部門經(jīng)理和職員三者的默認(rèn)權(quán)限是完全不同的。相對于總經(jīng)理 、 部門經(jīng)理的審核申請、 查看他人日志、查看他人總結(jié)、查看職員信息、修改職員信息、修改職員密碼、分配任務(wù)、發(fā)送通知這些權(quán)限都只是對自己所在部門的職員 、 而總 經(jīng)理則是對所有的部門職員和部門經(jīng)理。具體的基于角色的權(quán)限分配 如表 ： 表 權(quán)限分配表 角色 權(quán)限 總經(jīng)理 部門經(jīng)理 職員 基本權(quán)限 √ √ √ 審核申請（１０） √ √ 查看他人日志（１１） √ √ 刪除他人日志（１２） √ √ 查看他人總結(jié)（１３） √ √ 分配權(quán)限（１４） √ √ 查看職員信息（１５） √ √ 修改職員信息（１６） √ √ 刪除職員信息（１７） √ 修改職員密碼（１８） √ √ 分派任務(wù)（１９） √ √ 發(fā)送通 知（２０） √ √ 備份數(shù)據(jù)庫（２２） √ 還原數(shù)據(jù)庫（２３） √ 系統(tǒng)設(shè)置（３０） √ 管理部門、職務(wù)和職稱（２１） √ 注：權(quán)限后面括號的數(shù)字是此權(quán)限在系統(tǒng)中的代號。 畢業(yè)設(shè)計 (論文 ) 第 26 頁 軟件學(xué)院 用戶權(quán)限 用戶權(quán)限是用戶在使用本系統(tǒng)時 、 被授予的權(quán)限。當(dāng)用戶注冊并可以使用本系統(tǒng)時 、獲得的是角色權(quán)限 、 而當(dāng)別的用戶授予另外一些高級權(quán)限之后 、 則擁有的新的權(quán)限是用戶權(quán)限 、 并且用戶權(quán)限是高于角色權(quán)限的。 頁面權(quán)限 頁面權(quán)限是某些頁面是需要權(quán)限來訪問 、 否則將不會顯示其內(nèi) 容。頁面權(quán)限高于用戶權(quán)限和角色權(quán)限。如表 ： 表 頁面權(quán)限表 頁面 功能 權(quán)限要求 Apply/ 用戶注冊 無 登陸頁面 無 主頁面 要求登陸 Log/ 寫日志頁面 要求登陸 Log/ 寫總結(jié)頁面 要求登陸 Message/ 發(fā)送消息頁面 要求登陸 Log/?Find=self 查看自身日志頁 要求登陸 Log/?Find=self 查看自身總結(jié)頁面 要求登陸 Task/ 查看任務(wù)頁面 要求登陸 Task/ 查看通知頁面 要求登陸 Message/ 查看消息頁面 要求登陸 Power/ 查看擁有權(quán)限頁面 要求登陸 Staffer/?Info=Info 查看自身信息頁面 要求登陸 Staffer/?Modi=Modi 修改自身信息頁面 要求登陸 Staffer/?Info=Self 修改自身密碼頁面 要求登陸 Task/ 發(fā)送通知頁面 ２０ Log/?Find=other 查看職員日志頁面 １１ Log/?Find=other 查看職員總結(jié)頁面 １３ Staffer/?Info=Other 修改職員密碼頁面 １８ Power/ 分配權(quán)限頁面 １４ Task/ 分配任務(wù)頁面 １９ Power/ 內(nèi)容／系統(tǒng)設(shè)置、數(shù)據(jù)庫備份和還原頁面 總經(jīng)理 Apply/ 審核申請頁面 １０ Staffer/ 查找職員頁面 １５ Apply/?userID=000 修改職員頁面 １６ 注：上表中權(quán)限要求的數(shù)字是對應(yīng)表 中的權(quán)限代號。 畢業(yè)設(shè)計 (論文 ) 第 27 頁 軟件學(xué)院 數(shù)據(jù)表設(shè)計 數(shù)據(jù)庫設(shè)計的好壞直接影響整個系統(tǒng) 、 如果數(shù)據(jù)庫設(shè)計不好 、 不僅僅很多的業(yè)務(wù)處理起來相當(dāng)?shù)膹?fù)雜和煩瑣 、 而且在編寫系統(tǒng)代 碼的時候也會遇到很多問題。所以 、 一個合理的數(shù)據(jù)庫是必須的、是必要的。所以在數(shù)據(jù)庫設(shè)計之前首先要注意的幾個問題如下： ：命名的明確性有利于數(shù)據(jù)庫的管理 、 在建立數(shù)據(jù)庫的時候應(yīng)該本著簡單 、 易于理解的原則 、 另外 、 不同的數(shù)據(jù)庫產(chǎn)品對對象的命名有不同的要求 、 因此 、數(shù)據(jù)庫中的各種對象的命名、后臺程序的代碼編寫應(yīng)采用大小寫敏感的形式 、 各種對象命名長度不要過長 、 這樣便于應(yīng)用系統(tǒng)適應(yīng)不同的數(shù)據(jù)庫。 (Index)：創(chuàng)建索引一般有以下兩個目的：維護(hù)被索引列的唯一性和提供快速訪問表中數(shù)據(jù)的策略。添加任何 一種索引均能提高查詢的速度 、 但是同時也是需要付出代價的 、 那就是會降低插入、更新、刪除操作的性能 、 尤其是當(dāng)填充因子（ Fill Factor）較大時。所以對索引較多的表進(jìn)行頻繁的插入、更新、刪除操作 、 建表和建索引時應(yīng)設(shè)置較小的填充因子 、 以便在各數(shù)據(jù)頁中留下較多的自由空間 、 減少頁分割及重新組織的工作。 （ Relation）：設(shè)計表間關(guān)聯(lián)是為了保證數(shù)據(jù)庫的一致性和完整性 、 降低數(shù)據(jù)的冗余 、 但同時卻增加了表間連接查詢的操作 、 為了提高系統(tǒng)的響應(yīng)時間 、 合理的數(shù)據(jù)冗余也是必要的 [16] 。 企業(yè)在線工作日志管 理系統(tǒng) 的所有數(shù)據(jù)用了數(shù)據(jù)庫 + XML 的方式來存儲。且數(shù)據(jù)庫采用的是 ACCESS 2021。 數(shù)據(jù)庫中各個表的結(jié)構(gòu)情況如下： 數(shù)據(jù)庫備份信息表（ DBBackup） 表 數(shù)據(jù)庫備份信息表 字段名 說明 類型 主鍵 可否空 外鍵 ID 編號（系統(tǒng)自動產(chǎn)生） BigInt(8) √ Path 備份數(shù)據(jù)庫路徑 Varchar(40) Date 備份時間 DateTime(8) Intro 備份說明 Varchar(40) √ 畢業(yè)設(shè)計 (論文 ) 第 28 頁 軟件學(xué)院 個人信息表（ Personnel） 表 個人信息表 字段名 說明 類型 主鍵 可否空 外鍵 ID 編號（系統(tǒng)自動產(chǎn)生） Int(4) √ Per_ID 員工編號 、 手動輸入。 Varchar(16) √ Pwd 密碼 Varchar(16) Name 員工姓名 Varchar(24) Sex 性別 Varchar(4) Address 地址 Varchar(100) Phone 固定電話 Varchar（ 10） MoPhone 移動電話 Varchar(12) √ Email 電子郵箱 Varchar(50) Birthday 出生年月 DateTime(8) Interest 興趣愛好 Varchar(1