北航面向对象设计与构造2021第四单元作业总结

一、总结本单元作业的架构设计

本单元的任务是在已有框架基础上，补齐关键部分，使程序能够解析 StarUML 软件用于记录 UML 数据的json格式文件，并实现一定的查询和查错功能。

json文件本来是树形结构，里面的各元素的父类都叫UmlElement。但已有框架把它们都拆散了，需要我们根据各实例的特征属性，重新建立相应的关系。

需要我们补齐的是一个叫UmlGeneralInteraction的类，程序运行时会创建这个类，并传入框架已解析出的所有UmlElement实例，它们可能是UmlClass、UmlOperation、UmlAttribute、UmlAssociation、UmlAssociationEnd、UmlGeneralization、UmlInterface、UmlInterfaceRealization、UmlParameter、UmlStateMachine、UmlStateLikeObject、UmlTransition、UmlOpaqueBehavior、UmlInteraction、UmlLifeline、UmlMessage、UmlRegion、UmlCollaboration、UmlEndpoint、UmlEvent。

为了还原树形关系，需要对UmlClass、UmlCollaboration、UmlFinalState、UmlInteraction、UmlInterface、UmlLifeline、UmlOperation、UmlPseudoState、UmlState、UmlStateMachine进行封装，但已有框架都通过final关键字禁止了继承它们，因此只能选择对他们进行包裹（wrap），得到相应的包裹类（wrapper class）。由于有些情况需要统一对UmlFinalState、UmlPseudoState和UmlState进行操作，但已有框架未建立相应层次关系，因此建立UmlStateLikeObject接口。由于有些情况需要高效便捷地保证查询的不重不漏，而已有框架不满足需求，故建立ClassAttributeInformation类。

由于临近期末，为了写起来方便并减少重构的可能，并没有把查错部分、类图解析部分、状态图解析部分、时序图解析部分分到额外的相应类中，导致类行数面临超过 500 行的风险。由于课程组的 checkstyle 对超行扣分严重，而对import *形式的导入扣分较少，因此在本次需要大量导入的情况下，选择使用import *形式的导入来精简无意义的代码行。

最后，代码架构如图所示：

二、总结自己在四个单元中架构设计及OO方法理解的演进

本着高内聚、低耦合的思想，前三单元的架构设计请见前三单元博客。

在上本课程之前，我一直天真地以为，封装、继承、多态这些面向对象方法只是高级程序设计语言提供的一种控制程序复杂性的抽象语法机制，它可读性好，且利于复用和维护。

上完本课程，从层次化、多线程、规格化、模型化一路走来，我才意识到，合理识别、设计和构造对象，建立良好的架构才是面向对象的关键；至于语法，用 C 语言通过结构体、函数指针和枚举类型也能在底层手动实现这些高级语言的面向对象机制，用 Java 语言在糟糕的架构设计下也可以写出面向过程、可读性差、难以维护的程序。

同时，我感到面向对象有着浓浓的哲学色彩，感觉曾经的程序员们从面向过程的坎坷中逐渐总结出来的面向对象方法，就是从实践中把理论抽象出来了。面向对象的思维方式可能对今后认识世界和改造世界都会有独特的帮助。

三、总结自己在四个单元中测试理解与实践的演进

经过本课程的训练，我对测试的体会是——测试者应该与实现者不同。在很多情况下，我本地的自我测试无法测出隐蔽的问题，原因是我仍陷于已有的逻辑中，而问题往往出在题目理解错误等其它因素中，导致我构造不出导致程序出错的用例。通常，我只能对基本的正确性和性能手动或自动构造一些样例来测试，而这也通常能发现大多数问题。

掌握了在代码中使用assert确保前置条件、使用JUnit和 Python 的 subprocess等工具的方法。