OO第三次课程总结分析
OO第三次课程总结分析
规格化设计发展历史
在网上找了好久也没找到合适的信息，稍稍参考了同学的博客。大致如下：最初的的软件并没有形式化方法，随着软件工程的兴起，为了便于工程间的协调管理，人们提出采用工程方法来组织、管理软件的开发过程并深入探讨程序和程序开发过程的规律，建立严密的理论。随着时代的发展，软件的复杂度日益加大，结构化程序设计的缺点日渐暴露出来，面向对象设计由此产生，规格化设计进一步发展，这一次的规格设计可以更好地区分置换条件，以适应面向对象设计。如今，规格化设计基本完善，软件可以轻松实现跨平台、松耦合的开发需求。
规格化设计得到重视的原因
规格化设计可以提高程序的规范性、可读性，可以有效整理逻辑，避免出错；对类、方法等进行规范化设计，也有利于程序的模块化划分。规格化设计程序可以使得数据更加安全可控，也便于测试、维护程序，因而受到程序设计人员的重视。
被报告的规格bug以及原因分析
|
作业 |
bug类别 |
所在方法 |
方法的代码行数 |
bug产生原因 |
|
9 |
JSF不符合规范 |
readmap |
50 |
直接使用所给的例子，未进行修改，实际是不符合布尔表达式规范的 |
|
10 |
JSF不符合规范 |
readmap |
50 |
同上，直接用时忘记改了 |
|
Requires逻辑错误 |
readlight |
64 |
这个各个条件之间未用&&连接，不符合布尔表达式 |
|
|
Modifies逻辑错误 |
is_right |
25 |
Modifies不应该有方法内新建的变量 |
|
|
11 |
无 |
无 |
无 |
无 |
前置、后置条件不好写法及改进
前置不好写法：
1.直接用自然语言阐述
2.直接用自然语言阐述
3.没有使用布尔表达式
4.逻辑不够严谨
5. 对前置条件不做要求
前置改进：
1.换成规范写法
2.不使用自然语言
3.使用布尔表达式
4.使用规范语句
5.应该进行约束
后置不好写法：
1.使用自然语言
2.蕴含式不对
3.使用else
4.表述不规范
5.使用自然语言
后置改进：
1.使用比较规范的语言
2.改成正确形式
3.不使用else
4.规范表述
5.使用规范语言
功能bug与规格bug关系分析
|
方法 |
功能bug数 |
规格bug数 |
|
which_run |
2 |
0 |
|
WriteStringToFile |
1 |
0 |
|
readmap |
0 |
2 |
|
readlight |
1 |
2 |
|
is_right |
0 |
1 |
|
Vip_taxi |
1 |
0 |
|
service_shortest_run() |
1 |
0 |
|
reqok |
2 |
0 |
仔细分析似乎没有太大聚焦，毕竟是先码的代码再照着代码写的规格。
设计规格和撰写规格的基本思路
先写好规格确实能有效帮助实现和避免犯错误，从几次上机实践能深刻地感受到规格的强大作用，设计规格的基本思路基本上就是可以先构思好这个方法具体的功能是实现什么，会造成什么效果，然后可以推断要产生这个效果必须得满足什么条件，进行约束（当然能容错也可以不必），最后思考产生这个效果修改了什么数据，产生了什么副作用（个人想法）。
体会
写JSF要花上大把时间，不仅如此，还因为这些换来bug，实验课上收获的明显比JSF互测要多，通过实验课的练习，我觉得JSF能有效提高，但通过互测提高设计规格的能力确实不如实验来得实在。
