Reuso desw

581
-1

Published on

Basic Concepts on Software Reuse OOP polymorphism etc.

Published in: Technology
1 Comment
1 Like
Statistics
Notes
No Downloads
Views
Total Views
581
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
1
Likes
1
Embeds 0
No embeds

No notes for slide

Reuso desw

  1. 1. Reuso de Software Cleverson de Freitas Cristian Leandro Stroparo Juliano Lorenzet Curitiba, 10 de Junho de 2009 CI221 – Engenharia de Software Profª Silvia Regina Vergilio
  2. 2. O que é reuso de software? É o processo de incorporar em um novo produto : <ul><li>Código;
  3. 3. Especificações de requisitos e projeto;
  4. 4. Planos de teste;
  5. 5. Informações/dados gerados em desenvolvimentos anteriores;
  6. 6. Conhecimento em geral; </li></ul>“ Reuso pode ser entendido como uso de conceitos ou produtos previamente adquiridos ou construídos em uma nova situação ” (Biggerstaff and Perlis, 1989)‏
  7. 7. O que é reuso de software? <ul><li>Nasceu da observação de que os softwares frequentemente seguem padrões similares; </li></ul><ul><li>Não é aplicavel somente a fragmentos do código, também é uma forma eficaz de aproveitar os conhecimentos sobre o desenvolvimento de sistemas; </li></ul><ul><li>Envolve a representação dos produtos em vários níveis de abstração, armazenamento, identificação de similaridades entre situações novas e antigas, recuperação de produtos já desenvolvidos e sua adaptação na nova situação; </li></ul>
  8. 8. Reusabilidade <ul><li>Medida da facilidade em se utilizar os conceitos e produtos em novas situações; </li></ul><ul><li>É o grau de facilidade ou de potencialidade que um componente possui para ser Reusado; </li></ul><ul><li>Está relacionado à alta coesão e baixo acoplamento com outros módulos. </li></ul>
  9. 9. Características básicas do reuso <ul><li>O reuso de software tem três características chaves : </li></ul><ul><ul><li>Prática sistemática de desenvolvimento de software;
  10. 10. Explora similaridade em requisitos e/ou arquiteturas entre aplicações;
  11. 11. Oferece benefícios substanciais na produtividade, qualidade e performance comercial. </li></ul></ul>
  12. 12. Benefícios (Objetivos)‏ <ul><li>Aumento da produtividade: reutilizando-se artefatos o esforço no desenvolvimento diminui gerando um produto final de igual ou superior qualidade do que um gerado sem reutilização;
  13. 13. Aumento da qualidade e confiabilidade: como os artefatos foram previamente testados, a probabilidade de sua corretude é ainda maior. Se a parte tem qualidade, o todo também terá.
  14. 14. Redução dos custos e tempo de desenvolvimento: o custo de construção de artefatos reutilizáveis é diluído entre os vários projetos onde será reutilizado. </li></ul>
  15. 15. Benefícios (Objetivos)‏ <ul><li>Redução no tempo de entrega: se o esforço no desenvolvimento diminui, consequentemente o tempo de entrega também diminui.
  16. 16. Interoperabilidade: a padronização garante que os sistemas se comportem de maneira comum, aumentando a interoperabilidade
  17. 17. Previsibilidade / Confiabilidade / Redução dos riscos: artefatos bem testados e reutilizados várias vezes têm alto grau de confiabilidade, diminuindo os riscos de erro.
  18. 18. Padronização: como os artefatos seguem uma padronização pré-definida, sua reutilização em um sistema causará conseqüente padronização. </li></ul>
  19. 19. Requisitos <ul><li>Deve ser possível encontrar os componentes; </li></ul>(catalogação)‏ <ul><li>Certeza de comportamento como especificado; </li></ul>(certificação)‏ <ul><li>Possibilidade de entendimento e adaptação. </li></ul>(documentação)‏
  20. 20. Dificuldades <ul><li>Empenho - a principal razão da baixa taxa de reutilização que se verifica deve-se à inexistência de qualquer esforço para reutilizar;
  21. 21. Existência - o fato de não existirem partes isoladas, sob a forma de artefatos, quer tenham sido desenhados para reutilização ou não, representa um impedimento;
  22. 22. Disponibilidade - a falta de repositórios e a limitação do seu uso são as principais razões da falta de disponibilidade do artefato;
  23. 23. Acessibilidade - a má ou insuficiente representação e classificação do artefato ou a fraca qualidade das ferramentas de busca são as principais razões para não encontrá-lo;
  24. 24. Legibilidade - a dificuldade em compreender o artefato, seja por documentação insuficiente ou devido a uma excessiva complexidade do mesmo, estão na origem da sua desconsideração para reutilização; </li></ul>
  25. 25. Dificuldades <ul><li>Validação - a falta de teste do artefato, o baixo desempenho, a não adesão aos padrões de normalização ou a falta de suporte por parte do produtor do artefato são consideradas as principais razões para sua rejeição na validação;
  26. 26. Integrabilidade - a existência de incompatibilidade de hardware e ambiente de integração são as razões mais frequentes que impedem a integração do artefato;
  27. 27. Barreiras psicológicas;
  28. 28. Barreiras legais e econômicas;
  29. 29. Falta de ferramentas de apoio. </li></ul>
  30. 30. Fases do Reuso <ul><li>Fase pré OO: 1960-1970 </li></ul><ul><ul><li>Técnica: Cut-and-Paste - linhas de código roubadas de um programa e usadas em outro;
  31. 31. Técnica: Subrotinas - código comum de um programa;
  32. 32. Técnica: Bibliotecas - funções inteiras genéricas, relacionadas, para servir em várias situações em programas diferentes </li></ul></ul>
  33. 33. Fases do Reuso <ul><li>Fase da revolução OO: 1980 </li></ul><ul><ul><li>Técnica: Herança – conceitos inteiros através de classes ( permite fazer programming-by-difference);
  34. 34. Técnica: Interfaces – contratos de relacionamento entre objetos. </li></ul></ul>
  35. 35. Fases do Reuso <ul><li>Fase pós deslumbramento OO: 1990 </li></ul><ul><ul><li>Técnicas foram inventadas e catalogadas para “resolver” os problemas que ocorriam anteriormente;
  36. 36. Design Patterns (Padrões de Projeto) - A granularidade de reuso está aumentando de “classes individuais” (hierarquias de classes) para “várias classes e suas colaborações”. </li></ul></ul>
  37. 37. Fases do Reuso <ul><li>Fase pós deslumbramento OO: 1990 (cont.)‏ </li></ul><ul><ul><li>Frameworks - Para reusar análise, arquitetura, design inteiro, semântica de interação e testes;
  38. 38. Componentes – Uso frequente de ferramentas visuais para criar componentes. Apareceu para compor interfaces gráficas mais rapidamente </li></ul></ul><ul><ul><ul><li>Permitiram o RAD (Rapid Application Development)‏ </li></ul></ul></ul>
  39. 39. Frameworks <ul><li>Abstração que une códigos comuns entre vários projetos de software provendo uma funcionalidade genérica. (Aplicação semi-completa)
  40. 40. Hot-Spots: </li></ul><ul><ul><li>Partes do framework que podem ser adaptadas;
  41. 41. Específicas de sistemas individuais;
  42. 42. Funcionalidades/serviços que devem ser implementados; </li></ul></ul><ul><li>Frozen-Spots: </li></ul><ul><ul><li>Partes fixas do framework;
  43. 43. Definem a arquitetura geral do sistema;
  44. 44. Serviços já implementados pelo framework. </li></ul></ul>
  45. 45. Framework X Design Pattern <ul><li>Design Pattern são mais abstratos que framework;
  46. 46. Framework inclui código;
  47. 47. Frameworks tem um domínio de aplicação particular. </li></ul>
  48. 48. Tipos de Framework <ul><li>Framework Vertical </li></ul><ul><ul><li>Tenta resolver problemas de um domínio;
  49. 49. Usado em vários software do mesmo domínio;
  50. 50. Exemplos: Framework financeiro, recursos humanos. </li></ul></ul><ul><li>Framework Horizontal </li></ul><ul><ul><li>Não depende do domínio da aplicação;
  51. 51. Pode ser usado em diferentes domínios;
  52. 52. Exemplos: Interfaces gráficas. </li></ul></ul>
  53. 53. Tipos de reuso
  54. 54. Abordagens de reutilização <ul><li>Geradores de Aplicação: a partir de uma descrição/especificação de alto nível o programa é gerado. Trabalham dentro de apenas um domínio de aplicação. O processo de reutilização é transparente ao usuário. </li></ul><ul><li>Reutilização por Composição: a partir da seleção de um componente é possível construir ou compor um programa. Isso implica que o usuário é parte ativa do processo de reutilização. </li></ul>
  55. 55. Reuso com Orientação a Objetos A princípio, Reuso não é tão fácil de conseguir como se espera. Para produzir modelos reusáveis de objetos são necessários: <ul><li>Experiência
  56. 56. Familiaridade </li></ul>
  57. 57. Objetos como provedores de serviço Técnica de modelagem O.O.: <ul><li>Um sistema prove serviços e é constituído por objetos;
  58. 58. Tais objetos proveem serviços;
  59. 59. Objetos que compõe outros objetos proveem serviços, e assim por diante. </li></ul>
  60. 60. Objetos como provedores de serviço Vantagens de se valorizar um objeto/classe pelos serviços que provê: <ul><li>Identificar classes a serem implementadas ou adquiridas;
  61. 61. Coesão melhorada do Projeto/Design. </li></ul><ul><ul><li>Mais fácil de &quot;encaixar&quot; classes ao Design; </li></ul></ul><ul><li>Grande possibilidade de reuso do modelo e implementação. </li></ul>
  62. 62. Componentes e R.A.D. (Rapid App. Development)‏ Classes &quot;prontas&quot;: <ul><li>Frameworks;
  63. 63. Componentes de IDE's. </li></ul>Colocação em uso é rápida. Conclusão: produção acelerada .
  64. 64. Reuso com polimorfismo <ul><li>Tipos específicos tratados como genéricos ( upcasting ). Mensagens ao tipo genérico e execução do código específico (late binding). </li></ul><ul><li>Software altamente extensível : </li></ul><ul><ul><li>Exemplo: Código que trata coleção de objetos de diversos tipos (polimorfos) fica intacto ao se incluir um novo tipo à coleção. </li></ul></ul>
  65. 65. Reuso com polimorfismo
  66. 66. Reuso com polimorfismo
  67. 67. Herança vs. Composição <ul><li>Herança, é bom, mas é supervalorizada.
  68. 68. Prefira composição a herança, no início da modelagem. É mais flexível.
  69. 69. Usar ambas com inspeção. </li></ul><ul><ul><li>Experiência, insight e bom senso. </li></ul></ul>
  70. 70. Referências Bibliográficas <ul><li>http://www.ime.usp.br/~yw/2004/mac5701i/monografias/claudia-acvm.pdf
  71. 71. http://inf.cp.cefetpr.br/ligia/papers/reuso.pdf
  72. 72. http://www.linux.ime.usp.br/~cef/mac499-06/monografias/alexandre/files/Monografia_Alexandre_Onishi.pdf
  73. 73. Thinking In Java, 4 th Edition, Bruce Eckel, MindView Inc. (www.mindview.net)‏
  74. 74. http://www.inf.ufpr.br/silvia/ES/reuso/reuso.pdf
  75. 75. http://www.cic.unb.br/~jhcf/MyBooks/iess/Reuso/Reusoereusabilidade.pdf
  76. 76. http://disciplinas.lia.ufc.br/engsof081/arquivos/Introducao_Reuso_de _Software_Aula_Profa_Rossana.pdf
  77. 77. http://www.dsc.ufcg.edu.br/~jacques/cursos/map/pdf/4.1-Facetas%20da%20Reusabilidade%20de%20Software.pdf </li></ul>

×