1. Diagrama de Classes
Conceitos básicos
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
2. Roteiro
• Casos de uso X AOO;
• Diagrama de classes:
– Identificação
– Criação
– Abstração
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
3. Análise Orientada a Objetos
• Descreve entidades no mundo real e suas interações.
• Na OO o analista precisa:
– Decompor o sistema em um conjunto de objetos que
interagem entre si.
Obs.: Todas as informações destes slides estão contidos em [1]
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
4. Análise Orientada a Objetos
• Identificando os Objetos: os objetos são
identificados conforme as entidades que existem em
um determinado domínio.
• Interação: por meio de troca de mensagens.
– Requisição de um serviço, ou
– Reação a uma outra mensagem.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
5. Porque utilizar a Análise Orientada a Objetos?
O mapeamento de conceitos em entidades (objetos), torna um
problema mais fácil de ser entendido.
– Ex.:
Entidades Objetos
Pratos GARÇON
# Matricula: Int;
+ Nome: String;
+ Telefone: String;
Garçons - Comissao: Real;
Conceitos: + ServeMesa(Cliente);
Restaurante
Clientes Aula baseada nos originais de Morais , Edison A. M.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
6. Porque utilizar a Análise Orientada a Objetos?
Ocultamento e abstração de informações.
– Ex.: GARÇON
# Matricula: Int;
+ Nome: String;
+ Telefone: String;
- Comissao: Real; Detalhes sobre
+ ServeMesa(Cliente); implementação podem (e
devem) ser ocultados
Deve-se abstrair somente
aquilo que é importante
no contexto.
Aula baseada nos originais de Morais , Edison A. M.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
7. UML – Diagrama de classes
Floribela Antoniolo
- Nome: Floribela - Nome: Antoniolo
- Sexo: feminino - Sexo: masculino
- Cor do cabelo: verde - Cor do cabelo: preto
- Cor da roupa: azul - Cor da roupa: verde e branca
- Cor da pele: amarela - Cor da pele: marrom
- Cor dos sapatos: vermelho - Cor dos sapatos: azul
- Altura: 6cm - Altura: 5,5cm
- Humor: assustada - Humor: feliz
Aula baseada nos originais de Mateus Raeder – fevereiro de 2009
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
8. UML – Diagrama de classes
Uma classe, então, vai representar o conjunto de objetos que
possuem determinadas características em comum
Ao definir uma classe, então, devemos definir dois pontos
principais:
1 – atributos, que são informações da classe (cor do
cabelo, sexo, altura, etc...)
2 – métodos, que são as ações que podem ser
realizadas pelos objetos de cada classe
(andar, correr, falar, pensar, etc...)
Aula baseada nos originais de Mateus Raeder – fevereiro de 2009
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
9. UML – Diagrama de classes
Classe Pessoa Objeto Floribela Objeto Antoniolo
Floribela e Antoniolo
são instâncias da classe Pessoa
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
10. UML – Diagrama de classes
Pessoa Nome da classe
nome
sexo
cor_cabelo
cor_roupa
Atributos da classe
cor_pele
cor_sapato
altura
humor
falar
correr Métodos da classe
andar
pensar
Aula baseada nos originais de Mateus Raeder – fevereiro de 2009
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
11. UML – Diagrama de classes
Nome da classe Pessoa
-nome: String
-sexo: char
-cor_cabelo: String
+cor_roupa: String
visibilidade atributo: tipo -cor_pele: String
+cor_sapato: String
-altura: double
+humor: String
+falar(): String
+correr(): int
visibilidade método: retorno +andar(): int
+pensar()
Visibilidade:
- : privado (visível somente dentro da classe)
+ : público (visível por qualquer classe)
# : protegido Aula baseada nos originais de Mateus Raeder – fevereiro de 2009
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
12. Diagrama de Classes
• Descreve
– Classes de objetos do sistema
– Relacionamentos estáticos que existem entre elas
• Associações (ex. Um cliente pode alugar vários filmes)
• Subtipos (Generalização) - ( ex. Uma enfermeira é do tipo pessoa )
Elementos
Básicos
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
13. Diagrama de Classes
• Conceitos Avançados
– Estereótipos
– Diagramas de Objetos
– Operações e Atributos com escopo de Classe
– Classificação Múltiplica e Dinâmica
– Agregação e Composição
– Associações e Atributos Derivados
– Interfaces e Classes Abstratas
– Objetos de Referência e Objetos de Valor
– Coleções e Frozen
– Classificação e Generalização
– Associações Qualificadas
– Classes de Associações e Classes Parametrizadas
– Visibilidade
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
14. Perspectivas dos Diagramas de Classes
• Conceitual ou de domínio
• Especificação
• Implementação
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
15. Conceitual ou de domínio
• Representa os conceitos do domínio;
• Destinada ao cliente;
• Conceitos do domínio – considerado independente de
implementação (da linguagem);
• Construído na fase de análise;
• Nesta fase deve ser dado pouco ou nenhum enfoque ao
software.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
16. Conceitual
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
17. Modelagem de Classes de Domínio (conceitual)
• O processo de criação:
– Passo 1: Identificação das classes conceituais de domínio;
– Passo 2: Identificação das associações relevantes entre as
classes.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
18. Modelo de Domínio - (conceitual)
• Para identificar as classes, o analista deve investigar:
• Relatórios;
• Documentos;
• Textos;
• Outros softwares relacionados;
• Qualquer outro artefato que faça parte do domínio do problema.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
19. Modelagem de Classes de Domínio
• Para criar o modelo de domínio:
– Crie um lista de categorias de classes.
– Ex.:
No modelo de
domínio pode-se
definir um
vocabulário
comum sobre os
componentes do
sistema
Fonte: Morais , Edison A. M.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
20. Modelagem de Classes de Domínio (conceitual)
• Como criar o modelo de domínio:
– Identifique substantivos a partir dos requisitos.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
21. Modelo de Domínio (conceitual)
• Diretrizes importantes
– 1. Use nome no singular para as classes conceituais.
– 2. Use um nome que identifique um único objeto ao
invés de uma coleção deles (categorias).
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
22. Modelo de Domínio (conceitual)
• Ex.:
– Uma instância de funcionário, ex. Márcia
Rabello, trabalha para empresa, por exemplo IMED.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
23. Especificação
• Foca nas principais interfaces da arquitetura;
• Principais métodos, mas não de sua implementação;
• Definir a navegabilidade entre as classes;
• Destinado as pessoas que não necessitam dos detalhes do
desenvolvimento (gerente de projetos por exemplo)
• Neste nível novas classes podem ser definidas para a solução do
problema;
• É definido na fase de projeto;
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
24. Especificação
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
25. Implementação
• Aborda detalhes da implementação:
– Navegabilidade;
– Atributos;
– Tipos;
– Métodos, etc.
• Construído na fase de implementação;
• Voltado para a equipe de desenvolvimento;
• Segundo Martin Fowler, esta é utilizada com freqüência, porém a
perspectiva de especificação é freqüentemente a melhor para ser usada.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
26. Implementação
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
27. Nomenclaturas
• A equipe pode utilizar qualquer tipo de
nomenclatura, porém uma vez escolhida esta
deve ser seguida.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
28. Nomenclaturas
• Identificadores: espaços em branco serão removidos.
• Nomes das classes e relacionamentos: começam com letras
maiúsculas. Ex. Cliente, ItemPedido, Pedido, Realiza, Reside, etc.
• Nome de atributos e operações: escrever a primeira palavra do
nome do atributo em minúscula e as palavras subseqüentes em
maiúsculas. Ex. quantidade, precoUnitario, CPF, nome,
dataNascimento, obterTotal, etc.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
29. Notações
Classe A Classe B
1 1,*
• Classe Nome Atributos Atributos
Atributos Operações Operações
Operações Associação
• Relacionamento
A Tipo 1 A Tipo 2
• Relacionamento
Atributos Atributos
Generalização
Operações Operações
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
30. Exemplo - Reservas
• Classes de Objetos (Algumas delas)
– Cliente
– Vôo
– Categoria Vôo
– Reservas
– Compra
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
31. Exemplo – Reservas
Perspectiva conceitual
Voo
Cliente Reserva Numero
horaSaida
Nome 1 Data 1 horaChegada
Fone * Horario
* tempoVoo
Email AeroportoSaida
AeroportoChegada
*
*
*
Cli Fidelid 1
Compra Categoria
Data Nome
Horario Equivalência
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
32. Exercício
• Crie o diagrama de classes para o Sistema de
Compra pela Internet ou conta de luz .
– Use a perspectiva conceitual
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
33. Exemplo – Reservas
Perspectiva de especificação
Voo
Cliente Reserva Numero
horaSaida
Nome 1 Data 1 horaChegada
Fone * Horario
* tempoVoo
Email AeroportoSaida
total():Numeric AeroportoChegada
categCliente():String
horaChegada():Time
* tempoAtraso():Minutes
*
Navegabilidade
*
Cli Fidelid 1
cqtdMilhas():Integer Compra Categoria
Data Nome
Horario Equivalência
listarEquiv(): List
Mais modelos tipoPgto():Int
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
34. Exemplo – Reservas
Perspectiva de implementação
Reserva Voo
Cliente * Data * Numero
horaSaida
Horario
Nome 1 1 horaChegada
cliente: Cliente
Fone tempoVoo
voo: Voo
Email AeroportoSaida
numero: Compra
AeroportoChegada
categCliente():String
total():Numeric horaChegada():Time
tempoAtraso():Minutes
*
*
*
Cli Fidelid 1
cqtdMilhas():Integer Compra Categoria
Data Nome
Horario Equivalência
listarEquiv(): List
tipoPgto():Int
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
35. Exemplo – Reservas
Perspectiva de implementação
• Exemplo da implementação da Classe Reserva em java:
class Reserva{
private Cliente cliente;
private Voo voo;
private Compra numero;
}
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
36. Exercício
• Crie o diagrama de classes para o Sistema de Compra
pela Internet ou conta de luz.
– Use a perspectiva de especificação
– Crie as classes em PHP5, ou java.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
37. Exemplo – Reservas: Regras de Restrição
Voo
Cliente Reserva Numero
horaSaida
Nome 1 Data 1 horaChegada
Fone * Horario
* tempoVoo
Email AeroportoSaida
AeroportoChegada
total():Numeric
categCliente():String
horaChegada():Time
*
{se tempoAtraso():Minutes
Reserva.cliente.categCliente *
<> Fidelidade
Então prePago = sim}
*
Cli Fidelid 1
cqtdMilhas():Integer Compra Categoria
Data Nome
Horario Equivalência
listarEquiv(): List
tipoPgto():Int
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
38. Exercício
• Crie, no mínimo, duas regras de
restrições, em classes diferentes.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
39. Agregação e Composição
• Agregação
– Relacionamento “parte de”
– “A parte pode viver sem o todo”
• Composição
– Relacionamento “composição de”
– “A composição não vive sem o todo”
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
40. Agregação e Composição
• Exemplo
Dependentes é parte de pessoa
Pessoa 1
Emprego
Dependentes * 1 Nome * Nome
Fone Area
Nome
Data de nascimento Email Salário
listaEmprego():String calculaBonus():String
Composição
Agregação
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
41. Agregação vs Composição vs Associação
Pessoa Emprego
* Nome * 1 Nome Associação?
Fone Area
Email Salário
listaEmprego():String calculaBonus():String
Pessoa 1
Emprego
* Nome
Fone
* Nome
Area
Composição?
Email Salário
listaEmprego():String calculaBonus():String
Pessoa 1
Emprego
* Nome * Nome
Fone
Email
Area
Salário
Agregação?
listaEmprego():String calculaBonus():String
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
42. Agregação vs Composição vs Associação
• Dica de perguntas:
1. Se deletar PESSOA, tem que deletar EMPREGO/TRABALHO?
• se a resposta for Sim é = composição
• Não = pode ser agregação ou nada...
2. TRABALHO/EMPREGO tem alguma utilidade SOZINHO ?
• Sim = associação comum
• Não = agregação
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
43. Corrigindo o diagrama das Reservas
Voo
Cliente * Reserva
Numero
Nome
* horaSaida
1 Data 1 horaChegada
Fone Horario tempoVoo
Email AeroportoSaida
AeroportoChegada
total():Numeric
categCliente():String
horaChegada():Time
* tempoAtraso():Minutes
*
*
Cli Fidelid 1
cqtdMilhas():Integer Compra Categoria
Data Nome
Horario Equivalência
listarEquiv(): List
tipoPgto():Int
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
44. Exercício
• Considerando os conceitos de agregação, composição
e associação, corrija o seu diagrama de classes.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br
45. Referências
• Dorneles, Carina F. UML Unified Modeling Language : Conceitos básicos. Passo Fundo, 2008.
• UML Essencial: um breve guia para a linguagem-padrão de modelagem de objetos. Martin
Fowler e Kendall Scott. 2.ed. Bookman: Porto Alegre, 2000
• The Unified Modeling Language User Guide. Grady Booch, James Rumbaugh e Ivar
Jacobson. Addison-Wesley, 1999.
• Morais , Edison A. M. Engenharia de requisitos – Orientação a objetos. 2006.
• Nogueira, F. Criação de Modelos de Domínio: Identificando Classes e Associações.
• Raeder, Mateus. UML - Diagrama de classes. unisinos, 2009.
Disciplina: Análise e Projeto de Sistemas I
Email para contato: marcia@imed.edu.br