OO第三次总结

第三次OO作业

规格设计调研

发展历史

• 在20世纪60年代第一次软件危机以前，软件的规模很小，大多只是用于满足私人请求。

• 到了80年代，“软件工程”的概念第一次被提出，计算机的速度和容量大大提高，程序的复杂度也急剧增长，人们开始在程序设计时以模块为单位，有了自己各自独立的工作，开始出现规格化抽象。比如说C++和JAVA的类说明和类实现出现了分离。

• 21世纪之后，出现了使用者和设计者的分离，也就完善成了如今的样子，使用者们不需要关心他们如何被设计出来的，也就是代码有了好的封装性。这样也就使代码的可移植性，跨平台性有了很大的提高。

为何被人们重视

• 正因为代码的分工合作性越来越明显，整个工程都是一种“分而治之”的工作状态，所以规格化也就十分重要了，因为这样可以使程序员的可读性大大增加，使程序的修改难度大大降低，所以人们发现他的方便以及作用，便开始重视了。

三次作业bug

	功能bug	规格bug	总bug数
第九次作业	4	0	4
第十次作业	2	1	3
第十一作业	0	0	0

规格bug

• 我这三次作业只被报了一个规格bug：Require不完整，也就是一些对于输入有范围了我写成了none，但是我认为require的要求应该是所有在require范围内的输入参数都不会使该方法失控，所以其实我并不觉得我有问题。而对方理解的则是输入的参数因为在外部使用该方法时会有一个范围所以我不应该写none。

功能bug

• 第九次作业在修改过程中，存在没有改全的部分，所以出现了功能bug，算是粗心吧。
• 然后第十次作业的两个功能bug都是测试者找到了我的程序在输入过程中可能导致crash的情况，怎么说，在我看来有一种偏离了测试重点的感觉，不过我的确这是没有try住，也是我的问题。

聚焦关系

• 从上面的功能bug和规格bug也可以看出应该是没有聚焦关系的。

前置条件的改进

• 尽量将requires写的清楚些，写成none的确容易出错：

• 改进后：

• 作业中没有，剩下的4种我要注意修改的前置条件改进：

• 2.不要用分号隔开，要用逻辑表达式&&

• 3.多用exist的写法比较规范

• 4.对于一些被修改的变量，要使用old

• 5.对于一些前置条件运用了别的函数来判断的，不要直接调用函数，能写成几句逻辑判断最好

后置条件的改进

• 原方法：

• 对于effects部分，我认为我自己写的太过于详细，也就是不够直观，有背于规格设计的初衷：能通过看JSF简单的知道方法的作用。

• 所以我觉得要改进的地方是，对于一些不重要的effects可以用简单的话语描述，不用写逻辑表达式，这样太过于形式化，不够实用。

• 作业中没有，剩下的4种我要注意修改的后置条件改进：

• 2.若是调用的别的方法，写成几句逻辑判断

• 3.直接运用实现代码的部分会不够直观，能够写成一些通用的方法会比较好

• 4.对于一些被修改的变量，要使用old

• 5.注意格式的美观性，注意写的风格

基本思路与体会

• 首先自己是先写代码再写规格的，这样做的确不太符合设计的初衷（但是不得不承认这样基本不会有JSF与代码不一致，以后自己会尽量改正，应该先去设计规格的）。

• 在写规格过程中，我可以说是花费了很长时间的，没有用过自然语言，每一个effects都是对应的修改一个个写了的，刚开始的时候还是很痛苦的，因为所做的比较机械化，而且比较枯燥，不过到后来，熟练了之后写的速度也就变快了很多，可以说也是有了进步吧。

• 经过了这三次作业之后，感觉自己最大提升的还是心态，看到周围很多同学都被扣了很多bug也看到了有的同学认真去找别人的bug，我认为这样的现状应该不是课程组所期望的吧，课程更希望的应该是同学们认真的去完成自己的作业，所以我并不认为这样的扣对方分加自己分是一个好的设计。我还是比较佛（fei）系（zhai）的，也感谢我的对手没有为难我。

• 最后感谢助教们辛苦的回答我们的问题，希望未来这一门OO能够越来越好。