一、测试vs正确性论证
测试是根据程序的功能预判可能的输入与输出，分门别类，对一个完成了全部或部分功能、模块的计算机程序在正式使用前的检测，以确保该程序能按预定的方式正确地运行。
pros：
根据程序的用途设计，针对性强；
一个好的测试用例有可能发现很多的错误，会很高效；
cons：
设计感强，考验测试人员的能力；
容易仍然遗留一些不易发现的bug；
正确性论证是论证程序达到预期目的的一般性论述，与特定值无关，甚至能够代表穷举性测试。Dijkstra说过“程序测试只能证明程序有错，不能说明程序正确”。这也就是正确性论证的重要性。
pros：
在需要绝对保证正确的领域中有很大作用；
更为严密，相当于测试中的穷举测试；
保证程序正确的唯一途径
cons：
目前这种方法仍然不够完善；
能真正掌握的软件人员也不多；
二、OCL语言vsJSF规格
OCL(Object Constraint Language)语言。一个约束就是对一个（或部分）面向对象模型或者系统的一个或者一些值的限制。UML类图中的所有值都可以被约束，而表达这些约束的方法就是 OCL。
OCL取了自然语言和数学符号的折中方案，使用普通的ASCII字符来表达数学中同样的概念。
OCL是一种声明式语言，大部分表达式执行后会返回一个布尔值，也有一些表达式会用来选择一个单一值或者一个对象/值的集合。
OCL结构
JSF(Java Semi-Formal Specification Language)是一种规格。与OCL语言有一定的相似之处，但是主要针对的是方法的规格，即过程规格。
从整体上把握住一个方法对外部的要求(Requires)、 对外部的承诺(Effects)和方法要修改的系统状态和对象状态(Modifies)；
一定不能在Effects部分撰写控制流程或算法流程，而是方法执行 后用户获得的效果；
Effects一定要概括方法在不同输入形态下的多种执行效果；
三、单电梯系统图示
UML类图
时序图
状态图
程序构造图
四、oo，了解一下
4.1阐述四个单元模块知识点之间的关系
最开始的一个单元先介绍了面向对象的设计思想，知道了它在程序设计上与过程式规划有何不同以及鲁棒性的重要性。之后就是非常重要的多线程设计，其中各种锁的放置，同步机制的应用也是十分重要。后来逐渐抽象起来，将程序的过程进行抽象，即先搭起程序的框架，不在乎具体的算法，因此，学习了JSF规格的撰写，只为将方法进行抽象。最后，程序完成后的步骤就是测试了，先是编写测试数据来覆盖所有的测试情况，后来用形式化的语言进行论证。
4.2梳理自己所设计实现的程序，分析自己在设计、测试和质量上的进步
在一个学期的练习后，思考一个问题的解决办法时，开始考虑如何用面向对象的思想去解决。思考与构建程序框架的时间会大于完善方法主体的时间，并且试图构建出更好的方式，以便未来的扩展。
4.3阐述自己对工程化开发的理解
将系统化，规范的，可度量的方法应用于软件的开发、运行和维护的过程就是程序的工程化开发。工程化开发的目的在于提高程序的质量，主要有以下几个方面：
正确性(Correctness)：依据规约 完成任务
鲁棒性(Robustness)：异常情况 合理反应
完整性(Integrity)：非法访问或修改 合理反应
易扩展性(Extendibility)：软件产品应规约改变而改变
易复用性(Reusability)：软件模块 用于构建多种不同应用
兼容性(Compatibility)：软件模块相互组合的难易
高效性(Efficiency)：尽量少地使用硬件资源 处理器时间 内存 外存 网络带宽 等
易移植性(Portability)：转换到不同的软硬件平台上
易用性(Ease of use)：不同背景的用户学习使用软件产品解决问题的难易
以及在Java开发中的六大原则：
单一职责原则(Single Responsibility Principle, SRP)：一个类只负责一个功能领域中的相应职责，或者可以定义为：就一个类而言，应该只有一个引起它变化的原因。
开闭原则(Open-Closed Principle, OCP)：一个软件实体应当对扩展开放，对修改关闭。即软件实体应尽量在不修改原有代码的情况下进行扩展。
里氏代换原则(Liskov Substitution Principle, LSP)：所有引用基类（父类）的地方必须能透明地使用其子类的对象。
依赖倒转原则(Dependency Inversion Principle, DIP)：抽象不应该依赖于细节，细节应当依赖于抽象。换言之，要针对接口编程，而不是针对实现编程。
接口隔离原则(Interface Segregation Principle, ISP)：使用多个专门的接口，而不使用单一的总接口，即客户端不应该依赖那些它不需要的接口。
迪米特法则(Law of Demeter, LoD)：一个软件实体应当尽可能少地与其他实体发生相互作用。
要尽量通过这些原则实现上述对程序质量的要求。
4.4对课程的任何期望或建议
在我看来，目前的机制也相对完整，但是很明显，这门课程仍然在探索的路途中。
首先，关于指导书的问题。诚然，我们之后不会遇到更好的指导书，但是，一个粗略的指导书勾勒出大体的框架，据此完成的程序自然是每个人有不同的完成方式，甚至有不同的结果，自然，这门课的测试需要一个统一的标准，这是不可能用一个粗略的指导书完成的。那么，在这个中间有一片灰色区域，就是readme。
个人信息的问题。提供统一的方式进行个人信息的删除。
最后，我竟然有个奖，抱枕超级舒服，game changer！