Facetas da Reusabilidade
de Software
- Daremos um breve panorama da disciplina inteira:
reusabilidade de software
Qual é o problema?
- Fazer software é difícil
- Fazer software é lento e caro
- Não temos tecnologia ainda para fazer software grande do
zero, rapidamente e com poucos bugs
Qual é a solução?
- Reutilizacao é "o" caminho mais
freqüentemente apontado
- As mesmas idéias básicas devem ter sido
projetadas e reprojetadas pela mesma pessoa ou
pessoas diferentes muitas vezes, com certeza!
- Será que temos que começar tudo de novo,
sempre??
Por que a solução não é fácil?
- Reuso não acontece automaticamente!
- Para reusar, tem que:
- Bolar boas abstrações (i.e., abstrações
úteis); e
- Empacotá-las para facilitar o reuso
- Como reutilizar bem tem sido meio misterioso ao longo dos
anos
- Como fazer isso?
- Que técnicas usar?
- Orientação a Objeto prometeu muito mas não cumpriu a
promessa
- Porque nao é facil
- Pouca gente conseguiu bons resultados
- Ficou mais marketing (com exceção de alguns
bons programadores)
- Por que é dificil?
- Sugestões de William Opdyke em
"Refactoring, Reuse, and Reality":
- Técnicos podem não entender o que
reusar ou como reusá-lo;
- Técnicos podem não se motivar a aplicar
técnicas de reuso a não ser que
benefícios de curto prazo sejam
alcançáveis (porém, o reuso é mais um
investimento a longo prazo);
- Overhead, curva de aprendizado e custos
de descobrimento devem ser endereçados
para que o caminho do reuso seja bem
sucedido.
O que mudou recentemente?
- Na metade da década de 90, as lições e caminhos
cristalizaram com:
- Design patterns; e
- Frameworks
- Frameworks são mais antigos, datando do
final de 80 mas explodiram apenas
recentemente devido ao casamento com
design patterns
Tipos de reuso
- Falaremos das técnicas historicamente empregadas para
atingir o reuso
- Do mais simples/antigo para mais sofisticado/novo
- A granularidade de reuso mudou
radicalmente ao longo dos anos
- 500 AC
- Reuso da solução do vizinho numa prova :-)
- 1960-1970
- O que é reutilizado: linhas de código
roubadas de um programa e usadas em outro
- Nome (moderno) da técnica: Cut-and-Paste
- O que é reutilizado: código comum de
um programa
- Nome da técnica: Subrotinas
- O que é reutilizado: funções inteiras
genéricas, relacionadas, para servir em
várias situações em programas diferentes
- Nome da técnica: Bibliotecas
- 1980 - A Revolução O-O
- O que é reutilizado: conceitos inteiros
através de classes
- Nome da técnica: herança,
composição/delegação
- Permite fazer Programming-by-Difference
- Composição é melhor do que herança
normalmente, pois:
- Permite mudar a associação
entre classes em tempo de
execução;
- Permite que um objeto assuma mais
de um comportamento (ex. papel);
- Herança acopla as classes demais
e engessa o programa
- O que é reutilizado: Contratos de
relacionamento entre objetos
- Nome da técnica: Interfaces
(originalmente chamado Protocolo)
- Interface como conceito de "Plug
Point"
- Interface como conceito de "barreira
de desacoplamento"
- Uma lei fundamental da
programação: "Program
to an Interface, not to an
Implementation"
- Classes abstratas são usadas para criar
interfaces em algumas linguagens, mas
deve-se diferenciar bem dois conceitos
que classes abstratas podem implementar:
- Classe puramente abstratas
definem uma interface (um tipo
abstrato de dados);
- Classe abstratas com alguma
implementação são usadas para
juntar código comum.
- O primeiro conceito é o mais
importante, já que o segundo
pode ser feito com
composição/delegação.
- Lembre: classe = implementação,
interface = contrato
- Em Java:
- Classes abstratas são
usadas apenas para
herança de
implementação
- Interfaces são usadas
para herança de tipo
- Late binding (polimorfismo) permite
melhor reuso pois desvincula o uso da
implementação
- Qualquer implementação da
interface pode pintar em tempo de
execução e ser usada
- Se fóssemos forçados a escolher
(isto é, fazer o binding) em
tempo de execução, teríamos
amarração a uma implementação
(classe) particular;
- Com late binding, mais objetos
podem trabalhar um com o outro,
pois eles sabem menos coisas um
do outro
- Porém, no final da década de 80, as técnicas
acima ainda não cumpriram a promessa de reuso
completamente
- Quais são as coisas que
ainda dificultam a reutilização de software?
- São situações novas que forçam um
redesign
- Criar um objeto especificando sua classe
explicitamente
- O código se compromete com uma
implementação particular
- Dependência de operações específicas
- Especificar uma operação
particular diz como
fazer algo e não apenas qual é
o efeito desejado
- Dependência de plataformas de hardware
ou software específicas
- Dependência da representação ou
implementação de objetos
- Clientes que sabem como um objeto
é representado, armazenado,
localizado ou implementado terão
que mudar se o cliente mudar
- Dependências algorítmicas
- Objetos que dependem de um
algoritmo devem mudar quando o
algoritmo é estendido, otimizado
ou trocado durante a manutenção
- Acoplamento forte
- O reuso isolado de classes que
têm acoplamento forte é
frequentemente impossível
- No extremo, temos um sistema
monolítico (puxa um fio e tudo
vem atrás)
- Extensão de funcionalidade através da
herança
- Cria um forte acoplamento entre a
superclasse e as subclasses
- Dificuldade de alterar classes
convenientemente
- Pode não ter código fonte ou
não querer mudar uma classe
- 1990
- Técnicas foram inventadas e catalogadas para
"resolver" os problemas mencionados
acima
- Catalogação das "boas idéias de
projeto" que os melhores programadores do
mundo tiveram aos longo dos anos
- São micro-arquiteturas que definem as colaborações
entre classes e objetos
- Chamados Design Patterns
- A granularidade de reuso está
aumentando de "classes
individuais" (ou hierarquias
de classes) para "várias
classes e suas
colaborações"
- Exemplo: Padrão Iterator para
varrer um objeto sem saber sua
implementação
- Não se reutiliza código aqui, só
idéias
- Soluções boas aos problemas de reuso
apresentados acima
- Especificam formas de separar e isolar o
que é igual do que é diferente entre
situações
- São soluções boas aos dois problemas:
"Bolar boas abstrações" e
"Empacotá-las para facilitar o
reuso"
- Resolvem particularmente bem o
segundo problema
- Aumentando ainda mais a granularidade: frameworks
- Para reusar: análise, arquitetura,
design inteiro, semântica de interação
e até testes!
- Imagine analisar, projetar, implementar e
testar várias aplicações semelhantes
- De um mesmo Domínio de
Problema
- Após implementar e testar as várias
aplicações, fatora o que elas tem de
comum num código único e deixe ganchos
para enxertar as diferenças
- Você acabou de criar um framework
- Frameworks explodindo no final da década
de 90 pois ficou mais claro como
criá-los usando Design Patterns
- Reutilização de objetos inteiros já
instanciados
- Componentes
- Cuidado! A palavra é usada de
várias formas!
- De forma geral, significa alguma
abtração plugável
- Para nós, a semântica é um
pouco mais restrita: Objetos
manipuláveis em Design Time
- Novo conceito: Design Time
- Para se somar a Compile Time
e Execution Time
- Queremos, em design time, instanciar
objetos, configurá-los e utilizá-los
num programa
- Uso frequente de ferramentas
visuais para criar componentes
- Apareceu para bolar interfaces gráficas
mais rapidamente
- Pioneirismo de Visual Basic
- Componentes permitiram a revolução
chamada RAD (Rapid Application
Development)
- Hoje: uso estendido para "Server
Components" que nem sequer têm
interface gráfica
- Técnicas para melhorar código para aumentar a
qualidade do software
- Incluindo sua legibilidade, robustez,
reusabilidade
- Técnicas se agrupam sob o termo Refactoring
- Refactoring consiste em fazer mudanças
de forma a um programa sem
introduzir mudanças funcionais
Palavras finais: Implantação da cultura de reuso nas
empresas
- Neste nova cultura, uma empresa se foca em construir e
melhorar seu patrimônio de reuso
- Isto deve ser encarado como investimento
- Um conceito novo na área de desenvolvimento de
software
- Generalizar algo para ser reutilizado não se
justifica se se considerar apenas o objetivo
original proposto
- Requer alargar os requisitos originais
- Requer coisas novas:
- Um processo de desenvolvimento adequado
- Além de desenvolver um produto, queremos
criar abstrações reutilizáveis e
aumentar o patrimônio da empresa
- Novos papeis
- Para coordenar o reuso entre times
diferentes
- Treinamento
- Incentivos apropriados para o reuso
- Porque atrapalhar meu cronograma só para
que o que faço seja reutilizado por outro
time depois?
intro-1 programa