OO第四单元及课程总结

1.第四单元总结

第四单元共有两次作业,第十三次作业是实现一个UML类图解析器,可以通过输入各种指令来进行类图有关信息的查询;第十四次作业是在第十三次作业的基础上,扩展解析器,使得能够支持对UML顺序图和UML状态图的解析,并能够支持几个基本规则的验证。

1.1第十三次作业架构设计

第十三次作业类图如下:

 

此次作业为实现一个UML类图解析器,输入为一条条用于建模的语句。因为类图本身具有层次结构,例如一个model下是若干的class和interface,每一个class或interface下是它的attribute,operation,association和generation或realization,因此此次作业用于保存类图信息的结构也可以采用上述的层次。在上述层次结构的基础上加上用于命令查询的接口和用于计算或保存计算结果的类就是此次作业的架构。单从架构的角度上讲还是较为易于设计,重点在于根据查询指令保存建模用的关键信息,并采用适当的算法计算需要的结果(事实上,由于类和接口的继承关系和类对接口的实现,很多查询指令需要使用递归方法查询,这就会产生大量的中间结果,对中间结果的保存以及对已有的中间结果不再进行重复运算对运算效率的提高至关重要)。

1.2第十四次作业架构设计

第十四次作业类图如下:

 

此次作业是在上次作业的基础上加上对UML顺序图和UML状态图的解析,对几个基本规则进行验证。在架构上,UML顺序图和UML状态图本身同样具有层次结构:UML顺序图         下是若干role和interaction,interaction下是lifeline和message;UML状态图下是region,region下是state和transition。对这两类图只需在上次代码的基础上加上上述结构即可。对于规则的验证,第一条是涉及类和接口内属性和关联关系的,后两条是涉及类和接口以及其继承或实现关系的,我单独建立一个类,对第一条规则对每个类检查其成员属性和关联对端内是否有重名,对后两条规则分别建立可达矩阵和可达路径数矩阵进行验证。

1.3 bug及修复

这一单元的两次作业在最终的测试中没有出现什么bug,但写这两次作业的过程中感觉指导书中有些东西说的不够明确,有些地方是在讨论区陆陆续续做出规定后一点点改正过来的,希望课程组以后能够完善指导书关于内容说明和测试限制的部分吧。

 

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

第一单元的作业是对表达式进行求导。在进行第一单元作业,尤其是第一单元的第一次作业时,因为是第一次使用java这种面向对象的语言 ,思想还没完成从面向过程到面向对象的转换,在现在看来当时的代码架构很难体现出面向对象语言的特点。第一次作业时只有两个类,main类和提供方法的类,如果不是为了编译能够通过,很难看出和用c语言写有什么区别。当时对面向对象的理解也不够,无法明确什么能作为一个对象,望文生义般地以为一个实体才是一个对象,通过以后三个单元的作业才逐渐意识到:万物皆可为对象。

第二单元的任务是多线程电梯的调度。这是我第一次接触多线程编程,虽然OS课上讲过了进行并发控制的锁,但只有当自己亲自去用锁进行多线程的并发控制并亲眼目睹的各种各样谜一般的输出顺序和输出结果后,才明白究竟该如何控制才能够既保证效率又保证安全。在写第一单元的作业时,因为架构设计的问题,三次作业每一次都要大改架构才能够适应新的需求。在第二单元时我吸取了上一个单元的教训,仔细思考了程序的结构,使得代码易于扩充,避免像上个单元一样大量的重构代码。其具体做法是尽可能的把联系较少的对象分离开,做到“高内聚,低耦合”。不过这句话说起来容易做起来难,第二单元前两次作业还好,有把电梯、请求队列、调度器分离开来,但到第三次作业时为了方便把请求队列和调度器合在了一起,这样十分不利于代码扩充,如果有第四作业的话,恐怕要大改架构。在OO方法的理解上,较第一单元有所长进,当然这也与电梯、调度器、乘客在现实中本身就是一个个独立的实体有关。从架构设计上看,对OO的理解还是不够的,还有很大的提高空间。

第三单元作业为根据代码规格撰写代码最终实现一个地铁系统,可以对该系统的图进行增删和查询操作。这一单元的主要目的是理解JML规格。在完成这一单元作业的过程中,我能明显感觉到在架构设计上较前两个单元有长足的进步,具体表现在能够根据作业要求划分结构的层次,并预先设计好各个类的功能和它们之间的联系,能够考虑怎样设计利于代码扩充以便更高效的完成接下来的作业。同样的,在OO方法的理解上,随着对架构设计理解的加深,也同样的有所加深,表现在在进行方法调用时,不再是单一的调用方法,而是有层次的调用方法

第四单元的作业是对UML三种图的解析和一些规则的验证。第四单元的架构设计如第1点所示,从类图上看和第一单元第一次作业只有两个类的类图相比复杂了许多,这不只是因为难度增大了许多,也是因为我对架构设计有了深入的理解。通过四个单元的作业,通过自己的不断练习和瞻仰课程组选出来的优秀作业,“熟读唐诗三百首,不会做诗也会吟”,在第四单元完成时对架构设计的理解已经完全不同于第一次写OO作业时的不知所措,在OO方法的理解上也同样如此。现在在读完指导书后会先思考如何划分层次,如何把需要用到的繁复的东西做合并和分离,如何利用类之间的关系高效地进行存储和运算。

 

3. 四个单元中测试理解与实践的演进

第一单元测试时像之前一样写测试样例尽可能的覆盖测试范围,分别考虑正确样例和错误样例,思考特殊情况如边界和过分复杂的样例(有的复杂的测试样例想要自己求导出来正确答案还挺麻烦的=,=)。靠自己想着范围写测试样例的方式还是难免会出现漏考虑的情况,第二次作业时就因为有的样例没有测试到导致强测中出现错误。第三次作业栽到了运行时间上(这就样归咎于代码架构和算法上了)。

第二单元的作业是多线程,这就会导致一个情况:同样的输入可能会产生不同的结果,而这些结果中有可能会有错误的情况。因此即便写出较为完善的测试样例,在某一次测试中得到正确结果还是不能保证代码的正确性。所以就需要从理论上证明多线程并发控制时保证安全,考虑所有可能的代码执行顺序保证无论以何种顺序执行都能够保证安全性。

第三单元学会了使用工具测试代码,JMLUnitNG与JMLUnit是较为方便的工具,使用这些工具可以在改变代码后进行快速的测试来保证正确性。

第四单元要输入指令来查询,这就需要根据查询指令可能返回的结果种类构造测试样例,同样的,要覆盖所有的情况范围。在规则的验证上考虑特殊情况和对测试数据的限制构造测试样例。

总的来说,无论是手动测试还是利用工具进行测试,都少不了测试者对需要测试的样例的了解,这就需要测试者完全理解代码的作用和希望达到的效果,并把样例分成各种情况进行测试。

 

4. 课程收获

通过四个单元的作业学习到了很多,从各个单元来说:第一个单元初次学习了java代码的撰写,开始了解OO方法和架构设计,代码思维开始转变。第二个单元学习多线程,掌握如何进行并发控制,如何合理使用锁。第三个单元学到了使用工具进行测试,学会了用代码规格去描述程序。第四个单元学会了如何读和画UML的三种图。

总的来说,四个单元的作业,万行左右的代码,对java代码撰写的熟练程度、架构设计和OO方法的理解有了很大的提高和加深,对代码的测试和代码运行过程中数据的缓存和效率的保证也同样学习到了很多。

 

5. 改进建议

1)作业对运行时间进行了限制,但在实际写作业时无法确保自己的代码在测评机上能否在限制时间内运行完成。可以开发一个功能在测评机上输入自己的测试样例,返回程序的运行时间。

2)有很多规定是在作业过程中才做出规定的,导致还要在出现新的规定后修改代码,课程组可以把今年指导书上没有考虑的内容收集一下写到下一年的指导书里。

3)希望老师在每一个单元的总结课后就一份具体的具有优秀架构的代码讲一讲架构如何设计以及这样设计的好处,便于加深对架构设计的理解。

 

最后,感觉老师和课程组的辛勤付出。

我,结课,开心(小声)

相关文章

UML有助于在软件开发生命周期的所有阶段理解和可视化系统。以...
UML各种图总结-精华 https://www.cnblogs.com/jiangds/p/65...
MicrosoftOfficeVisio“UML模型图”模板为创建复杂软件系统的...
用例图1.用例图是UML用于描述软件功能的图形。用例图包括用例...
一、用例图:用例图(usecasediagram)是UML用于描述软件功能...
1.A类B类C类这三个类是什么关系?B类依赖A类和C类因为最主要...