第十二次oo作业

作业十二

规格化设计简介

规格化设计的发展历史

1950年代，第一次分离，主程序与子程序的分离结构是树状模型，子程序可先于主程序编写。通过使用库函数来简化编程，实现最初的代码重用。产生基本的软件开发过程：分析—设计—编码—测试，使大型软件系统的开发成为可能。

1975—1980年代，第二次分离，规格说明（Spec）和体（body）的分离说明是类型定义和操作描述，体是操作的具体实现。（具体的例子就是C++,Java等面向对象语言的类说明与类实现的分离。）解决方案设计只关注说明，实现时引用或者设计体。体的更改、置换不影响规格说明，保证了可移植性。支持多机系统，但要同样环境。此时产生了划时代的面向对象技术。

1995—2000年代，第三次分离，对象使用和对象实现的分离基于构件开发：标准化的软件构件如同硬件IC，可插拔，使用者只用外特性，不计内部实现。Web Services：软件就是服务。分布式，跨平台，松耦合。

规格化设计为何得到大家的重视

一方面，规格化设计可以帮助开发者理清思路，构建一个写程序的框架，这样一来开发者可以按照既定的套路来完成自己的任务，从而能够摒弃杂念，提高效率。

另一方面，一个程序中很多代码会以一块一块的形式被反复使用，这些重复的代码块有可能被封装为函数反复使用，也有可能被放入库中供他人使用。如果能按照一定的规格去完成他们，那么调用者不必大费周折的去理解代码，可以通过已有的对于格式的学习以及清晰明了的格式来快速完成对代码的理解，从而提高学习工作的效率。

bug分析

第九次

BUG内容	BUG类型	BUG代码行数	BUG原因	方法名
程序无法运行	error	10	在main方法中未将所有线程start	public static void main()

无JSF错误

第十次

BUG内容	BUG类型	BUG代码行数	BUG原因	方法名
规格检查->没有写Overview	imcomplete	1	将Overview写在了每个方法前，而没有写在类前
是否选择流量最短的路径	error	1	忘记将上一次有车经过的边的流量加一	public void drive(int des)

聚集关系：无

第十一次

BUG内容	BUG类型	BUG代码行数	BUG原因	方法名
方法规格检查->JSF不符合规范	imcomplete	1	有的JSF中将==写为了=
缺程序设计文档	imcomplete	1	误解了指导书的要求，没有写程序设计文档
行驶一条边的时间不为500ms	error	10	因为程序采用系统时间，而且不能进行化整，故每过几秒程序会有几毫秒的误差

聚集关系：无

不好的写法

未按照要求格式书写

//错误
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :return flow;
 */

//改进
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :\result == flow;
 */

误将==写为=

//错误
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :\result = errorInfo;
 */

//改进
/**
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS :\result == errorInfo;
 */

使用自然语言

// 错误
/*
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS: 初始化出租车；
 */
// 改进
/*
 * @REQUIRES:None
 * @MODIFIES:None
 * @EFFECTS: \this.id == id;
 */

语句结束未加;

//错误
/**
 * @REQUIRES:this.repOK == true && edge.repOK == true
 * @MODIFIES:this.edgeNearBy
 * @EFFECTS :(edge.isLegal) ==> edgeNearBy.add(edge)
 */
//改进
/**
 * @REQUIRES:this.repOK == true && edge.repOK == true
 * @MODIFIES:this.edgeNearBy
 * @EFFECTS :(edge.isLegal) ==> edgeNearBy.add(edge);
 */

部分语句不够简洁

//错误
/**
 * @REQUIRES:this.repOK == true && taxiNumber >= 0 && taxiNumber <= 99
 * @MODIFIES:taxiCanTake
 * @EFFECTS :taxiCanTake.add(taxiNumber)；
 */
//改进
/**
 * @REQUIRES:this.repOK == true && 0 <= taxiNumber <= 99
 * @MODIFIES:taxiCanTake
 * @EFFECTS :taxiCanTake.add(taxiNumber)；
 */

思路和体会

这几次作业，我们的主要着重点在于程序的JSF规范，类规范上，这些虽然对于代码质量没有直接的提高，但是在我们以后开发大型程序，需要一个团队协作时，一个好的JSF规范，类规范，能够极大地提高团队协作的效率，能够从另外一方面提高代码，乃至整个团队的质量。

在我们以后的学习中，我们也可以保持书写规范的习惯，这能够极方便的与他人进行交流学习，降低学习与合作的成本。同时我们最好也在写代码前先进行规划，比如写JSF优先于代码实现，这样能够通过抽象出某一段代码的功能，提前考虑好程序各部分之间的关系，提高后续编写代码时的效率，提高代码整体的可读性。

转载于:https://www.cnblogs.com/AlbertShen99/p/9110609.html