442
社区成员




在本单元中,正向建模与开发是课程组一直在强调的一个重点。经过三次作业的练习,我对这一概念有了一个比较具体的认识,用比较通俗的话讲就是:先使用UML进行架构与流程设计,再基于这样的设计进行开发,这似乎也是课程组在这单元在程序评测之外还引入了图评测的本意。
但是在本单元中正向建模的实际效果并不好,课程组的设想似乎是“通过一个逻辑较为复杂的业务场景引导同学们借助建模工具来做好正向设计与开发”,但是本单元似乎没有做好复杂度的把控,题面在一些边界情况上没有给出清晰的说明,并且在开发过程中不断地修改需求,这对课程组所期望的正向开发造成了一定的阻碍,实践了这种开发方法论的同学们在设计阶段就很难针对一个语焉不详的指导书做出清晰的设计。
图评测的引入的确让我对UML建模及其工具(starUML)有了一个较为清晰的认识,但是正向设计的体验并不好,希望日后能在本单元设置一个更加清晰,复杂度更为合理的业务场景,让同学们体会到正向建模与开发的优越性。
本单元中,由于hw15只是进行了“轻量化迭代”,因此在hw14到hw15,架构并没有什么明显的变化,故这里只展示hw13和hw15的架构图。
其实第一次作业还是想进行一番设计,尽可能做到符合 高内聚,低耦合 的设计的,因此封装了许多的与指导书描述的职责角色相对应的类,并在它们的方法设计以及职责划分上做了一定的思考。
而到了hw14,但是因为我太菜了加上被大量的指导书细节信息狂暴鸿儒以及对复杂度感到头疼于是最终设计的耦合还是 挺高的(甚至对于图书管理处都没有做单独建类),没做到我想要的效果(其实是在设计上有所摆烂,不过也跟第二次指导书的功能设计其实是有些违背课程组一直强调的开闭原则的, 预定逻辑相对hw13进行了大改)。这些也都是挺遗憾的事情,而且也干的挺累的,还写了一坨不怎么优雅的代码。不过幸运的是本单元因为种种原因数据强度都比较温和,是我这个菜狗人生第一个满分的单元,可喜可贺。
至于追踪关系,我的状态图与顺序图的设计都较为简单,故与程序能保持较好的一致性。
本单元其实在我看来是理解难度(除了U4的题面)最高的一个单元,倘若贸然coding,不做一点设计与思考的话,很容易写到一半就迷失在树上(指表达式树)了。本单元的难点在我看来主要是要理清表达式的递归树结构,并基于对这个结构的理解进行程序设计,才能对类间的层次关系,层层嵌套的递归调用有更好的理解。
我认为电梯单元是一个架构很容易趋同的单元,大家的思路无非就是 生产者-消费者模式,不同最多在于调度器的有无以及相应的调度策略怎样设计。本单元的主要难点在于线程安全的细节问题,怎样堵好所有的漏洞让我们的整个系统里的乘客 一个不多,一个不少,这其实也要求我们对于架构设计以及时序有一个清晰的把控,只有对这两者了然于胸,才能分析清楚 我的电梯到底在哪里把人丢了这样的问题。
第三单元貌似在架构设计层面涉及不多,更多强调的是对 规格化设计 的体验。
本单元正式强调了严格的正向设计,不同于之前几个单元没有显示要求的草稿性设计,本单元似乎是想让同学们学会从多角度画一张程序设计的蓝图,我在本单元学会了如何较为规范地进行uml建模。
这里用一张表格做个总结吧。
单元 | 测试手段 | 强测成绩 |
---|---|---|
U1 | 样例/手搓 | 均分70左右 |
U2 | 第一次作业写了个评测机(随机生成)/使用讨论区佬们的评测机 | 均分90左右 |
U3 | 同上,不过自己只是写了个数据生成器和朋友对拍/还尝试了一下junit | 一次90其余满 |
U4 | 简单测试基本功能,因为不确定正确逻辑() | 全满 |
开学第一周我可谓是面临诸多压力啊,美赛,缓考以及OO的第一次作业。在设计了两天还未产出一行代码的那个周四的晚上,我靠在椅背长叹一口气,内心问了句自己:这学期真扛得住吗?现在正在写这篇博客的我可以给当时的我一个确定的答复:真扛得住!
正如所有人所说,oo是一门代码量大,任务重的6系经典大课重课,我这学期在一周周的设计,实现,测试以及debug的循环中,提升了自己嗯造代码的能力,提升了自己将来从业时的抗压能力,更重要的,在这门课之后,我可以说:我更敢写代码了。
谢谢oo的历练,更谢谢撑到最后所有作业都做到有效的我自己,暑假快乐!