【做业4.0】HansBug的第四次面向对象课程思考

嘛。。不知不觉这门课程要结束了，那么就再说点啥以示庆祝呗。

测试vs正确性论证

说到这个，相比不少人对此其实颇有疑惑，请让我慢慢分析。

逻辑概览

首先咱们来看看两种方式各自的作法和流程是什么样的：

单元测试

在测试中，咱们是这样的一个流程

此外，为了保证测试能覆盖到工程代码的每个区域，须要保证测试的覆盖率。

正确性证实

在证实中，咱们是这样的一个流程

在这一过程当中

• 基于行为分析的repOk永真性证实依赖于JSF中的modifies项
• 方法正确性将基于JSF中所描述的effects和requires项
• 各方法内其余方法的调用须要依赖被调用方法的正确性，具体来讲
  • 对于系统自带的类与方法实现一概默认正确
  • 对于其余位置的调用，正确性则依赖于其具体方法或类的正确性证实

关键细节

基于以上的逻辑，咱们不难发现一个细节：

• 在单元测试的流程图上，当程序经过测试后，是假定程序为正确而不是程序为正确

或者更具体地说，这里多出了一个名为假定的字眼。

这是什么缘由的？其实说来也很是简单——由于测试，只能证实程序有错，而不能证实程序是对的。

虽然有大数定律的理论支撑（即只要测试集数量无限大，则一定能够覆盖一切状况），但是实际上并不存在无限大的测试集，故测试上的死角总仍是会存在的。

设一个有限集 $ T $ ，为测试集（单元测试中的测试集不可能作到无穷），而 $ S $为全集。然而，在实际状况下，可能遇到的状况经常是无穷多的，故 $ S $ 是一个无穷集。

故，$ \complement^{S}{T} $ 即为测试集没有覆盖到的地方。又 $ T $ 有穷， $ S $ 无穷，故 $ T \subset S $ 恒成立，$ \complement^{S}{T} \neq \emptyset $

故永远有覆盖不到的数据，且对于这部分没法覆盖到的区域，是没法仅依靠测试来证实正确性的。

故基于测试的正确性验证的严谨性问题是不可避免的。若要严格意义上地论证正确性，基于程序逻辑的正确性证实是惟一的选择。

异与同、取与舍

在上面的分析中，咱们论证了单元测试方法存在的硬伤。

然而，咱们为啥还要保留这样的方法呢？

由于，实际问题与应用大都不是一元线性的，而是时间、经济、人力等多方面成本以及多方面效益指标所构成的高维量。

其实，在工业界各种应用中，经常有如下两种模式能够长久而稳定的存在：

• 较高的成本，绝对高的质量（或者说其质量水准具备不可替代性），可是部署门槛稍高
• 成本低廉，较高的质量，且易于普遍普及与部署，易于操做易于维护

实际上，不只在计算机行业，在其余工业界乃至于商业中，也经常会造成这样两种模式并存的局面。

而反映在软件质量保证领域，则分别是基于程序设计逻辑的正确性证实（正确性从原理层面上就有绝对的保障，但是成本嘛，各位都写过一次论证，体验过其成本之高昂）和面向数据指望的单元测试（操做很是简便，方便大范围部署，且能覆盖绝大部分实际状况）。

因此，在实际应用中

• 严格的正确性证实经常只会被运用在一些对产品质量要求绝对高的局部区域（例如航天器的核心控制程序，对错误的容忍度为零）
• 普通的单元测试则会被普遍运用在通常工程项目的测试中（对错误有必定的容忍限度，但务必兼顾时间、经济成本和效益，创业公司的项目中更是如此）

说到底，这二者其实很难去严格区分一个优劣。不少问题，根本上仍是一句话——具体问题具体分析，适合的就是对的。

OCLvsJSF

何谓OCL

OCL，英文全称object constraint language，翻译过来就是对象约束语言。

顾名思义，其做用在于对设计的对象进行约束，且保证不存在二义性。且实际上，OCL和UML（统一建模语言，Unified Modeling Language）捆绑使用。

异与同

从以上的一些基本概述中，咱们不难发现OCL实际上和JSF有着类似之处：

• 都是对于程序设计上的约束（其中包含了类合法性、以及方法行为等要素）
• 最终目标都是描述程序设计的预期行为，做为一个统一的标准

然而进一步研究与分析，其区别也是很大的：

• 首先，OCL约束的核心对象和JSF有较大差异。JSF在围绕方法和类，而OCL则在对象，以及对象内、对象间所包含的数据项。
• 基于以上的缘由，OCL的表达能力远远比JSF丰富。OCL做为约束语言，能够自由地约束各处的数据项和设计规范。而JSF的不变式约束相比之下就逊色了很是多。
• 也正是因为OCL的丰富性和完备的可计算性，因此OCL彻底具有相似SQL那样的查询能力。
• 可是，为了支撑如此庞大丰富的能力，且保证无二义性，OCL所付出的代价就是重量化。而JSF则相比之下更轻便更快捷。

而至于具体应用呢，则仍是老规矩——适合的就是最好的。在不一样的工程项目，不一样的场合下，天然会有不一样的选择。

关于第十四次做业

UML类图

顺序图

状态图

其余

知识点之间的关系

首先，咱们来回顾下咱们这学期四章的各个标题：

• 第一章 Java与对象（Java和面向对象基本概念入门）
• 第二章 并发与安全（多线程程序设计入门）
• 第三章 抽象与规格（规格化与总体设计进阶）
• 第四章 测试与论证（工程化质量保证措施学习与体验）

其实这很明显，是一个按部就班的过程，体如今两个不一样的层面上：

• 从学生学习的角度而言，知识体系是层层递进的
• 从工业生产的角度而言，这个也很接近一个产品从设计到交付，自底向上的一个完整流程

我的收获与小结

实际上，笔者在多年前，就已经接触并使用了面向对象程序设计语言。

因此，实际上在这个学期，笔者的主要收获以下：

• 经过十几回做业对程序框架设计的反复揣摩，笔者在总体框架设计上的水平更加趋于成熟
• 更加深刻的了解了严格工业界的一些作法（例如普遍地规格化程序设计，以及正确性证实等）
• 此外，笔者结合以前多年的实践经验（理论课上讲到过的坑，笔者当年几乎全都亲自踩过一遍）和对工业界的一些基本了解（笔者已经作过多笔的外包项目，目前仍在着手运营的项目也有数个），对面向对象和工程化的理解也更加深刻了。

工程化的我的看法

关于工程化呢，其实说难也难，说简单也简单得很。

一些具体的好处呢，笔者在前三次博客做业中均有不一样程度的论述（此处再也不赘述）：

• 【做业】HansBug的前三次OO做业分析与小结
• 【做业2.0】HansBug的5-7次OO做业分析与小结，以及一些我的体会
• 【做业3.0】HansBug的第三次博客规格总结

不过说到底呢，其实就几件事：

• 任什么时候代任何状况下，左右战局的决定性因素，永远是人
• 所以，工程化的一个基本思想就是以人为本
  • 从开发者角度，为开发者提供方便提升效率（不管是短时间仍是长期，不管是单人仍是团队，都是须要考虑的）
  • 从商业团体角度，提升总体战斗力，创造更大的效益和价值
  • 从用户角度，让用户体验更优（或者说给用户提供足够的方便），让用户更加愿意直接或间接地掏腰包（统计意义上的）
• 此外，对于不一样的解决方案，通常状况下存在即合理（或者说，对于尚未被淘汰的解决方案，其存在终究是能够良好知足某些场合下的需求的）。对此，咱们该作的，就是具体问题具体分析，选择在具体状况下最优的方案。

课程思考与建议

我的的思考与建议

关于这个问题，笔者在两三个月前，就已经开始思考了。

众所周知，面向对象课程的槽点仍是不算少的。

不过，据笔者看，这些问题看似庞杂，可是只要仔细去理一理背后的逻辑关系，其实也很简单。

笔者根据自身了解的一些事实，和大半个学期以来的观察与分析，粗略的获得了下面的这张逻辑图：

不过这样一来，看似错综复杂的事情也就清楚了。

稍加观察，即可以发现问题的根源——没有一个相对公平合理的横向比较机制。（稍微了解拓扑排序的概念，即可以得出这样的结论，找到节点的上游）

其实，不少同窗（包括16级的和之前的学长学姐们）以前所吐槽过的问题，根源都在这边。

假如，咱们有一个很靠谱的自动化横向比较机制

• 那么，咱们的分数将更具备梯度和区分度，且评分核心依据将是程序的真实质量
• 那么，互测的实际门槛将能够考虑提升，互测人员的总体素质也将提升
• 那么，基于上一条，咱们将再也不须要每次祈祷不赶上坏人（指的是为了本身的分数能够不要脸良心还从不痛的那种）
• 那么，基于上一条，咱们的助教们将再也不须要面临巨大的仲裁任务压力
• 那么，基于上一条，咱们的同窗们将再也不须要承受等待助教仲裁的痛苦煎熬
• 那么，咱们的评测将能够考虑部分模糊化，以适应模糊化的需求
• 那么，基于上一条，咱们的同窗能够再也不不停地纠结需求细节（经常仍是可有可无的细节），助教们也将大大减小issue答疑时间
• 那么，基于以上全部条，咱们的同窗们的总体体验将有质的飞跃
• 那么，基于上一条，同窗们将更加愿意积极努力学习这门课程

实际上，想作出改变，也并不难，好比：

• 公测再也不严格面向bug出数据。或者至少不彻底面向bug，面向bug的部分能够做为功能性弱测。
• 自动化公测引入模糊化测试。好比相似于oj中的Special Judge和提交答案题里面的部分分机制相结合，让程序只要不违背基本法（例如电梯不许瞬移不许分身）就能有分数，且各个水准的程序得分有梯度。
• 能够将面向bug的功能性弱测和模糊化性能强测相结合，构建出更有游戏性的制度（也能够容许在必定时间内公测屡次提交，屡次刷分，追求卓越）。
• 由此，能够基于公测最终成绩，设立必定的互测门槛，经过门槛者方可进入互测环节。
• 在互测环节中，能够设计相似codeforces那样的多对多大混战hack模式（也能够考虑待测程序不匿名，今后再也不有无效做业的坑），保证互测的运气成分降到最低。

固然以上只是一些初步构想，笔者对于这个（自认为）靠谱的新制度，已经有了更深层次的计划和构想，更具体的计划等细节将在另外一篇文章中详细阐述。

想对接下来的分析者们说的一些话

笔者写到这里以前，看过以前很多同窗的一些思考与建tu议cao。

不得不说，虽然大部分的所谓分析彻底流于表面，透过现象看本质的几乎没有（截至2018.6.25 6点整），可是，你们反映的问题，也很真实，或者说很真实地描绘了大众水平同窗眼中的面向对象课程。

说这个，其实不是想吐槽各位（实际上，笔者更但愿你们能继续描述心里的真实体验）。

引用笔者以前说过不止一遍的一句话

无法带来丝毫改变，甚至只会让事情更坏的怒火，是毫无心义的。

因此呢，但愿接下来看到笔者文章的各位，能在吐槽的基础上和自身能力所及的状况下，进行更深刻的思考，能够的话也多想一想到底如何才能让事情变得更好，而不是一味地抱怨与泄私愤。

抱怨没有用，实干才能解决问题。