POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2)

1,656 views

Published on

Material utilizado na disciplina de Programação Orientada a Objetos (animações e outros efeitos foram perdidos no carregamento). Ciência da Computação (3o período). Universidade do Vale do Itajaí - Campus Kobrasol.

Published in: Education

POO - Unidade 2 (parte 1) - Diagrama de Classe - Associação (versão 2)

  1. 1. Prof. Marcello Thiry <marcello.thiry@gmail.com> PROGRAMAÇÃO ORIENTADA A OBJETOS Unidade 2 (parte 1) 3º período
  2. 2. marcello.thiry@gmail.com 2
  3. 3. marcello.thiry@gmail.com UML 3  Linguagem de Modelagem Unificada  Padrão OMG (Object Management Group) desde 1997  http://www.uml.org/  http://www.omg.org/spec/UML/2.5/Beta2/PDF/
  4. 4. marcello.thiry@gmail.com Diagramas UML 4  14 diagramas  7 diagramas estruturais  Visão estática  7 diagramas comportamentais  Visão dinâmica
  5. 5. marcello.thiry@gmail.com 5 UML 2.5 (beta 2), pg. 718
  6. 6. marcello.thiry@gmail.com Diagramas UML 6  14 diagramas  Mas, iremos trabalhar nesta disciplina com apenas 2 diagramas
  7. 7. marcello.thiry@gmail.com 7 Visão estática Visão dinâmica
  8. 8. marcello.thiry@gmail.com Diagrama de classe  Descreve a estrutura de um sistema  Um diagrama de classe permite visualizar:  classes do sistema, seus atributos e operações  relacionamentos entre as classes  relacionamentos entre classes e interfaces 8
  9. 9. marcello.thiry@gmail.com Principais relacionamentos  Generalização / Especialização (herança)  Associação  Agregação e Composição 9 Já trabalhamos com herança na Unidade 1
  10. 10. marcello.thiry@gmail.com Associação  Relação entre ocorrências (objetos) das classes  Indica que objetos “Professor” estarão associados com objetos “Aluno” 10
  11. 11. marcello.thiry@gmail.com 11 Professores Alunos marcello alessandro fabiane anita joao maria pedro jose objetos com objetos
  12. 12. marcello.thiry@gmail.com Associação  Mas, qual é a relação entre Professor e Aluno? 12
  13. 13. marcello.thiry@gmail.com Associação 13
  14. 14. marcello.thiry@gmail.com 14 Nome da associação (indica a semântica da conexão entre os objetos)
  15. 15. marcello.thiry@gmail.com 15 Note que a semântica é diferente nas duas associações
  16. 16. marcello.thiry@gmail.com 16 O nome da associação deve sempre ser uma frase verbal
  17. 17. marcello.thiry@gmail.com A semântica aqui é diferente? São mesmo duas associações diferentes?
  18. 18. marcello.thiry@gmail.com Se a semântica é a mesma, então é a mesma associação
  19. 19. marcello.thiry@gmail.com 19 Mas, como devemos ler a associação?  quem orienta quem?  quem coordena quem?
  20. 20. marcello.thiry@gmail.com 20Sem conhecer o negócio, a leitura destas associações é ambígua!
  21. 21. marcello.thiry@gmail.com E agora? Facilitou o entendimento?
  22. 22. marcello.thiry@gmail.com Indica a direção da associação (orienta a leitura)
  23. 23. marcello.thiry@gmail.com Lado da associação (uma associação possui dois lados)
  24. 24. marcello.thiry@gmail.com Lado da associação (uma associação possui dois lados)
  25. 25. marcello.thiry@gmail.com Professor “orienta” Aluno Professor “coordena” Aluno
  26. 26. marcello.thiry@gmail.com Mas, um professor pode orientar quantos alunos?
  27. 27. marcello.thiry@gmail.com UM professor orienta VÁRIOS alunos VÁRIOS = = 0, 1 ou mais *
  28. 28. marcello.thiry@gmail.com UM aluno é orientado por UM professor Mas, Regras de negócio: Todo e qualquer aluno precisa ter um orientador Nem todo professor precisa orientar um aluno
  29. 29. marcello.thiry@gmail.com UM professor coordena VÁRIOS alunos UM aluno é coordenado por UM professor Pegou a ideia?
  30. 30. marcello.thiry@gmail.com Multiplicidade  Define quantos objetos participam em um relacionamento  O número de objetos de uma classe relacionada a UM objeto da outra classe  Deve ser especificada em cada lado da associação 30
  31. 31. marcello.thiry@gmail.com Multiplicidade x Cardinalidade  Cardinalidade  Número de elementos em um conjunto  Multiplicidade  A especificação do intervalo de valores de cardinalidade permitidas – o tamanho – que um conjunto pode assumir 31 (Booch, Rumbaugh e Jacobson, 1999)
  32. 32. marcello.thiry@gmail.com Indicadores de multiplicidade 32 Vários/Muitos/Zero, um ou mais: Um ou mais: Zero ou um: Exatamente um: Exatamente três: Faixa especificada: Múltiplas faixas: * *1.. 0..1 1 3 2..4 2..4, 6..8
  33. 33. marcello.thiry@gmail.com Veja se você consegue ler....
  34. 34. marcello.thiry@gmail.com 34 Professores Alunos marcello alessandro fabiane anita joao maria pedro jose 1 para 1
  35. 35. marcello.thiry@gmail.com 35 Professores Alunos marcello alessandro fabiane anita joao maria pedro jose 1 para *
  36. 36. marcello.thiry@gmail.com 36 Professores Alunos marcello alessandro fabiane anita joao maria pedro jose para **
  37. 37. marcello.thiry@gmail.com 1 1
  38. 38. marcello.thiry@gmail.com 1 1 Um objeto Professor aponta para um objeto Aluno O objeto Professor precisa de um ponteiro (objeto)
  39. 39. marcello.thiry@gmail.com 1 1 A classe Aluno é independente da classe Professor A classe Professor depende da classe Aluno
  40. 40. marcello.thiry@gmail.com 0..1 * Agora, as regras de negócio espelham melhor a realidade:  Nem todo professor precisa ter um orientando ( = 0, 1 ou +)  Um professor pode ter vários orientandos ( = 0, 1 ou +)  Um aluno pode ter ou não um professor orientador, mas nunca mais do que um orientador (0..1) * *
  41. 41. marcello.thiry@gmail.com Alguma ideia para tratar este lado da associação? Como um objeto Professor poderá apontar para vários objetos Aluno?
  42. 42. marcello.thiry@gmail.com 0..1 *
  43. 43. marcello.thiry@gmail.com *0..1
  44. 44. marcello.thiry@gmail.com * O que você acha? Faz mais sentido? 0..1
  45. 45. marcello.thiry@gmail.com Navegabilidade 45 Unidirecional Bidirecional Indefinida
  46. 46. marcello.thiry@gmail.com Navegabilidade  Os dados podem fluir em uma ou em ambas as direções através da associação  Canal de comunicação pelo qual, os objetos conversam entre si (trocam mensagens)  Uma mensagem pode ser uma requisição por informação ou uma requisição para executar uma ação  Uma mensagem é trocada quando um objeto “chamador” invoca uma operação de um objeto “receptor” 46
  47. 47. marcello.thiry@gmail.com 47 Se utilizarmos uma associação bidirecional no nosso exemplo, o nome da associação valerá apenas para uma das direções!
  48. 48. marcello.thiry@gmail.com 48 Mas, quando pensamos na implementação, precisamos considerar um atributo para cada lado, certo?! Papel (role) assumido pelos objetos Aluno nesta associação Papel (role) assumido pelo objeto Professor nesta associação
  49. 49. marcello.thiry@gmail.com Nomeando uma associação com nomes de papel (role names) Note que, se utilizarmos nomes de papel, é uma boa prática evitar o nome da associação (poderia deixar o diagrama “poluído”)
  50. 50. marcello.thiry@gmail.com Implementando a partir dos nomes dos papéis interpretados pelas classes Papel do Professor Papel do Aluno
  51. 51. marcello.thiry@gmail.com Nomeando uma associação com nomes de papel (role names) Você notou o sinal?
  52. 52. marcello.thiry@gmail.com Nomeando uma associação com nomes de papel (role names) Representa o modificador de visibilidade “privado”
  53. 53. marcello.thiry@gmail.com Tudo ok com esta representação? O que deveríamos interpretar?
  54. 54. marcello.thiry@gmail.com Haveria duplicação de atributos com o mesmo nome! Se você utilizou uma associação, não coloque sua implementação nas classes do diagrama
  55. 55. marcello.thiry@gmail.com Mas, qual é o problema que temos quando a associação é bidirecional?
  56. 56. marcello.thiry@gmail.com Vamos considerar um cenário, onde temos um Professor chamado “marcello” que orienta dois Alunos chamados “joao” e “pedro” Vamos criar primeiro o objeto Professor: Professor marcello = new Professor (“Marcello”); Observe que se Professor fosse obrigado a ter um orientando, teríamos uma situação inconsistente Poderíamos criar o objeto Aluno antes e repassá-lo ao Professor no momento da instanciação Mas, se um Aluno também tivesse que ter obrigatoriamente um orientador?
  57. 57. marcello.thiry@gmail.com joao.setOrientador(marcello); pedro.setOrientador(marcello); Cenário onde temos um objeto Professor chamado “marcello” e dois objetos Aluno chamados “joao” e “pedro”: Como seria a implementação da operação “setOrientador”?
  58. 58. marcello.thiry@gmail.com
  59. 59. marcello.thiry@gmail.com Se houver um orientador, então precisamos sincronizar antes... E garantir que o novo orientador também conhecerá o novo orientando Operação “Atômica” (indivisível)
  60. 60. marcello.thiry@gmail.com Outra forma, caso não seja implementada a operação “delOrientando” na classe Professor Retornaria a lista de orientandos ArrayList<Aluno>
  61. 61. marcello.thiry@gmail.com Lembre-se: Semânticas diferentes, associações diferentes!
  62. 62. marcello.thiry@gmail.com
  63. 63. marcello.thiry@gmail.com Você precisa garantir as regras:  Um aluno não pode ficar sem coordenador  Um coordenador precisa ter, pelo menos, um aluno  ...
  64. 64. marcello.thiry@gmail.com Para considerar:  Associações bidirecionais...  ... aumentam o acoplamento (dependência entre classes), reduzindo a reusabilidade  ... aumentam a complexidade da implementação, pois exigem que o sincronismo seja mantido nos dois lados da associação  ... quando definidas como vários para vários, aumentam ainda mais a complexidade da implementação
  65. 65. marcello.thiry@gmail.com 65 Para exercitar! Modele um diagrama UML a partir dos seguintes conceitos: Aluno, Professor, Turma, Disciplina, Curso Pense na sua realidade dentro da universidade
  66. 66. marcello.thiry@gmail.com Referências 66  Grady Booch, James Rumbaugh, and Ivar Jacobson. The Unified Modeling Language User Guide. 2nd ed. Addison-Wesley, 2005.  Ricardo Pereira e Silva. UML 2 em Modelagem Orientada a Objetos. Visual Books, 2007.  OMG (Object Management Group), OMG Unified Modeling Language v2.5, 2013.  http://www.omg.org/spec/UML/2.5/Beta2/PDF/
  67. 67. marcello.thiry@gmail.com marcello.thiry@gmail.com

×