oo最后阶段总结

 

oo最后一次总结~

一、测试&正确性论证

    测试是从代码的执行结果的层面去考量代码的正确性，而正确性论证是从逻辑层面来检测方法使用的正确性。测试不关注于每个方法执行的逻辑正确性，更注重结果的正确性，正确性论证恰恰相反，这两点（逻辑正确性和结果正确性）在大多数时候是等同的，但是并不完全相等。

    测试的优点：能够直观的衡量代码的执行结果，从最终结果的角度修改代码，以达到代码完善性。缺点：需要构造大量测试集以涵盖所有的测试点，有时候很多方法叠加在一起，经过排列组合会有很多种情况需要考虑，这些情况都需要构造不同的测试集，较为麻烦，且极易出现疏漏。

    正确性论证的优点：能够从方法的逻辑角度细致的验证每个方法的正确性，再上升到整个类的正确性，能够确保整个流程的正确性。缺点：通过自然语言对其进行逻辑推理论证，篇幅过大，难免也会出现错误，较难确保逻辑推理的严谨性。

二、OCL语言&JSF规格

    OCL语言：OCL语言即对象约束语言（Object Constraint Language)，它是一种施加在指定的模型元素上的约束语言。OCL表达式以附加在模型元素上的条件和限制来表现该对象的约束，其中包括附加在模型元素上的不变量或约束的表达式，附加在方法上的前置条件和后置条件等。 对象约束语言是一种形式化语言，它主要用于表示UML模型中施加于模型上的约束。OCL具有如下特点：
    1、OCL是一种精确的，无二义性的语言
    2、OCL是一种规范说明性语言，所有有关实现的问题都不能用OCL来表达
    3、OCL是一种纯表达式语言，它是具有没有任何副作用的申明性语言。
    4、OCL是一种类型化语言，即OCL中的每一个表达式都是具有类型的。
    5、OCL不是一种程序设计语言，不能用OCL编写程序逻辑和控制流程。

    OCL预定义的标准类型定义了一组基本类型和集合类型。OCL的基本类型有"Boolean"、"Integer"、"Real"、"String"等。集合类型包括"Collection"、"Set"、"Bag"、"Sequence"等。这些标准型是OCL表达式的组成部分。

OCL表达式对于一个OCL类型求值。OCL表达式有以下特点：
    1、OCL表达式可以附加在模型元素上，模型元素的所有实例都应该满足表达式的条件。
    2、OCL表达式可以附加在操作上。
    3、OCL表达式可以指定附加在模型元素上的监护条件。
    4、OCL表达式的计算顺序是从左到右。
    5、OCL表达式既可以使用基本类型又可以使用集合类型。

   与JSF的相似：都是对象约束语言，都有前置条件（OCL里的pre，JSF里的REQUIRES）和后置条件（OCL里的post，JSF里的EFFECTS），都是无二义性的规范说明性语言，不是程序设计语言。

   与JSF的不同：OCL具有严谨的语法结构和标准表达式，而JSF语言较放松，有时甚至可以使用自然语言进行描述。

三、基于单电梯系统的设计

类图：

时序图：

 

状态图：

 

 四、学期总结

4.1 四个阶段知识点关系

    四个阶段象征着面向对象课程学习的四个阶段，我们从代码的基本思想开始，渐渐学习语法，并在语法的基础之上更加逐步深入的理解面向对象思想。

    第一阶段是我们大多数人刚接触oo的阶段，也可以说是最难熬的阶段，不仅要自己自学语法，完成大量的程序作业，还要一次次的响应指导书的实时更新，每周都过的很充（jian）实（nan）。

    第二阶段到达了多线程阶段，对于我们很多人来说，又是一次难度上的飞跃，各种锁加的五花八门，结果BUG还是被报的触不及防。

   第三阶段似乎是放松下来了，其实对于一部分来说并不是，规格的到来不仅为我们带来大量的程序修改，还为我们带来了大量的BUG，写好JSF需要我们梳理整个方法的逻辑关系，并且注意书写规范。

   第四阶段就是测试阶段了，针对第三次电梯作业进行测试和正确性论证，测试和正确性论证能够让我们找到自己曾经在方法上的疏漏和结果上的错误，从结果和逻辑的角度衡量代码的正确性。

   这四个阶段衔接自然，从语法到多线程到规格到测试，逐步深入，为我们构建了较完善的面向对象知识体系。

4.2 自己的进步

    通过梳理自己所设计实现的程序，有以下进步：

设计上：之前设计时想到哪写到哪，写的时候思路一团糟，写完之后代码一团糟，花费了大量时间在debug上，而后来自己拿到指导书之后，会先静下心来慢慢分析，画出设计图，流程图等等，使思路更加清晰，设计上更加简洁明了。

测试上：之前测试时是随便测，也不会记录自己的测试用例，测完即扔，这样就会造成重复测试和测试疏漏，既浪费时间又容易疏漏。后来测试的时候就会按照分支树构造测试样例，并把测试样例记录下来，一个个测试，不会造成测试重复，也可以慢慢的扩充完善自己的测试用例，尽量避免测试疏漏。

质量上：以前的程序每个方法都是又臭又长，现在都是尽量注意代码的长度适宜，书写上也更注重整齐，更加美观，代码可读性增强。

4.3 对工程化开发的理解

    对于工程化开发，我的理解就是每个类，每个方法分工明确，简单明了，善于利用接口。

    工程化开发更需要完善自己的设计，让别人也能看懂你的代码，还需要完善自己的规格，规范化的代码有利于大家共同完成一个项目。

4.4 对课程的希望&建议

    希望每个学过oo这门课的人都能从中学到一些，也许并不只是面向对象思想，代码的灵活使用，课程的打击和互测的毫无人性有时也能让人看清一些事情，都是我们从这门上学到的宝贵财富。

   建议老师上课的时候多于每次的作业相结合，不要一味的讲述太过抽象化的知识。

   建议实验课的介绍再清楚明白一些，实验课的指导书再目的明确一些。

   建议合理安排作业开始-截止时间，让学生也有学习其他科目的时间。

 

转载于:https://www.cnblogs.com/luluzhang/p/9224378.html