结对编程————电梯整理报告

小伙伴： 12061159 张迎春

照片：

 

 

团队成员的优缺点：

   张迎春：非常认真，代码能力也非常强，精明能干，待人真诚的人。缺点不好写。。缺点就是没有 然后让我没法写博客

 我：检查代码错误能力比较强，调试能力也还行，但是 对c#的掌握不好 

 

结对编程的优点

1. 能够综合两个人的优缺点（例如：一个人算法功底很强，另一个人代码风格很好）
2. 能够综合两个人的思路。有时候，一个人想问题可能不是很全面。两个人一起可以互相检查错误或者疏漏的地方。
3. 减少工作量。。。显而易见。。
4. 两个人互相交流。比如看不懂代码，两个人一起讨论就能很快解决。

 

结对编程的缺点：

  有时候找到两个人都有时间比较困难。

  有时候两个人对算法的理解稍有偏差，可能导致代码错误。

  结对编程的缺点是开始时两个人需要一定的磨合期，需要在程序编写前知道对方的编写习惯，并且尽量先统一一下编写的格式，命名的方式等，不想一个人编程那样随意。

 

 

程序的好设计方法：

 

　　信息的隐藏，或者说是程序的封装性，这是为了保证程序的安全性，保证程序的内部信息不会被随便的获得和改写，这使得程序变得更加具有独立性，高内聚，面向对象的特征更加明显，为了保证这一点，我们在程序中对一些需要被外部访问的属性设定了专门的方法，通过方法的方式将内部属性传递出去。

 

　　 接口的设计。接口的设计在一定程度上决定了继承该接口的类的功能。传递数据信息是接口的一个比较重要功能，通过接口完成相互独立的模块之间的信息传递，很好的保护了程序的封装性。

 

程序模块间的低耦合性。这使得程序之间的联系尽可能的少，不再会“牵一发而动全身”。低耦合性使得程序的维护变得简单，某个程序更改后，其他的程序只需要做很小的修改，甚至不需要修改就可以使用。

 

关于契约式编程：

 

　　契约式编程可以减少软件开发的成本，要求软件设计者为软件组件定义正式的，精确的并且可验证的接口，这样，为传统的抽象数据类型又增加了先验条件、后验条件和不变式。契约式编程就是函数调用者应该保证传入函数的参数是符合函数的要求，如果不符合函数要求，函数将拒绝继续执行。按照契约式编程的思想编写代码，就要求我们写函数时检查函数参数。契约式编程使得软件开发的分工更加合理，加强了开发的安全性，降低了开发的困难程度。

 

Unit test:

我们对绝大多数的方法进行了全方面的测试（主要是后来我们修改过或者自行添加的函数，一些get和单纯的传递属性的函数没有进行测试，因为意义不大）。

 

 

　　UML截图如下，我们选取了该程序中主要的五个类做出了UML图，以便于更加清晰的反映各个类之间的关系。主要有电梯类，调度类，乘客类，请求类，调度规划类。具体如下。

 

我们的算法：

 

　　由于实现实时分配调度任务比较困难，所以我们采用了及时分配的策略。具体如下：

 

　　我们更改了程序的接口，放弃了原来的调度队列，并将其分解为四个独立的调度队列，分别对应于四个电梯。当有一个乘客发出方向请求时，我们会根据电梯当前的状态计算出电梯来接这位乘客的花费（包括到该层的时间和电梯中原有的乘客要在这层等待的时间花费），选择当前花费最小的电梯，将该请求加入到这部电梯的调度队列之中。如果所有的电梯调度花费都是无穷大（比如电梯当前不顺路或者电梯根本无法到达该层），那么这个乘客的请求将会被搁置，直到某个时刻有电梯到该层的花费不是无穷大，由该电梯来接受请求。对于电梯去接乘客，但是发现乘客要求去得楼层电梯不能够到达时，乘客不会进入电梯。该乘客将再次发出请求（实际情况也是这样），并且乘客会记住这个电梯，对这个不能到达目的地的电梯进行标记，从其他的电梯中进行选择。为了优化上下班高峰期的情况，我们对电梯的请求队列内的请求数进行了优化。当该电梯的请求过多时，电梯便不会再接受请求，这样一方面减少了乘客们等待的时间，另一方面也是的请求尽量分配到多个电梯，使电梯的调度分配更加合理。还有就是一些小的细节上的优化，比如电梯不会接受在自己的最高层发出的向上的请求，不会接受在自己的最底层发出的向下的请求等等。