1、java課程設計指導書目錄第一章 網吧計費管理系統 目標 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 展望第二章 聊天室系統目標 2.1 背景介紹 2.1.1 業務背景 2.1.2 技術背景 2.2 需求分析 2.2.1功能需求分析 2.2.2 業務對象分析 2.2.3 驗收測試要求 2.3 系統設計 2.3.1 總體設計 2.3.2 詳細設計 2.4 系統實現 2.5 小結 2.6

2、 展望第一章 網吧計費管理系統學習目標：能使用java集成開發環境,運用swing設計圖形界面，運用jdbc訪問數據庫，掌握事件處理編程，了解簡單兩層c/s項目的開發及簡單面向對象程序的設計過程，發展基本的團隊協作開發能力。學習寄語：雖然本項目并不是一個商業項目，其產品也不能用來賺錢，但從中你可以學到實際開發中的許多經驗和技巧，獲得一種“學有所用”、“學有所得”的成就感，同時贏得老師和同學（同事）對你的格外尊重。在此項目的學習中，你不但是個學生，還是一個職業人，將與同事一起盡全力完成你所要做的工作，并再次驗證“天道酬勤”的真理。我們的信念是：“不拋棄，不放棄”。你的改變和收獲是老師真誠的期待。

3、1.1 背景介紹1.1.1 業務背景“海之星”網吧，是一個小型網吧，以前是人工記帳，現需要開發一個簡單的網吧計費管理系統。原人工管理的主要過程如下：客戶在門口服務臺，出示上機卡，若是新客戶則先發新卡；管理員先查詢是否有空機器，若有則根據上機卡號查到該卡對應的記錄（賬簿），若有余額（5元），則分配一個空閑的機器號給客戶，客戶根據機器號對號入座，管理員記下客戶卡號、上機機器號、上機時間。客戶下機要到門口的服務臺，請求下機，管理員根據當前時間、上機時間及費率計算出本次上機費用，并記錄，同時將費用從卡余額中扣除，若費用不夠則需充值。原手工系統主要有如下缺點：1 手工記帳，管理員工作量大，且易出錯；2

4、超時超費使用不能及時發現。因此需要開發一個簡易計費管理軟件，取代人工記帳方式，由軟件統一管理記錄上下機、計費、上機卡、機器情況，提供簡單統計功能，超時超費提醒功能等。1.1.2 技術背景 本系統要求使用java技術開發，使用數據庫（如access，sqlserver）保存數據，集成開發環境可使用支持可視化gui界面設計的主流工具(如eclipseant beanjbuilder)。開發者應有java程序設計語言、swing基本gui組件、文件使用、jdbc存取數據庫、使用一種集成開發工具的基本知識和技能。系統采用兩層c/s體系結構，c端負責通過gui與管理員交互、處理業務邏輯及存取數據庫，s端

5、主要是數據庫系統。系統分析設計主要采用面向對象的分析設計方法。友情提示：對項目有了一個最基本的認識后，是不是立即準備大干一場？是否要問一問值不值得干？能不能干？商業項目一般可以從經濟性、技術性、法律社會等方面進行可行性分析，但本項目作為一個學習型項目顯然無利可圖、技術也欠缺（事實上技術正是要學習的東西）、好在項目是合法的。那是否繼續？當然！因為本項目的目標不是在合法的前提下獲取最大利潤，而是習得知識和技能，只要你愿意，就可以繼續進一步了解“網吧計費管理系統”，lets go!1.2 需求分析1.2.1功能需求分析系統需求分析的主要任務是從用戶角度考察系統應具有哪些功能及非功能性需求，對于網吧計

6、費管理系統，用戶主要是指系統管理員，系統的主要功能是：登錄、上機、下機、卡管理（發卡、刪卡、充值、查詢）、機器管理（添加機器、刪除機器、查詢狀態、修改狀態），統計功能（日、月費用統計），口令管理（添加用戶、刪除用戶、修改口令），參數設置（時段費率），使用幫助。主要使用流程是：管理員登錄，根據客戶請求上機，根據客戶請求下機。主要功能的用例（use case）描述如下：一 上機 1 管理員輸入空閑機器號，上網人輸入口令、卡號，請求上機。 2 系統驗證卡號，檢查卡中余額，卡狀態3系統獲取當前系統時間作為上機開始時間4 系統修改該機器的使用標志為“在用”，卡標志為“在用”。5 系統記錄上機信息（卡號、

7、機器號、上機時間）6 系統提示上機成功若1中無空閑機器又請求上機的，系統提示“沒用空閑機器”，2中卡驗證未通過，提示“無此卡號”，余額不足，提示“余額不足”，卡狀態為“在用”，則提示“不能一卡多用”。二 下機1 管理員選擇被使用的機器號，請求下機2 系統獲取系統當前時間作為下機時間；3 系統計算費用；4 系統顯示應繳費用5 系統記錄下機時間和此次費用；6 系統從卡中扣費，修改卡狀態為“空閑”；7 系統修改該機器的狀態為“空閑”；8系統顯示本次上機記錄信息，提示下機成功三 登錄1 管理員輸入用戶名和密碼，請求進入系統2 系統驗證用戶名和密碼3 系統顯示主界面若一次驗證不通過，則提示再輸入一次，仍

8、不通過則系統退出。四 卡維護卡有三種狀態：停用、空閑、在用。 發新卡：1 管理員輸入卡號（保證卡號唯一）2 管理員輸入卡初始金額3 上網人輸入用戶名、口令4 管理員請求添加新卡5 系統保存卡號、金額、用戶名和密碼，狀態為“空閑”6 系統提示添卡成功，顯示卡號及金額，以便核對。7管理員將系統生成的有卡號、用戶名的紙卡給上網人。 充值：1 管理員輸入卡號2 系統顯示該卡信息（卡號、用戶名、余額、狀態）3 管理員核對后，輸入充值金額4 系統計算并保存該卡總金額5 系統顯示充值后的卡信息（卡號、用戶名、余額、狀態）。 查詢卡信息：1 管理員輸入卡號或請求察看所有卡信息2 系統查詢卡信息（卡號、用戶名、

9、余額）并顯示 刪除卡：1管理員輸入卡號2 系統查詢卡余額及狀態3 若余額已結清且狀態為“空閑”，則將該卡信息刪除4 系統提示刪除成功若有余額或“在用”則不能刪除 五 機器維護機器有三種狀態：停用、空閑、在用。添加機器： 1 管理員輸入機器號，請求添加 2 系統驗證機器號是否重復 3 系統添加機器記錄信息（機器號、狀態為“空閑”） 4 系統提示添加成功刪除機器： 1 管理員輸入機器號，請求刪除 2 系統刪除相應機器信息3 系統提示刪除成功查詢機器狀態： 1管理員輸入機器號或請求察看所有機器信息 2 系統查詢并顯示機器信息（機器號和狀態）并顯示六 管理員口令管理 添加用戶 1 管理員輸入用戶名、密

10、碼和確認密碼，請求添加 2 系統驗證用戶是否是新用戶，兩次輸入的密碼是否相同 3 系統添加用戶、密碼信息 4 系統提示添加成功刪除用戶 1 管理員輸入用戶名、密碼 2 系統驗證用戶名、密碼是否正確 3 系統刪除用戶名、密碼記錄 4 系統提示刪除成功修改密碼 1管理員輸入用戶名、密碼，請求修改密碼 2 系統驗證用戶名、密碼是否正確 3 管理員輸入新密碼、及確認密碼 4 系統保存新密碼 5 系統提示修改成功七 統計管理1 管理員輸入起始時間（年、月、日），結束時間,請求按日、月、年匯總2 系統查詢上網記錄，計算、統計出時間段的總費用、人次、總上機時間等信息。3 系統顯示上述信息八 參數管理 時段費

11、率設置： 0 系統顯示當前設置 1 管理員設置時間段（時、分）及對應的費率，請求保存 2 系統保存設置 3 系統提示保存成功 超時報警定時器間隔設置九 超時超費報警 1 設置定時器為周期觸發方式，觸發間隔由參數獲得，默認為30分鐘 2 定時器到時，系統查詢當前正在上機的記錄，計算其上機時間及費用，計算其卡中余額是否低于最低費用。 3 系統提示已超費卡號、機器號，及超的費用本系統除了功能性需求，還有易用性、可靠性、安全性等要求，可以在實現上述功能性需求的基礎上，進一步實現完善非功能性要求。友情提示：本文使用“用例”法分析功能性需求，屬于面向對象分析（ooa）法，其實質就是從用戶角度，通過觀察、與

12、用戶交談等方式，記錄下用戶希望如何使用系統，系統相應需要實現哪些功能。分析用戶需求一般由系統分析人員完成，其核心能力是熟練掌握業務領域的知識和溝通的技巧，需求分析的最大難點在于需求的可變性，最令開發人員氣餒的莫過于辛苦設計實現了一個功能，用戶突然說不需要這個功能了，另一個常見的問題是隱蔽性的需求（行業慣例、日常規則）常被用戶和分析人員忽略。不同的需求對于客戶而言重要性是不同的，一般需要對需求劃分優先級，優先級高的優先設計實現。你能否從上述一到九大用例描述中找出哪些用例是高優先級的？1.2.2 業務對象分析根據上面的主要用例描述，可以分析出系統的主要業務對象，它是設計階段核心類圖的基礎（不一定一

13、一對應），這些對象必須實際存在，其行為和屬性應與問題領域相關：1 上網卡： 主要維護上網卡的相關信息。卡號、密碼、余額、卡用戶名、卡狀態（在用、空閑、停用） 2 機器：主要維護上網吧計算機的相關信息。機器號、使用標志（在用、停用、空閑）、備注3 費用記錄：記錄每次上機的信息。記錄編號、卡號、機器號、開始上機時間，下機時間、費用 4 費率記錄：起始時間、終止時間，費率5 管理員： 利用14完成各種業務操作。1.2.3 驗收測試要求 用戶要求開發產品，產品開發完成后，需要交付用戶驗收，驗收要求常常是合同中的重要組成部分，這是一個必經的環節，主要思路是按照用戶使用的過程測試系統，越頻繁使用的功能越要

14、多測試。本系統功能性需求驗收測試的基本要求如下：前置條件：1 除口令表有初始用戶名和密碼外，各庫表為空。2 程序安裝配置正確，能正常啟動運行。一 初始化數據1 啟動程序，進入“卡維護”，選“發新卡”，輸入一條數據記錄，退出，進入“信息瀏覽”，查看記錄是否已被正確加入；退出“信息瀏覽”，再進入“發新卡”，連續發3張卡，其中有張卡余額為0；再進入“信息瀏覽”，查看記錄是否已被正確加入。2 同理按1 ，添加機器。3 進入“費率維護”，設置費率。二 功能測試1 上下機測試。進入“上機”，觀察上機界面，有無可用機器，按說明操作上機，連續上機3次，第一次正確輸入，第二次輸入不存在的卡號，第三次輸入錯誤口令

15、；進入“下機”界面，看有無正確的上機，連續下機兩次。觀察輸出信息界面，看內容是否正確（金額、卡號，時間，費用）。已下機器是否已被同步從上機下拉表中清除。再進入“上機”，比對可選空閑機器是否正確，輸入已上機用戶的卡號，觀察結果；輸入卡金額不足的卡號，觀察結果；不輸入任何值，直接按確認的結果。2 統計測試，進入“統計”功能，按日，月，年查詢統計，與庫中實際數據比對，不同日、月、年分別查2次3進入“卡維護”，進入“卡充值“，輸入余額不足卡號，給卡充值，進入“信息瀏覽”，查看卡充值是否正確，并以此卡號上機；再進入“卡維護”的“信息瀏覽”，查看記錄；然后選“刪除卡”，連續刪2張卡，應不能刪除在線卡，并能

16、標識出卡余額，以便清帳；進入“信息瀏覽”，查看記錄是否已被正確刪除。正在上機的不能被刪除。選“修改密碼”，輸入正確的用戶名、口令，修改成新口令；進入“信息瀏覽”，查看口令是否已更改；進入“上機”，以新口令上機。4 同3測試“機器維護”中的刪除機器功能，應不能刪除在線機器5 測試“費率維護”，退出程序，重啟動，進入“費率維護”，修改費率，上下機，觀察費用計算結果。6 測試超時報警功能：發一張新卡，初始額剛達到最低標準，以此卡上機，為縮短超時等待時間，可設置定時器間隔為1分鐘，等待2分鐘，看系統是否能正確報警。7 測試幫助功能。按照幫助說明使用系統，驗證幫助說明的正確性。友情提示：測試是保證程序質

17、量的基本手段，一般可分為單元測試、集成測試、系統測試、驗收測試，其中驗收測試一般由用戶在真實的運行環境下測試系統，是用戶確認系統符合要求的關鍵環節，你開發的系統必須通過上述最基本的驗收測試。并不是整個系統完成后才可以進行上述測試，完成相應模塊后就可以有針對性地測試，驗收測試的內容經過分解后是單元測試、集成測試、系統測試的基本依據，測試工作并不是從編碼時才開始的，在需求分析階段就已展開（如根據用例提出驗收測試要求）。有的it公司內部的質量部門在產品正式交付用戶前，也會做類似的測試，以保證用戶驗收時一次通過。1.3 系統設計1.3.1 總體設計一 系統體系結構一般要確定系統的體系結構，主要模塊，系

18、統運行環境（如操作系統、數據庫），開發平臺及語言。本系統主要運行在windows系列平臺上，數據庫使用access,使用eclipse開發系統。采用兩層c/s體系結構。系統體系結構圖如下圖所示：圖形界面swing業務邏輯數據訪問（jdbc）數據庫accesssql客戶端服務端 圖1 系統體系結構客戶端分3層，圖形界面層（采用java的swing設計）負責與用戶交互，業務邏輯層則根據用戶的請求執行各種功能(如上、下機等)，數據訪問層主要根據業務邏輯層的請求通過jdbc/sql存取數據庫。數據庫使用access，可根據情況使用其他數據庫（如sql server）,客戶端基本不做修改，僅有的少量修改

19、也只在數據訪問層。客戶端與服務端在物理上可以運行在一臺機器上，也可以分別運行在不同機器上。二 系統功能模塊及主要類系統的主要功能模塊如圖2所示：主模塊登錄上機下機幫助卡維護發卡充值查詢刪除卡機器維護添加機器刪除機器查詢口令維護添加用戶更改口令統計參數維護刪除用戶圖2 系統模塊圖可據此設計菜單，劃分模塊。系統主要類圖如下：圖 3總類圖的畫法基本遵循視圖層、業務邏輯層、數據模型及數據庫訪問層的自上而下的順序，其中視圖層中的視圖因為較多未畫出，主要的業務邏輯控制類是businessmanager，用戶的上下機請求，通過界面的事件機制，在事件處理程序中會調用businessmanager中的方法，然后

20、再調用xdao類方法，在xdao類中一般先通過dbconnection獲取連接，再通過jdbc/sql訪問數據庫。cardcomputerrecordmanager類是“值對象”，主要是存放相應的屬性，方法也是setxgetx類方法，“值對象”常作為參數在各種方法中傳遞。三 經驗共享1 客戶端基本采用三層結構（視圖view、控制controller、模型mode），層與層間耦合性較小，提高了整體的可擴展性、可重用及抗變動能力。缺點是要求預先設計好，對設計水平要求高，不過一旦形成模式，養成習慣，能“照葫蘆畫瓢”，也是提高設計水平的捷徑。2 使用xdao類將業務邏輯和數據庫訪問隔離，只要xdao對

21、上提供的接口不變，以后數據庫存取代碼發生改變也不會影響上層代碼（如業務邏輯層）。接口中的參數主要是“值對象”,這樣即使cardcomputerrecordmanager類中的屬性發生改變，由于“值對象”的封裝，對接口的影響也不大，缺點是如果“值對象”本身很大，而又只用到其中很少的屬性，則對性能和內存浪費較大。與此對應，比較一般的設計是在事件處理代碼中就實現業務邏輯（如驗證、計算、上下機）、獲取數據庫連接并通過jdbc訪問數據庫，這樣做的好處是實現較容易、符合一般過程性思維（常用于初始的或原型系統的開發中），缺點是代碼一旦需要修改，則改動較多、且容易出錯，代碼重用性差。3 使用dbconnect

22、ion類統一完成連接的獲取和釋放，好處是連接部分代碼可重復使用，如果連接參數（如連到不同的數據庫）改動，只需更改dbconnection類中的相關參數屬性（當然更好的做法是將這些連接參數放在配置文件中，這樣可以只修改配置文件，無需修改程序），另外還可以為了提高性能擴展成“連接池”，同時對使用它的xdao類沒有影響。友情提示：如果你不能理解上述描述，也不必擔心，按照你的直覺去開發系統，如果你一帆風順，那么你肯定是這方面的天才，如果遇到各種問題，上述的文字可供參考，同學之間可以互相交流，老師也樂意為你效勞，勤思、善問、實干是快速提高水平的不二法門。1.3.2 詳細設計 詳細設計主要是關注模塊一級的

23、設計，一般有界面，核心算法及處理流程，數據庫表（表、屬性及表間關系）的設計。由于模塊較多，下面選擇幾個典型模塊分析設計，其中“經驗共享”，揭示難點的同時，也介紹了相應的解決方法及設計經驗。 數據庫設計數據庫設計主要是根據分析和概要設計中發現的對象和類，確定哪些對象需要持久保存，然后將對象屬性及對象間關系轉化成關系表。經過分析card、computer、record、manger需要保存在數據庫中，將config參數配置信息保存在文件中。其中card、computer、record的關系如下圖所示：圖 持久對象屬性及關系圖一條record記錄必有對應的一個card及一臺comput

24、er，對于未用機器及卡，則沒有對應的記錄。將其轉換為關系表時，關鍵是在record中設置cardid,computerid作為外鍵指向card和computer。共設計出四張表：1.card 表 名稱編碼數據類型卡號id（主鍵）varchar（20）用戶名username（非空）varchar（20）密碼password（非空）varchar（15）卡狀態status（非空）integer余額balance（非空）double 2.computer 表名稱編碼數據類型機器號id（主鍵）varchar（10）狀態status（非空）integer備注notesvarchar（200）3.reco

25、rd 表名稱編碼數據類型記錄號id（主鍵）varchar（20）卡號cardid（非空）varchar（20）機器號computerid（非空）varchar（10）上機時間begintime（非空）date下機時間endtimedate上機費用feedouble 4. manager 表名稱編碼數據類型用戶名username（非空）varchar（20）口令password（非空）varchar（20）經驗共享：數據庫設計一般相對獨立，采用的主要方法是將對象模型轉化為數據庫關系模型，也可以采用傳統的設計出e-r圖，再定關系表的方法。即使是簡單數據庫的設計若從實用角度出發也需要考慮多方面的問題

26、。首先基本的是確定有哪幾張表，表間關系，然后是表中的字段，比較麻煩的是確定字段的約束（主鍵、非空等），字段數據類型，范式的調整等，因為此時會考慮到存儲空間、性能、易編程、數據質量等方面的因素。如定義“用戶名”字段要有多大，就需要在存儲空間節省和適應性間權衡，定義的較小，遇到長名字的情況，程序不能適應；定義的過大，對于大多數情況可能又會浪費存儲空間，一般寧愿定義的大些，以空間換取適應性。再比如確定哪些字段為“非空”，從編程角度看必須保證“非空”字段有值，這會增加驗證“非空”字段程序的代碼量，對用戶的約束也加強，有些值要求用戶必須輸入，如口令就不能為空。但若允許字段可以為“空”，如機器狀態字段，則

27、機器的當前狀態就可能難以確定，影響數據質量。一個基本的方向是“約束”多，則編程的代碼量會變大，性能會下降，但數據的質量會得到提高。在record表中“下機時間”和“上機費用”沒有定義為“非空”，是因為上機時這兩項不能確定，只能填寫部分上機記錄信息。一般數據庫表結構的變動對于程序的影響較大，在程序設計上可通過xdao類盡量消減變動的影響，在實現階段應避免對數據庫結構大的改動。 上機模塊設計一 界面設計 界面設計主要是根據功能要求構建界面，界面中的每個元素均應有其作用，以支持功能的實現，界面設計還要考慮到界面風格的一致、符合一般window應用gui的規范。設計應簡潔實用，避免在細節

28、上（如字體、顏色）耗費時間。上機模塊參考界面如圖4所示：圖4 參考界面二 上機流程 1 初始化 （1） 顯示界面 （2）獲取空閑機器 （3） 將空閑機器號加入下拉列表 2 上機處理過程： （1）驗證機器號、卡號、密碼是否為空 （2）根據卡號、密碼獲取卡對象（3） 若卡對象為空則說明卡號或密碼錯，給出提示“卡號或密碼錯”，要求重輸（4）判斷卡狀態，若卡正在使用則給出提示“不能一卡多用”（5）計算卡中余額，若低于設定值，則提示“余額不足”（6）修改卡狀態為在用，修改機器狀態為在用，獲取上機時間，將上機時間、機器號、卡號保存到記錄對象，再通過recorddao在庫中添加一條新上網記錄。（7）提示上網

29、成功三 經驗共享1 上機處理中的第6步要在一個完整的“事務”中完成，對卡、記錄、機器數據的更改添加要保證要么全部更改成功，要么都不更改，以保證數據的一致性。2 費用計算是按時段計算的，需要考慮跨時段費用如何計算，另外為了降低復雜性，可規定時段只能為三段，時間精確到分，費用精確到角。3 記錄id如何保證唯一且自動增長。基本有兩種：一是編程控制，插入新記錄前獲取當前最大記錄號,通過select max(id) from record，加1后，將id及其它信息寫入，若有多用戶訪問該表，則上述過程要放在一個“事務”中。二是利用關系數據庫提供的“自增字段”特性，將id設置成“自增字段”，由數據庫負責每添

30、加一條記錄就將id加1。 下機模塊設計一 界面設計 下機模塊主要根據用戶請求（報出卡號/機器號），管理員根據卡號/機器號執行下機操作，參考界面如圖5所示，大的文本空白文本框用于顯示下機記錄信息。當然還有其它的設計方式，如顯示當前上機的所有記錄信息，選中其中一條執行下機操作。 圖 5 下機模塊界面二 下機流程 1 管理員輸入機器號或卡號，請求下機 2 系統獲取機器號，據機器號獲取相應記錄對象，要處理機器號錯誤的情況 3 系統根據記錄對象獲取該記錄對應的卡對象 4 系統計算費用，并比較卡對象余額，若不夠則提示“余額不足”，并顯示余額5 系統從卡中扣費，修改卡狀態為“空閑”； 系統修改

31、該機器的狀態為“空閑”；系統更新記錄信息（下機時間、費用）。6 系統顯示本次上網完整的記錄（record）信息及卡余額，并提示下機成功 注： 下機處理4中修改三表的操作應作為一個“事務”完成。 發新卡模塊設計一 界面設計發卡需要輸入卡號、用戶名、密碼、金額，參考界面如下圖所示。界面設計布局應簡潔一致，從用戶友好性出發，提供了輸入提示，增加了“確認密碼”，以提醒用戶記住密碼，輸入的密碼用*號顯示以提高安全性。雖然有了提示但在代碼中仍需對輸入進行驗證，如金額不能為負值，以避免誤輸及惡意輸入。當然從口令強度考慮，要求密碼只輸入數字和字母又是不妥的，相反可提示用戶輸入特殊字符及輸入的最小

32、字符數。所以此界面雖簡單，但已涉及到界面的視覺風格、用戶友好性、安全性考慮。圖 發卡界面二 發卡流程 1 系統從界面獲取所有信息，依次判斷是否為空 2 判斷金額是否大于0 3 判斷密碼和確認密碼是否一致， 4 判斷密碼和用戶名是否在最小及最大長度之間 5 判斷卡號是否有效（唯一） 6 生成card對象，請求carddao向card表中添加一條新記錄。 7 提示卡添加成功，并顯示卡號和金額三 經驗共享1 輸入數據的驗證是難點，驗證輸入數據是保證程序可靠性的重要措施，例如：若不限制用戶或口令長度在相應數據庫表字段設定的范圍內，一旦將超長的用戶名寫入數據庫則會產生數據被截斷或數據庫異常，而這完全可以

33、在用戶輸入時予以控制。驗證輸入數據的難點之一在于在驗證的代碼量和限制大多數常見錯誤間取得平衡，過多地驗證代碼無疑會增加編碼量和難度，但沒有驗證或很少驗證又使程序可靠性太差而難以實用。但也有一些常規經驗可循，如是否限定字符數據的長度，驗證是否為空、數字數據是否在范圍內等，有些輸入控件提供了限定輸入長度等功能，應該充分利用以減少編碼量。一般驗證可遵循如下策略：輸入前提示如何輸入，輸入后驗證，驗證不通過則再提示（如通過對話框）。輸入驗證的時機：可以在輸入一項后立即驗證該項輸入是否合法，也可以全部輸完后再逐項驗證，某項若驗證不通過，除給出提示，從用戶友好性角度，還可以將焦點定位到出錯項（缺點是代碼復雜

34、性增加）。驗證通過后的數據在程序內部傳遞時，一般無需重復驗證。2 卡號的獲取。最基本的方式由管理員手工編號并保證卡號的唯一性，但卡一旦多了，這會成為管理員的負擔，因此，可以由系統自動編號，如規定卡號從1依次遞增編號，這樣卡號就無需輸入。可在每次增加新卡時，從卡表中獲取最大id，加1后作為新增卡的卡號。也可以獲取當前時間轉化成字符串作為id，一般時間不會重復，可保證id唯一，優點是生成id無需訪問數據庫，還可以代表發卡時間。 刪除卡模塊設計一 界面設計 刪除卡參考界面如下圖所示：圖 刪除卡界面二 刪除卡流程1管理員輸入卡號2 系統根據卡號，請求carddao查詢有無該卡3 若返回的

35、卡對象存在，則執行下一步，否則提示“卡號錯誤”，要求重輸。4 系統從card查詢卡狀態5 若為“在用”，則提示“不能刪除在用卡”6 查詢余額，若有則對話框提示“請結清余額”7 若余額已結清且狀態為“空閑”，則將該卡信息刪除8系統提示刪除成功三 經驗共享 1 如何刪除卡：一種是真刪，卡記錄信息從數據庫中永久刪除，采用delete from where 語句，此時還要注意，由于record中有指向card表的外鍵，刪除涉及到“級連刪除”這一概念，即在record中包含該卡號的記錄是否要一起刪除。一般不允許“級連刪除”，因為record中記錄是統計費用的基本依據，刪除后會使統計數據失真。還有一種是假

36、刪，即標注卡狀態信息為“停用”,只需用update語句更改其狀態即可，這樣做好處是：一是可以完整保留已發卡信息，二是易于重新恢復已刪卡。壞處是：若有大量卡（數以十萬計）長期不用，會占用數據庫空間，影響訪問卡表的性能。 2 一般數據庫中數據刪除后難以恢復，同時難以避免因為意外導致的數據損壞，因此重要數據的保存備份必不可少，本系統沒有要求做數據備份功能，因為數據庫管理工具一般會提供相應功能，只是要求用戶會使用數據庫管理工具，所以從方便用戶使用考慮，程序本身提供備份（手動或定期自動備份）功能也是必要的。1.4 系統實現系統實現主要運用集成開發環境、java、數據庫工具根據設計制做出實際的界面，編寫代

37、碼，生成數據庫表，進行測試，這也是初級程序員所要完成的主要任務，在此列出部分典型代碼，僅供參考。1.4.1 數據庫訪問對數據庫的基本操作是：增、刪、改、查，數據庫連接的建立、關閉，其中的難點是訪問數據庫的異常處理和參數化sql，現舉例如下：1 獲取連接的代碼：private static final string driver_class = sun.jdbc.odbc.jdbcodbcdriver; /定義驅動類 private static final string datasource = jdbc:odbc:netbardatasource; /定義odbc數據源 public sta

38、tic connection getconnction() connection dbconnection = null; try class.forname(driver_class); dbconnection = drivermanager.getconnection(datasource); catch (exception e) e.printstacktrace(); return dbconnection; 該代碼針對jdbcodbcdriver驅動，odbc源名為netbardatasource，未支持口令驗證。 2 查詢代碼： 下面是根據用戶名和口令驗證卡是否有效的代碼，需要

39、注意的是查詢參數值需要加單引號：/* * judge card is valid or not. * param card card * return boolean */ public boolean isvalid( card card) boolean isvalid = false; connection dbconnection = null; preparedstatement pstatement = null; resultset res = null; try dbconnection = connectionmanager.getconnction(); / 構建查詢sql

40、語句 string strsql = select * from card where id= + card.getid() + and password = + card.getpassword() + ; if (dbconnection != null) system.out.println(dbconnection != null); /查詢操作 pstatement = dbconnection.preparestatement(strsql); res = pstatement.executequery();/執行sql語句，并返回結果 if (res.next() /若res有記

41、錄說明卡存在 isvalid = true; catch (sqlexception sqle) sqle.printstacktrace(); finally connectionmanager.closeresultset(res);/關閉結果集 connectionmanager.closestatement(pstatement); connectionmanager.closeconnection(dbconnection); /關閉連接 return isvalid; 3 更新代碼下面是更新機器狀態的代碼，其中sql語句中，“id =(?)”是動態參數，具體值設置在pstateme

42、nt.setstring(1, computer.getid()/* * record the computer have used. * param computer computer */ public void updateonuse( computer computer) connection dbconnection = null; preparedstatement pstatement = null; try string strsql = update computer set status =1 where id =(?) ; ; pstatement = dbconnect

43、ion.preparestatement(strsql); pstatement.setstring(1, computer.getid(); /設置機器號id參數 pstatement.executeupdate(); catch (sqlexception sqle) sqle.printstacktrace(); finally connectionmanager.closestatement(pstatement); connectionmanager.closeconnection(dbconnection); 1.4.2 下機模塊 在businessmanager類中有一doche

44、ckout（）方法是實現下機過程的關鍵。/* * do check out business. * param rec record，已有機器號值 * return comsumedisplayinfo含有上機記錄、對應卡記錄 */ public static comsumedisplayinfo docheckout( record rec) recorddao dao = new recorddao();/獲取包含了下機記錄及對應卡信息的comsumedisplayinfo comsumedisplayinfo result = dao.getstopcompouterrelationin

45、fo(rec); record record = result.getrecord(); card card = result.getcard(); /計算本次上機的費用 int fee = calfee(record.getbegintime(), record.getendtime(); record.setfee(fee); /計算余額 int balance = card.getbalance() - fee; card.setid(record.getcardid(); card.setbalance(balance);/將數據寫入數據庫 recorddao dao2 = new r

46、ecorddao(); dao2.docheckoutdb(record, card);/返回含有上機記錄、card記錄的comsumedisplayinfo，供界面顯示下機結果 result.setrecord(record); result.setcard(card); return result; 1.4.3 上機模塊 處理請求上機的部分代碼如下，主要有界面數據（機器號、密碼、卡用戶號）驗證代碼；卡有效性、余額可用性驗證。/* * deal business about click confirm button. * param e actionevent */ void confirm

47、button_actionperformed(actionevent e) string cardid=; string passwordtemp = ;string computerid =;/獲取機器號，并去掉空格cardid = cardidtextfield.gettext().trim();/獲取密碼 for(int i=0;ipasswordfiled.getpassword().length;i+) passwordtemp += passwordfiled.getpassword()i;/獲取機器號 computerid = computeridcombox.getselect

48、editem().tostring();/判斷機器號是否為空，未填或只有空格 if(computerid=null | computerid.trim().length()=0) joptionpane.showmessagedialog(this,請選擇機器號!,警告, joptionpane.warning_message ,null ); return ;/判斷卡號是否為空，未填或只有空格 if(cardid=null | cardid.length()=0) joptionpane.showmessagedialog(this,請輸入卡號!,警告, joptionpane.warnin

49、g_message ,null ); return ; if(passwordtemp=null | passwordtemp.length()=0) joptionpane.showmessagedialog(this,請輸入密碼!,警告, joptionpane.warning_message ,null ); return ;/生成卡對象，并設置卡用戶名、口令、上機時間card card = new card(); card.setid(cardid); card.setpassword(passwordtemp); record record = new record(); recor

50、d.setcardid(cardid); record.setcomputerid(computerid); record.setbegintime(dispalynowtime);/生成機器對象，更新機器狀態時用 computer computer = new computer(); computer.setid(computerid);/驗證卡是否有效、余額是否夠，符合要求后調docheckin實際處理上機業務 if(businessmanager.cardisvalid(card) if(businessmanager.cardhavebalance(card) businessmana

51、ger.docheckin(record,computer); else joptionpane.showmessagedialog(this,卡余額不足，請充值!,警告, joptionpane.warning_message ,null ); return ; else joptionpane.showmessagedialog(this,卡號或者密碼不對!,警告, joptionpane.warning_message ,null ); system.out.println(卡號或者密碼不對); return; 1.4.4 幫助模塊在實現幫助功能時，編碼上沒有難點，基本上是一個簡單的帶滾

52、動條的只讀文本瀏覽器，難在幫助文件的內容如何寫？幫助文件是指導用戶如何操作系統的，內容應正確，語言應對客戶簡明易懂，最好輔以圖形說明。做到這兩點并不容易，內容正確要求寫幫助的人對系統的功能非常熟悉，簡明易懂則充分體現出作者的文字功底。建議參考類似“記事本”（winodws主菜單-所有程序-附件-記事本）這樣的程序，看它們的幫助是如何寫的。友情提示：客戶會根據幫助說明來使用系統，系統功能正確，但因為幫助說明錯誤導致的問題甚至官司比比皆是，所以在通過基本的驗收測試后，老師會按照你寫的幫助來使用系統，進而測試幫助文檔的正確性。1.5 小結 經過日夜奮戰，終于做出了系統，通過了驗收和答辯，雖然有點難熬，但終于熬過來了，是不是可以松一口氣或是慶祝一下？請不要忘記老師對你的期待，期待你的改變和收獲，做一件事情和沒做這件事情結果都一樣將是我們共同的失敗，請寫下你所做的工作，發現了哪些問題？如何解決的？有哪些經驗和教訓？不應局限于技術，只要是與項目相關的屬于自己的思考和想法都可以寫下來，請