OO第九、十、十一次作业总结
一、规格化设计调研
发展历史
【背景·软件危机】
- 在20世纪60年代以前，计算机刚刚投入使用，此时的软件设计往往只是为了一个特定的应用而在指定的计算机上设计和编制，此时软件规模较小，文档资料通常不存在，很少使用系统化的开发方法，设计软件往往等同于编制程序。软件在这个时期表现出私人化的特点。60年代中期，大容量、高速度计算机的出现，使计算机的应用范围迅速扩大，软件开发急剧增长。高级语言开始出现；操作系统的发展引起了计算机应用方式的变化；大量数据处理导致第一代数据库管理系统的诞生。软件系统的规模越来越大，复杂程度越来越高，软件可靠性问题也越来越突出。原来的个人设计、个人使用的方式不再能满足要求，迫切需要改变软件生产方式，提高软件生产率，软件危机开始爆发 。
- 由于软件制造的难度陡然增加，软件制造表现出以下五大问题：1）软件开发进度难以预测 2）软件开发成本难以控制 3）软件产品质量无法保证 4）软件产品难以维护 5）软件缺少适当的文档资料
- 1968年，北大西洋公约组织（NATO）在联邦德国的国际学术会议创造软件危机（Software crisis）一词。而1960年代中期开始爆发众所周知的软件危机，为了解决问题，在1968、1969年连续召开两次著名的NATO会议，并同时提出软件工程的概念。
【软件工程】
- 在软件危机出现后，软件工程的概念应运而生。软件工程是一门研究用工程化构建和维护有效的、实用的和高质量的软件的学科。规格化设计便是软件工程中工程化的重要内容之一。
重要性
- 软件的工程量日益变大，完成一个项目所需要的程序员的数量也不断增多。如何合理有效让这些程序员更有效率的合作不得不议程。规格化设计相应地应运而生。规格化设计使得软件的逻辑更加清晰明了，大大增加了软件的可读性。由于规格化设计使程序员们之间的合作更加高效，因而便被广泛采用。
二、规格bug分析
表格分析
| 规格bug类别 | 出现位置 |
|---|---|
| 类规格缺省 | Controller类 |
| 类规格缺省 | transferspace类 |
规格bu*生原因
- 在编写类规格时误遗漏
三、前置后置条件分析
- 借昂神博客的话，只要搞清楚规格的作用与意义，很多问题就应该迎刃而解，无需举过多的例子。个人对此持同样的观点，相较于举出5个前置后置条件的错误不如对问题进行归类分析。
未注意隐式前置条件引自乔同
- 在书写方法的规格时，存在这样一种情况：虽然没有参数传入，但是方法内部使用类的属性
改正思路：明确类的属性的有效范围，添加至前置条件中
过多使用自然语言引自张少昂
*例如如下的代码块使用了自然语言，但完全可以通过布尔表达式表示。@effects: result will be the equation between a and b;
修改方法如下@effects: \result == (a == b);
语法表示存在改进空间
*对于某些JSF的写法，存在语义表达不清的问题，例如\result=a
- 该段采用=而非==，即对effect后应为布尔表达式的理解不清导致。
正确写法应如下所示：\result==a
四、功能性bug与规格bug的聚集关系
- 方法规格bug为0，无聚类关系
五、规格设计与撰写的基本思路和体会
基本思路
- 明确方法中出现的变量类型，确认局部变量、类的属性等，明确各变量的定义域
- 理解方法的功能实现
- 尝试用离散课上所学到的数理逻辑对自己的方法进行形式化描述
体会
- 在OO课程中，我可以感受到老师们想让我们明白规格化设计的重要性。但是在具体实践中可能存在如下问题。
1）课程时间较短，学生编程能力有限，无法在方法实现上较好的符合规格化原则，因而在JSF书写上便会相应地存在问题
2）JSF语法在实践中不清晰，存在百家争鸣、百花齐放的局面
我们可以理解，在工程化实践中规格化设计与实现是一件非常重要的事情，但是将这样的理念引入课堂之中可能还需要较多的改进才能更加成熟。希望OO课程越来越好。╮(￣▽￣)╭