OO最后一次作业

终于开始最后一次作业了，是时候为这学期oo画一个圆满的局句号了。

回首这学期的OO经历，一路走来，经过了开始对面向对象的初步接触，然后就是充满痛苦回忆的多线程，接下来到了令人焦头烂额的规格设计，最后是测试和论证，中间还穿插着几次（用来放松的）博客作业。这些作业把我这个学期填充的十分充实。

那么还是先把这次作业写完再说。

---

测试与正确性论证

这一部分接触了两种论证手段，就是测试和正确性论证。

测试使用了junit4的测试框架，针对每个方法来进行规格测试。核心在于构造完备的子集，保证能覆盖到每一条语句以及每一种情况下，方法都能正确完成。初次接触junit4，感觉还是挺简单实用的一种测试方式。

优点：直观，覆盖率和测试结果都能直观显示出来。

缺点：难以覆盖所有情况。且对于repOK这些方法没有办法测试与覆盖。

正确性论证是基于逻辑来验证自己的代码是“正确”的，描述自己代码所有可能的情况，进行严密的逻辑验证。

优点：覆盖性强，逻辑性更为严密

缺点：对于稍微长一点的方法就很难验证其正确性，往往需要长篇大论的论证。一份完整的正确性验证报告估计没有一二十页写不出来。（还好今年是没有互测这玩意）

效果差异：测试是从测试样例的覆盖来测试程序的正确性，而正确性论证则是通过逻辑来严格的验证程序正确。总的来说这两种测试手段都各有用武之地。

---

OCL语言

ocl语言（即object constraint language，对象约束语言）从名字就能看出来是一种约束语言。一个约束就是对一个（或部分）面向对象模型或者系统的一个或者一些值的限制。UML类图中的所有值都可以被约束，而表达这些约束的方法就是 OCL。

OCL的基础是数学中的集合论和谓词逻辑，并且它有一个形式化的数学语义，但是它并没有使用某种数学符号。因为虽然数学符号能够清晰的、无歧义的表达事物，但是只有极少的专家可以看懂。所以数学符号并不适合用于一个广泛应用的标准语言。

用OCL可以描述四类约束，分别是不变量、前置条件、后置条件和监护条件。

1）不变量是在属性的生命期内一直保持为真的规则。

2）前置条件是在一个操作被调用时必须为真的约束。它是一个断言，不是可执行语句。

3）后置条件就是在操作完成时必须为真的约束。它不是可执行语句而是断言，必须为真。

4）监护规则是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。

相似点：都有前置条件和后置条件，都是无二义性的精确语言，来对程序进行约束

不同点：OCL语言标准更完善，表现力更强；JSF可以看做一种简化过的OCL语言。

---

第14次作业UML图

类图

UML顺序图

UML状态图

---

学期总结

写完这个部分然后提交，这学期的oo旅程就算正式结束了。（应该会是星期一晚上写完，做一次ddl战士）用博客来回顾一下这学期的面向对象之路，也回顾一下这个学期是否让我感到充实。

微小的工作：

这学期的OO一共分成了四个单元，每个单元三次编程作业（最后一次调整了只有两次，可喜可贺）加上一个总结性的博客。回过头来总结一下这四个单元究竟学了什么：

（1）JAVA编程入门，面向对象编程入门（+互测入门）：

这一部分的三次作业是：多项式相加，傻瓜电梯，ALS电梯。

说是面向对象编程入门，实际上大多数同学做第一次作业之前连JAVA都没有写过，第二次作业开始就要写有一定规模的面向对象程序了。可以说是一周的JAVA速成加上一周的面向对象速成加上一周的面向对象进阶。

（2）JAVA多线程从入门到入土：

这一部分的三次作业是：三线程ALS电梯，IFTTT实现文件监视器，100辆出租车调度程序。

这一部分难度有了质的飞跃，实现JAVA多线程编程。途中debug，编代码（主要是电梯）遇到了各种各样的不明所以的奇奇怪怪的bug，让我们认识到多线程的强大以及线程安全的重要性。不过同样只有一周时间就要我们写完一个难度极高的电梯，也可以说是一周的JAVA多线程速成了。

（3）面向规格的设计（与互测）：

这一部分的三次作业是：在出租车程序中增加道路流量，增加红绿灯，增加可迭代的出租车。

这一部分仍然是用多线程实现JAVA的多线程，但是侧重点变了。由实现程序的正确性（包括线程安全问题）变成了设计层面问题。如何做出优雅的设计，如何编写出无懈可击（不被扣分）的JSF。

（4）测试与论证：

这一部分的三次作业是：基于Junit4的测试与覆盖，正确性论证，UML图的绘制（博客）

这一部分的学习任务从编写转为了测试与论证，对于规格、设计的要求也上升了。

总的来说这学期的学习内容还是十分充足庞大的，涵盖了除了面向对象的几乎大部分内容。也难怪有前辈指出，北航面向对象的格局，跟其他学校是完全不同的。整套面向对象课程体系完整看下来像是一整套程序编程的体系，从正确性到安全性，再到优雅设计，最后是测试和论证；而完全不像仅仅是面向对象的课程，还是挺有意思的。

程序的进步：

（1）设计：这部分还是很明显的。从一开始写多项式poly都感觉有点费劲，完全不会面向对象，只能按照提供的框架一步步来写。二三次电梯的设计虽然能看到一丢丢面向对象的影子，但是设计还是不够细，仍然有god类和idiot类出现。到后面两个星期能写出难度不小的多线程程序，电梯（虽然bug不少)和IFTTT。尤其是能在一个星期内写出来这样的程序，当时肯定是不敢想的。然后写的出租车已经颇有面向对象的风范了，对于抽象对象，提取共性写方法也逐渐熟练了起来。

（2）测试：从一开始只会system.out，到现在知道了junit4这种方便的测试工具。至于测试别人的代码，还是佛系一点吧。

（3）代码质量：跟1一样也是很明显的进步。一开始的ALS电梯出现了一个奇长无比的方法（虽然我也懒得改了），现在看来里面充斥着各种无用的废话。包括写第一次作业和第二次作业时候也还有造轮子之嫌。虽然有些人说造轮子并不是完全没有意义，但我自己看来这些轮子造的是真的没有意义。明明有更加方便的工具却还是写了一堆冗长无用的废代码，确实很不应该。在了解了JAVA的方便之后，各种内置的工具确实比自己造的轮子高到不知到哪里去，可读性质量都比以前好了不少。现在看来之前的代码写的确实是辣鸡啊。

另外一点进步就是心态，面向对象真的很锻炼心态，让我更加坚强了。

工程化的一点理解：

之前并没有写过工程啊。。。也并不知道什么是工程化。

不过还是得完成作业，在我看来工程化应该是很多人一起完成的。所以对于个人来说，代码一定要保证精简和可读，做好封装、写好注释以及规格。

代码可读性强是基本的，毕竟在一个庞大的项目中，出现一个可读性差的代码显然不是明智的。而对于一个写好的代码，应该让项目的其他人更好的理解自己写的内容，所以规格和注释也是十分必要的。

同时还要做好代码的规范性，统一编程的规范才能让团队便于理解和维护。

小小的建议：

这里对课程的各个方面提出小小的建议和意见：

首先是难度方面的

如果不打算降低难度的话不算什么建设性意见，可以直接跳过。毕竟我的oo旅程已经快结束了，再难也跟我没关系了，希望下届的学生能撑过来吧hhh。

（1）课程内容方面（作业量）：

课程内容还是十分丰富的，瑕疵是跨度和难度略大。尤其是作业量十分充足，一星期一个大工程。面向对象的程序都还不怎么会写，就已经要求写很难的多线程程序了。而且一星期速成多线程，还是那么难的电梯，哪怕能写出来质量也不见得一定很高。而且听说下一届的os难度会加大，不知道双重课业压力之下，下一届的学生能不能承受住了。

就我自己来说，在oo重压那一段时间基本是为了oo放弃了os的，可能是因为我太菜了，实在是无力应对这样两门课程。

（2）作业安排方面：

多线程电梯很显然是最难的一次作业了，对于设计的难度且不提，对于线程安全的要求显然是最高的。安排在刚刚接触多线程的那一星期有一点难了。当然正值清明节假期时间比其他的一星期是要多一点。

至于IFTTT我觉得是没什么必要的一次作业了。这次作业的目标说是“训练同学们针对线程安全问题，如何平衡线程访问控制和共享对象之间的矛盾”。这一次作业主要自学了一段时间的文件系统，难度主要在文件系统和监控的实现上。而我在实际编写过程中耗时最多的是实现，甚至并没有太多关注线程安全。而在测试时发现哪怕对于同一个文件的操作，只要是SafeFile类文件的也不太会因为共享对象而出现线程安全问题。我认为这一次作业的难点其实是理解指导书，自学文件系统和实现文件监控，甚至没有怎么涉及到线程安全问题。

而多线程电梯就不一样了。请求不断的输入，请求队列不断地扫描，还要根据电梯的各种状态来进行判断和分配。请求队列的共享十分明显，而且对于线程安全的要求相当高，如果哪里同步出了一点问题都会有意想不到的情况发生。（指导书上居然对“线程安全”四个字只字不提）

所以我认为可以删除IFTTT这一次作业，用两个星期来编写三线程电梯。事实上我感觉IFTTT这次作业意义真的不是很大，如果用两个星期来编写电梯，如果真的能实现好这个电梯，对于线程安全的理解肯定不会差的。

接下来是对于指导书的一点吐槽。

希望下一届指导书能够更加明确，意思通顺。老师的初衷是希望我们能跟助教讨论共同完成指导书内容，本意是好的。但是我还是希望能在指导书中加入内容时审查一遍。

例如第七次指导书中：

可能是我的语文不好，读了5遍还是没能把“往往通过数字来表达的能力”这句读通顺。

最后是互测这一部分

（1）对于乱扣分，恶意扣分的人应该有惩处机制。如果仅仅依靠申诉或者仲裁，乱扣分现象是不会停止的。应该通过制度来约束。而且乱扣分现象少了之后，助教处理的申诉和仲裁也会减少。

（2）取消JSF的互测。很多学生连JSF的内容自己写都不一定能写好，却有资格去扣别人的JSF。而且这个东西主观性过于强，如果按照自己的理解来扣很容易扣许多。建议改为助教统一评判。

（3）互测出现的bug真的得到有效解决了吗？现阶段只测出别人的bug，而省略了debug这一步。

---

结语

一学期下来oo这门课总算到了尾声。

为这门课花了心思的老师辛苦了！

为我们答疑解惑的助教辛苦了！

能把这门课通过的同学（包括我自己）也辛苦了！

祝北航面向对象课程越来越完备越来越好。能被越来越少的学生喷。

总而言之这一学期的oo之旅就到此为止了。