OO第十五次作业

写在最前面：

　　终于结束了。

一、测试与正确性论证的效果差异。

1.测试

　　我认为，测试就是通过一系列实例的输入，通过输出以及对象的状态和预期的结果进行比对，从而发现程序的bug。我认为测试有以下这几点的优势：

1）操作起来简单快捷方便。因为我们只需对程序输入一系列的测试用例，然后对输出和预期结果进行比对就好了。除了构造测试用例费一些脑子，其实整个过程还是操作起来很简单的。

2）结果是客观可靠的。我们通过测试发现的bug，那就是客观上真实存在的，说明我们的程序就是真的有bug。而通过正确性论证的话，说不定哪儿手抖写错了，或者是逻辑出错了（我觉得对于初级的新手来说这种情况很可能发生，写上一次作业的时候，写到最后我也不知道我写了些什么，头晕脑胀，恶心想吐），我觉得不太靠谱。

3）对于功能简单的程序，可以快速的检查是否有bug，如果有bug则可以快速定位，修改bug。假如一段程序或者一段代码的功能比较简单，我们完全可以写几个测试用例来找bug，虽说这样理论上不能完全保证程序是正确的，但从概率上来说几乎可以说这个代码就是没问题的，而且这么做的最大优点就是速度快。同时，假如真的存在bug，并且你构造出了合适的测试用例，那你通过debug工具或者是自己眼睛回溯，其实可以快速的找到bug的位置，从而修复bug。

　　当然测试也是存在缺点的，我觉得测试存在的最大缺陷就是：对于复杂的代码，构造全面的测试用例很难，而且测试从理论上仍然无法保证程序的正确性。我们通过测试，永远只能保证程序的某些“点”是正确的，但是也永远无法证明“线”是正确的。这是我觉得存在的最大问题。

　　但从我个人而言，测试其实还是我们写程序时最基本，最方便快捷，最有效的检查程序正确性的方法。虽说不能完全保证程序是正确的，但是只要我们构造出合适的测试用例，在很大概率上还是可以保证你的程序没有什么问题。

2.正确性论证

　　正确性论证在我看来就是通过严密的思维逻辑推理论证，来证明程序是正确的。我的水平比较菜，我其实想问一个在别人看来很愚蠢的问题，“真正现实生活中做工程真有人用这种方法？”。我知道老师既然教我们就一定有教我们的道理，只是我才学尚浅，不能理解。我觉得正确性论证归根到底是采用自然语言来说明的，怎么能保证在用自然语言论证的过程中不会引入新的问题呢？而且对于正确性论证文档，动则数十页上百页，写文档出现的漏洞和错误的概率我觉得比写程序出现bug的概率大的多。我上次在写正确性论证文档的时候，差点写吐了，而且最要命的是，我写的东西我都不想回头再看一眼，看一眼都感觉要爆炸了。

　　言归正传，无论我怎么不理解，还是需要吹一波它的好处。它的优势在于，比起测试，它可以做到完整而全面的论证出程序的正确性。

　　再说说它的不足，我觉得最大的不足就是费时费力，论证的过程枯燥而繁琐，还容易出现错误。并且别人阅读起来也很难受。（起码我阅读起来很难受......）

二、OCL语言与JSF的相同和不同

　　唉，其实我在网上并没有找到完整的OCL语言的例子，以下内容大部分来自https://www.cnblogs.com/zhoujg/archive/2010/12/21/1912294.html。

1.相同

 1）均是声明式语言。首先，这两种语言均不会改变模型的具体内容。其次，在表达式中，仅仅描述了“去做”什么，而不是描述“怎么去做”。拿java来说就是不必关心方法具体怎么实现，只需关心这个方法有什么效果。

2）均是一种约束语言。均包含不变量（不变式），前置条件（Requires），后置条件（Effects）。

3）均基于了数学中集合论和谓词逻辑，但又不完全通过数学符号来表示。

2.不同

1）JSF中多了一个Modifies,OCL中没有对应的部分。

2）OCL中多了一个监护条件。监护条件是在对象能够从一种状态转变为另一种状态前其值必须为真的约束。

3）我们所学习的JSF语言，主要作用于类的方法中。而OCL语言表达式的作用范围可以是类或类的属性或类的方法。并且OCL语言通过一个叫做“上下文”的东西给出。

4）JSF的语言的表达式应该为一个布尔表达式，而OCL则没有这一要求。

5）JSF和OCL具体的语法（例如一些具体的符号、单词等）不同。

三、UML分析

1.类图、顺序图、状态图之间的关系

　　类图，通过显示出系统的类以及这些类之间的关系来表示系统。类图是静态的，它们显示出什么可以产生影响但不会告诉你什么时候产生影响。

　　顺序图是一个二维图。纵向是时间轴，时间沿竖线向下延伸。横向轴代表了在协作中各独立对象的类元角色。类元角色用生命线表示。消息用从一个对象的生命线到另一个对象生命线的箭头表示。箭头以时间顺序在图中从上到下排列。

　　对象拥有行为和状态。对象的状态是由对象当前的行动和条件决定的。状态图显示出了对象可能的状态以及由状态改变而导致的转移。

　　至于它们之间的关系，我认为，类图是顺序图和状态图的基础。当你完成一个程序后，如果不完成类图，那么完成顺序图和状态图是很难完成的。所以我觉得类图是一个程序最本质最基础的图。至于其他联系，我觉得顺序图和状态图还是有较大差异的。对于顺序图来说它只表示出了基于一条时间线度量的情况下，对象的反应，更适用于简单过程的描述。而对于状态图来说，它是基于不同条件下，对象的反应，更加适合对象因条件变化而状态变化比较多的情形。我觉得它们之间几乎没有关系。

2.UML

 

四、对一学期所学所练的总结

1.

　　这一部分来谈谈四个单元之间的关系。

　　第一单元我觉得是为java以及面向对象打基础的单元。这一单元首先介绍了面向对象，以及如何更好的设计，以及面向对象的继承和接口。实际上这一部分就为后面的三个单元做了铺垫。没有这一部分的铺垫，后面的单元也无法很好的进行。

　　第二单元我觉得是整个课程的重头戏——多线程。有了第一单元的对面向对象的铺垫，我们在这一单元进行了多线程的学习，包括如何写多线程，多线程的安全以及锁等。同时，这一单元的最后一次作业——出租车，为下一单元的写规格做了准备。

　　第三单元的主题是工程化规格的书写。经过了前两个单元，实际上我们对“写”程序，已经掌握的差不多了。下面我们就得更进一步，学习如何写“规范的”程序。这一单元的学习使得我们掌握了规格的书写，以及加深了对工程化的认识。

　　第四单元我觉得其实是收关单元。这一部分的内容其实我觉得没有那么多，也没有那么重。更多的是对之前代码的回顾，以及对前三个单元的总结思考，可以说第四单元是对前三单元以及整个课程的一个收尾。

2.

　　这一部分来谈谈通过梳理一学期所设计的程序，谈谈在设计、测试、质量上的进步。

　　首先在设计上。我其实觉得我在设计上没啥进步，因为每次的作业都不一样，而且我对我第一次到最后一次作业的设计都很满意，如果现在让我回头重写前几次的作业，我觉得我在大的设计架构上并不会有太大的不同，只是在具体的一些代码上可能有所提升。

　　其次在测试上。我觉得我这学期在测试上的收获就是学会了使用debug工具（在这学期之前我一直采用printf的方法debug），而且学会了JUnit4来测试代码。别的一些测试上的进步我觉得不是很明显。

　　最后谈谈质量上的进步。怎么说呢，我觉得这是一个相对比较抽象的概念。你说最后一次的代码和第一次代码比较起来，写的好了吗？显然好了。哪里好呢？可能有点难以回答。我觉得这种进步是一种潜移默化的进步。在不知不觉之间，你形成了属于自己独有的代码风格，并且不断的琢磨，不断进步。但是要是让我说哪进步了，还真不好说。我觉得归纳起来就是一句话“我形成了属于自己的一套代码的风格”。但是纸面上明显的进步还是有的，最最最令我欣慰的就是，我的命名规则在最后几次作业中比之前的几次作业舒服很多了，前几次作业基本上就是想怎么命名就怎么命名。

3.

　　下面我来谈谈我对工程化开发的理解。在我看来，对于工程化开发，我能想到的几个词是“严格”、“和谐”、“让别人明白”。首先关于“严格”，我觉得工程化的最大的特点就是，在设计以及写程序的时候，必须要遵循某些特定的规则，而且是需要严格遵守，这样才能使得每一部分的代码都严丝合缝，最终组成最后的代码。其次就是“和谐”。其实这是一个很抽象的词，我脑海中想的大概就是，在工程化的过程中，首先代码要保持和谐，也就是一种很舒服的状态；其次还要保证人与人的和谐，因为工程化永远不是一个人在做的。第三个词是“让别人明白”，我觉得这个特点就是，在工程化的过程中，你的代码不是写给自己的，你的程序也不是写给自己的，你要记得让别人明白你写了些什么，要让别人明白你要做什么。

4.

　　最后来说说对课程的一些建议吧。唉，说真的，我在宿舍里骂了无数次这门课，但是真回过头来想想的确学习到了很多东西。但是，我还是觉得这个课有不合理之处，就是这门课所需的时间不是很合理。换句话说就是它的内容和学分和所需要花费的时间严重不匹配。我觉得计算机学院每年都有一门这种课。对于除了大佬以外的普通一点的学生（例如我），想要学好这门课就得牺牲掉其他的许多课的时间。我有时候也在想，我给OO这么多时间真的对吗？至少现在还不能回答。我觉得还是得从它对我未来的影响来衡量，但是现在还是无法下定论的。唉，说了这么多其实也白说，又不能取消这门课，放到其他学期也不合适，唉，还是希望能在课程内容上改进改进，尽量做的简而精一些。

转载于:https://www.cnblogs.com/lllc/p/9190184.html