第四单元总结

第四单元总结性博客作业

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

本单元作业主要是实现一个 UML 解析器,使其支持对 UML 图的分析,可以通过输入相应的指令来进行相关查询,同时还可以针对某些不符合UML规则的情况进行判断。

在本单元中,我采用的主体思路是:对于类图、顺序图、状态图这三种图用三个不同的类MyUmlClassModel, MyCollaboration, MyStateMachine来分别表示,同时将处理每种图的逻辑装在每个子类中。在MyImplementation类中,用HashMap来储存所有的顺序图和状态图,同时由于每个UML图中最多只有一个类图,可以将类图作为MyImplementation类的一个属性来储存。在对于类图查询时,就将问题交给类图给出答案;对于顺序图和状态图,首先通过HashMap来找到对应的顺序图或者状态图,然后再由这个图给出问题的答案。

1.1 U4T1

第一次作业仅是对类图的查询。

对于类图,我采用了许多的HashMap来保存各种信息

private final HashMap<UmlClass, UmlClass> umlClassMap; //考虑类单继承,类与它的父类可以装在一个Map表示
private final HashMap<UmlClass, ArrayList<UmlOperation>> operationMap; //类与类中对应的方法
private final HashMap<UmlInterface, ArrayList<UmlInterface>> interfaceMap; //接口与其继承的所有接口
private final HashMap<UmlClass, HashSet<UmlInterface>> realizationMap; //类与其实现的所有接口
private final HashMap<UmlOperation, ArrayList<UmlParameter>> parameterMap; //方法与其所有参数
private final HashMap<UmlClass, HashSet<UmlAttribute>> attributeMap; //类与类中的的所有属性
private final HashMap<UmlInterface, HashSet<UmlAttribute>> attributeInterfaceMap; //接口与接口中的所有属性
private final HashMap<UmlClass, Integer> couplingDegreeMap; //储存类的继承深度,便于查询

将所有信息条理清晰地储存起来,在进行后续查询/判断时也方便。

1.2 U4T2

第二次作业增加了对顺序图和状态图的查询。

顺序图:

private final ArrayList<UmlLifeline> lifelines; //顺序图中所有的lifeline
private final ArrayList<UmlEndpoint> endpoints; //顺序图中所有的endpoint
private final ArrayList<UmlMessage> messages; //顺序图中所有的Message
private final HashMap<UmlLifeline, HashSet<UmlLifeline>> creates; //判断一个lifeline能够创造的所有lifeline
private final HashMap<UmlLifeline, Integer> founds; //计数所有lifeline收到的found信息
private final HashMap<UmlLifeline, Integer> lost; //计数所有lifeline发出的lost信息
private final ArrayList<UmlAttribute> attributes; //顺序图中相关的属性
//UmlCollaboration作为每个顺序图的标志,在MyImplementation类的HashMap中储存

状态图:

private UmlPseudostate umlPseudostate; //起始状态
private final ArrayList<UmlState> umlStates; //所有状态
private final ArrayList<UmlFinalState> umlFinalStates; //所有最终状态
private final HashMap<UmlTransition, ArrayList<UmlEvent>> transitionAndEvents; //所有的迁移和迁移对应的事件
private final HashMap<UmlElement, Boolean> criticalJudge; //记录状态是否为关键状态
private final HashMap<UmlElement, ArrayList<UmlElement>> stateTree; //判断从一个状态能够到达的所有状态
private boolean flag; //判断原状态图是否能从起始状态到达任意一个最终状态

1.3 U4T3

第三次作业增加了对模型合法性的检查,包括R001~R009一共9个规则。

基本架构不用发生变化,只是在查询之前需要进行是否符合规则的判断。

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

2.1 第一单元

首先是第一单元。第一单元我写的可谓一塌糊涂。。。第一单元的架构主要是参考了训练中的代码设计,将表达式分为Expr, Term, Factor三种类型,同时对于表达式进行递归下降处理。其实这个思路没什么问题,只是我实现的时候过于拘束在这三种类型的框架之中,所以我完全没有意识到我需要将Sin, Cos, Sum以及自定义表达式等等作为新的对象,建立新的类来处理(所以当时的架构写的很乱,计算过程自然也很乱)。在第三次作业的debug过程中,我才开始意识到明确对象、面向对象编程的重要性。

2.2 第二单元

然后就到了第二单元。第二单元主要是多线程,这单元的载体是电梯。此时的我架构反面仍然参考实验时候的代码,选择了输入线程、调度器线程、电梯线程多线程运行的结构。此时我选择的是将电梯作为对象,选择单例模式的调度器,各方面协调运转。此时的我对于架构设计虽然仍是在实验代码的基础上进行编写,但此时我已经逐渐理解了架构设计清晰对于程序设计的重要性,这个单元我也没有因为架构设计的问题而吃过亏(但是,在性能方面。。。)。在这时候,我逐渐加深了对于面向对编程的理解。

2.3 第三单元

之后就是第三单元,这时已经没有官方架构了,官方给出的是各个接口以及JML规格,我们只需要实现这些接口,剩余的架构设计就全部自由处理。第三单元我个人认为就是“你说什么,我就去实现什么”的感觉。在写第三单元作业的时候,我架构设计只需要保证我的逻辑清晰,要找什么数据我能够简洁明了的找到并且处理就可以。所以第三单元对于异常的计数我选择了单例模式的Counter来处理,各个异常都直接汇总到Counter,再有Counter给出计数就可以;对于MyPerson, MyGroup, MyNetwork类,由于官方架构已经给出了数组的处理方式,所以只需要用ArrayList, Hashset, HashMap等数据结构,逻辑清晰的储存即可。这一单元让我明确体会到了一个完备的JML规格能够对程序设计起到的关键作用。JML规格越完备,就可以越明确需求,在编程时就可以实现“说什么,就做什么”的一种“完全不用动脑子”的状态。

2.4 第四单元

最后就是第四单元。到了第四单元,也是没有官方架构,这回连JML规格都没有了。但是经过了前三单元的学习,我认为此时我的架构能够做到逻辑清晰有条理。架构方式正如第一部分所说。在这一单元的完成过程中,我已经开始切身体会到了架构有条理的好处——谁的事情,就交给谁去办。类图的事情类图给答案,顺序图的事情顺序图给答案,状态图的事情状态图给答案。这样代码编写时逻辑清晰,同时也提高了代码的可读性。同时,在这一单元中,我们对于Pre3 Task5中就提到的UML图进行了更加细致而深入的讲解,让我体会到一个完整的UML图对于程序设计初期的架构设计具有的强大的帮助作用。

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

3.1 第一、二单元

前两个单元的测试主要是通过测试边界数据来进行测试。由于此时刚刚开始,所以手动操作的边界数据可能不够完善。

3.2 第三、四单元

第三单元开始介绍了JUnit的测试方式,此时的测试变得单元化、系统化,使得测试的准确性相对提高,找出bug的概率也提高了。

4.总结自己的课程收获

对于整个学期的面向对象课程的学习,我感觉到我受益匪浅。

4.1 程序编写要注重层次性、逻辑性

从第一单元的一塌糊涂,到第四个单元的游刃有余,我深刻的体会到程序编写过程中层次性、逻辑性的重要性。一份逻辑清晰有条理的代码对于编写者、读者,都是要比一份糊涂的代码要更容易理解。同时,在Debug的过程中,一份逻辑清晰的代码也更容易定位到bug的位置,提高效率。

4.2 程序编写初期要有明确的架构目标

一开始我写代码的时候喜欢直接上手开始写,一边写一边确定逻辑层次。但是,我现在发现这样做太容易走弯路了。由于有UML图的存在,在程序设计初期可以通过画一份UML图来思考、优化自己的代码架构设计,使得自己的代码在初期就有明确的架构目标,从而在实际上手时目的更加明确。

4.3 程序编写要有良好的可扩展性

本学期的代码课程分四个单元,每个单元都有三次作业,每次作业都是对于上一次作业的增量开发。这也就意味着,在写作业的同时,也要考虑到之后可能会添加的内容,要给程序留出足够的余地来进行扩展,也就是具有良好的可拓展性。如果对于一份代码,每次扩展都要大动筋骨,那么工作效率就会变得很低,这样完全不利于作业编写,更不用说工作展开了。

4.4 程序编写要确定每个方法(函数)的作用

事实上,第三单元的代码编写我感觉时非常舒服的——每个函数要干嘛都明确告诉了,需要做的就是实现这些目的。目前还是课内代码,代码量和实际工作中会遇到的代码量肯定时无法比较的。但是,对于每个函数,如果能够确定每个函数要做的事情,在JML规格中限定每个函数的作用范围,这样在编程时也能感到更加得心应手。

5.立足于自己的体会给课程提三个具体的改进建议

5.1 架构模式

可以对于架构模式多一些讲解。在刚开始看第二单元的代码时,我看的还是比较懵的,直到后来自己了解了一些内容后才逐渐理解。可以针对这方面多一些讲解。

5.2 单元之间的关系

感觉四个单元都在各讲各的,之间的联系不是非常密切(个人认为)。

5.3 测试相关

中测数据太弱!虽然我不知道这是否时课程组有意为之,但是一份有着明显bug的代码能够通过中测,就导致自己在课下进行测试时的压力提升。同时,互测时虽然是鼓励研究他人代码,寻找他人代码的bug,但是我个人感觉,一方面下载他人代码、配置jdk等等作为先决条件比较麻烦(第三单元还需要将他人代码和官方代码相结合),另一方面比起研究bug,直接采用高强度数据(甚至可以没那么高)进行hack的成功率也明显很高。这同样也暴露出中测数据的强度较弱。我不知道这些是否是课程组的故意安排,但我认为这样的设计对我而言相对不是非常合理的。

posted @ 2022-06-26 19:41  普通桑  阅读(9)  评论(0编辑  收藏  举报