�
����������������� �������������������� �
������������
�
����������� ��������
�������������� ������������� ���������� ��
�� ���� ����� ���� ���������� ��
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
�'�������<�)+�'�������������"������!�������������������������������������������������--(
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 �)���).
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 ���%����.
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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 �������).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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:
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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 ), ... }
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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:
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
extent → { RDVLV0HWDFODVV }
FRQFHSWXDOBVFKHPD�2DVLV0HWDFODVV
��������������������������������������������
HQGBFRQFHSWXDOBVFKHPD
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, ...).
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
29
FRQFHSWXDOBVFKHPD�2DVLV0HWDFODVV
���FODVV�elemental_class������
���HQGBFODVV
�HYHQWV�newInstance;�������������������������
HQGBFRQFHSWXDOBVFKHPD
extent → { RDVLV0HWDFODVV }
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
30
LVBLQVWDQFHBRI
QHZ,QVWDQFH
FRQFHSWXDOBVFKHPD�´´
HQGBFRQFHSWXDOBVFKHPD
extent → {}
name -> “” ;class_list -> { }
FV�
FRQFHSWXDOBVFKHPD�2DVLV0HWDFODVV
���FODVV�elemental_class������
���HQGBFODVV
�HYHQWV�newInstance;�������������������������
HQGBFRQFHSWXDOBVFKHPD
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”
“temporalSpecialization_class”
“aggregation_class”“permanentSpecialization_class”
“primitive_class”
“member” “book”
“lend”
“markedMember”: is_a: is_instance_of
(O�PRGHOR�GH�REMHWRV�GH�2$6,6�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�������.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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 ���(�'��.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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)
3. expresión ������� ���� ����
scalMI(r0, ..., rk) ��� s (k≥0)
4. expresión ������ ������������ ���� ����
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.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 =>>.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 ������.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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>.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 |= α.
7UDQVDFWLRQ�)UDPH�/RJLF�
�
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.
)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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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%�����’.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�����'����
)RUPDOL]DFLyQ�GH�2$6,6�HQ�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�%����
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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 ��.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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���)�����
)RUPDOL]DFLyQ�GH�2$6,6�HQ�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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�������
)RUPDOL]DFLyQ�GH�2$6,6�HQ�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).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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).
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
73
����������
newInstance
destroyInstance“elemental_class”
“permanentSpecialization_class”
“temporalSpecialization_class”
“aggregation_class”
“primitive_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 ������������*�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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��
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�>*�
� ��=����%$'�����*������>*� �
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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)
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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 ��)
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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).
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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).
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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
temporalSpecialization_class.
�=��*���>@�'%������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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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��=��*���>�
&'(')'('+'� ���������
A continuación se muestran los valores de los atributos más importantes del metaobjeto
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
temporalSpecialization_class.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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:
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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��
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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��=��*���>�
&'(')'&'+'� ���������
A continuación se muestran los valores de los atributos más importantes del metaobjeto
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
136
Como en el servicio anterior, el proceso puede definirse haciendo uso de los eventos heredados.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
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 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á
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
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. 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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
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. 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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�$'%�� �%��>����
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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:
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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�>��
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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,
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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).
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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��
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
)RUPDOL]DFLyQ�GH�2$6,6�HQ�7)/�
�
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.
(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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(O�VLVWHPD�$)7(5�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 (�������).
(O�VLVWHPD�$)7(5�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(O�VLVWHPD�$)7(5�
�
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(O�VLVWHPD�$)7(5�
�
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 ����������).
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 �����������
(O�VLVWHPD�$)7(5�
�
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 ���
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 ���
(O�VLVWHPD�$)7(5�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
&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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
%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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
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,
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
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
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
6HUYLFLRV�DX[LOLDUHV�GH�HYROXFLyQ�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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
6HUYLFLRV�DX[LOLDUHV�GH�HYROXFLyQ�
�
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�>�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�>�
6HUYLFLRV�DX[LOLDUHV�GH�HYROXFLyQ�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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���� ��������'�� ��������������� ���������'�������(��� ��������������������
6HUYLFLRV�DX[LOLDUHV�GH�HYROXFLyQ�
�
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�>*� �
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
6HUYLFLRV�DX[LOLDUHV�GH�HYROXFLyQ�
�
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���������� �'� �������������������������� ����������������
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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” ) ).
(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�
�
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” ] ) )
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�
�
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:
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�
�
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�
�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�
�
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.
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
(MHPSORV�GH�XVR�GH�OD�0HWDFODVH�2$6,6�
�
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.
$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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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 ��.
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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��=�*���>�>���
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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������)�>���
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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�
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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���
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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�"�>�
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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�>������
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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��������.���������'���'������
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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.
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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�����
2$6,6�FRPR�PDUFR�FRQFHSWXDO�SDUD�OD�HYROXFLyQ�GHO�VRIWZDUH�
�
�
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���
$QLPDFLyQ�GH�HVSHFLILFDFLRQHV�2$6,6�HQ�7)/�
�
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.
Top Related