OO Unit4 总结（终于结束了）

符悦-21231042 学生 2024-06-11 16:43:46

UML

统一建模语言（Unified Modeling Language，简称UML）是一种标准化的建模语言，用于规范化描述软件系统的结构和行为。它提供了一套图形化的符号和规则，用于描述系统的各种元素及其相互关系，常用于软件开发的需求分析、设计和文档编制阶段。本单元的主要任务其实是用UML来进行设计，然后根据设计用Java做具体的实现

UML的主要图表类型

本单元用到了三种UML图标

类图（Class Diagram）：描述系统的类及其属性、方法和相互关系。
序列图（Sequence Diagram）：描述对象之间按时间顺序发生的交互。
状态图（State Diagram）：描述对象在其生命周期中所经历的状态及状态之间的转换。

UML在Java开发中的应用

个人开发：在本单元的实践中，UML其实不是很能体现出它的优点。由于本次单元仍然是个人开发，在开发的实践中我们会发现，即便提前用UML做好架构设计，具体的实现中仍然会进行修改，一来一回反而没有直接写代码来的顺畅。在个人开发中，我认为UML其实作为一种可视化效果好的注释
团队开发：这才是UML真正展示其威力的地方。在团队开发过程中，很难直接把架构先以代码的形式做好，并且从架构师手中分发到每一个开发者手里，这里就体现出了UML的优点了，通过总的先做架构设计，然后再分发到每个人手中做具体的实现，可以很好的完成分工合作。

UML工具

本单元使用StarUML进行建模（不好用，浪费提交次数）

架构

本单元的架构主要分为以下几个部分

Library：图书馆的实体，包含了图书馆的各个部分
- BookShelf：书架，实现了对图书进行存取分类的功能，广泛应用于图书馆的各个部分
- BorrowReturnDesk：借还处
- Drifting：漂流角
- ReservationDesk：预约处
Book：包含Book类和BookType枚举
User：管理用户的部分，管理类结构为UserData-UserDataNode-User
- User：存储用户信息的节点
- UserDataNode：存储User的索引和预约信息（这似乎没有必要增加一层索引）
- UserData：存储用户信息的总数据结构
Request：包含了请求（实际上只有预约请求一种子类）

Library

这部分其实没什么太多的好说的，最好用的是实现了一个统一的BookSelf类来管理不同的书，并且做了统一的接口，这个类被用于每一个需要用数据结构来管理书籍的部分，非常方便

Book

单纯是因为先写没有考虑到官方包输入输出接口做的类，由于要适配官方包，里面有大量在官方枚举和自己枚举的转换代码

public Book(LibraryBookId.Type type, String bookId) {
        switch (type) {
            case A:
                this.type = BookType.A;
                break;
            case B:
                this.type = BookType.B;
                break;
            case C:
                this.type = BookType.C;
                break;
            case AU:
                this.type = BookType.AU;
                break;
            case BU:
                this.type = BookType.BU;
                break;
            case CU:
                this.type = BookType.CU;
                break;
            default:
                this.type = null;
        }
        this.bookId = bookId;
        this.uuid = UUID.randomUUID();
        this.donateUser = null;
    }

此外，每本书的唯一标识被设定为一个字符串BookType+BookId，这个唯一标识被称为BSBN（BUAA Standard Book Number），提供了很多相互转换的静态函数

public static String bsbn2BookId(String bsbn) {
        BookType type = bsbn2BookType(bsbn);
        switch (Objects.requireNonNull(type)) {
            case A:
            case B:
            case C:
                return bsbn.substring(1);
            case AU:
            case BU:
            case CU:
                return bsbn.substring(2);
            default:
        }

        return null;
    }

User

对用户信息做了比较简单的管理，这部分其实应该跟Reservation联系起来，把跟每个用户相关的预约信息存储到用户节点里面去的（但是一开始脑抽了没这样做），最后导致预约信息一部分保存在借还处，一部分保存在用户节点里面，预约信息的流动变得很复杂，删增都不是很方便

Request

保存了用户的请求（实际上只有预约）信息，包括时间等等。

架构-UML

其实我是先写了代码，再画的UML。

整体来说UML提供了一个很清晰的类与类之间的关系和类之间的信息流动关系，我整体上把UML当做一种比较好用的注释使用。

四个单元架构设计思维的演进

~~首先，三个单元（JML有什么用啊）~~

第一个单元相比架构更多的还是算法吧，整体上第一个单元的解析器不需要很复杂的架构设计（大多数设计都来源于学长学姐之前的经验），由于问题不是很简单，实现起来也比较麻烦，正确率和自己写的代码都不是很满意。
第二个单元应该算是OO最OO的一集了，也是写的最爽的一个单元。第二单元的架构完全依赖于自己的设计，算法上能够利用的往届经验也很少，大部分还是靠自己的设计，多线程编程也很有意思（而且很实用）。这个单元应该算是我自己做的最满意的一次架构设计。
JML真不想谈，什么时候删一下。
UML单元整体难度偏低，能设计的角度也不多，最重要的地方还是要看清楚题目要求。