第一篇:高可用性軟件架構(gòu)設(shè)計(jì)和實(shí)現(xiàn)論文
摘要:硬件冗余可以極大地提高計(jì)算機(jī)應(yīng)用系統(tǒng)的可用性,然而,一旦關(guān)鍵硬件出現(xiàn)故障或數(shù)據(jù)庫(kù)宕機(jī),正在進(jìn)行中的業(yè)務(wù)流程通常會(huì)中斷。探討了一種如何實(shí)現(xiàn)應(yīng)用系統(tǒng)高可用性的軟件架構(gòu)的設(shè)計(jì)方案,以彌補(bǔ)純硬件冗余應(yīng)用系統(tǒng)的不足。
關(guān)鍵詞:高可用性;軟件容錯(cuò);分布式數(shù)據(jù)庫(kù)
在業(yè)內(nèi),計(jì)算機(jī)應(yīng)用系統(tǒng)的可用性定義為計(jì)算機(jī)應(yīng)用系統(tǒng)保持正常運(yùn)行時(shí)間的百分比,通常用表1所示的“9”的個(gè)數(shù)來(lái)劃分可用性的類(lèi)型。
通常,硬件冗余(容錯(cuò)計(jì)算機(jī)、雙機(jī)或多機(jī)集群、磁盤(pán)陣列、SAN等)、數(shù)據(jù)復(fù)制、合理的災(zāi)難備份和恢復(fù)策略都可以極大地提高計(jì)算機(jī)應(yīng)用系統(tǒng)的可用性。正因?yàn)槿绱?,?dāng)前,對(duì)于計(jì)算機(jī)應(yīng)用系統(tǒng)的高可用性、業(yè)務(wù)的可持續(xù)性要求,業(yè)內(nèi)通常以硬件系統(tǒng)的高可用性來(lái)應(yīng)對(duì)或代替。常見(jiàn)的解決方案是雙機(jī)(或多機(jī))集群方案或直接采用容錯(cuò)計(jì)算機(jī)來(lái)保障系統(tǒng)的高可用性,應(yīng)用軟件的設(shè)計(jì)和開(kāi)發(fā)往往僅注重業(yè)務(wù)流程的分析和過(guò)程控制。在這種完全依賴(lài)硬件來(lái)保障整個(gè)系統(tǒng)的可用性的系統(tǒng)里,一旦關(guān)鍵硬件出現(xiàn)故障或數(shù)據(jù)庫(kù)宕機(jī),正在進(jìn)行中的業(yè)務(wù)流程(如需較長(zhǎng)執(zhí)行時(shí)間的事務(wù)處理、后臺(tái)批處理過(guò)程等)必然會(huì)中斷,這是因?yàn)殡p機(jī)切換也需要時(shí)間。對(duì)此,應(yīng)用軟件本身并無(wú)多少作為,該類(lèi)業(yè)務(wù)必須等待系統(tǒng)重新恢復(fù)后全部或部分重做。
本文以基于大型數(shù)據(jù)庫(kù)的應(yīng)用系統(tǒng)為例,從“軟件容錯(cuò)”設(shè)計(jì)的概念出發(fā),參考“分布式”數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì),以“系統(tǒng)服務(wù)總線”為核心,給出了一種可行的高可用性軟件架構(gòu)的設(shè)計(jì)方案,可以極大地提高應(yīng)用軟件的可用性和業(yè)務(wù)系統(tǒng)的可持續(xù)性。無(wú)論是傳統(tǒng)的C/S架構(gòu),還是近年來(lái)流行的B/S架構(gòu),本文中給出的設(shè)計(jì)方案都有一定的參考意義。
1軟件結(jié)構(gòu)模型
任何基于大型數(shù)據(jù)庫(kù)的應(yīng)用系統(tǒng),都可以抽象為對(duì)數(shù)據(jù)的“讀”和“寫(xiě)”操作。至于客戶端如何展現(xiàn)“讀”到的數(shù)據(jù),以及“客戶端”與“服務(wù)端”基于何種通信協(xié)議通信,不在本文討論之列。
軟件結(jié)構(gòu)的設(shè)計(jì)其實(shí)就是針對(duì)“讀”和“寫(xiě)”的一系列流程的設(shè)計(jì)。如何最大限度地保證系統(tǒng)中的所有“硬件”和“軟件”協(xié)同工作,正確完成每一次“讀”和“寫(xiě)”的操作,也就是對(duì)系統(tǒng)“高可靠性”和“高可用性”的要求。
圖1是基于“軟件容錯(cuò)”和“分布式數(shù)據(jù)庫(kù)系統(tǒng)”的原理,并參照了計(jì)算機(jī)“總線”的工作原理給出的一種基于分布式數(shù)據(jù)庫(kù)或文件系統(tǒng)的高可用性的軟件架構(gòu)設(shè)計(jì)方案。系統(tǒng)采用3層架構(gòu):客戶端、中間應(yīng)用層和數(shù)據(jù)庫(kù)層。
2系統(tǒng)設(shè)計(jì)
2.1數(shù)據(jù)庫(kù)配置為了更清楚地闡述本文的設(shè)計(jì)方案,先對(duì)數(shù)據(jù)庫(kù)的配置及其功能進(jìn)行描述。本系統(tǒng)中,數(shù)據(jù)庫(kù)按角色可劃分為如下三類(lèi)數(shù)據(jù)庫(kù):控制數(shù)據(jù)庫(kù)(COTROLL DB)、日志數(shù)據(jù)庫(kù)(LOG DB)、業(yè)務(wù)數(shù)據(jù)庫(kù)(BUS DB_N)。
2.1.1控制數(shù)據(jù)庫(kù)
控制數(shù)據(jù)庫(kù)也可以是一個(gè)或多個(gè)系統(tǒng)控制(參數(shù))文件。它存放要訪問(wèn)的目標(biāo)數(shù)據(jù)庫(kù)的節(jié)點(diǎn)(N)、端口、用戶、文件頭、表、視圖等信息;存放對(duì)節(jié)點(diǎn)、業(yè)務(wù)數(shù)據(jù)庫(kù)、表或視圖的授權(quán)或訪問(wèn)控制信息;目標(biāo)數(shù)據(jù)庫(kù)(或文件)的當(dāng)前狀態(tài)(聯(lián)機(jī)/脫機(jī)、忙/空閑等);目標(biāo)數(shù)據(jù)庫(kù)中的表或視圖的當(dāng)前狀態(tài)(聯(lián)機(jī)/脫機(jī)、忙/空閑、加鎖/解鎖等)。
2.1.2日志數(shù)據(jù)庫(kù)
日志數(shù)據(jù)庫(kù)獨(dú)立于業(yè)務(wù)數(shù)據(jù)庫(kù)之外,用于記錄客戶端節(jié)點(diǎn)信息、請(qǐng)求時(shí)刻和發(fā)來(lái)的所有請(qǐng)求的原始內(nèi)容,但不做業(yè)務(wù)流程相關(guān)的處理、運(yùn)算等。記錄每次數(shù)據(jù)操作分配的唯一的“事件號(hào)”(EVENT_ID)。對(duì)每一次客戶端的“請(qǐng)求”,“系統(tǒng)服務(wù)總線”(SYSSRV)會(huì)分配唯一的標(biāo)識(shí)符號(hào),可以定義為有一定意義的字符串,比如,“當(dāng)前時(shí)刻+流水號(hào)”。以上信息可以被壓縮、打包、加密后存放,以記錄格式保存于數(shù)據(jù)庫(kù)的表或文件中。它可以設(shè)計(jì)為數(shù)據(jù)庫(kù)中的一個(gè)或多個(gè)表,也可以是文件格式。
2.1.3業(yè)務(wù)數(shù)據(jù)庫(kù)
業(yè)務(wù)數(shù)據(jù)庫(kù)記錄所有業(yè)務(wù)相關(guān)的數(shù)據(jù)信息。所有業(yè)務(wù)數(shù)據(jù)庫(kù)的相關(guān)業(yè)務(wù)邏輯的數(shù)據(jù)結(jié)構(gòu)相同,即,N個(gè)節(jié)點(diǎn)的業(yè)務(wù)數(shù)據(jù)庫(kù)中與業(yè)務(wù)模式相關(guān)的表、視圖、過(guò)程或其他程序設(shè)置相同。
需要特別指出的是:
(1)控制數(shù)據(jù)庫(kù)、日志數(shù)據(jù)庫(kù)和業(yè)務(wù)數(shù)據(jù)庫(kù)可以是不同數(shù)據(jù)庫(kù)廠家或品牌的產(chǎn)品。比如,日志數(shù)據(jù)庫(kù)可以采用低端的數(shù)據(jù)庫(kù)產(chǎn)品或開(kāi)源數(shù)據(jù)庫(kù)系統(tǒng),業(yè)務(wù)數(shù)據(jù)庫(kù)可以采用高端的大型數(shù)據(jù)庫(kù)產(chǎn)品。
(2)控制數(shù)據(jù)庫(kù)、日志數(shù)據(jù)庫(kù)和業(yè)務(wù)數(shù)據(jù)庫(kù)在物理上和邏輯上是可以相互隔離的,這可以極大地提高系統(tǒng)的整體安全性。目標(biāo)數(shù)據(jù)庫(kù)和要訪問(wèn)的表或視圖對(duì)客戶端來(lái)說(shuō)是“不可見(jiàn)”的,由控制數(shù)據(jù)庫(kù)動(dòng)態(tài)定義和控制。
(3)所有類(lèi)別的數(shù)據(jù)庫(kù)在物理上位于一個(gè)或多個(gè)節(jié)點(diǎn)上,即節(jié)點(diǎn)N>=1;任意一個(gè)節(jié)點(diǎn)N上建有一個(gè)或多個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)(邏輯數(shù)據(jù)庫(kù)>=1);任意一個(gè)節(jié)點(diǎn)是一個(gè)完整的、可獨(dú)立工作的計(jì)算機(jī)。根據(jù)性能要求,可以是高性能PC機(jī)、PC服務(wù)器、小型機(jī)、集群或超級(jí)計(jì)算機(jī),或是它們的“混合體”;任意一個(gè)節(jié)點(diǎn)是指定網(wǎng)絡(luò)中的一個(gè)指定節(jié)點(diǎn)。
2.2應(yīng)用層設(shè)計(jì)
中間應(yīng)用層由5個(gè)后臺(tái)進(jìn)程構(gòu)成:(1)系統(tǒng)服務(wù)總線(SYSSRV);(2)數(shù)據(jù)庫(kù)寫(xiě)進(jìn)程(DBWRT_N);(3)數(shù)據(jù)庫(kù)讀進(jìn)程(DBRED_N);(4)數(shù)據(jù)庫(kù)在線恢復(fù)進(jìn)程(DBRCY);(5)日志檢查進(jìn)程(LOGCHK)。
2.2.1系統(tǒng)服務(wù)總線
這是一個(gè)后臺(tái)監(jiān)聽(tīng)、分發(fā)、調(diào)度總進(jìn)程。設(shè)計(jì)目標(biāo)具有一定的“自我修復(fù)”和“自我復(fù)制”動(dòng)能。它可以根據(jù)負(fù)載情況,自我復(fù)制或開(kāi)啟子進(jìn)程響應(yīng)新的負(fù)載;可以動(dòng)態(tài)配置可服務(wù)的節(jié)點(diǎn)或客戶端;可以為特定節(jié)點(diǎn)或客戶端指定專(zhuān)用進(jìn)程;它通過(guò)“DBWRT”和“DBRED”“讀/寫(xiě)”日志數(shù)據(jù)庫(kù)或日志文件。
2.2.2寫(xiě)進(jìn)程
寫(xiě)進(jìn)程負(fù)責(zé)向所有節(jié)點(diǎn)寫(xiě)數(shù)據(jù)。它可以配置成多進(jìn)程/單進(jìn)程模式;多進(jìn)程模式,指對(duì)應(yīng)每個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)N都有獨(dú)立的“寫(xiě)”進(jìn)程;單進(jìn)程模式,指對(duì)應(yīng)多個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)只有一個(gè)主進(jìn)程,主進(jìn)程開(kāi)啟多個(gè)線程提供“寫(xiě)”服務(wù)。
2.2.3讀進(jìn)程
讀進(jìn)程負(fù)責(zé)向所有節(jié)點(diǎn)讀數(shù)據(jù),它可以配置成多進(jìn)程/單進(jìn)程模式。多進(jìn)程模式指對(duì)應(yīng)每個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)N都有獨(dú)立的“讀”進(jìn)程,單進(jìn)程模式指對(duì)應(yīng)多個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)只有一個(gè)主進(jìn)程,主進(jìn)程開(kāi)啟多個(gè)線程提供“讀”服務(wù)。
根據(jù)需要,讀進(jìn)程可以配置成:向所有在線節(jié)點(diǎn)并發(fā)讀數(shù)據(jù),返回最快的結(jié)果集,拋棄其他的結(jié)果集,并中斷其他讀進(jìn)程;也可以配置成:隨機(jī)讀某個(gè)節(jié)點(diǎn)的數(shù)據(jù),如果失敗或超時(shí),則再隨機(jī)讀余下的在線節(jié)點(diǎn),直到“讀”成功或失敗;還可以配置成向所有節(jié)點(diǎn)順序讀數(shù)據(jù),過(guò)程類(lèi)似上面“隨機(jī)讀”。
以上“讀寫(xiě)”業(yè)務(wù)數(shù)據(jù)庫(kù)的進(jìn)程,設(shè)計(jì)上支持多種數(shù)據(jù)庫(kù)訪問(wèn)接口,針對(duì)“表”或“視圖”提供統(tǒng)一格式的、標(biāo)準(zhǔn)的、動(dòng)態(tài)的SQL數(shù)據(jù)操作接口和方法,完成對(duì)數(shù)據(jù)庫(kù)中表或視圖的增、刪、改、查和批處理操作。它們可以設(shè)計(jì)為數(shù)據(jù)庫(kù)中的存儲(chǔ)過(guò)程,也可以是C++,Java程序的API或混合體。
2.2.4數(shù)據(jù)庫(kù)在線恢復(fù)進(jìn)程
該進(jìn)程負(fù)責(zé)檢查全部或部分節(jié)點(diǎn)數(shù)據(jù)庫(kù)(包括所有授權(quán)控制數(shù)據(jù)庫(kù)、業(yè)務(wù)數(shù)據(jù)庫(kù)和日志數(shù)據(jù)庫(kù))或文件的工作狀態(tài);檢查數(shù)據(jù)庫(kù)或文件表中數(shù)據(jù)的一致性;將以上檢查結(jié)果寫(xiě)入日志數(shù)據(jù)庫(kù)(或日志文件)。
當(dāng)某個(gè)業(yè)務(wù)數(shù)據(jù)庫(kù)中的表寫(xiě)入失敗時(shí),它負(fù)責(zé)從“日志數(shù)據(jù)庫(kù)”的表或日志文件中讀出原始數(shù)據(jù),接著寫(xiě)入出現(xiàn)問(wèn)題的業(yè)務(wù)數(shù)據(jù)庫(kù)的表中,并檢查結(jié)果?;驈钠渌?jié)點(diǎn)的數(shù)據(jù)庫(kù)中讀相關(guān)數(shù)據(jù)并寫(xiě)入到出現(xiàn)問(wèn)題的業(yè)務(wù)數(shù)據(jù)庫(kù)的表中。
接收外部命令,根據(jù)“時(shí)間點(diǎn)”或“事件號(hào)”從特定時(shí)刻、特定數(shù)據(jù)庫(kù)(包括日志數(shù)據(jù)庫(kù))、特定表恢復(fù)數(shù)據(jù)到特定目標(biāo)數(shù)據(jù)庫(kù)的表或文件。
2.2.5日志檢查進(jìn)程
該進(jìn)程負(fù)責(zé)讀、寫(xiě)日志文件,檢查數(shù)據(jù)操作結(jié)果的一致性。如果不一致,則報(bào)告給“系統(tǒng)服務(wù)總線”,將問(wèn)題數(shù)據(jù)庫(kù)或數(shù)據(jù)庫(kù)中的表、視圖設(shè)置為“離線”狀態(tài)。
3系統(tǒng)實(shí)現(xiàn)
3.1系統(tǒng)初始化啟動(dòng)配置好的后臺(tái)進(jìn)程即完成系統(tǒng)初始化過(guò)程。
3.2數(shù)據(jù)“寫(xiě)”流程
數(shù)據(jù)“寫(xiě)”流程的主要步驟如下:(1)客戶端通過(guò)給定協(xié)議(或混合多種通信協(xié)議)向后臺(tái)“系統(tǒng)服務(wù)總線”發(fā)送“寫(xiě)”請(qǐng)求。
(2)激活“數(shù)據(jù)庫(kù)寫(xiě)進(jìn)程”,將客戶端的“請(qǐng)求”寫(xiě)入“日志數(shù)據(jù)庫(kù)”(或日志文件),并分配一個(gè)唯一的“事件號(hào)”。
(3)“系統(tǒng)服務(wù)總線”查詢(xún)“授權(quán)/控制數(shù)據(jù)庫(kù)”(或/配置文件)得到客戶端請(qǐng)求訪問(wèn)的數(shù)據(jù)存放的目標(biāo)數(shù)據(jù)庫(kù)(或文件)節(jié)點(diǎn)N(或文件存放的節(jié)點(diǎn)N)、端口、用戶、表、文件頭等信息。節(jié)點(diǎn)N可以是多個(gè),即節(jié)點(diǎn)N>=1。
(4)“系統(tǒng)服務(wù)總線”向N個(gè)“數(shù)據(jù)庫(kù)寫(xiě)進(jìn)程”發(fā)送數(shù)據(jù)“寫(xiě)”訪問(wèn)請(qǐng)求,并得到各節(jié)點(diǎn)的返回結(jié)果集。
(5)只要有1個(gè)節(jié)點(diǎn)寫(xiě)入成功,“系統(tǒng)服務(wù)總線”就將寫(xiě)入成功的標(biāo)志發(fā)回客戶端;“數(shù)據(jù)庫(kù)寫(xiě)進(jìn)程”將各節(jié)點(diǎn)的返回結(jié)果狀態(tài)寫(xiě)入“日志數(shù)據(jù)庫(kù)”(或日志文件)中。
(6)“日志監(jiān)控”查詢(xún)“日志數(shù)據(jù)庫(kù)”(或日志文件),比較N個(gè)節(jié)點(diǎn)的寫(xiě)入狀態(tài)。如發(fā)現(xiàn)寫(xiě)錯(cuò)誤、失敗、超時(shí)等狀態(tài),則將該“業(yè)務(wù)數(shù)據(jù)庫(kù)”(或文件、表、視圖)標(biāo)志為“非正常聯(lián)機(jī)數(shù)據(jù)庫(kù)”(或文件、表、視圖不可用)。
(7)激活“數(shù)據(jù)在線恢復(fù)進(jìn)程”,進(jìn)程為“非正常聯(lián)機(jī)數(shù)據(jù)庫(kù)”,則執(zhí)行數(shù)據(jù)庫(kù)數(shù)據(jù)“同步”。在線同步恢復(fù)如失敗,則將該“數(shù)據(jù)庫(kù)”標(biāo)志為“需要DBA維護(hù)”的類(lèi)別,留待DBA或軟件維護(hù)工程師處理。
3.3數(shù)據(jù)“讀”流程
數(shù)據(jù)“讀”流程的主要步驟如下:(1)客戶端通過(guò)給定協(xié)議(或混合多種通信協(xié)議)向后臺(tái)“系統(tǒng)服務(wù)總線”發(fā)送“讀”請(qǐng)求。
(2)激活“寫(xiě)進(jìn)程”,將客戶端的“請(qǐng)求”寫(xiě)入“日志數(shù)據(jù)庫(kù)”(或日志文件),并分配一個(gè)唯一的“事件號(hào)”。
(3)“系統(tǒng)服務(wù)總線”查詢(xún)“授權(quán)/控制數(shù)據(jù)庫(kù)”(或/配置文件)得到客戶端請(qǐng)求訪問(wèn)的數(shù)據(jù)存放的目標(biāo)數(shù)據(jù)庫(kù)節(jié)點(diǎn)N(或文件存放的節(jié)點(diǎn)N)、端口、用戶、表等信息。
節(jié)點(diǎn)N可以是多點(diǎn),即節(jié)點(diǎn)N>=1。
(4)“系統(tǒng)服務(wù)總線”查詢(xún)“授權(quán)/控制數(shù)據(jù)庫(kù)”(或/配置文件)得到可用的、空閑的目標(biāo)數(shù)據(jù)庫(kù)節(jié)點(diǎn)N(或文件存放的節(jié)點(diǎn)N)。
(5)激活“讀進(jìn)程”(或隨機(jī)、或順序)向N個(gè)節(jié)點(diǎn)的“業(yè)務(wù)數(shù)據(jù)庫(kù)”(或文件)發(fā)送數(shù)據(jù)“讀”訪問(wèn)請(qǐng)求,并得到各節(jié)點(diǎn)的返回結(jié)果集。
(6)“系統(tǒng)服務(wù)總線”將最快返回的結(jié)果集發(fā)回客戶端;拋棄其他結(jié)果集,中斷其他讀進(jìn)程。
在本系統(tǒng)的設(shè)計(jì)和實(shí)現(xiàn)中,由于采用了“分布式”數(shù)據(jù)庫(kù)或文件系統(tǒng)部署,只要N個(gè)節(jié)點(diǎn)中至少有一個(gè)節(jié)點(diǎn)的“業(yè)務(wù)數(shù)據(jù)庫(kù)”正常工作,因?yàn)橐粋€(gè)或幾個(gè)“業(yè)務(wù)數(shù)據(jù)庫(kù)”系統(tǒng)(或節(jié)點(diǎn)硬件)故障所引起的業(yè)務(wù)系統(tǒng)的不可持續(xù)性理論上將可以完全避免,因而提高了系統(tǒng)的“容錯(cuò)”性。
由于N個(gè)數(shù)據(jù)庫(kù)同時(shí)在線,且節(jié)點(diǎn)是否可用、空閑等狀態(tài)可實(shí)時(shí)監(jiān)控,這為特定業(yè)務(wù)快速訪問(wèn)和獨(dú)享訪問(wèn)提供了先決條件。如可以指定某特定“業(yè)務(wù)數(shù)據(jù)庫(kù)”僅為某個(gè)或幾個(gè)特定客戶端服務(wù)提供“讀”訪問(wèn)。
因?yàn)樵O(shè)計(jì)了統(tǒng)一、標(biāo)準(zhǔn)的增、刪、改、查的過(guò)程方法或API,前端開(kāi)發(fā)人員甚至不必寫(xiě)任何SQL語(yǔ)句就可以完成對(duì)數(shù)據(jù)庫(kù)中表或視圖的操作,可以大大地縮短編程和調(diào)試時(shí)間。
需要指出的是,雖然“系統(tǒng)服務(wù)總線”具有“自我修復(fù)”和“自我復(fù)制”的特點(diǎn),但因?yàn)椤肮?jié)點(diǎn)”硬件故障或“授權(quán)/控制數(shù)據(jù)庫(kù)”(或/配置文件)或“日志數(shù)據(jù)庫(kù)”故障而引起的全系統(tǒng)不可用依然存在,因此,建議該節(jié)點(diǎn)采用性能好、可靠性高的中、高端服務(wù)器。
第二篇:B-S架構(gòu)論文:基于J2EE的稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)
B/S架構(gòu)論文:基于J2EE的稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)
【中文摘要】隨著信息時(shí)代的到來(lái),為了適應(yīng)全面建設(shè)小康社會(huì)的新形勢(shì)和依法治國(guó)的進(jìn)程,必須全面推進(jìn)依法行政,建設(shè)法治政府。推行行政執(zhí)法責(zé)任制,是推行依法行政的重要舉措。即依法界定執(zhí)法職責(zé),科學(xué)設(shè)定執(zhí)法崗位,規(guī)范執(zhí)法程序;建立公開(kāi)、公平、公正的評(píng)議考核制和執(zhí)法過(guò)錯(cuò)或者錯(cuò)案責(zé)任追究制。為了能夠更好的將稅收?qǐng)?zhí)法責(zé)任制與崗位職責(zé)落實(shí)到各個(gè)單位、責(zé)任人等身上,在各行各業(yè)都廣泛使用計(jì)算機(jī)的信息時(shí)代,稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng)(Tax
Law-Excuting Check Manage System,簡(jiǎn)稱(chēng)TLEC)應(yīng)運(yùn)而生。通過(guò)應(yīng)用稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng),實(shí)現(xiàn)稅務(wù)機(jī)關(guān)管理的現(xiàn)代化,提高工作效率,將大大有利于監(jiān)督稅務(wù)部門(mén)依法行政,規(guī)范稅務(wù)行政執(zhí)法行為,保證國(guó)家稅務(wù)法律法規(guī)的貫徹執(zhí)行;有利于維護(hù)納稅人的合法權(quán)益,改善征納關(guān)系。論文主要從以下四個(gè)方面來(lái)開(kāi)展研究。首先,進(jìn)行前期調(diào)研分析。通過(guò)資料檢索、文獻(xiàn)查閱的方式,了解了稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng)的、國(guó)內(nèi)外的發(fā)展現(xiàn)狀和存在的問(wèn)題,經(jīng)過(guò)總結(jié)分析,提出了本系統(tǒng)開(kāi)發(fā)的意義和研究的內(nèi)容。然后,對(duì)系統(tǒng)進(jìn)行需求分析和設(shè)計(jì)。對(duì)稅收機(jī)關(guān)實(shí)行稅收?qǐng)?zhí)法責(zé)任制總體業(yè)務(wù)流程圖給出了詳細(xì)的分析描述,確定了整個(gè)系統(tǒng)的功能模塊和設(shè)計(jì)原則、設(shè)計(jì)思想。在此基礎(chǔ)上結(jié)合稅收機(jī)關(guān)稅收?qǐng)?zhí)法責(zé)任制考核功能特點(diǎn)及實(shí)際要求,詳細(xì)的設(shè)計(jì)了稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng)的開(kāi)發(fā)方案,系統(tǒng)數(shù)據(jù)流圖和E-R圖
設(shè)計(jì),并對(duì)系統(tǒng)安全和數(shù)據(jù)庫(kù)進(jìn)行相應(yīng)的設(shè)計(jì)。最后,完成了系統(tǒng)的具體實(shí)現(xiàn)工作,包括日常監(jiān)控、執(zhí)法考核、過(guò)錯(cuò)申辯、責(zé)任追究、綜合評(píng)比、執(zhí)法通報(bào)和過(guò)錯(cuò)糾正、統(tǒng)計(jì)查詢(xún)等功能模塊的開(kāi)發(fā)與實(shí)現(xiàn)。
【英文摘要】With the information age, building a moderately prosperous society in order to meet the new situation and the process of the rule of law, we must comprehensively promote administration according to law and building rule of law.Implement the responsibility system of administrative law enforcement is an important measure to implement according to law.That is defined according to the law enforcement responsibilities, the scientific set of law enforcement positions, standardizing law enforcement procedures;an open, fair and impartial law enforcement system and the evaluation by the fault or misjudgments accountability.In order to better law enforcement responsibility with the tax applied to every unit of their duties, responsibilities and other persons who, in all walks of life are widely used computer information age, the tax assessment law enforcement responsibility system(Tax Law-Excuting Check Manage System, referred TLEC)came into being.Assessment through the application of tax law enforcement responsibility system, and the modernization of the tax authority management, improve efficiency, will
contribute greatly to the tax department of supervision according to law, standardize tax administration law enforcement, to ensure national implementation of tax laws and regulations;be conducive to safeguarding taxpayer legitimate rights and interests, improve relations between tax collectors and taxpayers.The thesis is mainly from the following aspects of the work done for exposition and show.First, the preliminary investigation and analysis.Through information retrieval, document inspection, to understand the tax assessment system of accountability of law enforcement background, present situation and development of domestic and international problems through the summary analysis, the significance of this system development and research content.Then, the system requirements analysis and design.The tax authorities on the implementation of the overall business tax enforcement responsibility flow chart gives a detailed description of the analysis to determine the function modules and the whole system design principles, design.On this basis, combined with the tax authorities of tax law enforcement responsibility system features and the actual assessment requirements, detailed design assessment of tax law enforcement responsibility system development program, the system data flow diagram and ER
diagram design, and the corresponding security and database design.Finally, the complete realization of the system, including daily monitoring, law enforcement assessment, fault defense, accountability, comprehensive assessment, law enforcement notification and fault correction, statistical inquiry function module development and implementation.【關(guān)鍵詞】B/S架構(gòu) MVC 稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng) J2EE 【英文關(guān)鍵詞】B / S structureMVCTax Law-Excuting Check Manage SystemJ2EE
【目錄】基于J2EE的稅收?qǐng)?zhí)法責(zé)任制考核系統(tǒng)的設(shè)計(jì)與實(shí)現(xiàn)摘要4-5
ABSTRACT5-6
11-13
第一章 緒論11-161.1.1 研究背景11
1.1 1.1.2 1.3 本論
1.5
課題研究背景與目的研究目的11-13文的主要工作及目標(biāo)本章小結(jié)15-1616-23
1.2 國(guó)內(nèi)外研究現(xiàn)狀13-1414-15
1.4 論文組織結(jié)構(gòu)15
第二章 理論基礎(chǔ)及相關(guān)知識(shí)
2.2 稅收?qǐng)?zhí)法責(zé)
2.1 稅收?qǐng)?zhí)法責(zé)任制的概念16
任制的考核16-171718-191921-2223-34
2.3 稅收?qǐng)?zhí)法責(zé)任制的考核系統(tǒng)
2.4.1 MVC 設(shè)計(jì)模式
2.4.3 MVC 的優(yōu)點(diǎn)2.6 ORACLE 數(shù)據(jù)庫(kù)系統(tǒng)第三章 系統(tǒng)需求分析23-26
3.2 系統(tǒng)子模塊
2.4 MVC 模式17-19
2.4.2 MVC 的處理過(guò)程192.5 J2EE 架構(gòu)概述19-212.7 本章小結(jié)22-233.1 系統(tǒng)功能需求分析
需求分析26-3226-2829-30313232-3334-72架構(gòu)35-36設(shè)計(jì)36-38控40控41-42稿錄入43-4445-4647-5350-515253-58
3.2.1 日常監(jiān)控263.2.2 執(zhí)法考核3.2.4 責(zé)任追究3.2.6 執(zhí)法考核通報(bào)
3.2.3 過(guò)錯(cuò)申辯28-293.2.5 綜合評(píng)比30-313.2.7 過(guò)錯(cuò)糾正31-323.2.9 幫助
3.2.8 統(tǒng)計(jì)查詢(xún)
3.3 系統(tǒng)的性能需求分析
第四章 系統(tǒng)設(shè)計(jì)
4.2 系統(tǒng)的應(yīng)用體系
4.4 系統(tǒng)功能4.5.1 分單位監(jiān)4.5.3 分過(guò)錯(cuò)行為監(jiān)4.6.1 人工考核底4.6.3 考核設(shè)置
3.4 本章小結(jié)33-344.1 系統(tǒng)設(shè)計(jì)原則34-35
4.3 系統(tǒng)的技術(shù)體系結(jié)構(gòu)364.5 日常監(jiān)控模塊38-42
4.5.2 分責(zé)任人監(jiān)控40-414.6 執(zhí)法考核模塊42-47
4.6.2 自動(dòng)考核44-45
4.6.4 考核撤消46-474.7.1 申辯申請(qǐng)49-50
4.7 過(guò)錯(cuò)申辯模塊4.7.2 調(diào)查報(bào)告
4.7.4 申辯調(diào)整4.8 責(zé)任追究模塊4.8.2 制作追究處
4.8.4 責(zé)任追4.9.1 系統(tǒng)數(shù)據(jù)
4.9.3
4.7.3 申辯處理決定書(shū)51-524.7.5 過(guò)錯(cuò)申辯文書(shū)打印52-534.8.1 追究清冊(cè)生成55-56
4.8.3 追究執(zhí)行57-584.9 數(shù)據(jù)庫(kù)設(shè)計(jì)
58-71
理決定書(shū)56-57究文書(shū)打印58庫(kù)E-R 圖58-60數(shù)據(jù)表設(shè)計(jì)61-71功能實(shí)現(xiàn)72-87
4.9.2 數(shù)據(jù)庫(kù)設(shè)計(jì)原則60-614.10 本章小結(jié)5.1 系統(tǒng)平臺(tái)設(shè)計(jì)
71-7272-75
第五章 系統(tǒng)5.1.1 系統(tǒng)
主機(jī)平臺(tái)設(shè)計(jì)72-7373-74
5.1.2 系統(tǒng)前置機(jī)部署
5.1.4 系統(tǒng)據(jù)庫(kù)
5.1.3 系統(tǒng)應(yīng)用服務(wù)器部署
服務(wù)器74-7575-76
5.2 系統(tǒng)開(kāi)發(fā)方法及開(kāi)發(fā)環(huán)境介紹
5.3.1
5.3 用戶權(quán)限控制(UPC)的配置76-77
5.3.2 UPC 配置的基本流程
77-78
UPC 系統(tǒng)主要組成76-77術(shù)7778-80監(jiān)控80-8283-8486-87置87-8890-9292-9393-94致謝96-97
5.4 系統(tǒng)業(yè)務(wù)邏輯層實(shí)現(xiàn)5.4.2 實(shí)現(xiàn)實(shí)例77-78
5.4.1 實(shí)現(xiàn)技
5.5 系統(tǒng)數(shù)據(jù)訪問(wèn)層實(shí)現(xiàn)
5.6.1 日常
5.6 系統(tǒng)各功能模塊的實(shí)現(xiàn)80-86
5.6.2 執(zhí)法考核82-835.6.4 責(zé)任追究84-86第六章 系統(tǒng)驗(yàn)證測(cè)試87-956.2 功能測(cè)試88-906.4 測(cè)試結(jié)果926.6 回歸測(cè)試936.8 本章小結(jié)94-95
參考文獻(xiàn)97-99
5.6.3 過(guò)錯(cuò)申辯5.7 本章小結(jié)
6.1 測(cè)試環(huán)境與配6.3 系統(tǒng)的完成情況
6.5 缺陷統(tǒng)計(jì)6.7 測(cè)試結(jié)果總結(jié)分析
第七章 總結(jié)95-96攻讀碩士學(xué)位期間已發(fā)表
或錄用的論文99-100
第三篇:[藍(lán)牙] 1藍(lán)牙核心技術(shù)了解(藍(lán)牙協(xié)議架構(gòu)硬件和軟件筆記)
[藍(lán)牙]
1、藍(lán)牙核心技術(shù)了解(藍(lán)牙協(xié)議、架構(gòu)、硬件和軟件
筆記)
聲明:這篇文章是樓主beautifulzzzz學(xué)習(xí)網(wǎng)上關(guān)于藍(lán)牙的相關(guān)知識(shí)的筆記,其中比較多的受益于xubin341719的藍(lán)牙系列文章,同時(shí)還有其他網(wǎng)上作者的資料。由于有些文章只做參考或統(tǒng)計(jì)不足,如涉及版權(quán)請(qǐng)?jiān)谙旅媪粞詞。同時(shí)我也在博客分類(lèi)中新建一個(gè)藍(lán)牙通信分類(lèi),用來(lái)研究分享藍(lán)牙相關(guān)技術(shù)。
下載連接:Bluetooth PROFILE SPECIFICATIONS(基本涵蓋所有藍(lán)牙協(xié)議)、buletooth core 2.1-4.0 SPECIFICATION(三藍(lán)牙版本的核心協(xié)議v2.1v3.0v4.0)、藍(lán)牙核心技術(shù)與應(yīng)用 馬建倉(cāng) 版(藍(lán)牙協(xié)議相關(guān)初學(xué)者必讀,開(kāi)發(fā)者參考)藍(lán)牙核心技術(shù)概述
(一):藍(lán)牙概述 藍(lán)牙核心技術(shù)概述
(二):藍(lán)牙使用場(chǎng)景
藍(lán)牙核心技術(shù)概述
(三): 藍(lán)牙協(xié)議規(guī)范(射頻、基帶鏈路控制、鏈路管理)
藍(lán)牙核心技術(shù)概述
(四):藍(lán)牙協(xié)議規(guī)范(HCI、L2CAP、SDP、RFOCMM)
藍(lán)牙核心技術(shù)概述
(五):藍(lán)牙協(xié)議規(guī)范(irOBEX、BNEP、AVDTP、AVCTP)
有道筆記分享鏈接:http://note.youdao.com/share/?id=950d00cefa9b7fd3c559eec349805b24&type=note
下面是摘抄筆記內(nèi)容:
藍(lán)牙核心技術(shù)概述
(一):藍(lán)牙概述
藍(lán)牙,是一種支持設(shè)備短距離通信(一般10m內(nèi))的無(wú)線電技術(shù)。能在包括移動(dòng)電話、PDA、無(wú)線耳機(jī)、筆記本電腦、相關(guān)外設(shè)等眾多設(shè)備之間進(jìn)行無(wú)線信息交換。利用“藍(lán)牙”技術(shù),能夠有效地簡(jiǎn)化移動(dòng)通信終端設(shè)備之間的通信,也能夠成功地簡(jiǎn)化設(shè)備與因特網(wǎng)Internet之間的通信,從而數(shù)據(jù)傳輸變得更加迅速高效,為無(wú)線通信拓寬道路。藍(lán)牙采用分散式網(wǎng)絡(luò)結(jié)構(gòu)以及快跳頻和短包技術(shù),支持點(diǎn)對(duì)點(diǎn)及點(diǎn)對(duì)多點(diǎn)通信,工作在全球通用的2.4GHz ISM(即工業(yè)、科學(xué)、醫(yī)學(xué))頻段。其數(shù)據(jù)速率為1Mbps。采用時(shí)分雙工傳輸方案實(shí)現(xiàn)全雙工傳輸。
Bluetooth的系統(tǒng)構(gòu)成
1、無(wú)線射頻單元(Radio):負(fù)責(zé)數(shù)據(jù)和語(yǔ)音的發(fā)送和接收,特點(diǎn)是短距離、低功耗。藍(lán)牙天線一般體積小、重量輕,屬于微帶天線。
2、基帶或鏈路控制單元(LinkController):進(jìn)行射頻信號(hào)與數(shù)字或語(yǔ)音信號(hào)的相互轉(zhuǎn)化,實(shí)現(xiàn)基帶協(xié)議和其它的底層連接規(guī)程。
3、鏈路管理單元(LinkManager):負(fù)責(zé)管理藍(lán)牙設(shè)備之間的通信,實(shí)現(xiàn)鏈路的建立、驗(yàn)證、鏈路配置等操作。
4、藍(lán)牙軟件協(xié)議實(shí)現(xiàn):如上圖紫色部分,這個(gè)后面我們做詳細(xì)說(shuō)明。
低耗電藍(lán)牙相關(guān)規(guī)范
(二)藍(lán)牙協(xié)議組成2.1 藍(lán)牙協(xié)議架構(gòu)藍(lán)牙協(xié)議體系中的協(xié)議按SIG的關(guān)注程度分為四層:
1.核心協(xié)議:BaseBand、LMP、L2CAP、SDP;
2.電纜替代協(xié)議:RFCOMM;
3.電話傳送控制協(xié)議:TCS-Binary、AT命令集;
4.選用協(xié)議:PPP、UDP/TCP/IP、OBEX、WAP、vCard、vCal、IrMC、WAE。除上述協(xié)議層外,規(guī)范還定義了主機(jī)控制器接口(HCI),它為基帶控制器、連接管理器、硬件狀態(tài)和控制寄存器提供命令接口。在圖1中,HCI位于L2CAP的下層,但HCI也可位于L2CAP上層。
藍(lán)牙核心協(xié)議由SIG制定的藍(lán)牙專(zhuān)用協(xié)議組成。絕大部分藍(lán)牙設(shè)備都需要核心協(xié)議(加上無(wú)線部分),而其他協(xié)議則根據(jù)應(yīng)用的需要而定。總之,電纜替代協(xié)議、電話控制協(xié)議和被采用的協(xié)議在核心協(xié)議基礎(chǔ)上構(gòu)成了面向應(yīng)用的協(xié)議。
藍(lán)牙協(xié)議棧允許采用多種方法,包括 RFCOMM 和 Object Exchange(OBEX),在設(shè)備之間發(fā)送和接收文件。如果想發(fā)送和接收流數(shù)據(jù)(而且想采用傳統(tǒng)的串口應(yīng)用程序,并給它加上藍(lán)牙支持),那么 RFCOMM 更好。反過(guò)來(lái),如果想發(fā)送對(duì)象數(shù)據(jù)以及關(guān)于負(fù)載的上下文和元數(shù)據(jù),則 OBEX 最好。
藍(lán)牙應(yīng)用程序活動(dòng)圖,如下:
2.1.1 串口仿真RFCOMM介紹 藍(lán)牙—RFCOMM協(xié)議
找到服務(wù),RFCOMM是通過(guò)不同的頻道(channel)來(lái)提供不同的Profile的,所以需要找到要用的服務(wù)在設(shè)備上的哪個(gè)頻道上,這是通過(guò)同一個(gè)軟件包里的sdptool來(lái)完成的,就是SDP,服務(wù)發(fā)現(xiàn)協(xié)議
2.2 藍(lán)牙profile 2.2.1 藍(lán)牙profile概述 參考 對(duì)藍(lán)牙profile的理解
從3.0版本開(kāi)始(據(jù)說(shuō)2.1也是支持的?TBD),藍(lán)牙才開(kāi)始支持BluetoothProfile。BluetoothProfile是藍(lán)牙設(shè)備間數(shù)據(jù)通信的無(wú)線接口規(guī)范。想要使用藍(lán)牙無(wú)線技術(shù),設(shè)備必須能夠翻譯特定藍(lán)牙配置文件,配置文件定義了可能的應(yīng)用.藍(lán)牙配置文件表達(dá)了一般行為,藍(lán)牙設(shè)備可以通過(guò)這些行為與其他設(shè)備進(jìn)行通信.藍(lán)牙技術(shù)定義了廣泛的配置文件,描述了許多不同類(lèi)型的使用安全.按藍(lán)牙規(guī)格中提供的指導(dǎo),開(kāi)發(fā)商可創(chuàng)建應(yīng)用程序以用來(lái)與其他符合藍(lán)牙規(guī)格的設(shè)備協(xié)同工作.在最低限度下,各配置文件規(guī)格應(yīng)包含下列主題的相關(guān)信息.① 與其他配置文件的相關(guān)性
② 建議的用戶界面格式
③ 配置文件使用的藍(lán)牙協(xié)議堆棧的特定部分.為執(zhí)行其任務(wù),每個(gè)配置文件都使用堆棧各層上的特定選項(xiàng)和參數(shù).若需要,也可包括必需的服務(wù)記錄概要。ProfilesAPI層則分別對(duì)Audio、Data、Control等提供了不同的模塊。目前已規(guī)范有四大類(lèi)、十三種協(xié)議規(guī)格。
Bluetooth的一個(gè)很重要特性,就是所有的Bluetooth產(chǎn)品都無(wú)須實(shí)現(xiàn)全部的Bluetooth規(guī)范。為了更容易的保持Bluetooth設(shè)備之間的兼容,Bluetooth規(guī)范中定義了Profile。Profile定義了設(shè)備如何實(shí)現(xiàn)一種連接或者應(yīng)用,你可以把Profile理解為連接層或者應(yīng)用層協(xié)議。
? 常用的profile介紹請(qǐng)參考“藍(lán)牙Profile的概念和常見(jiàn)種類(lèi)”,幾種種最基本的配置文件為:
1.通用訪問(wèn)配置文件(Generic Access Profile, GAP)GAP是所有其他配置文件的基礎(chǔ),它定義了在藍(lán)牙設(shè)備間建立基帶鏈路的通用方法.除此之外,GAP還定義了下列內(nèi)容:
① 必須在所有藍(lán)牙設(shè)備中實(shí)施的功能
② 發(fā)現(xiàn)和鏈接設(shè)備的通用步驟
③ 基本用戶界面術(shù)語(yǔ).GAP確保了應(yīng)用程序和設(shè)備間的高度互操作性,還允許開(kāi)發(fā)人員利用現(xiàn)有的定義更加容易地定義新的配置文件.GAP處理未連接的兩個(gè)設(shè)備間的發(fā)現(xiàn)和建立連接過(guò)程.此配置文件定義了一些通用的操作,這些操作可供引用GAP的配置文件,以及實(shí)施多個(gè)配置文件的設(shè)備使用.GAP確保了兩個(gè)藍(lán)牙設(shè)備可通過(guò)藍(lán)牙技術(shù)交換信息,以發(fā)現(xiàn)彼此支持的應(yīng)用程序.不符合任何其他藍(lán)牙配置文件的藍(lán)牙設(shè)備必須與GAP符合以確保基本的互操作性和共存.2.服務(wù)發(fā)現(xiàn)應(yīng)用配置文件(Service Discovery Application Profile, SDAP)
SDAP描述了應(yīng)用程序如何使用SDP發(fā)現(xiàn)遠(yuǎn)程設(shè)備上的服務(wù).由于GAP的要求,任何藍(lán)牙設(shè)備都應(yīng)能夠連接至其他藍(lán)牙設(shè)備.基于此,SDAP要求任何應(yīng)用程序都應(yīng)當(dāng)能夠發(fā)現(xiàn)它要連接的其他藍(lán)牙設(shè)備上的可用服務(wù).此配置文件可承擔(dān)搜索已知和特定服務(wù)及一般的任務(wù).SDAP涉及了稱(chēng)為“服務(wù)發(fā)現(xiàn)用戶應(yīng)用程序”的一個(gè)應(yīng)用程序,這是藍(lán)牙設(shè)備查找服務(wù)所必需的.此應(yīng)用程序可與向/從其他藍(lán)牙設(shè)備發(fā)送/接收服務(wù)查詢(xún)的SDP相接.SDAP依賴(lài)于GAP,并可以重新使用部分GAP.3.串行端口配置文件(Serial Port Profile, SPP)
SPP定義了如何設(shè)置虛擬串行端口及如何連接兩個(gè)藍(lán)牙設(shè)備.SPP基于ETSI TS 07.10規(guī)格,使用RFCOMM協(xié)議提供串行商品仿真.SPP提供了以無(wú)線方式替代現(xiàn)有的RS-232串行通信應(yīng)用程序和控制信號(hào)的方法.SPP為DUN,FAX,HSP和LAN配置文件提供了基礎(chǔ).此配置文件可以支持最高128kb/s的數(shù)據(jù)率.SPP依賴(lài)于GAP.4.通用對(duì)象交換配置文件(Generic Object Exchange Profile, GOEP)
GOEP可用于將對(duì)象從一個(gè)設(shè)備傳輸?shù)搅硪粋€(gè)設(shè)備.對(duì)象可以是任意的.如:圖片,文檔,名片等.此配置文件定義了兩個(gè)角色:提供拉提或推送對(duì)象位置的服務(wù)器及啟動(dòng)操作的客戶端.使用GOEP的應(yīng)用程序假定鏈路和信道已按GAP的定義建立.GOEP依賴(lài)于串行端口配置文件.GOEP為使用OBEX協(xié)議的其他配置文件提供了通用藍(lán)圖,并為設(shè)備定義了客戶端和服務(wù)器角色.對(duì)于所有的OBEX事務(wù).GOEP規(guī)定應(yīng)由客戶端啟動(dòng)所有事務(wù).但是此配置文件并沒(méi)有描述應(yīng)用程序就如何定義要交換的對(duì)象或如何實(shí)施交換.這些細(xì)節(jié)留給屬于GOEP的配置文件.即OPP,FTP和SYNC去完成.通常使用此配置文件的藍(lán)牙設(shè)備為筆記本電腦,PDA,手機(jī)及智能電話.注意:藍(lán)牙1.1版本規(guī)范所有藍(lán)牙設(shè)備的最小實(shí)現(xiàn)必須支持通用訪問(wèn)配置文件,服務(wù)發(fā)現(xiàn)應(yīng)用配置文件和串行端口配置文件.在兩臺(tái)電腦或者Labtop之間就可以建立這種連接,如下圖所示:
SPP是基于RFCOMM的,spp 協(xié)議處于rfcomm的上層,spp的應(yīng)用需走rfcomm層。如果你使用RFCOMM能夠?qū)崿F(xiàn),那么也就不需要使用SPP,而卻速度還會(huì)比SPP來(lái)做快,因?yàn)槭÷粤瞬捎胮rofile的一些數(shù)據(jù)包頭等。不過(guò),還是推薦采用SPP來(lái)做,兼容性有保證,這也是為什么藍(lán)牙本質(zhì)上數(shù)據(jù)和語(yǔ)音的傳送卻出現(xiàn)HFP,HSP,SPP,OPP等諸多具體應(yīng)用profile的原因。Bluez SPP實(shí)現(xiàn)代碼分析
2.2.2 藍(lán)牙profile框架
每個(gè)attribute屬性被UUID(通用唯一標(biāo)識(shí)符)唯一標(biāo)識(shí),UUID是標(biāo)準(zhǔn)128-bit格式的ID用來(lái)唯一標(biāo)識(shí)信息。attributes 被 ATT 格式化characteristics和services形式進(jìn)行傳送。特征(Characteristics)— 一個(gè)characteristics包含一個(gè)單獨(dú)的value值和0 –n個(gè)用來(lái)描述characteristic 值(value)的descriptors。一個(gè)characteristics可以被認(rèn)為是一種類(lèi)型的,類(lèi)似于一個(gè)類(lèi)。
描述符(descriptor)—descriptor是被定義的attributes,用來(lái)描述一個(gè)characteristic的值。例如,一個(gè)descriptor可以指定一個(gè)人類(lèi)可讀的描述中,在可接受的范圍里characteristic值,或者是測(cè)量單位,用來(lái)明確characteristic的值。服務(wù)(service)—service是characteristic的集合。例如,你可以有一個(gè)所謂的“Heart RateMonitor”service,其中包括characteristic,如“heart rate measurement ”。你可以在 bluetooth.org找到關(guān)于一系列基于GATT的profile和service。
如上圖所示:藍(lán)牙設(shè)備可以包括多個(gè)Profile,一個(gè)Profile中有多個(gè)Service,一個(gè)Service中有多個(gè)Characteristic,一個(gè)Characteristic中包括一個(gè)value和多個(gè)Descriptor。
profile框架和android低功耗藍(lán)牙管理和使用簡(jiǎn)介
2.3 藍(lán)牙4.0和4.1
它們有什么差別?全面解析藍(lán)牙技術(shù)4.0和4.1標(biāo)準(zhǔn) ? 藍(lán)牙4.0實(shí)際是個(gè)三位一體的藍(lán)牙技術(shù),它將傳統(tǒng)藍(lán)牙、低功耗藍(lán)牙和高速藍(lán)牙技術(shù)融合在一起,這三個(gè)規(guī)格可以組合或者單獨(dú)使用。也就是說(shuō) BLE是藍(lán)牙4.0增加的,之前沒(méi)有?(TBD)
藍(lán)牙4.0專(zhuān)門(mén)面向?qū)Τ杀竞凸亩加休^高要求的無(wú)線方案,其主打特性就是省電、省電、省電。極低的運(yùn)行和待機(jī)功耗使得一粒紐扣電池甚至可連續(xù)工作一年之久。它有低功耗、經(jīng)典、高速三種協(xié)議模式。其中:高速藍(lán)牙主攻數(shù)據(jù)交換與傳輸;經(jīng)典藍(lán)牙則以信息溝通、設(shè)備連接為重點(diǎn);低功耗藍(lán)牙以不需占用太多帶寬的設(shè)備連接為主。這三種協(xié)議規(guī)范能夠互相組合搭配,從而適應(yīng)更廣泛的應(yīng)用模式。正因?yàn)橛辛巳N可以互相組合搭配的協(xié)議,藍(lán)牙4.0因此成為唯一一個(gè)綜合協(xié)議規(guī)范。它有著極低的運(yùn)行和待機(jī)功耗。此外,低成本和跨廠商互操作性,3毫秒低延遲、AES-128加密等諸多特色,可以用于計(jì)步器、心律監(jiān)視器、智能儀表、傳感器物聯(lián)網(wǎng)等眾多領(lǐng)域,大大擴(kuò)展藍(lán)牙技術(shù)的應(yīng)用范圍。? 藍(lán)牙4.1主打IOT(Internet Of Things全聯(lián)網(wǎng)),最新的藍(lán)牙4.1標(biāo)準(zhǔn)是個(gè)很有前途的技術(shù),其智能、低功耗、高傳輸速度、連接簡(jiǎn)單的特性將適合用在許多新興設(shè)備上。藍(lán)牙4.1設(shè)備可以同時(shí)作為發(fā)射方和接受方,并且可以連接到多個(gè)設(shè)備上。舉個(gè)例子,智能手表可以作為發(fā)射方向手機(jī)發(fā)射身體健康指數(shù),同時(shí)作為接受方連接到藍(lán)牙耳機(jī)、手環(huán)或其他設(shè)備上。藍(lán)牙4.1使得批量數(shù)據(jù)可以以更高的速率傳輸,當(dāng)然這并不意味著可以用藍(lán)牙高速傳輸流媒體視頻,這一改進(jìn)的主要針對(duì)的還是剛剛興起的可穿戴設(shè)備。例如已經(jīng)比較常見(jiàn)的健康手環(huán),其發(fā)送出的數(shù)據(jù)流并不大,通過(guò)藍(lán)牙4.1能夠更快速地將跑步、游泳、騎車(chē)過(guò)程中收集到。因?yàn)樾聵?biāo)準(zhǔn)加入了對(duì)IPv6專(zhuān)用通道聯(lián)機(jī)的支持,通過(guò)IPv6連接到網(wǎng)絡(luò),實(shí)現(xiàn)與Wi-Fi相同的功能,解決可穿戴設(shè)備上網(wǎng)不易的問(wèn)題。
藍(lán)牙4.0和藍(lán)牙4.1的比較
2.3.1 藍(lán)牙4.0低功耗(BLE)TI低功耗藍(lán)牙(BLE)介紹
① 低功耗藍(lán)牙Bluetooth Low Energy(BLE)是藍(lán)牙4.0增加的。(?TBD),蘋(píng)果系列都支持4.0.② Android4.3(API級(jí)別18)引入內(nèi)置平臺(tái)支持BLE的central角色,同時(shí)提供API和app應(yīng)用程序用來(lái)發(fā)現(xiàn)設(shè)備,查詢(xún)服務(wù),和讀/寫(xiě)characteristics。與傳統(tǒng)藍(lán)牙(ClassicBluetooth)不同,藍(lán)牙低功耗(BLE)的目的是提供更顯著的低功耗。這使得Android應(yīng)用程序可以和具有低功耗的要求BLE設(shè)備,如接近傳感器,心臟速率監(jiān)視器,健身設(shè)備等進(jìn)行通信。③ BLE低功耗藍(lán)牙軟件有2個(gè)主要組成: OSAL操作系統(tǒng)抽象層和 HAL硬件抽象層,多個(gè)Task任務(wù)和事件在OSAL管理下工作,而每個(gè)任務(wù)和事件又包括3個(gè)組成:BLE 協(xié)議棧,profiles和應(yīng)用程序。BLE藍(lán)牙協(xié)議棧結(jié)構(gòu)
附圖1 BLE藍(lán)牙協(xié)議棧結(jié)構(gòu)圖 分為兩部分:控制器和主機(jī)。對(duì)于4.0以前的藍(lán)牙,這兩部分是分開(kāi)的。所有profile(姑且稱(chēng)為劇本吧,用來(lái)定義設(shè)備或組件的角色)和應(yīng)用都建構(gòu)在GAP或GATT之上。下面由結(jié)構(gòu)圖的底層組件開(kāi)始介紹。
附圖 2 BLE低功耗藍(lán)牙系統(tǒng)架構(gòu)圖,圖中的Task用附圖1BLE藍(lán)牙協(xié)議棧結(jié)構(gòu)圖來(lái)描述
通用屬性規(guī)范(GATT)—GATTprofile是一個(gè)通用規(guī)范用于在BLE鏈路發(fā)送和接收被稱(chēng)為“屬性(attributes)”的數(shù)據(jù)片。目前所有的低功耗應(yīng)用 profile都是基于GATT。藍(lán)牙SIG定義了許多profile用于低功耗設(shè)備。Profile(配置文件)是一個(gè)規(guī)范,規(guī)范了設(shè)備如何工作在一個(gè)特定的應(yīng)用場(chǎng)景。注意:一個(gè)設(shè)備可以實(shí)現(xiàn)多個(gè)profile。例如,一個(gè)設(shè)備可以包含一個(gè)心臟監(jiān)測(cè)儀和電池電平檢測(cè)器。
主從機(jī)連接建立過(guò)程:
2.3.2 藍(lán)牙4.0(BLE)主從通信透?jìng)髂K
低功耗藍(lán)牙模塊主透?jìng)鲄f(xié)議是針對(duì)低功耗藍(lán)牙模塊從透?jìng)鲄f(xié)議設(shè)計(jì)的,通過(guò)本協(xié)議模塊可替代手機(jī)設(shè)備與從透?jìng)鲄f(xié)議模塊連接,實(shí)現(xiàn)透?jìng)鞴δ芑蛑彬?qū)控制功能。此協(xié)議模塊可用作從透?jìng)鲄f(xié)議模塊開(kāi)發(fā)過(guò)程中的輔助工具。
BLE主透?jìng)鲄f(xié)議模塊(以下簡(jiǎn)稱(chēng)MTTM)可以工作在透?jìng)髂J剑═TM)或指令模式(CM)。
MTTM上電啟動(dòng)后,處于待機(jī)模式(SBM),此時(shí)處于空閑狀態(tài),無(wú)睡眠,需要用戶通過(guò)AT指令控制模塊連接從設(shè)備。在成功與從設(shè)備建立鏈接后,MTTM會(huì)自動(dòng)查找從設(shè)備的透?jìng)魍ǖ?,如果從設(shè)備屬于BLE從透?jìng)鲄f(xié)議模塊(以下簡(jiǎn)稱(chēng)STTM),MTTM默認(rèn)進(jìn)入透?jìng)髂J剑駝t默認(rèn)進(jìn)入指令模式。
透?jìng)髂J较?,用戶CPU可以通過(guò)模塊的通用串口與STTM進(jìn)行雙向通訊。從MTTM串口輸入的數(shù)據(jù)將轉(zhuǎn)發(fā)到STTM,并從STTM的串口輸出;從STTM輸入的數(shù)據(jù)將轉(zhuǎn)發(fā)到MTTM,并從MTTM的串口輸出,從而實(shí)現(xiàn)透明傳輸功能,用戶數(shù)據(jù)的具體含義由上層應(yīng)用程序自行定義。
透?jìng)髦袛?shù)據(jù)的格式也是profile,或藍(lán)牙標(biāo)準(zhǔn)profile或自定義simple profile?;窘Y(jié)構(gòu)依然是:
1、profile
profile可以理解為一種規(guī)范,一個(gè)標(biāo)準(zhǔn)的通信協(xié)議,它存在于從機(jī)中。藍(lán)牙組織規(guī)定了一些標(biāo)準(zhǔn)的profile,例如 HID OVER GATT,防丟器,心率計(jì)等。每個(gè)profile中會(huì)包含多個(gè)service,每個(gè)service代表從機(jī)的一種能力。
2、service
service可以理解為一個(gè)服務(wù),在ble從機(jī)中,通過(guò)有多個(gè)服務(wù),例如電量信息服務(wù)、系統(tǒng)信息服務(wù)等,每個(gè)service中又包含多個(gè)characteristic特征值。每個(gè)具體的characteristic特征值才是ble通信的主題。比如當(dāng)前的電量是80%,所以會(huì)通過(guò)電量的characteristic特征值存在從機(jī)的profile里,這樣主機(jī)就可以通過(guò)這個(gè)characteristic來(lái)讀取80%這個(gè)數(shù)據(jù)
3、characteristic
characteristic特征值,ble主從機(jī)的通信均是通過(guò)characteristic來(lái)實(shí)現(xiàn),可以 理解為一個(gè)標(biāo)簽,通過(guò)這個(gè)標(biāo)簽可以獲取或者寫(xiě)入想要的內(nèi)容。
4、UUID
UUID,統(tǒng)一識(shí)別碼,我們剛才提到的service和characteristic,都需要一個(gè)唯一的uuid來(lái)標(biāo)識(shí)
每個(gè)從機(jī)都會(huì)有一個(gè)叫做profile的東西存在,不管是上面的自定義的simpleprofile,還是標(biāo)準(zhǔn)的防丟器profile,他們都是由一些列service組成,然后每個(gè)service又包含了多個(gè)characteristic,主機(jī)和從機(jī)之間的通信,均是通過(guò)characteristic來(lái)實(shí)現(xiàn)。
實(shí)際產(chǎn)品中,每個(gè)藍(lán)牙4.0的設(shè)備都是通過(guò)服務(wù)和特征來(lái)展示自己的,服務(wù)和特征都是用UUID來(lái)唯一標(biāo)識(shí)的。一個(gè)設(shè)備必然包含一個(gè)或多個(gè)服務(wù),每個(gè)服務(wù)下面又包含若干個(gè)特征。特征是與外界交互的最小單位。藍(lán)牙設(shè)備硬件廠商通常都會(huì)提供他們的設(shè)備里面各個(gè)服務(wù)(service)和特征(characteristics)的功能,比如哪些是用來(lái)交互(讀寫(xiě)),哪些可獲取模塊信息(只讀)等。比如說(shuō),一臺(tái)藍(lán)牙4.0設(shè)備,用特征A來(lái)描述自己的出廠信息,用特征B來(lái)與收發(fā)數(shù)據(jù)等。
?4.0中profile的存在是干嘛用的呢,只是一種組織形式存在?
服務(wù)和特征都是用UUID來(lái)唯一標(biāo)識(shí)的,UUID的概念如果不清楚請(qǐng)自行g(shù)oogle,國(guó)際藍(lán)牙組織為一些很典型的設(shè)備(比如測(cè)量心跳和血壓的設(shè)備)規(guī)定了標(biāo)準(zhǔn)的service UUID(特征的UUID比較多,這里就不列舉了)4.0 BLE數(shù)據(jù)傳輸可參考下述系列:
藍(lán)牙4.0 BLE 數(shù)據(jù)傳輸
(一)(三)Android Bluetooth 架構(gòu)
1、面向庫(kù)的架構(gòu)視圖
2、面向進(jìn)程的架構(gòu)視圖
參考 藍(lán)牙4.0 For IOS iOS 有兩個(gè)框架支持藍(lán)牙與外設(shè)連接。
一個(gè)是 ExternalAccessory。從ios3.0就開(kāi)始支持,也是在iphone4s出來(lái)之前用的比較多的一種模式,但是它有個(gè)不好的地方,External Accessory需要拿到蘋(píng)果公司的MFI認(rèn)證。另一個(gè)框架則是本文要介紹的CoreBluetooth,在藍(lán)牙4.0出來(lái)之后(注意,硬件上要4s以上,系統(tǒng)要ios6以上才能支持4.0),蘋(píng)果開(kāi)放了BLE通道,專(zhuān)門(mén)用于與BLE設(shè)備通訊(因?yàn)樗腁PI都是基于BLE的)。這個(gè)不需要MFI,并且現(xiàn)在很多藍(lán)牙設(shè)備都支持4.0,所以也是在IOS比較推薦的一種開(kāi)發(fā)方法。現(xiàn)CoreBluetooth在的開(kāi)發(fā)幾乎全部基于該框架,本節(jié)只介紹CoreBluetooth。
1,CoreBluetooth介紹
CoreBluetooth框架的核心其實(shí)是兩個(gè)東西,peripheral和central, 可以理解成外設(shè)和中心。對(duì)應(yīng)他們分別有一組相關(guān)的API和類(lèi),如下圖所示:
如果你要編程的設(shè)備是手機(jī)的central,那么你大部分用到peripheral API。反之亦然,設(shè)備是peripheral,iphone手機(jī)是central,所以將大部分使用central API。使用peripheral編程的例子也有很多,比如像用一個(gè)ipad和一個(gè)iphone通訊,ipad可以認(rèn)為是central,iphone端是peripheral,這種情況下在iphone端就要使用上圖右邊部分的類(lèi)來(lái)開(kāi)發(fā)了。
作為一個(gè)中心(central)要實(shí)現(xiàn)完整的通訊,一般要經(jīng)過(guò)這樣幾個(gè)步驟:(1)建立中心角色—
(2)掃描外設(shè)(discover)(通過(guò)接收從設(shè)備廣播來(lái)掃描、發(fā)現(xiàn)設(shè)備,獲得peripheral ID)—
a, 如果數(shù)據(jù)中已經(jīng)和某些藍(lán)牙設(shè)備綁定,可以使用BluetoothAdapter.getBondedDevices();方法獲得已經(jīng)綁定的藍(lán)牙設(shè)備列表。通過(guò)指定特定的peripheral的UUID,central只會(huì)discover這個(gè)特定的設(shè)備。
b, 搜索周?chē)乃{(lán)牙設(shè)備受用BluetoothAdapter.startDiscovery()方法
c, 搜索到的藍(lán)牙設(shè)備都是通過(guò)廣播返回,so..。需要注冊(cè)廣播接收器來(lái)獲得已經(jīng)搜索到的藍(lán)牙設(shè)備(3)連接外設(shè)(connect)(根據(jù)peripheral ID連接指定的外設(shè))—
(4)掃描外設(shè)中的服務(wù)和特征(discover)(一個(gè)設(shè)備里的服務(wù)和特征往往比較多,一般會(huì)在發(fā)現(xiàn)服務(wù)和特征的回調(diào)里通過(guò)service、characteristic UUID去匹配我們關(guān)心那些)—
(5)與外設(shè)做數(shù)據(jù)交互(explore and interact)—
(6)斷開(kāi)連接(disconnect)。
2, 設(shè)備ID描述DID
每個(gè)與蘋(píng)果設(shè)備兼容的藍(lán)牙接入都必須:支持藍(lán)牙設(shè)備ID描述,1.3版本或者更高;使用藍(lán)牙SIG分配的Assigned Numbers文檔中的公司標(biāo)識(shí)作為他的Vendor ID值,也就是VID,如果生產(chǎn)商沒(méi)有藍(lán)牙SIG公司標(biāo)識(shí),那么藍(lán)牙HID描述接入可能會(huì)使用USB Implementers Forum分配的VID;使用他的VID值來(lái)標(biāo)識(shí)最終的產(chǎn)品生產(chǎn)商;使用版本值來(lái)唯一標(biāo)識(shí)軟件的版本;使用ProductID值唯一標(biāo)識(shí)產(chǎn)品。Device ID描述使得蘋(píng)果產(chǎn)品能夠識(shí)別遠(yuǎn)程的藍(lán)牙接入,該信息可以用來(lái)在與遠(yuǎn)程接入交互的時(shí)候連接藍(lán)牙描述間的交替互操作。因此Device ID中的信息記錄非常重要。
理想情況下,這兩個(gè)設(shè)備應(yīng)該有不同的產(chǎn)品ID。但是,當(dāng)他們擁有完全相同的硬件、軟件和特性的時(shí)候擁有相同的ProductID也是可以允許的。如果他們有任何的不同,就都應(yīng)該有不同的Product ID。
3,IOS的藍(lán)牙低功耗
藍(lán)牙4.0標(biāo)準(zhǔn)引入了藍(lán)牙低功耗,一種針對(duì)有限電池資源的藍(lán)牙接入的無(wú)線技術(shù)。如果支持藍(lán)牙低功耗的話,接入點(diǎn)需要支持下面的這些特性。(這里更多的是藍(lán)牙芯片商要做的事情)
角色
藍(lán)牙接入需要實(shí)現(xiàn)藍(lán)牙4.0標(biāo)準(zhǔn)中定義的外圍角色 廣告通道
藍(lán)牙接入需要在所有三個(gè)廣告通道中針對(duì)每個(gè)廣告事件進(jìn)行廣告 廣告PDU 藍(lán)牙接入需要使用如下廣告PDU中的一個(gè):ADV_IND;ADV_NOCONN_IND;ADV_SCAN_IND。其中ADV_DIRECT_IND不推薦使用。廣告數(shù)據(jù)
由藍(lán)牙接入發(fā)送的廣告信息應(yīng)該至少包含藍(lán)牙4.0標(biāo)準(zhǔn)中包含的如下信息:Flags;TX Power Level;Local Name;Services。如果需要降低電量消耗或者并不是所有的廣告數(shù)據(jù)都適合放入到廣告PDU中的時(shí)候,接入點(diǎn)可能將Local Name和TX Power Level數(shù)據(jù)方知道SCAN_RSP PDU中。需要注意的是根據(jù)它的狀態(tài),蘋(píng)果產(chǎn)品可能不會(huì)總是執(zhí)行激活掃描。主要的服務(wù)應(yīng)該總是放在廣告PDU中進(jìn)行廣告。次要的服務(wù)不應(yīng)該進(jìn)行廣告。對(duì)于接入點(diǎn)不重要的服務(wù)信息可能會(huì)因?yàn)閺V告PDU中的空間不足而被忽略。廣告數(shù)據(jù)和SCAN_RSP PDU中的掃描響應(yīng)數(shù)據(jù)應(yīng)該遵循藍(lán)牙4.0標(biāo)準(zhǔn)中的格式。廣告間隔
藍(lán)牙接入的廣告間隔應(yīng)該慎重考慮,因?yàn)樗麜?huì)影響到發(fā)現(xiàn)和連接的性能。對(duì)于低功耗的接入,電池資源也應(yīng)該被考慮在內(nèi)。為了能夠被蘋(píng)果產(chǎn)品發(fā)現(xiàn),藍(lán)牙接入應(yīng)該首先使用推薦的廣告間隔20ms,并持續(xù)至少30秒。如果在這30秒內(nèi)沒(méi)有被發(fā)現(xiàn),那么接入點(diǎn)可能會(huì)選擇節(jié)省電池電量然后增加廣告間隔,蘋(píng)果推薦使用如下依次延長(zhǎng)的事件間隔來(lái)發(fā)現(xiàn)藍(lán)牙接入點(diǎn):645 ms;768 ms;961 ms;1065 ms;1294 ms 連接參數(shù)
藍(lán)牙接入負(fù)責(zé)用來(lái)LE連接的連接參數(shù)。接入點(diǎn)需要請(qǐng)求合適的連接參數(shù)來(lái)在合適的時(shí)候發(fā)送一個(gè)L2CAP連接參數(shù)跟新請(qǐng)求。如果他沒(méi)有符合如下規(guī)則,那么連接參數(shù)請(qǐng)求可能會(huì)被拒絕:Interval Max *(Slave Latency + 1)≤ 2 seconds;Interval Min ≥ 20 ms;Interval Min + 20 ms ≤ Interval Max;Slave Latency ≤ 4;connSupervisionTimeout ≤ 6 seconds以及Interval Max *(Slave Latency + 1)* 3 < connSupervisionTimeout。蘋(píng)果設(shè)備不會(huì)讀取或者使用Peripheral Preferred Connection Parameters特性中的參數(shù)。隱私
藍(lán)牙接入應(yīng)該在任何情況下都能夠滿足Resovable Private Address。因?yàn)樗诫[方面的考慮,蘋(píng)果設(shè)備將會(huì)使用藍(lán)牙4.0標(biāo)準(zhǔn)中定義的隨機(jī)設(shè)備地址。授權(quán)
藍(lán)牙接入不需要請(qǐng)求特殊的授權(quán),如配對(duì)、認(rèn)證或加密等來(lái)發(fā)現(xiàn)服務(wù)和特性。只有在獲取特性值或者描述值的時(shí)候可能會(huì)需要特殊的授權(quán)。9 配對(duì)
藍(lán)牙接入不應(yīng)該請(qǐng)求配對(duì)。如果處于安全考慮,接入點(diǎn)需要與Central建立綁定關(guān)系,外圍可以使用Insufficient Authentication錯(cuò)誤碼在必要的時(shí)候拒絕ATT請(qǐng)求。因此蘋(píng)果設(shè)備可能會(huì)需要按照既定的安流程程來(lái)執(zhí)行過(guò)程。配對(duì)可能會(huì)需要基于蘋(píng)果產(chǎn)品的用戶認(rèn)證。服務(wù)
通用接入描述服務(wù):藍(lán)牙接入應(yīng)該實(shí)現(xiàn)按照藍(lán)牙標(biāo)準(zhǔn)4.0中的Device Name特性 通用屬性描述服務(wù):只有當(dāng)接入有能力在生命周期內(nèi)更改他的服務(wù)的時(shí)候,該接入點(diǎn)才需要實(shí)現(xiàn)Service Changed特性。蘋(píng)果產(chǎn)品可以使用Service Changed服務(wù)特性來(lái)決定它是否可以使用之前讀取的或者緩存的來(lái)自設(shè)備的信息。設(shè)備信息服務(wù):藍(lán)牙接入應(yīng)該實(shí)現(xiàn)設(shè)備信息服務(wù)。服務(wù)的UUID不應(yīng)該包含在廣告數(shù)據(jù)當(dāng)中。如下的特性需要被支持:Manufacturer Name String;Model Number String;Firmware Revision String;Software Revision String
4,IOS APP開(kāi)發(fā) 的藍(lán)牙操縱API
手機(jī)APP要想獲得藍(lán)牙設(shè)備的一些額外的信息如電量或者操作藍(lán)牙設(shè)備,必須通過(guò)IOS API。那么IOS底層必然有某種方式來(lái)與藍(lán)牙設(shè)備交互。那么電量通過(guò)什么來(lái)讀寫(xiě)呢?自定義 service characteristic?
任何免提的藍(lán)牙耳機(jī)都可以在iOS設(shè)備的狀態(tài)欄中顯示一個(gè)用來(lái)標(biāo)識(shí)他電池電量的圖標(biāo)。這個(gè)特性被所有的iOS設(shè)備所支持,包括iPhone、iPod和iPad。耳機(jī)的藍(lán)牙知識(shí)通過(guò)兩個(gè)iOS藍(lán)牙HFP AT命令:HFP Command AT+XAPL
HFP命令A(yù)T+XAPL 描述:允許通過(guò)耳機(jī)自定義AT命令 發(fā)起者:耳機(jī)
格式:AT+XAPL=[vendorID]-[productID]-[version],[features] 參數(shù):
vendorID: 標(biāo)識(shí)生產(chǎn)商的vendor ID的十六進(jìn)制表示,但是沒(méi)有0x前綴productID: 標(biāo)識(shí)生產(chǎn)生的product ID的十六進(jìn)制表示,但是沒(méi)有0x前綴version: 軟件的版本features: 用10進(jìn)制標(biāo)識(shí)的位標(biāo)識(shí): 1 = 耳機(jī)支持電池電量報(bào)告2 = 耳機(jī)暫?;蛘哒诔潆娖渌当A?/p>
例子: AT+XAPL=ABCD-1234-0100,3響應(yīng): +XAPL=iPhone,[features] HFP命令A(yù)T+IPHONEACCEV 描述:報(bào)告耳機(jī)的狀態(tài)變更發(fā)起者:耳機(jī)格式:AT+IPHONEACCEV=[Number of key/value pairs ],[key1 ],[val1 ],[key2 ],[val2 ],...參數(shù):
Number of key/value pairs : 接下來(lái)參數(shù)的數(shù)量key: 被報(bào)告狀態(tài)變化的類(lèi)型 = 電量等級(jí)2 = 暫停狀態(tài) val: 更改的值
Battery events:0-9之間數(shù)字的字符串 A string value between '0' and '9'.Dock state: 0 = undocked, 1 = docked.Example: AT+IPHONEACCEV=1,1,3
(五)硬件接口
一般藍(lán)牙芯片通過(guò)UART、USB、SDIO、I2S、PcCard和主控芯片通信。如下圖所示,通過(guò)UART和主控芯片通信。
最后叮囑:大家有好的的藍(lán)牙通信的資料鏈接在下面留言分享下~多謝?(^?^*)
第四篇:基于.Net三層架構(gòu)高校戶籍管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)
基于.Net三層架構(gòu)高校戶籍管理系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)
摘 要:為了實(shí)現(xiàn)對(duì)高校戶籍科學(xué)化、規(guī)范化和動(dòng)態(tài)化管理,提出了一種基于.Net三層架構(gòu)技術(shù)的高校戶籍管理系統(tǒng)解決方案,研究了戶籍管理系統(tǒng)數(shù)據(jù)訪問(wèn)層、基本邏輯層和頁(yè)面表示層的設(shè)計(jì)及實(shí)現(xiàn)。實(shí)踐證明了解決方案的有效性。
關(guān)鍵詞:Net;戶籍管理;三層架構(gòu)
中圖分類(lèi)號(hào):TP311.52 文獻(xiàn)標(biāo)識(shí)碼:A 文章編號(hào):1672-7800(2011)09-0071-02 系統(tǒng)業(yè)務(wù)分析??
戶籍管理系統(tǒng)旨在實(shí)現(xiàn)對(duì)高校戶籍的科學(xué)化、規(guī)范化和動(dòng)態(tài)化管理。通過(guò)對(duì)戶籍科相關(guān)人員所做需求分析,該系統(tǒng)必須實(shí)現(xiàn)以下功能:①戶籍信息管理:包括戶籍基本信息管理,教師和學(xué)生戶籍基本信息、相片管理、戶口遷入、遷出、注銷(xiāo)、遷移及借用等信息的增加、刪除和更新;②信息查詢(xún)管理:包括戶籍基本信息查詢(xún)、學(xué)生信息查詢(xún)、戶口遷入、遷出、注銷(xiāo)、遷移及借用信息查詢(xún)等;③收費(fèi)管理:學(xué)生畢業(yè)之后,學(xué)校免費(fèi)保管學(xué)生戶籍兩年,兩年過(guò)后按照一定的標(biāo)準(zhǔn)收取保管費(fèi)用。此模塊主要包括戶籍保管費(fèi)用的收取和退費(fèi)等操作;④操作日志管理:戶籍科操作人員的日常工作無(wú)法量化,收費(fèi)操作需要規(guī)范以避免費(fèi)用的多收、少收、漏收和徇私舞弊的情況的發(fā)生。此模塊將操作人員的所有關(guān)鍵操作記錄在案,以備出現(xiàn)問(wèn)題時(shí),有據(jù)可查;⑤學(xué)院信息管理:此模塊主要包括學(xué)生學(xué)院和專(zhuān)業(yè)信息的增加、刪除、更新和查詢(xún);⑥系統(tǒng)維護(hù):此模塊用來(lái)維護(hù)用戶基本信息、管理員的權(quán)限以及數(shù)據(jù)庫(kù)的安全,防止非授權(quán)用戶對(duì)系統(tǒng)有意或者無(wú)意的破壞。??
系統(tǒng)架構(gòu)??
2.1 系統(tǒng)整體架構(gòu)??
分層應(yīng)用設(shè)計(jì)當(dāng)下非常流行。它對(duì)系統(tǒng)的性能、可擴(kuò)展性、可移植性、安全性等提供了有力的保障。經(jīng)典的分層架構(gòu)開(kāi)發(fā)模式將系統(tǒng)分為3個(gè)層次,即數(shù)據(jù)訪問(wèn)層、基本邏輯層和頁(yè)面表示層。當(dāng)然,每個(gè)層次可能分解為更小的子層次以保證系統(tǒng)功能的合理設(shè)計(jì)。戶籍管理系統(tǒng)的整體架構(gòu)如圖1所示。??
圖1 系統(tǒng)整體架構(gòu)??
2.2 數(shù)據(jù)訪問(wèn)層設(shè)計(jì)??
數(shù)據(jù)訪問(wèn)層負(fù)責(zé)管理數(shù)據(jù)庫(kù)的物理存儲(chǔ)、備份與恢復(fù)。主要包括數(shù)據(jù)庫(kù)的連接與存取操作,即數(shù)據(jù)庫(kù)表的查詢(xún)、更新,增加和刪除操作。數(shù)據(jù)訪問(wèn)層接口對(duì)數(shù)據(jù)訪問(wèn)邏輯進(jìn)行抽象,以此對(duì)不同的數(shù)據(jù)庫(kù)(SQL Server,Oracle等)進(jìn)行統(tǒng)一的管理。通過(guò)封裝類(lèi)調(diào)用數(shù)據(jù)庫(kù)的存儲(chǔ)過(guò)程,同時(shí),上層基本邏輯層提供統(tǒng)一的調(diào)用接口。??
2.3 基本邏輯層設(shè)計(jì)??
基本邏輯層作為整個(gè)系統(tǒng)的邏輯處理中心,主要負(fù)責(zé)管理系統(tǒng)的業(yè)務(wù)邏輯和規(guī)則。系統(tǒng)的邏輯處理都被抽象為本層的不同的邏輯接口。邏輯層接口處于數(shù)據(jù)訪問(wèn)層和頁(yè)面表示層之間,對(duì)上層提供接口調(diào)用,調(diào)用下層數(shù)據(jù)訪問(wèn)層接口連接數(shù)據(jù)庫(kù),而非直接連接數(shù)據(jù)庫(kù),降低了層與層之間的耦合度。修改數(shù)據(jù)訪問(wèn)層的接口實(shí)現(xiàn),不需要修改基本邏輯層代碼。??
2.4 頁(yè)面表示層設(shè)計(jì)??
頁(yè)面表示層負(fù)責(zé)接收界面輸入和邏輯結(jié)果的顯示。包括頁(yè)面的布局、控件的使用等。頁(yè)面表示層調(diào)用基本邏輯層的接口進(jìn)行邏輯處理。系統(tǒng)邏輯處理發(fā)生變化時(shí),只需要修改基本邏輯層接口實(shí)現(xiàn),不會(huì)影響頁(yè)面表示層的編碼。??
數(shù)據(jù)庫(kù)設(shè)計(jì)??
好的數(shù)據(jù)庫(kù)的設(shè)計(jì)是信息系統(tǒng)的一個(gè)重要組成部分。戶籍管理系統(tǒng)涉及到10多個(gè)表的設(shè)計(jì)和60多個(gè)存儲(chǔ)過(guò)程的編寫(xiě)。限于篇幅,這里不一一列出。??
主要技術(shù)及開(kāi)發(fā)工具??
4.1 權(quán)限管理策略??
系統(tǒng)的訪問(wèn)控制策略使用基于用戶角色的訪問(wèn)控制策略。這種訪問(wèn)控制策略已經(jīng)廣泛應(yīng)用于系統(tǒng)操作、數(shù)據(jù)庫(kù)及應(yīng)用項(xiàng)目中。角色訪問(wèn)控制策略有利于確認(rèn)和管理用戶身份,對(duì)不同用戶分配不同的操作權(quán)限。??
4.2 系統(tǒng)安全策略??
為了防止未經(jīng)授權(quán)的用戶訪問(wèn)系統(tǒng)資源,給系統(tǒng)帶來(lái)危害,同時(shí)考慮到戶籍管理系統(tǒng)數(shù)據(jù)錄入時(shí)間一般集中在開(kāi)學(xué)等時(shí)間,大批量的數(shù)據(jù)錄入之后,一旦發(fā)生問(wèn)題,導(dǎo)致數(shù)據(jù)丟失,再次重復(fù)錄入數(shù)據(jù),工作量巨大。系統(tǒng)使用自動(dòng)備份與手工備份相結(jié)合的方式,用戶可以通過(guò)界面,手工備份與恢復(fù)先前的數(shù)據(jù)庫(kù)??紤]到數(shù)據(jù)庫(kù)的移植,在數(shù)據(jù)訪問(wèn)層引入“抽象工廠模式”,根據(jù)數(shù)據(jù)庫(kù)的不同,提供實(shí)現(xiàn)不同數(shù)據(jù)庫(kù)結(jié)構(gòu)的數(shù)據(jù)業(yè)務(wù)邏輯對(duì)象,使用.Net框架的反射機(jī)制,在系統(tǒng)運(yùn)行時(shí)動(dòng)態(tài)決定調(diào)用的數(shù)據(jù)庫(kù)類(lèi)型。??
4.3 并行開(kāi)發(fā)策略??
三層架構(gòu)的優(yōu)勢(shì)之一系統(tǒng)架構(gòu)清晰,合理的分配開(kāi)發(fā)任務(wù),同時(shí)保證系統(tǒng)的并行開(kāi)發(fā),以此提高效率。系統(tǒng)開(kāi)發(fā)過(guò)程中,引入實(shí)體類(lèi)和基本邏輯層和數(shù)據(jù)訪問(wèn)層的共同接口,保證解決方案程序與數(shù)據(jù)庫(kù)的并行開(kāi)發(fā),兩者相關(guān)部分都完成之后,通過(guò)接口,完成數(shù)據(jù)庫(kù)庫(kù)記錄與實(shí)體類(lèi)的映射即可。??
4.4 版本控制策略??
項(xiàng)目開(kāi)發(fā)是一個(gè)團(tuán)隊(duì)協(xié)作,迭代開(kāi)發(fā)的過(guò)程,版本的控制與管理非常重要。項(xiàng)目開(kāi)發(fā)過(guò)程中使用visual svn和tortoise svn進(jìn)行系統(tǒng)解決方案、源代碼的控制,單獨(dú)設(shè)立版本控制服務(wù)器,團(tuán)隊(duì)所有成員從服務(wù)器中更新項(xiàng)目的最新版本,每天工作完成之后,單獨(dú)提交各自負(fù)責(zé)部分的開(kāi)發(fā)工作,使服務(wù)器中的版本始終保持最新?tīng)顟B(tài)。??
4.5 項(xiàng)目開(kāi)發(fā)主要工具??
項(xiàng)目開(kāi)發(fā)成員使用resharper和coding style enforcer工具保證編碼風(fēng)格的統(tǒng)一,使用NUnit,NCoverage等工具結(jié)合cruise control.net每日構(gòu)建技術(shù),進(jìn)行測(cè)試及覆蓋率檢測(cè),保證產(chǎn)品的質(zhì)量。??
結(jié)束語(yǔ)??
戶籍管理系統(tǒng)采用三層架構(gòu)進(jìn)行設(shè)計(jì)、開(kāi)發(fā),系統(tǒng)接口更加清晰,滿足模塊獨(dú)立性,層內(nèi)高內(nèi)聚、層間低耦合的原則,有利于開(kāi)發(fā)者分工合作,具有很強(qiáng)的通用性、可維護(hù)性和可擴(kuò)展性,可以?xún)H作少量修改升級(jí)為Web Service架構(gòu),為系統(tǒng)維護(hù)及功能擴(kuò)展留下足夠的空間。??
參考文獻(xiàn):
[1] HUANG LONGJUN,ZHOU CAIYING,DAI LIPING.Dai Liping.Research and Implementation of E-commerce Platform Based on.NET Framework[Z].Proceeding of the 2009 International Symposium on Web Information System and Application Nanchang,China,May 22-24,2009.[2] 陳友良,盛可軍,王陽(yáng)陽(yáng).基于ASP.NET三層架構(gòu)軟件的研究與開(kāi)發(fā)[J].現(xiàn)代電子技術(shù),2010(6).[3] 江義火.基于ASP.NET MVC2的三層架構(gòu)應(yīng)用系統(tǒng)開(kāi)發(fā)研究與實(shí)現(xiàn)[J].軟件導(dǎo)刊,2010(12).(責(zé)任編輯:周曉輝)
Design and Implementation of College Residence Management
System Based on.Net and Three-tier Architecture
??
Abstract:In order to realize the scientific,standardized and dynamic management of college Residence booklet , a solution based on.Net and three-tier architecture has been proposed, the design and implementation of data access layer,basic logic layer and presentation layer is discussed.Practice has improved that it is a effective solution.Key Words: Dot Net;Residence Management;Three Tier Architecture
第五篇:公交查詢(xún)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)論文
公交查詢(xún)系統(tǒng)設(shè)計(jì)與實(shí)現(xiàn)論文
1引言
隨著城市經(jīng)濟(jì)的發(fā)展、規(guī)模的擴(kuò)大以及人口的增長(zhǎng),城市交通問(wèn)題日益突出。降低出行時(shí)間將使所有的公交利用者產(chǎn)生效益,快速的交通、更好的信息及更好的市場(chǎng)可以提高公交的形象,能夠增加公交乘坐者。城市公共交通運(yùn)輸以其覆蓋面廣、經(jīng)濟(jì)、快捷的特點(diǎn),成為絕大多數(shù)出行者的首選方式,也是各地城市政府大力發(fā)展的一種交通方式。本地市民特別是外來(lái)旅游、出差、就醫(yī)等急需了解本地道路情況的人可以利用本系統(tǒng)方便快捷的查詢(xún)出所有符合他們要求的公交路線,對(duì)他們的出行和生活提供幫助。我國(guó)城市公交乘客信息系統(tǒng)的發(fā)展處于一個(gè)落后的水平,廣大乘客可以獲得信息的方式很少,公交信息的完整性和準(zhǔn)確性得不到保證,而且還沒(méi)有專(zhuān)門(mén)的機(jī)構(gòu)負(fù)責(zé)信息的發(fā)布和管理。出于這個(gè)目的,在老師的指導(dǎo)下,我設(shè)計(jì)了這個(gè)城市公交線路查詢(xún)系統(tǒng)。在對(duì)公交乘客出行心理特征進(jìn)行分析的基礎(chǔ)上,考慮乘客選擇公交線路決策的因素,進(jìn)行程序關(guān)鍵部分的框架設(shè)計(jì)。
現(xiàn)階段,人們的出入方式主要還是來(lái)源于城市公交,特別是對(duì)于那些到外地出差、打工,進(jìn)行商業(yè)有關(guān)或其他事情需要在外地進(jìn)行短暫停留的人而言,公交對(duì)他們是必不可少的,但是對(duì)于那個(gè)不屬于自己所熟悉的城市,坐公交也是一個(gè)很大的難題,因此,開(kāi)發(fā)一個(gè)公交查詢(xún)系統(tǒng)就顯得非常的重要。本系統(tǒng)的核心是對(duì)選擇好的車(chē)次進(jìn)行路線的查詢(xún),或者輸入所要查詢(xún)的車(chē)站名,點(diǎn)擊“查詢(xún)”按鈕,查詢(xún)所有含有該站的車(chē)次及相應(yīng)的??空?。此處既可以“精確查詢(xún)”也可以是“模糊查詢(xún)”,“模糊查詢(xún)”主要方便那些對(duì)站名不是很清楚,但知道其中的一部分的乘客,系統(tǒng)可以幫助他們快速的查出。
1.1論文的研究?jī)?nèi)容
公交查詢(xún)系統(tǒng)是一個(gè)取代過(guò)去由人工查詢(xún)的查詢(xún)系統(tǒng)。本論文論述了一個(gè)基于瀏覽器/服務(wù)器(B/Srowser/Server)模式的公交查詢(xún)系統(tǒng)的研究和實(shí)現(xiàn)的過(guò)程.論文從開(kāi)發(fā)平臺(tái)和工具談起,對(duì)ASP.NET服務(wù)器所提供的組件及其屬性和方法做了一般介紹,更重要的是闡述了ASP.NET的數(shù)據(jù)庫(kù)訪問(wèn)組件ADO.NET的使用方法。最后,詳細(xì)介紹了如何創(chuàng)建“公交查詢(xún)系統(tǒng)”的全部過(guò)程。系統(tǒng)的開(kāi)發(fā)工具與環(huán)境
2.1ASP.NET簡(jiǎn)介
ASP.NET是一種建立在通用語(yǔ)言上的程序構(gòu)架,能被用于一臺(tái)
Web務(wù)器來(lái)建立強(qiáng)大的應(yīng)用程序。ASP.NET提供許多比現(xiàn)在的開(kāi)發(fā)模式強(qiáng)大的的優(yōu)勢(shì)。AS.PNET建立在.NET Framework的編程類(lèi)之上,它提供了一個(gè)web應(yīng)用程序模型,并且包含使生成web應(yīng)用程序變得簡(jiǎn)單的控件集和結(jié)構(gòu)。ASP.NET包含封裝公共用戶界面元素(如文本框和下拉菜單)的控件集。但這些控件在務(wù)器上運(yùn)行,并以HTML的形式將它們的用戶界面推送到瀏覽器。在服務(wù)器上,這些控件公開(kāi)一個(gè)面向?qū)ο蟮木幊棠P?,為web開(kāi)發(fā)人員提供了面向?qū)ο蟮木幊痰呢S富性。ASP.NET還提供結(jié)構(gòu)服務(wù)(如會(huì)話狀態(tài)管理和進(jìn)程回收),進(jìn)一步減少了開(kāi)發(fā)人員必須編寫(xiě)的代碼量并提高了應(yīng)用程序的可靠性。另外,ASP.NET 使用這些同樣的概念使開(kāi)發(fā)人員能夠以服務(wù)的形式交付軟件。使用ML webservices功能ASP.NET開(kāi)發(fā)人員可以編寫(xiě)自己的業(yè)務(wù)邏輯并使ASP.NETT結(jié)構(gòu)通過(guò)SOAP交付該服務(wù)。Visual Studio.NET是一套完整的開(kāi)發(fā)工具,用于生成應(yīng)用程序、XML Web services、桌面應(yīng)用程序和移動(dòng)應(yīng)用程序。Visual Basic.NET、Visual C++.NET、Visual C#.NET和VisualJ#.NET全都使用相同的集成開(kāi)發(fā)環(huán)境(IDE),該環(huán)境允許它們共享工具并有助于創(chuàng)建混合語(yǔ)言解決方案。另外,這些語(yǔ)言利用了.NET Framework的功能,此框架提供對(duì)簡(jiǎn)化應(yīng)用程序和XML Web services 開(kāi)發(fā)的關(guān)鍵技術(shù)的訪問(wèn)。
2.1.1ASP.NET技術(shù)的優(yōu)點(diǎn)
ASP.NET是一種將各種Web元素組合在一起的服務(wù)器技術(shù),是一個(gè)統(tǒng)一的Web開(kāi)發(fā)平臺(tái),它提供了生成一個(gè)完整的Web應(yīng)用程序所必須要的各種服務(wù)。與以前的開(kāi)發(fā)模型相比較,它提供了以下數(shù)個(gè)重要的優(yōu)點(diǎn):
(1)增強(qiáng)的性能。ASP.NET是在服務(wù)器上運(yùn)行的編譯好的公共語(yǔ)言運(yùn)行庫(kù)代碼。與被解釋的前輩不同,.NET可利用早期綁定、實(shí)時(shí)編譯、本機(jī)優(yōu)化和盒外緩存服務(wù)。這相當(dāng)于在編寫(xiě)代碼之前便顯著提高了性能。(2)世界級(jí)的工具支持。ASP.NET框架補(bǔ)充了Visual Studio集成開(kāi)發(fā)環(huán)境中的大量工具箱和設(shè)計(jì)器。WYSIWYG編輯、拖放服務(wù)器控件和自動(dòng)部署只是這個(gè)強(qiáng)大的工具所提供功能中的少數(shù)幾種
(3)威力和靈活性。由于ASP.NET基于公共語(yǔ)言運(yùn)行庫(kù),因此應(yīng)用程序開(kāi)發(fā)人員可以利用整個(gè)平臺(tái)的威力和靈活性。.NET框架類(lèi)庫(kù)、消息處理和數(shù)據(jù)訪問(wèn)解決方案都可從 Web 無(wú)縫訪問(wèn)。ASP.NETT也與語(yǔ)言無(wú)關(guān),所以可以選擇最適合應(yīng)用程序的語(yǔ)言(如C#),或是跨多種語(yǔ)言分割應(yīng)用程序。另外,公共語(yǔ)言運(yùn)行庫(kù)的交互性保證在遷移到ASP.NET時(shí)保留基于COM的開(kāi)發(fā)中的現(xiàn)有投資。(4)簡(jiǎn)易性。ASP.NET使執(zhí)行常見(jiàn)任務(wù)變得容易,從簡(jiǎn)單的窗體提交和客戶端身份驗(yàn)證到部署的站點(diǎn)配置。
(5)可管理性。ASP.NET采用基于文本的分層配置系統(tǒng),簡(jiǎn)化了將設(shè)置應(yīng)用于服務(wù)器環(huán)境和Web應(yīng)用程序。由于配置信息是以純文本形式存儲(chǔ)的,因此可以在沒(méi)有本地管理工具幫助的情況下應(yīng)用新設(shè)置。此“零本地管理”哲學(xué)也擴(kuò)展到了ASP.NET框架應(yīng)用程序的部署。只需將必要的文件復(fù)制到服務(wù)器,即可將ASP.NET框架應(yīng)用程序部署到服務(wù)器。不需要重新啟動(dòng)服務(wù)器,即使是在部署或替換運(yùn)行的編譯代碼時(shí)。
(6)可縮放性和可用性。ASP.NET在設(shè)計(jì)時(shí)考慮了可縮放性,增加了專(zhuān)門(mén)用于在聚集環(huán)境和多處理器環(huán)境中提高性能的功能。另外,進(jìn)程受到ASP.NET 運(yùn)行庫(kù)的密切監(jiān)視和管理,以便當(dāng)進(jìn)程行為不正常(泄漏、死鎖)時(shí),可就地創(chuàng)建新進(jìn)程,以幫助保持應(yīng)用程序始終可用于處理請(qǐng)求。2.1.2.NET Framework概述 NET Framework是用于生成、部署和運(yùn)行XML Web services 和應(yīng)用程序的多語(yǔ)言環(huán)境。它由以下幾個(gè)主要部分組成:
公共語(yǔ)言運(yùn)行庫(kù)
運(yùn)行庫(kù)實(shí)際上在組件的運(yùn)行時(shí)和開(kāi)發(fā)時(shí)操作中都起到很大的作用,盡管名 稱(chēng)中沒(méi)有體現(xiàn)這個(gè)意思。在組件運(yùn)行時(shí),運(yùn)行庫(kù)除了負(fù)責(zé)滿足此組件在其他組件上可能具有的依賴(lài)項(xiàng)外,還負(fù)責(zé)管理內(nèi)存分配、啟動(dòng)和停止線程和進(jìn)程,以及強(qiáng)制執(zhí)行安全策略。在開(kāi)發(fā)時(shí),運(yùn)行庫(kù)的作用稍有變化;由于做了大量的自動(dòng)處理工作(如內(nèi)存管理),運(yùn)行庫(kù)使開(kāi)發(fā)人員的操作非常簡(jiǎn)單,尤其是與今天的COM相比。特別是反射等功能顯著減少了開(kāi)發(fā)人員為將業(yè)務(wù)邏輯轉(zhuǎn) 變?yōu)榭芍赜媒M件而必須編寫(xiě)的代碼量。
統(tǒng)一編程類(lèi)
該框架為開(kāi)發(fā)人員提供了統(tǒng)一的、面向?qū)ο蟮?、分層的和可擴(kuò)展的類(lèi)庫(kù)集(API)。目前,C++開(kāi)發(fā)人員使用Microsoft基礎(chǔ)類(lèi),而Java開(kāi)發(fā)人員使用Windows 基礎(chǔ)類(lèi)。框架統(tǒng)一了這些完全不同的模型并且為Visual Basic和JScript程序員同樣提供了對(duì)類(lèi)庫(kù)的訪問(wèn)。通過(guò)創(chuàng)建跨所有編程語(yǔ)言的公共 API 集,公共語(yǔ)言運(yùn)行庫(kù)使得跨語(yǔ)言繼承、錯(cuò)誤處理和調(diào)試成為可能。從JScript到C++的所有編程語(yǔ)言具有對(duì)框架的相似訪問(wèn),開(kāi)發(fā)人員可以自由選 擇它們要使用的語(yǔ)言。2.2 ADO.NET概述
ADO.NET并不是ADO的升級(jí)版本,它是全新的面向?qū)ο竽P?。比ADO更適應(yīng)于分布式及Internet等大型應(yīng)用程序環(huán)境,為了多人同時(shí)存取更具擴(kuò)展性,ADO.NET的數(shù)據(jù)存取采用的是離線存取模式,可說(shuō)是專(zhuān)門(mén)為.NET臺(tái)設(shè)計(jì)的數(shù)據(jù)存取結(jié)構(gòu)。它具有簡(jiǎn)單地訪問(wèn)關(guān)系數(shù)據(jù)、可擴(kuò)展性、支持多層應(yīng)用程序、統(tǒng)一XML和關(guān)系數(shù)據(jù)訪問(wèn)的特點(diǎn)。ADO.NET的主要目標(biāo)是提供對(duì)關(guān)系數(shù)據(jù)的簡(jiǎn)單訪問(wèn)功能。坦白的說(shuō),易于使用的類(lèi)描述關(guān)系數(shù)據(jù)庫(kù)中的表、列和行。另外,ADO.NET引入了DataSet類(lèi),它代表來(lái)自封裝在一個(gè)單元中的關(guān)聯(lián)表中的一組數(shù)據(jù),維持他們之間完整的關(guān)系。這是在ADO.NET中的新概念,可以顯著的擴(kuò)展數(shù)據(jù)訪問(wèn)接口的功能。ADO.NET可以擴(kuò)展——它為插件.NET 數(shù)據(jù)提供者(也稱(chēng)為可管理提供者)提供了框架,這些提供者被構(gòu)建,以便從任何數(shù)據(jù)源讀取和寫(xiě)入數(shù)據(jù)。ADO.NET提供了兩種內(nèi)置的.NET數(shù)據(jù)提供者,一種用于OLE DB數(shù)據(jù)源,另一種用于Microsoft SQL Server??梢酝ㄟ^(guò)OLE DB訪問(wèn)數(shù)據(jù)格式(比如Microsoft Access)、第三方數(shù)據(jù)庫(kù)和非關(guān)系數(shù)據(jù)另外,Microsoft最近預(yù)演了用于ADO.NET的ODBC.NET數(shù)據(jù)提供者,它允許.NET 訪問(wèn)更多的舊的數(shù)據(jù)格式和第三方數(shù)據(jù)庫(kù)。ADO.NET用于多層應(yīng)用程序。這是當(dāng)今商業(yè)和電子商務(wù)應(yīng)用程序最常見(jiàn)的體系結(jié)構(gòu)。在多層體系結(jié)構(gòu)中,應(yīng)用邏輯的不同部5分1運(yùn)a行s在p多x個(gè)服務(wù)器或進(jìn)程中,每一部分就稱(chēng)為一層。ADO.NET使用開(kāi)放的Internet標(biāo)準(zhǔn)XML格式在層之間通信,允許數(shù)通過(guò)Internet防火來(lái)傳遞,并允許以非Microsoft技術(shù)來(lái)實(shí)現(xiàn)一層或多層。那么在Visual Studio.NET中ADO.NET訪問(wèn)數(shù)據(jù)庫(kù)分為二種。一種是SQL Server 數(shù)據(jù)庫(kù),另一種是其任何類(lèi)型的數(shù)據(jù)庫(kù)。本系統(tǒng)的后臺(tái)數(shù)據(jù)庫(kù)為SQL Server2005,因此是通過(guò)SQLConnection、SqlCommandSqlDataAdapter、DataSet等幾個(gè)主要的數(shù)據(jù)訪問(wèn)對(duì)象來(lái)訪問(wèn)數(shù)據(jù)的.需求分析
3.1系統(tǒng)需求分析
隨著我國(guó)經(jīng)濟(jì)的高速發(fā)展,人們生活水平的提高,越來(lái)越多的人開(kāi)始熱衷于到外地旅游。那么對(duì)于這些外來(lái)旅游者,首先搞清這個(gè)城市的公交路線顯的很重要!我的家鄉(xiāng)沈陽(yáng),作為一個(gè)旅游城市,每年都要吸引大量的游客,為了滿足這些游客熟悉公交路線的需求,特以公交查詢(xún)系統(tǒng)為設(shè)計(jì)課題。本軟件不僅能給游客帶來(lái)方便,也能給廣大市民提供方便。我認(rèn)為這樣的系統(tǒng)應(yīng)該具有很好的實(shí)用性!開(kāi)發(fā)本系統(tǒng)的目標(biāo)就是立足廣大乘客的實(shí)際,著眼于公交業(yè)的未來(lái)發(fā)展,規(guī)范公交管理,提高服務(wù)質(zhì)量,方便乘客查詢(xún),并為此設(shè)計(jì)該系統(tǒng)。人們生活水平的提高,越來(lái)越多人喜歡旅游,但是第一次來(lái)一個(gè)陌生的城市,肯定對(duì)公交路線不熟悉,所以必定需要一個(gè)能查看具體公交線路的公交系統(tǒng)。有些只知道一個(gè)站的某幾個(gè)字或一個(gè)車(chē)次的某幾個(gè)數(shù)字,所以本系統(tǒng)將給出站點(diǎn)的模糊查詢(xún),方便用戶的查詢(xún),有些只知道車(chē)次
或某個(gè)站點(diǎn),本系統(tǒng)也給出了公交線路查詢(xún)、公交站點(diǎn)查詢(xún)、公交換乘查詢(xún),進(jìn)一步方便大家的出行,但也有用戶什么都查不到,想留言問(wèn)問(wèn)人,所以再搞個(gè)留言板很有必要,方便大家交流以及解答各種疑難問(wèn)題!本系統(tǒng)采用結(jié)構(gòu)化設(shè)計(jì)的方法來(lái)實(shí)現(xiàn)系統(tǒng)總體功能,提高系統(tǒng)的各項(xiàng)指標(biāo),即將整個(gè)系統(tǒng)合的劃分成各個(gè)功能模塊,正確地處理模塊之間和模塊內(nèi)部的聯(lián)系以及和數(shù)據(jù)庫(kù)的聯(lián)系,定義各模塊的內(nèi)部結(jié)構(gòu),通過(guò)對(duì)模塊的設(shè)計(jì)和模塊之間關(guān)系的系統(tǒng)來(lái)實(shí)現(xiàn)整個(gè)系統(tǒng)的功能前臺(tái)主要有3個(gè)模塊,線路查詢(xún)、站點(diǎn)查詢(xún)、公交換乘模塊和后臺(tái)管理模塊
功能名稱(chēng):線路查詢(xún)
功能概述:可以獲得要查詢(xún)公交所通過(guò)的各個(gè)站點(diǎn)。
功能名稱(chēng):站點(diǎn)查詢(xún)
功能概述:通過(guò)輸入的指定站點(diǎn)查詢(xún)經(jīng)過(guò)該站點(diǎn)的公交。
功能名稱(chēng):公交換乘查詢(xún)
功能概述:分為公交直達(dá)、公交一次換乘,主要體現(xiàn)那些不可直達(dá)需要轉(zhuǎn)車(chē)的路線的所有換法。(如果用戶輸入的起始點(diǎn)和終點(diǎn),有一條及一條以上的公交線可以直達(dá)的,則為公交直達(dá);如果輸入的起始點(diǎn)和終點(diǎn),沒(méi)有一條公交線可以直接到的,系統(tǒng)將會(huì)給出一次換乘的方案,則為公交一次換乘)功能名稱(chēng):后臺(tái)管理
功能概述:用于管理員登陸,添加、修改、刪除公交線路,修改信息資料、安全密碼,回復(fù)留言板等功能。
本系統(tǒng)提供了的車(chē)次查詢(xún)功能、路5線1查A詢(xún)S功P能X。乘客可以方便的進(jìn)行查詢(xún),以防乘錯(cuò)車(chē)次。當(dāng)然有些功能的智能化不是很強(qiáng),系統(tǒng)有待進(jìn)一步來(lái)完善。
3.2 數(shù)據(jù)庫(kù)需求分析
數(shù)據(jù)庫(kù)在一個(gè)信息管理系統(tǒng)中占有非常重要的地位,數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)的好壞將直接對(duì)應(yīng)用系統(tǒng)的效率以及實(shí)現(xiàn)的效果產(chǎn)生影響。合理的數(shù)據(jù)庫(kù)結(jié)構(gòu)設(shè)計(jì)可以提高數(shù)據(jù)存儲(chǔ)的效率,保證數(shù)據(jù)的完整和一致。
數(shù)據(jù)庫(kù)技術(shù)是由傳統(tǒng)的文件系統(tǒng)發(fā)展而來(lái)的,從層次模型、網(wǎng)狀模型發(fā)展到關(guān)系模型。數(shù)據(jù)庫(kù)技術(shù)是數(shù)據(jù)管理的最新技術(shù),是計(jì)算機(jī)科學(xué)的一個(gè)重要分支,它能指導(dǎo)我們正確地設(shè)計(jì)數(shù)據(jù)庫(kù)系統(tǒng),它的出現(xiàn)極大地促進(jìn)了計(jì)算機(jī)應(yīng)用的發(fā)展。采用數(shù)據(jù)庫(kù)技術(shù)的原理和方法可以有效地設(shè)計(jì)實(shí)用的數(shù)據(jù)庫(kù)系統(tǒng)。一個(gè)完整的數(shù)據(jù)庫(kù)系統(tǒng)包括數(shù)據(jù)庫(kù)管理系統(tǒng)(DBMS),數(shù)據(jù)庫(kù)管理員(DBA)、數(shù)據(jù)庫(kù)(DB)、應(yīng)用程序和相應(yīng)的硬件設(shè)施。
目前許多數(shù)據(jù)庫(kù)管理系統(tǒng)都基于關(guān)系模型,關(guān)系模型的主要特點(diǎn)是用表格結(jié)構(gòu)表達(dá)實(shí)體,用鍵表示實(shí)體與實(shí)體之間的聯(lián)系。與層次模型和網(wǎng)狀模型相比,關(guān)系模型比較簡(jiǎn)單,容易為初學(xué)者接受。關(guān)系模型是由若干個(gè)關(guān)系模式組成的集合,關(guān)系模式相當(dāng)于記錄類(lèi)型,它的實(shí)例稱(chēng)為關(guān)系。每個(gè)關(guān)系是一張表格。表格簡(jiǎn)單,用戶易懂,用戶只需用簡(jiǎn)單的查詢(xún)語(yǔ)句就可以對(duì)數(shù)據(jù)庫(kù)進(jìn)行數(shù)據(jù)操作,并不涉及到存儲(chǔ)結(jié)構(gòu),訪問(wèn)技術(shù)等細(xì)節(jié)。關(guān)系模型是數(shù)學(xué)化的模型,要用到集合論,離散數(shù)學(xué)等知識(shí)。SQL語(yǔ)言是關(guān)系數(shù)據(jù)庫(kù)的代表性語(yǔ)言,已經(jīng)得到廣泛應(yīng)用。
在設(shè)計(jì)數(shù)據(jù)庫(kù)時(shí),應(yīng)注意數(shù)據(jù)的安全性,保證數(shù)據(jù)的安全,防止非法用戶訪問(wèn)數(shù)據(jù)庫(kù),以免泄露重要信息,同時(shí)也能51防A止s非法用戶的蓄意破壞,有許多保護(hù)數(shù)據(jù)的方法,如采用用戶標(biāo)識(shí),口令密碼或訪問(wèn)控制等方法。一個(gè)成功的數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)應(yīng)具有用戶標(biāo)識(shí),每一個(gè)合法用戶具有一個(gè)用戶名和相應(yīng)的口令,進(jìn)入數(shù)據(jù)庫(kù)應(yīng)用系統(tǒng)前必須輸入正確的口令,否則無(wú)法進(jìn)入系統(tǒng),這就保證了只有合法的用戶才能操作數(shù)據(jù)庫(kù)系統(tǒng)。為了保證數(shù)據(jù)的合法語(yǔ)義,必須對(duì)數(shù)據(jù)庫(kù)的數(shù)據(jù)進(jìn)行完整性約束,即防止用戶輸入不合語(yǔ)義的數(shù)據(jù)。
在設(shè)計(jì)應(yīng)用軟件時(shí),應(yīng)嚴(yán)格按照軟件工程學(xué)的方法進(jìn)行設(shè)計(jì),傳統(tǒng)的方法采用瀑布模型,從問(wèn)題定義、可行性分析、需求分析、概念設(shè)計(jì)、總體設(shè)計(jì)、系統(tǒng)實(shí)現(xiàn)、編碼和軟件測(cè)試、運(yùn)行和維護(hù)等軟件生命周期內(nèi),每一階段均在前一階段的基礎(chǔ)上進(jìn)行設(shè)計(jì),并在每一階段有相應(yīng)的文檔資料。設(shè)計(jì)數(shù)據(jù)庫(kù)系統(tǒng)時(shí)應(yīng)該首先充分了解用戶各個(gè)方面的需求,包括現(xiàn)有的以及將來(lái)可能增加的
需求。數(shù)據(jù)庫(kù)設(shè)計(jì)一般包括如下幾個(gè)步驟:數(shù)據(jù)庫(kù)需要分析,數(shù)據(jù)庫(kù)概念結(jié)構(gòu)設(shè)計(jì),數(shù)據(jù)庫(kù)邏輯結(jié)構(gòu)設(shè)計(jì)。
4系統(tǒng)概要設(shè)計(jì)
4.1概述
本階段設(shè)計(jì)的基本目標(biāo)是解決系統(tǒng)如何實(shí)現(xiàn)問(wèn)題,也叫做概要設(shè)計(jì),本階段主要任務(wù)是劃分
出系統(tǒng)的物理元素及設(shè)計(jì)軟件的結(jié)構(gòu),完成軟件定義時(shí)期的任務(wù)之后就應(yīng)該對(duì)系統(tǒng)進(jìn)行總體設(shè)
計(jì),即根據(jù)系統(tǒng)分析產(chǎn)生的分析結(jié)果來(lái)確定這個(gè)系統(tǒng)由哪些系統(tǒng)和模塊組成,這些系統(tǒng)和模塊又如何有機(jī)的結(jié)合在一起,每個(gè)模塊的功能如何實(shí)現(xiàn)。系統(tǒng)設(shè)計(jì)的目標(biāo)是使系統(tǒng)實(shí)現(xiàn)擁有所要求的功能,同時(shí),力爭(zhēng)達(dá)到高效率、高可靠性、可修改性,并且容易掌握和使用。模塊化的依據(jù)是:
把復(fù)雜問(wèn)題分解成許多容易解決的小問(wèn)題。原來(lái)的問(wèn)題也就變得容易解決。模塊化設(shè)計(jì)是把大型軟件按照一定的原則劃分成一個(gè)較小的相對(duì)功能獨(dú)立又相關(guān)聯(lián)的模塊。每個(gè)模塊完成一個(gè)特定的子功能。把這些模塊結(jié)合起來(lái)組成一個(gè)整體。完成指定的功能,滿足問(wèn)題的要求。采用模塊化原理的優(yōu)點(diǎn)在于可以使軟件結(jié)構(gòu)清晰,容易測(cè)試和調(diào)試。從而提高軟件的可靠性,可修改性。有助于軟件開(kāi)發(fā)的組織管理。一個(gè)大型軟件可分別編寫(xiě)不同的模塊。4.2功能模塊劃分 查詢(xún)系統(tǒng)模塊
該模塊實(shí)現(xiàn)公交查詢(xún)功能。可實(shí)現(xiàn)按線路查詢(xún)、站點(diǎn)查詢(xún)和起點(diǎn)—終點(diǎn)查詢(xún)?nèi)N查詢(xún)方式。錄入系統(tǒng)模塊該模塊實(shí)現(xiàn)數(shù)據(jù)的新增、修改、刪除功能。
4.3.1 數(shù)據(jù)庫(kù)概念結(jié)構(gòu)設(shè)計(jì)
在系統(tǒng)設(shè)計(jì)的開(kāi)始,我首先考慮的是如何用數(shù)據(jù)模型來(lái)數(shù)據(jù)庫(kù)的結(jié)構(gòu)與語(yǔ)義,以對(duì)現(xiàn)實(shí)世界進(jìn)行抽象。目前廣泛使用的數(shù)據(jù)模型可分為兩種類(lèi)型,一種是獨(dú)立于計(jì)算機(jī)系統(tǒng)的“概念數(shù)據(jù)模型”,如“實(shí)體聯(lián)系模型”;另一種是直接面向數(shù)據(jù)庫(kù)邏輯結(jié)構(gòu)的“結(jié)構(gòu)數(shù)據(jù)模型”。在本系統(tǒng)中我采用“實(shí)體聯(lián)系模型”(ER模型)來(lái)描述數(shù)據(jù)庫(kù)的結(jié)構(gòu)與語(yǔ)義,以對(duì)現(xiàn)實(shí)世界進(jìn)行第一次抽象。ER模型直接從現(xiàn)實(shí)世界抽象出實(shí)體類(lèi)型及實(shí)體間聯(lián)系然后用ER圖來(lái)表示數(shù)據(jù)模型。它有兩個(gè)明顯的優(yōu)點(diǎn):接近于人的思維,容易理解;與計(jì)算機(jī)無(wú)關(guān),用戶容易接受。但它只是數(shù)據(jù)庫(kù)設(shè)計(jì)的第一步。E-R圖是直觀表示概念模型的工具,它有三個(gè)基本成分:
(1)矩形框,表示實(shí)體類(lèi)型(考慮問(wèn)題的對(duì)象)。(2)菱形框,表示聯(lián)系類(lèi)型(實(shí)體間的聯(lián)系)。(3)橢圓形框,表示實(shí)體的屬性。實(shí)體和屬性的定義如下:
管理員表(登陸ID,登錄姓名,登錄密碼)站名表(站名編號(hào),站名)
車(chē)輛線路編號(hào)表(車(chē)次,車(chē)線類(lèi)型)
線路表(線路編號(hào),車(chē)次,站名,次序)
車(chē)輛表(車(chē)輛編號(hào),車(chē)次,車(chē)輛類(lèi)型,服務(wù)類(lèi)型,票價(jià),IC 卡類(lèi)型,運(yùn)行區(qū)間)
冬季發(fā)車(chē)時(shí)間表(車(chē)次,編號(hào),首班時(shí)間,末班時(shí)間)
夏季發(fā)車(chē)時(shí)間表(車(chē)次,編號(hào),首班時(shí)間,末班時(shí)間)
4.3.2數(shù)據(jù)庫(kù)邏輯結(jié)構(gòu)設(shè)計(jì)
本系統(tǒng)創(chuàng)建的SQL數(shù)據(jù)庫(kù)名稱(chēng)為城市公交查詢(xún)系統(tǒng)。并將數(shù)據(jù)文件和日志文件保存在公交查詢(xún)系統(tǒng)APP_DATA文件夾中。①管理員表(LoginTable)
管理員表存放登陸系統(tǒng)所需要的用戶名和密碼,登錄后臺(tái)時(shí)需要訪問(wèn)此表。
②站名表
站名表存放站名等數(shù)據(jù),修改站名需要訪問(wèn)此表。
③車(chē)輛線路編號(hào)表
車(chē)輛線路編號(hào)表存放線路編號(hào)等數(shù)據(jù),修改車(chē)輛線路編號(hào)將要訪問(wèn)此表。
④線路表
線路表存放公交車(chē)線路的數(shù)據(jù),修改車(chē)輛線路需要訪問(wèn)此表。
5詳細(xì)設(shè)計(jì)與實(shí)現(xiàn)
5.1.連接數(shù)據(jù)庫(kù)的包含文件
在動(dòng)態(tài)網(wǎng)站中,調(diào)用數(shù)據(jù)庫(kù)中的數(shù)據(jù)是十分頻繁的,為了避免編寫(xiě)重復(fù)的代碼。編寫(xiě)一個(gè)數(shù)據(jù)庫(kù)連接文件是非常重要的。DB.cs
文件中包含了本系統(tǒng)中的數(shù)據(jù)庫(kù)的連接代碼。本系統(tǒng)的數(shù)庫(kù) 的連接代碼如下:
public static SqlConnection createConnection(){
SqlConnection
con=new SqlConnection(“server=.;database=城市公交查詢(xún)系統(tǒng);uid=sa;pwd=;”);return con;}
5.1.1新增車(chē)次線路
此模塊為管理員操作,如當(dāng)?shù)爻霈F(xiàn)新的公交線路,或原有公交車(chē)線路有新的站點(diǎn)加入,管理員可以登錄此表,及時(shí)添加線路和站點(diǎn)的信息,以保證車(chē)次線路的及時(shí)更新,方便用戶查詢(xún)。添加車(chē)次的界面如圖所示。
在輸入相關(guān)車(chē)次信息后便進(jìn)入站名添加過(guò)程如圖
5.1.2新增車(chē)次線路
此模塊為管理員操作,如當(dāng)?shù)爻霈F(xiàn)新的公交線路,或原有公交車(chē)線路有所變動(dòng)是,管理員可以登錄此模塊,及時(shí)添加相關(guān)的線路圖,以保證車(chē)次線路圖的及時(shí)更新,方便用戶查詢(xún)。添加的界面如圖
5.1.3刪除車(chē)次以及無(wú)效站點(diǎn)
此模塊同樣為管理員操作,如當(dāng)?shù)啬膫€(gè)公交線路已經(jīng)被廢除,或原有公交車(chē)線路有哪個(gè)站點(diǎn)被刪除,管理員可以登錄此表,及時(shí)刪除線路和站點(diǎn)的信息,以保證車(chē)次線路的及時(shí)更新,方便用戶查詢(xún)。刪除的界面如圖
5.1.4刪除線路圖
該模塊在管理員系統(tǒng)中實(shí)現(xiàn),如當(dāng)?shù)啬膫€(gè)公交線路已經(jīng)改變,管理員可以登錄此模塊,及時(shí)刪除線路圖信息,以保證車(chē)次線路圖的及時(shí)更新,方便用戶查詢(xún)。刪除的界面如圖
6測(cè)試與維護(hù)
6.1 創(chuàng)建和測(cè)試應(yīng)用程序
為了確保本系統(tǒng)能夠正常運(yùn)行,需要在發(fā)布之后做一次較全面的測(cè)試?,F(xiàn)將具體操作及過(guò)程
舉例說(shuō)明如下:
創(chuàng)建和測(cè)試應(yīng)用程序應(yīng)是交替進(jìn)行的,既要注意開(kāi)發(fā)的效率也要注意它的穩(wěn)定性。每編寫(xiě)一個(gè)模塊,就要對(duì)這個(gè)模塊進(jìn)行測(cè)試,看它能否根據(jù)特定的要求工作。及早發(fā)現(xiàn)問(wèn)題,及早解決,否則到最后再來(lái)測(cè)試的話,難度會(huì)大大增加。6.2測(cè)試項(xiàng)目
在MIS開(kāi)發(fā)過(guò)程中采用了多種措施保證軟件質(zhì)量,但是實(shí)際開(kāi)發(fā)過(guò)程中還是不可避免地會(huì)產(chǎn)生差錯(cuò),系統(tǒng)中通??赡茈[藏著錯(cuò)誤和缺陷,不經(jīng)周密測(cè)試的系統(tǒng)投入運(yùn)行,將會(huì)造成難以想象的后果,因此系統(tǒng)測(cè)試是MIS開(kāi)發(fā)過(guò)程中為保證軟件質(zhì)量必須進(jìn)行的工作。大量統(tǒng)計(jì)資料表明,系統(tǒng)測(cè)試的工作量往往占MIS 開(kāi)發(fā)總工作量的40%以上。因此,我們必須重視測(cè)試工作。由于程序中隱藏的缺陷只在特定的環(huán)境下才有可靠顯露,系統(tǒng)缺陷通常是由于對(duì)某些特定情況考慮不周造成的。因此測(cè)試不是為了表明程序正確;成功的測(cè)試也不是沒(méi)有發(fā)現(xiàn)錯(cuò)誤的測(cè)試。
有意義的軟件測(cè)試應(yīng)該是從“破壞”軟件系統(tǒng)的角度出發(fā),精心設(shè)計(jì)最有可以暴露程序系統(tǒng)缺陷的測(cè)試方案。因此軟件測(cè)試的目標(biāo)應(yīng)該是以盡可能少的代價(jià)和時(shí)間找出軟件系統(tǒng)中潛在的錯(cuò)誤和缺陷。
總結(jié)
在公交數(shù)字化的時(shí)代,公交系統(tǒng)的設(shè)計(jì)者應(yīng)當(dāng)以乘客需求為首位,調(diào)整服務(wù)策略,滿足社會(huì)的需要和乘客的需要,充分發(fā)揮公交系統(tǒng)交通中心的作用。本系統(tǒng)基本達(dá)到了預(yù)定的設(shè)計(jì)目標(biāo),但是在系統(tǒng)的實(shí)際化應(yīng)用中仍需要改進(jìn)和提高公交查詢(xún)系統(tǒng)的服務(wù)職能。系統(tǒng)的不足與改進(jìn)方案:
在數(shù)據(jù)庫(kù)設(shè)計(jì)方面,還有待改進(jìn),數(shù)據(jù)庫(kù)設(shè)計(jì)也可采用別的形式,比如:可以用一個(gè)字段作為站點(diǎn)字段,另一個(gè)字段作為經(jīng)過(guò)該站點(diǎn)的車(chē)次字段,只要找到經(jīng)過(guò)某個(gè)站點(diǎn)最多的車(chē)次,就可以設(shè)計(jì)該字段的類(lèi)型以及長(zhǎng)度。其次,系統(tǒng)的實(shí)際應(yīng)用化欠缺,可以通過(guò)使用根據(jù)起點(diǎn)站、終點(diǎn)站來(lái)確定那條路線,給出多種乘車(chē)方案的方法改進(jìn)。線路的更新應(yīng)該可以通過(guò)調(diào)整數(shù)據(jù)庫(kù)次序的方法來(lái)更新。同時(shí),界面的設(shè)計(jì)不夠美觀版面的設(shè)計(jì)以及查詢(xún)結(jié)果的顯示不夠人化,視覺(jué)效果不佳。應(yīng)當(dāng)參照一些比較美觀的網(wǎng)站設(shè)計(jì)進(jìn)行色彩的調(diào)整,同時(shí)亦可以加入更多的FLASH效果使得頁(yè)面更具動(dòng)態(tài)性。
致謝
時(shí)光飛逝,一轉(zhuǎn)眼我的大學(xué)生活就要結(jié)束了。這兩年我學(xué)到了很多很多的知識(shí),是我人生的一個(gè)轉(zhuǎn)折。我之所以能取得這些成績(jī),除了有自己的努力外,在我的學(xué)習(xí),生活中還得到了很多人的關(guān)心和幫助。在此我要對(duì)他們表示衷心的感謝。
首先,我要感謝我的畢業(yè)指導(dǎo)老師。在連續(xù)數(shù)月的畢業(yè)設(shè)計(jì)中,她不遺余力地指導(dǎo)和幫助我。在她孜孜不倦的教誨下,我順利地完成了畢業(yè)設(shè)計(jì)。老師對(duì)工作認(rèn)真負(fù)責(zé)的態(tài)度,對(duì)學(xué)生無(wú)私的關(guān)懷,使我受益良多。我衷心地感謝她。在這里我還要感謝所有指導(dǎo)過(guò)我的老師們,沒(méi)有你們的培養(yǎng)我無(wú)法完成兩年的大學(xué)學(xué)業(yè)還有,我能有今天,是與我父母的辛勤培養(yǎng)分不開(kāi)的,他們?yōu)槲腋冻隽艘磺?。我將在以后的學(xué)習(xí)、工作中再接再厲,盡我最大的努力做到最好來(lái)報(bào)答父母的養(yǎng)育之恩。
參考文獻(xiàn)
[1]曹祖圣.吳明哲.Visual C#.NET 程序設(shè)計(jì)經(jīng)典.北京:科學(xué)版社,2004.P.50-53.[2]宣小平.ASP.NET數(shù)據(jù)庫(kù)系統(tǒng)開(kāi)發(fā)實(shí)例導(dǎo)航.上海:人民郵電出版社,2003.P.121-130.[3]金銀秋.數(shù)據(jù)庫(kù)原理與設(shè)計(jì).北京:科學(xué)出版社,2003.P.201-230.[4]張海藩.軟件工程.北京:人民郵電出版社2002.P.75-80.[5]朱曄.ASP.NET 第一步——基于C#和ASP.NET2.0.北京:清華大學(xué)出版社,.2007-7-1.P.301-310.[6]譚振林.道不遠(yuǎn)人——深入解析ASP.NET 2.0 控件開(kāi)發(fā).北京:子工業(yè)出版社。2007-9-1.P.125-140.[7]哈特 ASP.NET 2.0經(jīng)典教程——C#篇孟憲瑞,易磊.北京:人民郵電出版社.2007-2-1.P.20-40.[8]朱印宏,熊利榮.Dreamweaver 8完美網(wǎng)頁(yè)設(shè)計(jì)——ASP動(dòng)態(tài)網(wǎng)頁(yè)設(shè)計(jì)篇.北京 中國(guó)電力出版社.2006-10-1.P.63-72.[9]郝剛ASP.NET 2.0開(kāi)發(fā)指南.北京:人民郵電出版社.2006-5-1.P.53-55.