项目成员：罗海屏、郑晓婷
一 、Github项目地址：https://github.com/ting9500/GNIT_Second
二、PSP表格
|
PSP2.1 |
Personal Software Process Stages |
预估耗时（分钟） |
实际耗时（分钟） |
|
Planning |
计划 |
30 |
30 |
|
· Estimate |
· 估计这个任务需要多少时间 |
30 |
30 |
|
Development |
开发 |
1080 |
1320 |
|
· Analysis |
· 需求分析 (包括学习新技术) |
80 |
120 |
|
· Design Spec |
· 生成设计文档 |
20 |
20 |
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
30 |
40 |
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
10 |
10 |
|
· Design |
· 具体设计 |
45 |
60 |
|
· Coding |
· 具体编码 |
240 |
300 |
|
· Code Review |
· 代码复审 |
40 |
60 |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
60 |
60 |
|
Reporting |
报告 |
90 |
80 |
|
· Test Report |
· 测试报告 |
30 |
20 |
|
· Size Measurement |
· 计算工作量 |
10 |
10 |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
15 |
10 |
|
summary |
合计 |
1810 |
2170 |
三、效能分析
由于在实现题目查重这一功能上花费的时间较长，因此对于其他功能实现代码并未做过多的改进，主要是体现在式子生成及计算上的改进：
（1）在分别实现生成题目和计算出题目答案两个功能之后，运行程序发现花费的时间较长，分析觉得可能是因为随机生成式子，因此生成的式子计算过程中产生的负数的几率较大，而若产生负数的情况要删除式子重新生成，故时间较长；后来我们将生成题目和计算出题目答案合二为一，边生成边计算，一旦中间结果产生负数，则立刻销毁式子，重新生成，在一定程度上提高了程序的运行效率，但同时也增大了空间复杂度，以空间换时间。使用这个方式另一方面也会使代码的可读性较差；
（2）因为题目要求生成的式子及答案均以真分数的形式显示，但是对于带分数的运算比较复杂，故我们在进行运算之前就先把带分数转换成假分数，直接运用计算表达式进行运算，使代码更加简洁，可读性较强。
生成10000道题目并且计算出答案所需时间：
四、设计实现过程
1. 对于此次的课程题目，我们决定通过图形界面来展示结果，在一个生成类中自动生成小学四则运算题目，使用二叉树来进行题目查重，然后调用一个计算类计算出题目答案，再将题目保存在Exercises.txt文件中，答案保存在Answers.txt文件中。通过图形界面获取用户输入的答案，与正确答案进行校对并统计出正确题目数量。
2. 简单的需求分析之后我们具体到功能类的实现：
（1）生成题目：我们的思路是先随机生成前 n - 1 个数的表达式，再添加最后一个数字，补全剩余的括号，目的是为了使所有的括号都有意义。而对于题目中含有“÷ 0”的情况，直接删除，但是对于计算过程中出现的除以0的情况，则需要在计算类中判断是否生成该题目；
（2）计算题目：我们利用栈对题目的计算过程中的运算符、数值及中间结果进行处理，利用Map获取对应运算符的优先级，进行相应的运算。根据有无括号及运算符优先级调用不同的方法doCalcul ( )、comparePriority ( )，然后通过finalResult ( )方法获取到最终结果并将其规范化表达；
（3）题目查重：这个功能比较复杂，一开始的想法是使用数组存放运算过程中运算符及数值的操作顺序记录，之后每次生成题目时都与之前的记录作比较，不同则表示题目不重复，进行下一步运算，否则则重新生成新的题目。但是对于 ( a + b ) + ( c + d )形式的题目，我们暂时没有想到更好的处理方式进行查重，所以我们换了另外一种思路——使用二叉树进行查重，数值作为叶子节点，运算符作为父节点及中间节点，处于同一父节点的两个叶节点按照较小数值置于左边，较大数值置于右边，以此生成二叉树。但是由于逻辑上还有些不清晰，代码一直出现bug，导致最终还是无法实现该功能，将在后面补上；
（4）四则运算：此功能比较简单，我们首先将两个数值都转换成“a / b”的形式，再进行计算，使用add ( )，subtraction ( ) 、multiplication ( )、division ( )计算得出结果。
（5）代码改进：在分别实现生成题目和计算出题目答案两个功能之后，运行程序发现花费的时间较长，分析觉得可能是因为随机生成式子，因此生成的式子计算过程中产生的负数的几率较大，而若产生负数的情况要删除式子重新生成，故时间较长；后来我们将生成题目和计算出题目答案合二为一，边生成边计算，一旦中间结果产生负数，则立刻销毁式子，重新生成，在一定程度上提高了程序的运行效率。
五、代码说明
（1）边生成题目边计算中间结果，得出题目答案：
思路：考虑到直接使用正则表达式先生成式子再来判断式子是否有效并计算最终结果这种方法可能会导致程序的运行效率不高，因为式子的生成是随机的，有很大几率会生成运算过程中出现负数或者是式子中出现“÷ 0 ”这种不合法的题目，等待式子生成后再来销毁题目重新生成，因此花费的时间较长。所以我们采用边生成式子边计算，利用tag标志位判断是否要添加括号以及是生成“（”还是“）”，由于不采用正则表达式来匹配式子表达的正确性，所以我们将表达式分为两部分：前 n - 1个数的组合及最后一个数的添加，同时在生成最后一个数的时候补全剩余括号，使式子中的所有括号有效。生成过程中每添加一个数字或运算符，都进行相应的操作：数字压入数值栈，运算符则根据优先级判断先执行哪一部分的计算，已操作的数字及运算符出栈，中间产生的结果入栈，最终得到只有一个数值的数值栈，即为生成式子的结果。
（2）使用MAP结构设置运算符的优先级，以数值的大小表示运算符优先级高低，数值越大优先级越高。
（3）优先级：高 -> 低情况下的计算
表达式的操作数将push到一个数值栈中，而运算符将push到运算符栈中。将当前运算符和栈顶运算符对比，如果栈顶运算符优先级高于或同级于当前运算符，则执行一次二元运算（递归比较并计算），否则当前运算符入栈。
（4）优先级：低 ->高 情况下的计算
首先排除子表达式运算结果为负数的情况，再进行下一步计算。
分别取括号内表达式的参与计算的数值1、数值2和运算符加以计算，将计算结果当做操作数入栈。当括号类型为左括号则停止计算，同时将左括号从栈中移除，否则递归本函数；当遇到等号类型只要栈中还有运算符就继续递归计算。
（5）将结果进行格式化，排除结果为负数的情况。
（6）四则运算。将二元运算表达式中的两个分数（a/b、c/d）拆分成两个分子和两个分母，计算之后再转成分数形式。
（7）文件保存
接收需要保存的字符串和tag标志。若tag=1，即保存为Exercise.txt（题目文件）；若tag=2，即保存为Answers.txt（答案文件）；若tag=3，即保存为Grade.txt（成绩文件）。
六、测试运行
（1）开始运行程序
（2）未输入生成题目数量及数值范围
（3）输入数值
（4）随机生成题目
（5）用户输入并提交答案，后台将用户答案与正确答案进行校正，统计正确题数
（6）保存题目Exercises.txt文件
（7）保存答案Answers.txt文件
（8）Grade.txt文件
（9）保存的文件
测试运行实例
验证程序的正确性：
（1）大量的样本计算可大致认为程序正确；
（2）通过 js 的 eval ( ) 函数可计算出字符串表达式的结果，与该程序的答案进行校对，可保证结果的正确性。
七、实际花费的时间
|
PSP2.1 |
Personal Software Process Stages |
实际耗时（分钟） |
|
Planning |
计划 |
30 |
|
· Estimate |
· 估计这个任务需要多少时间 |
30 |
|
Development |
开发 |
1320 |
|
· Analysis |
· 需求分析 (包括学习新技术) |
120 |
|
· Design Spec |
· 生成设计文档 |
20 |
|
· Design Review |
· 设计复审 (和同事审核设计文档) |
40 |
|
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
10 |
|
· Design |
· 具体设计 |
60 |
|
· Coding |
· 具体编码 |
300 |
|
· Code Review |
· 代码复审 |
60 |
|
· Test |
· 测试（自我测试，修改代码，提交修改） |
60 |
|
Reporting |
报告 |
80 |
|
· Test Report |
· 测试报告 |
20 |
|
· Size Measurement |
· 计算工作量 |
10 |
|
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
10 |
|
summary |
合计 |
2170 |
八、项目小结
本次四则运算的练习还是做得不够完善，运用的方法比较笨重，代码比较冗余，时间复杂度和空间复杂度较大，题目查重将使用二叉树的形式，目前还未完成查重功能，此项目将会继续完善下去。
同时通过结队编程，我更深刻地体验到代码规范的重要性。多人结队编程，如果固执己见地坚持自己的打码风格，不遵守规范，就会造成组合代码时浪费更多的时间。