Capacidades da Arquitetura Ideal

Gostaria de abordar hoje sobre as capacidades que uma arquitetura bem planejada deve contemplar para proporcionar bons índices de qualidade. Este tema se torna extremamente importante se olharmos sob a ótica de que a qualidade afeta diretamente a satisfação do cliente e envolvidos com o sistema, sendo um ponto fundamental para o sucesso de um projeto de software.

Foram eleitas basicamente as seguintes 11 capacidades:

Disponibilidade

É a capacidade do sistema se manter no ar para uso devido. Diz-se que o sistema possui alta disponibilidade quando se mantém disponível a maior parte do tempo. Quando se contrata serviços de infra-estrutura, geralmente é acorda um percentual de disponibilidade que tal infra deve garantir, podendo pagar multas caso não cumpra o acordo, são as chamadas SLA's de disponibilidade.

 Robustez

É a característica pela qual se mede o nível de tolerância a falhas do sistema. O software deve ser capaz de prever situações inusitadas vindas de seus usuários e reagir com medidas que o mantenha estável, ou seja, sem apresentar falhas.

Gerenciabilidade

É a capacidade que mede o quão um sofware é configurável. A configuração dos níveis de logs gerados por um determinado software é um bom exemplo disso.

 Flexibilidade

Característica inerente à maneira em como um determinado software se comporta à mudanças, tanto arquiteturais quanto funcionais. Por exemplo, se um software hoje acessa uma base de dados Oracle, diz-se que ele é flexível caso seja possível mudá-lo para acessar uma base de dados SQL Server sem que para isso sejam necessárias grandes alterações em seu código-fonte.

 Desempenho

Esta característica está relacionada à utilização de recursos, como por exemplo, o tempo de processamento de uma grande quantidade de mensagens em uma fila JMS ou o tempo de processamento de uma consulta no banco de dados.

 Capacidade

Se refere às limitações impostas ao sistema, com o que o sistema deve suportar. Por exemplo: um sistema deve suportar 500 acessos simultâneos.

Resiliência

Este nome um tanto quanto "exótico" se refere ao grau de estabilidade do sistema mediante a picos de processamentos. Exemplo: um determinado sistema tem que suportar uma carga durante 3 horas e depois voltar ao seu estado normal sem sofrer quedas ou gerar defeitos.

Escalabilidade

É a capacidade de um determinado sistema ser flexível a ponto de prever o seu crescimento, ou seja, possbilita o seu incremento de funcionalidade e capacidades sem se tornar obsoleto, acompanhando sempre as necessidades do usuário.

Extensibilidade

É a capacidade que o sistema tem de crescer pela adição de novos componentes e que, muitas vezes, permita ao sistema fazer algo que ele já faz, mas de forma diferente. O polimorfismo em classes é um bom exemplo de extensibilidade em sistemas orientados a objetos, sendo possível através do uso de programação para interfaces e  nunca para classes com implementação concreta.

 Reusabilidade

Permite que um determinado sistema seja usado em contextos diferentes, ou então, que seus componentes sejam usados também em outras aplicações. Este tipo de reusabilidade de componentes facilita muito o desenvolvimento de aplicações corporativas, pois, proporciona uma maior facilidade de manutenção e ganho na produtividade do software.

Segurança

É a característica que permite avaliar o quanto um sistema é protegido, dadas as suas condições de exposição, contra ataques ou falhas internas ou externas que gerem inconsistências em suas informações ou outros tipos de defeitos, compromentendo a todas as outras capacidades aqui citadas. 

Um bom sistema deve prover condições de segurança nos quisitos autenticidade,  confidencialidade,  integridade e disponibilidade.

 

Fico por aqui pessoal. Para qualquer dúvida ou complemento das informações aqui postadas, não deixem de postar os seus comentários.   ;)

Um grande abraço e até o próximo post!

.

Arquitetura de Software

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.

.