基于UML的圖書館借閱管理系統(tǒng)設計

1、附件1：學 號： 課 程 設 計題 目基于UML的圖書館借閱管理系統(tǒng)設計學 院計算機科學與技術專 業(yè)計算機科學與技術班 級計算機0803姓 名指導教師2012年01月10日課程設計任務書學生姓名： 專業(yè)班級： 計算機0803班 指導教師： 工作單位：計算機科學與技術學院 題 目: 基于UML的圖書館借閱管理系統(tǒng)設計初始條件：理論：學完UML及軟件體系結(jié)構(gòu)課程，掌握一種計算機高級語言的使用。實踐：計算機實驗中心提供計算機及軟件開發(fā)環(huán)境。要求完成的主要任務: （包括課程設計工作量及其技術要求，以及說明書撰寫等具體要求）（1）系統(tǒng)分析（包括系統(tǒng)描述（問題域描述）、用例模型、分析類圖）。（2）系統(tǒng)設計

2、（包括系統(tǒng)的邏輯模型如設計類圖、順序圖、狀態(tài)圖及組件圖等）。（3）系統(tǒng)實施（包括信息代碼設計、數(shù)據(jù)庫設計、輸入設計、輸出設計、用戶界面設計和處理過程的設計以及最終的程序設計）。（4）編制好程序后，設計若干測試用例，上機測試并通過所設計的程序系統(tǒng)。（5）設計報告格式按附件要求書寫。課程設計報告書正文的內(nèi)容應包括： 1問題描述；2用例模型及分析類圖的描述；3設計類圖、核心用例的順序圖與狀態(tài)圖、組件圖等的描述；4信息代碼設計、數(shù)據(jù)庫設計、輸入設計、輸出設計的描述；5用戶界面設計和處理過程的設計的描述；6給出軟件的測試方法和測試結(jié)果。7設計的特點、不足、收獲與體會。時間安排：設計安排3周（17-19周

3、）：第一周周1至周4：完成系統(tǒng)分析；第一周周5：完成系統(tǒng)設計。第二周周1至周5：完成系統(tǒng)實施中的信息代碼設計、數(shù)據(jù)庫設計、輸入設計、輸出設計、用戶界面設計和處理過程的設計。第三周周1至第三周周3：完成系統(tǒng)實施中的程序設計。第三周周4至周5：撰寫課程設計報告。設計驗收安排：第19周的星期五第14節(jié)課到實驗中心進行上機驗收。設計報告書收取時間：第19周星期五晚上7：30。指導教師簽名： 2011年11月21日系主任（或責任教師）簽名： 年 月 日基于UML的圖書館借閱系統(tǒng)設計1. 問題描述1.1. 需求分析描述圖書借閱系統(tǒng)開發(fā)的總體任務是實現(xiàn)圖書的借閱和管理信息化,在圖書借閱系統(tǒng)中,對于讀者來說,

4、他們所關心的問題是如何能夠方便的查閱到書籍以及自己正在借閱或是已經(jīng)借閱了什么樣的書,所借的書是否已經(jīng)到期,對于上述的需求進行分析之后,可以得到一個面向讀者的簡單需求分析并得出系統(tǒng)在面向讀者方面應該至少做到如下幾點: 修改個人密碼管理 查詢書籍并借閱書籍 續(xù)借書籍管理 歸還書籍管理 為過期的書籍進行付款 注冊帳號管理而對于圖書館管理員來說,他們需要關心的問題是: 圖書館中書籍如何管理,比如方便地增加,刪除,以及編輯一些書籍,并知道哪些書籍已經(jīng)被借出去,借出的書就不能被管理了. 對于規(guī)則的一些管理,因為每個圖書館都有每個圖書館的規(guī)則,比如第一次借閱天數(shù),最大借閱的本數(shù),最大的續(xù)借次數(shù),最大每次續(xù)借

5、天數(shù)等一些規(guī)定,這些都可以通過設定的一些改變來做出不同的策略. 對于借閱者卡號的一些管理,因為只涉及到借閱圖書方面,所以暫時只考慮了對于借閱者卡號的充值,停封,恢復方面的功能.1.2. 性能分析描述因為該系統(tǒng)是基于JSP的B/S系統(tǒng),所以對于客戶端訪問的性能要求很低,在服務器配置方面得根據(jù)圖書館的書籍多少以及服務質(zhì)量程度方面進行考慮.1.3. 安全分析描述安全性方面首先是服務器端的端口,采用的是SQL2000的默認端口,因此在端口可設防火墻以免受到攻擊,在用戶登陸進行操作后,如果是用戶想直接進入需要進行操作的頁面時,頁面會自動識別其ID并作出相應的處理,非法用戶直接踢出登陸入口,合法用戶會顯示

6、其詳細信息.2. 用例設計描述2.1. 用例模型描述用例模型圖如下:圖2-1(用例模型圖)用例的用戶中分兩個角色,一個是管理員,一個借閱者,用例分類為管理操作和借閱操作兩個大部分,然后分為如圖1的一些功能用例.2.2. 分析類圖描述 類圖如下:圖2-2(類圖)分為圖書信息類,借閱者卡號信息類,管理員信息類,借閱信息類,懲罰信息類,規(guī)則信息類,其中借閱者信息類和管理員信息類各自有自己的方法,借閱者不能對除自己個人密碼外的其它類進行操作,管理員可以對規(guī)則信息,圖書信息,借閱者卡號信息進行操作.3. 用例詳細設計描述3.1. 類圖設計類圖如圖2,圖書信息類中分為圖書的ID號,圖書的名字,圖書的作者,

7、ISBN號,出版期,價格,入庫時間,狀態(tài)等信息.借閱者不能對其屬性進行操作,但是可以有一定的聯(lián)系,從而產(chǎn)生相應的類,比如懲罰類和借閱類,管理員可以對實體信息類進行直接操作,修改其信息,從而保證了類的對外封裝性以及對內(nèi)可操作性.3.2. 核心用例時序圖設計 主要的核心用例:借閱書籍用例,注冊用例,對于管理員來說有:增加書籍信息,刪除書籍信息,編輯書籍信息. 下面通過這些用例進行分析: 借閱書籍用例時序圖圖3-1(借閱書籍用例時序圖) 注冊用例時序圖圖3-2(注冊用例時序圖) 增加書籍信息用例時序圖圖3-3(增加書籍用例時序圖) 刪除書籍信息用例時序圖圖3-4(刪除書籍用例時序圖) 編輯書籍信息用

8、例時序圖圖3-5(編輯書籍用例時序圖)3.3. 核心用例狀態(tài)圖設計 借閱書籍用例狀態(tài)圖 圖3-6(借閱書籍用例狀態(tài)圖) 注冊用例狀態(tài)圖圖3-7(注冊用例狀態(tài)圖) 增加書籍用例狀態(tài)圖圖3-8(增加書籍用例狀態(tài)圖) 刪除書籍用例狀態(tài)圖圖3-9(刪除書籍用例狀態(tài)圖) 編輯書籍用例狀態(tài)圖圖3-10(編輯書籍用例狀態(tài)圖)3.4. 組件圖設計 組件主要是JSP文件,如下圖:圖3-11(主要結(jié)構(gòu)圖) 在admin_op包里面有:圖3-12(admin_op包里的組件內(nèi)容) 在user_op包里面有:圖3-13(user_op包里的組件內(nèi)容)4. 代碼設計描述4.1. 信息代碼設計描述首先在圖書信息類里的信息

9、代碼: 圖書的ID 設計為8位,其中第一位數(shù)字代表書籍的國籍,0表示國外,1表示國內(nèi),第2-3位數(shù)字代表圖書的類型,可以由每個館自己定義其數(shù)字,比如12為建筑學類,13為交通管理學. 狀態(tài)設為bit型,0表示被借出去,1表示未被借出去.在借閱者信息類里: 借閱者的ID是在注冊的同時通過系統(tǒng)當時的時間函數(shù)currentTimeMillis()生成一個時間值,這個時間值是從1970年1月1日0點到目前時刻所走過的毫秒數(shù),因此注冊的ID不可能重復. 借閱者的卡號就是學生一卡通的卡號,必須是13位數(shù)字而且以”012”開頭. 規(guī)則ID是應用學生的規(guī)則，注冊時初始為當?shù)貓D書館的規(guī)則，我定義的規(guī)則ID是24

10、34,詳細說明見規(guī)則信息類代碼描述 狀態(tài)同樣設為bit型，0表示被停封，1表示正常狀態(tài)，當被停封時不能登陸在規(guī)則信息類里: 規(guī)則ID表示圖書館規(guī)則代號，定義為整型，只能為4位，具體的數(shù)值供管理員寫入在借閱關系信息類里: 借閱ID也是通過時間函數(shù)值產(chǎn)生的，不同的，為防止在借閱幾本書的同時產(chǎn)生相同的ID,采用了系統(tǒng)計數(shù)疊加的方法防止重復在懲罰信息類里: 懲罰ID和借閱ID的原理一樣，超過規(guī)定的時間就會產(chǎn)生懲罰ID,也為防止重復采用系統(tǒng)計數(shù)疊加4.2. 數(shù)據(jù)庫設計描述列名數(shù)據(jù)類型描述備注Reader_IDvarchar借閱ID 主鍵CardNumbervarchar卡號Passwordvarchar

11、密碼ReaderNamevarchar借閱者姓名Card_start_timevarchar卡號注冊時間Card_valuable_timeint卡號有效時間Rule_IDint規(guī)則IDStatementbit狀態(tài)Stored_moneymoney卡上的金額表4-1借閱者數(shù)據(jù)庫列名數(shù)據(jù)類型描述備注Admin_IDvarchar管理員ID主鍵CardNumbervarchar卡號Passwordvarchar密碼Admin_namevarchar管理員姓名表4-2 管理員數(shù)據(jù)庫列名數(shù)據(jù)類型描述備注Book_IDBigint圖書ID主鍵TitleVarchar書名AuthorVarchar作者IS

12、BNVarcharISBN號Publish_timeVarchar出版時間Pricemoney價格In_timeVarchar入庫時間Statementbit狀態(tài)表4-3 圖書數(shù)據(jù)庫列名數(shù)據(jù)類型描述備注Rule_IDint規(guī)則ID主鍵Rule_namevarchar規(guī)則名稱Borrow_daysInt最大借閱天數(shù)Secondary_borrow_daysInt最大續(xù)借天數(shù)Max_borrow_mountsInt最大借閱本數(shù)Max_Secondary_borrow_timesint最大續(xù)借次數(shù)Punish_pricemoney懲罰金額率元/天表4-4 規(guī)則數(shù)據(jù)庫列名數(shù)據(jù)類型描述備注Punish_

13、IDvarchar懲罰ID主鍵Reader_IDvarchar借閱者IDBook_IDvarchar圖書IDPunish_reasonvarchar懲罰原因默認為懲罰Punish_moneymoney罰款金額表4-5 懲罰數(shù)據(jù)庫列名數(shù)據(jù)類型描述備注Borrow_IDvarchar借閱ID主鍵Reader_IDvarchar借閱者IDBook_IDvarchar圖書IDPunish_IDvarchar懲罰IDBorrow_timevarchar借閱時間Secondary_borrow_timesint已續(xù)借次數(shù)表4-6 借閱關系數(shù)據(jù)庫4.3. 輸入設計描述 因為是采用的JSP頁面管理,在頁面里有

14、下拉框輸入,文本輸入,多選框,單選框輸入,然后通過表單提交發(fā)送信息.4.4. 輸出設計描述 根據(jù)消息產(chǎn)生的不同情況,提示消息有頁面直接顯示,彈出對話框顯示,還有在文本框里顯示在數(shù)據(jù)庫里的記錄.5. 界面設計描述5.1. 用戶界面設計在注冊和登陸界面方面沒有過多進行設計,只是簡單的表格和輸入框形式,登陸框分為兩個,一個是管理員登陸入口,另一個是用戶登陸入口,如下圖: 圖5-1(登陸界面圖)注冊界面如下:圖5-2(注冊界面圖)借閱者操作界面基本都是多選框操作,下面只例舉借閱時候的界面,(這時候搜索的是書名為fdf的結(jié)果,默認的是顯示全部的圖書,灰色的fdf書是已經(jīng)被借出去了的):圖5-3(借閱查詢

15、選擇界面)管理員的操作界面只舉兩個:一個是增加書籍信息界面,第二個是查詢并編輯書籍.圖5-4(增加書籍記錄界面)圖5-5(查詢we書籍并選中界面)圖5-6(對we書籍進行編輯界面)5.2. 界面處理設計 在界面處理方面: 用戶不會因為不正常的操作而陷入一個死角,都有基本的處理,比如你在選中借閱后,但是沒有在多選框中選中任何圖書,這時候就會提示沒有選中,或是直接不做處理,仍然在停留在原頁面. 界面保持原樣,有時候同一個頁面需要進行多個交互,這樣的話一個界面是遠不夠的.所以可以建立像_server這樣同樣的界面來交互并發(fā)送信息. 界面都是通過相應的身份ID來交互的,這個ID是通過表單的一個隱藏類數(shù)

16、據(jù)來傳送的,因此不能因為沒有ID的用戶通過打一個操作界面而可以進行操作,這樣可以保證界面始終不對非法用戶開放,無ID的用戶直接返回登陸界面6. 測試描述6.1. 測試方案及相應結(jié)果6.1.1. 用例測試因為用例涉及很多,所以將幾個非常需要去測試的用例列舉出來了.注冊用例 任何一個輸入為空,就會提示輸入為空.在用戶姓名輸入fdfg,在卡號輸入f,其余都不輸入,得到如下圖所示: 注冊卡號必須13位而且以”012”開頭.用戶姓名輸入fdfg,卡號輸入07,密碼12 重新密碼 12 注冊卡號不能相同,如果相同了,就證明以前有注冊過,提示注冊過了(名字可能有相同的人)用戶姓名輸入fdfg,卡號輸入07,

17、密碼12 重新密碼 12 輸入的密碼必須一致,否則提示兩次輸入密碼不一致.用戶姓名輸入fdfg,卡號輸入23,密碼12 重新密碼 31.增加書籍用例 圖書的ID是8位且必須為數(shù)字 圖書的名字可以為漢字可以為英文 里面的各個日期都必須是YYYY-MM-DD,并且MM不能大于12,DD不能大于31, ISBN號10位必須為數(shù)字 各個輸入不能為空 不能增加重復ID的圖書截圖(略)7. 設計優(yōu)缺點及心得 用例模塊設計用例方面的角色很清楚,一個管理員,一個是借閱者,至于書籍,規(guī)則等實體對象方面沒有作為角色考慮,因為感覺沒有必要添加一個被操作的角色名稱,這樣會添加用例聯(lián)系復雜性,因此,在用例的操作行為對象

18、上劃清了界限,這樣的話方便管理這些行為信息.因為只是借閱系統(tǒng),所以在管理員的用例方面沒有作太多的功能,比如對借閱者的卡號詳細信息進行管理,還有管理員的自我信息修改等,因為感覺那是屬于圖書館管理方面的系統(tǒng)了,所以沒有多花時間去考慮. 數(shù)據(jù)庫設計數(shù)據(jù)庫方面感覺自己設計還是可以的,數(shù)據(jù)庫的表名中的內(nèi)容沒有多的冗余內(nèi)容,基本都是根據(jù)一個實體類應有的信息進行創(chuàng)建的,而且界限很清晰,分為讀者,借閱,書籍,管理員,懲罰,規(guī)則,這些類既可以互相的制約,但是離開某個類后又不會影響該類的基本信息,符合所有非主屬性對每一個碼都是完全依賴,所有主屬性對每一個不包含的碼完全依賴,沒有任何屬性完全依賴于非碼的任何一組屬性

19、. 數(shù)據(jù)設計在數(shù)據(jù)方面,像即時ID的之類的類型基本都是字符串形式,這樣的話比較好從數(shù)據(jù)庫中查詢,因為一般都是通過字符串查詢來獲得結(jié)果集的,這樣依然可以把結(jié)果集中的字符串再轉(zhuǎn)換成其它形式.在圖書借閱系統(tǒng)中時間是一個很重要的東西,在JAVA中獲取時間的格式是和我們平常生活中的格式不一樣的,所以還得把Date類型格式的日期用一個函數(shù)格式化為YYYY-MM-DD HH:MM:SS 這樣平常使用的形式存入數(shù)據(jù)庫中.對于過期的時間的話不能通過普通的1天就是加1天,因為你不知道下一個月到底是多少天,是30還是31天都不清楚,而是要把系統(tǒng)的Date格式轉(zhuǎn)化為毫秒時間,然后通過加上借閱天數(shù)的毫秒數(shù)獲得未來到期的時間,那樣才是真實的到期時間.還一個就是漢字解析問題,存入數(shù)據(jù)庫時,如果沒有進行編碼轉(zhuǎn)換的話,存入數(shù)據(jù)庫里面的就不是漢字,而是亂碼,從而導致再次查詢時不能正常的獲取字段,原因是數(shù)據(jù)在傳輸時是以ISO-8859-1格式傳輸?shù)?所以在得轉(zhuǎn)換為gb2312所再存到數(shù)據(jù)庫中.最后一個就是sql2000中的