Profissionais TI - Pra quem respira informação

Introdução

Este artigo tem o objetivo de mostrar que é possível construir softwares de missão critica na WEB modelando inteiramente orientado a objetos, ganhando com isso as vantagens que uma arquitetura flexível nos dá, como escalonamento. Nunca antes isso fez mais sentido, sobretudo com a possibilidade de qualquer pessoa física poder hoje contratar uma infraestrutura inteiramente configurável desde CPU e gigas de memória e até mesmo outras máquinas virtuais e clusters de banco de dados construindo um verdadeiro data center sem ter que necessariamente arcar com os custos de tê-lo fisicamente em um espaço próprio.

Com a evolução dos métodos de segurança na rede para as aplicações, empresas como Google, Red Hat , Microsoft e Amazon massificaram a venda de serviços de infraestrutura na nuvem. Com isso, voltou aquela discussão de investir ou não em praticas de engenharia de software em seus negócios, mais especificamente em sistemas que servem como plataforma para empresas rodarem suas operações.

Não é segredo que a maioria das empresas em solo brasileiro usam sistemas onde sua arquitetura se define em controlar a transação com o banco de dados, assegurar a integridade funcional dos dados com validações e algoritmos bem validados junto a área de negócio e que funcione rápido o suficiente para que seja funcional. Tendo isso garantido, não importa se a logica de negocio está uma parte na camada de cliente, ou se está inteiramente dentro de procedures de banco de dados, algo que em realidade ajuda na performance e na simplicidade de execução.

E isso não está errado, muito pelo contrário! Até porque o objetivo de uma corporação é operar em uma plataforma segura e que não comprometa negativamente as ações dos seus negócios, além do fato de que a maioria dos produtos tecnológicos no mercado, como plataformas e linguagens, darem mais ênfase na cobertura de operações corporativas de forma pragmática. Em uma palestra de Ralph Johnson escutei ele pessoalmente dizer que o importante é você ter em conta as vantagens e desvantagens de cada estratégia que irá adotar, não é somente o fato do uso correto de um padrão que garantirá o bom funcionamento de um sistema. Muitas vezes até o exagero do seu uso nos projetos e na definição de requisitos, pode resultar em ser extremamente negativo. Pode por exemplo, complicar o que deveria ser simples, inclusive na comunicação da equipe ou ainda exigir um conhecimento abstrato da equipe que não esteja especificamente preparada ou casos que o desenho leva a um aumento de latência das operações por excessos nas divisões de camadas. O próprio Ralph Johnson citou na mesma palestra: – Você pode se envenenar até mesmo de água, caso consumida em excesso.

Padrões de Arquitetura

Usando as classificações dadas por Martin Fowler, podemos separar em 3 padrões de arquiteturas:

1. Transactional Script: Este é um padrão muito usado encontrado em sistemas de gestão que não dependem diretamente de integração com outros sistemas em ambientes ou tecnologias diferentes. Basicamente recebe um conjunto de dados de input , faz todas as validações em um mesmo bloco de instruções ou subdivide estes blocos em um conjunto de sub funções. Armazena os dados de forma direta e acoplada.

Contém muitas vantagens e não é por qualquer razão que grande parte dos sistemas que estão rodando hoje nas instituições estão neste padrão. Pois é procedural e simples para que a grande maioria dos desenvolvedores possam compreender. Funciona muito bem conectando a um único objeto de acesso a dados, onde Martin Fowler chama Row/Table Data Gateway. E é simples de controlar os limites de transações.

2. Table Module: Este é o padrão mais usado nos sistemas de gestão que  observei até hoje. Ele muitas vezes é descrito como um meio termo entre o Transactional Script e o Domain Model. Porque organiza o desenho do domínio em tabelas ao invés de procedimentos, fornecendo uma melhor estrutura. Porém impede o uso de inúmeras técnicas que o Domain Model fornece, como padrões de orientação a objetos heranças, estratégias e etc.

Devido a essas vantagens e simplicidade os principais produtos de desenvolvimento foram feitos para atender a demanda de negócios cada vez mais crescente, por exemplo o Microsoft COM e .NET. Com uma abordagem mais simples seriam mais dissemináveis nos projetos pelo globo. Não é de se estranhar o grande numero de aplicações de missão critica rodando com a lógica de negocio em stored procedures e na parte de apresentação contar com uma chamada a um único objeto de acesso a dados muitas vezes denominados como DAO.

3. Domain Model: Este é o oposto do transaction script, porque ao invés de ter toda a lógica em uma rotina, o Domain Model organiza a lógica de negocio dentro de um modelo representacional que é desenhado ao inicio, onde suas tabelas são extraídas dos substantivos do domínio de aplicação e os métodos ou casos de uso são retirados dos verbos. Um sistema de vendas no varejo por exemplo teria classes como: Produto, Carrinho, Compra, Fatura, Cliente. E um caso de uso seria Finalizar Compra, ou Registrar Cliente.

Esse padrão de arquitetura é o que vamos tratar neste artigo, por entender que se beneficia de todas as vantagens da orientação a objetos e das boas praticas da engenharia de software. Mesmo sabendo que a sua aplicação é mais complicada e um pouco frustrante para quem não ainda está habituado com este paradigma, recomendo sua utilização para o problema em questão que é arquitetura de aplicações em cloud.

Cloud Computing

O conceito do cloud computing se refere ao uso de memória ou capacidade de armazenamento e computo compartilhados e interligados a outros servidores pela internet utilizando o principio GRID (computação em grade). Com sua evolução foram criados 7 tipos:

• IaaS – Infrastructure as a Service ou Infraestrutura como Serviço (em português): quando se utiliza uma percentagem de um servidor, geralmente com configuração que se adeque à sua necessidade. (p. Ex.: Softlayer)
• PaaS – Plataform as a Service ou Plataforma como Serviço (em português): utilizando-se apenas uma plataforma como um banco de dados, um web-service, etc. (p.ex.: IBM Bluemix, Windows Azure e Jelastic).
• DaaS – Development as a Service ou Desenvolvimento como Serviço (em português): as ferramentas de desenvolvimento tomam forma na computação em nuvem como ferramentas compartilhadas, ferramentas de desenvolvimento web-based e serviços baseados em mashup.
• SaaS – Software as a Service ou Software como Serviço (em português): uso de um software em regime de utilização web (p.ex.: Google Docs , Microsoft SharePoint Online).
• CaaS – Communication as a Service ou Comunicação como Serviço (em português): uso de uma solução de Comunicação Unificada hospedada em Data Center do provedor ou fabricante (p.ex.: Microsoft Lync).
• EaaS – Everything as a Service ou Tudo como Serviço (em português): quando se utiliza tudo, infraestrurura, plataformas, software, suporte, enfim, o que envolve T.I.C. (Tecnologia da Informação e Comunicação) como um Serviço.
• DBaas – Data Base as a Service ou Banco de dados como Serviço (em português): quando utiliza a parte de servidores de banco de dados como serviço.

Em uma arquitetura Transactional Script onde se mantém toda a sua lógica e seus dados em um mesmo bloco, e caso imaginarmos um cenário que pede um escalonamento vertical como, por exemplo, trabalhar com vários repositórios de dados em simultâneos, já teríamos um grande problema. Se precisar trabalhar com sistemas integrados de forma online, essa arquitetura tampouco seria funcional.

Em uma Arquitetura Table Module, caso necessário trabalhar com múltiplos servidores web em loadballacing ele atenderia, porém, se voltamos a pensar se funcionaria com múltiplos servidores de banco de dados diferentes de forma online, também teríamos um grande problema. Ou caso se encontre uma solução a isso, o custo de manutenção tenderia ser mais elevado que o de um domain model.

Em resumo, o aparecimento do clound computing exige uma arquitetura escalável e requer realmente seu uso. Sobretudo se pensarmos na maturidade do produto a longo prazo. Refletindo a respeito da engenharia de software podemos concluir que a solução para esse novo requerimento arquitetônico seria uma arquitetura com baixo nível de acoplabilidade, utilizando para isso técnicas e padrões de programação e modelos orientados a objetos com Domain Model.

Podemos pensar no exemplo de criar um sistema na nuvem como um SaaS, de forma que sua infraestrutura estaria totalmente na nuvem em um serviço IaaS da Amazon. Tendo uma arquitetura física de 1 servidor web, outros 2 de banco de dados e um outro de arquivos – este utilizado para upload de dados oriundos de um outro sistema. Ainda devendo compartilhar uma série de serviços na WEB para que aplicações mobile possam interagir com o sistema. Uma arquitetura Domain Model seria a ideal para este problema em questão.

Outra razão da escolha deste padrão de arquitetura, é respeitar duas leis básicas da engenharia de software, o limite das possibilidades de alteração de código tende ao infinito, pois se trata de um produto abstrato gerado a partir do intelecto humano sem a necessidade de materiais. Outra lei é: Quanto mais já tenha sido construído o software, mais será complexa a sua alteração.

As técnicas de orientação a objetos nos ajudam a mitigar este problema tornando o software mais flexível à mudanças, tornando ao final financeiramente mais barata a modificação do produto em etapas tardias do projeto. Permitindo ser usada em projetos de larga escala e de grande importância na geração de valores.

Abaixo há um gráfico que explica a curva de complexidade dos 3 padrões.

Técnicas e Ferramentas Propostas

1) Análise orientada a objetos e padrões de projetos

Como mencionado na descrição do Domain Module, primeiro é modelado o domínio em uma representação UML, utilizando a linguagem do domínio como referência onde os substantivos se tornam as classes e os verbos os casos de uso. A interação entre as classes e os métodos das classes podem ser especificadas por diagramas como os de sequencia em UML. Porém, com minha experiência não o recomendo, porque daí surge um conflito entre o que o analista pensa (Ou muitas vezes chamado de Designer) da realização do caso, e o que o desenvolvedor pensa em como resolver o caso. Neste caso o desenvolvedor sempre terá a melhor visão de COMO fazer, e o analista sempre terá a melhor visão de O QUE FAZER.

A solução para este impasse, para mim, sempre foi o uso de diagramas de atividades, onde são melhor detalhados em especificações de casos de uso.

Claro que recomendo essa pratica para casos complexos que exigem muito feedback do especialista do domínio, que muitas vezes é o próprio cliente. Para casos com pouca interação ou complexidade poderia ser simplesmente resolvido com Story Case. Notem que esta linha de raciocínio é de simplificar o máximo possível, caso seja um problema complexo recomenda-se um estudo detalhado de caso com estas ferramentas da analise orientada a objeto que se baseiam em especificações detalhadas e representadas em diagramas UML para melhor entendimento.

Tenho um texto publicado que detalha esse processo baseado no estudo de Craig Larman no seguinte link: https://www.academia.edu/7933694/Processo_de_Desenvolvimento_Iterativo_de_Software. O texto do link não trata o uso pratico das tecnologias, porém, esta falta será suprida com esse artigo.

2) Tecnologia proposta

1. Java – Linguagem amplamente difundida no mercado, multiplataforma e ajusta muito bem ao paradigm de orientação a objetos.
2. Hibernate – Ao invés de criar DAOs , proponho o uso de uma camada de acesso a dados com todos os objetos do modelo de domínio mapeados aplicando técnicas mais a seguir.
3. MySQL – Escolhida esta base porque neste exemplo não iremos demandar tantos dados, porem poderia ser perfeitamente substituído por qualquer outro motor de base de dados ACID já que toda a arquitetura ira lidar com a logica e controle de transações.
4. Maven – Auxilia para gerenciar as dependências.
5. Tomcat – Servidor WEB que executa nossa aplicação JAVA e Spring
6. Wicket – Framework JAVA que trabalha com o conceito de programação por componentes, se encaixa muito bem com quem programa orientado a Domínio utilizando POJOs.
7. Spring – Nos será útil por permitir a injeção de objetos on the fly permitindo também a Ioc (Inversão de controle)
8. AWS – Amazon WEB services, que prove um computador na nuvem para executar nossa pagina.
9. RDS – Banco de dados também oferecido pela Amazon, um perfeito exemplo de DaaS.
10. Cytoscape – Framework javascript que apresenta dados em grafos por meio de Jquey, útil para alguns casos na camada de apresentação.

Leia a segunda parte deste artigo, que irá demonstrar a aplicação destes conceitos com as ferramentas atuais.