• No results found

Chapter 6 Conclusions

6.5 Implications for personal professional practice

Para definir el modelo independiente de la plataforma (PIM) se partió de tres de los sistemas de conceptos del Metamodelo de Bases de Acontecimientos que hemos presentado en el capítulo anterior: (1) Del sistema de conceptos básicos (Figura 9.1), (2) del sistema de conceptos para representar cambios de estado (Figura 9.3), y (3) del sistema de conceptos para representar información dependiente del contexto (Figura 9.4). Sobre ellos se realizó lo siguiente:

1 Se fijaron las multiplicidades de los roles de cada relación entre las clases.

Recordemos que el metamodelo proporciona una serie de conceptos que pueden ser utilizados para la especificación de modelos de bases de acontecimientos; la estructura de

IV El Lenguaje de Acceso a Información de Acontecimientos Conclusiones y trabajo futuro

estos modelos se basa en la estrategia de diseño seleccionada en cada caso. Sin embargo, para la definición del modelo independiente de la plataforma del Diccionario, la estructura del metamodelo se mantiene y, por tanto, es necesario fijar las multiplicidades de las relaciones entre cada una de las clases al existir una libertad en el metamodelo que, para este caso, es necesario restringir.

2 Se materializaron las relaciones entre las clases.

La materialización es necesaria para asegurar que la independencia perceptiva de las clases asociadas se conserve en los niveles inferiores de abstracción.

3 Aplicando los conceptos del metamodelo para representar información dependiente del contexto tal y como se ha descrito en el apartado 9.4 se especificaron los atributos de cada una de las clases del diccionario.

Concretamente se incluyeron dos atributos: (1) Un atributo para posibilitar el registro de un identificador de cada elemento y asociación de la base de acontecimientos descrita en el diccionario, y (2) un atributo name para registrar el nombre de dichos elementos.

4 Se fijaron una serie de reglas para asegurar la consistencia del modelo resultante. Reglas

Para la especificación del modelo independiente de la plataforma se fijaron las siguientes reglas:

1 Todas las clases que refieren a conceptos del metamodelo, así como ciertas asociaciones que interesaba identificar, se especificaron incluyendo dos atributos: un identificador de objeto (OID; Object Identifier) declarado como OID_<nombre_elemento> u

OID_<asociacion>, y un nombre (name).

El identificador de objeto se utiliza para identificar internamente a los elementos genéricos representados por los conceptos recogidos del metamodelo, así como a las asociaciones. El nombre (name) se utiliza para identificar en el UoD (Universo del Discurso) al elemento genérico o asociación.

El objetivo sería, por ejemplo, poder registrar en la entidad ObjectType del diccionario un tipo de objeto con nombre “Sample” identificado de forma unívoca en el mismo como

“0001”.

2 Excepcionalmente, aquellos elementos que son utilizados como señales para la localización no incluyen el atributo name. Es por ejemplo el caso de las clases que identifican los tipos de estado de objetos que pueden ser iniciales o finales: InitialStateObjectType y

FinalStateObjectType.

3 El valor del OID de un elemento genérico tiene que identificarlo entre todos los elementos genéricos registrados en una implementación del diccionario; para reflejar esto, los atributos OID_<nombre_elemento> se han estereotipado como <<Unique>>. Esto es aplicable también a los correspondientes atributos de las asociaciones.

4 El valor del atributo name debe ser único entre los nombres de los elementos de un determinado tipo y entre todos los demás elementos registrados en una implementación del diccionario; para reflejar esto, los atributos name se han estereotipado como <<Unique>>. Esto es aplicable también a los correspondientes atributos de las asociaciones.

Por ejemplo, si en una implementación del diccionario hubiera registrada una instancia de

tipo de objeto (ObjectType) con nombre “Sample”, este nombre no podría tenerlo la

instancia de un tipo de estado de objeto (StateObjectType); o si “Stored” es un nombre de

la instancia de un tipo de estado de objeto, entonces no puede existir una instancia de tipo de proceso ejecutado (ExecutedProcessType) que se llame así: o si “SampleStorage” es el

nombre de una instancia de tipo de proceso ejecutado, no puede existir una instancia de tipo de proceso (ProcessType) que se llame así.

El modelo resultante

Tras realizar este proceso, el modelo independiente de la plataforma (PIM) que se obtuvo fue el representado en el siguiente diagrama de clases (lo mostramos dividido en partes para facilitar su legibilidad):

IV El Lenguaje de Acceso a Información de Acontecimientos Conclusiones y trabajo futuro

Figura 10.1 El modelo independiente de la plataforma (PIM) del Diccionario

IV El Lenguaje de Acceso a Información de Acontecimientos

Objetos de información

Cuando hablemos de Información de Acontecimientos utilizaremos en ocasiones el concepto

Objeto de Información; dado que el término Objeto se utiliza con asiduidad es importante diferenciar este concepto de otros conceptos que hacen referencia a objetos.

Para referir a los objetos que forman parte de los acontecimientos recurrimos al concepto

Objeto de Acontecimiento; dicho de otro modo, el concepto Objeto de Acontecimiento se utiliza para referir a aquellos objetos afectados por acontecimientos; este concepto de objeto es al que hemos referido en numerosas ocasiones a lo largo de este texto.

Para referir a otros tipos de objeto, que pueden contemplarse en un modelo de base de acontecimientos (y por tanto en el Diccionario), y dan información sobre un Objeto de Acontecimiento o sobre los otros elementos de un acontecimiento como proceso ejecutado y estado, recurrimos al concepto Objeto de Información.