OO终章

测试与正确性论证的对比

测试的优点简捷高效易操作，缺点在于仅能发现设计的错误之处，不能测试出设计的缺陷和不足，对设计的优化几乎没有帮助。

正确性论证的优点是全面深入和可靠，在论证过程中不仅很容易就能发现设计的错误之处，还能发现设计的缺陷和不足，在此基础上可以对设计进行优化，缺点在于耗时极为可怕——仅仅五六百行的代码量，也往往意味着1w字、20+页的论证文档！

OCL语言与JSF

OCL，即对象约束语言，是UML可选的附加内容，用于更好地定义对象的行为，并为任何类元指定约束。OCL是且只是一门形式语言，可以用于任何实现方式的非正规语言，它对UML的图形以及其他组件没有控制权，也不能修改对象状态，只能指示对状态的修改何时发生。

在大体上看，OCL和JSF没有太大差别。二者都是为约束建模对象、指示对象状态改变而生，都定义了一些特定的概念和语法，都是通过提炼和构建可判定真假的表达式的方式来实现提示和约束。在细节上，诞生于1995年的OCL的历史显然更加悠久（废话），更加细致和复杂，甚至还有OCL标准库，正如其命名，它实际上是一门语言；而JSF只是源自一位学姐的毕设的一种建模约束规范，本身可能借鉴了OCL的思路和实现，但在实现时较为简洁（或称简陋……），相对于OCL而言更易于掌握。

总体来说，使用JSF基本能够实现使用OCL的效果，而且JSF在时间上更为经济。

UML图

UML类图

 

 

UML时序图

 

 

UML状态图

 

 

总结

1、知识点

第一单元的训练主要是Java基础编程训练，训练同学们面向对象编程的能力，让同学们熟悉和掌握面向对象编程的方法和技巧。在这一单元，用面向对象的方式解决问题是难点所在。

第二单元的训练是基于第一单元的进阶篇，主要引入了多线程编程，这一单元较上一单元在难度上有了质的飞跃，多线程并发处理在极大提高处理效率的同时，也引入了许多安全性问题——这些问题都是依靠第一单元的知识完全不可能解决的诡异问题。在这一单元，线程安全问题是难点所在。

第三单元的训练是规格化设计，也就是喜（吐）闻（槽）乐（不）见（断）的JSF。这一单元训练同学们通过规格化设计和实现各个模块以满足需求的能力，同学们在学习过程中需要为自己的模块写JSF。这一单元的难点主要在于正确、规范地书写JSF。

第四单元的训练是测试和论证，训练内容是通过两种有效的方式来检查和验证实现的正确性。测试是通过编写测试代码来对实现代码进行覆盖，通过实践的方式确保实现的正确性；论证是通过对所有类的抽象对象有效实现、对象有效性和方法实现正确性进行论证，通过理论的方式证明实现的正确性。这一单元的难点在于实现思路的清晰化——无论是测试还是论证，同学们都需要对自己的实现思路极为了解明晰；但是，这是第三次作业的代码，假如没有重构，那么也许大家早就忘了自己写了些什么了，思路什么的就更别提了。

2、进步

在设计上，通过这一学期的训练，我的设计明显更加简洁、规范和均衡，最开始常常出现的“上帝类”“傻子类”到了后期完全消失，一个方法动辄百行以上的代码的情况也不再出现，并且在变量命名、方法分拆等方面也学会了规范操作。

在测试上，从一开始主要通过阅读代码、根据实现逻辑发现问题，到后来通过JSF进行核对、通过设计针对性样例进行验证、通过覆盖性测试进行验证等等，我的测试方式变得更加多样，测试能力明显提高。

在质量上，我的编程能力得到了飞跃般的提升，这种提升可以通过一个直观的对比来体现——在训练之前，两三百行代码对我来说绝对是一项极具挑战性的大工程；而在训练之后，千行代码对我来说已经是完全在我的能力范围之内、问题不大了。更重要的是，通过这个学期的OO训练，我的代码在简洁性、规范性和可读性方面都有了极大提升，前些天翻看自己第三次作业的代码，我都不敢相信这样的垃圾居然是出自自己之手；重构第三次作业的代码之后，我都不敢相信我能写出如此简洁高效而规范的代码。

总的来说，这一学期的OO虽然痛苦了些（尤其是第二个月熬得天昏地暗还全都无效了），但只要坚持下来，绝对是收获颇丰。三个月下来，菜鸟变大神完全不是梦，而是OO的常规（什么？三个月没坚持下来？补给站见）。

3、工程化开发

在我看来，工程化开发意味着：（1）程序的可靠性（健壮性）和正确性必须得到保证；（2）代码的实现需要简洁规范，执行效率要高；（3）代码的可读性要尽可能地高，要易于让人理解。

工程化开发的项目往往是较为重要的，那么其程序首先要可靠，不能随意造成系统崩溃，否则造成的损失可能会难以估量；在可靠的基础上还要求程序的执行是正确的。

工程化开发的项目，其代码量通常也会比较大，这就要求每个模块、每个方法的实现要尽量简洁规范，执行效率要尽可能地高，这样整个程序的执行效率才有保障。

工程化开发通常应用于团队合作开发，这就对代码的可读性提出了较高的要求。一个团队成员实现的代码绝不能只有他本人才能读懂，否则在相互不理解各自实现的模块的情况下，团队的协作配合将无从谈起。

4、期望和建议

我的建议有二：

第一点，无效有必要有所区分。信息无效和实现无效有区别，这是极好的。可是，不写的无效和写了但没写完（或者写完但没达到设计要求）的无效是否应该有区别？按照目前的规定，没写和没写完、写完但没达到设计要求，其结果似乎都是一样的——实现无效。那么，假如某位同学眼看完成无望，在两种无效完全等价的情况下，为何还要花时间去写，还有何动力去写？并且，一个根本没写，一个写了只是没写完（或写完但存在致命缺陷），其效果理当等价吗？在实现无效方面，希望课程组做出更细致的划分。

第二点，关于安排不一致和要求一致造成的不公平。这种不公平并非源自于OO课程，而是源自于金工实习。金工实习的时间是每周三，几乎占据周三全天，而且不少时候课上都是有任务的；本系的金工实习是分成两批的，前几个班在上半学期上课，后几个班在下半学期上课。如此，前面几个班的同学恰好在OO水深火热的时候，还要每周三早起，花大半天的时间去搞金工实习，等到当天课程结束，DDL也近在眼前了；而后几个班的同学去搞金工实习的时候，OO已经是进行到了第三、第四单元，编程能力已经大幅度提升的同时OO压力还骤减，完全可以轻松应对。对于这种不公平，我没有太好的建议（更确切地说是不愿意给出建议），但我希望课程组能够注意到这种情况的存在，并且考虑采取一些措施来改变这种不公。