buaa oo-unit4

该文总结了学习UML过程中绘制类图、状态图、时序图的实践,强调了类的职责划分、静态类与动态过程的刻画,并回顾了从第一次作业的图书馆系统设计到第二次作业的校际借阅流程及第三次作业的借阅时间限制的实现。作者反思了在架构设计和测试思维上的演进,指出在设计时需注重高内聚低耦合以及严谨的分析思考。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

Part0 前言

  这单元在仓促中结束了,中间有着比较大的波折,我的体验也不算太好。但毕竟第四单元经历了比较大的改革,助教们也很难一把做到完整。
  这单元的主题是 U M L UML UML图,我们在三次作业中依次画了类图、状态图、时序图。这三种图都是对于程序的一种刻画。其中类图是“静态”的,状态图是对于某一个具体的对象的状态在执行过程中的变化的刻画,而时序图则是对于一些特定操作或者一个程序执行过程的“动态”刻画。

Part1 本单元所实践的正向建模与开发

第一次作业

  本单元第一次作业需要比较注意的点是对于书借阅判断的时机,对于书借还等操作,在哪个机器上实现等等的细致分析。实现的主要部分在于,把每个类的职责给分清楚,不要出现耦合的情况。第一次作业中,我把图书馆 L i b r a r y Library Library作为一个主类,他管辖有 O r a d m i n , L R a d m i n Oradmin,LRadmin Oradmin,LRadmin等管理员,在设计这些类的时候我没有考虑到后面的迭代,都设计成了静态类(觉得只有一个图书馆)。静态类也有好处就是,在引用的时候不需要把每个对象都把指针传到其他对象里去,可以方便调用。

第二次作业

  本单元第二次作业实现了校际借阅,但这个借阅的流程比较麻烦,我在写了一版代码后发现有很多顺序的问题,经过助教更正之后再改了一些细节。这次作业我把“校际 I n t e r S c h o o l InterSchool InterSchool”这个抽象的含义写成了类,也就是相当于写了一个类管理、包含所有的学校。并且,我把第一次作业的所有静态类和静态方法都改成了普通的类和方法。另外新增了 R e q Req Req类,用于解决一系列的请求(如校际借阅、购书、校内订阅等),并且这些请求全部用 H a s h M a p HashMap HashMap或者 A r r a y L i s t ArrayList ArrayList实现(依据于这个请求是否有顺序要求),对于一些既要查询又要保证顺序的,我用这两个数据结构都存了一遍。
  特别的,对于“校际借阅”这种复杂的步骤,而且每个步骤还要有功能性的输出,在每个时间节点有固定的操作的一些行为,我采取了老老实实模拟的方式,把每次运出、运进、接受,都分开写了方法,用了 H a s h M a p HashMap HashMap进行存储书籍。

第三次作业

  本单元第三次作业实现了借阅时间的限制。我在每个学生的类中加入了一个 H a s h M a p HashMap HashMap用于管理他借到的每本书的借阅初试时间。

Part2 总结架构设计

第一次作业

类图(img-hPYAnMEA-1687081789506)(h1-1.png)]

第二次作业

类图(img-Itz6TedC-1687081789507)(h2-1.png)]
状态图(img-RUHfB0Ev-1687081789507)(h2-2.png)]

第三次作业

类图(img-gDzDsExo-1687081789507)(h3-1.png)]
状态图

同第二次

时序图

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-g5YTdxwj-1687081789507)(h3-2.png)]

实现代码与架构之间的追踪关系

  在时序图中的每个 m e s s a g e message message都能对应到代码中的方法,方法在类内部的实现,信息发送的位置也和代码的具体实现相对应,可以串成一条线。(图和代码的一一对应真的很美妙)
  在状态图中的对于借书和还书操作的状态转移,也和代码中的时序一一联系,每一步都能有足够的依据进行转移。

Part3 在四个单元中架构设计思维的演进

第一单元

  由于表达式化简比较复杂,我想架构的时间也比较长,但在处理过程中(如判断相等)还是出现了问题,没有对自己的设计思路做严谨的分析。导致写着写着总觉得之前的思路可能不行了。但又不想重构,只能用一些奇怪的方法去弥补。

第二单元

  第二单元中,我参考了学长的电梯策略,决定使用自由竞争。自由竞争比较好写,但也存在耗电大的问题(当然可以使用提前加队列等方式解决,但我选择摆)。让我记忆犹新的是,第二次作业中,加入了开关门以及电梯维护等新的要求,我没有进行很细致的分析。实际上电梯维护是很复杂的,存在很多边界情况,分析的稍微不严谨或是有错漏就会出现 b u g bug bug,在那次作业中我超过了 10 10 10次提交,足足用了 11 11 11次提交才通过。说明我在设计思维方面,虽然对全局有一定的把握,但在细微处缺少分析能力,没有进行细致深入的思考。

第三单元

  第三单元中,由于是给出了 J M L JML JML语言,相当于是伪代码的作用,给我们的设计带来了不少方便。我的大多数思考是在数据的存储结构和如何高效的进行代码实现上。虽然这单元在 J M L JML JML语言上被同学们诟病,但也让我体会到了“设计外包”的思想。

第四单元

  第四单元,是我认为架构设计对程序实现最重要的一个单元。在这单元中,我特地注意了类的高内聚低耦合性,把所有的功能都细分开,防止出现一手全揽的局面。为了做到这点,我牺牲了一些性能,但也保证了正确性,对每个借书还书的动作都进行了模拟(也为输出带来了方便)。但在第二次作业中,我产生了一定的失误,直接进行了管理员和管理员之间的通信,如果中间把图书馆当做消息传递的媒介,而不是直接进行类的调用,我觉得会好很多。

Part4 在四个单元中测试思维的演进

第一单元

  第一单元由于是开学初期,比较忙碌,我没有进行特别的测试,只是把同学手搓的一些测试点拿过来跑了一下,导致在强测中出现了很憨的错误。

第二单元

  第二单元电梯的测试,手造数据不太方便,但我不会写 s p j spj spj和评测机,主要是白嫖队友的评测机来用。

第三单元

  第三单元,我自己写了评测(只写了第二次作业),让我体会到了造数据的不易(也感受到了分享评测机的大佬的爱心和胸怀),造数据的过程中,我把数据的强度和造数据程序的实现难度进行了平衡,虽然写的数据生成算法不是很难,但 m a k e d a t a makedata makedata d e b u g debug debug了好久。数据的生成算法也比较值得思考,既要有一定的随机性,也不能太“完全图”,我在思考和交流的过程中学到了很多。

第四单元

  第四单元,我没有写造数据(全部用的权佬的评测机和队友的评测机)。

Part5 总结自己的课程收获

  这学期的 O O OO OO课终于结束了,给我最大的感受就是,一开始上来的强度很大。表达式化简这个内容是我觉得很值得探究的,但当时我空余时间不太多,只写了最基础的算法,没有用三角恒等式进行化简比较可惜,希望课程组能够对这单元继续优化和使用。
  第二单元我感觉对我帮助比较大,让我接触了新的知识,并行程序真的是很美妙,但对新手又很不美好。我在各种调错的过程中,最最最深的感受就是,自己需要具有严谨的思路,每次都是边边角角的错,补了这头,那边又漏了。我希望在后面的学习中能够继续深入学习多线程程序。
  第三和第四单元,我觉得也还可以,虽然这两单元的争议比较大,第三单元的 J M L JML JML虽然早已被业界淘汰,但让我初窥了一个大工程如何一点点生成的。不是平底建高楼,而是进行了整体到局部,大方向到细微等各方面的实现。 J M L JML JML只给出了“要求”,而实现需要外包,我觉得这对于我的设计思想也是一种补充。

评论 1
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值