Prototipo de Software para Solucionar Procesos de Decisión de Markov Implementando Algoritmo Recocido Simulado
Texto completo
(2) PROTOTIPO DE SOFTWARE PARA SOLUCIONAR PROCESOS DE DECISIÓN DE MARKOV IMPLEMENTANDO ALGORITMO RECOCIDO SIMULADO. XIMENA GALINDO RAMIREZ 20111078027 CRISTHIAN DAVID SANDOVAL PAZU 20111078105. Proyecto presentado como requisito para optar el título de Tecnólogo En Sistematización De Datos. DIRECTOR: ROBERTO EMILIO SALAS RUIZ INGENIERO DE SISTEMAS. UNIVERSIDAD DISTRITAL FRANCISCO JOSÉ DE CALDAS FACULTAD TECNOLÓGICA TECNOLOGÍA DE SISTEMATIZACIÓN DE DATOS BOGOTA D.C 2015.
(3) Nota de aceptación: _______________________________________ _______________________________________ _______________________________________ _______________________________________. TUTOR. _______________________________________ Ing. Roberto Emilio Salas. Presidente Jurado. _______________________________________ Ing. Jorge Rodríguez. _______________________________________ Ing. John Zabala. Bogotá D.C. Agosto 2015.
(4) TABLA DE CONTENIDO RESUMEN ......................................................................................................................... 1 ABSTRACT........................................................................................................................ 2 INTRODUCCIÓN .............................................................................................................. 3 1.. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN .............................. 5. 1.1. TÍTULO DEL TRABAJO ....................................................................................... 5. 1.2. TEMA ...................................................................................................................... 5. 1.3. PLANTEAMIENTO DEL PROBLEMA ................................................................ 5. 1.3.1. DESCRIPCIÓN ................................................................................................ 5. 1.3.2. FORMULACIÓN ............................................................................................. 6. 1.4. JUSTIFICACIÓN .................................................................................................... 6. 1.5. OBJETIVOS ............................................................................................................ 6. 1.5.1. OBJETIVO GENERAL ................................................................................... 7. 1.5.2. OBJETIVOS ESPECÍFICOS ........................................................................... 7. 1.6. ALCANCES Y DELIMITACIONES ...................................................................... 7. 1.6.1. ALCANCES ..................................................................................................... 8. 1.6.2. DELIMITACIONES ........................................................................................ 8. 1.7. MARCO DE REFERENCIA ................................................................................... 9. 1.7.1. MARCO TEÓRICO ......................................................................................... 9. 1.7.2. MARCO CONCEPTUAL ................................................................................ 9. 1.8. METODOLOGÍA DE DESARROLLO ................................................................ 18. 1.9. FACTIBILIDAD ................................................................................................... 19. 1.9.1. FACTIBILIDAD ECONÓMICA ................................................................... 19. 1.9.2. FACTIBILIDAD OPERATIVA .................................................................... 19. 1.9.3. FACTIBILIDAD TÉCNICA .......................................................................... 20. 1.9.4. FACTIBILIDAD LEGAL .............................................................................. 20. 1.10 CRONOGRAMA DE ACTIVIDADES ................................................................ 20 2. MODELO DE NEGOCIO ............................................................................................ 20 2.1. MODELADO DEL NEGOCIO ............................................................................. 21. 2.2. DIAGRAMAS DE PROCESO .............................................................................. 21. 2.2.1. DIAGRAMA DE PROCESOS MÓDULO INGRESAR DATOS ................. 21.
(5) 2.2.2. DIAGRAMA DE PROCESOS MÓDULO PDM .......................................... 22. 2.2.3 DIAGRAMA DE PROCESOS MÓDULO ALMACENAMIENTO DE DATOS 23 2.3. MODELO DEL DOMINIO ................................................................................... 24. 2.3.1 2.4 3. GLOSARIO DE TERMINOS ............................................................................... 25. REQUERIMIENTOS .................................................................................................... 27 3.1. REQUERIMIENTOS FUNCIONALES ................................................................ 27. 3.2. REQUERIMIENTOS NO FUNCIONALES ......................................................... 30. 3.3. DEFINICIÓN DE ACTORES ............................................................................... 30. 3.4. LISTA PRELIMINAR DE CASOS DE USO ....................................................... 31. 3.5. MODELO DE CASOS DE USO ........................................................................... 31. 3.5.1 4. DIAGRAMAS DE SECUENCIA ......................................................................... 41. 4.1.1. DIAGRAMA DE SECUENCIA MÓDULO INGRESO DE DATOS ........... 42. 4.1.2. DIAGRAMA DE SECUENCIA MÓDULO PDM ........................................ 42. 4.1.3. DIAGRAMA DE SECUENCIA MODULO ALMACENAMIENTO DATOS 43. 4.2. DIAGRAMAS DE ACTIVIDAD .......................................................................... 45. 4.2.1. DIAGRAMA DE ACTIVIDAD MODULO INGRESO DATOS ................. 46. 4.2.2. DIAGRAMA DE ACTIVIDAD MÓDULO PDM ........................................ 47. 4.2.3. DIAGRAMA DE ACTIVIDAD MODULO ALMACENAR DATOS ......... 48. DISEÑO ........................................................................................................................ 49 5.1. 6. DOCUMENTACIÓN DE CASOS DE USO ................................................. 32. ANÁLISIS ..................................................................................................................... 41 4.1. 5. DIAGRAMA DE DOMINIO ......................................................................... 25. PROTOTIPACIÓN ................................................................................................ 49. 5.1.1. INDEX ............................................................................................................ 49. 5.1.2. CONFIGURACIÓN ....................................................................................... 50. 5.1.3. OBTENER POLÍTICA .................................................................................. 51. 5.2. LISTA INICIAL DE CLASES .............................................................................. 52. 5.3. DIAGRAMA DE CLASES ................................................................................... 53. 5.4. MODELO DE INTERFAZ .................................................................................... 54. IMPLEMENTACIÓN ................................................................................................... 56 6.1. DEFINICIÓN DE CLASES .................................................................................. 56.
(6) 6.1.1. DEFINICIÓN DE CLASES CAPA MODELO ............................................. 56. 6.1.2. DEFINICIÓN DE CLASES CAPA VISTA ................................................... 57. 6.1.3. DEFINICIÓN DE CLASES CAPA CONTROL ........................................... 58. 6.2. DIAGRAMA DE DESPLIEGUE .......................................................................... 58. 6.3. DIAGRAMA DE COMPONENTES ..................................................................... 59. 6.4. DIAGRAMA DE PAQUETES .............................................................................. 60. 7. PRUEBAS ..................................................................................................................... 62 7.1. PRUEBAS UNITARIAS ....................................................................................... 62. 7.1.1. PRUEBAS UNITARIAS MÓDULO INGRESO DATOS ............................ 62. 7.1.2. PRUEBAS UNITARIAS MÓDULO PDM ................................................... 63. 7.1.3. PRUEBAS UNITARIAS MODULO ALMACENAMIENTO DE DATOS . 65. 7.2. PRUEBAS FUNCIONALES ................................................................................. 65. 7.3. ANALISIS COMPLEJIDAD COMPUTACIONAL ............................................. 67. 8. CONCLUSIONES ........................................................................................................ 73. 9. RECOMENDACIONES ............................................................................................... 74. 10. REFERENCIAS BIBLIOGRÁFICAS ...................................................................... 75.
(7) LISTA DE TABLAS Tabla 1. Integrantes en el desarrollo del proyecto ................................................................ 19 Tabla 2. Herramientas para desarrollo del proyecto ............................................................. 20 Tabla 3. Glosario De Términos ............................................................................................ 26 Tabla 4. Requerimientos funcionales ................................................................................... 28 Tabla 5. Requerimientos no funcionales .............................................................................. 30 Tabla 6. Definición de Actores ............................................................................................. 31 Tabla 7. Lista preliminar casos de uso ................................................................................. 31 Tabla 8. Documentación caso de uso: Crear Decisiones ...................................................... 32 Tabla 9. Documentación caso de uso: Cargar Decisiones .................................................... 33 Tabla 10. Documentación caso de uso N°3: Guardar Decisiones ........................................ 35 Tabla 11. Documentación caso de uso: Configuración Recocido Simulado ........................ 36 Tabla 12. Documentación caso de uso: Buscar Política ....................................................... 37 Tabla 13. Documentación caso de uso: Generar Reporte ..................................................... 38 Tabla 14. Documentación caso de uso: Modificar Decisiones ............................................. 39 Tabla 15. Lista Inicial de clases............................................................................................ 52 Tabla 16. Definición de Clases Capa Modelo ...................................................................... 56 Tabla 17. Definición de Clases Capa Vista .......................................................................... 57 Tabla 18. Definición de Clases Capa Control ...................................................................... 58 Tabla 19. Pruebas Unitarias Módulo Ingreso Datos ............................................................. 62 Tabla 20. Pruebas Unitarias Módulo PDM .......................................................................... 63 Tabla 21. Pruebas Unitarias Modulo Almacenamiento de Datos ......................................... 65 Tabla 22. Pruebas Funcionales. ............................................................................................ 66.
(8) LISTA DE FIGURAS Figura 1. Modelo de procesos Ingresar Datos ...................................................................... 22 Figura 2. Modelo de procesos PDM ..................................................................................... 23 Figura 3. Modelo de procesos Almacenamiento Datos ........................................................ 24 Figura 4. Modelo de Dominio .............................................................................................. 25 Figura 5. Modelo de Casos de uso general ........................................................................... 32 Figura 6. Modelo de secuencia ingreso datos ....................................................................... 42 Figura 7. Modelo de Secuencia PDM ................................................................................... 43 Figura 8. Modelo de secuencia almacenamiento datos ........................................................ 44 Figura 9. Modelo de actividad ingreso datos ........................................................................ 46 Figura 10. Modelo de actividad PDM .................................................................................. 47 Figura 11. Modelo de actividad almacenar datos ................................................................. 48 Figura 12. Pre-pantalla índex................................................................................................ 49 Figura 13. Pre-pantalla índex matrices ................................................................................. 50 Figura 14. Pre-pantalla configuración .................................................................................. 51 Figura 15. Pre-pantalla obtener política ............................................................................... 52 Figura 16. Modelo de clases ................................................................................................. 54 Figura 17. Modelo de Interfaz .............................................................................................. 55 Figura 18. Modelo de despliegue ......................................................................................... 59 Figura 19. Modelo de componentes ..................................................................................... 60 Figura 20. Modelo de paquetes............................................................................................. 61.
(9) LISTA DE ANEXOS. Anexo 1. Presupuesto y fuentes de financiación .................................................................. 78 Anexo 2. Cronograma de actividades ................................................................................... 79 Anexo 3. Diagramas específicos casos de uso ..................................................................... 80 Anexo 4. Diagramas específicos secuencia .......................................................................... 83 Anexo 5. Manual de Usuario ................................................................................................ 90 Anexo 6. Manual de desarrollador ..................................................................................... 127. 1.
(10) RESUMEN Este documento tiene como objetivo mostrar el proceso de diseño e implementación que se hizo para la solución " PROTOTIPO DE SOFTWARE PARA SOLUCIONAR PROCESOS DE DECISIÓN DE MARKOV IMPLEMENTANDO ALGORITMO RECOCIDO SIMULADO". Inicialmente se hizo un plan para identificar el problema general, se ha diseñado el modelo de negocio para mostrar los procesos que forman parte de la aplicación, se ha recopilado información sobre los requisitos que aclaran el alcance de la solución, se continua con el análisis para llevar a cabo un diseño que incluye una vista previa de la aplicación y se define como será la aplicación, el proceso culmina en una fase de prueba que permitió encontrar errores que fueron evaluados y resueltos. Por último, las conclusiones y recomendaciones resultantes del desarrollo del proyecto se documentan. PALABRAS CLAVE: Procesos De Decisión De Markov, Recocido Simulado, Decisión y Política..
(11) ABSTRACT This document aims to show the process of design and implementation that was made for the solution "software prototype for making decision Markov chain using simulated annealing". Initially a plan was made to identify the general problem, it has designed the business model to show the processes that are part of the application, it has compiled information on the requirements that clarify the scope of the solution, continue with the analysis to carry out a design that includes a preview of the application and be defined as will be the application, and the process culminates in a test phase which allowed to find errors that were evaluated and resolved. Finally, conclusions and recommendations resulting from the development of the project are documented. KEYWORDS: Markov Decision Process Simulated Annealing, Decisions And Policy..
(12) INTRODUCCIÓN La importancia que tienen los procesos de decisión de Markov (PDM) en varios campos de la ciencia y la industria está ligada a la capacidad que tienen para predecir el comportamiento de un sistema a través del tiempo y lograr tomar decisiones con criterio o probabilidad. Los PDM están conformados por cadenas de Markov, estas no son más que una serie de eventos, en la cual la probabilidad de que ocurra un evento depende del evento inmediatamente anterior. En efecto, las cadenas de este tipo tienen memoria, recuerdan el último evento y esto condiciona las posibilidades de los eventos futuros. Este documento permite identificar elementos y conceptos importantes que están relacionados con la temática, en la descripción del problema se exponen las limitaciones que el campo de investigación de operaciones aún no logra alcanzar, principalmente encontrar una solución óptima a problemas considerablemente grandes de forma eficiente. La formulación de este trabajo abre paso a la profundización en dos campos científicos diferentes pero estrechamente relacionados, que son, la inteligencia artificial que demuestra con algoritmos metaheurísticos una solución alternativa a problemas de optimización combinatoria, y la investigación de operaciones que permite modelar procesos estocásticos para tomar decisiones con criterio y lograr optimizar procesos y situaciones en muchas áreas de la industria, investigación entre otros. En los alcances y limitaciones se analiza y explica los diferentes aspectos que influyen en la viabilidad de desarrollar este prototipo de software, justifica las restricciones necesarias para garantizar la realización y el desarrollo del proyecto. Los objetivos responden a la formulación establecida en el proyecto, plasman de forma tangible la viabilidad de obtener políticas óptimas de un PDM implementando el algoritmo de recocido simulado, dan las especificaciones técnicas del prototipo de software que se.
(13) desarrollará, establecen características esenciales que permitirán implementar un algoritmo metaheurístico de forma coherente para generar políticas óptimas a PDM. La investigación justifica la razón por la cual dos campos diferentes de la ciencia, como lo son la inteligencia artificial y la investigación de operaciones están estrechamente relacionados y su importancia en la optimización de operaciones. Se plasman también características y técnicas relacionadas con el desarrollo y gestión del proyecto de software como los son la metodología a utilizar, sus respectivas fases y sus flujos de trabajo, se evalúa la factibilidad económica, operativa y técnica que permite establecer los requisitos externos de la gestión del software y se establece un cronograma de trabajo de 6 meses que reúne todas las actividades del proyecto..
(14) 1. FASE DE DEFINICIÓN, PLANEACIÓN Y ORGANIZACIÓN 1.1. TÍTULO DEL TRABAJO PROTOTIPO DE SOFTWARE PARA SOLUCIONAR PROCESOS DE DECISIÓN. DE MARKOV IMPLEMENTANDO ALGORITMO RECOCIDO SIMULADO. 1.2. TEMA Software para demostrar la optimización de problemas mediante el uso de esquemas y. técnicas de enfriamiento en el algoritmo recocido simulado. 1.3. PLANTEAMIENTO DEL PROBLEMA Todo problema debe ser definido y limitado en el tiempo y en el espacio, debe implicar. la posibilidad de realizar una prueba empírica, es decir, que sea factible de observarse en la realidad única y objetiva. 1.3.1 DESCRIPCIÓN En la temática de procesos de decisión de Markov surgen problemas particulares que son solucionados con implementaciones independientes, por tal motivo aún no hay un planteamiento general para abordar y hallar la solución o política más adecuada en este tipo de procesos estocásticos. También por su naturaleza estos procesos son de complejidad exponencial con respecto a la cantidad de estados que se pueden llegar a trabajar en una cadena de Markov, esto implica que métodos rigurosos o tradicionales tengan alto costo computacional y en la mayoría de los casos no puedan ser aplicables a problemas considerablemente grandes. Las cadenas de Markov en su formulación permiten acoger temas diversos que van desde planteamientos comunes y sencillos (matriz de transición con pocos estados) hasta arduos y complejos (matriz de transición con cantidades considerables de estados), la optimización de operaciones ha buscado adaptar dichas cadenas a métodos de búsqueda de.
(15) políticas sin que se halle, hasta ahora, un método general con la viabilidad apropiada para ofrecer una solución a cualquier problema. 1.3.2 FORMULACIÓN ¿Cómo obtener la política más óptima en un sistema con estados y acciones diferentes, propuesto por medio de un proceso de decisión de Markov implementando el algoritmo de recocido simulado? 1.4. JUSTIFICACIÓN Implementar algoritmos metaheurísticos para hallar la mejor política en los procesos. de decisión de Markov es una de las prácticas más utilizadas en el campo de la optimización de operaciones y día a día va tomando más fuerza por sus favorables resultados en comparación con métodos clásicos de optimización. El avance investigativo de estas áreas constituye la creación de un desafío a la adaptación de dichos métodos para cada sistema de estados y acciones propuesto, en general esta práctica se ha venido aplicando de forma particular para solucionar problemas específicos de optimización, y esto ha provocado que sea difícil o casi imposible aplicar una solución genérica para cualquier proceso de decisión de Markov. Teniendo en cuenta esta situación, surge la necesidad de realizar un estudio que evalúe la viabilidad de implementar y parametrizar el algoritmo recocido simulado a procesos de decisión de Markov de cantidades de estados diferentes.. 1.5. OBJETIVOS Definición del fin que se pretende alcanzar, se realiza una descripción muy concreta de. la meta y el desarrollo que se realizara para el funcionamiento..
(16) 1.5.1 OBJETIVO GENERAL Desarrollar un prototipo de software para la toma de decisiones de cadenas de Markov implementando recocido simulado. 1.5.2 OBJETIVOS ESPECÍFICOS Implementar un prototipo de software que genere políticas óptimas para procesos de decisión de Markov de diferentes cantidades de estados. Desarrollar un módulo que permita ingresar la matriz de transición, matriz de recompensa y la cantidad de acciones que representen el proceso de decisión de Markov. Desarrollar la interfaz que permite al usuario elegir parámetros inherentes al algoritmo como el esquema de vecindad y las estrategias de reducción de temperaturas. Generar el reporte de la solución encontrada por la aplicación, identificando la mejor política hallada. Implementar gráficas ilustrativas del comportamiento del algoritmo recocido simulado en cada uno de los ejercicios. Comprobar el funcionamiento de la herramienta por medio de pruebas y ejercicios propuestos o relacionados con la temática. Se referencia el problema del automóvil 1 propuesto por Howard para realizar esta prueba. 1.6. ALCANCES Y DELIMITACIONES Se indica la definición y control de lo que está y no está incluido en el proyecto..
(17) 1.6.1 ALCANCES Entre los alcances de la investigación es de prioridad llevar a cabo los objetivos planteados en el proyecto con el fin de realizar un aporte al campo de la optimización de operaciones y en general al estudio de este tipo de problemas estocásticos. El prototipo de software que se desarrollará contribuirá a la exploración y análisis de PDM, que en la actualidad se hace de forma arbitraria, de esta manera se brindará una nueva herramienta a los usuarios finales principalmente la comunidad académica, científica e investigativa que pueden estar interesados en profundizar en este campo de la ciencia. También puede llegar a ser una herramienta de aprendizaje que brinde la oportunidad a personas que no conozcan de la temática, aprender de manera práctica conceptos esenciales de los PDM. 1.6.2 DELIMITACIONES Es importante explicar que una cadena de Markov puede ser tan grande como el problema lo requiere, cuando este caso se presenta el espacio de búsqueda de una solución se incrementa de manera exponencial, esto lleva a un gasto computacional elevado y puede convertirse en un problema intratable, impráctico o peor, no computacional. Por esta razón la principal delimitación o restricción es que el prototipo de software trabajará con máximo 20 estados para representar una cadena de Markov. Esto garantiza que los problemas que se modelen sean lo suficientemente grandes para demostrar los resultados de implementar el algoritmo recocido simulado sin correr el riesgo de tratar con problemas inalcanzables y no prácticos. Por definición un proceso estocástico es un modelo probabilístico que evoluciona en el tiempo, en otras palabras representa la probabilidad de pasar de un estado a otro, por tal.
(18) motivo el prototipo de software deberá poder representar cadenas de Markov con un mínimo de dos estados, esto garantizará que hallan suficientes datos para poder trabajar. 1.7. MARCO DE REFERENCIA Recopilación breve y concisa de conceptos, teorías y reglamentación que se relacionan. directamente con el desarrollo del tema y del problema de investigación. 1.7.1 MARCO TEÓRICO Descripción detallada de cada uno de los elementos esenciales de la teoría, de tal manera que la formulación del problema y su solución sean una deducción lógica de ella. 1.7.1.1 Estado del arte La revisión de diferentes artículos y trabajos de investigación permiten dar un panorama sobre el desarrollo que se ha tenido en el campo de investigación de operaciones, y en particular de los avances en los que se han implementado algoritmos meta heurísticos para solucionar procesos de decisión de Markov (PDM) que permitan obtener políticas óptimas para mejorar el desempeño de un sistema en especial1. El desarrollo de estas temáticas ha sido implementado desde los años cincuenta y su evolución ha permitido integrar varias ramas de investigación como la economía, ingeniería entre otros. Uno de los primeros trabajos es el artículo de Danny Barash2 “A Genetic Search In Policy Space For Solving Markov Decision Processes”, publicado en 1999 en la Universidad de California el cual presenta una nueva metodología para resolver PDMs, basada en algoritmos genéticos. Para esto el autor utiliza el “Model Problem Presentation” y lo define como un pequeño PDM para comparar el método clásico de interacción de políticas. 1. Hillier F. S. y Lieberman G. J. Introducción a la investigación de operaciones, 6a ed.Bogotá, Colombia: McGraw Hill, 1999. 2 Barash, D.(1999) A Genetic Search In Policy Space For Solving Markov Decision Processes [online], Disponible en: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=A96FEF213AE5512AE416C27 BA18D0D15?doi=10.1.1.30.9717&rep=rep1&type=pdf>..
(19) con la propuesta de algoritmos genéticos. Como resultado encontró que el método clásico tenía una mejor eficiencia en problemas pequeños pero que el algoritmo genético resultaba apropiado para abordar cadenas de Markov grandes por su ventaja para encontrar soluciones óptimas de forma aleatoria. Luego en el 2005 el profesor Roberto Salas de la Universidad Distrital Francisco José De Caldas publica el artículo “Simulated Annealing para la búsqueda de políticas óptimas en procesos de decisión de Markov” 3. Este artículo se centra en un modelo para la toma de decisiones secuénciales bajo incertidumbre, los llamados procesos de decisión de Markov (PDM). Este modelo consta de un conjunto de estados, un conjunto de decisiones disponibles (acciones) para cada estado, un costo o recompensa de acuerdo a la acción que se tome en cada estado. Dependiendo del estado en que se encuentre el sistema y de la acción que se tome en ese estado se transitará con cierta probabilidad a otro estado, esta probabilidad es independiente de los estados y acciones pasadas en el sistema. La idea del tomador de decisiones es encontrar una secuencia de acciones (política) a seguir en cada estado de tal manera que el sistema, después de un número determinado de iteraciones o en ciertos casos a largo plazo, produzca una recompensa o costo óptimas. Con el fin de encontrar la mejor política se define e implementa el algoritmo Simulated Annealing y así poder abordar o solucionar el problema de reemplazar un automóvil. En el problema de reemplazar un automóvil se establecieron 40 estados que representan la cadena de Markov y se definieron dos posibles acciones, la primera es mantener el carro y la segunda es reemplazarlo, si se eleva la cantidad de acciones a la cantidad de estados da como resultado más de un billón de. 3. Salas, E (2007) SIMULATED ANNEALING PARA LA BÚSQUEDA DE POLÍTICAS ÓPTIMAS EN PROCESOS DE DECISIÓN DE MARKOV. Vínculos.vol 2(1), 113, 53-62. [online], Disponible en: <http://revistas.udistrital.edu.co/ojs/index.php/vinculos/article/view/4086/5751>.
(20) políticas o soluciones diferentes para resolver el problema. Dentro de sus conclusiones más destacadas se demostró que el simulated annealing, es una técnica válida para resolver procesos de decisión de Markov con políticas estacionarias ya que logro obtener una política óptima. También se concluyó que si bien, el algoritmo del simulated annealing se probó en un problema relativamente pequeño, parece factible utilizar el mismo en problemas mucho más grandes, donde son inaplicables técnicas como la rutina de mejoramiento de políticas por lo costosa que es, o en problemas donde las probabilidades de transición no están disponibles y por ende no se puede obtener la cadena de Markov. Posteriormente en el año 2008, de nuevo el profesor Roberto Salas de la Universidad Distrital Francisco José De Caldas publica el artículo “Algoritmos genéticos para la búsqueda de políticas óptimas en procesos de decisión de Markov” 4. El objetivo principal de este artículo es el uso de un algoritmo genético simple como una alternativa para encontrar buenas políticas ("cercanas a las óptimas") en este tipo de modelo, el cual se aplicó al problema de reemplazar un automóvil. Como resultado de este trabajo se evidencia que es factible encontrar con algoritmos genéticos buenas políticas cercanas a óptimas en procesos de decisión de Markov. En las pruebas experimentales que se plantearon, los algoritmos genéticos produjeron resultados al menos tan buenos como los producidos por las estrategias tradicionales disponibles (cálculo e iteración de políticas) para estos problemas. Los algoritmos meta heurísticos han sido objeto de investigación en los últimos años y aunque este documento trata sobre la aplicación de este tipo de algoritmos a los Procesos de Decisión de Markov es necesario destacar otros trabajos que demuestran la efectividad y versatilidad que tienen los algoritmos metaheurísticos en otros temas o áreas del. 4 Salas, E (2007) Algoritmos genéticos para la búsqueda de políticas óptimas en procesos de decisión de Markov [online], Disponible en: <http://www.redalyc.org/articulo.oa?id=257021008001>.
(21) conocimientos. Por ejemplo en el proyecto “Herramienta de Software para la implementación de algoritmos basados en técnicas meta heurísticas, orientados a optimizar el establecimiento de rutas para el flujo de información en comunicaciones de multidifusión” 5, realizado en el año 2004 se trabajó con el algoritmo de Simulated Annealing y búsqueda tabú con el fin de comprobar cuál de los dos ofrecía mejores resultados en la optimización de funciones como conteo de saltos, ancho de banda consumido, retardo de propagación y costo económico en una transmisión de tipo multidifusión, las pruebas que se realizaron en el proyecto se basaban en los siguientes datos, 50 nodos , 70 enlaces de red y 4 casos de prueba, los algoritmos ofrecieron respuestas satisfactorias con lo que se concluye que las meta heurísticas en los procesos de optimización tienen gran importancia y más cuando se trata de un tamaño considerable y un funcionamiento que no tiene solución general, debido a que se busca una ruta óptima a seguir. En el año 2004 se publica el artículo “Entrenamiento De Una Red Neuronal Artificial Usando El Algoritmo Simulated Annealing”, realizado por los estudiantes de maestría ingeniería eléctrica de la Universidad Tecnológica de Pereira German Alonso Gómez Rojas, Juan Carlos Henao López y el profesor facultad de ingeniería Harold Salazar Isaza. El artículo expone el problema de la modificación de los pesos y bias con un algoritmo de entrenamiento de un perceptrón multicapa es un problema clásico de programación no lineal irrestricto. El presente trabajo muestra el desempeño del “Simulated Annealing” como algoritmo de entrenamiento de esta red neuronal resolviendo dos problemas clásicos en redes neuronales, el problema de la “Codificación” y el problema de la “Doble Espiral”. Los. 5 Benito, J y Rodríguez J, (2011). Herramienta de Software para la implementación de algoritmos basados en técnicas meta heurísticas, orientados a optimizar el establecimiento de rutas para el flujo de información en comunicaciones de multidifusión. Bogotá: Facultad tecnológica, universidad Distrital..
(22) resultados de buena calidad son obtenidos cuando se compara esta propuesta frente a algoritmos clásicos de entrenamiento, Aunque el tiempo de cómputo es más elevado en el proceso SA, se llegan a soluciones de mejor calidad para la función objetivo con este entrenamiento, mientras que algunos algoritmos BP quedan atrapados en determinadas regiones del espacio de soluciones posible. También se puede apreciar el trabajo realizado por Jhon Rodríguez y Gabriel Cruz “Simulación Y Optimización Topológica Del Diseño De Una Red De Computadores A Través De La Implementación De Un Algoritmo Meta Heurístico De Resolución Multiobjetivo” 6, publicado en el año 2008, cuya propuesta fue desarrollar un software que permitiera optimizar el diseño de una red implementando algoritmo de tabú y recocido simulado, en general los resultados coincidieron en que los dos algoritmos permiten optimizar redes que contengan hasta 50 nodos y esto permite corroborar la importancia de los algoritmos me1ta heurísticos en procesos de optimización y en particular en sistemas de redes donde el tamaño y la complejidad de las redes no permiten generar una solución general. En el artículo “Aplicación De Cadenas De Markov Continúas A Las Estadísticas Del Secuestro En Colombia” 7, realizado en el 2008 por las estudiantes Yuleidy Jordan y Fernanda Lerma en conjunto con la ingeniera Eliana Toro, realizaron el modelamiento, en un proceso estocástico, de los datos hallados de la investigación respecto a la implicación que tienen los grupos en el secuestro a nivel Colombia, el estudio realizado fue planteado en. 6. Rodríguez, J y Cruz, G (2011) Simulación y optimización topológica del diseño de una red de computadores a través de la implementación de un algoritmo meta heurístico de resolución multi-objetivo. Bogotá: Facultad tecnológica, universidad Distrital. 7 Jordan Y, Lerma L Y Toro E.(2008) Aplicación De Cadenas De Markov Continúas A Las Estadísticas Del Secuestro En Colombia.
(23) procesos markovianos, técnica que se hace viable cuando se desea realizar operaciones de datos con el fin de obtener estados estables a partir de la información. También se puede apreciar el trabajo publicado en el año 2013 “Algoritmo De Recocido Simulado Aplicado Al Problema De Secuencia miento Regular” 8, realizado por Jhon Jairo Santa Chávez, César Augusto Peñuela Meneses y Mauricio Granada Echeverry de la Universidad Tecnológica de Pereira. En este trabajo se realizó una descripción detallada del algoritmo de Recocido Simulado como metodología de solución a problemas de optimización combinatorial. Este se enfocó especialmente a la solución del problema de secuenciamiento de tareas dentro de una planta de producción con recursos limitados. Se presentan resultados de simulaciones realizadas sobre un problema de la literatura especializada, mostrando la amplia versatilidad, eficiencia, y facilidad de implementación del algoritmo propuesto. Como resultado se resolvió el problema de secuenciamiento de tareas en línea (flow-shop) para un problema de 20 tareas y 5 máquinas. Las respuestas obtenidas alcanzaron, en todas las veces, respuestas cercanas al óptimo deseado. Uno de los últimos trabajos realizados con el algoritmo de recocido simulado fue “Algoritmo de Recocido Simulado para Mejorar el Rendimiento de Codificación de los Signos Wavelet” 9, publicado en el 2014, y realizado por Pedro Moreno-Bernal, Marco Antonio Cruz –Chávez, Alina Martínez-Oropeza y Abelardo Rodríguez-León vinculados a la universidad de Cuernavaca Mexico. En este artículo presentamos una aproximación de codificación del signo utilizando un algoritmo de Recocido Simulado para predecir de manera eficiente el signo de los coeficientes wavelet. Se compara la predicción obtenida con. 8. Santa J, Peñuela C, Granada Mauricio (2013)Algoritmo De Recocido Simulado Aplicado Al Problema De Secuenciamiento Regular 9 Moreno P, Cruz M, Martínez A, Abelardo (2014) Algoritmo de Recocido Simulado para Mejorar el Rendimiento de Codificación de los Signos Wavelet.
(24) el resultado de un algoritmo genético reportado en la literatura, el cual fue introducido en un codificador aritmético con el objetivo de validar la calidad de la solución. Los resultados preliminares muestran que las capacidades de incluir la predicción del signo en un codificador aritmético, tiene una ganancia de compresión arriba de 17% mejorando el rendimiento global del codificador también se comprueba de forma experimental que el algoritmo RS es eficaz en la predicción de signos para maximizar la función objetivo obteniendo buenos resultados al comparar estos con un algoritmo genético reportado en la literatura. 1.7.2 MARCO CONCEPTUAL Se desarrolla el grupo central de conceptos que fundamenta el proyecto con base al planteamiento del problema. 1.7.2.1 Recocido Simulado El recocido simulado o Simulated Annealing (SA) se basa en el concepto que cuando una estructura se calienta, sus moléculas empiezan a moverse con altas velocidades debido a la gran cantidad de energía, con el tiempo y por la pérdida de energía, dichas moléculas adquieren un movimiento más lento y se acomodan permitiendo establecer estructuras cristalinas simétricas10. Desde un punto de vista algorítmico el principio de la operación en el que se basa el recocido simulado se puede enunciar en los siguientes términos: El recocido simulado es un algoritmo de búsqueda local capaz de escapar de los óptimos locales permitiendo que bajo. 10. Barash, D.(1999) A Genetic Search In Policy Space For Solving Markov Decision Processes [online], Disponible en: http://citeseerx.ist.psu.edu/viewdoc/download;jsessionid=A96FEF213AE5512AE416C27BA18D0D15?doi=1 0.1.1.30.9717&rep=rep1&type=pdf>..
(25) ciertas circunstancias se admiten movimientos que empeoren la mejor solución encontrada hasta el momento en el proceso de búsqueda11. 1.7.2.2 Cadenas de Markov Son un tipo especial de procesos estocásticos (modelos de probabilidad de procesos que evolucionan en el tiempo de una manera probabilística)12, que responden a la propiedad Markoviana, propiedad que se basa en la verificación de que la probabilidad de un estado futuro, dado un estado presente y todos los estados pasados, depende solo del estado presente sin tener en cuenta los anteriores y además si también es independiente del tiempo la cadena de Markov tiene probabilidades de transición estacionarias u homogéneas. 1.7.2.3 Procesos de Decisión de Markov (PDM) Un proceso de decisión de Markov es similar a una cadena de Markov con la diferencia que la matriz de transición depende de la acción tomada por un agente en cada paso de tiempo. El objetivo es hallar una función llamada política, la cual especifica que acción se va tomar en cada estado, de modo que optimice alguna función de costo o de recompensa. 1.7.2.4 Política Es una regla que específica qué acción tomar en cada punto en el tiempo. Es un mapeo de estados con unas acciones tomadas. Un sistema tiene como mínimo (m) ^n políticas, donde n son la cantidad de estados y m la cantidad de acciones. 1.7.2.5 Matlab (“MATrix LABoratory”) Es un potente lenguaje diseñado para la computación técnica, integra el cálculo, la visualización y la programación en un ambiente fácil de utilizar donde los problemas y las. 11. Salas, E (2007) Algoritmos genéticos para la búsqueda de políticas óptimas en procesos de decisión de Markov [online], Disponible en: <http://www.redalyc.org/articulo.oa?id=257021008001> 12 Salas, E (2007) SIMULATED ANNEALING PARA LA BÚSQUEDA DE POLÍTICAS ÓPTIMAS EN PROCESOS DE DECISIÓN DE MARKOV. Vínculos.vol 2(1), 113, 53-62. [online], Disponible en: <http://revistas.udistrital.edu.co/ojs/index.php/vinculos/article/view/4086/5751>.
(26) soluciones se expresan en una notación matemática. Es un sistema interactivo cuyo elemento básico de datos es el arreglo que no requiere de dimensionamiento previo. Esto permite resolver muchos problemas computacionales, explorando y colaborando en todas las disciplinas13. 1.7.2.6 Recompensa esperada de la política s. El siguiente modelo se conoce como Costo promedio esperado (a largo plazo) por unidad de tiempo. En la implementación de este trabajo es utilizado para encontrar la recompensa de una política “a” y por eso se han redefinido algunos conceptos que a continuación se pueden apreciar en la figura 114. Figura 1. Recompensa esperada de la política s. 𝐸 𝑠 = Es la recompensa de la política s. m = Cantidad de estados o lo que es igual a la longitud de la política. 𝑣𝑖𝑠 = Es la recompensa de tomar la decisión aj en el estado i. 𝜋𝑖𝑠 = Es la probabilidad de estado estable de la matriz de transición (𝑃 𝑠 ) asociado a la política s. Este modelo es la función objetivo que el algoritmo de recocido simulado siempre intentara maximizar y así obtener la mejor política que tenga una recompensa óptima.. 13. Matlab [online], Disponible en: http://www.mathworks.com/products/matlab/ Taha, H. Investigación de operaciones, 7a ed. México: PEARSON EDUCACIÓN, 2004. [online], Disponible en: <https://vagosuatfis.files.wordpress.com/2012/07/thaja-investigacion-de-operaciones-byk9.pdf> 14.
(27) 1.7.2.7 Integración MATLAB y JAVA En el modelo “recompensa esperada de la política s” es necesario encontrar los 𝜋𝑖 o probabilidades de estado estable de la matriz de transición asociada a una política, por esta razón se utilizó librerías de Matlab que fueran capaz de resolver sistemas de ecuaciones y así poder encontrar los 𝜋𝑖 solicitados. La integración de MATLAB y JAVA que se utilizara está basada en crear un componente en Matlab que reciba una matriz de transición, solucione y retorne un vector columna con las probabilidades de estado estable. A continuación en la figura 2 se muestra el diseño de cómo interactúan Matlab y java. Figura 2. Interacción MATLAB y JAVA. 1.8. METODOLOGÍA DE DESARROLLO La metodología a utilizar en el desarrollo del proyecto es Rational Unified Process. (RUP), ya que permite estimar riesgos tempranamente y distribuye la carga a lo largo del trabajo. Adicionalmente, permite realizar revisiones continuas para una mejora del proyecto en cuanto a código, módulos, y librerías. El desarrollo de esta metodología se realiza a través de 4 fases principales: Fase de inicio: es una de las fases más importantes, ya que se entiende el negocio para elaborar el software de manera organizada. Los flujos de trabajo son el.
(28) modelado del negocio y definición de requisitos. Los usuarios que interactúan con el sistema y las clases que lo conforman son los aspectos más importantes para tener en cuenta en la fase de inicio. Fase de elaboración: en esta fase se continúa trabajando con los flujos de análisis y diseño. Por otra parte, se proponen y analiza los riesgos y amenazas que pueden afectar al proyecto a lo largo de su desarrollo. Fase de construcción: es una fase independiente y transitoria, ya que el foco de trabajo se encuentra en el desarrollo operativo del producto final, es decir, es el momento de mayor intervención de los programadores. Fase de transición: la interacción con el cliente es mayor en esta fase, puesto que comienza el ciclo de pruebas y el posible levantamiento de nuevos requerimientos según petición del cliente. 1.9. FACTIBILIDAD Para desarrollar el proyecto en su totalidad, son necesarios los siguientes recursos:. 1.9.1 FACTIBILIDAD ECONÓMICA Revisar información contenida en el Anexo 1. Presupuesto y fuentes de financiación. 1.9.2 FACTIBILIDAD OPERATIVA El recurso humano con el que se cuenta para el desarrollo del proyecto está conformado por director y desarrolladores, ver Tabla 1.. Tabla 1. Integrantes en el desarrollo del proyecto FACTIBILIDAD OPERATIVA NOMBRE INTEGRANTE FUNCIÓN Roberto Emilio Salas Director Ximena Galindo Ramirez Desarrollador.
(29) Cristhian David Sandoval Pazu Desarrollador Fuente: Autores. 1.9.3 FACTIBILIDAD TÉCNICA Se planean las herramientas como base para el desarrollo del proyecto, ver Tabla 2Tabla 2. Herramientas para desarrollo del proyecto. Tabla 2. Herramientas para desarrollo del proyecto FACTIBILIDAD TÉCNICA RECURSO HERRAMIENTA Lenguaje de programación java Entorno de desarrollo Netbeans IDE7.4 Recocido Algoritmo metaheuristico Simulado Lenguaje de programación Matlab Entorno de desarrollo Matlab R2011a DELL Portátil HP Portátil Fuente: Autores 1.9.4 FACTIBILIDAD LEGAL Al ser un proyecto de investigación con el fin de obtener el título académico de tecnólogos y sin ánimo de lucro, no se presenta problema alguno por hacer uso de la herramienta Matlab; en cuanto al entorno de desarrollo netbeans no se presenta limitación ya que es trabajado sobre una licencia de software libre y código fuente abierta. 1.10 CRONOGRAMA DE ACTIVIDADES Revisar información contenida en Anexo 2. Cronograma de actividades.. 2. MODELO DE NEGOCIO.
(30) 2.1. MODELADO DEL NEGOCIO El modelado del negocio tendrá como finalidad describir cada proceso del negocio. especificando sus actores, datos, actividades y reglas del negocio para entender el entorno de la aplicación a implementar. 2.2. DIAGRAMAS DE PROCESO Permiten identificar las relaciones existentes entre acciones del usuario, del sistema y. visualización del flujo de los eventos. 2.2.1 DIAGRAMA DE PROCESOS MÓDULO INGRESAR DATOS Forma gráfica de las actividades involucradas en el proceso ingresar datos, ver Figura 1..
(31) Figura 1. Modelo de procesos Ingresar Datos. Fuente: Autores. 2.2.2 DIAGRAMA DE PROCESOS MÓDULO PDM Forma gráfica de las actividades involucradas en el proceso PDM, ver Figura 2..
(32) Figura 2. Modelo de procesos PDM. Fuente: Autores. 2.2.3 DIAGRAMA DE PROCESOS MÓDULO ALMACENAMIENTO DE DATOS Forma gráfica de las actividades involucradas en el proceso almacenamiento de datos, ver Figura 3..
(33) Figura 3. Modelo de procesos Almacenamiento Datos. Fuente: Autores. 2.3. MODELO DEL DOMINIO Diagrama donde se proporciona una perspectiva conceptual entre las clases de mayor. relevancia, sus atributos y las asociaciones entre estas..
(34) 2.3.1 DIAGRAMA DE DOMINIO Visualización y relación de las clases conceptuales utilizadas para el desarrollo de la aplicación, ver Figura 4. Figura 4. Modelo de Dominio. Fuente: Autores. 2.4. GLOSARIO DE TERMINOS Muestra la relación y definición de la lista de palabras y expresiones que conforman el. contexto de la aplicación, ver Tabla 3..
(35) Tabla 3. Glosario De Términos CONCEPTO. DESCRIPCIÓN. Usuario. Es el actor encargado de la manipulación de la aplicación.. Interfaz. Es la forma en que los usuarios pueden comunicarse con la plataforma, y comprende todos los puntos de contacto entre el usuario y el sistema.. Estados. Se emplea para describir una situación en la cual se halla un objeto en relación con los cambios que influyen en su condición.. Decisiones. Determinación o resolución que se toma sobre una determinada cosa. Por lo general la decisión supone un comienzo o poner fin a una situación; es decir, impone un cambio de estado.. Matriz de Transición. Es una matriz cuadrada cuyos elementos son decimales positivos y la suma de los elementos de cada fila es igual a 1. Cada elemento debe ser una probabilidad por eso sus valores están contemplados en el rango de 0 a 1.. Matriz de Recompensa. Es una matriz cuadrada cuyos elementos representa la recompensa de un estado.. Nuevo Proyecto. Es el botón que habilita las opciones para el ingreso de datos de un nuevo problema a resolver.. Abrir proyecto. Es la manera en la que el usuario puede traer datos de un archivo xls previamente creado y almacenado, de una ruta específica.. Guardar Proyecto. Es la opción que se ofrece en la aplicación para almacenar los datos de las matrices que han sido previamente modificadas.. Obtener Política. Especifica la acción que se debe tomar en cada estado, es también un mapeo de estados con una decisión tomada.. Configuración. Es el formulario en donde se puede elegir el método y la cantidad de iteraciones internas y externas con las que se desea adquirir la solución de cada problema.. Reporte. Es el archivo con extensión pdf que se genera, si el usuario lo desea, evidenciando toda la información del problema..
(36) Temperatura Inicial. Es el campo donde se permite especificar el valor que se va a dar para iniciar la solución del problema.. Cantidad de iteraciones E. Un esquema de descenso de temperatura, enfriamiento, que garantiza la convergencia a óptimos globales => mínima energía.. Cantidad de iteraciones I. Un método que permite obtener nuevas configuraciones (estados) a partir de la actual => esquema de exploración del espacio de configuraciones.. Esquema de enfriamiento. Son las técnicas de búsqueda aleatoria que se ofrecen en la aplicación para obtener la solución al problema.. Templado de Cauchy. Es una función que se puede elegir para el enfriamiento del problema, donde se almacena una fórmula que permite la reducción de temperatura.. Templado de Boltzmann. Es una red neuronal recurrente estocástica que representa la información a partir de una distribución de probabilidad, el propósito de evaluar la función de energía con el algoritmo Simulated Annealing es llevarla a una distribución de equilibrio, no minimizarla.. Descenso Geométrico Lundy y Mees. Es un mecanismo de enfriamiento Es una función de enfriamiento que determina que se ejecuta una sola iteración para cada temperatura, pero por el contrario la temperatura se reduce a una velocidad muy lenta. Fuente: Autores. 3. REQUERIMIENTOS. Fase en la que se establece todo lo relacionado en cuanto al funcionamiento que tendrá la aplicación mediante la documentación de funcionalidad e identificación de los casos de uso. 3.1. REQUERIMIENTOS FUNCIONALES Declaración explicita de las acciones con las que el sistema debe cumplir, visualizar. Tabla 4..
(37) Tabla 4. Requerimientos funcionales Código del requerimiento RF-1. RF-2. RF-3. RF-4. RF-5. RF-6 RF-7. RF-8. RF-9. Requerimiento. Descripción. Crear una Matriz de El sistema debe permitir Crear una Matriz de Transición transición de mínimo 2 filas y 2 columnas y máximo 20 filas y 20 columnas. Cargar una Matriz de El sistema debe permitir Cargar una Matriz de Transición Transición de n filas por n columnas. (Mínimo 2 filas y 2 columnas. Máximo 20 filas y 20 columnas). El archivo que debe cargar el sistema es un libro de Excel (.xls) donde se encuentran registrados los datos de la matriz de transición. Guardar una Matriz El sistema debe permitir Guardar una Matriz de de Transición Transición de n filas por n columnas. (Máximo una matriz de 20X20) en un libro de Excel (.xls). Crear matriz de El sistema debe permitir crear una matriz de recompensa recompensa. Esta matriz va te tener las mismas dimensiones de la matriz de transición asociada. Cargar la matriz de El sistema debe permitir cargar la matriz de recompensa. recompensa. El archivo que debe cargar es un libro de Excel (.xls), donde se encuentran registrados los datos de la matriz de recompensa. Guardar la matriz de El sistema debe permitir guardar la matriz de recompensa. recompensa en un libro de Excel (.xls). Implementar el Implementar el algoritmo de recocido simulado algoritmo de recocido para buscar la política óptima y se pueda obtener simulado. la recompensa más alta. Configuración del El usuario puede escoger varias tipos de algoritmo Recocido esquemas de temperatura. simulado El usuario puede escoger la cantidad de iteraciones externas. Esto está relacionado con el criterio de parada. El usuario puede escoger la cantidad de iteraciones externas. Esto está relacionado con el criterio de parada. El usuario puede escoger la temperatura inicial con la que iniciara el algoritmo. Buscar política Esta acción debe tomar los datos ingresado al óptima sistema, validarlos y procesarlos para buscar la política óptima que refleje la recompensa más alta posible..
(38) RF-10. RF-11. RF-12. RF-13. RF-14. RF-15. Mostrar comportamiento del algoritmo recocido simulado. Mostrar el comportamiento del algoritmo recocido simulado por medio de gráficas mostrando la recompensa obtenida en cada iteración externa o en otras palabras la recompensa obtenida en temperaturas diferentes. Generar Reporte Generar documento en el que se muestran los resultados obtenidos. (Formato pdf). Este reporte debe contener: Las decisiones que fueron ingresadas. La configuración con que se encontró la política. La política obtenida por el sistema. La recompensa de aplicar la política encontrada. Gráfica que muestre en comportamiento del algoritmo en cada iteración. Validación del Si el algoritmo toma demasiado tiempo en obtener algoritmo Recocido una política debe tener la posibilidad de cancelar simulado o parar para que el usuario pueda cambiar la configuración del algoritmo y de nuevo intentar obtener la mejor política. Verificar condiciones El sistema debe verificar que se cumplan con las condiciones mínimas para ser una matriz de transición válida (La suma de todos los elementos de una fila[i] deben ser igual 1). Y los valores de esta matriz deberán ser decimales positivos. Si esto no se cumple debe mostrar un mensaje al usuario que indique que debe corregir o ajustar los datos ingresados. Cuando los datos estén correctamente ingresados se podrá continuar con el proceso de buscar la mejor política. Ingresar decisiones El sistema debe permitir ingresar mínimo 2 decisiones o máximo 10 decisiones. Una decisión es la asociación de una matriz de transición y una matriz de recompensa. Mostrar decisiones El sistema debe mostrar de forma ordenada las decisiones ingresadas. Una decisión es la asociación de una matriz de transición y una matriz de recompensa. Fuente: Autores.
(39) 3.2. REQUERIMIENTOS NO FUNCIONALES Requerimientos que no se refieren directamente a las funciones específicas que. proporciona el sistema, sino a las propiedades emergentes del mismo, visualizar Tabla 5. Tabla 5. Requerimientos no funcionales Código del requerimiento. Requerimiento. RNF-1. Usabilidad. RNF-2. RNF-3 RNF-4 RNF-5. RNF-6. 3.3. Descripción. Debe ser fácil de usar, debe tener interfaz intuitiva. Condiciones El sistema deberá funcionar en sistemas operativos Windows 7 en adelante puede utilizar herramientas como Matlab, Microsoft Office (libros de Excel) y formatos pdf. Rendimiento La aplicación debe soportar gran cantidad de datos durante su proceso. Desempeño No debe presentar errores durante su manejo. Requerimientos Se deberán realizar estudios, si posteriormente externos a la implementación de este sistema los usuarios están interesados en complementarlo con otras funcionalidades que manejaría más adelante, esto permitiría actualizar el software y generar implementaciones para que este pueda agilizar el proceso u ofrecer nuevas funcionalidades. Requerimientos Ofrecer al usuario final una explicación del organizacionales funcionamiento y la finalidad del software en cada módulo (manuales de uso y soporte). Fuente: Autores. DEFINICIÓN DE ACTORES Un actor es una agrupación uniforme de personas, sistemas o máquinas que interactúan. con el sistema, en este caso una aplicación de escritorio, se describe el actor relacionado que hará uso del software, ver Tabla 6..
(40) Tabla 6. Definición de Actores ACTOR. DESCRIPCIÓN. Es el actor que hace uso de las herramientas suministradas por la aplicación, puede acceder a los módulos de Nuevo proyecto, Abrir proyecto, Guardar proyecto, Obtener política, Configurar y Generar Reporte. Fuente: Autores. 3.4. LISTA PRELIMINAR DE CASOS DE USO Listado de los casos de uso principales que dan pauta al desarrollo del prototipo, ver. Tabla 7.. Tabla 7. Lista preliminar casos de uso . USUARIO Crear Decisiones Cargar Decisiones. Guardar Decisiones. Configuración Recocido Simulado. Buscar Política. Generar Reporte. Modificar Decisiones. Fuente: Autores. 3.5. MODELO DE CASOS DE USO Los diagramas de casos de uso detallan las relaciones y las dependencias entre un grupo. de casos de uso y el actor participante en el sistema. Se muestra el diagrama de caso de uso general, visualizar Figura 5. Los demás se encuentran en el Anexo 3. Diagramas específicos casos de uso, con fines de preservación de acuerdo a la norma de medio ambiente del Ministerio TIC “Cero Papel”..
(41) Figura 5. Modelo de Casos de uso general. Fuente: Autores. 3.5.1 DOCUMENTACIÓN DE CASOS DE USO Descripción detallada de las especificaciones y los pasos que sigue el actor para interactuar con el sistema. Tabla 8. Documentación caso de uso: Crear Decisiones IDENTIFICACION CU-1. CASO DE USO ACTORES Crear decisiones USUARIO OBJETIVO Permitir crear decisiones desde la aplicación. El usuario podrá ingresar los datos y definir cuantas decisiones desea crear. DESCRIPCIÓN Una decisión está conformada por una matriz de transición y una matriz de recompensa. Esto implica que el sistema debe permitir crear la cantidad de decisiones que el usuario solicite y garantizar que el usuario puede modificar los valores de estas decisiones cuando sea necesario. El Actor debe ingresar a la aplicación. El Usuario debe ingresar a la sección nuevo proyecto. El usuario debe ingresar la cantidad de decisiones. Un máximo Precondiciones de 10 decisiones o mínimo de 2 decisiones. El usuario debe ingresar la cantidad de estados de las decisiones..
(42) . . El sistema debe crear la cantidad de decisiones solicitadas por el usuario. El sistema debe mostrar la matriz de transición y la matriz de recompensa de cada decisión creada. Las dimensiones de las matrices de transición y de recompensa dependen de la cantidad de estados solicitados por el usuario. El sistema debe habilitar la sección Guardar decisiones. El sistema debe habilitar la sección Buscar política. El sistema debe habilitar la sección Modificar Decisiones.. . El usuario puede cancelar la operación Crear decisiones. Si la aplicación es cerrada se cancela la operación.. Pos condiciones. Alternativas y excepciones. . CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario debe ingresar a la aplicación. 5. El sistema crea la cantidad de decisiones 2. El usuario debe dar clic en la opción Crear solicitadas. decisiones. 6. El sistema crea las matrices de transición y 3. El usuario escoge la cantidad de de recompensa de cada decisión. Las decisiones. dimensiones de las matrices de transición y de 4. El usuario escoge la cantidad de estados. recompensa dependen de la cantidad de estados solicitados por el usuario. 7. El sistema habilita la sección Guardar decisiones. 8. El sistema habilita la sección Buscar política. 9. El sistema habilita la sección Modificar Decisiones. PUNTOS DE INTERRUPCIÓN El usuario puede cancelar la operación desde la acción dos. Fuente: Autores Tabla 9. Documentación caso de uso: Cargar Decisiones IDENTIFICACION CU-2. CASO DE USO ACTORES Cargar Decisiones USUARIO OBJETIVO El sistema debe permitir cargar masivamente las decisiones y datos necesarios y garantizar que puedan ser modificados y procesados con el fin de ser utilizados por el sistema. DESCRIPCIÓN El caso de uso permite cargar la cantidad de decisiones que se encuentren en un archivo Excel. Cada decisión debe tener una matriz de transición y una matriz de recompensa..
(43) Precondiciones. . El usuario debe ingresar a la aplicación. El usuario debe ingresar a la sección Cargar Decisiones. El usuario debe seleccionar el archivo Excel (.xls), en donde se encuentran las decisiones a cargar.. El sistema debe validar que el archivo seleccionado sea (.xls). El sistema debe validar que la cantidad de decisiones sea mínimo 2 máximo 10. El sistema debe validar que por cada decisión exista una matriz de transición y una matriz de recompensa. El sistema debe validar que la matriz de transición y la matriz de recompensa tengas las mismas dimensiones. Si no se cumplen las validaciones anteriores el sistema mostrará un mensaje que le indique al usuario por que no se Pos condiciones pudo cargar las decisiones. Si las validaciones anteriores se cumplen el sistema debe cargar las decisiones y mostrarlas de forma ordena en la pantalla principal de la aplicación. Si las validaciones anteriores se cumplen el sistema debe habilitar la sección Guardar decisiones. Si las validaciones anteriores se cumplen el sistema debe habilitar la sección Buscar política. Si las validaciones anteriores se cumplen el sistema debe habilitar la sección Modificar Decisiones. El usuario cancela la operación. Notificar mensaje de error si la matriz no cumple con los Alternativas y requisitos necesarios. excepciones Notificar mensaje de error si la aplicación no encuentra la ruta en donde se almaceno las matrices. Si la aplicación es cerrada se cancela la operación. CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario debe ingresar a la aplicación. 4. el sistema valida que el archivo cumpla con 2. El usuario debe dar clic en la opción los requisitos mínimos. Si no cumple muestra cargar decisiones. un mensaje al usuario para que revise lo 3. El usuario debe seleccionar el archivo ocurrido. (.xls), donde se encuentra las decisiones a 5. el sistema valida que el archivo cumpla con cargar. los requisitos mínimos. Si cumple muestra las decisiones cargadas en la pantalla principal. 6. Si las validaciones anteriores se cumplen el sistema debe habilitar la sección Guardar decisiones. 7. El sistema valida que el archivo cumpla con los requisitos mínimos. Si cumple sistema debe habilitar la sección Buscar política..
(44) 8. El sistema valida que el archivo cumpla con los requisitos mínimos. Si cumple debe habilitar la sección Modificar Decisiones.. PUNTOS DE INTERRUPCIÓN El usuario puede cancelar la operación desde la acción dos. Fuente: Autores Tabla 10. Documentación caso de uso N°3: Guardar Decisiones IDENTIFICACION CU-3. CASO DE USO ACTORES Guardar Decisiones USUARIO OBJETIVO El sistema debe permitir guardar las decisiones cuando el usuario lo considere necesario. Se deben guardar en un archivo Excel (.xls). DESCRIPCIÓN El caso de uso permite guardar en un archivo Excel (.xls) las decisiones creadas o cargadas por el usuario para que puedan ser utilizadas en otra ocasión por el sistema. Precondiciones. . Pos condiciones. . Alternativas y excepciones. . El usuario debe ingresar a la aplicación. El usuario debe haber creado previamente las decisiones desde la sección Crear decisiones. El usuario debe haber cargado previamente las decisiones desde la sección Cargar decisiones. El usuario debe seleccionar la ruta donde se crea el archivo Excel donde se guardaran las decisiones y asignar un nombre al archivo. El sistema deberá guardar las decisiones en la ruta escogida por el usuario en formato xls (Libro de Excel). El sistema deberá guardar las decisiones de forma ordenada y con el fin de identificar que cada matriz de transición está asociado con una matriz recompensa. El usuario cancela la operación. Notificar mensaje de error si el directorio donde se va a guarda no existe. Notificar sí las decisiones fueron guardadas o no. Si el usuario no decide la ruta del archivo el sistema lo guardará por defecto en la carpeta del proyecto PDM-RC. Si la aplicación es cerrada eventualmente debe desplegar la opción de guardar el archivo.. CURSO NORMAL DE LOS EVENTOS.
(45) ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. El usuario debe ingresar a la aplicación. 5. El sistema guarda las decisiones en el 2. El usuario debe decidir entre dos archivo Excel. operaciones abrir proyecto o nuevo 6. Si la operación fue exitosa se abrirá proyecto. automáticamente el archivo Excel y se 3. El usuario podrá dar clic en la pestaña mostrará al a usuario. guardar proyecto. 7. Si la operación no es exitosa el sistema 4. El actor elige la ruta donde quedará mostrará un mensaje "operación no exitosa". guardado el archivo. PUNTOS DE INTERRUPCIÓN El usuario puede cancelar la operación desde la acción número cuatro. Fuente: Autores Tabla 11. Documentación caso de uso: Configuración Recocido Simulado IDENTIFICACION. CASO DE USO. ACTORES. CU-4. Configuración Recocido Simulado. USUARIO. OBJETIVO El usuario puede escoger los criterios de parada y los esquemas de enfriamiento que son indispensables para que el algoritmo recocido simulado pueda encontrar una política óptima con la recompensa más alta posible.. . DESCRIPCIÓN El usuario debe ingresar a la aplicación El usuario debe crear decisiones desde la opción Nuevo Proyecto. El usuario debe cargar decisiones desde la opción Abrir Proyecto. El usuario debe dar clic en el botón Configuración. El sistema debe guardar la configuración que el usuario definió. El sistema debe guardar el valor de la temperatura. El sistema debe guardar el valor de las iteraciones externas e internas. El sistema debe guardar el esquema de enfriamiento.. . El usuario cancela la operación configuración. El usuario cierra la aplicación.. Precondiciones. . Pos condiciones. Alternativas y excepciones. . CURSO NORMAL DE LOS EVENTOS ACCION DEL ACTOR RESPUESTA DEL SISTEMA 1. Desplegar la aplicación. 3. El sistema carga las matrices de las 2. El usuario crea o abre un proyecto. decisiones..
(46) 4. El usuario realiza las modificaciones que 6. El sistema carga la interfaz Configuración considere pertinentes en cada decisión. y habilita los campos que se pueden 5. El usuario despliega la opción modificar. Configuración. 8. El sistema guarda internamente los valores 7. El usuario ingresa la temperatura, la definidos. cantidad de iteraciones y el esquema de 10. El sistema cierra la ventana configuración enfriamiento. y retorna al menú principal. 9. El usuario oprime el botón aceptar. PUNTOS DE INTERRUPCIÓN El usuario puede cancelar la operación desde la acción número cinco. Fuente: Autores Tabla 12. Documentación caso de uso: Buscar Política IDENTIFICACION. CASO DE USO. ACTORES. CU-5. Buscar Política. USUARIO. OBJETIVO Obtener la política óptima que refleje la recompensa más alta que da solución al problema en cuestión realizando la validación del algoritmo recocido simulado y de los valores de las matrices. DESCRIPCIÓN La finalidad del proyecto es dar una solución óptima al problema que fue planteado, el caso de uso ofrece esa política óptima que refleja la recompensa más alta encontrada en el curso de las iteraciones que realiza el algoritmo. . Precondiciones. . Pos condiciones. . El usuario debe ingresar a la aplicación. El usuario debe crear decisiones desde la opción Nuevo Proyecto. El usuario debe cargar decisiones desde la opción Abrir Proyecto. El sistema debe verificar que se cumplan con las condiciones mínimas para ser una matriz de transición válida (La suma de todos los elementos de una fila[i] deben ser igual a 1). Y los valores de esta matriz deberán ser decimales positivos. Si esto no se cumple debe mostrar un mensaje al usuario que indique que debe corregir o ajustar los datos ingresados. Cuando los datos estén correctamente ingresados se podrá continuar con el proceso de buscar la mejor política. El usuario debe desplegar la ventana Obtener política. El sistema debe obtener el valor específico de la recompensa más alta. El sistema debe habilitar la opción Reporte..
Figure
Documento similar
Convocatoria de ayudas públicas en régimen de concurrencia competitiva para proyectos de carácter no productivo de la medida 19 "LEADER" en el marco del Programa de
Convocatoria de las bases reguladoras para la concesión de ayudas del Ayuntamiento de Benacazón destinadas a emprendedores/as para la creación de empresas de trabajo autónomo en
Título Convocatoria que tiene por objeto promover la participación en el programa plan internacional de promoción, cofinanciado en un 50% por el Fondo Europeo de Desarrollo
Fuente de emisión secundaria que afecta a la estación: Combustión en sector residencial y comercial Distancia a la primera vía de tráfico: 3 metros (15 m de ancho)..
La campaña ha consistido en la revisión del etiquetado e instrucciones de uso de todos los ter- mómetros digitales comunicados, así como de la documentación técnica adicional de
Abstract: This paper reviews the dialogue and controversies between the paratexts of a corpus of collections of short novels –and romances– publi- shed from 1624 to 1637:
Y tendiendo ellos la vista vieron cuanto en el mundo había y dieron las gracias al Criador diciendo: Repetidas gracias os damos porque nos habéis criado hombres, nos
diabetes, chronic respiratory disease and cancer) targeted in the Global Action Plan on NCDs as well as other noncommunicable conditions of particular concern in the European