Aula diagrama de classes
-
Upload
marcia-rodrigues -
Category
Documents
-
view
9.111 -
download
2
Transcript of Aula diagrama de classes
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Diagrama de ClassesConceitos básicos
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Roteiro
• Casos de uso X AOO;
• Diagrama de classes:
– Identificação
– Criação
– Abstração
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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.:
Conceitos:
Restaurante
Pratos
Garçons
Clientes
GARÇON
Entidades Objetos
# Matricula: Int;+ Nome: String;+ Telefone: String;- Comissao: Real;
+ ServeMesa(Cliente);
Aula baseada nos originais de Morais , Edison A. M.
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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;
+ ServeMesa(Cliente);
Detalhes sobre 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 IEmail para contato: [email protected]
UML – Diagrama de classesFloribela
- Nome: Floribela- Sexo: feminino- Cor do cabelo: verde- Cor da roupa: azul- Cor da pele: amarela- Cor dos sapatos: vermelho- Altura: 6cm- Humor: assustada
- Nome: Antoniolo- Sexo: masculino- Cor do cabelo: preto- Cor da roupa: verde e branca- Cor da pele: marrom- Cor dos sapatos: azul- Altura: 5,5cm- Humor: feliz
Antoniolo
Aula baseada nos originais de Mateus Raeder – fevereiro de 2009
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
UML – Diagrama de classes
Objeto Floribela Objeto AntonioloClasse Pessoa
Floribela e Antoniolo são instâncias da classe Pessoa
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
UML – Diagrama de classes
nomesexocor_cabelocor_roupacor_pelecor_sapatoalturahumor
Pessoa
falarcorrerandarpensar
Atributos da classe
Métodos da classe
Nome da classe
Aula baseada nos originais de Mateus Raeder – fevereiro de 2009
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
UML – Diagrama de classes
visibilidade atributo: tipo
visibilidade método: retorno
Nome da classe-nome: String-sexo: char-cor_cabelo: String+cor_roupa: String-cor_pele: String+cor_sapato: String-altura: double+humor: String
Pessoa
+falar(): String+correr(): int+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 IEmail para contato: [email protected]
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 )
ElementosBásicos
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
Perspectivas dos Diagramas de Classes
• Conceitual ou de domínio
• Especificação
• Implementação
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
Modelagem de Classes de Domínio
• Para criar o modelo de domínio:
– Crie um lista de categorias de classes.
– Ex.:
Fonte: Morais , Edison A. M.
No modelo de domínio pode-se
definir um vocabulário
comum sobre os componentes do
sistema
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
Notações
• Classe
• Relacionamento
• Relacionamento
Nome
Atributos
Operações
Classe A
Atributos
Operações
Classe B
Atributos
Operações
A Tipo 1
Atributos
Operações
A Tipo 2
Atributos
Operações
Associação
Generalização
1 1,*
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Exemplo - Reservas
• Classes de Objetos (Algumas delas)
– Cliente
– Vôo
– Categoria Vôo
– Reservas
– Compra
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Exemplo – ReservasPerspectiva conceitual
ClienteNomeFoneEmail
Cli Fidelid CategoriaNomeEquivalência
VooNumerohoraSaidahoraChegadatempoVooAeroportoSaidaAeroportoChegada
*
*
ReservaDataHorario
* 11 *
CompraDataHorario
1
*
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
Exemplo – ReservasPerspectiva de especificação
ClienteNomeFoneEmail
categCliente():String
Cli FidelidcqtdMilhas():Integer
CategoriaNomeEquivalência
listarEquiv(): List
VooNumerohoraSaidahoraChegadatempoVooAeroportoSaidaAeroportoChegada
horaChegada():Time tempoAtraso():Minutes
*
*
ReservaDataHorario
total():Numeric
* 11 *
CompraDataHorario
tipoPgto():Int
1
*
Navegabilidade
Mais modelos
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Exemplo – ReservasPerspectiva de implementação
ClienteNomeFoneEmail
categCliente():String
Cli FidelidcqtdMilhas():Integer
CategoriaNomeEquivalência
listarEquiv(): List
VooNumerohoraSaidahoraChegadatempoVooAeroportoSaidaAeroportoChegada
horaChegada():Time tempoAtraso():Minutes
*
*
ReservaDataHorariocliente: Clientevoo: Voonumero: Compra
total():Numeric
*11
*
CompraDataHorario
tipoPgto():Int
1
*
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
• Exemplo da implementação da Classe Reserva em java:
class Reserva{
private Cliente cliente;
private Voo voo;
private Compra numero;
}
Exemplo – ReservasPerspectiva de implementação
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
Exemplo – Reservas: Regras de Restrição
ClienteNomeFoneEmail
categCliente():String
Cli FidelidcqtdMilhas():Integer
CategoriaNomeEquivalência
listarEquiv(): List
VooNumerohoraSaidahoraChegadatempoVooAeroportoSaidaAeroportoChegada
horaChegada():Time tempoAtraso():Minutes
*
*
ReservaDataHorario
total():Numeric
* 11 *
CompraDataHorario
tipoPgto():Int
1
*{se Reserva.cliente.categCliente <> Fidelidade Então prePago = sim}
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Exercício
• Crie, no mínimo, duas regras de restrições,
em classes diferentes.
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
Agregação e Composição
• Exemplo
PessoaNomeFoneEmail
listaEmprego():String
EmpregoNomeAreaSalário
calculaBonus():String
Dependentes
NomeData de nascimento
* 1 * 1
ComposiçãoAgregação
Dependentes é parte de pessoa
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Agregação vs Composição vs Associação
PessoaNomeFoneEmail
listaEmprego():String
EmpregoNomeAreaSalário
calculaBonus():String
* * 1
PessoaNomeFoneEmail
listaEmprego():String
EmpregoNomeAreaSalário
calculaBonus():String
* * 1
PessoaNomeFoneEmail
listaEmprego():String
EmpregoNomeAreaSalário
calculaBonus():String
* * 1
Associação?
Composição?
Agregação?
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
• 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
Agregação vs Composição vs Associação
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
Corrigindo o diagrama das Reservas
ClienteNomeFoneEmail
categCliente():String
Cli FidelidcqtdMilhas():Integer
CategoriaNomeEquivalência
listarEquiv(): List
VooNumerohoraSaidahoraChegadatempoVooAeroportoSaidaAeroportoChegada
horaChegada():Time tempoAtraso():Minutes
*
*
ReservaDataHorario
total():Numeric
*11
*
CompraDataHorario
tipoPgto():Int
1
*
Disciplina: Análise e Projeto de Sistemas IEmail para contato: [email protected]
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 IEmail para contato: [email protected]
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.