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.
- flexibilidade
- 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.
- manutenibilidade
- performance
- 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
