272
社区成员




回顾一下第四单元完成的任务:利用UML进行正向建模,并完成一个小型的图书馆管理系统
- hw13:实现借阅,预约,预约取书,还书等基本流程
- hw14: 实现图书室借阅功能,并增加热门书架与普通书架
- hw15:引用用户信用积分限制
正向建模与开发是一种软件工程方法,主要用于系统设计和实现过程中,特别是在软件开发和硬件设计领域。这种方法从高层次的需求和概念开始,逐步细化和分解,直到实现细节,整个过程类似于从宏观到微观的构建方式。正向建模与开发强调从抽象到具体、从整体到部分的设计思想,有助于确保系统设计的连贯性和完整性,便于团队成员理解整个系统的工作原理。
OO作业是迭代性任务,一个良好的初期架构对于后期作业的顺利完成是十分重要的,本单元中,课程组的初衷是先绘制UML类图等进行正向建模,并据此进行后续开发。对此,我的做法是首先设计整体框架,抽象出主要类例如书架、借还处、预约处等类,将类聚合到一个总体类图书馆中,对不同操作抽象出一些大的方法,得到一开始的粗略图。在图书馆类中针对不同操作抽象方法,调用不同的组成部分调用其内部具体实现方法,在通过代码具体实现每个组成功能时完善原有的图,样在一开始设计图时不必关心下层设计,在编写代码时又有清晰的参考,以此实现图和代码的同步推进。
实际上,这样的结果是并未直接开展UML设计,而是箭和靶子同步画,不经过任何代码直接得到十分全面的UML图还是过于困难。
第一次功能相对简单,实现了以下几个类
Apooffice
:预约处,处理预约请求并为对应顾客留存对应的书Brooffice
:借还处,用于通过借阅以及预约取书拿到的书都会在此处归还Bookshelf
:书架,保存依旧属于书架中的书BookManager
:图书历史记录管理User
、Book
、Apointment
、Record
:用户类、图书类、预约记录、历史记录Library
:类似于一个抽象的图书馆类,用于各个部门与输入输出的交互实现实际上,代码中应有的类在指导书以及oolens
的推送中已经暗示的非常明显了。
但联系现实生活,一本书不应知道除书本记录的文字内容之外的信息,所以我用管理器管理历史记录,类似于现实生活中的图书查询系统。
本次作业新增了热门书架,阅读,归还等功能。
为避免对架构的改变,我在Library
中设置了两个Bookshelf
的实例,分别对应普通书架与热门书架。并在开馆整理时候将对应的书移到相应书架,并通过removeBook
的返回值来告知外界其来自哪个书架。
新增阅读室Readingroom
,完成阅读以及归还功能,并在每日闭馆的整理过程中将阅读室剩余的书整理回书架。
本次作业中引入了用户信用分系统,对用户的行为做进一步限制,同时新增了图书借阅期限的限制。
维护一个容器,在其中记录所用被借阅或者预约取书拿走还未通过return请求归还的书。在借阅和取书成功后加入该容器,并在书中存储对应的截止日期与用户id等信息。在每日闭馆后对逾期未还书的用户进行信用分扣除。
由于开馆闭馆日期的不连续,我们需要注意在每日开馆时候计算扣除包括两次开馆之间间隔天数对应的信用积分,同时更新上一次扣除过的日期。
设计需求:在四单元中,对于设计的需求十分分散,可以利用大模型进行一个初步的总结,将情景和输出中隐含的一些要求进行归纳总结,以便之后不漏掉一些关键的设计信息。
模型提取:通过大模型可以提取基本的类框架,实现初步建模。
层次设计:大模型可以进一步优化类之间的关系,根据具体需要定义一些接口或者父子类的继承,使类设计更加简洁有逻辑。
修改问题:对于自己的一些架构设计,可以询问大模型修改建议,针对他提出的一些问题进一步做出修改。
测试挖掘: 对于写好的代码,可以询问大模型可能存在的漏洞,帮助测试时进行debug。
经历层次化设计、多线程设计、JML规格设计、UML正向建模与开发四个单元的训练,我在架构设计和代码规划水平上有了较大提升。
通过一学期的OO学习,可以说对面向对象有了更加清晰和实际的认识。不论是从代码的量(开学前几周)还是代码的复杂性(新主楼电梯),都和大一的程序设计不可同日而语,从一开始oopre的手足无措到现在能够独立完成一个大的项目,OO这门课程算是见证了大二这一年的时光,也见证了我编程能力和设计能力的提升。
同时通过强测以及互测机制,我的测试能力也进步不少,学会了使用python编写一些简单的gui和测试程序,对于之后的代码测试也有很大的帮助。
每四周一次的OO仿佛在计算着一个学期,每到一次单元的博客作业仿佛都经历了一场战斗,总的来说,OO的旅途已经结束了,命运的齿轮将继续旋转,而前方将不再有等候着的命运。