结对项目-地铁出行路线规划程序（续）
git网址：https://github.com/nrm1/subway_GUI
备注：因为我们使用git的过程中不小心把debug文件夹给交上去了，导致分出一堆分支，最后只能人工合了，所以Git上就交了几次，把最后和好的交了，之前的那个仓库给删了。
本程序使用方法：
subway_GUI.exe （输入线路名则输出整个线路站名）
subway_GUI.exe -b 知春路 北京西站（输出最短路径）
subway_GUI.exe -c 知春路 北京西站（输出经过换乘站最少）
subway_GUI.exe -g （打开图形界面）
注：演示动画在线路展示完全后等待6s会自动退出
小组成员：
14061035 崔正龙
14061041 谷大鑫
结对编程的优点和缺点：
优点：
1、队友间可以相互帮助，遇到问题可以相互讨论，寻求对方的意见。
有问题不用一个人憋着，可以随时向对方提问，因为大家都是比较了解项目要求的，所以不用太多的说明就能明白对方的意思，还能比较快和准确的反馈相关的建议。
2、可以降低学习成本，减少开始编程前的知识准备时间。
因为这次使用的是C#，两个人其实都不是很熟悉C#语言，要是一个人又学前端又学后台的编程，感觉会花费一定的时间，再加上编程、调试、测试的时间，总体上时间就会非常的紧张，可是分给两人以后，大家就可以各司其职，各学各的就快了很多（当然，我们计划完成作业以后还是要自学一下对方学习的知识的，这一块上因为彼此都能给对方讲解，学的速度就更快了，也算是另一种意义上的节省时间。）
3、能更好的坚持讨论时定好的设计规范、代码风格等。
之前自己一个人写的时候就是写到哪想到哪，感觉写起来不顺了，就立马换个思路继续了，毕竟只有自己一个人，怎么顺手怎么来，现在是两个人结对完成，必须要遵守和对方定义好的设计规范，使得自己能比较好的坚持下来。
4、不得不说代码质量确实高了一点。
之前就自己一个人的时候写代码感觉心里反而没啥负担，写的代码丑也是自己看，写的代码错了，自己负责调试。结对的感觉就不一样了，毕竟自己写的代码好坏也会影响到对方，所以就真的一点不敢大意，质量上应该会提高一些吧。
缺点：
1、两人在一起编程有时候会聊一些闲话，反而降低效率。
因为在一起的时候可能会因为聊其他的话，分心导致真正编程的效率降低很多，后来决定还是分开写，最后一起合，这样可能会更快。
2、有时候两个人可能会说岔了，最后才发现所以还需要改。
这个我们没遇到，发现说差了及时就改回来了。
两人的优缺点：
先说自己吧：
优点：
1、能够按照说好的约定完成代码。
2、不会的知识会很乐意去学习。
3、不拖时间，按时完成。
缺点：
1、对C#语言不够熟悉，需要先学习相关知识。
2、有时候会犯懒，产生懒惰心理，自己也在努力克服。
谷大鑫：
优点：
1、很有责任心，能够很好的完成任务。
2、编程能力强，有很强的求知欲。
3、合作态度好，每次讨论都能提出有建设性的建议。
4、能够按时完成任务。
缺点：
1、对C#图形化不够熟悉，需要花一段时间学习。
技术方法：
一、Information hiding
概念：信息隐藏指在设计和确定模块时，使得一个模块内包含的特定信息（过程或数据），对于不需要这些信息的其他模块来说，是不可访问的。
我们的应用：
首先我们的前端和后端是分开的，作为两个模块，期间关于数据交换有特定的函数接口Search，除此之外，其他的数据两个类非别存储、处理，前端无法访问到后端对于站的连接情况、站点属性等数据的访问，后端也无法访问前端的函数、存储数据等信息。
其次，定义的类中属性为private限定，类外的除非通过类提供的特定接口，否则无法修改类内的属性，这样就能够有效的保护好数据。类内的方法被封装在类内，类外可以调用类内的方法，除了类提供的接口，其他不能修改类内的数据。
二、Interface Design
我们根据接口设计的六大原则进行应用：
1、单一职责原则：There should never be more than one reason for a class to change.
类中定义的方法，每个方法仅针对一个功能，做到职责单一化。
2、里氏替换原则：Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it.
所有引用基类的地方必须能透明地使用其子类的对象，因为没有定义新的子类，所以暂时没有用到这个原则。
3、依赖倒置原则：High level modules should not depend upon low level modules.Both should depend upon abstractions.Abstractions should not depend upon details.Details should depend upon abstractions.
高层模块不应该依赖低层模块，两者都应该依赖其抽象。
抽象不应该依赖细节。
细节应该依赖抽象。
我们定义的类都存在接口，尽量没有覆盖基类的方法。
4、接口隔离原则：Clients should not be forced to depend upon interfaces that they don't use.
建立了单一的接口，减少了接口的冗余，使接口的数量尽量的少。、
5、最少知识原则
和其他类的联系时，减少不必要的联系，保护自己类内的属性，本类的方法放置在本类中。
6、开闭原则：Software entities like classes, modules and functions should be open for extension but closed for modifications.
我们对项目和软件按照逻辑规则划分模块，模块和函数有可扩展性，可以对扩展开放，对修改关闭。
三、Loose Coupling
概念：在我们的代码设计时，不用担心会破坏其它地方的代码。这种类与类之间依赖性低的设计方法，使一个类与另外一个类仿佛隔开了，它们之间只是通过消息来联系的，所以设计一类时，可以不用担心破坏另外一个类。当代码有改动时，可以不用大规模的改动我们的代码，我们只用定位于一个出问题的模块，然后对其进行更改就好了，而且能做到不改变其它模块的服务。
我们尽量的把耦合度降低，以确保代码的正确性、可读性。
四、Design by contract
契约式编程，契约式编程规定了软件设计师间应该遵守的、定义正式的、准确的、可核查的接口定义规范、软件组件的普遍定义、扩展抽象数据类型与先决条件、后置条件和不变式。
优点：
1、在开始编程前就能够定义好接口定义、组件的规范和方法的前置条件和后置条件，这样就可以方便的将两个人的工作分开，就可以分开工作，只需要最后将两个人的代码根据其契约整合在一起就可以了。
2、能够有效的统一代码风格和规范，使得代码的整体性更强，前端和后端的代码风格更加完整统一。
缺点：
有一点刻板，不像个人变成一样自由随便，需要绝对的遵守之前定义好的契约项目，不能根据项目的进行而自行更改，任何关于契约的修改需要多人协商后才能确定。
单元测试
namespace subway_GUI.Tests
{
[TestClass()]
public class ProgramTests
{
Program p = new Program();
[TestMethod()]
public void SearchTest()
{
string[] s = { "-b","知春路","北京西站" };
Program.Main(s);
int start = 162;
int end = 115;
int modle = 0;
int expected = 8;
int[,] result;
Program.Search(modle, start, end, out result);
int actual = result[0,0];
//Assert.AreEqual(expected+1, actual);
Assert.AreEqual(expected, actual);
}
[TestMethod()]
public void SearchTest2()
{
string[] s = { "-b", "2号航站楼", "苹果园" };
Program.Main(s);
int start = 275;
int end = 0;
int modle = 0;
int expected = 21;
int[,] result;
Program.Search(modle, start, end, out result);
int actual = result[0, 0];
//Assert.AreEqual(expected+1, actual);
Assert.AreEqual(expected, actual);
}
}
}
VS2015的社区版好像没找到生成代码覆盖率的功能。
六、UML图
七、代码关键
使用BFS算法算得最短路径。
利用BFS算法的计算换乘最少的路径。
