Introdução Aluno: Rafael de Holanda Barroso Professor Responsável: Carlos Eduardo Ferreira Orientador: Alfredo Goldman vel Lejbman Tipo do Trabalho: Estágio

O objetivo desta monografia é descrever minha experiência como estagiário na empresa ITM Channelmarketing no período de Maio/05 a Dezembro/05.

Apresentarei os conhecimentos técnicos adquiridos e desenvolvidos durante o estágio e contarei parte das minhas experiências pessoais, relacionando o estágio ao curso de Bacharelado em Ciência da Computação do IME-USP.

Primeiramente falarei da empresa em que fiz meu estágio, seu campo de atuação e posição no mercado. Em seguida, destaco o principal projeto em que trabalhei, o Sistema Together, e discuto aspectos técnicos da sua concepção. Depois, apresento outro foco do meu estágio, o Sistema Channel Monitor, que trabalha em conjunto com o Together e, no final da parte técnica, descrevo um pouco a respeito da mineração de dados com o R, que estou pesquisando no momento.

A Empresa A Empresa

A ITM Channel Marketing é uma empresa que foi fundada há 9 anos e atua em marketing voltado a canais nos mercados brasileiro e latino-americano. Ela possui cerca de 150 funcionários distribuídos em suas sedes - duas em São Paulo, uma no Rio de Janeiro, uma no México e uma em Nova York - sendo cerca de 30 na área de tecnologia.

O Canal de Distribuição

Na atualidade, são inúmeros e variados os esforços empreendidos pelas empresas com o objetivo de se destacarem e ganharem mercado. Recentemente, percebeu-se a importância decisiva do Canal de Distribuição para o alcance desses objetivos empresariais.

Canal de Distribuição consiste no caminho percorrido pelos produtos de uma empresa desde a sua fonte até a chegada ao seu público consumidor final. A construção de sistemas e ferramentas baseadas em tecnologia que auxiliem a obtenção de dados confiáveis e atualizados é fundamental para se dominar o Canal e, conseqüentemente, permitir a tomada de decisões rápidas e eficazes para estar à frente dos concorrentes.

A principal atividade a mim atribuída no estágio realizado foi o desenvolvimento e a manutenção de algumas dessas ferramentas. Os sistemas em que trabalhei foram:

Together, onde efetuei uma série de refatorações e reorganizei o código de forma a criar uma biblioteca de classes para usos posteriores; Channel Monitor, onde adicionei recursos inexistentes e participei de uma migração de tecnologia de comunicação; finalmente, a ferramenta com apoio da linguagem R para a mineração de dados, em que estou trabalhando no momento.

O Sistema Together Introdução

O HP Together é um sistema baseado em tecnologia .Net desenvolvido para a Hewlett-Packard do México. Ele tem como objetivo manter o cadastro atualizado de distribuidores e revendedores e agrupá-los de acordo com o nível de relacionamento com a HP. Esse sistema comporta tarefas diversas, tais como incluir empresas em campanhas de marketing e estabelecer ativos (formulários direcionados a um grupo de revendas alvo) para a equipe de operadores de telemarketing a fim de manter estreito o relacionamento com o Canal.

Durante o período do estágio, fui responsável pela refatoração do código do sistema. Primeiramente, fiz uma reavaliação dos requisitos do sistema e após isso propus uma nova modelagem orientada a objetos, visto que a que existia anteriormente não satisfazia a esse critério. Posteriormente a implementei, aproveitando o código já criado.

As principais fases na reengenharia do sistema foram as seguintes:

1. Identificação de requisitos 2. Identificação de Padrões de Projeto 3. Modelagem do sistema 4. Desenvolvimento 5. Testes

1. Identificação de requisitos

Logo que iniciei minhas atividades na empresa, fui alocado para trabalhar no sistema Together. Essa fase inicial foi basicamente de treinamento, integração com o resto da equipe e de familiarização com o projeto - seu escopo e suas regras de negócio. Adquiri bastante conhecimento sobre VB.NET[1] e suas diferenças em relação ao Java, liguagem orientada a objetos com a qual eu tinha maior familiaridade. Também tive que aprender a utilizar a ferramenta Visual Studio, usada no desenvolvimento.

A fase de identificação de requisitos exigiu algumas reuniões com os gerentes da ITM, clientes (funcionários da HP), além de uma vasta leitura de código, pois o Sistema Together já estava em produção. Esse período de pesquisa revelou que, no que diz respeito às regras de negócio, os requisitos haviam mudado um pouco e, quanto à parte técnica, apesar de usar uma linguagem orientada a objetos, o sistema não havia sido projetado para isso, portanto era de difícil manutenção. Além disso, não havia documentação referente ao projeto ou à implementação do sistema.

Havia a necessidade de tornar o sistema mais modular e configurável, pois sistemas similares eram oferecidos a outros clientes e o reaproveitamento de código consistia em

replicar o código em um novo local e modificar os arquivos de estilo, a fim de se adequar ao do cliente.

Outro aspecto a favor dessa opção era que o sistema não havia sido escrito com perspectivas de mudança e, a cada novo requisito que surgia, mais código era replicado ou criado em no local mais conveniente naquele momento, o que tornou o código bastante confuso.

Surgiu então a idéia de, aproveitando o máximo de código pronto, criar um framework, ou seja, uma bibioteca de classes. Essa biblioteca deveria não somente solucionar o caso do Together, mas também proporcionar uma produção de novos sistemas a partir dos pacotes desenvolvidos. Dessa forma, teríamos módulos cada vez mais evoluídos, tornando a correção necessária apenas uma vez e num só trecho de código.

Para realizar a identificação de requisitos, adotei o conceito de cenários, descrita na seção intitulada Requisitos.

2. Identificação de Padrões de Projeto

Padrões de projeto são soluções elegantes e reutilizáveis para problemas recorrentes que encontramos diariamente no processo de desenvolvimento de aplicativos para o mundo real. Eles tratam da concepção e da interação entre objetos, definindo um padrão de comunicação que é compartilhado por toda a equipe de desenvolvimento.

Pensando em melhorar o que já fora desenvolvido e garantir o futuro do framework, pesquisei alguns livros ([4] e [5]) sobre padrões de projeto e procurei identificá-los no software a fim de implementá-los posteriormente. Alguns dos padrões identificados foram:

• MVC : o design de 3 camadas do MVC encaixava-se perfeitamente na divisão dos macro-aspectos do sistema (modelo, visão e controle) e habilitava uma nova solução a corrigir os erros nas camadas:

1. Visão: por ser um modelo de negócio vendido a vários clientes, era necessário que a visão fosse o mais desacoplada possível. Além disso, visões diferentes deveriam ser oferecidas para "atores" com interesses diferentes. Por exemplo, gerentes e operadores de telemarketing não devem ter acesso aos mesmos tipos de dados.

2. Controle: a camada de interação com o banco de dados era desorganizada e dispersa. Foi criada uma unidade de conexão no framework, tornando todas as transações transparentes ao sistema gerenciador de banco de dados usado.

3. Modelo: o modelo correspondia ao banco de dados em si, que está fora do escopo do meu estágio, já que existe uma equipe responsável por esta parte.

• Singleton : é um padrão de criação de objetos cujo objetivo é garantir uma instância única e acessível de forma global e uniforme. Foi utilizado em várias classes que no projeto anterior eram usadas como referências a variáveis globais ou instanciadas diversas vezes sem necessidade.

• Adapter : permite a comunicação entre classes que não poderiam trabalhar juntas devido à incompatibilidade de suas interfaces. A unidade de integração com o banco de dados implementa esse padrão.

• State : uma mesma interface do Together deveria poder ser usada em vários países de línguas diferentes. Esse padrão permite a um objeto alterar o seu comportamento quanto o seu estado interno mudar. Assim, bastaria o usuário indicar que língua tinha como preferência (essa informação era guardada no banco de dados) para o sistema passar a usá-la.

• Interpreter : o Together tem uma funcionalidade especial chamada infoextra que consiste em permitir que a interface gerencial crie formulários para que os operadores de telemarketing preencham junto aos clientes. Esse padrão foi usado pois uma pequena linguagem teve de ser criada, sendo interpretada em código html e .Net.

Os padrões de projeto acima estão mais detalhadamente explanados na seção Padrões de Projeto.

3. Modelagem do sistema

A identificação dos padrões deu início à modelagem do sistema em si. A partir de então, os primeiros diagramas de classes foram desenvolvidos e, para corrigí-los numa segunda versão, construí diagramas de casos de uso e de sequência. Para ajudar a projetar melhor o software, tentei paralelamente outra abordagem, que foi a de seguir uma modelagem baseada em componentes (utilizando [7]).

O desenvolvimento de software baseado em componentes produz um sistema bastante robusto e completo, já no primeiro ciclo. A familiarização com o processo desenvolvido no livro pôde ainda diminuir o tempo de projeto e desenvolvimento de software, já que as fases são bem definidas e mostram avanços no projeto que estimulam o desenvolvedor a seguí-las.

Além disso, o processo produz componentes facilmente substituíveis, cumprindo o seu principal objetivo. Módulos bem implementados podem ser aproveitados em outros sistemas, bastando conhecermos sua interface, o que diminui o acoplamento. Por fim, como qualquer método de programação modular, o método estudado possibilita a construção de sistemas complexos, tais como o Together, pois podemos dividi-los em partes menores, mais simples de implementar.

A seguir, um exemplo de diagrama usado na modelagem com UML Components:

O diagrama acima representa o Business Concept Model [7] referente ao caso de criação de companhia. Esse diagrama está ligado a um requisito importante que mudou da versão antiga para o framework do Together. Antes não era obrigatório a inserção de um RFC único (RFC é o correspodente ao CNPJ no México) nem de uma matriz para poder ser inserida uma companhia. As novas regras também exigem que para uma matriz seja inserida, temos que apresentar um código postal único. Não tivemos problema em considerar o CEP como chave pois empresas geralmente não são vizinhas. Finalmente, optamos por não obrigar um e-mail exlcusivo pois às vezes muitos contatos apresentavem o e-mail geral da empresa ou mesmo mudavam de uma empresa para outra.

Esses e outros cenários de eventos foram modelados utilizando a teoria dos casos de uso e a modelagem baseada em cenários, descrita na seção de Modelagem do Sistema.

4. Desenvolvimento

O grande desafio da fase de desenvolvimento foi que o Together era um sistema pronto e em uso. Assim, tive de desenvolver blocos de software que pudessem resolver o mais rapidamente possível os erros dos quais os clientes reclamavam sem com isso retirar

funcionalidades do sistema. A solução encontrada foi montar um cronograma de desenvolvimento que permitisse manter a interface com o usuário, mas refatorando o sistema.

O software possuía por volta de 60 classes. Algumas foram agrupadas e outras subdivididas segundo a modelagem feita, e o cronograma foi montado de forma que a cada passo fosse substituído um conjunto de classes com efeitos comuns.

Para que não fosse percebido pelos clientes que o sistema estava sendo modificado, gerando erros ou emitindo mensagens indevidas durante essa etapa, eu dispunha de um sistema de teste, onde tinha liberdade para desenvolver sem me preocupar com eventuais erros durante o processo.

Cada substituição exigia uma bateria de testes, parte manual, parte automatizada (veja abaixo). Algumas vezes eu disponibilizava a interface de teste para os gerentes responsáveis pela conta do HP Together e para o gerente de TI, para que eles também verificassem o seu bom funcionamento. Sempre que tinha oportunidade eu fazia isso, pois os testes manuais feitos por eles não eram viezados como os meus e em boa parte das vezes envolviam casos que eu não havia previsto. Dessa forma o problema era corrigido antes de chegar ao cliente e eu ainda podia melhorar os testes unitários.

Para assegurar o histórico das versões submetidas foi usado o VSS - Microsoft Visual SourceSafe [8] -, um servidor de versão que dispõe de tarefas como verificar, submeter, intercalar e reverter versões de software. As poucas vezes em que efetivamente foi necessário o uso de reversão já valeram o esforço de configurar e utilizar esse burocrático servidor, pois desfazer o código escrito é muito dispendioso e cansativo, além de gerar erros.

5. Testes

Simultaneamente ao desenvolvimento, foram realizados testes de unidade. Testes unitários automatizados permitem exercitar o código sobre uma bateria de testes, provendo um feedback imediato durante o desenvolvimento. Quando pode-se testar mudanças no código para validá-lo, os erros se tornam aparentes imediatamente. O código se torna simples e os testes provêem um grande exemplo de documentação.

Utilizei o NUnit [6] como framework de testes. Ele é totalmente escrito em C# mas comunica-se com qualquer linguagem da platadorma .Net. Os testes foram executados para cada classe ou conjunto de classes com funcinalidades afins e, ao contrário do que meu chefe acreditava inicialmente, programar ao mesmo tempo o sistema e os seus testes foi de grande valia para o bom andamento do projeto. Sem eles a correção de erros seria bastante difícil e trabalhosa.

Os testes de unidade não objetivam sanar todos os erros. Mesmo para torná-los úteis já há um grande esforço, sendo bastante difícil fazer bons testes. Mas eles têm grande utilidade como uma primeira barreira contra erros e valem a pena serem implementados, tornando-se fundamentais em sistemas de grande ou médio porte, como o Together.

Identificação de Requisitos

Introdução:

O antigo Sistema Together possuía diversas falhas estruturais e não atendia mais às regras de negócio, pois os processos e protocolos seguidos dentro da empresa sofreram muitas modificações e ele não tinha sido projetado para ser flexível a grandes mudanças. Contudo, não havia tempo para um projeto totalmente novo pois ao mesmo tempo que o sistema deveria sofrer modificações para se enquadrar ao novo contexto, o seu funcionamento não poderia ser interrompido. Dada a situação busquei no conceito de Cenários ([10]) uma forma elegante de solucionar esse impasse.

Cenários:

Pessoas sem conhecimento técnico de computação têm uma grande dificuldade de expressar os requisitos do software que desejam. Uma maneira mais natural de expor as funcionalidades seria montar uma série de ambientes de interação, onde cada um possui descrições de eventos aos quais responde. Esse é justamente o conceito de cenário.

A reação a cada evento pode:

• Modificar o cenário atual: no caso de preenchimento de formulário, por exemplo, ao inserir os dados nos campos obrigatórios passamos de um estado inicial, no qual não era possível a submissão do formulário, para um estado que atende aos requisitos necessários para que o formulário possa ser submetido.

• Trocar de cenário: ao submetermos um formulário com os dados esperados, podemos passar a um próximo cenário, que poderia ser o preenchimento de um segundo formulário ou o próprio cenário inicial do sistema.

• Gerar um erro: podemos inserir dados incorretos e o evento gerar um erro. Esses erros também devem estar previstos no cenário, bem como seus respectivos tratamentos.

A fim de utilizar cenários numa abordagem mais estruturada, onde possamos aproveitar os resultados na modelagem do sistema, criamos os diagramas de casos de uso a partir dos cenários.

Para exemplificar, vejamos os cenários dos chamados ativos:

• Ativos são quaisquer contatos entre os agentes de telemarketing e as revendas. • Para existirem no sistema, eles devem ser inseridos pelo gerente de

telemarketing. Na inserção do ativo cadastramos informações como intervalo de tempo em que ele deve ser realizado e descrição.

• Inserido o ativo, o gerente deve especificar para quais empresas esse ativo será utilizado, ou seja, com quem os agentes de telemarketing deverão falar. Isso é chamado de mailing.

• Cada agente de telemarketing tem um conjunto de revendas sobre as quais tem responsabilidade. Esse conjunto é chamado de carteira e é definido pelo gerente.

• Postado o ativo, os operadores de telemarketing verificam se as empresas que entraram naquele ativo pertencem à sua carteira através da verificação de pendências.

• Se houver alguma pendência de ativos, o operador deve contactar as revendas e preencher o formulário correspondente.

• Uma vez finalizado o ativo, o gerente tem a possibilidade de visualizar relatórios de ativos gerados dinâmicamente pela interface.

Esses cenários nos levam a criar alguns casos de uso. Eis o diagrama:

O diagrama acima descreve os vários casos de uso relacionados à manipulação de ativos. Cada caso de uso deve possuir uma descrição mais detalhada que nos oriente a identificar os objetos no sistema e compreender o que o sistema deve realizar. O quadro abaixo descreve o caso de uso Especificar Carteira:

Sistema Manipulação de Ativo

Use-case Especificar Carteira

Agentes Gerente de Telemarketing

Dados Os identificadores das empresas que participarão da carteira e os operadores de telemarketing que receberá essa carteira.

Estímulo O gerente, ao manpular o cadastro dos agentes, especifica as empresas que participarão da carteira de um determinado agente.

Resposta As empresas relacionadas na carteira ficarão sob a responsabilidade do seu respectivo agente através do relacionamento gerado no banco de dados.

Comentários Em geral, as carteiras modificam-se pouco pois é preferível que os agentes estejam mais familiarizados com o seu grupo de empresas. Empresas das carteiras

podem ser divididas com o intúito de equilibrar a carga de trabalho dos agentes.

Padrões de Projeto

Introdução

Assim como na maioria das ciências, na computação os problemas se repetem. Os requisitos de vários sistemas terminam por revelar uma certa semelhança nas suas estruturas e, historicamente, surgiu a necessidade de apresentar soluções elegantes e eficientes que fossem reutilizáveis em todos esses casos. Elas deveriam ser genéricas o suficiente para não descrever apenas um pequeno conjunto de casos mas também específicas o suficiente para resolver a contento aquilo a que se propunha. Surgiram assim os Padrões de Projeto, que vêm ganhando uma enorme importância, principalmente no mundo OO.

Durante o processo de desenvolvimento do framework, procurei encontrar nas necessidades do sistema problemas que se encaixassem nos padrões de projeto, especialmente os do livro do "GOF"[4], com os quais tinha maior familiaridade, pois os havia estudado em Programação Orientada a Objetos. Eis alguns dos principais padrões utilizados, seguidos de exemplos reais de utilização no sistema:

1. Singleton (130)

É importante para algumas classes possuir apenas uma instância, ou simplesmente controlar o número de instâncias existentes. Singleton é um padrão que provê exatamente esse controle. Evitando a criação de uma variável global (pois mesmo com ela não garantimos a unicidade da instância), esse padrão disponibiliza o método instance() como única forma de instanciar a classe. Dessa forma, se já existe uma instância, a classe Singleton apenas a devolve como resposta à chamada do construtor :

Apesar de ser um padrão de simples implementação, o Singleton possui uma vasta aplicabilidade. No desenvolvimento do framework existiam muitas classes instanciadas repetidamente em uma sessão. Apliquei o padrão em algumas delas: AddressType, AlternativeType, EmailType, TelephoneType. Particularmente, no caso da conexão com banco de dados, essa nova implementação aumentou a eficiência do sistema pois antes era possível, por falha da implementação, várias conexões simultâneas com o banco de dados, muitas delas ociosas. Na nova implementação, no máximo uma conexão estará aberta.

2. Adapter (140)

A intenção do padrão Adapter é converter uma interface de classe em outra, esperada pelo cliente. Ele proporciona ao sistema a mudança futura de uma classe e mesmo de sua interface mantendo todo restante intacto. Para isso, basta desenvolver o adaptador (Adapter) que forneça a interface já conhecida pelo sistema. Existem dois tipos de implementação deste padrão:

• Para Classes : utiliza-se de herança múltipla - da classe que apresenta a interface do domínio do cliente (Target) e da classe adaptável (Adaptee) - para implementar a interface;

• Para Objetos : o Adaptador implementa a interface - através de herança - e delega as funcionalidades à instância da classe Adaptee que possui.

Esse padrão foi utilizado na classe responsável pela conexão com o banco de dados pois a biblioteca de acesso a bancos de dados que a linguagem VB.Net possui não possui uma interface muito amigável. Implementei o Adapter para objetos, delegando as funcionalidades para as classes nativas e adaptando-as ao sistema:

Dessa forma, a interface detalhada e complicada do conjunto de classes nativas usadas para acessar o banco de dados é trocada por outra mais simples e de mais alto nível.

3. State (284)

Há casos em que o comportamento de um objeto depende do seu estado e as suas operações têm comandos condicionais grandes, freqüentemente usados em várias operações, espalhadas por vários pontos do sistema. Nesses casos é interessante aplicar o padrão State, que através do polimorfismo da classe que representa o estado oferece uma interface única, implementada pelos diversos estados existentes:

O Sistema Together é usado em países como Brasil, México, Bolívia, Equador e outros países da América do Sul, onde falam-se línguas diferentes e se faz necessária a

tradução de todas as mensagens usadas. Para tanto, implementei a classe abstrata Language, que apresenta a interface de mensagens e as classes concretas correspondentes a cada língua.

Abaixo temos um trecho de código da classe abstrata e os métodos da página de login:

E suas respectivas implementações e resultados em português...

... e em espanhol do México:

4. Interpreter (231)

Gramáticas simples não precisam ser interpretadas por códigos criados através de geradores de analizadores sintáticos. Para isso, podemos criar uma simples hiearquia de classes baseada na gramática que, através de recursão, devolve a interpretação do código de entrada. É justamente isso que apresenta o padrão Interpreter: uma solução elegante na interpretação de pequenas gramáticas.

O Sistema Together permite aos supervisores a criação de formulários extras para serem preenchidos pelos operadores de telemarketing. Esses formulários seguem um padrão simples, onde se pode adicionar perguntas através de CheckBox, Text, Label, TextArea ou DropDown. A tela de edição desses formulários segue abaixo:

A solução para este problema é dada pela gramática abaixo:

infoExtra : label | textBox | dropDown | textArea | checkBox | infoExtra & infoExtra

Esta gramática, basenado-se no padrão Interpreter, nos leva a estrutura de classe da figura abaixo:

Perceba que temos um problema pequeno, facilmente modelável, em que não vale a pena utilizar ferramentas que gerem um código interpretador. Assim, o Interpreter se encaixa perfeitamente nesse caso. Note que a eficiência não é uma preocupação crítica, pois os formulários nunca são muito grandes e demorar um segundo para carregar uma página não é considerado lento.

5.MVC

Todos os sistemas interativos precisam fornecer algum meio de apresentar as informaçoes aos usuários.Uma boa prática de projeto de sistema é manter o software requerido para apresentar as irformações separado das próprias informações. Isso contradiz, até certo ponto, a filosofia orientada a objetos, pois segundo ela as operações que envolvem os dados devem estar encapsuladas juntamente com os próprios dados. Apesar disso o MVC (Model - View - Controler) é um padrão amplamente usado na comunidade OO.

A abordagem MVC surgiu primeiramente associada a Smalltalk. Esse padrão constitui um meio eficaz de trabalhar com várias apresentações de dados. Os dados, por sua vez, ficam encapsulados em um modelo de objeto. Podemos ter várias visualizações para um mesmo modelo de dados, e o usuário tem a possibilidade de usar várias delas, dependendo da sua necessidade. Cada visão possui um objeto controlador associado que manipula a entrada do usuário e a interação de dispositivos.

O MVC, tal como foi utilizado no framework do Sistema Together, é representado no diagrama abaixo:

Modelagem do Sistema

Introdução:

Uma vez identificados os requisitos, através dos cenários e casos de uso, e as boas práticas de programação, através do uso de padrões de projeto, temos recursos suficientes para modelar o sistema.

As classes mais facilmente identificáveis são aquelas que estão fortemente relacionadas com o banco de dados, possuindo uma entidade correspondente no mesmo. O diagrama UML das principais classes do sistema pode ser visto aqui.

Identificação de Objetos:

Através da descrição detalhada dos casos de uso e de seus diagramas, podemos identificar os objetos do sistema. Na verdade, tentamos definir as classes de objeto pois o projeto é descrito em termos dessas classes, ou seja, pretendemos determinar os participantes "reais" (classes concretas) para depois modelar o sistema de forma que ele opere eficientemente e que seja reutilizável.

Existem vários métodos para identificar as classes de objetos. Utilizamos uma análise baseada em cenários, compatível com a metodologia usada na identificcação de requisitos. Nesse método, os vários cenários gerados na etapa anterior são analizados a fim de identificar objetos, atributos e operações.

Voltemos ao caso da manipulação de ativos. Através das descrições dos casos de uso podemos identificar as classes abaixo:

• Usuario: essa classe de objetos engloga dois objetos identificados inicialmente: Gerente e Operador;

• Carteira: representa a coleção de empresas relacionadas a um operador; • Ativo: classe que encapsula os dados de cada ativo; • Site: representa uma revenda. Site foi o nome escolhido para representar um

local físico de uma companhia. Já está contido no diagrama das classes principais.

O diagrama com um esboço das classes e seus relacionamentos está ilustrado abaixo:

O Sistema Channel Monitor Introdução

Channel Monitor é um sistema em J2ME utilizado por funcionários da ITM chamados de agentes móveis e tem o objetivo de detectar com rapidez as açães de concorrentes no canal alvo. Esse sistema trabalha em conjunto com o Hp Together e funciona oferecendo aos agentes uma interface de banco de perguntas a serem feitas aos revendedores do canal.

Essas perguntas são enviadas ao agente via conexão GPRS [12], que no ambiente da própria revenda, as responde. As respostas são enviadas ao servidor, armazenadas no banco de dados, tabuladas e disponibilizadas em uma interface web para análise dos consultores de marketing.

Contribuições

As minhas contribuições a esse projeto foram dadas em conjunto com outras pessoas da equipe. Desenvolvemos o módulo que faz a comunicação GPRS e os novos formulários foram criados após termos assumido o projeto. Assim como o Together, o Channel Monitor já estava escrito. Porém, até mesmo por ser um sistemas mais simples, possuía uma estrutura melhor e não achamos necessário refatorá-lo.

A primeira versão do Channel Monitor usava o protocolo WAP [11]. WAP é a sigla de Wireless Application Protocol (Protocolo para Aplicações sem Fio), um conjunto de especificações que caracteriza um ambiente similar à Web, voltado para redes de aparelhos sem fio e em velocidades mais baixas, basicamente os telefones celulares. Apesar de funcionar, o sistema era comercialmente inviável, pois uma vez conectado pelo protocolo, não há desconexão até a completa transferência de dados. Como a

tarifação da telefonia celular para conexão com internet é por minutos, a visita de um agente móvel saía muito cara para a empresa.

A solução encontrada foi usar WAP sobre GPRS (General Packet Radio Service). Os GPRS incluem o uso eficaz de recursos, acesso on-line instantâneo e entrega rápida de informações. Essa solução permitiu que fossem feitos "bursts" de trocas de dados intercalados com outros sem conexão. Como a maior parte do tempo um agente móvel passa realizando as perguntas e preenchendo os formulários, essa nova implementação gerou uma economia considerável nos gastos.

Uma dificuldade ao usar o GPRS foi que constatamos falhas de conexão e entregas incompletas de dados, gerados por falhas nos serviços prestados pelas operadoras de telefonia celular. Uma das causas era a banda oferecida pela operadora, que não era suficiente para atender a todos os clientes, e em dias onde, tipicamente, muitas pessoas usam serviços de mensagens, como dia dos namorados, dos pais e das mães, dificilmente conseguíamos sucesso nas transferências de dados sem fio.

Para suprir essas falhas implementamos um módulo de consistência que mantinha o formulário armazenado na memória do celular enquanto os dados não eram enviados através do servidor para o banco de dados. O Channel Monitor tentava enviar os dados de tempos em tempos e, em dias de tráfego ruim, os dados eram transferidos para o banco através de cabos, quando o celular estava na própria empresa.

Minha outra contriuição no Channel Monitor foi implementar novos formulários de perguntas. Um fato que percebi programando em J2ME foi que temos muito menos recursos do que na programação para desktops, então, mesmo tarefas simples como esses formulários, tornam-se complicadas de desenvolver e testar.

O Uso do R na Mineração de Dados

Há alguns meses vem surgindo uma nova necessidade no sistema Together e em similares oferecidos a outros clientes. Os sistemas são bastante eficientes em acumular dados pois o formato web e a abordagem ativa de ir até a fonte buscar os dados produz resultados satisfatórios. No entanto, a análise desses dados e a geração de relatórios mais complexos como, por exemplo, análise multi-dimensional e multi-variada(por estado e faturamento, ou por venda de uma certa linha de produtos por espaço de tempo) deve ser feita manualmente, usando ferramentas proprietárias, gerando gastos e consumindo tempo.

Com o objetivo de automatizar esse processo, estou, no momento, pesquisando a respeito do R [9], um ambiente desenvolvido para computação estatística e para a geração de gráficos. Por ser uma linguagem funcional, o R facilita a manipulação de dados. Além disso, ele é um sofware livre e já dispõe de bibliotecas estatísticas e gráficas completas que permitirão realizar análises e apresentá-las de uma forma amigável no ambiente web. É possível criar rotinas de scripts, que serão interpretadas pelo R, que por sua vez devolverá os gráficos que serão apresentados na interface do sistema.

Para implementar esse sub-sistema, criamos o conceito de alarme. Alarmes são índices estatísticos que visam o controle de aspectos relacionados às vendas. Podemos configurar um alarme para que ele possa estar vermelho, amarelo ou verde, dependendo do nível de atenção que devemos ter com determinada revenda. Uma revenda com um alarme em vermelho significaria que ela requer atenção, enquanto uma em verde, que está tudo bem em relação a esse critério.

Suponha, por exemplo, que criamos um alarme visando detectar quais empresas tiveram maior redução percentual no seu faturamento deste ano fiscal. Observe que isso não é tão simples quanto parece, pois devemos levar em conta a média de faturamento total, a variância do faturamento dos meses anteriores e até mesmo fatores sazonais ou influenciados por datas comemorativas e lançamentos de novos produtos: o faturamento na venda de desktops aumentado no mês de natal é normal, enquanto a redução na venda de uma impressora após o lançamento de uma com tecnologia superior deve ser tratada de forma especial.

Atualmente, estamos fazendo os primeiros testes com os alarmes. A linguagem oferecida pelo R não vem se mostrando tão eficiente na programação de scripts que interajam com as páginas web. Portanto estou pesquisando qual a melhor linguagem de script para usar nesse caso: Ruby ou Perl. Perl tem a vantgagem de existir há mais tempo e, portanto, possuir mais documentação, fórums e livros disponíveis. Ruby é uma linguagem nova, que promete desenvolvimento de curtíssimo tempo e é totalmente orientada a objetos. Ambas possuem integração com a web e interface de conexão com bancos de dados. Os testes, porém, me levam a acreditar que Ruby será escolhida, por facilitar a programação orientada a objetos.

Escolhemos um aspecto (faturamento por região por intervalo de tempo) e estou desenvolvendo uma série de rotinas que permitam gerar resultados aproveitáveis. Creio que será um grande desafio finalizar esse sistema e integrá-lo ao framework gerenciador de canais que desenvolvi ao refatorar o Together, mas também acredito que será bastante recompensador chegar ao fim desta etapa e constatar que o progresso obtido nos métodos de interpretação de dados manipulados pela empresa teve a minha contribuição.

Parte Subjetiva

Objetivos e Desafios

Meu principal objetivo ao procurar um estágio foi conhecer na prática como funciona todo o processo de desenvolvimento de um software num ambiente corporativo, para perceber como os conceitos vistos em sala de aula (e no desenvolvimento dos exercícios-programa) podem ser aplicados num contexto real de uma empresa. Meu primeiro contato com o estágio foi em 2004, no entanto, minhas expectativas não foram satisfeitas a contento, visto que não tive a oportunidade de desenvolver nada mais que scripts e obter a experiência em atender aos usuários na rede do CEC.

Além disso, eu estava muito interessado em conhecer as linguagens, os frameworks e as comunidades de desenvolvimento ligados ao mundo .Net, já

que na faculdade não temos oportunidade de entrar em contato com elas e que o mercado de trabalho muitas vezes exige conhecimentos de linguagens comerciais. Na ITM tive a oportunidade de me familiarizar com esse assunto ao mesmo tempo que desenvolvia o Together. No decorrer do ano, percebi que seria necessário aprender muito mais coisas além do que eu imaginava e esta experiência foi algo bastante desafiador.

Meu maior desafio foi, no entanto, ter desenvolvido a biblioteca de classes para o desenvolvimento de sistemas gerenciadores de canais. Tive muito orgulho de ter participado da sua concepção e do seu desenvolvimento pois o resultado foi bem melhor que o esperado. O sistema Together tinha o apelido de "Forever" dada a quantidade de problemas e trabalho que ele dava a quem o tinha sob sua responsabilidade. Quando cheguei na empresa, recebíamos da HP algo em torno de cinco e-mails de reclamação de erros por dia. Durante o processo de desenvolvimento esse número foi sendo reduzido e, ao final do processo, não recebíamos mais reclamação alguma.

Quando decidi entrar na ITM, meu intúito era prover ferramentas tecnológicas para profissionais de gestão. Ao desenvolver sistemas para uma área não voltada à computação usando os meus conhecimentos adquiridos na faculdade, pude obter um conhecimento resultante da união das estratégias de marketing com a ciência da computação. Espero sempre poder trabalhar no riquíssimo ramo da tecnologia da informação, que une os assuntos pelos quais tenho maior interesse.

Ambiente de Trabalho

O clima do ambiente de trabalho era bastante agradável pois, a princípio tinha que lidar com pessoas que eu não conhecia, mas com facilidade e em pouco tempo me integrei com a equipe. Isso ajudou bastante, especialmente no começo, durante a fase de adaptação, quando eu não estava a par da rotina na empresa, desde as formalidades, como a complexa hierarquia da empresa, até as ocasiões mais informais e corriqueiras, como os locais de almoço e os "happy hours".

A equipe de desenvolvimento de software da qual fazia parte era composta por mais dois desenvolvedores, o gerente de TI, que era nosso superior imediato, e o professor Alfredo Goldman, consultor da empresa e meu orientador. Geralmente, cada projeto ficava sob responsabilidade de um desenvolvedor, com excessão do Channel Monitor, que tinha relação com mais de um sistema. A despeito disso, sempre trocávamos experiências, oferecendo e requisitando ajuda quando necessário.

No segundo semestre desse ano, a ITM mudou de localização. Antes da mudança, o novo local foi totalmente planejado e reformado. O ambiente físico de trabalho ficou mais moderno e organizado, o que refletiu no clima dos próprios funcionários e estágiários, aumentando a auto-estima de todos e até a produtividade. A mudança para a nova sede mostrou que a empresa está em crescimento e que eu tenho muitas oportunidades de alcançar satisfação profissional junto a ela.

Apesar de haver uma hierarquia formal na empresa, sempre tive acesso direto ao Glauro, meu superior, com quem trocava idéias acerca dos projetos, de como poderíamos apresentar os dados e sobre as ações prioritárias. Também conversava bastante com o Alfredo, tanto na USP como na própria empresa, a respeito das dificuldades nas tarefas e dos resultados obtidos. Ele sempre dava contribuições pontuais mas de grande importância para o andamento do meu trabalho.

Estágio X IME

Posso destacar como diferenças entre o trabalho no estágio e o curso de graduação no IME vários pontos. Um deles diz respeito aos prazos. No IME temos prazos estabelecidos e cumprí-los faz parte das responsabilidades dos alunos. O estágio, por sua vez, não atrelava prazos às tarefas atribuídas. Isso a meu ver era desfavorável ao bom andamento das atividades, pois acredito que prioridades devem sempre estar sendo estabelecidas de modo a garantir que seja dada a devida importância a aspectos comerciais e estratégicos que sejam do interesse da empresa.

Outro aspecto divergente é que, no estágio, há uma maior rigidez com relação a erros, pois o cliente freqüentemente é bastante exigente quanto à qualidade do produto que estão adquirindo, algumas vezes faz exigências até mesmo inviáveis. No IME estávamos certos de que as cobranças eram feitas com responsabilidade e por profissionais e/ou monitores que conheciam o assunto do qual tratavam. No estágio, as pessoas que utilizavam os sistemas por mim desenvolvidos não tinham familiaridade com os detalhes de sistema e, muitas vezes, pouco conheciam sobre computadores. Com isso, aprendi a programar de maneira mais conveniente aos usuários leigos , tentando tratar todos os possíveis erros, independente da probabilidade de seu acontecimento ser alta ou baixa.

Além de cercar meus softwares de proteções para usuários despreparados, aprendi a sempre criar interfaces amigáveis. Quando desenvolvia exercícios-programa, a minha intenção era fazê-lo funcionar corretamente de acordo com a especificação pedida e da forma mais eficiente possível, sem me preocupar com a camada de interação com o usuário. Na empresa, vi que existia uma equipe especializada em web design, o que indicava que uma aparência agradável e uma boa disposição das informações na tela muito contribui para o sucesso de um sistema de software, e portanto deve ser considerada.

Uma das semelhanças entre o estágio e o BCC é a importância dada à documentação. No IME, a importância era mensurada através das notas dadas pelos monitores que precisavam de um aboa documentação para entender o código para avaliá-lo. Na ITM, de maneira semelhante, tive que dedicar bastante tempo à documentação do framework, já que outros desenvolvedores iriam utilizá-lo como base de outros sistemas gerenciadores de canal. A experiência adquirida na graduação me deu suporte para documentar de forma adequada, inclusive os colegas de trabalho que não utilizavam códigos documentados elogiaram esse procedimento e tentaram passar a utilizá-lo.

Tanto no estágio quanto no IME (na disciplina de Engenharia de Software) aprendi que testes automatizados são de fundamental valor para um desenvolvimento mais eficiente e eficaz. No caso do Together, os teste unitários com NUnit tornaram o software mais robusto e confiável. Apesar de não garantir a ausência de erros e de uma boa bateria de

testes ser de difícil desenvolvimento, eles são praticamente obrigatórios como uma ferramenta na criação de sistemas de médio e grande porte.

Finalmente, um fator importante que devo considerar é a flexibilidade dos horários na ITM. Lá eu tinha uma carga horária semanal que podía ser distribuida por mim como eu bem entendesse, apenas importando o cumprimento das tarefas programadas. Essa liberdade foi indispensável para que eu conciliasse o estágio com a graduação, principalmente no segundo semestre, onde tive uma carga didática pesada devido às matérias pendentes.

Disciplinas Relevantes

A meu ver, a formação que o BCC dá aos alunos é muito ampla e, sem dúvida, muito valiosa. A relevância de cada disciplina depende da área interesse do estudante, bem como das exigências do mercado de trabalho ou do ambiente científico, mas a minha maior lição no curso foi aprender a aprender. Como computação é uma ciência relativamente nova e em constante evolução, estar sempre interessado em aprender sobre as novas tecnologias é de suma importância para ser um bom profissional.

Todas as disciplinas são importantes para a construção do currículo abrangente oferecido pelo BCC. Abaixo cito as que mais ajudaram no estágio e no meu desenvolvimento como pessoa e como profissional:

Disciplina Nome Comentários

MAC110 Introdução à Computação

Nunca havia programado e 110 me proporcionou o primeiro contato com programação. Aprendi sobre a linguagem C e linguagens procedurais em geral

MAC122 Princípios de Desenvolvimento de Algoritmos

Uma das matérias mais importantes na minha opinião. Deu uma base sólida a respeito de algoritmos, ponteiros e o que aprendi nessa disciplina é relevante até hoje para o meu trabalho.

MAC211 Laboratório de Programação

Tive minha primeira oportunidade de trabalhar em grupo, percebendo seus prós e contras. Também aprendi sobre expressões regulares e como funcionam os compiladores.

MAC242 Laboratório de Programação II

Minha primeira oportunidade de aprender Java e programação orientada a objetos. Conheci também um pouco sobre python.

MAC426 Sistemas de Banco de Dados

Aprendi sobre o modelo Entidade-Relacionamento e sobre consultas SQL, os utilizo bastante no meu estágio.

MAC441 Programação Orientada a Objetos

Conheci o real significado da programação orientada a objetos através da linguagem Smalltalk, observando padrões e

entendendo a reutilização de código.

MAC332 Engenharia de Software

Essa matéria foi de fundamental importância dentro do estágio pois ao conhecer os processos de produção de software pude aplicá-los ao Together. Senti as dificudades, mas em contrapartida as vantagens de se utilizar esses métodos. Além disso, aprendi a utilizar testes unitários, que me foram muito úteis, tanto na discplina quanto no estágio.

MAC413 Tópicos de Programação Orientada a Objetos

O modo como essa matéria foi conduzida foi muito interessante pois nos deu quatro visões e experiências diferentes: naked objects, programação orientada a aspectos, design fest e o conceito de metaclasses.

MAC340 Laboratório de Engenharia de Software

Ao desenvolver o projeto dessa disciplina usando UML Components pude adquirir experiência para então aplicar a idéia no projeto do estágio. Isso ajudou bastante para a modelagem do framework.

Vale destacar que as disciplinas optativas livres estimulam os alunos a conhecer outras unidades da USP. Isso foi muito proveitoso, pois percebi que tinha interesses em diversas áreas. Cursei as optativas na FEA e agora pretendo estudar mais sobre os assuntos lá aprendidos, principalmente tecnologia da informação.

Considerações Finais

Conclusão:

É possível viver no BCC, inclusive sendo possível estagiar e terminar o curso em 4 anos. Ao contrário do que alguns pensam, acho que o estágio é de fundamental importância para a formação de um aluno de graduação no IME e, por outro lado, que o curso de Bacharelado em Ciência da Computação é de fundamental importância para a formação de bons profissionais, preparados tecnicamente, para desenvolver sistemas computacionais, e pessoalmente, para melhorar o mundo em que vivemos.

Agradecimentos:

Gostaria de agradecer a todos que me ajudaram durante os 4 anos que estudei no IME. Em especial, agradeço à minha família por, mesmo à distância, tanto ter me ajudado e apoiado desde o princípio, e à minha namorada pela compreensão, já que estudar no BCC às vezes exige dias e noites de esforço e terminamos usando um tempo que não é nosso para isso. Por fim, mas não menos importantes, lembro aqui as turmas do BCC

2002, com quem ingressei na faculdade, e do BCC 2003, com quem me integrei durante o curso.

Referências:

[1] Microsoft .NET - http://www.microsoft.com/net [2] Microsoft SQL Server - http://www.microsoft.com/sql [3] Java 2 Micro Edition (J2ME) - http://java.sun.com/j2me [4] GAMMA, Eric; HELM, Richard; JOHNSON, Ralph; VLISSIDES, John. Design Patterns - Elements of Reusable Object-Oriented Software . Addison-Wesley, 1995. [5] GRAND, Mark; MERRILL, Brad. Visual Basic .Net Design Patterns. [6] NUnit - http://www.nunit.org/ [7] CHEESMAN, John; DANIELS, Jonh. UML Components - A Simple Process for Specifying Component-Based Software. [8] Microsoft Visual SourceSafe - http://msdn.microsoft.com/ssafe/ [9] The R Project for Statistical Computing - http://www.r-project.org/ [10] SOMMERVILLE, Ian. Engenharia de Software. 6.ed. Addison-Wesley, 2003. [11] Open Mobile Alliance - Technical Section - http://www.openmobilealliance.org/tech/affiliates/wap/wapindex.html [12] GSM World - http://www.gsmworld.com/technology/gprs/index.shtml