CAPÍTULO 2: Diseño del algoritmo

Transcripción

1 CAPÍTULO 2: Diseño del algoritmo 2.1 Introducción La fase del diseño del algoritmo es la fase previa a la de la implementación del mismo, y no cabe ninguna duda de que el éxito o el fracaso de dicho algoritmo dependerá en gran medida del grado de acierto que hayamos tenido a la hora de abordar nuestro diseño. Empezaremos este capítulo mostrando el modelo de datos que tendrá nuestro sistema, o lo que es lo mismo, deberemos definir la estructura general que tendrá nuestro problema para que el algoritmo que diseñemos pueda ser pasado a un determinado lenguaje de programación para su resolución. Una vez obtenida la jerarquización de nuestro problema pasaremos a definir el tipo de algoritmo que utilizaremos. En primer lugar haremos una pequeña justificación de nuestra elección, racionalizando en la medida de lo posible la elección que hemos hecho, mostrando los pros y los contras de algunas de las alternativas que se nos presentaban. Finalmente y para concluir este capítulo mostraremos la opción escogida, definiéndola con todo el detalle posible y dando en la medida de lo posible todas las pautas para comparar las pautas generales que siguen este tipo de algoritmos, y las características que tendrá el realizado en nuestro proyecto, mostrando las diferencias y similitudes finalmente también por medio de un cuadro (figura 2.3)

2 2.2 Modelo de datos Figura 2.1

3 En la fase de diseño del algoritmo la parte principal y seguramente más importante es la parte que trataremos a continuación, la del diseño del modelo de datos. Si de por sí esta fase ya tiene una importancia capital en cualquier proyecto en el que haya que programar, esta será aún mayor en el caso en el que el lenguaje de programación que se va a utilizar (el lenguaje JAVA, el cual ya explicaremos más adelante) esté orientado a objetos, como es el caso ante el que nos encontramos. Modelar los datos del problema consiste en identificar los distintos conceptos que intervienen en él (lo que en un futuro serán las clases del sistema) y relacionarlos entre sí. Para mostrar gráficamente el modelo del sistema hemos utilizado lenguaje UML (lenguaje de modelado unificado), lenguaje que se creó precisamente con este propósito. Pasando ya a al explicación del modelo en sí podemos observar que todas las clases están representadas en un cuadro, estando unidas algunas de ellas entre sí. Estas uniones representan una relación entre las clases en cuestión y los números que hay sobre las líneas representan la cardinalidad de dicha relación. La primera de las uniones (la que hay entre la clase Turno y la clase TurnoCirujano ) nos indica que cada turno puede pertenecer a uno o varios turnos de cirujano (1 n), mientras que como es lógico cada turno de cirujano posee un solo objeto de tipo turno (1). Esto también puede comprobarse en los atributos de dichas clases (los códigos de las mismas serán presentados más adelante) ya que la clase TurnoCirujano posee como atributo un único objeto de tipo turno. Totalmente análoga es la relación entre la clase Turno y la clase TurnoDeQuirofano, ya que mientras que cada turnodequirofano tiene un solo turno, los objetos de tipo turno pueden pertenecer a muchos turnodequirofano. Esta explicación también sería valida para las relaciones entre las clases Cirujano y TurnoCirujano y Quirófano y TurnoDeQuirofano. Por otra parte la relación entre la clase Quirófano y la clase Paciente tiene el siguiente significado. Cada paciente tiene como atributo una lista de quirófanos en los

4 cuales podrá operarse, mientras que en la clase Quirófano no se hace ninguna referencia a la clase Paciente. Es por esto la cardinalidad de dicha relación. Para finalizar explicaremos la relación entre la clase TurnoDeQuirofano y la clase Paciente. Volviendo al razonamiento del párrafo anterior, en la clase TurnoDeQuirofano hay una lista de los pacientes que serán operados en ese turno y en ese quirófano, mientras que en la clase paciente no hay ninguna referencia a la clase anterior, por lo que la cardinalidad será múltiple desde el punto de vista de la clase TurnoDeQuirofano y simple desde el punto de vista de la clase paciente 2.3 Justificación de la elección En primer lugar y antes de entrar en profundidad en la exposición de las características del tipo de algoritmo utilizado, plasmaremos un breve resumen del porqué de la elección de dicho tipo de algoritmo. El algoritmo seleccionado para resolver el problema al que nos enfrentamos pertenece a la familia de los algoritmos voraces o de tipo greedy, algoritmos que (como su propio nombre indica) buscan la solución de una manera rápida y agresiva. En lugar de explicar bien en que consisten dichos algoritmos (eso lo haremos en el siguiente apartado) vamos a centrarnos en explicar porque lo hemos elegido, y ha sido por una razón fundamental, la codificación de la solución. Muchos de los tipos de algoritmos (genéticos, recocido simulado ) existentes encuentran su solución final simplemente combinando otras muchas. La metodología que siguen consiste en partir de un conjunto inicial de soluciones más o menos aleatorias (población), para ir iterando con ellas e intentando acercarse a una solución que esté lo más próxima al óptimo posible. Estos tipos de algoritmos necesitan una codificación mucho más clara y concisa de sus soluciones.

5 Un ejemplo de este tipo de algoritmos es el algoritmo genético. En este algoritmo debe estar totalmente definido el concepto de vecindad entre dos soluciones, así como el cruce y la mutación entre ellas. El concepto de vecindad consiste en marcar una línea que indique cuando dos soluciones son lo suficientemente parecidas para ser consideradas vecinas. Al cruzar y al mutar dos soluciones debemos dar soluciones vecinas a las de la generación anterior, y es ahí donde está el problema. Cómo definimos dos soluciones vecinas, ante un grado tan alto de heterogeneidad? Como hemos visto en el modelo de datos, cada turno de quirófano tendrá un número distinto de bloques, cirujanos, pacientes, quirófanos, etc y ante eso, definir cuando dos soluciones distintas son o no parecidas, se hace una tarea altamente dificultosa. Dicho problema no existe (o al menos no en un grado tan alto) en el algoritmo voraz, ya que este construye una única solución en particular a partir de unos determinados principios en lugar de ir iterando con una población de estas, por lo que la codificación no juega un papel tan relevante. Otro concepto importante a tener es la experiencia anterior a la hora de manejar algoritmos voraces, lo que hace que siempre sea más ventajoso afrontar el problema con este tipo de algoritmo. Por todas estas razones hemos elegido está manera de solucionar la cuestión que se nos plantea, pasando a continuación a detallar todos los entresijos del algoritmo en cuestión. 2.4 Algoritmo voraz Los algoritmos voraces suelen ser algoritmos bastante simples. Suelen acercarse de una manera rápida y agresiva a la solución y no garantizan el óptimo, por lo que la eficiencia de los mismos depende en gran medida de la audacia del diseñador.

6 Son empleados sobre todo para resolver problemas de optimización, como por ejemplo, encontrar la secuencia óptima para procesar un conjunto de tareas por un computador, hallar el camino mínimo de un grafo, etc. En nuestro caso será utilizado para encontrar una combinación de pacientes que maximice la ponderación de los mismos, pero sin perder de vista las fechas de vencimiento. Aunque es difícil dar un esquema y unos elementos genéricos en este tipo de algoritmos ya que suelen implementarse de formas muy distintas, intentaremos proponer y aplicar a nuestro caso los que se utilizan más comúnmente. Habitualmente, los elementos que intervienen son: un conjunto o lista de candidatos (tareas a procesar, vértices del grafo, etc.); un conjunto de decisiones ya tomadas (candidatos ya escogidos); una función que determina si un conjunto de candidatos es una solución al problema (aunque no tiene por qué ser la óptima); una función que determina si un conjunto es completable, es decir, si añadiendo a este conjunto nuevos candidatos es posible alcanzar una solución al problema, suponiendo que esta exista; una función de selección que escoge el candidato aún no seleccionado que es más prometedor; una función objetivo que da el valor/coste de una solución (tiempo total del proceso, la longitud del camino, etc.) y que es la que se pretende maximizar o minimizar En nuestro caso, y como parece lógico, la lista de candidatos serán los pacientes que aún no hayan sido asignados a un turno, cirujano, quirófanos Estos formarán todos parte de una lista de los que se deberán ir seleccionando a los mejores, entendiendo por mejor a los que más ayudan a aumentar el valor de la función objetivo. Análogamente al caso anterior, el conjunto de decisiones ya tomadas serán los pacientes que ya han sido seleccionados, bien sea por su fecha de vencimiento o por su

7 alta ponderación. En ningún caso dichos pacientes saldrán de la lista de decisiones ya tomadas, siendo este por tanto un algoritmo poco flexible. Es aquí donde se observa que no todos los algoritmos voraces tienen porque tener todos los componentes genéricos, ya que en el nuestro esta función no existe. Cualquier conjunto de pacientes ya introducidos en el sistema es una solución al problema, por lo que no es necesario comprobarlo. Simplemente se intentará seguir introduciendo nuevos hasta que la lista haya concluido. Exactamente lo mismo ocurre con esta otra función, ya que para nosotros cualquier conjunto de pacientes siempre será completable. Es tal la diversidad que puede tener una solución, que resulta mucho menos costoso intentar seguir introduciendo pacientes hasta que se acaben, que comprobar si el los huecos que quedan se podría introducir alguno. La función que escoge al candidato más prometedor si existe en el algoritmo diseñado para la resolución de nuestro problema, pero consta de dos partes bien diferenciadas. En la primera de ellas los candidatos más prometedores son los pacientes que tienen una fecha de vencimiento próxima, mientras que en las siguientes son los que tienen una ponderación más alta. En nuestro caso la función objetivo que se pretende optimizar (maximizar en el problema que abordamos) es la suma de las ponderaciones de los pacientes operados, pero sin perder de vista que lo prioritario es el cumplimiento de las fechas para todos y cada uno de los pacientes. Como se ha podido observar el algoritmo voraz es un algoritmo poco homogéneo, aunque se podría dar también un esquema genérico de resolución de problemas el cual fue obtenido de [6] y es expuesto a continuación (figura 2.2), aunque como ya hemos mencionado, no se parecerá demasiado a nuestro algoritmo, el cual será presentado en capítulos posteriores.

8 Figura 2.2 Por otra parte, ahora mostraremos de una manera más esquemática (figura 2.3) los componentes de nuestro sistema, para que se pueda apreciar con mayor claridad lo que explicamos en las líneas anteriores: ESQUEMA GENERAL Conjunto o lista candidatos a entrar en la solución Conjunto o lista de decisiones ya tomadas Función que determina si un conjunto de candidatos es la solución al problema Función que determina si un conjunto es completable Función que se encarga de elegir al candidato más prometedor Función objetivo que se encarga de medir la bondad de una solución ESQUEMA PROPIO Pacientes que aún no han sido seleccionados Pacientes que ya han sido seleccionados No tenemos, puesto que cualquier conjunto admisible puede ser solución No tenemos, puesto que probamos hasta que se acaban los pacientes Función que elige primero por fecha de vencimiento y luego por ponderación Función que suma las ponderaciones de los pacientes elegidos. Figura 2.3