Análisis, diseño e implementación de un software que determine la planificación de carga de un Contenedor

Texto completo

(1)Universidad Nacional de San Agustı́n Facultad de Ingenierı́a de Producción y Servicios Escuela Profesional de Ingenierı́a de Sistemas. Análisis, diseño e implementación de un software que determine la planificación de carga de un contenedor Tesis presentada por el bachiller:. Abraham Max Santos Ramos para optar el Tı́tulo Profesional de:. Ingeniero de Sistemas. Arequipa - Perú 2017.

(2) 2.

(3) Resumen. La planificación de carga es una tarea importante en la logı́stica de las empresas o instituciones. Usualmente en este problema se tiene contenedores con forma de paralelepı́pedo y la carga dispuesta en cajas y lo que se desea es encontrar una forma de colocar las cajas apiladas en e contenedor de manera que se aproveche al máximo el espacio en del mismo. En esta tesis se propone implementar un softwarede código abierto para la planificación de carga de un contenedor que tiene como parámetros las dimensiones (largo, ancho y alto) del contenedor y las dimensiones de cada una de las cajas, y que produce como resultado la posición de cada una de las cajas ası́ como su orientación y el orden de su colocación dentro del contenedor. Para la implementación del software se ha hecho uso de un algoritmo de planificación de crga propuesto por el profesor David Pisinger en 1999 disponible en internet. Se mencionan asimismo, en el estado del arte los problemas derivados del problema de planificación de carga y algunos de los algoritmos existentes. Este software propuesto permitirá optimizar el uso del espacio y ası́ reducir costos en la logı́stica del transporte y/o almacenamiento de carga. Palabras clave: planificación de carga, algoritmos de optimización, heurı́sticas..

(4) Abstract. Load planning is an important task for logistics companies or institutions. Usually, in this problem we have a parallelepiped container and cargo arranged in boxes and what is wanted is to find a way to place the boxes stacked into the container in order to use most of the space available. In this thesis it is proposed an open source software for the load planning of a container which has as parameters the dimensions (length, width and height) of the container and the dimensions of each of the boxes, and outputs as result the position of each one of the boxes and their orientations and placement within the container. To implement this software, it has been made use of a load planning algorithm proposed by Professor David Pisinger in 1999. It was also mentioned in the state of art the problem arising from the container loading problem and some existing algorithms. This proposed software can serve to optimize the use of space and to reduce costs in transport and storage of cargo. Keywords: load planning, optimization algorithms, heuristics..

(5) Índice general. 1. Introducción y Antecedentes. 7. 1.1. Definición del problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 7. 1.2. Marco conceptual del problema . . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.2.1. El problema de la mochila . . . . . . . . . . . . . . . . . . . . . . .. 8. 1.2.2. El problema de la planificación de carga de un contenedor . . . . .. 10. 1.3. Estado del arte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 13. 1.3.1. Algoritmo de Pisinger . . . . . . . . . . . . . . . . . . . . . . . . .. 14. 1.3.2. Algoritmo de Gehring y Bortfeldt . . . . . . . . . . . . . . . . . . .. 19. 1.4. Aplicaciones similares existentes . . . . . . . . . . . . . . . . . . . . . . . .. 22. 1.4.1. EasyCargo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 1.4.2. CargoWiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 1.4.3. CubeMaster . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 1.4.4. packVol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 1.4.5. LoadPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 27. 1.

(6) 1.4.6. Análisis comparativo entre aplicaciones . . . . . . . . . . . . . . . .. 28. 1.5. Descripción y sustentación de la solución . . . . . . . . . . . . . . . . . . .. 31. 1.5.1. Objetivo general . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 31. 1.5.2. Objetivos especı́ficos . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 1.5.3. Resultados esperados . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 2. Análisis. 33. 2.1. Metodologı́a . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 2.1.1. Concepción . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 2.1.2. Elaboración . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 2.1.3. Implementación . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 2.2. Requerimientos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 2.2.1. Requerimientos funcionales . . . . . . . . . . . . . . . . . . . . . . .. 36. 2.2.2. Requerimientos no funcionales . . . . . . . . . . . . . . . . . . . . .. 37. 2.2.3. Restricciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 2.3. Análisis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 2.3.1. Modelo de casos de uso . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 2.3.2. Caracterı́sticas de los usuarios . . . . . . . . . . . . . . . . . . . . .. 43. 2.3.3. Diagrama de clases de análisis . . . . . . . . . . . . . . . . . . . . .. 43. 3. Diseño. 45 2.

(7) 3.1. Arquitectura de la solución . . . . . . . . . . . . . . . . . . . . . . . . . . .. 45. 3.1.1. Representación de la arquitectura . . . . . . . . . . . . . . . . . . .. 45. 3.1.2. Escenarios o casos de uso . . . . . . . . . . . . . . . . . . . . . . . .. 47. 3.1.3. Vista de procesos . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. 3.1.4. Vista lógica . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 49. 3.1.5. Vista de despliegue . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54. 3.1.6. Vista de desarrollo . . . . . . . . . . . . . . . . . . . . . . . . . . .. 55. 3.2. Diseño de la interfaz gráfica . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 3.2.1. Pantalla principal . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 57. 3.3. Arquitectura de la información . . . . . . . . . . . . . . . . . . . . . . . . .. 60. 3.3.1. Flujo de información del software . . . . . . . . . . . . . . . . . . .. 61. 3.3.2. Persistencia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 61. 4. Implementación. 65. 4.1. Aspectos de la implementación . . . . . . . . . . . . . . . . . . . . . . . . .. 65. 4.1.1. Tecnologı́as utilizadas . . . . . . . . . . . . . . . . . . . . . . . . . .. 65. 4.1.2. Frameworks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 66. 4.2. Implementación del algoritmo de planificación de carga . . . . . . . . . . .. 67. 4.2.1. Función principal . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 67. 4.2.2. Encapsulamiento del algoritmo . . . . . . . . . . . . . . . . . . . .. 68. 3.

(8) 4.2.3. Algoritmo de ordenación para la colocación de las cajas . . . . . . .. 69. 4.2.4. Implementación de la visualización en 3D . . . . . . . . . . . . . . .. 70. 4.3. Pruebas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 70. 4.3.1. Pruebas funcionales . . . . . . . . . . . . . . . . . . . . . . . . . . .. 71. 4.3.2. Prueba del algoritmo . . . . . . . . . . . . . . . . . . . . . . . . . .. 73. 4.4. Observaciones . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 74. 4.

(9) Índice de figuras 1.1. Ejemplo de vehı́culo utilizado en el transporte de carga . . . . . . . . . . .. 8. 1.2. El algoritmo de Pisinger llena capas a lo largo del contenedor. . . . . . . .. 14. 1.3. Plan de colocación con cuatro capas. . . . . . . . . . . . . . . . . . . . . .. 20. 1.4. Interfaz de EasyCargo . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 1.5. Interfaz de CargoWiz . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 24. 1.6. Interfaz de CubeMaster Online . . . . . . . . . . . . . . . . . . . . . . . .. 25. 1.7. Interfaz de packVol. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 1.8. Interfaz de LoadPlanner . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 28. 2.1. Diagrama de actores. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 2.2. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 2.3. Diagrama de clases de análisis. . . . . . . . . . . . . . . . . . . . . . . . . .. 44. 3.1. Diagrama de flujo de datos de la aplicación . . . . . . . . . . . . . . . . . .. 46. 3.2. Diagrama de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. 5.

(10) 3.3. Diagrama de actividades de la aplicación. . . . . . . . . . . . . . . . . . . .. 49. 3.4. Diagrama de clases de la aplicación. . . . . . . . . . . . . . . . . . . . . . .. 50. 3.5. Diagrama de secuencia para el proceso Resolver Problema. . . . . . . . . .. 54. 3.6. Diagrama de despliegue de la aplicación. . . . . . . . . . . . . . . . . . . .. 55. 3.7. Diagrama de componentes de la aplicación . . . . . . . . . . . . . . . . . .. 55. 3.8. Diagrama de paquetes de la aplicación . . . . . . . . . . . . . . . . . . . .. 57. 3.9. Barra de herramientas de la aplicación . . . . . . . . . . . . . . . . . . . .. 58. 3.10. Interfaz mostrando los datos del problema. . . . . . . . . . . . . . . . . . .. 59. 3.11. Interfaz mostrando datos de la solución. . . . . . . . . . . . . . . . . . . .. 60. 3.12. Visualización del contenedor de carga con las cajas en su interior. . . . . .. 61. 3.13. Flujo de la información del software. . . . . . . . . . . . . . . . . . . . . .. 62. 3.14. Ejemplo de archivo XML para almacenar los datos de un problema de planificación de carga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. 3.15. Ejemplo de archivo XML para almacenar los resultados de un problema de planificación de carga. . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 64. 4.1. Prueba para el caso de uso Añadir grupo (datos ingresados). . . . . . . . .. 71. 4.2. Problema generado por la aplicación. . . . . . . . . . . . . . . . . . . . . .. 72. 4.3. Datos guardados por el software de un problema de planificación de carga.. 73. 4.4. Datos guardados de la solución . . . . . . . . . . . . . . . . . . . . . . . .. 74. 4.5. Visualización de un problema resuelto . . . . . . . . . . . . . . . . . . . . .. 75. 6.

(11) Capı́tulo 1 Introducción y Antecedentes En este capı́tulo se detallará el problema que se desea resolver: la planificación de carga del contenedor. Se realizará la definición del problema en su contexto y seguidamente se desarrollará toda el marco teórico respectivo al problema en cuestión. Este capı́tulo está organizado de la siguiente manera: En la primera sección, describimos la definición del problema dentro de la industria. La segunda sección contiene el marco conceptual del problema, en el cual la teorı́a referente al problema de la mochila y la del problema del contenedor son tratadas. En la cuarta sección tenemos el estado del arte del problema del contenedor. En la quinta sección mostramos el plan de del proyecto de tesis. Por último, en la sexta sección definimos la descripción y sustentación de la solución propuesta, en la que detallamos los objetivos, resultados esperados, sustentación de la solución y el alcance.. 1.1.. Definición del problema. El transporte de carga es una actividad común en la logı́stica de las empresas. Para este fin, se utilizan vehı́culos con contenedores de carga en forma de paralelepı́pedo como el mostrado en la figura 1.1. En estos contenedores se colocan cajas de diferentes productos y lo que se desea es acomodarlos de manera que se maximice la cantidad de carga en el 7.

(12) contenedor y, ası́, minimizar la cantidad de contenedores necesarios para transportar los cajas. Este problema puede ser abordado de manera empı́rica acomodando las cajas a cualquier criterio, sin embargo, posiblemente no se haya aprovechado de manera eficiente el espacio disponible en el contenedor. Es por ello que se han propuesto diversos algoritmos para resolver el problema del contenedor. Esta tesis propone la utilización de un sistema de información para automatizar la planificación de carga de un contenedor.. Figura 1.1: Ejemplo de vehı́culo utilizado en el transporte de carga Fuente: Gepsa Agencia de Aduanas [Gep15]. 1.2.. Marco conceptual del problema. Mencionaremos a continuación los conceptos mas importantes y relevante para el estudio del problema de planificación de carga del contenedor. El problema del contenedor es un caso derivado del problema de la mochila. Es por ello que en esta sección incluiremos la definición del problema de la mochila y sus variantes. Ası́ como también algunos algoritmos para resolverlos.. 1.2.1.. El problema de la mochila. El problema de la mochila está clasificado dentro del conjunto de problemas de optimización combinatoria. Esto es, busca la mejor solución dentro de un conjunto de soluciones a un. 8.

(13) problema. Una definición del problema de la mochila es la siguiente [MT90]: Dada una mochila con una capacidad determinada y un conjunto de objetos cada uno con un peso y un valor especı́ficos, se desea seleccionar un subconjunto de los objetos tal que la suma de su valor sea el máximo siempre que no se exceda la capacidad de la mochila. Esta definición la podemos modelar matemáticamente. Primeramente, tenemos una mochila con una capacidad c y un conjunto de objetos en donde cada objeto tiene un peso wj y un valor pj . Entonces, el problema se trata de. maximizar. n X. p j xj. j=1. sujeto a. n X. wj xj ≤ c,. j=1. xj = 0 o 1, j = 1, ..., n. Este problema en particular se conoce como problema de la mochila 0-1.. Complejidad computacional El problema de la mochila y los problemas derivados pertenecen a la clase de complejidad NP-hard, esto es, no se conoce un algoritmo de clase polinómica que los resuelva. Para una demostración de esta propiedad véase [MT90]. No obstante, se han desarrollado algoritmos de ramificación y poda que lo resuelven y de pseudo programación dinámica eficientemente.. Algoritmo de programación dinámica Si bien se ha dicho que el problema de la mochila pertenece a la clase de complejidad NPhard, se conoce un algoritmo para resolverlo en tiempo O(nW ) donde n es el número de. 9.

(14) elementos disponibles a colocar en la mochila y W es el valor numérico de la capacidad de la mochila. Esto no entra en contradicción con el hecho de que el problema esta clasificado en la clase de complejidad NP-hard ya que W , a diferencia de n no es polinomial en la longitud de entrada del problema. La longitud del valor de entrada W es proporcional al número de bits en W , osea log W , no W en sı́ mismo. Ahora explicaremos el algoritmo de programación dinámica. Sean w1 , w2 , ..., wn , W (enteros estrictamente positivos). Sea el subproblema m[i, w] definido como el valor máximo que puede ser obtenido con peso menor o igual que w usando los primeros i objetos. Podemos definir este problema recursivamente como sigue: m[0, w] = 0 m[i, w] = m[i − 1, w] si wi > w m[i, w] = máx(m[i − 1, w], m[i − 1, w − wi ] + vi ) si wi ≤ w. La primera definición nos indica que el valor máximo menor o igual a 0 usando cualesquiera de los objetos siempre será cero. La segunda definición indica que el valor máximo que se puede obtener es el valor máximo con i − 1 objetos si es que el peso del objeto wi es mayor que w puesto que ese objeto no puede ser colocado ya que sobrepasarı́a el lı́mite. Para el tercer caso, tenemos que escoger entre el valor máximo si no seleccionamos el objeto (el valor de m[i−1, w]) o si lo hemos seleccionado y hemos tomado la solución de m[i−1, w−wi ] agregándole el valor vi . La solución puede ser encontrada en el valor de m[n, W ]. Para encontrarla eficientemente podemos hacer uso de una tabla de valores precalculados. El pseudocódigo del programa dinámico es el que se puede ver en el algoritmo 1.. 1.2.2.. El problema de la planificación de carga de un contenedor. El problema de la planificación de carga de un contenedor [BW12] consiste en la asignación de pequeñas cajas tridimensionales a unas cajas grandes con forma de paralelepı́pedo que pueden ser un contenedor real, el espacio de carga de un camión o un palé. Esto se debe 10.

(15) Algoritmo 1 Programa para el problema de la mochila 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15:. procedure Mochila(v, w, W ) for j ← 0, W do m[0, j] ← 0 end for for i ← 1, n do for j ← 0, W do if w[i − 1] ≤ j then m[i, j] ← máx(m[i − 1, j], m[i − 1, j − w[i − 1]] + v[i − 1]) else m[i, j] ← m[i − 1, j] end if end for end for return m[n, W ] end procedure. hacer de tal modo que una función objetivo sea optimizada y se mantengan dos condiciones básicas de factibilidad: Todas las cajas deben estar completamente dentro del contenedor. Las cajas no deben sobreponerse. Se han establecido [WHS07] dos categorı́as de clasificación de los problemas de carga del contenedor: En el primer caso se considera los problemas en los cuales se tienen suficientes contenedores y lo que se desea es minimizar el número de contenedores utilizados. Este caso se denomina minimización del valor de entrada. En el segundo caso solo un subconjunto de los objetos pueden ser empacados ya que no se disponen de suficientes contenedores y lo que se desea es empacar el máximo valor posible siendo que a cada objeto tiene un valor asociado. Este caso se denomina maximización del valor de salida. Los problemas de minimización del valor de entrada son los siguientes: Single Stock Cutting Stock Problem Consiste en empacar una carga de objetos de dimensiones débilmente heterogénea en un número mı́nimo de contenedores idénticos. 11.

(16) Multiple Stock-Size Cutting Stock Problem Consiste en empacar una carga de objetos de dimensiones débilmente heterogénea en un conjunto de contenedores de dimensiones débilmente heterogéneo tal que el valor de los contenedores utilizados sea minimizado. Residual Cutting Stock Problem Consiste en empacar una carga de objetos débilmente heterogénea a un conjunto fuertemente heterogéneo de contenedores de modo que el valor de los contenedores usados sea minimizado. Single Bin-Size Bin Packing Problem Consiste en empacar una carga de objetos fuertemente heterogénea en un mı́nimo número de contenedores idénticos. Multiple Bin-Size Bin Packing Problem Consiste en empacar una carga de objetos fuertemente heterogénea en un conjunto de contenedores débilmente heterogéneo de tal modo que el valor de los contenedores utilizados es minimizado. Residual Bin Packing Problem Consiste en empacar una carga fuertemente heterogénea en un conjunto de contenedores fuertemente heterogéneo de tal modo que el valor de los contenedores usados sea minimizado. Open Dimension Problem Consiste en empacar una carga en un único contenedor con una o más dimensiones variables de tal modo que el volumen del contenedor sea minimizado.. Los problemas de maximización del valor de salida son los siguientes:. Identical Item Packing Problem Consiste en cargar un único contenedor con el máximo número de objetos pequeños e idénticos. Single Large Object Placement Problem Consiste en cargar un único contenedor con con una selección de un conjunto de carga débilmente heterogéneo de tal modo que el valor de los objetos seleccionados sea el máximo. Multiple Identical Large Object Placement Problem Consiste en cargar un conjunto de contenedores idénticos con una selección de objetos débilmente heterogénea de tal modo que el valor de los objetos seleccionados sea maximizado.. 12.

(17) Multiple Heterogeneous Large Object Placement Problem Consiste en cargar un conjunto heterogéneo de contenedores con una selección de un conjunto débilmente heterogéneo de carga de tal modo que el valor de los objetos seleccionados sea maximizado. Single Knapsack Problem Cargar un único contenedor con una selección de un conjunto heterogéneo de carga de tal modo que el valor de los objetos seleccionados sea maximizado. Multiple Identical Knapsack Problem Consiste en cargar un conjunto de contenedores idénticos con una selección de una carga fuertemente heterogénea de tal modo que el valor de los objetos seleccionados sea maximizado. Multiple Heterogeneous Knapsack Problem Consiste en cargar un conjunto heterogéneo de contenedores con una selección de una carga fuertemente heterogénea de tal modo que el valor de los objetos seleccionados sea maximizada.. El software que se pretende desarrollar deberá estar basado en el Single Knapsack Problem. Es decir que la entrada de datos consistirá en las dimensiones de un único contenedor junto con las dimensiones de las cajas a ser colocadas en su interior.. 1.3.. Estado del arte. En el estado del arte se han seleccionado los artı́culos de investigación mas recientes relacionados al Single Knapsack Problem puesto que se desarrollará un sistema de planificación de carga que resuelva uno de los problemas mencionados en este trabajo. En esta sección se detallarán algunos de los algoritmos existentes para resolver el problema del contenedor y seguidamente mencionaremos las aplicaciones de software desarrolladas que se utilizan para resolver el problema del contenedor.. 13.

(18) Capa de dimensiones (W × H × d). d. Alto (H). Largo (D). Ancho (W ) Figura 1.2: El algoritmo de Pisinger llena capas a lo largo del contenedor. Fuente: Elaboración propia.. 1.3.1.. Algoritmo de Pisinger. El algoritmo de Pisinger [Pis99] aborda el problema mediante la descomposición del contenedor en capas, y éstas, a su vez, en tiras tal como se ve en la figura 1.2. Para determinar el largo de las capas y el ancho de las tiras se hace uso de un algoritmo de árbol de búsqueda que explora las diferentes longitudes de capas y anchos de tiras. Teniendo en cuenta la complejidad del árbol de búsqueda, sólo un número fijo de subnodos son considerados para cada nodo de ramificación. De este modo, en cada nodo se considera M1 medidas de profundidad de capa seleccionadas de acuerdo a una regla de clasificación. Cada capa es llenada con un número de tiras que pueden estar orientadas horizontalmente o verticalmente. Solamente un número fijo M2 de anchos de tira son consideradas. La tira puede ser llenada resolviendo un problema de la mochila unidimensional. Para un subconjunto de cajas N 0 , una profundidad de contenedor residual d y un volumen empacado previo V , el procedimiento recursivo choose depth selecciona M1 profundidades de capa diferentes de acuerdo a la regla de clasificación a ser descrita mas adelante. Para cada profundidad d0 , se intenta emparejar las cajas de dos en dos para obtener dimensiones 14.

(19) uniformes. Este procedimiento será descrito más adelante. La capa de dimensiones W ×H × d0 es llenada usando el procedimiento fill layer. Las cajas elegidas L para la capa actual son removidas del problema, y choose depth es llamada recursivamente. El algoritmo hace backtracking cuando no hay mas espacio para una capa. El procedimiento hace uso de dos variables globales X ∗ la cual es la mejor solución actualmente (osea un conjunto de cajas y sus posiciones), y V ∗ la cual es el volumen correspondiente. Inicialmente, V ∗ debe ser asignado el valor de 0 antes de llamar a choose depth(D, 0, N ). Una vez concluido, X ∗ es la solución heurı́stica y V ∗ es su volumen. Algoritmo 2 Procedimiento recursivo para elegir las profundidades de las capas 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16:. procedure choose depth(d, V, N 0 ) if V > V ∗ then Guardar solución en X ∗ V∗ ←V end if if d < mı́nj∈N 0 mı́n wj , hj , dj then return end if seleccionar las mejores M1 profundidades de capa {d01 , d02 , ..., d0M1 } for each depth d0 ∈ {d01 , d02 , ..., d0M1 } do Emparejar las cajas para obtener una profundidad cerca a d0 U∗ ← 0 call fill layer(W , H, d0 , 0, N ); Sea L las cajas elegidas, y U ∗ su volumen call choose depth(d − d0 , V + U ∗ , N \ L); end for end procedure. El procedimiento recursivo fill layer llena una capa de dimensiones w × h × d0 con un subconjunto de los objetos de N 00 . El volumen de las cajas que ya han sido colocadas en esta capa es dado por el parámetro U . La capa es llenada con un número de tiras las cuales pueden ser verticales u horizontales. Antes de llenar una tira, un preprocesamiento de los objetos de N 00 es hecho, tal que ellos son rotados para ocupar la menor altura posible (o anchura). Este procedimiento es descrito más adelante. El procedimiento hace uso de las variables globales L y U ∗ , manteniendo el mejor llenado actual de la capa y del valor objetivo correspondiente. Despues de haber buscado cada una de las profundidades de capa d01 , . . . , d0M1 , escogemos aquella que haya sido llenada con mayor eficiencia: la que tenga entre todas el mejor uso 15.

(20) Algoritmo 3 Procedimiento para llenar una capa del contenedor 1: 2: 3: 4: 5: 6: 7: 8: 9: 10: 11: 12: 13: 14: 15: 16: 17: 18: 19: 20: 21: 22: 23:. procedure fill layer(w, h, d0 , U, N 00 ) if U > U ∗ then Guardar solución en L U∗ ← U end if l ← mı́njinN 00 mı́n{wj , hj , dj }; if w < l ó h < l then return end if if d < mı́nj∈N 0 mı́n wj , hj , dj then return end if . Llenar tira vertical 0 Seleccionar M2 anchos mejor clasificados {w10 , w20 , . . . , wM }. 2 0 for each ancho w0 ∈ {w10 , w20 , . . . , wM } do 2 Rotar las cajas y resolver un KP con capacidad h. Sea K el conjunto de las cajas elegidas. P call fill layer(w − w0 , h, U + j∈K vj , N 00 \K); end for . Llenar la tira horizontal 0 0 0 Seleccionar M2 alturas mejor clasificadas {h1 , h2 , . . . , hM2 }. for each altura h0 ∈ {h01 , h02 , . . . , h0M2 } do Rotar las cajas y resolver un KP con capacidad w. Sea K el conjunto de las cajas elegidas. P call fill layer(w, h − h0 , h, U + j∈K vj , N 00 \K); end for end procedure. de volumen. Para cada una de las tiras que necesita ser llenada se aplica el problema de la mochila unidimensional, el cual se puede resolver utilizando el algoritmo de programación dinámica que se ha mostrado en la sección anterior. Para seleccionar la longitud de las capas se ha de tomar como base alguna de las dimensiones de las cajas (no se hará de manera arbitraria). Primeramente, se aplica una regla de clasificación para las cajas disponibles: se elige la caja l que tenga el mayor tamaño de su menor dimensión (el razonamiento es que tal caja será difı́cil de acomodar después en la planificación de carga). Esta caja es rotada tal que su largo sea el máximo sin sobrepasar un parámetro dado k. El largo de la capa es asignado el valor de dl de la caja elegida.. 16.

(21) Ranking de anchos y bajos En cada nodo de ramificación consideramos las M1 mejores profundidades de una capa, o los mejores altos/anchos de una tira. Los experimentos computacionales realizados por Pisinger mostraron que el rendimiento del algoritmo dependı́a estrictamente del ranking de esas dimensiones. Los experimentos computacionales llevados a cabo por Pisinger mostraron que los mejores resultados obtenidos fueron con la función objetivo: Dimensión mas larga con frecuencia incrementada. Osea, las dimensiones mas largas son seleccionadas, tal que cada dimensión elegida tiene una alta frecuencia que otra larga dimensión. De esta forma, sea fk la frecuencia de la dimensión k, osea el número de cajas j ∈ N 0 con wj , hj o dj igual a k. Las M1 profundidades son elegidas como sigue: Inicialmente asignar d01 = máx{k : fk > 0}. Los valores subsecuentes son encontrados como d0i = máx{k : fk > fd0i−1 } para i = 2, . . . , M1 . Los M2 anchos/alturas son elegidas al asignar 0 wi0 = arg máx{fk : k 6= w10 , . . . , wi−1 } para i = 1, . . . , M2 .. Llenado de las tiras Las tiras pueden ser llenadas horizontalmente o verticalmente. Ya que los casos son simétricos consideraremos un llenado vertical a continuación. El llenado de una tira de ancho w0 y profundidad d0 puede ser formulado como un Problema de la Mochila. Primero, cada caja j es rotada en una de seis direcciones tal que wj ≤ w0 , dj ≤ d0 y hj es minimizada. Si no es posible encajar la caja j dentro w0 × d0 entonces añadir esta al conjunto de cajas descartadas D. De otra manera asignar. aj = hj. cj = vj = wj hj dj. (1.1). para cada apropiada caja j ∈ N \D. Entonces el problema del llenado de la tira se convierte en. 17.

(22) maximizar. X. cj x j. j∈N \D. sujeto a. X. aj x j ≤ b. (1.2). j∈N \D. xj ∈ {0, 1},. j ∈ N \D. donde N \D es el conjunto de cajas disponibles, y b es la altura h del algoritmo fill layer. El problema resultante es un Problema de la Mochila que puede ser resuelto en tiempo O(nb) a través de programación dinámica, donde n = |N \D|.. Emparejamiento de las cajas La solución encontrada por el problema de la mochila puede ser mejorada emparejando las cajas de dos en dos siempre que sea posible. Ya que la complejidad de este algoritmo es O(n2 ) sólo es ejecutado una vez para cada capa que tenga profundidad d0 . Ası́ asúmase que una caja j ha sido rotada tal que su profundidad dj es la mas larga posible que satisface dj ≤ d0 . Una medida de cuan bien llena la profundidad es α(j) = vj /(wj hj d0 ) = dj /d0 . El objetivo en mejorar este llenado emparejando la caja j con otra caja i. Ası́ para cada caja i 6= j todas las diferentes rotaciones de i y j son consideradas donde di + dj ≤ d0 , cada vez derivando el ratio de llenado β(i, j) = (vi + vj )/(d0 máx{wi , wj } máx{hi , hj }). Si β(i, j) ≤ α(j) para todas las cajas i y todas las rotaciones, entonces la caja j permanece sola. De otro modo, la caja i (y la rotación correspondiente) que conduce al valor mas grande de β(i, j) es elegida y una nueva caja k es construida con las dimensiones. wk = máx{wi , wj };. hk = máx{hi , hj };. dk = d0. (1.3). Las cajas originales i y j son removidas temporalmente del problema, para descartar que ellas sean elegidas dos veces en el llenado de la capa.. 18.

(23) 1.3.2.. Algoritmo de Gehring y Bortfeldt. Gehring y Bortfeldt [GB02] presentaron un algoritmo genético paralelo para resolver el problema del contenedor. Este algoritmo es explicado primeramente secuencialmente y a continuación de modo paralelo.. Algoritmo genético secuencial El algoritmo genético secuencial involucra dos componentes. El primer componente, también llamado heurı́stica básica sirve la generación de arreglos de cajas. El segundo componente es una metaheurı́stica de orden superior la cual contiene los operadores genéticos y controla el proceso de búsqueda. Ya que la búsqueda es realizada inmediatamente en el espacio de soluciones del problema (fenotipos), no es requerida una codificación de las soluciones separadamente. Sin embargo, la búsqueda está restringida a tipos de planes de colocación por capas. Cada uno de los planes de colocación consiste en capas rectangulares las cuales siguen a cada otra sin espacios y las cuales están en paralelo al lado frontal del contenedor. Cada capa contiene un arreglo de uno o mas cajas están completamente dentro de la capa. La altura y el ancho de una capa coincide con la dimensión correspondiente del contenedor. La profundidad de la capa es determinada por la caja de determinación de capa y la orientación espacial de esta caja. La figura 1.3 muestra la estructura en capas de los planes de colocación generados. En el inicio de la búsqueda la heurı́stica básica es usada para generar los planes de almacenamiento (individuos del algoritmo genético) de la población. Esta población sirve como punto de partida del proceso de evolución. Las siguientes poblaciones son generadas de acuerdo al modelo de reemplazo generacional con la exclusión de duplicados. Dos operadores especı́ficos del problema, el operador de cruzamiento y mutación, siempre se transfieren inicialmente sin cambios a las capas de los individuos padres con alto volumen de utilización particularmente. Ya que la transferencia de capas no lleva generalmente a soluciones completas, las capas adicionales las cuales todavı́a están faltando son generadas por la heurı́stica básica. Además, algunos individuos de la generación actual son transferidos sin cambios a la siguiente generación. 19.

(24) y. Profundidad de capa. wC. Caja de determinación de capa x capa 1. capa 2. capa 3. capa 4. dC. Figura 1.3: Plan de colocación con cuatro capas. Fuente: Elaboración propia. La generación de una capa consiste de dos pasos. El primer paso sirve para definir la capa. Una capa es definida a través de arreglar la caja de determinación de capa y su orientación espacial. En el segundo paso, la capa es llenada con la caja de determinación de capa y cajas adicionales. Ya que la heurı́stica básica procede de una manera determinista, el arreglo de cajas es determinado sin ambigüedad por una definición de capa dada. Por un lado, la heurı́stica básica es usada para preparar los individuos de la población inicial. Por otro lado, la heurı́stica básica sirve a la generación de capas adicionales con una utilización de volumen alta las cuales son requeridas para completar individuos de las siguientes poblaciones. Ambas tareas son realizadas escencialmente modificando la definición de capa y generando una correspondiente variedad de capas. Empezando con la capa cuboide una capa es llenada sucesivamente cargando los espacios residuales sucesivamente dentro de la capa. Después que un espacio residual ha sido carga20.

(25) do, tres espacios residuales adicionales son generados dentro de este espacio residual. Los tres nuevos espacios residuales son insertados en una pila de espacio residual y procesados mas adelante. Sin embargo, antes que nuevos espacios residuales sean procesados, un intento es hecho para fusionarlos con espacios residuales existentes. Cada espacio residual es llenado con el par de volumen máximo de cajas sin almacenar la cual encaja completamente en el espacio residual. Si las cajas a ser llenadas en un espacio residual pueden ser arregladas de maneras diferentes, la posición relativa, la variante de rotación, y el arreglo espacial de las cajas son determinados de acuerdo a reglas heurı́sticas definidas. El método de colocación de cajas y generación de espacios residuales excluye un sobresalimiento de cajas en los lados. El algoritmo genético secuencial por consiguiente siempre respeta la restricción de estabilidad (C1). Además, el algoritmo genético secuencial también toma en cuenta las restricciones restantes (C2) a (C4) en cuenta. El cuadro 1.1 contiene los parámetros del algoritmo genético secuencial. Los valores estándar especificados de los parámetros constituyen la configuración estándar del algoritmo genético secuencial usada para la prueba. Cuadro 1.1: Parámetros para el algoritmo genético secuencial. Parámetros Comentarios popsize Tamaño de la población ngen Número de generaciones a ser evolucionadas qrepro Radio de individuos reproducidos por generación en %. Valor estándar 50 500 20. Los parámetros rvmode y sdivision requieren algunos comentarios adicionales: Para determinar las variantes de rotación espacial de las cajas colocadas el algoritmo genético secuencial puede usar dos reglas heurı́sticas alternativas. La primera regla (’P3.1’) es usada exclusivamente para el ajuste rvmode = 0 y la segunda regla (’P3.2’) para el ajuste rvmode = 1. Para el valor rvmode = 2, de otro lado, la primera regla es aplicada a las primeros 50 % de las poblaciones generadas y la segunda regla a las últimas 50 %; con rvmode = 3 es al revés. Colocar una caja en un espacio residual conduce a una área libre de base en forma de ”L”la cual está para ser subdividida en dos rectángulos con el objetivo de generar 21.

(26) espacios residuales hijos. Para el ajuste sdivision = 0 el área en forma de ”L.es subdividida preferentemente de tal manera que el área del más largo de los rectángulos resultantes sea maximizada, mientras que para sdivision = 1 el área del más pequeño rectángulo sea maximizada.. 1.4.. Aplicaciones similares existentes. Se encuentran en internet diversas aplicaciones para resolver el problema del contenedor. Se ha tomado algunas para describirlas y realizar un análisis comparativo entre las mismas con la intención de destacar las caracterı́sticas encontradas y seleccionar las que soportará el software que será desarrollado.. 1.4.1.. EasyCargo. EasyCargo [Eas16] es un software de planificación de carga basado en web desarrollado por la compañı́a Bee Interactive s.r.o. de República Checa. Lo único que necesita el cliente para empezar a usar EasyCargo es una cuenta en su página web. Las caracterı́sticas que presenta el software son las siguientes: El software tiene un número ilimitado de cálculos de plan de carga. El software puede procesar 10000 o más objetos de hasta 250 tipos diferentes. Soporte para unidades del sistema anglosajón (pulgadas, libras) o unidades del sistema métrico. Se pueden definir grupos de prioridad separando las cajas basados en el destino final. Los grupos pueden ser apilados o ser divididos con una pared virtual. Se pueden insertar datos de los objetos directamente desde un archivo Excel. Se pueden definir restricciones de posicionamiento para las cajas (no apilable, sin inclinación, sin rotación, desplazamiento al centro de masa, etc.) 22.

(27) Se pueden crear reportes del plan de carga visualizado. Se pueden guardar y reusar los planes de carga.. En la figura 1.4 se puede apreciar la interfaz de este programa.. Figura 1.4: Interfaz de EasyCargo Fuente: Captura de pantalla de la aplicación web.. 1.4.2.. CargoWiz. CargoWiz R [Car16] es un software de planificación de carga desarrollado por la empresa SoftTruck de Tampa, Florida, EEUU. Las caracterı́sticas que presenta este software son las siguientes:. Hay disponibles una variedad de lenguajes (inglés, español, alemán, turco, francés italiano o chino). Posee un editor para mover las cajas mediante el mouse del computador haciendo posible crear diseños de carga enteramente de uno mismo. Dispone de los tamaños comunes de camiones y contenedores de carga. 23.

(28) Muestra una vista de la etapa de carga en la cual se indica las cajas que han sido colocadas y las faltantes durante el procesamiento del algoritmo. Permite ingresar datos directamente en una grilla o importarlos usando una plantilla Excel. Opcionalmente permite definir reglas de carga, por ejemplo: lı́mites de apilamiento, apilar algunas cajas en el fondo solamente, ajustar prioridades de carga, entre otras.. En la figura 1.5 se puede apreciar la interfaz gráfica de este programa.. Figura 1.5: Interfaz de CargoWiz Fuente: Captura de pantalla de la aplicación de escritorio.. 1.4.3.. CubeMaster. CubeMaster Online [Cub16] es una solución en la nube desarrollada por la compañı́a Logen Solutions de California en Estados Unidos. Permite construir un plan de carga óptimo para camiones, tráileres, contenedores marı́timos y palés con equipos trabajando conjuntamente 24.

(29) en áreas distribuidas. Este software afirma disponer de una manera eficiente para compartir y controlar la planificación de carga de un contenedor. Está disponible como servicio web o aplicación autónoma. La aplicación puede verse en la figura 1.6.. Figura 1.6: Interfaz de CubeMaster Online Fuente: Captura de pantalla de la aplicación web. El software provee tres tipos de optimización:. Optimización de carga de vehı́culos. Optimización de carga de palés. Optimización de carga aérea.. Las principales caracterı́sticas de la optimización de carga de vehı́culos son:. 25.

(30) Soporta varios tipos de carga: carga mixta para varios vehı́culos, carga única para un sólo tamaño de producto. Dispone de diversas reglas de carga: varios tipos de vehı́culos, agrupamiento para las mismas direcciones o paradas, orientaciones permitidas, entre otras.. 1.4.4.. packVol. El software packVol [pac16] ha sido desarrollado por Angelucci Dr. Antimo de nacionalidad italiana para el sistema operativo Microsoft Windows. Escrito en el lenguaje de programación C++, el software se adapta fácilmente a palés, camiones, contenedores, vagones. La interfaz de packVol puede verse en la figura 1.7.. Figura 1.7: Interfaz de packVol. Fuente: Captura de pantalla de la aplicación de escritorio. Las principales caracterı́sticas de este software son: 26.

(31) El software posee un optimizador interno avanzado verdaderamente tridimensional. Se puede gestionar diversas reglas de carga. Posee un entorno visual para la modificación y creación de la planificación de carga. Dispone de una fácil integración con sistmas de gestión externos. Se puede realizar la planificación de carga ya sea automáticamente (con un algoritmo) o manualmente. El software permite la importación de datos desde archivos Excel o la extracción desde fuentes de datos ODBC. El software dispone de una base de datos interna donde almacena las dimensiones estándar de las diferentes cajas y vehı́culos contenedores utilizados en la industria. Se pueden generar reportes visuales de la planificación de carga en formato PDF. La aplicación soporta la definición de reglas de carga, por ejemplo: lista de prioridad, agrupamiento, ordenamiento.. 1.4.5.. LoadPlanner. LoadPlanner [Loa16] es un software para la planificación de carga desarrollado en Java por la empresa Optimum Logistic de Illinois, Estados Unidos. Según la página web de la empresa, este software posee un sofisticado algoritmo de carga en 3D como resultado de muchos años de investigación y cooperación con destacados proveedores logı́sticos. Sus principales caracterı́sticas son:. El software puede clasificar objetos del negocio (cajas, órdenes, contenedores, etc) en un sistema flexible de categorı́as. Se pueden formular reglas y restricciones de alto nivel y aplicarlas a categorias seleccionadas.. 27.

(32) Se pueden usar reglas y restricciones en el proceso de la planificación de carga y optimización. El software puede resolver un conjunto de problemas de planificación de carga multinivel (empaque, colocación en palé, carga en contenedor o remolque). Los resultados son mostrados en unos gráficos 3D interactivos fáciles de analizar. La interfaz de LoadPlanner puede verse en la figura 1.8.. Figura 1.8: Interfaz de LoadPlanner Fuente: Captura de pantalla de la aplicación de escritorio.. 1.4.6.. Análisis comparativo entre aplicaciones. Como se ha visto, se han descrito algunas de las soluciones de software encontradas en internet para la aplicación. A continuación se mencionarán en una tabla las ventajas y 28.

(33) desventajas de los software encontrados con respecto a la funcionalidad, uso, entorno de ejecución, limitaciones, etcétera. Cuadro 1.2: Análisis comparativo entre las aplicaciones encontradas. Software. Ventajas. Desventajas. EasyCargo No necesita instalación ya que está disponible como aplicación web. Dispone de una vista tridimensional donde se puede inspeccionar las cajas colocadas en el contenedor. Los objetos pueden ser etiquetados para una mejor visualización. Sencilla curva de aprendizaje para las funciones del software.. Requiere de una conexión a internet permanente.. El software muestra una vista gráfica de las cajas que han sido procesadas (colocadas en el contenedor) ası́ como también las que no han podido ser colocadas.. El software sólo está disponible para el sistema operativos Microsoft Windows. Muestra una proyección caballera del contenedor y las cajas. La vista que muestra es estática.. CargoWiz. Continúa en la siguiente página. 29.

(34) Cuadro 1.2 – Continúa de la página anterior Software. Ventajas. Desventajas. CubeMaster El software es una solución en la nube que no requiere instalación previa y puede ejecutarse en cualquier navegador. El software posee una API (application programming interface) para su uso como servicio web y que puede conectarse a ERPs o similares aplicaciones. Posee un listado estandar de las dimensiones de las cajas que usualmente son utilizadas como carga.. El software requiere de una conexión permanente a internet.. Posee una interfaz simple y amigable con el usuario. Permite generar e imprimir reportes. Permite optimizar la carga sobre uno o varios contenedores.. El software solo está disponible para el sistema operativo MS Windows.. packVol. Continúa en la siguiente página. 30.

(35) Cuadro 1.2 – Continúa de la página anterior Software. Ventajas. Desventajas. LoadPlanner El software posee dos opciones de ejecución: • Remotamente mediante la conexión a un servidor que ejecuta el algoritmo de planificación de carga.. A pesar de haber sido desarrollado en Java, el software solo está disponible para el sistema operativo MS Windows.. • Localmente mediante la instalación de un procesador que es descargado por internet. El software puede generar reportes en formato HTML.. 1.5.. Descripción y sustentación de la solución. Según lo visto en este proyecto, una actividad en la logı́stica de las empresas es el transporte de carga. Con las tecnologı́as disponibles en este tiempo se hace factible desarrollar software para el proceso de optimizar la planificación de carga en los contenedores. Siendo ası́, es necesario fomentar el desarrollo de estas soluciones para las empresas. Esto llevará a un ahorro en costos y energı́a, además de la mayor transportación de objetos de valor.. 1.5.1.. Objetivo general. Realizar el análisis, diseño e implementación de un software que permita obtener la planificación de carga de un contenedor a través de algoritmos de optimización combinatoria 31.

(36) y/o heurı́sticas.. 1.5.2.. Objetivos especı́ficos. Realizar un análisis de las aplicaciones similares existentes. Identificar los requisitos funcionales y no funcionales del software de planificación de carga y realizar el análisis de los mismos. Diseñar la arquitectura del software de planificación de carga teniendo en cuenta los módulos y clases que tendrá el software ası́ como la interacción entre ellos. Implementar el código del sistema para obtener el software de planificación de carga.. 1.5.3.. Resultados esperados. Se tendrá un estudio de algunos de los algoritmos de planificación de carga encontrados en la literatura. Se tendrá un análisis y diseño del software de planificación de carga. Se tendrá implementado un software que proporcione una solución al problema de planificación de carga.. 32.

(37) Capı́tulo 2 Análisis En este capı́tulo desarrollaremos el análisis del software de planificación de carga. Este capı́tulo está organizado de la siguiente manera: En la primera sección se explica la metodologı́a de desarrollo del software del contenedor. En la segunda sección, se detallan los requerimientos funcionales y no funcionales. En la tercerca sección, se realiza el análisis del software.. 2.1.. Metodologı́a. Para este proyecto se va a emplear la metodologı́a denominada Programación Extrema (comúnmente abreviada como XP de la frase en inglés eXtreme Programming). Esta metodologı́a es apropiada para el software de planificación de carga pues se tienen claros los requerimientos del software y el desarrollo lo hará una sola persona. Esta metodologı́a está basada en cinco valores que se detallan a continuación:. Simplicidad La idea es simplificar el diseño para agilizar el desarrollo del código fuente. Comunicación La comunicación se realiza de diversas maneras. Se espera que los desarrolladores utilicen un código simple, con el cual comuniquen mejor su implementación. 33.

(38) Se prefiere que el código sea autodocumentado y que sólo se comenten aquellos elementos que no van a cambiar, por ejemplo la definición de una clase o la funcionalidad de un método. Retroalimentación El cliente está integrado en el proyecto de software, por tanto, conoce el estado del proyecto en tiempo real y los desarrolladores constantemente realizan los cambios requeridos por el cliente. Valentı́a Los desarrolladores deben tomar la decisión de modificar, transformar y/o desechar su código cuando sea necesario. También se refiere a la persistencia cuando un desarrollador intenta resolver algún problema un dı́a entero, y luego lo resolverá al dı́a siguiente si es persistente. Respeto Los miembros del equipo se respetan mutuamente. Los desarrolladores no pueden escribir código que haga que las pruebas fallen on que demore a otros.. 2.1.1.. Concepción. En esta etapa se han desarrollado los objetivos del proyecto y se determinan los principales procesos de software. Esta etapa consta de las siguientes actividades:. 1. Elaboración del plan de proyecto (ver capı́tulo 1) Definición del problema. Definición de los objetivos. Definición de los resultados esperados. Definición de la metodologı́a a utilizar. Planificación del proyecto. 2. Elaboración del marco conceptual (ver capı́tulo 1) 3. Elaboración del estado del arte Estudio de los métodos de solución del problema. Estudio de los productos existentes que brindan una solución al problema. 34.

(39) Análisis comparativo entre las soluciones. 4. Identificación de requerimientos Elaboración del catálogo de requisitos del software. Especificación de requisitos del software.. 2.1.2.. Elaboración. En esta sección expondremos el análisis y diseño del software y las pruebas necesarias para la verificación y validación del mismo. Se realizarán las siguientes actividades:. 1. Análisis: como se mencionó anteriormente elegimos la metodologı́a XP. 2. Diseño, se compone de los siguientes elementos: a) Definición de la arquitectura del software (ver punto 3.1). b) Definición de la arquitectura de la información (ver la sección 3.3). c) Diagrama de clases de diseño (ver la sección 3.1.4). d ) Diagramas de secuencia (ver dentro de la sección 3.1.4). e) Diseño de la interfaz gráfica (ver la sección 3.2). 3. Pseudocódigo del algoritmo (se encuentra explicado en la sección 4.2). 4. Diseño de pruebas (se encuentra explicado en la sección 4.3.. 2.1.3.. Implementación. La implementación del software se encuentra explicada en su totalidad en el capı́tulo 4. Abarca los siguientes puntos:. Aspectos de la implementación.. 35.

(40) Tecnologı́as utilizadas. Frameworks. Implementación del algoritmo de planificación de carga. Implementación del software de planificación de carga. Pruebas.. 2.2.. Requerimientos. En esta sección se presentan los requisitos para el software de planificación de carga del contenedor.. 2.2.1.. Requerimientos funcionales. Cuadro 2.1: Requerimientos funcionales del software de planificación de carga. Nro.. Descripción. Prioridad. RF01. El software permitirá ingresar las dimensiones del con- Normal tenedor de carga y las dimensiones de las cajas en su interior.. RF02. El software permitirá generar un problema de ejemplo para demostración de su uso.. RF03. El software permitirá guardar en un fichero la informa- Normal ción de las dimensiones del contenedor de carga y las dimensiones de las cajas en su interior. RF04. El software permitirá cargar problemas de planificación Normal previamente guardados y poder modificarlos o calcular la planificación de carga del contenedor.. Normal. Continúa en la siguiente página. 36.

(41) Cuadro 2.1 – Continúa de la página anterior Nro.. Descripción. RF05. El software comprobará la validez del archivo de texto Normal que contiene la especificación del problema de planificación de carga. RF06. El software calculará una planificación de carga para el Normal problema de carga especificado por el usuario. RF07. El software visualizará el contenedor de carga junto con Normal las cajas en su interior de acuerdo a la planificación de carga en 3D. RF08. El software permitirá mostrar y almacenar los resultados de la ejecución del algoritmo de planificación de carga en un fichero de texto.. 2.2.2.. Prioridad. Normal. Requerimientos no funcionales. Cuadro 2.2: Requerimientos no funcionales del software de planificación de carga. Nro.. Descripción. RNF01. Para la implementación se utilizará el lenguaje de pro- Implementación gramación C++ con el framework Qt.. RNF02. Los resultados de la ejecución del algoritmo de planifi- Implementación cación de carga podrán almacenarse en archivos de texto y XML.. RNF03. La aplicación podrá ser ejecutada sobre los sistemas op- Implementación erativos Windows, Linux o Mac OS.. 2.2.3.. Tipo. Restricciones. La función principal de la aplicación es generar una planificación de carga para un contenedor y las cajas que debe contener en su interior. El software sólo podrá aceptar las dimensiones de cajas tridimensionales con forma. 37.

(42) de paralelepı́pedo. Cada caja podrá ser rotada y colocada sobre cualquiera de sus lados. Esto es hay como máximo 3 configuraciones de la caja con sus respectivas dimensiones que podrán ser usadas. Para fines de simplificar el problema, no se tendrán en cuenta restricciones acerca del peso que puede soportar el contenedor o el peso que puede soportar cada caja encima. Como se ha explicado en el estado del arte, existen muchas variantes del problema del contenedor de carga con restricciones. La implementación de dichas variantes se dejan para futuras investigaciones.. 2.3.. Análisis. En esta sección se presenta el análisis realizado a partir de los requerimientos especificados en la sección anterior.. 2.3.1.. Modelo de casos de uso. En el modelo de casos de uso se presenta un diagrama del uso que el/los usuario(s) hace del software. Para el desarrollo de los casos de uso se ha utilizado la herramienta Umbrello.. Catálogo de actores. Usuario. Figura 2.1: Diagrama de actores. Fuente: Elaboración propia.. 38.

(43) Usuario La aplicación solamente es usada por una clase de usuario cuya función es ingresar las dimensiones del contenedor y las cajas y a continuación indicar al software que realice la planificación de carga.. Casos de uso En la figura 2.2 se muestran los casos de usos identificados. Ingresar datos de problema. Generar problema de ejemplo. Editar datos de problema. Guardar datos de problema. Usuario. Resolver problema. Guardar datos de solución. Visualizar planificación de carga. Figura 2.2: Diagrama de casos de uso. Fuente: Elaboración propia. A continuación se detallan cada uno de los casos de uso: Caso de uso: Ingresar datos de problema Objetivo Permitir el ingreso de datos al software desde la interfaz gráfica. Precondiciones El software debe estar ejecutándose y debe mostrarse su ventana principal. 39.

(44) Evento/Acción El usuario presiona el botón para ingresar un nuevo problema de planificación de carga. Resultado El software limpia los datos mostrados y la visualización de la pantalla. Postcondiciones El usuario está habilitado para ingresar los datos de un nuevo problema de planificación de carga. Actores El usuario. Caso de uso: Abrir datos de problema Objetivo Permitir la carga desde un archivo de los datos de un problema. Precondiciones (2) El software debe estar ejecutándose y debe mostrarse su ventana principal. El archivo de un problema de planificación de carga debe haberse guardado previamente. Evento/Acción El usuario presiona el botón para cargar el problema de planificación de carga. Resultado El software muestra los datos del problema de planificación de carga. Postcondiciones El software está listo para resolver el problema mostrado o para realizar cambios. Actores El usuario. Caso de uso: Generar problema de ejemplo Objetivo Generar un problema de planificación de carga automáticamente. Precondiciones El software debe estar ejecutándose y debe mostrarse su ventana principal. Evento/Acción (2) El usuario presiona el botón correspondiente para generar un problema de planificación de carga. El software despliega un cuadro de diálogo con las opciones de configuración. Resultado El software genera un problema de planificación de carga y coloca los datos en la interfaz de usuario. 40.

(45) Postcondiciones El software está listo para resolver el problema mostrado o para realizar cambios. Actores El usuario. Caso de uso: Guardar datos de problema Objetivo Guardar en un archivo los datos de un problema de planificación de carga. Precondiciones Debe haberse ingresado un problema de planificación de carga en el software. Evento/Acción (2) El usuario presiona el botón correspondiente para guardar los datos del problema. l software despliega un cuadro de diálogo donde el usuario puede especificar la ruta y el nombre del archivo en que se guardará el problema. Resultado El software procede a convertir los datos que tiene del problema en memoria a un formato de texto y los guarda en el archivo especificado por el usuario. Postcondiciones El software no ha realizado ningún cambio en los datos mostrados. Actores El usuario. Caso de uso: Resolver problema Objetivo Resolver un problema de planificación de carga. Precondiciones Debe haberse ingresado un problema de planificación de carga en el software. Evento/Acción El usuario presiona el botón correspondiente para resolver el problema de planificación de carga. Resultados (2) El software despliega las posiciones de las cajas que serán empacadas en una tabla junto con sus orientaciones. El software visualiza en 3D el interior del contenedor con la colocación de las cajas.. 41.

(46) Postcondiciones El software no ha realizado ningún cambio en los datos mostrados. Actores El usuario. Caso de uso: Guardar datos de solución Objetivo Guardar los datos del problema y la solución en un archivo de texto. Precondiciones Debe haberse ingresado un problema de planificación de carga en el software y debe haberse aplicado la opción para resolver el problema. Evento/Acción (2) El usuario presiona el botón correspondiente para guardar los datos de la solución. El software muestra un cuadro de diálogo donde el usuario indica la ruta y el nombre del archivo en que se guardarán los datos. Resultados El software procede a convertir los datos que tiene del problema y la solución a un formato XML y los guarda en el archivo especificado por el usuario. Postcondiciones El software no ha realizado ningún cambio en los datos mostrados. Actores El usuario. Caso de uso: Abrir datos de solución Objetivo Abrir los datos de un problema y su solución en un archivo desde un archivo de texto. Precondiciones El software debe estar ejecutándose y debe mostrar su ventana principal. Evento/Acción (2) El usuario presiona el botón correspondiente para abrir los datos de una solución al problema de planificación de carga. El software despliega un cuadro de diálogo en donde el usuario indica la ruta del archivo con la solución. Resultados El software traduce el contenido del archivo y muestra la información relativa a la solución en la interfaz del programa. También se muestra la planificación de carga en 3D.. 42.

(47) Postcondiciones El software no ha realizado ningún cambio en los datos mostrados. Actores El usuario. Caso de uso: Visualizar planificación de carga Este caso de uso se aplica inmediatamente después de haber realizado el caso de uso Resolver problema o inmediatamente después del caso de uso Abrir datos de solución.. 2.3.2.. Caracterı́sticas de los usuarios. Los usuarios del software son personas con conocimiento teórico-práctico de geometrı́a en 3 dimensiones, capaces de ingresar las dimensiones correspondientes del contenedor y las cajas respectivas. Asimismo capaces de interpretar los resultados para disponer fı́sicamente las cajas en el interior del contenedor.. 2.3.3.. Diagrama de clases de análisis. En la figura 2.3 mostramos el diagrama de clases de análisis que consta de tres clases:. ContainerProblem Esta clase almacena los datos del problema del contenedor. Los datos que almacena son las dimensiones del contenedor y las dimensiones de las cajas a ser colocadas en el interior del contenedor. Las cajas se agrupan en grupos que tengan las mismas dimensiones. ContainerProblemSolver Esta clase contiene un único método que ejecuta el algoritmo para la solución del problema de contenedor provisto como parámetro. El resultado es un objeto de tipo ContainerSolution. ContainerSolution Esta clase almacena los datos de una solución encontrada a un problema de planificación de carga. Esta clase tiene una referencia a la clase ContainerProblem.. 43.

(48) ContainerProblemSolver + solve(problem : ContainerProblem, out solution : ContainerSolution). ContainerProblem. ContainerSolution. - containerLengthXValue : int. - containerLengthXValue : int. - containerLengthYValue : int. - containerLengthYValue : int. - containerLengthZValue : int. - containerLengthZValue : int. - boxLengthXValues : QVector<int>. - boxLengthXValues : QVector<int>. - boxLengthYValues : QVector<int>. - boxLengthYValues : QVector<int>. - boxLengthZValues : QVector<int>. - boxLengthZValues : QVector<int>. + addBox(lengthX : int, lengthY : int, lengthZ : int). - boxCoordinateXValues : QVector<int>. + removeBoxes(indexes : QModelIndexList). - boxCoordinateYValues : QVector<int>. + clear(). - boxCoordinateZValues : QVector<int>. + setContainerLengthX(value : int). - boxPackedFlagValues : QVector<bool>. + setContainerLengthY(value : int). - boxOrderIndexes : QVector<int>. + setContainerLengthZ(value : int). - packedVolumeValue : int + clear() + setSolution(). Figura 2.3: Diagrama de clases de análisis. Fuente: Elaboración propia.. 44.

(49) Capı́tulo 3 Diseño Todo software ha de tener un diseño antes de ser desarrollado. En este capı́tulo se presentarán los temas relacionados con el diseño del Software. Este capı́tulo está estructurado de la siguiente manera. En la primera sección se muestra y explica la arquitectura de la solución propuesta. En la segunda sección se explica la el diseño de la interfaz gráfica. En la tercera sección se muestra la arquitectura de la información.. 3.1.. Arquitectura de la solución. En esta sección se señalarán las principales caracterı́sticas de la arquitectura empleada para el diseño del software.. 3.1.1.. Representación de la arquitectura. Los estilos arquitectónicos que sigue el presente software son las siguientes:. 45.

(50) Arquitectura de flujo de datos Se ha elegido esta arquitectura ya que la información del problema del contenedor se procesan desde los datos recogidos de un archivo para ser luego ingresados al algoritmo de planificación de carga, el cual genera una solución al problema de planificación de carga. Por último estos datos son visualizados en una representación de 3 dimensiones. Archivo de datos de problema. Datos de problema en memoria. Datos de solución de problema. Modelo de visualización de datos. Figura 3.1: Diagrama de flujo de datos de la aplicación Fuente: Elaboración propia.. Arquitectura orientada a objetos Este estilo arquitectónico es adecuado para el software pues modelamos varios de los componentes del software mediante clases. Un ejemplo de esto son las clases ProblemaContenedor que representa a un problema de planificación de carga, AlgoritmoContenedor que representa a un objeto que resuelve un problema de planificación de carga, y la clase SolucionContenedor que representa a una solución para el problema de planificación de carga.. 46.

(51) Repositorio Este estilo de arquitectura es apropiado para el software pues se utilizarán archivos XML para almacenar tanto los datos del problema como de la solución.. Monolı́tica El software será utilizado en una sola aplicación que brindará toda la funcionalidad descrita en los requerimientos. Se hará uso de un único programa en un solo ordenador.. 3.1.2.. Escenarios o casos de uso. Los casos de uso son los que guian el diseño y el desarrollo del software. Los casos de uso identificados son los siguientes:. Ingresar datos de problema Este caso de uso se refiere al ingreso de datos del problema en la aplicación por parte del usuario. Abrir datos de problema Este caso de uso se refiere a la recuperación y edición de datos desde un archivo. Generar problema de ejemplo Se refiere a la demostración que realiza el software mediante la generación de los datos de un problema de planificación de carga. Guardar datos de problema Este caso de uso se refiere a guardar los datos de un problema en un archivo de formato XML. Resolver problema Este caso de uso se refierea aplicar el algoritmo de planificación de carga sobre los datos ingresados y generar una solución. Guardar datos de solución Este caso de uso vuelca los datos de la solución generados en un archivo XML que puede leerse nuevamente. Abrir datos de solución Este caso de uso abre los datos de una solución a un problema de planificación de carga previamente guardados. 47.

(52) Visualizar planificación de carga Este caso de uso se refiere a visualizar la solución generada por el algoritmo de planificación de carga y mostrarla gráficamente en 3D al usuario.. En la figura 3.2 se muestran los casos de uso identificados. Ingresar datos de problema. Generar problema de ejemplo. Editar datos de problema. Guardar datos de problema. Usuario. Resolver problema. Guardar datos de solución. Visualizar planificación de carga. Figura 3.2: Diagrama de casos de uso. Fuente: Elaboración propia.. 3.1.3.. Vista de procesos. En la vista de proceso se tratan los aspectos dinámicos del sistema. Esta vista se puede apreciar en el diagrama de actividades que se muestra en la figura 3.3. 48.

(53) Accede al sistema. Ingresa el problema de planificación de carga. Almacena el problema de planificación de carga. Valida el problema ingresado. Calcula la planificación de carga. Almacena los resultados. Figura 3.3: Diagrama de actividades de la aplicación. Fuente: Elaboración propia.. 3.1.4.. Vista lógica. La vista lógica describe las clases mas importantes, su organización en paquetes de servicio y subsistemas, y la organización de estos en capas.. Diagrama de clases Las clases mas importantes son las que se muestran en la figura 3.4. Se describen a continuación:. ContainerProblem Representa a un problema de planificación de carga. Posee las siguientes funciones miembro: containerLengthX No recibe parámetros. Retorna la longitud del contenedor en el eje X. containerLengthY No recibe parámetros. Retorna la longitud del contenedor en el eje X.. 49.

(54) Figura 3.4: Diagrama de clases de la aplicación. Fuente: Elaboración propia. MainWindow. ContainerProblemSolver + solve(problem : ContainerProblem, out solution : ContainerSolution) ejecuta produce. resuelve. llena ContainerProblem + + + + + + + + + + + + + + + + + + + +. containerLengthX() containerLengthY() containerLengthZ() groupsCounter() groupLengthX() groupLengthY() groupLengthZ() groupBoxesCounter() groupColor() groupName() removeGroup() refiere allBoxesQuantity() clear() setGroupsCount() addGroup() setGroup() setContainerLengthX() setContainerLengthY() setContainerLengthZ() setGroupBoxCount(). + + + + + + + + + +. on_actionGenerateProblem_triggered() on_actionNewProblem_triggered() on_actionSolveProblem_triggered() on_actionAddGroup_triggered() on_actionDeleteGroup_triggered() on_actionSaveProblem_triggered() on_actionOpenProblem_triggered() on_actionSaveSolution_triggered() on_actionOpenSolution_triggered() on_actionAbout_triggered(). ContainerSolution - boxLengthXValues : QVector<int> - boxLengthYValues : QVector<int> - boxLengthZValues : QVector<int> - boxCoordinateXValues : QVector<int> - boxCoordinateYValues : QVector<int> - boxCoordinateZValues : QVector<int> - packedBoxesGroupsIndexes : QVector<int> + setBoxes() + clear() + boxLengthX(index : int) : int + boxLengthY(index : int) : int + boxCoordinateX(index : int) : int + boxCoordinateY(index : int) : int + boxCoordinateZ(index : int) : int + boxGroupIndex(index : int) : int + boxesCount() : int. lee o escribe. lee o escribe. ContainerXmlParser - streamReader : QXmlStreamReader - streamWriter : QXmlStreamWriter + writeProblem() + readProblem() + writeSolution() + readSolution(). muestra. visualiza invoca. visualiza. GLContainerWidget - mouseLastPosition : QPoint - rotationX : int - rotationY : int - rotationZ : int - distance : int - displayedBoxesLimit : int + setContainerSolution() + initializeGL() + paintGL() + resizeGL() + mousePressEvent() + mouseMoveEvent() + mouseReleaseEvent() + wheelEvent() + resetView() + setDisplayedBoxesLimit(value : int). containerLengthZ No recibe parámetros. Retorna la longitud del contenedor en el eje X. groupsCounter No recibe parámetros. Retorna el número total de grupos definidos. groupLengthX Recibe como parámetro el ı́ndice de un grupo. Retorna la longitud de la caja del grupo en el eje X. groupLengthY Recibe como parámetro el ı́ndice de un grupo. Retorna la longitud de la caja del grupo en el eje Y . groupLengthZ Recibe como parámetro el ı́ndice de un grupo. Retorna la longitud de la caja del grupo en el eje Z.. 50.

(55) groupBoxesCounter Recibe como parámetro el ı́ndice de un grupo. Retorna el número de cajas que representa ese grupo. groupColor Recibe como parámetro el ı́ndice de un grupo. Retorna el color de la caja del grupo que es un objeto QColor. groupName Recibe como parámetro el ı́ndice del grupo. Retorna el nombre descriptivo del grupo. removeGroup Recibe como parámetro el ı́ndice de un grupo y procede a removerlo del problema. Todos los demás grupos con ı́ndice superior a este grupo decrementan sus ı́ndices en 1. clear Elimina todos los grupos. addGroup Recibe como parámetros los datos de un grupo y añade un nuevo grupo al final de la lista de grupos. setGroupsCount Cambia el tamaño de la lista de grupos al valor pasado como parámetro. setGroup Recibe como parámetros el ı́ndice y los datos de un grupo y cambia los valores del grupo por los valores recibidos. setGroupBoxCount Recibe como parámetros el ı́ndice de un grupo y un valor que indicará el número de cajas en el grupo. setContainerLengthX Asigna el valor de la longitud del contenedor en el eje X. setContainerLengthY Asigna el valor de la longitud del contenedor en el eje Y . setContainerLengthZ Asigna el valor de la longitud del contenedor en el eje Z. ContainerSolution Representa a la solución de un problema de planificación de carga. Posee las siguientes funciones miembros: setSolutionData Asigna un nuevo valor a los vectores que almacenan los datos de las cajas pertenecientes a la solución. clear Cambia el tamaño de los vectores que almacen los datos a cero. boxLengthX Recibe como parámetro el ı́ndice de una caja. Retorna la longitud de la caja en el eje X. boxLengthY Recibe como parámetro el ı́ndice de una caja. Retorna la longitud de la caja en el eje X. 51.

(56) boxLengthZ Recibe como parámetro el ı́ndice de una caja. Retorna la longitud de la caja en el eje X. boxCoordinateX Recibe como parámetro el ı́ndice de una caja. Retorna el menor valor X de la posición de la caja en el contenedor. boxCoordinateY Recibe como parámetro el ı́ndice de una caja. Retorna el menor valor Y de la posición de la caja en el contenedor. boxCoordinateZ Recibe como parámetro el ı́ndice de una caja. Retorna el menor valor Z de la posición de la caja en el contenedor. ContainerXmlParser Se encarga de realizar el parseo de los objetos ContainerProblem y ContainerSolution para convertirlos en archivos de texto y viceversa. writeProblem Recibe como argumentos un objeto de la clase ContainerProblem y un objeto archivo y se encarga de volcar el objeto en el archivo de texto. readProblem Recibe como argumentos un objeto archivo y un objeto ContainerProblem y se encarga de parsear el contenido del archivo al objeto ContainerProblem. writeSolution Recibe como argumentos un objeto de la clase ContainerSolution y un objeto archivo y se encarga de volcar el objeto en el archivo de texto. readSolution Recibe como argumentos un objeto archivo y un objeto ContainerSolution y se encarga de parsear el contenido del archivo al objeto ContainerSolution. GLContainerWidget Representa a un objeto en 3D de OpenGL que se encarga de visualizar el contenedor y las cajas en sus respectivas posiciones. Posee las siguientes funciones miembro: setContainerSolution Asigna el objeto ContainerSolution que se desea visualizar. initializeGL, paintGL, resizeGL Son funciones que son necesarias para la inicialización, renderizado y ajuste del objeto OpenGL en donde se visualiza el contenedor de carga y las cajas. mousePressEvent, mouseMoveEvent, mouseReleaseEvent Son funciones que se encargan de manipular el objeto OpenGL para girar la vista de la visualización. 52.

(57) wheelEvent Es una función es utilizada para acercar o alejar la vista de la visualización. setDisplayedBoxesLimit Recibe como parámetro un número que indica cuantas de las cajas serán visualizadas. Esta función es útil para indicar parcialmente como se va llenando el contenedor con las cajas. ContainerProblemSolver Encapsula al algoritmo de planificación de carga desarrollado por el profesor David Pisinger. Posee las siguientes funciones miembro: solveProblem Resuelve el problema de planificación de carga que se le envı́a como parámetro. Emite una señal al encontrar la solución del problema. MainWindow Representa al objeto principal de la interfaz de usuario. Posee funciones miembro para ejecutar las acciones requeridas por el usuario: on actionGenerateProblem triggered Se encarga de generar un problema de planificación de carga. on actionSolveProblem triggered Se encarga de resolver el problema de planificación de carga. on actionAddGroup triggered Se encarga de añadir los datos de un nuevo grupo al problema de planificación de carga. on actionDeleteGroup triggered Se encarga de eliminar el grupo seleccionado del problema de planificación de carga. on actionEditGroup triggered Se encarga de mostrar un cuadro de diálogo que permitirá editar los datos de un grupo seleccionado. on actionSaveProblem triggered Se encarga de guardar los datos de un problema de planificación de carga al archivo de texto indicado en un cuadro de diálogo. on actionOpenProblem triggered Se encarga de abrir los datos de un problema de planificación de carga previamente guardado. on actionSaveSolution triggered Se encarga de guardar los datos de un problema de planificación de carga y su solución al archivo de texto indicado en un cuadro de diálogo. on actionOpenSolution triggered Se encarga de abrir los datos de un problema de planificación de carga y su solución previamente guardado. 53.