软件工程个人项目-地铁出行路线规划程序
2016-09-15 01:37
225 查看
[b]项目进度[/b]
非附加要求：
附加要求：
[b]性能分析：[/b]
-b和-c选项整体思路是BFS
-a附加功能思路是DFS+贪心策略寻找较优可行解。
上图为-c功能时程序性能分布情况。
[b]github[/b]
https://github.com/Helicopt/subway.git
[b]数据格式：[/b]
线号名称 num
站点1[*]
站点2[*]
...
站点|num|[*]
[环路站点[*]]
按站点起始顺序描述一条线路，读到文件末尾完成所有线路的输入
num若为负数，则表示存在环路，最后一个站存在下一站（环路起始），环路站点一定是之前出现过的；若num为正数，则线路不存在环路。
若站点后存在'*'符号，表示上一站到这一站是单向行驶。
这样设计的好处是用尽可能简单的信息将整个地铁图的情况描述清楚，将建边负担交给程序。
[b]算法优化[/b]
前两个功能（-b和-c）计算量上基本已经达到理论上界，效率为O(n)和O(n^2)，对于-c功能，由于地图的简单，实际效率应该属于O(n)级别，第二维的n可以下降成一个相当小的常数。
因此着重优化的是-a功能，且优化的是可行解的最少步数，而非时间。（因为精确解暂时找不到方法求取）
优化前策略：每次使用最短路径到达下一个最近的未访问点，直至所有点都被访问，然后从最后一个访问点最短路径返回起点。
优化前示例：
从天安门西出发，最后回到天安门西。
优化：在一点上如果有未访问的单向死路（只能原路返回的路径），优先选择，同时每次在最近点和次近点中选择，增加不同的可行方案，最终取最小值。
优化后的路线：
优化前是462个站点，优化后是458个站点。
另外有一种情况（以T2航站楼为起点），优化前480个站点，优化后471个站点。
[b]测试[/b]
并未进行覆盖性测试，因为难以批量检验正确结果。因此选取几个典型测试用例测试关键功能。
第一，机场线单向行驶测试（手工验算）：
上述结果可以证明程序正确处理了机场线单向行驶的特殊情况。
第二，换乘次数最少以及站数最少（手工验算）：
第三，换乘次数相同站数最少（手工验算）：
第四，长距离测试（与百度地图推荐方案比较）：
站数优于百度地图推荐（距离未必最优）。
换乘次数最优为4次。
附加功能结果如上文优化部分图片所述，能够覆盖所有站点。
非附加要求：
| PSP 2.1 | Personal Software Process Stages | Plan | Actual |
| Planning | 计划 | 0.1h | 0.1h |
| · Estimate | · 估计这个任务需要多少时间 | 0.1h | 0.1h |
| Development | 开发 | 6.5h | 7.5h |
| · Analysis | · 需求分析 (包括学习新技术) | 20min | 20min |
| · Design Spec | · 生成设计文档 | - | - |
| · Design Review | · 设计复审 (和同事审核设计文档) | - | - |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | - | - |
| · Design | · 具体设计 | 2h | 2h |
| · Coding | · 具体编码 | 1.5h | 1.5h |
| · Code Review | · 代码复审 | 2h | 3h |
| · Test | · 测试（自我测试，修改代码，提交修改） | 40min | 40min |
| Reporting | 报告 | 0.8h | 0.8h |
| · Test Report | · 测试报告 | 30min | 30min |
| · Size Measurement | · 计算工作量 | 6min | 6min |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 12min | 12min |
| 合计 | 7.4h | 8.4h |
| PSP 2.1 | Personal Software Process Stages | Time |
| Planning | 计划 | 0.1h |
| · Estimate | · 估计这个任务需要多少时间 | 0.1h |
| Development | 开发 | 11h |
| · Analysis | · 需求分析 (包括学习新技术) | 30min |
| · Design Spec | · 生成设计文档 | - |
| · Design Review | · 设计复审 (和同事审核设计文档) | - |
| · Coding Standard | · 代码规范 (为目前的开发制定合适的规范) | - |
| · Design | · 具体设计 | 3h |
| · Coding | · 具体编码 | 2h |
| · Code Review | · 代码复审 | 5h |
| · Test | · 测试（自我测试，修改代码，提交修改） | 40min |
| Reporting | 报告 | 0.8h |
| · Test Report | · 测试报告 | 30min |
| · Size Measurement | · 计算工作量 | 6min |
| · Postmortem & Process Improvement Plan | · 事后总结, 并提出过程改进计划 | 12min |
| 合计 | 11.9h |
-b和-c选项整体思路是BFS
-a附加功能思路是DFS+贪心策略寻找较优可行解。
上图为-c功能时程序性能分布情况。
[b]github[/b]
https://github.com/Helicopt/subway.git
[b]数据格式：[/b]
线号名称 num
站点1[*]
站点2[*]
...
站点|num|[*]
[环路站点[*]]
按站点起始顺序描述一条线路，读到文件末尾完成所有线路的输入
num若为负数，则表示存在环路，最后一个站存在下一站（环路起始），环路站点一定是之前出现过的；若num为正数，则线路不存在环路。
若站点后存在'*'符号，表示上一站到这一站是单向行驶。
这样设计的好处是用尽可能简单的信息将整个地铁图的情况描述清楚，将建边负担交给程序。
[b]算法优化[/b]
前两个功能（-b和-c）计算量上基本已经达到理论上界，效率为O(n)和O(n^2)，对于-c功能，由于地图的简单，实际效率应该属于O(n)级别，第二维的n可以下降成一个相当小的常数。
因此着重优化的是-a功能，且优化的是可行解的最少步数，而非时间。（因为精确解暂时找不到方法求取）
优化前策略：每次使用最短路径到达下一个最近的未访问点，直至所有点都被访问，然后从最后一个访问点最短路径返回起点。
优化前示例：
从天安门西出发，最后回到天安门西。
优化：在一点上如果有未访问的单向死路（只能原路返回的路径），优先选择，同时每次在最近点和次近点中选择，增加不同的可行方案，最终取最小值。
优化后的路线：
优化前是462个站点，优化后是458个站点。
另外有一种情况（以T2航站楼为起点），优化前480个站点，优化后471个站点。
[b]测试[/b]
并未进行覆盖性测试，因为难以批量检验正确结果。因此选取几个典型测试用例测试关键功能。
第一，机场线单向行驶测试（手工验算）：
上述结果可以证明程序正确处理了机场线单向行驶的特殊情况。
第二，换乘次数最少以及站数最少（手工验算）：
第三，换乘次数相同站数最少（手工验算）：
第四，长距离测试（与百度地图推荐方案比较）：
站数优于百度地图推荐（距离未必最优）。
换乘次数最优为4次。
附加功能结果如上文优化部分图片所述，能够覆盖所有站点。
内容来自用户分享和网络整理，不保证内容的准确性，如有侵权内容，可联系管理员处理 
相关文章推荐
- 个人项目-地铁出行路线规划程序
- 【软工个人项目-地铁出行路线规划程序】
- 个人项目-地铁出行路线规划程序
- 个人项目-地铁出行路线规划程序
- 个人项目-地铁出行路线规划程序
- 个人项目-地铁出行线路规划程序
- 结对项目--地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序(续)(附加)
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序（续） （附加）
- 结对项目-地铁出行路线规划程序（续）
- 结对项目--地铁出行路线规划程序（续）——附加题
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序(续)
- 结对项目-地铁出行路线规划程序（续）
- 结对项目-地铁出行路线规划程序（续）