OO第三次博客做业

面向对象第十二次做业暨第三次博客做业

1、探究规格化设计

　　1.面向机器编程

　　　　从最初的打孔式编程到汇编语言，本质上都是对人很不友好的面向机器编程，尽管汇编语言相对于二进制编码有了更高的可读性，可是由于不直观、最简单的逻辑过程也要编程者一步步紧盯着，很是容易出错。

　　2.面向过程编程

　　　　面向过程是一次思想上的飞跃，将程序员从复杂的机器操做和运行的细节中解放出来，转而关注具体须要解决的问题。

　　3.软件危机

　　　　如今咱们能借鉴的编程经验与约定俗成的习惯都是前人从经验与失败中总结出来的成功率更高的规律：

　　　　软件危机最典型的例子莫过于 IBM 的 System/360 的操做系统开发。佛瑞德·布鲁克斯(Frederick P. Brooks, Jr.)做为项目主管,率领 2000 多个程序员夜以继日的工做,共计花费了 5000 人一年的工做量,写出将 近 100 万行的源码,总共投入 5 亿美圆,是美国的“曼哈顿”原子弹计划投入的 1/4。尽管投入如此巨大, 但项目进度却一再延迟,软件质量也得不到保障。布鲁克斯后来基于这个项目经验而总结的《人月神话》 一书,成了史上最畅销的软件工程书籍。

　　　　第二次软件危机的根本缘由仍是在于软件生产力远远跟不上硬件和业务的发展,相比第一次软件危机主要 体如今“复杂性”,第二次软件危机主要体如今“可扩展性”、“可维护性”上面。传统的面向过程(包括 结构化程序设计)方法已经愈来愈不能适应快速多变的业务需求了,软件领域迫切但愿找到新的银弹来解 决软件危机,在这种背景下,面向对象的思想开始流行起来。

　　4.规格化设计的诞生

　　　　规格化设计不是一次就完整的提出来的，一套完备有效的规格化设计标准也有一个发展的历程：1960年代晚期至1970年代晚期的期间中，编程语言的发展也有了重大的成果。大多数如今所使用的主要语言范式都是在这段期间中发明的。在1960年代以及1970年代中结构化程序设计的优势也带来许多的争议，特别是在程序开发的过程当中彻底不使用GOTO。[跑题]在正式上大学学习编程以前就听过一个关于GOTO的段子，在一部各类编程语言拟人化的漫画中，C语言在田径项目中因为使用GOTO语句在前半圈领先众人（众语言），在最有一个弯道直接跳到了未定义区域冲出了跑道GG。

　　　　1980年代的编程语言与以前相较显得更为强大。C++合并了面向对象以及系统程序设计。在语言设计上有个重大的新趋势，就是研究运用模块或大型组织化的程序单元来进行大型系统的开发。这一阶段程序的模块化、标准化程度进一步提升。

2、做业中关于规格的BUG

做业	分支名称	错误位置	问题缘由
第九次做业	JSF不符合规范	Taxi.java	@和REQUIRE没有连在一块儿
第十次做业	JSF不符合规范	/	由于想写成标准的英文不使用天然语言，部分EFFECTS留空，申诉后测试者认同个人想法撤回了BUG
第十一次做业	/	/	通过三次重写，规格部分看起来好多了

3、分析BUG缘由

 　　在课程学习过程当中个人问题主要出如今两个地方：

　　1.开始时规格书写不规范

　　　　第一次没有仔细看JSF说明犯了不少错误…感谢此次的测试者没有在JSF上大作文章，而是很实在地经过一个bug指出了个人问题并给出了一些建议。

　　2.使用了天然语言描述

　　　　第一次时使用了天然语言描述，在OO第五次课上实验后，由于提供的代码中有不少规范的JSF书写，因此才学会了该怎么写，可是此时EFFECTS部分个人理解还不对，不少地方留了空，而且理解错了OVERVIEW的功能，幸运的是测试者理解、接受了个人想法，没有在JSF上扣太多而是把测试和讨论重点放在了代码自己上；后来在第十一次做业我也尽快改正了以上的问题。

4、条件写法的改进　　

 　　1.　　使用天然语言描述

　　改进方法：　　　使用标准的符号语言描述逻辑关系

　　2.　　“@ REQUIRES”中间留有空格

　　改进方法：　　改成：　　* @REQUIRES

　　3.　　误认为返回值void类型的方法EFFECTS能够留空

　　改进方法：　　像返回值为boolean类型的方法应有\result相关描述，void类型的方法的EFFECTS中若是不为null就将改变过涉及的类属性都写全；

　　4.　　线程安全的方法规格不完备

　　改进方法：　　

　　　　*@THREAD_REQUIRES: locked(this);
　　　　*@THREAD_EFFECTS: locked(m);

　　5.　　再简单的方法也要写完善的JSF，侧面说明另外一个问题

　　改进方法：　　某次测试中个人被测有几个功能很是简单的方法，只有一行return，可是没有写JSF，侧面说明另外一个问题就是各个方法之间功能性“不均衡”

5、分析汇集关系

做业	方法名	BUG	与JSF汇集关系
第九次做业	/	Request有一些问题	加了没必要要的线程锁，JSF冗余
第十次做业	serve	接单后没有暂停1s模拟上下车	主要是readme看漏了，JSF的EFFECTS部分也没有写全
第十次做业	setLight	在不合法路口设立红绿灯时没有给出输出提示	/
第十一次做业	/	/	/

 

6、概括总结

 　　由于陌生，因此会犯错；我比较幸运，遇到的测试者将测试重点放在功能上，只是在JSF部分指出我确实存在的问题没有把JSF当作刷分的工具。可是看到身边不少同窗被扣不少不少JSF，我内心仍是很难受的，教学团队为了让咱们重视规格因此将之加入了互测，可是即便设置了扣分上限仍是可能会受到不公正的待遇，每周四晚上十点点开oj就跟开奖同样，若是是两三个BUG，能够心平气和地把不合理的申诉了跟测试者聊聊天；要是一点开一片红，仔细一看还一大片JSF，能够洗洗睡了。平心而论我也由于互测好几回很生气，可是说实话没有想到更有效的让咱们重视规格化的方法，老师一再强调这东西有时比代码自己更重要，可是就算设置个OO期末考试也很差测试这个，就当是把期末考试那种瞬间的紧张和难受分摊到平时了吧。若是能够提建议的话，我以为OO第五次、第六次提供的代码中的JSF都写的很是不错，若是在第一次书写规格时就提供这些（标准的）代码做为参考的话，你们犯的错误可能会更少一些。

　　就我本身来讲，经过这三次规格的撰写，对于如何介绍本身的函数、如何确保个人类和方法有效有了必定的掌握，可是在读了一些标准库的代码后以为本身所写、所考虑的还有不少欠缺。