2020-面向对象第四单元-总结博客

本单元三次作业的架构设计总结

这三次作业完成了对uml核心图中类图、顺序图、状态图的解析，从零散的信息中找出联系，最终复原uml模型图，实现相关的统计查询功能，以及完成一些uml模型的规则检查。

第一次作业

第一次作业是完成对类图的解析，重要的是要理解各个元素的相互关联关系，以及层次关系。总的来说可以分为三个层次，类和接口在最顶层来统率下属的属性、操作、建立对关联、继承、实现关系的存储。能够利用的信息层次如下。

//level 1
UmlClass 
	_id 对应的是类的 id
	_type 对应的是该标签的类型，在这里对应的是类 UML_CLASS
	_parent 对应的是父类的id，如果是顶层父类，对应的是 UmlModel 的 id
	name 对应的是类的名字
	visibility 对应的是类的可见性
	
UmlInterface 
	_id 对应的是接口的 id
	_type 对应的是该标签的类型，在这里对应的是接口 UML_INTERFACE
	_parent 对应的是父接口的id，如果是顶层父接口，对应的是 UmlModel 的 id
	name 对应的是接口的名字
	visibility 对应的是接口的可见性

//level 2
UmlAttribute 
	_id 对应的是属性的 id
	_type 对应的是该标签的类型，在这里对应的是属性 UML_ATTRIBUTE
	_parent 对应的是所在类的 id
	name 是该属性的名称
	visibility 对应的是该属性的可见性
	type 是该属性的变量类型

UmlOperation 
	_id 对应的是该操作的 id
	_type 对应的是该标签的类型，在这里对应的是操作 UML_OPERATION
	_parent 对应的是所在类的 id
	name 是该操作的名称
	visibility 对应的是该操作的可见性

UmlGeneralization 
	_id 对应的是继承关系的 id
	_type 对应的是该标签的类型，在这里对应的是继承关系 UML_GENERALIZATION
	_parent 对应的是继承关系中子类的 id
	name 是该继承关系的名称
	source 对应的是该继承关系所对应子类的 id
	target 对应的是该继承关系所对应父类的 id

UmlInterfaceRealization 
	_id 对应的是接口实现关系的 id
	_type 对应的是该标签的类型，在这里对应的是接口实现关系 			UML_INTERFACE_REALIZATION
	_parent 对应的是接口实现关系中实现接口的类的 id
	name 是该接口实现关系的名称
	source 对应的是该接口实现关系所对应实现接口的类的 id
	target 对应的是该接口实现关系所对应接口的 id

UmlAssociation
	_id 对应的是关联的 id
	_type 对应的是该标签的类型，在这里对应的是关联 UML_ASSOCIATION
	_parent 对应的是相互关联的两个类中的其中一个的 id
	name 对应的是关联名称
	end1 对应的是其中一个 UmlAssociationEnd 的 id
	end2 对应的是另一个 UMLAssociationEnd 的 id

//level3
UmlAssociationEnd 
	_id 对应的是关联端的 id
	_type 对应的是该标签的类型，在这里对应的是关联端 UML_ASSOCIATION_END
	_parent 对应的是所在的关联的 id
	name 是该关联端的名称
	reference 对应的是该 UmlAssociationEnd 所对应的类的 id

UmlParameter
	_id 对应的是参量的 id
	_type 对应的是该标签的类型，在这里对应的是参量 UML_ParaMETER
	_parent 对应的是所在操作的 id
	name 是该参量的名称
	type 对应的是变量类型
	direction 对应的是该参量的传递方向，指的是传入参数或返回值

类图分析：

从类图分析中容易看出，建立了新的class、interface类来存储相关的信息（level2），其中class类相对复杂，因为查询都是与class相关，所以需要存储level2的属性，操作，该类的继承类，实现接口，与之关联的对端，而操作还需进一步存储level3的参数信息；interface类则相对简单，只需要存储它所继承的接口，其它在作业中无需体现的信息可以放弃。值得注意的是关联关系，比如类与类，类与接口，接口与接口都能有关联关系，父类的关联关系被子类继承等等，这些内容在吴老师的暖心贴中都能获得。

第二次作业

第二次作业相比第一次作业稍微轻松一点，只需要对顺序图和状态图的各3种元素进行分析即可。

顺序图
对interaction、lifeline、message三个元素建立层次关系，以interaction为统率，存储lifeline和message即可。
状态图
对statemachine、state、transition三个元素建立层次关系，以statemachine为统率，需要注意的是利用region得到state、transtion的爷爷（statemachine）。
类图分析：

整体来说，是继承官方包代码中的三个接口完成对各个类的解析，最后再聚合到通用交互类中；可以说，架构基本是基于官方包的这些接口，然后再实现了一些辅助的存储类，完成了这次作业。

第三次作业

这次作业增加对规则的检查，我的架构是将各个检查分别放在类图、状态图里面完成，而规则检查类与他们是聚合关系，通过将图对象传递进来完成对检查的调用。基本用到的方法都是bfs。

四个单元中架构设计及OO方法理解的演进总结

第一单元——表达式求导，我按照因子的类别建立相应的类来存储，对每个因子都覆写求导函数，总的来说算是比较好的完成了作业的要求，但因为我的方法主要还是针对作业需求进行的开发，如果再增加别的需求，也许需要再动动小手术。
第二单元——电梯多线程，这一单元开始有了迭代开发的味道，基本都能够直接延用上次的代码，而三次作业均死死抓住生产者消费者模式的救命稻草，也让我没有出现线程安全的问题。对调度的管理也较为合理，调度器与电梯分离，电梯只管电梯运行的事情，而送客则由调度器来操控，这样可以方便的改变调度的策略，甚至做三种不同的电梯策略一起使用，有一些模块化的思想。
第三单元——JML，这一单元的架构几乎是按照官方代码来走的，我所做的只是建立必要的存储容器，以及针对个别性能要求强的方法单独实现高效算法。
第四单元——UML，这一单元的架构是按照uml元素的层次关系构建的，每种图实现对应的交互接口，图内元素间建立由高到低的存储关系。
总的来说，相比第一单元的只为完成功能而实现的代码，后面的代码都有了一定的扩展能力，而我想这也正是OO迭代开发的意义，尽可能是以轻量级的调整算法来改变，而不是重量级的调整架构。

四个单元中测试理解与实践的演进总结

测试总的来说是使用随机测试，在本地跑比公测数据限制稍微更大的数据，与同学对拍或是程序的逻辑判断来验证测试是否通过。
前两单元，均是采用手动构造以及数据生成的方式来进行测试，在第三单元开始使用Junit对代码进行测试，一般是一些比较基础的功能测试，对于性能的测试还是通过手动构造特殊数据或是生成比数据限制更大量的数据来看是否满足时间要求。第四单元的测试只手动画了些图，做了很基础的功能测试，导致在第一次的时间上出现了问题。
在四个单元的学习后，我认为junit在规格化迭代开发过程中能起到很大的作用，积累样例，考虑边界条件，而对于我们的作业来说，有的时候还需要进行有强度的随机测试，二者结合，才能更好的保证实现的正确性。

课程收获总结

第一单元算是对OO的入门吧，也编写了较为复杂的第三次求导作业，掌握常用的容器以及java正则表达式的相关知识；第二单元则引入多线程，学习了多线程的相关知识，在实际作业中对生产者消费者模式有了较为深刻的理解；第三单元则学习了JML相关的知识，初窥规格化开发的形式，也学习了一些高效算法；第四单元，学习了UML模型，也在对uml信息复原的代码作业中更深入理解了UML元素的具体语义。
一学期的OO课程令我受益匪浅，从刚开始遇见OO的头皮发麻，到现在能够静下心来仔细思考迭代作业中需要的可扩展性架构，我认为我是有所进步的。而在四个单元的渐进作业中，也感受到了可扩展性架构的魅力，如果次次都是重量级的重构，那势必会大幅增加完成时间，而在可扩展的架构下，理解题意后能较为迅速的完成作业，并可以自由的替换一些性能策略。也感谢课程组的老师和助教，设置三次一单元的作业形式，单元里合理的需求扩展，让我们能体验到面向对象迭代开发的乐趣~~（苦中作乐）~~。

立足于自己的体会给课程提三个具体改进建议

就我自己的体会来说，我认为疫情背景下的OO体验应该算是较为良好的，因为少了一般专业课的学习，有了更多的时间花费在OO上，可以不急不躁的思考，查阅博客，与同学交流，最终完成一份有质量的作业。~~但感觉实验是真滴难顶~~
建议如下：

实验或许可以放在课下作为课后作业，感觉在短时间内要理解实验的代码又要完成相应的题目有些难度，作为课后作业则让我们能有更多的时间去了解实验代码的背景知识。
每单元的第一次作业可以稍微弱化一些难度，以帮助同学入门该单元为目的；或是在该单元第一次作业前进行一些小的案例训练。在多线程以及UML单元的第一次作业中均感到一些压力，一个是从未在代码层面涉及过的多线程，一个是元素层次没有直接讲明的UML，这迫使我在作业中将重点放在对所用到知识结构的理解，而疏忽容易出现的错误。
最后一个，对于互测环节，我想它的本意应该是阅读同学的代码，而不是一味的进行测试来找到错误，但在我的实际操作中，只读了少数几次的代码，复杂度稍高的作业便会存在读不懂他人代码的情况（当然我自己的代码别人也有可能读不懂）。也许在代码中写上一定的注释可以让同学之间更好的理解其编写意图。

线上学习OO课程的体会

线上课程还是挺棒的，可以选择自己喜欢，相对安静，注意力集中的时间观看网课视频，而在课后也有少量题目的问卷对整个授课内容做一些检测，遇到不会的可以立刻查看ppt，这帮助我更好的掌握课程内容。
研讨课相比以往我经历的课程展示，我认为是更棒的，尤其是一些印象深刻的展示，比如评测机的搭建、策略的分享、架构的设计、而且不懂可以询问同学，展示的同学一般都会很好的回答，或者老师也会给出他的意见。
线上学习OO的弊端就是遇到一些实际问题，很难与同学交流解决。上学期计组课设同学间可以互相讨论一些写法，以及具体的实现过程，而在线上，更多是微信的交流，有时效果不太理想。

这学期体验的两门课程中，OO比OS还是相对善良的,~~虽然写OO有时也感到痛苦，但想想OS，哦我还是写OO好了~~。

2020面向对象——收官