BUAA 面向对象课程 第四单元总结以及课程总结

第四单元——UML

1. 总结本单元作业的架构设计

最终版本代码行数接近1k9行。

本单元是要实现一个接口，功能为对UML信息进行建模、解析、异常处理。

在第一次作业中，由于只有一种UML类型（类图）的查询，直接将建模的数据存储在MyUmlInteraction中。

在之后的开发中，考虑到UML图的多样性，可以实现一个通用的查询接口，在起内部对每一种类型（类图、时序图、状态图 ...）分别构建查询器（xxxQueryTool）。通用查询接口中不保存实际的建模信息，这样实现了通用性，新加类型的时候可以不删除代码，只进行添加即可完成功能的新增。

graph TD A(GeneralInteraction)-->类图查询器 A(GeneralInteraction)-->时序图查询器 A(GeneralInteraction)-->状态图查询器 A(GeneralInteraction)-->ValidityChecker A(GeneralInteraction)-->......

对于建模过程，由于给定模型符合java8标准，也就意味着可以用相似的结构来将元素转换成各个类之间的组合关联等关系。于是可以构建自己的各种模型类，将官方的各种Uml元素封装起来，如封装出MyUmlClass，MyUmlInterface等。

建模过程是对于各个查询器来说独立的。实际实现的时候，通过多次遍历所给的UmlElement，将各种元素按照相互的依赖关系，理清所处的层次（类似于在json树结构中的深度），先建第一层，在建第二层、第三层......

对于具体的查询指令，这里想说一下有关于递归查询的部分。由于接口是可以多继承的，那么在考虑父类的情况下，时间复杂度就不是线性增长的了。这时要用到记忆化。由于这类查询指令具有无后效性（应该可以这么理解），那么就可以在搜索的过程中，将中间过程答案存储下来，减少杜绝重复计算。

差不多就这些

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

总的来说，就是 “因地制宜”、“就事论事”、“宏观把握”。

第一单元，表达式求导，类似于树形结构，和本单元（第四单元）有些类似。另外的表达式解析的任务交给新的类，这样把职责分割开。

第二单元电梯。整体分为，Model（模型或理解为数据）和Controller（控制/操作）。

第三单元jml，狭义的理解，就是一种翻译，只不过是一种语言翻译成另一种语言（jml --> java)。jml本身的意义及重要性实际上也是具有争议的可以被探讨的。毕竟jml可以算是一种逻辑严谨的伪代码/逻辑表述。那么jml和真正的代码间到底差了什么呢？是不是甚至可以跳过jml直接写代码，也就是某些情况下根本不需要使用jml。（以上仅是一种想法，一种观点）

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

测试前两个单元就是搭建评测机，后两个单元只对junit进行了简单测试，并没有应用在实际任务中。

4. 总结自己的课程收获

• java语言基础
• java多线程开发基础，包括各种经典锁的原理和使用
• 面向对象相关
  • 设计模式
  • 测试
• 迭代开发思想（向后看）

Talk is cheap，show me the code。代码能力只有在不断的编写中才能提高。显然，面向对象课程是有助于提升代码能力的，特别是在大二这个时间段。

5. 给课程提改进建议及其他

• 实际上，UML这种工具，可以进行了解。第四次作业实际上是实现了一种解析工具，感觉说是UML单元，其实只是解析工具的语法要求是UML，实际开发重点没有Uml的使用，这个是看课程的设计重点了。但毕竟单元名叫Uml，Uml本身就具有Unified性质，而实际开发过程中却出现了许多细节的询问甚至潜藏的二义性。这种矛盾可能显得有些别扭，也说明Uml的出现并没有完全解决自然语言和精确逻辑之间的转换与理解问题。以上提出一个小矛盾点，也说不上是个问题。
• 多线程问题可以适当增加一些内容，比如各种Lock的使用。

标签：总结,--,查询器,BUAA,课程,jml,UML,单元
来源： https://www.cnblogs.com/rixson/p/14938957.html