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)]](https://i-blog.csdnimg.cn/blog_migrate/3c1a5038371ce2410ba171e1700ae91f.png)
第二次作业
类图![(img-Itz6TedC-1687081789507)(h2-1.png)]](https://i-blog.csdnimg.cn/blog_migrate/9c1abd62ab0df86e8fb634e372417ff2.png)
状态图![(img-RUHfB0Ev-1687081789507)(h2-2.png)]](https://i-blog.csdnimg.cn/blog_migrate/8459e3a0c19d923d3e7a80e784f10463.png)
第三次作业
类图![(img-gDzDsExo-1687081789507)(h3-1.png)]](https://i-blog.csdnimg.cn/blog_migrate/c9cad9697011c671c135ca373d846042.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只给出了“要求”,而实现需要外包,我觉得这对于我的设计思想也是一种补充。