Princípios de Análise e
Projeto Orientados a
Objetos com UML
Eduardo Bezerra
Editora CAMPUS
1
Capítulo 9
Generalização
Se eu vi mais longe que outros, é porque eu me apoiei nos
ombros de gigantes.
Isaac Newton
2
Introdução
 O modelo de classes também pode
representar relacionamentos entre classes.
 Esses denotam relações de generalidade ou
especificidade entre as classes envolvidas.


o conceito mamífero é mais genérico que o
conceito ser humano.
o conceito carro é mais específico que o conceito
veículo.
 Chamado de relacionamento de
generalização.
3
Introdução
 Também pode ser chamado de
relacionamento de especialização, pois a
generalização e a especialização são dois
pontos de vista do mesmo relacionamento.
 O termo herança também é comumente
utilizado como sinônimo do relacionamento
de generalização. (implementação)
 A generalização pode ser utilizada tanto no
modelo de classes de domínio quanto no de
especificação.
4
Introdução
5
Semântica de uma generalização,
.
6
Terminologia
 subclasse X superclasse.
 supertipo X subtipo.
 classe base X classe herdeira.
 classe de especialização X classe de
generalização.
 ancestral e descendente (generalização em
vários níveis)
7
Notação para generalização
Superclasse
Subclasse1
Subclasse2
Superclasse
... SubclasseN
Subclasse1
Subclasse2
... SubclasseN
8
Generalização X Associação
 Importante: a generalização difere da
associação (agregação, composição ) porque
a primeira se trata de um relacionamento
entre classes.


“Gerentes são tipos especiais de funcionários”.
“Gerentes chefiam departamentos”.
 Na associação, objetos específicos de uma
classe se associam entre si ou com objetos
específicos de outras classes.
9
Herança de associações
 Atributos e operações e associações são
herdados pelas subclasses.
Realiza
Cliente
1
ClientePessoaFísica
Pedido
*
ClientePessoaJurídica
10
Hierarquias de generalização
11
Hierarquias de generalização
 A generalização pode ser aplicada em vários
níveis (hierarquia de generalização).

uma classe que herda propriedades de uma outra
classe pode ela própria servir como superclasse.
 Características importantes:
 Transitividade: uma classe em uma hierarquia
herda propriedades e relacionamentos de todos
os seus ancestrais..
 Assimetria: dadas duas classes A e B, se A for
uma generalização de B, então B não pode ser
uma generalização de A. Ou seja, não pode haver
ciclos em uma hierarquia de generalização.
12
Hierarquias de generalização
Pessoa
-nome
-dataNascimento
-endereco
Cliente
-status
O atributo status define se o
cliente é comum ou especial.
Empregado
-matrícula
-dataContratação
Vendedor
-taxaComissão
13
Herança múltipla
14
Herança múltipla
 Herança múltipla: Uma classe pode ter mais
de uma superclasse.

Tal classe herda de todas a suas superclasses.
 O uso de herança múltipla deve ser evitado.
 Esse tipo de herança é difícil de entender.
 Algumas LPs não dão suporte à implementação
desse tipo de herança (Java e Smalltalk).
15
Exemplo (Herança múltipla)
Barco
Carro
CarroAnfíbio
16
Classes abstratas
17
Relacionamentos de dependência
 Usualmente, a existência de uma classe se
justifica pelo fato de haver a possibilidade de
gerar instâncias (classes concretas).
 No entanto, podem existir classes que não
geram instâncias diretas: classes abstratas.
 Utilizadas para organizar e simplificar uma
hierarquia de generalização.

Propriedades comuns a diversas classes podem
ser organizadas e definidas em uma classe
abstrata a partir da qual as primeiras herdam.
 Subclasses de uma classe abstrata também
podem ser abstratas, mas a hierarquia deve
terminar em uma ou mais classes concretas.
18
Notação para classes abstratas
 Na UML, uma classe abstrata é representada
com o seu nome em itálico.
ContaBancária
ContaCorrente
ContaPoupança
19
Definição de restrições
sobre uma generalização
20
Restrições sobre generalizações
 Restrições sobre generalizações são
representadas (entre chaves) no diagrama de
classes próximas à linha do relacionamento.
 Restrições predefinidas pela UML:




Sobreposta
Disjunta
Completa
Incompleta
21
Exemplos (Restrições sobre
generalizações)
FiguraGeométrica
Veículo
{incompleta, disjunta}
{incompleta}
Caminhão
Homem
Trator
Elipse
Quadrado
Círculo
Indivíduo
Atleta
{completa, disjunta}
{incompleta, sobreposta}
Mulher
Nadador
Corredor
22
Refinando o modelo de
classes com generalização
23
Refinando o modelo de classes com
generalização
 A generalização permite refinar o modelo de
classes.

Idéia básica: identificar abstrações mais genéricas
ou mais específicas que outras.
 Refinamentos podem seguir segundo duas
estratégias alternativas e complementares:


Generalização: criar uma classe mais genérica, e
definir as classes semelhantes como subclasses.
Especialização: criar classes mais específicas a
partir de uma classe preexistente.
24
Refinando o modelo de classes com
generalização
 O seguinte teste pode ser realizado para
identificar se duas classes X e Y se
relacionam por generalização:
X é um tipo de Y?
 Regra da substituição: seja a classe A uma
generalização de outra B. Não pode haver
diferenças entre utilizar instâncias de B ou de
A, do ponto de vista dos usuários de A.

Ou seja, é inadequado o uso de generalização
onde nem todas as propriedades da superclasse
fazem sentido para a subclasse.
25
Conformidade das subclasses à
superclasse
Cliente
*
*
ContaBancária
-número
-dataAbertura
-saldo
+debitar()
+creditar()
ContaCorrente
-limiteSaque
HistóricoTransações
1
*
ContaPoupança
-dataAniversário
-rendimento
26
Dicas
 Deve-se evitar a construção de hierarquias
de generalização muito profundas (com mais
de três níveis)

dificultam a leitura do diagrama.
 Papéis e subclasses não devem ser
confundidos.


Um papel corresponde ao uso de uma certa
classe em uma associação.Uma classe pode
assumir vários papéis.
O modelador deve evitar a criação de subclasses
em situações que podem ser resolvidas através
da utilização de papéis.
27
Papel X Subclasse
Inadequado
Adequado
Pessoa
morador
Pessoa
Edifício
*
Morador
*
Edifício
*
*
28
Herança de operações e
polimorfismo
29
Herança de operações e polimorfismo
 Uma subclasse herda todas as propriedades
de sua superclasse que tenham visibilidade
pública ou protegida.
 Entretanto, pode ser que o comportamento
de alguma operação herdada seja diferente
para a subclasse.



Nesse caso, a subclasse deve redefinir o
comportamento da operação.
A assinatura da operação pode ser reutilizada.
A implementação da operação (método) é
diferente.
30
Operações polimórficas
 Operações polimórficas são operações de
mesma assinatura definidas em diversos
níveis de uma hierarquia de generalização e
que possuem comportamento diferente.

assinatura é repetida na(s) subclasse(s) para
enfatizar a redefinição de implementação.
 Operações polimórficas implementam o
princípio do polimorfismo no qual duas ou
mais classes respondem a mesma
mensagem de formas diferentes.
 Objetivo: garantir que as subclasses tenham
uma interface em comum.
31
Operações polimórficas
 Operações polimórficas facilitam a
implementação.



Se duas ou mais subclasses implementam a
mesma operação polimórfica, a mensagem a ser
passada é a mesma para todas elas.
O remetente da mensagem não precisa saber
qual a verdadeira classe de cada objeto, pois eles
aceitam a mesma mensagem.
A diferença é que o método que implementa a
operação é diferente em cada classe.
32
Exemplo (Operações polimórficas)
return salárioBase;
return comissão * obterSalárioBase();
Funcionário
-salárioBase : Moeda
+obterPagamento() : Moeda
+definirSalárioBase(in umSalario : Moeda)
+obterSalárioBase() : Moeda
Vendedor
-comissão : Porcentagem
+obterPagamento() : Moeda
33
Operações abstratas e polimorfismo
 Em termos de operações, uma classe é
abstrata quando ela possui pelo menos uma
operação abstrata.
 Uma operação abstrata não possui
implementação.


Uma classe pode possuir tanto operações
abstratas quanto operações concretas.
Uma classe que possui pelo menos uma
operação abstrata é abstrata.
 Uma subclasse que herda uma operação
abstrata e não fornece uma implementação é
ela própria abstrata.
34
Operações abstratas e polimorfismo
 As classes Círculo e Quadrado são
concretas, pois fornecem implementação
para a operação abstrata herdada.
FiguraGeométrica
+desenhar()
Círculo
+desenhar()
Operação abstrata. Subclasses
devem implementar o
comportamento desta operação.
Quadrado
+desenhar()
35
Operações abstratas e polimorfismo
 Classes ContaCorrente e ContaPoupança
redefinem a operação aplicarJuros.
ContaBancária
-saldo : Moeda
+aplicarJuros(in umaTaxa : Porcentagem)
+debitar(in umaQuantia : Moeda)
+creditar(in umaQuantia : Moeda)
ContaCorrente
ContaPoupança
+aplicarJuros(in umaTaxa : Porcentagem)
+aplicarJuros(in umaTaxa : Porcentagem)
36
Reuso através de delegação
37
Reuso por generalização
 O reuso por generalização se baseia na
noção de subclasses herdando
comportamento de sua superclasse.

Exemplo: um objeto ContaCorrente não tem como
atender à mensagem para executar a operação
debitar só com os recursos de sua classe. Ele,
então, utiliza a operação herdada da superclasse.
 Vantagem: fácil de implementar.
 Desvantagem:
 Exposição dos detalhes da superclasse às
subclasses (Princípio do encapsulamento).
 Possível violaçào do Princípio de Liskov (regra da
substituição).
38
Reuso por delegação
 A delegação é outra forma de realizar o
reuso.
 “Sempre que um objeto não pode realizar
uma operação por si próprio, ele delega uma
parte dela para outro(s) objeto(s)”.
 A delegação é mais genérica que a
generalização.

um objeto pode reutilizar o comportamento de
outro sem que o primeiro precise ser uma
subclasse do segundo.
39
Reuso por delegação
 O compartilhamento de comportamento e o
reuso podem ser realizados em tempo de
execução.
 Desvantagens:


desempenho (implica em cruzar a fronteira de um
objeto a outro para enviar uma mensagem).
não pode ser utilizada quando uma classe
parcialmente abstrata está envolvida.
40
Generalização X Delegação
adicionar(objeto, topo)
topo := topo + 1
remover(objeto)
topo := topo - 1
Vetor
Pilha
+adicionar()
+remover()
+obter()
+empilhar()
+desempilhar()
1
topo := topo + 1
vetor.adicionar(topo, objeto)
return vetor.obter(topo)
topo := topo - 1
1
Pilha
+empilhar()
+desempilhar()
Vetor
+adicionar()
+remover()
+obter()
41
Generalização X Delegação
 Há vantagens e desvantagens tanto na
generalização quanto na delegação.
 De forma geral, não é recomendado utilizar
generalização nas seguintes situações:



Para representar papeis de uma superclasse.
Quando a subclasse herda propriedades que não
se aplicam a ela.
Quando um objeto de uma subclasse pode se
transformar em um objeto de outra subclasse.

Por exemplo, um objeto Cliente se transforma em um
objeto Funcionário (vide a seguir).
42
Classificação dinâmica
43
Classificação dinâmica
 Problema na especificação e implementação
de uma generalização.

Um mesmo objeto pode pertencer a múltiplas
classes simultaneamente, ou passar de uma
classe para outra.
 Considere uma empresa em que há
empregados e clientes.



Pode ser que uma pessoa, em um determinado
momento, seja apenas cliente;
depois pode ser que ela passe a ser também um
empregado da empresa.
A seguir essa pessoa é desligada da empresa,
continuando a ser cliente.
44
Classificação dinâmica
 As principais LPOO (C++, Java, Smalltalk)
não dão suporte direto à implementação da
classificação dinâmica.

se um objeto é instanciado como sendo de uma
classe, ele não pode pertencer posteriormente a
uma outra classe.
 Solução parcial: definir todas as possíveis
subclasses em uma determinada situação.

Exemplo (para a situação descrita há pouco): as
classes Empregado, Cliente e EmpregadoCliente
seriam criadas.
45
Classificação dinâmica
 Não resolve o problema todo:
 Pode ser que um objeto mude de classe!
(metamorfose)
 A adição de novas classes à hierarquia torna o
modelo ainda mais complexo.
 Uma melhor solução: utilizar a delegação.
 Uma generalização entre cada subclasse e a
superclasse é substituída por uma composição.
 Exemplo no próximo slide.
46
Classificação dinâmica
Empregado
Cliente
Pessoa
0..1
0..1
1
Cliente
Empregado
1
Pessoa
47
Classificação dinâmica
 Comentário final: nada impede que haja uma
hierarquia de classes em um modelo de
domínio onde um objeto possa pertencer a
mais de uma subclasse, ou possa mudar de
subclasse.
 No modelo de especificação é que o
modelador deve considerar a reestruturação
da hierarquia de classes para resolver o
problema.
48