Generación Automática de Prototipos en Entornos Internet ...

Computacioacuten y Sistemas Vol 3 No I pp 38-49 copy 1999 elc -IPN ISSN 1405-5546 Impreso en Meacutexiacuteco=--___________________________

Generacioacuten Automaacutetica de Prototipos en Entornos InternetIntranet a Partir de Modelos Conceptuales 00

Osear Pastor Vicente Peleehano Emilio Insfraacuten Departamento de Sistemas Informaacuteticos y Computacioacuten

Universidad Politeacutecnica de Valencia 46071 Valencia (SPAIN)

email [opastorpeleeinsfran]dsicupves

Jaime Goacutemez Departamento de Lenguajes y Sistemas Informaacuteticos

Universidad de Alicante 03690 Alicante (SPAIN) email jgomezdlsiuaes

Artiacuteculo recibido el 2 de abril 1998 aceptado el11 de julio 1999

Resumen

Este artiacuteculo presenta un proceso de generacioacuten aushytomaacutetica de coacutedigo en entornos InternetIntranet Jashyva en particular OO-Method (Pastor et al 1997) es la metodologiacutea 00 que da soporte a este proceso Esta metodologiacutea estaacute basada en OASIS (Pastor et aL 1992 Pastor amp Ramos 1995) un lenguaje de especificacioacuten formal y orientado a objetos El punto de partida del proceso de generacioacuten es el modelo conceptual obtenido en la fase de anaacutelisis de OO-Method Un modelo de ejecucioacuten preciso establece una representacioacuten del modeshylo conceptual en el entorno de desarrollo elegido (atenshydiendo aspectos estaacuteticos y dinaacutemicos) y siguiendo la estrategia de ejecucioacuten subyacente a dicho modelo de ejecucioacuten se obtiene de forma automaacutetica una impleshymentacioacuten completa del sistema modelado El resultado final es una aplicacioacuten Web funcionalmente equivalente a la especificacioacuten del sistema con una arquitectura de tres capas implementada en Java que utiliza una base de datos relacional como repositorio de objetos

Palabras Clave Modelizacioacuten cltlnceptual Lenguajes de especificacioacuten Generacioacuten de coacutedigo Tecnologiacuteas InternetIntranet

38

1 Introduccioacuten

Un problema claacutesico en la ingenieriacutea del software es coacutemo derivar software ejecutable a partir de los requisitos de un sistema y coacutemo podriacutea sistematizarse este proceso La aproximacioacuten orientada a objetos proporciona un modeshylo comuacuten durante todo el proceso de desarrollo (desde el anaacutelisis a la implementacioacuten) permitiendo una suave transicioacuten entre cada una de estas fases

En este contexto a lo largo de estos antildeos han surgido varios meacutetodos de modelado conceptual De entre estos meacutetodos OMT (Rumbaugh et al 1991) OOSE (Jacobshyson et al 1992) Booch (1991) y ahora el lenguaje de modelado UML (Booch et al 1997) son los que estaacuten soportados por la mayoriacutea de herramientas CASE del mercado como Rational ROSEJava (Rational-Software 1995) o Paradigm Plus (Platinum-Technology 1997) Estas herramientas intentan resolver la problemaacutetica asociada al desarrollo de sistemas incluyendo generashycioacuten de coacutedigo a partir de los modelos de anaacutelisis Sin embargo si examinamos maacutes a fondo el coacutedigo generado encontraremos que no se obtiene un producto funcionalshymente equivalente a la descripcioacuten capturada en el moshydelo conceptual lo que se obtiene en realidad no es maacutes que un conjunto de plantillas para la declaracioacuten de las clases donde no se implementa ninguacuten meacutetodo

En este artiacuteculo se presenta un proceso de generashycioacuten automaacutetica de coacutedigo propuesto por OO-Method un meacutetodo basado en un modelo de objetos formal Este proceso constituye una solucioacuten operativa al problema de la generacioacuten de coacutedigo funcionalmente equivalente a

iexcl O Pastor V Pelechano E Insfraacuten y J GoacutemezGenetacioacuten Automaacutetica de Prototipos en Entornos Internetllnttanet a Partir de Mbullbull

la especificacioacuten de un sistema de informacioacuten La caracteriacutestica principal de este meacutetodo es que los

esfuerzos de los desarrolladores se centran en la etapa de modelado conceptual y a continuacioacuten de forma aushytomaacutetica se obtiene una implementacioacuten completa del sistema siguiendo un modelo de ejecucioacuten preciso (que incluye estructura y comportamiento)

El resultado final es en este caso una aplicacioacuten Web con una arquitectura de tres capas implementada en Java sobre una base de datos relacional como repositorio de objetos

La herramienta OO-MethodiexclCASEl da soporte a este meacutetodo y constituye una aproximacioacuten operacional a las ideas del paradigma de programacioacuten automaacutetica (Blazer et al 1983) recoleccioacuten de las propiedades del sistema de informacioacuten generacioacuten automaacutetica de una especificacioacuten formal del sistema y obtencioacuten de un proshytotipo de software funcionalmente equivalente a la esshypecificacioacuten del sistema

El contenido del artiacuteculo se estructura de la siguienshyte manera en el punto 2 se comentan brevemente las caracteriacutesticas principales del lenguaje de especificacioacuten OASIS y se presenta OO-Method describiendo los moshydelos que permiten especificar el sistema graacuteficamente y el modelo de ejecucioacuten que se utiliacuteza como patroacuten en el proceso de generacioacuten de coacutedigo En el punto 3 se explican las caracteriacutesticas de la arquitectura de un proshytotipo generado enmiddot Java Para comprender mejor este proceso de traduccioacuten en el punto 4 se desarrolla un cashyso de estudio relativo al Servicio de Mantenimiento de un Hospital Finalmente se presentan las conclusiones y las liacuteneas futuras de actuacioacuten que derivan de este trabajo

2 OO-Method y OASIS

OO-Method es una metodologiacutea de produccioacuten aushytomaacutetica de software basada en teacutecnicas de especificacioacuten formales que usa diagramas graacuteficos similares a los emshypleados tradicionalmente por las metodologiacuteas convenshycionales (OMT Booch UML) El proceso de produccioacuten de software empieza con la fase de modelado conceptual donde se recogen con modelos graacuteficos las propiedades relevantes del sistema a desarrollar Una vez que teshynemos la descripcioacuten del sistema se obtiene de forma automaacutetica una especificacioacuten formal y 00 del sistema Esta especificacioacuten es la fuente de un modelo de ejecucioacuten que determina de forma automaacutetica las caracteriacutesticas del sistema dependientes de la implementacioacuten (intershyfaz de usuario control de acceso activacioacuten de servishy

1El desarrollo de la herramienta OO-MethodCASE ha sido parcialmente subvencionada por el IMPIVA a traveacutes de un proyecshyto del Plan de Ciencia y Tecnologiacutea Valenciano

cios consulta y manipulacioacuten de informacioacuten) Esta proshypuesta proporciona un marco bien definido que nos pershymite construir herramientas de modelado y generacioacuten de coacutedigo basadas en el paradigma de programacioacuten aushytomaacutetica

21 OASIS Un Modelo Formal Orientashydo a Objetos

OO-Method se ha creado sobre las bases de OASIS un lenguaje formal y 00 de especificacioacuten de sistemas de informacioacuten Vamos a dar un breve repaso de las prinshycipales caracteriacutesticas de OASIS En una especificacioacuten OASIS una clase es un patroacuten o conjunto de propiedades que comparten todos sus ejemplares Este patroacuten tiene un nombre y permite la declaracioacuten de un mecanismo de identificacioacuten La signatura de la clase incluye atributos eventos y un conjunto de foacutermulas de la loacutegica dinaacutemica que nos permiten describir el resto de sus propiedades

bull restricciones de integridad estaacuteticas y dinaacutemicas

bull evaluaciones que especifican coacutemo cambian los atrishybutos debido a la ocurrencia de eventos

bull derivaciones que especifican el valor de un atributo derivado en funcioacuten de otros

bull precondiciones que establecen condiciones que deben satisfacerse para activar un evelto

bull disparos que provocan la activacioacuten espontaacutenea de un evento como consecuencia de la satisfaccioacuten de una condicioacuten

Ademaacutes un objeto puede definirse como un proceshyso observable por lo que la especificacioacuten de la clase se enriquece con un aacutelgebra de procesos baacutesica (Pastor amp Ramos 1995) que permite declarar las vidas posibles de un objeto como teacuterminos de este aacutelgebra cuyos elemenshytos son eventos y transacciones combinados con operashydores de alternativa y secuencia de procesos

Por razones de espacio la descripcioacuten del lenguaje de especificacioacuten es introductoria El lector puede encontrar una descripcioacuten mas detallada de OASIS en (Pastor et al 1992) y la descripcioacuten completa de su semaacutentica y fundamentos formales en (Pastor amp Ramos 1995)

22 Modelado Conceptual

Los conceptos formales asociados a OASIS determinan la informacioacuten relevante a capturar en la fase de modelado conceptual Para ello OO-Method proporciona tres moshydelos con los que recoger las propiedades relevantes de un sistema de informacioacuten Los diagramas asociados a cada

39

O Pastor V Pelechano E Insfraacuten y J GoacutemezGeneracioacuten Automaacutetica de Prototipos en Entornos InternetIntranet a Partir de M

uno de esos tres modelos respetan la notacioacuten graacutefica hashybitual en contextos de anaacutelisis aunque su semaacutentica estaacute concebida para declarar con precisioacuten soacutelo aquel conjunto de informacioacuten que es realmente necesaria para describir el Sistema Como deciacuteamos ese conjunto queda detershyminado por las secciones de especificacioacuten de una clase en OASIS

bull modelo de Objetos es un modelo graacutefico en el cual se definen las clases del sistema (incluyendo atrishybutos servicios y relaciones entre clases) Las relashyciones pueden ser de agregacioacuten (parte-de) especialshyizacioacuten (es-un) generalizacioacuten y de agente (introshyducidas para especificar queacute objetos pueden activar los servicios ofrecidos por cada clase)

bull modelo Dinaacutemico es un modelo graacutefico que permite especificar las vidas vaacutelidas de los objetos de una clase y las interacciones entre objetos Para ello se utilizan dos tipos de diagramas

Diagramas de Transicioacuten de Estados se utilizan para describir geneacutericamente la secuencia corshyrecta de eventos en la vida de los objetos de una clase

- Diagramas de Interaccioacuten entre objetos se utishylizan para representar las interacciones entre los objetos del sistema En este diagrama se definen dos mecanismos baacutesicos de interaccioacuten los disparos (servicios que se activan de forma automaacutetica como consecuencia del cumplimshyiento de una condicioacuten sobre el estado de un objeto) e interacciones globales (transacciones que involucran a servicios de diferentes objeshytos)

bull modelo Funcional es un modelo que se utiliza para capturar la semaacutentica asociada al cambio de estashydo de un objeto como consecuencia de la ocurrenshycia de un evento El efecto de los eventos sobre el estado de los objetos se corresponde con una evalushyacioacuten de la loacutegica dinaacutemica que se especifica sigushyiendo una estrategia de clasificacioacuten de los atributos en categoriacuteas (definidas en (Pastor et al 1997)) y les asigna nuevos valores en funcioacuten de los eventos ocurridos Iacutetsta es una aportacioacuten interesante de este meacutetodo que nos facilita la generacioacuten de forma automaacutetica de una especificacioacuten completa en OAshySIS Finalmente a partir de la informacioacuten recogishyda en estos tres modelos se obtiene utilizando una estrategia de traduccioacuten bien definida una especishyficacioacuten formal y 00 en OASIS que constituye un repositorio de alto nivel del sistema

40

23 El Modelo de Ejecucioacuten

Una vez especificado el sistema un modelo de ejecucioacuten establece una representacioacuten del modelo conceptual en el entorno de desarrollo elegido (atendiendo a aspectos estaacuteticos y dinaacutemicos) y una estrategia de ejecucioacuten asoshyciada

231 Estrategia de Generacioacuten de Coacutedigo

A continuacioacuten se explica el patroacuten geneacuterico y los comshyponentes software a utilizar para implementar en un enshytorno de desarrollo las propiedades del sistema utilizando una arquitectura loacutegica de tres niveles (three-tier)

bull Nivel de interfaz en este nivel se situacutean los comshyponentes que implementan la interaccioacuten con los usuarios finales mostrando una representacioacuten vishysual de los datos y los servicios que ofrecen los obshyjetos del sistema

bull Nivel de aplicacioacuten en este nivel se situacutean los composhynentes que implementan de forma completa el comshyportamiento de las clases especificadas en la fase de modelado conceptual

bull Nivel de persistencia en este nivel se situacutean los comshyponentes que proporcionan los servicios necesarios para dar persistencia a los objetos del nivel de aplishycacioacuten La persistencia de los objetos actualmente se realiza recurriendo a un sistema gestor de bases de datos relacional (SGBDR)

232 Estrategia de Ejecucioacuten

Para animar el sistema especificado se define una esshytrategia de ejecucioacuten e interaccioacuten Esta estrategia es cercana a las teacutecnicas de realidad virtual en el sentido de que un objeto activ02 se introduce en la sociedad de objetos como miembro de ella e interactuacutea con los demaacutes enviando y recibiendo mensajes Para iniciar una sesioacuten de ejecucioacuten los pasos a seguir son

1 Identificacioacuten del usuario (control de acceso) conshysiste en la conexioacuten del usuario al sistema Una vez conectado se le proporciona una visioacuten clara de la sociedad de objetos (ofrecieacutendole queacute clases de obshyjetos puede ver los servicios que puede activar y los atributos que puede consultar)

2 Activacioacuten de servicios~ el usuario podraacute activar cualquier servicio (evento o transaccioacuten) disponible en su visioacuten de la sociedad Ademaacutes podraacute reshyalizar observaciones del sistema (object queries)

2Un otijeto activo es una instancia de una clase que actuacutea como agente de los servicios de alguna clase

O Pastor V Pelechano E Insfraacuten y J GoacutemezGeneracioacuten Automaacutetica de Prototipos en Entornos InternetIntranet a Partir de M bullbull

I

1

j

~ Las clases que implementan las tareas de control de acceso y construccioacuten de la vista del sistema (clases y servicios visibles) se implementaraacuten en el nivel de interfaz La informacioacuten necesaria para configurar la vista del sistema estaacute incluida en la especificacioacuten del sistema (relaciones de agente) obtenida en la fase de modelado conceptual Cualquier activacioacuten de un servicio tiene dos partes la construccioacuten del menshysaje y su ejecucioacuten (si es posible) El algoritmo de activacioacuten de un servicio sigue los siguientes pasos

(a) Identificacioacuten del objeto servidor si el objeto existe el nivel de persistencia se encargaraacute de recuperar el objeto servidor de la base de datos y si el servicio solicitado es un evento de creacioacuten reservaraacute espacio para su almaceshynamiento

(b) Introducir los argumentos necesarios para la ejeshycucioacuten del evento el nivel de interfaz pregunshytaraacute por los argumentos del evento que va a activarse (siacute es necesario)

Una vez el mensaje se ha enviado se identifica el obshyjeto servidor3 y se procede a seguir la siguiente secuencia de acciones sobre dicho objeto

1 Transicioacuten vaacutelida de estado se verifica en el diagrama de transicioacuten de estados que exista una transicioacuten vaacutelida para el servicio seleccionado

2 Satisfaccioacuten de precondicioacuten se comprueba que se cumpla la precondicioacuten asociada al servicio en ejeshycucioacuten (si existe)

Si no se cumplen 1 y 2 se generaraacute una excepcioacuten informando que el servicio no puede ejecutarse

3 Evaluaciones se modifican los valores de los atribushytos afectados por la ocurrencia del servicio (como se especificoacute en el modelo funcional)

4 Comprobacioacuten de las restricciones de integridad las evaluaciones del servicio deben dejar al objeto en un estado vaacutelido Se comprueba que no se violan las restricciones de integridad (estaacuteticas y dinaacutemicas) Si alguna de ellas se viola se generaraacute una excepcioacuten y el cambio de estado producido se ignoraraacute

5 Comprobatioacuten de las relaciones de disparo despueacutes de un cambio de estado vaacutelido y como accioacuten final se debe verificar el conjunto de reglas condicioacuten-accioacuten que representa la actividad interna del sistema Si alguna de ellas se cumple se activaraacute el servicio coshyrrespondiente

3La existencia del objeto servidor es una condicioacuten impliacutecita para ejecutar cualquier evento excepto si se trata del evento de creacioacuten

Una vez finalizadas con eacutexito las acciones preceshydentes los componentes de la capa de persistencia se encargan de actualizar (UPDATE) la BDR correspondishyente

Los pasos anteriores guiaraacuten la implementacioacuten de cualquier aplicacioacuten para asegurar la equivalencia funshycional entre la descripcioacuten del sistema recogida en el modelo conceptual y su reificacioacuten en un entorno de proshygramacioacuten de acuerdo con el modelo de ejecucioacuten

3 Arquitectura del Prototipo Geshynerado en Java

El modelo abstracto de ejecucioacuten mostrado anteriorshymente estaacute orientado a la generacioacuten de prototipos con arquitectura de tres capas A cQntinuacioacuten se presenta una implementacioacuten concreta utilizando tecnologiacutea WEB y Java como lenguaje de programacioacuten

31 Traduccioacuten de un Modelo Concepshytual a Clases Java

En este apartado se presentan las clases que implemenshytan las capas de interfaz aplicacioacuten y persistencia En la capa de interfaz estaacuten las clases que implementan la interaccioacuten entre el usuario y la aplicacioacuten (interfaz graacutefica de usuario)

bull Clase ControLdeAcceso se implementa como un applet que contiene los tiacutepicos widgets que permiten al usuario su identificacioacuten como miembro de la soshyciedad de objetos (proporcionando su identificador password y la clase a la cual pertenece)

Este applet se crea cada vez que el usuario quiere conectarse al sistema (implementando el primer pashyso del modelo de ejecucioacuten)

La declaracioacuten de esta clase es la siguiente

import javaawt import javaappletiexcl public class Control_Acceso extends Applet

bull Clase Vista_deLSistema cuando un usuario estaacute conectado al sistema un objeto de la clase Vista_del5istema mostraraacute un frame con un menuacute bar asociado que tendraacute tantos submenuacutes como clases el objeto puede interactuar Cada submenuacute tendraacute tantos items como servicios de dicha clase el usuario puede activar La declaracioacuten de esta clase es la siguiente

41

O Pastor V Pelechano E Insfraacuten y J G6mezGeneracoacuten Automaacutetica de Prototipos en Entornos Internetllntranet a Partir de M

import javaawt public class Vista_Sistema extends Frame

bull Clase Activadoacuten_de5ervicio esta clase definiraacute el interfaz tiacutepico de WWW para entrada de datos una caja de diaacutelogo donde se solicitan los argushymentos relevantes del servicio El objeto Activashydoacuten_de_Servicio seraacute geneacuterico para todos los servishycios de todas las clases y dependiendo del servicio seleccionado mostraraacute las correspondientes etiqueshytas con sus celdas de edicioacuten Una vez que hayan sido rellenadas el usuario enviaraacute el mensaje al desshytinatario o ignoraraacute la accioacuten de peticioacuten de datos Su declaracioacuten es

import javaawt public class Activacion_Servicio extends Dialog

En la capa de aplicacioacuten tendremos las clases que implementan el comportamiento de las clases especifishycadas en el modelo conceptual (clases del dominio) Para garantizar que los objetos de estas clases se comporshytan como objetos OASIS (objetos que siguen el modeshylo de objetos propuesto en OASIS) necesitamos de un mecanismo que permita a estas clases implementar los meacutetodos necesarios para soportar el algoritmo de ejecushycioacuten de servicios del modelo de ejecucioacuten tal y como se comentoacute en el punto 232 Este mecanismo se imshyplementa en Java como un interface (que denominamos OASIS) y que proporciona las plantillas de los meacutetodos que obligatoriamente deben implementarse en las clases del dominio El interfaz tendraacute la siguiente estructura

import javaawt interface OASIS void Check_T_Estad (string event) void Check_Precond (string event) void Check_Restricc O void Check_Disparos O

Estos meacutetodos se corresponderaacuten respectivamente con los pasos 1 2 4 y 5 del algoritmo de ejecucioacuten de servicios del modelo de ejecucioacuten

La capa de persistencia estaraacute integrada por la base de datos es decir por las tablas relacionales que representan las clases del diagrama de clases y sus relashyciones (herencia y agregacioacuten) Dicho de otro modo cashyda clase del diagrama de clases se representaraacute como una tabla cuyas tuplas seraacuten instancias de esa clase La imshyplementacioacuten de las relaciones (agregacioacuten y herencia) se realiza conforme a (Letelier amp Ramos 1995) Ademaacutes

42

en esta capa se implementaraacute la clase GestorPersistenshyda que proporcionaraacute los meacutetodos para salvar borrar y recuperar objetos de la base de datos La clase GestorshyPersistencia tiene la siguiente estructura geneacuterica

class GestorPersistencia extends Object void borrar O j

void salvarO void recuperare)

Las clases JDBC de Java se utilizaraacuten en la impleshymentacioacuten de estos meacutetodos para acceder de forma senshycilla a los servidores relacionales que almacenen el reshypositorio de sistema Finalmente para permitir que las clases del dominio sean persistentes Eacutestas heredaraacuten de la clase GestorPersistencia mediante la clauacutesula extends en la declaracioacuten de la clase y redefiniraacuten para cada una de ellas los meacutetodos correspondientes

Es importante resaltar que aunque en el artiacuteculo nos centremos en Java este disentildeo permitiraacute traducir a cualquier otro lenguaje de programacioacuten distribuyendo adecuadamente los componentes de la aplicacioacuten depenshydiendo de las caracteriacutesticas y necesidades del entorno destino

32 Distribucioacuten de Clases Java en una Arquitectura WWW

bullUna vez que todas las clases han sido generadas se disshytribuyen en una arquitectura en tres capas como se ilusshytra en la figura 1

Un navegador Web descargaraacute la paacutegina HTML de la aplicacioacuten desde un servidor Web junto con el applet que conforma el interfaz de la aplicacioacuten El usuario inshyteractuaraacute con los objetos Java del sistema a traveacutes del cliente Web Los objetos Java del sistema se almaceshynaraacuten en el servidor Web de la aplicacioacuten que consultaraacute o actualizaraacute el estado de los objetos almacenados en el servidor de datos a traveacutes de los servicios proporcionados por la clase GestorPersistencia Los componentes de esta arquitectura se generaraacuten de forma automaacutetica usando la herramienta OO-MethodCASE

4 Caso de Estudio

La herramienta OO-MethpdCASE nos permite moshydelar y generar automaacuteticamente prototipos Java funshycionalmente equivalentes al modelo Conceptual consshytruido Para comprender mejor la arquitectura y el funshycionamiento de las clases Java generadas presentamos como caso de estudio el Servicio de Mantenimiento de un Hospital

I

l I

O Pastor V Pelechano E Insfraacuten y J GoacutemezGeneracioacuten Automaacutetica de Prototipos en Entornos Intemetllntranet a Partir de M

J

~ CAPA I CAPA 11 CAPA 111

iexcl

Sr_olt Compaiexcliblo

Java

Cliente SeacutelVidor SO

Figura 1 Arquitectura WWW de tres capas

El servicio de mantenimiento de un hospital gestiona las averiacuteas que se producen en eacutel El servicio estaacute formashydo por 1 responsable 7 maestros encargados de cada una de las aacutereas del servicio y unos cuantos operarias asigshynados a cada aacuterea Diariamente el responsable clasifica los partes de averiacuteas que se reciben en funcioacuten del aacuterea a asignar y la urgencia que precise Cada maestro recibe los partes de averiacutea correspondientes a su aacuterea y procede a la resolucioacuten de la averiacutea asignado los trabajos a sus operarios A veces ocurre que las averiacuteas se producen sobre maquinaria muy especiacutefica que el servicio de manshytenimiento no es capaz de atender (ascensores rayos-X ) En estos casos el maestro debe de comprobar si la maacutequina tiene contrato de mantenimiento con alguna empresa externa y en caso afirmativo generar un aviso de averiacutea Respecto a las maacutequinas debemos tener en cuenta que

bull cuando se da de alta una maacutequina en el servicio no se le asocia ninguacuten contrato de mantenimiento

bull soacutelo se podraacute asignar un contrato de mantenimienshyto a una maacutequina si eacutesta no tiene ninguacuten contrato anterior en vigor

bull para cualquier maacutequina con contrato se puede moshy

bull el responsable es el uacutenico que puede asignar modishyficar o cancelar un contrato de mantenimiento entre una maacutequina y una empresa mantenedora

A partir de esta especificacioacuten construimos el Modelo Conceptual (modelo de objetos dinaacutemico y funcional) identificando las clases las relaciones entre eacutestas y esshypecificando su comportamiento Vamos a ilustrar estas tareas paso a paso

41 Modelo de Objetos

Vamos a centrarnos en la especificacioacuten que afecta a los contratos de mantenimiento En la figura 2 podemos ver la porcioacuten del diagrama de clases que se corresponde con esta especificacioacuten La clase contrato_mantenimiento es una agregacioacuten que tiene como componentes la clase maacutequina y la clase empresa_mantenedora

Ademaacutes podemos obfiervar la relacioacuten de agente asoshyciada a la clase maacutequina de ella podemos deducir que la clase responsable es agente de los eventos de la clase

dificar yo cancelar su contrato de mantenimiento

bull el responsable es el uacutenico que puede dar de alta una maacutequina

maacutequina enlazados a traveacutes de las liacuteneas punteadas Fijeacutemonos que a partir de las relaeacuteiones de agente podeshymos obtener la vista del sistema que le corresponde a cualquier objeto instanciado de una clase

43

O Pastor V Pelechano E Insfraacuten y J G6mezGenetacioacuten Automaacutetica de Prototipos en Entornos InternetIntranet a Partir de 11

- Maquina

~d_III4Ui~=oa odlo Ifldescntilde~oacuteio onlrlt0 ot1d

0 ~stro)()0nml rO dlto _bullbull1111010 _~anoti r_00 ntnloacute t)

e ontrlt ~bullntn 1m nto1 _ shy ~ r--shyr---shy

Emp sa-nton dora

i~ICemPNn ~ircclon 111

d~poSt1 Ilt~no

~

~ ()

iexcliexcltro)() ~OMr3ImiddotrO odllo_onI1311gt0 --noir_conlrlIOO

11

middot~od_conmiddot1rlto

~fe_contrto ~mpnS3 ~ quiexclnmiddot

~ O ~Iro)l() -onpllrO dltbullbull _conmloO nnodar_00 n1rJlCJO

Figura 2 Diagrama de clases del sistema

42 Modelo Dinaacutemico

Para cada una de las clases obtenidas en el paso anteshyrior especificamos un diagrama de transicioacuten de estados La figura 3 refleja el diagrama de transicioacuten de estados para la clase maacutequina del diagrama anterior Podemos observar como la creacioacuten de un objeto de esta clase viene caracterizada por la accioacuten RESPnew que implica la activacioacuten del evento de creacioacuten por parte del responshysable produciendo la transicioacuten al estado MaquinaO A partir del estado MaquinaO se pueden producir dos camshybios de estado (Maquinal o Destruccioacuten) caracterizados nuevamente por las acciones asociadas a las transiciones entre estos estados Ademaacutes las acciones pueden ser enshyriquecidas con informacioacuten de precondiciones que han de cumplirse para llevar a cabo una accioacuten

Ademaacutes en el modelo dinaacutemico con el diagrama de interaccioacuten de objetos se pueden representar las interacshyciones entre objetos en teacuterminos de disparos y transacshyciones globales

43 Modelo Funcionaacutel

Finalmente con el modelo funcional especificamos el efecshyto que tienen las operaciones sobre el estado del objeto como respuesta a los eventos indicando coacutemo cambia su estado Cada uno de los atributos variables de la

CLASE Maacutequina ATRIBUTO estado CATEGORIA pertenencia a una situacioacuten_______________________________iacute __________

Antes Accioacuten Despueacutes

SIN_CONTRATO RESPcontratar CON_CONTRATO CON_CONTRATO RESPcancelar SIN_CONTRATO

Figura 4 Modelo funcional del atributo estado de la clase maacutequina

clase tendraacute una entrada en el modelo funcional que esshypecificaraacute como cambia su valor en funcioacuten del evento que se ejecute La figura 4 representa la especificacioacuten del atributo estado de la clase Maacutequina en el modelo funcional Este atributo se categoriza como de perteshynencia a una situadon lo que indica que toma su valor en un dominio limitado Maacutes concretamente si la acshycioacuten que se produce es RESPcontratar y el atributo estashydo valiacutea SIN_CONTRATO su nuevo valor pasaraacute a ser CON_CONTRATO

44

O Pastor V Pelechano E Insfreacuten y J GoacutemezGenenlcloacuten Automaacutetica de Prototipos en Entomos Intemetllntranet a Partir de M

RESPcontralaacuter 1f estado=SIN_CONTRATO MaquinaO

RESPnew__-n

REScancear_contrato

RESPdeslrOy

bull Figura 3 DTE para la clase maacutequina

44 Modelo de Ejecuci6n

Una vez especificado el sistema el modelo de ejecucioacuten establece la representacioacuten del modelo conceptual en el entorno de desarrollo elegido (en este caso Java) seguacuten lo explicado en el punto 3 Como resultado del proceso de generacioacuten de coacutedigo definido en el modelo de ejecucioacuten obtendremos la arquitectura de la aplicacioacuten para un enshytorno Web de forma automaacutetica Como se comentoacute en el punto 31 esta arquitectura se organiza en tres capas que incluyen

441 Capa de Interfaz

La capa de interfaz estaraacute formada por las clases Java que implementan el interfaz de usuario seguacuten el modelo de ejecucioacuten

Estas clases se estructuran como sigue

bull ControLAccesojava se obtiene la informacioacuten que se necesita para implementar esta clase consultando las clases del dominio que aparecen en el diagrama de clases En el ejemplo son responsable contrashyto_mantenimiento maacutequina y empresa_mantenedora

bull Vista-Sistemajava se obtiene la informacioacuten que se necesita para implementar esta clase consultanshydo del diagrama de clases las relaciones de agente las clases del dominio y los eventos y del diagrama de interaccioacuten de objetos las transacciones globales En el ejemplo la vista del sistema para la clase responsable viene caracterizada por sus relaciones de agente se corresponde con la clase maacutequina y con ella sus eventos new destroy contratar modishyficar_contrato y cancelar_contrato

bull Activacion_Serviciojava se obtiene la informacioacuten que se necesita para implementar esta clase consulshytando del diagrama de clases los atributos necesarios para ejecutar un servicio En el ejemplo para ejecushytar el servicio contratar necesitamos el cad_referencia

de la clase maacutequina y el ciLempresa de la clase emshypresa_ mantenedora

442 Capa de Aplicacioacuten

La capa de aplicacioacuten estaraacute formada por clases Java que implementan las clases del dominio del problema Exshyaminando esta plantilla (ver abajo) podemos observar que toda clase deriva de GestorPersistencia heredando los meacutetodos que se necesitan para asegurar la persistencia de los objetos de la clase Ademaacutes implementa el Intershyface Oasis unas liacuteneas maacutes adelante entenderemos que quiere decir esto

Publiacutec class ltNombreClasegt extends t

ltNombreGestorPersistenciacuteagt implements ltNombrelnterfaceOasisgt ltTipoAtributogt ltAtributogt

servicios de la clase

protected void ltNombreEventogt laquoParametrosgt [] x) protected void ltNombreTransacciongt laquoParametrosgt (] x)

servicios para implementar el modelo de ejecucion

protected void ltNombreCheckTransEstgt (String ltNombreEventoraquo throvs ltNombreExcepcionTransEstgt protected voiacuted ltNombreCheckPrecondgt (String ltNombreEventoraquothrovs ltNombreExcepcionPrecondgt protected void ltNombreCheckRestriccgt (String ltNombreEventoraquo throws ltNombreExcepcionRestriccgt protected void ltNombreCheckDisparosgt (String ltNombreEventoraquo throvs ltNombreExcepcionDisparosgt public void ltActivarNombreEventogt

45

I O Pastor V Pelechano E Insfraacuten y J G6mezGeneracioacuten Automaacutetica de Prototipos en Entornos Internetllntranet a Partir de Mbullbull

laquoParametrosgt [] x) public void ltActivarNombreTransacciongt laquoParametrosgt [] x)

A continuacioacuten se declaran los atributos y se impleshymentan los meacutetodos que se corresponden con los servishycios de la clase (eventos y transacciones) Maacutes adelante se implementa el Interface Oasis es decir se implemenshytan los meacutetodos necesarios para satisfacer el modelo de ejecucioacuten Estos meacutetodos se corresponden con los servishycios para chequear las precondiciones la transicioacuten de estados las restricciones y los disparos Finalmente se implementan los meacutetodos que se necesitan para la acshytivacioacuten de los servicios de la clase habraacute un meacutetodo de este tipo para cada uno de los servicios de la clase (~ventos y transacciones)

La visibilidad de los meacutetodos que se corresponden con los servicios de clase y la de los servicios que implementan el Interfaz Oasis es protected (es decir soacutelo son visibles para los objetos de la clase y sus clases descendientes) Sin embargo la visibilidad de los meacutetodos encargados de la activacioacuten de los servicios de la clase laquoActivarNombreEventogt si es un evento o ltActivarNombreTransacciongt si es una transaccioacuten) es public para permitir que puedan ser solicitados desde obshyjetos instanciados de otras clases Maacutes concretamente estOS meacutetodos seraacuten solicitados por los agentes vaacutelidos

Es importante resaltar el hecho de que toda la inforshymacioacuten que se necesita para implementar este patroacuten de disentildeo se obtiene a partir de los distintos diagrashymas del modelo conceptual lo que asegura el proceso de generacioacuten automaacutetica Los patrones de disentildeo para implementar las precondiciones transicioacuten de estados restricciones y disparos no se comentan por razones de espacio Siguiendo esta plantilla de disentildeo se genera aushytomaacuteticamente el coacutedigo asociado a las clases del doshyminio A continuacioacuten se muestra resumido el coacutedigo Java que implementa la clase del dominio maacutequina

Package capa_aplicacioacuten import Gestor_Persistencia import Oasis bull import excepciones bull

public class M~quina extends Gestor_Persistencia implements Oasis

II atributos de la clase String cod_maquina II identificador String estado String marca String modelo String descripcion String contrato

String revisor

II Atributo que almacena el estado del II DTE en el que se encuentra el objeto String estado_dte II Constructor de la clase public void Maquina (Object[] _parametros)

II Eventos que implementan las II evaluaciones protected boolean Contratar (string empresamnto)

estado = uCON_CONTRATO revisor = empresamnto

II Eventos para soportar la estrategia II de ejecucioacuten protected void Check_Trans_Estados (string event)throws EX_Trans_Estados protected void Check_Precondiciones (string event) throws EX_Precond protected void Check_Restricciones()

throws EX_Restricciones bull protected void Check_Disparos() throws EX_Disparos

II Meacutetodos encargados de la activacioacuten II de servicios ofertados I

public void Activar_Serv_Contratar (String p_cod_maquina String p_empresamnto)

try Recuperar(p_cod_maquina) Check_Precondiciones(UContratarU) Check_Trans_Estados(ItContratar fl )

Contratar(empresamnto) Check_Restricciones() Check_Disparos() SalvarO

catch (EX_Precond e) catch (EX_Trans_Estados e) catch (EX_Restr_Integridad e) catch (EX_Disparos e)

II fin clase maacutequina

Podemos observar como el coacutedigo generado se corresshyponde con el patroacuten de disentildeo Primero tenemos los atrishybutos de la maacutequina luego los meacutetodos correspondientes con los servicios de la clase que en este caso son Maacutequina (meacutetodo constructor de la clase) y Contratar A conshytinuacioacuten los meacutetodos que implementan el Interfaz Oashy

47

O Pastor V Pelechano E Insfraacuten y J GoacutemezGeneraci6n Automtlca de Prototipos en Entornos InternetIntranet a Partir de M

sis que son ChecLTrans_Estados Check_Precondiciones Check_Restricciones ChecLDisparos y finalmente el meacutetodo que implementa la activacioacuten del servicio conshytratar que sigue el algoritmo de ejecucioacuten de eventos tal y como se explicoacute en el punto 232

443 Capa de Persistencia

La capa de persistencia estaraacute integrada por la base de datos es decir por las tablas relacionales que represhysentan las clases del diagrama de objetos y sus relashyciones (herencia y agregacioacuten) En el ejemplo tenshydremos tablas cuyas tuplas representaraacuten objetos de las clases maacutequina responsable empresa_mantenedora y conshytrato_mantenimiento Ademaacutes en esta capa se impleshymentaraacute la clase GestorPersistencia que proporciona los meacutetodos para salvar borrar y recuperar objetos de la base de datos tal y como se explicoacute en el punto 31

444 Ilustracioacuten del Ejemplo

A continuacioacuten se describe un escenario ilustrativo para el prototipo generado

Cuando un cliente carga la paacutegina principal (HTML) de la aplicacioacuten se descarga un applet que instancia un objeto de la clase ControLAcceso Este objeto pide la identificacioacuten del usuario tal y como se puede apreciar en la figura 5 Una vez que el usuario es autentificashydo se instancia un objeto de la clase Vista_deLSistema abrieacutendose un frame que contiene la vista de la sociedad de objetos (servicios a los cuales dicho usuario tiene pershymiso)

La barra de menuacute del frame contiene como iacutetems las clases visibles para el usuario conectado

A cada una de estas clases se le asocia un menuacute desshyplegable que tiene tantos iacutetems como servicios de esa clase a los que el usuario tiene permiso de ejecucioacuten La figura 6 muestra esta situacioacuten

Cuando el usuario selecciona alguno de estos sershyvicios se invoca un meacutetodo de la clase corresponshydiente ( ltActivarNombreEventogt si es un evento o ltActivarNombreTransacciongt si es una transaccioacuten) desshyplegando una caja de diaacutelogo (ver figura 7) para la inshytroduccioacuten de los paraacutemetros necesarios para proceder a la activacioacuten de e~e servicio

El botoacuten OK de esta caja de diaacutelogo tiene asociashydo el coacutedigo necesario para llamar al meacutetodo de la clase que implementa el efecto de la ejecucioacuten de ese evenshyto Este meacutetodo comprobaraacute que existe una transicioacuten vaacutelida desde el estado actual e intentaraacute ver si se sashytisfacen las precondiciones Si se tiene eacutexito el cambio de estado del objeto se nevaraacute a cabo de acuerdo a la especificacioacuten del modelo funcional

middotmiddot--ControMAtceso~middotmiddot

Pasiword

Figura 5 Control del acceso al sistema

Figura 6 Vista del sistema

O Pastor V Pelechano E Insfraacuten y J GoacutemezGeneracoacuten Automaacutetica de Prototipos en Entornos Intemetllntranet a Partir de Mbullbullbull

Clase MfQU1NA

Figura 7 Activacioacuten del servicio contratar

Finalmente se verificaraacuten las restricciones de integrishydad y las condiciones de disparo en el nuevo estado alshycanzado

La actualizacioacuten del estado del oacutebjeto se haraacute persisshytente en la base de datos a traveacutes de los servicios ofertashydos por la clase GestorPersistencia

5 Conclusioacuten y Thabajos Futuros

La construccioacuten de aplicaciones Web maacutes complejas deshypenderaacute en gran parte de hacer la tecnologiacutea de objetos maacutes simple y segura Para conseguir este objetivo debeshymos de producir marcos metodoloacutegicos bien definidos con una correcta conexioacuten entre entornos de modelashydo conceptual 00 y entornos de desarrollo de software OO OO-Method proporciona esta conexioacuten Las caracshyteriacutesticas maacutes relevantes son las siguientes

bull Obtencioacuten de una implementacioacuten operativa del paradigma de programacioacuten automaacutetica

bull Un modelo orientado a objeto bien definido cuya caracteriacutestica baacutesica es el uso de un lenguaje de esshypecificacioacuten como diccionario de datos de alto nivel

Todo esto realizado dentro de entornos de desarrollo Web haciendo uso de arquitecturas InternetIntranet y usando Java como lenguaje de desarrollo de software

Actualmente se estaacuten llevando a cabo trabajos de inshyvestigacioacuten para mejorar la calidad del producto final software generado incluyendo caracteriacutesticas maacutes avanshyzadas tales como interfaces definidos por el usuario evolucioacuten de esquema y mecanismos de optimizacioacuten de acceso a base de datos

48

Referencias

Balzer R Cbeatbam TE and Green C Softshyware technology in the 1990s using a new paradigm IEEE Computer 14(5) 66-77 1983 Boocb G Object Oriented Design with Applications BenjaminCummings 1991 Boocb G Rumbaugb J and Jacobson l UML v1 Tech Rept Rational Software Corp 1997 Jacobson l Cbristerson M Jonsson P and Overgaard G 00 Software Engineering a Use Case Driven Approach Addison-Wesley 1992 Letelier P and Ramos l Un metamodelo estaacutetico para especificaciones OASIS y su implementacioacuten en una base de datos relacional Tech Rept DSIC Universidad Politeacutecnica de Valencia 1995 Pastor O and Ramos l OASIS 211 A ClassshyDefinition Language to Model Inlormation Systems Usshying an Object-Oriented Approach 3a ed Servicio de Publicaciones Universidad Politeacutecnica de Valencia 1995 Pastor O Rayes F and Bear S OASIS An Object-Oriented Specification Language in Loucopoushylos P (ed) Proceedings 01 CAiSE92 International Conshylerence Springer-Verlag vol 593 1992 pp348-363 Pastor O Insfraacuten E Pelecbano V Merseguer J and Romero J OO-Method An 00 Software Production Environment Combining Conventional and Formal Methods f in Oliveacute A and Pastor O (eds) Proceedings 01 CAiSE97 International Conlerence Springer-Verlag LNCS vol 1250 1997 pp 145-158 PIatinum-TecbnoIogy Ine Paradigm Plus Roundshy1hp Engineering lor JAVA Tech Rept Project Techshynology 1997 Rational Software Corp Rational Rose Users Manual Tech Rept Rational Software Corporation 1995 Rumbaugb J BIaba M PremerIani W Eddy F and Lorensen W Object Oriented Modeling and Design Prentice-Hall 1991

O Pastor V Pelechano E Insfraacuten y J GoacutemezGeneracioacuten Automaacutetica de Prototipos en Entornos InternetIntranet a Partir de Mbull

Dr Oscar Pastor es Profesor Titular en el Departamento de Sistemas Informaacuteticos y Computacioacuten de la Universidad Politeacutecnica de Valencia (DSIC) Espantildea Oscar Pastor es Licenciado en Ciencias Fiacutesicas por la Universidad de Valencia y Doctor en Informaacutetica por la Universidad Politeacutecnica de Valencia Es miembro del Grupo de Investigacioacuten en Proshygramacioacuten Loacutegica e Ingenieriacutea del Software en el DSIC y responsable de varios proyectos de Investigacioacuten y Desarrollo en modelado conceptual orientado a objeto y prototipacioacuten automaacutetica Sus actuales liacuteneas de investigacioacuten comprenden ingenieriacutea de requisitos modshyelado conceptual generacioacuten automaacutetica de coacutedigo disentildeo de bases de datos y metodologiacuteas orientadas a objetos

Vicente Pelechano es Profesor Titular Interino en el DSIC de la Universidad Politeacutecnica de Valencia Recibioacute el grado de Licenciado en Informaacutetica por la Universidad Politeacutecnica de Valencia Espantildea Sus intereses de investigacioacuten son orientacioacuten a objetos modelado conceptual ingenieriacutea de requisitos sistemas software basados en componentes y lenguajes de especificacioacuten Es miembro del grupo de investigacioacuten en Programacioacuten Loacutegica e Ingenieriacutea del Software en el DSIC

Emilio Insfraacuten es Profesor Asociado en el DSIC de la Universidad Politeacutecnica de Valencia Sus intereses de investigacioacuten son metodologiacuteas orientadas a objetos modelado conceptual ingenieriacutea de requisitos lenguajes de especificacioacuten y bases de datos Recibioacute el grado de licenciado en Informaacutetica por la Universidad Nacional de Asuncioacuten Paraguay y es Master en Informaacutetica por la Universidad de Cantabria Espantildea Es miembro del grupo de investishygacioacuten en Programacioacuten Loacutegica e Ingenieriacutea del Software en el DSIC y miembro de la IEEE Actualmente realiza una estancia de investigacioacuten en la Universidad de Twente (Holanda) con el ProfDr Roel Wieringa

Jaime Goacutemez es Profesor Titular en el Departamento de Lenguajes y Sistemas Inshyformaacuteticos de la Universidad de Alicante(DLSI) Espantildea Sus intereses de investigacioacuten son orientacioacuten a objetos modelado conceptual ingenieriacutea de requisitos tecnologiacuteas intershynetintranet sistemas distribuiacute dos y generacioacuten de componentes software Recibioacute el grado de licenciado en Informaacutetica por la Universidad Politeacutecnica de Valencia Es miembro del grupo de investigacioacuten en Programacioacuten Loacutegica e Ingenieriacuteadel Software en el DSIC y miembro del grupo de investigacioacuten de Programacioacuten Loacutegica y Sistemas de Informacioacuten en el DLSI Actualmente se encuentra finalizando su tesis doctoral en Generacioacuten Automaacutetica de Componentes Software a partir de modelos Conceptuales 00

38

39

40

41

42

43

44

45

46

47

48

49

iexcl O Pastor V Pelechano E Insfraacuten y J GoacutemezGenetacioacuten Automaacutetica de Prototipos en Entornos Internetllnttanet a Partir de Mbullbull

la especificacioacuten de un sistema de informacioacuten La caracteriacutestica principal de este meacutetodo es que los

esfuerzos de los desarrolladores se centran en la etapa de modelado conceptual y a continuacioacuten de forma aushytomaacutetica se obtiene una implementacioacuten completa del sistema siguiendo un modelo de ejecucioacuten preciso (que incluye estructura y comportamiento)

El resultado final es en este caso una aplicacioacuten Web con una arquitectura de tres capas implementada en Java sobre una base de datos relacional como repositorio de objetos

La herramienta OO-MethodiexclCASEl da soporte a este meacutetodo y constituye una aproximacioacuten operacional a las ideas del paradigma de programacioacuten automaacutetica (Blazer et al 1983) recoleccioacuten de las propiedades del sistema de informacioacuten generacioacuten automaacutetica de una especificacioacuten formal del sistema y obtencioacuten de un proshytotipo de software funcionalmente equivalente a la esshypecificacioacuten del sistema

El contenido del artiacuteculo se estructura de la siguienshyte manera en el punto 2 se comentan brevemente las caracteriacutesticas principales del lenguaje de especificacioacuten OASIS y se presenta OO-Method describiendo los moshydelos que permiten especificar el sistema graacuteficamente y el modelo de ejecucioacuten que se utiliacuteza como patroacuten en el proceso de generacioacuten de coacutedigo En el punto 3 se explican las caracteriacutesticas de la arquitectura de un proshytotipo generado enmiddot Java Para comprender mejor este proceso de traduccioacuten en el punto 4 se desarrolla un cashyso de estudio relativo al Servicio de Mantenimiento de un Hospital Finalmente se presentan las conclusiones y las liacuteneas futuras de actuacioacuten que derivan de este trabajo

2 OO-Method y OASIS

OO-Method es una metodologiacutea de produccioacuten aushytomaacutetica de software basada en teacutecnicas de especificacioacuten formales que usa diagramas graacuteficos similares a los emshypleados tradicionalmente por las metodologiacuteas convenshycionales (OMT Booch UML) El proceso de produccioacuten de software empieza con la fase de modelado conceptual donde se recogen con modelos graacuteficos las propiedades relevantes del sistema a desarrollar Una vez que teshynemos la descripcioacuten del sistema se obtiene de forma automaacutetica una especificacioacuten formal y 00 del sistema Esta especificacioacuten es la fuente de un modelo de ejecucioacuten que determina de forma automaacutetica las caracteriacutesticas del sistema dependientes de la implementacioacuten (intershyfaz de usuario control de acceso activacioacuten de servishy

1El desarrollo de la herramienta OO-MethodCASE ha sido parcialmente subvencionada por el IMPIVA a traveacutes de un proyecshyto del Plan de Ciencia y Tecnologiacutea Valenciano

cios consulta y manipulacioacuten de informacioacuten) Esta proshypuesta proporciona un marco bien definido que nos pershymite construir herramientas de modelado y generacioacuten de coacutedigo basadas en el paradigma de programacioacuten aushytomaacutetica

21 OASIS Un Modelo Formal Orientashydo a Objetos

OO-Method se ha creado sobre las bases de OASIS un lenguaje formal y 00 de especificacioacuten de sistemas de informacioacuten Vamos a dar un breve repaso de las prinshycipales caracteriacutesticas de OASIS En una especificacioacuten OASIS una clase es un patroacuten o conjunto de propiedades que comparten todos sus ejemplares Este patroacuten tiene un nombre y permite la declaracioacuten de un mecanismo de identificacioacuten La signatura de la clase incluye atributos eventos y un conjunto de foacutermulas de la loacutegica dinaacutemica que nos permiten describir el resto de sus propiedades

bull restricciones de integridad estaacuteticas y dinaacutemicas

bull evaluaciones que especifican coacutemo cambian los atrishybutos debido a la ocurrencia de eventos

bull derivaciones que especifican el valor de un atributo derivado en funcioacuten de otros

bull precondiciones que establecen condiciones que deben satisfacerse para activar un evelto

bull disparos que provocan la activacioacuten espontaacutenea de un evento como consecuencia de la satisfaccioacuten de una condicioacuten

Ademaacutes un objeto puede definirse como un proceshyso observable por lo que la especificacioacuten de la clase se enriquece con un aacutelgebra de procesos baacutesica (Pastor amp Ramos 1995) que permite declarar las vidas posibles de un objeto como teacuterminos de este aacutelgebra cuyos elemenshytos son eventos y transacciones combinados con operashydores de alternativa y secuencia de procesos

Por razones de espacio la descripcioacuten del lenguaje de especificacioacuten es introductoria El lector puede encontrar una descripcioacuten mas detallada de OASIS en (Pastor et al 1992) y la descripcioacuten completa de su semaacutentica y fundamentos formales en (Pastor amp Ramos 1995)

22 Modelado Conceptual

Los conceptos formales asociados a OASIS determinan la informacioacuten relevante a capturar en la fase de modelado conceptual Para ello OO-Method proporciona tres moshydelos con los que recoger las propiedades relevantes de un sistema de informacioacuten Los diagramas asociados a cada

39








40














I

1

j























41









42









4 Caso de Estudio


I

l I


J


iexcl


Java















43


- Maquina




Emp sa-nton dora


d~poSt1 Ilt~no

~

~ ()


11















44



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49








40














I

1

j























41









42









4 Caso de Estudio


I

l I


J


iexcl


Java















43


- Maquina




Emp sa-nton dora


d~poSt1 Ilt~no

~

~ ()


11















44



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49


I

1

j























41









42









4 Caso de Estudio


I

l I


J


iexcl


Java















43


- Maquina




Emp sa-nton dora


d~poSt1 Ilt~no

~

~ ()


11















44



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49









42









4 Caso de Estudio


I

l I


J


iexcl


Java















43


- Maquina




Emp sa-nton dora


d~poSt1 Ilt~no

~

~ ()


11















44



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49

I

l I


J


iexcl


Java















43


- Maquina




Emp sa-nton dora


d~poSt1 Ilt~no

~

~ ()


11















44



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49


- Maquina




Emp sa-nton dora


d~poSt1 Ilt~no

~

~ ()


11















44



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49



RESPnew__-n

REScancear_contrato

RESPdeslrOy



















45









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49









String revisor













47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49

47













Pasiword




Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49


Clase MfQU1NA










48

Referencias







38

39

40

41

42

43

44

45

46

47

48

49






38

39

40

41

42

43

44

45

46

47

48

49

Generación Automática de Prototipos en Entornos Internet ...

Documents

Transcript of Generación Automática de Prototipos en Entornos Internet ...