ARQUITETURA DE SOFTWARE Em seu livro, que constitui um referencial sobre o assunto, Shaw e Garlan discutem arquitetura de software da seguinte maneira: Desde quando o primeiro programa foi dividido em módulos, os sistemas de software passaram a ter arquiteturas, e os programadores têm sido responsáveis pelas interações entre os módulos e as propriedades globais da montagem. Historicamente, as arquiteturas eram implícitas sistemas herdados do passado. Desenvolvedores de software têm adotado um ou mais padrões arquiteturais como estratégias para a organização de sistemas, mas eles usam esses padrões informalmente e não têm meio para torná-los explícitos no sistema resultante. Já Grochow define arquitetura de software como um arcabouço abrangente que descreve sua forma e estrutura seus componentes e como eles se articulam. Arquitetura Quando discutimos a arquitetura de um edifício, muitos atributos diferentes vêm à mente. No nível mais simplista, consideramos a forma geral da estrutura física, mas na realidade arquitetura é muito mais. É a maneira pela qual os vários componentes do edifício são integrados para formar um todo coeso. É o modo pelo qual o edifício se ajusta a seu ambiente e se mistura com os outros edifícios da vizinhança. É o grau com que o edifício alcança sua finalidade declarada e satisfaz às necessidades do seu proprietário. É o sentido estético da estrutura o impacto visual do edifício e o modo pelo qual texturas, cores e materiais são combinados para criar a fachada externa e o ambiente de convivência interno. São pequenos detalhes o projeto de dispositivos de iluminação, de piso, colocação de ornatos de paredes, a lista é quase sem fim. E por fim, é arte.
ARQUITETURA DE SOFTWARE Pela definição de Bass, Clements e Kasman: A arquitetura de software de um programa ou sistema computacional é a estrutura ou estruturas do sistema que abrange os componentes de software, as propriedades externamente visíveis desses componentes e as relações entre eles. POR QUE A ARQUITETURA É IMPORTANTE? Representações da arquitetura de software constituem um facilitador da comunicação entre todas as partes interessadas (envolvidas) no desenvolvimento de um sistema baseado em computador. A arquitetura destaca decisões iniciais de projeto que terão um impacto profundo em todo o trabalho de engenharia de software que se segue e, igualmente importante, no sucesso final do sistema como uma entidade operacional. A arquitetura constitui um modelo relativamente pequeno, intelectualmente inteligível de como o sistema é estruturado e como seus componentes trabalham em conjunto. ESTILOS E PADRÕES ARQUITETURAIS Um software construído para sistemas baseados em computador exibe um ou vários estilos arquiteturais. Cada estilo descreve uma categoria de sistemas que abrange (1) um conjunto de componentes (um banco de dados, módulos computacionais, etc.) que realizam a função que é requisito do sitema; (2) um conjunto de conectores que possibilita comunicação, coordenação e cooperação entre os componentes; (3) restrições que definem como os componentes podem ser integrados para formar o sistema; e (4) modelos semânticos que possibilitam ao projetista entender as propriedades gerais de um sistema pela análise das propriedades conhecidas de duas partes constitutivas.
Um estilo arquitetural é uma transformação imposta sobre o projeto de um sistema completo. O objetivo é estabelecer uma estrutura para todos os componentes do sistema. TAXONOMIA DE ESTILOS ARQUITETURAIS Apesar de milhões de sistemas baseados em computador terem sido criados ao longo dos últimos 50 anos, a grande maioria pode ser categorizada em um dos relativamente poucos estilos arquiteturais: ARQUITETURA CENTRADA EM DADOS Um depósito de dados (por exemplo um arquivo ou banco de dados) fica no centro dessa arquitetura e dá acesso frequentemente a outros componentes que atualizam, adicionam, retiram ou modificam de outra forma os dados contidos no depósito. Neste estilo arquitetural, o software cliente tem acesso a um repositório central. Em alguns casos, o repositório central de dados é passivo, isto é, o software cliente tem acesso a dados independentemente de quaisquer modificações nos dados ou nas ações dos outros softwares clientes. Uma variante desse estilo transforma o repositório em um quadro-negro. Arquiteturas centradas em dados promovem integrabilidade. Componentes existentes podem ser modificados e novos componentes clientes podem ser adicionados à arquitetura sem preocupação com outros clientes (porque os componentes clientes operam independentemente). ARQUITETURA DE FLUXO DE DADOS Essa arquitetura é aplicada quando dados de entrada devem ser transformados, por meio de uma série de componentes computacionais ou manipulativos, em dados de saída. Uma estrutura tubo e filtro tem um conjunto de componentes, chamados de filtros, conectados por tubos que transmitem dados de um componente para o próximo. Cada filtro trabalha independentemente dos componentes afluentes e efluentes, e é projetado para esperar entrada de dados de uma certa forma e produzir dados de saída (para o filtro seguinte) de um modo específico. No entanto, o filtro não exige conhecimento do trabalho dos filtros vizinhos.
ARQUITETURA DE CHAMADA E RETORNO Esse estilo arquitetural permite ao projetista de software conseguir uma estrutura de programa relativamente fácil de modificar e ampliar. Dois subestilos existem nessa categoria: Arquiteturas de programa principal/sub-programa. Esta estrutura básica de programa decompõe a função em uma hierarquia de controle em que um programa principal aciona um certo número de componentes de programa, que por sua vez, invocam outros componentes. Arquiteturas de chamada de procedimentos remotos. Os componentes de uma arquitetura de programa principal / subprogramas são distribuídos em vários computadores de uma rede ARQUITETURA ORIENTADA A OBJETOS Os componentes de um sistema encapsulam os dados e as operações que devem ser aplicadas para manipular os dados. A comunicação e a coordenação entre componentes são obtidas por meio de passagem de mensagens. ARQUITETURA EM CAMADAS Um certo número de camadas diferentes é definido, cada uma realizando operações que se tornam progressivamente mais próximas do conjunto de instruções de máquina. Na camada exterior, os componentes servem as operações da interface com o usuário. Na camada mais interna os componentes realizam a interface com o sistema operacional. As camadas intermediárias fornecem serviços utilitários e funções do software de aplicação. CONCLUSÕES Depois que a engenharia de requisitos descobre as características e restrições do sistema a ser construído, o estilo arquitetural, ou conjunto de estilos, que melhor se encaixa nessas características e restrições, pode ser escolhido. Em muitos casos, mais de um estilo pode ser adequado e alternativas poderiam ser projetadas e avaliadas. Por exemplo, um estilo em camadas (adequado à maioria dos sistemas) pode ser combinado com uma arquitetura centrada em dados em muitas aplicações de banco de dados.
Bibliografia: Pressman, Roger S. Engenharia de Software / Roger S. Pressman 6. Ed. São Paulo: McGraw-Hill, 2006.