图书销售系统需求分析.docx

网上图书销售系统需求分析

1 引 言 1
1.1 简介 1
1.2 参考资料 1
2 系统分析 2
2.1 开发背景及意义 2
2.2 可行性研究 2
2.3 功能需求 4
2.3.1 用例分析 4
2.3.2 概念类描述 8
2.3.3 顺序类描述 10
2.4 性能需求 13
2.4.1 响应时间 13
2.4.2 吞吐量 13
2.4.3 并发用户数 13
2.4.4 资源利用率 14
2.5 环境需求 14
2.5.1 硬件环境 14
2.5.2 软件环境 14
3 系统设计 15
3.1 系统结构设计 15
3.1.1 软件设计的原则 15
3.1.2 系统层次结构 16
3.2 数据库设计 17
3.2.1 数据库概念设计 17
3.2.2 数据库逻辑设计 18
3.3 用户界面设计 21
3.3.1 人机界面设计原则 21
3.3.2 主界面设计 22
3.4 系统详细设计 23
3.4.1 订单管理PAD图 24
3.4.2 购物车PAD图 25
3.4.3 图书查询PAD图 25
4 系统实现 27
4.1 任务与原则 27
4.2 系统功能实现 27
4.2.1 系统登录 27
4.2.2 图书管理 28
4.2.3 订单管理 28
4.2.4 个人信息 29
4.2.5 图书信息 29
4.2.6 其他功能简介 30
5 软件测试 30
5.1 测试计划的制定 30
5.1.1 调试计划的整体目标 31
5.1.2 定义软件测试的标准 31
5.1.3 测试实施策略的制定 31
5.1.4 测试计划的活动的细分 31
5.1.5 测试计划的要点 32
5.2 测试的基础 32
5.2.1 测试的目标 32
5.2.2 白盒测试和黑盒测试 33
5.2.3 测试的准则 33
5.3 功能测试 34
5.3.1 等价划分测试 34
5.4 软件可靠性 35
5.4.1 基本定义 35
5.4.2 估算平均无故障时间的方法 36
5.4.3 MTTF和ASS的估算 37
结 论 37

1 引言

1.1 简介

随着计算机和互联网的发展打开了人们的视野，使人们呼吸道信息化、数字化的这股春风，一种新的购物平台已经被创建，电子商务平台。通过网络进行电子购物不但节省了消费者的时间，而且商家也可以根据需要进行产品的生产和不断更新，这样在一定的程度上提高了生产效率，促进了商品和资金的流通，改进了人们的生活方式。
在当今这个不断变化，不断更新的社会，人们的生活方式和生活节奏变得越来越快。那些传统的营销模式已经不能够在满足现在社会的需要。在中国图书销售行业实现在网上销售，通过计算机来管理信息。却只在1998年才有了中国的第一家网上图书销售网站。这比世界先进水平的国家晚了将进10年之久。中国大陆已经注册的网上书店大约有100多家，有网站的有50多家，但已经投入运营能够买到书的只有十来家。
很多人看到了书这种商品网上销售的诸多好处：方便购买、金额小、风险小、用户容易决定；信息的完整性以及很少出现质量问题和退货现象等。尽管全球最大的网上书城亚马逊股票惨跌，尽管各家书店都承认目前的亏本经营状况，但这并未阻挡投资者对网上书店“钱”景的期待。
众所周知国内各大型网站都有各自的网上书店，国内最大的网上书店亚马逊就是一个例子。这种网上书店的发展正在逐步完善。其中的功能比较丰富，操作也比较简便，因此吸引了大量的用户。然而，网络的资源是有限的，随着数据量的加大，网站的服务质量，尤其是熟读会变得不堪忍受。而我的系统针对小范围。如此一来，在保证效率的前提下，可以使用相对廉价的设备，节省费用和资源。

1.2 参考资料

1．朱少民 《软件测试方法和技术》 清华大学出版社 2005
2．韩万江 姜立新 《软件项目管理案例教程》 机械工业出版社 2010
3．徐人凤 曾建华 《SQL Server 2005 数据库及应用》 高等教育出版社 2007
4．Karl E.Wiegers 《软件需求》 清华大学出版社2004
5．吴炜煜 《面向对象分析设计与编程》 清华大学出版社2007
6．吉根林 崔海源 《Web程序设计》 电子工业出版社 2008

2 系统分析
2.1 开发背景及意义

社会的发展正在向信息化和数字化的方向发展，信息技术在社会各行各业都有了很大的发展空间，而且产业的发展强大必须依靠信息化的管理。计算机，互联网也必须是他们的主要依附。图书销售行业的发展壮大一样必须依靠互联网的技术，在这种情况下网上图书销售系统应运而生。
开发网上图书销售系统的宗旨在于方便人们进行图书的购买，加快书本的更新速度，使访问者足不出户就可以购买到自己想要的书籍，这种购书的方式打破了传统的单一购书方法，促使人们以更快的节奏、更高的投入到现在的生活中来。
网上图书销售系统有很多突出的优点，具体如下。
1、全面的书籍介绍：当读者找到自己所需要的书后，就可以更进一步地查看该书的相关介绍，除了书名、定价、出版社等基本信息外，还可以查看该书的目的、内容简介。
2、方便的书籍浏览：购书系统中以列表方式显示图书的信息，包括最新上架图书、特价图书以及最近的图书销售排行。
3、快捷的购物方式：当读者找到合适的书籍后，就可以将其添加到购物车中，待购买结束后就可以进行订单的提交，以等待商家寄书。
4、高价值的图书评论：图书的评论不但影响其他读者的购买欲望，更在很大的程度上对商家的供货、更新以及装订质量提出了更高的要求。

2.2 可行性研究

可行性研究的任务是从技术上、经济上、使用上、法律上分析应解决的问题是否有可行的解决方案。其目的是用极少的代价在最短的时间内确定被开发的软件是否开发成功。
1、技术可行性
Web技术的迅猛发展正推动Internet上信息服务类的进步。WWW服务的基础是HTML语言，HTML语言是静态网页编程语言，不能带后台，不能带数据库。所以在当今这个社会中HTML已经不能满足人们的需求。Struts2语言就很好的解决了HTML中的问题，并且支持数据库的连接，写好的网站会有一个后台的管理，当浏览器向服务器请求网页的时候，服务器会响应这个请求。将网页再发回给浏览器，同时将数据保存在后台的数据库中。断开连接，直到下一个请求。
网络图书销售管理系统有以下几个特点：一是数据量大，要求及时查询和浏览的内容较多，二是数据处理比较集中。内部数据处理量大，输入和输出的量大。三是即时处理，要不断更新最新的数据信息。基于以上三个特点，现有的技术都可以达到现有的目标。在单机环境下组建管理信息系统，该系统的开发工作可以用struts2做前台，SQL Server 2000做后台，前台可视化程度较高，人机交互能力较强，应用方便。后台数据库管理数据功能强大，能更好的支持系统的运行。
2、经济可行性
软件系统的主要设资费用包括：设备费用（计算机及软件配置的费用），开发费用（开发人员，维护人员的费用），系统开销（所用的电力，硬件的磨损折旧等）和另外的一些系统的费用。现在各大中小型书店都是自主经营，自负营亏。本系统对硬件的要求并不是特别高，只是一般的计算机就可以运行起来，还有就是开发人员和维护人员的费用，开发人员只需要一次性付款，而维护人员只是公司员工开工资即可，系统的开销并不大。中小型书店应该可以接受并支付得起。
另外还有一点就是公司员工的培训，本系统简单易学。对于熟悉图书销售的工作人员来说，只要掌握简单的计算机操作知识，便可以熟练掌握。本系统的后台系统稳定，易于维护，并不会消耗掉太多的人力和物力，商家也应该愿意支付。
本系统会给商家带来巨大的经济利益。前期的投资对于后期的创益来说应该是极其值得的。系统能使书店的工作人员从繁重的体力劳动中解脱出来。
系统不仅给销售管理工作带来方便，同时也满足了不同客户的不同需求。提高了数据的安全性、共享性和实力性，大大地降低公司预算，提高了工作效率，为图书商家在业界市场的激烈竞争中减少不小的开支。
3、使用可行性
本系统采用Struts2设计前台界面，用SQL Server 2000数据库为后台管理。可以在Windows xp、Windows2000 等Windows操作系统系列下运行。本系统考虑到当今社会当中计算机已经成为不可缺少的元素之一，中国现在网民人数已经突破2.6亿，而这也仅仅是上半年的调查结果。中国在网上消费的人数也在大幅度增加。这些人都有一定的计算机操作基础。本系统前台界面美观，操作简单，只要掌握一些计算机基本操作的人便可以短时间内熟练使用系统。后台管理中数据库稳定不易出现错误，易于管理。基于以上的种种理由，本系统完全可以在社会中使用，推动中国计算机网络的发展，同时也为书店商家创造出巨大的经济利益。
4、法律可行性
现在中国的法律中对于非法的软件的管理还处在一个空白的阶段，使得现在非法软件肆意猖獗。比如偷窥别人的隐私，打扰别人的正常生活（病毒），盗版等。本系统是完全遵守着软件开发人员的职业道德，系统并没有加入任何能够损害到商家和消费者利益的东西，可以放心使用。而且本系统完全遵守国家的《中华人民共和国计算机软件保护条例》的条例，使本系统也拥有着法律的保护。

2.3 功能需求

主要针对中小型书店对书店的图书信息和用户（书店工作人员，网站注册用户即潜在购书者）信息的进行有效的管理，对图书的进销存等环节进行信息化管理，实现读者网上浏览图书，网上购书的可能。通过读者对购买图书的在线评价，处理读者网上的投诉和建议。

2.3.1 用例分析

用例图主要用来图示化系统的主事件流程，它主要用来描述需求，即希望系统具备的完成一定功能的动作，通俗地理解用例就是软件的功能模块，是设计系统分析阶段的起点，设计人员根据需求来创建和解释用例图，用来描述软件应具备哪些功能模块以及这些模块之间的调用关系，用例图图符如表2.1所示。
表2.1 uml用例图图符
可视化图符
名称
描述

系统边界
用来表示系统边界，所有用例放在系统之中，它确定系统的范围

用例
用来表示用例图中的用例，它代表系统提高的范围

参与者
用于描述与系统功能有关的外部实体，可以是用户，也可以是外部系统

关联
连接执行者和用例，它表示角色与用例间的关系
通过系统的功能需求分析，可得到系统的服务对象为购书者，网上图书销售系统的内部工作人员可以按照工作需要各自完成自己指定的任务。其中管理员为抽象角色，所以系统角色分析用例图如图2.1所示。

图2.1 系统角色分析用例图
顶层用例：对网站涉及到的所有人员进行详细地分工，描述了每个用例之间的联系。故网上图书销售系统顶层用例图如图2.2所示。

图2.2 顶层用例图
图书管理：对图书库中的所有的图书信息进行管理包括基本的增、删、改、查，同时也能对图书进行分类像计算机类，经济类，外语类等，还可以对读者对图书的评价进行回应，可以及时改变书店的图书供货关系，可以查看缺书登记，对用户想要购买的书及时进货，图书管理用例图如图2.3所示。

图2.3 图书管理用例图
订单管理：订单的管理主要是执行订单和查看订单的详细信息，修改订单的下达信息，保证用户能够及时看到自己购买图书的发货信息，同时，管理员可以对不合法的订单进行删除。总体来说用户在网站前台购书并到收银台结账生成订单后，还需要执行订单。订单管理用例图如图2.4所示。

图2.4 订单管理用例图
用户管理：对在网站注册的用户进行统一管理，可以查看用户列表，对于会员信息的管理主要是查看会员基本信息和对部分非法用户予以删除，用户管理用例图如图2.5所示。

图2.5 用户管理用例图
新闻管理：对于新闻的管理主要是查看新闻列表及信息的查看，添加新闻和删除新闻。由于新闻信息涉及到新闻发布时间，所以没有修改新闻信息的功能，新闻管理的用例图如图2.6所示。

图2.6 新闻管理用例图
注册用户：通过网站注册的用户可以直接登录网站进行相关的活动，用户登录后可以查看、搜索、购买图书，并可以对喜欢的图书进行购买放入购物车，并且可以管理购物车对购物车的图书下订单结账，并对不小心加入购物车的图书进行删除，对自己已经下订单的并不满意在没有发货前也可以对订单删除，注册用户用例图如图2.7所示。

图2.7注册用户用例图

2.3.2 概念类描述

类图(Class diagram)是显示了模型的静态结构，特别是模型中存在的类、类的内部结构以及它们与其他类的关系等。类图不显示暂时性信息[9]。
类图是由若干类关联在一起，反映系统或者子系统组成结构的静态图。类图的建模贯穿工程的分析和设计阶段的始终，通常从商务伙伴能够理解的类开始建模，最终往往成为只有开发小组才能够完全理解的类。
类图描述系统中类的静态结构。不仅定义系统中的类,表示类之间的联系如关联、依赖、聚合等,也包括类的内部结构(类的属性和操作)。类图描述的是一种静态关系,在系统的整个生命周期都是有效的。
类图是在面向对象的系统模型中使用得最普遍的图。类图包含了一组类、接口和协作以及其之间的关系。使用类图来为系统的静态视图建模。通常这包括模型化系统的词汇，模型化协作，或则模型化模式。类图还是一些相关的图的基础，包括组件图、分布图。
类图的重要性不仅仅体现在为系统建立可视化的、文档化的结构模型，同样重要的是构建通过正向和反向工程建立执行系统。
没有类是单独存在的，类通常和别的类协作，创造比单独工作更大的语义。因此，除了捕获系统的词汇以外，还要将注意力集中到这些类是如何在一起工作的。使用类图来表达这种协作，类图图符如表2.2所示。

表2.2 类图图符
可视化图符
名称
描述

类
表示具体的一个类，第一栏为类名，第二栏为类的属性，第三栏为类的方法

包
一种分组机制，表示一个类图的集合

关联
表示类的对象间的关系，包括聚集关联和组成关联

泛化关系
描述类或包的一般元素与特殊元素之间的分类关系
类图是一种显示应用程序的类及类之间关系的可视表示。类可以定义每个元素实例包含的属性以及每个元素执行或经历的操作。由上面的用例图得到图书类的方法可有查看图书信息、添加图书信息、修改图书信息、删除图书等，图书订单类和图书库存类的方法可有查看订单详细信息、更新库存等，操作记录类的方法可有高级查询、查看图书详细信息、查询订单详细信息、查询图书库存、删除订单等，管理员类的方法可有用户管理、订单管理、库存管理、公告管理等。其中图书类别类可以泛化出小说、幼儿读物、计算机类图书、工具书、哲理书等具体类，图书订单类和图书库存类可以分别泛化出查看订单详细信息、删除订单等具体类，概念类的类图如图2.8所示。

图2.8 概念类类图

2.3.3 顺序类描述

顺序图重点是显示对象之间发送的消息的时间顺序。它也显示对象之间的交互，就是在系统执行时，某个指定时间点将发生的事情。顺序图由多个用垂直线显示的对象组成，图中时间从上到下推移，并且顺序图显示对象之间随着时间的推移而交换的消息或函数。消息是用带消息箭头的直线表示的，并且它位于垂直对象线之间。时间说明以及其他注释放到一个脚本中，并将其放置在顺序图的页边空白处。
顺序图是一种动态建模方法。一般用于确认和丰富一个使用情境的逻辑。一个使用情境就是系统潜在的使用方式的描述，也就是它的名称所要描述的。通过观察什么消息被发送给一个对象，以及通过概略的观察运行被调用的方法需要花费多长时间，很快就能了解哪里的设计需要变化，以达到在系统内部平衡负荷的目的，UML顺序图图符如表2.3所示。
表2.3 UML顺序图图符
可视化图符
名称
描述

带有生命线的对象
用于表示顺序图中参与交互的对象

激活
表示在这个时间段内，对象处于活动状态

消息
用于表示对象之间传递的消息

返回消息
用于表示对象之间传递的消息
创建顺序图包含4项任务：一、确定需要建模的工作流；二、从左道右布置对象；三、添加消息和条件以便创建每一个工作流；四、绘制总图以便连接各个分图。在了解顺序图的建模方法情况下。绘制系统的顺序图首先要了解系统的过程，根据系统类图中的方法可以获得详细的系统过程，系统管理操作顺序图如图2.9所示。

图2.9 系统管理操作顺序图

2.4 性能需求

性能指标有些模糊，很难有一个确切、具体的数值来描述。通常是通过系统的稳定性、可靠性、无故障工作时间和故障恢复难易程度来体现的。
系统的性能是系统的一种非功能特性，它关注的不是系统是否能够完成特定的功能，而是在完成功能时展示出来的及时性。为了能够客观地度量系统的性能，定义了一系列的性能指标，以便于在不同情况下度量系统的性能。

2.4.1 响应时间

响应时间是指用户发出请求，系统做出相应的反应的这段时间叫做响应时间。在讨论系统的响应时间时，通常是指系统所有功能的平均响应时间或者所有功能的最大响应时间。对一个系统，其响应时间如果小于1秒应该是不错的，如果达到5秒就完全难以接受了。本系统采用jsp语言编写对用户本机与浏览器要求低，响应时间也相对较短，最大为4秒平均为2~3秒，完全符合需求。

2.4.2 吞吐量

吞吐量（throughput），是指单位时间内流经被测系统的数据流量，一般单位为b/s,即每秒钟流经的字节数。对于无并发的系统而言，吞吐量与响应时间成严格的反比关系，实现上此时吞吐量就是响应时间的倒数。由于本系统的响应时间比较短，所以系统的吞吐量比较大。在不同领域不同版本的资料当中，对吞吐量的概念是不尽相同的。

2.4.3 并发用户数

是同时执行一个操作的用户，或者是同时执行脚本的用户，这个并发在设置不同场景的时候并发的情况是不一样的，在实际的测试中需要根据具体的需求进行设计。与吞吐量相比，并发用户数是一个更直观但也更笼统的性能指标。实际上，并发用户数是一个非常不准确的指标，因为用户不同的使用模式会导致不同用户在单位时间发出不同数量的请求。

2.4.4 资源利用率

资源利用率反映的是在一段时间内资源平均占用的情况。对于数量为1的资源，资源利用率可以表示为资源被占用的时间与整段时间的比值；对于数量不为1的资源，资源利用率可以表示为在该段时间内平均被占用的资源数与总资源数的比值。

2.5 环境需求
2.5.1 硬件环境

服务器端的最低配置是由建立站点所需的软件来决定的，在最低配置的情况下，服务器的往往不尽如人意，现在的硬件性能已经相当出色，而且价格也很便宜，因此通常应给服务器端配置高性能的硬件，本系统服务器端的配置如下：
处理器：Inter Pentium(R) Dual-Core CPU T4300 2.1GHz 或更高
内存：2GB
硬盘空间：250GB
显卡：Nvidia GeForce G210M
因为客户端主要用于浏览和操作数据，所以对客户端的硬件要求不高，不过现在的电脑很高的性价比，因此需要的配置应该高于下面的配置：
处理器：Inter Pentium 1.9GHz 或更高
内存：512MB
硬盘空间：80GB
显卡：SVAG显示适配器。

2.5.2 软件环境

服务器端软件环境如下：
操作系统：Windows XP Professional Service Pack3
网络协议：TCP/IP
web服务器：tomcat6.0
数据库：Microsoft SQLserver2000
浏览器：Internet Explorer 8.0

用户端要求如下：
操作系统：Windows 98/2000/XP
网络协议：TCP/IP
服务器：.NET Framework 环境
浏览器：Internet Explorer 5.0以上

3 系统设计
3.1 系统结构设计
3.1.1 软件设计的原则

1．模块化
模块化设计不仅减低了系统复杂性，使得系统容易修改，而且推动了系统各个部分的并行开发，从而提高了软件的生产效率。
2．抽象与逐步求精
抽象是指抽出事物的本质特性而暂时不考虑他们的细节。逐步求精是把问题的求解过程分成若干步骤活阶段，每个步骤活阶段都比上一个步骤更精细化，更接近问题的解法。逐步求精是与抽象紧密相关的感念，是一个由抽象到具体的过程。
3．信息隐藏和局部化
信息隐藏是指每个模块的实现细节对于其他模块来说是隐藏的。模块所包含的信息部允许其他不需要这些信息的模块使用，如模块的内部数据、过程等。信息屏蔽使修改软件时引入的错误造成的影响只局限在一个或几个模块内部，不涉及软件的其他部分。局部化则是指把一些关系密切的软件元素放的彼此靠近。在模块中使用局部数据元素就是局部化的一个例子。显然局部化有利于实现信息的隐藏。
4．模块独立性
模块独立性是指软件系统中每个模块只涉及软件要求的具体子功能，而和软件系统中其他模块的借口是无关的。模块独立的概念是模块化、抽象、信息隐藏和局部化概念的直接结构。模块的借口是无关的。

3.1.2 系统层次结构

HIPO图(hierarchy plus input-process-output)是IBM公司于70年代中期在层次结构图(structure chart)的基础上推出的一种描述系统结构和模块内部处理功能的工具(技术)。HIPO图由层次结构图和IPO图两部分构成,前者描述了整个系统的设计结构以及各类模块之间的关系,后者描述了某个特定模块内部的处理过程和输入/输出关系。
HIPO图由三个基本图表组成，进行模块层次功能分解遵循以下步骤：
1、总体IPO图：它是数据流程图的初步分层细化结果，根据数据流程图，将最高层处理模块分解为输入、处理、输出三个功能模块。
2、HIPO图：根据总体IPO图，对顶层模块进行重复逐层分解，而得到的关于组成顶层模块的所有功能模块的层次结构关系图。
3、低层主要模块详细的IPO图：由于HIPO图仅仅表示了一个系统功能模块的层次分解关系，还没有充分说明各模块间的调用关系和模块间的数据流及信息流的传递关系。因此，对某些输送低层上的重要工作模块，还必须根据数据字典和HIPO图，绘制其详细的IPO图，用来描述模块的输入、处理和输出细节，以及与其他模块间的调用和被调用关系。
网上图书销售系统的层次结构大体分为三层，第一层是系统的主体，第二层是系统的个功能块的划分，第三层是对各功能模块进行详细说明，如此实现自顶向下逐步求精，系统的层次结构图如图3.1所示。

图3.1 系统的层次结构图
H图只说明了系统由哪些模块组成及其控制层次结构，并未说明模块间的信息传递及模块内部的处理。因此对一些重要模块还必须根据H图绘制具体的IPO表。用户和管理人员可利用IPO表编写、修改和维护程序。IPO表中包含的附加信息主要有系统名称、图的作者，完成的日期，本图描述的模块的名字，模块在层次图中的编号，调用本模块的模块清单，本模块调用的模块的清单、注释以及本模块使用的局部数据元素等。
订单状态修改的上层调用模块为订单管理，没有下层模块可调用，订单状态修改的IPO表如表3.1所示。
表3.1 订单状态修改的IPO表
系统名称：网上图书销售系统
设计者：张玲、曾宪俊、张晨辰
模块名：订单状态修改
日期：2009-12-10
模块编号：1.2

上层调用模块：订单管理
下层被调用的模块：无
输入数据：无
输出数据：状态修改后得到的结果
处理：根据修改的状态确认后，重新查看是否显示相应的状态
图书添加的上层调用模块为图书管理，没有下层模块可调用，图书添加的IPO表如表3.2所示。
表3.2 修改信息的IPO表
系统名称：网上图书销售系统
设计者：张玲、曾宪俊、张晨辰
模块名：修改信息
日期：2009-12-10
模块编号：3.1

上层调用模块：图书管理
下层被调用的模块：无
输入数据：填写要添加的信息
输出数据：对数据库的更新结果
处理：判断添加的图书信息的合法性，添加成功后返回主页进行浏览判断添加是否成功

3.2 数据库设计
3.2.1 数据库概念设计

1.用户登记表：存储用户的基本信息。
2.图书类别表：存储图书类别的信息。
3.图书基本信息表：存储图书的基本信息。
4.图书评论表：存储读者对图书的评论信息。
5.缺书登记表：存储没有的图书信息。
6.图书订购信息表：存储购买图书的信息。
7.图书订购者详情表：存储订书用户的信息。
8.购物车详情表：记录购买者和书的信息。

3.2.2 数据库逻辑设计

用户登记表是用来存放用户的详细信息的数据表，会员通过用户名和密码登陆到本站，实现购买图书，下订单，添加购物车等功能如图3.3所示。
表3.3 用户登记表
序号
名称
字段
类型
备注
1
编号
ID
int

2
用户名
UserName
varchar(60)
主键
3
登录密码
PasswordStr
varchar(60)

4
真实姓名
RealName
varchar(60)

5
性别
Sex
int
允许空
6
证件名称
IDName
varchar(60)
允许空
7
证件编号
IDNumber
varchar(20)
允许空
8
教育水平
Education
varchar(20)
允许空
9
所在地
Province
varchar(20)
允许空
10
地址
Address
varchar(100)

11
邮编
PostCode
varchar(20)

12
电话号码
PhoneNumber
varchar(20)

13
移动电话
MobliePhone
varchar(20)

14
电子邮件
Email
varchar(100)

15
读者层次
UserLevel
int
允许空
16
累计消费
TotalConsumption
varchar(40)
允许空
图书类别表是用来存放图书类别的数据表，包括类别类别编号、类别名、说明、分类，内容如表3.4所示。
表3.4 图书类别表
序号
名称
字段
类型
备注
1
类别名称
TypeName
varchar(40)

2
说明
Description
varchar(200)
允许空
3
类型编号
BookType
int

4
分类
SuperBookType
int

图书基本信息表，用来保存图书的基本信息像书名、作者、出版社等等，当有新书添加时，图书的信息都保存在这里。网站上图书的显示也是直接从这个表中读取的，如表3.5所示。
图书评论表是用来存储读者对每本图书评论意见的，当其时用户进行浏览该图书的话就会看到相应的评论，查看图书的好与坏，如表3.6所示。
所缺图书书目表用来存储所缺图书信息，当用户注册并登陆的用户没有查找到自己想要的图书时可以通过缺书登记记录出自己想要图书信息都存储在此表中，如表3.7所示。
图书订购信息表用来存储订单已经下达的，表中包括读者的信息和图书的信息，订单下达后，图书管理员就可以在这里查看订单的信息，如表3.8所示。
表3.5 图书基本信息表
序号
名称
字段
类型
备注
1
编号
ID
int
主键,自增长
2
书名
BookName
varchar(80)

3
作者
Author
varchar(40)

4
ISBN
ISBN
varchar(20)

5
页数
Pages
int

6
出版社
Publishing House
varchar(60)

7
类信息
ClassInfo
int

8
翻译
Translator
varchar(40)
可为空
9
系列名称
SeriesName
varchar(60)
可为空
10
出版日期
PublishDate
varchar(40)

11
定价
Price
varchar(40)

12
内容简介
Description
text
可为空
13
摘要
Abstract
text
可为空
14
目录
BookCatalog
text
可为空
15
封面
Cover
image
可为空
16
评论条数
CommentNumber
int
可为空
17
点击次数
HitNumber
int
可为空
18
售出数
SoldNumber
int
可为空
19
会员级别
Status
int
可为空
20
特价
SpecialPrice
int
可为空
21
折扣
Discount
int
可为空
22
开本
Pagelarge
Int

表3.6 图书评论表
序号
名称
字段
类型
备注
1
编号
ID
int
主键,自增长
2
书名
BookID
int

3
说明
Caption
varchar(80)
可为空
4
评论
Comment
text

5
读者姓名
UseName
varchar(40)
可为空
6
电子邮件
Email
varchar(60)
可为空
7
出版日期
PublishDate
datetime

表3.7 所缺图书书目表
序号
名称
字段
类型
备注
1
编号
ID
int

2
读者姓名
UseName
varchar(20)

3
书名
BookName
varchar(80)

4
出版社
Publisher
varchar(60)
允许空
5
作者
Author
varchar(20)
允许空
6
登记日期
RegisterDate
varchar(60)

表3.8 图书订购信息表
序号
名称
字段
类型
备注
1
读者编号
UesrID
int

2
订单号
OrderID
int

3
书号
BookID
int

4
订购数量
Quantity
tinyint

5
优惠价
DiscountPrice
varchar(40)

图书订购者详情表用来保存下订单的用户的信息，主要信息包括读者的姓名和地址信息，如图3.9所示。
表3.9 图书订购者详情表
序号
名称
字段
类型
备注
1
编号
ID
int
主键
2
读者编号
UserID
int

3
读者姓名
ContactName
varchar(60)

4
读者地址
Address
varchar(100)

5
电子邮件
Email
varchar(40)

6
邮编
PostCode
varchar(20)

7
电话号码
PhoneNumber
varchar(20)

8
移动电话
MobilePhone
varchar(20)

9
邮寄备注
SendMemo
varchar(200)
允许空
10
邮寄方法
SendMethod
int

11
付款方法
payMethod
int

12
订购日期
OrderDate
varchar(40)

13
订购情况
OrderStatus
int

14
订购完成日
OrderFinishDate
varchar(40)
允许空
15
是否要发票
NeedInvoice
int

16
总计
TotalDiseountPrice
varchar(40)
允许空
购物车详情表存储购买的图书信息，如图3.10所示。
表3.10 购物车详情表
序号
名称
字段
类型
备注
1
读者编号
UserID
int

2
书号
BookID
int

3
订购数量
Quantity
int

3.3 用户界面设计

用户界面设计也叫做人机界面设计，是指通过一定的手段对用户界面有目标和计划的一种创作活动.大部份为商业性质、少部份为艺术性质。
人机界面是计算机科学和认知心理学两大学科相结合的产物，同时也吸收了语言学、人机工程学和社会学等学科的研究成果。经过40余年的发展，已经成为一门以研究用户及其与计算机的关系为特征的主流学科之一。近年来，人机界面的设计理论已经更广泛地发展和应用到人、机、环境系统工程等领域，使工程技术设计与使用者的身心行为特点相适应，从而使人能够高效、舒适地工作与生活。
人机界面的设计质量，直接影响用户对软件产品的评价，从而影响软件产品的竞争力和寿命，因此，必须对人机界面设计给以足够重视。

3.3.1 人机界面设计原则

1.以用户为中心的基本设计原则
在系统的设计过程中，设计人员要抓住用户的特征，发现用户的需求。在系统整个开发过程中要不断征求用户的意见，向用户咨询。系统的 设计决策要结合用户的工作和应用环境，必须理解用户对系统的要求。最好的方法就是让真实的用户参与开发，这样开发人员就能正确地了解 用户的需求和目标，系统就会更加成功。
2．顺序原则
即按照处理事件顺序、访问查看顺序（如由整体到单项，由大到小，由上层到下层等）与控制工艺流程等设计监控管理和人机对话主界面及 其二级界面。
3．功能原则
即按照对象应用环境及场合具体使用功能要求，各种子系统控制类型、不同管理对象的同一界面并行处理要求和多项对话交互的同时性要求等，设计分功能区分多级菜单、分层提示信息和多项对话栏并举的窗口等的人机交互界面，从而使用户易于分辨和掌握交互界面的使用规律和 特点，提高其友好性和易操作性。
4．一致性原则
包括色彩的一致，操作区域一致，文字的一致。即一方面界面颜色、形状、字体与国家、国际或行业通用标准相一致。另一方面界面颜色、形状、字体自成一体，不同设备及其相同设计状态的颜色应保持一致。界面细节美工设计的一致性使运行人员看界面时感到舒适，从而不分散 他的注意力。对于新运行人员，或紧急情况下处理问题的运行人员来说，一致性还能减少他们的操作失误。
5．频率原则
即按照管理对象的对话交互频率高低设计人机界面的层次顺序和对话窗口莱单的显示位置等，提高监控和访问对话频率。
6．重要性原则
即按照管理对象在控制系统中的重要性和全局性水平，设计人机界面的主次菜单和对话窗口的位置和突显性，从而有助于管理人员把握好控制系统的主次，实施好控制决策的顺序，实现最优调度和管理。
7．面向对象原则
即按照操作人员的身份特征和工作性质，设计与之相适应和友好的人机界面。根据其工作需要，宜以弹出式窗口显示提示、引导和帮助信息 ，从而提高用户的交互水平和效率。
人机交互界面，无论是面向现场控制器还是面向上位监控管理，两者是有密切内在联系的，他们监控和管理的现场对象是相同的，因此 许多现场设备参数在他们之间是共享和相互传递的。人机界面的标准化设计应是未来的发展方向，因为它确实体现了易懂、简单、实用基