电梯作业总结
程序结构与复杂度的分析
第一次作业
1.设计思路
第一次作业是电梯作业的第一次，也是我多线程变成的第一次实践。任务是编写一个多线程实时电梯系统，采用FAFS的调度方式。由于第一次作业中没有涉及到多部电梯以及捎带的情况，因此来说是比较简单的。我采用的是指导书提示部分中的模式，即生产者消费者模式
- 主线程进行输入的管理，使用ElevatorInput，负责接收请求并存入队列
- 开一个线程，用于模拟电梯的活动，负责从队列中取出请求并进行执行，执行完后继续取继续执行
- 构建一个队列，用于管理请求，且需要保证队列是线程安全的
ElevatorInputHanler
在第五次的作业中，我将主线程main直接作为了输入管理进程，原因是看到了知道书中的主线程进行输入的管理，使用ElevatorInput，负责接收请求并存入队列
Request
在理解了题意和指导书中的模式推荐，我觉得这和我之前在《设计模式——可复用面向对象软件的基础》这本书中看到的生产者——消费者模式相近，故我采用了该模式来编写Request类
Elevator
Elevator类就是电梯类，内部保存着电梯的状态（如当前楼层），主要完成电梯在接收到请求之后的上下路以及开关门的操作
整体架构图如下：
2.度量分析
(1)复杂度分析
从图中可以看出在第一次电梯作业中，我的程序的复杂度在一个合适的范围，说明我第一次作业的设计是比较合理的
(2)类规模
在第一次作业中我的每个类的规模都在100行以内，比较合理
(3)时序图
第二次作业
1.设计思路
第二次作业中，电梯仍然是一部电梯，只是算法上用ALS捎带算法代替了FAFS的傻瓜调度，所以整体的架构我还是沿用第一次作业，仍然以生产者消费者模式为主。三各类的功能和第一次作业大体相同，只不过因为ALS算法而添加了不同的方法，在这里不过多赘述， 整体结构图如下：
2.度量分析
(1)复杂度分析
Elevator.deal()函数的代码如下：
private void deal() throws InterruptedException {
sleep(30);
queueRequest = request.getQueueRequest(nowFloor);
if (first) {
request.getAnother(direction, nowFloor);
}
if (queueRequest.size() >= 1) {
int i = 0;
boolean isOpen = false;
while (i < queueRequest.size()) {
if ((queueRequest.get(i).getFromFloor() == nowFloor
&& request.getFlag(i) != 0)
|| (queueRequest.get(i).getToFloor() == nowFloor
&& request.getFlag(i) != 1)) {
isOpen = true;
break;
}
i++;
}
if (isOpen) {
open(nowFloor);
}
i = 0;
while (i < queueRequest.size()) {
if (queueRequest.get(i).getFromFloor() == nowFloor
&& request.getFlag(i) != 0) {
movePeople(nowFloor, queueRequest.get(i).getPersonId(),
"IN");
if (request.getFlag(i) == 1) {
request.setFlag(i, 0);
}
i++;
continue;
}
if (queueRequest.get(i).getToFloor() == nowFloor
&& request.getFlag(i) != 1) {
movePeople(nowFloor, queueRequest.get(i).getPersonId(),
"OUT");
queueRequest.remove(i);
request.removeFlag(i);
continue;
}
i++;
}
if (isOpen) {
sleep(timeOpenOrClose * 2);
close(nowFloor);
}
queueRequest = request.getQueueRequest(nowFloor);
if (first) {
request.getAnother(direction, nowFloor);
}
}
}首先，从代码中很容易看出里面包含了很多的if分支以及if分支的嵌套，这导致了v(G)的数值很大；并且在函数内部的request.getQueueRequest()函数是对Request实例方法的调用，并且在其中调用了很多的本类中的方法，增加了模块与模块之间的调用，所以iv(G)的数值高；总体的导致整体复杂度ev(G)的提高。
Request.getAnother()的代码如下：
public synchronized void getAnother(int direction, int nowFloor) {
if (!queue.isEmpty() && queue.get(0) != null) {
int i = 0;
while (i < queue.size()) {
if (queue.get(i) != null) {
if ((queue.get(i).getToFloor() - queue.get(i)
.getFromFloor()) * direction > 0
&& (nowFloor - queue.get(i).getFromFloor())
* (nowFloor - queue.get(i).getToFloor()) >= 0) {
queueRequest.add(queue.get(i));
flag.add(-1);
queue.remove(i);
continue;
}
}
i++;
}
}
}从中可以看车里面的if分支的条件判断十分复杂，并且存在嵌套，这大大提高了程序调试的难度，我在第二次作业中出现的BUG也正是因为这个方法中的条件判断出现了问题。
Request.getQueueRequest()方法的代码如下：
public synchronized ArrayList<
PersonRequest> getQueueRequest(int nowFloor) {
while (queue.isEmpty() && queueRequest.isEmpty()) {
try {
wait();
} catch (InterruptedException e) {
e.printStackTrace();
}
}
if (queueRequest.isEmpty()) {
queueRe