sistema de gestión de procesos de despacho de productos
TRANSCRIPT
UNIVERSIDAD AUSTRAL DE CHILE SEDE PUERTO MONTT
ESCUELA DE INGENIERIA EN COMPUTACION
Sistema de Gestión de Procesos de Despacho de Productos para Covepa.
Seminario de Titulación para optar
al título de Ingeniero en Computación
PROFESOR PATROCINANTE: Sra. Sandra Ruiz Aguilar
ERIC MAURICIO WISTUBA ZUÑIGA
PUERTO MONTT - CHILE 2014
Esta Tesis está dedicada a Juan y Sonia, mis padres, sin los cuales no podría
haber conseguido acceder a la educación universitaria, por todos los sus
esfuerzos que han hecho posible mi Titulación.
A mi hermano por su ejemplo y constante ayuda.
A mis amigos, familiares y conocidos por sus palabras de aliento.
A mi novia Priscyla que me apoyó en los momentos difíciles en que más la
necesité.
Agradecimientos.
A Jorge Astudillo por todas sus enseñanzas en Java y por todo el apoyo brindado.
Marcelo Garrido, Alfredo Fiebig, Edgard Schultz, Jesús Estay, Gonzalo Ojeda,
Gerardo Felmer, Jimena Avendaño, Ximena Calisto y a todos los que de alguna
u otra forma intervinieron terrenal y espiritualmente para que esta tesis haya sido
escrita.
A mi profesora patrocinante Sandra Ruiz por ser quien me ayudó a corregir este
documento, por su paciencia, dedicación y por recordarme incansablemente las
fechas límite.
ÍNDICE
ABSTRACT. ........................................................................................................ 0
SÍNTESIS.
1. Introducción. ................................................................................................... 1
2. Objetivos ......................................................................................................... 5
2.1 Objetivo General. ...................................................................................... 5
2.2 Objetivos Específicos. .............................................................................. 5
3. Planteamiento del Problema. .......................................................................... 6
3.1 Antecedentes. ........................................................................................... 6
3.1.1 Definición del Problema. .................................................................. 6
3.1.2 Esfuerzos Anteriores. ...................................................................... 8
3.1.3 Solución Propuesta. ...................................................................... 14
3.1.4 Grupo de Trabajo. ......................................................................... 15
3.2 Justificación. ........................................................................................... 17
3.2.1 Situación sin Proyeto. .................................................................... 17
3.2.2 Situación con Proyecto. ................................................................. 18
3.3 Delimitación. ........................................................................................... 19
4. Metodología. ................................................................................................. 21
4.1 Actividades de la metodología AUP. ....................................................... 22
5. Recursos. ...................................................................................................... 25
5.1 Hardware. ............................................................................................... 25
5.2 Software.................................................................................................. 26
6. Desarrollo del proyecto ................................................................................. 29
6.1 Conceptualización .................................................................................. 29
6.1.1 Entrevistas y toma de requerimientos. .......................................... 29
6.1.2 Datos recopilados en la entrevista. ............................................... 29
6.1.2.1 Despacho a cliente ............................................................ 31
6.1.2.2 Despacho diferido a cliente ............................................... 31
6.1.2.3 Despacho a Sucursales (STM Solicitud Traslado
Materiales). .................................................................................... 32
6.1.3 Datos relevantes para el despacho de productos. ........................ 32
6.1.4 Reuniones para fijar los requerimientos ........................................ 34
6.1.5 Toma de requerimientos y especificación de los mismos. ............. 35
6.2 Sistematización de los procesos de despacho. ...................................... 36
6.2.1 Identificación de los usuarios de SIGEDES. .................................. 36
6.2.2 Casos de uso. ............................................................................... 37
6.2.3 Narrativa del caso de uso general. ................................................ 37
6.2.4 Generación y especificación de los casos de uso ......................... 38
6.2.4.1 Caso de Uso SIGEDES-CU-01 Autenticar Usuario. .......... 39
6.2.4.2 Caso de Uso SIGEDES-CU-02 Generar Bultos ................. 40
6.2.4.3 Caso de Uso SIGEDES-CU-03 Calcular Peso Volumen.... 41
6.2.4.4 Caso de Uso SIGEDES-CU-04 Agregar Camión. .............. 42
6.2.4.5 Caso de Uso SIGEDES-CU-05 Seleccionar Camiones
Disponibles. ................................................................................... 43
6.2.4.6 Caso de uso SIGEDES-CU-06 Generar Plan de Despacho.
....................................................................................................... 44
6.2.4.7 Caso de Uso SIGEDES-CU-07 Modificar Plan de Despacho.
....................................................................................................... 45
6.2.4.8 Caso de Uso SIGEDES-CU-08 Mantener Sistema. ........... 46
6.3 Diagramas de Casos de Uso de SIGEDES. .......................................... 47
6.3.1 Diagrama de caso de uso SIGEDES Login. .................................. 47
6.3.2 Diagrama de caso de uso SIGEDES Principal. ............................. 48
7. Elaboración ................................................................................................... 49
7.1 Identificación de los riesgos técnicos del proyecto ................................. 49
7.2 Validación de la arquitectura en base a los requerimientos .................... 50
7.2.1 Capa de Presentación. .................................................................. 51
7.2.2 Capa de lógica de Negocios. ......................................................... 51
7.2.3 Capa de Acceso a Datos. .............................................................. 52
7.3 Prototipado ............................................................................................. 53
7.3.1 Elaboración de páginas principales, navegación y Look & Feel. ... 53
7.3.1.1 Navegación. ....................................................................... 53
7.3.1.2 Página de Login. ................................................................ 55
7.3.1.3 Página Generar Plan de Despacho. .................................. 56
7.3.1.4 Página Agregar Nuevo Camión. ........................................ 57
7.3.1.5 Página Plan de Despacho. ................................................. 58
7.3.1.6 Página Plan de Despacho Aprobado. ............................... 59
7.3.2 Investigación y elección de algoritmos matemáticos. .................... 59
7.4 Funcionamiento del algoritmo matemático. ............................................ 61
7.4.1 Paralelización del algoritmo Evolutivo. .......................................... 64
7.4.2 Funcionamiento General del Algoritmo Evolutivo. ......................... 67
7.4.2.1 Inicio de la Población. ........................................................ 69
7.4.2.2 Selección de los mejores individuos. ................................. 71
7.4.2.3 Reproducción. .................................................................... 71
7.4.2.4 Convergencia del algoritmo y reinicio poblacional. ............ 72
7.4.2.5 Condición general de parada. ............................................ 73
7.4.2.6 Obtención de Resultados. .................................................. 74
7.5 Elección de la herramienta para el algoritmo matemático. ..................... 74
7.5.1 Entendiendo el funcionamiento de MOEA Framework .................. 75
7.5.1.1 La clase Executor. ............................................................. 75
7.5.1.2 La clase Instrumenter......................................................... 77
7.5.1.3 La clase Analyzer. .............................................................. 81
8. Construcción ................................................................................................. 85
8.1 Configuración de un servidor de versiones. ............................................ 85
8.2 Configuración de un servidor de base de datos. ..................................... 86
8.3 Adecuamiento de base de datos existente. ............................................ 87
8.4 Poblamiento de BD con los datos necesarios para el proyecto. ............. 90
8.5 Testing. ................................................................................................... 91
9 Transición ...................................................................................................... 98
9.1 Testing final. ........................................................................................... 98
10. Conclusiones y/o recomendaciones. ........................................................ 109
11. Bibliografía. ............................................................................................... 112
12 Anexos. ...................................................................................................... 115
12 A) Ejemplo de uso una instancia de la clase Executor .......................... 115
12 B) Obtener datos desde el Acumulator. ................................................. 115
12 C) Ejemplo de uso de Analyzer. ............................................................ 116
INDICE DE TABLAS
Tabla 1: Definición del grupo de trabajo en el proyecto. ................................... 15
Tabla 2: Actividades para este proyecto usando la metodología AUP. ............. 23
Tabla 3: Hardware ............................................................................................ 25
Tabla 4: Software .............................................................................................. 26
Tabla 5: Recepción de listado de productos ..................................................... 30
Tabla 6: Modalidades de entrega de listado de productos. ............................... 30
Tabla 7: Datos del cliente ................................................................................. 33
Tabla 8: Datos del camión ................................................................................ 33
Tabla 9: Datos de cada artículo ........................................................................ 34
Tabla 10: Identificación de los usuarios de SIGEDES ...................................... 37
Tabla 11: Casos de Uso SIGEDES ................................................................... 38
Tabla 12: Funcionamiento general de un algoritmo Evolutivo. ......................... 68
Tabla 13: Función orientativa para el inicio de la función. ................................ 69
Tabla 14: Algoritmo optimizador genérico (Procedimiento Optimizador
(Individuo). ........................................................................................................ 70
Tabla 15: Algoritmo general para la reproducción. ........................................... 72
Tabla 16: Algoritmo orientativo para el reinicio poblacional. ............................. 73
Tabla 17: Paso de los 3 parámetros básicos necesarios al Executor ............... 76
Tabla 18: Acceder a los resultados entregados por el framework. ................... 77
Tabla 19: Recolectar datos con el Instrumenter................................................ 78
Tabla 20: Creación y configuración de una instancia del Executor ................... 79
Tabla 21: Acceder a los datos guardados en el Acumulator. ............................ 80
Tabla 22: Obtener datos desde el Acumulator. ................................................. 80
Tabla 23: Inicializar una instancia de Analyzer. ................................................ 82
Tabla 24: Ejemplo de uso del Executer y Analyzer ........................................... 83
Tabla 25: Resumen de Pesos y Volúmenes de las 4 facturas. ......................... 95
Tabla 26: Camiones disponibles para despacho. ............................................. 96
INDICE DE FIGURAS
Figura 1: SAP. Estructura General y detalles de módulos. ................................. 9
Figura 2: Estructura interna del módulo SAP SD. ............................................. 10
Figura 3: Ejemplo de Flujo de procesos de Oracle JD Edwards EnterpriseOne.
.......................................................................................................................... 11
Figura 4: Módulos de Microsoft Dynamics AX. ................................................. 12
Figura 5: Diagrama simplificado de Solución Propuesta. .................................. 17
Figura 6: Ciclo de vida de AUP. ........................................................................ 21
Figura 7: Caso de Uso SIGEDES-CU-01 Autenticar Usuario. .......................... 39
Figura 8: Caso de Uso SIGEDES-CU-02 Generar Bultos. ................................ 40
Figura 9: Caso de Uso SIGEDES-CU-03 Calcular Peso Volumen. .................. 41
Figura 10: Caso de Uso SIGEDES-CU-04 Agregar Camión. ............................ 42
Figura 11: Caso de Uso SIGEDES-CU-05 Seleccionar Camiones Disponibles.43
Figura 12: Caso de Uso SIGEDES-CU-06 Generar Plan de Despacho. .......... 44
Figura 13: Caso de Uso SIGEDES-CU-07 Modificar Plan de Despacho. ......... 45
Figura 14: Caso de Uso SIGEDES-CU-08 Mantener Sistema. ......................... 46
Figura 15: Diagrama Caso de Uso SIGEDES Login. ........................................ 47
Figura 16: Diagrama Caso de Uso SIGEDES Main. ......................................... 48
Figura 17: Arquitectura de Software. ................................................................ 50
Figura 18: Navegación por las pantallas de SIGEDES. .................................... 54
Figura 19: Página de Autenticación de Usuario SIGEDES. .............................. 55
Figura 20: Página Generar Plan de Despacho SIGEDES. ............................... 56
Figura 21: Página Agregar Nuevo Camión. ...................................................... 57
Figura 22: Página Plan de Despacho SIGEDES. .............................................. 58
Figura 23: Página Reporte PD Aprobado. ........................................................ 59
Figura 24: Ejemplo de Frente de Pareto. .......................................................... 63
Figura 25: Modelo Maestro Esclavo. ................................................................. 65
Figura 26: Parte de la tabla ARTICU en la BD de producción de Covepa. ....... 88
Figura 27: Diseño lógico de la base de datos de pruebas del proyecto. ........... 89
Figura 28: Diseño físico de la base de datos de pruebas del proyecto. ............ 90
Figura 29: Primera Factura para Testing. ......................................................... 92
Figura 30: Segunda Factura para Testing. ....................................................... 93
Figura 31: Tercera Factura para Testing. ......................................................... 94
Figura 32: Cuarta factura para Testing. ............................................................ 95
Figura 33: Factura 1 de testing terreno. ............................................................ 98
Figura 34: Factura 2 de testing en terreno. ....................................................... 99
Figura 35: Factura 3 de testing en terreno. ....................................................... 99
Figura 36: Factura 4 de testing en terreno. ..................................................... 100
Figura 37: Factura 5 de testing en terreno. ..................................................... 100
Figura 38: Factura 6 de testing en terreno. ..................................................... 101
Figura 39: Factura 7 de testing en Terreno. .................................................... 101
Figura 40: Factura 8 de testing en Terreno. .................................................... 102
Figura 41: Factura 9 de testing en Terreno. .................................................... 102
Figura 42: Factura 10 de testing en Terreno. .................................................. 103
Figura 43: Factura 11 de testing en tereno. .................................................... 103
Figura 44: Sigedes – Login. ............................................................................ 104
Figura 45: Sigedes – Generar Plan de Despacho (GPD). .............................. 104
Figura 46: Sigedes – Agregar Nuevo Camión................................................. 106
Figura 47: Sigedes – Plan de Despacho. ........................................................ 107
Figura 48: Sigedes – Reporte de Plan de Despacho Aprobado. .................... 108
SÍNTESIS.
El principal propósito del presente seminario es mostrar las etapas de diseño,
análisis e implementación de un sistema de gestión de procesos de despacho
de productos para Covepa. Para lograrlo se desarrolla un sistema para
plataforma Web usando programación orientada a objetos.
La metodología usada para el desarrollo del sistema fue AUP (Agile Unified
Process) debido a que se ajusta mejor al tipo de proyecto y ofrece las
herramientas necesarias para lograr el objetivo final.
La mayor complejidad técnica del sistema viene dada por el estudio, análisis e
implementación de un algoritmo matemático que sugiera la mejor distribución de
la carga en los camiones disponibles para despacho en Covepa. Es por esta
razón que el dominio de complejidad es de computación científica.
Cuando el proyecto ya esté en marcha en Covepa se obtendrá un sistema que
ordene los procesos de despacho, que provea de una ayuda administrativa a los
encargados de despacho de productos en las bodegas así como también llevar
un registro histórico de estas operaciones.
ABSTRACT.
The current seminar’s main purpose is to show the design, analysis and
implementation stages of a Product Dispatch Process Manager System for
Covepa. To achieve this development for web platform and Object Oriented
Programming is applied.
AUP (Agile Unified Process) is used as methodology because it fits better to the
project type and offers the most appropriated tools needed to accomplish the final
objective.
The system’s major technical complexity is given for the study, analyze and
implementation of a mathematical algorithm that suggests the best distribution of
the load for trucks available at Covepa. For this reason the complexity domain is
Scientific Computing.
Once the Project is running Covepa gets a system that manages the dispatch
process and provides an administrative support to all personnel in charge of
dispatches as well as keep an operation record.
1
1. Introducción.
En las secciones de despacho de la Empresa Covepa se realiza la labor de
planificar la distribución de los productos vendidos por la empresa a sus clientes
en las distintas sucursales a lo largo de varias comunas del sur de Chile. Esta
labor se realiza sin seguir ningún procedimiento formal de trabajo y se basa en
que éste sea hecho de la mejor forma posible por los encargados de la sección.
La percepción de un buen trabajo realizado depende de la cantidad de reclamos
que haga el cliente o los problemas que se generen. Teniendo en consideración
esto es que la gerencia quiere formalizar los procesos que intervienen en el
funcionamiento de la sección de despacho de la empresa y a su vez entregar una
herramienta que sugiera al encargado una forma de distribuir los productos en
los distintos camiones disponibles de tal manera que la gestión del despacho se
vea facilitada.
Se consideraron posibles soluciones usadas por otras empresas y éstas estaban
orientadas a la implementación de módulos de despacho ofrecidos por ERPs
(Enterprise Resource Planning) del mercado. Para poder aprovechar de mejor
forma estos sistemas se hace necesario implementar muchos módulos ya que
éstos están profundamente integrados entre sí para funcionar de la mejor forma.
Los altos costos del software, de implementación inicial, de mantenimiento y de
la prima anual de las licencias para su funcionamiento además del impacto en la
2
productividad de la organización debido a los tiempos de aprendizaje de uso del
software entre muchos otros factores hicieron que se descarte su adopción.
El crecimiento del Área de Desarrollo de Covepa ha ido a la par con el de la
empresa y ésta tiene muy buena experiencia generando sus propias soluciones
informáticas en las cuales el uso de tecnologías libres tiene especial importancia.
De esta forma el alumno desarrolló un sistema hecho a la medida y que considera
la forma de trabajo actual de la fuerza laboral lo cual representa la mejor
alternativa, ya que genera menores costos de implementación y mantención a lo
largo del tiempo. Para lograr lo anterior se hicieron entrevistas con los
encargados de despacho y con la gerencia de Administración y Finanzas de
manera tal de ofrecer un Sistema de Gestión de Procesos de Despacho que
facilite su labor diaria.
La metodología usada para el desarrollo de este proyecto es AUP (Agile Unified
Process). Esta es una versión simplificada de la metodología creada por IBM:
RUP (Rational Unified Process). Presenta actividades sugeridas en cada una de
sus 4 etapas de desarrollo las cuales son: Conceptualización, Elaboración,
Construcción y Transición. Establece una estructura lo suficientemente completa
como para llevar a cabo de buena forma este proyecto.
A continuación se reseñan brevemente los capítulos contenidos de este
seminario de titulación:
3
El capítulo 1 está dedicado a la presente introducción.
En el capítulo 2 se detallan los objetivos generales y específicos del proyecto.
El capítulo 3 está dedicado al planteamiento del problema, los esfuerzos
anteriores por resolverlo y se presenta la solución propuesta.
En el capítulo 4 se describe la metodología usada para llevar a cabo el proyecto
y se especifican las actividades que se desarrollaron en el proyecto en cada una
de las etapas propuestas por la metodología.
En el capítulo 5 se enumeran los recursos de Hardware y Software que se
utilizaron.
El capítulo 6 está dedicado al desarrollo del proyecto, el que incluye entrevistas,
tomas de requerimientos y la sistematización del Sistema de Despacho. Además
se establecen los casos de uso y se presentan los diagramas UML.
En el capítulo 7 se describe la etapa de Elaboración de la Metodología de
desarrollo usada. Además se muestra el diseño, Look & Feel de la interfaz gráfica
del sistema y su flujo de navegación.
En el capítulo 8 se alcanza la etapa de Construcción de la metodología AUP. Se
describen las configuraciones a nivel de servidores y los frameworks usados para
el proyecto. También se incluyen los modelos lógicos y físicos de la base de datos
usada.
4
El capítulo 9 muestra la etapa de elaboración de la metodología AUP.
El décimo capítulo está dedicado a las conclusiones y/o recomendaciones.
En el capítulo 11 se detalla la bibliografía.
Para finalizar en el capítulo 12 se incluyen los anexos.
5
2 Objetivos.
2.1 Objetivo general.
Desarrollar un software, basado en un algoritmo de ordenamiento de cargas,
que gestione los procesos de despacho de productos de empresa Covepa.
2.2 Objetivos específicos.
Como objetivos específicos de este proyecto se pueden individualizar los
siguientes:
- Sistematizar los procesos de despacho de productos.
- Investigar y aplicar un algoritmo de ordenamiento de cargas en camiones
de despacho.
- Planificar la configuración de carga para los camiones.
6
3. Planteamiento del Problema.
3.1 Antecedentes.
3.1.1 Definición del problema.
La empresa Covepa (especializada en la comercialización de productos
veterinarios, insumos agrícolas, ferretería, maquinaria agrícola y equipamiento
industrial para la acuicultura) lleva 31 años creciendo junto a la zona. Se
caracteriza por generar lazos de cercanía con sus clientes y tener la disposición
de atender con prontitud sus solicitudes generando lealtad y apoyo de parte de
ellos.
Covepa se caracteriza por impulsar a sus clientes a innovar ofreciéndoles
productos que incorporan nuevas tecnologías. Este impulso también lo aplican
en los procesos de la misma empresa y es de esta forma que están en constante
búsqueda de mejoras en todos los ámbitos.
Teniendo en cuenta lo anterior y aprovechando la sinergia propia de la empresa
es que se requiere sistematizar la gestión de procesos de despacho de productos
en sus distintos tipos. A saber:
- Despacho a clientes en la misma sucursal (Pedidos que el mismo cliente
retira al momento de la compra).
7
- Despacho a clientes fuera de la sucursal. Aquí los pedidos involucran
mayores volúmenes de carga. Los productos son despachados de acuerdo
a un lugar y fecha de entrega acordada con el cliente al momento de generar
la compra.
- Despacho a Sucursales. Este caso ocurre principalmente en una bodega
central de Covepa ubicada en Puerto Varas por lo que es común que muchos
de los despachos que hagan sean a otras sucursales de la empresa.
Estos despachos no son manejados de una manera formal por los encargados.
Ellos simplemente reciben un listado impreso o por correo electrónico de los
productos comprados que contiene los datos del cliente, la forma y dirección de
despacho convenido. Este es procesado por ellos mismos tomando en cuenta su
propia experiencia en la forma de ordenar carga y la distribución de productos
según su factor peso volumen.
8
3.1.2 Esfuerzos anteriores.
Existen sistemas ERP (Enterprise Resource Planning) [Wikipedia2013] que
manejan la producción, logística, distribución, inventario, envíos, facturas y
contabilidad de la compañía de forma modular. Sin embargo, la Planificación de
Recursos Empresariales o el software ERP pueden intervenir en el control de
muchas actividades de negocios como ventas, entregas, pagos, producción,
administración de inventarios, calidad de administración y la administración de
recursos humanos.
Para este caso existen módulos para distribución que podrían ser aplicables a
COVEPA (Soluciones para empresas de más de 100 empleados).
Entre los ERP más conocidos se encuentran:
a) SAP.
Es el ERP número 1 a nivel de ventas y adopción a nivel mundial. Cuenta
con clientes tan importantes como 3M, AMD, Ebay, IBM, Lenovo y
Telefónica entre muchos otros.
9
Figura 1: SAP. Estructura General y detalles de módulos.
Para acceder al Módulo SAP Shipping, que es el módulo que provee de la
funcionalidad requerida, se debe comprar el módulo completo SD ya que
tiene integración completa con otros módulos necesarios para su
funcionamiento.
En específico en su módulo SD-SHP (Sales Distribution - Shipping) es el
que provee las características de:
- Gestión de las entregas.
- Recogidas de materiales.
- Impresión de Guías de Despacho.
- Información para planificar el transporte.
- Despacho.
- Facturación.
10
Figura 2: Estructura interna del módulo SAP SD.
b) Oracle.
El módulo de ERP de Oracle que maneja los despachos es el JD Edwards
EnterpriseOne. [ORACLE2013] Este ERP es una suite de software de
planificación de recursos empresariales completo con aplicaciones
integradas que combina valor de negocio, tecnología basada en
estándares y profunda experiencia del sector en una solución empresarial.
Entre otras herramientas ofrece:
11
- Administración Financiera.
- Gestión de Proyectos.
- Administración del ciclo de vida del capital.
- Administración de Órdenes de Compra.
- Generación de Reportes.
Figura 3: Ejemplo de Flujo de procesos de Oracle JD Edwards EnterpriseOne.
12
c) Microsoft Dynamics AX para distribución.
Posee un historial probado en gestión de la distribución y de la cadena de
suministro. Puede aportar visibilidad de los datos de venta, los niveles de
inventario y la programación de envíos, lo que proporciona confianza
respecto a su capacidad para satisfacer las exigencias de los clientes.
[Microsoft2013]
Figura 4: Módulos de Microsoft Dynamics AX.
Microsoft Dynamics ERP también puede ayudar a:
- Identificar comportamientos de clientes emergentes.
- Prever mejor las tendencias futuras del mercado.
- Ajustes de inventario.
- Tomar decisiones de compra más inteligentes y reducir los costes.
- Negociar mejores condiciones con proveedores y vendedores.
- Mejorar las relaciones con los clientes.
13
Estos ERP son de comprobada eficacia en cada uno de sus módulos y están
respaldados por empresas de larga experiencia y reconocimiento internacional.
Covepa es una empresa que apoya mucho los desarrollos internos y las
soluciones de software hechas a medida, cuyos editores de código y tecnologías
sean Open Source o que tengan un costo reducido.
De esta forma el proceso de evaluación consideró las desventajas de los ERP:
- La instalación del sistema ERP es muy costosa. En un alto porcentaje de
los casos los presupuestos para instalación y puesta en marcha de un ERP son
sobrepasados.
- Los ERPs funcionan con una licencia que tiene un costo anual.
- Si se necesita una adecuación del funcionamiento del ERP al
funcionamiento de la empresa también tiene costos asociados.
- Los ERP son vistos como sistemas muy rígidos, y difíciles de adaptarse al
flujo de trabajo específico de los empleados y el proceso de negocios de algunas
compañías, este punto se cita como una de las principales causas de falla.
- Todos los ERP son propietarios y no se tiene acceso al código fuente para
hacer adaptaciones por parte del departamento de desarrollo de la empresa.
14
3.1.3 Solución Propuesta.
Covepa tiene claro que el sistema de despachos funciona aunque no existe una
forma de trabajar establecida o una serie de pasos definidos. Las actividades
para llevar a cabo la planeación y despacho se fueron estableciendo de acuerdo
a la experiencia de los encargados en cada sucursal y no se saben si son iguales
para todos.
Se sistematizarán las actividades realizadas (asimilando la experiencia de los
encargados) además de generar un proceso con actividades definidas que sea
uniforme para todos y que asista en la planeación, la asignación de recursos de
transporte para generar los despachos dependiendo de su naturaleza, fecha,
hora y lugar geográfico de entrega final.
La parte más fuerte de este proyecto tiene relación con la investigación e
implementación de un algoritmo matemático para asistir en el acomodamiento de
la carga en los camiones teniendo en cuenta factores de peso/volumen de
manera de ofrecer una sugerencia para la estiba final de los camiones en forma
eficiente. En consecuencia el dominio de desarrollo del proyecto es de
Computación Científica aunque tiene una componente menor de Ingeniería de
Software.
15
El producto final es un sistema web desarrollado en Java que genere los
despachos de acuerdo a la disponibilidad de los productos que aparecen en la
orden de despacho del cliente en bodega y la disponibilidad volumétrica de los
camiones que se asignarán para el despacho final de los productos. El sistema
hará los cálculos necesarios y entregará una sugerencia de estiba en los
camiones de acuerdo a los resultados de la evaluación del algoritmo matemático
de ordenación de carga, asistiendo de esta manera a los encargados de
despacho en su labor diaria.
3.1.4 Grupo de trabajo.
Definición el equipo de trabajo que intervendrá en el proyecto:
Tabla 1: Definición del grupo de trabajo en el proyecto.
Cliente Gerente comercial de la Empresa
Covepa el cual se encargará de
generar los requerimientos del
sistema.
Alumno Encargado del análisis, investigación,
planificación y desarrollo del algoritmo
matemático de asistencia de carga de
los camiones y del sistema final
usando la metodología de desarrollo
AUP.
16
Personal de Informática Covepa Se encargarán de ofrecer toda la
información referente a las bases de
datos e información técnica de los
puntos de trabajo y la tecnología
disponible para implementar la
solución final.
Personal encargado de despachos de Bodega Covepa
Personal del cual se obtendrá toda la
información posible en orden a
dilucidar la mejor forma de realizar los
despachos teniendo muy en cuenta
su experiencia en el cargo.
Profesora Patrocinante Profesional con años de experiencia
en la enseñanza de las Ciencias de la
Computación quien guiará en la
elaboración del documento de
seminario y aportará su experticia en
la creación de soluciones informáticas.
A continuación se muestra un diagrama simplificado de la solución:
17
Figura 5: Diagrama simplificado de Solución Propuesta.
3.2 Justificación.
3.2.1 Situación sin Proyecto.
Los encargados de la planificación de los despachos de producto no tienen un
proceso formal de trabajo que esté definido, delimitado o normado de alguna
manera. Su forma de trabajo ha sido moldeada por la experiencia empírica que
han adquirido con el tiempo de realizar dicha labor.
El flujo de trabajo consiste en recibir un listado con los productos que deben
despachar a un cliente o sucursal donde figuran los datos del destinatario,
dirección y fecha acordada de despacho. Disponen de una cierta cantidad de
18
camiones de distinto tamaño y ellos deben acomodar ese listado de productos de
la mejor forma en el volumen de carga que tienen disponible.
3.2.2 Situación con Proyecto.
La ejecución de este proyecto toma en cuenta todos los factores que considera
el cliente para llevar a cabo la realización de mejoras a sus procesos informáticos.
De esta forma se evitan todos los inconvenientes que genera la implementación
de un ERP en una empresa.
Se ofrece una solución a la medida y que toma en cuenta la experiencia de los
empleados que llevan años haciendo su trabajo de la forma que les da buenos
resultados. Así mismo se contribuye a generar una sistematización del proceso
que se realiza y se proponen mejoras para la distribución de la carga en los
camiones además de generar los despachos considerando las características de
la carga y espacio disponible.
Con el encapsulamiento del algoritmo matemático de asistencia de carga el
Departamento de Informática podría implementar su uso en otras áreas de la
empresa que tienen pueden ser susceptibles de mejorar tales como las bodegas
de almacenamiento.
19
3.3 Delimitación.
Para el desarrollo del Sistema de Gestión de Procesos de Despacho (SIGEDES)
de productos se consideran las siguientes delimitaciones:
- Para generar una solución que integre la experiencia de los empleados se
deben realizar entrevistas las cuales se harán por un espacio no mayor a una
semana.
- Se trabajará con una base de datos de muestra que será modificada para
que ofrezca los datos necesarios para el funcionamiento del algoritmo
matemático de asistencia de carga.
- Los datos usados para el sistema serán proporcionados por Covepa y
serán ajustados para que puedan ser procesados con los fines indicados.
- Los datos de volumen usados considerarán figuras geométricas de 6 caras
llamados ortoedros (cuerpos geométricos "en forma de caja", en la que todos sus
ángulos - en cada cara -, son ángulos rectos) para la simplificación del cálculo
del volumen de cada ítem. Por ejemplo un saco de alimento para perros no es un
ortoedro pero se lo considerará como tal.
- El resultado final esperado es una propuesta de distribución de la estiba
de la carga en el volumen de uno o más camiones con rampa abierta disponibles
20
para el despacho de los productos. Este resultado no considera la distribución
uniforme de los pesos de la carga en el camión (carga contrapesada).
- El encapsulamiento del algoritmo matemático y su funcionamiento está
delimitado al uso de camiones sin que esto signifique que no pueda ser
modificado en forma posterior para otros usos dentro de la empresa.
- Si los volúmenes de despacho sobrepasan el volumen disponible para su
estiba no se aplicará el algoritmo matemático.
21
4. Metodología.
La metodología que se usará será AUP (Agile Unified Process). Esta es una
versión simplificada de la metodología creada por IBM: RUP.
AUP describe una forma simple y fácil de entender el desarrollo de software
empresarial usando técnicas y conceptos ágiles que son heredados de RUP.
Incluye técnicas de desarrollo ágiles tales como Test Driven Development (TDD)
y Agile Model Driven Development (AMDD) entre otras. [AMBLER2012]
La figura 6 grafica el ciclo de vida de AUP. Describe las fases y disciplinas que
son de naturaleza iterativa y se repetirán tantas veces como versiones
incrementales sean necesarias para completar el desarrollo completo del
proyecto:
Figura 6: Ciclo de vida de AUP.
22
En la metodología AUP establecen 4 fases de consecutivas:
1. Conceptualización: Su objetivo es obtener una comprensión del alcance
del nuevo sistema, tanto del cliente como del equipo de desarrollo, y
definir una o varias arquitecturas candidatas para el mismo.
2. Elaboración: En esta etapa el equipo de desarrollo se ocupa en
profundizar la comprensión de los requisitos del sistema y en validar la
arquitectura.
3. Construcción: Durante esta fase el sistema es desarrollado y probado por
completo en ambiente de desarrollo usando los datos de prueba
4. Transición: el sistema es sometido a pruebas de validación.
Estas fases se pueden repetir en varias iteraciones a lo largo del desarrollo del
proyecto.
4.1 Actividades de la metodología AUP.
En la tabla 2 se detallan las actividades a realizar en cada una de las etapas de
la metodología:
23
Tabla 2: Actividades para este proyecto usando la metodología AUP.
Metodología AUP
Fase Actividades
Conceptualización Toma de requerimientos del cliente tomando en cuenta
las condiciones actuales de despacho.
Realización de entrevistas con encargados de despacho
para detectar el patrón de trabajo.
Reuniones con el cliente donde se establece un proceso
claro que sistematice el despacho y detalle las reglas de
negocios involucradas.
Generar los casos de uso necesarios como fruto de esa
sistematización del despacho.
Elaboración Identificar los riesgos técnicos del proyecto.
Validar la arquitectura del sistema en base a los
requerimientos.
Elaborar un prototipo de la interfaz de usuario con las
pantallas principales y establecer el “look and feel”
básico de la aplicación.
Investigar y elegir un algoritmo matemático que evalúe
la mejor manera de ordenar la carga en los camiones
destinados para despacho a clientes.
Construcción Configurar un servidor de versiones para asegurar las
buenas prácticas del desarrollo de software y como
24
medida precautoria para respaldar el código en sus
distintas etapas de desarrollo.
Configuración de un servidor de bases de datos.
Adecuar las tablas de la base de datos existente que se
son usadas para el proceso de despacho.
Poblar la base de datos existente con los nuevos
atributos necesarios para ser usados en las pruebas del
algoritmo matemático.
Implementar el algoritmo matemático.
Generar pruebas contantes para controlar la pertinencia
de los resultados entregados por algoritmo matemático
de estiba de cargas.
Transición: Testing final de la aplicación.
Administración de la configuración final de la aplicación.
25
5. Recursos.
5.1 Hardware.
El hardware utilizado se detalla en la tabla 3.
Tabla 3: Hardware
Hardware
Notebook HP G56-127NR.
Procesador: AMD V140 @ 2.3GHz, 64 Bit
RAM: 5GB
Disco Duro: 250GB 5400 RPM (Interno)
Disco duro Externo LG de 1 TB para respaldos manuales.
Este equipo fue usado en todas las etapas del desarrollo de la tesis. Inicialmente
tenía sólo 2 GB de RAM, pero cuando se instaló del IDE de desarrollo Netbeans
se notó que este demoraba mucho en compilar el proyecto por lo que se optó por
comprar un módulo de 4 GB para mejorar este aspecto del desempeño del
equipo.
26
Adicionalmente al respaldo de código en el servidor SVN se respaldaron los
documentos de investigación en un disco duro externo para mantener una copia
de seguridad adicional a la local.
5.2 Software.
En la tabla 4 se detalla el Software usado para llevar a cabo el proyecto:
Tabla 4: Software
Software
Java JDK 7u21: kit de desarrollo para Java en su versión para
Windows de 64 bits.
Netbeans 7.4: es un entorno de desarrollo integrado libre,
hecho principalmente para el lenguaje de programación Java.
Existe además un número importante de módulos para
extenderlo. NetBeans IDE es un producto libre y gratuito sin
restricciones de uso.
Servidor Subversion: es un sistema de control de versiones
diseñado específicamente para reemplazar al popular CVS. Es
software libre bajo una licencia de tipo Apache/BSD. Se le
27
conoce también como svn por ser el nombre de la herramienta
utilizada en la línea de comando.
Para conectarse el servidor SVN en se usó el plugin integrado
de conexión que incluye Netbeans.
Java DB: es un servidor de base de datos transaccionales
basados en el estándar, provee seguridad, soporte para SQL,
para la API JDBC, y para la tecnología Java EE es una
distribución de Apache Derby soportada por SUN.
Apache Tomcat 7.0.41.0: funciona como un contenedor de
servlets desarrollado bajo el proyecto Jakarta en la Apache
Software Foundation. Tomcat implementa las especificaciones
de los servlets y de JavaServer Pages de Sun Microsystems.
GlassFish Server 3.1.2.2: servidor de aplicaciones de software
libre desarrollado por Sun Microsystems, compañía adquirida
por Oracle Corporation, que implementa las tecnologías
definidas en la plataforma Java EE y permite ejecutar
aplicaciones que siguen esta especificación.
MOEA Framework: Framework compatible con Java que
provee los métodos matemáticos para realizar la planeación de
la carga de camiones.
28
Enterprise Architect: es una herramienta visual para el
modelamiento y diseño basado en OMG UML. Esta plataforma
suporta el diseño y la construcción de sistemas de software y
modelado de procesos de negocios. Esta herramienta fue usada
para el modelamiento de los Diagramas de Casos de uso.
Se usará Java ya que es un lenguaje orientado a objetos que se ajusta a la
problemática del proyecto y además provee de portabilidad en distintos
dispositivos y plataformas, una característica muy necesaria en la actualidad.
Otro motivo muy poderoso para usar este lenguaje de programación es el hecho
que se usa para el desarrollo de software al interior del Departamento de
Informática de Covepa por lo que los desarrolladores ya están familiarizados con
él.
29
6. Desarrollo del proyecto
El desarrollo del proyecto fue estructurado siguiendo la Metodología AUP. A
continuación se detallan cada una de sus 4 etapas principales.
6.1 Conceptualización.
6.1.1 Entrevistas y toma de requerimientos.
Se entrevista al jefe de bodega de la sucursal de Covepa en Puerto Varas que
además es el encargado de los despachos de productos. Se eligió esta sucursal
debido a que es la Bodega Principal de la empresa donde la mayoría de los
productos llegan y por lo tanto es la sucursal que presenta todos los casos
particulares de despacho.
6.1.2 Datos recopilados en la entrevista.
Se consideran todos los procesos de venta realizados y se pone atención desde
la recepción de los datos para ejecutar los despachos cuando sea pertinente.
Existen varias formas de recibir la información de los productos a despachar, las
cuales, se presentan en la tabla 5:
30
Tabla 5: Recepción de listado de productos.
Formas de recepción de listado de productos
Facturas con detalle de productos a despachar.
Fax con detalle de productos a despachar.
Mail con detalle de productos a despachar.
Orden de Compra con detalle de productos a despachar.
Dependiendo de las necesidades del cliente y la empresa, la entrega del producto
puede hacerse en las siguientes modalidades:
Tabla 6: Modalidades de entrega de listado de productos.
Modalidades de entrega de listado de productos
Despacho a Cliente en la misma sucursal: El cliente
personalmente retira los productos en la sección de despacho de
la bodega y se los lleva con sus propios medios.
Despacho a cliente fuera de la sucursal: El cliente espera que
se le envíen los productos adquiridos a una dirección que él
determina.
31
Despacho por Traslado a otras Sucursales: Se despachan
productos a otras sucursales de la misma empresa.
6.1.2.1 Despacho a cliente.
Este es el tipo de despacho más simple de hacer ya que es el mismo cliente quien
retira los productos que compró en bodega. De esta forma lo que se hace es
entregar los productos adquiridos al cliente y hacer la correspondiente
actualización de las existencias. En este caso no se aplica el algoritmo
matemático de ordenamiento de carga.
6.1.2.2 Despacho diferido a cliente.
En este tipo de despacho el cliente compra los productos y acuerda con el
vendedor que se los despache a una cierta dirección en un día y rango horario
determinado.
El encargado de despachos de esa sucursal es quien programa la distribución de
los productos en los camiones que tiene disponibles ese día. La carga es
ordenada de acuerdo a la experiencia de los cargadores de los camiones.
32
6.1.2.3 Despacho a Sucursales (STM: Solicitud Traslado Materiales).
Estos despachos se hacen a otras sucursales de la empresa y se rigen por un
plan de despacho programado a lo largo de la semana desde la bodega principal
en su mayoría de las veces. En este caso se realiza a través de una Solicitud de
Traslado de Materiales (STM) que genera una guía de despacho, la cual, es
generada por las sucursales. El Jefe de Bodega es quien decide, basado en los
valores máximos y mínimos de stock en la sucursal de destino, qué productos y
en qué cantidades son enviadas a las sucursales. Este proceso queda fuera del
proyecto y se considera el documento de despacho final generado por él como
entrada al sistema.
6.1.3 Datos relevantes para el despacho de productos.
En reunión con el Jefe de Bodega, quien además es el Encargado de Despachos
de Puerto Varas se establecen que los datos que presentan mayor importancia
para llevar a cabo los despachos son los que se detallan a continuación:
33
Tabla 7: Datos del cliente
Datos del cliente
Nombre del cliente
Rut
Dirección del cliente
Teléfono: Fijo/Móvil
Fecha de despacho
Rango horario del despacho
Tabla 8: Datos del camión
Datos del camión
Nombre de la empresa de transporte
Patente del camión
Patente de la rampa
Nombre del chofer
Rut del chofer
Teléfono móvil del chofer
Nombre del dueño del Camión
Celular del dueño del Camión
Carga Máxima
Largo
34
Ancho
Alto
Tabla 9: Datos de cada artículo
Datos del artículo
Código
Nombre
Restricción
Ancho
Largo
Alto
Volumen
Peso
6.1.4 Reuniones para fijar los requerimientos.
Desde un principio, en las reuniones para fijar los requerimientos, se habló de las
delimitaciones que tendría el proyecto por lo que éstas estaban acotadas a lo que
ellas estipulaban. Esto fue un poco difícil de conseguir en un comienzo ya que el
cliente siempre trata que el sistema cubra todas las necesidades que existen y
35
fue necesario dejarle en claro que por los tiempos y alcances de este proyecto
debían acotarse los requerimientos para que puedan ser cumplidos en el plazo
que se tenía. Entendido esto las reuniones fueron más productivas para los
propósitos del proyecto.
Las reuniones de toma de requerimientos a nivel global, esto quiere decir para
fijar los objetivos macros del sistema, fueron hechas con el Gerente de
Administración y Finanzas y las reuniones para ver el ámbito más detallado en
terreno fueron, como ya se ha mencionado anteriormente, con el Jefe de Bodega
de Puerto Varas.
Como resultado de esas reuniones se generó la especificación de los
requerimientos que a continuación se presentan.
6.1.5 Toma de requerimientos y especificación de los mismos.
Se requiere sistematizar los despachos con un procedimiento que permita fijar
una secuencia de actividades para cada tipo de despacho.
Esta sistematización resulta en un listado de productos para despachar y cuya
distribución, al momento de realizarse el despacho, sea asistida por el sistema.
El sistema debe entregar una propuesta de distribución en los camiones
disponibles en la sucursal.
36
Una vez realizado el despacho se almacenan los datos del despacho y se hace
la actualización del stock de productos en la bodega de la sucursal que realizó
dicho despacho.
Un requerimiento que estableció el Gerente de Administración y Finanzas en la
última reunión de toma de requerimientos tiene relación con el cambio de
prioridad que se había considerado en un principio con respecto a alcanzar el
mejor aprovechamiento volumétrico posible para el despacho de camiones fue
considerado de mediana importancia ya que lo principal para la empresa es
planificación de los despachos en forma oportuna con los clientes. Citando sus
palabras: “el cliente de Covepa está acostumbrado a recibir los artículos que
adquirió en la fecha acordada con el vendedor. Eso se lleva haciendo por mucho
tiempo y es uno de nuestros compromisos adquiridos que más valoran nuestros
clientes”.
6.2 Sistematización de los procesos de despacho.
6.2.1 Identificación de los usuarios de SIGEDES.
Los usuarios de SIGEDES son 2: Administrador y usuario. En la siguiente tabla
se especifican sus privilegios en el sistema:
37
Tabla 10: Identificación de los usuarios de SIGEDES
Tipo Usuario Privilegios
Administrador Es el encargado de mantener el sistema funcionando y tiene
todos los privilegios sobre éste.
Usuario El único usuario no administrador será el Encargado de
Despachos de cada sucursal, el cual, tiene acceso a todo el
sistema excepto a las tareas de mantención que puede
realizar el administrador.
6.2.2 Casos de uso.
6.2.3 Narrativa del caso de uso general.
Cada venta realizada genera un “pendiente de entrega” que es la información de
entrada a procesar por SIGEDES. A este listado de productos que vienen con los
datos de cantidad de cada ítem junto con su peso y su volumen individual se le
calcula el peso y volumen total del pedido completo. Esto se hace con todos los
pendientes de entrega. Cuando se va a cumplir la fecha de entrega se agrupan
todos los despachos del día y dependiendo de la disponibilidad de camiones se
aplica el algoritmo matemático de ordenamiento de carga, el cual, indica los
camiones a ocupar y genera una sugerencia de ordenamiento para cargar los
camiones. Una vez realizado el despacho se hacen las actualizaciones al stock
de la sucursal y se deja un registro de la operación realizada en la base de datos.
38
6.2.4 Generación y especificación de los casos de uso
En la tabla 11 se muestran los casos de uso desarrollados con notación UML:
Tabla 11: Casos de Uso SIGEDES
Casos de uso SIGEDES
SIGEDES-CU-01 Autenticar Usuario
SIGEDES-CU-02 Generar Bultos
SIGEDES-CU-03 Calcular Peso Volumen
SIGEDES-CU-04 Agregar Camión
SIGEDES-CU-05 Seleccionar Camiones Disponibles
SIGEDES-CU-06 Generar Plan de Despacho
SIGEDES-CU-07 Modificar Plan de Despacho
SIGEDES-CU-08 Mantener Sistema
A continuación se detallan los casos de uso detectados en las reuniones de
planificación del sistema.
39
6.2.4.1 Caso de Uso SIGEDES-CU-01 Autenticar Usuario.
Figura 7: Caso de Uso SIGEDES-CU-01 Autenticar Usuario.
40
6.2.4.2 Caso de Uso SIGEDES-CU-02 Generar Bultos
Figura 8: Caso de Uso SIGEDES-CU-02 Generar Bultos.
41
6.2.4.3 Caso de Uso SIGEDES-CU-03 Calcular Peso Volumen.
Figura 9: Caso de Uso SIGEDES-CU-03 Calcular Peso Volumen.
42
6.2.4.4 Caso de Uso SIGEDES-CU-04 Agregar Camión.
Figura 10: Caso de Uso SIGEDES-CU-04 Agregar Camión.
43
6.2.4.5 Caso de Uso SIGEDES-CU-05 Seleccionar Camiones Disponibles.
Figura 11: Caso de Uso SIGEDES-CU-05 Seleccionar Camiones Disponibles.
44
6.2.4.6 Caso de uso SIGEDES-CU-06 Generar Plan de Despacho.
Figura 12: Caso de Uso SIGEDES-CU-06 Generar Plan de Despacho.
45
6.2.4.7 Caso de Uso SIGEDES-CU-07 Modificar Plan de Despacho.
Figura 13: Caso de Uso SIGEDES-CU-07 Modificar Plan de Despacho.
46
6.2.4.8 Caso de Uso SIGEDES-CU-08 Mantener Sistema.
Figura 14: Caso de Uso SIGEDES-CU-08 Mantener Sistema.
Este caso de uso no genera ninguna pantalla de usuario ya que son actividades
de mantención externas al sistema (llevadas a cabo por el administrador) pero
que sí son necesarias de hacer tanto como para la instalación del sistema como
para la mantención de este en el tiempo.
47
6.3 Diagramas de Casos de Uso de SIGEDES.
Se hace hincapié en que la funcionalidad del sistema a nivel de Ingeniería de
Software no tiene gran complejidad por lo que los diagramas de casos de uso
que se detallan a continuación son simples.
6.3.1 Diagrama de caso de uso SIGEDES Login.
Figura 15: Diagrama Caso de Uso SIGEDES Login.
48
6.3.2 Diagrama de caso de uso SIGEDES Principal.
Figura 16: Diagrama Caso de Uso SIGEDES Main.
49
7 Elaboración
7.1 Identificación de los riesgos técnicos del proyecto.
Dentro de los riesgos técnicos de este proyecto se identificaron los siguientes:
Riesgo en la estimación del tiempo de implementación del algoritmo matemático
de ordenamiento de carga debido principalmente a que el tipo de problema al que
se enfrentó el alumno es, en la actualidad, una rama de investigación relacionada
con el CLP (Container Loading Problem). Este tipo de problemas, desde el punto
de vista computacional, tiene una complejidad NP-Dura, es decir, no se puede
obtener una solución exacta en un tiempo polinomial. CLP es un área de
investigación activa y que tiene muchas aplicaciones en el mundo real,
particularmente en el transporte de contenedores y en la industria de la
distribución. El aumento constante del precio del combustible es una gran
motivación para los transportistas a la hora de aprovechar el espacio usado en
los contenedores reduciendo el número global de viajes necesarios.
El cambio de prioridad inicial representó un duro revés en cuanto a la planificación
de los esfuerzos e importancia de las tareas planificadas, sin embargo la
metodología ágil elegida demostró su adaptabilidad al cambio de prioridad
especificado al final del punto 6.1.5.
50
7.2 Validación de la arquitectura en base a los requerimientos
La arquitectura usada en este proyecto es en 3 niveles como se aprecia en la
siguiente figura:
Figura 17: Arquitectura de Software.
La adopción del modelo de 3 capas es ventajoso debido a que el desarrollo se
puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún
cambio, sólo se ataca al nivel requerido sin tener que revisar entre código
51
mezclado. Un buen ejemplo de este método de programación sería el modelo de
interconexión de sistemas abiertos.
7.2.1 Capa de Presentación.
Como se desarrolló un sistema web basado en páginas codificadas en Java la
capa de presentación está representada por las páginas que son visualizadas por
el usuario en el navegador que utilice. En el caso de este sistema el navegador
para el cual fue optimizado el sistema fue Firefox. Este es un navegador libre
mantenido por la Fundación Mozilla. Tiene un programa de actualizaciones muy
activo lo que asegura la adopción de la última tecnología para la visualización de
contenido web.
7.2.2 Capa de lógica de Negocios.
En esta capa residen los programas que se ejecutan, se reciben las peticiones
del usuario y se envían las respuestas tras el proceso. Se denomina capa de
negocio (e incluso de lógica del negocio) porque es aquí donde se establecen
todas las reglas que deben cumplirse. Esta capa se comunica con la capa de
presentación, para recibir las solicitudes y presentar los resultados, y con la capa
de datos, para solicitar al gestor de base de datos almacenar o recuperar datos
de él. También se consideran aquí los programas de aplicación.
52
En este caso la tecnología de Tomcat, Glassfish y MOEA Framework son los que
soportan el sistema en el procesamiento de las páginas web, la aplicación web y
el cálculo matemático para obtener el ordenamiento de la carga respectivamente.
7.2.3 Capa de Acceso a Datos.
Es donde residen los datos y es la encargada de acceder a los mismos. Está
formada por uno o más gestores de bases de datos que realizan todo el
almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación
de información desde la capa de negocio.
Como ya se ha mencionado anteriormente en el apartado de Software usado de
este documento se usó Java DB como DBMS. Java DB es la distribución de Base
de Datos de código abierto Apache Derby soportaba por Oracle. Respeta los
estándares ANSI/ISO SQL a través de las APIs JDBC y Java EE. Entre sus
características destacables tenemos:
Provee todas las características y la facilidad de uso de su par
comercial.
Protección de transacciones y recuperación de errores.
Embebible en aplicaciones.
53
7.3 Prototipado.
7.3.1 Elaboración de páginas principales, navegación y Look & Feel.
La totalidad de páginas a las que el usuario podrá acceder a SIGEDES son 5:
I. Login.
II. Generar Plan de Despacho.
III. Agregar Nuevo Camión.
IV. Generar Plan de Despacho.
V. Reporte de Plan de Despacho Aprobado.
7.3.1.1 Navegación.
A continuación se presentan las pantallas que componen el sistema. Estas que
fueron diseñadas teniendo en cuenta la facilidad de uso y enfocadas en la
secuencia del proceso. De esta forma se consiguió que la navegación por las
páginas sea natural haciendo que el proceso sistematizado de actividades sea
más claro.
El flujo de las páginas es el siguiente:
54
Figura 18: Navegación por las pantallas de SIGEDES.
55
7.3.1.2 Página de Login.
Esta es la primera página que se presenta al usuario al solicitar acceso al
sistema:
Figura 19: Página de Autenticación de Usuario SIGEDES.
La funcionalidad de esta página esta descrita en la sección 6.2.4.1 Caso de Uso
SIGEDES-CU.01 Autenticar Usuario.
56
7.3.1.3 Página Generar Plan de Despacho.
Figura 20: Página Generar Plan de Despacho SIGEDES.
Para mayores detalles de funcionamiento de esta página revisar las secciones
6.2.4.2 Caso de Uso SIGEDES-CU-02 Generar Bultos, 6.2.4.3 Caso de Uso
SIGEDES-CU-03 Calcular Peso Volumen, 6.2.4.4 Caso de Uso SIGEDES-CU-04
Agregar Camión, 6.2.4.5 Caso de Uso SIGEDES-CU-05 Seleccionar Camiones
Disponibles y 6.2.4.6 Caso de uso SIGEDES-CU-06 Generar Plan de Despacho.
57
7.3.1.4 Página Agregar Nuevo Camión.
Figura 21: Página Agregar Nuevo Camión.
Para mayores detalles de funcionamiento de esta página revisar sección 6.2.4.4
Caso de uso SIGEDES-CU-04 Agregar Camión.
58
7.3.1.5 Página Plan de Despacho.
Figura 22: Página Plan de Despacho SIGEDES.
Para mayores detalles de funcionamiento de esta página revisar las secciones
6.2.4.6 Caso de uso SIGEDES-CU-06, Generar Plan de Despacho y 6.2.4.7 Caso
de Uso SIGEDES-CU.07 Modificar Plan de Despacho.
59
7.3.1.6 Página Plan de Despacho Aprobado.
Figura 23: Página Reporte PD Aprobado.
El detalle de lo mostrado en esta página está en la sección 6.2.4.6 Caso de uso
SIGEDES-CU-06 Generar Plan de Despacho.
7.3.2 Investigación y elección de algoritmos matemáticos.
El problema de CLP (Container Loading Problem) es un área de investigación
activa en la actualidad. Existen muchos enfoques, métodos matemáticos y
aproximaciones de resolución según el grado de exactitud que se quiera lograr
60
de la solución final o dependiendo de qué tanto se acote el problema en cuando
a simplificación de la realidad. En este punto el alumno debió decidir en la medida
justa cuánto se puede simplificar o idealizar la realidad de modo que el sistema
entregue una solución lo suficientemente buena como para aportar valor a la
planificación de la carga de camiones. Si se decide, por ejemplo considerar todas
las delimitaciones del apartado 3.3 de este documento en el que no se considera
la carga contrapesada tenemos, según la opinión del Director de la Escuela de
Pedagogía en Matemáticas de la UACh, sede Puerto Montt Dr. Francisco Cala,
la cual, se pasa a citar a continuación:
“(…) Si lo que me quieres consultar es si el problema puede abordarse de esta forma, te digo que con las delimitaciones que planteas (…) pues obviamente que sí. Más aun cuando no consideras el peso de cada "caja", para lograr una distribución uniforme de la carga (fundamental para aspectos de seguridad en el transporte de mercancías por cualquier vía y especialmente por carretera).
Esto último que te digo tiene que ver con el planteamiento tuyo que dice: no considera la distribución uniforme de los pesos de la carga en el camión (carga contrapesada). Desde mi punto de vista, esta delimitación deja el problema en el campo de las soluciones inservibles, poco interesantes, pues en la práctica no creo que ninguna empresa la adopte. ”
Considerando esta opinión experta del Profesor Cala, y muy realista desde el
punto de vista de la adopción de la solución, es que se optó por considerar el
apoyo humano que está involucrado dentro del problema, vale decir, la solución
propuesta no considera entregar la carga contrapesada ya que esa tarea la han
ejecutado siempre los cargadores de los camiones y no se tiene registro de
accidentes que tengan que ver con carga mal contrapesada.
61
Para hacerse una idea acabada de solución se consideraron 2 papers que
afrontan este problema desde puntos de vista distintos:
Uno es un proyecto de un fin de master [PARRA2011] en que se enfoca
la solución a una optimización del empaquetado de palets mediante el
uso de algoritmos evolutivos.
El segundo es una investigación hecha por varias personas y que se titula
“El Problema de Carga de Contenedores: una Aproximación Paralela y
Multi-objetivo”. En este paper se encuentran muchas aproximaciones de
solución usando distintos tipos de algoritmos evolutivos secuenciales y
paralelos [ARMAS2012].
De ambos papers se obtienen ideas de implementación más acabadas.
Se hicieron pruebas de implementaciones con MOEA Framework para Java. Este
framework provee una herramienta para probar la efectividad del algoritmo de
ordenamiento usado.
7.4 Funcionamiento del algoritmo matemático.
La complejidad de la solución que se maneja en esta tesis radica precisamente
en la investigación, implementación y uso práctico de un algoritmo matemático
capaz de abordar un problema, cuya solución se encuentra en pleno desarrollo
tanto en el campo de las Ciencias de la Computación como a nivel matemático.
62
La investigación realizada y la tendencia de las soluciones usadas en forma
generalizada apuntaron a que la mejor solución a este tipo de Problema de
Optimización Multiobjetivo (MOP por sus siglas en inglés Multiobjective
Optimization Problem) son los Algoritmos Evolutivos Multiobjetivo. Se llegó a esta
conclusión luego de analizar que en un problema de CLP como este pueden tener
múltiples ordenamientos factibles de ser los más óptimos desde el punto de vista
del aprovechamiento volumétrico del espacio de carga. Dicho de otra forma es
posible que los resultados obtenidos en dos ejecuciones distintas difieran sólo un
poco y que en la práctica ambas soluciones sean lo suficientemente buenas como
para ser implementadas. Es así que se puede generar un pool de resultados
aceptables luego de varias ejecuciones para el mismo conjunto de ítems a cargar.
De esta forma se trabaja con un conjunto de resultados máximos y mínimos de
una única función que engloba todos los objetivos del problema. Este conjunto
es llamado Pareto-óptimo y su imagen en el espacio objetivo es llamado Frente
de Pareto [GOLDBERG1989].
En la siguiente imagen se grafica el Frente de Pareto para un problema de 2
objetivos (bi-dimensional) donde el trazo grueso representa el frente de Pareto y
el área sombreada es la imagen de la función objetivo. Se puede observar que
para cualquier punto de la zona T no existe ningún otro punto que mejore un
objetivo sin empeorar el otro por lo que el Frente de Pareto proporciona siempre
las mejores soluciones en los problemas de optimización. Por ejemplo, para el
punto p3 se puede trazar la vertical hasta encontrar un punto de corte p1 en ese
63
eje, el cual, representa siempre la mejor solución Pareto-óptima en ese punto. Si
se toma un punto p1 y p2 se observa que para P1 mejora f2, pero a costa de
empeorar f1.
Figura 24: Ejemplo de Frente de Pareto.
Los algoritmos evolutivos (Evolutionary Algorithms - EAs) han demostrado ser
especialmente adecuados para la optimización Multiobjetivo (Multiobjective
Evolutionary Algorithms - MOEA). Con la aplicación de MOEAs en forma
creciente en los problemas reales de optimización es necesario mejorar el
desempeño de los mismos para asegurar que sean aplicables a los problemas
de complejidad ascendente. Para esto es necesario incorporar el desarrollo del
64
paralelismo al diseño de estos algoritmos por lo que finalmente se usaron
pMOEAs (parallel Multiobjective Evolutionary Algoriths) para mejorar la
capacidad de búsqueda de los MOEAs.
7.4.1 Paralelización del algoritmo Evolutivo.
Para generar una solución óptima es necesario conocer el Frente de Pareto, el
cual, puede ser muy costoso de obtener desde el punto de vista computacional o
incluso imposible, en especial en problemas de ingeniería. Por lo tanto lo que se
pretende es obtener un buena aproximación lo más cerca del frente Pareto-
óptimo verdadero.
La integración de la computación paralela y la computación evolutiva da origen a
los algoritmos evolutivos paralelos Multiobjetivo (pMOEAs). Su uso provee
ventajas ya que une las características propias de los MOEAs con las ventajas
del cómputo paralelo. Básicamente los MOEAs intentan buscar soluciones tan
buenas o mejores que su contraparte secuencial en menos tiempo y/o explorar
un espacio más amplio de soluciones.
Los modelos de paralelización de EAs más importantes son:
Modelo Maestro-Esclavo.
Modelo de difusión.
65
Modelo de Islas.
En el modelo maestro esclavo son éstos los que realizan el cálculo de la función
objetivo y el maestro se encarga de distribuir el cómputo entre los esclavos y la
ejecución de los operadores evolutivos.
Figura 25: Modelo Maestro Esclavo.
Al acelerar el cómputo de la función objetivo, este modelo posibilita realizar más
generaciones de un algoritmo secuencial en el mismo tiempo. Así, el modelo
maestro esclavo permite la explotación de un espacio de búsqueda mayor en un
tiempo dado, por lo que se obtienen mejores aproximaciones en comparación a
un algoritmo secuencial
El modelo de difusión considera conceptualmente a una única población con
pocos individuos. Este modelo supone que el cruzamiento entre distintas
subpoblaciones llevará a buenas soluciones, las que se encuentran distribuidas
en diferentes áreas al considerar toda la población. Así, en este modelo se
66
necesita de alguna estructura que restrinja la selección y recombinación entre
elementos encontrados en ciertas subpoblaciones.
El modelo de paralelización usado fue el de islas, el cual, está basado en el
fenómeno natural de que las poblaciones se encuentran en islas y está
relativamente aisladas la unas de las otras [ALBA2005].
Los pMOEAs basados en este modelo se denominan MOEAs de multipoblación
o distribuidos. La principal característica de los pMOEAs basados en el modelo
de islas es que los individuos de una población particular pueden migrar de forma
ocasional a alguna otra.
Conceptualmente, en el modelo de islas, una población se divide en un número
de poblaciones separadas e independientes. Los diferentes operadores
evolutivos trabajan en cada isla, lo que implica que las distintas poblaciones se
encuentran buscando en regiones diferentes del espacio de búsqueda.
Cada isla también podría tener distintos parámetros así como diferente estructura
de MOEA. Además, individuos de una isla podrían migrar a otra isla de acuerdo
a algún criterio definido.
Los distintos procesos que intervienen en la búsqueda de soluciones pueden
comunicarse entre sí utilizando distintas topologías de interconexión, tanto
lógicas como físicas. [VONLUCKEN2003]
67
El modelo de islas requiere la selección de políticas de migración que señalen
entre otras:
la manera en que los individuos migrarán.
el número de migrantes.
la frecuencia de migración.
de dónde se seleccionarán los elementos a migrar y cómo se
realizará el reemplazo de los elementos en una población por los
migrantes provenientes de otras poblaciones.
los distintos parámetros y algoritmos a utilizar en cada una de las
diferentes islas.
7.4.2 Funcionamiento General del Algoritmo Evolutivo.
Para conseguir la comprensión de la idea general del funcionamiento de un
algoritmo evolutivo se describen los seudocódigos en forma sencilla pero
detallada. Como entrada a la función es necesaria la introducción de parámetros
de configuración tales como el tamaño de la población, la cantidad de padres o
el número de hijos a crear. La salida queda indicada con la sentencia Return
puede ser un frente de soluciones encontradas o la mejor solución.
68
El seudocódigo de la siguiente tabla muestra que un algoritmo evolutivo mantiene
en todo momento a la población (pool de soluciones a un problema que se intenta
resolver) las cuales se relacionan entre sí en un marco competitivo (selección y
actualización):
Tabla 12: Funcionamiento general de un algoritmo Evolutivo.
Variables Locales Pob, Hijos, Padres: Arrays de Individuos
Pob ← IniciarPoblacion(TamañoPob) While NOT TerminacionEA() Pob ← RealizarMutacion(Pob); Padres ← SeleccionarNMejores(Pob); Hijos ← Reproducir(Padres);
Actualizar Población(Pob, Hijos); If Convergencia(Pob) Then ReiniciarPoblacion(Pob); Return Mejor Solucion o frente
69
7.4.2.1 Inicio de la Población.
Esta es la primera función requerida en el procedimiento principal del EA:
Tabla 13: Función orientativa para el inicio de la función (Iniciar población).
Variables Locales Individuo: individuo Pob: Array de Individuos
For j ← 1 To TamanoPob Individuo ← IndividuoIngresado(); Optimizador(Individuo); Pob(j) ← Individuo; Return Pob
Esta función se encarga de ingresar los individuos (ítems a cargar en los
camiones) y en cada individuo se emplea un optimizador, el cual, es un operador
de mutación “dirigido” característico de los EAs. Funciona de la siguiente forma:
Si el individuo ha mejorado la modificación, se guarda, en caso contrario ésta se
elimina. Se muestra el funcionamiento de este operador en la tabla 14. La función
F es la función guía o función de evaluación, de mérito o de aptitud, la que se
encarga de evaluar cuán bueno es el individuo pasado por parámetro. Esta
función se incluye ya que es obligatoria en cualquier algoritmo de optimización
ya que es la que mueve y hace evolucionar la solución propuesta final. Cabe decir
que la función de optimización no siempre es la misma ya que esta varía
dependiendo del tipo de problema que se quiera resolver.
70
Tabla 14: Algoritmo optimizador genérico (Procedimiento Optimizador (Individuo)).
Variables Locales nuevo: individuo
Repeat nuevo ← AplicarOperador(Individuo); If F(nuevo) es mejor que F(Individuo) Then Individuo ← nuevo; Until TerminacionOptimizadorLocal(); Return Individuo
El optimizador opera con una solución al problema elegida al azar y sobre ella
realiza una mutación, si se producen mejoras se guardan y se repite el proceso
hasta que se cumpla una cantidad de iteraciones específicas o se encuentre que
no hay una mejora en las mutaciones luego de una cantidad dada de iteraciones.
71
7.4.2.2 Selección de los mejores individuos.
La función SeleccionarNMejores (función que aparece dentro de la Tabla 12)
toma una muestra de los N Mejores individuos de la población, quienes
intervendrán en el proceso de reproducción. Para decidir qué individuo es mejor
que otro se utiliza una función guía. La selección y la actualización son las
responsables de forzar la competición entre individuos. La fase de selección de
individuos se implementa de acuerdo a una técnica de selección que ayuda a
mantener la diversidad de la población buscando una convergencia a las mejores
soluciones. El procedimiento consiste en seleccionar las soluciones no
dominadas del Frente de Pareto y pasarlas a las sucesivas generaciones
sustituyendo las peores soluciones de acuerdo a un criterio establecido. Para
este caso las peores soluciones están determinadas por aquellas que ofrecen
una mayor cantidad de camiones ocupados por despacho por lo que se descartan
aquellas con mayor número de camiones usados en su propuesta de solución.
7.4.2.3 Reproducción.
En esta fase se llevan a cabo los procesos de cooperación entre individuos al
construir nuevos empleando la información extraída del grupo de individuos
elegidos para tal fin (lista de ítems a ordenar), lo cual, recibe el nombre de
recombinación. A cada individuo se le pueden aplicar operadores de mutación y
un optimizador justo después de su nacimiento.
72
La tabla 15 muestra un algoritmo para la reproducción en la que se detalla el
funcionamiento clásico de este operador:
Tabla 15: Algoritmo general para la reproducción (Función Reproducir).
Variables Locales padre, madres, hijo: individuo
For i ← 1 To NumeroHijos padre ← ElegirPadre(poblacion); madre ← ElegirPadre(poblacion); hijo ← Recombinar(padre, madre); OptimizadorLocal(hijo); Hijos(i) ← hijo; Return Hijos
7.4.2.4 Convergencia del algoritmo y reinicio poblacional.
El reinicio es otro componente básico de los EAs ya que dependen de éste para
que se haga un buen uso de los recursos computacionales o se desperdicien al
explorar soluciones de una población con una gran similitud entre todos los
individuos. Esto se conoce como convergencia del algoritmo evolutivo y se
cuantifica utilizando medidas de la Teoría de la Información como la de Shannon
por ejemplo [Davidor1992] la que plantea que cuando la entropía cae bajo cierto
73
umbral, los individuos de la población se sustituyen por otros pudiendo conservar
algunos individuos de la población inicial en la nueva población.
En la tabla 16 se muestra cómo se guardan primero algunos individuos de la
población actual en la nueva para luego llenar los espacios con nuevos individuos
ingresados para el ordenamiento.
Tabla 16: Algoritmo orientativo para el reinicio poblacional.
For i ← 1 To individuos a conservar NuevaPob(i) ← SiguienteMejor(Pob); For i ← individuos a conservar + 1 To TamañoPob NuevaPob(i) ← IndividuoIngresado(); Optimizador(NuevaPob(i)); Pob ← NuevaPob
7.4.2.5 Condición general de parada.
En el caso de los EAs la condición de parada está representado por
TerminacionEA (función que aparece en la Tabla 12) donde existen 2 criterios
para ésta: a) Ejecutar el algoritmo una cantidad fija de veces las que se conocen
como generaciones o b) obligar a que pasen una cierta cantidad de veces por la
función guía. Para este caso se usó una condición de parada de 25.000
evaluaciones.
74
7.4.2.6 Obtención de Resultados.
Para obtener el mejor individuo de todas las generaciones por las que ha pasado
el algoritmo, se va almacenando en una estructura a aquel individuo con menor
número de camiones alcanzado. Así se garantiza que ninguna solución pueda
perderse luego de la aplicación de algún operador. Para finalizar se almacena en
un archivo de salida toda la información de la población de individuos final con la
configuración de cada uno guardando en este archivo las posiciones de los ítems
en los diferentes camiones.
7.5 Elección de la herramienta para el algoritmo matemático.
Luego de dejar en claro el marco teórico de lo que son los EAs y cómo funcionan
internamente se pasa a explicar el uso y funcionamiento básico del Framework
para Java usado para resolver el problema de CLP que compete a esta tesis.
Como ya se ha nombrado con anterioridad, se usó MOEA Framework como base
para proveer la sugerencia de plan de despacho de ítems en los camiones
disponibles. Este framework para Java es de uso libre y Open Source. Es usado
para desarrollar y experimentar con MOEAs y otros algoritmos de optimización
multiobjetivo de propósito general. MOEA Framework proporciona soporte para
algoritmos genéticos, evolución diferencial, optimización de enjambre de
partículas, programación genética, evolución gramatical y más. Un número de
algoritmos son proporcionados listos para ser usados como NSGA-II, ε-MOEA,
75
GDE3, y MOEA/D, proveyendo además las herramientas necesarias para
diseñar, desarrollar, ejecutar y testear estadísticamente los algoritmos de
optimización. [MOEA2013]
7.5.1 Entendiendo el funcionamiento de MOEA Framework
Para hacer uso de las herramientas y los algoritmos internos que posee este
framework es necesario usar 3 clases de java [ManualMOEA2013] que manejan
internamente todas las características que esta herramienta ofrece:
I. Executor (Ejecutor).
II. Instrumenter (Instrumentador).
III. Analizer (Analizador).
7.5.1.1 La clase Executor.
Es responsable de construir y ejecutar las pasadas de un algoritmo. Una pasada
requiere 3 piezas de información: 1) el problema; 2) el algoritmo usado para
resolverlo; y 3) el número de funciones objetivo asignadas para resolver el
problema. El siguiente código muestra cómo se pasan estos 3 parámetros al
Executor.
76
Tabla 17: Paso de los 3 parámetros básicos necesarios al Executor.
1 2 3 4 5
NondominatedPopulation result = new Executor() .withProblem("UF1") .withAlgorithm("NSGAII") .withMaxEvaluations(10000) .run();
La línea 1 crea una nueva instancia del Executor, las líneas 2, 3 y 4 fijan el
problema, el algoritmo y el máximo número de evaluaciones de la función
objetivo, respectivamente. En el ejemplo se usa el problema UF1 con el algoritmo
NSGAII. La última línea ejecuta el experimento y retorna el set de resultados
aproximados.
Una vez que la ejecución del experimento termina se puede acceder a los
resultados. La primera línea del código de la tabla 18 muestra el set de
aproximación, el cual, es una NonDominatedPopulation que es asignada a la
variable result. Este set de aproximación contiene todas las soluciones Pareto-
óptimas producidas por el algoritmo durante su ejecución. El siguiente trozo de
código muestra los dos objetivos por consola:
77
Tabla 18: Acceder a los resultados entregados por el framework.
1 2 3 4
for (Solution solution : result) {
System.out.println(solution.getObjective(0) + " " + solution.getObjective(1)); }
La línea 1 itera sobre cada solución en el resultado. Una solución guarda las
variables de decisión, los objetivos, las constantes y cualquier atributo relevante.
Las líneas 2 y 3 muestran cómo los valores objetivos pueden ser obtenidos desde
una solución.
El código Java completo de este ejemplo se encuentra en la letra A) del anexo
de este documento.
7.5.1.2 La clase Instrumenter.
MOEA Framework provee 2 herramientas para analizar el comportamiento de los
algoritmos a lo largo de su ejecución, estas son las Runtime Dynamics, la cual
graba cómo la calidad de la ejecución varía además de otros elementos de
cambio, y End of Run Analysis que se enfoca en el resultado final de una
ejecución completa y compara el desempeño relativo de varios algoritmos.
La herramienta de análisis Runtime Dynamics es usada por la clase Instrumenter,
la cual, tiene este nombre debido a su habilidad de agregar instrumentación al
78
algoritmo, o sea, provee piezas de código que graban información. Los rangos
de datos que se pueden ser recolectados por la clase Instrumenter son:
I. Elapsed time.
II. Population size / archive size.
III. The approximation set.
IV. Performance metrics.
V. Restart frecuency.
El Instrumenter trabaja mano a mano con el Executor para recolectar los datos.
El Executor es el responsable de configurar y correr el algoritmo y también
permite al Instrumenter grabar toda la información necesaria mientras el
algoritmo está en ejecución. Para comenzar a recolectar datos usando Runtime
Dynamics se debe crear y configurar una instancia del Instrumenter:
Tabla 19: Recolectar datos con el Instrumenter.
1 2 3 4
Instrumenter instrumenter = new Instrumenter() .withProblem("UF1") .withFrequency(100) .attachAll();
79
La línea 1 crea una instancia del Instrumenter, la línea 2 especifica el problema y
la línea 3 fija la frecuencia en la que los datos son grabados, en este ejemplo los
datos son grabados cada 100 evaluaciones. Finalmente en la línea 4 indica que
todos los datos disponibles deben ser recolectados.
Luego, se debe crear y configurar la instancia del Executer con el siguiente trozo
de código:
Tabla 20: Creación y configuración de una instancia del Executor
1 2 3 4 5 6
NondominatedPopulation result = new Executor() .withProblem("UF1") .withAlgorithm("NSGAII") .withMaxEvaluations(10000) .withInstrumenter(instrumenter) .run();
Este trozo de código es similar a los ejemplos previos del Executor pero incluye
la línea 5, la cual, hace que todos los algoritmos que ejecute sean instrumentados
con la instancia del Instrumenter. Una vez que el Instrumenter está fijado y el
algoritmo está configurado se puede correr el código en la línea 6.
Cuando la ejecución termina se puede acceder a los datos recolectados por el
Instrumenter. Los datos son guardados en un objeto Acumulator. Este puede ser
accedido mediante la siguiente línea de código
80
Tabla 21: Acceder a los datos guardados en el Acumulator.
1
Accumulator accumulator = instrumenter.getLastAccumulator();
Un Acumulator es similar a un mapa en el que se guardan pares clave-valor. La
clave identifica el tipo de datos guardados. Sin embargo, en vez de guardar un
solo valor, el Acumulator guarda varios valores, uno por cada punto de datos
recolectado por el Instrumenter. Los datos pueden ser extraídos del Acumulator
con la siguiente iteración.
Tabla 22: Obtener datos desde el Acumulator.
1 2 3 4
for (int i=0; i<accumulator.size("NFE"); i++) { System.out.println(accumulator.get("NFE", i) + "\t" + accumulator.get("GenerationalDistance", i)); }
Con este código se obtienen 2 columnas de datos: el número de evaluaciones de
la función objetivo y el indicador de desempeño de la distancia generacional.
El código Java completo de este ejemplo se encuentra en la letra B) en el anexo
de este documento.
81
Hay algunos cuidados que es necesario tener al usar el Instrumenter:
Primero, instrumentar un algoritmo y recolectar todos los datos ralentizará la
ejecución de los algoritmos y aumentará significativamente el uso de memoria,
por lo que se recomienda limitarse a recolectar los datos que se consideren
importantes y omitir el resto. Esto se logra reemplazando el parámetro attachAll
por attachGenerationalDistanceCollector.
Segundo, si el uso de memoria excede la que puede ser direccionada por Java
aparecerá una OutOfMemoryExceptions, por lo que será necesario cambiar la
cantidad de memoria que puede direccionar Java especificando el comando
–Xmx en la línea de comandos cuando la aplicación Java se ejecute. Por ejemplo
este comando ejecutará un programa Java con 512 MB de memoria disponible:
java -Xmx512m -classpath ...
Si se configura el uso de toda la memoria RAM del con la opción –Xmx y aún se
obtiene la excepción OutOfMemoryExceptions entonces será necesario limitar
la frecuencia de recolección de datos o restringir los datos recolectados
innecesarios.
7.5.1.3 La clase Analyzer.
El Analyzer provee End of Run Analysis. Este análisis al final de la ejecución se
enfoca en el resultado de la aproximación del Frente de Pareto y cómo es
82
comparado con un resultado conocido. El Analizer es útil para comparar
estadísticamente los resultados obtenidos por 2 o más algoritmos o también del
mismo algoritmo pero con diferente configuración de sus parámetros. Para
comenzar a usar el Analizer se debe crear y configurar una instancia de él como
se muestra a continuación.
Tabla 23: Inicializar una instancia de Analyzer.
1 2 3 4
Analyzer analyzer = new Analyzer() .withProblem("UF1") .includeAllMetrics() .showStatisticalSignificance();
Primero se ejecuta el constructor de Analyzer en la línea 1, luego en la línea 2 se
fija el problema (al igual que en Executor e Instrumenter). La línea 3 le dice al
Analyzer que evalúe todas las métricas de desempeño disponibles. Finalmente
en la línea 4 se habilita la comparación estadística de los resultados.
El siguiente trozo de código muestra cómo el Executor es usado para correr los
algoritmos NSGA-II y GDE3 para 50 iteraciones y se guardan los resultados en
el Analyzer. Ejecutar para múltiples iteraciones (o seeds) es importante para la
generación de resultados estadísticos.
83
Tabla 24: Ejemplo de uso del Executer y Analyzer
1 2 3 4 5 6 7 8 9
Executor executor = new Executor() .withProblem("UF1") .withMaxEvaluations(10000);
analyzer.addAll("NSGAII", executor.withAlgorithm("NSGAII").runSeeds(50));
analyzer.addAll("GDE3", executor.withAlgorithm("GDE3").runSeeds(50));
En las líneas 1 - 3 se crea el Executor, en forma similar a los ejemplos anteriores
excepto que aún no se ha especificado el algoritmo. Las líneas 5-6 ejecutan
NSGA-II, se fija este algoritmo, se itera 50 veces y se agregan los resultados de
las 50 iteraciones al Analyzer. En las líneas 5-8 se ejecuta el algoritmo GDE3 y
se agregan los resultados al Analyzer. Igualmente en las líneas 8-9 se ejecuta
GDE3 y se guarda en el Analyzer. En las líneas 5 y 8 se pasa un string como
primer algumento para addAll. Esto genera un nombre para las muestras
recolectadas.
Finalmente se puede mostrar el resultado de los análisis con el comando
analyzer.printAnalysis();
El código Java completo de este ejemplo se encuentra en la letra C) en el anexo
de este documento.
Es necesario mencionar que se han mostrado ejemplos básicos del Executor,
Instrumenter y Analyzer que sirven para ilustrar el funcionamiento básico de
84
MOEA Framework, sin embargo esta herramienta provee otras opciones
sofisticadas, las cuales, están documentadas en su API [MOEAAPI, 2013]
disponible en el paquete de código fuente en su sitio oficial. Estas opciones no
se incluyen en la documentación de esta tesis ya que escapan del alcance de la
misma.
85
8 Construcción.
8.1 Configuración de un servidor de versiones.
Un servidor de versiones es de gran importancia en el desarrollo de proyectos ya
que permite ir generando un registro histórico del avance del proyecto. Además
de ofrecer un respaldo del código fuente proporciona, como su nombre lo indica,
muchas versiones del código del proyecto por lo que si en medio del desarrollo
se llega a un punto donde el código se vuelve demasiado complejo es posible
volver a una versión anterior y comenzar desde ese punto a desarrollar el código
con otro enfoque de solución.
Luego de investigar varias alternativas de solución para implementar un servidor
de versiones entre las que se cuentan CVS, Subversion y GIT, se habló con el
Departamento de Informática de Covepa y ellos ofrecieron habilitar un repositorio
en el servidor de Subversion 1.7.7 usado por el área de desarrollo. Este servidor
de versiones está instalado en una máquina Linux corriendo CentOS 5.8 de 64
bits.
Cabe señalar que este servidor se pudo haber implementado en el mismo equipo
de desarrollo pero no tiene sentido hacerlo de esa forma ya que una de las
ventajas de los servidores de versiones es, entre otras, que sirva como respaldo
del código en una máquina distinta a la que se usa para el desarrollo.
86
Desde el punto de vista de la seguridad que ofrece la sala de servidores, donde
está alojado el equipo con el SVN, se tienen las versiones del código en una sala
de acceso controlado tanto física como lógicamente. La accesibilidad se podía
obtener sólo en los momentos en que el equipo de desarrollo estaba conectado
a la misma red interna de Covepa.
En la primera parte del proyecto se usó un servidor SVN. En la segunda parte del
proyecto hubo un cambio en la seguridad del departamento de Covepa por lo que
los respaldos de código se hicieron en forma semanal en un disco duro externo.
8.2 Configuración de un servidor de base de datos.
Como Gestor de base de Datos (BDMS por sus siglas en Inglés) se usó Java DB,
el cual es un servidor de base de Datos integrado al IDE de desarrollo Netbeans
y necesario para su funcionamiento. Eso representa una ventaja ya que se
elimina la necesidad de montar un servidor de base de datos externo, es fácil de
usar y provee de una base de datos lo suficientemente robusta para soportar bien
la carga del sistema.
Para su implementación es necesario crear una base de datos en el gestor
interno de Netbeans. Luego se conecta a esta base de datos con el nombre de
usuario y la contraseña establecidos en la creación de la misma. Una vez hecho
esto se ejecuta el archivo SQL con la información de las tablas y sus atributos
87
con lo que se genera la estructura interna de las tablas, las cuales quedan listas
para ingresar los datos accediendo en forma directa a los campos.
Con posterioridad se crearon los mantenedores de la base de datos por lo que
esta práctica quedó regulada.
8.3 Adecuamiento de base de datos existente.
Con el fin de tomar como entrada de datos al sistema, a nivel de bases de datos,
se consideró hacer indistinta la fuente de la información de los productos a
despachar (como resultado de una venta a cliente o como resultado de una
Solicitud de Traslado de Materiales (STM)). En la práctica, estos datos vienen de
centros de costos distintos pero a la entrada al sistema esto no tiene importancia
debido a que ambos tipos de despacho tienen los datos comunes necesarios
para poder ser procesados por SIGEDES.
En la figura siguiente se muestra una parte de la tabla ARTICU de la base de
datos de producción de Covepa:
88
Figura 26: Parte de la tabla ARTICU en la BD de producción de Covepa.
Para lograr adecuar la base de datos se tomaron todas las tablas que son de
producción y se le quitaron todos los datos que no sirven para los propósitos del
proyecto. Adicionalmente, como a estas tablas les faltan los datos de las medidas
de cada artículo para fines de cálculo volumétrico se agregan los campos largo,
ancho y alto. El peso de cada artículo, dato que es relevante para el proyecto, ya
estaba en el sistema por lo que no fue necesario agregarlo.
Posteriormente se generó el diseño lógico de las tablas para la base de datos de
pruebas.
89
Se usó la herramienta Case PowerDesigner 16.1 para modelar la base de datos
tanto en forma lógica como física. Esta herramienta permitió generar el script de
SQL el cual se ejecutó dentro de Netbeans y generó la base de datos con sus
tablas.
Como ya se mencionó anteriormente el modelamiento de la base de datos fue
hecho en Covepa por lo que el principal trabajo consistió en aislar las tablas que
sirven para el proyecto.
Figura 27: Diseño lógico de la base de datos de pruebas del proyecto.
90
Figura 28: Diseño físico de la base de datos de pruebas del proyecto.
8.4 Poblamiento de BD con los datos necesarios para el proyecto.
En general la mayoría de los datos estaban en las bases de datos a excepción
de los datos de las medidas para calcular el volumen de los artículos y la base
de datos de los camiones. Debido a esto se debió ir a terreno a medir las 3
dimensiones de algunos productos de mayor rotación en la bodega principal
ubicada en Puerto Varas.
91
Se consideraron un total de 31 productos de los que, aparte de medir sus
medidas de ancho, largo y alto, se midieron las dimensiones de los pallets en que
muchas veces se distribuyen estos productos. De esta forma cada artículo
factible de ser cargado en pallets tendrá estos datos disponibles para hacer la
planeación de la distribución.
Se da el caso que algunos artículos no tienen los datos de medidas en pallets ya
que por su alto volumen son cargados como una unidad en sí, como por ejemplo
en el caso de las fosas sépticas.
8.5 Testing.
Para testear la aplicación se hizo una simulación de uso del sistema en que se
crearon facturas con ítems a entregar para el día 20 de Diciembre de 2013. Las
facturas creadas son las siguientes:
92
Figura 29: Primera Factura para Testing.
La primera factura registra un peso Total de 9.083,5 Kg. y un volumen total de
16,492 mt3.
93
Figura 30: Segunda Factura para Testing.
La segunda factura registra un peso Total de 0 Kg. y un volumen total de 82,137
mt3. En estricto rigor el peso total no es cero, pero se lo considera así debido al
factor peso volumen usado en los despachos, vale decir, el parámetro que pone
la limitante para el transporte en este caso es el volumen y en términos prácticos
el peso de los ítems a despachar puede tomarse como un dato no relevante. Este
ejemplo fue hecho deliberadamente de esta forma para explicar este punto.
94
Figura 31: Tercera Factura para Testing.
La tercera factura registra un peso Total de 20.600 Kg. y un volumen total de
46,020 mt3.
95
Figura 32: Cuarta factura para Testing.
La cuarta factura registra un peso Total de 1.590 Kg. y un volumen total de 3,254
m3.
Tabla 25: Resumen de Pesos y Volúmenes de las 4 facturas.
Factura Peso (Kg) Volumen (m3)
Primera 9.083,5 16,492
Segunda 0,0 82,137
Tercera 20.600,0 46,020
Cuarta 1.590,0 3,254
Totales 31.273,5 147,903
96
Al tratarse de pedidos para la cuidad de Puerto Varas los camiones disponibles
allí para ese día son los siguientes:
Tabla 26: Camiones disponibles para despacho.
Patente Carga (Kg) Volumen (m3)
CV3487 28.000 87,36
HJUY76 38.000 116,48
SU6655 32.000 97,50
CVCD33 32.000 97,50
GN2853 27.000 84,24
PK6237 27.000 84,24
VC6297 30.000 91,00
Como el volumen total máximo (147,93 m3) excede la capacidad volumétrica
máxima de todos los camiones disponibles se debe separar la factura de mayor
volumen para ver dónde se puede acomodar la carga restante. Una vez hecho
esto existen 2 cargas: una de 65,766 m3 correspondiente a la suma de los
volúmenes de carga de la primera, tercera y cuarta factura y otra de 82,137 m3
que pertenece a la segunda factura por sí sola. Teniendo esto claro se puede
inferir que la carga de la segunda factura cabe perfectamente en el camión de
patentes GN2853. Considerando los valores de volumen para la carga restante
se podría decir que cabe en el camión de patente PK6237 pero esto no es posible
debido a que la carga máxima de este vehículo es de 27.000 Kg y el peso total
de la carga restante es de 31.273,5 Kg por lo que esta carga debe ser asignada
97
a cualquiera de los 2 camiones patente CVCD33 o SU6655 ya que ambos tienen
capacidad para 32.000 Kg de carga y hasta 97,5 m3.
Como se aprecia, es completamente necesario el uso de un segundo camión, el
cual, queda ocupado prácticamente con la totalidad de su capacidad de carga. Si
se considera que la gerencia de Covepa entrega más valor a la conformidad del
cliente, con respecto a la entrega oportuna de su pedido, por sobre el
aprovechamiento óptimo del espacio esta es una solución acorde con tal premisa
de funcionamiento.
Estos resultados son pruebas de ensayo sin el cotejo ni validación en terreno. En
la próxima sección de Transición y Testing final se mostrará el resultado de la
aplicación en terreno.
98
9 Transición
9.1 Testing final.
En esta etapa se considera una prueba hecha en terreno con los productos que
estaban disponibles en la bodega en ese momento y que figuraban en la tabla
ARTICULO de la base de datos de prueba con la que se trabajó. La etapa de
transición considera una prueba y testing final de la aplicación.
El testing final fue hecho bajo una situación controlada en terreno. Se recorrió la
bodega y se fueron generando facturas de despacho con los productos existentes
en bodega y en la base de datos de prueba.
Posteriormente se eligieron camiones para carga disponibles ese día. Las
facturas generadas son las siguientes:
Figura 33: Factura 1 de testing terreno.
99
Figura 34: Factura 2 de testing en terreno.
Figura 35: Factura 3 de testing en terreno.
100
Figura 36: Factura 4 de testing en terreno.
Figura 37: Factura 5 de testing en terreno.
101
Figura 38: Factura 6 de testing en terreno.
Figura 39: Factura 7 de testing en Terreno.
102
Figura 40: Factura 8 de testing en Terreno.
Figura 41: Factura 9 de testing en Terreno.
103
Figura 42: Factura 10 de testing en Terreno.
Figura 43: Factura 11 de testing en tereno.
Nota: los nombres de clientes, direcciones y números de teléfono que aparecen
es estas facturas son ficticias y no tienen ninguna relación con identidades reales.
104
Para ingresar al sistema se debe hacer a través de la página de Login:
Figura 44: Sigedes – Login.
Una vez que el usuario es autentificado correctamente se muestra la página de
Generar Plan de Despacho.
Figura 45: Sigedes – Generar Plan de Despacho (GPD).
105
En esta página el usuario selecciona la fecha de despacho y presiona en el botón
buscar. Esto genera una consulta a la base de datos por todas las facturas que
figuran para ese día (23-12-2013). El sistema consulta la base de datos y
devuelve las facturas para despachar ese día en esa sucursal.
Luego se seleccionan los camiones que están disponibles para ese día desde el
control desplegado en pantalla. Estos camiones son todos aquellos que están
ingresados en la base de datos.
Si existe un camión disponible para hacer despachos en esa sucursal y no se
encuentra ingresado en la base de datos, se puede agregar a la base de datos
de camiones para ser seleccionado y esté disponible para despachos. Para esto
se hace clic en el botón Agregar Nuevo Camión lo que despliega un formulario
con todos los campos necesarios para agregar otro a la base de datos. Cuando
se terminan de llenar todos los datos se presiona en enviar. Esta acción guarda
los datos para su posterior utilización. Una vez que se agrega un camión ya
puede ser usado en los despachos.
106
Figura 46: Sigedes – Agregar Nuevo Camión.
Una vez agregados los camiones disponibles se presiona en el botón Generar
plan de despacho. Luego del proceso de ordenamiento, que se desarrolla con el
algoritmo matemático, se genera un Plan de despacho sugerido:
107
Figura 47: Sigedes – Plan de Despacho.
Cuando el encargado de despacho revisa el Plan de Despacho y está de acuerdo
con él presiona sobre el botón Aprobar Plan de Despacho, el cual, genera un
Plan de Despacho Aprobado en que se muestra un detalle de la patente asignada
a cada número de factura, los datos del cliente y los números de teléfono del
chofer y del cliente además del nombre de este último. Se muestra además un
detalle de los ítems que tiene la factura individualizada en el encabezado.
Este informe puede ser impreso para que el personal que carga los camiones
tenga una guía de lo que deben poner en cada camión.
108
Figura 48: Sigedes – Reporte de Plan de Despacho Aprobado.
La aplicación del algoritmo matemático posibilita la generación de una sugerencia
de carga que ahorra tiempo a los encargados de despacho.
El ejercicio en terreno fue exitoso y se necesitó de un despliegue de recursos
importante para probar el sistema.
109
10 Conclusiones y/o recomendaciones.
Los problemas de CLP son un área fértil para el desarrollo y obtención de
economías de escala, no sólo a través de la optimización de espacios de
carga, sino que también es posible generar ahorros desde el punto de vista
del aprovechamiento del combustible al integrar en el despacho el uso de
georreferenciación para hacer una planeación de las rutas de entrega de la
carga considerando temas como rutas de tráfico y zonas de distribución. Esta
mejora no se implementó ya que queda fuera del ámbito de esta tesis debido
a sus delimitaciones, lo que no implica que sea un área interesante de abordar
a futuro.
Con respecto a la investigación realizada se destaca el aporte que realiza la
comunidad científica en esta área que se encuentra en pleno desarrollo y en
constante evolución. El uso de MOEA framework en esta tesis fue de gran
ayuda debido a la alta complejidad que reviste resolver un problema de CLP
codificando los algoritmos desde cero. Sin esta herramienta científica esta
tesis habría tardado muchísimo más en completarse.
La importancia de una buena documentación inicial más una adecuada toma
de requerimientos, en un proyecto de desarrollo de software, es una parte vital
y fundamental para la obtención de un sistema que cumpla con las
expectativas del cliente final y por sobretodo de los usuarios. Se recomienda
110
tomarse el tiempo, tener la paciencia necesaria y la empatía con los usuarios
finales para que éstos se sientan comprometidos con la solución que se quiere
construir para ellos. Queda como experiencia que cuando se usan actividades
inclusivas, que tomen en cuenta las recomendaciones de todos los sectores
a los cuales atañe el desarrollo del proyecto de software, se obtiene la
identificación del usuario con el software final obtenido, lo cual, ayuda a
disminuir la resistencia al cambio que produce la implementación de un nuevo
sistema informático en cualquier empresa y grupo de trabajo.
La elección de una metodología de desarrollo de software adecuada es una
decisión muy importante dentro del proyecto de desarrollo de software, debe
adecuarse al tamaño del proyecto, la cantidad de desarrolladores y las
dinámicas de grupo que se generen. La elección de una metodología ágil de
desarrollo de software como AUP fue de gran ayuda ya que se adecúo a la
naturaleza del proyecto y al no necesitar de excesiva documentación (Como
lo hace RUP) los documentos generados fueron los precisos para lograr la
mejor combinación entre toma de requerimientos y documentación y los
tiempos de desarrollo del sistema.
La experiencia en terreno indica que la utilidad de SIGEDES, como solución
de ordenamiento de carga, es relevante ya que genera despachos sugeridos
de buena calidad y que ayudan al planeamiento diario de la carga a distribuir
111
a los clientes. Además aporta a la trazabilidad de los despachos realizados lo
que le entrega un valor agregado al negocio.
112
11 Bibliografía.
[Ambler2012] The Agile Unified Process (AUP), 2012.
http://www.ambysoft.com/unifiedprocess/agileUP.html
[Microsoft2013] Microsoft Dynamix AX (ERP), 2013
http://www.microsoft.com/es-es/dynamics/erp-ax-introduccion.as
[Oracle2013] Oracle. JD Edwards EnterpriseOne, 2013.
http://www.oracle.com/lad/products/applications/jd-
edwardsenterpriseone/overview/index.html
[Wikipedia2013] Wikipedia. Sistema de planificación de recursos
empresariales, 18 de marzo de 2013.
http://es.wikipedia.org/wiki/Sistema_de_planificaci%C3%B3n_de_recursos_
empresariales
113
[PARRA2011] Proyecto fin de Magister: “Optimización de problemas
multi-objetivo de empaquetado de palets mediante algoritmos evolutivos”,
2010/2011.
http://archive-es.com/page/542457/2012-10-
28/http://repositorio.ual.es/jspui/handle/10835/809
[ARMAS2012] “El problema de la carga de contenedores: una
Aproximación Paralela y Multi-objetivo”, 2011.
http://www.congresomaeb2012.uclm.es/papers/paper_13.pdf
[GOLDBERG1989] D. E., “Genetic algorithms in search, optimization and
machine learning”. New York, Addison Wesley, 1989.
[ALBA2005] Alba E., “Parallel Metaheuristics: A New Class of
Algorithms”, Wiley, 2005.
[VONLUCKEN2003] Algoritmos Evolutivos para Optimización
Multiobjetivo, 2003.
114
[DAVIDOR1992] Davidor Y. and Ben-Kiki O., “The interplay among the
genetic algorithm operators: Information theory tools used in a holistic way”.
In R. Manner and B. Manderick, editors, Parallel Problem Solving From
Nature II, 75perators:
[MOEA2013] Página oficial de MOEA Framework.
http://www.moeaframework.org/
[ManualMOEA2013] Manual de uso, instalación y contribución de MOEA
Framework 2.0, Septiembre de 2013.
https://sourceforge.net/projects/moeaframework/files/MOEAFramework-
2.0/MOEAFramework-2.0-Manual.pdf/download
115
12 Anexos.
12 A) Ejemplo de uso una instancia de la clase Executor
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19
import java.util.Arrays; import org.moeaframework.Executor; import org.moeaframework.core.NondominatedPopulation; import org.moeaframework.core.Solution;
public class Example1 { public static void main(String[] args) { NondominatedPopulation result = new Executor() .withProblem("UF1") .withAlgorithm("NSGAII") .withMaxEvaluations(10000) .run();
for (Solution solution : result) { System.out.println(solution.getObjective(0) + " " + solution.getObjective(1)); } } }
12 B) Obtener datos desde el Acumulator.
1 2 3 4 5 6 7 8 9
10 11 12 13 14 15
import java.io.IOException; import java.io.File; import org.moeaframework.core.NondominatedPopulation; import org.moeaframework.Instrumenter; import org.moeaframework.Executor; import org.moeaframework.analysis.collector.Accumulator;
public class Example2 {
public static void main(String[] args) throws IOException { Instrumenter instrumenter = new Instrumenter() .withProblem("UF1") .withFrequency(100) .attachAll();
NondominatedPopulation result = new Executor() .withProblem("UF1")
116
16 17 18 19 20 21 22 23 24 25 26 27 28 29
.withAlgorithm("NSGAII") .withMaxEvaluations(10000) .withInstrumenter(instrumenter) .run();
Accumulator accumulator = instrumenter.getLastAccumulator();
for (int i=0; i<accumulator.size("NFE"); i++) { System.out.println(accumulator.get("NFE", i) + "\t" + accumulator.get("GenerationalDistance", i)); } }
}
12 C) Ejemplo de uso de Analyzer.
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26
import java.io.IOException; import org.moeaframework.Analyzer;} import org.moeaframework.Executor;
public class Example3 {
public static void main(String[] args) throws IOException { Analyzer analyzer = new Analyzer()
.withProblem("UF1") .includeAllMetrics() .showStatisticalSignificance();
Executor executor = new Executor()
.withProblem("UF1") .withMaxEvaluations(10000);
analyzer.addAll("NSGAII", executor.withAlgorithm("NSGAII").runSeeds(50));
analyzer.addAll("GDE3", executor.withAlgorithm("GDE3").runSeeds(50));
analyzer.printAnalysis(); }
}