Engenharia de Software. Prof. Me. Clodoaldo Brasilino

Transcrição

1 Engenharia de Software Prof. Me. Clodoaldo Brasilino

2 Acompanhamento da Disciplina 1. Introdução à Engenharia de Software 2. Processos de Software e Projetos 3. Metodologia Ágil 4. UML 5. Git - Gerência de Configuração 2

3 Conteúdo da Aula Diagrama de Classes Estrutura e composição Multiplicidade Interpretação em programas Associações bidirecionais Operações Generalização Notas e comentários Dependência Dicas de utilização 3

4 Diagramas de Classes

5 Diagramas de Classes O diagrama de Classes é um diagrama estrutural Descreve: Os tipos de objetos presentes no sistema Os tipos de relacionamento estáticos Características: Propriedades Operações Restrições 5

6

7 Estrutura e Composição Propriedades: Representam as características estruturais de uma classe Dividem-se em: Atributo Associação 7

8 Estrutura e Composição Atributo: linha de texto na caixa no seguinte formato: visibilidade nome: tipo multiplicidade = valor_padrão {restrições} visibilidade: público (+) privado (-) pacote (~) protegido (#) 8

9 Estrutura e Composição Atributo: linha de texto na caixa no seguinte formato: visibilidade nome: tipo multiplicidade = valor_padrão {restrições} nome: nome do atributo tipo: restrição sobre o tipo de objeto multiplicidade: veremos em breve 9

10 Estrutura e Composição Atributo: linha de texto na caixa no seguinte formato: visibilidade nome: tipo multiplicidade = valor_padrão {restrições} valor_padrão: valor atribuído, caso não se tenha definido algum em sua criação restrições: restrições e propriedades que podem ser definidas ao tipo 10

11 Estrutura e Composição Associação: Linha cheia entre duas classes, direcionada da classe de origem para a de destino O nome da propriedade fica no destino O destino vincula à classe que é o tipo da propriedade Pode apresentar multiplicidades 11

12 Estrutura e Composição Quando devo usar associação ou atributo? 12

13

14 Multiplicidade A multiplicidade indica quantos objetos podem/devem preencher um objeto; As mais comuns são: 1 - deve ter exatamente pode ou não ter um único * - pode ter nenhum, um ou vários 14

15 Multiplicidade 15

16 Multiplicidade Geralmente são definidas com limite inferior e superior Limite inferior: qualquer número natural (>=0) Limite superior: qualquer número positivo (>0) ou * para ilimitado Termos referentes à multiplicidade: Opcional: limite inferior = 0 Obrigatório: limite inferior > 0 Valor único: limite superior = 1 Valores múltiplos: limite superior > 1 (em geral, *) 16

17 Multiplicidade Quando uma propriedade tem valores múltiplos, em geral usamos plural no nome dela Valores múltiplos assumem a forma de conjunto, logo podem-se aplicar restrições como: {ordered} - ordenado {unordered} - desordenado {unique} - objetos distintos apenas {nonunique} - objetos iguais permitidos {bag} - desordenado, iguais permitidos 17

18 Interpretação em programas Não existe uma maneira única de interpretar propriedades no código Analisem a propriedade preço a seguir 18

19

20 Interpretação em programas 20

21 Associações bidirecionais Até agora vimos associações unidirecionais Podemos ter associações bidirecionais, como a descrita abaixo: 21

22 Associações bidirecionais No caso, a classe Carro tem a propriedade proprietário: Pessoa[1] E a classe Pessoa tem a propriedade carros: Carro[*] 22

23 Associações bidirecionais Podemos não definir a navegabilidade também, através da representação abaixo Nesta representação, não importa a navegabilidade (unidirecional para um sentido ou outro, ou bidirecional) 23

24 Dica para o programador Associações bidirecionais Cuidado com as associações bidirecionais! 24

25 Dica para o programador Associações bidirecionais Devemos atualizar ambos os lados sempre! 25

26 Operações São as ações que uma classe sabe realizar Correspondem diretamente aos métodos Em geral, as operações que apenas manipulam propriedades (encapsulamento) são omitidas 26

27 Operações A sintaxe das operações UML é: visibilidade nome (lista-de-parâmetros) : tiporetorno {restrições} visibilidade: público (+) privado (-) pacote (~) protegido (#) 27

28 Operações A sintaxe das operações UML é: visibilidade nome (lista-de-parâmetros) : tiporetorno {restrições} nome: nome da operação lista-de-parâmetros: lista de parâmetros tipo-retorno: tipo do dado retornado, caso haja algum restrições: restrições e propriedades que podem ser definidas à operação 28

29 Operações Dica para o programador A lista-de-parâmetros é escrita da seguinte forma: direção nome: tipo = valor_padrão direção: pode ser de entrada (in), saída (out) ou entrada e saída (inout) Em Java, todos os parâmetros são inout nome: nome do parâmetro tipo: restrição sobre o tipo de objeto valor_padrão: valor atribuído, caso não se tenha definido algum em sua chamada 29

30 Operações Alguns conceitos da UML sobre operações: Consulta - operação que não modifica o estado do sistema: restrição {query} Modificadores ou comandos - operações que alteram o estado do sistema Método de leitura - retorna o valor de um campo apenas Método de modificação - coloca um valor em um campo apenas 30

31 Operações Alguns conceitos da UML sobre operações: Operação - algo que é chamado em um objeto (a declaração de um método/ função) Método - é o corpo de um procedimento/ função 31

32 Generalização É a visão na UML da herança nas linguagens orientadas a objetos Envolve a separação de tipos específicos e gerais de um certo grupo de tipos 32

33 Generalização Exemplo clássico: Pessoa 33

34 Notas e comentários Podem aparecer isolados ou vinculados através de uma linha tracejada 34

35 Dependência Uma dependência entre dois elementos existe quando mudanças na definição de um elemento afeta outro Identificar dependências é um fator muito importante em sistemas que tomam grandes proporções Quanto maior for a propagação das dependências, mais difícil/custoso será modificar 35

36 Dependência 36

37 Dependência Muitos relacionamentos apresentam dependência, não apenas o relacionamento de Dependência A dependência básica não é transitiva Cuidado com ciclos de dependência! Mostrar todas as dependências existentes em um diagrama de classes é perda de tempo! Mostre apenas o que for necessário Ferramentas de engenharia reversa são de grande utilidade na identificação de dependências 37

38 Dependência 38

39 Restrições São aspectos importantes das definições das estruturas de dados Deve-se escrever as restrições entre chaves {} Já vimos alguns exemplos anteriormente Podemos utilizar: Linguagem natural Linguagem de programação OCL - Object Constraint Language OCL é a notação formal da UML 39

40 Dicas de Utilização Os diagramas UML são a espinha dorsal da linguagem Diagramas de classes são tão ricos que podem tornar-se complexos demais para utilizar Não tente utilizar todas as notações que dispõe Diagramas de classe conceituais são muito úteis na exploração da linguagem de negócio Não desenhe modelos para tudo Cuidado para não focar apenas na estrutura 40

41 Resumo da Aula Vimos: Diagramas de Classes 41

42 Alguma dúvida? 42

43 Fixação da Aula Leitura dos capítulos: UML Essencial - Cap. 3 43