20172301 结对编程练习_四则运算 第一周 阶段总结

20172301 结对编程练习_四则运算 第一周 阶段总结

1.项目内容设计

• 自动生成题目

  • 可独立使用（能实现自己编写测试类单独生成题目的功能）

  • 可生成不同等级题目，类似于：

     1级题目：2 + 5 =

     10 - 5 =

     之类的两个数，一个运算符的题目

• 题目运算（判题）

  • 可独立使用

  • 实现中缀表达式转为后缀表达式并计算
    判断用户答题正误，并输出正确结果

• 支持真分数

  • 可独立使用

  • 实现分数算式的计算

• 题目去重（扩展需求，加分项）

  • 可独立使用

  • 实现对自动生成表达式的去重:如下

     若生成：2 + 5 =
     5 + 2 =
     为同一题目.

2.设计思路内容

• (1).我们大致分为了五个等级：(一个等级即为一个方法)
  第一个等级：加减
  第二个等级：乘除
  第三个等级：加减乘除
  第四个等级：分数加减乘除

生成题目主要分为数字和符号两个部分。我们创建了一个char类型的数组来保存加减乘除符号。然后通过随机数随机得到数组的索引来进一步得到加减乘除符号。最后通过循环来得到相应题数相应等级的题目。

• (2).题目运算：
  这个我们考虑到记录正确和错误题数并求出正确率。需要把用户输入的答案和计算机计算的答案进行对比。而我们一般采用的都是中缀表达式，而中缀表达式的计算优先级的顺序无法正确传递给计算机。所以我们要考虑把中缀表达式转换为后缀表达式。并且把后缀表达式计算出相对结果。
  所以，我们学习新知识栈的使用。

• (3).支持真分数：
  真分数这个类，我们考虑用到第七章所编写的有理数计算——RationalNumber，通过其中的约分，取倒数的方法生成我们的第四个等级的题目。通过新建RationalNumber对象来调用方法。同样，在后缀表达式计算中，我们也考虑将整数转化为分母为1的分数进行计算。

• (4).题目去重：
  对于这个加分项，我们把它看成为一个难题，因为要考虑括号的因素太过于复杂。比如1 + 2 + 3和 3 + (2 + 1)是同一题目需要去重。但是我们现在的思路是，进行逐步计算，比较其逐步计算的结果，若每一步结果相同，那么一般就是需要去重的了。不过，现在仅仅停留在思路范畴。

• (5).添加括号：
  对于括号，我们组有一个大胆的想法，根据ASCII码进行添加。

  • 第一个思路：我们组研究发现，左括号一般要加在数字的左边，那么我们可以先添加左括号在索引0、2、4......也就是偶数位上。
    然后，相对应的，我们可以以相同的长度来预测右括号的位置。
  • 第二个思路：为什么要有第二个思路呢？因为第一个有缺点。第一种只适合0-9，也就是10以内的计算。因为两位数，将会影响索引的长度。
    所以，我们通过String.spit方法把字符串通过空格拆分成一个个小部分进行计算。

3.本周 上交成果

(1).UML类图

(2).编程过程中的问题和解决

• 问题1：题目符号和数字在输出中一直是相同的？
  

• 问题1解决方法：在运行很多遍以后，队员发现了问题，最后几位的操作数和符号都是相同的。我们重新检查了代码，发现我们的随机数在循环之前就已经确定了，无法正确“随机”，应该把随机数定义在循环当中。

• 问题2：分数不能输出。
  

• 问题2解决方案：我们实例化数组却没有实例化对象，导致无法调用fraction方法。
  

• 问题3：在中缀表达式转换为后缀表达式当中，我原来的思路是通过String.toCharArray进行分割。这个字符串就会直接存到char[]中。但是，学长推荐了StringTokenizer类。随后，我也发现了我原来思路的问题。遇到两位数，或者是分数，就不能正确的分割。会影响到后续的计算。
  

• 问题3解决方法：采用StringTokenizer类进行项目。

• 问题4：“双等号”错误。
  

• 问题4解决方案：我们组的李馨雨同学给出了解决方案。因为等号放在了循环里面，应该放在result里面。
  
  

• 问题5：在括号方面，我们的思路是通过ASCII码编写，但是，随着项目的进行，我们发现，ASCII码方法具有局限性。对于两位的，无法显示ASCII码的怎么办。

• 问题5解决方案：我们暂时没有更好的方法，在保持原有思路的情况下。如果到最后我们还是没有头绪的话，可能要重新进行思考。

(3).感受

总体来说，第一次小组任务还是比较成功的。组员之间非常协调和团结。在一些理论细小的地方，李馨雨同学会指出错误。而在一些难点，类似括号，段志轩同学往往能有一些大胆的想法，和我能够不谋而合。但是，我们的前期构思还是不够全面，总是需要大面积的修改。这可能和我们天马行空的想法有关？我希望我们组能多些创新，大胆尝试，即使有时候全面推倒重新构思会很疲惫，但是，那种思考，想法的碰撞的感觉让人热血沸腾。

PSP时间统计

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	60	65
Estimate	估计这个任务需要多少时间	3	2
Development	开发	2000	3000
Analysis	需求分析 (包括学习新技术)	350	300
Coding Standard	代码规范 (为目前的开发制定合适的规范)	60	10
Design UML	设计项目UML类图	60	60
Coding	具体编码	1500	2000
Code Review	代码复审	30	30
Test	测试（自我测试，修改代码，提交修改）	300	300
Size Measurement	计算工作量（实际时间 ）	2	2
Postmortem & Process Improvement Plan	事后总结, 并提出过程改进计划	30	10
	合计	4395	5229