OO第四次总结

1、测试与正确性论证

    程序的测试分为大小不一样的几个阶段，咱们在这个阶段的做业中进行的是基于JUnit测试框架的单元测试。

    单元测试是指对程序中最小的可测试单元进行测试。咱们测试的单元是方法。单元测试的特色使是从结果出发，寻找代码的漏洞。一个全面的单元测试可以对覆盖到方法执行过程当中遇到的全部状况，也就是覆盖全部分支条件。经过单元测试则说明该方法可以彻底符合指望的规格。所以，单元测试的优势是可以确保一个方法的正确性。然而构造一个完美覆盖的单元测试很难，尤为是当原方法的分支条件不少的时候。编写单元测试一般要花费比编写原方法更多的时间。

    正确性论证也是证实方法是否符合指望规格的手段。与单元测试从结果出发不一样，正确性论证是从代码逻辑出发，论证方法如何完成规格。正确性论证更像是数学中的证实题，须要严谨严密的逻辑思惟。完成正确性论证的前提是对代码逻辑彻底掌握。

    正确性论证可以对全部分支进行论证，较单元测试来讲更容易达到彻底覆盖，然而正确性论证过程较为复杂，相比单元测试"粗暴"地判断对错来讲更难保证论证结果的正确性。

    因为两者具备各有优劣，能够互相补充，两者兼用可以更充分的保证代码的正确性。

2、OCL语言

    OCL(object constraint language)语言即对象约束语言。它是一种用于约束指定模型的定义，形式化的没有二义性的语言。

    OCL拥有本身的语法体系，有数据类型和运算符，更优高级数据类型例如群、集合、袋和序列。在对象约束方面，OCL表达式包括不变量、前置条件和后置条件等。

    OCL同咱们学习的JSF用途相同，都是用于描述对象的约束规范的形式化语言。用两者描述的约束都是没有二义性的。不一样的是，OCL有一套比JSF更加完备高级的语法结构，而JSF只有二阶逻辑结构，没有高级的分支语句等，也没有对数据类型的描述。

3、单电梯系统模型

UML类图：

UML顺序图：

UML状态图：

4、学期总结

知识点梳理

    课程分为四个模块。

    第一个模块主要熟悉面向对象编程方法以及对象机制。这个模块是对java语言和面向对象的初步接触。

    第二个模块是多线程编程，以及线程安全问题。这个模块训练了多线程的思惟。

    第三个模块是规格设计。这个模块咱们将代码规范化，使代码更加规格化、模块化。

    第四个模块是基于规格的测试与论证。这个模块学习了更加严谨规范的测试方式。

    能够说这四个模块之间就是四层积木的关系，层层递进，让咱们从零开始体会面向对象程序从构思、实现到测试的完整过程，并在这个过程当中逐渐强化面向对象的编程思想。

进步总结

    在此以前彻底没有接触过面向对象有关知识，编程还停留在一个程序几个方法的过程式编程中。在第一次多项式的编程中，我仅仅使用了两个对象，且没有作到对象的封装，这两个对象之间相互调用，逻辑十分混乱；第三次ALS电梯在重构以前更是在调度类中一个方法写了两百多行，彻底没有作到方法的抽象，致使程序十分臃肿，不少BUG发现了却没法定位修复；

    从多线程电梯开始决定优化代码结构，至此开始，之后的做业中慢慢造成了面向对象的基本思想和思路框架，代码结构也在一次次训练中获得改善。

    总的来讲进步很是明显。经过这门课程的高强度训练，如今可以比较完整的从问题中抽象出对象并进行模块化的编程，代码的规范程度也有很大提升。但仍有不少不足之处，例如对接口的理解感受不是很深入。

对工程化开发理解

    工程化即系统化、模块化、规范化的过程。指将具备必定规模数量的单个系统或功能部件，按照必定的规范，组合成一个模块鲜明、系统性强的总体。工程化开发的关键是封装，将各类资源封装成一个个模块以后，咱们没必要再关心该封装下的具体细节，只须要将这些模块组装成一个总体就可以造成一个完整的工程。

    面向对象的设计原则与工程化开发中模块化的要求不谋而合，然而面向对象设计缺少清晰的层次关系，面对复杂的操做过程时实现效果不佳，涉及多个对象之间共同协做时也会显得不那么灵活，这是面相对象设计的一个不足之处。

    规格设计是工程化开发最重要的一环。良好的规格约束可以便于团队合做与相互理解，实现更好的协做关系。

对课程的指望与建议

1. 尽量在最初介绍更多的关于java语言的知识，或者哪怕提供更多资料也能够。
2. 但愿可以有更多更完整的程序实例和讲解，现有的ppt上的例子对于做业来讲彻底不是一个层次上的，致使咱们拿到做业的时候感受难度的跳跃很大。特别是多线程部分，我想多一点复杂的多线程程序例子对于咱们理解多线程操做来讲更有帮助。
3. 关于互测部分，特别是规格互测的时候，恶意乱报规格BUG的现象比较严重，我认为在报告规格BUG部分的机制欠妥。
4. 仍是互测，我提出一个关于issue的问题。对于指导书没有规定的内容，不少彻底能够自行定义而不影响整个程序的正确性的问题，因为助教一句话咱们就只能根据助教的理解方式修改程序。有时候这种修改须要花费不少精力，甚至更改整个代码的结构；甚至有一次因为助教理解错误形成我改过去又改了回来。。。我认为这些边角部分的问题不影响教学核心，能够给予咱们充分的自由。不然这些东西会在无形之中增长咱们的负担，自己课下任务量就很大，这些本来很小的问题可能会打击对课程的热情和积极性。