OO第四次博客总结

Posted wjy21

tags:

篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了OO第四次博客总结相关的知识,希望对你有一定的参考价值。

    测试与正确性论证    

  测试是检测特定的目标是否符合标准而进行的验证,得出特定的结果。换句话说,测试就是在为代码提供了特定的应用场景,以一定的概率查找出漏洞或错误。它实施起来较简单,但覆盖率和逻辑完整性不如系统的论证。

  程序正确性论证是个偏公式化的体系,步骤严格精细,可靠性与稳定性更强,但操作起来具有一定的困难,尤其是面对代码规模稍大的方法,论证很难做到完整清晰,由此效果可能削弱。

 

    OCL语言    

  对象约束语言,简称OCL,是一种指示用户建模系统中的限制方式,可以用来更好地定义对象的行为,并为任何类元指定约束。

  特点:

  1. 精确,无二义性,易于使用和掌握;

  2. 规范说明性语言,无法表达有关实现的问题;

  3. 纯表达式语言,没有任何副作用;

  4. 类型化语言,每个表达式都具有类型;

  5. 不属于程序设计语言,不能编写程序逻辑和控制流程。

  标准类型的层次结构:

  技术分享图片

  OCL与JSF的相似处:

  1. 两者都有所谓的“前置条件”、“后置条件”、“变量”、“不变量”等;

  2. 表达相对静态的运行结果,而非具体的过程;

  3. 都不能直接用于编写程序。

  不同点:

  1. JSF是规格化表达,OCL已是独立的一种语言;

  2. OCL的表达式有具体的类型分别,且有专门的类型层次结构。

 

    UML    

  1. 类图

  技术分享图片

  2. 时序图

  技术分享图片

  3. 状态图

  技术分享图片

 

 

    整理总结    

1. 知识点关系

  第一单元——基础。伴随着正则表达式、扫描算法、抽象继承等知识的学习与运用,我们接触了较为简单的单线程程序设计。

  第二单元——进阶。在单线程程序的基础上拓展,设计多线程交互系统,了解并掌握线程安全的维护。

  第三单元——完善。对程序进行规格化整理,是工程化开发的前提。

  第四单元——总结。根据规格信息,以方法为单位进行覆盖率达标的测试和正确性论证,使程序的可靠性在理论与实践中都得到证实。

2. 程序分析

  本学期完成的程序任务主要是多项式计算、傻瓜单电梯、捎带单电梯、捎带多电梯、IFTTT和出租车响应系统。这其中难度跨度最大的是多线程电梯系统,理解困难细节较多的是IFTTT文件操作,耗时最多的也是这两次作业。能完成需求已实属不易,无暇再去考虑代码结构和效率,从最终呈现的结果来看,这两份代码的质量应该最低。不过由此积累的经验也让我在后面的多线程出租车系统中更游刃有余一些,没有遇到太大的困难。

  代码设计的提升效果应该最为明显,表现为从开始的“过程式”编程逐渐升级为真正意义上的“面向对象”,从对类概念的模糊不清到较为熟练地根据要求划分类别,均衡分配任务和设计交互等,不过在代码的运行效率和类嵌套方面还有很大的改进空间。印象最深的是对多线程中时间误差的处理,前几次作业我由于对需求和其余细节扣得太紧而忽视了这一点,忘记了规避误差实则是对于开发者基本而关键的技术要求。最后在测试者的提醒下改正,也算是一次有意义的互测体验了。

  测试方面,主要掌握了基于bug树建立大规模的测试数据、单步调试、通过测试线程进行Junit测试和覆盖率检查等技能。互测阶段,通过阅读陌生的代码了解结构后有针对性地设计样例也是不小的收获,对以后的工程开发有重要的意义。最后的正确性论证算是对以上所有工作的一个总结和梳理,让整个工程更加完整规范。

3. 关于工程化开发

  工程化开发有两个关键点:需求、多人合作。本学期的课程,让我们尝遍了这其中的滋味。“需求”是开发者和客户之间的交流,对应着我们与指导书。开发者对“需求”只有分析与处理的权力,所以就要具备自主提取有效信息,合理扩展,形成设计框架的能力。当然,“需求”也不是一成不变的。这种变化可能是“A->B”,可能是“A->A:xxx”,甚至有可能是“A:xxx->A”。开发者无法预测,只能随机应变,这就对程序设计提出了较高的要求:优良的设计可以轻松调整,不良的设计就会牵一发而动全身,更新效率低下,从而达不到工程开发的标准。

  “多人合作”是多个开发者之间,或者开发者和测试者之间的交流,对应着我与互测的同学。测试者发现程序的问题、开发者保证程序的正确都是各自的责任,也是获利途径。Readme与程序的规格的撰写,也是便于多个开发者之间的合作,理解他人方法的前提要求和预期结果,才能避免程序融合对接时的不必要错误。实际上,规格对于开发者本身也非常重要,能指导方法代码的完成、降低程序崩溃的风险等。

4. 课程建议

  记得课后投票中有这么一个问题:一定的oo基础是否对这门课有帮助?绝大多数人都选择了赞同度最高的答案。所以我第一个建议是给所有即将学习这门课程的同学:提前看看java吧。本课程对于面向对象语言的语法并没有过多的讲解(并没有反对的意思),基本是我们在编写程序的过程中自学,所以就会耗费一些查找和理解的时间。处理需求、设计算法就足以让人焦头烂额了,语法上有经验的话可以减小一点心理压力,对代码编写肯定也有好处。

  第二个建议是关于第二单元的程序设计。三周时间,分别是第一次多线程设计、从零开始的文件系统以及从零开始的出租车系统,现在想想真是地狱一般的滋味。难度大,时间短,这样被逼出来的程序能完整实现功能的就不错了,对于初学者来说根本没办法兼顾其他诸如体现“对象化”的思想、注意代码结构匀称和低复杂度等。对于编程难度我没有什么异议,主要是时间的安排上,如果能给初次的多线程设计多点时间,或者去掉某些不必要的任务匀出时间,也许呈现的结果就不会像第二单元总结时那么惨烈了。

  最后一点是关于助教答疑的部分。我们没有办法改变指导书的规则,但也至少可以要求解释统一吧。是否可以每次作业,或者每几次相联系的作业都专门安排一两个助教集中回答呢?且对于按班级分群答疑的措施我也不是很理解,如果仅仅是尝试的话,我想结果已经很明显了吧,希望课程组可以好好考虑一下对助教和学生都有利的方案。

  毕竟已经结束了,还是祝本课程越办越好~

以上是关于OO第四次博客总结的主要内容,如果未能解决你的问题,请参考以下文章

OO第四次博客总结

OO第四次博客总结

oo第四次博客总结

OO第四次总结博客

oo第四次博客

oo第四次博客