Professor: Leandro Chernicharo
 Arquitetura
dividida em três níveis:
Nível externo
Nível interno
Nível conceitual
 Nível
externo  o mais próximo do usuário
 Nível
interno  trata de como os dados serão
final: aplicações, resultado de consultas, etc.;
efetivamente armazenados: tipos, algoritmos,
discos, etc.;
 Nível
conceitual  é o modelo que reflete o
banco de dados, abstraindo sua implementação,
preocupando-se apenas com a informação em
si.
É
uma das etapas do Projeto de Banco de
Dados;
 Representa
a visão dos dados a serem
armazenadas abstraindo sua implementação
física;
 Apresenta
 Pode
uma visão estática do sistema;
ser baseado em entidades (MER) ou
em objetos (Diagrama de Classes)
 Etapas
do Projeto de BD:
Modelagem Conceitual
Projeto Lógico de Dados
Projeto Físico de Dados
BD
BD
BD
Conjunto de
Requisitos
“Um modelo de classes de domínio é uma
representação das classes conceituais do
mundo real, não dos componentes do
software. Ele não é um conjunto de
diagramas descrevendo as classes do
software ou objetos do software e suas
responsabilidades”
[LARMAN, Craig, Utilizando UML e Padrões, 2a ed.]
 Modelagem
conceitual de dados é o
processo de criação de um modelo
conceitual de dados a partir dos requisitos
extraídos para um determinado artefato
de software.
“Quem”
Um hospital possui um número de alas,
nas quais os pacientes são admitidos, suas
doenças tratadas, e das quais são
liberados após o tratamento. Cada ala
atende a uma especialidade e admite
pacientes do sexo feminino ou masculino
(não há alas mistas). “O que”
[…]
“como”
“Quem”
0..*
Ala
nome
sexo
0..*
Tratamento
Data_inicio
Data_fim
nome
1..*
Doenca
nome
1
realiza
1
Especialidade
engloba
Paciente
sexo
atende
1..*
1
1..*
0..*
“O que”
1..*
Pertence a
trata
“como”
 Resumindo:
• As informações para construção do modelo
podem vir do minimundo ou das descrições de
caso de uso (mais comum);
• O modelo conceitual abstrai completamente
qualquer tipo de implementação, concentrandose apenas na representação lógica do negócio;
• Serve como estrutura fundamental para todo o
desenvolvimento do sistema.
 Ferramenta: Diagrama
de Classes da UML
 Existe em três níveis de abstração
• Análise
A
• Projeto
• Implementação
 Estrutural
 Representa as classes e suas
relações
 Estático  Não apresenta informações de
interações entre os objetos
 No
nível de análise, representamos
apenas as classes que tenham relação
com o domínio de problema, abstraindo
recursos e decisões de projeto ou
implementação;
 Por
esse motivo, também é conhecido
como diagrama de classes de domínio
 São
representados
classes de análise:
no
diagrama
• Classes;
 Atributos (sem os respectivos tipos de dado);
• Associações;
 Simples / agregações / composições
 Multiplicidades
 Adornos
• Generalizações/especializações
de
 Classes
• São abstrações que representam objetos com as
mesmas características e papéis dentro do SW;
• Pode possuir atributos e operações:
 Atributos  são as características do objeto, as
informações que conhecemos a seu respeito
 Operações  São os comportamentos que o objeto é
capaz de executar
 Classes

– Notação
Representada por um retângulo com um a três
compartimentos:
• Nome da classe
• Atributos
• Operações

Os nomes de classe devem ser sempre iniciados
com letras maiúsculas e devem estar no singular.
Exemplos:
• Livro
• Pedido
• ItemPedido
Classes
– Notação
 Os
atributos e operações devem iniciar
com letras minúsculas e, para cada nova
palavra no nome, a letra maiúscula deve
ser usada. Exemplos:
• numero
• dataRealizacao
• obterValorTotal()
Classes
– Notação
 As
operações sempre devem terminar
com parênteses, mesmo que nao haja
parâmetros. Exemplos:
• calcularValor()
• somar(a : int, b : int) : int
• adicionarFuncionario(func : Funcionario)
Classes
Nome da Classe
– Notação (exemplos)
Nome da Classe
Lista de atributos
Nome da Classe
Lista de operações
Nome da Classe
Lista de atributos
Lista de operações
Pedido
Pedido
numero
dataRealizacao
Pedido
obterValorTotal()
Pedido
numero
dataRealizacao
obterValorTotal()
 Associações
 Representam
a relação entre objetos de duas
ou mais classes;
 Essa
ligação só se concretizará (ou não)
durante a execução do sistema;
 Representada
no diagrama de classes por
uma linha ligando os elementos envolvidos.
 Associações
 Uma
Classe pode se associar com ela
própria. A esse fato damos o nome de
associação reflexiva;
 As
associações possuem atributos que
podemos utilizar para lhes dar maior
significado, legibilidade e clareza;
 Esses
atributos são colocados sobre ou sob a
linha que representa a associação
Associações
 São
atributos possíveis de uma
associação:
• Nome
• Direção de leitura
• Papel
• Multiplicidades
 Associações
 Nome
 dá legibilidade e significado à
associação;
 Direção
de leitura  indica para que lado se
lê o significado dado pelo nome da
associação;
 Papel
 indica o papel que determinado
objeto executa naquela associação. Pode ser
usado em substituição do nome.
Associações
 Multiplicidades
 representam as
quantidades mínima e máxima de objetos
com os quais o outro pode estar ligado.
Nome
Simbologia
Apenas um
1..1 ou 1
Zero ou muitos
0..* ou *
Um ou muitos
1..*
Zero ou um
0..1
Valores definidos
2..4 | 1..6
Associações
A
partir das multiplicidades extraímos dois
novos conceitos: conectividade e participação.
 Conectividade
 define a maneira como se dá a
associação entre as classes.
• Descoberta a partir do limite superior de cada um dos pares de
multiplicidade de uma determinada associação
Conectividade
Limites superiores da associação
Um para Um
1e1
Um para Muitos
1 e * (ou um número superior a 1)
Muitos para Muitos
* e * (ou dois números superiores a 1)
 Associações
 Participação
 indica a obrigatoriedade ou
não da existência da ligação entre os objetos
durante a execução do sistema.
• Descoberta a partir do limite inferior de cada um dos
pares de multiplicidade de uma determinada associação
A
participação de uma classe em uma
associação é descoberta no extremo oposto a
onde ela está
Associações
– Notação (exemplos)
nome da associção
Departamento
1
direção de leitura
aloca
0..*
Funcionario
multiplicidades
associação
Conectividade: um para muitos
Participação de Departamento: opcional
Participação de Funcionario: mandatória
Associações
Organização
– Notação (exemplos)
1..*
contrata
1..*
Indivíduo
É o mesmo que
Organização
- contratante
1..*
Indivíduo
- contratado
1..*
Conectividade: muitos para muitos
Participação de Organizacao: mandatória
Participação de Individuo: mandatória
papel
Associações
Corrida
1.. *
– Notação (exercício)
participa de
Conectividade? muitos para muitos
Participação de Corrida? opcional
Participação de Corredor? mandatória
0 .. *
Corredor
Associações
 Além
da associação simples (que vimos
até agora), existem dois tipos especiais de
associação:
• Agregação;
• Composição
Associações
 Agregação
e composição:
• São usadas para indicar uma semântica de todo-parte na
relação entre duas classes;
• Podem, em qualquer caso, ser substituídas por uma
associação simples;
• Seu uso é indicado quando for necessário enfatizar a
semântica da associação;
• Todos os adornos de uma associação simples podem ser
aplicados a elas.
Associações
 Agregação
x Composição:
• Agregação
 Neste tipo de associação, as partes podem ser criadas sem que
haja o todo;
 Uma mesma parte pode fazer parte de diversos todos;
 A destruição de um não implica na destruição do outro.
 Ex.: Um clube esportivo e seus sócios
Associações
 Agregação
x Composição:
• Composição
 Neste tipo de associação, há uma dependência entre as classes, de
tal forma que a parte não existe sem o todo;
 Os objetos parte são pertencentes a um único todo;
 Os objetos parte são criados e destruídos pelo objeto todo.
 Ex.: Uma venda e seus itens
Associações
 Agregação
x Composição:
• Notação
 Agregação e composição são representados no diagrama de
classes por um losango na extremidade todo;
 Na agregação o losango é aberto;
 Na composição o losango é fechado;
Associações
 Agregação
x Composição:
• Exemplo
Clube
0..*
Venda
Agregação
1..* - sócio proprietário
Socio
1
Composição
1..*
ItemVenda
Sempre é 1, por isso alguns autores omitem esta multiplicidade
Associações
 Agregação
x Composição:
• IMPORTANTE
 Pode-se construir hierarquias de associações desse tipo,
formando hierarquias todo-parte;
 Esse tipo de associação é transitivo.
Capitulo
1..*
Secao
1..*
Paragrafo

Associações n-árias

São associações que envolvem mais de duas classes
simultaneamente (n > 2);

O tipo mais comum – ou menos incomum – desse
tipo de associação é a associação ternária (n = 3);


São representadas por um losango que conecta as
linhas de associação de todas as classes que dela
participam;
Para determinar as multiplicidades de cada uma
das classes, devemos analisá-la no contexto da
associação com as demais classes participantes,
simultaneamente.

Associações n-árias
 Exemplo:
Profissional
1..*
*
Projeto
1..*
Empresa
Uma empresa contrata um profissional para trabalhar em um projeto específico.
• Se não houver projeto, não há a contratação;
• Se não houver profissionais disponíveis, não é possível realizar o projeto;
• Os profissionais só podem trabalhar no projeto se forem contratados por uma empresa.
 Classe

de Associação
Usada para armazenarmos características e
operações referentes a uma associação entre duas
classes;
• Ou seja, a informação não pertence a uma ou a outra classe da
associação, mas sim à união de ambas, ao par.
Também conhecida como classe associativa;
 Pode ser usada em associações com qualquer
conectividade;
 Pode ser usada em uma associação ternária.

Classe
de Associação
 Representada
no diagrama de classes por uma
linha tracejada ligando a classe à associação à
qual ela se refere;
Só fazem sentido se houver o
par, se houver a realização
da associação
Emprego
dtContratacao
salario
Pessoa
nome
telefone
Empresa
*
- empregado
* razaoSocial
- empregador CNPJ
Generalização/Especialização
 Relacionamento
entre classes do domínio que
representa generalidade ou especificidade
entre os envolvidos;
 Pode-se
dizer que uma classe é uma
especialização de outra quando ela adiciona
atributos, associações ou comportamentos a
esta;
 Diz-se
mais comumente que a classe específica
é uma extensão da classe mais genérica.
 Generalização/Especialização

Em suma, diz-se que A estende B quando A pode
ser visto como um subtipo de B e lhe adiciona novas
características (atributos, associações e/ou
operações);
• ContaPoupanca e ContaCorrente são subtipos de ContaBancaria


O nome mais comum que se dá a essa relação entre
classes é herança;
Na herança, atributos e operações que não sejam
privados na classe mais genérica são
automaticamente herdados nas classes mais
específicas.
Generalização/Especialização
 Benefício
do uso de herança  Reuso;
 Malefício
do uso de herança  Acoplamento;
É
necessário discernimento e bom senso no uso
de herança no processo de modelagem;
 Excesso
leva a acoplamentos exagerados.
 Generalização/Especialização
Representamos no diagrama de classes com uma
seta fechada e vazada que vai do mais específico
para o mais genérico;
 Não há limites para o número de classes envolvidas
em um relacionamento de herança;
 Pode-se criar hierarquias de classes em níveis, a
priori, infinitos;
 O relacionamento de herança é:

• Transitivo  As mais específicas herdam as características de
todos os seus ascendentes diretos na hierarquia;
• Assimétrico  Se A herda de B, B não pode herdar de A.
Generalização/Especialização
 Notação:
Superclasse
Superclasse
Subclasse1
Subclasse2
...
SubclasseN
Subclasse1
Subclasse2
...
SubclasseN
Generalização/Especialização
 Exemplo:
Generalização/Especialização
 Termos
comuns:
Genérico
Específico
Superclasse
Subclasse
Supertipo
Subtipo
Classe base
Classe herdeira
Ancestral
Descendente
Classe pai
Classe filha
Classe de generalização
Classe de especialização
Generalização/Especialização
É
possível adicionar restrições aos diversos
relacionamentos de herança:
• Sobreposta / Disjunta
• Completa / Incompleta
Generalização/Especialização
 Exemplo das restrições:
As subclasses
Há ainda
outras
subclasses
Não há mais
outras
subclasses
são mutuamente
exclusivas
Um nadador
pode ser
também um
corredor
Generalização/Especialização
É
importante não confundir papel de uma
classe em uma associação com herança!!;
Papel executado
pela classe...
ERRADO!!
CORRETO!!
Generalização/Especialização
 Uma
classe pode ter mais de um ancestral direto
ao mesmo tempo;
A
este fato damos o nome de herança múltipla;
A
maioria das linguagens OO não dão suporte à
herança múltipla;
 Deve-se
evitar seu uso, pois é um conceito
complicado de entender e implementar.
Generalização/Especialização
 Herança
múltipla (Exemplo):
VeiculoAereo
VeiculoAquatico
VeiculoAeroAquatico
Implementa comportamentos e guarda
características de ambos os tipos de veículo
Hidroavião é um exemplo disso
 Classes




Abstratas
São classes que aparecem no modelo apenas para
definir uma interface comum a uma determinada
hierarquia de classes;
Não podem ser instanciadas!!
Classes abstratas podem herdar de outras classe
abstrata, mas a hierarquia deve terminar em uma
classe concreta;
Classes concretas são aquelas que, ao contrário das
abstratas, são instanciáveis;
• Todas as que vimos até agora
Classes
Abstratas
 Usamos
classes abstratas para organizar uma
hierarquia de classes, concentrando nela os
atributos e comportamentos comuns às demais;
 Em
alguns casos as classes são qualificadas
como abstratas simplesmente por não fazer
sentido criar uma instância sua diretamente;
• Polígono, por exemplo
Classes
Abstratas (Exemplo)
Classe abstrata
(Representada com
o nome em itálico)
Pagamento
Dinheiro
Cartao
Classes concretas
Cheque