基于SSH架构的多媒体网站管理系统.docx
《基于SSH架构的多媒体网站管理系统.docx》由会员分享，可在线阅读，更多相关《基于SSH架构的多媒体网站管理系统.docx（24页珍藏版）》请在冰豆网上搜索。
基于SSH架构的多媒体网站管理系统
吉林大学珠海学院
毕业设计（论文）
基于SSH架构的多媒体网站管理系统
TheMultimediaWebsiteManagementSystemBasedOnSSH
完成日期：
2013年1月17日
吉林大学珠海学院本科毕业论文（设计）开题报告
摘要
在目前流行的网络环境之下，有不少诸如视频网站，音乐网站甚至是制图网站，它们满足了大多数网民对于媒体资源的诉求，但是有一些用户并不满足于此。
由于当今社会对于版权问题十分重视，这些网站并不能满足所有人的喜好。
加上媒体网站只主推一种产品，对于媒体文件之间有效的整合和互相的转换都少有涉及。
在资源的购买方面，没有一个有效和规范的环境，在这样的前提下，很难保障上传者和下载者的实际利益。
从以上几个方面看，能够推出一个满足用户个性化要求，又不伤害其他人的利益的多媒体网站管理系统是很有必要但是却不容易实现的。
经过反复的讨论和论证，针对这样的问题和之前的构想，加上委托方的要求，建立一个私人的，小范围使用的多媒体网络管理系统，既不会伤及版权问题，又可以尽量满足会员的个性要求。
在目前的环境之下是一个最好的解决方案。
需要指出的是，本网站并不是对所有的网络使用者开放的，而是对定制用户开放的，所有的用户必须得到授权才能进入。
关键词：
Struts2；Spring；Hibernate；Oracle；网站管理
Abstract
Underthecurrentprevalentwebenvironment,lotsofwebsiteshavemettherequirementsofmostofnetusersformediaresources,Suchasvideosites,musicsiteseventmappingsites,butsomeoftheusersarenotsatisfiedwithit.Thesewebsitesarenotabletomeetthepreferenceofeverybodybecauseoftheattentionforcopyrightproblemsinthesocietycurrently.Inadditional,mediasitesonlypromoteonekindofprincipalproduct,theinvolvementsoftheeffectiveintegrateandtransformamongmediadocumentsarerare.Asforthepurchaseoftheresources,itisshortofavalidandcanonicalenvironment.Undertheconditionlikethis,itishardtoprotecttherealisticbenefitsofbothuploadersanddownloaders.
Fromtheseaspectsabove,itisnecessarybuthardtobuildamultimediawebsitemanagementsystem,whichcanmeetthepersonalrequirementofusersanddon'thurtthebenefitsofothersatthesametime.Afterrepeatingdiscussionandprofanes,aimingattheproblemsandpreviousthoughts,plustherequirementsofprincipal,buildingaprivateandsmall-range-usemultimediawebmanagementssystemwon'thurtthecopyrightandcanmeetusers'personalneedsbest.Itisthebestsolventinthecurrentenvironment.
WhatIneedtopointoutisthatthiswebsiteisnotopenedforeverywebuser.Instead,itisopenedforspecificuserswhichmeansthatalltheuserscan'tenterthewebsiteunlesstheyhavegottheauthorization.
Keywords：
Struts2；Spring；Hibernate；Oracle；Websitemanagement
目录
1.绪论………………………1
1.1研究背景………………………1
1.2开发环境简介………………………2
1.2.1SSH系统架构简介………………………2
1.2.2Mysql数据库简介………………………2
1.2.3Oracle数据库简介………………………3
2.需求分析………………………4
2.1需求调研………………………4
2.2需求分析………………………4
2.3系统功能分析图………………………5
3.总体设计………………………6
3.1系统结构图………………………6
3.2总体功能设计………………………7
3.3系统E-R图………………………8
3.4数据字典………………………9
4.设计思想与实现思路………………………12
4.1用户注册登陆模块………………………12
4.2媒体资源模块………………………15
4.3用户信息模块………………………22
4.4财务管理模块………………………23
4.5评论模块………………………24
4.6在线编辑模块………………………25
4.7直播模块………………………26
4.8搜索模块………………………26
5.系统测试与运行………………………28
5.1系统运行环境………………………28
5.2系统测试的重要环节………………………28
5.3系统测试用例………………………29
5.3.1在线编辑功能集成测试测试用例………………………29
5.3.2登录功能阶段性纠错测试测试用例………………………29
5.3.3搜索多媒体资源功能阶段性模拟测试………………………31
6.结束语………………………32
参考文献………………………33
致谢………………………错误!
未定义书签。
1.绪论
1.1研究背景
在目前运营的提供媒体资源的网站，诸如视频网站，图片网站，音乐网站和一些小说网站等等，都不能提供一个比较完整的多媒体平台，并且受版权影响，并不能呈现所有的媒体文件，有些文件损坏程度比较严重，有些文件本来就是非法转载而来，如果用于教学等其他非商业目的来讲，有些文件又存在水印，字幕不全，非法修改等误导消费者的部分。
为了解决在媒体资源之间的转换问题和在维护版权前提下的媒体资源分享问题，由本开发小组发起，准备建立一个新的多媒体网络资源管理系统。
在本小组提出基本的系统构想后，应项目的支持者的要求，本系统的设计构想基本定位在一个小范围的私人论坛试运营，之后再完善系统并进一步扩大规模。
而最终是希望建成一个具有独立的媒体资源编辑能力并集媒体资源的上传，下载，买卖，共享等为一体的综合性私人论坛。
这样作为一个一般用户，不必购买昂贵的软件就可以使用或者购买简易的多媒体相关功能和文件。
而对于在市面上并未出现过的多媒体内容，用户也可以在在线浏览之后决定是否购买（只能浏览指定的一部分，带有水印等，并且在浏览过程中不能进行录像和截图操作）。
对于版权问题，本站采取尊重原创作者的版权，不仅所有的媒体文件都会标明出处，对于没有版权的作者也会尽量保证他们的权益，对于拥有版权且不能公开转载的作者的作品，将通过协商的方式寻找合适的方式在本站使用他们的资源，有些一定要进行购买的，本站将采用统一的购货方式进行购买。
而购买所产生的费用，则通过用户浏览来承担，一部分付费的VIP用户采用月付费承担，剩下的普通用户和一些价格比较昂贵的将再进行单独标价付款后才可以观看。
在这些定价之中，网站本身不收取任何费用，所得的费用完全投入多媒体文件的购买。
而网站的运营费用则是由论坛内部共同承担，具体操作流程不在本系统的讨论范围之内。
经过大量的讨论和论坛内部将近半年时间的问卷调查，设计小组基本上了解了论坛成员对于网站的需求状况，经过总结后小组共同编写了需求说明书并在论坛上公示获得通过，本网站管理系统的设计工作正式启动，其中大部分的设计工作由本人完成，而具体实现则由小组成员分工完成。
1.2开发环境简介
1.2.1
SSH系统架构简介SSH架构是目前比较流行的web程序框架，由Struts2+Spring+Hibernate构成，在java开发中可谓是黄金组合，并且这些框架都是开源的框架，这样就大大降低了开发成本。
[1]
下面对该框架的内容进行必要的简介：
AStruts2
Struts2是在Struts1和Webwork的基础上进行了很大改进发展而来的，它以Webword为核心，抛弃了Struts1中的大部分内容，使得业务逻辑控制器和ServletAPI完全解耦。
主要负责业务逻辑的跳转，和MVC的分离。
系统中用Struts2架构完成的代码主要实现了各个模块的主要功能。
[2]
需要指出的是第一期网站使用的前台脚本语言是JSP，这主要是针对Struts2与JSP的兼容性好，但是JSP页面存在响应时间过缓的问题，所以在第二期开发过程之中，小组将前台脚本语言改为PHP开发，这样修改的原因是PHP与数据库mysql服务器兼容性好，而且响应速度也比JSP页面快。
B Spring
Spring旨在使用javaBean来完成以前只能由EJB完成的事情。
主要负责管理，将对象之间的依赖关系交由Spring进行控制。
[3]系统中的集成问题都是采用Spring框架制作。
C Hibernate
Hibernate是一个开放源代码的对象关系映射框架，它对JDBC进行了非常轻量级的对象封装，使得程序员可以随心所欲的使用对象编程思维来操纵数据库。
所以利用hibernate对持久层提供支持。
而鉴于hibernate是小组成员以前开发很少使用的部分，这次的开发过程在这里是一个挑战，在设计方面难免会有考虑不周的地方。
[4]
1.2.2Mysql数据库简介
之所以选择mysql数据库作为最开始使用的数据库服务器，是考虑到其本身体积并不大，对于初级开发者而言相对比较容易操作。
而且网站第二阶段的构想，前台的脚本将使用PHP作为脚本语言，选择mysql数据库可以更好地与脚本语言配合。
[5]对于第一期和第二期的开发工作，使用mysql作为数据库服务器的确给开发团队带来很大的便利。
但是随着开发工作的进行，特别是网站增加了在线编辑媒体文件的功能之后，mysql数据库服务器显然不能满足用户最终的需要，这使得小组在这一阶段之后不得不放弃简单易行的mysql数据库而改用较为复杂的oracle数据库。
而之所以在此列出，是因为在本篇论文完成之时，虽然第三阶段的设计工作已经基本完成，但是还没有在开发中实现，所以所看到的系统运行情况仍然停留在mysql数据库的实现阶段。
1.2.3Oracle数据库简介
本次开发的最终数据库服务器采用oracle11g进行开发，oracle数据库是目前世界上被采用最多的数据库管理系统。
采用oracle数据库服务器是鉴于它强大的数据处理能力和安全性能。
并且在数据库的备份和恢复方面，oracle数据库也拥有其他同类产品所不具有的优势。
1.
2.需求分析
2.1需求调研
本网站的开发目的是为了满足某论坛的功能扩展，所以在开发之前进行了详细的调研，以确定开发的产品是能够满足既定人员的所有需求的。
对于网站开发的成本和维护产生的费用，由该论坛承担。
本开发团队采取网络问卷的形式，对论坛的每一个用户都进行了调查根据反馈的结果，证实了团队之前的构想是可行和正确的。
2.2需求分析
根据问卷调查的内容，本小组总结出以下几条需求内容。
A注册：
除了要进行实名认证之外还要求是论坛的注册用户，并且通过论坛的授权才能进行成功注册。
注册时要签署网站的定制协议，违反协议将追究法律责任。
（有些用户表示这还是不够的，还要求登记该用户在各大论坛的用户名称，但是开发团队认为这样做有些画蛇添足）
B登陆：
在输入账户名和密码后如果登录失败，显示账户名称或者密码不正确，不仅要重新输入，而且要求重新进行论坛认证，这样做虽然繁琐，但是是防止盗号问题的一个有效的办法。
C找回密码：
找回密码不仅要进行论坛认证，还要求重新进行实名认证，如果与上次实名认证结果不一致，则该用户将被记入黑名单，不允许再次注册。
D用户的划分和来源：
论坛的管理用户将组成日常的管理员团队，论坛的高级用户有权注册认证成为开发者用户，论坛的合作伙伴有权注册为供货商用户，论坛的其他用户只能注册成为一般用户。
允许开发者用户和管理员同时成为一般用户。
论坛的经理用户为论坛的版主，只有一个经理用户，不能多次注册经理用户。
用户的划分由管理员在注册的认证阶段实现，管理员有权更改用户的权限。
E游客权限：
未经注册和登陆的游客，不能访问本站，不能浏览任何本站提供的资源。
本站的登陆界面视为本站对外开放的界面，本站的主界面只对注册用户开放。
F在线的直播功能：
对于某些特殊的资源，只提供特定时间的在线浏览。
G定制资源功能：
本站提供的定制资源平台是为了某些创意资源拥有自己和版权，从而维护创作者的权益，而这些资源的使用权限完全由创作者决定。
H媒体资源的种类：
本站支持主流的视频、音频、图片和文本文件格式，并且还提供少量的其他资源如操作系统主题、输入法皮肤等。
2.3系统功能分析图
图2-1系统功能分析图
3.总体设计
3.1系统结构图
图3-1系统机构图
3.2总体功能设计
A根据用户划分的内容：
a用户：
第一期：
媒体资源的在线浏览和评论；部分媒体资源的上传和下载。
第二期：
用户划分为普通用户和VIP用户；可以通过网上银行付费成为VIP用户，浏览和下载更多媒体资源；用户账户管理。
第三期：
用户和VIP用户的等级划分，通过登陆的天数获得不同的积分，达到一定积分就可以升级用户，等级越高的用户会获得更高的用户权限；自定义的定制资源购买和在线的资源编辑；用户个性化设置。
b开发者：
第二期：
媒体资源的更新和网站的日常维护。
第三期：
用户自定义定制资源的接收和提交；开发者账户管理。
c供货商：
第二期：
媒体资源的更新和定价；供货商账户管理。
第三期：
用户自定义定制资源的接收和提交；供货商等级的划分，等级越高的用户能够获得更高的价格，并在定制资源和购买资源时被优先考虑。
d管理员：
第一期：
用户管理；媒体资源管理；评论管理。
第二期：
供货商管理；开发者管理；财务管理。
第三期：
在线直播管理；管理员权限划分；经理用户，经理用户中的管理员管理对管理员进行授权和删除等操作。
B根据模块划分：
a媒体资源模块：
媒体资源的浏览权限、制作、上传、下载、标价、买卖、搜索、评论、基本信息修改。
b用户模块：
用户的注册、登陆、删除、授权、查询、信息浏览。
c财务模块：
网站收支状况查询，用户、供货商、开发者的收支状况查询。
d定制资源模块：
媒体资源的定制、在线直播、网站的界面管理、排行榜管理。
3.3系统E-R图[6]
图3-2系统E-R之一
图3-3系统E-R图之二
3.4数据字典
在此有必要将某些数据表的设计过程和思想简单列出：
3.4.1用户信息表
用户信息表的主要存储内容有两个：
A在网站第一次注册的未经批准的用户，其是否通过认证选项为未通过，与此同时，以下列出的5、6、7三项则不会由系统自动生成。
B已经被网站批准的认证用户，其中的5、6、7三项会由系统自动生成。
这样设计的虽然在操作方面有些复杂，但是主要考虑了以下两点：
A使用一张表大大的节省了存储空间和操作程序，如果使用两张表存储未经认证的用户和已经认证的用户，两张表之间需要转换过程，而且需要大量的删除和插入操作，而这两项操作通常会同时发生，不仅容易出错，还占用了大量的网站资源。
而同时，使用本站的用户根据目前的规模最多只有一千人，同时进行注册的人数不会超过一百人，因此不会产生操作阻塞的情况。
B出于对于以上第一点的发展，这样做也可以节约网站的开发成本。
并且在用户被删除之后，将会进入黑名单，用户信息会被保留，防止用户再次注册。
这样使得在用户的注册和登陆过程中，主要操作都集中在一张表之内完成。
表3-1用户信息表
3.4.2用户权限表
出于对用户权限的划分建立的用户权限表，只是为了方便不同用户登录后所匹配的不同服务项目所使用的，在表建立之后内容就不能更改、添加和删除。
表3-2用户权限表
3.4.3媒体资源信息表
这里列出的是媒体资源的存储信息，而对于媒体资源的详细信息，例如作者、国籍、类型等等则是有一个媒体资源详情表可以查询的。
因为这个表除了在用户搜索中使用，需要管理员及时更新之外，没有其他用途，并且在网站的设计方面，也不是一个主要内容但会占用大量的篇幅，所以并不在文中列出此表。
如同上文所述的用户详情表也并未在此列出也是出于同样原因。
对于下表所示的资源权限一栏，所填的选项包括：
表3-3媒体资源信息表
3.4.4用户账户信息表
用户账户信息表是由于与用户的基本信息存在于不同的模块之内并且不处于同一个开发周期内而被单独列出的。
在进行财务交易的情况下无需访问用户基本信息表，操作起来更为简便。
表3-4用户账户信息表
3.4.5账户交易信息表
交易信息采用的存储和查询的方式基本上和下面的评论是相同的，在这里需要解释其中的交易类型字段，其中填写的信息是几个固定的字段：
卖出、买进、租出、租进、VIP月费、工资、网站维护、虚拟交易。
表3-5账户交易信息表
3.4.6媒体资源评论表
表3-6媒体资源评论表
4.设计思想与实现思路
由于本人在小组中主要担任需求调研、设计和测试方面的工作，除了Struts2编写的部分java脚本和前期jsp页面之外，没有更多参与编程工作。
4.1用户注册登陆模块
关于用户的注册问题，小组和论坛用户经过了很长时间的讨论，总结出了几套方案：
A方案一：
采用实名注册，在浏览媒体文件的时候提出申请，在申请获得批准后才能进行浏览。
显然这种方案使得管理员工作大量增加，而且用户也无法获得足够的正常响应。
如果每个用户浏览资源时都要经过讨论而获得相应或大或小的权限，会造成实现上极度的繁杂，而且容易发生不可预知的错误，在设计方面也有相当的难度。
B方案二：
不采用实名注册，只是在浏览特定资源的情况下采用购买的方式。
通过论证，如果不进行必要的实名注册，就不能判断浏览者是否为可信任用户，从而使得版权等问题无法保障。
而采用购买方式并不能本质上解决这方面的问题。
C方案三：
实名认证用户注册认证方式采用类似验证码的方式，采用问题认证，由系统本身决定认证内容。
经过论证这种认证方式存在缺陷，仍然有可能有非论坛用户进入本站，造成信息等的泄露。
并且类似验证码的方式极其容易被破解，实现起来也不十分容易，如果要经常更换验证的内容则需要大量的人力。
根据以上的方案，研发小组和论坛管理团队商定的最后方案是：
采用实名认证方式注册，认证由论坛内部决定内容，并通过网站通过，本站并不涉及认证信息的任何内容，所有的申请都由后台管理员手动操作，并且在注册的同时，用户需要签署本站的公约，公约的内容是由论坛成员共同制定的。
但是从网站设计角度来讲，要求管理员手动批准申请的方式仍然是一个十分原始的操作手段，在设计中要尽量避免使用，因为如果申请人数太多也会造成人力上极大的投入。
但是考虑到网站使用的小众性以及上述所讲的各项原因，开发小组认为采用这种比较原始的手段仍然是十分必要和可行的。
但是开发小组仍然认为这并不是一个最终的解决方案，在以后的维护过程中，还会逐步探索真正能够用程序获得程式化的解决方式。
而关于身份证认证的问题，本站采用统一购买的接口进行连接，在实现上不属于小组内部的设计内容。
在实现方面，在注册页面用户输入的信息通过Action类中的get方法获取用户输入的值，该值先通过jsp页面的javaScript在数据收集时进行初步校验，然后在registerAction的相同目录下创建输入校验文件registerAction-validation.xml，构成服务器校验。
这里选择的校验器是内建校验器。
在邮箱部分使用邮件地址校验器，在身份证部分暂时采用自定义的身份证校验器。
在姓名方面，自定义了姓氏的字段进行自定义校验。
对于以上各项信息统一都需要采用字符长度校验器。
使用验证器Annotation指定必填校验规则：
@RequiredStringValidator（type=ValidatorType.FIELD,
key="register.requried",message=""）
以上注册内容如果校验失败则输出login.requried注册失败校验内容。
由于注册中只有一项用户请求，当点击注册时，系统调用Action类中的excute（）方法进行表单的提交和处理。
客户端校验并不是注册验证的全部内容。
当客户端输入的信息通过上述校验之后，用户信息将被写入用户信息表中。
管理员在客户端收到注册信息之后逐一对注册者的姓名和验证信息进行比对，在此开发小组称这项工作为人工校验。
当通过最后这道校验之后，管理员点击授权后用户对应的角色，系统自动匹配授权编号并发送给数据库，自动生成该用户的权限编号和用户等级、账户编号，是否通过认证数据项由false修改为true，生成是否为黑名单数据项为false。
于此同时，用户账户建立，系统自动生成账户余额数据项为0。
至此，完成用户注册的各项步骤。
图4-1注册用户验证逻辑示意图
图4-2注册界面截图
关于登陆，用户通过注册之后会收到邮件，在此之后，用户就可以通过注册的用户名和密码访问本站。
登陆时输入的信息也存在客户端校验和服务器校验两个部分，在登陆时将调用相同的校验器进行校验。
在登陆页面，用户输入信息后点击登录由Action类中的excute（）方法进行处理，而点击注册则由在客户端由login.jsp直接跳转至register.jsp进行处理。
在登陆之后设置自定义拦截器获取用户的权限信息来调用不同的jsp页面进行用户服务。
图4-3用户登陆逻辑示意图
关于密码的找回和输入三次错误密码，设计要求将重新进入认证阶段，如果发生与前次实名注册不一致和认证无法通过，这个用户将被加入黑名单，不允许再次访问本站。
而在登陆界面，并不存在找回密码的按钮，用户找回密码的操作同输入三次错误密码的操作一样，遵循重新认证。
关于输入三次错误密码返回注册页面，开发团队认为单单使用计数器是不够的，为此专门在用户信息表增加输入错误密码次数数据项，这一项信息在注册之后自动生成值为0，每当用户输入一次错误密码，loginAction将会拦截这次请求并使该数据项值增加1，当loginAction捕捉到该数据项值为3时，则会调用restartAc
升级会员 