Aplicación de algoritmos de búsqueda en la optimización de caminos de coste mínimo en grafos de decisión

Texto completo

(1)

(2) AGRADECIMIENTOS A mi familia por su apoyo durante toda la carrera. A mi tutor Vicente por brindarme su ayuda y dedicación..

(3) Índice general. 1. RESUMEN 1.1. ESPAÑOL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2. ENGLISH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 1 1 2. 2. INTRODUCCIÓN Y OBJETIVOS 2.1. OBJETIVOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.1. PRIMERA FASE . . . . . . . . . . . . . . . . . . . . . . . . . . 2.1.2. SEGUNDA FASE . . . . . . . . . . . . . . . . . . . . . . . . .. 3 5 5 5. 3. BREVE ESTUDIO DEL ALGORITMO 3.0.3. DEFINICIÓN: . . . . . . . . . . . . . . . . . . . . . . . . . . . 3.0.4. CARACTERÍSTICAS PRINCIPALES: . . . . . . . . . . . . . .. 6 6 7. 4. TOMA DE MEDIDAS. 8. 5. FASE 1 5.1. MAPA CONCEPTUAL 1º FASE . . . . . . . 5.2. ESPECIFICACIÓN DE REQUISITOS . . . . 5.3. DISEÑO DE ALTO NIVEL PRIMERA FASE 5.4. DISEÑO DE BAJO NIVEL PRIMERA FASE 5.5. PLAN DE PRUEBAS . . . . . . . . . . . . . 5.5.1. PRUEBAS UNITARIAS . . . . . . . 5.5.2. PRUEBAS DE ENSAMBLAJE . . . 5.5.3. CASOS DE USO . . . . . . . . . . . 5.6. IMPLEMENTACIÓN PRIMERA FASE . . . 5.6.1. LIBRERÍAS UTILIZADAS . . . . . 5.6.2. OTROS . . . . . . . . . . . . . . . . 5.6.3. CÓDIGO . . . . . . . . . . . . . . . 2. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 12 12 14 15 15 17 17 18 21 31 31 32 32.

(4) 5.7. EVALUACIÓN DE LA PRIMERA FASE . . . . . . . . . . . . . . . . . 6. FASE 2 6.1. MODIFICACIONES AL PROYECTO . . . . 6.2. DIAGRAMA DE GANTT DEL PROYECTO 6.3. RE-ANÁLISIS DE REQUISITOS . . . . . . 6.4. MAPA CONCEPTUAL 2º FASE . . . . . . . 6.5. DISEÑO DE ALTO NIVEL 2º FASE . . . . 6.6. DISEÑO DE BAJO NIVEL 2º FASE . . . . . 6.7. IMPLEMENTACIÓN 2º FASE . . . . . . . . 6.7.1. PROGRAMAS UTILIZADOS . . . . 6.7.2. LIBRERÍAS UTILIZADAS . . . . . 6.7.3. OTROS . . . . . . . . . . . . . . . . 6.7.4. CÓDIGO . . . . . . . . . . . . . . . 6.8. PLAN DE PRUEBAS . . . . . . . . . . . . . 6.8.1. PRUEBAS UNITARIAS . . . . . . . 6.8.2. PRUEBAS DE ENSAMBLAJE . . . 6.8.3. CASOS DE USO . . . . . . . . . . .. 32. . . . . . . . . . . . . . . .. 34 34 35 37 39 41 41 43 43 43 44 44 44 45 50 55. 7. RESUMEN Y CONCLUSIONES 7.1. EVALUACIÓN FINAL . . . . . . . . . . . . . . . . . . . . . . . . . . . 7.2. CONCLUSIONES . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 69 69 72. 8. CITAS Y BIBLIOGRAFÍA. 73. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. 9. ANEXO A: CÓDIGO DESARROLLADO 1º FASE 9.1. Package Arbol . . . . . . . . . . . . . . . . . . . 9.1.1. Arbol.java . . . . . . . . . . . . . . . . . 9.1.2. Elemento.java . . . . . . . . . . . . . . . 9.1.3. LTree.java . . . . . . . . . . . . . . . . . 9.1.4. LTree.java . . . . . . . . . . . . . . . . . 9.2. Package Grafica . . . . . . . . . . . . . . . . . . 9.2.1. AA.java . . . . . . . . . . . . . . . . . . 9.2.2. ChoiceLle.java . . . . . . . . . . . . . . 9.2.3. ChoiceSal.java . . . . . . . . . . . . . . 9.2.4. Dibujo.java . . . . . . . . . . . . . . . . 9.2.5. Pixel.java . . . . . . . . . . . . . . . . . 9.2.6. Ventana.java . . . . . . . . . . . . . . . 9.3. Package Grafo . . . . . . . . . . . . . . . . . . . 9.3.1. Grafo.java . . . . . . . . . . . . . . . . . 9.3.2. Nodo.java . . . . . . . . . . . . . . . . . 3. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. 74 74 74 80 82 87 89 89 109 117 125 129 131 136 136 141.

(5) 10. ANEXO B: CÓDIGO DESARROLLADO 2º FASE 10.1. Package Arbol . . . . . . . . . . . . . . . . . . . 10.1.1. Arbol.java . . . . . . . . . . . . . . . . . 10.1.2. Elemento.java . . . . . . . . . . . . . . . 10.1.3. LTree.java . . . . . . . . . . . . . . . . . 10.1.4. LTreeNode.java . . . . . . . . . . . . . . 10.2. Package Grafica . . . . . . . . . . . . . . . . . . 10.2.1. AA.java . . . . . . . . . . . . . . . . . . 10.2.2. ChoiceLle.java . . . . . . . . . . . . . . 10.2.3. ChoiceSal.java . . . . . . . . . . . . . . 10.2.4. Dibujo.java . . . . . . . . . . . . . . . . 10.2.5. menuayuda.java . . . . . . . . . . . . . . 10.2.6. menumapa.java . . . . . . . . . . . . . . 10.2.7. Pixel.java . . . . . . . . . . . . . . . . . 10.2.8. Principal.java . . . . . . . . . . . . . . . 10.2.9. Ventana.java . . . . . . . . . . . . . . . 10.3. Package Grafo . . . . . . . . . . . . . . . . . . . 10.3.1. Grafo.java . . . . . . . . . . . . . . . . . 10.3.2. Nodo.java . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . .. 143 143 143 150 153 159 161 161 181 190 199 208 212 216 218 219 229 229 234.

(6)

(7) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 1 RESUMEN. 1.1.. ESPAÑOL. El presente proyecto tratará sobre la aplicación de un algoritmo que ayude a tomar decisiones en un grafo para llegar desde un nodo a otro. Dicho grafo representará el mapa de la ciudad de Valencia, el cual tendrá tantos nodos como estaciones existan. Para dicho proyecto el objetivo es preparar y documentar el proceso que se darı́a a lo largo de un proyecto real de software estableciendo ası́ tanto los requisitos como los diseños de alto y bajo nivel para el mismo, un plan de pruebas, la implementación del proyecto en lenguaje java y una evaluación final que ayude a determinar la solidez de la aplicación de ese algoritmo en dicho grafo. Al igual que en los proyectos software, el desarrollo del mismo se hará en varias fases bien definidas entre sı́, en las cuales se irá depurando y mejorando. Dada la dificultad del proyecto, el numero de fases establecidas ha sido de dos. En ambas se aplicarán los mismos criterios de programación y desarrollo de la documentación, entregándose ası́ en la memoria de seguimiento la primera fase del proyecto casi en su totalidad siendo de esta forma establecida como primer Deadline de entrega del proyecto. La segunda fase, se dedicará a cumplir con los requisitos que no hayan sido superados a lo largo del primer ciclo o que se hayan decidido añadir tras la finalización de la primera fase (re-análisis), finalizando ası́ todo el proyecto en la entrega del segundo Deadline y habiendo solucionado los posibles errores de implementación encontrados en la evaluación de la primera fase.. R.Sanz. 1.

(8) Escuela Técnica Superior de Ingenieros Informáticos. 1.2.. Enero 2016. ENGLISH. The following project will show the application of decision making algorythms in the selection of the fastest path between two nodes. This selection will be done in a specific graph: Valencia’s Underground System. The number of nodes will be defined by the number of stations that this map has. This project will be defined and done like a software engineering project, establishing a system of requirements, the high level design and the low level design. Also, a system test will be done and the implementation of the proyect using Java language. Finally, an evaluation will be applied using the test system in order to find out the mistakes and subsequently,in a second phase fix them. The second phase will be used to finish all the requirements (including the new ones) and the mistakes of the first phase will be arranged. There will be two deadlines along the development: the first one will coincide with the delivery of the tracking memory and the second one will be on the delivery of the final memory.. R.Sanz. 2.

(9) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 2 INTRODUCCIÓN Y OBJETIVOS En la actualidad, la aplicación de diferentes algoritmos matemáticos se encuentra en todos los ámbitos de nuestra vida. Desde las búsquedas más sencillas que un usuario puede hacer en un buscador de internet, hasta los sistemas de geoposicionamiento mas sofisticados del momento. Estos algoritmos, tienen una mayor o menor capacidad de adaptación a la resolución de ciertos problemas, resultando ası́ más o menos útiles según qué problemas necesitemos resolver. Con el actual crecimiento exponencial de los núcleos urbanos, los sistemas de transporte se han ido sofisticando y agrandando en función de las necesidades, llegando a un punto en el cual, el usuario necesita la ayuda de sistemas informáticos que le puedan orientar tanto para localizar el destino al que quieren llegar como la forma de llegar a ese destino. Este proyecto, pretende abordar la problemática de estos usuarios, centrándolo en las búsquedas de caminos mas cortos para llegar desde su origen a su destino y aplicándolo más concretamente a los sistemas de metro que tantas ciudades poseen en todo el mundo y a su vez, presentando de forma gráfica una interfaz amigable que permita mostrarles el resultado de la búsqueda en cuestión. De entre todos los algoritmos existentes en la actualidad para localizar el camino de menor coste, se utilizará el Algoritmo a Estrella cuya definición viene dada por la siguiente afirmación (entre otras): .El algoritmo A* se clasifica dentro de los algoritmos de búsqueda informados. Encuentra siempre y cuando se cumplan unas determinadas condiciones, el camino de menor coste entre un vértice origen y uno destino. El problema de algunos algoritmos de búsqueda en grafos informados, es que se guı́an en exclusiva por la función heurı́stica, la cual puede no indicar el camino de coste más. R.Sanz. 3.

(10) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. bajo, o por el coste real de desplazarse de un nodo a otro. Pudiéndose dar el caso de que sea necesario realizar un movimiento de coste mayor para alcanzar la solución. Se da por ello el hecho de que un buen algoritmo de búsqueda informada deberı́a tener en cuenta ambos factores, el valor heurı́stico de los nodos y el coste real recorrido. Ası́, el algoritmo A* utiliza una función de evaluación F = G + H, donde H representa el valor heurı́stico del nodo a evaluar desde el actual hasta el nodo de destino. Y G el coste real del camino recorrido para llegar a dicho nodo destino.[2]”. R.Sanz. 4.

(11) Escuela Técnica Superior de Ingenieros Informáticos. 2.1.. Enero 2016. OBJETIVOS. Los objetivos son: Breve estudio del algoritmo.. 2.1.1.. PRIMERA FASE. 1. Análisis del problema. 2. Análisis de requisitos: Elegir el orden de los problemas, estableciendo unos requisitos que permitan solucionarlos. 3. Diseños de alto y bajo nivel. 4. Plan de pruebas. 5. Implementación y codificación: Implementar el algoritmo. Crear una interfaz gráfica. 6. Evaluación de la primera fase: Aplicar el plan de pruebas para depurar y mejorar el proyecto en una segunda fase pasado el primer Deadline.. 2.1.2.. SEGUNDA FASE. 1. Reanálisis del problema partiendo de los datos obtenidos en la primera fase. 2. Revisión de los requisitos para la segunda fase. 3. Cambios en el diseño de alto y bajo nivel en el caso de ser necesarios. 4. Implementación y codificación: Mejorar la implementación del algoritmo su fuera necesario. Modificar la interfaz gráfica para que quede de forma definitiva. 5. Evaluación de la segunda fase.. R.Sanz. 5.

(12) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 3 BREVE ESTUDIO DEL ALGORITMO En esta sección se introducirá de forma orientativa el algoritmo siguiendo distintas definiciones encontradas por Internet [4].. 3.0.3.. DEFINICIÓN:. El algoritmo de búsqueda A* se clasifica dentro de los algoritmos de búsqueda en grafos. Presentado por primera vez en 1968 por Peter E. Hart, Nils J. Nilsson y Bertram Raphael, el algoritmo A* encuentra, siempre y cuando se cumplan unas determinadas condiciones, el camino de menor coste entre un nodo origen y uno objetivo. El problema de algunos algoritmos de búsqueda es que se guı́an en exclusiva por la función heurı́stica, la cual puede no indicar el camino de coste más bajo, o por el coste real de desplazarse de un nodo a otro (como los algoritmos de escalada), pudiéndose dar el caso de que sea necesario realizar un movimiento de coste mayor para alcanzar la solución. Es por ello que un buen algoritmo de búsqueda informada deberı́a tener en cuenta ambos factores, el valor heurı́stico de los nodos y el coste real del recorrido. Ası́, el algoritmo A* utiliza una función de evaluación: f (n) = g(n) + h (n). (3.1). Donde, g(n) : el coste real del camino recorrido para llegar a dicho nodo, n, desde el nodo inicial h (n) : representa el valor heurı́stico del nodo a evaluar R.Sanz. 6.

(13) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. A su vez, A* mantiene dos estructuras de datos auxiliares, que podemos denominar abiertos, implementado como una cola de prioridad (ordenada por el valor f (n) de cada nodo), y cerrados, donde se guarda la información de los nodos que ya han sido visitados. En cada paso del algoritmo, se expande el nodo que esté primero en abiertos, y en caso de que no sea un nodo objetivo, calcula la f (n) de todos sus hijos, los inserta en abiertos, y pasa el nodo evaluado a cerrados.. 3.0.4.. CARACTERÍSTICAS PRINCIPALES:. Como todo algoritmo de búsqueda en amplitud, A* es un algoritmo completo: en caso de existir una solución, siempre dará con ella. Si para todo nodo n del grafo se cumple g(n) = 0, nos encontramos ante una búsqueda voraz. Si para todo nodo n del grafo se cumple h(n) = 0, A* pasa a ser una búsqueda de coste uniforme no informada. Para garantizar la optimización del algoritmo, la función h(n) debe ser heurı́stica admisible, esto es, que no sobrestime el coste real de alcanzar el nodo objetivo. De no cumplirse dicha condición, el algoritmo pasa a denominarse simplemente A, y a pesar de seguir siendo completo, no se asegura que el resultado obtenido sea el camino de coste mı́nimo. Asimismo, si garantizamos que h(n) es consistente (o monótona), es decir, que para cualquier nodo n y cualquiera de sus sucesores, el coste estimado de alcanzar el objetivo desde n no es mayor que el de alcanzar el sucesor más el coste de alcanzar el objetivo desde el sucesor.. R.Sanz. 7.

(14) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 4 TOMA DE MEDIDAS La toma de medidas se ha realizado con la herramienta de medición de Google Maps. Dichas medidas son aproximadas ya que se han ajustado algunas a mano para la realización de pruebas. A continuación se muestran algunas imágenes extraı́das de dicho proceso. No se ha tomado ninguna estación como referencia al tratarse de un grafo por lo que la medición se ha hecho entre estaciones sin dejar ninguna variación entre medias.. Posicionamiento de estaciones de metro y cercanı́as de Valencia:. R.Sanz. 8.

(15) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Situación geográfica de todo el plano zonal valenciano:. Gracias a la tecnologı́a desarrollada por Google Maps, se puede superposicionar el plano zonal de transportes de Valencia para trabajar sobre el terreno. Esto ha sido de gran ayuda ya que si hubiera sido de otra forma, se habrı́an dado serios problemas debido a que el tiempo habrı́a sido todavı́a mucho mayor del que ha sido hasta ahora, que ya ha supuesto demasiado.. R.Sanz. 9.

(16) Escuela Técnica Superior de Ingenieros Informáticos. Confluencia de varias lineas en una misma estación:. Ejemplos de extracción de medidas con google maps:. R.Sanz. 10. Enero 2016.

(17) Escuela Técnica Superior de Ingenieros Informáticos. R.Sanz. 11. Enero 2016.

(18) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 5 FASE 1 En esta sección se detallará el desarrollo de todo el proyecto al completo. Ambas fases vendrán detalladas en la memoria de forma que se puedan ver los cambios que se han ido realizando a lo largo del mismo.. 5.1.. MAPA CONCEPTUAL 1º FASE. En esta sección se muestra un mapa conceptual de las principales funciones de la aplicación. Las ’extras’ como cargado y guardado de rutas no se muestran. Como podemos observar, el usuario mediante su computadora seleccionará una estación origen y una estación destino de las que están incluidas en el metro de Valencia. Una vez realizada dicha selección, el usuario pulsará el botón ’Send’ el cual dará la orden de búsqueda de la ruta mas corta al algoritmo implementado en el desarrollo. A su vez, se generará una ventana emergente la cual mostrará por pantalla la ruta escogida por el algoritmo, dando una lista detallada de las estaciones y la lı́nea al a que pertenece dicha estación (el itinerario a seguir por el usuario). Una vez mostrado, el usuario volverá a obtener el control del programa.. R.Sanz. 12.

(19)

(20) Escuela Técnica Superior de Ingenieros Informáticos. 5.2.. Enero 2016. ESPECIFICACIÓN DE REQUISITOS. En la siguiente sección se describen los requisitos establecidos en una reunión predesarrollo. Como se podrá comprobar, están divididos en dos clases: de Sistema y de Interfaz. En los primeros se detallarán los requisitos relativos a qué pautas deben seguirse y cumplirse para crear el proyecto. En los requisitos de Interfaz se detallará qué debe cumplirse a la hora de crear la interfaz gráfica del proyecto. La especificación de requisitos y su organización se basa en el estándar IEEE-STD-8301998 [1]: 1. Sistema 1.1. El Sistema tendrá que contener tantos nodos como estaciones tenga el metro de Valencia 1.2. El Sistema implementará el algoritmo a estrella para calcular el camino de menor coste. 1.3. El Sistema funcionará de forma autónoma y sin conexión a Internet. 1.4. El Sistema deberá estar implementado en Java, utilizando una librerı́a especializada. 1.5. El Sistema deberá ser aplicable a cualquier red de metro en caso de ser necesario. NOTA: Se deberá encontrar una solución genérica al problema que aplique el algoritmo y permita ser utilizado para cualquier red de metro cambiando los datos de las estaciones en cuestión.. 2. Interfaz 2.1. El Sistema mostrará una lista de todas las estaciones por las que deberá pasar para llegar desde el origen al destino. 2.2. El Sistema permitirá al usuario seleccionar la estación de origen. 2.3. El Sistema permitirá al usuario seleccionar la estación destino. 2.4. El Sistema tendrá una interfaz gráfica depurada que muestre las estaciones de forma intuitiva y sencilla. 2.4.1. El Sistema será lo más fiel posible a la regla de los 3 clics [5] 2.4.2. El Sistema permitirá salir de la aplicación mediante el correspondiente botón. 2.4.3. El Sistema ofrecerá la posibilidad de mostrar quien ha sido el desarrollador del sistema.. R.Sanz. 14.

(21) Escuela Técnica Superior de Ingenieros Informáticos. 5.3.. Enero 2016. DISEÑO DE ALTO NIVEL PRIMERA FASE. La arquitectura utilizada para el diseño de alto nivel de la aplicación, es la arquitectura basada en capas, la cual esta formada por tres en este caso: Capa de Presentación: La interfaz gráfica, la cual estará de cara a los usuarios de la aplicación. Capa de Negocio: En esta capa se sitúa toda la implementación interna del algoritmo a estrella, la cual se encargará de procesar las rutas encontrando el camino mas corto para cada petición que haga el usuario. Capa de Datos: Esta capa contendrá todos los datos extraı́dos del metro de Valencia y los cuales serán la fuente en la cual se apoyara la capa de Negocio para realizar las búsquedas.. 5.4.. DISEÑO DE BAJO NIVEL PRIMERA FASE. El diseño de Bajo Nivel ha sido creado con la herramienta ObjectAid UML Explorer para el entorno de desarrollo Eclipse.. R.Sanz. 15.

(22)

(23) Escuela Técnica Superior de Ingenieros Informáticos. 5.5.. Enero 2016. PLAN DE PRUEBAS. El siguiente plan se ha diseñado para poner a prueba de tres formas distintas el proyecto. A pesar de ser pocas pruebas, las funciones principales del programa han sido cubiertas en esta primera fase. En las pruebas unitarias lo más importante es la comprobación del algoritmo (ver que calcula bien la ruta que se elija y que devuelve la lista de estaciones por las que pasar a modo de itinerario del camino más corto). Respecto a las pruebas de ensamblaje, lo más importante es probar los 4 puntos crı́ticos del sistema que son los puntos donde interfaz gráfica y código se unen: las pulsaciones de los botones, las selecciones de las estaciones y la devolución de la ruta en cuestión en una ventana emergente. Por último, como pruebas definitivas, se han diseñado varios casos de uso en los cuales la utilización del software será puesto a prueba, y el algoritmo tendrá que buscar rutas cada vez más complicadas.. 5.5.1.. PRUEBAS UNITARIAS. Selección del camino mas corto (prueba del algoritmo): • Objetivo: Dada una estación origen y una estación destino, la aplicación deberá devolver una ruta que sea la del camino mas corto para llegar de una estación a otra • Resultado: SATISFACTORIO Como ejemplo, para la estaciones seleccionadas: Alameda y Alboraya Palmaret, el camino devuelto es el siguiente:. R.Sanz. 17.

(24) Escuela Técnica Superior de Ingenieros Informáticos. 5.5.2.. Enero 2016. PRUEBAS DE ENSAMBLAJE. Selección de estación origen: • Objetivo: Buscar mediante scroll vertical la estación de origen que el usuario quiera seleccionar. • Resultado: SATISFACTORIO. Selección de estación destino: • Objetivo: Buscar mediante scroll vertical la estación de destino que el usuario quiera seleccionar. • Resultado: SATISFACTORIO. R.Sanz. 18.

(25) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Selección de Envı́o de información: • Objetivo: Una vez superadas las dos pruebas anteriores, Pulsado de botón Aceptar. Debe devolver una ventana emergente con una lista de estaciones. • Resultado: SATISFACTORIO. Ensamblado de Interfaz gráfica con módulo de código: • Objetivo: Comprobar que todas las selecciones y botones realizan su función. Seleccionar estación de origen y estación destino. Una vez seleccionadas pulsar Aceptar. • Devuelve: Debe generar una ventana emergente en la cual aparecerá una lista de las estaciones en cuestión que sigue el camino calculado. • Resultado: SATISFACTORIO. R.Sanz. 19.


(27) Escuela Técnica Superior de Ingenieros Informáticos. 5.5.3.. Enero 2016. CASOS DE USO. En esta sección se detallan algunos casos de uso utilizados para poner a prueba la aplicación. Van de menor a mayor dificultad.. De una estación a otra adyacente: Nombre Actores Función. Trayecto de estaciones adyacentes Usuario Saber cual es el itinerario más corto entre dos estaciones adyacentes Descripción El usuario puede elegir una estación origen y una estación destino que sean adyacentes. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro. Origen: Empalme (Linea 4) Destino: Palau de Congressos (Linea 4). R.Sanz. 21.


(29) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. De una estación a otra de la misma linea: Nombre Actores Función Descripción. Trayecto de una lı́nea sin transbordos Usuario Saber cual es el itinerario más corto entre dos estaciones de la misma linea El usuario puede elegir una estación origen y una estación destino dentro de la misma linea de metro. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro.. Origen: Empalme (Linea 4) Destino: Transits (Linea 4). R.Sanz. 23.


(31) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. De una estación a otra de una linea distinta con un transbordo: Nombre Actores Función Descripción. Trayecto de varias lineas con un transbordo Usuario Saber cual es el itinerario más corto entre dos estaciones de distintas lineas El usuario puede elegir una estación origen y una estación destino situadas en dos lineas distintas siempre y cuando solo haya un transbordo entre ellas. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro.. Origen: Sagunt (Linea 4) Destino: Orriols (Linea 6). R.Sanz. 25.


(33) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. De una estación a otra de una linea distinta con dos transbordos: Nombre Actores Función. Trayecto de una linea con dos transbordos Usuario Saber cual es el itinerario más corto entre dos estaciones de distintas lineas Descripción El usuario puede elegir una estación origen y una estación destino situadas en dos lineas distintas siempre y cuando haya dos transbordo entre ellas. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro. Origen: Palau de Congressos (Linea 4) Destino: Mislata (Linea 3). R.Sanz. 27.


(35) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Usuario quiere ver quién desarrolló el proyecto: Nombre Actores Función Descripción. Ver desarrollador Usuario Consultar quien ha desarrollado la aplicación El usuario puede consultar quien es ha desarrollado de la aplicación. Hacer click en ’Archivo’, ’A cerca de...’. R.Sanz. 29.

(36) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Usuario quiere salir del programa Nombre Actores Función Descripción. Salir del programa Usuario Salir del programa sin haber hecho una búsqueda El usuario puede salir del programa sin haber hecho una búsqueda previamente sin tener que cerrar la ventana de forma abrupta. Hacer click en ’Archivo’, ’Salir’. R.Sanz. 30.

(37) Escuela Técnica Superior de Ingenieros Informáticos. 5.6.. IMPLEMENTACIÓN PRIMERA FASE. 5.6.1.. LIBRERÍAS UTILIZADAS. Enero 2016. Para el desarrollo del proyecto se han utilizado especı́ficamente dos librerı́as externas de Java a parte de las que vienen por defecto:. Java Decision Diagram Libraries: Esta librerı́a se puede localizar el siguiente enlace [6]:. http://java-decision-diagram-libraries.soft112.com/ This project contains two different Binary Decision Diagrams (BDD) libraries: 1. JBDD: a Java interface to two popular BDD libraries, CUDD and BuDDy. 2. JDD: a native Java library supporting BDD, Z-BDD and more (graph/automata/Petri nets/SAT).. Net Datastructures 5: Esta librerı́a se puede localizar en el siguiente enlace [7]:. http://net3.datastructures.net/ net.datastructures is a Java package containing a collection of Java interfaces and classes that implement fundamental data structures and algorithms, such as: sequences, trees, priority queues, search trees, hash tables sorting algorithms graphs, their traversals, and applications, (e.g. shortest paths) The package was designed for educational use. It provides a set of functional components defined by simple APIs and easy to use. The code is readable, reliable, asymptotically efficient, and object-oriented. Programming can be done through interfaces only, with knowledge of specific implementations necessary only for specialized applications. net.datastructures has been developed at Brown University and at the University of California, Irvine. The work on this project was supported in part by the National Science Foundation under grants DUE-0231202 and DUE-0231467.. R.Sanz. 31.

(38) Escuela Técnica Superior de Ingenieros Informáticos. 5.6.2.. Enero 2016. OTROS. ObjectAir UML Explorer Herramienta de visualización de código creada para el IDE de Eclipse. Permite ver en tiempo real el código implementado dentro de un proyecto como si fuera un diagrama UML.[8].. Latex Toda la memoria del proyecto ha sido realizada en Latex, utilizando diversas librerı́as de inserción de código para los Anexos finales.[9].. 5.6.3.. CÓDIGO. Todo el código desarrollado en el ciclo 1 se podrá ver en el Anexo B situado al final de la Memoria de Seguimiento. El lenguaje utilizado es Java, con el entorno Eclipse Jee Neon. Las librerı́as ya mencionadas en la sección anterior son las que se han utilizado para desarrollar el proyecto.. 5.7.. EVALUACIÓN DE LA PRIMERA FASE. En general el desarrollo del proyecto ha sido un poco complicado desde el punto de vista de tener que compaginar toda la documentación con el desarrollo del algoritmo. Inicialmente con la creación del mapa conceptual se pudo aproximar una idea muy generalizada del objetivo de la aplicación pudiendo ası́ perfilar lo que serı́a posteriormente el proyecto una vez se ahondase en el mismo. Una vez visto el objetivo que se pretendı́a conseguir, toda la atención se centró en la búsqueda de unos requisitos que pudieran acotar el problema a resolver por parte del creador del proyecto y a su vez tomar un primer contacto con la supuesta organización del código a desarrollar. La inversión de tiempo en lo que a los diseños de Alto y Bajo nivel se refiere, quedaron un poco descompensadas desde el punto de vista del desarrollo puesto que se fueron dando cambios que pudieran ayudar a implementar de una forma más sencilla el proyecto en detrimento de la idea inicial. Respecto al plan de pruebas, se diferenciaron tres tipos de pruebas: unitarias, ensamblaje y casos de uso. Teniendo en cuenta el enfoque del desarrollo, se consideró que el plan creado era más que suficiente para poner a prueba todo el software, tanto la parte gráfica R.Sanz. 32.

(39) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. como el código interno de la aplicación. Una vez definidos todos los pasos anteriores se comenzó con el desarrollo de la aplicación. Inicialmente fue bastante costoso, llevándome a invertir más horas de las previstas en el plan de trabajo puesto que debı́a introducir los datos de todas las estaciones del Metro de Valencia por lo que no me quedó más remedio que invertir horas extras (aproximadamente 10 horas entre localización de las estaciones, cálculos pertinentes e introducción de la información de las mismas en java). La implementación del algoritmo me llevo a invertir prácticamente la mayorı́a de las horas planificadas ya que tenı́a conocimientos previos sobre como implementar interfaces gráficas. Una vez implementado todo el proyecto correspondiente a la primera fase, comenzó la aplicación de las pruebas del plan creado para localizar errores. El fallo más grande que se dió y que será corregido es el ya mencionado anteriormente (error de envió al no seleccionar ninguna estación, caso no tratado). Por otro lado, se detectó cierta inestabilidad a la hora de representar por pantalla el listado de estaciones, pero a diferencia del error anterior, al incluir la segunda fase el arreglo de la interfaz, se espera que sea subsanado cuando se hagan los cambios. Como conclusión del proceso de desarrollo de la primera fase del proyecto, se puede afirmar sin duda alguna que está siendo un éxito la implementación del algoritmo (a pesar de las dificultades tenidas al principio del mismo) habiéndose cumplido los requisitos: 1.1, 1.2, 1.3, 1.4, 1.5, 2.1, 2.2, 2.3, 2.4.1, 2.4.2, 2.4.3.. R.Sanz. 33.

(40) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 6 FASE 2. 6.1.. MODIFICACIONES AL PROYECTO. En este capı́tulo se describen los objetivos del trabajo modificados para la finalización del proyecto. Durante toda la primera fase, se han ido cumpliendo las metas y requisitos establecidos para la misma, llegando a un grado de completud bastante alto. Después de la entrega intermedia, y a modo de reunión orientativa, se establecieron nuevos objetivos, los cuales estarı́an directamente basados y relacionados con los de la primera fase. Cabe destacar que el método de trabajo ha sido exactamente el mismo y el esfuerzo de horas se ha volcado aproximadamente de la misma manera que en la primera fase, con la excepción de que al estar parte de la documentación hecha, algunas de estas horas se han utilizado para optimizar el código y mejorar su legibilidad en la sección de interfaz gráfica, buscar algunos nuevos requisitos y preparar un plan de pruebas que fuera acorde con los mismos de forma que todo quedase mucho mas completo. A nivel estructural del presente documento (Memoria Final), se puede afirmar que no ha cambiado nada ya que únicamente han sido añadidas las partes relativas a la segunda fase. A excepción de lo mencionado, el proyecto ha seguido su curso en torno a la organización ya establecida en la reunión inicial.. R.Sanz. 34.

(41) Escuela Técnica Superior de Ingenieros Informáticos. 6.2.. Enero 2016. DIAGRAMA DE GANTT DEL PROYECTO. En la figura añadida en la página siguiente se puede observar la organización a lo largo de sus 324 horas de duración. Al ser una modificación del diagrama del Plan de Trabajo, se podrá observar que el número de horas dedicadas a las tareas mencionadas anteriormente han sido modificadas y a su vez, se han eliminado los tres objetivos descritos al final de la sección ’Revisión de la lista de objetivos’. Igualmente, la suma de todas las horas del proyecto sigue siendo 324, por lo que se considera que la carga de trabajo asignada es la adecuada. En la página siguiente se muestra el diagrama de Gantt modificado.. R.Sanz. 35.


(43) Escuela Técnica Superior de Ingenieros Informáticos. 6.3.. Enero 2016. RE-ANÁLISIS DE REQUISITOS. En la siguiente sección se describen los requisitos establecidos en una reunión intermedia realizada después de la entrega de la primera fase. Como se podrá comprobar, están divididos en dos clases: de Sistema y de Interfaz. En los primeros se detallarán los requisitos relativos a qué pautas deben seguirse y cumplirse para crear el proyecto. En los requisitos de Interfaz se detallará qué debe cumplirse a la hora de crear la interfaz gráfica del proyecto. Para esta segunda fase, se ha realizado el añadido de varios requisitos debido a que en la primera fase se pudo cumplir relativamente bien con los plazos de entrega. Se ha acentuado sobre todo el esfuerzo en la mejora de la interfaz gráfica y el añadido de la funcionalidad de mapa. La especificación de requisitos y su organización se basa en el estándar IEEE-STD-8301998 [1]: 1. Sistema 1.1. El Sistema tendrá que contener tantos nodos como estaciones tenga el metro de Valencia 1.2. El Sistema implementará el algoritmo a estrella para calcular el camino de menor coste. 1.3. El Sistema funcionará de forma autónoma y sin conexión a Internet. 1.4. El Sistema deberá estar implementado en Java, utilizando una librerı́a especializada. 1.5. El Sistema deberá ser aplicable a cualquier red de metro en caso de ser necesario. 1.6. El Sistema deberá permitir el añadido de módulos complementarios que permitan aumentar el número de funcionalidades de forma limpia. NOTA: Se deberá encontrar una solución genérica al problema que aplique el algoritmo y permita ser utilizado para cualquier red de metro cambiando los datos de las estaciones en cuestión.. 2. Interfaz 2.1. El Sistema mostrará una lista de todas las estaciones por las que deberá pasar para llegar desde el origen al destino. 2.2. El Sistema permitirá al usuario seleccionar la estación de origen. 2.3. El Sistema permitirá al usuario seleccionar la estación destino. 2.4. El Sistema tendrá una interfaz gráfica depurada que muestre las estaciones de forma intuitiva y sencilla. 2.4.1. El Sistema será lo más fiel posible a la regla de los 3 clics [5] R.Sanz. 37.

(44) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 2.4.2. El Sistema permitirá salir de la aplicación mediante el correspondiente botón. 2.4.3. El Sistema ofrecerá la posibilidad de mostrar quien ha sido el desarrollador del sistema. 2.5. El sistema ofrecerá de forma limpia la ruta en una ventana emergente. 2.5.1. Dicha ventana emergente podrá ser cerrada de forma individual y sin causar fallos al resto de la aplicación. 2.6. El sistema ofrecerá la opción de poder ver el mapa del metro de la ciudad en cuestión en una ventana emergente. 2.6.1. Dicha ventana emergente podrá ser cerrada de forma individual y sin causar fallos al resto de la aplicación. 2.7. El sistema ofrecerá en cada ventana de la aplicación la opción de salir mediante un botón. 2.8. El sistema ofrecerá un botón en la ventana principal de la aplicación llamado Ayuda que ofrezca información a los usuarios de la misma.. R.Sanz. 38.

(45) Escuela Técnica Superior de Ingenieros Informáticos. 6.4.. Enero 2016. MAPA CONCEPTUAL 2º FASE. En esta sección se muestra un mapa conceptual de las funciones de la aplicación. Como podemos observar, el usuario mediante su computadora seleccionará una estación origen y una estación destino de las que están incluidas en el metro de Valencia. Una vez realizada dicha selección, el usuario pulsará el botón ’Send’ el cual dará la orden de búsqueda de la ruta mas corta al algoritmo implementado en el desarrollo. A su vez, se generará una ventana emergente la cual mostrará por pantalla la ruta escogida por el algoritmo, dando una lista detallada de las estaciones y la lı́nea a la que pertenece dicha estación (el itinerario a seguir por el usuario). Una vez mostrado, el usuario volverá a obtener el control del programa. Por otro lado, el usuario podrá observar en todo momento el mapa del metro accediendo a él desde el menú superior de la aplicación y/o consultar el menú de ayudas situado en el botón que la aplicación tendrá al sur de su ventana principal.. R.Sanz. 39.

(46)

(47) Escuela Técnica Superior de Ingenieros Informáticos. 6.5.. Enero 2016. DISEÑO DE ALTO NIVEL 2º FASE. Como ya se comentó en la primera fase, la arquitectura utilizada para el diseño de alto nivel de la aplicación, es la arquitectura basada en capas, la cual esta formada por tres en este caso: Capa de Presentación: La interfaz gráfica, la cual estará de cara a los usuarios de la aplicación. Capa de Negocio: En esta capa se sitúa toda la implementación interna del algoritmo a estrella, la cual se encargará de procesar las rutas encontrando el camino mas corto para cada petición que haga el usuario. Capa de Datos: Esta capa contendrá todos los datos extraı́dos del metro de Valencia y los cuales serán la fuente en la cual se apoyará la capa de Negocio para realizar las búsquedas. Al haberla definido ası́ de inicio, no se ha modificado por lo que queda exactamente igual.. 6.6.. DISEÑO DE BAJO NIVEL 2º FASE. En esta sección se podrán observar los cambios que se han producido a nivel de código en el programa. El diseño de Bajo Nivel ha sido creado con la herramienta ObjectAid UML Explorer para el entorno de desarrollo Eclipse (se habla a cerca de la misma en la subsección ”3.13.1 Programas Utilizados”). R.Sanz. 41.

(48)

(49) Escuela Técnica Superior de Ingenieros Informáticos. 6.7.. IMPLEMENTACIÓN 2º FASE. 6.7.1.. PROGRAMAS UTILIZADOS. Enero 2016. Para la creación de la cabecera y modificación de parte del plano de metro utilizado se ha aprendido a utilizar Adobe Photoshop CC 2017.. 6.7.2.. LIBRERÍAS UTILIZADAS. Para el desarrollo del proyecto se han utilizado especı́ficamente dos librerı́as externas de Java a parte de las que vienen por defecto:. Java Decision Diagram Libraries: Esta librerı́a se puede localizar el siguiente enlace [6]:. http://java-decision-diagram-libraries.soft112.com/ This project contains two different Binary Decision Diagrams (BDD) libraries: 1. JBDD: a Java interface to two popular BDD libraries, CUDD and BuDDy. 2. JDD: a native Java library supporting BDD, Z-BDD and more (graph/automata/Petri nets/SAT).. Net Datastructures 5: Esta librerı́a se puede localizar en el siguiente enlace [7]:. http://net3.datastructures.net/ net.datastructures is a Java package containing a collection of Java interfaces and classes that implement fundamental data structures and algorithms, such as: sequences, trees, priority queues, search trees, hash tables sorting algorithms graphs, their traversals, and applications, (e.g. shortest paths) The package was designed for educational use. It provides a set of functional components defined by simple APIs and easy to use. The code is readable, reliable, asymptotically efficient, and object-oriented. Programming can be done through interfaces only, with knowledge of specific implementations necessary only for specialized applications. net.datastructures has been developed at Brown University and at the University of California, Irvine. The work on this project was supported in part by the National Science Foundation under grants DUE-0231202 and DUE-0231467. R.Sanz. 43.

(50) Escuela Técnica Superior de Ingenieros Informáticos. 6.7.3.. Enero 2016. OTROS. ObjectAir UML Explorer Herramienta de visualización de código creada para el IDE de Eclipse. Permite ver en tiempo real el código implementado dentro de un proyecto como si fuera un diagrama UML.[8].. Latex Toda la memoria del proyecto ha sido realizada en Latex, utilizando diversas librerı́as de inserción de código para los Anexos finales. [9].. 6.7.4.. CÓDIGO. Todo el código desarrollado en el ciclo 1 se podrá ver en el Anexo B situado al final de la Memoria de Seguimiento. El lenguaje utilizado es Java, con el entorno Eclipse Jee Neon. Las librerı́as ya mencionadas en la sección anterior son las que se han utilizado para desarrollar el proyecto.. 6.8.. PLAN DE PRUEBAS. El siguiente plan se ha diseñado para poner a prueba de tres formas distintas el proyecto completo. Al revés que en el primer plan de pruebas, el numero de las mismas en este caso ha aumentado para confirmar las capacidades ya probadas y a su vez, probar las nuevas funcionalidades implementadas en la segunda fase. En las pruebas unitarias lo más importante es la comprobación del algoritmo (ver que calcula bien la ruta que se elija y que devuelve la lista de estaciones por las que pasar a modo de itinerario del camino más corto), ver que no hay fallos en general de ejecución, etc. Respecto a las pruebas de ensamblaje, lo más importante es probar los 4 puntos crı́ticos del sistema que son los puntos donde interfaz gráfica y código se unen: las pulsaciones de los botones, las selecciones de las estaciones y la devolución de la ruta en cuestión en una ventana emergente. Por último, como pruebas definitivas, se han diseñado varios casos de uso en los cuales la utilización del software será puesto a prueba, y el algoritmo tendrá que buscar rutas cada vez más complicadas. R.Sanz. 44.

(51) Escuela Técnica Superior de Ingenieros Informáticos. 6.8.1.. Enero 2016. PRUEBAS UNITARIAS. 1. Selección del camino mas corto (prueba del algoritmo): • Objetivo: Dada una estación origen y una estación destino, la aplicación deberá devolver una ruta que sea la del camino mas corto para llegar de una estación a otra • Resultado: SATISFACTORIO Como ejemplo, para la estaciones seleccionadas: La Canyada y Les Carolines, el camino devuelto es el siguiente: En consola obtenemos:. En ventana emergente (para usuario) obtenemos:. 2. Salida del programa (algoritmo) sin seleccionar estaciones. • Objetivo: Al estar implementadas interfaz y algoritmo en el mismo proyecto, asegurarse de que todas las ventanas emergentes se crean y destruyen correctamente sin que se den fallos o se lancen excepciones. • Resultado inicial: FALLO Tras la realización de varias pruebas, se ha encontrado el error de que se lanzaban excepciones cuando se entraba a la aplicación y se salı́a de la misma sin haber utilizado el algoritmo. Esto viene dado debido a que al no ejecutar el algoritmo, hay ventanas emergentes que no se crean, y cuando se pretende salir de la aplicación, se intentan cerrar ventanas que no han sido creadas.. R.Sanz. 45.

(52) Escuela Técnica Superior de Ingenieros Informáticos. • Resultado final: SATISFACTORIO. R.Sanz. 46. Enero 2016.

(53) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 3. Estabilidad de interfaz gráfica • Objetivo: Crear una interfaz gráfica confiable a nivel de código, que cumpla con sus funciones y que no de lugar a error. Qué ejecute código de forma optimizada y que elimine la inestabilidad inicial encontrada tras las pruebas de la primera fase. • Resultado inicial: FALLO : La antigua interfaz poseı́a el error explicado más adelante. Para la segunda fase se comenzó con la reestructuración a nivel de código de la interfaz, cambiándola por completo y por lo tanto eliminando el fallo. Al ejecutar en numerosas ocasiones el algoritmo, se ha detectado una inestabilidad gráfica bastante grave en las rutas que se tenı́an que representar muchas estaciones. En la ventana emergente se auto-refrescaba el contenido hasta el punto de que en alguna ocasión se ha borrado el contenido de la misma haciéndola impracticable. (NOTA: Esta prueba fue creada en inicio para la fase 1, se ha mantenido y posteriormente se añadió la 6 con la diferencia de que es por fuerza bruta y de fase 2).. • Resultado final: SATISFACTORIO. R.Sanz. 47.

(54) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 4. Estado inicial de la aplicación. • Objetivo: Que la aplicación este en un estado inicial el cual no tenga errores y permita al usuario buscar su ruta. • Resultado inicial: ***** : Inicialmente el estado de la aplicación no ha dado problemas o fallos como tal pero se ha detectado que la inclusión de las opciones iniciales Elegir estación de llegada... y Elegir estación de destino... generaban excepciones si por error el usuario pulsaba Aceptar debido a que ambos elementos se incluyen dentro de la oferta de estaciones seleccionables y obviamente no lo son por lo que no están referenciados. Esto lleva a un error inevitable por lo que se ha reestructurado esta sección del código.. • Resultado final: SATISFACTORIO. R.Sanz. 48.

(55) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 5. Forzado del algoritmo por fuerza bruta Parte I. • Objetivo: Ejecutar el algoritmo un número determinado de veces y comprobar si en alguna de ellas falla. • Resultado inicial: FALLO : La puesta a prueba del algoritmo de esta manera, ha hecho que se pueda deducir el error de final de thread al cerrar una ventana de forma abrupta que no fuera la principal. Más concretamente las ventanas de mapa y ayuda. Gracias a esto se ha podido solucionar y la aplicación termina su thread de forma correcta en todo momento ya sea por cierre abrupto de las ventanas o por uso de los botones dedicados a ello. • Resultado final: SATISFACTORIO 6. Forzado del algoritmo por fuerza bruta Parte 2. • Objetivo: Ejecutar el algoritmo un número determinado de veces, representarlo gráficamente y comprobar si en alguna de ellas falla. • Resultado inicial: FALLO : La puesta a prueba del algoritmo de esta manera, ha hecho que se pueda deducir la inestabilidad que tenı́a la representación gráfica después de la primera fase. Se tomó como un fallo aunque hubiera que arreglarlo igualmente. Gracias a esta prueba se ha decidido desechar todo el módulo de código en cuestión y rehacerlo desde cero para asegurar un buen funcionamiento del mismo. • Resultado final: SATISFACTORIO. R.Sanz. 49.

(56) Escuela Técnica Superior de Ingenieros Informáticos. 6.8.2.. Enero 2016. PRUEBAS DE ENSAMBLAJE. 1. Selección de estación origen: • Objetivo: Buscar mediante scroll vertical la estación de origen que el usuario quiera seleccionar. • Resultado: SATISFACTORIO. 2. Selección de estación destino: • Objetivo: Buscar mediante scroll vertical la estación de destino que el usuario quiera seleccionar. • Resultado: SATISFACTORIO. R.Sanz. 50.

(57) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 3. Selección de Envı́o de información: • Objetivo: Una vez superadas las dos pruebas anteriores, Pulsado de botón Aceptar. Debe devolver una ventana emergente con una lista de estaciones. • Resultado: SATISFACTORIO. R.Sanz. 51.

(58) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 4. Ensamblado de Interfaz gráfica con módulo de código: • Objetivo: Comprobar que todas las selecciones y botones realizan su función. Seleccionar estación de origen y estación destino. Una vez seleccionadas pulsar Aceptar. • Devuelve: Debe generar una ventana emergente en la cual aparecerá una lista de las estaciones en cuestión que sigue el camino calculado. • Resultado: SATISFACTORIO Ventana de usuario:. Consola de programador:. R.Sanz. 52.

(59) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 5. Rescatado de mapa zonal de Valencia: • Objetivo: Comprobar que la funcionalidad de mapa funciona correctamente. • Devuelve: Ventana emergente con el mapa zonal de Valencia. • Resultado: SATISFACTORIO. R.Sanz. 53.

(60) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 6. Rescatado del menú de ayuda: • Objetivo: Comprobar que la funcionalidad de ayuda funciona correctamente. • Devuelve: Ventana emergente con la ayuda disponible. • Resultado: SATISFACTORIO. R.Sanz. 54.

(61) Escuela Técnica Superior de Ingenieros Informáticos. 6.8.3.. Enero 2016. CASOS DE USO. En esta sección se detallan algunos casos de uso utilizados para poner a prueba la aplicación. Van de menor a mayor dificultad.. 1. De una estación a otra adyacente: Nombre Actores Función. Trayecto de estaciones adyacentes Usuario Saber cual es el itinerario más corto entre dos estaciones adyacentes Descripción El usuario puede elegir una estación origen y una estación destino que sean adyacentes. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro. Origen: Empalme (Linea 4) Destino: Palau de Congressos (Linea 4). R.Sanz. 55.


(63) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 2. De una estación a otra de la misma linea: Nombre Actores Función Descripción. Trayecto de una lı́nea sin transbordos Usuario Saber cual es el itinerario más corto entre dos estaciones de la misma linea El usuario puede elegir una estación origen y una estación destino dentro de la misma linea de metro. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro.. Origen: Empalme (Linea 4) Destino: Transits (Linea 4). R.Sanz. 57.


(65) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 3. De una estación a otra de una linea distinta con un transbordo: Nombre Actores Función Descripción. Trayecto de varias lineas con un transbordo Usuario Saber cual es el itinerario más corto entre dos estaciones de distintas lineas El usuario puede elegir una estación origen y una estación destino situadas en dos lineas distintas siempre y cuando solo haya un transbordo entre ellas. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro.. Origen: Sagunt (Linea 4) Destino: Orriols (Linea 6). R.Sanz. 59.


(67) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 4. De una estación a otra de una linea distinta con dos transbordos: Nombre Actores Función. Trayecto de una linea con dos transbordos Usuario Saber cual es el itinerario más corto entre dos estaciones de distintas lineas Descripción El usuario puede elegir una estación origen y una estación destino situadas en dos lineas distintas siempre y cuando haya dos transbordo entre ellas. El usuario puede pulsar aceptar una vez seleccionadas y recibir el itinerario de las estaciones por las que pasará el metro. Origen: Palau de Congressos (Linea 4) Destino: Mislata (Linea 3). R.Sanz. 61.


(69) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 5. Usuario quiere ver quién desarrolló el proyecto: Nombre Actores Función Descripción. Ver desarrollador Usuario Consultar quien ha desarrollado la aplicación El usuario puede consultar quien es ha desarrollado de la aplicación. Hacer click en ’Archivo’, ’A cerca de...’. R.Sanz. 63.


(71) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 6. Usuario quiere consultar el mapa Nombre Actores Función Descripción. Consultar el mapa Usuario Consultar el programa antes de consultar una ruta o después de consultarla El usuario puede consultar el mapa Zonal en el momento que deseé sin que afecte a la consulta de la ruta. Hacer click en ’Ver’, ’Mapa’ Hacer click directo en botón ’Salir’ del menú principal.. R.Sanz. 65.

(72) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 7. Usuario quiere salir del programa Nombre Actores Función Descripción. Salir del programa Usuario Salir del programa sin haber hecho una búsqueda El usuario puede salir del programa sin haber hecho una búsqueda previamente sin tener que cerrar la ventana de forma abrupta. Hacer click en ’Archivo’, ’Salir’. Hacer click directo en botón ’Salir’ del menú principal. Click directo sobre botón ’Salir’:. R.Sanz. 66.

(73) Escuela Técnica Superior de Ingenieros Informáticos. Click en ’Archivo’, ’Salir’:. R.Sanz. 67. Enero 2016.

(74) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 8. Usuario quiere consultar el menú de ayuda Nombre Actores Función Descripción. Menú de ayuda Usuario Consultar el menú de ayuda para informarse El usuario puede consultar el menú de ayuda en cualquier momento para consultar alguna duda. Hacer click directo en botón ’Ayuda’ del menú principal.. R.Sanz. 68.

(75) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 7 RESUMEN Y CONCLUSIONES. 7.1.. EVALUACIÓN FINAL. Como se comentó en la evaluación de la primera fase, en general el desarrollo del proyecto ha sido un poco complicado desde el punto de vista de tener que compaginar toda la documentación con el desarrollo del algoritmo. Aunque inicialmente con la creación del mapa conceptual de la primera fase se pudo aproximar una idea muy generalizada del objetivo de la aplicación, la necesidad de ampliar la misma en la segunda, provocó una nueva modificación del mapa para que quedase más completo y depurado. Una vez visto el nuevo objetivo que se pretendı́a conseguir para esta segunda fase, toda la atención se centró en el re-análisis de los requisitos para volver a acotar, esta vez de forma definitiva, el problema a resolver por parte del creador del proyecto. En una reunión intermedia con el tutor, se habló sobre añadir alguna funcionalidad nueva a la aplicación y a la vez depurar el código, aislar errores que aparecieron y re-implementar todo lo relativo a la devolución de la ruta (mejora de la interfaz) la cual tenı́a cierta inestabilidad. De esta forma se sacaron nuevos requisitos y por consiguiente se agrandó el proyecto en vistas a cumplir el segundo deadline con una aplicación mucho mas completa que en su versión. anterior. El Diseño de Alto Nivel, no se vio afectado en esta segunda fase puesto que la propuesta ha sido la misma, pero como es obvio, el Diseño de Bajo Nivel ha tenido que ser modificado al haberse implementado nuevos módulos de la aplicación. La inversión de tiempo ha sido mucho más pequeña que en la primera fase puesto que ya se tenı́an los conocimientos previos y no habı́a que detenerse tanto para hacerlo.. R.Sanz. 69.

(76) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Respecto al plan de pruebas, en la primera fase se diferenciaron tres tipos de pruebas: unitarias, ensamblaje y casos de uso. Para esta segunda fase, la premisa ha sido la misma con la diferencia de que se han añadido pruebas que ayudasen a encontrar fallos al sistema. Lo primero que se hizo fue pasar las pruebas que ya estaban creadas una vez se implementaron los nuevos requisitos y posteriormente se añadieron y llevaron a cabo las nuevas. De esta forma la baterı́a de pruebas quedó mucho mas completa, llegando a tomar una mayor importancia dentro del plan de pruebas los casos de uso. La implementación para la segunda fase, fue mucho menos costosa que en la primera ya que toda la sección del algoritmo estaba implementada, y las horas de desarrollo se centraron en la solución de errores, depuración, re-ordenación y re-maquetación de la aplicación. Durante la aplicación del plan de pruebas, se aislaron varios errores que fueron subsanados nada ma terminar el desarrollo por lo que el restante de horas se vio dedicado a esta actividad. Es de destacar que las horas invertidas en desarrollo tanto en la primera fase como en la segunda, fue mayor de lo esperado puesto que los conocimientos que se tenı́an antes del desarrollo del proyecto eran bastante limitados. Como ya se ha comentado, al haber terminado la implementación general del proyecto, se comenzó a aplicar el plan de pruebas de la primera fase para asegurar el funcionamiento de las funcionalidades anteriores y una vez hecho, se comenzaron a aplicar las nuevas pruebas. Varios fallos fueron localizados dentro de la aplicación (sección 4.8 de la memoria final). Algunos de ellos fueron: 1. Fallo en la primera ejecución de la aplicación: La aplicación funcionaba normalmente pero las dos primeras estaciones que estaban situadas en el array de estaciones de llegada no funcionaban. El motivo era que la selección inicial estaba vacı́a y solo se llenaba cuando se hacı́a click sobre una de las opciones del array. Se soluciono haciendo una inicialización de la selección que fuera coherente. 2. Situación inicial de la aplicación en primera fase: Cuando se ejecutaba la aplicación, en la selección de estaciones de salida habı́a una opción que era ”Seleccione estación de salida...”. Era un elemento del array que no estaba referenciado en el resto del proyecto ya que no era una estación. Esto llevo a su eliminación de la interfaz tanto en Salida como en Llegada ya que presentaban exactamente el mismo tipo de error. La localización de este fallo llevó directamente a encontrar el anteriormente mencionado. 3. Situación inicial de la aplicación en primera fase: Cuando se ejecutaba la aplicación, en la selección de estaciones de salida habı́a una opción que era ”Seleccione estación de salida...”. Era un elemento del array R.Sanz. 70.

(77) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. que no estaba referenciado en el resto del proyecto ya que no era una estación. Esto llevo a su eliminación de la interfaz. La localización de este fallo llevó directamente a encontrar el anteriormente mencionado. 4. Inestabilidad gráfica: Cuando se ejecutaba la aplicación,todo funcionaba correctamente, pero cuando se elegı́an estaciones muy distantes entre sı́, se daba un error muy grave de inestabilidad a la hora de representar las estaciones y lı́neas de la ruta. El contenido de la ventana emergente comenzaba autorefrescarse y desaparecı́a el contenido de la ruta a pesar de que el programa la tenı́a bien guardada en memoria. Se aisló el fallo y toda la sección de código fue modificada. Igualmente, uno de los requisitos establecı́a que la representación de la ruta debı́a ser mucho mas amigable e intuitiva por lo que para la versión final era algo que habı́a que cambiar obligadamente. 5. Problemas de ejecución del hilo de la aplicación: Al trabajar con tantas ventanas emergentes, el hilo de ejecución no siempre terminaba como era de esperar. En los casos en los que se salı́a de las ventanas mediante su botón correspondiente, el thread terminaba de forma correcta, pero en los casos en los que se cerraba la ventana de forma abrupta, no se trataba dicho cerrado por lo que el hilo seguı́a ejecutando. Fue un fallo bastante problemático ya que se localizó justo al final del desarrollo de esta segunda fase por lo que se tardó en localizar. Una vez localizado se fue experimentando hasta arreglarlo de la forma correcta. Como conclusión del proceso de desarrollo del proyecto al completo, se puede afirmar sin duda alguna que ha sido un éxito la implementación del algoritmo (a pesar de las dificultades tenidas al principio del mismo) y de la interfaz incluyendo sus nuevas funcionalidades.. R.Sanz. 71.

(78) Escuela Técnica Superior de Ingenieros Informáticos. 7.2.. Enero 2016. CONCLUSIONES. La realización de este proyecto sin duda alguna ha puesto a prueba mis capacidades y los conocimientos aprendidos durante la carrera. A pesar de ser un algoritmo ampliamente conocido, he podido comprobar de primera mano su funcionamiento y su efectividad en una aplicación tan necesaria como un planificador de rutas. Obviamente esta aplicación tiene un alcance muy limitado ya que la toma de datos ha sido propia y hecha a mano, pero la decisión de hacerlo ası́ ha sido necesaria para evitar problemas con datos de terceros. Si en algún momento se quisiera utilizar con información más extensa, conectándola a una base de datos ya sea en local u online, el algoritmo funcionarı́a exactamente igual por lo que las posibilidades de la aplicación como tal son muy grandes en términos de funcionalidad. Respecto a los conocimientos puestos en práctica, puedo decir que los más útiles han sido los adquiridos en Ingenierı́a del Software I y II, Inteligencia Artificial y asignaturas de programación. La gestión de un proyecto llevado completamente por mı́, ha supuesto una nueva forma de completar el aprendizaje que se inició en las dos primeras asignaturas que he mencionado. La forma en la que gestionar el proyecto fue definida por mi tutor, pero realmente me ha dado muchas libertades para que yo eligiera de qué forma hacerlo siempre y cuando los motivos por los que escogiera mis elecciones fueran coherentes con el proyecto. A parte de todo lo mencionado, tengo que decir que estoy bastante contento con el trabajo que he desarrollado puesto que considero que entre otras cosas el manejo de interfaces gráficas me vendrá bien de cara al futuro a corto o medio plazo (el mercado actual del desarrollo de aplicaciones sin duda esta al alza) y a su vez, completa en cierto grado mi formación como programador puesto que en mi caso no es algo que haya visto de forma concisa en ninguna asignatura por lo que es más que bienvenido.. R.Sanz. 72.

(79) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. Capı́tulo 8 CITAS Y BIBLIOGRAFÍA [1] IEEE-STD-830-1998 : Software requirements specification.. [2] Blog, Datos en abierto (Wordpress), https://datosenabierto.wordpress.com/2011/08/14/implementacion-algoritmo-a-estrella-definicion/ ,2011 [3] Centro de Inteligencia Artificial, Universidad de Oviedo, http://www.aic.uniovi.es/ssii/ssii-t3-busquedaii.pdf [4] Algoritmo a Estrella, Wikipedia, https://es.wikipedia.org, búsqueda: Algoritmo a Estrella [5] Consultorı́a de Diseños y Usabilidad,Usolab, http://www.usolab.com/wl/2009/07/la-regla-de-3-clics.php [6] Java Decision Diagram Libraries,soft112, http://java-decision-diagram-libraries.soft112.com/ [7] net.datastructures, http://net3.datastructures.net/ [8] The ObjectAid UML Explorer for Eclipse, http://www.objectaid.com/ [9] Latex-project, https://www.latex-project.org/. R.Sanz. 73.

(80) Escuela Técnica Superior de Ingenieros Informáticos. Capı́tulo 9 ANEXO A: CÓDIGO DESARROLLADO 1º FASE. 9.1.. Package Arbol. 9.1.1.. Arbol.java. 1. package Arbol;. 2. import java.io.IOException;. 3. import java.util.ArrayList;. 4. import java.util.Iterator;. 5. import java.util.List;. 6. import java.util.Map;. 7. import jdd.graph.Edge;. 8. import Grafo.*;. R.Sanz. 74. Enero 2016.

(81) Escuela Técnica Superior de Ingenieros Informáticos. 9. public class Arbol. Enero 2016. {. 10. Nodo salida;. 11. Nodo llegada;. 12. Grafo grafo;. 13. Map<String, List<Edge>> tabla;. 14. LTree<Elemento> arbol = new LTree<Elemento>();. 15. List<LTreeNode<Elemento>> posibles = new ArrayList<LTreeNode< Elemento>>();. 16. public Arbol(Nodo salida,Nodo llegada,Grafo grafo){. 17. this.salida = salida;. 18. this.llegada = llegada;. 19. this.grafo = grafo;. 20. this.arbol.addRoot(new Elemento(0,salida.distancia(llegada), salida));. 21. this.arbol.root.element().setrecorrido(salida.distancia(llegada) );. 22. this.arbol.root.setChild(grafo.getChild(this.arbol.root, llegada ));. 23. addList(posibles,this.arbol.root.getChild());. 24. }. 25. private void addList(List<LTreeNode<Elemento>> lis,. 26. List<LTreeNode<Elemento>> hijos){. 27. Iterator<LTreeNode<Elemento>> it = hijos.iterator();. R.Sanz. 75.

(82) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 28. while(it.hasNext()){. 29. lis.add(it.next());. 30. }. 31. }. 32. public LTreeNode<Elemento> CalcularRecorrido(){. 33. LTreeNode<Elemento> nodo = this.arbol.root;. 34. if (salida.getNombre()!=llegada.getNombre()){. 35. nodo = selectChild(nodo);. 36. while(!isEnd(nodo)){. 37. nodo = selectChild(nodo);. 38. }. 39. }. 40. return nodo;. 41. }. 42. public LTreeNode<Elemento> selectChild(LTreeNode<Elemento>padre) {. 43. LTreeNode<Elemento> nodo = new LTreeNode<Elemento>(null,null, null);. 44. LTreeNode<Elemento> nod = new LTreeNode<Elemento>(null,null,null );. 45. Iterator<LTreeNode<Elemento>> iterador = posibles.iterator();. 46. int gh = 0;. 47. nod = iterador.next();. R.Sanz. 76.

(83) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 48. gh = gh(nod);. 49. nodo=nod;. 50. int i = 0;. 51. int j = 0;. 52. while(iterador.hasNext()){. 53. nod = iterador.next();. 54. i++;. 55. if (gh>gh(nod) &&. 56. (nod.element().getnodo().getNombre()!=. 57. padre.element().getnodo().getNombre())){. 58. gh = gh(nod);. 59. nodo=nod;. 60. j = i;. 61. }. 62. }. 63. System.out.println(nodo.element().getnodo().getNombre());. 64. nodo.element().setrecorrido(gh);. 65. i=0;. 66. posibles.remove(j);. 67. iterador = posibles.iterator();. 68. List<Integer> borrar =new ArrayList<Integer>();. 69. while(iterador.hasNext()){. 70. if(iterador.next().element().getnodo().getNombre()==. R.Sanz. 77.

(84) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 71. nodo.element().getnodo().getNombre()). 72. borrar.add(i);. 73. i++;. 74. }. 75. Iterator <Integer >iterad = borrar.iterator();. 76. while(iterad.hasNext()){. 77. posibles.remove(iterad.next());. 78. }. 79. if (nodo.getChild() == null){. 80. nodo.setChild(grafo.getChild(nodo, llegada));. 81. addList(posibles,nodo.getChild());. 82. }. 83. return nodo;. 84. }. 85. public int gh (LTreeNode<Elemento> nodo){. 86. return nodo.getParent().element().recorridoParcial() +. 87. nodo.element().recorridoMax();. 88. }. 89. public boolean isEnd(LTreeNode<Elemento>fin){. 90. return (fin.element().getnodo().getNombre() == llegada.getNombre ());. 91. }. 92. public List<Nodo> recorridoObtimo(LTreeNode<Elemento> fin){. R.Sanz. 78.

(85) Escuela Técnica Superior de Ingenieros Informáticos. 93. List<Nodo> recorrido = new ArrayList<Nodo>();. 94. LTreeNode<Elemento> posicion = fin;. 95. boolean condicion = true;. 96. while(condicion){. 97. if (posicion.getParent()==null){. 98. recorrido.add(((Elemento)posicion.element()).getnodo());. 99. condicion = false;. 100. }. 101. else{. 102. recorrido.add(((Elemento)posicion.element()).getnodo());. 103. posicion = posicion.getParent();. 104. }. 105. }. 106. return recorrido;. 107. }. 108. }. R.Sanz. 79. Enero 2016.

(86) Escuela Técnica Superior de Ingenieros Informáticos. 9.1.2.. Elemento.java. 1. package Arbol;. 2. import Grafo.Nodo;. 3. public class Elemento {. 4. private double g;. 5. private int h,recorrido;. 6. private Nodo nodo;. 7. public Elemento(double g, int h, Nodo nodo){. 8. this.g = g;. 9. this.h = h;. 10. this.nodo = nodo;. 11. }. 12. public double getG(){. 13. return this.g;. 14. }. 15. public void setG(int g){. 16. this.g = g;. 17. }. 18. public int getH(){. 19. return this.h;. 20. }. 21. public void setH(int h){. 22. if(h>=0). R.Sanz. 80. Enero 2016.

(87) Escuela Técnica Superior de Ingenieros Informáticos. 23. this.h = h;. 24. else. 25. this.h = -h;. 26. }. 27. public Nodo getnodo(){. 28. return this.nodo;. 29. }. 30. public void setnodo(Nodo nodo){. 31. this.nodo = nodo;. 32. }. 33. public int getrecorrido(){. 34. return this.recorrido;. 35. }. 36. public void setrecorrido(int recorrido){. 37. this.recorrido = recorrido;. 38. }. 39. public int recorridoParcial(){. 40. return this.recorrido-this.h;. 41. }. 42. public int recorridoMax(){. 43. return (int)this.g+this.h;. 44. }. 45. }. R.Sanz. 81. Enero 2016.

(88) Escuela Técnica Superior de Ingenieros Informáticos. 9.1.3.. LTree.java. 1. package Arbol;. 2. import net.datastructures.*;. 3. import java.util.*;. 4. public class LTree<E> implements Tree<E> {. 5. protected LTreeNode<E> root=null;. 6. public int size() {. 7. int numPos=0;. 8. for (Position<E> p: positions()) ++numPos;. 9. return numPos;. 10. }. 11. public boolean isEmpty() {. 12. return (root==null);. 13. }. 14. public Iterator<E> iterator() {. 15. List<E> list = new LinkedList<E>();. 16. for (Position<E> p: positions()) list.add(p.element());. 17. return list.listIterator();. 18. }. 19. public Iterable<Position<E>> positions() {. 20. return nodeList(root);. 21. }. 22. public E replace(Position<E> v, E e) {. R.Sanz. 82. Enero 2016.

(89) Escuela Técnica Superior de Ingenieros Informáticos. Enero 2016. 23. LTreeNode<E> node = getLTreeNode(v);. 24. E tmp = node.element();. 25. node.setElement(e);. 26. return tmp;. 27. }. 28. public Position<E> root() throws EmptyTreeException {. 29. if (isEmpty()) throw new EmptyTreeException("Tree is empty");. 30. return root;. 31. }. 32. public Position<E> parent(Position<E> v) throws InvalidPositionException,. 33. BoundaryViolationException {. 34. if (isRoot(v)) throw new BoundaryViolationException("At root node");. 35. LTreeNode<E> node = getLTreeNode(v);. 36. return node.getParent();. 37. }. 38. public Iterable<Position<E>> children(Position<E> v) throws. 39. InvalidPositionException {. 40. return childrenList(v);. 41. }. 42. public boolean isInternal(Position<E> v) throws InvalidPositionException {. R.Sanz. 83.

(90) Escuela Técnica Superior de Ingenieros Informáticos. 43. return !isExternal(v);. 44. }. 45. public boolean isExternal(Position<E> v) throws. Enero 2016. InvalidPositionException { 46. LTreeNode<E> node = getLTreeNode(v);. 47. return false;. 48. }. 49. public boolean isRoot(Position<E> v) throws InvalidPositionException {. 50. LTreeNode<E> node = getLTreeNode(v);. 51. return node==root();. 52. }. 53. public Position<E> addRoot(E e) throws NonEmptyTreeException {. 54. if (root != null) {. 55. throw new NonEmptyTreeException("adding new root to nonempty tree");. 56. }. 57. root = new LTreeNode<E>(e,null,null);. 58. return root;. 59. }. 60. public Position<E> addChild(E e,Position<E> v). 61. throws InvalidPositionException {. 62. LTreeNode<E> node = getLTreeNode(v);. R.Sanz. 84.