【文章內容簡介】 小結 本章介紹了 書店 管理 系統(tǒng)的基本概念，研究現狀與發(fā)展動態(tài)，給出了 書店 管理 系統(tǒng)采用的技術與方法，闡述了本文的項目背景、課題來源、研究內容、目的和意義。 第一章 緒論 第二章 書店管理系統(tǒng)需求分析 第三章 書店管理系統(tǒng)的設計 第四章 書店管理系統(tǒng)的實現 第五章 結論與展望 10 第 2 章 需求分析 需求分析概述 需求分析 [5]是整個軟件開發(fā)過程的指南，是軟件開發(fā)人員開發(fā)出符合用戶要求的軟件的基礎。需求分析為用戶和軟件開發(fā)者雙方對該系統(tǒng)的初始框架有一個共同的理解，使之成為整個項目開發(fā)工 作的基礎。 書店管理 系統(tǒng) 需求 背景 書店管理系統(tǒng) 主要要滿足以下三個 方面需求：第一，書店工作人員通過計算機來管理各類圖書，進行圖書分類編號，調整圖書結構，增加圖書庫存，適應讀者的需求。第二，工作人員對讀者的需求情況能作好全面的掌握，及時得到歷史銷售記錄。第三，也是書店的核心工作，對圖書的銷售管理。 系統(tǒng)功能結構設計 該 用戶管理模塊中主要用戶有兩種：營業(yè)員和供應商，在該模塊中只有系統(tǒng)管理員才能操作該模塊，其他操作人員沒有權限操作，主要完成對營業(yè)員和供應商基本信息的增、刪、改、查。 該模塊主要有兩個子模塊：圖書類別管理和圖書管理，圖書類別管理主要是要對書店購買的圖書進行分類，這樣便于日后的管理工作，圖書管理主要完成圖書基本信息的增、刪、改、查。 該模塊中主要有三個子模塊：圖書采購管理，退書管理，價格調整，該模塊主要有采購人員進行管理，其他操作人員無權管理， 圖書采購管理主要實現對圖書的采購，如果 采購人員發(fā)現有些書不想訂購了 ，也可以利用 退貨 管理來完成此功能，一定的時間內圖書的價格可能會發(fā)生波動，價格調整主要是完成此功能。 該模塊中 主要有三個 子 模塊： 銷售管理，退書管理，銷售查詢 ，銷售人員對各類圖書的銷售 和退書 情況進行記錄 ， 也可以查詢在某段時間內某種圖書的銷售情況 。 也可以查看所有圖書的銷售情況 。 11 該模塊主要有三個 子 模塊：庫存管理，庫存盤點，庫存報警，該模塊主要由庫存管理人員來操作， 庫存管理主要可以查看庫存的總量，某種圖書的現存數量。庫存盤點主要可以查看某種圖書在某段時間內的銷售情況和庫存情況。 當庫存某種圖書的數量小于 3 本時，就會將該書的信息顯示出來，告訴管理人員要購買此圖書了。 該模塊主要有四個 子模塊：數據庫備份，數據庫恢復，修改密碼，系統(tǒng)退出。數據庫備份和恢復主要是了防止數據庫中的數據受到破壞，可以隨時進行備份和恢復。 操作人員也可以對自己的密碼進行修改 。 當操作人員想要退出書店管理系統(tǒng)時可以單擊退出系統(tǒng)菜單。 系統(tǒng)功能結構圖 圖 系統(tǒng)功能結構模塊 書店管理系統(tǒng)的 用例圖設計 參照書店管理 系統(tǒng)的需求，系統(tǒng)的主要用例圖中包括有管理員 、采購員、前臺營業(yè)員 和 庫存管理員 。 管 理員功能要求： 書 店 管 理 系 統(tǒng) 用戶管理 圖書管理 采購管理 銷售管理 庫存管理 系統(tǒng)設置 12 本系統(tǒng)管理員 可以對所有的模塊進行操作 。 操作人員的 功能要求： 采購人員，銷售人員，庫存管理人員只能操作他們自己的模塊，其他模塊都沒有權限操作 [6]，其用例圖如下： 圖 管理員 用例分析 圖 采購人員 用例分析 13 圖 銷售人員 用例分析 圖 庫存管理 人員 用例分析 14 系統(tǒng)流程圖 圖 系統(tǒng)流程圖 小結 本章首先對需求分析的概念做了簡述，然后根據系統(tǒng)的需求背景和可行性分析，設計了 書店管理 系統(tǒng)的基本功能模塊，并給出系統(tǒng)的功能結構圖、用例圖 ，為本系統(tǒng)的設計指明方向。 登錄 圖書類別信息 添加 圖書基本信息 添加 訂購單信息 添 加 圖書庫存信息 入 庫 圖書的銷售 銷售 銷售查詢 查詢 注冊 注 冊 15 第 3 章 系統(tǒng)的設計 書店管理 系統(tǒng)架構設計 書店管理 系統(tǒng)架構設計遵循多層次的架構設計原則，從上到下依次為 表現層、 業(yè)務邏輯 層、模型層和數據 訪問 層，系統(tǒng)層次架構模型如圖 所示。 圖 的層次架構模型 在本系統(tǒng)中， 表現層用 Java 圖形用戶界面 (GUI)實 現 ,然后表現層調用業(yè)務邏輯層中的代碼，所有的判斷都放在業(yè)務邏輯層，而數據 層 (DAO)層主要封裝了連接數據庫和對數據庫操作的一些代碼，業(yè)務邏輯層只管調用數據訪問層中的數據，具體實現在業(yè)務邏輯層并不關心。 VO/PO 為在各層次間傳遞數據的 JavaBean。VO 也就是值對象或者說數據傳輸對象，主要用于表現層； PO 持久層對象，主要用于表達實體模型數據。 書店管理系統(tǒng) 架構模型圖如圖 所示。 圖 書店管理 系統(tǒng)架構模型圖 業(yè)務實體設計 一個系統(tǒng)的業(yè)務實體在內存中表現為實體域對象，在數據庫中表現為關系數據，實現業(yè)務實體包括設計域模型 [1]、創(chuàng)建域模型實體對象和設計關系數據模型。 而 如何在自定義框架中設計通用數據操作和規(guī)范業(yè)務實體 呢？ 無論你習慣將 自己 的程序分為多少層來設計，但是這些都是細分經典的 MVC 模式 [7]。而這個GUI BUSINESS DAO 表現層 業(yè)務邏輯層 模型層 數據訪問層 依賴關系逐漸減弱 依賴關系逐漸減弱 數據庫層 16 數據操作與業(yè)務實體其實就相當于 MVC 中的 Model。 對于業(yè)務實體的設計，有的人喜歡用 XML 進行描述，有的人喜歡用類。前者的靈活性很好，對于多變的業(yè)務邏輯來說，前者是個不錯的方案。 但該系統(tǒng)選擇后者， 這樣一來效率可以有一定的提高，設計上也更加簡便一些。 下面通過一張圖（圖 ）來概括的描述一下數據操作與業(yè)務實體的關系 ： 圖 數據操作與業(yè)務實體的關系圖 由上圖可以看出，不同的業(yè)務實體擁有相同的父類，通過該父類，可以讓所有的業(yè)務實體都具有最重要也是最基本的數據庫連接、數據操作、以及性能優(yōu)化等功能。各個業(yè)務實體直接又絲毫沒有聯系，這樣一來當一個業(yè)務發(fā)生改變時完全不會影響到其它業(yè)務的運行，即便有聯系有影響，那也是在業(yè)務邏輯中應該規(guī)定的內容 。 業(yè)務實體概述 業(yè)務實體（ Business Entity）代表業(yè)務角色執(zhí)行業(yè)務用例時所處理或使用的“事物”。一個業(yè)務實體經常代表某個對多個業(yè)務用例或用例實例有價值的事 物 [8]，因此，業(yè)務實體對象的生存期相當長。通常，業(yè)務實體代表產品的文檔或重要組成部分。有時候，業(yè)務實體也代表一些非實體的對象，如關于市場或客戶的重要信息。例如，飯店中的業(yè)務實體有菜單和飲料；而在機場，機票和登機牌是重要的業(yè)務實體，在 書店管理 系統(tǒng)中， 圖書 是本系統(tǒng)中重要的業(yè)務實體。我們 Database DB Connect Parameter ConmandTest 業(yè)務實體類 業(yè)務實體類 業(yè)務實體類 業(yè)務實體類 數據操作與業(yè)務實體 數據操作 17 只需將業(yè)務對象模型 [9]中其他類必須引用的那些現象 建模為業(yè)務實體。而其他“事物”可以建模為相關類的屬性，或只在這些類中進行文字描述。 書店管理 系統(tǒng)的 數據庫 設計 在本系統(tǒng)中共設計了 7 張數據表 [10]，員工表 (tb_employee),供應商表(tb_supplier), 圖書類型表 (tb_bookType),圖書信息表（ tb_book）， 采購訂單表 （ tb_order） ，銷售表 (tb_sell),庫存表 (tb_store),具體表結構如下： 表 31 員工表 (tb_employee) 字段名 類型 說明 empID Varchar(16) 編號，主鍵 empUsername Varchar(20) 用戶名 empPassword Varchar(20) 密 碼 Emptype Int 類 型 empRealName Varchar(20) 真實姓名 empAge Int 年 齡 empidentityCard Varchar(20) 身份證 empSex Varchar(2) 性 別 empPhone Varchar(20) 電話號碼 empAddress Varchar(100) 家庭住址 empHireDate datetime 受雇日期 Salary Int 薪 水 表 32 供應商表 (tb_ supplier)： 字段名 類型 說明 SupID varchar(16) 編號，主鍵 SupName varchar(20) 用戶名 SupAge varchar(20) 年 齡 SupSex Int 性 別 SupPhone varchar(20) 電話號碼 SupAddress Int 家庭住址 18 表 33 圖書類型表 (tb_ bookType)： 字段名 類型 說明 idType varchar(16) 編號，主鍵 name varchar(20)