一、论述测试与正确性论证的效果差异，比较其优缺点
测试是设计若干组测试用例，运行程序并检验其是否完成预期功能。测试是一种直接发现BUG的方法，可以准确断定什么样的BUG会发生，并通过辅助调试进一步确定发生BUG的代码位置。测试效果取决于测试者设计测试用例的覆盖面和针对性。
正确性论证是根据规格化设计原则，逐个检查每个类的属性、方法代码是否有违设计规格和数据保护原则，从而确定程序的正确性和错误发生的位置。这种方法相对测试，其随机性会小一些，效果主要取决于规格是否真实反映了客户端需求以及论证者的逻辑严密程度。
总的来说，测试的优点是发现BUG的证据相对确凿，效果直接明显。缺点是测试过程不可避免具有随机性，而且发现BUG之后的定位工作也需要花费一定时间。正确性论证的优点是论证体系严密，降低了随机性，并能够做到更加精准的错误定位。缺点是对程序员的逻辑严密程度提出了更高的要求，且对规格的准确性有一定要求。
二、调研OCL语言，并比较其与课程所介绍的JSF规格之间的相似和不同之处
对象约束语言(Object Constraint Language, OCL)是一种用于施加在指定的模型元素上约束的语言。它是用来进行约束定义的，形式化的，无二义的语言。
相似：
两者均采用了布尔表达式来表示约束条件。
对于方法约束，二者均借鉴了规格化设计思想，设计语法表达前置、后置条件。
不同之处：
JSF的语法风格接近一阶谓词逻辑公式，OCL的语法风格接近C语言。
JSF对方法规格和类规格做了严格的格式规定，例如方法规格必须有
/**
* @REQUIRES:
* @MODIFIES:
* @EFFECTS:
*/
3个内容（前置条件、修改对象、后置条件），写在每个方法代码之前。
类规格OVERVIEW必须写在每个类内部第一行。
而OCL在格式上灵活一些。首先利用context指明适用的类（对象），之后可以补充关于某个属性的约束，或是关于某个方法的前置、后置条件。换言之，OCL里面写些什么，完全是看编程者需要让调用者明白什么，显得不那么死板。
应用场景上，JSF主要作为注释添加在源代码中，与特定方法或类代码绑定。OCL可以插入在UML图中，或是单独成文档。
三、第15次作业：单电梯系统的UML表示
UML类图：
UML顺序图（调度器的调度过程）：
UML状态图（电梯运行中的状态转换）：
上面UML类图的图表示：
四、整理总结一个学期所学所练
1、阐述四个单元模块知识点之间的关系
第一单元 初识面向对象
本单元通过3次作业的开发，使学生熟悉面向对象式程序的基本写法，了解类、对象、实例变量、方法、继承、接口、多态这些基本概念及其实际应用。
第二单元 多线程设计与面向对象设计
本单元一是通过多线程电梯、文件系统监控这两次作业的开发，使学生熟悉多线程程序的基本写法，了解线程、线程状态、锁、同步化这些基本概念，体验线程安全设计。
二是通过城市出租车调度系统开发，使学生学会根据客户需求提炼出需求文档，并体会SOLID设计原则对工程化开发的帮助。
第三单元 规格化设计
本单元通过在之前作业基础上新增功能，并撰写规格，使学生掌握规格化设计思想，实践LSP原则，感悟客户需求发生变化时如何尽可能少地调整自己代码以适应变化。
第四单元 测试与正确性论证
本单元基于之前作业，要求学生撰写测试代码以寻找之前作业的BUG，并撰写文档证明该程序的正确性。
总的来说，前两个单元是本课程的基础，而第3、4单元分别训练了专业软件工程人员两个方面的能力。之所以说前两个单元是基础，一方面是后两个单元的作业要在前面作业的基础之上完成，另一方面是学生只有熟悉了JAVA语言、面向对象和多线程的基本概念，具备了一定能力，才能通过后两个单元的学习实现能力的进一步提升。第3单元训练学生规范自己代码的能力，以方便整个项目团队的交流合作。第4单元训练学生测试和论证的能力，以确保学生日后能够开发高质量的面向对象程序。
2、梳理自己所设计实现的程序，分析自己在设计、测试和质量上的进步
设计：从无到有
之前的“数据结构与程序设计基础”课，布置的作业都是考察特定数据结构的使用，根本不涉及程序“设计”的问题。只要看一眼题目，便大概知道需要做什么工作。OO课布置的作业更贴近实际工程开发，代码规模远超之前的程序设计课程。而且，很多作业以系列的形式呈现，更加强调一开始做出一个良好的设计。我在设计方面，可以说经历了一个从无到有的过程。拿到第一份作业时，我一脸茫然，因为自己已经很久没接触程序设计题目了，而且还是综合性如此强的题目。随着自己自学JAVA语言以及学习理论课，我逐步掌握了从作业题中提取关键数据封装为类的面向对象思想，在设计之初就能大致确定这次作业需要写几个类，分别完成什么功能。
测试：逼上梁山
之前的程序设计课，在截止时间之前是可以无限次提交的，因此自己之前一般不自己做测试，而是依靠OJ评测发现自己的问题。OO课不一样，交上去只能显示编译通过，公测会在提交截止后进行，到那时候什么都晚了。从那时起，我开始在提交之前测试自己的程序。但是前半学期主要是从指导书上找样例，有时也去讨论区看看别人提出的问题和测试用例，自己设计的测试用例还是太少。进入最后一个单元，所有学生被要求使用Junit 4写自己之前作业的测试代码，并且还提出了覆盖率要求。这个时候我开始苦心孤诣编写测试代码测试，以求达到那个覆盖率目标。然而，自己最后还是因为覆盖率不足被扣了分，申诉到现在依然没有结果。其中的原因不得而知，但是自己在测试程序上还有很大的提升空间。
质量：更加负责
之前自己在设计程序时，基本上不考虑质量问题，因为也没有人教给我高质量的程序应该怎样去写。自己对质量的认识，也只停留在程序崩溃时跳出的报错界面。到了OO课这里，质量问题被尖锐的提了出来，不crash成为了基本要求。我通过听课和自学，掌握了异常处理、数据封装等提高安全质量的方法。同时通过第3单元的训练，我开始在类和方法中添加注释，帮助别人理解我的程序。
3、阐述自己对工程化开发的理解
特点1：规模大
一个复杂的软件系统，其实现的功能是十分丰富的，这就决定了其代码规模远远超过我们所写的任何一份作业。如何从总体上把握这项工程的脉络，分解这一任务，显得尤为重要。这就需要软件工程人员准确提炼客户需求，准确识别所需管理的数据并以类为单位进行合理划分，交由不同的人员予以具体实现。为了保持工程整体的可维护性，也需要用到所讲的SOLID设计原则。
特点2：重视合作
工程化开发的第一个特点，决定了它不可能由个人独立完成，而必须依赖团队的协同与合作。如何提高沟通的效率、使自己代码被他人使用时不出问题，就需要规格化的设计与代码实现。规格就像契约，规定了类的抽象或方法所实现的功能，并通过前、后置条件予以约束。它为整个团队提供了契约，使彼此合作有规可循。
特点3：存在BUG
在北航核心通识课“失败的逻辑”上，潘星老师通过讲解墨菲定律、海因里希法则，说明了由人完成的工程项目中，错误和漏洞总是难以避免的。工程化开发的第一个特点也决定了软件不可避免地存在漏洞。一方面，工程团队尽可能去发现和封堵漏洞，即测试。另一方面，工程团队试图通过一定论证手段，证明自己软件的正确性，或是说明漏洞处于可控的范围内。
4.4 对课程的任何期望或建议
1、备受争议的互测机制与乱扣分现象
北航计算机学院的学生对这门课程普遍评价不高，很大一个原因就是尚不完善的互测机制。学生调侃这门课是面向“运气”编程，因为课程成绩一部分取决于自己分配到测试者的个人素质。测试者较为仁慈或是测试能力有限，那么自己有可能能得到较高的成绩。测试者道德沦丧，那么自己就可能被疯狂报BUG，甚至乱扣分。
固然，这些情况课程组（尤其是助教团队）是清楚的。今年他们通过分类树机制降低了功能BUG被乱报的可能。然而，对于无法纳入分类树的部分（尤其是JSF规格），乱扣分的现象依然十分普遍。这导致课程规定的训练目标无法按期达到，甚至出现了为规避扣分而将大量代码集中在一个类/方法中的现象。
建议课程组拿出“打虎拍蝇”的高压态势，对乱扣分者实行“封号”措施（无互测资格，甚至直接取消作业成绩），起到震慑作用。学生“不想乱扣”的终极目标需要我国教育体制的深层次变革（特别是德育教育）予以实现，但是“不敢乱扣”、“不能乱扣”这两个层次完全是课程组通过制度完善能够实现的目标。
2、互测中的匿名机制与无效作业
为了杜绝互测环节的权钱交易，今年课程组实行双盲互测：要求所有提交内容必须删除个人信息，否则测试者可以申报无效作业。
今年测试者与被测者私下交易的情况确实少了很多，这固然是可喜的。但是有些学生并未试图私下交易，却仅因为个人信息没有删干净而被报告无效作业，令人痛心。出现这样的情况一定是课程组制定规则时始料未及的，而且删除个人信息也不是本课程训练的重点，这就对这条规则的合理性提出了质疑。
改进措施1：规定发现个人信息时，必须至少找出一处BUG才可以申报无效。
改进措施2：规定只有发现编程者的联系方式（手机号、微信号、QQ号、邮箱等）才可以申报无效。
3、通知的下发
目前学生与课程助教的交流手段有两种，一是每两个小班建立一个答疑群，二是通过gitlab的issue讨论区。然而，课程组有时需要发布一些对于作业的统一补充说明（以下简称“通知”），但是经常出现学生不能及时看到通知，作业出现一些本可以避免的错误的情况。
通知并不适合通过这两种方式下发。答疑群容易出现大佬水群，而且微信群的“群公告”一次只能保存和显示一条信息。ISSUE的功能偏向答疑，一些遗留问题比较多的作业都会有数十条issue，根本没功夫看完。另外，计算机学院虽然有一个名为“通知版”的微信群，但是这些通知并不适合发布在这里，而且也没有照顾外系的同学。
我注意到课程网站上有“公告区”，但是自始至终这个公告区没有发布过一条公告，成为了摆设。强烈建议助教团队将它利用起来，在此区域发布通知公告。
4、课程组对问题及时响应的问题
我理解课程组老师和助教都有本职工作，时间有限，但这不应该成为响应不及时的理由。我遗憾地看到一些issue很久没回复，一些申诉得不到及时回复，问卷调查反映的一些问题课程组连个说法都不给。如果学生提出的改进建议老师连给出答复都困难，那还做问卷干什么！