结队成员：林璐10061142-孙胜10061169
一、pair work照片以及优缺点
1.1 pair work优缺点
优点：1.两个人一起编程效率很高，因为不会想去边编程边听歌，或者编一会儿去看会电影。两个人都全身心的投入到设计算法，编程的过程中，甚至过去了一整天都没什么感觉；
2.面对复杂的算法思路，两个人可以一起思考，随时商量，克服自己的思维局限。就像上面的照片，是我们设计算法时的记录。
3.在编程过程中可以分工，我们把整体的结构搭好之后，可以把工作分成几个模块，两个人分别做，并且随时可以商量调整。比如孙胜负责写外部、内部请求的存储方法，我负责写计算下一个目标地址的方法，然后两个人和在一起，调整错误，就比一个人写的效率高很多。
缺点：时间不好协调统一。
1.2 孙胜的优缺点
优点：1.查找资料的能力强，我们的算法灵感都来自于这些资料；
2.交流能力很好，在商量算法和具体实现的时候，碰到问题能够很好的表达，所以我们的交流一直顺畅无阻；
3.很主动，我们的工作一旦商量好怎么分配，她就能很快的进入角色，并高质量的完成；
4.特别谦和，所以我们一起结队的好几天都能很愉快的度过。
缺点：1.对工程的整体把握不是很清晰，各个类的关系和实例的相互调用理解不是很深。
二、关于information hiding,interface design,loose coupling等好的设计方法的学习
这些设计方法很大程度上决定了一个模块设计的好坏，它们可以使模块功能完善化，消除重复代码和功能，降低模块接口的复杂程度，是每个模块都可以独立开发、测试，并且当其他模块改变后，可以保持自己的独立性。
information hiding 信息隐藏原则：将每个程序的成分隐藏在模块内，尽可能少的显露其内部处理，可以提高软件都可修改性、可测试性和可移植性；
interface design 接口设计遵循的原则：简单原则，要求接口方法命名规则，接口相关参数的数据类型简单，减少模块间直接性的复杂数据的传递。封闭原则，模块内部的处理逻辑修改时，不会影响到其他模块的使用。完整性原则：可以方便的利用继承，重写，覆盖等技术手段来提高代码的复用率。接口隔离原则，使用多个专门的接口比使用单一的接口要好，在接口中禁烧公布public方法。
loose coupling 松耦合：耦合是指模块间依赖的程度的度量，模块设计追求的是强内聚，松耦合。耦合的强度依赖于：一个模块对另一个模块的调用，一个模块向另一个模块传递的数据量，一个模块施加到另一个模块控制的多少，模块之间接口的复杂程度。尽量减少两个模块之间的直接调用和控制，两个模块之间的联系最好全都通过主模块的控制和调用来实现。
这次电梯调度的项目，我对此有些体会，我尽量把一个会被多次调用的功能写成一个模块，这样就直接调用模块，因此修改的时候，只需要修改该模块，而不需要找到那些调用的地方再做大量冗余修改。
这次比较大的项目让我觉得对软件的整体设计很重要，体会并用好这些设计方法可以极大地提高软件的可移植性，减少很多调试修改工作。
三、类图
3.1 需求描述：
我们需要设计一个四路电梯调用系统（Elevator Dispatching, ED）允许乘客进入电梯，并被运送到目标楼层。
乘客想从x层到y层，当乘客在x层电梯门口按下上/下方向键之后，ED响应该外部请求，调度程序处理该请求，调度电梯的运行，结合电梯的载客情况（过载则待有空余重量再接受上电梯请求），使之最终到达该楼层接乘客。乘客进电梯，按键选择目标楼层，电梯对乘客信息以及内部请求信息进行处理，改变电梯载客和运行状态，以便判断并处理其它楼层乘客的请求，最终电梯到达乘客目标楼层，开门送客，并改变状态参数。
3.2 对粗体字的名词短语处理得到用例：
乘客，Passenger
电梯，Elevator
调度程序，Scheduler
请求，Request
3.3 Framework:
SigmaPassenger类: 提供passenger的体重姓名等个人信息，通过引发request，进出电梯等与其他类传递消息；
PassengerReq类：包含请求信息的重要属性（请求时间，源楼层，目的楼层，方向，请求电梯），与Elevator和Passenger交流；
SenElevator类：包含电梯运行的各个参数（电梯编号，最高楼层，限重，方向，目的地，状态等），限重与passenger相关，运行与request相关。
Sheduler类（我们的工作）：根据调度算法，对电梯的运行进行调度。
3.4 类图
四、算法思路
我们的算法主要优在对请求的分类存储，以及对电梯下一个目标楼层的计算。
4.1请求的分类按序存储
我们把请求分为外部请求和内部请求，外部请求是乘客在电梯外面的上下行方向请求，内部请求是乘客在电梯内部的目的地请求。将二者分别放在List<IRequest>OuterReqList和List<IRequest>InnerReqList中保存，并按照下列权值进行从大到小的顺序。每次一旦有一个请求（事先分好是内部还是外部请求），按照下列权值插入到List的相应位置，这样可以保证每次List中的第一个元素都是这类请求最先应该执行的。
外部请求的权值从大到小：
若电梯向上运行：同向前方的请求>逆向前方的请求>逆向后方的请求>同向后方的请求
若电梯向下运行：同向后方的请求>逆向后方的请求>逆向前方的请求>同向前方的请求
内部请求的权值从大到小：
若电梯向上运行：上方的请求>下方的请求
若电梯向下运行：下方的请求>上方的请求
4.2 电梯的下一个目标楼顶层的计算
若电梯向上运行，那么目标楼层的权值应该是：同向前方的外部请求or上方的内部请求（要判断谁更近）>highestFloor
若电梯向下运行，那么目标楼层的权值应该是：同向前方的外部请求or下方的内部请求（要判断谁更近）>0
这部分的代码最难缠，因为有很多情况要考虑，比如如果外部请求的List为空或者内部请求的List为空，等等，我们也是因为这部分的算法考虑欠妥因而调试了很久，耽误了很久。
4.3 算法的灵感来源
这是我们从网上查找到资料中的一个流程图，是关于请求的权值计算，正是这个图帮助我们设计我们的算法。
4.4 预计完成的更优化的算法（因为时间问题没能实现）
主要是针对高峰期的考虑。因为上班高峰大部分都是上行的请求，而下班高峰大部分是下行的请求。因此，我们计划在上班高峰时使用3个电梯只满足上行请求命令，而1个电梯正常运行满足少数的上下穿梭，同理下班高峰时使用3个电梯只满足下行请求命令，而1个电梯正常运行满足少数的上下穿梭。
我们可以通过对乘客请求中满足from = 0,1的比例来判断是否是上班高峰，而对to = 0,1的比例来判断是否是下班高峰。
四、pair work感想
这次pair work有很多收获，也有一些遗憾。
我第一次与别人合作完成一个项目，感受到了很多好处，我明显觉得在两个人一起工作时自己的效率变高了，而且思路也开阔了不少。尽管这个项目挑战很大，但是我们还是咬牙完成了，得益于我们良好的沟通和相互的支持鼓励。
但是，有一点遗憾是没能尽早的开始，以致最后调试的时间很少，很多边界情况比如楼层请求超出范围之类的没时间考虑，最后我们那个分上下班高峰的想法也没能实现。
五、我的工作
主要是对framework的整体把握和模块搭建，以及计算下一个目标楼层方法的编写。