畢業(yè)設計（論文）任務書

第1頁

第2頁

　 第3頁

基于Android與多媒體的英文學習APP的設計與實現(xiàn)

摘 要

縱觀人類的歷史發(fā)展進程，總是伴隨著科技的進步而演變，從石器時代到冷兵器時代再到工業(yè)時代再到互聯(lián)網(wǎng)時代，每一次技術的更替人類的生活方式就發(fā)生一次質的變化，而如今移動互聯(lián)網(wǎng)的時代已經(jīng)到來。今年兩會期間，李克強總理也提出了“互聯(lián)網(wǎng)+”的概念，也從側面再次印證了這一規(guī)律。手機作為終端中較為輕便的一種，正在逐漸演變?yōu)橐环N連接一切的控制中心。英語是一種被世界上大部分國家所接受的語種，其在不同地域、不同民族、不同文化的交流中所起到的作用無可取代。在今天，英語的使用頻率已經(jīng)發(fā)展為僅次于母語。不同階層對英語學習的訴求不斷增強。在這樣的背景下，我們應該改變傳統(tǒng)方式，用一種更加方便的方式來實現(xiàn)學習英語的目的。本項目主要結合實際情況，利用Android與多媒體技術就大學生的英語學習進行了適度的群體定制，主要實現(xiàn)的功能模塊有：詞典、翻譯、音頻課堂、諺語名言及單詞本等功能。

關鍵詞： Android； 多媒體； 英語學習； 互聯(lián)網(wǎng)+

Android and multimedia English study design and Implementation Based on APP

Abstract

Throughout the history of human development is always accompanied by the progress of science and technology and the evolution from the stone age to the age of cold weapons to the industrial age to the age of the Internet, every technological change the human way of life has a qualitative change, and now the mobile Internet era has arrived. During the two sessions this year, Premier Li Keqiang put forward the concept of “Internet +”, also from the side once again confirms the rule. A mobile phone as the terminal is more portable, is gradually evolved into a connected all the control center. English is one of the most countries in the world have been accepted by language, in different regions, different nationalities, different cultures in the role can not be replaced. Today, the frequency of use of English has developed into the second language. Different levels of demands on English learning enhancement. In this context, we should change the traditional way, in a more convenient way to achieve the purpose of learning English. This project is mainly combined with the actual situation, the use of Android and multimedia technology on College Students English learning were moderate group customization, the main realization function module: dictionary, translation, audio classroom, saying words and word memory book and other functions.

Keywords:?Android; multimedia; English learning; Internet +

目 錄

1 緒論11

1.1 項目背景11

1.2 論文主要工作22

2 項目相關技術介紹與分析44

2.1 Android的發(fā)展和歷史44

2.2 Android體系結構55

2.2.1 Application（應用層）55

2.2.2 Application Framework（應用框架層）55

2.2.3 Libraries（系統(tǒng)運行庫層）55

2.2.4 Linux Kernel（Linux內核層）66

2.3 Android開發(fā)環(huán)境與工具66

2.3.1 搭建Android開發(fā)環(huán)境66

2.3.2 Android開發(fā)工具介紹1111

2.4 環(huán)境說明1111

2.4.1 編程環(huán)境1111

2.4.2 運行環(huán)境1111

3 項目可行性分析1212

3.1 可行性研究1212

3.1.1 技術可行性1212

3.1.2 經(jīng)濟可行性1212

3.1.3 操作可行性1212

4 項目需求分析與總體設計1313

4.1 需求分析1313

4.1.1 功能性需求分析1313

4.1.2 非功能性需求分析1313

4.2 系統(tǒng)總體設計及模塊劃分1313

4.2.1 模塊劃分1313

4.2.2 系統(tǒng)操作流程圖1414

4.3 數(shù)據(jù)庫設計及數(shù)據(jù)操作1515

4.3.1 數(shù)據(jù)庫概念設計1616

4.3.2 數(shù)據(jù)庫邏輯設計1717

4.3.3 數(shù)據(jù)庫的創(chuàng)建1717

4.3.4 數(shù)據(jù)庫的操作1717

4.3.5 數(shù)據(jù)的查看1717

5 系統(tǒng)的詳細設計與實現(xiàn)1919

5.1 系統(tǒng)主界面的設計1919

5.2 查詢模塊詳細設計：2020

5.2.1 調用有道翻譯API20API20API20

5.2.2 Json數(shù)據(jù)解析2121

5.3 發(fā)現(xiàn)模塊詳細設計2222

5.4 我的模塊2727

6 系統(tǒng)的測試2929

6.1 程序的測試2929

6.1.1 歡迎界面3030

6.1.2 主界面3131

6.1.3 “詞典”以及“翻譯”模塊3232

6.1.4 “發(fā)現(xiàn)”模塊測試3636

6.1.5 “我的”模塊測試3737

6.2 測試結果說明3838

致謝4040

參考文獻4141

外文文獻4242

1 緒論

1.1 項目背景

隨著全球化地球村時代的到來，英語成為全球化的基礎交流語言，想要走出國門走向世界，英語成為每一位追夢人的必跨門檻。它對于希望擁有更寬視野的人來說，必不可少社會生活的信息化和經(jīng)濟的全球化，使英語的重要性日益突出。英語作為最重要的信息載體之一，已成為人類生活各個領域中使用最廣泛的語言，英語能力已成為一種必備技能。學生若能學得一種外語能力，就能幫他打開進入另一個世界的學習之門，最后達成多元學習與價值的目標。從全世界來看，說英語的人數(shù)已經(jīng)超過了任何語言的人數(shù)，英語在45個國家是官方語言，世界三分之一的人口講英語，75%的電視節(jié)目是英語，四分之三的郵件是用英語書寫，電腦鍵盤是英語鍵盤，任何一個會議敢號稱是國際會議，其會議語言一定要用英語。此外，外貿行業(yè)也把英語作為通用語言，外貿交往、國際禮儀、書信函電、進出口文件、還有銀行文件語言等，統(tǒng)統(tǒng)以英語作為標準通用語言。大多數(shù)國家的高等學府，大學院校，都開設英語語言文學專業(yè)，僅在中國，就有數(shù)百所大學設有英語專業(yè)或英語相關專業(yè)。電腦和互聯(lián)網(wǎng)也是建立在英語的基礎上，這個行業(yè)的語言，就是英語，另外，在醫(yī)學領域、建筑領域、文學領域，都與英語有極大的關聯(lián)。

在Twitter與Facebook出現(xiàn)之前，當Google還只是一個想法的時候，手機只是足夠小的便攜式電話，能夠放在一個公文包中，電池足夠用上幾個小時，雖然沒有多余的功能，但是手機確實使人們可以不通過物理通信線路就能自由通信。

現(xiàn)在、小巧、時尚而且功能強大的手機已經(jīng)相當普及并且不可或缺。硬件的發(fā)展使手機在擁有更大更亮的屏幕和越來越多的外圍設備的同時也變的更加小巧和高效。

作為一款Linux內核的操作系統(tǒng)，android系統(tǒng)因其移植性、跨平臺性以及開放性被廣大移動終端廣泛使用。它涵蓋移動信息設備工作所需的全部軟件，包括操作系統(tǒng)、用戶界面和應用程序。Android系統(tǒng)不但可以應用于智能手機，在平板電腦市場也在急速擴張。Android正在逐漸成為目前移動信息設備應用程序開發(fā)的最主要的平臺。

移動互聯(lián)網(wǎng)(MobileInternet, 簡稱MI)是一種通過智能移動終端，采用移動無線通信方式獲取業(yè)務和服務的新興業(yè)務，包含終端、軟件和應用三個層面。終端層包括智能手機、平板電腦、電子書、MID等；軟件包括操作系統(tǒng)、中間件、數(shù)據(jù)庫和安全軟件等。應用層包括休閑娛樂類、工具媒體類、商務財經(jīng)類等不同應用與服務。隨著技術和產(chǎn)業(yè)的發(fā)展，未來，LTE(長期演進，4G通信技術標準之一)和NFC(近場通信，移動支付的支撐技術)等網(wǎng)絡傳輸層關鍵技術也將被納入移動互聯(lián)網(wǎng)的范疇之內。

移動互聯(lián)網(wǎng)的多媒體信息中的應用。隨著科技的進步，多媒體服務的移動用戶將成為主要趨勢，移動通信的發(fā)展在未來的十年。無線技術仍然在高速發(fā)展，未來空中接口的帶寬不斷增加，手持終端的功能將不斷完善和提高，各種移動應用的發(fā)展開辟了廣闊的空間。第二代數(shù)字移動通信系統(tǒng)發(fā)展到第三代移動通信系統(tǒng)是必然的趨勢。移動終端用戶對移動數(shù)據(jù)業(yè)務的強烈需求，和運營商也要提供更多的增值服務的設備。移動互聯(lián)網(wǎng)的發(fā)展，需要滿足統(tǒng)一的IP核心網(wǎng)的戰(zhàn)略要求，為移動數(shù)據(jù)通信的需要移動的主要移動互聯(lián)網(wǎng)市場。人們可以使用一些強大的掌上電腦，掌上電腦和筆記本電腦進行大量的數(shù)據(jù)處理和顯示，真正滿足用戶的移動計算應用的需求。

4G互聯(lián)網(wǎng)時代下，移動應用越來越多，Android 4.2.2更新包于2013年2月11日發(fā)布，未來采用Android系統(tǒng)手機越來越多。不僅僅在于手機，在任何移動設備上，都可以采用Android開發(fā)移植到終端設備上，例如電視、冰箱、空調、洗衣機等。將這些設備計入互聯(lián)網(wǎng)，我們可以通過手機實時知道各個設備的狀態(tài)，也可以控制它們工作?？傊?，Android 將帶給我們更加智能、便捷、現(xiàn)代的生活。從而，Android應用的開發(fā)，

將會越來越龐大，需求將會越來越豐富。

1.2 論文主要工作

本論文的內容主要包括摘要、目錄、緒論、Android簡介及編程環(huán)境與工具、有道英語可行性分析、有道英語需求分析、有道英語APP的總體設計、有道英語APP的詳細設計、有道英語APP的測試、結束語、致謝和參考文獻幾部分內容。

其中，緒論部分主要介紹了國內外移動互聯(lián)的發(fā)展情況、課題實現(xiàn)的背景及意義和本論文的主要結構；Android簡介及編程環(huán)境與工具部分主要介紹了編程環(huán)境的搭建，開發(fā)工具的使用；有道英語APP分析部分主要說明了該項目的可行性分析、需求分析；有道英語APP的總體設計部分主要介紹了軟件每個模塊的設計框架以及每個模塊子模塊的設計框架；有道英語APP的具體實現(xiàn)部分即詳細設計部分，主要敘述了軟件的具體實現(xiàn)思路、邏輯和部分主要截圖及源代碼；有道英語APP的測試部分主要描述了軟件最后實現(xiàn)的效果是否滿足軟件設計之初的基本需求。

1.3 論文脈絡

圖1-1

2 項目相關技術介紹與分析

2.1 Android的發(fā)展和歷史

Android是以Linux為基礎的開放源碼的操作系統(tǒng)，主要應用于便攜設備。最開始由Andy Rubin開發(fā)，主要支持手機。2005年由Google收購注資，并組建開放手機聯(lián)盟開發(fā)一戶，其逐漸擴展至平板電腦及其他領域上。2012年2月數(shù)據(jù)顯示，Android占據(jù)全球智能手機操作系統(tǒng)市場52.5%的份額，中國市場占有率為68.4%。

Android系統(tǒng)版本發(fā)布時間如表2-1所示。

表2-1 Android版本發(fā)布時間

2.2 Android體系結構

在Android操作系統(tǒng)中，將體系結構劃分為4層：Application（應用層）、Application Framework（應用框架層）、Libraries（系統(tǒng)運行庫層）以及Linux Kernel（Linux內核層）。Android體系結構如圖2-1所示：

圖2-1 Android體系結構圖

2.2.1 Application（應用層）

應用層是使用Java語言進行開發(fā)的一些應用程序，如地圖軟件、聯(lián)系人管理、E-mail連接、瀏覽器等都屬于應用層上運行的程序，許多開發(fā)出來的程序（如音樂播放器、通訊錄等）也都是運行在應用層上的。[3]該軟件（TYUT掌中行）也是運行在此層上的。

2.2.2 Application Framework（應用框架層）

應用框架層主要是Google發(fā)布的一些操作支持的類庫（API框架），開發(fā)人員可以使用這些類庫方便地進行程序開發(fā)，但是在開發(fā)時必須遵守框架的開發(fā)原則。而在應用框架層中也包含了眾多的組件。[3]

2.2.3 Libraries（系統(tǒng)運行庫層）

當使用Android框架層進行開發(fā)時，Android操作系統(tǒng)會自動使用一些C/C++的庫文件來支持所使用的各個組件，使其可以更好地為程序服務。[3]

2.2.4 Linux Kernel（Linux內核層）

Android操作系統(tǒng)主要基于Linux2.6內核，程序的安全性、驅動程序、進程管理等都由Linux內核所提供。[3]

2.3 Android開發(fā)環(huán)境與工具

2.3.1 搭建Android開發(fā)環(huán)境

1、下載、安裝JDK及測試JDK是否成功安裝

下載網(wǎng)址：http://www.oracle.com/technetwork/java/javase/downloads/index.html

下載界面如圖2-2所示。圖2-2 JDK下載頁面

我的JDK安裝路徑，如圖2-3所示。

圖2-3 JDK安裝路徑

JDK環(huán)境變量配置，如圖2-4所示。

圖2-4 JDK環(huán)境變量設置

檢查JDK是否安裝成功，在cmd下輸入命令javac，如果出現(xiàn)如圖2-5所示情況則為安裝成功。

圖2-5 JDK安裝成功界面

1. 下載并安裝Eclipse
   下載網(wǎng)址：http://www.eclipse.org/downloads/，如圖2-6所示。下載完畢后直接解壓，無需安裝。

圖2-6 eclipse下載界面

1. 下載Android SDK
   下載網(wǎng)址：http://developer.android.com/sdk/index.html，登錄該網(wǎng)址將會出現(xiàn)如圖2-7所示網(wǎng)頁，點擊Download the SDK選擇對應版本下載解壓即可。

圖2-7 SDK下載界面

1. 安裝Android開發(fā)插件

(1)打開Eclipse, 在菜單欄上選擇 Help->Install New SoftWare 將會出現(xiàn)如圖2-8所示界面。

圖2-8 安裝插件第一步

1. 點擊 Add按鈕,出現(xiàn)如圖2-9所示界面。其中，Name可以自己設定，此處設為“Android”，Location中輸入網(wǎng)址：http://dl-ssl.google.com/android/eclipse/。

圖2-9 安裝插件第二步

1. 點擊如圖2-9所示界面OK按鈕，出現(xiàn)如圖2-10所示界面。

圖2-10 安裝插件第三步

1. 點擊如圖2-10所示界面 Next按鈕，出現(xiàn)如圖2-11所示界面。

圖2-11 安裝插件第四步

1. 點擊如圖2-11所示界面Next按鈕，出現(xiàn)如圖2-12所示界面。

圖2-12 安裝插件第五步

1. 選擇I accept the terms of the license agreements 點擊如圖2-12所示界面Next按鈕,進入安裝插件界面，如圖2-13所示。

圖2-13 安裝插件第六步 圖2-14 安裝插件第七步

1. 安裝完成后，提示重新啟動Eclipse，點擊如圖2-14所示界面Yes按鈕。

2. 配置Android SDK

點擊Eclipse菜單window->preferences,進入如圖2-15所示界面。選擇SDK所在目錄。點擊OK。

圖2-15 配置SDK

通過以上步驟，本文作者就把Android開發(fā)環(huán)境搭建好了。

2.3.2 Android開發(fā)工具介紹

任何軟件的開發(fā)都離不開強大的開發(fā)工具，同理Android開發(fā)也有自己的開發(fā)工具。以下內容將簡要介紹Android的開發(fā)工具。

1.JDK簡介

JDK(Java Development Kit)是Sun Micro Systems針對Java開發(fā)員的產(chǎn)品。自從Java推出以來，JDK已經(jīng)成為使用最為廣泛的Java SDK。JDK 是整個Java的核心，包括了Java運行環(huán)境、Java工具和Java基礎類庫。

2.Eclipse簡介

Eclipse 是一種基于 Java 的可擴展開源開發(fā)平臺。其僅僅是一個框架和一組服務，用于通過插件組件構建開發(fā)環(huán)境。另外，Eclipse 附帶了一個標準的插件集JDT（Java Development Tools），Eclipse 還包括插件開發(fā)環(huán)境PDE（Plug-in Development Environment），這個組件主要為希望擴展 Eclipse 的軟件開發(fā)人員而設計。

3.ADT簡介

ADT(Android Development Tools)是Android開發(fā)所用工具是Eclipse編譯IDE環(huán)境中的工具，安裝ADT，可以為Android開發(fā)提供便利。

4.SDK簡介

SDK(Software Development Kit)是一些被軟件工程師用于為特定的軟件包、軟件框架、硬件平臺、操作系統(tǒng)等建立應用軟件的開發(fā)工具的集合。

2.4 環(huán)境說明

以下內容將說明本文作者開發(fā)該軟件所使用的編程環(huán)境以及該軟件運行的平臺。

2.4.1 編程環(huán)境

本文作者用Eclipse和Android SDK（Android2.2）作為編程環(huán)境，在軟件編寫初期使用模擬器進行測試，后期軟件逐步成熟后使用真機進行測試。

2.4.2 運行環(huán)境

軟件運行在操作系統(tǒng)為Android2.2以上版本的手機?；緷M足Android2.2系統(tǒng)以

上的各種型號手機（主要指屏幕適配方面）。

3 項目可行性分析

3.1 可行性研究

3.1.1 技術可行性

技術可行性分析主要分析現(xiàn)有技術條件能否順利完成開發(fā)工作，硬、軟件配置能否滿足開發(fā)者需要等。對于Android開發(fā)，Google公司提供了良好的開發(fā)集成工具，且本文作者大學所學專業(yè)為軟件工程移動互聯(lián)網(wǎng)方向，對Android手機應用有一段時間的研究與開發(fā)經(jīng)驗，并且熟悉Java語言。所以該軟件在開發(fā)技術這方面是可行的。

3.1.2 經(jīng)濟可行性

本軟件開發(fā)所使用的eclipse集成環(huán)境是免費軟件，這很大程度上節(jié)省了開發(fā)成本。并且在后期的實際使用過程中，太原理工大學良好的校園無線覆蓋為師生使用該軟件過程中需要網(wǎng)絡連接提供很大便利。所以該軟件在經(jīng)濟可行性方面也是滿足的。

3.1.3 操作可行性

該軟件的安裝使用和Android應用市場的大多數(shù)應用軟件類似，所以大多數(shù)用戶都能夠在不需進行指導的前提下方便使用該軟件，并且軟件系統(tǒng)里面都有良好的提示功能。因此從操作可行性的角度來衡量，該軟件的開發(fā)是可行的。

綜上可知，該軟件系統(tǒng)在技術、經(jīng)濟和操作上都是可行的，滿足可行性分析的要求，因此可以開發(fā)此軟件系統(tǒng)。

4 項目需求分析與總體設計

4.1 需求分析

4.1.1 功能性需求分析

通過一段時間的調研，根據(jù)反饋回來的意見，有道英語的功能需求大致定為：

a、查詞并實現(xiàn)添加到生詞本

b、翻譯語句

c、四六級音頻學習

4.1.2 非功能性需求分析

非功能需求有：

a、低資源消耗

手機設備CPU及內存資源相對有限，要求程序節(jié)省單詞查詢和翻譯時所用時間以及對CPU的占用，從而節(jié)省對手機硬件資源的占用，提高程序運行的流暢度。

b、易用性

易用性是與一組規(guī)定或者潛在的用戶為使用其軟件所需做的努力和對這樣的使用所作的評價有關的一組屬性。具體包括：

? 易理解性：與用戶為人質邏輯概念即其應用范圍所花的努力有關的軟件屬性。

? 易學習性：與用戶為學習軟件應用所花的努力有關的軟件屬性。

? 易操作性：與用戶為操作和運行控制所花的努力有關的軟件屬性。如帶首字母篩選功能的下拉列表等。

4.2 系統(tǒng)總體設計及模塊劃分

4.2.1 模塊劃分

根據(jù)功能性需求，系統(tǒng)模塊劃分為：詞典模塊、翻譯模塊、發(fā)現(xiàn)模塊、我的模塊。對應的模塊圖如圖4-1:

圖4-1 系統(tǒng)模塊圖

4.2.2 系統(tǒng)操作流程圖

本系統(tǒng)在預設的操作過程為：點擊APP通過響應界面后。

第一：進入查詢單詞的界面，詞典功能的實現(xiàn)是通過調用有道api進行聯(lián)網(wǎng)查詢，查詢出的單詞可以進行單獨備份，即：錄入單詞本中；

第二，可以通過底部的切換卡進行，切換至翻譯界面，然后可以輸入對應的中英文句子，同樣通過調用有道api進行聯(lián)網(wǎng)實現(xiàn)翻譯；

第三，通過切換卡將界面切換至發(fā)現(xiàn)模塊，可以進行四六級音頻的學習以及四六級?？嫉拿跃?；

第四，通過切換卡將界面切換至我的模塊，可以進行之前在單詞查詢中備份的單詞進行查看，并且可以通過點擊單詞實現(xiàn)再次跳轉到詞典界面實現(xiàn)二次查詢。

該軟件的操作流程圖如圖4-2所示：

圖4-2 系統(tǒng)操作流程圖

4.3 數(shù)據(jù)庫設計及數(shù)據(jù)操作

SQLite，是一款輕型的數(shù)據(jù)庫，是遵守ACID的關系型數(shù)據(jù)庫管理系統(tǒng)，它的設計目標是嵌入式的，而且目前已經(jīng)在很多嵌入式產(chǎn)品中使用了它，它占用資源非常的低，在嵌入式設備中，可能只需要幾百K的內存就夠了。它能夠支持Windows/Linux/Unix等等主流的操作系統(tǒng)，同時能夠跟很多程序語言相結合，比如 Tcl、C#、PHP、Java等，還有ODBC接口，同樣比起Mysql、PostgreSQL這兩款開源世界著名的數(shù)據(jù)庫管理系統(tǒng)來講，它的處理速度比他們都快。

SQLite相關知識點：

SQLiteDatabase

一個SQLiteDatabase的實例代表一個SQLite的數(shù)據(jù)庫，通過SQLite實例的一些方法，我們可以執(zhí)行SQL語句，進行對數(shù)據(jù)庫的增刪改查。數(shù)據(jù)庫對于一個應用來說是私有的，并且在一個應用當中，名字也是唯一的。

（2）SQLiteOpenHelper

這是一個抽象類。對于SQLiteOpenHelper我們通常需要繼承它，并實現(xiàn)它里面的三個函數(shù)。

1)onCreate

在數(shù)據(jù)庫第一次生成時會調用這個方法，一般我們在這個方法里生成數(shù)據(jù)庫表。

2）onUpgrade

當數(shù)據(jù)庫需要升級的時候，Android系統(tǒng)會自動調用這個方法，一般我們在這個方法里面刪除數(shù)據(jù)庫表，并建立新的數(shù)據(jù)庫表。并且還可以根據(jù)應用需求進行其他操作。

3）onOpen

這是當打開數(shù)據(jù)庫是的回調函數(shù)，一般不會用到。

本系統(tǒng)采用的是sqlite數(shù)據(jù)庫，sqlite數(shù)據(jù)庫是Android自帶的小型數(shù)據(jù)庫，可以將少量的數(shù)據(jù)存放在該數(shù)據(jù)庫中。針對不同的用戶的生詞是不同的，可以很方便的將生詞導入到數(shù)據(jù)庫中，也可以很方便的將單詞從數(shù)據(jù)庫中刪除。將此軟件中的數(shù)據(jù)表的關系設計如下：

4.3.1 數(shù)據(jù)庫概念設計

根據(jù)需求分析的結果，將本APP的數(shù)據(jù)庫設計如下：

圖4-3 生詞表的設計

圖4-4 翻譯句子表的設計

圖4-5歷史詞匯表的設計

4.3.2 數(shù)據(jù)庫邏輯設計

本APP維護了3個表，并且由于為了實現(xiàn)簡便，并沒有涉及到3個表之間的交互及數(shù)據(jù)共享，因此，得到的表的結構及屬性分別為：

history(_id ,query, translation ,uk ,us,explain)

sentence(_id ,JUZI ,YISI )

history(_id , query, translation, uk, us explains );

4.3.3 數(shù)據(jù)庫的創(chuàng)建

Android 提供了標準的數(shù)據(jù)庫創(chuàng)建方式。繼承SQLiteOpenHelper ,實現(xiàn)onCreate() 和 onUpgrade() 兩個方法，有個好處就是便于數(shù)據(jù)庫版本的升級，連接數(shù)據(jù)庫的算法見程序清單。數(shù)據(jù)庫如果創(chuàng)建不成功則拋出FIleNotFoundException異常。

4.3.4 數(shù)據(jù)庫的操作

Android對SQLite數(shù)據(jù)庫的操作主要有插入、刪除、查詢操作。但是前置條件是必須打開數(shù)據(jù)庫。在這里打開數(shù)據(jù)庫用的主要的方法是openForReadable()和openForWriteable(),打開數(shù)據(jù)之后才能進行相關的操作，其中插入單詞的方法是insert(),刪除單詞的方法是delete()。其詳細代碼見程序清單。注意：在操作完了數(shù)據(jù)庫之后，需要對資源進行釋放，這里就是對數(shù)據(jù)庫資源進行關閉，關閉數(shù)據(jù)庫的方法是close()。

4.3.5 數(shù)據(jù)的查看

Android中程序是利用Cursor游標類指向數(shù)據(jù)表中的某一項，然后進行查詢數(shù)據(jù)，用Log日志顯示出來。查詢時用的方法是數(shù)據(jù)庫本身的查詢方法query(),需要注意的是這個方法比較復雜，他有8個參數(shù)，因為它將一個完整的SQL語句拆成了若干個部分：

第一個參數(shù)table：表名，相當于SQL的from后面的部分。在此還要注意

如果和多表聯(lián)合查詢時，就用逗號將兩個表名分開，拼成一個字符串的table值。

第二個參數(shù)是columns，要查詢出來的列名。相當于SQL的select后面的部分。

第三個參數(shù)是selection，查詢的條件，相當于SQL的where后面的部分，在這個語句中允許使用“？”，也就是說這個用法和JDBC中的PreparedStatement的用法相似。

第四個參數(shù)selectionArgs，對應于selection的值，selection有幾個問號，這里就得用幾值。

第五個參數(shù)groupBy，相當于SQL的group by后面的部分。

第六個參數(shù)having，相當于SQL的having后面的部分。

第七個參數(shù)orderBy，相當于SQL的order by后面的部分，如果是倒序，或者是聯(lián)合排序，可以寫成類似這樣：String orderBy = “id desc,name”。

第八個參數(shù)limit，指定的結果集的大小，它和Mysql的limit用法不太一樣，Mysql可以指定從多少行開始之后取多少條，例如，“l(fā)imit 100,10”，但是這里只支持一個數(shù)值。

5 系統(tǒng)的詳細設計與實現(xiàn)

5.1 系統(tǒng)主界面的設計

本項目的主界面的菜單欄的底部位置是通過TabHost這個組件來實現(xiàn)的，首先在activity_translate.xml布局文件中聲明，切換卡則通過TabWidget實現(xiàn)，而切換卡的背景更換則是通過chat_tab_selector.xml的設置來實現(xiàn)，chat_tab_selector.xml的代碼如下：

<?xml version=”1.0″ encoding=”utf-8″?>

<selector xmlns:android=”http://schemas.android.com/apk/res/android“>

<item android:drawable=”@drawable/ju” android:state_focused=”true”/>

<item android:drawable=”@drawable/dise” android:state_selected=”true”/>

<item android:drawable=”@drawable/dise” android:state_pressed=”true”/>

<item android:drawable=”@drawable/ju”/>

</selector>

制定完主頁面布局后，在src/com.example.translate下的TranslateActivity文件中OnCreate（OnCreate方法是用來初始化Activity實例對象的）中調用布局，另外因為本activity在創(chuàng)建時沒有繼承TabActivity，因此必須在得到tabHost之后，添加標簽之前調用tabHost.setup()，到現(xiàn)在為止頂部菜單欄的布局已經(jīng)基本完成，但現(xiàn)在里面所對應的內容還是空的。所以就需要在這里給tabHost中添加tab內容，以第一格的tab為例，先是通過Intent的方式新建個intent1，用來實現(xiàn)頁面的跳轉的方法，然后動態(tài)用createTab()的方法添加對應切換卡內容以及跳轉對象。具體代碼如下：

public class TranslateActivity extends ActivityGroup {

private TabHost tabHost = null;

@Override

protected void onCreate(Bundle savedInstanceState) {

super.onCreate(savedInstanceState);

setContentView(R.layout.activity_translate);

tabHost = (TabHost) findViewById(R.id.trainTab);

// 如果不是繼承TabActivity，則必須在得到tabHost之后，添加標簽之前調用tabHost.setup()

tabHost.setup(this.getLocalActivityManager());

Intent intent1 = new Intent(this, WordActivity.class);

Intent intent2 = new Intent(this, ContentActivity.class);

Intent intent3 = new Intent(this, FxActivity.class);

Intent intent4 = new Intent(this, SCActivity.class);

createTab(“詞典”, intent1.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP));

// 切換時刷新Activity

createTab(“翻譯”, intent2);

createTab(“發(fā)現(xiàn)”, intent3);

// 切換時刷新Activity

createTab(“我的”, intent4.addFlags(Intent.FLAG_ACTIVITY_CLEAR_TOP));

tabHost.setCurrentTab(0);

}

在上述思路下我們的詳細的效果圖如下：

圖5-1 系統(tǒng)主界面

5.2 查詢模塊詳細設計：

5.2.1 調用有道翻譯API

有道翻譯API，為廣大開發(fā)者提供開放接口，從而降低語言理解與應用門檻。依靠有道翻譯網(wǎng)絡數(shù)據(jù)挖掘和統(tǒng)計機器翻譯技術實力做基礎，可以更加快捷的完成項目，具體代碼如下：

try {

urlStr =

“http://fanyi.youdao.com/openapi.do?keyfrom=justTec&key=1249502330&type=data&doctype=json&version=1.1&q=” +URLEncoder.encode(word, “utf8”);

} catch (UnsupportedEncodingException e1) {

// TODO Auto-generated catch block

e1.printStackTrace();

}

5.2.2 Json數(shù)據(jù)解析

在本系統(tǒng)中查詞和翻譯調用有道接口，通過HTTP協(xié)議回傳給設備，返回來的數(shù)據(jù)為標準的Json格式，再通過Json解析顯示到對應的UI上。具體代碼如下：

try?{

String jsonData = “”;

// 向指定的URL發(fā)送Http請求

HttpResponse response = httpClient.execute(new?HttpGet(urlStr));

// 取得服務器返回的響應

HttpEntity entity = response.getEntity();

BufferedReader bufferedReader =?new?BufferedReader(new?InputStreamReader(entity.getContent()));

String line = “”;

while?((line = bufferedReader.readLine()) !=?null) {

jsonData = jsonData + line;

}

word =?new?Word();

JSONObject jsonObject =?new?JSONObject(jsonData);

word.setQuery(query);

word.setTranslation(jsonObject.getJSONArray(“translation”).getString(0));

JSONObject basic = jsonObject.getJSONObject(“basic”);

// 音標

word.setUk(basic.getString(“uk-phonetic”).trim());

word.setUs(basic.getString(“us-phonetic”).trim());

// 返回json數(shù)組

String otherString = “”;

JSONArray otherArray = basic.getJSONArray(“explains”);

for?(int?i = 0; i < otherArray.length(); i++) {

otherString += “;” + otherArray.getString(i);

}

word.setExplains(otherString.substring(1));

}?catch?(Exception e) {

}

模塊效果截圖如下：

圖5-2 模塊界面 圖5-3 中文查詞

5.3 發(fā)現(xiàn)模塊詳細設計

發(fā)現(xiàn)模塊意在提升大學生的空閑時間利用率，因此結合大部分同學們的需求，加入了四六級聽力音頻以及四六級作文中經(jīng)常被引用的諺語名言，最后還加入了關于我們，用來申明一些系統(tǒng)的信息：

1. 四六級聽力音頻，主要是利用了Android自帶的mediaplayer來進行定制實現(xiàn)，首先將所要播放的音頻放入到資源raw文件夾中，然后申明出一個mediaplayer對象，通過其start(),stop()和pause()三個方法進行對應的音頻的播放，停止和暫停。具體代碼如下：

布局代碼：

<RelativeLayout xmlns:android=”http://schemas.android.com/apk/res/android“

xmlns:tools=”http://schemas.android.com/tools“

android:layout_width=”match_parent”

android:layout_height=”match_parent”

android:paddingBottom=”@dimen/activity_vertical_margin”

android:paddingLeft=”@dimen/activity_horizontal_margin”

android:paddingRight=”@dimen/activity_horizontal_margin”

android:paddingTop=”@dimen/activity_vertical_margin”

android:background=”@drawable/mao”

tools:context=”.Cet41Activity” >

<Button

android:id=”@+id/pauseBtn”

android:layout_width=”wrap_content”

android:layout_height=”wrap_content”

android:layout_alignParentLeft=”true”

android:layout_alignParentTop=”true”

android:layout_marginLeft=”21dp”

android:layout_marginTop=”122dp”

android:text=”暫?！?/>

<Button

android:id=”@+id/playBtn”

android:layout_width=”wrap_content”

android:layout_height=”wrap_content”

android:layout_alignLeft=”@+id/pauseBtn”

android:layout_alignParentTop=”true”

android:layout_marginTop=”28dp”

android:text=”播放” />

<Button

android:id=”@+id/stopBtn”

android:layout_width=”wrap_content”

android:layout_height=”wrap_content”

android:layout_alignLeft=”@+id/pauseBtn”

android:layout_below=”@+id/pauseBtn”

android:layout_marginTop=”46dp”

android:text=”停止” />

</RelativeLayout>

對應實現(xiàn)代碼：

player=MediaPlayer.create(this,R.raw.cet4);

playBtn.setOnClickListener(new OnClickListener() {

public void onClick(View v) {

// TODO Auto-generated method stub

player.start();

playBtn.setEnabled(false);

stopBtn.setEnabled(true);

pauseBtn.setEnabled(true);

}

});

實現(xiàn)效果如下：

圖5-4 音頻課堂 圖5-5 音頻播放

b、諺語名言模塊，將四六級考試中常用到的100句諺語名言整理成Excel文件，然后把Excle表中的100個英文語句與翻譯寫入數(shù)據(jù)庫，然后通過隨機函數(shù)Random()在每次啟動程序從100個句子隨機顯示一句及其翻譯。具體實現(xiàn)該模塊的重點代碼如下：

1）將Excle表中的句子導入數(shù)據(jù)庫表的代碼：

try {

// 讀取Excel，導入到數(shù)據(jù)庫

InputStream in = this.getClass().getClassLoader().getResourceAsStream

(“com/example/translate/db/juzi.xls”);

// 創(chuàng)建工作簿

HSSFWorkbook workBook = new HSSFWorkbook(in);

HSSFSheet sheet = workBook.getSheet(“Sheet1”);

int rows = sheet.getPhysicalNumberOfRows();

if (rows > 0) {

for (int j = 0; j < rows; j++) {

// 行循環(huán)

HSSFRow row = sheet.getRow(j);

if (row != null) {

HSSFCell cell1 = row.getCell(0,

HSSFRow.RETURN_BLANK_AS_NULL);

HSSFCell cell2 = row.getCell(1,

HSSFRow.RETURN_BLANK_AS_NULL);

ContentValues content = new ContentValues();

content.put(“JUZI”, cell1.getStringCellValue());

content.put(“YISI”, cell2.getStringCellValue());

db.insert(TABLE_SENTENCE, null, content);

}

}

}

} catch (IOException e) {

e.printStackTrace();

}

2）隨機顯示諺語名言的代碼：

CommonBean bean = new CommonBean();

Cursor cursor = database.query(TABLE_SENTENCE, new String[] { “_id”, “JUZI”,

“YISI” }, “_id=” + CommonUtils.getRandom100(), null, null, null, null, null);

if (cursor.moveToNext()) {

bean.setId(cursor.getInt(0));

bean.setW(cursor.getString(1));

bean.setY(cursor.getString(2));

}

cursor.close();

實現(xiàn)效果圖，如下：

圖5-6

c、關于我們，將應用的一些信息呈現(xiàn)給用戶，主要是利用了Android的AlertDialog來實現(xiàn)的，首先申明一個AlertDialog的builder對象，然后利用builder的setMessage（）方法進行定制，具體實現(xiàn)代碼如下：

final Builder builder=new AlertDialog.Builder(this);

gywmBtn.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View v) {

// TODO Auto-generated method stub

builder.setIcon(R.drawable.face2);

builder.setMessage(“中華人民共和國萬歲！”

+ “世界人民大團結萬歲！”);

builder.create().show();

}

});

實現(xiàn)效果如下：

圖5-7

5.4 我的模塊

在我的模塊中有在查詞過程中保存的生詞，在該模塊中我們可以對生詞進行管理，可以刪除生詞以及當點擊某個生詞時可以再次跳轉到查詢該詞的界面，方便二次查詢。具體實現(xiàn)代碼如下：

public View getView(final int position, View convertView, ViewGroup parent) {

if (convertView == null) {

convertView = mInflater.inflate(R.layout.scitem, null);

}

TextView id = (TextView) convertView.findViewById(R.id.id);

TextView query = (TextView) convertView.findViewById(R.id.query);

TextView translate = (TextView) convertView.findViewById(R.id.translate);

Button delete = (Button) convertView.findViewById(R.id.delete);

id.setText(String.valueOf(list.get(position).get_id()));

query.setText(list.get(position).getQuery());

translate.setText(list.get(position).getTranslation());

delete.setOnClickListener(new OnClickListener() {

@Override

public void onClick(View view) {

CommonUtils.dbAdater.deleteSc(list.get(position).get_id());

setList(CommonUtils.dbAdater.getScList());

notifyDataSetChanged();

Toast.makeText(getApplicationContext(), “刪除成功”,

Toast.LENGTH_SHORT).show();

}

});

return convertView;

}

具體實現(xiàn)效果如圖5-8所示：

圖5-8

6 系統(tǒng)的測試

6.1 程序的測試

在設計系統(tǒng)的過程中，存在一些錯誤是必然的。對于語句的語法錯誤，在程序運行時自動提示，并請求立即糾正，因此，這類錯誤比較容易發(fā)現(xiàn)和糾正。但另一類錯誤是在程序執(zhí)行時由于不正確的操作或對某些數(shù)據(jù)的計算公式的邏輯錯誤導致的錯誤結果。這類錯誤隱蔽性強，有時會出現(xiàn)，有時又不出現(xiàn)，因此，對這一類動態(tài)發(fā)生的錯誤的排查是耗時費力的。

（1）測試的重要性

在實踐中，軟件測試的困難常常使人望而卻步或敷衍了事，這是由于對測試仍然存在一些不正確的看法和錯誤的態(tài)度，這包括:

①認為測試工作不如設計和編碼那樣容易取得進展難以給測試人員某種成就感;

②以發(fā)現(xiàn)軟件錯誤為目標的測試是非建設性的，甚至是破壞性的，測試中發(fā)現(xiàn)錯位是對責任者工作的一種否定;

③測試工作枯燥無味，不能引起人們的興趣;

④測試工作是艱苦而細致的工作;

⑤對自己編寫的程序盲目自信，在發(fā)現(xiàn)錯誤后，顧慮別人對自己的開發(fā)能力的看法。

這些觀點對軟件測試工作是極為不利的，必須澄清認識、端正態(tài)度，才可能提高軟件產(chǎn)品的質量。

（2）測試的目的

如果測試的目的是為了盡可能多地找出錯誤，那么測試就應該直接針對軟件比較復雜的部分或是以前出錯比較多的位置。

①軟件測試是為了發(fā)現(xiàn)錯誤而執(zhí)行程序的過程;

②測試是為了證明程序有錯，而不是證明程序無錯誤;

③一個好的測試用例是在于它能發(fā)現(xiàn)至今未發(fā)現(xiàn)的錯誤;

④一個成功的測試是發(fā)現(xiàn)了至今未發(fā)現(xiàn)的錯誤的測試。

這種觀點可以提醒人們測試要以查找錯誤為中心，而不是為了演示軟件的正確功能。但是僅憑字面意思理解這一觀點可能會產(chǎn)生誤導，認為發(fā)現(xiàn)錯誤是軟件測試的唯一目，查找不出錯誤的測試就是沒有價值的，事實并非如此。

　首先，測試并不僅僅是為了要找出錯誤。通過分析錯誤產(chǎn)生的原因和錯誤的分布特征，可以幫助項目管理者發(fā)現(xiàn)當前所采用的軟件過程的缺陷，以便改進。同時，這種分析也能幫助我們設計出有針對性地檢測方法，改善測試的有效性。其次，沒有發(fā)現(xiàn)錯誤的測試也是有價值的，完整的測試是評定測試質量的一種方法。與開發(fā)過程類似，測試過程也必須分步驟進行，每個步驟在邏輯上是前一個步驟的繼續(xù)。大型軟件系統(tǒng)通常由若干個子系統(tǒng)組成，每個子系統(tǒng)又由若干個模塊組成。因此，大型軟件系統(tǒng)的測試基本上由下述幾個步驟組成：

（1）模塊測試在這個測試步驟中所發(fā)現(xiàn)的往往是編碼和詳細設計的錯誤。

（2）系統(tǒng)測試在這個測試步驟中發(fā)現(xiàn)的往往是軟件設計中的錯誤，也可能發(fā)現(xiàn)需求說明中的錯誤。

（3）驗收測試在這個測試步驟中發(fā)現(xiàn)的往往是系統(tǒng)需求說明書中的錯誤。

模塊測試主要是將軟件總體的幾個分模塊進行獨立地測試，從而發(fā)現(xiàn)分模塊的bug并進行相關的調試。有道英語APP的模塊測試主要分以下幾個模塊進行測試。

6.1.1 歡迎界面

測試歡迎界面圖片能夠顯示。如圖6-1所示：

圖6-1 歡迎界面（清晰）

測試結果：可以正確實現(xiàn)首界面，界面友好顯示。

6.1.2 主界面

測試主界面是否可以正確顯示，如圖6-3和圖6-4所示：

圖6-2 主界面 圖6-3 主界面

測試結果：可以正確顯示主界面及及其他功能界面，功能界面之間界面之間切換流暢，不會出現(xiàn)卡死現(xiàn)象的發(fā)生。

6.1.3 “詞典”以及“翻譯”模塊

數(shù)據(jù)合理性測試：選取合理的測試數(shù)據(jù)，對查詢功能進行測試。測試數(shù)據(jù)如表6-1所示。

表6-1 查詢數(shù)據(jù)示例

具體步驟如下：

第一步：對測試的項目進行分析，確定測試策略，制定測試計劃。計劃被審核批準后轉向第二步。測試工作啟動前一定要確定正確的測試策略和指導方針，這些是后期開展工作的基礎。只有將本次的測試目標和要求分析清楚，才能決定測試資源的投入。

第二步：設計測試用例。設計測試用例要根據(jù)測試需求和測試策略來進行，進度壓力不大時，應該設計的詳細，如果進度、成本壓力較大，則應該保證測試用例覆蓋到關鍵性的測試需求。該用例被批準后轉向第三步。

第三步：如果滿足“啟動準則”（EntryCriteria），那么執(zhí)行測試。執(zhí)行測試主要是搭建測試環(huán)境，執(zhí)行測試用例。執(zhí)行測試時要進行進度控制、項目協(xié)調等工作。

第四步：提交缺陷。這里要進行缺陷審核和驗證等工作。

第五步：消除軟件缺陷。通常情況下，開發(fā)經(jīng)理需要審核缺陷，并進行缺陷分配。進入到回歸測試階段。如果滿足“完成準則”（ExitCriteria），那么正常結束測試。

第六步：撰寫測試報告。對測試進行分析，總結本次的經(jīng)驗教訓，在下一次的工作中改。

測試結果如圖6-4–6-11所示：

圖6-4 全為數(shù)字 圖6-5 無字符

圖6-6 正常拼寫 圖6-7 首字母大寫

圖6-8 大小寫間插 圖6-9 數(shù)字與字母間插

圖6-10 正常語句 圖6-11 數(shù)字與字母與中文間插

測試結果：可以正確實現(xiàn)查詢信息錯誤或正確時的相關的顯示結果。

6.1.4 “發(fā)現(xiàn)”模塊測試

圖6-12 “發(fā)現(xiàn)”界面 圖6-13 音頻課堂

圖6-14 關于我們 圖6-15 諺語名言

測試發(fā)現(xiàn)界面及功能是否可以正確實現(xiàn)，其中，主要測試的方面有：

1. 音頻課堂的界面能否正確顯示，并且在播放音頻上能否正確的實現(xiàn)播放與停止；

2. 諺語名言的界面能否正確顯示，并且在名言警句的切換上能否正確順暢的切換；

3. 關于我們的界面，能否正確的彈出系統(tǒng)預設的一些信息。

測試結果：可以正確實現(xiàn)音頻播放以及諺語的切換顯示。

6.1.5 “我的”模塊測試

測試發(fā)現(xiàn)界面及功能是否可以正確實現(xiàn)，如圖6-16和圖6-17:

圖6-16 生詞本 圖6-17 生詞本

測試結果：可以正確實現(xiàn)單詞的刪除并實現(xiàn)生詞的查找跳轉。

6.2 測試結果說明

由于篇幅有限，本論文中將不能把所有測試過程一一羅列，上述測試部分只是該軟件中比較重要的模塊，其余模塊也經(jīng)過反復的測試，測試出現(xiàn)的問題經(jīng)過反復不斷的調試。主要問題及解決思路在結尾部分有所說明。經(jīng)過反復的測試與調試，目前該軟件已經(jīng)基本可以實現(xiàn)需求中所需的功能，并且可以在系統(tǒng)為Android2.2以上版本的各種手機上友好地運行使用。

總結

本APP基本實現(xiàn)了設計之初的預想需求，并且在一定程度上有創(chuàng)新之處，當然還存在一些不足之處。下面在此做一個總結，為此后的研究做一個展望：

a、適配問題

沒有做到不同屏幕，不同類型的終端的適配，由于當初界面的設定，使得本APP在一些平板上的運行效果，反而要比手機端更好，在一些屏幕較小的手機上，運行效果可能沒有預期中的完美。

b、本地化問題

由于當初實現(xiàn)時，借助于有道api,對于運行本APP的同時，需要網(wǎng)絡的支持，當網(wǎng)絡斷掉的時候就無法實現(xiàn)新詞的查詢，因此在使用中可能會給用戶帶來一定的不方便。

c、音頻資源

由于在實現(xiàn)音頻學習的板塊中，使用的是android自帶的mediaplayer,并且直接將音頻資源打包進apk中，所以暫時只能提供為數(shù)不多的音頻資源，無法實現(xiàn)資源的搜索，只能寄希望于版本的更新，從而更新資源庫。

畢設的設計完成過程中遇到的問題遠遠不止如上所述，有些是用戶體驗不好的小問題，有些是直接讓程序意外中止的大問題，這些問題只有在實踐中才肯出現(xiàn)，僅僅是書本上的理論學習中是永遠不會遇到的。另外在本次畢業(yè)設計完成的過程中，才知“書到用時方恨少”，很多時候會在一些細小的問題上出錯，不經(jīng)感慨自己的經(jīng)驗不足。白駒過隙，逝水流年，面對內功的不足，唯有加強修煉了，經(jīng)過這次畢設的經(jīng)歷，也讓自己明確了今后努力的方向。

致謝

值此論文付梓之際，心情無比激動?！帮嬈淞鞫计湓?，成吾學而念吾師”。四年前的秋天，我懷揣著對夢想的執(zhí)著追求，成為一名大學生，并如愿成為理工學子。四年來母校的老師學識淵博，品格高尚、治學嚴謹、平易近人，都給我留下了深刻的印象，這些都是我今后學習工作生活中的寶貴財富，將永遠激勵著我不斷求索前進。

感謝宋春花教授，她謙和坦蕩的風范、嚴謹勤奮的精神以及對我悉心幫助和指導，令我由衷的感動。感謝尹珂男講師，雖身兼數(shù)職，工作繁忙，但這段時間來從未放松過對我的教育，兩位導師的諄諄教誨常在耳畔，絲絲關懷銘記心間；每有疑難，師長循循善誘，博文以禮，約我以文，總有沐浴春風、茅塞頓開之感。感謝任青松、胡莉二位老師，他們既如長者給我教誨與關懷，又如兄長與我分享生活中的得失與快樂，既是良師亦為益友；得良師益友如此，我三生之有幸。

感謝李杰、蘇澤楠、韓軍華等同學，與他們共同學習、探討交流，給我的論文提出寶貴的意見和建議，對我啟迪良多，情同手足，惠我實多；諸多關懷，銘記于心！
感謝我的父母，他們養(yǎng)育了我，給予我強健的體魄和自強不息的人生信念，正是他們在背后默默的支持和鼓勵，才使我得以安心學習，在此向他們表示由衷的感謝。
最后感謝所有幫助我的領導、同學，你們的支持和幫助是我不懈的動力！書山有路，學海無涯。我將會在以后的人生道路上繼續(xù)奮勇前進，實現(xiàn)自己的人生價值！

參考文獻

1. 商陸民，朱丹群，周然，邢海榮. 多功能電子詞典軟件設計[J]. 東南大學電子工程系,1995

2. 任楨.電子詞典的設計研究[J]. 華中科技大學,2003

3. 黃藝鋒，閆巧.基于Android平臺電子詞典的設計與實現(xiàn)[J].深圳大學計算機與軟件學院,2011

4. 朱婷婷，李惠.基于Android的應用軟件的綜述[J] .浙江師范大學數(shù)理信息學院,2011

5. 邵明博.基于智能手機的大學英語移動學習平臺研究[D]. 華中師范大學,2011

6. 尹京華,王華軍 .基于Android開發(fā)的數(shù)據(jù)存儲[J]. 成都理工大學信息科學與技術,2012

7. 劉銳.Android開發(fā)的性能優(yōu)化[D]. 新華網(wǎng)股有限公司,2009

8. Serguei A.Mokhov,Mashrur Mia.A UI Design Case Study and a Prototype of a Travel Search Engine.Scientific American,2010

9. J.MANI BHARATHI,?S.Hemalatha,?V.AISHWARYA?.Advancement in Mobile Communication using Android .International Journal of Computer Applications, 2010, Vol.1 (7)

[10]Code Home.Android-An Open Handest Alliance Project.Future Generation Computer Systems,2011

外文文獻

An Enhanced Dragonfly Key Exchange?Protocol against Offline

Dictionary Attack

Abstract

Dragonfly is Password Authenticated Key Exchange protocol that uses a shared session key to authenticate parties based on pre-shared secret password. It was claimed that this protocol was secure against off-line dictionary attack, but a new research has proved its vulnerability to off-line dictionary attack and proving step was?applied by using “Patched Protocol” which was based on public key validation. Unfortunately, this step caused a raise in the computation cost, which made this protocol less appealing than its competitors. We proposed an alternate enhancement to keep this protocol secure without any extra computation cost that was known as “Enhanced Dragonfly”.This solution based on two-pre-shared secret passwords instead of one and the rounds between parties had compressed into two rounds instead of four. We prove that the enhanced-Dragonfly protocol is secure against off-line dictionary attacks by analyzing its security properties using the Scyther tool. A simulation was developed to measure the execution time of the enhanced protocol,which was found to be much less than the execution time of patched Dragonfly. The off-line dictionary attack time is consumed for few days if the dictionary size is 10,000. According to this, the use of the enhanced Dragonfly is more efficient than the patched Dragonfly.

Keywords:Password Authenticated Key Exchange (PAKE), Original Dragonfly,

Patched Dragonfly, Enhanced Dragonfly, Two-Pre-Shared Password

1. Introduction
   Nowadays, information is increasing at a faster rate and it needs to be secured when exchanging it over insecure networks. The most efficient way to secure this information is Cryptology which is the science of building and analyzing secret code. It consists of cryptography and cryptanalysis. Cryptography is the science that builds secret codes and cryptanalysis is the science that analyzes those codes [1]. There are two types of cryptography:
   Symmetric and Asymmetric key cryptography. Symmetric key cryptography has a shared key that is used by the sender and receiver in encryption and decryption processes, while Asymmetric key cryptography has a public key which is used in encryption processes and private key which is used in decryption processes .
   One of the symmetric cryptography protocols is key exchange protocol, which allows two parties who share non-secret information to compute a shared key via public communication. Authenticated Key Exchange (AKE) is a symmetric protocol that not only allows parties to compute the shared key but also ensures the identity of the parties where a party can compute a shared key only if he/she is the one who claims to be [3]. Another example of symmetric protocols is the Two-party Password-based Authenticated Key Exchange (2PAKE) protocol that permits two parties to generate a session key based on a pre-shared password and authenticates each other[4]. In general, PAKE protocols are exposed to different types of attacks, mainly passive and active attacks. Passive attacks are difficult to detect and are used to get information that is sent between parties without modifying the information or harming the resources. Active attacks enable the attacker to modify the encrypted message orchange the meaning of the decrypted message by creating false streams [5]. However, the most complicated type of attack is the dictionary attack regardless of whether it is offline or online. Offline dictionary attack enables the attacker to record information from successful execution of the protocol by eavesdropping on the communication between parties. Then the attacker goes offline to find the required password by trying all passwords and choosing the correct password depending on the recorded information. The interaction with the server is not required in an offline dictionary attack. Online dictionary attacks enable the attacker to find the required password by trying all passwords during the interaction with the server [6].
   2PAKE protocol has various types of protocols. In 1992, the first 2PAKE protocol (called the Encrypted KeyExchange (EKE)) was proposed by Bellovin and Merritt [7]. Since then, many other 2PAKE protocols have been proposed (e.g. [8]-[12]). One of these protocols was Dragonfly which was defined by Dan Harkins who claimed that this protocol had resistance to passive attacks, active attacks and offline dictionary attacks without security proofs [12]. In 2013, Dylan and Feng analyzed this protocol and proved that this protocol had weakness points in its security properties against active attack and offline dictionary attacks. They proposed to patch Dragonfly as a solution to verify its security properties by adding a public key validation [12].
   The main problem in the patched dragonfly protocol was that it consumed an increased computation cost during the execution of the protocol when public key was used, which involved a large bit operation. In this paper,we introduced another enhancement for the Dragonfly protocol without using a public key. The proposed solution is based on using two-pre-shared secret passwords instead of one and the number of rounds between parties has been reduced to two instead of four. This step adds more security to the original Dragonfly protocol while the attacker will require more than 1.5 days to perform the off-line attack in case the shared password is extracted from a dictionary with the size 1000. This result has been approved through a simulation project which was developed by the java programming language. The simulation project has been used to find out the required execution time by both parties who are sharing the communication. The execution time is found to be less than
   the time required in the use of public key validation. We also approved the efficiency of Enhanced-Dragonfly protocol by using the Scyther tool to analyze its security properties and its structure.
   The paper is organized into sections: Section 2 presents the related work; Section 3 presents review of the Dragonfly protocol; the proposed solution is presented in Section 4, while discussion is presented in Section 5.Finally, the conclusion is in Section 6. It is focused towards those who are interested in cryptography and cryptanalysis domain.

2. Related Work
   Password Authenticated Key Exchange (PAKE) protocols have been playing an essential role in providing secure communications. As is usual in cryptography, with each new release of a protocol, attempts to attack this protocol have also been released in order to measure resistance against these attacks.
   In research [13], analysis of the security weaknesses of SPAKE1 and SPAKE2 protocols has been introduced.It was found that these protocols are vulnerable against password compromises, impersonation and Denialof-Service (DoS) attacks. Additionally, it was proved that the Hitchcock protocol [14], which uses public key encryptions, is insecure against momentary key compromise masquerades, Key Compromise Impersonation(KCI) attacks and off-line dictionaries. To remove these disadvantages, a new efficient protocol has been designed which relies on two-party PAKE protocols based on symmetric key exchange protocol and multiple hashfunction calculations. The public key scheme has been replaced here with the symmetric encryption because the
   latter requires fewer bit operations. Many theories have been explained to prove that the proposed scheme is secure against various attacks. It provides the mutual authentication and forward secrecy attributes with many other security attributes. However, there is a little increase in computational costs that was caused by the extra hash calculations. This may be deemed negligible when considering the efficiency of the extra security attributes and lower number of rounds.
   Moreover, another research [15] introduced the vulnerabilities of SPEKE and EKE protocols and analyzed them due to theoretical practices. In addition, a new PAKE protocol was proposed and was called Password Authenticated Key Exchange by Juggling (J-PAKE). It depends on shared secret-password between two entities and it has two rounds to create a strong shared key. It is based on well-established primitive in cryptography called Zero-Knowledge Proof (ZKP) that allows a person to prove his knowledge of a discrete logarithm without revealing it. The analysis of this protocol proved that it prevents off-line dictionary attacks, limits an active attacker to guess only one password per protocol execution and provides forward secrecy. It has advantages like:protection of users from leaking passwords and it does not require PKI deployments. This protocol is very efficient
   according to the use of well-established primitives.
   Recent researches in the field of PAKE protocols are moving towards using Public Key Infrastructure (PKI) in the authentication process. In recent years, PAKE has been used with RSA encryption method to provide the appropriate secrecy between two parties. In [16] a new proposed protocol named as E3PAKE-RSA, which is based on RSA scheme with the three-party model that enables two entities to only need to remember a humanmemorable
   password to authenticate each other and agree on a large session key with the assistance of the trusted server. The public/private key parameters are selected by the clients rather than a trusted distribution center, which makes the process of on-line authentication obsolete. It was predicted that the computation cost for this protocol would be respectively high according to the two-party RSA-PAKE. However, during the testing phase, which applied to the generic constructions, the computation cost of E3PAKE-RSA protocol was found to be as much as the two-party RSA-PAKE and the number of total rounds are less than this. Actually, this protocol requires more time to execute due to the use of the RSA encryption method and the long bit operations, while the other PAKE protocols (which do not use PKI) work faster.
   Overview on Dragonfly Protocol
   Dragonfly is a PAKE protocol that is used to exchange session keys between two parties with mutual authentication inside mesh networks. It was defined by Dan [12]. Finite cyclic groups are required to implement dragonfly such as Finite Field Cryptography (FFC) or Elliptic Curve Cryptography (ECC) [17]. This paper implements this protocol by using FFC. A finite field is “a field F that contains a finite number of elements which is the order of F” [18]. More details about finite field are presented in.
   In this section, we will explain the Dragonfly protocol in detail, with the discovered attack on it followed bythe solution which is suggested in [12].

3. The Proposed Solution

This paper proposes a solution to secure the original Dragonfly protocol without the addition of public key in order to keep the execution time as fast as possible. It relies on using two pre-shared passwords instead of one. Here the attacker must search for each N, P in the dictionary. The first password P will be generated in the same way as in the original Dragonfly protocol. This is done by extracting a string from the dictionary and using the

identities of both parties. It has a length of 1024 bits. The generation of the second password N is the same as Pbut with two minor changes; which are based on the extraction of another word from the same dictionary and the use of the identity of the respondent and it has a length of 160 bits instead of 1024.

The enhanced Dragonfly protocol will work according to the following steps:

1. Two passwords will be generated, which are P and N, and will be shared between both parties.

2. Both parties produce scalar and element operations based on choosing one scalar that belongs to Q randomly(r). Then each party will compute his/her scalar (A,B) = r(A,B) + N and element operations E = P – N.

3. Both parties will compute the hash value of E which is E’ = H (E).

4. The first party will compute the hash value A for the parameters E’ and sA. Then A will be sent to the second party with the scalar value of the first party. The second party will verify the hash value A to ensure the authentication process. Here if the hash value is verified then the second party will compute the hash value B and send it to the first party with his/her scalar value SB, otherwise it will be declined. The first party in turn will verify the hash value B. If it is valid then the authentication succeeds.

5. After that each party will calculate the shared secret which is ss = (PsB E)rA

6. Then they create a shared secret key which is K = H(ss|E|(sA + sB) mod q).

The benefits of this solution are: firstly, the attacker will never be able to guess the hash value which includes the hash of the element value that uses the exponent of two-secret values. Secondly, the authentication processoccurs in two rounds rather than four rounds as in the original protocol. This elimination makes the execution process go faster. The steps of enhanced Dragonfly protocol have been displayed in Figure 2.

4.1. Methodology over Protocol Testing

A simulation project has been developed to test the time needed to execute the protocol compared to the patched dragonfly protocol. It was written in Java and maintained in Net Beans. This project has been handled by using 64 bits Windows 8.1 pro-operating system and a processor with the speed 2.38 GHz. This project includes three various classes:

1. Dragonfly: is the main class that has objects from the other two classes and it also has some local variables

such as:

? ID_A, ID_B are identities of initiator and respondent. The identity is the Mac address. For example ID_A =

001CB3098515, ID_B = 001AB3008600.

3) EnhancedDragonfly: is the class that implements the proposed solution. It works as the initiator agent,which is Alice. The respondent agent which is Bob will follow the same steps that are provided by this class.First, a random value rA will be selected from {1,…,q} while q is a Subgroup Order as shown in Table 2. The

passed P and N will be used with rA to calculate Scalar sA, Element E and hash value A. Then these values will be used to calculate the shared secret key. We use MD5 for hash function.

This class includes seven methods:

1. Enhanced Dragonfly is the constructor that takes p_modularandq as parameters.

2. scalar_operation: it is calculating scalar operation that is sA = rA + N

3. element_operation: it is calculating element operation that is E = P N

4. sending_operation: it is used to calculate and send the hash value A

5. verifying_operation: It returns true or false according to the verification of the hash value of the other party.

6. sharedsecret_computation: used to calculate the shared secret key ss, which will be used later in the next equation.

7. sharedkey_computation: returns the secret key in the form of hash value.

The class diagram of this project is displayed in Figure 3, while Figure 4 presents the input and output of Enhanced Dragonfly protocol simulation. The values of important parameters of Enhanced Dragonfly protocol simulation are listed in Table 2.

By applying this simulation, the execution time for one participant was found to be 19 minutes only. This experiment was applied 15 times in order to measure the total execution time of the enhanced Dragonfly protocol and the average of the total time is almost 38 minutes. This result works as a proof for the efficiency of the proposed solution, and the use of two-shared passwords will not affect the time of exchanging the secret keys.

4.2. Testing and Analysis of the Enhanced Dragonfly Protocol

Any protocol should be analyzed in order to see if there are any possible attacks that can occur and find how secure it is. The automatic analysis is the most recent approach which is used in analysis of security protocols and it is more efficient than the manual one. The required time to write the protocol description depends on the

learning of its language. All possible attacks will be tested by the used tool. The automatic analysis will be used in this research. Various tools are used to analyze the security protocols and to check the possibility of any attack can happen when protocol is put to use. An example for this is the Scyther tool which supports the evaluation of protocols with respect to these corruption models which have led to the automatic detection of many attacks that previously could only be found by manual analysis [22].

4.2.1. Description of Scyther Tool and SPDL

Scyther [23] is one of the most efficient analyzing tools compared with other tools [24]. It was found that this tool can discover attacks more efficiently than others and it can also verify protocols with an unlimited numberof sessions. Its run time is also less than others. There are many protocols that have been analyzed by this tool such as IKEv1, IKEv2 protocol suits, ISO/IEC 9798 family of authentication protocols and MQV family of protocols.

The Scyther tool takes the protocol description as input, and outputs a summary report stating whether the claim was true or false, whether any attack was found or not, and optionally, visual graph descriptions in the dot language from the GraphVizlibrary or representations of trace patterns in XML which describe the trace pattern[25]. Additionally, there are a set of Python bindings for the Scyther command-line tool, which provide a convenient means to script Scyther experiments. Figure 5 displays how this tool works.

Security Protocol Description Language (SPDL) is a language that is used in Scyther for writing a protocol[26]. This language is just expressive enough to capture the most relevant security protocols in an abstract way.It allows us to develop high-level reasoning methods and tools, which can be applied to a large class of protocols.SPDL is used to create a definition for existing protocols that use symmetric or asymmetric encryption. It includes three scopes; global scope (the largest scope), protocol scope (smaller than global) and role scope (thesmallest one). Furthermore, it includes the initial knowledge required to execute a role (each agent’s role includessequence of events, such as sending or receiving a message), the declaration of functions, global constants and variables.

4.2.2. SPDL of Enhanced Dragonfly Protocol and Analysis Result

In this sub-section, the SPDL representation of Enhanced Dragonfly protocol will be explained in detail. After that, the findings from this analysis will be discussed. The SPDL code of the enhanced dragonfly is displayed in Figure 6. First of all, a global hash function H1 & H2 has been defined (outside the protocol definition) to make it available to be accessed by all rolls in the protocol. Also, the functions of multiplication mult, addition add,

exponential exp and the inverse inv were defined globally. Function is a special type which defines a function term that can take a list of variables. By default, it behaves like a hash function: given the term H1(x) where H1 is of type Function, it is impossible to derive x. These functions are defined in an abstract way in SPDL, which doesn’t support any real equations.

Next, the protocol description starts with the keyword protocol which takes the role names as parameters.There are three rolls, namely; the key generator center (role KGC), the initiator (role A) and the respondent (role

B):

? Key generator center role KGC [27]: Used here to pass the shared secret password P and N to role A and B. The way of generation, which is used to generate these shared passwords, doesn’t take a place here in the tool because the tool depends on the structure of the protocol only. The shared secret passwords P&N have been identified as constants and their scope is within the protocol because they should be used inside all

roles.

? Initiator role A:

? This role represents the start of the communication to compute the shared secret key. The selection of random

value rA, which is the first step in the protocol structure (see Figure 2) by Alice (initiator), has been

clarified by using the fresh declaration which is used by SPDL to get random values. Nonce is a standard

data type that is often used in Scyther tool.

? The calculation of SA (Scalar value), E (element value), and A1 (hash value) occurs by using the predefined

functions, and then SA and A1 will be sent to role B.

? Note: labels in recv and send need to disambiguate similar occurrences of events in a protocol specification.

In addition, they are used to link each send event with its recv one [28].

? In the received event of role A, the hash value of B and the Scalar value SB will be saved in a Ticket variable,which can be substituted by any term.Role A will verify if these values are from Role B or not by using the match function. The definition of match [29] ensures the new variable assignment equivalent to the old one and it returns true or false. If the returned value is true then the next steps computed, otherwise Role A will conclude that this value is not from the honest agent, and it closes the session.

? The calculation of the secret key needs to be kept in secrecy, so that a claim with the type secret is used. The main idea behind claim events is locality [28] [29]: that a term is not in the adversary knowledge, or any certain role in run. Secrecy means that if an agent communicates with non-compromised agents, the term should be secret in every trace of the protocol. Secrecy expresses that certain information is not revealed to an adversary, even though this data is communicated over an un-trusted network. Here, claim event has been

used to keep session’s key secret and is known to role A only. When the tool runs, it tries to find the corresponding attack to each claim.

? Respondent Role B:

? Generates the random value rB by fresh declaration.

? Calculates the scalar SB, Element E and hash value B1 and sends it to Role A.

? Verifies the received hash value from Role A and compares it by using match function.

If the output of matching is true, then B will calculate the secret session key and claim it with secret type.The SPDL of the protocol is inserted into the Scyther tool to see if any attack could occur or if there is any structural weak point in this proposed protocol. The result of this analysis brings out that there is NO attack found. All roles are verified, which means that no impersonation can occur during the connection and the characteristics of the protocol structure are verified. This means that the way of exchanging the data is totally secure.This result is printed in Figure 7 and Figure 8.

5、Discussion

5.1. Off-Line Attack Simulation

Attack class has been applied to previous simulation projects. This class works by measuring the time taken to check all possible passwords, as dictionary size varies from 100, 1000 to 100,000 words. Each experiment was performed 5 times to find the search time by attack class and the average value was taken. As a result, the average time of this search within the enhanced protocol increased linearly as with increase in the dictionary size. The average time of off-line search when the dictionary length is 10,000 is more than 1.5 days, and with the

original Dragonfly protocol [12] the off-line search algorithm took an average of 25 seconds to find the correct password with the same dictionary length. This is because the enhanced protocol has an exponential relationship between the two-secret passwords in thecomputation of the element variable. Therefore, the attacker will be forced to search for two words instead of one. As a comparison between the time that is required for searching one password and the time required for searching two passwords, this experiment found that the time increased

exponentially. The search of such an attack on the patched Dragonfly protocol requires few days to be successful. However, here the execution time will have an impact on the efficiency of Key exchange technique. Table 3 shows a linear relationship between dictionary size and the time taken to try all passwords.

5.2. Comparison between Enhanced Dragonfly and Patched Dragonfly Protocols

The enhanced Dragonfly protocol is very similar to the patched Dragonfly protocol except for two minor changes. Firstly, the patched protocol uses only one shared password and a public key, while the enhanced protocol uses two-shared passwords. Second, the rounds between the initiator and the respondent are only two rounds in the enhanced protocol while it is four rounds in the patched protocol. However, the patched dragonfly involves some computational cost because it is uses a public key validation which creates large bit operations due to its large size. This can decrease the protocol efficiency and make it less appealing than its competitors[12]. Otherwise, in the enhanced dragonfly protocol, the execution of the protocol will take less time. In order to measure the execution time of the enhanced Dragonfly protocol we used the simulation project to compute the time required by the key generation center that uses dictionary size 10,000 plus the time which required by the

initiator party when execute the required computation of the protocol. The cost of both patched and enhanced Dragonfly protocol for each participant has been placed into Table 4, and based on these time measurements we have observed that the efficiency of using two-shared passwords is more than using the public key.

The limitation of this research is that these results are based on a normal speed machine with the 64 bits Windows 8.1 pro-operating system and a processor with the speed of 2.38 GHz which is not the case in the real time attack. Furthermore, the attacker is likely to significantly shorten the time of exhaustive search by distributing the calculation over several high performance machines.

6Conclusion

In this research we proved that the Dragonfly protocol can be enhanced in a way, other than the public key validation,to make it secure against off-line dictionary attacks. The proposed solution that has been introduced to the original Dragonfly protocol relies on the use of two-shared secret passwords P and N. This solution works by the use of an exponential relationship between these passwords and performing the authentication process in two

rounds only instead of four, which positively affects its efficiency. The use of public key validation, which is proposed in the patched protocol, is causing a computational cost to its execution that makes it less efficient.However, the execution time of the enhanced Dragonfly protocol and the time of an off-line dictionary attack were measured in the developed simulation project. As a result of this simulation, the required time to execute the enhanced protocol for one of the parties was 19 ms, while it was 64 ms in the patched protocol.

一個增強的蜻蜓密鑰交換協(xié)議對離線

字典攻擊

摘 要

蜻蜓的口令認證密鑰交換協(xié)議使用一個共享的會話密鑰進行身份驗證，基于預共享秘密的密碼。據(jù)稱，該協(xié)議是安全的對離線字典攻擊，但一項新的研究已證明離線字典攻擊和證明步驟的漏洞是采用“修補”協(xié)議是基于公共密鑰驗證。不幸的是，這一步在計算成本引發(fā)，使這個協(xié)議比其競爭對手缺乏吸引力。我們提出了把這個協(xié)議沒有任何額外的計算成本，被稱為“增強的蜻蜓”的另一種增強。該解決方案基于預共享密鑰的密碼而不是一輪雙方已經(jīng)壓縮成兩輪而不是四。我們證明了蜻蜓的協(xié)議是安全的離線字典攻擊，利用飛天螳螂工具分析其安全性能。開發(fā)了模擬測量增強協(xié)議的執(zhí)行時間，這被認為是比修補的蜻蜓的執(zhí)行時間少。離線字典攻擊的時間是幾天消耗如果字典的大小是10000。根據(jù)這個，對增強蜻蜓的使用要比修補蜻蜓更有效。

關鍵詞：口令認證密鑰交換（交換）; 原蜻蜓; 打補丁的蜻蜓;

蜻蜓的增強; 兩預共享密碼

1 介紹

如今，信息以更快的速度增加，它需要保護時，它在不安全的網(wǎng)絡交換。為了保護這些信息的最有效方法是密碼是密碼科學的建立與分析。它包括密碼學和密碼分析。密碼是建立密碼和密碼分析是科學分析這些代碼[科學] 1。有兩種類型的密碼：

對稱和非對稱密鑰加密。對稱密鑰密碼體制有一個共享密鑰，加密和解密過程是由發(fā)送者和接收者，而非對稱密鑰加密也用于加密過程和私有密鑰用于解密公鑰的過程。

一種對稱密碼協(xié)議的密鑰交換協(xié)議，允許雙方誰分享非機密信息來計算共享密鑰通過公共通信。認證密鑰交換（阿克）是一個對稱的協(xié)議，不僅使雙方計算共享密鑰并保證當事人身份當事人可以計算共享密鑰只有他/她是一個自稱。另一個例子是對稱協(xié)議的兩方基于口令認證的密鑰交換（2PAKE）協(xié)議，允許雙方產(chǎn)生一個基于預共享密碼和驗證對方會話密鑰。一般來說，PAKE協(xié)議在不同的攻擊類型，主要是被動攻擊和主動攻擊。被動攻擊難以檢測和得到信息發(fā)送當事人之間無需修改信息或破壞資源。主動攻擊使攻擊者修改加密解密的消息或改變的意義創(chuàng)造虛假的流。然而，攻擊的最復雜的類型是字典攻擊，無論是離線或在線。離線字典攻擊使攻擊者記錄信息從協(xié)議成功執(zhí)行的當事人之間的通信進行竊聽。然后攻擊者脫機嘗試所有的密碼和選擇正確的密碼，根據(jù)記錄的信息找到所需要的密碼。與服務器的交互是不需要離線字典攻擊。在線字典攻擊使攻擊者通過嘗試所有的密碼與服務器的互動中找到所需的密碼。

有不同類型的協(xié)議2PAKE協(xié)議。1992，第一2PAKE協(xié)議（稱為加密密鑰交換（EKE））是由 Bellovin和梅利特提出的。自那時以來，許多其他的2PAKE協(xié)議被提出。這一協(xié)議是蜻蜓是由丹哈金斯聲稱此協(xié)議具有抵抗被動攻擊的定義，主動攻擊和離線字典攻擊沒有安全證明。2013，迪倫與馮分析該協(xié)議證明了該協(xié)議的安全性能對主動攻擊和離線字典攻擊有弱點。他們建議補丁蜻蜓作為解決通過添加一個公共密鑰驗證驗證其安全性能。

在修補蜻蜓協(xié)議的主要問題是，它消耗的運算成本增加在協(xié)議執(zhí)行時，公共密鑰的使用，這涉及到一個大的位操作。在本文中，我們介紹了蜻蜓的另一個增強的協(xié)議不使用公共密鑰。提出的解決方案是基于使用兩個預共享密鑰密碼而不是一輪數(shù)，雙方已減少到兩個而不是四個。這一步增加了更多的安全到原蜻蜓協(xié)議而攻擊者將需要超過1.5天的情況下，共享密碼是從一個以大小1000詞典提取執(zhí)行離線攻擊。這一結果已通過仿真項目是由Java編程語言開發(fā)。仿真項目已被用來找出所需的執(zhí)行時間由雙方分享通信。執(zhí)行時間是小于在使用公共密鑰驗證所需的時間。我們也同意用飛天螳螂的工具來分析其安全性能和結構增強蜻蜓協(xié)議的效率。

本文共分部分：2部分介紹了相關的工作；3部分介紹了蜻蜓的協(xié)議的審查；4部分提出了解決方案，同時討論在第5節(jié)。最后，得出的結論是在6節(jié)。這是針對那些有興趣在密碼學和密碼分析領域。

2 相關工作

口令認證密鑰交換（PAKE）協(xié)議已提供安全的通信，起到了至關重要的作用。通常是在密碼學中，有一個協(xié)議的新版本，試圖攻擊該協(xié)議也被釋放，為了衡量抵抗這些攻擊。在研究對spake1和spake2協(xié)議的安全缺陷分析介紹了。發(fā)現(xiàn)這些協(xié)議對密碼的妥協(xié)是脆弱的，模仿和對服務（DOS）攻擊。此外，證明了希區(qū)柯克協(xié)議，使用公鑰加密，不能抵抗密鑰泄露偽裝一時，密鑰泄露（KCI）和離線字典攻擊。為了消除這些缺點，一種新的有效的協(xié)議，設計了基于對稱密鑰交換協(xié)議和多個哈希函數(shù)計算兩方PAKE協(xié)議。公鑰方案已經(jīng)取代了這里的對稱加密，因為后者需要較少的位操作。有許多理論解釋，證明該方案對各種攻擊的安全。它提供了相互身份驗證和保密性等安全屬性的屬性。然而，在計算成本的額外的哈希計算造成略有增加。這可能被視為微不足道的考慮額外的安全屬性和輪數(shù)的效率低。此外，另一個研究介紹了斯皮克的漏洞和EKE協(xié)議和分析由于理論實踐。此外，一個新的PAKE協(xié)議提出了被稱為密碼認證密鑰交換的雜耍（j-pake）。這取決于共享密鑰密碼兩實體和它有兩輪創(chuàng)建一個強之間的共享密鑰。它是基于成熟的原始密碼“零知識證明（ZKP）使人能證明他沒有透露它的離散對數(shù)知識。這一協(xié)議的分析證明，它可以防止離線字典攻擊，限制主動攻擊者猜測每個協(xié)議的執(zhí)行只有一個密碼，提供了保密。它的優(yōu)點是：泄漏用戶密碼保護，它不需要PKI的部署。該協(xié)議是非常有效的根據(jù)既定的原語的使用。

在領域的最新研究PAKE協(xié)議對使用公共密鑰基礎設施（PKI）在認證過程。近年來，園區(qū)已使用RSA加密算法提供了雙方之間的適當?shù)谋Ｃ?。在[ 16 ]提出了一種新的協(xié)議稱為e3pake-rsa，這是基于三方模型，使兩個實體，只需要記住一個humanmemorable RSA方案互相驗證并在可信服務器的幫助大會話密鑰一致的密碼。公共/私人密鑰參數(shù)由客戶而不是一個值得信賴的配送中心的選擇，使得在線認證淘汰的過程。據(jù)預測，該協(xié)議的計算成本將分別根據(jù)兩方rsa-pake。然而，在測試階段，適用于通用的結構，e3pake-rsa協(xié)議的計算成本是一樣的兩方rsa-pake和總輪數(shù)少于這。實際上，這個協(xié)議需要更多的時間來執(zhí)行針對RSA加密方法的使用和長期的位操作，而其他的PAKE協(xié)議（不使用PKI）工作得更快。

3 蜻蜓協(xié)議概述

蜻蜓是一種用來交換會話密鑰的雙方之間的相互認證網(wǎng)格內部網(wǎng)絡交換協(xié)議。它是由丹[定義] 12。有限循環(huán)群都需要實現(xiàn)蜻蜓如有限域密碼（FFC）或橢圓曲線密碼體制（ECC）[ 17 ]。本文采用FFC實施該協(xié)議。有限的領域是“一場F包含有限數(shù)目的元素的順序是F”[ 18 ]。關于有限域的更多詳情。在本節(jié)中，我們將詳細講解蜻蜓的協(xié)議，以發(fā)現(xiàn)攻擊它所遵循的解決方案是在[ 12建議]。

4 提出的解決方案

本文提出了一種解決安全原蜻蜓協(xié)議沒有為公鑰保持執(zhí)行時間盡可能快的加入。它依賴于使用兩個預共享密碼而不是一個。在這里，攻擊者必須尋找每一個N，P在字典。第一個密碼P會產(chǎn)生相同的方式在原蜻蜓協(xié)議。這是通過提取從字典字符串并使用

雙方的身份。它有一個長度為1024位。第二密碼n為兩小變化但相同的產(chǎn)生；這是基于相同的字典和答辯人的身份和使用它有一個長度為160位而不是1024提取的另一個詞。

增強的蜻蜓協(xié)議將按以下步驟的工作：

1）兩個密碼將產(chǎn)生，這是P和N，并將雙方之間的共享。

2）雙方產(chǎn)生標量和單元操作的基礎上選擇一個標量屬于Q隨機（R）。然后，每一方將計算他/她的標量（A，B）= R（A，B）+ N和E = P元素操作–N.

3）雙方將計算出的哈希值E = H（E）。

4）甲方將計算哈希值的參數(shù)E和SA。然后將發(fā)送給乙方與甲方的標量值。乙方將驗證哈希值來保證認證過程。如果哈希值進行驗證，則乙方將計算哈希值B寄給甲方與他/她的標量值某人這里，否則將被拒絕。反過來，甲方將驗證哈希值，如果它是有效的，認證成功。

5）之后，每一方將計算共享密鑰是SS =（PSB E）RA

6）然后創(chuàng)建一個共享密鑰，K = H（SS | E |（SA某人）mod q）。

這種方案的好處是：首先，攻擊者無法猜測的哈希值，包括使用兩個秘密值指數(shù)的元素值的哈希。其次，在兩輪而不是四輪在原協(xié)議的認證processoccurs。這使得執(zhí)行過程更快的消除。增強的蜻蜓協(xié)議的步驟已經(jīng)在圖2中顯示的。

4.1 在協(xié)議測試方法

一個模擬項目已開發(fā)測試需要執(zhí)行協(xié)議相比，修補的蜻蜓協(xié)議的時間。這是寫在Java和保持凈豆。該項目已通過使用64位的Windows 8.1 Pro操作系統(tǒng)處理和與速度2.38 GHz處理器。該項目包括三個不同的類別：

1）蜻蜓：是從其他兩類主要的類，對象，它也有一些局部變量,如：

?id_a，id_b是引發(fā)劑和被申請人的身份。身份是MAC地址。例如id_a =

001cb3098515，id_b = 001ab3008600。

3）enhanceddragonfly：是執(zhí)行方案的類。它作為引發(fā)劑，這是愛麗絲。被告代理這是鮑勃將遵循由這類提供相同的步驟。首先，一個隨機值RA將選自{ 1，……Q }，而Q是一個子群順序如表2所示。的

通過P和N將用于RA計算標量SA，元和散列值，然后將這些值用于共享密鑰計算。我們使用MD5哈希函數(shù)。

這一類包括七種方法：

1）增強的蜻蜓是以p_modularandq作為參數(shù)的構造函數(shù)。

2）scalar_operation：它是計算標量運算，SA RA + N =

3）element_operation：它是計算單元操作，E = P n

4）sending_operation：它是用來計算哈希值并發(fā)送

5）verifying_operation：它返回true或false根據(jù)對方的散列值的驗證。

6）sharedsecret_computation：用來計算共享密鑰的SS，這將會在接下來的方程后用。

7）sharedkey_computation：返回的哈希值形式的密鑰。

這個項目的類關系圖顯示在圖3中，圖4給出了輸入和輸出增強蜻蜓協(xié)議仿真。增強的蜻蜓協(xié)議仿真的重要參數(shù)列于表2。

通過這種模擬，一個參與者的執(zhí)行時間是19分鐘。本實驗應用15次為了測量增強蜻蜓協(xié)議的總執(zhí)行時間和總時間平均約38分鐘。這一結果作為建議的解決方案的效率的一個證明，和兩個共享密碼的使用不會影響的密鑰交換時間。

4.2 蜻蜓的增強協(xié)議測試與分析

任何協(xié)議應進行分析，以查看是否有任何可能的攻擊，可以發(fā)現(xiàn)它是多么的安全。自動分析的最新方法，用于安全協(xié)議分析和它比人工更高效。所需的時間寫協(xié)議的描述取決于

其語言學習。所有可能的攻擊將被用來測試工具。自動分析進行研究。各種工具用于分析安全協(xié)議和檢查任何攻擊的可能性會發(fā)生在協(xié)議投入使用。這方面的一個例子是飛天螳螂的工具支持對這些腐敗模型具有LED的許多攻擊，以前只能通過人工分析[ 22 ]發(fā)現(xiàn)自動檢測協(xié)議的評價。

4.2.1 飛天螳螂的工具和論文描述

任何協(xié)議應進行分析，以查看是否有任何可能的攻擊，可以發(fā)現(xiàn)它是多么的安全。自動分析的最新方法，用于安全協(xié)議分析和它比人工更高效。所需的時間寫協(xié)議的描述取決于其語言學習。所有可能的攻擊將被用來測試工具。自動分析進行研究。各種工具用于分析安全協(xié)議和檢查任何攻擊的可能性會發(fā)生在協(xié)議投入使用。這方面的一個例子是飛天螳螂的工具支持對這些腐敗模型具有LED的許多攻擊，以前只能通過人工分析[ 22 ]發(fā)現(xiàn)自動檢測協(xié)議的評價。

飛天螳螂是一個最有效的分析工具與其他工具相比。結果發(fā)現(xiàn)，這個工具可以發(fā)現(xiàn)攻擊比別人更有效，它也可以與無限數(shù)量的會話驗證協(xié)議。它的運行時間也比別人少。有許多協(xié)議已通過該等工具分析了IKEv2協(xié)議IKEv1，西裝，ISO / IEC 9798系列認證協(xié)議和MQV協(xié)議族的飛天螳螂的工具以協(xié)議描述作為輸入，并輸出報告陳述請求是否是真或假，無論任何攻擊被發(fā)現(xiàn)或沒有，和任選地，從XML描述跟蹤模式[ 25 ]跟蹤模式的graphvizlibrary或表示點可視化圖形描述語言。此外，還有一組Python綁定的飛天螳螂的命令行工具，以腳本飛天螳螂實驗提供了一個方便的方法。圖5顯示了這個工具廠。

安全協(xié)議形式化描述語言（SPDL）是一種用于飛天螳螂寫協(xié)議[ 26 ]語言。這種語言是足夠的表現(xiàn)力，以一種抽象的方式捕捉最相關的安全協(xié)議。它允許我們發(fā)展高層次的推理方法和工具，可以適用于一大類protocols.spdl用于創(chuàng)建現(xiàn)有的協(xié)議，使用對稱和非對稱加密的定義。它包括三個范圍；全球范圍（最大范圍），協(xié)議范圍（小于全球）和作用范圍（最小的一個）。此外，它包括需要執(zhí)行作用的初步知識（事件，每個代理的角色includessequence如發(fā)送或接收消息），聲明函數(shù)，全局常量和變量。

4.2.2 該增強蜻蜓協(xié)議分析結果

在本部分，增強蜻蜓協(xié)議的SPDL表示將詳細解釋。之后，從這個分析的結果進行討論。增強的蜻蜓SPDL代碼顯示在圖6。首先，一個全球性的哈希函數(shù)H1和H2被定義（外部協(xié)議定義）使它可以用在所有卷訪問協(xié)議。同時，多功能的乘法，加法，

定義全局指數(shù)指數(shù)和逆逆。函數(shù)是一種特殊類型，定義了一個函數(shù)，可以把一個變量列表。默認情況下，它的行為像一個哈希函數(shù)：所謂H1（x），H1是類型的函數(shù)，它是不可能得到X的這些功能在幾個抽象的方式定義的，它不支持任何真正的方程。

其次，協(xié)議描述開始，以角色名作為參數(shù)的關鍵詞協(xié)議。有三卷，即；密鑰生成中心（角色KGC），引發(fā)劑（作用）及答辯（角色

B）：

?密鑰生成中心KGC的作用[ 27 ]：用在這里通過共享密鑰密碼P和N的角色A和B的產(chǎn)生方式，它是用來產(chǎn)生這些共享密碼，并不需要一個地方來的工具，因為該工具取決于結構的協(xié)議只。共享密鑰密碼P和N被確定為常數(shù)及其范圍內的協(xié)議，因為他們應該用在所有

角色。

?引發(fā)作用：

?這個角色代表的通信開始計算共享密鑰。隨機選擇

Ra值，這是在協(xié)議結構的第一步（見圖2）由愛麗絲（引發(fā)劑），已

用新鮮的宣言是用該得到的隨機值澄清。目前是一個標準的

數(shù)據(jù)類型，通常用在飛天螳螂的工具。

?SA的計算（標量值），E（元素值），和A1（哈希值）通過使用預定義的發(fā)生

功能，然后SA和A1將被發(fā)送到的作用B.

注：標簽：將需要對類似的事件發(fā)生在一個協(xié)議規(guī)范。

此外，他們是用來連接每個發(fā)送事件的接收一個[ 28 ]。

? 在角色一個接收到的事件，B的哈希值和標量值某人將被保存在一張票的變量，它可以通過任何術語取代。角色將驗證這些值是從角色B或不使用匹配功能?；鸩馵 29 ]確保新變量賦值相當于舊的定義和它返回true或false。如果返回值是真的然后下一步計算，否則作用會得出這樣的結論：這個值是不誠實的經(jīng)紀人，并關閉會話。

? 密鑰的計算需要保密，所以一個類型使用秘密索賠。在索賠事件的主要思想是局部性[ 28 ] [ 29 ]：這一項不在對手的知識，或有一定的作用在運行。保密意味著如果代理與非代理通信術語應該妥協(xié)，在協(xié)議的每一絲秘密。表示一定保密信息不透露給對手，盡管這個數(shù)據(jù)是在不可信的網(wǎng)絡連通。在這里，索賠事件已用于維持會話的關鍵秘密是眾所周知的作用只。該工具運行時，它試圖找到相應的攻擊各有說法。

?答辯角色B：

?生成隨機值Rb新鮮宣言。

?計算標量某人，元和散列值并將其發(fā)送到角色A B1

?驗證收到的散列值的作用并利用匹配函數(shù)。

如果匹配的輸出是正確的，那么B將計算出會話密鑰和索賠與秘密型。該協(xié)議的SPDL插入飛天螳螂的工具以查看是否有任何攻擊可能發(fā)生或是否有在該協(xié)議的任何結構的薄弱點。這個分析的結果提出沒有發(fā)現(xiàn)攻擊。所有的角色都進行了驗證，這意味著沒有模擬可以連接和協(xié)議結構特征發(fā)生了。這意味著交換數(shù)據(jù)的方式是完全安全的。這一結果打印在圖7和圖8。

5 討論

這項研究結果顯示，增強了蜻蜓的協(xié)議是安全的離線字典攻擊和它的批準率由于其執(zhí)行速度。在這一部分中，離線攻擊將發(fā)展為仿真項目中分析時間為攻擊者執(zhí)行他/她的搜索兩個共享密碼的要求。然后，對增強蜻蜓協(xié)議的效率和原/比較修補蜻蜓協(xié)議介紹。

5.1 離線攻擊仿真

攻擊類已應用到以前的模擬項目。這類作品通過測量被檢查所有可能的密碼的時候，字典大小的變化從100，1000到100000個單詞。每個實驗的攻擊類和平均值發(fā)現(xiàn)搜索時間進行了5次了。因此，在字典的大小增加在增強協(xié)議的搜索平均時間線性增加。離線搜索的平均時間當字典長度是10000超過1.5天，并與

原蜻蜓協(xié)議[ 12 ]離線搜索算法平均花費25秒找到正確的密碼字典長度相同。這是因為增強協(xié)議的元變量計算兩密碼指數(shù)之間的關系。因此，攻擊者將不得不尋找兩個而不是一個詞。作為一個比較之間的時間，是尋找一個密碼和搜索兩個密碼所需的時間要求，本實驗發(fā)現(xiàn)時間增加

指數(shù)。這種攻擊對修補的蜻蜓協(xié)議搜索需要幾天才能成功。然而，這里的執(zhí)行時間將會對密鑰交換技術效率的影響。表3顯示了一個線性關系字典大小和時間嘗試所有的密碼。

5.2 蜻蜓，蜻蜓之間增強的修補方案的比較

增強的蜻蜓協(xié)議是補丁的蜻蜓協(xié)議非常相似，除了兩個小的變化。首先，修補協(xié)議僅使用一個共享的密碼和公鑰，而增強的協(xié)議采用兩共享密碼。其次，發(fā)起人與被告之間的輪在增強協(xié)議只有兩輪，而這是在修補協(xié)議四輪。然而，補丁的蜻蜓涉及一些計算成本，因為它是使用一個公共密鑰驗證造成大的位操作由于其大尺寸。這可以減少協(xié)議的效率，使它比其競爭對手[ 12 ]缺乏吸引力。否則，在增強蜻蜓的協(xié)議，該協(xié)議的執(zhí)行將花更少的時間。為了測量采用模擬項目來計算使用字典大小的10000加上所需的時間密鑰生成中心所需時間的增強蜻蜓協(xié)議的執(zhí)行時間引發(fā)劑方在執(zhí)行所需的協(xié)議計算。每個參與者的補丁和增強蜻蜓協(xié)議已經(jīng)被放置在表4的成本，并根據(jù)這些時間的測量我們發(fā)現(xiàn)，使用兩個共享密碼的效率比使用公共密鑰。

本研究的局限性在于，這些結果是基于正常機速與64位Windows 8.1 Pro操作系統(tǒng)和一個2.38 GHz的實時攻擊不是這樣速度的處理器。此外，攻擊者可能會顯著縮短窮舉搜索時間分布的計算在幾個高性能的機器。

6結論

在這項研究中我們證明了蜻蜓協(xié)議可以在增強，比其他的公共密鑰驗證，使其安全的離線字典攻擊。提出的解決方案，已被引入到原蜻蜓協(xié)議依賴于兩個共享秘密的密碼，P和N使用這種解決方案，通過這些密碼和兩執(zhí)行認證過程呈指數(shù)關系的使用輪只而不是四，這正是影響其效率。公共密鑰驗證的使用，這是在修補協(xié)議的提出，是造成其執(zhí)行效率較低，使得計算成本。然而，在開發(fā)的仿真項目進行增強的蜻蜓協(xié)議的執(zhí)行時間和離線字典攻擊的時間。由于這種模擬，所需的時間為一方當事人執(zhí)行增強的協(xié)議是19毫秒，而64毫秒在修補協(xié)議。分別的時間，進行離線字典攻擊是非常接近的時間為字典大小10000攻擊補丁的協(xié)議，這意味著增強協(xié)議的對離線字典攻擊性證明。增強的協(xié)議已經(jīng)用飛天螳螂分析工具分析發(fā)現(xiàn)它是安全的，沒有任何結構上的失敗。我們可以說，增強協(xié)議的可執(zhí)行的蜻蜓在很短的時間，而離線字典攻擊是一種攻擊者耗時的搜索，它需要幾天的時間來完成它。文章來源地址http://www.zghlxwxcb.cn/news/detail-814492.html

到了這里，關于[任務書+論文+PPT+源碼]基于Android與多媒體的英文學習APP的設計與實現(xiàn)的文章就介紹完了。如果您還想了解更多內容，請在右上角搜索TOY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關文章，希望大家以后多多支持TOY模板網(wǎng)！