畢業論文-基于android的手機斗地主游戲的設計與實現(編輯修改稿)

　

【文章內容簡介】 1,(colors)1,1。所以此時，當前出牌玩家出的牌，只要是合法的牌型，就可打合法地打出去。 玩家操作 功能 操作 判斷機制 switch()case 中， case 共分 0:登錄 1:退出 2:開牌 3:叫牌 4:出牌 5:pass 6:計分六種情況。在此以最重要使用、最頻繁的“ case 4:出牌”來講述這個 功能。 首先，判斷處理結果是否表明前面出牌是否非法，如果是，將給機會客戶端重新出牌。否則，判斷，信息是否是發給發出前面動作的本人。是，則將合法牌顯示在 UI 上，并更新手上的牌。否則， 只顯示別人打出來的牌，及其所剩牌數目。 然后，當前面動作者是接收方的直接上家（或邏輯上家）時，接收方獲得出牌權。否則，沒有出牌權。 詳細規則請參看附錄 1 客店端對出牌的顯示控制 。 顯示信息功能 存儲玩家手上的牌。 然后實現排序的問題和合法牌打出以及非法牌回收的問題。 排序效果如圖 : 圖 玩家收到的牌 及其三種排序 (按花色 ,大小 ,牌型 ) 排序算法如下 : 先將用戶手上的牌 card20 copy 到 cardHit 中去 . 畢業設計 13 然后 ,按其數據成員 color(桃 心 梅 方 ),value(大 小 ),num(多 少 )設置為不同級別的關鍵字 . (1)按花色排序 : 主關鍵字 color,次關鍵字 value (2)按大小排序 : 主關鍵字 value,次關鍵字 color (3)按牌型排序 : 主關鍵字 num,次關鍵字 value,color 前兩種排序只是處理調用 sortOnValue()與 sortOnColor()的先后關系 .而按 b排序稍復雜一點 ,先按大小排序 ,再從 右 邊開始查找 .先找只有 2個牌相同的 ,找到就往最左邊放 .然后依同理查找只有 3 個牌相同的和只有 4 個牌相同的 ,再就是查找火箭 .最后剩下單牌就留在最后邊 . 玩家通過點擊 flash UI 上面的牌， flash UI 把各個被選中的牌的 position 傳遞至這個參數，并被存儲起來。 當玩家用鼠標點擊某個牌時 ,該牌會彈出來 ,高出其他兄弟牌半截 ,此時 ,它在牌組 cardHit 中的位 置 position 已經被取出并存入 中 ,等待發送至服務器端 .當用戶選完想出的牌 ,點擊手形圖標后 ,就同時 觸發方法 void (), 就 隨之 被發送到服務器端了 。服務器的處理方式請參看 合法性判斷功能 玩家出如果經服務器判斷合法，將被接受并存儲在這個參數里。 客戶端將合法的牌全部顯示在界面中央 ,并在動作者的手上將相應的牌清除掉 (使相應 牌的 exist=1)。如下圖： 我們可以看到，動作者手上的梅花 3 補打出去了，由于這是地主的第一次出牌，服務器判定其合法，客戶端收到判斷結果后，將牌打出去在界面的中央位置顯示，而在自己手上，清除掉 該 “梅花 3”。 畢業設計 14 圖 選中一張牌并正常打出去 如果不合法 ,系統將不打出去 ,并給出錯誤提示 .并且，將不合法的牌還原到動作者手中，讓動作者重新選擇：出牌 OR PASS。原理其實與上面的大同小異，就不必贅述了。 如圖 : 非法出牌報錯 畢業設計 15 游戲退出功能 CdisplayDlg::OnExit()退出游戲 調用系統方法關閉窗口 、 關閉對話框。 畢業設計 16 第 6 章 系統測試與維護 在軟件程序編碼完成之后 ， 在軟件投入使用之前要進行軟件測試 。 何謂軟件測試 ,簡言之 ： 軟件測試是為了發現錯誤而執行程序的過程 。 也就是根據軟件開發各階段的規格說明何程序的內部結構而精心設計測試用例 ， 用這些用例去運行程序以發現程序錯 誤 的過程 。 系統測試在一個系統的周期中占有越來越重要的位置了。在系統正式投入運行的轉換工作之前，還需對系統進行一系列的調試即測試。系統調試的任務是根據系統說明書和系統實施 方案，對程序設計的結果進行全面的檢查，找出并糾正其中的錯誤，使可能發生的問題和錯誤，盡量消滅在系統正式運行之前。 6. 1 系統測試的原則 ? 應當盡早和不斷的進行軟件測試 . ? 測試用例應由測試輸入數據和預期輸出結果兩部分組成 .(注意 :測試用例包含輸入和輸出兩部分 ). ? 測試用例應包括合理的輸入條件和不合理的輸入條件 .前者即使程序正常運行的條件 ,后者即可能引起程序非法操作的條件 . ? 程序員應避免檢查自己的程序 .因為父母總是疼愛自己的孩子 .程序員總是在潛意識不愿意否定自己的勞動成果 . ? 注意測試中的群集現象 .測試后程序 中殘存的錯誤數目與該程序中已發現的錯誤數目成正比 .所以 ,不要在某個程序段中找到幾個錯誤就誤認為該程序段就沒有錯誤而不再測試 ,相反該程序段更要集中精力測試 。 ? 測試應該制訂計劃 ,嚴格按計劃進行測試 ,避免測試的隨意性 . ? 應對每一個測試結果做全面檢查 . 有時出錯的征兆已經在測試結果中出現了 ,但由于沒有對測試結果進行仔細檢查 ,而使這個錯誤成了漏網之魚 . ? 應妥善保存測試計劃 ,用例 ,錯誤記錄和分析報告 . 6. 2 測試過程及方法 軟件的測試過程有四個步驟 :單元測試 ,集成測試 ,確認測試和系統測試 . 單元測試即對每一個單元 模塊進行測試 .然后把測試過的模塊組裝起來進行集成測試 ,主要是對軟件體系結構的構造進行測試 .接著進行確認測試 ,檢查軟件畢業設計 17 是否滿足了各種需求 ,以及配置是否合理安全 .最后是系統測試 ,即把經確認測試后的軟件放到實際運行環境中 ,與系統的其他構件一起進行測試 . 單元測試時 ,有時需要為測試的模塊編寫輔助模塊 :驅動模塊和樁模塊 .前者是用來調用被測模塊 。后者用來代替被測模塊調用的子模塊。 集成測試 ,又叫組裝測試 ,分為兩種 :一次性組裝和增殖式組裝 .一次性組裝方式即把經單元測試后的模塊一次性的組裝成系統進行測試 .增殖式組裝方式即在 模塊組裝的過程中 ,邊組裝邊測試 ,每增加一個或幾個模塊就測試一次 ,最后組裝成最后的系統 ,它又分為 :自頂向下的增殖 ,自底向上的增殖 ,混合增殖等幾種方式 . 確認測試過程要做的工作包括 :有效性測試 ,軟件配置復審 ,驗收測試和安裝測試 .在驗收測試中常用的有 α 測試和 β 測試 .α 測試時 ,開發者坐在用戶旁邊 ,隨時記錄用戶發現的問題 .β 測試則開發者不在測試現場 ,故是在開發者無法控制的環境下進行的測試 ,通常是由軟件開發者向用戶散發 β 版軟件 ,然后收集用戶的意見 . 測試的方法大體可以分為兩種 :黑盒測試和白盒測試 . 黑盒測試即把測試的對 象看成一個黑盒子 ,不考慮程序內部的邏輯結構和內部特性 ,主要在軟件的接口處進行測試 ,主要測試軟件的功能 .黑盒測試的方法包括 :等價類劃分法 ,邊界值分析 ,錯誤推測法 ,因果圖 ,功能圖等 . 白盒測試把測試對象看成是一個打開的盒子 ,程序內部的邏輯結構和其他信息對測試人員都是公開的 .白盒測試的方法有 :邏輯覆蓋 (語句覆蓋 ,判定覆蓋 ,判定 條件覆蓋 ,條件組合覆蓋 ,路徑覆蓋 ),基本路徑測試等 . 6. 3 測試環境 測試的硬件環境為：主機為英特爾賽揚 M處理器 360 ，硬盤為 40G，內存容量 256M。 測試的軟件環 境是： 用戶界面用 Android 模擬器 進行測試 ， 邏輯控制用 單元測試工具 JUnit進行測試 。 最后，在 Android 模擬器上進行集成測試 。 畢業設計 18 6. 4 測試中的 BUG 及問題總結 測試的過程中，我首先進行了代碼走查。對自己編寫過的代碼進行了全面的檢查，發現不僅有很多設計不合理的地方，還有很多潛在的錯誤。比如，在定義類的對象的類型時，為了方便，都定義為 Public，這對這些都對系統以后的運行造成錯誤和危險。對于及時發現的問題，我都進行了改正。 接著是白盒測試，我對各個模塊又小到大，有單個到集成進行了測試，發現在模塊 間的銜接上總會出現些小問題。但經耐心檢查定位，一個個找到了錯誤的原因，排除了錯誤。 最后進行的是黑盒測試，由于之前的調試修改為這次測試做了鋪墊，在黑盒測試中，并沒有發現很大的問題。最后，對照需求規格說明書，對軟件的功能實現是否符合要求進行了檢查，均已達到要求。 在進行了修改與整理后，最后的驗收測試進行的很順利，程序驗收合格。 6. 5 軟件的維護 軟件維護的原因可分為 4 類 :改正性維護 ,適應性維護 ,完善性維護和預防性維護 . ? 改正性維護 :在軟件投入運行后 ,可能會暴露一部分在測試階段沒有發現的錯誤 ,為改正這些 錯誤而對軟件進行的修改就是改正性維護。 ? 適應性維護 :由于軟件運行的外部環境 (軟件 ,硬件 )和數據環境等的變化而修改軟件使之適應這些變化 ,就是適應性維護 .例如 :原先在 DOS 下開發的軟件，現在要使之適用于 windows而進行的修改。 ? 完善性維護：用戶的需求是經常變化的，在軟件使用過程中，用戶會對軟件提出新的功能和性能要求，為了滿足這些新的要求而對軟件進行修改，使之功能和性能得到完善． ? 預防性維護：就是采用先進的軟件工程方法對需要維護的軟件或某部分軟件重新進行設計，編碼和測試，以提高軟件的可維護性和可靠性等，為以后 進一步改進軟件打下基礎．例如：有個軟件原先是用結構化的思想編寫的，現在為了提高軟件的質量而用面向對象的方法重新設計和編寫軟件。 畢業設計 19 軟件的可維護性就是指軟件維護的難易程度．要做到軟件的可維護性要注意以下幾點：建立明確的軟件質量目標和優先級；使用提高軟件質量的技術和工具，如：面向對象技術，軟件體系結構思想等；進行明確的質量保證審查；選擇可維護的程序設計語言；做好程序的文檔等等． 畢業設計 20 附錄 A 部分 源程序清單 1 客戶端程序清單 圖 A1 客戶端程序清單 部分代碼： // Cs serialization void Cs::Serialize(CArchiveamp。 ar) { ncolor=。 if (()) { armessagencolorm_nBroadcastArrivedbeginfirstInfoAboutm_strplayerIDm_strNamem_strPasswordm_strSucessm_norder_seatsm_nintegralm_nsparecardsm_nescapem_nIsReadym_ncandpointm_n畢業設計 21 Pointm_nPassm_strpcardsm_strposm_strselectcardsm_stroutcardsm_nclose_lippedm_nfirstcandm_nmytimem_nvictorym_nlandownerpass_timesm_nlegalInfom_strfrontmul_point。 // TODO: add storing code here } else { armessagencolorm_nBroadcastArrivedbeginfirstInfoAboutm_strplayerIDm_strNamem_strPasswordm_strSucessm_norder_seatsm_nintegralm_nsparecardsm_nescapem_nIsReadym_ncandpointm_nPointm_nPassm_strpcardsm_strposm_strselectcardsm_stroutcardsm_nclose_lippedm_nfirstcandm_nmytimem_nvictorym_nlandownerpass_timesm_nlegalInfom_strfrontmul_point。 // TODO: add loading code here } } 圖 A2 displayflashDlg 成員 畢業設計 22 void CdisplayflashDlg::Connect() { // TODO: Add your control notification handler code here m_pSocket2=new CClientUseSocket2(this)。 if(!ConnectServer(m_pSocket2)) { m_pSocket2=NULL。 delete m_pSocket2。 } Sleep(1000)。 SendGetCardMessage()。 } void CdisplayflashDlg::OnReceive(CClientUseSocket2 *pClientSocket) { static Cs msg。 pClientSocketReceiveMassage(amp。msg)。 if(m_norder_seats==)//如果消息是發給 ‘我’的 { switch() //0:登錄 1:退出 2:開 牌 3:叫牌 4:出牌 5:pass 6:計 分 { //不同的 case 做不同的動作 ,詳細請看磁盤 } }//if 畢業設計 23 }// OnReceive 2 服務器端程序清單 圖 A3 服務器程序清單 Cs 是與客戶端完全一致的 .這里就不再贅述 . // : implementation of the playingCards class. //這是個大模塊 ,只出示部分代碼 ////////////////////////////////////////////////////////////////////// 畢業設計 24 圖 A4 playingcards 成員清單 include in