网上交易平台系统分析及其设计应用报告.doc

C2C网上交易平台系统分析与设计报告
电子商务01级
9月

小构成员：
陈 剑 郝雪梅
吴 双 吴 婷
薛莉丽 赵柏敏

一、项目定义 3
二、需求分析 3
2.1 C2C市场存在乎义 3
2.2 现存C2C市场缺陷 3
2.3 本系统C2C网上交易平台概述 4
三、系统分析 5
3.1 业务流程分析 5
3.1.1 顾客注册登陆 5
3.1.2 交易过程 6
3.3信用体制 8
3.3.1信用描述： 8
3.3.2评价指标 9
3.3.3也许浮现问题： 9
3.3.4信用体制解决问题： 9
3.4收费机制： 9
3.5 系统数据流程 10
3.6 系统实体关系图 11
四 系统设计 12
4.1系统运营基本环境 12
4.2 数据库设计 12
4.2.1 数据库分析与数据库规范 12
4.2.2数据表、数据项之间关系 13
4.3系统设计 15
4.3.1 MVC简介 15
4.3.2 Smarty简介 16
4.3.3 为什么选用MySQL 17
4.3.4 持久层设计 17
4.3.5 系统整体设计 18
4.3.6顾客权限设计 19

一、项目定义
本系统旨在构建一种以学生为买方主体C2C网上商店。面向南大浦口、鼓楼学生以及外校某些年轻人群。重要角色涉及买方、卖方和系统管理员。卖方除了普通零散客户还为供应较多、较稳定大型卖者提供个人店铺空间。

二、需求分析
2.1 C2C市场存在乎义
随着人们消费水平提高，个人消费品市场空前发展，咱们发现，越来越多人拥有大量闲置商品。这些商品有新有旧，但都具备完整使用价值。拥有者们也许当前不需要它们，便想到把它们出售。可是如何找到买主，却成为一种令人头疼问题。
以学生为例。由于学生爱追赶潮流潮流，并且购买行为往往缺少筹划性，使得她们经常因一时冲动买下某物，之后又发现并没有用。学生对于电脑、手机、MP3等电子产品需求较多，而这些东西更新又不久，需求不同使她们但愿能互通有无。某些旧书籍、杂志、音像制品、生活用品等，也是留之无用、弃之可惜，若能卖给需要人不是皆大欢喜?
与此同步，随着学生们商品意识加强，有诸多同窗以代理商品销售为兼职，有开设个人店铺需求。但由于资金方面限制，不也许开设真正店铺。
可是由于供需双方市场不对称性，卖主很难找到适当买主，有这些需求人更是不懂得有谁要出售，导致这种C2C交易很难达到。当前普遍办法是卖者在校内摆个地摊。做代销同窗处处帖广告或者直接上门推销，展示并出售自己商品，可是时间、地点、规模都受到限制，并且要耗费大量时间和体力，尚未必有好效果。要是有一种平台，让供需双方集中地发布交易信息，并提供双方联系方式，促成其交易达到，将为买卖双方带来极大便利。
2.2 现存C2C市场缺陷
面对如此商机，精明商家不会无动于衷，当前C2C网上交易市场已经发展壮大起来。但是咱们分析后发现，现存C2C市场存在着某些缺陷，特别不能适应校园市场需求。
咱们调查发现，当前C2C网站中大某些都是拍卖网站。固然，拍卖作为C2C主导交易模式，其长处是存在，但它缺陷也是明显：交易时间长，买卖双方要耗费大量时间和精力。这种模式适合于价值较高商品，而学生闲置商品往往是耐用消费品，价值较低，拥有者但愿尽快出手，而并不想耗费太多精力计较一点价格差别，因而拍卖模式对校园市场特别不适合。
现存另一种C2C网上交易市场就是类似于小百合bbsfleamarket。这是以bbs为平台，供交易双方发布信息，并提供站内联系。但这种方式是很初级，它只是以交易信息作为bbs一项内容，而不是专业交易平台。它没有按商品分类，顾客查找起来很不以便，只能“误打误撞”；由于它是非正式，缺少交易规则约束，特别是它没有保证交易者信用保障，也没有信用评估体系，交易者要承担一定风险，使它可信度下降。
鉴于以上分析，咱们系统为买卖双方提供一种集中C2C信息交易平台，增进买卖双方信息沟通，较完善信用机制提供一定限度上信用保证，为同窗们提供以便同步保证同窗们交易安全性。
2.3 本系统C2C网上交易平台概述
本系统面向以学生为主顾客群体，为它们提供C2C 交易平台。卖者发布出售商品信息，买者也可发布求购信息。本系统顾客分为散户和个人店铺顾客。
系统采用虚拟货币进行交易和流通，顾客通过汇款或银行划账等方式用真实货币换取虚拟货币，卖方按其类型收取不同费用，费用通过本站系统虚拟货币扣除。可以在需要购买商品时换取虚拟货币也可以预先在本系统设立个人虚拟货币银行。一方面是金融业发达加快货币流通使得汇款或转帐变得更为快捷，另一方面一次转帐可以减少顾客多次汇款转帐额外费用，节约了开支。
顾客在本站通过搜索或分类查找，谋求交易伙伴。顾客可以查询卖方有关信息和信用评价等指标，决定与否购买。
交易中，按卖方类型（普通零散顾客或店铺顾客）提成两种不同模型：
系统为有较大商品销售需求卖方提供店铺空间，集中展示个人商品，并为卖家提供一定优惠和折扣。
顾客通过度类搜索，查询到满意商品。同步可以查看到卖方上站时间、上架商品次数以及与否有在本站交易违约行为记录等历史信息，如果是店铺卖方，买家还可以查询店铺有关历史信息。决定购买后顾客可通过站内或其她联系方式联系。双方成交后，在网下自行交易，本站不监控交易过程。在交易过程中如有哪一方浮现欺骗行为，可以进行投诉，经系统管理员确认后，对欺骗方进行惩罚。
本系统对个人店铺卖方顾客实行会员制，收取会员费用；对普通零散型卖方按所发布商品信息收取费用，费用通过虚拟货币扣除。本系统对买方不收取费用。在商店运营初期，为了提高网站知名度和扩大网站影响力，本系统在1年内不收取费用。
本系统保证了买卖双方交易安全性。咱们针对当前C2C市场普遍缺少信用保证现状，使通过本站达到交易更加安全可靠，提高顾客放心度和满意度。

三、系统分析
3.1 业务流程分析
顾客进入本网站须注册并获得账号后方能进行交易。若没有注册，也可以浏览商品信息，但不能获得卖方或买方联系方式，也不能对商品留言或在论坛刊登观点。顾客登录后，可以发布商品信息，买方浏览所需商品，双方供需匹配后联系，进行实际交易。
由此得出本系统业务流程分为三某些：顾客注册登陆、交易过程、信用评价。下面分别予以阐明：
3.1.1 顾客注册登陆
业务流程图如下所示：
图1
顾客注册登录过程分为散户注册和个人店铺顾客注册。系统规定顾客注册真实信息。如果因顾客注册为非真实信息而导致任何损失本系统不予以负责。
对于零散顾客，咱们采用email地址作为个人身份验证标记。顾客注册时，输入个人email地址，本网站将其密码发送至其邮箱中，顾客用该密码登录本网站，成为正式顾客。此举在一定限度上保证了注册者身份可靠，防止恶意注册。
若为店铺顾客，需要进行实地验证。店铺顾客需向系统出具保证个人真实身份证件。例如身份证件、学生证等。经本系统管理人员确认后予以通过。以此最大限度保证店铺顾客身份真实性，为买方提供信用保障。
散户顾客在注册后可以申请升级为店铺顾客。已登录顾客可随时修改密码。
3.1.2 交易过程
业务流程图如下所示：

图2
3.1.2.1开设个人虚拟银行
系统为每个顾客开设虚拟银行，并勉励顾客预存一某些货币一以便交易。系统对卖方顾客收费采用扣除个人虚拟货币形式。
系统参照其个人虚拟账户货币金额数量评估卖方信用。
3.1.2.2卖方发布商品信息
系统卖家可以是普通零散顾客也可以是店铺顾客。卖家发布所要出售商品信息，可配以文字描述和图片，商品信息在本网站内按类别显示。
若卖方为普通零散顾客，按发布商品信息收取少量费用，按卖方所需，每个商品设立不同保存时间，按不同步间收取费用，在规定期间内如卖方未将商品下架，系统自行删除商品。
若为个人店铺顾客，可以申请不同空间集中展示自己商品。按不同空间收取不同会员费用。个人店铺提供了更为详尽商品信息。除了普通商品信息外，尚有商品数量以及已定购数量，供买方作为购买参照。
3.1.2.3买方查询卖方和商品信息，进行交易
对于买家，可以在分类区查找商品信息；也可以用站内搜索器按商品名称、类别、卖家、价格等核心字搜索；还可以去个人店铺中寻找。一旦找到与自己需求匹配商品，可以通过查看卖家评价信息借以判断卖家信用。
买方可以与卖家在站内联系，也可以通过卖方发布其她联系方式联系（卖方可选取发布其站外联系方式）。此后双方交易过程为本系统外部行为，交易在网下进行。买卖行为为买卖双方个人行为，买卖双方在交易前要确认对方身份真实性。若因个人行为不慎导致损失不在本系统负责范畴之内。
对于零散卖方，在商品卖出后卖方可自行将其下架；如若在一定期限内商品未下架，系统将予如下架。对于店铺卖方，由顾客自行管理商品。依照顾客会员级别予以不同数量商品货架，本网站勉励顾客尽快将已出售商品下架，若买方顾客投诉店铺卖方长期空货架行为，系统对卖方信用进行惩罚。
本系统提供一定信用评价机制，为交易双方提供一定限度上信用参照价值，最大限度保证交易双方交易安全性。对零散拥护和店铺顾客，提供不同信用评价。
卖方顾客必要留存一定金额货币，如有需要（如取消店铺权限、取消账号等）可以在规定期间内将站内虚拟货币进行结算。
3.1.2.4买方发布求购信息
同步，咱们也为买家提供了发布求购商品信息平台。买家可列出其需要而没有找到商品，卖家依照这些信息，可将符合需求商品上架，或直接与该买家联系。

3.3信用体制
本系统与相似C2C网上商店相比，运用本系统内部虚拟货币，监控买卖双方交易行为，提供一种较为有效信用保障体制。
3.3.1信用描述：
本系统通过顾客用人民币1：1换取站内虚拟货币。在本系统内部开始个人虚拟货币银行。顾客缴费是以虚拟货币为流通货币。
由于零散型顾客买卖商品普通为低价值商品，加之大某些零散型卖方交易行为都是短期一次性交易。本系统仅为这些顾客提供交易信息平台，并没有控制和监控双方买卖行为。买方在购买普通顾客商品时，可以参照系统提供顾客信用值。
而对于店铺卖方，由于普通交易金额较大，且采用定单形式。订单解决由卖方自行负责。卖方可以在受到汇款后才会发货，也可以货到付款。卖方货架空间是有限，因而在一件商品售出后会尽快将其下架。双方如有任何争执或投诉，都必要出具证明，有管理人员裁定。如果卖方浮现欺骗行为，除了扣除其信用值外，还按其违约行为严重限度扣除其银行账户金额，如若为买方欺骗行为，系统也将口初其个人信用值。
3.3.2评价指标
客户搜索到所需商品后，可以查询卖方信用级别。
对于普通顾客，信用指标涉及：其在本网站登陆时间，上站时间，个人银行账户金额。
对于店铺顾客，信用指标涉及：其在本网站注册历史，个人银行账户金额以及浮现违约次数。
3.3.3也许浮现问题：
由于无法本系统没有对零散客户买方交易进行监控，因而没有对普通零散买卖双方进行很完善信用评价。仅仅用了简朴评价指标，不能完全体现普通顾客交易信用。
3.3.4信用体制解决问题：
1. 保证买方利益，约束卖方交易行为；
2. 敦促卖家（店铺）尽快将已售商品下架 ；
3. 为买卖双方提供一定信用参照

由于本系统是针对C2C网上商店，不太也许有一种非常完善信用体制。信用体制建立是在理性消费者假设上，也就是假设理性消费者不会做损人不利己事。事实上，本系统作为信息发布平台，对信用规定也是有限。针对咱们有限信用规定，信用体制上某些未解决问题给系统带来危害也并不是很大。
3.4收费机制：
本系统引入虚拟货币机制：每个顾客均有虚拟货币帐户，虚拟货币与实际货币硬性等价转换。由此，无论是普通顾客还是店铺顾客，如果需要发布商品信息，一方面通过实款缴纳转化成虚拟货币。
普通顾客在发布信息时费用从虚拟账户扣除，按卖方所需，每个商品设立不同保存时间，按不同步间收取费用，在规定期间内如卖方未将商品下架，系统自行删除商品。
店铺顾客由系统管理员定期从其虚拟账户上扣除。店铺顾客可以申请不同空间集中展示自己商品。按不同空间收取不同会员费用。
对于零散顾客在注册之初，本系统予以一定货币金额。卖方顾客可以发布有限条商品信息，满足只发布几条信息顾客所求。
对于店铺顾客，在规定期间可以结算。保存一定金额后可以兑出。

需要阐明是在本系统试运营初期，并不顾客收费。在运营一定期间后由管理者按市场环境决定何时进行收费。
3.5 系统数据流程

图3
上图表白了系统中数据流程，从数据角度重新分析了业务中交易流程和信用评价流程。
卖方注册时有关信息就将记录在系统中客户信息数据库中。顾客信息涉及顾客常规信息以及卖方顾客类型：店铺型，零散型。
卖方在提交商品信息给系统时，系统会自动检测顾客货币量与否足够。只有保存一定量虚拟货币，卖方商品信息才干成功提交给系统。成功后，系统将商品信息展示在网站上并记录在数据库中。
买方通过检索网站上展示商品搜寻到所满意商品。在拟定购买前，买方还可以查询卖方信用信息以判断与否购买。如果没有搜寻到商品，可以在本系统登记所需商品。
决定购买后，提交定单。系统将定单记录保存。卖方自行解决定单。
如若在交易中浮现了某方欺诈行为可以在本系统进行投诉。系统将投诉进行记录，并在核算后对欺诈方进行惩罚，对其信用值进行扣减。
3.6 系统实体关系图
系统实体涉及：买方、卖方、系统管理员以及商品。

买方可以发布商品需求，可以对商品进行评价，同步可以购买商品。
卖方可以发布并修改商品信息，对商品进行评价，出售商品。

顾客在注册中以及注册后都可以申请权限升级。当在交易中浮现问题时顾客可以向系统管理员进行投诉。管理员拥有对顾客信用值进行管理权限。
同步，所有顾客都可以对各个店铺进行信用评价权利，并且系统管理员可以对所有商品以及商品目录进行管理。
四 系统设计
4.1系统运营基本环境
CPU：1.0G Hz 以上（推荐）
内存：128M 以上（推荐）
操作系统：Windows
技术选取：PHP（Smarty Template Engine）
构架选取：MVC
DBMS选取：MySQL
构架实现选取：Smarty

4.2 数据库设计
4.2.1 数据库分析与数据库规范
依照数据流程分析和ER分析，实体以及实体间关系可以讲数据库提成：
users，products，orders，assess，requires，categories，mailbox，message
个表。
按照表与表之间一对一或一对多原则，可以将表重新设计为：
users，shop，products，orders，orders_items，assess，requires，products_categories，categories，mailbox，message。
各表中属性涉及：
users (username，password，priv，firstname，lastname，email，phone，address，account，credit，prop，logintime，favorite )
products (id，username，name，description，price，on_special，timestamp，assess_id，on_advice)
requirs (id，username，name，description，price，amount，timestamp)
orders (id，username，o_timestamp，a_timestamp，status，status_detail，custionfo，comments，amount)
order_item (order_id，producst_id，price，qty，state)
products_categories (product_id，category_id)
categories (id，parented，name，description，products_id，category_id)
shop (id，username，name，size，u_size，description，assess_id)
assess (id，username，prop，description)
emailbox (username，t_size，used_size)
message (id，username，send_time，title，size，receive_time，content )
其中，加横线为表中主键，波浪线为其外键。
在users表中，username是顾客主键，priv代表顾客权限，与否为管理员，prop代表顾客属性，是店铺顾客还是普通顾客，account为顾客虚拟账户，credit是顾客信用评价值，logintime是顾客注册时间。
products记录了商品信息。on_special，on_advice表达商品与否为特价商品以及与否为广告商品，assess_id将商品和对它评价信息关联。
requires表，记录了顾客对商品需求。
orders表记录顾客每笔定单。order_item将orders表和products表有关联。一种定单可以订各种商品，一种商品也可以被各种人订取。
categories记录是商品目录。同样，products_categories表将categories和products表有关联。一种商品属于一种目录，但一种目录下可以有各种商品。
shop表记录是每个店铺顾客开社商店信息。assess_id将记录对商店评价信息与shop有关联。
assess表记录了顾客对商品或者对商店评价。其中prop区别了此两者用途，
emailbox和message表分别记录了顾客消息箱以及每条消息。
4.2.2数据表、数据项之间关系
数据库中各个表单之间关系以及数据项间关系间下图。图中表及其关联表达了表中属性类型以及表和表之间关联关系。
强关联关系规定一种商品必要相应一种顾客，一种定单必要对于一种顾客，一种ordr_items必要相应一种orders表，一种shop必要相应一种顾客，products_categorites必要同步相应一种products和一种categories表单，一种emailbox表单必要相应一种users表，一种massage必要相应一种users表。
图中表达出了各表之间主键和外键。

图4

4.3系统设计
4.3.1 MVC简介
M：Model 模型
V：View 视图
C：Controller 控制器

图5
4.3.1.1 M-V-C各自职责：
Model 作用重要是封装数据及系统状态，此外太还要解决商业逻辑，但是在当前设计中普通是把商业逻辑此外分开（PHP）
View 是用来显示和发送request一种UI，在View普通没有商业解决，只是将要解决数据格式化（HTML）
Controller 它只要负责接受request，选取相应response视图，并传递模型数据（PHP）
4.3.1.2 M-V-C特点
开发MVC系统比简朴PHP开发要复杂一点，它需要更多时间学习和掌握。同步新东西引入会带来新问题：
必要基于MVC组件方式重新思考和设计应用构造。本来通过建立一种简朴 PHP页面就能实现应用当前变成了各种环节设计和实现过程。
所有页面和组件必要在MVC框架中实现，因此必要进行附加地开发工作。
MVC自身就是一种复杂系统，因此采用MVC实现Web应用时，最佳选一种现成MVC框架，在此之下进行开发，从而获得事半功倍效果。当前有诸多可供使用MVC框架，由于Smarty有完整文档并且相对来讲比较简朴，因此用它开发MVC系统还是比较以便地。
此外阐明，严格说Smarty不是一种MVCFramework，只是一种Template Engine，但是咱们可以用Smarty来实现MVC
4.3.2 Smarty简介
*Smarty是PHP官方样版引擎
1．什么是样版引擎
样版引擎目是要达到逻辑分离功能。它能让程序开发者专注于数据控制或是功能达到；而视觉设计师则可专注于网页排版，让网页看起来更具备专业感。
2．Smarty如何运作？

图6
3．Smarty在系统中角色

图7
4.3.3 为什么选用MySQL
MySQL是一种免费强大DBMS
免费：没有赞助和投资咱们只能选用免费DBMS
强大：MySQL虽然是一种免费产品，但是它功能和效率绝对比商业DBMS要弱，并且MySQL后来将更SAP合伙，这样MySQL将会有较好前景
MySQL和PHP是最佳组合，特别在Linux下有最佳效率
4.3.4 持久层设计
咱们当前选用是MySQL作为咱们DBMS，但是也要考虑系统数据库移植到别DBMS因而咱们要先第一种统一Interface，然后有不同实现。在系统数据库变化后咱们可以不变化咱们界面和业务实现。
当前咱们系统支持：
mySQL ，Oracle8/9 ,InterBase，FireBird ，PostgreSQL,MS-SQL ,SQLite ,SQLite c++
默认实现为：MySQL

图8
此外咱们把咱们持久设计较好Smarty集成在一起（详细实现不在这里详细讲述）
4.3.5 系统整体设计
将以上设计整合成一种系统

图9
系统为了后来扩展应当支持模块动态插入，也就是真个系统应当是类似一种CMS系统

图10
4.3.6顾客权限设计
1．权限管理总体目的
权限管理子系统实现系统权限管理某些功能。以用例（User Case）分析办法，可以得出，系统权限管理子系统满足三种重要功能。
获取访问项列表
根据预先为顾客配备好权限设立，来获取某顾客所能访问访问项列表。
访问可访问项
顾客通过访问项列表来访问某一可访问项时，权限管理子系统予以权限控制，如：允许、不允许、只读等。
权限管理
设立顾客、顾客组与访问项之间访问关系，也即咱们熟悉权限指派、配备等。同步，在这个设计中，使用“顾客组”来归属相似权限属性“顾客”。可见，顾客组是一种与权限管理直接有关对象，所有，顾客、顾客组关联管理也是权限管理子用例一种重要构成某些

2．权限管理对象模型

“Module”代表系统中可访问模块。
“Privilege”代表权限，如：禁止、只读、读写、完全控制。
“User/Group”顾客，和具备相似访问属性顾客容器――顾客组。之间存在1对多关系。
“Access”访问关联，连接Module和Group，并为其绑定权限――Privilege
3．权限管理数据模型