Aula 3 ferramenta case e orientação a objetos

501 visualizações

Publicada em

ferramenta case e orientação a objetos

Publicada em: Educação
0 comentários
0 gostaram
Estatísticas
Notas
  • Seja o primeiro a comentar

  • Seja a primeira pessoa a gostar disto

Sem downloads
Visualizações
Visualizações totais
501
No SlideShare
0
A partir de incorporações
0
Número de incorporações
3
Ações
Compartilhamentos
0
Downloads
16
Comentários
0
Gostaram
0
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Aula 3 ferramenta case e orientação a objetos

  1. 1. Ferramenta CASE orientada a Objetos e Orientação a Objetos Professor Wagner Gadêa Lorenz wagnerglorenz@gmail.com Disciplina: Engenharia de Software II Curso de Sistemas de Informação Cachoeira do Sul, 11 de Março de 2015.
  2. 2. Ferramenta CASE Baseadas na Linguagem UML ❖ Ferramentas CASE (Computer-Aided Software Engineering ou Engenharia de Software Auxiliada por Computador) são softwares que, de alguma maneira, colaboram para a execução de uma ou mais atividades realizadas durante o processo de engenharia de software. Engenharia de Software II 2
  3. 3. Ferramenta CASE Baseadas na Linguagem UML ❖ A maioria das ferramentas CASE atuais suporta UML, sendo essa uma das suas principais características. ❖ Astah (http://astah.net/) ❖ http://astah.net/student-license-request ❖ StarUML (http://staruml.io/) Engenharia de Software II 3
  4. 4. Orientação a Objetos ❖ A UML está totalmente inserida no paradigma de orientação a objetos. Por esse motivo, para compreendê-la corretamente precisamos, antes, compreender o conceito de orientação a objetos. Engenharia de Software II 4
  5. 5. Classificação, Abstração e Instanciação ❖ Nosso modo de aprender, no início é orientado a objetos, ou seja, aprendemos por meio de classificações (por exemplo, uma criança). ❖ Aprendemos a classificar praticamente tudo, criando grupos de objetos com características iguais, sendo que cada grupo de objetos é equivalente a uma classe. Engenharia de Software II 5
  6. 6. Classificação, Abstração e Instanciação ❖ Sempre que precisamos compreender um conceito novo, criamos uma nova classe para esse conceito, muitas vezes derivando-a de classes mais simples (ou seja, conceitos mais simples), e determinamos que todo o objeto com as características dessa classe é um exemplo, uma instância dela. ❖ Assim, instância constitui-se simplesmente em criar um exemplo de um tipo, um grupo, uma classe. Engenharia de Software II 6
  7. 7. Classificação, Abstração e Instanciação ❖ Quando instanciamos um objeto de uma classe, estamos criando um novo item do conjunto representado por essa classe, com as mesmas características e comportamentos de todos os outros objetos já instanciados. ❖ Além disso, depois de abstrair um conceito inicial, costumamos criar subdivisões dentro das classes, isto é, grupos dentro de grupos, o que já caracteriza um novo nível de abstração. Engenharia de Software II 7
  8. 8. Classificação, Abstração e Instanciação ❖ Podemos criar subgrupos dentro da classe Carro, classificando-os por marca ou modelo, por exemplo, ou dentro da classe Pessoa, classificando os novos grupos por profissionais, grau de parentesco ou status social. Engenharia de Software II 8
  9. 9. Classificação, Abstração e Instanciação ❖ No entanto, deve-se ter em mente que, apesar de terem os mesmo atributos, os objetos de uma classe não são exatamente iguais, pois cada objeto armazena valores diferentes em seus atributos. ❖ Por exemplo, todos os objetos da classe Carro possuem o atributo cor, mas um dos objetos pode ter uma cor azul, enquanto outro objeto pode ter uma cor verde. ❖ Da mesma forma, todos os objetos da classe Pessoa têm o atributo altura, mas o valor armazenado nesse atributo varia de pessoa a pessoa. Engenharia de Software II 9
  10. 10. Classes de Objetos ❖ Uma classe represente uma categoria, e os objetos são os membros ou exemplos dessa categoria. ❖ Na UML, uma classe é representada por um retângulo que pode ter até três divisões. Engenharia de Software II 10
  11. 11. Classes de Objetos ❖ A primeira divisão armazena o nome pelo qual a classe é identificada, a segunda enuncia os possíveis atributos pertencentes à classe e a terceira lista os possíveis métodos que a classe contém. ❖ Em geral, uma classe tem atributos e métodos, mas é possível encontrar classes que contenham apenas uma dessas características ou mesmo nenhuma delas, como no caso de classes abstratas. Engenharia de Software II 11 Carro Figura 1. Exemplo de uma Classe
  12. 12. Classes de Objetos ❖ Pode-se observar na Figura 1 um exemplo da classe. Nesse caso identificamos uma classe chamada Carro. ❖ Observe que essa classe tem apenas uma divisão que contém seu nome, pois não é obrigatório representar uma classe totalmente expandida, embora seja mais comum encontrar exemplos assim. ❖ Além disso, a classe pode simplesmente não conter atributos e métodos, quando se tratar de classes abstratas. Engenharia de Software II 12
  13. 13. Atributos ou Propriedades ❖ Classes costumam definir atributos, também conhecidos como propriedades. ❖ Os atributos representam as características de uma classe, ou seja, as peculiaridades que costumam variar de um objeto para outro, como altura, em um objeto da classe Pessoa ou a cor em um objeto da classe Carro, e que permitem diferenciar um objeto de outro da mesma classe devido as tais variações. Engenharia de Software II 13
  14. 14. Atributos ou Propriedades ❖ Os atributos são apresentados na segunda divisão da classe e contêm, normalmente, duas informações: • o nome que identifica o atributo; e • o tipo de dado que o atributo armazena, como por exemplo, integer, float ou character. (não é obrigatória, mas muitas vezes é útil e recomendável) Engenharia de Software II 14
  15. 15. Atributos ou Propriedades ❖ Na realizada não é exatamente a classe que contém os atributos, mas sim, as instâncias, os objetos dessa classe. ❖ Não é realmente possível trabalhar com uma classe, apenas com suas instâncias. ❖ Por exemplo, a classe Pessoa não existe realmente: é uma abstração, uma forma de classificar e identificar um grupo de objetos semelhantes. ❖ Nunca poderemos trabalhar com a classe Pessoa propriamente dita, apenas com suas instâncias, como João, Pedro ou Miguel, que são nomes que identificam três objetos da classe Pessoa. Engenharia de Software II 15
  16. 16. Atributos ou Propriedades ❖ Assim, os objetos têm os atributos relativos à classe à qual pertencem. Tais atributos são as caraterísticas do objeto, como cor e número de portas, no caso de uma instância de classe Carro. ❖ Todas as instâncias de uma classe possuem exatamente os mesmos atributos, no entanto, esses atributos podem assumir valores diversos. Engenharia de Software II 16 Carro Figura 2. Exemplo de uma classe com atributos. cor portas
  17. 17. Atributos ou Propriedades ❖ Pode-se observar na Figura 2 a mesma classe da Figura 1, mas com duas divisões. ❖ A segunda divisão armazena os atributos da classe carro, que, nesse caso são “cor” e “portas”. Neste exemplo não foram ainda definidos os tipos dos atributos. Engenharia de Software II 17
  18. 18. Métodos, Operações ou Comportamentos ❖ Classes costumam ter métodos, também conhecidos como operações ou comportamentos ( a UML usa o termo operação). ❖ Um método representa uma atividade que um objeto de uma classe pode executar. Engenharia de Software II 18
  19. 19. Métodos, Operações ou Comportamentos ❖ Podemos comparar um método a uma função como as desenvolvidas nas linguagens de programação. ❖ Um método pode receber ou não parâmetros (valores que são utilizados durante a execução do método) e, em geral, como nas funções, um método tende a retornar valores. ❖ Esse valores podem representar resultados da operação executada ou simplesmente indicar se o processo foi concluído com sucesso ou não. Engenharia de Software II 19
  20. 20. Métodos, Operações ou Comportamentos ❖ Desta forma, um método representa um conjunto de instruções que são executadas quando o método é chamado, por exemplo, um objeto da classe Carro pode executar a atividade de transportar pessoas. ❖ Os métodos são armazenados na terceira divisão de uma classe. Engenharia de Software II 20 Figura 3. Exemplo de uma classe com métodos Carro cor portas TransportarPessoas()
  21. 21. Visibilidade ❖ A visibilidade é utilizada para indicar o nível de acessibilidade de um determinado atributo ou método, sendo representada à esquerda destes. ❖ Existem basicamente quatro modos de visibilidade: • público; • protegido; • privado; e • pacote. Engenharia de Software II 21
  22. 22. Visibilidade ❖ A visibilidade privada é representada por um símbolo de menos (-) e significa que somente os objetos da classe detentora do atributo ou método poderão enxergá-lo ou utilizá-lo. ❖ A visibilidade protegida é representada pelo símbolo de sustenido (#) e determina que além dos objetos da classe detentora do atributo ou método também os objetos de suas subclasses poderão ter acesso ao mesmo. Engenharia de Software II 22
  23. 23. Visibilidade ❖ A visibilidade pública é representada por um símbolo de mais (+) e determina que o atributo ou método pode ser utilizado por qualquer objeto. ❖ A visibilidade pacote é representada por um símbolo de til (˜) e determina que o atributo ou método é visível por qualquer objeto dentro do pacote. Somente elementos que fazem parte de um pacote podem ter essa visibilidade. Nenhum elemento fora do pacote poderá ter acesso a um atributo ou método com essa visibilidade. Engenharia de Software II 23
  24. 24. Visibilidade Engenharia de Software II 24 Carro - cor - portas +TransportarPessoas() Figura 4. Exemplo de visibilidade.
  25. 25. Herança ❖ A herança é uma das características mais poderosas e importantes da orientação a objetos. ❖ D e v i d o a o f a t o d e a h e r a n ç a p e r m i t i r o reaproveitamento de atributos e de métodos, otimizando o tempo de desenvolvimento, além de permitir a diminuição de linhas de código, bem como facilitar futuras manutenções. Engenharia de Software II 25
  26. 26. Herança ❖ O conceito de herança trabalha com os conceitos de superclasses e subclasses, também chamadas de classe-mãe, é uma classe que contém classes derivadas a partir dela, chamadas subclasses, também conhecidas como classes-filhas. ❖ As subclasses, ao serem derivadas a partir de uma superclasse, herdam suas características, ou seja, seus atributos e métodos. Engenharia de Software II 26
  27. 27. Herança ❖ A vantagem do uso da herança é óbvia: ao declararmos uma classe com atributos e métodos específicos e, depois disso, derivarmos uma subclasse a partir da classe já criada, não precisamos redeclarar os atributos e métodos previamente definidos: a subclasse herda-os automaticamente, permitindo uma reutilização do código já pronto. ❖ Assim, só precisamos nos preocupar em declarar os atributos ou métodos exclusivos da subclasse, o que torna muito mais ágil o processo de desenvolvimento, além de facilitar igualmente futuras manutenções, sendo necessário apenas alterar o método da superclasse para que todas as subclasses estejam também atualizadas imediatamente. Engenharia de Software II 27
  28. 28. Herança ❖ Além disso, a herança permite trabalhar com especializações. ❖ Podemos criar classes gerais, com características compartilhadas por muitas classes, mas que tenham pequenas diferenças entre si. ❖ Assim, criamos uma classe geral com as características comuns a todas as classes e diversas subclasses a partir dela, detalhando apenas os atributos ou métodos exclusivos das mesmas. Engenharia de Software II 28
  29. 29. Herança ❖ Uma subclasse pode se tornar uma superclasse a qualquer momento, bastando para tanto que se derive uma subclasse a partir dela. Engenharia de Software II 29
  30. 30. Herança Engenharia de Software II 30 Figura 5. Exemplo herança.
  31. 31. Herança ❖ Pode-se observar na Figura 5, a existência de uma classe geral chamada Animal e que essa classe tem um método chamado Locomover(), assim, qualquer instância da classe Animal, pode se locomover de um lugar para outro. ❖ A partir da classe Animal, derivamos duas subclasses, Mamifero e Ave. ❖ A classe Mamifero tem como atributo a existência de pelos e como método a capacidade de mamar, enquanto a classe Ave tem como atributo a existência de um bico e como método a capacidade de pôr ovos, mas ambas têm a capacidade de se locomover, herdada da superclasse Animal. Engenharia de Software II 31
  32. 32. Herança Múltipla ❖ Basicamente, a herança múltipla ocorre quando uma subclasse herda características de duas ou mais superclasses. ❖ No caso, uma subclasse pode herdar atributos e métodos de diversas superclasses. ❖ No entanto, não são todas as linguagens de programação orientadas a objeto que fornecem esse tipo de recurso, sendo este encontrado, por exemplo, na linguagem C++. Engenharia de Software II 32
  33. 33. Herança Múltipla Engenharia de Software II 33 Figura 6. Exemplo de Herança Múltipla.
  34. 34. Herança Múltipla ❖ O exemplo da Figura 6, tem uma classe a mais que na Figura 5, essa classe derivada das classes Mamiferos e Ave, a classe Ornitorrinco. ❖ Com isso, qualquer instância da classe Ornitorrinco terá pelos, e poderá mamar, peculiaridades herdadas da classe Mamifero, e também tem bico e poderá pôr ovos, peculiaridades da classe Ave. Engenharia de Software II 34
  35. 35. Polimorfismo ❖ O conceito de polimorfismo está associado à herança. O polimorfismo trabalha com a redeclaração de métodos previamente herdados por uma classe. ❖ Esses métodos, embora semelhantes, diferem de alguma forma da implementação utilizada na superclasse, sendo necessário, portanto, reimplementá- los na subclasse. Engenharia de Software II 35
  36. 36. Polimorfismo ❖ Porém, para evitar ter de modificar o código-fonte, inserindo uma chamada a um método com um nome diferente, redeclara-se o método com o mesmo nome declarado na superclasse. ❖ Assim, podem existir dois ou mais métodos com a mesma nomenclatura, diferenciando-se na maneira como foram implementados, sendo o sistema responsável por verificar se a classe da instância em questão contém o método declarado nela própria ou se herda de uma superclasse. Engenharia de Software II 36
  37. 37. Polimorfismo Engenharia de Software II 37 Figura 7. Exemplo de Polimorfismo.
  38. 38. Polimorfismo ❖ A partir do exemplo apresentado, utilizamos uma classe geral camada Conta_Comum. ❖ Essa classe tem um atributo chamado “saldo”, o qual contém o valor total depositado em uma determinada instância da classe e um método chamado Saque. ❖ O método Saque da classe Conta_Comum simplesmente diminui o valor a ser debitado do saldo da conta e, se este não tiver o valor suficiente, a operação deverá ser recusada. Engenharia de Software II 38
  39. 39. Polimorfismo ❖ A partir da classe Conta_Comum derivamos uma nova classe chamada Conta_Especial que tem um atributo próprio, além dos herdados, chamado “limite”. ❖ Esse atributo define o valor extra que pode ser sacado além do valor contido no saldo da conta. ❖ Por esse motivo, a classe Conta_Especial apresenta uma redefinição do método Saque, porque o algoritmo do método Saque da classe Conta_Especial não é idêntico ao do método Saque declarado na classe Conta_Comum, já que é necessário incluir o limite da conta no teste para determinar se o cliente pode retirar ou não o valor solicitado. Engenharia de Software II 39
  40. 40. Polimorfismo ❖ Porém, o nome do método permanece o mesmo: apenas no momento de executar o método o sistema deverá verificar se a instância que chamou o método pertence à classe Conta_Especial ou à Conta_Comum, executando o método definido na classe em questão. Engenharia de Software II 40
  41. 41. Polimorfismo ❖ O conceito de polimorfismo é um pouco semelhante ao de variáveis globais e locais utilizado pela linguagem de programação C. ❖ Ao declararmos uma variável global em um programa escrito na linguagem C, essa variável poderá ser vista e utilizada por qualquer outra função do programa. ❖ O mesmo ocorre com os métodos polimórficos, ou seja, supondo existirem diversas subclasses que herdam um método de uma superclasse, se uma delas redeclarar esse método, ele só se comportará de maneira diferente nos objetos da classe que o modificou, permanecendo igual à forma como foi implementado na superclasse para os objetos de todas as demais classes. Engenharia de Software II 41
  42. 42. Próxima Aula • Diagrama de Caso de Uso. Engenharia de Software II 42
  43. 43. Dúvidas • Conteúdo • Moodle • (http://wagnerglorenz.com.br/moodle/) • Dúvidas • wagnerglorenz@gmail.com Engenharia de Software II 43
  44. 44. Referências Bibliográficas • GUEDES, Gilleanes T. A.. UML: uma abordagem prática. São Paulo: Novatec, 2004. Engenharia de Software II 44

×