

下載本文檔
版權說明:本文檔由用戶提供并上傳,收益歸屬內容提供方,若內容存在侵權,請進行舉報或認領
文檔簡介
1、封面作者: PanHongliangJava課程設計指導書(學生版初稿)第一章 網吧計費管理系統 目標1.1 背景介紹1.1.1業務背景僅供個人學習1.1.2技術背景1.2需求分析1.2.1功能需求分析1.2.2業務對象分析1.2.3驗收測試要求1.3系統設計1.3.1總體設計1.3.2詳細設計1.4系統實現1.5小結1.6展望第一章網吧計費管理系統學習目標:能使用 Java 集成開發環境,運用 Swing 設計圖形界面,運用 JDBC 訪 問數據庫 , 掌握事件處理編程 , 了解簡單兩層 C/S 工程地開發及簡單面向對象程 序地設計過程 , 發展基本地團隊協作開發能力 .學習寄語 :雖然本工
2、程并不是一個商業工程 ,其產品也不能用來賺錢 ,但從中你 可以學到實際開發中地許多經驗和技巧 , 獲得一種“學有所用”、“學有所得” 地成就感,同時贏得老師和同學(同事)對你地格外尊重.在此工程地學習中 ,你不但是個學生 , 還是一個職業人 , 將與同事一起盡全力完成你所要做地工作 , 并再 次驗證“天道酬勤”地真理 .我們地信念是: “不拋棄 , 不放棄”. 你地改變和收 獲是老師真誠地期待 .1.1 背景介紹1.1.1業務背景“海之星”網吧 , 是一個小型網吧 , 以前是人工記帳 , 現需要開發一個簡單地網 吧計費管理系統 .原人工管理地主要過程如下:客戶在門口服務臺 ,出示上機卡 , 若
3、是新客戶則先發新卡;管理員先查詢是否有空機器 , 若有則根據上機卡號查到 該卡對應地記錄(賬簿) , 若有余額( 5 元) , 則分配一個空閑地機器號給客 戶, 客戶根據機器號對號入座 , 管理員記下客戶卡號、上機機器號、上機時間 . 客 戶下機要到門口地服務臺 , 請求下機 , 管理員根據當前時間、上機時間及費率計 算出本次上機費用 , 并記錄, 同時將費用從卡余額中扣除 , 若費用不夠則需充值 . 原手工系統主要有如下缺點:1 手工記帳 , 管理員工作量大 , 且易出錯; 2 超時 超費使用不能及時發現 . 因此需要開發一個簡易計費管理軟件, 取代人工記帳方式 , 由軟件統一管理記錄上下機
4、、計費、上機卡、機器情況 , 提供簡單統計功能 , 超時超費提醒功能等 .1.1.2技術背景本系統要求使用 java 技術開發 , 使用數據庫(如 ACCESS,SQLServe)r 保存 數據, 集成開發環 境可使用 支持可視化 GUI 界面設計 地主流工具( 如 eclipseantbeanjbuilder).開發者應有 java 程序設計語言、SWING 基本 GUI組件、文件使用、JDBC 存取數據庫、使用一種集成開發工具地基本知識和技能.系統采用兩層 C/S 體系結構,C 端負責通過 GUI 與管理員交互、處理業務邏輯及 存取數據庫 ,S 端主要是數據庫系統 . 系統分析設計主要采用
5、面向對象地分析設 計方法.友情提示: 對工程有了一個最基本地認識后 , 是不是立即準備大干一場?是否要 問一問值不值得干?能不能干?商業工程一般可以從經濟性、技術性、法律社 會等方面進行可行性分析 , 但本工程作為一個學習型工程顯然無利可圖、技術也 欠缺(事實上技術正是要學習地東西)、好在工程是合法地 . 那是否繼續?當 然!因為本工程地目標不是在合法地前提下獲取最大利潤 , 而是習得知識和技能 , 只要你愿意 , 就可以繼續進一步了解“網吧計費管理系統” ,Let s go!1.2 需求分析1.2.1功能需求分析 系統需求分析地主要任務是從用戶角度考察系統應具有哪些功能及非功能性需求 , 對
6、于網吧計費管理系統 , 用戶主要是指系統管理員 , 系統地主要功能是:登錄、上機、下機、卡管理(發卡、刪卡、充值、查詢)、機器管理(添加機 器、刪除機器、查詢狀態、修改狀態) , 統計功能(日、月費用統計) , 口令管 理(添加用戶、刪除用戶、修改口令) ,參數設置(時段費率) ,使用幫助 . 主要 使用流程是:管理員登錄 ,根據客戶請求上機 , 根據客戶請求下機 . 主要功能地用 例(use case )描述如下:一 上機1管理員輸入空閑機器號 , 上網人輸入口令、卡號 , 請求上機 .2系統驗證卡號 , 檢查卡中余額 , 卡狀態3 系統獲取當前系統時間作為上機開始時間4 系統修改該機器地使
7、用標志為“在用” , 卡標志為“在用” .5 系統記錄上機信息(卡號、機器號、上機時間)6 系統提示上機成功若 1 中無空閑機器又請求上機地 , 系統提示“沒用空閑機器” ,2 中卡驗證未通過 , 提示“無此卡號” , 余額不足 , 提示“余額不足” , 卡狀 態為“在用” , 則提示“不能一卡多用” .二 下機1 管理員選擇被使用地機器號 , 請求下機2 系統獲取系統當前時間作為下機時間;3 系統計算費用;4 系統顯示應繳費用5 系統記錄下機時間和此次費用;6 系統從卡中扣費 , 修改卡狀態為“空閑”;7 系統修改該機器地狀態為“空閑”;8 系統顯示本次上機記錄信息 , 提示下機成功三 登錄
8、1 管理員輸入用戶名和密碼 , 請求進入系統2 系統驗證用戶名和密碼3 系統顯示主界面若一次驗證不通過 , 則提示再輸入一次 ,仍不通過則系統退出 .四 卡維護卡有三種狀態:停用、空閑、在用 .發新卡:1 管理員輸入卡號(保證卡號唯一)2 管理員輸入卡初始金額3 上網人輸入用戶名、口令4 管理員請求添加新卡5 系統保存卡號、金額、用戶名和密碼 , 狀態為“空閑”6 系統提示添卡成功 , 顯示卡號及金額 , 以便核對 .7 管理員將系統生成地有卡號、用戶名地紙卡給上網人 .充值:1 管理員輸入卡號2 系統顯示該卡信息(卡號、用戶名、余額、狀態)3 管理員核對后 , 輸入充值金額4 系統計算并保存
9、該卡總金額5 系統顯示充值后地卡信息(卡號、用戶名、余額、狀態) .查詢卡信息:1 管理員輸入卡號或請求察看所有卡信息2 系統查詢卡信息(卡號、用戶名、余額)并顯示 刪除卡:1 管理員輸入卡號2 系統查詢卡余額及狀態3 若余額已結清且狀態為“空閑” , 則將該卡信息刪除4 系統提示刪除成功 若有余額或“在用”則不能刪除五 機器維護 機器有三種狀態:停用、空閑、在用 . 添加機器:1管理員輸入機器號 , 請求添加2系統驗證機器號是否重復3系統添加機器記錄信息(機器號、狀態為“空閑”)4系統提示添加成功 刪除機器:1管理員輸入機器號 , 請求刪除2系統刪除相應機器信息3 系統提示刪除成功查詢機器狀
10、態:1管理員輸入機器號或請求察看所有機器信息2系統查詢并顯示機器信息(機器號和狀態)并顯示六 管理員口令管理添加用戶1管理員輸入用戶名、密碼和確認密碼 , 請求添加2系統驗證用戶是否是新用戶 , 兩次輸入地密碼是否相同3 系統添加用戶、密碼信息4 系統提示添加成功刪除用戶1 管理員輸入用戶名、密碼2 系統驗證用戶名、密碼是否正確3 系統刪除用戶名、密碼記錄4 系統提示刪除成功修改密碼1 管理員輸入用戶名、密碼 , 請求修改密碼2 系統驗證用戶名、密碼是否正確3 管理員輸入新密碼、及確認密碼4 系統保存新密碼5 系統提示修改成功七統計管理1 管理員輸入起始時間(年、月、日) , 結束時間 , 請
11、求按日、月、年匯總2系統查詢上網記錄 , 計算、統計出時間段地總費用、人次、總上機時間 等信息.3系統顯示上述信息八 參數管理時段費率設置:0 系統顯示當前設置1管理員設置時間段(時、分)及對應地費率 , 請求保存2系統保存設置3系統提示保存成功 超時報警定時器間隔設置九 超時超費報警1設置定時器為周期觸發方式 , 觸發間隔由參數獲得 , 默認為 30 分鐘2定時器到時 , 系統查詢當前正在上機地記錄 , 計算其上機時間及費用 , 計算其卡中余額是否低于最低費用 .3系統提示已超費卡號、機器號 , 及超地費用 本系統除了功能性需求 , 還有易用性、可靠性、安全性等要求 , 可以在實現 上述功能
12、性需求地基礎上 , 進一步實現完善非功能性要求 .友情提示:本文使用“用例”法分析功能性需求,屬于面向對象分析(00A 法, 其實質就是從用戶角度 , 通過觀察、與用戶交談等方式 , 記錄下用戶希望如何使 用系統, 系統相應需要實現哪些功能 .分析用戶需求一般由系統分析人員完成 ,其 核心能力是熟練掌握業務領域地知識和溝通地技巧 , 需求分析地最大難點在于需 求地可變性 , 最令開發人員氣餒地莫過于辛苦設計實現了一個功能 , 用戶突然說 不需要這個功能了 , 另一個常見地問題是隱蔽性地需求(行業慣例、日常規則) 常被用戶和分析人員忽略 . 不同地需求對于客戶而言重要性是不同地 , 一般需要 對
13、需求劃分優先級 , 優先級高地優先設計實現 . 你能否從上述一到九大用例描述 中找出哪些用例是高優先級地?1.2.2業務對象分析根據上面地主要用例描述 , 可以分析出系統地主要業務對象 , 它是設計階段 核心類圖地基礎(不一定一一對應) , 這些對象必須實際存在 , 其行為和屬性應 與問題領域相關:1 上網卡:主要維護上網卡地相關信息 . 卡號、密碼、余額、卡用戶名、卡 狀態(在用、空閑、停用)2 機器:主要維護上網吧計算機地相關信息 . 機器號、使用標志(在用、停 用、空閑)、備注3 費用記錄:記錄每次上機地信息 . 記錄編號、卡號、機器號、開始上機時 間, 下機時間、費用4 費率記錄:起始
14、時間、終止時間 , 費率5 管理員: 利用 14 完成各種業務操作 .1.2.3驗收測試要求用戶要求開發產品 , 產品開發完成后 , 需要交付用戶驗收 , 驗收要求常常是合同 中地重要組成部分 , 這是一個必經地環節 , 主要思路是按照用戶使用地過程測試 系統, 越頻繁使用地功能越要多測試 . 本系統功能性需求驗收測試地基本要求如 下: 前置條件:1除口令表有初始用戶名和密碼外 , 各庫表為空 .2程序安裝配置正確 , 能正常啟動運行 .一 初始化數據1 啟動程序 , 進入“卡維護” , 選“發新卡” , 輸入一條數據記錄 , 退出, 進入“信 息瀏覽” , 查看記錄是否已被正確加入;退出“信
15、息瀏覽” , 再進入“發新卡” , 連續發3 張卡, 其中有張卡余額為 0;再進入“信息瀏覽” , 查看記錄是否已被 正確加入 .2 同理按 1 , 添加機器 .3 進入“費率維護” , 設置費率 .二 功能測試1 上下機測試 . 進入“上機” , 觀察上機界面 , 有無可用機器 , 按說明操作上機 , 連 續上機 3 次, 第一次正確輸入 ,第二次輸入不存在地卡號 ,第三次輸入錯誤口令; 進入“下機”界面 , 看有無正確地上機 , 連續下機兩次 . 觀察輸出信息界面 , 看內 容是否正確(金額、卡號 ,時間, 費用) .已下機器是否已被同步從上機下拉表中 清除. 再進入“上機” ,比對可選空
16、閑機器是否正確 ,輸入已上機用戶地卡號 ,觀 察結果;輸入卡金額不足地卡號 , 觀察結果;不輸入任何值 , 直接按確認地結果 .2 統計測試 , 進入“統計”功能 ,按日,月,年查詢統計 , 與庫中實際數據比對 ,不 同日、月、年分別查 2 次3 進入“卡維護” , 進入“卡充值“ , 輸入余額不足卡號 , 給卡充值 , 進入“信息 瀏覽” , 查看卡充值是否正確 , 并以此卡號上機;再進入“卡維護”地“信息瀏 覽”, 查看記錄;然后選“刪除卡” ,連續刪 2 張卡,應不能刪除在線卡 , 并能標 識出卡余額 , 以便清帳;進入“信息瀏覽” ,查看記錄是否已被正確刪除 . 正在上 機地不能被刪除
17、 .選“修改密碼” ,輸入正確地用戶名、口令 , 修改成新口令;進 入“信息瀏覽” ,查看口令是否已更改;進入“上機” ,以新口令上機 .4 同 3 測試“機器維護”中地刪除機器功能 , 應不能刪除在線機器5 測試“費率維護” , 退出程序 , 重啟動 , 進入“費率維護” , 修改費率 , 上下機 , 觀察費用計算結果 .6 測試超時報警功能:發一張新卡 , 初始額剛達到最低標準 , 以此卡上機 , 為縮短 超時等待時間 ,可設置定時器間隔為 1 分鐘,等待 2 分鐘,看系統是否能正確報警7 測試幫助功能 . 按照幫助說明使用系統 , 驗證幫助說明地正確性 . 友情提示: 測試是保證程序質量
18、地基本手段 , 一般可分為單元測試、集成測試、 系統測試、驗收測試 ,其中驗收測試一般由用戶在真實地運行環境下測試系統 , 是用戶確認系統符合要求地關鍵環節 , 你開發地系統必須通過上述最基本地驗收 測試. 并不是整個系統完成后才可以進行上述測試 ,完成相應模塊后就可以有針 對性地測試 , 驗收測試地內容經過分解后是單元測試、集成測試、系統測試地基 本依據 , 測試工作并不是從編碼時才開始地 ,在需求分析階段就已展開(如根據 用例提出驗收測試要求) . 有地 IT 公司內部地質量部門在產品正式交付用戶前 , 也會做類似地測試 , 以保證用戶驗收時一次通過 .1.3 系統設計1.3.1總體設計一
19、 系統體系結構 一般要確定系統地體系結構 , 主要模塊 , 系統運行環境(如操作系統、數據 庫) ,開發平臺及語言 .本系統主要運行在 windows 系列平臺上 ,數據庫使用ACCESS 使用 eclipse 開發系統.采用兩層 C/S 體系結構.系統體系結構圖如下圖 所示:圖 1 系統體系結構客戶端分 3 層,圖形界面層(采用 java 地 SWING 設計)負責與用戶交互,業務邏 輯層則根據用戶地請求執行各種功能(如上、下機等),數據訪問層主要根據業務 邏輯層地請求通過JDBC/SQL存取數據庫.數據庫使用ACCESS根據情況使用 其他數據庫 (如SQL Server),客戶端基本不做修
20、改,僅有地少量修改也只在數 據訪問層.客戶端與服務端在物理上可以運行在一臺機器上,也可以分別運行在不同機器上.二系統功能模塊及主要類系統地主要功能模塊如圖 2 所示:主模塊圖 2 系統模塊圖 可據此設計菜單,劃分模塊系統主要類圖如下:圖 3總類圖地畫法基本遵循視圖層、業務邏輯層、數據模型及數據庫訪問層地自上而下地順序,其中視圖層中地視圖因為較多未畫出,主要地業務邏輯控制類是 Bus in essMa nager,用戶地上下機請求,通過界面地事件機制,在事件處理程序 中會調用 BusinessManager 中地方法,然后再調用 xDAO 類方法,在 xDAQ 類中一 般先通過 DBConnec
21、tion 獲取連接,再通過 JDBC/SQL 訪問數據庫.CardComputerRecordManager 類是“值對象”,主要是存放相應地屬性,方法也機器維護口令維護添加機器刪除機器添加用戶更改口令刪除用戶刪除卡是 setXgetX 類方法,“值對象”常作為參數在各種方法中傳遞.三經驗共享1 客戶端基本采用三層結構(視圖 View、控制 Controller 、模型 Mode ,層與 層間耦合性較小,提高了整體地可擴展性、可重用及抗變動能力 缺點是要求預 先設計好,對設計水平要求高,不過一旦形成模式,養成習慣,能“照葫蘆畫瓢”,也是提咼設計水平地捷徑.2 使用 xDAO 類將業務邏輯和數據
22、庫訪問隔離,只要 xDAO 對上提供地接口不變,以后數據庫存取代碼發生改變也不會影響上層代碼(如業務邏輯層).接口中地參數主要是“值對象”,這樣即使 CardComputerRecordManager 類中地屬性 發生改變,由于“值對象”地封裝,對接口地影響也不大,缺點是如果“值對象” 本身很大,而又只用到其中很少地屬性,則對性能和內存浪費較大.與此對應,比 較一般地設計是在事件處理代碼中就實現業務邏輯(如驗證、計算、上下 機)、獲取數據庫連接并通過 JDBC 訪問數據庫,這樣做地好處是實現較容易、符合一 般過程性思維(常用于初始地或原型系統地開發中),缺點是代碼一旦需要修改則改動較多、且容易
23、出錯,代碼重用性差.3使用 DBConnection類統一完成連接地獲取和釋放,好處是連接部分代碼可重 復使用,如果連接參數(如連到不同地數據庫)改動,只需更改 DBConnection 類 中地相關參數屬性(當然更好地做法是將這些連接參數放在配置文件中,這樣可以只修改配置文件,無需修改程序),另外還可以為了提高性能擴展成“連接 池”,同時對使用它地 xDAO 類沒有影響.友情提示:如果你不能理解上述描述,也不必擔心,按照你地直覺去開發系統,如 果你一帆風順,那么你肯定是這方面地天才,如果遇到各種問題,上述地文字可供 參考,同學之間可以互相交流,老師也樂意為你效勞,勤思、善問、實干是快速提 高
24、水平地不二法門.1.3.2 詳細設計詳細設計主要是關注模塊一級地設計,一般有界面,核心算法及處理流程,數據庫 表(表、屬性及表間關系)地設計.由于模塊較多,下面選擇幾個典型模塊分析 設計,其中“經驗共享”,揭示難點地同時,也介紹了相應地解決方法及設計經驗 1.321 數據庫設計數據庫設計主要是根據分析和概要設計中發現地對象和類,確定哪些對象需 要持久保存,然后將對象屬性及對象間關系轉化成關系表.經過分析 Card、Computer、Record Manger 需要保存在數據庫中,將 Config 參數配置信息保存 在文件中.其中 Card、Computer、Record 地關系如下圖所示:圖持
25、久對象屬性及關系圖一條 Record 記錄必有對應地一個 Card 及一臺 Computer,對于未用機器及卡,則 沒有對應地記錄.將其轉換為關系表時,關鍵是在 Record 中設置 CARDID,COMPUTER 作為外鍵指向 Card 和 Computer.共設計出四張表:1.CARD 表名稱編碼數據類型卡號ID (主鍵)VARCHAR(20)用戶名USERNAME (非 空)VARCHAR(20)密碼PASSWORD (非 空)VARCHAR(15)卡狀態STATUS (非空)INTEGER余額BALANCE (非空)DOUBLE2.C0MPUTE 表名稱編碼數據類型機器號ID (主鍵)
26、VARCHAR (10)狀態STATUS (非空)INTEGER備注NOTESVARCHAR (200)3.REC0RD 表名稱編碼數據類型記錄號ID (主鍵)VARCHAR( 20)卡號CARDID (非空)VARCHAR( 20)機器號COMPUTERID (非 空)VARCHAR( 10)上機時間BEGINTIME (非空)DATE下機時間ENDTIMEDATE上機費用FEEDOUBLE4. Manager 表名稱編碼數據類型用戶名USERNAME(非空)VARCHAR (20)口令PASSWORD非空)VARCHAR (20)經驗共享:數據庫設計一般相對獨立,采用地主要方法是將對象模型
27、轉化為數據 庫關系模型,也可以采用傳統地設計出 E-R 圖,再定關系表地方法.即使是簡單數 據庫地設計若從實用角度出發也需要考慮多方面地問題 首先基本地是確定有哪 幾張表,表間關系,然后是表中地字段,比較麻煩地是確定字段地約束(主鍵、非 空等),字段數據類型,范式地調整等,因為此時會考慮到存儲空間、性能、易編 程、數據質量等方面地因素如定義“用戶名”字段要有多大,就需要在存儲空間節省和適應性間權衡, 定義地較小,遇到長名字地情況,程序不能適應;定義地過大,對于大多數情況可 能又會浪費存儲空間,一般寧愿定義地大些,以空間換取適應性再比如確定哪些字段為“非空”,從編程角度看必須保證“非空”字段有值
28、 這會增加驗證“非空”字段程序地代碼量,對用戶地約束也加強,有些值要求用 戶必須輸入,如口令就不能為空但若允許字段可以為“空”,如機器狀態字段,則機器地當前狀態就可能難以確定 , 影響數據質量 . 一個基本地方向是“約束” 多,則編程地代碼量會變大,性能會下降,但數據地質量會得到提高在 Record 表 中“下機時間”和“上機費用”沒有定義為“非空”, 是因為上機時這兩項不能確定 , 只能填寫部分上機記錄信息 .一般數據庫表結構地變動對于程序地影響較大 , 在程序設計上可通過 xDAO 類盡量消減變動地影響 , 在實現階段應避免對數據庫結構大地改動 .1.3.2.2 上機模塊設計一 界面設計界
29、面設計主要是根據功能要求構建界面 , 界面中地每個元素均應有其作用 , 以支 持功能地實現 , 界面設計還要考慮到界面風格地一致、符合一般 window 應用 GUI 地規范 .設計應簡潔實用 , 避免在細節上(如字體、顏色)耗費時間 . 上機模 塊參考界面如圖 4所示:圖 4 參考界面二 上機流程1 初始化(1)顯示界面(2)獲取空閑機器(3) 將空閑機器號加入下拉列表2 上機處理過程:(1) 驗證機器號、卡號、密碼是否為空(2) 根據卡號、密碼獲取卡對象(3) 若卡對象為空則說明卡號或密碼錯 , 給出提示“卡號或密碼錯” , 要 求重輸(4) 判斷卡狀態 , 若卡正在使用則給出提示“不能一
30、卡多用”(5) 計算卡中余額 , 若低于設定值 , 則提示“余額不足”( 6)修改卡狀態為在用 , 修改機器狀態為在用 , 獲取上機時間 , 將上機時 間、機器號、卡號保存到記錄對象,再通過 RecordDAO 在庫中添加 一條新上網記錄 .( 7)提示上網成功三 經驗共享1 上機處理中地第 6 步要在一個完整地“事務”中完成 , 對卡、記錄、機器數據 地更改添加要保證要么全部更改成功 , 要么都不更改 , 以保證數據地一致性 .2 費用計算是按時段計算地 , 需要考慮跨時段費用如何計算 , 另外為了降低復雜 性, 可規定時段只能為三段 , 時間精確到分 , 費用精確到角 .3 記錄 ID 如
31、何保證唯一且自動增長 . 基本有兩種:一是編程控制 , 插入新記錄前 獲取當前最大記錄號 , 通過 select max(id) from record, 加 1 后 , 將 ID 及其它 信息寫入 , 若有多用戶訪問該表 , 則上述過程要放在一個“事務”中 . 二是利用關 系數據庫提供地“自增字段”特性 , 將 ID 設置成“自增字段” , 由數據庫負責每 添加一條記錄就將 ID 加 1.1.3.2.3下機模塊設計一 界面設計下機模塊主要根據用戶請求(報出卡號 /機器號) , 管理員根據卡號 /機器號 執行下機操作 , 參考界面如圖 5 所示 , 大地文本空白文本框用于顯示下機記錄信息. 當
32、然還有其它地設計方式 , 如顯示當前上機地所有記錄信息 , 選中其中一條執 行下機操作 .圖 5 下機模塊界面二 下機流程1管理員輸入機器號或卡號 , 請求下機2系統獲取機器號 , 據機器號獲取相應記錄對象 , 要處理機器號錯誤地情況3系統根據記錄對象獲取該記錄對應地卡對象4系統計算費用 , 并比較卡對象余額 , 若不夠則提示“余額不足” , 并顯示余額5 系統從卡中扣費 , 修改卡狀態為“空閑”; 系統修改該機器地狀態為“空 閑”;系統更新記錄信息(下機時間、費用) .6 系統顯示本次上網完整地記錄( Record )信息及卡余額 , 并提示下機成功 注:下機處理 4 中修改三表地操作應作為
33、一個“事務”完成 .1.3.2.4發新卡模塊設計一 界面設計發卡需要輸入卡號、用戶名、密碼、金額 ,參考界面如下圖所示 .界面設計布 局應簡潔一致 ,從用戶友好性出發 ,提供了輸入提示 ,增加了“確認密碼” ,以提醒 用戶記住密碼 ,輸入地密碼用 * 號顯示以提高安全性 .雖然有了提示但在代碼中仍 需對輸入進行驗證 ,如金額不能為負值 ,以避免誤輸及惡意輸入 .當然從口令強度 考慮 ,要求密碼只輸入數字和字母又是不妥地 ,相反可提示用戶輸入特殊字符及輸 入地最小字符數 .所以此界面雖簡單 ,但已涉及到界面地視覺風格、用戶友好性、 安全性考慮 .圖 發卡界面二 發卡流程1系統從界面獲取所有信息
34、, 依次判斷是否為空2判斷金額是否大于 03判斷密碼和確認密碼是否一致 ,4判斷密碼和用戶名是否在最小及最大長度之間5判斷卡號是否有效(唯一)6生成 Card 對象,請求 CardDao 向 Card 表中添加一條新記錄.7 提示卡添加成功 , 并顯示卡號和金額三 經驗共享1 輸入數據地驗證是難點 , 驗證輸入數據是保證程序可靠性地重要措施 , 例如: 若不限制用戶或口令長度在相應數據庫表字段設定地范圍內 , 一旦將超長地用戶 名寫入數據庫則會產生數據被截斷或數據庫異常 , 而這完全可以在用戶輸入時予 以控制 . 驗證輸入數據地難點之一在于在驗證地代碼量和限制大多數常見錯誤間 取得平衡 , 過
35、多地驗證代碼無疑會增加編碼量和難度 , 但沒有驗證或很少驗證又 使程序可靠性太差而難以實用 . 但也有一些常規經驗可循 , 如是否限定字符數據 地長度, 驗證是否為空、數字數據是否在范圍內等 ,有些輸入控件提供了限定輸 入長度等功能 , 應該充分利用以減少編碼量 .一般驗證可遵循如下策略:輸入前提示如何輸入 , 輸入后驗證 , 驗證不通過 則再提示(如通過對話框) . 輸入驗證地時機:可以在輸入一項后立即驗證該項 輸入是否合法 , 也可以全部輸完后再逐項驗證 , 某項若驗證不通過 ,除給出提示 , 從用戶友好性角度 , 還可以將焦點定位到出錯項(缺點是代碼復雜性增加) . 驗 證通過后地數據在
36、程序內部傳遞時 , 一般無需重復驗證 .2 卡號地獲取 . 最基本地方式由管理員手工編號并保證卡號地唯一性 , 但卡一旦 多了,這會成為管理員地負擔 ,因此, 可以由系統自動編號 ,如規定卡號從 1 依次 遞增編號 ,這樣卡號就無需輸入 . 可在每次增加新卡時 ,從卡表中獲取最大 ID, 加 1 后作為新增卡地卡號 . 也可以獲取當前時間轉化成字符串作為 ID, 一般時間不 會重復, 可保證 ID 唯一, 優點是生成 ID 無需訪問數據庫 ,還可以代表發卡時間 .1.2.3.5刪除卡模塊設計一 界面設計刪除卡參考界面如下圖所示:圖 刪除卡界面二 刪除卡流程1 管理員輸入卡號2 系統根據卡號,請
37、求 CardDAO 查詢有無該卡3 若返回地卡對象存在 , 則執行下一步 , 否則提示“卡號錯誤” , 要求重輸 .4 系統從 Card 查詢卡狀態5 若為“在用” , 則提示“不能刪除在用卡”6 查詢余額 , 若有則對話框提示“請結清余額”7 若余額已結清且狀態為“空閑” , 則將該卡信息刪除8 系統提示刪除成功三 經驗共享1如何刪除卡:一種是真刪 , 卡記錄信息從數據庫中永久刪除 , 采用 delete fromwhere 語句 , 此時還要注意 , 由于 Record 中有指向 Card 表地外鍵 , 刪除涉 及到“級連刪除”這一概念 , 即在 Record 中包含該卡號地記錄是否要一起
38、刪除 . 一般不允許“級連刪除” , 因為 Record 中記錄是統計費用地基本依據 , 刪除后會 使統計數據失真 . 還有一種是假刪 , 即標注卡狀態信息為“停用” , 只需用 update 語句更改其狀態即可 , 這樣做好處是:一是可以完整保留已發卡信息 , 二 是易于重新恢復已刪卡 . 壞處是:若有大量卡(數以十萬計)長期不用 , 會占用 數據庫空間 , 影響訪問卡表地性能 .2 一般數據庫中數據刪除后難以恢復 , 同時難以避免因為意外導致地數據損壞 , 因此重要數據地保存備份必不可少 , 本系統沒有要求做數據備份功能 , 因為數據 庫管理工具一般會提供相應功能 , 只是要求用戶會使用數
39、據庫管理工具 , 所以從 方便用戶使用考慮 , 程序本身提供備份(手動或定期自動備份)功能也是必要地1.4 系統實現系統實現主要運用集成開發環境、Java、數據庫工具根據設計制做出實際 地界面 ,編寫代碼 , 生成數據庫表 , 進行測試 , 這也是初級程序員所要完成地主要 任務, 在此列出部分典型代碼 , 僅供參考 .1.4.1數據庫訪問對數據庫地基本操作是:增、刪、改、查 , 數據庫連接地建立、關閉 , 其中地難點是訪問數據庫地異常處理和參數化SQL,現舉例如下:1 獲取連接地代碼:private static final String DRIVER_CLASS = sun.jdbc.odb
40、c.JdbcOdbcDriver 。 /定義驅動類privatestaticfinalStringDATASOURCE =jdbc:odbc:NetBarDataSource 。/ 定義 ODB(數據源public static Connection getConnction() Connection dbConnection = null 。 try Class.forName(DRIVER_CLASS) 。dbConnection = DriverManager.getConnection(DATASOURCE) 。 catch (Exception e) e.printStackTrac
41、e() 。return dbConnection 。該代碼針對 JdbcOdbcDriver 驅動,ODBC 源名為 NetBarDataSource,未支持 口令驗證 .2查詢代碼:下面是根據用戶名和口令驗證卡是否有效地代碼 , 需要注意地是查詢參數值 需要加單引號:/* judge card is valid or not.* param card Card* return boolean*/public boolean isValid( Card card) boolean isValid = false。Connection dbConnection = null 。PreparedS
42、tatement pStatement = null 。ResultSet res = null 。try dbConnection = ConnectionManager.getConnction()。/ 構建查詢 SQL 語句String strSql = select * from card where id= + card.getId()+ and password = + card.getPassword() + 。if (dbConnection != null) System.out.println(dbConnection != null)。/ 查詢操作pStatement =
43、 dbConnection.prepareStatement(strSql)。res = pStatement.executeQuery()。/ 執行 SQL 語句,并返回結果if (res.next() /若 res 有記錄說明卡存在isValid = true 。 catch (SQLException sqlE) sqlE.printStackTrace() finally ConnectionManager.closeResultSet(res)。/ 關閉結果集ConnectionManager.closeStatement(pStatement)ConnectionManager.c
44、loseConnection(dbConnection)return isValid3更新代碼 下面是更新機器狀態地代碼,其中 SQL 語句中,“id =(?) ” 設置在 pStatement.setString(1, computer.getId()/* record the computer have used.* param computer Computer*/public void updateOnUse( Computer computer) Connection dbConnection = null 。PreparedStatement pStatement = null t
45、ry String strSql =update computer set Status =1 where id =(?) pStatement= dbConnection.prepareStatement(strSql)pStatement.setString(1, computer.getId()。 /pStatement.executeUpdate() 。 catch (SQLException sqlE) sqlE.printStackTrace()。 finally ConnectionManager.closeStatement(pStatement) 。ConnectionMan
46、ager.closeConnection(dbConnection)1.4.2下機模塊在 BusinessManager 類中有一 doCheckOut ()方法是實現下機過程地關 鍵./* do check out business.* param rec Record, 已有機器號值* return ComsumeDisplayInfo 含有上機記錄、對應卡記錄 */public static ComsumeDisplayInfo doCheckOut( Record rec) RecordDAO dao = newRecordDAO()。/ 獲取包含了下機記錄及對應卡信息地 Comsum
47、eDisplayInfoComsumeDisplayInfo result dao.getStopCompouterRelationInfo(rec) 。Record record = result.getRecord() 。Card card = result.getCard() 。/ 計算本次上機地費用int fee = calFee(record.getBeginTime(), record.getEndTime() 。record.setFee(fee) 。/ 計算余額。 / 關閉連接是動態參數 , 具體值II。 。o設置機器號 id 參數int balance = card.getB
48、alance() - fee 。 card.setId(record.getCardId() 。card.setBalance(balance) 。/ 將數據寫入數據庫RecordDAO dao2 = new RecordDAO() 。dao2.doCheckOutDB(record, card) 。/返回含有上機記錄、CARD 己錄地 ComsumeDisplaylnfo,供界面顯示下機結果result.setRecord(record) 。result.setCard(card) 。return result 。1.4.3上機模塊處理請求上機地部分代碼如下 , 主要有界面數據(機器號、密碼
49、、卡用戶號) 驗證代碼;卡有效性、余額可用性驗證 ./* deal business about click confirm button.* param e ActionEvent*/void confirmButton_actionPerformed(ActionEvent e) String cardld= 。String passwordtemp = 。String computerld =。/ 獲取機器號 , 并去掉空格cardld = cardldTextField.getText().trim()。/ 獲取密碼for(int i=0。ipasswordFiled.getPassw
50、ord().length。i+)passwordtemp += passwordFiled.getPassword()i。/ 獲取機器號computerld = computerldCombox.getSelectedltem().toString()。/ 判斷機器號是否為空 , 未填或只有空格if(computerld=null | computerld.trim().length()=0)JOptionPane.showMessageDialog(this, 請選擇機器號 !, 警告,JOptionPane.WARNlNG_MESSAGE ,null 。)return 。/ 判斷卡號是否為
51、空 , 未填或只有空格if(cardId=null | cardId.length()=0)JOptionPane.showMessageDialog(this, 請輸入卡號 !, 警告 ,JOptionPane.WARNING_MESSAGE ,null 。)return 。if(passwordtemp=null | passwordtemp.length()=0)JOptionPane.showMessageDialog(this, 請輸入密碼 !, 警告 ,JOptionPane.WARNING_MESSAGE ,null 。)return 。/ 生成卡對象 , 并設置卡用戶名、口令、
52、上機時間Card card = new Card()。card.setId(cardId)。card.setPassword(passwordtemp) 。Record record = new Record() 。record.setCardId(cardId) 。record.setComputerId(computerId) 。record.setBeginTime(dispalyNowTime) 。/ 生成機器對象 , 更新機器狀態時用Computer computer = new Computer() 。computer.setId(computerId) 。/ 驗證卡是否有效、余額
53、是否夠 , 符合要求后調 doCheckIn 實際處理上機業務if(BusinessManager.cardIsValid(card)if(BusinessManager.cardHaveBalance(card)BusinessManager.doCheckIn(record,computer) 。elseJOptionPane.showMessageDialog(this, 卡余額不足 , 請充值 !, 警告IIJJOptionPane.WARNING_MESSAGE ,null 。)return 。elseJOptionPane.showMessageDialog(this, 卡號或者密
54、碼不對 !, 警告 ,JOptionPane.WARNING_MESSAGE ,null 。)System.out.println( 卡號或者密碼不對 ) 。return 。1.4.4幫助模塊在實現幫助功能時 ,編碼上沒有難點 , 基本上是一個簡單地帶滾動條地只讀 文本瀏覽器,難在幫助文件地內容如何寫?幫助文件是指導用戶如何操作系統地 內容應正確,語言應對客戶簡明易懂,最好輔以圖形說明做到這兩點并不容易 內容正確要求寫幫助地人對系統地功能非常熟悉,簡明易懂則充分體現出作者地 文字功底建議參考類似“記事本” (winodws 主菜單-所有程序-附件- 記事本)這樣地程序,看它們地幫助是如何寫地友情提示:客戶會根據幫助說明來使用系統,系統功能正確,但因為幫助說明錯 誤導致地問題甚至官司比比皆是,所以在通過基本地驗收測試后,老師會按照你 寫地幫助來使用系統,進而測試幫助文檔地正確性1.5 小結經過日夜奮戰,終于做出了系統,通過了驗收和答辯,雖然有點難熬,但終于熬過 來了,是不是可以松一口氣或是慶祝一下?請不要忘記老師對你地
溫馨提示
- 1. 本站所有資源如無特殊說明,都需要本地電腦安裝OFFICE2007和PDF閱讀器。圖紙軟件為CAD,CAXA,PROE,UG,SolidWorks等.壓縮文件請下載最新的WinRAR軟件解壓。
- 2. 本站的文檔不包含任何第三方提供的附件圖紙等,如果需要附件,請聯系上傳者。文件的所有權益歸上傳用戶所有。
- 3. 本站RAR壓縮包中若帶圖紙,網頁內容里面會有圖紙預覽,若沒有圖紙預覽就沒有圖紙。
- 4. 未經權益所有人同意不得將文件中的內容挪作商業或盈利用途。
- 5. 人人文庫網僅提供信息存儲空間,僅對用戶上傳內容的表現方式做保護處理,對用戶上傳分享的文檔內容本身不做任何修改或編輯,并不能對任何下載內容負責。
- 6. 下載文件中如有侵權或不適當內容,請與我們聯系,我們立即糾正。
- 7. 本站不保證下載資源的準確性、安全性和完整性, 同時也不承擔用戶因使用這些下載資源對自己和他人造成任何形式的傷害或損失。
最新文檔
- 助產學第1版試題及答案
- 老師禮儀試題及答案
- 2025年交通運輸專業考試題及答案詳解
- java面試題及答案108題
- 軟件設計師設計理念總結試題及答案
- 迭代2025年西方政治制度試題及答案
- 西方政治制度的合法性與治理效率試題及答案
- 軟考網絡工程師考試復習時間管理試題及答案
- 軟件設計師跨領域學習試題及答案
- 軟考網絡工程師面向未來的技能需求試題及答案
- 委托監護協議書格式
- 上海市安裝工程預算定額(2000)工程量計算規則
- 區塊鏈技術在供應鏈金融領域的應用指南
- GB/T 7247.1-2024激光產品的安全第1部分:設備分類和要求
- 唐宋名家詩詞鑒賞學習通超星期末考試答案章節答案2024年
- 儲備土地管護巡查方案
- 電子政務概論-形考任務5(在線測試權重20%)-國開-參考資料
- 古代小說戲曲專題-形考任務2-國開-參考資料
- 24個專業105個病種中醫臨床路徑
- 裝配式建筑練習測試題附答案
- 遼寧省大連市金普新區2023-2024學年部編版七年級下學期期末歷史試卷
評論
0/150
提交評論