TDNss

  博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

一、规格化设计的发展

   程序规格化设计的发展史,我们也可大概从程序设计思想的发展史一探究竟。

  最早的程序设计都是采用机器语言来编写的,直接使用二进制码来表示机器能够识别和执行的指令和数 据。简单来说,就是直接编写 0 和 1 的序列来代表程序语言。例如:使用 0000 代表 加载(LOAD),0001 代表 存储(STORE)等。缺点就是写起来太过困难。

  脱离机器第一步:面向过程,面向过程是一次思想上的飞跃,将程序员从复杂的机器操作和运行的细节中解放出来,转而关注具体需要解决的问题。

  第一次软件危机:结构化程序设计,根本原因就是一些面向过程语言中的goto语句导致的面条式代码,极大的限制了程序的规模。

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

  从程序设计的思想发展就可看出,程序软件在复杂性和可扩展性的需求越来越大的情况下,程序变的越来越庞大,程序中每个方法的功能和条件以及对整个程序的影响就需要一种很方便的,让人一目了然的方式来表现出来。这样可想而知规格就诞生并得到了人们的重视。规格的好处是有统一的内容和撰写方式,方便人们对程序中每个方法的作用和要求显示地表示出来。

 

二、规格BUG分析

第九次作业

编号 规格bug类别 所在方法 方法代码行数
1 Effects不完整
TaxiMove(int i) 
18

 

第十次作业

  无

第十一次作业 

   无

 

规格BUG产生的原因

  首先,因为虽然规格指导书上书写了如何写规格,但是自己还是不太理解,导致书写的不规范。其次,由于是先写出代码再加规格,先后顺序导致自己写出的规格并不是那么完善。

三、前置条件和后置条件改进

前置条件

1.前置条件必须是布尔表达式

  @ REQUIRES:time is long type;   改:time == long type;


2.前置条件需要更具体

public void randomMove() {

/** @ REQUIRES:None;    改:nowP.x>=0 && nowP.y>=0;



3.前置条件需要具体,不仅要考虑数据合法性,还要考虑空指针的问题

public long sleepTimeCaculate(long t,int s) {

/** @ REQUIRES:None;      改:t!=null && s!=null;

 

4.考虑需要用到的某些属性是否已经被初始化

/** @ REQUIRES:None;  改:maps != null;

 

5. 对于数组,要对整个数组的合法性做判断;
/** @ REQUIRES:code is valid; 改: 0=<i<=99 => 0<=code[i]<=99;

后置条件

1.尽量避免自然语言书写
@ EFFECTS:设定车现在执行的乘客请求;
改:
   this.initial=initial;
   this.desti=desti;
   statu=2;

2.后置条件不能是None
@ EFFECTS:None;
改:
  if(i==1) nowP.y+=1;
   else if(i==-1) nowP.y+=-1;
   else if(i==80) nowP.x+=1;
   else nowP.x+=-1;

3.后置条件需要写多线程的内容

@THREAD_EFFECTS:None; 改:@THREAD_EFFECTS:\lock=();
 
4.后置条件可以对数组使用谓词逻辑
  @EFFECTS:设定taxi为正确的状态;   改: @EFFECTS:\all taxi[i].stats;0<=car[i].state<=3;

5.后置条件书写可以使用java中的方法来表示

  @ EFFECTS:计算还需要睡的时间;  改:\this.t==s-System.currentTimeMillis();

 

四、聚集关系分析

我的这一单元作业中主要有三个问题。

车并为按随机方向行走,因为没有确定添加流量和车判断行驶方向的先后关系。

出租车的初始化问题,因为对于出租车的中属性的初始化并不全面,造成了会出现空指针的问题。

出租车的时间最小单位为100ms的问题。

但是我的jfs并没有在上述的情况下报bug,究其原因,一部分原因是jfs是先于程序写成的,所以问题不容易被发现,其次是有一些是代码在多线程执行先后实现上的问题,jfs不容易检查出来。

五、设计规格和撰写规格的基本思路和体会

  由于代码的规格都是先写了代码才写了规格,所以对这一部分,我也只能讲一些微薄的见解。

  对于Effects,就是这个函数要实现什么功能,就直接写其实现功能。

  对于modified,就需要多考虑这个函数在执行过程中的影响。另外还要在函数写完以后再检查一遍是否考虑周全。

  不过虽然我是在写完代码后才写了规格,所以我也算是get到了规格虽然没了对程序书写时的规范作用,但还是能帮助我检查代码的规范性,这一点还是对我来说很受用的。

 

posted on 2018-05-30 00:50  TDNss  阅读(185)  评论(0编辑  收藏  举报