BUAA_OO 第四单元：图书馆（UML）总结

最新推荐文章于 2024-07-12 16:26:30 发布

于耀博-22373393

最新推荐文章于 2024-07-12 16:26:30 发布

阅读量610

点赞数 18

文章标签： uml java

本文链接：https://blog.csdn.net/m0_74774220/article/details/139635726

版权

文章目录

前言

OO第四单元类似于第三单元一样，有自己的任务主题，同时借着这个主题学习UML建模语言
任务主题是图书馆借书这样一个业务场景，算法层面并没有什么困难之处，注意自己的实现要面面俱到即可；UML上则需要下功夫，好在可以借助staruml的图形化交互来辅助快速画图

正向建模与开发

我从最开始并没有想要正向建模，反而因为要画UML类图，我的初步想法是我一定不要为难自己：不要创建过多的类，类和类之间的关系能多简单就多简单，以至于我的架构核心是把业务处理流程全部放到main类里，main与其他类为依赖关系。算是因祸得福，我最后发现那这个main类其实就是一个library呀，但我不想更改他的名字了，所以最终我的类图如下：

在这里插入图片描述

我应该算是先写代码再去画类图，因为我觉得我先画类图再写代码肯定要做很多类图上的更改，我没有把握在第一次画类图的时候就想的面面俱到，但是我认为在我写代码的过程中，其实也是建模的过程，只是没有体现在UML而是直接体现在代码上。譬如写到时间需求的时候——逾期还书，预约逾期等，我就想到了要建立一个TimeBook类作为载体，来处理时间相关的业务。

架构设计

从可拓展性上来讲我觉得我的架构并不差，只是Main类有点过于庞大，业务处理逻辑基本都堆积在Main类里，但是这样子我想要增加一个功能，我只需要在Main类里增加一个deal*方法，然后再去让各个部门（书架、借还处、预约处、图书漂流角、用户）交互

我的架构设计还是很清晰明了的，上面一段话基本上就涵盖了我的大体实现思路，其中小的细节值得提的如TImeBook的设立、Main类里全局管理所有的对象。

从上面类图就可以看出TimeBook类中有MaxSaveTime、MaxReturnTime等属性，当我需要处理与时间有关的业务的时候，我就创造一个TimeBook对象，他并不是唯一的映射图书的对象（本次作业中我并没有把图书实体化，而是应用BookId这一官方包实现的类来代替一本书），而更像是一个计时器，当用户取书后，用户得到一个TimeBook，当他还书之后，这个对象也就随之消失了，只是将BookShelf的BookId数加一，故而更加灵活，也可以根据后续的需求做更改

Main类里管理所有的对象交互，具体的架构如下：

//Main.java
public static void main(String[] args) {
	Bookshelf bookshelf = new Bookshelf();
	BorrowingAndReturningOffice bandR = new BorrowingAndReturningOffice();
	ReservationCounter reservationCounter = new ReservationCounter();
	TuShuPiaoLiuJiao tuShuPiaoLiuJiao = new TuShuPiaoLiuJiao();
	HashMap<String, User> users = new HashMap<>();
	HashMap<String, Integer> usersCre = new HashMap<>();

	libraryRun(bookshelf, bandR, reservationCounter, users, tuShuPiaoLiuJiao, usersCre);
}

private static void libraryRun(Bookshelf bookshelf, ...) {
     ...  
    else if (type.equals(LibraryRequest.Type.BORROWED)) {
    	dealBorrow(bookshelf, bandR, request, studentId, bookId, users, tsplj, usersCre);	
	else if (type.equals(LibraryRequest.Type.RETURNED)) {
    	dealReturn(studentId, bookId, bandR, request, users, tsplj, usersCre);
	else if (type.equals(LibraryRequest.Type.ORDERED)) {
    	dealOrder(studentId, bookId, reservationCounter, request, users, usersCre);
	else if (type.equals(LibraryRequest.Type.PICKED)) {
    	dealPick(studentId, bookId, reservationCounter, request, users, usersCre);
	...

这样子大多数耦合都是Main类与各个部门的耦合，可以降低不同的部门之间的耦合

架构设计思维的演进

第一单元设计思维算是借鉴了以往的“最佳实践”，即寻找基本项，其实也是层次化设计的一种体现形式，结合递归下降法解析表达式，然后将表达式转化为基本项，利用基本项与基本项的四则运算进而得到化简结果。架构设计的思维吸收了层次化这一概念
第二单元的设计思维则也是借鉴了生产消费者模式，更多的侧重点在于线程安全，同时也做算法提速上的考量。由于是第一次写多线程代码，难点主要在于类与类之间的交互是否是安全的，如何设计同步互斥成了这一单元的重点考量。架构设计的思维吸收了线程安全（同步互斥）这一概念
第三单元的设计思维则更加偏向于已有的图论算法，由于整体架构都是课程组给出的，我们的考量也就只能停留在算法层次（或者是只实现基本的JML要求的功能），相当于这次的架构不是我们来设计，而是我们要去实现别人设计出来的架构。架构设计的思维吸收了JML这一概念
第四单元的设计思维则更加偏向于UML统一建模语言，课程组的设想是先画图，做宏观上的架构设计，再去具体写代码实现，是一种好习惯。架构设计的思维吸收了UML这一概念

测试思维的演进

测试是很重要的，如果充分做好测试，我也不会扣这么多分（哭死

第一单元算是我最测试最积极的阶段，初步对黑盒测试有了概念，即数据生成与正确性判断两部分，其中各有各的难处：数据生成强调数据的质量，完全随机并不是一个好的选择，一些边缘数据或者特殊构造可能更具有测试效力；正确性判断则需要全面性，例如第二单元电梯的正确性判断是像而言不太好写的，需要模拟电梯具体运行；进一步有能力还可以做性能测试，如第一单元的最终输出字符串长度，第二单元的时间性能（按照课程组给出的性能判定），根据测试人数的增多，可以给出一个大概的分数分布，可惜我们这一届没有人做这个工作，不然还是很有趣的（~~我为啥不做？我菜啊~~
三四单元可能因为大家的OS压力增加，且具体代码难度有所下降，导致测试做的不够积极，这也导致我因为很多简单问题而扣分，还是很伤的。可以做简单的黑盒测试，正确性判断依靠对拍或正确性分析等都可，当然U3还引进了白盒测试，即检测方法的运行前后是否符合JML规格要求，但是成本颇高，需要写很多Junit测试代码