老师,很抱歉上一次作业更改题目没有及时将消息告知。
一、数据库设计
1.1 E-R图(用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 额外的说明
瀑布模型:最终产品直到最后才实现,前期需要详细的设计,因为没有专业的设计人员和管理人员,所以瀑布模型不适合本团队。
渐进交付的流程:开发->发布->听取反馈->根据反馈做改进
敏捷流程:原则:变化的需求,多次发布,沟通。