第一篇：高可用性軟件架構設計和實現論文

摘要：硬件冗余可以極大地提高計算機應用系統的可用性，然而，一旦關鍵硬件出現故障或數據庫宕機，正在進行中的業務流程通常會中斷。探討了一種如何實現應用系統高可用性的軟件架構的設計方案，以彌補純硬件冗余應用系統的不足。

關鍵詞：高可用性;軟件容錯;分布式數據庫

在業內，計算機應用系統的可用性定義為計算機應用系統保持正常運行時間的百分比，通常用表1所示的“9”的個數來劃分可用性的類型。

通常，硬件冗余(容錯計算機、雙機或多機集群、磁盤陣列、SAN等)、數據復制、合理的災難備份和恢復策略都可以極大地提高計算機應用系統的可用性。正因為如此，當前，對于計算機應用系統的高可用性、業務的可持續性要求，業內通常以硬件系統的高可用性來應對或代替。常見的解決方案是雙機(或多機)集群方案或直接采用容錯計算機來保障系統的高可用性，應用軟件的設計和開發往往僅注重業務流程的分析和過程控制。在這種完全依賴硬件來保障整個系統的可用性的系統里，一旦關鍵硬件出現故障或數據庫宕機，正在進行中的業務流程(如需較長執行時間的事務處理、后臺批處理過程等)必然會中斷，這是因為雙機切換也需要時間。對此，應用軟件本身并無多少作為，該類業務必須等待系統重新恢復后全部或部分重做。

本文以基于大型數據庫的應用系統為例，從“軟件容錯”設計的概念出發，參考“分布式”數據庫結構設計，以“系統服務總線”為核心，給出了一種可行的高可用性軟件架構的設計方案，可以極大地提高應用軟件的可用性和業務系統的可持續性。無論是傳統的C/S架構，還是近年來流行的B/S架構，本文中給出的設計方案都有一定的參考意義。

1軟件結構模型

任何基于大型數據庫的應用系統，都可以抽象為對數據的“讀”和“寫”操作。至于客戶端如何展現“讀”到的數據，以及“客戶端”與“服務端”基于何種通信協議通信，不在本文討論之列。

軟件結構的設計其實就是針對“讀”和“寫”的一系列流程的設計。如何最大限度地保證系統中的所有“硬件”和“軟件”協同工作，正確完成每一次“讀”和“寫”的操作，也就是對系統“高可靠性”和“高可用性”的要求。

圖1是基于“軟件容錯”和“分布式數據庫系統”的原理，并參照了計算機“總線”的工作原理給出的一種基于分布式數據庫或文件系統的高可用性的軟件架構設計方案。系統采用3層架構：客戶端、中間應用層和數據庫層。

2系統設計

2.1數據庫配置為了更清楚地闡述本文的設計方案，先對數據庫的配置及其功能進行描述。本系統中，數據庫按角色可劃分為如下三類數據庫：控制數據庫(COTROLL DB)、日志數據庫(LOG DB)、業務數據庫(BUS DB_N)。

2.1.1控制數據庫

控制數據庫也可以是一個或多個系統控制(參數)文件。它存放要訪問的目標數據庫的節點(N)、端口、用戶、文件頭、表、視圖等信息;存放對節點、業務數據庫、表或視圖的授權或訪問控制信息;目標數據庫(或文件)的當前狀態(聯機/脫機、忙/空閑等);目標數據庫中的表或視圖的當前狀態(聯機/脫機、忙/空閑、加鎖/解鎖等)。

2.1.2日志數據庫

日志數據庫獨立于業務數據庫之外，用于記錄客戶端節點信息、請求時刻和發來的所有請求的原始內容，但不做業務流程相關的處理、運算等。記錄每次數據操作分配的唯一的“事件號”(EVENT_ID)。對每一次客戶端的“請求”，“系統服務總線”(SYSSRV)會分配唯一的標識符號，可以定義為有一定意義的字符串，比如，“當前時刻+流水號”。以上信息可以被壓縮、打包、加密后存放，以記錄格式保存于數據庫的表或文件中。它可以設計為數據庫中的一個或多個表，也可以是文件格式。

2.1.3業務數據庫

業務數據庫記錄所有業務相關的數據信息。所有業務數據庫的相關業務邏輯的數據結構相同，即，N個節點的業務數據庫中與業務模式相關的表、視圖、過程或其他程序設置相同。

需要特別指出的是：

(1)控制數據庫、日志數據庫和業務數據庫可以是不同數據庫廠家或品牌的產品。比如，日志數據庫可以采用低端的數據庫產品或開源數據庫系統，業務數據庫可以采用高端的大型數據庫產品。

(2)控制數據庫、日志數據庫和業務數據庫在物理上和邏輯上是可以相互隔離的，這可以極大地提高系統的整體安全性。目標數據庫和要訪問的表或視圖對客戶端來說是“不可見”的，由控制數據庫動態定義和控制。

(3)所有類別的數據庫在物理上位于一個或多個節點上，即節點N>=1;任意一個節點N上建有一個或多個業務數據庫(邏輯數據庫>=1);任意一個節點是一個完整的、可獨立工作的計算機。根據性能要求，可以是高性能PC機、PC服務器、小型機、集群或超級計算機，或是它們的“混合體”;任意一個節點是指定網絡中的一個指定節點。

2.2應用層設計

中間應用層由5個后臺進程構成：(1)系統服務總線(SYSSRV);(2)數據庫寫進程(DBWRT_N);(3)數據庫讀進程(DBRED_N);(4)數據庫在線恢復進程(DBRCY);(5)日志檢查進程(LOGCHK)。

2.2.1系統服務總線

這是一個后臺監聽、分發、調度總進程。設計目標具有一定的“自我修復”和“自我復制”動能。它可以根據負載情況，自我復制或開啟子進程響應新的負載;可以動態配置可服務的節點或客戶端;可以為特定節點或客戶端指定專用進程;它通過“DBWRT”和“DBRED”“讀/寫”日志數據庫或日志文件。

2.2.2寫進程

寫進程負責向所有節點寫數據。它可以配置成多進程/單進程模式;多進程模式，指對應每個業務數據庫N都有獨立的“寫”進程;單進程模式，指對應多個業務數據庫只有一個主進程，主進程開啟多個線程提供“寫”服務。

2.2.3讀進程

讀進程負責向所有節點讀數據，它可以配置成多進程/單進程模式。多進程模式指對應每個業務數據庫N都有獨立的“讀”進程，單進程模式指對應多個業務數據庫只有一個主進程，主進程開啟多個線程提供“讀”服務。

根據需要，讀進程可以配置成：向所有在線節點并發讀數據，返回最快的結果集，拋棄其他的結果集，并中斷其他讀進程;也可以配置成：隨機讀某個節點的數據，如果失敗或超時，則再隨機讀余下的在線節點，直到“讀”成功或失敗;還可以配置成向所有節點順序讀數據，過程類似上面“隨機讀”。

以上“讀寫”業務數據庫的進程，設計上支持多種數據庫訪問接口，針對“表”或“視圖”提供統一格式的、標準的、動態的SQL數據操作接口和方法，完成對數據庫中表或視圖的增、刪、改、查和批處理操作。它們可以設計為數據庫中的存儲過程，也可以是C++，Java程序的API或混合體。

2.2.4數據庫在線恢復進程

該進程負責檢查全部或部分節點數據庫(包括所有授權控制數據庫、業務數據庫和日志數據庫)或文件的工作狀態;檢查數據庫或文件表中數據的一致性;將以上檢查結果寫入日志數據庫(或日志文件)。

當某個業務數據庫中的表寫入失敗時，它負責從“日志數據庫”的表或日志文件中讀出原始數據，接著寫入出現問題的業務數據庫的表中，并檢查結果。或從其他節點的數據庫中讀相關數據并寫入到出現問題的業務數據庫的表中。

接收外部命令，根據“時間點”或“事件號”從特定時刻、特定數據庫(包括日志數據庫)、特定表恢復數據到特定目標數據庫的表或文件。

2.2.5日志檢查進程

該進程負責讀、寫日志文件，檢查數據操作結果的一致性。如果不一致，則報告給“系統服務總線”，將問題數據庫或數據庫中的表、視圖設置為“離線”狀態。

3系統實現

3.1系統初始化啟動配置好的后臺進程即完成系統初始化過程。

3.2數據“寫”流程

數據“寫”流程的主要步驟如下：(1)客戶端通過給定協議(或混合多種通信協議)向后臺“系統服務總線”發送“寫”請求。

(2)激活“數據庫寫進程”，將客戶端的“請求”寫入“日志數據庫”(或日志文件)，并分配一個唯一的“事件號”。

(3)“系統服務總線”查詢“授權/控制數據庫”(或/配置文件)得到客戶端請求訪問的數據存放的目標數據庫(或文件)節點N(或文件存放的節點N)、端口、用戶、表、文件頭等信息。節點N可以是多個，即節點N>=1。

(4)“系統服務總線”向N個“數據庫寫進程”發送數據“寫”訪問請求，并得到各節點的返回結果集。

(5)只要有1個節點寫入成功，“系統服務總線”就將寫入成功的標志發回客戶端;“數據庫寫進程”將各節點的返回結果狀態寫入“日志數據庫”(或日志文件)中。

(6)“日志監控”查詢“日志數據庫”(或日志文件)，比較N個節點的寫入狀態。如發現寫錯誤、失敗、超時等狀態，則將該“業務數據庫”(或文件、表、視圖)標志為“非正常聯機數據庫”(或文件、表、視圖不可用)。

(7)激活“數據在線恢復進程”，進程為“非正常聯機數據庫”，則執行數據庫數據“同步”。在線同步恢復如失敗，則將該“數據庫”標志為“需要DBA維護”的類別，留待DBA或軟件維護工程師處理。

3.3數據“讀”流程

數據“讀”流程的主要步驟如下：(1)客戶端通過給定協議(或混合多種通信協議)向后臺“系統服務總線”發送“讀”請求。

(2)激活“寫進程”，將客戶端的“請求”寫入“日志數據庫”(或日志文件)，并分配一個唯一的“事件號”。

(3)“系統服務總線”查詢“授權/控制數據庫”(或/配置文件)得到客戶端請求訪問的數據存放的目標數據庫節點N(或文件存放的節點N)、端口、用戶、表等信息。

節點N可以是多點，即節點N>=1。

(4)“系統服務總線”查詢“授權/控制數據庫”(或/配置文件)得到可用的、空閑的目標數據庫節點N(或文件存放的節點N)。

(5)激活“讀進程”(或隨機、或順序)向N個節點的“業務數據庫”(或文件)發送數據“讀”訪問請求，并得到各節點的返回結果集。

(6)“系統服務總線”將最快返回的結果集發回客戶端;拋棄其他結果集，中斷其他讀進程。

在本系統的設計和實現中，由于采用了“分布式”數據庫或文件系統部署，只要N個節點中至少有一個節點的“業務數據庫”正常工作，因為一個或幾個“業務數據庫”系統(或節點硬件)故障所引起的業務系統的不可持續性理論上將可以完全避免，因而提高了系統的“容錯”性。

由于N個數據庫同時在線，且節點是否可用、空閑等狀態可實時監控，這為特定業務快速訪問和獨享訪問提供了先決條件。如可以指定某特定“業務數據庫”僅為某個或幾個特定客戶端服務提供“讀”訪問。

因為設計了統一、標準的增、刪、改、查的過程方法或API，前端開發人員甚至不必寫任何SQL語句就可以完成對數據庫中表或視圖的操作，可以大大地縮短編程和調試時間。

需要指出的是，雖然“系統服務總線”具有“自我修復”和“自我復制”的特點，但因為“節點”硬件故障或“授權/控制數據庫”(或/配置文件)或“日志數據庫”故障而引起的全系統不可用依然存在，因此，建議該節點采用性能好、可靠性高的中、高端服務器。

第二篇：B-S架構論文：基于J2EE的稅收執法責任制考核系統的設計與實現

B/S架構論文：基于J2EE的稅收執法責任制考核系統的設計與實現

【中文摘要】隨著信息時代的到來,為了適應全面建設小康社會的新形勢和依法治國的進程,必須全面推進依法行政,建設法治政府。推行行政執法責任制,是推行依法行政的重要舉措。即依法界定執法職責,科學設定執法崗位,規范執法程序;建立公開、公平、公正的評議考核制和執法過錯或者錯案責任追究制。為了能夠更好的將稅收執法責任制與崗位職責落實到各個單位、責任人等身上,在各行各業都廣泛使用計算機的信息時代,稅收執法責任制考核系統(Tax

Law-Excuting Check Manage System,簡稱TLEC)應運而生。通過應用稅收執法責任制考核系統,實現稅務機關管理的現代化,提高工作效率,將大大有利于監督稅務部門依法行政,規范稅務行政執法行為,保證國家稅務法律法規的貫徹執行;有利于維護納稅人的合法權益,改善征納關系。論文主要從以下四個方面來開展研究。首先,進行前期調研分析。通過資料檢索、文獻查閱的方式,了解了稅收執法責任制考核系統的、國內外的發展現狀和存在的問題,經過總結分析,提出了本系統開發的意義和研究的內容。然后,對系統進行需求分析和設計。對稅收機關實行稅收執法責任制總體業務流程圖給出了詳細的分析描述,確定了整個系統的功能模塊和設計原則、設計思想。在此基礎上結合稅收機關稅收執法責任制考核功能特點及實際要求,詳細的設計了稅收執法責任制考核系統的開發方案,系統數據流圖和E-R圖

設計,并對系統安全和數據庫進行相應的設計。最后,完成了系統的具體實現工作,包括日常監控、執法考核、過錯申辯、責任追究、綜合評比、執法通報和過錯糾正、統計查詢等功能模塊的開發與實現。

【英文摘要】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.【關鍵詞】B/S架構 MVC 稅收執法責任制考核系統 J2EE 【英文關鍵詞】B / S structureMVCTax Law-Excuting Check Manage SystemJ2EE

【目錄】基于J2EE的稅收執法責任制考核系統的設計與實現摘要4-5

ABSTRACT5-6

11-13

第一章 緒論11-161.1.1 研究背景11

1.1 1.1.2 1.3 本論

1.5

課題研究背景與目的研究目的11-13文的主要工作及目標本章小結15-1616-23

1.2 國內外研究現狀13-1414-15

1.4 論文組織結構15

第二章 理論基礎及相關知識

2.2 稅收執法責

2.1 稅收執法責任制的概念16

任制的考核16-171718-191921-2223-34

2.3 稅收執法責任制的考核系統

2.4.1 MVC 設計模式

2.4.3 MVC 的優點2.6 ORACLE 數據庫系統第三章 系統需求分析23-26

3.2 系統子模塊

2.4 MVC 模式17-19

2.4.2 MVC 的處理過程192.5 J2EE 架構概述19-212.7 本章小結22-233.1 系統功能需求分析

需求分析26-3226-2829-30313232-3334-72架構35-36設計36-38控40控41-42稿錄入43-4445-4647-5350-515253-58

3.2.1 日常監控263.2.2 執法考核3.2.4 責任追究3.2.6 執法考核通報

3.2.3 過錯申辯28-293.2.5 綜合評比30-313.2.7 過錯糾正31-323.2.9 幫助

3.2.8 統計查詢

3.3 系統的性能需求分析

第四章 系統設計

4.2 系統的應用體系

4.4 系統功能4.5.1 分單位監4.5.3 分過錯行為監4.6.1 人工考核底4.6.3 考核設置

3.4 本章小結33-344.1 系統設計原則34-35

4.3 系統的技術體系結構364.5 日常監控模塊38-42

4.5.2 分責任人監控40-414.6 執法考核模塊42-47

4.6.2 自動考核44-45

4.6.4 考核撤消46-474.7.1 申辯申請49-50

4.7 過錯申辯模塊4.7.2 調查報告

4.7.4 申辯調整4.8 責任追究模塊4.8.2 制作追究處

4.8.4 責任追4.9.1 系統數據

4.9.3

4.7.3 申辯處理決定書51-524.7.5 過錯申辯文書打印52-534.8.1 追究清冊生成55-56

4.8.3 追究執行57-584.9 數據庫設計

58-71

理決定書56-57究文書打印58庫E-R 圖58-60數據表設計61-71功能實現72-87

4.9.2 數據庫設計原則60-614.10 本章小結5.1 系統平臺設計

71-7272-75

第五章 系統5.1.1 系統

主機平臺設計72-7373-74

5.1.2 系統前置機部署

5.1.4 系統據庫

5.1.3 系統應用服務器部署

服務器74-7575-76

5.2 系統開發方法及開發環境介紹

5.3.1

5.3 用戶權限控制（UPC）的配置76-77

5.3.2 UPC 配置的基本流程

77-78

UPC 系統主要組成76-77術7778-80監控80-8283-8486-87置87-8890-9292-9393-94致謝96-97

5.4 系統業務邏輯層實現5.4.2 實現實例77-78

5.4.1 實現技

5.5 系統數據訪問層實現

5.6.1 日常

5.6 系統各功能模塊的實現80-86

5.6.2 執法考核82-835.6.4 責任追究84-86第六章 系統驗證測試87-956.2 功能測試88-906.4 測試結果926.6 回歸測試936.8 本章小結94-95

參考文獻97-99

5.6.3 過錯申辯5.7 本章小結

6.1 測試環境與配6.3 系統的完成情況

6.5 缺陷統計6.7 測試結果總結分析

第七章 總結95-96攻讀碩士學位期間已發表

或錄用的論文99-100

第三篇：[藍牙] 1藍牙核心技術了解(藍牙協議架構硬件和軟件筆記)

[藍牙]

1、藍牙核心技術了解（藍牙協議、架構、硬件和軟件

筆記）

聲明：這篇文章是樓主beautifulzzzz學習網上關于藍牙的相關知識的筆記，其中比較多的受益于xubin341719的藍牙系列文章，同時還有其他網上作者的資料。由于有些文章只做參考或統計不足，如涉及版權請在下面留言~。同時我也在博客分類中新建一個藍牙通信分類，用來研究分享藍牙相關技術。

下載連接：Bluetooth PROFILE SPECIFICATIONS（基本涵蓋所有藍牙協議）、buletooth core 2.1-4.0 SPECIFICATION（三藍牙版本的核心協議v2.1v3.0v4.0）、藍牙核心技術與應用 馬建倉 版（藍牙協議相關初學者必讀，開發者參考）藍牙核心技術概述

（一）：藍牙概述 藍牙核心技術概述

（二）：藍牙使用場景

藍牙核心技術概述

（三）： 藍牙協議規范（射頻、基帶鏈路控制、鏈路管理）

藍牙核心技術概述

（四）：藍牙協議規范（HCI、L2CAP、SDP、RFOCMM）

藍牙核心技術概述

（五）：藍牙協議規范（irOBEX、BNEP、AVDTP、AVCTP）

有道筆記分享鏈接：http://note.youdao.com/share/?id=950d00cefa9b7fd3c559eec349805b24&type=note

下面是摘抄筆記內容：

藍牙核心技術概述

（一）：藍牙概述

藍牙，是一種支持設備短距離通信（一般10m內）的無線電技術。能在包括移動電話、PDA、無線耳機、筆記本電腦、相關外設等眾多設備之間進行無線信息交換。利用“藍牙”技術，能夠有效地簡化移動通信終端設備之間的通信，也能夠成功地簡化設備與因特網Internet之間的通信，從而數據傳輸變得更加迅速高效，為無線通信拓寬道路。藍牙采用分散式網絡結構以及快跳頻和短包技術，支持點對點及點對多點通信，工作在全球通用的2.4GHz ISM（即工業、科學、醫學）頻段。其數據速率為1Mbps。采用時分雙工傳輸方案實現全雙工傳輸。

Bluetooth的系統構成

1、無線射頻單元(Radio)：負責數據和語音的發送和接收，特點是短距離、低功耗。藍牙天線一般體積小、重量輕，屬于微帶天線。

2、基帶或鏈路控制單元(LinkController)：進行射頻信號與數字或語音信號的相互轉化，實現基帶協議和其它的底層連接規程。

3、鏈路管理單元(LinkManager)：負責管理藍牙設備之間的通信，實現鏈路的建立、驗證、鏈路配置等操作。

4、藍牙軟件協議實現：如上圖紫色部分，這個后面我們做詳細說明。

低耗電藍牙相關規范

（二）藍牙協議組成2.1 藍牙協議架構藍牙協議體系中的協議按SIG的關注程度分為四層：

1.核心協議：BaseBand、LMP、L2CAP、SDP；

2.電纜替代協議：RFCOMM；

3.電話傳送控制協議：TCS-Binary、AT命令集；

4.選用協議：PPP、UDP/TCP/IP、OBEX、WAP、vCard、vCal、IrMC、WAE。除上述協議層外，規范還定義了主機控制器接口（HCI），它為基帶控制器、連接管理器、硬件狀態和控制寄存器提供命令接口。在圖1中，HCI位于L2CAP的下層，但HCI也可位于L2CAP上層。

藍牙核心協議由SIG制定的藍牙專用協議組成。絕大部分藍牙設備都需要核心協議（加上無線部分），而其他協議則根據應用的需要而定。總之，電纜替代協議、電話控制協議和被采用的協議在核心協議基礎上構成了面向應用的協議。

藍牙協議棧允許采用多種方法，包括 RFCOMM 和 Object Exchange（OBEX），在設備之間發送和接收文件。如果想發送和接收流數據（而且想采用傳統的串口應用程序，并給它加上藍牙支持），那么 RFCOMM 更好。反過來，如果想發送對象數據以及關于負載的上下文和元數據，則 OBEX 最好。

藍牙應用程序活動圖，如下：

2.1.1 串口仿真RFCOMM介紹 藍牙—RFCOMM協議

找到服務，RFCOMM是通過不同的頻道（channel）來提供不同的Profile的，所以需要找到要用的服務在設備上的哪個頻道上，這是通過同一個軟件包里的sdptool來完成的，就是SDP，服務發現協議

2.2 藍牙profile 2.2.1 藍牙profile概述 參考 對藍牙profile的理解

從3.0版本開始（據說2.1也是支持的？TBD），藍牙才開始支持BluetoothProfile。BluetoothProfile是藍牙設備間數據通信的無線接口規范。想要使用藍牙無線技術,設備必須能夠翻譯特定藍牙配置文件,配置文件定義了可能的應用.藍牙配置文件表達了一般行為,藍牙設備可以通過這些行為與其他設備進行通信.藍牙技術定義了廣泛的配置文件,描述了許多不同類型的使用安全.按藍牙規格中提供的指導,開發商可創建應用程序以用來與其他符合藍牙規格的設備協同工作.在最低限度下,各配置文件規格應包含下列主題的相關信息.① 與其他配置文件的相關性

② 建議的用戶界面格式

③ 配置文件使用的藍牙協議堆棧的特定部分.為執行其任務,每個配置文件都使用堆棧各層上的特定選項和參數.若需要,也可包括必需的服務記錄概要。ProfilesAPI層則分別對Audio、Data、Control等提供了不同的模塊。目前已規范有四大類、十三種協議規格。

Bluetooth的一個很重要特性，就是所有的Bluetooth產品都無須實現全部的Bluetooth規范。為了更容易的保持Bluetooth設備之間的兼容，Bluetooth規范中定義了Profile。Profile定義了設備如何實現一種連接或者應用，你可以把Profile理解為連接層或者應用層協議。

? 常用的profile介紹請參考“藍牙Profile的概念和常見種類”，幾種種最基本的配置文件為：

1.通用訪問配置文件(Generic Access Profile, GAP)GAP是所有其他配置文件的基礎,它定義了在藍牙設備間建立基帶鏈路的通用方法.除此之外,GAP還定義了下列內容:

① 必須在所有藍牙設備中實施的功能

② 發現和鏈接設備的通用步驟

③ 基本用戶界面術語.GAP確保了應用程序和設備間的高度互操作性,還允許開發人員利用現有的定義更加容易地定義新的配置文件.GAP處理未連接的兩個設備間的發現和建立連接過程.此配置文件定義了一些通用的操作,這些操作可供引用GAP的配置文件,以及實施多個配置文件的設備使用.GAP確保了兩個藍牙設備可通過藍牙技術交換信息,以發現彼此支持的應用程序.不符合任何其他藍牙配置文件的藍牙設備必須與GAP符合以確保基本的互操作性和共存.2.服務發現應用配置文件(Service Discovery Application Profile, SDAP)

SDAP描述了應用程序如何使用SDP發現遠程設備上的服務.由于GAP的要求,任何藍牙設備都應能夠連接至其他藍牙設備.基于此,SDAP要求任何應用程序都應當能夠發現它要連接的其他藍牙設備上的可用服務.此配置文件可承擔搜索已知和特定服務及一般的任務.SDAP涉及了稱為“服務發現用戶應用程序”的一個應用程序,這是藍牙設備查找服務所必需的.此應用程序可與向/從其他藍牙設備發送/接收服務查詢的SDP相接.SDAP依賴于GAP,并可以重新使用部分GAP.3.串行端口配置文件(Serial Port Profile, SPP)

SPP定義了如何設置虛擬串行端口及如何連接兩個藍牙設備.SPP基于ETSI TS 07.10規格,使用RFCOMM協議提供串行商品仿真.SPP提供了以無線方式替代現有的RS-232串行通信應用程序和控制信號的方法.SPP為DUN,FAX,HSP和LAN配置文件提供了基礎.此配置文件可以支持最高128kb/s的數據率.SPP依賴于GAP.4.通用對象交換配置文件(Generic Object Exchange Profile, GOEP)

GOEP可用于將對象從一個設備傳輸到另一個設備.對象可以是任意的.如:圖片,文檔,名片等.此配置文件定義了兩個角色:提供拉提或推送對象位置的服務器及啟動操作的客戶端.使用GOEP的應用程序假定鏈路和信道已按GAP的定義建立.GOEP依賴于串行端口配置文件.GOEP為使用OBEX協議的其他配置文件提供了通用藍圖,并為設備定義了客戶端和服務器角色.對于所有的OBEX事務.GOEP規定應由客戶端啟動所有事務.但是此配置文件并沒有描述應用程序就如何定義要交換的對象或如何實施交換.這些細節留給屬于GOEP的配置文件.即OPP,FTP和SYNC去完成.通常使用此配置文件的藍牙設備為筆記本電腦,PDA,手機及智能電話.注意:藍牙1.1版本規范所有藍牙設備的最小實現必須支持通用訪問配置文件,服務發現應用配置文件和串行端口配置文件.在兩臺電腦或者Labtop之間就可以建立這種連接，如下圖所示：

SPP是基于RFCOMM的，spp 協議處于rfcomm的上層，spp的應用需走rfcomm層。如果你使用RFCOMM能夠實現，那么也就不需要使用SPP，而卻速度還會比SPP來做快，因為省略了采用profile的一些數據包頭等。不過，還是推薦采用SPP來做，兼容性有保證，這也是為什么藍牙本質上數據和語音的傳送卻出現HFP，HSP，SPP，OPP等諸多具體應用profile的原因。Bluez SPP實現代碼分析

2.2.2 藍牙profile框架

每個attribute屬性被UUID（通用唯一標識符）唯一標識，UUID是標準128-bit格式的ID用來唯一標識信息。attributes 被 ATT 格式化characteristics和services形式進行傳送。特征（Characteristics）— 一個characteristics包含一個單獨的value值和0 –n個用來描述characteristic 值（value）的descriptors。一個characteristics可以被認為是一種類型的，類似于一個類。

描述符(descriptor)—descriptor是被定義的attributes，用來描述一個characteristic的值。例如，一個descriptor可以指定一個人類可讀的描述中，在可接受的范圍里characteristic值，或者是測量單位，用來明確characteristic的值。服務（service）—service是characteristic的集合。例如，你可以有一個所謂的“Heart RateMonitor”service，其中包括characteristic，如“heart rate measurement ”。你可以在 bluetooth.org找到關于一系列基于GATT的profile和service。

如上圖所示：藍牙設備可以包括多個Profile，一個Profile中有多個Service，一個Service中有多個Characteristic，一個Characteristic中包括一個value和多個Descriptor。

profile框架和android低功耗藍牙管理和使用簡介

2.3 藍牙4.0和4.1

它們有什么差別？全面解析藍牙技術4.0和4.1標準 ? 藍牙4.0實際是個三位一體的藍牙技術，它將傳統藍牙、低功耗藍牙和高速藍牙技術融合在一起，這三個規格可以組合或者單獨使用。也就是說 BLE是藍牙4.0增加的，之前沒有？（TBD）

藍牙4.0專門面向對成本和功耗都有較高要求的無線方案，其主打特性就是省電、省電、省電。極低的運行和待機功耗使得一粒紐扣電池甚至可連續工作一年之久。它有低功耗、經典、高速三種協議模式。其中：高速藍牙主攻數據交換與傳輸；經典藍牙則以信息溝通、設備連接為重點；低功耗藍牙以不需占用太多帶寬的設備連接為主。這三種協議規范能夠互相組合搭配，從而適應更廣泛的應用模式。正因為有了三種可以互相組合搭配的協議，藍牙4.0因此成為唯一一個綜合協議規范。它有著極低的運行和待機功耗。此外，低成本和跨廠商互操作性，3毫秒低延遲、AES-128加密等諸多特色，可以用于計步器、心律監視器、智能儀表、傳感器物聯網等眾多領域，大大擴展藍牙技術的應用范圍。? 藍牙4.1主打IOT（Internet Of Things全聯網），最新的藍牙4.1標準是個很有前途的技術，其智能、低功耗、高傳輸速度、連接簡單的特性將適合用在許多新興設備上。藍牙4.1設備可以同時作為發射方和接受方,并且可以連接到多個設備上。舉個例子，智能手表可以作為發射方向手機發射身體健康指數，同時作為接受方連接到藍牙耳機、手環或其他設備上。藍牙4.1使得批量數據可以以更高的速率傳輸，當然這并不意味著可以用藍牙高速傳輸流媒體視頻，這一改進的主要針對的還是剛剛興起的可穿戴設備。例如已經比較常見的健康手環，其發送出的數據流并不大，通過藍牙4.1能夠更快速地將跑步、游泳、騎車過程中收集到。因為新標準加入了對IPv6專用通道聯機的支持，通過IPv6連接到網絡，實現與Wi-Fi相同的功能，解決可穿戴設備上網不易的問題。

藍牙4.0和藍牙4.1的比較

2.3.1 藍牙4.0低功耗(BLE)TI低功耗藍牙（BLE）介紹

① 低功耗藍牙Bluetooth Low Energy（BLE）是藍牙4.0增加的。（？TBD），蘋果系列都支持4.0.② Android4.3（API級別18）引入內置平臺支持BLE的central角色，同時提供API和app應用程序用來發現設備，查詢服務，和讀/寫characteristics。與傳統藍牙（ClassicBluetooth）不同，藍牙低功耗（BLE）的目的是提供更顯著的低功耗。這使得Android應用程序可以和具有低功耗的要求BLE設備，如接近傳感器，心臟速率監視器，健身設備等進行通信。③ BLE低功耗藍牙軟件有2個主要組成： OSAL操作系統抽象層和 HAL硬件抽象層，多個Task任務和事件在OSAL管理下工作，而每個任務和事件又包括3個組成：BLE 協議棧，profiles和應用程序。BLE藍牙協議棧結構

附圖1 BLE藍牙協議棧結構圖 分為兩部分：控制器和主機。對于4.0以前的藍牙，這兩部分是分開的。所有profile（姑且稱為劇本吧，用來定義設備或組件的角色）和應用都建構在GAP或GATT之上。下面由結構圖的底層組件開始介紹。

附圖 2 BLE低功耗藍牙系統架構圖，圖中的Task用附圖1BLE藍牙協議棧結構圖來描述

通用屬性規范（GATT）—GATTprofile是一個通用規范用于在BLE鏈路發送和接收被稱為“屬性（attributes）”的數據片。目前所有的低功耗應用 profile都是基于GATT。藍牙SIG定義了許多profile用于低功耗設備。Profile（配置文件）是一個規范，規范了設備如何工作在一個特定的應用場景。注意：一個設備可以實現多個profile。例如，一個設備可以包含一個心臟監測儀和電池電平檢測器。

主從機連接建立過程:

2.3.2 藍牙4.0(BLE)主從通信透傳模塊

低功耗藍牙模塊主透傳協議是針對低功耗藍牙模塊從透傳協議設計的，通過本協議模塊可替代手機設備與從透傳協議模塊連接，實現透傳功能或直驅控制功能。此協議模塊可用作從透傳協議模塊開發過程中的輔助工具。

BLE主透傳協議模塊（以下簡稱MTTM）可以工作在透傳模式（TTM）或指令模式（CM）。

MTTM上電啟動后，處于待機模式（SBM），此時處于空閑狀態，無睡眠，需要用戶通過AT指令控制模塊連接從設備。在成功與從設備建立鏈接后，MTTM會自動查找從設備的透傳通道，如果從設備屬于BLE從透傳協議模塊（以下簡稱STTM），MTTM默認進入透傳模式，否則默認進入指令模式。

透傳模式下，用戶CPU可以通過模塊的通用串口與STTM進行雙向通訊。從MTTM串口輸入的數據將轉發到STTM，并從STTM的串口輸出；從STTM輸入的數據將轉發到MTTM，并從MTTM的串口輸出，從而實現透明傳輸功能，用戶數據的具體含義由上層應用程序自行定義。

透傳中數據的格式也是profile，或藍牙標準profile或自定義simple profile。基本結構依然是：

1、profile

profile可以理解為一種規范，一個標準的通信協議，它存在于從機中。藍牙組織規定了一些標準的profile，例如 HID OVER GATT，防丟器，心率計等。每個profile中會包含多個service，每個service代表從機的一種能力。

2、service

service可以理解為一個服務，在ble從機中，通過有多個服務，例如電量信息服務、系統信息服務等，每個service中又包含多個characteristic特征值。每個具體的characteristic特征值才是ble通信的主題。比如當前的電量是80%，所以會通過電量的characteristic特征值存在從機的profile里，這樣主機就可以通過這個characteristic來讀取80%這個數據

3、characteristic

characteristic特征值，ble主從機的通信均是通過characteristic來實現，可以 理解為一個標簽，通過這個標簽可以獲取或者寫入想要的內容。

4、UUID

UUID，統一識別碼，我們剛才提到的service和characteristic，都需要一個唯一的uuid來標識

每個從機都會有一個叫做profile的東西存在，不管是上面的自定義的simpleprofile，還是標準的防丟器profile，他們都是由一些列service組成，然后每個service又包含了多個characteristic，主機和從機之間的通信，均是通過characteristic來實現。

實際產品中，每個藍牙4.0的設備都是通過服務和特征來展示自己的，服務和特征都是用UUID來唯一標識的。一個設備必然包含一個或多個服務，每個服務下面又包含若干個特征。特征是與外界交互的最小單位。藍牙設備硬件廠商通常都會提供他們的設備里面各個服務(service)和特征(characteristics)的功能，比如哪些是用來交互(讀寫)，哪些可獲取模塊信息(只讀)等。比如說，一臺藍牙4.0設備，用特征A來描述自己的出廠信息，用特征B來與收發數據等。

？4.0中profile的存在是干嘛用的呢，只是一種組織形式存在？

服務和特征都是用UUID來唯一標識的，UUID的概念如果不清楚請自行google,國際藍牙組織為一些很典型的設備(比如測量心跳和血壓的設備)規定了標準的service UUID(特征的UUID比較多，這里就不列舉了)4.0 BLE數據傳輸可參考下述系列：

藍牙4.0 BLE 數據傳輸

（一）（三）Android Bluetooth 架構

1、面向庫的架構視圖

2、面向進程的架構視圖

參考 藍牙4.0 For IOS iOS 有兩個框架支持藍牙與外設連接。

一個是 ExternalAccessory。從ios3.0就開始支持，也是在iphone4s出來之前用的比較多的一種模式，但是它有個不好的地方，External Accessory需要拿到蘋果公司的MFI認證。另一個框架則是本文要介紹的CoreBluetooth，在藍牙4.0出來之后（注意，硬件上要4s以上，系統要ios6以上才能支持4.0），蘋果開放了BLE通道，專門用于與BLE設備通訊（因為它的API都是基于BLE的）。這個不需要MFI，并且現在很多藍牙設備都支持4.0,所以也是在IOS比較推薦的一種開發方法。現CoreBluetooth在的開發幾乎全部基于該框架，本節只介紹CoreBluetooth。

1，CoreBluetooth介紹

CoreBluetooth框架的核心其實是兩個東西，peripheral和central, 可以理解成外設和中心。對應他們分別有一組相關的API和類，如下圖所示:

如果你要編程的設備是手機的central，那么你大部分用到peripheral API。反之亦然，設備是peripheral，iphone手機是central,所以將大部分使用central API。使用peripheral編程的例子也有很多，比如像用一個ipad和一個iphone通訊，ipad可以認為是central，iphone端是peripheral,這種情況下在iphone端就要使用上圖右邊部分的類來開發了。

作為一個中心（central）要實現完整的通訊，一般要經過這樣幾個步驟：（1）建立中心角色—

（2）掃描外設（discover）（通過接收從設備廣播來掃描、發現設備，獲得peripheral ID）—

a, 如果數據中已經和某些藍牙設備綁定，可以使用BluetoothAdapter.getBondedDevices();方法獲得已經綁定的藍牙設備列表。通過指定特定的peripheral的UUID,central只會discover這個特定的設備。

b, 搜索周圍的藍牙設備受用BluetoothAdapter.startDiscovery()方法

c, 搜索到的藍牙設備都是通過廣播返回，so..。需要注冊廣播接收器來獲得已經搜索到的藍牙設備（3）連接外設(connect)（根據peripheral ID連接指定的外設）—

（4）掃描外設中的服務和特征(discover)（一個設備里的服務和特征往往比較多，一般會在發現服務和特征的回調里通過service、characteristic UUID去匹配我們關心那些）—

（5）與外設做數據交互(explore and interact)—

（6）斷開連接(disconnect)。

2, 設備ID描述DID

每個與蘋果設備兼容的藍牙接入都必須：支持藍牙設備ID描述，1.3版本或者更高；使用藍牙SIG分配的Assigned Numbers文檔中的公司標識作為他的Vendor ID值，也就是VID，如果生產商沒有藍牙SIG公司標識，那么藍牙HID描述接入可能會使用USB Implementers Forum分配的VID；使用他的VID值來標識最終的產品生產商；使用版本值來唯一標識軟件的版本；使用ProductID值唯一標識產品。Device ID描述使得蘋果產品能夠識別遠程的藍牙接入，該信息可以用來在與遠程接入交互的時候連接藍牙描述間的交替互操作。因此Device ID中的信息記錄非常重要。

理想情況下，這兩個設備應該有不同的產品ID。但是，當他們擁有完全相同的硬件、軟件和特性的時候擁有相同的ProductID也是可以允許的。如果他們有任何的不同，就都應該有不同的Product ID。

3，IOS的藍牙低功耗

藍牙4.0標準引入了藍牙低功耗，一種針對有限電池資源的藍牙接入的無線技術。如果支持藍牙低功耗的話，接入點需要支持下面的這些特性。（這里更多的是藍牙芯片商要做的事情）

角色

藍牙接入需要實現藍牙4.0標準中定義的外圍角色 廣告通道

藍牙接入需要在所有三個廣告通道中針對每個廣告事件進行廣告 廣告PDU 藍牙接入需要使用如下廣告PDU中的一個：ADV_IND；ADV_NOCONN_IND；ADV_SCAN_IND。其中ADV_DIRECT_IND不推薦使用。廣告數據

由藍牙接入發送的廣告信息應該至少包含藍牙4.0標準中包含的如下信息：Flags；TX Power Level；Local Name；Services。如果需要降低電量消耗或者并不是所有的廣告數據都適合放入到廣告PDU中的時候，接入點可能將Local Name和TX Power Level數據方知道SCAN_RSP PDU中。需要注意的是根據它的狀態，蘋果產品可能不會總是執行激活掃描。主要的服務應該總是放在廣告PDU中進行廣告。次要的服務不應該進行廣告。對于接入點不重要的服務信息可能會因為廣告PDU中的空間不足而被忽略。廣告數據和SCAN_RSP PDU中的掃描響應數據應該遵循藍牙4.0標準中的格式。廣告間隔

藍牙接入的廣告間隔應該慎重考慮，因為他會影響到發現和連接的性能。對于低功耗的接入，電池資源也應該被考慮在內。為了能夠被蘋果產品發現，藍牙接入應該首先使用推薦的廣告間隔20ms，并持續至少30秒。如果在這30秒內沒有被發現，那么接入點可能會選擇節省電池電量然后增加廣告間隔，蘋果推薦使用如下依次延長的事件間隔來發現藍牙接入點：645 ms；768 ms；961 ms；1065 ms；1294 ms 連接參數

藍牙接入負責用來LE連接的連接參數。接入點需要請求合適的連接參數來在合適的時候發送一個L2CAP連接參數跟新請求。如果他沒有符合如下規則，那么連接參數請求可能會被拒絕：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。蘋果設備不會讀取或者使用Peripheral Preferred Connection Parameters特性中的參數。隱私

藍牙接入應該在任何情況下都能夠滿足Resovable Private Address。因為私隱方面的考慮，蘋果設備將會使用藍牙4.0標準中定義的隨機設備地址。授權

藍牙接入不需要請求特殊的授權，如配對、認證或加密等來發現服務和特性。只有在獲取特性值或者描述值的時候可能會需要特殊的授權。9 配對

藍牙接入不應該請求配對。如果處于安全考慮，接入點需要與Central建立綁定關系，外圍可以使用Insufficient Authentication錯誤碼在必要的時候拒絕ATT請求。因此蘋果設備可能會需要按照既定的安流程程來執行過程。配對可能會需要基于蘋果產品的用戶認證。服務

通用接入描述服務：藍牙接入應該實現按照藍牙標準4.0中的Device Name特性 通用屬性描述服務：只有當接入有能力在生命周期內更改他的服務的時候，該接入點才需要實現Service Changed特性。蘋果產品可以使用Service Changed服務特性來決定它是否可以使用之前讀取的或者緩存的來自設備的信息。設備信息服務：藍牙接入應該實現設備信息服務。服務的UUID不應該包含在廣告數據當中。如下的特性需要被支持：Manufacturer Name String；Model Number String；Firmware Revision String；Software Revision String

4，IOS APP開發 的藍牙操縱API

手機APP要想獲得藍牙設備的一些額外的信息如電量或者操作藍牙設備，必須通過IOS API。那么IOS底層必然有某種方式來與藍牙設備交互。那么電量通過什么來讀寫呢？自定義 service characteristic？

任何免提的藍牙耳機都可以在iOS設備的狀態欄中顯示一個用來標識他電池電量的圖標。這個特性被所有的iOS設備所支持，包括iPhone、iPod和iPad。耳機的藍牙知識通過兩個iOS藍牙HFP AT命令：HFP Command AT+XAPL

HFP命令AT+XAPL 描述：允許通過耳機自定義AT命令 發起者：耳機

格式：AT+XAPL=[vendorID]-[productID]-[version],[features] 參數：

vendorID: 標識生產商的vendor ID的十六進制表示，但是沒有0x前綴productID: 標識生產生的product ID的十六進制表示，但是沒有0x前綴version: 軟件的版本features: 用10進制標識的位標識: 1 = 耳機支持電池電量報告2 = 耳機暫停或者正在充電其他值保留

例子: AT+XAPL=ABCD-1234-0100,3響應: +XAPL=iPhone,[features] HFP命令AT+IPHONEACCEV 描述：報告耳機的狀態變更發起者：耳機格式：AT+IPHONEACCEV=[Number of key/value pairs ],[key1 ],[val1 ],[key2 ],[val2 ],...參數：

Number of key/value pairs : 接下來參數的數量key: 被報告狀態變化的類型 = 電量等級2 = 暫停狀態 val: 更改的值

Battery events:0-9之間數字的字符串 A string value between '0' and '9'.Dock state: 0 = undocked, 1 = docked.Example: AT+IPHONEACCEV=1,1,3

（五）硬件接口

一般藍牙芯片通過UART、USB、SDIO、I2S、PcCard和主控芯片通信。如下圖所示，通過UART和主控芯片通信。

最后叮囑：大家有好的的藍牙通信的資料鏈接在下面留言分享下~多謝?(^?^*)

第四篇：基于.Net三層架構高校戶籍管理系統設計與實現

基于.Net三層架構高校戶籍管理系統設計與實現

摘 要：為了實現對高校戶籍科學化、規范化和動態化管理，提出了一種基于.Net三層架構技術的高校戶籍管理系統解決方案，研究了戶籍管理系統數據訪問層、基本邏輯層和頁面表示層的設計及實現。實踐證明了解決方案的有效性。

關鍵詞：Net；戶籍管理；三層架構

中圖分類號：TP311.52 文獻標識碼：A 文章編號：1672-7800（2011）09-0071-02 系統業務分析??

戶籍管理系統旨在實現對高校戶籍的科學化、規范化和動態化管理。通過對戶籍科相關人員所做需求分析，該系統必須實現以下功能：①戶籍信息管理：包括戶籍基本信息管理，教師和學生戶籍基本信息、相片管理、戶口遷入、遷出、注銷、遷移及借用等信息的增加、刪除和更新；②信息查詢管理：包括戶籍基本信息查詢、學生信息查詢、戶口遷入、遷出、注銷、遷移及借用信息查詢等；③收費管理：學生畢業之后，學校免費保管學生戶籍兩年，兩年過后按照一定的標準收取保管費用。此模塊主要包括戶籍保管費用的收取和退費等操作；④操作日志管理：戶籍科操作人員的日常工作無法量化，收費操作需要規范以避免費用的多收、少收、漏收和徇私舞弊的情況的發生。此模塊將操作人員的所有關鍵操作記錄在案，以備出現問題時，有據可查；⑤學院信息管理：此模塊主要包括學生學院和專業信息的增加、刪除、更新和查詢；⑥系統維護：此模塊用來維護用戶基本信息、管理員的權限以及數據庫的安全，防止非授權用戶對系統有意或者無意的破壞。??

系統架構??

2.1 系統整體架構??

分層應用設計當下非常流行。它對系統的性能、可擴展性、可移植性、安全性等提供了有力的保障。經典的分層架構開發模式將系統分為3個層次，即數據訪問層、基本邏輯層和頁面表示層。當然，每個層次可能分解為更小的子層次以保證系統功能的合理設計。戶籍管理系統的整體架構如圖1所示。??

圖1 系統整體架構??

2.2 數據訪問層設計??

數據訪問層負責管理數據庫的物理存儲、備份與恢復。主要包括數據庫的連接與存取操作，即數據庫表的查詢、更新，增加和刪除操作。數據訪問層接口對數據訪問邏輯進行抽象，以此對不同的數據庫（SQL Server，Oracle等）進行統一的管理。通過封裝類調用數據庫的存儲過程，同時，上層基本邏輯層提供統一的調用接口。??

2.3 基本邏輯層設計??

基本邏輯層作為整個系統的邏輯處理中心，主要負責管理系統的業務邏輯和規則。系統的邏輯處理都被抽象為本層的不同的邏輯接口。邏輯層接口處于數據訪問層和頁面表示層之間，對上層提供接口調用，調用下層數據訪問層接口連接數據庫，而非直接連接數據庫，降低了層與層之間的耦合度。修改數據訪問層的接口實現，不需要修改基本邏輯層代碼。??

2.4 頁面表示層設計??

頁面表示層負責接收界面輸入和邏輯結果的顯示。包括頁面的布局、控件的使用等。頁面表示層調用基本邏輯層的接口進行邏輯處理。系統邏輯處理發生變化時，只需要修改基本邏輯層接口實現，不會影響頁面表示層的編碼。??

數據庫設計??

好的數據庫的設計是信息系統的一個重要組成部分。戶籍管理系統涉及到10多個表的設計和60多個存儲過程的編寫。限于篇幅，這里不一一列出。??

主要技術及開發工具??

4.1 權限管理策略??

系統的訪問控制策略使用基于用戶角色的訪問控制策略。這種訪問控制策略已經廣泛應用于系統操作、數據庫及應用項目中。角色訪問控制策略有利于確認和管理用戶身份，對不同用戶分配不同的操作權限。??

4.2 系統安全策略??

為了防止未經授權的用戶訪問系統資源，給系統帶來危害，同時考慮到戶籍管理系統數據錄入時間一般集中在開學等時間，大批量的數據錄入之后，一旦發生問題，導致數據丟失，再次重復錄入數據，工作量巨大。系統使用自動備份與手工備份相結合的方式，用戶可以通過界面，手工備份與恢復先前的數據庫。考慮到數據庫的移植，在數據訪問層引入“抽象工廠模式”，根據數據庫的不同，提供實現不同數據庫結構的數據業務邏輯對象，使用.Net框架的反射機制，在系統運行時動態決定調用的數據庫類型。??

4.3 并行開發策略??

三層架構的優勢之一系統架構清晰，合理的分配開發任務，同時保證系統的并行開發，以此提高效率。系統開發過程中，引入實體類和基本邏輯層和數據訪問層的共同接口，保證解決方案程序與數據庫的并行開發，兩者相關部分都完成之后，通過接口，完成數據庫庫記錄與實體類的映射即可。??

4.4 版本控制策略??

項目開發是一個團隊協作，迭代開發的過程，版本的控制與管理非常重要。項目開發過程中使用visual svn和tortoise svn進行系統解決方案、源代碼的控制，單獨設立版本控制服務器，團隊所有成員從服務器中更新項目的最新版本，每天工作完成之后，單獨提交各自負責部分的開發工作，使服務器中的版本始終保持最新狀態。??

4.5 項目開發主要工具??

項目開發成員使用resharper和coding style enforcer工具保證編碼風格的統一，使用NUnit，NCoverage等工具結合cruise control.net每日構建技術，進行測試及覆蓋率檢測，保證產品的質量。??

結束語??

戶籍管理系統采用三層架構進行設計、開發，系統接口更加清晰，滿足模塊獨立性，層內高內聚、層間低耦合的原則，有利于開發者分工合作，具有很強的通用性、可維護性和可擴展性，可以僅作少量修改升級為Web Service架構，為系統維護及功能擴展留下足夠的空間。??

參考文獻：

［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］ 陳友良，盛可軍，王陽陽.基于ASP.NET三層架構軟件的研究與開發［J］.現代電子技術，2010(6).［3］ 江義火.基于ASP.NET MVC2的三層架構應用系統開發研究與實現［J］.軟件導刊，2010(12).（責任編輯：周曉輝）

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

第五篇：公交查詢系統設計與實現論文

公交查詢系統設計與實現論文

1引言

隨著城市經濟的發展、規模的擴大以及人口的增長，城市交通問題日益突出。降低出行時間將使所有的公交利用者產生效益，快速的交通、更好的信息及更好的市場可以提高公交的形象，能夠增加公交乘坐者。城市公共交通運輸以其覆蓋面廣、經濟、快捷的特點，成為絕大多數出行者的首選方式，也是各地城市政府大力發展的一種交通方式。本地市民特別是外來旅游、出差、就醫等急需了解本地道路情況的人可以利用本系統方便快捷的查詢出所有符合他們要求的公交路線，對他們的出行和生活提供幫助。我國城市公交乘客信息系統的發展處于一個落后的水平,廣大乘客可以獲得信息的方式很少,公交信息的完整性和準確性得不到保證，而且還沒有專門的機構負責信息的發布和管理。出于這個目的,在老師的指導下,我設計了這個城市公交線路查詢系統。在對公交乘客出行心理特征進行分析的基礎上,考慮乘客選擇公交線路決策的因素,進行程序關鍵部分的框架設計。

現階段，人們的出入方式主要還是來源于城市公交，特別是對于那些到外地出差、打工，進行商業有關或其他事情需要在外地進行短暫停留的人而言，公交對他們是必不可少的，但是對于那個不屬于自己所熟悉的城市，坐公交也是一個很大的難題，因此，開發一個公交查詢系統就顯得非常的重要。本系統的核心是對選擇好的車次進行路線的查詢，或者輸入所要查詢的車站名，點擊“查詢”按鈕，查詢所有含有該站的車次及相應的停靠站。此處既可以“精確查詢”也可以是“模糊查詢”，“模糊查詢”主要方便那些對站名不是很清楚，但知道其中的一部分的乘客，系統可以幫助他們快速的查出。

1.1論文的研究內容

公交查詢系統是一個取代過去由人工查詢的查詢系統。本論文論述了一個基于瀏覽器/服務器（B/Srowser/Server）模式的公交查詢系統的研究和實現的過程.論文從開發平臺和工具談起，對ASP.NET服務器所提供的組件及其屬性和方法做了一般介紹，更重要的是闡述了ASP.NET的數據庫訪問組件ADO.NET的使用方法。最后，詳細介紹了如何創建“公交查詢系統”的全部過程。系統的開發工具與環境

2.1ASP.NET簡介

ASP.NET是一種建立在通用語言上的程序構架，能被用于一臺

Web務器來建立強大的應用程序。ASP.NET提供許多比現在的開發模式強大的的優勢。AS.PNET建立在.NET Framework的編程類之上，它提供了一個web應用程序模型，并且包含使生成web應用程序變得簡單的控件集和結構。ASP.NET包含封裝公共用戶界面元素（如文本框和下拉菜單）的控件集。但這些控件在務器上運行，并以HTML的形式將它們的用戶界面推送到瀏覽器。在服務器上，這些控件公開一個面向對象的編程模型，為web開發人員提供了面向對象的編程的豐富性。ASP.NET還提供結構服務（如會話狀態管理和進程回收），進一步減少了開發人員必須編寫的代碼量并提高了應用程序的可靠性。另外，ASP.NET 使用這些同樣的概念使開發人員能夠以服務的形式交付軟件。使用ML webservices功能ASP.NET開發人員可以編寫自己的業務邏輯并使ASP.NETT結構通過SOAP交付該服務。Visual Studio.NET是一套完整的開發工具，用于生成應用程序、XML Web services、桌面應用程序和移動應用程序。Visual Basic.NET、Visual C++.NET、Visual C#.NET和VisualJ#.NET全都使用相同的集成開發環境(IDE)，該環境允許它們共享工具并有助于創建混合語言解決方案。另外，這些語言利用了.NET Framework的功能，此框架提供對簡化應用程序和XML Web services 開發的關鍵技術的訪問。

2.1.1ASP.NET技術的優點

ASP.NET是一種將各種Web元素組合在一起的服務器技術，是一個統一的Web開發平臺，它提供了生成一個完整的Web應用程序所必須要的各種服務。與以前的開發模型相比較，它提供了以下數個重要的優點：

(1）增強的性能。ASP.NET是在服務器上運行的編譯好的公共語言運行庫代碼。與被解釋的前輩不同，.NET可利用早期綁定、實時編譯、本機優化和盒外緩存服務。這相當于在編寫代碼之前便顯著提高了性能。(2）世界級的工具支持。ASP.NET框架補充了Visual Studio集成開發環境中的大量工具箱和設計器。WYSIWYG編輯、拖放服務器控件和自動部署只是這個強大的工具所提供功能中的少數幾種

（3）威力和靈活性。由于ASP.NET基于公共語言運行庫，因此應用程序開發人員可以利用整個平臺的威力和靈活性。.NET框架類庫、消息處理和數據訪問解決方案都可從 Web 無縫訪問。ASP.NETT也與語言無關，所以可以選擇最適合應用程序的語言（如C#），或是跨多種語言分割應用程序。另外，公共語言運行庫的交互性保證在遷移到ASP.NET時保留基于COM的開發中的現有投資。（4）簡易性。ASP.NET使執行常見任務變得容易，從簡單的窗體提交和客戶端身份驗證到部署的站點配置。

（5）可管理性。ASP.NET采用基于文本的分層配置系統，簡化了將設置應用于服務器環境和Web應用程序。由于配置信息是以純文本形式存儲的，因此可以在沒有本地管理工具幫助的情況下應用新設置。此“零本地管理”哲學也擴展到了ASP.NET框架應用程序的部署。只需將必要的文件復制到服務器，即可將ASP.NET框架應用程序部署到服務器。不需要重新啟動服務器，即使是在部署或替換運行的編譯代碼時。

（6）可縮放性和可用性。ASP.NET在設計時考慮了可縮放性，增加了專門用于在聚集環境和多處理器環境中提高性能的功能。另外，進程受到ASP.NET 運行庫的密切監視和管理，以便當進程行為不正常（泄漏、死鎖）時，可就地創建新進程，以幫助保持應用程序始終可用于處理請求。2.1.2.NET Framework概述 NET Framework是用于生成、部署和運行XML Web services 和應用程序的多語言環境。它由以下幾個主要部分組成：

公共語言運行庫

運行庫實際上在組件的運行時和開發時操作中都起到很大的作用，盡管名 稱中沒有體現這個意思。在組件運行時，運行庫除了負責滿足此組件在其他組件上可能具有的依賴項外，還負責管理內存分配、啟動和停止線程和進程，以及強制執行安全策略。在開發時，運行庫的作用稍有變化；由于做了大量的自動處理工作（如內存管理），運行庫使開發人員的操作非常簡單，尤其是與今天的COM相比。特別是反射等功能顯著減少了開發人員為將業務邏輯轉 變為可重用組件而必須編寫的代碼量。

統一編程類

該框架為開發人員提供了統一的、面向對象的、分層的和可擴展的類庫集(API)。目前，C++開發人員使用Microsoft基礎類，而Java開發人員使用Windows 基礎類。框架統一了這些完全不同的模型并且為Visual Basic和JScript程序員同樣提供了對類庫的訪問。通過創建跨所有編程語言的公共 API 集，公共語言運行庫使得跨語言繼承、錯誤處理和調試成為可能。從JScript到C++的所有編程語言具有對框架的相似訪問，開發人員可以自由選 擇它們要使用的語言。2.2 ADO.NET概述

ADO.NET并不是ADO的升級版本，它是全新的面向對象模型。比ADO更適應于分布式及Internet等大型應用程序環境，為了多人同時存取更具擴展性，ADO.NET的數據存取采用的是離線存取模式，可說是專門為.NET臺設計的數據存取結構。它具有簡單地訪問關系數據、可擴展性、支持多層應用程序、統一XML和關系數據訪問的特點。ADO.NET的主要目標是提供對關系數據的簡單訪問功能。坦白的說，易于使用的類描述關系數據庫中的表、列和行。另外，ADO.NET引入了DataSet類，它代表來自封裝在一個單元中的關聯表中的一組數據，維持他們之間完整的關系。這是在ADO.NET中的新概念，可以顯著的擴展數據訪問接口的功能。ADO.NET可以擴展——它為插件.NET 數據提供者（也稱為可管理提供者）提供了框架，這些提供者被構建，以便從任何數據源讀取和寫入數據。ADO.NET提供了兩種內置的.NET數據提供者，一種用于OLE DB數據源，另一種用于Microsoft SQL Server。可以通過OLE DB訪問數據格式（比如Microsoft Access）、第三方數據庫和非關系數據另外，Microsoft最近預演了用于ADO.NET的ODBC.NET數據提供者，它允許.NET 訪問更多的舊的數據格式和第三方數據庫。ADO.NET用于多層應用程序。這是當今商業和電子商務應用程序最常見的體系結構。在多層體系結構中，應用邏輯的不同部5分1運a行s在p多x個服務器或進程中，每一部分就稱為一層。ADO.NET使用開放的Internet標準XML格式在層之間通信，允許數通過Internet防火來傳遞，并允許以非Microsoft技術來實現一層或多層。那么在Visual Studio.NET中ADO.NET訪問數據庫分為二種。一種是SQL Server 數據庫，另一種是其任何類型的數據庫。本系統的后臺數據庫為SQL Server2005,因此是通過SQLConnection、SqlCommandSqlDataAdapter、DataSet等幾個主要的數據訪問對象來訪問數據的.需求分析

3.1系統需求分析

隨著我國經濟的高速發展，人們生活水平的提高，越來越多的人開始熱衷于到外地旅游。那么對于這些外來旅游者，首先搞清這個城市的公交路線顯的很重要！我的家鄉沈陽，作為一個旅游城市，每年都要吸引大量的游客，為了滿足這些游客熟悉公交路線的需求，特以公交查詢系統為設計課題。本軟件不僅能給游客帶來方便，也能給廣大市民提供方便。我認為這樣的系統應該具有很好的實用性！開發本系統的目標就是立足廣大乘客的實際，著眼于公交業的未來發展，規范公交管理，提高服務質量，方便乘客查詢，并為此設計該系統。人們生活水平的提高，越來越多人喜歡旅游，但是第一次來一個陌生的城市，肯定對公交路線不熟悉，所以必定需要一個能查看具體公交線路的公交系統。有些只知道一個站的某幾個字或一個車次的某幾個數字，所以本系統將給出站點的模糊查詢，方便用戶的查詢，有些只知道車次

或某個站點，本系統也給出了公交線路查詢、公交站點查詢、公交換乘查詢，進一步方便大家的出行，但也有用戶什么都查不到，想留言問問人，所以再搞個留言板很有必要，方便大家交流以及解答各種疑難問題！本系統采用結構化設計的方法來實現系統總體功能，提高系統的各項指標，即將整個系統合的劃分成各個功能模塊，正確地處理模塊之間和模塊內部的聯系以及和數據庫的聯系，定義各模塊的內部結構，通過對模塊的設計和模塊之間關系的系統來實現整個系統的功能前臺主要有3個模塊，線路查詢、站點查詢、公交換乘模塊和后臺管理模塊

功能名稱：線路查詢

功能概述：可以獲得要查詢公交所通過的各個站點。

功能名稱：站點查詢

功能概述：通過輸入的指定站點查詢經過該站點的公交。

功能名稱：公交換乘查詢

功能概述：分為公交直達、公交一次換乘，主要體現那些不可直達需要轉車的路線的所有換法。(如果用戶輸入的起始點和終點，有一條及一條以上的公交線可以直達的，則為公交直達；如果輸入的起始點和終點，沒有一條公交線可以直接到的，系統將會給出一次換乘的方案，則為公交一次換乘)功能名稱：后臺管理

功能概述：用于管理員登陸，添加、修改、刪除公交線路，修改信息資料、安全密碼，回復留言板等功能。

本系統提供了的車次查詢功能、路5線1查A詢S功P能X。乘客可以方便的進行查詢，以防乘錯車次。當然有些功能的智能化不是很強，系統有待進一步來完善。

3.2 數據庫需求分析

數據庫在一個信息管理系統中占有非常重要的地位，數據庫結構設計的好壞將直接對應用系統的效率以及實現的效果產生影響。合理的數據庫結構設計可以提高數據存儲的效率，保證數據的完整和一致。

數據庫技術是由傳統的文件系統發展而來的，從層次模型、網狀模型發展到關系模型。數據庫技術是數據管理的最新技術，是計算機科學的一個重要分支，它能指導我們正確地設計數據庫系統，它的出現極大地促進了計算機應用的發展。采用數據庫技術的原理和方法可以有效地設計實用的數據庫系統。一個完整的數據庫系統包括數據庫管理系統（DBMS），數據庫管理員（DBA）、數據庫（DB）、應用程序和相應的硬件設施。

目前許多數據庫管理系統都基于關系模型，關系模型的主要特點是用表格結構表達實體，用鍵表示實體與實體之間的聯系。與層次模型和網狀模型相比，關系模型比較簡單，容易為初學者接受。關系模型是由若干個關系模式組成的集合，關系模式相當于記錄類型，它的實例稱為關系。每個關系是一張表格。表格簡單，用戶易懂，用戶只需用簡單的查詢語句就可以對數據庫進行數據操作，并不涉及到存儲結構，訪問技術等細節。關系模型是數學化的模型，要用到集合論，離散數學等知識。SQL語言是關系數據庫的代表性語言，已經得到廣泛應用。

在設計數據庫時，應注意數據的安全性，保證數據的安全，防止非法用戶訪問數據庫，以免泄露重要信息，同時也能51防A止s非法用戶的蓄意破壞，有許多保護數據的方法，如采用用戶標識，口令密碼或訪問控制等方法。一個成功的數據庫應用系統應具有用戶標識，每一個合法用戶具有一個用戶名和相應的口令，進入數據庫應用系統前必須輸入正確的口令，否則無法進入系統，這就保證了只有合法的用戶才能操作數據庫系統。為了保證數據的合法語義，必須對數據庫的數據進行完整性約束，即防止用戶輸入不合語義的數據。

在設計應用軟件時，應嚴格按照軟件工程學的方法進行設計，傳統的方法采用瀑布模型，從問題定義、可行性分析、需求分析、概念設計、總體設計、系統實現、編碼和軟件測試、運行和維護等軟件生命周期內，每一階段均在前一階段的基礎上進行設計，并在每一階段有相應的文檔資料。設計數據庫系統時應該首先充分了解用戶各個方面的需求，包括現有的以及將來可能增加的

需求。數據庫設計一般包括如下幾個步驟：數據庫需要分析，數據庫概念結構設計，數據庫邏輯結構設計。

4系統概要設計

4.1概述

本階段設計的基本目標是解決系統如何實現問題，也叫做概要設計，本階段主要任務是劃分

出系統的物理元素及設計軟件的結構，完成軟件定義時期的任務之后就應該對系統進行總體設

計，即根據系統分析產生的分析結果來確定這個系統由哪些系統和模塊組成，這些系統和模塊又如何有機的結合在一起，每個模塊的功能如何實現。系統設計的目標是使系統實現擁有所要求的功能，同時，力爭達到高效率、高可靠性、可修改性，并且容易掌握和使用。模塊化的依據是：

把復雜問題分解成許多容易解決的小問題。原來的問題也就變得容易解決。模塊化設計是把大型軟件按照一定的原則劃分成一個較小的相對功能獨立又相關聯的模塊。每個模塊完成一個特定的子功能。把這些模塊結合起來組成一個整體。完成指定的功能，滿足問題的要求。采用模塊化原理的優點在于可以使軟件結構清晰，容易測試和調試。從而提高軟件的可靠性，可修改性。有助于軟件開發的組織管理。一個大型軟件可分別編寫不同的模塊。4.2功能模塊劃分 查詢系統模塊

該模塊實現公交查詢功能。可實現按線路查詢、站點查詢和起點—終點查詢三種查詢方式。錄入系統模塊該模塊實現數據的新增、修改、刪除功能。

4.3.1 數據庫概念結構設計

在系統設計的開始，我首先考慮的是如何用數據模型來數據庫的結構與語義，以對現實世界進行抽象。目前廣泛使用的數據模型可分為兩種類型，一種是獨立于計算機系統的“概念數據模型”，如“實體聯系模型”；另一種是直接面向數據庫邏輯結構的“結構數據模型”。在本系統中我采用“實體聯系模型”（ER模型）來描述數據庫的結構與語義，以對現實世界進行第一次抽象。ER模型直接從現實世界抽象出實體類型及實體間聯系然后用ER圖來表示數據模型。它有兩個明顯的優點：接近于人的思維，容易理解；與計算機無關，用戶容易接受。但它只是數據庫設計的第一步。E-R圖是直觀表示概念模型的工具，它有三個基本成分：

（1）矩形框，表示實體類型（考慮問題的對象）。（2）菱形框，表示聯系類型（實體間的聯系）。（3）橢圓形框，表示實體的屬性。實體和屬性的定義如下：

管理員表（登陸ID，登錄姓名，登錄密碼）站名表（站名編號，站名）

車輛線路編號表（車次，車線類型）

線路表（線路編號，車次，站名，次序）

車輛表（車輛編號，車次，車輛類型，服務類型，票價，IC 卡類型，運行區間）

冬季發車時間表（車次，編號，首班時間，末班時間）

夏季發車時間表（車次，編號，首班時間，末班時間）

4.3.2數據庫邏輯結構設計

本系統創建的SQL數據庫名稱為城市公交查詢系統。并將數據文件和日志文件保存在公交查詢系統APP_DATA文件夾中。①管理員表(LoginTable)

管理員表存放登陸系統所需要的用戶名和密碼，登錄后臺時需要訪問此表。

②站名表

站名表存放站名等數據，修改站名需要訪問此表。

③車輛線路編號表

車輛線路編號表存放線路編號等數據，修改車輛線路編號將要訪問此表。

④線路表

線路表存放公交車線路的數據，修改車輛線路需要訪問此表。

5詳細設計與實現

5.1.連接數據庫的包含文件

在動態網站中，調用數據庫中的數據是十分頻繁的，為了避免編寫重復的代碼。編寫一個數據庫連接文件是非常重要的。DB.cs

文件中包含了本系統中的數據庫的連接代碼。本系統的數庫 的連接代碼如下：

public static SqlConnection createConnection(){

SqlConnection

con=new SqlConnection(“server=.;database=城市公交查詢系統;uid=sa;pwd=;”);return con;}

5.1.1新增車次線路

此模塊為管理員操作，如當地出現新的公交線路，或原有公交車線路有新的站點加入，管理員可以登錄此表，及時添加線路和站點的信息，以保證車次線路的及時更新，方便用戶查詢。添加車次的界面如圖所示。

在輸入相關車次信息后便進入站名添加過程如圖

5.1.2新增車次線路

此模塊為管理員操作，如當地出現新的公交線路，或原有公交車線路有所變動是，管理員可以登錄此模塊，及時添加相關的線路圖，以保證車次線路圖的及時更新，方便用戶查詢。添加的界面如圖

5.1.3刪除車次以及無效站點

此模塊同樣為管理員操作，如當地哪個公交線路已經被廢除，或原有公交車線路有哪個站點被刪除，管理員可以登錄此表，及時刪除線路和站點的信息，以保證車次線路的及時更新，方便用戶查詢。刪除的界面如圖

5.1.4刪除線路圖

該模塊在管理員系統中實現，如當地哪個公交線路已經改變，管理員可以登錄此模塊，及時刪除線路圖信息，以保證車次線路圖的及時更新，方便用戶查詢。刪除的界面如圖

6測試與維護

6.1 創建和測試應用程序

為了確保本系統能夠正常運行，需要在發布之后做一次較全面的測試。現將具體操作及過程

舉例說明如下：

創建和測試應用程序應是交替進行的，既要注意開發的效率也要注意它的穩定性。每編寫一個模塊，就要對這個模塊進行測試，看它能否根據特定的要求工作。及早發現問題，及早解決，否則到最后再來測試的話，難度會大大增加。6.2測試項目

在MIS開發過程中采用了多種措施保證軟件質量，但是實際開發過程中還是不可避免地會產生差錯，系統中通常可能隱藏著錯誤和缺陷，不經周密測試的系統投入運行，將會造成難以想象的后果，因此系統測試是MIS開發過程中為保證軟件質量必須進行的工作。大量統計資料表明，系統測試的工作量往往占MIS 開發總工作量的40%以上。因此，我們必須重視測試工作。由于程序中隱藏的缺陷只在特定的環境下才有可靠顯露，系統缺陷通常是由于對某些特定情況考慮不周造成的。因此測試不是為了表明程序正確；成功的測試也不是沒有發現錯誤的測試。

有意義的軟件測試應該是從“破壞”軟件系統的角度出發，精心設計最有可以暴露程序系統缺陷的測試方案。因此軟件測試的目標應該是以盡可能少的代價和時間找出軟件系統中潛在的錯誤和缺陷。

總結

在公交數字化的時代，公交系統的設計者應當以乘客需求為首位，調整服務策略，滿足社會的需要和乘客的需要，充分發揮公交系統交通中心的作用。本系統基本達到了預定的設計目標，但是在系統的實際化應用中仍需要改進和提高公交查詢系統的服務職能。系統的不足與改進方案：

在數據庫設計方面，還有待改進，數據庫設計也可采用別的形式，比如：可以用一個字段作為站點字段，另一個字段作為經過該站點的車次字段，只要找到經過某個站點最多的車次，就可以設計該字段的類型以及長度。其次，系統的實際應用化欠缺，可以通過使用根據起點站、終點站來確定那條路線，給出多種乘車方案的方法改進。線路的更新應該可以通過調整數據庫次序的方法來更新。同時，界面的設計不夠美觀版面的設計以及查詢結果的顯示不夠人化，視覺效果不佳。應當參照一些比較美觀的網站設計進行色彩的調整，同時亦可以加入更多的FLASH效果使得頁面更具動態性。

致謝

時光飛逝，一轉眼我的大學生活就要結束了。這兩年我學到了很多很多的知識，是我人生的一個轉折。我之所以能取得這些成績，除了有自己的努力外，在我的學習，生活中還得到了很多人的關心和幫助。在此我要對他們表示衷心的感謝。

首先，我要感謝我的畢業指導老師。在連續數月的畢業設計中，她不遺余力地指導和幫助我。在她孜孜不倦的教誨下，我順利地完成了畢業設計。老師對工作認真負責的態度，對學生無私的關懷，使我受益良多。我衷心地感謝她。在這里我還要感謝所有指導過我的老師們，沒有你們的培養我無法完成兩年的大學學業還有，我能有今天，是與我父母的辛勤培養分不開的，他們為我付出了一切。我將在以后的學習、工作中再接再厲，盡我最大的努力做到最好來報答父母的養育之恩。

參考文獻

[1]曹祖圣.吳明哲.Visual C#.NET 程序設計經典.北京:科學版社,2004.P.50-53.[2]宣小平.ASP.NET數據庫系統開發實例導航.上海:人民郵電出版社,2003.P.121-130.[3]金銀秋.數據庫原理與設計.北京:科學出版社,2003.P.201-230.[4]張海藩.軟件工程.北京:人民郵電出版社2002.P.75-80.[5]朱曄.ASP.NET 第一步——基于C#和ASP.NET2.0.北京:清華大學出版社,.2007-7-1.P.301-310.[6]譚振林.道不遠人——深入解析ASP.NET 2.0 控件開發.北京:子工業出版社。2007-9-1.P.125-140.[7]哈特 ASP.NET 2.0經典教程——C#篇孟憲瑞，易磊.北京:人民郵電出版社.2007-2-1.P.20-40.[8]朱印宏，熊利榮.Dreamweaver 8完美網頁設計——ASP動態網頁設計篇.北京 中國電力出版社.2006-10-1.P.63-72.[9]郝剛ASP.NET 2.0開發指南.北京:人民郵電出版社.2006-5-1.P.53-55.