OO第四次博客总结
程序的正确性论证是在用户提出需求后，进行规格撰写后，论证程序是否符合规格的过程。因为规格往往是布尔型或自然语言，对程序员来说并不如代码和测试数据直观，且工作量巨大。但相应的，好处是对代码整体进行了具体的剖析，在规格符合需求的前提下，能够发现程序与规格间的逻辑上的不符。
测试则需要通过输入特定数据等方式，检查程序是否和预期相同，因为测试不可能穷举，导致了不穷举的测试不可能验证程序是完全正确的，只能验证程序在测试时没有发生错误，尽管如此，测试依然是一种高效的检查程序的方法，通过输入数据或复现现场，直观的发现代码的问题，进而在代码中找到问题的来源并修正。
二. OCL语言和JSF规格的对比
OCL语言的全称是Object Contraint Language，即对象约束语言，是UML中约束定义的语言。对OCL的讲解，可以参考这里。
与JSF规格相比，都有不变式和数学逻辑表达式，但JSF多了MODIFIES，而OCL的语法遵循巴斯科范式，并且有集合等高级数据结构。
三. 对ALS单电梯系统的图表示
UML类图：
UML顺序图：
UML状态图：
四. 总结
oo第一单元是基本的设计思想，包括类的抽象，私有，接口和继承等等，是后续部分的奠基石。第二单元是多线程的数据管理和冲突解决，引入了多线程的编程方法。第三单元是规格化设计，为第四章论证铺垫。第四单元是单元测试和正确性论证，根据规格对每个方法进行测试和覆盖率检查，对每个类进行正确性论证。
一个学期的数次编程联系中，提高最大的应该是设计。以前在编写一个程序，看中的是算法，但当程序有了一定规模和多次的增补，没有一个好的设计很可能导致之后的新功能收到影响，甚至不得不重构。以出租车为例，当初为了方便，采用了单线程控制100辆出租车来实现，但当流量的定义被改变和加入了红绿灯后，这样的设计没有办法让所有车每500ms一起移动，即使记录下一次最先移动的车，当程序运行时间足够长，也会变成每1ms遍历100辆车1次的情况，当初的设计反而让程序的效率降低。同样在第14次作业中，因为要对ALS单电梯系统的方法添加JSF规格说明，由于当初刚刚接触java，代码的调度器部分的方法长达200行，难以写清不变式，只得重构。重构后发现，所有方法都在40行一下，更加清晰。
测试的水平却不想设计一样平稳上升，而是先上升后下降，主要原因在于后期作业的设计占了更多的时间，完成代码后往往已经没有足够的时间进行测试。但还是要说的是，对于单线程、统一输入格式的程序，完全可以将两份作业进行自动化的随机产生输入、对比输出，从而完成测试，这一方法也用在了ALS单线程电梯中。
此外，互评机制确实让很多人第一次见识了工程化的代码是什么样的，一切源于在第一次电梯作业中，我有幸拿到了某个已经开始在公司实习的dalao的代码，简单的程序，大多数人用了5个类或更少来完成程序，这份代码却包括了23个类，其中包括了exceptions、interfaces、models、helpers、configs等部分，这份代码也被我分享给了很多人，确实对初次接触稍复杂的程序时是一种震撼。
但是确实很多人在完成了所有的编程作业后，也还是不知道究竟什么样的设计是“很好”的设计，不知道什么样的代码是好的，不妨在每次测评结束后选出一份给大家借鉴的代码，并附上程序的结构说明。此外对于一些问题，或许已经在前期讲过，但是当时我们对java和oo的认识非常有限，导致到了后期依然不知道该怎么解决，比如属性已经全部为private，也明确说明不应每一个private都有get和set，那么如何减少set和get函数数量？即究竟如何高内聚低耦合？以及对诸如请求队列这样的类，究竟是该设置为public static的全局变量还是应该繁琐的引用？相信很多人在oo结束后仍有这种感觉：一个学期的oo，很确定自己学到的是一些java的语法、一种多线程编程的方法、JSF规格的撰写、程序的测试和设计上的锻炼，却对什么样的程序是好的程序仍然觉得迷茫，也可能是课程组故意为之吧，毕竟计算机类的专业课，基本职责就该是让学生了解有这样一个东西，更进一步的内容还需要自己去深入。
最后感谢oo老师和助教们一学期的辛苦，给我们答疑解惑，一起熬夜~你问我滋不滋持oo滋不滋持互测，我当然是滋持的。
