計算機畢業設計 jsp社區管理系統(ssh) 畢設25

演示視頻：

https://www.bilibili.com/video/BV1TC4y1c7T5/

第4章總體設計

3.1系統設計方法三原則

人類在復雜的工程技術系統如能源、交通等建設方面，積累了豐富的經驗，為研究復雜系統如管理信息系統
提供了科學的指導性方法論，其主要原則如下：

（1）整體性原則。系統是相互聯系，相互作用的諸要素組成的綜合體。我們必須從整體和各組成部分的相互關系來考察事物，從整體目標和功能出發，正確處理系統各組成部分之間的相互關系和相互作用。

（2）分解—協調原則。就是把復雜問題化成若干相對簡單的子問題以方便求解。若子系統的問題比較復雜，還可以再分。但在處理各類子問題時，必須根據系統的整體功能和目標，協調各子系統的行為、功能與目標，以保證整體功能目標的實現。

（3）目標優化原則。所謂目標優化原則對簡單系統來說，是求Zui優解，對復雜系統來說，求的是滿意解。一定要注意，目標優化原則并不簡單是求Zui優解的問題

這里Zui需要指出的是：以上三原則是系統方法中處理復雜系統問題的三個主要原則，并非全部原則。在處理實際問題時，還需在這些原則的指導下，根據問題的特點，確定求解的具體方法和策略。

3.3 系統流程圖設計

要進行系統首先要有一個管理員登陸驗證，管理員輸入正確的用戶名和密碼后進入后臺管理界面。在這里設置了一個超級管理員，這個管理員需要在數據庫中直接添加，是不可以在管理員管理界面被刪除的。管理員登陸后根據權限對公司人力資源基本信息進行管理。

根據上述說明，建立了系統流程圖，如3.3所示。

圖3.3 系統后臺流程圖

3.4 數據庫設計

3.3.1 數據庫需求分析

需求具體體現在各種信息的提供、保存、更新和查詢方面，這就要求數據庫結構能充分滿足各種信息的輸入和輸出。收集基本數據、數據結構及數據處理的流程，組成一份詳盡的數據字典，為后面的具體設計打下基礎。

通過系統功能分析，針對一般的在線信息交流系統，總結出如下的需求信息：

（1）人員管理：

物業員工管理：物業員工信息的添加刪除修改。

陌生人拜訪管理：對進入小區的陌生人進行記錄管理。

人員出入管理：出入小區的人員進行登記管理。

（2）車輛管理：

對出入小區的各種車輛進行管理。

（3）帶出物品管理：

對從小區帶出物品的管理。

（4）系統維護：對管理員進行統一管理。

3.3.2 數據庫概念結構設計

在概念設計階段中，從用戶的角度看待數據及處理要求和約束，產生一個反映用戶觀點的概念模式。然后再把概念模式轉換成邏輯模式。將概念設計從設計過程中獨立開來，使各階段的任務相對單一化，設計復雜程度大大降低，不受特定DBMS的限制。利用ER方法進行數據庫的概念設計，可分成三步進行：首先設計局部ER模式，然后把各局部ER模式綜合成一個全局模式，Zui后對全局ER模式進行優化，得到Zui終的模式，即概念模式。

得到上面數據項和數據結構以后，就可以設計出能夠滿足用戶需求的各種實體，以及它們之間的關系，為后面的邏輯結構設計打下基礎。這些實體包含各種具體信息，通過相互之間的作用形成數據的流動。

設計規劃出的實體有：管理員、員工實體、車輛實體、帶出物品實體。

ER模型的“聯系”用于刻畫實體之間的關聯。一種完整的方式是對局部結構中任意兩個實體類型，依據需求分析的結果，考察局部結構中任意兩個實體類型之間是否存在聯系。若有聯系，進一步確定是1:1、1:N、M:N的關系。還要考察一個實體類型內部是否存在聯系，兩個實體類型之間是否存在聯系，多個實體類型之間是否存在聯系，等等針對本系統分析如下：

一個管理員一次可以多個工資信息，而一個工資信息只可以被一個管理員編輯

N

1

工資信息

管理員

管理員信息實體E-R圖如圖所示：

員工信息實體ER圖如圖所示：

3.3.2 數據庫邏輯結構設計

數據庫的概念結構設計完畢后，現在可以將上面的數據庫概念結構轉化為某種數據庫系統所支持的實際數據庫模型，也就是數據庫的邏輯結構。

居民住宅社區管理系統數據庫中各個表的設計結果如表所示。每個表格表示在數據庫中的一個表。

表1為管理員表，存儲系統中的管理員信息。

表1 管理員表（admin）

表2為員工信息表，記錄系統中員工信息。

表2 員工信息表（person）

表3為陌生人訪問信息，記錄小區陌生人訪問的信息。

表3 陌生人訪問信息表（visit）

表4為出入人員信息表，記錄小區出入人員信息的信息。

表3 出入人員信息表（accesscontrol）

表5為出入車輛表，記錄小區出入車輛的信息。

表5 出入車輛信息表（vehicle）

表6為帶出物品表，記錄從小區帶出物品的信息。

表6 帶出物品信息表（goods）

第5章系統模塊實現

系統界面的大部分功能都是以管理模塊為前提的，因為客戶模塊所顯示的數據大部分需要通過管理模塊來添加。因此，我們首先要來介紹管理模塊的設計與開發。管理模塊相對客戶模塊要復雜一些，因為在這里需要對所有信息進行維護，包括瀏覽、增加、修改和刪除等操作。為了便于系統維護，頁面的命名才用“模塊名+功能名”的方式。

3.1 SSH2配置

系統使用的是SSH2框架。Struts2框架實現了MVC模式，層次結構清晰，程序員只需要注重業務邏輯的實現就可以了，這樣一來大大的提高了開發的效率； Struts2只要有配置文件，就可以把握住整個系統各個部分之間的關系； Spring框架在沒有程序員的情況下就可以自己實現singleton模式。Hibernate框架的可移植性非常好。在開發過程中簡潔的HQL語句，減少了JDBC與SQL操作數據庫的代碼量，使開發難度降低。[14]

3.2 MVC設計模式

3.2.1 MVC介紹

MVC的英文全稱是Model-View-Controller，就是把一個應用的輸入、輸出和處理流程按照模型、視圖、控制的方式進行分離，這樣一個應用就會被分成三個層次——模型層、控制層、視圖層。如圖3-2為MVC模式的基本分層圖。[15]

圖3-2 MVC 模式基本分層圖

1.視圖(View)

視圖代表人機交互界面，就是用戶可以清楚看到內容，同時可以參與交互的界面。主要功能實現數據的傳輸和輸出功能，然后在相關頁面顯示出來，這樣用戶便可以從視圖層獲取到有用信息。不同的視圖利用不同的方法來呈現需要反應給用戶的信息。每一個視圖組件都會有一個更新函數，當模型層發生變化的時候這個函數就會被激活。在這個函數被激活以后視圖層就會進行更新操作。通過狀態查詢函數，視圖層可以從模型獲取數據。

2.模型(Model)

模型層的另一個名字是業務邏輯層，它主要用來封裝業務邏輯和業務產生的數據。業務邏輯是軟件的核心。用戶是無法看到業務邏輯層的，業務邏輯層獨立于特定輸出表示或者輸入模式。用戶只能利用控制器來控制業務邏輯層。

3.控制(Controller)

控制層可以理解起到控制整個業務流程的作用，實現View層跟Model層的協同工作。每個視圖有一個與之對應的控制器組件。一旦控制器組件接受到某個事件，就會將這個事件翻譯成為對模型或者視圖的請求。如果控制器的行為取決于模型的狀態，那么控制器需要進行變更的時候也需要向模型發出變更請求通知。例如：用戶點擊確定按鈕，確定按鈕的事件響應函數將會做出相應的反應來處理用戶要求。

本論文在實現系統時，系統架構使用了MVC設計模式。所以它擁有以下幾點優勢。

第一，新月出租車公司管理系統擁有多個視圖對應一個模型的能力。這樣做可以減少本系統代碼量，在進行維護時也減少了工作壓力，同時也便于維護。其次，該模型還沒有數據顯示格式，因此，這些模型可以直接應用到接口。

第二，因為應用程序被分成三個圖層，所以有時候改變其中之一將能夠滿足應用程序的更改。

第三，系統控制層的概念也很有效，因為它把不同的模型和不同的視圖組合在一起完成不同的要求，因此，控制層可以說是包含用戶請求的權限的概念。

第四，本系統采用的設計模式有利于軟件的工程管理。由于每層都有著不同的功能，而每一層不同的應卻具有某些相同的特征。利用這樣的特點程序員可以工程化、工具化產生管理程序代碼。

   由于界面簡約，操作簡便，系統在設計時就充分考慮到這點，所以，在此不再累述其中的操作過程。系統界面設計人性化，功能齊全無遺漏、無冗余，是物業管理系統的Zui大亮點。