成员：12061162 王骜
12061225 钟毅恒
一、合作过程中的照片
、
二、结对编程的优缺点
优点：
1）在编程过程中，任何一段代码都不断地复审，同时避免了将写代码的责任抛给一个人的问题，而是属于两个人，可以帮助建立集体拥有代码的意识。
2）结对编程的过程也是一个互相督促的过程，每个人都可以监督，督促对方的工作。由于这种督促的压力，使得双方都可以更认真地工作，频繁交流讨论对方的代码以防止出现纰漏，提高自身的代码质量。
3）为了避免一个人长时间进行同一项工作会产生疲劳的现象，结对编程中两个程序员还可以互换角色，轮换驾驶员和领航员的角色，从而长时间保证较高的工作效率。
缺点：
1）如果两个人的共同时间比较少的话，互相等待，影响效率，采用结对编程的方式反而比较浪费时间。
2）如果是一个需要花时间长期钻研的项目，采用结对编程的方式反而会影响一个人的思路，适得其反。
三、每个人的优缺点
王骜
优点：
1） 代码编写能力强，有丰富的代码编写经验
2） 刻苦勤奋，锲而不舍
3） 逻辑思维活跃，能有创新的想法
缺点：
1） 调试较费时间，调试代码的能力有待提高
钟毅恒
优点：
1） 勤奋好学，能边学习C#同时编写代码
2） 能够虚心听取partner提出的意见
3） 较细心
缺点：
1） 代码编写能力较弱，编写量有待提高
四、 看教科书和其它资料中关于 Information Hiding, interface design, loose coupling 的章节并说明怎样利用好这些设计方法。
information hiding（信息隐蔽）
每个模块应该对其他所有模块隐蔽自己的设计决策。换句话说，模块应该规定并设计成为在模块中包含的信息（算法和数据）不被不需要这些信息的其他模块访问。
通过定义一系列独立的模块可以得到有效的模块化，独立模块相互之间只交流实现软件功能所必需的那些信息。还可以加强对模块内过程细节的访问约束和对模块所使用的任何局部的数据结构的访问约束。
在随后软件维护过程中，修改过程中不小心产生的错误不至于传播到软件的其他位置。
interface design（接口设计）
接口设计包括三个重要的元素：
1.用户界面（UI）
包含美学元素，人机工程元素和技术元素，通常UI使整个应用体系结构中独一无二的子系统。
2.和其他系统，设备，网络或其他信息生成者或使用者的外部接口。
需要关于发送和接收信息的实体的确定信息。在所有情况下，这些信息都要在需求工程中收集，并且开始时还要检验这些信息。
3.各种设计构件之间的内部接口。
分析类的设计实现表示所有操作和信息传递模式，使得不同类的操作之间能够进行通信和协作。每个消息的设计必须提供必不可少的信息传递和已被请求操作的特定功能需求。
loose coupling （松耦合）
在设计模型内，协作应该保持在一个可以接受的最小范围内。即通常，一个子系统内的设计类对其他子系统中的类应仅有有限的了解。一个类中的方法应该只向周边类中的方法发送消息，而不是直接的套用周边类中的方法内部的内容。
松耦合，就是在对象之间既要保持一定的通信，也要有一定地独立性。但在程序设计中不能一味地追求松耦合，这样会使程序粒度过低，使得程序庞大繁杂，适得其反。
在这次的程序设计中，Scheduler的算法不能仅仅适用于测试用例，如果电梯的部数变化，场景变化，Scheduler也不用修改，因此，即使知道现在的电梯是4部，也不能在算法中直接使用4，而是应该使用电梯的Count()值。并且算法的实际也不能仅仅使用于测试案例，应该有更大地适用范围。
Scheduler和Elevator类虽然密切相关，但是二者还是主要通过通信来相互控制，并没有直接进行引用。
描述这些契约式设计做法的优缺点, 说明你是如何把它们融入你的作业中的。
契约式设计的提出，主要基于软件可靠性方面的考虑。可靠性包括正确性和健壮性，正确性指软件按照需求规格执行的能力，健壮性指软件对需求规格中未声明状况的处理能力。
优点：
- 文档。在文档中不仅包含签名描述，也能包含契约描述，如果能更进一步象VisualStudio智能提示那样呈现，能减少很多编码过程中犯下错误。
- 测试、调试、品质保证。NUnit是比较完善的断言测试框架，如果语言本身提供契约式设计支持，我们可以使单元测试中断言的覆盖范围更广泛（考虑一般都是开发者自己做单元测试），能够帮助发现更多隐性的缺陷，断言测试代码的编写会更简洁。
缺点：
契约式设计过于死板，不容易让创意得到实现，也不容易添加新的功能，因为函数功能已经约定好。
在作业中我们应用契约式设计主要体现在对用户输入数据的接收上，这就好比商业契约，用户和程序员之间呈现一种相对平等的关系，即如果用户没有遵守程序员在程序开头所定下的准则，那么程序员所编写的程序也没有义务必须给用户呈现一个满意的结果。
契约式设计在本次工程中的应用
刚开始我和柴泽华对算法进行了讨论，确定了算法的主线。之后，为了达到契约式设计的目的，我们进一步细化算法，几乎以伪代码的方式实现了算法，这个伪代码就是我们的契约。
在实践中，我们发现，契约式设计使得代码的编写一次成型，貌似很好。但是，这个契约式的代码的结果并不理想，当我们想对它进行小规模地修改时，发现它牵一发而动全身。最后不得不重新写一份代码，以获得良好的结果。
可以看出，契约式设计虽然保证了正确，但是对于不断适应外部新环境的开发，以及探索地、创新地开发并不适用。而现在软件开发所面对的环境就是一种不断变化的环境，契约式设计可能会逐渐不能适应。
五、通过截屏显示你是如何用VS 的unit test 来保证你写的类的质量的。显示unit test 对你的写的类(class) 的覆盖率
单元测试结果：
类的覆盖率：
最终覆盖率达到了92.50%。
六、画出UML 图显示各个实体之间的关系
七、
实现你的算法并说明你的算法的关键 （不必列出源代码）, 以及独到之处。
算法的关键：
优化BUS算法，把所有已进队的指令扫一遍，找出最近的顺路需停靠楼层（即有乘客从楼层外部发出请求或从电梯内部发出停靠楼层指令的楼层），然后判断，若此楼层为电梯可停靠楼层，就把电梯所要停靠的下一楼层设为该楼层。
然后，因为最近的所需停靠楼层初始值为21或-1，若指令扫一遍以后这个值没有改变，则表示当前方向楼层没有需要停靠的，则把电梯运行方向改变，继续搜索下一停靠楼层。
独到之处：
首先对最近顺路需停靠楼层的定义使电梯更贴近实际情况，而若电梯当前方向上没有需停靠楼层，则电梯运行方向改变，这使得乘客的等待时间大幅度减少，是性能提高路上一次质的飞跃。