A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

Relacionamentos UML e Polimorfismo

Apresentações semelhantes


Apresentação em tema: "Relacionamentos UML e Polimorfismo"— Transcrição da apresentação:

1 Relacionamentos UML e Polimorfismo
Oberdan Bitencourt Ferreira

2 Relacionamentos UML e Polimorfismo Associação Composição Agregação
Dependência Realização Herança Polimorfismo

3 Relacionamentos UML Tipos de Relacionamento
Associação Conexão entre classes Agregação/Composição Especialização de uma associação onde um todo é relacionado com suas partes (relacionamento “parte-de” ou “contenção”) Herança(Generalização): Um dos princípios da OO, permite a reutilização, uma nova classe pode ser definida a partir de outra já existente Dependência Um objeto depende de alguma forma de outro (relacionamento de utilização) Realização Um contrato que classe faz(obrigação)

4 Relacionamentos UML Tipos de Relacionamento

5 Relacionamentos UML Associação
Uma associação é uma conexão entre classes Associações são representadas em um diagrama de classe através de uma linha conectando as classes associadas. Os dados podem fluir em uma ou em ambas as direções através do link.

6 Relacionamentos UML Associação
class Departamento{ private Empregado empregados[ ] = new Empregado[N]; } class Empregado{ private Departamento dept;

7 Relacionamentos UML Composição
Descreve uma classe que contém outras classes, onde podemos visualizar uma relação todo-parte. As partes dependem da existência do todo. Se o todo deixa de existir, também deixam de existir as partes. Também há o efeito de nenhuma das partes poder pertencer a mais de um todo. Por isso, neste tipo de relacionamento, a cardinalidade da classe que representa o "todo" é sempre 1. Para descobrir se existe este relacionamento, olhamos para o problema e tentamos ver se há "todos" e "partes". Um exemplo interessante é o que vemos em um texto. Uma frase é parte de um parágrafo, que por sua vez é parte de um capítulo, que por sua vez é parte de um livro.

8 Relacionamentos UML Composição
class Empresa{ private Departamento deptos[]; public Empresa(){ depts = new Departamento[50]; } public void adicionaDepartamento(int pos){ deptos[pos] = new Departamento();

9 Relacionamentos UML Agregação
Uma pura associação entre duas classes representa um relacionamento estrutural entre pares, significando que essas duas classes estão conceitualmente em um mesmo nível, sem que uma seja mais importante do que a outra. Representa um relacionamento do tipo “tem-um”, o que significa que um objeto do todo contém os objetos das partes. A agregação é uma forma fraca de composição. Na agregação, as partes não são destruídas quando o todo deixa de existir. Isto significa que a parte é independente do todo, ou seja, têm vida própria, mas o todo requer a parte. Nesse caso, também a parte pode pertencer a outro todo. Podemos ver a agregação como o todo contendo as partes.

10 Relacionamentos UML Agregação
Agregação é uma forma especializada de associação especificada utilizando-se uma associação simples com um losango aberto na extremidade do todo Agregação é conhecido como um relacionamento de contenção ou “todo-parte”. Agregação: a “é parte essencial de” b

11 Relacionamentos UML Agregação
class Projeto private IList<Projetista> equipe = new List<Projetista>( ); public adicionaProjetista(Projetista umProjetista){ equipe.add(umProjetista); { }

12 Relacionamentos UML Dependência
Dois elementos de modelo: um dependente e um independente. Uma modificação no elemento independente poderá afetar o elemento dependente. O relacionamento pode acontecer entre diversos tipos de elementos de modelo. Não há associação explícita entre os elementos. Ocorre quanto uma classe A apenas usa a instância de uma outra classe B, geralmente para que a classe A use um serviço da classe B.

13 Relacionamentos UML Dependência

14 Relacionamentos UML Realização
Relacionamento no qual um item especifica um contrato cujo cumprimento é realizado por outro item. São encontrados em dois locais Entre interfaces e as classes ou componentes que as realizam Entre casos de uso e as colaborações que os realizam

15 Relacionamentos UML Realização

16 Relacionamentos UML Herança
Herança é o mecanismo pelo qual elementos mais específicos incorporam a estrutura e o comportamento de elementos mais gerais. Atributos, operações e relacionamentos são herdados Herança define uma hierarquia de abstrações na qual uma subclasse herda de uma ou mais superclasses Herança simples: a subclasse herda de uma única superclasse Herança múltipla: a subclasse herda de duas ou mais superclasse (Não existe no C#) Herança é um relacionamento “é um”ou “tipo de”

17 Relacionamentos UML Herança
O relacionamento de herança não relaciona objetos individuais: O relacionamento não é nomeado no diagrama UML Multiplicidade não se aplica Uma classe herda de uma Superclasse: Os atributos (desde que não sejam privados) As operações (desde que não sejam privados) Os relacionamentos Uma Subclasse pode: Adicionar atributos, operações e relacionamentos Redefinir operações herdadas.

18 Relacionamentos UML Herança
Para usar herança, alguns critérios devem ser satisfeitos: CRITÉRIO 1 A subclasse deve expressar uma relação “é um tipo especial de” e não “pode exercer o papel de”, em outras palavras, a herança NUNCA deve mudar a função da superclasse. CRITÉRIO 2 A subclasse deve especializar uma papel, uma transação ou um dispositivo, sem NUNCA mudar a função da superclasse. CRITÉRIO 3 A subclasse deve estender, e NUNCA redefinir e NUNCA anular o contrato (responsabilidade) da superclasse. CRITÉRIO 4 A subclasse NUNCA deve estender funcionalidades de classes utilitárias.

19 Relacionamentos UML Herança
Critério Atendido ? Motivo Critério 1 Sim As classes Reserva e Pagamento são tipos especiais de Transacao Critério 2 As classes Reserva e Pagamento especializam uma transação. Critério 3 As classes Reserva e Pagamento apenas estendem, sem redefinir e nem anular a responsabilidade ou contrato de Transação Critério 4 As classes Reserva e Pagamento não especializa uma classe utilitária Os quatro critérios foram satisfeitos, então esse é um exemplo de utilização adequada de herança

20 Relacionamentos UML Herança
Critério Atendido ? Motivo Critério 1 Não A subclasse Reserva não é um tipo especial de objetos Observable Critério 2 A classe Observable é uma classe utilitária e não faz parte do domínio da aplicação. Critério 3 Sim A subclasse Reserva apenas adiciona funcionalidades sem rederinir ou anular a responsabilidade da superclasse. Critério 4 A subclasse Reserva estende uma classe utilitária. Os quatro critérios não foram satisfeitos mutuamente, então este é um caso onde herança não deve ser usada.

21 Polimorfismo Conceito
O polimorfismo é uma característica dos sistemas e da programação orientada por objetos. Esta técnica é que faz da Orientação por Objetos uma ferramenta interessante. O polimorfismo está intimamente relacionado à capacidade de estendermos um sistema sem que tenhamos de alterar substancialmente o que já existe. O essencial em um programa que faz uso do polimorfismo é a existência de uma superclasse base, que contêm métodos que são modificados em cada subclasse para implementar diferentes comportamentos, de acordo com a natureza de cada subclasse.

22 Polimorfismo Ad-hoc O polimorfismo ad-hoc permite ter funções do mesmo nome, com funcionalidades similares, em classes sem nenhuma relação entre elas (a não ser, claro, serem filhas da classe objeto). O polimorfismo ad-hoc permite assim definir operadores cuja utilização será diferente de acordo com o tipo dos parâmetros que lhes são passados. É por isso possível, por exemplo, sobrecarregar o operador + e fazê-lo realizar ações diferentes conforme se trate de uma operação entre duas totalidades (adição) ou entre duas cadeias de caracteres (concatenação).

23 Polimorfismo Paramétrico
O polimorfismo paramétrico representa a possibilidade de definir várias funções do mesmo nome mas possuindo parâmetros diferentes (em número e/ou tipo). O polimorfismo paramétrico torna assim possível a escolha automática do bom método a adotar em função do tipo de dado passado em parâmetro. Assim, pode-se por exemplo definir vários métodos homônimos add() efetuando uma soma de valores. O método int add (int, int) poderá dar a soma de duas totalidades O método float add (float, float) poderá dar a soma de dois flutuantes O método char add(char, char) poderá definir à vontade do autor a soma de dois caracteres etc. Chama-se assinatura ao número e tipo (estático) dos argumentos de uma função. É por conseguinte a assinatura de um método que determina qual será chamado.

24 Polimorfismo Polimorfismo de Herança
Permite fazer abstração dos detalhes das classes especializadas de uma família de objeto, mascarando-o com um interface comum (que é a classe básica). Imagine um jogo de xadrez que comporta os objetos rei, rainha, bispo, cavalo, torre e peão, herdando cada um do objeto peça. O método movimento() poderá, graças ao polimorfismo de herança, efetuar o movimento adequado em função da classe do objeto remetido no momento da chamada. Isto permitirá nomeadamente ao programa dizer peça.movimento() sem ter de se preocupar com a classe da peça.

25 Polimorfismo Polimorfismo de Herança

26 Polimorfismo Extra: Classe Abstrata
Geralmente quando construímos uma hierarquia de classes, há classes que não são projetadas para ser instanciadas (Elas são importantes para o Polimorfismo). No exemplo apresentado anteriormente, a classe base Animal não tem sentido de ser usada para criarmos objetos dela, uma vez que ela foi criada para que seus elementos fossem reaproveitados nas subclasses (Vaca, Cao e Gato). Para deixar claro que não vamos usar a classe para gerar objetos (instanciação), precedemos sua declaração com o marcador abstract. Com isto, se tentarmos instanciar um objeto dela, o compilador apresentará um erro.

27 Mão na massa


Carregar ppt "Relacionamentos UML e Polimorfismo"

Apresentações semelhantes


Anúncios Google