CENTRO NACIONAL DE INVESTIGACIÓN Y DESARROLLO TECNOLÓGICO

Cenidet GENERACIÓN DE UN MODELO DE EJECUCIÓN BASADO EN ESPECIFICACIONES FORMALES OASIS

T E S I S

PARA OBTENER EL GRADO DE

MAESTRO EN CIENCIAS DE LA COMPUTACIÓN

PRESENTA: MARIO HUMBERTO TIBURCIO ZÚÑIGA

DIRECTOR DE TESIS M.C. HUGO ESTRADA ESQUIVEL

. 0 1 - 0 4 4 5 CO-DIRECTOR

DR. JAVIER ORTIZ HERNÁNDEZ

CUERNAVACA, MORELOS AGOSTO, 2001.

Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C3

REVISION DE TESIS

Cuernavaca, Morelos a 2 de julio de 2001

Dr. Raúl Pinto Elíac Presidente de la Academia de Ciencias Computacionales Presente

Nos es grato comunicarle, que conforme a los lineamientos para la obtención del grado de Maestro en Ciencias de este Centro, y después de haber sometido a revisión académica la tesis denominada: GENERACIÓN DE UN MODELO DE EJECUCIÓN BASADO EN ESPECIFICACIONES FORMALES OASIS, realizada por el C. Mario Humberto Tiburcio Zúñiga, y habiendo cumplido con todas las correcciones que le fueron indicadas, acordamos no tener objeción para que se le conceda la autorización de impresión de la tesis.

Sin otro particular, quedamos de usted.

Atentamente

ba comisión de revisión de tesis

J

INTERIOR INTERNADO PALMIRA SIN, CUERNAVACA. MOR. MÉXICO APARTADO POSTAL 5-161 CP 62050. CUERNAVACA. TELS.(73)12 2314.12 7613.18 7741.FAX (73) 12 2430 cenidef

. .

, I Centro Nacional de Investigación y Desarrollo Tecnológico FORMA C 4

AUTORIZACION DE IMPRESIÓN DE TESIS

Cuernavaca, Morelos a 1 O de julio de 2001

I

C. Mario Hurnberto Tiburcio Zúñiga Candidato al grado de Maestro en Ciencias en Ciencias Computacionales Presente

~ Después de haber atendido las indicaciones sugeridas por la Comisión Revisora de la ~ Academia de Ciencias Cornputacionales en relación a su trabajo de tesis: GENERACIÓN DE ~ UN MODELO DE EJECUCIÓN BASADO EN ESPECIFICACIONES FORMALES OASIS, me es

grato comunicarle, que conforme a los lineamientos establecidos para la obtención del grado de Maestro en Ciencias' en este Centro, se le concede la autorización para que proceda con la impresión de su tesis.

Atentamente

Dr. Rodoi f o Pazos Rangel Jefe del Depto. de Ciencias Computacionales

! ! INTERIOR INTERNADO PALMIRA SIN. CUERNAVACA. MOR. MÉXICO

APARTADO POSTAL 5-164 CP 62050, CUERNAVACA, TELS. (73112 2314.12 7613.18 7741,FAX (731 12 2434 cenidet

AGRADECIMIENTOS A Eloí y los maestros de la cosmogonía, por brindamos a los hombres la libertad de albedrío y una inagotable fuente de inspiración.

A mis padres: Humberto I. Tiburcio Hernández y Laura Zúñiga Barajas, por todos sus sabios consejos, su gran apoyo y su gran cariño recibidos. La distancia física entre nosotros no merma la fuerte afinidad de espíritu que nos une,

A mis hermanos: Laura, Sandra, Elsy, Arturo y Leonor, por ese gran afecto y por todos los momentos compartidos desde la infancia hasta la actualidad. F

A mi abuela Cata, fía laquel y mis primos Leonardo y Angélica, gracias por SU c ~ i f i o . ’ 1

A la Secretaría de Educación Pública y al Centro Nacional de investigación y Desarrollo Tecnológico, por permitirme estudiar una maestría, y haberme brindado la oportunidad de culminarla.

en mi persona, para alcanzar este objetivo.

A mis amigos de la Academia de Sistemas y Computación del I.T.Z. Especialmente a José Francisco Carpio Tovilla, por todos la momentos buenos y malos vividos desde nuestra llegada a Morelos

A mis compañeros del grupo IRIS, por los momentos de trabajo ameno y amistad que recibí, (Ana, Juan Carlos, Erika y Octavio). A la gran asesoría y aliento recibidos de Hugo Estrada y Javier Ortiz, mis asesores en este proyecto de investigación. Sobre todo, muchas gracias por esa incondicional amistad.

A mis revisores de tesis, Humberto Hernández Garcia, José Luis Liñán y Antonio Zárate Marceleño, cuyas valiosas observaciones permitieron el desarrollo y escritura de esta tesis.

AI grupo de investigación en Ingeniería de Software, de la Universidad Politécnica de Valencia (Isidro Ramos, Oscar Pastor, Patricio Letelier, José Casi, V. Pelechano), por todas las ideas que contribuyeron a la realización de este trabajo.

A mi gran amiga Teresa Rojas, por ese gran apoyo y amistad desinteresada. Por saber aconsejarme en los momentos de flaqueza, con el siempre elevado espíritu que posee y la manera tan especial de ver las cosas.

Contenido Página

.. 1 . Introduccion ................................................................................................................. 1 1.1 Motivacion ....................................................................................................... 2 1.2 Entorno de desarrollo tesis ............................................................................... 3 1.3 Objetivos .......................................................................................................... 5 1.4 Estructura de la tesis ........................................................................................ 5

2 . Antecedentes ................................................................................................................ 7 8 2.1 Marco teorico ...................................................................................................

2.1.1 Ingenieria de requisitos ............................. ~ ............................................. 8 8 9

2.1 4 Validacion y verificacion ........................................................................ 10 12 2.1.5 Prototipacion y animacion ......................................................................

2.2 Descripción del trabajo de tesis ....................................................................... 15 2.3 Trabajos relacionados ...................................................................................... 16 2.4 Alcances del proyecto ...................................................................................... 20

21 3.1 Descripcion general ......................................................................................... 22

24 3.2 Definiciones ..................................................................................................... 3.3 Esquema conceptual ........................................................................................ 26 3.4 Atributos .......................................................................................................... 27 3.5 Derivaciones .................................................................................................... 28 3.6 Restricciones de integridad .............................................................................. 28 3.7 Eventos ............................................................................................................ 28 3.8 Evaluaciones 29 3.9 Precondiciones ................................................................................................. 29 3.10 Disparos .......................................................................................................... 30

.. . .

. . . . . .

2.1.2 Modelado conceptual orientado a objetos .............................................. 2.1.3 Métodos formales y OASIS ....................................................................

2.1.6 Programacion automatica ....................................................................... 13

. . . .. .. .. .. . .

3 . El lenguaje OASIS ....................................................................................................... . . . . .

. . . .

....................................................................................................

.. 3.1 1 Especificacion de protocolos ......................................................... : ............... 30 3.12 Especificacion de interfases ........................................................................... 31

4 . Desarrollo de prototipos en Java ................................................................................ 32

4.2 Arquitectura de los prototipos generados .................................................................... 35

..

4.1 Generación de modelos de ejecución (prototipos) ........................................... 33 4.1.1 Estrategia de generación de codigo ........................................................ 33 4.1.2 Estrategia de ejecucion ........................................................................... 33

35 4.2.1.1 Nivel de interfaz ........................................................................ 35 4.2.1.2 Nivel de aplicación .................. .............................................. 39 4.2.1.3 Nivel de persistencia ............... .................. 42

45

5.2 Estructuras de objetos usadas por GENCOD ................................................. 47

. . ..

4.2.1 Traducción del modelo conceptual a clases Java ...................................

4.2.2 Distribución de las clases generadas en una arquitectura WEB ............ 43

5.1 El programa GENCOD ................................................................................... 46 ................................ 5 . Desarrollo del programa generador de modelos de ejecución

5.2.1 Representación del esquema OASIS ...................................................... 48 5.2.2 Representación de la clase OASIS ......................................................... 49 5.2.3 Representación de una interfaz OASIS .................................................. 57

5.3 Arquitectura del GENCOD ............................................................................. 58 5.4 Funcionamiento del GENCOD ........................................................................ 63

6 . Pruebas ......................................................................................................................... 65 6.1 Validación de requisitos funcionales por animación ....................................... 66 6.2 Caso de estudio “Animación de un sistema bancario simple” ........................ 66

Conclusiones .................................................................................................................... 89 Principales aportaciones ........................................................................................ 90 Trabajos futuros ..................................................................................................... 91

Indice de tablas ................................................................................................................ 92 Indice de figuras ............................................................................................................. 93 Referencias bibliográficas ............................................................................................... 95

. .

. .

.. 11

Capítulo I introducción

Capítulo 1 Introducción En este capítulo se presenta la motivación y los objetivos de esta tesis. Además se incluye una descripción breve del contenido de los capítulos posteriores.

I ,I

Capítulo I Introducción

1.1 Motivación

La ingeniería de requisitos [Pho197, Wie96, Dav941, es un campo de reconocida importancia en el ámbito teórico y práctico de la ingeniería de software. Las mayores carencias y desafíos de la construcción de software se encuentran en las primeras actividades del proceso. En ellas, la principal dificultad radica en la distancia existente entre el espacio del problema (Universo de Discurso) y el espacio de la solución (el software construido). El modelo conceptual establece el vínculo entre ambos expresando los requisitos funcionales del sistema y constituyendo la base para las tareas siguientes en el desarrollo del sistema.

La construcción del modelo conceptual del sistema es un proceso de descubrimiento, no sólo para el analista, sino también para el usuario. La estrategia que más se ajusta a esta situación es construir un modelo conceptual de forma iterativa, con refinamientos sucesivos y mediante la interacción entre el usuario y el analista. En cada paso el analista debe verificar el modelo y validarlo respecto a las necesidades del usuario. Finalmente, una vez alcanzada la conformidad de las partes involucradas, el modelo conceptual se utiliza como entrada en las fases posteriores del desarrollo.

Errores u omisiones en el modelo conceptual tienen por lo general graves consecuencias en el resto del proceso de desarrollo de software. Por esto, la validación temprana de requisitos es una actividad de reconocida importancia. En este sentido, los enfoques más extendidos incluyen técnicas semiformales y en particular prototipación. Sin embargo, el resultado obtenido está lejos de ser satisfactorio. La combinación de técnicas formales con prototipación abre nuevas perspectivas, en especial la prototipación basada en especificaciones formales ejecutables denominada animación de especificaciones. El desafío en este caso está en la capacidad para obtener código ejecutable a partir de una especificación, más aún si se pretende conseguir la generación automática de dicho código. Precisamente una de las ventajas de un enfoque formal es el ofrecer un marco más apropiado para establecer un proceso de traducción desde una especificación hacia un programa. En este trabajo de Tesis se presenta el desarrollo de una primera versión de una herramienta para la generación automática de modelos de ejecución en el lenguaje de programación Java, para la animación de especificaciones OASIS (Open and Active Specification of Information Systems) [Let98]. Los modelos generados serán prototipos auxiliares en la validación de requisitos.

2

I

Capítulo 1

1.2 Entorno de desarrollo de la tesis

Introducción

Este trabajo se ha generado en el grupo de investigación de Ingeniería de Requisitos en Ingeniería de Software (IRIS) [Iris2000], perteneciente al Departamento de Ciencias Computacionales del Centro Nacional de Investigación y Desarrollo Tecnológico (CENIDET). El proyecto IRIS está enmarcado dentro de un gran proyecto iberoamericano de desarrollo de sistemas informáticos denominado Ingeniería de Ambientes de Software (IDEAS) [Ideas2000], cuyos objetivos en términos generales son:

La construcción de herramientas que ayuden en la producción de software incrementando su calidad y reusabilidad mediante un proceso fuertemente asistido o totalmente automático.

La adaptación, modificación y uso de métodos formales de especificación del estado, comportamiento y comunicación de los sistemas.

El desarrollo de sistemas de software basados en herramientas actuales (entornos de programación visual y subsistemas de bases de datos).

Promover el intercambio de conocimiento y tecnología entre países de iberoamérica

La capacitación de docentes e investigadores en el desarrollo de tecnología de software.

En CENIDET a través de IRIS, se pretende aprovechar los resultados obtenidos en IDEAS, complementarlos con investigaciones originales en el campo de la Ingeniería de Requisitos, para finalmente producir un ambiente para la especificación y desarrollo de prototipos de sistemas de información.

En IRIS, la idea fundamental es complementar los requisitos obtenidos directamente de los usuarios con una presentación clara y explicita del funcionamiento de la organización. Esta presentación de la organización es adquirida a partir de un análisis de las reglas y procesos de negocio. Ambos tipos de información deben ser validados e integrados en un modelo que caracteriza de manera más completa los requisitos de la organización.

Para llevar a cabo lo anterior se requiere de la crcación de ciertas herramientas y ciertos métodos que permitan:

Sistematizar la caracterización de la empresa con la finalidad de obtener requisitos. Sistematizar la determinación de las intenciones de los usuarios respecto a lo que esperan de la organización como del sistema informático. Administrar una base de requisitos de software. Obtener un esquema conceptual de la organización. Generador de prototipos a partir de un modelo conceptual.

3

P

Capitulo I

1.3 Objetivos Introducción

El objetivo general de este trabajo de tesis es desarrollar una primera versión de una herramienta que reciba como entrada una especificación formal en OASIS [Let981 y genere un prototipo didáctico que anime dicha especificación para efectos de validación. Se debe mantener la equivalencia funcional entre la especificación OASIS y el código del prototipo generado, utilizando el lenguaje Java [Chan97, JavaSun] para la implementación de la herramienta y los prototipos generados.

Los objetivos particulares de esta tesis son:

Sugerir un modelo abstracto de ejecución para especificaciones OASIS.

Establecer correspondencias entre OASIS y Java para efectos de traducción y generación de código.

Construir una versión preliminar de un programa que genere modelos de ejecución para la animación de especificaciones OASIS.

Generar modelos ejecutables funcionalmente equivalentes a especificaciones OASIS en Java.

1.4 Estructura de la tesis.

El trabajo de tesis se ha organizado en los siguientes capítulos:

Capítulo 1 : Introducción Capitulo 2: Antecedentes Capítulo 3: El lenguaje de Oasis Capítulo 4: Desarrollo de prototipos en Java. Capítulo 5: Desarrollo del programa generador del modelo de ejecución Capítulo 6: Pruebas Conclusiones

En el Capítulo 1 se presenta la motivación y los objetivos perseguidos en esta tesis.

En el Capítulo 2 se describe el marco teórico permitiendo ubicar adecuadamente el trabajo desarrollado y establecer su alcance. Adicionalmente se analizan algunos trabajos relacionados ilustrando el estado del arte.

En el Capítulo 3, se abordan conceptos referentes al lenguaje OASIS. Se describen también los elementos y secciones que componen una especificación formal en OASIS.

En el capítulo 4, se describen los puntos clave que han sido considerados para la generación de modelos ejecutables en Java, que reflejan la estructura y funcionalidad de una especificación escrita en OASIS.

5

Capítulo I Iniroducción

En el capítulo 5 , se presenta la arquitectura y funcionalidad del programa generador de modelos de ejecución GENCOD.

En el Capítulo 6 , se presenta un caso de generación de un prototipo en código Java, ilustrándose su equivalencia funcional con el modelo conceptual expresado en OASIS, a partir del cual se obtiene.

Por último se exponen las conclusiones obtenidas en la realización de este trabajo, resumiendo los alcances logrados, las mejoras y trabajos futuros.

6

Capítulo 2 Antecedentes

Capítulo 2 Antecedentes En este capítulo se describe el contexto en el cual se desenvuelve esta tesis, permitiendo enmarcar adecuadamente el trabajo desarrollado y establecer su alcance. Adicionalmente se analizan algunos trabajos relacionados ilvstrando el estado del arte.

7

Capitulo 2 Antecedentes

2.1 Marco teórico

En este trabajo se conjugan varios aspectos de la ingeniería del software. A continuación se hará una breve descripción de cada uno de ellos.

2.1.1 Ingeniería de requisitos

"Ingeniería de requisitos es el proceso para establecer los servicios que el sistema debería proveer y las restricciones bajo las cuales debe operar" [Som, 951. En general dichos servicios y restricciones se denominan requisitos. Un requisito funcional es aquel que describe un servicio o función del sistema, en cambio, un requisito no-funcional es una restricción impuesta sobre el sistema o el proceso de desarrollo.

Algunos problemas que afectan el éxito del proceso de ingeniería de requisitos son [LaB, 941:

Es potencialmente imposible definir un conjunto completo de requisitos. Se puede expresar con precisión un requisito conocido, pero no existe un método que nos diga qué debería ser especificado.

Es difícil obtener un conjunto consistente de requisitos. En sistemas grandes hay diversidad de usuarios, conflicto entre restricciones organizacionales y de presupuesto con respecto a necesidades de usuarios finales.

Los requisitos evolucionan constantemente, incluso durante el desarrollo del sistema.

No existen métodos satisfactorios para abordar esta fase y consecuentemente las herramientas disponibles no ofrecen una adecuada integración de técnicas.

Las barreras de comunicación entre los colectivos involucrados suelen ser un gran problema.

Los requisitos pueden establecerse en tres niveles de abstracción [Rare, 941: Requisitos organizacionales (relacionando al sistema con los objetivos y restricciones del negocio), requisitos del dominio del problema (describiendo el sistema en términos de las interacciones con su entorno) y requisitos del sistema (estableciendo la estructura y el comportamiento interno del sistema), En este sentido, nuestro interés se centra principalmente en el modelado de requisitos del sistema.

2.1.2 Modelado conceptual orientado a objetos

Un modelo conceptual de un sistema de información representa 10s requisitos del sistema, esencialmente los requisitos funcionales. El término conceptual se refiere al hecho de que el modelo está constituido por conceptos mediante los cuales el usuario y el analista interpretan y observan el espacio del problema. El modelado conceptual tiene sus raíces en el modelado semántico de datos [Yang92, Chi81, Hu1187, Ham811. Cuando se utiliza el enfoque orientado a

8

Capitulo 2 Antecedentes

objetos para el modelado conceptual, los requisitos funcionales son encapsulados bajo el concepto de objeto, incluyendo las perspectivas estática y dinámica del sistema estudiado. Durante la fase de modelado conceptual se llevan a cabo esencialmente cuatro tareas [Dub91]:

1. Captura de requisitos.-Descubrir lo que el usuario quiere obtener como sistema.

2. Modelado.- Describir el modelo concephial del sistema

3. Análisis.-Verificar que el modelo satisface ciertos criterios de calidad y consistencia.

4. Validación.- Determinar si el modelo conceptual reúne los requisitos informales obtenidos del usuario.

Estas tareas se repiten hasta que en 4) se obtiene la conformidad del modelo conceptual respecto de los requisitos informales del usuario.

2.1.3 Métodos formales y OASIS

Una manera de apoyar la construcción de software más fiable es utilizar métodos formales [Win90, NASA95, Lug97, Gold961. Los métodos formales ofrecen para el desarrollo de software una mejora en la calidad del producto y reducción de costos de construcción y mantenimiento. Sin embargo, la introducción de métodos formales no ha sido inmediata y sólo en la actualidad comienzan tímidamente a ser introducidos en el entorno industrial de desarrollo de software [Crai95]. Cuatro razones explican esta situación [Hin96]: falsas expectativas o desconocimiento, carencia de estándares para métodos y su aplicación, falta de herramientas integradas en entornos CASE y finalmente precaria preparación entre sus usuarios potenciales.

La verificación y validación del modelo conceptual exigen disponer de algún formalismo preciso y a la vez con la suficiente capacidad expresiva, necesaria para capturar los aspectos de interés del problema. En la práctica, los requisitos del usuario son representados mayoritariamente utilizando modelos semiformales, entre ellos los métodos no orientados a objetos [Jac83, You891 y los orientados a objetos [Rum91, Boo96, Jac92, Mar98, Sh192, Mar961. Notacionalmente los métodos orientados a objetos más conocidos han sido integrados en el Unified Modeling Languaje (UML) [Pastor97].

OASIS [Let981 es un enfoque orientado a objetos y formal para la especificación de modelos conceptuales de sistemas de información. En OASIS un sistema de información es visto como una sociedad de objetos autónomos y concurrentes que se comunican entre sí a través de acciones. OASIS en su primera versión [Pastor921 fue formalizado a través de lógicas de Primer Orden que evolucionan con el tiempo. Este enfoque lo situó históricamente en un entorno de Programación Lógica complementado con un monitor para la gestión de la perspectiva dinámica del sistema. A partir de la segunda versión [Pastor951 se cambió de marco formal y se trabajó en el contexto de una variante de la Lógica Dinámica [Har84] que permite representar los operadores de obligación, prohibición y permiso usados en Lógica

9

Capitulo 2 Antecedentes

Deóntica [Gab84]. En este marco, OASIS tiene una base formal más completa para el tipo de problema que se quiere resolver.

Otros enfoques formales con una motivación similar a la de OASIS son: TROLL [Jun95], LCM [Fee93], ALBERT [Dub93], OBLOG [OBL99] y TESORO [Tor97]. Sin entrar en detalles de comparación, sólo se destacará que a diferencia de otros enfoques formales, en OASIS desde sus primeras versiones se ha puesto especial interés en tres aspectos esenciales que facilitan su integración en entomos industriales de desarrollo de software:

Construcción de herramientas que soporten el proceso de modelado conceptual. Se ha construido un entomo CASE basado en OASIS y adaptado a 00-METHOD [Pastor96].

Establecimiento de un método de desarrollo basado en OASIS, llamado 00-METHOD [Pastor97].

Generación automática de código a partir de especificaciones OASIS, orientada tanto a la validación de requisitos (interés de esta Tesis) como a la construcción del producto final (Pastor981.

Por otra parte, si se compara el procedimiento seguido por las propuestas semiformales para modelado orientado a objeto más populares respecto del enfoque que se ha seguido en el desarrollo de OASIS, se puede observar que son contrapuestos. En OASIS un aspecto importante ha sido el reducir la notación y técnicas a un conjunto pequeño y coherente, con la suficiente expresividad y con un significado preciso, evitando así problemas de “interferencia semántica” [OBL99] entre los diferentes aspectos del lenguaje. Esta estrategia es opuesta a la seguida en el desarrollo de UML, en el cual se han fundido varias notaciones para posteriormente intentar establecer una interpretación y un método de aplicación globales. En el caso de OASIS, después de establecer los conceptos fundamentales, es relativamente sencillo establecer una notación o buscar alguna entre las notaciones existentes y adaptarla, incluso se puede utilizar parte de la notación de UML.

2.1.4 Validación y verificación

La noción de corrección para el software está inherentemente limitada. Para abordar un sistema basado en computadora debe comprenderse su hardware, su software y su entorno, y cómo es la interacción entre ellos. En la medida que los sistemas de información a desarrollar son más complejos quedan en evidencia las deficiencias de su proceso de construcción. En particular es reconocida la dificultad para verificar sistemas concurrentes y/o distribuidos. Cada vez existe mayor preocupación respecto de los posibles daños por errores en sistemas de información, más aún cuando se trata de posibles problemas para las personas (safe@ critical systems). Estos factores de complejidad se presentan frecuentemente en sistemas de tiempo real y/o “empotrados”. Se trata pues de una cuestión de confiabilidad asociada a la calidad del producto de software construido. La validación y verificación del producto desempeñan un papel esencial para asegurar la calidad del software. La validación y verificación (V & V) son las tareas encargadas de asegurar la calidad del producto de software y se definen como [Boe79] :

10

Capitulo 2 Antecedentes

Validación.- ¿Estamos construyendo el producto correcto?, es decir, comprobar que el sistema reúne las expectativas del usuario,

Verificación.- ¿Estamos construyendo correctamente el producto?, es decir, comprobar que el sistema satisface su especificación.

Si la validación y verificación no son las adecuadas, los errores en los requisitos se propagarán hacia las fases posteriores. El costo de modificar un sistema debido a un error en los requisitos, se considera generalmente mucho mayor que el costo de reparar un error de programación, puesto que existe un efecto de amplificación del impacto del error al pasar de una fase a otra. Así, mientras más tarde se corrija un error más costoso resulta repararlo.

Las técnicas para validación y verificación pueden clasificarse en [Som, 951:

Técnicas estáticas.- Se centran en el análisis y comprobación de la representación del sistema, incluyendo documentos, diagramas y código.

Técnicas dinámicas.- Implican ejecutar algún tipo de implementación del sistema. e

Podría parecer que sólo con las técnicas estáticas es suficiente pero esto no tiene mucho sentido puesto que las técnicas estáticas se orientan más bien a la verificación y no pueden demostrar que el sistema satisface las expectativas del usuario (validación). En este trabajo el interés es apoyar a las técnicas dinámicas al proveer una herramienta para la animación y validación del modelo conceptual.

La prototipación y las pruebas de programas son técnicas dinámicas. En ambos casos es importante tener presente la célebre frase de W. Dijkstra:

"las pruebas pueden demostrar la presencia de errores pero no su ausencia".

En prototipación normalmente se cuenta con una implementación parcial (en a l g h sentido) del sistema, en cambio las pruebas del programa se realizan sobre todo o parte del producto ya construido. Las pruebas de programa son útiles principalmente para la verificación del sistema.

A continuación se presenta una clasificación de técnicas específicas para la validación de modelos conceptuales [Dub94]:

e Técnicas de conversión.- Presentan el modelo conceptual en una forma más fácil de ser comprendida por el usuario.

Técnicas de comportamiento.- Presentan una ejecución de la especificación, lo que permite en un sentido amplio observar y experimentar propiedades de la especificación. La prototipación se incluye en este grupo.

e

1 1

Capitulo 2 Antecedentes

Técnicas de análisis.- Se basan en el estudio de trazas posibles obtenidas de la especificación y contrastadas con el comportamiento esperado. Para obtener trazas de la especificación pueden utilizarse técnicas de comportamiento.

En cualquier técnica de validación es necesario contrastar en algún sentido la especificación con los requisitos informales del usuario. Lo más inmediato es incluir ai usuario en el proceso de validación y utilizar técnicas de conversión junto con técnicas de comportamiento.

2.1.5 Prototipación y animación

Las dificultades encontradas para validar con mayor precisión el modelo conceptual del sistema han impulsado la utilización de técnicas de prototipación. La existencia de errores y omisiones constituye un riesgo significativo en el modelado conceptual. Los objetivos de un prototipo pueden ser: determinar las interfaces, validar los requisitos funcionales y/o demostrar la factibilidad del sistema. Un argumento común contra la prototipación es su costo, el cual puede ser considerable.

Normalmente, el prototipo exhibe sólo algunos aspectos del sistema, dejando de lado otros como eficiencia, seguridad, confiabilidad, etc. Un prototipo puede orientarse a ilustrar detalles de ciertas partes de la funcionalidad total (propotipado vertical) o mostrar toda la funcionalidad sin llegar a implementar funciones específicas (prototipado horizontal). En la práctica ambos enfoques se mezclan.

Por otra parte, los prototipos pueden clasificarse en prototipos desechables y prototipos evolutivos. El objetivo de un prototipo desechable es capturar y validar los requisitos del usuario, una vez cumplido este propósito el prototipo es desechado. En este caso el prototipo es construido desde una especificación obtenida experimentalmente y modificada hasta obtener la conformidad del usuario. Con un prototipo evolutivo se pretende llegar a la versión definitiva del producto mediante refinamientos sucesivos.

Algunas herramientas para construcción de prototipos son: lenguajes de especificación ejecutables, lenguaje de muy alto nivel y generadores de aplicaciones en lenguajes de cuarta generación. La utilización de un lenguaje de especificación ejecutable y formal resulta particularmente atractiva pues combina una especificación no ambigua con prototipación, sin haber costos adicionales una vez que la especificación ha sido escrita. La prototipación de una especificación orientada a la validación de requisitos, se denomina "animación" [Dub94, Har93, Sid971.

Desde el punto de vista de la validación de requisitos, un prototipo permitiría descubrir un comportamiento no deseable mediante una simple interacción con él. La prototipación tradicional permite sólo validación exploratoria pues generalmente el prototipo provee la interfaz del producto final, sin ofrecerse mecanismos que permitan concentrarse en acciones acontecidas o facilitar la observación del estado de los objetos. Esta última característica proporciona una validación más clara y útil, que es conveniente sea tomada en cuenta en la construcción de prototipos que interactúen con el analista y el usuario.

12

Capítulo 2

2.1.6 Programación automática Antecedentes

El paradigma de programación automática enunciado por Balzer [Ba183, Ba185J parece estar en Su apogeo, aunque no siempre basado en métodos formales, como se propuso originalmente, sino más bien en métodos semiformales. La generación automática de código a partir de especificaciones (preferentemente gráficas) es un tema actual de gran interés en ingenieria de software. La automatización de las fases del desarrollo ha determinado una tendencia histórica en la evolución del proceso de desarrollo de software, según la cual actividades realizadas inicialmente de manera informal son mas tarde formalizadas y finalmente automatizadas (con poca o ninguna intervención del desarrollador) [Dav93]. La generación de código a partir de modelos conceptuales no es más que la continuación de dicha tendencia. El desarrollo de software se concentra cada vez más en la parte más creativa e irreemplazable (no automatizable completamente) del proceso, es decir, el análisis y la especificación del sistema.

Para la mayoría de los métodos semiformales se han construido entornos CASE que permiten llevar a la práctica su perspectiva de ingeniería del software. En ellos, la posibilidad de conseguir automáticamente código ejecutable es una característica muy valorada. El resultado conseguido va desde plantillas de código y definiciones de bases de datos hasta aplicaciones completas incluyendo el código compilado y la creación de la base de datos [Pop97, Rose981. Sin embargo, el software obtenido sigue padeciendo los mismos defectos asociados al proceso de desarrollo sin automatización. La razón es que en la mayoría de 10s Casos la m u m a de consmir los sistemas no se cambia, sólo se automatizan técnicas y procedimientos CUYO rigor es cuestionable.

Eyiecilicaci6n

Manlenim'enlo

Formal

I n - Manlenim'enlo Figura 2.1: Paradigma de programación automática

La Figura 2.1 (extraída desde [Bai85]) ilustra un paradigma ideal de programación automática. Se distinguen dos fases globales: especificación (incluyendo validación) y transformación. Las características principales de este paradigma son: la especificación es formal y ejecutable

13

Antecedentes Capítulo 2

(constituye el primer prototipo del sistema); la especificación es validada mediante prototipación; a través de transformaciones formales la especificación se convierte en la implementación del sistema; en el último paso de transformación se obtiene una implementación en un lenguaje de programación determinado. Las pruebas que verifican la correspondencia con la especificación no son necesarias, el mantenimiento se realiza sobre la especificación (no sobre el código fuente), la documentación es generada automáticamente y el mantenimiento es realizado por repetición del proceso (no mediante parches sobre la implementación). La capacidad de ejecución de una especificación ha sido tema de debate, contando con simpatizantes [Fuch92] y detractores [Hay90]. Uno de los aspectos más cuestionados es la conveniencia de eliminar.la mítica frontera entre especificar el "qué" y el "cómo" [Sid94] que históricamente ha diferenciado análisis respecto del diseño del sistema. Una especificación ejecutable tiene inevitablemente que incorporar ciertos aspectos asociados comúnmente a decisiones de diseño.

Sin embargo, la falta de ejecutabilidad hace que una especificación de análisis requiera mucho trabajo para convertirla en una especificación de diseño. En este sentido, el paradigma propuesto por Balzer es conciliador de ambas posturas pues está basado en transformaciones sucesivas de la especificación hasta obtener una implementación definitiva. Inicialmente la especificación es informal y no ejecutable, a continuación pasa a ser formal y ejecutable, posteriormente mediante refinamientos formales sucesivos llega a ser el producto final, manteniendo la equivalencia semánticamente respecto de la especificación original.

En [Be11981 se hace una clasificación del estado actual en generación automática de código a partir de modelos, estableciendo tres enfoques: estructural, de comportamiento y de traducción.

En el enfoque estructural la generación de código es incompleta y se centra en los aspectos de estructura del código. Este enfoque es el que más se ajusta a la mayoría de las metodologías orientadas a objetos en las cuales se hace un desarrollo incremental pasando en forma gradual desde análisis a diseño y posteriormente a código.

El enfoque de comportamiento se basa en añadir especificaciones de acciones a los diagramas de transición de estado, lo cual asociado a los modelos de objetos y de comunicación permite generar código que puede ser ejecutado. Sin embargo, el código generado no suele ser la versión definitiva.

El enfoque de traducción está basado en establecer un modelo de aplicación y uno de arquitectura, ambos independientes. El modelo de la aplicación determina para los objetos su estructura, comportamiento y comunicación. El modelo de arquitectura es un conjunto de reglas que traducen los constructores del modelo de aplicación en código fuente considerando aspectos específicos del entorno de implementación. El enfoque de traducción es el que incluye mayor grado de automatización. Sin embargo, no es sencillo definir un modelo de arquitectura específico, existen muchos factores en un entorno de implementación que hacen necesario combinar conocimientos técnicos de diversas áreas (lenguajes de programación, sistemas operativos, redes, etc.).

14

Capitulo 2 Antecedentes

2.2 Descripción del trabajo de tesis

De acuerdo con lo presentado en la sección anterior, este trabajo de Tesis se sitúa en un marco que combina lo siguiente:

Utilización de OASIS como enfoque formal para describir modelos orientados a objetos.

Animación de especificaciones OASIS. A partir de una especificación OASIS se obtiene automáticamente un prototipo del sistema, orientado a la validación del modelo conceptual y funcionalmente equivalente a la especificación. Es decir, se aborda la primera fase del paradigma de programación automática de Balzer.

Formalizar el necesidades requisitos

0 Producir una

especificación Prototipo generado

Fig. 2.2 Modelado de requisitos basado en OASIS

La Figura 2.2 ilustra el proceso de modelado conceptual en OASIS, orientado a la validación mediante animación de un prototipo generado automáticamente. En la captura de requisitos se considera la utilización de alguna técnica para que el analista extraiga de las necesidades del usuario los elementos de especificación que conformarán la especificación de requisitos. En este aspecto, es importante destacar que esta labor no es una tarea sencilla y la calidad del resultado depende en gran medida de la capacidad del analista. Para la representación del modelo conceptual se utilizan técnicas principalmente gráficas que guardan una correspondencia directa con elementos de una especificacion OASIS. Así, para el analista resulta implícita la utilización de OASIS, más aún si se utiliza una notación gráfica basada, por ejemplo en UML y utilizando sólo los elementos de UML que sean útiles desde el punto de vista de OASIS, La verificación de consistencia del modelo conceptual consiste en comprobar las restricciones del modelo OASIS. Gracias a utilizar un modelo formal es posible realizar una verificación exhaustiva de este modelo mediante técnicas estáticas.

15

Antecedentes Capitulo 2

Mediante un traductor, a Partir del modelo conceptual OASIS se genera un prototipo orientado a la validación del modelo conceptual. El prototipo está codificado en lenguaje Java, EI analista puede interactuar directamente con el prototipo, solicitando y observando las acciones acontecidas y los estados alcanzados por los objetos del sistema.

La actividad de validación es llevada a cabo contrastando el comportamiento esperado del prototipo respecto del comportamiento exhibido por la animación de la especificación.

La propuesta descrita tiene las particularidades siguientes:

La validación podría comenzar apenas disponga de una versión del modelo conceptual. Para la generación automática sólo debe verificarse que el modelo conceptual sea consistente y completo (al menos de acuerdo con lo mínimo establecido para efectuar la generación automática del prototipo ).

El prototipo es generado para funcionar en ambientes WEB, dado el gran auge que en la actualidad se ha dado a este tipo de aplicaciones. Si bien es cierto que sólo se trata de prototipos y que no se genera aún un producto final de software, si se logra una aproximación de éste último.

El proyecto de tesis se resume en el siguiente párrafo:

Se establecen las bases para la generación automática de modelos de ejecución (prototipos), para la animación de especificaciones OASIS. Se ha construido una versión preliminar de una herramienta con la cual, a partir de un modelo conceptual en OASIS, se obtiene de forma automática un prototipo funcionalmente equivalente a la especificación, que ayuda a la validación de requisitos y que permita concentrarse al usuario y analista en las acciones o eventos acontecidos, así como facilitar la observación del estado de los objetos involucrados. Para la implementación del prototipo se ha utilizado el lenguaje de programación Java.

2.3 Trabajos relacionados

La mayoría de las herramientas CASE comerciales [InRose] incluyen en alguna medida generación automática de código, principalmente en lenguajes imperativos y en especial C++. Sin embargo, resulta dificil establecer con precisión la calidad del código generado automáticamente. Como suele suceder, existe una notable diferencia entre la información ofrecida por el proveedor y las verdaderas cualidades de la herramienta. Además, por ser un tema candente, las frecuentes nuevas versiones de las herramientas dejan obsoleta cualquier comparación. Sin embargo, como referencia, a continuación se presentan algunos comentarios que reflejan el estado del arte desde la perspectiva de las propuestas existentes en el ámbito académico y comercial.

Rational Rose de Rational [Rose] (en la que participan Booch, Jacobson y Rumbaugh) genera plantillas de código muy elementales (siguiendo el enfoque estructural para la generación de código).

16

Capitulo 2

Dos herramientas que usan el enfoque de Comportamiento para generación de código son: (relacionada con Harel) y ObjecTime [OTime] (incluye ROOM,

Real-Time Object-Oriented Method). En estas herramientas es posible obtener prototipos ejecutables a partir de los modelos establecidos.

Varias herramientas proveen un lenguaje de scripts mediante el cual se puede adaptar la generación de código a distintos estilos y arquitecturas de programación para una determinada configuración hardware-software (coincidiendo así con el enfoque de traducción para la generación de código). Así, el grado de automatización conseguido depende de la calidad del script utilizado. Este es el caso de System Architect de Popkin Software & Systems [Pop] que trae predefinido un conjunto de scripts muy rudimentarios para generar código en varios lenguajes, pero que tienen que ser modificados en gran medida para obtener un resultado útil.

En OBLOG [Oblog] se dispone de un editor de reglas de traducción, sin embargo, el lenguaje utilizado no resulta muy amigable. En Bridgepoint de Project Technology Inc. [Bpoint] (relacionada con Shlaer y Mellor y su propuesta metodológica) se ofrece como módulo adicional un conjunto de arquitecturas (llamadas model compilers que incluyen reglas de traducción y librerías) específicas para distintos entomos y usadas como entrada para el proceso de generación de código.

Un enfoque similar utiliza 00-METHOD CASE, en el cual la traducción se orienta hacia un producto final considerando una determinada arquitectura, pero sin posibilidades de ser modificada por el usuario de la herramienta. Por otra parte, y centrándose exclusivamente en la validación de requisitos mediante animación de la especificación, pocas herramientas proporcionan una ayuda de este tipo. Aunque algunas herramientas son capaces de generar un prototipo ejecutable, normalmente no se ofrecen facilidades específicas para la validación utilizando dicho prototipo. La razón es que en la mayoría de los casos el objetivo perseguido es la generación del producto final, con lo cual el prototipo no está pensado para facilitar la validación de requisitos.

Una excepción la constituyen algunas herramientas cuyo ámbito de aplicación incluye sistemas de tiempo real y sistemas empotrados. Entre ellas se puede incluir a Rhapsody, ObjecTime y Bridgepoint (en OBLOG existe un módulo de animación pero aún no está comercialmente disponible). En Rhapsody y ObjecTime (y en OBLOG, pero aún en construcción) se incorpora una representación gráfica en diagrama de secuencia en el cual se representan escenarios como secuencias de las interacciones entre objetos a través del tiempo.

En este sentido, Aonix [AONIX] proporciona un módulo llamado "Validator" que incorpora edición, ejecución y evaluación de escenarios.

En estos productos el proceso de validación se dirige a contrastar trazas obtenidas por ejecución del prototipo. En ObjecTime se provee un procedimiento para contrastar automáticamente escenarios así especificados. En Bridgepoint la validación se realiza monitoreando el prototipo en distintos niveles (acción, sentencia y componente) pero es difícil determinar variaciones respecto al comportamiento esperado pues la interfaz y el enfoque seguido se acercan más a la funcionalidad de un depurador de código fuente.

Antecedentes

de I-LOgiX

17

Capitulo 2

Estas propuestas presentan el inconveniente de estar basadas en modelos donde el comPortamiento es especificado de f 0 m a imperativa con 10 cual la validación ,jebe establecerse en un nivel de abstracción bastante más bajo que el presente en el espacio del Problema. El caso de OBLOG podría ser una excepción puesto que se originó en un contexto formal Y declarativo, sin embargo, no se ha contado con información para poder constatar si dichas características se mantienen en ia versión comercial. En los últimos años se ha registrado gran interés en torno a ia validación de especificaciones formales mediante su animación [siS97]. LOS trabajos más próximos al desarrollado en esta Tesis corresponden a Propuestas para validación mediante animación en lenguajes formales cercanos en motivación a OASIS, por ejemplo los trabajos de animación en TROLL, en ALBERT y en TESORO.

En lo que respecta a TROLL, en [Har93] se establecieron los conceptos y una arquitectura general para dar soporte de animación a una especificación en dicho lenguaje. Posteriormente, en [Gog95] se bosqueja un ambiente para animación de especificaciones TROLL iigth (un dialecto de TROLL). En [Herz94] se describe un prototipo muy preliminar de dicho ambiente, en el cual es posible explorar el estado de objetos, introducir ocurrencias de eventos y visualizar cambios de estado. Finalmente uno de los últimos trabajos de los que se tiene constancia es [Gra97], en el cual no parece haber adelantos significativos respecto de las publicaciones anteriores.

En cuanto a ALBERT, en [Dub941 se presenta el diseño (en términos muy generales) de un ambiente para animación de especificaciones ALBERT. En [Hey97a] se propone comprobar escenarios respecto de la animación de una especificación ALBERT y se establece un proceso de validación basado en animación. En [Hey97b] se describe la funcionalidad y arquitectura para un módulo de animación de especificaciones ALBERT, además se presenta un prototipo muy rudimentario de una herramienta, donde la principal novedad respecto a trabajos anteriores en ALBERT es el manejo de varias sesiones de animación a la vez, posibilitando la validación cooperativa de escenarios. En [Hau98] se describe un método que integra captura de requisitos junto con validación mediante animación.

Finalmente, en TESORO se han realizado algunos trabajos de prototipación pero orientados específicamente al estudio de protocolos de comunicación [Cor99]. En resumen, en los enfoques cercanos a OASIS aunque existen precedentes en animación (automática en algunos casos), aún no existen resultados consolidados en lo que se refiere a herramientas disponibles, los entomos descritos son de carácter preliminar. AI contrastar los resultados presentados con las arquitecturas y funcionalidad preestablecidas en las publicaciones analizadas queda en evidencia que todavía hay mucho trabajo por realizar. Además, es importante destacar que en las publicaciones antes referenciadas no se proporcionan detalles del enfoque ni modelo de implementación utilizado, en este aspecto sólo se indica su existencia utilizando términos como TROLL-Kernel o ALBERT-Core. En el caso de OASIS se ha desarrollado una herramienta CASE (00- METHOD CASE) basada en OO-METHOD.

Sin embargo, tanto en 00- METHOD y como en el CASE asociado, el esfuerzo se ha concentrado en la obtención automática del producto final. De esta forma, sólo es posible realizar validación sobre el producto final. Por lo tanto, además del trabajo desarrollado en esta Tesis, no existen precedentes en io que respecta a técnicas específicas para la validación

Antecedentes

18

Capítulo 2

de Antecedentes

OASIS mediante animación. Con la realización de esta tesis, en este OASIS queda en una situación favorable respecto de TROLL y ALBERT,

prototipado a Partir de especificaciones formales, es un punto de interés sobre el que convergen diversos trabajos que permiten la traducción de una especificación formal a distintas clases de lenguajes de implementación, dentro de 10s que se incluyen: . Lenguajes lógicos

Lenguajes concurrentes Lenguajes orientados a objetos

Para OASIS existen diferentes versiones de prototipado, usando lenguajes lógicos destino como Prolog [Men98], el sistema de gestión de bases de datos deductivas, activas y orientadas a objetos KAOS [Men98], la TF-Logic [Men981 y lenguajes lógicos concurrentes [Men98].

Existen también trabajos, que tomando como base OASIS, pretenden generar código en lenguajes concurrentes. Se ha trabajado con Parlog [Con891 y KLI[Let97] como lenguajes lógicos concurrentes, cuyas propiedades son similares. La razón de la selección de estos lenguajes es que presentan una correspondencia clara y directa con muchas de las características de la estructura de OASIS.

En lo que respecta a lenguajes orientados a objetos, se han implementado diversas alternativas de generación de código a partir de OASIS, en entornos como C++, Delphi, Visual C++, etc.

En el trabajo a desarrollar en la tesis, se pretende contribuir proponiendo un mecanismo que utilice como lenguaje de implementación el lenguaje Java, y como lenguaje de especificación el OASIS. Creemos que el utilizar Java como lenguaje de implementación se justifica por dos razones principales:

El obtener prototipos en Java, además de servir como una herramienta de validación de requisitos nos acerca más a la implementación final de un producto de software, a diferencia del uso de lenguajes con carácter más declarativo.

Un prototipo en Java puede ser probado prácticamente en cualquier plataforma que soporte una máquina virtual de Java, además de flexibilidad que brinda el lenguaje por su enfoque orientado a objetos (al igual que OASIS).

El uso del lenguaje Java permite abarcar en forma completa la especificación de OASIS, ya que los lenguajes en los que se había traducido hasta ahora no permiten implementar aspectos como concurrencia, persistencia de objetos, etc, aspectos que aunque en esta tesis no son considerados, son un requisito para contar con un prototipo completamente funcional, los cuales serán abordados en posteriores investigaciones.

19

Capítulo 2

2.4 Alcances del proyecto Antecedentes

En una primera versión de la herramienta a desarrollar, el proceso de prototipación se ha restringido a algunos aspectos expresivos de OASIS. Las reglas para la generación automática de código Java a partir de la especificación en OASIS se basarán tomando en cuenta los siguientes conceptos OASIS,

Clases individuales

Identificadores de objetos Eventos Privados Restricciones de integridad simples Evaluaciones Precondiciones Disparos (triggers) Protocolos (en su mínima expresividad) Un solo cliente para cada acción. interfaces (relaciones de agente)

Existen otras características importantes que no se ha tratado, pero pensamos que con las elegidas es posible ilustrar la manera de obtener prototipos a partir de OASIS y efectuar validación de requerimientos para especificaciones de clases, considerando al menos un comportamiento restringido de ellas. Entre los aspectos no tratados y que podrían incorporarse a futuro tenemos:

Atributos (constantes, variables y derivados)

Eventos compartidos Transacciones Soporte completo para especificación de clientes en evaluaciones, precondiciones y procesos.

Clase complejas (obtenidas por agregación y herencia)

20

Capítulo 3 El lenguaje OASiS

Capítulo 3 El lenguaje OASIS Dada su utilización en el trabajo de tesis, el presente capítulo realiza una presentación de los conceptos fundamentales del lenguaje OASIS y la sintaxis de las secciones que han sido tomadas en cuenta para la realización de este trabajo de tesis.

21

Capítulo 3

3.1 Descripción general El lenguaje OASIS

OASIS (Open and Active Specification of information Systems), es un lenguaje de especificación formal orientado a objetos (00) para el desarrollo de Sistemas de Información,

En OASIS un sistema de información es entendido como una sociedad de objetos autónomos y Concurrentes que interactúan entre ellos mediante acciones.

Cada objeto encapsula Su estado y las regias que rigen su comportamiento. LOS objetos pueden ser vistos desde dos perspectivas distintas: estática y dinámica. Desde el punto de vista estático, llamaremos atributos al conjunto de propiedades que describen estmcturalmente al objeto. LOS valores asociados a cada propiedad estructural del objeto caracterizan el estado del objeto en un instante dado. La evolución de los objetos (perspectiva dinámica) viene caracterizada por la noción de cambio de estado: la ocurrencia de una acción puede generar cambios (definidos por evaluaciones y derivaciones) en los valores de los atributos. La actividad de un objeto está determinada por un conjunto de reglas: precondiciones, restricciones de integridad, disparos, protocolos y operaciones. La vida de un objeto puede representarse como una secuencia de pasos; cada paso está formado por un conjunto de acciones que ocurren en un instante de la vida del objeto [Let98].

Cada objeto tiene un identificador único (oid) proporcionado implícitamente por el sistema. Sin embargo, el objeto es referenciado mediante mecanismos de identificación pertenecientes al espacio del problema. Una función de identificación establece correspondencia entre los mecanismos de identificación y el oid del objeto [Let98].

El tipo es la plantilla que describe la estructura y el comportamiento de un objeto. Una clase se compone de un nombre de clase, una o más funciones de identificación y un tipo. Una clase compleja es aquella definida utilizando otras clases. Las relaciones entre clases disponibles en OASIS son agregación y herencia [Let98].

Las interfaces son un mecanismo que permite establecer relaciones de accesibilidad entre objetos, definiendo la visión que tiene cada objeto respecto de la sociedad de objetos.

OASIS emplea una metodología formal en la construcción y especificación del desarrollo de un sistema de información. Cuando se construye la especificación de un sistema, se especifican clases.

Para formalizar la funcionalidad de las clases se introduce la noción de metaclase. La metaclase es una clase cuyas instancias (también denominadas metaobjetos) son objetos “especiales” que a su vez son clases de objetos. Todos los objetos son instancias de alguna clase y las clases son a su vez instancias de la metaclase. De esta manera, las clases son objetos de primera categoría y pueden ser tratadas de la misma manera que los objetos. Para cerrar el ciclo y no tener una jerarquía (potencialmente infinita) de metaclases se realiza el cierre reflexivo de la metaclase diciendo que es instancia de sí misma. En la Figura 3.1 [Let981 se observa la jerarquía que relaciona la metaclase, las clases y los objetos que van a poblar los esquemas conceptuales a través de la relación is-instance-of:

22

Capitulo 3 El lenguaje OASIS

nivel metaclase

nivel de clase

nivel de objetos

Las instancias de la metaclase poseen una doble visión que puede ser observada en la figura 3.2. Por un lado, son clases de objetos en las que se definen las propiedades estructurales que comparten todas sus instancias (la plantilla), son la factoría y el almacén de sus instancias. Por otro lado, son objetos con un estado (representado los atributos evaluados), y una dinámica (expresada por los ciclos de vida posibles). El estado de los metaobjetos, almacena la plantilla de la clase en atributos variables que contienen todas las seccciones que describen la misma. Así, los eventos que manipulan el estado son capaces de modificar la plantilla de la clase. En el ejemplo se pueden observar 10s servicios que proporciona el metaobjeto: añadir un atributo constante, añadir un evento, etc.

(clase)

oid,

poblacion(oid6, ...) siguiente-oid

className="libro" Author: string list-ev Purchase: date

Title: string / list-an-cte list-att-var

new(alta-libro) I /

/ (objeto)

addCteAtt

addEve

destroy(baja-libro) ...

Figura 3.2 Ejemplo de la doble visión de una metaclase

23

Capítulo 3 El lenguaje OASIS

3.2 Definiciones

Es esta sección de definen algunos conceptos teóricos importantes relacionados a OASIS:

Atributo: Es un par , siendo nombre el identificador del atributo y sort de evaluación un conjunto de valores que puede tomar dicho atributo.

Servicio: es un evento (abstracción de un cambio de estado, atómico e instantáneo) o una operación (servicio no atómico y que en general tiene duración).

Accia'n: es una tupia , que representa tanto la acción asociada a requerir el servicio en el objeto cliente como la acción asociada a proveer el servicio en el objeto servidor.

Plantilla o tipo: Una plantilla de clase está representada por una tupla .

Atributos es el alfabeto de atributos evaluados. Eventos es el alfabeto genérico de eventos. V e EEventos podemos obtener g=0e

siendo 0 una substitución básica de los posibles parámetros del evento. Fórmulas es un conjunto de fórmulas en diversas lógicas según sea la sección del

lenguaje donde se utilizan. Procesos es el conjunto de especificaciones de proceso. Cada proceso se especifica

usando un cálculo de procesos basado en un subconjunto del lenguaje propuesto en CCS(Calcu1us of Communicating Systems) [Let98]. Las especificaciones de proceso se clasifican en operaciones y protocolos.

Para cada clase, se asume la existencia implícita de un conjunto A de acciones a partir de los servicios que los objetos de la clase pueden requerir (cuando son clientes) o proveer (cuando son servidores). Va E Acciones podemos obtener @=Bu siendo 0 una substitución básica de los posibles cliente, servidor y servicio.

Términos

- Cada constante perteneciente a un determinado sort es un término de dicho sorf - Cada variable es un término de su sori de definición. - Sif: SI X S ~ .,.Xs,+ s es una función de paridad n, y 11, 12, ..., t,son términos, donde cada ti pertenece al sort si, entoncesf(t1, t2, ..., I,) es un término del sori s. - Cada atributo de la plantilla es un término de su sorf de evaluación. - Sólo son términos aquellos construidos siguiendo las reglas anteriores

24

Capítulo 3

Átomos El lenguaje OASIS

- Las constantes true yfalse son átomos, si t / Y t2 son términos del mismo sort, y R es uno de los siguientes operadores relacionales

=) O,

Capítulo 3 El lenguaje OASIS ~. Para exponer la sintaxis de un determinado elemento del lenguaje se usarán las

siguientes simplificaciones: x es un elemento en particular, para describir un bloque de elementos x usaremos ; para una lista de elementos x se usará . Los significados asociados a cada uno de ellos se establecen a continuación.

-

A continuación se explican algunos símbolos no terminales utilizados:

el no terminal hace referencia a una fórmula bien formada en lógica de predicados de primer orden, basada en valores constantes, atributos y/o parámetros de acciones.

el no terminal es una expresión booleana o aritmética basada en valores constantes, atributos y/o parámetros de acciones.

el no terminal es un elemento de alguna especie de los dominios permitidos

3.3 Esquema conceptual

El modelo conceptual de un sistema de información se corresponde en OASIS con la especificación de un esquema conceptual, el cual es la base de toda especificación formal escrita en OASIS. Su sintaxis se ilustra en la tabla 3.1.

Sintaxis ::= Conceptual schema

Capítulo 3 El lenguaje OASIS

Sintaxis:

class [] [] [] [] [] [] [] [] end class

Tabla 3.2 Plantilla de una clase en OASIS

3.4 Atributos

El estado de un objeto en OASIS se observa mediante los valores de sus atributos. En OASIS se distinguen tres tipos de atributos:

Atributos constantes: Aquellos que toman su valor cuando se crea el objeto y no lo cambian a lo largo de su vida.

Atributos variables: Aquellos cuyos valores pueden cambiar cuando ocurre un acción relevante.

Atributos derivados: Aquellos cuyos valores pueden cambiar cuando ocurre una acción relevante.

Sintaxis ::=

::=

constants attributes variable attributes derivated attributes ':'

Tabla 3.3 Plantilla general para definir atributos en OASIS

27

Capítulo 3

3.5 Derivaciones

El lenguaje OASIS

La sección de derivaciones se utiliza para especificar la definición de un atributo derivado.

::= derivations

::= ['('')'] ::= ':=I

3.7 Eventos

Desde la perspectiva del lenguaje OASIS un evento es la abstracción de un cambio de estado atómico e instantáneo que le puede acontecer a un objeto. Y desde la perspectiva del usuario un evento representa una actividad o una acción que debe o no llevarse acabo y sobre la base de esto se obtendrá un resultado. En las siguientes tablas se define cada una de las secciones de eventos en OASIS.

::= constraints

: := '(''}' I '(''}'

I I I Tabla 3.6 Plantilla general para definir eventos en OASIS

..= .. events ::= ['(' lista-defqarámetro')']

[new I destroy]

28

Capitulo 3

new y destroy indican que se trata #_.

::=

::=

El lenguaje OASIS

valuations ‘[’’]’

I evento de creación o de destrucción de instancias. new crea el objeto y debe ser forzosamente el primer evento en la vida del objeto. destroy es la causa de la destrucción de un objeto. Si una clase no declara dicho evento se asume que los objetos son “inmortales”. Los eventos definidos en OASIS son: eventos privados, eventos implicados y eventos compartidos. Los eventos privados son servicios ofrecidos o requeridos por un objeto y cuya ocurrencia depende sólo del comportamiento del objeto en sí mismo. Los eventos implicados y los compartidos corresponden a servicios provistos por un objeto agregado, coordinados con servicios en sus objetos componentes. En el primer caso la ocurrencia del evento en el objeto agregado implica necesariamente la ocurrencia del correspondiente servicio en sus objetos componentes. En los eventos compartidos, dicha implicación es en ambos sentidos [Let98]. En lo que respecta al alcance del trabajo de tesis, sólo serán considerados los eventos privados.

3.8 Evaluaciones

::= ‘:=’

Las evaluaciones son fórmulas en lógica dinámica que establecen cómo las acciones afectan el estado del objeto, establecen como los atributos variables modifican sus valores en función de la ocurrencia de eventos.

::=

Las evaluaciones son fórmulas en lógica dinámica del tipo ty-b [a] 4 y se interpretan como: “s i en un determinado estado del objeto se satisface ty y ocurre la acción a, en el estado inmediatamente posterior del objeto se satisface @’.

Preconditions

3.9 Precondiciones

Las precondiciones determinan cuando un evento puede ser activado. En el contexto de la lógica dinámica, las precondiciones tienen la forma -4 [a]false, donde 4 es una fórmula bien formada interpretada como una condición para la ocurrencia de la acción indicada. El significado es “si 4 no se cumple, la ocurrencia de la acción no lleva al objeto a un siguiente estado”.

29

Capítulo 3

El lenguaje OASIS

..= .. Triggers -

::= when ‘{‘’)’

::=

::= ..= .. ::=

::= Qcciónqroceso> ::=

Protocols ’=’ I ’+’ [‘.’ ]

30

Capítulo 3

Observaciones:

::=

::= ::= ::=

El lenguaje OASIS

interface with

Capítulo 4 Desarrollo de prototipos en Java

Capítulo 4 Desarrollo de prototipos en Java En este capítulo se describen los puntos clave que han sido considerados para la generación de modelos ejecutables en Java que reflejan la estructura y funcionalidad de una especificación escrita en OASIS.

32

Desarrollo de prototipos en Java Capltulo 4

4.1 Generación de modelos de ejecución (prototipos)

Puesto que el propósito de este trabajo es generar modelos ejecutables en Java a partir de modelos conceptuales en OASIS, es conveniente mencionar la estrategias empleadas que sirven como guía en la representación del modelo conceptual en el entorno de desarrollo. Las dos estrategias a describir son:

Estrategia de generación de código. Estrategia de ejecución.

Estas estrategias constituyen, el modelo abstracto de ejecución, en el cual se basa la generación de prototipos.

4.1.1 Estrategia de generación de código

Para generar código, se debe establecer un patrón genérico y los componentes de software a utilizar para implementar las propiedades del sistema. En este trabajo, se ha usado una arquitectura lógica de tres niveles para los prototipos generados. Estos tres niveles son:

Un nivel de interfaz: En el que se sitúan los componentes que implementan la interacción con los usuarios, mostrándose una representación visual de los datos y los servicios que ofrecen los objetos del sistema.

Un nivel de aplicación: En el que se sitúan los componentes que implementan el comportamiento de las clases especificadas en el modelo conceptual (especificación OASIS).

Un nivel de persistencia: Este nivel se encarga de dar persistencia a los objetos del nivel de aplicación. La persistencia de objetos se realiza a través de un sistema gestor de bases de datos.

4.1.2 Estrategia de ejecución

Para lograr implementar y animar de una forma sencilla un sistema que se especifica en OASIS, se necesita predeterminar la forma en la cual los usuarios interactúan con los objetos del sistema. Se sabe que OASIS es orientado a objetos y como tal, permite definir una sociedad de objetos del sistema de información que se describe. La forma de interacción utilizada es la de permitir que un objeto activo se incluya en la sociedad de objetos como un miembro más de ella, enviando y recibiendo mensajes (un objeto activo no es mas que una instancia de una clase que actúa como agente de los servicios de otra clase).

Cada vez que un usuario desee iniciar una sesión de ejecución, deberá ejecutar los siguientes pasos:

1. Se identifica al usuario: Se permite a un usuario conectarse al sistema, y una vez conectado, se le proporciona una vista de la saciedad de objetos (mostrándosele qué clases de objetos puede ver y qué servicios activar).

33

Capíiulo 4 Desarrollo de prototipos en Java

2. Activación de servicios: Aquí el usuario puede activar (0 invocar) cualquier servicio (evento) que esté disponible en la vista de la sociedad de objetos que se le proporcion~,

Las que implementan 10s procedimientos de control de acceso y construcción de la sistema i (refiriéndose a las clases y a los servicios que el usuario puede ver), se han

implementado en el nivel de interfaz. Toda la información necesaria para configwar la del sistema está incluida en la especificación OASIS en la sección de interfaces (interface) que muestra las relaciones de agente.

Cualquier activación de un servicio consta de dos partes:

1. la construcción del mensaje y 2. su ejecución, siempre que ésta sea posible.

Para poder construir el mensaje el usuario debe proporcionar la siguiente información:

1. La identificación del objeto servidor: Es claro comprender, que para ejecutar cualquier servicio de un objeto, éste debe existir, excepto por supuesto si el servicio referido es el de creación del objeto. Si el objeto existe, el nivel de persistencia lo recuperará de la base de datos, pero si el evento o servicio es de creación, se almacenará en ella.

2. Los argumentos necesarios para la ejecución del evento. En este caso, si el servicio requiere de argumentos, estos deberán ser introducidos por medio del nivel de interfaz.

Hasta este momento, el mensaje ha sido construido y enviado, sin embargo la ejecución del servicio que éste representa dependerá de las propiedades descritas en la especificación OASIS, como son: transiciones de estado, precondiciones, evaluaciones, restricciones de integridad y disparos. Estás propiedades deben ser tomadas en cuenta, para garantizar la equivalencia funcional entre la especificación OASIS y el código Java que se desea generar.

Para garantizar la equivalencia funcional entre OASIS y Java, y al mismo tiempo verificar el proceso de generación del código, se sigue la siguiente secuencia de acciones cada vez que se envíe un mensaje y se desee ejecutar:

1. Transición válida de estado: Verificar en el diagrama de transición de estados que exista una transición válida para el servicio seleccionado (en OASIS las transiciones de estado válidas se describen en la sección profocols). De no ser así, se generará una excepción impidiéndose la ejecución del servicio.

2. Satisfacción de precondición: Comprobar que se cumpla la precondición asociada al servicio que se está ejecutando (la sección precondifions define las precondiciones de los distintos eventos en la especificación OASIS).

Si no se cumplen los pasos anteriores, el servicio no podrá ejecutarse, y deberá generarse una excepción.

34

Desarrollo de prototipos en Java Capitulo 4

3. Evaluaciones: Modificar los valores de los atributos que se afecten por la ocurrencia del servicio o evento. (las asignaciones para lograr tal fin están definidas para cada evento en la sección valuations de la especificación OASIS).

4. Comprobación de las restricciones de integridad: Comprobar que las evaluaciones asociadas a un servicio, dejen al objeto en un estado válido, verificando las restricciones de integridad si es que existen. Si alguna de ellas se viola, se generará una excepción y el cambio de estado producido se ignorará (la sección constraints, define las restricciones de integridad en la especificación OASIS).

5 . Comprobación de la relaciones de disparo: Verificar después de un cambio de estado válido, las reglas condición-acción que representan la actividad interna del sistema. Si alguna de ellas se cumple, deberá activarse el servicio correspondiente.

Si las acciones anteriores son exitosas, la capa de persistencia se encargará de actualizar los valores del estado actual del objeto servidor.

4.2 Arquitectura de los prototipos generados

El modelo abstracto de ejecución mostrado antes está orientado a una arquitectura de tres capas para la generación de los prototipos. Enseguida se describe el proceso de implementación del modelo descrito utilizando tecnología WEB, y como ya se ha mencionado anteriormente, es en el lenguaje Java. La selección de esta tecnología en el presente trabajo, se debe a las facilidades que presenta Java para desarrollos en el WEB, en particular para el manejo de interfaces gráficas, bases de datos y entornos en red.

4.2.1 Traducción del modelo conceptual a clases Java

En este punto se describe la implementación de los niveles de interfaz, aplicación y persistencia.

4.2.1.1 Nivel de interfaz

En el nivel de interfaz están las clases que implementan la interacción entre el usuario y los prototipos generados (esto es, la interfaz gráfica del usuario). El nivel de interfaz lo conformarán fundamentalmente las siguientes clases:

La clase de APPLETCONTROL: que se implementa como un applet conteniendo los típicos elementos gráficos (ver ejemplo en la fig. 4.1) que permiten al usuario su identificación como miembro de la sociedad de objetos (proporcionando su identificador, password y la clase a la cual pertenece).

35

Capitulo 4 Java

Fig. 4.1 Vista de una instancia de la clase APPLETCONTROL

Este applet se utiliza cada vez que el usuario desee conectarse al sistema.

La declaración de esta clase es la siguiente:

import java.applet.*; import java.awt.*; public class APPLETCONTROL extends Applet {

I /* código del applet

Para implementar esta clase, se definen fundamentalmente dos cajas de texto (una para la identificación del usuario y otra para su password), un menú desplegable para mostrar las clases de usuario y un botón para aceptar los datos capturados. Si los datos capturados corresponden a una instancia de usuario existente (esto se verifica necesariamente con un acceso a la base de datos de objetos persistentes), se le permitirá al usuario acceder al sistema y se instanciará un objeto de la clase INTERFAZ. Si el usuario no existiera, el applet mandará un mensaje de acceso denegado, instanciándose para ello un objeto de la clase DIALOGOMEN. La información requerida para la construcción del menú desplegable se toma de las relaciones de agente definidas en la sección de interfases de la especificación OASIS. La clase APPLETCONTROL se invoca desde un documento en Hhnl generado automáticamente. Éste se muestra en la figura 4.2.

36

Capitulo 4

~ -

Desarrollo de prototipos en Java

Control de Acceso Animacion Nombre Esquema OASIS

La clase INTERFAZ: Esta clase se instanciará cuando el usuario logre conectarse ai sistema, mostrándole un Frame con una barra de menú que tendrá tantos submenús como clases puedan ser vistas por el usuario. Cada submenú tendrá tantas opciones (items) como servicios (eventos) de dicha clase el usuario tenga permitido activar (ver ejemplo en la fig. 4.3).

Fig. 4.3 Vista de una instancia de la clase INTERFAZ.

La declaración de esta clase es la siguiente:

import j ava. awt . * ; public class INTERFAZ extends Frame {

1 La implementación de esta clase incluye un constructor con tres parámetros: una cadena para desplegase en la barra de título del Frame, el nombre de la clase del usuario que accesa el

37

/* Código de la clase INTERFAZ

Desarrollo de prototipos en Java Capítulo 4

sistema y su identificacador. Estos parámetros le permiten al objeto N T E W A Z mostrar sólo los elementos gráficos necesarios (submenús e items) y acordes a lo estipulado en la sección de interfaces de la especificación OASIS.

La clase DIALOGO: Esta clase definirá el interfaz típico para entrada de datos donde se solicitan los argumentos relevantes del servicio o evento. El objeto DIALOGO será genérico para todos los servicios de todas las clases, y dependiendo del servicio seleccionado mostrará las correspondientes etiquetas con sus celdas de edición (ver ejemplo en la fig 4.4). Una vez que hayan sido llenadas, el usuario enviará el mensaje al destinatario o ignorará la petición de datos, para lo cual se proveerán botones de aceptar o cancelar respectivamente.

Fig 4.4 Vista de una instancia de la clase DIALOGO.

La declaración de la clase DIALOGO es:

import java.awt.*; public class DIALOGO extends Dialog 1

/* Código de DIALOGO 1 Para la implementación de esta clase se incluye un contructor con los siguientes parámetros: la referencia al Frame padre, una cadena con el nombre de la clase servidora, una cadena con el nombre de evento a ejecutarse, el número de parámeros requerid’o para ese evento, una cadena con el nombre de la clase que solicita el servicio y una cadena más con el identificador del objeto que solicita el servicio. La información requerida para el constructor de DIALOGO, se obtiene consultando en la especificación OASIS los atributos necesarios para ejecutar el evento o servicio solicitado.

0 La clase DIALOGOMEN: Utilizada para la visualización de mensajes de éxito, de ocurrencia de excepciones (propias de la estrategia de ejecución) o excepciones críticas con mensajes del sistema (ver ejemplos en las figuras 4.5).

38

Capitulo 4 Desarrollo de prototipos en Java

. . .

Fig. 4.5 Vistas de instancias de objetos DIALOGOMEN.

La declaración de la clase DIALOGOMEN es:

import java.awt.*; public class DIALOGOMEM extends Dialog {

1 /* Código de DIALOGOMEM

La implementación de la clase DIALOGOMEM, incluye un constructor con tres parámetros: la referencia al Frame padre, una cadena para definir el título y otra cadena para el mensaje que se despliega.

4.2.1.2 Nivel de aplicación

El nivel de aplicación estará conformado por todas aquellas clases que implementan las clases del modelo conceptual definido en OASIS. Para garantizar que los objetos de estas clases se comporten como objetos OASIS, se necesita un mecanismo que permita a estas clases implementar sus métodos de manera que soporten el modelo de ejecución abstracto descrito anteriormente. Este mecanismo se implementa haciendo uso de cuatro clases que heredan de la clase Exception, una para cada chequeo descrito en el modelo de ejecución abstracto (transición de estado, precondiciones, restricciones de integridad y disparos).

39

Capítulo 4 Desarrollo de prototipos en Java Cada clase del modelo conceptual en OASIS tendrá su correspondiente clase generada en Java. Para lograr esto es necesario establecer algunas reglas de traducción entre OASIS y Java. Las equivalencias más relevantes consideradas para la traducción de OASIS a Java se describen a continuación:

En Oasis : tipooasis;

costo : real; nombre : string;

En Java tipoJava ;

double costo; String nombre;

Notamos que los nombres de los identificadores de los atributos no cambia, solo cambia el nombre del tipo de dato utilizado. La tabla 4.2 muestra la correspondencia entre tipos OASIS y Java:

Tipo Oasis I ,PO Java

Real Double I

n

En OASIS

Tabla 4.2 Correspondencia de tipos OASIS a Java

Los aiributos derivados, que cambian su valor en función de los valores de otros atributos (constantes y/o variables) se traducen como métodos de las clases Java a las que pertenecen y en correspondencia a las expresiones definidas en la sección derivations, como lo muestra la tabla 4.3. El nombre del atributo derivado es usado como el nombre del método.

en Java

: TipoOasisl; attributes derivated

derivations

attributes variables

: TipoOasis2;

=(};

TipoJava2 ()

return (); í

} double cantidad;

Cantidad : real; attributtes derivated

impuesto : real; derivations

1 double impuesto() return (cantidad*O.lO);

í

40

Capitulo 4

and

Desarrollo de prototipos en Java

&&

Las expresiones en OASIS utilizan algunos operadores con notación diferente a los de Java. Es por eso necesario establecer la equivalencia entre estos mostrada en la tabla 4.4. Los operadores relacionales >=, , < así como los aritméticos +,-,/,* son escritos de igual forma tanto en OASIS como en Java.

not I

Operadores relacionales en OASIS Operadores relacionales en Java

Operador de asignación en Oasis Operador de usignación en .Java

Tabla 4.4. Correspondencia entre operadores OASIS y Java

Las evaluaciones en Oasis se traducen como métodos de las clases Java (tabla 4.5):

In Oasis

ittributes variables

!vents (: TipoOasis),

raluations [ ()]

, ,

ittributes variables cantidad : real;

?vents depositar(importe:real);

valuations [depositar(impor t e)]

cantidad : = cantidadiimporte;

Tabla 4.5. Traducción dc

:II Java loid (TipoJava )

/* Chequeo de transición de estado */ /* Chequeo de precondiciones */ /* Asignaciones que modifican el estado

; ; ... /* Chequeo de restriciones de integridad */ /* Chequeo de ocurrencia de disparos */

ioid depositar( double importe) c /* Chequeo de transición de estado */ /* Chequeo de precondiciones */

/*Asignaciones que modiJican el estado

del objeto */

I

del objeto */ cantidad=cantidad+importe;

/* Chequeo de restriciones de integridad *! /* Chequeo de ocurrencia de disparos */

I valuaciones a métodos Java.

I

41

Desarrollo de prototipos en Java Capítulo 4

Notamos que el nombre del método que se implementa corresponde al nombre del evento o servicio que se define en la sección evenfs y corresponde a la definición de la evaluación. Si el evento tiene parámetros, también se usará el mismo nombre en la traducción, consultándose el tipo de los mismos en la sección events.

Cada uno de los chequeos indicados como comentarios, lleva implícito código Java para realizar su función. Este código lanzará excepciones según sea el caso, mismas que ocurrirán de acuerdo a la estrategia de ejecución planteada. Se desarrollaron clases que heredan de la clase Excepfion de Java para cada caso. Las clases mencionadas son:

PreException (para chequeo de precondiciones), EstException (para chequeo de transición de estado), ResException (para chequeo para restricciones de integridad) y DisException (para chequeo de disparos).

El código Java para la clase de excepción de precondición se muestra en la tabla 4.6

class PreException extends Exception {

public PreException (String mensaje) {

1 super(mensaje);

Tabla 4.6. Código que implementa la clase PreException.

El código para las tres restantes clases de excepciones es similar

4.2.1.3 El nivel de persistencia

La capa de persistencia estará conformada por las tablas dentro de una base de datos que representan las clases del dominio del problema. Dicho de otra forma, cada clase del modelo conceptual se representará como una tabla cuyas tuplas serán instancias de esa clase. LOS métodos para salvar, borrar y recuperar objetos de la base de datos, estarán implementados para cada una de las clases del dominio del problema. Las clases JDBC de Java se utilizarán en la implementación de estos métodos para acceder a través de sentencias SQL al servidor de bases de datos que da persistencia a los objetos del sistema.

La declaración de los métodos para dar persistencia a los objetos es:

void salvar( )

/* Código del método salvar */ {

1

42

Capitulo 4

- . Navegador

Desarrollo de prototipos en Java

Documento HTM' I I I I=]

void bonar(TipoJava identificador - - del objeto) I

I

{

I

{

I

/* Código del método borrar, se requiere el identificador del objeto que habrá de ser borrado */

void recuperar(Tip0Java identificador - - del objeto)

I* Código del método borrar, se requiere el identificador del objeto que habrá de ser recuperado */

void modificar( )

/* Código del método modificar */

La información para construir los "querys" SQL utilizados por los métodos de las clases JDBC, es obtenida a partir de los identificadores y tipo de los atributos constantes y variables definidos en la especificación de una clase OASIS.

4.2.2 Distribución de las clases generadas en una arquitectura WEB

Cuando todas las clases han sido generadas, se distribuyen en una arquitectura como la que se muestra en la Fig. 4.6.

- a i A- datos

I Generador de código Java a partir de OASIS

Fig. 4.6 Arquitectura de distribución de clases en el WEB.

43

Capítulo 4 Desarrollo de prototipos en Java

El usuario descarga desde el navegador Web, la página del prototipo generado, junto con el upplet qu