Postagens

Arquitetura em projetos de aplicações em nuvem - noções iniciais

Hoje o foco é arquitetura para uma aplicação que será implantada na nuvem. Em primeiro lugar, o que motiva colocar uma aplicação na famosa nuvem? Se você pensou algo do tipo "deve ser melhor, porque todo mundo está fazendo", quero que você reflita mais sobre suas decisões.

Existem motivações para se colocar uma aplicação em nuvem. Cito algumas: necessidade de começar com pouco investimento em infraestrutura e crescer sob demanda; possibilidade de escalar a aplicação horizontalmente em resposta rápida a uma quantidade de acessos maior que o normal; de forma análoga, a capacidade de diminuir a escala da aplicação e evitar servidores ociosos (e seus custos) em momentos de calmaria; menor preocupação com infraestrutura e sua gestão; alta disponibilidade; facilidade de criar ambientes de homologação e fazer o chaveamento entre estes e produção. Bem, existem outros fatores, certamente, mas vamos focar nesses.

Para se conseguir obter os benefícios de uma aplicação em nuvem é precis…

Validação arquitetural

Continuando o papo sobre arquitetura, hoje o foco é sobre a sua validação. A ideia é responder se a proposta arquitetural feita irá honrar todos os requisitos, especialmente os não funcionais.

Como eu posso saber se o site que eu planeje suportaria dez mil usuários simultâneos? Ou quantas conexões eu tenho que colocar no meu pool para dar conta de atender aos meus clientes, na minha aplicação multi-tenant? Esse tipo de pergunta é melhor respondida se você colocar a prova o sistema.

O ideal é fazer uma carga e observar, colhendo alguns indicadores. Ora, como qualquer bom trabalho, o primeiro passo é planejar: o que precisa ser medido / testado? Quais serial bons valores obtidos? Para esta última pergunta, vale buscar referências de mercado, sua base histórica (você tem uma, não?), informações com parceiros e quaisquer outras fontes que puder levantar. Então, é preciso se munir de instrumentos para colher indicadores. Busque ferramentas que possam medir uso de memória, processador, disc…

Documento de arquitetura

Hoje, o assunto é a documentação arquitetural. Entendo que documentar a arquitetura tem duas grandes funções: comunicar formalmente as decisões tomadas, para nortear o desenvolvimento do software, e registrar para consultas futuras, resgatando o racional empregado.

A forma de documentar pode variar bastante, mas me agrada mais os formatos publicáveis em portais de documentação, exportando o conteúdo em HTML puro ou na modalidade WIKI, com marcações - que não deixa de ser uma variação do hipertexto tradicional. Essas formas são fáceis de se consultar e indexáveis.

O que colocar em um documento de arquitetura?

1- Eu gosto de começar com uma visão geral do problema e um diagrama, com o que é chamado de Big Picture, que mostra um panorama da solução técnica, comentando as principais características da arquitetura proposta. Normalmente se mostra um desenho com as camadas lógicas da aplicação, incluindo as ortogonais (cross cutting concerns), que tipicamente são resolvidas por injeção de có…

Um pouco mais sobre arquitetura

Vamos discutir um pouco mais sobre arquitetura? Bem, logo depois de ter entendido o problema e traduzido as necessidades do cliente em requisitos (vide posts anteriores sobre esses assuntos), é hora de definir a solução técnica.
Importante: pode existir solução técnica preliminar, normalmente feita antes de vender o projeto, ainda em fase de negociação com o cliente, com o objetivo de fazer estimativas de prazo e custo. Para o escopo deste post, focaremos na solução técnica da fase de projeto mesmo, quando o negócio já foi fechado. 
Primeiro ponto importante: normalmente há mais de uma solução técnica candidata. Por isso, é preciso decidir qual dessas opções será a implementada. Para isso recomendo montar uma tabela de decisão, em que são colocados critérios objetivos, com uma escala numérica e pesos para os critérios. A solução que obtiver mais pontos, segundo esses critérios ponderados será a escolhida. Não há uma receita para os critérios, mas posso dar exemplos: conhecimento do ti…

Levantamento de requisitos

Hoje o papo é sobre o começo do processo de engenharia de software: os requisitos.

Vou começar com uma analogia que gosto de fazer. Imagine que você não se sentiu bem e foi a um pronto-socorro. Agora, imagine que o médico que o atendeu não examinou direito e já receitou um remédio, mas não era exatamente para o problema que você tinha. Você não melhora, vai a outro médico, que o analisa corretamente, pede exames complementares e dá um diagnóstico mais preciso, encaminhando ao tratamento adequado.

Bem, se você quiser sair fazendo o software, sem fazer o levantamento e a análise dos requisitos, você estará receitando um remédio para um problema que você nem sabe qual é. Não parece nada bom, não é mesmo?

Os requisitos servem para formalizar o domínio do problema. Não que software ou o negócio do seu cliente sejam problemas. É que se chama de problema o desafio que se tem ao preparar um software para apoiar um determinado objetivo, normalmente de algum negócio.

A arquitetura e a codificaç…

Requisitos conflitantes e dilemas no projeto de software

Ah, os trade-offs... Todo projeto nós os encaramos. E temos que tomar decisões. Daquelas importantes, que podem gerar desconforto para algum envolvido.

Antes de mais nada, afinal, o que é esse tal de trade-off? Este termo é utilizado para indicar uma situação que é necessária uma escolha, para resolver um certo conflito. Um exemplo que sempre cito é: um stakeholder solicita que o sistema seja extremamente seguro e quer que seja aplicada uma complexa criptografia em tudo o que se possa imaginar. Legal. Mas outro stakeholder solicita que o software entregue as resposta com o máximo de desempenho possível. Hummm... Aquela criptografia, solicitada pelo primeiro, degrada a performance do sistema. E agora? Eis o tal do trade-off.

Bom, sei que é clichê, mas aqui não tem muito certo ou errado. A dica para lidar com os trade-offs é avaliar cada requisito sob vários aspectos. Julgo que o mais importante é quanto de valor aquele requisito incorpora ao sistema e a quem o solicitou. Quão important…

Rastreabilidade: da necessidade do cliente ao produto pronto

Você já se perguntou de onde veio alguma fórmula mágica que está escrita no código? Ou já se deparou com o desafio de avaliar qual seria o impacto de um requisito que mudou? Para deixar sua vida mais fácil, o que é necessário é que seu projeto tenha rastreabilidade.

E o que é rastreabilidade? É tornar evidente o vínculo entre as etapas e entre os artefatos gerados durante o processo, para saber qual a sua origem ou motivação.

O ideal é que uma necessidade do cliente seja mapeada em um ou mais requisitos. Não basta apenas evoluir o texto da necessidade de forma a gerar os requisitos, tornando-o objetivo e passível de testes. É preciso documentar que a primeira está associada a esses requisitos. A forma de fazer isso pode variar. Há quem crie matrizes de rastreabilidade, que funcionam bem. Também é possível identificar necessidades e requisitos com códigos inteligentes, de modo que uma parte do código dos requisitos seja justamente o da necessidade que o motivou - o que funciona para a …