De acordo com Bosch (2000 APUD Sommerville, 2011), “a arquitetura de software é importante porque afeta o desempenho, a robustez, a distributabilidade e a manutenibilidade de um sistema”. E segundo o curso de Segurança no Desenvolvimento de Software da UniSerpro, “a definição da arquitetura de um software é uma atividade consolidada em praticamente todos os ciclos de desenvolvimento de softwares”. Entretanto, se o arquiteto de software estiver limitado a uma visão de curto prazo, restringindo-se ao cenário que lhe é apresentado pelo analista de requisitos, a manutenibilidade do sistema pode ficar comprometida.

A manutenibilidade é a característica mais fácil de ser relegada ao esquecimento, pois seu impacto não é imediato. Na primeira entrega do sistema, o desempenho será satisfatório, ele se mostrará robusto e conseguirá ser distribuído de forma adequada. Mas, a medida em que novos lançamentos de versão do sistema forem entregues, sua complexidade aumentará, junto com inevitáveis bugs. Os requisitos originais mudarão por forças maiores do que o desejo dos usuários e clientes, como a legislação e a tecnologia que suporta o sistema de software.

A manutenibilidade é uma característica vital para o sucesso de um processo ágil de desenvolvimento. Um dos princípios do Manifesto Ágil é que “mudanças nos requisitos são bem-vindas, mesmo tardiamente no desenvolvimento” pois “processos ágeis tiram vantagem das mudanças visando vantagem competitiva para o cliente”. Só é possível, entretanto, tirar vantagens de mudanças, se elas forem fáceis de fazer. E elas só serão fáceis de fazer se os princípios de manutenibilidade forem considerados na definição da arquitetura do software.

Os princípios de manutenibilidade, percebidos a partir de lições aprendidas a partir de vários projetos de software ao longo dos anos e citados extensivamente na obra de autores reconhecidos na área de arquitetura de software como Kent Beck, Martin Fowler, Robert C. Martin e Roger S. Pressman, entre outros, são os seguintes:

Configurabilidade

O comportamento de um software deve ser facilmente alterado pelo usuário ou administrador do sistema, guardadas as restrições de segurança. Condições e valores que não sejam verdades eternas não podem ser constantes codificadas de forma intrínseca.

Extensibilidade

Outro princípio do Manifesto Ágil é que “simplicidade – a arte de maximizar a quantidade de trabalho não realizado – é essencial”. O software deve evitar ao máximo a replicação de comportamentos genéricos, restringindo o trabalho de desenvolvimento à implementação de comportamentos específicos.

Acoplabilidade

Mudanças em um software podem implicar tanto na adição quanto na remoção de funcionalidades. Por isso o software deve permitir que funcionalidades sejam conectadas e desconectadas sem a necessidade de lançamento de novas versões do software.

Orientada a padrões abertos

Se um software é capaz de se comunicar com outros softwares utilizando protocolos de comunicação abertos, será desnecessário adicionar funcionalidades que já existam em serviços consumíveis por interfaces baseadas nesses padrões. Além disso, ele pode se tornar o integrador de sistemas existentes, evitando a contratação ou desenvolvimento de novos sistemas.

Independente de produtos específicos

Este princípio deveria ser decorrente do anterior, visto que seguir padrões significa observar a especificação de uma tecnologia e não uma implementação, mas é necessário ressaltar o perigo de adotar produtos que implementam funcionalidades não descritas em especificações abertas, pois isso tem como consequência o aprisionamento tecnológico. Um software não deve limitar a escolha de fornecedores, pois isso dificulta a negociação de contratos de suporte.

A não observância dos princípios acima pode comprometer a sustentabilidade de um projeto de software. Um projeto que conte com uma boa arquitetura permite maximar as receitas ao longo do tempo, pois o trabalho de desenvolvimento é reduzido pelo reaproveitamento e pela facilidade de adicionar, remover e integrar funcionalidades. E uma boa arquitetura depende do investimento em bons arquitetos de software.

O arquiteto de software deve sempre ter um olhar para o futuro. Criar uma solução de software subordinada unicamente às opções de produtos tecnológicos disponíveis no início do projeto é assinar um compromisso para um gradual aumento de custos ao longo do tempo. Nosso foco de trabalho é o cliente e precisamos criar condições para entregar as mudanças necessárias solicitadas por ele da forma mais ágil possível. O arquiteto não precisa resolver os problemas do amanhã, para os quais ainda não foi pago inclusive, mas deve ser precavido, reconhecendo que eles virão, e assim abrir caminho para que eles possam ser resolvidos.

Referências:

• Sommerville, Ian. Software Engineering. 9.ed. Addison-Wesley, 2011.
• http://www.agilemanifesto.org/iso/ptbr/principles.html

Flávio Gomes da Silva Lisboa
É bacharel em Ciência da Computação com pós-graduação em Tecnologia Java e Aplicações Corporativas usando Orientação a Objetos. Trabalha no Serpro há dez anos, após fazer carreira no Banco do Brasil até chegar à Diretoria Internacional. É engenheiro e arquiteto de software certificado pela Zend Technologies, professor da disciplina Programação Orientada a Objetos com PHP e Testes Unitários na pós-graduação da Unicesumar e autor de seis livros técnicos pela Novatec e seis sobre quadrinhos pela Loja Perse.