老师，很抱歉上一次作业更改题目没有及时将消息告知。
一、数据库设计
1.1 Ｅ-Ｒ图(用Powerdesigner画CDM)
1.2 数据字典
表1-1 用户表
|
表名 |
webuser(用户表) |
主键 |
webuser_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
webuser_id |
Char |
10 |
不允许 |
用户编号，唯一标识用户的字段，以U开头 |
|
usertype_id |
char |
10 |
不允许 |
用户类别id，所有注册用户默认为0,以UTY开头 |
|
User_account |
varchar |
50 |
不允许 |
用户登录账号，为手机 |
|
User_pwd |
varchar |
50 |
不允许 |
用户密码，可以为数字和字母和其他符号组成，规定长度在6~20之间 |
|
user_name |
nvarchar |
20 |
允许 |
用户昵称，字符不超过20的任意字符 |
|
user_sex |
char |
2 |
允许 |
用户性别，可为空 |
|
User_tel |
char |
11 |
不允许 |
联系用户的方式，规定为0-9数字组成 |
|
User_icon |
varchar |
50 |
允许 |
用户头像 |
|
User_point |
int |
|
不允许 |
用户积分，默认初始为0.00 |
|
reg_time |
datetime |
|
不允许 |
用户注册时间, 默认系统时间 |
|
Bank_card |
varchar |
10 |
允许 |
银行卡号 |
|
Balance |
char |
11 |
允许 |
账户余额 |
|
Pay_pwd |
money |
|
允许 |
支付密码 |
|
Webuser_id |
char |
10 |
不允许 |
用户编号 |
表1-2 用户类别表
|
表名 |
usertype（用户类别表） |
主键 |
usertype_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
usertype_id |
Char |
10 |
不允许 |
用户类别id，分为0,1，所有注册用户默认为0，用户类别名，0对应‘普通’，1对应‘会员’,以UTY开头 |
|
usertype_name |
char |
4 |
不允许 |
用户类别名，默认为普通 |
表1-3 商品表
|
表名 |
produce(商品表) |
主键 |
pro_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
pro_id |
Char |
10 |
不允许 |
商品编号,以pro开头 |
|
pro_name |
nvarchar |
20 |
不允许 |
商品名称，以汉字或者英文字母组成 |
|
protype_id |
int |
|
不允许 |
商品类别id,有0-9数字组成，代表该商品类别（肉类，蔬菜，海鲜……） |
|
pro_price |
money |
|
不允许 |
商品单价 |
|
pro_amount |
int |
|
不允许 |
商品库存，默认所有商品库存为200 |
|
pro_icon |
varchar |
50 |
不允许 |
商品图片路径 |
|
pro_info |
ntext |
|
允许 |
商品简介（250字内） |
|
pro_disprice |
money |
|
允许 |
商品打折价格 |
|
collect_num |
int |
|
允许 |
商品被收藏次数,默认零 |
表1-4 商品类别表
|
表名 |
protype(商品类别表) |
主键 |
protype_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
protype_id |
Char |
10 |
不允许 |
商品类别id,有0-9数字组成，代表该商品类别（肉类，蔬菜，海鲜……）,以PTY开头 |
|
protype_name |
nvarchar |
10 |
不允许 |
商品类别名（蔬菜，肉类，海鲜，野味……） |
表1-5 收藏表
|
表名 |
collect(收藏表) |
主键 |
collect_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
collect_id |
Char |
10 |
不允许 |
收藏编号,以COL开头 |
|
webuser_id |
Char |
10 |
不允许 |
用户编号，唯一标识用户的字段，以U开头 |
|
pro_id |
char |
10 |
不允许 |
商品编号 |
|
collect_time |
datetime |
|
不允许 |
收藏时间，默认系统时间 |
表1-6 评价表
|
表名 |
comment(评价表) |
主键 |
comment_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
com_id |
Char |
10 |
不允许 |
用户评论id ,以COM开头 |
|
order_id |
Char |
10 |
不允许 |
订单编号，以O开头 |
|
pro_id |
char |
10 |
不允许 |
商品编号，以PRO开头 |
|
com_time |
datetime |
|
不允许 |
用户评价时间，默认系统时间 |
|
com_message |
ntext |
|
不允许 |
用户发表评论内容,任意可打印字符 |
|
Com_pic |
varchar |
50 |
允许 |
评价图片 |
|
Com_score |
Int |
|
允许 |
评价等级分数 |
|
Com_seq |
Int |
|
不允许 |
评价序号,以区分是首次评价还是追加评价 |
表1-7 收货地址表
|
表名 |
useraddress(收货地址表) |
主键 |
Address_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
address_id |
Char |
10 |
不允许 |
收货地址编号，唯一标识用户的收货地址字段,以add开头 |
|
webuser_id |
char |
10 |
不允许 |
用户编号，唯一标识用户的字段 |
|
address |
nvarchar |
100 |
不允许 |
收货地址，由任意可打印字符组成 |
表1-8 订单表
|
表名 |
orders(订单表) |
主键 |
order_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
order_id |
Char |
10 |
不允许 |
订单编号 |
|
webuser_id |
char |
10 |
不允许 |
用户编号，唯一识用户的字段 |
|
order_time |
datetime |
10 |
不允许 |
订单时间，默认系统时间 |
|
order_sum |
money |
|
不允许 |
订单总价 |
|
address_id |
char |
10 |
不允许 |
收货地址编号，唯一标识用户的收货地址字段，规定长度为11位数字 |
|
order_state |
char |
6 |
不允许 |
五个字符串常量：“待付款”、“待配送”、“待收货”、“待评价”、“已评价” |
|
del_money |
money |
|
允许 |
配送费 |
|
del_id |
char |
10 |
允许 |
配送员编号 |
|
del_time |
datetime |
|
允许 |
配送时间 |
|
rec_time |
datetime |
|
允许 |
送达时间 |
表1-9 订单明细表
|
表名 |
orderinfo(订单明细表) |
主键 |
Order_id,produce_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
produce_id |
char |
10 |
不允许 |
商品编号 |
|
order_id |
Char |
10 |
不允许 |
订单编号 |
|
order_amount |
int |
|
不允许 |
所订购的商品数量 |
|
return_goods |
Boolean |
|
不允许 |
判别用户是否申请退货 |
|
refund |
boolean |
|
不允许 |
判别用户是否申请退款 |
表1-10 配送员表
|
表名 |
deliveryman |
主键 |
delivery_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
del_id |
Char |
10 |
不允许 |
配送员编号,以del开头 |
|
del_name |
varchar |
10 |
允许 |
配送员姓名 |
|
del_tel |
char |
11 |
允许 |
配送员联系电话 |
|
del_wage |
money |
|
允许 |
配送员工资 |
|
del_pwd |
varchar |
50 |
不允许 |
配送员密码 |
|
del_account |
varchar |
50 |
不允许 |
配送员账号 |
|
del_point |
int |
|
允许 |
配送员信用评分 |
表1-11 售后表
|
表名 |
Sale_back |
主键 |
Saler_id、Pro_id、Order_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
Saler_id |
Char |
10 |
不允许 |
商家编号 |
|
Pro_id |
Char |
10 |
不允许 |
商品编号 |
|
Order_id |
Char |
10 |
不允许 |
订单编号 |
|
Deal_time |
datetime |
|
不允许 |
处理时间 |
|
Refund_money |
money |
|
不允许 |
退款金额 |
表1-12 商家回复表
|
表名 |
Saler_reply |
主键 |
Com_id,saler_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
Com_id |
Char |
10 |
不允许 |
用户评价编号 |
|
Saler_id |
char |
10 |
不允许 |
商家编号 |
|
Reply_time |
datetime |
|
允许 |
回复时间 |
|
Reply_context |
varchar |
200 |
允许 |
回复内容 |
表1-13 商家表
|
表名 |
Saler |
主键 |
Saler_id |
|
|
列名 |
数据类型 |
长度 |
是否允许为空 |
描述 |
|
Saler_id |
Char |
10 |
不允许 |
商家编号，以s开头 |
|
Saler_pwd |
varchar |
20 |
允许 |
登录密码 |
|
Saler_account |
varchar |
50 |
允许 |
商家登录账号 |
1.3 安全性
(1) 角色：数据库管理员（商家）、顾客、游客、配送员
(2) 用户：数据库管理员、顾客、游客、配送员
(3) 登录名：saler、customer、visitor、deliveryman
(4) 用户密码：使用PWDENCRYPT()加密存放。
1.4 存储过程设计
|
序号 |
过程名 |
功能 |
入口参数 |
权限 |
|
1 |
proc_WebUserInsert
|
实现用户注册，将用户密码经过MD5加密后存入数据库。
|
用户账号，密码，用户名，性别，联系电话 |
管理员、顾客 |
|
2 |
proc_WebUserSelectLogin
|
用户登录，使用PWDCOMPARE函数比对输入的密码与数据库中经过加密的是否一致。
|
用户账号，密码 |
管理员、顾客 |
|
3 |
proc_ProduceSelect
|
分类浏览商品，显示排序后的结果 |
商品类别编号，排序字段，排序类别 |
管理员、顾客 |
|
4 |
proc_ProdeuceNameSelect
|
搜索商品名字 |
关键字 |
管理员、顾客 |
|
5 |
proc_ProduceIdSelect
|
查看商品详情 |
商品编号 |
管理员、顾客 |
|
6 |
proc_OrdersInsert
|
生成订单 |
用户编号，商品编号列表，商品数量列表，收货地址编号 |
管理员、顾客 |
|
7 |
proc_OrdersInfoInsert
|
生成订单明细 |
订单编号，商品编号，商品数量 |
管理员、顾客 |
|
8 |
proc_OrdersInfoOrderIdSelect
|
查看某个订单 |
订单编号 |
管理员、顾客 |
|
9 |
proc_OrdersStateSelect
|
查看用户的订单列表 |
用户编号，订单状态 |
管理员、顾客 |
|
10 |
proc_OrderStateUpdatePay
|
付款操作 |
订单编号，用户编号 |
管理员、顾客 |
|
11 |
proc_OrderStateUpdateReceive
|
收货操作，用户对某个订单进行收货 |
订单编号 |
管理员、顾客 |
|
12 |
proc_OrderStateUpdateComment
|
评价商品操作 |
商品编号，订单编号，评价内容 |
管理员、顾客 |
|
13 |
proc_CollectInsert
|
收藏商品 |
商品编号，用户编号 |
管理员、顾客 |
|
14 |
proc_WebuserUpdate
|
修改用户信息 |
用户名，性别，联系电话，用户编号 |
管理员、顾客 |
|
15 |
proc_WebuserSelect
|
查看用户信息 |
用户账号 |
管理员、顾客 |
|
16 |
proc_AddressForWebuserIdSelect
|
用户查看本人的收货地址 |
用户编号 |
管理员、顾客 |
|
17 |
proc_AddressIdSelect
|
查看收货地址信息 |
地址编号，用户编号 |
管理员、顾客 |
|
18 |
proc_AddressInsert
|
添加收货地址 |
用户编号，地址信息 |
管理员、顾客 |
|
19 |
proc_AddressUpdate
|
修改地址内容 |
地址编号，地址信息 |
管理员、顾客 |
|
20 |
proc_AddressDelete
|
删除收货地址 |
地址编号 |
管理员、顾客 |
|
21 |
proc_WebuserAccountMoneyUpdate
|
用户充值 |
用户编号，充值金额 |
管理员、顾客 |
|
22 |
proc_showProduceSaleOfStage
|
统计某个时间段的每个商品销售量，显示商品编号，开始时间，结束时间，销售数量 |
开始时间，销售时间 |
管理员、顾客 |
|
23 |
proc_showProduceSaleAll
|
统计每个商品总销售量，显示商品编号，商品名称，销售数量 |
无 |
管理员、顾客 |
|
24 |
proc_showUserOrderNumOfStage
|
统计某个时间段每个用户订单情况，显示用户编号，用户时间，订单数量，开始时间，结束时间，付款总金额 |
开始时间，结束时间 |
管理员 |
|
25 |
proc_showUserOrderNum
|
统计每个用户订单情况，显示用户编号，用户名称，订单数量，付款总金额，平均每单付款金额 |
无 |
管理员 |
|
26 |
proc_OrderStateSelectForDelivery |
配送员查找“待配送”状态的订单 |
无 |
管理员、配送员 |
|
27 |
proc_OrderStateUpdateDelivery |
配送员接单,将配送编号插入订单表中，更新配送时间为当前时间 |
配送员编号,订单编号 |
管理员、配送员 |
1.5 触发器设计
|
序号 |
触发器名 |
功能 |
类型 |
作用表 |
|
1 |
tri_orderinfoInsert_UpdateOrders
|
插入订单明细时，更新订单总金额 |
Insert |
Orderinfo(订单明细表) |
|
2 |
tri_orderinfoInsert_UpdateProduce
|
插入订单明细时，更新商品库存 |
insert |
Orderinfo(订单明细表) |
|
3 |
tri_produceUpdate
|
更新商品库存，检查商品库存是否小于20，小于20的提醒商家进货 |
update |
Produce(商品表) |
|
4 |
tri_ordersUpdate1
|
修改订单时，统计用户不是待付款状态的订单数量，修改用户级别 |
update |
Orders(订单 表) |
|
5 |
tri_orderStateUpdate2
|
付款修改订单状态时，修改用户余额 |
update |
Orders(订单表) |
|
6 |
tri_commentInsert
|
插入评价记录时，修改订单状态 |
insert |
Comment(评价表) |
|
7 |
tri_collectInsert
|
插入收藏记录时，统计商品收藏次数，修改collect_num值 |
Insert |
Collect(收藏表) |
|
8 |
tri_recommand_produce
|
每次用户下单成功后，推荐该用户购买数量最多的同类别商品 |
update |
Orders(订单表) |
|
9 |
tri_orderStateUpdate3
|
修改订单状态为待评价时，更新配送员的工资 |
Update |
Orders(订单表) |
二、典型用户和典型场景
2.1 典型用户列表
表2-1
|
典型用户 |
特点 |
|
上班族 |
工作繁忙，生活节奏快。 |
|
大学生 |
大学生在寝室偶尔会煮一些东西吃，但量的大小不定，而寝室也无法处理超市买回来的食材，购菜系统里包装精良的现成菜品是不二选择。 |
|
配送员 |
如何快速接单，高效配送。 |
|
供应商 |
供应菜品 |
|
网站管理员 |
拥有管理该网站的权限，可以对所有用户和微博进行操作。 |
|
网站破坏者 |
入侵网站、盗窃他人账号等威胁人群。 |
2.2 典型用户和典型场景
表2-2
|
名字 |
胡一统 |
|
用户性别 |
男 |
|
用户属性 |
上班族 |
|
动机、目的、困难 |
动机：喜爱做饭，但由于工作太忙，每天的午饭晚饭都靠着外卖来解决。想要买菜做饭但时间不允许。 困难：如何把蔬菜配合工作时间合适的时间送货上门。 |
|
典型场景 |
下单购菜，与配送员交接 |
表2-3
|
名字 |
王文 |
|
用户性别 |
女 |
|
用户属性 |
大学生 |
|
动机、目的、困难 |
动机：突发奇想在寝室煮火锅，但懒得去超市购买菜品。 困难：由于需求的菜品量大，对配送员还是提供点都是需要时间的。且用户不需要太过精确的对接时间，需要提前下单，并且在一个时间段之内送到即可。 |
|
典型场景 |
提前下单，预计送达。预计送达的前后一小时内与配送员对接。 |
表2-4
|
名字 |
吴所谓 |
|
用户性别 |
男 |
|
用户属性 |
配送员 |
|
动机、目的、困难 |
动机：每一笔订单按公里数，菜品重量，送达时间等计费 困难： 如何在规定时间送达菜品，如何高效接单。 |
|
典型场景 |
接单，配送 |
表2-5
|
名字 |
陈恩 |
|
用户性别 |
女 |
|
用户属性 |
供应商 |
|
动机、目的、困难 |
动机：面面交易无法满足所有人的需求，新的方式可以卖出更多蔬菜，同时也满足了更多人的需求，和网站的合作互利共赢。 困难：需要对菜品做进一步处理，浪费人力和时间。有时菜品供不应求。 |
|
典型场景 |
查看用户订单并通过订单准备需要处理的蔬菜，在规定时间内处理完成。 |
表2-6
|
名字 |
赵端 |
|
用户性别 |
男 |
|
用户偏好 |
维护网站的安全、正常运行。管理网站的信息安全和信息合法。 |
|
动机、目的、困难 |
动机：作为管理员，维持网站运行的秩序。 困难：目前仍需要提防有恶意用户攻击网站、窃取用户隐私数据。 |
|
典型场景 |
网站管理端 |
表2-7
|
名字 |
Black |
|
用户性别 |
男 |
|
用户偏好 |
以入侵别人的网站，获取到网站管理员权限为乐。 |
|
动机、目的、困难 |
动机：入侵网站、炫耀自己的技术。 困难：网站的安全意识高，网站存在的漏洞少。 |
|
典型场景 |
忘记密码、用户登录。 |
三、软件原型设计
3.1 用户
3.2 商家
3.3 配送员
四、功能模块设计
4.1 用户：
4.1.1 注册：Void CustomerZhuce();注册账号，可以通过手机或者邮箱进行注册。
4.1.2 登录：Void CustomerDenglu();利用账号密码登录，或者手机验证码登录。
4.1.3 修改用户信息：Void CustomerXiugai();可以修改用户的收货地址、昵称、姓名等等
4.1.4 找回密码：Void CustomerFindPassword();可以通过邮箱找回、通过手机找回或者通过客服申述找回
4.1.5 用户点评：Void Dianping();用户对已经收到的菜进行评价。
4.1.6 下单：Void Xiadan();用户通过在网页浏览到的商品添加入购物车，然后最后在结算的时候向商家付款，从而生成订单。
4.1.7 查看订单：Void CustomerSelectOrder();用过查看自己下的单的信息
4.2 商家：
4.2.1 登录：Void MerchantZhuce();利用账号密码登录，或者手机验证码登录。
4.2.2 注册：Void MerchantDenglu();注册账号，可以通过手机或者邮箱进行注册。
4.2.3 订单管理：Void ManagerSelectOrder ();查看订单的状态，并对订单进行一些相应的管理，如退单等。
4.2.4 统计功能：Void SumFunction();统计近期菜品的销量及销量总额。
4.2.5 回复评价：Void Reply();在线回复用户的评价。
4.2.6 添加/删除/修改商品：Void AddGoods();添加商品
Void DeleteGoods();删除商品
Void ChangeGoods();修改商品的信息
4.3 配送员：
4.3.1 登录：Void DelivererZhuce();利用账号密码登录，或者手机验证码登录。
4.3.2 注册：Void DelivererDenglu();注册账号，可以通过手机或者邮箱进行注册。
4.3.3 查看配送单：Void DelivererSelectOrder ();配送员可以查看自己所需配送的订单信息。
4.3.4 查看工资：Void SelectSalary();配送员可以查看自己的工资。
五、代码管理和开发流程
5.1 日期规划表
5.2 代码管理
- 版本控制系统Git，代码托管采用Github仓库，可采用可视化工具：桌面版Github。
- Branch分支：采用B/S架构，前端在browser分支开发，后端在server分支开发，前后端的成员均在自己的分支开发后融合(merge)到browser、server分支，然后讲 browser、server分支融合到master分支。
5.3 开发流程
5.3.1 软件团队模式：
业余剧团模式，每个人挑选角色，开发过程中发展为功能团队模式
5.3.2开发流程：
主体为敏捷流程，但密度稍有降低，以周为单位，一定程度上接近渐进交付的流程。
5.3.3 敏捷流程：
第一步：Product Backlog 确定待实现的需求和待解决的问题(Backlog)，产品负责人主导大家对于这个Backlog进行增/删/改工作。考虑到并不是职业的开发团队，而是学生实践项目，每一项工作的时间估计单位为“周”。
第二步：Sprint Backlog 分解需求或者问题，分解为以“周”为单位的任务，由团队成员认领任务。任务并不是Master一人制定的，而是由团队成员共同商讨出方案。团队成员能主导任务的估计和分配。
第三步：Sprint 团队成员在单位时间(周)独立开发，期间不受其它被更改的需求的干扰。但这种独立并不是绝对的，Master需要沟通所有成员的意见。需要注意的是必须保证团队成员集中注意力开发。
以周为单位的Scrum Meeting 中每个成员汇报进度，不管是未解决的问题还是新产生的问题，每个成员都可以提出看法和解决思路。结合每周的工作量，用图表展示整个项目的进度，有利于团队成员调整节奏和进度。
第四步：得到软件的一个增量版本，结合代码管理，此时可以融合不同分支，根据现有的功能的实现构建新的版本，发布，团队成员使用结合测试，在此基础上又进一步计划增量的新功能和改进。
5.3.4 额外的说明
瀑布模型：最终产品直到最后才实现，前期需要详细的设计，因为没有专业的设计人员和管理人员，所以瀑布模型不适合本团队。
渐进交付的流程：开发->发布->听取反馈->根据反馈做改进
敏捷流程：原则：变化的需求，多次发布，沟通。
