OO第四次博客作业

　　　　　　　　　　　　　　　　　　　　OO第四次博客作业
一． 单元测试与正确性论证
　　在最后一阶段的作业中，我们使用Junit进行单元测试，并且通过划分分支来论证自己程序的正确性，相较于以前盲目的黑箱测试，这两种方式更加科学，覆盖面也更加广泛，能找到黑箱测试难以找到的问题。
　　两种测试方法其实都是通过对每一个类的方法的每一个分支进行测试，通过程序执行情况和预期情况的比较来判断方法的正误，相对比而言，单元测试注重每一个分支的正确性，更加细节一点；而正确性论证则是应对不同的输入，从大的方向上说明方法行为的正确性，更加具有全局性。
单元测试的细节性决定了进行单元测试是一个及其耗费精力的工作，要做到分支的100%覆盖，我们需要对代码的每一个分支有详尽的了解，对于以前写过的代码，要反复阅读理解全部含义，这样才能做到不遗漏，每一组测试样例的构造都要下一番辛苦来保证所有的节点都能通过。除此以外，测试时有时还会遇到某一个分支永远无法覆盖的“有趣”现象，而这个分支的情况自己也很难判断是否存在。。。。。。我们在写代码时遇到某一个分支难以判断是否会发生的时候，往往会做一个比较保险的决定——假设它会发生然后处理掉，于是测试的时候你就不得不绞尽脑汁把这个奇葩的情况想出来。同时，单元测试的细节性往往会让人忘记一些情形，比如电梯指令我们直接输入一个RUN，首先它是合法指令，所以合法判断是通过的；但是在后边相应的处理函数中，我们默认输入的都是合法指令，而第一条指令规定必须是(FR,1,UP,0)，往往容易忘记直接输入RUN的情况，出现错误可能就直接crash了。这也是细节测试带来的弊端——忘记程序的整体性。
　　正确性论证相较来说更加有全局性，对于方法的行为能有一个很好的预料，因此在整个论证过程中，方法与方法之间的配合也能很周全的考虑到，这样的情况下我们就能一定程度保证全局的正确性，而且相较于细节性的单元测试来说，正确性论证能省下一些构造样例的麻烦，但也同时可能会忽略一些细节性的错误。
二． OCL与JSF
　　OCL（Object Constraint Language），对象约束语言，是一种指示用户建模系统中的限制方式，可以更好地定义对象的行为，并为任何类元指定约束。
　　OCL与JSF一样都是形式化语言，具有无二义性的特点，但是它的语言介于自然语言与逻辑语言，所以更加容易理解。OCL还提供了很多的关键字、基本数据类型和容器。
三． UML
（1） 类图

（2） 时序图

（3） 状态图

四． 学期总结
（1） 个人总结
　　这十五次作业恰好以四次博客作业为划分，大致可以分为《Java从入门到懵逼》、《多线程从懵逼到折磨》、《规格化设计从折磨到放弃》、《单元测试正确性论证从放弃到解脱》（小皮一下）。。。。。。四阶段可以说很贴切的让我们体会到作为程序员要和语言斗智斗勇，要和算法斗智斗勇，要和需求斗智斗勇还要和测试斗智斗勇。不过也正是在这个斗智斗勇的过程中，我逐渐掌握了java这门语言的基本知识，多线程的运行规则以及算法，还有作为工程化开发时需要的规格和测试。。。。。。种种技能汇聚一起其实可以总结为一个程序员的应该具备的基本素养。
（2） 工程化开发
　　工程化开发给我的第一个印象就是——规范。因为当需要合作的时候，规范能保证彼此之间能听懂彼此的话，能在同一套规范中了解同伴的意思，这是开发高效性的一个保证，只有在这样的保证下，才能让大家七手八脚“拼凑”出来的程序正常的跑起来；工程化开发给我的第二个印象是——详细，它与一般的编程作业或者竞赛时写的代码有很大差别，因为你不知道你面对什么样的用户，所以他会用尽各种奇怪的输入来测试你的程序，要保证程序的鲁棒性，就要保证每一个方法，在每一种输入或者每一种情况下都有可以预见性的行为，因此就需要专门为一些非法的输入考虑相应的处理方式，对每一个方法的规格就要详尽到每一个分支。
（3） 一点点建议
　　OO已接近结束，就把我们做作业过程中遇到的问题反映一下吧。
　　首先是指导书的问题，我对比上届感觉指导书本身没有特别大的变化，也就是说作业基本没有太大变化，所以是否可以推导出大家问的问题也大致相同呢。所以我希望在给下一届的指导书中，参考我们这届issue的一些问题，把相应的不甚明了的话语尽可能描述明白。
　　然后。。。。。。没了，大苦大难我也结束了，那就让学弟们好好享受OO的美好吧（坏笑）。

　　最后还是要感谢各位老师和助教，若干次测试，我问了不知多少蠢问题。。。。。。这百多天，也曾欣喜也曾生气，但最终还是会成为在沙河一段美好的回忆吧。