nodejs汽车维修系统python-flask-django

汽车维修管理系统的设计与实现
摘 要
 
目前在本课题范围内，分析了汽车维修管理人员对汽车的管理现状和现有的用户对汽车维修管理人员的服务的要求。针对两者的要求，设计了一套基于nodejs的汽车维修管理系统。本系统的集成开发环境是Eclipse，使用MySQL作为数据库管理系统，Web服务器采用Tomcat，为了充分利用网络信息化的优势，本系统采用B/S结构。系统具有专门的供用户使用的前台和专门供汽车维修管理人员使用的后台。汽车维修管理系统，首页展示汽车维修管理系统的欢迎界面，管理员对车辆进行管理、查看、修改等操作，车辆对自己信息进行查看、修改等操作，对于用户而言可体验日常汽车管理的流程以及在线查询汽车的信息。随着计算机技术的高速发展，现代计算机系统已经从以计算为中心向以信息化处理为中心的方向发展。而汽车维修，不仅需要在硬件上为现代社会的人们提供一个汽车维修的平台，获取汽车知识的环境，更要在软件上为车辆提供汽车维修的服务。于是汽车维修管理系统便应运而生。
在汽车维修管理系统的实现下，汽车维修管理人员能够充分发挥信息化处理的优势，提高日常管理的处理速率。用户一方可以更好的享受信息化处理带来的便利。系统运行能够稳定且高效。并且人机友好程度能够显著提升。
前端技术：nodejs+vue+elementui,
Express 框架于Node运行环境的Web框架,
语言 node.js
框架：Express
前端:Vue.js
数据库：mysql
数据库工具：Navicat
开发软件：VScode
视图层其实质就是vue页面，通过编写vue页面从而展示在浏览器中，编写完成的vue页面要能够和控制器类进行交互，从而使得用户在点击网页进行操作时能够正常。

代码结构讲解
 1、 node_modules文件夹(有npn install产生)
    这文件夹就是在创建完项目后，cd到项目目录执行npm install后生成的文件夹，下载了项目需要的依赖项。
2、package.json文件
     此文件是项目的配置文件（可定义应用程序名，版本，依赖项等等）。node_modules文件夹下的依赖项是从哪里知道的呢？原因就是项目根目录下的这个package.json文件，执行npm install时会去找此文件中的dependencies，并安装指定的依赖项。
3、public文件夹(包含images、javascripts、stylesheets)
      这个文件夹做过Web开发的应该一看就知道，为了存放图片、脚本、样式等文件的。
4、routes文件夹
      用于存放路由文件。
5、views文件夹
      存放视图。  
 

第1章 项目概述
1.1 问题描述
目前现有的汽车维修管理系统对于用户而言其维修业务流程仍然过于繁琐，对于汽车维修而言其系统安全性并不能保障。同时整套系统所使用的技术相对较为落后，界面不能动态化展示。相比较于其它同类型网站而言不能体现技术先进性。
1.2 项目目标

本系统主要针对现在汽车维修管理系统中存在的问题，对需要改进的地方进行系统分析，对系统所要实现的功能进行完善，使得其更具有高度界面友好的特性。提出对于系统而言具备可行性的方案，做好系统分析。编译出界面友好，功能齐全的汽车维修管理系统。
1.3 项目适用范围
该项目的前台适用于普通用户，后台适用于汽车维修管理人员。
1.4 项目应遵守的规范与标准
为了信息传输的安全性，与数据库进行交互的情况下，重要的信息比如“用户密码”，一律用密文传输。
目 录
摘 要 I
Abstract II
第1章　项目概述 1
1.1 问题描述 1
1.2 项目目标 1
1.3 项目适用范围 1
1.4 项目应遵守的规范与标准 1
1.5 涉众 1
第2章　需求分析 2
2.1 业务需求 2
2.1.1 业务流程 2
2.1.2 业务对象 4
2.2 功能性需求 4
2.2.1 用例概述 4
2.2.2 用例细化描述 5
2.3 非功能性需求 11
2.4 运行环境 11
第3章　系统设计 13
3.1 技术路线 13
3.2 软件体系结构设计 14
3.2.1 功能结构 14
3.2.2 系统架构 14
3.3 数据库设计 15
3.3.1 概念结构设计 15
3.3.2 表的详细设计 16
第4章　系统实现 29
4.1 核心功能实现 29
4.2 关键技术难点与解决方案 32
4.3 编码规范 33
第5章　系统测试 34
5.1 功能测试 34
5.2 测试总结 36
第6章　结论与展望 38
参考文献 39
致 谢 401.5 涉众
在本系统中，涉及到的人员有汽车维修管理人员和用户。
对于汽车维修管理人员，其使用习惯是偏向于实用性和安全性。希望该系统能够高度安全，并且能够正常实现汽车维修管理业务的各项功能。
对于用户而言，其更倾向于界面友好性和便捷性。不仅希望系统能动态展示，还希望系统能够做到“一步到位”，其希望能实现的功能除了正常的汽车维修业务以外还希望能够网上维修业务的服务。
 图2.5 高层用例图
图2.5之间的用例标识、用例名称和摘要描述如表2.1所示。
表2.1 用例摘要描述
用例标识（UC） 用例名称 摘要描述
0 登录 使用系统前的身份验证。
1.1 更改密码 用户可以在系统上更改密码。
1.2 查看维修单信息 用户可以查看维修单信息，并可以获得包括维修名、价格、编号等信息。
2.1 管理用户信息 汽车维修管理人员可以管理用户的信息
2.2 管理库存信息 汽车维修管理人员可以管理库存的信息
2.3 管理供应商信息 汽车维修管理人员可以管理供应商的信息
2.4 管理维修师信息 汽车维修管理人员可以管理维修师的信息。
2.5 管理入库信息 汽车维修管理人员可以管理入库的信息。
2.6 管理维修项目信息 汽车维修管理人员可以管理维修项目的信息

2.2.2 用例细化描述
（1）管理用户信息用例
汽车维修管理人员可以通过管理用户信息用例对用户信息进行维护，包括对用户信息的增删改查。管理用户信息用例图如图2.6所示。

图2.6 管理用户信息用例图
添加用户信息用例中描述如表2.2所示。
表2.2 添加用户信息用例表
用例标识 2.1.1
用例名称 添加用户信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在用户表中添加一条用户信息。
用例概述 汽车维修管理人员可以对用户信息进行添加。
基本事件流 1. 汽车维修管理人员在管理用户主界面选取添加用户信息项。
2. 系统显示添加用户界面。
3. 汽车维修管理人员按照用户提供的信息输入用户姓名、用户密码、用户性别、用户电话后，提交添加请求。
4. 系统检查输入信息的有效性。
5. 系统查询结果确认没有重复姓名，将录入用户信息到用户信息表中。
6. 系统显示添加用户成功。
备选事件流 5a 系统查出有重复姓名，将显示添加用户失败，管理员重新输入另一名称，系统查出没有重复姓名，显示添加用户成功。
备注 用户编号生成
更改用户信息用例描述如表2.3所示。
表2.3更改用户信息用例表
用例标识 2.1.2
用例名称 更改用户信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在用户表中更改一条用户信息。
用例概述 汽车维修管理人员可以对用户信息进行更改。
基本事件流 1. 汽车维修管理人员在管理用户主界面选取更改用户信息项。
2. 系统显示更改用户界面,并将用户信息显示齐全。
3. 汽车维修管理人员按照用户提供信息更改用户信息，提交更改请求。
4. 系统检查输入信息的有效性。
5. 系统根据查询结果确认没有重复姓名，将更改用户信息表中的记录。
6. 系统显示更改用户成功。
备选事件流 5a 系统查出有重复姓名，将显示更改用户失败，管理员重新输入另一名称，系统查出没有重复姓名，显示更改用户成功。
备注 无
删除用户信息用例描述如表2.4所示。
表2.4删除用户信息用例表
用例标识 2.1.3
用例名称 删除用户信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在用户表中删除用户信息。
用例概述 汽车维修管理人员可以对用户信息进行删除。
基本事件流 1. 汽车维修管理人员在管理用户主界面选取删除用户信息项。
2. 系统显示是否删除用户，汽车维修管理人员选择删除。
3. 系统删除用户信息表中相对应的用户信息。
4. 系统显示删除用户成功。
备选事件流 2a 系统显示是否删除用户，管理人员选择不删除。系统不改变
备注 无
搜索用户信息用例描述如表2.5所示。
表2.5搜索用户信息用例表
用例标识 2.1.4
用例名称 搜索用户信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在用户表中搜索用户信息。
用例概述 汽车维修管理人员可以搜索用户信息。
基本事件流 1. 汽车维修管理人员在管理用户主界面选取搜索用户信息项。
2. 系统显示搜索用户页面。
3. 汽车维修管理人员输入用户个别信息，并进行搜索。
4. 系统根据输入的信息，返回搜索结果。
备选事件流 4a 系统根据输入结果搜索不到结果，在主页面显示搜索不到结果。
备注 无
（2）管理维修项目信息用例
汽车维修管理人员可以通过管理维修项目信息用例对维修项目信息进行维护，包括对维修项目信息的增删改查。管理维修项目信息用例图如图2.7所示。

图2.7 管理维修项目信息用例图
其添加维修项目信息用例的描述如表2.6所示。
表2.6 添加维修项目信息用例表
用例标识 2.4.1
用例名称 添加维修项目信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在维修项目表中添加一条维修项目信息。
用例概述 汽车维修管理人员可以对维修项目信息进行添加。
基本事件流 1. 汽车维修管理人员在管理维修项目主界面选取添加维修项目信息项。
2. 系统显示添加维修项目界面。
3. 汽车维修管理人员输入维修项目名称、维修项目简介后，提交添加请求。
4. 系统检查输入信息的有效性。
5. 系统根据查询结果确认没有重复维修项目名，将维修项目信息录入到维修项目信息表中。
6. 系统显示添加维修项目成功。
备选事件流 5a 系统查出有重复书记类别名称，将显示添加维修项目失败，管理员重新输入另一名称，系统查出没有重复维修项目，显示添加维修项目成功。
备注 维修项目编号生成
更改维修项目信息用例描述如表2.7所示。
表2.7 更改维修项目信息用例表
用例标识 2.4.2
用例名称 更改维修项目信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在维修项目表中更改一条维修项目信息。
用例概述 汽车维修管理人员可以对维修项目信息进行更改。
基本事件流 1. 汽车维修管理人员在管理用户主界面选取更改维修项目信息项。
2. 系统显示更改维修项目界面,并将维修项目信息显示齐全。
3. 汽车维修管理人员更改维修项目信息，提交更改请求。
4. 系统检查输入信息的有效性。
5. 系统根据查询结果确认没有重复维修项目名称，将更改维修项目信息表中信息。
6. 系统显示更改维修项目成功。
备选事件流 5a 系统查出有重复维修项目名称，将显示更改维修项目失败，管理员重新输入另一名称，系统查出没有重复维修项目名称，显示更改维修项目成功。
备注 无
删除维修项目信息用例描述如表2.8所示。
表2.8删除维修项目信息用例表
用例标识 2.4.3
用例名称 删除维修项目信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在维修项目表中删除维修项目信息。
用例概述 汽车维修管理人员可以对维修项目信息进行删除。
基本事件流 1. 汽车维修管理人员在管理维修项目主界面选取类别后删除维修项目信息项。
2. 系统显示是否删除维修项目，汽车维修管理人员选择删除。

续表2.8删除维修项目信息用例表
基本事件流 3. 系统检查供应商分类下是否有供应商
4. 系统确认供应商分类下无供应商，将删除维修项目信息表中指定信息。
5. 系统显示删除供应商分类成功。
备选事件流 1a 选取不同类别，选择批量删除
2a 系统显示是否删除维修项目，汽车维修管理人员选择不删除。系统不改变
4a 系统确认供应商分类下有供应商，显示因分类下有供应商，删除失败。
备注 无
（3）管理供应商信息用例
汽车维修管理人员可以通过管理供应商信息用例对维修项目信息进行维护，包括对供应商信息的增删改查。管理供应商信息用例图如图2.8所示。

图2.8 管理供应商信息用例图
新增供应商信息用例描述如表2.9所示。
表2.9 新增供应商信息用例表
用例标识 2.5.1
用例名称 新增供应商信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在供应商表中添加一条供应商信息。
用例概述 汽车维修管理人员可以对供应商信息进行添加。
基本事件流 1. 汽车维修管理人员在管理供应商主界面选取添加供应商信息项。
2. 系统显示新增供应商界面。
3. 汽车维修管理人员输入供应商名称、供应商地址、联系电话、供应商内容、负责人，提交添加请求。
4. 系统检查输入信息的有效性。
5. 系统根据查询结果确认没有重复供应商名称，将信息录入到供应商信息表中。
6. 系统显示添加供应商成功。
备选事件流 5a 系统查出有重复供应商名称，将显示添加供应商失败，管理员重新输入另一名称，系统查出没有重复供应商名称，显示添加供应商成功。
备注 供应商编号生成
图3.3 系统概念模型ER图
3.3.2 表的详细设计
通过对汽车维修管理系统在需求分析中的领域对象、业务对象及对象之间的分析，进行了对汽车维修管理系统的数据库建表设计。如表3.1-表3.6 所示。汽车维修管理系统数据库管理部分采用MySQL。
（1）管理人员信息表(admin)
管理人员信息表主要用于保存汽车维修管理人员的信息，主要字段包括：管理人员ID、登录账号、登录密码。表结构如表3.1所示。
表3.1 管理人员信息表（admin）
列名 数据类型 长度 允许空 是否主键 说明
userid varchar 32 否 是 汽车维修管理人员ID
username varchar 50 否 否 登录账号
password varchar 100 否 否 登录密码
（2）车辆信息表(user)
车辆信息表主要用于保存用户的信息，主要字段包括：用户ID、用户名称、用户登录密码、用户性别、用户电话。表结构如表3.2所示。
表3.2 车辆信息表（user）
列名 数据类型 长度 允许空 是否主键 说明
Id varchar 32 否 是 用户ID
name varchar 100 否 否 用户名
username varchar 32 否 否 用户登录名
pwd varchar 100 否 否 密码
sex varchar 100 否 否 性别
tel varchar 100 否 否 手机
chepai varchar 100 否 否 车牌
beizhu varchar 100 否 否 备注
chexing varchar 100 否 否 车型
（3）供应商信息表(gys)
供应商信息表主要用于保存供应商的信息，主要字段包括：供应商ID、供应商名称、供应商地址，联系电话。表结构如表3.3所示。
表3.3 供应商信息表（gys）
列名 数据类型 长度 允许空 是否主键 说明
id varchar 32 否 是 ID
name varchar 100 否 否 供应商名称
addr text 0 是 否 供应商地址
tel varchar 100 否 否 联系电话
fuzren varchar 100 否 否 负责人
beizhu varchar 100 否 否 备注
（4）维修项目出库信息表(chuku)
维修项目出库信息表主要用于保存维修项目出库的信息，主要字段包括：ID、维修项目、维修单号、维修项目、维修项目编号、维修项目名称、维修项目供应商、单价。表结构如表3.4所示。
表3.4 维修项目出库信息表（chuku）
列名 数据类型 长度 允许空 是否主键 说明
id varchar 32 否 是 ID
pinfo varchar 32 否 否 维修项目
wx varchar 100 否 否 维修单号
xm varchar 100 否 否 维修项目
bh varchar 100 否 否 维修项目编号
name text 0 否 否 维修项目名称
gys date 0 否 否 维修项目供应商
jiage varchar 100 否 是 单价
wnum varchar 100 否 是 数量
uname varchar 100 否 是 经手人
sdate varchar 100 否 是 出库日期
（5）维修项目信息表(book_article)
维修项目信息表主要用于保存维修项目的信息，主要字段包括：维修项目ID、维修项目名称、维修项目编号。表结构如表3.5所示。
表3.5 维修项目信息表（book_article）
列名 数据类型 长度 允许空 是否主键 说明
Id varchar 32 否 是 ID
name varchar 100 否 否 维修项目名称
bianhao varchar 100 否 否 维修项目编号
jiage varchar 100 否 否 维修项目价格
gys varchar 100 否 否 供应商
（6）入库信息表(ruku)
入库信息表主要用于保存入库的信息，主要字段包括：ID、维修项目、名称、编号、价格。表结构如表3.6所示。
表3.6 入库信息表（ruku）
列名 数据类型 长度 允许空 是否主键 说明
Id varchar 32 否 是 ID
pinfo varchar 100 否 否 维修项目
name varchar 15 否 否 名称
bk varchar 100 否 否 编号
jiage varchar 10 否 否 价格
kucun varchar 10 否 否 数量
sdate varchar 10 否 否 入库日期

第4章 系统实现
4.1 核心功能实现
在汽车维修管理系统中，核心业务用例的实现效果如下所示。
（1）登陆注册模块实现
管理员通过点击后台管理，进入页面可以输入账号、密码、验证码进行登录相对应操作，
 
更改供应商信息用例描述如表2.10所示。
表2.10更改供应商信息用例表
用例标识 2.5.2
用例名称 更改供应商信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在供应商表中更改一条供应商信息。
用例概述 汽车维修管理人员可以对供应商信息进行更改。
基本事件流 1. 汽车维修管理人员在管理供应商主界面选取更改供应商信息项。
2. 系统显示更改供应商界面,并将供应商信息显示齐全。
3. 汽车维修管理人员更改供应商信息，提交更改请求。
4. 系统检查输入信息的有效性。
5. 系统根据查询结果确认没有重复供应商名称，将更改供应商信息表中的记录。
6. 系统显示更改供应商成功。
备选事件流 5a 系统查出有重复供应商名称，将显示更改供应商失败，管理员重新输入另一名称，系统查出没有重复供应商名称，显示更改供应商成功。
备注 无
删除供应商信息用例描述如表2.11所示。
表2.11 删除供应商信息用例表
用例标识 2.5.3
用例名称 删除供应商信息
参与者 汽车维修管理人员
前置条件 已经以汽车维修管理人员身份登录。
后置条件 在供应商表中删除供应商信息。
用例概述 汽车维修管理人员可以对供应商信息进行删除。
基本事件流 1. 汽车维修管理人员在管理供应商主界面选取供应商后选择删除供应商信息。
2. 系统显示是否删除供应商，汽车维修管理人员选择删除供应商。
3. 系统删除供应商信息表中的相对应的供应商信息。
4. 系统显示删除供应商成功。
备选事件流 1a 选取不同供应商后，选择批量删除
2a 系统显示是否删除供应商，管理人员选择不删除。系统不改变
备注 无
2.3 非功能性需求
安全性：用户信息具有保密性，用户信息只能由汽车维修管理人员控制更改使用，用户注册也只能在汽车维修管理人员处进行注册登记。
正确性：不允许出现业务错误。
兼容性：可在各种支持HTML5的浏览器中使用。
性能：系统处理业务时页面响应时间不能超过2秒，在繁忙时间最多不能超过6秒。
并发性：允许多个用户用户登录操作。
2.4 运行环境
汽车维修管理系统运行需要的硬件环境如下
（1）主机类型
系统主机服务器：DELL PowerEdge R630，四核CPU，8G RAM
数据库服务器：HP DL388 Gen9，四核CPU，8G RAM
用户用PC机：任意可联网设备
（2）网络类型
以太网
（3）存贮器容量
系统主机服务器：200G以上
数据库服务器：1000G以上
（4）设备分布图
设备分布图如图2.9所示。

图2.9 设备分布图
汽车维修管理系统运行所需的软件环境如下。
（1）操作系统：
应用服务器：Windows NT Server 2008以上版本
用户用PC机：windows XP和以上
（2）数据库管理系统：
MySQL 5.0.27
（3）网页浏览器：
应用服务器：Google Chrome
用户用PC机：Google Chrome或者Firefox
（4）开发环境：
IDE采用Eclipse Java EE IDE Luna（4.4.1）
（5）数据库管理工具：
Navicat Premium 10.0.9
（6）运行环境：
Tomcat 7.0 + Apache
第5章 系统测试
汽车维修管理系统的测试是和系统开发同步进行的，因此在需求阶段测试人员就已经对需求阶段的各个指标进行了相对应的验证测试，在系统开发过程中进行单元测试，在系统开发完成后针对性能、功能性和可用性进行系统测试。限于篇幅所限，下面主要围绕功能测试用例和测试总结两个方面进行说明。
5.1 测试目的
在本系统的测试中，主要对各个的功能模块进行测试，在测试的过程之中，为了更好的测试出系统功能的关键功能和不足之处，必须设置出针对系统的各项功能特定的测试方式方法，通过特定的测验，来检查所设计的在线投票系统是否符合开始所设计所有功能，并且在发现出错时对发生错误的地方进行修正，保证系统的运行。。
5.2 软件测试的方式
(1)功能测试：功能测试，顾名思义就是为了测试功能是否存在缺陷，有没有出现链接没有实现，是否出现表单没有提交成功，以及数据库是否能够连上等等，这些都是常规的功能测试内容。
(2) 性能测试：性能测试首先要测试性能是否正常，比如反应速度是否正常，如果客户访问非常慢的话，用户体验将会非常糟糕，这个工作也很重要。
(3)兼容性测试：我们都知道，在系统开发完成以后，要进行多平台的兼容性测试，比如火狐浏览器，谷歌浏览器，微软浏览器，浏览器有多个不同的版本，就需要进行多方面的测试，因为不同的版本可能会出现不同的结果，为了使它们能够在这个系统上面都可以正常使用，就需要进行兼容性测试。
(4) 安全测试：系统测试的最后一步是进行安全性测试，系统开发以后，为了确保运行正常，以及后台的正常使用，确保数据的安全，防止黑客攻击，防止数据库的注入，以及是否存在漏洞，这些都要进行安全性测试，不然一旦数据被黑客攻击，就将对整个系统造成影响，甚至造成数据的泄漏。
5.3 测试分析
经过对系统进行有效的测试和修改，保证系统具备较好的稳定性和可用性。测试结束后，在测试总结中通过按等级统计、按类型统计对测试情况进行了客观的统计和分析，具体如图5.1-5.2所示。

按等级统计bug的结果，如图5.1所示。

图5.1 按等级统计bug数
按类型统计bug的结果，如图5.2所示。

图5.2 按类型统计bug数

经过开发人员对bug进行有效的修改，保证了系统具备较好的稳定性和可用性。经过一系列测试，本软件的各项功能基本实现但是在涉及到一些细节，比如数据唯一性，安全性等存在漏洞，在软件性能方面，数据量过大软件运行会非常吃力，可用性方面不太适用于偏大型的公司数据管理。
5.4 测试总结
在开发期间采用的是边开发边测试的方式，使得开发周期和测试周期同步。经检测，在最后的系统测试期间，全部bug数为320个，在开发阶段的bug就有280个。在最后测试阶段的bug则只有40个。通过开发和测试共同进行的方式，最终保证系统能够具有较高的稳定性。同时通过不断的版本控制，使得系统具备较好的可用性。
系统在功能性上由于新技术所造成的不稳定性，导致了新技术所带来的功能性bug较多。但性能bug则很少，另外经过多次改进，新技术造成的错误数大幅度减少。

第6章 结论与展望
在这近几个月的不断的努力中，汽车维修管理系统终于圆满完成。这套系统具有很多优点，不仅能完成日常库存管理的，还可以对汽车维修的业务进行扩展。不过在本项目完成的同时，由于时间短，项目紧促，造成了该系统也有很多不足的地方。整个项目仍有改进的空间。具体的改进如下：
（1）优点
本项目的优点在于项目前后台分离，各自负责不同的部分。同时还应用了较为新颖的技术。项目运用了SmartAdmin，使项目能有较高的易用性，其强大的UI库保证了界面的美观程度。页面加载部分使用Ajax方法，使得页面能够动态显示各种信息。在信息传输上使用MD5加密技术，增强信息传输的安全性。
（2）缺点
本项目的缺点在于由于只有一个人完成整个项目，以此来计算的情况下完成整套系统的时间显得非常仓促。在需求调研阶段就调研结果而言并不能高度满足于现有系统真正所需要的要求。另外在项目中，并没能很好的完全分离前后台，这一点还有待加强学习。同时，项目中由于SmartAdmin的UI库信息量非常多，其显示的并不一定是最符合其位置的UI样例。
对于汽车维修管理系统的缺点的相对应改善计划是，理清前后台的业务逻辑，使之能够做到前后台分离。而SmartAdmin中我们可以通过加强对JQuery的使用对其进行补充。使得项目能够有更好的易用性。针对SmartAdmin UI库过多的问题，可以对其进行库设计，从而达到快速引用的设计。
通过这几个月的不断努力和学习，最终独立的完成了整个项目。对此有很多的感触。项目中应用到了不少的新技术。有很多都不在学校的课堂中学习到而是通过不断的实践获得的。有很多的知识通过在公司的实习和在对技术的应用中获得，而这些知识将全部应用在汽车维修管理系统这个项目上来。随着技术的进步，我们还需要不断的学习与探索，会有更好的天地等着我们去实现。
 

致 谢
在系统全部完成之际，我非常感谢在毕业设计时给予我帮助的人。没有他们的帮助，就没有我能够顺利的完成毕业设计。
首先，我要感谢我的指导教师老师，这几个月来，老师为我们付出了很多的努力，针对我们的系统和论文进行了非常细心的指导。根据毕业设计期间的要求和政策对我提出了不少的意见和建议。在她的建议下我能够圆满完成我的毕业设计任务。对此再次表示衷心的感谢。
其次我需要感谢的是我的父母，在整个毕业设计期间，是我的父母，作为在毕业设计期间最强有力的后盾，我可以全身心的去关注、去撰写我的毕业设计论文。在大学生活中我的每时每刻都离不开来自于我的父母的全力支持和关心。
之后，我要感谢的是全体软件工程系的大力协助，在大学的四年间，您们严谨的教学态度和科学的工作方法对我们的成长有很重要的影响。没有您们为我们无私的传授知识和获取知识的方法，就没有我们能够在软件行业立足的基础。
最后我要感谢的，是我们的学校。“精勤博学，学以致用。”这个校训一直陪伴了我在大学的时光。不仅教育我们知识，对我们的思想道德的培养更多。使我们不仅能够做一名合格的大学生，更能在走出校园时，能够成为一名合格的社会人。