Arquitetura

Arquitetura de Software

Arquitetura de Software é a area de produção de software preocupada com o plano da construção: a planta. O termo remete a semelhanças com a arquitetura tradicional de edificações. A ideia não é controlar o processo de construção do software mas guiar a posição dos alicerces sobre as quais o software será construido.

Arquitetura de Software é baseada em definir e reutilizar componentes. Quando falamos de “uma arquitetura” estamos falando de um conjunto especifico desses componentes para utilizar em determinada aplicação. Definir estes componentes e a sua oganização é uma das tarefas mais importantes do arquiteto pois são esses componentes que sedimentam como o software será criado. Esta é a semelhança com a arquitetura de edificações onde a planta define os alicerces da edificação. O edificio não poderá nunca ir além dos seus alicerces. Da mesma forma um software não pode ir além dos componentes da sua arquitetura.

Arquitetura de Software é uma daquelas disciplinas que podemos discutir sem entrar muito no detalhes da programação, mas nos obriga a entrar em detalhes das tecnologias, plataformas e paradigmas utilizados nessa programação.

Este é o primeiro de uma série de artigos sobre as várias arquiteturas. Começaremos por descobrir algums componentes básicos da arquitura e algums objetivos principais da sua construção. Em outros artigos analizaremos cenários especificos e quais arquiteturas são relevantes para eles.

O cubo

Antes de começar é importante ter uma ideia do que trata a arquitetura de um software. O que estamos escolhendo e porquê temos que escolher. O melhor exemplo que encontrei para explicar isso é o cubo apresentado pela metadologia SunTone^[1] desenvolvida pela Sun.

Ilustração 1:O cubo da metodologia SunTone

Embora esta metodologia é especialmente desenhada para sistema web o cubo nos ajuda a entender os diferentes aspectos da arquitetura de um projeto. Como se pode depreender da figura existem três aspectos ortogonais e independentes cujos “cruzamentos” defines as escolhas que temos que fazer.

Não estou endossando esta metodologia em nenhum ponto, estou apenas utilizando o cubo como um exemplo de uma representação visual dos três aspectos que formam uma arquitetura: Plataformas , Qualidades e Camadas

Plataformas: Alicerce físico

O primeiro é a alicerce fisico. Tal como na construção de edificações a qualidade do solo é importantissima à construção. Sem um solo que suporte a construção não ha como a construir. Em software o solo é o hardware: a máquina, ou máquinas, em que o software irá correr.
Hoje em dia a quantidade de máquinas disponiveis para se correr software são bastante diversificadas: celulares, PDA , settop boxes, laptops, desktops, mainframes… Além do hardware temos que pensar nas plataformas que funcionam directamente acima dele e que mediam o fluxo da informação entre o hardware e o softeare. Estas plataformas vão desde do Sistema Operacional(Plataforma Inferiror) a middlewares (Plataforma Superior) e às API directamente utilizadas na constução da aplicação (Plataforma Virtual). Estes cinco componentes sedimentam a construção da aplicação.

Estes componentes da arquitura formam uma pilha tal como as várias camadas de solo e por isso, o seu conjunto é normalmente chamadas de “stack” (pilha). O stack de componentes físicos pode limitar a utilização da aplicação em formas imprevistas ou indesejáveis. Por exemplo, uma aplicação construida com C++ (Plataforma Superior)e compilada para funcionar no sistema operativo Linux não funcionará, sem ajustes, no sistema operativo Windows. Já utilizando uma plataforma como Java este problema não existirá.

Qualidades

Quando um edificação é construida ela tem um objetivo maior. Por exemplo, uma ponte não é apenas um pedaço de cimento, é uma ligação entre duas margens. É um novo caminho que trará desenvolvimento para as duas regiões ligadas. A ponte provê um serviço. O mesmo é válido para software. A aplicação serve um objetivo maior. Para isso ela tem que ter qualidades que garantem esse serviço conforme requisitos próprios dela. Estas qualidades são várias mas dividem-se em quatro grupos: Manifestas, Operacionais , Evolutivas e Desenvolvimento. As manifestas afetam a interação do usuário como o sistema ( Segurança , Disponibilidade, Ergonomia, …) . As operacionais afetam o funcionamento do sistema em si (Escalabilidade, Consumo de Memória, Tempo de Processamento…). As qualidades de desenvolvimento refletem custos (Facilidade de Manutenção) e as evolutivas são relacionadas a como o sistema está aberto a receber mais responsabilidades/funcionalidades após algum tempo de uso.

Este componentes da arquitura não formam uma pilha. São objetivos que a aplicação tem. A arquitetura de uma aplicação feita para funcionar durante 1 mês com 10 usuários é diferente de uma feita para funcionar 10 anos com 10 usuários, e estas diferentes de uma para funcionar durante 6 meses com 10 milhões de usuários.

Frequentemente os objetivos interagem entre si e muitas vezes têm que ser feitos sacrificios de alguma qualidade em deterimento de outra (trade-off).

Andares : Funcionalidade

O alicerce lógico define o fluxo de informação que altera o estado da aplicação. Essa alteração é feita pelo exterior ou automáticamente no interior conforme regras. O cliente é a parte da aplicação que recebe estimulos do exterior e com que o usuário interage diretamente. Esses estimulos irão ser interpretados pela Apresentação que os transforma em invocações de processos que correm no Dominio. Por outro lado, o Dominio necessita de informações que obtêm de Recursos. Algumas vezes esses recursos se encontram num formato diferente daquele que a aplicação necessita. Dai a necessidade de uma Integração.

Este componentes da arquitura formam uma pilha lógica. A sua implementação em código pode tomar certos atalhos para aumentar as qualidades ( por exemplo, para diminuir consumo de memória ou tempo de processamento)

Distribuição

Um dos paradigmas do funcionamento e organização de aplicações modernas é a distribuição. Em uma era onde o custo das máquinas é reduzido é interessante que o processamento seja dividido entre várias máquinas “menos-poderosas” do que concentrado em uma máquina única e “super-poderosa”. Esta ideia ganhou destaque na era da internet com sistema sendo distribuidos a todo o mundo sem custos, mas já existia na arquitura do tipo cliente-servidor dos anos pré-internet.

A distribuição implica em que a aplicação não tem a preservação do seu estado e/ou o seu processamento acontecendo numa única máquina ou melhor, num único stack físico. Ela afeta não só a quantidade e tipo dos stack físicos, mas também a distribuição das funcionalidade. As qualidades são mais omnipresentes, mas para cada stack físico existem diferentes trade-offs a serem feitos.

A distribuição causa a separação dos componentes em três grupos: andares, nodos e camadas.

Nodo

Os nodos (tiers) representam diferentes stack físicos de plaformas. Eles representam unidades distribuidas de processamento compostas por seu hardware , sistema operacional e plataforma superior especificos. A plataforma da aplicação é diferente para cada um dos nodos conforme o objetivo que eles cumprem na arquitetura.

Os nodos estão directamente relacionados com mecanismos de comunicação e protocolos assim como capacidades das plataformas em suportar esses protocolos.

Andar

O andar (store, também designado de forma aleatória de tier ou layer) representa o conjunto de componentes que compõem o fluxo de informação entre o usuário do nodo e sistema como um todo. Se nodos fossem edificios, andares seriam separações dentro dos edificios. Em cada andar a informação é processada sobre um certo aspecto. Os andares têm uma relação directa com as funcionalidades dos sistema. São os “blocos” lógicos por onde a informação tem que passar. Acontece apenas que em cada bloco, dependendo do nodo, acontecem coisas ligeiramente diferentes em implementação, mas iguais em propósito.

Camada

A camada (layer) é a tradução do andar em código. É um conjunto de código que serve um determinado propósito. Elas são a tradução real dos andares. Além disso existe uma diferença subtil. Os andares seguem uma herarquia de pilha , o andar do topo não comunica o andar do fundo. As camada podem fazer isso.

Arquiteturas

A seguir uma lista (não exaustiva) das arquiteturas mais utilizadas ou que, de alguma forma, ainda influenciam as arquiteturas atuais.

Standalone Architecture – Um único nodo existe que contém todos os componentes.

Client-Server – Um nodo é o servidor onde todo o processamento acontece, inclusive persistencia de dados. N outros nodos são os clientes. Aqui ficam andares de client e apresentação

Peer-To-Peer – N nodos existem ligados numa formação de vizinhança. Nem todos os nodos são ligados aos outros. Podem existir nodos especiais (servidores) ou não.

Service Oriented Architecture (SOA) – O nodo fornece serviços. Cada nodo pode fornecer mais do que um serviço. Os nodos consomem os serviços de outros nodos para alcançar o objetivo da aplicação

Cloud Computing – Existem N nodos trablhando num único estado de sistema não-localizável: a nuvem (cloud)

3-Tier Architecture – Um nodo é o servidor onde todo o processamento acontece ( servidor de aplicação), um outro onde a persistencia acontecer ( servidor de dados) e N outros nodos são os clientes. algumas variantes existem:
- n-Tier Architecture – Existe um numero não definido de nodos cliente, servidores de dados e servidores de aplicação.
- Web Architecture – Existe um numero não definido de nodos cliente que correm browsers, N servidores de dados e M servidores de aplicação. A especialização aqui é o uso do Browser como um componente genérico já existente nos nodos cliente, o qual não é necessário construir.