Una intuitiva analogía que puede hacerse entre la simulación de un sistema físico mediante un software y viceversa [6]. Un modelo físico está forma...

Una intuitiva analogía que puede hacerse entre la simulación de un sistema físico mediante un software y viceversa [6]. Un modelo físico está formado por objetos, pero se puede llegar a necesitar más objetos que no existen realmente en el sistema físico. Es de esta manera en que el software puede estar formado por objetos análogos y abstractos que representan al modelo físico [1]. La amplia aplicabilidad del acercamiento a los lenguajes orientados a objetos (LOO), puede ser atribuida a la analogía descrita anteriormente. También existen otros factores que hay que tener en cuenta dentro del diseño de un sistema, como son: la resistencia y la reusabilidad [6]. Uno de los objetivos de este documento, es proponer otra manera intuitiva de modelar algunos problemas bajo el principio de activaciones llamadas activaciones proactivas. Para ello, se deberán tomar en cuenta los puntos fundamentales para la reutilización, la resistencia y una intuición apropiada para modelar ciertos problemas físicos [6]. En este trabajo se mostrará un vértice de la programación orientada a objetos, así como los fundamentos teóricos y prácticos que permitan mostrar las implicaciones en el análisis, diseño e implantación de un software. Para tener una mejor noción de dicho paradigma basado en mensajes de activación, se plantea el siguiente problema: Se posee un estanque t1 de agua con tres sensores (s1, s2 y s3) que detecta tres niveles (n1, n2 y n3), donde n1 es el nivel bajo, n2 es un nivel aceptable y n3 nivel alto (peligro de desbordamiento). Se solicita realizar un sistema de cómputo basado en objetos que simule dicho proceso físico, con la restricción de que en el momento en que el agua llegue al nivel n3 se active una alarma a1. Si bien, uno de los objetivos de la programación orientada a objetos es que éste represente y simule a un sistema físico mediante alguna analogía; también es importante que cumpla con otros requisitos como son: el de reuso y la evolución. Primero se tomará un esbozo industrial (ver Figura 1.1), el cual permite tener una visión del problema del estanque a simular. Posteriormente se analizará con más profundidad un diseño apegado al patrón Observador1 [41, 44]. En éste se podrá estudiar una posible solución al problema del estanque. Se denota que para realizar un diseño con las características del patrón Observador, es necesario delegar a un objeto llamado monitor la responsabilidad de revisar y tener la lógica de selección. Este objeto se encargará de observar los diferentes niveles y de emitir la señal correspondiente a la alarma seleccionada. Una manera simple de representar este diseño es mediante un diagrama UML2 [19], en el cual se muestren los objetos abstractos que interactúan en el modelo del estanque (ver Figura 1.2). Un problema que se presenta en este diseño sucede al momento en que el objeto Sensor delega la responsabilidad de realizar la verificación lógica (mensaje de activación) a Monitor. Esto es, en el instante en el que nivel n3 es alcanzado se activará la alarma correspondiente. Este problema se discutirá con detenimiento en el Capítulo 4; donde se muestran algunas alternativas de solución y sus implicaciones en el diseño y análisis del problema. Cabe indicar que el diseño mostrado en la Figura 1.2 está basado en un modelo jerárquico con tipos y sin covarianza [6]; por lo que se deberá tener cuidado con la naturaleza de los objetos al momento de implantarlo en algún lenguaje orientado a objetos. Ahora bien, este mismo problema será bosquejado en la Figura 1.3 bajo el paradigma proactivo orientado a objetos propuesto. No se intenta ahondar en este punto por el momento, sólamente es una ilustración para observar una manera simple de cómo resolver el proceso involucrado. En la Figura 1.3 se presenta un esbozo general de cómo podría operar el paradigma propuesto. Se observa que la responsabilidad está en cada parte física, como se ve en la Figura 1.1. Además, se muestra que la condición de activación de la alarma está dentro del mensaje o relación, a la que se llamará mensaje de activación. Esta indica cual será el objeto que se ha de activar y en qué condiciones funcionales o imperativas se realizará dicho proceso. En los Capítulos 4 y 5 se explicará con detalle esta última forma de modelar.