正向建模和开发
本单元通过学习三种UML图,在具体写代码之前先对架构进行构建。理论上讲,这样是可以节省很多时间并优化架构的,但是我实际执行过程中,经常遇到原来的UML图架构考虑不周,而不得不根据代码反过来修改UML图,最后第一次作业基本上就和先写代码没有区别,好在第二,三次迭代时这样的情况减少了很多。先确定结构再开发一定是更好的,而且随着项目的增大,这种优势会愈发明显,第一次作业先写代码再画的UML图,直接导致了类之间的关系依赖错综复杂,画出来的UML图基本没法看。对比之下,我一位同学全程根据先画出的UML图来构建的架构要简洁的多。因此,以后还是要多多练习建模,提高正向设计水平。
架构设计和UML之间的关联
由于第一次作业我实际上是先写代码再写UML图的,所以第一次也说不上什么关联,无非就是UML图忠实的反映了我设计的架构。由于没有预先设计,我的思路说起来较为简单,基本上就是模拟真实的图书借阅流程设置图书类,书架类,图书馆类,管理员类,学生类等一共17个类,按照指导书的要求一步一步的模拟运行。这就导致了虽然说起来,理解起来比较方便,但是类与类之间的关联,依赖等关系非常的多。光一个图书馆类就与6个类有着关联关系。对比一些同学使用的类似电梯调度系统中的控制类统筹全局的做法,我的UML图明显更为复杂。
第二次迭代我则是先画的UML图再具体实现,根据课上学到的经验,用一个图书馆管理类管理所有图书馆,处理校际借阅问题,具体实现过程中明显感受到了好的架构带来的清晰思路。由于先修改的UML图,最后也没有产生更为复杂的类。通过状态图的绘制,我对我的设计运行过程也有了更加清楚的认识。最后成功删去了几个不必要的类,把类控制在了15个。
第三次迭代,课程组大发慈悲只提出了非常小的要求,也是轻松完成了。
四个单元中架构设计思维的演进
第一单元主要学习了递归下降,在这个单元中我体会到了继承思想和模块化思想在设计中的优势
学习到了把一个复杂的问题一步一步的分解成一个个能够直接解决的小问题的做法。也认识到了代码要留出足够的迭代空间,有的同学一遇到要求支持括号嵌套就不得不重构,而我的设计甚至天然支持嵌套。
第二单元主要学习了多线程和信号量机制,我运用了生产者-消费者模型和调度器与电梯分离实现。其中调度器和电梯的分离使得代码的耦合度更低,方便后续根据根据要求实现不同策略的电梯,生产-消费模型和信号量的使用则确保了每个电梯的所见即所得,不会有空气乘客和出不去的乘客。感觉对我最有意义的就是这个控制器模式架构,所有的实际指令运行都要经过控制器的分发,这对我在多线程环境下的bug修复的定位起到了很大的作用。
第三单元则是根据JML来实现具体代码,这里我学习到了设计和实现分离的架构思想,设计负责讲清楚一件时期,实现负责如何把这件事情做得又快又对。因此完全按照设计来实现的代码并不是优秀的代码,这个单元对我们的算法要求是最高的,然而,课程组并没有特意的强调这一点,导致最后我的成绩不是很理想,希望以后能做出改进。
第四单元对我架构水平的提升是最大的,第一次设计,实现,测试都由我独立完成。在吸取第一次作业的教训之后,我在后续设计时尽量保持了高内聚低耦合思想,一个对象不必要拥有的类就绝不分配给它,最终使得我迭代后的类总数不增反降,架构也更加清楚。
四个单元中测试思维的演进
第一单元: 自己动手随便捏造测试点。
第二单元: 考虑各种临界情况构造测试点,同一时刻大量人员进入,构造压力和性能测试点。
第三单元: 第一次尝试设计评测机,用大量的测试碰撞和跟同学对拍来找到BUG
第四单元: 由于题目状态实在太多,随机生成的数据难以保证有效性,最后还是自己动手设计了几个测试数据。
课程收获
最大的收获就是学习了JAVA这门语言,相比于C语言,JAVA中的继承和接口,前人提供的大量实用函数,arraylist和hashmap结构体,IDEA的代码自动补全。以上种种都为我的开发带来了全新的体验。
学习了面向对象设计思维,对代码架构有了更深的理解。
学习了评测机的使用和搭建,自己可以独立完成小型项目的测试和BUG修复。
课程改进建议
第一单元的难度对于没有JAVA的同学过大,可以适当的调整顺序,比如把第三单元作为第一单元。让学生根据JML学习的同时初步了解JAVA语言。
第四单元第二次作业的指导书不够清晰,导致最后变成需要同学们不断提问来补全各种状况,对于一些不太关注讨论区的同学不太友好,希望能够改进。
可以在每次的指导书上提供更多的测试样例。
标签:OO,总结,架构,迭代,代码,BUAA,设计,UML,单元 From: https://www.cnblogs.com/liuhaodong1101/p/17489397.html