Uml单元作业架构设计分析
第一次作业架构分析：
类图：
总览图：
总结及分析：
此次作业的要求是查询给出的由uml类图解析出来的文件包含了多少个类，每个类的属性，操作以及操作可见性、关联对端、接口的实现和继承情况等等共计十条指令，因此在最初设计架构的时候我觉得把元素分成类和接口两大类比较合适，因此有了上图总览中的TryClass和MyIntergrace两个自己定义的类，分别用来实现类和接口相关数据的整合，这是一个总的框架，大致是把数据分散到不同的子树下，然后在MyUmlInteraction里面进行查询数据的操作，该类中只保存数据的索引列表。
在进一步实现的时候，我考虑到查询和存储以及时间性能的需要，决定在查询机制中采用电梯的调度策略，在进行一次查询的时候存储经过的所有可能被查询的中间值，这种策略相比于构造时一次性计算出查询结果，提高了性能，但也带来了代码量增大的问题，因此，我考虑到将MyUmlInteraction里面用于计算的部分也迁移到对应的TryClass或者MyIntergrace类中，将数据和查询部分彻底分离，但是考虑到代码已经基本完成，就没有再进一步优化，只是简化了MyUmlInteraction中的HashMap索引结构。
算法部分，一部分查询计算为了简化代码和电梯算法实现缓存的原因，采用了递归算法，最终问题也就出现在了递归算法上，也就是递归的起始，过程，返回与复原并没有处理好，导致出现了一些问题，该部分在下一次作业中受到了重视。
第二次作业架构
类图：
总览图：
分析及总结：
第二次作业在第一次作业的基础上增加了三条状态图的查询指令、三条顺序图的查询指令和三条规则检测，因此可以直接将第一次的代码复用。但由于规则检查需要用到第一次代码的一些数据，因此没有采用继承的方式，同时，又觉得改成数据和查询分离的模式更改部分太多，担心出现错误，因此，将部分第一次作业代码写入Lib这个类作为方法调用，同时在实现第二次作业的时候完全采用了树形结构，在作为查询类的MyUmlGenerallnteraction中只保存了用来检索数据的索引，方法直接调用对应元素类的方法，也就是计算只在MyUmlGenerallnteraction的下级进行，本级只进行单纯的查询操作。更改为这种模式的架构后，代码的解耦就很顺利，层层分离，对下级方法只需要传递元素的索引即可，层次比第一次作业清晰。
这种架构模式带来的体验就是，在修改代码时不会出现粘连的情形，逐行排查代码问题的时候也不会影响上层或者下层代码，不管是排查还是修改层次都变得很清楚，我认为是一个比较完善的架构。但存在的麻烦是，对于输入数据的处理没有解耦，依然是一个大块，这一点因为影响不是很大就没有解决。
四个单元架构设计及OO方法的理解：
第一单元作业：
虽然第一次作业历时比较就久远了，但依然给我留下了较深的印象。按照最后一次理论课的说法，第一次作业是逐步引入不同的项并且逐步引入组合规则，但是，我实际完成这三次作业并不是这个感受。第一次和第二次作业我的重点基本上都在正则表达式的运用上，之后对数据的推理和数据的处理反而在其次，第一次作业我甚至只提交了一个类就完成了所有的工作，根本不可能有什么层次化抽象和归一化处理，而且这一单元重点介绍的继承和接口在前两次作业中根本没有用过。
然后就是给我留下了深刻印象的第三次作业，从看完指导书到结束设计开始进入编码，这一过程我用了两天，也是这两天我基本搞懂了什么是层次化抽象，以及继承和接口究竟有什么用，而对OO的模糊认识也有了一个较大的飞跃，从一个文件一下子跨到了9个文件，开始习惯从逻辑上对需求进行分层和分类，而不是和以前一样直接开始写代码，边写边构思。
实际上这里我对OO和其架构设计的理解，基本就是从逻辑上解耦，以第三次作业为例，将式子拆解成一个个类别下的小块，然后小块将自己完成任务，也就是将信息分解并层次化，后续作业的架构设计基本都包含了这一设计思路。
第二单元作业：
第二单元引入了一个全新的概念，多线程。这一部分我觉得和我的相性相当高，可能是因为平常我就是一个比较喜欢同步做事情的人。这一部分引入的并发、调度等概念，以及观察者模式、工厂模式、生产者-消费者模式、订阅-发布模式、哲学家就餐等设计模式同时在多门课程上进行了讲解，包括C++、OS等，因此理解起来相对简单。
这一部分设计架构主要借鉴了这几个设计思路：1、寻找共享数据并将其与线程等分离；2、将属性与方法与线程挂钩，设计线程之间的同步和互斥关系；3、管理线程间的同步和互斥。架构的具体设计主要采用了调度器和电梯分离的模式，电梯只负责自己的运行，由调度器根据电梯的运行情况和当前用户列表进行分配。架构的具体细节上，以第三次作业为例，因为只有三部属性不同的电梯，没有采用工厂模式，而且因为是调度器分配任务给电梯，没有采用观察者模式，而是纯粹的信息传输的模式，而对电梯和调度的内部，架构只划分到了方法的层次，调度器的划分是根据功能，如分类、查询和搜索，电梯的划分是根据类别，上行和下行，这些划分的形式并不适合于扩展，但在代码的可读性和修改方面还是有一些便利之处。
而且，由于第二次和第三作业的区别不大，第三次的作业框架基本沿用了第二次，只做了一些适应性改变，对这次作业来说，架构的设计还是蛮合理的。
第三单元作业：
第三单元主要讲解了面向对象过程中的一个重要的方法或者说工具，jml规格。
这一单元的重点不是架构设计，而是如何读懂和根据需要写jml规格。jml规格对于开发人员和设计人员来说是一个非常重要的沟通利器，尤其对开发人员来说，jml规格减少了对需求理解的二义性。
所以我觉得这一单元对架构的没有要求，主要是感受jml规格的便利性和重要以及对jml规格的理解。
第四单元作业：
第四单元讲的是uml类图，对于程序设计上的侧重可以说很少，主要在如何使用uml绘图软件来完成程序的需求设计工作，架构方面还是采用了第一单元学习到的分类和分层的思想，主要的OO方法为逐步引入的uml的模型的理解、语义和语法规则、以及对uml图的结构化解析。
这一单元和上一单元类似，作业只是学习的辅助工具，是为了增加对uml图的理解而服务的，作业本身的难度比较低，重点在全面地理解uml图的元素含义及如何使用uml图来完成自己根据需求要实现的代码的层次结构和功能。
四个单元中测试的理解和实践：
四个单元过去，我的架构设计能力和思想可以说有较为稳健的提升的话，那么对于测试，我的提升非常有限。在第一单元的时候，我的测试主要是手动编写一些临界条件测试或者较为全面的功能普查性测试，这些测试的用处不小但都有一个较为局限的问题，他们都出自我的理解，也就是只要我考虑了的问题，那么我都会写对应部分的代码，因此我所谓的测试，其实测试的不是程序功能的面向需求的正确性，而是程序功能面向我理解的正确性，而我理解的正确性无法确保，这一问题到了第四单元集中爆发。其次，我没有像水群和讨论区中采用了什么对拍器和规格化单元测试对每一次作业进行测试，最多只是使用了数据生成器对程序进行了手动的较大规模的普查，而且在第二和第三单元的时候我对测试的重视比较低，也没有耐心对代码进行普查，因此有两次强测得了非常低的分数。到了第四单元，为了确保代码的正确，第一次作业我编写了较为完善的测试样例，有效果，但没有根治代码的bug，强测依然出现了小毛病，因此，到了第二次作业，我直接对代码挨行进行检查，效果个人认为比编写测试样例要强，但是比较费精力。
综上，我觉得日后对代码的检查，可以采用以代码逐行检查为主，样例测试和规格检查为辅助的形式。
课程收获总结
首先，这个课程带我了解了什么叫做面向对象编程。目前，我所认识的面向对象编程就是与以往的的编程相比，面向对象更倾向于在寻找解决具体问题的数据结构和算法之前，先对抽象的问题进行抽象的处理，也就是所谓的对象，然后在这个基础上，由上而下地逐步填满包括数据结构和算法在内的诸多层次。而以往的编程模式，有三个特点，第一、问题是具体而特定的；第二、对于程序地整体架构考虑较少或不考虑；第三、程序的体量小，独立性强。而面向对象需要考虑复杂、多样且抽象的问题，架构是必须考虑的内容，程序的体量较大而且程序之间存在逻辑上的关系。因此，这四个单元的作业带给我的最大的收获就是对面向对象入门级的了解和体验以及对架构设计的理解和重视。
其次，四个单元的作业也伴随了四个单元的测试，虽然在这个过程中我没有尝试太多的新的测试方法，但对于原本的以测试样例为核心的测试模式有了新的感悟，对测试样例的编写有了新的体会。同时，也确定了以阅读代码为核心的检查方式的必要性，
再次，这四个单元通过事实告诉了我一个人的力量是有极限的，尤其是第四个单元，如果不是水群里群策群力，讨论区里互相帮助，以及私下和同学的讨论，最后一次作业将会面临完全不知道指导书要求标准的尴尬情况，因此，团队合作是非常重要的，而且必须主动地寻求交流和合作。
最后，感谢这个课程告知的多线程概念，让我第一次明白了所谓的并行执行是怎么用代码实现的，补充了我对代码理解的局限，同时展示了代码能够实现计算机功能的一个新的领域。而在第二单元上手编写了一次代码，也让我对多线程运行有了真实的体会。
给课程提的三个具体改进建议
1、第一单元多项式求导的跨越性太大，从假期给的小的java程序体验题目到第一单元的继承多态封装等抽象概念的跨度太大，可以看出老师和助教希望通过三次作业实现过度学习，但是，我觉得这个过度并没有做好，变相导致第三次作业难度骤然上升。我觉得对第一单元的三次作业的要求可以提高一些，加入诸如必须使用继承、接口等的条件，以及可以把第四单元的uml类图部分提前到第一单元，作为形式上的辅助。
2、第四单元的指导书是希望同学通过解析uml图的元素来学习uml图的诸多含义和画法，我觉得这一部分单独放出来有些多余，不如放入第一单元作为辅助性工具进行学习，而把结构解析单独列出来作为一单元，解析更复杂的数据模型，作为学期总结把之前学过的继承、多线程等都用上，作为一个大作业来完成。
3、关于实验课，实验课的游戏体验非常差，上午刚听讲完下午就要尝试做，而且只有不到两个小时的时间，时间紧张，内容不熟，感觉完全起不到实践上午学习知识的作用，不如把实验课的内容放到课后作为课后作业，实验课留作课后作业的时间，也不需要要求同学必须到机房，而是自选是否到场，到场的同学可以向助教咨询问题等。
