二手交易平台设计与开发毕业论文.doc

二手交易平台设计与开发毕业论文目 录目 录III第1章引言11.1选题背景与问题概述11.2研究的意义及重要性11.3研究的内容和主要工作21.4论文组织结构3第2章需求分析42.1业务需求42.2功能需求92.3数据需求142.4非功能需求17第3章系统设计183.1总体设计183.2数据库设计343.3系统实现39第4章总结与展望474.1总结474.2进一步的工作48附 录I系统的源码I框架官方地址I参考文献49致 谢IILI第1章 引言1.1 选题背景与问题概述1.1.1 选题背景本课题“二手交易平台的设计与开发”是电子商务平台开发的一个典型代表。在国内，基于web的“二手货”交易系统是近年来倍受用户青睐的一种交易方式，它不仅促进电子商务在各行各业中的进一步推广，提高商品的利用率，更是给卖家和买家提供了有用即时的信息，给双方带来真正的实惠和经济效益。1.1.2 问题概述大多数的毕业生在大学毕业的时会留下许多物品，而大多数的学生是很乐意变卖自己这些东西的。但是由于缺乏一个交易场所或中介交易，很多人将这些东西当垃圾处理，没有发挥其可再利用价值。另一方面，低年级的同学则是希望购买到物美价廉的商品却无从获知此类信息。此外，当代人的消费观念及消费心理也随着时代的改变而不断在改变，目前主要趋于实惠、经济和多样化发展。网上购物和二手交易支持的人也越来越多，大多数在校大学生都有过从他人那里购买或出售使用过的诸如教材书之类的二手物品的经历。1.2 研究的意义及重要性1.2.1 研究的意义从前景来看，在国家大力提倡“建设节约型社会”的背景下，二手交易领域也是大有发展前途。比如学生的书本，自行车，体育用具等闲置东西可能通过交易，在需要的人手上循环再用，自己又能换取些别的东西或是金钱，可谓一举两得。1.2.2 研究的重要性信息实用，学生可以在二手网站上方便地提供各种与学习和生活的信息，如二手书籍，台式机，笔记本，饮水机和电磁炉等。这些都可以在大学生活结束时，变卖给低年级同学。其中旧自行车在新生中还是相当抢手，而高年级就很少用了，很多都摆在停车点生锈，给人可惜，放着又会坏掉，最后居然批量地给保安按去了。而且大学校园面积不小， 跑来跑去费时又辛苦，有时偶尔上街，外出游玩等。至于买新的，价格高，还容易丢，所以还是“二手”的好。在学期开始，很多学生也可以先到网站上搜寻与课程要求相同的教材，而不用去买新书，这在大二以上的年级还是很普通的。如英语教材，新书40 元左右，而二手书仅10元。况且，在旧书中还有高年级的笔记，更加实用。网站还可以由卖家出售其它各类商品：MP3、电脑配件、台灯、衣架、体育器材等。此外还能培养学生的经营意识。过去一到期末，或临近毕业，书籍、生活用品几本上都成废品，很便宜的卖给收废品的或是直接扔掉或送人。而现在，学生可以将这些物品信息挂在校园二手网站，以便学生之间双向选择，创造一定的经济价值。有的学生还可以对这些信息和物品进行收集和整理，再进行经营，体验下做“老板”的感觉。1.3 研究的内容和主要工作1.3.1 研究的内容l 学习并掌握基本的二手交易网站的原理和设计方法；l 学习Web开发的工具和语言：包括JAVA，HTML，CSS，JavaScript等前台语言和JSP服务器端开发语言；l 整合SSH2(Struts2，Spring3，Hibernate3)框架，熟悉其框架下MVC模式应用开发的流程和过程；l 在项目中加入和常用的Java组件：如Ant自动化，JUnit进行单元测试，Log4J进行日志控制8等；1.3.2 本人主要工作l 搭建开发平台，下载并安装jdk，tomcat服务器和eclipse开发工具，建立SVN服务器进行项目的版本控制，为后面开发做好基本的准备；l 用UML对系统进行建模，分析需求，系统分析和设计，设计出类的基本功能；l 编码。系统整体了采用MVC设计模式：其中使用hibernate3进行类和关系的映射，解决重复烦琐的数据库编程；spring3进行对象管理，通过依赖注入来减少各模块的依赖；struts2则充当控制角色，实现各WEB请求对应的处理和JSP页面的选择；l 采用Junit4进行单元测试和部分集成测试，Log4j日志记录，用于及时发现错误和系统设计的不足和多余，完善设计，利于迭代开发；l 进行系统的部署、运行和功能测试，其中完成了一些基本的系统功能：商品的上传、显示、搜索、加入购物车和下订单功能，用户的登陆、注册、修改功能，管理员的日志浏览功能。1.4 论文组织结构本文由以下几章内容组成：第1章介绍本文的研究背景，概述了所要解决的问题，并讨论项目的研究意义与重要性，阐述了论文的主要内容以及本人完成的主要工作。第2章是本文的核心内容之一，针对系统的业务需求、功能需求、数据需求和非功能需求等进行了详细分析，给出了主要的业务流程图和用例图，并对核心用例进行了详细描述，同时进行了基础数据的概念设计。第3章是本文的重点，在进行了系统总体设计的基础上，采用UML的包图、类图、顺序图和活动图11等对系统的子模块进行了功能性详细设计，并给出了主要功能的界面设计，同时通过实体类图、E-R图和数据字典对数据库进行了详细设计。第4章总结了本文所做的工作，同时对进一步的工作进行了展望。第2章 需求分析2.1 业务需求需求就是以一种清晰、简明、一致且无二义性的方式对一个待开发系统中的各个方面有意义的陈述的集合。以下以UML中的活动图进行简单描述11。2.1.1 业务描述（一） 实现用户注册登陆、商品展示、商品检索、商品选择、网上订货等功能，对网上购物的基本过程进行管理；（二） 实现对网上购物过程中产生的所有业务数据的管理，如订货单、支付记录、发货信息的管理与维护；（三） 具有配套的系统后台管理维护功能，能够对商品信息、用户信息、系统日志等信息进行管理与维护，并能够进行对应的权限管理；（四） 响应速度合理，安全性较高；（五） 系统运行稳定，并且应易于维护。2.1.2 业务流程（一） 用户注册和登陆，实现流程如图 21所示：图 21用户注册和登陆（二） 商品展示活动图，见图 22：图 22商品展示活动图（三） 网上订货活动图，具体流程见图 23：图 23网上订货活动图（四） 货款支付活动图，见图 24：图 24货款支付活动图（五） 发货活动图，见图 25：图 25商品发货活动图（六） 退货处理活动图，见图 26：图 26退货处理活动图2.2 功能需求功能需求刻画系统行为，定义了必须实现的软件功能，使得用户通过这些功能完成他们的任务，满足业务需要。下文将以UML中的用例图进行描述11。2.2.1 业务功能（一） 商品选购，用例图见图 27：图 27商品选购用例图（二） 货款支付，见图图 28：图 28货款支付用例图（三） 商品发货，见图 29：图 29商品发货用例图（四） 退货处理，见图 210：图 210退货处理用例图（五） 网上订货，见图 211：图 211网上订货用例图（六） 订单管理，见图 212：图 212订单管理用例图（七） 发货信息管理，见图 213：图 213发货信息管理用例图2.2.2 管理功能（一） 用户管理，见图 214：图 214用户管理用例图（二） 日志管理，见图 215：图 215日志管理用例图（三） 商品信息管理，见图 216：图 216商品信息管理用例图2.3 数据需求（一） 商品选购，见图 217：图 217商品选购（二） 货款支付，见图 218：图 218货款支付表示（三） 商品发货，见图 219：图 219商品发货表示（四） 退货处理，见图 220：图 220退货处理表示（五） 用户管理，见图 221：图 221用户管理表示（六） 日志管理，见图 222：图 222日志管理表示（七） 商品信息管理，见图 223：图 223商品信息管理表示2.4 非功能需求非功能需求包括产品必须遵从的标准、规范和合约；外部界面的具体细节和性能要求；设计或实现的约束条件及质量属性。2.4.1 环境需求1. Web服务器使用的Tomcat；2. 服务器能在Linux平台下部署10，能跨平台在其它OS下部署更佳；3. 数据库使用Mysql或Oracle。2.4.2 性能需求1. 可维护性。提供对自身的集中操作维护的功能，实现数据的备份和恢复。2. 易操作性。界面尽可能美观实用、方便和直观，充分考虑用户的体验。3. 可扩展性。能满足用户今后系统扩充和扩大使用范围的要求。4. 开放性。确保应用程序具有良好的互操作性和移植的可能。2.4.3 安全需求1. 容错性。用户输入或误操作时，系统应给出相关的响应，提示用户重新输入或者进行自动的修复校正。2. 系统的外在环境安全。充分考虑硬件和软件的安全因素，包括：网络的安全，系统的备份，防火墙，用户权限设置等； 3. 系统内部安全。确保授权用户的合法使用。4. 系统运行安全。系统应具有抵抗非法入侵的能力，支持定期自动和手动数据备份，能在数据损坏或丢失的情况下有一定的恢复能力。第3章 系统设计软件设计是软件开发的关键步骤，要解决“怎么做”的问题，主要着手对软件系统的功能结构、数据结构和用户界面等进行设计。3.1 总体设计3.1.1 系统设计的原则本系统设计尽可能地遵循实用性，先进性，规范性，安全性，易于集成，可扩展性等几大设计原则。3.1.2 系统体系结构设计B/S（Browser/Server）体系结构如下图 31：图 31体系结构B/S体系结构利用Web技术，通过浏览器实现软件应用的跨平台，节约了开发成本和维护成本。其应用程序以静态或动态网页的形式存放于Web服务器上，在一定程度上具有集中特征，并且安装、修改和维护全在服务器端解决，很容易在运行时自动升级。3.1.3 系统功能架构设计系统功能架构设计定义软件系统各主要部件及成分之间的关系。可以通过UML的包图来表示，系统功能简单对应需求分析中的用例。3.1.4 系统实现框架图系统采用MVC设计模式7，并对SSH2开发框架进行了整合，按层次划分为：PO，DAO，Manager，Action，Jsp Page五大模块8，如图 32：图 32系统模块划分3.1.5 包的内容及作用3.1.5.1 po（persistent object）包po包是业务数据的抽象，如用户，商品等，包内容见图 33。它主要用于持久化存储和各层间数据的传递。其中用hibernate框架对实体进行持久化，通过配置对象关系的映射来实现（见图 34），过数据库的操作语句和会话维护等烦锁重复的编程便由框架代为实现12。图 33 po包图 34 hibernate对实体类的配置3.1.5.2 dao（data access object）层图 35dao层dao层为数据访问接口层，主要包括四个包，见图 35。其作用是进行底层数据的更新、查找、增删等数据库操作的实现。以下将介绍dao层内各包的内容和作用：3.1.5.3 dao包dao包使用了模板方法，为po包中实体类都定义了对应的dao接口，见图 36，提供了各实体相应的数据库操作接口。图 36 dao包3.1.5.4 dao.impl.hibernate包dao.impl.hibernate包是dao包中接口的具体实现，这遵循了“接口实现相分离”的原则1来降低系统的耦合度，提高灵活性，见图 37。设计充分考虑了以后可能的扩展和修改的需要。例如采用jdbc包来实现而不采用hibernate框架，则提供类似的实现包即可，而上层对外的功能接口没有变化，其它的代码也就不受影响。图 37 dao.impl.hibernate包3.1.5.5 dao.facade 包dao.facade包采用了外观模式7进行设计，对各种不同类型的dao进行封装(如图 38所示），使得dao包的使用更方便和集中，修改和管理更容易；图 38 dao.facade图 39 dao.facade.impl3.1.5.6 Service层图 310 service层service层为业务逻辑实现层，层中各包见图 310。该层采用的设计技术和dao层十分类似。层中的各manager类进一步封装了dao包的各种操作，同时还增加了各种业务逻辑功能8。该层的另一作用就是使action层和dao层解耦，这些正是MVC模式设计的好处。3.1.5.7 Manager包manager包定义了各种业务对象管理接口，如用户管理，商品管理等业务逻辑管理类，见图 311；图 311 manager包3.1.5.8 manager.impl包manager.impl包是manager包接口的具体实现，如图 312，其设计思想和dao的impl包类似；图 312 manager.impl包3.1.5.9 manager.servicemanager.service也采用外观模式进行设计，对所有的manager进行封装，进行统一生成和管理，见图 313；图 313 manager.service包图 314 manager.service.impl包3.1.5.10 视图控制层该层使用struts2的MVC设计模式实现，结构见图 315。struts2.action包中的类充当控制器的角色，而视图显示则采用JSP动态页面。图 315 视图和控制层3.1.5.11 Action包struts2.action包充当MVC设计模式中的控制器角色14，处理各种客户端请求，见图 316。它实现了用例中各种业务功能和处理的动作调用，如注册对应RegisterAction，登陆对应LoginAction等，这通过配置文件struts.xml进行映射完成,如图 317。图 316 action包图 317 struts.xml配置login和register3.1.5.12 Jsp模块JSP Page模块实现系统的各个WEB视图界面5，见图 318。struts2各种action的处理结果都会返回对应的视图，如注册成功就调用注册成功的JSP页面，错误则调用错误的JSP页面等；图 318系统JSP包3.1.5.13 Spring充当的角色Spring在整个系统中并未显式出现，但它充当了极大的作用。如各个对象的成员变量、hibernate的会话工厂等的初始化都是通过spring注入13，即spring创建了对象，然后调用成员的setter进行了设置，下图 319便是对部分Action类的配置情况。这样就不用在代码中显式地调用new生成，降低了耦合度，并提高模块的灵活性，适应变化的能力更强。图 319 spring对action类的配置3.1.6 系统运作原理下面以“产品关键词搜索”用例来说明系统的大体运作原理，如图 320。图 320产品搜索的系统调用流程1. 当客户端浏览器发出请求链接时，Struts控制器将业务请求映射到对应的SearchAction类进行业务处理；2. SearchAction实例生成时，成员service是由spring注入的，在图中没有体现；接着通过service.getGoodInfoManager()，便能得到IGoodInfoManager的一个实例；3. SearchAction会通过Paging实例的paing（IGoodInfoManager）进行分页查找，在paing中调用了goodInfoManager.searchByLimit()，该函数将通过IGoodInfoDao的findBylimit()进行实际的数据库操作，最后获得并返回对应页的产品数据列表List；4. 上面的manager的操作只是进一步封装了dao层的接口，使得各层分明，耦合更低，而返回的数据由po包的实体类封装传递。3.2 数据库设计3.2.1 实体关系设计（一） 实体关系图图 321实体类关系图（二） 实体关系图（E-R图）15图 322在线购物E-R图图 323系统管理E-R图3.2.2 数据库表设计（一） GoodCategory(商品类别表)保存商品类别的基本信息。字段名数据类型长度主键否描述为空否默认CategoryIdint主键商品分类IDNOT NULLCategoryNamevarchar(20)20否商品分类名称NOT NULLLevelint否分类层次级别NOT NULL1Parentint否上一级分类NOT NULL0表 31商品信息表（二） GoodInfo(商品信息表) 保存商品的基本信息。字段名数据类型长度主键否描述为空否默认IdInt主键IDNOT NULLNamevarchar(150)150否名称NOT NULLPriceint否单价NOT NULLAmountint否库存量NOT NULLDescriptionvarchar(255)255否描述NULLPhotoBlob否照片NULLPhotoUrlVarchar(50)否照片路径NULLCategoryvarchar(50)50否所属分类NOT NULLStatusvarchar(10)10否促销状态NOT NULLUserInt否所属商家NOT NULL1表 32商品类别表（三） ShoppingCart(购物车表) 保存购物车记录的基本信息。字段名数据类型长度主键否描述为空否默认IdInt主键购物车对应的IDNOT NULLOwnerIdInt否车主的IdNOT NULLGoodIdInt否所放商品的IdNOT NULLQuantityint否所购买商品数量NOT NULLCreateDateDatetime否购物车创建日期NOT NULLMoneyint否车中商品总额NOT NULL表 33购物车表（四） OrderDetail(订单项表) 保存订单项的基本信息。字段名数据类型长度主键否描述为空否默认OrderDetailIdInt主键订单项IDNOT NULLOrderIdInt否所属订单的IDNOT NULLGoodIdInt否所记录的商品IdNOT NULLQuantityint否所买商品数量NOT NULLMoneyint否所记录的商品总额NOT NULL表 34订单项表（五） Order(订单表) 保存订单的基本信息。字段名数据类型长度主键描述为空否默认IdInt主键订单的IdNOT NULLUserIdInt否所属买家的IdNOT NULLSumMoneyint否订单最终总额NOT NULLOrderDateDatetime否下订单的日期NOT NULLPaymentStatuesvarchar(10)10否订单支付状态NOT NULLGoodsDeliverStatusvarchar(10)10否订单发货状态NOT NULLEndDateDatetime否订单完成日期NOT NULL表 35订单表（六） User(用户信息表) 保存用户的基本信息。字段名数据类型长度主键否描述为空否默认IdInt主键IDNOT NULLTypeInt否类型NOT NULLNamevarchar(10)10否姓名NOT NULLCodevarchar(20)20否登陆帐号NOT NULLPasswordvarchar(20)20否登陆密码NOT NULLMailvarchar(50)50否电子邮件NOT NULLMobilePhonevarchar(50)50否手机号码Telvarchar(50)50否电话Addressvarchar(255)255否收货地址SexByte否性别NOT NULL表 36用户信息表（七） ReturnGoodsApplication(退货申请表) 保存退货申请的基本信息。字段名数据类型长度主键描述为空否默认IdInt主键退货申请的IDNOT NULLOrderIdInt否对应的订单IdNOT NULLDealDateDatetime否退货申请的受理日期NOT NULLApplicantIdInt否退货申请的买家IdNOT NULLDescriptionvarchar(255)255否退货原因描述NOT NULLFeedbackResultvarchar(255)255否反馈结果NOT NULLStatusvarchar(10)10否退货申请受理状态NOT NULLSubmitDateDatetime否退货申请填写日期NOT NULL表 37退货申请表（八） PaymentRecord(支付记录表) 保存支付记录的基本信息。字段名数据类型长度主键否描述为空否默认IdInt主键支付记录IDNOT NULLOrderIdInt否订单IdNOT NULLPaymentTypevarchar(10)10否支付方式NOT NULLStatusvarchar(10)10否支付记录状态NOT NULLPayTimeDatetime否支付时间NOT NULLSumMoneyint否支付总额NOT NULLUserIdInt否支付人IdNOT NULL表 38支付记录表（九） GoodsDeliverRecord(发货记录表) 保存发货记录的基本信息。字段名数据类型长度主键描述为空否默认IdInt主键记录IDNOT NULLOrderIdInt否订单IdNOT NULLDeliverDateDatetime否发货日期NOT NULLStatusnvarvhar(10)10否发货状态NOT NULLTransportCompanynvarvhar(50)50否货运公司NOT NULLRoutenvarvhar(255)255否物流信息NOT NULLWayBillNumbernvarvhar(20)20否运单号NOT NULL表 39发货记录表（十） Log(系统日志表) 保存系统日志的全部内容。字段名数据类型长度主键描述为空否默认IdInt主键日志记录IDNOT NULLUserIdInt否操作人IDNOT NULLOperationTypeVarchar(20)20否操作类型（如：登录）NOT NULLOperateTimeDatetime否操作时间NOT NULLDescriptionVarchar(255)255否操作的详细描述NOT NULL表 310系统日志表3.3 系统实现3.3.1 界面的设计界面设计应用sitemesh框架和JSP技术5，这样能使得整个系统有一个统一的结构，每个页面只需专注于该页的内容即可，更容易实现模块化分配，有利用团队合作。其次各个页面的框架代码公用，使每个页面代码量也减少。源码 1是采用sitemesh后主框架结构的JSP源码。main.jspCategory > Category2 > Category3 > Name Product源码 1web界面主框架结构3.3.2 美化和JSJSP页面采用的DIV+CSS技术进行布局和美化3而不是硬编码，所以布局更改很灵活。布局目前主要参考了京东和淘宝。在开发阶段，各个主要的页面都有一个对应的CSS文件（见图 324），以后系统发布时可使用压缩工具进行压缩，合成一个，从而节省流量和系统的链接开销。这些都是后面的系统优化内容了。图 324 css和js源码结构JS的开发能提高系统的用户体验和交互性，本系统使用了流行的JQuery库和部分JS插件。不过目前只用到了图片自动播放功能和分页功能，JS开发还不是很多，当然也未使用Ajax开发。3.3.3 界面设计（一） 系统主页，见图 325图 325系统主页（二） 登陆框见图 326图 326登陆框（三） 注册框，见图 327图 327注册框（四） 用户登陆后主页，见图 328图 328登陆后的主页（五） 商家添加或更新商品，如图 329图 329商家添加商品（六） 用户中心，见图 330图 330用户资料修改（七） 搜索和搜索结果显示见图 331和图 332图 331搜索框图 332搜索结果（八） 商品详细信息，见图 333图 333单个商品详细信息（九） 结帐和下订单，见图 334和图 335图 334结帐或继续购物图 335购物车信息和下订单第4章 总结与展望4.1 总结毕业设计虽然已经快结束了，时间也十分有限了，但是学无止境，如果有兴趣的话，以后仍然可以继续开发下去。该系统加入了很多框架，而且代码大都有对应的Junit单元测试，所以扩展性和维护性是很不错的。不过，优点的同时也带来了缺点，那就是目前功能不多，但相对要掌握的知识多，使得系统显得复杂了些，但随着系统的变大，复杂性波动不会很大的。经过这几个月的努力，系统所设计的一些基本功能已经完成了。在这过程中遇到了不少的问题：1. 知识的学习和实践。J2EE开发要了解和学习的知识相当的多，这个花了不少时间，而且很多东西都是现学现卖的，所以难免会出现很多问题；2. 各种软件的下载和平台的搭建。毕竟以前都没有做过什么整合框架的项目，自己从网上、框架的官网文档、书籍等资源教程慢慢地去实践，最后感觉基本上掌握了基本的运作原理，能举一反三了；3. 系统的设计和编码二者间的同步问题。由于一开始，系统设计并不完美，所以在开发过程中，不断发现需要新的功能加入，这样使得一开始的设计又要去维护，工作量很大，所以最后那些UML设计落下