Fatos e Falácias de Engenharia de Software - Reutilização
Autor: Lucas Vegi | Publicado: 2011-04-17T17:06:00-03:00

Após quase um mês sem atualizações aqui, estou voltando a postar continuando a&nbsp;seqüência&nbsp;de temas relacionados a Engenharia de Software.&nbsp;Nessa postagem irei abordar um tema que muito me agrada e que tem relação indireta com minha pesquisa: Reutilização no processo de desenvolvimento do software.

Digo que tem relação indireta pois minha pesquisa envolve bastante sobre Padrões de Análise, que basicamente proporciona reutilização conceitual no processo de software, enquanto que na discussão dessa postagem irei abordar mais especificamente a reutilização de código.

Futuramente estarei postando também sobre Padrões de Análise por aqui, mas enquanto isso vamos ao nosso texto de hoje.

Universidade Federal de Viçosa
Departamento de Informática
Mestrado em Ciência da Computação
INF 622 - Engenharia de Software
Resumo no. 03

Fatos
15 - Reutilização em pequena proporção (bibliotecas de sub-rotinas) começou há quase 50 anos e é um problema bem resolvido.
16 - Reutilização em grande proporção (componentes) continua sendo um problema na maior parte não resolvido, embora todos concordem que é importante e desejável. 
17 - Reutilização em grande proporção funciona melhor nas famílias de sistemas conexos e, portanto, é dependente do domínio. Isso restringe a aplicabilidade potencial desse tipo de reutilização.

Discussão
Ambos os fatos estudados tratam da Reutilização, sendo que cada um deles aborda o tópico por visões distintas. Atualmente muito se fala em reutilização de código, sendo que muitos tratam dessa técnica como se ela fosse novidade. O próprio paradigma de programação orientada a objetos coloca a reutilização como uma das suas grandes inovações. O fato 15 mostra que na verdade Reutilização de código é um conceito que surgiu na década de 50 com a Organização Share [1]. A proposta da Organização Share foi a de criar um espaço semelhante a uma biblioteca tradicional, porém lá ao invés de livros, os programadores compartilhavam códigos de programação de uso freqüente, e sempre que precisavam implementar algo que achavam que alguém poderia já ter feito antes, consultavam a biblioteca de códigos para evitar o retrabalho. Dentre esses códigos de uso comum que eram compartilhados, são exemplos funções para realização de operação matemáticas, funções de ordenação e busca de valores.

Com o passar dos anos a idéia de reutilização em pequenas proporções tornou-se muito difundida e ficou claro que isso agiliza muito o desenvolvimento. A maioria das linguagens mais utilizadas atualmente possui vastas bibliotecas de códigos definidos para diversos domínios comuns, como por exemplo, as conexões com os variados tipos de SGBDs. 

As bibliotecas das linguagens geralmente possuem funções que já foram exaustivamente testadas e amplamente utilizadas, passando assim um alto grau de confiabilidade. Portanto é muito mais eficiente em termos de agilidade na implementação e até mesmo de segurança (dependendo do domínio), utilizar funções pré-definidas nas bibliotecas do que ter o trabalho de fazer algo já existente.  

O fato 16 trata da reutilização de código em grandes proporções, a chamada engenharia de software baseada em componentes. Essa proposta prega que softwares podem ser montadas unicamente a partir de união de “peças” já existentes (componentes), escolhidos mediante a especificação dos requisitos. Essa idéia nos leva a pensar em uma verdadeira linha de montagem de software, porém na prática isso não acontece exatamente assim. 

Essa idéia de reutilização de componentes (reutilização de códigos em grande proporção) também não é nova, mas ao contrário da reutilização de bibliotecas de sub-rotinas comuns (reutilização de códigos em pequena proporção), ela nunca se tornou algo utilizado em grande escala. A discussão do fato 16 é basicamente a respeito do motivo pelo qual isso nunca aconteceu, mesmo sabendo-se que na teoria é algo que traria avanços significativos de produtividade no processo de desenvolvimento de software.

O problema maior da criação de componentes reutilizáveis, é que eles devem ser genéricos o suficiente para atender a qualquer domínio. Porém há grandes diferenças de exceções entre os domínios. Embora alguns problemas grandes quando analisados superficialmente possam parecer semelhantes, há uma série de restrições para as possíveis soluções quando analisamos os mesmos problemas em domínios diferentes. 

O fato 17 trata de algo extremamente realista e menos utópico que a reutilização de componentes totalmente genéricos. A grande barreira que impede a disseminação da reutilização em grandes proporções são as sutilezas que diferem os domínios. Elas dificultam muito na criação de componentes genéricos que atendam a todos os domínios de forma eficiente. Porém quando se trata de componentes aplicados a um mesmo domínio de problemas, a chance de sucesso aumenta consideravelmente [4]. 

Os estudos realizados pelo Software Engineering Laboratory (SEL), da NASA-Goddard [2] exemplificam bem essa afirmação, haja vista que 70% dos softwares desenvolvidos por eles dentro do domínio específico de dinâmica de vôos reutilizaram componentes com sucesso. 

Grandes empresas como a Microsoft utilizam desses conceitos em seus softwares principais. Plataformas como o pacote Office e o sistema operacional Windows, são desenvolvidas atualmente reutilizando-se de diversos componentes que foram sendo implementados pela empresa ao decorrer dos anos. A cada nova versão, grande parte dos componentes anteriores é reutilizada e inovações são acrescentadas, gerando assim novos componentes que serão reutilizados posteriormente. 

Esse processo de reutilização também torna o processo de desenvolvimento de uma empresa cada vez mais maduro, montando uma espécie de linha de montagem de software, mas é importante observar que o domínio de aplicação desses componentes acaba sendo bem restrito para alcançar tal eficiência na sua aplicação. 

Controvérsia
A principal controvérsia do fato 15 é relacionada ao desconhecimento da história da reutilização. Principalmente após a difusão do paradigma de programação orientada a objetos, muito começou a se falar sobre reutilização de código como uma grande inovação. O conceito de reutilização de código não é novo como muitos entusiastas imaginam e já existia muito antes de orientação a objetos por exemplo.

Existem muitas controvérsias entre as tentativas de explicações para o fato 16.  Enquanto alguns vêem a engenharia de software baseada em componentes como o futuro, outros são completamente céticos com relação a sua aplicação real.

O NASA's Goddard Space Flight Center [2] realizou durante anos estudos relacionado ao desenvolvimento de softwares específicos baseados em componentes. Cerca de 70% dos softwares desenvolvidos dentro do domínio de atuação do NASA-Goddard foram construídos com reutilização de componentes, um número alto, mas que não pode ser interpretado de qualquer maneira. A eficiência da reutilização de componentes nesse caso foi devido à semelhança real dos softwares. Softwares de um mesmo domínio tendem a terem restrições semelhantes, portanto a generalização eficiente dos componentes fica facilitada.

Outro motivo levantado para a possível não adoção em massa da reutilização em grande proporção, é a chamada síndrome do “Não-Inventado-Aqui” (NIH em inglês). Essa síndrome seria comum a profissionais teimosos que acreditam ser mais complicado administrar algo não criado por eles mesmos.

De uma maneira geral, não se pode afirmar que a engenharia de software baseada em componentes é boa ou ruim, para isso é necessário analisar o contexto. Devido às diferenças entre os diversos domínios, é muito complicado que a criação de componentes totalmente genéricos seja eficiente para aplicação em todos os casos, mas em casos específicos eles podem ser extremamente eficientes. Muitos autores, assim como GLASS [3], acreditam que a reutilização de código em grandes proporções não chegará a ser tão difundida e comum quanto a de pequenas proporções, mas essa visão embasa-se na sua complexidade e não na qualidade da proposta.

As controvérsias ao fato 17 são referentes às pessoas entusiastas da reutilização em grandes proporções da forma mais genérica possível, abrangendo a domínios de qualquer espécie. Essas pessoas acabam tendo esse tipo de visão por desconhecerem as diferenças entre os domínios, pois essas diferenças impossibilitam uma maior eficiência na resolução de problemas comuns a domínios distintos utilizando componentes totalmente genéricos.

Referências Bibliográfica

[1] SHARE Inc. About SHARE. Disponível em: http://www.share.org/AboutSHARE/tabid/65/Default.aspx Acesso em  10  Abr.  2010.
[2] NASA-Goddard Space Flight Center.  About the Goddard Space Flight Center. Disponível em: http://www.nasa.gov/centers/goddard/about/index.html Acesso em  10  Abr.  2010.
[3] GLASS, R. Facts and Fallacies of Software Engineering. Addison Wesley. October 2002.
[4] McBREEN, Pete. Software Craftsmanship. Boston: Addison-Wesley. Says "cross-project reuse is very hard to achieve." 2002.