面向对象UML的初步了解
面向对象课程终于到达了终点，最后一次博客作业啦~~。
一、单元测试与正确性论证
在这一阶段作业中，我们尝试了使用JUnit进行单元测试，也尝试了基于分支划分的程序正确性论证。两者都是为了保证程序的正确性，但是方式却截然不同：单元测试就是将一个个方法进行黑盒测试；正确性论证则是类似于代码走查，通过分析、陈述程序的每一个分支，来证明代码的正确性。
从第一感觉上说，我还是更偏爱单元测试一些，毕竟之前写的代码比较短，习惯了直接输入样例来分析代码bug的方式；但是课上老师一直强调，工作中代码量更大的话，很多情况下就不能通过测试来找bug，而更多可能需要靠代码走查的形式，一行一行地读代码，静态地分析程序中的错误。这几次作业实践了这两种方式之后，对于这两种方式有了更多的一些理解。
单元测试实际进行起来并没有那么愉快。不难想到，要想达到100%的语句覆盖率，85%的分支覆盖率，其实根本就不能是黑箱测试了。实际上还是要了解代码，才能构造出覆盖面足够大的测试情景与样例；而为了达到分支覆盖率的要求，每一个分支都要有相应的测试样例，这样所需的样例又会很多。在自己进行测试的时候，其实就是在对着源代码写测试代码，其实还是挺费神的。这时就理解了老师说的话，对于代码量很大的工程，想要构造出有效的测试情景与样例，本来就是很费力的事情。但是单元测试当然也有自己的好处。自己的感觉是，单元测试毕竟是只关注结果的测试，当测试设计得合适时，测试结果就说明了问题，可以快速定位到哪个方法，哪条语句。
与单元测试对应的，正确性论证给我的感觉总是不那么可靠，尤其是像这次作业一样，自己写的代码自己进行正确性论证，这样可能第一次犯得逻辑错误，进行正确性论证时也会再犯，毕竟不像单元测试那样有一个明确的结果。正确性论证确实是省去了构造测试情景、编写测试代码的麻烦，而且有了JSF对照之后，可以直接分析代码的输入输出是否与JSF的描述相符，也就是以方法为单位进行论证。正确性论证那次作业确实是挺烦人的，每个方法都要写那么一大串。但确实不可否认，静态分析代码的能力也是我们必须的。
二、OCL与JSF
由于没有怎么使用过OCL，所以可能对于OCL的理解不会那么到位。OCL（Object Constraint Language），对象约束语言，是一种指示用户建模系统中的限制方式，可以更好地定义对象的行为，并未任何类元指定约束。与JSF一样，OCL是一种形式语言，通过附加上的条件和限制来变现对该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在操作和方法上的前置条件和后置条件等。JSF与OCL都是为了准确表达对象的行为，而且其语法都避免了二义性。
两者的差别也有很多。OCL为了能够更方便，更广泛地被应用，所以并没有采取纯粹二阶逻辑的符号语言，而是提供了一种介于自然语言与逻辑语言之间的新的表述方法。OCL为此提供了很多关键字、基本数据类型以及容器。而JSF在表述上完全采用二阶逻辑来表述，这保证了JSF的无歧义性，但是会给编写者以及阅读者带来很大的麻烦。
三、单电梯系统UML表述
单电梯系统类图
单电梯系统时序图
单电梯系统调度器状态图
四、学期总结
(1) 单元知识点总结
本学期已经写过了三次博客作业了，以博客作业为节点划分OO课程可以分成四个阶段。之前的三次博客作业分别叫做《Java初体验》、《多线程初体验》、《程序设计规格化的反思与探究》，还有就是这次的《面向对象UML的初步了解》（不太敢叫“初体验”了，并没有很深的体验，QAQ）。
这三次博客名字就很鲜明地反映了这四个阶段的学习内容。第一个阶段主要是熟悉java这门语言，以及面向对象的一些概念；第二个阶段就是多线程了，这也是OO作业最难的地方，学习了多线程的机制，以及java对多线程的一些支持方式；第三个阶段主要学习了代码规格化设计，主要通过大量的JSF标注，体验了一下代码规格化的实践意义；第四个阶段主要是和代码的正确性分析有关的内容，单元测试以及正确性论证等内容。
想一下这四个阶段的话，很明显可以看到其渐进渐深的课程设置。首先是对于java语言特性，以及面向对象概念的了解，这些是写代码的基础；然后接触多线程，这个一方面是学习多线程的相关知识，一方面是锻炼了一下写复杂系统的能力；能够写出一些工程之后，就以这些代码为基础，优化自己的设计以代码规格化的要求；最后，就要求保证代码完备的正确性。
(2) 个人总结
从第一次简单的多项式加减，到最后的出租车系统，本学习的OO课程确实有一定代码量。记得最开始的几次作业，有时候会为了”极致的抽象“，或者为了体现java的某些特性，进行了很多奇怪的设计，就感觉代码越写越让人感觉难受。后来写多了之后，才发现有些之前认为理所应当的概念，可能并不是优秀的设计，更多的时候，简明、不依赖语言特性的设计实现起来才更加舒服。对了，这学期还得到了一个教训，就是动手写代码之前，一定要先规划好设计方案。有好几次作业都是写着写着发现，很难继续顺着写下去了，不得不推倒重来。
关于测试，在第一次博客中就提到了。从上学期机组的经验中就学到了，做测试不能单纯以量取胜，而是应该具体的分析测试情景，分类设计测试样例。
(3) 工程化开发
工程化开发，听起来和计算机组成一脉相承。回忆一下，计算机组成的工程化方法具体体现就是通过借助详尽的表格来分析规划系统设计，从而保证系统的正确性。OO训练的工程化开发可能核心思想都是一样的。就我个人的第一感觉而言，工程化开发的一个关键词是“详尽”。
尤其是在OO课程规格化设计与正确性论证这部分最能体现这个词。JSF要求以方法为单位，正确性论证要求每个分支都要覆盖，带来了很大的工作量，这个也应该有自己的意义。“详尽”意味着考虑问题的完备性，也就意味着系统的正确性有一定的保证。
(4) 对课程想说的
虽然做作业的时候，有不少吐槽，但真的想要提出什么建设性的意见，还是挺麻烦的。有很多不是很好的设置，但是又想不到更好的来替代。毕竟老师做出的课设都有自己的考虑。
唯一想提的一些建议，可能就是感觉OO课上对于面向对象的一些核心概念训练的不够。像多态等方面，在我们的作业中，都是通过一个毫无意义的附加条件来训练的。这也是这门课让人感觉不像是在教OO的原因。还有一点就是对于Gitlab上issue的态度。我自己觉得，写作业应当完全根据指导书上来，而不应该把issue上的问答当作标准的一部分。对于指导书上有歧义的部分，可以通过发布追加的指导书补充说明，没有补充的部分，完全由readme说明。总之，个人感觉吧，issue破坏了开发者与需求者的交互规则。
最后，还是十分感谢OO课程组的辛勤劳动以及任劳任怨啦。比心。