OO第二单元总结

目录

• HW1
  • 思路
  • 程序结构
    • UML分析
      • Class Diagram
      • Sequence Diagram
    • 代码规模分析
    • 复杂度分析
• HW2
  • 思路
  • 程序结构
    • UML分析
      • Class Diagram
      • Sequence Diagram
    • 代码规模分析
    • 复杂度分析
• HW3
  • 思路
  • 程序结构
    • UML分析
      • Class Diagram
      • Sequence Diagram
    • 代码规模分析
    • 复杂度分析
• 总结
  • Test n Bugs
    • 测试方法
    • 测试情况
  • SOLID原则
    • SRP
    • OCP
    • LSP
    • ISP
    • DIP
  • 心得体会
    • 线程安全
    • 设计原则

HW1

思路

本次作业，需要完成的任务为单部多线程可捎带电梯的模拟。

在IO处理中，本次作业使用官方包，不需要进行格式检查。

电梯系统可以采用任意的调度策略，基于LOOK算法，本次作业中的调度策略思路为：

如果电梯中有乘客，电梯按照原始方向继续运行，捎带中途所有乘客；

如果电梯中没有乘客，电梯运行到当前有请求的最近楼层或停止运行等待请求；

当电梯所移动的方向上不再有请求时立即改变运行方向。

本次作业采用生产者消费者模式:

Scheduler类维护了共享的请求队列，以及volatile类型的end flag；

Input类为生产者，读入Passenger请求，加入请求队列；

Elevator类为消费者，取出Passenger请求，加入电梯内部的Passenger队列。

程序结构

分析工具：UML，MetricsReloaded，Statistic，DesigniteJava

UML分析

Class Diagram

Passenger类封装了以官方包中PersonRequest为基础的一些新操作，方便之后的迭代开发。

Scheduler类为共享对象，共享请求队列与结束标志变量，有基于调度策略的methods。

Elevator类作为消费者，包含描述电梯状态的各种变量，封装了电梯的基本运行、调度运行methods。其中维护了电梯内Passenger的Set，使用其有序性方便电梯调度。

Input类作为生产者，调用官方输入包读入请求。

在Main中，创建了共享Scheduler对象的一个生产者线程和一个消费者线程。

Sequence Diagram

代码规模分析

Total LOC analyzed: 295

Number of classes: 5

Number of methods: 30

属性和方法规模见Class Diagram

复杂度分析

其中OCavg代表类的方法的平均循环复杂度，WMC代表类的方法的总循环复杂度。

其中Essential Complexity (ev(G)、Module Design Complexity (iv(G)）、Cyclomatic Complexity (v(G)。

总体上代码复杂度低。Elevator类中的run方法进行了结束判断以及等待请求判断。这里的等待请求处理利用了阻塞容器的方法，增加了一些判断，造成了复杂度高。实际上到后边的作业发现还是需要自己扩展取请求方法。

Type Name	Method Name	Implementation Smell	Cause of the Smell
Elevator	updateState	Complex Conditional	The conditional expression ((boardList.first().getToFloor() > currentFloor) && (currentState == -1)) || ((boardList.last().getToFloor() < currentFloor) && (currentState == 1)) is complex.

updateState这一method中判断电梯是否需要转换方向这一判断条件复杂。

HW2

思路

本次作业，需要完成的任务为多部多线程可捎带调度电梯的模拟。另外，相比第一次作业，增加了电梯的载客量限制。

思路和HW1基本相同，沿用HW1的架构。增加了ElevatorControl类，用于创建多部电梯。

程序结构

UML分析

Class Diagram

ElevatorControl类根据输入的电梯数创建多部电梯。

Elevator类中增加了capacity属性，只需在进入电梯的boarding方法中加入容量限制即可。

其他类同HW1。

Sequence Diagram

代码规模分析

Total LOC analyzed: 353

Number of classes: 6

Number of methods: 33

属性和方法规模见Class Diagram

复杂度分析

整体在HW1基础上修改不多。

Elevator类中的run方法进行了结束判断，当电梯内无人且输入结束且请求队列为空时结束，这里复杂度高。但是相比HW1，封装了取出请求的调度方法，复杂度有所下降。

当电梯运行到每一层，都会调用Scheduler类中的boarding方法进行捎带。此方法中遍历请求队列加入可稍带对象，此时复杂度高，在后续的作业中使用map容器，以floor为key，可以简化遍历操作。

Type Name	Method Name	Implementation Smell	Cause of the Smell
Elevator	updateState	Complex Conditional	The conditional expression ((boardList.first().getToFloor() > currentFloor) && (currentState == -1)) || ((boardList.last().getToFloor() < currentFloor) && (currentState == 1)) is complex.

同HW1。

HW3

思路

本次作业，需要完成的任务为多部多线程可捎带调度电梯的模拟。相比上一次作业，增加了实时增一部可以使用的电梯的功能，并且本次多部电梯的可停靠楼层，运行时间，最大载客量为不同的固定值。

沿用上一次作业的架构，另外：

将请求以queue修改为请求map，以FromFloor为key，简化调度相关的methods；

由于存在中转乘客，Elevator类既是生产者，又是消费者。中转乘客在第一程结束后出电梯，产生第二程新请求加入请求队列；

对于中转的处理：

根据电梯的可达楼层可发现中转乘客仅需中转一程；

不预先规划路线，根据实时电梯运行情况进行捎带（即不更改捎带规则），之后随机选择中转站避免电梯负荷不平均；

设置passenger的type、directWay、nextRoute属性描述passenger的中转信息。属性使用one-hot编码方便计算。

修改结束标志。设置cnt记录目前请求数量，中转乘客出电梯时不减cnt（中转乘客的第二程一定为直达类型）；

封装官方输出包为线程安全包。

程序结构

UML分析

Class Diagram

Scheduler类为共享对象，共享请求请求hashmap、Input线程结束标志变量、Elevator线程结束标志变量。增加types属性用于调度中的捎带方法。

Elevator类作为生产者和消费者。

Input类作为生产者，调用官方输入包读入请求。

ElevatorControl类增加实时添加一部电梯方法。

其他同HW2。

Sequence Diagram

代码规模分析

Total LOC analyzed: 532

Number of classes: 7

Number of methods: 48

Type Name	Method Name	LOC	CC	PC
SafeOutput	println	3	1	1
Scheduler	Scheduler	9	2	0
Scheduler	setElevatorEnd	4	1	0
Scheduler	getEnd	3	1	0
Scheduler	setEnd	4	1	0
Scheduler	updateTypes	13	3	2
Scheduler	biType	11	3	1
Scheduler	add	7	1	2
Scheduler	boarding	29	8	3
Scheduler	findNearest	23	5	3
Scheduler	toString	3	1	0
Scheduler	isEmpty	3	1	0
Scheduler	isEmpty	8	3	2
ElevatorControl	ElevatorControl	7	1	1
ElevatorControl	createElevator	19	4	3
ElevatorControl	runDefault3Elevators	6	2	0
ElevatorControl	addnRun	5	1	2
Elevator	Elevator	14	1	8
Elevator	getnickname	3	1	0
Elevator	toString	3	1	0
Elevator	printState	8	2	2
Elevator	printState	8	2	3
Elevator	aMove	12	3	0
Elevator	sleep4awhile	8	1	1
Elevator	rush	17	5	1
Elevator	in	14	4	1
Elevator	out	19	5	0
Elevator	update	14	3	0
Elevator	updateState	18	5	0
Elevator	run	20	4	0
MainClass	main	9	1	1
Input	Input	5	1	2
Input	run	26	5	0
Passenger	Passenger	14	3	4
Passenger	getType	3	1	0
Passenger	isdirect	3	1	2
Passenger	isinrange	3	1	3
Passenger	addTransit	12	3	3
Passenger	splitRoute	6	1	3
Passenger	getDirectWays	3	1	0
Passenger	getNextRoute	3	1	0
Passenger	getFromFloor	3	1	0
Passenger	getPersonId	3	1	0
Passenger	getToFloor	3	1	0
Passenger	equals	10	3	1
Passenger	hashCode	3	1	0
Passenger	compareTo	9	3	1
Passenger	toString	3	1	0

复杂度分析

飘红情况同HW2，另外，由于在Scheduler类的增加封装了调度的方法，Elevator类的复杂度相比HW2稍有下降。

Type Name	Method Name	Implementation Smell	Cause of the Smell
Elevator	updateState	Complex Conditional	The conditional expression ((boardList.first().getToFloor() > currentFloor) && (currentState == -1)) || ((boardList.last().getToFloor() < currentFloor) && (currentState == 1)) is complex.
Input	run	Long Statement	The length of the statement "scheduler.add(new Passenger(((PersonRequest)request).getPersonId()'((PersonRequest)request).getFromFloor()'((PersonRequest)request).getToFloor()`1)'1);" is 151.
Scheduler	isEmpty	Complex Conditional	The conditional expression (!storageTakers.get(key).isEmpty()) && (floors.contains(key)) && ((biType(key) & (tp)) != 0) is complex.isEmpty

第一条同HW2。

中转乘客结束第一程后会增加新的第二程请求，为了重用Passenger的构造函数，更改参数列表后，对于输入中的创建请求语句长度过长。这里可以override。

在调度策略中，当电梯为空时，将寻找最近请求楼层，此调度方法中就包含了复杂判断：此楼层存在请求且此楼层为可达楼层且此楼层中请求可稍带。

总结

Test n Bugs

测试方法

本单元的测试方法和上一单元有所不同，设置断点的方法往往不能发现线程安全问题，所以主要采用System.err.println通过输出信息进行debug。

对于一个bug,通过批量随机测试+重复测试先判断此bug为线程安全性bug或非线程安全性bug。非线程安全性bug按照以往经验定位修改即可；由于线程安全问题的不可复现性，通过随机测试发现总结错误特点，将涉及共享资源部分逐步检查是否存在不安全问题。

• 基础性测试

构造所有可能出现的进出楼层电梯搭配进行基础性测试。

• 自动化测试

使用bash，python package subprocess、random、signal进行随机测试用例生成、合法检查。

生成测试用例并结合重定向运行代码；

with subprocess.Popen([r'java', r'-jar', r'Elevators.jar'],
                      stdin=subprocess.PIPE,
                      text=True,
                      stdout=open(r'stdout.txt', "w"),
                      stderr=open(r'stderr.txt', "w")
                      ) as subpcs:
    covernRun(subpcs, 'test.txt')

按照指导书中的正确性要求进行检查；

保存结果到文件。

测试情况

• 互测中主要采用自动化测试的办法。在第一次作业中，hack到电梯层数的bug（floor=0）。
• 在第三次作业中，被hack到关于结束标志设置的bug，当所有乘客请求均满足的一段时间后以增加电梯请求为输入结束，这时我的程序无法结束。是因为我在调度算法的“当电梯为空则寻找最近请求”这一方法中的结束标志设置不完全。这里出现问题也因为盲信自动随机评测，没有手动构造有针对性的覆盖性测试用例。比如关于程序的结束是一个重要问题点，对于这一点应进行重点测试。
• 在第三次作业中room内大多数同学都hack到了bug，但是我跑的自动评测机一直没有hack成功，后来总结发现手动设计测试用例的重要性。

SOLID原则

设计原则：关于设计的整体要求和约束，通过满足设计原则来获得好的设计质量。

设计原则是对OO设计思维的整体要求。

SRP

Single Responsibility Principle每个类或方法都只有一个明确的职责，所以类所管理的数据应“聚焦”。

Elevator类管理电梯的状态，实现了电梯简单的开关门，上下人，上下运行的方法。Scheduler类负责调度的方法，职责划分明确，互不影响。

OCP

Open Close Principle无需修改已有实现，而是通过扩展来增加新功能。

这次电梯的设计可扩展性较好，三次作业均改动不多，沿用架构。总体架构基于生产者消费者模式。

Scheduler类维护共享资源，根据调度策略可扩展相关调度方法；结束标志也在三次作业中体现了扩展性。

Input类作为生产者，调用官方输入包读入请求，当输入请求类别增加时，Passenger类相应扩展了其构造函数。

Elevator类作为生产者和消费者，当电梯增加新维度的约束时可在此类增加属性和方法，电梯参数在构造方法时传入，方便新增电梯。

LSP

Liskov Substitution Principle任何父类出现的地方都可以使用子类来代替，并不会导致使用相应类的程序出现错误。

本次作业中Passenger类封装了官方包中PersonRequest，相当于继承了此类，并实现了Comparator接口，用于建立电梯内乘客的有序set。

ISP

Interface Segregation Principle通过接口来建立行为抽象层次具有更好的灵活性。

本次作业中没有使用接口。

DIP

Dependency Inversion Principle通过接口来建立行为抽象层次具有更好的灵活性。

输入和输出模块互不依赖，各个电梯互相独立。

但是对于调度器和电梯的通信应通过一个消息类抽象，而不是具体的容器。

心得体会

线程安全

在HW1的自动测试中就发现了线程安全问题的不可复现性，因为习惯于断点定位的debug pattern，第一次main对此就有些措手不及，但是随着后边几次作业测试中陆续遇到了线程安全问题进行debug，发现多线程的安全性问题从测试结果中就可大致定位，并且代码中对于共享资源的维护与访问一共也不多，逐部排查总能发现（go off my loop ^_）。另外，线程安全问题也在很大程度上依赖于手动设计魔鬼测试去发现，在这一点上本次作业做得还不够（比如自己写着写着第三次作业发现结束信号设置的有问题-> 我是怎么通过第二次作业的 -> 第二次作业中没有构造这种测试情况用例进行测试）。

System.err.println真的很好用。

我遇到的线程安全问题有：

电梯在“空时寻找最近请求”中轮询。后修改了进入寻找的条件以及增加wait。

运行不结束。后修改了结束标志，通过输入请求结束标志、电梯为空、请求队列为空、电梯线程结束标志协同控制。

当无输入请求时，电梯在“空时寻找最近请求”中死锁等待。后修改了进入等待的条件。

设计原则

多线程部分总体设计比较简单，在实现安全性时只需要维护共享资源的安全性。

我认为要遵守OCP原则，SRP原则是很重要的一点。在第一次设计时就将职责合理划分，输入、调度、电梯，于是可扩展性就很好。