U4单元总结

建模与开发

1. 正向建模:

   • 通过绘制类图,我可以清楚地识别出系统中的核心实体,如书籍、读者、借还记录等,以及它们之间的关系。这有助于更好地定义系统的数据结构。

   • 顺序图则可以帮助我理解系统中不同实体之间的交互过程,比如读者如何借阅和归还图书。这为后续的功能实现提供了蓝图。

   • 状态图则可以描述图书的状态转换,如可借阅、已借出、遗失等,为系统的动态行为建模。

   • 总的来说,这些UML建模有助于我深入理解系统的需求、结构和行为,为后续的代码实现打下良好的基础。

2. 面向对象开发:

   • 根据之前的类图设计,我可以直接将其转化为Java的面向对象结构,包括类的定义、属性、方法等。

   • 借助面向对象的封装、继承、多态等特性,我可以更好地组织和管理系统中的各个模块,提高代码的可复用性和可维护性。

   • 在实现具体功能时,我可以参考之前的顺序图和状态图,将用例转化为面向对象的方法调用和状态转换。

   • 总的来说,面向对象的开发方式能够确保系统的结构清晰,并提高代码的可读性和可拓展性。

3. 总结:

   • 首先，通过先进行UML建模,再采用面向对象的方法进行开发,可以确保系统设计合理,实现高质量。但说实话，我在第一次作业和第二次作业都是先写代码再建模……理由是，我当时认为，我在写代码的时候实际上并不能准确知道后续我都需要些什么功能，先建模的话势必会导致我写码之后再修改模型，那么为什么不干脆先写码呢（X）

   • 然而随着作业逐渐深入，我意识到，其实事先建模的好处就是让我先思考需要些什么，然后不走回头路，可以少重构。。。

整体架构

第一次作业

第一次的架构还是比较容易的，我把所有的order都抽象到了Library类里面进行处理，然后在User里面保存来借书的人。其余类整体用的都是按照题目要求的，bookshelf是在书架的书，BorrowAndBack是借还处，Appointment是预约处。只需要在Library里面对他们下达命令就好了。

第二次作业

第二次作业主要是添加了借还处。借还处我要喷一下，这个借书太不合理了。我们来假设一个例子：

• 图书馆里有两本叫B001的书，而此时一本被甲童鞋接走了。

• 此时乙童鞋来order这本书，书架上的B001被从书架挪到预约处。

• 随后甲童鞋想来续借这本书，但是因为乙童鞋没有取走他预约的书，而导致甲童鞋不能续借。

？？？什么吃着锅里的看着碗里的？太不合理了吧，这功能真的是为了保证让借阅率达到最大吗？？

上述条件读了很久的题才揣度出来这个意思，难绷。

以及关于order要喷的另外一点：

在第一次作业中说可以自由规划order的策略，第二次作业又说必order，第三次作业又说order的新策略。不是，这多少有点逼同学反复重构的意思（比如我）

第三次作业

第三次作业添加到比较少，主要是在User类里面添加了信用分。只需要老老实实按照题目要求加分就没有什么问题了。

本单元作业我觉得最需要思考的点反而是时间。这个时间指的是每天的开馆前和开馆后的区别。在第一次作业中开馆前后没有什么大区别，但是第二次作业就需要考虑order书的开馆前后如何加时间了。第三次作业更是需要每次开馆前后都扫一遍今天出没出现老赖。

幸好本单元数据量小，所以疯狂扫描也不会TLE（并没有指认第三单元）

追踪关系

• 类图与代码设计：每个类及其属性、方法的设置直接对应类图中类、属性、方法的设置。同时，各个类之间的关系也依照类图设计的关系

• 顺序图与方法调用：代码中的重要的方法调用和方法执行顺序聚能直接对应到顺序图中对象之间的消息传递和调用顺序。

• 状态图与状态转换：代码中不同状态之间的转换均能在状态图中找到相对应的内容。

测试思维

先跪谢大佬cxz以及传奇评测机dpo，如果没有他，我的oo已经挂了。

我主要的测试压力被dpo分走了……所以主要在互测的时候寻思怎么为难别人了，尤其以第二单元为例。

而其余的主要是如何给自己debug。我的策略是，先把输入数据化简。比如第三单元的样例动不动就上千，那也只能一点点化简到100行左右，然后再仔细看是哪儿出现的问题。

课程收获

• 在本学期的学习中深入了解了面向对象的特性，更了解了不局限于面向对象的代码设计方法和设计模式，比如递归相关的层次化设计及相关的递归控制和克隆问题、支持代码复用的继承/接口设计、使用生产者/消费者模式和共享对象进行的多线程同步互斥方法、死锁的避免、形式化方法、模型的抽象等。

• 提高了代码能力。每次课程代码的迭代量太吓人了，更不用说重构的量加起来了。太锻炼我各种实现能力了(吐血)

• 熟悉了测试方法还有各种git工具的使用。

• 祝愿OO课程越办越好~~