结对项目-地铁出行路线规划程序（续）

Posted 2020-08-12 Xzw_Zai

结对编程

结对编程队友：

金豪，杨金键

结对编程优点：

队员之间能互相督促，培养人的责任感。可以及时发现Bug。互相之间的交流可以带来更多灵感。

缺点：需要大量的沟通，导致一定的时间浪费。

 

 个人优点：

　　金豪：积极主动，想法灵活，认真学习

　　谢振威：刻苦努力，代码质量高bug较少，认真负责

　　杨金键：认真刻苦，勤于实践，思路明了

个人缺点：

　　金豪：遇到奇怪问题。。

　　谢振威：与队员沟通不够

　　杨金键：强立flag，喜欢自打脸

 

关于设计方法

 

设计方法：

　　在动手写代码之前先进行周密的设计，包括各个模块的功能，模块之间的具体接口。关键在于接口，队员之间一定要协商好后行动，不然在后续编程中容易产生各式各样的bug。同时模块内部的属性应当不能由其他模块直接访问，即应当通过get/set方法（如需要被访问）才能被其他模块进行访问。同时当两个模块由不同的人写的时候，这个时候我们可以预先写好一个中间层，然后依据中间层各自进行各自的设计确保和中间层的链接。

契约式设计：

　　最初是被Bertrand Meyer在设计他的Eiffel语言时所创造的概念，并且在1986年开始逐渐被各式各样的论文引用。用文档来记载权利和义务的说明并用程序来检验，这就是契约式设计的核心。契约式设计其之所以得到了人们的重视，因为它将责任的分工明确化。当一段代码发生异常时，我们过去的思想总会模糊的认为，是否是这段代码本身存在错误？而程序的规格化设计明确地告诉了我们这一错误的责任到底在于用户还是设计者。在面向对象技术中，接口是我们在面向对象中需要关心的东西，可是只有借口这却还不够充分，我们究竟如何才能正确的使用接口，而这恰恰是契约式设计所提供的部分。只有考虑到了规格，才可能实现面向对象的目标：可靠性，可扩展性，和可复用性。

 

UML

测试

　　测试方面，我们是采用VS2015针对计算模块专门新建项目做的测试（也打包在随后的代码库里面）。测试用力基本涵盖了所有的可能情况，具体如下：

　　以及代码覆盖率是这样的：

 

 

 

 

实现算法

将站与站之间的关系用2个邻接矩阵表示，同一个站如果在不同的线上出现，算作不同的站。求最短路的邻接矩阵中，不同的线上的同一个站的距离设为0，求最少换乘的邻接矩阵中，不同的线上的同一个站的距离设为MAX/10（大于线上站点总数的值）。同一条线上相邻的站距离为1，不相邻的站设为最大距离MAX。计算时，都使用Dijkstra算法，即可得到最短路径或者最少换乘路径。

 

附加题：

　　http://www.cnblogs.com/thereisnoname/p/5928416.html

Github地址：

　　https://github.com/XzwZai/