面向对象第十二次作业

面向对象第十二次作业

16061189 于金泽

1.规格化设计的历史

调研，然后总结介绍规格化设计的大致发展历史和为什么得到了人们的重视

在1960年代末至1970年代初期，出现了一次软件危机：一方面需要大量的软件系统，如操作系统、数据库管理系统；另一方面，软件研制周期长，可靠性差，维护困难。人们希望编写出的程序结构清晰、易阅读、易修改、易验证，即得到良好结构的程序。

这直接导致了软件工程的产生：软件工程诞生于60年代末期，它作为一个新兴的工程学科，主要研究软件生产的客观规律性，建立与系统化软件生产有关的概念、原则、方法、技术和工具，指导和支持软件系统的生产活动，以期达到降低软件生产成本 、改进软件产品质量、提高软件生产率水平的目标。软件工程学从硬件工程和其他人类工程中吸收了许多成功的经验，明确提出了软件生命周期的模型，发展了许多软件开发与维护阶段适用的技术和方法，并应用于软件工程实践，取得良好的效果。

---

1969－1972 C.A.R Hoare撰写了"计算机编程的公理基础（An Axiomatic Basis for Computer Programming）"和"数据表示的正确性证明"两篇开创性的论文，并提出了基于“前置后置条件”的接口规格方法的概念。

扩展Hoare方法的一个关键是将应用于函数的规格机制扩展到为类建立形式化规格，即利用前置条件、后置条件描述类的各个方法，并集成为一体表现类的行为。扩展Hoare方法的一个关键是将应用于函数的规格机制扩展到为类建立形式化规格，即利用前置条件、后置条件描述类的各个方法，并集成为一体表现类的行为。

1974－1975 B.Liskow/S.N. Zilles和J. Guttag引入了"抽象数据类型"的概念。

1976 E.W. Dijkstra定义了"最弱前置条件"的概念

1977 R.Burstall和J.Goguen提出了第一个代数规格说明语言：Clear

1988 Standford的SRI开发了代数规格说明语言OBJ3

1980-1986 C.Jones定义了VDM语言，也就是维也纳开发方法。

1985－1992 牛津大学的程序研究小组开发了Z规格说明语言。与此同时BP研究室开发了称之为B方法的面向模型的规格说明语言。

1985－1993 在MIT和Digital SRC开发了代数规格说明语言Larch

从1991年开始，面向对象的形式规格说明语言开始发展，例如，Object-Z, VDM++, CafeOBJ等语言。

1996－2000年 在欧洲CoFI（Common Framework Initiative）项目资助下开发"统一"代数规格说明语言CASL(Common Algebraic Specification Language)

2.规格bug及产生原因

• 按照作业，针对自己所被报告的规格bug以及雷同的规格bug（限于 bug树的限制，对手无法上报），列一个表格分析

​ • 规格bug类别（采用bug树上的名称）、每个出现所对应方法的代码行数

• 分析自己规格bug的产生原因

序号	规格bug类别
1	requires逻辑错误
2	modifire逻辑错误

bug1

测试者认为的错误

这里的require应该是传入数据的要求而不是结果吧

代码

    /** @REQUIRES: \result.equals(time是一个有效的系统时间);
     * @MODIFIES:  this.startTime;
     * @EFFECTS: \result == (this.startTime = time);
     */
    public void setStartTime(long time)
    {
        this.startTime = time;
    }

错误原因

复制粘贴的时候忘了改

bug2

测试者认为的错误

这两个方法几乎相同但是modifies却不一样

代码

    public void recordRequest(int requestNum, long time, Point src,Point dst)
    {
        synchronized (FileWriter.class)
        {
            try
            {
                ps.printf("Request:%d:\tTime:%d From:(%d,%d) To(%d,%d)\n", requestNum, time-startTime, src.x, src.y, dst.x, dst.y);
            } catch (Exception e) {}
        }
    }

    /** @REQUIRES: 0 <= requestNum < Main.requestHandler.threads.length;
     *               0 <= taxiNum < 100;
     *               time.equals(time是一个有效的系统时间);
     *               taxi_status.equals(出租车被派单时）;
     * @MODIFIES: this;
     * @EFFECTS: \result.equals(将被派单的出租车信息写入文件);
     * @THREAD_EFFECTS: \locked(\this);
     */
    public void recordGetRequest(int taxiNum, int requestNum, long time)
    {
        synchronized (FileWriter.class)
        {
            try
            {
                ps.printf("Taxi%d:\tGet Request%d Position:(%d,%d) Time:%d\n", taxiNum, requestNum, Main.taxiQueue.getTaxiPosition(taxiNum).x, Main.taxiQueue.getTaxiPosition(taxiNum).y, time-startTime);
            } catch (Exception e) {}
        }
    }

错误原因

复制粘贴的时候忘了改

后置条件写法

分别列举5个前置条件和5个后置条件的不好写法，并给出改进写法

功能bug和规格bug的聚集关系

按照作业分析被报的功能bug与规格bug在方法上的聚集关系

​ • 即给出表格：方法名、功能bug数、规格bug数

没有体会到任何功能bug与规格bug的相关关系。

由于在实际的完成作业的过程中，从第九次作业开始才加入有关JSF的内容，但是出租车的作业已经在第七次作业中定型，后续的所有作业都是在其基础上进行修改，因此，即使加入了JSF的内容，也只能是在已有的代码上，再次对自己的代码进行分析，然后按照代码写JSF，这与实际的过程应该是完全相反的。

由于第一次和第二次出租车分别对应的是第7和第9次作业，已经经过了两周的时间，所以在分析自己的代码并填写JSF的过程中，经常会出现自己在前期的设计中以及代码的实现过程中考虑到的内容没有在JSF中体现。

因此，在这几次作业中没有体现JSF和功能bug的关系。此外，由于互测中加入了JSF的内容，部分测试者选择放弃进行功能bug的查找，转而在JSF上吹毛求疵，凑到自己预期的加分数即完成测试。

感想体会

归纳自己在设计规格和撰写规格的基本思路和体会

1. 课上对于JSF的讲解完全不够，不知道怎么写，应该是怎么样的，而是“到时候会发JSF的说明，你们自己看就好了”一言以蔽之。但是JSF的说明中，只有关于JSF的内容而没有与代码的结合，并不能体会到如何将JSF与代码对应。而且经过一节课，然后就要求同学们能够完全理解并使用JSF，使用规格设计的相关内容完全是不现实的，只是加以介绍然后就要求完全掌握并能够给已有代码加上JSF的要求个人看来是难以理解的。

2. 在代码互测的过程中，由于已经经过了大半个学期的学习和段位的分配，测试者并不总能找到被测者的功能性bug，因此有些不友好的测试者选择转向更容易得到加分的JSF进行吹毛求疵、大量扣分，实际互测中的分数结果与课程安排的讲解之间完全不平衡，而对于规格的吹毛求疵而忽略了实际代码的功能和准确，我并不认为这应该是合理的课程要求。有关JSF的教学和理解，实际上是在JSF作业已经截止后的周五的OO上机进行的讲解，这基本上是我们第一次看到JSF应该怎么写、好的JSF是什么样的、代码和JSF的对应关系是什么样的？？？？？？？？？？

3. 个人理解JSF的实际作用应该是体现在大型项目的集体协作之间，而对于个人的小型项目的开发，由于个人有个人既定的代码风格和实现算法设计，因此，在代码实现的过程中如果自己能够添加足够自己未来理解代码、重构代码的注释，再辅以自行设计、自行论证过的算法，当然，出于互测考虑，不会在代码中附带完全的算法流程说明等内容以供测试者寻找bug，就我个人而言，在演草纸上有较为完整的程序框图等内容以供我后续理解等。互测并没有要求要让测试者理解自己的代码，而实际上也不会有人会“大公无私”地讲解自己的代码，反而会隐藏一些说明和测试用的功能，而这与JSF的出发点是相悖的，即使加上了JSF，也无法真正做到易于阅读代码的人理解。

4. 希望老师和助教能够明确作业指导书的要求，即使无法做到完全消除二义性，也请有统一的、明确的理解与要求，在有人提出issue时有明确、前后不产生矛盾的回复，而不是有人提出一个issue，说是不是怎么怎么做更好啊，然后就要求所有人按照他的理解进行实现。

   另外，也请维护一个实时更新的在线文档等，把所有的补充内容进行明确，在已有的基础上不断修改，而不是像现在这样，这种要求散落在各个issue、助教群回复等内容中，经常导致有些测试者死抠issue、面向文档debug，以及不同班级要求不同的问题，例如，对于红绿灯而言，有四个班要求所有红绿灯的方向一致，即所有红绿灯都为东西方向允许通过，而我们班的要求是所有红绿灯的变化时间一致，但是初始状态随机指定，即同一时刻有些红绿灯允许东西方向另一些允许南北方向。然后在和助教确认要求到底是怎么样的时候，助教回复“哦，readme“。

   强烈建议助教维护一个在线文档或者公开置顶的讨论帖，实时更新新增和修改的内容，以供助教自己和学生查验。
   

转载于:https://www.cnblogs.com/lafite/p/9108957.html