第四次团队作业——系统设计

目录

一.《需求规格说明书》初稿的不足

---

总结了一下，主要有一下不足：

1.注册功能的抢注

问题

栋哥在课堂上对我们小组的注册功能进行了一番猛烈“抨击”——我们是用学号注册的，但是如果学号唯一的话，被别人注册了，就没辙了。其实，这点我们之前是讨论过的。橙汁采用的办法是，用户名自己随便注册，但是在个人信息中，填入学号，并不会冲突。

栋哥说了一种情况，就是报名的时候，A用B的学号报名活动1，B也用自己的活动报名活动1，会不会冲突。其实是不会的，报名表上到时候相同的学号只会产生一个。

解决

为了从根本上解决冲突的问题，我们将注册功能重新构建。新增手机号发送验证码来避免抢注事情的发生。将学号作为主键，为了确保一个手机号对应一个学号，学号注册完无法更改。

2.角色身份之管理员

问题

最开始我们小组的设想，我们程序员本身就是管理员。直到被栋哥问的时候才意识到，产品一旦交出去，程序员便不再使用。所以权限的管理必须需要一个专门的管理员角色来管理

解决

我们新增了管理员的角色，并专门为他做了一个界面。在程序登录的界面中，可以选择自己的身份，并登陆。在管理员界面中，有着四个功能，分为两类，审核与管理。

3.发布新活动之推送范围

问题

我们之前所设想的方案，是根据学号来进行身份的解析，定点投放通知消息。栋哥问的时候，说如何确定投送范围？原本的原型上，写着的是1、2、3三个等级分别代表着校级、院级、班级。答辩的时候有点懵，一时不知道该回答是年级还是班级。。。其实这样的方案是有问题的，比如我想投放“数计学院14级全体学生”，这时候你按这个1、2、3根本没什么用。。。😂。然后我们才恍然大悟。

解决

我们在注册的时候，就让同学选择自己所在院系年级，并且去掉了班级。班级的通知一般用QQ群，我们面向的主要是大范围的信息推送。
在活动发布的时候，也是可以选择推送范围的，这时候是直接出现了具体的院系跟年级，不像之前那毫无用处的"1、2、3"。。。。

4.“特色功能”的实现问题

• 我的好友
• 水友集结
• 猜你喜欢

前三项功能最开始所想的本来是想作为特色功能的，但是时间匆忙，实际上并不是核心功能，Alpha版本没有必要实现，所以就删去了。先做好核心功能——活动发布、报名以及签到才是重中之重。

二.对原型的一些改进说明

经过数次会议的讨论，我们重新设计了找回密码、注册、发布活动等功能的界面

1.重新设计忘记密码功能

之前是忘记密码联系管理员的QQ，现在是提交自己的手机号以及新密码即可。

2.软件主界面分为别为三个角色身份重新设计

之前是活动发布者与活动参与者公用一个界面，造成混乱不便管理。现在可以在登录界面直接选择身份，并且对应的登录进属于自己的界面，里面只有自己的功能，简洁易懂。

3.为配合管理员审核功能，重新设计“权限审核”功能模块

需要先声明的一点，所有的注册，仅限于活动参与者。如果需要活动发布者的身份，需要进行权限申请，由管理员审核。

在参与者界面中的个人中心下方有个权限申请，填入个人信息以及理由，便可以申请了。

4.管理员添加注销账号功能

在注册的时候，如果有人不小心注册成别人的学号，会导致这个学号的人自己无法注册。所以这个学号的主人可以联系管理员，提交证明，注销掉自己的学号，这样便可以放心注册了。

5.消息箱功能的改变

由于之前有我的好友这个功能，所以消息箱用于接受别人的消息。把我的好友功能删除后，便用了管理员接收权限申请等的消息请求。

三.编码规范

http://www.cnblogs.com/gzwu/p/6006001.html

四.新版需求说明书以及框架的github链接:

https://github.com/cafe3165/admin

五.数据库设计之ER图

ER图

PowerDesigner实现

六.分工与工作比例

组员	分工	比例
橙汁	根据讨论结果对原型进行了重新的设计、更新需求文档界面部分	13%
黄志明	撰写上回需求说明书的不足以及改进的地方、整合新需求文档	13%
牛姐	项目的体系结构设计和界面设计、性能需求部分更新	18%
李严	项目的体系结构设计和界面设计、验收标准更新	15%
洪志兴	数据库的E-R图设计、用户特点以及场景更新	14%
佳恺	数据库的E-R图设计、类图以及用例图的更新	14%
格格	编码规范的撰写、功能描述部分的更新	13%