基于Java组件的无人机售后服务MIS系统的设计与实现本科毕业设计论文Word格式.docx
《基于Java组件的无人机售后服务MIS系统的设计与实现本科毕业设计论文Word格式.docx》由会员分享，可在线阅读，更多相关《基于Java组件的无人机售后服务MIS系统的设计与实现本科毕业设计论文Word格式.docx（61页珍藏版）》请在冰豆网上搜索。
6）论文主体部分：
引言（或绪论）、正文、结论
7）参考文献
8）致谢
9）附录（对论文支持必要时）
2.论文字数要求：
理工类设计（论文）正文字数不少于1万字（不包括图纸、程序清单等），文科类论文正文字数不少于1.2万字。
3.附件包括：
任务书、开题报告、外文译文、译文原文（复印件）。
4.文字、图表要求：
1）文字通顺，语言流畅，书写字迹工整，打印字体及大小符合要求，无错别字，不准请他人代写
2）工程设计类题目的图纸，要求部分用尺规绘制，部分用计算机绘制，所有图纸应符合国家技术标准规范。
图表整洁，布局合理，文字注释必须使用工程字书写，不准用徒手画
3）毕业论文须用A4单面打印，论文50页以上的双面打印
4）图表应绘制于无格子的页面上
5）软件工程类课题应有程序清单，并提供电子文档
5.装订顺序
1）设计（论文）
2）附件：
按照任务书、开题报告、外文译文、译文原文（复印件）次序装订
3）其它
摘 要
本文研究的主题是无人机售后服务管理信息系统的开发过程。
系统涵盖了西安ECN技术集团公司无人机售后服务业务的全过程，包括了服务立项、工程分派、维修执行等7个业务环节，涉及了售后服务办公室、财务部、设计部等11个部门。
系统解决的主要问题是售后服务业务流程控制、业务输入重复工作缩减和基于数据重用的精确统计输出。
系统的整体设计充分考虑了全面性、安全性和高效性的原则，力求数据库和程序算法上的准确和精要。
在面向对象（ObjectOriented，OO）思想的前提下，本系统选用领域内最常用的统一建模语言（UnitedModulingLanguage，UML）进行系统的分析和设计。
基于UML设计模型图，选择企业级应用最广泛的Java平台来配合作为本系统的主要实现手段。
系统的所有工作都建立在详细需求报告的基础上，报告的内容源自与客户的多次反复沟通，并全面覆盖了无人机售后服务的相关业务。
本文从系统工程角度描述了本系统的开发流程，将系统分解成25个基础用例，在用例的基础上设计JavaServlet组件，并最终通过Java代码来实现。
本文的研究成果在于成功地完成了一个基于Java组件的Browser/Server模式系统的开发。
实现环境建立在ApacheTomcat5.0前台应用服务器和IBMDB27.2后台数据库管理系统上。
经过2个月的设计与编程，系统目前已处于测试阶段，由于基本满足了初期需求设计，获得了售后服务办公室职员的好评。
关键词：
售后服务，UML，用例，Servlet组件，JavaBean
ABSTRACT
ThediplomathesisonhandconductsaprocedureofManageInformationSystemdevelopmentreferstotheunmannedaeroplaneafter-servicemanagementofECNcorporation.SuchM.I.S,covers7businesssegmentsand11departments,allowsforsupervisionaswellasoptimizationofAfter-Serviceprocedure,reductionoreliminationofrepetitivemanipulationanddeliveramulti-functionalprecisestatisticsfortherefinementofunmannedaeroplanebasedonthedatareprocessing.Beingobedientwithcomprehensive,secureandefficientrules,suchsystemisdedicatedtoalgorithmrefinementincodeanddatabasedesign.
Thisspecificsystem,planned,analyzedanddesignedviaUnitedModuleLanguage（UML）toolkit,isdevelopedanddeployedontheplatformofJava2.Allofabovearebasedonthedetailedrequirementreport,whichderivesfromrepetitivecommunicationswiththecustomersandmustbeassociatedwithoneormoredailybusinessneeds.Thisthesispresentsasystematicalapproachtobreakdowntheprojectinto25use-cases,onwhichtheJavaServletcomponentsdesigningisbased,andisultimatelyimplementedbyJavacodeclasses.
BuiltontheframeworkofBrowser/Servermode,theresolutionruntimeenvironmentiscomprisedofIBMDB27.2databasemanagementsystemandApache-Tomcat5.0JSP/ServletApplicationServer.Andafter2months’researchanddevelopment,thesystemhasbeenaccomplishedandrunssmoothlyontheserver,whichobtainshighpraisefromtheusers.
KEYWORDS:
After-Service,UML,use-case,Servletcomponent,JavaBean
第1章绪论
1.1研究的背景
现代营销理论将企业营销的中心定位于更全面有效地满足客户，在此基础上诞生的4Ps理论从产品（Product）、价格（Price）、渠道（Place）、促销（Promotion）四个基础变量对这一理念进行了全面的阐释。
产品（Product）概念也远远超出了传统范畴，将包装、商标、售后服务、质量保证等也一并囊括进来，于是就衍生出除核心产品以外的形式产品和附加产品。
售后服务作为附加产品的重要部分虽然不直接带给消费者基本功能上的满足，但在近三十年市场经济发展中却越来越体现出在产品销售中不容忽视的重要地位。
时下，无论是企业还是客户，对产品售后服务的关注都是空前的。
显然，消费者可以省去许多在产品使用过程中产生的额外成本，售后服务突出的厂商又可以借此获得竞争力。
同样热门的另一领域，计算机和网络技术风靡全球，计算机辅助管理软件广泛应用于不同规模的企事业。
从图书借阅系统、饭卡管理系统、话吧收费管理系统，到大型企业的ERP系统、销售管理系统、合同管理系统，信息化的足迹随处可见。
计算机技术被越来越多地应用到现代各个领域的管理中，并日益渗透到日常管理的深层细节，实现了两者的无缝结合。
信息化与营销管理最直接的结合点就是销售订货管理系统和售后服务管理系统。
售后服务管理系统在营销管理中的地位也就不言而喻了。
ECN无人机售后服务管理系统（After-ServiceManagementSystemofECN，以下通称ECN-ASMS）的开发研究始于西安ECN技术集团公司售后服务办公室（以下简称售后办）“管理信息化”的需求。
售后办目前的日常业务主要应对无人机客户提出的产品售后需求，业务环节包括最初的客户接待、维修立项到后期复杂的任务分派和费用结算。
在这些环节中，售后办操作的业务对象是大量的表格和单据，并且要求尽可能保证表单在业务流程各环节中准确高效地传递和统计。
由此，需要一套更好的解决方案来辅助手工操作。
1.2研究的目的和意义
1.2.1问题提出
售后办职员在实际工作中遇到两大难题：
1.多客户并行服务的流程管理问题
售后办受理的无人机客户提出的现场维修、备件购置、返所维修等业务。
针对每一位用户提出的服务需求，售后办都需要一套明确的业务流程与之相匹配。
业务流程包括从“服务需求登记”到“用户服务费用结算”的7道流程，涉及了飞机室、飞控室等11个相关部门。
传统的纸质办公可以有效地应付单笔需求的业务管理控制，但一旦两个以上客户并行提出服务需求时，流程的控制及部门间的协作效率就捉襟见肘了。
2.某一时段服务数据的统计问题。
售后服务业务数据最终有两方面应用：
一、用户资料的数据统计和维护；
二、产品反馈信息的统计和维护。
前者向销售部门提供用户的消费信息，如对产品消费频次，用途等，本系统体现在特定客户对无人机的购买周期和频次；
后者的信息涉及产品使用的质量反馈结果，体现在某一机型或某一配件的故障频次，该统计信息可以反馈给设计部或相关制造部门，对无人机研发制造进行改善。
但是，业务数据统计一直是传统纸质办工最大的效率瓶颈。
每次上报季度或年度统计数据，售后办职员都要投入大量的时间，翻阅大量的服务表单来提取统计数据。
不仅耗费时间成本，而且最大的问题在于统计数据不准确。
实践验证，有时间压力的前提下，人工计算统计会不可避免地出现或大或小的统计误差。
统计误差对任一单位部门带来的可见和潜在的损失都是无法预估的。
此外，售后办每位职员配备一台计算机，但是纸质办公主导了业务主体，现有的计算机资源无法充分利用。
因此，基于上述问题和硬件环境，本文的焦点在于寻找一套有效的解决方案，该方案需要满足四个基本条件：
1、充分利用现有的计算机资源，远期易扩展（系统功能和系统用户能迅速完成扩充）
2、准确管理每笔业务和服务数据，使表格和单据流的各个环节衔接更通畅
3、减少重复性工作，对已有的数据实现重复利用和职员、部门间共享
4、从不同的对象角度，提供快速、准确的统计数据。
1.2.2研究意义
ECN-ASMS是有效的信息化解决方案。
结合ECN技术集团公司售后服务的管理现状，分析日常人工管理中存在的问题，本系统开发研究的作用在于改善售后服务管理的业务流程，提高整体流程的系统性、一致性和信息流的准确性，并最终从准确和高效两方面满足售后办对日常表单的统计需求。
ECN-ASMS开发的目标分解为以下三个方面：
1.系统性：
功能全面合理，覆盖售后服务管理业务的整个流程。
2.一致性：
业务数据实现数据采集一致，程序处理一致和输出格式一致。
3.高效性：
优化程序算法和数据库算法设计，提高系统的运行速度。
系统目前已处于测试阶段。
从实际运行效果来看，随着基础数据的积累和业务数据的增加，系统的优势也越来越明显：
一方面，基础数据能重复应用在表格录入中，提高表格的输入速度；
另一方面，时段业务数据的统计能准确反应出无人机的性能缺陷以及零部件库存管理等信息，为无人机的改进和客服质量的提高提供数据参考。
1.3研究的内容和方法
本文研究的主题是ECN-ASMS，开发一个基于B/S模式的管理系统，所有业务数据建立在关系型数据库存储调用的基础上。
系统的分析设计采用面向对象法（ObjectOriented，OO），主体程序开发选用java语言与之相适。
初期，从售后办的日常业务入手，进行需求分析，系统详细分析和系统设计。
全文的核心是分析和设计部分，采用的工具是面向对象建模领域最流行的统一建模语言（UnifiedModelingLanguage，UML）。
UML与系统开发的各个阶段相结合产生了本文核心内容的行文思路，如图1-1所示。
业务分析阶段采用过程图描述售后办业务，剧本分析用于整理业务流程线路，并以UML活动图形式建立业务模型；
需求分析阶段采用UML用例图建立本系统的核心用例模型图。
用例分析阶段利用UML顺序图对用例模型进行分解阐释。
图1-1本文核心内容行文思路
系统设计阶段主要采用UML体系结构设计模型，分析的过程基于包（Package），并在详细设计过程中拆分包，细化到类（Class）以及类的属性和方法。
本文的另一焦点是探讨ECN-ASMS系统实现中四大难题的解决方案。
应售后办需要，ECN-ASMS系统中集成了5项独特设计，除界面设计外包括了软件防拷贝、系统安全、系统监控和统计输出四个问题，涉及的相关技术包括了MD5单向散列加密技术、硬编码获取、PDF报表打印等。
这5项设计尝试在同类系统中并不多见。
第2章ESC-ASMS框架与开发方法
2.1系统的物理结构
目前，数据库应用系统常用的物理结构有本地型数据库应用模式、客户机/服务器（Client/Server，C/S）模式和基于WEB的浏览器/服务器（Browser/Server，B/S）三种。
系统结构的选择之所以重要是因为它不仅直接影响到系统用户对运行环境的软硬件和网络进行选择，而且也会影响到开发模型、开发语言及开发策略的选择。
2.1.1C/S数据库应用模式简介
常用的企业级数据库应用系统结构有C/S和B/S两种模式，前者建立在前端客户程序与后台数据库服务器的基础上，是典型的二层结构，如图2-1所示。
图2-1C/S数据库应用系统模型
客户端数据库应用程序向数据库服务器发送服务请求，服务器一方面从数据库存取数据，另一方面对数据进行适当的处理，并最终向客户端返回处理结果。
现代系统控制论中有条公理,越简单的系统越稳定[1]，从结构模型看C/S模式层次简单，节省了多层次带来的不必要效率开销，符合了公理。
但主要缺点是：
1.业务数据的安全问题。
前端程序与后台数据库直接通信降低了业务数据的安全性，客户端受到病毒或黑客攻击时将直接影响到核心信息业务的完整性和保密性。
2.维护不便。
两个或两个以上的客户端使用系统时，部署阶段需要为每一个客户端安装一套客户端程序；
升级阶段同样需要为每一个客户端进行逐个调试。
2.1.2ECN-ASMS数据库应用模式
早期的系统一般客户端数量较少，C/S模式比较适合。
但本系统考虑到数据安全等诸因素，选用的是基于WEB的B/S模式[2]。
这种结构在目前大中小型企业中是应用最广泛，如图2-2所示。
图2-2ECN-ASMS物理结构模型
售后办的内部局域网是前提，在此基础上售后办的任意终端可以直接通过浏览器（IE或NetScape）访问ECN-ASMS的Web服务器。
内部运行过程如下：
首先，Web服务器向访问客户发送静态文本（HTML）页面，并同时把客户端的请求发送到应用服务器的JSP/Servlet引擎；
其次，JSP/Servlet引擎解析Servlet代码与数据库建立连接，实现数据的读写交互操作。
在这个过程中，Web服务器与应用服务器中的JSP/Servlet引擎实现了动态与静态业务的分工，前者由专门处理静态页面的WEB服务器Apache来承担，后者由ApacheTomcat承担处理动态业务，实现两者的无缝结合。
建立在WEB基础上的B/S模式与上文C/S模式相比有什么优点？
1.业务数据更安全。
在用户和数据库间，B/S系统多了WEB服务器和应用服务器两个控制层，实现客户端与数据层的有效分离。
另一方面，大型的C/S系统软件通常安装在多个服务器上，需要在多个服务器间进行数据同步，那么任一台服务器数据的安全都会影响到整个系统的安全，而B/S的数据集中放在一台数据库服务器上，解决了C/S模式业务数据的脆弱。
2.部署维护方便。
不考虑服务器主机的性能，B/S结构可以轻易实现远程客户端的无限量扩充，客户端只需具备网络环境就可以直接通过互联网接入系统，相比C/S模式省去了逐个客户端布署调试的工作量；
同理，在系统维护和升级阶段，本模式只需要在服务器端一次修改就可以在所有客户端运行更新后的系统。
3.客户端硬件要求低。
B/S模式的系统把所有的业务和数据处理都集中的服务端，大大减轻了客户端硬件的处理负担，所以，系统对客户端的硬件基本要求几乎可以忽略，只需要具备浏览器和联网环境，是对系统良好扩展性的支持。
结合ECN技术集团公司的实际情况。
ECN-ASMS选择B/S模式出于以下三点的考虑：
1.业务数据的特殊性。
ECN-ASMS的业务数据关系到军方涉密信息，所以核心数据的保密性、完整性和可用性是系统首要解决的问题。
在结构方面，B/S模式是相对有效的解决方案。
2.用户数量难以预估。
ECN-ASMS的II期工程要求对外提供一个可访问系统部分业务的接口，受众范围从公司发展到全国，最终面向全球。
从长远角度估测，客户端数量较大，而在用户扩充上C/S模式没有B/S灵活便利。
3.统计的准确性要求。
ECN-ASMS统计模块需要为无人机设计和销售提供精确的统计数据作有效参考。
ECN-ASMS的覆盖面扩大后，应流量和地域的需要，C/S难以实现多服务器间数据的实时同步，当业务发生变化时看到的往往是事后数据，影响到时段统计数据的准确性和业务的实时管理；
相反，B/S的优点在于无需多服务器分担，也就不存在数据同步问题。
2.2系统应用程序构架
企业级应用系统通常可分为两层、三层或N层，这里的层指的是代码层，即一条信息从客户端到达数据库后，又返回客户端需要穿越不同代码层的数量。
2.2.1传统二层架构简介
二层架构一般应用于轻量级的系统，业务处理量较小。
这类系统通常包括前台视图层和后台数据库两部分[3]。
如图2-3所示
图2-3二层系统架构图
其中视图层（B/S）一般采用ASP、JSP、Perl等技术编写代码功能页面，这种结构的使用户可以通过第一层接口与数据库直接发生交互操作，优点是运行稳定处理逻辑少，速度快；
缺点是用户直接通过页面代码层与数据库交互，业务数据的安全性较差，在实际应用中二层架构的系统通常是黑客攻击的目标。
2.2.2基于J2EE的MVC架构简介
MVC是一个面向重量级业务系统搭建的构架模型。
MVC（模型层－视图层－控制层，Model-View-Controller）主要设计思想是把数据输入、处理和输出按Model-View-Controller的三层界定标准进行分离[4]。
三层的标准和功能如表2-1所示。
表2-1MVC层次综述表
层
功能
常见方案
视图层
与用户交互
页面布局组件、HTML/JSP等
模型层
接受视图层数据，进行业务处理并返回处理结果。
其中业务处理模型是MVC的核心，处理过程对外不可见。
派生于ProcessBase类和派生于EntityBase类的业务实体对象以JavaBean形式存在[4]
控制层
接收并处理用户请求、将请求委托至分发类、根据业务处理的状态来决定视图层显示的内容
Servlet
或JavaBean（Controller）
MVC运行的基本范式[4]如图2-4所示：
控制层获取视图层的用户数据请求，委托模型层对象来处理应用领域的内容；
模型层对象向视图层发出内容更新的信号；
视图层通过控制层对象对内容更新的影射进行内容的显示。
图2-4MVC运行范式图
MVC的优点很多，实际应用中通常在构建大型系统中能体现良好的性能，但在中小型的系统开发中却并未如此，常见的缺点有：
1.增加系统结构的复杂性。
对于业务简单的系统采用MVC模式进行三层分离会增加系统结构的复杂性，导致运行速度和稳定性的下降。
处理流程的复杂度最终导致系统运行效率的下降。
2.视图层访问数据效率低。
模型操作的接口往往是不同的，所以很容易出现多次取库的情况，即视图层可能需要调用多个接口才能够获取足够的数据项，这是效率的损失。
3.开发过程复杂。
MVC在实现过程中加入了中间级别，增加了系统的复杂性，在视图中加入了用户界面代码的事件驱动，两者增加了开发者在用户视图调试的困难。
总体增加了系统开发的工作量，延长了开发周期。
因此，MVC实际上并不是中小型系统的理想方案。
在实际中小型系统开发中，花费大量时间在MVC框架组件的搭建上往往得不偿失。
2.2.3ECN-ASMS实际架构模型
系统的架构直接关系到系统的开发周期和运行效率。
以上介绍的两种是目前流行的WEB架构，前者适用于业务相对简单的小型系统开发，后者多用于大型复杂系统。
二层架构与三层MVC，两者各有优缺点，但从总体框架上进行归类可以发现两者的优缺点刚好是互补的：
前者以简单的业务逻辑换取运行效率，而后者以运行效率为代价换取复杂业务的处理能力。
从售后办的实际业务流程和业务量出发，ECN-ASMS充分考虑了二层架构的性能和MVC业务能力，提出了一套基于Servlet和JavaBean组件的三层架构模型。
ECN-ASMS顶层架构模型如图2-5所示。
图2-5ECN-ASMS系统架构模型图
相比二层结构，ECN-ASMS在视图层中取消了直接操作数据库的代码，从中分离出了包括表单提交、数据库修改和业务流控制三部分核心代码，避免用户与核心代码的直接交互，阻止用户层对数据库的直接操作。
分离出来的三部分核心代码在视图层与数据库间单独建立一层用于控制数据库连接和业务流的组件层。
该层的组成元素包括两部分：
1.Javabean组件设计
用于数据库连接及操作的bean、单向散列摘要生成器和权限控制器等10个组件。
这部分组件主要用于控制视图层的显示和Servlet中的业务逻辑。
两项职能实际上没有本质的区别，都并实现了基于功能模块的控制逻辑。
因此，bean通常既在JSP显示页面中调用，也在Servlet业务类中调用。
2.Servlet业务组件，包括了核心的表单提交组件、报表生成器和下载组件在内的25个处理逻辑。
这部分组件主要面向业务，从视图层获取业务数据或访问请求，与数据库建立连接并进行必要的数据处理，最后返回至视图层。
ECN-ASMS三层架构的运行过程如图2-6所示。
图2-6ECN-ASMS运行模型图
自建模型的原因：
1.售后办的业务复杂度和业务量尚未达到构建MVC级别框架的最佳程度，如采用MVC架构，结果只会降低整体系统的运行效率。
2.组件层的Servlet和JavaBean组件在设计和实现过程中根据售后办的实际业务量身定做，不存在功能模块的浪费，故不会造成系统运行效率的损失。
3.
升级会员 