OO第四单元总结及课程总结
作者：互联网
OO第四单元以及本学期总结
经过一个学期的鏖战,终于迎来了OO课程的终点,中间还是辛酸,但是,收获当然不少.老师传授的面向对象的思想不能说百分之百get到了,但是说是完成了面向对象的入门大概不为过吧.从面向过程转变为面向对象的确会有阵痛,但是,熬过了之后,确实看代整个结构会有事先思考,建模的过程,可以说完成了思想的转变吧.不唠了,进入正题.
OO第四单元总结
第四单元完全是记录,检查,没有修改的操作,可以说是操作比较顺滑的一个单元了,大部分的需求都是增加的,对以往的需求完全兼容.因此架构的设计可以很好地迭代,没有太大的改动,都是增加模块就可以实现的.因此,三次作业的架构设计是比较固定的.
第一次作业
这次主要是实现类图的属性查询,进而了解类图在UML中的属性关系以及构成.由于UML的类图各种属性之间区别还是比较明显的,因此我设计了几个主要的类来分别管理类本身的属性,方法,父类;接口的继承关系;类之间的关联关系.
ClassManger主要是管理类本身的属性,方法,父类,由于类本身是由多种属性以及方法组成的元素,并且持有多个父类,在查询的时候可能会用到父类.因此,我选择将类的属性,方法,父类放在一起.将各种元素的id作为map的索引,构建一个专门的类信息的查询类.
InterfaceManger主要是管理接口的多继承关系,由于本次作业严格区分接口与类,并且接口的多继承与类的单继承有较大的区别.因此,我决定单独实现一个接口管理类(尽管只有一个查询方法).
AssociationManger主要是管理不同类之间的关联关系,由于类之间没有navigable属性,所有的关联关系之间都是互通的,即无向图的关系.这个管理类里面通过记录各个节点的连接节点,实现图的关系,能够查询联系的数量
第二次作业
这次作业主要是添加了对状态图的查询(主要是对状态图中元素和基于状态转移的图的遍历)
以及对时序图的查询(主要是对时序图中的元素以及转移状态的进出进行查询).由于内容与第一次作业相比改动不大,且内容相似,不再赘述.
第三次作业
第三次作业在原有的前两次作业的基础上添加了对UML图的合法性查询.同样没有对原有的设计有改动的要求,只需要添加检查的模块,增加相应的方法即可.实现中需要关注的是,有向图的环路查询(强连通分量),树形结构的判断.
架构设计及OO方法理解的演进
第一单元
(1)类(对象):面向对象的"对象",在面向过程的学习中是没有概念的(毕竟都是一个类就搞定了).面向对象中的对象思想,是我们首先接触的.现在想想,大概可以理解对象为一个有独立能力的拥有自己的数据和方法的,相对独立的个体.对于设计者,在对象内部,只需要考虑对象是怎么实现的即可(对象内部也可以构造对象,形成一个层次),对象外部,则主要考虑怎样使用现有对象,或者增加,或者删改.对象实现者主要考虑用户的需求,并且对调用进行一定的规范;对象调用者则需要以合法的方式调用对象,处理数据.
(2)继承,多态,接口实现初窥:面向过程到面向对象,一个重大的特点就是继承和多态思想的产生.对于一个类,想要复用它,但是又不想复制;或者想要规范一个类必须实现的方法,这两种情况下都必须实现依靠继承,接口实现.这种方法在开发迭代的过程中非常重要.
(3)架构设计:第一单元中,需求的迭代变化非常大,每次增加需求,都需要比较大的改动,乃至需要重构.对于刚刚上手的新手来说,确实比较痛苦.我记得我的第二次作业重构了,第三次作业做了大的改动,这些都很耗费时间.实际上,应该考虑未来的需求变动可以一定程度上缓解需要重构的现象.具体实现上,就需要划分层次关系,例如多项式作为上层,每一个项作为下层,每一个项又可以分为系数和次数部分,底数也可以多种实现,形成一个真正符合现实情况的模型,而不是为了方便而构造随意的模型,这种模型的适用性就很好.
第二单元
(1)多线程:尽管还是入门的难度,这个作业也足够将多线程"剪不断,理还乱"的情形表现出来了.多线程中为了防止多个线程同时访问资源,导致的切换时的错误,需要一套严格的互斥访问体系;另外,为了规范不同线程之间的运行顺序,也就是同步,也需要一套严格的唤醒,睡眠体系.这些都需要设计者进行设计,一个不小心,就会产生死锁,并且由于多线程的不可再现性,重复实现同一个错误比较困难.这些都给多线程的设计带来了极大的困难.
(2)架构设计:多线程中的架构设计需要更加考虑不同部件之间的先后协作关系,具体表现在实现中的利用睡眠/唤醒机制实现的线程同步.例如,当又乘客请求到达,应该先经过调度器,再通过调度器分配任务到电梯中进行实现,类似这样的前后顺序需要在架构设计中体现出来.
(3)提高并发度:对于多线程,要实现高效率就要实现尽量减少互斥锁的范围,因为互斥锁阻碍了其他线程的运行.另外,对于忙等这种极其消耗CPU的实现方法,也要尽可能的避免,能够睡眠让渡CPU的就睡眠,但是如果带着其他锁进行睡眠,也会导致效率低下,这一点要特别注意.
第三单元
(1)建模语言初窥:JML虽然是一款已经几乎没有得到维护的老旧语言了,但是,作为初学者接触建模语言,接触形式化验证的方法,它确实还是以其直观易懂,简单易操作的特性,得到了大家的认可的(在没有很复杂的逻辑的情况下). JML语言采用离散数学的表示方法,语义是没有歧义的,这是模型化语言相较于自然语言的巨大优势.另外,采用数学语言的表达甚至可能能够在数理逻辑上加以证明.当然,这些都是超过我们学习范围的知识,我们在这个单元中学到比较重要的理念就是产品的需求者如何与产品的开发者沟通.产品需求者可以通过前置条件,后置条件,不变式等对产品进行需求的要求.产品的开发者则可以通过解读语言,获得确定的需求,独立进行整体的框架设计(JML的实现只是抽象的,具体实现可以自己进行),将设计与实现分离的思想,可以在这个单元很好地体现.
(2)架构设计:本单元结构的迭代开发需求变动不大,大多都是增量.如果说确实有什么比较特别的话,那就是,千万不要照着需求机械地实现!人家叫你遍历你就遍历,效率绝对低下,需要自己设计实现方法或者设计层次架构.
第四单元
(1)UML:来了,统一建模语言,现在最主流的建模语言,能够表达类之间的关系,表现动态的过程,表现单个类自己的模式变化,当然还有很多其他方面的功能.总的来说就是,十分全面.你想要表达的逻辑意思,大都可以用UML表达,并且依赖UML甚至可以自动生成代码,自动化验证,功能十分强大.我们的学习中,主要是通过对UML中各个元素的关系,学习一个视图中的元素是如何构建关系的,构建了怎样的关系的.另外,学习解析UML图其实也是作为对UML图操作的开端,例如自动生成代码(尽管差得十万八千里).程序的模块化设计其实是可以先从UML开始的,尽管还没有加以实践(大部分模块设计都是手绘个大概的),以后还是要学会借助工具才行.
(2)架构设计:本次作业架构设计比较简单,没有太值得说的点.
测试理解与实践的演进
第一单元:生成的数据要贴合构建的模型,根据模型的层次构建数据的层次.具体来说就是,要生成一个多项式,就要先生成项,要生成项就要根据项的组成规律生成相应的系数,底数和指数.另外,生成的随机数据可以完全随机,前后没有顺序要求,因此可以以项作为单位,生成若干个项,组成一个多项式.
第二单元:生成数据不能一次性投放了,需要根据随机生成的时间戳投放,这就要借助python的包进行实现.但是,生成数据本身除了不能重名,时间必须递增外,没有太多的要求.由于本身特殊的要求,需要保证工作完成后电梯内没有人,以及符合一定的出入规范.这些都给评测机的结果检查提出了比较高的要求.
第三单元:统一的输入输出接口为对拍实现提供了可能,由于有唯一的结果,并且评测机如果自己生成结果,这也是实现者的逻辑.因此最好的方法就是对拍.初次之外,这个单元提出了另外一种验证的方式,就是基于JUnit的独立模块的验证.这打开了测试驱动开发,每写完一个模块就首先自己构造常规数据,边界数据测试一下,保证结果的有效性,虽然比较耗时,但是确实是保证逻辑实现正确的重要方法.
第四单元:第四单元与第三单元的总体设计还是非常相似的,真正实现检测还是要通过随机生成数据对拍实现的,但是由于实现过程中的约束.例如,属性属于类,方法属于类,继承关系,接口实现关系之间的约束,生成起来会有诸多限制,这些都需要注意.
课程收获
其实前面思想的演进,检测方法的理解实践都已经比较好地指出了课程学习的收获.在这里,就不厌其烦地再做一下总结吧.
(1)面向对象的思维:面向过程虽然思路清晰,但是一旦遇到复杂的情况,往往很难指出不同部分之间的协作关系,思绪非常混乱.面向对象则是更加具有逻辑层次性的语言,学会面向对象的思维,就一定程度上掌握了模式设计开发的方法,学会了模型设计的思想,学会了层次设计的思想,知道如何将功能拆散并且重新分发.对于对象,作为使用者,我们能够放心地调用它,作为创造者,我们要确保正确地实现它.这种分而治之,以不同视角看问题地方法可能是面向对象教给我的一个重要方法论.
(2)架构设计:从头到尾,课程一直都很强调架构设计,老师也说,好的算法和编程能力只能部分改善程序的性能,真正影响程序性能的是架构设计.架构设计好,代码动得少,真正优秀的程序员,动手之前都会好好设计架构.通过几个单元的学习,给我印象最深的还是一二单元的架构设计.第一单元的要求变化大,因为初期接触,也没有很好的设计概念,直接硬上,真的就磕得"头破血流"--第二次重构,第三次大改,开始对OO落下阴影.在第二次作业中,如何将请求分发到合适的电梯,电梯如何自行调度自己的调度队列,这些都需要设计实现,以便迭代.吸取了第一单元的教训,第二单元好好设计架构后也的确取得了很好的效果.
(3)多线程,互斥,共享:对于从未接触过多线程的人,从未知道还有这种程序内并发的操作.当然,多线程带来效率的同时,也对开发者提出了更高的要求,怎么协调不同的资源互斥访问更有效率,怎么唤醒和沉睡线程使得更少忙等.好比缠到一起的丝线,一不小心就会死锁,加之不可再现性,确实会在实际开发中比较头疼.
(4)建模语言:如何讲一个所有人都听得懂,没有歧义的话?如何模型化地表达逻辑?建模语言可以帮你.建模语言以其严谨性,可证明性被广泛运用.我们也在课程中学到了JML和UML两种建模语言,当然这两种建模语言还是有比较大的去别的,JML主要是数理逻辑地形式,对于复杂的关系需要构建多个中间层,可以对实现者和调用者都有一个比较好的规范.UML则主要是图形化的建模语言,更加直观,适用性更强,且可以通过不同的视图表达通过一个模型的不同方面,可以说是比较全面,有效的建模语言了.
(5)正确性测试:作为一款软件,最基本的就是得对,得准确.在我们进行作业练习的时候,也是将这个放在了首位,其次才是追求效率.在检验正确性的时候,一般选择有白盒测试,黑盒测试,进行迭代开发的时候还需要回归测试.白盒测试就是JUnit,这个在第三单元的测试中开始接触,虽然有点麻烦,但是,测试驱动开发还是可以很好地确保软件的正确性的.黑盒测试则主要在完成开发后,自己构造测试样例,然后对拍,或者自己构建正确性判断的模块.由于,以往编写代码的"面向评测机编程"失效了,真的测试还得靠自己.
改进建议
写之前,先吐槽一下,为什么非得三个...改进建议不敢说,一点小的看发还是有的,希望OO课程组的各位老师助教,能够姑且一听吧.
(1)讲课可以再有活力一点呀!虽然要求老师们太搞怪有点违背老师的严肃形象,但是,大家都想让上课更有效率一点嘛,能让学生爱听就再好不过了,对吧?这里我想"点名表扬"一下纪一鹏老师呀,老师可能和我们比较年龄相近,讲的都很接地气,少有的几节课是我听得最津津有味的了,老师们也可以稍微"俏皮"一点嘛.另外,诸彤宇老师讲的也不错呀!
(2)JML可以稍微缩一下,如果说课程有哪里比较不合理的话,第三单元大概算一个.第三单元其实是想让我们接触一下建模语言,了解一下数理逻辑表达的要求,但是,我个人觉得,好像用三周的时间学习确实有点长了.其实,可以稍微减少一下作业周数,毕竟后面的作业考察对图的算法的运用的性质更大一点.
(3)其实UML好像是会运用的非常广泛的建模语言,我觉得可以将第三单元的时间匀一点出来给第四单元,进行UML相关的其他教学,例如如何在编程中使用(尽管实验有涉及,但是我觉得强度并不够).
线上学习oo课程的体会
一个学期过去了,我觉得线上学习还是比较有效的吧(尽管以我看网课的速度从来没能在讨论开始之前看完),可以重复,可以暂停,每个知识点都能够好好地记下来,对我这种习惯记笔记的(经常跟不上老师记笔记),可以说是十分舒适了!但是,我还是得"自爆"一下,有时候偷懒,确实是会不按时上课,这也是上网课的弊端之一吧,还是希望以后能正经地上现场课吧,毕竟整个学习都没见过各位老师地"尊容"确实是有一些失落呢.
最后的最后,还得说一句,非常谢谢各位老师的倾囊相授,祝oo课程越上越好!
标签：总结,OO,建模语言,架构设计,实现,课程,UML,多线程,单元 来源： https://www.cnblogs.com/huge-fat-dragon/p/13154381.html