Durante o ciclo de vida de um software, uma coisa é certa: haverá mudanças. Como consequência dessas mudanças, temos as decisões, que precisam ser tomadas para atender aos requisitos especificados, decisões estas que devem ser cuidadosamente estudadas para não impactar negativamente na arquitetura do software, trazendo prejuízos ao desempenho, escalabilidade e outros atributos de qualidade do sistema.
Elaborar a arquitetura de um software pode ser uma tarefa árdua para muitos profissionais. Dependendo do tamanho e da missão do sistema, são milhares de linhas de código, centenas de componentes, bibliotecas de terceiros, relatórios, integração com sistemas legados, servidores de aplicações, tabelas de banco de dados, segurança de acesso, alta disponibilidade e demais elementos que aumentam a complexidade da arquitetura.
Como verificado, o desafio é grande e desenvolver um sistema sem o devido planejamento não é a melhor solução.
Se já é complicado para um arquiteto de software e sua equipe colocarem todos esses artefatos funcionando em situações normais de operação, imagine em momentos de instabilidade como excesso de usuários, falha de hardware, indisponibilidade de rede ou banco de dados, etc.
Agora, imagine como colocar um sistema semelhante em funcionamento sem planejar sua arquitetura?
Durante o desenvolvimento de um sistema o arquiteto irá se deparar com perguntas como: Qual componente deve ser utilizado para integrar com o legado?
Será que a interface de comunicação com o ERP deverá ser feita com web services ou será melhor utilizar uma API proprietária do fabricante que possui um melhor desempenho?
Há restrições legais para fazer uso de código open source? Qual será o comportamento do sistema se a conexão com o banco de dados ficar indisponível?
Perguntas como estas precisam ser respondidas para que seja definida a arquitetura do sistema.
Deste modo, o ideal é que as respostas sejam obtidas de forma consciente e racional, baseadas em boas práticas, padrões e experiência do arquiteto e da equipe, avaliando para cada decisão o risco envolvido.
Porém, as respostas que estão corretas hoje podem não mais representar a melhor escolha amanhã, pois o negócio do cliente exige mudanças frequentes. Sendo assim, como avaliar o impacto dessas mudanças dentro da atual arquitetura? A inclusão de uma nova funcionalidade poderá degradar o desempenho do sistema?
Felizmente, a busca pelas respostas de questões como estas não necessita de adivinhações ou outro tipo de inspiração que não seja o conhecimento. Para ajudar a obter essas respostas deve-se escolher um método de avaliação arquitetural e aplicá-lo em seu trabalho.
A adoção de um método não exige grandes transformações na empresa e, na maioria das vezes, sua utilização se dá de modo direto, sem dispendiosas adaptações ao modelo de negócio, e abrange qualquer tipo de sistema de diversos segmentos de mercado.
Entretanto, os métodos divergem no estilo e forma de trabalho, podendo um método ser mais detalhista e levar mais tempo na sua execução em relação a outro.
Com base nisso, neste artigo será apresentado um método que auxilia os arquitetos de software e suas equipes na avaliação arquitetural e na tomada de decisões sobre a arquitetura.
Este método foi escolhido por ser mais adequado a times que utilizam metodologias ágeis e desejam que o impacto da avaliação seja o menor possível no prazo e custo durante o desenvolvimento do software.
O que é arquitetura de software?
Todo sistema de software tem uma arquitetura. Talvez ela não seja do conhecimento de todos os envolvidos e não esteja documentada. Talvez não tenha sido planejada e tenha sido evoluída mediante diversas modificações durante o ciclo de vida do software. Mesmo assim, ainda podemos assegurar categoricamente que a afirmativa é verdadeira.
Para iniciar o entendimento sobre o que é arquitetura de software, usaremos a definição do livro Software Architecture in Practice.
Apesar disso, existem dezenas de outras definições publicadas por outros autores, mas que acabam por passar um mesmo conceito: “Arquitetura de software é a estrutura (ou estruturas) de um sistema, construída por elementos (componentes) de software, suas propriedades visíveis externamente e dos relacionamentos entre esses elementos.”.
Nessa definição, vale destacar o trecho “relacionamento entre esses elementos”, ou seja, como ocorre a interação entre as partes, pois a arquitetura precisa ser elaborada buscando o baixo acoplamento para facilitar a substituição dessas partes, quando necessário, e não acarretar em elevados custos de manutenção na reescrita de código.
Em sistemas modernos, a interação ocorre através de interfaces, o que proporciona um baixo acoplamento, visto que um componente não precisa conhecer os detalhes de implementação de outro para estabelecer uma comunicação.
P ...
