-
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
