Reuso de SoftwareProf. Agnaldo Volpe Lovato

Introdução

Uso em outras disciplinas Engenharia Mecânica Eletrônica

Objetivo: Reuso do Software Existente Somente nos últimos anos sua aplicação tornou-

se mais ativa Reposta às demandas:

Menores custos Manutenção de Software Entregas mais rápidas Aumento da qualidade Direções opostas

Introdução

Visão Empresarial

Os itens de reuso passam a fazer parte

de um ativo valioso

Promovem reuso para aumentar seu

retorno sobre investimentos de software

Benefícios

Confiança aumentada

Risco de processo reduzido

Uso eficiente de especialistas

Conformidade com padrões

Desenvolvimento acelerado

Problemas

Custos de manutenção aumentados Código do componente indisponível

Falta de apoio de ferramenta Muitas ferramentas CASE não apóiam o reuso

Síndrome do não-inventado-aqui Preferência em reescrever o componente

Criação e manutenção de uma biblioteca de componentes Imaturidade na organização de uma biblioteca de

componentes Procura, compreensão e adaptação de

componentes reusáveis

Panorama

Várias técnicas foram desenvolvidas nos últimos 20 anos

Reuso possível em diferentes níveis Funções simples até aplicações completas Padrões facilitam o reuso

Design patterns

Framewors de aplicação

Linhas de produtos de aplicação

Desenvolvimento de Software Orientado a

AspectosDesenvolvimento

baseado em componentes

Empacotamento de sistemas

legados

Integração de COTS

Geradores de programa

Sistemas orientados a

serviços

Aplicações verticais

configuráveisBibliotecas de Programas

Panorama

Qual a técnicas mais apropriada?

Requisitos

Tecnologia

Ativos reusáveis

Conhecimento da equipe

Considerações no planejamento do reuso

Cronograma de desenvolvimento do software Quanto mais curto for o prazo, a tendência em reusar sistemas prontos

em vez de componentes individuais aumenta

Ciclo de vida previsto do software Ciclo de vida longo

▪ Se concentrar na facilidade de manutenção

▪ Além das possibilidades de reuso, deve-se também pensar nas implicações a longo prazo

▪ Adaptação do sistema aos novos requisitos – mudanças nos componentes

▪ Se você não tem acesso ao código-fonte, evite o uso de componentes e sistemas de fornecedores externos

Conhecimento, habilidades e experiência da equipe de desenvolvimento Tecnologias de reuso são bastante complexas

Treinamento

Considerações no planejamento do reuso

Importância do software e seus requisitos não funcionais Softwares com requisitos de desempenho

Uso de geradores de programas pode ser ineficaz

Não acesso ao código fonte pode trazer problemas Domínio da aplicação

Alguns domínios de aplicação trazem produtos genéricos que podem ser reutilizados

Alguns permitem a exportação e importação de dados Plataforma sobre a qual o sistema será executado

Buscar componentes compatíveis

Considerações no planejamento do reuso

A gama de técnicas é grande – há possibilidade de reuso de software

Empregar reuso é frequentemente uma decisão mais gerencial do que técnica

Gerentes Podem não desejar comprometer seus requisitos com o

reuso

Podem decidir que o desenvolvimento de componentes ajudará a criar uma base de ativos de software

Podem não compreender os riscos associados ao reuso da mesma forma que compreendem os riscos de desenvolvimento original

Preferem riscos conhecidos a desconhecidos

Desenvolvimento baseado em Componentes

Criados com o objetivo de conduzir ao reuso Surgiu da frustração de que o desenvolvimento

orientado a objetos não tinha conduzido a um extensivo reuso

Classes e objetos são muito detalhadas e específicas

Componentes são mais abstratos que as classes de objetos e podem ser considerados provedores de serviços

Os componentes devem ser bem documentados para ajudar o projetista a compreendê-los e adaptá-los a uma nova aplicação

Desenvolvimento baseado em Componentes

Pontos essenciais na engenharia baseada em componentes: Componentes independentes▪ Deve haver uma clara separação entre a interface do

componente e sua implementação Padrões de componentes▪ Permitem o uso em mais de uma linguagem de

programação Middleware▪ Permitir que componentes independentes e

distribuídos trabalhem juntos Processo de desenvolvimento

Reuso Baseado em Geradores Conhecimento reusável é capturado em um sistema gerador de

programas

Pode ser programado por especialistas

A descrição da aplicação especifica, de maneira abstrata, quais

componentes reusáveis serão empregados

Aplicações de mesmo domínio têm arquiteturas comuns

Podemos ter:

Geradores de parser para processamento de linguagem

Geradores de código em ferramentas CASE

Podem gerar códigos ineficientes

Podem trazer riscos, pois tem um custo inicial alto na definição e

implementação de conceitos do domínio

Reuso Baseado em Geradores

Descrição da Aplicação

Conhecimento de domínio da

aplicação

Banco de Dados

Gerador de Programa

Programa Gerado

Reuso Baseado em Geradores Software Orientado a Aspectos

Resolve o problema da separação de assuntos - princípio básico do projeto

Cada unidade ou componentes deve realizar uma, e somente uma função

Exemplos▪ Componente dedicado à busca de informações▪ Componente dedicado à impressão de documentos▪ Componente dedicado à conexão com o banco de dados

Contudo, estes componentes acabam de alguma forma se cruzando

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

Frameworks de Aplicações É um projeto de subsistema composto por um conjunto de classes

abstratas e concretas e as interfaces entre elas.

3 classes de Frameworks:

Frameworks de infra-estrutura de sistemas

Frameworks de integração de middleware

Frameworks de aplicações empresariais

É uma estrutura genérica que pode ser ampliada para criar um

subsistema ou aplicação mais específica

Ampliar o Framework pode envolver a adição de classes concretas que

herdam operações de classes abstratas no Framework

O maior problema está na sua complexidade e tempo para aprender a

usá-lo

Reuso do Sistema de Aplicações Envolve o reuso de sistemas de aplicações

inteiras Pode-se alcançar o objetivo:

Pela configuração de um único sistema

Pela integração de um ou mais sistemas para criar uma nova aplicação

É frequentemente a técnica mais eficiente de reuso

Envolve o reuso de grandes ativos que podem ser rapidamente configurados para criar um novo sistema

Reuso de Produto COTS

Um produto comercial (COTS) é um sistema de software que pode ser usado sem alterações pelo comprador

Exemplo: Sistemas Gerenciadores de Banco de Dados

Escolhas que precisam ser feitas quando usamos COTS Quais produtos COTS oferecem a

funcionalidade mais apropriada? Como os dados serão trocados? Quais recursos de um produto serão realmente

usados?

Reuso de Produto COTS

ClienteNavegador

WebSistema de e-

mail

ServidorSistema de e-

commerce

Sistema de pedidos e

faturas

Adaptador

Adaptador

Sistema de e-mail

Reuso de Produto COTS

Problemas de integração de sistemas COTS:

Falta de controle sobre a funcionalidade e o

desempenho

Problemas com a interoperabilidade de sistemas

COTS

Nenhum controle sobre a evolução do sistema

Suporte dos fornecedores de COTS

Linhas de Produtos de Software

É um conjunto de aplicações com uma arquitetura comum

específica de aplicação

Cada aplicação específica é especializada de alguma

maneira

O núcleo comum é reusado cada vez em que uma nova

aplicação é necessária

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

Linhas de Produtos de Software Tipos de especialização em uma LPS:

Especialização da plataforma▪ Somente componentes que fazem interface com o hardware

e o sistema operacional são modificados Especialização de ambiente▪ Exemplo: componentes do sistema são alterados para refletir

a funcionalidade do equipamento de comunicação usado Especialização funcional▪ Requisitos diferentes. Adição ou modificação de

componentes Especialização de processo▪ Adaptação do sistema para lidar com processo de negócios

específicos

Linhas de Produtos de Software Linhas de produtos de software podem ser

configuradas em dois pontos no processo de desenvolvimento: Configuração em tempo de implantação

▪ ERP (Enterprise Resource Planning) ou

▪ SIGE (Sistemas Integrados de Gestão Empresarial)

Configuração em tempo de projeto

▪ Levantar os requisitos dos stakeholders

▪ Escolher um membro da família mais adequado

▪ Renegociar requisitos

▪ Adaptar o sistema existente

▪ Entregar novo membro de família

Considerações Finais

Não temos ferramentas apropriadas

Muitas organizações ainda não estão preparadas

Não entendem que o esforço inicial pode ser revertido em

benefícios para as próprias empresas

Grandes organizações como HP e Motorola já adotam o

reuso

Empresas tem medo de perder seu staff

momentaneamente para o reuso

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

Considerações Finais

O planejamento é fundamental para evitar re-trabalho na

reutilização de ativos de software

Pode requerer uma reestruturação na área de TI da

empresa

Requer mudança de cultura

É preciso de um plano de comunicação bem estruturado

Motivar as equipes de projeto a gerar componentes de uma

maneira que eles possam ser facilmente encontrados e

reutilizados

Capacitar as equipes envolvidas