301
社区成员
发帖
与我相关
我的任务
分享本单元中,我首先通读指导书,梳理了本单元的需求要求,剩下的任务就是根据草稿的需求正向建模UML类图描述架构设计,UML状态图描述图书的不同状态及其转换,UML顺序图表示取得书籍的过程
与图书馆相关的解析与输出操作均已在官方包中给出,故我只需设计图书馆的业务流程即可
统览全局,需要设计学生类、预定类、图书馆的若干业务相关类
学生类处理学生相关的各个操作,由于学生的操作具有唯一性等等性质,同时学生具有信用分等字段,将其糅杂进图书业务部门等关联很小的类中十分冗余,有必要单独建类
预定类负责记录一次预定,由于其既涉及学生层面,又涉及图书层面,还涉及图书业务流程,需要重复若干次,单独建类能使架构清晰
对于整个图书馆系统我主要分成三层结构进行建模:
Dispatcher:协调图书馆的各个机构,处理各种需求,并管理学生总表和书籍借还次数总表等,并按天进行总调度
各个部门:包含各个部门独有的属性,如预定处需要额外的书架来存储已被预约的书,这部分书不参与整理
Shelf:每个部门都拥有的书架,用于抽象对书的具体存储操作
本单元的 UML 类图、状态图、顺序图分别如下:



我的 starUML 崩了,各位看官轻喷(
由于借还处 AppointmentOffice 的预定列表 reservations 具有按照时间先后排序、且反复增删元素的特性,所以我采用了 LinkedList 存储
由于学生对每个书号最多只能存储一个副本,故在 Student 类中我设计了 LibraryBookId 到 LocalDate 的 Map,用于存储持有的书的应还日期
同时我也定义了书架 Shelf 类来包装HashMap和添加取出书的方法 receiveBook、retrieveBook 等
我理解的追踪关系是指:最后的代码实现和最初的UML设计图之间的一致性。UML图中涉及业务逻辑的方法基本都有涉及,具体细节设计处有欠缺。但是从总体上来看,代码设计和UML设计之间有较强的追踪性,也体现了正向建模分析的重要性。
官方包装了 LibraryRequest 类,用于解析用户的输入后传递给图书管理系统,故我也采取此机制作为层次间通信。
我按照需求进行遍历,由于需求具有时间上的偏序性,故事实上也是按照时间顺序遍历。对于各个类别的不同请求,交由不同的方法进行处理。
第一单元我采用了大力推荐的递归下降解析方法和 Poly - Mono 的多项式存储架构,经过 oopre 的训练,已经初步有了高内聚低耦合的意识,并对几种类设计了同名的方法便于调用,在以后的设计中延续了这种方法
第二单元我采用了随机调度+LOOK的策略,将单个电梯作为线程的架构设计,并用 Controller 控制整体的需求调度和线程结束。这也是多线程经典的基础处理架构
第三单元的架构设计主要由JML完成()
第四单元的架构设计采取了上面所述三层结构设计,采取了先正向建模的方法,具体建模不再赘述
通观四个单元,除了 U3 建模由 JML 完成外,我的建模方法逐渐由先写代码再完成扩充到先正向建模,逐步向着科学的方法靠拢
第一单元的数据具有明显的递归嵌套特征,故数据生成的主要思路也是递归,我设置了递归层数等参数,结果验证调用 sympy 库进行比较(需要将 ^ 替换为 **),此外我也带入特殊数据,将运行结果与 Matlab 的结果比较验证
第二单元具体的评测思路是判 false,正确情况较难判断,但出现错误情况较好处理,以下是常见的异常情况:
先下不存在的人后上人
电梯超载
开关门时间和上下人时间不对
停留时间过短过长
遇到这些错误就 return false
因为本单元答案具有唯一性,可以通过简单的字符串比对实现,故我本单元通过生成数据和与其他同学对拍的方式验证结果
第四单元的结果也不唯一,但输入大致类似,故我找了实现思路类似的朋友进行对拍,剩余的正确性验证类似第二单元的判断 false 思路:
要移动的书不存在或移动多次
请求批准与否不一致
此外我也进行了对特定功能的压力测试
学习了很多经典架构与设计模式,架构设计能力有了大的提升
学习了多线程知识,初步具备了设计多线程程序的能力
初步具备了编写和调试千行级别程序的能力
收获了很多不眠的夜晚()
建议第一单元设置合理的难度梯度,留一个阶梯 or 喘息的机会
建议提升一下验题强度(),作为二周目的老登真的看到了课程体系的很大完善,衷心希望改指导书的事情越来越少就好(我个人倒是无所谓,反正我都卡 ddl 开始 debug,主要是怕大家产生情绪之类的)
今年是真心学到了东西,希望课程组越办越好~