C2C网上交易平台系统分析与设计报告.docx
《C2C网上交易平台系统分析与设计报告.docx》由会员分享，可在线阅读，更多相关《C2C网上交易平台系统分析与设计报告.docx（21页珍藏版）》请在冰点文库上搜索。
C2C网上交易平台系统分析与设计报告
C2C网上交易平台系统分析与设计报告
电子商务01级
2004年9月
小组成员：
陈剑郝雪梅
吴双吴婷
薛莉丽赵柏敏
一、项目定义
本系统旨在构建一个以学生为买方主体的C2C网上商店。
面向南大浦口、鼓楼学生以及外校的部分年轻人群。
主要的角色包括买方、卖方和系统管理员。
卖方除了一般的零散客户还为供应较多、较稳定的大型卖者提供个人店铺空间。
二、需求分析
2.1C2C市场存在的意义
随着人们消费水平的提高，个人消费品市场空前发展，我们发现，越来越多的人拥有大量的闲置商品。
这些商品有新有旧，但都具有完整的使用价值。
拥有者们也许现在不需要它们，便想到把它们出售。
可是如何找到买主，却成为一个令人头疼的问题。
以学生为例。
由于学生爱追赶时尚潮流，而且购买行为往往缺乏计划性，使得他们常常因一时冲动买下某物，之后又发现并没有用。
学生对于电脑、手机、MP3等电子产品需求较多，而这些东西更新又很快，需求的不同使他们希望能互通有无。
一些旧书籍、杂志、音像制品、生活用品等，也是留之无用、弃之可惜，若能卖给需要的人不是皆大欢喜?
与此同时，随着学生们的商品意识的加强，有很多同学以代理商品销售为兼职，有开设个人店铺的需求。
但由于资金方面的限制，不可能开设真正的店铺。
可是由于供需双方市场的不对称性，卖主很难找到合适的买主，有这些需求的人更是不知道有谁要出售，造成这种C2C交易很难达成。
目前普遍的办法是卖者在校内摆个地摊。
做代销的同学到处帖广告或者直接上门推销，展示并出售自己的商品，可是时间、地点、规模都受到限制，而且要耗费大量的时间和体力，还未必有好的效果。
要是有一个平台，让供需双方集中地发布交易信息，并提供双方的联系方式，促成其交易的达成，将为买卖双方带来极大的便利。
2.2现存C2C市场的缺陷
面对如此商机，精明的商家不会无动于衷，现在C2C网上交易市场已经发展壮大起来。
但是我们分析后发现，现存C2C市场存在着一些缺陷，尤其不能适应校园市场的需求。
我们调查发现，目前C2C网站中大部分都是拍卖网站。
当然，拍卖作为C2C的主导交易模式，其优点是存在的，但它的缺陷也是明显的：
交易时间长，买卖双方要耗费大量的时间和精力。
这种模式适合于价值较高的商品，而学生的闲置商品往往是耐用消费品，价值较低，拥有者希望尽快出手，而并不想耗费太多精力计较一点价格差异，因此拍卖模式对校园市场尤其不适合。
现存的另一种C2C网上交易市场就是类似于小百合bbs的fleamarket。
这是以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.0GHz以上（推荐）
内存：
128M以上（推荐）
操作系统：
Windows2000
技术选择：
PHP（SmartyTemplateEngine）
构架选择：
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.1MVC简介
M：
Model模型
V：
View视图
C：
Controller控制器
图5
4.3.1.1M-V-C各自的职责：
Model的作用主要是封装数据及系统的状态，另外太还要处理商业逻辑，但是在目前的设计中通常是把商业逻辑另外分开（PHP）
View是用来显示和发送request的一个UI，在View通常没有商业处理，只是将要处理的数据格式化（HTML）
Controller它只要负责接受request，选择相应的response视图，并传递模型数据（PHP）
4.3.1.2M-V-C的特点
开发MVC系统比简单的PHP开发要复杂一点，它需要更多的时间学习和掌握。
同时新东西的引入会带来新的问题：
必须基于MVC组件的方式重新思考和设计应用结构。
原来通过建立一个简单的PHP页面就能实现的应用现在变成了多个步骤的设计和实现过程。
所有的页面和组件必须在MVC框架中实现，所以必须进行附加地开发工作。
MVC本身就是一个复杂的系统，所以采用MVC实现Web应用时，最好选一个现成的MVC框架，在此之下进行开发，从而取得事半功倍的效果。
现在有很多可供使用的MVC框架，由于Smarty有完整的文档并且相对来讲比较简单，所以用它开发MVC系统还是比较方便地。
另外说明，严格的说Smarty不是一个MVC的Framework，只是一个TemplateEngine，但是我们可以用Smarty来实现MVC
4.3.2Smarty简介
*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,SQLitec++
默认实现为：
MySQL
图8
另外我们把我们的持久设计很好的Smarty集成在一起（具体实现不在这里详细讲述）
4.3.5系统整体设计
将以上的设计整合成一个系统
图9
系统为了以后的扩展应该支持模块的动态插入，也就是真个系统应该是类似一个CMS系统
图10
4.3.6用户权限设计
1．权限管理的总体目标
权限管理子系统实现系统的权限管理部分的功能。
以用例（UserCase）分析的方法，可以得出，系统的权限管理子系统满足三种主要的功能。
获取访问项列表
依据预先为用户配置好的权限设置，来获取某用户所能访问的访问项列表。
访问可访问项
用户通过访问项列表来访问某一可访问项时，权限管理子系统给予权限控制，如：
许可、不许可、只读等。
权限管理
设置用户、用户组与访问项之间的访问关系，也即我们熟悉的权限指派、配置等。
同时，在这个设计中，使用“用户组”来归属相同权限属性的“用户”。
可见，用户组是一种与权限管理直接相关的对象，所有，用户、用户组关联管理也是权限管理子用例的一个重要组成部分
2．权限管理的对象模型
“Module”代表系统中的可访问模块。
“Privilege”代表权限，如：
禁止、只读、读写、完全控制。
“User/Group”用户，和具有相同访问属性的用户容器――用户组。
之间存在1对多的关系。
“Access”访问关联，连接Module和Group，并为其绑定权限――Privilege
3．权限管理的数据模型
升级会员 