Desarrollo de aplicaciones OOP. El diseño orientado a objetos: la realización de lo posible.

Sólo bajo condiciones ideales es posible obtener resultados ideales. Esto es así también para el Desarrollo de Aplicaciones Orientadas a Objetos (OOP). Quienes esperen de la orientación a objetos un remedio general contra todos los problemas informáticos acumulados con el tiempo, se verán decepcionados.

En ocasiones se plantea la cuestión de si en la Orientación a Objetos no desaparecerán las diferencias entre análisis, diseño y programación. En realidad, todo parece dispuesto: un objeto se convierte en módulo objeto, es decir, en un ejemplar (instancia) de una clase, que hereda de una supraclase (abstracción) algunos atributos (variables), los cuales se agrupan (encapsulation) con procedimientos (métodos).

En caso de que el diseño se realice haciendo en primer lugar tabla rasa y en segundo lugar sin más condiciones (seguridad, recovery, velocidad) mediante Smalltalk o Eiffel, la situación es (casi) correcta. De todas formas, hay que tener en cuenta que a nivel de la programación se trata en principio de objetos muy abstractos (por ejemplo, entero, punto, ángulo recto).

Si se trata por otra parte de un entorno ya existente, en el que hay que aumentar la productividad bajo una diversidad de condiciones marco mediante la introducción del concepto de la orientación a objetos, existe una enorme diferencia entre Análisis Orientado a Objetos (OOA) y Diseño Orientado a Objetos (OOD). Si en el análisis se ha partido de los problemas técnicos, es decir, del qué, en el diseño se trata por el contrario de la conversión o, en otras palabras, el como.

Si se observa durante un momento por ejemplo el objeto impresora, se constata que, bajo puntos de vista de un análisis, podrían ser importantes:

- La selección de calidad.

- El lugar de emisión (para sistemas con varias impresoras, dirección, etc.) - La velocidad.

Desde el punto de vista del diseño, hay que considerar de antemano un sistema de objetos, y problemas internos como:

- Gestión de colas.

- Routing.

- Integración (Advanced Function Printing, PostScript).

- Distribución de los datos necesarios para la creación de documentos.

Esta diferencia fundamental entre análisis y diseño se complementa, en lo que se refiere al desarrollo de aplicaciones para sistemas grandes, por una cantidad de servicios estándar en modo alguno orientados a objetos, y que deberán tenerse en cuenta. Así, por ejemplo, en el caso de una aplicación comercial del mundo VMS, habrá que pensar como mínimo en:

- Un sistema de seguridad (como RACF, por ejemplo).

- Un monitor de transacciones (por ejemplo, CICS).

- Software de comunicaciones (por ejemplo, VTAM).

- Un sistema de banco de datos (como IMS).

Esta difícil situación se completa con el hecho de que por el momento no parece existir aún ningún compilador OO para MVS.

Tomando en consideración este contexto, resulta claro que no exista una respuesta sencilla y de validez general a la pregunta de en que consiste el Diseño Orientado a Objetos.

A continuación se presenta en forma de ejemplo sencillo una propuesta de cómo sería posible, dentro del marco del proceso de datos comercial, poner en marcha el diseño orientado a objetos con el fin de aumentar la capacidad de mantenimiento, la seguridad de los sistemas y la reusabilidad del diseño y la codificación.

Para ello se parte de tres premisas:

- En primer lugar se realizaría un análisis OO. No hay nada en principio que se oponga a esto -aparte de la experiencia y la costumbre del desarrollador de aplicaciones-.

- En segundo lugar, sería conveniente la utilización de un banco de datos relacional. Esto no es necesario (un interfaz lo suficientemente claro sería suficiente), pero sirve a la simplificación y parece apropiado, ya que parece que los sistemas de bancos de datos relacionales se seguirán imponiendo.

- En tercer lugar se requiere un front-end, con el fin de poder realizar el proceso conjunto. Esto es por una parte realista, y por otra simplifica el problema, ya que existen entornos de desarrollo OO reales para Pcs.

Considérese por ejemplo una parte de una aplicación de seguros. Este sistema deberá servir de ayuda al empleado de la compañía en la situación siguiente: el Sr. Pérez desea suscribir un seguro de vida. El empleado se interesa en primer lugar por la situación del Sr. Pérez en lo relativo a seguros, y llama al objeto de pantalla Asegurado (A), solicitando el objeto Pérez.

Deberá entonces crearse el ejemplar A(Pérez). En el set o conjunto de sus métodos deberá estar contenido Visualizar (Seguros correspondientes). Esto nos lo indica el análisis.

Considérese ahora el caso de que haya que introducir la solicitud del Sr. Pérez. se llamará objeto de pantalla Contrato, entre cuyos métodos está Nueva póliza. Se creará por lo tanto en el PC un objeto Contr(Pérez), capaz de recoger los datos necesarios. Las variables serían complementadas mediante los correspondientes mensajes del objeto de ventana de diálogos.

La nueva póliza real requiere sin embargo una comprobación complicada, una actualización de las condiciones jurídicas y muchas otras cosas (por ejemplo, la impresión y envío del contrato). Bajo los supuestos de este ejemplo, la comprobación y envío deben tener lugar en el Host. Sería conveniente el envío por Contr(Pérez) de un mensaje a un objeto Host Comprobación con los valores (Contrato (Vida), Nueva Póliza, Pérez).

Fuerte aislamiento y protocolo estable

La clase de objeto Comprobación, que contiene virtualmente los datos necesarios para esas comprobaciones y diferentes métodos generales de prueba (por ejemplo, para modificaciones y rescisiones) llama ahora a una subclase Comprobación para Seguro de Vida (CSV), que ofrece el método para Nueva Póliza. El objeto CSV (Pérez) es ahora un ejemplar de esta clase, que ha heredado el método para Nueva Póliza. Desde el punto de vista de la implementación, Comprobación consiste en un programa de control que -dependiendo de los parámetros introducidos- llama a otro programa de control para el caso concreto -en este caso CSV- que llama entonces a las transacciones necesarias para la obtención de los datos y los cálculos, o bien avisa a otro programa de control, en caso de que se necesiten datos pertenecientes a otros objetos (por ejemplo A ó Cobro). Se obtiene así un fuerte aislamiento de la implementación de los diversos objetos y un protocolo estable respecto a los objetos que continúan con el proceso.

El camino de la próxima década

En este ejemplo, CSV (Pérez) podría reaccionar enviando un mensaje a Contr(Pérez), indicando que es imposible una nueva póliza porque el Sr.Pérez no paga los seguros pendientes -por ejemplo: (Contr(Pérez), rechazar, no paga). Aquí rechazar sería un método que procesaría de forma cortés el parámetro no paga.

Si por el contrario todo está en orden, CSV (Pérez) podría enviar un mensaje al objeto de contrato Host ContrH poniendo en marcha la nueva póliza, por ejemplo (ContrH, Abrir Póliza, Pérez, SV, Suma Seguro...). Aquí, el método Abrir Póliza emitiría la secuencia de instrucciones SQL necesaria para actualizar el banco de datos con las especificaciones jurídicas. Además, sería necesario enviar diferentes mensajes a otros objetos, tales como confirmación a Contr(Pérez), entrada adicional para AH, etc.

Volviendo a repasar los datos esenciales OO:

- Encapsulación, Abstracción e Information Hiding: estos eran los principios o normas básicas de diseño.

- Inheritance: Hay que recordar Comprobación. En un sistema en el que se gestionan muchos tipos de seguro, como vehículos, accidente, vida, etc, hay muchas partes de las comprobaciones que son iguales (por ejemplo, lo relativo a las cuentas). Estas partes se heredan, de forma que las transacciones se recogen en los correspondientes