Reuso de software

7.570 visualizações

Publicada em

1 comentário
4 gostaram
Estatísticas
Notas
Sem downloads
Visualizações
Visualizações totais
7.570
No SlideShare
0
A partir de incorporações
0
Número de incorporações
2
Ações
Compartilhamentos
0
Downloads
222
Comentários
1
Gostaram
4
Incorporações 0
Nenhuma incorporação

Nenhuma nota no slide

Reuso de software

  1. 1. Reuso de Software<br />Prof. Agnaldo Volpe Lovato<br />
  2. 2. Introdução<br />Uso em outras disciplinas<br />Engenharia Mecânica<br />Eletrônica<br />Objetivo: Reuso do Software Existente<br />Somente nos últimos anos sua aplicação tornou-se mais ativa<br />Reposta às demandas:<br />Menores custos<br />Manutenção de Software<br />Entregas mais rápidas<br />Aumento da qualidade<br />Direções opostas<br />
  3. 3. Introdução<br />Visão Empresarial<br />Os itens de reuso passam a fazer parte de um ativo valioso<br />Promovem reuso para aumentar seu retorno sobre investimentos de software<br />
  4. 4. Benefícios<br />Confiança aumentada<br />Risco de processo reduzido<br />Uso eficiente de especialistas<br />Conformidade com padrões<br />Desenvolvimento acelerado<br />
  5. 5. Problemas<br />Custos de manutenção aumentados<br />Código do componente indisponível<br />Falta de apoio de ferramenta<br />Muitas ferramentas CASE não apóiam o reuso<br />Síndrome do não-inventado-aqui<br />Preferência em reescrever o componente<br />Criação e manutenção de uma biblioteca de componentes<br />Imaturidade na organização de uma biblioteca de componentes<br />Procura, compreensão e adaptação de componentes reusáveis<br />
  6. 6. Panorama<br />Várias técnicas foram desenvolvidas nos últimos 20 anos<br />Reuso possível em diferentes níveis<br />Funções simples até aplicações completas<br />Padrões facilitam o reuso<br />Design patterns<br />Desenvolvimento de Software Orientado a Aspectos<br />Linhas de produtos de aplicação<br />Framewors de aplicação<br />Geradores de programa<br />Empacotamento de sistemas legados<br />Integração de COTS<br />Desenvolvimento baseado em componentes<br />Sistemas orientados a serviços<br />Aplicações verticais configuráveis<br />Bibliotecas de Programas<br />
  7. 7. Panorama<br />Qual a técnicas mais apropriada?<br />Requisitos<br />Tecnologia<br />Ativos reusáveis<br />Conhecimento da equipe<br />
  8. 8. Considerações no planejamento do reuso<br />Cronograma de desenvolvimento do software<br />Quanto mais curto for o prazo, a tendência em reusar sistemas prontos em vez de componentes individuais aumenta<br />Ciclo de vida previsto do software<br />Ciclo de vida longo<br />Se concentrar na facilidade de manutenção<br />Além das possibilidades de reuso, deve-se também pensar nas implicações a longo prazo<br />Adaptação do sistema aos novos requisitos – mudanças nos componentes<br />Se você não tem acesso ao código-fonte, evite o uso de componentes e sistemas de fornecedores externos<br />Conhecimento, habilidades e experiência da equipe de desenvolvimento<br />Tecnologias de reuso são bastante complexas<br />Treinamento<br />
  9. 9. Considerações no planejamento do reuso<br />Importância do software e seus requisitos não funcionais<br />Softwares com requisitos de desempenho<br />Uso de geradores de programas pode ser ineficaz<br />Não acesso ao código fonte pode trazer problemas<br />Domínio da aplicação<br />Alguns domínios de aplicação trazem produtos genéricos que podem ser reutilizados<br />Alguns permitem a exportação e importação de dados<br />Plataforma sobre a qual o sistema será executado<br />Buscar componentes compatíveis<br />
  10. 10. Considerações no planejamento do reuso<br />A gama de técnicas é grande – há possibilidade de reuso de software<br />Empregar reuso é frequentemente uma decisão mais gerencial do que técnica<br />Gerentes<br />Podem não desejar comprometer seus requisitos com o reuso<br />Podem decidir que o desenvolvimento de componentes ajudará a criar uma base de ativos de software<br />Podem não compreender os riscos associados ao reuso da mesma forma que compreendem os riscos de desenvolvimento original<br />Preferem riscos conhecidos a desconhecidos<br />
  11. 11. Desenvolvimento baseado em Componentes<br />Criados com o objetivo de conduzir ao reuso<br />Surgiu da frustração de que o desenvolvimento orientado a objetos não tinha conduzido a um extensivo reuso<br />Classes e objetos são muito detalhadas e específicas<br />Componentes são mais abstratos que as classes de objetos e podem ser considerados provedores de serviços<br />Os componentes devem ser bem documentados para ajudar o projetista a compreendê-los e adaptá-los a uma nova aplicação<br />
  12. 12. Desenvolvimento baseado em Componentes<br />Pontos essenciais na engenharia baseada em componentes:<br />Componentes independentes<br />Deve haver uma clara separação entre a interface do componente e sua implementação<br />Padrões de componentes<br />Permitem o uso em mais de uma linguagem de programação<br />Middleware<br />Permitir que componentes independentes e distribuídos trabalhem juntos<br />Processo de desenvolvimento<br />
  13. 13. Reuso Baseado em Geradores<br />Conhecimento reusável é capturado em um sistema gerador de programas<br />Pode ser programado por especialistas<br />A descrição da aplicação especifica, de maneira abstrata, quais componentes reusáveis serão empregados<br />Aplicações de mesmo domínio têm arquiteturas comuns<br />Podemos ter:<br />Geradores de parser para processamento de linguagem<br />Geradores de código em ferramentas CASE<br />Podem gerar códigos ineficientes<br />Podem trazer riscos, pois tem um custo inicial alto na definição e implementação de conceitos do domínio<br />
  14. 14. Reuso Baseado em Geradores<br />Gerador de Programa<br />Programa Gerado<br />Descrição da Aplicação<br />Conhecimento de domínio da aplicação<br />Banco de Dados<br />
  15. 15. Reuso Baseado em Geradores<br />Software Orientado a Aspectos<br />Resolve o problema da separação de assuntos - princípio básico do projeto<br />Cada unidade ou componentes deve realizar uma, e somente uma função<br />Exemplos<br />Componente dedicado à busca de informações<br />Componente dedicado à impressão de documentos<br />Componente dedicado à conexão com o banco de dados<br />Contudo, estes componentes acabam de alguma forma se cruzando<br />Orientação a Aspectos busca realizar a integração separando e organizando o código de acordo com a sua importância para a aplicação<br />
  16. 16. Frameworks de Aplicações<br />É um projeto de subsistema composto por um conjunto de classes abstratas e concretas e as interfaces entre elas.<br />3 classes de Frameworks:<br />Frameworks de infra-estrutura de sistemas<br />Frameworks de integração de middleware<br />Frameworks de aplicações empresariais<br />É uma estrutura genérica que pode ser ampliada para criar um subsistema ou aplicação mais específica<br />Ampliar o Framework pode envolver a adição de classes concretas que herdam operações de classes abstratas no Framework<br />O maior problema está na sua complexidade e tempo para aprender a usá-lo<br />
  17. 17. Reuso do Sistema de Aplicações<br />Envolve o reuso de sistemas de aplicações inteiras<br />Pode-se alcançar o objetivo:<br />Pela configuração de um único sistema<br />Pela integração de um ou mais sistemas para criar uma nova aplicação<br />É frequentemente a técnica mais eficiente de reuso<br />Envolve o reuso de grandes ativos que podem ser rapidamente configurados para criar um novo sistema<br />
  18. 18. Reuso de Produto COTS<br />Um produto comercial (COTS) é um sistema de software que pode ser usado sem alterações pelo comprador<br />Exemplo:<br />Sistemas Gerenciadores de Banco de Dados<br />Escolhas que precisam ser feitas quando usamos COTS<br />Quais produtos COTS oferecem a funcionalidade mais apropriada?<br />Como os dados serão trocados?<br />Quais recursos de um produto serão realmente usados?<br />
  19. 19. Reuso de Produto COTS<br />Cliente<br />Navegador Web<br />Sistema de e-mail<br />Servidor<br />Sistema de e-commerce<br />Sistema de pedidos e faturas<br />Adaptador<br />Sistema de e-mail<br />Adaptador<br />
  20. 20. Reuso de Produto COTS<br />Problemas de integração de sistemas COTS:<br />Falta de controle sobre a funcionalidade e o desempenho<br />Problemas com a interoperabilidade de sistemas COTS<br />Nenhum controle sobre a evolução do sistema<br />Suporte dos fornecedores de COTS<br />
  21. 21. Linhas de Produtos de Software<br />É um conjunto de aplicações com uma arquitetura comum específica de aplicação<br />Cada aplicação específica é especializada de alguma maneira<br />O núcleo comum é reusado cada vez em que uma nova aplicação é necessária<br />O novo desenvolvimento pode envolver a configuração de componentes específicos, a implementação de componentes adicionais e a adaptação de alguns componentes<br />
  22. 22. Linhas de Produtos de Software<br />Tipos de especialização em uma LPS:<br />Especialização da plataforma<br />Somente componentes que fazem interface com o hardware e o sistema operacional são modificados<br />Especialização de ambiente<br />Exemplo: componentes do sistema são alterados para refletir a funcionalidade do equipamento de comunicação usado<br />Especialização funcional<br />Requisitos diferentes. Adição ou modificação de componentes<br />Especialização de processo<br />Adaptação do sistema para lidar com processo de negócios específicos<br />
  23. 23. Linhas de Produtos de Software<br />Linhas de produtos de software podem ser configuradas em dois pontos no processo de desenvolvimento:<br />Configuração em tempo de implantação<br />ERP (Enterprise ResourcePlanning) ou<br />SIGE (Sistemas Integrados de Gestão Empresarial)<br />Configuração em tempo de projeto<br />Levantar os requisitos dos stakeholders<br />Escolher um membro da família mais adequado<br />Renegociar requisitos<br />Adaptar o sistema existente<br />Entregar novo membro de família<br />
  24. 24. Considerações Finais<br />Não temos ferramentas apropriadas<br />Muitas organizações ainda não estão preparadas<br />Não entendem que o esforço inicial pode ser revertido em benefícios para as próprias empresas<br />Grandes organizações como HP e Motorola já adotam o reuso<br />Empresas tem medo de perder seu staff momentaneamente para o reuso<br />Estudos indicam que empresas que possuem iniciativas de reuso de ativos de software podem aumentar sua produtividade, qualidade e agilidade em, pelo menos, 5 vezes<br />
  25. 25. Considerações Finais<br />O planejamento é fundamental para evitar re-trabalho na reutilização de ativos de software<br />Pode requerer uma reestruturação na área de TI da empresa<br />Requer mudança de cultura<br />É preciso de um plano de comunicação bem estruturado<br />Motivar as equipes de projeto a gerar componentes de uma maneira que eles possam ser facilmente encontrados e reutilizados<br />Capacitar as equipes envolvidas<br />

×