测试与正确性论证
用测试样例进行测试，可以直观地发现对于该测试样例，程序运行中在什么位置出现了问题。问题本身能直观地反映bug的存在。此外，一个bug的修复往往使得多个之前无法通过的测试样例得以正常通过。但是用测试样例进行测试想要进行全面的覆盖，工作量是十分庞大的。首先，要明确一个测试样例的在各个阶段的运行处理流程；然后，再根据各个阶段中的各个分支流程及其组合，构造测试样例进行测试；此外，还要结合各处数据的边界限制条件进一步加以组合并测试。随着程序规模的增长，系统复杂性的上升，组合的情况总数越来越多，想要全面覆盖所有情况将是一项庞大的工程；另外，在程序生命周期中，不断地更新迭代往往会使得先前测试中的做的工作中的一部分付之东流，需要重新进行测试。在人力物力和时间有限的情况下，我们往往需要进行合理的trade off。
而正确性论证则不同，它是以规格为导向的。在一定程度上，比直接构造测试样例更依赖于规格。进行正确性论证的前提是规格的正确性。对照规格，将程序中的每个方法按照流程全部论证正确后即可在一定程度上确保程序的正确性。这种方法的好处在于省时省力，只需对照代码和规格即可完成。问题在于，对于数据的边界条件，往往不能很好地体现在正确性的论证中；尤其是在调用层次过多的场合，前置条件能否满足往往有待斟酌，不那么容易一眼看明白。最致命的一点是，正确性论证是基于规格的正确性的，因此它本身往往并不能意识到在规格上可能出现的错误，而出现把错误的规格当做正常的功能的情况。
OCL语言与JSF规格
OCL是强类型的、声明式的、约束（Constraint）语言和查询（Query）语言
一个约束就是对一个（或部分）面向对象模型或者系统的一个或者一些值的限制。UML类图中的所有值都可以被约束，而表达这些约束的方法就是 OCL。在UML2标准中，OCL不仅用来写约束，还能够用来对UML图中的任何元素写表达式。每个OCL表达式都能指出系统中的一个值或者对象。因为 OCL表达式能够求出一个系统中的任何值或者值的集合，因此它具有了和SQL同样的能力，也就是说OCL也是一种查询语言。
OCL是一个类型语言，任何表达式的值都是属于一个类型的。这个类型可以是预定义的标准类型例如Boolean或者Integer，也可以是UML图中的元素例如对象。也可以是这些元素组成的集合，例如对象的集合、包、有序集合等等。
OCL表达式仅仅描述了应该去做"什么"，而不是应该"怎样"去做。因为OCL是宣言式语言，所以UML中的表达式被提升到了纯建模的领域，而不必理会实现的细节和实现的语言。
OCL是基于数学的，但没有使用数学符号
OCL的基础是数学中的集合论和谓词逻辑，并且它有一个形式化的数学语义，但是它并没有使用某种数学符号。因为虽然数学符号能够清晰的、无歧义的表达事物，但是只有极少的专家可以看懂。所以数学符号并不适合用于一个广泛应用的标准语言。自然语言是最易懂的，但是它是含混不清晰的。OCL取了自然语言和数学符号的折中方案，使用普通的ASCII字符来表达数学中同样的概念。如果你不喜欢当前的OCL表达方法，OCL规范还允许你定义自己的OCL符号集，这点是可以理解的，因为OCL有一个清晰的数学语义。
OCL类型和语法
OCL起源于1997年BIM公司为响应OMG的"面向对象分析和设计标准"征求稿所提交的"对象时间限制提议"，OCL是该提议的部分内容。 用OCL可以描述四类约束，分别是不变量、前置条件、后置条件和监护条件。
1）不变量是在属性的生命期内一直保持为真的规则。
2）前置条件是在一个操作被调用时必须为真的约束。它是一个断言，不是可执行语句。
3）后置条件就是在操作完成时必须为真的约束。它不是可执行语句而是断言，必须为真。
4）监护规则是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。
OCL与JSF的异同
异：1.OCL采用了自然语言和数学语言之间的折中方案，在表达式的可读性和精确性严谨性之间进行了权衡；而JSF采取的一般都是纯粹的一阶逻辑，大量使用逻辑符号。
2.JSF有modified项而OCL没有，OCL有监护规则而JSF没有。
3.JSF对类型的规定与限制比较模糊，而OCL是强类型的。
同：1.都是程序规格的一种表示方式。
2. 均采用了部分数学语言作为规格表述。
3.均有前置条件、后置条件以及不变式。
ALS单电梯UML图
类图
时序图
状态图
课程收获
知识点联系
自我进步
1.Java零基础→会写一般的多线程程序；
2.从未接触过面向对象→初步了解了面向对象有关思想；
3.认识到程序设计的工程化、流程化的重要性，做程序的设计分析更加高效熟练；
3.代码鲁棒性、测试的完备性与熟练度大幅提升；
4.沟通能力得到了有效锻炼；
5.认识到了从更高的角度纵观事物的全局的重要性以及一些基本的方法，进一步锻炼了在多种选择中多项事务中进行权衡的能力；
6.强化了自己对情绪和精神状态的管控。
工程化开发初步
笔者认为，在工程化开发上，尤为重要的是可用资源和目标实现之间的权衡，以及甲方乙方的沟通。实际的项目开发中，团队中成员的可进行的工作量基本是恒定的，可用的物力、预算也基本恒定，因此在一定时间内完成的工作量也是恒定的。所以在面对甲方的花样需求时，往往需要更多的、及时的、合理的沟通，在有限的生产力与工作量之间进行权衡。而要达到这个目的，则需要团队领导严格的工期把控，需要把控工作流程使之有一定的弹性。
对OO课的期望与建议
1.希望能改善更改需求的时候的沟通效率，尽可能确保沟通是及时的，双向的。
2.希望在相邻两次作业之间的难度提升更加合理，从单线程到多线程这部分给的缓冲时间有点不足，这部分作业的效果和辛苦程度并不是一个很合适的状态。
3.希望能更多地体现teamwork以及项目本身的维护。比如每次作业先进行随机分组让组内同学内部相互测试对程序进行完善，之后再进行双盲测试。