Nós temos Arquiteto de Software! E arquitetura?

O termo arquiteto de software está virando uma commodity dentro das software houses desse meu Brasil.

Esse papel tão importante se apresenta como um diferencial nos serviços prestados aos olhos do cliente e um imenso custo aos olhos da empresa, que sem hesitar, desprezam a idéia de encarar de forma correta o processo de desenvolvimento de software.

Mas, afinal, o que é arquitetura de software?

Bom, a arquitetura de software trata o interesse de 3 visões:

• Usuário: como os usuários usarão o sistema?
• Negócio: como manter a aplicação flexível e gerenciável?
• Sistema: quais os requisitos de performance, internacionalização, segurança e configuração? Quais tendências impactam no design agora ou após a distribuição da aplicação?

O processo de definir estruturas de solução fornece e avalia alternativas de projeto atuando na organização geral de controle, definindo a atribuição de funcionalidade a componentes de projeto, buscando extrair alto desempenho e escalabilidade, sem esquecer claro, de atender requisitos técnicos e operacionais.

O arquiteto de software é o profissional que:

• Possui grande compreensão (arriscamos a incluir também “ou facilidade de compreensão”) do negócio e das tecnologias pertinentes para trabalhar na modelagem da solução;
• Possui entendimento dos apectos técnicos para o desenvolvimento de sistemas para trabalhar na análise de viabilidade;

• Conhece bem as técnicas de levantamento, modelagem e desenvolvimento para trabalhar em provas de conceito, simulações e experimentos;
• Entende as estratégias de negócio da instituição onde atua para analisar tendências tecnológicas;

O que é um software bem arquitetado?

Alguns podem dizer que é aquele que faz o que o(s) usuário(s) quer(em). Mas, para avaliarmos se um software está bem projetado temos que identificar os atributos que desejaríamos encontrar nele.

O software bem arquitetado fornece:

E como construímos um software bem arquitetado?

Nosso trabalho começa junto da etapa de levantamento de requisitos buscando identificar:

• Peculiaridades de comportamento;
• Informações do domínio da aplicação;
• Restrições sobre a operação;

A lista abaixo pode ser utilizada como um check-list inicial do que levantar de requisito não-funcional:

• Usabilidade
  
  • Facilidade de aprender
  • Facilidade de usar
• Manutenção
  
  • Reparo
  • Evolução
• Confiabilidade
  
  • Disponibilidade
  • Taxa de falhas
• Desempenho
  
  • Tempo
  • Espaço
• Reusabilidade
  
  • Da aplicação
  • Dos subsistemas
  • Dos objetos
  • Dos módulos
• Portabilidade
• Segurança
  
  • Disponibilidade
  • Integridade
  • Confidencialidade
  • Operacional

E os complementando estão os atributos do projeto que guiam a concepção de solução para que o produto final satisfaça aos requisitos identificados. Esses atributos são:



Em uma arquitetura podemos identificar os componentes (subsistemas), conectores, mecanismos de interação, topologia e restrições semânticas (por exemplo, a camada de interface só pode acessar dados através da camada de negócios).

O estilo arquitetural, ou o conjunto de padrões, fornecem um conjunto de requisitos não-funcionais e atributos de projeto que permitem distinguir uma arquitetura de outra e prever as características desejadas no sistema.

Os estilos de arquiteturas mais comuns são:

:: CAMADAS

Estruturar o sistema num conjunto de camadas onde cada uma agrupa um conjunto de tarefas num determinado nível de abstração.

vantagem

• flexibilidade

desvantagem

• alto grau de dependência
• performance

:: OBJETOS

Permite a organização do programa em tipos de dados abstratos, que interagem através de troca de mensagens, podem ser modificados, reutilizados, distribuídos e executados sequencialmente ou em paralelo.

vantagem

• manutenibilidade
• performance

desvantagem

• acoplamento
• reuso

Atualmente, a combinação de estilos, por exemplo, camadas e objetos, guiam o desenvolvimento de software. A imagem abaixo ilustra a recomendação da Microsoft para a criação de sistemas de informação:



Os atributos que guiam o Microsoft Architecture Guide 2.0 são:

• Separação de conceitos: divida as funcionalidades da aplicação (alta coesão) e minimizar pontos de interação (baixo acoplamento);
  
• Responsabiliade única: cada componente deve ser responsável por apenas uma funcionalidade;
• DRY (Don’t Repeat Yourself): específique suas intenções em apenas um lugar;
• YAGNI (You Ain’t Gonna Neet It): projete apenas o necessário;
• LoD (Least Knowledge): um componente ou objeto não deveria conhecer os detalhes internos de implementação

Esperamos que esses conceitos acadêmicos com uma visão prática possam ajudá-lo a vencer os desafios do dia-a-dia.

Na próxima falaremos sobre Arquiteturas de Domínios Específicos (DSSA) e Arquiteturas de Interface com o Usuário.

Até a próxima!

---

Artigos Recomendados:

>>   Pensando em ERGONOMIA e USABILIDADE
>>   Reflection de Alta de Performance
>>   Boas práticas para gerência de requisitos, de acordo com os modelos MPS.BR e CMMI
>>   Extension Methods = Manutenibilidade
>>   Alinhamento Estratégico de TI – Parte 1