结对项目——电梯调度(5)

by 潘

Part 0 进度概述

目前为止，整个项目已经完成，底层逻辑、UI界面、软件测试都已完成，对底层逻辑：对调度算法进行了模块化，使得每种调度算法存在一个专门的函数，但某个电梯学院需要采用某种调度算法时只需要调用该算法即可，目前已经完成的调度算法有：Bus、LOOK、FD-SCAN。UI界面：我们为电梯设计了内部按钮以及外部按钮，并通过按钮的颜色变化观察电梯所处楼层以及信号。对软件测试：我们利用了visual studio附加的功能，进行了分支覆盖率测试、单元测试、系统测试等。这些我将在下面详细叙述。

Part 1 PSP

PSP2.1	Personal Software Process Stages	预估耗时（分钟）	实际耗时（分钟）
Planning	计划	30	30
· Estimate	· 估计这个任务需要多少时间	20	10
Development	开发	7200	6000
· Analysis	· 需求分析 (包括学习新技术)	400	180
· Design Spec	· 生成设计文档	30	60
· Design Review	· 设计复审 (和同事审核设计文档)	20	10
· Coding Standard	· 代码规范 (为目前的开发制定合适的规范)	10	10
· Design	· 具体设计	60	40
· Coding	· 具体编码	600	500
· Code Review	· 代码复审	1920	1200
· Test	· 测试（自我测试，修改代码，提交修改）	600	600
Reporting	报告	145	380
· Test Report	· 测试报告	100	300
· Size Measurement	· 计算工作量	15	20
· Postmortem & Process Improvement Plan	· 事后总结, 并提出过程改进计划	30	60
	合计	11180	9400

Part 2 小队分工

这一阶段我们依旧按照以前的分工，我主要负责程序的实现和UI界面的设计，曹主要负责软件测试，包括单元测试、分支覆盖率等。但曹也会参与到代码实现的过程，我也会负责一部分软件测试的工作。

Part 3 实现内容

3.1 调度算法模块化

在项目进行之初，我们常以电梯1作为设计的实验点，在在电梯1处写好调度算法，然后复制到其他的电梯处并稍加修改，但这样有一个巨大的缺点，就是一旦设计调度算法之后便很难修改，且要设计新的调度算法时需要对代码进行一个较大规模的变化，使得整个项目的可复用性、灵活性都不高，但我们一开始却没用反应过来，后来，在查看后续的需求是，无意中想到我们可以通过对函数对调度算法进行模块化设计，这样我们在修改代码时只需要修改该函数，修改的灵活性、简易性得到大幅度的提升，我们在需要变化电梯的调度算法时也只需要变化更改调用的算法即可。示例如下：

//电梯1的驱动函数
void runElevator1(){BUS(ele1);          //bus算法//LOOK(ele1);        //look算法//FD_SCAN(elel);    //FD-SCAN算法
}
void runElevator2(){LOOK(ele2);
}

3.2 电梯参数修改以及电梯信息查看

我们除了最基本的调度之外，我们还实现了电梯参数的修改以及电梯信息的查看，这一功能的实现还需要UI界面的配合，故在此处只叙述原理部分，UI界面的设计留在后续专门讲述UI界面的部分专门进行讲述。

3.2.1 电梯参数修改

在一开始设计时想要让参数修改以及信息查看都集中在一个窗口处，但后面发现如此设计UI界面不够美观，故额外在设计了一个窗口，通过这一窗口来输入信息，但由于C#的特性，两个窗口之间不能直接传递变量，故我额外设计了一个类class ChangeData，专门用来传递两个窗口之间的变量，其变量示例如下：

public static string ele1LimitWeight;        //电梯1的最高载重
public static string ele1LimitNum;          //电梯1的最高载客数
public static string ele1RunSpeed;          //电梯1的运行速度
public static string ele1OpenSpeed;         //电梯1的开关门速度
//其余参数类似于上述变量

利用static型变量的特点，使得参数可以在两个两个窗口之间传递，从而达到了修改参数变量的目的，实现的流程为：在参数修改窗口输入数据，利用ChangeData类中的变量储存，调用参数变化函数exchange()，此时需要注意一点，参数变化时并非所有的参数都会发生改变，只有当ChangeData类中的变量不为空时才能发生变化，示例如下：

void exchange(){if (ChangeData.ele1LimitNum != "")int.TryParse(ChangeData.ele1LimitNum, out ele1.limitPeopleNum);//此处省略其余参数的变化
}

另外，为了保证修改好的参数可以实时传递给电梯，我们将调用exchange()的位置放在了调度算法之中，通知增加了一个布尔类型的变量，每当参数发生变化时，该变量会置为true，只有在其为true的情况下才会调用exchange()，且调用完exchange()函数，该布尔类型变量马上便会置为false，这样既保证了参数可以实时变化，又保证了函数的运行效率，不用浪费额外的资源，示例如下：

void fun() {     //fun()表示调度算法if (ChangeData.exFlag == true)   {//exFlag表示电梯参数发生是否变化，其位于ChangeData类中exchange();         //变化参数函数ChangeData.exFlag = false;         //参数调用完毕马上马上置为false}//函数中省略了调度算法及附加功能代码
}

3.2.2 查看电梯信息

此处类似与2.2.1，如果将电梯信息的查看整合进入电梯“使用”界面不够美观，整合进入电梯参数设置窗口则有种类型不搭的感觉，故也额外为其设计了一个信息查看窗口，但由于C#语言的代码特性，使用自动实时刷新代价过高，故使用手动刷新，具体UI界面见后续UI设计部分。因为查看信息的窗口与电梯调度算法运行的位置并不相同，故也需要利用静态类型变量，也就是static类型变量进行信息的传递，当然此处信息的传递并不只有利用静态类型变量一种，还有通过构造带有参数的构造函数进行信息的传递，但这有一个较大的缺点，那就是难以刷新电梯信息，而使用静态类型变量可以以一个较为方便的形式传递信息，并为了减少变量个数，便将此时需要的static类型变量放在具有一定关联性的ChangeData类中。变量的示例如下：

public static int ele1_NowFloor;     //电梯1当前楼层
public static int ele1_PeopleNum;       //电梯1当前载客数
public static double ele1_Weight;       //电梯1当前载重
//其余电梯参数类似于上述变量

利用static型变量的特点，使得参数可以在两个两个窗口之间传递，从而达到了修改参数变量的目的，实现的流程为：点击查看电梯信息按钮，点击刷新，程序调用Flash()函数，电梯信息得到刷新。Flash()函数示例如下：

void Flash()  {text11.Text = ChangeData.ele1_NowFloor.ToString();//text11为显示电梯1当前楼层的textbox组件text12.Text = ChangeData.ele1_PeopleNum.ToString();//text12为显示电梯1当前载客数的textbox组件text13.Text = ChangeData.ele1_Weight.ToString();//text13为显示电梯1当前载重的textbox组件//其余电梯的信息显示类似于上述语句
}

3.3 UI界面

UI界面的设计千言万语都没有一张图说的清楚，直接上图：

系统主界面图：

电梯参数设置图：

电梯信息查看：

3.4 软件测试

由于我电脑上下载的VS版本为Visual Studio 2019社区版，软件测试功能近乎于无，故在软件测试阶段我主要参与测试用例的设计阶段，主要负责系统测试的测试用例设计。经过分析，本次项目主要负责不同调度算法是否可以运行，每部电梯是否可以可以按照参数设定正常运行。测试用例及其测试的功能如下：

	测试用例	目的
1	开始运行 -> 等待2-3 min -> 停止运行	负责测试电梯在没有收到任何请求时能否按照设定运行
2	开始运行 -> up 9 -> 电梯1-17 ×1 -> 运行 -> 停止运行	负责测试电梯在收到向上的信号时能够正常运行
3	开始运行 -> down 10 -> 电梯2-5 ×1 -> 运行 -> 停止运行	负责测试电梯在收到向上的信号时能够正常运行
4	开始运行 -> down 20 -> 电梯3-（-1）×1 -> 运行 -> 停止运行	负责测试电梯在临界情况下能够正常运行
5	开始运行 -> down 19 -> 电梯4-17 ×1，电梯4-（-1）×1 -> 运行 -> 停止运行	负责测试电梯能够在多个请求下正常运行
6	开始运行 -> up 14 -> 电梯4-20 ×20 -> 运行 -> 停止运行	负责测试电梯在临界条件下能否正常运行
7	开始运行 -> up 6 -> 电梯1-20 ×2，电梯4-18 ×1 -> 运行 -> 停止运行	负责测试多台电梯同时运行是否正常
8	开始运行 -> up 14 -> 电梯参数设置 -> 电梯1-最多人数=9 -> 电梯1-13 ×10 -> 运行 -> 停止运行	负责测试电梯参数设置功能中的人数上限设置是否正常
9	开始运行 -> up 2 -> 电梯参数设置 -> 电梯2-最高载重=100 -> 电梯2-7 ×10 -> 运行 -> 停止运行	负责测试电梯参数设置功能中的载重上限设置是否正常
10	开始运行 -> up 1 -> 电梯参数设置 -> 电梯3-电梯运行速度=100 -> 3-9 ×1 -> 运行 -> 停止运行	负责测试电梯参数设置功能中的运行速度设置是否正常

Part 4 个人感悟

到这里结对项目——电梯调度就告一段落了，从一开始编程语言选择到后面的调度算法实现，再到最后面的软件测试，一切都感觉就在昨天。在刚开始写时感觉能够在千行代码之内写完，但写到后面却发现千行代码不够，到目前位置负责主页面的代码已有四千五百多行，这还不包括其他页面以及类设计的代码，这或许和选择语言有一定的关系，我们选择的是C#，设计好的按钮就有一百多个，每个按钮都有其专属的功能，再加上调度算法，数据交换等，便使得代码长度变得如此之长，但有一点却没有错，那就是核心代码，也就是调度算法只有一千多行。这可以说的上是我写过最长的代码了，以前写的代码最长也就一千多行，而这次写的代码合起来也有五千多行近六千行，这对我来说也是一次艰巨的挑战。

在实现项目的过程中也出现过不想写，干脆就这样算了的想法，但后面也慢慢的调整好了心态，重新振作了起来。也经历失败，在实现过程，由于对C#的不熟悉，出现代码无法实现预想效果的情况，但我们也没有因此放弃，随着项目的进行，对C#语法的逐渐熟悉，以前无法实现的一些功能也逐渐实现了。也出现过僵局，在实现调度算法时，由于有些算法的描述不够清晰，许多细节都无法确定，至此项目的实现陷入了僵局，但后续我们通过各种途径，如查资料、询问老师等方式，逐渐了解了这些细节，进而破除僵局。也出现过两人时间难以匹配的问题，这个时间我有空他没空，那个时候我没空他有空，但我们都经过计划的调整，使得时间能够有一段时间达到一致，进而保证了项目的正常进行。

的描述不够清晰，许多细节都无法确定，至此项目的实现陷入了僵局，但后续我们通过各种途径，如查资料、询问老师等方式，逐渐了解了这些细节，进而破除僵局。也出现过两人时间难以匹配的问题，这个时间我有空他没空，那个时候我没空他有空，但我们都经过计划的调整，使得时间能够有一段时间达到一致，进而保证了项目的正常进行。

这个项目总的来说还是对我收益良多的，让我更加熟悉了一种编程语法，让我的编程能够得到了很大程度的提高，让我得以运用以软件工程的方式实现一个项目的过程，也让我对两个组队实现的形式有了一定的熟悉。