3 过程论述 3.1 需求分析 3.1.1 系统综合要求 前台要实现的功能： 由于在商场进行购物的顾客是来自不同的群体，如何帮助他们正确使用购物过程中的操作和技巧，尽快投入到购物中，必须在这个设计中体现出来[3]。 (1) 界面友好，操作简单，提供大量的使用和提示说明。 (2) 提供会员制：只有注册的顾客才能够买本商场的商品，但对未注册的顾客允许浏览页面。另外，为提高购物的积极性，用户之间要有等级之分。 (3) 提供最新、推荐、人气最旺、热销、特价和促销商品信息的浏览。 (4) 对站内所有的商品能够进行分类，或无条件的模糊查询。 (5) 显示商品的具体信息时，要详细显示商品的大部分信息，并注明不同用户和不同产品价格区别，并能够提供对同类相关产品的显示。 (6) 允许登录用户对商品进行评论，并能够对已发表的评论进行回复。未注册顾客可以浏览评论内容。 (7) 为了更好与用户进行沟通，在首页要显示商场公告，并给注册用户提供发送站内短信的功能，以利于用户之间和用户与商场管理员之间的交流。 (8) 对于用户购买物品到提交订单整个流程要做到简单明了、安全，尽量模拟现实购物的习惯。对于购物车内的物品要用列表一一显示出来，并提供删除功能，对于重复够买的物品要累加计算。在用户提交订单时要提供多种运送方式，并对信息提供重复审核的功能。 (9) 为了增加商场的吸引力兼顾商场以后的发展方向和更贴近顾客，要为他们提供娱乐购物广场，使他们看到的不再是单调的图片和文字，而是要享受虚拟现实中购物场景。充分发挥三维世界给用户生活带来感观上的享受。 (10) 整个界面以蓝、绿色为主色调，布局统一，用CSS统一整个版面的样式。 后台管理功能： 要能够对网站绝大部分的动态信息直接操作，尽量不改动页面。 (1) 提供订单管理，商品管理，会员管理，短信管理，评论管理，菜单管理，文件管理，公告管理等。 (2) 提供网站本身信息修改，使用空间查看等附加功能。 安全性：提供数据备份和系统日志查看和管理。 系统性能要求：数据处理速度要快，并能够在短时间内响应顾客的请求。 运行要求：为了使系统安全、稳定的运行，操作系统和数据库要采用服务器版，WEB服务器要能够允许多人在线同时访问。 可靠性：系统运行数据要一致，如果遇到系统不能正常运行要提供快捷恢复方式。 可用性：系统要能够为以后商场不同业务的发展提供扩展功能。 出错处理：对于用户输入的错误数据或非法数据，要尽量在程序中进行检验并提示相关预定义的错误。对于可能出现的系统错误要尽量隐蔽其细节，并转向相应的出错处理程序进行重新处理。 3.1.2 系统前台购物和后台管理流程图 系统的前台购物流程图如图1：当顾客想在商场购买物品时，必须通过会员登录模块验证才行，无论登录成功或失败都要写入用户日志文件。顾客成功登录后就可以把他的物品放入购物车并可以随时到收银台进行结账。用户进行结账时，首先生成一张临时的订单，订单包括用户购买物品结算后的总额和某些个人信息。然后，用户可以根据需要选择支付方式，并可以修改其中某些个人信息。当用户确认提交订单后，这时物品购买流程才结束并写入订单库，同时显示用户订单号和本次付款总额。 后台管理流程图如图2：管理员通过后台入口进入管理登录模块，无论是否成功登录都会写入用户日志文件。当管理员成功登录后，他就可以对自己的某些信息进行修改，并根据自己的权限对管理用户进行操作。管理员可以根据业务的需要对商品、订单、类别、会员、用户短信文件、网站信息、菜单、和计数进行管理，并可以调出安全日志文件进行查看、跟踪、和统计。 3.1.3 数据流图 下面是对用户购买物品和提交订单的过程中，系统内的数据流图，由于这些功能间数据流比较复杂，我按处理事物的功能将它大体上划分为四部分。图3是商场前台功能划分的高层数据流图。顾客通过登录功能模块1进入购物系统，用功能模块2购买商品，然后在功能模块3提交订单并通过功能模块4退出系统。 图4是功能1进一步分解后的数据流图，无论顾客是否注册都可以浏览物品，但进行购物时必须进行登录，如果不是注册用户，则返回注册功能模块。用户输入账户、密码和验证码成功登录后不仅可以根据商品标识购买物品，而且还可以查询订单号和收发站内短信。 图5是功能2进一步分解后的数据流图，用户可以在购物车内放更多的物品，同时允许对已放入的物品删除，如果购买完后，可以对购物车内的物品结账。 图6是功能3 进一步分解后的数据流图，用户在收银结算后会生成订单，包括所有物品的总额和用户的部分信息。用户可以对生成的部分信息进行修改，当确认提交时，生成订单号并存入数据库中。此时用户就可以退出购物系统。 虚拟商场的总体设计 3.2.1 系统E-R图 E-R图是用来表示数据及其联系的工具，它描述的是现实世界的数据模型，与具体的DBMS无关，但是它是设计阶段设计数据库逻辑模型的重要依据[13]。 系统的购物E-R图，如图7所示：其中主要涉及的实体有用户，商品，购物车，订单和类别等。当用户访问站点时，计数器自动增加一条包括用户访问的页面、登录IP、登录时间的记录，如果经过登录过程，用户日志会自动记录下用户登录时的账户、IP、登录时间和结果；用户可以根据自己的登录账户查看自己已购买但并未结算的商品，也可以查看消息、发表评论和购买商品。当生成临时订单时，先根据账户提取用户购物车内已购买但未经过确认的商品，然后根据用户选择的支付方式生成订单。商品种类一般较多，先将商品按大类划分，进一步划分大类包括的小类，最后对商品进行小类归属。
系统的后台管理E-R图，如图8所示：其中主要涉及的实体有用户、商品、购物车、订单、会员和菜单等(实体属性见附录)。当用户登录时，用户日志会自动记录下用户登录时的账户、IP、登录时间和结果；用户登录后就可以通过管理来和这些实体发生关联。
3.2.2 数据库设计 在设计数据库时，通常用“范式(Normal Forms)”定义消除数据冗余的程度，范式越高，分解的表也增多，访问时性能（速度）将下降。因此在本设计中我主要以第三范式为主，兼顾系统实际运行情况，允许部分冗余的存在。 下面是E-R图，向关系模型转换后的部分关系模式： 商品（商品编号、商品标识、商品名、商品大类、商品小类、…） 订单（订单号、订单标识、用户编号、支付类型…） 用户（用户编号、用户标识、密码、用户名、…） 评论（评论标识、用户编号、商品编号、内容、…） 购物车（商品编号、购物车标识、用户编号、商品名、订单号、…） 运送方式（标识、方式、支付金额） 公告板（公告标识、标题、内容、提交时间、提交人、修改时间、修改人） 计数器（计数标识、普通虚拟商场、娱乐购物广场、访问时间、访问IP） 消息（消息标识、消息内容、发送者、接收者、发送时间、查看、回复） 系统信息（网站名、标题、网址、标志、所有者、QQ、Email、建站时间、…） 管理员（管理员账户、密码、姓名、等级） 菜单（菜单标识、菜单名、网址、页面序号） 商品大类（大类标识、类名、类编号、可视） 商品小类（小类标识、小类名、大类名、小类编号）首页 上一页 1 2 3 4 5 6 下一页 尾页 2/6/6 相关论文
首页 上一页 1 2 3 4 5 6 下一页 尾页 2/6/6
