Um pouco de Arquitetura de Software

Muitas pessoas se perguntam o que é, ou se de fato existe a “Arquitetura de Software”. Para ajudar a compreender, é importante analisarmos alguns players na concepção de um software, bem como seus papéis:

• Programador: Bem, este dispensa apresentações, é o criador de códigos, componentes, artefatos do software. Compreende e domina as linguagens de programação, frameworks, etc. Altamente técnico.
• Testador: Profissional responsável pelas rotinas de testes do software. Os testes, para os softwares modernos, são fundamentais. Estes profissionais tem de compreender um pouco de programação em algumas circunstancias, para escreverem programas que testam programas, macros e até mesmo códigos que testam códigos.

Até aqui é interessante observar uma perspectiva natural do mundo do Software: estes profissionais são muito técnicos e “estão em um mundo diferente” dos usuários do software. Pode parecer exagero meu. Mas ao pé da letra é assim! O que acontece é que em muitos casos, no desenvolvimento de um software, nós acabamos assumindo mais de um papel, e algum deles contém um contato maior com o usuário do software. E, tanto é verdade o que eu digo, que eu quero que tentem responder uma pergunta: vocês conhecem algum programador que fez parte da codificação do Windows? E do GMail?

Continuando…

• Engenheiro de Software: Esse profissional é responsável em mapear o material coletado com o usuário (e pode não ser ele quem coleta o material) e transformar em documentação (técnica) para os desenvolvedores e testadores.
• Analista (de sistemas ou até mesmo de negócios): É um típico coletor de informações das necessidades do usuário com relação ao software.
• Arquiteto de Software: Profissional responsável por pegar as informações levantadas, requisitos do sistema e montar uma solução de software. Ele vai decidir como o software será concebido. Isso envolve linguagens, protocolos, requisitos de hardware e comunicação entre as partes do software. Ele tem a visão macro da coisa.

Vamos analisar um exemplo pratico: o Twitter.

Eu considero que o Twitter é um caso de sucesso em sua arquitetura. Isso porque ele é um sistema relativamente novo, e podemos usar o front-end que desejarmos (inclusive desenvolver um próprio) para ele. A arquitetura do Twitter é baseada em um core que se tornou uma API altamente difundida. Com isso vemos que o site oficial, o site mobile, apps Java para celular, apps desktop ,dentre outras, simplesmente consomem suas APIs. Se desejarmos desenvolver uma aplicação para o Twitter é só entrar no site deles e ler a documentação da API.

Toda essa flexibilidade do Twitter só foi possível graças a sua concepção arquitetural.

Agora me responda, seu software, é possível eu plugá-lo na web? E no celular?

Deixa eu adivinhar, não é possível pois toda a regra de negócios está no “click” do botão salvar (com mais de 500 linhas, e alguns SQLs) do seu app desenvolvido em Delphi 7.

Este é um dos benefícios expostos por um bom estudo de arquitetura de software. Já ouviram falar em Entity Framework? JPA? Hibernate?

Agora me respondam, tentaram usar algum por que eles são orientados a objetos? Estão na moda? São fáceis? Não é preciso se preocupar com SQL?

Pois bem, na verdade a premissa principal de frameworks como esses é: Abstração de banco de dados, ou seja, não é preciso se preocupar se a base de dados será Oracle, SQL Server, MySQL etc.

Agora juntem as possibilidades: múltiplas interfaces, múltiplos bancos, e, com uma boa arquitetura, é fácil fazer módulos, plug-ins… enfim, tornar a aplicação bem extensível e plugável.

O arquiteto de software tem de ser capaz de planejar, documentar e decidir quais tecnologias estarão envolvidas na concepção do software (isso inclui linguagem de programação e framework), e até mesmo a infra-estrutura necessária para abrigar e processar o software.

Isso só representa benefícios ao software: o torna modular, testável, expansível. Ajuda a compreender seu funcionamento juntamente com a infra-estrutura e tecnologias envolvidas.

Importante observar que o arquiteto de software não tem uma visão detalhista de software, pois não é do interesse dele saber como que o analista ou engenheiro definiram o cálculo de juros para o programador. Ele tem uma visão de cima, macro, de como o software passa as informações processadas de um lado para o outro. Por isso ele também é um dos primeiros na concepção do software (lembrando que concepção é diferente de planejamento). Ou seja, após feita a análise e levantado os requisitos, o arquiteto vai gerar um projeto (ou solução) de software que irá abrigar o software. Ele vai definir camadas, por exemplo: Camada visual, Camada de Banco de dados, Repositórios; e como elas devem se comunicar, e o que é preciso para elas funcionarem; Depois disso ele repassa essa carcaça/esqueleto montado para os desenvolvedores codificarem.

Vamos ver isso um pouco na prática: Vamos fazer uma calculadora com as quatro operações básicas. Porém ela deve rodar na Web, Desktop e Console. Este projeto será concebido no Visual Studio.

Para isso nós teremos o seguinte gráfico de camadas e dependências:

Crie no Visual Studio a seguinte solução com os seguintes projetos:

• CalculadoraBase (Class Library)
• ConsoleCalculadora (Console)
• WindowsCalculadora (Windows Forms)
• WebCalculadora (Web Application)

Segundo o diagrama de dependência, os projetos de interface (web, windows e console) devem referenciar o projeto CalculadoraBase, para isso dê um “Add Reference” nos projetos:

No projeto CalculadoraBase, vamos adicionar e implementar a classe Calculadora:

Feito isso, podemos instanciá-la nos outros projetos e consumir suas regras, veja:

Pronto! temos aí uma prova de conceito. Centralizamos a regra em um projeto e distribuímos as funcionalidades (já prontas) em três frentes!

Agora imagine que você pode fazer isso com sua aplicação… Comercial por exemplo. Vamos pensar: Uma aplicação comercial Orientada a Objetos, tem que ter objetos mapeados da base de dados. Além disso, ela tem as regras de negócio, o próprio banco de dados, e uma interface. Nessa linha de raciocínio, teríamos:

 

Com esse modelo, caso fosse desejado/necessário plugar uma outra interface gráfica, bastaria referenciar a regra de negócios e o mapeamento do banco de dados. E outras possibilidades também podem ser viabilizadas. Além do que este é um modelo básico. A arquitetura pode ir muito além disso, como por exemplo rodar webservices em servidores externos com pré-requisitos de SO e Hardware. Enfim, não há receita de bolo, o arquiteto tem de planejar (para não dizer arquitetar).

O arquiteto deve se preocupar com baixo acoplamento, se o desenvolvimento e a manutenção dos elementos também é facilitado, possibilitar o desenvolvimento independente, mudanças terem menor impacto.

Vejamos mais alguns pontos/ideias da Arquitetura de Software:

• Relacionamento com softwares externos
• Comunicação entre os envolvidos no software
• Reuso
• Confiabilidade
• Segurança
• Escalonamento
• Usabilidade
• Visão funcional/lógico.
• Visão organizacional de código
• Design Patterns
• Estrutura do software
• Melhor controle de concorrência/processo/thread
• Visão de protocolos
• Sincronização
• Geração de componentes de software, e até mesmo uso de componentes, adequados ao contexto, de terceiros.

O arquiteto deve responder perguntas como:

• A solução é Web ou Windows?
• Qual linguagem usar?
• Qual impacto na atualização de uma tecnologia utilizada no software?
• Qual SO?
• E o servidor?
• Como o software deve ser atualizado?
• E a segurança?
• Como vai ocorrer a autenticação?
• Como vai ocorrer sincronizações?
• Quais os protocolos envolvidos?
• Quais os designs patterns envolvidos?

Concluindo, um bom planejamento arquitetural de seu software é fundamental no mundo contemporâneo de software. Isso ajuda a modularizar, testar, manter e estender seu software. Além do que, fazer software vai além da escolha de algoritmos e estrutura de dados. Pois essa questão envolverá também decisões sobre as estruturas que formarão o sistema, a estrutura global de controle será usada, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidade a elementos do sistema, ou ainda sobre distribuição física dos elementos do sistema.

E finalmente, isso foi meio que uma visão geral de arquitetura, não disse tudo, a intensão nem é esta. apenas exemplifiquei algumas coisas, mas este é um universo bem maior.

Espero que tenham gostado