北航面向对象设计与构造第一单元课程设计总结

杨曜铖22371281 学生 2024-03-21 18:58:32

表达式解析器先将输入的表达式序列经预处理器PreProcessor代入函数，接着使用解析器Parser对表达式进行解析，在解析过程中创建数据管理类型并构建其关系，最终构造一个严格符合原输入表达式的表达式树结构；表达式化简时，由Main直接调用根表达式Calc的化简方法，并由表达式数据类型自动递归调用其内部的化简方法来实现。

设计较好地实现了模块化，尝试和努力实现松耦合设计。在表达式数据结构内，由于数学表达式天然的逻辑依赖性，其耦合度自然较高，因此采用为一个模块，在非数学逻辑上的组合之外尽力实现依赖反转，为内部控制和外部控制提供抽象，例如Main对Calc和Calc对下层表达式类型的抽象的控制使得表达式数据结构成为了控制部件的一个“插件”。

设计中数据管理类均采用了可变对象，即在化简过程中对原表达式树的结构及属性进行修改。其优点是架构逻辑清晰，缺点是实现复杂度相对较高。

应当指出的是，上述架构仍然需要进一步重构和优化以达到最优状态，这是由于第三次迭代开发之后已经无需进行这项工作。

类名	功能	其他信息
Main	进行顶层控制。
PreProcessor	接受输入表达式序列，输出已经代入函数的表达式。
Lexer	接受输入表达式，解析为词法单元序列，接受操作和输出指定的词法单元。
Parser	接受输入表达式，解析为表达式结构树，输出这个表达式树。
Func	由预处理器使用，存放解析自定义函数得到的信息。
Calc	表示任一类型的数学表达式语法项。
Expr	表达式，表达为项的和。
Term	项，表达为因子的积。
Factor	因子，表达为底数的幂。
Base	因子的底数。
Num	数字类型，内部包含一个`BigInteger`，提供运算方法。	也是因子的幂。
Var	变量类型。	一切非关键字的词在解析器中都会被解释为变量。
Diff	需要一阶求导的表达式。
Exp	自然指数表达式。
BigIntegerMultiLooper	工具类，为因子的多项式定理展开提供不定长向量遍历工具。
Debugger	工具类，提供可配置的调试信息输出方法。

质量控制经验

代码高质量的内涵有以下几个要点：

代码应当具有可阅读性，使得任何人可以方便、轻松地了解项目整体结构，可以方便、轻松地从任意位置开始阅读和理解部分代码；
代码架构应当优雅、灵活，符合良好的架构设计原则，能够被方便地理解和扩展；
必须保证对代码的高质量、高覆盖率测试，以一定程度上保障其可靠性。

高质量的代码有一种“优雅”的气息。在开发过程中不断探索和追求优雅的代码，培养对高质量代码的敏锐嗅觉，能够形成对高质量代码的自然感觉。经过本次开发实践的过程，我对这些要点有了更深的认识和认同。

历史错误分析

错误内容	作业次数	错误分析
在化简过程中正负符号合并处理有误	第一次	这是实现的最后一个模块，在实现完成之后进行的代码检查和测试不够充分。另外，在第一次作业时，尚未形成自动化测试，只开发了数据生成器，在中测提交截止互测开启后自动测试才完成开发，并检测出了这一错误。
在化简过程中对`exp()`内的括号层数把握不当	第二次	架构本身并非严格按照文法进行，而是在文法与自然的数学逻辑不相符时，选择采用了更加普适化的数学逻辑。因此，满足这一输出格式的处理是在重写`Exp`类的`toString()`方法时进行判断的，然而在判断时却对文法理解有误，误认为项数为1即可不必嵌套括号，因此出现了错误。
在化简过程中超时	第二次	在处理表达式的幂运算时，使用的是将其展开为表达式相乘的形式再进行乘法运算的方法，使得在幂次增加时化简用时急剧增加。相关的优化见下文“计算时间性能优化”部分。

软件出现的错误基本上与架构设计无关，一般是细节性错误，因此无法分析架构的影响以及复杂度的影响。

整体测试

在软件开发过程中，同步开发了自动化整体测试：kINo204/oo-test-project: A test project for Beihang University 2024 Object Oriented course. (github.com)，其原理是生成数据后，不断将数据在被测程序和sympy库中运行的结果进行比对，将所有错误结果写入错误日志errs.log，从而测试被测程序输出的数学逻辑正确性。测试支持对数据生成器进行各方面配置，以降低生成数据的复杂度。

该方法无法完全检测题目要求的正确性，例如多余的括号会被该sympy库化简约去，从而失去括号层数的信息（例如，这一方法无法检测出上述第二项错误）。

在互测中，直接将被测对象的程序打包为jar包，配置合适的运行参数并运行测试即可得到其错误数据。若运行一段时间未发现错误，可以认为其没有数学逻辑的错误。