UML与学期总结
一.第四单元架构设计
第四单元是关于UML类图、顺序图、状态图的分析，官方包先将类图中的语言拆分成每一个元素，作业代码则是先获取所有元素信息，然后将每个元素信息整合形成一棵树，最后根据查询要求输出相应的信息。
这一单元代码并不难，在我的架构设计中，我是一边读入信息一边构造信息树，但是由于部分信息相对顺序无法确定，可能存在类似于成员变量信息出现但是类还没有构造过这样的情况，所以造树时会使用大量的判断条件(先读取所有信息并分类，再按照顺序建树方便许多)；按照要求创建了一个Kind类表示类或接口，创建一个Sequence类表示顺序图，StateMachine类表示状态图，完全按照逻辑意义建类，存储相应的信息。为了避免单一文件超过500行，将每个具体的方法写到所属的类中而不是全写在MyUmlGeneralInteraction类里面，这个类只需要存所有自创的类，查询信息时获取相应类，直接调用类里的方法即可。完全做到层层递进的设计，工程量相对而言还是比较大的。
二.架构设计和方法理解演进
第二单元和第三单元使我对于架构设计有很深的理解，第二单元第一次到第二次的过渡，只加一个捎带，由于第一次简单，我的架构直接将获取的指令传给电梯，电梯直接按照顺序执行，忽略了调度器，所以第二次我需要加一个调度器类对指令要求进行排序，然后传给电梯，整个架构完全改变，写了三四天才写完；第三次多电梯时，我只需要新开两个电梯类，再对调度器进行一个改写，将命令按照电梯种类拆分即可，工程量并不多，再多写一个拆分指令前一部分完成后唤醒后一部分命令的功能即可。
第三单元第一次作业完成后，后两次都沿用了之前的架构，基本就是三个类，Path一个类，PathContainer一个类，每次添加功能就在对应类中添加相应的容器和方法，每次工程量虽然不大，但是由于没有实现类的分层，导致最后代码形成了一种屎山，又丑又长，容器类中有将近20个方法，后来为了避免500行把类进行了拆分，虽然通过了强测，但是完全背离了oo课程的初衷。
总结
一个好的架构要考虑后续可能添加的功能，为其预留出空间，从而避免出现程序需要重写的情况发生。在大型工程中，代码量庞大，团队共同完成程序的编写，每个人的程序会相互影响，此时良好的架构尤为重要，当用户提出新功能时，只需要负责相应内容的成员进行完善，而不是整个程序重新设计编写，提高效率和收益，这也是架构设计员比程序员更受市场追求的原因。 在我以后的程序编写中，我会刻意培养自己在架构方面的能力，尽量做到类与类之间的分离，一个类只负责一种功能，并且为可能出现的情况预留空间，通过每次添加功能积累架构方面的经验；当然有时对于架构不能过分深究，有几个大佬作业中过度追求架构，编写时引入了大量的难题需要解决，最后甚至没法在规定时间内完成要求。还是应当通过大量训练去把握这个度。
三.测试与实践理解演进
第一单元生成数据不难，检测结果的正确性可以用类似matlab这样软件，比较困难的是生成不易发现Wrong Format这样的数据。
第二单元困难的是对时间的模拟，java和python都有对应的时间模拟库，但是需要自学，而且也会用到线程部分知识。最难的就是结果正确性的检验，不同的人调度设计不同，运行结果还不一样，所以还不能同学间对照。只能根据逻辑检验，比如电梯时间是否正确，乘客是否正确上下电梯，是否超载，拆分指令执行是否正确等，代码量着实不少。
第三单元结果的检测不难，因为答案是固定的，所以直接比较两份不同代码输出结果是否相同即可检验正确性；构造测试集会出现一点问题，如果完全的使用随机数生成测试数据，添加和删除路径指令还没有影响，但是查询的时候会出现大量的无效数据，检测的效率大大降低，即便结果一样也无法代表正确性，所以查询数据的生成还要使用记忆算法，尽量使得每次查询的数据都在容器中，保证测试的充分性。
第四单元检测跟算法关系就不大了，只能手动画mdj文件，命令行使用官方包对mdj文件进行解析，比较两份不同代码输出的结果验证正确性。可以保证检测的精度但是无法保证检测的广度。
四.课程收获
1.通过一门新的java语言学会了面向对象思想，相比于之前学过的计组和os，oo这门专业课的内容真正跟以后的工作相关，是以后工作的饭碗，所以这门课重要性不言而喻，通过每周一次小型工程的完成，不断强化设计架构——编写代码——修改BUG这一流程。oo中所有的内容都是助教和老师精心设计的，JML与UML是当前特别流行的与oo相关的两类内容，企业人员举办的讲座也能告知我们面向对象在工作中的使用，日后的工作中真正做到学以致用。
2.后两个单元涉及了图的知识，染色算法，floyed算法，bfs算法，dfs算法，迪杰斯特拉算法，并且作业对时间和空间也有限制，学习oo同时也复习了数据结构。
3.经历11周每周一次限时的作业，不仅增长了专业技能，同时更是对自身意志品质的磨练，中途想过放弃，但最后仍然坚持下来，这一段经历是我人生中宝贵的财富。
五.改进建议
oo这门课程今年是第一次改革，无论是题型还是评测机制发生了很大的改变，助教和老师为了给我们一个良好的体验经历付出很多，无论是课程PPT，还是每单元作业手写的官方包都倾注了大量的心血(虽然有时候会迟到)。规则从来都是不破不立，而我从这门课中收获颇丰，当然就我自身体验我还是希望提出几个小意见。
1.强测机制的改进
我记得第一单元第三次作业强测结束后，在水群中同学们发生了激烈的争论，焦点是对助教强测数据质量的质疑。强测结果存在两个情况：I.强测结果全对但是互测被发现出程序很大的漏洞。II.强测挂了几个但是程序只有一个小问题。
这样前者往往占了很大的便宜，后者则吃了亏，成绩上二者差距也会较大。当然互测结果也不可以和强测结果相等价，毕竟互测是精准打击，强测是随机的。为了解决这里的矛盾，我想到了一个方法：每次仍然先靠强测进行ABC分组，12点分组后前两个小时只显示分组信息(代码是封闭的)，这两个小时中每个人可以随机提交2组数据(盲狙)，不交视为放弃，这2组数据也会计入强测结果，hack成功奖励分也会比看代码的hack多，给每个同学强测他人程序的机会，这样即使出现前者那种情况也不会有同学抱怨，毕竟给过一个和助教平等的机会。
2.上机的改进
对于oo而言上机测验其实很难测出来什么，毕竟只有一个半小时，读题、构思、编写代码、修改BUG全部完成有点不太现实，像os和计组上机都是在原有框架上加几十行到100行代码，这种可行性较高，oo后面几次上机确实也是这样做的。但是每次上完机后，所有上机的资料都会被封锁(个人认为资料很有价值，都是助教总结的基础知识，PPT上又没有)，根本看不了，只有两次的实验数据在gitlab上是开放的，如果课上没保存课后就看不了(上机的时间又是有限的)，这样就没有了上机的意义，希望以后上机结束助教可以开放实验资源(即便不放题只放资料也可以)。
3.课程内容的改进
这一学期一共四个单元，每个单元采取3+1(最后2+1)的机制。我相信大多数人和我感觉一样，前两单元内容较难，后两单元新知识比较多，但是代码难度不高(如果没有过多涉及数据结构的话)。我认为学习JML和UML两个当前较为流行的内容是应该的，可是平心而论这里大部分都是概念，主要是靠记的，代码上体现不出来特别多的内容，相比第二单元多线程难度就是另一个高度，多线程的安全和程序结果正确性同时保证无误并不简单。多线程的掌握也是面试中重要考察方向，只有一个单元很容易遗忘。所以我的意见：将第四单元和第三单元调换顺序，然后JML这里将JML语言和多线程结合，不仅学习了JML，还可以复习和标准化多线程的内容；还可以用JML语言来规范一个程序的架构，让同学们亲身经历如何写出一个好的架构，而不是总停留于理论层面，给人一种可望不可及的感觉，当然这对于下一届的助教而言是个不小挑战。
4.展示课的改进
每两周的一次展示课，这是一个大家相互交流的平台，大佬展示分享经验的平台，但是对于展示的材料一定要严格审查，因为有些同学的展示内容实在没有营养，PPT质量差，完全是为了加分。我是诸老师班的，前两次的展示课对我而言内容真的很好，当时刚入门，大佬讲了如何写面向过程代码，如何初步架构，还有如何用IDEA本地调试(多种调试方法)，oo自带容器的区别等，这些内容我用了一个学期。但是后来有那么两次课，讲的是oo在一些工程中的使用(过于玄幻)，还有一些分享经验内容(比较鸡肋)，知识的梳理(知识点又特别简单)，体验不是很好。希望在展示之前助教能够严格审核，最好是助教能提出希望展示的内容，并且对PPT进行检查；再或者在群里同学们先提出希望展示的内容，让报名的人去准备，而不是为了高分去随便讲。每次同学展示的课件在网站平台最好也能进行更新，方便大家相互学习。
最后祝愿oo这门课能够越办越好，成为计算机学院的一个招牌，在此也感谢助教大大和老师们一个学期的辛勤付出。
