团队作业——第二周

需求规格说明书更新

MarkDown
PDF
上周写得需求规格说明书在这一周的实现过程中，实际实现起来就有一些不太合理的地方，根据实际情况我们组及时作出了调整，在每个页面的功能有增有减，具体修改如下：

以下仅为修改的内容

对3.3.1精度部分进行过修改，原因是在越往后的关卡，障碍物出现的速度会越来越快，碰撞的精度会下降。
补充了目录，方便查看内容
补充了用例示意图，之前只有表格版的，现在加上图示更清楚。

4.1.3界面验收标准

界面名称	界面描述
开始界面	背景图填充，有开始游戏、离开游戏、排行榜、商店等按钮
商店界面	提供不同风格的跑酷角色，供玩家进行选择跑酷
游戏界面(操作)	类似王者荣耀的两端式的按钮，在界面两侧各设置按钮来实现跑酷角色躲避障碍物的不同状态
游戏界面(游戏)	跑酷角色在当前背景图下躲避障碍物的动画
暂停界面	提供用户优势暂时的离开
加载界面	加载游戏时避免用户无聊而创建的部分
通关界面	不同风格的跑酷风格，给用户提供多样的跑酷状态

4.1.4功能验收标准

功能名称	操作界面	详细介绍
选择标准	商店界面	点击人物会被选择开始游戏
排行	排行界面	点击会出现最高名次
人物动作	游戏界面	通过游戏界面的按钮进行不同状态的变换

4.1.5游戏检验标准

功能名称	操作界面	详细介绍
人物动画	游戏界面	能够通过按钮使人物躲避障碍物实现跑酷
障碍	游戏界面	能够以一定规律进行出现
音乐	各个界面	提供游戏时音乐效果，可以手动关闭
排行	排行榜	能够查询最高成绩

团队编码规范

命名规范
- 用全英文单词命名的方式，准确地描述性质，使代码容易理解。如使用printTrace而不是PT。
- 避免命名时使用下划线。
- 采用大小写混合的方式来命名，增强命名的可读性。组成类名、变量名中的每个单词的首字母均大写，其余的小写，例如ArrayMaxHeap;方法名的第一个字母小写，其他单词的首字母大写，例如toString。
- 尽量避免使用单词缩写，对于单词过长的不得不使用缩写的情况，必须使用通用缩写方式，例如number可写为num而不是nu。并且在所有类中保持不变。
- 避免太长的命名，以少于20个字符为宜。
- 避免两个命名只是某些字母大小写不一样，其他拼写完全相同的情况，这样容易造成混淆。例如SuffixExpresion和suffixexpresion。
- 常量使用大写拼写并用下划线分隔。
- 避免使用不易理解的数字，例如：
```
if  (state == 0)
{
    state = 1;
    ... // program  code
}
```
  这样对于数字的理解，编码人员之间可能会有不同的理解，应改为如下:
```
private final static int  TRUNK_IDLE = 0; private final static int TRUNK_BUSY = 1; private final static int TRUNK_UNKNOWN = -1;  
if (state == TRUNK_IDLE){     
    state = TRUNK_BUSY;     
    ... // program code
}
```
- 数组声明的时候使用 int[] index ，而不要使用 int index[]
- 包名统一使用小写，点分隔符之间有且仅有一个自然语义的英语单词。包名统一使用单数形式，但是类名如果有复数含义，类名可以使用复数形式。
- 抽象类命名使用 Abstract 或 Base 开头；异常类命名使用 Exception 结尾；测试类命名以它要测试的类的名称开始，以 Test 结尾。
代码规范
- 代码中的{}不可省，在if语句和while语句中即使只有一行代码也不可省。
- 方法类型默认为是密封的。
- 对接口和复杂代码块必须进行注释，并尽量使用简洁易懂的注释代码，避免长篇大论。
- 在自定义异常时，必须使用提供的模板来创建自定义异常。
- 所有的数据类必须重载toString() 方法，返回该类有意义的内容。说明：父类如果实现了比较合理的toString() ，子类可以继承不必再重写。例如：
```
 public TopoNode
{
 private String nodeName;
 public String toString()
   {
  return "NodeName : " +  nodeName;
  }
 }
```
- 抛出的异常必须要填写详细的描述信息,便于问题定位。例如：
```
throw  new IOException("Writing data error! Data: " + data.toString());
```
OPP规约
- 当一个类有多个构造方法，或者多个同名方法，这些方法应该按顺序放置在一起
- 类内方法定义顺序依次是:公有方法或保护方法 > 私有方法 > getter/setter 方法。
- final 可以声明类、成员变量、方法、以及本地变量，下列情况使用 final 关键字:
  - 不允许被继承的类，如:String 类。
  - 不允许修改引用的域对象，如:POJO 类的域变量。
  - 不允许被重写的方法，如:POJO 类的 setter 方法。
  - 不允许运行过程中重新赋值的局部变量。
  - 避免上下文重复使用一个变量，使用 final 述可以强制重新定义一个变量，方便更好地进行重构。
- 类成员与方法访问控制从严:
  - 如果不允许外部直接通过 new 来创建对象，那么构造方法必须是 private。
  - 工具类不允许有 public 或 default 构造方法。
  - 类非 static 成员变量并且与子类共享，必须是 protected。
  - 类非 static 成员变量并且仅在本类使用，必须是 private。
  - 类 static 成员变量如果仅在本类使用，必须是 private。
  - 若是 static 成员变量，必须考虑是否为 final。
  - 类成员方法只供类内部调用，必须是 private。
  - 类成员方法只对继承类公开，那么限制为 protected
- 使用索引访问用String的split方法得到的数组时，需做最后一个分隔符后有无内容的检查，否则会有抛出IndexOutOfBoundsException 的风险。例如：
```
String str = "a,b,c,,";
String[] ary = str.split(","); 
// 预期大于 3，结果是 3 
System.out.println(ary.length);
```
- Object 的equals方法容易抛空指针异常，应使用常量或确定有值的对象来调用equals。应使用“test”.equals(object);而不是object.equals(“test”); 所有的相同类型的包装类对象之间值的比较，全部使用 equals 方法比较。

注释规范

修改代码时保持注释同步。
修改他人代码时要先注释对方代码，并写明修改原因，不允许随便删除他人代码。
发布前移除无用注释。

类注释

/**
* @version: V1.0
* @author: fendo
* @className: user
* @packageName: user
* @description: 这是用户类
* @data: 2017-07-28 12:20
**/

构造函数注释

**
* @description: 构造函数
* @param: [sid, pid]
*/

方法注释

/**
* @author:  fendo
* @methodsName: addUser
* @description: 添加一个用户
* @param:  xxxx
* @return: String
* @throws: 
*/

代码块注释

/**
* 实例化一个用户
* xxxxxxx
*/
User user=new User();

单句注释

User user=new User();  //实例化一个用户

选择理由
- 代码规范我们组自己想的并不完整，考虑也不周全，具体参考了网上的一些较完善的代码规范，编程规约之OOP规约
  ，编码规范(一)----JAVA注释规范
- 首先是与我们实际使用情况相结合的，选择的是在代码编写过程中常用的并且是有必要的。
- 第二，由于我们组是团队合作完成，所以统一且易于使用的代码规范有助于增强代码的可读性，促进小组成员的协作。
- 第三，良好的代码规范在程序出现bug时，可以方便审查代码查找错误。
- 第四，老师以前分享过一篇文章，题目是：因不写注释，码农杀了4位同事，一人情况危急...所以，我希望我们的小组成员能够健康快乐...

ER图

我们组暂未使用到数据库，下周会使用到Android Studio自带的数据库，现在对其他方面作了图。

主体
动画

项目后端架构设计

游戏图标是一个可爱的凸显游戏性质的图片
主界面包括
- 1.开始游戏按钮
  - 点击进入游戏界面开始游戏
    - 游戏界面有高低障碍物随机出现，玩家可以点击跳跃和俯身两个动作按钮来躲避障碍物。
- 排行榜按钮
  - 点击可以查看历史成绩，有较好的前几次成绩记录，并附有用户信息。
- 商店按钮
  - 点击可以有多重人物以供玩家选择，玩家可以点击自己喜欢的人物形象来游戏，增强玩家在游戏过程中的体验感。
- 退出游戏
  - 点击即可退出游戏

团队分工

参考分而治之（Work Breakdown Structure, WBS）
利用象限法确定各个核心需求的优先级
团队Alpha版本需要实现的功能
- Alpha版本
  - 1.开始，退出，暂停按钮
  - 2.游戏界面：人物，障碍物（空中、地面），跑道
  - 3.障碍物出现，人物奔跑功能
  - 4.商店，游戏通关/失败功能，成绩排行功能
- β版
  - 1.商店选择人物功能
  - 2.音乐播放功能
Leangoo图
WBS图
团队各个成员认领的工作，当前团队的TODOList，并在最后给出燃尽图。
- 各个成员认领的工作
  - 谭鑫：动画实现
  - 黄宇塘：美工
  - 赵晓海：界面实现
  - 方艺雯：文案
  - 王禹涵：界面实现
- ToDoList图
- 燃尽图
  
  由于使用Github生成燃尽图的过程中，到填写网站生成图片的那一步时，码云链接无效，仅支持Github，所以上周没有生成燃尽图。这周用到的ToDoList软件有生成燃尽图功能，但制作完成后发现他不是燃尽图该有的样子，思考之后发现应该是因为前两周的是现在补的并设定为任务完成，所以在当时是没有完成的，在第一周显示的是一个任务没有完成，在第二周新增任务后显示两个任务没有完成，今天全都设定为完成任务所以下降为未完成任务为0，应该从下周开始就正常了吧。

总结会议

这周小组会议中主要谈论了上周工作总结和下周安排，具体情况如下：

上周谭鑫和赵晓海负责动画的实现并成功完成任务；黄宇塘和王禹涵负责制作背景图以及界面设计，确定了主题并且主要页面设计完成；方艺雯负责写每周总结博客以及博客中要求的一切图之类的东西。
下一周小组任务是实现游戏的可使用功能，能够选择人物游戏并躲避障碍物或撞上障碍物游戏失败，但没有闯关等拓展功能。其次就是界面将不断进行美化，必要时进行更换。

组员分工和工作量比例

小组分工基本不变，但相互协作，机动地变化。

人员	工作	占比
谭鑫	初步实现部分功能	20%
黄宇塘	制作背景图	20%
赵晓海	初步实现部分功能	20%
方艺雯	写博客和需求说明书	20%
王禹涵	初步实现部分功能	20%

参考资料

posted @ 2018-12-02 19:38 FYiW 阅读(347) 评论(0) 编辑收藏举报

刷新页面返回顶部

FYiW