OO第四次博客作业

课程总结博客

第四单元(UML)三次作业的架构设计

第一次作业

在写第一次作业的时候因为自己的一些原因，导致最后没能完成本次的作业，导致一次（当事人现在非常的后悔，希望大家引以为戒/(ㄒoㄒ)/~~）在课下的时候de完了自己的bug。

主要设计思路：利用Hashmap的结构，把所有的UML中的信息根据type的不同进行分类存储，这样在后续的判断的时候可以实现分类处理；同时将相关联的数据通过Hashmap的结构链接起来，其中主要的关系有如下的几个：类和属性的对应关系、类和方法的对应关系、方法和参数的对应关系、类和AssociationEnd之间的关系、类和继承的关系、类和接口之间的关系；用id作为索引，将和class有关的各种关系用Hashmap存储起来，方便后续进行访问；这些存储的工作实在初始化的时候就已经完成的，将数据分类。

用到的数据结构：在找一个类相关的的类、一个类实现的接口的时候用bfs进行查找，逐层的进行遍历；

难点：主要的难点在于将每个方法背后的所有的情况考虑清除，对类的继承和接口的继承均需要着重考虑，一下是我在做第一次作业的时候总结的一些可能出现问题的地方

1. 对classname的报错理解：classname只在一开始找数据的时候会关注该name是否重复，因为需要通过name找到唯一的id，在找到该name对应的id之后就不用管了
2. 指导书上没有说需要考虑接口的地方都不要考虑，接口是接口，关系是关系
3. 注意所有get的地方都是可能会出现nullpointerexception的，这个也是和我的存储形式有着密切的关系，需要对所有的get到的东西进行检查是否为空之后，在使用
4. 注意一个class中可能是含有多个同名的方法的，所以当涉及到按照方法的名称进行统计的时候需要分别进行计算，而不是算一个
5. 一个实现接口的方法他的_parent是接口的id；一个association附带两个associationend；类实现接口，接口之间的多继承，类是单继承的

第二次作业

本次作业和第一次作业的不同之处在于：添加了顺序图和状态图，以及一些最基本的查询操作

主要的设计架构：本次主要的设计架构是将不同的图分开，每个图分别管理自己的数据，最后用 Generalization将类图、状态图、顺序图链接在一起；采用这种设计架构的原因是三种图之间的交互非常的少，几乎没有，都是处理自己图内部的事情，所以适合分而治之；状态图和顺序图的存储方式和之前一样，采用Hashmap的方式进行分类存储。

主要用到的数据结构还是BFS，对接口的继承，状态的转移的处理。

本次作业问题总结：

1. 这是对状态图和顺序图分析比较好的两篇博客，适合前期了解（摘自讨论区），状态图：https://www.javaxxz.com/thread-367595-1-1.html；时序图：https://www.cnblogs.com/wolf-sun/p/UML-Sequence-diagram.html
2. 在求后继的state的时候，不能先把本身加进去然后再剪掉，因为再往后的过招的过程中自己可能会变成自己的后继state，形成一个环；本来是不包括自己，但是后来可以后继到自己
3. umlatrribute的parentid可以是不同的类型：既可能是umlclass，也可能是umlinteracion，也可能是实际没有的Umlcollabration（此时的atrribute数据是无用的数据），在处理的时候实际上正常存储，不需要特殊处理，因为没有parentid就不会访问到他
4. 第二次作业的目的是将类图、顺序图和状态整合在一个类中进行操作，比较建议的是将几个接口分别实现，然后在最顶层的General类中分别调用其他类中的方法，需要在顶层类中进行初始化和其他各种类的实例化

第三次作业

本次作业增加了对一致性规则的检查

主要的设计架构：和之前第二次作业的架构没有区别，实现最顶层的接口中对应的方法

UML图如下

本次作业问题总结：

1. R001：应该是一个class的成员属性和它的关联对端associationends之间不能有重名就，也就是说将成员变量和对端的associationends放在一起，相互之间不能有重名；一个类关联的对端包括继承的间接关联的对端；注意：可能会出现一个class的两个end对端的名称是相同的也是需要报r001的
2. R002：不能有循环继承，只需要考虑类的继承关系和接口之间的继承关系所导致的循环继承的问题（本质上找是否会形成环，只需要对每个class和接口进行可以用bfs遍历看是否形成环）
3. R003：类的继承不能重复，接口的继承不能重复，**注意：既包括直接继承也包括间接继承所以需要遍历一个类的所有父类，然后把他们期间继承的所有类统计起来，判断是否重复；对接口也是一样，需要考虑接口的多继承关系
4. R004：一个类不能重复实现同一个接口；注意：需要考虑类之间的继承关系、接口之间的继承关系、类对接口的实现关系
5. R005：类图的元素名字不能空，检查所有name不能为空的元素；因为associationend的name可能为空，所以在检查r001的时候遇到name为null就跳过

四个单元架构分析和OO方法理解的演进

第一单元（多项式求导

架构分析：多项式的求导对架构的要求还挺高的，前期的设计如果架构比较好的话，扩展性是比较强的，可以减少重构的概率，本单元的主要的架构是将一个求导的式子拆分成一个个项，在将项拆分成一个个因子，回归到对因子的求导，基于这个思路，对类进行划分，每个类应该包括对自己所负责的数据的所有的必要的操作，包括求导、乘等等，一个从上到下逐渐细化的结构。

理解感悟：在OO预习的作业无法整整的理解如何去解决一个问题，如果对问题中涉及到的东西进行合理的划分。在这个单元中，主要是学会了分而治之的思想，之后的作业中也同样适用，将输入、求导、输出分开进行处理，同时知道了如何对数据进行划分，将对某类的数据和处理的方法包装在一起，方便进行统一的的处理。

第二单元（难忘的多线程

架构分析：本单元是解决电梯载人问题，本单元的主要任务就是实现多线程，主要的架构设计是分成三个主要的线程，输入线程（专门的处理输入，可以使用缓存对请求进行存储）、调度器线程（主要是对从输入线程得到的请求进行划分，决定对应的请求应当分配给哪一部电梯，从而提高效率）、电梯线程（实现载人和放人的任务）；这也是分而治之的思想，我们将调度器与输入和电梯线程分开，一方面可以更好的降低耦合度，同时也能够对请求进行更好的划分，提高性能，同时对于每个部分来说只需要负责自己的那一部分即可，如输入线程只需要负责对输入的处理，将获得的请求加入到缓存队列中即可、调度器只需要负责获取请求分配请求、电梯线程则负责运送即可；这种架构的设计具有更好的扩展性，耦合度低；

理解感悟：本单元最令人印象深刻的当然就是多线程了，本单元，系统的了解了多线程的工作原理，有哪些常见的保证线程安全的方法，如何对多项成程序进行调试。再一次的认识到了分而治之的思想，不同的线程的划分，实际上需要我们在一开始对任务的这只能就行划分，每个线程负责自己的专一的的任务，通过共享对象的访问实现线程间的交互，所以总体来说学会层次化的思想很重要。

第三单元（JML

架构分析：本单元是学习规格化的JML的语言，通过阅读JML规格正确编写对应的方法；从架构上来说，本单元的架构是比较固定的，主要的架构已经设计好了，主要的任务其实是在规格的实现和优化上面。

理解感悟：规格可以很大程度上的通过严谨的方法表达自己程序的功能和指明方法的需求，通过本单元的学习我们了解了JML语言，对规格化的思想有了一个初步的了解，对动态优化以及各种数据结构进行了训练，对性能的要求较高，主要的任务在性能的提高上。

第四单元

前一个部分说了，在这里就不赘述了

测试理解与实践的演进

总的来说随着课程的推进，对问题的分析和解题的思路越来越清晰，不想刚开始的时候会感觉没有思路，对类的划分和数据的存储访问越来越熟练，实现起来也越来越顺手，但是debug总是少不了了，在自己测试的时候就需要关注边界数据以及进行必要的压力测试，（这里感谢hjw同学实力带飞），对于debug来说构造数据当然是必不可少的，一方面是自动话测试报错的数据，另一方面就是对边界数据的检验了。

个人感觉每个的单元的侧重点都有所不同，让我们对不同方面的知识都有所涉猎，但是有一些思想上的东西是共同的，例如分而治之的思想，封装的思想（将一类数据和对应的操作方法封装到一个类中）等等，这些思想可以给我们在架构设计、类的划分等方面提供一些思路。

学期收获

虽然在过程中有些遗憾，没能很好的完成这门课的所有要求，但是这不妨碍这是一门好课，在这门课上我从一个java的小白，到逐渐的理解java编程思想，称为一个入门级选手，还是很高兴的，在这们课上学到了很多，既涉及了多线程、线程安全、各种设计模式、架构设计思想，也对之前学到的DFS、BFS等数据结构有了更好的锻炼，掌握了一些基本的优化方法，如动态优化以及tarjan等优化算法；同时每一次的研讨课，不乏dl们给我们带来一些使用的方法和技巧，收获满满；讨论区同学们的积极交流讨论也让我对一些问题的理解有了新的思路。总的来说，OO带给我们的不仅仅是每周的紧迫感，更有在经历过后的成长，虽然这们课结束了，但相信从这门上学习到的很多东西将会让我们受益良多。