网上购物系统_毕业论.doc

装订线安徽工业大学毕业设计（论文）安徽工业大学毕业设计(论文)任务书课题名称网上购物系统学 院计算机学院专业班级软件工程专业101班姓 名赵倩学 号109074170毕业设计(论文)的主要内容及要求：1、了解相关领域的行业背景、业务需求和发展趋势（EB，尤其是B2C）；查阅数据库、软件工程和WEB应用开发相关的文献资料，撰写综述。2、按照软件工程的思想和方法,进行网上购物系统的需求分析、系统设计、编码和测试。3、在关系型数据库平台下, 采用JSP+ Struts2框架编程语言，设计并实现具有以下功能的网上购物系统：（1）前台客户端：用户注册和登录，商品信息浏览，购物车，前台订单处理。（2）后台管理端：用户管理，商品管理，后台订单管理。4、按照规范要求撰写毕业论文指导教师签字： 摘要随着互联网的普及，整个世界逐渐进入了网络经济时代。作为一种新型购物方式，网络购物的产生，对人们的生活方式，对世界的经济发展都产生了巨大影响。本系统是一个基于B/S模式的网上购物系统，使用Java作为开发语言，以Tomcat作为服务器，数据库管理系统采用MySQL,同时使用了Struts2框架开发。本文按照软件生命周期的观点展开论述，借助用例图、类图、顺序图等建模工具，清晰地展现了可行性分析、需求分析、总体设计、详细设计、测试等阶段的开发过程，重点介绍了系统的需求分析和详细设计。关键词：网上购物；Java；MySQL；Struts2 简洁明了，关键词在摘要中均出现AbstractWith the wide spread of the Internet, the whole world is gradually entering the network economy era. As a new way to shop, online shopping had a great influence on peoples way of life and the economic development of the world. The system is a online shopping system based on B / S mode.It uses java as the programming language and Tomcat as the server.MySQL is used as the database management system. It uses the Struts2 framework development as well.In this paper, according to the software life cycle perspective, with case diagrams, class diagrams, sequence diagrams and other modeling tools, clearly demonstrates the feasibility analysis, requirements analysis, design, detailed design, testing and other phases of the development process, focusing on needs a systematic analysis and detailed design.Keywords: online shopping;Java;MySQL;Struts2翻译尚可目录1 绪论11.1课题背景11.2网上购物网站现状11.3系统定义12 可行性分析32.1 技术可行性32.2 操作可行性32.3 结论33 需求分析43.1客户需求分析43.1.1 客户端功能需求43.1.2 后台管理功能需求43.1.3 需求补充说明43.2 系统建模53.2.1 确定用例63.2.2 绘制用例图63.2.3 用例图细化123.3 概念模型163.3.1寻找概念163.3.2建立概念类173.3.3系统初始类图194 总体设计214.1 系统总体设计思路214.2 系统功能模块划分214.2.1 前台系统功能模块划分214.2.2 后台系统功能模块划分224.3 数据库逻辑结构设计235 详细设计255.1 各功能模块详细设计255.1.1 注册模块255.1.2 登录模块265.1.3 商品浏览模块265.1.4 购物车模块275.1.5 订单模块285.1.6 确认付款模块305.1.7 发货处理模块305.1.8 用户管理模块305.1.9 商品管理模块335.1.10 商品类别管理模块335.1.11 订单管理模块335.2 系统总类图345.3 数据库表结构设计346 软件测试386.1 单元测试386.1.1 注册模块测试386.1.2 登录模块测试466.2 集成测试48总结53参考文献54致谢55附录56 3 需求分析拆成两章比较符合OOA/D过程，即“需求分析”或“用例建模” 与 “系统分析”第 IV 页 共 IV 页1 绪论1.1 课题背景随着互联网技术的发展，电子商务已经不再是一个梦想。通过网上银行、网上交易平台的支持，人们足不出户，便可轻松进行网上交易活动。本文介绍的系统是电子商务的一个部分，即网上购物系统的实现。用户进入该购物系统的后，通过虚拟的网上商店，在线挑选自己需要的商品，放置在虚拟的购物车内，接着通过购物系统向网上商店下订单，向该商品支付相关费用。网上商店收到用户订单后，等待用户支付的费用，在收到费用后发货，此次交易过程结束。另外，利用该系统，可以更好地进行商品的管理，及时添加新的商品，对部分商品可以下架等。“1.1课题背景”这几个字可以删去，这样下面的文字就可作为章节序言1.2网上购物网站现状在这信息高速发展的社会里，网络已经成为人们日常学习生活中不可或缺的一部分。人们可以从网络中浏览信息，享受服务，享受高科技带来的便利。因此网络市场前景相当广阔，而作为网络服务主流的网上购物更是很具有开发潜力。网络购物具有以下特点：商品的信息更加深进全面、减少了商品的销售本钱、节约了消费者的时间和体力、消除了消费者与商家的面对面冲突、降低了商户的经营本钱等等。当然，很多人对网络购物还存在一些顾虑，主要包括：不信任网站、怕受骗；担心商品质量问题；担心付款安全问题；担心商品配送有问题等等。但网民的所有这些顾虑，在不久的将来都会得到解决。购物网站信用的树立，和安全可靠的网上支付工具的发展，只是时间问题。1.3系统定义 “系统定义”含义不清，有点象开发技术现状Struts2框架: Struts 2是Struts的下一代产品，是在 struts 1和WebWork的技术基础上进行了合并的全新的Struts 2框架。Struts 2以WebWork为核心，采用拦截器的机制来处理用户的请求，这样的设计也使得业务逻辑控制器能够与ServletAPI完全脱离开。JDBC: JDBC（Java Data Base Connectivity,java数据库连接）是一种用于执行SQL语句的Java API，可以为多种关系数据库提供统一访问，它由一组用Java语言编写的类和接口组成。JDBC提供了一种基准，据此可以构建更高级的工具和接口，使数据库开发人员能够编写数据库应用程序。JQuery:JQuery是继prototype之后又一个优秀的Javascript框架。它是轻量级的js库 ，它兼容CSS3，还兼容各种浏览器（IE 6.0+, FF 1.5+, Safari 2.0+, Opera 9.0+）。jQuery使用户能更方便地处理HTML（标准通用标记语言下的一个应用）、events、实现动画效果，并且方便地为网站提供AJAX交互。jQuery还有一个比较大的优势是，它的文档说明很全，而且各种应用也说得很详细，同时还有许多成熟的插件可供选择。jQuery能够使用户的html页面保持代码和html内容分离，也就是说，不用再在html里面插入一堆js来调用命令了，只需定义id即可。B/S模式：B/S(Browser/Server)结构即浏览器和服务器结构。它是随着Internet技术的兴起，对C/S结构的一种变化或者改进的结构。在这种结构下，用户工作界面是通过WWW浏览器来实现，极少部分事务逻辑在前端(Browser)实现，但是主要事务逻辑在服务器端(Server)实现，形成所谓三层3-tier结构。这样就大大简化了客户端电脑载荷，减轻了系统维护与升级的成本和工作量，降低了用户的总体成本(TCO)。三层架构：三层架构(3-tier application) 一个三层架构的应用程序由三部分组成，这三部分各自分布在网络中的不同地方。这三个部分分别是：工作站或表示层接口、事务逻辑、数据库以及与其相关的程序设计。用户工作站包括提供图形用户界面(GUI)的程序设计和具体的应用程序入口表格或交互式窗口。事务逻辑处在局域网(LAN)服务器或其他共享主机上，它作为响应工作站所发出客户请求的服务器，而相对于处于大型机的第三层它是作为客户端，并且决定需要什么数据以及数据存储在哪里。第三层包括数据库以及处理读写以及访问数据库的程序。然而应用程序的设计可能比这个架构要复杂，对于大型程序来说，这个三层模式是一种比较简便的考虑方法。这种应用程序的设计使得各层可以同时开发，并且可以由不同的程序员组用不同的语言来开发。因为各个层次的开发不会影响其他层次，所以这种模型对于进一步开发软件是很方便的。J2EE: J2EE Java2平台企业版（Java 2 Platform,Enterprise Edition） J2EE是一套全然不同于传统应用开发的技术架构，包含许多组件，主要可简化且规范应用系统的开发与部署，进而提高可移植性、安全与再用价值。J2EE核心是一组技术规范与指南，其中所包含的各类组件、服务架构及技术层次，均有共通的标准及规格，让各种依循J2EE架构的不同平台之间，存在良好的兼容性，解决过去企业后端使用的信息产品彼此之间无法兼容,，企业内部或外部难以互通的窘境。2 可行性分析开发一个基于计算机的系统通常都受到资源（如人力、财力、设备等）和时间上的限制，可行性分析主要从技术、操作等方便分析所给出的解决方案是否可行，能否在规定的资源和时间的约束下完成。每章前都要有一段序言，承上启下，可以2.1 技术可行性本系统在Windows系统下开发，Windows是最常用的的操作系统，与用户交互很好，Windows系统下的软件安装、文件管理都很方便；MyEclipse开发工具功能强大，且会自动编译，这给编程带来很大好处；java语言是面向对象的语言，具有简单性、可靠性和跨平台等特点。本系统采用的系统和软件都是很常用的系统和软件，当前的技术完全能支持系统开发的各项活动，所以技术上不存在任何风险。2.2 操作可行性本系统运行在通用的Windows操作系统上，由于是B/S模式，采用IE,FireFox等常用浏览器即可浏览本网站，无需安装专用的客户端软件，电脑用户都可以熟练操作本系统。因此，在操作的可行性上是不存在问题的。2.3 结论由技术可行性、操作可行性的研究，可以得出结论，网上购物系统的开发是可行的。理由较充分，结论明确，可以3 需求分析在计算机发展的初期，软件规模不大，软件开发所关注的是代码编写，需求分析并未受到重视。自软件工程出现后，在软件开发中引入了生存周期的概念，需求分析成为极其重要的阶段。随着软件系统规模的扩大，需求分析与定义在整个软件来发与维护过程中越来越重要，直接关系到软件的成功与否。人们逐渐认识到需求分析活动不再仅限于软件开发的最初阶段，还贯穿于系统开发的整个生存周期。20世纪80年代中期，形成了软件工程的子领域需求工程。需求工程是应用已证实有效的技术和方法开展需求分析，确定客户需求、帮助分析人员理解问题、评估可行性、协商合理的解决方案、无歧义地规约方案、确认规约以及将规约转换到可运行的系统时的管理需求1。首次出现引用，对应参考文献1Requirement Engineering，对下面我们将从客户需求、系统建模和概念模型三个部分分析本系统的需求。3.1客户需求分析本系统主要由前台和后台俩部分组成，前台是客户端，用户可以注册系统账号、登录系统、浏览商品、商品选购商品、填写订单、支付等。后台主要进行用户管理、商品管理、订单管理等。3.1.1 客户端功能需求（1）用户的注册。用（1），不能用1，因为1表示第1章，对（2）用户登录。（3）分类浏览商品。（4）选择购买商品并添加至购物车。（5）购物车中更改商品数量与删除商品。（6）订单的提交及收货人信息的修改。（7）支付。3.1.2 后台管理功能需求（1）管理员登录。（2）用户的管理，包括添加、修改、删除。（3）商品的管理，包括商品的增、删、该、查。（4）订单的管理，主要进行订单状态的修改等。3.1.3 需求补充说明（1）数据保存eshop系统需要长期保存在数据库中的数据有：用户信息：用户会长期使用本系统购物，其基本信息需要长期保留。这里的用户信息包括前端用户和后台管理员。商品信息：商品会长时间显示在系统界面上供用户浏览，其基本信息需要长期保留。服装信息：服装是商品的一种，为了方便系统以后增加新的种类商品，这里将本系统的商品详细信息与商品的基本信息分开存储。商品类别信息：用户可以按照类别搜索需要的商品，商品类别要显示给用户，需要长期保存。购物车商品条目信息：用户加入购物车中的商品可能不会及时付款，购物车中商品条目信息需要长期保留。订单信息：用户提交的订单可随时查看，要长期保存。收货人地址信息：用户的收货人地址信息每次购物的时候都会用到，需要长期保存。（2）系统的用户eshop 系统的用户包括前端客户和后台管理人员，为了更加清晰的展示购物流程，这里我们可以将后台管理人员做进一步划分为确认到款管理员，发货管理员，后台管理员。前端客户：浏览商品，购买商品，下订单，支付等。确认到款管理员：用户支付成功，到款之后确认。发货管理员：对已付款的订单发货。后台管理员：商品的添加、修改、删除，订单的管理等（3）系统运行的软件、硬件环境1）系统运行的软件环境系统建模采用支持UML的StartUML。本系统实现语言采用java。数据库管理采用MySQL数据库管理系统。系统操作平台采用Windows。2）系统运行的硬件环境3.2 系统建模从前面的客户需求分析可以看出，eshop 系统有4个执行者，即前端客户，确认到款管理员，发货管理员，后台管理员。这些执行者的业务活动和对系统的功能要求如下：（1）前端客户：注册账号，登录系统，浏览商品，添加商品至购物车，修改购物车中的商品，核对订单并填写收货人信息，提交订单并付款。（2）确认到款管理员：用户支付完成，修改订单状态为已付款。（3）发货管理员：对已付款的订单进行发货。（4）后台管理员：管理用户信息，添加新的商品，修改商品的信息，管理订单等。3.2.1 确定用例根据需求分析中客户对系统功能提出的要求，以及系统执行者的确定，可以确定系统用例。（1）根据前端客户对eshop 系统的整体业务功能需求，可选的用例有：用户注册。用户登录。浏览商品。用户购物并将选购的商品加入购物车。用户购物车管理。用户订单处理。（2）根据确认付款管理员对eshop 系统的整体业务功能需求，可选的用例有：确认付款管理员登录。确认付款管理员确认到款。（3）根据发货管理员对eshop 系统的整体业务功能需求，可选的用例有：发货管理员登录。发货管理员对已付款订单进行发货处理。（4）根据后台管理员对eshop系统的整体业务功能需求，可选的用例有：后台管理员登录。用户管理。商品管理。商品类别管理。订单管理。通过参与者找用例，可以。Android系统可能需要从功能要求找用例，大型管理系统可能需要从业务流程或系统流程找用例3.2.2绘制用例图根据系统需求说明分析中用户对系统的功能需求，已经确定了执行者和用例，现在可以绘制用例图了。（1） 根据前端客户对eshop 系统的整体业务功能需求，可以绘制出如图3.1所示的用例图。应把图号标注文字倒过来写，即“可以绘制出前端客户用例图，见图3.1”图3.1前端客户用例图图写下面，对用户注册用例描述见表3-1：表号标注正确表3-1：用户注册用例描述表写上面，对用例注册用例描述用户注册成为系统会员参与者前端用户前置条件无后置条件用户注册成为会员基本流程1. 点击注册进入注册页面2. 输入用户名、密码、确认密码3. 提交到数据库可选流程输入的用户名已注册，用户名或者密码字符非法，用户名或者密码长度不正确，密码与确认密码不匹配则返回重新注册，或取消，终止用例重点是基本流程+替代流程，对用户登录用例描述见表3-2：表3-2：用户登录用例描述用例登录用例描述用户登录进入系统参与者前端用户前置条件无后置条件用户登录系统基本流程1. 点击登录进入登录页面2. 输入用户名和密码3. 进入系统首页可选流程输入的用户名和密码不匹配，则返回重新登录，或取消，终止用例用户浏览商品用例描述见表3-3：表3-3：用户浏览商品用例描述用例浏览商品用例描述用户浏览商品参与者前端用户前置条件无后置条件用户浏览基本流程1. 用户选择商品的类别2. 系统根据用户选择的商品类别去数据库中查询商品并显示3. 用户在商品列表中选择具体商品查看商品详细信息4. 系统根据用户选择的具体商品显示商品的详细信息可选流程无用户购物车处理用例描述见表3-4：表3-4：用户购物车处理用例描述用例购物车处理用例描述用户购物车处理参与者前端用户前置条件登录进入系统后置条件用户处理购物车中商品基本流程1. 用户将商品加入购物车2. 用户去购物车结算3. 系统显示购物车中商品条目可选流程1. 用户修改购物车商品的数量2. 用户删除购物车中商品的数量3. 用户没有登录，则返回登录界面重新登录，或取消，终止用例用户订单处理用例描述见表3-5：表3-5：用户订单处理用例描述用例订单处理用例描述用户订单处理参与者前端用户前置条件登录进入系统后置条件用户处理订单基本流程1. 用户从购物车中选择商品下订单2. 用户核对收货人地址信息或者重新修改收货人地址信息保存到数据库3. 用户选择支付订单可选流程用户输入收货人地址信息有误，则重新填写收货人地址信息，或者取消，终止用例（2）根据付款确认管理员对eshop 系统的整体业务功能需求，可以绘制出如图3.2所示的用例图。图3.2付款管理员用例图用户订单处理用例描述见表3-6：表3-6：用户订单处理用例描述用例确认到款用例描述管理员确认到款参与者管理员前置条件登录进入系统后置条件确认到款基本流程1. 系统查询订单，显示需要确认到款的订单2. 选择需要确认到款的订单点击确认3. 系统修改订单状态为已到款4. 退出系统可选流程系统没有需要确认到款的订单则显示提示消息，或者取消，终止用例（3）根据发货管理员对eshop 系统的整体业务功能需求，可以绘制出如图3.3所示的用例图。图3.3发货管理员用例图用户订单处理用例描述见表3-7：表3-7：用户订单处理用例描述用例发货用例描述管理员发货参与者管理员前置条件登录进入系统后置条件发货基本流程1. 系统查询订单，显示需要发货的订单2. 管理员选择需要发货的订单，点击确认3. 系统修改订单的状态为已发货4. 退出系统可选流程系统没有需要发货的订单则显示提示消息，或者取消，终止用例（4）根据据后台管理员对eshop 系统的整体业务功能需求，可以绘制出如图3.4所示的用例图。图3.4后台管理员用例图用例描述：用户管理用例，用于管理员查看、修改、添加以及删除用户信息。商品管理用例，用于管理员查看、修改、添加以及删除商品。商品类别管理用例，用户管理员查看、修改、添加以及删除商品类别。订单管理用例，用户管理员查看以及删除订单。3.2.3 用例图细化也可放到设计阶段前端用户主要功能需求为：注册，登录，浏览商品，购买商品，购物车处理，订单处理，这里我们对购物车处理和订单处理进一步细化。后台管理员主要功能需求为：用户管理，商品管理、商品类别管理，订单管理，这里将逐一细化。（1）购物车处理主要功能需求包括：修改商品数量，删除商品。购物车处理用例图如图3.5所示。图3.5购物车处理用例图用例说明：修改商品数量用例，用于用户增加或减少购买商品的数量。删除商品用例，用于用户删除不需要购买的商品。（2）订单处理主要功能需求包括：填写收货人信息，提交订单，查看订单。订单处理用例图如图3.6所示。图3.6订单处理用例图用例描述：填写收货人信息用例，用于用户填写送货地址，便于商家送货。提交订单用例，用户用于确定下单并进行付款的操作。查看订单用例，用于用户查看自己订购的商品及其订单的状态。（3）用户管理主要功能需求包括：查看用户信息、添加用户信息、修改用户信息、删除用户信息。用户管理用例图如图3.7所示。图3.7用户管理用例图用例描述：查看用户信息用例，用于管理员查看系统用户的资料信息。增加用户信息用例，用于管理员增加一个新的用户信息，便于这个新用户登录系统。修改用户信息用例，用于管理员修改系统已经存在的用户的资料。删除用户信息用例，用于管理删除一些用户的信息。（4）商品管理主要功能需求包括：查看商品信息、添加商品信息、修改商品信息、删除商品信息。商品管理用例图如图3.8所示。图3.8商品管理用例图用例说明：查看商品用例，用于管理员查看商品的详细信息。添加商品用例，用于管理员添加的商品。修改商品用例，用于管理员修改系统存在的商品的信息。删除商品用例，用于管理员删除系统存在的商品。（5）商品类别管理主要功能需求包括：查看商品类别、添加商品类别、添加商品类别、删除商品类别。商品类别管理用例图如图3.9所示。图3.9商品类别管理用例图用例描述：查看商品类别用例，用于管理员查看商品类别。添加商品类别用例，用于管理员添加新的商品类别。修改商品类别用例，用于管理员修改已经存在的商品类别。删除商品类别用例，用户管理员删除已经存在的商品类别。（6）订单管理主要功能需求包括：查看订单信息。订单管理用例图如图3.10所示。图3.10订单管理用例图用例描述：查看订单信息用例，用于管理员查看用户已下的订单信息，便于做相关统计。3.3 概念模型概念模型表征了待解释的系统的学科共享知识。为了把现实世界中的具体事物抽象、组织为某一数据库管理系统支持的数据模型，人们常常首先将现实世界抽象为信息世界，然后将信息世界转换为机器世界。也就是说，首先把现实世界中的客观对象抽象为某一种信息结构，这种信息结构并不依赖于具体的计算机系统，不是某一个数据库管理系统（DBMS）支持的数据模型，而是概念级的模型，称为概念模型2。3.3.1寻找概念根据用例图以及用例描述，可以确定对象类及其属性。（1）用户信息类名：用户。功能：保存用户的基本信息。属性：用户id、用户名、用户密码、是否是管理员。（2）商品信息类名：商品。功能：保存商品基本信息。属性：商品id、商品名称、商品原价、商品现价、是否下架、商品图片、现存货量、售量、上架时间、是否特价。（3）商品规格（这里是服装）信息类名：服装。功能：保存服装规格信息。属性：服装id、商品id、服装品牌、服装材料、服装尺寸、服装数量。（4）商品类别信息类名：商品类别。功能：保存商品类别信息。属性：商品类别id、商品类别名称、上级类别id。（5）购物车商品条目信息类名：购物车条目。功能：保存购物车中的商品条目。属性：商品条目id、用户id、商品id、商品数量，商品尺寸。（6）订单信息类名：订单。功能：保存订单信息。属性：订单id、订单号、用户id、订单状态、总价格。（7）订单详细信息类名：订单详细。功能：保存订单详细信息。属性：订单详细id、订单id、商品id、商品数量、商品尺寸。（8）收货人信息类名：收货人信息。功能：保存收货人信息。属性：收货人信息id、用户id、收货人姓名、收货人详细地址、收货人联系电话。3.3.2建立概念类根据对象类可以画出类图，为了方便起见，我们把类名及其属性用英文表示。 （1）用户类图，如图3.11所示：图3.3.2-1用户类图图3.11用户类图（2）商品类图，如图3.12所示：图3.12商品类图（3）服装类图，如图3.13所示：图3.13服装类图（4）商品类别类图，如图3.14所示：图3.14商品类别类图（5）购物车条目类图，如图3.15所示：图3.15购物车条目类图（6）订单类图，如图3.16所示：图3.16订单类图（7）订单明细类图，如图3.17所示：图3.17订单明细类图（8）收货人信息类图，如图3.18所示：图3.18收货人信息类图3.3.3系统初始类图根据系统功能需求和对象类，可以得出对象类之间的关联，进而画出系统的初始总类图，如图3.19所示：图3.19系统初始类图虚线箭头是依赖，不对，应该用实直线（关联），关联上应该有多重性，即几对几4 总体设计经过需求分析阶段的工作，系统必须做什么已经清楚了，总体设计阶段就是决定怎么做的时候了。总体设计的基本目的就是回答“概括的话，系统该如何实现？”这个问题。下面就开始对系统的总体设计。总体设计主要从系统的架构、系统的模块划分和系统数据库的逻辑结构三方面进行设计。4.1 系统总体设计思路本系统采用分层模式把系统组织成一系列的层次，每一层提供一组服务。视图层主要用于与用户交互，提供用户操作接口，在具体实现中，主要用JSP技术展现交互界面；模型层主要用来封装业务逻辑，具体业务逻辑会放在各个组件当中；控制层用来协调模型和视图的，系统采用了Struts框架，总控制主要由Struts2控制器来实现。用简单的话描述这三层之间的协调工作流程就是，视图层将用户的操作请求交给控制器，控制器调用合适的模型来处理请求，模型处理的结果会发送给控制器，控制器选择合适的视图来显示处理结果。4.2 系统功能模块划分由需求分析的结果，系统主要分为前台和后台俩个子系统，后台做了进一步划分，分为确认付款、发货处理和后台管理，系统包图如图4.1所示：图4.1系统包图4.2.1 前台系统功能模块划分前台主要为客户端用户提供进入系统的途径以及在线购物的功能，前台系统包图如图4.2所示：图4.2前台系统包图4.2.2 后台系统功能模块划分后台付款确认系统主要为后台付款确认管理员提供进入系统的途径并进行到款确认操作，发货处理系统主要为后台发货处理管理员提供进入系统的途径并进行发货操作，后台管理系统主要为后台管理员提供进入系统的途径并管理用户、商品、订单。（1）确认到款系统包图如图4.3所示：图4.3确认到款系统包图（2）后台发货处理系统包图如图4.4所示：图4.4后台发货处理系统包图（3）后台管理系统功能模块图如图4.5所示：图4.5后台管理系统功能模块图还可写各模块思路（流程），页面跳转流程等4.3 数据库逻辑结构设计概念模型转关系模式，对在需求分析中，我们分析出数据的概念模型，概念模型是独立于任何一种数据模型，可以转换成任何一种具体的DBMS所支持的数据模型，如网状模型、层次模型和关系模型3。这里我们采用关系模型。在概念模型中，我们确定的类有：用户信息类(user)，商品信息类(product)，服装信息类(clothes)，商品类别信息类(category)，购物车条目信息类(cartiten)，订单信息类(order)，订单详细信息类(orders_detail)，以及他们的属性和操作，这里为了清晰地表达商品和商品类别这俩个对象类之间的联系，我们将他们的联系也转换成一个关系模式（category_product），把每一个类转换成一个关系模式如下，其中，单下划线表现主键，双下划线表示外键：user(id,username,password,isAdmin);product(id,name,fix_price,jd_price,is_deleted,picture,now_amout,sale_amount,adds_time,is_special);clothes(id,pro_id,brand,material,size,size_qty);category(id,name);category_product(id,pro_id,cat_id);cartitem(id,user_id,pro_id,qty,size);orders(id,order_no,user_id,state,total_price);orders_detail(id,order_id,pro_id,qty,size);外键用波浪线。如何用关系范式进行设计没讲清，即多对多，一对多如何处理的5 详细设计详细设计是对总体设计的一个细化，详细设计的主要任务是设计每个模块的的算法、所需的局部数据结构。下面介绍了以顺序图方式描述了系统形式化的动态行为，并设计了数据库的表结构。5.1 各功能模块详细设计在总体设计中，系统被划分成四个部分：前台客户端部分、确认付款部分、发货处理部分、后台管理部分。其中前台客户端部分又可分为注册、登录、商品浏览、购物车处理、订单处理五个模块，后台管理部分可分为用户管理、商品管理、商品类别管理和订单管理四个模块。接下来对每个模块进行详细设计。5.1.1 注册模块前台用户在首次使用该系统时，需要注册一个进入系统的账号和密码，至于验证码部分，由于系统是用于毕业设计，考虑到验证码的用处不大，故这里略去。系统要求用户输入合法地用户名和密码才能注册成功，否则注册失败，并且向用户给出错误提示信息。用户注册的顺序图如图5.1所示：图5.1用户注册顺序图5.1.2 登录模块前台用户必须登录系统后才能进行完整的购物，在输入有效的用户名和密码后才能登录成功，否则登录失败，将显示登录失败原因。后台管理员登录与之类似。用户登录的顺序图如图5.2所示：图5.2用户登录顺序图5.1.3 商品浏览模块用户进入系统之后，可以选择商品的类别，然后按照类别进行浏览商品。商品浏览的顺序图如图5.3所示：图5.3商品浏览顺序图5.1.4 购物车模块用户选中商品后，可以将商品添加到购物车当中，在购物车中，用户可以更改商品的数量或者删除购物车中商品。购物车模块顺序图如图5.4所示：图5.4购物车处理顺序图5.1.5 订单模块用户选中购物车中的商品以后，去订单界面结算，需要核对订单信息以及收货人地址信息。如果用户是首次在本系统购买商品时，系统没有该用户的收货人地址信息，需要用户手动填写，填写完毕且核对有效后系统将保存此用户的收货人地址信息；如果用户不是第一次购买商品，系统会保留用户上一次购买商品时的收货人地址信息，将直接显示在收货人地址信息栏，用户也可以不用此地址，修改保存即可。当收货人地址信息和订单信息核对成功，用户可以点击提交订单，提交订单成功，用户可以查看我的订单，购物车中对应的商品将被清除；提交订单失败，则显示失败提示信息。订单模块顺序图如图5.5所示：图5.5订单模块顺序图5.1.6 确认付款模块用户提交订单支付完成后，管理员登录进入系统予以确认，即将订单状态改为已付款。确认付款模块顺序图如图5.6所示：图5.6确认付款模块顺序图5.1.7 发货处理模块订单已确认付款，管理员将进行发货处理，即将订单状态改为已发货。发货处理模块顺序图如图5.7所示：图5.7发货处理模块顺序图5.1.8 用户管理模块后台管理员进入系统后，可以管理用户信息。(1)查看用户默认会显示所有用户信息，包括管理员信息。点击“详情”可以显示与用户相关的订单信息、收货人地址信息和购物车信息（如果有的话）。(2)修改用户信息点击用户id，用户信息将已可编辑状态显示出来，管理员可以修改用户信息，保存即可。(3)添加用户信息点击添加用户，输入用户基本信息，保存即可。(4)删除用户信息选中需要删除的用户，点击删除，用户将永久从系统删除，包括与用户相关的订单信息、收货人地址信息和购物车信息（如果有的话），也会被永久删除。用户管理模块顺序图如图5.8所示： 图5.8用户管理模块顺序图5.1.9 商品管理模块管理员登陆系统后，默认是用户信息管理，切换到商品管理就可以管理商品信息。(1)查看商品列出所有商品基本信息，由于系统商品较多，采用分页显示，点击“详情”可以查看商品详细信息；(2)修改商品点击商品id，将以可编辑状态显示商品基本信息，管理员可以修改商品的信息，保存即可。(3)添加商品点击添加商品，输入商品的基本信息和详细信息保存即可。(4)删除商品选中需要删除的商品，点击删除，商品将永久从系统删除，如果只是想将商品下架，可以修改商品的基本信息“是否下架”属性。5.1.10 商品类别管理模块管理员登陆系统后，切换到商品类别管理就可以管理商品类别信息。(1)查看商品类别列出所有的商品类别信息，商品类别较多，采用分页显示。(2)修改商品类别点击商品类别id，商品类别将以可编辑状态显示出来，管理员修改商品类别信息之后保存即可。(3)添加商品类别点击添加商品类别，输入商品类别基本信息，保存即可。(4)删除商品类别选中需要删除的商品类别，点击删除，商品类别基本信息将永久从系统删除，如果删除的商品又子类别，子类别也一并删除。5.1.11 订单管理模块管理员登录系统后，切换到订单管理就可以管理订单信息。默认显示所有订单信息，可以根据订单状态选择查看订单信息。订单数目过多，采用分页显示。以上所有顺序图，样子尚可，但内容基本不对！5.2 系统总类图总结以上对各个模块的详细设计，可以进一步得出系统的总类图，如图5.9所示。图5.9系统总类图用实线箭头，即关联设计5.3 数据库表结构设计关系模式转表结构，对考虑到系统数据量不大，服务器在本机，Oracle数据库太庞大，系统采用了Mysql数据库。Mysql数据库具有体积小，稳定，易安装等特点。在总体设计中给出了数据库的关系模式，根据关系模式可以建立数据库的表结构如下，这里采用sql语句建表。（1）用户表：drop table if exists user;create table user(id int not null auto_increment,username varchar(20) not null,password varchar(10) not null,isAdmin int not null default 0,primary key (id), unique key (username);（2）商品表：drop table if exists product;create table product(id int not null auto_increment,name varchar(50) not null,fixed_price double not null,jd_price double not null,is_deleted int not null default 0,picture varchar(20),now_amount int not null,sale_amount int not null,adds_time varchar(20) not null,is_special int not null default 0,primary key (id);（3）服装表：drop table if exists clothes;create table clothes(id int not null auto_increment,pro_id int not null,brand varchar(20