第三次OO总结

Posted 2020-11-09 challenging

规格化发展的历史

　　规格化的发展史说的宽泛一些其实就是软件工程的发展史.
　　1968年秋季，NATO（北约）的科技委员会召集了近50名一流的编程人员、计算机科学家和工业界巨头，讨论和制定摆脱“软件危机”的对策。在那次会议上第一次提出了软件工程（software engineering）这个概念，研究和应用如何以系统性的、规范化的、可定量的过程化方法去开发和维护软件，以及如何把经过时间考验而证明正确的管理技术和当前能够得到的最好的技术方法结合起来的学科。它涉及到程序设计语言、数据库、软件开发工具、系统平台、标准、设计模式等方面。其后的几十年里，各种有关软件工程的技术、思想、方法和概念不断被提出，软件工程逐步发展为一门独立的科学。
Edsger Dijkstra 于 1968 发表了著名的《GOTO 有害论》的论文,引起了长达数年的论战,并由此产生了结构化程序设计方 法。同时,第一个结构化的程序语言 Pascal 也在此时诞生,并迅速流行起来。

　　结构化程序设计的主要特点是抛弃 goto语句,采取“自顶向下、逐步细化、模块化”的指导思想。结构化程序设计本质上还是一种面向过程的设计思想,但通过“自顶向下、逐步细化、模块化”的方法,将软件的复杂度控制在一定范围内,从而从整体上降低了软件开发的复杂度。结构化程序方法成为了 1970 年 代软件开发的潮流。
1970年代和1980年代的软件危机。在那个时代，许多软件最后都得到了一个悲惨的结局，软件项目开发时间大大超出了规划的时间表。一些项目导致了财产的流失，甚至某些软件导致了人员伤亡。同时软件开发人员也发现软件开发的难度越来越大。在软件工程界被大量引用的案例是Therac-25的意外：在1985年六月到1987年一月之间，六个已知的医疗事故来自于Therac-25错误地超过剂量，导致患者死亡或严重辐射灼伤.

　　1993年，电气电子工程师学会（IEEE）给出了一个更加综合的定义："将系统化的、规范的、可度量的方法用于软件的开发、运行和维护的过程，即将工程化应用于软件开发中"。此后，IEEE多次给出软件工程的定义。

BUG分析

 

　　对于规格的bug, 由于刚开始对于jsf并不熟悉, 导致产生了一些语法上的错误, 或者是jsf写的不完整的问题.
甚至还有一次是因为粗心漏填了一点东西被别人找到了.
　　而对于功能性的bug, 出现这些bug的根本原因还是自己没有对程序进行完整和规范的测试, 导致被别人测出了许多的bug, 还有几个是由于自己对指导书没有认真阅读而导致的, 由于粗心没有注意到出租车只有在等待服务状态下才能抢单, 而我只是设定了接单的只能是等待服务状态, 还有一个是由于第十一次的指导书的状态编码和之前的有了变化, 自己没有认真阅读, 从而导致了错误. 虽然每次都被别人扣了很多分, 感觉很不爽, 却又找不到什么反驳的理由, 首先也有在自己身上找原因. 之前的几次作业总是让我抱着侥幸的心理, 从而导致了如此多的错误. 之后还是得严谨地阅读指导书, 对自己程序进行严谨的测试.

前置条件和后置条件不好的写法
1.
这是出租车run函数的jsf, 写得过于简略, 从jsf中并不能看出函数的逻辑.
/**
@Requires: None
@Modifies: time,dep,flag,path,status,position
@Effects: time==old(time+100), position==position.run()||position==position.randomRun();status==(WFS,SERVE,TASK,PAUSE)
*/

2.
Effects使用了自然语言描述, 不太规范, 容易产生二义性.
/**
@Requires: request!=null
@Modifies: taxiInfos,taxi.request
@Effects: distribute request to the best fit taxi

*/

3.前置条件的布尔表达式不够严谨, 夹杂了c语言的语法
/**
@Requires: int 0<=sta<=3, s=WFS||SERVE||PAUSE||TASK
@Modifies: this.sta,this.s
@Effects: this.sta==sta,this.s==s

*/
4.这个方法有try catch, 所以应该写清楚exceptional_behaviors, 这样effects才更完整.
/**
@Requires: in!=null
@Modifies: map,requestQueue,scheduler,map[][],taxi
@Effects: initial map, request, light and taxi

*/
5.没写清楚哪些变量进行了修改, 不够清晰明了
/**
@Requires: position!=null, request!=null;
@Modifies: this
@Effects: this.position = position, this.request = request
*/

心得与体会

　　这几次的作业难度上可能没之前那么高, 主要的训练重点放到了规格化上, 但是还是暴露出自己很多的问题, 其中最大的一个就是对指导书研究得不够透彻, 导致犯了一些很蠢的错误.
　　在规格的设计上, 规格的设计非常重要, 关系到自己代码的可读性是否好, 在拓展的时候是否更加方便, 在完成第11次作业的过程中, 也对继承的概念有了进一步的认识. 通过对jsf的学习, 也对规格的总结与概括有的新的认识.通过这几次的训练, 感觉自己的编程能力还是有待提高的, 尤其是对于一些细节方面的把控需要加强, 对于如何构造测试数据也需要多多构思.