OO Unit4 Summary

回顾一下第四单元完成的任务:利用UML进行正向建模,并完成一个小型的图书馆管理系统

  • hw13:实现借阅,预约,预约取书,还书等基本流程
  • hw14: 实现图书室借阅功能,并增加热门书架与普通书架
  • hw15:引用用户信用积分限制

一、正向建模与开发

正向建模与开发是一种软件工程方法,主要用于系统设计和实现过程中,特别是在软件开发和硬件设计领域。这种方法从高层次的需求和概念开始,逐步细化和分解,直到实现细节,整个过程类似于从宏观到微观的构建方式。正向建模与开发强调从抽象到具体、从整体到部分的设计思想,有助于确保系统设计的连贯性和完整性,便于团队成员理解整个系统的工作原理。

OO作业是迭代性任务,一个良好的初期架构对于后期作业的顺利完成是十分重要的,本单元中,课程组的初衷是先绘制UML类图等进行正向建模,并据此进行后续开发。对此,我的做法是首先设计整体框架,抽象出主要类例如书架、借还处、预约处等类,将类聚合到一个总体类图书馆中,对不同操作抽象出一些大的方法,得到一开始的粗略图。在图书馆类中针对不同操作抽象方法,调用不同的组成部分调用其内部具体实现方法,在通过代码具体实现每个组成功能时完善原有的图,样在一开始设计图时不必关心下层设计,在编写代码时又有清晰的参考,以此实现图和代码的同步推进。

实际上,这样的结果是并未直接开展UML设计,而是箭和靶子同步画,不经过任何代码直接得到十分全面的UML图还是过于困难。

二、本单元架构设计与UML追踪

ClassDiagram1

2.1 第一次架构设计

第一次功能相对简单,实现了以下几个类

  • Apooffice:预约处,处理预约请求并为对应顾客留存对应的书
  • Brooffice:借还处,用于通过借阅以及预约取书拿到的书都会在此处归还
  • Bookshelf:书架,保存依旧属于书架中的书
  • BookManager:图书历史记录管理
  • UserBookApointmentRecord:用户类、图书类、预约记录、历史记录
  • Library:类似于一个抽象的图书馆类,用于各个部门与输入输出的交互实现

实际上,代码中应有的类在指导书以及oolens的推送中已经暗示的非常明显了。

但联系现实生活,一本书不应知道除书本记录的文字内容之外的信息,所以我用管理器管理历史记录,类似于现实生活中的图书查询系统。

2.2 第二次架构设计

本次作业新增了热门书架,阅读,归还等功能。

为避免对架构的改变,我在Library中设置了两个Bookshelf的实例,分别对应普通书架与热门书架。并在开馆整理时候将对应的书移到相应书架,并通过removeBook的返回值来告知外界其来自哪个书架。

新增阅读室Readingroom,完成阅读以及归还功能,并在每日闭馆的整理过程中将阅读室剩余的书整理回书架。

2.3 第三次架构设计

本次作业中引入了用户信用分系统,对用户的行为做进一步限制,同时新增了图书借阅期限的限制。

维护一个容器,在其中记录所用被借阅或者预约取书拿走还未通过return请求归还的书。在借阅和取书成功后加入该容器,并在书中存储对应的截止日期与用户id等信息。在每日闭馆后对逾期未还书的用户进行信用分扣除。

由于开馆闭馆日期的不连续,我们需要注意在每日开馆时候计算扣除包括两次开馆之间间隔天数对应的信用积分,同时更新上一次扣除过的日期。

三、大模型辅助正向建模

  • 设计需求:在四单元中,对于设计的需求十分分散,可以利用大模型进行一个初步的总结,将情景和输出中隐含的一些要求进行归纳总结,以便之后不漏掉一些关键的设计信息。

  • 模型提取:通过大模型可以提取基本的类框架,实现初步建模。

  • 层次设计:大模型可以进一步优化类之间的关系,根据具体需要定义一些接口或者父子类的继承,使类设计更加简洁有逻辑。

  • 修改问题:对于自己的一些架构设计,可以询问大模型修改建议,针对他提出的一些问题进一步做出修改。

  • 测试挖掘: 对于写好的代码,可以询问大模型可能存在的漏洞,帮助测试时进行debug。

四、OO架构设计思维的演进

经历层次化设计、多线程设计、JML规格设计、UML正向建模与开发四个单元的训练,我在架构设计和代码规划水平上有了较大提升。

  • 层次化设计——U1:这一单元主要训练层次架构设计能力。通过不同种类因子的类的设计和相互交互,我对复杂结构的设计有了更加清晰的认识,递归下降的思路帮助我建立了抽象思维,对于更加大型的项目也能够得心应手。正则表达式的使用也使我掌握了文本匹配的方法,对于类似的语句递归解析有了更加深刻的认识。
  • 多线程设计——U2: 这一单元主要训练多线程设计能力。对于多线程设计,我们应该首先明确任务场景,确定需要作为线程的类,在确定各个线程应该完成的工作后,下一步确定各个类之间的交互关系,接下来确定交互区域,保证多线程安全。对于多线程,如何保证并发访问的安全性是重中之重,不论是利用同步块还是java的锁,都需要考虑死锁和等待问题,提高多线程安全性和效率。
  • JML规格设计——U3: 这一单元我们主要训练规格化设计能力。规格化的功能描述对程序开发十分重要,能够保证语义的确定、唯一、简洁,对于大型项目或者多人开发有着至关重要的作用,对比自然语言,JML有着严谨清晰有逻辑的优点,但是自然语言有时候会更加符合人类的描述和直观描述,因此,JML和适当的自然语言结合是一种折中而又不失严谨性的做法,可以帮助我们更加容易地进行项目开发。
  • UML正向建模——U4: 这一单元我们主要训练使用UML进行系统建模与开发。一个清晰的初期架构设计对于复杂系统的开发是极其重要的的,通过对情景和要求进行分析,进行类和方法的提取,并根据具体的交互进行类之间关联、继承、实现的设计,可以使开发过程变得简单严谨,同时便于进行系统的整体展示和设计。

五、OO测试思维的演进

  • U1:在层次化设计单元,我主要针对出现的各种情况的表达式进行构造设计,对一些有代表性的特殊数据进行构造,同时定义一些基本组成式子,通过程序进行批量化随机组合嵌套,进行随机化测试。
  • U2: 在多线程单元,我主要进行压力测试和边界条件测试。多线程设计中容易出现的便是并发访问的问题,对于测试数据的并发强度要求较高,手动构造耗时耗力。因此,我主要搭建了评测机,通过同一时刻投放大量请求以及多线程评测等方法加大测试强度,对于随机测试不能覆盖的问题,我使用手动构造边界楼层或者独立申请电梯的用户个体,实现边界数据的测试。
  • U3: 在规格化设计单元,我主要进行了单元测试。对于规格设计明确的系统,数据范围与边界明确,我们可以利用Junit等单元测试工具,对于一些易出错或者关键方法进行测试验证,编写参数化设计的Junit进行大批量测试,同时也对一些特殊结构进行特判。
  • U4: 在UML正向建模与开发单元,我们主要基于模型进行黑盒测试。通过分析UML类图,我们可以在开发之初便明确待测模型各个类的功能以及交互关系,并对此进行覆盖性测试。通过评测机生成根据之前状态的输出的输入,进行状态转移,同步判断代码的转移正确性。

六、课程收获

通过一学期的OO学习,可以说对面向对象有了更加清晰和实际的认识。不论是从代码的量(开学前几周)还是代码的复杂性(新主楼电梯),都和大一的程序设计不可同日而语,从一开始oopre的手足无措到现在能够独立完成一个大的项目,OO这门课程算是见证了大二这一年的时光,也见证了我编程能力和设计能力的提升。

同时通过强测以及互测机制,我的测试能力也进步不少,学会了使用python编写一些简单的gui和测试程序,对于之后的代码测试也有很大的帮助。

每四周一次的OO仿佛在计算着一个学期,每到一次单元的博客作业仿佛都经历了一场战斗,总的来说,OO的旅途已经结束了,命运的齿轮将继续旋转,而前方将不再有等候着的命运。