软件工程  ---   Pair Project: Elevator Scheduler [电梯调度算法的实现和测试]

说明结对编程的优点和缺点。

结对编程的优点如下：

在独立设计、实现代码的过程中不免要犯这样那样的错误。在结对编程中，因为有随时的复审和交流，队员们取长补短。这样，程序中的错误就会少得多，程序的初始质量会高很多，同时也省下很多以后修改、测试的时间。这样高质量的产出能够给程序员带来一些信心。而且，在结对编程的过程中两位程序员互相交流，相互学习传递经验，能够在结对编程的过程中学习到更多的东西。

但是结对编程也存在着一定的缺点：

结对编程的过程中，代码一直处于“复审”的过程，即不断地审核，提高设计和编码质量的过程。这样对于提高代码质量有很大的帮助，但是在互审的过程中也存在着一些问题：例如，复审的程序员对代码不及编写代码的程序员深入了解降低了复审的效果。而且，这次结对编程是随机分组的，我和周敏轩犇犇以前并不熟悉，这次结对编程的过程也会因为互相并不熟悉而产生一些缺少交流的问题。

结对的每一个人的优点和缺点在哪里 (要列出至少三个优点和一个缺点)。

周宣同学的优点：认真负责，工作效率高，接受能力强

　　　　　　缺点：实现算法时思路不够集中

周敏轩的优点：能写点代码，能查资料，能虚心请教大神

　　　　　　缺点：经常没想仔细就实现代码，倒是debug和重写浪费太多时间

看教科书和其它资料中关于 Information Hiding, interface design, loose coupling 的章节,说明怎样利用这些好的设计方法。

Information Hiding：在面向对象方法中Information Hiding是通过对象的封装实现的。隐藏对象的属性和实现细节，仅对外公开接口，控制在程序中属性的读和修改的访问级别；将抽象得到的数据和行为（或功能）相结合，形成一个有机的整体。

在程序设计过程中可以通过控制访问权限来实现。例如用private，public，protected修饰属性和方法。

interface design：interface design包括三个方面：

一、用户接口

用来说明将向用户提供的命令和它们的语法结构，以及软件的回答信息。

二、外部接口

用来说明本系统同外界的所有接口的安排包括软件与硬件之间的接口、本系统与各支持软件之间的接口关系。

三、内部接口

用来说明本系统之内的各个系统元素之间的接口的安排

loose coupling：类与类之间的互相调用，这两个类之间就会有比较高的耦合程度，降低类与类之间的耦合程度，可以通过接口实现。

看 Design by Contract, Code Contract 的内容:描述这些做法的优缺点, 说明你是如何把它们融入你的作业中的。

契约式设计或者Design by Contract (DbC)是一种设计计算机软件的方法。这种方法要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。这种方法和商业契约的情况有点类似。所谓契约，也就是合约，规定两个交互物件上的权利和责任。雇佣合同规定你的工作时数和你必须遵守的行为规则，作为公司则付你薪水，双双履行义务，双双受益。DbC的核心思想是对软件系统中的元素之间相互合作以及“责任”与“义务”的比喻。

在面向对象程序设计中一个类的函数提供了某种功能，那么它要：

1.期望所有调用它的客户模块都保证一定的进入条件：这就是函数的先验条件—客户的义务和供应商的权利，这样它就不用去处理不满足先验条件的情况。

2.保证退出时给出特定的属性：这就是函数的后验条件—供应商的义务，显然也是客户的权利。

3.在进入时假定，并在退出时保持一些特定的属性：不变式。

因此在进行Dbc的时候我们通常要考虑三个问题：

1.它期望的是什么？

2.它要保证的是什么？

3.它要保持的是什么？

DbC六大原则

原则1 区分命令和查询。查询返回一个结果，但不改变对象的可见性质。命令改变对象的状态，但不返回结果。（应当是不一定返回结果）

原则 2 将基本查询同派生查询分开。派生查询可以用基本查询来定义。

原则 3 针对每个派生查询，设定一个后验条件，使用一个或多个基本查询的结果来定义它。这样我们只要知道基本查询的值，也就能知道派生查询的值。

原则 4 对于每个命令都撰写一个后验条件，规定每个基本查询的值。结合“用基本查询定义派生查询”的原则，我们现在已经能够知道每个命令的全部可视效果。

原则 5 对于每个查询和命令，采用一个合适的先验条件。先验条件限定了客户调用查询和命令的时机。

原则 6 撰写不变式来定义对象的恒定特性。类是某种抽象的体现，应当将注意力集中在最重要的属性上，以帮助读者建立关于类抽象的正确概念模型。

通过截屏显示你是如何用VS 的unit test 来保证你写的类的质量的。显示unit test 对你的写的类(class) 的覆盖率

好不容易弄清楚单元测试干什么的，但是许多方法因为都没设返回值，不知道怎么编写单元测试的代码，最后测试出来的结果就是：

虽说结果很挫，还是分析下吧。忽略那些没有通过的测试，整体的代码覆盖率简直就是惨不忍睹，不知道写了正确的测试代码后能不能提升一点。或者就是我写程序的习惯太差了吧，下次一定改进。

画出UML 图显示各个实体之间的关系 (画一个图即可)

图示通过vs自动生成的，感觉很详细，很全面，就用这个了。

说明你的算法的关键 （不必列出源代码）, 以及独到之处。

算法概述：

对于每个电梯，建立一个List<dst>存放该电梯需要访问的楼层列表，dst类包含一个int和一个Direction参数，一个表示目标楼层，一个表示该请求的方向。该列表通过一个sortList()方法进行排序（根据电梯当前方向和楼层来确定List中元素的访问顺序）。

每次调用run()方法时，首先遍历所有电梯，调用gotoFirst()方法访问它们访问列表的首项，如果没有首项，根据当前客流情况（上下班之类的）添加一个目的地。

随后我们扫描当前请求列表中的请求，对于每个请求，我们扫描每个电梯，通过一个估价函数upValue()来确定当前请求插入后所产生的代价，然后选取代价最小的电梯，将该请求插入到访问列表中。然后调用sortList()方法进行排序。

算法关键：

排序算法sortList()的应该算是一个关键吧，排序要考虑当前方向和楼层，然后根据请求的方向和楼层来排访问列表，这里情况很多，所以代码量很大。另一个关键就是估价函数upvalue()，对于一个请求，扫描电梯的访问列表确定其所在位置，然后返回一个代价，这里找位置也不太容易实现，其实最后我也没有精确的找到这个位置，只是给出了一个大概的位置和估价。sortList()方法调试了我好久，重写了大概3次吧，因为如果稍微顺序错了，就会导致人上不了电梯，更诡异的还会直接把这个人给忽略掉。

独到之处:

首先，由于存在上下班高峰的情况，所以我开了3个int变量gotowork, gohome, sum来记录当前请求的上班数，下班数，以及总数（实时更新的），然后根据它们的比例来确定当前的状况。上班的话，没有任务的电梯都加入一个前往0层的任务，下班的话，没有任务的电梯分别分配到5，10，15，20层，如果随机情况就让电梯停在当前楼层。

独到之处我也不知道怎么讲，可能就是贪心的比较好吧。效率的话其实还是不错的，效率如下图：

	Bus	我们的算法
Passenger1.xml	307.05	62.7
Passenger2.xml	665.443	222.229
Passenger3.xml	942.943	319.847

如表所示，效率还是可以的。除了passenger3的数据可能不是很优（薛神算法180只能说略残暴）。不过其他两个的效率还是可以的。