II- Padrão ODMG Object Definifion Language - ODL

II.1 O Modelo de Objeto

Conceitos ClasseInterface Atributo Relacionamento Assinatura de Método Chave Repositório Herança

Classe e Interface Toda classe é concreta –Reposit ó 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

Atributo Coleção OrdemRepetiçãoTamanho Set Bag  List  Array 

Atributo Coleção {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

Relacionamento (2)

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

Herança (2)

Herança (3)

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 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 ) /* 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

Classe (2) 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 estrelado_por inverse Estrela::estrelou_em; relationship Estúdio realizado_por inverse Estúdio::realizou; }

Classe (3) A classe Filme podia ter sido definida sem a interface, isto é, com todos os m é todos definidos dentro da classe

Classe (4) class Estrela : Métodos_Estrela (extent Estrelas key nome) { attribute string nome; attribute Struct End {string rua, string cidade} endereço; relationship Set estrelou_em inverse Filme::estrelado_por; }

Classe (5) class Estúdio : Métodos_Estúdio (extent Estúdios key nome) { attribute string nome; attribute Estrela::End endereço; relationship Set realizou inverse Filme::realizado_por; }

Classe (6) Pergunta: A estrutura End poderia ser definida como uma interface? Como?

Atributo Coleção Attribute Bag atrib Attribute List atrib Attribute Array atrib

Atributo versus Relacionamento Attribute List é legal Relationship List é ilegal Attribute List é ilegal Relationship List é legal Relationship só pode envolver classe definida pelo usu á rio (classe), por exemplo Relationship List Attribute só pode envolver classes nativas

Relacionamento Ternário?

Relacionamento Ternário? (2) 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 …; };

Relacionamento Ternário? (3) Na classe Filme Relationship Set contratos inverse Contrato::o_filme;

Relacionamento Ternário? (4) 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 Como interpretar o relacionamento Des_Animado estrelado-por Estrela? class Des_Animado extends Filme {... relationship Set dublado_por;...};

Herança de Classe / Interface Class C2 : I1 : I2 : I3 extends C1

Regras de Integridade Chave. Dado o conjunto de atributos- chave 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

Regras de Integridade (2) 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 */

Regras de Integridade (3) 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

Regras de Integridade (4) 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)

Regras de Integridade (5) 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

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

Exercícios (2) 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 Total Geral: xxx.xxx,xx definir a classe ODL PedidoDeCompra

Exercícios (3) 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

Exercícios (4) 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

Exercícios (5) 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

Exercícios (6) Defina a classe Pessoa, incluindo a á rvore geneal ó gica