BUAA_OO_2021_Unit3_Summary

Posted 2021-05-29 18231029

BUAA_OO_2021_Unit3_Summary

(1)总结分析自己实现规格所采取的设计策略

第一次作业

• 需要完成person，network和各异常计数类，由于逻辑不复杂，按照JML规格直接实现即可，第一次作业重点在于对isCircle和qbs的设计和优化；本人采用构建可达表，将信息以HashMap的方式存储起来实现，对于qbs，其JML规格为循环实现，而背后逻辑含义是连通分量的数目，可以直接维护一个整数值，在addperson和addrelation时更新即可，时间复杂度降为O（1）。

第二次作业

• 在第一次作业的基础上，增加了完全相似（实现上）的新的异常类和group，message类，同样逻辑不复杂，按照规格实现即可，第二次作业重点在于qqvs，与第一次作业的实现类似，在group类内部维护一些变量，在addtogroup和delfromgroup时更新（根据需要在addrelation更新），降低时间复杂度（空间换时间）即可。

第三次作业

• 在第二次作业基础上，额外增加了异常类和具体的不同种类的message类，按照规格实现即可，重点在于两点间最短路径的算法实现并且要保证时间复杂度不高，本人采用dijkstra算法，以HashMap的方式实现，开始并未构建优先队列，每次都以循环方式找到权值最小的边，为O（n）复杂度，而java本身含有优先队列的容器，通过简单的新类将person的id和对应权值value封装并改写compareTo方法即可利用PriorityQueue实现，大大降低时间复杂度。

总结

• 三次作业均按照规格实现即可，整体难度无论是架构还是方法的实现都不大，重点都放在对时间复杂度的处理上，要想获取时间的效率，（不考虑无用功）一定会以牺牲空间为代价，本单元的实现均按照这个思想，方式也比较简易。

(2)基于JML规格来设计测试的方法和策略

• 对于各类指令，可以简单覆盖性构造测试来验证基本功能，这方面是相对不容易出现bug的；而三次作业hack核心都放在时间上，可构造大量如qbs相同指令不断查询来放大实现中可能有的时间上的效率低下。

• 测试是十分重要的，一方面测试数据的构造与对问题思考本身就是强相关的，另一方面测试数据也可以从问题的逻辑角度抽离出来，构造完备的测试集对于程序算法的验证角度是独立和不可或缺的。

• 由于本单元作业的逻辑并不复杂，且整体架构完全已由JML规格给出，所以本人测试的构建仅包含了上述两个方面。

(3)总结分析容器选择和使用的经验

• 三次作业均主要使用HashMap，HashSet容器，少量使用List（仅在getreceivedmessage方法用到）和PriorityQueue（用于优化）容器。

• 从图论角度看本单元作业，person类是整体的基础，而每个person可由其id唯一决定，故以HashMap的方式不仅方便索引，而且逻辑上可以涵盖所需要的功能实现。

(4)性能问题分析

• 本单元在第二次作业的强测和互测中因超时被hack（性能问题），bug是第一次作业中实现的方法qbs，本人实现是构建可达表reach，以Hashmap的方式实现，对于每个person都构造id-HashSet（id）的键值对，在每次addrelation时需要更新被关联的各person的HashSet，具体实现为先更新某一person的HashSet，由于被关联的各person的Hashset是一样的，故对该person的Hashset内元素对应的person的各Hashset同步为该Hashset即可，本人初次实现为HashMap的addAll方法，会有线性的时间复杂度，因而导致超时，而更改为put方法，O（1）复杂度，修复了该bug。

(5) 架构设计梳理

• 对问题本身的深入思考是能写出好的架构的第一步，同样的，把握住问题的核心点，解决问题的方法自然会是最简洁高效的。

• 本单元作业的抽象架构并不复杂，而且与已给出的JML规格基本一致，只需要在实现上具体化即可。

• 图模型的构建与维护主要依赖person类，其实现为每个person节点包含了与其关联的其它person以及衡量关联程度的权值value，而对于可能会需要的图的应用，该构建包含了图的全部信息，故从逻辑上是可以实现任何可能的功能的。