Modelo de objectos 2

Apoiantes da norma

Object Database Management Group
• representa 90 % do mercado existente de SGBDO’s:
– Object Design
– Objectivity
– O2
– Versant
– Ontos
– Servio
– Itasca
e liderado por Rick Cattell da SunSoft
Modelo de objectos - 1
Modelo de objectos



Modelo proposto pela ODMG (Object Database Management Group
dirigido por Rick Cattell) para servir como norma (versão 2.0) para
BDOO
Modelo abstracto — existem mapeamentos para C++, Smalltalk e
Java
Arquitectura com três componentes




ODL - Object Definition Language — interesse para o projecto
OQL - Object Query Language — extracção de informação
OML - Object Manipulation Language — alteração dos dados; pouco desenvolvida na
norma por ser específica de cada linguagem
ODL é uma extensão da IDL (Interface Description Language), a
componente da CORBA que descreve as interfaces entre objectos
Modelo de objectos - 2
CORBA

Common Object Request Broker Architecture







norma desenvolvida pelo OMG (Object Management Group) para sistemas de objectos
distribuídos
pretende tornar a distribuição transparente
e aumentar a interoperabilidade
fornece uma infraestrutura que permite encontrar um determinado objecto para lhe
solicitar um serviço e que faz as conversões necessárias
cada objecto apresenta ao sistema uma interface com a sua descrição feita em IDL
(Interface Description Language)
as aplicações ligam-se através
dessa interface a uma espécie
de barramento de dados
houve a preocupação de garantir
IDL
IDL
IDL
que o modelo de objectos ODMG
fosse um superconjunto do modelo
de objectos OMG
CORBA
Modelo de objectos - 3
Linguagem de Definição de Objectos


em ODL o Mundo é constituído por objectos, com identidade,
agrupados em classes
uma classe agrupa objectos que



propriedades:




correspondem a conceitos do mundo real semelhantes
têm todos as mesmas propriedades
atributos - têm tipos baseados em tipos primitivos, que não envolvam classes
associações - referência ou colecção de referências para objectos
métodos - funções aplicáveis aos objectos da classe
declaração de uma classe (muito ao estilo C++)
interface <nome> {
<lista de propriedades>
}
Modelo de objectos - 4
Exemplo

As definições de classe em rigor têm uma interface e uma
implementação (daí a designação)
interface Filme {
attribute string titulo;
attribute integer ano;
attribute integer comprimento;
attribute enum Filme {cor, pretoBranco} tipoFilme;
}


o quarto atributo é do tipo enumerado Filme, o qual é um conjunto
com dois literais cor, pretoBranco
interface Estrela {
attribute string nome;
attribute Struct Morada {string rua, string cidade} endereco;
}
neste exemplo existe um atributo composto, mas sem referência
Modelo de objectos - 5
Associações

Representar as participações de estrelas em filmes


acrescenta uma linha a Filme com um conjunto (Set) de referências para Estrelas
relationship Set<Estrela> estrelas;
ou acrescenta uma linha a Estrela, com uma referência para o Filme de que é a estrela
principal
relationship Set<Filme> filmes;
Estrela
nome
morada
rua
cidade
filmes
Filme
titulo
ano
comprimento
tipoFilme
estrelas
Modelo de objectos - 6
Associação inversa


é natural que se no objecto Jack Nicholson, no conjunto dos filmes
constar o objecto Shinning, se espere ir encontrar no objecto Shinning
uma referência ao Jack Nicholson
a manutenção da coerência em ambos os lados de uma associação
pode ser feita automaticamente, desde que, numa classe, se indique
qual o atributo que faz par na outra e é usado para garantir o inverso.
interface Estrela {
attribute string nome;
attribute Struct Morada {string rua, string cidade} endereco;
relationship Set<Filme> filmes inverse Filme::estrelas;
}

em ODL, por ser abstracta, insiste-se na existência de inversa


permite percorrer os dados arbitrariamente nos vários sentidos
uma concretização numa linguagem OO, pode levar a só criar inversos em associações
que o justifiquem.
Modelo de objectos - 7
Multiplicidade das associações


Muitos-para-muitos: é o caso da estrelas nos filmes; implementada
com conjuntos de ambos os lados
Muitos-para-um: proprietário de um filme; implementada com um
conjunto de um lado mais uma referência simples do outro
interface Filme {
attribute string titulo;
attribute integer ano;
attribute integer comprimento;
attribute enum Filme {cor, pretoBranco} tipoFilme;
relationship Set<Estrela> estrelas inverse Estrela::filmes;
relationship Estudio proprietario inverse Estudio::possui; }
interface Estudio {
attribute string nome;
attribute string endereco;
relationship Set<Filme> possui inverse Filme::proprietario; }

Um-para-um: caso dos presidentes dos estúdios; implementada com
uma referência simples quer de um lado quer do outro
Modelo de objectos - 8
Tipos em ODL

Tipos atómicos integer, float, character, string, boolean, enumeration



Tipos interface na realidade são estruturas com componentes para os
atributos e para as associações mas, uma vez definidos, podem
também ser vistos como tipos base
Construtores de tipos






enumerações são listas de constantes vistas como sinónimos dos inteiros
Set (conjunto) - sem repetidos e sem ordem
{1, 2}
Bag (multiconjunto) - com repetidos e sem ordem
{1,2,1}={2,1,1}
List (lista) - com repetidos e com ordem; string = List<char>
(1,2,1)  (2,1,1)
Array (vector) - com repetidos e com ordem, com dimensão definida; Array<char,10>
denota as cadeias de caracteres de comprimento 10
Struct (estrutura) - se T1, T2, …, Tn forem tipos e F1, F2, …, Fn nomes de campos Struct
N{ T1 F1, T2 F2, …, Tn Fn } é uma estrutura
Colecções: Set, Bag, List, Array
Modelo de objectos - 9
Regras de uso dos tipos

Atributos - começam em tipos atómicos ou estruturas só com tipos
atómicos e podem ser envolvidos por uma colecção (4 casos possíveis)





integer
Struct N {string campo1, integer campo2}
List<float>
Array<struct N {string campo1, integer campo2}>
Associações - tipo interface ou um tipo colecção aplicado a um tipo
interface


possível: Filme; Bag<Estrelas>
impossível:
• Struct N {Filme campo1, Estrela campo2} - envolve uma estrutura
• Set<integer> - envolve só tipos atómicos
• Set<Array<Estrela>> - envolve colecção de colecções
Modelo de objectos - 10
Princípios de projecto


Fidelidade às especificações
evitar a redundância



cada facto da realidade deve estar representado num único sítio no sistema
as relações inversas, se automaticamente mantidas, não implicam redundância
parcimónia e simplicidade

KISS (keep it simple, stupid)

escolha do elemento apropriado para representar a realidade

Declaração de chave (objectos continuam a ter identidade)

interface filme
key( titulo, ano)
{…}
Modelo de objectos - 11
Subclasses


por vezes ocorre que, numa dada classe, parte dos seus objectos tem,
para além das características comuns a todos os outros, algumas
propriedades específicas. Nesse caso faz sentido usar o conceito de
subclasse.
Notação: pôr a seguir ao nome da classe a ser definida, dois pontos e
respectiva superclasse
interface Cartoon : Filme {
relationship Set<Estrela> vozes; // inverse Estrela::personagensAnimação;
}


a subclasse herda todas as propriedades de todos os que estão para
cima na hierarquia
herança múltipla: se existir interface Policial : Filme {attribute string arma}
interface Cartoon-policial : Cartoon, Policial {};
herda dos dois lados, mas para uma classe acessível por mais do que
um caminho só herda uma vez (Filme que é superclasse duplamente)
Modelo de objectos - 12
Exemplo dos Internamentos
Considere o seguinte esquema de uma BD de um hospital. O hospital
organiza-se em serviços, cada qual com a designação da respectiva
especialidade e o número de camas onde pode internar doentes. Os
doentes são pessoas adicionalmente descritas pelo organismo de
segurança social e respectivo número. Relativamente a cada
internamento, regista-se o momento de entrada no serviço, o motivo, o
respectivo momento de alta, o estado à saída e o médico responsável;
uma transferência de serviço corresponde a uma alta do primeiro em
simultâneo com um novo internamento no segundo. Os funcionários
são pessoas com um vencimento e o serviço a que estão adstritos. Os
médicos são funcionários com uma especialidade e os enfermeiros são
também funcionários com uma categoria e que pertencem a uma
equipa.

Obtenha o modelo de objectos (em ODL) da situação descrita.
Modelo de objectos - 13
Resolução
Object
Servico
Pessoa
Funcionario
Enfermeiro
Doente
*
Internamento
*
refere objecto
Medico
refere conjunto de internamentos (e de
funcionarios no caso dos Servicos)
subclasse
associação com atributo inverso
Equipa
*
associação sem manutenção automática
de atributo inverso (conjuntos têm os
correntes; Internamento os históricos)
Modelo de objectos - 14
Algumas classes
interface Servico {
attribute string designacao;
attribute int camas;
relationship Set<Funcionario> pessoal
inverse Funcionario::serviço;
relationship Set<Internamento> internados
}

a associação pessoal tem uma inversa na
classe de Funcionarios chamada serviço de
forma a garantir a consistência da sua
representação em ambas as classes, i.e.,
que se um funcionário indica a pertença a
um serviço, então esse serviço tem que o
referir como parte do seu pessoal (idem
para Internamento::internado)
interface Internamento {
relationship Doente internado inverse
Doente::internamentos;
attribute date entrada;
attribute date alta;
attribute string motivo;
attribute string estado;
relationship Servico servico;
relationship Medico medico;
}
 a associação Serviço::internados não tem
inversa; no conjunto só se incluem os
internamentos correntes; do lado dos
internamentos, mantém-se o registo
completo, incluindo o histórico, dos
internamentos, pelo que há referências a
objectos serviço sem que nestes existam as
correspondentes ligações a internamentos
(apagadas quando o doente teve alta)
Modelo de objectos - 15