我的项目《四则运算题目生成程序》分析总结

1、Planning：

PSP2.1	Personal Software Process Stages	Time
Planning	计划
· Estimate	· 估计这个任务须要多少时间	2h
Development	开发
· Analysis	· 需求分析 (包括学习新技术)	2h
· Design Spec	· 生成设计文档	1h
· Design Review	· 设计复审 (和同事审核设计文档)	1h
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	30min
· Design	· 具体设计	1h
· Coding	· 具体编码	3h
· Code Review	· 代码复审	1h
· Test	· 测试（自我测试，修改代码，提交修改）	3h
Reporting	报告
· Test Report	· 测试报告	1h
· Size Measurement	· 计算工做量	30min
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	1h
	合计	17h

 

2、Development：

一、需求分析

对题目中的要求进一步剖析，明确要注意的点以及须要进一步明确的技术等。

1. 参数内容的获取方式
2. 按照算术表达式的生成语法规则来进行构造和解析，空格将做为分隔符号，而且应该注意需求345的约束条件
3. 对于重复问题，先判断结果是否相同，结果相同再判断他们是否可以经过有限次的交换来转化
4. 将题目和答案分别记录到相应的文件中去
5. 对给定的题目和答案文件进行断定，须要解析题目的语法

二、生成设计文档

a) 类的建立：

i. 根据计算的需求，在这个项目中须要对天然数和分数进行运算，那么就有必要建立一个新的类用于表示天然数和分数

因而设计一个class Item，其主要的成员变量是 denominrator(分母)和numerator(分子)；

而后重载+-*/这四个运算符来实现计算；

同时还有一个关键的函数是toString()，用于方便后面放进具体的表达式中。

ii. 最终是为了生成表达式，那么就须要建立一个表达式类class Expression

其主要的成员curValue 来记录当前表达式的值，expressionString用于记录表达式的字符串形式，level用于记录当前表达式有多少个运算符，lastoperator用于记录最后一个运算符的类型；

同时为了后面可以判断表达式是否重复，还分别记录了表达式中各类运算符号的个数，而且将生成过程当中的子表达式的值也给保留了；

而后在构造函数中，须要的参数是数的范围以及运算符的数目，具体的表达式构造方式请见下一部分。

b) 表达式的生成方式：

主要是根据表达式中运算符的数目，利用递归的方式从更简单表达式（运算符数目更少）生成。好比2运算符-表达式能够用1运算符-表达式加上一个符号一个操做数来生成。因而，我决定采用的方式是：先生成1-运算符的表达式，再用它去生成2-运算符表达式，而后再考虑生成3-运算符表达式。这个生成顺序也是个人计算顺序，至关于先 生成的表达式我都保证运算时优先，这时候若是它的最后运算是加减法我就加上括号。

这样一来生成的表达式的值我就可以很好地把控住。

c）如何判断重复，以及如何解决参数要求是否可以知足：

用排列组合的方法也只能差很少推导出上界和下界，然而好像并不能很好得去肯定是否可以生成足够的不重复表达式。因此我仍是偏向于从几率的角度，若是连续生成的好几个新的表达式都被判断出与已有的表达式重复，则说明可能差很少没法再生成不重复的表达式，就直接终止程序。

而如何重复就是用个人表达式对象中的各个参数进行比较，若是都相等，这个时候重复的几率很是大，因此直接舍去。

d) 对于检验对错：

就是解析字符串，先将中缀表达式转换成后缀表达式，而后将后缀表达式进行求值，这个过程当中利用了栈以后将很好完成。

三、设计复审

四、代码规范

（这两个方面在实际过程当中几乎是隐藏在和同窗们的交流和讨论中的，没有很严肃严格得进行这两个环节）

五、具体编码

这个过程是整个项目开发中费时最多的环节，而后也是烦恼最多的部分，遇到了不少细节问题和bug。具体有如下几个方面：

a) 字符问题：因为考虑输入输出中有extend ASCII， 也就是× 和÷ 号，因此在处理过程仍是费了不少时间去弄明白它们在char, char*和string中的存储方式，最后试验以后仍是发现使用起来比较方便。

b) 运算方面的细节问题：有一些表达式的逻辑没能处理得很好，而后有一些漏洞，最后在分析计算结果的时候花费了较大的时间。

这个方面我以为可能之后注意在开发的过程当中注意单元测试，而后尽可能在小规模代码下将基本问题解决，可能会有利于问题的解决。

c) 涉及语言的熟悉度方面的问题。（在点滴中消耗了不少时间）

六、代码复审

主要是debug，而后解决的分别是字符问题，输入输出问题，运算正确度问题。

七、测试（这个部分也是我判断本身程序正确性的初步环节）

首先测试各类参数组合形式的输入。

再来是尝试生成表达式，而且抽样检查是否规范。

接下来是输入特定组合的表达式，检查求值状况。

多轮下来，最后发现基本没有什么问题。

3、性能分析与优化

 

在分析性能的时候选的参数是-n 10000 -r 20

在性能问题上主要是后期生成的每一个表达式都须要与前面生成的大量表达式进行判重。能明显觉察到后期生成表达式的速度变慢了。

为了可以进一步优化的时间的复杂度，能够选择考虑用新的结构将表达式组织起来，从而可以更快的判断是否重复。

通过和同窗们的讨论发现，其实有几个同窗采用的就是打表的方式，每生成一个表达式划掉一个值，这样判断重复就快多了。

 

总结：

实际的使用时间

PSP2.1	Personal Software Process Stages	Time
Planning	计划
· Estimate	· 估计这个任务须要多少时间	1h
Development	开发
· Analysis	· 需求分析 (包括学习新技术)	2h
· Design Spec	· 生成设计文档	2h
· Design Review	· 设计复审 (和同事审核设计文档)	1.5h
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	1h
· Design	· 具体设计	2h
· Coding	· 具体编码	6h
· Code Review	· 代码复审	1h
· Test	· 测试（自我测试，修改代码，提交修改）	3h
Reporting	报告
· Test Report	· 测试报告	1h
· Size Measurement	· 计算工做量	0.5h
· Postmortem & Process Improvement Plan	· 过后总结, 并提出过程改进计划	2h
	合计	23h

4、收获与感悟

一、关于程序存在的几点漏洞说明：

a) 对程序的输入格式要求比较严格

好比在检验四则运算的正确性这个环节，个人程序的读入方式要求在序号的“n.”后面紧跟着一个空格，而后再是表达式或者答案。

其实这个问题在使用过程当中仍是会存在一些问题的，由于没有给用户进行提示说明就将输入的格式限制住了，其实对用户体验来讲不是很好，下一轮要改正这个缺陷。

b) 在性能上面存在一些缺陷

在这里比较表达式是否重复其实是O(n²)的复杂度，或许能够采用某些特殊的方式在这里进行优化。

二、关于项目开发的计划、设计与实现方面的体会：

我我的的体会是计划当然是很是重要的，可是在现阶段我的能力以及经验仍是明显不够的，因此在对项目各个阶段用时的估计上面会过度乐观，结果反而容易形成在开发过程当中对时间的把控显得不够，影响整个开发的节奏。

而后是设计与实现，设计应当细化到什么程度呢？

这是我一直很疑惑的问题。通过这么屡次的相似项目（做业）的实践经历，我想我认识到了一点，对我我的来讲，必定要勇敢去实践，由于对我我的来讲，我喜欢将不少东西放到脑壳里面而后让它不断发酵，同时让本身在有意无心中去产生灵感、好的想法来解决问题，这种方式有时当然可以带来不少惊喜，可是同时也让我愈来愈不重视编码的这个过程，而实际上在编程过程当中不管是语言工具的使用仍是算法的运用方面都会遇到一些小的阻碍。

因此我认为现阶段我给本身定的提升方法是：增长敏捷度。提升设计的效率，而后在实现的过程当中去不断碰到问题解决问题。有时不是要越过问题，而是要经过对相关问题理解认识来旁敲侧击，从而在主要问题上面有新的理解和认识。因此要习惯于专一编程的过程，在这个过程当中不断优化设计，不但回归理论和知识，而后甚至屡次迭代。

毛主席《实践论》中的哲理也能够用到设计和具体实现过程当中来，要二者不断补充，从而使提升开发效率，提升产品质量。

三、在我的习惯和心态方面的感悟

看到有的同窗作的PSP安排和规划，确实感受到了软件工程师的我的习惯和态度在很大程度上会决定它的项目是否可以顺利在预期时间内完成，而且在很大程度上会影响产品的质量。

发现本身确实在从此这门课的学习上面要更加投入一些，珍惜此次锻炼的机会，借助此次课的机会好好体验软件开发以及团队合做，开发出让人满意的产品。