oo第四次作业

一、测试与正确性论证效果差异

　　虽然测试能够非常直观地找到bug，但是测试的问题在于无法保证程序没有bug，只能保证程序没有被发现的bug。要想证明一段程序没有错误，必然需要测试之外的其它方法来进行证明：即正确性论证。

　　程序正确性论证是从代码出发进行理论推理来证明代码没有bug。它的优点是全面且能够证明代码正确，缺点则是可能存在没有被考虑到的地方。毕竟，如果光凭推理就能找到所有bug的话就没有调试存在的必要了。某种程度上可以将测试和正确性论证看成是“实践可能”和“理论可能”。

 

二、OCL语言

　　OCL语言是一种约束语言和查询语言，可以用来描述四种约束：不变量、前置条件、后置条件和监护条件。

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

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

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

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

　　OCL和JSF相似之处在于都有前置条件、后置条件和不变量的描述。不同在于OCL需要有一个明确的上下文，而且多了监护规则。

 

三、第十四次作业UML

　　（1）类图：

　　（2）时序图

　　（3）状态图

四、总结

　　（1）阐述四个单元模块知识点之间的关系

　　我认为四个单元之间的关系是一个循序渐进的过程。第一单元先从java的基础开始，到第二单元的多线程有关。第三单元开始讲设计相关的内容，开始为程序添加规格，第四单元则增加了测试和正确性论证。

　　（2）梳理自己所设计实现的程序，分析自己在设计、测试和质量上的进步

　　个人认为我通过学习这门课最大的进步在于了解了面向对象的思想，并且通过不断的完成工程提高了一些基础的编写代码能力（比如我现在终于意识到了将一个长函数/方法划分成多个函数/方法的好处（求不嘲讽））。

　　（3）阐述自己对工程化开发的理解

　　我认为工程化开发就是方便开发者操作，通过增加一些看似冗余的步骤来实现一个可执行的最优解，方便多个环节之间的沟通和工程的维护。通过规格和需求分析来明确工程的要求和具体实现内容，再通过工程化的编程方式以方便多开发者合作以及后续维护。

　　（4）AT LONG LAST

　　　　1.评测机制并不鼓励面向对象编程，或者说评测机制根本不鼓励好的编程方式。举例而言，在后几次作业中JSF的分数是依照出错次数来扣的，也就是说我如果写一个几千行的main方法实现了工程要求，那么我在JSF这一项上最多只会被扣一两分；但倘若我将其写作一个稍微看得过去的工程，我被扣分的风险就会大大增加。课程组当然可以用“学到了知识”这个说法来安慰代码写得好但扣分反而更多的同学，但是分数和知识不一样，它是看得见摸得到的。有没有学到知识是学生的问题，评测机制能否鼓励学生学到知识则是课程组的问题。

　　　　2.互评机制的运气成分太大。我认为这部分不需要我来解释。希望课程组能减少互测得分在成绩中所占的比重。

　　　　3.朝令夕改。倘若没有因为指导书需求模糊而过不了公测或互测的现象，那指导书就是一天改十次我们都不会有意见。问题就是指导书里的需求经常十分模糊，十个人读可能就会产生三种不同的实现方法；可偏偏这三种实现方法里只有一种能得分。希望课程组能减少改需求和解释指导书的次数（并不是说有问题晾在一边，而是从一开始就不要有问题），要么就推迟ddl给学生更多的时间来消化新需求。

　　　　4.课程组效率过于低下。这部分我只有一个请求：请在课程出成绩之前把我从第九次作业开始的仲裁请求都处理了，我觉得我的成绩还能抢救一下。大量的仲裁和关于指导书的疑问难以及时得到处理。希望课程组能够多花点钱，多雇几个助教或是让同等数量的助教工作效率提高，再或者请老师们亲自下来拯救oo课程组的效率问题，顺便感受一下同学们对这门课的“热爱”。不过我更希望课程组考虑一下LEAD, DON'T MICROMANAGE.

　　　　5.再次请求课程组的老师们平时多出来面对同学们。把助教扔出去接受同学们对课程的不满，发动群众斗群众这种行为实在是令人不悦。

　　上面这些就是我对oo的意见。至于怎么实现，我认为这是课程组的责任了。虽然我不会做饭，但我至少知道做好的饭好不好吃。