˘ ˇ - dsic.upv.es · v ˛ ˘ ˘ En todo proyecto de cierta envergadura es imprescindible la ayuda...

�

��

��

�

��

��

��

Memoria presentada para optar al título de ��

�

Dirigida por:��

� ��

Tribunal de lectura:

Presidente: � �� !� �� Universitat Politècnica de Catalunya

Vocales: � �� "��#��$ Universitat Politècnica de València

� �� %�� $�#� �� Universidad del País Vasco

� �� &� �� Universidad de Granada

Secretario: � �� %�� &�'$ Universitat Politècnica de València

Valencia, Octubre de 1999

��

�

�

�

v

��

En todo proyecto de cierta envergadura es imprescindible la ayuda de ciertas personas sin las cuales no

sería posible la culminación del mismo, por lo que se hace necesaria esta página de agradecimientos.

Quisiera agradecer, en primer lugar, al Profesor Canós y al Profesor Ramos su inestimable ayuda a la hora

de desarrollar el presente trabajo por sus consejos, revisiones, ideas y apoyo tanto en lo académico como

en lo personal.

Además, quisiera agradecer a Adela Coronado, Raúl Gualberto y Sergio Camilleri por sus aportaciones

realizadas en la implementación del prototipo y por no quejarse conforme las especificaciones iban

cambiando dinámicamente a lo largo del proyecto.

También quisiera agradecer a todos los miembros del grupo de Programación Lógica e Ingeniería del

Software del DSIC y en particular a Fco. Javier Jaén, Mª Carmen Penadés, Vicente Pelechano, Oscar

Pastor, Patricio Letelier, Juan Sánchez y Pedro Sánchez por su apoyo e ideas en las numerosas reuniones

que hemos tenido en los últimos años.

Finalmente, a Inma por su paciencia y apoyo incondicional.

�

vii

��

(� �� (

(�(� ) ��*��! ��!�+�� ,

1.1.1. Diferentes aproximaciones a la Evolución del Esquema .......................................................... 7

(�-� ��.�� /

(�0� !�+�� (1

(�2� )�� +� �� ((

-� )��+��!��(0

-�(� 3�� (,

-�-� !�+�� (,

-�0� �� (/

2.3.1. Agregación ............................................................................................................................. 20

2.3.2. Herencia ................................................................................................................................. 21

-�2� "��+�� --

-�,� "�� -,

-�4� )�5��'�� -6

-�6� &��"��!�� -6

-�/� �� '��!�� -7

-�7� �� 0(

0� 8 ��9: ��&��00

�

�

viii

0�(� : ��&�� 04

3.1.1. Sintaxis de la Frame Logic ..................................................................................................... 37

3.1.2. Ejemplos................................................................................................................................. 39

3.1.3. Semántica Declarativa de la Frame Logic .............................................................................. 41

0�-� 8 ��: ��&�� 20

3.2.1. Sintaxis de la ��................................................................................................................... 44

3.2.2. Ejemplos................................................................................................................................. 44

3.2.3. Semántica Declarativa de la ��............................................................................................ 45

3.2.4. Consecuencia Lógica Ejecucional .......................................................................................... 48

0�0� �� 27

2� :� ��$��!�� ,(

2�(� �� ' �� ,0

2�-� 8�'�� ,4

4.2.1. Identificadores de Objetos...................................................................................................... 57

4.2.2. Atributos................................................................................................................................. 57

4.2.3. Alias e identificación de objetos............................................................................................. 58

4.2.4. Fórmulas de consulta sobre el estado ..................................................................................... 59

4.2.5. Acciones secuenciales ............................................................................................................ 62

4.2.6. Eventos ................................................................................................................................... 63

4.2.7. Transacciones ......................................................................................................................... 64

4.2.8. Servicios ................................................................................................................................. 66

4.2.9. Relaciones de disparo ............................................................................................................. 66

4.2.10. Procesos.................................................................................................................................. 67

4.2.11. Varios ..................................................................................................................................... 68

2�0� �' ��!�� 47

4.3.1. Objetos OASIS ....................................................................................................................... 69

4.3.2. Clases OASIS ......................................................................................................................... 70

4.3.3. Metaobjetos ............................................................................................................................ 71

4.3.4. Metaclases .............................................................................................................................. 71

4.3.5. Esquemas Conceptuales.......................................................................................................... 71

�

ix

4.3.6. Instancia de un Esquema Conceptual ..................................................................................... 72

4.3.7. La Metaclase OASIS .............................................................................................................. 72

4.3.7.1. Identificadores de las metaclases................................................................................. 73

4.3.7.2. La metaclase elemental_class...................................................................................... 74

4.3.7.3. La metaclase temporalSpecialization_class............................................................... 107

4.3.7.4. La metaclase permanentSpecialization_class ............................................................ 122

4.3.7.5. La metaclase aggregation_class................................................................................. 137

4.3.7.6. La metaclase primitive_class..................................................................................... 154

4.3.7.7. La metaclase OASIS ................................................................................................. 160

4.3.8. Caracterización de las clases OASIS en �� ....................................................................... 167

2�2� �� (4/

,� )��(6(

,�(� �� (60

,�-� � 5�� (62

,�0� ��# �� (6,

,�2� �� (/,

4� ��;�8 ��+��:�� (/6

4�(� 8 ��+��:�� (71

*�� (70

�'�� -1(

�'��*�� .�� -16

�'��<�)+�'��"��!��--(

�

�

x

�'��<��'��!��8:& ��-06

�

xi

=��:��

Figura 1: Modificación por evolución. Los esquemas antiguos no son accesibles. ...................................... 8

Figura 2: Modificación por versionado de esquemas. Diferentes esquemas pueden ser válidos a la vez..... 8

Figura 3: Un objeto OASIS....................................................................................................................... 18

Figura 4: Definición de la plantilla de una clase en OASIS ....................................................................... 19

Figura 5: El metaobjeto book ................................................................................................................... 23

Figura 6: Representación de la jerarquía �� de metaclases en la metaclase OASIS ................................ 26

Figura 7: Representación del esquema conceptual de oasisMetaclass. ................................................... 28

Figura 8: Relación �� entre el esquema conceptual de la metaclase OASIS y su instancia

oasisMetaclass........................................................................................................................ 28

Figura 9: Doble visión de la metaclase OASIS. ......................................................................................... 29

Figura 10: Un nuevo esquema conceptual instancia de la metaclase.......................................................... 30

Figura 11: Relaciones �� e �� en el esquema conceptual de la biblioteca............................ 31

Figura 12: Jerarquía �� entre la metaclase OASIS (en la raíz de la jerarquía), dos esquemas

conceptuales y diferentes instanciaciones de los esquemas. ...................................................... 32

Figura 13: Evolución del estado en �� .................................................................................................... 36

Figura 14: Representación de la jerarquía �� de metaclases y jerarquía �� entre los

metaobjetos que definen con su estado las metaclases en la metaclase OASIS......................... 73

Figura 15: Una clase elemental en un sistema de información genérico .................................................... 75

Figura 16: Parte de la plantilla ��de la metaclase �� ........................................................ 76

Figura 17: Arquitectura de �� .......................................................................................................... 174

Figura 18: Detalle de la Interfaz Gráfica de Usuario de �� .............................................................. 175

Figura 19: Pantalla de entrada a �� con dos esquemas definidos. .................................................... 176

Figura 20: Esquema conceptual de la metaclase OASIS .......................................................................... 176

Figura 21: Una instancia de la metaclase OASIS (un esquema conceptual)............................................. 177

Figura 22: Clase �� ........................................................................................................... 178

�

�

xii

Figura 23: Metaobjeto �� instancia de la metaclase ��............................................ 179

Figura 24: Visión como clase de un metaobjeto....................................................................................... 180

Figura 25: Ventana de entrada de parámetros para añadir un atributo a un metaobjeto. .......................... 181

Figura 26: El esquema conceptual ��............................................................................................... 182

Figura 27: La biblioteca �� ..................................................................................................... 182

Figura 28: Clase �� en una instancia del esquema �� .................................................................. 183

Figura 29: Visión de una instancia de la clase �� ................................................................................ 183

Figura 30: Definición de una vista por proyección sobre la clase �� ................................................... 184

Figura 31: Definición de una vista por selección sobre la clase �� ...................................................... 185

Figura 32: Reificación en �� del evento ��! de los esquemas conceptuales......................................... 240

Figura 33: Reificación en TFL del evento "�� de clases elementales ................................................ 241

Figura 34: Reificación en �� del evento ��! de las clases elementales ................................................ 243

Figura 35: Reificación en TFL del evento "�� de clases elementales ................................................ 244

Figura 36: Reificación en �� del servicio que especializa temporalmente a las instancias de una clase 245

Figura 37: Reificación en �� del servicio que hace perder la especialización a las instancias de una

especialización temporal. ........................................................................................................ 246

Figura 38: Reificación en �� del servicio que crea objeto especializados permanentemente................ 248

Figura 39: Reificación en �� del servicio que destruye instancias de especializaciones permanentes. . 248

Figura 40: Reificación en �� del evento ��! de las clases elementales ................................................ 250

Figura 41: Reificación en �� del evento "�� de clases elementales................................................. 250

Figura 42: Reificación en �� del modelo de ejecución de eventos de OASIS....................................... 252

�

xiii

=��8��

Tabla 1: Atributos más importantes de los metaobjetos OASIS................................................................. 24

Tabla 2: Principales eventos de los metaobjetos o clases OASIS .............................................................. 24

Tabla 3: Relaciones de herencia en ��. ................................................................. 39

�

(��

,QWURGXFFLyQ�

3

�

#$�� %�� &'(� �� "�� "�� )�"�� "�� *� ��

��+��"��"��%��+��"��"��"��)�"��,�

Primera ley de ingeniería de sistemas [Ber80].

Es un hecho, detectado por numerosos profesionales de la industria, que la mayor parte de los esfuerzos

realizados en informática hacen referencia al área del mantenimiento del software. Según estudios

realizados, entre el 65% y el 75% de las fuerzas vivas relacionadas con el mundo de la informática

[McK84] y aproximadamente el 80% de los gastos totales del software [You89] se dedican al

mantenimiento del software existente.

En [Sjø93] se realizó un estudio de la evolución del sistema de gestión de información de un hospital

implantado sobre bases de datos relacionales durante 18 meses. En dicho estudio se observó que, en ese

periodo, el número de relaciones aumentó en un 139%, el número de atributos se incrementó en un 279%

y todas las relaciones sufrieron modificaciones. Aunque el estudio se hizo sobre un sistema relacional

podemos extrapolar los resultados a sistemas orientados a objetos.

El software debe evolucionar porque los requerimientos de los sistemas de información (SI) cambian con

el tiempo. Una vez finalizado el proceso de desarrollo, se ofrece a los clientes un producto que es modelo

de su sistema de información en ese momento. Con el paso del tiempo, el sistema deberá adaptarse a los

cambios, ya vengan inducidos por el entorno (legislaciones, normas,...), ya sean inducidos por el propio

sistema (crecimiento, cambios en las motivaciones,...) [Pre97]. Por supuesto, todo el esfuerzo que el

usuario haya realizado trabajando con el producto no debe perderse y los datos almacenados en el sistema

de información deben cambiar para adecuarse al nuevo modelo.

A la vista de los porcentajes anteriores queda claro que el uso de herramientas que automaticen el proceso

de evolución es muy interesante y puede ayudar a la mejora de los procesos de mantenimiento del

software y a la reducción de los costes asociados.

Por otro lado, cuando a un analista se le encarga el estudio de un sistema de información, obtiene un

modelo del mismo que puede no reflejar exactamente el sistema. Esto es debido, posiblemente, a

problemas de comunicación, a la falta de vocabulario común, a la posible inexperiencia del analista y a la

posible falta de concreción del problema por parte de los usuarios.

Aplicando ciclos de vida evolutivos del software [Pre97] - a ser posible con construcción de prototipos -

las especificaciones se pueden ir refinando hasta llegar un momento en el que serán validadas por los

usuarios. Tal y como propone Balzer [Bal83, Bal85], sería deseable que los prototipos y los programas

2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�

�

�

4

finales fuesen creados de forma automática a partir de las especificaciones. Si se utilizan en la

construcción de los sistemas software herramientas que generen automáticamente las aplicaciones

partiendo de las especificaciones, el proceso de mantenimiento de aquellas puede verse en gran medida

reducido, ya que podría abordarse mediante cambios en la especificación seguidos de un proceso de

regeneración automática que afecte tanto al código como a los datos.

Parets [Par99] clasifica los trabajos realizados en torno al tópico de evolución en 5 categorías:

i. ��"��"��"��"��+��"��-�: centrados en capturar la dinámica de los

sistemas como sucesión de estados por los que pasan y los motivos por los que cambian de

estado.

ii. ��"��"��"��"��+��"��!��: consideran la evolución como los cambios sufridos por

los programas, no como una necesidad por adaptarse al entorno, sino como fuente de problemas

que hay que cuantificar.

iii. ��"��"�� "�� %�� "�� "�� "�� !��: relacionado con el diseño de modelos,

fundamentalmente iterativos, para capturar el proceso de producción de software, incluyendo la

gestión de configuraciones y el control de versiones.

iv. ��"��"�� "�� "��+�� "�� %�� "�� %��-��"�� "�� !��: la evolución se

entiende como los diferentes ��"��"��"'��-� por los que pasa el sistema. En este caso el

cambio de un estadio a otro está motivado por la intervención del equipo de desarrollo para

cambiar el modelo del sistema.

v. ��"��%��: centrados en el proceso de transformación de un programa P en

un programa P’ que satisfaga los requisitos del programa original con el mismo significado.

En este trabajo nos vamos a centrar en la cuarta categoría. Cambiar un sistema lo vamos a considerar

como la obtención de un nuevo modelo del sistema, inducido por el diseñador del mismo.

Gran parte de los sistemas de información (SI) usan los servicios de un Sistema Gestor de Bases de Datos

(SGBD) para dotar de persistencia a los datos con los que se trabaja. Por ello, es importante estudiar la

evolución del software desde el punto de vista de las bases de datos; que en este caso, consiste en la

modificación del esquema conceptual que modela los sistemas de información y de los datos

almacenados.

,QWURGXFFLyQ�

�

5

(�(�� ) ��*��! ��!�+��

En los sistemas gestores de bases de datos relacionales (SGBDR) clásicos sólo se almacena los datos y las

relaciones entre las tablas que forman el esquema. El problema de la evolución se resuelve ofreciendo un

conjunto de primitivas que permiten modificar las tablas y las relaciones que se hayan establecido entre

las mismas. SGBDR más avanzados incluyen disparos y procedimientos almacenados en los que se debe

asegurar la consistencia si el esquema sufre modificaciones.

En los sistemas gestores de bases de datos orientados a objetos (SGBDOO) el problema de la evolución es

más complejo, puesto que la complejidad del modelo es mayor. No sólo se almacenan datos y sus

relaciones, sino que un objeto es una unidad que encapsula estado y comportamiento, por lo que la

evolución debe contemplar, no sólo los datos y sus relaciones (mantenimiento de la ��

��'��'��) sino que, además, debe contemplar la modificación de los servicios que ofrezcan los objetos y

las posibles inconsistencias entre los mismos (mantenimiento de la ��"��%��).

Para poder modificar un esquema, es necesario proporcionar un conjunto de primitivas que manipulen

cada una de las características del modelo sobre el que se basa. Banerjee [Ban87] proporcionó una

primera taxonomía sobre la evolución basada en ORION que todavía hoy es aplicable a muchos

SGBDOO (con las modificaciones pertinentes basándose en el modelo de objetos subyacente). La

siguiente es una versión muy resumida de la taxonomía de ORION.

1. ��"�� "�� "��-�� "�� . Incluyen las primitivas para añadir, borrar y

modificar tanto atributos como métodos.

2. ��"��-��"��.��&'/��"��0��. Cambios en la jerarquía de herencia, inserción y

eliminación de una superclase.

3. ��"��-�� "�� .'�� "�� . Creación, destrucción y cambios de nombre de

clases.

Las primitivas de manipulación de los esquemas se pueden clasificar en: �"��)�, '��)� o ��

[Mon93]. Los cambios aditivos son aquellos que añaden información al esquema, como por ejemplo:

añadir un atributo, una clase, etc. Los cambios substractivos son aquellos que eliminan información del

esquema. Finalmente, existen primitivas, como el cambio de nombre de un atributo, cuyos cambios son

aditivos y substractivos a la vez.


�

�

6

Además, las primitivas pueden ser ��"�%��"�� "�� 1 si no afectan a las consultas que se

puedan realizar sobre la BDOO. La primitiva que cambia el código asociado a un método es un ejemplo

de primitiva independiente de la interfaz.

Won Kim en [Kim90] propone otra forma de categorizar los cambios en los esquemas. Un cambio débil

(��) es aquél que no requiere que las instancias sean migradas1 a otra clase, como, por ejemplo, el añadir

o borrar atributos o cambiar el nombre de un atributo. Un cambio fuerte (0��")�es aquél que implica la

migración de objetos entre clases, como por ejemplo el dividir una clase en � subclases con el

consiguiente reajuste de las poblaciones a la nueva jerarquía de herencia.

Cuando se induce una modificación en el esquema de una BDOO es posible que éste quede en un estado

inconsistente. Tradicionalmente, para resolver este problema se han definido un conjunto de invariantes

que rigen el proceso. La lista siguiente incluye los invariantes más comunes que se aplican en ORION

[Ban87], GemStone [Bre89], O2 [Del91, Zic91] y Chimera [Cer93].

� �� !�"��#��

La jerarquía de herencia debe formar un grafo dirigido acíclico. Algunos sistemas requieren que

el grafo tenga una raíz única (la clase del sistema OBJECT o CLASS).

� �� $��% ��

Todas las clases tienen nombres diferentes. Todos los atributos y métodos de una clase deben

tener nombres diferentes.

� �� % ��

Todos los atributos y métodos deben tener un origen único distinto: una clase no puede tener dos

atributos o dos métodos distintos que tengan el mismo origen en la jerarquía de herencia.

� �� #��

Las clases heredan todas las características de sus superclases, excepto cuando se producen

violaciones de los invariantes anteriores.

1 En el sentido de pertenencia a la población de una clase.

,QWURGXFFLyQ�

�

7

� �� $��

Si un atributo Ai de una clase C es heredado de un atributo Aj de una superclase de C, entonces el

dominio de Ai debe ser el mismo de Aj o una subclase del dominio de Aj.

�� &�'�� &��(��

Cuando se redefine un método en una subclase, el dominio de los parámetros de salida debe ser

el mismo o especializado en la redefinición (��)��1�). El dominio de los parámetros de entrada del

método redefinido debe de ser el mismo o una generalización (��)��1�).

� ��

Cuando una información va a ser eliminada de una clase, con el fin de que no se produzca una

pérdida de información, los clientes de la clase2 son informados del cambio que se va a producir,

proporcionándoles la información necesaria para que puedan seguir funcionando. Este invariante, presente

únicamente en Gemstone, todavía no ha sido implementado.

La mayoría de los trabajos realizados hasta la fecha se centran en el problema del mantenimiento de la

consistencia estructural (de hecho, los invariantes presentados fueron definidos para asegurarla). Pero una

de las principales características de la orientación a objetos es la encapsulación del estado y del

comportamiento. ¿Qué pasa con el mantenimiento de la consistencia de comportamiento cuando se

produce un cambio en una clase? ¿Qué ocurre con los métodos definidos en las clases y que hacen uso de

los atributos que se manipulan?

Algunos sistemas como por ejemplo Gemstone estudian el impacto del cambio de la estructura sobre los

métodos. En O2 se dice que una base de datos es �� %�� si ningún método

produce errores o resultados inesperados en tiempo de ejecución.

(�(�(�� ' �.��) ��)�5��

A la hora de realizar los cambios en las BDOO existen básicamente dos aproximaciones a la

modificación:

• Modificación por ��: basada en la visión dinámica (modelo conceptual dinámico

[Bub86]). Cuando se induce una modificación del esquema, todos los objetos existentes

2 Entendidos como los objetos que referencian la clase.


�

�

8

deben adaptarse al nuevo esquema, inmediatamente o en diferido, con lo que se pierde la

información del estado anterior. Algunos de los sistemas que usan esta aproximación son:

ORION, GemStone, OTGen [Ler90], O2, COCOON [Tre92].

�� !PRG� PRG� PRG�

Figura 1: Modificación por evolución. Los esquemas antiguos no son accesibles.

• Modificación por ��: basado en una visión temporal o en mecanismos de vistas

ampliados para simular la evolución. Cuando se induce un cambio se genera una nueva

versión/vista del esquema. Desde ese momento coexistirán las dos versiones en el sistema.

Esta aproximación plantea problemas adicionales como puede ser la necesidad de que los

objetos pertenezcan a diferentes versiones del esquema. Estos son algunos de los sistemas

que usan esta aproximación: Avance [Bjø88], Encore [Ska87], Multiple Views [Zdo90],

CLOSQL [Mon93], Multiperspectives [Odb95].

�� !PRG� PRG� PRG�

Figura 2: Modificación por versionado de esquemas. Diferentes esquemas pueden ser válidos a la vez.

Para mantener la compatibilidad de los programas externos con la BDOO que se modifica existen

diferentes aproximaciones. Como ya se ha visto, se pueden mantener diferentes vistas o versiones del

esquema, manteniendo la compatibilidad entre las mismas, lo que puede tener justificación desde un punto

de vista estructural pero no de comportamiento. Otra aproximación, consiste en asegurar que los métodos

que sean invocados externamente no sean modificados (mantengan la interfaz) [Lem94].

(�-�� .��

En la actualidad, se están realizando numerosas propuestas para captar la dinámica de los sistemas usando

reflexión. Por reflexión se entiende la construcción de sistemas haciendo uso de varios niveles, en el que

el comportamiento de un nivel (nivel base) es descrito como datos en el nivel superior (nivel meta), de

manera que cambiar el comportamiento del nivel base se realiza modificando el estado del nivel meta. La

,QWURGXFFLyQ�

�

9

ventaja es que el mismo modelo y los mismos mecanismos de manipulación pueden ser utilizados para

trabajar en ambos niveles.

En [Cue99] se presentan diferentes niveles de reflexión en función de las capacidades de los sistemas:

• ��%��-�, cuando se puede recuperar información del sistema,

• ��2�-��'/�� o ��'��'��, cuando se permite añadir nuevos componentes,

• ��2�-��"��%��, cuando es posible cambiar el comportamiento de los componentes

existentes.

El lenguaje de programación SmallTalk [Gol87] ya contemplaba en su definición la utilización de

metaclases para poder inicializar de manera especial a los objetos (servicios de creación de objetos). Sun

incluyo en la versión 1.1 de Java un API3 que permite la introspección en el lenguaje pudiendo recuperar

en tiempo de ejecución información sobre los campos, métodos y constructores definidos en las clases

[Sun99]. Microsoft, en su modelo de componentes �3�, también permite la introspección cuando las

clases de componentes implementan la interfaz 45�%��0, pudiendo obtener información en tiempo de

ejecución sobre cuáles son las propiedades y métodos que implementa un componente [Rog97].

Las bases de datos OO de COCOON [Tre92] y la versión reflexiva del $�0��)��'�� de

Chimera [Lem95] utilizan metaclases para definir y manipular la parte estática de los esquemas de bases

de datos. ODMG 2.0 [Cat97] ha incluido una interfaz meta para poder acceder a la información de un

esquema en tiempo de ejecución, definiendo incluso un conjunto de operaciones para poder manipular el

esquema cuya implementación se deja a los SGBD que cumplan con el estándar. Aunque la especificación

sólo contempla la lectura de la información, dejando la escritura para futuras versiones.

El patrón arquitectónico �� [Bus96] proporciona mecanismos para cambiar la estructura y el

comportamiento de sistemas dinámicamente. El patrón divide las aplicaciones en niveles, de manera que

la lógica de la aplicación se implementa en el nivel base y las propiedades volátiles (que pueden cambiar

fácilmente) se deben implementar como estado de un nivel meta (pudiendo existir tantos niveles meta

como sea necesario). Para poder cambiar dinámicamente el comportamiento del nivel base, se debe

proporcionar un ��3�.�� (MOP) encargado de hacer los cambios pertinentes tanto en el nivel

base como en el nivel meta. El MOP se encarga de realizar los cambios desde fuera del nivel meta. En

este patrón existe comunicación entre ambos niveles: el nivel meta obtiene información del nivel base y el

3 Application Programming Interface


�

�

10

nivel base para funcionar usa las características definidas en el nivel meta. Tal y como propone el patrón

de diseño, sólo pequeñas partes de la aplicación (las que pueden cambiar) se colocan a nivel meta, el resto

se codifican a nivel base.

(�0�� !�+��

Este trabajo pretende abordar la problemática de la evolución continuando la línea emprendida hace unos

años por la escuela declarativa [Ser87] en las que se fusionaba el uso de ambientes y lenguajes lógicos

con nociones objetuales que ya se conocían, provenientes de la escuela imperativa. En esta línea apareció

hacia 1989 la familia de lenguajes MOL [Ram90, Can91], que más tarde evolucionarían hacia el lenguaje

OASIS [Pas92], una herramienta de especificación de sistemas de información abiertos y activos cuyo

objetivo primordial ha sido históricamente la construcción rápida de prototipos de sistemas de

información en el marco del paradigma de la programación automática, proceso soportado

metodológicamente por OO-METHOD [Pas92], obteniendo finalmente una versión de OASIS que puede

ser usada como lenguaje único en bases de datos deductivas y activas orientadas a objetos resolviendo el

problema del desacoplo de impedancia [Can96].

Tomando como referencia básica el modelo de objetos de OASIS se plantea su uso como marco

conceptual en el que describir y abordar las tareas de mantenimiento del software, preservando en todo

momento la consistencia tanto de los modelos como de los datos. La aproximación que se va a seguir se

basa en una evolución por cambio del modelo del sistema (ver clasificación de Parets en la página 4).

Con el fin de incluir aspectos de evolución, se amplía el modelo de OASIS de manera reflexiva

introduciendo la noción de metaclases, que permiten definir y cambiar los esquemas haciendo uso del

propio modelo OASIS, obteniendo un modelo con reflexión de comportamiento que permite el cambio del

comportamiento de los objetos dinámicamente.

Se ha construido un prototipo que permite la especificación, validación y evolución de los sistemas de

información utilizando como metáfora única de trabajo el modelo OASIS. El prototipo realizado sigue

una aproximación por evolución de los esquemas y no por versionado de esquema porque pensamos que

el versionado de esquema sólo tiene sentido si lo que se desea es acceder a la información almacenada

(los datos) desde programas externos que no son actualizados automáticamente cuando se cambia el

esquema. Aún en este caso, dichos programas ya no podrán usar los métodos definidos en las versiones

antiguas a riesgo de que actualicen mal la información almacenada, siendo necesario usar los métodos de

la última versión del esquema. Por otro lado, en OASIS los únicos programas que acceden a la

,QWURGXFFLyQ�

�

11

información se modelan como clases dentro del esquema y por lo tanto, en nuestra aproximación,

evolucionan junto con los cambios que se introducen en el esquema.

(�2�� )�� +��

El tema de esta Tesis se soporta en tres pilares básicos: un modelo, la definición de las operaciones de

evolución del mismo y una herramienta que soporta el modelo e implementa las operaciones de

modificación sobre éste. El capítulo 2 presenta el modelo orientado a objetos OASIS ampliado con las

nociones de metaobjetos y metaclases que, de forma reflexiva, proporcionan las bases para soportar la

evolución de los sistemas desde dentro del propio modelo

Con el objetivo de realizar una descripción formal de la metaclase OASIS se hace necesario el uso de

algún formalismo que de soporte a la ��-�4 de OASIS. En el capítulo 3 se presenta la ��

�� ( ��) el formalismo lógico escogido para describir formalmente el modelo ampliado de

OASIS con metaclases.

En el capítulo 4 se describe formalmente el modelo de OASIS haciendo uso de la ��. Se describen todos

los servicios que proporcionan las metaclases con la semántica asociada a las operaciones de modificación

de los esquemas. Los servicios presentados se encargan de asegurar la consistencia estructural y de

comportamiento de los modelos que se definan.

En el capítulo 5 se describe �� , el prototipo construido que implementa las ideas presentadas en los

capítulos precedentes. �� es una herramienta CASE que tiene como núcleo una implementación de la

metaclase OASIS realizada en ��. �� permite definir modelos de SI usando el modelo OO de

OASIS, validar por prototipación automática las especificaciones realizadas y evolucionarlas haciendo

uso de los servicios proporcionados.

Finalmente, en el capítulo 6 se presentan las conclusiones y las futuras líneas de investigación que quedan

abiertas tras el presente trabajo.

4 Una reificación es un cambio en el nivel de abstracción de manera que aquello que es atómico en un nivel de

abstracción deviene compuesto desde un punto de vista reificado. Técnicas de reificación: técnicas desarrolladas para

descomponer el software en piezas más simples [Den96]. El refinamiento que acompaña al cambio de nivel de

análisis a diseño de un concepto es una reificación. También lo es, la implementación de un concepto de diseño en un

lenguaje de programación concreto.


�

�

12

En los apéndices se presenta un resumen de la notación gráfica utilizada, servicios adicionales de

evolución a los presentados en el capítulo 4 que los complementan y aseguran el mantenimiento de la

consistencia, varios ejemplos de uso de la Metaclase OASIS para definir sistemas, crear prototipos y

modificarlos y, finalmente, las transacciones �� que permiten animar las especificaciones OASIS.

�

-�� )��+��!��

(O�PRGHOR�GH�REMHWRV�GH�2$6,6�

15

Tratándose de una aproximación a la evolución del software como evolución del modelo conceptual, antes

de nada es necesario presentar el modelo de referencia ya que éste determinará las operaciones que se

podrán aplicar.

En este capítulo se presenta, en primer lugar, un resumen del modelo de objeto de OASIS que sustenta

nuestro trabajo, basado en el descrito en [Can96]. Como veremos, se basa en nociones ��+�� del mundo

de los sistemas de información, las bases de datos y la teoría de procesos, abordadas desde una

perspectiva formal usando ciertas lógicas que permiten representar los conceptos definidos.

Posteriormente el modelo es extendido con la noción de metaclases para dar cuenta de la evolución de los

sistemas de información organizacionales [Fal96] dentro del propio modelo.

-�(�� 3��

En el modelo orientado a objetos el universo de discurso está compuesto de objetos. Los objetos tienen un

nombre que les identifica y, en general, se relacionan entre sí durante sus vidas. Los sistemas pueden ser

descritos como sociedades de objetos que interaccionan. Por su parte, la estructura del sistema se plasma

en la capacidad de los modelos OO para expresar relaciones estructurales entre los distintos objetos que

los componen; así, veremos que podemos definir objetos complejos a partir de otros más simples, de los

que heredarán ciertas propiedades dependiendo del tipo de composición que se realice. La idea de

jerarquía se plasmará, pues, en nuestro modelo atendiendo a dos tipos de relaciones fundamentales como

son la especialización y la agregación.

-�-�� !�+��

En OASIS, los bloques básicos de construcción de los sistemas de información son los ��.��. Un objeto

es un proceso observable que encapsula estado y comportamiento. Todo objeto tiene un �"��"��

(oid5), que es independiente del estado del objeto y permanece inalterado siempre. El tipo abstracto de

datos (TAD) que representa el conjunto de identificadores debe cumplir dos propiedades: tener

cardinalidad infinita (para asegurar la identificación de cualquier objeto que pueda existir) y que exista

una relación de igualdad definida (para poder determinar si dos objetos son o no el mismo objeto).

5 Object IDentifier, en inglés.


�

�

16

El ��"� de un objeto está caracterizado por el conjunto de valores de sus ��'��. Existen tres tipos de

atributos:

• ��, que toman valor en el instante de creación del objeto y no cambian durante la

vida del mismo,

• )��, cuyo valor puede cambiar durante la vida del objeto,

• "��)�"�, cuyo valor se obtiene a partir de otros atributos mediante ��"��"��)��-�.

En OASIS se utiliza la lógica para representar el estado de los objetos: el estado de un objeto en un

momento dado se reifica en una teoría en alguna lógica (por ejemplo, lógica de 1er orden en [Can96]);

fórmulas bien formadas (fbf) caracterizan el valor de los atributos. Para facilitar la identificación de los

objetos se definen mecanismos de identificación (��) basados en los atributos constantes de los objetos,

de forma que estos puedan ser identificados en el espacio del problema.

El ��%�� de un objeto se define por los servicios que ofrece al resto de la sociedad de objetos y

por la forma en que los sirve:

• Un �)�� es la abstracción de un cambio de estado. Un conjunto de fórmulas, las �� "��

�)��'��-�, representa cómo se ve afectado el estado de los objetos debido a la ocurrencia de los

eventos. En [Can96] se usa la lógica dinámica para representar dichas fórmulas. Otras

aproximaciones se pueden seguir usando diferentes lógicas como la ��

[Kif95a] usada en el presente trabajo o la ��%�� [Ehr96].

• Las �� son unidades de comportamiento moleculares, formadas a partir de eventos, que

poseen dos características: cuando una transacción comienza, ésta se ejecuta totalmente o, en caso de

fallo, se debe deshacer lo realizado; y los estados por los que pasan los objetos durante la ejecución

de transacciones no son observables.

Otra parte del comportamiento de los objetos está relacionada con los conceptos deónticos de prohibición,

permiso y obligación. Por un lado, la %��"��-� de un evento es una fórmula que, evaluada sobre el

estado del objeto, impide que el objeto realice el servicio en el caso de que no se satisfaga. Por otro lado,

6 suceso (del inglés �)��).


�

17

las �� "�� "�%�� permiten definir el comportamiento activo de los objetos en función de su

estado; son reglas condición-acción�en las que la condición es una fórmula que, cuando se satisface en el

estado del objeto, éste adquiere la obligación de iniciar la acción (petición de servicio a algún objeto). Se

distingue entre dos tipos de disparos: aquellos que sólo pasan un mensaje al objeto destino (�/��) y

aquellos en los que es necesario que el destinatario responda para continuar con la actividad del objeto

cliente (/��).

Las ��"��"�" restringen los estados (��+��) o secuencias de estados ("��+��) en

los que pueden encontrarse los objetos. Se representan usando lógica de 1er orden y temporal,

respectivamente.

El %�� que representa a un objeto [Ram92] es construido sobre el alfabeto de eventos usando

operadores tomados de la teoría de procesos. Operadores como la elección, la secuencia, etc., son la parte

funcional del álgebra de procesos usada para describir las vidas posibles de los objetos, asociando

términos del álgebra para representar el conjunto de secuencias de eventos o ��1� permitidas en la vida

del objeto. La vida de un objeto, entendida como sucesión de cambios de estado, se puede, por tanto,

describir mediante una traza formada a partir de los eventos servidos por el objeto, que debe ser correcta

de acuerdo a las especificaciones de comportamiento expresadas en la descripción de proceso.

Cuando un objeto recibe, a través de un mensaje, la petición de uno de los servicios que ofrece, sigue unos

pasos predeterminados que concluirán con la ejecución del servicio pedido si se satisfacen ciertas

condiciones. Se llama ��"�� "�� .��'��-� a los pasos que se siguen para resolver la petición de un

servicio. El modelo genérico de ejecución de eventos para objetos OASIS es el siguiente:

1. Validación del evento según la traza actual del objeto y su descripción como proceso.

2. Validación de la precondición del evento.

3. Modificación del estado interno del objeto conforme se haya definido en las reglas de evaluación.

4. Comprobación de la validez de las restricciones de integridad en el estado de llegada.

5. Comprobación de las condiciones de activación de los disparos en el nuevo estado y petición de

todos aquellos servicios cuya condición se satisfaga.

La Figura 3 muestra un objeto OASIS en la notación gráfica que viene descrita en el Apéndice A. En

concreto, en la figura se muestra el estado y los servicios ofrecidos por un libro en el sistema de

información (simplificado) de una biblioteca. El estado de un libro está formado por un código (id_book),

un título (title), un autor (author), y puede estar en cualquier momento disponible o no (available). Los

servicios que ofrece un libro son: el de ser prestado a (lend), o devuelto por (return) un socio. Los


�

�

18

eventos anteriores podrán atenderse siempre que se satisfagan las precondiciones pertinentes (para poder

prestar un libro debe de estar disponible). Nótese que el oid (en este caso, book1) se ha dibujado fuera

del objeto deliberadamente para así dejar claro que es un elemento no perteneciente al dominio del

problema y, por tanto, no forma parte del estado del objeto. En cualquier momento un objeto cliente

puede pedir a ese libro alguno de sus servicios enviando el mensaje apropiado. A su vez, el libro podría

ser cliente de otros objetos del sistema, aunque no sea éste el caso7.

id_book → 113;title → “Hamlet”;

author → “Shakespeare” ;available → true

�� 6

��"

��'��

Figura 3: Un objeto OASIS

En la figura anterior no aparecen reflejadas las reglas del proceso, ni las precondiciones de los eventos, ni

las reglas de evaluación, ni los disparos. Todas éstas características se codifican siguiendo el modelo de

ejecución presentado, en forma de reglas (en [Can96] la codificación se realiza en lógica dinámica, en este

trabajo se codifican en ��, como se verá en el capítulo 4 y en el apéndice D).

-�0��

OASIS ofrece, al igual que la mayoría de modelos OO mecanismos de clasificación, de forma que objetos

de propiedades similares se agrupan en clases. Antes de definir el concepto de clase se presentan unas

definiciones previas.

Se llama %�� al conjunto de propiedades de estructura y comportamiento que son compartidas por

una colección de objetos. La plantilla define los atributos, los eventos, las reglas de evaluación, las

precondiciones de los eventos, las restricciones de integridad, las relaciones de disparo, y la descripción

del proceso.

7 Un libro no es un objeto activo en este ejemplo.

8 Del inglés ��%��.


�

19

Se llama ��%� a la tupla formada por: una plantilla, una �'��-��"�� y la definición de la

parte pública de la plantilla9. La función de nombramiento relaciona cada objeto con un identificador

independiente del estado del objeto.

�� book�� )��$��id_book: nat; title: string; author: string;��$��)��$�� available:bool; �� id_book( ID ) & ID>100.��***� �)��

Figura 4: Definición de la plantilla de una clase en OASIS

Una �� OASIS está formada por: un tipo, una ��/� (que proporciona los mecanismos para la

creación y destrucción10) y un ��(� de objetos (a través de la noción de %��-�). Tradicionalmente,

en OASIS se ha usado la clase para la definición de plantillas (en la Figura 4 se puede ver una parte de la

especificación de la plantilla de la clase book). En [Can96] se introdujo por primera vez en OASIS la

visión de clase como algo más una plantilla. Una clase es el equivalente en tiempo de ejecución a lo que

representa una plantilla en tiempo de especificación; en cierto modo, es la implementación de una

plantilla.

Todo objeto es un ejemplar11 de alguna clase. Los objetos y las clases están relacionados a través de

relación ��. Los objetos tienen un estado determinado por los valores que toman unos

atributos, ofrecen unos servicios y satisfacen las fórmulas definidas en la plantilla de la clase.

9 OASIS asume que el estado de los objetos está totalmente encapsulado y que un objeto no puede acceder a un

atributo de otro objeto; por ello, se asume que en la plantilla de todo objeto, además de los eventos declarados

explícitamente, existe de manera implícita un evento por cada atributo, con el mismo nombre que el atributo y que

representa el servicio “hacer público el valor del atributo” sin alterar el estado propio.

10 Eventos ��!�y "�� respectivamente.

11 También llamado instancia (del inglés ��).


�

�

20

La complejidad de la descripción del mundo real requiere distinguir entre diferentes tipos de clases: las

�� %��)� (que permiten definir tipos abstractos de datos utilizados como dominios de los

atributos), las �� y las ��%��.� (construidas a partir de otras clases utilizando

operadores entre clases tales como la especialización y la agregación). Veamos a continuación las

facilidades que ofrece OASIS a la hora de especificar clases complejas.

-�0�(��

En los modelos OO la ��-� es la forma habitual de representar que un objeto complejo tiene como

componentes a otros objetos. La definición de la agregación varía en función de los criterios usados a la

hora de fijar el significado de reunir objetos en un objeto compuesto. En OASIS se caracterizan los

diferentes tipos de agregación de acuerdo con las siguientes dimensiones:

1. Si un objeto puede aparecer como componente de más de un objeto simultáneamente, es decir, si

puede participar a la vez en más de una agregación, se habla de agregación ��"�.'��, mientras

que en caso contrario la agregación se llama "�.'��. La agregación no disjunta permite que

ciertos objetos compartan algunos componentes.

2. Si un objeto sólo puede existir como parte de un objeto compuesto, la agregación es �� y en

caso contrario ��2��.

3. Dependiendo del número de objetos componentes que comparten la misma plantilla asociados a un

objeto compuesto, distinguiremos entre agregación '��)��'�"��(sólo uno) y �'��)��'�"��(tantos

como se quiera).

4. Si alguna clase componente puede no tener instancias participando en la agregación en un

momento dado, tenemos una agregación con nulos (�'��). En caso contrario tenemos una

agregación sin nulos (��'��).

5. Si la agregación tiene una composición fija una vez ha sido creada, se habla de agregación ��+��;

si, por el contrario, su composición cambia con el tiempo debido a la ocurrencia de eventos

relevantes de inserción y extracción para sus componentes, la agregación se dice "��+��.

6. Dependiendo del tipo de ligadura o relación entre contenido y continente se distingue entre:


�

21

• Agregación��'�)�: es aquella en la que los componentes no pueden existir fuera del objeto

compuesto. Su principal característica es que cualquier objeto componente está

completamente encapsulado en la agregación, en el sentido de que su estado sólo puede ser

alterado por eventos locales, activados por los eventos proporcionados por la interfaz de la

agregación.

• Agregación ��o��7 difiere de la inclusiva por el hecho de que sólo denota

una relación existente entre los objetos componentes, sin ser necesaria una inclusión completa

de éstos en el objeto compuesto. Se puede acceder a los objetos componentes sin pasar por el

objeto compuesto.

-�0�-��

La 0�� es un poderoso mecanismo que permite introducir la clasificación en el modelado de los

sistemas compartiendo propiedades entre clases que se organizan en una jerarquía, con una representación

en forma de grafo en el caso más general, que posibilita, desde el punto de vista de la programación, la

reutilización de código en la construcción de programas. La especialización y la generalización dan

soporte a la noción de herencia.

• En el modelo OASIS se definen dos tipos básicos de relaciones de especialización:

i) �%��1��-�� %�� o ��: en ella los objetos cambian su estado y comportamiento de

forma dinámica. Cuando el objeto sufre un evento, llamado %��"��, el objeto pasa a .'��

�� descrito en la plantilla de la clase especializada.

ii) �%��1��-�� %��: un objeto es instancia de la clase especializada desde el mismo

momento de su creación debido a que se cumple una ��"��-��"��%��1��-� basada en el

valor que toman algunos de sus atributos constantes en el instante de creación del objeto.

• La ��1��-� es la operación inversa a la anterior y define la 0��"�� o generación de

plantillas padres recogiendo las propiedades comunes de las plantillas definidas con anterioridad, es

decir, la plantilla generalizada es construida sobre un conjunto de plantillas hijas, abstrayendo sus

propiedades comunes y reuniéndolas en una plantilla de un nivel superior.


�

�

22

-�2�� "��+��

Con el objetivo de formalizar la funcionalidad como factoría de las clases, se introduce la noción de

metaobjeto. Un metaobjeto es un objeto que puede ser visto desde dos puntos de vista diferentes, pero

complementarios (ver Figura 5):

• Como clases (parte izquierda de la figura) ofrecen unos servicios que son precisamente los

encargados de:

a) crear y destruir objetos, mediante los eventos ��! y "�� (buyBook y dropBook en la

figura) y

b) mantener vivo el censo de objetos que ha creado y todavía no han sido destruidos (extent en

la figura).

En la figura se puede ver parte de la especificación OASIS de la plantilla de la clase book y la

población en el atributo extent.12

• Como objeto (parte derecha de la figura) ofrece unos servicios que permiten definir el conjunto de

propiedades que constituyen el tipo que compartirán todas sus instancias. La figura muestra parte del

estado del metaobjeto book cuyo nombre es “book”. Además tiene definidos los atributos constantes

title y author, como evento lend, etc.

Los servicios como addConsAtt, addEvent, etc. son precisamente los que permiten construir el tipo de

la clase. Los objetos que crea un cierto metaobjeto se conocen como sus instancias, como ocurre en la

aproximación tradicional OO, y en el momento de su creación toman el tipo definido por (parte de) el

estado del metaobjeto que lo creó. En efecto, los valores de los atributos variables consAtt, varAtt, etc.,

del objeto�book en el momento en que éste realice el servicio buyBook�� determinarán precisamente la

estructura con la que el objeto book1 de la Figura 3 es creado. De la misma manera, el valor del atributo

event determina el conjunto de servicios que sus instancias ofrecerán.

12 La sintaxis utilizada en las figuras para mostrar los atributos es la sintaxis de la �� que será

presentada en el siguiente capítulo.

13 Este es el evento ��! de la clase book.


�

23

Figura 5: El metaobjeto book

Asociamos la vista como objeto del metaobjeto a la definición de los sistemas. Los usuarios de los

servicios que manipulan el estado de los metaobjetos son los diseñadores que, en ��%�� "�� "��-�,

describen los sistemas haciendo uso de los servicios proporcionados. Y, asociamos la vista como clase a

la explotación de los sistemas. Los usuarios finales harán uso de los servicios que hayan definido los

diseñadores para trabajar con el sistema.

En la Tabla 1 se muestran los atributos más importantes que poseen los metaobjetos, y que están

directamente relacionados con los servicios que éstos ofrecen. Los primeros permiten definir el tipo que

van a compartir todos los objetos que cree la clase, el último (marcados con el símbolo *) forman parte de

lo que podríamos llamar el ��"��%��%�� de la clase.

�8��*38!� ��#>�:��!�

��

��

�� ;�� '� ��

��

�� ' �'��

�#�� '� ��

��+�� ' ��

��,��

��

��'�� '��

�� '� ��

�� 5��

��

�� '��' ��

��

vista como clase

vista como objeto

�""��

�""�)��

�'��

"��%��

�� book�� )��$��

� �)��extent ->> { }

name -> “book”; consAtt ->> { atr( title, string ),

atr( author, string )... } ;

event ->> { ev( lend, nil ), ... }

��

vista como clase

vista como objeto

�""��

�""�)��

�'��

"��%��

�� book�� )��$��

� �)��extent ->> { }

name -> “book”; consAtt ->> { atr( title, string ),

atr( author, string )... } ;

event ->> { ev( lend, nil ), ... }


�

�

24

�-�� '��

Tabla 1: Atributos más importantes de los metaobjetos OASIS

Los principales eventos definidos en la plantilla de los metaobjetos OASIS aparecen reflejados en la

Tabla 2. En ella se aprecia cómo se puede construir un tipo. Así, por ejemplo, si a un metaobjeto se le

solicita el servicio addVarAtt con los argumentos adecuados (nombre del atributo, tipo en el que toma

valores y valor por defecto), el efecto que tendrá sobre su estado será que el atributo varAtt tendrá un

elemento más. Si el metaobjeto que se ha modificado tiene instancias, éstas deberán ser modificadas para

ser válidas de acuerdo con el nuevo estado. Este punto será abordado con todo detalle en el capítulo 4.

��)?)>8!� ��#>�:��!�

�� @�� '��

��,�� @�� ;�� '� ��

��.�� @�� ;��

�� @�� ' �'��' �� ;� ��

��/��#�� ' �'��'� ��

�� @��

��# ��+�� ' ��

��# ��

��# ��,��

�� @��.' ��'� ��

��

��,��

��.��

�� ' �'��

��#�� '� ��+��

��

�� 0� � ��+�'� ��

��'�0� ��+�'� ��

Tabla 2: Principales eventos de los metaobjetos o clases OASIS

Los eventos ��! y "�� son los encargados de crear y destruir ejemplares de la clase. Éstos, al ser

creados, toman como estado inicial una instanciación de la plantilla que define el estado del metaobjeto

que lo ha creado. Merece la pena contemplar con mayor detalle el proceso que sigue un metaobjeto para

crear ejemplares de él. El proceso consiste en:


�

25

1. determinar el oid que se asignará al objeto creado,

2. crear el objeto con dicho oid, y

3. actualizar el estado del metaobjeto en su atributo �2��.

Como se puede ver, se trata de una acción compleja pero que debe tener un comportamiento atómico con

las características propias de las transacciones. Así pues, y aunque sigamos hablando de ella como de un

evento, se considera la creación de objetos como una transacción definida para las clases. En el momento

de creación del objeto, los valores iniciales del objeto deben estar definidos. Esto se consigue de la

manera siguiente:

a) Los valores de los atributos constantes los proporciona el objeto que solicita a la clase la creación

del nuevo ejemplar como parte de los argumentos de la llamada.

b) Los valores de los atributos variables se inicializan al valor por defecto definido en la plantilla o

se proporcionan en los argumentos de la llamada.

c) Los valores de los atributos derivados se calculan a continuación a través de las fórmulas de

derivación (aunque por razones de eficiencia se relega la evaluación hasta que los atributos son

consultados)

-�,�� "��

Como ya se ha comentado, todo objeto es un ejemplar de alguna clase, por lo tanto, los metaobjetos

también son instancias de alguna clase. Tradicionalmente, las clases de las que son instancias las clases se

llaman ��.

Las plantillas de las metaclases definen los atributos necesarios para almacenar el conjunto de fórmulas

que definen la plantilla de una clase OASIS (la Tabla 1 mostró la mayor parte de los atributos), los

eventos que permiten manipular dichos atributos (la Tabla 2 mostró los principales eventos definidos en

las metaclases), las precondiciones, restricciones de integridad, las evaluaciones, etc.

OASIS proporciona tres unidades de diseño a la hora de definir sistemas de información, que son: las

clases primitivas (que permiten definir tipos abstractos de datos), las clases elementales y las clases

complejas. Por cada una de las diferentes clases que se pueden especificar en OASIS existe una metaclase

distinta.


�

�

26

En la Figura 6 se pueden observar las metaclases definidas cuyas instancias son los metaobjetos que con

su estado definen la plantilla de las clases primitivas (primitive_class), las clases elementales

(elemental_class) y las clases complejas: especializaciones temporales y permanentes

(temporalSpecialization_class y permanentSpecializacion_class respectivamente), y agregaciones

(aggregation_class).

is-a

is-a

is-a

“elemental_class”

“permanentSpecialization_class”

“temporalSpecialization_class”

“aggregation_class”

“primitive_class”

Figura 6: Representación de la jerarquía �� de metaclases en la metaclase OASIS

En el diagrama anterior las metaclases están relacionadas por herencia ya que se ha tomado la decisión de

utilizar los mismos servicios que sirven para especificar las características de las clases elementales para

especificar las características de las clases complejas, redefiniendo el comportamiento cuando sea

necesario. Las clases complejas son especializaciones temporales, ya que cualquier aspecto de una

especificación OASIS puede ser cambiado una vez definido, incluyendo las relaciones que se puedan

definir entre las clases14.

La metaclase OASIS, tal y como se puede observar en la Figura 6, surge del estudio del modelo de objetos

de OASIS centrándose fundamentalmente en los aspectos sintácticos de las especificaciones. Otras

metaclases podrían definirse pero se escogió ésta por ser la más cercana a cómo son las especificaciones

OASIS de los sistemas de información, existiendo una relación 1 a 1 entre un metaobjeto instancia de

alguna metaclase del diagrama anterior y una clase en la especificación de un sistema, haciendo uso del

lenguaje de especificación OASIS.

En [Ram95] se puede encontrar la especificación OASIS de una primera versión de un editor textual de

especificaciones OASIS haciendo uso de metaclases.

14 De forma que una clase que es una clase elemental pueda pasar a ser subclase de otra o compuesta de otras clases,

etc.


�

27

-�4�� )�5��'��

Los �&'�� %�'�� proporcionan el marco en el que definir las plantillas de las clases que

constituyen un determinado sistema de información. El conjunto de todas las plantillas con sus relaciones

de estructura que modelan un sistema forman un esquema conceptual. Los esquemas, de forma similar a

las clases, están formados por una plantilla que es el resultante de la composición de las plantillas de las

clases en él definidas, una ��/� (que proporciona los mecanismos para la creación y destrucción de

instancias suyas) y un ��(�.

Instanciaciones diferentes de un esquema conceptual dan lugar a diferentes %��%� o bases de datos del

sistema de información definido, que comparten la misma definición de esquema. Las instancias de los

esquemas conceptuales están formadas inicialmente por la composición paralela15 de las clases, sin

población, cuyas plantillas están definidas en el esquema del cual es instancia. Conforme el usuario haga

uso de los servicios ��! y "�� de las clases irá creando y destruyendo objetos en el prototipo del

sistema.

Por lo tanto, distinguimos entre: esquema conceptual como una colección de plantillas que definen

totalmente un sistema de información (codificado en el estado de unos metaobjetos), e instancia de un

esquema conceptual que será un prototipo del sistema que los diseñadores validarán por animación y con

el que los usuarios finales pueden trabajar. La primera noción corresponde a lo que se conoce como

��%��"��"��-� y la segunda al ��%��"��.��'��-��-�.

-�6�� &��"��!��

Se llama ��3�$4$ al esquema conceptual que define las plantillas de las metaclases que permiten

crear metaobjetos que con su estado definen las características de clases primitivas, elementales y

complejas. Diferentes instancias de la metaclase OASIS serán diferentes esquemas conceptuales OASIS

cada uno de ellos definiendo, posiblemente, diferentes modelos de sistemas de información.

La metaclase OASIS, a cuyo oid llamamos oasisMetaclass, ofrece como únicos servicios el evento de

creación de instancias de ella (el evento newInstance) y el de destrucción de sus instancias (el evento

destroyInstance). Tiene como población el conjunto de esquemas definidos y como plantilla la

composición de las plantillas de las metaclases (ver Figura 7).

15 En el caso de que se hayan definido varias clases en el esquema.


�

�

28

FRQFHSWXDOBVFKHPD�2DVLV0HWDFODVV

��FODVV�elemental_class��

��HQGBFODVV

�HYHQWV�newInstance;��

HQGBFRQFHSWXDOBVFKHPD

RDVLV0HWDFODVV

QHZ,QVWDQFH

extent → { RDVLV0HWDFODVV }

GHVWUR\,QVWDQFH

Figura 7: Representación del esquema conceptual de oasisMetaclass.

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. De manera que, una de las instancias de la

metaclase OASIS es ella misma y en ella están codificadas todas las operaciones que permiten definir el

tipo de los esquemas, crear metaobjetos y hacerlos evolucionar. La instancia de la metaclase OASIS cuyo

oid es oasisMetaclass, define cómo deben de ser los esquemas conceptuales a través de unos

metaobjetos que almacenan como estado la plantilla de las metaclases presentadas en la Figura 6 (ver

Figura 8).

RDVLV0HWDFODVVRDVLV0HWDFODVV

QHZ,QVWDQWH



��


LVBLQVWDQFHBRI

class_list -> { elemental_class,tempSpec_class, ... }

elemental_class[ name -> ... ].tempSpec_class[ name -> ... ]....

GHVWUR\,QVWDQFH

Figura 8: Relación ��entre el esquema conceptual de la metaclase OASIS y su instancia

oasisMetaclass.

El esquema definido en la instancia de la metaclase OASIS oasisMetaclass y el esquema conceptual de

la metaclase OASIS� son el mismo esquema en sus dos visiones (esquema / instancia). Visto como

esquema proporciona el servicio de creación de esquemas conceptuales que serán descritos por los

diseñadores. Visto como objeto contiene en su estado la definición de las metaclases (elemental,

primitiva, especializaciones, ...).


�

29



��HQGBFODVV




name -> “OasisMetaclass”;class_list -> { elemental_class,

tempSpec_class,... }

elemental_class[ name -> ... ].tempSpec_class[ name -> .. ].

RDVLV0HWDFODVV

QHZ,QVWDQFH

LVBLQVWDQFHBRI

GHVWUR\,QVWDQFH

vistacomo

instancia

vistacomo

esquema

Figura 9: Doble visión de la metaclase OASIS.

-�/�� '��!��

Cuando un diseñador decide crear un nuevo esquema, la única posibilidad de que dispone es la activación

del servicio newInstance de la metaclase OASIS. La activación de dicho servicio genera una

instanciación de la metaclase OASIS lista para ser usada, cuyo oid podría ser por ejemplo cs1. La

operación de instanciación tiene como efecto generar un metaobjeto complejo que tiene como tipo el

definido en el esquema en el que se ha invocado el evento ��!. Dicha instancia podrá ser manipulada para

definir el esquema conceptual que se desee.

La nueva instancia de la metaclase OASIS tiene un estado, inicialmente vacío, en el que todos los

atributos tienen valores por defecto y las metaclases que forman parte de dicho esquema no tienen

inicialmente población (ver Figura 10). El diseñador puede definir nuevas clases (invocando el servicio

��! de la metaclase elemental_class), definir la plantilla de las mismas (añadiendo atributos, eventos,

precondiciones, etc.), definir las relaciones entre las clases, ... Conforme va disparando eventos, se va

rellenando el estado de la metaobjeto cs1 para reflejar el esquema conceptual del SI que está definiendo.


�

�

30

LVBLQVWDQFHBRI

QHZ,QVWDQFH

FRQFHSWXDOBVFKHPD�´´


extent → {}

name -> “” ;class_list -> { }

FV�



��HQGBFODVV



extent → { oasisMHWDFODVV�

FV� }

name -> “OasisMetaclass”;class_list -> { elemental_class,

tempSpec_class,... }

elemental_class[ name -> ... ].tempSpec_class[ name -> .. ].

RDVLV0HWDFODVV

QHZ,QVWDQFH

LVBLQVWDQFHBRI

GHVWUR\,QVWDQFH

GHVWUR\,QVWDQFH

�

Figura 10: Un nuevo esquema conceptual instancia de la metaclase.

Supongamos que el diseñador decide definir el esquema conceptual de una biblioteca. Haciendo uso de

los servicios que le proporcionan las metaclases, el usuario podrá definir nuevas clases (el socio, el libro,

el préstamo), definir las propiedades de las clases (atributos, precondiciones, restricciones de integridad,

etc.), definir las relaciones existentes entre las clases que pueblan el esquema (préstamo agregación

relacional de socio y libro), etc. Al hacerlo así, se alcanzaría un estado tal y como se muestra en la

siguiente figura, en la que existen unos determinados metaobjetos (cuyos nombre son: member, book,

markedMember, lend) que con su estado definen las plantillas de las clases del esquema de la biblioteca

(cs1).

“elemental_class”


“aggregation_class”“permanentSpecialization_class”


“member” “book”

“lend”

“markedMember”: is_a: is_instance_of


�

31

Figura 11: Relaciones �� e �� en el esquema conceptual de la biblioteca.

Una vez definido el esquema conceptual de la biblioteca, el usuario podrá crear instanciaciones del

mismo, invocando el evento new del esquema conceptual (newLibrary)16, de forma que diferentes

instanciaciones del esquema conceptual de la biblioteca darán lugar a diferentes bases de datos que

comparten el mismo esquema conceptual. Por ejemplo, la biblioteca de la “Universidad Politécnica de

Valencia” (lib1) o la biblioteca de la “Universidad de Murcia” (lib2) o la biblioteca de la “Universidad de

Valencia” (lib3) etc. En la Figura 12 se pueden ver dos esquemas conceptuales: el de la biblioteca y el de

la venta de coches, cada uno con instanciaciones diferentes (diferentes prototipos que comparten la misma

definición de esquema conceptual).

-�7��

En este capítulo se ha presentado el modelo de objetos sobre el que se sustenta OASIS, incluyendo la

metaclase como parte del propio modelo, con la posibilidad de instanciar las clases y los esquemas que se

definan.

El trabajo de esta Tesis se centra en la definición de la metaclase como herramienta a utilizar durante todo

el ciclo de vida de las aplicaciones software, de forma que abarque las áreas de análisis, diseño,

implementación y especialmente la de mantenimiento. Para diseñar un modelo de un sistema de

información el ingeniero de software utiliza la metaclase para ir construyendo interactivamente un modelo

de la realidad. La implementación del software se obtiene automáticamente por prototipación automática a

partir de las especificaciones que ha introducido gracias a unas semánticas bien definidas. El

mantenimiento del software surge de forma natural al hacer uso de los servicios de la metaclase en los que

están codificadas las acciones necesarias a realizar cuando el sistema debe ser cambiado para adecuarlo a

la nueva realidad.

16 Suponemos que se ha renombrado el evento ��! del esquema conceptual.


�

�

32

��

��

��

�8�6

��

��

��

0�%P

��

FRQFHSWXDOBVFKHPD OLEUDU\��

FRQFHSWXDOBVFKHPD VKRSSLQJ��

FRQFHSWXDOBVFKHPD 2DVLV0HWDFODVV

��

�

Figura 12: Jerarquía �� entre la metaclase OASIS (en la raíz de la jerarquía), dos esquemas

conceptuales y diferentes instanciaciones de los esquemas.

�

�

0�� 8 ��9: ��&��

7UDQVDFWLRQ�)UDPH�/RJLF�

35

Para poder describir de manera formal la metaclase introducida en el capítulo anterior se hace necesario

el uso de algún modelo formal que proporcione una sólida base sobre la que apoyarse al hacer la

definición. Existen diferentes formalismos que se han usado a la hora de expresar las bases de diferentes

modelos OO, especificaciones algebraicas [Wie90 y Wie91] para CMSL, especificaciones algebraicas

[Tov94] y lógica dinámica [Can96] para OASIS, lógica lineal temporal para OBLOG [Ser91]. Muchos de

los modelos formales anteriores tienen el problema de la lejanía de los conceptos formales y los conceptos

objetuales que formalizan. La �� no presenta el problema anterior, siendo el

propio modelo lógico el que soporta directamente los conceptos objetuales más comunes como objeto,

identificador, jerarquía de herencia, plantilla. Además, la �� permite la definición de los datos y los

metadatos, así como su manipulación haciendo uso del mismo lenguaje. Por las razones anteriores se

escogió dicho formalismo para sustentar a la metaclase OASIS que se presentará formalmente en el

capítulo 4.

Parte de este capítulo ha sido extraído de [Kif95a], [Kif95b], [Bon95] y [Car97a].

La �� ( ��) es un formalismo lógico recientemente propuesto por Michael Kifer,

Georg Lausen, Anthony Bonner y James Wu, que proporciona un modelo formal para los LPOO y las

BDOO haciendo uso de los tradicionales conceptos de objeto, identificador lógico, jerarquía de herencia y

plantilla de clase. �� es la resultante de la unión de dos lógicas: la �� [Kif95b] que da soporte

a la noción de estado en un marco orientado a objetos, y la �� [Bon95] que formaliza la

noción de cambio de estado declarativo.

La �� es un formalismo interesante que permite la descripción de las sociedades de objetos haciendo uso

de un lenguaje sencillo, lógico y formal orientado a objetos. Permite definir con el mismo lenguaje los

datos y los metadatos eliminando la necesidad de cambiar de marco para tratar la evolución del esquema.

De forma similar a como se hace en los lenguajes imperativos, �� usa operadores secuenciales para

especificar transacciones componiendo acciones simples17 en otras más complejas haciendo uso de una

nueva conectiva lógica llamada conjunción secuencial. �� puede dar soporte a un amplio rango de

aplicaciones, como por ejemplo, bases de datos deductivas, programación lógica o inteligencia artificial

en las que tanto el estado como el comportamiento es tratado de forma declarativa.

17 Acciones de inserción o borrado de información del estado.


�

�

36

Estado 0

Transacciones

Estado 1

Estado nt1 t2 tn

Figura 13: Evolución del estado en ��

En �� existe, por un lado, la BDOO que describe el estado usando fórmulas en �� (F-logic)

que reflejan el estado actual de la sociedad de objetos y, por otro lado, existe una ��"��

que manipula el estado. La base de transacciones no es susceptible de ser manipulada y permanece

inalterada con el paso del tiempo. En cambio, el estado es modificable y evoluciona conforme se ejecutan

transacciones. La Figura 13 ilustra gráficamente está situación.

La �� tiene una semántica declarativa por teoría de modelos y una teoría de la demostración correcta y

completa que la hace ejecutable y, por tanto, especialmente interesante a efectos de prototipación.

0�(�� : ��&��

La F-logic es, como ya se ha dicho, una “lógica de estados”. Los componentes básicos con los que se

construyen los estados son los ��.��. El estado de los objetos está caracterizado por el conjunto de

valores de las propiedades estáticas de los objetos llamadas �(��"�. Los objetos proporcionan el

��2�� en el que se evalúan los métodos. Cada objeto tiene un �"��"�� independiente de su estado

y que permanece inalterado a lo largo de la vida del mismo. Objetos similares (que comparten las mismas

propiedades) se agrupan en ��. La especificación de una clase es la descripción de las propiedades que

una colección de objetos (las instancias de la clase) comparten. Para reflejar la complejidad de los

sistemas reales, los objetos y las clases se organizan en .��&'/��"��0��.


�

37

0�(�(�� .��: ��&��

El ��$�� de un lenguaje (�) en F-logic, consiste en:

• un conjunto de constructores de objetos, �;

• un conjunto de símbolos de predicados, ℘;

• un conjunto infinito de variables, �;

• símbolos auxiliares: (, ), [, ], ->, ->>, *->>, =>, etc; y

• las conectivas lógicas usuales y cuantificadores: �, �, �, �, �.

Los constructores de objetos (los elementos de �) juegan el papel de símbolos de función en F-logic. Cada

función tiene una aridad. Los símbolos con aridad 0 se llaman ��. Se llama �"�� a los términos

de primer orden construidos a partir de símbolos de función y constantes, que se usan como

identificadores lógicos de objetos.

Existen tres tipos de ��18:

1. 9��0�� 4��. Permiten definir .��&'/�� "�� 0��. Se dispone de dos tipos de relaciones de

herencia entre objetos: por un lado, la relación i�� permite definir una clase como subclase de otra

dada; por otro lado, la relación i�� permite definir las instancias de las clases. Si ' y 5 son

id-terms, la sintaxis de las relaciones de herencia es:

'�<�5� indica que el objeto ' es una instancia de la clase 5

'<<5 indica que la clase ' es una subclase de la clase 5

2. ��(�'��. Tienen la forma:

'A�.' ��B�B�� Q��

En F-logic se pueden encontrar diferentes tipos de expresiones. Las cuatro primeras expresiones se

llaman �2%��"��"�� (usadas para definir las propiedades de los objetos y de las clases), y las

18 También llamadas +�� o ��(�'��.


�

�

38

dos últimas se llaman �2%��"��'�� (usadas para definir la plantilla de las clases). Sean

ri, si id-terms que denotan objetos y, vi, ai id-terms que denotan clases.

1. expresión ��

scalM(r0, ..., rk) �� s (k≥0)

2. expresión, ��

setM(r0, ..., rk) �� { s0, ..., sn } (k, n≥0)


scalMI(r0, ..., rk) �� s (k≥0)


setMI(r0, ..., rk) �� { s0, ..., sn } (k, n≥0)

5. expresión de ��

scalM(v0, ..., vk) �� (a1, ..., at) (k≥0, t≥1)

6. expresión de ��

setM(v0, ..., vk) �� (a1, ..., at) (k≥0, t≥1)

Tanto las expresiones de datos como las expresiones de signatura pueden ser escalares o evaluadas a

conjunto. Los símbolos ��, �� y �� denotan expresiones de métodos escalares, y los símbolos ��, ��

�� y �� denotan expresiones de métodos evaluados a conjunto.

Las expresiones de datos pueden ser heredables o no heredables. Las flechas �� y �� denotan

expresiones de métodos no heredables y las flechas �� y �� denotan expresiones de métodos

heredables. Los métodos heredables son heredados como métodos heredables en las subclases de las

clases en la que estén definidos, y son heredados como métodos no heredables en las instancias de las

clases en las que estén definidos (ver semántica en 3.1.3).

3. ��(�'��. Tienen la forma:

�� !��!��Q�"��

Siendo �� un símbolo de predicado y ��, ..., �Q id_terms.


�

39

Las fórmulas atómicas pueden ser combinadas para formar �� haciendo uso de las

conectivas lógicas (�, �, �), cuantificadores (�, �) y la implicación lógica (�).

#�$�%�� &��

Algunos ��'�� de objetos, o id_terms, son:

6:*��8;<*�.��:8*�%�"��=��>*��

Un oid puede hacer referencia tanto a un objeto como a una clase19, lo que permite manipular los datos

(objetos) y el esquema (las clases) con el mismo lenguaje.

Se pueden definir ��(�)�� a través de los 0��0��4��.

�

*�� +�� +��'��

�� .��7��'"�� (.�� es una instancia de la clase ��'"��)

�� '"��77�%�� (la clase ��'"�� es una subclase de %��)

Tabla 3: Relaciones de herencia en ��.

Los �� son F-moléculas que pueden ser vistos como cuasi-funciones20 (��7�3�"� �?�5��)21 que

reflejan el estado de los objetos. En el siguiente ejemplo se pueden observar los objetos .�� y �� con

los atributos ��, �� e 0�.� en F-logic.

.��@��?,A�(�B��/�,�C��?�DEEEEE�F�

��@�0�.��??�G�'�*��H�F�

donde .��, ��, �'� y �� son identificadores lógicos de objetos que identifican a personas*�#A�(�

B��/�, es un identificador de un objeto de tipo ��, DEEEEE es un identificador de un objeto �� y

��, �� e 0�.� son atributos. El atributo 0�.� es un atributo evaluado a conjunto. Los atributos

evaluados a conjunto tienen como co-dominio el superconjunto del dominio (��7�3�"��?�8'RP).

19 En cierto sentido las clases se ven como objetos.

20 Ya que su valor puede cambiar de una invocación a otra para un mismo argumento.

21 Los atributos tienen como dominio el conjunto de identificadores de objetos y como co-dominio el dominio en el

que están definidos los valores que devuelve la función.


�

�

40

Los �� son F-moléculas que pueden ser vistos como cuasi-funciones que, dado un objeto y unos

argumentos, devuelven unos resultados (��07�3�"�2�5��2��2�5��Q��?�5��). Formalmente, el objeto

que proporciona el contexto es el primer argumento de la función y el resto de argumentos son los

argumentos propios del método. En el siguiente ejemplo se puede observar cuál es el ��4"�� de un

objeto dado.

.��@��4"��=�6II8�>��?�8EE�F��

.��@��4"��=�6II:�>��?�86E�F��

.��@��4"��=�6IIJ�>��?�DEE�F��

A pesar de que en algunos sistemas orientados a objetos se marca una línea de separación entre atributos y

métodos, en F-logic los atributos no son otra cosa que métodos 0-arios22, esto es, métodos que no poseen

argumentos propios.

Tanto las expresiones de datos como las expresiones de signatura pueden ser escalares o evaluadas a

conjunto. Por ejemplo, .��@��=6IIJ>��;EEEEF indica que cuando se invoca el método �� con

argumento 6IIJ en el objeto .�� se devuelve el objeto cuyo identificador es ;EEEE. Una F-molécula con

una expresión evaluada a conjunto como ��6@0�.�=�'�*��>��G.'��*.��*��HF indica que

cuando se invoca el método 0�.� en el objeto ��6 con argumentos �'� y ��, se devuelve un

conjunto formado por los identificadores de objetos .'��, .�� y ��.

En F-logic se pueden usar �� que son útiles para, por ejemplo:

• Definir, manipular y razonar sobre las clases y sus instancias, usando el mismo lenguaje.

• Para definir clases virtuales (o vistas) y sus atributos a través de reglas deductivas.

• Explorar el esquema y buscar información.

El peligro existente en usar lógicas de orden superior como base de un lenguaje de programación es que la

validación no sea computable. A pesar de todo, una sintaxis de orden superior no tiene por qué implicar

problemas computacionales, especialmente si, como se ve en [CKW93], la semántica resultante es de

22 Cuasi-funciones 1-arias.


�

41

primer orden (si las variables de orden superior toman valores sobre la intensión de los conjuntos y no

sobre los conjuntos mismos).

En F-logic, las expresiones de orden superior se obtienen eliminando la distinción entre clases, atributos y

objetos. En concreto, no es necesario un �� especial para representar las clases. El mismo término

sintáctico puede ser usado como identificador de objeto, clase o nombre de método, dependiendo,

únicamente de la posición sintáctica que ocupe el término en la frase. Por ejemplo, para preguntar a qué

clases pertenece el objeto .��, escribimos:

K��.��7�L�

donde la variable X puede tomar valores sobre el conjunto de oids. Debido a la posición sintáctica de la X,

los únicos oids que pueden ser sustituidos por la variable X son los de las clases.

Las posibilidades para buscar información son muy extensas. Se pueden definir reglas como la siguiente:

3@��"�=�>�??G�H�F�←�3@��?�F�M��7��

en la que se define cuáles son los atributos interesantes A para cualquier objeto O de una clase C como el

conjunto de atributos en los cuales el objeto tiene como valor V un id-term de la clase C.

#�$�#�� +��,��-�� .��/��

Dado un F-lenguaje, �, siendo � el conjunto de símbolos de función y ℘ el conjunto de símbolos de

predicado, el ��)��"��9��" de �, �, es el conjunto de todos los id-terms básicos. La ��"��

9��" de �, ΗΒ, es el conjunto de todas las fórmulas atómicas básicas.

Se llama ��'��'��"��9��" de � a cualquier 0�� ΗΒ que satisface las siguientes condiciones:

• Las fórmulas en 0 deben satisfacer las propiedades de la igualdad: reflexiva, simétrica, transitiva y

sustitutiva.

• Los hechos Is-A satisfacen las siguientes propiedades:

� �� p :: p ∈ 0, ∀p ∈ ��

�� p :: q, q :: r ∈ 0 �� p :: r ∈ 0�

�� p :: q, q :: p ∈ 0 �� p = q ∈ 0�


�

�

42

�� p : q, q :: r ∈ 0 �� p : r ∈ 0

• Los métodos escalares deben satisfacer la propiedad de ��, que exige un comportamiento

funcional de los métodos escalares, tanto heredables como no heredables, de forma que un método

escalar sólo puede devolver un único valor para un único estado:

��p[m(q0,...,qk)->r1],�p[m(q0,...,qk)->r2] ∈ 0�� r1=r2 ∈ 0

� p[m(q0,...,qk)*->r1],�p[m(q0,...,qk)*->r2] ∈ 0�� r1=r2 ∈ 0

• Las expresiones de signatura cumplen las propiedades siguientes:

� � �� 1 Los tipos son heredados por todas las subclases.

� � � s::t, t[m(q0, ..., qk)≈>23r] ∈ 0�� s[m(q0, ..., qk)≈>r] ∈ 0

� �� 1�Si en un método se espera un argumento de la clase qi, cualquier objeto

perteneciente a una subclase q’i también es válido (polimorfismo de inclusión de programación

orientada a objetos).

� p[m(q0,...,qi,...,qk)≈>s],�q’i::qi ∈ 0 �� p[m(q0,...,q’i,..., qk)≈>s] ∈ 0

� �� 1�Si un método debe devolver un valor perteneciente a la clase r, también

puede devolver un valor perteneciente a una superclase s.

��p[m(q0,...,qk)≈>r], r::s ∈ 0�� p[m(q0,...,qk)≈>s] ∈ 0

• Las expresiones de datos deben cumplir las expresiones de signatura que hayan sido definidas en las

clases (los argumentos de la invocación del método pi deben ser instancias de qi y el valor devuelto r

debe ser instancia de la clase s):

� o[m(p0, ..., pk)-> r], c[m(q0, ..., qk)=> s], o:c ∈ 0�� ∀i pi:qi, r:s ∈ 0

� o[m(p0, ..., pk)->> r], c[m(q0, ..., qk)=>> s], o:c ∈ 0�� ∀i pi:qi, r:s ∈ 0

23 El símbolo ≈> denota cualquiera de los dos símbolos que permiten definir la signatura de los objetos: => o =>>.


�

43

• Los atributos heredables son propios en las instancias de las clases en las que están definidos:

� o:c, c[m(p0, ..., pk)*-> r] ∈ 0�� o[m(p0, ..., pk)-> r] ∈ 0

� o:c, c[m(p0, ..., pk)*->> r] ∈ 0�� o[m(p0, ..., pk)->> r] ∈ 0

• Los atributos heredables se heredan a través de las relación de subclase:

� s::t, t[m(p0, ..., pk)*-> r] ∈ 0�� s[m(p0, ..., pk)*-> r] ∈ 0

� s::t, t[m(p0, ..., pk)*->> r] ∈ 0�� s[m(p0, ..., pk)*->> r] ∈ 0

-�'��$ $��-��"��-��'��%��'��'��"��9��"�

Sea 0 una Estructura de Herbrand, entonces:

• Una molécula básica24, α, es cierta en 0 ( denotado por 0 |= α ) sii α ∈ 0�;

• Un literal negativo básico, ¬α, es cierto en 0 ( 0 |= ¬α ) sii α ∉ 0�;

• Una cláusula básica, β1 ∨ ... ∨ βn, es cierta en 0 ( 0 |= β1 ∨ ... ∨ βn ) sii ∃i, 0 |= βi ;

• Una cláusula básica, β1 ∧ ... ∧ βn, es cierta en 0 ( 0 |= β1 ∧ ... ∧ βn ) sii ∀i, 0 |= βi ;

• Una regla básica R, de la forma, α ← β1∧...∧βn, es cierta en 0 ( 0 |= R ) sii siempre que β1∧...∧βn

∈ 0 también α ∈ 0�;

• Una regla, R, es cierta en 0 sii todas las instanciaciones básicas de R son ciertas en 0.

Si todas las fórmulas de un conjunto S, son ciertas en 0, se dice que 0 es un ��"��"��9��" de S.

#�%�� 2��.��/��

La �� es un formalismo lógico que permite realizar manipulaciones declarativas sobre el estado de una

base de datos orientada a objetos, representada por hechos y reglas en F-logic.

24 Asignaciones de valores constantes a las variables.


�

�

44

#�%�$�� +��

Para representar el estado se hace uso de las F-fórmulas que se han definido en el punto 2.1.

Para representar la base de transacciones, además de las �� de F-logic, se define un

nuevo tipo de fórmulas atómicas llamadas ��"��"�� que tiene la forma:

�X "��y� �X "� ��

donde X es una F-regla.

Para construir �� además de las conectivas clásicas se hace uso de la ��)��

��'�� 25.

#�%�%�� &��

Las transiciones de estado elementales son un conjunto de operaciones que nos permiten manipular

cualquier aspecto del estado a través de las acciones de inserción (ins) y borrado (del). Algunos ejemplos

son:

=�%��@��"�"�N?��F�>��

=�.��@��"��?��F�>�"��

=��'��7��>�"��

=��77��>��

La conjunción secuencial permite decir que después de una ��-� se ejecuta otra. Una acción es una

consulta (por ejemplo, la evaluación de un método en un objeto) o una transición de estado elemental. Por

ejemplo, la siguiente proposición expresa que primero hay que ejecutar =� �'�@�"�"�?8EF� >�� y en el

estado alcanzado ejecutar =��@��"��?��F>�"��:

25 � ��

26 Inserta en el estado una f-molécula que describe parte de la signatura de la clase personas.

27 Elimina del estado la f-molécula que expresa que el objeto .�� tiene en su atributo estado el valor ��.


�

45

=�'�@�"�"�?8EF>��=��@��"��?��F>�"��

Se llama ��-� a una regla con una F-fórmula atómica en cabeza y con un cuerpo en el que se usa la

conjunción secuencial como conectiva. Por ejemplo, se puede definir la transacción que cambia el estado

civil de una persona de la siguiente manera:

�6@��=�8>�F�O��

�67%��87%��

=�6@��"��?��C�%��.��?��F>�"��

=�6@��"��?��"�C��%��.��?�8F�>��

que se leería como sigue: un objeto �6 puede casarse con un objeto �8 si los dos son personas, de forma

que el estado del objeto �6 pasa de ser �� a ser ��"� y la pareja que antes era nadie, pasa a ser el

objeto �8.

Una importante característica de la �� es la uniformidad de representación de las consultas y las

actualizaciones al no existir diferencia notacional entre realizar una consulta de un método y ejecutar una

transacción:

K��6@��?P��F� � � Q��'��"��'��(��"��

K��'�@��=��>F� � � � Q��.��'��-��"��'��-��

#�%�#�� +��,��-��

La �� está parametrizada por el ��+�'�� "�� "�� y el ��+�'�� "�� . La

finalidad del oráculo de datos consiste en responder a preguntas como: “R�� -��'��'��

��"��"�"�K”. El oráculo de transiciones responde a cuestiones como: “R$��%'�"��%��"��'��"��

��'��"��'��-��"��"��K”.

Formalmente, cada oráculo es una función. El oráculo de datos, θd, es una función definida sobre estados

que devuelve conjuntos de fórmulas ciertas. De manera similar, el oráculo de transiciones, θt, es una

función entre pares de estados que devuelve conjuntos de operaciones atómicas.

Intuitivamente, que α ∈ θd(D), quiere decir que la fórmula α es cierta en el estado D. De forma similar

que β ∈ θt(D1, D2) quiere decir que la fórmula β es una transición elemental que cambia el estado D1 al

estado D2.


�

�

46

En ��, el oráculo de datos determina qué F-fórmulas son ciertas dado un estado definido por hechos y

reglas de F-logic, y el oráculo de transiciones determina cuáles son las transiciones de estado elemental

(inserción y borrado de reglas F-logic) y cómo modifican el estado cuando son aplicadas a algún estado.

Así:

�X�"��θt �D, D’"��D’ = D�3�4�X�5�

� � � �X�"� ��θt D, D’"��D’ = D��4�X�5

La semántica formal de �� está basada en estados y �� "�� .��'��-� (un camino de longitud k

sobre un lenguaje � es una secuencia finita de estados, <D1, ..., Dk>, con k≥1). Cuando se ejecuta una

transacción, la base de datos puede cambiar, pasando por algunos estados intermedios hasta alcanzar el

estado final. En ��, el éxito de una ejecución se define sobre los caminos, no sobre los estados. Por

ejemplo, (a).ins sc (b).ins no es los mismo que, (b).ins sc (a).ins, ya que los

caminos de ejecución < D28, D3{a}, D3{a,b} > y < D, D3{b}, D3{a,b} > son distintos. La estructura

de caminos distingue entre un estado D y un camino <D> de longitud 1. El estado D representa las

fórmulas almacenadas en la base de datos, mientras que el camino <D> representa las fórmulas obtenidas

tras la combinación de la base de datos y la base de transacciones.

En general, si el camino tiene longitud 1, entonces la transacción es una consulta; si el camino tiene

longitud 2, entonces la transacción es una transición de estado elemental y si el camino tiene una longitud

superior a 2, entonces es una transacción compuesta

-�'��% ��'��'��"��="��9��">

Una Estructura de Caminos, �, es una función que asigna una Estructura de Herbrand a cualquier camino.

La función está limitada por las siguientes restricciones:

1. ��"��+�'��"��"��: Para cualquier estado D y cualquier fórmula φ ∈ θd(D),

�(<D>) |=F φ, donde ‘|=F’ denota el concepto de satisfacción visto en la definición 1. Esto quiere

28 D representa el estado anterior a la ejecución de la transacción.


�

47

decir que la estructura semántica asignada al camino <D> debe ser modelo de las fórmulas que el

oráculo de datos dice que son ciertas en D.

2. ��"�� +�'�� "�� : Para cualquier par de estados D1, D2, �(<D1,

D2>) |=F φ donde φ�∈ θt(D1, D2). En otras palabras, las transiciones especificadas por el oráculo

de transiciones son las verdaderas transiciones en la estructura de caminos.

La estructura de caminos, �, determina qué átomos son ciertos en qué caminos. Estos átomos denotan

acciones que ocurren a lo largo de los caminos. Como veremos, estas acciones pueden estar total o

parcialmente especificadas por fórmulas lógicas. Por ejemplo, la fórmula α ← φ sc ϕ expresa que la

acción α ocurrirá siempre que la acción φ se ejecute antes que la acción ϕ. En un contexto de

programación lógica el átomo α se puede ver como el nombre de la acción compleja φ sc ϕ. Esta

interpretación proporciona la capacidad para definir subrutinas en ��.

La verdad o falsedad de una fórmula transaccional se evalúa sobre estructuras de caminos de la siguiente

forma:

-�'��# $��-��

Sea � una estructura de caminos, sea π un camino arbitrario, y sea ) una asignación de valores del

dominio � sobre variables. Entonces:

1. �, π |=Y α sii �(π)� |= Y

F α, para cualquier fórmula atómica α, donde ‘|=Y

F ’ denota el concepto de

satisfacción de la definición 1.

8�� M*�π�SNv�¬φ ��&'��M*�π�SNv�φ��

:�� M*�π�SNv�=φ�∧ϕ>��M*�π�SNv�φ��M*�π�SNv�ϕ��

D�� M*�π�SNv�=φ��ϕ>��M*�π��SNv�φ��M*�π��SNv�ϕ�%��"��π��π��'��-��π��

;�� M*�π�SNv�=∀L>φ��M*�π�SNµ�φ�%��"��-��"��)��µ��"��v��2��%��L��

Si �, π |=Y φ, diremos que φ se satisface (o es cierto) en el camino π en la estructura de caminos � bajo la

sustitución ).

29 Un camino π es una concatenación de caminos <D1, ..., Dn> y <Dj, ..., Dm> sii Dn = Dj y π = <D1, ..., Dj, ..., Dm>.


�

�

48

� es modelo de una ��fórmula φ� �(� |= φ�) sii �, π |= φ para cualquier camino π. Una estructura de

caminos, �, es modelo de un conjunto de fórmulas si y sólo si es modelo de cada una de las fórmulas del

conjunto.

#�%�6�� 7��/��&��

Sea P un conjunto de transacciones, φ una fórmula transaccional, y D0, D1, ..., Dn una secuencia de estados

de la base de datos. Entonces, la sentencia:

P, D0, D1, ..., Dn |= φ�

es cierta sii �*�<D0, D1, ..., Dn> |= φ para cualquier modelo �, de P.

Relacionada con la sentencia anterior está la sentencia:

P, D0 --- |= φ

que es cierta sii existe una secuencia de estados D0, D1, ..., Dn para los que la primera sentencia es cierta.

La importancia de la última sentencia estriba en que ni el usuario ni el sistema conocen de antemano

cuáles van a ser los estados por los que va a pasar la base de datos en la ejecución de la fórmula φ. Sólo se

conoce P (el conjunto de transacciones) y D0 (el estado inicial). Los siguientes estados D1, ..., Dn, son

generados como parte de la ejecución de la transacción φ. Esto es precisamente lo que se muestra en la

teoría de la demostración en [BK95].

Para cualquier conjunto de transacciones P y cualquier secuencia de estados D0, D1, ..., Dn y cualesquiera

fórmulas transaccionales α y β, las siguientes sentencias son propiedades de la consecuencia lógica

ejecucional:

• � P, D0, ..., Di |= α 8 P, Di, ..., Dn |= β �� P, D0, ..., Dn |= α sc β.

• � α ← β ∈ P 8 P, D0, ..., Dn |= β ��P, D0, ..., Dn |= α.

• � α ∈ θt(D1, D2) �� P, D1, D2 |= α.

• � α ∈ θd(D0) ��P, D0 |= α.


�

49

#�#�� *��

Se han presentado en este capítulo las bases del formalismo lógico �� que se

utilizará en el capítulo siguiente para soportar el concepto de metaclase OASIS. Se puede ver que la

diferencia entre el modelo OO de la �� y el modelo OO de OASIS es mucho menor que la existente

entre otros formalismos y OASIS.

Además, la �� es un formalismo interesante para tratar los problemas relacionados con la evolución del

esquema ya que permite describir los datos (objetos) y los metadatos (clases) y manipularlos con el mismo

lenguaje de forma declarativa ejecutando transacciones.

Como parte del trabajo realizado se construyó un intérprete de dicha lógica que se puede consultar en el

informe técnico [Car97a] y se presentó en [Car97b] y [Car98a]. Dicho intérprete ha sido usado con éxito

en la implementación que se presenta en el capítulo 5, del prototipo de la herramienta que soporta la

evolución de los sistemas de información haciendo uso de la metaclase OASIS.

�

6�� .��9�� :;+0+��

��

)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�

53

En el capítulo 2 se ha presentado la metaclase como una codificación en OASIS del propio modelo

OASIS que proporciona servicios que permiten definir y/o modificar los esquemas conceptuales de

sistemas de información. Para actualizar un sistema sólo será necesario disparar el servicio adecuado en el

metaobjeto del esquema conceptual que defina la plantilla de la clase que se desee hacer evolucionar. La

semántica asociada a los cambios se especifica mediante reglas (precondiciones, evaluaciones,

restricciones de integridad, etc.) en el tipo de la metaclase. Las diferentes taxonomías de evolución surgen

de la propia definición de los eventos que permiten especificar y/o modificar los esquemas y su semántica

asociada. Los diferentes invariantes clásicos asociados a la evolución de los esquemas que han sido

propuestos en la literatura (ver capítulo 1) se captan en la definición de la metaclase, bien como

precondiciones de determinados eventos, bien como restricciones de integridad sobre los atributos de los

metaobjetos.

En este capítulo se presenta la definición de la metaclase OASIS haciendo uso del formalismo lógico ��.

La idea básica consiste en crear un objeto (resp. clase) �� por cada objeto (resp. clase) OASIS. La base

de objetos contendrá el estado de todos los objetos que se definan (metaclase y metaobjetos incluidos) y la

base de transacciones contendrá la implementación de los cambios de estado. Al así hacerlo, cualquier

detalle de la definición de un esquema es susceptible de ser manipulado sin más que ejecutar la

transacción que implementa el comportamiento del servicio en el objeto que se desee modificar. Trabajos

iniciales de traducción de especificaciones OASIS a �� se pueden encontrar en [Car96a, Car96b y

Che99].

6�$�� 7��

A la hora de definir la semántica de las operaciones de evolución existen varias alternativas dependiendo

del punto de vista adoptado.

!��

Existen aproximaciones al modelado de sistemas [Dia97] que dividen los sistemas en dos partes

claramente diferenciadas: una parte fija o �� que se supone no cambia nunca, y una variable o )��+��

que es posible modificar conforme cambie la política que rige el comportamiento del sistema (las ��

"��). Es una decisión del diseñador el establecer las partes que no cambiarán y aquéllas que sí

pueden hacerlo en un futuro. Se necesita mucha experiencia por parte del diseñador, para poder distinguir

��%�� qué parte de los sistemas se va a mantener inmutable y cuál va a cambiar, ya que no es posible

predecir totalmente necesidades futuras que no existen en el momento de definición del sistema.


�

�

54

" ��

Definir sistemas es una tarea complicada en la que se deben establecer numerosas relaciones entre los

componentes de los mismos. La modificación de un componente posiblemente afecte a otros con los que

está relacionado, pudiendo incurrir en inconsistencias30. A la hora de especificar la semántica de las

operaciones de modificación del esquema es necesario que éstas dejen al mismo en estados consistentes.

Para ello se pueden tomar tres aproximaciones:

1. no permitir las operaciones que dejen al esquema en estados inconsistentes,

2. permitirlas y eliminar toda posible inconsistencia,

3. una mixta, en la que se permita realizar las operaciones de modificación, arreglando las

inconsistencias directas que se puedan generar, pero no se permitan aquéllas en las que el coste de la

recuperación de la consistencia se escape de lo que se espera de la operación de modificación (por

ejemplo, eliminación de información de otras clases con las que esté relacionada la clase que sufre el

cambio).

Por ejemplo, imaginemos un posible escenario de evolución en el que en un sistema existe definida una

relación de herencia entre las clases A y B, en la clase A está definido un atributo ai que en la clase B (que

lo hereda) se utiliza para definir la precondición de un evento ej y que las clases A y B tienen población

no vacía. Supongamos que se pretende eliminar el atributo ai:

• Con la primera aproximación, no se permitiría el borrado del atributo porque la clase A está poblada

y habría que eliminar dicha información de las instancias, y además se utiliza en la clase B para

definir una característica.

• Con la segunda aproximación, hay que borrar el atributo ai de la clase A, eliminar dicha información

de las instancias pertenecientes a la población de la clase A y eliminar la precondición del evento ej

en la clase B (porque ya no existe el atributo).

30 Realmente, este es el principal problema de la evolución de los sistemas.


�

55

• Con la tercera aproximación, se eliminaría el atributo ai de la clase A y se eliminaría dicha

información de las instancias de la clase A, pero no se permite la eliminación porque dejaría al

esquema en un estado inconsistente (la clase B utiliza el atributo para definir una característica local).

• Con la tercera aproximación existe otra posible solución: eliminar el atributo ai de la clase A,

definirlo en la clase B y eliminar la información del atributo ai de las instancias de la clase A pero no

de las instancias de la clase B.31

A lo largo del presente trabajo se han asumido las siguientes premisas:

• !�� Cualquier aspecto que se utilice para modelar un sistema es susceptible de ser

modificado: nombre, eventos, tipo de clase, etc. De esta manera la herramienta será lo más versátil

posible.

• " ��Las operaciones de modificación del esquema realizan aquello que se espera de ellas,

pero si cabe la posibilidad de dejar el esquema en algún estado inconsistente son descartadas

siguiendo una estrategia mixta tal y como se ha comentado. Será responsabilidad del usuario eliminar

las posibles inconsistencias que se podrían dar, antes de realizar la operación de modificación del

esquema.

Por ejemplo, cuando se intente borrar un atributo, no se permitirá si éste es usado en alguna

precondición. En cambio, sí se permitirá añadir un evento (con sus precondiciones, evaluaciones,

etc.) aunque según el %�� no esté incluido en el conjunto de vidas válidas de las instancias de la

clase (se considera pues, un mal diseño del sistema de información). Para corregir el error, el

diseñador puede animar la especificación, comprobar si se puede o no servir dicho evento y corregir

la especificación del sistema.32

31 Cuantas más alternativas se ofrezca al diseñador para realizar las operaciones de modificación del esquema más

cómoda y flexible será la herramienta.

32 Adicionalmente, se podrían diseñar atributos derivados para los metaobjetos que validarán las expresiones del

párrafo %�� teniendo en cuenta lo comentado.


�

�

56

6�%�� 2��;�� -��

Para llevar a cabo la tarea de descripción formal de la metaclase, se hace necesario el uso de determinados

TAD33 que permitirán expresar con corrección determinados valores o expresiones. La �� no soporta la

definición de TAD (sólo soporta la definición de objetos) por lo que se ha realizado una implementación

�"�0��. Todo dominio que se defina será instancia de la metaclase primitive_class, de manera abreviada

p_c (ver definición en 4.3.7.6). Un elemento de un TAD será un objeto cuyo oid representa su valor, y las

funciones definidas sobre el TAD se codifican como relaciones cuyos argumentos serán los oid de los

objetos sobre los que aplicar la función más el argumento que proporciona el resultado de la misma.

Por ejemplo, el TAD de las listas se puede construir de la siguiente forma:

Q�5��-��"��(��'��%��

��=L>�7�%��←�L�7�%��

Q��'��

��7��=L>��

��=��*��>�7��=L>�←��7��=L>�M��7�L��

Q�3%��-��%��'��T��"��"��'��

��=L>@��'��??��'��=��*�P�>�F��

��=L>@��'��??�=�'��=��*�E�>*��'�>�F��

��=L>@��'��??�=�'��=��=�*��>*P>*��"=�'��=��*��>*�'�=�*�6*�P>�>F��

��

Con la primera fórmula se expresa que list(X) es un nuevo tipo de datos, la segunda y tercera fórmulas

definen los constructores de la lista, la cuarta fórmula expresa que hay definida una función que se llama

numElementos y la quinta y sexta fórmula definen la función que calcula el número de elementos de una

lista (más adelante se define el TAD formula que permite expresar cómo se realizan los cálculos).

33 También llamados dominios.

34 Las funciones se definen en el atributo functions del metaobjeto que representan al TAD en el que se define la

función.

35 Las fórmulas que definen las funciones se describen en el atributo formulas del metaobjeto que representan el

TAD en el que se define la función.


�

57

Con el TAD anterior, el objeto �� cuyo oid es concat( concat( nil, 9 ), 7 ) es del tipo list( integer ) y,

como facilidad sintáctica, lo trataremos como el valor [ 7, 9 ] (una lista formada por dos enteros).

En lo sucesivo, supondremos predefinidos los TAD básicos (enteros, naturales, string, boolean) y la lista

con sus constantes y operaciones definidas (ver [Car97]), y haciendo uso de ellos se construirán los TAD

estructurados que se necesiten para representar OASIS. Llamamos átomo (atom) a cualquier secuencia

alfanumérica que empiece por una letra minúscula. Una variable (var) es cualquier secuencia

alfanumérica que empiece por una letra mayúscula o el carácter ‘_’.

6�%�$�� 0 ��'�� :��

En �� un identificador de objeto es cualquier término construido a partir de símbolos de función y

constantes (ver página 37). Como se desea representar diferentes esquemas conceptuales en la misma

teoría � se divide el espacio de identificadores de forma que el oid de un objeto o metaobjeto será un par

de la forma:

��"�7�%��

�=��$�0�4�*�3�.��>��"��

donde Object es un átomo que identifica a un objeto que puebla la instancia del esquema conceptual cuyo

identificador es ConScheIns. Además, se definen dos oid especiales:

��7��"��

%��7��"��

Al igual que los identificadores de los objetos, los identificadores de las clases o metaclases están

formados por un par cuyo primer elemento es el identificador de la instancia del esquema en el cual está la

clase y el segundo elemento es un átomo.

��"�7�%��

�=��$�0�4�*��>�7��"�

6�%�%�� ;��

Un atributo constante se define mediante un nombre y un tipo; un atributo variable mediante un nombre,

un tipo y un valor por defecto; finalmente, un atributo derivado queda definido por un nombre, un tipo y

una función de derivación que calcula el valor del atributo en función de los valores de los demás


�

�

58

atributos. Ya que �� permite el uso de atributos multi-evaluados36, será posible definir atributos

variables cuyo codominio sea un conjunto. En �� los constructores de los atributos constantes (aC),

variables escalares (aV) y multi-evaluados (aVs) y derivados (aD) se definen de la siguiente manera:

��7�%��

��=�P��*� �%��>�7��←��=P��>�M� �%��7�%��

)��7�%��

��=�P��*� �%�*�5��>�7�)��←��=P��>�M� �%�7%��M�5��7� �%��

��=�P��*� �%�*�� >�7�)��←��=P��>�M� �%�7%��

��=�P��*� �%��>�7�)��←��=P��>�M� �%�7%��

��=�P��*� �%�*�5��>�7�)��←��=P��>�M� �%�7%��M�5��7��= �%�>��

"��7�%��

�5=�P��*� �%�*�5��>�7�"��←��=P��>�M� �%��7�%��M�5��7��'��

6�%�#�� ;�� '��

OASIS ofrece mecanismos para identificar a los objetos en el espacio del problema (alias) haciendo uso

de los atributos constantes definidos en las clases. Para representar los alias se utiliza el TAD alias.

��7�%��

��=��P��*��>�7��←��=��P��>�M��7��=��>��

El servicio que define alias en una clase comprueba que cada uno de los átomos que forman la lista

ConsAttList sea el nombre de un atributo constante definido en la clase.

36 También llamados, evaluados a conjunto.

37 Con este átomo se indica que el valor inicial del atributo variable se debe pasar como parámetro en el instante de

creación del objeto.

38 Se utiliza una lista para representar el valor inicial del atributo evaluado a conjunto.

39 Esta fórmula debe describir cómo se calcula el valor del atributo derivado asignándole valor a una variable que se

llame como el atributo.


�

59

Para poder identificar a los objetos (normalmente en los disparos que se definan) se utiliza el TAD

identifier que hace uso de los alias que se definan en las clases para identificar a sus instancias.

�"��7�%��

�"=��*��P��*��>�7��"��←��7��M��=��P��>�M��

��7��=��>��

Finalmente, para identificar a las clases dentro de un esquema conceptual se utilizan los siguientes

identificadores:

��=��>�7��"��←��7��

Se define el TAD ident para identificar a los objetos de una clase dada a través de los alias que se hayan

definido (este TAD se utilizará en la definición del atributo de una clase o de un esquema que a partir de

los valores proporcionados en ConsAttList devuelve el oid del objeto).

�"��7�%��

�"=��P��*��>�7��"��←��=��P��>�M��7��=��>��

6�%�6�� .��

Para poder almacenar las fórmulas que caracterizan los estados de los objetos se define el TAD formula.

Las fórmulas son conjunciones o disyunciones en notación prefija de consultas de valores de atributos,

comparaciones relacionales, operaciones definidas, true y false.

Una fórmula se representa en �� como un objeto de la clase formula cuyo oid coincidirá con la

expresión de la fórmula a evaluar. La definición recursiva en �� de los objetos formula es la siguiente:

��'��7�%��

��"�=��6*��8>�7��'��←��6�7��'��M��87��'��

��=��6*��8>�7��'��←��67��'��M��87��'��

��=��>�7��'��←��7��'��

��'�7��'��

40 Cada uno de los valores debe ser del tipo del atributo constante que forma parte del alias. Esto se comprueba en los

servicios que introducen los identificadores en la especificación de los sistemas.


�

�

60

��7��'��

��=P��*��'�>7��'�� Q��'��"��'��'��

��=P��*��'�>7��'��

��7��'��←��7� �M� �7�%�� Q��'��

�'��7��'��←�� 7�%��M� @��'��??��'��F�Q��'��

��3%�7��'��←�� 7�%��M� @��3%��??��3%�F�� Q�3%��"��

Una fórmula siempre se evalúa sobre el estado de un objeto. Esto se consigue mediante el predicado

(evalF), cuyos argumentos representan, por este orden, el objeto que proporciona el contexto42 para la

evaluación y la fórmula a evaluar.

�)��=�3*��"=�*��>�>�←��)��=�3*��>�M��)��=�3*��>��

�)��=�3*��=�*��>�>�←�=��)��=�3*��>��)��=�3*��>�>��

�)��=�3*��=��>�>�←��=��)��=�3*��>�>��

�)��=��*��'�>��

�)��=��*��>�←��

�)��=�3*��=��*��'�>�>�←�3@��?��'��F��

�)��=�3*��=��*��'�>�←�3@��??��'��F��

�)��=�3*��'��>�←� @��'��??��=��'��*��*��'��>�F�M��)��=3*��>�M��

� � � ��)��=3*��'��>��

�)��=�3*��3%�>�←� @��3%5��??��%=��3%*��3%5��>�F��M��)��=3*��3%5��>��

Como ya se ha comentado, se suponen predefinidos los TAD básicos integer, nat, string y boolean con

sus operadores relacionales y funciones.

Para representar, por ejemplo, la evaluación en un objeto O de una restricción de integridad en la que el

código de un socio debe tener un valor comprendido entre 100 y 1000 se utiliza la siguiente expresión.

41 Los operadores relacionales se definen en el atributo relOp del metaobjeto que representan al TAD en el que se

define el operador relacional.

42 Conjunto de F-moléculas cuyo de la forma p[ ... ] cuyo identificador (p) es el identificador de un objeto OASIS.

43 La evaluación de los operadores relacionales se define en el atributo relOpDef de los metaobjetos que representan

el TAD en el que se define el operador relacional.


�

61

�)��=�3*��"=��=��"��*��>*��"=��=��*�6EE>*��=�*�6EEE>�>�>�>�

La expresión anterior, utilizando notación infija y sustituyendo las funciones por las predefinidas en ��,

el símbolo ��" por el más común M y utilizando como contexto el objeto O, quedaría de la siguiente

forma:

3@��"��?��F�M��?6EE��M��O6EEE

Cuando se define una agregación entre una clase compuesta y una componente, desde los objetos

compuestos se puede acceder al estado de los objetos componentes. Si la agregación es relacional,

además, se puede acceder al estado de los objetos compuestos44 desde los objetos componentes

(visibilidad bidireccional). Para poder expresar en las fórmulas el acceso a los atributos de los

componentes o de los compuestos se amplían los términos del TAD formula con �2%�� "��

��45.

%��0=��P��*��=P��*��'�>�>�7��

%��0=��P��*��=P��*��'�>�>�7��

La evaluación de las expresiones de camino en un objeto compuesto se resuelve con la siguiente regla en

��.

�)��=�3*�%��0=��P��*��>�>�←�3@��%��??��%=��P��*�3�.��>�F�M� �

� � � � � ��)��=�3�.��*��>��

Como se puede observar en la regla anterior, cuando se quiera consultar desde un objeto compuesto O el

valor que tiene uno de sus componentes a través de la relación RelName en su atributo Att habrá que

localizar el objeto Object con el que está relacionado el objeto O a través del atributo component, que

tienen todas las instancias de las agregaciones (ver definición de la agregación en 4.3.7.5) para evaluar en

el objeto componente el valor del atributo.

44 En las agregaciones relacionales no tiene sentido el hablar de objetos compuestos y objetos componentes porque

no existe dicha relación de composición. Pero como en las especificaciones OASIS la relación siempre se define en

uno de los dos lados de la relación, llamamos clase compuesta a aquella en la que se define la relación y componente

a la clase del otro extremo de la relación.

45 Del inglés ‘%��0��2%��’.


�

�

62

De manera similar, cuando se quiera consultar desde un objeto componente O el valor que tiene uno de

los objetos compuestos por la relación RelName en su atributo Att habrá que localizar el objeto Object

con el cual está relacionado el objeto O a través del atributo partOf (que tienen todas las instancias de

clases componentes de agregaciones relacionales) para evaluar en el objeto compuesto el valor del

atributo.

�)��=�3*�%��0=��P��*��>�>�←�3@�%��3��??��=��P��*�3�.��>F�M��)��=�3�.��*��>��

6�%�<�� ;��

La forma en que la ocurrencia de los eventos afecta al estado de los objetos se especifica a través de

transacciones haciendo uso de un subconjunto de las transiciones de estado elemental que proporciona la

��. La única forma de modificar un atributo será:

• si el atributo es escalar, mediante el reemplazamiento (la eliminación y posterior inserción) de la F-

fórmula atómica que describe el valor de dicho atributo, o

• si el atributo es multi-evaluado, a través de la inserción y el borrado de valores en el mismo.

Cuando un evento provoque el cambio en más de un atributo, se han de concatenar las transiciones de

estado elemental. Para ello se utilizarán las conectivas secuenciales � y ", cuya semántica está definida a

través del oráculo de transiciones de la �� (ver sección 3.2.3).

A continuación se define el TAD serialAction en el que las acciones secuenciales son conjunciones o

disyunciones (secuenciales) de transiciones de estado elementales. Una acción secuencial en� �� será un

objeto de la clase serialAction, con un oid que coincidirá con la expresión de la acción secuencial a

ejecutar.

��7�%��

�=��*��>�7��←��7��M��7��

"=��*��>�7��←��7��M��7��

��%=��=�P��*�P�!��'��>�>�7��←��=P��>��

��=��=�P��*��'�>�>�7��←��=P��>��

"��=��=�P��*��'��>�>�7��←��=P��>��

��7��←��7��'��


�

63

Las acciones secuenciales se ejecutan siempre sobre un objeto en un estado. Existe un conjunto de

transacciones ��, llamadas evalSA, cuyos argumentos son el objeto que proporciona el contexto para la

ejecución y la acción secuencial a ejecutar.

�)��$�=�3*��=��*��>�>�←��)��$�=�3*��>��)��$�=�3*��>��

�)��$�=�3*�"=��*��>�>�←�=��)��$�=�3*��>�"��)��$�=�3*��>�>��

�)��$�=�3*��%=��=��*��'��>�>�>�←�=�3@��?��F�>�"��=�3@��?��'��F�>��

�)��$�=�3*��=��=��*��'��>�>�>�←�=�3@��??��'��F�>��

�)��$�=�3*�"��=��=��*��'��>�>�>�←�=�3@��??��'��F�>�"��

�)��$�=�3*��>��←��)��=�3*��>��

Para representar, por ejemplo, una evaluación en la que el número de libros que tiene en préstamo el socio

S de una biblioteca se incremente en una unidad se utiliza la siguiente expresión.

�)��$�=$*��=��=�'��*�P>*��=�'�=P*�6*��>*��%=��=�'��*�>�>�>�>�>�

La expresión anterior en notación infija, sustituyendo las transiciones de estado elemental por las

definidas en �� y utilizando como contexto el objeto S, quedaría de la siguiente forma:

$@�'��?�PF��N�P�U�6��=$@�'��?��F�>�"��

=$@�'��?��F�>��

Podría parecer que las acciones secuenciales descritas son pobres para expresar las necesidades de

información a la hora de especificar SI. En OASIS se utiliza una categorización de los atributos que es

suficiente para expresar las necesidades de información de los sistemas [Pas95]. Es fácil demostrar que

con la transición secuencial de reemplazamiento se puede expresar cualquier cambio de estado inducido

por la categorización de atributos utilizada en OASIS.

6�%�=�� &��

Un evento queda definido por un nombre y una lista de argumentos; para definirlos se utiliza el TAD

event. El perfil, las precondiciones y las reglas de evaluación asociadas se expresan con los TAD

evType, evPre y evVal, respectivamente.

�)��7�%��


�

�

64

�)=�P��*��>�7��)��←��=�P��>�M��7��=�)��>��

�) �%��7�%��

�) =��)��*� �%��>�7��) �%��←��)��7��)��M� �%��7��=�%��>��

�)��7�%��

�)��=��)��*��>�7��)��←��)��7��)��M��7��'��

�)��7�%��

�)��=��)��*��>�7��)��←��)��7��)��M��7��

Para modelar un evento compartido se utiliza, además, el TAD shared que permite especificar las clases

con las que es compartido un evento.

0��"�7�%��

0=��)��*��>�7�0��"�←��)��7��)��M��7��=��>��

6�%�>�� 2��

Las transacciones están formadas por un nombre y una lista de argumentos; para expresarlas se utiliza el

TAD transaction. Para indicar los tipos de los argumentos de las transacciones se utiliza el TAD trType.

Cuando se invoca una transacción se ejecuta una serie de eventos de forma secuencial con un

comportamiento transaccional; para indicar la lista de eventos que forman parte de la transacción se utiliza

el TAD trVal.

��7�%��

��=�P��*��>�7��←��=�P��>�M��7��=�)��>��

�� %��7�%��

�� =� ��*� �%��>�7�� %��←� ��7��M� �%��7��=�%��>��

��7�%��

46 Cada uno de los argumentos que puede recibir un evento se representa a través de una variable, de forma que el

paso de información del mensaje al objeto se realiza vía unificación.


�

65

��=� ��*��"��>�7��←� ��7��M��"��7��$��

Para definir el cuerpo de las transacciones se utilizará el TAD tranSerialAction. Como se puede ver en la

definición, una transacción es la conjunción o disyunción secuencial de eventos o fórmulas sobre el estado

del objeto servidor de la transacción:

��$��7�%��

�=��*��>�7��$��←��7��$��M��7��$��

"=��*��>�7��$��←��7��$��M��7��$��

��7��$��←��7��)��

��7��$��←��7��'��

La semántica asociada a las tranSerialAction se reifica en la conjunción y disyunción secuenciales de la

��, la consulta del valor de atributos y la invocación de eventos.

�)�� $�=�3*��=��*��>�>�←��)�� $�=�3*��>��)�� $�=�3*��>�� Q��.'��-��

�)�� $�=�3*�"=��*��>�>�←�=��)�� $�=�3*��>�"��)�� $�=�3*��>�>�� Q�5��'��-��

�)�� $�=�3*��)��>�←�3@��)��F�� Q��)��

�)�� $�=�3*��>�←��)��=�3*��>�� Q��-��'��

Cuando se define una agregación, desde los objetos compuestos se pueden invocar eventos de los objetos

componentes en el cuerpo de las transacciones. Además, cuando se define una agregación relacional,

desde los objetos componentes se pueden invocar eventos de los objetos compuestos. Para poder expresar

en las transacciones la invocación de eventos en los componentes o en los compuestos se amplía la

definición del TAD tranSerialAction con expresiones de camino.

%��0=��P��*��)��>�7��$��←��)��7��)��

La resolución de las expresiones de camino para los eventos en el cuerpo de las transacciones de los

objetos compuestos se resuelve a través de la siguiente transacción ��:

�)�� $�=�3*�%��0=��P��*��)��>�>�←�3@��%��??��%=��P��*�3�.��>�F��

� � � � � � ��)�� $�=�3�.��*��)��>��

47 En la página 6 se puede ver la reificación de los eventos en ��.


�

�

66

Esto es, cuando se ejecute sobre un objeto O una transacción en cuyo cuerpo aparezca una expresión de

camino invocando un evento Event en uno de sus componentes, relacionado a través de RelName, habrá

que invocar el evento sobre el objeto Object con el cual está relacionado el objeto O.

De forma similar, la resolución de las expresiones de camino para los servicios en el cuerpo de las

transacciones en un objeto componente se resuelve a través de la siguiente transacción ��:

�)�� $�=�3*�%��0=��P��*��)��>�>�←�3@�%��3��??��=��P��*�3�.��>�F��

� � � � � � ��)�� $�=�3�.��*��)��>��

El significado de esta transacción es el mismo que en el caso anterior.

6�%�?�� +��

Los eventos y las transacciones son los servicios que ofrecen los objetos al resto de la sociedad; para

modelarlos se define el TAD service:

��)��7�%��

�)��7��)��←��)��7��)��

��7��)��←� ��7��

6�%�@�� *��

Con los disparos se introduce actividad a través de la llamada de eventos en la sociedad de objetos que se

describa. La sociedad tiene una actividad interna consistente en la detección de la satisfacción de la

condición de activación de los disparos definidos para activar automáticamente el correspondiente evento

en algún objeto de la sociedad.

Para representar las relaciones de disparo se utiliza el TAD trigger. Una acción (action) es la invocación

de un evento en un objeto (que puede ser él mismo).

��7�%��

��=��"��*��>�7��←��"��7��'��M��7��

��7�%��

��=� ��*�$��)��>�7��←� ��7��M�$��)��7��)��


�

67

��7�%��

��7�� Q��%��%��.��

3�.��7��←�3�.��7��"�� Q��.��

La semántica del comportamiento de los disparos se implementa en un monitor de disparos

(triggerMonitor) que se activa tras la ejecución de los eventos y que comprueba la satisfacción de las

condiciones de activación de los disparos para activarlos en caso afirmativo.

6�%�$A�� B��

Los procesos se construyen usando los eventos como acciones atómicas. Son términos del álgebra básica

de procesos que describen las posibles vidas de los objetos.

Para poder definir el proceso se utilizan unas constantes (state) que definen los diferentes estados en los

que se pueden encontrar los objetos. Existen dos constantes especiales que denotan el instante de creación

del objeto (al que sólo puede seguir el evento ��!) y la destrucción del objeto (que irá precedido del

evento "��). Con el TAD process se define la relación de alcanzabilidad entre estados.

%��7�%��

%�=�3�"$��*��)��P��*�P�!$��>�7�%��←�

3�"$��7��M��=�)��P��>�M�P�!$��7��

��!�7��

"��7��

P�7��←�P7��

La vida de un objeto puede representarse como una secuencia de eventos o traza. Para representar las

trazas se utiliza el TAD trace.

��7�%��

��=��)��>�7��←��)��7��=��)��>��

Se puede ampliar la expresividad de las relaciones de disparo para expresar comportamiento reactivo ante

la ocurrencia de un evento [Can98], ampliando el TAD formula con el predicado happens/1.

48 EventName debe ser el nombre de un evento definido en la clase.


�

�

68

0�%%��=��>�7��←��7��)��

�)��=�3*�0�%%��=��>�>�←�3@��?��)��F�M��=��*��)��>��

6�%�$$�� C��

Para conocer en todo momento las clases agentes que usan los servicios definidos por una clase, se define

el TAD agent.

��=�$��)��*��>�7��←�$��)��7��)��M��7��=��>��

Las superclases de especializaciones permanentes almacenan cuáles son sus subclases y la razón por la

cual sus instancias deben especializarse, haciendo uso del TAD permSubClass. Condition es la

condición de especialización que debe basarse en los atributos constantes definidos en la superclase.

%=�$'��*��"��>�7�%��$'��←�$'��7��M��"��7��'��

Las clases componentes de una agregación almacenan con qué clases AggName están relacionadas, cuál

es el nombre de la relación RelName y las características de la relación que hay definida entre ambas

usando el TAD aggregated.

�=�P��*��P��*��*$��*��)��'�"*5�.��*��2��*P'��>�7��"�←�

� � ��P��7��M��P��7��M��7��M�$��7��M��

� � ��)��'�"�7��M�5�.��7��M��2��7��M�P'��7��

Las clases compuestas de una agregación almacenan con qué clases CompName están relacionadas, cuál

es el nombre de la relación RelName y las características de la relación las liga usando el TAD

component.

��%=��%P��*��P��*��*$��*��)��'�"*5�.��*��2��*P'��>7��%��←�

� � ��%P��7��M��P��7��M��7��M�$��7��M��

� � ��)��'�"�7��M�5�.��7��M��2��7��M�P'��7��


�

69

6�#�� *�� :;+0+��

En este punto se presenta la reificación de los conceptos OASIS en �� haciendo uso de los TAD que se

han presentado con anterioridad.

6�#�$�� :��:;+0+�

El estado de un objeto OASIS se reifica en una F-molécula, en la que los atributos constantes o variables

OASIS son expresiones de métodos escalares o multievaluados no heredables. Los atributos derivados

obtienen su valor a través de una formula evaluada sobre el estado del objeto.

Los cambios de estado fuertes se reifican en transacciones �� que implementan la semántica de la

creación o destrucción de instancias en función del tipo de la clase: clases elementales, agregaciones o

especializaciones temporales o permanentes.

La modificación o cambio de estado de un objeto por la ocurrencia de un evento se modela como la

ejecución de una transacción �� en la que las modificaciones que se pueden aplicar están restringidas al

conjunto de atributos que forman el estado del objeto en el que se ejecuta la transacción. Para expresar los

cambios de estado débiles se utiliza el TAD serialAction.

La precondición de un evento se modela como la evaluación de una formula cuya satisfacción precede a

la ejecución de la modificación de estado del evento.

Las restricciones de integridad se modelan como la evaluación de una formula que se debe satisfacer tras

la ejecución de la modificación del estado de un objeto.

Los disparos se modelan a través de la ejecución de la transacción �� equivalente al evento a disparar en

el caso de que se cumpla la condición de activación del disparo (una formula que se evalúa sobre el

estado de un objeto).

Todo objeto almacena su traza en un atributo especial llamado trace. El estado alcanzado tras el servicio

de los eventos de la traza se almacena en un atributo especial llamado state (el estado será el descrito por

el proceso). La semántica del modelo de ejecución es la encargada del mantenimiento de dichos atributos

(cada vez que se ejecute un evento se añade a la traza del objeto que lo ha servido y se actualiza el

estado).


�

�

70

6�#�%�� 7��:;+0+�

Como se vio en el capítulo 2 las clases OASIS están formadas por una plantilla, una factoría y un almacén

de los objetos que son instancias suyas, vamos a ver cómo representar dichos conceptos en ��.

Cada clase OASIS se reifica en una clase �� con un conjunto de expresiones de signatura y de métodos

escalares y multievaluados que describen la plantilla y el almacén, y un conjunto de transacciones que

representan los servicios que proporcionan las clases y que implementa el concepto de factoría.

• #�� El conjunto de fórmulas que definen la plantilla de una clase OASIS (atributos, alias,

eventos, precondiciones, restricciones de integridad, etc.) queda definida a través del valor que toman

unos atributos49. Expresiones de signatura �� denotan qué atributos tendrán sus instancias y el

dominio en el que tomarán valor dichos atributos.

• ��$�� La relación existente entre los objetos y sus clases se modela con la relación ��

de la �� que servirá para definir la población de la clase como el conjunto de objetos que la

satisfagan.

• ��%��El evento de creación de ejemplares de las clases se implementa como una transacción ��

que se encarga de:

1. Comprobar que se satisface la precondición del evento ��!

2. Dar un oid al nuevo objeto.

3. Crear el objeto asignando valores iniciales a los atributos.

4. Comprobar que se satisface la restricción de integridad.

5. Comprobar si se satisfacen las condiciones de activación de algún disparo y lanzarlo en caso

afirmativo.

El evento de destrucción de ejemplares de las clases se implementa como una transacción que:

1. Comprueba que el evento es un posible siguiente según la traza del objeto a destruir y la

definición del proceso.

2. Valida la precondición del evento "��.

49 Más adelante se verá que los atributos de las clases que describen la plantilla en realidad se obtienen a través de

una vista por proyección de los metaobjetos que definen la plantilla de las clases (ver 4.3.8).


�

71

3. Destruye el objeto.

Los diferentes tipos de clases que se pueden especificar en OASIS (clases primitivas, elementales,

compuestas o especializaciones) hace que la implementación de los servicios de factoría sea

dependiente del tipo de la clase. En el apéndice D se puede observar las diferentes transacciones que

dan soporte a los servicios de factoría.

6�#�#�� D��

Los metaobjetos se reifican en objetos �� con un conjunto de atributos que almacenan la plantilla de la

clase que representan. Dichos objetos ofrecen unos servicios (definidos en la metaclase de la que son

instancia) que son los encargados de modificar los atributos y al hacerlo modificar la plantilla de la clase

que definen y adecuar las instancias.

6�#�6�� D��

En función del tipo de clase que codifica con su estado, un metaobjeto será instancia de una metaclase

diferente. Las metaclases son las clases cuyas instancias son los metaobjetos que describen la plantilla de

alguna clase OASIS. Las metaclases se reifican como clases �� con un conjunto de atributos50 que

describen la plantilla y el almacén y un conjunto de transacciones que representan los servicios de factoría

de metaobjetos.

6�#�<�� &�(��7��

En �� un esquema conceptual se codifica como un objeto complejo formado por un conjunto de

metaobjetos que definen con su estado la plantilla de las clases OASIS que constituyen el modelo de un

sistema. Dicho objeto complejo tiene unos atributos que permiten definir la plantilla del esquema

conceptual y unos servicios que permiten crear instancias del esquema y destruirlas. Trabajar con un

esquema conceptual supone estar trabajando en tiempo de edición y se pueden invocar los servicios de

manipulación del esquema.

50 Al igual que las clases, las metaclases obtienen la plantilla a través de una vista por proyección de los metaobjetos

que definen la plantilla de las metaclases.


�

�

72

6�#�=�� 0�� &�(��7��

Al hacer uso del servicio de creación de instancias del esquema, se genera un objeto complejo51 que

contiene un conjunto de clases representando al sistema de información en su estado inicial (en el

apéndice D se puede ver en detalle la creación de una instancia de un esquema conceptual). Dichas clases

están formadas por: la plantilla definida en los metaobjetos del esquema (vista por proyección de los

atributos de los metaobjetos en la que no están disponibles los servicios de modificación), la factoría y el

almacén. Trabajar con una instancia de un esquema conceptual supone estar trabajando en tiempo de

ejecución y no se permite la modificación del esquema. A partir de un esquema conceptual se pueden

crear muchas instancias distintas, compartiendo todas ellas la misma definición de esquema.

6�#�>�� /��D��:;+0+�

La metaclase OASIS es el esquema conceptual que define la plantilla de las metaclases en el estado de

unos metaobjetos que son instancias de sí mismos, vistos como las metaclases que definen (definición

reflexiva).

En la Figura 14 se puede observar una representación gráfica de la metaclase OASIS. La metaclase

OASIS tiene un identificador (oasisMetaclass), ofrece los servicios de creación y destrucción de

esquemas (newInstance y destroyInstance) y está formada por diferentes metaclases que definen las

características de las clases primitivas (primitive_class), las clases elementales (elemental_class) y las

clases complejas: especializaciones temporales y permanentes (temporalSpecialization_class y

permanentSpecializacion_class respectivamente), agregaciones (aggregation_class).

Por simplificación, en ocasiones, se hará referencia a las metaclases por sus nombres abreviados, de

manera que, om es el sustituto de oasisMetaclass, e_c de elemental_class, ts_c de

temporalSpecialization_class, ps_c de permanentSpecialization_class y p_c de primitive_class.

Las instancias de las metaclases (e_c, ts_c, ..) serán los metaobjetos que definen con su estado la plantilla

de las clases que forman parte de un esquema.

51 Se puede asimilar la noción de instancia de un esquema conceptual a lo que comúnmente se denomina

base de datos o prototipo en ejecución del sistema.


�

73

��

newInstance

destroyInstance“elemental_class”

“permanentSpecialization_class”


“aggregation_class”


: is_a: is_instance_of

Figura 14: Representación de la jerarquía �� de metaclases y jerarquía �� entre los

metaobjetos que definen con su estado las metaclases en la metaclase OASIS.

Como se puede observar en la figura, las metaclases están relacionadas por especialización porque los

servicios definidos en la metaclase elemental_class que permiten definir la plantilla de las clases

elementales son usados para definir las agregaciones y especializaciones, redefiniendo el comportamiento

de los servicios cuando es necesario.

El metaobjeto elemental_class define con su estado la plantilla de la metaclase elemental_class, por

eso es instancia de sí misma. En cambio, las metaclases permanentSpecialization_class,

temporalSpecialization_class y aggregation_class son especializaciones temporales de la metaclase

elemental_class. Por lo tanto, los metaobjetos que definen la plantilla de dichas metaclases son

instancias de la metaclase que define las especializaciones temporales (temporalSpecialization_class).

&'(')'*'� ��

Ya hemos comentado que el identificador del esquema conceptual de la metaclase OASIS es om. Para

poder tener diferentes esquemas conceptuales en ��, se ha realizado una partición del espacio de los

identificadores. De manera que, siguiendo el patrón propuesto en 4.2.1, los identificadores de las

metaclases en la metaclase OASIS son:

�=��*��> para la metaclase ��*�

�=��*��> para la metaclase ��%��$%��1��*�

�=��*%��> para la metaclase %��$%��1��*�

�=��*��> para la metaclase ��*�


�

�

74

%�� para la metaclase %��)��.

Y los identificadores de los metaobjetos que con su estado definen la plantilla de las metaclases que

forman parte de la metaclase OASIS son los siguientes:

�=��*��> para el metaobjeto ��*�

�=��*��> para el metaobjeto ��%��$%��1��*�

�=��*%��> para el metaobjeto %��$%��1��*�

�=��*��> para el metaobjeto ��*�

%�� para el metaobjeto %��)��.

&'(')'+'� �� ,��

La metaclase elemental_class es la raíz de la jerarquía de especializaciones temporales de metaclases.

Define unos atributos que permiten describir todas las secciones de la especificación OASIS de una clase

elemental (atributos constantes, variables, derivados, eventos, precondiciones, etc.) como valores de

dichos atributos y unos servicios que permiten darles valor y modificarlos.

En las especificaciones OASIS, las clases elementales no juegan sólo el papel de clases independientes

que no tienen nada que ver con el resto de clases que forma parte de un sistema. Las clases elementales,

en determinados sistemas, pueden ser superclases (temporales y/o permanentes) y/o componentes de

algunas agregaciones. Por lo tanto, a la hora de especificar las propiedades y el comportamiento de las

clases elementales deberá tenerse en cuenta este hecho. En la Figura 15 se puede ver resaltada una clase

elemental en un sistema de información genérico que juega diversos papeles.

La clase C es una clase elemental y es superclase directa de C1, C2 y C3, y, además, es componente de las

agregaciones C6 y C7. Las propiedades definidas en C son heredadas por todas sus subclases y si estas

subclases son especializaciones temporales se puede redefinir el comportamiento heredado. Además, las

propiedades definidas en la clase C pueden ser utilizadas para determinar las propiedades y el

comportamiento de las agregaciones C6 y C7.

52 Por las razones que se exponen en la sección 4.3.7.6 el identificador de la metaclase primitive_class es simple.


�

75

CC1

C2 C3

C4 C5

C7

C6C8

Figura 15: Una clase elemental en un sistema de información genérico

&'(')'+'*'� #��

A continuación se muestra la plantilla �� de la metaclase elemental_class. En dicha plantilla se puede

observar qué atributos y dominios tendrán cada una de las instancias de esta metaclase. Por comodidad, en

determinados atributos (consAtt, shared, ...) se utiliza como codominio un conjunto para aprovechar las

características de la ��.

�=��*��>@��N?��F��

�=��*��>@��N??��F��

�=��*��>@�)��N??�)��F��

�=��*��>@�"��N??�"��F��

�=��*��>@��N??��F��

�=��*��>@��N?��'��F��

�=��*��>@��!�N??��)��F��

�=��*��>@�"��N?��)��F��

�=��*��>@��)��N??��)��F��

�=��*��>@��) �%��N??��) �%��F��

�=��*��>@��)��N??��)��F��

�=��*��>@��)��N??��)��F��

�=��*��>@�0��"�N??�0��"�F��

�=��*��>@��N??��F��


�

�

76

�=��*��>@�� %��N??�� %��F��

�=��*��>@��N??��F��

�=��*��>@��N??��F��

�=��*��>@�%��N??�%��F��

Figura 16: Parte de la plantilla ��de la metaclase ��

Normalmente, los estados válidos de un objeto se especifican a través de un conjunto de restricciones de

integridad. El conjunto de estados válidos que definen el conjunto de restricciones de integridad es el

mismo conjunto de estados que define la conjunción (��") de las restricciones. Se ha optado por definir

una única restricción de integridad por clase, por comodidad, pero sin pérdida de expresividad. En el caso

de que hubiera varias restricciones de integridad para una misma clase, la restricción resultante sería la

conjunción de las restricciones.

Cuando se define un disparo en una clase se establece una relación de agente entre la clase cliente (que

tendrá definido el disparo) y la clase servidora (que tiene definido el servicio). Dicha relación se mantiene

a través del atributo agent.

�=��*��>@��N??��F�

Como una clase elemental puede ser la superclase de otras clases en diferentes jerarquías de herencia,

tanto temporales como permanentes, las clases elementales deben conocer cuáles son sus subclases y la

relación existente entre la subclase y la superclase. Para ello los metaobjetos disponen de dos atributos:

tempSubClasses para conocer las subclases temporales y permSubClasses para conocer las subclases

permanentes y cuál es la condición de especialización.

�=��*��>@��%$'��N??��F�

�=��*��>@�%��$'��N??�%��$'��F�

Una clase elemental puede ser componente de una agregación, modificando su comportamiento en

función de las peculiaridades de la relación definida entre el objeto compuesto y el componente. Las

instancias de la metaclase elemental_class disponen de un atributo llamado partOf que almacena en qué

relaciones de agregación participan sus instancias y cuáles son las características de la relación.

�=��*��>@�%��3��N??��"�F��

En la definición de las clases existen propiedades que no están definidas localmente: por ejemplo, en los

eventos compartidos y en los disparos se hace referencia a servicios de otras clases o, para identificar al


�

77

objeto destino de un disparo se utilizan alias definidos en otras clases. Existen diversas operaciones de

modificación que no pueden realizarse sin conocer si otras clases están usando en su definición las

características que se quieren borrar y/o modificar. Para ello, cada metaobjeto tiene definidos unos

atributos derivados cuya función es la de revisar su estado interno y determinar si se está utilizando en su

definición propiedades de otras clases. Los atributos derivados son:

• '��=��P��*��P��>, que comprueba si en la definición de una clase se utiliza el alias

AliasName definido en la clase ClassName en los objetivos de los disparos,

• '�$��=� ��P��*� $��)�� >, que comprueba si en la definición de una clase se usa el servicio

Service de la clase ClassName en los eventos compartidos, en los disparos definidos o en el cuerpo

de las transacciones, y

• '��P��=��P��>, que comprueba si en la definición de una clase se utiliza el nombre de

clase ClassName en los destinos de los disparos y en los eventos compartidos.

La plantilla �� de los anteriores atributos derivados es la siguiente:

�=��*��>@�'��=��*��>�N?��F�

�=��*��>�@�'�$��=��*��)��>�N?��F�

�=��*��>�@�'��P��=��>�N?��F�

La población de un metaobjeto (extent) está formada por todas las instancias de las clases cuya plantilla

está definida en el metaobjeto. En determinadas circunstancias nos interesa saber qué objetos son

instancias de un metaobjeto y no de los metaobjetos con los que está relacionado a través de relaciones de

herencia y viceversa. Para ello existen los atributos directExtent e indirectExtent.

�=��*��>@��2��N??��"�F��

�=��*��>@�"��2��N??��"�F��

�=��*��>@��"��2��N??��"�F��

Como se ha dicho con anterioridad, todo objeto es instancia de alguna clase. Para no tener una jerarquía

potencialmente infinita de metaclases, se define la metaclase elemental_class como instancia de sí

misma y en el estado del metaobjeto o(om,e_c) está definida la plantilla de la metaclase

elemental_class. En �� declaramos que,

�=��*��>�7��=��*��>�

En el siguiente apartado se proporciona el estado del metaobjeto o(om,e_c).


�

�

78

La metaclase OASIS se ha definido haciendo uso de las características de la ��, dando en todo momento

la ilusión de ser clases OASIS definidas de forma reflexiva. Por ello, siguen las características dadas para

cualquier clase OASIS (existen unos objetos que con su estado definen la plantilla de la clase que

representan, tienen unos atributos variables y derivados, ofrecen servicios, ...) excepto en la definición del

comportamiento de los servicios que se han reificado como transacciones ��y no como evaluaciones

usando el TAD serialAction.

&'(')'+'+'� ��

A continuación se muestran los valores de los atributos más importantes del metaobjeto

elemental_class. Se puede observar la definición reflexiva de la metaclase que con su estado define su

plantilla y, por ejemplo, con su atributo varAtt define cuáles son los atributos variables que tiene dicho

metaobjeto, con su atributo event define los eventos, etc.

�=��*��>@��?�V��V�F�

�=��*��>@��??��=��*�@��F�>�F�

�=��*��>@�)��??�G�� =��*��*�� >*� � � �

� ��=��*��>*� � � � �

� ��=�)��*�)��>*� � � � �

� ��=��*��>*� � � � � �

� ��=��*��'��*��'��>*� � � �

� ��=��!*��)��*�@�)=��!*��>F�>*� � � �

� ��=�"��*��)��*��)=�"��*��>�>*� � �

� ��=��)��*��)��>*��

� ��=��)��*��)��*�@��)��=��)=��!*��>*��'��>*� � �

� � � ��)��=��)=�"��*��>*��'��>�F�>*� �

� ��=��)��*��)��*�@��)��=��)=��!*��>*��'�>�F�>*� � �

� ��=�0��"*�0��"�>*��

� ��=��*��>*� � � �

� ��=�� %�*�� %��>*��

� ��=��*��>*��

� ��=��*��>*��

� ��=�%��*�%��*�@�%�=��!*��!*�E>*�%�=E*�"��*�"��>�F�>*�

� ��=��%$'��*��>*� �


�

79

� ��=%��$'��*�%��$'��>*� � �

� ��=�%��3�*��">�H�F�

�=��*��>@��?��'��F�

�=��*��>@��!��??��)=��!��*��>�F�

�=��*��>@�"��?��)=�"��*��>�F�

�=��*��>@��)��??�G�� )=��""��*�@�P��*� �%��F�>*� � � �

� �)=��""��*�@�P��*� �%�*��F�>*� �

� �)=��""��*�@�P��*� �%�*��'��F�>*� � �

� �)=��""5��*�@�P��*� �%�*��'��F�>*��HH�F��

�=��*��>@��%$'��??G�#��%��$%��1��,*

� #%��$%��1��,*�#��,�H�F�

��

Todos los atributos son variables porque cualquier aspecto de la especificación de un sistema es

susceptible de ser modificado; si existiese algún atributo constante, éste no podría ser modificado durante

la vida del metaobjeto.

Las poblaciones, definidas como atributos en los metaobjetos, se calculan deductivamente a través de las

reglas siguientes:

�=�$*��>�@��2��??�3�F�←��5��7��$�M�3�7��=5�*��>��

�=�$*��>@�"��2��??�3�F�←�5��7��$�M�3�7��=5�*��>�M��

� � � � � ��=�3�7��=5�*��6>�M��WN�6�M��=5�*��6>�77��=5�*��>�>��

�=�$*��>@��"��2��??�3�F�←�5��7�$�M�3�7��=5�*��>�M� � � �

� � � � � 3�7��=5�*�6>�M��WN�6�M��=5�*�6>�77��=5�*�>��

Como se puede observar en la definición, se consideran instancias de los metaobjetos o(CS,C) todas las

instancias O de las clases c(DB,C) de las que el metaobjeto define la plantilla, en todas las instancias de

los esquemas conceptuales DB que se hayan creado a partir del esquema conceptual CS en el cual se ha

creado el metaobjeto (como se puede observar, las clases y los metaobjetos están relacionados a través de

C, ver 4.3.8).

53 En el apartado 4.3.7.2.3 se detallan todos los servicios junto con su semántica.


�

�

80

&'(')'+'('� - ��

A continuación se muestran todos los servicios que permiten definir la plantilla de las clases elementales

siguiendo el siguiente patrón:

a. Perfil del servicio: estado de los atributos event y evType en los que se describe el nombre del

servicio, los argumentos y sus tipos.

b. Condiciones necesarias para poder ser ejecutados (precondiciones)

c. Acciones de modificación del estado. En el conjunto de acciones que modifican el estado, se

consideran como parte del estado local del metaobjeto las instancias de las clases de las que el

metaobjeto define la plantilla y por lo tanto son modificadas de acuerdo a la semántica de la

operación de modificación.54

d. Comunicación con otros metaobjetos implicados en la modificación con un comportamiento

transaccional (si falla el servicio invocado en los metaobjetos relacionados, también fallará el

servicio invocado en el metaobjeto original).

Existen dos tipos de servicios definidos para los metaobjetos: �+�� y �'2��. Los servicios básicos

son aquellos que el usuario invoca para modificar la plantilla de una clase. Para mantener la consistencia

de la especificación, los servicios básicos se apoyan en los servicios auxiliares cuyos agentes son los

metaobjetos sobre los que el diseñador ha invocado un servicio de modificación y no el diseñador. La

definición de los servicios auxiliares se puede ver en el apéndice B.

54 Si el servicio de modificación se invoca sobre un metaobjeto MOi perteneciente a un esquema conceptual CSj que

tiene n instancias DB1, DB2, ..., DBn en las cuales el metaobjeto MOi define la plantilla de la clase Ci, se consideran

instancias del metaobjeto MOi todas las instancias de la clase Ci en todas las instancias del esquema DB1, DB2, ...,

DBn. (ver definición de extent para los metaobjetos)


�

81

&'(')'+'('*'� .� ��

El evento ��! que permite crear clases55 elementales se llama newClass y está definido en el atributo que

describe cuál es el evento ��! de la metaclase elemental_class.

�=��*��>@��!��??��)=��!��*��>��F�

Tal y como se puede ver en la reificación del servicio de creación de instancias en la Figura 34 (pág. 243),

se asume que los primeros argumentos de cualquier evento ��! son los valores que se dará a los atributos

constantes y variables que sean necesarios, en el instante de creación (en este caso sólo es necesario

proporcionar el nombre que se le va a dar a la clase).

El invariante de unicidad de nombres dice que debe ser único en un esquema; esto se comprueba como

precondición del servicio de creación de metaobjetos. Normalmente, la definición de alias se realiza sobre

los atributos constantes de la clase, pero como en el metanivel no existen atributos constantes, se permite

la definición de alias sobre el nombre de la clase a pesar de ser un atributo variable. Para asegurar la

unicidad de los nombres, los servicios que dan nombre a una clase o lo cambian debe comprobar que el

nombre no introduzca duplicidad en el conjunto de clases definidas en el esquema conceptual.

Si no se introducen duplicados en el conjunto de clases que forman parte del esquema conceptual, se

realizan los siguientes pasos:

• crear una instancia de la metaclase elemental_class,

• darle al nombre de la clase el valor pasado como argumento y,

• al resto de atributos variables darles el valor por defecto, esto es:

� no hay definido ningún atributo constante ni variable ni derivado,

� ningún evento ni transacción,

� el nombre del evento ��! es new,

� el nombre del evento "�� es destroy,

55 En las operaciones de modificación del esquema se utiliza a menudo la palabra �� para hacer referencia al

metaobjeto que describe con su estado la plantilla de una clase. Esto se hace para hacer más cómoda la lectura del

documento, si bien el concepto de clase ya ha sido definido como el componente de una instancia de un esquema

conceptual formado por una plantilla, una factoría y un almacén (en 4.3.8 se puede encontrar una caracterización

precisa de una clase OASIS en ��)


�

�

82

� la restricción de integridad es true,

� no hay ningún disparo definido,

� el párrafo %�� sólo permite el disparo del evento ��!,

� no es superclase de ninguna clase ni componente de ninguna agregación.

&'(')'+'('+'� " ��

El evento que destruye clases elementales se llama destroyClass y está definido en el atributo que

describe cuál es el evento "�� de la metaclase elemental_class. Se asume que el argumento del

servicio debe ser un identificador de clase existente.

�=��*��>@�"��?��)=�"��*��>��F�

Eliminar una clase es una operación substractiva que puede dejar el esquema en estados inconsistentes.

Para evitarlo se controlan, como precondición del servicio, las siguientes situaciones:

• no puede haber disparos declarados en otras clases que invoquen servicios en instancias de la

clase que se va a borrar,

• no tiene que haber definidos eventos compartidos con otras clases,

• la clase no puede ser la superclase de ninguna especialización permanente o temporal,

• la clase no puede participar en ninguna agregación.

Si todas las condiciones anteriores se cumplen, se puede proceder al borrado de la clase, lo cual supone

eliminar toda la información de la clase y eliminar todas sus instancias.

Alternativamente, la operación de eliminación de una clase se podría plantear de forma destructiva

eliminando la clase aunque ésta estuviera relacionada con otras clases. Al así hacerlo, habría que eliminar

toda la información que hiciera referencia a la clase eliminada de las clases con las que estuviera

relacionada. Pero esta forma de actuar, podría hacer que desapareciera información de las clases con las

que está relacionada.

Por ejemplo, si en una clase compuesta se usa un atributo de la clase componente en la fórmula de

derivación, habría que eliminar el atributo derivado o, si se usa un atributo heredado en la precondición de

un evento en una subclase, habría que eliminar la precondición para dejar el esquema en un estado


�

83

consistente. Creemos que esto haría que la herramienta tomara numerosas decisiones que

fundamentalmente corresponde tomarlas al diseñador.

&'(')'+'('('� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�P��F�>�F�

� �=��*��>@��) �%��??�) =��)=��0��P��*�@�P��F�>*�@��F�>�F�

Como precondición del servicio se comprueba que el nuevo nombre sea único en el esquema.

Este servicio cambia el nombre de la clase definido por el atributo name.

Cuando cambie un nombre puede que algún trigger o evento compartido de otra clase quede inconsistente

porque apunta a una clase que ya no exista. Para solucionarlo, a toda clase que usa en su definición el

antiguo nombre de la clase se le invoca el servicio classNameChanged para que actualice su estado

cambiando el nombre antiguo por el nuevo.

A todas las subclases directas que pueda tener la clase a la que se le cambia el nombre se les invoca el

servicio superClassNameChanged para que actualicen su estado.

A las agregaciones en las que participa la clase se invoca el servicio compClassNameChanged para

que actualicen su estado.

&'(')'+'('&'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@�P��*� �%��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%��F�>*�@��*�%��F�>�F�

�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*��F�>�F�

�=��*��>@�) �%��??�) =�)=�""��*@P��* �%�*��F>*@��*%��*��F>F�

�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*��'��F�>�F�

�=��*��>@��) �%��??��) =�)=�""��*�@�P��*� �%�*��'��F�>*@��*�%��*� �%��F�>�F�

�=��*��>@��)��??��)=��""��4*�@�P��*� �%�*��F�>�F�


�

�

84

�=��*��>@��) �%��??��) =�)=�""��4*�@�P��*� �%�*��F�>*� � �

� � � � � � ��@��*�%��*��= �%�>�F�>�F�

La precondición comprueba que no exista un atributo (constante, variable o derivado) con el mismo

nombre que el que se quiere crear; de esta forma, se satisface el invariante de unicidad de nombres al nivel

de atributos en la clase. Como una clase elemental puede ser superclase de n subclases (temporales o

permanentes), en ningún caso se permitirá la adición de un nuevo atributo si en alguna de las subclases ya

se ha declarado un atributo emergente con el mismo nombre. Si se usa un evento ��! de la clase en el

disparo de alguna otra clase, tampoco puede añadirse un atributo constante porque el disparo será

inconsistente con la nueva definición de clase, ya que en el mensaje que se envíe para crear un nuevo

objeto faltaría el nuevo atributo.

Para añadir un atributo constante a una clase hay que añadirlo al atributo que almacena los atributos

constantes que tiene la clase. A partir de dicho momento, cuando se cree una instancia de la clase se

deberá pasar un nuevo argumento para el atributo constante.

Al ser estas operaciones aditivas, si la clase que se está modificando tiene instancias, existe el problema

adicional de asignar valor a las instancias de la clase para dicho atributo. Presentamos cuatro posibles

soluciones a dicho problema disponibles a través de los cuatro servicios presentados en el perfil.

• Dar el valor por defecto del tipo de datos del atributo (servicio addConsAtt), de esta forma a los

objetos existentes se les daría el valor por defecto del TAD usado como dominio del atributo. En la

siguiente tabla se muestra los valores por defecto de los tipos predefinidos.

�5� ��%��"��

�� #,�

�� E�

�� E�

��

��

�

• Ejecutar una función de migración en cada uno de los objetos (servicio addConsAttP) de forma que

el valor del atributo constante sea calculado en función del estado del objeto. Para ello se especifica

cómo cambia el estado de cada una de las instancias a través del TAD serialAction.


�

85

• Dar un valor especificado por el usuario al atributo constante a todas las instancias de la clase

modificada (servicio addConsAttV).

• Dar un valor especificado por el usuario a cada una de las instancias de la clase modificada (servicio

addConsAttVI).

&'(')'+'('0'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� %�*�@��P��*�P�! �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %�*�@��P��*�P�! �%��F�>*�@��*�%��F�>F�

�=��*��>@��)��??��)=��0�� %��*�@��P��*�P�! �%�*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %��*�@��P��*�P�! �%�*��F�>*��

� � � � � � � � ��@��*�%��*��F�>F�

Si el nuevo tipo (NewType) es una generalización del definido originalmente, se cambia el tipo en la

definición del atributo y ya esta, pues los valores que tengan los objetos en el atributo (AttName) no

necesitan sufrir ninguna modificación.

En caso contrario:

La precondición comprueba que el atributo no esté siendo usando en los alias, las fórmulas de derivación,

las precondiciones o las condiciones de disparo de la clase o de sus subclases o en expresiones de camino

en las agregaciones en las que participe la clase.

Este servicio cambia el tipo del atributo cambiando el atributo consAtt.

Las posibles instancias que tenga la clase deben adaptar su estado a la nueva definición de la clase, para

ello se definen 2 eventos:

• changeConsAttType, cambia el atributo en cada una de las instancias aplicando una función de

conversión entre tipos por defecto,

• changeConsAttTypeP, cambia el atributo ejecutando en cada instancia una función de conversión

definida por el usuario haciendo uso del TAD serialAction que especifica qué valor se le debe

proporcionar al atributo.


�

�

86

&'(')'+'('1'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��*�@�P��F�>�F�

�=��*��>@��) �%��??��) =�)=��)��*�@�P��F�>*�@��F�>�F�

Para evitar que los esquemas queden en estados inconsistentes tras la realización de una operación de

borrado, únicamente se podrá borrar un atributo si no está siendo usado en ninguna parte de la

especificación de un sistema. Como precondición del borrado, se comprobará que dicho atributo no esté

siendo usado:

• En las fórmulas de las precondiciones de los eventos, en las condiciones de activación de los

disparos, en la restricción de integridad, en las evaluaciones de los eventos, en los alias definidos de

la clase ni en ninguna de sus subclases.

• Tampoco se puede borrar el atributo si se usa en expresiones de camino en las agregaciones con las

que pueda estar relacionada la clase o sus subclases.

Para poder borrar un atributo será necesario previamente eliminar todas las referencias que se hagan al

mismo.56

El borrado de un atributo implica la eliminación de dicha información en todas las instancias de la clase

afectada.

&'(')'+'(')'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��F�>*�@��*�%��*� �%��F�>�F�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��*��F�>�F�

56 Para poder realizar esta operación de forma cómoda, en caso de error, la interfaz gráfica debería ayudar al usuario

indicando por qué no se puede realizar la operación mostrando los lugares que hay que modificar.


�

87

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��*��F�>*��

� � � � � � ��@��*�%��*� �%�*��F�>�F�

�=��*��>@��)��??��)=��""��$*�@�P��*� �%��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��$*�@�P��*� �%��F�>*�@��*�%��F�>�F�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��*��F�>*� � �

� � � � � � ��@��*�%��*� �%�*� �%�F�>�F�

�=��*��>@��)��??��)=��""��4*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��4*�@�P��*� �%�*�5��'��*��F�>*� �

� � � � � � ��@��*�%��*� �%�*��= �%�>�F�>�F�

La semántica de la adición de un atributo variable a una clase elemental es muy similar a la de añadir un

atributo constante: la precondición es la misma y la evaluación debe añadir la información de que existe

un nuevo atributo variable cuyo nombre es Name, su tipo Type y el valor por defecto que toma en el

instante de creación de los objetos es Default (si Default contiene el átomo askFor el valor inicial del

atributo variable deberá ser pasado como argumento en el evento de creación).

Con respecto a las instancias existentes de la clase modificada, las soluciones adoptadas son similares al

caso de la adición de un atributo constante:

• el primer servicio añadirá el atributo a las instancias dándoles como valor inicial el valor por defecto

(si el valor por defecto es askFor se les da el valor por defecto del tipo del atributo),

• el segundo servicio ejecuta en cada una de las instancias una acción secuencial encargada de

modificar adecuadamente el estado del objeto para darle un valor concreto,

• el tercer servicio nos permite añadir atributos cuyo codominio es un conjunto (como valor por defecto

de un conjunto se asume el conjunto vacío),

• el cuarto servicio permite añadir un atributo y dar como valor del atributo a las instancias de la clase

uno distinto al valor por defecto (Val),

• finalmente, el quinto servicio permite asignar un valor especial a cada una de las instancias de la clase

que se debe pasar como argumento en ValList.


�

�

88

&'(')'+'('3'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@�P��*�P�!��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��5��*�@P��*P�!��F>*�@��*��F�>�F�

Para poder cambiar el valor por defecto de los atributos variables la única precondición es que el nuevo

valor pertenezca al �� definido para el atributo.

A partir de este momento, las nuevas instancias que se creen de la clase, tendrán como valor por defecto el

recién definido.

&'(')'+'('4'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� %�*�@��P��*�P�! �%�*�P�!5��'��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %�*�@��P��*�P�! �%�*�P�!5��'��F�>*��

� � � � � � � @��*�%��*�P�! �%�F�>F�

�=��*��>@��)��??��)=��0�� %��*�@��P��*�P�! �%�*�P�!5��'��*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %��*�@��P��*�P�! �%�*�P�!5��'��*��F�>*�

� � � � � � � @��*�%��*�P�! �%�*��F�>F�

Este servicio funciona de forma idéntica al servicio changeConsAttType (pág. 85) que cambia el tipo de

un atributo constante.

&'(')'+'('*5'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��*�@�P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)��*�@�P��F�>*�@��F�>�F�

Borrar un atributo variable es una operación substractiva que presenta los mismos problemas que los

presentados para el caso de los atributos constantes y, por lo tanto, las soluciones son las mismas.


�

89

El borrado de un atributo implica la eliminación de dicha información en todas las instancias de la clase

afectada.

&'(')'+'('**'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""5��*�@�P��*� �%�*��F�>�F�

�=��*��>@�) �%��??�) =��)=�""5��*�@�P��*� �%�*��F�>*�@��*�%��*��'��F�>�F�

A la hora de añadir un atributo derivado la precondición comprueba que el nombre no está duplicado (ni

en la clase ni en las subclases) y que la fórmula de derivación es correcta: se utilizan atributos definidos

para el objeto, las variables tienen el tipo correcto, si la clase forma parte de una agregación relacional

pueden usarse expresiones de camino para consultar atributos de la clase compuesta y debe existir una

variable que coincida con el nombre del atributo a través de la cual se devuelve el valor calculado para el

atributo derivado

Este servicio añade el nuevo atributo derivado al estado del metaobjeto sobre el que se invoca el servicio

añadiéndolo al atributo derAtt.

&'(')'+'('*+'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@�P��*� �%�*�P�!��F�>�F�

�=��*��>@��) �%��??�) =�)=�0��5��*@P��* �%�*P�!��F>*@��*%��*��'��F>�F�

Para cambiar un atributo derivado hay que comprobar que la fórmula de derivación es consistente tal y

como se vio en el punto anterior.

&'(')'+'('*('� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)�5��*�@�P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)�5��*�@�P��F�>*�@��F�>�F�

Al igual que en el resto de operaciones de borrado no se permite el borrado de información que pueda

dejar el esquema en estados inconsistentes, comprobándolo en la precondición del servicio.


�

�

90

En el caso de que sea posible el borrado del atributo, únicamente es necesaria la eliminación de la

información del atributo en el metaobjeto en el que estaba definido.

&'(')'+'('*&'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�

Como precondición hay que comprobar que no hay un atributo con el mismo nombre que se le quiere dar

al que se quiere cambiar de nombre ni en la clase ni en las subclases.

Esta operación se puede plantear, al menos, de dos maneras:

• No permitiendo la modificación del nombre mientras esté siendo usado en alguna parte de la

especificación, con lo cual hay que comprobarlo como precondición del servicio.

• Permitir el cambio, pero trasladarlo (invocar el servicio attNameChangedInSuperClass) a todas

las subclases en las que el antiguo nombre pueda estar siendo usado, modificando los alias, las

precondiciones, restricciones de integridad, fórmulas de activación de disparos y evaluaciones de los

eventos en las subclases. Además, hay que comunicar (servicio compAttNameChanged) a las

clases compuestas que el nombre de un atributo en una clase componente ha cambiado para que

actualicen su estado.

Se ha optado por la segunda opción por ser más flexible.

&'(')'+'('*0'� " ��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@��P��*��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@��P��*��F�>*�@��*��=��>�F�>�F�

La precondición comprueba que no exista un alias definido con el mismo nombre que el que se quiere

definir ni en la clase ni en las subclases. Se comprueba que los atributos de la lista que definen el

mecanismo de nombramiento (ConsAttList) estén definidos en la clase y sean todos atributos constantes.

Como se exige de los alias que identifiquen de forma única a cada uno de los objetos, se comprueba que


�

91

en los objetos que ya existan en la clase no haya duplicados para la combinación de los valores de la lista

de atributos que define el alias.

Para añadir un nuevo alias se añade al atributo que los almacena (alias). A partir de dicho momento, se

pueden identificar las instancias de la clase usando el alias definido como mecanismo de identificación.

La equivalencia entre los alias y los oid de los objetos se calcula deductivamente a través de unas reglas

definidas (ver 4.3.8).

&'(')'+'('*1'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�

Como precondición hay que comprobar que exista el alias y que el nuevo nombre no ha sido ya usado

como nombre de otro alias ni en la clase ni en las subclases.

La evaluación asociada únicamente cambia el antiguo nombre por el nuevo en el atributo alias de la

clase.

Los alias se utilizan para identificar a los objetos cuando se definen los disparos. Podría ser que al

cambiar el nombre a un alias, algún disparo quedase inconsistente. Para evitarlo, a todos los agentes de los

servicios de la clase se les invoca el servicio aliasNameChanged indicándoles que el nombre de un alias

ha cambiado para que actualicen su estado.

&'(')'+'('*)'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@��P��*�P�!5��F�>�F�

�=��*��>@��) �%��??��) =�)=��0��5��*�@��P��*�P�!5��F�>*��

� � � � � � � @��*��=��>F>F�

La precondición comprueba que exista el alias, que los atributos de la lista estén definidos en la clase y

sean todos atributos constantes y que, en los objetos que ya puedan existir en la clase, no existan

duplicados para la combinación de los valores de la lista de atributos que definirán el alias. Tampoco se


�

�

92

permite cambiar la definición de un alias si se está usando para identificar a las instancias de la clase en

los disparos de alguna otra clase.57

Como evaluación se modifica la definición de alias en el atributo (alias).

&'(')'+'('*3'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��*�@��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)��*�@��P��F�>*�@��F�>�F�

No se permite el borrado del alias si se usa para identificar a las instancias de la clase en los disparos de

los agentes de los servicios de la clase.

Para eliminar un alias únicamente es necesaria la eliminación de la información del atributo (alias) en el

metaobjeto. A partir de ese momento ya no se podrá identificar a las instancias de la clase a través del

alias.

Otra posible solución consistiría en borrar todos los disparos que para identificar al destino haga uso del

alias que se va a borrar. Pero esta forma de actuar llevaría a eliminar información de la cual el diseñador

posiblemente no es consciente.

&'(')'+'('*4'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��F�>*�@��'��F�>�F�

Como precondición del servicio hay que comprobar que la fórmula es consistente en la clase en la que se

quiere introducir. Ser consistente quiere decir ser una �� tal y como define el TAD formula y utilizar

atributos definidos en la clase en la que se define la restricción (si la clase forma parte de una agregación

relacional, pueden usarse expresiones de camino para consultar atributos de la clase compuesta).

57 La razón es que los disparos podrían ser inconsistentes si se cambia la definición del alias (se añaden, cambian o

borrar atributos constantes de la definición) y no se cambia en los disparos de las clases.


�

93

Cuando se crea un metaobjeto, la restricción de integridad definida por defecto para la clase es true,

indicando que no hay ninguna restricción. Dinámicamente, se puede cambiar la restricción de integridad

haciendo uso del servicio changeConstraint. Al hacerlo, podría darse el caso de que las instancias de la

clase que está siendo modificada dejaran de ser consistentes con la nueva restricción. Hemos detectado

dos posibilidades de actuación:

• No permitir el cambio de restricción si existen instancias de la clase que no satisfacen la nueva

restricción. Esto se comprobaría en la precondición del servicio.

• Eliminar los objetos que dejen de ser consistentes con la nueva restricción de integridad como parte

de la evaluación del servicio.

Creemos que la primera opción es la mejor, ya que introduce menos cambios en los sistemas que la

segunda opción la cual haría desaparecer determinados objetos al dejar de ser consistentes con la nueva

definición del esquema.58

&'(')'+'('+5'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""�)��*�@��)��*� �%��F*�>�F�

�=��*��>@��) �%��??�) =�)=��""�)��*�@��)��*� �%��F�>*�@��)��*��=%��>�F�>�F�

La precondición del servicio impide que se pueda añadir el evento si el nombre del evento está ya

definido en la clase.

La evaluación del servicio modifica el atributo que define los eventos de la clase y los tipos de los

argumentos (event y evType), inicializa la evaluación asociada al evento como true (indicando que no

hay ningún cambio de estado asociado) y la precondición a true (indicando que no hay ninguna

restricción asociada a la invocación del evento).

En el caso de que existiera un evento definido en alguna especialización temporal con el mismo nombre,

se considerará redefinido en dicha subclase. En el caso de que exista un evento con el mismo nombre en

58 La herramienta que ofrezca al usuario los servicios para la definición de sistemas, podría facilitar en todo momento

ayuda al usuario indicándole, en este caso, qué debe hacer para poder cambiar la restricción de integridad (cuáles son

los objetos que no satisfacen la nueva restricción de integridad y que deben cambiar su estado para ser consistentes

con la nueva restricción).


�

�

94

una especialización permanente, se considera que en la subclase se amplía la acción del evento. En las

subclases en las que no esté definido ningún evento con el mismo nombre y perfil se considera heredado.

&'(')'+'('+*'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��)��*�@�3�"�)��*�P�!�)��*P�! �%��F�>�F�

�=��*��>@�) �%��??�) =�)=�0��)��*@3�"�)��*�P�!�)��*�P�! �%��F>*� �

� � � � � � @��)��*��)��*��=%��>F�>�F�

Entendemos por cambio del perfil de un evento el cambio del nombre o los argumentos del mismo.

La precondición del servicio impide que se pueda modificar el evento:

� si ya existe un evento con el nuevo nombre en la clase,

� si los argumentos que no aparecen en el nuevo perfil que sí estaban definidos en el perfil antiguo se

usan en la precondición o en la evaluación asociada al evento en la clase o en las subclases,

� si el evento participa en una transacción y los nuevos argumentos del evento no están definidos en el

perfil de la transacción o se les proporciona valor en el cuerpo de la transacción,

� si los parámetros del nuevo perfil son menos generales que los definidos previamente en la clase o en

las subclases para el evento (��)��1�).

Si es posible realizar el cambio de evento, la evaluación modifica los atributos que definen los eventos de

la clase, los tipos, las precondiciones y las evaluaciones (event, evType, evPre y evVal).

Al igual que pasaba con los atributos, es posible que el nombre antiguo estuviera siendo usado en

diferentes partes de la especificación de la clase (en el párrafo process, en las evaluaciones, en las

precondiciones, en los disparos, en la definición de eventos compartidos o fuera el evento que especializa

a las instancias de la clase en una subclase temporal). El evento antiguo debe ser cambiado por el nuevo

en todos los lugares en los que aparezca, incluidas las subclases, las clases agentes del evento y las clases

con las que se comparte el evento.

A las subclases se les invoca el servicio eventSigChangedInSuperClass para comunicarles que se ha

cambiado el perfil de un evento en la superclase. A las clases agentes del evento que ha cambiado se les


�

95

invoca el servicio eventSigChanged. Si el evento es compartido con otras clases, se les comunica

(servicio sharedSigChanged) que deben cambiar el perfil del evento compartido. A las clases

compuestas se les invoca el servicio compEventSigChanged para que cambien el perfil del evento del

componente en las expresiones de camino en las que se pueda invocar.

&'(')'+'('++'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��)��*��"�F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��)��*��"�F�>*�@��)��*��'��F�>�F�

La precondición del servicio comprueba que la fórmula que define la precondición sea consistente en la

clase de la misma manera que se hizo al definir la restricción de integridad.

Se pueden definir precondiciones para el evento ��!. Dichas precondiciones, obviamente, no pueden ser

evaluadas sobre el estado de un objeto que todavía no existe. La evaluación de la precondición del evento

��! se realiza sobre el estado de la clase que ofrece dicho servicio, pudiendo utilizar en su definición los

atributos definidos para las clases59.

La evaluación modifica el atributo que define las precondiciones de los eventos de la clase (evPre).

&'(')'+'('+('� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��)��*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��)��*��F�>*�@��)��*��F�>�F�

La precondición del servicio comprueba que la acción secuencial que define la evaluación del evento sea

consistente en la clase. En este caso la consistencia vendrá dada por ser una �� tal y como se describe en

el TAD �� y que las transiciones de estado elementales afecten únicamente a atributos variables

definidos en la clase.

Este servicio modifica el atributo que define las evaluaciones de los eventos de la clase (evVal).

59 De esta forma se pueden imponer, por ejemplo, precondiciones basadas en la población de las clases.


�

�

96

&'(')'+'('+&'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��)��*�@��)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)��)��*�@��)��P��F�>*�@��F�>�F�

La precondición del servicio impide que se pueda borrar un evento si está siendo usado:

• localmente: en el párrafo process, como evento que especializa a las instancias de la clase

temporalmente, en los disparos, en las transacciones o en la definición de eventos compartidos,

• en las subclases: en el párrafo process, como evento new, en los disparos, en las transacciones,

• en las clases agentes: en los disparos,

• en las agregaciones: a través de expresiones de camino en el cuerpo de las transacciones.

Este servicio elimina el evento de los atributos que lo definen (event, evType, evVal y evPre).

&'(')'+'('+0'� �/�� 6

B��'�� 1�

�=��*��>@��)��??��)=��""P�!*�@��)��*� �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��""P�!*�@��)��*� �%��F�>*�@��)��*��=%��>�F�>�F�

La precondición del servicio impide que se pueda añadir el nuevo evento ��! si el nombre del evento está

ya definido en la clase o en sus subclases permanentes.

El servicio añade un nuevo evento al atributo que define los eventos ��! en la clase; la evaluación y la

precondición se inicializan a valor true, indicando que no hay definida precondición ni evaluación. Se

asume que cuando se invoca el evento ��! en una clase, los primeros argumentos contendrán el valor para

los atributos del objeto a crear. Los argumentos declarados en este servicio servirán para diferenciar los

diferentes ��! que se declaren en una clase.

&'(')'+'('+1'� .�� 6

B��'�� 1�


�

97

�=��*��>@��)��??��)=��0��P�!*�@�3�"�)��*�P�!�)��*�P�! �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P�!*�@�3�"�)��*�P�!�)��*�P�! �%��F�>*� �

� � � � � � �@��)��*��)��*��=%��>�F�>�F�

Este evento funciona de forma similar al descrito para cambiar el perfil de un evento (apartado

4.3.7.2.3.21) teniendo en cuenta que el perfil que se está cambiando es el de un evento ��!.

&'(')'+'('+)'� 2�� 6� ��

B��'�� 1�

�=��*��>@��)��??��)=��)�P�!*�@�)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)�P�!*�@�)��P��F�>*�@��F�>�F�

Al igual que ocurre cuando se intenta borrar un evento la precondición impide que se pueda borrar si está

siendo usado tal y como se ha explicado en el apartado 4.3.7.2.3.24. Adicionalmente, no se puede borrar

el evento si es el único que queda (siempre debe haber definido un evento ��!, por lo menos).

Se elimina el evento ��! del atributo que lo define.

&'(')'+'('+3'� �/�� 7

B��'�� 1�

�=��*��>@��)��??��)=��""5��*�@��)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��""5��*�@��)��P��F�>*�@��F�>�F�

La precondición del servicio impide que se pueda añadir el servicio si dicho nombre está ya definido en la

clase o en sus subclases o si ya está definido el evento "�� en la clase.

Este servicio modifica el atributo que define el nombre del evento "�� en la clase (destroy). No es

necesario indicar el argumento porque siempre debe ser un identificador de objeto.

&'(')'+'('+4'� .�� 7

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@��)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��5��*�@��)��P��F�>*�@��F�>�F�


�

�

98

Este servicio funciona de forma análoga a como lo hace el servicio que cambia de nombre el evento ��!

definido anteriormente.

Adicionalmente, en las subclases se invoca el servicio eventSigChangedInSuperClass para que

actualicen el nombre del evento donde sea utilizado. A los agentes del evento se les dispara el evento

eventSigChanged.

&'(')'+'('(5'� 2�� 7� ��

B��'�� 1�

�=��*��>@��)��??��)=��)�5��*��>�F�

�=��*��>@��) �%��??�) =�)=��)�5��*��>*��>�F�

Al igual que ocurre cuando se intenta borrar un evento, la precondición impide que se pueda borrar si está

siendo usado tal y como se ha explicado en el apartado 4.3.7.2.3.24.

Se elimina el evento "�� del atributo que lo define.

&'(')'+'('(*'� .��

B��'�� 1�

�=��*��>@��)��??��)=�� $0��"*�@��)��*��F�>�F�

�=��*��>@��) �%��??�) =�)=�� $0��"*�@��)��*��F�>*�@��)��*��=��>F�>�F�

La precondición del servicio comprueba que el evento a compartir esté definido en la clase que no sea en

��! ni el "�� y que existan las clases indicadas en ClassList.

La evaluación modifica el atributo que define los eventos compartidos (shared) añadiendo la nueva

información.

A las clases con las que se comparte el evento, definidas en ClassList, se les invoca el servicio

madeShared para comunicarles que se ha definido un evento como compartido y sus instancias deberán

participar en el mismo (con lo que el evento debe pasar a ser compartido con la clase en la que

inicialmente se ha definido).


�

99

&'(')'+'('(+'� " ��

B��'�� 1�

�=��*��>@��)��??��)=��)�$0��"*�@��)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)�$0��"*�@��)��P��F�>*�@��F�>�F�

La evaluación modifica el atributo que define los eventos compartidos (shared) eliminando al evento de

la lista de compartidos pasando a ser privado en la clase en la que se invocó el servicio.

A las clases con las que se compartía el evento se les invoca el servicio removedShared para

comunicarles que el evento que anteriormente estaba definido como compartido con la clase deja de serlo.

&'(')'+'('(('� �/��

B��'�� 1�

�=��*��>@��)��??��)=��"" ��*�@� ��*� �%��F�>�F�

�=��*��>@��) �%��??��) =��)=��"" ��*�@� ��*� �%��F�>*� � �

� � � � � ��@��*��=%��>�F�>�F�

La precondición del servicio impide que se pueda añadir la transacción si dicho nombre está ya definido

como una transacción en la clase o en las especializaciones permanentes.

La evaluación del servicio modifica el atributo que define las transacciones de la clase y los tipos de los

argumentos (transaction y trType) e inicializa el cuerpo de la transacción (trVal) como true (indicando

que no hay ningún cuerpo asociado).

&'(')'+'('(&'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� *�@�3�" ��*�P�! ��*�P�! �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� *�@�3�" ��*�P�! ��*P�! �%��F�>*��

@��*��*��=%��>�F�>�F�

Entendemos por cambio del perfil de una transacción el cambio del nombre o el cambio de los

argumentos de la misma.

La precondición del servicio impide que se pueda modificar la transacción si ya existe una con el nuevo

nombre en la clase o en las subclases permanentes, si los argumentos que no aparecen en el nuevo perfil


�

�

100

que sí estaban definidos en el antiguo son necesarios porque tienen el mismo nombre que algún argumento

de algún evento del cuerpo de la transacción o si los parámetros del nuevo perfil son menos generales que

los definidos previamente en la clase o en las subclases temporales para la transacción (��)��1�).

Si es posible realizar el cambio de perfil, la evaluación modifica el atributo que define las transacciones

de la clase, el tipo de sus argumentos y el cuerpo de la transacción (transaction, trType y trVal).

De forma similar a los eventos, es posible que el antiguo perfil de la transacción estuviera siendo usado en

la especificación de los disparos de la clase, las subclases o los agentes. El perfil antiguo debe ser

cambiado por el nuevo en todos los lugares en los que aparezca.

A las subclases temporales se les invoca el servicio tranSigChangedInSuperClass para comunicarles

que se ha cambiado el perfil de una transacción en la superclase. A las clases agentes de la transacción que

ha cambiado se les invoca el servicio tranSigChanged.

&'(')'+'('(0'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� "�*�@� ��*��"��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� "�*�@� ��*��"��F�>*��

��@��*��$��F�>�F�

La precondición del servicio comprueba que el cuerpo de la transacción sea consistente en la clase. En

este caso la consistencia vendrá dada por ser una �� tal y como se describe en el TAD tranSerialAction,

que los eventos estén definidos en la clase, que a todos los argumentos de los eventos se les proporcione

valor en el cuerpo de la transacción o que tengan el mismo nombre y tipo que los argumentos de la

transacción y, si la clase forma parte de una agregación relacional, que los eventos que se invoquen en

expresiones de camino estén definidos en la clase compuesta.

La evaluación modifica el atributo que define el cuerpo de las transacciones de la clase (trVal).

&'(')'+'('(1'� 2��

B��'�� 1�

�=��*��>@��)��??��)=�� *�@� ��P��F�>�F�

�=��*��>@��) �%��??�) =�� *�@� ��P��F�>*�@��F�>�F�


�

101

La precondición del servicio impide que se pueda borrar una transacción si está siendo usada en los

disparos de los agentes de la transacción.

La evaluación elimina la transacción de los atributos que la definen (transaction, trType y trVal).

&'(')'+'('()'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��"" ��*�@� ��F�>�F�

�=��*��>@��) �%��??��) =��)=��"" ��*�@� ��F�>*�@��F�>�F�

La precondición comprueba que el disparo a añadir sea diferente de los disparos previamente existentes

en la clase. La condición de activación debe ser una formula, usar los atributos definidos en la clase y, si

la clase forma parte de una agregación relacional, los atributos que se consulten en las expresiones de

camino deben estar definidos en la clase compuesta. El destino debe existir, es decir: la clase debe estar

definida en el esquema o si se invoca a un objeto concreto de una clase, el alias que se utiliza para

identificar al destino debe estar definido en la clase. El servicio a invocar también debe estar definido en

la clase destino del disparo.

La evaluación del servicio modifica el atributo que define los disparos de la clase (triggers).

El hecho de definir un disparo establece una relación de agente entre la clase que tiene definido el disparo

y la clase que ofrece el servicio. A la clase que define el servicio se le invoca el evento addAgent para

comunicarle cuáles serán los posibles agentes de los servicios que define.

&'(')'+'('(3'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� *�@� ��*�P�!��"��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� *�@� ��*�P�!��"��F�>*��

@��*��'��F�>�F�

La precondición del servicio comprueba que la nueva condición sea correcta tal y como se ha comentado

cuando se define un disparo. Además, debe existir el disparo a cambiar.

Este servicio modifica el atributo que define los disparos de la clase (triggers).


�

�

102

&'(')'+'('(4'� 2��

B��'�� 1�

�=��*��>@��)��??��)=�� *�@� ��F�>�F�

�=��*��>@��) �%��??��) =��)=�� *�@� ��F�>*�@��F�>�F�

Se elimina el disparo del atributo (triggers).

Si el servicio que se invocaba en el disparo ya no es invocado en ningún otro disparo definido en la clase,

se invoca el servicio remAgent en la clase en la que está definido el servicio, indicando que la clase en la

que se ha eliminado el disparo ya no es agente del servicio.

A partir del momento en que se elimina un disparo, las instancia de la clase dejan de tener la obligación

que representaba dicho disparo.

&'(')'+'('&5'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@�4��$��*��)��P��*��$��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�4��$��*��)��P��*��$��F�>*� �

� � � � � ��@��*��*��F�>�F�

Es condición necesaria para poder realizar este servicio que el evento esté definido en la clase. Si el

evento es un evento ��! el estado inicial sólo puede ser el estado new, si el evento es el "�� el estado

final sólo puede ser destroy.

Este evento añade la nueva descripción de proceso en la clase modificando el atributo process.

Si se modifica de alguna manera (inserta, borra o modifica) la descripción de proceso de una clase cuando

está poblada, es muy posible que la traza de los objetos existentes ya no sea una vida válida según la

descripción de proceso. Frente a este problema se puede optar por alguna de las soluciones siguientes:

a) Destruir los objetos que ya no son válidos según el proceso.

b) Hacer una restricción de los eventos de la traza según la nueva definición de proceso para obtener una

traza válida. Pero en este caso no se mantendría la equivalencia entre el estado ��!��"�y el estado

�� !��", y se pierde la información de los eventos que han servido los objetos.


�

103

c) Relajar la necesidad de que la traza deba ser una vida válida y asumir que contiene los eventos

servidos por el objeto a lo largo de su vida aunque haya cambiado el proceso y utilizar el estado en el

que se encuentra el objeto según el proceso como punto de continuidad para la vida del objeto. En

este caso también se pierde la equivalencia entre el estado ��!��"�y estado �� !��".

Hemos optado por la tercera posibilidad por ser aquella en la que se pierde menos información. Aunque

desde un punto de vista estricto sólo la primera posibilidad es la correcta.

&'(')'+'('&*'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@�4��$��*��)��P��*��$��*�P�!�)��F>F�

�=��*��>@��) �%��??��) =�)=�0��*@4��$��*�)��P��*��$��*P�!�)��F>*�

� � � � � �� @��*��*��*��F�>�F�

Es condición necesaria para poder realizar este servicio que exista la descripción de proceso a cambiar y

que el nuevo evento esté definido en la clase. Adicionalmente, se deben comprobar las mismas

condiciones que en el servicio anterior.

Este evento cambia la descripción de proceso en la clase modificando el atributo process.

&'(')'+'('&+'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��*�@�4��$��*��)��P��*��$��F�>�F�

�=��*��>@��) �%��??��) =�)=��*�@�4��$��*��)��P��*��$��F�>*� �

� � � � � ��@��*��*��F�>�F�

Es condición necesaria para poder realizar este servicio que exista la descripción de proceso a borrar.

Este evento elimina la descripción de proceso en la clase en la que se invoca.60

60 De cara a evaluar la consistencia de la especificación de proceso de una clase, se podrían definir atributos

derivados que comprobasen diferentes condiciones que podrían inducir errores en la animación de la especificación.

Por ejemplo, se podría comprobar si algún evento no está en la especificación de proceso (con lo que nunca se podría

invocar) o si existe algún camino que permita la invocación de todos los servicios definidos en las clases, etc.


�

�

104

&'(')'+'('&('� .�� 8��

B��'�� 1�

�=��*��>@��)��??��)=�� $'�� $*��>�F�

�=��*��>@��) �%��??��) =��)=�� $'�� $*��>*��>�F�

�=��*��>@��)��??��)=�� $'�� $�*��>�F�

�=��*��>@��) �%��??��) =��)=�� $'�� $�*��>*��>�F�

�=��*��>@��)��??��)=�� $'�� $�*��>�F�

�=��*��>@��) �%��??��) =��)=�� $'�� $�*��>*��>�F�

�=��*��>@��)��??��)=�� $'�� $�4*��>�F�

�=��*��>@��) �%��??��) =��)=�� $'�� $�4*��>*��>�F�

Este servicio especializa a una clase en especialización temporal de otra. A partir de dicho instante, la

subclase hereda todas las propiedades que hubieran definidas en la superclase (invariante de herencia

total). Las propiedades que existieran definidas en la subclase serán, a partir de entonces, propiedades

emergentes.

Cuando se decide introducir una nueva relación de herencia en una especificación, se debe comprobar que

las instancias que pueda tener la subclase son consistentes con la nueva especificación. Para ello se han

definido 4 eventos (makeSubClassTS, makeSubClassTSP, makeSubClassTSV,

makeSubClassTSVI) que proporcionan 4 posibles soluciones al problema de la adecuación de las

instancias a la nueva definición. La semántica de cada uno de los eventos se puede ver en el apartado

4.3.7.3.3.1 en la página 109.

61 Los argumentos de los eventos que especializan a los objetos sobre los que se invocan, no quedan totalmente

definidos por el perfil del evento definido en la superclase. En la definición del perfil en la superclase sólo se definen

los argumentos necesarios para la evaluación que se defina en la superclase. Tal y como se puede ver en la Figura 42

de la página 6, los primeros argumentos que se pasarán en la invocación del servicio son los definidos en el perfil de

la superclase, después los valores de las propiedades emergentes del objeto que se especializa y a continuación los

argumentos que necesite el evento para la evaluación que se defina en la subclase. En este caso el primer argumento

será el nombre de la superclase y los siguientes dependerán del servicio invocado.


�

105

Tal y como se puede ver en la reificación del modelo de ejecución en la página 252, cuando se debe

especializar a un objeto temporalmente se invoca el evento ��! de la especialización temporal (en este

caso se invoca el evento makeSubClassTS�, donde � es el sufijo del servicio que se haya invocado en

el metaobjeto, en la metaclase temporalSpecialization_class).

&'(')'+'('&&'� .�� 8��

B��'�� 1�

�=��*��>@��)��??��)=�� $'��$*��>�F�

�=��*��>@��) �%��??��) =��)=�� $'��$*��>*��>�F�

�=��*��>@��)��??��)=�� $'��$�*��>F�

�=��*��>@�) �%��??�) =�)=�� $'��$�*��F>*��>�F�

�=��*��>@�)��??�)=�� $'��$�*��>F�

�=��*��>@�) �%��??�) =�)=�� $'��$�*��>*��>�F�

�=��*��>@��)��??�)=�� $'��$�4*��>F�

�=��*��>@�) �%��??�) =�)=�� $'��$�4*��>*��>�F�

Este servicio especializa a una clase en especialización permanente de otra. A partir de dicho instante, la

subclase hereda todas las propiedades que hubieran definidas en la superclase.

Se debe comprobar que las instancias que puedan tener la superclase y la subclase son consistentes con la

nueva relación de herencia introducida. Para ello se han definido 4 eventos (makeSubClassPS,

makeSubClassPSP, makeSubClassPSV, makeSubClassPSVI) que proporcionan 4 posibles

soluciones al problema de la adecuación de las instancias a la nueva definición de esquema. La semántica

de cada uno de los eventos se puede ver en el apartado 4.3.7.4.3.1 en la página 125.

62 Cuando se invoque alguno de los servicios sobre una clase los argumentos con los que se debe invocar son: los

argumentos definidos en esta definición (ninguno), los valores de las propiedades emergentes definidas en la subclase

(la condición de especialización y el nombre de la superclase) y los argumentos que se definan en el evento ��! de la

subclase (ver sección 4.3.7.4.3.1).


�

�

106

Cuando se debe especializar a un objeto temporalmente se invoca el evento ��! de la especialización

temporal (en este caso, se invoca el evento makeSubClassPS� de la metaclase

permanentSpecialization_class).�

&'(')'+'('&0'� .��

B��'�� 1�

�=��*��>@��)��??��)=�� *��>F�

�=��*��>@��) �%��??��) =�)=�� *��>*��>�F�

La invocación de este servicio en un metaobjeto lo convierte en una agregación (lo especializa

temporalmente como instancia de la clase aggregation_class), inicialmente sin componentes, a la que se

le irán añadiendo los componentes que forman parte de la agregación gradualmente, invocando el servicio

addComp definido para las agregaciones.

Cuando se debe especializar a un objeto temporalmente se invoca el evento ��! de la especialización

temporal (en este caso se invoca el evento makeAgg en la clase aggregation_class).


�

107

&'(')'('� �� -� ��8��,��

Los servicios que convierten a una clase en una especialización temporal se llaman makeSubClassTS,

makeSubClassTSP, makeSubClassTSV y makeSubClassTSVI, han sido definidos como eventos

propios en la superclase elemental_class y son los eventos ��! de la metaclase

temporalSpecialization_class.

Cuando un objeto se especializa, el conjunto de propiedades del mismo está formado por las propiedades

0��"�"� definidas en las superclases y las propiedades �� definidas en la especialización. En

las especializaciones temporales se puede redefinir el comportamiento de los servicios heredados

modificando las precondiciones y las evaluaciones de los eventos y el cuerpo de las transacciones, ya que

sólo se exige compatibilidad de signatura.

&'(')'('*'� #��

La metaclase temporalSpecialization_class, tal y como se vio en la Figura 14, es una especialización

temporal de la metaclase elemental_class:

�=��*��>�77��=��*��>��

A continuación se muestra la parte emergente de la plantilla �� de la metaclase


�=��*��>@�'%��N?��F��

�=��*��>@��0�N??��F��

�=��*��>@�)��0�N??�)��F��

�=��*��>@�"��0�N??�"��F��

�=��*��>@��0�N?��'��F��

�=��*��>@��)��0�N??��)��F��

�=��*��>@�0��"0�N??�0��"�F��

�=��*��>@��0�N??��F��

�=��*��>@��0�N??��F��

63 La relación de herencia entre las metaclases realmente se define entre los metaobjetos que definen la plantilla de las

metaclases y es la vista por proyección descrita en el apartado 4.3.8 la encargada de trasladarla a las metaclases.


�

�

108

�=��*��>@�%��0�N??�%��F��

Los atributos derivados (consAtth, varAtth, derAtth, ...) se han definido con el objetivo de conocer

cuáles son las propiedades heredadas de su superclase.

La plantilla de la metaclase temporalSpecialization_class está descrita en el estado del metaobjeto

o(om,ts_c). Como la metaclase temporalSpecialization_class es una especialización temporal, el

metaobjeto que define su plantilla es instancia de la metaclase que define las especializaciones

temporales:

�=��*��>�7��=��*��>�

&'(')'('+'� ��


temporalSpecialization_class. Como se puede observar, los atributos emergentes están definidos en el

atributo varAtt, los eventos emergentes y los redefinidos están definidos en event, etc.

�=��*��>@��?�#��%��$%��1��,�F�

�=��*��>@�'%��?�#��,�F�

�=��*��>@�)��??�G��=�'%��*��*�� >�H�F��

�=��*��>@��!��??�G��)=�� $'�� $*��>*��)=�� $'�� $�*�@��F>*�

�)=�� $'�� $�*�@��F>*��)=�� $'�� $�4*�@��F>�H�F�

�=��*��>@� �)�� ??� G� �)='%��P��0��"*� @P�!P��F>*� �)=�0��P��"*�

@3�"P��*� P�!P��F>*� �)=�)��$��0��"4�$'%��*� @3�)��*�

P�)��*� �%��F>*��H�F�

��

Dado un metaobjeto C instancia de la metaclase temporalSpecialization_class, la regla deductiva a

través de la cual se obtienen los atributos constantes heredados de sus superclases es la siguiente:

�@��0��??��F�←��7��=�*��>�M��77�$��M��WN�$��M�$�@��??��F��

64 En 4.3.7.3.3 se pueden observar todos los servicios emergentes o redefinidos de la metaclase



�

109

�@��0�??��F�←��7��=�*��>�M��77�$��M��WN�$��M�$�@��0��??��F��

El resto de atributos derivados para las propiedades heredadas se definen de la misma manera, excepto

constrainth que se define como la conjunción de las restricciones definidas en las superclases.

&'(')'('('� - ��

Los servicios que ofrecen las instancias de la metaclase temporalSpecialization_class son

esencialmente los mismos que ofrecen las clases elementales que permiten definir la plantilla OASIS de

las clases elementales, más unos pocos emergentes. Algunos servicios que ofrecen las especializaciones

temporales están redefinidos porque deben tener en cuenta, a la hora de especificar el tipo, las

características que vienen heredadas de sus superclases. A continuación se muestran los servicios básicos

de evolución y en el apéndice B se pueden ver los auxiliares.

- ��9� � ��

&'(')'('('*'� .� �� 8�� : � �� 6;

Tal y como se define en OASIS, el evento que especializa dinámicamente a las instancias de una

superclase en instancias de la subclase es el evento ��! de ésta. De forma que la semántica asociada al

evento ��! cambia: el evento ��! de las especializaciones temporales no crea instancias nuevas sino que

especializa a las instancias de las superclases (ver página 245 para más detalles).

Los eventos de creación de las especializaciones temporales están definidos en el atributo new del

metaobjeto tempSpecialization_class.

�=��*��>@��!��??�G�� )=�� $'�� $*��>*��)=�� $'�� $�*�@��F>*�

�)=�� $'�� $�*�@��F>*��)=�� $'�� $�4*�@��F>�H�F�

Como se puede ver en la reificación del servicio que especializa a objetos (Figura 36), el primer

argumento que se pasará cuando se invoquen estos servicios será el oid del objeto a especializar, después

se proporcionarán los valores de las propiedades emergentes (en este caso únicamente el nombre de la

superclase) y finalmente los argumentos necesarios según el evento que se invoque (Actions o AttList).

Existen ciertas restricciones a la hora de definir una especialización temporal de una clase que deben ser

comprobadas como precondición del servicio:


�

�

110

• La introducción de esta nueva relación no puede introducir ciclos en el grafo de herencia ��

(invariante de grafo de herencia acíclico).

• Tal y como explica Wieringa en [Wie95] una especialización temporal no puede especializarse

permanentemente. Para evitarlo se comprueba que ni la clase sobre la que se invoca este evento ni

ninguna de sus subclases sea superclase de una especialización permanente.

• En OASIS no pueden existir atributos con el mismo nombre en las subclases que los definidos en la

superclase (invariante de unicidad de nombres).

• En la superclase deben existir eventos con el mismo nombre que los eventos ��! de la

especialización.

• No pueden haber definidos disparos a los eventos portadores en la superclase porque va a cambiar el

perfil de los mismos.

Para modelar que la clase SubClass sobre la que se invoca este evento es subclase de SuperClass se

inserta la relación �� entre los metaobjetos que definen las plantillas de las clases:

=�$'��77�$'%��>��

siendo SubClass y SuperClass los identificadores de los metaobjetos que definen las clases.

El principal problema a la hora de crear una relación de herencia entre dos clases existentes proviene del

hecho de que ambas pueden estar pobladas de antemano; en concreto, las instancias de la subclase

adquieren en un instante unas propiedades heredadas a las que se les debe dar valor. Con los atributos

variables no hay excesivo problema porque se les puede dar el valor por defecto, pero con los atributos

constantes hay que optar por una de las siguientes vías:

• no permitir la definición de relaciones de herencia entre clases si la subclase tiene población, lo cual

simplifica mucho las cosas, o

• permitirlo, y este caso habrá que dar valor a los atributos emergentes de todas las instancias de la

subclase.

Obviamente, la primera solución haría que la herramienta fuese poco útil, ya que sólo se podría modificar

el esquema si las clases no estuvieran pobladas.


�

111

La segunda solución, mejor desde el punto de vista de la prototipación de sistemas, tiene el inconveniente

de que hay que proporcionar los valores para las instancias de la subclase. Se ha optado por esta solución

ya que desde el punto de vista del modelado de sistemas, si las superclases definen unos atributos es

porque son importantes en la definición de los objetos, posiblemente permiten identificarlos, y,

probablemente, de ellos depende el comportamiento de sus instancias.

Para ello se han definido cuatro eventos que implementan cuatro posibles soluciones al problema de

proporcionar valor a las propiedades emergentes de las poblaciones existentes. El diseñador deberá

escoger, según el caso, cuál de ellos es más apropiado:

• Con makeSubClassTS a las instancias se les da el valor por defecto en función del tipo de datos

definido como dominio de los atributos.

• Con makeSubClassTSP se ejecuta una función de migración (Actions) definida por el diseñador

en cada una de las instancias que se encarga de asignar los valores adecuados a los atributos.

• Con makeSubClassTSV a todas las instancias se les proporciona los mismos valores para los

atributos emergentes. Dichos valores se pasan en el argumento AttList.

• Con makeSubClassTSVI se asigna a cada instancia un conjunto de valores diferenciado a sus

atributos emergentes, estos valores deben ser proporcionados por el diseñador cuando invoca este

servicio en el argumento AttList que, en este caso, será una lista de listas de valores de los atributos

emergentes.

A la superclase se le invoca el servicio makeSuperClassTS para notificarle que es superclase de la clase

en la que se ha invocado el servicio makeSubClassTS� y que, a partir de entonces, cuando en una de

sus instancias se invoque un evento con el mismo nombre que algún ��! de la especialización temporal, la

instancia deberá especializarse temporalmente.

&'(')'('('+'� " �� 8�� : � �� 7;

El evento "�� de las especializaciones temporales se llama unmakeSubClassTS y está definido en el

atributo destroy de la metaclase tempSpecialization_class.

�=��*��>@�"��?��)=�'�� $'�� $*��>�F�

Como se puede ver, el argumento del servicio que hace perder la especialización temporal a una instancia

de una especialización temporal es el identificador del metaobjeto.


�

�

112

Existen una serie de precondiciones que se deben satisfacer para poder llevar a cabo este servicio:

• no puede haber características de la especialización (ni de sus subclases si las tiene) que usen

características heredadas de la superclase:

• no se pueden utilizar atributos heredados en las fórmulas que definen las precondiciones de los

eventos, ni en la definición de la restricción de integridad, ni en las condiciones de activación de

los disparos, ni en las fórmulas de derivación de los atributos derivados, ni en las evaluaciones de

los eventos,

• tampoco se pueden usar eventos heredados en la definición de transacciones, ni disparos a self,

ni en el párrafo %��*

• si la clase es componente de una agregación, en la clase compuesta no se pueden utilizar propiedades

heredadas de la superclase para definir sus características (no puede haber expresiones de camino que

hagan referencia a propiedades heredadas de la clase que va a dejar de ser especializada),

• no puede haber definidos disparos a los eventos portadores en la superclase.

Al eliminar la relación de herencia la clase pierde todas las características emergentes por dejar de ser una

especialización temporal y las instancias de la clase pierden todas las características que eran heredadas

de la superclase.

Se elimina la relación de herencia existente entre la subclase y su superclase:

=�$'��77�$'%��>�"��

A la superclase se le invoca el servicio unmakeSuperClassTS para que conozca que deja de ser

superclase de la clase en la que se ha invocado el servicio unmakeSubClassTS.

&'(')'('('('� #��

B��'�� 1�

�=��*��>@��)��??��)=��5��$'%��*�@��P��F�>�F�

� �=��*��>@��) �%��??��) =��)=��5��$'%��*�@��P��F�>*�@��F�>�F�


�

113

Este servicio pasa la definición de un atributo constante o variable de la superclase a la subclase en la que

se invoca este servicio.

Como precondición se comprueba que AttName sea un atributo constante o variable heredado.

En la subclase se copia la definición del atributo de la superclase como propiedad emergente.

A la superclase se le invoca el servicio passAttDefinitionToSubClass para que elimine de su estado

local la definición del atributo AttName.

Se podrían definir más servicios con una semántica similar que trasladaran las definiciones por las

jerarquías de herencia, lo que haría más cómoda la herramienta para los usuarios.

- ��

El resto de servicios que vienen a continuación son los servicios que se han definido para las clases

elementales con el comportamiento redefinido para tener en cuenta que los metaobjetos que ofrecen

dichos servicios definen la plantilla de especializaciones temporales. Los servicios que no se mencionan a

continuación conservan la semántica dada para las clases elementales.

Por simplificación de la exposición sólo se mencionan aquellos aspectos relacionados con la característica

emergente de ser especialización temporal. Por lo tanto, la información que se proporciona a continuación

debe entenderse como una �� al comportamiento de los servicios descritos para la metaclase

elemental_class.

&'(')'('('&'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�P��F�>�F�

� �=��*��>@��) �%��??��) =��)=��0��P��*�@�P��F�>*�@��F�>�F�

A la superclase se le invoca el servicio subClassNameChanged para que actualice en su estado el

nombre de la subclase que ha cambiado de nombre.

&'(')'('('0'� �/��

B��'�� 1�


�

�

114

�=��*��>@��)��??��)=��""��*�@�P��*� �%��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%��F�>*�@��*�%��F�>�F�

�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*��F�>�F�

�=��*��>@�) �%��??�) =�)=�""��*@P��* �%�*��F>*@��*%��*��F>F�

�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*��'��F�>�F�

�=��*��>@��) �%��??��) =�)=�""��*�@�P��*� �%�*��'��F�>*@��*�%��*� �%��F�>�F�

�=��*��>@��)��??��)=��""��4*�@�P��*� �%�*��F�>�F�

�=��*��>@��) �%��??��) =�)=�""��4*�@�P��*� �%�*��F>*@��*�%��*��= �%�>F>�F�

El nombre del nuevo atributo no debe coincidir con el nombre de ningún atributo heredado ni con el

nombre de un atributo definido en ninguna otra subclase de otra rama de la jerarquía de herencia en la que

se encuentre la subclase para evitar conflictos si la herencia fuese no disjunta.

&'(')'('('1'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��F�>*�@��*�%��*� �%��F�>�F�

�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��*��F�>*� �

� � � � � � ��@��*�%��*� �%�*��F�>�F�

�

�=��*��>@��)��??��)=��""��$*�@�P��*� �%��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��$*�@�P��*� �%��F�>*�@��*�%��F�>�F�

�=��*��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��*��F�>*� � �

� � � � � � ��@��*�%��*� �%�*� �%�F�>�F�

�=��*��>@��)��??��)=��""��4*�@�P��*� �%�*�5��'��*��F�>�F�


�

115

�=��*��>@��) �%��??��) =�)=��""��4*�@�P��*� �%�*�5��'��*��F�>*� �

� � � � � � ��@��*�%��*� �%�*��= �%�>�F�>�F�

Al igual que pasa con los atributos constantes, no se puede definir un atributo variable en una

especialización si dicho nombre ya ha sido definido en alguna superclase o en alguna otra subclase de otra

rama de la raíz de la jerarquía de herencia en la que se encuentre la subclase sobre la que se invoca este

servicio.

&'(')'('(')'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""5��*�@�P��*� �%�*��F�>�F�

�=��*��>@�) �%��??�) =��)=�""5��*�@�P��*� �%�*��F�>*�@��*�%��*��'��F�>�F�

Al igual que los atributos constantes y variables el nombre no puede estar declarado en ninguna superclase

ni en ninguna otra subclase en otra rama de la raíz de la jerarquía de herencia en la que se encuentre la

subclase sobre la que se invoca este servicio.

Para determinar la consistencia de la fórmula por la que se calcula el valor de atributo derivado hay que

tener en cuenta que el conjunto de atributos válidos está formado por los definidos localmente

(emergentes) y por los heredados.

&'(')'('('3'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@�P��*� �%�*�P�!��F�>�F�

�=��*��>@��) �%��??�) =�)=�0��5��*@P��* �%�*P�!��F>*@��*%��*��'��F>�F�

Para determinar la consistencia de la fórmula de derivación hay que tener en cuenta, además de los

atributos emergentes, a los atributos heredados.

&'(')'('('4'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�


�

�

116

En la precondición se debe comprobar que el nuevo nombre del atributo no haya sido declarado en

ninguna superclase ni en ninguna otra subclase en otra rama de la raíz de la jerarquía de herencia en la que

se encuentre la subclase sobre la que se invoca este servicio.

&'(')'('('*5'� " ��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@��P��*��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@��P��*��F�>*�@��*��=��>�F�>�F�

Hay que comprobar que el nombre del alias no haya sido definido en ninguna superclase. En la lista de

atributos que forman el mecanismo de nombramiento pueden participar atributos constantes heredados.

&'(')'('('**'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�

Hay que comprobar que el nuevo nombre no ha sido ya usado como nombre de otro alias en ninguna de

las superclases.

&'(')'('('*+'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@��P��*�P�!5��F�>�F�

�=��*��>@��) �%��??��) =�)=��0��5��*�@��P��*�P�!5��F�>*�@��*��=��>F>F�

En la lista de atributos que definen el alias pueden participar los atributos constantes heredados.

&'(')'('('*('� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��F�>*�@��'��F�>�F�


�

117

Para determinar la consistencia de la restricción de integridad hay que tener en cuenta que se pueden

utilizar atributos heredados.

&'(')'('('*&'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""�)��*�@��)��*� �%��F*�>�F�

�=��*��>@��) �%��??�) =�)=��""�)��*�@��)��*� �%��F�>*�@��)��*��=%��>�F�>�F�

La precondición del servicio impide que se pueda añadir el evento en la clase si el nombre coincide con el

de algún evento "�� de las superclases o si existe un evento heredado o definido en una subclase de

otra rama de la jerarquía de herencia en la que se encuentra la clase con el mismo nombre y distinto

número de argumentos o si los tipos de los argumentos son menos generales.

&'(')'('('*0'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��)��*�@�3�)��*�P�)��*�P �%��F�>�F�

�=��*��>@�) �%��??�) =�)=�0��)��*@3�)��*P�)��*P �%��F>*� � �

� � � � � � ��@�)��*�)��*��=%��>F>F�

Sólo se puede cambiar el perfil de los eventos emergentes. No se puede cambiar el perfil si existe un

evento "�� definido en alguna superclase con el mismo nombre. Si existe un evento heredado o

definido en una subclase de otra rama de la jerarquía de herencia en la que se encuentra la clase con el

mismo nombre, el número de los argumentos debe ser el mismo y los tipos de los argumentos deben ser

los mismos o subtipos de los definidos.

&'(')'('('*1'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��)��*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��)��*��F�>*�@��)��*��'��F�>�F�

Para determinar la consistencia de la precondición hay que tener en cuenta que se pueden utilizar atributos

heredados.


�

�

118

&'(')'('('*)'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��)��*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��)��*��F�>*�@��)��*��F�>�F�

Los atributos heredados pueden ser modificados por la acción secuencial que determina la evaluación del

evento.

&'(')'('('*3'� �/�� 6

B��'�� 1�

�=��*��>@��)��??��)=��""P�!*�@��)��*� �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��""P�!*�@��)��*� �%��F�>*�@��)��*��=%��>�F�>�F�

Como precondición se debe comprobar que exista un evento definido en la superclase con el mismo

nombre (a través del cual se especializarán sus instancias).

&'(')'('('*4'� .�� 6

B��'�� 1�

�=��*��>@��)��??��)=��0��P�!*�@�3�"�)��*�P�!�)��*�P�! �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P�!*�@�3�"�)��*�P�!�)��*�P�! �%��F�>*� �

� � � � � � @��)��*��)��*��=%��>�F�>�F�

La precondición comprueba que el nuevo nombre del evento esté definido en la superclase (ya que será

éste el evento que especializará a las instancias de la superclase).

A la superclase se le invoca el servicio changeEvent para que actualice el nombre del evento antiguo por

el nuevo.

&'(')'('('+5'� �/�� 7

B��'�� 1�

�=��*��>@��)��??��)=��""5��*�@��)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��""5��*�@��)��P��F�>*�@��F�>�F�


�

119

Hay que comprobar que el nombre del evento "�� no esté definido en las superclases.

&'(')'('('+*'� .�� 7

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@��)��P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��5��*�@��)��P��F�>*�@��F�>�F�

Hay que comprobar que el nuevo nombre del evento no esté definido en las superclases.

&'(')'('('++'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��"" ��*�@� ��*� �%��F�>�F�

�=��*��>@��) �%��??��) =��)=��"" ��*�@� ��*� �%��F�>*� � �

� � � � � � @��*��=%��>�F�>�F�

No puede haber una transacción con el mismo nombre en ninguna subclase de las otras ramas de la

jerarquía de herencia en la que se encuentre la clase sobre la que se invoca este evento.

&'(')'('('+('� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� *�@�3 ��*�P ��*�P �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� *�@�3 ��*�P ��*�P �%��F�>*��

@��*��*��=%��>�F�>�F�

No puede haber una transacción con el mismo nombre en ninguna subclase de las otras ramas de la

jerarquía de herencia en la que se encuentre la clase sobre la que se invoca este evento.

&'(')'('('+&'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� "�*�@� ��*��"��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� "�*�@� ��*��"��F�>*��

��@��*��$��F�>�F�


�

�

120

El conjunto de los eventos que pueden participar en la transacción está formado por los heredados y los

emergentes.

&'(')'('('+0'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��"" ��*�@� ��F�>�F�

�=��*��>@��) �%��??��) =��)=��"" ��*�@� ��F�>*�@��F�>�F�

Los atributos heredados pueden ser usados para especificar la condición de activación del disparo.

&'(')'('('+1'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� *�@� ��*�P�!��"��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� *�@� ��*�P�!��"��F�>*��

@��*��'��F�>�F�

Como ya se ha comentado para definir la condición de especialización pueden intervenir los atributos

heredados.

&'(')'('('+)'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""��*�@�4��$��*��)��P��*��$��F�>�F�

�=��*��>@��) �%��??��) =�)=��""��*�@�4��$��*��)��P��*��$��F�>*� �

� � � � � ��@��*��*��F�>�F�

Para definir los procesos se pueden utilizar eventos definidos en las superclases.65

65 En OASIS se exige que la descripción de proceso de las subclases incluya a la descripción de proceso de la

superclase de manera que la restricción de una traza de un objeto especializado sobre los eventos definidos en la

superclase debe dar una traza válida para una instancia de la superclase. Se podría definir un atributo derivado en las


�

121

&'(')'('('+3'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*@4��$��*��)��P��*��$��*�P�!�)��F>F�

�=��*��>@�) �%��??��) =�)=�0��*@4��$��*�)��P��*��$��*P�!�)��F>*�

� � � � � ��@��*��*��*��F�>�F�

Al igual que en el servicio anterior, se pueden utilizar eventos heredados para definir el proceso.

especializaciones que comparase los procesos de la superclase y la subclase y determinase si la definición de proceso

de la subclase es compatible con la de la superclase.


�

�

122

&'(')'&'� �� -� ��8��,��

Los servicios que convierten a una clase en una especialización permanente se llaman

makeSubClassPS, makeSubClassPSP, makeSubClassPSV y makeSubClassPSVI, han sido

definidos como eventos propios en la superclase elemental_class y son los eventos ��! de la metaclase

permanentSpecialization_class. Cada uno de ellos resuelve de manera diferente los problemas de

migración existentes al definir relaciones de herencia.

Cuando un objeto es especializado permanentemente, el conjunto de propiedades está formado por las

propiedades heredadas definidas en las superclases y las propiedades emergentes definidas en la

especialización. En las especializaciones permanentes se exige compatibilidad de comportamiento y por

tanto no se permite redefinir los servicios heredados, pero sí se puede ampliar el comportamiento de los

eventos definiendo precondiciones complementarias y evaluaciones que modifiquen los atributos

emergentes.

Al igual que en las especializaciones temporales, la herencia se modela a través de hechos ��. Las

características propias de las especializaciones permanentes en OASIS se especifican a través de atributos

y transacciones ��.

&'(')'&'*'� #��

La metaclase permanentSpecialization_class, tal y como se vio en la Figura 14, es una especialización

temporal de la metaclase elemental_class:

�=��*%��>�77��=��*��>�

heredando todas las propiedades y servicios definidos en la clase elemental_class y redefiniendo los

servicios que sean necesarios. A continuación se muestra la plantilla �� emergente de la metaclase

permanentSpecialization_class.

�=��*�%��>@��"��$%��N?��'��F�

�=��*�%��>@�'%��N?��F��

�=��*%��>@��0�N??��F��

�=��*%��>@�)��0�N??�)��F��

�=��*%��>@�"��0�N??�"��F��


�

123

�=��*%��>@��0�N?��'��F��

�=��*%��>@��)��0�N??��)��F��

�=��*%��>@�0��"0�N??�0��"�F��

�=��*%��>@��0�N??��F��

�=��*%��>@��0�N??��F��

Los últimos 8 atributos se han definido con el objetivo de conocer cuáles son las propiedades heredadas

de la superclase.

Tal y como se define en OASIS, para especializar instancias de una superclase en una subclase

permanente se debe satisfacer una condición de especialización definida sobre atributos constantes

definidos en la superclase. La satisfacción o no de la condición de especialización se comprueba en

specializationNew en el instante de creación del objeto, de modo que si se satisface la condición de

especialización se especializa al objeto adquiriendo las propiedades y el comportamiento definido en la

subclase (ver página 243 para ver más detalles).

La plantilla y las propiedades de la clase permanentSpecialization_class está descrita en el estado del

metaobjeto o(om,ps_c). Como la clase permanentSpecialization_class es una especialización

temporal, el metaobjeto que define su plantilla es instancia de la clase que define las especializaciones

temporales:

�=��*%��>�7��=��*��>�

&'(')'&'+'� ��


permanentSpecialization_class. Como se puede observar, los atributos variables emergentes están

definidos en el atributo varAtt, los eventos emergentes y los redefinidos están definidos en event, etc.

�=��*%��>@��?�#%��$%��1��,�F�

�=��*%��>@�'%��?�#��,�F�

�=��*%��>@�)��??�G��=��"��$%�*��'��*� ��>*��=�'%��*��*� ��>�HF��

�=��*%��>@��!��??�G�� )=�� $'��$*��>*��

� �)=�� $'��$�*�@$'��*�$'%��F>*��

� �)=�� $'��$�*�@$'��*�$'%��F>*� � �

� �)=�� $'��$�4*�@$'��*�$'%��F>�H�F�


�

�

124

�=��*%��>@��)��??�G��)=�'%��P��0��"*�@P�!P��F>*� � � � �

�)=�0��P��"*�@3�"P��*�P�!P��F>*�

�)=�)��$��0��"4�$'%��*�@3�)��*�P�)��*� �%��F>*��HF�

��

De la misma forma que para las especializaciones temporales, dado un metaobjeto C instancia de la clase

permanentSpecialization_class, la regla deductiva a través de la cual se definen los atributos

constantes heredados de las superclases es la siguiente:

�@��0��??��F�←��7��=�*�%��>�M��77�$��M��WN�$��M�$�@��??��F��

�@��0��??��F�←��7��=�*�%��>�M��77�$��M��WN�$��M�$�@��0��??��F��

El resto de atributos derivados para las propiedades heredadas se define de la misma manera, excepto

constrainth que se define como la conjunción de las restricciones de las superclases.

&'(')'&'('� - ��

Los servicios que ofrecen las instancias de la metaclase permanentSpecialization_class son,

esencialmente, los mismos que ofrecen las clases elementales que permiten definir la plantilla OASIS de

las clases elementales más unos pocos emergentes. Algunos servicios que ofrecen las especializaciones

permanentes están redefinidos porque deben tener en cuenta, a la hora de especificar el tipo, las

características que vienen heredadas de sus superclases. A continuación se pueden ver los servicios

básicos de evolución y en el apéndice B los servicios auxiliares.

- ��9� � ��

66 En el punto 4.3.7.4.3 se pueden ver con detalle todos los servicios emergentes y redefinidos de

permanentSpecializacion_class.


�

125

&'(')'&'('*'� .� �� 8�� : � �� 6;

Los eventos ��! de las especializaciones permanentes están definidos en el atributo new del metaobjeto

permanentSpecialization_class.

�=��*%��>@��!��??�G� � �)=�� $'��$*��>*��

� �)=�� $'��$�*�@$'��*�$'%��F>*��

� �)=�� $'��$�*�@$'��*�$'%��F>*� � �

� �)=�� $'��$�4*�@$'��*�$'%��F>�H�F�

El primer argumento de los eventos debe ser el metaobjeto a especializar, después, los valores de las

propiedades emergentes (que en este caso serán la condición de especialización y el nombre de la

superclase) y finalmente, los argumentos necesarios en función del servio invocado (SubActions y

SuperActions o SubAttList y SuperAttList).

Existen ciertas restricciones a la hora de definir una subclase especialización permanente de otra clase que

deben ser comprobadas como precondición del servicio:

• No se deben introducir ciclos en el grafo de relaciones ��.

• Como se ha comentado en el evento makeSubClassTS� no se permite la definición de

especializaciones permanentes a partir de especializaciones temporales.

• No pueden existir atributos con el mismo nombre en las subclases que los definidos en la superclase.

Para modelar que la clase SubClass sobre la que se invoca este evento, es subclase de SuperClass se

inserta la relación �� entre las clases:

=�$'��77�$'%��>��

siendo SubClass y SuperClass los identificadores de los metaobjetos que definen las clases.

Las instancias de la subclase que existieran antes de la creación de la relación de herencia adquieren en un

instante unas propiedades heredadas a las que se les debe dar valor. La solución adoptada es la misma que

se ha comentado para las especializaciones temporales implementada por los cuatros servicios ��!�

definidos.

Las instancias de la subclase deben todas satisfacer la condición de especialización definida (Condition).

Las instancias de la subclase que no satisfagan dicha condición pierden su condición de ser instancias de


�

�

126

la subclase (perdiendo el estado y los servicios emergentes definidos en la subclase). Como es el

diseñador el que define la condición de especialización y el que proporciona los valores de las

propiedades heredadas para las instancias de la subclase, puede proporcionar los valores adecuados para

que satisfagan la condición de especialización y que no se produzca ninguna migración. O por el contrario

podría proporcionar unos valores tales que ninguna instancia de la subclase satisfaciera la condición de

especialización pasando todas a ser instancias de la superclase.

A la superclase se le invoca el servicio makeSuperClassPS� para indicarle que es superclase de

aquélla en la que se ha invocado el servicio makeSubClassPS� y que las instancias que satisfagan la

condición de especialización deben especializarse (se le pasa el argumento SuperActions o SuperAttList

para dar valor a las propiedades emergentes de las instancias de la superclase que deban especializarse) y

que a partir de entonces, cuando se cree una nueva instancia se debe comprobar si se satisface la

condición de especialización.

&'(')'&'('+'� " �� 8�� : � �� 7;

El evento "�� de las especializaciones permanentes se llama unmakeSubClassPS y está definido en

el atributo destroy de la clase permanentSpecialization_class.

�=��*%��>@�"��?��)=�'�� $'��$*��>�F�

El argumento del servicio que hace perder la especialización temporal es el identificador del objeto.67

Existen una serie de precondiciones que se deben satisfacer para poder llevar a cabo este servicio:

• no puede haber características de la especialización (ni de sus subclases si las tiene) que usen

características heredadas de la superclase:

• no se pueden utilizar atributos heredados en las fórmulas que definen las precondiciones de los

eventos, ni en la definición de la restricción de integridad, ni en las condiciones de activación de

67 Aunque se vaya a eliminar una relación de especialización permanente, el metaobjeto sobre el cual se invoca el

servicio, fue especializado temporalmente cuando se definió que con su estado representaba la plantilla de una

especialización permanente. Por lo tanto, ahora que va a dejar de representar a una especialización permanente, el

metaobjeto va a dejar de estar especializado temporalmente en la clase permanentSpecialization_class.


�

127

los disparos, ni en las fórmulas de derivación de los atributos derivados, ni en las evaluaciones de

los eventos,

• ni usar eventos heredados en la definición de transacciones, ni disparos a self, ni en el párrafo

%��,

• si la clase es componente de una agregación, en la clase compuesta no se pueden utilizar propiedades

heredadas de la superclase para definir sus características: no puede haber expresiones de camino que

hagan referencia a propiedades heredadas de la clase que va a dejar de ser especializada.

Al eliminar la relación de herencia, la clase pierde todas las características emergentes por dejar de ser

una especialización permanente y las instancias de la clase pierden todas las características que eran

heredadas de la superclase.

Se elimina la relación de herencia existente entre la subclase y su superclase.

=�$'��77�$'%��>�"��

A la superclase se le invoca el servicio unmakeSuperClassPS para que conozca que deja de ser

superclase de la clase en la que se ha invocado el servicio unmakeSubClassPS.

&'(')'&'('('� .�� 8��

B��'�� 1�

�=��*%��>@��)��??�)=��0��"��$%�*�@P�!��"F>F�

�=��*%��>@��) �%��??��)=��0��"��$%�*�@P�!��"F>*@��'��F�>�F�

�=��*%��>@��)��??�)=��0��"��$%��*�@P�!��"*��F>F�

�=��*%��>@��) �%��??��)=��0��"��$%��*@P�!��"*��F>*@��'��*��F>F�

�=��*%��>@��)��??�)=��0��"��$%��*�@P�!��"*��F>F�

�=��*%��>@��) �%��??��)=��0��"��$%��*�@P�!��"*��F>*@��'��*��=�>�F�>�F�

�=��*%��>@��)��??�)=��0��"��$%��4*�@P�!��"*��F>F�

�=��*%��>@��) �%��??��)=��0��"��$%��4*�@P�!��"*��F>*@��'��*��=��=�>>�F>F�

Para poder cambiar la condición de especialización, ésta debe estar basada sobre atributos constantes

heredados en la subclase.


�

�

128

La evaluación de este servicio modifica el valor del atributo conditionSpe.

Al cambiar la condición de especialización, es posible que algunos de los objetos que estaban

especializados deban dejar de estarlo porque ya no satisfagan la condición de especialización. La

evaluación de este servicio evalúa la condición sobre todas las instancias de la subclase y, en el caso de

que no la cumplan, dejan de ser instancias de la subclase de forma similar a como la invocación del

servicio "�� sobre objetos especializados temporalmente hace que pierdan las propiedades y el

comportamiento especializado.

Se comunica a la superclase que ha cambiado la condición de especialización de la clase invocando el

servicio conditionSpeChanged� , donde � es el sufijo de los eventos anteriores, porque puede que

alguna de las instancias de la superclase deba especializarse al satisfacer la nueva condición de

especialización. Para dar valores a las propiedades emergentes de las instancias que se especializarán se

pasan los argumentos Actions o AttList dependiendo del servicio.

- ��

Los servicios que vienen a continuación son redefiniciones de los servicios definidos para las clases

elementales teniendo en cuenta que los metaobjetos que ofrecen dichos servicios son especializaciones

permanentes. Los servicios heredados que no se mencionan a continuación conservan la semántica dada

para las clases elementales.

Al igual que en la descripción de los servicios redefinidos de la metaclase

temporalSpecialization_class, sólo se mencionan aquellos aspectos relacionados con la característica

emergente de ser especialización permanente. Por lo tanto, la información que se proporciona a

continuación debe entenderse como una �� al comportamiento de los servicios descritos para la

metaclase elemental_class.

&'(')'&'('&'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��P��*�@�P��F�>�F�

� �=��*%��>@��) �%��??��) =��)=��0��P��*�@�P��F�>*�@��F�>�F�


�

129

A la superclase se le invoca el servicio subClassNameChanged para que actualice el nombre de la

subclase que ha cambiado.

&'(')'&'('0'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��""��*�@�P��*� �%��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��*�@�P��*� �%��F�>*�@��*�%��F�>�F�

�=��*%��>@��)��??��)=��""��*�@�P��*� �%�*��F�>�F�

�=��*%��>@�) �%��??�) =�)=�""��*@P��* �%�*��F>*@��*%��*��F>F�

�=��*%��>@��)��??��)=��""��*�@�P��*� �%�*��'��F�>�F�

�=��*%��>@��) �%��??��) =�)=�""��*�@�P��*� �%�*��'��F�>*@��*�%��*� �%��F�>�F�

�=��*%��>@��)��??��)=��""��4*�@�P��*� �%�*��F�>�F�

�=��*%��>@��) �%��??��) =�)=�""��4*�@�P��*� �%�*��F>*@��*�%��*��= �%�>F>F�

No se puede definir un atributo con el mismo nombre que otro heredado ni definido en ninguna subclase

perteneciente a otra rama de la jerarquía de herencia en la que se encuentre la subclase sobre la que se

invoca este servicio para evitar conflictos en el caso de que la jerarquía de herencia fuese no disjunta.

&'(')'&'('1'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��*@�P��*� �%�*�5��'��F>*�@��*�%��*� �%��F�>�F�

�=��*%��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��*��F�>*��

� � � � � � ��@��*�%��*� �%�*��F�>�F�

�=��*%��>@��)��??��)=��""��$*�@�P��*� �%��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��$*�@�P��*� �%��F�>*�@��*�%��F�>�F�

�=��*%��>@��)��??��)=��""��*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��*�@�P��*� �%�*�5��'��*��F�>*� � �

� � � � � � ��@��*�%��*� �%�*� �%�F�>�F�


�

�

130

�=��*%��>@��)��??��)=��""��4*�@�P��*� �%�*�5��'��*��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��4*�@�P��*� �%�*�5��'��*��F�>*� �

� � � � � � ��@��*�%��*� �%�*��= �%�>�F�>�F�

Al igual que con los atributos constantes, el nombre del atributo tiene que ser diferente al de los atributos

heredados y al de los definidos en las subclases pertenecientes a otras ramas de la jerarquía de herencia en

la que se encuentre la subclase sobre la que se invoca este servicio.

&'(')'&'(')'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��""5��*�@�P��*� �%�*��F�>�F�

�=��*%��>@�) �%��??�) =��)=�""5��*@�P��*� �%�*��F�>*�@��*�%��*��'��F�>�F�

Como en los anteriores eventos, el nombre tiene que ser distinto del nombre de los atributos heredados y

al de los definidos en las subclases pertenecientes a otras ramas de la jerarquía de herencia en la que se

encuentre la subclase sobre la que se invoca este servicio.

Para determinar la consistencia de la fórmula de derivación hay que tener en cuenta que se pueden usar los

atributos heredados para definirla.

&'(')'&'('3'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��5��*�@�P��*� �%�*�P�!��F�>�F�

�=��*%��>@��) �%��??�) =�)=�0��5��*@P��* �%�*P�!��F>*@��*%��*��'��F>�F�

Para determinar la consistencia de la fórmula de derivación hay que tener en cuenta a los atributos

heredados.

&'(')'&'('4'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�


�

131

El nuevo nombre no puede coincidir con el de un atributo heredado ni con el de los definidos en las

subclases pertenecientes a otras ramas de la jerarquía de herencia en la que se encuentre la subclase sobre

la que se invoca este servicio.

&'(')'&'('*5'� " ��

B��'�� 1�

�=��*%��>@��)��??��)=��""��*�@��P��*��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��*�@��P��*��F�>*�@��*��=��>�F�>�F�

El nombre del alias no debe ser usado en ninguna superclase. En la lista de atributos que definen el alias

pueden participar atributos constantes heredados.

&'(')'&'('**'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�

El nuevo nombre no puede coincidir con el nombre dado a algún alias en alguna superclase.

&'(')'&'('*+'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��5��*�@��P��*�P�!5��F�>�F�

�=��*%��>@��) �%��??��) =�)=��0��5��*�@��P��*�P�!5��F�>*��

� � � � � � ��@��*��=��>F>F�

En la lista de atributos que definen el alias pueden participar atributos constantes heredados.

&'(')'&'('*('� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��*�@��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��*�@��F�>*�@��'��F�>�F�


�

�

132

Los atributos heredados pueden participar en la fórmula que define la restricción de integridad definida

para las instancias de la clase.

&'(')'&'('*&'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��""�)��*�@��)��*� �%��F*�>�F�

�=��*%��>@��) �%��??�) =�)=��""�)��*�@��)��*� �%��F�>*�@��)��*��=%��>�F�>�F�

La precondición del servicio impide que se pueda añadir el evento si el nombre coincide con el de algún

evento ��! o "�� de las superclases o si existe un evento heredado o definido en alguna subclase

perteneciente a otra rama de la jerarquía de herencia a la que pertenece la subclase sobre la que se invoca

este servicio, con el mismo nombre y distinto número de argumentos o si los tipos de los argumentos son

menos generales.

&'(')'&'('*0'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��)��*�@�3�)��*�P�)��*�P �%��F�>�F�

�=��*%��>@�) �%��??�) =�)=�0��)��*@3�)��*P�)��*P �%��F>*� � �

� � � � � � ��@�)��*�)��*��=%��>F>F�

Sólo se puede cambiar el perfil de los eventos emergentes. No se puede cambiar el perfil si existe un

evento ��! o "��definido en alguna superclase con el mismo nombre. Si existe un evento heredado o

definido en una subclase de otra rama de la jerarquía de herencia en la que se encuentra la clase con el

mismo nombre, el número de los argumentos debe ser el mismo y los tipos de los argumentos deben ser

los mismos o subtipos de los definidos.

&'(')'&'('*1'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��*�@��)��*��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��*�@��)��*��F�>*�@��)��*��'��F�>�F�


�

133

En la fórmula que define la precondición se pueden usar atributos heredados.

&'(')'&'('*)'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0��*�@��)��*��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��*�@��)��*��F�>*�@��)��*��F�>�F�

En la evaluación sólo se puede modificar los atributos emergentes.

&'(')'&'('*3'� �/�� 6

B��'�� 1�

�=��*%��>@��)��??��)=��""P�!*�@��)��*��)��*� �%��F�>�F�

�=��*%��>@��) �%��??�) =�)=��""P�!*�@��)��*��)��*� �%��F�>*�@��)��*��)��*��=%��>�F�>�F�

Hay que comprobar que el nombre del evento ��! sea distinto de cualquier otro evento heredado.

&'(')'&'('*4'� .�� 6

B��'�� 1�

�=��*%��>@��)��??��)=��0��P�!*�@�3�"�)��*�P�!�)��*�P�! �%��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��P�!*�@�3�"�)��*�P�!�)��*�P�! �%��F�>*� �

� � � � � � @��)��*��)��*��=%��>�F�>�F�

No se puede cambiar el nombre si el nuevo nombre está ya definido en alguna de las superclases.

&'(')'&'('+5'� �/�� 7

B��'�� 1�

�=��*%��>@��)��??��)=��""5��*�@�P�)��F�>�F�

�=��*%��>@��) �%��??�) =�)=��""5��*�@�P�)��F�>*�@��)��F�>�F�

La precondición del servicio impide que se pueda añadir el servicio si dicho nombre está ya definido en

alguna de las superclases.


�

�

134

&'(')'&'('+*'� .�� 7

B��'�� 1�

�=��*%��>@��)��??��)=��0��5��*�@��)��P��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0��5��*�@��)��P��F�>*�@��F�>�F�

No se puede cambiar el nombre si el nuevo nombre está definido en alguna de las superclases.

&'(')'&'('++'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��"" ��*�@� ��*� �%��F�>�F�

�=��*%��>@��) �%��??��) =��)=��"" ��*�@� ��*� �%��F�>*� � �

� � � � � � @��*��=%��>�F�>�F�

La precondición del servicio impide que se pueda añadir la nueva transacción si dicho nombre está ya

definido en alguna superclase. Tampoco puede haber una transacción con el mismo nombre en ninguna

subclase de las otras ramas de la jerarquía de herencia en la que se encuentre la clase sobre la que se

invoca este evento.

&'(')'&'('+('� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0�� *�@�3 ��*�P ��*�P �%��F�>�F�

�=��*%��>@��) �%��??�) =�)=��0�� *�@�3 ��*�P ��*�P �%��F�>*��

@��*��*��=%��>�F�>�F�

No se puede cambiar el perfil si el nuevo nombre coincide con el de otra transacción definida en alguna

superclase, ni puede haber una transacción con el mismo nombre en ninguna subclase de las otras ramas

de la jerarquía de herencia en la que se encuentre la clase sobre la que se invoca este evento.

&'(')'&'('+&'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0�� "�*�@� ��*��"��F�>�F�


�

135

�=��*%��>@��) �%��??�) =�)=��0�� "�*�@� ��*��"��F�>*��

��@��*��$��F�>�F�

El conjunto de eventos que se pueden usar para definir el cuerpo de la transacción está formado por los

emergentes y los heredados.

&'(')'&'('+0'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��"" ��*�@� ��F�>�F�

�=��*%��>@��) �%��??��) =��)=��"" ��*�@� ��F�>*�@��F�>�F�

Para determinar la condición de activación se pueden utilizar atributos heredados.

&'(')'&'('+1'� .��

B��'�� 1�

�=��*%��>@��)��??��)=��0�� *�@� ��*�P�!��"F�>�F�

�=��*%��>@��) �%��??�) =�)=��0�� *�@� ��*�P�!��"F�>*�@��*��'��F�>�F�

Los atributos heredados pueden formar parte de la condición de activación del disparo.

&'(')'&'('+)'� �/��

B��'�� 1�

�=��*%��>@��)��??��)=��""��*�@�4��$��*��)��P��*��$��F�>�F�

�=��*%��>@��) �%��??��) =�)=��""��*�@�4��$��*��)��P��*��$��F�>*� �

� � � � � ��@��*��*��F�>�F�

Los eventos heredados pueden formar parte de la descripción de proceso de la clase.

&'(')'&'('+3'� .��

B��'�� 1�

�=��*%��>@��)��??�)=��0��*�@�4��$��*��)��P��*��$��*�P�!�)��F>F�

�=��*%��>@�) �%��??�) =�)=�0��*@4��$��*�)��P��*��$��*P�!�)��F>*�

� � � � � ��@��*��*��*��F�>�F�


�

�

136

Como en el servicio anterior, el proceso puede definirse haciendo uso de los eventos heredados.


�

137

&'(')'0'� �� ,��

El servicio que convierte a una clase en una agregación se llama makeAgg, es el evento ��! de la clase

aggregation_class, y ha sido definido como evento propio en la superclase elemental_class.

Cuando se define una relación de agregación entre dos clases, el comportamiento de sus instancias se ve

condicionado por el tipo de relación (con sus cardinalidades) que se defina entre las clases. Esto queda

reflejado en las transacciones que implementan los servicios de animación de las especificaciones que

dependen de si la clase es o no componente de una agregación (ver apéndice D).

Las precondiciones, restricciones de integridad, fórmulas de derivación y condiciones de activación de

disparos de un objeto compuesto pueden acceder al estado de sus componentes. Además, se pueden

definir transacciones que invoquen eventos definidos en sus componentes.

La relación de agregación que se define entre los objetos compuestos y sus componentes queda

caracterizada por las siguientes dimensiones:

• Relacional o inclusiva: Si la relación es inclusiva los componentes no pueden existir fuera del

compuesto, estando totalmente encapsulados. La agregación relacional sólo denota que existe una

relación entre los objetos, pudiendo las instancias de las clases componentes existir

independientemente de los compuestos68.

• Estática o dinámica: En las agregaciones estáticas los componentes de una relación no pueden

cambiar una vez definidos. Las agregaciones dinámicas disponen de eventos de inserción y borrado69

de componentes de la relación que permiten cambiarlos.

• Unievaluada o multievaluada: En una agregación unievaluada cada objeto compuesto puede estar

relacionado como máximo con un objeto componente, mientras que en una relación multievaluada un

compuesto puede estar relacionada con muchos componentes.

68 Aunque en las agregaciones relacionales no tiene sentido hablar de clases componentes o compuestas, puesto que

no existe dicha relación de composición, se llama clase compuesta a la clase en la que se define la agregación

relacional y componente a la relacionada con la primera.

69 El nombre por defecto de los eventos de inserción y borrado es: insertComp y remComp (ver apéndice D).


�

�

138

• Disjunta o no disjunta: Si la agregación es no disjunta, los componentes pueden formar parte de

diferentes objetos compuestos.

• Flexible o estricta: En una agregación flexible los componentes pueden existir con independencia de

si están relacionados o no a un agregado. En una relación estricta los componentes sólo pueden existir

si están relacionados con algún objeto compuesto.

• Permite nulos o no los permite: Si se permiten nulos, los objetos compuestos pueden no estar

relacionados con ningún componente.

Fundamentalmente, las características anteriores son importantes para la animación de los sistemas,

aunque algunas tienen su importancia a la hora de hacer modificaciones en el esquema, tal y como

veremos a continuación.

Los objetos instancia de clases compuestas mantienen información de los objetos con los que están

relacionados a través de un atributo llamado component gestionado de forma automática por los

servicios de creación de instancias y los de inserción y borrado de componentes de una agregación (si

ésta es dinámica). De forma dual, los componentes de agregación relacionales también mantienen

información sobre los objetos con los que están relacionados en un atributo llamado partOf gestionado de

forma automática por las transacciones �� que permiten animar los esquemas (ver animación de

especificaciones OASIS en el apéndice D).

&'(')'0'*'� #��

La metaclase aggregation_class, tal y como se vio en la Figura 14, es una especialización temporal de la

metaclase elemental_class, de forma que hereda todas las propiedades y servicios definidos en la

metaclase elemental_class, redefiniendo los servicios que sean necesarios.

�=��*��>�77��=��*��>�

La definición de los siguientes atributos constituye la plantilla �� emergente de la metaclase

aggregation_class.

�=��*��>@��%��N??��%��F�

�=��*��>@�'��=��*��>�N?��F�


�

139

Como en la definición de la plantilla de las clases agregadas se puede consultar el estado de los

componentes de la agregación y no se permite eliminar un atributo si está siendo usado para definir otras

clases, las instancias de la metaclase aggregation_class disponen del atributo derivado useAtt(Class,

AttName), que comprueba si en la definición de la clase compuesta se usa el nombre de atributo

AttName de la clase componente Class en alguna expresión de camino en las fórmulas que definen las

precondiciones, las restricciones de integridad, las fórmulas de derivación o las condiciones de activación

de disparos.�

La plantilla y las propiedades de las clases compuestas están descritas en el estado del metaobjeto

o(om,a_c). Como la clase aggregation_class es una especialización temporal, el metaobjeto que define

su plantilla es instancia de la clase que define las especializaciones temporales.

�=��*��>�7��=��*��>�

&'(')'0'+'� ��

A continuación se muestran los valores de los atributos más importantes del metaobjeto que define la

especificación de la metaclase aggregation_class. Como se puede observar, los atributos variables

emergentes están definidos en el atributo varAtt, los eventos emergentes y los redefinidos están definidos

en event, etc.

�=��*��>@��?�#��,�F�

�=��*��>@�'%��?�#��,�F�

�=��*��>@�)��??�G��=��%��*��%��>�HF��

�=��*��>@��!��??��)=�� *��>�F�

�=��*��>@��)��??�G�� )=��""��%*�@��P��*��P��F>*��

� �)=��0��P��*�@3�"P��*�P�!P��F>*��H�F�

��

&'(')'0'('� - ��

El conjunto de servicios que ofrecen los metaobjetos especializados temporalmente en la metaclase

aggregation_class está formado por los eventos heredados y los redefinidos de la metaclase

70 En 4.3.7.5.3 se puede ver con detalle los servicios emergentes y redefinidos para aggregation_class.


�

�

140

elemental_class y los eventos emergentes necesarios para especificar las características emergentes. A

continuación se muestran los servicios básicos. Los servicios auxiliares pueden verse en el apéndice B.

- ��9� � ��

&'(')'0'('*'� .�� : � �� 6;

El evento ��! de las clases compuestas se llama makeAgg y está definido en el atributo new del

metaobjeto aggregation_class:

�=��*��>@��!��??��)=�� *��>�F�

Por el modelo de ejecución mostrado en la página 245, se asume que el primer argumento del evento que

especializa a las instancias es el oid del objeto a especializar y el resto son los valores de las propiedades

emergentes. En este no hay que pasar valores para las propiedades emergentes ya que el atributo

componentClass se inicializa al conjunto vacío indicando que la clase no tiene componentes.

Las instancias de la clase que existieran antes de convertirla en clase compuesta no necesitan sufrir

ninguna modificación ni relacionarse con otros objetos ya que inicialmente la agregación no tiene

componentes.

&'(')'0'('+'� " �� : � �� 7;

El evento "�� de las clases compuestas se llama unmakeAgg y está definido en el atributo destroy

del metaobjeto aggregation_class.

�=��*��>@�"��?��)=�'�� *��>�F�

El argumento del servicio que hace perder la especialización a las instancias de especializaciones

temporales es el identificador del objeto.71

71 Aunque el objetivo de este servicio consiste en que una clase deje de ser clase compuesta, el metaobjeto sobre el

cual se invoca el servicio, fue especializado temporalmente cuando se definió que con su estado representaba la


�

141

Para poder llevar a cabo este servicio, es necesario que la clase en la que se invoca no tenga ningún

componente (es necesario, pues, eliminar antes los componentes).

Al dejar de ser una clase compuesta, la clase pierde todas las características emergentes (en este caso el

atributo componentClass) y deja de ofertar los servicios emergentes que permitían expresar las

características de ser una agregación.

&'(')'0'('('� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""��%*�@��P��*��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��""��%*�@��P��*��P��F>*@��*��F>F�

Con este evento se expresa que la clase ClasName formará parte como componente de la clase sobre la

que se invoca este servicio. El nombre de la relación que se establece entre la clase compuesta y la clase

componente se llama RelationName.

El nombre que se le va a dar a la relación entre las clases no puede haber sido definido con anterioridad.

Las características por defecto de la relación que une la clase compuesta con la componente son las

siguientes: relacional, dinámica, multievaluada, no disjunta, flexible y permite nulos.�Estas propiedades

han sido escogidas buscando que las posibles instancias que pueblen las clases no tengan por qué sufrir

ninguna modificación al definirse la relación entre la clase compuesta y la componente. Más adelante, se

puede hacer uso de los eventos de inserción y borrado de componentes de que disponen las agregaciones

dinámicas para relacionar los objetos compuestos con los componentes. En el caso de que la relación

entre las clases no tuviera las propiedades por defecto, se pueden invocar los servicios que modifican las

propiedades para ajustarlas al valor deseado (descritas un poco más adelante).

A la clase ClassName definida como componente de la clase compuesta se le invoca el servicio

makeComp para que “sepa” que forma parte de una agregación con las propiedades por defecto.

plantilla de una clase compuesta. Por lo tanto, ahora que va a dejar de representar a una clase compuesta, el

metaobjeto va a dejar de estar especializado temporalmente en la clase aggregation_class.


�

�

142

&'(')'0'('&'� .�� 7��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@3�"P��*�P�!P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0��P��*@3�"P��*�P�!P��F>*@��*��F>F�

Como precondición se comprueba que el nuevo nombre no esté ya definido como relación con otra clase

componente.

Este servicio cambia el nombre en el atributo componentClass. Además, todas las instancias de la clase

compuesta actualizan en su estado el nombre de la relación que ha cambiado.

A la clase componente se le invoca el servicio relationNameChanged para que cambie el nombre de la

relación en la que participa.

&'(')'0'('0'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� *�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� *�@��P��F�>*@��F>F�

Al invocar este servicio la agregación pasa a ser relacional.

Un cambio de estas características no afecta (con respecto a la evolución) a las instancias que pudiera

haber en las clases compuesta y componente: los objetos compuestos siguen estando relacionados con los

componentes y viceversa y los que no estuvieran relacionados tampoco lo estarán. Sí afecta a la animación

de los esquemas, porque desde este momento se podrá acceder a las instancias de la clase componente sin

tener que pasar por el objeto compuesto.

Se modifica el atributo componentClass para reflejar que ahora la agregación es relacional.

A la clase componente se le invoca el servicio relationChangedToRelational para comunicarle que

cambia el tipo de agregación en la que participa.

&'(')'0'('1'� .��

B��'�� 1�


�

143

�=��*��>@��)��??��)=��0�� 4��'�)�*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� 4��'�)�*�@��P��F�>*@��F>F�

Al invocar este servicio la agregación pasa a ser inclusiva.

Como en el caso anterior, un cambio de estas características no afecta (con respecto a la evolución) a las

instancias que pudieran haber en las clases compuesta y componente. Desde el punto de vista de la

animación sólo se podrá acceder a las instancias de la clase componente desde las instancias de la clase

compuesta. Las instancias de la clase componente que no estén relacionadas en el instante en que se

invoque este servicio no serán accesibles al no haber un compuesto con el que estén relacionadas.

Se modifica el atributo componentClass para reflejar que ahora la agregación es inclusiva.

A la clase componente se le invoca el servicio relationChangedToInclusive.

&'(')'0'(')'� .�� <��<��

B��'�� 1�

�=��*��>@��)��??��)=��0�� 5��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=�0�� 5��*�@��P��F�>*@��F>F�

Al invocar este servicio la agregación pasa a ser dinámica.

Un cambio de estas características tampoco afecta (con respecto a la evolución) a las instancias que

pudieran haber en las clases compuesta y componente. Desde el punto de vista de la animación será

posible invocar los eventos de inserción y borrado de componentes en los objetos compuestos para

cambiarlos.

Se modifica el atributo componentClass para reflejar que ahora la agregación es dinámica.

A la clase componente se le invoca el servicio relationChangedToDynamic.

&'(')'0'('3'� .�� <�� <��

B��'�� 1�

�=��*��>@��)��??��)=��0�� $��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=�0�� $��*�@��P��F�>*@��F>F�


�

�

144

Al invocar este servicio la agregación pasa a ser estática.

Un cambio de estas características no afecta (con respecto a la evolución) a las instancias que pudieran

haber en las clases compuesta y componente. Desde el punto de vista de la animación ya no se podrán

invocar los eventos de inserción y borrado de componentes en los objetos compuestos, quedándose la

agregación en el estado correspondiente al instante de invocación de este servicio.

Se modifica el atributo componentClass para reflejar que ahora la agregación es estática.

A la clase componente se le invoca el servicio relationChangedToStatic.

&'(')'0'('4'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� '��)��'�"*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0��" ��'��)��'�"*�@��P��F�>*@��F>F�

Al invocar este servicio pasa a ser multievaluada.

Un cambio de estas características no afecta (con respecto a la evolución) a las instancias que pudiera

haber en las clases compuesta y componente. Desde el punto de vista de la animación de las

especificaciones será posible que un objeto compuesto esté formado por varias instancias de la misma

clase componente.

Se modifica el atributo componentClass para reflejar que ahora la agregación es multievaluada.

A la clase componente se le invoca el servicio relationChangedToMultievalued.

&'(')'0'('*5'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� )��'�"*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0��" ��)��'�"*�@��P��F�>*@��F>F�

Al invocar este servicio pasa a ser unievaluada.


�

145

Para poder realizar este servicio las instancias de la clase compuesta no pueden estar relacionadas con más

de un objeto componente (ya que esto es lo que se exige al cambiar a unievaluada). El diseñador tendrá

que eliminar esa posible inconsistencia: bien eliminando los objetos compuestos con múltiples

componentes, bien destruyendo los objetos componentes, o bien eliminando componentes de la relación

haciendo uso del servicio de borrado de componentes si la agregación es dinámica. Desde el punto de

vista de la animación ya no será posible que un objeto compuesto esté formado por varias instancias de la

misma clase componente.

Se modifica el atributo componentClass para reflejar que ahora la agregación es unievaluada.

A la clase componente se le invoca el servicio relationChangedToUnievalued.

&'(')'0'('**'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� P��5�.��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� P��5�.��*�@��P��F�>*@��F>F�

Al invocar este servicio pasa a ser no disjunta.


haber en las clases compuesta y componente. Desde el punto de vista de la animación será posible que un

objeto componente sea compartido por varios objetos compuestos.

Se modifica el atributo componentClass para reflejar que ahora la agregación es no disjunta.

A la clase componente se le invoca el servicio relationChangedToNotDisjoint.

&'(')'0'('*+'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� 5�.��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� 5�.��*�@��P��F�>*@��F>F�

Al invocar este servicio pasa a ser disjunta.

Para poder realizar este servicio las instancias de la clase componente no pueden estar relacionadas con

más de un objeto compuesto (ya que esto es lo que se exige al cambiar a disjunta). El diseñador tendrá


�

�

146

que eliminar esa posible inconsistencia: bien eliminando los objetos componentes relacionados con

múltiples compuestos, bien destruyendo los objetos compuestos que estén relacionados con el mismo

componente, o bien eliminando componentes de las relaciones haciendo uso del servicio de borrado de

componentes si la agregación es dinámica. Desde el punto de vista de la animación ya no será posible que

un objeto componente esté relacionado con varios objetos compuestos.

Se modifica el atributo componentClass para reflejar que ahora la agregación es disjunta.

A la clase componente se le invoca el servicio relationChangedToDisjoint.

&'(')'0'('*('� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� $��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� $��*�@��P��F�>*@��F>F�

Al invocar este servicio la agregación pasa a ser estricta.

Las instancias de la clase componente deben estar relacionadas, necesariamente, con algún objeto

compuesto. En caso negativo, el diseñador deberá eliminar las instancias de la clase componente que no

estén relacionadas con ningún objeto compuesto72 o relacionarlas con algún objeto compuesto invocando

los servicios de inserción de componentes en clases compuestas si éstas son dinámicas, para no incurrir en

inconsistencias. Desde el punto de vista de la animación no será posible crear objetos instancias de la

clase componente si estos no se relacionan con algún objeto compuesto y cuando se destruya el objeto

compuesto se destruirán los componentes inclusivos.

Se modifica el atributo componentClass para reflejar que ahora la agregación es estricta.

A la clase componente se le invoca el servicio relationChangedToStrict.

72 Aunque, de forma alternativa, se podría asumir dicho comportamiento como parte de la valuación de este servicio y

eliminar de forma automática las instancias de la clase componente no relacionadas con ningún objeto compuesto.


�

147

&'(')'0'('*&'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� 2��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� 2��*�@��P��F�>*@��F>F�

Al invocar este servicio la agregación pasa a ser flexible.


haber en las clases compuesta y componente. Los objetos compuestos siguen estando relacionados con los

componentes y viceversa. Desde el punto de vista de la animación será posible que objetos instancias de

la clase componente no estén relacionados con ningún objeto compuesto.

Se modifica el atributo componentClass para reflejar que ahora la agregación es flexible.

A la clase componente se le invoca el servicio relationChangedToFlexible.

&'(')'0'('*0'� .�� =� � �� =� ��

B��'�� 1�

�=��*��>@��)��??��)=��0�� P��P'��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� P��P'��*�@��P��F�>*@��F>F�

Al invocar este servicio la agregación deja de permitir nulos.

Las instancias de la clase compuesta deben estar relacionadas, necesariamente, con algún objeto

componente. En caso negativo, el diseñador deberá eliminar las instancias de la clase compuesta que no

estén relacionadas con ningún objeto componente73 o relacionarlas con algún componente invocando el

servicio de inserción de componentes si la agregación es dinámica, para no incurrir en inconsistencias.

Desde el punto de vista de la animación no será posible crear objetos compuestos si no se relacionan con

algún componente y cuando se destruya el objeto componente se destruirán los compuestos.

Se modifica el atributo componentClass para reflejar que ahora la agregación no permite nulos.

73 Aunque, de forma alternativa se podría asumir dicho comportamiento como parte de la valuación de este servicio y

eliminar de forma automática las instancias de la clase compuesta no relacionadas con ningún objeto componente.


�

�

148

A la clase componente se le invoca el servicio relationChangedToNotNull.

&'(')'0'('*1'� .�� =� �� =� �%��

B��'�� 1�

�=��*��>@��)��??��)=��0�� P'��*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��0�� P'��*�@��P��F�>*@��F>F�

Al invocar este servicio la agregación permite nulos.


haber en las clases compuesta y componente. Los objetos compuestos siguen estando relacionados con los

componentes y viceversa. Desde el punto de vista de la animación será posible que objetos instancias de

la clase compuesta no estén relacionados con ningún objeto componente.

Se modifica el atributo componentClass para reflejar que ahora la agregación permite nulos.

A la clase componente se le invoca el servicio relationChangedToNull.

&'(')'0'('*)'� 9��

B��'�� 1�

�=��*��>@��)��??��)=��%*�@��P��F�>�F�

�=��*��>@�) �%��??�) =�)=��%*�@��P��F�>*�@��F>F�

Este servicio se invoca cuando se desea que la clase ClassName deje de ser componente de una clase

compuesta.

Como precondición de este servicio se comprueba que en la definición de la clase no se usen propiedades

de la clase componente que va a dejar de serlo en expresiones de camino.

Este servicio hace que la clase ClassName deje de ser una componente de la clase compuesta

eliminándola del atributo componentClass.

Las instancias que tenga la clase compuesta dejan de estar relacionadas con las instancias de la clase

componente.


�

149

Se invoca el servicio unmakeComp en la clase ClassName para que actualice su estado y conozca que

ya no es componente de la clase compuesta.

- ��

El resto de servicios que vienen a continuación son los servicios que se han definido para las clases

elementales con el comportamiento redefinido para tener en cuenta que los metaobjetos que ofrecen

dichos servicios son agregaciones. Los servicios que no se mencionan a continuación conservan la

semántica dada para las clases elementales.

Al igual que en las secciones anteriores sólo se mencionan aquellos aspectos relacionados con la

característica emergente de ser clase compuesta, �� la semántica de los eventos que se

redefinen.

&'(')'0'('*3'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� %�*�@��P��*�P�! �%��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %�*�@��P��*�P�! �%��F�>*��

� � � � � � � ��@��*�%��F�>F�

�=��*��>@��)��??��)=��0�� %��*�@��P��*�P�! �%�*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %��*�@��P��*�P�! �%�*��F�>*��

� � � � � � � ��@��*�%��*��F�>F�

No se puede cambiar el tipo de un atributo si está siendo usado en alguna expresión de camino en algún

componente de una agregación relacional.

&'(')'0'('*4'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��*�@�P��F�>�F�

�=��*��>@��) �%��??��) =�)=��)��*�@�P��F�>*�@��F�>�F�

No se puede borrar el atributo si se usa en expresiones de camino en la definición de clases componentes

de una agregación relacional.


�

�

150

&'(')'0'('+5'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� %�*�@��P��*�P�! �%�*�P�!5��'��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %�*�@��P��*�P�! �%�*�P�!5��'��F�>*��

� � � � � � � @��*�%��*�P�! �%�F�>F�

�=��*��>@��)��??��)=��0�� %��*�@��P��*�P�! �%�*�P�!5��'��*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� %��*�@��P��*�P�! �%�*�P�!5��'��*��F>*�

� � � � � � � @��*�%��*�P�! �%�*��F�>F�

Como precondición comprueba que el atributo no se usa en ninguna expresión de camino en ninguna clase

componente de una agregación relacional.

&'(')'0'('+*'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��*�@�P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)��*�@�P��F�>*�@��F�>�F�

Tampoco se pueden borrar atributos variables si el atributo se usa en expresiones de camino en la

definición de clases componentes de una agregación relacional.

&'(')'0'('++'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��""5��*�@�P��*� �%�*��F�>�F�

�=��*��>@�) �%��??�) =��)=�""5��*�@�P��*� �%�*��F�>*�@��*�%��*��'��F�>�F�

En la fórmula de derivación del atributo pueden usarse expresiones de camino para consultar atributos de

las clases componentes.


�

151

&'(')'0'('+('� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��5��*�@�P��*� �%�*�P�!��F�>�F�

�=��*��>@��) �%��??�) =�)=�0��5��*@P��* �%�*P�!��F>*@��*%��*��'��F>�F�

Al igual que en el servicio anterior, en la fórmula de derivación del atributo pueden usarse expresiones de

camino para consultar el valor de los atributos de los objetos componentes.

&'(')'0'('+&'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)�5��*�@�P��F�>�F�

�=��*��>@��) �%��??�) =�)=��)�5��*�@�P��F�>*�@��F�>�F�

No se pueden borrar atributos derivados si el atributo es usado en expresiones de camino en la definición

de clases componentes de agregaciones relacionales.

&'(')'0'('+0'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��P��*�@�3�"P��*�P�!P��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��P��*�@�3�"P��*�P�!P��F�>*�@��*��F�>F�

Como el atributo puede ser usado en diferentes expresiones de camino en las fórmulas que definen la

plantilla de las clases componentes si la agregación es relacional, se invoca en éstas el servicio

aggAttNameChanged.

&'(')'0'('+1'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��F�>*�@��'��F�>�F�

En la fórmula que define la restricción de integridad se puede usar expresiones de camino para consultar

atributos de las clases componentes.


�

�

152

&'(')'0'('+)'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��)��*�@�3�)��*�P�)��*�P �%��F�>�F�

�=��*��>@�) �%��??�) =�)=�0��)��*@3�)��*P�)��*P �%��F>*@�)��*�)��*��=%��>F>F�

A las clases componentes relacionales se les invoca el servicio aggEventSigChanged para que cambien

el perfil del evento del componente en las expresiones de camino en las que se invoque dicho evento.

&'(')'0'('+3'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0��*�@��)��*��F�>�F�

�=��*��>@��) �%��??�) =�)=��0��*�@��)��*��F�>*�@��)��*��'��F�>�F�

La precondición del servicio comprueba que la fórmula que define la precondición sea consistente en la

clase de la misma manera que se hizo al definir la restricción de integridad.

&'(')'0'('+4'� 2��

B��'�� 1�

�=��*��>@��)��??��)=��)��)��*�@��)��F�>�F�

�=��*��>@��) �%��??�) =�)=��)��)��*�@��)��F�>*�@��)��F�>�F�

No se puede borrar un evento si se usa en una expresión de camino en el cuerpo de alguna transacción en

algún componente relacional de la clase.

&'(')'0'('(5'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� "�*�@� ��*��"��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� "�*�@� ��*��"��F�>*��

��@��*��$��F�>�F�

En el cuerpo de las transacciones se pueden usar expresiones de camino para invocar servicios definidos

en las clases componentes.


�

153

&'(')'0'('(*'� �/��

B��'�� 1�

�=��*��>@��)��??��)=��"" ��*�@� ��F�>�F�

�=��*��>@��) �%��??��) =��)=��"" ��*�@� ��F�>*�@��F�>�F�

En la condición de activación se pueden utilizar expresiones de camino para consultar el estado de los

atributos de los objetos componentes.

&'(')'0'('(+'� .��

B��'�� 1�

�=��*��>@��)��??��)=��0�� *�@� ��*�P�!��"��F�>�F�

�=��*��>@��) �%��??�) =�)=��0�� *�@� ��*�P�!��"��F�>*��

@��*��'��F�>�F�

La consistencia de la condición de activación se comprueba tal y como se ha descrito en el servicio que

añade un disparo.


�

�

154

&'(')'1'� �� ,��

La metaclase primitive_class es una metaclase que permite declarar los TAD que se utilicen en las

fórmulas que definen la plantilla de las clases. El hecho de que sea una clase es por uniformidad en el

modelo, pero realmente su comportamiento es totalmente distinto al presentado en el resto de metaclases,

ya que una instancia de la metaclase primitive_class (un TAD) no tiene instancias (en el sentido en el que

se ha estado usando hasta ahora). Las ‘instancias’ de una clase primitiva son las constantes o la aplicación

de los constructores sobre las constantes definidas en el TAD.

Como ya se ha comentado en la presentación de los TAD que se utilizan en la descripción de la metaclase

OASIS (sección 4.2), la �� no contempla la definición de TAD. La implementación �"�0�� realizada

utiliza clases como tipos y oid como valores del TAD. Además, para poder evaluar las funciones del

TAD, se debe proporcionar la implementación a través de un evaluador (presentado en 4.2.4).

Los TAD se definen globalmente, de forma que se pueden utilizar todos los TAD que se hayan definido

en todos los esquemas conceptuales. No se permite la evolución sobre los constructores de los TAD ni

sobre el perfil de las funciones. Sí se permite el cambio de las fórmulas de las funciones pero manteniendo

el perfil. Modificaciones más profundas sobre un TAD deben abordarse como definición de un nuevo

TAD.

Un TAD se define como un objeto �� instancia de la metaclase primitive_class cuyas propiedades se

describen a continuación.

&'(')'1'*'� #��

Las instancias de la metaclase primitive_class que representan TAD poseen unos atributos en los que se

definen las características del mismo. Los atributos contienen las constantes, los constructores, el valor

por defecto, las funciones y los operadores relacionales definidos para el TAD que representa el

metaobjeto.

%��@��N??��F�

%��@��'��N??��'��F�

%��@�"��'��N?��F�

%��@��'��N??��'��F�


�

155

%��@��'��N??��=��'��*��*��'��>�F�←��

� � � � � � � ��7��'��M��'��7��'��

%��@��3%�N??��3%��F��

%��@��3%5��N??��%=��3%*�5��>�F�←�5��7��'��

Los valores que toman las instancias de la metaclase primitive_class en sus atributos (constants,

constructors, functions y relOp) definen qué términos son constantes, constructores, funciones y

operadores relacionales, respectivamente. Los valores que tomen los atributos formulas y relOpDef

definen cómo se deben evaluar las funciones y los operadores relacionales, respectivamente.

&'(')'1'+'� - ��

Los servicios que presentamos a continuación permiten definir nuevos TAD con sus constantes,

constructores y funciones:

&'(')'1'+'*'� " ��

El servicio que permite crear nuevos TAD se llama newDomain.

%��@��)=��!5��*�@5��P��F�>�F�

Este servicio comprueba que no se haya definido con anterioridad un dominio con el mismo nombre que

el que se desea crear.

Crear un nuevo dominio supone crear una nueva instancia de la metaclase primitive_class.

=�5��P��7�%��>��

Para declarar un dominio como subtipo de otro existente, se define el servicio newDomainSubTypeOf.

%��=��)=��!5��$'� �%�3�=�@�5��P��*�$'%�� %��F�>�F�

que, además de crear un nuevo dominio instancia de la metaclase primitive_class define la relación de

subtipo entre DomainName y SuperType.

=�5��P��77�$'%�� %��>��


�

�

156

&'(')'1'+'+'� " ��

Con el servicio addConstant se pueden añadir constantes a un dominio previamente creado.

��@��)=��""��*�@��F�>�F�

Como precondición se comprueba que la constante no haya sido definida con anterioridad en el TAD y

que sea básica y atómica. Este servicio añade una nueva constante al dominio.

&'(')'1'+'('� " ��

El servicio addConstructor ofrecido por los TAD permite definir nuevos constructores.

��@��)=��""��'��*�@��'��*��B$�F�>�F�

Para poder llevar a cabo este servicio no debe haberse definido con anterioridad un constructor con el

mismo símbolo. LARGS contendrá una lista de pares, uno por cada argumento del constructor, cuyo

primer elemento es la variable que aparece como argumento del constructor y el segundo en el tipo de la

variable. Este servicio añade un constructor al TAD.

Por ejemplo, si se desea definir como constructor de los números imaginarios:

��=��*��>�7��←��7��M��7��

y suponiendo que el metaobjeto imaginary representa al TAD de los números imaginarios se invocará el

servicio:

��@��)=��""��'��*�@��=��*��>*�@�@�*��F*�@�*��F�F�F�>�F�

&'(')'1'+'&'� " ��

El servicio defDefault permite definir el valor por defecto del TAD.

��@��)=�"��5��'��*�@��'�F�>�F�

Por ejemplo, para definir como valor por defecto de los números imaginarios el valor img(0,0) se

invocará el servicio:


�

157

��@��)=�"��5��'��*�@��=�E*�E�>�F�>�F�

&'(')'1'+'0'� " ��

El servicio addFunction ofrecido por los TAD permite definir nuevas funciones.

��@��)=��""�'��*�@��'��*��B$�F�>�F�

Este servicio comprueba que no se haya definido para el TAD una función con el mismo perfil que la que

se desea definir. LARGS contendrá una lista de pares, uno por cada argumento de la función, cuyo primer

elemento es la variable que aparece como argumento de la función y el segundo en el tipo de la variable.

Este servicio modifica el atributo functions del metaobjeto que define el TAD sobre el que se define la

nueva función (inmediatamente hay que definir la fórmula de la función).

Por ejemplo, si se desea definir la función suma de número imaginarios:

'��=��*��*��>�7��'��←��7��M��7��M��7��

se invocará el servicio:

��@��)=��""�'��*�@�'��=��*��*��>*�@�@�*��F*�@�*��F*��

� � � � � � ��@�*��F��F�F�>�F�

&'(')'1'+'1'� �/��

El servicio que permite definir funciones sobre un TAD se llama addFormula y recibe tres argumentos:

la función, la restricción de aplicabilidad de la función y la fórmula que se debe evaluar para calcular el

valor de la función.

��@��)=��""��'��*�@��'��*��*��'��F�>�F�

Este servicio modifica el atributo formulas del metaobjeto que define el TAD sobre el que se desea

definir la fórmula.

Por ejemplo, si se desea definir la suma para los números imaginarios de la forma:

'��=��=��*��4>*��=��*��4�>*��=��*��4�>�>�←�'��=��*��*��>�M�'��=��4*��4*��4�>��


�

�

158

se debe invocar el servicio:

��@��)=��""��'��*�@�'��=��=��*��4>*��=��*��4�>*��=��*��4�>�>*��'�*� �

� � � � ��"=�'��=��*��*��>*�'��=��4*��4*��4�>>�F�>�F�

&'(')'1'+')'� .��

El servicio que permite cambiar una fórmula que define una función se llama changeFormula y recibe

tres argumentos: la función, la antigua fórmula y la nueva fórmula que se debe evaluar para resolver la

función.

��@��)=��0��'��*�@��'��*�3�"��'��*�P�!��*�P�!��'��F�>�F�

Este servicio modifica el atributo formulas del metaobjeto que define el TAD que se desea modificar.

&'(')'1'+'3'� " ��

El servicio addRelOpe ofrecido por los TAD permite definir nuevos operadores relacionales.

��@��)=��""��3%*�@��3%*��B$�F�>�F�

Este servicio comprueba que no se haya definido para el TAD un operador relacional con el mismo perfil

que el que se desea definir. LARGS contendrá una lista de pares, uno por cada argumento del operador,

cuyo primer elemento es la variable que aparece como argumento del operador y el segundo en el tipo de

la variable.

Este servicio modifica el atributo opRel del metaobjeto que define el TAD sobre el que se define el nuevo

operador relacional (inmediatamente hay que definir como se evalúa el operador).

Por ejemplo, si se desea definir el operador de igualdad para los números imaginarios:

�&'��=��*��>�7��%��←��7��M��7��

se invocará el servicio:

��@��)=��""��3%*�@��&'��=��*��>*�@�@�*��F*�@�*��F��F�F�>�F�


�

159

&'(')'1'+'4'� �/��

El servicio que permite definir operadores relacionales sobre un TAD se llama addRelOpDef y recibe

dos argumentos, el operador relacional y la definición del mismo.

��@��)=��""��3%5��*�@�3%��*�3%��5��F�>�F�

Este servicio modifica el atributo relOpDef del metaobjeto que define el TAD sobre el que se desea

definir el operador.

Por ejemplo, si se desea definir la igualdad para los números imaginarios de la forma:

�&'��=��=��*��4>*��=��*��4�>�>�←��&'��=��*��>�M��&'��=��4*��4�>��

se debe invocar el servicio:

��@��)=��""��3%5��*�@��&'��=��=��*��4>*��=��*��4�>�>*� � � �

� � � � � ��"=��&'��=��*��>*��&'��=��4*��4�>>�F�>�F�

&'(')'1'+'*5'� .��

El servicio que permite cambiar la definición de un operador se llama changeRelOpDef y recibe tres

argumentos, el operador, la antigua y la nueva definición.

��@��)=��0��3%5��*�@��3%*�3�"5��*�P�!5��F�>�F�

Este servicio modifica el atributo relOpDef del metaobjeto que define al TAD que se desea modificar.


�

�

160

&'(')')'� �� >�-�-

Todas las metaclases que se han descrito hasta aquí, forman parte de lo que hemos llamado la ��

3�$4$ (om). La metaclase OASIS es un esquema conceptual compuesto por unos metaobjetos que con su

estado describen la plantilla de las metaclases que permiten construir y modificar especificaciones OASIS,

de forma reflexiva.

Los esquemas conceptuales ofrecen servicios de factoría y almacén que permiten crear y destruir

instancias suyas. Cuando el diseñador decide crear una nueva definición de esquema conceptual invoca el

servicio newInstance en el esquema om, que genera una instancia del esquema conceptual de la

metaclase OASIS. Dicho esquema conceptual está formado, inicialmente, por las metaclases

elemental_class, temporalSpecialization_class, permanentSpecialization_class,

aggregation_class y primitive_class que permiten crear metaobjetos que describirán con su estado la

plantilla de clases elementales, especializaciones temporales, especializaciones permanentes, agregaciones

y dominios, respectivamente.

Una instancia de un esquema conceptual estará formada, inicialmente, por las clases cuya plantilla se ha

definido en los metaobjetos que forman parte del esquema y que ofrecen los servicios de factoría y

almacén de sus instancias. La instancia de un esquema conceptual es un prototipo animable del sistema

que se ha descrito al especificar el esquema. Se pueden crear diferentes instancias de un mismo esquema,

permitiendo así tener diferentes animaciones del mismo.

Haciendo un símil con el mundo de las bases de datos, diferentes instancias de un esquema conceptual son

bases de datos distintas que comparten la misma definición de esquema. Cada una de las bases de datos

tendrá poblaciones de objetos distintas, y serán animadas independientemente de las otras bases de datos.

En este contexto, la evolución de los sistemas de información se plantea, obviamente, en el nivel de los

esquemas conceptuales. Cuando se modifica la definición de un esquema conceptual, todas las bases de

datos creadas a partir de dicho esquema son modificadas para que sus poblaciones sigan siendo

consistentes con la nueva definición de esquema. Así se ha definido en la semántica de las operaciones de

modificación de esquema presentadas.

&'(')')'*'� #��

A continuación se describe la plantilla del esquema conceptual oasisMetaclass.


�

161

��@��N?��F�

��@��N??��F�

��@�)��N??�)��F�

��@�"��N??�"��F�

��@��N??��F�

��@��N?��'��F�

��@��!�N??��)��F�

��@�"��N?��)��F�

��@��)��N??��)��F�

��@��) �%��N??��) �%��F�

��@��)��N??��)��F��

��@��)��N??��)��F�

��@�%��N??�%��F�

Los esquemas conceptuales disponen de dos generadores de identificadores diferentes. El primero de ellos

sirve para generar los identificadores de las instancias del esquema conceptual. El segundo se utiliza para

generar los identificadores de las instancias que pueblan el esquema.

��@��4"�N?��F�

��@��2��$�N?��"�F� Q�B��"��"��"�%��"��&'��

��@��"�N?��F�

��@��2�3�"�N?��"�F� Q�B��"��"��"�%��&'��

Se puede consultar la población de los esquemas conceptuales a través de su atributo extent:

��@��2��N?��"�F�

A las instancias de los esquemas se las identifica por medio de algún alias que se haya definido. El

atributo derivado aliasOid devuelve el oid de una instancia a partir de su identificador.

��@��3�"=��"��>�N?��"�F�

Los nombres de los metaobjetos que definen la plantilla de las clases de un esquema conceptual se puede

consultar con el atributo classes.

��@��N??��F�

Además de los atributos definidos, se podrían definir nuevos atributos derivados que a partir de las

definiciones de clases que se realicen verifiquen determinadas propiedades como puede ser, por ejemplo,


�

�

162

la posibilidad de que los disparos definidos en el esquema provoquen abrazos mortales, que dos clases

sean muy semejantes entre sí, etc.

Como ya hemos comentado, la metaclase OASIS es un esquema conceptual definido de forma reflexiva.

Es decir, es instancia de la metaclase OASIS.

��7��

&'(')')'+'� ��

A continuación se muestran los valores de los atributos más importantes de la metaclase OASIS (om).

��@��?�#��,�F�

��@�)��??�G��=��*��*�� >*��

� � � ��=��*��*�@��=��*��>�F�>*� � � �

� � � ��=�)��*�)��*�@��=�"*��*�E>F�>�*� � � � �

� � � ��="��*�"��>*� � � � � � �

� � � ��=��*��>*��

� � � ��=��*��'��*��'�>*��

� � � ��=��!*��)��*��)=��!4��*�@P��F>�>*� � � �

� � � ��="��*��)��*��)=�"��4��*�@P��F�>>*� � � �

� � � ��=�)��*��)��*�@�)=��4"*��>�F�>*� � � � �

� � � ��=�)��*��)��*�@�)��=�)=��4"*��>*��'�>F�>*� � � �

� � � ��=�)��*��)��*�@�)��=�)=��4"*��>*��=��=��"*�45>*�=�'�=�45*�6*�P45>*�

� � � � � � � ��=��%=��=�"*�P45>�>�>�>�>�>F�>*�

� � � ��=�4"*��*�E>*� � � � � � � �

� � � ��=�"*��*�E>�H�F�

��@�"��??�G��5=��2��$*��"*��>*��5=��2�3�"*��"*��>*��5=��2��*��"*��>*��

� � �5=��*��*��>�H�F�

��@��??��=��*�@��F�>�F�

��@��!��??��)=��!4��*�@P��F>�F�

��@�"��?��)=�"��4��*�@�P��F�>�F�


�

163

��@��)�� ??�G��)=4��4"*��>*� �)=��""��*� @�P��*� �%��F�>*��)=��""��*�@�P��*�

�%�*��F� >*� �)=��""��*� @�P��*� �%�*��'��F�>*��)=��""5��*�@�

P��*� �%�*��'��F�>*��HH��F

Los valores de los atributos derivados nextCS y nextOid se obtienen deductivamente a través de las

reglas siguientes:

�$@��2��$��?��=��$*��$P�>�F�←��$�7��M��$@��4"��?��$4"�F�M�P�$�N��$4"�U�6�M��

� � � ��=P�$*��P�$>�M��%%��"=�@II*�66;F*��P�$*��$>�M�

� � � ��=�$P*��$>��

�$4@��2�3�"��?��=��$4*�345P�>�F�←��$47�$�M��$7��M��$@��"��?�45�F�M�P45�N�45�U�6�M�

� � � ��=P45*��P45>�M��%%��"=�@666F*��P45*��345>�M� �

� � � � ��=345P*��345>��

Con la primera regla se obtienen los identificadores de las instancias de los esquemas conceptuales y con

la segunda los identificadores de los objetos que forman parte de una instancia de un esquema conceptual

concreto.

En las reglas anteriores se puede observar la construcción utilizada para generar oids como un par

formado por el identificador del esquema (o de la instancia del esquema) y un átomo distinto para cada

objeto creado (para los esquemas conceptuales será ‘cs + número’75 y para los objetos que pueblen las

instancias de los esquemas conceptuales ‘o + número’).

La población de un esquema conceptual en cada momento está formada por todas las instancias que se

hayan creado de él y no hayan sido destruidas.

�$@��2��??�3�F�←��$�7��M�3�7��$��

El nombre de los metaobjetos que forman un esquema coincide con el nombre de los metaobjetos

instancia de la metaclase elemental_class en el esquema.

�$@��??�P��F�←��$�7��M��=�$*��>@��2��??�3�F�M�3@��?�P��F��

74 En el punto 4.3.7.7.3 se detallan los servicios junto con su semántica.

75 El símbolo + representa al operador de concatenación entre dos listas, siendo la primera lista la formada por

valores ASCII de la cadena ‘cs’ y la segunda lista los valores ASCII de la conversión de un número a cadena.


�

�

164

&'(')')'('� - ��

El conjunto de servicios definidos para los esquemas conceptuales permite definir y manipular el estado

de los esquemas. Como se puede observar, la plantilla ��de los esquemas conceptuales es, en su mayor

parte, idéntica a la presentada para las clases elementales en el punto 4.3.7.2.1. Por lo tanto, los servicios

que permiten dar valor y manipular los atributos de los esquemas son similares a los presentados para dar

valor y manipular los atributos de las clases elementales.

En este punto, sólo se presentan los nuevos servicios y aquéllos cuya semántica es diferente a la

presentada para las clases elementales.

&'(')')'('*'� .� �� =� �� : � �� 6� �� >�-�-;

El evento ��! que permite crear esquemas conceptuales se llama newInstance y está definido en el

atributo new del metaobjeto om.

��@��!��??��)=��!4��*��>��F�

La operación de creación de instancias de un esquema conceptual realiza los siguientes pasos:

1. Se crea una instancia del esquema sobre el que se invocó el servicio (la metaclase OASIS).

A los atributos variables se les da el valor por defecto o el pasado en los argumentos si hay

que proporcionarlo (en este caso el nombre del esquema). Se incrementa el contador de

esquemas creados (atributo csId).

2. Por cada uno de los metaobjetos que definen la plantilla de la metaclase OASIS se crea la

metaclase correspondiente.76

76 Las metaclases que componen los esquemas conceptuales son las metaclases elemental_class,

temporalSpecialization_class, permanentSpecialization_class, aggregation_class y primitive_class, sin

población inicialmente. Dichas metaclases permiten crear instancias suyas (metaobjetos) que con su estado definirán

la plantilla de las clases que formarán el esquema.


�

165

&'(')')'('+'� " �� =� �� : � �� 7� �� >�-�-;

El evento que permite destruir esquemas conceptuales se llama destroyInstance y está definido en el

atributo destroy del metaobjeto om.

��@�"��?��)=�"��4��*��>��F�

La operación de destrucción de esquemas conceptuales elimina del estado de la �� el metaobjeto que

describe el esquema, las metaclases que contiene, los metaobjetos definidos, las relaciones �� e

�� y todas las instancias del esquema que se puedan haber creado.

&'(')')'('('� �� =� ��

B��'�� 1�

��@��)��??��)=��4"*��>�F�

��@��) �%��??�) =�)=��4"*��>*��>�F�

Cuando una clase crea un objeto pide a la instancia del esquema conceptual en la que se encuentra que

incremente el contador de instancias creadas.

La evaluación únicamente incrementa en uno el valor del atributo id.

El resto de los servicios definidos para los esquemas conceptuales permiten dar valor y modificar los

atributos definidos en ellos:

• cambiar el nombre de los esquemas,

• añadir, borrar y modificar atributos constantes, variables y derivados,

• añadir, borrar y modificar alias,

• cambiar la restricción de integridad,

• añadir, borrar y modificar eventos, sus precondiciones y evaluaciones asociadas,

• añadir, borrar y modificar descripciones de proceso.


�

�

166

La semántica de estas acciones es muy similar a la presentada para los mismos servicios en las clases

elementales, por lo que se remite al lector a las mismas (sección 4.3.7.2.3).


�

167

6�#�?�� 7��9�� :;+0+��

A continuación se presenta la caracterización de una clase OASIS en ��. Como se puede ver en la regla

siguiente, una clase tiene un identificador de la forma c(DB, C), donde DB es el identificador de una

instancia de un esquema (instancia a su vez de la metaclase OASIS) y el metaobjeto que define la plantilla

de la clase o(CS, C) es instancia de la metaclase elemental en el esquema CS.

�=5�*��>�7��←�5��7��$�M��$�7��M��=�$*��>�7��=�$*��>��

Dada una clase c(DB, C), el metaobjeto o(CS, C) del esquema CS que describe con su estado la plantilla

de la clase, queda definido con la siguiente regla:

�=5�*��>@��.��?��=�$*��>�F�←��=5�*��>7��M�5��7�$��M��=�$*��>�7��=�$*��>��

Es decir, una clase �� c(DB,C) es una clase OASIS si dicha clase forma parte de la instancia de un

esquema conceptual DB, instancia de CS que a su vez es instancia de la metaclase OASIS (om) y el

metaobjeto o(CS,C) es instancia de la metaclase elemental c(CS,e_c).

La plantilla de clase, definida en los atributos de un metaobjeto del esquema, está disponible en las clases

a través de reglas que implementan la vista por proyección comentada en el punto 4.3.6. A nivel de

instancia de esquema no se permite la evolución, esto es, las clases conocen cuál es su plantilla pero no

pueden manipularla.

��$$@��?�P�F�←��$$�7��M��$$@��.��?��F�M��@��?�P�F��

��$$@��??��F�←��$$�7��M��$$@��.��?��F�M��@��??��F��

��$$@��)��??��F�←��$$�7��M��$$@��.��?��F�M��@��)��??��F��

��

La plantilla �� de las clases se obtiene de los metaobjetos que definen las plantillas a partir de las

siguientes reglas deductivas:

��$$@��N?� �%��F�←��$$�7��M��$$@��??��=��*� �%��>�F��

��$$@��N?� �%��F�←��$$�7��M��$$@�)��??��=��*� �%�*��>�F��

��$$@��N??� �%��F�←��$$�7��M��$$@�)��??��=��*� �%��>�F��

��$$@��N??� �%��F�←��$$�7��M��$$@�)��??��=��*� �%�*��>�F��

��$$@��N?� �%��F�←��$$�7��M��$$@�"��??��5=��*� �%�*��>�F��


�

�

168

Las relaciones �� que se hayan podido definir entre los metaobjetos en los esquemas, se trasladan a las

clases en las instancias de los esquemas gracias a la siguiente regla.

�77$��←��7��M�$�7��M��@��.��?��FM�$�@��.��?��$�F�M��77�$��

La población de cada una de las clases se obtiene a través de la regla siguiente a partir de las relaciones

�� definidas en ��:

��$$@��2��??�3�F�←��$$�7��M�3�7��$$��

A las instancias de una clase se las identifica por medio de los alias definidos. El atributo derivado

aliasOid devuelve el oid de una instancia a partir de su identificador.

��$$@��3�"=��"=��P��*��>�>��?�3�"�F�←�

� ��$$@��?��=��P��*��>�F�M�

� 3�7��$$�M�

� �0�� =�3�"*��*��>��

�0�� =��*��*��>��

�0�� =�3�"*�@��S��F�*�@��S��F�>�←�

� 3�"@��?��F�M�

� �0�� =�3�"*��*��>��

Entre las transacciones definidas para animar los sistemas hay unas que implementan la semántica de las

operaciones de creación y destrucción de instancias. Estos servicios se muestran en el apéndice D, y son

dependientes del tipo de la clase (por ejemplo, no es lo mismo el evento ��! de una clase elemental que el

evento ��!�de una especialización permanente).

6�6�� *��

En este capítulo se ha presentado la reificación en �� de la metaclase OASIS. Se han presentado los

atributos que tienen los metaobjetos y que describen la plantilla de las clases OASIS que forman parte de

los esquemas conceptuales, así como los servicios que permiten modificar dichos atributos. Los servicios

presentados implementan las operaciones de modificación de esquemas. Se han identificado los problemas

y las posibles soluciones a los problemas relacionados con la especificación y evolución de sistemas


�

169

haciendo uso del modelo de objetos de OASIS. Todo lo anterior se ha realizado utilizando el marco

formal proporcionado por la ��.

De esta forma, se ha descrito el núcleo de una herramienta CASE que permite a los diseñadores definir,

validar y evolucionar sistemas de información, utilizando siempre la misma metáfora de trabajo: el

modelo de objetos de OASIS.

�

<�� &��9��

(O�VLVWHPD�$)7(5�

173

<�$�� 0��

El formalismo lógico �� nos ha permitido hacer una descripción declarativa de la metaclase OASIS (ver

capítulo 4) ‘a bajo coste’ gracias a la cercanía de los conceptos �� con los conceptos OASIS. Al tener la

�� una semántica operacional correcta y completa respecto a su semántica declarativa [Kif95b y

Bon95], la propia especificación de la metaclase OASIS se convierte en un prototipo ejecutable por

animación que se puede usar en las tareas de validación de sistemas.

La metaclase OASIS se convierte en el núcleo de una herramienta CASE que proporciona un marco de

trabajo en el que, utilizando una metáfora única, desarrollar, validar y modificar modelos de sistemas de

información.

Como parte del trabajo realizado se implementó un intérprete de la �� [Car97a]. El propio intérprete de

�� nos permite, a través de su línea de comando, lanzar consultas y ejecutar transacciones. Esta forma de

interacción se realiza de manera textual, siendo difícil trabajar debido a la necesidad de conocer detalles

del sistema para poder realizar acciones (hay que conocer los atributos, los eventos, el número y tipo de

los argumentos, ...), existe poca o nula retroalimentación por parte del intérprete (para saber qué ha

pasado es necesario realizar una consulta para comprobar el nuevo estado), etc.

En este capítulo se presenta �� , la herramienta que se ha construido y que implementa las ideas

presentadas en los capítulos anteriores. �� utiliza la metaclase OASIS como núcleo y presenta una

Interfaz Gráfica de Usuario (IGU) que facilita el uso de la herramienta.

Partiendo de la idea de que definir sistemas de información haciendo uso de la metaclase OASIS es

exactamente lo mismo que trabajar con las instancias de los esquemas conceptuales que definen los

sistemas de información, se presenta una IGU homogénea que utiliza el diagrama de configuración de

clases (DCC) de OO-METHOD [Pas97] como base para la presentación de la información e interacción

con los usuarios. El ambiente gráfico que se va a presentar podrá ser utilizado tanto para la definición de

los sistemas como para la validación de los mismos.

Herramientas CASE existentes ($��0�� [Pop99], �� [Rat99], 33��0�"�[Pas97],

etc.), utilizan en la definición de los sistemas, diferentes modelos gráficos para la introducción de la

información: modelo de objetos, modelo dinámico, modelo funcional y/o modelos de interacción. El

modelo de IGU que se va a presentar puede verse como una alternativa, no excluyente, a dichos modelos.

El usuario/diseñador podría trabajar con cualquiera de los modelos gráficos con los que se sienta más

cómodo aunque internamente estaría trabajando con los servicios que le proporciona la metaclase.


�

�

174

<�%�� ;�(��

La arquitectura de la herramienta CASE construida está formada por dos subsistemas, como se puede

observar en la siguiente figura.

IGU Metaclase OASIS

��9�

Figura 17: Arquitectura de ��

1. Por un lado, la IGU proporciona a los usuarios los mecanismos (ratón, teclado, ventanas, ...)

necesarios para que éstos trabajen de forma cómoda con la metaclase OASIS.

2. Por otro lado, la metaclase OASIS proporciona los servicios que permiten a los usuarios definir los

sistemas, animarlos y modificarlos, consultando los atributos de los objetos e invocando los servicios

definidos para dichos objetos.

La IGU, construida haciendo uso del lenguaje ��M [Wel97], se divide a su vez en los dos módulos que

pueden observarse en la Figura 18:

• El módulo ��"��1 se comunica con el usuario y con el módulo gestor de consultas. El

usuario realiza peticiones al programa a través de su interfaz; estas peticiones pueden requerir

información externa o no. Por ejemplo, cuando el usuario quiere ver la información de una clase ha

de pedírsela al intérprete a través del gestor de consultas que se encarga de comunicarse con el

intérprete y de devolver la información requerida. �

• El módulo ��"��'�� recibe peticiones de información del módulo gestor de la interfaz.

Estas peticiones son complejas y necesitan ser traducidas para el intérprete. Por ejemplo, la petición

de consultar la plantilla de una clase puede dividirse en múltiples peticiones al intérprete acerca del

nombre de la clase, sus atributos constantes, variables y derivados, sus eventos propios y

compartidos, etc. Este módulo procesa las respuestas del intérprete y les da formato antes de enviarlas

al módulo gestor de la interfaz que se encargará de mostrarlas al usuario.


�

175

IGU

Figura 18: Detalle de la Interfaz Gráfica de Usuario de ��

La metaclase OASIS presentada en el capítulo 4 se ejecuta sobre un intérprete de �� que proporciona los

servicios de animación. Como ya se vio en el capítulo 3 una especificación ��tiene dos partes: el estado

y un conjunto de transacciones que modifican el estado. El estado de la �� forma la base de datos OO

que almacena toda la información que generan los usuarios, definiendo los sistemas o animando los

definidos.

Si el lector desea conocer más detalles sobre la IGU puede consultar [Cam99]. Sobre la implementación

de la metaclase OASIS en �� puede consultar [Cor98] y [Gua99]. Para conocer más detalles sobre la

implementación del intérprete de �� consultar [Car97a].

<�#�� ;��E�,'��

En este punto se va a presentar el ambiente gráfico desarrollado con el que se puede definir, animar y

evolucionar sistemas de forma cómoda haciendo uso de la metaclase OASIS a través de ejemplos que

ilustren la forma de trabajar con el mismo.

Al poner en marcha �� , la primera pantalla muestra el conjunto de esquemas conceptuales

disponibles en el instante actual representados en forma de iconos tal y como se puede ver en la Figura 19.

El conjunto de esquemas presentados coincide con la población de la metaclase OASIS (entre las

instancias, está la propia metaclase OASIS). Para utilizar un esquema conceptual no hay más que

seleccionarlo con el ratón.


�

�

176

Figura 19: Pantalla de entrada a �� con dos esquemas definidos.

Supongamos que el usuario quiere crear un nuevo esquema, para ello seleccionará la metaclase OASIS

apareciendo ante el usuario una ventana con el esquema en OASIS de la metaclase OASIS y su factoría.

Figura 20: Esquema conceptual de la metaclase OASIS

Al pulsar sobre el botón que representa el servicio de creación de esquemas (servicio newInstance) se le

pregunta al usuario por el valor de los argumentos que necesita el servicio (en este caso el nombre del

esquema que va a crear) y se invoca el servicio que crea una instancia de la metaclase OASIS.

Supongamos que el usuario desea definir el esquema conceptual de la biblioteca (��).


�

177

Acto seguido, aparece una nueva ventana como la mostrada en la Figura 21. Esta ventana consta de una

barra de herramientas, cuyos servicios se describirán en breve, un ��)�77 sobre el que se representa el

DCC con las clases definidas en el esquema conceptual del cual es instancia éste con el que se está

trabajando y una barra de estado que proporciona al usuario información varia. Al ser el esquema una

instancia de la metaclase OASIS las clases que aparecen en el DCC son las metaclases definidas en la

metaclase OASIS.

Figura 21: Una instancia de la metaclase OASIS (un esquema conceptual).

El DCC muestra las metaclases que se han presentado en el capítulo anterior que permiten al usuario

definir y modificar los metaobjetos que con su estado definen la plantilla de clases elementales,

agregaciones, especializaciones temporales o permanentes y clases primitivas. Para trabajar con una clase

del DCC no tenemos más que hacer doble click sobre el rectángulo que la representa. Las clases del DCC

pueden, además, desplazarse por el ��)� para mayor comodidad del usuario.

Supongamos que el usuario desea trabajar con las clases elementales, para ello hará doble click sobre el

rectángulo que representa la metaclase ��. Existe otro modo de seleccionar una clase del

DCC, a través del botón presente en la barra de herramientas, el cual muestra una lista con las clases

que forman el DCC que se está visualizando. Una vez seleccionada la clase, la pantalla tendrá el aspecto

mostrado en la Figura 22 (en el ejemplo ya se han creado los metaobjetos: ��, �� , ...).

77 Superficie de dibujo.


�

�

178

Para crear un metaobjeto que describa una clase elemental, el diseñador debe pulsar sobre el botón que

ofrece el servicio ��! de la metaclase e introducir los valores iniciales de los atributos constantes y

variables necesarios.

Figura 22: Clase ��

Si ya se han definido clases (creado metaobjetos) en el esquema el usuario puede seleccionar cualquier

objeto de la población de la metaclase seleccionada, por ejemplo, el metaobjeto socio (��), instancia

de la metaclase ��, para lo cual hará doble click sobre el elemento de la población

correspondiente. Existe otro botón en la barra de herramientas que permite ver una instancia de la clase

visualizada. Ese servicio viene representado por el botón que permite elegir una instancia de la

población de la clase seleccionada.

La representación gráfica de los metaobjetos viene dada por la doble visión comentada en el capítulo 2.

Los metaobjetos pueden verse como objetos y como clases de objetos. Todas las instancias de las

metaclases tienen esa doble visión. Sin embargo, las instancias de los metaobjetos (los objetos instancias

de las clases) sólo poseen la visión objetual.

En la Figura 23 y la Figura 24 se puede observar el metaobjeto socio (��) instancia de la metaclase

�� en sus dos visiones como objeto y como clase respectivamente.


�

179

La visión objetual de una instancia consiste en una ventana dividida en tres zonas:

• En la zona superior hay una etiqueta para el identificador de la instancia y tres botones cuyo

funcionamiento detallaremos en breve. Tras el identificador se muestra la clase de la que el objeto es

instancia. En el ejemplo de la Figura 23 el identificador de la instancia es su nombre: ��. El

primer botón situado a la más a la izquierda permite visualizar la clase de la cual es instancia el

objeto. El segundo botón , indica la visión actual seleccionada78, y sirve para cambiar entre la

visión de clase a la objetual y viceversa. Por último, el tercer botón minimiza el rectángulo.

• La zona central se utiliza para mostrar el estado de la instancia o, lo que es lo mismo, el valor que

tienen sus atributos. Los nombres de los atributos aparecen junto a sus valores en una rejilla con dos

columnas.

• Por último, en la parte inferior se muestran los servicios que ofrece la instancia. Estos servicios son los

eventos y transacciones definidos en la signatura de la clase de la cual es instancia el objeto. En este

caso los servicios permiten definir y modificar la plantilla de las clases. Si el diseñador desea

modificar de alguna forma la plantilla de la clase no tiene más que pulsar sobre el botón que representa

el servicio adecuado e introducir los valores de los argumentos del servicio que vaya a invocar.

Figura 23: Metaobjeto �� instancia de la metaclase ��

78 En este caso la de objeto


�

�

180

Como ya se ha comentado, una clase OASIS está formada por una plantilla, una factoría y un conjunto de

objetos llamados la población de la clase. La visión como clase de un metaobjeto consiste en una ventana

dividida en cuatro zonas, de las que tres se corresponden con los elementos de la definición anterior.

• La zona superior de la ventana es la misma que en el caso de la visión como objeto exceptuando el

hecho de que el botón de cambio de visión resalta la visión como clase .

• En la zona central aparece la plantilla de objetos! es decir, la especificación OASIS de la clase que se

está visualizando. La plantilla muestra con diferentes colores los distintos elementos presentes en ella

(tipos, nombres, palabras clave, fórmulas, …).

�

Figura 24: Visión como clase de un metaobjeto.

• La zona inferior izquierda muestra la factoría de objetos, es decir, los servicios de creación y

destrucción de instancias. Cuando se solicita alguno de estos servicios aparece un diálogo en el que se

establece el valor de los parámetros, que para el caso del evento ��! consiste en la instancia del

esquema conceptual en la cuál se quiere crear el objeto el valor de los atributos constantes y de los

variables necesarios que formarán el estado inicial del objeto, y para el evento destructor el

identificador de la instancia a destruir.

• Por último, la zona inferior derecha muestra el conjunto de objetos llamados la población de la clase.

La población de la clase viene dada en forma de lista de pares cuyo primer elemento es el identificador

de la instancia del esquema conceptual en el que se ha creado el objeto y el segundo elemento muestra

el identificador de las instancias de la clase.


�

181

Para modificar de cualquier forma la definición de un esquema sólo hay que localizar el metaobjeto que

contiene la información a cambiar e invocar el evento correspondiente. Por ejemplo, si se desea añadir un

atributo a la clase �� se puede invocar el evento addVarAttP en el metaobjeto que describe la clase

��. Una vez pulsado el botón que modeliza la invocación del evento aparece una ventana en la que

hay que introducir los valores de los argumentos del servicio, en este caso el nombre del nuevo atributo, el

tipo, el valor por defecto para las nuevas instancias que se creen de la clase y, como suponemos que la

clase puede estar poblada, la acción serial a ejecutar en cada una de las instancias que pueda tener la clase

para asignar un valor al nuevo atributo (la semántica del evento addVarAttP ha sido descrita en el

capítulo 4).

Figura 25: Ventana de entrada de parámetros para añadir un atributo a un metaobjeto.

También se pueden definir atributos y eventos en el esquema conceptual. Para trabajar con el esquema

hay que hacer un doble clic sobre el ��)� o pulsar sobre el botón . Al hacerlo, aparece la visión como

objeto del esquema que se está definiendo pudiendo ver su estado e invocar los eventos definidos.

Supongamos que el usuario desea trabajar en explotación con alguna instancia de esquema conceptual de

la biblioteca. A partir de la ventana inicial (Figura 19) hay que seleccionar el esquema deseado tal y como

se hizo con la metaclase OASIS. Una vez en esta situación, mostrada en la Figura 26, sólo queda escoger

la instancia concreta sobre la que se quiere trabajar en la población del esquema (en el ejemplo se supone

que se han creado dos instancias de la biblioteca: la �� o la ��).


�

�

182

Figura 26: El esquema conceptual ��

En la Figura 27 se puede observar el DCC de una biblioteca (��). El aspecto de la ventana es similar

al de la Figura 20, exceptuando el DCC mostrado en el ��)� y el título de la ventana. Este esquema

simplificado consta de libros (�� ) y socios (��), relacionados entre sí a través de préstamos

(��) los socios pueden ser fichados �� "��cambiando dinámicamente su comportamiento.

Figura 27: La biblioteca ��


�

183

Si el usuario selecciona la clase libro se mostrará tal y como aparece en la Figura 28 en la que se puede

ver la plantilla de la clase, la factoría y el almacén de la misma.

Figura 28: Clase �� en una instancia del esquema ��

Supongamos ahora que el usuario quiere consultar la instancia de libro que aparece en primera posición

de la población. Para ello hará doble click sobre dicho elemento, tras lo cual se encontrará en la situación

mostrada en la Figura 29.

�

Figura 29: Visión de una instancia de la clase ��


�

�

184

Como se puede observar en la figura anterior, los botones y están habilitados. Estos servicios

sirven para ir a la instancia anterior y posterior a la instancia visualizada. Si se sitúa el cursor del ratón

sobre alguno de estos botones se visualizará el nombre de la instancia, anterior o posterior, en la etiqueta

de ayuda flotante que poseen algunos controles.

Una característica destacable de la herramienta es la posibilidad de definir distintos tipos de vistas sobre

las clases: vistas por selección - representadas por el botón - y vistas por proyección - representadas

por el botón .

En la Figura 30 se muestra cómo puede definirse una vista por proyección. Como se puede observar en la

figura, una vez expresada la intención de generar una nueva vista por proyección, se despliega ante el

usuario una nueva representación de la clase en la que aparecen todos los nombres de los atributos y

servicios que forman parte de su signatura. Cada uno de estos elementos podrá seleccionarse o no a partir

de esta pantalla de manera que, una vez definida la vista, se ocultarán al usuario:

• la parte del estado correspondiente a los atributos que no hayan sido seleccionados,

• los servicios de la clase sobre la que se está definiendo la vista y que no aparecen en dicha definición

como seleccionados.

Figura 30: Definición de una vista por proyección sobre la clase ��


�

185

Tras la definición de la vista, el usuario dejará de percibir la clase libro� tal y como la percibía hasta el

momento y pasará a trabajar con la nueva vista. Las instancias de la clase libro son ahora objetos virtuales

obtenidos a partir de las instancias reales de la clase libro sobre las que se aplica la proyección.

En la Figura 31 se ilustra la definición de una vista por selección sobre la clase libro. Cada una de estas

vistas puede ser nombrada, de forma que podrá ser recuperada en cualquier instante una vez definida. En

el ejemplo podemos ver que la vista definida es la de todos aquellos �� correspondientes al ��

"�)'��-� que no se encuentren prestados en el momento de la aplicación de la vista

Figura 31: Definición de una vista por selección sobre la clase ��

El resultado de aplicar esta vista sobre la clase �� proporciona la población de una clase virtual

obtenida a partir de la población original de la clase libro aplicando una condición de selección

(expresada mediante un OQL).

<�6�� *��

Se ha presentado la herramienta �� con un ambiente gráfico que posibilita la definición y explotación

de sistemas de información dentro del marco formal y uniforme que proporciona la metaclase OASIS.

El ambiente gráfico tiene como ventaja el uso de un modelo único para la definición y explotación de los

sistemas de información. La forma de trabajar para definir y validar el esquema conceptual es exactamente

la misma y está basada en una metáfora totalmente orientada a objetos.


�

�

186

El ambiente gráfico presentado permite al analista introducirse en las sociedades de objetos que diseñe

convirtiéndose �� en una potente herramienta de depuración de especificaciones al poder observar si

los objetos se comportan tal y como se especificaron.

Es interesante observar la homogeneidad del ambiente presentado. El modo de trabajo es siempre el

mismo, ya se trate de definir, evolucionar o animar los esquemas o sus instancias.

Alguna de las posibles líneas futuras de actuación con respecto a la IGU sería proporcionar una apariencia

más comercial del estilo de las últimas aplicaciones Windows. y la adecuación del DCC al propuesto por

UML por ser este el estándar actual. También se podrían integrar otros modelos gráficos más conocidos

como pueden ser los modelos de interacción, modelos funcionales, modelos dinámicos, etc con el actual.

�

=�� 7��8�2��.��

&RQFOXVLRQHV�\�WUDEDMRV�IXWXURV�

189

En este trabajo se ha presentado una extensión del modelo OASIS consistente en la incorporación de

metaclases, las cuales permiten definir modelos de sistemas de información a través de la invocación de

sus servicios. Los sistemas definidos pueden ser ejecutados de manera automática por prototipación a

partir de las especificaciones.

La exigencia de evolución de los sistemas se encuentra incluida en la propia definición de la metaclase

OASIS, cuyos servicios permiten no sólo definir sino hacer evolucionar las especificaciones. El problema

de la evolución se plantea y resuelve manteniendo tanto la consistencia estructural como de

comportamiento.

Se ha construido una herramienta (�� ) en la que los aspectos de construcción del software se

encuentran soportados por la metaclase OASIS. El lenguaje con el que se definen los esquemas es

exactamente el mismo que el lenguaje con el que se invocan eventos en los objetos y el mismo con el que

se modifican los esquemas, no siendo necesario aprender diferentes lenguajes para cada una de las tareas

anteriores. La interfaz gráfica del prototipo construido facilita todavía más la tarea de modificar los

sistemas. Al utilizar una herramienta que automatiza, no sólo el proceso de construcción de aplicaciones,

sino el proceso de mantenimiento de las mismas, el coste de las aplicaciones puede reducirse

significativamente si nos atenemos a las cifras dadas en el capítulo 1.

Además, es posible realizar razonamientos hipotéticos sobre la modificación del esquema, ya que al

comportarse las operaciones de modificación de forma transaccional, si en algún momento de la

transacción con la que se modela el cambio del esquema se alcanza un estado no deseado, todos los

cambios realizados son deshechos alcanzando el estado previo a la ejecución del servicio de

manipulación.

Si se utilizan en la construcción de los sistemas software herramientas que generen automáticamente las

aplicaciones partiendo de las especificaciones, de los tres tipos de cambios gestionados en las tareas de

mantenimiento de software (corrección de errores, adaptación a nuevos entornos y mejoras o cambios

promovidos por usuarios y/o desarrolladores [Som96]) la única categoría a soportar es la última, ya que

los sistemas deben cambiar con el paso del tiempo para adecuarse a las nuevas necesidades. La primera no

tiene sentido ya que las especificaciones pueden ser validadas sintáctica (de forma automática) y

semánticamente (de forma automática por demostración de propiedades de la especificación y de forma

asistida por validación de los requerimientos). La segunda categoría tampoco tiene sentido porque para

cambiar la plataforma operativa sólo habrá que cambiar la plataforma sobre la que funciona la

herramienta CASE con la que se trabaja.

La taxonomía propuesta para ORION, O2, etc., como una lista de primitivas que modifican el esquema,

puede ser vista como el conjunto de todos los eventos proporcionados por la metaclase donde existe una


�

�

190

partición de los mismos en función del comportamiento que deban tener por estar definidos en las

diferentes metaclases que forman la metaclase OASIS.

La semántica de las operaciones queda perfectamente definida en las evaluaciones asociadas a cada

servicio de modificación de los metaobjetos que se encargarán de, por un lado, modificar la plantilla

almacenada en el estado del metaobjeto (edición) y, por otro lado, modificar las poblaciones para

adecuarlas al nuevo estado (evolución).

El conjunto de invariantes, que se definen para que las bases de datos sean consistentes, se traducen en

precondiciones o restricciones de integridad definidas en las metaclases. En el capítulo 4 se mostró dónde

quedan ubicados todos los invariantes definidos.

El posible problema de que las aplicaciones queden desfasadas por la evolución del esquema desaparece,

ya que las aplicaciones son objetos definidos como clases que forman parte del esquema y van a

evolucionar conjuntamente. Por ejemplo, si se desea cambiar el nombre de un atributo en una clase, si éste

está siendo usado por una aplicación79 se adecuará al nuevo estado en el que el atributo ha cambiado de

nombre. Por otro lado, los cambios que podrían dejar al esquema en estados inconsistentes para los que no

existe una solución automatizable, son detectados y no permitidos inicialmente. Para este tipo de cambios,

se proporcionan las herramientas necesarias para que al diseñador deshaga las posibles causas de

conflictos y aplique el cambio (algunos ejemplos se pueden encontrar en el apéndice C).

Finalmente, cabe resaltar que todo sistema desarrollado con AFTER está documentado, ya que la única

documentación necesaria son las especificaciones del sistema y las acciones asociadas al cambio son

realizadas y almacenadas automáticamente por la herramienta utilizada.

=�$�� 2��.��

El trabajo presentado en esta Tesis puede ser ampliado en diferentes direcciones, lo cual puede abrir

diversas líneas de investigación:

79 Un objeto de la sociedad.

&RQFOXVLRQHV�\�WUDEDMRV�IXWXURV�

�

191

• Demostración de propiedades automáticamente a partir de las definiciones de un sistema. Con la

metaclase, los esquemas de los sistemas están representados en el estado de determinados objetos.

Haciendo uso de los mecanismos de deducción de la �� sería posible escribir determinadas reglas

que, a partir de dicho estado, comprobasen automáticamente si se cumplen determinadas propiedades.

• Estudiar como afecta la introducción de la herencia múltiple en los problemas de evolución de

esquema.

• En [Can96] se extendió la semántica del párrafo %�� de OASIS asumiendo una relación de

causalidad entre eventos, lo que dio mayor riqueza a la actividad de los objetos, permitiendo la

introducción de los programas dentro de la especificación OASIS. Una extensión interesante a

nuestro trabajo puede ser la introducción y estudio de dichos programas con respecto a las nociones

de evolución descritas.

• Los servicios presentados en el presente trabajo forman el conjunto mínimo de eventos que permite

modificar cualquier aspecto de una especificación OASIS, pero no son los únicos que se pueden

definir a la hora de manipular especificaciones. Puede ser interesante estudiar la inclusión de eventos

de mayor nivel de abstracción [Bre96] como pueden ser: la integración de n clases en 1, la

descomposición de 1 clase en n clases, la posibilidad de mover una clase en una jerarquía de herencia

a lo largo de la misma, poder borrar una clase aunque esté relacionada por herencia y/o agregación

con otras clases, etc.

• La interfaz gráfica presentada en el capítulo 5 deriva directamente del DCC de OO-METHOD. Dicha

IGU facilita el uso de la metaclase para la definición y modificación de esquemas conceptuales. Pero

aun así, cuando no se puede modificar un esquema porque no se cumple la precondición de algún

servicio el diseñador debe buscar la causa de la insatisfacción de la precondición y deshacerla. Se

debería investigar en el área de IGU para hacerla más amigable e inteligente de forma que ayudara al

usuario a realizar las acciones que éste desea, proponiendo diferentes vías de solución.

• Otra de las áreas en las que queda trabajo por realizar es en la aplicación de los resultados

presentados en el campo de la evolución para la construcción de aplicaciones finales que

evolucionen. En [Pas98] se ilustra cómo, a partir de especificaciones formales, se puede llegar a

generar aplicaciones finales con una funcionalidad equivalente a la especificación en entornos

industriales de programación. Una aplicación directa de los resultados de la presente Tesis consistiría

en la evolución de dichas aplicaciones finales generadas de forma automática a partir de la semántica

dada para los servicios de manipulación del esquema.


�

�

192

• En el ámbito de la reutilización, se podría incorporar toda la teoría desarrollada en ese campo a la

hora de construir especificaciones de sistemas. Se podrían definir atributos derivados en los esquemas

que buscasen entre las definiciones de clases que se hayan realizado cuáles se ajustan a una serie de

parámetros para, una vez localizadas, utilizar servicios de copia entre los esquemas.

• El modelo OO de OASIS y su lenguaje de especificación están en continua evolución; recientemente

se ha definido una nueva versión [Let98], la 3.0, que mejora en numerosos aspectos algunas carencias

que tenía la versión 2.2. El presente trabajo está basado en la definición de OASIS 2.2 y, como se ha

visto, las posibilidades de modificación de los esquemas conceptuales de los sistemas son

dependientes del modelo OO usado para definirlos. Otro campo de investigación vendría dado por la

definición reflexiva de la metaclase OASIS 3.0 de forma que fuera posible definir y hacer evolucionar

especificaciones de sistemas haciendo uso de todas las características de la nueva versión.

�

F��')��

%LEOLRJUDItD�

195

[Bal83] Balzer R., Cheatman T.E., Green C., $��!�� 0�� 0�� 6IIEX7� �� P�!�

��"��, IEEE Computer, Noviembre 1983, pag. 39-45.

[Bal85] Balzer R., �� 6;� Y�� %��)�� '�� , IEEE Transactions on

Software Engineering, VOL. SE-11, No. 11, Noviembre 1985.

[Ban87] Banerjee J., Kim W., Kim H.K., Korth H.F., $�� "� ��%�� 0��

�)��'��.��"�"��, Proc. Of ACM-SIGMOD International Conference on

Management of Data, San Francisco CA, Mayo 1987.

[Ber80] Bersoff E. H., Henderson V.D., Siegel S.G., $��!��'��, Prentice-

Hall, 1980.

[Bjø88] Bjørnerstedt A., Britts S., �)��.��, Proc. of the Conference

on Object-Oriented Systems, Languages and Applications (OOPSLA), San Diego, California,

USA, pag. 206-221, Septiembre 1988.

[Bon95] Bonner A.J., Kifer M., �� , Technical Report CSRI-323,

disponible en: ftp:/csri.toronto.edu/csri-technical-reports/323/report.ps.Z, Noviembre 1995.

[Bon99] Bonner A., Kifer M., ��'�� "��'�� , disponible en:

ftp://ftp.cs.sunysb.edu/pub/TechReports/kifer/concurrent-trans-logic.ps.Z.

[Bre89] Breitl R. et al., 0��B��$��"��, en [KIM 89], pag. 283-308.

[Bre96] Brèche P., �")��"��)�� 0��$�0��3�.��5��, Proc. of the

CAiSE’96 conference, Springer-Verlag, Heraklion, Creta, Mayo 1996.

[Bus96] Buschmann F., Meunier R., Rohnert H., Sommerland P., Stal M., ��$��, Ed.

John Wiley and Sons Ltd, ISBN: 0-471-95869-7, 1996.

[Cam99] Camilleri S., 4��1�B�+��"��'��%��3�$4$, Proyecto Fin de Carrera,

Facultad de Informática, Universidad Politécnica de Valencia, en preparación.

[Can91] Canós, J.H. et al., �'�� "� 3�.��3��"� $%�� 4�� $��,

Proc. of the DEXA-91, Springer-Verlag, Agosto. 1991.

[Can96] Canós J.H., 3�$4$*� '�� '�.�� T�� %�� "�� "�� "�� .��, Tesis

Doctoral, Universidad Politécnica de Valencia, Valencia 1996.

[Can98] Canós J.H., Jaén F.J., Ramos I., �!��"� ��&'�� )�� 5��

$��?Actas del WER'98, 1998, Brasil.

[Car96a] Carsí J.A., Ramos I., Bonet B., Jaén F.J., Penadés M.C., 4�%��-��"��"��

'��"��%��-��'��+��"��3�$4$, Informe Técnico DSIC-II/15/96,

Universidad Politécnica de Valencia, Abril 1996.


�

196

[Car96b] Carsí J.A., Ramos I., Penadés M.C., Pelechano V., 5��%��-�� "��"�� "�� .�� "��

3�$4$��)(�"�� , JIS'96, I Jornadas de Trabajo en Ingeniería

del Software, Sevilla, 12 pág., Noviembre 1996.

[Car97a] Carsí J.A., Canós J.H., Ramos I.,� 4�%��-�� "�� '�� 4��(�%�� "��

��, Informe Técnico DSIC-II/35/97, Universidad Politécnica de Valencia, 82 págs.,

Octubre 1997.

[Car97b] Carsí J.A., Canós J.H., Ramos I., �� (�%�� "�� , JIS'97, II

Jornadas de Trabajo en Ingeniería del Software, San Sebastian, 14 pág., Septiembre 1997.

[Car98a] Carsí J.A., ��)��'��-��"��&'��3�$4$, MENHIR'98, II Jornadas de

Trabajo en MENHIR, Valencia, 22 pág., Febrero 1998.

[Car98b] Carsí J.A., Ramos I., Canós J.H., ��3�$4$, IDEAS'98, Workshop Iberoamericano

de Ingeniería de Requisitos y Ambientes Software, Torres-BRASIL, 12 pág., Abril 1998.

[Car98c] Carsí J.A. et al,��5335�$�� 0��$�0��)��'��, EDBT'98 Demo

Session, VI Intl. Conference on Extending Database Technology, Valencia, 2 pág., March 1998.

[Car98d] Carsí J.A., Camilleri S., Canós J.H., Ramos I., ��%'�� "�� 4��1� B�+�� "�� '��

0��(��%��5��Z��2%��-��"��$��"��4��-�, JIS’98, III Jornadas de

Trabajo en Ingeniería del Software, Murcia, Noviembre 1998.

[Car98e] Carsí J.A., Canós J.H., Ramos I., ��'"��"��'��-��"��$��!��"�"��'��

��%��)��3��"�� 3�.��, III Jornadas de Trabajo en MENHIR, Murcia, Noviembre

1998.

[Cat97] Cattell R. et al, 0��3�.��5��$��"��"7�35�B�8�E* Morgan Kaufmann Publishers

Inc., 1997.

[Cer93] Ceri S., Manthey R., ��"��"� %�� 0��, IDEA deliverable

IDEA.DE.2P.006.001, ESPRIT Project 6333, 1993.

[Che99] Chenoll A., �&'��"�� "'��-��"��3�$4$�� , Proyecto Fin de

Carrera, Facultad de Informática, Universidad Politécnica de Valencia, Julio 1999.

[Cor98] Coronado A., 5��%��-�� "��"�� "�� 0�� "�� 3�$4$� ��

��, Proyecto Fin de Carrera, Facultad de Informática, Universidad Politécnica de

Valencia, Octubre 1998.

[Cue99] Cuesta C., Fuente P., Barrio M., 5��"��$��!��0��'��, Actas de

las 4ª jornadas de trabajo de MENHIR, Sedano – Burgos - España, Mayo 1999.

%LEOLRJUDItD�

�

197

[Del91] Delcourt C., Zicari R., 0��5�� 4��0�� =4��>� ��3�.��

3��"�5��$��, ECOOP’91, Switzerland, Springler-Verlag, Julio 1991.

[Den96] Denker G., ��0��!%��'��)�� '�0, En Haveraan, M., and

Owe, O., and Dahl, O.-J., editors, Recent Trends in Data Types Specification, Proc. 11th

Workshop on Specification of Abstract Data Types joint with the 8th General COMPASS�

Meeting. Oslo, Norway, September 1995. Selected papers,� pag. 182-199. Springer, LNCS

1130, 1996.

[Dia97] Diaz O., Paton N.W., $��'��"��'��"��'��7��0��"��

��"� )��"�� 0��'0� �0�� )�� '�', Proc. CAiSE, A. Olive and J. Pastor (eds),

Springer-Verlag, 33-46, 1997.

[Ehr96] Ehrich H.D.; 3�.��$%��In Astesiano, E. ; Kreowski, H.J. and Krieg-Brückuer, B

(ed.), IFIP WG 14.3 Book on Algebraic Foundation of Systems Specification, Springer, 1996.

[Fal96] Falkenberg E., et al, ��!�� 4�� $��%�7� 0��4$�3��%��,

Informe del IFIP WG 8.1 Task Group FRISCO, 1996.

[Gol87] Goldberg A., Robson D., $�� [E� 0�� '�� "� �� 4�%��, Addison-

Wesley, 1987.

[Gua99] Gualberto R., �� )��'��-��"��&'��3�$4$7��-��&'��

��%�'��, Proyecto Fin de Carrera, Facultad de Informática, Universidad Politécnica de

Valencia, Julio 1999.

[Kif95a] Kifer M., 5�"'��)��"�3�.��5��'��7��\'��4��, Keynote address

at the 4-th Intl. Conf. on Deductive and Object-Oriented Databases, Singapore, Diciembre

1995 (Springer's LNCS 1013).

[Kif95b] Kifer M., Lausen G., Wu J., �� '�"�� 3�.��3��"� ��"� ��"�

��'��, Journal of the ACM, 42 (4), pag.741-843, Julio 1995.

[Kim89] Kim W. and Lochovsky, F.H. (eds.), 3�.��3��"��%�*�5��"��%%��,

ACM Press, Addison-Wesley, 1989.

[Kim90] Kim W., 4��"'�� 3�.��3��"��%�*�5��, The MIT Press, ISBN: 0-

262-11124-1, 1990.

[Lem94] Lemke T., $�0��)��'��335��$7��$��)��3)��)��!��"�$��'��,

Technical Report IDEA.WP.22.O.002, University of Bonn, Octubre 1994.


�

198

[Lem95] Lemke T., 55�� N� 5��K� �� 2�� )�� $�0�� 0��,

Technical Report IDEA.WP.22.O.003, University of Bonn, Marzo 1995.

[Ler90] Lerner B.S., Habermenn A.N., ��"� $�0�� )��'�� 5�� 1��, In

Proc. Of the Joint Conference on Object-Oriented Systems, Languages and Applications

(OOPSLA) and ECOOP, Ottawa, Canada, pag.67-76, Octubre 1990.

[Let98] Letelier P., Ramos I., Sanchez P., Pastor O.,�3�$4$�:�E7��&'��%��"��"��

��%�'�� "�� .��. Servicio de Publicaciones Universidad Politécnica de

Valencia, SPUPV -98.4011, ISBN 84-7721-663-0, 1998.

[Man91] Manley, John, et al., ]��$6��'��=��:>, HP-Labs. Internal Report HPL-91-

178, Bristol, 1991.

[McK84] McKee, J.R., �� '�� 5��, In Proc. AFIPS National Computer

Conf., Las Vegas, 187-93.

[Mon93] Monk, S., �� "�� $�0�� )��'�� 3�.��3��"� 5�� $��, Ph. D.

Thesis, Computing Department, Lancaster University, Febrero 1993.

[Odb95] Odberg, E., �'��%��%��)�7�3�.��)��'��"�$�0��"��

3�.��3��"�5��, Ph.D. Thesis, Department of Computer Systems and Telematics,

Norwegian Institute of Technology, Febrero 1995.

[Par99] Parets J., Carsí J.A., Canós J.H, Penades M.C., Anaya A., Paderewski P., Ramos I.,

Rodríguez M.J., ��)��'��-��"��"��"��"��!��7��&'��3�$4$��

��5�$, IV Jornadas de Ingeniería del Software (JIS’99), Caceres, Noviembre 1999.

[Pas92] Pastor O., 5��Z��5��"��'��"��"'��-��'��+��"��$��!��"��

��"��3��"��3�.��, Ph.D. Thesis, U.P. Valencia, 1992.

[Pas95] Pastor O. et al., 3�$4$�)��8�=8�8>7��5��'��"��4��

$�� '�� 3�.��3��"� �%%��0, SPUPV-95.788, Universidad Politécnica de

Valencia, 1995.

[Pas97] Pastor O., Insfrán E., Pelechano V., Romero J., Merseguer J.

33�� 9357� �� 33� $��!�� "'�� )�� )�� "�

��0�" Conference on Advanced Information Systems Engineering (CAiSE '97).

LNCS (1250), pag. 145-159. Springer-Verlag 1997. ISBN: 3-540-63107-0.

Barcelona, Junio 1997.

%LEOLRJUDItD�

�

199

[Pas98] Pastor O., Pelechano V., Insfrán E., Gómez J., ��3�.��3��"��%�'��"��

��'��"��A�)�*�17th International Conference on Conceptual Modeling

(ER'98). Noviembre 1998, Singapore

[Pop99] Popkin Software, http://www.popkin.com.

[Pre97] Pressman R.,�4��/��"��$��!��7��&'��%�+��=D^��"�>, McGraw-Hill, 1997.

[Ram90] Ramos I., �� "� 33�5��7� �� 5��)�� %%��0, Proc. of the DEXA-90,

Springer-Verlag, 1990.

[Ram92] Ramos I., Pastor O., Cuevas J., Devesa J., 3�.��3��)��* Proceedings of

the 3rd Workshop on the deductive Approach to Information System Design, Roses

(Cataluña), 1992.

[Ram95] Ramos I., Pelechano V., Penadés M.C., Bonet B., Canós J.H., Pastor O., �%��-��

��3�$4$�"��'��"��%��-��'��+��, Informe Técnico II-DSIC-10/95, Julio

1995.

[Rat99] Rational Software, http://www.rational.com.

[Rog97] Rogerson D., 4��"��3�, Microsoft Press, 1997.

[Ser87] Sernadas A. et al., 3�.��3��"� $%�� 5��7� �� %%��0.

Proc. 13th Int. Conf. on Very Large Database�VLDB'87. VLDB Endowment Press, Saratoga

(CA), 1987, pag. 107-116.

[Ser91] Sernadas A. et al, 3��3B� �� 3�.��3��"� ��7� �� 4�� 4��"'��. Internal

report, INESC, Lisbon, 1991.

[Sjø93] Sjøberg D., \'��$�0��)��'��, Information and Software Technology, vol. 35, no. 1, pag. 35-54.

[Ska87] Skarra A.H., Zdonik S.B., �%��)��'��3�.��3��"�5��. In Bruce Shriver

and Peter Wegner (Eds.): Research Directions in Object-Oriented Programming, pag. 393-

415, MIT Press, 1987.

[Som96] Sommerville, I., $��!�� , Fifth Edition, ISBN:0-201-42765-6, Addison-Wesley, 1996.

[Sun99] Sun, A�)��, en:

http://java.sun.com/products/jdk/1.2/docs/guide/reflection/spec/java-reflection.doc.html

[Tov94] Toval A., ��1��-��"��'��"��"'��-��'��+��"��%��

3��"��3�.��, Tesis Doctoral, Universidad Politécnica de Valencia, Marzo 1994.


�

200

[Tre92] Tresch M., Scholl M.H., �� .�� "� �� %%�� "��

�)��'��, In Proc. Of the 11th International Conference on the Entity-Relationship Approach,

Karlsruhe, Germany, pag. 299-321, Octubre 1992.

[Wie90] Wieringa R., �� '�"�� 5�� %�'�� "�� PhD thesis, Vrije Universiteit, Amsterdam, 1990.

[Wie 91] Wieringa R., ��1��3�.��'��&'��5��, in Proc. of the

DOOD 91, LNCS, Springer-Verlag, 1991.

[Wie95] Wieringa R., et al, ��5��"��"��3�.��, in

Theory and Practice of Object Systems, Vol. 1, Ed. John Wiley and Sons, 1995.

[You89] Yourdon E., ��:7� ��*� ��'��'�� "� ��)�� , American

Programmer, 2 (4), pag. 3-10, 1989.

[Zdo90] Zdonik S.B., 3�.��3��"� �%�� )��'��. In François Bancilhon and Peter Buneman

(Eds.): Advances in Database Programming Languages, pag. 277-288, Addison-Wesley,

1990.

[Zic91] Zicari R., ��!�� 0��'%"��.��"�"��, In IEEE

International Conference on Data Engineering (DE 91), Kobe, Japan, pag. 2-13, Abril 1991.

�

;�� ;��*�� ,'��

5HVXPHQ�GH�OD�QRWDFLyQ�JUiILFD�GH�22�0(7+2'�

203

0��

La notación gráfica utilizada en el presente trabajo deriva directamente de la notación de OO-METHOD.

OO-METHOD es una metodología que cubre las fases típicas del proceso de producción de software

(Análisis, Diseño e Implementación), recogiendo los principios del modelo OO expuestos en el capítulo 2.

Esta metodología proporciona avanzados modelos gráficos que permiten construir una especificación

gráfica como resultado del análisis del sistema, cuya especificación textual equivalente en OASIS se

obtiene de forma automática. A continuación se incluye un pequeño resumen en el cual se presentan los

puntos básicos de esta metodología en lo referente a la fase de análisis, que incluye la notación gráfica

empleada a lo largo de la Tesis.

/��'�� ,��

OO-METHOD proporciona en la fase de análisis�una notación para generar especificaciones gráficas y

orientadas a objetos. En dicha fase, los pasos a seguir son:

1. Un proceso de ��-� para identificar las clases existentes en el sistema de información, y las

relaciones entre ellas. Las relaciones que se van a considerar son las de agregación y herencia.

2. Para cada clase identificada se determinarán cuáles son sus atributos, sus eventos relevantes, los

��"��%�� de sus instancias, y cuáles los eventos causantes de la transición de un estado a otro,

así como las hipotéticas condiciones asociadas a tales cambios de estado.

Como resultado del análisis se generan dos tipos de modelos gráficos:

• El 5��"��'��-��"�� (DCC): es un modelo semántico extendido que muestra la

estructura estática del sistema, pero que incluye también, para cada clase, los eventos de su signatura.

• Cada clase componente del DCC tiene asociado un 5��"��"��"�� (DEC) en el que

se representan, para cada atributo variable, los estados potencialmente válidos para instancias de la

clase, y los eventos causantes de las transiciones entre dichos estados.

Los modelos gráficos obtenidos en la fase de análisis OO, se traducen de forma automática a una

especificación en OASIS, que es utilizado como herramienta de diseño asociada a OO-METHOD.

G��E�,'��9� ��-77��

El DCC es la herramienta gráfica que permite describir las clases componentes del sistema a modelar,


�

�

204

definiendo sus aspectos característicos y las relaciones que existen entre ellas. De esta forma se obtiene

una visión estática�del mismo como sociedad de objetos.

*��

En el DCC cada clase elemental se representa mediante una caja o rectángulo con el nombre de dicha

clase. La información que estará asociada a la clase, y que tendrá que introducirse en el proceso de

análisis, será la siguiente:

• Sus atributos constantes*�variables y derivados, y las restricciones de integridad�estáticas asociadas.

• Los eventos� de la clase. Hay dos tipos de eventos que, interpretados como servicios, son los

proporcionados por una clase (eventos propios) y los proporcionados por más de una clase (eventos

compartidos).�En la siguiente figura se aprecia la notación gráfica empleada.

*��

La notación gráfica de OO-METHOD permite especificar los diferentes tipos de relaciones entre clases de

la manera que se muestra en la siguiente figura. Entre las relaciones están las que dan lugar a clases

complejas (agregación y especialización) y la relación “��"�”.

5HVXPHQ�GH�OD�QRWDFLyQ�JUiILFD�GH�22�0(7+2'�

�

205

RESUMEN DE LA NOTACIÓN GRÁFICA

RLG

vistacomoclase

vistacomoobjeto

HYHQWR��

HYHQWR�Q

QHZ

GHVWUR\

FODVV�nombre��FRQVWDQWBDWWULEXWHV

��

HQGBFODVV

atributo 1 -> valor

atributo k -> valor

atributo 1 → valor

...

atributo k → valor

RLG

HYHQWR��

HYHQWR�Q

FODVV nombre��FRQVWDQWBDWWULEXWHV

��atributo: tipo; ... atributo: tipo;YDULDEOHBDWWULEXWHV

atributo:tipo; FRQVWUDLQWV id_book( ID ) & ID>100.��

HQGBFODVV

��

��

��

��

representación de la agregación representación de la especialización

�

;�� F��+��

6HUYLFLRV�DX[LOLDUHV�GH�HYROXFLyQ�

209

En este apéndice se describen todos los servicios auxiliares que se encargan de asegurar la consistencia de

las especificaciones definidas haciendo uso de los servicios presentados en el capítulo 4. Estos servicios

nunca serán invocados por los usuarios ya que su función sólo tiene sentido porque se ha provocado un

cambio en algún metaobjeto y se deben de mantener la consistencia con el resto de metaobjetos. Los

servicios se encuentran ordenados por la metaclase en la que se define los servicios.

Los servicios se muestran en forma de tabla en la que las diferentes filas proporciona, de forma ordenada,

la siguiente información:

• el nombre del servicio y una descripción de lo que hace,

• el perfil del servicio a través del valor del atributo evType (sección 4.3.7.2.1) del metaobjeto en

el que esté definido el servicio,

• el agente,

• la precondición,

• la evaluación,

• los disparos generados para mantener la consistencia de la especificación.

D��

addAgent ;H� ��

B(5),/�'(/�6(59,&,2� �) =��)=��""��*�@�$��)��*��F�>*�@��)��*��F�>�

$*(17(� La clase en la que se ha definido un disparo a un servicio de esta clase.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Este evento actualiza la información en el atributo agent, no permitiendo duplicados (aunque estén definidos varios disparos desde la clase Class al servicio Service, un agente sólo aparece una vez en la lista)

;&&,21(6�,192&$'$6�

aggAttNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =�)=��P��0��"*�@��P��*�3�"P��*P�!P��F>*� �� @��*��*��F�>�

$*(17(� La agregación en la que ha cambiado el nombre de un atributo.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia el nombre del atributo en todas las expresiones de camino en las que


�

�

210

se use: en las fórmulas de derivación, en la restricción de integridad, en las condiciones de activación de disparos y en las precondiciones de los eventos.

;&&,21(6�,192&$'$6�

aggEventSigChanged 7�� '��

B(5),/�'(/�6(59,&,2� �) =�)=��)��$��0��"*@��P��*3�"�)��*P�!�)��*P�! �%��F>*� �� @��*��)��*��)��*��=%��>�F�>�

$*(17(� La agregación en la que ha cambiado el perfil de un evento.

35(&21',&,Ï1� A los argumentos del evento se les debe proporcionar valor en el cuerpo de la transacción o deben tener el mismo nombre y tipo que algunos de los argumentos definidos en el perfil de la transacción en la cual se invoque el evento que ha cambiado el perfil.

'(6&5,3&,Ï1� Cambia el perfil en las expresiones de camino en las que se usa el evento en el cuerpo de las transacciones

;&&,21(6�,192&$'$6�

aliasNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =��)=��P��0��"*�@�3�"P��*�P�!P��F�>*�@��*��F�>�

$*(17(� La clase que ha cambiado el nombre de algún alias.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia en la definición de los disparos el nombre del alias.

;&&,21(6�,192&$'$6�

classNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =��)=��P��0��"*�@3�"P��*�P�!P��F�>*�@��*��F�>�

$*(17(� La clase cuyo nombre ha cambiado por el servicio changeName.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia en todos los lugares donde se usaba el antiguo nombre de clase OldName (definición de eventos compartidos y disparos de la clase) por el nuevo nombre NewName.

;&&,21(6�,192&$'$6�

conditionSpeChanged@ 7�� 9�� 9��

B(5),/�'(/�6(59,&,2� �) =�)=��"��$%��0��"*�@�$'��*�P�!��"�F�>*@��*��'��F�>��) =�)=��"��$%��0��"�*� @� $'��*� P�!��"*� $'%�� F� >*� � � ��@��*��'��*��F>��) =�)=��"��$%��0��"�*� @� $'��*� P�!��"*� $'%�� F� >*� � � ��@��*��'��*��=�>F>��) =�)=��"��$%��0��"�4*� @� $'��*� P�!��"*� $'%�� F� >*� � � ��@��*��'��*��=��=�>>F>�F�


�

211

$*(17(� La subclase permanente en la que ha cambiado la condición de especialización.

35(&21',&,Ï1� La condición de especialización debe estar definida sobre atributos constantes de la superclase.

'(6&5,3&,Ï1� Este servicio modifica la condición de especialización modificando el atributo permSubClasses. Al cambiar la condición de especialización, puede que algunas instancias de la superclase deban especializarse permanentemente porque satisfagan la nueva condición. Parte de la ejecución de este servicio evalúa la condición sobre las instancias de la clase especializándolas permanentemente si la satisfacen. Los valores de los atributos de las propiedades emergentes de los objetos que se especializan se deben pasar en el último argumento. Se han definido cuatro eventos que implementan cuatro posibles soluciones al problema de la migración de las poblaciones: • con el primer servicio (conditionSpeChanged) a las instancias que

deban migrar se les da el valor por defecto en función del tipo de datos definido como dominio: 0 para nat, false para bool, ...,

• con el segundo servicio (conditionSpeChangedP) se ejecuta una función de migración (Actions) que debe definir el manipulador de las clases que se encargue de asignar los valores adecuados para cada una de las instancias de la clase que deba migrar,

• con el tercer servicio (conditionSpeChangedV) a todas las instancias se les proporciona los mismos valores para todos los atributos emergentes, dichos valores se pasan en el argumento AttList,

• el último servicio definido (conditionSpeChangedVI) asigna a cada instancia que deba migrar un conjunto de valores diferenciado a los atributos emergentes, estos valores deben ser proporcionados por el diseñador cuando invoca este servicio en el argumento AttList que en este caso será una lista de listas de valores de los atributos emergentes.

;&&,21(6�,192&$'$6�

eventSigChanged 7�� '��

B(5),/�'(/�6(59,&,2� �) =��)=�)��$��0��"*�@3�"�)��*P�!�)��*�P�! �%��F>*�� @�)��*��)��*��=%��>�F�>�

$*(17(� La clase en la que se ha cambiado el perfil de un evento de la que esta clase es agente.

35(&21',&,Ï1� A todos los argumentos se les debe asignar valor en la condición de disparo (deben existir variables con el mismo nombre y tipo).

'(6&5,3&,Ï1� Actualiza los disparos cambiando el perfil antiguo por el nuevo.

;&&,21(6�,192&$'$6�

madeShared 3��

B(5),/�'(/�6(59,&,2� �) =�)=��"�$0��"*�@��)��*��F�>*�@��)��*��=��>F�>�

$*(17(� La clase en la que se define un evento compartido.

35(&21',&,Ï1� El evento a compartir debe estar definido en la clase con el mismo perfil y no ser el ��!�ni el "��.

'(6&5,3&,Ï1� La evaluación modifica el atributo que define los eventos compartidos (shared) añadiendo la nueva información.


�

�

212

;&&,21(6�,192&$'$6�

makeComp 3��

B(5),/�'(/�6(59,&,2� �) =��)=�� %*�@��3��F��>*�@��"F��>��

$*(17(� La agregación a la que se le ha añadido esta clase como componente.

35(&21',&,Ï1� El nombre de la relación que liga a la clase componente con la agregación no puede haber sido definido con anterioridad como relación en la que participa esta clase.

'(6&5,3&,Ï1� Este servicio inserta la información en el atributo partOf. ;&&,21(6�,192&$'$6�

makeSuperClassPS@ 3�� 9��

B(5),/�'(/�6(59,&,2� �) =��)=�� $'%��$*@$'��*��"��F>*�@��*��'��F�>��) =��)=�� $'%��$�*�@$'��*��"��*�$'%��F>*� �� @��*��'��*��F�>��) =��)=�� $'%��$�*�@$'��*��"��*�$'%��F>*� �� @��*��'��*��=�>�F�>��) =��)=�� $'%��$�4*@$'��*��"��*�$'%��F>*�� @��*��'��*��=��=�>>�F�>��

$*(17(� Este servicio es invocado por la subclase en la que se ha invocado el servicio makeSubClassPS�., donde � es el sufijo del servicio invocado.

35(&21',&,Ï1� La condición de especialización debe ser consistente y sólo se pueden utilizar atributos constantes definidos en la clase.

'(6&5,3&,Ï1� La evaluación inserta la información en el atributo permSubClasses que define qué clases son especializaciones permanentes y cuál es la condición de especialización por la cual sus instancias se especializan. Al convertirse la clase en superclase de una especialización permanente, las instancias cuyos estados satisfagan la condición de especialización deben especializarse. Parte de la ejecución de este servicio evalúa la condición sobre las instancias de la clase, especializándolas permanentemente si la satisfacen. Como se deben de proporcionar los valores de los atributos de las propiedades emergentes de los objetos que se especializan, se han definido cuatro eventos que implementan cuatro posibles soluciones al problema de la adecuación de las poblaciones: • con el primer servicio (makeSuperClassPS) a las instancias que deban

migrar se les da el valor por defecto en función del tipo de datos definido como dominio de los atributos: 0 para nat, false para bool, etc.,

• con el segundo servicio (makeSuperClassPSP) se ejecuta una función de migración (SuperActions) que debe definir el diseñador que se encargue de asignar los valores adecuados para cada una de las instancias de la clase que deba migrar,

• con el tercer servicio (makeSuperClassPSV) a todas las instancias se les proporciona los mismos valores para todos los atributos emergentes, dichos valores se pasan en el argumento SuperAttList,

• con el último servicio definido (makeSuperClassPSVI) se asigna a los


�

213

atributos emergentes de cada instancia que deba migrar valores diferenciados, estos valores deben ser proporcionados por el diseñador cuando invoca este servicio en el argumento SuperAttList (en este caso será una lista de listas de valores de los atributos emergentes).

;&&,21(6�,192&$'$6�

makeSuperClassTS 3�� 9��

B(5),/�'(/�6(59,&,2� �) =��)=�� $'%�� $*�@�$'��F�>*�@��F�>�

$*(17(� Este servicio es invocado cuando una clase es convertida en superclase de una especialización temporal porque en la subclase se ha invocado el servicio makeSubClassTS.

35(&21',&,Ï1�

'(6&5,3&,Ï1� La evaluación inserta la información en el atributo tempSubClasses que define qué clases son especializaciones temporales.

;&&,21(6�,192&$'$6�

passAttDefinitionToSubClass

3�� '� ��

B(5),/�'(/�6(59,&,2� �) =��)=�%��5�� $'��*�@�$'��*��P��F�>*�@��*��F�>�

$*(17(� La subclase SubClass en la que se ha invocado el servicio getAttDefinitionFromSuperClass.

35(&21',&,Ï1� Este servicio se comporta como un borrado en la superclase, por lo tanto la precondición es muy similar a la definida para el borrado de atributos en la página 86. AttName debe ser un atributo constante o variable y no debe ser usado en la definición de la superclase o en las otras subclases diferentes de SubClass que pueda tener la superclase o en las agregaciones en las que participe la superclase o sus subclases.

'(6&5,3&,Ï1� La evaluación elimina la definición del atributo de los atributos consAtt o VarAtt (según sea un atributo constante o variable) y elimina el atributo de todas las instancias directas de la clase.

;&&,21(6�,192&$'$6�

relationChangedTo@ 7�� 8��

B(5),/�'(/�6(59,&,2� �) =�)=��0��" ��*�@��P��F�>*@��F�>��) =�)=��0��" �4��'�)�*�@��P��F�>*@��F�>��) =�)=��0��" �5��*�@��P��F�>*@��F�>��) =�)=��0��" �$��*�@��P��F�>*@��F�>��) =�)=��0��" ��)��'�"*�@��P��F�>*@��F�>��) =�)=��0��" ��'��)��'�"*�@��P��F�>*@��F�>��) =�)=��0��" �5�.��*�@��P��F�>*@��F�>��) =�)=��0��" �P��5�.��*�@��P��F�>*@��F�>��) =�)=��0��" ��2��*�@��P��F�>*@��F�>��) =�)=��0��" �$��*�@��P��F�>*@��F�>��) =�)=��0��" �P'��*�@��P��F�>*@��F�>��) =�)=��0��" �P��P'��*�@��P��F�>*@��F�>�


�

�

214

$*(17(� La agregación en la que se ha cambiado alguna propiedad de la relación con ésta clase componente.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia el atributo partOf que define el tipo de agregación en la que participa la clase. La semántica asociada a los cambios para estos servicios está comentada en los apartados del 4.3.7.5.3.5 al 4.3.7.5.3.16.

;&&,21(6�,192&$'$6�

relationNameChanged 7�� (��

B(5),/�'(/�6(59,&,2� �) =��)=��P��0��"*�@3�"P��*�P�!P��F>*�@��*��F�>�

$*(17(� La agregación en la que se ha cambiado el nombre de la relación con la que esta clase es componente.

35(&21',&,Ï1� El nuevo nombre de la relación tiene que ser distinto de los otros nombres de relación en los que participe la clase componente.

'(6&5,3&,Ï1� Este servicio modifica el atributo partOf para reflejar el nuevo nombre. Si la agregación en la que participa la clase es relacional, las instancias deben actualizar en su estado el nuevo nombre dado para identificar a los objetos compuestos con los cuales están relacionados.

;&&,21(6�,192&$'$6�

remAgent &��

B(5),/�'(/�6(59,&,2� �) =��)=��*�@�$��)��*��F�>*�@��)��*��F�>�

$*(17(� La clase en la que se elimina todos los disparos que apuntan a servicios definidos en esta clase.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Este evento elimina la información del atributo agent. ;&&,21(6�,192&$'$6�

removedShared 3��

B(5),/�'(/�6(59,&,2� �) =�)=��)�"$0��"*�@�$0��"�)��*��P��F>*@�)��*��F�>��

$*(17(� La clase en la que un evento deja de ser compartido.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Se elimina a la clase ClassName de la lista de clases con las que se comparte el evento. Si no queda ninguna clase con la que compartir el evento pasa a ser privado.

;&&,21(6�,192&$'$6�

� �

sharedSigChanged 7�� '��

B(5),/�'(/�6(59,&,2� �) =��)=0��"$��0��"*�@�3�"�)��*�P�!�)��*P�! �%��F>*�� @��)��*��)��*��=%��>�F�>�


�

215

$*(17(� La clase en la que ha cambiado el perfil de un evento compartido.

35(&21',&,Ï1� No puede existir un evento con el nuevo nombre en la clase. Los argumentos que no aparecen en el nuevo perfil que sí estaban definidos en el perfil antiguo no pueden ser usados en la precondición o en la evaluación asociada al evento en la clase o en las subclases. Si el evento participa en una transacción los nuevos argumentos del evento deben estar definidos en el perfil de la transacción o se les debe proporcionar valor en el cuerpo de la transacción. Los parámetros del nuevo perfil deben ser igual o más generales que los definidos previamente en la clase o en las subclases para el evento (��)��1�).

'(6&5,3&,Ï1� Modifica los atributos que definen los eventos de la clase, los tipos, las precondiciones y las evaluaciones (event, evType, evPre y evVal).

;&&,21(6�,192&$'$6� A las subclases se les invoca el servicio eventSigChangedInSuperClass para comunicarles que se ha cambiado el perfil de un evento en la superclase. A las clases agentes del evento que ha cambiado se les invoca el servicio eventSigChanged. A las clases compuestas se les invoca el servicio compEventSigChanged para que cambien el perfil del evento del componente en las expresiones de camino en las que se pueda invocar.

subClassNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =�)=�'��P��0��"*�@�3�"P��*�P�!P��F�>*�@��*��F�>�

$*(17(� La subclase que ha cambiado de nombre.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia el nombre de la subclase en el atributo tempSubClasses o permSubClasses dependiendo de si la subclase es temporal o permanente.

;&&,21(6�,192&$'$6�

��$��0��" 7�� '��

B(5),/�'(/�6(59,&,2� �) =�)=��$��0��"*�@3�" ��*P�! ��*�P�! �%��F>*�� @��*��*��=%��>�F�>

$*(17(� La clase en la que se cambia el perfil de una transacción de la que esta clase es agente.

35(&21',&,Ï1� En las condiciones de activación de los disparos se debe proporcionar valor a todas las variables definidas como argumentos de la transacción a disparar.

'(6&5,3&,Ï1� Actualiza los disparos cambiando el perfil antiguo por el nuevo.

;&&,21(6�,192&$'$6�

unmakeComp -��

B(5),/�'(/�6(59,&,2� �) =��)=�'�� %*��>*��>�

$*(17(� La agregación con la que esta clase deja de estar relacionada.

35(&21',&,Ï1� En la clase componente no pueden existir expresiones de camino que consulten atributos ni invoquen eventos de la clase compuesta.

'(6&5,3&,Ï1� Este servicio elimina la información del atributo partOf.


�

�

216

Si la agregación es relacional, en todas las instancias de la clase componente se debe de eliminar la información de que están en relación con objetos de la clase compuesta.

;&&,21(6�,192&$'$6�

unmakeSuperClassPS -�� 9��

B(5),/�'(/�6(59,&,2� �) =��)=�'�� $'%��$*@$'��F>*�@��F�>�

$*(17(� La subclase que deja de ser especialización permanente porque le han disparado el servicio unmakeSubClassPS.

35(&21',&,Ï1�

'(6&5,3&,Ï1� La evaluación elimina la información del atributo permSubClasses.

;&&,21(6�,192&$'$6�

unmakeSuperClassTS -�� 9��

B(5),/�'(/�6(59,&,2� �) =��)=�'�� $'%�� $*�@�$'��F�>*�@��F�>�

$*(17(� Este servicio es invocado en la superclase de una especialización temporal cuando la subclase deja de serlo porque le han disparado el servicio unmakeSubClassTS

35(&21',&,Ï1�

'(6&5,3&,Ï1� La evaluación elimina la información del atributo tempSubClasses.

;&&,21(6�,192&$'$6�

D��+��9��

attNameChangedInSuperClass

7�� '��(��

B(5),/�'(/�6(59,&,2� �) =�)=��P��0��"4�$'%��*�@�3�"P��*�P�!P��F�>*� �� @��*��F>�

$*(17(� La superclase en la que ha cambiado el nombre de un atributo.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia todas las referencias al antiguo nombre de atributo heredado OldName por el nuevo nombre NewName.

;&&,21(6�,192&$'$6� El cambio se propaga a las subclases que pueda tener la clase para que también actualicen su especificación. Si la clase es componente de alguna agregación, se invoca el servicio compAttNameChanged para que actualice las expresiones de camino que pueda haber definidas en la clase compuesta y que usen el atributo que ha cambiado de nombre.

eventSigChangedInSuperClass

7�� '�� '��(��


�

217

B(5),/�'(/�6(59,&,2� �) =�)=�)��$��0��"4�$'%��*@3�"�)��*P�!�)��*P�! �%��F>*�� @��)��*��)��*��=%��>�F�>�

$*(17(� La superclase en la que ha cambiado el perfil de un evento.

35(&21',&,Ï1� En las precondiciones o evaluaciones no se deben usar argumentos que no aparezcan en el nuevo perfil y los tipos de los argumentos deben ser igual o más generales que los tipos del antiguo perfil (��)��1�) En las transacciones en las que se vaya a cambiar el perfil del evento se debe obtener valor para todos los nuevos argumentos.

'(6&5,3&,Ï1� Cambia todas las referencias al antiguo perfil OldEvent por el nuevo NewEvent.

;&&,21(6�,192&$'$6� El cambio se propaga a las subclases que pueda tener la clase para que también cambien el perfil del evento. Si la clase es componente de alguna agregación, se invoca el servicio compEventSigChanged para que actualice las expresiones de camino que puedan haber definidas en la clase compuesta y que usen el evento que ha cambiado de perfil. A las clases agentes del evento se les invoca el servicio eventSigChanged. Si el evento es compartido, se invoca el servicio sharedSigChanged para que cambien el perfil.

superClassNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =�)=�'%��P��0��"*�@P�!P��F>*�@��F�>�

$*(17(� La superclase que ha cambiado de nombre.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia el nombre de la superclase del atributo superClass.

;&&,21(6�,192&$'$6�

tranSigChangedInSuperClass

7�� '�� '�� (��

B(5),/�'(/�6(59,&,2� �) =�)=��$��0��"4�$'%��*�@3 ��*P ��*�P �%��F�>*�� @��*��*��=%��>�F�>�

$*(17(� La superclase en la que ha cambiado el perfil de una transacción.

35(&21',&,Ï1� Los argumentos que no aparecen en el nuevo perfil no deben ser usados (para asignar valor a los argumentos de los eventos) en la especificación de la transacción en la subclase y los nuevos tipo deben ser igual o más generales que los antiguos (��)��1�).

'(6&5,3&,Ï1� Este evento cambia en el estado local del metaobjeto todas las referencias al antiguo perfil OTran por el nuevo NTran.

;&&,21(6�,192&$'$6� El cambio se propaga a las subclases que pueda tener la clase para que también cambien el perfil de la transacción. A las clases agentes del evento se les invoca el servicio tranSigChanged.

D��+��9��

attNameChangedInSuperClass

7�� '��(��

B(5),/�'(/�6(59,&,2� �) =�)=��P��0��"4�$'%��*�@�3�"P��*�P�!P��F�>*� �


�

�

218

� � � � ��@��*��F>�

$*(17(� La superclase en la que ha cambiado el nombre de un atributo.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia todas las referencias del antiguo nombre de atributo heredado OldName por el nuevo nombre NewName.

;&&,21(6�,192&$'$6� Si la clase en la que se ha invocado este servicio tiene subclases, el cambio se propaga a las subclases para que también cambien el nombre del atributo si es usado en su especificación. Si la clase es componente de alguna agregación, se invoca el servicio compAttNameChanged para que actualice las expresiones de camino que puedan haber definidas en la clase compuesta y que usen el atributo que ha cambiado de nombre.

eventSigChangedInSuperClass

7�� '�� '��(��

B(5),/�'(/�6(59,&,2� �) =�)=�)��$��0��"4�$'%��*@3�"�)��*P�!�)��*P�! �%��F>*�� @��)��*��)��*��=%��>�F�>�

$*(17(� La superclase en la que ha cambiado el perfil de un evento.

35(&21',&,Ï1� En las precondiciones o evaluaciones no se deben usar argumentos que no aparezcan en el nuevo perfil y los tipos de los argumentos deben ser igual o más generales que los tipos del antiguo perfil (��)��1�) En las transacciones en los que se vaya a cambiar el perfil del evento se debe de obtener valor para todos los argumentos nuevos.

'(6&5,3&,Ï1� Cambia todas las referencias al antiguo perfil OEvent por el nuevo NEvent. ;&&,21(6�,192&$'$6� Si la clase en la que se ha invocado este servicio tiene subclases, se propaga

el cambio a las subclases para que también cambien el perfil del evento si es usado en su definición. Si la clase es componente de alguna agregación, se invoca el servicio compEventSigChanged para que actualice las expresiones de camino que puedan haber definidas en la clase compuesta y que usen el evento que ha cambiado de perfil. A las clases agentes del evento se les invoca el servicio eventSigChanged. Si el evento es compartido, se invoca el servicio sharedSigChanged para que cambien el perfil.


�

219

superClassNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =�)=�'%��P��0��"*�@P�!P��F>*�@��F�>�

$*(17(� La superclase que ha cambiado de nombre.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia en el nombre de la superclase del atributo superClass.

;&&,21(6�,192&$'$6�

D��

compAttNameChanged 7��

B(5),/�'(/�6(59,&,2� �) =�)=��%��P��0��"*@��P��*3�"��P��*P�!��P��F>*�� @��*��*��F�>�

$*(17(� La componente en la que ha cambiado el nombre de un atributo.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia todas las referencias al antiguo nombre de atributo OldName del componente ClassName por el nuevo nombre NewName en las expresiones de camino.

;&&,21(6�,192&$'$6�

compClassNameChanged

7��

B(5),/�'(/�6(59,&,2� �) =�)=��%��P��0��"@3�"P��*P�!P��F�>*� � �� @��*��F>�

$*(17(� La componente en la que ha cambiado el nombre.

35(&21',&,Ï1�

'(6&5,3&,Ï1� Cambia el nombre de la clase componente del atributo componentClass.

;&&,21(6�,192&$'$6�

compEventSigChanged 7�� '��

B(5),/�'(/�6(59,&,2� �) =�)=��%�)��$��0��"*@��P��*3�)��*P�)��*P �%��F>*�� @��*��)��*�)��*��=%��>�F�>�

$*(17(� La componente en la que ha cambiado el perfil de un evento.

35(&21',&,Ï1� A los nuevos argumentos del evento se les debe de proporcionar valor en el cuerpo de la transacción o bien tener el mismo nombre y tipo que algunos de los definidos en el perfil de la transacción.

'(6&5,3&,Ï1� Cambia el perfil en las expresiones de camino en las que se use el evento en el cuerpo de las transacciones.

;&&,21(6�,192&$'$6�

passAttDefinitionToSubClass

3�� '� ��


�

�

220

&;7(16,Ï1�'(/�6(59,&,2�

�) =�)=%��5�� $'��*@$'��*��P��F�>*�@��*��F>�

35(&21',&,Ï1� Además de lo definido para las clases elementales, si la clase sobre la que se invoca este servicio es una agregación, no podrá eliminarse el atributo si es usado en expresiones de camino en los componentes relacionales.

�

;�� 71� &�� D��

:;+0+�

(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�

223

En este apéndice se presentan tres ejemplos de utilización de la metaclase OASIS para:

1. Definir un sistema de información.

2. Solucionar el problema del año dos mil de un sistema.

3. Modificar un esquema existente con clases pobladas.

En los ejemplos se muestran los objetivos a lanzar en el intérprete de ��. Como se puede observar la

sintaxis es pesada porque hay que identificar perfectamente al objeto sobre el que se invoca el evento y

además hay que conocer la plantilla de las metaclases definidas para realizar consultas. Justamente para

aliviar la complejidad asociada a la escritura de los objetivos, se desarrolló la interfaz gráfica presentada

en el capítulo 5 que facilita el uso de la metaclase pudiendo elegir visualmente el objeto que interesa, ver

el estado del mismo o escoger el evento a disparar, pudiendo escribir en una ventana los argumentos que

necesite el evento.

/��F��

Si hay un ejemplo que no puede faltar en un texto de informática es el de la definición del sistema de

información de una biblioteca cuyo DCC se puede observar en la siguiente figura.

M ember Book

Borrow

M arkedM ember

A continuación se presentan la traza de eventos que definen el esquema conceptual de la biblioteca,

haciendo uso de los servicios que se han definido en el capítulo 4, se crean dos instancias del esquema

para prototiparlo creando libros, apuntando socios y prestado los libros a los socios.

Lo primero que hay que hacer es crear una nueva instancia de la metaclase en la que se definirá el

esquema de la biblioteca

��@��)=��!4��*�@#��,�F�>��?��4��Y�F�


�

�

224

El evento newInstance devuelve el oid del esquema en la variable LIBRARY.

En los siguientes eventos, con el fin de facilitar la lectura, se han sustituido los oid de los objetos a los que

van dirigidos los eventos por las variables con las que los eventos ��! devuelven los oid de los objetos.

De manera que, siempre que aparezca una variable como identificador del objeto al que va dirigido el

evento habrá que sustituirla por el oid del objeto que proporciona el evento ��! cuando se crea dicho

objeto.

A continuación cambiamos los eventos ��!�y "�� de la biblioteca.

�4��Y��@��)=��0��P�!*�@��)=��!4��*��>*��)=��!��*��>*��F�>F�

�4��Y�@��)=��0��5��*�@�"��F�>F�

Se define el atributo nombre de las bibliotecas y un alias que utiliza el nombre para identificar a las

instancias que se creen del esquema “Library”.

�4��Y�@��)=��""��*�@��*��F�>F�

�4��Y�@��)=��""��*�@��*�@��F�F�>F�

A continuación se crea una instancia de la metaclase elemental_class en el esquema de la biblioteca.

�=�4��Y*��>��@��)=��!��*�@�#��,�F�>��?��F�

En la variable MEM se devuelve el oid del metaobjeto en el que se va a definir la plantilla de la clase

“Member”.

A continuación se crean los atributos constantes y variables de la clase “Member”.

��@��)=��""��*�@�"��*��F�>�F�

80 De manera alternativa, haciendo uso del alias definido en la metaclase OASIS se puede identificar al esquema con

el sustituto: id( “oasisMetaclass”, cs, [ “Library” ] )

81 También se puede identificar la metaclase por el sustituto: c( id( “oasisMetaclass”, cs, [ “Library” ] ), class(

“elemental_class” ) ).


�

225

��@��)=��""��*�@��*��F�>�F�

��@��)=��""��*�@�0�� *��*�E�F�>�F�

��@��)=��""��*�@��*��*��F�>�F�

Se cambia la restricción de integridad de la clase.

��@��)=��0��*�@��=��=�"��*�P>*��=��=P*�6>*��=P*�6EEEE>>>�F�>�F�

Se define un alias.

��@��)=��""��*�@�"��*�@�"��F�F�>�F�

Se cambian los nombres de los eventos ��! y "�� por defecto.

��@��)=��0��P�!*�@��)=��!*��>*��)=��!��*��>*��F�>F�

��@��)=��0��5��*@�"��F�>F�

Se cambia la precondición del evento "��.

��@��)=��0��*�@��)=�"��*��>*��=��=�0�� *�P>*��&'��=P*�E>�>�F�>�F�

Se añade el evento borrow y se cambia la precondición y la evaluación por defecto.

��@��)=��""�)��*�@��)=��!*��>*��F�>�F�

��@��)=��0��*�@��)=��!*��>*��=��=�0�� *�P>*��=P*�6E>�>�F�>�F�

��@��)=��0��*�@��)=��!*��>*��

� � �=��=�0�� *�P>*��=�'�=P*�6*��>*��%=��=�0�� *��>�>�>�>�F�>F�

Se añade el evento return y se cambia la evaluación por defecto.

��@��)=��""�)��*�@��)=��'��*��>*��F�>�F�

��@��)=��0��*�@��)=��'��*��>*� � � � � � �

� � �=��=�0�� *�P>*��=�'�=P*�6*��>*��%=��=�0�� *��>�>�>�>�F�>�F�

Se añade el evento mark por el que se especializarán las instancias de la clase “Member”

82 Alternativamente se puede identificar al metaobjeto creado a través del alias definido en la metaclase

elemental_class con el sustituto: o( id( “oasisMetaclass”, cs, [ “Library” ] ), id( “elemental_class”, class, [

“Book” ] ) )


�

�

226

��@��)=��""�)��*�@��)=�� *��>*��F�>�F�

��@��)=��0��*�@��)=�� *��>*��=��*��>�F�>�F�

��@��)=��0��*�@��)=�� *��>*��%=��=��*��'��>�>�F�>�F�

Se define el proceso de la clase “Member”

��@��)=��""��*�@��!*��!��*�6�F�>�F�

��@��)=��""��*�@�6*��!*�6�F�>�F�

��@��)=��""��*�@�6*��'��*�6�F�>�F�

��@��)=��""��*�@�6*�� *�6�F�>�F�

��@��)=��""��*�@�6*�"��*�"��F�>�F�

A continuación se define la clase “MarkedMember”.

�=�4��Y*��>@��)=��!��*�@#�� "��,F�>�?��F�

Se cambia el nombre del evento ��!�de “MarkedMember”.

��@��)=��0��P�!*�@��)=��!*��>*��)=�� *��>*��F�>�F�

Se define que “MarkedMember” es una especialización temporal de “Member”.

��@��)=�� $'�� $*�@#��,F�>�F�

Se cambia el nombre del evento "�� de la clase “MarkedMember”.

��@��)=��0��5��*�@�'�� F�>�F�

Se redefine la precondición del evento borrow en la especialización.

��@��)=��0��*�@��)=��!*��>*��=��=�0�� *�P>*��=P*�:>�>�F�>�F�

Se define el proceso de la clase “MarkedMember”

��@��)=��""��*�@��!*�� *�6�F�>�F�

��@��)=��""��*�@�6*��!*�6�F�>�F�

��@��)=��""��*�@�6*��'��*�6�F�>�F�

��@��)=��""��*�@�6*�'�� *�"��F�>�F�


�

227

A continuación se define la clase “Book”.

�=�4��Y*��>@��)=��!��*�@#�� ,F�>��?��33]�F�

�33]@��)=��""��*�@��"�� *��F�>�F�

�33]@��)=��""��*�@��*��F�>�F�

�33]@��)=��""��*�@��'�0��*��F�>�F�

�33]@��)=��""��*�@��)��*��*��'��F�>�F�

�33]@��)=��""��*�@�� *�@��"�� F�F�>�F�

�33]@��)=��0��P�!*�@��)=��!*��>*��)=�'�� *��>*��F�>�F�

�33]@��)=��0��5��*�@�"��%�� F�>�F�

�33]@��)=��0��*�@��)=�"��%�� *��>*��=��=��)��*�5>*��&'��=5*��'�>�>�F�>�F�

�33]@��)=��""�)��*�@��)=��!*��>�F�>�F�

�33]@��)=��0��*�@��)=��!*��>*��=��=��)��*�5>*��&'��=5*��'�>�>�F�>�F�

�33]@��)=��0��*�@��)=��!*��>*��%=��=�)��*��>�>�F�>�F�

�33]@��)=��""�)��*�@��)=��'��*��>�F�>�F�

�33]@��)=��0��*�@��)=��'��*��>*��=��=��)��*�5>*��&'��=5*��'�>�>�F�>�F�

�33]@��)=��0��*�@��)=��'��*��>*��%=��=�)��*��>�>�F�>�F�

�33]@��)=��""��*�@��!*��'�� *�6�F�>�F�

�33]�@��)=��""��*�@�6*��!*�8�F�>�F�

�33]�@��)=��""��*�@�8*��'��*�6�F�>�F�

�33]�@��)=��""��*�@�6*�"��%�� *�"��F�>�F�

Se define la clase “Loan” y se convierte en una agregación.

�=��4��Y�*��>@�)=��!��*@#��,F�>��?��3�P�F�

�3�P�@��)=��""��*�@�"��*��F�>�F�

�3�P@��)=��""��*�@��"��*��F�>�F�

�3�P@��)=��""��*�@��*�@�"��*��"��F�F�>�F�

�3�P�@��)=��0��P�!*�@��)=��!*��>*��)=��!*��>*��F�>F�

�3�P@��)=��0��5��*�@��'��F�>F�

�3�P@��)=��""��*�@��!*��!*�6�F�>�F�

�3�P�@��)=��""��*�@�6*��'��*�"��F�>�F�

�3�P@��)=�� *��>�F�

Para controlar que los valores que se introduzcan en el atributo date sigan un formato determinado se

define la siguiente restricción de integridad:


�

�

228

�3�P@��)=��0��*�@��"=��="��*�5� �>*��

��"=�'��=5� �*�:*�8*��>*�

��"=��8��=�*��4>*�

��"=��=�4*�6:>*�

��"=��=��4*�E�>*�

��"=�'��=5� �*�;*�8*�5>*�

� ��"=��8��=�5*�54�>�*�

��"=��=5*�E>*��=5*�:8>>�

� � � � >>>>>>>�F�>�F�

Se definen los componentes de la agregación y sus propiedades.

�3�P�@��)=��""��%*�@�#�� ,*�� F�>F�

�3�P�@��)=��0�� $��*�@�� F�>F�

�3�P�@��)=��0�� )��'�"*�@�� F�>F�

�3�P�@��)=��0�� 5�.��*�@�� F�>F�

�3�P�@��)=��0�� P'��*�@�� F�>F�

�3�P�@�)=��""��%*�@�#��,*��F�>F�

�3�P�@�)=��0�� $��*�@��F�>F�

�3�P�@�)=��0�� )��'�"*�@��F�>F�

�3�P�@�)=��0�� P'��*�@��F�>�F�

En este momento se ha acabado de definir el esquema conceptual de la biblioteca y se está en condiciones

de crear diferentes prototipos del sistema definido. Para empezar, se crea la biblioteca de la “Technical

University of Valencia” haciendo uso del evento ��!�del esquema conceptual que fue renombrado.

�4��Y@��)=��!��*�@�# ��0��)��,�F�>��?��4�6�F�

Se compran tres libros. Como se puede apreciar, los argumentos del evento ��!� son los valores que

tomarán los atributos constantes del objeto que se va a crear ordenados por orden alfabético del nombre

del atributo (author, id_book y title).

�=�4�6*��=#�� ,>�>�@��)=��'�� *�@�#��)��,*�#P�EE6,*�V��\'�.��"��0�VF>�

� � � � � � � � � � ��?��6�F�

�=�4�6*��=#�� ,>�>�@��)=��'�� *�@�#�0�,*�#4�EE6,*�V��%��,�F>��?��8�F�


�

229

�=�4�6*��=#�� ,>�>�@��)=��'�� *�@�#��/,*�#4�EE8,*�V ��'��,�F>��?��:�F�

Se crean tres socios.

�=�4�6*��=#��,>�>�@��)=��!��*�@�8E6;[6EE*�#A�(�9��-,�F>��?��6�F�

�=�4�6*��=#��,>�>�@��)=��!��*�@�<I6:[::J*�#4�"��,�F>��?��8�F�

�=�4�6*��=#��,>�>�@��)=��!��*�@�8ID<;[8J*�#A�(��/,�F>��?��:�F�

Se realiza el primer préstamo del libro cuyo identificador es “N-001” al socio con dni 20158100 el día

12/2/99. Como se puede observar, los argumentos del servicio son: primero los valores de los atributos

constantes del objeto que se va a crear y después los identificadores de los objetos relacionados en el

préstamo.

�=�4�6*��=#��,>�>�@�)=��!*�@�VIIE868V*�6*��"=�� *�@#P�EE6,F�>*� � �

� � � � � � � �"=�"��*�@8E6;[6EEF�>�F�>��?��6�F�

Se realizan dos préstamos más.

�=�4�6*��=#��,>�>�@�)=��!*�@�VIIE868V*�8*��"=�� *�@#4�EE6,F�>*� � �

� � � � � � � �"=�"��*�@<I6:[::JF�>�F�>��?��8�F�

�=�4�6*��=#��,>�>�@�)=��!*�@�VIIE86DV*�6*��"=�� *�@#4�EE8,F�>*� � �

� � � � � � � �"=�"��*�@8ID<;[8JF�>�F�>��?��8�F�

Se especializa al socio cuyo dni es 20158100.

�=��"=�#��,*��*�@# ��0��)��,�F�>*� � � �

� � � � � ��"=�#��,*�"��*�@8E6;[6EEF�>�>�@��)=�� *��>�

F�

Se crea otra biblioteca, esta vez la de la “University of Valencia”.

�4��Y@��)=��!��*@#��)��,F>��?��4�8F�

Se compran libros.

�=�4�8*��=#�� ,>>�@�)=��'�� *@�#��0��,*�#E�;[8�;:;DJ�<,*�VA�!�8VF>�?�DF�

�=�4�8*��=#�� ,>>�@�)=��'�� *@�#��"��!��,*�#6�[;:8<�66;�J,*� � �

� � � � � ��V ��]��0'�VF�>��?��;�F�


�

�

230

Etc.

7��

A continuación se muestran algunas de las consultas que se pueden realizar. Como se puede ver es posible

preguntar por cualquier aspecto relacionado con la especificación del sistema o con la animación de

cualquiera de los prototipos creados.

¿Qué instancias de la metaclase elemental_class en la biblioteca tienen definido un atributo cuyo

nombre es has_books?

��7��=�4��Y*��>�M��@�)��?��F�M��P��=��*�0�� >��

¿Qué clase de agregación hay definida entre las clases “Member” y “Loan”?

�=��"=�#��,*��*�#��,>*��"=�#��,*��*�#��,>�>� � �

� @��%��??��%=�#��,*��P��*��*�$��*��)��'�"*�5�.��*�

� � � � ��2��*�P'��>�F�

¿Qué eventos modifican el atributo has_books en la clase “Member”?

��@��)��??��)��=��P *��>�F�M�'��4�$��=��*�0�� >��

¿Qué socios no son socios marcados en la primera biblioteca?

�=�4�6*��=#��,>�>@��2��?��F�M��

� � � � � ��=��=�4�6*��=#�� "��,>�>@��2��?��F�>�

¿Cuántos libros tiene en préstamo el socio 20158100 de la primera biblioteca?

�=�4�6*��"=#��,*�"��*�@8E6;[6EEF�>>@�0�� ?�9�$�F�

83 attName es una función definida que dado un atributo devuelve el nombre del mismo.

84 useAttInSerialAction es un predicado que busca si en la valuación que se pasa como primer argumentos se usa el

atributo que se pasa como segundo argumento.


�

231

¿Cuáles son los libros que tenemos en la primera biblioteca?

�=�4�6*��=#�� ,>>@��2��??��33]$�F�

¿Cuáles estan disponibles en la primera bilioteca?

�=�4�6*��=#�� ,>>@��2��??��33]$�F�M��33]$@��)��?��'��F�

¿Cuáles son los libros que tenemos en la segunda biblioteca?

�=�4�8*��=#�� ,>>@��2��??��33]$8�F�

¿Hay algún libro con el mismo título en las dos bibliotecas?

�=�4�6*��=#�� ,>>@��2��??��33]$�F�M��33]$@��?� 4 ��F�M��

� � �=�4�8*��=#�� ,>>@��2��??��33]$8�F�M��33]$8@��?� 4 ��F�

�


�

�

232

&�� H��%AAA�

Conforme se acerca el cambio de siglo, uno de los mayores problemas con los que se están encontrando

las empresas desarrolladoras de software proviene del hecho de que no se pensó en su momento que dos

dígitos no eran suficientes para hacer comparaciones en el próximo siglo.

Aprovechando el ejemplo de la biblioteca presentado con anterioridad, se va a corregir dicho problema

definiendo un nuevo TAD con capacidad para almacenar los años con 4 dígitos.

%��@��)=��!5��*�@��5��F�>�F�

Se define el constructor de las fechas.

�5��@��)=��""��'��*�@�"��=��*��*�5�>*�@�@�*��F*�@�*��F*�@�*��F�F�F�>�F�

Como se va a cambiar la definición de un atributo es interesante conocer dónde se está usando dicho

atributo porque se debe eliminar primero las referencias de dicho atributo para poder modificarlo. Las

siguientes consultas tendrán éxito cuando detecten que se usa el atributo date en los alias, las formulas de

derivación, las precondiciones o las condiciones de disparo, respectivamente.

�3�P@��??��=��P��*��>�F�M��=�"��*��>�

�3�P@�"��??��5=�5��P��*� �%�*�5��>�F�M�'��4��'��=�5��*�"��>��

�3�P@��)��??��)��=��)��*��"�>�F�M�'��4��'��=��"*�"��>�

�3�P@��??��=��"*��>�F�M�'��4��'��=��"*�"��>�

Tras evaluar los objetivos anteriores se puede comprobar que el atributo date se usa para definir el alias

loan y la restricción de integridad de la clase. Los pasos a seguir para cambiar la definición del atributo

son:

1. Eliminar la definición del alias.

�3�P@��)=��)��*�@��F�>�F�

85 useAttInFormula es un predicado que busca si en la fórmula que se pasa como primer argumento aparece la

consulta del atributo cuyo nombre se pasa como segundo argumento.


�

233

2. Eliminar la restricción de integridad.

�3�P@��)=��0��*�@��'��F�>�F�

3. Cambiar la definición del atributo. Como no deseamos que se produzca perdida de información y la

función de conversión de tipos entre un string y un tDate no está definida, se utiliza una función de

conversión que calcula para cada instancia de la clase el nuevo valor del atributo.

�3�P@��)=��0�� %��*�@�"��*��5��*��=��=�"��*�5$�>*��

� �=�'��=�5$*�6*�8*��$�>*� �

� ��=��=#6I,*�$*P�$>*� �

� ��=��8��=P�$*�P��>*��

� ��=�'��=5$*�:*�8*��$>*��

� ��=��8��=�$*�P�>*�

� � �=�'��=5$*�;*�8*�5$>*�

� � ��=��8��=5$*�P5>*�

� � ��%=��="��*"��=P�*P�*�P5>>>�

� >>>>>>>>�F�>�F�

4. Definir la restricción de integridad.

�3�P@��)=��0��*�@��"=��="��*�"��=�*��*�5>�>*��

��"=��=�*�6:>*�

��"=��=��*�E�>*�

��"=��=5*�E>*��=5*�:8>>�

� � � � >>>�F�>�F�

5. Definir el alias.

�3�P@��)=��""��*�@��*�@�"��*��"��F�F�>�F�

Los ejemplos presentados pueden parecer complicados por la sintaxis. Para aliviarla, la IGU facilita la

introducción de los valores de los argumentos de los servicios permitiendo la introducción de las fórmulas

con notación infija validándolas sintáctica y semánticamente y trasformándolas a notación prefija de

forma automática.


�

�

234

;H� ��(��

En cualquier momento es posible modificar el esquema creado aunque las clases estén pobladas. A

continuación se muestra como introducir en la biblioteca las revistas para que estas puedan también ser

prestadas a los socios. Se introduce una clase llamada “Document” en la que se especializan los libros y

las revistas. La siguiente figura ilustra lo que se desea hacer mostrando los DCC de partida y de llegada.

Member Book

Borrow

MarkedMember

Member Document

Borrow

MarkedMember Book Magazine

Para ello, primero se cambia el nombre a la clase “Book” por “Document”, se cambian los eventos ��! y

"��, el nombre del atributo id_book y el nombre del alias por otros más acordes con su condición de

documentos.

�=��4��Y*��"=#��,*��*�@#�� ,F�>>@��)=��0��P��*�@�#5��'��,�F�>�F�

�=��4��Y*��"=#��,*��*�@#5��'��,F>>�@�)=�0��P�!*@��)=��'�� *��>*�

� � � � � � � � �)=��!�"��'��*��>*��F�>�F�

�=�4��Y*�"=#��,*��*@#5��'��,F>>�@�)=�0��5��*@"��%�"��'��F>F�

�=�4��Y*�"=#��,*��*@#5��'��,F>>� � � � �

� � � � � � @�)=��0��P��*@��"�� *��"�"��'��F>F�

�=�4��Y*��"=#��,*��*@#5��'��,F>>� � � � �

� � � � � � @��)=��0��P��*�@�� *�"��'��F>F�

Para poder distinguir a los libros de las revistas se añade el atributo kind a la clase “Document”. Como los

objetos que existen en este momento en la clase son todos libros se les da a todos el valor “B” para el

atributo.

�=�4��Y*�"=#��,*��*@#5��'��,F>>�@��)=��""��*�@ ��"*��*#�,F>F�


�

235

Como los únicos valores válidos del atributo kind son “B” y “M” se define una restricción de integridad

que lo asegure.

�=�4��Y*�"=#��,*��*@#5��'��,F>>� � � � �

� � � � @��)=��0��*�@��=��= ��"*�#�,>*��= ��"*�#�,>>�F�>�F�

Se crea la nueva clase “Book”.

�=�4��Y*��>@��)=��!��*�@#�� ,F�>��?�P�_�33]�F�

Y se define que la clase “Book” es una especialización permanentemente de la clase “Document”. La

condición de especialización de los documentos en libros será que en su atributo kind tengan un valor

“B”. Como en la subclase no se han definido atributos emergentes no es necesario definir qué valores se

debe dar a las instancias de “Document” cuando se especialicen en la clase “Book”. De la misma manera,

como la clase “Book” no tiene instancias no hay que decir que valores hay que asignar a las propiedades

heredadas de la clase “Document”.

P�_�33]@��)=�� $'��$*�@�#5��'��,*��=� ��"*�#�,�>�F�>�F�

En la definición de la clase “Document” hay dos atributos que no pertenecen realmente a los documentos

sino a los libros. Las definiciones de los atributos title y book son pasadas de la superclase “Document” a

la subclase “Book”.

P�_�33]@��)=��5��$'%��*�@��F�>�F�

P�_�33]@��)=��5��$'%��*�@��'�0��F�>�F�

Se crea la clase “Magazine”.

�=�4��Y*��>@��)=��!��*�@#��1��,F�>��?��B�F�

Se define que la clase “Magazine” es una especialización permanentemente de la clase “Document”. La

condición de especialización de los documentos en libros será que en su atributo kind tengan un valor

“M”. Como no hay ningún documento en este momento que sea una revista, no se especializará ningún

documento en revista.

��B@��)=�� $'��$*�@�#5��'��,*��=� ��"*�#�,�>�F�>�F�

A continuación se definirían las propiedades de la clase “Magazine” y se continuaría trabajando creando

documentos, revistas o libros y pudiendo prestar cualquier documento a los socios.

�

;�� -1� ;�� '��

:;+0+��2./�

$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�

239

Aunque no es el objetivo central del presente trabajo, presentamos en este apéndice el conjunto de

transacciones �� que permite animar las especificaciones de los esquemas conceptuales que se definan

haciendo uso de la metaclase OASIS presentada y validar si los requerimientos del usuario se satisfacen

en el modelo que se diseñe del sistema. Dichas transacciones implementan el modelo de ejecución de

eventos presentado en la página 17.

En las transacciones siguientes no se tiene en cuenta el posible comportamiento concurrente de las

especificaciones ya que la �� no lo es. Existe una extensión concurrente de la �� con

conectivas que modelan la ejecución concurrente de procesos complejos [Bon99]. Redefiniendo las

transacciones siguientes, teniendo en cuenta las peculiaridades que introduce la concurrencia en la

animación, se podrían animar especificaciones OASIS concurrentes.

Primero se presentan las transacciones que implementan los servicios de creación y destrucción de

instancias de los esquemas conceptuales que se encargan de crear los prototipos ejecutables por

animación; seguidamente, se presentan las transacciones que implementan los cambios de estado fuertes

(creación y destrucción de objetos) y finalmente, se muestran las transacciones que implementan los

cambios de estado débiles (cambios en el estado de un objeto).

7��8� �� (��

El servicio de creación de instancias de un esquema conceptual tiene la reificación en �� que se muestra

a continuación:

�$@��)=�P�!�)*��>��?�3�"�F�O��

� Q��$�"��"��'��"��3�$4$�=��>�

� �$�7��

� Q�P�!�)�"��"��"��)��!�

� �$@��!��??��)=P�!�)*��>�F��

� Q��"�"��"��"��

� �$@��2��$��?��$4�F��=�$@��4"�?P�F>�"��'�=P*�6*�P6>��=�$@��4"�?P4�F>��

� Q��$4��"��&'��$�

� =��$4�7��$�>��

� Q��2��)��"��'��=��>��'��"��)��=��>�

� �2��'��=�$*��*��*�P�!�)*��*��>��

� Q��%�'��&'��%��"��-��"��)��!�

� �$@��)��??��)��=��)=�P�!�)*��>*��>�F��)��=��$*��>��

� Q��"��)��'��)��"��$4�


�

�

240

� �$@��?��F��=��$4*��*��*��>��

� �$@�)��?��F��=��$4*��*��>��

� Q��%�'��&'��'�)��"'��"'%��"�"��

� ��&'�=��$*��$4�>��

� Q��.��'��&'��"��)��'��-��"��)��!�

� �$@��)��??��)��=��)=�P�!�)*��>*�$��>�F��)��$�=��$4*�$��>��

� Q��%�'��&'��-��"��"��$4�

� �$@��?��F��)��=��$4*��>��

� Q��Z�"��)��1��"��$4�

� =��$4@��?�@��)=�P�!�)*��>��F�>��

Figura 32: Reificación en �� del evento ��! de los esquemas conceptuales

La transacción extractArguments extrae, de la lista de argumentos con la que se ha invocado el servicio

(ArgList), los primeros que darán valor a los atributos definidos en el esquema (AttList) y los siguientes

(Args) que serán los definidos para el evento NewEv y se utilizarán para evaluar la precondición y/o

evaluación asociada en el caso de que se hayan definido.

Las transacciones fillConsAtt y fillVarAtt dan valor a los atributos constantes y variables, respectivamente,

del objeto CSI a partir de los valores de AttList.

La transacción aliasUnique comprueba que el nuevo objeto no introduce duplicidad en los alias que se

hayan podido definir con antelación, probando si los valores asignados a los atributos constantes en el

nuevo objeto que hayan sido definidos como mecanismos de identificación no son los mismos que los que

identifiquen a ningún otro objeto que ya exista.

En el instante de creación, una instancia de un esquema está compuesta por las clases cuyas plantillas se

definieron en el esquema. Dichas clases no tienen población, ofrecen los servicios de factoría, y su

plantilla la obtienen a través de una vista por proyección del metaobjeto que contiene en su estado la

codificación de la plantilla. Los identificadores de las clases están formados por un par cuyo primer

elemento es el identificador de la instancia del esquema y el segundo elemento es el mismo átomo que

tiene el metaobjeto que define con su estado la plantilla. Por ejemplo, si en el esquema CSi existe un

metaobjeto MOj cuyo oid es o(CSi, J) y se crea una instancia del esquema con oid DBi, ésta contendrá

una clase cuyo identificador será c(DBi, J). De esta forma existe una clara relación entre la clase y el

metaobjeto que describe su plantilla. En la página 167 se mostró una caracterización precisa del concepto

de clase OASIS en ��.


�

241

El evento de destrucción de instancias de los esquemas destruye la instancia cuyo identificador se pase

como argumento. A continuación se puede observar la reificación del evento "�� de los esquemas:

�$@��)=�5��)*�@�4"��F�>�F�O��

� Q��$��&'��'��"��3�$4$�

� �$�7��

� Q��"�=�$4>�"��"��"��'��

� �$@��3�"=4"��>��?��$4�F��

� Q��&'��"��"��5��)��)��"��

� �$@�"��?��)=5��)*��>�F��

� Q��)+��"��T��1��"��$4��"��%��-��"��%��"��&'��$�

� )��"P�2��)��=��$*��$4*�5��)�>��

� Q��%�'��&'��%��"��-��"��)��

� �$@��)��??��)��=�)=�)5��*��>*��"�>�F��)��=��$4*��"�>��

� Q��"��'��"��0��0��"��$4�

� "��$4��=��$4*��$�>��

Figura 33: Reificación en TFL del evento "�� de clases elementales

La transacción validNextEvent comprueba que dada la descripción de proceso definida en el esquema

CS y la traza de eventos de la instancia CSI se puede ejecutar el evento DestroyEv.

La transacción destroyCSInstance elimina toda la información que tenga como identificador a CSI.

7�� '��

7��

Las clases elementales ofrecer los servicios de factoría que las caracteriza. A continuación se muestra la

transacción que crea instancias de cualquier clase elemental.

�@��)=�P�!�)*��>��?�3�"�F�O��

� Q��&'��'��

� ��7��

� Q��.��&'��"��'�%��"��"��

� � �@��.��?��F��

� ��7��=�*��>��=��7��=�*��>�"��7��=�*�%��>�"��7��=�*��>�>��


�

�

242

� Q�P�!�)�"��"��"��)��!�

� �@��!��??��)=P�!�)*��>�F��

� Q�"��"��&'��&'��'��"�

� Q��"��.��"��"��

� ��N��=�$4*�>��$4@��2�3�"��?�3�"F��$4@�)=��4"*��>F��

� Q��3�"��.��&'/��"��

� =�3�"�7��>��

� Q��2��)��"��'��=��>��'��"��)��=��>�

� �2��'��=�*��*��*�P�!�)*��*��>��

� Q��%�'��&'��%��"��-��"��)��

� �@��)��??��)��=��)=�P�!�)*��>*��>�F��)��=��*��>��

� Q��"��)��'��)��%��"��

� �@��?��F��=�3�"*��*��*��>��

� �@�)��?��F��=�3�"*��*��>��

� Q��.��'��&'��0��"��"��.��3�"�

� �@��)��??��)��=��)=�P�!�)*��>*�$��>��)��$�=�3�"*�$��>��

� Q��%�'��&'��3�"��0��"'��"��"'%��"�"��"��

� ��&'�=��*�3�"�>��

� Q��%�'��&'��-��"��"�"�

� �@��?��F��)��=�3�"*��>��

� Q��"��%��1��.��"��%��1��

� %��1��P�!=�3�"*��*�P�!�)*��*��8�>��

� Q��"��.��"��.��0��

� ��%��0�)��'�P�!=�3�"*��*��8�>��

� Q��Z�"��)��P�!�)��1��"��.��1��

� =�3�"@��?�@��)=�P�!�)*��>��F�>��

� �@�%��??�%�=��!*�P�!�)*�$��>�F��=�3�"@��?�$��F�>��

� Q��1��"�%��'��"��-��"��"�%��

86 Esto es consistente con lo que define el estándar ODMG [Cat94] que indica que el encargado de asignar

identificadores a los objetos es el sistema gestor de base de datos (en este caso las instancias de los esquemas

conceptuales) garantizando, de esta forma, la unicidad de los identificadores en cada una de las instancias de los

esquemas conceptuales.


�

243

� ��=�3�"�>�

Figura 34: Reificación en �� del evento ��! de las clases elementales

La transacción specializationNew comprueba si el evento NewEv se ha definido como evento ��! de

alguna especialización temporal (con lo que habrá que especializar temporalmente al objeto Oid en la

subclase) o si se satisface alguna condición de especialización definida en alguna especialización

permanente (con lo que habrá que especializa permanentemente al objeto). Los valores que deban tomar

los atributos emergentes del objeto se pasan en ArgRest.

La transacción compBehaviourNew comprueba si la clase C está relaciona por agregación con alguna

otra clase y si es necesario establecer un vínculo entre el objeto Oid y algún otro objeto instancia de la

clase agregada. En ArgRest2 debe proporcionarse el(los) identificador(es) de la(s) instancia(s) con la(s)

que se tenga que relacionar Oid.

La transacción triggerMonitor comprueba si se satisface la condición de activación de algún disparo para

invocarlo en caso afirmativo.

El evento de destrucción de objetos es un servicio ofrecido por las clases que debe destruir el objeto cuyo

identificador se pase como argumento. A continuación se puede observar la reificación del evento "��

de las clases elementales:

�@��)=�5��)*�@�4"��F�>�F�O��

� Q��&'��'��

� ��7��

� Q��.��&'��"��%��"��"��"��

� �@��.��?��F��

� ��7��=�*��>��=��7��=�*��>�"��7��=�*�%��>�"��7��=�*��>�>��

� Q��'%��"�"��.��"��"��%��4"��

� �@��3�"=4"��>��?�3�F��

� Q�5��)�"��"��"��)��"��

� �@�"��?��)=5��)*��>�F��

� Q��)+��"��T��1��"��3��"��%��-��"��%��"��

� )��"P�2��)��=��*�3*�5��)�>��

� Q��%�'��&'��%��"��-��

� �@��)��??��)��=�)=5��)*��>*��"�>�F��)��=�3*��"�>��

� Q�%��%��%��"��'��-��

� ��%��0�)��'�5��=�3*��*�5��)�>��


�

�

244

� Q��"��'��"��0��0��"��.��3�

� "��3�.��=�3*��>��

Figura 35: Reificación en TFL del evento "�� de clases elementales

La transacción compBehaviourDestroy comprueba si el objeto participa en alguna agregación ya que

puede que no se pueda eliminar el objeto dependiendo de las cardinalidades definidas en la agregación o

que haya que invocar el evento DestroyEv en los objetos con los que esté relacionado.

La transacción destroyObject eliminan todos los hechos que definan al objeto cuyo oid es O.

&��9��

El servicio ��! de las especializaciones temporales no crea objetos nuevos sino que especializa

dinámicamente a las instancias de la superclase. A continuación se muestra la transacción �� que

especializa a las instancias de una superclase. Esta transacción es llamada por la transacción

specialization (ver “Cambios de estado débiles” más adelante) cuando se invoca un evento sobre un

objeto con el mismo nombre que algún evento ��! en la subclase. Como se puede ver el primer

argumento de la transacción �� que especializa a objetos es el oid del objeto que se encarga de

proporcionar specialization.

�@��)=�$%��)*�@3�S��F�>�F�O��

� Q��&'��'��

� ��7��

� Q��.��&'��"��%��"��"��%��$%��1��

� �@��.��?��F��

� ��7��=�*��>��=��7��=�*�%��>�"��7��=�*��>�>��

� Q�$%��)�"��"��"��)��!

� �@��!��??��)=$%��)*��>�F��

� Q��.��3��"��

� =�3�7��>��

� Q��2��)��"��'��=��>��'��"��)��=��>�

� �2��'��=�*��*��*�P�!�)*��*��>��

� Q��%�'��&'��%��"��-��

� �@��)��??��)��=��)=�$%��)*��>*��>�F��)��=��*��>��

� Q��"��)��'��)��"��.��3�


�

245

� �@��?��F��=�3*��*��*��>��

� �@�)��?��F��=�3*��*��>��

� Q��.��'��)��'��-��"��)��!�

� �@��)��??��)��=��)=�$%��)*��>*�$��>��)��$�=�3*�$��>��

� Q��%�'��&'��0��"'��"��"'%��"�"��

� ��&'�=��*�3�>��

� Q��%�'��&'��-��"��"�"�"��"��

� �@��?��F��)��=�3*��>��

� Q��'%��

� �@��0��?��0�F��)��=�3*��0�>��

� Q��%�'��"��%��1��.��3�

� %��1��P�!=3*��*�$%��)*��*��8�>��

� Q��%�'��"��.��"��.��

� ��%��0�)��'�P�!=3*��*��8�>��

Figura 36: Reificación en �� del servicio que especializa temporalmente a las instancias de una clase

El evento "��de las especializaciones temporales no destruye objetos sino que hace que los objetos

pierdan las propiedades y el comportamiento emergente que se definió en la especialización. A

continuación se muestra la transacción �� que hace perder la especialización a las instancias de una

especialización temporal. Como se puede observar el argumento del servicio es el identificador del objeto.

�@��)=�5��)*�@4"��F�>�F�O��

� Q��&'��'��

� ��7��

� Q��.��&'��"��%��"��"��%��$%��1��

� �@��.��?��F��

� ��7��=�*��>��=��7��=�*�%��>�"��7��=�*��>�>��

� Q��"�"��.��%��"��"��"��4"��

� �@��3�"=4"��>��?�3�F��

� Q�5��)�"��"��"��)��"��)+��"��

� �@�"��?��)=5��)*��>�F��

� Q��)+��"��T��1��"��3��"��%��-��"��%��"��

� �)��"P�2��)��=��*�3*�5��)�>��

� Q��%�'��&'��%��"��-��"��)��

� �@��)��??��)��=��)=5��)*��>*��"�>�F��)��=�3*��"�>��

� Q��"��'��"��.��3�


�

�

246

� �@��?��F��"��=�3*��>��

� �@�)��?��F��"��=�3*��>��

� Q�3�"�.��"��"��'��

� =�3�7��>�"��

� Q�%��%��%��"��'��-��

� ��%��0�)��'�5��=�3*��*�5��)�>��

� Q��Z�"��)��1��"��.��

� �"" ��=�3*��)=�5��)*�@4"��F�>�>��

� Q��1��"�%��'��"��-��"��)��-��

� ��=�3�>��

Figura 37: Reificación en �� del servicio que hace perder la especialización a las instancias de una

especialización temporal.

La transacción deleteFacts elimina los hechos que definen los atributos constantes (CAL) y variables

(VAL) del objeto O.

La transacción addTrace añade el evento servido (DestroyEv) en la cabeza de la traza del objeto O.

&��9��

El evento ��! de las especializaciones permanentes tiene una semántica diferente a la definida para las

clases elementales y las especializaciones temporales. El evento ��! de una especialización permanente

crea objetos de forma similar a lo hace el evento ��!�de las clases elementales. En los argumentos que

recibe este servicio deben estar los valores de todos los atributos (constantes y variables necesarios) para

dar valor a los atributos que forman el estado del objeto que se va a crear. Se empieza creando el objeto a

partir de la raíz de la jerarquía de herencia de la clase SubC. Finalmente, el objeto debe de ser instancia

de la subclase SubC, si esto no ocurre es porque los atributos pasados en AttList no contienen los valores

adecuados para que se satisfagan las condiciones de especialización definidas entre la clase raíz y la

subclase sobre la que se ha invocado el evento que hacen que finalmente el objeto sea instancia de SubC.

$'��@��)=�P�!�)*�@��F�>��?�3�"�F�O��

� Q�$'��&'��'��

� $'��7��

� Q��.��"��"��%��$%��1��

� $'��@��.��?��F��


�

247

� ��7��=�*%��>��=��7�=�*��>�"��7�=�*��>�>��

� Q�P�!�)�"��"��"��)��!�

� $'��@��!��??��)=P�!�)*��>�F��

� Q��'%��*��/1�"��.��&'/��"��0��"��$'��

� $'��77��=��77�$��WN�$��>��

� Q��'��.��%��"��"��'%��=��!�"��>�

� ��N��=�$4*�>��$4@��2�3�"��?�3�"F��$4@�)=��4"*��>F��

� =�3�"�7��>��

� Q��2��)��"��'��"��.��=��>��%��"��

� ��'��=�*��*��*��>��

� �@��?��F��=�3�"*��*��*��>��

� �@�)��?��F��=�3�"*��*��>��

� ��&'�=��*�3�"�>��

� �@��?��F��)��=�3�"*��>��

� �@��0��?��0�F��)��=�3�"*��0�>��

� Q��%�'��%��1��%��.��3�"�

� %�P�!��=�3�"*��*�P�!�)*��*��8�>��

� Q��.��"��"��'��$'��=��%��&'��0��'�%��"��

� � Q��"��"��%��1��-��"��"��'%��'��$'��

� 3�"�7�$'��

� Q��2��'��"��)��!�=��>�

� ��'��=��*��8*��:�>��

� Q��%�'��%��"��-��

� $'��@��)��??��)��=��)=�P�!�)*��>*��>�F��)��=��*��>��

� Q��.��'��)��'��-��"��)��!�

� $'��@��)��??��)��=��)=�P�!�)*��>*�$��>��)��$�=�3*�$��>��

� Q��%�'��&'��-��"��"�"��

� $'��@��?��$'��F��)��=�3�"*��$'��>��

� Q�%��%��%��"��'��-��

� ��%��0�)��'�P�!=�3�"*��*��:�>��

� Q��Z�"��)��1��"��.��"��1��

� =�3�"@��?�@��)=�P�!�)*��>��F�>��

� $'��@�%��??�%�=��!*�P�!�)*�$��>�F��=�3�"@��?�$��F�>��

� Q��"�%��'��"��-��

� ��=�3�"�>�


�

�

248

Figura 38: Reificación en �� del servicio que crea objeto especializados permanentemente.

La transacción getAttributes extrae de los argumentos pasados al evento (ArgList) los que formarán parte

del estado del objeto cuando se cree (AttList). Esta transacción es diferente de extractArguments porque

no extrae los argumentos del evento.

La transacción speNewPC se encarga de especializar al objeto en todas las subclases en las que haga

falta si se satisfacen las condiciones de especialización definidas partiendo de la superclase C.

La transacción getArguments extrae los argumentos del evento (Args) que se utilizan para evaluar la

precondición y la evaluación asociada.

El servicio "��de las especializaciones permanentes debe destruir el objeto cuyo identificador se pase

como argumento. A continuación se muestra la transacción �� que elimina objetos instancia de

especializaciones permanentes.

�@��)=�5��)*�@4"��F�>�F�O��

� Q��"��"��'��

� ��7��

� Q��.��"��"��%��$%��1��

� �@��.��?��F��

� �7�=�*%��>��=��7��=�*��>�"��7��=�*��>�>��

� Q��"�"��.��

� �@��3�"=4"��>��?�3�F��

� Q�5��)�"��"��"��)��"��

� �@�"��?��)=�5��)*��>�F��

� Q��)+��"��T��"��%��-��"��%��"��1��"��.��

� )��"P�2��)��=��*�3*�5��)�>��

� Q��%�'��%��"��-��"��)��

� �@��)��??��)��=��)=5��)*��>*��">�F��)��=�3*��"�>��

� Q�%��%��%��"��'��-��

� ��%��0�)��'�5��=�3*��*�5��)�>��

� Q��.��3�

� "��3�.��=�3*��>��

Figura 39: Reificación en �� del servicio que destruye instancias de especializaciones permanentes.


�

249

;��

A continuación se muestra la transacción que crea instancias de cualquier clase agregada.

�@��)=�P�!�)*��>��?�3�"�F�O��

� Q��&'��'��

� ��7��

� Q��.��&'��"��%��"��

� � �@��.��?��F��

� ��7��=�*��>��=��7��=�*��>�"��7��=�*�%��>�>��

� Q�P�!�)�"��"��"��)��!��

� �@��!��??��)=P�!�)*��>�F��

� Q��"��"��&'��"�"��.��

� ��N��=�$4*�>��$4@��2�3�"��?�3�"F��$4@�)=��4"*��>F��

� Q��3�"��"��

� =�3�"�7��>��

� Q��2��'��"��)��=��>��)��"��'��=��>�

� �2��'��=�*��*��*�P�!�)*��*��>��

� Q��%�'��%��"��-��"��)��

� �@��)��??��)��=��)=�P�!�)*��>*��>�F��)��=��*��>��

� Q��"��)��'��)��"��.��

� �@��?��F��=�3�"*��*��*��>��

� �@�)��?��F��=�3�"*��*��>��

� Q��.��'��-��"��)��

� �@��)��??��)��=��)=�P�!�)*��>*�$��>��)��$�=�3�"*�$��>��

� Q��%�'��&'��0��"'��"��'��"'%��"�"��

� ��&'�=��*�3�"�>��

� Q��%�'��&'��-��"��"�"�"��"��

� �@��?��F��)��=�3�"*��>��

� Q��%��&'��0��&'��%��1��.��0��"��"��'��

� %��1��P�!=�3�"*��*�P�!�)*��*��8�>��

� Q��%��.��%'��

� ��0�)��'�P�!=�3�"*��*��P�!�)*��8�>��

� Q��Z�"��)��1��"��.��1��

� =�3�"@��?�@��)=�P�!�)*��>��F�>��

� �@�%��??�%�=��!*�P�!�)*�$��>�F��=�3�"@��?�$��F�>��


�

�

250

� Q��"�%��

� ��=�3�"�>�

Figura 40: Reificación en �� del evento ��! de las clases elementales

La transacción aggreBehaviourNew dependiendo de las propiedades definidas en la agregación,

establece el vínculo entre el objeto compuesto y su(s) componente(s)87 o crea a los componentes.

El evento de destrucción de objetos compuestos, es un servicio ofrecido por las clases que debe destruir el

objeto que se pase como argumento. A continuación se puede observar la reificación del evento "��

de las agregaciones:

�@��)=�5��)*�@�4"��F�>�F�O��

� Q��&'��'��

� ��7��

� Q��.��&'��"��%��"��

� �@��.��?��F��

� ��7��=�*��>��=��7��=�*��>�"��7��=�*�%��>�>��

� Q��"�"��.��

� �@��3�"=4"��>��?�3�F��

� Q�5��)�"��"��"��)��"��

� �@�"��?��)=5��)*��>�F��)��"P�2��)��=��*�3*�5��)�>��

� Q��%�'��%��"��-��

� �@��)��??��)��=�)=�)5��*��>*��"�>�F��)��=�3*��"�>��

� Q��%��.��"��

� ��0�)��'�5��=�3*��*�5��)>��

� Q��"��'��.��

� "��3�.��=�3*��>��

Figura 41: Reificación en �� del evento "�� de clases elementales

87 Recordamos que, aunque en las agregaciones relacionales no tiene sentido hablan de clases compuestas y clases

componentes, se mantiene la notación llamando compuesta a aquella clase en el que se define la relación de

agregación y componente a la clase que está al otro lado de la relación.


�

251

La transacción aggreBehaviourDestroy describe el comportamiento como objeto agregado de manera

que si el objeto participa en agregaciones con unas determinadas propiedades puede que haya que invocar

el evento "�� de los componentes.

7��

El modelo de ejecución para los eventos presentado en la página 17, ampliado con detalles relacionados

con la animación, se reifica en la transacción �� que se muestra a continuación.

3@��)=�P��*��>�F�←��

� Q��)��"��)��P��%��%��"��.��3�

� "��)��=�3*�P��*��>��

� Q��Z�"��)��1��"��1��

� �"" ��=�3*��)=�P��*��>�>��

� Q��"�%��'��"��-��"��)��-��0��)�"��

� ��=�3�>��

"��)��=�3*�P��*��>�←�

� Q�3��"��"��"��

� ��=��*�3�7��=�3�7�$��$��77��$��WN��>*��>��

� Q��)��"��)+��"��T��"��%��-��"��%��1��"��.��

� )��"P�2��)��=��*�3*�P��>��

� Q��)��P��"��"��"��0��"�"��"��'%��

� ��=��*��>��

� =��@��)��0��??��)=�P��*��>�F�"��@��)��??��)=�P��*��>�F�>��

� Q��2��'��"��)��

� ��'��=��*��*��>��

� Q��%�'��&'��'��"��%��)+��"��

� ��%��=�3*��*�P��*��>��

� Q��%�'��%��"��-��"��)��

� ��)��"��=��*�P��*��*��"�>��)��=�3*��"�>��

� Q��.��'��)��'��-��"��)��

� ��)��'��=��*�P��*��*�$��>��)��$�=�3*�$��>��

� Q��%�'��&'��-��"��"�"�"��"��

� ��)��=��*��>��)��=�3*��>��

� Q��%�'��"��%��1��.��'��'��


�

�

252

� %��1��=3*��*�P��*��>��

� Q�%��%��%��%'��"��'��-��

� ��0�)��'�=�3*��*�P��*��>��

Figura 42: Reificación en �� del modelo de ejecución de eventos de OASIS

La transacción retrievePrecondition recupera la precondición a comprobar para poder servir un evento:

1. si el objeto es instancia de una especialización temporal y se ha redefinido el evento, la

precondición será la definida en la subclase,

2. si el objeto es instancia de una especialización temporal y no se ha redefinido el evento, la

precondición será la definida en la superclase,

3. si el objeto es instancia de una especialización permanente y se ha ampliado el efecto del

evento, la precondición estará formada por la conjunción de las precondiciones de la

subclase y la superclase (de esta manera se asegura la compatibilidad de comportamiento),

4. si el objeto es instancia de una especialización permanente y no se ha ampliado el efecto del

evento, la precondición será la definida en la superclase,

5. si el objeto es instancia de una clase elemental, la precondición será la definida en la clase.

La transacción retrieveValuation recupera la evaluación a ejecutar:

1. si el objeto es instancia de una especialización temporal y se ha redefinido el evento, la

evaluación será la definida en la subclase,

2. si el objeto es instancia de una especialización temporal y no se ha redefinido el evento, la

evaluación será la definida en la superclase,

3. si el objeto es instancia de una especialización permanente y se ha ampliado el efecto del

evento, la evaluación estará formada por la conjunción serial de las evaluaciones de la

subclase y la superclase (de esta manera se asegura la compatibilidad de comportamiento),

4. si el objeto es instancia de una especialización permanente y no se ha ampliado el efecto del

evento, la evaluación será la definida en la superclase,

5. si el objeto es instancia de una clase elemental, la evaluación será la definida en la clase.


�

253

La transacción specialization comprueba si las clases de LC son superclase de alguna especialización

temporal y el evento Name se ha definido como ��! en la especialización de forma que hay que

especializar al objeto. Los valores de las propiedades emergentes se deben de proporcionar en ArgRest.

La transacción aggregationBehaviour comprueba:

• si las clases de LC son agregaciones y es necesario compartir el evento Name con los

componentes con los que pueda estar relacionado el objeto O, o

• si las clases de LC son componentes de una agregación relacional y hay que compartir el evento

con los objetos con los que esté relacionado el objeto O.

La �� proporciona un comportamiento declarativo para las actualizaciones, de manera que, si en algún

momento falla alguno de los subobjetivos descritos en la regla, se deshacen todos los cambios realizados

vía �� hasta encontrar una nueva unificación que haga que algún subobjetivo tenga éxito.

Los eventos compartidos entre varias clases sin que exista definida una agregación entre las mismas

necesitan que se identifiquen a todos los objetos en los que se deba invocar el servicio compartido. La

siguiente transacción �� simula el comportamiento de los eventos compartidos. Como �� no permite la

ejecución de transacciones de forma concurrente, la implementación serializa el comportamiento de los

eventos compartidos.

3��@�0=�P��*��>�F�←�

� 3��N�@�3�*��F��

� 3�7��

� �@�0��"��??�0=��)=P��*��>*��F��

� 0��"�)��=�3��*��*��)=P��*��>�>��

0��"�)��=��*��*��>��

0��"�)��=�@�3*��3�F*�@��*��F*��)��>�←�

� 3�7��@��?��F��

� 3@��)=�P��*��>�F��

� 0��"�)��=��3*��*��)��>��

Las transacciones OASIS definidas en las clases se ejecutan gracias a la siguiente transacción ��:

3@��=�P��*��>�F�←�

� 3�7��


�

�

254

� �@��??��=P��*��>�F��

� ��%��=��*�P��*��>��

� �@��??��=��=P��*��>*��"�>�F��)�� $�=�3*��"�>��

Cualquier servicio que se pida a un objeto se satisfará a través de la siguiente transacción ��:

3@�=�$��)��P��*��>�F�←�

� 3@��)=�$��)��P��*��>�F�"�� Q�%'�"��'��)��

� 3@��=�$��)��P��*��>�F�� Q�%'�"��'��-��

Cuando la agregación definida entre una clase compuesta y una componente es dinámica, las instancias de

la clase compuesta disponen de los servicios de inserción y borrado de componentes. Las siguientes

transacciones �� ilustran la reificación de los eventos de inserción y borrado que, como se puede ver,

son dependientes de las propiedades definidas en la agregación.

3@��)=��%*�@��P��*�4"��F�>�F�←�

� 3�7��7��@��.��?��F��7��=�*��>��

� Q�5��+��

� �@��%��??��%=��%��*��P��*��*��'�*��*�5�*��*��>F��

� ��%��@��3�"=4"��>��?�3��F��

� Q��)��'�"��%'��"��"��

� �=��=�3@��%��??��%=��P��*��>�F�>�

� "�

� ��=��>�>�� Q��'��)��'�"��

� Q�5�.'��%��"��T��%'��

� �=�5��=3�@�%��3��??��=��P��*��>�F�>�

� "�

� ��=5�>�>�� Q��"�.'��

� �=3@��%��??��%=��P��*�3�>�F�>��

� �=3�@�%��3��??��=��P��*�3�>�F�>��

3@��)=��)��%�@��P��*�4"��F�>�F�←�

� 3�7��7��@��.��?��F��7��=�*��>��

� Q�5��+��

� �@��%��??��%=��%��*��P��*��*��'�*��*�5�*��*�P'��>F��

� ��%��@��3�"=4"��>��?�3��F��


�

255

� Q�$-��-��2��=��0��/��&'��"��'��%��>��

� ��

� Q�$��P'��%��&'��0��+��%��

� �=��=P'��>��3@��%��?��%=��P��*�3�8>�F��3�8�WN3��

� "�

� P'��>�� Q�%��'��

� =3@��%��??��%=��P��*�3�>�F�>�"��

� �� =3�@�%��3��??��=��P��*�3�>�F�>�"��

Para los eventos que se puedan definir en los esquemas conceptuales existe una transacción que

implementa el comportamiento de los mismos cuando se invocan sobre una instancia de un esquema. La

transacción es similar a la presentada para la resolución de los eventos en las instancias de las clases en la

Figura 42 eliminando la parte que se encarga de la herencia, la composición de objetos y los disparos.

˘ ˇ - dsic.upv.es · v ˛ ˘ ˘ En todo proyecto de cierta envergadura es imprescindible la ayuda...

Documents

Transcript of ˘ ˇ - dsic.upv.es · v ˛ ˘ ˘ En todo proyecto de cierta envergadura es imprescindible la ayuda...