OO第四单元UML做业总结暨OO课程总结

目录

目录1、第四单元UML两次做业架构设计第一次做业第二次做业2、架构设计总结与OO方法理解演进3、测试理解与实践演进4、课程收获总结5、课程改进建议6、尾声🎉

1、第四单元UML两次做业架构设计

第一次做业

　　第一次UML做业的文件树以下：

　　本次做业采用的是分离需求的设计思路，每一类需求整合到对应的类中单独存储，并配置修改和访问方法。

　　在顶层，实现课程组提供的UmlInteraction接口的类MyUmlInteraction只负责将UmlElement传入parser解析，并对外提供查询接口，剩下处理数据的任务交由parser完成。此外，在此类中还存放有全部UmlElement的查询表，并提供全局访问方法，经过id便可访问到对应元素

　　MyUmlClassMapParser类负责解析处理类图中的UmlElement，考虑到后续做业会新增顺序图和状态图的解析，故将其放在parser包中以便扩展。

　　ClassBlock类存放了须要查询的类/接口中的信息（名字取的很差。。把接口和类统称为类块了），其中包括：AssociationInfo（关联信息），AttributeInfo（属性信息），InterfaceInfo（接口信息），OperationInfo（方法信息），这4个需求信息统一归到infos包中管理。

　　对于用于查询的各个info类，存放信息使用的数据结构基本上为HashMap与HashSet嵌套使用，且在每一个info类中都或者存放有已查询过的confirmed数据表，或者是isConfirmed的boolean型确认表，其目的都是为了实现记忆式查询，如属性可见性、关联对端等需求的查询，在访问过父类后便可记录下结果，下次访问时就没必要再从新往深层探索，而是直接获取已有数据，这样就使得查询的速度会随查询次数的增大而加速。查询方法采用的算法基本为递归查询，以便在回溯时记录数据。

　　如下是本次做业的Uml类图：

第二次做业

　　第二次UML做业文件树以下：

　　本次做业大部分继承了上次做业采用的架构，改动的地方是除去了parse包，而将每种UML图的解析都归类到单独的包里，即classmap包（负责类图处理），collaration包（负责顺序图处理），statechart包（负责状态图处理），并将各个parser放在了对应包的顶层。此外，新增的checker包用于归类UML规则检查。

　　类图的处理在第一次做业中已经介绍，在此再也不赘述。顺序图的处理按照UML顺序图的分层方法进行了层次划分，Interaction类做为“画布”存储了核心的解析数据，如lifeline，message等（顺序图的画布Interaction“撞脸“了解析器的命名，因此在命名这一环节上处理得不太好），MyUmlCollarationParser提供解析数据与查询数据的接口。相似地，状态图的处理也按照UML状态图的分层方式进行层次划分，Region做为”画布“存储核心数据，MyUmlStateChartParser提供parser功能。

　　本次的checker包中只有一个MyUmlChecker类负责规则检查，一方面是为了方便，另外一方面也是做为UML类图规则检查划分到一个类中。若是后续有扩展需求的话，能够选择在类中添加方法或创建新的类，按照检查的维度进行划分。

　　如下是本次做业的Uml类图（与第一次做业相同的内容省略）：

2、架构设计总结与OO方法理解演进

• 第一单元：表达式求导

　　做为OO的最初篇章，脑子里对“架构”这两个字并无什么概念，对于程序的设计仍停留在分析需求、面向过程的编程思想上。固然，对类和对象概念的理解也促使着我在朝着面向对象的思惟方式上转变。

　　这一单元的三次做业采用了三种不一样的架构设计，但设计的思想都大抵一致，也就是将表达式逐层剖离至基本元，再进行求导。第一次做业只分离出了Unit做为最基本的求导元，没有考虑可扩展性，是为完成需求而设计，利用正则表达式对表达式进行拆分解析的过程也统一放在Expression类中。第二次做业的需求直接报废了第一次做业的设计，虽然还是用Unit做为基本元，但对这一基本元类作了重构，将其修改成三元组（x, sinx, cosx）的形式进行存储，本次做业作了一个新的尝试是将求导操做抽象为一个类，在计算时实例化求导对象进行计算。第三次做业的需求又再次颠覆了第二次做业的设计：三元组没法支持嵌套元求导，故又再次进行了重构，将表达式解离为多个嵌套表达式，而嵌套表达式又由多个基本表达式和嵌套表达式组合而成，并尝试抽象出了CombTerm和Term两个接口以显示本身有在学面向对象，当层次设计完成后，表达式拆分的目的地就比较明确了，求导计算就变成了自顶向下逐层完成任务的过程。

　　总之，第一单元的体会就是：次次重构次次爽。虽然说这一单元花在表达式解析和WF判断上的精力比较多，但其实面向对象的思想也有训练到，尤为是第三次做业，在设计好层次关系，理清各个层的职能以后，真实地感觉到思路清晰带来的爽快感。

 

• 第二单元：电梯调度

　　这一单元亲自体会到了多线程的“恶心”之处，但实际上在完成这一单元的训练以后，会发如今一开始架构设计的大路就已经被课程组铺好了，剩下的只是怎么在这条路上走出花样、走出水平。做为多线程和设计模式的零基础学员，只能老老实实循序渐进地“走大道”了。但不得不说的是，接触了设计模式与设计原则后，已经逐渐可以从面向过程的需求分析思惟，过渡到面向对象的架构设计思惟上去了。

　　第一次做业十分简单，老实按生产者-消费者模式代入便可安全经过。第二次做业加上了捎带的需求，仍然沿用生产者-消费者模式，改进的地方是引入缓冲区供捎带队列的获取，以及电梯内的捎带算法调整，感受此次做业本身的重点更多地放在调度策略的设计上，而对架构的考虑不是很充分。第三次做业使用了Worker-Thread加观察者的组合模式，即电梯做为工人获取请求并处理，调度器存储外部请求，并能够登记或移除电梯。对于换乘的设计，采用“换乘港口”的思路，将请求送至港口后就做为新请求送入调度器。

　　这一单元对设计模式的了解使得架构设计在必定程度上变清晰了（虽然内部调度处理仍是让代码变得很难看。。。）。对SOLID设计原则的考虑也进一步规整了设计，而不只仅停留在“完成需求”的要求上了。

 

• 第三单元：JML规格语言

　　这一单元的训练重点是JML规格语言的理解和代码功能的迭代设计（其实我感受重点更偏向图论和数据结构。。。）。不过令我满意的一点是，这三次做业的重构范围比较小，基本上是在沿用上一次代码的基础上根据需求进行增添，这或许是能力提高的一个表现？

　　第一次做业没有创新，只实现了官方的接口就能通关。第二次做业在实现接口的基础上增长了MyGraphCalc类用于处理图的相关计算。第三次做业按照功能将类划分入了三个包，即calculator，container和raildata包，分别表明计算模块、顶层容器模块和地铁系统中相关数据模块。计算模块负责图结构或地铁系统中的相关计算；顶层容器模块负责提供路径、图、地铁系统的修改与访问接口；地铁系统中相关数据模块将地铁系统中须要查询的信息分为几个模块（连通块、最少票价、最少不满意度等），每一个模块中完成指定信息的修改、存储与访问接口的提供。

　　总的来讲，这一单元算是复习了一遍数据结构和图论，但不知不觉地，本身也对架构的设计有了要求，而且这是一个良性的过程，设计考虑得越周到，编码消耗的时间就越少，bug也容易定位。

 

• 第四单元：UML图解析

　　这一单元的架构设计已经介绍，故再也不赘述。从第一单元的设计尝试，到第四单元认真地思考哪种设计能更好地实现需求，而且对可扩展性、耦合度、鲁棒性都有必定的考量，对架构设计的理解算是有些小进步吧。但要想设计出优秀的架构，如今的能力还相差甚远，还需进一步在练习中不断学习。

 

3、测试理解与实践演进

　　测试确实是软件设计中不可或缺的一个环节，每次做业看到中弱测全过期，心里就会产生一种错觉：个人程序已经没有bug了！然而强测一片红时又会开始悔不当初：为何当初很差好作测试？在一学期四个单元里，测试方法由肉眼法到写对拍器，再到Junit测试，算是测试实践的逐步演进。每次通过充分测试后，内心就会十分踏实了，而若是再被纠出bug，这些bug就再也不是粗枝大叶致使的bug，而成为值得回顾反思的“优质bug”。

　　第一单元对测试不是很上心，测试的方法是比较原始的肉眼查bug，不管是对本身的程序仍是互测屋中的程序，测试的精力放在输入输出的检测上，对于求导的逻辑就没有过多的关心。在第三次做业时实现了对拍器，算是测试方法的一种改进，但实际上有了对拍器后就更懒得看代码了。。。研讨课上同窗分享的观点值得反思：“互测的目的并非‘找到’，而是‘去找’。“

　　第二单元的电梯做业，因为是多线程设计，测试起来就更加困难了，在本身的程序测试中采用的是IDEA中自带多线程Debug方法。在互测屋的测试中实现了定点投放数据脚本，但没有实现对拍器和数据生成器，所以只能以肉眼观察找数据为主，定点投放为辅，配合使用进行测试。

　　第三单元真正接触了Junit，体验极佳！尤为是看到代码覆盖率和本身代码栏左侧密集的绿条时，心里十分知足安心。此外，写完Junit测试程序后，每次测试只需一键，很是方便，能够轻松定位到bug出现的位置，即便找到逻辑错误，进行必定范围的修改后，也一键测试也很方便检测这次修复的bug是否会影响到以前测试点的经过率，避免出现“修复1个bug长出10个”的状况。

　　第三单元还接触了JML规格检查以及JMLUnitng自动生成测试样例等JML有关的测试方法，这些方法虽然在理论上十分强大，但目前好像并非很“智能”，期待之后的发展。

　　第四单元的测试仍沿用Junit的测试方法，但发现写Junit测试程序也须要耗费必定的精力，尤为是在课程组提供官方接口的状况下，测试样例的编写就比较困难，也许是我尚未发现样例编写的捷径？

　　总之，在测试方面也算是有了些收获，也意识到了测试的重要性，往后还须要在这方面上下足功夫。

4、课程收获总结

　　本学期对于OO的训练量，说多也很少，说少也很多。很少的缘由是独立设计出的架构还远没有达到OO所要求的质量，很多的缘由是这学期确实在摸爬滚打中走来，也有了很多“本身的东西”。

　　从各个单元实际内容的收获来看，第一单元学到的是正则表达式解析表达式与表达式的处理，第二单元是多线程程序设计与电梯调度，第三单元是JML规格语法与图论，第四单元是UML模型的理解。经过对各类问题的分析，以及阶梯式的问题难度和测试，对于各种程序设计问题都有获得必定的训练。

　　从各个单元的设计目标来看，虽然没有彻底达到目标，但在接近目标的过程当中也有不小的收获。第一单元的目标是 “构造抽象层次，进行归一化处理“，在将表达式逐层解析的过程当中，也在锻炼将问题抽象分解的能力。第二单元的目标是 ”识别线程及共享数据，控制共享安全“，因为初次接触线程安全，即便通过三次难度递增的做业的训练，对线程安全的理解还只停留在比较基础的阶段，对一些线程控制方法并不能很好的融汇贯通，不过可以完成协调多个线程工做的任务，也算是一大收获吧。此外，设计模式的学习也提供了架构设计的模板，这些模板并不必定要生搬硬套，理解这些设计模式后相信对本身的设计能力会有很大帮助。第三单元的目标是 “根据功能须要适应性能要求的中间数据模型和协同架构”，第三单元虽然说是以JML规格语言为主题，关注的重点更多的是如何让本身的图结构算法不被RTE，三次做业依次地逐层构造以及复杂度的增长，对架构设计的可延续性与性能的考虑能力有所提高。第四单元的设计目标是 “针对诸多不一样类型的对象构造层次和关系，构造模型过程当中动态维护相关查询数据”，这一单元给出了各个对象原型，训练的是如何将这些对象按照其属性特征、功能结构进行分层、整合，从而更好地协同工做。

　　整体来看，这一学期收获到的是面向对象程序设计思惟与架构设计能力的入门卡。不得不说，一个好的设计架构所带来的编码体验是不言而喻的，体验到架构设计的魔力之后，将来对一份需求的设计就会更加上心，运用合理的架构设计思惟去分析需求所得到的效果。以及，课程收获到的仍是强大的抗压能力：中测wa掉一个不可见的点不管怎样都测不过，即便心态爆炸也要含泪继续debug；在有限的ddl以前若是架构崩坏，须要有狠下心重构的勇气；强测爆炸即便很沮丧仍要笑对bug修复。。。

 

5、课程改进建议

1. 指导书对需求的规定须要有一个时间点彻底定格下来，不然的话规则的任意修改不利于提前动工的同窗，容易引战。
2. 当程序代码量和复杂度增大时，互测屋的积极性可能会有所降低（尤为是我这种懒人。。。），虽然有着活跃度惩罚的威胁和优秀代码的吸引，但有时候实在没有认真翻阅8我的代码的动力。所以，课程组能够根据强测的结果，给出几个互测中的关注重点，这些重点虽然必定程度上下降了互测的难度，但同时增长了查看代码的效率与积极性，而不会出现看了几遍别人的代码逻辑毫无收获的状况。此外，互测关注重点还能够引入单元中的重点，从而让同窗们在翻阅代码的过程当中不断回忆单元重点内容，巩固提升。
3. 课程网站中将BUG修复的修复状况能够整理放在我的中心里面，而不是在BUG修复结束后只有”Bug修复已结束“几个字。。。这样在单元结束或学期结束还能够回味一番，总结踩过的坑点的同时还挺有乐趣:-) 虽然说这些bug总结工做能够私下在本地完成，可是有时因为时间缘由或是其余缘由也会致使这项工做不能很好地获得完成。总之，有个平台可以帮忙统计是一件提升学习积极性的事情呀！

 

6、尾声🎉

　　感谢老师、助教、讨论区大佬们这学期的帮助与贡献！祝愿OO课程越办越好🎈🎈🎈（这学期体验其实挺不错