接着继续(OO博客第四弹)

、测试与JSF正确性论证

　　测试和JSF正确性论证是对一个程序进行检验的两种方式。测试是来的最直接的，输入合法的输入给出正确的提示，输入非法的输入给出错误信息反馈，直接就能很容易的了解程序的运行状况。可是，每次测试只是在程序涉及的整个问题空间取一个元素进行测试，一次测试只能确保程序对于测试中的样例和同类样例是正确的，并不能确保全局正确性。而为了追求全局覆盖性，就须要大规模的测试样例轰炸了，可是这时测试的最致命缺陷就出现了，一是如何构造如此大量且属于不一样类别的测试样例，二是如何确保构造的测试样例可以覆盖全部的语句和分支，三是对于一些复杂的，可靠性要求高的程序，这样的测试级别还不够，还须要更高级别的组合测试，例如，如今有两个分支1和2，分支1有a,b两种状况，分支2有c,d两种状况，单纯的分支测试只会保证a,b,c,d都被执行过，但对其中的组合状况没有考虑，而这正是实际问题中bug容易发生的地方，多重分支的叠加最后达到一个编程人员在设计很难预料到的情形，从而发生错误，而组合测试就须要将可能发生的组合：ac,ad,bc,bd所有测试一遍，而随着问题规模的扩大，测试样例的数目将呈指数级上升，这将带来很是大的测试难度。

　　正确性论证是一个上限很高的方法，若是可以完整且正确地对一个程序完成论证，那么这样分析事后的程序的可靠性几乎是100%，可以概括覆盖整个问题空间。可是，正确性论证对于使用者的要求很高，一些复杂的论证须要很高的数学技巧，论证多分支状况时也很难保证彻底不出错误不发生遗漏，这须要使用者对于该程序有很是高的熟悉度和强大的全局驾驭能力。此外，正确性论证须要的步骤不少，须要严格的证实，且主要是人来完成，所以须要大量的时间。同时，面对多分支组合问题，论证时也将面对指数级增加的划分数，这致使工做量会变得更大，很是消耗时间。

　　所以，我认为更合理的方式是结合两种方法，即便用正确性论证的思想来进行划分，对于每个划分的状况构造通用性高的测试样例进行测试，最终获得具备高覆盖率的测试集。同时，应该作到测试与设计并行，在设计时也要适当考虑测试因素，对每一个类和方法作更多的规约和异常检测，减少问题空间的维度，为测试减少压力。

 

2、OCL语言 VS JSF

　　OCL语言介绍：OCL（Object Constraint Language）语言，即对象约束语言，一般与UML一块儿使用，用来表达对于UML图的约束，而一个约束就是对一个（或部分）面向对象模型或者系统的一个或者一些值的限制。

　　两者相同点：

　　（1）都是声明式语言（Declarative），即表达式仅仅描述了应该去作"什么"，而不是应该"怎样"去作。由于OCL是宣言式语言，因此UML中的表达式被提高到了纯建模的领域，而没必要理会实现的细节和实现的语言。JSF也是说明了方法执行先后产生的影响，而不描述具体是如何产生影响的。

　　（2）都是基于数学（集合论和数理逻辑），取数学符号和天然语言的折中方案，使用逻辑表达式来描述约束内容，可是具体的元素可使用天然语言说明。

　　（3）都有不变式，前置条件，后置条件这样的语法。

　　不一样点：

　　（1）OCL是强类型语言，任何表达式的值都是属于一个类型的。这个类型能够是预约义的标准类型例如Boolean或者Integer，也能够是UML图中的元素例如对象。也能够是这些元素组成的集合，例如对象的集合、包、有序集合等等。JSF中对此没有很严格的规定和要求。

　　（2）OCL规定了不少具体的操做符，数据类型和表达式语法，而JSF中更着重于必定要按照逻辑运算规则进行推理，更加要求符合数理逻辑中的规则，而对于操做符没有很严格的要求。

　　（3）OCL语言能够对类，类的属性和操做等等任意的进行约束，而JSF仅针对类和方法。

　　（4）OCL一般结合UML类图使用，加之其支持对于各类上下文的约束，同时还要保证没有二义性，因为须要支持这么多的功能，因此它是一门“重型”语言，不像JSF是轻量化的语言。

 

3、第十四次做业相关UML图

　UML类图

　　顶层package

　　package：helper

　　

 　　package：interface

　　package：model

　　package：model中Elevator类

　　

　　package：model中QuestQueue类

　　package：model中SchedulerAI类

　　　　

　　顺序图

 

 

4、总结

4.1本学期OO的四个模块内容

• （1） Java与对象（java速成+面向对象程序设计入门）
• （2） 并发与安全（多线程程序设计入门）
• （3） 抽象与规格（规格化和设计方法学入门）
• （4） 测试与论证（单元测试+JSF论证）

　　首先，四个模块是按部就班，将整个工程化设计的内容划分红几大部分，而后分部分进行学习和训练。从你们最熟悉的程序语言开始，一步步深刻到面向对象程序设计思想，多线程程序设计方法，直到工程设计方法，总体相似于一个自底向上的过程。可是呢，我的观点，在讲课的时候当然分红四个模块逻辑清晰，可是实际应用中四个模块的方方面面都是要涉及的，是否能够设计一些单元之间内容交互的做业，或者是综合做业，这样更具备综合性的东西才会更加让人感觉到工程化方法的重要性，不然每次只针对一个点会让一些人可能产生应付该次做业的心态，固然这样的综合做业时间周期能够加长，专项做业中穿插综合做业，我以为是更有意义的选择。

4.2我的收获与感悟

　　做为一个从大学开始接触编程的人，前一年半基本上是在面向过程语言中度过，写了数不清的C代码，因此不少时候脑子里有不少C语言的设计思想，常常会想java中是如何提供这个语法功能的。本学期接触面向对象程序设计，最大的感觉就是：原来编程语言相关的设计和思想这么精彩。先说我的的程序吧，首先呢，得益于几位大佬的帮助和课程的训练，代码能力上取得的进步是最大的，从命名规范，书写格式，数据结构，类和方法的设计，再到线程的规划与管理，都有了长足的进步。固然确定要贴图对比才最直观了：

第一次做业：

 

若是硬要评价的话，此次做业就是满满的C味java，彻底是C语言的设计思想，只不过伪装创建一个类调了java类库的一些方法而已。

那么到了第十一次做业：

编程规范上已经有了长足的进步，同时也学会使用java的一些更加高级的语法，最重要的是，真正使用面向对象的思想来建模，逐步使用接口来对设计进行规划。

到了最后一次代码做业，即第十四次做业，即重构ALS电梯时：

代码风格已经趋于稳定，算是比原来的本身上了一个大台阶吧。

　　关于文档和规格，其实我一贯是很是支持注释和文档的书写，代码写的简洁高效易读，同时辅以良好的注释和说明文档，就像本身写的一篇文章同样。不过说实话，我对于以JSF这种方式进行规格撰写是不太支持的，我我的偏向于java类库中那种javadoc的格式，这个想作到自动化太难了，从理解的直观性来讲，天然语言是要好过逻辑语言的，若是咱们在设计上加以优化，二义性的问题也能获得很好解决，JSF的优点是能覆盖到问题的各个方面，绝无二义性，因此我的以为也能够适当把JSF补充在可能出现二义性的地方。不过，规格书写的重要性，或者更深层次，设计规约的重要性，我在第十四次做业中获得了很是良心的体验。在进行JSF论证以前，我对以前的代码进行了不折不扣的重构，自认为已经很完美了。可是在进行论证的过程当中，仍然发现了几处很难表述的方法，而以后经过对划分执行状况，再对代码做进一步分析后发现，个人设计思路中有不少交叉和冗余地方，好比明明能够经过维护队列完成的功能，我在以前的设计中却给队列元素增长了两种标记，标记之中还有小的分类，导致代码功能虽然正确可是很臃肿，而经过论证时对于各种状况的剖析与划分，便能很容易的找出问题的缘由所在，这也再一次告诫我，必定要设计优先，不要直接上手写代码。

　　关于设计问题，我大约经历了这样一个过程：面向过程——无脑使用类，方法当函数用——抽象类+接口设计。仅凭大脑思考，基本是不可能驾驭大工程的，那么经过设计方法学来首先作设计规约，并把全部的设计思路具象化，在java中使用抽象类+接口设计的方式进行初期规划，并辅以文档和规格进一步对类和方法进行规范化，作完全部准备工做以后再开始写代码，这样，才能真正写出大工程。

　　测试是个人一个很严重的弱项，老实说如今还处于对拍器对比输出结果的阶段。本学期初步接触了单元测试，可是感受理解的还很不足，我的认为这部份内容最重要的仍是在实际中使用，为了完成做业去编写单元测试意义不大，由于测试的代码基本上都是已经修复完bug的版本，少了测试——发现bug——修复bug——再测试这一环节，就很难深入体会到单元测试的优势，这部份内容结合在复杂的几回做业中就更好了。

4.3 工程化方法之我见

　　工程化方法包括不少的内容，一一说下来要列好长的清单，其实核心就在于如何解决我的有限的能力和工程无限大的复杂度的矛盾。实际工做中大工程须要不少人来合做完成，而每一个人的能力，特色又不可能相同，因此1+1=2是绝对不可能的，那么如何在这样的状况下，尽量的追求整体的最终的高效率和高质量，这就是工程化方法告诉咱们的事了。固然，如今的工程化方法大可能是创建在人的经验之上的。说不定到了将来，因为编程人员能力的提升（或者说机器自动生成底层代码），相关数据分析能力的提升，工程化方法将变成数据导向的产物，人类的思考只需作最高层的设计。毕竟，最核心的永远是解放生产力，让人的思考用到最关键的地方去呀。

4.4 关于OO

　　关于OO课程，首先表示很是感谢这门课程，确实给我带来了不少变化。这门课程虽然被不少人诟病，可是我以为仍是颇有其存在必要的，只是一些具体实现的环节仍然存在问题，所以，我但愿能成为OO助教，真正去修补这些问题，而具体的建议，就经过实际工做来看吧，OO接着继续！