oo第三次博客

Posted 2020-11-09 喝水水

技术博客

(1)

发展历史：这个问题我没有找到很近似的答案，但我知道既然能这么问那么规格的发展历史肯定很悠远。可以肯定的是，规格化设计是伴随着计算机软件技术越来越成熟的过程不断完善的，是程序员之间墨守成规的一种写法，在多人团队合作设计中非常有用。

得到重视的原因：设计者先把规格写好，交给开发者，开发者才能根据这个规格来进行代码的构造，这个在系统性很强的工程化开发中应该会很有效率，相当于用一种简洁的语言进行想法的传递。但在这次课程中用处不大，因为开发者和设计者都是一个人。

(2)分析规格bug

Bug编号	分支树名称	位置
0	Overview是否明确抽象对象	Request类27行
1	JSF不规范	MapReader类30行

(3)bug原因

0：手抖忘记写repOk方法了

1: repOK写成了reqOK方法

(4)

前置条件不好的写法

[email protected]:None 改进：没有前置条件就干脆别写了

[email protected]:this 改进：this！=null 或者别写

[email protected]:(A!=null);(B!=null) 改进： 写成&&

[email protected]: (0<=x1,x2,x3,x4<=100) 改进：分开写呗

[email protected]: \all String args[] 改进：没前置条件就别硬写

后置条件不好的写法

[email protected]:\all+自然语言 改进：全写自然语言

[email protected]:exceptional _behaviour:XXX 改进：明确产生异常的条件

[email protected]:\this  改进：直接写this

[email protected]:\result = a   改进：\result == a

5．@EFFECTS:(\result == a)==>(XXX)  改进：反过来写 不能因果倒置

(5)聚焦关系

方法名	功能bug	规格bug
ReadMap	0	1
Request	0	1
Run(Taxi)	3	0
FindShortestPath	1	0
InitCommand	1	0

(6)

基本思路

先写方法的规格 在脑袋里构造出一个大致的思路然后再实现。在实现的过程中一步一步再修改规格，对每一种情况做好容错的处理，所以基本上前置条件也不用写太多

感想

规格真的很麻烦 但是他对我们这些程序员来说非常有意义 我最爱写规格了 同时也喜欢仔细看别人写的规格 看看他写的代码是不是规格的正确形式 从中吸取经验教训 再看看能不能给他扣分 这样对于我oo课的成绩也有很大的提高 简直是一举多得。