Escolhas de Projeto

Atualmente existem diversas ferramentas, aplicativos e componentes que auxiliam o processo de desenvolvimento de um software. Uma seleção correta desses artefatos, adequados às necessidades do projeto, pode reduzir consideravelmente o esforço de desenvolvimento, facilitando a organização e documentação.

4.2.1. Ferramentas

A ferramenta utilizada para codificação do sistema foi o Eclipse 3.2 [16], de licença gratuita e bastante utilizada por desenvolvedores. O Eclipse possui uma interface fácil de usar e recursos que permitem identificar erros no código no momento da edição, o que economiza tempo de depuração. Integrada ao Eclipse, outra ferramenta bastante utilizada foi o Ant, que auxilia na compilação e empacotamento das classes, através de um arquivo de regras XML.

Para trabalhar com o banco de dados foi utilizado o DBManager 3.1 [17], outra ferramenta de licença livre para gerenciamento dos dados.

O programa Openwave SDK 6.2 [18], de licença livre, permitiu a simulação da

interface wap para celular.

4.2.2. Aplicativos e Componentes

O servidor de aplicação J2EE adotado foi o JBoss 4.2.0 [8], uma das implementações mais utilizadas, com ampla documentação disponível na Internet. O JBoss contém o container EJB, que executa os componentes EJB da camada de negócios do sistema, controlando seus ciclos de vida e realizando outros serviços de infra-estrutura, e o container Tomcat, responsável por executar os códigos JSP e Servlet presentes na camada de apresentação do sistema.

O servidor de banco de dados utilizado foi o MySQL 4.1.2 [9], de licença gratuita e um dos mais utilizados existentes no mercado. Este aplicativo conta com ampla documentação e ferramentas de apoio disponíveis na Internet.

camada de apresentação e delega os serviços à camada de negócios. Conta com uma coleção de classes utilitárias que encapsulam dados de formulários, erros, lógica para apresentação e redirecionamento de respostas, entre outras. Um ponto forte deste framework é o uso de arquivos de configuração para realizar alterações na aplicação. Sem a necessidade de editar e recompilar classes, a aplicação pode reagir rapidamente às alterações com um mínimo de esforço.

O framework OpenSwing [12] foi a solução utilizada para implementar o cliente

desktop do sistema. Assim como o Struts, ele se baseia no padrão MVC. Utiliza a biblioteca Java Swing e implementa classes que encapsulam formulários, modelo de dados e lógica de controle de janelas. Possui uma coleção de componentes gráficos utilizados em formulários, como botões, menus, grids e tabelas. Este framework, de licença gratuita, possui uma documentação bem simples, presente em seu site, mas que se mostrou muito útil, possibilitando todo o aprendizado necessário a sua utilização.

A API Google Maps [13], desenvolvida na linguagem JavaScript, foi utilizada para a

adição de mapas geográficos em páginas web. Possui ampla variedade de funções para manipulação de mapas, de fácil aprendizado. Sua utilização depende apenas de um registro, indicando em qual URL será publicada a página web contendo o mapa.

Outro componente importante no funcionamento do sistema foi o Java Service Wrapper [14]. Este componente permitiu instalar o JBoss como um “serviço” nos sistemas operacionais Windows. Além de eficaz, sua instalação foi bem simples.

4.3. Iterações de Projeto

De acordo com a metodologia do processo iterativo, desenvolveu-se a seguinte seqüência de interações:

1ª. Iteração

O trabalho teve início com a concepção do sistema pelos interessados. Procurou-se definir o problema a ser resolvido, escopo do produto e sua viabilidade. O levantamento dos requisitos e regras do domínio iniciou o processo de análise do sistema.

Continuando, fez-se o levantamento de casos de uso, identificando a fronteira do sistema, seus atores e objetivos. O problema chave nesta prática foi definir o nível e escopo

dos casos de uso, de acordo com os objetivos a serem atendidos pelo sistema. Apenas os casos de uso principais foram detalhados.

A partir dos casos de uso levantados, criou-se um modelo de classes do domínio, onde os principais conceitos, relacionamentos e atributos foram identificados. Nesta prática, a dificuldade esteve em distinguir conceitos, comportamentos e atributos.

A tarefa seguinte foi pesquisar e definir soluções para o estabelecimento do ambiente de desenvolvimento, como aplicativos e ferramentas de suporte, aparelhos de rastreamento e computadores para desenvolvimento. O último passo foi a instalação e teste das ferramentas e aplicativos, destacando-se o servidor JBoss, o banco de dados MySQL e o aplicativo de rastreamento.

2ª. Iteração

Nesta iteração, o processo de análise continuou sendo prioridade, com a adição de novos requisitos funcionais e detalhamento de mais casos de uso e do modelo de domínio.

Investigando um cenário simples de sucesso de um dos casos de uso principais, descrevemos como os atores interagem com o sistema através de eventos, que são tratados por operações de sistema. Estas operações foram detalhadas através de diagramas de interação e serviram de base para o projeto de classes de software. Algumas dessas classes representaram os conceitos do modelo de domínio.

O modelo de domínio permitiu identificar as entidades cujos dados teriam que ser salvos no banco de dados. O modelo de dados foi então implementado no banco MySQL.

A fase final foi a implementação e testes de algumas funcionalidades do componente SIMT-Server, permitindo a consulta das condições do tráfego nos corredores e o posicionamento dos veículos. Nesta primeira versão, entre as dificuldades encontradas podemos citar o uso das conexões com banco de dados gerenciadas pelo JBoss e a implementação de listas de objetos para pesquisas de informações.

classes de fachada, no componente SIMT-Server, permitindo que o sistema fosse separado em camadas sem acoplamento.

A tarefa mais importante foi a implementação do componente SIMT-Web e sua integração como componente SIMT-Server. Nesta primeira versão, o cliente web não contava com os mapas geográficos, apenas fornecia informações sobre o tráfego nos corredores. O esforço maior se deu no aprendizado do framework Struts.

Devido à semelhança na implementação, o componente SIMT-Wap também teve a sua primeira versão. Foi utilizada a linguagem WML, específica para navegadores de aparelhos celulares.

4ª. Iteração

Nesta iteração, operações para administração do banco de dados foram adicionadas à fachada do componente SIMT-Server, permitindo assim interagir com o componente SIMT-

Admin. Este começou a ser implementado com o aprendizado do framework OpenSwing.

O componente SIMT-Web teve sua segunda versão com a inclusão de um mapa

geográfico na página HTML, através da API Google Maps, além de ajustes na sua visualização. O componente SIMT-Server ainda não disponibilizava informações sobre o tempo de chegada nas paradas.

Todos os casos de usos foram detalhados, levando-se em conta todas as alterações realizadas nos modelos nas interações anteriores. O mesmo aconteceu para os componentes implementados, de modo a refletir as atualizações.

5ª. Iteração

A meta nessa iteração foi a implementação e testes das operações de análise no componente SIMT-Server. Outra tarefa importante foi o término da primeira versão do componente SIMT-Admin. Nessa versão, o componente não contava com as funcionalidades de análise do tráfego e geração de relatórios, apenas realizava o cadastro e edição das entidades no banco de dados do sistema.

Essa interação terminou com uma revisão completa dos modelos de análise e projeto, verificando se os componentes implementados até o momento atendiam os requisitos e objetivos dos usuários. Diversos acertos e melhorias foram estipulados, seguindo as necessidades do projeto.

6ª. Iteração

Ao final desta iteração obteve-se a primeira versão completa do sistema. Os modelos teóricos foram finalizados. O componente SIMT-Server teve sua funcionalidade completada, com a consulta do tempo de chegada nas paradas, permitindo que os componentes SIMT-Web e SIMT-Wap a utilizassem. O componente SIMT-Admin também foi finalizado com a geração de relatórios de análise.

4.4. Dificuldades e Contratempos

Ao longo da realização do projeto, várias dificuldades foram encontradas. Algumas delas necessitaram uma atenção maior em busca de soluções e são descritas a seguir:

Funcionamento das linhas de transporte

Quando analisamos o funcionamento das linhas de transporte, verifica-se uma diversidade de modos de operação, o que dificulta a criação de um modelo que atenda a todas as linhas. A idéia inicial seria a criação de um algoritmo de pesquisa genérico, capaz de processar os dados para qualquer linha. Mas ao realizar os testes na Ilha do Fundão já foi possível identificar as dificuldades em se criar tal algoritmo.

A situação ideal é aquela em que o sistema possa identificar a linha realizada por cada veículo mesmo que estes não tenham uma linha fixa para operar. A lógica do sistema se baseia na busca pelos veículos que se encontram nos corredores pertencentes à linha selecionada pelo usuário. O problema surge quando duas linhas possuem corredores em comum, o que dificulta saber qual linha o veículo está operando e assim qual o próximo corredor que ele irá seguir.

No caso da Ilha do Fundão, existem duas linhas que foram monitoradas. Uma delas é a linha Alojamento-Vila e a outra é a linha Especial. Ambas as linhas possuem um trecho em comum, o corredor Hospital-CCMN. Caso um ônibus tenha saído do hospital em direção ao CCMN, ou saído do CCMN em direção ao Hospital, a princípio não há com saber em qual

simples. De acordo com o responsável pela operação dos veículos na Ilha do Fundão, os veículos são alocados em linhas pré-definidas, com exceção do caso em que um deles tem problemas mecânicos e precisa ser substituído. Mas na prática não é isto que acontece, havendo algumas mudanças não programadas entre as linhas. Além disso, um veículo pode sair da operação, indo para a garagem ou então seguir para o campus da Praia Vermelha ou para Bonsucesso.

Além dos problemas destacados acima, outra situação deve ser considerada. É aquela em que, numa mesma linha, existem veículos com muitas paradas (“parador”) e outros com poucas paradas (“rápido”). Como o intervalo de deslocamento nos corredores será diferente, a estimativa de chegada nas paradas e o índice de congestionamento não estarão corretos. Logo terão que ser consideradas linhas diferentes

Infelizmente a Ilha do Fundão não se mostrou uma rede de transporte ideal para realizar os testes nesta versão do sistema. Além do problema da troca dos veículos, seus corredores têm um intervalo de deslocamento pequeno, o que aumenta o percentual de erro nas medidas de tempo.

Lógica de pesquisa na operação

Diante das dificuldades listadas anteriormente e da previsão de que outras linhas apresentariam os mesmo problemas, foi decidido criar um algoritmo de pesquisa para cada linha em sua própria classe Java. Tal classe identifica exatamente qual banco de dados do aplicativo GPS pesquisar, quais paradas procurar e, principalmente, a lógica correta para não confundir sua linha com outras.

Uma classe cliente usa a interface Java IOperaçao, com a definição dos métodos a serem utilizados, sem se preocupar em saber qual implementação será utilizada. Este desacoplamento permite que os algoritmos mudem independentemente. A única restrição é o cliente saber o nome da classe Java que implementa o algoritmo. Dessa forma existe a necessidade de se cadastrar no banco de dados do sistema, na tabela de linhas, o nome da classe.

Embora o algoritmo de pesquisa seja parecido, cada classe de operação de uma linha possui um método para análise e outro para tráfego. Inicialmente ambas as funções eram executadas num único método, mas isto criava um acoplamento indesejado, dificultando possíveis alterações nas lógicas de cada uma.

Como já foi visto na seção 3.6, o algoritmo de pesquisa inicia com a seleção, no banco de dados do aplicativo GPS, de todos os pontos geográficos enviados até o momento. Esta lista de pontos está agrupada por módulos e ordenada pela hora de registro. Para cada ponto registrado, o algoritmo verifica se é uma parada de algum corredor da linha selecionada. Esse processo continua até que todos os corredores sejam identificados e repete-se para todos os módulos. Definidos os corredores onde se encontram cada veículo, o algoritmo faz a estimativa do tempo de chegada nas paradas. Este cálculo foi motivo de dúvida sobre como seria feito, dispondo de duas opções.

Na primeira, usou-se o índice de congestionamento do corredor anterior, completado pelo veículo, para estimar o tempo de viagem até a parada final do corredor. O problema desta opção está no fato do índice de congestionamento do corredor anterior não refletir as condições reais do corredor atual do veículo. Cada corredor apresenta seu próprio índice de congestionamento. Assim o tempo estimado não seria uma medida confiável.

Na segunda opção, escolhida como solução, usou-se o índice de congestionamento do corredor atual do veículo, calculado a partir do último veículo que o completou. Embora esta opção seja mais confiável que a anterior, o tempo estimado pode não refletir as condições reais do tráfego no instante da consulta, pois se baseia na última vez que o corredor atual foi completado por outro veículo. Se houver uma variação no fluxo de veículos de um corredor, ela só será “notada” pelo sistema quando algum veículo terminar de percorrê-lo. O ideal é que tenhamos vários veículos igualmente espaçados no itinerário da linha, de modo que os corredores sejam completados com maior freqüência, aumentando o grau de confiabilidade das medidas de tempo.

Alguns detalhes são muito importantes na lógica de pesquisa. Para calcular o tempo previsto para um veículo chegar a uma parada é preciso saber quanto tempo ele já percorreu no corredor em que se encontra. Esse tempo é calculado pela diferença entre a hora da consulta (hora presente) e a hora que ele saiu da parada de origem do corredor (hora de partida). Pode acontecer casos em que um veículo está ligado, esperando por passageiros numa parada. O tempo de espera na parada deve ser descartado, para que o tempo percorrido pelo veículo não fique incorreto. Outro fator importante é o relógio da máquina onde se encontra instalado o sistema. Se este relógio estiver incorreto, o tempo previsto de chegada

um tempo percorrido pelo veículo fora do normal. O algoritmo deve identificar estas situações e descartar o veículo da lista de previsões de chegada nas paradas.

Outro detalhe que requer atenção é o caso em que numa mesma parada exista a espera por veículos em dois sentidos. No caso da Ilha do Fundão, na parada CCMN ocorre espera por veículos vindos da Vila e do Alojamento. É preciso identificar qual a origem do veículo para que se possa saber o sentido do deslocamento, sem erro na identificação das linhas.

Uma linha de transporte pode ser circular ou não. A lógica de pesquisa se baseia no corredor seguinte ao último corredor percorrido para identificar em qual corredor o veículo se encontra. Se uma linha não for circular, seu primeiro corredor não é corredor seguinte de nenhum outro. Esta situação exige que o algoritmo saiba identificar o veículo no primeiro corredor usando outros critérios. Neste caso pode-se usar a parada de origem da linha e o tempo percorrido como parâmetros.

Todas as paradas de uma linha podem ser cadastradas, mas a estimativa do tempo de chegada só é realizada para as paradas de origem e de destino dos corredores da linha. A lógica do sistema se baseia no índice de congestionamento de um corredor. Poderíamos supor que cada par de paradas consecutivas na linha fosse considerado um corredor, mas não teríamos estimativas satisfatórias, pois o pequeno intervalo de tempo aumentaria o percentual de erro.

Foram escolhidas as paradas de maior movimento de passageiros na linha, sem deixar que os corredores fossem muito extensos, pois muitas paradas seriam excluídas. Além disso, os corredores são consecutivos. Se existirem trechos “vazios” não será possível estimar o tempo de chegada, pois não sabemos o tempo gasto neste trecho “vazio”.

Funcionamento dos aparelhos de rastreamento

Entre os pontos de dificuldade, um dos maiores problemas é o funcionamento dos aparelhos de rastreamento. Inicialmente, a maioria dos aparelhos estava com um intervalo de registro de 3 minutos, o que é bem superior ao tempo que um ônibus gasta quando está numa parada. Como não há o registro do momento em que o veículo está na parada, o algoritmo de pesquisa não consegue completar sua lógica, produzindo erros nos resultados. Após entrar em contato com a empresa Geocontrol, este intervalo passou para menos de 1 minuto, o que já diminuiu bastante os erros.

Além disso, eventualmente algum aparelho para de transmitir, necessitando uma visita técnica para concertá-lo. Esta falha causa um erro na análise de headway da linha, pois necessita que todos os veículos estejam operando.

Aplicação da tecnologia Java

O desenvolvimento desse sistema foi uma grande oportunidade para o aprendizado das tecnologias que compõem a plataforma J2EE. A inexperiência sobre o assunto causou algumas dificuldades, principalmente no início da implementação do projeto, quando se gastou mais tempo com o aprendizado da tecnologia do que com a codificação.

A instalação e execução do servidor de aplicação JBoss não apresentou maiores problemas. Seu processo de implantação de uma aplicação requer a edição de arquivos de configuração para os componentes e outros recursos do servidor. Entre essas configurações, existe o conceito de conexão gerenciada pelo servidor e conexão não gerenciada. Inicialmente, sem considerar este detalhe, o sistema utilizava conexões gerenciadas, mas isto estava causando erro. Nesta configuração não é permitido abrir conexões com mais de um banco de dados simultaneamente. Mas isto é necessário, pois existem dois bancos sendo utilizados, o MySQL e o FirebirdSql. Após configurar as conexões para não serem gerenciadas pelo servidor, o funcionamento passou a ser normal.

Durante a codificação, os maiores problemas aconteceram com a manipulação de listas de dados, usadas pelo padrão Value List Handler. A interação sobre estas listas gerava erros em tempo de execução difíceis de encontrar, exigindo um esforço maior de depuração. Tais erros eram decorrentes da não inicialização de variáveis nas listas.

A integração do componente SIMT-Admin com o SIMT-Server não foi simples. O framework OpenSwing possui a interface ValueObject, que deve ser implementada por todas as classes de objeto de valor, pois ela é referenciada por todos os componentes gráficos do framework. A princípio, para criar as classes de objeto de valor no SIMT-Admin, bastaria implementar esta interface e herdar as respectivas classes do SIMT-Server. Mas isto não foi possível. A biblioteca do framework utiliza classes de wrapping (embrulho) para tratar os tipos primitivos como objetos. Como as classes de objeto de valor no SIMT-Server foram

Eclipse não consegue localizar a referência que existe entre classes de diferentes pacotes, acusando erro no código, embora esteja tudo correto. Cada vez que isso acontecia era necessário recriar todo o projeto no Eclipse. Como solução, basta remover a biblioteca nativa do Java da lista de referências e depois adicioná-la novamente. Esta ação provoca uma atualização no Eclipse que elimina o erro.

Uma das grandes vantagens do JBoss é o controle do ciclo de vida dos objetos instanciados na memória. Este controle permite que um pool de instâncias seja reutilizado em cada chamada, tornando o processamento mais rápido. Mas um problema ocorre quando há uma alteração no banco de dados do sistema, deixando algumas instâncias com seus dados desatualizados. Infelizmente não se encontrou outra solução senão deixar o próprio JBoss decidir remover todas as instâncias da memória ou então reiniciá-lo.

Depois de feitos os testes no sistema, era necessário colocá-lo na máquina servidora para que fosse possível acessá-los externamente à rede do laboratório Planet. Mas esta máquina já possuía um site rodando no servidor web Apache, o que criava um problema. Por padrão, toda requisição HTTP que chega ao servidor é direcionada a porta 80, utilizada pelo Apache. Mas o servidor web Tomcat, contido no JBoss, utiliza a porta 8080. Não era possível redirecionar as requisições para a porta 8080, pois o site contido no Apache sairia do ar. A solução estava no próprio Apache [15]. Este possui arquivos de configuração que permitem ao