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方法把字符串通过空格拆分成一个个小部分进行计算。
- 第一个思路:我们组研究发现,左括号一般要加在数字的左边,那么我们可以先添加左括号在索引0、2、4......也就是偶数位上。
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 |
原文地址:https://www.cnblogs.com/gk0625/p/8977740.html
时间: 2024-10-09 19:07:35