UML单元架构设计
第一次作业
这次作业中,大部分的查询是针对类所拥有的属性和方法而进行的,所以,首先建立了一个MyUmlClass类,对每一个umlclass都创建一个MyUmlClass对象。然后,将类图中类对应的属性和操作都保存在类图中。查询的接口类里,只保存这些对象,每次查询属性和操作时,先找到对应的对象,然后再调用对象的查询方法。同时,还建立了一张图,用于存储类图中各类的association关系,方便对association关系的查询。对umlInterface也是建立了一个MyInterface类,用于存储接口的属性和方法。在初始化各个元素的存储后,会先对接口进行父系的继承,存储到自己的对象中,然后,对MyUmlClass进行父类的继承和接口的实现,同样将属性和方法存储到自己对象。这样在查询时会很方便。以上所有类的具体存储实现,基本是通过HashMap,HashSet和ArrayList组合实现的。
第二次作业
这次作业,首先是对新增的顺序图和状态图新建两个类,来进行存储,并负责查询。这次作业的内容复杂性主要在规则的检查。针对rule1,是在每个MyUmlClass里面添加一个方法针对rule1进行检查。针对rule2,是通过在上次作业建立的树上,进行圈的检查。针对rule3,是在更新每个类的父类和接口时,进行检查,然后再遍历所有类,看是否有违背规则的情况。
OO课程作业架构演变
第一单元
第一单元作业,主要是按照面向过程的方法,基本是建立一个项类,存储单独项,并且建立求导方法。然后有一个表达式类,检查格式并对调整格式后的表达式进行拆项,前两次是按照加号拆项,第三次是建立了表达式树。总体来说,第一单元在逐渐对面向对象的原则和java的特性进行熟悉。
第二单元
第二单元作业,首先是建立了电梯类,调度器类,和接收器类,利用生产者和消费者模型,以及单例模型去解决,防止死锁的主要方法是通过synchronized 关键字来实现的。电梯类里下属着电梯车厢和电梯升降器两个类,用于控制楼层和人员的管理。当时,并没有对线程有更加深入的学习理解,导致调度方法都冗杂在run里面,调度节果不是很好,而且代码复杂度有点高。
第三单元
第三单元作业,主要建立了是建立了Path类,负责Path的查询和存储;PathContainer类对简单的Path相关内容进行操作,然后还有一个graph类,用于建立整个图的查询和更新。图的更新采用floyd算法,第三次作业中还使用了spfa算法来做部分预处理图,最后对色块的查询还用了并查集算法。这次作业,主要是增加了我对数据结构的理解和使用,以及对Hash容器类的使用。
第四单元
具体架构可参看前面,这次作业的很多存储容器设计都与上个单元相类似,用hash来提高查询速度。同时,还增加了对树和树的遍历的熟练程度。在架构上,更多是将每个类的属性和方法存在自己内部,然后关联交给图去管理,父类和接口,都是提供引用,然后在后续进行更新。
OO作业测试演变
第一单元
一开始,是手写测试数据,并手动输入测试;到第二次作业开始,搭建了一个简单的对拍器,用python的sympy进行求导结果对拍,但是依旧是手动构建测试样例。
第二单元
这一单元的课下测试,我主要放在了对死锁的测试上,导致对正确性的测试不够完善。对死锁的测试,主要还是手动构建样例,然后进行测试。
第三单元
这一单元的课下测试,是通过python构建的一个自动生成器,生成数据进行测试。但程序正确性大多还是靠自己手动构建数据测试。自动生成的随机数据主要是为了测试运行时间。
第四单元
这一单元,由于和烤漆基本混在一起,所以没怎么进行测试,第一次作业时,手撸了一个uml类图并进行边界测试,第二次就没有怎么测。
收获与体会
首先,对java的使用熟练程度增多了,对一些数据结构的组织和使用熟练了,对多进程机制有了了解。其次,对程序的设计架构,较之以往,有了更多的经验,并且对一些面向对象的原则有了更深入的学习理解。最大的收获,还是工程量的收获吧,一学期基本上每周都有着不小工程量的代码训练,导致现在的代码能力较之刚开学有了很大提升,并且也开始用面向对象的方法去思考设计程序。但是,在学习过程中,没有太敢于尝试学习一些课上没讲的东西,比如线程池。而且架构设计上,总是设计的没有完全跟上变化,总要修改一部分设计。以后,还是要在写代码前多多思考,并且在写的过程中,更加严谨一点,不能一味追求速度而不保证质量。
意见与建议
-
可以调整一下课程顺序,比如第三单元改为第一单元这种,将难度逐步提升,然后,烤漆前的作业再把难度下降,并尽可能避免烤漆的作业。
-
希望能多一些面向对象的架构设计的考察,比如像第三单元作业那种,可以感受到程序的迭代开发过程。主要是很多作业完全可以通过面向过程或者不那么OO的方式,强行莽完。然后,这门课就变得像一门学java开发的课。
-