本文是一篇工程硕士论文，工程硕士论文只能有一个主题（不能是几块工作拼凑在一起），这个主题要具体到问题的基层（即此问题基本再也无法向更低的层次细分为子问题），而不是问题所属的领域，更不是问题所在的学科，换言之，研究的主题切忌过大。（以上内容来自百度百科）今天为大家推荐一篇工程硕士论文，供大家参考。
专业工程硕士毕业论文范文精选篇一
第 1 章 绪 论
1．1 数字复合信号传输设备的发展
随着国家对数字信息化大力推进与发展，模拟信号已经不能满足人们对内容互动、多样化、个性化的要求，于是基于多种数字复合信号技术的传输流 传输设备应运而生，有国家制定的标准，还有企业标准，并利用新的标准开发出各种产品，为模拟转数字提供了夯实的物理基础，并提供了从通道到内容的各种实时监测接口协议，为数字复合信号传输设备的 提供了很好的基础，数字复合信号传输设备的 的优点主要体现在：数字复合信号传输设备的 将传统的模拟信号转换成数字信号后，提供了高清晰度的数字内容，比模拟时收看到的内容更加清晰；采用此技术，可以利用原有模拟通道不变的情况下，能传输 6-12 套经过压缩解码过的数字流媒体，提高了资源的利用率；由于采用数字信号进行传输，所以可以方便的对信号进行加密和解密，从而实现通信的安全性；数字复合信号传输设备的 还可以提供大量的多媒体信息，用户可选择收看个性化的内容。正是因为多路调制和解调、激光技术、光电转换、模数转换在数字信号的发生革命性的发展，使得数字复合信号的传输设备厂家应运而生，2012 年国家广电总局大力投入，做模数转换工作和普及数字复合信号传输设备的 ，广播电视数字化已被国家列入重点计划，并被纳入正在制定的国家中长期科技发展规划，2015 年随着物联网的快速发展，这些技术得到了飞速发展。
………
1．2 对数字信号的分析监测的必要性
随着数字复合传输技术的应用日渐成熟，我国各种传输网络的数字化也正在进行中快速的网改，以广播电视为例，计划是 2019 年完成全部数字化，原则上取消模拟信号的传输，了保证数字复合信号传输设备的 及网络的正常运转和传输质量，必须采取相应的监测设备作为辅助手段，实时在线监测分析；因此需求而开发的码流监测和分析设备，数字多画面实时监播系统，信号防范系统；监测系统对整个前端系统进行实时监测，能快速定位到的设备包括：多路调制、解调、编解码、复用、加扰、解扰、混频和传输等多个环节；整个系统涉及的各项技术指标比较多，其中的关键参数直接影响着数字信号质量和整个系统的稳定性，所以必须对关键的技术参数进行测试和实时在线监测。在数字复合信号传输设备的 系统建设过程中，模拟信号是按照 MPEGII 标准经过抽样、量化、分析及压缩编码形成基本码流 ES（原始）流，ES 流是连续码流，不可分段，把基本码流分割成子块，并加上相应的头文件数据封包形成封包的基本码流 PES 流，PES 包和包之间可以是不连续的，在传输时将 PES 包再分段打成有固定长度 188 字节或 204 字节的传送包码流叫传输（TS）流；传输流经复用单元加入标准的 PSI 表／SI 表以及加密信息形成多路 PS 传输流，最后上传混频器，进入HFC混合网中，在传输过程中，有的会用OTT或OTI及IPQAM等各种设备，这些设备的实时信息也是监测的重点。
……..
第 2 章 数字复合信号的实时监测系统
2．1 数字复合信号传输流的复用
MPEG II 标准是 ISO／IEC 组织推出的音视频压缩的国际标准，目前全球70%的国家都在采用这一标准，图像质量达到了广播级，MPEG 4 已经达到高清和超高清级别了，被广泛应用于数字多媒体通信、数字复合信号传输设备的 、高标清视频点播、会议系统、互联网视频会议、远程医疗、互联网高清教学等领域，MPEGII 的传输 TS 流主要用于远程通信、有线广播，目前也有部分用户在用 H264、H265 等的编解码设备，数字信号监测系统是兼容这几个标准的，对于在 DVB 数字广播电视系统中，也是用数字复用技术复用后传输传送 PS 的。MPEG II 标准可分为三部分：视频、音频、操作系统（通常是嵌入式操作系统），视音频编码是针对每单路信号的图像和伴频进行，视音频编码后的包是 ES码流基本包 （又叫原始包）, ES 流经过复用封包后的包是 PES 基本流，PES基本流的包长度是不确定的，视频一般是单帧包，音频包长度一般为一个音频帧，被封包的视、音频基本码流再经过复用封包后，成为两种不同的码流，即（PS）节目信息流和传输流，在 MPEGII 系统中，数字信息复合、分离的过程又被称为系统复接、分接，由视音频的 ES 码流及数据复接生成的用于实际传输的标准信息流称为 MPEGII 传送流（TS：Transport Stream ），根据传输媒体的质量区别，MPEGII 中规定了两种复合信息流：传送流（TS：Transport Stream ）和 PS 流（PS：Program Stream）。
……..
2．2 数字传输流的比特流要求
传输流是基于数据包(Packet)的位流格式而存在，每个数据包大小是 188 字节或 204 字节，204 字节的格式仅仅在 188 字节的包后部加上 16 字节的 CRC 数据，其他格式全部是一样的；传输流的系统层是由系统层信息和有效数据负载信息构成；传输流系统层信息就是在基本数据（PES）包信息组成传输（TS）流的过程中，为了适用于信道传输和接收端单元恢复数据而添加的 TS 包头和其他相关控制信息的码流，传输流分组包是以一个 4 字节{0x47}前缀开始的，后面有一个 13 位的分组标识 PID 号信息值，PID 号信息值通过 PSl／SD 表指定包含在传输流分组中的数据内容里，具有相同 PID 值的传输流数据包分组携带仅来自同一个基本流的数据，随后是适应字段数据信息值控制字段数据信息值值，连续性计数器字段数据信息值等信息；适应字段数据信息值控制字段数据信息值表示当前包携带调整字段数据信息值和有效负载的情况时，连续性计数器字段数据信息值是具有同 PID 值的 TS 流数据包之间的连续计数值。从系统层的角度来看，TS 包的结构一般有以下几种：有调整字段数据信息值部分又有有效负载，只有调整字段数据信息值没有有效负载，只有有效负载没有调整字段数据信息值。这就是所说的有效负载指的是原来 PES 包所包含的信息，携带有系统层信息(如 PSl 和 Sl 表)的数据包不含有效负载信息。空包可以用于填充传输流，也可以再复合处理中被插入或删除，所以并不能假定空的分组会作为有效负载数据而被传送到解码单元，在此部分，有的设计厂商开发了 TS 流字幕广告插播器，见图 2.2.1B 单一传输 TS 流与混合 TS 的区别，当然这也是数字监测重点监测的部分。
…….
第 3 章 码流监测的具体分析与实现.....20
3．1 基本信息........20
3．2 电子节目指南 EPG 分析.........35
3．3 TRl01．290 错误信息值监测.......38
3．4 PS 信息......42
3．5 带宽信息........44
3．6 视音视频信息......45
3．7 数字信号的信息复用........46
3．8 数字传输流的 PCR 分析....46
3．9 软件设计与实现..........47
第 4 章 总结 .....65
第 3 章 码流监测的具体分析与实现
3．1 基本信息
传输流的基本信息实时监测包括码流传输速率、PID 实时数量、网络名称、网络节点指标、传输流所包含的 PS 数量、每个 PS 的 PS 号和 PS 名称、PS 是否被加密信息等信息；监测系统不但能实现普通的监测业务，还需具有智能布防技术实现智能布防和专业的数据库管理，并具有较高的码流采样精度，并有效的降低误报率，可实现以下功能：RF 信号分析、监测：对射频信号的性能参数（通过电平，符号率，MER,EVM,星座图和 RS 前后的 BER 等）进行实时监视、监测、分析和报警。TS 码流，TS 加扰流分析、监测：对 TS 码流（SPTS 和 MPTS）进行专业级分析，监测内容包括复用带宽的监测、TR 101 290 的监测、包间隔的监测、PCR 的监测、节目的监测、图象质量的监测，SI/PSI 的实时解表监测等等，通过具体的对信源的监测，可以让我们及时发现 DVB 平台出现错误的位置所在。ES 码流分析、监测：对数字电视独有的 ES(原始编码流)进行监测、监视，彻底解决 DTV 信源监测。数据业务分析、监测：如 EPG(电子节目指南)、游戏、股票信息、和 VOD等，满足开展 MHP 等数据业务的分析项目，可以开展更多的分析业务的“模板操作”。
……..
总结
本文主要讨论了关于数字复合信号在传输流中的实时监测与分析，同时也实现了多画面的实时报警与监测；系统性的分析与阐述了关键参数、整体结构和软件部分的设计，并详细分析了核心代码。在数字信号实时监测与分析项目中，本人负责的调研与研发任务己基本完成；该码流分析软件主要完成以下几个重要功能：目前该软件已经和数字多画面实时监测与分析联调成功，可以把实时获取的信息导入到数据库，可以实现远程实时监测，画面可以远程调度和回播。通过这次课题的认真研究，我加深了对软件编程的熟练应用技巧，对数字信号传输流的特性及数字传输网也有了更加深入透彻的了解，同时意识到码流的分析监测对数字复合信号传输设备的推广的重要性，我也有信心研制出适合我国国情的数字复合信号传输设备的监测分析设备，推动数字信息化进程。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇二
第1章 概述
1.1 项目来源
本项目来源于某个研究所的实际项目。本课题主要负责实现分布式网络环境下的服务器状态监测，保证用户对分布式网络环境中所有服务器运行状态的实时监测，支持用户个性化定制服务器监测管理参数。
1.2 项目开发目的和意义
分布式网络是由多个终端节点组成的，而且各个节点相互连接，网络中的每一个节点都有两条线与其相连，当其中的一条发生故障时，网络的通信传输可以通过另外一条路径完成，网络传输的可靠性较好。因为该种网络没有网络控制中心等，所以不会因为网络中心被攻击而出现问题[1]。分布式网络的优点是节点中相互连接，数据传输可以通过不同的路径进行，可靠性较好，但是不利于管理，而且因为节点多，所以安全性有待提高。甲骨文白皮书《OracleContact Center Anywhere 分布式网络架构》中提到分布式软件架构的重要性在于它支持镜像过程和镜像数据库等故障保险机制，进而支持热备份功能[2]。分布式网络环境下对监测服务器状态进行监测，是为了实现对分布式网络环境下服务器以及网络资源的统一管理和有效监测，能够实时获取分布式网络环境下各个节点服务器状态信息，满足对网络管理和突发事件及时应对的需要。如果忽略了网络监测的环节，将会出现很多类似未经授权以各种方式外发文件、上班时间利用网络做不应该做的事等违规违法事件发生，这些都是非常严重的安全隐患。所以在分布式网络环境下对监测服务器状态进行监测是非常必要的。本项目的目的是在 linux 环境下将大规模分布式部署的 Linux/Unix 服务器作为监测目标，实现对服务器基本性能及状态指标的监测，主要包括 CPU 使用率、CPU 负载、内存使用率、磁盘空间使用率、磁盘 I/O、网络流量和系统特定进程等；同时支持用户级别的监测内容定制，如服务器特定运行信息参数设定，周期性获取服务器状态以及动态调整个服务器监测状态信息。项目的意义在于构建了一种适合于分布式网络环境下数据传输的模型，着重解决分布式服务器状态管理系统中配置的下发策略，数据一致性的校验与维护，全双工通信网络组建，业务子系统间高效信息交换等问题。为当前分布式环境下服务器监测领域提供了一个范例。
……..
第2章 系统需求分析
2.1 功能性需求
本项目来构建了一个面向分布式网络的服务器监测系统。通过使用该系统，系统管理员能够实时掌控系统所在分布式网络环境下所有被监测服务器的信息，并且能够根据服务器信息对突发情况做出及时的应对处理。系统的用户主要包含三类：配置生成人、配置审核人、系统管理员，根据上述不同的用户可以进行系统用例设计，系统具体的用例图如图 2-1 所示。配置审核人可以对所有等待审核的下发配置指令进行审核，决定是否放行。（3）系统管理员 系统管理员可以进行用户管理和系统管理两方面的工作。用户管理包括对配置生成人和配置审核人信息进行管理的功能，系统管理包括系统监测、系统参数配置、查看日志和历史信息查询等功能。为了实现上述不同系统角色所对应的系统功能，将系统划分为七个模块和一个前台系统。其中，七个模块分别是通信模块、解析模块、数据镜像/加载模块、可靠性保证模块、日志模块、数据库操作封装模块、服务器状态获取模块。每个功能模块的具体功能需求概述如下：通信模块功能需求:服务器在运行过程中，无论是人工操作还是系统自动发送消息，都能实现相邻节点间的数据发送、接收等操作。解析模块功能需求服务器基于网络接收数据时，会收到上一个节点的服务器发过来的封装成固定格式的消息，需要根据消息类型按照对应的方式解析数据包并获取消息内容。数据镜像/加载模块功能需求当服务器数据管理系统发送故障时，可以通过数据镜像/加载模块对最新的服务器数据镜像文件进行恢复。可靠性保障模块功能需求在设备故障或重启等情况导致静态表或动态表丢失的情况下，可以从上游节点或同级节点获取最新备份。并且在设备故障或重启后，需要定时保活机制和重传机制保证数据的正确传输。被监测的服务器可以通过执行下发的配置指令进行服务器状态的获取以及用户级别的服务器监测内容的定制。前台系统的需求是实现用户管理模块、配置生成模块、配置审核模块和系统管理模块。其中，用户管理模块实现对用户信息管理的功能，配置生成模块实现人工生成配置的功能，配置审核模块实现对下发配置先机器审核后人工的审核的功能，系统管理模块实现将服务器信息进行图表等方式展示的功能。
…….
2.2 非功能性需求
本条将由性能需求和运维和稳定性需求两个方面的需求来阐述非功能性需求。
（1）性能需求 性能需求应包含如下几个需求：服务器信息获取的时间误差小于 2s。程序内存使用率不差过 50%，保证程序的正常运行。
（2）运维和稳定性需求 运维和稳定性需求应包含如下几个需求：配置策略下发的总成功率达到 90%。策略有效下发的总成功率= 成功服务器数/目标服务器数*100%，只有高成功率才能保证系统运行的稳定性。数据库入库成功率大于 90%。本系统关键程序重启次数不超过 3 次/周。
……..
2.3 本章小结
章对面向分布式网络环境的服务器监测系统进行需求分析。在需求分析方面，将整个系统进行功能性和非功能性分析。在功能性分析方面，将系统分为多个模块和一个前台系统，并分别进行需求分析，使工作的模块性更鲜明，减少系统的耦合度，为系统后续的更新等工作提供了更大的便利。在非功能性分析方面，提出了性能需求和运维和稳定性需求，要求系统具有更好的性能。按照功能进行需求的划分，为后续开发研究工作奠定了基础。
……..
第 3 章 系统总体设计 ..... 7
3.1 系统总体设计 .... 7
3.2 系统开发环境和工具 ........ 12
3.2.1 开发语言 ........ 12
3.2.2 开发工具 ........ 12
3.2.3 开发环境 ........ 12
3.3 本章小结 .......... 12
第 4 章 系统详细设计与实现 ......... 13
4.1 系统详细设计 ........... 13
4.1.1 数据库详细设计 ..... 13
4.1.2 模块功能详细设计 .......... 15
4.1.3 关键流程设计 ......... 23
4.2 系统实现 .......... 29
4.3 本章小结 .......... 40
第 5 章 系统测试与性能分析 ......... 42
5.1 后台模块测试 ........... 42
5.2 前台系统测试 ........... 48
5.3 系统性能分析 ........... 50
5.4 本章小结 .......... 52
第5章 系统测试与性能分析
5.1 后台模块测试
系统后台部分由通信模块、解析模块、数据镜像/加载模块、可靠性保证模块、日志模块、数据库操作封装模块、服务器状态获取模块等七大模块组成。不同模块之间相互独立同时又具有一定联系，对不同模块可以进行独立的测试。表 5-1 是通信模块测试用例表。其中，测试项包括了中心节点与二级节点通信，二级节点与三级节点通信，三级节点与二级节点通信以及二级节点与一级节点通信。经过测试后，实际结果与预期结果一致，说明了后台运行的通信模块能够正常运行。在测试这部分模块代码时，通过对 h 码表进行处理来测试，其中，h 码表中的数据量为 258113。图 5-1 是未处理的 h 码表，图 5-2 是处理后的 h 码表。write.txt 中格式是“号码段+归属地+运营商+区号+身份证”，经过 h 码表重新整理后输出的结果是“号码段+归属地+运营商+区号”，并且，相邻两个字段之间的距离也重新处理为定长。经过测试，hashtable 构造的 insert（）等函数功能正常，即数据镜像/加载模块功能正常。
………
结 论
本文针对分布式网络环境下的服务器监测问题，基于需求分析、总体设计、详细设计、系统实现、系统测试等一系列软件工程方法，设计并完成了面向分布式网络环境的服务器监测系统。本文取得的成果如下：
（1）支持分布式网络环境下的服务器监测的功能。直接通过操作中心节点服务器上的服务器监测系统，在网络通信正常的情况下，可以获取当前分布式网络环境下所有其他服务器的信息。
（2）实现了服务器监测的高效运转。分布式网络可以将负载由单个节点转移到多个，从而提高效率。
（3）代码模块之间的耦合度小，代码具有很强的复用性。其中部分模块代码如日志模块，数据库操作封装模块等可以被其他系统开发使用。当需要作出功能改动时，可以比较方便的进行修改。
（4）系统使用长链路保活技术保障系统的长期，高效运行。同时也能降低因为通信中断而造成的网络丢包率。
（5）在数据镜像/加载模块使用 hashtable 保障程序快速高效运行。
（6）程序中加入了大量的日志信息跟踪程序的运行，可以及时，准确的跟踪程序运行路径。
遗憾的是系统前台做的比较简陋，由于开发环境的限制，不能开发真实分布式网络环境下的面向大规模分布式网络环境的服务器监测系统。而且系统不是工作项目，由我个人完成，项目中难免有部分隐藏 bug 存在。
............
参考文献(略)
专业工程硕士毕业论文范文精选篇三
第一章绪论
1.1研究背景与意义
为指导银行的企业信息化建设方向和具体实施，推动银行业务良性、快速发展，支撑企业发展与战略目标的实现，2009年制定了中国邮政金融IT总体规划。IT规划根据邮政金融业务的信息化战略，提出了适合邮政金融业务未来发展的IT建设重点和建设原则，设计了邮政金融信息系统应用架构、数据架构、基础设施架构、信息安全架构、IT治理与运维模式等，确定了总体实施演进策略与步骤、目标系统实施方案及系统改造整合方案。
………..
1.2渠道管理平台的研究进展
在渠道管理上，国外银行越来越重视网点与其他业务渠道之间的信息共享、服务对接和统一管理。一方面突出网点在增进与客户互动交流方面的独特优势，另一方面充分利用其他服务渠道拓展网点的服务半径，寻求更多业务楊会⑴。国内银行业受科技条件和经营理念的限制，不同业务渠道间的衔接性往往不够理想，银行网点与其他业务渠道之间相互割裂，各自为战的问题仍十分普遍，严重制约了银行的整体客户服务能力和对业务机会的挖掘能力[2]。一些银行在解答客户业务咨询时，网点与电话银行的答复不一致的情况也时有发生，不利于向客户树立专业化的品牌形象[3]。按照中国邮政金融IT总体规划，渠道管理平台为各渠道建立统一的数据标准和服务规范，实现流程和信息整合，降低各渠道整体的维护和开发成本为目标，将人工渠道、自助渠道以及外部渠道纳入其中，作为各类渠道的后台接入系统，实现渠道交易信息的统一传递和交易数据的统一分发，以及统一的安全认证和授权、统一的系统接入、统一的信息模型及转换、统一的流程管理、便捷的监控管理等，以满足新业务的快速部署、产品一次开发多渠道发布、产品主动营销、向客户提供一致的信息、为客户提供多渠道个性化服务等市场需求，实现所有渠道统一接入，屏蔽各渠道与各系统之间通讯方式、报文格式等接口的差异，实现各渠道应用业务逻辑的整合、机构人员的统一认证管理和安全管理，在各个不同的服务渠道上提供统一客户体验，实现渠道服务标准化管理功能。
………..
1.3本文主要研究内容
系统上线初期，柜员信息管理系统建立渠道管理平台系统所需后台人员(柜员)信息，渠道管理平台系统向柜员信息管理系统提供后台人员所需角色的标准数据，由柜员信息管理系统进行初始数据导入，并将人员信息(含对应角色信息）提供给渠道管理平台系统，渠道管理平台系统进行初始数据导入。实现人员登录，进行相关参数维护，可以对柜面、柜员以及自助渠道进行异常监控预警。本文一共分为七章，其结构安排如下。第一章绪论。本章简要介绍本论文的背景与意义、渠道管理平台的研究进展和本文的主要研究内容。第二章对后台管理子系统实现所用到的关键技术进行总体描述，介绍了系统实现所用到的工作流引擎、通讯引擎、交易引擎以及SocketServer観讯配置。第三章主要描述后台管理子系统的需求分析，包括系统的总体架构、整体功能模块划分、具体模块的功能需求分析、系统建设原则以及与其他系统关系。第四章主要描述后台管理子系统的概要设计和数据库设计，总体描述系统的应用分层结构和总体交易流程，针对每个不同的模块划分设计表结构。第五章主要描述后台管理子系统的详细设计与实现，对各个具_功能进行详细功能设计、类设计和业务流程设计。第六章主要描述后台管理子系统的实现与异常处理，详细展现各个子模块的表现形式，对于运行过程的异常处理流程进行了描述。第七章对本文的工作进行总结，并对项目的未来进行展望。
………
第二章后台瞀理子系统的关键技术
2.1工作流引擎
传统的工作流引擎在处理任务的时候都是采用编码的方式，通过在流程运行时调用预先实现的代码单元来实现具体的文件操作、数据库操作等框架在工作流逻辑处理方面充分结合了交易引擎，使用交易引擎来完成每一个流程动作的处理逻辑。这样充分利用了交易引擎在交易处理过程中的灵活性、可配置性在这种模式下，工作流的定义更加专注于业务流程本身，而将具体的每个步骤的动作处理交由交易逻辑来完成[7]。如果说，交易逻辑是通过对资源（数据库、文件等）的调度来满足用户的一次请求，那么工作流逻辑则是通过对交易逻辑的调度来完成多人协作模式下的事务请求。流程步骤、流程分支、流程合并提供了描述不同业务流程的基础元素，通过他们的组合来描述复杂的业务流程。流程动作包含于某一流程步骤中，一个流程步骤可以包含若干流程动作流程动作由执行该动作的条件、动作执行代码以及动作导向的下一步骤的路由组成。流程状态描述了某一时刻流程所处的状态，他是该时刻流程所有步骤的状态的集合。框架釆用面向对象建模的方式，将上述的定义建模成一组对象，其中流程模板对象描述了流程逻辑。在此基础上，提供了基于XML文件和数据库表来生成流程模板对象的组件这样，我们可以根据实际应用的需要来灵活的选择流程定义的方式。对于XML方式的流程模板定义，框架提供对应的XML Schema文档来约束流程定义文档的规范性和合法性，同时也可对相应的XML编辑器提供友好的XML编辑提示支持['2]。对于数据库方式的流程模板定义，目前，框架完成了底层的工作流引擎的核心功能;框架尚未提供可视化的编辑方式界面，这将在后期的开发中根据具体的业务要求实现。
……..
2. 2 通讯引擎
通讯引擎的支撑主要是三层：通讯接口层，组包解包层，业务逻辑层，下而就通讯引擎的系统结构，以及目前的通讯引擎的实现情况作简单的介绍，如图2-1所示：实现了 FixFormat、变长分割符、RA的LV格式、XML四种格式的报文的组包解包，以及各种形式的相互组合的报文组包和解包“9]。在组包解包层完成了 String，Date, Decimal, int, Long等多种基本数据类型的标签实现_，并且通过标签的扩展属性来确定具体的组包解包特性，来满足现有的渠道平台的通讯的需求。组包解包层和通讯接口层可以灵活组合搭配使用；此外组包解包层自身也可以组合使用，通过灵活的组合搭配可以适应各种通讯情况[21]。为了更好的解决交易的实现，在通讯的组包解包层之外加入的业务逻辑处理层，在业务逻辑层实现业务逻辑和再次主机通讯，来完成交易组合，并且交易引擎通过各种交易组件来完成各种业务需求比如数据库操作，通讯，加密，FTP，Mail等，关于业务逻辑层的功能，将在交易引擎部分做具体的描述。
………
第三章后台管理子系统需求分析........... 11
3. 1系统总体架构.......... 11
3.2功能性需求.......... 13
3.3系统性能需求.......... 18
3. 3.1系统建设原则.......... 18
3. 3. 2系统性能需求.......... 19
3.4与其他系统关系.......... 19
3.5小结 .......... 21
第四章后台管理子系统概要设计与数据库设计.......... 23
4.1应用分层结构 ..........23
4. 2总体交易流程.......... 24
4. 3数据表设计.......... 24
第五章后台管理子系统详细设计.......... 29
5. 1公共管理.......... 29
5. 2后台人员管理.......... 34
5. 3参数管理.......... 45
5. 4监控预警.......... 50
第六章后台管理子系统的实现与异常处理
6. 1公共管理
主管登录渠道管理平台系统后，在待审核交易列表中选择相应的交易进行审核处理。审核同意后，进行参数维护，提示交易成功，结果返回交易经办人员；审核拒绝后，提示交易结束，结果、意见返回交易经办人员。后台管理处理子系统为B/S架构的OLTP (On-Line Transaction Processing)系统，在出现异常时应该能实时将异常信息反馈给客户操作页面，并对异常信息进行记录。按照是否需要和外部系统交互区分，本子系统的异常处理分为两类：该类异常指不需要调用外部系统通讯接口的交易异常。常见异常包括数据库连接失败、数据校验错误、数据存储空间不够等。对于此类型异常，系统提供统一的出错页面，提示用户重新进行操作，对用户已操作的数据进行回滚，同时记录系统错误日志。通讯交易异常：该类异常指调用外部系统提供的通讯接口进行交易过程中产生的异常。主要包括通讯返回超时，通讯连接失败等。对于通讯连接失败异常，系统中断当前操作并提供统一出错页面，将已操作的数据进行回滚，同时记录错误日志。对于通讯超时异常，系统提示用户进行查询操作，并提供查询交易确认数据是否操作成功。
……..
总结
本论文完成了渠道管理平台后台管理子系统的设计与开发工作，总结如下：首先，本文对渠道管理平台的背景及现状进行了分析，然后对整个系统的组成和架构进行了介绍，分析渠道管理平台系统后台管理子系统的关键技术，为后台管理子系统的设计与实现奠定基础。其次，本文从系统关键技术、系统结构、需求分析、概要设计、数据库设计、详细设计几方面对后台管理子系统的实现过程进行了描述。其中，在需求分析中，根据该子系统的业务需求，具体分为公共管理、人员管理、参数管理和监控预警四个子模块，然后根据不同的子模块设计数据表结构，详细设计时，对具体的子模块进行功能设计、流程设计和类设计，并将具体子模块的实现进行展示。最后，管理终端使用WEB浏览器的方式呈现，后台管理处理子系统为B/S架构的OLTP系统，在出现异常时应该能实时将异常信息反馈给客户操作页面，并对异常信息进行记录。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇四
第一章绪论
1.1选题背景及意义
网络应用近些年全球范围的持续增长。这些应用从各个方面影响着人们的日常生活，工作以及社交活动。技术在变革，全球互联网用户的需求和期望也在变化。在这些变化的驱动下，网络资源合理分配并且及时应对网络变化进行资源调整变得日益重要。随着Internet的不断扩大，网络结构趋于复杂，链路负载随着网络应用的增多而增加，网络管理及资源调度的难度也相应加大。己有的云监测系统主要用来’测量局域网节点之间的链路，并且每个节点都必须事先部署好测量程序。在部署好的广域网中的节点上部署测量程序后同样可以测量真实环境下的链路性能。但是由于探针数量及分配给系统的广域网IP有限，同时受地域及其他资源的限制，.无法同时进行多个城市甚至多个国家的网络性能监测。利用局域网或小范围广域网收集到的网络测量结果不足以进行数据分析统计，无法为网络管理者提供决策依据。大规模测量是’指在真实的网络环境下，对多地区的多条链路进行长时及短时的测量，以收集有权威性、代表性、能反映真实情况的结果数据进行分析处理。大规模测量需要测量系统有较高的安全性和稳定性，并且可以支持同时部署多个节点、下发多个任务以提高系统的使用效率。PlanetLab是一个可共享的、大规模的、开放的、针对下一代互联网的测试平台，属于“覆盖网络”[1]。它帮助开发人员能够分布式的在现实的网络环境下部署和开发应用程序。PlanetLab节点分布在全球25个国家，大多数节点由研究机构负责，部分位于同一局域网或属于同一个中心路由。这些节点与全球Internet主要地区的网络均有连接，因此基于这些节点的网络测量可以真实的反应不同地区的网络性能以及地区间的链路状况。
………
1.2国内外研究现状
局域网的测量数据目前已经无法帮助研究人员对现实网络资源进行评估和合理分配。因此，需要使用测量系统来测量真实网络环境下的不同时间、不同地区的网络，用获取到的结果帮助研究人员更好的了解网络状况，进而为未来的资源分配、决策制定提供重要的显示依据。Internet技术和Web服务的不断发展促进了用户需求的不断变化，相关研究和技术也在不断革新，Web服务的数据量与日俱增。为了能够更好的满足用户需求，跟上科技进步的脚步，真实网络环境下的大规模测量变得越来越有意义。PlanetLab作为一个大规模分布式的实验开发环境，被广泛的应用于海量存储、云计算等方面。近些年出现了较多的基于:PlanetLab的网络测量、监控系统。可以利用PlanetLab开发分布式系统用于测量端到端的网络性能并依据测量数据进行故障诊断。目前的测量系统多为通过主动测量、下发测量任务得到网络性能参数（包括时延、丢包及抖动）的测量结果。故障诊断平台大多基于测量结果提出新的网络性能和故障分析的体系结构，为未来的故障诊断以及网络架构的重构奠定基础。测量系统也可以利用CERNET2和PlanetLab的节点建立大规模路由的试验平台，此系统不仅提供多种监控功能，也支持使用者对网络性能、用户信息以及节点资源进行监控，并查看立式测量数据。这些测量系统的目的和实现大规模测量的方式都基本相同。同样，大规模测量也适用于移动网络及WiFi的测量研究[2]。
……….
第二章相关技术背景介绍
2.1面向大规模测量的云监测系统相关技术
随着互联网的发展，理解网络的性能及行为对于网络资源的管理和下一代网络的构建都有重要意义。本课题依托于云监测系统TANC进行大规模测量，旨在在真实网络环境下，通过大规模测量对真实网络进行评估，为研究网络行为提供测量结果依据。为了实现大规模测量，需要依托于TANC系统，使用PlanetLab测试床环境，并使用自动生成的拓扑图以及Google Maps API帮助大规模测量计划的制定。TANC为云监系统，可以测量网络性能，主要由测量探针和集中管理平台组成。测量探针为部署好测量程序的独立的主机或机器，支持不同类型的测量任务下发和执行。任务下发主要参数为任务类型、节点任务时长等，且节点为网络中任意一个已经部署好的探针。集中管理平台由数据分析器、负载均衡器和集中管理平台三个部分组成。通过Hadoop集群上的云监测平台可以管理分布在网络上的测量探针，可以向一个或一组测量探针下发测量任务。云监测很重要的功能是接收到测量探针获取到测量结果并保存到HBase中。集中管理平台处理测量结果之后，通过TANC的Web页面呈现给用户。此Web系统作为监测系统与用户直接交互的部分，不仅是用户下发、管理任务的方式，同时也提供了测量结果数据查看的接口，将底层的测量程序及测量结果处理程序与用户接口隔离开来。是普通用户使用测量程序进行网络性能监控的唯一途径。
…
2.2 Web系统安全性问题
早期的Web系统没有使用规范性的框架，开发技术并不成熟。大部分Web系统都会面临着SQL注入、跨站脚本攻击、通过源代码篡改表单等问题。近些年开发人员都会使用一些稳定的、公认的开发框架，对系统结构、代码分层做出相应的调整，己经可以解决并应对一些常规的Web攻击。但是不同的应用系统会有各自不同的安全性需求，这就需要开发人员深入理解、研究整个系统，并选取重点的需求对系统进行安全性优化，提高系统的稳定性。注入的攻击方式的根本原因是后台的运行程序与用户输入的信息没有彻底解耦或进行分离，使得攻击者能够把输入的指令传输给后台程序，并且后台程序任务此信息为用户输入信息而运行了对应的程序。这样攻击者就可以根据自己的攻击目标构建指令传入后台程序。结构化查询语言（Structured Query Language，SQL)是用于数据库的标准查询、编程语言，多用于关系型数据库的增刪改查等功能。开发人员可以在不了解数据库存放方式以及数据结构的情况下，使用SQL语句操作数据对象。并且SQL语句提供了较多的关键词，并且可以进行逻辑嵌套，具有很强的灵活性。基本操作的语句易于学习，逻辑清晰。当开发人员要实现较为复杂的功能时SQL语句,中的字段会较多，需要使用字符串来存储这些语句，而且只有当开发人员有数据库管理员权限的时候才可以与数据库建立连接。因此，这就给攻击者利用这些语句攻击数据库的机会，例如在字符串中添加能够对数据库信息造成破坏的语句，甚至破坏整个数据库。这种攻击方式就叫做SQL注入。
……..
第三章面向大规模测量的界面呈现的设计与实现.......... 15
3.1 PlanetLab节点地理信息呈现的设计与实现.......... 15
3.2 PlanetLab节点拓扑信息呈现的设计与实现.......... 21
3.3使用PlanetLab节点测量的界面功能的设计与实现 ..........25
3.4本章小结.......... 36
第四章密码及用户权限控制的研究与实现.......... 37
4.1 Web安全概述.......... 37
4.2TANC安全性介绍.......... 38
4.3 RSA加密明文密码 .......... 40
4.4用户权限管理.......... 42
4.5本章小结.......... 45
第五章用户体验优化的研究与实现 ..........46
5.1用户体验优化概述.......... 46
5.2浏览器兼容性的优化.......... 46
5.3数据呈现的优化.......... 49
5.4本章小结.......... 52
第六章集成测试与结果分析针
6.1运行环境
为了顺利进行大规模测量，本课题将系统集中管理平台移植到真实网络环境下，并对slice中的PlanetLab节点进行了自动部署。通过自动部署既能为大规模测量奠定基础，同时也可以对扩展的功能进行测试。并在测试用户体验、系统安全性等模块的同时，使用PlanetLab节点进行了大规模的测量任务下发，对测量结果同样进行了解析。基于这些大规模测量收集得到的数据，利用MatLab及数学方法的解析，得到了全网范围内的链路性能的时间、空间上的结论。图6-1中绿色的节点为国内部署好的可进行大规模测量的PlanetLab节点。测试内容及方案主要是以功能测试的角度对本课题对TANC系统进行优化涉及到的功能及模块进行测试。从系统优化的角度出发将测试内容分为大规模测量的测试、系统安全性的测试以及用户体验的测试。由于大规模测量相关的测试较多，本章只选取使用次数较多的manetLab节点和较为重要的几组数据列举出来，下发的任务类型以时延丢包为主。
…………
总结
面向大规模测量的云监测系统TANC的性能优化研究与实现课题重要研究了如何使用云监测和PlanetLab节点进行大规模测量，使系统能够部署在地理分布的现实网络环境中。并对系统性能，包括安全性、.用户体验等方面进行优化。本文首先从大规模测量的现实需求出发，从PlanetLab节点呈现、拓扑图的生成以及与任务下发相关的功能进行功能扩展，帮助用户使用TANC系统进行大规模测量。同时从系统安全和用户体验方面对系统性能进行了整体的优化。这些设计与实现不仅从功能上使TANC系统能够将测量节点部署在大规模的分布式网络环境上进行大规模测量，还有效的对系统性能进行了优化，完善了用户体验，增强了系统安全性。对通过大规模测量数据进行进一步的研究与实验奠定了良好的基础。经过这段期间的研究与开发实现，TANC系统己经在大规模测量功能上（节点地理位置呈现、拓扑图自动生成、单节点多节点的自动部署以及任务卞发)，系统的安全性（RSA加密认证、用户权限管理)，以及系统的用户友好性（页面样式的统一、提高浏览器兼容性以及结果呈现页面响应速度）等多个方面都有了稜明显的改进和优化。目前TANC系统能够使用户高效的进行节点部署及大规模测量的任务下发。同时系统页面能够较好的兼容各类浏览器，页面响应速度明显提高，系统用户体验良好。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇五
第一章绪论
1.1研究背景与意义
近年来，随着我国住房公积金事业的发展，住房公积金已成为我国居民住房体系的一种保障。作为我国居民的一种重要民生保障手段，当前其正处于重要的转型阶段，设备电子化、系统网络化已成为大势所趋。伴随着国内住房公积金覆盖面的不断扩大，各地住房公积金在缴存单位数量、缴存职工人数方面都大幅增加，传统柜台业务模式在效率、便利性、安全性等方面均存在很大的局限性，越来越不能适应当今业务发展的需要。从商业银行发展商看，如今网上银行替代了 63%的柜台业务⑴，业务电子化信息化已成为必然趋势。为了方便缴存单位、缴存职工的业务办理，住房公积金行业正在经历着电子化、信息化的办公模式转变升级，本文致力于住房公积金行业的统一认证系统的设计和开发，是住房公积金业务信息化升级的不可或缺的重要组成部分。随着住房公积金业务的信息化服务的全面普及，越来越多的子系统被开发出来，但由于各种客观条件和历史因素，这些系统开发时期和应用的技术各不相同，且每个系统都有各自独立的身份验证机制，这既造成了开发上的重复性，同时在实际应用中，也使得用户必须要花费大量的时间来输入验证信息，影响了工作效率。而且，当系统中的身份验证信息发生了修改时，必须要对各个系统的身份验证模块分别进行人工调整，这不仅严重增加了系统维护和升级的负担，而且也容易出错，所以研究住房公积金系统的统一认证解决方案具有很强的现实意义。为了使本文设计的住房公积金统一认证系统具有现实的实用性和技术上的领先性，本文借鉴了商业银行电子认证系统的发展模式，和当今较为领先的安全认证技术，并综合了住房公积金各业务模块的业务需求，设计并实现了应用灵活、安全性高的住房公积金行业统一认证系统。
………
1.2课题研究现状
本课题主要涉及住房公积金电子业务幵展过程中的安全认证领域，本章节主要针对客户安全认证技术的研究现状进行阐述和分析。现如今，还有不少住房公积金行业内部信息系统或互联网系统依然在使用用户名/密码的认证方式，系统中的个人用户信息存在较大的安全风险，解决上述问题，就需要建设完善的身份认证系统。在国外，微软的Passport已经对外提供多年的认证服务，它其实是一种Web Service认证服务，其核心的验证服务器及用户个人信息存储服务器由微软一手把控，是一种集中统筹式的身份认证服务系统。与之相对应的是自由联盟(Liberty Alliance)网络身份验证规范，由IBM、HP、Intel、Oracle等众多公司和机构组成。旨在创建一个统一的、能联合各个系统、具有幵放性的身份认证解决方案。自由联盟身份验证规范采用联合身份管理认证机制，即身份认证提供者不是唯一存在，可以相互独立，这样有效避免了认证系统单点故障导致的全系统瘫痪的局面。自由联盟核心为SAML，英文全称是Security Assertion Markup Language,即安全断言标记语言。它是一个XML框架，也就是一组协议和规范，它定义了身份提供者和服务提供者，并在两者构成了不同的安全域。目前已经有商业和开源的SAML实现可供选择，如BEA Web Logic Server 9.0, Open SAML, Shibboleth等。此外，近年来OAuth协议发展势头迅猛，得到了广泛应用。OAuth协议是一个关于授权（authorization)的开放网络标准，目前的版本是2.0版。国内的很多机构和系统正在或已经进行了统一身份认证的改造，如互联网、电力、银行、高校等信息化比较先近的企业。在住房公积金行业，各地的信息系统建设时期不同，信息化水平各异，对统一身份认证需求的急迫性也就不同。一般来说，对于渠道系统建设较多的住房公积金管理中心，存在着提供身份认证安全性、整合多渠道身份认证的诉求。
……….
第二章理论基础及相关技术研究
2.1信息安全的基本概念
信息系统安全指网络与信息系统正常运行，防止网络与信息系统中的信息丢失、泄露以及未授权访问、修改或者删除。其核心一般从以下五个方面定义[11]:保密性(Confidentiality):保密性是指信息不向非授权用户透露，信息不被非法使用。完整性(Integrity)：完整性是指信息没有经过许可的情况下不能进行改变的特性，即信息在传输或存储过程中不被修改、破坏，并且有能力判别数据是否已被修改。可用性(Availability)：可用性是指允许信息被已授权实体访问及使用的特性，并且在使用过程中而不受外界因素影响。可控性(Controllability)：可控性是指在一定的授权范围内，能自主的控制信息的流向及信息的行为方式。不可否认性(Non-repudiation)：不可否认性是指信息发出者要对自己发出的信息负责，不能否认自己曾收到的信息数据，也不能抵赖自己曾发出的信息数据。
………
2. 2密码学理论
前面论述了信息安全的基本概念，下面从密码学概念、对称加密算法、非对称加密算法、数字签名几个方面介绍密码学的基本知识。密码学作为是信息安全领域的理论基础，其理论基础来源于数学理论——数论。密码学包括两个分支：编码学和破译学[12]。编码学主要研究对信息进行加密，使得在传递过程中保护信息不被窃取、解读和利用的方法；破译学则主要研究如何对加密的信息进行分析、破译。当前，由于计算机及互联网技术的飞速发展，各个行业基于互联网的应用不断增多，密码加密及解密技术更成为了保障信息的保密性、完整性、不可抵赖性的有效手段，其已经成为保护个人、国家信息安全的一道有效屏障。世界上各个国家都投入了很大的精力，研究加密和解密技术。密码加密的基本思路是对明文信息以一定的方式、一定的逻辑进行变换。一个密码系统需要完成如下工作：信息发送者对需要进行加密的信息（明文）进行加密变换，得到的密文看起来是与明文毫不相关的信息表示；如果信息接收者为合法用户则获得了加密的信息（密文）后，他可以通过事先和信息发送者约定的密销，从密文的信息中解密得到原有的明文信息（解密变换），而如果信息接收者为不合法的用户，获得了加密信息（密文）后，试图从密文中分析得到原有的明文信息，是不可能的或代价过于巨大（NP难度问题）。一般情况下，密钥系统采用的基本工作方式为密钥体制，其中密钥加解密算法、密朗是保密的关键。按照密匙加解密算法的特点，可分为：对称加密算法和非对称加密算法。
……….
第三章住房公积金统一认证系统需求分析.......... 15
3.1统一认证系统的需求分析.......... 15
3.2统一认证系统的方案设计.......... 18
3.2.1 设计原则.......... 18
3.2.2系统总体设计.......... 18
3.2.3部署环境设计.......... 20
3.3 小结.......... 21
第四章统一认证平台的详细设计与实现.......... 23
4.1 UKEY认证模块详细设计与实现.......... 23
4.2个人客户统一认证详细设计与实现.......... 24
4.3小结.......... 27
第五章系统的测试与分析.......... 29
5.1系统运行环境.......... 29
5.2系统功能测试.......... 33
5.3系统性能测试与分析.......... 35
5.4小结.......... 36
第五章系统的测试与分析
5. 1系统运行环境
统一认证系统在生产环境中运行，各个渠道系统调用统一认证系统发布在ESB上的服务完成用户身份认证流程；个人客户认证信息修改，通过各渠道系统调用统一认证系统服务完成；单位客户认证信息修改，需到第三方认证机构或合作银行完成。系统测试环境如图5-1所示，软硬件环境配置表见表5-1，软件应用配置表见表5-2。本节将详细介绍统一认证系统运行情况，主要包括各渠道系统（个人査询网站、APP、呼叫中心IVR、单位网上缴存），住房公积金统一认证服务（个人客户认证子系统、单位客户UKEY认证子系统）和监控告警子系统等的运行情况。通过使用单位系统建设的实践证明，住房公积金客户统一认证系统采用SOA架构，与各渠道系统实现接口对接，达到了一个渠道注册、多个渠道使用，具有良好的综合效益；性能上达到了设计要求。
………
结论
论文中主要完成了以下几个方面的工作：
一、首先介绍了研究住房公积金行业统一认证系统的背景与意义，接着详细阐述了国内外安全认证应用研究现状以及网络安全数据传输研究现状，并且根据某住房公积金中心的实际情况，选择安全认证及网络安全传输的方案，最后对论文的主要研究内容做了 一个整体的概述。
二、第二章主要介绍住房公积金行业安全认证设计得相关技术，包括：信息安全的基本概念、密码学理论知识、身份认证相关技术、并重点介绍了基于UKEY数字证书认证技术旳两种实现方式(基于冲击-响应的双因子认证方式和基于数字证书的认证方式)，以及SOAP协议标准技术规范、SSL相关技术，这些内容为后续章节阐述面向住房公积金的统一认证系统设计与实现的细节做好铺垫。
三、以某省市住房公积金中心统一认证系统建设的实际为例，介绍面向住房公积金的统一认证系统业务需求，包括：统一认证系统单位客户第三方认证需求分析，统一认证系统单位客户合作银行认证需求分析，以及统一认证系统个人客户认证需求分析。同时也阐述了统一认证系统的方案设计，包括：系统设计原则、系统总体设计、部署环境设计。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇六
1绪论
1.1背景及意义
物联网是继互联网后又一次新的信息技术革命，互联网改变了人与人之间信息的交流和共享，而物联网是互联网的触角的进一步的延伸到人们现实生活中的各种物品上，物联网要实现人与物，物与物之间的连接互通。物联网包括传统的互联网还有传感器组成的传感网（Sensor Networks) 通过传感器来与物品进行信息沟通，然后运用互联网的强大的存储能力，运算能力，共享能力来将获得的信息进行处理，连接互通，使物与物之间，物与人之间可以方便快捷的交流互通，协同工作，为人们的生活带来前所未有的便利。工信部部长在2015年的两会上表示，在未来的20年间，中国工业互联网发展至少可以带来3万亿美元左右的GDP增量，而工业互联网的核心就是物联网。全球专业的咨询公司埃森哲发布的《携手产业物联网，实现共赢发展》报告中说，通过物联网使机器设备智能的连接到一起，从而为企业带来新的数字化服务，开创新的商业模式，预计到2030年可以为全球贡献新产值14.2万亿美元。物联网主要的应用领域包括智能家居，智能物流，生产环境监测，智能农业，军事设施建设等多个领域。物联网通过依靠强大的传感器层将触角伸到传统生活工作场景的各个领域。在智能家居方面，利用物联网对家庭环境进行安全监视，同时也可利用周界防入侵传感器网系统来对重点区域进行安全监视小米公司通过智能手机加智能路由为智能家居的核心，将电视机，电脑和空调等设备连接起来，通过互联网进行远程智能控制。海尔公司发布的海尔空调盒子同样也是把家居常用电器连接到互联网，为了增加用户的操作便利性，海尔公司发布出平台，希望搭建一个开放的生态环境，让各个公司的智能设备可以方便的接入，包括智能电视，落地灯，无线灯泡，电动窗帘，无线插座等可以用统一的平台进行控制，国际电信联盟曾经这样形容智能家居：当主人上班时忘记带了某些东西，手提包会主动提醒主人；当下班回到家之前给浴紅发条信息，浴紅会自动放好水并且把水调节到合适的温度智能物流领域，物联网技术更是深深地改变了这个领域。从商品库存管理，出库管理，运输管理都有物联网的影子。
……….
1.2研究现状
从物联网开始普及以来,对物联网中应用最广泛的传感器层技术的RFID技术的应用研究一直是热点。其中主要是研究电子标签的标准和识读器的管理。国际标准化组织早在1995年就提出了 ISO/IEC的RFID标准，定义了应用程序和读写器的交互接口,规范了标签中数据编码、压缩、转换等处理流程。这个标准包括四部分：RFID标签标准、RFID识读器读取RFID标签的标准，系统的测试标准和RFID识读器到应用程序之间的通信标准。EPCgoba是由UCC和EAN共同组建的RFID标准研究机构，该机构推出了 EPCglobal标准⑴]。EPCglobal标准尽量与ISO兼容，同时特别关注供应链的各个环节中的物品的相关信息的统计。和EPCglobal标准相似日本提出了 UID标准。UID主要专注于得到和分析信息，分析的形式采用扁平式的分析方式，特别关注RFID识读器和RFID标签的集成的小型化。我国虽然在制定RFID标准的过程中落后，但是也在大力的发展物联网行业，并取得了大幅度的进步。在2012年全国的智慧城市建设数量为320个，总共投入资金3000亿元。到现在为止已落实智慧城市建设的城市共有193个，遍布全国各地，包括国家发展和改革委员会等的8个国家部委明确提出到2020年我国要建设出多个具有特色鲜明的智慧城市。
………
2相关理论和技术介绍
2.1射频识别技术
RFID (radio frequency identification)技术简称射频识别技术，它是利用物体反射的电磁信号来对物体进行识别的技术，RFID识别系统具有读写速度快、存储容量大、识别距离远和可以同时读写多个电子标签等特点。1999年麻省理工学院的Kevin Ashton教授提出了把RFID技术应用于日常物品中形成一个物联网[18]。物联网中利用该技术制造出RFID识读器和EPC(electronic product code)标签，它们之间利用射频方式进行非接触双向通信来对物体进行唯一性识别EPC标签同条形码相比,EPC标签具有应用更灵活、信息容量更大、抗环境污染和抗干扰等优点，EPC标签读取和修改方便，时间短，并且RFID识读器对EPC标签的读写是不用光学接触的，也就是说粘贴了 EPC标签的物品即使被存放在纸箱里或者货架上，管理人员在附近就可以对其进行批量的读取和修改，这比对传统的二维码标签读取需要光学接触而言方便了许多[21]。虽然EPC标签比二维码标签的读取和修改都要方便，但是EPC标签的造价比二维码标签要高。尤其是在EPC标签的应用初期RFID标签的平均成本为几元钱，要比几分钱的二维码标签成本高很多。但随着EPC标签的批量生产及技术进步，现在的EPC标签的成本己经下降到积分至几角钱。同时RFID识读器的成本降低，稳定性增强，体积变小，便携性提高等因素都促进了 RFID技术在物联网中的应用。
……..
2.2中间件技术
中间件原本是为了解决分布异构问题，使不同的应用程序能够运行在多种不用的硬件和操作系统上时所提出的概念。现在的中间件的应用变得逐渐广泛，其定义也变得模糊起来。现在的中间件包括对象中间件，交易中间件，消息中间件，数据访问中间件和消息中间件等。中间件的总体作用是通过中间件来适配多种不同的下层应用，而上层应用不用再关心下层应用的具体应用，只需要调用统一的中间件就可以完成自己的工作[23]。中间件需要根据底层应用的不同而去编写驱动程序，来驱动和管理每一种不用的下层应用，并且要预留接口，从而为新出现的下层应用适配。中间件向上层应用提供统一的连接接口，上层应用可以方便的调用。中间件在物联网中也有着广泛的应用，其中的RFID中间件在RFID识读器的管理中经常被应用，RFID中间件是介于前端读写器硬件模块与后端数据库和应用软件之间的重要环节，它是RFID应用部署运作的中枢。EPCGlobal标准也对RFID中间件的实现做出了定义。RFID中间件的主要作用是要对需要EPC标签的应用程序提供统一接口去操纵不同厂家生产的不同种类和规格的RFID识读器。应用程序只需将要完成的对RFID识读器的操作传递给RFID中间件，再由RFID中间件通过解析操作，将其转化为每种RFID识读器能够识别的指令发送给RFID识读器，完成操作后再将不同RFID识读器返回的信息作统一处理后产生应用程序能够识别的信息后返回给应用程序。在上述工作过程中，RFID中间件可以完成过滤冗余和错误的电子标签，整合数据，打包服务等方便应用程序工作的操作。
………..
3非集中管理模型的设计 ..........16
3.1本地服务器的功能设计.......... 16
3.2中央服务器的功能设计..........17
3.3中央服务器和本地服务器通信模块设计.......... 17
3.4本章小结.......... 22
4本地服务器的设计实现.......... 23
4.1本地服务器的体系结构设计.......... 23
4.2本地服务器的实体关系 ..........25
4.3本地服务器数据库设计实现.......... 26
4.4本地服务器实体类 ..........27
4.5本章小结..........28
5中央服务器的设计实现.......... 29
5.1中央服务器的体系结构设计.......... 30
5.2中央服务器的实体关系 ..........30
5.3中央服务器数据库设计实现.......... 31
5.4中央服务器实体类.......... 32
5.5本章小结.......... 33
7系统测试评估
7.1对系统的测试
对本地服务器的测试主要包括两部分，第一部分是对RFID识读器生命周期管理的测试，第二部分是对RFID识读器控制的测试。本地服务器对RFID识读器生命周期管理的实测：如图7.1所示，首先通过程序界面上的新建按钮打幵添加RFID识读器窗口，然后在该窗口内输入要添加的RFID识读器信息，在点击保存按钮后看到RFID识读器的相关信息列表里新添加了刚才输入的识读器信息。本地服务器对RFID识读器控制的测试：如图7.1所示，首先通过单击RFID识读器列表里的RFID识读器的记录信息选择要控制的识读器，然后在弹出的RFID识读器控制窗口进行控制操作。在RFID识读器控制窗口里通过点击建立连接按钮，本地服务器会去连接RFID识读器，并将连接的结果在操作按钮上方的文本框里显示出来。与此操作形似的进行RFID识读器的开始读、停止度、关闭连接操作。需要注意的是当点击开始读按钮后，识读器读取到的电子标签信息会在操作按钮下方的列表里展示出来，操作按钮列表里的清除记录按钮被点击后会清除电子标签列表里的记录。本地服务器程序对多个RFID识读器进行操作时只需要在程序主界面里选择不同的RFID识读器进行控制即可，被选择的相应的RFID识读器的工作状态会在打开的RFID识读器控制窗口里显示。
……….
结论
本文的主要研究内容是非集中控制下的识读器的管理方法和技术研究。非集中管理模型是为了解决集中管理模型不能适应RFID应用系统中RFID识读器的数量迅速增加导致的管理难题提出的。非集中管理模型将集中管理模型中的管理中心划分为两部分，分别是中央服务器和本地服务器。中央服务器专注于对要执行的功能进行分解，将具体的对RFID识读器控制的工作交给本地服务器去完成，同时，中央服务器和本地服务器采用Client/Server架构，耦合度较低，只在其需要控制时进行连接，中央服务器可以控制大量本地服务器。当RFID识读器应用系统中识读器数量增加时，只需要增加本地服务器的数量去管理新增加的RFID识读器。本课题实现了中央服务器程序和本地服务器程序，并经过测试和评估证明非集中管理模型更加适合拥有大量RFID识读器的应用系统。本系统需要进一步完善的地方有两个。第一，本地服务器向中央服务器返回的操作结果内容可以更加丰富。比如返回的结果要包括每一个RFID识读器完成操作的详细的时间花费，中央服务器根据具体的RFID识读器完成操作的时间花费可以采取更加优化的处理策略，比如对耗费时间特别长的某个RFID识读器进行工作状态检査或者使其暂时停止工作等特殊处理。第二，在本文实现的非集中管理模型系统中的多个本地服务器之间并没有交互，可以进一步设置本地服务器之间的交互规则，当某些本地服务器工作压力太大时，可以将任务分发给相邻的工作压力较小的本地服务器，达到所有本地服务器负载均衡的效果，使系统能够控制更多的RFID识读器。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇七
第一章绪论
1.1研究背景与意义
随着J2EE开发技术的不断发展，产生了很多的开源框架，这些开源框架由官方机构发布，并不断进行完善，在很大程度上提高了开发效率。尽管框架复用可以带来显著的回报，但是不可忽视的是，开发框架的投入往往更高，由于框架开发成本可能要大于复用框架带来的费用减少部分，这使开发一个框架变得不合算⑴。与此同时，在J2EE业务系统的开发过程中，始终存在着较多的重复性编码工作，这些工作大多是由一些基础的代码类或是简单的业务逻辑处理功能组成的，开发人员在编写这些代码的过程中，通过不断地复制、粘贴和修改等操作来完成编码工作，并进行调试。这些基本的编码工作虽然难度并不大，但在整个项目的开发过程中却占用了开发人员大量的时间，同时，不同的开发人员所编写的代码在风格与质量等方面也极不统一，维护性较差，且容易降低系统测试的效率。敏捷型软件开发方法就是把敏捷方法应用到软件开发中，避免在一些不必要，重复的环节上浪费太多的精力[2]。实现敏捷型软件开发，可以在软件开发的过程中采用代码生成技术设计并开发一套基于J2EE的代码生成工具。代码生成就是一个专注于解放编码生产力，用程序来编程的研究方向。如果做一些核查，可以发现很多内容都离不开代码动态生成，比较著名的就有Aspect!、Hibernate、Spring、Qojure、Groovy、JRuby、Jython、Eclipse 等。良好的代码生成工具应该具有多种优良的特点，不仅能够为开发人员提供尽可能多的功能，且需要开发人员进行操作或设置的步骤应尽可能减少或尽可能地降低操作的复杂度，同时，生成出来的代码应该符合相关标准，同时保持较高的可读性，效率尽可能优化、格式尽可能规范等要求，最终的目标就是尽可能多的减少开发人员的工作量，使开发人员能够将更多的时间投入到更加复杂的业务逻辑实现中来。代码生成工具的使用可以促使开发人员在预定的架构下进行编程工作；可以减少开发人员在框架中注入新特性；有利于减少团队成员半途离开项目组所带来的影响[5]。能够提高代码质量，缩短项目的开发周期和测试周期，提高软件开发的效率。
……..
1. 2代码生成工具的研究进展
早在专业的代码生成工具出现之前，很多主流的开发工具就已经想到并使用了代码生成技术，例如Eclipse开发工具就为用户提供了一些简易的代码自动生成功能，包括了生成数据访问对象、构造器等方法。除此之外，像Hibemate[6]这样优秀的处理持久层业务的开源组件同样为用户提供了能够自动生成持久类映射文件的代码生成插件，通过连接数据库并解析数据表结构的方式就能够生成持久化对象的映射文件，以及按照Hibernate的格式生成的处理持久层业务的基本方法。类似这样的代码生成技术还有很多，这些都是由开发工具本身为用户提供的旨在解决重复性编码工作问题的简易功能，这些功能都蕴含着代码生成思想，可以视为代码生成技术的一部分。尽管在现有的web开发工作中，有很多开发工具以及与各种开源组件相配套的插件式工具提供了各种各样的能够帮助开发人员在小范围内生成代码的功能，解决了局部生成通用性代码的问题，帮助开发人员在开发过程中提高了编码效率，但在一个完整的J2EE业务系统的开发过程中，这种局部的通用性代码数量会非常多，也就是说，会有很多时候需要使用这些辅助代码生成工具，往往使用这些辅助的代码生成工具进行多次操作才能完成一次代码生成工作。如果能够将各种辅助代码生成工具的操作步骤汇集于一身，并通过一次简单的配置操作过程来代替这些辅助工具的多次操作步骤总和，并能够完成多个部分的代码生成任务，这必然能够更大地提高代码开发的效率，也能够使开发人员将有限的时间投入到更复杂的业务逻辑实现中来。随着web开发技术的不断发展，代码生成技术也紧跟web开发技术的步伐，人CI通过不断总结Java开发过程中的各种问题，并汲取各种代码生成技术的思想，从而涌现出了各种专业的代码生成工具，这些代码生成工具无论从运行方式、核心技术原理、生成结果等方面都具有各自的特点，也具有一定的共性。
……..
第二章研究对象分析
2.1基础概念
本文的研究对象是基于J2EE业务系统的代码生成工具，基于J2EE业务系统就决定了代码生成工具所生成的代码是属于J2EE范畴的，在设计和开发代码生成工具时，需要了解代码生成工具本身的概念与研究目标，对其服务的J2EE业务系统加以认识，了解J2EE所包含的内容，明确业务系统的概念与特点，除了关注工具本身在开发时所使用的技术之外，更需要关注的是在未来使用代码生成工具进行代码生成时，是否能够保证生成的代码或各种文件能够符合相应的文件结构和语法要求，对于生成的web业务系统在框架技术的使用方面是否能够满足一定的标准，需要在对代码生成工具进行设计与实现之前作为概念性的内容加以了解。代码生成工具是一种通过编程的方式来实现代码编写的应用程序。由代码生成工具编写出来的代码类型没有局限性，可以为任何编程语言设计代码生成工具，同时，也可以通过任何编程语言来开发代码生成工具。无论代码生成工具采用哪种开发语言，无论代码生成工具所生成的是哪种类型的代码，对于工具本身来说，其主要功能就是生成代码，提高开发效率。
……….
2. 2代码生成工具的作用
代码生成工具的核心作用是代替幵发人员编写代码，目标是帮助开发人员减少更多的开发和测试工作量，围绕着这一核心功能，代码生成工具便能够发挥提高开发效率、保持编码风格统一和不断完善技术架构等作用。代码生成工具的首要功能就是代替开发人员完成重复性的编码工作，减少了开发人员进行重复性手工编写代码的时间，能够使开发人员将更多的时间花费在实现复杂的业务逻辑中来。同时，由代码生成工具生成的代码，在层次结构以及运行时的正确性和稳定性等方面能够保证质量，在将目标代码模板与代码生成工具进行整合之前，必须保证生成的重复性代码是经过测试验证的，不仅要使代码符合语法要求，更要保证代码在运行时不出现任何差错，保证运行时的正确性和稳定性，这样一来不仅减少了开发人员编写代码的时间，也减少了测试时间，从而提高了开发效率。在一个完整的项目开发过程中，项目组成员一般由多人组成，不同的开发人员具有不同的编码习惯，但却在同一个开发架构中进行编码，如果所有的重复性编码都由开发人员手动完成，则很容易造成整个工程在编码风格上出现不一致的问题，特别是在项目后期阶段出现项目组人员变更时，容易为其他开发人员在阅读代码时造成困难。而使用代码生成工具对重复性代码进行生成，无论是代码的结构还是格式等方面都完全统一，并且经过了整理和调试，可以被视为出自一人之手，这样一来，有助于提高项目组内的幵发人员对于代码的可读性，同时在开发人员通过手工编码实现复杂业务逻辑时，能够提供统一的参考形式，有助于保持整个项目编码的风格统一。
………
第三章代码生成工具的设计与实现......... 21
3.1代码生成工具的设计........ 21
3.2实现过程中的主要问题与解决方案........ 26
3. 3技术实现 ........30
3. 4 小结........ 49
第四章代码生成工具的应用与分析........ 51
4.1创建工程项目 ........51
4.2代码生成工具的使用........ 52
4. 3选择页面样式........ 58
4.4应用分析结果 ........59
4. 5小结........ 60
第五章结论与展望........ 61
第四章代码生成工具的应用与分析
本文研究的代码生成工具能够在实际的应用过程中帮助开发人员建立完整的工程项目，创建目录结构，并按照不同的目录分别生成相应的代码文件，大大减少了开发人员的手工编码时间，提高了开发效率，同时保证了代码质量和结构的一致性。本章通过生成实际的J2EE业务系统的方式，对代码生成工具的应用进行详细说明，对应用情况进行了详细分析。
4.1创建工程项目
代码生成首先基于业务系统的主体结构，因此，第一步就要创建业务系统工程的目录结构。为了减少手工创建工程目录结构的时间，可通过Eclipse开发工具创建web工程项目，创建web工程项目需要填写工程基本信息，包括工程名称、资源文件根目录以及工程文件根目录等。在这里将工程名称填写为project,上下文链接自动与工程名称保持一致，Eclipse为资源文件根目录默认指定为src，将工程文件的根目录默认指定为WebRoot，可以保持这两项内容不变，如图4-1所示：
………
结论
在J2EE业务系统的开发过程中，不断出现的重复性编码工作造就了代码生成技术，促进了代码生成工具的发展。通过本文对代码生成工具的设计与研究，相比以往的代码生成工具，改善了其中的部分缺陷，主要体现在运行方式、核心技术原理、风格样式生成以及其他辅助功能等方面。以C/S结构的编程语言对代码生成工具进行设计与开发，使代码生成工具成为立的应用程序，改变了插件式代码生成工具的运行方式，从而解决了插件式代码生成工具必须依赖于开发工具而运行的问题，同时解决了插件式代码生成工具难以兼容多种开发工具的问题，通过实践证明了该运行方式完全可行，且生成后的代码可以通过任何幵发工具进行二次开发，保持了代码生成工具与开发工具的良好交互性。以解析物理数据库结构化信息作为核心处理技术，使物理数据库成为代码生成工具与最终生成的业务系统共同使用的数据资源，能够保证生成后的业务系统直接与业务数据库进行交互，解决了由于建模文件与物理数据库的结构化差异所造成的种种问题，自动帮助开发人员完成数据源配置文件的编写与调试工作，节省开发人员针对业务系统与数据库连接进行调试的时间。以预定义级联样式文件的方式作为J2EE业务系统前台样式的生成方法，为代码生成工具在前台页面样式的生成方面提供了解决方案，有效帮助美工及开发人员在项目初期完成系统风格样式的设计与整合工作。此外，本文研究的代码生成工具在处理数据库结构化信息的过程中，针对特殊的大字段类型提供了业务系统常用的开发方式，包含了前台的展示效果与后台的业务逻辑实现功能，除此之外，还包括了有选择性的自动复制JAR文件、图片文件以及标签库文件等细节性功能，秉承了尽可能多地减少开发人员进行手工操作的理念，丰富了代码生成工具的功能。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇八
第一章绪论
1.1课题研究背景
最近几年随着经济的飞跃式发展，国内的航空行业也在快速地前进。在由铁路、公路、水路、管道和航空等各种运输方式组成的综合交通运输体系中，航空运输的地位日益提高。2014年上半年国内几大航空公司的旅客运输量大概增长了 4.7%。客运量虽然增长速率不是很快，但增速快于航空公司的运输能力，结果是上半年的总平均上座率达到了 80.5%。中国民用航空局局长李家祥说，“在可预见的未来二十年内，按照我国经济、社会的快速可持续发展的进程，我国民航业仍会继续保持迅猛的发展势头。今后几年，我国将新建造机场70个，重建和改建机场100个。到2015年底，航空机场数量将达到230个以上，旅客运送量将达到4. 5亿人次，具备运输能力的飞机2700架，从事工农林渔、医疗卫生、科学试验等活动的通用航空飞机2000架。预计到2020年，航空机场数量可能达、到240个以上，争取满足约7亿人次旅客运输量这一市场需求”。目前航空业仍然保持着10%的增长率，根据这个现状，只要中国改革措施适当，就依然会存在较大的发展空间。真正实现“未来一二十年航空业发展的美好图景”，成为名副其实的航空大国、航空强国。航空业的发展快慢取决于国家的改革力度，同时也取决于航空公司以及机场等多方面的努力程度。目前，全国有七大空管局、三十多家航空公司和一百多家机场。中国国际航空股份有限公司，截至2008年3月底，拥有以波音、空客为主的各型飞机224架，运营覆盖28个国家和地区的243条航线，每周为旅客提供超过6000个航班、100万个座位。东方航空集团公司，截止2007年底，拥有不同种类飞机221架次，经营国内外客运和货运航线共467条，通航亚、欧、拉、美、非五大洲的53个城市。南方航空股份有限公司是国内载客航班数量最多、空中航行线路最为密集、年客运吞吐量最大的航空公司，经营包括波音737、747、757、777以及空客A300、319、320、321、330在内的客货运输飞机330多架，航线网络连通全球841个目的地，连接162个国家和地区，到达世界各大枢纽城市。
………
1.2课题研究目的和意义
数据挖掘技术是指20世纪80年代末所出现的技术，运用这些数据挖掘技术，可以从数据仓库中提取大量的有用信息和知识，这些信息和知识是人们所感兴趣的、隐含在数据中的，具有事先未知性。用概念、模式、规则和规律等不同的方式将这些信息及知识展现给用户，使用户能够解决信息爆炸时代中的“数量过量，信息缺乏”的矛盾。人们最初的探索是在数据库中对知识发现技术(KDD)的研究，数据挖掘技术应该是起源于此，而知识发现技术是伴随着信息量的指数型增长，数据库已经存储了大量业务的数据，釆用机器学习等技术分析这些数据后，进而挖掘这些数据背后的隐藏的知识而发展起来的。随着KDD研究不断获得重大突破和成就，越来越多的科研人员投身于KDD的研究事业。数据挖掘是KDD最核心、最重要的部分，是釆用机器学习等方法进行知识挖掘的关键阶段，所发现的知识质量的优劣将直接受所选用的数据挖掘算法好坏的影响。当前，一方面国内航空市场的稳步式发展，吸引了许多国内的民营航空公司以及境外航空公司，它们纷纷介入，市场竞争日益激烈，航空公司的经营收入逐年下滑；而另一方面，受持续攀升的燃油价格及经济因素的影响，航空公司的运营成本不断地升高。因此，国内无论是大型航空公司还是中小型航空公司都面临着不同程度的经营困难，它们迫切地需要找寻并制定出一系列能有效降低成本、最大化自身收益的措施，增强企业的核心竞争力。
………
第二章数据挖掘技术
2.1数据挖掘的涵义
数据挖掘(Data Mining)是从大量具有噪声性、不完整性、随机性、模糊性的原始数据中，提取隐藏在其中的、预先无法知道的、但可能是潜在有意义的知识和信息的过程。自从1989年第十一届国际联合人工智能学术会议上正式定义数据挖掘的概念以来，它一直是国内外专家学者研究和讨论的热门话题。数据挖掘大致步骤是，分析和处理数据库中存储的海量数据，寻找出数据中存在的隐含关系，研究和建立数学关系模型，总结和归纳有用的规则及知识，进而能够在表面上看起来毫无规则的大量数据中预测出将来的轨迹及趋势，然后基于先验知识，协助做出预测性的判断。目前很多学科领域已经开始重视数据挖掘的研究，这些领域包括可视化技术、数据库系统、并行计算、概率论、人工智能、神经网络等；同时，作为一种实用型技术，数据挖掘已广泛应用于财务金融、材料加工、运营商、物流、医疗保健、制造、互联网、公检法等多个行业、行政部门以及科学和研究机构。常见的典型数据挖掘系统的结构如图2-1所示：
……..
2. 2数据挖掘的过程
数据挖掘一般是一个周而复始的过程，主要有确定业务对象、准备数据、挖掘数据、分析结果、同化知识这五个主要阶段组成，各个步骤如图2-2所示。在数据挖掘中，准确地判定所要研究的业务，明确挖掘的目标是非常关键的一步。被研究的业务对象在整个数据挖掘过程中占据重要性地位，它可以被称为驱动器，驱动着整个过程的进行，同时也是检验最终结果的凭据。虽然挖掘的最终结果是无法提前预知的，但事先应该对问题有大致的研究方向，带有盲目性的为了数据挖掘而挖掘的做法是不可能成功的。另外，业务对象也是引导分析人员完成数据挖掘的灯塔。专业的业务分析人员不仅需要熟悉业务，将业务对象分解剖析，而且需要根据不同的业务对象定义不同的数据类型，确定挖掘算法的业务需求。数据的准备由数据的集成、选择、预处理和转换四个步骤组成。数据集成，即分类合并来自不同的文件或者不同数据库系统中的数据，发现并纠正语义的模糊歧义性，清洗数据以及检测遗漏的数据等。数据选择，对所有与业务对象有关的内部和外部的数据进行搜集整理和选择，转换不同类型的数据，以及统一和汇总不同来源的数据。数据预处理，因为数据可能是具有不完全性、噪声性、随机性的复杂数据，所以需要评估数据的质量，初步的整理数据，过滤不完整的数据，并选择将要进行数据挖掘操作的数据类型，为下一步的研究做准备。数据转换，将数据转化为一个模型进行分析，然后编码处理数据，把数据库中不同字段的数值映射为相应的编码形、式。
………
第三章航班动态数据的挖掘与分析.......... 13
3.1机场繁忙度......... 14
3. 2航班准点率......... 18
3. 3航班上座率及相对平均价格......... 19
3. 4航班上座率与相对平均价格的关系......... 20
3. 5航班上座率与季节的关系......... 21
3. 6本章小结......... 23
第四章航班到达时间的预测算法研究......... 24
4. 1航班到达时间的影响因素分析......... 24
4.1.1航班飞行时间......... 24
4.1.2航班经停延误时间......... 25
4.2航班飞行时间的研究......... 25
4. 3航班经停延误时间的研究......... 31
4. 4航班到达时间预测模型......... 33
4. 5本章小结......... 35
第五章航班到达时间预测模型的实现.........37
5. 1时间序列预测模型......... 37
5. 2预测过程......... 38
5.3常见预测方法在航班到达时间中的应用.........39
5.4预测结果对比分析......... 40
5. 5本章小结......... 41
第五章航班到达时间预测模型的实现
针对航班到达时间的预测问题，本文选取时间序列的预测算法，尝试从航班动态历史数据中构建航班到达时间预测模型。时间序列一般指的就是根据时间先后发生的顺序采样获得的一组观测值。时间序列是一个有序的结构，按照数据种类的不同可以分为单变量时间序列和多变量时间序列。时间序列数据在自然、历史以及社会等各行各业广泛出现,例如动植物的物种数量在某个区域随着时间变化的增加减少情况、每天的股票走势、一个国家或者地区每个月的国民生产总值等等。时间序列预测带有很强的先后性，发生时间较早的事件会对发生在它之后的事件造成影响，反之则不会。这就意味着，对时间序列进行数学建模时，只能选择发生在前的事件来预测发生在后的事件，用较晚发生的事件来预测较早的事件是徒劳无功的。在时间序列中，预测点的数据或多或少受它之前发生的一些历史数据的牵连，但这些影响是不尽一致的。发生在预测点附近的历史事件对预测点的影响较深，在预测结果中所占比重较大；而发生时间比预测点早出很多的历史事件对预测点的影响较浅，在预测结果中所占比重相对较小。因此，对时间序列进行建模时，需要针对发生时间不同的历史事件分别分配不同比例的权值，这样才能保证预测的合理性。
………
总结
随着科技的飞速发展，大数据及数据挖掘技术是目前国内外非常热门的研究方向之一。同时，经济的发展和物质文化生活水平的提高，越来越多的人们出行旅游选择飞机这种交通工具，每时每刻都在产生着大量的航班动态数据。对航班动态数据进行分析和研究，可以挖掘出很多有用的信息。例如可以做精准广告，其中有两个必要因素，一个是时机，一个是广告内容。经验告诉我们，针对旅客发布广告的最佳时机是订票后到登机前的时间，而通过数据挖掘我们可以得知旅客可能需要什么。大数据带来两个作用，首先是用户画像，包括用户的年龄段、性别、行为习惯等，帮助我们提高广告的精准性，同时也区别了垃圾短信，避免用户的投诉。第二个作用是给我们一种预测趋势，给其它行业提供一套咨询报告，比如航空公司是否需要增加航线、保险行业可能想知道每年多少人出国，他们会在国外呆多少天等等。本人主要的工作内容可以总结为如下几点：
1)通过研究与本课题相关的数据挖掘技术的理论和方法，以及在各个领域的应用，运用特征提取的方法，挖掘航班动态数据中的关键特征，包括机场繁忙度，准点率、延误次数、上座率、相对平均价格、上座率与相对平均价格的相关性、上座率与季节的相关性等，发现其中的以前未知的信息。
2)对航班到达时间的预测分析，围绕航班的飞行时间以及航班的经停延误时间进行论述，飞行时间的计算分为直接计算方法和间接计算方法，主要是根据瞬时速度或者平均速度来计算求解，经停延误过程细化为三个步骤，对减速进站过程、停站上下旅客过程、加速离站过程进行了详尽的分析，综合以上因素提出了航班到达时间的预测模型。
3)根据航班到达时间的详细分析，介绍并选取时间序列预测模型，对预测过程进行分析，包括数据预处理、预测步骤、预测参数评估等，使用线性回归、非线性回归、人工神经网络、贝叶斯常均值网络方法实现基于航班飞行时间的航班到达时间预测模型，并对几种方法的性能进行预测指标评估。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇九
1绪论
1.1研究现状
基于模型检测的测试用例自动生成己经有较长的研究历程。由P.Ammann[5]等提出的贯彻始终的基本思想是利用模型检测工具提供的描述语言刻画软件需要满足的性质，并利用工具进行全空间的搜索；当性质不满足的时候，工具会扑捉所有的反例路径，然后再根据反例提供的线索生成测试用例。Cong Tian[6]等也提出了利用模型检测从谓语连词中自动生成测试用例的方法。并且提出了一个算法将测试用例的生成从基于原子谓语表达式的连接转化为模型检测。而韩国爸庆大学Jaeyoun Jung[7]等实现了一种为LTS过程规范而提出的模型检测工具，它可以用来检查死锁，活锁，可达状态以及动作。在国内，苏开乐[8]等提出了一种模型检测算法。该方法通过将时态逻辑CTL*符号化，并通过所谓的tableau构造方法来判定一个有限状态系统是否满足CTL*规范。清华大学何惜铎[9]等提出了一种基于谓词抽象和反例引导抽象求精技术对源程序进行建模和验证的模型检测方法和关键算法，并自行研发了一个模型检测工具Jchecker。而与此同时，TTCN-3作为一种功能强大的基于响应系统的黑箱测试标准，早已发展成为了一种通用的测试规格语言。早在1997年，国内学者郝瑞兵等就已提出了一种形式化的基于TTCN的测试执行方法。其使用了标号变迁系统(LTS)刻画了这一方法的整个执行过程，并给出了具体实现。而蒋凡等在经过多年在TTCN-3领域中的研究之后，其概括地提出了 TTCN-3测试套开发模式并实现了应用。而Niusha Hakimipour[l2]等，提出了一个从"需求”中生成测试用例的方法，并使用行为树(BT)来建模系统需求。国防科技大学颜炯等在基于模型的软件测试综述一文，先驱般地概述了基于模型的软件测试的方法，阐明软件测试模型是对软件行为和软件结构的抽象描述，可以用于生成软件测试例。模型检测的发展由Clarke首次提出之后，发展至今其焦点结果依旧是反例路径。即特定断言与抽象模型相违背，则必然存在反例"[14]，反例路径即不满足断言时的产物。所以目前大部分将模型检测和软件测试进行融合的研究都是基于反例生成测试套的。如魏堂[15]提出了一种基于模型检测的Web服务的测试方法，主要由反例路径引导，生成TTCN-3测试套生成技术，该技术通过解析反例路径来明确测试目的，进而生成TTCN-3抽象测试套。而徐世华提出了一种基于正例路径来进行软件测试的方法。
…………
1.2研究内容和方法
本文提出了一种模型检测引导的软件测试技术，主要内容为TTCN-3的抽象测试套生成，在前人[二]已论证LTS与BT(Behavior Tree,简称BT)的等价性的基础上，实现LTS到BT的映射，为实现基于LTS的测试套自动生成奠定基础。并基于模型检测模型LTS的TTCN测试套自动生成算法研究，提出模型检测引导的TTCN-3抽象测试套生成算法。算法研究分两个方面的工作。其一是TTCN测试套逻辑框架自动提取；其二是测试用例的自动生成。具体研究方法如下：
1)对待测系统进行模型检测，利用副产物演算作为简化的LTS。
2)基于LTS到行为树转换的理论方法[22]，提出模型检测引导的TTCN-3抽象测试套生成算法。
3)根据上述算法生成TTCN-3抽象测试套。
4)生成简单测试用例以及复杂数据的模板加载。
5)实现工具，并结合相关案例进行分析。
6)与实验室其他同学开发的工具进行整合，以形成一个模型检测和软件测试相互制导的完整模型。
7)为本实验室TTRun平台添加实例应用，咖啡机和八皇后。
………..
2相关理论和技术介绍
2.1模型检测中的LTS模型
经过论证，早在亚里士多德时代就开始了用自然语言进行时序分析，而模型检测(ModelChecking)作为一种自动验证技术，其发展至今只经历了不到四十年的时间。A.Pnueli在1977年第一个提出了对并发程序的推理使用线性时序逻辑。之后，EClarke和AllenEmerson首次提提出了第一个模型检测算法。其使用计算树逻辑(CTL)表达式描述系统的属性[23]。此后L.McMillan开发了符号模型检验(Symbolic Model Checking)工具，SMV从而得名[24]。他们将其应用于硬件检测方向，并延续发展至今。在这之后的上世纪八十年代就成为了模型检测发展的黄金时代。1986 年，CADP(Constmction and Analysis of Distributed Processes)工具集应运而生，最初只集成了 CAESAR和ALDEBARAN两个工具。随着之后的发展，目前已集成了四十多种工具，而其中EVALUATOR是用于不同的时序逻辑和演算的模型检测工具，用于检测系统是否满足给定属性。模型检测的基本步骤通常分为：建模、规范和验证。我们第一步对被测系统进行建模（LTS模型）。第二步为了明确测试目的，使用H演算公式进行规范，编写对应的时序逻辑属性。第三步利用EVALUATOR对手写的演算进行编译运行，得出结果。而本课题所使用的是模型检测过程中的副产物，即P演算公式。
……..
2.2 TTCN-3 概述
TTCN((Testing and Test Control Notation)是一个由 ETSI (European Telecommunications Standards Institute)维护的全球适用的标准测试语言。TTCN-3作为标准测试语言，其不仅囊括了普通程序设计语言的简单明了，易于人机交互。而且其拥有便于测试的功能支持以及广泛的接口机制，如动态测试配置、测试判决处理、定时器机制、通信机制以及良好的匹配机制等。?TTCN-3主要特征是抽象测试套件和适配层，允许完全可移植性的测试套件，从而使它们独立于任何平台实现之间的分离。测试适配器处理所有平台和执行语言（java，C，C++)与被测系统(System Under Test，简称SUT)的通信问题以及实际的应用的编解码需求。故而可以应用于多种类型的软件测试中。测试人员需要通过由组件控制（Component Handling)、编解码器(Codec)、系统适配器(System Adapter)、平台适配器(Platform Adapter)、核心的测试执行器（Test Executable)以及测试管理（Test Management)、测试日志（Test Logging)所组成的测试系统，将抽象测试套与被测系统进行通讯，从而达到测试目的。TCI和TRI分别是ETSI ES 201 873-5和ETSI ES 201 873-6标准中公布的两个接口。TRI(TTCN-3 Runtime Interface)是TTCN-3运行坏境接口，主要提供了测试执行器与平台适配器以及系统适配器的交互方法。TCI(TTCN-3 Control Interfaces)是TTCN-3控制接口，主要提供了测试执行器与测试管理、测试控制以及编解码器进行交互时所用到的方法。
………….
3 TTCN-3抽象测试套的自动生成...........15
3.1模型检测引导 .........15
3.2抽象测试套生成.........16
4测试例的自动生成 .........20
4.1解析BPEL文件......... 20
4.2简单测试例生成......... 20
4.3数据模板的加载......... 21
5工具的设计与实现......... 23
5.1整体系统设计......... 23
5.2解析文档......... 23
5.3工具界面设计 .........25
5.4编解码器以及系统适配器......... 26
5.4.1编解码器 .........27
5.4.2系统适配器......... 27
5.5测试执行.........28
6案例研究与评估
6.1案例研究
作为TTCN-3的入门，咖啡机问题很具有代表性，咖啡机作为被测系统，而要买咖啡的人的作为就可以看作为测试系统。50块钱一杯咖啡，买咖啡的人付钱给咖啡机，如果<50元则判决为失败，如果>=50元则成功出售一杯咖啡，并找零。同理，如果买咖啡的人付给100元钱贝U，出两杯咖啡。首先记录组件ID以及端口 ID，之后将编码好的消息进入队列，裉据时序要求启动被测系统实现Coffee Machine. Switch On O。然后等待被测系统返回的消息，解码，返回给测试系统。我们应该注意在适配的调试过程中可以适当增加log日志以方便对适配器进行调整和修改。最后，将写好的编解码器和适配器一起打包，然后加载到平台上，执行测试，结果如图6.7，我们输入了 3元，所以我们的得到的判定结果如预期的一致，是fail。八皇后问题是一个以国际象棋为背景的问题[38]:即如何能够在8x8的国际象棋棋盘上放置八个皇后，使其不能互相攻击，为了守护皇后则任两个皇后都不能处于同一条水平线上。即任意横行、纵行或斜线之上。
………
结论
随着模型检测的日益发展和TTCN-3测试技术应用领域的不断延伸，软件测试技术将迎来崭新的一页。我们要加强自动化的同时，缩减状态空间。TTCN-3抽象测试套，作为测试系统中不可或缺的一部分，应该提高其生成效率。包括测试系统所需的适配器以及编解码器等，也应该进行通用化的设计，以增强复用率，而测试平台的开发和移植，更是亘古不变的难题。这些都是责无旁贷的关键性问题需要我们去解决。本课题设计和实现了模型检测引导的TTCN-3测试套自动生成系统，对模型检测和软件测试方法进行了融合。利用模型检测中的副产物，形式化规约文件p演算来明确测试目的，从而转化为等价的TTCN-3抽象测试套。主要完成的工作如下：
1)通过对H演算的研究，分析生成TTCN-3抽象测试套的逻辑框架。逻辑框架拥有完整的时序逻辑关系。
2)解析建模过程中产生的物理存储文件，WSDL文件，根据数据类型，或加载模板，生成测试用例，并加载到之前生成的逻辑框架中。
3)根据文中所提及的案例，分析编解码器以及适配器的开发方法，编写配套的编解码器和适配器。
4)在八皇后的案例中实现了多端口的测试系统的适配器。提供了一种对于多端口的测试系统的适配器的编写方法。
............
参考文献（略）
专业工程硕士毕业论文范文精选篇十
1绪论
1.1课题研究背景及意义
随着近年来计算机硬件和计算机软件技术的不断发展，网络游戏的发展达到了前所未有的高度。中国网络游戏产业的业绩也逐年刷新纪录。根据中国音数协游戏工委的中国游戏产业报告显示，2014年我国整个游戏市场实际销售收入达到1144.8亿元⑴。由此可见，网络游戏己经成为我国互联网经济的支柱产业。如图1.1所示，根据2014年游戏产业报告显示，客户端网络游戏市场实际销售收入达到608.9亿元，客户端网络游戏市场占网络游戏的53.191%⑴。由此可见，客户端网络游戏（尤其是MMORPG)是网络游戏中最受欢迎的游戏。客户端网络游戏的游戏世界通常都是由多个独立的游戏地图构成。根据游戏设计的初衷，每个游戏地图又可以划分为多个独立的更小的地图块，每个地图块由一个或多个地图服务器管理。相邻游戏地图之间通常是孤立的，只有处于同一地图块中的玩家才有可能交互。当游戏玩家进入另一地图时，通常是在客户端播放一段过关动画或者用走不完的沙漠，打不完的怪等来掩盖服务器端的处理，以期给玩家提供一个真实的连续的游戏世界。但玩家进入另一地图时却处于与之前不同的位置，给玩家的感觉像是穿越到了这个地方，对进入的过程完全不得而知。网络游戏场景来源于对真实世界的模拟，当玩家处于一个游戏地图边界区域时，玩家应该看到在自己视野范围内的游戏对象，如其他游戏玩家，NPC等。因此，在游戏地图边界区域，如何减少服务器处理多人游戏场景同步的时间，如何解决玩家在边界区域的交互以及玩家跨过边界区域进入相邻游戏地图的处理等问题，直接影响着游戏世界的连续性，影响着玩家的游戏体验。所以，对于大型网络游戏跨服务器物理边界处理的方法研究十分重要。
…………
1.2国内外现状
据中国2014年游戏产业报告显示，客户端网络游戏用户数量达到1.58亿人，客户端网络游戏的销售收入占中国游戏市场总收入的53.191%。按游戏类型划分，网络游戏可划分为角色扮演类游戏和休闲竞技类游戏。其中，角色扮演类游戏占客户端网络游戏的比重最大，为63.9%[1]。从这些不断增长的数字可以看出，角色扮演类游戏已经成为游戏爱好者十分喜爱的游戏类型，同时，国内外游戏开发者和学者也从网络游戏场景管理、场景同步和服务器的设计等方面做了大量研究。2004年Takuji等提出了游戏服务器区域联盟的概念，通过将区域权威服务器节点的负载交由其联盟服务器节点处理，实现了游戏的可伸缩性[2]。2005年吴措等人通过使用文件记录八叉树信息，降低了八叉树算法的时间复杂度，缩短了场景实时植染时间[3]。2005年Anthonyt等采用了 DHT (分布式哈希表）和P2P的混合架构来管理兴趣域，通过区域中home结点、master结点和slave结点的交互，提供了很好的可伸缩性和容错性，给玩家提供一个连续的游戏场景2005年Bart等提出了动态微单元（每个微单元包含游戏场景的小部分）分配的方法来平衡服务器端的负载[5]。2006年张渊等提出了一种以空间二叉树为索引表的排序查找方法来查找游戏对象的兴趣域[6]。2007年Ihab等将游戏世界划分为多个相邻的六边形区域，每个区域由一个服务器节点处理，采用可见性驱动的方法使区域划分对用户透明，并提出了应用层播的方法，将过热区域分割给相邻的服务器节点处理，防止了单台服务器节点过热[7]。2007年程卫星等将网络计算引入网络游戏，解决了服务器间的资源共享、动态分配和负载平衡问题[8]。2008年Shun等提出了 VSM (Voronoi State Management)保存基于对等网络虚拟世界的对象状态的方法，实现了服务器的负载均衡、一致性控制和容错管理。2012年Virajith等将云计算引入了网络游戏，构建了一个无缝迁移云平台，与传统的云计算平台不同的是，它的网络基础设施分布在更广阔的区域，充分利用了网络资源。国内外的很多网络游戏，都是将整个游戏世界按故事情节等分场景组织，服务器端使用服务器集群来为成千上万的玩家提供服务，如魔兽世界、天龙八部等。
………….
2相关技术研究
2.1场景划分
游戏场景是整个游戏故事发生的地方，承载着游戏玩家、敌人、树木、房屋等游戏元素。早期的网络游戏只有一个较小的游戏场景，或者单块地图无限延伸，不存在游戏场景划分的问题。随着计算机技术的不断发展，网络游戏也逐渐向大场景方向发展，如天龙八部、魔兽世界等。这种情况下，游戏场景中会有成千上万的玩家同时参与游戏。由于服务器处理能力的限制，单台服务器已不能承载成千上万的玩家。因此，游戏场景划分问题应运而生。游戏场景划分是网络游戏的一种优化策略。当游戏场景中有多个玩家参与游戏时，客户端与服务器之间必须频繁地交换数据信息，来保持游戏场景的同步。如果有成千上万的玩家，游戏场景巨大，位于游戏场景两端的许多玩家根本互相看不到，也不存在任何的交互。这种情况下，如果每个游戏场景更新的消息广播给所有玩家，这将严重消耗网络带宽，引起网络延时。如果预先对游戏场景进行合理划分，这样当有更新消息时，只需要在较小的区域内广播这些消息，减少了网络带宽的消耗，同时减少了服务器同步的信息量。
……….
2.2游戏服务器架构
常用的客户端网络游戏架构有C/S (Client/Server，客户端/服务器）架构、P-2-P(Peer-to-Peer,对等网络）架构、混合架构。(1)传统的C/S架构如图2.1，整个架构只有一台服务器，所有参与其中的玩家客户端均与这台服务器交换信息。客户端负责显示游戏世界的实时情景，服务器端负责响应客户端的请求，游戏逻辑的处理等[12]。服务器是整个架构的核心，维护着服务器端游戏数据及大规模多人游戏场景的一致性。这种网络架构主要用于早期的网络游戏。纯粹的P-2-P架构如图2.2所示，网络中的计算机既是服务的接受者，也是服务的提供者，各台计算机完全对等。网络游戏中，其中任意一台计算机需要某个资源时，都需要广播信息给其他对等节点，拥有该信息的节点收到信息后，则向该计算机节点发送信息，表示查找到所需数据信息。这种网络架构由于没有服务器，使得查找相应的计算机节点变得复杂，并且釆用广播信息的方式也可能增大网络流量。因此，目前还没有采用这种纯粹的P-2-P架构的客户端网络游戏。但是，P-2-P架构的优点在于：充分利用了网络中的硬件资源和网络带宽，可以有效的减少游戏运营商的投资。混合式架构如图2.3所示，混合式架构结合了前面两种架构的优势。客户端与服务器之间采用C/S模式：客户端之间通过服务器进行信息交换，维护画面一致性。客户端与客户端之间采用P-2-P模式：如客户端之间进行会话并不通过客户端，客户端之间可以共享游戏数据信息等。通过客户端与客户端之间的通信，减少了服务器的信息处理量，减轻了服务器的负担。现如今，大型大规模多人游戏多采用这种架构。
……….
3场景划分与游戏架构...........9
3.1场景划分研究......... 9
3.1.1静态场景划分研究......... 9
3.1.2动态场景划分研究......... 10
3.1. 3游戏场景划分......... 13
3.2游戏架构......... 14
3.3实验结果与分析......... 16
3.4本章小结 .........17
4场景同步......... 18
4.1场景同步概述 .........18
4.2基于AOI的游戏场景同步......... 18
4.3改进的基于AOI的同步......... 20
4.4实验验证与分析......... 23
4.5本章小结 .........26
5跨场景边界问题研究......... 27
5.1跨边界问题概述.........27
5.2跨边界问题......... 27
5.3实验验证与分析.........31
5.4本章小结......... 35
5跨场景边界问题研究
5.1跨边界问题概述
关于边界区域的交互问题，国内外很多学者也在做深入研究。Cronin等提出了镜像服务器的架构，每台服务器都有同一游戏世界的拷贝，所有客户端在服务器间均衡分配。但是由于服务器间需要同步的信息过多，因而很难在所有的服务器之间保持数据一致性。因此，任何一台服务器都无法完全拥有完整的游戏世界[37]。Bart等提出了动态微单元划分游戏世界的方法，采用了共享存储机制，但只考虑了同一台服务器管理的微单元之间的交互，并未考虑与其他服务器管理的微单元的交互[38]。Jiang等构建了一个区域分配的优化模型，证明了区域分配是一个NP难度的问题，并提出了在P2P系统中采用启发式的方法来划分物理网络和游戏世界的方法，以此来减少区域之间的交互开销[39]。陈杨提出了一种在客户端将用户标记为跨界状态的方法来完成用户的跨界，但没有考虑游戏后期的扩展结合前人的技术，本章将对网络游戏中游戏对象在边界区域存在的问题的解决方法做深入的研宄。本章提出了解决玩家在场景边界区域场景一致性的方法。当玩家处于边界区域时，既可以与当前服务器中的玩家交互，又可以与相邻区域中的玩家交互，并且实现了玩家从一台服务器到另一台服务器的迁移，呈现给玩家一个连续的游戏世界[41]。
……….
总结
大规模多人游戏中，连续的游戏世界是影响用户体验的重要因素，同时也是游戏开发过程中需要解决的重要问题。给玩家提供连续的游戏世界，必须保证玩家游戏场景的一致性。大规模多人网络游戏通常需要多个服务器分别处理不同的游戏地图块，地图块之间的过渡区域为边界区域。解决玩家处于边界区域以及跨边界时存在的问题，是保证游戏场景一致性的关键。针对玩家在场景边界区域以及跨边界存在的问题，本文提出了一种维持游戏场景一致性的方法，并通过仿真实验验证了方法。从游戏场景一致性出发，本文对游戏场景划分、游戏场景同步、边界场景一致性以及跨边界迁移的问题，分别进行了研究，并提出了相应的方法，主要研宄成果如下：
(1)划分游戏场景并设计实现游戏的服务器端。文章首先分析现有的几种的游戏场景的划分方法，总结了其优缺点，给出了本课题游戏场景的划分方法，并设计了游戏的架构设计，最后通过仿真实验进行了验证。
(2)改进并实现了基于AOI的场景同步方法。文章首先分析了现有的几种场景同步方法的优缺点，并提出了一种改进的场景同步方法：增加了玩家的远视域，同时对玩家对象和NPC对象分别同步。最后，仿真实验结果的分析对比验证了该方法能够有效地减少服务器处理AOI的时间，以及向客户端同步的信息量。
(3)在相邻服务器引入消息订阅、跨界缓冲区、场景同步，提出了通过跨边界游戏对象实时迀移来解决玩家跨边界问题的方法。在边界区域，通过相邻服务器实时同步边界区域的游戏状态信息，保持了边界区域游戏场景的一致性以及玩家的跨边界实时迁移，最后通过实验验证了提出的方法的可行性。
............
参考文献（略）