其他分享
首页 > 其他分享> > BUAA-OO-Unit4-UMLparser&courseSummary

BUAA-OO-Unit4-UMLparser&courseSummary

作者：互联网

第四单元--UML解析器 & OO课程总结

目录

一、第四单元架构设计

本次作业的要求是实现一个UML解析器，对于从mdj的输入转化成建模好的UML图中元素这一步，课程组已经帮我们完成，我们需要完成的，就是把离散的、单独的UML元素按照UML规定的结构建立层次关系，从而实现对UML图的各种查询指令。总体上来说，本单元作业难度不大，但是细节颇多，很容易陷入细节，常常为在什么细节上翻车而担忧，有些头疼QAQ。

1.1 第一次作业

本次作业实现了对于UML类图的解析，主要架构如下

这一次作业就是按照UML的类图模型对UmlElement进行建模，由于mdj文件的输入顺序是随机的，而层次之间有依赖关系，因此我通过多次循环的方法，先读入后续元素依赖的元素。并且尽可能将无关元素在一次循环中都处理，尽可能减少遍历次数，最终的读入顺序在第三次作业架构中呈现。

通过采用HashMap，保存一个id->element的映射，这样在查找元素的时候，时间复杂度较低。

将这些elements层次化建模之后，再在Implementation中调用各个类各自的查询方法就可以比较容易的实现要求的指令了。

1.2 第二次作业

本次作业实现了对于UML顺序图和状态图的解析，主要架构如下

本次作业添加了UML顺序图和类图的解析，总体上和第一次作业差不多，都是根据UML规定来对这些element进行层次化建模。

本次作业的FinalState、PseudoState、和普通State是三种不同的element，但它们在状态图路径查找中的性质又是类似的，因此我将他们重新包装，并让它们继承自MyGeneralState，这样在写判断是不是关键状态的时候会简单一些。

另外，为了MyImplementation不超过500行，我将最初建模相关的实现都转移到了Creator中。

1.3 第三次作业

本次作业是添加了关于UML图合法性的检查，与前几次不同的是，这次作业的输入中有可能有循环继承的情况，并且由于我之前的addSuperInterface和addInterface都是通过递归实现的，如果含有循环继承，那么就会出现无穷递归的问题，因此在这两个方法中需要稍作修改，维护一个变量将已经访问过的class或interface标记，以防被重复访问导致无穷递归。

同时，为了避免MyImplementation类过长，本次作业添加的关于规则检查类的实现，都放在了Checker当中。

最终的读入处理顺序如下

public void loop1(UmlElement element) {
    element instanceof UmlClass
	element instanceof UmlInterface
	element instanceof UmlStateMachine
	element instanceof UmlCollaboration
	element instanceof UmlAssociation
}

public void loop2(UmlElement element) {
	element instanceof UmlOperation
    element instanceof UmlAttribute
	element instanceof UmlRegion
	element instanceof UmlLifeline
	element instanceof UmlEndpoint
	element instanceof UmlAssociationEnd
}

public void loop3(UmlElement element) {
	element instanceof UmlGeneralization
	element instanceof UmlParameter
	element instanceof UmlPseudostate ||element instanceof UmlState ||element instanceof UmlFinalState
	element instanceof UmlMessage
}

public void loop4(UmlElement element) {
	element instanceof UmlInterfaceRealization
	element instanceof UmlTransition
}

public void loop5(UmlElement element) {
	element instanceof UmlEvent
}

二、四个单元中架构设计思维以及OO方法理解演进

2.1 第一单元

第一单元的主要架构设计思维是层次化，将表达式中的元素进行分层抽象，对具有某些共同性质的元素统一编写方法，并且要求这个抽象可以尽量经得起多次迭代增加需求的考验。这个单元最重要的任务就是对表达式进行层次化的抽象和储存，找到元素之间的共性，比如常熟因子和幂函数因子实质上可以统一成 常数*x**指数的形式，各种复杂的包含三角因子的项可以统一成常数*HashMap<三角因子/x,指数>的形式。如果建立好了层次化模型，并且将每个层次需要完成的工作都设计好，那么在需求增加的时候，可以几乎不用改变架构，即可取得不错的效果。

并且这个单元非常好的体现出了面向对象程序设计的特点：封装，继承，多态。在面对复杂的情景时，利用封装将问题转化成更加容易的小部分，利用继承来使代码得到复用，利用多态来让不同的类可以部分拥有相同的性质，有效降低了设计和编码的复杂度。

2.2 第二单元

第二单元的任务主要是学习多线程程序设计的基础知识，并掌握线程安全控制的方法。在这次作业中，我体会到了好的设计模式带来的便利。例如本次作业中，我采用了生产者消费者这一设计模式来保证线程安全，将保护线程安全的任务仅交给充当buffer角色的类。在设计buffer时，集中考虑线程安全问题，这样在设计生产者和消费者时，就完全不需要考虑线程安全问题，设计起来就非常流畅顺利，不会因为担心线程安全问题而被打断思路。并且如果线程安全出了bug，直接检查buffer类就可以，并不需要在各个类中四处寻找bug，这让debug效率也变高了。事实上，采用了这种设计模式，就几乎没有出现过线程安全的bug了，这部分时间精力就可以用来优化性能啦。

这个单元第二个重要的任务是保护电梯的状态转移正确，我学会了采用状态模式来设计电梯的行为，这样只要保证状态转移不出错，状态转移的条件不出错，那么整个电梯的运行也不需要过多的担心。

2.3 第三单元

第三单元由于总体架构已经被安排好，因此本单元的重点是理解规格化，形式化的表达。形式化的表达让信息传递的细节更加准确，但同时也增加了阅读和理解的成本，可以说是有利有弊。如果将形式化表述和自然语言表达的优点相结合，会不会达到更好的效果呢？

2.4 第四单元

第四单元在架构设计上发挥的空间也不是很大，因为UML的规则已经帮我们设计好了大体的架构，剩下需要我们做的就是在细节上做设计，从而达到更好的适应需求，更好的算法性能等目的。这一单元的架构也很有层次化的特点，我对层次化架构设计的理解加深了。

三、测试的演进

3.1 第一单元

第一单元我搭建了完成的评测机，包括基于形式化文法的数据生成，以及基于sympy的正确性评测机，以及和小伙伴的对拍机

3.2 第二单元

第二单元我和小伙伴合作完成了评测机，完成了电梯日志输出合理性的检测。数据构造方面利用测试树，手工构造数据以及构造极端数据，尽量保证覆盖率。

3.3 第三单元

第三单元我和小伙伴合作完成了评测机，完成了基于指令格式的数据生成机，并且在随机生成中添加了一些生成策略，让数据强度更高。在正确性评测方面采用了对拍方式。

3.4 第四单元

第四单元考虑到随机生成难度较大，并且期末时间紧张，采用了基于测试树的数据手工构造，这单元由于测试分支都比较明确，因此手工构造数据测试相比其他单元的有效性更强一些。正确性检验采用白盒测试，以及对拍两种方式尽量确保正确。

比较遗憾的是由于时间关系和对测试效果的考量，没能用上JUnit测试，希望可以在以后的学习中再做进一步了解。

四、课程收获