OOA(Object Oriented Analysis，面向对象分析)： 从客观存在的事务和事务之间的关系，归纳出有关对象（包括对象的属性和行为）以及对象之间的联系，并将具有相同属性和行为的对象用一个类(class)来表示。建立一个能够反映真实情况的需求模型。
OOD(Object Oriented Design，面向对象设计)：将面向对象分析阶段形成的需求模型进一步具体设计。如类的设计（继承、派生、类与类之间的消息协作）、算法的设计等。采取通用的工具，如流程图、类图等来描述。
在编码前我有手写过一些文字，大概就是要分几个函数，然后各个函数大概的接口长什么样子（不确定，只是初步），负责什么功能。我的前期草稿大概就这样，没有像这次题目要求的这么细致。很多东西都是到了真正编码的过程中遇到了问题or发现了更好的方法才加以改进的。
我觉得我把我的代码解释一遍就达到作业的要求了！一图胜千言，但发现画出清晰的图并不是很容易的事情。
类与接口
对于类，我只设计了一个表达式类。剩下的东西我觉得不足以用“类”去归纳它们。我现在是这么认为的：如果一个“东西”是名词，那么就可以写成类，如果这个东西是“动词”，那我觉得不应该写成类。比方说，这个“东西”是“表达式”，那么就可以写一个表达式类，里面私有成员包括中缀形式的式子、逆波兰形式式子、表达式的正确结果，以及一些方法。但如果这个“东西”是“交换”，“交换”是一个方法，那么我不喜欢把它写成类，而是写成swap函数。
如果要把swap写成类，那么方法就是对字符swap、对整数swap、…… 我不太赞成，我觉得应该是对一个“名词”写一个类，里面包含一个方法，叫做swap。
类图如下：
主函数框架如下（虽然觉得UML的图很高大上，然而还是不会画，所以先用lowb流程图）：
主函数串接了以下模块：语言资源文件模块、输入输出以及输入合法性检测模块、表达式相关以及答案检测的核心模块。主函数为上述模块提供输入，并将结果显示给用户，通过输出到文件或者标准输出的方式。
类中通信过程以及算法：
我这里主要想通过流程图介绍自己的思想。在图中我标注③和④的部分是主要的算法所在。但这两个部分的东西可以通过上网查阅资料学习，这里就不做流程图了。
下图是表达式产生的过程：
三个私有成员：expression 是显示给用户的中缀表达式，用 reversePolishNotation 来计算value 。用 value 和用户输入的答案比较正确与否
我的思路：长的表达式是由小part和运算符组成的。part可以是一个数，也可以是一个形如 (a+b) 的式子。part 和 part 之间再用运算符（oper）连接。整个式子的形式是（以式子的part数为3举例）：part oper part oper part 通过 part 来实现表达式的生成是我的想法，好处是：容易加入括号、容易实现不同长度且形式随机的表达式、并简化了程序的编写。
只要 part 内部的运算值合法，且 part 和 part 之间的运算值合法，就可以认为整个式子的运算值一定合法。不合法的例子包括：除以0和除不尽（对于小学生直接抛弃除不尽的除法式子）。可以看出来，都和除法有关。
解决方案：
- 单个 part 内，比较容易，part 如果是形如 (a/b) 的式子，让 b 不为 0 即可。
- part 和 part之间，用 val1 存前一个 part 的值，val2 存后一个 part 的值。当 part 和 part 之间的符号出现了乘除号，是 val1 和 val2 派上用场的时候。具体就看图吧。
最后说一下感想：我觉得这是栋哥这学期以来布置的最好的一次作业，甚至应该在寒假作业三之前布置这个作业，而不是先布置编码，让大家知道：一个好的工程不只有写代码（当然敲代码也很重要。。。）。先给出大致的框架，然后再修修补补，这样也不至于在编码的时候特别暴力或者无头绪。
附上学习链接：
- UML的9种图例解析 —— 特别完整、、我没看完。。
- UML学习（二）-----类图