Reúso de software
A engenharia de software baseada em reúso é uma estratégia da engenharia de software em que o processo de desenvolvimento é orientado para o reúso de softwares existentes. Apesar de o reúso ter sido proposto como uma estratégia de desenvolvimento há mais de 40 anos (McILROY, 1968), só em 2000 o ‘desenvolvimento com reúso’ se tornou a norma para novos sistemas de negócios. A mudança para o desenvolvimento baseado em reúso foi uma resposta às exigências de menores custos de produção e manutenção de software, entregas mais rápidas de sistemas e softwares de maior qualidade. Cada vez mais empresas consideram o software como um ativo valioso. O reúso tem sido promovido para aumentar o retorno sobre os investimentos em software.
A disponibilidade de softwares reusáveis tem aumentado significativamente. O movimento open source significa que existe uma enorme base de código reusável disponível a baixos custos. Isso pode dar-se na forma de bibliotecas de programas ou aplicações inteiras. Existem muitos sistemas de aplicação de domínios específicos disponíveis, os quais podem ser customizados e adaptados às necessidades de uma empresa específica. Algumas grandes empresas fornecem uma variedade de componentes reusáveis para seus clientes. Padrões, como os de web service, tornaram mais fácil o desenvolvimento de serviços gerais e reúso destes em uma variedade de aplicações.
A engenharia de software baseada em reúso é uma abordagem de desenvolvimento que tenta maximizar o reúso de softwares existentes. As unidades de software reusadas podem ser de tamanhos radicalmente diferentes. Por exemplo:
1. Reúso de sistema de aplicação. A totalidade de um sistema de aplicação pode ser reusada sem alterações em outros sistemas ou pela configuração da aplicação para diferentes clientes. Como alternativa, podem ser desenvolvidas famílias de aplicações com uma arquitetura comum, mas adaptadas para clientes específicos. Ainda neste capítulo, eu trato do reúso de sistemas de aplicação.
2. Reúso de componentes. Os componentes de uma aplicação, variando em tamanho desde subsistemas até objetos únicos, podem ser reusados. Por exemplo, um sistema de identificação de padrões desenvolvido como parte de um sistema de processamento de textos pode ser reusado em um sistema de gerenciamento de banco de dados. Trato de reúso de componentes nos capítulos 17 e 19.
3. Reúso de objetos e funções. Componentes de software que implementam uma única função, como uma função matemática ou uma classe de objeto, podem ser reusados. Essa forma de reúso, baseada em bibliotecas-padrão, tem sido comum nos últimos 40 anos. Muitas bibliotecas de funções e classes estão disponíveis gratuitamente. Você reusa as classes e funções nessas bibliotecas, ligando-as com o código da aplicação recém-desenvolvido. Essa é uma abordagem particularmente eficaz em áreas como algoritmos e gráficos matemáticos, em que o conhecimento especializado é necessário para o desenvolvimento de funções e objetos eficientes.
Os componentes e os sistemas de software são entidades potencialmente reusáveis, mas, algumas vezes, sua natureza específica significa que é caro modificá-los para uma nova situação. Uma forma complementar de reúso é o ‘reúso de conceito’, em que, em vez de reusar um componente de software, você reusa uma ideia, uma forma, um trabalho ou um algoritmo. O conceito reusado é representado em uma notação abstrata (por exemplo, um modelo de sistema), que inclui detalhes de implementação. Pode, portanto, ser configurado e adaptado para uma série de situações. O conceito de reúso pode ser incorporado em abordagens como padrões de projeto (discutidos no Capítulo 7), produtos configuráveis de sistema e geradores de programa. Quando conceitos são reusados, o processo de reúso inclui atividades nas quais os conceitos abstratos são instanciados para criar componentes reusáveis executáveis.
Uma vantagem óbvia do reúso de software é a redução dos custos globais de desenvolvimento. Menos componentes de software precisam ser especificados, concebidos, implementados e validados. No entanto, a redução de custos é apenas uma das vantagens do reúso. Na Tabela 16.1, listei outras vantagens do reúso de ativos de software.
Contudo, há custos e problemas associados ao reúso (Tabela 16.2). Existe um custo significativo associado ao processo de compreender se, em determinada situação, um componente é adequado para o reúso, e em testar esse componente para garantia de sua confiança. Esses custos adicionais significam que as reduções nos custos de desenvolvimento por meio de reúso podem ser menores do que o previsto.
Como discutido no Capítulo 2, os processos de desenvolvimento de software precisam ser adaptados para o reúso. Em particular, é necessário um estágio de refinamento dos requisitos em que os requisitos de sistema são modificados para refletir o software reusável que esteja disponível. Os estágios de projeto e implementação de sistema também podem incluir atividades explícitas para procurar e avaliar componentes candidatos ao reúso.
O reúso de software é mais eficaz quando está previsto como parte de um programa de reúso de toda a organização. Um programa de reúso envolve a criação de ativos reusáveis e a adaptação de processos de desenvolvimento para incorporar esses ativos no novo software. A importância do reúso de planejamento tem sido reconhecida por muitos anos no Japão (MATSUMOTO, 1984), onde o reúso é parte integrante da abordagem japonesa ‘fábrica’ para desenvolvimento de software (CUSAMANO, 1989). Empresas como a Hewlett-Packard também foram muito bem-sucedidas em seus programas de reúso (GRISS e WOSSER, 1995), e sua experiência foi documentada em um livro, por Jacobson e colegas. (1997).
O panorama de reúso
Ao longo dos últimos vinte anos, muitas técnicas foram desenvolvidas para oferecer suporte a reúso de software. Essas técnicas exploram os fatos de os sistemas, no mesmo domínio de aplicação, serem semelhantes e terem potencial para reúso. O reúso é possível em diferentes níveis, desde funções simples até aplicações completas, e normas para componentes reusáveis facilitam o reúso. A Figura 16.1 define várias possíveis maneiras de implementação de reúso de software. Cada uma será brevemente descrita na Tabela 16.3.
Dado esse conjunto de técnicas para reúso, a questão essencial é ’qual a técnica mais apropriada para se usar em uma determinada situação?’. Obviamente, isso depende dos requisitos para o sistema em desenvolvimento, a tecnologia e os ativos reusáveis disponíveis e a expertise da equipe de desenvolvimento. Fatores-chave que devem ser considerados ao planejar o reúso são:
1. O cronograma de desenvolvimento para o software. Caso o software necessite ser desenvolvido rapidamente, você deve tentar reusar sistemas de prateleira em vez de componentes individuais. Estes são ativos de alta granularidade reusáveis. Embora eles não se ajustem perfeitamente aos requisitos, essa abordagem minimiza a quantidade de desenvolvimento necessária.
2. A expectativa de duração do software. Caso você esteja desenvolvendo um sistema de vida longa, você deve centrar-se na manutenção de sistema. Você não deve apenas pensar nos benefícios imediatos do reúso, mas também nas implicações a longo prazo.
Ao longo de sua vida, você terá de adaptar o sistema aos novos requisitos, o que significa fazer alterações em partes do sistema. Caso você não tenha acesso ao código-fonte, você pode preferir evitar componentes de prateleira e sistemas de fornecedores externos; fornecedores podem não ser capazes de continuar dando suporte ao software reusado.
3. O conhecimento, as habilidades e a experiência do desenvolvimento da equipe. Todas as tecnologias de reúso são bastante complexas, e é necessário muito tempo para compreendê-las e usá-las eficazmente. Portanto, se a equipe de desenvolvimento tem habilidades em uma área específica, provavelmente essa é a área em que você deve se concentrar.
4. A importância do software e seus requisitos não funcionais. Para um sistema crítico que precisa ser certificado por um regulador externo, talvez seja necessário criar um caso de confiança para o sistema (discutido no Capítulo 15). Isso é difícil, caso você não tenha acesso ao código-fonte do software. Se o software tiver requisitos de desempenho rigorosos, pode ser impossível usar estratégias como o reúso baseado em geradores, em que você gera o código a partir de uma representação específica de domínio reusável de um sistema. Esses sistemas geralmente geram códigos relativamente ineficientes.
5. O domínio da aplicação. Em alguns domínios de aplicação, como manufatura e sistemas médicos de informação, existem diversos produtos genéricos que podem ser reusados, sendo configurados a uma situação local. Se estiver trabalhando em tal domínio, você sempre deve considerar essa opção.
6. A plataforma em que o sistema será executado. Alguns modelos de componentes, como .NET, são específicos para plataformas Microsoft. Da mesma forma, sistemas de aplicação genéricos podem ser específicos de determinada plataforma e você só poderá reusá-los se seu sistema for projetado para a mesma plataforma.
A gama de técnicas de reúso disponível é tal que, na maioria das situações, existe a possibilidade de algum reúso de software. Se o reúso não é atingido, muitas vezes é uma questão de gerenciamento e não um problema técnico. Os gerentes podem estar dispostos a comprometer seus requisitos para permitir que componentes reusáveis sejam usados. Eles podem não compreender os riscos associados ao reúso tão bem quanto compreendem os riscos de desenvolvimento original. Embora os riscos de desenvolvimento de um novo software possam ser maiores, alguns gerentes podem preferir esses riscos por já serem conhecidos.
Extraído do livro Engenharia de Software, Ian Sommerville, 9 Edição, Pearson (pág. 296–300).
