标签:自动 检索 导致 构造方法 依次 没有 结构 rev 数值
github项目地址:https://github.com/wzl666A/myApp-master
一、项目简介
实现一个自动生成小学四则运算题目的命令行程序
二、项目实现情况
1. 使用 -n 参数控制生成题目的个数(实现)
2. 使用 -r 参数控制题目中数值(自然数、真分数和真分数分母)的范围(实现)
3. 生成的题目中计算过程不能产生负数,也就是说算术表达式中如果存在形如e1 ? e2的子表达式,那么e1 ≥ e2。(实现)
4. 生成的题目中如果存在形如e1 ÷ e2的子表达式,那么其结果应是真分数。(实现)
5. 每道题目中出现的运算符个数不超过3个。(实现)
6. 程序一次运行生成的题目不能重复,即任何两道题目不能通过有限次交换+和×左右的算术表达式变换为同一道题目。(实现)
7. 在生成题目的同时,计算出所有题目的答案,并存入执行程序的当前目录下的Answers.txt文件。(实现)
8. 程序应能支持一万道题目的生成。(实现)
9. 程序支持对给定的题目文件和答案文件,判定答案中的对错并进行数量统计(实现)
三、PSP表格
PSP2.1 |
Personal Software Process Stages |
预估耗时(分钟) |
实际耗时(分钟) |
Planning |
计划 |
30 |
60 |
· Estimate |
· 估计这个任务需要多少时间 |
60 |
90 |
Development |
开发 |
300 |
330 |
· Analysis |
· 需求分析 (包括学习新技术) |
240 |
360 |
· Design Spec |
· 生成设计文档 |
40 |
60 |
· Design Review |
· 设计复审 (和同事审核设计文档) |
30 |
45 |
· Coding Standard |
· 代码规范 (为目前的开发制定合适的规范) |
15 |
20 |
· Design |
· 具体设计 |
60 |
90 |
· Coding |
· 具体编码 |
360 |
420 |
· Code Review |
· 代码复审 |
30 |
30 |
· Test |
· 测试(自我测试,修改代码,提交修改) |
120 |
150 |
Reporting |
报告 |
90 |
120 |
· Test Report |
· 测试报告 |
60 |
90 |
· Size Measurement |
· 计算工作量 |
45 |
60 |
· Postmortem & Process Improvement Plan |
· 事后总结, 并提出过程改进计划 |
30 |
40 |
合计 |
|
1450 |
1965 |
四、解题思路
五、设计实现过程
六、代码说明
项目分为三个包。分别为:
ration, utils, main
其中,ration为有理数包。其中包装了一个有理数类,该类有两个构造方法,可以把字符串,或者两个整型数包装成有理数对象。
还有一个uitls类。其中的方法都为静态方法,有把正常表达式变为逆波兰表达式的toRPN方法,还有计算逆波兰表达式的calRPN方法。
除此之外,还有四则运算,还有一些其他的方法,例如判断是否是负数,判断是否是带分数,也重写了toString方法。
最后是主类,主要是程序的交互逻辑。
七、测试运行
生成的四则运算表达式
生成的四则运算表达式答案
对运算结果进行检验
八、项目小结
刚拿到题目时,我和同伴没有做好充足的计划与准备就开始编写代码,导致途中出现了不少的问题,例如没看清楚需求,修改时不好修改或者不好在原本框架上添加,以及从一开始大局观不明确,走到死胡同时发现无路可走只能从头再来。这次项目实践给我好好上了一课,决不能低估任何项目中的需求,并且在代码编写开始前应该从全局出发考虑,遍及到每一个需求,找到最合适的方法与结构去处理问题,今后我会三思而后行。同时,在结对合作过程中我也学习到对方的不少优点,并且我们在工作中能形成互补,取长补短,相辅相成,让我感觉到1+1>2和合作的快乐与优势。
标签:自动 检索 导致 构造方法 依次 没有 结构 rev 数值
原文地址:https://www.cnblogs.com/wzl666A/p/9696067.html