其他分享
首页 > 其他分享> > 郑州地铁计费系统

郑州地铁计费系统

作者:互联网

郑州地铁计费系统



PSP阶段 预计花费时间(小时) 实际花费时间(小时)
计划 1 1
  • 明确需求和其他相关因素,估计每个阶段的时间成本
  • 1 1
    开发 9 14.5
  • 需求分析
  • 2 4
  • 代码规范
  • 1 0.5
  • 具体设计
  • 1 3
  • 具体编码
  • 3 3
  • 代码复审
  • 1 2
  • 测试(自测,修改代码,提交修改)
  • 1 2

    计划:

    在没有做需求分析前,刚拿到这个项目,觉得只需要几个简单的判断即可完成,所以在规划时间时需求分析所占时间并不高


    需求分析:

    制订计划时,觉得需求分析很快就能完成,2个小时绰绰有余,在真正开始做需求分析时才发现了很多问题:

    根据百度到的结果,郑州地铁计费是按照公里来计费,由于无法得到每站的公里数,改为按站的数量进行计费

    但是如果按照站计费,从起点站到终点站可以有很多不同的路线,那么应该选择哪一个?

    最后决定按照最短的一条路径来计费,那么这个项目的重点就发生了改变:怎么求最短路径


    具体设计:

    根据以往javaweb项目开发的经验,第一个反应是设计数据库,经过多次修改最终留下了三个表:普通站点,带换乘的站点,线路

    当设计完数据库后又是一头雾水,该怎么解决需要换乘的最短路径

    如果只有一个换乘,那么我们可以根据根据数据库找到换乘点即可找到,如果有两个我们可以找到两条线上有的换乘点是否同时存在另外一个换乘点上,如果再多就不知道怎么解决了

    因为第一个想法是这样的,让我陷入了严重的误区,找不到解决方法,经过思考,发现这种方法只能得到换乘最少的路线,并不是最短,显然不可行

    随即想到了加坐标,从起点出发,每次都往距离终点更近的方向前进,如果遇到换乘点,走距离终点更近的那条,但是这个想法很快就被否定了,有很多情况不能适用

    随后想了很多情况,但是都被一一否决,最后留下了一个保底的方案,算出所有请求,判断出最短,因为实在太过复杂,决定先百度学习别人的思路

    百度后发现大都采用Dijkstra(迪杰斯特拉)Floyd(弗洛伊德)算法,然后就去学习了这两个算法

    在学习Dijkstra时突然觉得豁然开朗,我们并不需要在乎终点在哪,只要每次都走最短的路径,如果走到了终点,那这条路径就是最短路径

    但是这个算法太复杂,同时还需要一个邻接矩阵,所以去学习了Floyd,拿这两个算法进行比较,Floyd显然简单了许多但是实现需要中间节点,算法的时间复杂度是立方阶,无法接受,最终决定使用Dijkstra

    使用Dijkstra时又有一个一个问题,因为我们是按照站来计算,所以所有权都是1,而且顶点会非常的多,后来想是否可以用换乘点作为顶点,虽然顶点少了,但是每两个顶点的权都要自己手工计算,让我觉得很不舒服,最后放弃了这个想法

    到这里才开始了真正的设计,前面的获取也可以算作为需求分析,现在就回到了最初的问题,是否需要数据库,由于这个项目并不需要扩展,也不需要考虑耦合度等问题,使用数据库只会增加难度,时间有限放弃了这种想法 那如果保存这些数据,首先就需要一个Station类(用来表示站点信息)那么如果保存这个数据,使用数组还是集合,如果使用数组那么就需要用下标表示站点在线路上的位置,虽然可行,但是查找起来太过于麻烦。既然相邻站点之间有联系,那么就可以采用 双向链表的数据结构,我们需要在Station类中添加两个私有属性,分别代表前一个站点和后一个站点。站点信息就保存了下来,那么该怎么保存最短路径那,在使用这个算法时我们会计算出所有顶点的最短路径,那么可以使用Map,key来表示到底是哪个顶点的最短路径 value本来决定使用int来记录经过的站点数量,但是如果我们使用一个set也可以顺便记录经过的站点,到这里总算设计好可以开始编码了


    具体编码 和 代码规范:

    因为前面已经确定了使用何种算法,应该怎么保存数据,所以在具体编码的时候只需要套用别人写的算法,稍加修饰就完成了编码,代码规范因为平时习惯加上编译器的强大,花了很短的时间就搞定了


    代码复审

    由于经验不足,担心不能看出问题,使用debug慢慢检查,对一些细节进行了修改,将之前一个很长的方法抽出了几个方法,同时由于编码时一心只想最短路径的问题,而忽略了当前项目的真实需求,计费。又添加了计费 算法,优化了输出结果


    测试

    由于前面花费了太多时间,没有时间完成很好的覆盖率,仅仅是随机抽取一些数据进行测试,在后期再进行拓展,或许能够发现新的问题


    总结

    因为没有做详细的测试,所以无法写出测试报告,后续再对其进行完善 写完这个项目后,计算自己所花时间,看到结果我是震惊的,原本觉得很简单的问题竟然花费了那么长的时间 ,原来觉得编码才是最花费时间的,结果需求分析和设计花费了更多的时间,事实上设计了很多可能也应该算作需求分析, 之前觉得需求分析只需要知道什么要求即可,现在发现要求里可以并不完整,可能那些隐藏的但是你需要完成的需求才是最难完成的

    所以在拿到需求时不能仅仅靠第一感觉,要深入的思考,真正的需求是什么,如果需求就弄错了,那后续编写的代码也是无用代码

    标签:需求,路径,郑州,站点,算法,地铁,计费,换乘
    来源: https://www.cnblogs.com/nzw2001/p/14639667.html