《团队作业第二周》五小福团队作业——UNO
一、修改完善上周提交的需求规格说明书
- THE FIRST改变
- 首先：我们组的博客无小组分工及占比，这是第一个问题，当时我们在写博客的时候由于很多问题都在讨论筹备当中，因此，在写博客的时候并没有及时的添加小组分工及占比。后来当我们将初步工作全部完成后之后我们在博客中补充了该内容。
我们小组的分工占比如下：
| 成员 | 分工 | 占比 |
|---|---|---|
| 郭恺 | 界面设计，原型设计需求分析，代码初步设计 | 20% |
| 段志轩 | 用例图设计，代码设计和部分编写 | 20% |
| 李馨雨 | 博客和需求说明书的撰写，功能说明图 | 20% |
| 王文彬 | 主要几种方法代码的编写 | 20% |
| 李楠 | 用例图设计，界面设计 | 20% |
-
THE SECOND改变
-
其次：我们组在提交的时候并没有给出用例图。因为我们刚开始的时候并不知道用例图的作用，以为它和我们之前做的功能介绍图一样，后来在看了刘伟康学长的博客之后才知道用例图也需要给出，我们小组在经过讨论之后了解到了用例图是指由参与者（Actor）、用例（Use Case），边界以及它们之间的关系构成的用于描述系统功能的视图。用例图（User Case）是外部用户（被称为参与者）所能观察到的系统功能的模型图。用例图是系统的蓝图。用例图呈现了一些参与者，一些用例，以及它们之间的关系，主要用于对系统、子系统或类的功能行为进行建模。对于了解我们的软件有很大的作用。
小组用例图如下：
二、团队的编码规范
1、 标识符命名规范
1.1、命名约定
尽量使用完整的英文描述符,采用适用于相关领域的术语;
要采用大小写混合使名字可读;尽量少用缩写，但如果用了，要明智地使用，且在整个工程中统一；
避免使用长的名字（最好小于15个字母）；避免使用类似的名字，或者仅仅是大小写不同的名字。
1.2、具体用例
- 包（Package）
采用完整的英文描述符，应该都是由小写字母组成。
- 类（Class）
采用完整的英文描述符，所有单词的第一个字母大写。 如：Card、Robot等
- 接口（Interface）
采用完整的英文描述符来说明接口封装，所有单词的第一个字母大写。习惯上，名字后面加上后缀 able，ible或者er，但这不是必需的。如：Contactable、Prompter。
- 组件/部件（Component）
使用完整的英文描述来说明组件的用途，末端应接上组件类型。 如：startButton、fileMenu
- 类变量
字段采用完整的英文描述，第一个字母小写，任何中间单词的首字大写，如： firstName
、lastName
- 实参/参数
同字段/属性的命名规则
public void setFirstName(String firstName)
{
this.firstName = firstName;
}
- 获取成员函数
被访问字段名的前面加上前缀get。例如：getFirstName(), getLastName().
- 设置成员函数
被访问字段名的前面加上前缀 set。例如： setFirstName(), setLastName(),setWarpSpeed()
- 方法名
首字母小写，如 addOrder() 不要 AddOrder()
动词在前，如 addOrder()，不要orderAdd()
动词前缀往往表达特定的含义。
- 静态常量字段（static final）
全部采用大写字母，单词之间用下划线分隔。 MIN_BALANCE, DEFAULT_DATE
- 循环计数器
通常采用字母 i，j，k 或者 counter 都可以接受。 i, j, k, counter
- 数组（Array）
数组应该总是用下面的方式来命名：
byte[] buffer;
2、代码格式
2.1、 源文件编码
源文件使用utf-8编码。
2.2、行宽
行宽度不要超过130。
2.3、包的导入
删除不用的导入，尽量不要使用整个包的导入。
2.4、代码块格式
2.4.1、缩进风格
大括号的开始要在代码块开始的下一行的行头，闭合在和代码块同一缩进的行首，例如：
public class TestStyle extends SomeClass implements AppleInter, BananaInter
{
public static final String THIS_IS_CONST = "CONST VALUE";
private static void main(String[] args)
{
int localVariable = 0;
}
public void compute(String arg)
{
if (arg.length() > 0)
{
System.out.println(arg);
}
for (int i = 0; i < 10; i++)
{
System.out.println(arg);
}
}
}
2.4.2、空格的使用
- 二元三元运算符两边用一个空格隔开
如下：
a + b = c;
b - d = e;
return a == b ? 1 : 0;
不能如下：
a+b=c;
b-d=e;
return a==b?1:0;
- 逗号语句后如不换行，紧跟一个空格
如：call(a, b, c);
不能如：call(a,b,c);
2.4.3、空行的使用
原因：空行可以表达代码在语义上的分割，注释的作用范围，超过十行的代码如果还不用空行分割，就会增加阅读困难将类似操作。
- 使用规则：
- 连续两行的空行代表更大的语义分割。
- 方法之间用空行分割;
- 域之间用空行分割;
- 示例：
order = orderDao.findOrderById(id);
//update properties
order.setUserName(userName);
order.setPrice(456);
order.setStatus(PAID);
orderService.updateTotalAmount(order);
session.saveOrUpdate(order);
上例中的空行，使注释的作用域很明显.
3.、注释规范
3.1、 注释代码规范
注释宜少而精，不宜多而滥，更不能误导。
命名达意，结构清晰，类和方法等责任明确，往往不需要，或者只需要很少注释，就可以让人读懂；相反，代码混乱，再多的注释都不能弥补。所以，应当先在代码本身下功夫。不要过于详细的注释，对显而易见的代码不添加注释。
注释要和代码同步，过多的注释会成为开发的负担;注释不是用来管理代码版本的，如果有代码不要了，直接删除，不用注释掉，否则以后没人知道那段注释掉的代码该不该删除。
3.2、Java Doc
表明类、域和方法等的意义和用法等的注释，要以javadoc的方式来写。Java Doc是个类的使用者来看的，主要介绍 是什么，怎么用等信息。凡是类的使用者需要知道，都要用Java Doc 来写。非Java Doc的注释，往往是个代码的维护者看的，着重告述读者为什么这样写，如何修改，注意什么问题等。 如下：
/** 我的数组帮助类
*定义一个用于操作数组的工具类。
*比如：获取最值，排序，折半。
*@author 张三
*@version V1.0
*/
具体可看博客参考
3.3、块级别注释
3.3.1、块级别注释
单行时用 //, 多行时用 /* .. */。
3.3.2、较短的代码块
用空行表示注释作用域
3.3.3、较长的代码块
用/*------ start: ------*/
和
/*-------- end: -------*/包围
如：
/*----------start: 订单处理 ------- */
//取得dao
OrderDao dao = Factory.getDao("OrderDao");
/* 查询订单 */
Order order = dao.findById(456);
//更新订单
order.setUserName("uu");
order.setPassword("pass");
order.setPrice("ddd");
orderDao.save(order);
/*----------end: 订单处理 ------- */
3.4 行内注释
行内注释用 // 写在行尾
4.选择理由
- 首先，这样方便软件维护。据统计，80％的软件开发费用在维护，规范化的代码才方便维护，降低维护成本。
- 其次， 好的编码规范能够大大增强代码的可读性，便于开发人员快速的理解新代码。任何产品都需要好的包装。我们可以把代码本身看作是一种产品，那么按照规范编程也是对这个“产品”的包装 。
- 另外，规范化的代码也是软件质量的保证手段之一，也是软件过程能够流畅的基础。我们每个人必须牢牢树立这样的观念：你今天所编写的代码，会一直使用很多年，并且很有可能被其他人维护和改进。所以，我们必须努力写出“干净”和易读的代码。本文档适用于软件开发过程中开发人员，主要包括编码人员、测试人员，开发人员，规范必须严格遵守，否则程序被视为不合格程序。
三、团队项目的数据库设计及相应ER图
由于我们组的数据库较为单纯，只需要存储用户的姓名、账号和密码以及用户在游戏中的排名和成绩，故我们的ER图较为简单。
四、项目的后端架构设计
-
我们小组使用Xmind实现如下：
-
登录界面
首先跳出一段我们制作的欢迎动画，让玩家感受到满满的游戏画面感。
然后进入登录界面
登录界面包括两个内容，注册与登录。
若已经注册则直接点击登录进入游戏，若尚未注册则点击注册进入注册页面，待注册完毕后登录进入游戏。 -
准备界面
准备界面包括开始游戏、退出游戏、游戏介绍。
点击开始游戏即可进入下一个界面，下一个界面包括继续上次游戏和选择游戏场规模两个选项；若选择继续上次游戏就直接进入游戏界面继续游戏，若单击选择游戏场规模就进入对游戏场的选择。一共有四个游戏场规模的选择，分别是三人场、四人场、五人场和无限场（不对牌的数量做限制）。再通过选择后进入游戏场。 -
游戏界面
游戏界面包括以下内容：
（1）牌类
该内容显示你现在所拥有的所有手牌，以及不同分类，还有其他玩家的手牌个数，牌堆剩余个数。
（2）功能按钮类 -
一键整理按钮：可以整理你的手牌
-
选色按钮：为下一家指定颜色。
-
出牌按钮：选定你选择的牌并点击出牌，若是满足游戏规则就正常出牌，若是不满足就报错给玩家。
-
菜单栏
- 存档：保存当前游戏，下次可在准备界面中选择继续游戏。
- 音乐选择：可以选择打开或者关闭
- 重来：重新开局
- 退出：直接退回开始的主界面。
五、团队分工
| 成员 | 分工 |
|---|---|
| 郭恺 | 负责有关Android界面设计 |
| 段志轩 | 负责Android数据库，存放用户名、密码、用户分数 |
| 李馨雨 | 代码规范，后端设计，学习动画设计 |
| 王文彬 | 设计纸牌还有牌类完善 |
| 李楠 | 整理博客，学习Android数据库 |
【注】个别成员在没有具体工作时会进行动态分配。
- 利用象限法确定各个核心需求的优先级：
- 功能介绍图（WBS）：
六、TODOList及燃尽图
- TODOList的项目添加
- 码云上的Issue：
- github上的Issue：
- 燃尽图：（仅本周任务）
七、本次分工及工作量比例
| 成员 | 个人贡献及完成度 | 占比 |
|---|---|---|
| 郭恺 | 界面的制作，学习了github完成燃尽图 | 20% |
| 段志轩 | 通过Powerdesigner完成团队项目的数据库设计，并在随笔中提供了相应ER图。 | 20% |
| 李馨雨 | 进行项目的后端架构设计 ，制定团队的编码规范，添加了issues | 20% |
| 王文彬 | 编写代码，确定每个子功能的工作量 | 20% |
| 李楠 | 整理博客，利用象限法确定各个核心需求的优先级 | 20% |
八、本周小组会议及交互总结
本周的共同学习时间太少，讨论时间不够，大家做事效率比较低，整体氛围有待缓冲提高。
在本周，我们小组共同确定了任务方向、制定了工作计划和任务。代码方面王文彬同学较好的完成了自己的工作，将bug整改了；李馨雨同学也学习了XMIND来完成了后端设计并制定了团队的编码规范，郭恺同学也着手部分界面设计和AS学习，段志轩同学也完成了自己负责的数据库方面，李楠同学做了象限图、用例图和博客的整理。
下一周我们将投入更多时间去攻坚克难，希望所有小伙伴们不要掉以轻心，多多做好自己分内的工作，互帮互助，努力写好小组项目的新篇章！
参考资料汇总
- [Java和Android开发学习指南]（第二版）
- 使用Github生成燃尽图
- 分而治之（Work Breakdown Structure, WBS）
- xmind新手入门教程
- ER图的绘制