UNIVERSIDAD DE LOS ANDES FACULTAD DE INGENIERÍA POSTGRADO EN COMPUTACIÓN

---

Tema 2. Modelos de objetos

Prof. Isabel Besembel Carrera

Núcleo La Hechicera. Edif. Economía. 3er. piso. Ala 3S. Mérida. Venezuela.

Sesión 2. Modelos lógicos. Tabla de contenido:

Programa del curso

Introducción OMG

Contexto: Objetos de servicio, facilidades comunes y objetos de aplicación.

Conceptos básicos:
Identidad del objeto e identificadores de los mismos
Tipos de objetos
Operaciones
Subtipos y herencia
Pase de argumentos y resultados
Interfaz de un tipo de objetos
Implementación

El modelo de objetos CORBA:

Arquitectura de OMG

Una aplicación es un conjunto de clases e instancias que interactúan a través del agente o corredor de requerimientos de objetos, que es un bus de software que permite que los objetos hagan y reciban peticiones y respuestas.

Cada aplicación o servicio se modela como un objeto:
OS: Es la colección de objetos de servicio que proveen las funciones básicas para crear y mantener objetos de cualquier categoría.
FC: Es la colección de clases y objetos que proveen capacidades de propósito general que son útiles en cualquier aplicación.
OA: Son los objetos específicos de cualquier aplicación de usuario final.

Conceptos básicos de OMG

• Un objeto modela cualquier entidad identificada univocamente, que persiste a lo largo del periodo de vida del objeto y que es independiente de las propiedades y comportamiento del objeto.
• Las operaciones se aplican a los objetos. Las operaciones asociadas con un objeto caracterizan su comportamiento.
• Los objetos se crean como instancias de los tipos.
• Un tipo caracteriza el comportamiento de sus instancias por medio del conjunto de operaciones asociadas con el tipo.
• Las interrelaciones entre los tipos son supertipo y subtipo.
• El estado de un objeto es el conjunto de valores e interrelaciones de dicho objeto.
• Cada objeto tiene una identidad única distinta e independiente de cualquier otra característica. La identidad es constante (inmutable).
• Cada objeto tiene un identificador que denota o refiere a dicho objeto (OId).
• El conjunto de los OIds se denota como Obj.
• Los objetos no cambian de tipo.
• Cada operación tiene una firma que consiste de un nombre, un conjunto de parámetros y un conjunto de resultados.
• El conjunto de todas las firmas de un tipo es la interfaz del tipo y ella incluye las que son heredadas de sus supertipos.
• Cada instancia de un tipo satisface la interfaz de dicho tipo.
• El conjunto de todas las instancias de un tipo es la extensión del tipo.
• Los tipos se organizan en jerarquía formando un digrafo acíclico.
• La raíz de la jerarquía es el tipo Objeto.
• Los nuevos tipos creados por las aplicaciones son subtipos del tipo Objeto.
• El conjunto de todos los tipos de objetos se denomina OTipos.

Ejm: La firma del tipo Persona se define con:

	Cadena		nombre(Persona)
	Cadena		dirección(Persona)
			nombre(Persona, Cadena)

Si Empleado es un subtipo de Persona, hereda las operaciones anteriores y ademas puede contener

	Real		salario(Empleado)

• Valores que no son objetos se denominan no-objetos. El conjunto de los objetos y los no-objetos conforman todos los valores denotables, DVal.
• El conjunto de los no-objetos se denomina NObj.
• El conjunto de los tipos de los no-objetos se denomina NTipos.

• Cada no-objeto debe pertenecer a un tipo NTipo. Estos no forman parte de la jerarquía de objetos.
• No se especifican operaciones para los objetos y los no-objetos, ya que sus tipos son diferentes.
• Una operación describe una acción que se puede aplicar a los parámetros.
• La invocación de una operación es un evento que puede producir:
• Un conjunto de resultados inmediatos (Observador)
• Efectos colaterales expresados en un cambio de estado (Transformador)
• Excepciones (Errores y advertencias)

	          nombre 	         parámetros      		resultados

Cada tipo T que pertenece a OTipos tiene un conjunto de operaciones Ops(T) = {Omega₁^T, Omega₂^T,..}

Especialización y generalización son relaciones entre los tipos que están basadas en sus interfaces. Ellas definen las reglas por las cuales unos objetos de un tipo son aceptados en el contexto de otro tipo.

Herencia es un mecanismo para reusar estructura y comportamiento, lo cual permite que un tipo sea definido en términos de otro.

• Un objeto es una instancia directa de un tipo si ella es una instancia de ese tipo y no de los subtipos del tipo.
• Si S es un subtipo de T (T es un supertipo de S), entonces para cada operación Omega_kT que pertenece a Ops(T) existe una operación correspondiente Omega_jS que pertenece a Ops(S) tal que
• Tienen el mismo nombre
• El número y tipo de los parámetros es el mismo
• El número y tipo de los resultados es el mismo
• Los tipos abstractos no tienen instancias y sirven para definir estructura y comportamiento común para los subtipos.
• Cuando una operación es pedida, se selecciona una implementación de la misma para ser ejecutada. Este proceso se denomina despachar.
• La operación Omega: omega:(X₁: sigma₁, X₂: sigma₂, ..., X_n: sigma_n)=> (Y₁: ro₁, Y₂: ro₂,..., Y_m: ro_m)
  cuando es invocada r₁ ,..., r_m <= omega(E₁, E₂, ..., E_n)
  donde omega es el nombre de Omega, E_i son los argumentos de entrada y r_i los resultados. Una petición es válida si los E_i se pueden evaluar en alfa_i o en sus tipos inmediatos alfa_i menor o igual que sigma_i.
• La firma garantiza que la petición regrese un conjunto de resultados beta_i del tipo o de su tipo inmediato beta_i menor o igual que ro_i.
• La semántica del pase de argumentos es por valor.
• Una clase define una especificación y una implementación del tipo.
• Un objeto es una instancia de una clase.
• Los tipos pueden tener varias implementaciones, por lo cual sus instancias pueden pertenecer a varias clases.

CORBA (Common Object Request Broker Architecture)-OMG

Arquitectura:

El servicio básico es el manejo de peticiones y respuestas de una pieza de código a otra. Estos dos objetos se denominan cliente y servidor. Cualquier objeto puede ser cliente, servidor o ambos.

Implementación:

• El lenguaje IDL(Interface Definition Language) de OMG es un lenguaje de especificación que se utiliza para especificar la interfaz independientemente de la programación, por lo tanto es OO y sirve para expresar el modelo de objetos.
• Un banco de interfaces (IR) con todas las clases de objetos disponibles.
• Una extensión completamente dinámica que permite encontrar a tiempo de ejecución los objetos disponibles, así como su interfaz y la forma de la construcción de las peticiones y la recepción de las respuestas.
• Una extensión del contexto para el paso de nombres opcionales como parámetros.
• Un mecanismo de abstracción (object adapter) para eliminar los detalles de la implementación de los objetos en el servicio de mensajes.

Modelo del IDL:

Es usado para generar el código de llamadas de procedimientos a través de una interfaz de red, llamados stubs y skeletons. Las especificaciones IDL están disponibles tembién en el sistema de tiempo de ejecución para soportar la generación dinámica de peticiones.

Interfaces CORBA-OMG

• La especificación de los objetos se dividen en interfaz e implementación.
• La sintaxis y semántica de las peticiones que usan CRO se hace a través de un fragmento (stub) o de la interfaz de invocación dinámica que es interpretada por el CRO, un esqueleto (skeleton) y una implementación.
• El adaptador de objetos adapta la definición local de los objetos. Dicha adaptación depende de los lenguajes de aplicación.
• Los clientes mirarán los objetos y sus interfaces CRO a través de la perspectiva del lenguaje que les brinda la especificación válida a nivel de programador.

Interfaces de los tipos y de los objetos:

Los tipos se refieren a aquello que puede ser especificado en los argumentos o resultados de la firma de las operaciones.
Un nombre de interfaz es un tipo legal en IDL.

Tipos de datos OMG

• Tipos básicos: Entero (int, long, short, signed, unsigned), real (float, double), caracter (Char), lógico (Boolean) y octeto o byte(Octet).
• Tipos construidos: Estructura (Struct), unión (Union) y enumerado (Enum).
• Tipos parametrizables: Secuencia (Sequence) y cadena (String).
• Arreglos (Array).

• Peticiones de COR como objetos de primera clase, según el caso.
• Listas de Nombre-Valor para manejo de memoria.
• Contextos para manejar listas de control especiales.

Interfaces en el banco de interfaces para manejar la representación dinámica de IDL a tiempo de ejecución.

Implementaciones en el banco de las mismas para manejar la asignación de interfaz-implementación a tiempo de ejecución.

Otros objetos proporcionados por CORBA:

Object define aquellas operaciones aplicables a todos los objetos del sistema como: get_implementation, create_request, get_interface, duplicate, release, is_nil.
Una interfaz para crear referencias de objetos persistentes, como: object_to_string, string_to_object.

Operaciones y peticiones OMG

El cliente inicia la petición mediante la llamada de un fragmento o mediante la construcción de la misma via la interfaz de invocación dinámica.

Semántica de la invocación:

Cuando una operación que no devuelve ninguna respuesta es invocada, ella será invocada a lo sumo una vez, lo cual no garantiza que se realice. Para el resto de las operaciones, ellas serán invocadas a lo sumo una vez si se obtiene una excepción y exactamente una vez si su resultado es exitoso.

• Los parámetros se declaran como E (entrada), S (salida) o E/S. Ellos regresarán valores adicionales a los resultados declarados en la interfaz. La firma de la operación puede especificar las excepciones de la misma.
• Se incluye un contexto del objeto para controlar los métodos y su ejecución en un ambiente particular. Este contiene una lista de propiedades, las cuales consisten de un nombre y un valor tipo cadena asociado. La implementación puede usar este par para reconocer si equivalen a su contexto.
• IDL soporta la especificación de los atributos. La definición de dichos atributos es logicamente equivalente a la declaración de un par de observador/mutador, denominados _get_x y _set_x. Ellos pueden ser declarados como de solo lectura (E).
• IDL soporta la especificación de excepciones que se declaran de tipo Struct
  Las excepciones comprenden un identificador IDL, el tipo y el valor.
  El identificador de la excepción está disponible al usuario.
• IDL soporta también, una rica sintaxis para el esquema de alcance de los nombres que permite la resolución de ambigüedades en la herencia múltiple.
• COR enruta una petición a una implementación de objeto, Él es responsable de encontrar la implementación adecuada para la petición, de preparar la implementación para recibir la petición y de comunicar los datos ya preparados a la misma.
• Los criterios para seleccionar una implementación, correspondencias entre interfaz e implementación y establecimiento de esta últimas no están definidos. Se pueden tener varias implementaciones, en servidores separados, librerías, un programa por método, una aplicación encapsulada, una base de datos OO, etc.

Introducción ODMG-93

El modelo ODMG fue concebido en 1991 como una iniciativa conjunta entre las empresas productoras de software en Sistemas Manejadores de Bases de Datos Orientados por Objetos (SMBDOO) y Rick Cattell, debido a la falta apreciable de un estándar en el área. A partir de esa fecha se conformó el grupo de trabajo llegando en 1995 a la versión 1.1 del modelo estandar, cuyo resumen se presenta a continuación.

El modelo de los objetos se expresa brevemente como:

• La primitiva es el objeto.
• Los objetos se pueden categorizar en tipos.
• Su estado lo describen los valores de sus propiedades, que pueden ser de sus atributos o de relaciones entre él y otros objetos.
• Su comportamiento lo define el conjunto de sus operaciones.

Tipos e instancias:

• El Tipo define estado y comportamiento de sus instancias.
• El conjunto de todas las instancias del tipo es la extensión del mismo.
• Estado y comportamiento se denominan las características del tipo.
• Los tipos se organizan en un grafo de subtipos y supertipos.
• Un subtipo hereda todas las características de sus supertipos, pudiendo definir nuevas características para él.
• Hay tipos abstractos que no tienen instancias ni implementación.
• Los tipos del sistema se organizan como un árbol, pero los definidos por el usuario pueden formar un digrafo acíclico (dag).

Jerarquía básica de tipos ODMG-93

• Denotable_Object
  • Object (Acepta subtipos y es mutable con identidad)
    • Atomic_Object
    • Structured_Object
  • Literal (Inmutable sin identidad)
    • Atomic_Literal
    • Structured_Literal

• Characteristic (No acepta subtipos)
  • Operation
  • Property (No acepta subtipos)
    • Attribute (No acepta subtipos)
    • Relationship (No acepta subtipos)
  
  
• Un objeto que es instancia del tipo A, es miembro de la extensión de A.
• Si A es un subtipo de B, entonces la extensión de A es un subconjunto de la extensión de B.
• Un tipo tiene una o más implementaciones.
• Una implementación de un tipo consiste de una representación y un conjunto de métodos.
• La representación es el conjunto de estructuras de datos y los métodos el cuerpo de los procedimientos.
• Hay un método por cada operación definida en la especificación.
• Pueden haber métodos y estructuras de datos en la implementación que no tengan su contraparte en la interfaz.
• Las implementaciones tienen nombre el cual debe ser único en el alcance del tipo.
• Una clase es una implementación del tipo.
• Cuando se crea un objeto se especifica su implementación la cual puede cambiarse dinámicamente después.
• Los objetos tienen estado, comportamiento e identidad.
• Los objetos mutables pueden cambiar los valores de sus atributos y sus relaciones con otros objetos, pero su identidad es invariante a lo largo de su vida.
• El identificador del objeto tiene como dominio la base de datos donde el existe.
• Un objeto tiene un único identificador pero puede tener varios nombres.
• Un nombre refiere a un objeto único en un determinado alcance.
• Si un objeto tiene varios nombres dentro de un alcance es posible determinar a tiempo de ejecución todos esos nombres.
• Un objeto se puede identificar por predicados sobre sus características.
• En el tipo se pueden declarar que valores de las propiedades son suficientes para identificar univocamente los objetos en la extensión del tipo.
• Solo hay herencia de tipos.
• Los subtipos de Denotable_Object heredan la operación equal?
  

El tipo Object tiene las siguientes propiedades ya definidas:

• has_name? : Boolean
• names : Set String
• type : Type

• delete ()
• same_as? (oid: Object_id) -> b : Boolean

• coterminus_with_procedure;
• coterminus_with_process;
• coterminus_with_database;

Este se define cuando el objeto se crea y no puede ser cambiado después. Objetos con tiempos de vida mayores pueden referirse a los que tienen tiempos de vida menores solamente en el periodo donde los menores existen.

Los objetos inmutables o literales tienen identidad pero no tienen oid. Su identificador es el valor del literal.
Las literales atómicos son:

• Integer
• Float
• Boolean
• Character

• Inmutable_Collection (Bit_String, Character_String, Enumeration)
• Inmutable_Structure (Date, Time, Timestamp, Interval)

Propiedades ODMG-93: Atributos y relaciones

Los atributos se definen para cada tipo de objeto tomando literales como valores y sin tener oid. Su individualidad se determina por el objeto individual al cual se aplica. Ejm: attribute Integer edad;

Sus operaciones ya definidas son:

• set_value (new_value : Literal)
• get_value () -> existing_value : Literal

Se provee el valor nulo para cada literal.

Los atributos definen el estado sin importar si es implantado con un campo de una estructura de datos o una operación. Ejm: edad puede ser calculada en base a la fecha de nacimiento y la fecha actual.

Los atributos no son de primera clase y no pueden tener a su vez atributos ni relaciones.

Se pueden reescribir las operaciones ya definidas por el sistema.

Se pueden definir valores por defecto para los atributos, haciendo que el constructor le asigne dicho valor al momento de creación. Ejm: attribute Integer edad default 12;

Las relaciones solo pueden definirse entre tipos mutables. Las relaciones son binarias del tipo 1:1, 1:M y N:M. Ellas no tienen nombre pero si sus caminos en cada dirección. Los caminos se declaran dentro de la interfaz del tipo con relationship clase nombreDelRol inverse clase::nombreDelRol, donde la relación se da.
Ejm: Relación 1:M

interface Curso
{ ...
relationship List Sección tiene_secciones
inverse Sección::es_sección_de
{order_by Sección::número};
....
};
interface Sección
{ ...
relationship Curso es_sección_de inverse Curso::tiene_secciones;
....
};

Las relaciones mantienen la integridad referencial. Ellas no tienen oid y se identifican por los objetos que ellas asocian. Las relaciones 1:M y N:M pueden ordenarse. Hay una sola instancia en las N:M que implica la existencia de dos conjuntos de 1:M y cada una de ellas implica la existencia de un conjunto de relaciones 1:1.

Operaciones para relaciones N:M:

• delete()
• add_one_to_one (o1: Denotable_Object, o2: Denotable_Object)
• remove_one_to_one (o1: Denotable_Object, o2: Denotable_Object)
• add_one_to_many (o1: Denotable_Object, s:Set Denotable_Object )
• remove_one_to_many (o1: Denotable_Object, s: Set Denotable_Object )
• remove_all_from (o1: Denotable_Object)

Operaciones para relaciones 1:M:

• create (o1: Denotable_Object, s: Set Denotable_Object )
• delete ()
• add_one_to_one (o1: Denotable_Object, o2: Denotable_Object)
• remove_one_to_one (o1: Denotable_Object, o2: Denotable_Object)
• traverse (from: Denotable_Object) -> s: Set Denotable_Object

Operaciones para relaciones 1:1:

• create (o1: Denotable_Object, o2: Denotable_Object)
• delete ()
• traverse (from: Denotable_Object) -> to: Denotable_Object

Modelado del comportamiento ODMG-93

Se representa con un conjunto de operaciones. Cada operación tiene una firma que contiene los nombres y tipos de los argumentos, excepciones y tipos y valores de regreso. Siempre se aplican sobre un solo objeto. No hay operaciones independientes de un tipo, ni pueden ser definidas para 2 o más tipos.

Las operaciones son únicas dentro de un tipo y pueden tener el mismo nombre para diferentes tipos. El tipo selecionado en el despachado de la operación será el tipo más específico del primer argumento.

Los argumentos pueden ser cualquier objeto denotable. Los resultados pueden ser cualquier objeto denotable o conjunto de ellos. Una operación sin valor de regreso especificado regresa nulo.

Las operaciones para el tipo Operation son:

• invoke ()
• return ()
• return_abnormally (e : Exception)

Ellas no pueden ser llamadas por los programas en la mayoría de los lenguajes de programación.

El modelo asume una ejecución secuencial de las operaciones.

No requiere soporte para operaciones concurrentes ni paralelas ni remotas.

El lugar por omisión donde se efectúa una operación es donde fue invocada.

Las excepciones son objetos y pueden organizarse en jerarquías subtipo/supertipo.

La raíz de dicha jerarquía es el tipo Exception proveido por el sistema. Este tipo incluye una operación para desplegar el mensaje, el tipo de excepción y terminar el proceso. La información sobre la causa de la excepción y su contexto se pasa al manejador de excepciones como una propiedad del objeto excepción.

Objetos estructurados ODMG-93

• Structured_Object (Mutables)
  • Collection
    • Set
    • Bag
    • List
    • Array
  • Structure

Las colecciones tienen un número variable de elementos del mismo tipo y no tienen ranuras. Se aceptan subtipos del tipo especificado.
Inserción y recuperación se hacen en base a posiciones absolutas o relativas, al inicio, fin, antes o después. Ademas se puede definir un predicado para recuperar elementos.

Pueden ser ordenadas o no, por orden de llegada o por valor. Pueden permitir la repetición de objetos o no.

Las estructuras tienen un número fijo de ranuras, cada una conteniendo un objeto o un literal. Inserciones, eliminaciones y recuperaciones se hacen con el nombre de la ranura y el operador punto.

El modelo soporta conjunto de estructuras, arreglos de ellas, etc.

Colecciones ODMG-93

Una colección es un objeto que agrupa otros objetos. Ejm: conjunto de, lista de, etc.

Se pueden definir sobre referencias o punteros a objetos.

Este es un tipo parametrizado, por lo cual permite el chequeo de tipo a tiempo de compilación.

Cada colección tiene su identidad inmutable.

Hay dos tipos de colecciones: predicate_defined y insertion_defined. Las primeras usan el predicado es del tipo T haciendo que todas las instancias de la extensión sean de tipo T. Las otras son responsabilidad del programador.

La inclusión de un objeto de tipo T en la colección no es automática, asi como tampoco su exclusión.

Se puede iterar sobre los elementos de la colección con un iterador. Para colecciones desordenadas el orden de iteración es arbitrario.

type Iterator <T>

properties:

stable? : Boolean
iteration_order : Enumeration (forward, backward)

operations:
next () -> element : T
first () -> element : T
last () -> element : T
more?() -> b : Boolean
reset ()
delete ()

La operación create_iterator se define para la colección y puede tener mas de uno.

Las colecciones definidas por el sistema son:

• Set <T>
• Bag <T>
• List <T>
• Array <T>

properties:
cardinality : Integer
empty? : Boolean
ordered? : Boolean
allows_duplicates? : Boolean

operations:
• create ([pragma {,pragma}]) -> c : Collection <T>
  where pragma ::= clustering | expected_cardinality | representation
• delete ()
• copy (c2 : Collection T [pragma {, pragma}])
  where pragma ::= clustering | representation
• insert_element (o : Denotable_Object)
• remove_element (o : Denotable_Object)
• remove_element_at (current_position : Iterator)
• replace_element_at (o : Denotable_Object, current_position : Iterator)
• retrieve_element_at (current_position : Iterator) - element : T
• select_element (predicate : String) -> element : T
• select (predicate : String) -> c : Collection <T>
• create_iterator (stable : Boolean) -> i : Iterator
• .....

properties:
indexed? : Boolean
operations:
• create_index (on : property of element [, t : Index_type])
• create_index (on : component of element [ t : Index_type])
• create_index (on : function [, t : index_type])
• create_index (on : value [, t : Index_type])
• drop_index ()

Tipo Set <T>

Son colecciones desordenadas que no permiten duplicados. Ella redefine:

• create () -> s : Set <T>
• insert_element (o : T)

• union (s2 : Set <T> ) -> s3 : Set T
• intersection (s2 : Set <T> ) -> s3 : Set T
• difference (s2 : Set <T> ) -> s3 : Set T
• .......

Tipo Bag <T>

Son colecciones desordenadas que permiten duplicados. Ella redefine

• create () -> b : Bag <T>
• insert_element (o : T )
• remove_element (element : T)
• select (predicate : String) -> b : Bag <T>

• union (b2 : Bag <T> ) -> b3 : Bag <T>
• intersection ( b2 : Bag <T> ) -> b3 : Bag <T>
• difference ( b2 : Bag <T> ) -> b3 : Bag <T>

Tipo List <T>

Son colecciones ordenadas por orden de inserción, que permiten duplicados. Ella define otra propiedad current_position : Integer redefine algunas operaciones heredadas como

• create () -> l : List <T>
• insert_element (o : T )
• select (predicate : String) -> l : List <T>

• insert_element_after (o : T, position : Integer)
• ......

Tipo Array <T>

Son arreglos unidimensionales de longitud variable. En la creation se define un tamaño inicial y luego si cambia de tamaño este puede cambiarse implicita o explicitamente. Implicitamente, mediante asignación a posiciones fuera de rango. Ella redefine

• create (length : Integer) -> a : Array <T>
• insert_element_at (o : T, position : Integer)

• remove_element_at (o : T, position : Integer)
• replace_element_at ( o : T, position : Integer)
• retrieve_element_at (position : Integer) -> element : T
• resize (new_size : Integer)

Tipo Structure

Es un tipo sin nombre que agrupa elementos. Cada elemento se compone de un par nombre, valor, donde el valor puede ser de cualquier subtipo del tipo Denotable_Object. Como ellas se componen de literales pueden ser valores de los atributos.

Las operaciones definidas para el tipo Structure e₁ : T₁, ... , e_n : T_n son

• create ([ initializer_list ]) -> s : Structure
• delete ()
• get_element_value (element) -> value : Denotable_Object
• ....

Literales estructurados:

Jerarquía de tipos ODMG-93

• Denotable_Object
  • Object
    • Atomic_Object
      • Type
      • Exception
      • Iterator
    • Structured_Object
      • Collection <T>
        • Set <T>
        • Bag <T>
        • List <T>
          String
          Bit_String
        • Array <T>
      • Structure e₁ : T₁, ... , e_n : T_n
  • Literal
    • Atomic_Literal
      • Integer
      • Float
      • Character
      • Boolean
    • Structured_Literal
      • Inmutable_Collection <T>
        • Inmutable_Set <T>
        • Inmutable_Bag <T>
        • Inmutable_List <T>
          • Inmutable_String
          • Inmutable_Bit_String
        • Inmutable_Array <T>
        • Enumeration
      • Inmutable_Structure e₁ : T₁, ... , e_n : T_n
        • Date
        • Time
        • Timestamp
        • Interval
• Characteristics
  • Property
    • Attribute
    • Relationship
  • Operation

Todos los tipos son instancias del tipo Type que a su vez es subtipo e instancia del tipo Atomic_Object. Los metadatos que definen el esquema de una base de datos son accesibles con las mismas operaciones definidas por el usuario a sus tipos.

El tipo Type tiene las siguientes propiedades

• has_operations : Set Operation
• has_properties : Set Property
• has_subtypes : Set Type
• has_supertype : Set Type
• name : String
• extent : Set Atomic_Object
• name_of_extent : String

Transacciones ODMG-93

Transaction::begin () - t : Transaction
....
Transaction::begin () - x : Transaction
....
Transaction::begin () - y : Transaction
....
if errorMenor y.abort()
if errorFatal y.abort_top_level()
.....
y.commit()
...
x.commit()
...
t.commit()

• begin ([optimistic]) -> t : Transaction
• commit ()
• abort ()
• checkpoint ()
• abort_to_top_level ()

• open ()
• close ()
• contains_objects? (iod : Object) -> b : Boolean
• lookup_object (oid : Object) -> b : Boolean

Cada base de datos tiene un esquema que contiene el conjunto de las definiciones de sus tipos.

Una BD lógica puede ser almacenada en una o más BD físicas.

Cada BD es una instancia del tipo Database.

Los nombres de sus tipos y sus extensiones son globales para la BD una vez abierta.

Programa