Básico 4 - A Reutilização de Software
A natureza humana é surpreendente em todos os seus aspectos. Uma das habilidades mais notáveis é, sem dúvida, a nossa capacidade de observar e filtrar tudo aquilo que vemos e sentimos, separando e aprendendo o que é útil, bom ou bonito daquilo que parece ser inútil, ruim ou feio no contexto da experiência vivida. Muitos engenheiros, por exemplo, criam soluções arquitetônicas baseadas em formas vistas na natureza. Outro exemplo famoso foi a invenção dos primeiros aviões inspirados no vôo das aves. Ainda, mais recentemente, muitos robôs estão sendo baseados na forma humana como solução para os problemas de locomoção e outras habilidades.
Esse mesmo princípio também se aplica às nossas atividades diárias. Quando observamos uma determinada moda surgindo ou vemos alguém com um novo penteado que não tínhamos idealizado antes, temos uma tendência natural em avaliar e, ao mesmo tempo, discernir se aquilo poderia cair bem ou não em nós.
Mas, o que tudo isso tem a ver com software? Por incrível que pareça, muita coisa. Ao lermos o código escrito por outra pessoa, por exemplo, podemos notar algum estilo diferente que é melhor do que aquele que costumávamos usar. Além disso, quando construímos um diagrama, precisamos reutilizar alguma notação criada por alguém para que todos possam se entender. Embora no contexto social a imitação ou reutilização de idéias possa parecer falta de originalidade, nas atividades de trabalho isso pode resultar em um aumento significativo na produtividade e uma redução considerável no tempo de execução das tarefas.
As primeiras idéias sobre reutilização de software são do ano de 1968, quando Doug McIlroy mostrou a sua motivação por software que funcionasse como "Circuitos Integrados" (CI) e que estes pudessem ser fabricados em massa. Além disso, ele examinou os tipos de variabilidade necessárias aos CIs e os possíveis tipos de CIs que poderiam ser padronizados desta forma [McIlroy1968]. A visão de McIlroy era baseada na indústria de componentes eletrônicos que podiam ser selecionados em catálogos de diferentes fabricantes, apresentando propriedades configuráveis e diferentes níveis de confiabilidade.
Apesar de os primeiros conceitos sobre reutilização de software terem sido idealizados no final da década de 1960, eles não receberam muita atenção da indústria e das universidades até os anos 80, quando a complexidade dos sistemas começou a aumentar e as empresas foram forçadas a procurar por métodos mais eficientes de construção de sistemas para refletir as necessidades do mercado.
A vantagem da reutilização de software está no potencial que ela exibe para se desenvolver software mais rápido, melhor e mais barato. Para que esse potencial seja o maior possível, o reuso não deve se limitar apenas ao código das aplicações, mas também aos requisitos, especificações, projetos, testes, e todos os outros elementos produzidos durante as fases de desenvolvimento [Sametinger1997].
Inicialmente, a reutilização de software era uma prática sem muita padronização. Ela deixava nas mãos dos desenvolvedores a responsabilidade de fornecer e recuperar possíveis artefatos ao longo dos projetos, além de fornecer pouco apoio e motivação para isso. Essa forma de trabalho era inadequada porque as pessoas perdiam muito tempo tentando procurar e entender o funcionamento de cada pedaço candidato e, ainda assim, corriam o risco de introduzir novos erros no sistema.
Outros problemas vinham dos aspectos não-técnicos dessa atividade, os quais devem ser igualmente apoiados pelas empresas. Por exemplo, o uso de recompensas para cada artefato reutilizado pode ajudar na implantação de um programa de reuso. Um outro ponto importante é o fato dos desenvolvedores terem muita boa vontade para construir software reutilizável, mas, ao mesmo tempo, possuírem igualmente um certa dificuldade em aceitar e confiar no trabalho feito por terceiros [Sametinger1997] [Endres+2003].
Essa resistência para reutilizar software desenvolvido por terceiros é conhecida como a sindrome do "Não-Inventado-Aqui" (Not-Invented-Here syndrome, em inglês).
O surgimento das tecnologias orientadas a objetos constituiu um marco essencial na reutilização de software. Isso porque elas conseguiram ampliar esse escopo e permitiram o reaproveitamento de classes de análise, projeto e implementação em diferentes projetos de software. Com isso, elas tornaram as antigas bibliotecas de funções obsoletas e proporcionaram o desenvolvimento de bibliotecas de classes, as quais modelam com mais coesão as regras de negócio dos sistemas [McClure1997]. Mais tarde, novos passos foram dados com a criação de frameworks reutilizáveis, que são estruturas de classes montadas e preparadas para um conjunto específico de problemas [Fayad+1999] [D'Souza+1999].
Um outro ramo que surgiu no final da década de 1980 e que ganhou atenção de diversas áreas da informática foi a computação distribuída de objetos, também chamada de Distributed Object Computing (DOC). A influência dessa tecnologia sobre a reutilização de software é muito significativa, pois técnicas de orientação a objetos são aplicadas com a finalidade de se distribuir serviços reutilizáveis e aplicações de forma eficiente, flexível e robusta em ambientes diferentes e normalmente heterogêneos.
Essa iniciativa surgiu quando o Object Management Group (OMG) elaborou uma especificação aberta sobre mediadores (middleware) para a distribuição de sistemas e desenvolveu o Common Object Request Broker Architecture (CORBA) [OMG2006]. O objetivo pretendido era permitir que diferentes empresas pudessem implementar a especificação e oferecer mediadores reutilizáveis que apoiassem a distribuição de objetos em aplicações de software. Com isso, elas poderiam se comunicar pela rede sem se preocupar com a localização dos objetos, linguagens de programação, sistemas operacionais, protocolos de comunicação e plataformas de hardware.
O advento da orientação a objetos e da computação distribuída foi decisivo para a definição do conceito de componente, que até então era tido como qualquer artefato de software que pudesse ser reutilizado. A introdução de interfaces bem definidas somadas ao conceito de encapsulamento trouxe essa idéia de componente para uma realidade mais próxima daquela vista em componentes de outras indústrias.
A invenção dos controles OLE (Object Linking and Embedding) pela Microsoft em 1991 desencadeou o início de uma das mais importantes tecnologias conhecidas para o desenvolvimento de software baseado em componentes: o COM (Component Object Model). Inicialmente, esses controles OLE apresentaram limitações quanto à dificuldade de programação e robustez que forçaram a Microsoft a buscar novos caminhos.
A subseqüente criação de controles ActiveX baseados no modelo COM foram mais bem sucedidos e contribuíram para o avanço da plataforma Windows e suas linguagens de programação RAD, como o Visual Basic e o Delphi. O aparecimento de novas necessidades do mercado fez a Microsoft estender o seu modelo e criar uma família de soluções que incluem o COM Distribuído (DCOM) e o COM+ [COM2006]. Essas soluções acrescentam suporte a serviços como, por exemplo, distribuição de processamento pela rede (DCOM), transações, segurança, eventos assíncronos, filas de mensagens, etc.
A plataforma java também teve a sua vez na especificação de arquiteturas de componentes. Em 1996, a Sun Microsystems lançou a especificação JavaBeans [Javabeans2006] voltada para o desenvolvimento padronizado de componentes reutilizáveis. Alguns anos mais tarde, em 1999, a evolução da tecnologia de componentes atingiu um novo estágio com o lançamento do Enterprise JavaBeans (EJB), um modelo de componentes focado no desenvolvimento e implantação de aplicações orientadas a negócio. Dentre as contribuições dessa tecnologia, temos a possibilidade de desenvolver aplicações distribuídas, robustas e reutilizáveis, podendo, ainda, aproveitar o suporte ao gerenciamento de transações e multithreading [EJB2006].
A transformação que todas essas tecnologias e mudanças causaram no desenvolvimento de software nas últimas décadas exigiram, além de outras coisas, a reformulação das metodologias e processos de reutilização de software. Abordagens específicas para componentes precisaram ser criadas para orientar as diferentes fases do ciclo de vida dos sistemas desenvolvidos. Dentre as mais conhecidas, podemos citar o Catalysis [D'Souza+1999], o UML Components [Cheesman+2001], o Kobra [Atkinson+2001] e a Fábrica de Componentes de Negócio (Business Component Factory) [Herzum+2000].
Referências
[McIlroy1968] Doug McIlroy. Mass Produced Software Components. Proceedings of the NATO Software Engineering Conference. Outubro, 1968.
[Sametinger1997] Johannes Sametinger. Software Engineering with Reusable Components. Springer-Verlag 1997.
[Endres+2003] Albert Endres e Dieter Rombach. A Handbook of Software and Systems Engineering - Empirical Observations, Laws and Theories. Addison-Wesley 2003.
[McClure1997] Carma McClure. Software Reuse Techniques: Adding Reuse to the System Development Process. Prentice Hall 1997.
[Fayad+1999] Mohamed Fayad, Douglas Schmidt, e Ralph Johnson. Implementing Application Frameworks: Object-Oriented Frameworks at Work. John Wiley & Sons 1999.
[D'Souza+1999] Desmond D'Souza e Alan Wills. Objects, Components, and Frameworks with UML - The Catalysis Approach. Addison-Wesley 1999.
[OMG2006] Object Management Group. http://www.omg.org.
[COM2006] COM: Component Object Model Technologies. http://www.microsoft.com/com.
[Javabeans2006] JavaBeans. http://java.sun.com/products/javabeans/index.jsp.
[EJB2005] Java 2 Platform, Enterprise Edition (J2EE). http://java.sun.com/j2ee/index.jsp.
[Cheesman+2001] John Cheesman e John Daniels. UML Components: A Simple Process for Specifying Component-Based Software. Addison-Wesley 2001.
[Atkinson+2001] Colin Atkinson, Joachim Bayer, Christian Bunse, Erik Kamsties, Oliver Laitenberger, Roland Laqua, Dirk Muthig, Barbara Paech, Jürgen Wüst, e Jörg Zettel. Component-based Product Line Engineering with UML. Addison Wesley Professional 2001.
[Herzum+2000] Peter Herzum e Oliver Sims. Business Component Factory: A Comprehensive Overview of Component-Based Development for the Enterprise. John Wiley & Sons (OMG Press) 2000.