计算机毕业设计 asp.net汽车中心销售管理系统 毕设

https://www.bilibili.com/video/BV1PJ4m1a7r7/

演示视频：

3.1系统分析的任务与步骤

3.1.1 系统分析的任务

了解用户要求。此用户即为系统的使用人员（管理员，用户）。了解他们在系统功能、性能等方面的要求及用户在硬件配置、开发周期处理方式等方面的意向与打算。把用户要求成文，完成系统分析报告。系统的逻辑模型由一系列的图表和文字组成。在逻辑上描述了系统的目标和所具备的功能于性能。

3.1.2 系统分析的步骤

1. 描述系统。在详细调查的基础上，用一定的图标、文字描述;

2. 分析用户新的要求，改进现行模型，形成新系统的逻辑模型。

3. 编写系统分析说明书。

3.2系统项目范围

焦作全达汽车销售管理系统从管理员用户角度进行功能划分。

1、系统管理：该模块主要是让超级管理员可以添加系统中的普通管理员来共同管理本系统。。

2、销售管理：可根据客需求，添加，查询销售记录，包括编号，名称，电话，地址，负责人，价格等。

3、订单管理：可管理订单信息，添加，查询，修改，删除等操作，包括车架代号，品牌子，车型，颜色，排量，换档方式，价格，图片，等。

4、汽车信息管理：包括编号,价格,图片,大小, 查询，修改，删除等操作等

5．用户管理：用户工添加，查询等操作，包括用户名，姓名，性别，电话，身份证，地址，出生年月，照片，密码等,

6、数据备份：数据保存，以防丢失。

3.4对性能的规定

3.4.1 精度

（1）、在执行数据增加的时候，不允许出现因为程序的原因导致增加操作失败，也不允许发生重复增加的数据；

（2）、在执行数据删除操作的时候，不允许因为程序的原因发生多删除数据、删除失败的情况；

（3）、数据的修改也要求保持对应的准确性；

（4）、每月要求的额外的数据存储空间为15M。

并且，所有数据采用集中式存储，数据位于数据库服务器上。数据库要有安全保障性能，必须只有授权的用户才能操作。

3.4.2  时间特性要求

在用户执行增加修改和删除操作的时候，在运行环境规定的条件下，单次操作的响应时间要求在2秒钟之内。

返回100行数据以内的数据查询，单次操作的响应时间要求在2秒之内。

3.4.3  灵活性

（1）、操作方式：

程序在通常的应用环境下使用鼠标和键盘进行输入和输出操作，对于执行按钮，通常使用鼠标的点击完成，但是，界面要求全部支持键盘的定位操作（在不安装鼠标的计算机上，也能够使用该系统）。

（2）、运行环境：

程序在通常的条件下，在Win98/NT/2000上安装运行，但是，还要求能够在XP及后续的MS的操作系统上运行。

系统要求能够在Win95的操作系统上安装和运行。

（3）、同其他软件的接口的变化：

（不适用）

（4）、精度和有效时限的变化：

（不适用）

（5）、计划的变化或改进：

由于本系统的规模比较小，计划和进度的改变不影响到需要实现的需求。

3.5 故障处理要求

（1）、在操作成员输入一些不合理的数据的时候，能够进行一些合理的提示信息，不能因为输入错误而导致系统的错误，或者程序停止运行；

（2）、程序运行时，对服务器和网络通信故障能够识别并提示，当故障排除后，程序恢复正常运行；

（3）、数据库要求有灾难备份机制，以防止数据的全部丢失。

3.6 其他专门要求

1、可扩充性：系统在开发完毕以后，应允许进行功能的扩展或者功能的重新解释和实现。

2、健壮性：系统应该保证在一次开机三个月之内稳定运行，数据库在一些灾难事故中能够在系统安装好之后，两小时内恢复。

3.7系统的数据库设计

3.7.1 概念设计    

在概念设计阶段中，从用户的角度看待数据及处理要求和约束，产生一个反映用户观点的概念模式。然后再把概念模式转换成逻辑模式。将概念设计从设计过程中独立开来，使各阶段的任务相对单一化，设计复杂程度大大降低，不受特定DBMS的限制。利用ER方法进行数据库的概念设计，可分成三步进行：首先设计局部ER模式，然后把各局部ER模式综合成一个全局模式，最后对全局ER模式进行优化，得到最终的模式，即概念模式。

3.7.1.1 设计局部ER模式
 1实体和属性的定义：

1）管理员用户类别（用户名，密码，权限，注册时间等）

图3-5-1管理员用户实体与属性的定义

2）用户类别（工号，姓名，性别，电话，身份证，地址，出生年月，照片，月薪，密码等）

图3-5-2用户信息实体与属性的定义

3）汽车信息类别（编号，名称，电话，地址，负责人，网址等）     

图3-5-3 汽车信息实体与属性的定义

2 实体关系定义：

ER模型的“联系”用于刻画实体之间的关联。一种完整的方式是对局部结构中任意两个实体类型，依据需求分析的结果，考察局部结构中任意两个实体类型之间是否存在联系。若有联系，进一步确定是1:1、1:N、M:N的关系。还要考察一个实体类型内部是否存在联系，两个实体类型之间是否存在联系，多个实体类型之间是否存在联系，等等针对本系统分析如下：

1. 一个管理员一次可以管理汽车信息，而一道汽车销售业务管理只可以被一个管理员布置

图3-5-9管理员与用户管理 1:N（一对多的关系）

3.7.1.2设计全局ER模式
   所有局部ER模式都设计好了后，接下来就是把它们综合成单一的全局概念结构。全局概念结构不仅要支持所有局部ER模式，而且必须合理地表示一个完整、一致的数据库概念结构。
1) 确定公共实体类型
   为了给多个局部ER模式的合并提供开始合并的基础，首先要确定各局部结构中的公共实体类型。在这一步中我们仅根据实体类型名和键来认定公共实体类型。一般把同名实体类型作为公共实体类型的一类候选，把具有相同键的实体类型作为公共实体类型的另一类候选。
2) 局部ER模式的合并
   合并的原则是：首先进行两两合并；先合并那些现实世界中有联系的局部结构；合并从公共实体类型开始，最后再加入独立的局部结构。
3) 消除冲突
   冲突分为三类：属性冲突、结构冲突、命名冲突。
   设计全局ER模式的目的不在于把若干局部ER模式形式上合并为一个ER模式，而在于消除冲突，使之成为能够被所有用户共同理解和接受的同一的概念模型。
4) 全局ER模式的优化
   在得到全局ER模式后，为了提高数据库系统的效率，还应进一步依据处理需求对ER模式进行优化。一个好的全局ER模式，除能准确、全面地反映用户功能需求外，还应满足下列条件：实体类型的个数要尽可能的少；实体类型所含属性个数尽可能少；实体类型间联系无冗余。

3.8系统的结构图

第5章 详细设计

3.1前台页面

5.1.1首页

此页面为网站首页，上面的导航栏有站内新闻，汽车查询,，用户注册，留言板，后台管理等功能。下面还有系统公告，友情链接等。

5.1.2站内新闻页面

此页面为站内新闻，可随时了解最新的新闻，双击可查看详细内容，

 

5.1.3用户注册页面

此页面为用户注册，包括用户名，密码，姓名，电话，邮箱，QQ，头像，籍贯，地址，性别，等

5.1.4汽车查询页面

此页面为汽车查询,可按编号,或者名称查询,,,点详细出现了以下页面

包括编号,名称,价格,类别,图片,库存,发布人等,也可以购买.

3.2 后台管理

5.2.1登录界面

图5-1-1系统首页

5.1.2 焦作全达汽车销售管理系统首页界面说明

本模块是系统登陆界面，实现的功能是检测合法用户，验证其用户名密码，以杜绝非法用户侵入系统。

本模块界面非常简单，就一用户名和密码两个文本框和一个登陆按钮，但实现的方法比较复杂，因为系统要自动判断其输入的用户名及密码的正误，还要自动识别其权限（超级管理员与普通管理员之分），如果登陆正常后，系统要将当前用户名和权限记录下来以便之后其他操作给予适当的权限分配。

实现本模块的主要代码如下所示：

 

5.2.1主操作界面

图5-2-1 系统主操作页面

5.2.2系统主操作界面说明

该界面是系统登陆后的第一个界面，也是系统操作的主界面，除了登陆模块之外，其他后台操作均在本平台上进行。

本界面是由一个框架组成，包括上左右三大块。左边是一个菜单列表，单击菜单时右边显示主模块页，操作非常简单明了。

3.3管理员信息管理界面

管理员可以进行密码修改、用户信息管理等操作。这里重点介绍下达任务界面。

5.3.1 管理员密码修改界面

 

图5-3-1管理员信息管理界面

5.3.2管理员管理界面说明

该界面的功能是让管理员用户录入管理员相关信息管理的信息，并读入数据库相应的表。

其他相应功能界面操作简单，故不一一介绍。

3.4注册用户管理界面

5.4.1注册用户管理界面

图5-4-1用户管理界面

5.4.2用户管理界面说明

用户管理：可根据客需求，添加，查询用户，包括编号，名称，电话，地址，负责人，网址等。实现该框架的主要代码如下所示：

3.5汽车信息管理界面

5.5.1人机界面

1）汽车添加信息管理：

图5-5-1汽车信息管理页面

2）汽车查询界面

图5-5-2汽车查询页面

5.5.2汽车信息管理界面说明

在此系统页面中，管理员可对所有汽车的信息进行增加、编辑、删除等操作，添加用户时需要填写的资料不太多，而编辑页面则是以详细列表的形式展开，一目了然。