总结本单元两个作业的架构设计
两次作业的架构都是在模拟类和接口的属性、行为、以及之间的关系的基础上进行的。
第一次作业
MyElement类，元素类，提供UML元素基本信息的查询，所有类均继承该类
- MyAttribute类，属性类，为类或者接口中的属性
- MyParameter类，参数类，为方法的参数
- MyOperation类，方法类，为类或接口中的方法；关联从属的MyParameter类
- MyContainer类，接口和类类，提供接口和类的共有属性和方法。
- MyInterface类，接口类，继承MyContainer类；在结构上关联从属的attribut和operation，在关系上关联继承的interfaces（支持多继承）和associationEnds
MyClass类，类类，继承MyContainer类；在结构上关联从属的attribute和operation，在关系上关联继承的父类、实现的interfaces和关联的对端associationEnds
之前看蹦迪大舞台的一条吐槽说，这单元的作业就是把树状结构的UML导出成线性结构，再让我们把它们重新建成树状结构，不得不说，除了接口多继承导致模拟类不太树但依然拓扑之外，老哥真是通透！
反思自己第一次的架构，发现许多类是没有必要的，比如处于结构最底层的MyAttribute类和MyParameter类，它们除了被查询没有更多行为，所以直接使用官方接口中的UMLAttribute类和UMLParameter类足矣。
第一次作业类图 第二次作业
第二次作业除了类图还增加了状态图和顺序图，所以则第一次作业的基础上新增了几个模拟类：
- MyStateMachine类，状态机类，关联从属的region和状态states
- MyRegion类，画布类，关联从属的states和transitions；由于本次作业不考虑嵌套状态，一个状态机只对应一个region，故MyRegion类可以省略，直接状态信息和转移信息关联到状态机类
- MyState类，状态类
- MyInteraction类，顺序图类，关联从属的lifelines和messages；事实上中间还省略了一层关系，另外，由于考期补天大业任务繁重，就没有细究attribute和lifeline的对应关系，直接根据数据认为lifeline与attribute一一对应
另外，由于MyClass类过于肥硕，以至于代码风格分再见了，于是通过MyExtendedClass继承MyClass将一个类拆成两个（丢人
实话拿到第二次作业官方接口的时候有些被吓到，此处马屁一波——架构真的重要，写接口的大大们头是真的好。有这么清晰的框架，此时不摸更待何时？直接按照同样的架构写就是了，爽。
第二次作业类图
总结在四个单元中架构设计及OO方法理解的演进
第一单元主要是通过多项式求导实践了继承父类和实现接口的应用。从第一次作业的类实现面向过程，到第二次作业通过继承第一次作业进行扩展，再到第三次作业接口统一大乱炖类的求导和输出，逐渐体会到面向对象“对扩展开放，对修改封闭”的含义，同时对类继承中父子类的共性与特性，和对方法的隐藏作用，以及接口对不同类的统一的作用有了基于实践的理解。
第二单元电梯多线程主要学习了通过对象锁sychronize实现多个线程之间的同步与互斥。明确了锁是加在对象上的，默认的wait和notify以及notifyAll操作把锁加在了this上，要通过"对象.wait"等实现将锁加在指定对象上。“A.wait”是使当前线程阻塞在A上，“A.notify”和“A.notifyAll”分别是唤醒阻塞在A上的任意一个线程和唤醒阻塞在A上的所有线程，然后这些线程再去争夺锁。另外，多线程判断语句一般用while而不是if。
第三单元基于指定JML规格完成路线查询程序。在这一单元的学习过程中，我掌握了JML的相关语法，并明确了JML的功能是规定方法的结果，而非实现；并总结出在编写JML时可以先通过数学推导对限制条件进行相应的拆分，比如“充分必要”可以拆分为一条充分条件和一条必要条件，然后依据拆分后的条件“翻译”JML，比较严谨和高效。
第四单元UML介绍了类图、状态图和顺序图，让我们在充足的时间中通过实践了解mdj文件的树形存储结构，并通过架构自己的代码解析别人的架构，在学习理论的同时进行实践，十分有趣。同时官方接口也给我们提供了良好的架构参考。
总结在四个单元中测试理解与实践的演进
第一单元时对课程的热情最高，测试的手段最原始。因为涉及多项式求导结果的验证，所以通过python编写检验程序，并结合手动matlab的方式进行特殊情况覆盖性测试，覆盖率可想而知的低，同时WF让人欲仙欲死。
第二单元多线程其实没咋测试，主要当时没有想到合适的手段，所以就手动造样例测试，基本上造一个炸一个，刺激。另外就是通过同一个测试点进行多次测试发现了一个锁加跑偏了导致线程不安全的bug。在研讨课上听同学分享多线程调试时多造几个同样的线程，通过增强竞争的方式测试线程安全，有点妙吼。
第三单元的测试学习了一波Junit，程序修改之后一键测试是爽的。
第四单元的测试甚至用到了美术功底，手造样例。极限数据是真的难造。
总结起来，我认为测试首先是在程序能够正确跑出几个小的常规样例的基础上，通过枚举边界条件进行定点爆破，然后再通过对拍程序扫射，如果程序能经得起这一番狂轰乱炸，基本上是稳了。从爸爸们那里py数据对于摸鱼蛙子来说也是不错的选择。
另外，就是测试态度的问题，在提交窗口关闭前测试不能停（发出马后炮的声音
总结自己的课程收获
在OO这门课我首先学习到了之前提及的架构设计及OO方法以及对测试的理解和实践，这些专业知识使我的程序猿素养不断提升，对之后的学业、就业都有可以预见的帮助。OO课程形式多样，包括老师授理论课、自己实践、同伴研讨、博客分享、互测在内的各种形式对我们各方面的能力都有要求，使我们在狂风暴雨中野蛮生长，幸好孩子是顽强的孩子。
三个具体改进建议
建议第一单元可以对性能的要求再弱一些，毕竟当时还是小白一个，架构一团乱还要想着提高性能是在有些为难。
- 互测屋的人数可以更有倾向性，比如想要学生通过编写对拍程序找bug可以人数再多一点，想要学生通过阅读对方代码找bug可以人数再少一点。
后两个单元的作业应用欠缺
课程中还存在许多问题，其中课程组时常咕咕的问题严重，比如第一单元WF问题，南湖捞人事件，第四单元数据限制咕咕等，整体没有计组严谨、体验感好。不过作为OO课程改革的第一批小白鼠对以上情况还是可以理解的，希望OO越来越好，学弟学妹们都能快乐OO哦~
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
