第一篇:高可用性软件架构设计和实现论文
摘要:硬件冗余可以极大地提高计算机应用系统的可用性,然而,一旦关键硬件出现故障或数据库宕机,正在进行中的业务流程通常会中断。探讨了一种如何实现应用系统高可用性的软件架构的设计方案,以弥补纯硬件冗余应用系统的不足。
关键词:高可用性;软件容错;分布式数据库
在业内,计算机应用系统的可用性定义为计算机应用系统保持正常运行时间的百分比,通常用表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.