OO第四次博客作业

第四单元架构设计

本单元致力于实现UML解析器，深入理解UML类图。

这三次作业是层层递进的，因此直接分析第三次作业的架构设计。

基本上是按照官方包的要求设立了MyUmlClassModelInteraction、MyUmlGeneralInteraction、MyUmlCollaborationInteraction、MyUmlStateChartInteraction四个类，其类构造方法中实际上存在着不少的重复代码，理论上来讲是可以只设一个MyClass类来“生产”上述四个类。只是那样的话依然要另外设置不少的辅助类，例如实现顺序图的lifeline与状态图的statemachine等。

其中第三次作业懒了，增添的功能要求直接就并在主类MyUmlGeneralInteraction里头。理论上来说仍然需要新建另一个类来作为容器使用。

如此设计，则大量的解析与构造代码均被包含在各个类的构造方法之中。

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

是由面向过程到面向对象的转变。事实上目前的认知里私以为面向过程应当被包含在面向对象之内，也即是面向对象是面向过程之上的一种设计思想。无论是怎样的代码最终都必然会有具体处理的部分，在OO课程的学习之前，也即是过往的面向过程编程之中我们是直接对这一具体处理部分进行编写与操作，忽略身为执行者的“主体”部分，而面向对象则是强调了执行体，就类似于工作中指导下属工作时是直接找某项具体工作对应的人还是该工作对应的部门主管。

第二单元核心在于对于多线程的理解与实现，是多线程程序架构的典型范例。不同调度模式如集中式调度与分布式调度对于程序的不同影响，如何在架构上安全地实现自己的电梯调度算法都是需要考虑的核心问题。可以说如果第一单元更多的是类架构的体现，那么第二单元就是时序架构的体现。如何构造架构使得程序时序结构也达到优化，也是不可回避的问题。

而三四单元在架构设计方面事实上并没有太多发挥的空间，三单元是对于JML的理解，四单元天然存在类的划分。

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

第一单元主要采用手动构造数据样例+python自动评测机的方法对程序进行测试，该单元隶属于普通的静态测试，每一个特定数据点都会对应一个固定的输出结果。

第二单元主要采取了阅读代码与自动测评机的模式，由于多线程的不确定性，我结合测评机进行评测，同时，在阅读代码时，易于找出线程不安全的样例，这是可以构造针对性的数据进行测试。此外，对于死锁测试问题，阅读代码也是很好的方式，因为及时对锁进行跟踪，判断wait()相应的notify，以及主要当涉及多个锁嵌套的情况时，出现的虚假唤醒而造成的相互死锁的问题，

第三单元中主要使用了基于JUnit测试，自动数据生成器以及阅读代码的方法。例如， 作为白盒测试，JUnit测试使我懂得了基于规格的测试中，我们应该基于七个性质：一致性、顺序性、区间性、依赖性、存在性、基数性和时间性来开展测试。本单元的学习使我的测试手段更多样化与丰富。

第四单元主要采用手动构造数据样例的方式，鉴于本单元的特殊性，构造的过程需要辅助UML图，更加直观。总而言之，手动构造数据+恰当运用测试工具，具体情况具体分析。

总结自己的课程收获

收获最大的应当是第二单元对于多线程的学习与应用，这是之前接触很少的领域，特意找来了java多线程的课程学习，学习到了相当多的生产模式与多线程相关知识。

除此之外当数对于设计模式的学习，顶层设计与底层代码逻辑的配合，尽可能降低代码耦合度便于二次复用。

再者即是对于评测模式的优化，以往都是手动测评最多打表，经过第三四单元的学习后尝试着使用自动评测工具进行测试。

具体改进建议

1.个人不建议晚上关闭平台，有时白天属实没有空余时间。

2.三四单元作业的体验感事实上并不是很好。JML与UML对于我们理解代码，尤其是UML对于代码具体功能的理解有着不可忽视的精简作用，易于总结代码功能。JML理论上讲在实际工程中也应当能起到便于理解的作用，但实际上JML单元的作业更类似于填空题。