MyFlag Step2：APP雏形的展现以及相关规范

引言

在之前的工作中，我们小组已经完成了MyFlag的产品定位以及相关的核心功能，现在，我们团队开始考虑到这个想法的具体实现。今天我们小组主要针对了以下几点进行了讨论：

• 具体需求的细化
• 根据需求初步确定mysql表，并进行相关优化
• 后台提供的功能以及接口规范
• 客户端的功能模块
• 相关框架、技术的初步确定
• 微信小程序的移植可行性（可选）

在这里，我将对团队工作进行简单介绍，对自己负责的内容进行侧重介绍。

需求细化

初步需求获取之后完成的用例图如下：

• 整个系统只有用户这一个角色
• 用户首先可以进行注册账号并填写个人信息
• 注册之后才可以登录当前账号
• 登录才能退出
• 用户可以进行相关的设置，其中包括个人资料的设置比如用户名、性别、个性签名等，还可以进行密码的修改
• 用户的好友功能，可以添加好友和删除好友
• 对于核心功能MyFlag，可以新建一个Flag，同时可以邀请好友监督我的Flag并且设置监督奖励，根据每天的情况打卡接受好友的监督
• 社区功能可以显示我以及好友的Flag，并且可以主动申请成为好友某一个Flag的监督人，并且监督好友Flag的完成情况

MySql表

经过分析，我们在数据库中一共设计了六个表，分别是：user（用户）表，friend（好友）表，flag（立的flag）表，member（团队成员）表，supervise（监督表），tempFriend（添加好友）表，具体如下。

`CREATE TABLE `fg_flag` (  `fid` int(10) NOT NULL AUTO_INCREMENT,  `uid` int(10) NOT NULL,  `content` blob NOT NULL,  `award` blob NOT NULL COMMENT '奖励',  `achieve` tinyint(1) DEFAULT NULL COMMENT '是否完成',  `isTeam` tinyint(1) NOT NULL COMMENT '单人或团队',  `startTime` int(11) NOT NULL COMMENT '开始时间',  `endTime` int(11) NOT NULL,  `createTime` int(11) NOT NULL,  PRIMARY KEY (`fid`),  KEY `uid` (`uid`),  CONSTRAINT `uid` FOREIGN KEY (`uid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE) ENGINE=InnoDB AUTO_INCREMENT=18 DEFAULT CHARSET=utf8;CREATE TABLE `fg_friend` (  `aUid` int(11) NOT NULL COMMENT '邀请者',  `bUid` int(10) NOT NULL COMMENT '被邀请人',  `remark` varchar(10) CHARACTER SET latin1 DEFAULT NULL COMMENT '备注',  KEY `aUId` (`aUid`),  KEY `bUid` (`bUid`),  CONSTRAINT `aUId` FOREIGN KEY (`aUid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE,  CONSTRAINT `bUid` FOREIGN KEY (`bUid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8;CREATE TABLE `fg_member` (  `fid` int(10) NOT NULL,  `uid` int(10) NOT NULL,  PRIMARY KEY (`fid`,`uid`),  KEY `muid` (`uid`),  CONSTRAINT `mfid` FOREIGN KEY (`fid`) REFERENCES `fg_flag` (`fid`) ON DELETE CASCADE,  CONSTRAINT `muid` FOREIGN KEY (`uid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8;CREATE TABLE `fg_supervise` (  `fid` int(10) NOT NULL,  `uid` int(10) NOT NULL,  `agree` smallint(1) DEFAULT '0' COMMENT '是否同意监管,0表示不确定，1失败，2成功',  `achieve` smallint(1) DEFAULT '0' COMMENT '是否完成',  `evaluate` blob COMMENT '评语',  `time` int(11) DEFAULT NULL COMMENT '评定时间',  PRIMARY KEY (`fid`,`uid`),  KEY `uid` (`uid`),  CONSTRAINT `fg_supervise_ibfk_1` FOREIGN KEY (`uid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE,  CONSTRAINT `fid` FOREIGN KEY (`fid`) REFERENCES `fg_flag` (`fid`) ON DELETE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8;CREATE TABLE `fg_tempfriend` (  `uid` int(10) NOT NULL,  `requestUid` int(10) NOT NULL,  `message` varchar(20) CHARACTER SET latin1 DEFAULT NULL,  `remark` varchar(10) CHARACTER SET latin1 DEFAULT NULL,  `agree` int(5) DEFAULT '0' COMMENT '1表示不同意',  PRIMARY KEY (`uid`,`requestUid`),  KEY `kl` (`requestUid`),  CONSTRAINT `kl` FOREIGN KEY (`requestUid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE,  CONSTRAINT `ui` FOREIGN KEY (`uid`) REFERENCES `fg_user` (`uid`) ON DELETE CASCADE) ENGINE=InnoDB DEFAULT CHARSET=utf8;、CREATE TABLE `fg_user` (  `uid` int(10) NOT NULL AUTO_INCREMENT,  `nickname` varchar(20) CHARACTER SET latin1 NOT NULL,  `password` varchar(20) CHARACTER SET latin1 NOT NULL,  `phone` bigint(11) NOT NULL,  `email` varchar(30) CHARACTER SET latin1 NOT NULL,  `information` text CHARACTER SET latin1,  `sex` varchar(10) DEFAULT '男',  PRIMARY KEY (`uid`,`phone`),  UNIQUE KEY `un` (`phone`)) ENGINE=InnoDB AUTO_INCREMENT=14 DEFAULT CHARSET=utf8;`

在设计数据库关系表时，我充分利用了在数据库课程上所学到的知识， 设计关系时最大限度减少冗余。设计出的关系表满足三范式的要求，符合基本的企业标准。

后台支持

后台的设计主要由李赵颖负责，经过小组的讨论，我们认为，根据需求可以将后台服务器所提供的功能大体分为以下几个方面：

• 关于用户
  
  • 用户注册
  • 用户登录
  • 修改个人信息
  • 修改密码
  • 查找用户
• 关于添加好友
  
  • 添加好友
  • 确认添加好友
  • 改变备注
  • 我的朋友
  • 获得好友请求列表
• 创建Flag
  
  • 创立Flag
  • 查看我的Flag
  • 查看朋友Flag
  • 删除Flag
  • 处理要求监督Flag的要求
  • 评价Flag
  • 获得邀请我监督的请求
  • 获得一个flag
  • 获取我监督的flag
  • 请求监督
  • 确认别人的请求监督
  • 得到别人想要申请监督我的flag的 消息列表
  • 得到我申请监督别人的flag的 消息列表

具体的接口规范大致按照如下格式：

 1 用户注册    URL：/user/Register    Parameter：   nickname  用户昵称        password   用户密码        phone      手机号  （11位）        email      电子邮件        information 个人信息        sex     性别（男或者女  String类型 ）    return：json格式的id(用户id)  2  登陆      URL：/user/Login    Parameter:        id      用户的id        password    用户密码    return：json格式的user

在这里，我们使用JSON，即JavaScript Object Notation，作为客户端和服务器通信接口的主要传输数据类型，这是因为JSON是一种轻量级的数据交换格式，采用完全独立于语言的文本格式，但是也使用了类似于C语言家族的习惯。这些特性使JSON成为理想的数据交换语言。 易于人阅读和编写，同时也易于机器解析和生成。这样设计，可以保证客户端和服务器通信接口的设计良好。

客户端功能模块

客户端的设计主要由我和王宁进行，因此我在这里进行一下重点的介绍。该系统许多操作都需要与服务器进行通信，而这些网络通信又都具有一定的共性，故将所有基本的网络通信方法封装在类util包下NetUtil类中，将具体处理留给实现了接口的子类来实现。采用这种设计，既减少了代码的冗余度，又保证了模块内高内聚，模块间低耦合的要求,符合软件工程的系统设计的要求。

经过讨论，已经确定的功能模块有：

• 网络请求工具类，封装了与服务器通信的方法
• 登录
• 注册
• 创建Flag

可以看到，这四个模块之间的关系并不紧密，这满足了模块间低耦合的要求；单个模块的功能比较单一，这满足了模块内高内聚的要求。
同时也可以发现，这四个模块的功能并不能包含系统的全部功能，这是因为目前还处于项目的初期,与服务器的接口还没有完全确定下来，我打算先从最基本的功能入手，先设计好最基本的模块，在接口文档进一步确定之后，再添加其他的模块。

相关框架、技术

主要框架技术如下：

• axure构件原型
• 安卓的界面使用materim design
• Retrofit2+OkHttp3+RxJava搭建网络框架
• daggar2依赖注入
• 服务器端与数据库连接的C3P0

详细介绍：

• Axure RP是一个专业的快速原型设计工具。它能快速、高效的创建原型，同时支持多人协作设计和版本控制管理。使用该工具可以迅速建立原型，以便更好地获取需求。
• materim design是谷歌公司的一款界面设计框架。这部分主要由马宗广负责。
• Retrofit2是一款流行的网络请求库，可以简化网络通信的操作。OkHttp3是一款流行的网络通信开源框架，RxJava 简单来说是一个实现异步操作的库。三者结合使用，保证网络通信的正常运行。
• daggar2是依赖注入，对软件的架构来说，是一种很好的解耦工具，可以进一步降低代码之间的耦合度。
• C3P0是一个开源的JDBC连接池，它实现了数据源和JNDI绑定。这部分主要由李兆颖负责。

微信小程序移植可行性（可选）

微信小程序，用一个不贴切的说法就是，微信内嵌web view 控件，本质上就是一个定制化的web浏览器，与普通浏览器相比只是增加了一些丰富的内部交互，比如可以轻松用户信息等等，以及可以存放独立缓存等数据，属于虚拟机范畴的优化。MyFlag清晰的逻辑结构以及功能完全可以移植进微信小程序。

总结

团队初步的将整体的框架设想出来并且经过充分的讨论达到一致的看法，仅仅是刚刚开始，有困难的日子还在后面，但我们相信我们一定可以逐步完成我们的项目。
在我主要负责的客户端的方面，目前的进度还是不错的，基本的系统设计已经完成，各种需要使用的技术也已经基本确定，和服务器的接口也确定了一部分，剩下的也在不断跟进，总体进度还是不错的。但是也不能掉以轻心，在正式的编程开始之后，可能还是会遇到问题，我要为那个时候做好充分的准备。