Reuso: Conceitos, Justificativas e Desculpas

Continuação de "Gerenciando Ativos de Software".

Obs importante: por se tratar de um compilação de idéias que estou realizando em "run time", a seqüência e conteúdo dos artigos desta série podem ser consideravelmente modificados em sua versão final, um PDF que espero publicar até o dia 11/jan/2007. Nem todas as revisões se refletirão no blog. Optei por falar sobre REUSO nesta 2ª parte por se tratar do grande objetivo da série. O capítulo seguinte, que deve ser publicado na próxima semana, falará sobre Ativos de Software de uma maneira mais específica. Inclusive (re)apresentando* a proposta RAS (Reusable Assets Specification) do OMG e fazendo uma relação da especificação com os elementos que compõem uma SOA.

* A primeira vez que publiquei um material sobre RAS foi em 2004. Está no artigo "Gestão Estratégica de Ativos de Software" [PDF]. Desta vez espero ser um tanto mais específico.

Reuso é a prática sistemática de se desenvolver software a partir de um conjunto de 'blocos de construção', de forma que as similaridades dos requisitos e/ou da arquitetura entre as aplicações possa ser explorada para que sejam alcançados benefícios substanciais na produtividade, qualidade e na performance do negócio.[1]

O texto acima, transcrito diretamente de "Practical Software Reuse" [1], é uma das mais recentes (re)definições do termo Reuso de Software. É forte porque desconsidera aquilo que Steve McConnell chamou de "reuso oportunista" [2]. O reuso oportunista/casual parece ser a única alternativa oferecida na versão original do RUP, por exemplo [3]. A definição acima também é completa, porque encerra em uma única frase aquilo que seus autores consideram as 4 características-chave do reuso:

• É uma prática sistemática para o desenvolvimento de software;
• Emprega um conjunto de 'blocos de construção' (artefatos reutilizáveis);
• Explora similaridades dos requisitos e/ou da arquitetura entre as aplicações; e
• Oferece benefícios substanciais para a produtividade, qualidade e performance do negócio.

Antes de uma análise de cada uma das características listadas, é interessante confrontar a definição acima com o Reuso prometido pela proposta SOA. O artigo anterior citou uma pesquisa [4] que diz que as empresas esperam reutilizar apenas 30% dos serviços implementados. É interessante notar que trata-se de um tipo de reuso relativamente diferente daquele apresentado acima.

Assim como em propostas anteriores, notadamente Orientação a Objetos (OO) e Componentização, o reuso em uma SOA pode acontecer em dois momentos muito distintos:

• Em Tempo de Construção, realizado diretamente por um analista ou programador; e
• Em Tempo de Execução, realizado por outro ativo.

O reuso em tempo de construção é parte central na implementação de uma SOA. Todos os serviços, particularmente aqueles que representam entidades ou processos de negócios, devem encapsular um ativo existente, independente da sua tecnologia. Uma SOA propõe dar sobrevida para todos os sistemas legados de uma organização. Por isso não faria muito sentido falar de níveis de reuso em tempo de construção de uma SOA.

A pesquisa, encomendada pela Bea [4], não fala explicitamente mas leva a entender que se trata do reuso em tempo de execução. De qualquer forma, a meta (30% de reuso) parece bastante modesta. Os 'blocos de construção' em uma SOA são os seus serviços que, conceitualmente, podem ser categorizados da seguinte maneira:

• Básicos: representam entidades (clientes, produtos) ou pequenas atividades (validação de crédito, verificação de disponibilidade em estoque);
• Intermediários: únicos que mantêm relação direta com a parte tecnológica da arquitetura (fornecendo pontes, conversores etc);
• Processos: representam diretamente atividades ou processos de negócios (vendas, baixa de duplicatas etc).

Espera-se que um serviço em uma SOA seja único na função ou conjunto de dados que oferece. Não faz sentido, por exemplo, que existam dois serviços representando a entidade Clientes. Por isso parece estranha a expectativa de que apenas 1/3 dos serviços seja reutilizado por outros em tempo de execução. De qualquer maneira, os dados disponíveis sobre implementações SOA existentes ou em andamento ainda são raros e vagos.

Experiências com a adoção do reuso sistemático anteriores à SOA mostram que é factível a colocação de metas mais ambiciosas. Alguns casos reportam níveis de reuso entre 50% e 95%! [1] Mais relevantes que as taxas de reutilização são os benefícios gerados diretamente por ela: ganhos de produtividade de 58% por ano em um período de 4 anos [2]; redução de 84% nos custos de desenvolvimento [1]; redução de 70% no tempo de desenvolvimento [1]. Um programa SOA não deve alcançar números tão altos, mas eles devem servir, no mínimo, como uma boa referência para os projetos SOA.

===

[ Continua ]

===

1. Practical Software Reuse
   Michel Ezran, Maurizio Moricio e Colin Tully
   Springer (2002).
   
2. Rapid Development
   Steve McConnell
   Microsoft Press (1996).
   
3. The Rational Unified Process - An Introduction (Second Edition)
   Philippe Kruchten
   Addison-Wesley (2000).
4. SOA Research - SOA Justification (PDF - Requer registro)
   GCR Custom Research
   Patrocinada pela Bea Systems.
   

Marcadores: administração_de_ativos, gerenciamento_de_ativos, mps, qualidade, reuso, spi