家具城进销存管理系统

家具城进销存管理系统

集团标准化工作小组 [Q8QX9QT-X8QQB8Q8-NQ8QJ8-M8QMN]

中文题目：某家具城进销存管理系统

外文题目：ONE FURNITURE CITY ENTERS SELLS SAVES

MANAGEMENT SYSTEM

班 级：

学 号：

姓 名：

成 绩：

电子与信息工程学院计算机系

毕业设计（论文）共 92 页（其中：外文文献及译文11页） 图纸共0

张

完成日期 2014年7月 答辩日期 2014年6月

摘要

如何对家具的进货、销售、存库进行有效的管理，构建高效的管理体系、节约家具

城资金，是一个家具城成功经营的一项重要任务。如今许多家具城已经开始着手构建自

己的进销存管理体系，建立统一的数字自动化家具资源管理平台。论文阐述了某家具城

进销存管理系统的开发过程，包括问题定义、可行性研究、需求分析、系统分析，功能

设计、数据库设计、系统测试及操作等几个阶段。该家具城进销存管理系统采用基础，

结合C#语言、EXTJS技术、ORACLE数据库，实现了对家具信息管理、客户信息息管理、

供应商信息管理、入库管理、销售管理、收款管理、工作任务流转等功能。本系统的应

用为工作人员提供可视化计算机数字办公，节省人力物力及成本，保证数据准确安全

性，促进管理工作高效进行。

关键词：家具;进销存管理 ; ;EXTJS ;C# ;ORACLE

Abstract

How to managing the entering selling saving of furniture efficiently,

building an efficient management system and saving the furniture city’s mone,

is an important task of one furniture city to make its success. Now many

furniture cities have already started to carry out the furniture enters sells

saves system themselves, establish a unified digital automation furniture

resources trading platform. Paper expounds the public resources trading

management office automation system development process, including problem

definition, feasibility study, demand analysis, system analysis, functional

design, database design, system test and operation stages, such as public

resources trading management office automation system USES foundation,

combined with the c # language, EXTJS technique, ORACLE database, realized

with furniture imformation managerment, customer information management,

supplier information management, enters management, sells management,

gathering management, work flow, etc. Provide staff with a visual computer

digital office, saves the manpower cost, guarantee the accuracy of the data

security, promote the management efficiency.

Keywords: furniture;management; , EXTJS;c #; ORACLE

目录

0 前言

随着社会的进步，经济的飞速发展，民众的物质水平越来越高，消费能力也越来越

强，这给家具城带来了新的机遇的同时，也带来了新的挑战。旧时的人工纯人工管理在

进货、销售、存货任务日益繁重的今日已愈来愈难以支撑起一个家具城的家具管理体

系。另一方面，由于科技的进步，计算机的普及，办公自动化的代价也越来越小。这就

使得建立一个高效的家具进销存管理系统成为一个家具城成功经营的必须任务。

通过一个成功有效的家具进销存系统，可以实时查询或录入家具的型号、库存、销

售、收款等信息，不仅减轻轻了员工的负担，使家具的进销存管理变得简洁精确，同时

也可以减少企业纸类文档、人力资源等方面开销。

本系统研究内容为.NET领域知识，结合C#语言实现B/S结构信息系统开发，其中涉

及数据库，js等相关知识领域。

能够方便地将数据集成页面，使用简单易学，并且有能力进行复杂的数据应用。而

ORACLE是一款非常优秀的的数据库管理软件，使用方面，性能稳定，更提供了表空间概

念，合理的设计可提升系统运行效率。EXTJS技术提供了很好的页面视觉效果，并使用面

向对象编程，很好的结合整体项目的特性。本系统是采用技术、ORACLE数据库开发，采

用MVC4设计模式，分层架构设计思想和AOP、DI等技术。

1 问题定义

系统名称

某家具城进销存管理系统。(下文中为方便描述，称本系统为进销存管理系统)。

现行系统存在的问题

目前用户暂无有关家具进销存的相关管理办公系统，所有相关工作由公共资源交易

中心人员以部门级别分类人工实现。

本次设计的公共资源管理系统主要实现了对家具信息管理、顾客信息管理、供应商

信息管理、家具入库管理、家具销售管理、收款管理以及流程工作任务流。管理系统的

优势在于可处理种类繁多厂商、家具、仓库、销售、收款、顾客信息的统一管理；此

外，为解决审批审核流程复杂繁琐问题，系统为此运用工作流技术，不同职位等级处理

相关任务实时，设置工作流程后，按流程控制前后衔接，全部采用数字化交流，无需人

员走动，为工作人员进行管理工作提供了方便与高效。

项目目标

销售中可使用计算机对家具城家具的库存、型号等信息进行查询，收款时可利用计

算机进行账本管理，进货时可查询销售供应商信息、更改库存信息。

本次设计的公共资源管理系统主要实现了对家具信息管理、顾客信息管理、供应商

信息管理、入库信息、销售管理、收款管理以及流程工作任务流。家具信息管理应提供

家具型号等具体信息。供应商信息管理记录供应商信息，若增加供应商应更新供应商信

息。每次入库、销售应该更新库存信息。收款信息要进行汇总及核算。

项目范围

本系统主要供某家具城职工使用。系统采用B/S结构开发，需要两台及以上服务

器，一台为网络服务器，一台为数据库服务器，并支持内网网络环境；安装Google游览

器，用户使用远程PC端访问系统。

可行性研究阶段经费估算

初步可行性研究阶段经费约占总投资的%～%，约为元～元

2 可行性研究

并非任何问题都有简单明显的解决办法，事实上，许多问题不可能在预订的系统规

模或时间期限之内解决。如果问题没有可行的解，那么花费在这项工程上的任何时间。

人力软硬件资源和经费，都是无谓的浪费。

可行性研究的目的是，就是用最小的代价在尽可能短的时间内确定问题是否能够解

决。

现行系统调研

现行系统操作靠人工纸质文件操作及公司内部职工电话交流，需要投入大量人力物

力来维持交易进行，很不便利且浪费大量资源，同时人工操作可造成数据丢失、错误，

不具有安全性。

现行系统目标

现行系统建立于80年代，支撑着该家具城的日常运营，为该家具城的进货销售存货

等日常运作提供了有效的管理手段。依靠着一批老员工的熟练业务该系统基本实现了家

具的信息管理、供应商信息管理、进货管理、库存管理、收款管理，使得该家具城的销

售额稳步上升。但随着销售额的增大，员工的再熟练的业务水平也显得力不从心，出现

销售查询库存信息及家具信息繁琐缓慢、收款管理错漏等问题。而进销存管理系统正是

帮助管理者高效，数字化，可视化的，整体化，条理化的进行工作提供了可能。

用户组织机构

家具进销存管理中心

销仓进财

售库货务

部 部 部 部

图2-1

家具进销存管理中心

组织结构图

Figure 2-1 furniture enters sells saves center organization VARCHAR2t

⑴销售部职能职责

①负责向顾客介绍家具；

②负责为顾客向仓库部核实是否有存货；

③负责为顾客向财务部提交顾客订单；

④负责整理顾客信息，存入顾客信息库；

⑵仓库部职能职责

①负责实时统计库存量；

②负责管理保存家具；

③库存量为零时负责向进货部提交进货单；

④收到财务部送货单时为顾客送货；

⑤收到货后向财务部发送货到信息；

⑥负责整理库存信息，存入库存信息库；

⑶进货部职责

①收到进货单时负责向供应商提交订单，同时向财务部提交订货账单；

②负责供应商信息管理；

⑷财务部职能职责

①收到销售部订单后负责向顾客收款；

②负责向仓库部发送送货单；

③收到进货部的订货账单后向供应商提交定金，；

④收到仓库部的到货信息后向供应商付清余额；

⑤负责统计支出与收入，存入财务信息库；

系统的业务流程描述

顾客信息

库 确认购买

家具介绍

顾客

销售部

库存信息核实库存

库

提交顾客订单

财务部

图2-1 销售管理业务流图

Figure 2-2 sells management business flow diagram

库存信息

库

核算库存 提交进货单

进货部

仓库部

财务部

发送货到信息 财务信息

部

提交订货账单

库

支付订金

选择供应商

付清余款

出货

供应商

提交进货单

图2-2进货管理业务流图

Figure 2-3 enters management business flow diagram

财务部

提交出货单

仓库部 顾客

送货

更新库存 库存信息

库

图2-3送货业务流图

Figure 2-5 sends business flow diagram

销售部

提交顾客订单

财务部

收款 整理账簿 财务信息

库

提交送货单

仓库部

图2-4收款作业务流图

Figure 2-6 gathering business flow diagram

系统接口

系统暂无外部接口。

可行性分析

可行性研究是软件项目在正式立项前必须进行的分析，目的不是解决问题，而是确

定软件项目是否值得做以及能否用尽可能小的代价在可能短的时间内解决。

可行性研究最根本的任务是对以后的行动方针提出建议，如果问题没有可行的解，

应建议停止这项开发工程，以避免时间、资源、人力和金钱的浪费；如果问题值得解，

则推荐一个好的解决方案，并制定一个初步的工程计划。

本节可行性研究内容包括技术可行性、经济可行性、操作可行性、法律可行性。

可行性分析的目的

可行性研究的目的是为了对问题进行研究，以最小的代价在最短的时间内 确定问题

是否可解 经过对此项目进行详细调查研究，初拟系统实现报告，对软件开发中将要 面

临的问题及其解决方案进行初步设计及合理安排。明确开发风险及其所带来的 经济效

益。本报告经审核后，交项目经理审查。

技术可行性

⑴系统开发选用技术结合C#语言进行开发。开发人员拥有完善的技术框架，包含数

据操作框架、验证框架知识，并掌握NHirbernate数据库操作架构技术，AOP面向切面编

程技术、DI依赖注入技术等，能够很好实现系统在代码程度上的需求。系统视图页面采

用EXTJS技术，用纯JS编写Html页面，开发人员掌握其JS面向对象编程技术，并封装

重写其模块功能控件，为页面的设计与开发提供了很好的技术支持。

⑵系统数据支持采用ORACLE数据库，ORACLE数据库是现今较流行的数据管理软件，

官方可提供正版，开发人员能够进行相关的数据库操作及维护。

经济可行性

⑴系统开发、建立费用共6万元。其中：

本系统开发期为3个月，需开发人员3人（不一定都是参加满3个月）。根据软件

系统的规模估算，开发工作量约为12人月，每人月的人工费按5000元计算，开发费用

为6万元。

⑵服务器2台及网络等设备费12万元。

⑶其他费费用共2万元。 一次性支出总费用：18万元。

主要是系统运行费用，假设本系统运行期5年，每年的运行费用(包括系统维护、设

备维护等)5万元，按年利率5%计算如下表。 系统投资成本总额为：19+=万元。

表2-1 运行费用分析表

Table 2-1 operation cost analysis table

年份 将来费用 （1+） 现在费用值 累计现在费用值

（万元） （万元） （万元）

N

第一年 5

第二年 5

第三年 5

第四年 5

第五年 5

假设投入本系统，效率可以提高50%，以现有的工作人员15人计算，可减少8人，

每人每月平均工资按2500元计算，每年节约人员工资8×12×=24万元/年。按通货膨胀

（年利率）5%计算，效益计算如下表。

系统收益总额为：万元

表2-2 效益分析表

Table 2-2 benefit analysis table

年份 将来费用 （1+） N 现在费用值 累计现在费用值

（万元） （万元） （万元）

第一年 24

第二年 24

第三年 24

第四年 24

第五年 24

在5年期内，系统总成本万元，系统总收益万元。 收益投资比 = / =

1+（－）/=年

操作可行性

⑴从调研现有软件，客户需要使用一款数字化管理办公软件，用以提高工作效率，

节省人力物力成本，并且系统操作人员均具有一定的文化知识水平，能够正确熟练操作

系统。

⑵系统在设计开发过程中将操作可视化，简单易操作，尽管流程有时会繁琐，但强

健的系统可令其流程清晰，易操作。

⑶系统实施由开发人员到现场进行软甲部署，同时培训操作系统的工作人员如何熟

练操作系统，进行自动化数字办公。

法律可行性

⑴所有技术资料都为合法。

⑵开发过程中不存在知识产权问题，所有技术架构均为交流技术成果。

⑶未抄袭任何系统，不存在侵犯版权问题。

⑷开发过程中未涉及任何法律责任。

⑸合同经双方同意签字后生效。

可行性研究结论

综上所述，本系统的开发从技术上、经济上、操作上以及法律上等都是完全可靠

的。并且可以开展近一步开发。

3 系统需求分析

软件需求分析就是把软件计划期间建立的软件可行性分析求精和细化，分析各种可

能的解法，并且分配给各个软件元素。需求分析是软件定义阶段中的最后一步，是确定

系统必须完成哪些工作，也就是对目标系统提出完整、准确、清晰、具体的要求。

进销存管理系统用户需求

进销存管理系统功能需求

⑴实现家具类型、供应商信息的管理；

⑵实现客户信息、家具信息的管理；

⑶实现家具入库管理；

⑷实现家具的销售管理；

⑸系统能够对交易场地进行管理，包括添加、查询、修改、删除交易场地信息。

⑹实现收款管理。

进销存管理系统环境需求

客户端的环境需求：用户在PC端通过浏览器访问系统，用户需使用Google浏览器

访问系统，PC端需安装Google游览器。

硬件环境：用户需提供至少2台以上可用服务器，一台网络服务器，一台数据库服

务器，提供数据支持。

软件环境：服务器操作系统需Window2000版本以上，且支持网络环境，内网环境。

进销存管理系统可靠性需求

⑴软件程序在正常工作中应拒绝不友好提示、系统崩溃等现象。

⑵软件应拒绝无权限或无账号人员进入操作。

⑶软件处理正常应在可接受范围时间内给出解决结果。

进销存管理安全保密需求

软件应对恶意输出做出良好处理，避免恶意操作导致数据泄露；软件应对用户的操

作权限，网络漏洞进行严格控制；软件应具有工作日志，数据操作日志，访问日志记

录，避免不可控因素导致系统安全保密性受损。

进销存管理系统用户界面需求

本系统视图页开发使用EXTJS技术，对用户界面需求进行更严格的把握，系统用户

界面必须可控且易操作，尽量满足大众所常用的桌面菜单式需求，尽可能用简单的拖拽

点击操作系统。

进销存管理系统资源使用需求

系统资源使用需求必须满足有2台可操作服务器；用户工作使用PC机，要求内存2G

及其以上；拥有内网资源或外网资源，安装购买正版软件。如有具体需求，可增加一台

服务器减少并发压力，购买相关ORACLE服务作为数据支持。

进销存管理系统用例模型

用例模型是系统既定功能及系统环境的模型，它可以作为客户和开发人员之间的契

约。用例是贯穿整个系统开发的一条主线。同一个用例模型即为需求工作流程的结果，

可当作分析设计工作流程以及测试工作流程的输入使用。

进销存系统用例图

管理

表3-1用例图元素说明表

Table 3-1 a use case diagram elements table

元素名称 表示符号 说明

参与者(Actor) 表示与您的应用程序或

用例(Use Case) 用例就是外部可见的系

系统进行交互的用户、

组织或外部系统

统功能，对系统提供的

子系统(Subsystem) 用来展示系统的一部分

关联 参与者与用例间关系

泛化 参与者之间或用例之间

包含 用例之间关系

扩展 用例之间关系

服务进行描述

功能，这部分功能联系

紧密

关系

进货管理

用例01-01

销售管理

用例02

业务模块

财务管理

用例01-04

仓库管理

用例01-03

用例01-02

系统用户

用例03

系统管理

角色管理

权限管理

菜单管理

用例02-01

用例02-02

用例02-04

用例02-05

流程配置

用例02-06

图3-1 系统整体用例图

Figure 3-1 overall system use case diagram

供应商信息

整理

用例01-01

进货管理 制定订货单 缺货消息

用户

供应商信息

送往供应商

发送订货单

送往财务部

图3-2进货管理用例图

Figure 3-2 a enters manage use case diagram

查询库存信息 库存信息

用例01-02

销售管理

查询家具信息 家具信息

用户

制定顾客订单

发送顾客订单

整理顾客信息 顾客信息

图3-3销售管理用例图

Figure 3-3 sells manage use case diagram

整理库存信息 库存信息

查询送货信息 送货消息

用例01-03

仓库管理

用户

发送缺货消息

图3-4仓库管理用例图

Figure 3-4 warehouse manage use case diagram

收款

顾客订单

支付定金

订货单

财务管理

用户

支付余额

用例02-04

盈亏统计

发送送货消

图3-5财务管理用例图

Figure 3-5 fiance manage use case diagram

系统管理

字典管理

用例03-

系统用户

用例03-

新增

角色管理

用例03-

修改

管理员

权限管理

用例03-

删除

菜单管理

用例03-

活动定义

流程配置

用例03-

依赖转发

图3-6 系统管理用例

Figure 3-7 system management cases

进销存管理系统用例描述

表3-2 进货管理用例描述表

Table 3-2 enters manage use case description table

用例编号： 01-01

用例名称： 进货管理用例

描述内容属供应商信息（名称、地址、电话）

性： 订货单（供应商、家具类型、数量、价格）

行为者 用户

先决条件： 注册登录成功

后置条件： 加入工作流

活动步骤： 步骤 活动

⑴ 用户录系统，收到缺货消息，选择供应商，制定

订货单，发送给供应商和财务部

⑵ 用户登录系统，整理供应商信息。

异常处理方友好提示跳转登陆页或首页

法：

备注： 无

表3-3 销售管理用例描述表

Table 3-3 sells manage use case description table

用例编号： 01-02

用例名称： 销售管理用例

描述内容属家具信息（型号、价格）

性： 库存信息（家具型号、库存数量）

订货单（顾客信息（顾客编号、姓名、电话、地址）、所订家

具、订货数量）

行为者 用户

先决条件： 注册登录成功且拥有权限

后置条件： 加入工作流

活动步骤： 步骤 活动

⑴ 登录系统，查询家具信息

⑵ 登录系统，查询库存信息

⑶ 登录系统，制定顾客订单，发送订单，整理顾客

信息

异常处理方友好提示跳转登陆页或首页

法：

备注： 无

表3-4 仓库管理用例描述表

Table 3-4 warehouse manage use case description table

用例编号： 01-03

用例名称： 仓库管理用例

描述内容属库存信息（家具型号、仓库地址、库存数量、入库信息（入库

性： 时间、入库数量）、出库信息（出库时间、出库数量））

行为者 用户

先决条件： 注册登录成功且拥有权限

后置条件： 加入工作流

活动步骤： 步骤 活动

⑴ 登录系统，整理登记库存信息

异常处理方友好提示跳转登陆页或首页

法：

备注： 无

表3-5 财务管理用例描述表

Table 3-5 finance manage use case description table

用例编号： 01-04

用例名称： 财务管理用例

描述内容属订单（顾客信息（姓名、电话、地址）、所订家具、订货数

性： 量）

收款信息（顾客、时间、折扣、金额）

支付信息（供应商、时间、金额）

行为者 用户

先决条件： 登录具有相关权限

后置条件： 加入工作流

活动步骤： 步骤 活动

⑴ 用户登录系统，收到顾客订单，处理收款

⑵ 用户登录系统，收到订货单，处理支付

⑶ 用户登录系统，整理统计盈亏

异常处理方友好提示跳转登陆页或首页

法：

备注：

表3-6 系统管理用例描述表

Table 3-7 system management use case description table

用例编号： 0006

用例名称： 系统管理用例

描述内容： 系统管理只有系统管理员可以操作，系统管理包括字典管理，

可添加删除修改字典项，字典项为系统以及后台代码公共，系

统用户管理可以添加删除用户，角色管理为系统用户配置相应

的角色权限，菜单管理同样属于权限控制，可设置用户可操作

的菜单。系统管理与业务相关的操作位流程配置，系统管理员

可以对流程的步骤，审核人员角色，权限进行设定，是系统可

以由工作人员自行维护。

行为者 系统管理员

先决条件： 登录具有相关权限

后置条件：

活动步骤： 步骤 活动

⑴ 点击系统管理菜单

⑵ 选择功能图标

⑶ 进行相关操作

异常处理方友好提示跳转登陆页或首页

法：

备注： 无

3 .3 系统用例的活动图描述

N

注册登录 选定机构

完善信息

Y

填写机构信息

上传机构证件

填写个人信息

上传个人证件

进货管理

查询缺货信息

查看供应商信息

送往供应商

制定订货单

送往财务部

图3-7进货管理用例图活动图

Figure 3-7 enters manage activity diagram

销售管理

查询家具信息

选择操

作

新增交易场地

制定顾客订单

发送顾客订单

图3-8 销售管理用例活动图

Figure 3-8 sells manage activity diagram

仓库管理

N

货到

库存整理

Y

发送货到消息

某家具库

存为零

收到送货

消息

Y

送货

Y

N

N

发送缺货信息

图3-9仓库管理活动图

Figure 3-9warehouse management activity diagram

财政管理

选择操作

收款

查询订货单

发送送货消息

收到货到

消息

Y

N

支付定金 支付余额 统计盈亏

图3-10财务管理用例活动图

Figure 3-10 finance manage activity diagram

4 系统分析

公共资源交易管理系统类划分

系统开发无论是后台C#语言代码，还是前台页面EXTJS，都属于面向对象开发，因

此所有系统操作都可具体化成类的操作。因此系统类可划分为视图，控制与实体。

视图部分具有总视图类，视图内部组件类。

控制部分具有业务控制类，数据控制类。每一个视图都有其控制类。

实体部分为底层实体类与数据库表对应的实体类。

实体类分析

顾客实体、供应商实体、仓库实体、家具实体、收款实体、文件表实体、字典项实

体、字典类别实体、系统用户实体、菜单实体、角色实体。

边界类分析

边界类为信息系统与用户之间的交互提供媒介及视图页面，视图元素中视图类为界

面视图类，其包含多个组件类及操作。视图组件类包括树形菜单类、表单类、Grid列表

类，Bar工具类、单选下拉列表类、多选下拉列表类、窗口类、容器类等。

视图类包括进货管理视图类、销售管理视图类、仓库管理视图类、财政管理视图

类、桌面视图类。

控制类分析

每一个视图都有其对应的控制类。控制类调用其下实体的数据控制类，业务逻辑控

制类。

控制类包括机构控制类、场地控制类、合同控制类。项目控制类、工作台控制类。

用类实现进销存管理系统各用例的时序图

进货管理视图缺货消息类

类

点击图标请求 Http Req…

订货单类

创建订货单实

填写订货单信息

例

返回实例集合

返回订货列表

显示订货信息

图4-1进货管理用例时序图

Figure 4-1 enters management cases sequence diagram

销售管理视图销售控制类 家具信息类 库存信息类 顾客订单类

Http Req…

类

Http Req…

创建家具实例

返回实例属性

返回家具实例

创建库存实例

显示家具信息

显示库存信息

返回库存属性 返回库存实例

填写订单信息 创建订单实例

返回订单

显示订单信息

返回订单实例

图4-2销售管理用例时序图

Figure 4-2 sells management sequence diagram

仓库视图类 仓库控制类 库存信息类

Http Req…

缺货消息类

Http Req…

创建库存实例

返回库存实例

填写库存信息

填写缺货信息

创建缺货消息实例

返回缺货消息实例

返回库存信息

返回缺货消息

图4-3仓库管理用例时序图

Figure 4-3warehouse management cases sequence diagram

财务管理视图财务管理控制支付类

点击图标请求

类

收款类 送货消息类

统计类

Http Req…

创建收款实例

返回收款实例

结果显示

返回实例集合

创建送货消息实例

返回送货消息实例

创建支付实例

返回支付实例集合

返回显示

返回消息

结果显示

返回支付信息

创建统计实例

返回统计实例集合

返回盈亏信息

返回显示文件

图4-4财务管理用例时序图

Figure 4-4finance management sequence diagram

进销存管理系统类设计

系统类的总体设计

进销存管理

进货管理控制类

-获得缺货消息()

-获取供应商信息()

-选择供应商()

-制定进货单()

-发送订货单()

仓库管理控制类

-整理库存信息()

-制定缺货消息()

-发送缺货消息()

-发送货到消息()

-获取送货消息()

销售管理控制类 财务管理控制类

-获取家具信息列表() -获取订单信息()

-获取库存信息列表() -创建收款单()

-创建顾客信息() -获取顾客信息()

-制定顾客订单() -制定送货消息()

-发送顾客订单() -发送送货消息()

-获取订货单消息()

-获取货到消息()

-统计盈亏()

图4-6 进销存控制图

Figure 4-6 enters sells saves control class diagram

5 系统设计

进销存管理系统各用例的流程设计

⑴进货管理用例流程：

用户收到缺货消息，查询供应商信息，选择供应商，填写订货单，分别发送给供应

商和财务部。

⑵销售管理用例流程：

用户查询家具信息，向顾客介绍家具，并查询相应库存信息，若顾客要购买则制定

顾客订单，并将订单发送给财务部。

⑶仓库管理用例流程：

系统统计库存信息，若缺货则发送缺货消息，若收到送货消息，则开始送货，登记

出库信息，若货到则发送货到消息给财务部。

⑷财务管理用例流程：

用户收到顾客订单，处理收款，发送送款消息；若收到订货单，则处理支付定金；

若收到货到消息，则处理支付余额；到月底处理盈亏。

5. 2 进销存管理系统代码设计

系统代码设计采用分层结构设计，分别为基础设施层、业务逻辑层。

基础设施层进行系统所有与数据库交互的操作，业务逻辑层只专注系统功能逻辑的

设计，不关心底层数据的操作，系统与数据库交互获得数据操作使用NHirbernate框架

技术，系统中写有NHirbernate帮助类，重写Nhirbernate源码，避免使用Nhirbernate

框架产生循环加载问题，为节省代码量，系统使用DI依赖注入技术，将调用类设为类的

私有变量，不需要对其进行实例化。同时为保证系统安全性，不出现不友好的提示，系

统封装完善的验证框架，并使用AOP面向切面编程技术，将验证封装在每一个控制类的

特性中，数据复杂操作使用QuerOver技术或HQL技术，保证系统代码都为面向对象语

言。

展现层：展现层采用MVC设计模式，采用EXTJS编写视图页面，与数据库中表结构

对应的实体作为系统以及MVC的实体。在所有Controller基类中重写MVC路由，并将js,

页面设为签入的资源。

5. 3 进销存管理系统数据库设计

概念设计

地址 供应商名

电话

供应商

供应数入库时入库数

n

供应

n

型号

m

家具 仓库

价格

n

销

出库时出库数

销售数

m

交易时间

1

客户

姓名

客户编号

客户电实收金额

客户地址

n m

入

m

出

仓库编号

容量

仓库地址

记录号

1

支

收款

折扣

图5-1 进销存管理相关关系E-R图

Figure 5-1 enters sells saves management relationship e-r diagram

逻辑设计

供应商（供应商名，所在城市）；供应商名为主键。

家具（型号，价格，库存量）；型号为主键。

供应（供应商名，型号，供应数量）；（供应商名，型号）为主键，供应商名、型

号分别参照供应商关系的供应商名和家具关系的型号。

仓库（仓库编号，仓库地址，容量）；仓库编号为主键。

入库（型号，入库时间，入库数量，仓库编号）；（型号，入库时间，仓库编号）

为主键，型号、仓库编号分别参照家具关系的型号和仓库关系的仓库编号。

出库（型号，出库时间，出库数量，仓库编号）；（型号，出库时间，仓库编号）

为主键，型号、仓库编号分别参照家具关系的型号和仓库关系的仓库编号。

客户（客户编号，姓名，客户地址，客户电话，交易时间）；客户编号为主键。

销售（型号，销售数量，客户编号）；（型号，客户编号）为主键，型号、客户编

号分别参照家具关系的型号和客户关系的客户编号。

收款（记录号，实收金额，折扣，客户编号）；记录号为主键。

经审查，上述关系模型无部分函数依赖，无传递函数依赖，符合3NF，符合最低要求

无需优化。

招标代理机构表（RPT_B_AGENT）：

表5-1 供应商数据库表结构

Table 5-1 a supplier database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Gysm VARCHAR2(是 否 否 供应商名

Szcs VARCHAR2否 否 否 所在城市

10)

（10）

供应商表 GYS

表5-2 供应数据库表结构

Table 5-2 a suppling database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Gysm VARCHAR2(是 否 是 供应商名

Gysl NUMBER(100 否 否 否 供应数量

10)

)

供应表 GY

Xh VARCHAR2是 否 是 型号

（10）

表5-3 家具数据库表结构

Table 5-3 furniture database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Xh VARCHAR2(是 否 否 型号

Kcl NUMBER(100 否 否 否 库存数量

Jg NUMBER(162 否 否 否 价格

10)

)

,4)

家具表 JJ

表5-4 入库数据库表结构

Table 5-4 enters database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Xh VARCHAR2(是 否 是 型号

Rksj DATE 是 否 否 入库时间

Rusl NUMBER(100 否 否 否 入库数量

Ckbh VARCHAR2是 否 是 仓库编号

10)

)

（10）

入库表 RK

表5-5 出库数据库表结构

Table 5-5 outing database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Xh VARCHAR2(是 否 是 型号

Cksj DATE 是 否 否 出库时间

Cksl NUMBER(100 否 否 否 出库数量

Ckbh VARCHAR2是 否 是 仓库编号

10)

)

（10）

出库表 CK

表5-6 仓库数据库表结构

Table 5-6 warehouse database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Ckbh VARCHAR2(是 否 否 仓库编号

Ckdz VARCHAR2否 否 否 仓库地址

Rl NUMBER(100 否 否 否 容量

10)

（50）

仓库表 CKH

)

表5-7 销售数据库表结构

Table 5-7 sells database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Xh VARCHAR2(是 否 是 型号

Khbh VARCHAR2是 否 是 客户编号

Xssl NUMBER(100 否 否 否 销售数量

10)

（10）

)

销售表 XS

表5-8 客户数据库表结构

Table 5-8 customer database table structure

字段名 字段类型 小数位数 是否主键 是否为空 是否外键 备注

Khbh VARCHAR2(是 否 否 客户编号

Xm VARCHAR2否 否 否 姓名

Khdz VARCHAR2否 否 否 客户地址

Khdh VARCHAR2否 否 否 客户电话

Jysj DATE 否 交易时间 否 否

10)

（20）

（50）

（20）

客户表 KH

表5-9 收款数据库表结构

收款表 SK

是否主键 字段名 字段类型 小数位数 是否为空 是否外键 备注

是 Jlh VARCHAR2(否 否 记录号

否 Ssje NUMBER(162 否 否 实收金额

否 Zk NUMBER(162 否 否 折扣

否 Khbh VARCHAR2否 否 客户编号

Table 5-9 gathering database table structure

10)

,4)

,4)

（10）

系统安全性设计

软件系统安全缺陷是所有常见计算机安全性问题的根源 ,而其安全性又是一个涉及

面广泛而又复杂的课题 ,其最大难题之一是 :总有可能出现与所有已知模式完全不符合

的新型安全性缺陷。因此 ,要保护软件免受各种可能类型 ,包括未知类型的攻击是不切

实际的 ,但可以通过在设计和构建软件时运用合理的系统安全性原则来避免软件陷入容

易被攻击的状况。本文对软件开发过程中的五项系统安全性设计原则进行了分析 ,包括

保护最薄弱环节、纵深防御、故障保护、最小特权以及分隔原则

数据安全性

⑴软件系统属于B/S结构开发，用户通过浏览器访问系统，因此，并发操作数据情

况就会出现。为避免并发操作给系统带来的脏数据，数据库设计中每一个表结构都有一

个Version字段，避免用户同时操作统一数据，避免出现脏读，脏数据情况。

⑵系统主要为用户信息的管理，与数据的交互非常频繁，并发带来的数据库频繁的

打开与关闭大大增大了数据库的压力，因此，系统设计将事务绑定在一次Http请求上，

调用数据库存储过程而不是SQL语句，保证数据安全性。如果用户条件允许，数据库的

临时表空间与系统表空间可以部署在2台独立的服务器上，提高系统性能。

⑶系统有完善的数据验证框架，将在前台与后台同时对数据进行验证，避免恶意输

出，垃圾数据对系统数据安全性造成影响。

⑷数据传递使用TCPIP协议，且为内网环境，无关人员无法对数据进行操作。

⑸系统对用户的权限有严格的控制，同时，系统存在操作日志，数据库同时存在数

据日志来监控数据的操作与流向。

登录用户的安全性

系统的每一次操作都会对用户进行身份验证，权限验证。

操作安全性

系统的系统管理员可对系统用户的权限进行授予与回收，权限的授予包括系统管理

员对系统用户角色的分配，操作权限的设定，菜单权限的设定。

除系统管理员可对系统用户进行权限授予与回收外，其他系统用户没有此操作权

限。

系统安全性的其它考虑

暂无其他系统安全系考虑。

6 编码

良好的编码系统和规范的编码有一下几点作用：

⑴提高可读性 “任何一个傻瓜都能写出计算机可以理解的代码，唯有写出人类容易

理解的代码，才是优先的程序员。”编码规范，帮助我们写出人类容易理解的代码，它

为我们提供了最基本的模板，良好的编码风格，使代码具有一定的描述性，可以通过名

字来获取一些需要IDE才能得到的提示，如可访问性、继承基类等。

⑵统一全局，促进团队协作开发软件是一个团队活动，而不是个人的英雄主义。编

码规范，要求团队成员遵守这一统一的全局决策，这样成员之间可以轻松地阅读对方的

代码，所有成员正以一种清晰而一致的风格进行编码。而且，开发人员也可以集中精力

关注他们真正应该关注的问题——自身代码的业务逻辑，与需求的契合度等局部问题。

⑶有助于知识传递，加快工作交接 风格的相似性，能让开发人员更迅速，更容易理

解一些陌生的代码，更快速地理解别人的代码。因为，他和你的代码风格是一样的，你

没有必要对他的一些个性化风格进行揣测。这样的好处是开发人员可以很快的接手项目

组其他成员的工作，快速完成工作交接。

⑷减少名字增生，降低维护成本 在没有规范的情况下，和容易为同一类型的实例起

不同的名字。对于以后维护这些代码程序员来说会产生疑惑。

⑸强调变量之间的关系，降低缺陷引人的机会 命名可以表示一定的逻辑关系，是开

发人员在使用时保持警惕，从而一定程度上减少缺陷被引人的机会。

⑹提高程序员的个人能力 不可否认，每个程序员都应该养成良好的编码习惯，而编

码规范无疑是教材之一。从一个程序员的代码本身能看出很多东西。所以，即便是为了

自身发展，作为程序员也没有理由抵制这种规则的存在。你可能没有认识到，我们正默

默地得益于编码规范。

编程工具的选择

开发工具：Visual Studio 2012

变量设计

变量采用英文单词组合表示，切记不可使用拼音，变量名采用驼峰命名法，即第一

个单词首字母小写，其他单词首字符大写。

函数名设计采用帕斯卡命名法，即所有单词首字母都大写。

变量名设计原则

⑴变量名应简单明了，望文知意。变量名采用英文单词。切忌使用汉语拼音来命

名。程序中的英文单词一般不要太复杂，用词应当准确。例如不要把CurrentValue写成

NowValue。尽量不要使用单词缩写或首字母缩写。只有当变量名过长时才考虑使用单词

缩写。在使用缩写时，不要自创缩写，尽量使用被广泛接受的缩写。

⑵变量名长度应当符合“min-length && max-information”原则。一般的讲，长名

字能更好地表达含义，所以函数名、变量名、类名长达十几个字符不足为怪。但是名字

也不是越长越好。例如：变量名maxval就比maxValueUntilOverflow更好用。单字符的

名字也是有用的，常见的如i,j,k,m,n,x,y,z等，它们通常用作函数内的局部变量。

⑶命名规则尽量与所采用的操作系统或开发工具的风格保持一致。例如Windows应

用程序的标识符通常采用“大小写”混排的方式，如addChild。而Unix应用程序的标识

符通常采用“小写加下划线”的方式，如add_child。别把这两类风格混在一起用。

⑷程序中不要出现仅靠大小写区分的标识符。例如：NUMBER(10) x和NUMBER(10)

X；void foo() 和void FOO() 等。

⑸避免在不同级别的作用域中重名。程序中不要出现标识符完全相同的局部变量和

全局变量，尽管两者因作用域的不同而不会发生语法错误，但会使人产生误解。

⑹正确命名具有互斥意义的变量名。使用正确的反义词组命名具有互斥意义的变量

或相反动作的函数。如："MinValue"和"MaxValue"，"GetName()" 和 "SetName()"

⑺尽量避免名字中出现数字编号。如Value1,Value2等，除非逻辑上的确需要编

号。这是为了防止程序产生无意义的名字，降低程序的可读性。

⑻使用库标志在开发动态库时，为了防止软件库中的一些标识符和其它软件库中标

识符冲突，可以为各种标识符加上能反映软件性质的前缀。例如三维图形标准OpenGL的

所有库函数均以gl开头，所有常量（或宏定义）均以GL开头。

7 测试设计

从用户的角度出发，就是希望通过软件测试能充分暴露软件中存在的问题和缺陷;从

开发者的角度出发，就是希望测试能表明软件产品不存在错误，已经正确地实现了用户

的需求。

系统测试的基本原则

在设计有效测试用例之前，测试工程师必需理解软件测试的基本原则。这里有一组

测试原则：

⑴所有的测试都应追溯到用户需求。正如我们所知：软件测试的目标在于揭示错

误。而最严重的错误（从用户角度来看）是那些导致程序无法满足需求的错误。

⑵应该在测试工作真正开始前的较长时间内就进行测试计划。测试计划可以在需求

模型一完成就开始，详细的测试用例定义可以在设计模型被确定后立即开始。因此，所

有测试应该在任何代码被产生前就进行计划和设计。

⑶Pareto 原则应用于软件测试。简单地讲， Pareto 原则暗示着测试发现的错误中

的 80 ％很可能起源于程序模块中的 20 ％。当然，问题在于如何孤立这些有疑点的模

块并进行彻底的测试。

⑷测试应从 “ 小规模 ” 开始，逐步转向 “ 大规模 ” 。最初的测试通常把焦

点放在单个程序模块上，进一步测试的焦点则转向在集成的模块簇中寻找错误，最后在

整个系统中寻找错误。

⑸穷举测试是不可能的。即使是一个大小适度的程序，其路径排列的数量也非常

大。因此，在测试中不可能运行路径的每一种组合。然而，充分覆盖程序逻辑，并确保

程序设计中使用的所有条件是有可能的。

⑹为了达到最佳效果，应该由独立的第三方来构造测试。 “ 最佳效果 ” 指最有

可能发现错误的测试（测试的主要目标），所以创建系统的软件工程师并不是构造软件

测试的最佳人选。

⑺不充分的测试是不负责任的；过分的测试是一种资源的浪费，同样也是一种不负

责任的表现。

类测试

面向对象软件测试与传统的软件测试区别不大,只有类和类簇的测试才体现了面向对

象软件测试的特点,而两者之间又以类的测试最为关键。本文通过对状态机模型生成类的

测试序列的方法和代码实现以及基于状态测试法的测试数据生成的问题的探讨,认为基于

状态的测试方法和基于代数规约的测试方法(ASTOOT方法)将是类测试的主要的发展方向,

其余方法大多只能以辅助的面貌出现。

类测试方案设计

各类测试设计方案为黑盒测试，根据用户实际情况输入测试数据，数据应具有一定

要求，来测试软件功能是否可控，将测试数据输入功能模块，查看其结果数据，对比功

能需求检验结果数据是否符合用户需求且是否正确。同时在输出测试数据时，可进行恶

性输入，来测试软件功能是否可用。

提交用例输入测试方案

提交用例输入首先需要首先输入各个类所需信息，信息或为可选项或固定项，手工

输入。

提交用例输出结果预测

信息填写准确无误后，确认提交，提交成功后，任务流转填写激活。

提交用例测试结果预测

填写无误相关信息后，设置任务流转，任务将进入工作流进行工作，用户打开工作

台，可在任务列表中找到填写的项目任务。并在工作流中流动。

测试记录

⑴提交项目成功。

⑵开评标信息，开评标文件表、招投标分包信息、任务流转TAB页激活。

⑶任务流转提交成功。

⑷项目进入工作台，在工作流中流转。

结果分析

用例结果均为正确输出结果，测试功能无误。

用例测试

用例测试方案设计

表7-1 进货管理用例测试

Table 7-1 entersmanagement cases to test

测试用例：进货管理用例

测试目的：测试系统对进货管理是否正确可用。

测试设计：⑴在登录页点击注册，填写注册基本信息，登录系统。

⑵查看缺货消息。

⑶查看供应商消息。

⑷制定订货单。

⑸发送订单。

预期结果：成功注册登录，能查到缺货消息、供应商信息，能制定订货单，成功发送订

货单。

实测结果：注册登录成功，查看缺货消息、供应商消息成功，发送订货单成功。

实测结果分析：符合正常需求功能。

测试结论：功能正常。

表7-2 销售管理用例测试

Table 7-2 sells management test

测试用例：销售管理管理用例

测试目的：测试系统能否正确进行销售管理。

测试设计：查看家具信息，查看库存信息，制定顾客订单，发送顾客订单。

预期结果：能查看家具信息、库存信息，能制定顾客订单，能发送顾客订单。

实测结果：成功查看家具信息、库存信息，成功制定顾客订单，成功发送顾客订单。

实测结果分析：符合正常需求功能。

测试结论：功能正常。

表7-3 仓库管理用例测试

Table 7-3 warehouse management cases to test

测试用例：仓库管理用例

测试目的：测试仓库管理能否正确进行。

测试设计： 整理库存信息，发送缺货消息，查看送货消息。

预期结果：能整理库存消息，能发送缺货消息，能查看送货消息。

实测结果：成功整理库存消息，成功发送缺货消息，成功查看送货消息。

实测结果分析：符合正常需求功能。

测试结论：功能正常。

表7-4 财务管理用例测试

Table 7-4 finance management use case testing

测试用例：财务管理用例

测试目的：测试财务管理是否正确进行。

测试设计：查看顾客订单，发送送货单，查看订货单，查看货到消息。

预期结果：能查看顾客订单，能发送送货单，能查看订货单、货到消息。

实测结果：成功查看顾客订单，成功发送送货单，成功查看订货单、货到消息。

实测结果分析：符合正常需求功能。

测试结论：功能正常。

公共资源交易管理系统测试结论

系统功能一切正常，无发现重要错误以及功能性错误，可投入正常使用。

软件能力

软件为公共资源交易中心工作人员提供网络数字化办公环境，节省人力物力资源，

提供工作效率，保证数据完整性，安全性。

软件体统炫酷桌面页面效果，便捷操作，简单灵活。

软件提供自身维护设置功能，无需开发人员干预。

软件体统数据维护，数据可靠安全性支持。

软件缺陷

⑴软件无没有实现产品规格说明所要求的功能模块缺陷。

⑵软件无实现了产品规格说明没有提到的功能模块缺陷。

⑶软件无没有实现虽然产品规格说明没有明确提及但应该实现目的缺陷。

⑷软件中无出现了产品规格说明指明不应该出现的错误缺陷。

⑸软件无难以理解,不容易使用,运行缓慢,或从测试员的角度看,最终用户会认为不

好。

软件限制

软件前台环境必须使用Google游览器访问。

软件支持ORACLE数据，最好将数据库与软件程序分别部署。

软件功能只适用公共资源交易中心工作人员使用。

参考文献

[1] Oracle,数据库管理与应用，王永贵 徐州：中国矿业大学出版社, 2009-08

[2] 数据库系统概论.王珊,萨师煊 北京：高度教育出版社,2006-05

[3] 软件工程导论 张海籓 北京： 清华大学出版社,2008-02

[4] (C#)程序开发 基础教程与实验指导 邵良杉,刘好增，马海军等 北京:, 2012-

03

[5] Abraham Silberschatz着.Database System Concepts.机械工业出版社， 1999

[6] 陈荣秋.马士华.生产运作管理.高等教育出版社.1999年8月

[7] 陈月波.电子商务解决方案.电子工业出版社.2004年2月

[8] 曹军.管理信息系统.清华大学出版社.1999年6月