bag

II- Padrão ODMG
Object Definifion Language - ODL
II.1 O Modelo de
Objeto
Conceitos
Classe
Interface
[Atributo]
[Relacionam.]
[Atributo]
[Assinatura de
Método]
[Chave]
[Assinatura de
Método]
Repositório
[Herança]
[Herança]
Classe e Interface
• Toda classe é concreta
– Repositório é o único elemento
obrigatório
• Toda interface é abstrata
– Classe abstrata (UML)
Atributo Coleção
• Uma coleção pode ser set, bag, list, array
– Um conjunto (set) tem elementos desordenados,
e somente uma ocorrência de cada elemento
– Um bag permite mais de uma ocorrência de um
elemento, mas as ocorrências ainda são
desordenadas
– Uma lista (list) permite mais de uma ocorrência
de um elemento, mas as ocorrências são
ordenadas
– Um array é uma lista com tamanho máximo prédeterminado
Ordem
Repetição Tamanho
Set
Bag

List


Array



• {1, 2, 1} e {2, 1, 1} são um mesmo bag
• {1, 2, 1} e {2, 1, 1} não são a mesma
lista
Relacionamento
• Relacionamentos são entre classes e
binários
– Dois objetos de classes diferentes ou da
mesma classe são associados de alguma
forma
– Explicitamente representados por um
par de referências inversas
Método
• Somente assinatura de métodos (nome do
método, parâmetros, exceções) é conceito
do modelo
– O corpo de um método pode ser implementado
usando qualquer linguagem de programação OO
(Java, C++, PL/SQL etc)
• Métodos do tipo get_atributo()
(métodos observer) e do tipo
set_atributo() (métodos mutator) são
implicitamente definidos
Chave
• Uma classe pode ter uma ou mais
chaves (key(s))
• Uma chave pode também ser definida
por um relacionamento ou um método
– Um relacionamento ou um método podem
fazer parte de uma chave composta
Repositório
• A toda classe, deve ser definido um
repositório (extent)
Herança
• Uma classe pode herdar de uma única
classe (class extends class)
• Uma classe pode herdar de múltiplas
interfaces (class implements
interface)
• Uma forma limitada de herança
múltipla
–
Uma classe e várias interfaces
Omissões do Modelo
• Não tem o conceito de relacionamento
agregação / composição
• Não tem o conceito de relacionamento
ternário
• Não tem o conceito de método de classe
– Não é propriamente um defeito!
• Conceito limitado de herança múltipla
• Não tem o conceito de classe de associação
II.2 A Linguagem ODL
• Interface
interface Métodos_Filme
{
float duração_em_horas()
raises(duração não encontrada)
/* converte duração em min para duração em hh:min */;
nomes_estrelas(out Set<Estrela>)
/* retorna o conjunto das estrelas de um filme */;
nome_estúdio(out string)
raises (estúdio não encontrado)
/* retorna o nome do estúdio que realizou o filme */;
...
};
Classe
• Classes nativas
–
–
–
–
–
–
–
–
–
Integer
Float
String
Boolean
Date
Enumeration
Struct
Collection
XML
class Filme : Métodos_Filme
(extent Filmes key (título, ano))
{
attribute string título;
attribute integer ano;
attribute integer duração;
attribute enumeration Cor{colorido, preto-e-branco}
corfilme;
relationship Set<Estrela> estrelado_por
inverse Estrela::estrelou_em;
relationship Estúdio realizado_por inverse
Estúdio::realizou;
}
• A classe Filme podia ter sido definida
sem a interface, isto é, com todos os
métodos definidos dentro da classe
class Estrela : Métodos_Estrela
(extent Estrelas key nome)
{
attribute string nome;
attribute Struct
End {string rua, string cidade} endereço;
relationship Set<Filme> estrelou_em
inverse Filme::estrelado_por;
}
class Estúdio : Métodos_Estúdio
(extent Estúdios key nome)
{
attribute string nome;
attribute Estrela::End endereço;
relationship Set<Filme> realizou inverse
Filme::realizado_por;
}
• Pergunta: A estrutura End poderia
ser definida como uma interface?
Como?
Atributo Coleção
• Attribute Bag<tipo_do_elemento>
atrib
• Attribute List<tipo_do_elemento>
atrib
• Attribute Array<tipo_do_elem, N>
atrib
Atributo versus
Relacionamento
•
•
•
•
•
Attribute List<float> é legal
Relationship List<float> é ilegal
Attribute List<Filme> é ilegal
Relationship List<Filme> é legal
Relationship só pode envolver classe
definida pelo usuário (classe), por
exemplo Relationship List<Filme>
• Attribute só pode envolver classes
nativas
Relacionamento
Ternário?
• Como determinar a multiplicidade de
um relacionamento ternário?
– Agregando duas classes, por vez
• Filme-Estrela, Estúdio
• Filme-Estúdio, Estrela
• Estrela-Estúdio, Filme
– Não conseguimos raciocinar
ternariamente
• Como ODL não oferece relacionamento
ternário, devemos usar uma regra de
transformação 1 relacionamento ternário
 3 relacionamentos binários
– O relacionamento é elevado a classe
• Eventuais perdas de informação
decorrentes da transformação devem ser
supridas com regras de integridade
Filme
Estrela
Contrato
M Valor
N
P
o_estúdio
Estúdio
A chave de Contrato é
Filme-Estrela-Estúdio
• Definição da classe Contrato
Class Contrato
(extent Contratos key (o_filme, a_estrela,
o_estudio))
{
attribute float valor;
relationship Filme o_filme inverse …;
relationship Estrela a_estrela inverse …;
relationship Estudio o_estudio inverse …;
};
• Na classe Filme
Relationship Set<Contrato> contratos
inverse Contrato::o_filme;
• Na classe Estrela
Relationship Set<Contrato> contratos
inverse Contrato::a_estrela;
• Na classe Estúdio
Relationship Set<Contrato> contratos
inverse Contrato::o_estúdio;
• De um modo geral
– Suponha uma relacionamento ternário R
entre as classes C1, C2 e C3. Podemos
substituir R por uma classe C e 3
relacionamentos binários N:1 de C (N)
para cada uma das Ci (1). Os atributos
de C são os atributos do relacionamento
ternário. C também se relaciona com
cada Ci
Herança de Classe
class Des_Animado extends Filme
{...
relationship Set<Estrela> dublado_por;
...};
• Como interpretar o relacionamento
Des_Animado estrelado-por Estrela?
Herança de Classe /
Interface
• Class C2 : I1 : I2 : I3 extends C1
– Uma forma limitada de herança múltipla
Regras de Integridade
• Chave. Dado o conjunto de atributoschave de uma classe, não pode haver
dois objetos da classe com o mesmo
valor da chave, e o valor da chave
deve ser obrigatoriamente informado,
quando da criação do objeto
• Valor opcional. Todos os
atributos/relacionamentos de uma classe
que não são chave são opcionais, isto é,
seus valores não precisam ser
obrigatoriamente informados. Cabe aos
projetistas definir como indicar que o valor
de um atributo não é informado
– enumeration Cor{preto_e_branco, colorido, null}
corfilme
– integer duração /* um valor negativo informa
que a duração de um objeto da classe Filme não
é informada */
• Par de Referências Inversas. Garante
que, se um objeto x de uma classe A
aponta para um objeto y de uma
classe B  A e B não
necessariamente diferentes  então
y aponta para x, e y não apontará
para nenhum objeto da classe A que
não aponte para ele. O par de
referências inversas permite a
correta navegação de A para B, e de
B para A
• Integridade Referencial. A única
forma de garantir integridade
referencial é definindo pares de
referências inversas. A garantia é
restrita: se dois objetos apontam um
para o outro (ciclo), nenhum dos dois
pode ser destruído individualmente,
pois romperia o ciclo; a única
possibilidade é a destruição dos dois
‘ao mesmo tempo’ (dentro de uma
transação)
• Integridade de domínio. Classes nativas e
classes definidas pelo usuário
• Regras Gerais. ODL não tem nada como
uma linguagem de definição de regras
gerais de integridade (por exemplo,
"salário maior que o mínimo", "um gerente
não pode ganhar menos que seus
subordinados", etc). As regras de
integridade devem ser embutidas, pelos
projetistas, nos corpos dos métodos
construtores
Exercícios
• Suponha que conceitualmente você
tem um array, mas o modelo lógico
objeto-relacional só oferece o tipo
tabela, que é um bag ou um conjunto.
Explique como você simularia o array
como um bag ou um conjunto
• Dado um pedido de compra
Código
Cliente
Data_emissão Data_entrega
Linha Item Quantidade Total Parcial
xx
xxx
xx
xx.xxx,xx
xx
xxx
xx
xx.xxx,xx
...
xx
xxx
xx
xx.xxx,xx
Total Geral: xxx.xxx,xx
definir a classe ODL PedidoDeCompra
• Descreva em ODL a classe
Empregado, com os atributos
matricula, nome, salario e gerente. A
classe deve ter obrigatoriamente um
método que encontra a matrícula, o
nome e o salário do gerente de um
empregado
• Considere o seguinte diagrama
UML
Imagine que A é Fornecedor, B é Produto,
e Associação é Fornecimento. Descreva este
diagrama de classes em ODL. Este exercício serve
para mostrar que Classe Associação é um conceito
dispensável, ou não essencial
• Crie uma classe-ODL, Calendário, fazendo
observar as particularidades dos
ambientes onde um calendário é aplicado.
Exemplos:
– Calendário comercial - Dias úteis: de segunda a
sexta, menos os feriados;
– Calendário hospitalar - Dias úteis: todos os
dias;
– Calendário escolar - de segunda a sexta, menos
os feriados, e eventualmente sábado; exceções:
todo o mês de janeiro e todo o mês de julho
• Defina a classe Pessoa, incluindo a
árvore genealógica