BUAA OO 第四单元总结
BUAA OO 第四单元总结
总结本单元作业的架构设计
架构设计
1、对元素进行再封装
以UmlClass为例，对于每个类，除了课程给定的UmlClass类中所包含的getId、getName等功能外，我们还需要实现一些其他功能，比如查询这个类的父类是谁，这个类实现了什么接口，这个类都有什么方法和成员属性等。
这个时候，为了扩展Class的内涵，可以选择对UmlClass进行再封装，建立MyClass类，伪代码如下：
public class MyClass extends MyElement {
private UmlClass umlClass;
private ... AttributeList;
private ... OperationList;
private ... fatherClass;
...
public MyClass getFatherClass() { return fatherClass; }
public void addAttribute(... attribute) {
do something;
}
public Map<Visibility, Integer> getOperationVisibility(String methodName) {
do something;
}
...
}
对于其他已有的Uml类，如有必要都可以按照此方法进行再封装。
2、类图分析
UmlClass -> MyClass的转化通过Updater类实现。
之所以选择新建一个uml分析类，是因为uml元素较多，分析过程较为冗长，单独建类较为简洁。
先通过init函数将读入的elements分类：
private void init(UmlElement... elements) {
for (UmlElement ele : elements) {
if (ele instanceof UmlClass) {
将ele放入umlClassMap
}
...
}
}
再从每类uml元素的列表中，提取元素进行再封装：
private void updateClass() {
for (Map.Entry<String, UmlClass> entry : umlClassMap.entrySet()) {
UmlClass uml = entry.getValue();
MyClass my = new MyClass(uml);
do something
}
}
3、有效性检查
新建了一个Checker类进行有效性检查，因为多数规则的检查不是能够在一个元素内部解决的，涉及多种uml元素，所以我们要么在MyImplementation中进行集中处理，要么就另建类处理。我选择新建了一个Checker类进行有效性检查，这样更为简洁，不然MyImplementation中内容过于冗杂。
4、数据结构
主要采用hashmap对于元素进行管理，因为hashmap可以比较方便地支持按id查找或按name查找。
private HashMap<String, UmlClass> umlClassMap;
总结自己在四个单元中架构设计思维及OO方法理解的演进
第一单元
第一单元的主题是表达式化简，主要训练的是层次化设计能力。
之前C语言程序设计中，由于是限时做题，难点主要在算法上，我采用的策略都是怎么方便怎么来，根本没有注意过架构的设计，往往就是定义一堆叫a、b、c、d的变量，然后就是面向过程按逻辑一main到底。这种编程方式，在面对大码量、对象化、多文件、可拓展的项目设计要求时，就会暴露出很大的问题。所以我在HW1的架构方面就遇到了困难，一直拿不定主意。在完成了第一次训练后，学习了助教提供的代码结构，一切才好起来……
本单元架构设计主要分为两部分：解析表达式和简化表达式。
解析表达式方面，我一直采取的都是训练中提到的递归下降的方法，这个方法非常高妙，在之后几个单元的编程中，这个方法的思想我也时常用到。
简化表达式方面，我主要是采用了一系列的字符串操作进行的，并没有设计独特的架构。
本单元是我面向对象程序设计的第一次尝试，很多地方看起来还是面向过程的，比如简化表达式的部分。但第一单元通过3次迭代开发的作业，还是让我体会到了面向对象的思想特质，也让我开始意识到了一个好的、可拓展性强的架构，可以大大节省之后的迭代时间，而节省下来的时间又可以用来进行算法的优化和性能的优化。
第二单元
第二单元的主题是电梯调度，主要训练的是多线程程序设计与线程安全。
整体架构参考了实验课的代码，基于生产者——消费者模式。大体思路是，输入处理类接收输入包的指令输入，对指令进行分析，将指令分配给对应电梯的请求队列Queue（在这里分配的原则是，根据请求所在楼座，分配给对应楼座的电梯）。请求进入电梯的请求队列后，按照电梯运行策略进行运动。
第二单元通过3次迭代开发的作业，让我体会到了多线程程序设计的思想特质、让我学会了多线程的基础知识和编程方法，熟悉了同步块与锁、线程安全设计、多线程设计模式等内容。
作业难度不小、颇具挑战，多线程的不确定性、一些bug的难以复现性更是为我带来了不小的困难。在线程安全设计，并发及其协调设计、并发场景的需求分析与设计等方面我还需要继续加强。
第三单元
第三单元的主题是JML契约式编程
这个单元对于架构设计的要求不高，重点在于对于JML的理解。我初步学习了基于规格的层次化设计，了解了JML规格，学会了如何读懂JML，如何书写简单的JML，如何基于规格进行程序设计等内容。初次接触规格，感觉JML的难点主要有两点：一是JML语法，比如各种操作符的含义；二是复杂JML难以理解，有些JML的表达式非常长，又嵌套了很多的\forall，\exists等逻辑较为复杂的子表达式，给理解带来了困难。我解决的主要方法就是，多层嵌套的JML表达式先进行分层，然后就是一遍遍地阅读，搞清楚每一层的含义。
第四单元
第四单元的主题是UML解析
架构在前面已经提过了，架构设计主要就是对于已给定的Uml元素的再封装上。同时我觉得这个单元的难点在于对于指导书的理解上，因为元素真的挺多的，指导书上对于数据的限制也很多，如何准确理解指导书，找到各个元素的数据什么地方有限制，什么地方没有限制需要我们处理，是正确完成该单元的重点。
总结自己在四个单元中测试理解与实践的演进
第一单元和第二单元，主要采取随机样例测试+自己构造边界数据的测试方法，在第一单元效果较好，但是第二单元由于多线程有一定随机性，因此还是出现了课下测试没有检查出bug导致被hack的情况。
第三单元和第四单元，随机样例测试+自己构造边界数据的测试方法继续沿用，再加上了与同学的对拍测试。第三单元的测试的难点在于控制异常发生的频次，随机测试大部分数据输出都是异常，实际上减弱了测试的效果。
此外在第三单元的训练中，我学习了Junit测试相关的内容，对于如何进行Junit测试有了了解，在HW1和HW2中也有所使用，但感觉由于方法较多，加上编写Junit测试程序不太熟练，导致测试效率较低，迫于时间原因，并没有进行详尽的Junit测试，而是以找同学使用自动评测机对拍为主。
总结自己的课程收获
首先，我学会了JAVA的基本知识与编程方法，了解了面向对象的编程思想。随着单元学习，掌握了层次化设计方法、多线程程序设计与线程安全、JML规格、UML图等内容。还有，对于递归下降法等编程方法有了认识，学会使用了多种设计模式等等。
此外，每周的作业迭代设计，锻炼了我程序设计、架构设计、算法使用的能力，也锻炼了我阅读指导书，了解项目需求的能力。每周的强测和互测惊心动魄，暗流涌动，课下的测试锻炼了我的bug自查能力和debug能力，互测锻炼了我阅读他人代码和检查bug的能力。
课程很有趣，也很锻炼人。吴际老师精彩的理论课讲解、助教的耐心解惑、训练和实验课中示例代码的精妙架构、研讨课上与同学们的思维碰撞相互学习，都让我印象深刻、收获良多。
三个具体的改进建议
1、希望实验课后，可以提供一下评测结果。
2、加强中测，尤其是第二单元，多线程的bug在本地不易发现。
3、建议在预习环节加入JML相关知识的介绍和UML顺序图状态图的介绍。
