程序设计实训报告模板.docx
《程序设计实训报告模板.docx》由会员分享，可在线阅读，更多相关《程序设计实训报告模板.docx（68页珍藏版）》请在冰豆网上搜索。
程序设计实训报告模板
毕业实习报告
（2010-2011-2）
题目
网络相册管理系统
学院
计算机学院
专业
软件工程
分组
为分组设计名称
学号
06057136（组内所有同学的学号）
学生姓名
邬奇辉（与学号相对应的姓名）
指导教师
游新冬
完成日期
2010年9月
1引言
相册在很早以前就有了，但是原来的相册是以纸质照片的形式的存在的，它使用人工方式进行管理，工作量大。
而且相册还存在不易保管，不方便携带，容易丢失，翻看不方便，占用空间等等问题。
后来随着时代的发展，科技的进步，摄影技术的发展，旅游业的进步，照片数量急速增加，使用传统的方式来管理照片显然力不从心，而个人电脑的发展，照片数码化，加速了电子相册的产生与进步，电子相册解决了传统相册不易保管，不方便携带，容易丢失，翻看不方便，占用空间等等问题。
而由于网络技术的发展，网络已经渐渐的大众化。
在网络冲印也已实现的今天[1]，人们对于电子相册的需求也不再局限于保管相片那么简单。
人们更希望把自己的照片同好友分享，希望照片更方便于携带，方便于搜索和查阅。
而近年来，随着各式网络社区的出现，web2.0概念的普及，为了提高网站的知名度，用户的黏度，迫使社区类网站不断改进扩充自己的功能。
而出于用户对电子相册分享的需要，使得网络相册能和网络社区极好的结合，也使其成为网络社区中一个不可或缺的组成部分[2]。
甚至还有一些社区模式的网站直接把网络相册作为其唯一的主体功能。
其中比较国外比较著名的有Picasa、Flickr等，而国内比较著名的有巴巴变、又拍等[3]。
有调查表明，2006年美国网络相册用户数量达到6500万，预计在未来几年网络相册用户数会继续保持平稳增长。
在2005年网络相册用户数占美国网民总数的29%。
2006年中国活跃网络相册账号约2500万个，预计未来四年会保持较高速度增长，年新增活跃账号在1000万左右[4]。
可见，网络相册作为一项基础互联网应用，正在随着网络环境的日益成熟以及用户需求的持续增长而得到快速发展。
而以交互分享为核心的网络相册2.0理念也成为产品功能改善和用户体验提升的重要标志。
而本课题就是在这样的前提下提出的，由于网络相册用户的大量增加，制作一款以web2.0概念为出发点，以良好的用户体验为基础，为用户提供一个以存储、分享照片为核心，结合了社区模式的平台，而且又兼具一些与众不同的功能的网络相册管理系统，来满足用户的需要，就显得十分必要，也十分具有现实意义和价值了。
2相关技术简介
本系统是基于J2EE平台开发的，实现过程中Hibernate、Spring、Struts、DWR框架和Applet技术，本章将简要介绍这些技术，框架的特点，以及其在本系统环节中所起的作用。
2.1J2EE开发平台概述
J2EE（Java2Platform,EnterpriseEdition）是一种用来开发分布式企业软件应用系统的平台[5]，其核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容，导致企业内部或外部难以互通的窘境。
它提供了一个多层次的分布式应用模型和一系列开发技术规范。
多层次分布式应用模型是指根据功能把应用逻辑分成多个层次，每个层次支持相应的服务器和组件，组件在分布式服务器的组件容器中运行，如Servlet组件在Servlet容器上运行，EJB（EnterpriseJavaBeans）组件在EJB容器上运行，容器间通过相关的协议进行通讯，实现组件间的相互调用。
遵从这个规范的开发者将得到行业的广泛支持，使企业级应用的开发变得简单、快速。
2.1Hibernate框架概述
2.2.1什么是ORM
ORM（Object/RelationMapping，对象-关系映射）是一种为了解决面向对象与关系数据库存在的互不匹配的现象的技术，可以减少重复的数据访问层的代码，减少系统的耦合，便于维护。
ORM是随着面向对象的软件开发方法发展而产生的。
面向对象的开发方法中对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。
ORM系统一般以中间件的形式存在，主要实现程序对象到关系数据库数据的映射。
2.2.2Hibernate框架介绍
Hibernate框架是一个数据持久层框架，是一种实现ORM的工具，它对JDBC（JavaDataBaseConnectivity，Java数据库连接）进行了轻量级的对象封装，使程序员可以使用对象编程思想来操作数据库。
Hibernate框架用XML（ExtensibleMarkupLanguage,可扩展标记语言）配置文件的形式来定义Java对象和数据表之间的映射关系，透明的提供对象与关系数据库的映射，以统一的接口方式支持多种数据库。
Hibernate对JDBC的优秀封装，通过使用HQL（HibernateQueryLanguage，Hibernate查询语言）完成Java对象和关系型数据库之间的转换[6]，在很大程度上简化了对数据的查询，加快了开发的效率。
而且Hibernate中提供了一个简单而直观的API（ApplicationProgrammingInterface，应用程序编程接口），用于对数据库所表示的对象执行查询。
避免了访问数据库时大量代码的出现。
使得开发人员可以从通常的数据持久化编程事务解放出来。
虽然Hibernate有诸多好处，但是Hibernate的劣势也是很明显的，只提供模型层的支持，但是却无法实现业务流程控制，这也使得系统不能单一的基于Hibernate框架开发。
故而，系统选择Hibernate这个成熟的ORM框架进行持久层开发，实现对象与数据库关系之间的交互，而在其他层次使用其他框架与之整合。
2.3Spring框架概述
2.3.1IoC和AOP
IoC（InversionofControl，控制反转）又称为DI（DependenceInjection，依赖注入）。
IoC的基本概念是：
不创建对象，但是描述创建它们的方式。
在代码中不直接与对象和服务连接，但在配置文件中描述哪一个组件需要哪一项服务。
容器负责将这些联系在一起。
其原理是基于OO设计原则的TheHollywoodPrinciple:
Don'tcallus,we'llcallyou（好莱坞理论：
别找我，我会来找你的）。
也就是说，所有的组件都是被动的，所有的组件初始化和调用都由容器负责。
组件处在一个容器当中，由容器负责管理。
AOP（AspectOrientedProgramming，面向方面的编程），可以说是OOP（Object-OrientedPrograming，面向对象编程）的补充和完善[7]。
OOP允许你定义从上到下的关系，但并不适合定义从左到右的关系。
而AOP技术则恰恰相反，它利用一种称为“横切”的技术，剖解开封装的对象内部，并将那些影响了多个类的公共行为封装到一个可重用模块。
简单地说，就是将那些与业务无关，却为业务模块所共同调用的逻辑或责任封装起来，便于减少系统的重复代码，降低模块间的耦合度，并有利于未来的可操作性和可维护性。
AOP把软件系统分为两个部分：
核心关注点和横切关注点。
业务处理的主要流程是核心关注点，与之关系不大的部分是横切关注点。
横切关注点的一个特点是，他们经常发生在核心关注点的多处，而各处都基本相似。
AOP的作用在于分离系统中的各种关注点，将核心关注点和横切关注点分离开来。
正如Avanade公司的高级方案构架师AdamMagee所说，AOP的核心思想就是“将应用程序中的商业逻辑同对其提供支持的通用服务进行分离。
”
2.3.2Spring框架介绍
Spring是一个开源框架，它由RodJohnson创建。
它是为了解决企业应用开发的复杂性而创建的。
Spring是一个轻量级的IoC和AOP的容器框架[8]。
Spring的核心就是它的轻量级IoC容器的功能。
通过Spring提供的IoC容器，可以将对象之间的依赖关系交由Spring进行控制，避免硬编码所造成的过度耦合。
Spring使开发人员不必再为属性文件解析等一些很底层的需求编写代码。
Spring提供了面向切面编程的丰富支持，把应用的业务逻辑与系统级服务（例如审计和事务管理）进行分离，使得应用对象只需要实现它们应该做的——完成业务逻辑——仅此而已。
它们并不负责（甚至是意识）其它的系统级关注点，例如日志或事务支持。
虽然Spring是一个优秀的松散耦合框架，而且Spring提供了对各种优秀框架的良好支持，但是在MVC（Model-View-Controller，模型—视图—控制器）模式上，却并未被广泛使用，参考文献也较少，不利于开发。
故而，系统利用Spring良好的AOP和对Hibernate的支持，负责Hibernate的事务代理；利用对IoC支持，为各层提供依赖注入，松散耦合。
而把MVC功能交给其他框架，已达到更快的开发效率和更高的软件质量。
2.4Struts框架概述
2.4.1MVC模式
MVC设计模式把一个应用流程划分成模型层、视图层、控制层这么三个层。
每个层次执行各自的职责。
视图（View）层：
该层是与用户交互的界面，仅负责视图上数据的采集和处理，以及接受用户的请求，而不包括在视图上的业务流程的处理。
业务流程的处理交予模型（Model）处理。
模型（Model）层：
该层负责业务流程/状态的处理以及业务规则的制定。
业务模型的设计可以说是MVC最主要的核心。
模型接受视图请求的数据，并返回最终的处理结果。
控制器（Controller）：
该层负责从用户接收请求，将模型与视图匹配在一起，共同完成用户的请求。
但是控制层并不做任何的数据处理。
2.4.2Struts框架介绍
Struts是Apache软件组织负责开发的一个开源框架[9]，实质上就是在JSP的基础上实现的一个MVC框架。
模型由实现业务逻辑的JavaBean或者EJB组件构成，从而与界面相独立。
控制器由ActionServlet和Action来实现，用于处理用户与软件的交互操作，控制模型和视图之间的数据传递，更新模型状态。
视图由一组JSP文件构成，视图还用于捕获用户所传递的数据，通过控制器传递给模型。
Struts是一款成熟的面向MVC建模的框架，可以把显示层同业务逻辑完全独立开来，使业务逻辑开发人员同显示层开发人员可以并行开发，加快开发速度。
然而Struts框架的劣势也是极为明显的，由于没有对业务逻辑层提供很好的支持，如数据库的事务操作等等。
所以单独使用Struts情况下，使得对于业务逻辑的开发较为复杂。
结合Struts的优缺点，系统提出了利用Struts成熟的MVC架构提供业务的流程控制的方案。
2.5DWR框架概述
2.5.1Ajax技术
在传统的Web应用通过提交表单时就向Web服务器发送一个请求。
服务器接收并处理表单，然后送回一个新的网页，由于前后两个页面中的大部分HTML码往往是相同的，而且应用的回应时间取决于服务器的回应时间，这就会使用户得到回应的速度较慢。
与此不同，Ajax（AsynchronousJavaScriptandXML，异步JavaScript和XML），仅向服务器发送并取回必需的数据，并在客户端采用JavaScript处理来自服务器的回应。
这使得服务器和浏览器之间交换的数据大量减少，而且很多的处理工作可以在发出请求的客户端机器上完成，所以Web服务器的处理时间也减少了，这样就使用户得到回应的时间大大缩短，提高了用户体验。
2.5.2DWR框架简介
DWR（DirectWebRemoting）是J2EE领域的Ajax框架，通过DWR的帮助，可以帮助开发者更简单地开发出Ajax应用[10]。
DWR采取了一个类似Ajax的新方法来动态生成基于Java类的JavaScript代码。
这样WEB开发人员就可以在JavaScript里使用Java代码；但是Java代码运行在Web服务器端而且可以自由访问WEB服务器的资源。
出于安全的理由，Web开发者必须适当地配置哪些Java类可以安全的被外部使用。
DWR把Ajax的异步特性和正常Java方法调用的同步特性相结合。
在异步模式下，结果数据在开始调用之后的一段时间之后才可以被异步访问获取到。
DWR允许Web开发人员传递一个回调函数，来异步处理Java函数调用过程。
正是这些原因使得基于DWR的脚本开发人员需要对Java开发有一定了解，或者需要熟悉业务逻辑层所暴露的函数及相关参数。
故而，系统在表现层使用DWR框架对Ajax技术提供支持，增强用户体验。
2.6Applet技术概述
JavaApplet即Java小应用程序，使用JavaApplet可以轻易设计出漂亮且有强大动态特性的网页，使设计的网页充满生气[11]。
故而系统使用Applet来实现系统的在线相片编辑这个插件。
2.6.1Applet的工作原理
当支持Java的浏览器遇到Applet的标记时，就将下载相应的Applet代码并在本地计算机上执行该Applet。
Applet的下载的时间则取决于Applet的大小和用户的网络连接的速度。
下载完后，便和本地计算机上的程序以相同的速度运行了。
Applet在用户的计算机上执行时，还可以下载其它的资源，而且还允许用户进行交互式操作。
故而在基于Internet的应用程序开发中发挥着重要的作用[12]。
2.6.2Applet的安全机制
由于Applet是需要通过网络传播，并要在被访问者的机器上执行，所以一定要对Applet的执行加以限制。
Java中提供了沙箱（sandbox）安全模式。
在这种安全模式下，Applet不能在运行中调用其他程序，不能对文件进行读写操作，不能装载动态链接库或调用本地方法，也不能试图打开非提供Applet的主机以外的某个Socket。
Applet只能和原来的Web服务器进行数据交换，而无法将数据传送到其他计算机。
有了这些严格的保护措施，可以将用户面临的安全性风险降到最低。
3系统需求及概要设计
本章主要根据需求分析的结果对系统的总体功能进行设计，对模块进行划分，并对各个模块以及他们之间的关系进行概述，并详细说明了各个模块的UC（UseCase，用例），并为了更好地提升系统性能，进行了架构方案的设计。
最后设计了能够完成系统所有功能所需的数据库。
3.1系统需求概要
3.1.1什么是Web2.0
Web2.0是以人为核心的，通过鼓励用户提供内容，鼓励用户交互而产生数据。
并根据用户所产生的这些数据，组织网络内容，提供相关的服务，给用户创造新的价值，给整个互联网产生新的价值。
在Web2.0里每个用户都是信息的提供者和受益者。
3.1.2系统需求描述
本相册管理系统是在Web2.0的概念下提出的，为用户提供一个开放的交互平台。
这个交互平台以网络相册为主体，通过用户上传相册产生主体数据；而通过好友、评论等功能实现用户之间的交互，从而在用户间形成社会网络，通过社会网络加强系统用户交互，提高系统用户黏度。
系统需要向用户提供简单，方便的操作界面，提高用户的可操作性，降低用户的使用难度；系统还需要向用户提供良好的界面表现效果，以提高用户体验，提高系统的用户黏度。
系统还应当向用户提供简单的图片修改插件，方便用户对相片的修改。
这类方便易用的小插件也是提高用户黏度的一个重要组成部分。
在现在多种浏览器并行的今天，跨浏览器也是系统需求中必不可少的一条。
对于一个Web2.0的系统，如果无法解决这点，将大大影响用户体验。
3.2系统模块细分
根据上述的系统需求，最终把该系统划分成用户注册/登陆模块，用户信息管理模块，用户相册管理模块，用户图片管理模块，用户评论管理模块，用户好分类友管理模块，用户好友管理模块，用户分享管理模块，用户站内信管理模块，用户留言管理模块，用户搜索模块，排行榜模块，这么几个主要功能模块，并各自向用户提供简单有效的功能及服务。
在此将具体介绍各自的功能用例。
系统整体的功能结构（如图3-1）：
图3-1系统功能模块图
3.2.1用户注册/登陆模块
通过该模块用户可以方便的进出本系统。
该模块主要提供的服务有注册、登陆、密码找回、登出，升级成VIP服务。
具体UC图（如图3-2）：
图3-2用户注册/登陆模块UC图
3.2.2用户信息管理模块
通过该模块用户可以方便的查看所有用户的个人信息。
还可以通过该模块上传头像、修改基本信息等方式修改个人信息。
具体UC图（如图3-3）：
图3-3用户信息管理模块UC图
3.2.3用户相册管理模块
通过该模块用户可以方便的浏览权限许可范围内的用户相册，并且可以方便的管理个人的相册。
该模块主要提供的服务有相册创建、相册信息修改、相册查看、相册删除。
具体UC图（如图3-4）：
图3-4用户相册管理模块UC图
3.2.4用户相片管理模块
通过该模块用户可以方便的浏览权限许可范围内的用户相片，并且可以方便的管理个人的相片。
该模块主要提供的服务有相片上传、相片信息修改、相片查看、相片在线编辑、相片删除、相片设为封面、相片批量移动。
具体UC图（如图3-5）：
图3-5用户相片管理模块UC图
3.2.5用户评论管理模块
通过该模块用户可以方便的进行对评论的管理操作。
该模块主要提供的服务有评论发表、评论回复、评论删除。
具体UC图（如图3-6）：
图3-6用户评论管理模块UC图
3.2.6用户好友分类管理模块
通过该模块用户可以方便的进行对好友分类的管理操作。
该模块主要提供的服务有好友分类添加、好友分类修改、好友分类删除。
具体UC图（如图3-7）：
图3-7用户好友分类管理模块UC图
3.2.7用户好友管理模块
通过该模块用户可以方便的浏览用户的好友，并进行对个人好友的管理操作。
该模块主要提供的服务有好友的查看、好友申请好友申请通知、接受或拒绝申请、好友的移动、好友关系的解除。
具体UC图（如图3-8）：
图3-8用户好友管理模块UC图
3.2.8用户分享管理模块
通过该模块用户可以方便的浏览用户分享的相册，并进行对分享的管理操作。
该模块主要提供的服务有好友分享查看、分享添加、分享删除。
具体UC图（如图3-9）：
图3-9用户分享管理模块UC图
3.2.9用户站内信模块
通过该模块用户可以方便的对站内信进行管理操作。
该模块主要提供的服务有查看、未读已收信件通知、未读已收信件查看、已读已收信件、阅读信息、删除信息、彻底删除信息、发送站内信。
具体UC图（如图3-10）：
图3-10用户站内信管理模块UC图
3.2.10用户留言管理模块
通过该模块用户可以方便的浏览用户的留言，并进行留言的管理操作。
该模块主要提供的服务有留言发表、留言回复、留言删除。
具体UC图（如图3-11）：
图3-11用户留言管理模块UC图
3.2.11用户搜索模块
通过该模块用户可以方便的搜索符合条件的用户和相册。
该模块主要提供的服务有用户搜索、相册搜索。
具体UC图（如图3-12）：
图3-12用户搜索模块UC图
3.2.12排行榜模块
通过该模块用户可以方便的浏览系统的实时排行榜。
该模块主要提供的服务有最热门相册排行榜、最新相册排行榜。
具体UC图（如图3-13）：
图3-13排行榜模块UC图
3.3系统架构设计
为了提高系统的可扩展性，可复用性，可维护性，提升系统稳定性，系统采用了如下的架构设计。
3.3.1系统层次划分
根据软件工程中“高内聚，低耦合”这个软件设计的核心思想[13]，把系统拆分成如下的层次，以降低系统层与层之间的耦合，防止系统把某一层的变化扩散到系统的其他层次，便于修改和维护。
而且采用分层还可以提高系统各层逻辑的复用的。
1、数据访问层。
在这一层中包含了实体（entity）类和数据访问对象（DAO）类（接口）。
其中实体类是系统ORM映射形成的映射类，做为一种数据封装的模型存在于系统中。
而数据访问对象类（接口）是系统访问数据库的接口，执行对数据库记录的CRUD（Create、Read、Update、Delete）操作，并把结果（一般是Read操作返回的记录）封装成对应的对象返回
2、业务逻辑层。
这一层是系统的核心部分，封装了系统的业务逻辑，所有的业务逻辑操作都在这一层完成。
这一层通过调用数据访问层的接口，执行业务逻辑操作，并把结果返回给调用者。
这一层通过Spring封装后的数据库事务机制支持，使数据的操作可靠。
3、控制器层。
这一层负责用户请求的转发，协调业务逻辑层和视图层的工作。
这一层由Struts框架的Action组成，主要负责一些前期的权限验证工作，传递视图层传入的数据给业务逻辑层接口，并把业务逻辑层接口的数据返回给显示层。
4、视图层。
这一层负责把数据展示给用户。
主要有JSP和Struts框架的ActionForm组件构成。
通过加入一些CSS、JavaScript等页面组成元素丰富用户体验，提升页面效果。
3.3.2系统服务器部署架构
基于对系统应用的可扩展性，分担系统压力，均衡用户请求的负载，支撑更高的用户访问量考虑。
根据服务器承担任务的不同，将系统划分成4个服务器，各自承担不同的任务。
而且服务器的域名是可配置式的，减少了代码对于服务器地址的依赖。
1、应用主服务器。
主服务器是系统的核心服务器，处理用户发往系统的所有请求（包括图片上传的请求），并根据用户要求访问其他服务器，与其他服务器交换数据。
主服务器专注于系统业务的处理，尽可能快速的响应用户的请求，而把业务无关性操作分发至其他服务器（数据库服务器、图片上传服务器）。
2、数据库服务器。
响应主服务器的数据访问请求。
将数据库从主服务器分离是为了消除主服务器和数据库服务器的相互影响，减轻主服务器的负担。
支撑更高的访问流量。
3、静态文件服务器。
静态文件服务器，主要存储CSS，JavaScript，系统图片等静态文件。
由于主服务器承担了所有的用户访问请求，压力较大，如果再让其承担浏览器发送的获取静态文件请求将大大加重主服务器负担。
因而分离出静态文件服务器以减轻主服务器的负载。
4、图片上传服务器。
主要用于接收主服务器或者Applet发送的图片数据流、并进行压缩、存储。
响应浏览器和Applet读取图片文件的请求。
分离此服务器的作用显而易见，图片的压缩与I/O是一件非常占用系统资源的工作，而让主服务器在响应用户请求的同时承担这项工作是极不合理的。
而在当前这种高速的带宽下，相对于图片的压缩运算与I/O，主服务器与文件间的数据传输的消耗也就显得微不足道了，故而分离此服务器是切实可行的。
具体的系统架构图（如图3-14）：
图3-14系统架构图
3.4系统数据库设计
3.4.1系统E-R图
系统的E-R图（如图3-15）：
图3-15系统简化E-R图
3.4.2系统表结构
这个章节列举了系统的表结构（如表3-1至表3-10）。
表3-1用户表（GAZE_USER）
字段名
数据类型
描述
USER_ID
NUMBER（20）
用户ID
USER_NAME
VARCAHR2（20）
用户名
PASSWORD
VARCAHR2（32）
经MD5加密后的用户密码
QUESTION
VARCAHR2（50）
用户安全性提示问题
ANSWER
VARCAHR2（50）
用户安全性提示问题答案
STATE
CAHR
（1）
用户状态
升级会员 