A arquitetura de software é um assunto largamente discutido nos dias de hoje, principalmente pelo fato de o mesmo ser uma das principais causas de insucesso nos projetos de software (mais especificamente sendo considerada como a segunda maior causa de insucesso, logo depois da definição de requisitos). Logo, uma arquitetura consistente e bem definida se torna fundamental para que o projeto seja implementado eficientemente.
Arquitetura de software nada mais é que a definição de uma representação abstrata de comportamentos e componentes do sistema. Se um programador disser, por exemplo, que para implementar uma determinada funcionalidade ele precisará criar uma interface gráfica com uma extensão X que envia requisições através de um protocolo Y para um determinado componente ou recurso W que acessa o componente de integração ao banco de dados Z, ele estará descrevendo a arquitetura utilizada por seu sistema. Repare que isto tem muito a ver com o estilo de desenvolvimento utilizado.
Existem algumas classificações de arquitetura, como por exemplo as que irei detalhar aqui, a arquitetura de referência e a arquitetura de distribuição.
Arquitetura de Referência: é um tipo de arquitetura que possui uma terminologia unificada, com a definição consistente de padrões de componentes e seus respectivos papéis/responsabilidades. Possui como principais características o fornecimento de flexibilidade e contém um conjunto consistente das melhores práticas de mercado muitas vezes provenientes da consolidação de funcionalidades amplamente utilizadas para resolver um determinado problema em um contexto específico.
Exemplos desta arquitetura: JEE, SOA e JME.
Arquitetura de Distribuição: é mais relacionada com topologia de servidores e componentização, porém não significa necessariamente que a aplicação necessite estar separada fisicamente, mas ela deve permitir que isso aconteça caso essa separação seja necessária um dia. Por exemplo, se uma aplicação roda hoje em um único servidor no qual estão instalados o contâiner web e um servidor de e-mails ao qual esta aplicação web acessa, nada impedirá de um dia separarmos estes dois recursos em dois servidores físicos e um continue acessando o outro normalmente.
Uma arquitetura pode ser representada também por um mapa de camadas, como temos, por exemplo, representado pelo tão utilizado MVC. Uma outra boa representação, ainda mais detalhada, pode ser representado pelas seguintes 5 camadas:
CLIENTE | APRESENTAÇÃO | NEGÓCIOS | INTEGRAÇÃO | RECURSOS
O cliente pode ser representado por uma Applet ou uma página HTML, ou seja, é o que é gerado para a exibição ao usuário final.
A apresentação seria o processo de geração da página do cliente e a nossa camada de controle (ou o controller do MVC), o qual interage com a camada de visão.
A camada de negócios representa toda a implementação efetiva do negócio ao qual o sistema deve atender (as regras do sistema) e a estrutura de representação das entidades no qual o sistema manipula.
A camada de integração é onde estão os componentes que acessam os recursos externos à aplicação, como por exemplo, uma API JDBC para acesso a banco de dados.
E finalmente, a camada de recursos pode representar, por exemplo, arquivos XML, bases de dados, sistemas mainframe, servidores de e-mail, enfim, tudo o que representa interações externas ao qual o sistema depende para executar uma determinada funcionalidade.
Bom, é isto pessoal, espero ter desmistificado alguns conceitos básicos sobre a Arquitetura de Software. O próximo tema abordado tratará a respeito das capacidades de uma arquitetura.
