电梯调度编写(oo-java编程)

第二单元的问题是写一个关于电梯调度的程序。

需要模拟一个多线程实时电梯系统，从标准输入中输入请求信息，程序进行接收和处理，模拟电梯运行，将必要的运行信息通过输出接口进行输出。

主要锻炼学生的多线程程序编写能力。

由于需要实时的输入和输出，我们不得不采用多线程。

在这个单元中任务仍然被分为三个小任务：

①完成单电梯（随时允许输入）

②单电梯+（楼层增加负层，必须使用比先来先服务更加高效的算法）

③多电梯调度（增加重量限制、楼层停靠限制、换乘）

---

一、调度算法设计

单电梯的调度算法：

我在网上寻找调度算法后发现，网上大多的算法采用的都是静态算法，几乎没有动态算法。所以，我自己设计一个算法（或者说是参照实际使用中电梯的运转方式设计的算法），如下：

①查看该楼层是否有请求（包括进电梯和出电梯），有则开门转②，否则转③

② 让请求的人进出，并进行输出，所有请求进的人将这些人的出电梯请求同时加入电梯的请求序列中。关门转③

③沿电梯运动方向查看是否有任意类型的请求，如果有请求则向该方向运动一层转④，否则改变方向查看请求。如果在另一方向上有请求，则想这一方向移动一层转④。如果两个方向都没有请求则进程休息（wait），等待唤醒，唤醒后转④。

④如果不在输入任何需求则结束，否则转①。

多电梯的调度算法：

多电梯我觉得可以在原来的基础上进行修改，在调度器分配请求时通过某种方式将请求分给不同的电梯，然后每台电梯按照单电梯的调度算法进行运行即可。由于本人的多电梯的调度算法效率比较低，所以这里就不多赘述，可以参考其他同学的多电梯调度算法。

---

二、程序分析

对每次的程序使用MetricsReloaded进行oo度量，使用diagram描绘类图

重要符号意义说明：

• ev(G)基本复杂度是用来衡量程序非结构化程度的.
• Iv(G)模块设计复杂度是用来衡量模块判定结构，即模块和其他模块的调用关系。
• v(G)是用来衡量一个模块判定结构的复杂程度，数量上表现为独立路径的条数。
• LOC: Line of Code
• NCLOC:Non-Commented Line Of Code

P1

oo度量

	LOC	NCLOC	方法个数	属性个数
Elevator	183	169	5	2
Main	9	9	1	0
Midlist	26	26	5	2
OrderClass	46	42	2	7

diagram类图

Sequence Diagram

P2

oo度量

	LOC	NLOC	方法个数	属性个数
Elevator	219	206	10	7
Main	11	11	1	0
Midlist	33	33	6	2
OrderClass	46	62	2	5

diagram类图

Sequence Diagram

P3

oo度量

	LOC	NLOC	方法个数	属性个数
Chart	62	62	5	1
Elevator	307	278	13	14
Entry	8	8	1	0
Main	12	12	1	0
Midlist	367	322	21	19
Orderlist	46	42	2	5

类图

Sequence Diagram

前面的时序图看着太复杂，而三次作业的结构大致一致，于是我做了一个简易版的sequence diagram。

优点：在第一次作业的时候就做好了基础的调度设计，是一个比较有效的设计，在随后的两次作业中修改的内容相对较少，也没有第一单元的重构情况，从类图上看，大体的结构并没有很大的变动。由于调度器不是一个进程，并发控制的难度比较低。

缺点：功能不够独立，在新需求出现时，常常要重新独立出一部分功能。设计时缺少借口等这类设计，导致一修改需求就会违背oo的设计SOLID原则。实际上第一次的设计从某种角度上来讲是存在瑕疵的，调度器不是一个进程，所以调度器在功能欲发复杂的情况下越来越庞大，但是却没有并行性，某种程度上限制了运行的性能。

---

 三、多线程的协同和同步控制

在第一次作业中，需要考虑如何停下自己的程序，我采用的是让中间的管道传递一个状态，即输入端是否关闭，如果关闭则再电梯的所有请求处理完后停止进程。

在第二次作业中，实际上并没有太多的改变（因为我第一次就已经做了优化），但是这次需要避免cpu轮循的问题。那么我在之前的基础上补充电梯wait的要求，应该是输入队列里没有东西，而且输入进程没有停止。

在第三次作业中，为了继承之前作业的架构，我并没有将调度器作为一个独立的进程。但是由于调度器中可能没有属于电梯的请求，这个时候电梯就应该wait，但是就算输入结束了也不能轻易的结束进程，因为有些人可能需要换乘（但这个需求可能还没有出现）。所以我做了下面一个表来处理这个相对复杂的问题。

电梯可以获得的请求	输入端	有无分割的请求 （换乘请求）	电梯动作
√	-	-	运行
×	√	-	sleep
×	-	√	sleep
×	√	√	结束

四、分析自己程序的bug

第一次作业中，程序结束的控制计较容易出bug，因为在程序结束输入的时候（ctrl+D），仅凭借队列里是否有未服务的对象是不够的，还需要有一个判断标志，在电梯每次轮循后对输入是否结束进行判断，从而决定是否结束电梯线程。

第二次作业中，由于不能轮循（因为太占cpu时间），所以必须使用wait/notify方法，这个时候需要考虑好线程有没有可能会死锁，如何才能保证不死锁以及如何控制线程结束。（这三个问题是第二次作业中比较重点的bug/问题）

第三次作业，由于程序难度的增加，程序的复杂，轮循和，进程意外退出，进程没有被唤醒再次成为问题的关键。在这一次中，我最后应该将轮循和进程退出可能的情况进行列表推演，当当靠脑子想这件事情是很不靠谱的！

五、寻找他人bug（我不做互测）

多线程中，PV操作及其重要，关于线程之间的变量必须synchronize，可以着重看这一部分的代码，而且各种状态的传播也会在这一部分中，这一部分代码是最容易出bug的。

根据这次多线程的特点，应该着重考虑多线程的死锁、轮循这两个问题，着重分析他人代码中占用的位置。而且多线程的bug不一定能够触发，所以可能要多试几次。

相比于第一单元，bug的查找更加困难，因为有一些bug是概率性出现的，所以在测试中可以能需要对一个测试样例输入多次（或者选择不同的时间节点输入）。

六、SOLID原则分析

S.O.L.I.D是面向对象设计和编程(OOD&OOP)中几个重要编码原则(Programming Priciple)的首字母缩写。

SRP	The Single Responsibility Principle	单一责任原则
OCP	The Open Closed Principle	开放封闭原则
LSP	The Liskov Substitution Principle	里氏替换原则
DIP	The Dependency Inversion Principle	依赖倒置原则
ISP	The Interface Segregation Principle	接口分离原则

SRP原则分析：在三次作业中，各个类的职责区分的非常清楚，启动线程、调度器线程、电梯线层、请求输入线程都能找到对应的类。

OCP原则分析：在这三次作业中（特别是第三次作业），我没有让三个电梯分别使用不同的策略（也就是说除了基础属性，其他他们都是相同的），所以不存在违背OCP原则的问题。

LSP原则、DIP原则分析:基于这次作业的难度，没有进行抽象和继承。

ISP原则分析：在设计的过程中，我并没有特别在意接口这个问题，所以我觉得这个单元的作业，在这个方面是有问题的。

七、心得体会

这次多线程的作业，让我全面理解了多线程。虽然在不需要涉及各种相对复杂的锁，但是仍然让我在大体上理解了多线程编写所需要的注意点。我希望接下来能够对我的编码进行指引，增加代码的限制，让我的代码更加工业化（能适应企业的要求）。