下载文档原格式
毕业设计之进销存管理系统——⼀步步搭建⾃⼰的框架及系统⼤学四年，即将毕业！⼤学期间的最后⼀篇博客，总结分享下我做的毕业设计。
我选的论⽂命题为《燃⽓管⽹设备仪器进销存管理系统之后台设计》，由于我们专业只有我⼀个⾛技术路线，所以，我⼀个⼈完成了整个系统的设计及开发，总耗时近⼀个⽉，最终获得优的成绩。
这⾥不讨论论⽂，不写具体实现细节，主要讲如何⼀步步搭建⾃⼰的系统框架及系统实现，分享下⾃⼰的⼼得，新⼿可以互相学习，⼤⽜们就当看作本⼈抛砖引⽟啦！！博客最后会附上系统开发相关的所有⽂件但不包括毕业论⽂，本⽂已⼤体包含了论⽂的内容！⼀、系统展⽰1.登录页⾯2.admin登录后的主页3.菜单管理4.⾓⾊管理>新增⾓⾊5.⽤户管理6.添加商品7.仓库管理8.供应商管理9.采购订单管理10.采购订单导出11.库存查看12.采购统计⼆、系统需求分析 上⾯简单的展⽰了完成后的系统测试截图，你可以下载war包部署到⾃⼰的tomcat上看，下⾯开始进⼊正⽂。
开发⼀个(简单)系统，我想⾸要做的就是进⾏系统需求分析，弄清楚你为什么要做这个系统，这个系统有哪些功能模块，每个功能具体实现些什么功能。
当然，我这⾥的主要⽬的是完成毕业设计，交出毕业论⽂。
但我并没有简单的只是为了完成⼀个毕业设计⽽去开发这个系统。
主要想法是以开发这套进销存管理系统为例，详细说明⼀个系统从确认需求、技术选型、架构设计、系统实现到测试部署的整个开发过程。
综合运⽤⾃⼰平时所学的知识、技术，及实习获得的经验等，去完整且较好的实现⼀个系统。
搭建⼀个基础系统框架，形成⼀定规范，以后在此基础上做开发，可以省去很多诸如搭建框架、加⼊依赖、配置等⼯作。
这次开发所做的主要⼯作及意义如下： ①学会站在⽤户的⾓度分析⽤户需求，完成需求分析设计等。
②熟练使⽤各种类相关开发、设计⼯具，及开源软件。
③熟练掌握Spring+SpringMVC+Hibernate+ExtJs的开发技术。
一、系统背景随着现代科学技术的迅猛发展，计算机技术已渗透到各个领域，成为各行业必不可少的工具，特别是Internet技术的推广和信息高速公路的建立，使IT产业在市场竞争中越发显示出其独特的优势，步入数字化时代，有巨大的数据信息等待着加工处理和传输，这使得对数据库的进一步开发和利用显得尤为迫切。
作为国内市场的一些中小超市，他们在信息化过程中的步伐要落后大中型超市，而对于这些企业的资源管理，信息的存储和处理也显的迫切需要，要适应市场竞争，就需要有高效的处理方式和管理方法，因此加快超市的电算化进程是必不可少的。
在会计业务中，产成品的完成，发出和结存关系到超市销计划的完成和流动资金占用情况，而销售核算子系统是电算化会计系统中一个关键且比较复杂的子系统。
通过这个子系统提供的信息可以了解企业的经营成果，通过产品销售收入用来补偿已消耗的生产资料，支付工资和其他费用，缴纳税金并实现利润。
超市进销存管理系统是目前应用于公司或企业进销存管理系统中的典型代表，它涉及商品或货物管理中主要的几个方面，即进货、销售、库存。
本文利用Visual Basic完成管理平台设计，构造所用的类库；使用Access数据库存储数据，限单机使用。
主要阐述了进销存管理系统的设计目标，系统要求、总体设计、详细设计、测试等。
二、系统的需求分析1、理解需求本系统通过进销存系统的终端用户和客户的进行调研后，得出系统需求的关键部分如下：（1）进货管理商品进货信息管理：商品进货信息包括商品进货数量、单价、供货商、进货日期、等。
商品进货管理功能完成进货信息登记、修改和删除等。
更新库存：进货信息的变动直接关系到库存的变化（2）库存管理库存商品信息管理：：商品库存信息包括商品进货数量、单价、供货商、进货日期、等。
商品库存管理功能完成库存信息登记、修改和删除、查询等。
（3）销售管理信息管理：商品销售信息包括商品销售数量、单价、统计日等商品销售。
管理功能完成销售信息登记、修改和删除，以及销售总汇查询。
进销存管理方案1. 背景故事咱们企业在运营过程中啊，货物的进出、库存管理一直有点乱。
有时候货物卖出去了，库存却没及时更新，导致顾客要货的时候找不到。
还有进货的时候，也不太清楚到底哪些货物需要多进，哪些应该少进。
所以呢，为了让企业运营得更顺畅，就需要一个好的进销存管理方案。
1.1 计划框架这个进销存管理方案啊，就像一个精密的齿轮组。
进货就像是往齿轮组里添加新的齿轮，销售就是齿轮组带动其他部件运转，库存就是齿轮组的储备库。
各个环节相互关联、相互影响，任何一个环节出问题，整个齿轮组就不能很好地运转。
所以我们要从进货、销售、库存这三个主要方面来设计方案，确保每个环节都能顺畅衔接，准确无误。
2. 实施步骤2.1分阶段行动2.1.1启动阶段（第1 - 2周）2.1.1.1责任人安排这个阶段我们需要一个有组织能力的项目经理，就像一个乐队的指挥。
他要负责整个方案的启动，协调各部门的人员。
同时，还需要一个熟悉业务流程的老员工来帮忙，这个老员工就像是指挥的助手，提供一些实际操作中的经验。
2.1.1.2具体行动首先，项目经理要组织各部门开会，让大家都明白进销存管理方案的重要性。
然后，助手老员工要详细介绍目前企业在进销存方面存在的问题。
之后，大家一起讨论初步的改进方向，比如确定需要哪些新的管理表格之类的。
2.1.2搭建框架阶段（第3 - 4周）2.1.2.1责任人安排这个阶段需要一个擅长数据管理的专员，他就像一个建筑设计师。
还需要一个程序员（如果有系统开发需求的话），他就像建筑工人。
2.1.2.2具体行动数据管理专员要开始设计进货、销售、库存管理的基本表格结构，明确每个表格需要记录哪些信息，比如进货表要有供应商名称、进货日期、货物名称、数量、单价等信息。
程序员呢，如果我们要开发一个进销存管理系统，他就要根据这些表格结构来搭建系统的基本框架。
2.1.3填充数据与培训阶段（第5 - 6周）2.1.3.1责任人安排各部门的业务骨干要参与进来，他们就像学生的辅导员。
进销存管理系统需求规格说明书安讯进销存管理系统(asuntech sales, purchasing, inventory manager system)：ASPIMS1业务描述在市场经济中，销售是企业动作的重要环节，为了更好的推动销售，不少企业建立分公司或代理制，通过分公司或代理把产品推向最终用户。
这些分公司或代理商大多分布在全国各地，甚至是在国外，运距离频繁的业务信息交流构成了这些企业业务活动的订特点。
在传统方式上，公司之间通常采用电传、电报、电话等方式传递订货、发货、到货、压货、换货、退货等信息，总公司的商务部门在接到分公司或代理商传来的订单和银行汇款单据传真件后，开具产品出库通知，然后把相关的进、销存信息手工存档，再对这些信息进行统计分析，才能了解到整个公司的生产、销售和库存情况。
这种信息传递、管理方式不仅效率低，可靠性、安全性和保密性都无法满足要求，而且数据统计时间严重滞后，往往是当领导了解到企业的“进、销、存”环节出现问题时，就已经远离了问题出现的时间和地点。
即便是没有分公司的企业，使用传统的手工方式管理也存在同样的问题。
通过进销存管理系统，及时通过网络把决策信息传递给相关决策人，从而可以及时发现问题、解决问题，从而更好地把握机会。
主要包括下面几个功能：1.1资料管理企业经营的基础资料是一个企业最基本、最重要的信息，脱离了基础资料（包括商品资料、供货商资料和客户资料等），进销存系统就无法运行。
“资料管理”功能就用于维护这些基础资料，其中所包含的功能模块商品编码设置、商品资料维护、供货商资料维护、客户资料维护、业务员信息维护、仓库信息维护、采购合同管理、销售合同管理1.2采购管理“采购管理”用于管理企业的采购业务1.3销售管理“销售管理”用于管理企业和销售业务1.4库存管理“库存管理”用于管理企业的库存信息1.5应付款管理“应付款管理”用于管理企业的应付款业务1.6应收款管理“应收款管理”用于管理企业的应收款业务1.7帐务管理“帐务管理”用于管理企业的结帐业务。
进销存管理系统–详细设计说明书1. 引言1.1 编写目的本文档主要描述了进销存管理系统的详细设计，包括系统的总体架构、模块划分、功能需求、数据库设计等方面，以指导开发团队进行系统开发。
1.2 背景随着市场经济的发展，企业对物流管理的重视程度不断提高，进销存管理系统作为一种提高企业物流管理效率的工具，越来越受到企业的青睐。
该系统可以帮助企业实现对商品的采购、销售、库存等环节的实时监控和管理，提高企业的运营效率。
1.3 定义和缩略词•进销存管理系统：用于企业物流管理的软件系统，包括采购、销售、库存管理等模块。
•数据库：用于存储和管理系统数据的软件系统。
2. 总体设计2.1 系统架构进销存管理系统采用B/S架构，前端使用HTML、CSS、JavaScript等技术实现用户界面，后端采用Java、Python等语言开发业务逻辑，并通过数据库存储数据。
2.2 模块划分系统主要分为以下几个模块：1.用户管理模块：实现用户的注册、登录、权限管理等功能。
2.商品管理模块：实现商品的添加、修改、删除、查询等功能。
3.采购管理模块：实现商品的采购申请、审批、入库等功能。
4.销售管理模块：实现商品的销售订单、出库、收款等功能。
5.库存管理模块：实现商品库存的实时查询、预警等功能。
6.报表管理模块：实现各类报表的生成、导出等功能。
3. 功能需求3.1 用户管理用户管理模块包括以下功能：1.用户注册：新用户可以注册账号，填写用户名、密码、邮箱等信息。
2.用户登录：用户通过输入用户名和密码登录系统。
3.用户权限管理：管理员可以为用户分配不同的角色和权限，以实现对系统的不同操作。
3.2 商品管理商品管理模块包括以下功能：1.商品添加：管理员可以添加新的商品，填写商品名称、价格、库存等信息。
2.商品修改：管理员可以修改已有的商品信息。
3.商品删除：管理员可以删除不再销售的商品。
4.商品查询：用户可以根据商品名称、类型等条件查询商品信息。
石家庄科技信息职业学院课程设计（实训）报告系部信息工程系专业 __软件技术___ 班级 _ _ _ __学号 __ _ 姓名 ____ _____课题企业进销存指导教师 ____ _____报告成绩______________日期：年月日摘要在经济快速发展的今天，企业的进销存管理是企业经营管理中的重要环节，也是一个企业能够取得效益的关键，如果能够做到合理进货，及时销售，库存量最小的同时又不至于缺货，那么企业就能获得最好的效益。
本文从兴弘昌物资有限公司进销存管理现状为背景，说明了物资进销存管理在企业中的重要性，运用在专业课中学习到的信息管理系统开发的理论与技术知识，分析它的业务流程、数据流程，并且对系统的概念模型和逻辑模型进行设计，采用比较流行的C#语言，Windows XP、SQL Server2005、Visual Studio 2008为开发环境，开发了兴弘昌物资有限公司进销存管理系统，本系统通过计算机局域网对公司进销存业务数据实现同步管理，以求降低企业管理成本，提高其经济效益。
关键词：进销存管理；进销存管理系统；系统测试目录测试项目简介 (3)一、项目需求 (4)1.1日常事务模块 (4)1.2其他事务模块 (4)1.3基础信息 (5)二、测试计划 (6)2.1测试方案 (6)2.2测试项目 (6)2.3测试准备 (6)2.4测试机构及人员 (6)三、设计测试用例 (7)3.1测试项目名称及测试内容 (7)3.2测试实例 (7)四、界面测试 (9)五、测试缺陷报告 (9)六、结论 (10)七、参考文献 (10)测试项目简介一、项目需求根据对进销存管理内容和进销丰管理系统的分析，一个标准的进销存管理系统应该包括以下几大功能。
1.1日常事务模块1）进货管理：进行商品采购入库,采购退货,进/退单据和当前库存查询,与供货商的往来帐务。
1.“采购订单”用于录入企业的采购订单。
一般来说，采购订单、入库单，主表“采购订单”的内容包括编号、供货商号、订货日期、有效起日、有效止日、业务员、人、税价合计、不含税价、税额等，从表“采购订单明细”的内容包括编号、订单号、货号、订货数量、进价、税价合计、扣率、税率、不含税价，税额等。
用例视图•类图的绘制过程及如何读懂一个类图？•类图中的常用辅助建模元素有哪些？知识回顾本讲知识图谱•用例和用例驱动开发•如何阅读用例图•如何绘制用例图•用例图应用说明•本章小结本讲主要内容就是一个小的，具有客户价值的功能，通常表示为<action><result><object>特性(Feature)由客户参与编写，说明他们需要系统为他们做什么，一般用客户的术语编写，其长度约为三句话左右用户故事(user story)描绘一个系统外在可见的需求情况，是代表系统中各个项目相关人员(风险承担人，Stakeholder)之间就系统的行为所达成的契约用例(Use case)描述实践名称•共性：站在用户的角度看待系统、定义系统；使用用户能够看懂的语言来表述现代需求实践用例驱动开发过程•知名的“用例驱动”的开发过程有两个，一个就是重型的RUP，另一个则是“离地1000公尺”的ICONIX •在这些开发过程中，开发人员首先捕获客户的需求，并以用例的形式组织成用例模型。
然后分析并设计系统来满足这些用例，因此在用例模型之后就是分析模型，接着是设计模型和实施模型。
在实现了整个系统之后，还将根据用例模型设计出测试模型来对系统进行验证。
•这些模型之间并不是线性转变的，它们是一个迭代、增量的开发过程。
也就是在整个项目开发周期中，将会多次经过这五个模型的迭代，每次都将越来越精化参与者•参与者是为了完成一个事件而与系统交互的实体，是用户相对系统而言所演的角色•参与者不仅可以由人承担，还可以是其它系统、硬件设备、甚至是时钟1）其它系统：当系统需要与其它系统交互时，如ATM柜员机系统中，银行后台系统就是一个参与者；2）硬件设备：如果系统需要与硬件设备交互时，如在开发IC卡门禁系统时，IC卡读写器就是一个参与者；3）时钟：当系统需要定时触发时，时钟就是参与者如何寻找系统的参与者•谁或为什么使用系统，交互中它们扮演什么角色。
•谁安装、维护、启动和关闭系统。
•与该系统交互的是什么系统。
•谁从系统获取信息。
•谁提供信息给系统。
•有什么事发生在固定事件。
•用例实例是在系统中执行的一系列动作，这些动作将生成特定参与者可见的价值结果。
一个用例定义一组用例实例。
•用例是由一组用例实例组成的，用例实例也就是常说的“使用场景”，就是用户使用系统的一个实际的、特定的场景•用例应该给参与者带来可见的价值，这点十分关键用例•特定参与者希望系统提供什么功能。
•系统是否存储各检索信息，如果是，这个行为由哪个参与者触发。
•当系统改变状态时，通知参与者吗。
•存在影响系统的外部事件吗。
•是哪个参与者通知系统这个事件。
识别用例的最好办法是从分析系统的参与者开始，考虑每个参与者是怎样使用系统。
如何识别系统的用例Ø绘制下列用例图课堂练习用例图的组成元素•图中的元素包括：参与者、用例和一些表示关系的连接线。
•参与者与用例的关系：在参与者和用例之间的关联是用一根带箭头的线来表示的•用例之间的关系：1）包含关系2）扩展关系3）泛化关系•被包含的用例（此例中的检查座位详情）不是孤立存在的，它仅作为某些包含它的更大的基用例（此例中的预订座位、安排座位）的一部分出现•基用例是可以独立于扩展用例存在的，只是在特定的条件下，它的行为可以被另一个用例的行为所扩展包含与扩展关系•可以用来表示参与者与参与者之间，用例与用例之间的特殊/一般化关系泛化关系所绘制的用例图分析•这张用例图首先定义了三个基用例：预订座位、安排座位和处理结账•客户通过Internet启动“预订座位”用例，在“预订座位”用例的执行过程中，将“检查座位信息”（被包含用例），如果没有空闲的座位或满意的座位，可以选择进入等候队列，这样就将启动扩展用例“处理等候队列”。
•总台服务员在客户到棋牌馆时，启动“安排座位”用例，在执行过程中，将启动被包含用例“检查座位信息”。
•当客户要离开棋牌馆时，总台服务员将启动“处理结账”用例，并且定义了两种“收款”用例，一个是“处理现金结账”，另一个是“处理银行卡结账”，而后一个用例将通过与外部系统“银联POS系统”交互来完成。
用例描述•用例描述的是一个系统做什么（what）的信息，并不说明怎么做（how），怎么做是设计模型的事•事件流：[对该用例实现时需要考虑的业务规则、非功能需求、设计约束等]规则与约束[对多次重复的事件流可以定义为子事件流，这也是抽取被包含用例的地方。
]子事件流……(其中可以包含子事件流，以子事件流编号来表示)1b [1a 表示是对1的扩展，其中应说明条件和活动]1a扩展事件流……(其中可以包含子事件流，以子事件流编号来表示)2[在这里写出触发事件到目标完成以及清除的步骤。
]1活动步骤基本事件流[描述当前目标完成后，环境变化情况。
]成功保证[即该用例完成之后，将执行什么动作。
]后置条件[即启动该用例所应该满足的条件。
]前置条件…………[从该用例获取的利益][项目相关人员名称]利益项目相关人项目相关人利益说明[该用例的次要Actor ，在此列出名称，并简要的描述它]次要参与者[该用例的主Actor ，在此列出名称，并简要的描述它]主参与者[用例的设计范围]范围[用例的目标，一个概要性的描述]用例概述[应为一个动词短语，让读者一目了然地知道用例的目标]用例名称[为用例制定一个唯一的编号，通常格式为UCxx]用例编号用例描述模板用例图的绘制流程录入新书时能够自动按规则生成书号FEAT04计算机类与非计算机类书籍采用不同的书号规则FEAT05录入新书时如果重名将自动提示FEAT06按书名、作者、类别、出版社等关键字组合查询书籍FEAT07列出所有书籍信息FEAT08记录外借情况FEAT09外借状态能够自动反应在书籍信息中FEAT10按人、按书查询外借情况FEAT11列出所有的外借情况FEAT12按特定时间段统计购买金额、册数FEAT13所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行FEAT14书籍信息按计算机类、非计算机类分别建档FEAT03修改已有的书籍信息FEAT02新增书籍信息FEAT01说明编号记录需求—特性表识别参与者•已有的上下文关系图（表示系统范围）及其他相关模型：它们描述了系统与外部系统的边界，从这些图中可以寻找出与系统有交互关系的外部实体。
•项目相关人员分析：对项目的相关人员进行分析，就能够决定出哪些人将会与系统进行交互。
•书面的规格说明和其它项目文档（如会谈备忘录等）•需求研讨会和联合应用开发会议的记录：这些会议的参与者通常是很重要的，因为他们在组织中所代表的角色就是可能与系统发生交互的参与者。
•当前过程和系统的培训指南及用户手册：这些东西中经常会有潜在参与者。
UC06.统计金额和册数FEAT13.按特定时间段统计购买金额、册数FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行UC05.查询外借信息FEAT11.按人、按书查询外借情况FEAT12.列出所有的外借情况FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行UC04.登记外借信息FEAT09.记录外借情况FEAT10.外借状态能够自动反应在书籍信息中UC03.查询书籍信息FEAT07.按书名、作者、类别、出版社等关键字组合查询书籍FEAT08.列出所有书籍信息FEAT14.所有查询、列表、统计功能应可以单独对计算机类或非计算机类进行UC02.修改书籍信息FEAT02.修改已有的书籍信息UC01.新增书籍信息FEAT01.新增书籍信息FEAT03.书籍信息按计算机类、非计算机类分别建档FEAT04.录入新书时能够自动按规则生成书号FEAT05.计算机类与非计算机类书籍采用不同的书号规则FEAT06.录入新书时如果重名将自动提示用例特性合并需求获得用例绘制用例图1.用例名称：新增书籍信息（UC01）2.简要说明：录入新购书籍信息，并自动存储建档。
3.事件流：3.1 基本事件流3.2 扩展事件流4.非功能需求5.前置条件：用户进入图书管理系统。
6.后置条件：完成新书信息的存储建档。
7.扩展点：无8.优先级：最高（满意度5，不满意度5）……3.事件流：3.1 基本事件流1）图书管理员向系统发出“新增书籍信息”请求；2）系统要求图书管理员选择要新增的书籍是计算机类还是非计算机类；3）图书管理员做出选择后，显示相应界面，让图书管理员输入信息，并自动根据书号规则生成书号；4）图书管理员输入书籍的相关信息，包括：书名、作者、出版社、ISBN号、开本、页数、定价、是否有CDROM；5）系统确认输入的信息中书名未有重名；6）系统将所输入的信息存储建档。
3.2 扩展事件流5a）如果输入的书名有重名现象，则显示出重名的书籍，并要求图书管理选择修改书名或取消输入；5a1）图书管理员选择取消输入，则结束用例，不做存储建档工作；5a2）图书管理员选择修改书名后，转到5）4.非功能需求：无特殊要求……编写要点•使用简单的语法：主语明确，语义易于理解；•明确写出“谁控制球”：也就是在事件流描述中，让读者直观地了解是参与者在控制还是系统在控制；•从俯视的角度来编写：指出参与者的动作，以及系统的响应，也就是从第三者观察的角度；•显示过程向前推移：也就是第一步都有前进的感（例如，用户按下tab键作为一个事件就是不合适的）；•显示参与者的意图而非动作（如果只描述了动作，人们不能够很容易地直接从事件流描述中理解用例）；编写要点(续)•包括“合理的活动集”（带数据的请求、系统确认、更改内部、返回结果）；•用“确认”而非“检查是否”，例如“系统确认所输入的信息中书名未有重名”；•可选择地提及时间限制；•采用“用户让系统A与系统B交互”的习惯用语；•采用“循环执行步骤x到y，直到条件满足”的习惯用语。
建模要点•构建结构良好的用例：1）为系统和部分系统中单个的、可标识和合理的原子行为命名；2）将公共的行为抽取出来，放到一个被包含用例中，再将它《include》进来；3）对于变化部分，将其抽取出来，放到一个扩展用例（用《extent》连接）中；4）清晰地描述事件流，使得读者能够轻而易举地理解。
•构建结构良好的用例图：摆放元素时，应该避免交叉线的出现；对于语义上接近的行为和角色，最好使它们在物理上也更加接近；•根据系统实际情况控制粒度课堂小结•首先从三种现代需求技术开始，引入了用例驱动开发过程的方法，并且详细地阐述了参与者和用例的概念。
•结合了一个“棋牌馆管理系统”的用例图讲解了阅读用例图的方法，分析了用例图的组成元素，包括包含关系、扩展关系以及泛化关系，并在此基础上介绍了用例描述的方法、格式及相关的要点。
