這份報告幫助了很多人完成學業，你值得擁有
下載鏈接: https://download.csdn.net/download/secretstarlyp/12504045
面向對象的系統分析與設計
課程實驗報告
1.研究背景及意義
學校圖書館希望設計一個圖書管理系統，管理讀者的登記、圖書的購入、借出、歸還以及註銷等。管理人員還可以查詢某位讀者、某本圖書的當前借閱情況、歷史借閱記錄，並可按照讀者角度、圖書角度、借閱角度分別進行統計，給出統計報表，以全面掌握圖書的流通情況。
目前圖書館爲手工管理，讀者辦理借閱等手續麻煩，而且管理員工作量打，開發這個系統最主要是方便管理，讀者可以咋計算機上查詢，預訂圖書，不須到圖書館直接去查找，這樣節省了很多時間，管理員也可以再計算機上操作圖書管理及讀者管理，方便快速。目前的圖書館也可以進行信息查詢預訂圖書，但因爲是手工管理，速度慢，不方便，新的系統可以快捷的實現這些功能。爲圖書館和讀者都帶來方便。
基於WEB的圖書管理系統是對圖書館的網上管理，提高工作的效率。目標系統在至少應提供一下功能：系統管理員能夠實現對系統管理：包括圖書，借閱信息等的插入、修改、註銷等功能，其中涉及基於以上操作的管理員操作，借閱者操作兩個方面。目標系統可以查詢某位讀者、某本圖書的當前借閱情況、歷史借閱記錄，並可按照讀者角度、圖書角度、借閱角度分別進行至少應該提供以下功能;證件的確認，借閱者可以查詢自己的借閱信息，資料，預訂圖書等，管理員可以統計，給出統計報表，以全面掌握圖書的流通情況。
2.系統的需求分析
2.1技術可行性
學校只需要建立一個局域網，並引入適當量的硬件設備就可以實現圖書管理系統的應用，目標系統準備使用Java技術實現，目前這種技術已經普遍，因此在技術手段上實現本系統成爲可能，高校也有計算機師資力量，對一定的軟件師生有能力在一定時間內掌握。綜上所述，目前實現目標系統的條件已經較爲成熟。
2.2經濟可行性
目標系統開發所需要求比較低，且系統不是十分複雜，開發的週期較短，人員經濟支出有限。當系統開發完實際運行後，將會改變學校原有的圖書手工管理，給許多讀者帶來方便，並且系統的開發將提高讀者的時間利用率。
2.3系統的具體功能性需求
2.3.1用戶分類和特徵：
管理員：圖書管理系統的管理者，管理讀者的登記、圖書的購入、借出、歸還以及註銷。查詢某位讀者、某本圖書的當前借閱情況、歷史借閱記錄，並可按照讀者角度、圖書角度、借閱角度分別進行統計，給出統計報表全面掌握圖書的流通情況。
讀者：借閱圖書館圖書的人。查詢，借閱，歸還圖書。
2.3.2功能需求
- 讀者註冊：沒有賬號的讀者可以註冊用戶，覈實讀者爲本校教師或學生後予以註冊。
- 讀者登記：爲讀者編制讀者卡片，包括讀者的具體信息（讀者編號，姓名，學院，專業，年級等），寫入讀者目錄文件中。
- 購入新書：爲該書編制圖書卡片，包括分類目錄號、流水號（唯一）書名、作者、內容摘要、價格和購書日期等信息，寫入圖書目錄文件中。
- 圖書註銷：在某些情況下，需要對圖書館的圖書進行清理工作，對無價值的和過時的圖書要註銷。
- 讀者借書：先檢查該讀者是否有效的讀者，若無效則拒絕借書，否則檢查該讀者所借圖書是否超過最大限制數（五本）以及有未歸還的過期圖書，否則拒絕借書。查找該圖書是否有多冊，如果有則可以借出，登記圖書分類號、讀者號和借閱日期等。
- 讀者還書：根據書號，從借書文件中讀出有關記錄，標明還書日期，如果圖書過期，則處以罰款，並打印罰款單。
- 查詢打印：根據需要可分爲查詢某位讀者、某種圖書和全局圖書三種方式進行，同時可以打印讀者和圖書情況統計表。
- 系統維護：管理員可以對系統的數據進行維護，如增加、刪除和更新書目，增加、刪除和更新借閱者帳戶，增加和刪除書籍。
2.3.3非功能性需求：
（1）性能需求
- 系統在10秒內響應所有的請求；
- 系統應該每週七天、每天24小時都可以使用，並且在每天中午13：00——13：30進行書目的借閱情況及庫存情況更新；
- 對一個沒有經驗的用戶而言，經過兩個小時的培訓就可以使用系統的所有功能。
（2）輸入輸出需求
輸入需求：
- 查詢時輸入讀者姓名，證件號碼，密碼，書目名稱或書目代碼；
- 讀者輸入姓名類型爲char；
- 讀者輸入的證件號碼類型爲char，號碼範圍爲1000000000——4999999999；
- 讀者輸入的密碼類型爲char;
- 讀者輸入書目名稱的類型爲char;
- 讀者輸入書目代碼的類型爲char,範圍爲xxA0000——xxZ9999；
輸出需求：
- 查看借閱信息正常輸出顯示借閱者姓名，學號，學院，借閱歷史，剩餘借閱量，預約狀態，欠費狀態，書目過期時間，即將過期書目顯示續借狀態；
- 查詢正常輸出顯示書目名稱，作者，發表日期，庫存量，可借數目，庫存地址；
- 預約正常輸出顯示書目名稱，作者，發表日期及預約成功；
- 借閱正常輸出顯示當前借閱者信息及書目名稱，作者，過期時間，剩餘借閱量；
- 借閱量滿情況下借閱時，顯示不能再借書；
- 欠費狀態顯示欠費情況，提示交費，不能借書；
- 讀者輸入信息不正確時，顯示輸入錯誤！請重新輸入。
（3）故障處理需求
- 死機情況下軟件要能自動保存當前信息。
- 處理：重啓機器，並查看覈實信息。
- 輸入信息類型不正確時，顯示請重新輸入有效信息。
- 不能正確顯示讀者信息或借閱信息時，管理員要覈查讀者信息，並對系統信息進行及時改正。
3.用例分析
用例圖
在本系統中一共包含了三個參與者：
（1）其中讀者的主要用例包括查詢讀者賬戶（即查詢自己的個人信息以及查詢自己的賬戶和借閱情況）、借書、還書和查詢圖書信息。
（2）圖書管理員的主要用例是查看讀者的賬戶，包括讀者的個人信息以及讀者的賬戶和借閱情況。在對書籍的信息進行管理的時候能夠查看並添加添加圖書的各種信息，修改圖書的信息，以及刪除圖書的信息。在對借書記錄和還書記錄進行管理時圖書管理員可以判斷讀者的借書情況是否超期，根據超期的情況決定是否需要罰款。
（3）系統管理員有五個用例，管理借閱者信息，包括添加新生信息和刪除畢業生信息。在對圖書的信息進行管理的時候，也能夠添加新書的信息和刪除已損壞圖書的信息。同時，系統管理員也可以查詢現有所有圖書的信息，來決定是否需要引進新書。系統管理員也可以管理借書記錄和還書記錄，主要是當圖書管理員遇到問題時，系統管理員也可以實現借還書的功能，另外，圖書管理員和系統管理員都繼承於圖書館內部人員這個父類。
4.數據庫分析與設計
類圖
本系統一共設計了七個類： 。
讀者類：屬性包含（1）讀者證號 （2）密碼 （3）最大借書數量
方法包括（1）借書 （2）還書 （3）查看用戶賬戶 （4）查看借書數量 （5）登錄系統
（5）查詢圖書信息 （6）交罰款
圖書管理員類：屬性包含（1）管理員帳號 （2）密碼
方法包括（1）查詢圖書信息（2）修改圖書信息
書架類：屬性包含（1）書架號 （2）類型（3）位置（4）存放數量
方法只有 存放圖書
圖書類：屬性包含（1）書號（2）書名（3）數量（4）價格（5）出版社
（6）館藏冊數（7）在館冊數
系統管理員類：屬性包含 值班時間
方法包括（1）查看用戶個人信息（2）修改用戶個人信息
後臺系統類：屬性包含（1）級別（2）配置
方法包括（1）存儲用戶個人信息（2）存儲圖書信息（3）存儲借閱信息
Item類：屬性包含 id
方法包括（1）創建（2）銷燬（3）更新（4）顯示圖書信息（5）顯示借閱次數
其中，圖書管理員類和系統管理員類是工作人員類的子類，圖書管理員在繼承了其父類的屬性和操作以外還自己添加了管理員帳號和密碼這兩個屬性，添加了查詢圖書信息和修改圖書信息這兩個操作。系統管理員在繼承了父類的基礎以外還添加了值班時間這個屬性，以及查看用戶個人信息和修改用戶個人信息這兩個操作。
另外，讀者類和工作人員類是Person類的子類，讀者在繼承了其父類的屬性和操作以外還自己添加了讀者證號、密碼和最大借書數量這幾個屬性，添加了借書、還書、查看用戶賬戶、查看借書數量、登錄系統、查詢圖書信息和交罰款這些操作。工作人員在繼承了其父類的屬性和操作以外還自己添加了工資和管理範圍這兩個屬性，添加了登錄賬戶、查詢用戶借閱信息、管理借書記錄、管理還書記錄、查看用戶賬戶這些操作。
Person類是讀者類和工作人員類的父類，它包含了所有人都有的三個屬性：姓名、性別和年齡。讀者類和工作人員類繼承於Person類，這就簡化了這兩個子類的屬性。
類之間的關係先從圖書管理員講起，圖書管理員能夠爲讀者提供服務，因此，二者之間應該是服務與被服務的關係。另外，圖書管理員能夠管理書架和圖書，而且書架與圖書之間是存放與被存放的關係，所有的圖書都被存放於圖書館的書架中。最後，圖書管理員還能夠查看Item，Item類有點類似於超市中在購物後產生的小票，當讀者在完成整個借閱的操作之後，後臺系統會自動生成一個Item，因此，在類圖中Item與後臺系統之間是一種聚合的關係，而讀者也可以查看Item，因爲當讀者在完成借閱之後，Item便可以證明借書是否成功以及後臺系統是否發生故障。
除了圖書管理員之外，同樣繼承於工作人員的系統管理員類也與其他類有着很多聯繫，比如說系統管理員同樣與圖書類有着維護與被維護這樣的關係，但與圖書管理員不同的是，系統管理員只負責通過從後臺系統中的添加、修改或者刪除來管理圖書，而不是像圖書管理員一樣去管理實體的圖書。另外，系統管理員可以管理後臺系統，控制後臺系統中所存儲的信息以及當後臺系統在發生一些故障時，系統管理員能夠提供及時的維修。
數據表設計
圖書表
讀者表
讀者類型表
正借閱表
已還表
書架表
工作人員表
5.系統主要交互流程設計
借書過程的順序圖：
上圖表示了讀者在進行借閱操作時的一系列變化，讀者在進行借書操作之前，首先需要輸入自己的信息包括帳號和密碼，顯示器將這些信息發送給數據庫，在數據庫中將讀者的帳號和密碼進行比對，進行身份驗證，並將驗證的結果返回給讀者。如果身份驗證成功則用戶登錄成功，反之讀者登錄失敗。
然後，讀者可以向圖書管理員發送借閱請求，圖書管理員在收到消息後可以向後臺系統輸入借閱信息，後臺系統查看對應圖書的館藏冊數，並根據館藏信息，返回該圖書是否可借閱。若可借閱，則圖書管理員可在此時修改後臺系統的借閱信息，將需要借閱圖書的讀者信息添加到後臺數據庫的借閱表中，並且後臺系統自動計算當前對應的借閱時間。
此時，後臺系統調用其Item功能，當圖書管理員修改完借閱表之後，後臺系統生成一張紙質書單，即類似於超市購物時的小票，圖書管理員得到小票確認無誤後將紙質小票返回給借閱者，借閱者可以得到實體的圖書，整個借閱過程結束。
還書過程的時序圖：
讀者在進行借書操作時，可以向圖書管理員發送借閱請求，圖書管理員在收到消息後可以向後臺系統輸入借閱信息，並查看對應圖書的館藏信息，並根據館藏信息，產生一個分支判斷。若館藏冊數爲0，則不可借閱，返回錯誤信息並拒絕讀者的借閱，之後結束整個借書操作。若館藏冊數不爲0，則可借閱，後臺系統返回可借閱信息。
圖書管理員在後臺系統返回可借閱信息之後修改後臺系統的借閱信息，將需要借閱圖書的讀者信息添加到後臺數據庫的借閱表中，並且後臺系統自動計算當前對應的借閱時間，與此同時，後臺系統調用其Item功能，當圖書管理員修改完借閱信息之後，後臺系統生成一張紙質書單。
完成這兩個操作之後，借閱者可以得到實體的圖書，整個借閱過程結束。
通信圖
通信圖也叫協作圖，可與時序圖相互轉化。它是動態設計視圖，強調參加交互的各個對象的組織，通信圖只對相互之間有交互的對象和這些對象那個之間的關係建模，忽略了其它對象和關聯。
協作圖的組成部分
對象：用長方形框表示對象。
連接：使用實線標記兩個對象之間的連接。
消息：由標記在連接上方的帶有標記的箭頭表示。
活動圖：
狀態圖：
讀者在進行借書與還書操作之前首先需要通過註冊來驗證身份，學校中的圖書館借閱者以學生爲主，學生在登記學生信息之後一直處於未註冊的狀態。通過圖書館管理員對其進行註冊操作，讀者的狀態才由未註冊轉向已註冊。另外，讀者在已註冊的狀態下也可以修改個人信息，此時借閱者的狀態不變。
註冊完之後的讀者在身份驗證成功之後就可以進入到系統，進行圖書信息和自己個人信息的查詢。已註冊的讀者此時處於可借閱的狀態，若讀者借書數量小於等於10本時，在辦理借閱手續之後就可以對圖書館中的圖書進行借閱。在取完實體書之後，借閱者便進入一個未還書的狀態。
若借閱者處於未還書狀態超過2個月，則借閱者進入欠款狀態，若借閱者處於未還書狀態不超過2個月，則借閱者依舊處於未欠款狀態。當借閱者在欠款狀態時，需要進行還款，還款之後返回到未欠款狀態。通過還書，借閱者進入已還書的狀態。
此時可選擇繼續借閱或者是直接結束，若是通過繼續借閱返回，則需要進行判斷，當讀者借書數量小於等於10本時，纔可以繼續借閱，若是讀者借書數量大於10本，則直接結束，無法再借。
讀者從未登記到還書成功時的狀態圖：
圖書管理書籍狀態圖
圖書管理借閱者狀態
6.系統實現
基於 vue.js 、element-ui 搭建一個前後端分離的的圖書管理系統。具體有以下特點：
- 完備組織架構體系，基於 RBAC 模型實現用戶權限配置
- 基於導航守衛，動態生成路由、用戶菜單、麪包屑導航等
- axios 異步請求統一封裝，統一處理操作結果通知
- element-ui 組件使用覆蓋率達到 70% 以上
1.登錄界面
2.系統首頁
3.圖書界面
4.圖書編輯界面
5.圖書章節界面
6.作者管理界面
7.新增作者界面
8.編輯作者界面
9.字典配置界面
10.用戶管理界面
11.新增用戶界面
12.菜單權限界面
13.個人中心界面
14.角色管理界面
7.總結
本系統是使用java技術實現的，對於自身而言很是困難，所以在這個過程中基本處於一邊學習一邊設計的情況，通過觀看各種javaweb視頻來進行學習並設計。儘管如此還是有許多不足，除了程序本身還是有很多不足，自身的基礎知識也不是很牢固。 程序自身還有很多繁瑣並且重複的地方，由於編寫前期受到視頻的影響將前端代碼寫到的後端，採用了輸出流的方式，使得程序異常繁瑣，導致添加功能時期的進度十分緩慢，對自己造成了很大的困難，走了很多彎路。經過這段時間的努力，對javaweb編程與mysql數據庫有了更深的理解，對自己以後的學習工作道路大有裨益。
通過開發這個設備管理系統學到了很多java全棧知識，例如ssm框架、git分支、數據庫、前端等等知識點，使我進步了許多，對後端開發有了一個全新的認識，主要是把基礎設施代碼和業務代碼儘可能的分開，各自不要干擾，而且能把BEAN都統一到spring container裏面去，這樣，bean的生老病死都由spring來管理，開發者就只需要關心業務怎麼實現就好了，別一會實現功能，中間還要來段事務處理，後面還要加個數據庫錯誤處理啥的。總而言之一句話，spring解決的問題就是儘可能的業務代碼歸業務代碼，基礎設施代碼（日誌、事務，異常，對外接口......）歸基礎設施代碼，搞定解耦的問題，希望在以後的學習生涯中可以瞭解更高效的技術，從淺入深，環環相扣，每一步都會對照着官方文檔結合自己的見解進行講解，同時也會編碼實現，理論與實踐相結合。