oo总结

dglr123 dglr123     2022-11-29     129

关键词:

OO总结

第四单元分析

问题分析:

本单元要求完成一个简易版的UML解析器,其中包括对UML类图、UML状态图、UML时序图的解析,这三者中难点在于类图的解析,需要全面地存储类和接口的相关信息,编写程序时会更进一步发现涉及到类实现多接口和接口的多继承是本单元的难点中的难点,关键在于不遗漏还有快速地查找到需要的信息。

编写思路:

编写思路分为两部分,主要程序架构和部分方法实现

本单元实质是对图的存储与查找,但图中的结点有“主次”之分,拿UML类图举例,最重要的UMLElement无疑是UMLClass,以其为中心,有UMLAttribute、UMLOperation等,还有UMLClass之间的关联和继承关系,UMLClass和UMLInterface之间的实现关系,UMLInterface之间的继承关系。基于这样的逻辑关系,本次单元我的设计思路如下:除Main类外所有类继承自UElement类,UElement类中有通用的属性并配置set和get方法,如下:
技术图片

设置通用类之后剩下的就要为有特殊行为的UMLElement设置专门的类,类图中有UClass、UInterface和UOperation,状态图中有UStateMachine、UState和UTransition,时序图中有UInteraction、ULifeline和UMessage。状态图和时序图无须特别说明,类图中发现类和接口有很多重合的地方,如都有属性和方法,都可以继承,可以互相关联,因此把这些共同点提取出来组成一个类UPoint,让UPoint继承UElement,UClass和UInterface继承UPoint。剩下的就是每个类中存储与自己有关的类,如UClass需要存储继承的UClass、有关联关系的UClass和UInterface、有实现关系的UInterface、UOperation、以及没有专门设置,由UElement代替的Attribute、AssociationEnd等。完整的UML图如下:

技术图片

MyUMLInteraction的构造方法中传入了一个UMLElement的数组,在构造方法中将两次遍历这个数组:第一次遍历,将所有的UMLElement转换为我自己的类,也就是UElement,并以id为key存储在一个HashMap中,id为key的目的是第二次遍历中查找方便,第二次遍历需要把每个类放到对应的“位置”上,比如遇到UMLAttribue,由其ParentId为索引找到一个UClass,把这个UMLAttribute(对应我自己的UElement)加入到UClass的为Attribute设置的容器中,第二次遍历还要将UClass、UStateMachine和UInteraction加入到以name为key的HashMap中,在方法中方便查找。两次遍历后还有一个dfs,以UClass和UInterface的topfather为起点,将父亲的方法和属性、关联的类和接口(以及实现的类)转递给所有继承意义上的后代。

第三次作业中重点在于前三个规则,R001难点在于理解其含义,真正理解后实现难度并不大,R002和R003都要dfs遍历且有些许不同。R002实质是找到图里所有在环中的结点,我采用tarjan算法,遍历中刚遇到某个结点时将该结点的low值设为dfn+1,遍历完该结点的子结点后若low<=dfn,说明这个结点在环中,就要放置到抛异常需要的那个set里。R003中由于类不会有多继承所以不用检查类,只需要遍历UInterface,遍历中把自身继承的类(接口)给子类(接口),然后看有没有重复的(之后发现这个方法很傻,只要看继承的数量就行)。

bug分析:

三次作业的bug都来自于类的实现多接口和接口的多继承上……

OO四单元总结

四单元架构设计及OO方法理解

面向对象程序设计无疑比面向过程程序设计更符合人们对于事物的认知,从而使程序员能够更好地抽出需要描述对象的主干逻辑,从而进行建模,进而一步步实现。四个单元的作业,使我对OOP的理解不断加深:

第一次求导作业,那个时候对继承、实现等概念还不太熟悉,但使用之后才发现:代码竟然还可以这么写!将三角函数因子、加法因子等的共同点抽离出来,之后只需要写不同的部分,如求导,就可以大幅度省去重复的代码,并且阅读起来体验更佳;第二次电梯,不得不说这个单元相当的经典,给人印象深刻,需要解决线程安全问题,这包括对synchronize机制的理解透彻,notify、wait等方法的熟练运用,还有高效、准确地调试,同时还涉及到调度算法,编写这一单元时就会触及到几个OO的设计原则,如是否需要设立一个“全知全能”的控制中心来调度其余的电梯线程,我一开始这样设想过,但是后续发现编写难度和维护难度超出了我的预期,遂中途放弃;第三单元JML建模,需要读懂每个JML规格描述然后从整体开始设计,最后逐一满足JML的要求;最后一单元又是一个综合性很强的作业,既要设计好整个的框架又要写出高效的查找算法,这四次作业无一不考研着编程人员对整个架构的把控,如果架构上出现失误,严重时可能将导致重构。总结下来,我对OO的理解便是:将需要描述的信息以“对象”的方式聚合起来,同时考虑到层次关系,将同一层次中相同的信息抽离出来放到更高层次,并通过继承来避免重复,优秀的层次关系能够更大程度上易于阅读,并在扩展时不修改原有代码。

测试与实践

经过一学期的学习,测试无疑是我最薄弱的环节,大部分是靠随机生成的样例进行测试,不能够突出重点,现有的很多测试工具,如JUnit,JML的OpenJml,听起来都很美好,但实际操作起来……

我现在发现很多测试问题都是形式化验证不充分,经常漏掉一些很难遇到的情况,测试了好多数据过了,然后中测过了,很开心,结果强测结果一出来瞬间傻眼了,后续学习的重点应该在于怎样有针对的进行测试。

课程收获

这门课的名称是面向对象程序设计,起初以为只是java,后续发现除了java之外能够学到很多意想不到的东西(奇怪的知识增加了.jpg)首当其冲的就是抗压能力,各个单元第一次作业都是最痛苦的,因为要充分理解这个单元的内容并设计出整个单元的架构,通常规划一堆东西,然后实现时总发现有各种各样的问题然后不断修改,并且要不断进行取舍,比如写法1可以让程序跑的更快,写法2更易于阅读,让程序更美,写法3又丑又慢,但是最好写,然后一看时间,当机立断选择写法3……(能跑就行.jpg)不断修改程序的同时与ddl进行斗争,有时会以失败告终,这时就要安慰自己,彻底放松一个晚上,第二天起来再慢慢改bug。

然后就是学会了使用很多小工具,比如python脚本,JUnit测试等等,还有学会了一些图论的算法,如tarjan。

改进建议

  1. 如前文所述,每个单元的第一次作业压力太大,既要理解整个单元的设计意图 ,规划好整个架构,还要作一些测试准备,而后续作业在不重构的前提下只需添加一部分内容,与第一次作业压力差距过大,但其实在题目层面上很难对这个问题改进,或许有可能把每个单元第一次作业的ddl延后?
  2. 每个单元的第一次实验安排在这个单元第一次课的第二天晚上,但是此时还来不及完成第一次作业,通常在学习的过程中光看理论只能有个大概的印象,只有做作业,在实践中才能加深对问题的理解,所以每个单元的第一次实验感觉都不太好,是否有可能将实验整体退后一周?
  3. 暂时没有更多的建议,那就希望课程组能够看到同学们的建议后能最大程度的改进,从而满足同学们的需求,带给同学们更好的OO体验。

线上学习小结

对我而言,线上学习的效果整体来说是不如在学校的学习效果,可以感觉到明显的差距,当然这也因人而异,对于我来说自制力偏弱,写东西时有意无意会拖延,并且在看理论课时容易走神,有些不明白的地方也就漏过去了,只有之后遇到问题时才会找答案,对自身的要求会不断降低,写代码前有很多预期,但写着写着就只管能不能出结果而忽视了架构(再一次 能跑就行.jpg)这个问题课程组对于课程组而言可能没有好的解决方法,只有期待能够早日返校了

结语

谢谢课程组一直以来的付出,正是有老师和助教们的不断努力我们才能有如此难忘的OO课,如果可以真想在学校上这门课。


oo第二单元总结

OO第二单元总结一、作业架构设计与分析1、homework51.1UML类图1.2UML协作图1.3架构设计请求处理方式在此次作业中我采用了生产者消费者模式,InputThread线程获取输入请求,再通过NewMainBuilding线程分发给各个楼座(SubBuil 查看详情

oo第三单元总结

OO第三单元总结JML梳理JML语言理论身为规格描述语言,JML有着严格的语法规范。注释行注释://@annotation,块注释:/*@annotation@*/方法规格前置条件(pre-condition):require后置条件(post-condition):ensure副作用范围限定(side-effects):assignable... 查看详情

oo第三单元总结

OO第三单元总结规格的阅读与实现心得JML的阅读方法语法上,可以参考课程组的《JMLlevel0手册》,涵盖了基本的jml关键词和语法,看不明白的话可以多翻翻,类比着就搞懂了阅读顺序上,阅读JML可以从一些比较底层的类开始读,... 查看详情

oo第四单元及课程总结

目录OO第四单元及课程总结架构设计四个单元中架构设计及OO方法理解的演进四个单元中测试理解与实践的演进课程收获课程改进建议OO第四单元及课程总结架构设计总体实现的类图如下总体思路就是功能的分发,由一个总类把各... 查看详情

oo第三单元总结

OO第三单元总结利用JML规格准备测试数据前置条件构造不满足前置条件的数据测试异常处理构造满足前置条件的数据测试正确性后置条件和约束条件用于判断输出结果的正确性利用JML规格的前置条件构造数据便于对所有可能的情... 查看详情

oo总结

第四单元总结homework13架构如下:复杂度分析如下:架构设计及OO方法理解演进从最开始的面向过程到进入第一单元开始注意对象实体之间的关系,以及为实体的属性设置方法等开始培养面向对象的思维,了解面向对象所包含的一... 查看详情

oo_unit4总结&课程总结(代码片段)

OO第四单元UML单元总结及课程总结OO_Unit4总结&课程总结本单元的作业是UML图的解析,作业的目的一是进一步强化架构设计能力,学会如何一步步将一个复杂的图结构进行多层解析。二是学习UML这一种强大的形式化语言,熟练掌... 查看详情

oo第二次课程总结

OO第五、六、七次作业总结一、第五次作业(一)多线程的协同和同步控制在第五次作业中首次采用了多线程的设计模式。多线程的设计使得对象的设计更具有独立的特性,但是在不同对象之间的交互也需要格外的注意。在此次... 查看详情

oo总结

OO总结第四单元分析问题分析:本单元要求完成一个简易版的UML解析器,其中包括对UML类图、UML状态图、UML时序图的解析,这三者中难点在于类图的解析,需要全面地存储类和接口的相关信息,编写程序时会更进一步发现涉及到... 查看详情

oo第三单元总结

oo第三单元总结一.梳理JML语言的理论基础、应用工具链情况(1)JML理论基础JML(JavaModelingLanguage)是用于对Java程序进行规格化设计的一种表示语言。JML是一种行为接口规格语言,基于Larch方法构建。一般而言,JML有两种主要的用法:... 查看详情

oo学习总结

第五次作业:多线程电梯多线程的同步和控制在本次作业里,请求发生器不断往请求队列里加入电梯请求,主调度器不停将电梯请求分发给从调度器,从调度器不断读取请求来操控电梯运行,因而这三者之间存在同步关系。请求... 查看详情

oo第三单元总结(代码片段)

OO第三单元总结前言?本单元中,初次接触到了TheJavaModelingLanguage(JML)这种语言,主要尝试了根据规格进行相应代码实现,及根据代码或需求抽象出相应规格的练习。从PathContainer,Graph到RailwaySystem,一路发展过来,在实现这些接口... 查看详情

oo第三单元总结(代码片段)

OO第三单元总结梳理JML语言的理论基础、应用工具链情况JML(JavaModelingLanguage)是一种行为规范接口语言,通过使用不会被编译的注释形式,和固定关键字的语法,指定Java模块代码的行为。大体上包括以下三种要求:前置:@requir... 查看详情

oo第一次反思与总结

...今天找到了一个能用的梯子才安装完插件。安装插件比写总结花的时间多太多了。  OO第一次作业可以说是让我一脸懵逼,毕竟在这之前从没有接触过java语言。语法什么的到还是小事,毕竟对于编程语言来说,学会了一种的语... 查看详情

oo第三单元总结

一、梳理JML语言的理论基础、应用工具链情况  JML以javadoc注释的方式来表示规格,每行以@起头。其中行注释为“//@annotation”,块注释为“/*@annotation...@*/”。  常用表达式有以下几种:  \\publicnormal_behavior:... 查看详情

buaa_oo第四单元总结——uml

BUAA_OO第四单元总结——UML被OO爱~~(折磨)~~了一个学期,终于要结束了,真的有些感慨。回顾这些博客和代码,也真的难以想象自己竟然写了这么多,虽然过程很折磨,但是最后还是坚持了下了,虽然在一次次的作业中我出现... 查看详情

oo第三阶段总结

一、规格化设计规格就是对一个方法/类/程序的外部可感知行为的抽象化表示,忽略实现的具体细节,使得设计与实现有效的分离开来。规格化设计的实现依赖于抽象化(Abstraction),包括过程抽象,数据抽象等等。使用规格化设计... 查看详情

oo第三单元总结(规格设计)

OO第三单元总结 一、关于JML  JavaModelingLanguage,即JML是一种规格化表示语言,主要用于对Java程序的各种方法功能的规范描述。这样做既可以给程序设计人员明确清晰的功能要求,又可以充分全面地验证已有的代码实现保证其... 查看详情