OO第四单元作业总结

一.第四单元作业架构设计

　　不知不觉中，已经到了最后一个单元了，而这一个单元主要是对UML的分析。由于第二次作业包含了第一次，所以我重点分析了第二次作业。一般只要看懂源码的element包，弄清楚每个元素之间的关系，和每个元素中包含的信息就能够成功的写出正确的答案了。如图

在这张图中就有我们需要解决的所有元素了。在讨论区中也有同学对此进行了详细的分析。而当时我遇到过几个比较坑的地方就是，在association的end1和end2存的是associationend的id。而associationend中所存的才是两个所关联的对象的id。而其他的就比较简单，可以比较轻松的看出他们之间的关系。

 

容器

在这次单元中，我主要用的是hashmap的容器，主要有通过id找uml,通过parentid找uml，还有一些针对特殊元素查找的容器。如图

而在这里面有比较特殊的就是二维数组了，这个是用来解决图中重复继承和有循环图的判断，用的是图中的算法WarShal算法

当对角元素不为0时，就代表有循环继承了，当有元素大于1时就代表重复继承了。

其他的一些方法大部分只用在相对应的容器里进行搜索就行了，并没有什么复杂的地方，感觉因为是进了烤漆，所以没有出很难。

 

二.四个单元递进架构设计和oo方法理解递进

第一单元:多项式求导

 第一单元我们是进行的多项式求导问题，在这一单元，我们主要学习了正则表达式的用法，还有java的基础语法，可以说通过这一单元我们可以用java写一些简单的程序了，但是面向对象的思维还不是很深入人心，还是按照c的方法来写。

 

第二单元:线程电梯

在这一单元，我们学习了多线程，而这一单元也可以说是最难的一单元了。在这一次作业中，我将调度器和电梯运行分开，用了单例模式。而且也学习到了怎么用锁。但是自己还是用的是最基础的算法，先来先服务，开始自己想着如果换了算法很容易被特殊例子卡时间，没想到后面互测时没有卡时间的限制了。而自己又不想改变自己算法。

 

第三单元:JML规格

在这一单元架构基本都已经被设计好了，而自己所需要做的就是选择容器，选择时间复杂度小的算法。

而这次重要的是对oo方法的理解，由于java限制比较小，可以做许多事，所以我们要注意规格，JML就是一种java建模语言。我们在写一个程序项目时，应该注重于目的，条件。把这些做好了再来想具体的实现功能。

 

第四单元.UML

这一单元和上一单元类似，重要的是让我们学习UML的用法，我们写的代码对UML图进行分析，其实就是为了加强我们对UML的理解，而时间有限，再加上烤漆的来临，自己对UML的理解，并不是很深。

 

三.测试理解与实践的演进 

第一单元:多项式求导

第一次测试的时候，自己还未想到对拍器等一系列用程序来测试的方法，自己主要是自己手打对一些边界的条件进行验证。自己也和其他同学一起进行了线下之间的互测。当然毕竟人力有尽，自己还是有一些bug。我也找到了一些bug，发现有一些bug是程序特有的，如果只是简单的边界或压力测试，而不看代码，是并不能够找到bug的。

 

第二单元:线程电梯

 这一次中在研讨课上有同学分享如何进行对拍，如何用程序进行验证，自己也写了一个程序，然后让程序来找bug，这样的确能找到一些比较隐秘的bug。但是对看代码却并没有很大的帮助。

 

第三单元:JML规格

 这一次比较特殊在于规格已经确定好了，我们可以用Junit来对规格进行覆盖测试，而在互测中也和上一次的一样，写了个对拍器。自动的进行测试。

 

第四单元.UML

这一次并没有互测，所以主要是自己对自己的程序进行验证。而我认为重要的地方在于对方法的理解，明确方法到低需要什么。自己再写几个测试样例。

 

四.总结收获

 转眼间，oo这么课就这么结束了，在上之前听学长学姐说，这门课的互测是多么的魔鬼。在经历这一切后，发现其实还好，只要自己在每一单元认真的完成作业，认真的看指导书，认真的听老师讲解，还是很容易的完成每次作业。当然我认为这也离不开这一届助教的改革，对整个oo课程都进行了很大的变化。

而且在这门课中也提醒了我们很多人忽略的地方，那就是代码风格，很多人写代码只是完成任务就行，根本不在乎可读性的问题，而这一次也养成了我们代码风格的习惯。

更重要的是这么课让我学会了面对对象的思想，虽然有可能学的并不是很好。但是这门课后，我能够就像开学老师所说，一周写1000行代码没有问题。而且当我在构思，在写代码时，总是很愉快，特别是在完成一部分功能时，总是看着自己所写的代码。为自己而感到开心。

 

五.三个建议

1.实验课和理论课

每次上午上完理论课，下午就要进行实验，没有时间进行消化。建议隔一周再进行相对应的考察，留个缓冲区。

2.互测人数

个人认为互测屋8个人太多了，如果要清楚的看清一份代码起码要花几个小时。而总共有7份，这样导致了许多人就只是写了个对拍器，没有认真的分析代码，阅读其他人的代码。建议互测屋4-5个人比较合适，这样每个人的代码基本都有时间看。

3.指导书

指导书有一些方面目的不是很明确，往往要在讨论区里才能找到答案。当然这也不能怪老师和助教，比较发现问题总是要简单的多，我希望可以多举几个例子，这样我们就可以从例子中理解指导书的意思。