【正文】 性驗證。 (card)。 (record, card)。 (balance)。 //計算余額 int balance = () fee。 //計算本次上機的 費用 int fee = calFee((), ())。 Record record = ()。 /** * do check out business. * param rec Record，已有機器號 值 * return ComsumeDisplayInfo 含有上機記錄、對應(yīng)卡記錄 */ public static ComsumeDisplayInfo doCheckOut( Record rec) { RecordDAO dao = new RecordDAO()。 (dbConnection)。 } catch (SQLException sqlE) { ()。 (1, ())。 。 PreparedStatement pStatement = null。 //關(guān)閉連接 } return isValid。//關(guān)閉結(jié)果集 (pStatement)。 } } catch (SQLException sqlE) { ()。 res = ()。 if (dbConnection != null) { (dbConnection != null)。 and password =39。 // 構(gòu)建 查詢 SQL 語句 String strSql = select * from card where id=39。 ResultSet res = null。 Connection dbConnection = null。 } 該代碼針對 JdbcOdbcDriver 驅(qū)動， ODBC 源名為 NetBarDataSource，未支 持口 令驗證。 } catch (Exception e) { ()。 try { (DRIVER_CLASS)。 //定義驅(qū)動類 private static final String DATASOURCE = jdbc:odbc:NetBarDataSource。 系統(tǒng)實現(xiàn) 系統(tǒng)實現(xiàn)主要運用集成開發(fā)環(huán)境 、 Java、數(shù)據(jù)庫工具 根據(jù)設(shè)計 制做出實際的界面，編寫代碼，生成數(shù)據(jù)庫 表 ， 進(jìn)行測試， 這 也是初級程序員所要完成的主要任務(wù)， 在此列出部分典型代碼， 僅 供參考。壞處是：若有大量卡（數(shù)以十萬計）長期不用，會占用數(shù)據(jù)庫空間，影響訪問卡表的性能。一般不允許“級連刪除”，因為 Record 中記錄是統(tǒng)計費用的基本依據(jù)，刪除后會使統(tǒng)計數(shù)據(jù)失真。 刪除卡模塊 設(shè)計 一 界面設(shè)計 刪除卡 參考 界面如下圖所示 ： 圖 刪除卡界面 二 刪除卡 流程 1管理員輸入卡號 2 系統(tǒng)根據(jù)卡號，請求 CardDAO 查詢有無該卡 3 若 返回的卡對象存在，則執(zhí)行下一步，否則提示“卡號錯誤”，要求重輸?？稍诿看卧黾有驴〞r，從卡表中獲取最大ID，加 1 后作為新增卡的卡號。 2 卡號的獲取。輸入驗證的時機：可以在輸入一項后立即驗證該項輸入是否合法，也可以全部輸完后再逐項驗證，某項 若 驗證不通過，除給出提示，從用戶友好性角度，還可以將焦點定位到出錯項（缺點是代碼復(fù)雜性增加）。 但也 有一些常規(guī)經(jīng)驗可循 ，如 是否限定 字符數(shù)據(jù)的長度， 驗證 是否為空、數(shù)字?jǐn)?shù)據(jù)是否 在 范圍 內(nèi) 等， 有些輸入控件提供了限定輸入長度等功能，應(yīng)該充分利用以減少編碼量。 7 提示卡添加成功，并顯示卡號和金額 三 經(jīng)驗共享 1 輸入數(shù)據(jù)的驗證是難點， 驗證輸入數(shù)據(jù)是保證程序可靠性的重要措施，例如：若不限制用戶或口令長度在相應(yīng)數(shù)據(jù)庫表字段設(shè)定的范圍內(nèi)，一旦將超長的用戶名寫入數(shù)據(jù)庫則會產(chǎn)生 數(shù)據(jù)被截斷或 數(shù)據(jù)庫異常，而這完全可以在用戶輸入時予以控制。所以此界面雖簡單，但已涉及到界面的視覺風(fēng)格、用戶友好性、安全性考慮。雖然有了提示但在代碼中仍需對輸入進(jìn)行驗證，如金額不能為負(fù)值，以避免誤輸及惡意輸入。 發(fā)新卡模塊 設(shè)計 一 界面設(shè)計 發(fā)卡需要輸入卡號、用戶名、密碼、金額，參考界面如下圖所示。 圖 5 下機模塊界面 二 下 機流程 1 管理員 輸入機器號 或卡號 ，請求下機 2 系統(tǒng)獲取機器號， 據(jù)機器號獲取相應(yīng)記錄對象 ，要處理機器號錯誤的情況 3 系統(tǒng)根據(jù)記錄對象獲取該記錄對應(yīng)的卡對象 4 系統(tǒng) 計算費用 ，并比較 卡對象 余額，若不 夠則提示“余額不足” ， 并顯示余額 5 系統(tǒng) 從卡中扣費， 修改卡狀態(tài)為“空閑” ； 系統(tǒng) 修改該機器的狀態(tài)為 “空閑” ；系統(tǒng) 更新 記錄信息 （下機時間、費用）。 下機模塊設(shè)計 一 界面設(shè)計 下機模塊主要根 據(jù)用戶請求（報出卡號 /機器號），管理員根據(jù)卡號 /機器號執(zhí)行下機操作，參考界面如圖 5所示， 大的文本空白文本框用于顯示下機記錄信息?；居袃煞N：一是編程控制， 插入新記錄前 獲取當(dāng)前最大記錄號 ,通過 select max(id) from record， 加 1 后，將 ID 及其它信息寫入，若有多用戶訪問該表，則上述過程要放在一個“事務(wù)”中。 2 費用計算是按時段計算的 ，需要考慮跨時段費用如何計算，另外為了降低復(fù)雜性，可規(guī)定時段只能為三段，時間精確到分，費用精確到角。 上機模塊 參考界面 如圖 4 所示： 圖 4 參考界面 二 上機流程 1 初始化 （ 1） 顯示界面 （ 2） 獲取空閑機器 （ 3） 將空閑機器 號 加入下拉列表 2 上機處理過程： （ 1）驗證機器號、卡號、密碼是否為空 （ 2）根據(jù)卡號、密碼 獲取 卡對象 （ 3） 若卡對象為空則說明卡 號或密碼錯，給出提示 “卡號或密碼錯” ，要求重輸 （ 4）判斷卡狀態(tài)，若卡正在使用則給出提示 “ 不能一卡多用 ” （ 5）計算卡中余額， 若低于設(shè)定值，則提示“余額不足” （ 6） 修改卡狀態(tài)為在用，修改機器狀態(tài)為在用，獲取上機時間，將上機時間、機器號、卡號保存到記錄對象 ，再通過 RecordDAO 在庫中添加一條新上網(wǎng)記錄。 上機模塊設(shè)計 一 界面設(shè)計 界面設(shè)計 主要是根據(jù)功能要求構(gòu)建界面，界面中的每個元素均應(yīng)有其作用，以支持功能的實現(xiàn)，界面設(shè)計還要考慮到界面風(fēng)格的一致、符合一般 window 應(yīng)用 GUI 的規(guī)范。 在 Record表中“ 下機時間 ”和“ 上機費用 ”沒有定義為 “非空”，是因為上機時這兩項不能確定，只能填寫部分上機記錄信息。 但若 允許 字段可以為“空”，如 機器 狀態(tài)字段，則 機器 的當(dāng)前狀態(tài)就 可能 難以確定，影響數(shù)據(jù)質(zhì)量。 如定義 “ 用戶名 ” 字段要有多大， 就需要在存儲空間節(jié)省和適應(yīng)性間權(quán)衡，定義的較小，遇到長名字的情況，程序不能適應(yīng)；定義的過大，對于大多數(shù)情況可能又會浪費存儲空間 ，一般寧愿定義的大些，以空間換取適應(yīng)性。 即使是簡單數(shù)據(jù)庫的設(shè)計若從實用角度 出發(fā) 也需要考慮多方面的問題。將其轉(zhuǎn)換為關(guān)系表時，關(guān)鍵是在 Record 中設(shè)置CARDID,COMPUTERID 作為外鍵指向 Card 和 Computer。經(jīng)過分析 Card、Computer、 Record、 Manger 需要保存在數(shù)據(jù)庫中，將 Config 參數(shù)配置信息保存在文件中。由于模塊較多，下面選擇幾個典型模塊分析設(shè)計，其中“ 經(jīng)驗共享 ”，揭示難點的同時，也介紹了相應(yīng)的解決方法及設(shè)計經(jīng)驗。 友情提示： 如果你不能理解上述描述，也不必?fù)?dān)心，按照你的直覺去開發(fā)系統(tǒng)，如果你一帆風(fēng)順，那么你肯定是這方面的天才，如果遇到各種問題，上述的文字可供參考， 同學(xué)之間可以互相交流，老師也樂意為你效勞， 勤思、善問、實干是快速提高水平的不二法門。 與此對應(yīng)，比較一般的設(shè)計是 在事件處理代碼中就實現(xiàn)業(yè)務(wù)邏輯（如驗證、計算、上下機）、 獲取數(shù)據(jù)庫連接并通過 JDBC 訪問數(shù)據(jù)庫，這樣做的好處是實現(xiàn)較容易、符合一般過程性思維 （常用于初始的或原型系統(tǒng)的開發(fā)中） ，缺點是 代碼一旦需要修改，則改動較多、且容易出錯，代碼重用性差。 2 使用 xDAO 類將業(yè)務(wù)邏輯和數(shù)據(jù)庫訪問隔離，只要 xDAO 對上提供的接口不變，以后數(shù)據(jù)庫存取代碼發(fā)生改變也不會影響 上層代碼（如 業(yè)務(wù)邏輯層 ） 。 三 經(jīng)驗共 享 1 客戶端 基本采用三層結(jié)構(gòu) （視圖 View、控制 Controller、模型 Mode） ， 層與層間耦合性較小，提高了整體的可擴展性、 可重用及 抗變動能力。 系統(tǒng)主要類 圖 如下： 圖 3 總 類圖 的畫法 基本遵循視圖層、業(yè)務(wù)邏輯層、數(shù)據(jù)模型及數(shù) 據(jù)庫訪問層 的自上而下的順序 ， 其中視圖層中的視圖 因為較多 未畫出，主要的業(yè)務(wù)邏輯控制類是BusinessManager，用戶的上下機請求，通過界面的事件機制，在事件處理程序中會調(diào)用 BusinessManager 中的方法，然后再調(diào)用 xDAO 類方法，在 xDAO 類中一般先通過 DBConnection 獲 取 連 接 ， 再通 過 JDBC/SQL 訪 問 數(shù) 據(jù)庫 。 客戶端與服務(wù)端在物理上可以運行在一臺機器上，也可以分別運行在不同機器上。 系統(tǒng)體系結(jié)構(gòu)圖如下圖所示： 圖 1 系統(tǒng)體系結(jié)構(gòu) 客戶端 分 3層，圖形界面層 （采用 java 的 SWING 設(shè)計 ） 負(fù)責(zé)與用戶交互，業(yè)務(wù)邏輯層則根據(jù)用戶的請求執(zhí)行各種功能 (如上、下機等 )， 數(shù)據(jù)訪問層主要 根據(jù)業(yè)務(wù)邏輯層的請求 通過 JDBC/SQL 存取數(shù)據(jù)庫。本系統(tǒng)主要運行在 windows 系列平臺 上 ，數(shù)據(jù)庫使用ACCESS,使用 eclipse 開發(fā)系統(tǒng)。 有的 IT公司內(nèi)部的質(zhì)量部門在產(chǎn)品正式交付用戶前，也會做類似的測試，以保證用戶驗收時一次通過。 友情提示： 測試是保證程序質(zhì)量的基本手段， 一般可分為單元測試、集成測試、系統(tǒng)測試、驗收 測試，其中驗收測試一般由用戶在真實的運行環(huán)境下測試系統(tǒng)，是用戶確認(rèn)系統(tǒng)符合要求的關(guān)鍵環(huán)節(jié) ， 你開發(fā)的系統(tǒng)必須通過 上述最基本的驗收測試 。 7 測試幫助功能。 4 同 3測試“機器維護”中的刪除機器功能，應(yīng)不能刪除在線機器 5 測試“費率維護”，退出程序，重啟動，進(jìn)入“費率維護”，修改費率，上下機，觀察費用計算結(jié)果。正在上機的不能被刪除。再進(jìn)入“上機”，比對可選空閑機器是否正確，輸入已上機用戶的卡號，觀察結(jié)果；輸入卡金額不足的卡號，觀 察結(jié)果；不輸入任何值，直接按確認(rèn)的結(jié)果。觀察輸出信息界面，看內(nèi)容是否正確（金額、卡號，時間，費用）。 二 功能測試 1 上下機測試。 2 同理按 1 ，添加機器。 2 程序安裝配置正確，能正常啟動運行 。 驗收測試要求 用戶 要求開 發(fā)產(chǎn)品，產(chǎn)品開發(fā)完成后，需要交付用戶驗收， 驗收要求常常是合同中的重要組成部分， 這是一個必經(jīng)的環(huán)節(jié)， 主要思路是按照用戶使用的過程測試系統(tǒng)，越頻繁使用的功能越要多測試。 機器號、使用標(biāo)志 （在用、停用、空閑） 、備注 3 費用記錄： 記錄每次上機的信息。 你能否從上述一到九大用例描述中 找出哪些用例是高優(yōu)先級的？ 業(yè)務(wù)對象分析 根據(jù)上面的主要用例描述， 可以分析出系統(tǒng)的主要業(yè)務(wù)對象 ，它是設(shè)計階段核心類圖的基礎(chǔ) （不一定一一對應(yīng)） ，這些對象必須 實際 存在 ，其行為和屬性應(yīng)與問題領(lǐng)域相關(guān) ： 1 上網(wǎng) 卡： 主要維護上網(wǎng)卡的相關(guān)信息。 分析用戶需求 一般由系統(tǒng)分析人員完成，其核心能力是熟練掌握業(yè)務(wù)領(lǐng)域的知識和溝通的技巧， 需求分析的最大難點在于需求的可變性，最令開發(fā)人員氣餒的莫過于辛苦設(shè)計實現(xiàn)了一個功能，用戶突然說不需要這個功能了， 另一個常見的問題是 隱蔽性的需求 （行業(yè)慣例、日常規(guī)則）常被用戶和分析人員忽略 。 3 系統(tǒng)提示已超費卡號、機器號， 及 超的費用 本 系統(tǒng)除了功能性需求，還有易用性、 可靠性 、安全性等要求， 可以在實現(xiàn)上述功能性需求的基礎(chǔ)上，進(jìn)一步 實現(xiàn)完善非功能性要求 。 添加機器： 1 管理員輸入機器號，請求添加 2 系統(tǒng)驗證機器號是否重復(fù) 3 系統(tǒng)添加機器記錄信息（機器號、狀態(tài)為“空閑”） 4 系統(tǒng)提示添加成功 刪除機器： 1 管理員輸入機器號，請求刪除 2 系統(tǒng)刪除相應(yīng)機器信息 3 系統(tǒng)提示刪除成功 查詢機器狀態(tài)： 1 管理員輸入機器號或請求察看所有機器信息 2 系統(tǒng)查詢并顯示機器信息（ 機器號 和 狀態(tài)