Aula diagrama de classes

  • 7,758 views
Uploaded on

 

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
7,758
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
233
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Diagrama de Classes Conceitos básicosDisciplina: Análise e Projeto de Sistemas IEmail 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: felizAula 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 classesClasse 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 pensarAula 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: Stringvisibilidade atributo: tipo -cor_pele: String +cor_sapato: String -altura: double +humor: String +falar(): String +correr(): intvisibilidade 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 VooCliente Reserva Numero horaSaidaNome 1 Data 1 horaChegadaFone * Horario * tempoVooEmail 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 VooCliente Reserva Numero horaSaidaNome 1 Data 1 horaChegadaFone * Horario * tempoVooEmail AeroportoSaida total():Numeric AeroportoChegadacategCliente():String horaChegada():Time * tempoAtraso():Minutes * Navegabilidade *Cli Fidelid 1cqtdMilhas():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 VooCliente * Data * Numero horaSaida HorarioNome 1 1 horaChegada cliente: ClienteFone tempoVoo voo: VooEmail AeroportoSaida numero: Compra AeroportoChegadacategCliente():String total():Numeric horaChegada():Time tempoAtraso():Minutes * * *Cli Fidelid 1cqtdMilhas():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 EmpregoDependentes * 1 Nome * Nome Fone AreaNomeData 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