项目源码： https://git.coding.net/beijl695/EGener2.git
（代码纯属原创，设计细节不同，请思量）
项目发布后，由于期间各种事情，耽搁至最后一天交付。这次的项目是由我和邵汝佳同学共同完成，感谢partner！
成员：
贝金林（我） 2016012070
邵汝佳 2016012085
psp:
PSP阶段
预计用时（分）
实际用时（分）
计划
5
5
估计这个任务需要的时间
5
5
开发
60 * 24
60 * 68
需求分析
45
11
生成设计文档
45
42
设计复审
30
1.5 * 60
代码规范
10
20
具体设计
60 * 2
60 * 4
具体编码
60 * 12
60 * 50
代码复审
60 * 3
60 * 5
测试
60 * 5
60 * 6
报告
60 * 2.5
60 * 7
测试报告
60
60 * 2
计算工作量
30
60
总结
60
60 * 4
设计：
这些都是面向对象程序设计的基本要求，汗！信息隐藏是类设计的基本要求，只暴露需要暴露的接口和域。接口设计来源于需求，我们在分析需求后进行初步设计，在初步设计时大致地细化类，每个类分别具有一定地功能，并暴露出接口（公共方法）。
这个项目比较简单，但是期间有很多麻烦的事情，比如说单元测试和效能分析。个人认为这些对这个小项目没什么影响，除非将这个小项目一直拓展。
这个项目开始之初，我们对项目进行了需求分析和初步设计。
需求分析几乎是照抄“客户需求”：
初步设计：
然而，做完了这些，具体设计几乎是边设计边写程序了，也就是说我们没有提前进行具体设计。
核心的代码虽然想直接使用上次项目的现成类（包括继承），但是因为需求的变化以及上次项目类的设计还不够仔细，故无可避免地要对现有类进行修改所以就干脆重写代码。对了，这次使用的项目是我做的EGener，它是java编写的命令行程序，在它的类库有我们所需的类，如LeftGenerator，EquationGenerator这两个类。
基于“工厂”设计，我们将等式左边(Left)比作原料，通过左式生成器(LeftGenerator)生成原料，将等式生成器(EquationGenerator)比作工厂，生成完整等式(产品)。
以下列出了类库中的所有类：
这里的类都是后台的核心类，Command就是项目规定的计算模块，可以通过命令行运行；Range是我们设计用来判断是否满足数字上下界的一个类；Test是我们用来做单元测试的主类，我们把单元测试做的比较灵活，我们的单元测试在某些类不能达到90% ，但是对于一些简单类，我们尽量给予保证。
单元测试截图：
可看到简单类（实现某单一功能）的覆盖率达到了百分之九十以上。
关于性能改进：
主要是对于计算模块（Command）。起初，左式生成器生成的左式真的是随机，它的目的就是随机生成运算数，运算符，随机拼接括号（用正则匹配适当位置，随机在“数符数”添加一重括号）；重点是等式生成器，它具有计算，判断，生成的功能。我在等式生成器内部构建了左式生成器，等式生成器的next()方法一定会生成符合条件的等式，因为它在获取结果的过程中，会进行判断。若是出现问题，如生成的中间结果不在Range内，就会调用左式生成器的next()令左式生成器继续生成新等式，再进行运算和判断。(ps：next方法是由random的next产生灵感)
后来在进行测试时，发现运算符多，运算带乘除，数的下界高，上界低都会使程序变慢，因为这些因素都会导致左式回炉的几率高。而我们程序的性能就是由回炉的次数决定的。这时我们意识到不能完全随机，于是我们开始修改LeftGenerator来使它能生产出更容易满足条件的原料。if(rand.nextInt(10) < 3)表示百分之三十的几率产生.....我们经常用这种形式设置随机的概率。我们还发现31以上1000内无乘除，于是就避免了更多垃圾左式的产生。
虽然开始时我们决定在产生带乘除的题目时，一定会带至少一个乘除号。但当31以上时，程序出现死循环；运算符10个，生成1000道带乘除的题，而下界接近于30时，也很难生成。所以我们去掉了一定生成乘除的功能，改为高概率生成一个乘除，低概率生成乘除。
另外，乘除的算数也是决定性能的重要部分，在31以上无乘除；在给定范围内，若有可能，我们高几率生成31以内数字作为算子，使之更容易生成合法的带乘除左式。
我们对于性能的改进比较粗糙，主要由“不可用”改为“可用”我们就很满足了，
1，在Command模块初步实现时，对于生成“1000道[30,1000]，最多10个运算符，带乘除，带括号”的题库，程序运行特慢，一分钟生成一道题，乘除算子只有30和31。通过将“一定生成乘除”改为“大数低几率”的方式生成乘除，这个问题解决了。花时60minutes。
2，虽然解决了主要因数（乘除的产生），但是程序还是不够快，有时一道题要花几秒产生。于是我们再从其他因素着手，对程序进行改进，还是在改进左式（原料），使之生成合理的运算数，使之生成合理的符号等。花时60 * 3minutes。
基于时间成本，我们的性能测试比较粗糙，也许不做精细的性能测试会提高成本，但在实际开发中心理上却很想偷懒。
关于异常处理方法：
异常处理使得程序的正常运行与处理方式分开，通过抛出异常使之能在恰当的地方进行处理。考虑到时间成本，我们并没有设计专用的异常类，因为我们的程序只有两个模块（计算模块和UI）。产生异常的模块若是计算模块，我们再产生异常的地方抛出带有“提示语句”的Exception，使得计算的线程能够中断，抛到UI模块进行处理（显示Dialog打印错误信息）。而UI模块产生的异常直接处理。
Command中：
UI中：
软件运行时：
以上只列出了三种不同的异常（我们的异常由打印的消息来区分），除了这些还有“文件上传失败异常”和“题库解析失败异常”等异常。
界面模块的设计：
界面模块的设计很简陋，由于不会使用图形化操作插件本人最烦GUI的布局。
出题器布局如下：
答题器布局如下：
UI的设计主要由一个主框架，一个菜单，数个对话框和两个面板构成，出题面板的设计思路比较简单：获取参数，出题并导出至文件，回显。
//为“出题”添加监听器
void addListenerInGener() {
generB.addActionListener(new ActionListener() {
public void actionPerformed(ActionEvent e) {
System.out.println("aadfdasfdasfasd");
num = numF.getText();
oNum = operF.getText();
down = rangeDownF.getText();
up = rangeUpF.getText();
isWithBrackets = isWithBracketsC.getState();
isWithMD = isWithMDC.getState();
StringBuilder sb = new StringBuilder();
sb.append("-n " + num + " -m " + down + " " + up + " -o " + oNum);
if(isWithBrackets) {
sb.append(" -b");
}
if(isWithMD) {
sb.append(" -c");
}
String[] args = sb.toString().split(" ");
BufferedReader bf;
try {
//调用 Command出题
Command.main(args);
//回显到TextArea
File file = new File(".." + File.separator + "result.txt");
bf = new BufferedReader(
new FileReader(file));
String line = "";
generT.setText("");
while((line = bf.readLine()) != null) {
generT.append(line);
generT.append("\n\r");
}
remindL.setText("已将题目导出至" + file.getCanonicalPath());
remindDia.setVisible(true);
bf.close();
} catch(Exception ex) {
String errMsg = ex.getMessage();
errL.setText(errMsg);
errDia.setVisible(true);
System.out.println("massage:" + errMsg);
}
}
});
答题器的思路：通过FileDialog获取txt文本，同时导入Exam的对象中，Exam的对象是专门为答题器设计的。Exam会读取文本文件（若文件内容不符合则抛出异常），并将文件的题目进行解析和优化（去空格和等号），调用内置的等式生成器产生结果，并将题目和答案存入映射集合中（同时起到去重作用）。Exam的对象暴露了许多接口，如获取答题的时间，答对的题数等等。因为Exam模块由于是提前做的，所以可能一些接口没有用上，留着以后用吧。Exam对象导入题目后，用户可点击“开始答题”进行答题。在UI中，我们设计了三个方法来控制出题：beginExam，check 和endExam，它们分别用来控制出题，验算和结束答题的行为。
void beginExam() {
String question;
if((question = exam.next()) == null) {
endExam();
return;
}
questionL.setText(question);
answerT.setText(null);
examD.setVisible(true);
}
void check() {
String answer = answerT.getText();
boolean isCorrect = false;
isCorrect = exam.isCorrect(answer);
if(isCorrect) {
checkL.setText("恭喜你，答对了！");
}
else {
checkL.setText("很遗憾，答错了，" + exam.getQuestion() + "=" + exam.getAnswer());
}
examD.setVisible(false);
checkD.setVisible(true);
}
void endExam() {
exam.end();
String result = "已回答" + exam.getNumOfDone() + "题，" + "共答对"
+ exam.getNumOfRight() + "题，答错" + exam.getNumOfWrong() +
"题，" + "用时" + exam.getCostTime();
checkD.setVisible(false);
examD.setVisible(false);
file = null;
exam = null;
uploadT.setText("");
resultL.setText(result);
resultD.setVisible(true);
}
添加监听器等各种UI的实现细节不用细说，因为显而易见。
结对过程：
在项目开始时，两人先对项目进行了需求分析和初步设计，然后我们进行了分工（我负责计算模块代码，邵汝佳负责UI的代码）。我花了一天的时间初步实现Command，然后我们又线下对代码进行单元测试，（我们的单元测试比较灵活，在一个main方法里测试许多单元，我们没有进行分别保存，这是个疏漏。）同时我又单独在产生错误的地方进行回归测试，尽力保证代码的健壮性。当我们负责的模块都初步实现了，由我对各模块进行拼接（实际上我重构了UI代码T-T，因为我读partner的源码比较困难）。感觉结对项目这种方式适合基础还行的 ，感觉我们的基础还不行，效能分析只能通过分析设计来估算，而不会用专业工具（即使有教程，笨）。至于单元测试，编程的过程中是必须用的，我理解的单元测试是保证细小模块的功能运行正常，但是测试有没有疏漏就在于单元测试代码的覆盖率。然而，我编程的时候，却很少正规地进行单元测试，现在想起还是必要的。至于coding.net的源代码管理那就更不会用了，我直至现在还把它当做一个网盘。
总之，结对编程适合有一定编程经验，懂得完整开发流程的。否则，那就不是一加一大于二，而是一加一小于二或一加一小于一了。
对partner的评价：
1，认真，为了UI编写，专门去学了UI。
2，好学，遇到问题不懂就问，对于一些JVM原理比较感兴趣。
3，耐心，会耐心测试程序中出现的bug，并汇总。
4，基础知识不扎实，编写的源码不规范。
对自己的评价：
1，辛苦，每天都在设计，编程和debug；
2，认真，项目开始前为自己设计了PSP表格并如实填写，写过设计书。
3，可以，感觉我的设计还可以，继续拓展更多的东西没问题。
4，经验不足，虽然想完全按流程进行开发，但是效率不高，开发中学习耽搁的时间太多。导致这次项目的单元测试不正规，以及没有做精确的效能分析。
