Sigamos con los sistemas de programación.
Hoy por hoy, la palabra demonio tiene muy mala imagen.
Esto no siempre fue así, Socrates decía que era inspirado por un demon, claro que por aquel entonces se les consideraba seres sobrenaturales, no obligadamente malos, más bien al contrario.
Viene a ser lo que actualmente entendemos por una Musa.
Pero el Diccionario de la Real Academia tiene otra acepción: Sentimiento u obsesión persistente y torturadora.
Todo aquel que ya ha manejado GNU/Linux ya conoce este termino.
Nos referimos a pequeños "diablillos" que de forma obsesa y persistente se dedican a una labor, y solo una.
Solemos hacer subrutinas que respondan a estímulos y que generen una respuesta o nuevos estímulos para el resto del programa o más demonios.
Estos demonios son tanto más eficaces cuanto menor sea su propósito, siendo más eficaz lanzar varios a hacer módulos más complejos.
Los estímulos que los alertan pueden ser temporales, eventos externos o variables internas, incluso generadas por otros demons.
Por poner ejemplos:
El ordenador que estas manejando tiene un demon que rastrea el teclado 50 veces por segundo para ver lo que has pulsado.
Ese mismo equipo tiene otro que comprueba si se inserta un USB, etc, etc..
Un ejemplo claro:
Cinco amigos tenemos que hacer una merendola, el tiempo es crítico.
Entramos en el supermercado y siguiendo un plan ya establecido cada cual se dedica de forma exclusiva a lo que mejor realiza.
Así queda la distribución del personal.
Nº1- Va a por el carro, situándose en lugares estratégicos.
Nº2- Va a por el vino y la cerveza.
Nº3- Va a por la carne.
Nº4- Ensaladas
Nº5- Refrescos
Nº6- Postres.
Nº7- espera en caja haciendo fila y sacando la plata.
El Nº1 no termina hasta hacerlo cada uno de los componentes, y el Nº7 empieza , a pagar, al acabar todos ellos.
En realidad, todos empiezan de forma simultánea, esto no es habitual.
Veamos un caso practico de control industrial:
Un ascensor.
Podemos hacerlo programando subrutinas que hagan las funciones de demons.
El programa principal llama a módulos que se encargan de labores menores.
Así, al llamar al ascensor....
Llamamos a un demon, que calcula si debemos subir o bajar.
Otro demon que llamamos simultáneamente, cierra las puertas.
Al terminar el proceso se desactiva.
Pasamos el control al módulo de movimiento.
Este llama al demon encargado de subir o bajar según el calculo previo.
Al llegar a destino este se desactiva.
Llamamos al demon de abrir las puertas, que se desactiva al hacerlo.
Puede parecer que este tipo de programación es muy enrevesado, pero tiene ventajas muy sustanciales.
En realidad solo programamos módulos que responden a un bit de activación y que se desactivan por sí mismos al cumplir la misión ellos u otros demons.
Si requerimos hacer un cambio, como puede ser en nuestro ejemplo, cambiar el sistema de cierre del ascensor, no afecta al resto del programa.
Dado que el demon que se encarga de esa misión es único y autónomo, no necesitamos cambiar para nada el resto del programa.
Así en nuestro ejemplo del supermercado si falla un componente, puede ser cambiado por otro amigo que se apunte, sin ni siquiera informar al resto. La misión no se verá influenciada.
Cada uno de los demons realiza tareas muy simples, siendo más sencillo el mantenimiento del programa.
Espero que quede claro este sistema de programación, a mí me gusta definirlo como:
"DIVIDE Y VENCERAS"
Hoy por hoy, la palabra demonio tiene muy mala imagen.
Esto no siempre fue así, Socrates decía que era inspirado por un demon, claro que por aquel entonces se les consideraba seres sobrenaturales, no obligadamente malos, más bien al contrario.
Viene a ser lo que actualmente entendemos por una Musa.
Pero el Diccionario de la Real Academia tiene otra acepción: Sentimiento u obsesión persistente y torturadora.
Todo aquel que ya ha manejado GNU/Linux ya conoce este termino.
Nos referimos a pequeños "diablillos" que de forma obsesa y persistente se dedican a una labor, y solo una.
Solemos hacer subrutinas que respondan a estímulos y que generen una respuesta o nuevos estímulos para el resto del programa o más demonios.
Estos demonios son tanto más eficaces cuanto menor sea su propósito, siendo más eficaz lanzar varios a hacer módulos más complejos.
Los estímulos que los alertan pueden ser temporales, eventos externos o variables internas, incluso generadas por otros demons.
Por poner ejemplos:
El ordenador que estas manejando tiene un demon que rastrea el teclado 50 veces por segundo para ver lo que has pulsado.
Ese mismo equipo tiene otro que comprueba si se inserta un USB, etc, etc..
Un ejemplo claro:
Cinco amigos tenemos que hacer una merendola, el tiempo es crítico.
Entramos en el supermercado y siguiendo un plan ya establecido cada cual se dedica de forma exclusiva a lo que mejor realiza.
Así queda la distribución del personal.
Nº1- Va a por el carro, situándose en lugares estratégicos.
Nº2- Va a por el vino y la cerveza.
Nº3- Va a por la carne.
Nº4- Ensaladas
Nº5- Refrescos
Nº6- Postres.
Nº7- espera en caja haciendo fila y sacando la plata.
El Nº1 no termina hasta hacerlo cada uno de los componentes, y el Nº7 empieza , a pagar, al acabar todos ellos.
En realidad, todos empiezan de forma simultánea, esto no es habitual.
Veamos un caso practico de control industrial:
Un ascensor.
Podemos hacerlo programando subrutinas que hagan las funciones de demons.
El programa principal llama a módulos que se encargan de labores menores.
Así, al llamar al ascensor....
Llamamos a un demon, que calcula si debemos subir o bajar.
Otro demon que llamamos simultáneamente, cierra las puertas.
Al terminar el proceso se desactiva.
Pasamos el control al módulo de movimiento.
Este llama al demon encargado de subir o bajar según el calculo previo.
Al llegar a destino este se desactiva.
Llamamos al demon de abrir las puertas, que se desactiva al hacerlo.
Puede parecer que este tipo de programación es muy enrevesado, pero tiene ventajas muy sustanciales.
En realidad solo programamos módulos que responden a un bit de activación y que se desactivan por sí mismos al cumplir la misión ellos u otros demons.
Si requerimos hacer un cambio, como puede ser en nuestro ejemplo, cambiar el sistema de cierre del ascensor, no afecta al resto del programa.
Dado que el demon que se encarga de esa misión es único y autónomo, no necesitamos cambiar para nada el resto del programa.
Así en nuestro ejemplo del supermercado si falla un componente, puede ser cambiado por otro amigo que se apunte, sin ni siquiera informar al resto. La misión no se verá influenciada.
Cada uno de los demons realiza tareas muy simples, siendo más sencillo el mantenimiento del programa.
Espero que quede claro este sistema de programación, a mí me gusta definirlo como:
"DIVIDE Y VENCERAS"
No hay comentarios :
Publicar un comentario
Gracias por tu colaboración.