【基于JAVA的網上訂餐系統設計與實現12000字(論文)】_第1頁
【基于JAVA的網上訂餐系統設計與實現12000字(論文)】_第2頁
【基于JAVA的網上訂餐系統設計與實現12000字(論文)】_第3頁
【基于JAVA的網上訂餐系統設計與實現12000字(論文)】_第4頁
【基于JAVA的網上訂餐系統設計與實現12000字(論文)】_第5頁
已閱讀5頁,還剩35頁未讀 繼續免費閱讀

下載本文檔

版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領

文檔簡介

基于JAVA的網上訂餐系統設計與實現摘要 摘要 在當今世界,人們普遍渴望通過享用美食的方式放松自我,養精蓄銳,但是由于時間和交通的緊張,加上有可能會有排隊的現象,很多人十分的抵觸去店面吃飯,那么這時候,可以通過在網上訂餐,且有專人送餐上門的模式便隨之誕生。網上訂餐的模式減輕了現在年輕人時間以及精神上的壓力,成為了當代年輕人十分推崇的訂餐方式。研究本課題的目的在于為當代年輕人打造一種更加輕快的訂餐模式。 本次課題對訂餐系統進行設計和實現,主要研究登錄注冊、購物車以及訂單相關業務邏輯。本系統主要應用JAVA語言,頁面主要依靠JSP進行動態顯示,數據的存儲應用MySQL。在對訂餐系統各個模塊有一定的了解以及清楚各模塊之間的聯系之后,先設計數據庫,然后按照JavaEE三層架構,采用MVC理念,依次從持久層,到業務邏輯層最后到web層編寫代碼的順序開發。 系統會收集用戶注冊信息、訂單信息以及菜品信息,并將它們存儲和處理,從而實現了信息的高度集成。總結就是應用訂餐系統可以有效的提高了工作效率,帶來了更可靠,堅硬的管理方式,大大節省了人力物力。關鍵詞:網上訂餐;購物車;訂單;java;三層架構 前言(緒論)1.1課題背景 在生活節奏快速,壓力變大的如今,對于消費者而言,網上訂餐系統的吸引力是因為它方便省時。許多人都喜歡在結束一天緊張的工作之后,能夠擁有一頓美食來進行放松,美食對這些人來說,有著重要的意義和誘惑,但是由于當今社會交通壓力大,人口密度大,如果去線下餐館吃,不僅要面對擁堵的交通問題,又可能還會出現吃飯排隊的現象,這樣不僅得不到放松,反而會讓人更加疲憊。還有一種情況是,人們并不想走出家門,還想吃到美食,所以網上訂餐系統就成人們的首選。 從企業經營方面,如果使用傳統的電話訂餐,會因為反復的電話溝通,用戶反復的進行相關咨詢而浪費大量的時間和人力浪費,十分的不便。而采用網上訂餐系統,圖文并茂的商品信息展現在用戶面前,最新的信息可以得到及時更新,用戶的下單信息自動保存等一系列信息化和自動化的操作大大彌補了電話訂餐的缺點。所以不難想象,網上訂餐的方式將逐步取代傳統。1.2在線訂餐系統的發展概況 在線訂餐系統的興起最早是在美國,這是因為美國屬于發達國家,網絡普及率高,生活節奏快等一系列相關因素所決定的。據調查,大部分大型網絡訂餐公司的營銷策略是通過網絡推廣和Email推廣,其中最常用的是Email營銷,歐洲一些國家則是網絡營銷更為普及一些。 在我國,網上訂餐的發展還沒有那么的普及。造成這種局面的原因是我國網民的主體主要集中在80、90、00后群體,而對于60、70后的群體本身思想比較守舊,接受新事物比較困難,且對網絡的信任度不高,生活也不怎么忙碌,因此在對于這部分群體,網上訂餐模式很難推廣。 目前網上訂餐平臺有餓了么、百度外賣、美團外賣、口碑外賣等品牌,我認為將來網上訂餐模式將會隨著網絡的普及和應用得到更廣泛的推廣和應用,網上訂餐平臺也會出現更多的新面孔。1.3主要研究內容 本系統基于javaEE三層架構,采用MVC編程思想來編寫代碼,頁面采用jsp技術實現動態顯示,存儲數據使用MYSQL,總體采用B/S架構,也就是瀏覽器和服務器結構來進行實現的。系統主要針對商品信息、用戶信息、購物車信息以及對訂單信息進行邏輯上的實現,而實現的前提則需要對業務需求有一定的了解,因此實現該系統必須先了解每個模塊的作用、功能以及它們之間聯系。1.4研究意義 網上訂餐必將成為新時代的主流訂餐方式,為了推動網上訂餐的發展,為當代快節奏的生活方式提供更加方便省時的新模式,研究網上訂餐系統是必要的。 我國在餐飲方面長期處于線下到實體店及電話訂餐的方式來享受美食,相對這兩種方式,通過網上訂餐的方式有著明顯的優勢。首先最直觀的感受就是快捷和靈活,消費者可以根據需要設置送餐的時間,從而可以在自己希望的時間享用食物,即使想要立刻享用,也依然可以在很短的時間內拿到食物;第二,網上訂餐有更多的食物可供選擇,幾乎應有盡有,而傳統的餐廳種類較為單一,可供選擇的菜品也十分有限;第三,訂餐將不再局限于時間,即便是深夜也依然可以通過網上訂餐的方式吃到想吃的東西。在此僅列舉三點,總之網上訂餐的方式就是新時代的產物,未來主流的模式將是網上訂餐模式。1.5相關技術介紹1.5.1MVCMVC是一種軟件編程思想,它認為,一個軟件,不論其功能有多復雜,其內部的組件都可以大致分為三個模塊。 Model:模型,負責數據的封裝和數據庫的訪問。 View:視圖,負責生成頁面,以及和用戶的交互。 Controller:控制器,負責調用Model和View。 MVC編程思想是一種解耦的思想,將一整個代碼塊按照功能劃分成很多小塊的做法,可以提高代碼的可讀性,同時代碼的可維護性也變的很高。因此,MVC設計模式是一種非常優秀的設計模式。1.5.2JavaScript JavaScript的出現最初是用于網頁的前端驗證,驗證用戶輸入的內容是否符合規定的格式要求。后來,隨著前端技術的發展,JavaScript應用變得越來越廣泛,例如頁面的動態展示效果、業務邏輯處理甚至是服務端技術,都有JavaScript的身影。 JavaScript同java一樣,都是面向對象的語言,但是JavaScript是基于原型的,在java里沒有原型的概念。JavaScript由三部分構成,分別是ECMAScript、DOM和BOM。ECMAScript的誕生是由于不同的瀏覽器廠商對JavaScript有不同的實現,為了確保不同瀏覽器運行同一個標準,所以便產生了ECMAScript。BOM是瀏覽器對象模型,可以利用BOM操作瀏覽器。DOM是文檔對象模型,利用它可以操作頁面。1.5.3Java開發模式Model2 Model2是基于MVC架構的設計模式,它是MVC思想在JavaEE中的具體應用。其中JSP負責動態展示頁面數據,Srvlet可以調用JSP和JavaBean,并且可以控制跳轉頁面,JavaBean負責數據層操作。其結構圖集如下。圖1.1Model2結構圖 圖1.2Model2改進結構圖1.5.4JavaEE三層架構 JavaEE三層架構將整個應用分成了三層,分別是web層/試圖展示層、service業務邏輯層和持久層。分層的目的和MVC思想是一樣的,都是為了高內聚,低耦合。視圖展示層主要起數據傳遞的作用,業務邏輯層主要根據業務需求進行業務邏輯處理,而持久層主要執行SQL指令,操作數據庫。JavaEE三層架構的結構圖如下圖所示。 圖1.3JavaEE三層架構結構圖1.5.5B/S架構 B/S架構是指瀏覽器服務器結構,不同于C/S架構,也就是客戶端服務端架構,C/S架構對于不同的應用需要安裝不同的客戶端,會占用更多的內存,對硬件配置的要求也比較高,而B/S架構,僅需要一個瀏覽器就可以,成本很低,維護起來也更加方便。B/S系統架構圖如下圖所示。 圖1.4B/S系統架構圖 第2章需求分析2.1系統概述 網上訂餐系統是面向商家和廣大消費者的,廣大消費者可以通過打開瀏覽器,輸入網址的方式訪問到訂餐系統,用戶可以瀏覽菜品,選擇喜歡的菜品進行購買,不過購買需要登錄后才可以,沒有賬號可以先注冊后登錄。登錄過后,具體的購買流程是選擇喜歡的菜品,點擊加入購物車,然后進入購物車界面,就可以看到自己選擇的菜品的數量,金額以及所有菜品相加后的總金額,也可以刪除購物車中不滿意的菜品和調整的商品數量,再下一步點擊購物車界面中結算按鈕,即可生成訂單。只需等待食物送上門即可。2.2系統功能分析2.2.1普通用戶功能分析 普通用戶如果不注冊,則僅可以在網站首頁瀏覽菜品以及對菜品進行查詢操作,無法執行加入購物車操作,自然也就無法支付下單,如果想要購買商品,需要登錄,登錄之后,用戶就可以正常的進行下單操作了,也可以執行修改用戶信息、用戶注銷、查詢歷史訂單及訂單詳情、刪除訂單等操作。用戶的下單流程需要先將喜歡的菜品加入購物車,然后在購物車界面會顯示菜品的圖片、單價、數量、每件商品的總金額,也就是單價乘數量、商品類別數以及所有商品的匯總金額等,用戶可以把不喜歡的菜品進行刪除,也可以修改菜品數量,匯總金額也會實時的更新。用戶在確定好購物車中的菜品后,點擊結算,就可以進行支付了,支付成功后,訂單就會自動產生,用戶可以查看訂單信息及詳情信息。以下將通過用例圖的形式對用戶操作模塊進行詳細的功能分析。 1.用戶登錄模塊 用戶如果要訂餐就必須進行登錄操作,如果沒有賬號,則需要先注冊再登錄,注冊賬號除了用戶名和密碼,還需要填寫收貨地址、手機號等重要信息,因為用戶下單購買菜品的時候,需要填寫收貨地址以及聯系方式等,為避免每次下單都要反復填寫的麻煩,只需要注冊的時候填寫相關信息,那么下單的時候,從用戶信息中取出收貨地址以及聯系方式自動填寫上去,只需用戶確認即可。 2.用戶信息修改模塊 考慮到如果用戶信息發生改變,例如用戶搬遷地址發生變化、用戶更換手機卡等。又或者是密碼泄露等問題。使得賬號信息不準確有風險。本系統添加了用戶信息修改功能,用戶只需要登錄系統,就可以在系統主界面看到用戶信息修改的功能,用戶可以對用戶名、密碼、地址、手機號進行修改。信息修改用例圖如下圖所示。 圖2.1用戶信息修改用例圖 3.購物車模塊 用戶可以對喜歡的商品執行加入購物車操作,在購物車頁面可以刪除商品,修改商品數量,清空購物車,結算等操作。購物車用例圖如下圖所示。 圖2.2購物車用例圖 4.訂單操作模塊 用戶成功購買商品后,會生成訂單,進入訂單界面,可以查看訂單,刪除訂單以及查看訂單詳情等操作。用戶訂單用例圖如下圖所示。 圖2.3用戶訂單用例圖管理員功能分析 管理員是訂餐系統的管理者,擁有最高權限,管理員可以管理用戶信息、商品信息以及訂單信息,管理員和普通用戶使用同一個登錄界面,管理員賬號登陸后會跳轉到后臺管理界面,管理員可以查看所有的用戶信息,也可以修改和刪除用戶信息。管理員也可以對商品進行管理,可以添加新的菜品信息,也可以對已有的菜品信息進行修改操作,比如修改商品圖片、單價等,還可以刪除菜品信息等。管理員可以查看所有的訂單信息,可以對訂單進行確認發貨處理,也可以刪除訂單信息。以下將通過用例圖的形式對用戶操作模塊進行詳細的功能分析。 1.用戶信息管理模塊 管理員可以查看所有用戶的信息,并可以修改和刪除用戶信息。用例圖如下所示。 圖2.4管理用戶用例圖 2.菜單操作模塊 菜單管理界面展示的是訂餐系統的商品信息,在該界面可以對商品進行修改、刪除和添加操作。菜品操作用例圖如下。 圖2.5管理員菜單用例圖 3.訂單管理操作模塊 管理員可以對所有用戶的訂單進行管理,可以查看訂單,查看訂單詳情,刪除訂單以及執行發貨處理。訂單用例圖如下所示。 圖2.6管理員訂單用例圖2.3非系統功能需求分析 (1)是否具有可用性 該系統雖然功能單一,但核心功能都具備,完全具備可用性。 (2)可擴展性 該系統采用MVC設計理念以及JavaEE三層架構的方式進行編寫,每個功能都進行了模塊化的細分,如果要添加新功能也比較容易,具有較好的可擴展性。 (3)流暢性 該系統幾乎沒有冗余的代碼,在代碼重用和邏輯處理上,都注意到了性能的消耗問題,所以本系統運行較為流暢。 (4)可維護性 該系統的組成代碼,邏輯分明并帶有較多注釋,分層編寫的架構使得代碼可讀性提高,具有較高的可維護性。 (5)可行性 該系統在成本上有較小的投入,具有經濟可行性。在技術上,采用Mysql數據庫存儲商品信息,訂單信息以及用戶信息,頁面采用CSS,JS,Jsp等技術實現,后臺代碼分為控制層,業務層,數據庫交互層,總體采用MVC的編程思想編寫,具有技術可行性。該系統基本實現了自動化,并且易操作,易管理,具有管理可行性。第3章系統設計3.1整體設計 本系統采用MVC的設計理念,代碼編寫架構采用JavaEE三層架構,總體基于B/S架構,前臺展示界面使用JSP技術、少量的JavaScript做前臺驗證、EL表達式以及CSS等技術構成。 本系統在功能上的設計根據角色劃分。普通用戶操作主要包括了登錄注冊、個人信息修改、菜品瀏覽、購物車操作以及訂單操作等。管理員可以登錄、管理用戶信息、管理商品信息、管理訂單信息等。下面圖3.1展示的系統功能結構圖所示。 圖3.1系統功能結構圖3.2系統功能設計3.2.1用戶模塊設計 用戶操作主要包括了用戶登錄注冊、瀏覽菜品、加入購物車、訂單操作以及個人信息修改等操作。用戶操作模塊類圖如下圖所示。 圖3.2用戶操作模塊類圖 1.用戶登錄注冊設計 用戶首先要有賬號,也就是說需要先注冊賬號,系統會對注冊信息做一定的格式驗證,驗證通過則會將注冊信息保存到數據庫中,注冊完成。登錄過程首先要用戶輸入用戶名和密碼,點擊登錄后,會到數據庫中查找是否存在該賬號,如果存在則返回成功信息,并且自動跳轉到系統主界面。如果不存在或者不匹配則會返回錯誤信息,繼續留在登錄界面。接下來展示用戶登陸注冊時序圖,如下圖所示。 圖3.3用戶登錄注冊時序圖用戶信息修改功能設計 用戶登錄過后,可以對個人信息進行修改操作,具體為首先跳轉個人信息界面,跳轉過程中,會去數據庫查找個人信息,然后返回信息展示到個人信息界面,所有的信息均為可編輯狀態,用戶可以直接修改。修改完成后,用戶可以進行提交操作,提交過程是將信息進行更新操作,將修改的信息覆蓋原信息。提交完成后,個人信息界面將會顯示修改后的數據。用戶信息修改時序圖如下圖所示。 圖3.4用戶信息修改時序圖 3.購物車模塊功能設計 用戶登錄過后,可以將喜歡的菜品加入購物車,點擊加入購物車并不會跳轉到購物車界面,這樣就可以邊瀏覽菜品邊將喜歡的菜品加入購物車。當用戶選好之后,可以手動進入購物車界面,購物車界面將顯示用戶選擇的菜品信息,如果用戶感覺購物車中的菜品不合適,可以同過修改菜品數量的方式加減菜品數量,也可以直接刪除某個不想要的菜品。當用戶確定好購物車中的菜品后,可以點擊結算進入結算界面。購物車操作時序圖如下圖所示。 圖3.5購物車操作時序圖 4.訂單模塊操作功能設計 用戶支付過后,會自動生成訂單,用戶可以查看訂單信息,也可以查看訂單詳情信息和刪除訂單信息,刪除訂單信息會一同將對應的訂單詳情數據一并刪除。具體流程為點擊我的訂單,進入訂單界面,在訂單界面將會顯示用戶所有的訂單信息,在該界面顯示訂單相關信息,比如訂單創建時間、訂單金額、收貨人姓名、收貨人地址和收貨人手機號等信息。如果想查看該訂單具體包含了哪些菜品,則可以點擊查看進入訂單詳情界面。訂單詳情界面展示的是該訂單包含的具體的商品信息,比如該訂單中包含了哪些菜品信息,每樣菜品的數量有多少,每樣菜品的單價以及總價是多少,都清楚的進行了展示。接下來展示用戶訂單模塊操作時序圖,如圖3.5所示。 圖3.6訂單模塊操作時序圖管理員模塊設計 管理員模塊的功能主要涉及到用戶信息管理、商品管理以及訂單管理等。它和普通用戶模塊有很多相同的模塊,比如都有信息管理模塊和訂單模塊。但是之所以分角色設計相同的模塊是因為權限不同,管理的范圍也不同,比如普通用戶的信息管理模塊只能管理用戶自身的信息,其他用戶的信息沒有權限管理。而管理員則不同,他可以管理所有用戶的信息。訂單管理也是同樣的道理,普通用戶僅可以管理自己生成的訂單,而管理員可以管理所有用戶生成的訂單。下面開始簡單的介紹一下本系統對管理員角色設計的功能模塊。 1.用戶信息管理模塊。 管理員可以查看所有的用戶信息,也可以對任何一個用戶的信息進行修改,甚至以修改用戶的角色信息,使普通用戶成為管理員。除了用戶信息修改以外,管理員還可以刪除用戶信息。 2.商品管理模塊。 管理員可以對菜品信息進行添加、修改和刪除操作。 3.訂單管理模塊。 對于訂單管理,管理員可以查看所有用戶的訂單,擁有對所有訂單進行確認的權限,當然也可以刪除訂單。下面展示管理員模塊操作類圖。 圖3.7管理員模塊操作類圖 管理員操作模塊細分如下: 1.管理員登錄注冊模塊設計 管理員登錄用的界面和普通用戶登錄使用的界面是同一個,系統會根據數據庫用戶表中的角色信息區分登錄用戶的身份,從而跳轉到不同的界面。管理員登錄過后會跳轉到后臺管理界面。注冊默認只能注冊普通用戶無法注冊管理員,管理員可以通過修改用戶角色信息來使普通用戶成為管理員。因此管理員模塊不包含注冊模塊。管理員登能注冊普通用戶無法注冊管理員,管理員可以通過修改用戶角色信息來使普通用戶成為管理員。因此管理員模塊不包含注冊模塊。 管理員登錄的流程信息為: (1)管理員輸入賬號密碼,點擊登錄。 (2)賬號信息被后臺接收,組織成SQL執行查詢 (3)如果沒有查詢到或者賬號密碼有一個對應不上,則返回的條數為0,表示沒有查詢到信息,返回錯誤信息。 (4)如果查詢到該條信息,則代表有該賬號,則返回成功信息,并且跳轉到后臺管理界面。 (5)登錄流程結束。 管理員注銷流程為: (1)點擊注銷按鈕 (2)注銷成功,跳轉登錄界面如下圖所示,下面展示管理員登錄注銷時序圖。 圖3.8管理員登錄注銷操作時序圖 2.管理員管理用戶信息模塊設計 管理員用戶管理模塊功能的設計大致分為三部分,用戶信息修改、刪除等。管理員在后臺管理界面可以通過點擊用戶管理的方式進入用戶管理界面,在進入用戶管理界面的過程中,系統會到數據庫中查詢所有的用戶信息,查詢到信息會被保存到request作用域中,轉發到用戶管理界面進行顯示。管理員可以通過該界面查看所有的用戶信息。 用戶信息修改流程為: (1)如果管理員想要修改某個用戶的信息,可以直接進行修改,修改完成之后,點擊提交。 (2)用戶的最新信息就會被提交到數據庫執行更新操作。 (3)更新完成后,重新查詢所有用戶信息 (4)查詢到的信息通過request轉發到用戶管理界面進行顯示,從而實現了實時修改的功能。 用戶信息刪除流程為: (1)管理員也可以刪除用戶信息,只需要在某用戶信息所在行點擊刪除 (2)那么系統將會根據該用戶編號信息到數據庫進行刪除操作。 (3)刪除完成同樣重新查詢所有用戶信息 (4)查詢的信息通過request攜帶轉發到用戶管理界面顯示。從而實現用戶信息的刪除功能。如下圖所示,下面展示用戶管理模塊功能時序圖。 圖3.9用戶管理模塊設計時序圖 3.管理員商品管理模塊設計 管理員商品管理模塊功能分為菜品添加、菜品信息修改、菜品信息刪除等。管理員可以對訂餐系統的菜品進行管理,在后臺管理界面點擊商品管理可以進入商品管理界面,在商品管理界面,管理員可以查看所有的菜品信息。 菜品添加流程為: (1)點擊菜品添加可以進入菜品編輯界面,在該界面可以填寫菜品信息,完成菜品添加后,點擊提交。 (2)菜品信息會在數據庫中的商品表中執行添加操作。 (3)添加完成后,重新查詢所有菜品信息。 (4)回到商品管理界面,新添加的菜品信息就會顯示在里面了。 菜品修改流程為: (1)點擊菜品信息修改也會跳轉菜品編輯頁面,只不過在點擊修改的時候,系統會從數據庫中獲取該菜品信息,然后顯示到菜品編輯界面。這樣一來,管理員就可以看到原菜品信息并可以直接修改。 (2)修改完成后,點擊提交。 (3)相應的菜品信息將在數據庫中執行更新操作。 (4)重定向到菜品管理界面,展示最新的信息。菜品的刪除,可以在菜品管理界面直接刪除即可。如下圖所示,接下來展示商品管理模塊設計時序圖。 圖3.10商品管理模塊設計時序圖 4.管理員訂單管理模塊設計 管理員訂單模塊包括查看訂單、查看訂單詳情以及訂單刪除等。 查看訂單的流程為: (1)管理員可以對所有用戶的訂單進行管理和確認,在后臺管理界面可以通過點擊訂單管理的方式打開訂單界面. (2)在打開該界面的過程中,系統會去數據庫的訂單表中查詢所有的訂單信息。 (3)查詢到的訂單被信息request攜帶,將通過轉發的方式轉發到訂單管理界面進行顯示,管理員可以查看所有的訂單信息。 管理員查看訂單明細流程為: (1)點擊查看訂單明細。 (2)跳轉訂單詳情頁的過程中,系統會根據訂單號去訂單商品表中查詢對應的商品信息。 (3)查詢到的信息通過轉發,然后展示到訂單詳情頁。 管理員刪除訂單流程為: (1)管理員有權刪除訂單信息,在訂單管理界面,點擊刪除。 (2)系統會到數據庫中,根據訂單號分別刪除訂單表和訂單商品表中對應的數據。 (3)刪除成功后,重新查詢所有訂單信息。 (4)轉發到訂單管理界面,展示最新的訂單信息。管理員訂單模塊設計設計時序圖如下圖所示。 圖3.11管理員訂單管理模塊設計時序圖數據庫設計 本系統的設計是從數據庫開始設計的,只有數據庫設計好了,后面系統功能的設計才能繼續。一開始根據模塊考慮表的設計,模塊包括了用戶模塊、商品模塊、購物車模塊、購物車商品模塊、訂單模塊、訂單明細模塊等六個模塊,但考慮到購物車模塊和購物車商品模塊與訂單模塊和訂單明細模塊相對應,所以就把購物車表和購物車商品表去掉了,但是去掉之后,購物車模塊就無法編寫了,而且訂單模塊也需要購物車中的信息,所以購物車和購物車商品信息不作為數據庫表,而是作為session中的數據,在購物車模塊設計的時候,購物車作為Map集合,購物車商品數據存到Map集合中,然后將購物車相關數據存放到session中,后面生成訂單數據可以直接從session中取得必要的數據。所以本系統數據庫表只有四個,分別是用戶表、商品表、訂單表以及訂單明細表。每張表具體的設計在下面的部分一一介紹。3.3.1數據庫概念模型設計(E-R圖) 1.實體屬性圖 (1)用戶/管理員實體包括編號、用戶名、密碼、地址、手機號、角色等屬性。編號用來唯一標識一個人的身份,用戶和密碼用于登錄,地址和手機號用于確定用戶收貨地址和聯系方式,角色用于區分用戶和管理員。用戶/管理員實體屬性圖如下圖所示。 圖3.12用戶/管理員實體屬性圖 (2)菜品實體包括編號、名稱、價格、銷量、圖片等屬性。菜品編號起唯一標識作用,名稱、價格、銷量及圖片都是描述菜品實體的。菜品實體屬性圖如下圖所示。 圖3.13菜品實體屬性圖 (3)訂單實體包括編號、創建時間、價格、狀態、用戶編號、收貨人姓名、收貨人地址、收獲人手機號。編號唯一標識訂單,創建時間表示訂單生成的時間,價格指訂單總價,狀態表示該訂單是否發貨,用戶編號指定訂單是那個用戶的。訂單實體屬性圖如下圖所示。 圖3.14訂單實體屬性圖2.系統E-R圖 圖3.15實體E-R關系圖3.3.2邏輯模型設計 本系統的數據庫設計只有四張表,分別為用戶/管理員信息表、商品表、訂單表、訂單明細表。用戶/管理員信息表主要用來存儲用戶及管理員的信息,商品表主要用來存儲菜品信息,訂單表用來存儲訂單信息,訂單明細表存儲訂單中的商品信息。每張表詳細劃分如下: (1)用戶/管理員信息表(包含編號、用戶名、密碼、地址、手機號、角色)。 (2)商品表(商品編號,商品名稱,商品價格,銷量,商品圖片)。 (3)訂單表(訂單編號,訂單創建時間,訂單價格,訂單狀態,用戶編號,收貨人姓名,收獲人地址,收貨人手機號)。 (4)訂單明細表(訂單商品編號,訂單商品名稱,訂單商品數量,訂單商品單價,訂單商品總價,訂單編號,訂單商品圖片)。3.3.3物理模型設計 表3.1用戶/管理員表 表3.2商品表 表3.3訂單表 表3.4訂單明細表第4章系統實現4.1系統實現工具 當前訂餐系統的實現使用了Mysql5.7、eclipse(需支持JavaEE)、tomcat8.5、谷歌瀏覽器、DBeaver等工具。4.2系統功能實現4.2.1登錄注冊功能實現 1.用戶登錄模塊 (1)用戶登錄 登錄界面包含用戶名稱、用戶密碼、提示信息以及可以跳轉注冊界面的立即注冊超鏈接。用戶可以在該界面輸入賬號密碼完成登錄。實現流程是系統會到數據庫存儲注冊信息的用戶表中,根據名稱和密碼查詢是否存在相應的數據,如果存在該條數據,則會跳轉到系統首頁,并將該用戶信息存進SESSION中。如果沒有查詢到數據,則返回登錄界面,提示信息將提示用戶名或密碼錯誤。用戶登錄界面如下圖所示。 圖4.1登錄界面 (2)用戶注銷 用戶登錄之后,用戶信息會被保存到SESSION中,保證后續功能需要獲取用戶信息時可以從SESSION中獲取。如果用戶想要注銷,那么直接將SESSION銷毀即可。 2.用戶注冊模塊 (1)用戶注冊 用戶如果初次訪問該系統,則必須注冊一個賬號,才能正常使用該系統的功能。注冊界面包括用戶名稱、用戶密碼、聯系方式、用戶地址和驗證碼。用戶輸入相應的信息后,點擊注冊,首先會走由JavaScript寫的前端驗證邏輯代碼部分,如果注冊信息通過了前端驗證,則會被request攜帶進入后臺邏輯,后臺將從request中取出注冊信息進行接收,轉換成合適的數據類型,經過一些邏輯處理,最終注冊信息會通過JDBC保存進數據庫的用戶信息表中。用戶注冊界面如下圖所示。 圖4.2用戶注冊界面4.2.2系統主界面 用戶輸入網站網址后,會進入系統主界面,此時用戶是未登錄狀態,所以用戶只能瀏覽菜品而不能將菜品加入購物車,界面也不會顯示購物車和訂單功能模塊,只顯示登錄注冊。當用戶登錄過后,購物車和訂單功能才會顯示,加入購物車才會生效,不然未登錄就點擊加入購物車,則會跳轉到登錄界面。登錄和未登錄區別的實現,是根據SESSION中是否含有用戶信息,如果有就顯示購物車、訂單以及正常加入購物車功能,沒有則相反。系統登錄前后主界面如下兩圖所示。 圖4.3未登錄系統主界面 圖4.4登錄后主界面4.2.3購物車模塊功能實現 用戶點擊加入購物車,會執行添加到購物車的邏輯,購物車中每件商品的信息是由商品實體類進行封裝的,類中描述了商品具有的屬性。而購物車實際上是一個Map,存儲一個個的鍵值對,每個鍵值對表示一件商品,鍵值對的鍵表示商品編號,值為商品類。由于本系統設計數據庫時,并沒有設計相關表存儲購物車相關數據,所以購物車被放進session中,供訂單模塊使用。 圖4.5購物車展示界面4.2.4用戶訂單模塊功能實現 當用戶成功結算后,就會生成訂單,生成訂單的邏輯大概是從session中取出購物車信息和用戶信息,然后獲取里面必要的信息,封裝成一個訂單對象,訂單對象必須包含用戶編號信息。同時會獲取購物車中的所有商品信息,用于生成訂單商品項,訂單商品對象必須包含訂單編號。當查詢訂單時會根據用戶編號查,查詢訂單商品項時,根據訂單編號查詢。訂單界面和訂單詳情界面如下兩圖所示。 圖4.6訂單界面 圖4.7訂單詳情界面4.2.5用戶信息修改模塊 用戶登錄過后,可以在主界面看到個人信息的字樣,用戶可以點擊它,然后進入個人信息界面,在個人信息界面將展示該用戶的用戶名、密碼、地址、手機號以及角色信息,其中角色信息是只讀的,用戶無法更改自己的角色信息,其他信息,用戶是可以更改的。下面展示用戶個人信息界面,如下圖所示。 圖4.8用戶個人信息界面4.2.6菜單管理模塊 點擊菜單管理,會進入菜單管理界面,菜單管理界面展示的數據是通過查詢數據庫中的商品表,將所有商品查詢出來進行展示。在管理界面也可以對單個商品進行修改和刪除操作,刪除操作就是以商品編號作為條件進行刪除,刪除之后會再次查詢所有商品重新展示,修改操作需要對商品信息進行回顯,回顯邏輯是將當前商品編號作為參數從數據庫中獲取商品信息,再將商品信息放進request作用域,轉到編輯頁面展示。添加商品的邏輯和更新差不多,只不過不需要編輯頁面傳遞參數。由于修改和添加操作的頁面中包含圖片信息,所以執行更新和添加時獲取參數不能通過getParameter()的形式獲取參數,因為參數是以流的形式傳過來的,所以需要以流的形式接收。下面展示菜單管理界面以及菜單編輯界面,如下兩圖所示。 圖4.9菜單管理界面 圖4.10菜單編輯界面4.2.7管理用戶管理功能實現 管理員在后臺管理界面,可以通過點擊用戶管理的方式進入用戶管理界面,在該界面將展示所用用戶的信息以及修改和刪除操作按鈕,管理員可以直接在界面修改和刪除用戶信息。管理員可以直接修改用戶角色信息,從而將普通用戶變為管理員。下面展示用戶管理界面,如下圖所示。 圖4.11用戶

溫馨提示

  • 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
  • 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
  • 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
  • 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
  • 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
  • 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
  • 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。

評論

0/150

提交評論