Lucas Persona

Parece que existe um consenso no meio acadêmico no processo de definição de nomes de teses. A premissa parece ser que a capacidade do trabalho em atrair atenção estaria diretamente relacionada à complexidade do título.
Se o título é simples, você acha que o conteúdo traria informações importantes?

O título do meu trabalho de graduação, ou melhor, Iniciação Científica foi Algoritmo Genético GARP para Modelagem Ambiental.
Não falei que precisava ser difícil?

Apesar de citar algoritmos genéticos, não trato de engenharia genética. Também não falo nada de transgênicos. Mas o título é bonito.
E na prática, qual era o objetivo? Consolidar conhecimento para auxiliar pesquisas com abelhas. Óbvio!

Explico.

Através de Modelagem Ambiental, ou, da criação de modelos para representação do meio ambiente com informações ambientais (temperatura, precipitação, etc) e geográficas (localização, altitude, etc) é possível trabalhar então com predição de mudanças e seus impactos nas abelhas (ou outros seres vivos).

Se a temperatura média mundial aumentar 1ºC será que ocorreria uma migração de determinada espécie de abelhas para outro local?

Já consegui explicar meio título. Agora falta o início. GARP é um Algoritmo Genético. Um “tipo de”. O significado da sigla: Genetic Algorithm for Rule-set Production, ou, Algoritmo Genético para Produção de Conjunto de Regras.
Aqui é onde o assunto complica. Por isso, quem quiser mais detalhes pode verificar o material que produzi durante este trabalho para publicações e divulgação final. O pôster produzido apresenta o melhor resumo do assunto:

• Produção em Iniciação Científica da Escola POLI-USP

PERSONA, Lucas; CORRÊA, Pedro Luiz Pizzigatti; SARAIVA, Antonio Mauro. Algoritmo genético GARP para modelagem ambiental. Produção em Iniciação Científica da Escola Politécnica da USP, PIC-EPUSP, São Paulo, n. 2, 2003.

• Publicação em Congresso Brasileiro SBIAgro (Pôster: )

PERSONA, Lucas; CORRÊA, Pedro Luiz Pizzigatti; SARAIVA, Antonio Mauro. Algoritmo genético GARP para modelagem ambiental. In: CONGRESSO BRASILEIRO DA SOCIEDADE BRASILEIRA DE INFORMÁTICA APLICADA À AGROPECUÁRIA E À AGROINDÚSTRIA., Porto Seguro, Brasil, 2003. SBIAGRO : anais. Lavras: SBIAGRO, 2003. v. 3, P. 629-632.

• Publicação em Congresso Internacional I2TS2003

PERSONA, Lucas; CORRÊA, Pedro Luiz Pizzigatti; SARAIVA, Antonio Mauro. Modelagem de nicho ambiental em biodiversidade com algoritmos genéticos. In: INTERNATIONAL INFORMATION AND TELECOMMUNICATION TECHNOLOGIES SYMPOSIUM., Florianópolis, Brasil, 2003. I2TS 2003: proceedings.. Florianópolis : Fundação Barddal de Educação e Cultura, 2003. p. 1-5

• Iniciação Científica de Graduação

PERSONA, Lucas. Algoritmo Genético GARP para Modelagem Ambiental. 2003. 38 p. Produção em Iniciação Científica – Escola de Engenharia de Piracicaba (EEP), Piracicaba, Brasil, 2003.

E para aqueles que não se interessam pelo assunto. Fica a dica para os dias de insônia.

A tarefa era simples. Comprar uma caixa adicional de piso para terminar a reforma.
Reforma e construção são duas palavras que permeiam o sonho de muitos. Até o momento em que elas se tornam realidade. E se transformam em pesadelo.

De posse da Nota Fiscal – com data da compra, número do pedido e código do item comprado – a ação seria imediata. Entrar na loja, pedir uma caixa a mais, e sair com o produto.

– E quais são as medidas? – indaga o vendedor.

Medidas? Na Nota Fiscal leio 45×45. Mas isso não importa, porque as medidas dos pisos normalmente variam.

– E qual é a bitola?

Nova surpresa.
Mas estamos na Era da Informação. Onde sistemas informatizados rastreiam tudo e a todos. E a tão defendida liberdade se torna cada vez mais restrita e vigiada. Existiria algo mais simples do que descobrir qual lote do piso a própria loja entregou?

A proposta foi consultar a experiência. Um vendedor experiente saberia dizer como conseguir esta informação.
– Não é possível saber qual piso você recebeu. Você guardou as caixas originais do produto para identificar o lote, as medidas e a bitola? – dispara a experiência.

Em plena campanha mundial a favor do meio ambiente, o apelo de um conjunto de caixas de papelão como salvadoras do mundo é muito forte. A esta altura, as preciosas caixas cumprem seu papel de salvar árvores.

E o Sistema? Para os vendedores, essa informação não existe em sistemas. Inconformado, a experiência apela para a aparência afirmando que 20 anos trabalhando com pisos lhe dão sapiência suficiente para afirmar que não é possível encontrar esta informação.

Grande parte das empresas é alheia à quantidade de informações geradas pelos sistemas. Ou pelo menos alheia à importância da recuperação e divulgação a todos os níveis da empresa, de como obter estas informações.

Investimentos maciços em termos mágicos como Business Intelligence (BI), Data Warehouse e Data Mining se perdem ao não considerar o fator mais importante destas equações: o humano.

A comunicação e capacitação dos colaboradores nas estratégias e soluções adotadas pelas áreas de Tecnologia (T.I.) são essenciais para o real sucesso destas ações. Aquele no qual o benefício da solução está no favorecimento do negócio pelo seu uso.

Acredito que a área de TI estava um pouco distante daquela loja. Talvez um problema geográfico. Mas a informação estava lá, a poucos cliques de distância.

Foi preciso ir até outro atendente, este com acesso a um computador, e pedir para acessar as informações do pedido. Lá estava o número. Um desses grandes que ninguém presta muita atenção.

– Sempre aparece um número assim no pedido. Acho que é do Código de Barras. – informa a atendente.

A informação existia. A desinformação também. Uma solução tecnológica que o vendedor nunca aprendera a usar e que teria mudado o discurso da experiência. Há pelo menos uns 5 anos.

Apesar da EMBRATUR ter iniciado o ano com comemorações pelos bons resultados do Turismo Brasileiro, malas nunca estiveram tão na moda como agora.
Maior destaque que o delas, apenas para seus carregadores. Estes são entrevistados, fotografados e divulgados por todo o mundo.

São os intermediários. Estão presentes nas transações, representando uma outra parte. Sua função é transportar, cada qual sua “mala”, entre o requisitante e a parte remota criando a ilusão que existe um acesso direto entre os participantes da transação.

Este conceito, também conhecido como proxy, está presente em vários momentos da nossa vida da política à Internet. E quase sempre é transparente. Até virar notícia.

Nos sistemas, onde estas questões são solucionadas através do uso de Proxies, o mais comum são as classes de Proxy programadas diretamente para desempenhar sua função.

Com todas as chamadas bem definidas, qualquer alteração na classe principal afeta diretamente o Proxy. E isto é um problema disto. Sua ligação direta com uma das partes. Compromete.

Então temos os Proxies Dinâmicos. Genéricos. Que em sua implementação não sabem para quem trabalham. Realizam sua função e repassam as malas.

Mas sua atuação está baseada em Reflexão. Isto permite maior flexibilidade, mas tem seu preço: Performance.

Porém, apesar de todo seu apelo, o uso isolado de Proxies Dinâmicos necessita de uma chamada explícita a eles. Alguns consideram ser tão simples quanto um telefonema. Mas é preciso incluir um código específico de recuperação do Proxy, seja ele dinâmico ou não, todas as vezes que for necessário utilizar seus serviços.

Se é preciso chamar, é possível descobrir quem chamou. Compromete. Também.

Unindo estas necessidades, podemos verificar na utilização da Programação Orientada a Aspectos, um adicional ao prover a solução de proxies. Sem a necessidade de explicitar, diretamente no código, o uso do Proxy. Seja ele dinâmico ou não.

Um aspecto que identifique o ponto exato da chamada pode definir a forma de utilização do Proxy. Ou mesmo sua não-utilização por uns tempos. Para não comprometer.

A forma de implementação desta solução é variada. Depende da linguagem de programação. Depende da implementação de Orientação a Aspectos preferida. Está relacionada ao gosto e necessidade de cada um. Como as malas.

A cena é de tensão. É possível sentir o giro dos motores.
A respiração dos pilotos está reduzida ao essencial.
Aguardando o reflexo instantâneo de acelerar. De correr.

Dada a largada, ajustes milimétricos de cada carro são suficientes para alterar todo o resultado. Pequenos ajustes que favorecem ou comprometem a performance.

E vários sistemas estão assim: a 300 Km/h, mas não em primeiro. O que está errado? Onde está o problema?

Cada escuderia tem o seu modo de atacar o problema. Algumas simplesmente recolhem o carro…e o piloto que espere a versão 2.0 da arquibancada.

Mas muitas escuderias não querem abandonar a corrida.

As imediatistas mandam o mecânico subir no carro, dividir o espaço com o piloto e encontrar o problema. Ah! Foi achada uma folha de árvore na parte interna da carroceria. Assim que o mecânico desce, o piloto agradece. Melhorou! E muito…

Para algumas empresas, a solução é a tecnologia: o cronômetro. Tal como código enxertado que fica no caminho do sistema, é entregue ao piloto durante uma parada programada nos boxes. A cada volta, o piloto precisa ligar o cronômetro, correr, desligar e berrar o resultado. Quanto deu? Ninguém escutou. O arquivo de log está com muito ruído…fica para a próxima volta.

Este é um cenário que permite a aplicação da AOP. Apesar de considerarmos as soluções anteriores um tanto quanto irreais, é a representação exata de muitos sistemas. Pilotos cronometrando o próprio tempo. Distribuindo o resultado. Calculando a média das últimas voltas e previsão até o final da corrida.

Por que, quando falamos de sistemas, se torna difícil visualizar essa separação? Uma atividade externa ao carro monitorando sua performance. Sem qualquer interferência no trabalho do sistema.

Este aspecto, capturando momentos previsíveis da passagem do sistema, na pista, pode fornecer diversas informações e ainda ser modificado sem qualquer alteração do sistema monitorado.

Os carros continuam sua corrida. Uma corrida sem fim. Até serem substituídos por novos modelos, mais possantes e avançados, mas que também precisam de uma equipe de apoio, de controle e de medição. Externa.

Mas quando esse apoio, controle e medição são tratados como algo interno, do carro, incomoda o piloto. Caleja. E tira o brilho da corrida.

Às margens de uma floresta, um lenhador muito pobre vive com seus filhos e esposa – a madrasta de seus filhos. Em tempos de dificuldade, a falta de alimento os leva a uma solução um tanto quanto drástica: abandonar os filhos na floresta por não ter como alimentá-los.

Apesar do apelo dramático, este é o verdadeiro início do conto de fadas “João e Maria” (ou, Hãnsel und Gretel) dos Irmãos Grimm, conhecido clássico infantil.

Na continuação do conto, João e Maria, conhecendo o triste objetivo de sua madrasta, decidem marcar o caminho para conseguir voltar. Da primeira vez com sucesso, ao usarem pedras brancas. Na segunda, com pão.

E isso me lembra de um clássico quando se fala em AOP: Log.

O principal exemplo em textos de AOP utiliza este clássico no intuito de auxiliar o entendimento do novo conceito.

Talvez porque o processo de Log em uma aplicação é amplamente conhecido como necessário, mas os meios e real utilização dele se aproximam das idéias de João e Maria. Alguns logam com pedras, outros com pão. Existem os que logam. E os que não.

João e Maria, como classes, têm outras responsabilidades. São crianças. Querem brincar e se divertir. Não deveriam se preocupar em marcar o caminho percorrido.

Mas muitas vezes surgem os temidos “bruxos do Processo e do Padrão”, terror dos implementadores. E com sua voz de trovão estabelecem: Todo método deve logar o início e fim de seu processamento. E as crianças tremem.

Nas primeiras semanas, os implementadores todos animados procuram as pedras brancas mais polidas para utilizar nos Logs. Claras identificações de entrada e saída de cada método. Até que o tempo começa a ficar escasso. Assim como as pedras. E surge o pão. Pedaços de Log jogados aqui e ali, que acabam sendo engolidos por outros códigos. Implementadores esfomeados que comem o pão e esquecem do Log. E João e Maria ficam perdidos na floresta.

E então temos a AOP, como uma fada-madrinha, para resolver o problema de João e Maria e acalmar os bruxos do Processo e do Padrão. Um aspecto de Log, que assume a responsabilidade de marcar o caminho e logar o início e fim de processamento de cada método. Um aspecto que pode ser colocado ou retirado de todo o sistema como um passe de mágica. Sem dependências com João e Maria, sem dependência com implementadores.

Este é um clássico da AOP que demonstra bem como uma responsabilidade – a de determinada regra de Log – pode ser retirada do código interno das classes. E transferida a um aspecto específico, de responsabilidade bem definida.

Ganha a classe, ficando mais objetiva e limpa. Ganha o implementador, focando apenas no desenvolvimento da funcionalidade da classe. Ganha o sistema, com um processo de Log padronizado e garantido, e ainda de fácil alteração. E como em todos os clássicos contos de fadas: vivem felizes para sempre.