Embed Size (px)
Citation preview
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SOLUÇÃO EM DISPOSITIVO MÓVEL PARA O CONTROLE DE UM
TERMINAL DE CONTÊINER VAZIO
Área de Computação Móvel
por
João Paulo Brassanini
Ovídio Felippe Pereira da Silva Jr, Dr. Orientador
Itajaí (SC), novembro de 2007
id12181328 pdfMachine by Broadgun Software - a great PDF writer! - a great PDF creator! - http://www.pdfmachine.com http://www.broadgun.com
UNIVERSIDADE DO VALE DO ITAJAÍ
CENTRO DE CIÊNCIAS TECNOLÓGICAS DA TERRA E DO MAR
CURSO DE CIÊNCIA DA COMPUTAÇÃO
SOLUÇÃO EM DISPOSITIVO MÓVEL PARA O CONTROLE DE UM
TERMINAL DE CONTÊINER VAZIO
Área de Computação Móvel
por
João Paulo Brassanini Relatório apresentado à Banca Examinadora do
Trabalho de Conclusão do Curso de Ciência da
Computação para análise e aprovação. Orientador: Ovídio Felippe Pereira da Silva Jr, Dr.
Itajaí (SC), novembro de 2007
ii
DEDICATÓRIA
A Deus,
A minha maravilhosa família
Aos Amigos
Por simplesmente estarem sempre ao meu lado por amor
iii
AGRADECIMENTOS
Agradeço profundamente a meus pais, João Francisco Brassanini e Maria Odete Brassanini
pelo amor incondicional dado durante toda a jornada do curso de Computação.
A Modallport Sistemas, por ter fornecido todo o apoio e estrutura necessária, sem o qual
esse projeto seria apenas uma idéia.
Aos meus irmãos, Marcio, Marcelo e Alessandro, amigos escolhidos pela natureza, pela
amizade e apoio de sempre, que durante todo o ano tiveram que me aturar.
Ao meu Orientador, Ovídio, pelo seu apoio dado no transcorrer do projeto.
A Josiane Martins, por me mostrar os caminhos do amor.
A Marcos Pamplona e a Luiz Carlos Bonneti, pelas suas grandiosas idéias.
A Deus, por me proporcionar todas as coisas maravilhas da vida.
SUMÁRIO
LISTA DE ABREVIATURAS..................................................................vi
LISTA DE FIGURAS..............................................................................viii
LISTA DE TABELAS................................................................................x
RESUMO....................................................................................................xi
ABSTRACT...............................................................................................xii
1 INTRODUÇÃO ......................................................................................1 1.1 PROBLEMATIZAÇÃO................................................................................... 3 1.1.1 Formulação do Problema .............................................................................. 3 1.1.2 Solução Proposta ............................................................................................ 3 1.2 OBJETIVOS ..................................................................................................... 4 1.2.1 Objetivo Geral................................................................................................ 4 1.2.2 Objetivos Específicos...................................................................................... 4 1.3 METODOLOGIA............................................................................................. 5 1.4 ESTRUTURA DO TRABALHO ..................................................................... 6
2 FUNDAMENTAÇÃO TEÓRICA ........................................................7 2.1 CONSIDERAÇÕES INICIAIS........................................................................ 7 2.2 AMBIENTE ORGANIZACIONAL ................................................................ 7 2.2.1 Tecnologia da Informação na Área Portuária.............................................. 8 2.2.2 Missão do Terminal de Contêiner Vazio....................................................... 9 2.2.3 Cadeia Logística do Contêiner Vazio.......................................................... 15 2.3 SISTEMA DE INFORMAÇÃO..................................................................... 16 2.3.1 Componentes dos Sistemas de Informação................................................. 18 2.3.2 Classificação dos Sistemas de Informação.................................................. 19 2.3.3 Processos Organizacionais........................................................................... 21 2.3.4 Qualidade da Informação ............................................................................ 22 2.4 COMPUTAÇÃO MÓVEL............................................................................. 24 2.4.1 Dispositivos móveis....................................................................................... 25 2.4.2 Tecnologia de comunicação sem fio ............................................................ 27 2.4.3 Arquiteturas de aplicações móveis .............................................................. 29 2.4.4 Ambiente de desenvolvimento ..................................................................... 31 2.4.5 Trabalhos relacionados................................................................................ 37 2.4.6 Solução Móvel para o Teconvi..................................................................... 38 2.4.7 Análise das Soluções..................................................................................... 39 2.5 RESUMO DA FUNDAMENTAÇÃO............................................................ 40
3 DESENVOLVIMENTO ......................................................................42 3.1 PROCESSOS DE UM TERMINAL DE CONTÊINER VAZIO ................. 42 3.1.1 Entrada do contêiner ................................................................................... 43
3.1.2 Vistoria ......................................................................................................... 43 3.1.3 Oficina........................................................................................................... 43 3.1.4 PTI ................................................................................................................ 44 3.1.5 Saída.............................................................................................................. 45 3.2 LEVANTAMENTO DE REQUISITOS ........................................................ 48 3.2.1 Requisitos funcionais ................................................................................... 48 3.2.2 Requisitos não funcionais ............................................................................ 48 3.2.3 Regras de negócio......................................................................................... 49 3.2.4 Restrições...................................................................................................... 51 3.3 MODELAGEM DO SISTEMA ..................................................................... 52 3.3.1 Diagramas de casos de uso........................................................................... 52 3.3.2 Diagrama de classe de negócio .................................................................... 54 3.3.3 Diagrama de classe de projeto..................................................................... 56 3.3.4 Diagrama de seqüência ................................................................................ 57 3.3.5 Diagrama Entidade-Relacionamento .......................................................... 58 3.3.6 Diagrama de implantação............................................................................ 59 3.4 FUNCIONAMENTO DO SISTEMA ............................................................ 60 3.4.1 Sistema Modall e Módulo Terminal........................................................... 61 3.4.2 Módulo SisAcess........................................................................................... 62 3.4.3 Operação do Sistema Móvel ........................................................................ 63 3.5 IMPLEMENTAÇÃO ..................................................................................... 67 3.6 TESTES E VALIDAÇÕES DO SISTEMA................................................... 73
REFERÊNCIAS BIBLIOGRÁFICAS ...................................................79
GLOSSÁRIO.............................................................................................83
A MODELAGEM DO SISTEMA..........................................................85 A.1 CASOS DE USO............................................................................................. 85 A.1.1 Pacote 01: Controle de Acesso .................................................................... 85 A.1.2 Pacote 02: Controle de Operações .............................................................. 86 A.2 TELAS DO SISTEMA ................................................................................... 97 A.3 DIAGRAMAS DE CLASSE E SEQUÊNCIA............................................. 102
B Testes ...................................................................................................110 B.1 CHECKLIST DO TESTE DE INTEGRAÇÃO.......................................... 110 B.2 TESTES DE USABILIDADE ...................................................................... 112 B.2.1 Ensaio de Interação.................................................................................... 112 B.2.2 Questionário ............................................................................................... 113
LISTA DE ABREVIATURAS
AA Aguardando Autorização AE Aguardando Estimativa AL Aguardando Lavagem AR Aguardando Reparo AV Aguardando Vistoria CDC Connected Device Configuration CF Compact Framework CLDC Connected Limited Device Configuration CLR Commom Language Runtime DC Dry Cargo DDL Data Definition Language ou Linguagem de Definição de Dados DER Diagrama Entidade-Relacionamento DML Data Manipulation Language ou Linguagem de Manipulação de Dados DV Dry Vented EDI Electronic Data Interchange FR Flat Rack GPS Global Positioning System HC High Cube IEEE Instituto de Engenharia Elétrica e Eletrônica ISO International Standard Organization J2EE Java 2 Enterprise Edition J2ME Java 2 Mobile Edition J2SE Java 2 Standard Edition JIT Just in Time JVM Java Virtual Machine LAN Local Area Network MBPS Megabits por Segundo MGW Maximum Gross Weight MMIT Mobile Internet Toolkit MSIL Microsoft Intermediate Language OT Open Top PAN Personal Área Network PDA Personal Digital Assistants PL Plataforma PL/SQL Procedural Language/Structured Query Language PTI Pré-Trip Inspection RAC Real Application Clusters RE Reefer RF Reefer RFID Radio-Frequency IDentification RH Reefer High Cube SAD Sistema de Apoio a Decisões SAE Sistema de Apoio aos Executivos SGBD Sistema Gerenciador de Banco de Dados SI Sistema de Informação SIG Sistema de Informação Gerencial
SO Sistema Operacional SPT Sistema de Processamento de Transações SQL Structured Query Language STC Sistemas de Trabalhadores do Conhecimento T Tonelada TEU Twenty foot Equivalent Unit TK Tanque UML Unified Modeling Language VS Visual Studio Wi-FI Wireless Fidelity WLAN Wireless Local Area Network XML EXtensible Markup Language ou Linguagem extensível de formatação
LISTA DE FIGURAS
Figura 1. Solução proposta. .............................................................................................................4 Figura 2: Contêiner Dry.................................................................................................................12 Figura 3. Contêiner Tanque ...........................................................................................................12 Figura 4. Contêiner Open Top .......................................................................................................12 Figura 5. Flat Rack ........................................................................................................................12 Figura 6. Plataforma ......................................................................................................................12 Figura 7. Reefer.............................................................................................................................12 Figura 8. Identificação dos dados do contêiner...............................................................................14 Figura 9. Cadeia logística do contêiner vazio .................................................................................16 Figura 10. Modelo representando o sistema de um terminal de contêiner vazio..............................18 Figura 11. Ligação entre os tipos de sistemas de informação .........................................................20 Figura 12. Vistoria de um contêiner realizada no Sistema Modall. .................................................23 Figura 13. Vistoria de um contêiner realizada no Sistema Modall, com a adoção da solução móvel.
..............................................................................................................................................24 Figura 14. Terminal Coletor de dados CPT 9500 ...........................................................................27 Figura 15. Arquitetura da Solução Móvel. .....................................................................................31 Figura 16. Processo de geração de uma aplicação .NET................................................................32 Figura 17. Processo de execução de uma aplicação .NET..............................................................33 Figura 18. Funcionamento do ASP .NET Móbile...........................................................................34 Figura 19. Processo de compilação e execução de um programa Java ............................................35 Figura 20. Solução Móvel para a Vila do Conde ............................................................................37 Figura 21. Telas da solução móvel para a Amazônia Terminais .....................................................38 Figura 22. Layout conceitual de um terminal de contêiner vazio. ...................................................46 Figura 23: Diagrama de atividades do processo de um terminal de contêiner vazio. .......................47 Figura 24: Diagrama de Caso de Uso Caso para o Controle de Acesso...........................................54 Figura 25. Diagrama de Caso de Uso Caso das Operações. ............................................................54 Figura 26. Digrama de Classe de Domínio do Sistema...................................................................56 Figura 27. Diagrama de Classe de Projeto da Manutenção do cadastro de contêiner.......................57 Figura 28. Diagrama de Classe de Seqüência da Manutenção do cadastro de contêiner ..................58 Figura 29. Diagrama entidade-relacionamento do Sistema Móvel. .................................................59 Figura 30. Diagrama de Implantação do Sistema. ..........................................................................60 Figura 31. Menu de Acesso do Módulo Terminal ..........................................................................62 Figura 32. Tela 01 � Login. ...........................................................................................................63 Figura 33. Tela 02 � Menu de Acesso. ...........................................................................................63 Figura 34. Atalho do sistema no Windows CE...............................................................................65 Figura 35. Menu inicial do sistema executando no dispositivo. ......................................................65 Figura 36. Tela de Consulta de Contêiner executando no dispositivo. ............................................65 Figura 37. Tela de Estimativa executando no dispositivo. ..............................................................65 Figura 38. Diagrama de Pacotes dos Casos de Uso. .......................................................................85 Figura 39. Tela 03A e 03B � Cadastro de Vistoria. .......................................................................98 Figura 40. Tela 04A � Cadastro do item da Estimativa...................................................................98 Figura 41. Tela 04B � Manutenção dos itens da Estimativa. ..........................................................98 Figura 42. Tela 05A - Consulta de Contêiner (Principal)................................................................99 Figura 43. Tela 05B - Consulta de Contêiner (2-Outros). ...............................................................99 Figura 44. Tela 05C - Consulta de Contêiner (2-Outros). ...............................................................99 Figura 47. Tela 06 � Manutenção de cadastro de contêiner. .........................................................100
Figura 45. Tela 05D.- Tracking do Contêiner...............................................................................100 Figura 46. Tela 05E. � Detalhes do Tracking. ..............................................................................100 Figura 48. Tela 07A � Cadastro do item do PTI. ..........................................................................101 Figura 49. Tela 07B � Alteração/exclusão de PTIs.......................................................................101 Figura 50. Tela 08 � Posicionamento do Contêiner. .....................................................................101 Figura 51. Tela 09 � Busca de Contêiner. ....................................................................................102 Figura 52. Tela 10 � Cadastro Padrão. .........................................................................................102 Figura 53. Tela 11 � Mensagem ao usuário. .................................................................................102 Figura 54. Diagrama de Classe de Projeto da UC 01.01 - Efetua Login........................................103 Figura 55. Diagrama de Classe de Seqüência da UC 01.01 - Efetua Login. ..................................104 Figura 56. Diagrama de Classe de Projeto da UC 02.01 � Vistoria de Contêiner. .........................104 Figura 57. Diagrama de Classe de Seqüência da UC 02.01 � Vistoria de Contêiner. ....................105 Figura 58. Diagrama de Classe de Projeto da UC 02.02 � Cadastro/Alteração de Estimativa........105 Figura 59. Diagrama de Classe de Seqüência da UC 02.02 � Cadastro/Alteração de Estimativa. ..106 Figura 60. Diagrama de Classe de Projeto da UC 02.03 - Consulta de Contêiner. ........................106 Figura 61. Diagrama de Classe de Seqüência da UC 02.03 - Consulta de Contêiner. ....................107 Figura 62. Diagrama de Classe de Projeto da UC 02.05 � Cadastro de PTI. .................................107 Figura 63. Diagrama de Classe de Seqüência da UC 02.05 � Cadastro de PTI..............................108 Figura 64. Diagrama de Classe de Projeto da UC 02.06 � Cadastro de Posicionamento. ..............109 Figura 65. Diagrama de Classe de Seqüência da UC 02.06 � Cadastro de Posicionamento...........109
LISTA DE TABELAS
Tabela 1. Medidas de um contêiner................................................................................................11 Tabela 2. Siglas do contêiner no Sistema Modall ..........................................................................12 Tabela 3. Exemplo da montagem de códigos ISO. .........................................................................13 Tabela 4. Resumo Tecnologias de Comunicação sem Fio ..............................................................29 Tabela 5. Status do contêiner em cada atividade do processo. ........................................................44
RESUMO
BRASSANINI, João Paulo. Solução em dispositivo móvel para o controle de um terminal de
contêiner vazio. Itajaí, 2007. 129 f. Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação)�Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí,
Itajaí, 2007. No início do século XXI, empresas de comércio exterior como portos, armazéns e terminais de contêineres investiram significativamente tanto em processos operacionais como em tecnologia da informação, devido ao aumento das exportações e da lei de modernização dos portos. A
Modallport Sistemas fornece soluções de software nessa área desde 1995, atendendo em todo o território nacional. Um dos sistemas mais usados e vendidos é o "Sistema de controle de terminais de contêineres vazios", parte do Sistema Modall, cuja função é controlar todo o processo
do contêiner dentro de um terminal de contêiner vazio, como entrada, saída, posicionamento,
vistorias, reparos, dentre outros, fornecendo ao armador (o dono do contêiner) e ao terminal
informações sobre todos esses processos. Um dos grandes problemas dessa solução é que ela não
possibilita uma forma de colocar a informação no sistema no momento em que ela ocorre, pois toda
a entrada dos dados é feitas primeiro em pranchetas e em seguida digitados por outras pessoas no
Sistema Modall. Isso ocasiona uma série de problemas como falta de exatidão das informações,
quebras das regras do fluxo de trabalho operacional, e no final, acarreta prejuízos financeiros. Além
disso, o sistema só pode ser acessado via computador desktop, que dificulta a obtenção de dados importantes dos operadores que estão no pátio do terminal, que é relativamente grande. Dessa
forma, o objetivo dessa pesquisa visa criar um software para um dispositivo móvel, em que os
operadores do pátio podem digitar dados do fluxo de trabalho no momento em que ele ocorre, além
de permitir que a informação seja acessada de qualquer lugar do terminal, com acesso direto ao
banco de dados do Sistema Modall. Como pressupostos básicos fundamentou-se as características
do contêiner e do ambiente organizacional onde o software rodará, com explanações sobre o fluxo de trabalho do terminal e da cadeia logística do contêiner vazio. Além disso, mostra o conceito de sistemas de informação e sua importância para o projeto, os conceitos envolvidos na computação móvel e quais tecnologias foram adotadas. O estudo de sistemas móveis da área portuária ajudou a determinar que tecnologias usar. Para a implementação, inicialmente se propôs o uso .NET ou Java, com a adoção do Visual Studio .NET 2005 e ferramentas de apoio.
Como o sistema executa integrado ao Sistema Modall, estudou-se sua estrutura, funcionamento e rotinas internas. Para a modelagem adotou-se UML com auxílio da ferramenta Enterprise Architect,
sendo construídos os diagramas de caso de uso, de classe, de atividades, de implantação e de
seqüência, além do DER do Sistema Modall. O sistema foi testado no emulador do Windows CE
5.0 e no dispositivo móvel, sendo realizados testes de funcionalidade e usabilidade. Concluiu-se que as tecnologias e métodos adotados mostraram-se adequados, proporcionando agilidade no desenvolvimento e confiabilidade na obtenção dos resultados. Palavras-chave: Computação Móvel. Terminal de Contêiner Vazio. Sistema de Informação.
ABSTRACT
At the beginning of the twenty-first century, companies of foreign trade as ports, warehouses and
container terminals invested significantly in both operational processes such as information
technology, due to the increase of exports and the law of modernization of ports. The Modallport
Systems have been providing software solutions to this area since 1995, working in the entire
national territory. One of the most used and sold systems is the "system of terminals control of
empty containers," part of the Modall system, whose function is to control the whole process of the
container within a terminal of empty container, as input, output, position, inspections , repairs,
among others, providing to the ship-owner (the owner of the container) and to the terminal
information about all these processes. One of the major problems of this solution is that it does not
allow a way of putting the information in the system at the moment that it is occuring, because all
entry of data is made first in clipboards and then typed by other people in the Modall system. This
causes a number of problems such as lack of information accuracy, breaking of the rules of the
operational work flow, and in the end, brings financial losses. In addition, the system can only be
accessed via desktop computer, which makes it difficult to obtain important data for operators that
are in the courtyard of the terminal, which is relatively large. Thus, the goal of this research aims
to create a software for a mobile device, in which traders can enter the data of the workflow when it
occurs, and allow information to be accessed from anywhere in the terminal, with direct access to
the database System Modall. As basic assumptions based the characteristics of the container and
the organizational environment where the software will work, with explanations about the workflow
of the terminal and the logistics chain of empty container. Moreover,it shows the concept of
information systems and its importance to the project, the concepts involved in mobile computing
and what technologies were adopted. The study of mobile systems of the port area helped to
determine which technology uses. Initially. NET or Java, with the adoption of Visual Studio. NET
2005 and tools of supportting was proposed to use for the implementation. As the system performs
integrated with Modall System, its structure, operation and internal routines were studied. For
modeling, it was adopted UML with aid of the Enterprise Architect tool, being built the diagrams of
use case, of class, of activities, of implementation, of deployment and of sequence, besides the DER
Modall System. The system was tested in the emulator of CE 5.0 Windows and in the mobile device,
being conducted tests of functionality and usability. It was concluded that the used technologies and
methods have been adequated, providing agility in the development and reliability in achieving of
the results.
Keywords: Mobile Computer. Terminal of Empty Container. Information System.
1 INTRODUÇÃO
Nos últimos anos empresas da área portuária como portos, terminais de contêineres e
armazéns aumentaram significativamente o investimento em tecnologia da informação, como a
aquisição de sistemas de informação operacional e gerencial, soluções web, soluções móveis e
automação em geral.
O aumento das exportações brasileiras ocasionou o surgimento ou aumento de estruturas
portuárias e áreas de apoio, elevando a concorrência no setor e conseqüentemente, o aumento da
qualidade dos serviços. Nesse sentido, a Modallport Sistemas fornece soluções na área de TI
(tecnologia da informação) desde 1995, com sistemas para controle de portos, armazéns de cargas
solta, terminais de contêineres, dentro outros, e vêm apoiando a missão dessas organizações.
Um dos sistemas mais usados é o �Sistema de Controle de Terminais de Contêineres
Vazios� ou �Módulo Terminal�, cuja função é controlar todo o processo do contêiner vazio dentro
de um terminal de contêiner vazio. Segundo Bandeira (2005), a principal função de um terminal é
guardar, reparar e inspecionar o contêiner vazio para o armador, que é o seu dono, disponibilizando-
o quando solicitado.
O terminal deve ter um sistema de informação que mostre em tempo real onde cada
contêiner se encontra dentro de um fluxo de trabalho determinado. Segundo Nobre (2007), �os
armadores passaram a exigir precisão nos recursos de tecnologia da informação�. O sistema da
Modallport atende parcialmente esse objetivo, pois não possibilita um meio de colocar a informação
no sistema no momento exato em que ela ocorre e não permite consultá-la em qualquer local no
terminal.
Dessa forma, esse projeto propõe-se criar uma aplicação em dispositivo móvel integrada ao
sistema da Modallport. A integração se justificou porque a empresa possui uma grande quantidade
de clientes, que estão cada vez mais investindo em soluções tecnológicas que resolvam seus
problemas. Assim, a principal motivação para o projeto revelou-se pela necessidade dos terminais e
clientes de Modallport, aliados aos investimentos em tecnologia da informação que eles vêm
fazendo.
2
De acordo com O�Brien (2001), a informação dentro de uma organização deve possuir uma
série de características que garantem sua qualidade, como estar disponível no momento e no local
necessário, além de livre de ser livre de erros, de fácil manipulação e compreensão.
No modelo de uso atual, pelo sistema da Modallport, a entrada dos dados desenvolvem-se
primeiro em pranchetas, usando papel e caneta e em seguida digitadas por outra pessoa no sistema.
Essa lacuna de tempo ocasiona uma série de transtornos, como informações desatualizadas para o
armador e dificuldade do andamento do fluxo de trabalho, já que há regras de negócios no software
interligadas aos processos que estão ocorrendo.
Além disso, o sistema permite que o operador de pátio, munido com seu dispositivo, acesse
as informações que necessita de forma rápida, não necessitando obtê-la por impressão de relatórios
na administração ou via rádio.
O uso de dispositivos móveis cresceu muito devido a uma série de fatores: aumento da
capacidade computacional, redução de custos de hardware, estruturas de redes adequadas,
ambientes de desenvolvimento robustos.
Em Isam (2007), ressalta-se que:
A computação móvel vem surgindo como uma nova proposta de paradigma computacional
advinda da tecnologia de rede sem fio e dos sistemas distribuídos. Nela o usuário,
portando dispositivos móveis, como palmtops e notebooks, tem acesso a uma infra-estrutura compartilhada independente da sua localização física. Isto fornece uma
comunicação flexível entre as pessoas e um acesso contínuo aos serviços de rede.
Inicialmente, a tecnologia proposta para o desenvolvimento da solução ficou entre Java e
.NET. Segundo SUN (2006), Java é a tecnologia mais adotada para dispositivos móveis no globo,
pois contém grande flexibilidade e portabilidade. De acordo com MICROSOFT (2006), o
Framework .NET permite o desenvolvimento independente de linguagem, plataforma e dispositivo.
Após uma série de estudos de ambas as tecnologias, selecionou-se a plataforma .NET devido ao seu
fácil aprendizado, a agilidade no desenvolvimento e ao suporte a aplicações móveis.
O projeto se justificou como um TCC porque envolveu o desenvolvimento de uma aplicação
computacional móvel, adotando tecnologias relativamente novas e que vem se popularizando. Além
disso, diversas disciplinas do curso foram contempladas como: sistemas de informações, engenharia
da usabilidade, engenharia de software, banco de dados, programação, redes e sistemas distribuídos.
3
1.1 PROBLEMATIZAÇÃO
1.1.1 Formulação do Problema
No modelo de uso atual do sistema do �Sistema de Controle de Terminais de Contêineres
Vazios�, de forma geral ocorrem dois problemas: a falta de acessibilidade e a falta de sincronia.
A falta de acessibilidade significa que as informações só podem ser obtidas na
administração, impressas e enviadas ao pátio, para uso dos operadores. Ocorre que o terminal é
relativamente grande, e nesse processo de idas e vindas ou contato por rádio há uma grande perda
de agilidade e até uma dificuldade em obter a informação certa.
A falta de sincronia significa que os dados dos processos não estão no sistema no momento
em que eles ocorrem. As entradas dos dados são feitas primeiro em pranchetas, usando papel e
caneta e em seguida digitadas por outra pessoa no sistema. Essa lacuna de tempo ocasiona uma
série de problemas, como informações desatualizadas para o armador, para operadores do terminal
e gerentes. Isso causa dificuldades do andamento do fluxo de trabalho, já que há regras de negócios
no software interligadas aos processos em andamento.
Assim, a Solução Móvel permite a inclusão de dados de forma online, sem atrasos, além de
permitir que a informação seja acessada em qualquer lugar do terminal.
1.1.2 Solução Proposta
A solução proposta consiste de um software rodando em um dispositivo móvel, acessando
via rede wireless e em tempo real o banco de dados do Sistema Modall relativo ao Sistema de
Controle de Terminais de Contêineres Vazios (Módulo Terminal), conforme mostra a Figura 1. O
sistema deve permitir o cadastro de operações comumente feitas num pátio, como o posicionamento
e vistorias de contêineres, dentre outras até então feitas através de meio manual, além de permitir a
consulta de informações gerais dos dados relativos aos contêineres.
4
Figura 1. Solução proposta.
1.2 OBJETIVOS
1.2.1 Objetivo Geral
Desenvolver uma solução em dispositivo móvel para o controle das operações de um
terminal de contêiner vazio integrado ao �Sistema de Controle de Terminais de Contêineres� da
ModallPort Sistemas.
1.2.2 Objetivos Específicos
Os objetivos específicos deste projeto de pesquisa são:
Conhecer conceitos, processos e áreas de negócios envolvidos na solução;
Analisar as ferramentas de desenvolvimento Java e .NET;
Conhecer as tecnologias de dispositivos móveis existentes;
Analisar projetos móveis equivalentes;
Definir os requisitos do sistema;
Realizar a análise do �Módulo Terminal� da Modallport Sistemas;
Realizar a modelagem do sistema;
Implementar o software; e
Realizar testes de funcionalidade e usabilidade no software.
5
1.3 Metodologia
Para atingir os objetivos específicos previstos nesse TCC, executou-se cinco etapas distintas:
(i) estudo dos conceitos envolvidos; (ii) análise e projeto; (iii) implementação; (iv) testes de
funcionalidades e usabilidade (v) e documentação.
Na etapa de estudo dos conceitos envolvidos, pesquisou-se tanto os conceitos
organizacionais quanto os tecnológicos. Para os conceitos organizacionais, estudou-se o ambiente
organizacional onde o software será processado, principalmente através de entrevistas com
especialistas do negócio, além de pesquisas bibliográficas sobre sistemas de informação e suas
características. O estudo dos conceitos tecnológicos envolveu a computação móvel, onde se
buscou, através da leitura de livros, de sites especializados da internet e de entrevista com
especialistas, a compreensão dos tipos de dispositivos móveis existentes, das tecnologias de
comunicação sem fio, dos ambientes de desenvolvimento e das arquiteturas de software para
sistema móvel. Além disso, a análise de trabalhos relacionados deu um entendimento e um sentido
mais amplo desses conceitos, auxiliando a definir as tecnologias a serem usadas.
Essa pesquisa registrou-se necessária e importante para a escolha das soluções adequadas ao
projeto, como a escolha do tipo de dispositivo e do ambiente de desenvolvimento.
A etapa de análise e projeto começou com o estudo do funcionamento interno de um
terminal de contêiner vazio, por meio de conversações com especialistas da área e analistas da
Modallport. Assim, com essa compreensão, os requisitos funcionais e as regras de negócios também
foram levantados junto a especialistas, profissionais de terminais e analistas da empresa.
Na modelagem, através da UML e com o auxílio da ferramenta Enterprise Architect,
descreveu-se o funcionamento do sistema, sendo construídos os casos de uso, o diagrama de
classes, de seqüência, o DER do Sistema Modall e o diagrama de implantação. Os protótipos das
telas foram desenvolvidos no Visual Studio 2005. Além disso, pesquisou-se o funcionamento do
Sistema Modall, através de pesquisa na Modallport e especificou-se a forma de operação do sistema
pelo usuário.
A etapa de implementação consistiu na codificação do sistema no Visual Studio 2005, em
conformidade com o projeto feito. Foi usada a linguagem C#, utilizando o Compact Framework 2.0
para Windows CE 5.0, numa construção windows application. Em paralelo, foram realizados os
testes de unitários.
6
A etapa de validação consistiu nos testes de funcionalidades, onde se testou a conformidade
com os requisitos e a integração com o Módulo Terminal do Sistema Modall, e os testes de
usabilidade, onde foi testada a experiência de uso do sistema.
A etapa de documentação compreendeu o registro de todos os processos referentes às etapas:
(i) leitura e levantamento de conceitos, (ii) análise e projeto, (iii) implementação; (iv) testes de
funcionalidades e usabilidade, seguindo as normas exigidas pela Coordenação de TCC.
1.4 Estrutura do trabalho
Esse trabalho estruturou-se em quatro capítulos: Introdução, Fundamentação Teórica,
Desenvolvimento e Conclusões.
O capítulo de introdução traça um panorama geral do projeto, além de apresentar o
problema a ser resolvido e a solução proposta.
O capítulo de fundamentação teórica divide-se em ambiente organizacional, onde são
apresentados conceitos relativos à área de negócio onde a aplicação rodará, sistema de informação,
onde são apresentados conceitos relativos a sistemas e sua importância para uma organização, e
computação móvel, onde são apresentados as tecnologias da computação móvel e os ambientes para
desenvolvimento de software.
O capítulo de desenvolvimento divide-se em: processo de um terminal de contêiner vazio,
que mostra o funcionamento de um terminal de contêiner vazio, levantamento de requisitos, que
define os requisitos do sistema, modelagem, que mostra os diagramas em UML e o DER do banco
de dados, funcionamento do sistema, que mostra a operação do Sistema Móvel e do Sistema
Modall, implementação, que mostra como o sistema foi codificado e por fim, testes de
funcionalidade e usabilidade, que mostra a metodologia adotada para tal.
O último capítulo, Conclusões, mostra as conclusões referentes ao desenvolvimento do
TCC, colocando a visão do autor sobre as tecnologias adotadas e as bibliografias pesquisadas. Além
desses capítulos, o apêndice relaciona os casos de uso, os diagramas de classe de projeto, os
diagramas de seqüência, as telas construídas e o checklist de testes. No anexo é mostrado a
especificação técnica do dispositivo móvel usado nos testes.
7
2 FUNDAMENTAÇÃO TEÓRICA
2.1 CONSIDERAÇÕES INICIAIS
Como o objetivo do projeto é construir um sistema de informação, acessado por um
dispositivo móvel, para o uso por um terminal de contêiner vazio, a fundamentação desdobra-se em
aspectos relacionados a cada um desses itens.
Primeiramente, mostra-se o ambiente organizacional onde o sistema será processado,
descrevendo o que é um terminal de contêiner e um contêiner e porque eles são usados para o
transporte de mercadorias. É importante conhecer onde se encontra um terminal dentro da cadeia
logística portuária, a fim de compreender o processo como um todo. Além disso, mostrar-se-á as
principais motivações para o investimento de sistemas para área portuária.
Em seguida, na seção de sistemas de informações, são tratados aspectos da importância dos
sistemas de informação para as organizações. Ainda, são descritos seus componentes constituintes,
sua classificação, o que são processos organizacionais e o porquê da qualidade da informação ser
vital para a empresa.
A seção de computação móvel descreve os principais conceitos relacionados a essa
tecnologia, bem como os dispositivos móveis existentes, as tecnologias de comunicação sem fio e
de desenvolvimento mais empregadas no momento. Ainda, são analisadas as tecnologias que podem
ser empregadas na construção do sistema, e mostrada quais serão de fato utilizadas. Além disso,
relaciona as características que um dispositivo deve ter para funcionar num terminal de vazios.
Todos os itens anteriormente citados, além de serem analisados sob o ponto de vista teórico,
também são vistos sob ponto de vista prático, relacionando-os com o sistema a ser construído.
2.2 AMBIENTE ORGANIZACIONAL
Essa seção tem o objetivo de mostrar o ambiente organizacional onde o sistema rodará,
caracterizando os principais elementos envolvidos com a área de negócio: a área portuária e de
terminais de contêineres.
Primeiramente, resume o porquê que as empresas da área portuária têm investindo em
tecnologia da informação nos últimos anos, revelando assim uma das motivações para a construção
8
do sistema. A seguir, são relacionados a missão e os serviços prestados pelo terminal de contêiner
vazio, além de discorrer sobre as características do contêiner, sua importância, medidas e história.
Por último, a fim de compreender o sistema como um todo, é estudado a cadeia logística do
contêiner vazio, que mostra a importância do terminal dentro de todo o processo de exportação e
importação de cargas.
2.2.1 Tecnologia da Informação na Área Portuária
Basicamente, portos são grandes áreas destinadas ao envio de cargas nacionais ao exterior
ou para dentro do país (a chamada exportação), ou o recebimento de cargas provenientes do exterior
ou do país (a importação). Nos últimos anos, o Brasil mostrou grande aumento das exportações
através dos portos, fazendo com que investimentos em TI e processos fossem necessários e vitais.
Esse crescimento começou na década de 90, com a abertura de mercado do governo Collor,
da onda de privatizações no Brasil e do plano real. Todas essas mudanças possibilitaram o
crescimento das empresas brasileiros no exterior vistos a partir do ano 2000, tendência que deverá
se manter daqui para frente, fazendo com que exportações aumentem ainda mais (EXAME, 2007, p.
31).
Uma dessas mudanças importantes foi a Lei de Modernização dos Portos (nº. 8.630), de
1993, que privatizou e mudou o cenário de muitos portos brasileiros. Os portos passaram a contar
com terminais mais bem equipados, utilizando modernos processos, administrados por profissionais
sintonizados com a demanda dos mercados, e acima de tudo, focados no atendimento ao cliente
(MANTELI, 2004).
Atualmente, a meta dos portos e terminais de contêineres brasileiros é melhorar os índices
de eficiência em relação ao da concorrência internacional e nacional. Para isso, os executivos
precisam reduzir seus custos através de uma utilização eficiente dos recursos humanos e de
investimentos em novas tecnologias de processo de operações e informação (MAÇADA, 2007).
De forma geral, a maior parte do investimento é feito na área operacional, como a compra de
guindastes mais potentes, portêineres, câmeras de vigilância, treinamentos dos operários. Porém,
uma parte do investimento (da qual é difícil precisar a porcentagem), vai para a área de automação e
sistemas de informação.
9
Assim, as empresas estão investindo em SI (Sistema de Informação) para o controle de
operações de pátio, agregados ao uso de dispositivos móveis, etiquetas de rádio freqüência,
catracas, leitor de códigos de barras, com o objetivo de agilizar os processos internos e fornecer aos
elos da cadeira logística informações precisas e da forma mais rápida possível.
A Modallport Sistemas vem fornecendo soluções desse tipo desde 1995, ajudando seus
clientes a atingir as metas descritas, com sistemas para a área de armazéns, de portos, de terminais
de contêineres, controle de importação, de EDIs (Electronic Data Interchange), dentre inúmeros
outros.
O sistema móvel desenvolvido nesse trabalho, integrado ao sistema de controle de terminais
de vazios da Modallport, encontra-se dentro dessa tendência. Na verdade, umas das grandes
motivações para o seu desenvolvimento foram as necessidades vinda dos próprios terminais, que
vêm solicitando o sistema como forma de agilizar seus processos e atender de forma mais precisa
seus clientes.
2.2.2 Missão do Terminal de Contêiner Vazio
A solução móvel será usada por um terminal de contêiner vazio, cuja missão é zelar pelo
contêiner armazenado em seu pátio. Assim, essa seção mostra as principais características do
contêiner, do terminal de contêiner vazio e onde ele se encontra dentro da logística da área
portuária.
Segundo entrevistas com analistas de negócios e sistemas da Modallport, é necessário um
conhecimento prévio desses conceitos para uma melhor compreensão do sistema a ser
desenvolvido, principalmente no levantamento de requisitos junto ao cliente. Além disso, o sistema
objetiva controlar o contêiner e o terminal precisa saber suas características como tamanho, tara,
MGW (Maximum Gross Weight), tipo, assim como uma loja precisa manter informações sobre os
produtos que estão à venda.
10
2.2.2.1 Contêiner
De acordo com o GUIA LOGISTICO (2007), designa-se contêiner um:
Equipamento de metal no formato de uma grande caixa, que serve para o transporte de diversos materiais, fazendo assim uma unitização de cargas, que ao estarem
acondicionados no seu interior, não sofrem danos durante o percurso e nem em caso de
transbordo para outros modais. (...) Podemos dizer que é uma grande embalagem de
metal para transporte e proteção de cargas.
De acordo com a Revista Portuária (2006), o contêiner foi criado no ano de 1957 pelo
empresário norte americano Malcon P. McLean para o transporte doméstico de cargas, e com o
tempo percebeu-se que era o meio eficiente e seguro para tal, sendo adotado em vários portos ao
redor do mundo.
Segundo Rumos (1999), �o container é responsável por uma verdadeira revolução no
transporte internacional. Começando pela redução de custos devido à facilidade de movimentação e
à maior proteção da carga contra intempéries, roubo e todo tipo de dano�.
Dentro das características que determinam o seu grande uso no transporte de cargas, cita-se
que os contêineres são de fácil carregamento e descarregamento, suportam o uso repetitivo e são
duráveis, além de serem adequados à movimentação mecânica e ao transportes por diferentes tipos
de equipamento (GARCIA JUNIOR, 2003).
Os armadores, seus donos, possuem milhares de contêineres espalhados ao redor do mundo.
Além disso, também são proprietários de dezenas de navios ou responsáveis por viagens de navios
de outros armadores.
Classificação dos Contêineres
Garcia Junior (2003) classifica os contêineres quanto aos padrões de peso e medidas e à
natureza da carga a ser transportada. Com o grande uso dos contêineres ao redor do mundo, foi
necessária a criação de normas técnicas que especificassem um padrão na sua classificação. Coube
a ISO (International Standard Organization), a tarefa de fazê-lo, e atualmente, suas determinações
são aceitas na maior parte do mundo.
A unidade padrão de medida adotada é o pé, simbolizado pelas aspas simples (�) e a
polegada, simbolizada pela aspas dupla (��). As medidas mais comuns dos contêineres são
mostradas na Tabela 1.
11
Tabela 1. Medidas de um contêiner
Contêiner Medida
Comprimento 20� e 40� Altura 8� até 9� 6�� Largura 8� Peso ou Tara 20�: até 2 T (Tonelada) e 40�: até 3.5 T MGW 20�: até 24 T e 40�: até 30 T
Fonte: Garcia Junior (2003)
Uma unidade muito empregada é o TEU (Twenty foot Equivalent Unit) que equivale a um
contêiner de 20�, e 2 TEUs, que equivale a 2 contêineres de 20� ou um de 40� (BANDEIRA, 2005).
De acordo com Garcia Junior (2003) e Rumos (1999), a natureza da carga a ser transportada
define o tipo do contêiner, e pode-se classificá-la em:
Unidades de Carga Geral ou Dry (carga seca): O tipo mais usado de contêiner devido a sua
grande flexibilidade de acondicionamento de cargas, pode ser usado tanto para carga granel
como para carga geral. A Figura 2 ilustra esse tipo.
Unidades Tanques: São usados para o transporte de granéis líquidos, como os derivados do
petróleo, petróleo, gases comprimidos. É ilustrado na Figura 3.
Unidades Reefer: São contêineres com sistemas de refrigeração acoplados. São usados para
cargas que exigem controle de temperatura, como as perecíveis (frango, carnes em geral). É
ilustrado na Figura 7.
Unidades de Granéis: São os contêineres usados para o transporte ou acondicionamento
granéis sólidos (minérios, cereais, fertilizantes, entre outros). Um dos tipos mais comuns é o
Open Top, em que a carga entra pelo teto do contêiner, como mostrado na Figura 4.
Contêiner plataforma e Flat Rack: São constituídos de uma base dotada de dispositivos de
canto, e se destina a cargas que excedem as dimensões normais dos contêineres, como
máquinas para agricultura, barcos, tanques, caminhões, bobinas de papel, dentre outros. São
mostrados nas figuras 5 e 6.
12
Figura 2: Contêiner Dry
Fonte: Garcia Junior (2003).
Figura 3. Contêiner Tanque
Fonte: Garcia Junior (2003).
Figura 4. Contêiner Open Top
Fonte: Worldnetlogistics (2007).
Figura 5. Flat Rack
Fonte: Rumos (1999).
Figura 6. Plataforma
Fonte: Rumos (1999).
Figura 7. Reefer
Fonte: Rumos (1999).
Essa classificação mostra, em resumo, os tipos mais comuns de contêineres. Conforme
pesquisa no Sistema Modall, cada tipo de contêiner é designado por uma sigla de dois dígitos,
conforme relaciona a Tabela 2.
Tabela 2. Siglas do contêiner no Sistema Modall
Tipo do Contêiner Siglas no Sistema Modallport
Unidades de Carga Geral (Dry) DC, HC, DV, OT Unidades Tanques TK Unidades Reefer RH, RF, RE, IN Unidades de Granéis OT Contêiner plataforma ou Flat Rack PL, FR
Fonte: Sistema Modall.
No Sistema Modall, a sigla do tipo do contêiner (DC, HC, dentre outros), junto a seu
tamanho (20� ou 40�), forma a identificação do tipo do contêiner. Assim, diz-se que um contêiner é
um DC20 ou DC40, significando um tipo dry de 20� e dry de 40� respectivamente. Essa forma
representa uma maneira usual de representar o tipo do contêiner, porém, não é a forma adotada pela
ISO. A ISO os representa através de um número de 4 dígitos, como no exemplo da Tabela 3.
13
Tabela 3. Exemplo da montagem de códigos ISO.
Tamanho Código do Tipo
20 00 - Contêiner fechado, para carga geral. 40 00 - Contêiner fechado, para carga geral.
O código ISO final é representado como 2000 e 4000. No Sistema Modall, as duas formas
são suportadas, ou seja, o tipo do contêiner pode ser identificado tanto como 4000 ou DC40.
Identificação dos Contêineres
Conforme Garcia Junior (2003) e pesquisas no Sistema Modall, a codificação dos
contêineres é dada pela norma ISO 2716 (Indentication Marking Code for Freight Conteiners), e é
formado pelos seguintes itens:
Código do Proprietário: Formado por três letras maiúsculas do alfabeto latino;
Unidade - Fixo U;
Número de Série - É formado por seis algarismos arábicos. Se o número de série tiver
menos do que seis algarismos significativos, o mesmo deve ser precedido de certo número
de zeros até completar seis algarismos; e
Número de controle ou código de dígito - Permite que se verifique a correção do registro do
código do proprietário e do número de série.
Exemplo: CSVU 123456-7
CSV � Código do proprietário, nesse caso, o armador CSAV;
U - Fixo;
123456 - Número de Série; e
7 � Número de Controle.
Além do identificador e do número ISO, o contêiner também possui outras características,
tais como:
Tara: É o peso do contêiner quando vazio;
MGW: É o peso máximo que um contêiner pode suportar quando cheio;
14
Net: Capacidade de carga do contêiner. É subtração do MGW pela tara; e
Capacidade cúbica: Capacidade cúbica (em m3) do interior do contêiner, disponível para o
depósito das cargas.
Esses dados estão fixados parte exterior do contêiner, geralmente na parte de trás, mas
também pode vir descrito nas laterais, ou em ambas. A Figura 8 mostra a localização dos dados na
parte traseira de um contêiner, que representa uma das formas mais comuns.
Figura 8. Identificação dos dados do contêiner
2.2.2.2 Missão do Terminal
Um terminal de contêiner vazio é uma organização que tem por objetivos fornecer aos
armadores serviços de armazenagem, oficina, inspeção e lavação de contêineres vazios. Em suma,
zelar pela integridade do contêiner para o armador. Bandeira (2005) designa um terminal como
�depósito�. De fato, trata-se de um depósito de contêiner vazio, sendo o termo DEPOT (Depósito
Terminal) um termo bem conhecido para designar um terminal.
Para Bandeira (2005):
Existem dois tipos de depósitos: depósitos de leasing, aonde as companhias navais vão
buscar contêineres para arrendamento de curto prazo, e depósitos de armazenagem, onde
as companhias de navegação armazenam seu estoque de contêiner vazio. Na prática, os
dois tipos de depósitos podem estar no mesmo local.
MGW
Tara
Capacidade cúbica
NET
Identificador do
Contêiner
Código ISO
Armador
15
Geralmente situam-se em áreas portuárias (como Santos, Paranaguá, Itajaí, dentre outros), e
são constituídos de imensos pátios vazios para a colocação dos contêineres, de área para
administração e área para oficina de reparos. Segundo Luiz Carlos Bonneti, gerente comercial da
Modallport Sistemas, grande parte deles também oferecem serviços de armazenagem de contêineres
cheios ou de carga solta. Alguns terminais estão dentro de uma estrutura portuária, como no caso do
Porto de Vila do Conde (Barcarena, PA), ou no Porto de Santos (SP).
De forma geral, os principais serviços oferecidos pelos terminais, em relação ao contêiner
vazio, são:
Armazenagem de contêiner vazio: guardar em seu pátio os contêineres dos armadores;
Inspeção e reparo de contêineres reefer: fazer a vistoria de contêineres refrigerados para
determinar se estão avariados, para, então, repará-los em sua oficina;
Inspeção e reparo e de contêineres dry: fazer a vistoria de contêineres dry para determinar se
estão avariados, para, então, repará-los em sua oficina; e
Limpeza: realizar a limpeza os contêineres vazios.
2.2.3 Cadeia Logística do Contêiner Vazio
Para melhor compreender o papel do terminal de vazios dentro da cadeira logística portuária
e posteriormente, os processos do terminal, o ciclo de vida do contêiner na cadeia logística explica-
se a seguir.
Segundo Bandeira (2005), o ciclo origina-se e termina no terminal, com o contêiner já vazio,
sendo feito por um conjunto de eventos de importação e exportação, resumindo a cadeia da seguinte
forma:
1 - Um cliente (exportador) retira um contêiner vazio de um depósito, que normalmente está
localizado próximo a um porto;
2 - Após carregá-lo (unitizar, deixando-o cheio) o cliente leva o contêiner ao porto poucos
dias antes da data prevista para a partida do navio;
3 - O contêiner será então colocado no navio (embarque), que irá para o porto de destino.
4 - Após chegar ao porto de destino, o contêiner desembarcará no porto e será direcionado
ao importador;
16
5 - Este irá desunitizar o contêiner (tirar as cargas), e devolvê-lo vazio a um terminal de
contêineres vazio ou diretamente ao porto; e
6 - Esse contêiner vazio poderá então ser utilizado para satisfazer a demanda deste porto, ou
armazenado como estoque, para então, ser enviado novamente a um exportador, iniciando o
processo novamente. A Figura 9 ilustra todo esse processo.
Figura 9. Cadeia logística do contêiner vazio
Segundo especialistas da Modallport, o contêiner pode entrar no terminal através de três
formas:
Devolução de Exportação: É quando o contêiner volta ao terminal devido ao cancelamento
da exportação, depois de ele ter saído para tal;
Devolução de Importação: É quando o contêiner vem de uma importação, é desunitizado no
importador e vai vazio para o terminal; e
Reposicionamento entre portos: É quando o armador transfere o contêiner de um terminal
para outro para uso futuro.
Ainda segundo considerações dos especialistas, o contêiner pode sair para ser reposicionado
a outro terminal (reposicionamento entre portos), para unitização no exportador para exportação
posterior ou para venda.
Dessa forma, vê-se que o terminal é uma peça importante dentro dos ciclos de
importação/exportação, sendo sua operação vital para toda a cadeia logística do país e em última
análise, para a economia como um todo.
2.3 SISTEMA DE INFORMAÇÃO
Nas últimas décadas, a crescente competição global por recursos e mercados exigiu das
empresas uma série de mudanças e adaptações para sobrevivência. Segundo Covey (2005),
17
passamos da era industrial, baseada nos meio de produção, para a era do conhecimento, baseado em
informação e em como as pessoas aplicam seu conhecimento.
De acordo com Laudon e Laudon (2001), é necessário um amplo conhecimento sobre
sistemas de informação para atingir níveis mais altos de produtividade nas fábricas e escritórios. Os
desafios colocados pelo novo mundo que surge, pedem muitos tipos de mudanças, como novos
sistemas administrativos, novas técnicas de produção, novas habilidades dos empregados, sendo os
sistemas de informação uma ferramenta necessária para aumentar a capacidade de reação da
organização, facilitando o trabalho baseado no conhecimento.
Para Laudon e Laudon (2001), um sistema de informação é um:
Um conjunto de componentes inter-relacionados, trabalhando juntos para coletar, recuperar, processar e distribuir informações com a finalidade de facilitar o planejamento,
o controle, a coordenação, a análise e o processo decisório em empresas e outras
organizações.
O sistema de informação tem o objetivo de transformar o dado em informação, tornando-o
útil ás organizações (GIL, 1995). Para O�Brien (2001), num SI, as informações são coletadas,
processadas e então enviadas aos gestores de conhecimento (administradores, gerentes, consultores,
dentre outros). De acordo com O�Brien (2001) e Laudon e Laudon (2001), o sistema de informação
é formado pelas seguintes partes:
Entrada: Onde os recursos são introduzidos, provenientes da organização ou de fora dela;
Processamento: Onde a entrada é processada no sistema, produzindo um elemento para a
saída;
Saída: É resultado obtido no processamento, o objetivo do sistema. A saída vai para o
ambiente remoto ou próximo;
Feedback ou realimentação: É uma saída que retorna a entrada. Visa realizar ajustes na
entrada ou no processamento, podendo ser realizada por pessoas, ou automaticamente pelo
sistema; e
Ambiente: Local em torno do qual o sistema opera e para onde a saída é enviada.
Além do SI em si, que faz parte da organização, pode-se analisar a própria organização
como um sistema, trocando informações com o SI. O�Brien (2001) relaciona sistemas e
organizações da seguinte forma:
18
Uma empresa é um sistema organizacional no qual os recursos econômicos (entrada) são
transformados por vários processos organizacionais (processamento) em bens e serviços
(saída). Os sistemas de informação fornecem para a administração informações do sistema
para sua direção e manutenção (controle), enquanto ele troca entradas e saídas com seu
ambiente.
Todo processo que ocorre dentro de um terminal de vazios pode ser visto sob a ótica de um
sistema. Por exemplo, o contêiner entra (entrada), a seguir é vistoriado, inspecionado ou consertado
(processamento), e, finalmente sai do terminal (saída). Em cada parte desse processo são gerados
dados que vão para o SI, das quais são validados, guardados no banco de dados e processados para
gerar relatórios gerenciais, faturamento de serviços e uma serie de informações úteis ao auxilio da
tomada de decisões em diferentes níveis organizacionais. A Figura 10 ilustra esse processo, com o
sistema de informação inserido nela.
Figura 10. Modelo representando o sistema de um terminal de contêiner vazio
Fonte: Baseado em O�Brien (2001).
Para Laudon e Laudon (2001), os SI são montados para resolver problemas importantes que
surgem nas organizações. A solução móvel integrada ao Sistema Modall busca resolver os
problemas de processo explicados anteriormente.
2.3.1 Componentes dos Sistemas de Informação
Para Laudon e Laudon (2001), �um sistema bem sucedido tem dimensões organizacional e
humana, além dos componentes técnicos�.
Os recursos técnicos são os hardwares e software, como o sistema em si, o computador onde
é rodado, a estrutura de rede, o sistema operacional. Os recursos organizacionais são as estratégias e
19
regras usadas para operação do sistema, como as políticas de segurança, o acesso aos dados, os
processos do negócio. Os recursos humanos são as pessoas que operam o sistema, podendo ser os
usuários, que o usam para seu beneficio, ou os profissionais, que dão suporte técnico ao uso.
Na solução móvel, a dimensão tecnológica envolve toda solução pronta, o ambiente de
desenvolvimento, o projeto, o dispositivo utilizado, e a estrutura de rede necessária ao
funcionamento. A dimensão humana envolve a questão da usabilidade, muito importante nesses
tipos de sistemas e a dimensão organizacional envolve as regras e fluxo de trabalho de todo o
terminal. Cada um desses itens foi tratado nesse projeto.
2.3.2 Classificação dos Sistemas de Informação
Laudon e Laudon (2001), classifica os SI de acordo com os níveis existentes na
organização:
Sistemas de Nível Operacional;
Sistemas de Nível do Conhecimento;
Sistemas de Nível Gerencial; e
Sistemas de Nível Estratégico.
Os Sistemas de Nível Operacional são os Sistemas de Processamento de Transações (SPT),
que controlam as informações que são geradas diariamente pelos processos da empresa, autuando
em seu nível operacional. Segundo Laudon e Laudon (2001), �transação é o registro de um evento a
qual a empresa deve responder�. Esse evento pode ser um contêiner que entrou no terminal, o seu
reposicionamento no pátio, o atendimento do pedido de informação do armador, a consulta sobre os
dados de um contêiner.
Esses sistemas exercem um papel crucialmente importante nas organizações. De acordo com
Laudon e Laudon (2001):
Os sistemas empresariais básicos atendem o nível mais elementar de uma organização
processando os dados de suas operações. Esses sistemas mantêm registros das atividades
empresariais rotineiras. (...) Eles dão suporte as funções de gravação, monitoramento e
avaliação das atividades básicas da empresa. Esses sistemas são importantes fornecedores
de dados para o nível operacional e também para os níveis mais elevados de uma empresa.
Grande parte de sua saída é essencial para a sobrevivência diária da empresa.
20
Segundo Linhares (2006), as informações �devem ser de fácil acesso, atualizadas e precisas,
para que os gerentes possam acompanhar os acontecimentos diários da empresa, proporcionando
maiores conhecimento dos fatos operacionais�.
Os Sistemas de Nível do Conhecimento, também chamados de Sistemas de Trabalhadores
do Conhecimento (STC), tem a função de apoiar a criação, a organização e a disseminação do
conhecimento para a organização.
Sistemas de Nível Gerencial são sistemas que fornecem ao nível gerencial das organizações,
informação e apoio para a tomada de decisão eficaz (O�Brien, 2001). Dividem-se em Sistemas de
Informações Gerenciais (SIG) e Sistemas de Apoio a Decisões (SAD) . Ambas processam dados
vindos dos SPT para gerar informações analíticas, em forma de gráficos ou relatórios.
Sistemas de Nível Estratégico, também chamados de Sistemas de Apoio aos Executivos
(SAE) ou Sistemas de Informação Estratégica, são os sistemas que ajudam os executivos em
questões estratégicas e de longo prazo, ou a definir tendências do negócio. Eles obtêm informações
dos outros tipos de SI.
Dessa forma, vê-se que é necessária uma interligação entre todos os SI da organização, de
modo a trabalharem juntos e completarem-se mutuamente. Segundo Oliveira (2005, p 71), �todos
os sistemas de informação atuam e devem interagir entre si, um influenciando e complementando o
outro. Dessa forma, visualizaremos a empresa como um grande processo�. A Figura 11 ilustra a
relação descrita.
Figura 11. Ligação entre os tipos de sistemas de informação
Fonte: Adaptado de Laudon e Laudon (2001).
21
A Solução Móvel se encaixa na categoria de STP, pois sua função é coletar os dados
provenientes das operações diárias e rotineiras do terminal e enviá-los a base de dados do Sistema
Modall. Além disso, o sistema usa esses dados coletados como entrada em outros sistemas
gerenciais importantes (como o sistema financeiro e de controle de qualidade), concluindo-se que é
vital que o sistema os colete da forma mais precisa possível.
O Sistema Modall completo, através de seus módulos individuais, pode ser classificado
tanto como um SPT, apoiando as operações diárias, como um SIG, fornecendo aos gerentes
informações importantes para a tomada de decisões. Geralmente, cada módulo possui uma seção de
relatórios gerenciais e gráficos específicos.
2.3.3 Processos Organizacionais
Todas as organizações operaram através de processos, com o objetivo de oferecer produtos
ou serviços a alguém. Hammer e Champy (1994) definem processo como uma �seqüência lógica
com objetivo de produzir um bem ou um serviço que tem valor para um grupo específico de
clientes�.
O�Brien(2001) define processo nas organizações em termos de processos empresariais: eles
refletem a maneira especifica pelas quais as organizações coordenam o trabalho, a informação, o
conhecimento, sendo que os processos bem desenvolvidos e executados podem tornar a organização
mais eficiente e competitiva.
Segundo Oliveira (2005) processo �é a maneira como os componentes se relacionam para
criar uma seqüência de operações ou procedimentos que produzem os resultados esperados�. Para
Cruz (2000), na grande maioria das pequenas e médias empresas existe apenas um processo,
podendo o mesmo ser dividido em subprocesso, atividades, procedimentos e tarefas.
As empresas operam através de processos, e apesar de determinados processos estarem bem
definidos ou documentados, eles ocorrem de alguma forma. Um processo organizado e bem
descrito evita erros em geral e a organização ganha em eficiência e eficácia, evitando custos
desnecessários.
Dentro de um terminal de contêiner vazio, podem-se descrever vários processos e
atividades que ocorre com o contêiner. Assim, o projeto definiu esses conceitos para facilitar o
estudo dos processos do terminal, de modo a levantar os requisitos do sistema da forma mais correta
22
possível. Na seção de projeto desse trabalho, são mostrados todos os processos que ocorrem dentro
do terminal em relação ao contêiner.
2.3.3.1 Processos através da Tecnologia da Informação
De acordo com Linhares (2006), a tecnologia tem um papel importante no estudo de
processos, tanto na forma de executar o trabalho como de gerenciá-lo.
A tecnologia da informação faz com procedimentos e atividades fiquem subordinadas a suas
regras, alterando os procedimentos de trabalhos de uma organização. Além disso, segundo
Gonçalves (2000), a TI pode ajudar inúmeras atividades como:
Visualização de processos;
Automatização e execução de processos;
Gestão de processos;
Sincronização de atividades;
Coordenação de esforços; e
Monitoramento do desempenho e comunicação dos processos.
Dentro dessa visão, a função da solução móvel é apoiar a automatização do processo, que é
feito através de pranchetas e papel, sendo um passo necessário na implantação de outras tecnologias
como etiquetas de radio freqüência. Além disso, corrige a falta de sincronia entre as atividades
interdependentes, como explicado nas figuras 12 e 13.
2.3.4 Qualidade da Informação
Segundo Banzato, Moura e Carillo Junior (2003), sistemas de informação para a
armazenagem devem prover rapidamente informações de forma rápida e de qualidade, sendo essas
características a base da eficiência das operações de armazenagens.
Para O�Brien (2001), a informação, para ser considera adequada, deve ter diversas
características, as quais precisam ser incorporadas a todos os sistemas de informação. Se elas forem
inexatas ou desatualizadas, a organização poderá tomar decisões ruins em seus negócios, além de
causar custos adicionais. As qualidades mais importantes, segundo O�Brien (2001), estão descritas a
seguir:
23
Oportuna ou acessível: deve estar disponível no momento e local necessário;
Atual: deve basear-se em dados o mais atual possível;
Exata ou confiável: não deve conter erros;
Relevante: deve ser relacionada com as necessidades de um usuário, para uma utilidade
específica;
Clara ou simples: deve ser fácil de perceber e interpretar. Informações sofisticadas podem
mais atrapalhar do que ajudar; e
Segura: deve ser segura para permitir acesso somente aos usuários autorizados.
Como já explicado anteriormente, o sistema de controle de terminais de contêiner vazio da
Modallport Sistemas não fornecem informações acessíveis e atuais. Ela só pode ser obtida num
computador desktop, e a entrada dos dados não é feita no momento em que o processo ocorre, sendo
o sistema móvel a solução que resolverá esse problema.
As figuras a seguir, ilustram um processo que ocorre atualmente, e como ele ficará com a
adoção da solução móvel. Os conceitos referentes ao processo em si serão explicados mais adiante.
Figura 12. Vistoria de um contêiner realizada no Sistema Modall.
Entrada de Contêiner Vistoria
Saída de
Contêiner Entrada Sistema
Processo Real
Tempo
Entrada de Contêiner
Vistoria
Saída de
Contêiner
24
Figura 13. Vistoria de um contêiner realizada no Sistema Modall, com a adoção da solução móvel.
Nota-se, na Figura 12, que a vistoria só é digitada no sistema após a saída efetiva do
contêiner. Ocorre que, ao realizar uma saída, o sistema valida as informações de vistoria, e como ela
não existe, uma série de problemas pode ocorrer com essa validação de regra de negócios. Já na
Figura 13, verifica-se que o problema não existe, e o problema da atualidade da informação é
resolvido.
2.4 Computação Móvel
Nessa seção mostra-se conceitos relativos à computação móvel, relacionando as
características da mobilidade e dos tipos de dispositivos, as tecnologias de comunicação sem fio, as
arquiteturas possíveis de soluções, o ambiente de desenvolvimento a ser usado e três estudos caso
de soluções móveis empregados na área portuária.
Segundo Ferreira (2006), �nos últimos anos, houve um grande crescimento no
desenvolvimento de tecnologias para a computação móvel. A computação móvel surge como uma
forte tendência no mundo moderno�. Para Matheus e Loureiro (1998), a computação móvel
representa de fato a revolução da informação.
Turisco e Case (2001 apud Crispim Junior 2006) define computação móvel como qualquer
solução onde a aplicação seja acessada via dispositivo de mão, realize transporte de dados de e para
onde o dispositivo precisar, além de suportar comunicação através de tecnologias wireless e realizar
processamento em lotes com fins de atualização.
Entrada de Contêiner
Saída de Contêiner
Entrada de Contêiner
Saída de
Contêiner
Entrada sistema
Processo Real
Tempo
Vistoria
Vistoria
25
Segundo Isam (2007), a computação móvel surge como uma proposta de um novo
paradigma para a computação, juntando tecnologia de rede sem fio, sistemas distribuídos e
permitindo ao usuário, portanto dispositivos móveis, ter acesso a uma infra-estrutura de rede
independente de sua localização.
Lee, Schneider e Schell (2005) descrevem as principais características da mobilidade:
Portabilidade: É a capacidade de ser facilmente transportável, levando em conta fatores
como tamanho e peso do dispositivo. Atualmente, portável significa ser facilmente
transportável pela mão;
Usabilidade: É dependente de vários fatores, como capacidade e conhecimento do
usuário, condições de funcionamento do ambiente de trabalho e as próprias
características do dispositivo como robustez e interface com o usuário;
Funcionalidade: São as aplicações que rodam num dispositivo; e
Conectividade: Em geral, operam em um de três modos: sempre conectado a um
sistema back-end; conectado de forma intermitente a um sistema back-end; e
inteiramente sem conexão a um sistema back-end.
O dispositivo ou sistema móvel que oferece a melhor mobilidade terá uma combinação
dessas características, e a importância de cada uma depende da aplicação a ser desenvolvida.
2.4.1 Dispositivos móveis
De acordo com Ferreira (2006), a computação móvel é caracterizada por um dispositivo
móvel, com capacidade de processamento, em um ambiente de rede sem fio.
Segundo Mateus e Loureiro (1998), o dispositivo móvel deve ser facilmente manipulável
pelo usuário, ter capacidade de processamento e troca de informações via rede. Para isso, ele precisa
ser de tamanho reduzido, caber na palma da mão ou colo, não precisar de cabos para conectá-lo à
rede elétrica e à rede de dados, possuir uma bateria e ter acesso a rede através de tecnologias de
redes sem fio.
Para Mateus e Loureiro (1998) e Lee, Schneider e Schell (2005), dentre os dispositivos
existentes citam-se: PDAs, celulares, smartphones, notebooks, tablet PCs, dentre outros.
26
Segundo o Dicionário Info (2004), PDA (Personal Digital Assistants) é um computador de
mão, também chamado de palmtop ou handheld, geralmente apresenta tamanho reduzido, é capaz
de acessar uma rede sem fio e tem grande poder de processamento e memória. Segundo Figueiredo
e Nakamura (2003), geralmente não possuem teclado, ou esse é bastante reduzido, e nem mouse, e a
entrada de dados pode ser feita através de uma caneta e um reconhecedor de escrita. Quanto à
bateria, possuem boa autonomia de tempo de uso. Também são conhecidos como PocketPC ou
Pocket PC.
Segundo Figueiredo e Nakamura (2003), os celulares possuem característica semelhante aos
PDAs, mas a forma de interagir com eles é ainda mais restrita, com teclado e tela de tamanho mais
reduzido. Atualmente, tem capacidade de processamento e comunicação através da integração da
rede celular com rede de dados, em especial a internet. Outra categoria que vem surgindo são os
smartphones, que unem as características de um celular e de um PDA. Há uma grande variedade de
tipos de celular para variados tipos de usuários, com diversos serviços e funções oferecidos pelas
operadoras.
Para Lee, Schneider e Schell (2005), notebook, ou laptop, pretendem ser uma versão móvel
completa com todos os recursos de um computador desktop, além de poderem executar os
programas que os computadores desktops executam. Possuem teclados padrão e mouse como
dispositivo de entrada e tela de vídeo equivalente a dos desktops. São provavelmente os maiores
dispositivos móveis que existem.
Um tablet PC é um computador móvel integrado a uma grande tela, onde o usuário pode
escrever diretamente sobre a tela usando uma caneta. Possui quase todas as funções de um
computador desktop. Um dispositivo PDA pode ser considerado um tablet PC, porém, esse roda
um sistema operacional mais poderoso, sendo de inicialização mais demorada (LEE; SCHNEIDER
e SCHELL, 2005).
O estudo dos tipos de dispositivos móveis visou determinar qual o modelo mais adequado
para o uso considerando o ambiente organizacional em que rodará. Não foram encontrados
trabalhos científicos que falam especificamente sobre dispositivos móveis para a área portuária ou
de terminais de vazios. No entanto, de acordo com percepções de especialistas e clientes da
Modallport, eles devem permitir o uso das funções de forma fácil e ágil, ser resistentes a umidade, a
poeira, a quedas bruscas e ao uso constante. Os Pockets PCs são a categoria que se enquadra melhor
nessas características.
27
Assim, pesquisou-se Pockets PCs de fabricantes como CipherLab e Symbol, responsáveis
por fabricar dispositivos para automação comercial e industrial em geral. O modelo escolhido foi o
Terminal Coletor de dados CPT 9500 (Pocket PC), da CipherLab (Figura 14), que atende esses
requisitos. Segundo Compex (2007), o CPT 9500 foi desenvolvido para suportar ambientes hostis,
sendo resistente a quedas de até 1,5 m em concreto, além de estar na norma de proteção IP94, que
especifica imunidade contra poeira e contra respingos e projeções de água. Além disso, roda o
Microsoft Pocket PC 2003 2ª Edição ou o Windows CE 5.0, possui tela touch screen, 128 MB de
Flash ROM e 64 MB SDRAM. As características completas encontram-se no Anexo I.
Figura 14. Terminal Coletor de dados CPT 9500
Fonte: Compex (2007).
2.4.2 Tecnologia de comunicação sem fio
Os dispositivos móveis precisam se conectar a uma rede de dados a fim de trocar
informações com eles. Assim, serão apresentados os métodos de conexão sem fio mais utilizados,
com o objetivo de determinar qual deles se enquadra no ambiente do sistema a ser construído e de
compreender melhor as tecnologias.
Para a comunicação na computação móvel, é necessária uma infra-estrutura que forneça aos
dispositivos móveis a capacidade de troca de informações para uma rede fixa (FIGUEIREDO e
NAKAMURA, 2003). Para Lee, Schneider e Schell (2005), existem vários métodos de conexão
sem fio, como celular, bluetooth, redes de satélites, rede local sem fio, dentre outras.
As redes celulares são compostas de conjuntos de áreas contíguas de cobertura de rádio
chamadas células. Quando usuários de um dispositivo móvel estão dentro de uma célula são
28
capazes de utilizar os serviços do dispositivo móvel. Quando saem de uma célula, automaticamente
são enviados a uma nova célula. Essas redes podem ser acessadas por celulares, smarthphones e
vários modelos de pockets PCs.
Bluetooth é um método de conexão sem fio que usa freqüência de rádios de curto alcance,
num intervalo de até 10 metros. Para o Guia do Hardware (2007b), em situações ideais, pode atingir
100 metros. Essa tecnologia não exige que os dispositivos fiquem em linha reta entre si, como no
caso da tecnologia de infravermelho. Com ela, é possível formar uma PAN (Personal Área
Network), com múltiplos dispositivos móveis comunicando-se entre si, permitindo a troca de dados
entre amigos por exemplo. Estão presente em grande parte dos celulares, Pockets PC, smarthphones
e notebooks do mercado.
O uso mais comum das redes de satélites é o GPS (Global Positioning System), que permite
determinar a localização do dispositivo móvel. Atualmente, muitos modelos de dispositivos móveis
usam receptores de GPS, como os de celulares, PDAs e smarthphones.
Segundo Lee, Schneider e Schell (2005), uma rede local sem fio, wireless LAN (Local Area
Network) ou WLAN (Wireless Local Area Network), é uma rede local que usa tecnologia sem fio
para comunicar-se com dispositivos móveis, sendo configuradas em escritórios corporativos para
permitir o deslocamento dos usuários por todo o edifício. Há vários padrões para comunicação,
como o IEEE 802.11b, o IEEE 802.11a e o IEEE 802.11g. O IEEE (Instituto de Engenharia Elétrica
e Eletrônica) é uma organização reconhecida mundialmente que desenvolve padrões para a indústria
de computadores e eletro-eletrônicos, e esses três padrões foram desenvolvidos por eles.
Segundo Luz (2006), as redes 802.11b ou Wi-Fi (Wireless Fidelity), são as mais empregadas
para redes locais sem fio, oferecendo uma taxa de transferência de 11 Mbps (Megabits por
segundo), mas na prática ela fica em torno de 2 Mbps. Segundo Figueiredo e Nakamura (2003, p.
21), o Wi-Fi �é a tecnologia ideal para substituir infra-estrutura de cabos onde não for possível ou
conveniente utilizá-la�.
Segundo Wireless Brasil (2007), as redes 802.11a tem uma velocidade máxima de 54 Mbps,
cerca de cinco vezes a do Wi-Fi, mas em compensação, a distância máxima de conexão por 802.11a
fica em torno de 20 metros, um quinto do alcance dos 802.11b. Uma área que pode ser interligada
com um ou dois pontos de acesso Wi-Fi exigiria cerca de dez pontos de acesso 802.11a. Isso
significa que no ambiente corporativo as redes 802.11a são mais caras.
29
Para o Guia do Hardware (2007a), o padrão de redes wireless atual é o 802.11g. Ele é
compatível com o padrão 802.11b, o que permite o uso de placas de rede e pontos de acesso
802.11g a uma rede 802.11b já existente, mantendo os componentes antigos. A velocidade de
transmissão no 802.11g é de 54 megabits, (como nas 802.11a), mas seu raio de alcance é bem
maior. Para IDGNOW (2007), um típico roteador Wi-Fi permite a cobertura de um raio de 45
metros em ambiente interno e 90 metros em área externa, mas é possível criar redes de múltiplos
pontos para garantir uma área de cobertura maior.
De acordo com Lee, Schneider e Schell (2005), o WiMax (Worldwide Interoperability for
Microwave Access), padrão 802.16, permitirá o surgimento de redes sem fio metropolitanas, onde
uma única antena atenderá uma área muito maior que a tecnologia Wi-Fi, podendo atingir até 50
quilômetros, com velocidade de até 74 Mbps.
A Tabela 4 resume as principais características das tecnologias apresentadas.
Tabela 4. Resumo Tecnologias de Comunicação sem Fio
Tecnologia Taxa de Transmissão
de Dados
Aplicação Raio de
Alcance
Bluetooth 56 Kbps � 721 Kbps Redes pessoais (PAN) 10 a 100 m Wireless LAN (802.11a) Até 54 Mbps Redes locais (LAN) 25 a 100 m Wireless LAN (802.11b) Até 11 Mbps Redes locais (LAN) 50 a 100 m Wireless LAN (802.11g) Até 54 Mbps Redes locais (LAN) 100 a 150 m WiMax (802.16) Até 74 Mbps Redes metropolitanas (MAN) 50 Km
Fonte: Adaptado de Luz (2006).
Nesse trabalho utilizou-se a tecnologia Wireless LAN padrão IEEE 802.11b, que é
suportada pelo dispositivo CPT 9500, sendo compatível com a estrutura de rede da maioria dos
terminais de contêineres cliente da Modallport
2.4.3 Arquiteturas de aplicações móveis
Essa seção baseou-se no estudo do capítulo �Arquiteturas de aplicação móvel� de Lee,
Schneider e Schell (2005) e na experiência do autor na área.
Uma aplicação móvel pode ser modelada adequadamente pela arquitetura cliente-servidor,
com um ou vários dispositivos solicitando informações a um servidor, e o servidor respondendo
com as informações solicitadas.
30
Os tipos de clientes, que ficam no dispositivo móvel, dividem-se em: clientes gordos e
clientes magros.
Os Clientes Gordos são usados quando não há garantia de conexão entre cliente e servidor, a
camada de apresentação, de negócio, acesso aos dados, além do banco de dados ficam todas no
dispositivo. São dependentes do SO (sistema operacional) e do tipo de dispositivo a ser usado, ou
seja, uma aplicação construída dessa forma geralmente só roda no dispositivo e sistema operacional
empregados. Uma grande vantagem é que são mais fáceis de serem construídos e mantidos.
Já os Clientes Magros são os que possuem pouco ou nenhum código no dispositivo. A
camada de negócio, acesso aos dados e o banco de dados ficam no servidor, assim, são empregados
quando há uma conexão constante e segura entre cliente e servidor. A camada de apresentação pode
ficar tanto no dispositivo móvel quanto do servidor (geralmente páginas web). A grande vantagem
desse tipo é que para aplicações web não há necessidade de atualização no dispositivo, uma vez que
isso é feito no servidor, além de permitirem maior portabilidade de SO e tipo de dispositivo.
Lee, Sheneider e Schell (2005) argumentam que deve-se construir aplicações móvel tão
independentes de dispositivo e plataforma quanto possível, mas isso nem sempre pode ser feito. Na
prática é preciso selecionar um dispositivo e plataforma para escrever a aplicação adequadamente.
Além disso, é desejável que seja escalonável, para suportar aumento de usuários, aplicações e
funcionalidades. Porém, essa afirmação é válida para clientes gordos, mas para clientes magros isso
nem sempre é verdade, por exemplo, uma aplicação que roda num browser é compatível com
grande parte dos dispositivos.
O Sistema Móvel foi desenvolvido numa arquitetura derivada dos clientes gordo, através de
uma aplicação windows, com duas camadas de aplicação: no cliente (dispositivo móvel), fica as
camadas de apresentação, negócio e acesso aos dados, e no servidor fica o SGBD (Sistema
Gerenciador de Banco de Dados) do Oracle, que contem o banco de dados do Sistema Modall (ver
Figura 15). Essa escolha se apóia no princípio da simples construção e manutenção, apesar da falta
de portabilidade. A grande desvantagem dessa escolha é a dificuldade da distribuição de novas
versões, pois é preciso atualizar o aplicativo em cada dispositivo.
O uso de uma aplicação Windows justifica-se por outros dois motivos: possui uma maior e
melhor quantidade de recursos de apresentação de dados, e permite, no futuro, a gravação dos dados
31
no dispositivo, de forma a possibilitar o uso de forma off-line (quando a rede wireless estiver
indisponível).
Nesse modelo, o usuário acessa a camada de apresentação, responsável por mostrar o dados
na tela, que por sua vez, chama a camada de negócio para validar as operações dos usuários (regras
de negócio). A seguir, essa camada de negócio chama a camada de acesso aos dados, que ordena a
execução dos comandos de consultas e gravação no banco de dados no servidor, completando uma
operação solicitada pelo usuário.
Figura 15. Arquitetura da Solução Móvel.
2.4.4 Ambiente de desenvolvimento
2.4.4.1 .NET
A tecnologia .NET, com seu poderoso framework de desenvolvimento, é, atualmente, uma
das melhores ferramentas para o desenvolvimento de aplicações móveis, aplicações para servidores,
aplicações clientes e aplicações web, independente de linguagem, plataforma e dispositivo.
Segundo Lima e Reis (2002) e Deitel et al. (2003), as principais características do .NET
são:
Independência de linguagem de programação;
Simplicidade na resolução de problemas complexos;
Explora o potencial dos WebService e das aplicações distribuídas;
Camada de Apresentação
Regras de negócios
Dispositivo Móvel (Cliente) Máquina PC (Servidor)
SGBD Banco de dados
Comandos
Acesso aos dados
32
Facilita a reutilização de software; e
É independente do tipo de dispositivo.
Segundo Deitel et al. (2003), toda linguagem de programação que suporta .NET gera um
código intermediário, o código MSIL (Microsoft Intermediate Language), que contém todo os
dados necessário para rodar a aplicação. O aplicativo em MSIL deve rodar dentro da CLR
(Commom Language Runtime), que é a máquina virtual do .NET, que através do compilador JIT
(just in time), transforma esse código no código nativo binário da máquina onde rodará (Figura 16).
Figura 16. Processo de geração de uma aplicação .NET
Fonte: Limas e Reis (2002).
Segundo Lima e Reis (2002), outra característica importante da plataforma é o seu
gerenciamento automático da memória, através do Garbage Collector, que é efetuado pelo runtime,
permitindo que o desenvolvedor se concentre na resolução do seu problema específico.
Em relação a aplicativos móveis, de acordo com Haddad (2007), o .NET Compact
Framework (CF), um sub-set do .NET Framework, possibilita o desenvolvimento de aplicações
para dispositivos inteligentes (smart devices) da mesma forma com que aplicativos para desktop são
desenvolvidos. Dessa forma, é possível colocar aplicativos diretos no dispositivo, rodando sob a
máquina virtual do .NET, acessando arquivos, banco de dados ou web services tanto local quanto
remotamente. Nesse caso, é necessário que o SO do dispositivo tenha compatibilidade com o .NET
CF, pois esse roda dependente do sistema operacional. A aplicação, rodando no dispositivo, acessa
a CLR, que roda sob o sistema operacional do dispositivo (Figura 17).
33
Aplicação .NET
CLR .NET CF
Sistema Operacional
Dispositivo Móvel
Figura 17. Processo de execução de uma aplicação .NET.
Segundo Mosimann Netto (2005), a CLR foi otimizada para que permitisse que tudo o que
era possível ser feito com a .NET Framework, também fosse possível de ser feito com a .NET CF,
sendo executada nos mais diversos e diferentes equipamentos. Na prática, grande parte do que era
possível fazer para desktop, é possível fazer para dispositivos móveis, mas com algumas restrições.
Outra possibilidade são as aplicações que rodam através do browser dos dispositivos, as
chamadas .NET Mobile Application, com o uso do ASP .NET Mobile Controls ou Mobile Internet
Toolkit (MIT), que é uma extensão do .NET Compact Framework para aplicações do lado servidor.
Segundo Microsoft (2007a), as principais características do MMIT são:
Geram linguagens markup para diferentes dispositivos;
Possui integração com o Visual Studio .NET baseado no principio de arrastar e soltar;
Capacidades de browser suficientemente poderosas para ampliar o potencial dos
dispositivos ASP .NET aos dispositivos móveis; e
Ampla documentação aos desenvolvedores.
Segundo Microsoft (2007b), uma requisição feita pelo browser do dispositivo é tratada pelo
servidor do ASP .NET, que reconhece o tipo de dispositivo que enviou a requisição e constrói
dinamicamente a linguagem de marcação adequada ao mesmo, como mostra a Figura 18. Isso
elimina a preocupação do desenvolvedor com o tipo de dispositivo usado.
34
Figura 18. Funcionamento do ASP .NET Móbile
Fonte: Adaptado de Microsoft (2007b).
Em relação aos ambientes de desenvolvimento, há duas ferramentas poderosas que são mais
usadas atualmente, o Visual Studio .NET e o C-SharpDevelop.
O Visual Studio .NET é a ferramenta oficial da Microsoft para o desenvolvimento em .NET.
Segundo o MSDNBRASIL (2007), o Visual Studio oferece uma série de ferramentas para a
construção de aplicações Web, desktop e móveis, além de XML Web Services. Permite o uso de
linguagens como Visual Basic, Visual C++, Visual C#, e Visual J#, dentro de um ambiente de
desenvolvimento integrado que facilita o desenvolvimento e integração de diferentes tipos de
aplicações.
O Visual Studio .NET possui um ambiente para o desenvolvimento de aplicações móveis
que emula o dispositivo e seu sistema operacional, não necessitando-os fisicamente para o teste,
além de instalar o .NET-CF (tanto emulado quanto fisicamente) caso esse não exista (MOSIMANN
NETTO, 2005).
Segundo Lima e Reis (2002), C-SharpDevelop é um ambiente open source e gratuito, que
apesar de ser um bom produto não chega ao nível do Visual Studio .NET. A idéia é permitir o uso
da plataforma .NET dentro do Linux, além do Windows e usa a linguagem C#.
2.4.4.2 Tecnologia Java
Verificação da
capacidade do dispositivo
Compilação das
páginas
Geração das telas
Pocket PC Requisições/respostas
Servidor ASP .NET
35
Segundo JavaFree (2007a), Java é uma linguagem de programação e um ambiente de
desenvolvimento, na qual os programas rodam sob a máquina virtual do Java, que é disponível para
a maior parte dos SO existentes.
Segundo Javafree (2007a), as principais características do Java são:
Portabilidade - Independência de plataforma - "write once run anywhere", escreva uma vez,
rode em qualquer lugar;
Simplicidade na especificação, tanto da linguagem como do "ambiente" de execução;
É distribuída com um vasto conjunto de bibliotecas ou APIs;
Possui facilidades para criação de programas distribuídos e multitarefa;
Desalocação de memória automática por processo de coletor de lixo (garbage collector); e
Facilidade para o desenvolvimento de aplicações web e móveis.
De acordo com JavaFree (2007b), todo programa Java é compilado para uma linguagem
intermediária, o bytecode, que depois é interpretada pela Java Virtual Machine (JVM) ou máquina
virtual do Java, disponível para diversas plataformas como Windows, celulares, Linux, dentre
outras, que geram o código nativo para a plataforma onde está rodando (Figura 19). O esquema é
parecido com o .NET, com a CLR equivalendo ao JVM, e o bytecode ao MSIL.
Figura 19. Processo de compilação e execução de um programa Java Fonte: JavaFree (2007b).
Em relação a dispositivo móveis, Java 2 Mobile Edition (J2ME) é a tecnologia Java para
desenvolver para dispositivos como celulares, palmtops, pocket PCs, smartphones e demais
dispositivos. As APIs são bem simples e leves para economizar espaço, memória e processamento.
É dividida em dois grupos:
36
Connected Limited Device Configuration (CLDC): Para celulares e smartphones, que
são mais limitados; e
Connected Device Configuration (CDC): Para Palmtops e Pocket PCs e alguns
dispositivos mais poderosos.
Para Figueiredo e Nakamura (2003), as principais características do J2ME são:
Modularidade e escalabilidade;
Possui um conjunto de tecnologias e ferramentas para o desenvolvimento de aplicação
para os mais diversos dispositivos móveis; e
Facilidade de integração com outras soluções Java, como por exemplo, para aplicações
corporativas e baseadas na Web.
Além do J2ME, é possível desenvolver para computador com maior capacidade de
processamento, como os computadores e notebook, através do Java 2 Standard Edition (J2SE), ou
para construção aplicações corporativas mais robustas, através do Java 2 Enterprise Edition (J2EE).
Crispim (2006) caracteriza a portabilidade e o reuso de código do J2ME como alta, sendo
uma tecnologia que permite a migração da aplicação para diversas outras plataformas ou
dispositivos, e o reaproveitamento dos códigos gerados para outras aplicações, respectivamente.
Porém, para a implementação desse trabalho foi escolhida a plataforma .NET, através do
Visual Studio .NET 2005, porque o aprendizado e a implementação nessa plataforma é mais rápido
e fácil. Além disso, ela é compatível com o dispositivo escolhido para o teste, conforme descrito na
especificação presente no Anexo I.
A aplicação é uma windows application, porque essa fornece maior controle sobre a
interface com o usuário, apesar da necessidade da instalação do .NET CF no dispositivo, e da
necessidade de atualização no dispositivo cada vez que uma alteração de software for feita.
Para a comunicação com o servidor de banco de dados, foi usado o conjunto de
componentes da Corelabs, que permitem uma aplicação windows, rodando num dispositivo móvel
acesse um banco de dados Oracle situado em outro local, sem necessidade de Web Services e do
client do Oracle. Esse método é melhor explicado na seção �3.5 � Implementação�.
37
2.4.5 Trabalhos relacionados
Nessa seção pesquisaram-se algumas soluções móveis feita pela Modallport a fim de atender
necessidades específicas de seus clientes. Com isso, buscaram-se algumas soluções nessa área que
pudesse servir de base para a escolha das tecnologias a serem adotadas nesse trabalho. Como são
produtos comerciais, não há artigos científicos relacionados.
2.4.5.1 Solução para o Porto de Vila do Conde
O porto de Vila do Conde, em Barcarena-Pará, usa um sistema móvel integrado ao Sistema
Modall para o controle de operações portuárias, como embarque e descarga e de terminal de vazios,
como vistoria e estimativas, através do Terminal Portátil Wireless CPT 8370 (pocket PC),
acessando a rede via IEEE 802.11b.
O aplicativo é feito em modo texto (Figura 20), usando a arquitetura de duas camadas
(software e banco de dados) e cliente gordo. O software é acessado via telnet pelo dispositivo
móvel, ou seja, a solução roda num computador normal como uma única aplicação e o pocketPC
apenas serve como um terminal portátil que acessa essa aplicação via cliente telnet do dispositivo.
Por esse motivo, considera-se um cliente gordo, por que todo o código se encontra num único
aplicativo. Essa arquitetura mostrou-se fácil de desenvolver e manter, além de permitir a utilização
por qualquer dispositivo que execute o telnet e que tenha tela menor ou igual ao do modelo da
solução.
Figura 20. Solução Móvel para a Vila do Conde
Fonte: ModallPort Sistemas
O pocket PC especificado é próprio para uso em ambientes sujeito a umidade, poeira e a
quedas bruscas, além de ter um baixo custo. Seu teclado alfanumérico com teclas diferentes para
número e letras (parte das teclas são formadas apenas por letras enquanto outra parte é formada por
metade letra e metade número) facilita a digitação, porém, a tela de tamanho pequeno atrapalha a
38
usabilidade de forma geral. Assim, rotinas com grande quantidade de dados para controle, como a
vistoria e estimativa, mostram-se de difícil uso, pois precisam de rolagens e mensagens curtas e
abreviadas.
2.4.5.2 Solução Móvel para a Amazônia Terminais
A Amazônia Terminais é um porto que fica na cidade de Manaus, no estado do Amazonas.
A empresa, tal como o Porto de Vila do Conde, realiza o controle de suas operações pelo Sistema
Modall, a qual é possível realizar operações de embarque, descarga e posicionamento de
contêineres, além de faturamentos em geral e outras operações.
Uma solução móvel foi adotada para cadastrar de forma on-line o posicionamento dos
contêineres no pátio, pois essa era feita através de papel e pranchetas e depois passadas ao Sistema
Modall, assim como para realizar a consulta de informações sobre o contêiner no pátio. A solução
utiliza o dispositivo móvel TekLogix 7035, que é aparelho robusto (resistente a umidade, quedas,
poeira), através de uma arquitetura de 3 camadas.
Nessa arquitetura, o software no dispositivo acessa um servidor de WebService, que provê
as regras de negócio e o acesso ao banco de dados do Sistema Modall. Essa arquitetura mostrou-se
de difícil manutenção e desenvolvimento, sendo utilizado apenas por restrições técnicas da
ferramenta de desenvolvimento. O sistema utiliza interface gráfica e as telas são de tamanho
adequado para a entrada de dados (Figura 21).
Figura 21. Telas da solução móvel para a Amazônia Terminais
Fonte: Modallport.
2.4.6 Solução Móvel para o Teconvi
39
O Teconvi é um operador portuário do Porto de Itajaí � Santa Catarina, que utiliza o Sistema
Modall tal como as outras empresas citadas.
Aqui, a solução móvel buscou resolver os mesmos problemas da Amazônia Terminal, que é
o posicionamento e acesso a informações, porém a solução adotada foi outra. O sistema utiliza três
camadas: um cliente magro acessado pelo dispositivo via telnet (como na solução da Vila do
Conde), um servidor de aplicações, contendo as regras de negócio e o banco de dados.
O servidor de aplicação foi usado porque o posicionamento também pode ser controlado por
um sistema de controle gráfico de posicionamento, chamado PortPlanner. Nesse sistema, o usuário
controla graficamente todo o pátio de contêiner do porto, e as regras de negócio estão todas no
servidor de aplicação, que também é usado pela solução móvel.
Essa solução foi escolhida pela facilidade de desenvolvimento e manutenção, além de ser
portável para dispositivos compatíveis com telnet.
2.4.7 Análise das Soluções
No estudo dessas soluções percebeu-se que os dispositivos móveis usados são robustos,
próprios para ambientes sujeitos a umidades e sujeiras, além de resistir a quedas e ao uso constante,
justificando também a escolha do dispositivo para esse trabalho.
Outra característica importante foi a adoção de soluções simples de desenvolvimento, e que
permitam maior manutenibilidade, como no caso das soluções para a Vila do Conde e Teconvi,
sendo a arquitetura de duas camadas a mais adequada. Porém, percebe-se que a adoção de interfaces
gráficas em vez de interfaces modo texto agrega maior usabilidade, além de serem mais fáceis de
desenvolver nas ferramentas atuais. A arquitetura de três camadas mostrou-se inadequada, pois é
complicada de se manter e desenvolver.
A solução móvel, em relação a esses produtos, difere-se no sentido de que ela agrega as
melhores características de cada uma, como a fácil manutenibilidade, a arquitetura de duas
camadas, o acesso on-line e a interface gráfica. A diferença mais importante é que ela possui
funcionalidades diferentes dessas, sendo exclusivas para terminais de vazios, como o PTI, o
posicionamento e o controle de contêineres vazios.
40
2.5 RESUMO DA FUNDAMENTAÇÃO
O objetivo do projeto é construir um sistema de informação integrado ao sistema de controle
de terminais de vazios da Modallport, acessado por um dispositivo móvel, para o uso de um
terminal de contêiner vazio.
Nos últimos anos, as organizações da área portuária, onde se encontram portos, armazéns de
cargas, terminais de contêineres vazios e cheios, em decorrência do aumento das exportações
brasileiras, vêm investindo em sistemas de informação e automação a fim de melhorar seus
processos internos e vencer a concorrência. Nessa área, precisão e agilidade são palavras chaves e
um SI deve ser construído para melhorar questões relativas a esses dois indicadores. Dentro desse
contexto, a Solução Móvel do módulo de controle de terminais de vazios do Sistema Modall será
construída.
Um SI é formado por processos organizacionais, tecnologia, e recursos humanos. Em
relação aos processos organizacionais, é importante conhecer a área de negócio associada ao
sistema, como a caracterização do contêiner, a missão do terminal de vazios e a descrição de seus
processos.
Um contêiner é uma grande caixa metálica usada no transporte seguro de cargas, largamente
adotado no mundo. Um terminal de contêiner vazio faz parte da cadeia logística portuária e
basicamente sua missão é armazenar, consertar e disponibilizar os contêineres vazios aos armadores
para que esse os forneça aos exportadores, objetivando a unitização de cargas.
O sistema a ser construído é caracterizado como um SPT, e grande parte de sua saída é
essencial para a sobrevivência diária da empresa, além de fornecer informações importantes a
outros SI usados de forma estratégica.
Em relação à tecnologia, o sistema deve rodar num dispositivo móvel, sendo que esse deve
ser de fácil manipulação pelo usuário, caber na palma da mão, ter grande capacidade de
processamento, permitir a comunicação com outra rede sem o uso de cabos e possuir uma boa
bateria. Para o uso na área Portuária, devem ser resistentes a umidade, a poeira, a quedas bruscas e
ao uso constante. Dos tipos mais comuns de dispositivos (pockets PC, celular, smartphones,
notebook), os pockets são a categoria que se enquadra melhor nessas características, e após
pesquisas em fabricantes, optou-se pelo Terminal Coletor de dados CPT 9500.
41
Todo dispositivo móvel deve ter um meio de se comunicar com outra rede, para obter seus
serviços. Os métodos mais comuns são Bluetooth, 802.11a, 802.11b, 802.11g e WiMax (802.16). O
método a ser usado nesse trabalho é o 802.11b, suportado pelo dispositivo CPT 9500. A conexão é
transparente ao desenvolvedor, e ele apenas deve configurar o dispositivo corretamente.
A solução móvel empregou a princípio a arquitetura de cliente gordo, com a camada de
apresentação, a camada de negócio e acesso aos dados no dispositivo, e o banco de dados numa
máquina PC, fazendo o papel do servidor. Essa arquitetura permite escalabilidade, além de ser mais
fácil de construir e manter.
Java e .NET são duas poderosas plataformas de desenvolvimento, tanto para dispositivos
móveis, como para aplicações windows e web. A grande vantagem do Java em relação ao .NET é a
portabilidade, pois oferece suporte para inúmeras plataformas e dispositivos, porém, optou-se pelo
.NET pela rapidez no aprendizado e pela agilidade no desenvolvimento.
3 DESENVOLVIMENTO
O objetivo do projeto é construir um sistema de informação, acessado por um dispositivo
móvel, para o uso por um terminal de contêiner vazio.
Assim, esse capítulo mostra o levantamento de requisitos e os aspectos da modelagem do
sistema, como os diagramas de caso de uso, de classe, de implantação e a modelagem do banco de
dados do Sistema Modall. Para isso, estudaram-se os processos do terminal de contêiner vazio, para
entender seu funcionamento e facilitar o levantamento de requisitos, e por conseqüência, a
construção da modelagem. Além disso, descreve também o funcionamento do Sistema Móvel e do
Sistema Modall, mostrando como funciona a integração entre ambos, e descreve como o sistema foi
construído e testado.
3.1 Processos de um Terminal de Contêiner Vazio
Para uma compreensão melhor dos requisitos a serem levantados e para facilitar a
comunicação com os usuários do sistema no levantamento dos requisitos, estudou-se o
funcionamento dos processos de um terminal de vazios.
A Figura 22 mostra um layout conceitual de um terminal, em que cada parte será citada e
explicada nesta seção. O diagrama de atividades da Figura 23 mostra as principais atividades
realizadas no terminal em relação ao fluxo de trabalho do contêiner, que é o escopo desse trabalho.
As informações foram obtidas junto a analistas da Modallport e a profissionais de terminais. Deve-
se ressaltar que não foram encontradas literaturas que falam especificamente sobre esses processos,
então se pesquisou de forma empírica (na prática), através do conhecimento de outras pessoas.
De forma resumida, o contêiner entra no terminal, é vistoriado, se a vistoria não estiver OK
ele vai para a oficina, e se estiver OK é posicionado no pátio. Esse pode ainda sofrer lavação, PTI e
reparo de reefer, no caso de contêiner do tipo reefer. Finalmente, quando o armador solicita, ele é
retirado do pátio, seguindo para seu destino num caminhão. O processo detalhado é descrito nos
tópicos a seguir.
43
3.1.1 Entrada do contêiner
O contêiner entra vindo de duas origens possíveis: reposicionamento entre portos e
devolução de importação, que foram descritos detalhadamente no Capítulo 2. O contêiner chega ao
terminal em cima de um caminhão e, dependendo do terminal, ele pode passar por uma pré-entrada
seguida de entrada ou por uma entrada direta. O motorista leva consigo uma guia com todos os
dados do contêiner, assim o operador de pátio pode fazer a digitação dos dados no sistema. Ao final,
uma guia é impressa e entregue ao motorista, como confirmação da entrada.
Na pré-entrada, o caminhão/contêiner fica numa área de estacionamento próxima das
dependências do terminal. Após a digitação dos dados, o caminhão entra no pátio, o contêiner é
retirado do caminhão, o caminhão segue para o gate, a confirmação de entrada é feita e o caminhão
sai vazio do terminal.
Na entrada direta, o caminhão/contêiner entra, o contêiner é retirado, o caminhão segue para
o gate e a entrada no sistema é processada. Em ambas, é necessária a impressão de uma guia de
entrada, entregue ao caminhoneiro.
3.1.2 Vistoria
Já no pátio, o contêiner passa por uma vistoria para determinar seu estado: se está sujo,
amassado, furado, cortado, ou seja, se contém alguma espécie de avaria. Ela pode ser feita em
qualquer lugar do pátio, mas geralmente é feita quando a empilhadeira está retirando o contêiner do
caminhão.
A vistoria é feita por um vistoriador, que determina se o contêiner está OK ou não OK. Se a
unidade estiver OK, o vistoriador a libera, e a empilhadeira coloca o contêiner numa posição
adequada no pátio. Se não estiver OK, o contêiner vai para uma área separada: a oficina.
O pátio é uma área ampla e aberta, geralmente separadas em quadras, onde as empilhadeiras
colocam as unidades em pilhas de no máximo 7 contêineres.
3.1.3 Oficina
Na oficina, o processo é vertical: ocorre a estimativa seguida da autorização e do reparo. A
estimativa determina detalhadamente as avarias e como elas serão consertadas: seu custo, o tipo e o
local da avaria e os recursos usados em geral. É um planejamento do que vai ser consertado. A
44
estimativa é enviada ao armador, que autoriza ou não o terminal a fazer o reparo, pagando-o pelo
conserto.
O Módulo Terminal possui um controle do status do reparo chamado de �status do
contêiner�, identificado pelas siglas AV (aguardando vistoria), AE (aguardando estimativa), AA
(aguardando autorização), AR (aguardando reparo) e OK. Elas identificam o estado atual do
contêiner no pátio em relação à avaria: se esta aguardando a vistoria, a estimativa, a autorização, o
reparo, ou se está pronto para ser posicionado.
O controle funciona da seguinte forma: conforme ilustra a Figura 23, o contêiner passa da
entrada para a vistoria, para a estimativa (se não OK), para a autorização e para o reparo. Para
passar de uma etapa para outro, o contêiner deve estar com um status definido, do contrário, ele não
pode passar. Por exemplo, para fazer a vistoria, ele deve estar com o status inicial de AV, e no final,
passar para o status de AE, que é o status inicial da próxima atividade, que é a estimativa. A Tabela
5 descreve essa regra para cada atividade.
Tabela 5. Status do contêiner em cada atividade do processo.
Atividades Vistoria Estimativa Autorização Reparo
Status Inicial AV AE AA AR Status Final AE AA AR OK
Um contêiner pode também sofrer lavação, que é feito numa área aberta própria para isso.
Nesse caso, a vistoria determina-o como não OK, passa pela estimativa e autorização, e então
lavagem e posicionamento. No sistema, o controle é feito apenas substituindo o status de AR por
AL (aguardando lavagem), com o processo funcionando da mesma forma.
3.1.4 PTI
Todo contêiner reefer passa pelo PTI, que é uma inspeção feita para determinar se seu motor
está funcionando adequadamente, com base na especificação desse contêiner. Como visto no
Capítulo 2, o contêiner reefer é uma unidade refrigerada, com um motor que mantém cargas
perecíveis na temperatura, ventilação e umidade adequadas.
Com o contêiner no pátio, o vistoriador liga seu motor e o deixa ligado durante 12 ou 24
horas, e ao final verifica se eles estão refrigerando na temperatura esperada, anotando os resultados
numa prancheta. Se o teste do PTI não estiver OK, o terminal ou faz seu conserto, enviando-o para
a oficina, ou manda-o para uma empresa especializada.
45
Ao final, com o PTI OK, ele é posicionado no pátio. O PTI e a vistoria podem ser feitos em
qualquer ordem de prioridade, mas não ao mesmo tempo. As vistorias são realizadas em todos os
contêineres e o PTI apenas em reefer. O Módulo Terminal controla o status do PTI através do
�Status Reefer�, indicando se estão OK ou não OK.
3.1.5 Saída
Dependendo do terminal, a saída do contêiner pode ser precedida ou não por uma pré-saída.
Na pré-saída, o cadastro da saída do contêiner é feito antes do caminhão ir buscá-lo. Assim, a saída
é feita diretamente e sem demora, pois apenas são informados dados do caminhão e da data/hora.
Na saída normal, o caminhão entra no pátio, o contêiner é colocado nele, os dados são colocados no
sistema e o caminhão com o contêiner sai do terminal. Em ambos os casos, uma guia impressa com
os dados do contêiner é emitida e entregue ao caminhoneiro.
Por fim, o destino do contêiner pode ser o reposicionamento entre portos ou a unitização
num exportador, para subseqüente embarque no navio, para a exportação.
Toda a entrada/saída de contêiner é controlada pelas pessoas do �Gate�, que é uma área
próxima ao portão de entrada/saída, onde é verificado se o contêiner pode entrar ou sair e onde são
impressos as guias.
Na Figura 22 é mostrado um layout conceitual de um terminal de contêiner vazio,
mostrando a localização de cada área dos processos descrito acima. Um terminal é bem maior do
que isso, mas contêm basicamente essas áreas.
46
O ficina Lavação
Quadra 0 1Quadra 0 3Quadra 05
Quadra 04
Portão de Entrada Portão de SaídaGate
Administração
Quadra 6Quadra 02 - Area
para Reefer e PTI
Reservado para Contêineres
Reservado para Contêineres
Entrada de contêineres
Saída de contêineres
E stacionameno para pré-entrada
Pátio Pátio
Figura 22. Layout conceitual de um terminal de contêiner vazio.
A análise do processo mostrou que algumas rotinas podem ser colocadas no dispositivo
móvel, como a entrada (antecedida pela pré-entrada), a vistoria, a estimativa, o reparo, o PTI, a
saída (antecedida pela pré-saída) e o posicionamento. Os processos de entrada ou saída não
precisam constar no sistema porque eles são feitas num local próprio para isso, no gate, onde uma
guia em papel precisa ser impressa e entregue ao motorista. Assim, verificou-se junto aos
especialistas da área quais os processos devem ser construídos para o sistema móvel e então,
relacionados no levantamento de requisitos.
A seguir, na figura 23, é apresentado o diagrama de atividades que resume todo o processo
explicado anteriormente, envolvendo as principais atividades realizadas no terminal em relação ao
fluxo de trabalho do contêiner.
47
ad Diagrama de Ativ idades
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Entrada de
Contêiner
PTI
Posiciona
Pré-Entrada de
Contêiner
Pré-Saída
Saída
Estimativ a
Autorização
Reparo
Reposicionamento entre
portos
Importação e
Desov a no Cliente
Vistoria
A origem pode ser por ambas
Unitização no cliente e
exportação
Reposicionamento entre
portos
O destino do contêiner pode
ser ambos
[Conteiner Reefer]
[Vistorianão OK]
[VistoriaOK]
[PTI não OK]
[PTI OK]
Figura 23: Diagrama de atividades do processo de um terminal de contêiner vazio.
48
3.2 Levantamento de requisitos
No levantamento de requisitos é onde são verificadas as necessidades do cliente para o qual
o sistema vai ser construído. Para Bezerra (2002), nessa etapa, os desenvolvedores juntamente com
os clientes, tentam levantar e definir as necessidades dos futuros usuários do sistema a ser
desenvolvido. Essas necessidades são chamadas de requisitos. Os requisitos da solução móvel
foram levantados junto a profissionais de terminais e analistas da Modallport.
A seguir serão apresentados os requisitos funcionais, não funcionais e regra de negócio do
sistema construído.
3.2.1 Requisitos funcionais
Os requisitos funcionais do sistema são:
RF1: O sistema deverá permitir autenticação de usuário;
RF2: O sistema deve permitir fazer vistoria de contêiner;
RF3: O sistema deve permitir fazer o cadastro e alteração de estimativas de contêiner;
RF4: O sistema deve permitir fazer a consulta de uma unidade informada, juntamente com a
relação de todos os seus movimentos (tracking do Terminal);
RF5: O sistema deve permitir a manutenção do cadastro de contêiner;
RF6: O sistema deve permitir o cadastro/alteração/exclusão de PTI; e
RF7: O sistema deve permitir fazer o posicionamento ou reposicionamento de contêiner.
3.2.2 Requisitos não funcionais
Os requisitos não funcionais do sistema são:
RNF1: O usuário deve informar apenas o número de série e dígito do identificador do
contêiner. Se houver mais de um número, deve mostrar um menu para escolha;
RNF2: O sistema deve rodar no dispositivo �Coletor de dados CPT 9500�, acessando o
banco de dados Oracle do Sistema Modall e gravando nas tabelas referentes aos processos
do Módulo Terminal;
49
RNF3: Nos campos do tipo busca (que são referência para outros cadastros), o sistema deve
permitir buscar o código pelo nome. Não é necessário ter seu cadastro no sistema, pois ele é
feito no Sistema Modall;
RNF5: O sistema deve ser de fácil utilização, usando termos comuns do Terminal;
RNF6: O sistema deve ser implementado em Visual Studio 2005, usando a tecnologia .NET;
RNF7: As mensagens de aviso ou alerta devem ser claras, apresentando cores diferenciadas;
RNF8: Deve ser otimizado para uso pelo apontador de tela e teclado;
RNF9: Deve ser escalonável para novas funções;
RNF10: Deve gerar log de todas as operações realizadas como exclusão, alteração e inclusão
de registros, gravando o contêiner, o usuário, a máquina e a operação feita; e
RNF11: Deve ser de fácil manutenção.
3.2.3 Regras de negócio
As regras de negócio do sistema são:
RN 1 - Login: O acesso ao sistema deve ser feito por usuário/senha, sendo esse já
cadastrado no Sistema Modall, através do Módulo SisAcess.
RN 2 - Vistoria: as regras a seguir são relativas ao processo de vistoria.
RN 2.1: Para fazer a vistoria, o contêiner deve estar no pátio e ter o status AV
(aguardando vistoria) no cadastro de contêiner;
RN 2.2: Deve trazer o status de entrada como DM, e também deve trazer
automaticamente os valores dos campos do cadastro de contêiner: instrução, tara, MGW,
bom para café (sim/não), bom para fumo (sim/não), bom para alimento (sim/não), carga
geral (sim/não);
RN 2.3: Os campos que precisam ser digitados são: contêiner, status (DM/OK), tara,
MGW, instrução , observação, bom para café (sim/não), bom para fumo (sim/não), bom
para alimento (sim/não), carga geral (sim/não), checklist (sim/não) para cheiro/odor,
adesivos, marca de tambores, marca de óleo, ferrugem interna, todos trazendo não como
padrão;
50
RN 2.4: Deve gravar a data/hora atual da vistoria automaticamente; e
RN 2.5: Se o status da vistoria for DM deve alterar o status do contêiner para AE. Se o
status da vistoria for OK, deve alterar o status do contêiner como OK.
RN3 - Cadastro de estimativa: as regras a seguir são relativas à rotina de cadastro de
estimativa.
RN 3.1: O contêiner deve estar no pátio e com o status como AE (aguardando
estimativa);
RN 3.2: Se houver uma estimativa já cadastrada para o contêiner no pátio, o sistema
permite alterá-la. Se não houver, o sistema permite incluí-la;
RN 3.3: Deve permitir cadastrar vários itens de estimativas;
RN 3.4: Os campos a serem cadastrados são: contêiner, avaria (busca), local (busca),
tamanho horizontal, tamanho vertical, tipo (estrutura, reefer, outros, wear/tear, lavação),
serviço (busca), complemento, quantidade e quantidade adicional. Obrigar todos os
campos; e
RN 3.5: Deve gravar a data/hora atual da estimativa automaticamente.
RN4 - Consulta de contêiner: as regras a seguir são relativas à rotina de consulta de
contêineres.
RN 4.1: Deve verificar se o contêiner existe no movimento, se existir, busca o último
movimento e mostra na tela;
RN 4.2: Os campos que devem aparecer são: contêiner, código ISO, navio/viagem, no
pátio (sim/não), tara, MGW, status atual, status PTI, status do maquinário, data de
entrada, número do booking, posição no pátio, todos os checklist da vistoria, instrução,
designado, bom para café (sim/não), bom para fumo (sim/não), bom para alimento
(sim/não), carga geral (sim/não), situação, armador, dias no pátio; e
RN3: No tracking, deve mostrar todos os movimentos realizados pelo contêiner
(entrada, saída, PTI, vistoria, estimativa, reparo e lavagem) e trazer os seguintes campos:
tipo de movimento, adicional (sim/não), data, recebimento, consignatário, armador,
booking, estimativa, oficina, status guia, vistoriador e autorização.
51
RN5: Manutenção do cadastro de contêiner: as regras a seguir são relativas à rotina de
cadastro de contêiner.
RN 5.1: Nesse cadastro, devem informados os campos: contêiner, código ISO (busca),
armador (busca), situação (busca), tara, MGW, material (ST/AL/FB/SI), bom para café
(sim/não), bom para fumo (sim/não), carga geral (sim/não), bom para alimento
(sim/não), designação e instrução;
RN 5.2: Campos obrigatórios: código ISO, armador e contêiner; e
RN 5.3: O sistema deve permitir apenas a manutenção de uma unidade, e não o seu
cadastro.
RN6 - Cadastro de PTI: as regras a seguir são relativas à rotina de cadastro de PTI.
RN 6.1: O contêiner deve estar no pátio e seu tipo deve ser reefer;
RN 6.2: Deve permitir cadastrar vários PTIs por contêiner, podendo também alterar os
existentes e excluir;
RN 6.3: Os campos a serem cadastrados são: contêiner, status (DM/OK) e tipo (mini
/normal);
RN 6.4: Os campos obrigatórios são status (DM/OK) e tipo;
RN 6.5: Deve gravar a data/hora atual do PTI automaticamente;
RN 6.6: Ao registrar o primeiro PTI, deve gravar a data e o status na tabela de status
maquinário (reefer); e
RN 6.7: Deve gravar o PTI automaticamente como cobrado, e calcular seu valor
conforme regra já existente no TM.
RN7 � Cadastro de posicionamento: as regras a seguir são relativas ao posicionamento/
reposicionamento de contêineres.
RN 7.1: O contêiner deve estar no pátio; e
RN 7.1: Deve obrigar os campos contêiner, local (busca) e quadra.
3.2.4 Restrições
52
As restrições do sistema são:
R1 - O Sistema Móvel não permitirá a realização de cadastros, como de códigos ISO, de
locais, de armadores, dentre outros.
R2 - Além disso, a rotina de Estimativa não fará o calculo de valor de faturamento,
incluindo custos de material e mão de obra, porque são calculo complexos demais e o tempo de
desenvolvimento se alongaria além desse projeto. Porém, será implementado futuramente.
3.3 Modelagem do sistema
Na modelagem do sistema, foram definidos os diagramas de casos de uso, os diagramas de
implantação, os diagramas de classe de negócio/domínio, os diagramas de classe de projeto e de
seqüência e gerado o diagrama de entidade-relacionamento do Sistema Modall referentes às tabelas
usadas no sistema móvel.
3.3.1 Diagramas de casos de uso
Os diagramas de caso de uso detalham os requisitos funcionais e regras de negócio,
mostrando qual a interação que o usuário terá com o sistema. De acordo com Bezerra (2002), os
diagramas de casos de uso correspondem a uma visão externa do sistema, representando
graficamente os atores, os casos de uso e o relacionamento entre eles.
Os diagramas de caso uso deste projeto estão divididos em dois pacotes: Controle de Acesso
e Controle de Operações, representados respectivamente pelas figuras 24 e 25. O sistema possui um
único ator, o Operador de Pátio, que representa o operador de pátio de um terminal.
O Controle de Acesso descreve a forma como o login no sistema é feito, e está representado
pelo caso de uso �UC 01.01 � Efetua Login� (Apêndice A.1.1) a qual é ilustrado na Figura 24, que
por sua vez está relacionado com o RF1 e RN 1.
O Controle de Operações representa o controle dos processos do terminal e estão
representado pelos casos de uso �UC 02.01� até �UC 02.07� (Apêndice A.1.2), relacionado com os
requisitos RF2 ao RF7, conforme detalhado a seguir e ilustrado na Figura 25.
53
O caso de uso �UC 02.01 - Vistoria de Contêiner�, está relacionado com o RF2 e RN2, e
representa a vistoria do contêiner, descrevendo como usuário fará uma vistoria no pátio com o uso
do sistema (Apêndice A.1.2.1).
O caso de uso �UC 02.02 - Cadastro/Alteração de Estimativa�, está relacionado com o RF3
e RN3, e representa o cadastro de estimativa do contêiner, descrevendo como o usuário fará uma
estimativa com o uso do sistema (Apêndice A.1.2.2).
O caso de uso �UC 02.03 - Consulta de contêiner�, está relacionado com a RF4 e RN4, e
representa a consulta de uma unidade, mostrando como o operador de pátio deve fazer uma consulta
de um contêiner em particular (Apêndice A.1.2.3).
O caso de uso �UC 02.04 � Manutenção do cadastro de contêiner�, está relacionado com o
RF5 e RN5, e representa o cadastro ou a alteração de uma unidade, mostrando como o operador de
pátio deve fazer para inserir ou alterar os dados de um de um contêiner em particular (Apêndice
A.1.2.4).
O caso de uso �UC 02.05 - Cadastro de PTI�, está relacionado com o RF6 e RN6, e
representa o cadastro ou a alteração de PTIs feito em contêineres reefer, mostrando como o
operador de pátio deve fazer para inserir ou cadastrar os dados dos PTIs (Apêndice A.1.2.5).
O �UC 02.06 - Cadastro de posicionamento/reposicionamento�, está relacionado com o
RF7 e RN7, e representa como o operador de pátio posiciona ou reposiciona um contêiner no pátio
(Apêndice A.1.2.6).
O �UC 02.07 - �UC 02.07 Consulta Sigla de Contêiner�, está relacionado com o RNF1, e
descreve a interação com a tela de escolha de identificador de contêiner, quando é informado um
número de série e dígito nos campos de digitação de contêiner (Apêndice A.1.2.7).
54
ud Controle de acesso• • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • •
Controle de Acesso
Operador de pátio
UC 01.01 - Efetua
Login
Figura 24: Diagrama de Caso de Uso Caso para o Controle de Acesso.
ud Operações
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Controle de Operações
Operador de pátio
UC 02.01 - Vistoria
de Contêiner
UC 02.04 -
Cadastro de
Contêiner
UC 02.05 -
Cadastro de PTI
UC 02.03 - Consulta
de Contêiner
UC 02.02 -
Cadastro/Alteração
de Estimativ a
UC 02.07 -
Consulta Sigla
Contêiner
Operador de pátio
UC02.06 - Cadastro de
Posicionamento/
Reposicionamento«extend»
«extend»«extend»
«extend»«extend»
«extend»
Figura 25. Diagrama de Caso de Uso Caso das Operações.
3.3.2 Diagrama de classe de negócio
De acordo com Bezerra (2002), os diagrama de classes permitem modelar o sistema desde o
nível de análise, passando pela especificação e pela implementação, descrevendo como o sistema
está estruturado internamente para que as funcionalidades visíveis externamente sejam produzidas.
O diagrama de classes é a base para a construção dos diagramas de comunicação, seqüência e
estados.
55
Eles representam os aspectos estáticos do sistema, ao passo que os aspectos dinâmicos, que
trata a interação entre os métodos da classe, são representados nos diagrama de seqüência.
Basicamente, eles são formados por classes, as quais são representadas por uma caixa contendo o
seu nome, seus métodos e propriedades e pelo relacionamento entre elas, representada por uma
linha que as une.
Ainda segundo Bezerra (2002), o diagrama de classe de negócio ou domínio objetiva
descrever o problema representado pelo sistema, não levando em consideração as características da
solução de software a ser utilizada, como por exemplo, o banco de dados escolhido.
Na Figura 26, o diagrama de classe de domínio do sistema é apresentado. A seguir, uma
breve descrição de cada classe é dada:
Contêiner: dados do cadastro do contêiner;
Movimentação_Conteiner: dados da entrada ou saída do contêiner no Módulo Terminal,
incluído o posicionamento;
Vistoria_Conteiner: responsável pela rotina de vistoria. Deve ter necessariamente um
movimento de entrada, embora um movimento não precise realizar vistoria;
PTI e Item PTI: responsável pela rotina de cadastrar PTI. Ele deve ter um movimento de
entrada, o PTI pode ter vários itens e o item necessariamente faz parte do PTI; e
Estimativa e Item_Estimativa: responsável pela rotina de cadastrar estimativas. Ele deve
ter necessariamente uma vistoria, a estimativa pode ter vários itens e o item
necessariamente faz parte da estimativa.
Operador: Mostrado duas vezes no diagrama por motivo de layout, representa o
operador de pátio (usuário) e as operações que ele pode fazer no sistema.
Convêm lembrar que essas classes não têm nenhuma ligação com a forma de divisão do
código fonte, que são tratados nos diagramas de classe de projeto. Apresentam assim, uma visão
geral e conceitual do que o sistema pode fazer.
56
cd Diagrama de Classe
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Conteiner
- Identificador_conteiner: char- Codigo_ISO: char- Status_oficina: char- Tara: float- MGW: float- Net: float- armador: char- Capacidade_Cubica: float- Situacao: char- Designado: char- Instrucao: int- obs_designado: char- bom_para_cafe: char- bom_para_alimento: char- bom_para_fumo: char- material: char
+ MostrarConteiner() : void+ GravarDados() : void+ Inseri rConteiner() : void+ AlterarConteiner() : void+ GerarLog() : void
Vistoria_Conteiner
- Identificador_conteiner: char- Data_hora : dateTime- adesivos: char- cheiro_odor: char- marca_oleo: char- marca_tambores: char- ferrugem_interna: char- MGW: float- tara: float- instrucao: char- bom_para_cafe: char- bom_para_fumo: char- bom_para_alimento: char
+ GravarDados() : void+ InserirVistoria() : void+ GerarLog() : void
PTI
- Identificador_conteiner: char
+ Gravar_Dados() : void+ Alterar_PTI() : void+ Inseri r_PTI() : void+ MostrarPTI() : void+ GerarLog() : void
Item_Estimativ a
- Local_Avaria: char- T ipo_Avaria: char- Avaria: char- Servico: char- dimensao_horinzontal: int- dimensao_vertical : int- qtde: float- qtde_Adicional: float- descricao: char
+ InserirItem() : void+ AlterarItem() : void+ ExcluirItem() : void+ GravarItem() : void+ MostrarItens() : void
Mov imentacao_Conteiner
- Identificador_Conteiner: Char- Data_Hora_Movimento: DateTime- No_Patio: boolean- Tipo_Movto: char- Local : char- Agencia: int- Quadra: char- Armador: int
+ VerificaSePatio(IdConteiner)() : boolean+ InserirPosicionamento() : void+ AlterarPosicionamento() : void+ GravarDadosPosicionamento() : void+ PegarUltimoMovto() : void+ ConsultarConteiner() : void
Item_PTI
- data_hora: dataTime- tipo: char- status_mini_pti: char
+ InserirItem() : void+ AlterarItem() : void+ ExcluirItem() : void+ GravarItem() : void+ MostrarItem() : void
Estimativ a_Conteiner
- Nro_estimativa: char- Identificador_Conteiner: char- Data_hora: dateTime
+ GravarDados() : void+ AlterarEstimativa() : void+ GerarLog() : void
Operador
- usuario: char- senha: char
+ LogarSistema() : void
Operador
- usuario: char- senha: char
+ LogarSistema() : void
0
Controla
*
1
Controla
*
1
Visualiza
*
1
Controla
*
1..*
1
1..*1
1Pode ter
0..1
1
Pode ter
0..*
1
Pode ter
0..1
1Pode ter
0..*
1
Controla
*
Figura 26. Digrama de Classe de Domínio do Sistema.
3.3.3 Diagrama de classe de projeto
Nesse trabalho, o diagrama de classe de projeto ou de especificação mostra a forma como as
classes do sistema foram divididas dentro do código fonte, detalhando as camadas que foram
utilizadas. Foi criado um diagrama de classe para cada caso de uso, com um diagrama de seqüência
relacionado. Esses diagramas representam os principais métodos adotados e foram usados como
base para a construção do código.
Na figura 27, é mostrado o diagrama de classe referente ao caso de uso �UC 02.04 �
Manutenção do cadastro de contêiner�. A classe de negócio/acesso controla todas as regras de
57
negócio, ficando também responsável pelo acesso ao banco de dados através do OracleConnection
(operações como consulta e gravação de dados). As classes de apresentação são responsáveis por
mostrar os dados na tela para o usuário. Detalhes dessa forma de implementação são mostradas em
�3.5 Implementação�.
cd CadConteiner
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Negócio/Acesso
Apresentação
TCadConteiner
- OracleConnection: OracleConnection- dsCadConteiner: DataSet
+ GravarDados() : bool+ getConteiner(char) : operacao+ Create() : void
TEL06A: Manutenção
+ GravarDados() : void+ LimpaDados() : void+ BuscaConteiner() : void+ showMessage() : void+ Show() : void+ ShowDados() : void
TEL09:frmDialog
- fSelection: DataRow- idcon: char
+ ShowDlg(DataTable) : conteiner+ OK() : void
Figura 27. Diagrama de Classe de Projeto da Manutenção do cadastro de contêiner
3.3.4 Diagrama de seqüência
Os diagramas de seqüência mostram a forma como as classes interagem entre si,
evidenciando seus aspectos dinâmicos, ao contrário da classe de projeto, que tratam de aspectos
estáticos (BEZERRA, 2003).
Na figura 28, é mostrado o diagrama de seqüência relacionado ao diagrama de classe da
figura 27, que trata o caso de uso �UC 02.04 � Manutenção do cadastro de contêiner�.
58
sd CadConteiner• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Operador
«form»
TEL06A:Manutenção
TCadConteiner
«form»
TEL09:frmDialog
Show()
Create()
BuscaConteiner()
{obtem DsCadConteiner }
dados= getConteiner(conteiner) [i f qtdeCntr >1]: conteiner=ShowDlg(DataTable)
{avisa e permite nova busca }
[if qtde = 0]: showMessage(mens)
[i f qtde = 1]: ShowDados()
{Digita dados e grava }
GravarDados()
bool= GravarDados()
{Deve permitir nova manutenção }
[i f GravouDados]: LimpaDados()
Figura 28. Diagrama de Classe de Seqüência da Manutenção do cadastro de contêiner
3.3.5 Diagrama Entidade-Relacionamento
O diagrama entidade-relacionamento do sistema, mostrado na Figura 29, foi obtido através
de engenharia-reversa do Sistema Modall, usando o aplicativo Enterprise Architect. Foram retirados
todos os campos não necessários ao Sistema Móvel, deixando apenas os campos utilizados.
59
cd Data Model
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
TC_CONT
column*PK IDCONT: CHAR(13) FK IDISO: CHAR(4) FK IDCLIENTE_ARMADOR: NUMBER(7) FK IDSITUACAO: CHAR(3) TARA: NUMBER(5) MGW: NUMBER(5) CAFE: CHAR(1) FUMO: CHAR(1) ALIMENTO: CHAR(1) DESIGNADO: CHAR(1) DESIGNACAO: CHAR(40) STATUS: VARCHAR2(2) INSTRUCAO: VARCHAR2(30) CAPACIDADE_CUBICA: NUMBER(9,3) NET_HEIGHT: NUMBER(5) MATERIAL: VARCHAR2(2)
TM_AVARIAS
column*PK IDAVARIA: VARCHAR2(3)* DS_AVARIA: VARCHAR2(30)* DS_AVARIA2: VARCHAR2(30)
TM_ESTIMATIVAS
column*PK IDESTIM: NUMBER(10)*FK IDMOVCONT: NUMBER(10) FK IDREPARO: VARCHAR2(3) FK IDSERVICO_OF: VARCHAR2(3) DH_VISTORIA: DATE DH_ESTIMATIVA: DATE NRO_ESTIMATIVA: VARCHAR2(20) CHECK_LIST_CHEIRO: VARCHAR2(1) CHECK_LIST_ADESIVOS: VARCHAR2(1) CHECK_LIST_MARCA_TAMBORES: VARCHAR2(1) CHECK_LIST_MANCHA_OLEO: VARCHAR2(1) CHECK_LIST_FERRUGEM_INTERNA: VARCHAR2(1)
TM_ESTRUTURAS
column*PK IDESTRUTURA: VARCHAR2(3)* DS_ESTRU: VARCHAR2(30)
TM_LOCAIS
column*PK IDLOCAL: varchar(255) DS_LOCAL: varchar(255)*pfK IDAGENCIA: varchar(255)
TM_MOVCONT
column*PK IDMOVCONT: NUMBER(10)* TIPO_MOVTO: VARCHAR2(1)* DH_MOVTO: DATE FK IDLOCAL: VARCHAR2(4)*FK IDCONT: CHAR(13)*FK IDAGENCIA: NUMBER(2)*FK IDCONT: CHAR(13) QUADRA: VARCHAR2(10)*FK IDCLIENTE_ARM_MOV: NUMBER(7) NO_PATIO: VARCHAR2(1)
TM_MOVESTIM
column*PK IDMOVESTIM: NUMBER(10)*FK IDESTIM: NUMBER(10)*FK IDAVARIA: VARCHAR2(3)*FK IDESTRUTURA: VARCHAR2(3)* DS_SERVICO: VARCHAR2(100) QTDE_SERVICO: NUMBER(4) QTDE_ADICIONAL: NUMBER(3) DIMENSAO_GERAL: VARCHAR2(15) DIM_HORIZ: NUMBER(8,2) DIM_VERT: NUMBER(8,2) TIPO_AVARIA: VARCHAR2(1) FK IDREPARO: VARCHAR2(3) FK IDSERVICO_OF: VARCHAR2(3)
TM_PTI
column*PK IDPTI: NUMBER(10)*FK IDMOVCONT: NUMBER(10) FK IDCONT: CHAR(13) DH_PTI: DATE STATUS_PTI: VARCHAR2(2) MINI_PTI: VARCHAR2(1)
TM_REPAROS
column*PK IDREPARO: VARCHAR2(3) DS_NOME: varchar(255)
TM_SERVICOS_OF
column*PK IDSERVICO_OF: VARCHAR2(3)*pfK IDREPARO: VARCHAR2(3)* DS_OF: varchar(255) DS_OF2: varchar(255)
TM_SITUACAO
column*PK IDSITUACAO: CHAR(3) DS_SITUACAO: VARCHAR2(30)
TC_TIPOS
column*PK IDISO: CHAR(4) TIPO_CNTR: CHAR(2) TAM_CNTR: NUMBER(2) ESPECIFICACAO: VARCHAR2(20)
TC_CLIENTES
column*PK IDCLIENTE: NUMBER(7)* NOME_CLI: VARCHAR2(100)
DE_AGENCIAS
column*PK IDAGENCIA: NUMBER(2)* DS_AGE: VARCHAR2(55)
PO_LOG_PORTUARIO
column*PK IDLOG: NUMBER(10)* IDAGENCIA: NUMBER(2) DH_CADASTRO: DATE SIGLA_CONT: CHAR(13) DS_OPERACAO: VARCHAR2(250)* USERNAME: VARCHAR2(50) TERMINAL: VARCHAR2(250)
TC_USERS
column*PK USERNAME: VARCHAR2(50)* PASSWORD: VARCHAR2(10) NOME: VARCHAR2(250)*PK ATIVO: CHAR(1)
0..*
(IDAVARIA = IDAVARIA)
1
0..*
(IDSITUACAO = IDSITUACAO)
1
(IDSO = IDISO)
0..*
(IDMOVCONT = IDMOVCONT)
1
0..*
(IDREPARO = IDSERVICO_OFIDSERVICO_OF = IDREPARO)
1
0..*(IDCONT = IDCONT)
1
0..*
IDCLIENTE_ARMADOR = IDCLIENTE
1
0..*
(IDCLIENTE_ARM_MOV = IDCLIENTE)
1
0..*
(IDREPARO = IDREPARO)
1
0..*
(IDESTIM = IDESTIM)
1
0..*
(IDESTRUTURA = IDESTRUTURA)1
0..*
(IDREPARO = IDSERVICO_OFIDSERVICO_OF = IDREPARO)
1
0..*
(IDAGENCIA = IDAGENCIA)
1
0..*
(IDCONT = IDCONT)
1
0..*
(IDMOVCONT = IDMOVCONT)
1
0..*
(IDAGENCIA = IDAGENCIAIDLOCAL = IDLOCAL)
1
(IDAGENCIA = IDAGENCIA)
(USERNAME = USERNAME)
Figura 29. Diagrama entidade-relacionamento do Sistema Móvel.
3.3.6 Diagrama de implantação
Os diagramas de implantação, conforme Bezerra (2002), representam a arquitetura física do
sistema, apresentando um mapeamento entre os componentes de software e hardware usado pelo
sistema.
60
Figura 30. Diagrama de Implantação do Sistema.
Na Figura 30 é apresentada a relação entre os componentes de hardware e de software da
solução móvel através do diagrama de implantação. Relaciona assim, a arquitetura da solução
móvel, o dispositivo móvel, o .NET CF e o banco de dados da aplicação, que são as tecnologias
usadas no desenvolvimento desse projeto.
O sistema móvel executa dentro do .NET CF, dependendo desse para conversão do código
MSIL para o código nativo do processador (explicado no seção 2.4.4). O software da solução móvel
e a máquina virtual do .NET CF devem ser instalados no dispositivo móvel. Numa máquina PC
fica o SGBD do Oracle e o banco de dados do Sistema Modall.
Assim, o sistema móvel grava e seleciona registros diretamente das tabelas do Sistema
Modall, que é controlado pelo SGBD Oracle. O cliente e o servidor, que são os componentes físicos
do sistema, trocam informações entre si referentes às operações que estão sendo realizadas pelo
usuário através da rede sem fio IEE 802.11b.
Resumindo, a aplicação, executando no dispositivo, rodando sob o .NET CF, troca dados via
wireless com o SGBD do Oracle/banco de dados Modall, que fica numa máquina PC.
3.4 Funcionamento do Sistema
Essa seção objetiva mostrar como é feita a operação da solução móvel pelo usuário e quais
os aspectos mais importantes do Sistema Modall, do Módulo Terminal e do Módulo SisAcess
relacionados a esse projeto.
61
3.4.1 Sistema Modall e Módulo Terminal
O Sistema Modall é formado por vários módulos, cada um específico para uma determinada
área do comércio exterior. Por exemplo, o Módulo Portuário é responsável pelo controle das
operações de um porto, ao passo que o Módulo Terminal é responsável pelas operações de um
terminal de contêiner vazio. Ao todo, o sistema é formado por cerca de 13 módulos, tais como o
Módulo Armazém, Módulo Portuário, Módulo Importação, Módulo Financeiro, dentre outros.
Os módulos do sistema compartilham o mesmo banco de dados, podendo funcionar
integrados, ou de forma isolada. O banco de dados usado é o Oracle 8i. Não há portabilidade para
outros bancos de dados, o sistema funciona exclusivamente nele.
O Sistema Modall roda apenas no Windows 2000 ou superior, e se trata de uma aplicação
desktop. Pode ser integrado a módulos Web em plataforma Linux ou Windows, e com
implementação específica pode ser integrado a qualquer outro sistema.
Todo ambiente de trabalho é acessado por agência ou área de trabalho, que define em qual
filial da organização o usuário trabalha. Assim, para cada usuário é preciso definir qual a agência
ele terá permissão para usar, o que pode ser feito através do Módulo Financeiro.
O Módulo Terminal, na qual se baseia o Sistema Móvel, é formado pelas seguintes partes:
Cadastro: Formado pelo cadastro de clientes, contêineres, navio/viagem, locais, tipos de
contêineres, código ISO, serviços, avarias, locais de avarias, dentre outros. Para o Sistema
Móvel, é o local onde os campos do tipo �busca� são inseridos no banco de dados;
Movimentação: Permite o cadastro das movimentações de contêineres como entrada e saída,
a movimentação da oficina, como vistoria, autorização, reparo e estimativa, o PTI, além do
faturamento de serviços em geral;
Relatórios: Permitem gerar relatórios impressos ou em tela, como relatórios de patiamento,
de oficina, de faturamento, gerenciais, gráficos, dentre outros; e
Utilitários: Permite consultar contêiner, consultar logs gerados, trocar senha de usuário,
dentre outros;
62
A Figura 31 mostra o Menu de Acesso do Módulo Terminal, com suas partes integrantes em
destaque. O acesso as rotinas pode ser feito tanto pela árvore (treeview) como pelos menus na parte
superior.
Figura 31. Menu de Acesso do Módulo Terminal
Fonte: Modallport Sistemas.
3.4.2 Módulo SisAcess
O Módulo SisAcess é responsável pelo cadastro dos usuários e pelas restrições de uso das
funcionalidades do sistema. Através dele é possível:
Cadastrar o usuário para acesso ao sistema;
Cadastrar grupos de usuários, com permissões em comum;
Cadastrar um usuário como �super�, com pleno acesso a todas as rotinas; e
Cadastrar permissões por usuário e por rotina.
Os usuários do sistema móvel devem ser cadastrados por um usuário �super� do SisAcess.
O cadastro de permissões por usuário/rotina só é possível através de uma alteração no SisAcess para
63
ficar compatível com a solução móvel, o que não será feito nesse trabalho. Para o futuro é uma
construção quase certa, pois um usuário que faz uma vistoria não necessariamente faz um PTI, e o
sistema deverá controlar a permissão/restrição dessas rotinas para usuários distintos.
3.4.3 Operação do Sistema Móvel
O Sistema Móvel funciona como um Módulo do Sistema Modall, e acessa diretamente o seu
banco de dados, de forma on-line. O usuário deve ser necessariamente cadastrado no Módulo
SisAcess, que automaticamente cria uma conta para o acesso ao sistema.
O usuário acessa o sistema por um arquivo executável rodando sob o .NET CF, o qual por
sua vez roda sob o sistema operacional do dispositivo móvel (Windows CE 5.0). Ao ser executado,
a primeira tela mostrada é a de login, mostrada na Figura 32, (conforme caso de uso UC 01.01 �
Efetua Login, no Anexo A.1.1). Com o login efetuado, a tela do Menu de Acesso é aberta (Figura
33), com botões para acessar as rotinas, numeradas de 1 a 6, que podem ser acessadas tanto pelo
número quanto pelo mouse.
Figura 32. Tela 01 � Login. Figura 33. Tela 02 � Menu de Acesso.
Cada opção do Menu de Acesso na Figura 33 chama uma funcionalidade do sistema, através
de uma tela, a qual é o inicio de um caso de uso, conforme descrito a seguir:
1 � Vistoria: Chama a tela de vistorias, conforme descrito no caso de uso �UC 02.01 -
Vistoria de Contêiner� (Apêndice A.1.2.1);
64
2 � Estimativa: Chama a tela de cadastro/alteração de estimativas, conforme descrito no caso
de uso �UC 02.02 - Cadastro/Alteração de Estimativa� (Apêndice A.1.2.2);
3 � Consulta Contêiner: Chama a tela de consulta de informações do contêiner, conforme
caso de uso �UC 02.03 - Consulta de contêiner" (Apêndice A.1.2.3);
4 � Cadastra Contêiner: Chama a tela de manutenção do cadastro do contêiner, conforme
caso de uso �UC 02.04 � Manutenção do cadastro de contêiner� (Apêndice A.1.2.4);
5 � PTI: Chama a tela das alteração/exclusão/inclusão de PTIs, conforme caso de uso �UC
02.05 - Cadastro de PTI� (Apêndice A.1.2.5); e
6 � Posicionamento: Chama a tela de posicionar/reposicionar contêiner, conforme caso de
uso �UC 02.06 - Cadastro de posicionamento/reposicionamento� (Apêndice A.1.2.6).
Todas as telas do sistema, obtidas com o sistema em funcionamento estão no Apêndice A. 2.
Usabilidade
Em toda tela de entrada de dados, ao se digitar o identificador do contêiner, foi criado uma
forma de facilitar a busca dos dados e a uma nova consulta, sem ter que sair da tela e entrar
novamente. Assim, o usuário conta com um botão ao lado do identificador: se o mesmo estiver
marcado como "..." a validação do contêiner está ativa e pode ser feita (por exemplo, na vistoria o
sistema valida se o contêiner está no pátio, permitindo fazer a vistoria ou não), e se estiver como
"X", a validação já foi feita e os dados estão na tela, podendo-se então limpar os dados para realizar
uma nova busca.
O sistema foi construído para ser operado tanto pelo uso do teclado, como pelo uso do
apontador de tela. Assim, por exemplo, todas as telas podem ser fechadas pela tecla esc ou pelo
botão de fechamento da tela, bem como é possível passar campo a campo pela tecla enter, todas
disponíveis no dispositivo móvel. Nos campos do tipo busca (onde o usuário digita um código
referente a um cadastro) é possível chamar a tela de busca tanto pela tecla F9 como pelo botão ao
lado do campo (marcado como �...�). Do mesmo modo, é possível gravar os dados tanto pela tecla
F2, como pelo botão de Salvar. Nos testes realizados, essas funções facilitaram a experiência de
uso.
Nas figuras a seguir, estão relacionadas fotos tiradas com o sistema operando no dispositivo
móvel conectado ao Sistema Modall. A Figura 34 mostra a tela do Windows CE com o atalho para
a Solução Móvel, seguida da foto do menu inicial do sistema na Figura 35. A partir do menu,
65
podem ser acessadas as rotinas de consulta de contêiner, mostrada na Figura 36 e a rotina de
Estimativa, mostrada na Figura 37.
Figura 34. Atalho do sistema no Windows CE. Figura 35. Menu inicial do sistema executando no dispositivo.
Figura 36. Tela de Consulta de Contêiner executando no dispositivo.
Figura 37. Tela de Estimativa executando no dispositivo.
66
Novas funcionalidades
Ao término do projeto, outras funcionalidades possíveis de serem criadas foram levantadas,
porém, não foram incluídas devido ao tempo de implementação, mas serão implementadas
posteriormente. São elas:
Estimativa por grupo, onde podem ser criadas várias estimativas por contêiner, por exemplo,
pré-estimativas e estimativas próprias para reefer ou PTI;
Vistoria por grupo, onde podem ser feitas várias vistorias por contêiner, por exemplo, uma
vistoria reefer e outra da estrutura;
Abastecimento Genset: onde são informados dados do abastecimento de combustíveis de
contêineres genset;
Pré-gate: onde o operador pega os dados do caminhão/contêiner antes dele entrar no pátio
pelo gate;
Novo posicionamento: Será implementado um novo posicionamento para o Sistema Modall
no Módulo Terminal, e ele poderá ser colocado também na solução móvel; e
Funcionamento off-line: É a operação sendo feita de forma desconectada do Sistema
Modall. Ao término do projeto, foi verificado a possibilidade da rede sem fio não alcançar
um operador trabalhando em uma área com contêineres em todos os lados, como é o caso do
PTI. Nesse modo, o usuário faria o cadastro dos PTI e posteriormente, a sincronização com
o Sistema Modall. Há diversas formas de guardar dados no dispositivo móvel, por exemplo,
em arquivos XML ou em banco de dados para dispositivos móveis.
Instalação e configuração
Para que o aplicativo rode no dispositivo móvel, são necessários os seguintes requisitos:
Sistema operacional Windows CE 5.0; e
Compact Framework 2.0.
Os arquivos necessários para a aplicação rodar são:
MobileTVZ.exe, que é o executável da aplicação;
Config.xml, que contêm os dados para conexão ao banco de dados; e
67
CoreLab.Oracle.dll, que contêm a camada de acesso ao banco de dados. Não é necessário o
client do Oracle, pois ele já está encapsulado nessa dll.
O arquivo Config.xml pode ser gerado tanto pela aplicação, como ser colocado diretamente
no aparelho. No primeiro caso, ao iniciar o sistema, é verificado se o arquivo existe, caso não exista,
é mostrada uma tela de entrada com os seguintes campos:
Server: IP do servidor onde se encontra o Oracle;
Sid: Sid do banco de dados do Sistema Modall;
Port: Porta do serviço do banco de dados do sistema Modall; e
Agência: Agência de trabalho da Solução Móvel.
Ao término da digitação dos dados, o sistema grava o arquivo XML (Extensible Markup
Language) na pasta atual, que é usado toda vez que o usuário loga no sistema. Para efeitos do caso
de uso, essa situação não é considerada, pois esse arquivo pode ser colocado e alterado
manualmente pelo especialista.
Com relação ao CF 2.0, é preciso verificar se ele já esta instalado no aparelho. Se não
estiver, é necessária sua instalação, através do arquivo �NETCFv2.wce5.x86.cab�, disponível no
Visual Studio (em suas pastas, há várias instalações, próprias para cada tipo de processador e SO.
No caso, é o Windows CE 5.0 e processadores Intel).
3.5 Implementação
Nessa seção mostra-se como o sistema foi implementado, relacionando as ferramentas
utilizadas na codificação, as ferramentas de suporte, a forma como o código foi dividido e as
dificuldades encontradas.
Visual Studio
O sistema foi construído com o uso da ferramenta Microsoft Visual Studio 2005, através da
linguagem C# e da plataforma .NET Compact Framework 2.0.
No VS (Visual Studio) é possível criar sistemas para dispositivos móveis diversos que
contenham as versões móbile do sistema operacional Windows, citando-se o Windows Pocket PC
68
2003, o Windows SmartPhone 2003 (para dispositivos menores como celulares) e o Windows CE
5.0 (para dispositivos maiores, como PDAs).
A ferramenta permitiu o rápido desenvolvimento da solução móvel, sendo que as
características mais marcantes notadas foram:
Possibilidade de debug direto no emulador ou no dispositivo móvel;
Função de Autocompletar conforme o contexto;
Rápida manipulação dos elementos da solução, como propriedades de objetos e arquivos;
O namespace, que permite a separação lógica das classes do sistema; e
Grande conjunto de componentes e classes prontos da CF.
.NET Compact Framework
O .NET CF possui um amplo conjunto de componentes e funções prontas que foram úteis
no desenvolvimento da solução móvel, como botões de checagem, datagrids para visualização de
dados, manipulação de arquivos XML e manipulação de dados, dentre inúmeras outras. Como
exemplo, pode-se citar a classe DataSet, que possibilita manipular várias tabelas do banco de dados
(na forma de registros e campos) localmente, sem a necessidade de conexão permanente a um banco
de dados.
A metodologia de codificação do .NET CF segue o mesmo padrão do framework .NET,
embora seu conjunto de funcionalidades seja menor. Na verdade, essa metodologia é a mesma para
qualquer tipo de plataforma e tipo de aplicação, o que permite que códigos sejam compartilhados
entre si, e o custo com treinamento de desenvolvedores seja reduzido.
A solução móvel adotou o Windows CE 5.0, a qual é suportado pelo Terminal Coletor de
dados CPT 9500, e onde é possível executar o .NET CF 2.0.
Conexão ao banco de dados do Sistema Modall
Há duas formas de conexão a um banco de dados: conectada e desconectada. Na forma
conectada, é criada uma conexão no início do programa ou rotina, e a mesma é mantida até o fim
da rotina/programa. Já na forma desconectada, a conexão é aberta e fechada conforme seu uso.
69
A solução móvel adotou o modo conectado: quando se inicia uma determinada rotina (como
a Vistoria ou a Consulta) uma conexão é aberta e quando o usuário fecha a tela, a conexão é
fechada.
Inicialmente, isso foi feito para otimizar o tempo de acesso, porém, em testes posteriores
verificou-se que esse tempo de abertura/fechamento pouco influencia na eficiência. Constatou-se
ainda que modo desconectado é o mais seguro, porém, o método conectado foi mantido na solução.
Oracle
O Sistema Modall roda unicamente no banco de dados Oracle. O Oracle é considerado o
melhor banco de dados existente e dentre suas principais características, citam-se:
Grande escalabilidade, em relação ao crescimento dos dados do banco;
Portabilidade: roda em diversos SO e arquiteturas;
Robusto e mais adequado para missões consideradas criticas;
Grande otimização de performance para dados em grande quantidade;
Possui esquema de segurança e confiabilidade, como o uso de transações, foreign keys e
permissões de acesso por grupo e usuários;
Permite uso de tipos binários (imagens, filmes, sons, arquivos grandes);
Permite a paralelização de operações pesadas, incluindo backups lógicos, importações via
SQLLoader, consultas longas;
Multi-usuário: permite a atualização e consulta simultânea dos dados por diversas pessoas;
Triggers: Possui a capacidade de disparar gatilhos (por exemplo, quando um registro é
inserido), ajudando a realizar auditorias e esquemas de segurança;
O uso do PL/SQL (Procedural Language/Structured Query Language) em Stored
Procedures permite centralizar as regras de negócio da aplicação, além de permitir o
controle de transações dentro de um bloco determinado;
Real Application Clusters (RAC) permite que aplicativos rodem em vários servidores
interconectados, ("em cluster"), sem a necessidade de serem customizados, aumentando a
escalabilidade e a disponibilidade;
70
As ferramentas de monitoramento da Oracle auxiliam o trabalho de manutenção do banco de
dados;
Exige especialização técnica, seja para administração do banco, bem como para atividades
de programação (geração de consultas, de base de dados, dentre outras);
Alto custo da licença e do hardware necessário para rodar os softwares
SqlTools
Esse aplicativo permite acessar qualquer banco de dados Oracle disponível e gerenciar seus
objetos. Por exemplo, é possível fazer o plano de querys (verificação de otimização), alterar os
dados das tabelas através de comandos update, insert e delete, alterar e adicionar tabelas, campos,
índices, além de permitir a criação de objetos PL/SQL.
Essa ferramenta foi usada para procurar, digitar e validar as consultas DML (Data
Manipulation Language) e DDL (Data Definition Language) necessárias ao sistema. Na camada de
negócio, todas essas consultas foram digitadas primeiramente no SQLTools, onde foram validadas
se estavam em conformidade e então passadas ao editor do VS, evitando erros posteriores.
Codificação
O sistema foi codificado em 2 camadas de código, como mostrado a seguir:
Camada de apresentação: Constituída das telas de entrada de dados, das telas de consulta de
dados e das validações de campos obrigatórios.
Camada de negócio/acesso aos dados: Constituída das regras de negócio, das consultas SQL
(Structured Query Language) e da gravação de dados. Cada vez que uma rotina é chamada (como o
PTI ou a Vistoria), é criado um objeto da classe de negócio correspondente, com a abertura de uma
conexão ao banco de dados.
Nessa camada, encontram-se os objetos de acesso aos dados, que determinam a forma como
é feito a conexão com o banco de dados Oracle. Foi utilizado o conjunto de componentes
proprietário da Corelabs (disponível em http://www.crlab.com) denominado "OraDirect .NET
Mobile version 4.20 for .NET CF 2.0", que são próprio para o desenvolvimento de aplicações
móveis para banco de dados Oracle, através do .NET CF. Elas foram necessárias porque a
71
ferramenta não disponibiliza uma forma nativa de conexão ao Oracle, ao menos que se use Web
Services.
Esses componentes permitiram e facilitaram a conexão e manipulação do banco de dados
Oracle do Sistema Modall diretamente do aplicativo.
Dentre as principais características que permitiram sua escolha, citam-se (CoreLabs, 2007):
Fácil desenvolvimento;
Sem necessidade de instalar cliente Oracle na estação;
Suporte as últimas versões do Oracle Server (inclusive a 8i, do Sistema Modall);
Suporte a todos os tipos de dados e objetos do Oracle;
Suporte ao .NET CF 2.0;
Suporte a tabelas e registros PL/SQL;
Integração com o Microsoft Visual Studio .NET 2005; e
Suporte ao tipo DataSet.
Nesse trabalho, foram usados os seguintes componentes:
OracleConnection: Abre uma sessão com um banco de dados especificado na string de
conexão, que contém usuário/senha,o nome do servidor Oracle e seu local na rede. Permite ainda
abrir, completar e cancelar transações.
OracleCommand: Permite o uso de instruções DML, como selects, updates, insert e deletes.
Esses componentes, acessados como objetos, são usados pela classe de negócio. Por
exemplo, em consultas "select", é passado uma string contendo o comando e seus parâmetros e o
objeto retorna um Dataset, que pode ser manipulado localmente. Do mesmo modo, para as rotinas
de gravação, é passado uma string contendo o SQL e seus parâmetros e o objeto envia
automaticamente esse comando ao banco de dados.
Cada rotina ou funcionalidade foi construída usando dois arquivos: um para a camada de
apresentação, nomeada com o prefixo 'frm' e outra para a classe de negócio/acesso aos dados,
nomeada como o prefixo "class", todas trabalhando no mesmo NameSpace.
72
Para facilitar a manutenibilidade, com relação ao nome das classes, foi adotado o seguinte
critério:
Camada de apresentação: Precedida de �frm� por exemplo, frmConteiner;
Camada de negócio: Precedida de �T�, por exemplo, TVistoria; e
Objetos de Acesso aos dados: Precedida de �Oracle� por exemplo, OracleConnection.
Essa configuração proporcionou ao sistema baixo acoplamento, uma vez que as classes
foram separadas de acordo com seu uso, possuindo poucas referencias uma a outras, a não ser em
classes de uso geral como as de Log e de banco de dados. Ainda no quesito manutenibilidade, todos
os objetos do sistema foram nomeados com um nome significativo, seja Datasets, caixa de seleção,
caixa de digitação, dentre outros, sempre através de um prefixo seguido de um nome. Além disso,
todas as funções e classes estão documentadas no código fonte, e, em alguns casos, as linhas
também estão documentadas.
Para escrever os comandos SQL de acesso ao Sistema Modall e definir algumas regras de
negócio foi necessário estudar o código fonte do Sistema Modall, sendo que sua disponibilidade foi
de grande importância ao desenvolvimento do projeto.
Foram estudados outras duas formas de implementação, mas que não foram adotadas:
Uso de PL/SQL: É uma extensão da linguagem SQL para banco de dados Oracle, que
permite a construção de programas armazenados no próprio SGDB. Como um exemplo,
imagina-se a execução de um comando update: a instrução estaria armazenada no banco e o
programa apenas chamaria o nome que a identifica. Essa construção facilita a manutenção
dos comandos SQL, diminui seu tempo de execução e centraliza as regras de negócio,
deixando apenas os aspectos da apresentação no lado cliente.
Uso de Web Services: Em vez de chamar uma função PL/SQL (como as storeds
procedures), o sistema pode consumir web services para executar comandos do banco, com
as mesmas vantagens de acessar diretamente PL/SQL (que pode ser feita pelo corelabs). No
entanto, perde-se em manutenibilidade: é necessário criar o aplicativo servidor do web
service (conectando ao banco através de PL/SQL ou de forma direta), o aplicativo cliente,
além de toda uma configuração e disponibilização de um servidor web. Assim, uma
manutenção rotineira teria que considerar vários artefatos do sistema.
73
Dificuldades encontradas
Apesar de a ferramenta ter-se mostrado muito boa para o desenvolvimento do sistema, com
grande auxilio a produtividade, algumas dificuldades foram encontradas, como:
Falta de uma plataforma: Não havia um conjunto de funções e componentes próprios para o
desenvolvimento desse tipo de aplicação e que podem ser usado em varias situações, por exemplo,
componentes para a consulta de códigos pelo nome, componentes para validações de códigos de
cadastro, dentre inúmeras outras funções, que precisaram ser criadas.
Falta de conhecimento da plataforma e da linguagem: Esse desenvolvedor possuía
inicialmente poucos conhecimentos da ferramenta. No entanto, há grande quantidades de
informação disponível na internet, principalmente na documentação do .NET e nos fóruns da
MSDN (http://msdn2.microsoft.com/pt-br/default.aspx). Além disso, a plataforma atendeu as
expectativas quanto ao aprendizado e à produtividade.
3.6 Testes e validações do Sistema
Nessa seção mostra-se como o sistema foi testado, apresentando os métodos de testes de
unidade, de integração, integração com o Sistema Modall, testes de funcionalidades e testes de
usabilidade.
O principal objetivo da realização de testes, é varrer o sistema em busca de erros, a fim de
corrigi-los antes que o usuário a encontre.
Primeiramente, após a construção de determinada parte do código (como a gravação dos
dados da manutenção de contêiner), os teste de unidade eram realizados em busca de erros de lógica
e de sintaxe. Esses testes eram feitos tanto no emulador do Windows CE 5.0 (disponível para
download no site da Microsoft), como no emulador integrado ao Visual Studio.
No primeiro caso, no emulador do Windows CE 5.0 foi necessário criar o ambiente dentro
do emulador, pois o mesmo não é integrado ao VS. Apesar da integração ser possível, isso não foi
feito porque demandaria recursos (como ferramentas e tempo) não disponíveis. Assim, foi instalado
o CF 2.0 no emulador, copiado todos os arquivos da Solução Móvel gerados pelo VS (item 3.4.3,
instalação e configuração) para ele, em seguida executado o arquivo .EXE do sistema.
74
Esse método mostrou-se adequado, com o sistema executando de forma rápida
(comparando-se a uma aplicação desktop padrão, com tempo de resposta entre 1 e 3 segundos).
Porém, em casos de erro mais complexos e difíceis de identificar a origem, foi usado debug do VS,
através do emulador do Windows Pocket PC 2003. Apesar de funcionar corretamente, o
desempenho foi lento (tempo de carregamento da primeira de vez variava de 20 a 50 segundos para
a maioria das rotinas), sendo indicado apenas em último caso.
Uma possibilidade interessante de debug com o VS, é realizá-lo diretamente no dispositivo
conectado ao PC. Esse método necessita apenas do ActiveSync instalado e configurado no PC
(disponível no site da Microsoft), de uma conexão via cabo do PC ao dispositivo e de algumas
configurações. Esse método, no entanto, não precisou ser adotado.
Além dos testes dos códigos em C#, foram feitos testes das instruções SQL. O sistema conta
com várias dessas instruções, que fazem as consultas e gravação de dados. Esses comandos foram
primeiramente validados (erro de sintaxe e de lógica) pela ferramenta SQLTools conectado ao
banco de dados do Sistema Modall, o que diminui esse tipo de erro no aplicativo.
Assim, os testes de unidade compreenderam a busca completa por erros de sintaxe e erros de
lógica das funções construídas. Para testar a conformidade com os requisitos, com as regras de
negócio e testar a integração com o Sistema Modall, foram realizadas uma série de testes em cada
rotina, seguindo um checklist, verificando sua adequação tanto no Sistema Modall, como na
Solução Móvel.
A seguir, é apresentado o checklist da rotina de Vistoria. Os checklist das rotinas de �PTI",
"Estimativa", "Posicionamento", "Consulta" e "Manutenção" encontram-se no Apêndice B.1.
Vistoria
Realizar Entrada de contêiner no TM (Módulo Terminal ou Sistema Modall);
Realizar a Consulta do Contêiner no Módulo Terminal: status deve ser "Ag. Vistoria";
Realizar a Consulta do Contêiner na Solução Móvel: status deve ser "Ag. Vistoria";
Fazer vistoria na Solução Móvel, colocando Status como �DM�: sistema deve permitir;
Realizar consulta do Contêiner na Solução Móvel: Status atual deve ser "Ag. Estimativa";
Realizar Consulta do Contêiner no TM: Status atual deve ser "Ag. Estimativa";
75
Fazer vistoria na Solução Móvel: Sistema Não deve permitir;
Realizar Saída de contêiner no TM;
Fazer vistoria na Solução Móvel: Sistema Não deve permitir;
Realizar Entrada de contêiner no TM;
Fazer vistoria na Solução Móvel, colocando Status como �OK�: sistema deve permitir;
Realizar consulta do Contêiner na Solução Móvel: Status atual não deve aparecer nada; e
Verificar no TM se os logs das operações foram feitas corretamente.
Com relação a estrutura física necessária aos testes, foram usados:
Uma máquina PC com o Sistema Modall, a qual foi usado o Módulo Terminal, ligado a
uma rede Ethernet;
Um Acess Point, que fornece o acesso do dispositivo móvel à rede física; e
O dispositivo Móvel (Terminal Coletor de dados CPT 9500), ligado a essa rede.
Com relação ao Acess Point, não foi feito estudos para determinar a quantidade e disposição
necessária num Terminal de contêiner vazio, sendo que isso deve ser feito postumamente.
Testes de usabilidade
Os testes de usabilidades foram feitos com analistas da Modallport, que são experientes no
uso do Módulo Terminal. Não foi possível realizar testes num ambiente com usuários de um
Terminal, porém, num ambiente real, esses usuários geralmente possuem um bom nível de
experiência.
Os testes foram feitos com base no ensaio de interação presente no Apêndice B.2.1, com o
desenvolvedor acompanhando o uso, mas não influenciando ou ajudando. Antes de sua aplicação,
um questionário foi entregue, em que se pede que o usuário marque se o passo dado no momento
está de acordo ou não, justificando em caso negativo. O questionário encontra-se no Apêndice
B.2.2.
Como exemplo, no Passo 2 do ensaio, é pedido que o usuário �Faça a vistoria do contêiner
como "DM" no dispositivo�. Logo, o usuário deve verificar na lista se houve algum problema, por
exemplo, �Os rótulos mostram aquilo que significam?� ou �As mensagens de erro e aviso são
claras� e assim por diante.
76
Futuramente, esses testes podem ser melhorados e aplicados a usuários do sistema em um
terminal de contêiner vazio.
O questionário aplicado teve questões baseadas e adaptas do ErgoList. O Ergolist é uma
ferramenta de avaliação de sistemas interativos, e permite avaliar e desenvolver sistemas sob o
ponto de vista de interação com o usuário (ERGOLIST, 2006).
Com relação aos resultados obtidos nesses testes, pôde-se concluir que:
Há necessidade de treinamento para uso de algumas rotinas;
Há necessidade de treinamento para uso do dispositivo;
Houve dificuldades com o teclado do Windows CE; e
Algumas mensagens não foram claras.
Partes das mensagens pouco claras foram corrigidas, porém, são necessários estudos e
ajuntes em algumas rotinas para sanar o problema da dificuldade com o teclado. Em suma essa
dificuldade acontece quando uma tela do sistema ocupa todo o visor do dispositivo e o teclado de
digitação do sistema (não do dispositivo) fica sobreposta a essa tela.
De maneira geral, apesar das dificuldades, houve a aceitação do sistema pelos usuários,
citando-se como pontos fortes suas funcionalidades, a disposição dos elementos na tela e as telas
não poluídas.
77
CONCLUSÕES
O objetivo desse trabalho orientou-se a criar uma solução móvel integrada ao Módulo
Terminal do Sistema Modall. Para isso, foram necessárias várias etapas, as quais incluem a pesquisa
referente à área portuária e às tecnologias de desenvolvimento, a modelagem e implementação do
sistema e por fim, os testes de funcionalidade e usabilidade.
Primeiramente, buscou-se o conhecimento do que seria preciso para que o projeto fosse
implementado numa plataforma de desenvolvimento, buscando compreender questões referente à
área de negócio onde o software processará, à computação móvel e ao planejamento do
desenvolvimento do sistema, através da sua modelagem e do levantamento dos requisitos.
Assim, buscou-se compreender o estágio atual em que se encontra a área portuária,
mostrando que o crescimento das exportações e a melhoria dos portos aumentaram o investimento
em TI como um todo, refletido na necessidade de novas soluções para as organizações dessa área,
como o Sistema Modall e a Solução Móvel desenvolvida. A seguir, o estudo das características de
um terminal de contêiner e do contêiner mostrou-se importantes para o levantamento dos requisitos
e da modelagem do sistema.
No estudo de sistema de informações, verificou-se a grande importância para as
organizações de um SPT, que vai além de ser um simples coletor de informações, pois fornece aos
outros sistemas da organização informações importantes e vitais para a tomada de decisões
estratégicas.
Já a pesquisa sobre computação móvel mostrou o que foi necessário para que o software
rodasse no dispositivo: a definição da comunicação com a rede física, o tipo de dispositivo usado, o
ambiente tecnológico e a arquitetura mais adequada. Os conceitos estudados deram todo o
conhecimento necessário para que a escolha da melhor solução, adequada ao contexto, fosse feita.
Na modelagem do sistema foi desenvolvida a documentação em UML, e apesar do nível de
detalhe empregado inicialmente, ainda foram necessários ajustes durante a implementação, com
mudança de alguns requisitos e casos de uso.
Na etapa de implementação, o uso do Visual Studio 2005 integrado ao CF 2.0 mostrou-se de
rápido aprendizado, com ganhos no tempo de desenvolvimento proporcionado pelo conjunto de
funções e componentes já prontos da plataforma. Verificou-se também que a arquitetura de duas
78
camadas facilitou a manutenibilidade, porém, o uso de PL/SQL no lado servidor a aumentaria ainda
mais. Com a utilização de Corelabs, acessando diretamente o Oracle sem Web Services ou Client
Oracle no dispositivo, a codificação ficou mais simples, também ajudando na questão de
manutenções posteriores.
Foram realizados testes de funcionalidade e usabilidade. As funcionalidades do sistema
foram testadas através de um roteiro pré-determinado, que incluiu testar a integração de cada rotina
isoladamente e sua integração com o Sistema Modall. O principal objetivo desses testes era
encontrar erros no sistema, que eram imediatamente corrigidos. Nos testes de usabilidade testou-se
a aceitação pelos usuários, através de ensaio de interação e questionário.
Como trabalhos futuros, propõem a continuidade de estudos sobre tecnologias de
desenvolvimento para dispositivos móveis, visto que novas ferramentas estão sendo sempre
lançadas e melhoradas. Assim, por exemplo, podem-se estudar novas conectividades entre
dispositivos móveis e banco de dados externos, ou explorar os bancos de dados móveis, que são
aqueles que podem ser armazenados no próprio dispositivo. Ainda, as possibilidades do RFID
(Radio-Frequency IDentification) podem ser trabalhadas junto a aplicações de diversas áreas de
negócios, e integradas a dispositivos, usando Java ou .NET.
79
REFERÊNCIAS BIBLIOGRÁFICAS
BANDEIRA, Denise Lindstrom. Alocação e movimentação de contêineres vazios e cheio � um
modelo integrado e sua aplicação. Porto Alegre, 2005. Teste de Doutorado, Universidade Federal do Rio Grande do Sul, Escola de Administração. BANZATO, Eduardo; MOURA, Reinaldo Aparecido; CARILLO JUNIOR, Edson. Atualidades na
armazenagem. São Paulo: IMAM, 2003. BEZERRA, Eduardo. Princípios de análise e projeto de sistemas com UML. Rio de Janeiro: Campus: Elsevier, 2002. COMPEX. Terminal Coletor de dados CPT 9500 (Windows). Disponível em: <http://www.compextec.com.br/produtos.php?codigo=84>. Acesso em: 17 maio 2007. CORELAB. OraDirect .NET. Disponível em <http://www.crlab.com/oranet>. Acesso em: 05 out. 2007. COVEY, Stephen R. O 8º Hábito: da eficácia à grandeza. São Paulo: Campus, 2005.
CRISPIM JUNIOR, Carlos Fernando. Análise de tecnologias para dispositivos móveis: um estudo de caso na área da saúde. Itajaí, 2006. 124 f. Trabalho de Conclusão de Curso (Graduação
em Ciência da Computação) � Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006.
CRUZ, Tadeu. Workflow: a tecnologia que vai revolucionar processos. São Paulo: Atlas, 2000. DEITEL, H. M. et al. C# Como programar. São Paulo: Pearson Education, 2003. DICIONÁRIO INFO. As palavras mais usadas (e abusadas) da computação e da internet
dissecadas uma a uma. São Paulo: Editora Abril, 2004. EXAME. Enfim, o mercado se impôs. Revista Exame, ano 41, n. 9, ed. 893, maio 2007. ERGOLIST. Projeto Ergolist. Florianópolis: UFSC, 2006. Disponível em: <http://www.labiutil.inf.ufsc.br/ergolist/projeto.htm>. Acesso em: 13 dez. 2007. FERREIRA, Thiago Antonio de Sousa. Sistema para consulta de planos alimentares, utilizando
um dispositivo móvel. Itajaí, 2006. 84 f. Trabalho de Conclusão de Curso (Graduação em Ciência
da Computação)�Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do
Itajaí, Itajaí, 2006.
FIGUEIREDO, Carlos Maurício Seródio; NAKAMURA, Eduardo. Computação Móvel: novas oportunidades e novos desafios. T&C Amazônia, ano 1, no. 2, jun. 2003.
GARCIA JUNIOR, Antônio Carlos (Organizador). Segurança e Saúde no Trabalho Portuário: Manual Técnico da NR 29. Vitória: Fundacentro/ES, 2003.
80
GIL, Antônio de Loureiro. Sistemas de informações: contábil, financeiros. São Paulo: Atlas, 1995. GONÇALVES, José E. Lima. As Empresas são Grandes Coleções de Processos. RAE - Revista de
Administração de Empresa, Jan/Mar de 2000. GUIA DO HARDWARE. 802.11g, Termos técnicos GdH. 2007a. Disponível em:
<http://www.guiadohardware.net/termos/802.11g>. Acesso em: 24 abr. 2007. GUIA DO HARDWARE. Bluetooth, Termos técnicos GdH. 2007b. Disponível em:
<http://www.guiadohardware.net/termos/bluetooth>. Acesso em: 24 abr. 2007. GUIA LOGÍSTICO. Glossário: Definição de Contêiner. 2007. Disponível em: <http://www.guiadelogistica.com.br>. Acesso em: 31 jan. 2007. HADDAD, Renato. Visão Geral do .NET Compact Framework. 2007. Disponível em:
<http://download.microsoft.com/download/f/d/4/fd4079d7-f96e-4cdb-859c-a2ca32859dbd/DOTNET%20FRAMEWORK/framework_visaogeral.doc>. Acesso em: 25 maio 2007. HAMMER, Michael; CHAMPY, James. Reegineerig the corporation. New York: Harper Business. 1994. IDGNOW. Bluetooth, Wi-Fi e Wimax: conheça as tecnologias de conexão sem fio. 2007. Disponível em: <http://idgnow.uol.com.br/telecom/2007/02/08/idgnoticia.2007-02-08.5288943928/IDGNoticia_view?pageNumber:int=2>. Acesso em: 24 abr. 2007. ISAM, Infra-estrutura de Suporte às Aplicações Móveis Distribuídas. Definição de computação
móvel. 2007. Disponível em: <http://www.inf.ufrgs.br/~isam/paginaDefComputacaoMovel.html>. Acesso em: 31 jan. 2007. JAVAFREE. Java. 2007a. Disponível em <http://www.javafree.org/wiki/Java>. Acesso em 26 maio 2007. JAVAFREE. O que é Java? 2007b. Disponível em:
<http://www.javafree.org/content/view.jf?idContent=84>. Acesso em 26 maio 2007. LAUDON, K. C. e LAUDON, J. P. Sistemas de Informação com Internet. Rio de Janeiro: LTC, 2001. LEE, Valentino; SCHNEIDER, Heather; SCHELL, Robbie. Aplicações Móveis: arquitetura, projeto e desenvolvimento. São Paulo: Makron Books, 2005. LIMA, Edwin. REIS, Eugênio. C# e .Net para desenvolvedores. Rio de Janeiro: Campus, 2002. LINHARES, Osmário Cezar. Solução WEB EDI Utilizando XML Como Apoio a Logística para
Portobello S.A. Itajaí, 2006. 172 f. Trabalho de Conclusão de Curso (Graduação em Ciência da
Computação) � Centro de Ciências Tecnológicas da Terra e do Mar, Universidade do Vale do Itajaí,
Itajaí, 2006.
81
LUZ, Rafael Pacheco. Utilização da tecnologia J2ME para automatização do controle de
expedição de equipamentos das empresas do Grupo MEG. Itajaí, 2006. 70 f. Trabalho de
Conclusão de Curso (Graduação em Ciência da Computação) � Centro de Ciências Tecnológicas da
Terra e do Mar, Universidade do Vale do Itajaí, Itajaí, 2006. MAÇADA, Prof. Dr. Antonio Carlos Gastaud. Tecnologia e Portos. 2007. Disponível em: <http://www.unisantos.br/mestrado/gestao/egesta/artigos/30.pdf>. Acesso em: 24 abr. 2007. MANTELI, Wilen. Uma nova arquitetura portuária. 2004. Disponível em:
<http://www.incubadora-santos.com.br/ped_integra.asp?codigo=16>. Acesso em: 25 maio 2007.
MATEUS, Geraldo R.; LOUREIRO, Antonio A.F. Introdução à computação móvel. In: 11a Escola de Computação, Rio de Janeiro, 1998.
MICROSOFT. Microsoft Mobile Internet Toolkit. Redmond: Microsoft, 2006. Disponível em:
<http://www.asp.net/mobile/intro.aspx?tabindex=6>. Acesso em: 15 fev. 2007. MICROSOFT. Reviewer's Guide do Microsoft Mobile Internet Toolkit. 2007a. Disponível em:
<http://www.microsoft.com/brasil/msdn/tecnologias/movel/mobilidade_revguide.aspx> Acesso em: 25 maio 2007. MICROSOFT. Mobile Web Application Architecture. 2007b. Disponível em <http://www.asp.net/mobile/flasharchitecture.aspx?tabindex=3&tabID=44>. Acesso em 01 jun. 2007. MOSIMANN NETTO, Max. Microsoft .NET Compact Framework - Conheça a plataforma para dispositivos móveis criada pela Microsoft. 2005. Disponível em:
<http://www.linhadecodigo.com.br/artigos.asp?id_ac=646&pag=1>. Acesso em: 25 maio 2007. MSDNBRASIL.Visual Studio: Introducing Visual Studio. 2007. Disponível em
<http://msdn2.microsoft.com/en-us/library/fx6bk1f4(VS.80).aspx>. Acesso em: 20 maio 2007. NOBRE, Marisa. A Gestão Logística do Contêiner Vazio. 2007. Disponível em: <http://www.unisantos.br/mestrado/gestao/egesta/artigos/78.pdf>. Acesso em: 31 jan. 2007. OLIVEIRA, Djalma de Pinho Rebouças de. Sistemas de informações versus Tecnologia da
Informação: um impasse empresarial. São Paulo: Atlas, 2005. O'BRIEN, James A. Sistemas de informação e as decisões gerenciais na era da internet. São
Paulo: Saraiva, 2001. REVISTA PORTUÁRIA. Contêiner, a grande alavanca das operações de comércio exterior.
Revista Portuária, Itajaí, edição nº 82, p.20-21, 2006. RUMOS. Container, revolução recente, que promete se expandir. Rumos, Informativo Mensal, ano 3, n. 38, nov. 1999. Disponível em:
<http://www.fertimport.com.br/rumos38/pagina2/pagina2.htm>. Acesso em: 13 maio 2007.
82
SUN. Introduction to Mobility Java Technology. 2006. Disponível em: <http://developers.sun.com/techtopics/mobility/getstart>. Acesso em: 15 fev. 2007. WIRELESS BRASIL. Variantes do 802.11 estão a caminho. 2007. Disponível em: <http://www.wirelessbrasil.org/wirelessbr/secoes/sec_802_11b/sec_802_11b.html>. Acesso em: 24 abr. 2007. WORLDNETLOGISTICS. 2007. Disponível em:
<http://www.worldnetlogistics.com/(images)/container_sea_opentop.png>. Acesso em: 01 maio 2007.
83
GLOSSÁRIO
Carga granel Carga em forma líquida ou grão.
Carga geral ou solta Todo tipo de carga que não é liquida ou grão.
Descarga É o processo de retirar a carga solta ou contêiner do navio.
Desunitização Retirada de diversos itens individuais de carga dentro de um contêiner.
Outro termo também usado é desova.
Embarque É o processo de colocar o contêiner ou carga solta no navio.
Exportação Vendas de mercadorias (bens ou serviços) ao exterior. Para a área portuária,
consiste em colocar um contêiner ou carga solta dentro de um navio que vai
para o exterior.
Genset Tipo de contêiner que armazena combustível (diesel) e acoplado a um
contêiner reefer fornece energia para ele.
Importação Compra de produtos originários do exterior. No porto, consiste em fazer a descarga do contêiner ou carga solta de um navio.
Logística Processo de planejamento, implementação, controle do fluxo e
armazenagem eficientes de matérias-primas, estoque em processo, produto acabado e informações relacionadas, desde o ponto de origem até o ponto de
consumo, como o objetivo de atender aos requisitos do cliente, em uma mesma organização.
Navio/Viagem Todo processo de embarque/descarga no porto é realizado por um navio, em
um terminado período de tempo. Cada período desses é identificado pelo
numero ou código da viagem daquele navio, no porto designado.
PTI Inspeção feita em contêiner reefer determinar se seu motor está funcionando
adequadamente, com base na especificação desse contêiner.
Porto Uma área localizada à beira de um oceano, mar, lago ou rio, destinada ao atracamento de barcos e navios, para a realização de embarque e descarga
de carga solta ou contêiner.
Unitização Colocação de diversos itens individuais de carga dentro de um contêiner.
Outro termo também usado é Ovação.
84
APÊNDICES
A MODELAGEM DO SISTEMA
A.1 CASOS DE USO
Os diagramas de caso de uso foram divididos em dois pacotes: Controle de Acesso, que
descreve o login do usuário, e o Controle de Operações, que descreve as funcionalidades do
sistema. A relação entre elas é mostrada na Figura 38.
Figura 38. Diagrama de Pacotes dos Casos de Uso.
A.1.1 Pacote 01: Controle de Acesso
Esse pacote consta o caso de uso responsável pelo login do usuário ao sistema.
A.1.1.1 UC 01.01 - Efetua Login
Caso de uso responsável pelo login do usuário no sistema.
Relações
RF01: O sistema deverá permitir autenticação de usuário do Sistema Modall.
Condições
Pré Condição: O usuário deve estar cadastrado no Sistema Modall através do Módulo
SisAcess; e
86
Pós Condição: Usuário logado no sistema.
Cenários
Fluxo Principal: Efetua Login
1. O sistema apresenta uma tela solicitando o usuário e a senha. (TEL01);
O usuário preenche os dados (usuário e senha);
O usuário confirma a digitação dos dados;
O sistema valida o login e a senha fornecidos; e
O sistema apresenta a tela principal com o Menu de Acesso (TEL02).
Fluxo de Exceção 1: Campos obrigatórios
Se no passo 3 o usuário e/ou a senha estiver(em) em branco, o sistema apresenta mensagem:
�Usuário e/ou senha obrigatórios� (TEL11) e retorna ao passo 1.
Fluxo de Exceção 2: Dados inválidos
Se no passo 4 o usuário não existir no sistema ou a senha para esse usuário estiver incorreta,
o sistema apresenta uma mensagem: �Login ou senha inválidos!� (TEL11) e retorna ao passo 1.
A.1.2 Pacote 02: Controle de Operações
O pacote Controle de operações descreve as funcionalidades do sistema que são usadas no
dia a dia dos operadores de pátio.
A.1.2.1 UC 02.01 � Vistoria de Contêiner
Caso de uso responsável pelo cadastro das vistorias de um contêiner.
Relações
RF2 - O sistema deve permitir fazer vistoria de contêiner;
RN 2.1: Para fazer a vistoria, o contêiner deve estar no pátio e ter o status AV
(aguardando vistoria) no cadastro de contêiner;
RN 2.2: Deve trazer o status de entrada como DM, e também deve trazer
automaticamente os valores dos campos do cadastro de contêiner: instrução, bom para
87
café (sim/não), bom para fumo (sim/não), bom para alimento (sim/não), carga geral
(sim/não), tara e MGW;
RN 2.3: Os campos que precisam ser digitados são: contêiner, status (DM/OK), tara,
MGW, instrução , observação, bom para café (sim/não), bom para fumo (sim/não), bom
para alimento (sim/não), carga geral (sim/não), checklist (sim/não) para cheiro/odor,
adesivos, marca de tambores, marca de óleo, ferrugem interna, todos trazendo não como
padrão;
RN 2.4: Deve gravar a data/hora atual da vistoria automaticamente;
RN 2.5: Se o status da vistoria for DM deve alterar o status do contêiner para AE. Se o
status da vistoria for OK, deve alterar o status do contêiner como OK; e
RNF1: O usuário deve informar apenas o número de série e dígito do identificador.
Condições
Pré Condição: O operador de pátio esta logado no sistema; e
Pós Condição: Uma vistoria cadastrada no sistema e o status do contêiner alterado.
Cenários
Fluxo Principal: Cadastrar Vistoria
1. O sistema apresenta a tela de cadastro de vistoria (TEL03);
2. O usuário informa o número de série e dígito do contêiner;
3. O sistema deve trazer automaticamente o status da vistoria como �DM�, e trazer a instrução, a tara, o MGW e os campos café, alimento, carga e fumo do cadastro de contêiner (RN 2.2), porém deve permitir a alteração;
4. O usuário preenche os demais campos da tela (RN 2.3);
5. O usuário confirma a operação; e
6. O sistema grava os dados informados, colocando a data/hora atual no campo �data da
vistoria� e alterando o status do contêiner para �AV� (aguardando vistoria) se o status da
vistoria for DM e OK se o status da vistoria for OK (RN 2.4 e RN 2.5). Além disso,
grava o log da operação (RNF7).
Fluxo de Exceção 1: No passo 2, ao digitar o contêiner:
88
a. O sistema deve verificar se o contêiner está no pátio do terminal e se tem o status de
�AV�. Se não estiver, mostra a mensagem �Contêiner não está no pátio ou status
diferente de AV� (TEL11) e volta ao passo 2 (RN 2.1);
Fluxo de Exceção 2: No passo 5, o usuário pode cancelar a operação. A tela será fechada e
o caso de uso se encerrará, voltando para o Menu de Acesso. O usuário pode optar ainda por fazer
uma nova Vistoria, sem deixar a tela.
Fluxo de Alternativo: No passo 2, ao informar o contêiner, o sistema deve verificar se
existe mais de um identificador de contêiner para o número de série e dígito informados,
pesquisando sobre a RN 2.1. Se sim, chama �UC 02.06 - Consulta Sigla Contêiner� (TEL09). Vai
para o passo 3 (RNF1).
A.1.2.2 UC 02.02 � Cadastro/Alteração de Estimativa
Caso de uso responsável por fazer a estimativa de reparo de contêiner.
Relações
RF3 - O sistema deve permitir fazer o cadastro e alteração de estimativas de contêiner;
RN 3.1: O contêiner deve estar no pátio e com o status como "AE" (aguardando
estimativa);
RN 3.2: Se houver uma estimativa já cadastrada para o contêiner no pátio, o sistema
permite alterá-la. Se não houver, o sistema permite incluí-la;
RN 3.3: Deve permitir cadastrar vários itens de estimativas;
RN 3.4: Os campos a serem cadastrados são: contêiner, avaria (busca), local (busca),
tamanho horizontal, tamanho vertical, tipo (estrutura, reefer, outros, wear/tear, lavação),
serviço (busca), complemento, quantidade e quantidade adicional. Obrigar todos os
campos;
RN 3.5: Deve gravar a data/hora atual da estimativa automaticamente;
RNF3: Nos campos do tipo busca, o sistema deve permitir buscar o código pelo nome; e
RNF1: O usuário deve informar apenas o número de série e dígito do identificador.
Condições
89
Pré Condição: Usuário logado no sistema; e
Pós Condição: Estimativa de reparo do contêiner cadastrada ou alterada.
Cenários
Fluxo Principal: Cadastrar Estimativa
1. O sistema apresenta a tela de Estimativa (TEL04A);
2. O usuário informa o número de série e dígito do contêiner;
3. O usuário digita ou altera os dados do item da estimativa;
4. O usuário confirma a operação; e
5. O sistema grava dos dados informados, colocando a data/hora atual na data da estimativa
(RN 3.5). Além disso, grava o log da operação (RNF7).
Fluxo de Alternativo 1
No passo 2, ao informar o contêiner, o sistema deve verificar se existe mais de um
identificador de contêiner para o número de série e dígito informados. Se sim, chama �UC 02.06 -
Consulta Sigla Contêiner� (TEL09). Vai para o passo 1 (RNF1).
Fluxo Alternativo 2: Alterar Estimativa
1 - No passo 2, se já existir alguma estimativa para o contêiner, o sistema pergunta se o
usuário quer cadastrar um novo ou alterar os existentes (RN 3.2);
2 - Se cadastrar um novo, avança ao passo 3 do fluxo principal. Se alterar, traz uma lista
com os itens da estimativa. (TEL04B);
3 � O usuário escolhe um item, podendo alterar ou excluir um item.
4 � Se decidir alterar, o sistema traz os dados para a tela, avançando ao passo 3 do fluxo
principal; e
4 � Se decidir excluir, o sistema pergunta se quer continuar. Após isso, o sistema continua
na mesma tela.
Fluxo Alternativo 3: Informar Avaria, Local e Serviço
90
No passo 3, nos itens da estimativa, quando o usuário informar cada um desses campos, que
são códigos para outros cadastros, o sistema deve permitir, através de uma tecla de função, chamar
uma tela (TEL10), exibindo uma lista com as respectivas tabelas. Nessa tela, o usuário pode
escolher pelo menu ou digitar a descrição e o sistema deve retornar seu código (RNF3).
Fluxo de Exceção 1: Validar contêiner
No passo 2, se o contêiner não estiver no pátio, ou seu status não for "AR� (aguardando
reparo), mostra mensagem ao usuário (TEL11) e volta ao passo 1 (RN 3.1).
Fluxo de Exceção 2: Campos obrigatórios
No passo 5, se algum campo do item da estimativa estiver em branco, o sistema avisa ao
usuário (TEL11) e volta ao passo 3 (RN 3.4).
Fluxo de Exceção 3: No passo 5, o usuário pode cancelar a operação. A tela será fechada e
o caso de uso se encerrará, voltando para o Menu de Acesso. O usuário pode optar ainda por
cadastrar um novo item, sem deixar a tela.
A.1.2.3 UC 02.03 - Consulta de Contêiner
Caso de uso responsável pela consulta das informações dos contêineres que estão no pátio,
ou que já saíram.
Relações
RF4 - O sistema deve permitir fazer consulta uma unidade informada, juntamente com a
relação de todos os seus movimentos (tracking do Terminal);
RN 4.1: Deve verificar se o contêiner existe no movimento, se existir, busca o último
movimento e mostra na tela; e
RN 4.2: Os campos que devem aparecer são: contêiner, código ISO, navio/viagem, no
pátio (sim/não), tara, MGW, status atual, status PTI, status do maquinário, data de
entrada, número do booking, posição no pátio, todos os checklist da vistoria, instrução,
designado, bom para café (sim/não), bom para fumo (sim/não), bom para alimento
(sim/não), carga geral (sim/não), situação, armador, dias no pátio;
RN3: No tracking, deve mostrar todos os movimentos realizados pelo contêiner
(entrada, saída, PTI, vistoria, estimativa, reparo e lavagem) e trazer os seguintes campos:
91
tipo de movimento, adicional (sim/não), data, recebimento, consignatário, armador,
booking, estimativa, oficina, status guia, vistoriador e autorização; e
RNF1: O usuário deve informar apenas o número de série e dígito do identificador do
contêiner.
Condições
Pré Condição: O operador de pátio estar logado no sistema; e
Pós Condição: As informações do contêiner devem estar na tela, apenas para consulta.
Cenários
Fluxo Principal: Consultar Contêiner
1. O sistema apresenta a tela de Consulta de Contêiner (TEL05A, TEL05B e TEL05C);
2. O usuário informa o número de série e dígito do contêiner;
3. O sistema busca os dados do banco de dados e mostra na tela (RN 4.2); e
4. O usuário lê os dados, optando por fechar a tela, voltando ao Menu de Acesso.
Fluxo de Exceção: No passo 2, ao digitar o contêiner, o sistema deve verificar se o
contêiner informado existe no cadastro de movimento. Se não existir, mostra a mensagem �O
contêiner não realizou movimento no terminal!� (TEL11) e volta ao passo 1. Se existir, o sistema
deve sempre buscar o último movimento do contêiner (RN 4.1).
Fluxo de Alternativo 1: No passo 2, ao informar o contêiner, o sistema deve verificar se
existe mais de um identificador de contêiner para o número de série e dígito informados em relação
a RN 4.1. Se sim, chama �UC 02.06 - Consulta Sigla Contêiner� (TEL09). Vai para o passo 3 (RNF
1).
Fluxo de Alternativo 2: No passo 4, o usuário pode fazer uma busca no tracking, através de
um botão de busca (�TR�). Deve trazer uma tela com os movimentos daquele contêiner (TEL 05B).
O usuário pode clicar no grid ou pressionar um botão para trazer os outros dados que não aparecem
na lista (TEL 06B) (RF4 e RN3). Ao fechar qualquer uma das telas, deve voltar ao passo 4.
Fluxo de Alternativo 3: O usuário pode optar ainda por fazer uma nova Consulta, sem
deixar a tela.
92
A.1.2.4 UC 02.04 � Manutenção do cadastro de contêiner
Caso de uso responsável por fazer a manutenção (alterações) do cadastro do contêiner.
Relações
RF5 - O sistema deve permitir a manutenção do cadastro de contêiner;
RN 5.1: Nesse cadastro, devem informados os campos: contêiner, código ISO (busca),
armador (busca), situação (busca), tara, MGW, material (ST/AL/FB/SI), bom para café
(sim/não), bom para fumo (sim/não), carga geral (sim/não), bom para alimento
(sim/não), designação e instrução;
RN 5.2: Campos obrigatórios: código ISO, armador e contêiner;
RN 5.3: O sistema deve permitir apenas a manutenção de uma unidade, e não o seu
cadastro; e
RNF3: Nos campos do tipo busca, o sistema deve permitir buscar o código pelo nome.
Condições
Pré Condição: Usuário logado no sistema; registros de armador, situação e ISO já
cadastrados.
Pós Condição: Contêiner com seus dados alterados.
Cenários
Fluxo Principal: Manutenção do cadastro de contêiner
1. O sistema apresenta a tela de cadastro de contêiner (TEL06);
2. O usuário informa o identificador do contêiner;
3. O usuário preenche ou altera os demais campos da tela (RN 5.1);
4. O usuário confirma a operação; e
5. O sistema grava os dados informados, assim como o log da operação (RNF7).
Fluxo Alternativo 1: Informar Armador e Situação.
Quando o usuário informar cada um desses campos, que são códigos para outros cadastros, o
sistema deve permitir, através de uma tecla de função, chamar uma tela (TEL10), exibindo uma lista
93
com as respectivas tabelas. Nessa tela, o usuário pode escolher pelo menu ou digitar a descrição e o
sistema deve retornar seu código (RNF3).
Fluxo de Exceção 1: Campos obrigatórios
No passo 4, se os campos �Código ISO� e �armador� não estão preenchidos, o sistema deve
exibir uma mensagem (TEL11) e voltar ao passo 3 (RN 5.2).
Fluxo de Exceção 2: No passo 4, o usuário pode cancelar a operação. A tela será fechada e
o caso de uso se encerrará, voltando para o Menu de Acesso. O usuário pode optar ainda por fazer
uma nova manutenção, sem deixar a tela.
Fluxo de Exceção 3: Validar existência do contêiner
No passo 2, o sistema deve verificar se o contêiner existe no cadastro. Se não, deve avisar e
bloquear, voltando para o passo 2.
A.1.2.5 UC 02.05 � Cadastro de PTI
Caso de uso responsável por fazer o cadastro, alteração e exclusão do PTI de contêineres
reefer.
Relações
RF6 - O sistema deve permitir o cadastro/alteração/exclusão de PTI;
RN 6.1: O contêiner deve estar no pátio e seu tipo deve ser Reefer;
RN 6.2: Deve permitir cadastrar vários PTIs por contêiner;
RN 6.3: Os campos a serem cadastrados são: contêiner, status (DM/OK) e tipo (mini
/normal);
RN 6.4: Os campos obrigatórios são status (DM/OK) e tipo;
RN 6.5: Deve gravar a data/hora atual do PTI automaticamente;
RN 6.6: Ao registrar o primeiro PTI, deve gravar a data e o status na tabela de status
maquinário (reefer);
RN 6.7: Deve gravar o PTI automaticamente como cobrado, e calcular seu valor
conforme regra já existente no TM; e
94
RNF1: O usuário deve informar apenas o número de série e dígito do identificador.
Condições
Pré Condição: Usuário logado no sistema, registro de Locais cadastrados; e
Pós Condição: PTI do contêiner cadastrado/alterado/excluído do sistema.
Cenários
Fluxo Principal: Cadastra PTI
1. O sistema apresenta a tela de PTI (TEL07A);
2. O usuário informa o número de série e dígito do contêiner (RN 6.3);
3. O usuário digita o status (DM/OK) e o Tipo (Mini/Normal) (RN 6.3);
4. O usuário confirma a operação; e
5. O sistema grava dos dados informados, colocando a data/hora atual na data do PTI (RN
6.5). Além disso, deve gravar o log da operação (RNF7), alterar o status maquinário (RN
6.6), e gravar o campo faturado e valor (RF 6.7).
Fluxo de Alternativo 1
No passo 2, ao informar o contêiner, o sistema deve verificar se existe mais de um
identificador de contêiner para o número de série e dígito informados, em relação ao RF 6.1. Se
sim, chama �UC 02.06 - Consulta Sigla Contêiner� (TEL09). Vai para o passo 3 (RNF1).
Fluxo Alternativo 2: Alterar/ Excluir PTI
1 - No passo 2, se já existir algum item no PTI, o sistema pergunta se o usuário quer
cadastrar um novo item ou alterar os existentes (RN 6.2);
2 - Se cadastrar um novo, retorna ao passo 3. Se alterar, traz uma lista com os PTIs.
(TEL07B);
3 � Na exclusão, o usuário pode selecionar um, pressionar e uma tecla de função e o sistema
exclui; e
4 � Na alteração, o usuário seleciona um, pressiona Enter e o sistema retorna ao passo 3.
Fluxo de Exceção 1: Validar contêiner
95
No passo 2, se o contêiner não estiver no pátio, ou o tipo não for reefer, exibe uma
mensagem (TEL11) e volta ao passo 1 (RN 6.1).
Fluxo de Exceção 2: Validar PTI
No passo 5, se os campos status e tipo não forem digitados, mostra mensagem ao usuário
(TEL11) e volta ao passo 3 (RN 6.4).
Fluxo de Exceção 3: No passo 5, o usuário pode cancelar a operação. A tela será fechada e
o caso de uso se encerrará, voltando para o Menu de Acesso. O usuário pode optar ainda por
cadastrar um novo PTI, sem deixar a tela.
A.1.2.6 UC 02.06 � Cadastro de Posicionamento/Reposicionamento
Caso de uso responsável por fazer o posicionamento ou reposicionamento dos contêineres.
Relações
RF7 - O sistema deve permitir fazer o posicionamento ou reposicionamento de
contêiner;
RN 7.1: O contêiner deve estar no pátio;
RN 7.2: Deve obrigar os campos contêiner, local (busca) e quadra; e
RNF1: O usuário deve informar apenas o número de série e dígito do identificador.
Condições
Pré Condição: Usuário logado no sistema; e
Pós Condição: Contêiner posicionado ou reposicionado.
Cenários
Fluxo Principal: Posicionar Contêiner
1. O sistema apresenta a tela de posicionamento (TEL08);
2. O usuário informa o número de série e dígito do contêiner;
3. O usuário informa o local e a quadra;
4. O usuário confirma a operação; e
96
5. O sistema grava dos dados informados, assim como o log da operação (RNF7).
Fluxo de Alternativo 1: Reposicionar Contêiner
No passo 2, ao informar o contêiner, o sistema deve verificar se existe mais de um
identificador de contêiner para o número de série e dígito informados, em relação ao RN 7.1. Se
sim, chama �UC 02.06 - Consulta Sigla Contêiner� (TEL09). Vai ao passo 3 (RNF1).
Fluxo de Alternativo 2: Reposicionar Contêiner
No passo 2, se contêiner já foi posicionado, traz os dados na tela, permitindo sua alteração.
Vai para o passo 3.
Fluxo Alternativo 3: Informar Local
Quando o usuário informar o local, que é um código para a tabela de locais, o sistema deve
permitir, através de uma tecla de função, chamar uma tela (TEL10), exibindo uma lista com os
locais existentes. Nessa tela, o usuário pode escolher pelo menu ou digitar a descrição e o sistema
deve retornar seu código (RNF3).
Fluxo de Exceção 1: Validar contêiner no pátio
No passo 2, se o contêiner não estiver no pátio, exibe uma mensagem (TEL11) e volta ao
passo 1 (RN 7.1).
Fluxo de Exceção 2: Validar campos obrigatórios
No passo 5, se os campos local e quadra não forem digitados, mostra mensagem ao usuário
(TEL11) e volta ao passo 4 (RN 7.2).
Fluxo de Exceção 3: No passo 4, o usuário pode cancelar a operação. A tela será fechada e
o caso de uso se encerrará, voltando para o Menu de Acesso. O usuário pode optar ainda por fazer
um novo posicionamento, sem deixar a tela.
A.1.2.7 UC 02.07 � Consulta Sigla Contêiner
Caso de uso responsável pela consulta do identificador do contêiner pelo número de série e
dígito informados.
Relações
97
RNF1: O usuário deve informar o número de série e dígito do contêiner. Se houver mais
de um, o sistema deve mostrar um menu para escolha.
Condições
Pré Condição: Um número de série e dígito do contêiner informado; e
Pós Condição: Um identificador retorna ao usuário.
Cenários
Fluxo Principal: Lista Contêineres
1. O sistema mostra uma lista com os contêineres ao usuário;
2. O usuário pode escolher um contêiner, através de um menu; e
3. O sistema retorna a sigla completa.
Fluxo Alternativo: No passo 2, o usuário pode digitar uma sigla completa. Se existir na
lista, vai para o passo 3, se não existir, mostra mensagem �Contêiner inexistente� e volta ao passo 1.
A.2 TELAS DO SISTEMA
Esta seção apresenta as telas do sistema, que foram citadas na descrição dos casos de uso
através da referência TEL seguida de um numero seqüencial. Algumas telas foram capturadas com
dados reais da aplicação em execução.
98
Figura 39. Tela 03A e 03B � Cadastro de Vistoria.
Figura 40. Tela 04A � Cadastro do item da Estimativa.
Figura 41. Tela 04B � Manutenção dos itens da
Estimativa.
99
Figura 42. Tela 05A - Consulta de Contêiner
(Principal). Figura 43. Tela 05B - Consulta de Contêiner (2-Outros).
Figura 44. Tela 05C - Consulta de Contêiner (2-Outros).
100
Figura 45. Tela 06 � Manutenção de cadastro de contêiner.
Figura 46. Tela 05D.- Tracking do Contêiner. Figura 47. Tela 05E. � Detalhes do Tracking.
101
Figura 48. Tela 07A � Cadastro do item do PTI. Figura 49. Tela 07B � Alteração/exclusão de
PTIs.
Figura 50. Tela 08 � Posicionamento do Contêiner.
102
Figura 51. Tela 09 � Busca de Contêiner. Figura 52. Tela 10 � Cadastro Padrão.
Figura 53. Tela 11 � Mensagem ao usuário.
A.3 DIAGRAMAS DE CLASSE E SEQUÊNCIA
A seguir são apresentados os diagramas de classe e seqüência referentes aos casos de uso da
modelagem, conforme foram apresentados nas seções 3.3.3 e 3.3.4.
103
cd Login• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Negócio/Acesso
Aprentação
Tconnection
- usuario: char- senha: char- Server: char- Sid: char
+ Open(char, char) : void+ getConfiguracao() : void+ create() : void
TEL01 - Login
- Usuario: char- Senha: char
+ create() : void+ Show() : void+ Showmessage() : void
TEL02 - Menu
+ Show() : void
Figura 54. Diagrama de Classe de Projeto da UC 01.01 - Efetua Login.
104
sd Login• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
TEL01 - Login
Tconnection
Operador
TEL02 - Menu
create()
create()
getConfiguracao()
Show()
Informa Usuario/Senha
Open(senha,usuario)
[if nao val ido]: Showmessage()
{fecha a tela de login }
[i f val ido]: Show()
Figura 55. Diagrama de Classe de Seqüência da UC 01.01 - Efetua Login.
cd Vistoria• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Negócio/Acesso
Apresentação
TVistoria
- OracleConnection: OracleConnection- dsVistoria: DataSet
+ gravarDados() : void+ getConteiner(char) : void+ create() : void
TEL09:frmDialog
- fSelection: DataRow- idcon: char
+ ShowDlg(DataTable) : conteiner+ OK() : void
TEL03-Vistoria
+ GravarDados()+ BuscarConteiner()+ LimparDados()+ Show()+ Showmessage()+ ShowDados() : void
Figura 56. Diagrama de Classe de Projeto da UC 02.01 � Vistoria de Contêiner.
105
sd Tv istoria• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Operador
TVistoria
«form»
TEL09:frmDialog
«form»
TEL03-VistoriaShow()
create()
BuscarConteiner()
{obtem DsVistoria }
dados= getConteiner(operacao)
[if qtde >1]: DataRow=ShowDlg(conteiner)[i f qtde = 0]: Showmessage()
[i f qtde = 1]: ShowDados()
GravarDados()
gravarDados()
[if gravouDados]: LimparDados()
Figura 57. Diagrama de Classe de Seqüência da UC 02.01 � Vistoria de Contêiner.
cd Estimativ a
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Acesso/Negócio
Apresentação
TEL04A - Item da
Estimativ a
+ GravarDados() : void+ Append() : void+ BuscaConteiner() : void+ Show() : void+ ShowDados() : void+ Showmessage() : void+ limparDados() : void
TEL04B -
Manutenção
+ Apagar() : void+ Alterar() : void+ Show() : void+ ShowItens() : void
TEL09:frmDialog
- fSelection: DataRow- idcon: char
+ ShowDlg(DataTable) : conteiner+ OK() : void
Testimativ a
- dsEstimativa: DataSet- oracleConnection: oracleConnection- dsEstimativas: DataSet
+ gravarDados() : void+ getConteiner() : void+ getItens() : void+ getItem() : void+ apagarItem() : void+ create() : void
Figura 58. Diagrama de Classe de Projeto da UC 02.02 � Cadastro/Alteração de Estimativa.
106
sd Estimativ a• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
«form»
TEL04A - Item daEstimativa
«form»
TEL04B -Manutenção
Testimativa
Operador
«form»
TEL09:frmDialog
Show()
create()
BuscaConteiner()
{obtem dsEstimativa }
dados= getConteiner()
[if QtdeCntr > 1]: conteiner=ShowDlg(DataTable)
{avisa e permite nova busca }
[if QtdeCntr = 0]: Showmessage()
getItem()
[i f qtdeItens > 1]: ShowItens()
[if qtdeItens = 0]: Append()
{usuário deseja apagar um item }
Apagar()
apagarItem()
{informa dados e grava }
GravarDados()
gravarDados()
{deve permitir novo item }
l imparDados()
Figura 59. Diagrama de Classe de Seqüência da UC 02.02 � Cadastro/Alteração de Estimativa.
cd Consulta• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Negócio/Acesso
Apresentação
TEL05ABC - Consulta
+ ShowDados() : void+ Show() : void+ Showmessage() : void+ BuscaConteiner() : void+ getTracking() : void
TEL09:frmDialog
- fSelection: DataRow- idcon: char
+ ShowDlg(DataTable) : conteiner+ OK() : void
Tela 05DE - Tracking
+ ShowTracking() : void
TConsulta
- OracleConnection: OracleConnection- DsConteiner: DataSet
+ Create() : void+ getConteiner(char) : dados+ getTracking() : void
Figura 60. Diagrama de Classe de Projeto da UC 02.03 - Consulta de Contêiner.
107
sd Consulta• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Operador
«form»
TEL05ABC -Consulta
«form»
Tela 05DE -Tracking
«form»
TEL09:frmDialog
TConsulta
Show()
Create()
BuscaConteiner()
{obtem DsConteiner }
dados= getConteiner(idcont)
[if qtde > 1]:conteiner=ShowDlg(DataTable)
{permite nova consulta }
[if qtde = 0]: Showmessage()
[if qtde = 1]: ShowDados()
{visualizar o tracking }
getTracking()
getTracking()
ShowTracking()
Figura 61. Diagrama de Classe de Seqüência da UC 02.03 - Consulta de Contêiner.
cd PTI• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Negócio/Acesso
Apresentação
TEL09:frmDialog
- fSelection: DataRow- idcon: char
+ ShowDlg(DataTable) : conteiner+ OK() : void
TPTI
- dsPTI: DataSet- OracleConnection: OracleConnection- dsPTIs: DataSet
+ gravarDados() : bool+ getConteiner() : operacao+ getPTIs() : void+ apagarPTI() : void+ Create() : void+ getPTI() : void
TEL07B - Manutenção PTI
+ Apagar() : void+ Alterar() : void+ Show() : void+ ShowPTIs() : void
TEL07A - Item do PTI
+ GravarDados() : void+ Append() : void+ BuscaConteiner() : void+ Showmessage() : void+ Show() : void+ showDados() : void+ LimparDados() : void
Figura 62. Diagrama de Classe de Projeto da UC 02.05 � Cadastro de PTI.
108
sd PTI• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Operador
TPTI
«form»
TEL07A - Itemdo PTI
«form»
TEL09:frmDialog
«form»
TEL07B -Manutenção PTI
Show()
Create()
BuscaConteiner()
{obtem DsPTI }
dados= getConteiner(idcont)
[i f QtdeCntr > 1]: conteiner=ShowDlg(DataTable)
{avisa e permite nova busca }
[i f QtdeCntr = 0]: Showmessage()
getPTI()
[i f QtdeItens > 1]: ShowPTIs()[i f qtdeItens = 0]: Append()
{usuario deseja apagar um item }
Apagar()
apagarPTI()
{informa dados e grava }
GravarDados()
gravarDados()
{Deve permitir novo PTI }
[if gravouDados]: LimparDados()
Figura 63. Diagrama de Classe de Seqüência da UC 02.05 � Cadastro de PTI.
109
cd Posicionamento
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
Negócio/Acesso
Apresentação
Tposicionamento
- dsPosicionamento: DataSet- OracleConnection: OracleConnection
+ getConteiner(char) : operacao+ gravarDados() : void+ Create() : void
TEL09:frmDialog
- fSelection: DataRow- idcon: char
+ ShowDlg(DataTable) : conteiner+ OK() : void
TEL08-Posicionamento
+ GravarDados() : void+ BuscaConteiner() : void+ LimparDados() : void+ Show() : void+ ShowDados() : void+ Showmessage() : void
Figura 64. Diagrama de Classe de Projeto da UC 02.06 � Cadastro de Posicionamento.
sd Posicionamento• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
• • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • • •
«form»
TEL08-Posicionamento
Tposicionamento
Operador
«form»
TEL09:frmDialog
Show()
Create()
BuscaConteiner()
{obtem dsPosicionamento }
dados= getConteiner(Conteiner)
[i f Qtde > 1]: conteiner=ShowDlg(DataTable)
{avisa e permite nova busca }
[i f qtde = 0]: Showmessage()
[i f qtde = 1]: ShowDados()
{informa dados e grava }
GravarDados()
gravarDados()
{permite nova busca }
[i f gravouDados]: LimparDados()
Figura 65. Diagrama de Classe de Seqüência da UC 02.06 � Cadastro de Posicionamento.
110
B Testes
B.1 CHECKLIST DO TESTE DE INTEGRAÇÃO
A seguir são relacionados todos os testes de integração realizados no sistema. Foi criado um
checklist para cada funcionalidade ou rotina, testando assim a integração com o Sistema Modall e a
conformidade com os requisitos da solução móvel.
PTI
Realizar entrada de contêiner Não reefer no TM;
Realizar PTI na solução Móvel: Sistema não deve permitir;
Realizar Entrada de contêiner Reefer no TM;
Realizar PTI na Solução Móvel com o Status �DM�: Sistema deve permitir;
Realizar Consulta do Contêiner na Solução Móvel: Status PTI deve ser "PTI DAMAGE" e
Status Maquinário deve ser �Ag. Estimativa�;
Realizar Consulta do Contêiner no TM: Status PTI deve ser "PTI DAMAGE" e Status
Maquinário deve ser �Ag. Estimativa�;
Realizar PTI na Solução Móvel: Sistema deve permitir;
Realizar PTI no TM: Sistema deve mostrar os dois PTIs cadastrados;
Realizar Saída de Contêiner no Módulo Terminal;
Realizar PTI na Solução Móvel: Sistema Não deve permitir;
Realizar Entrada de contêiner Reefer no TM;
Realizar PTI na Solução Móvel com o Status �OK�: Sistema deve permitir;
Realizar Consulta na Solução Móvel com o Status PTI deve ser �PTI OK� e Status
Maquinário deve ser �Disponível�; e
Verificar no TM se os logs das operações foram feitos corretamente.
Posicionamento
Realizar Entrada de contêiner no TM;
111
Realizar Posicionamento na Solução Móvel, alterando local e quadra: Sistema deve permitir;
Realizar Consulta do Contêiner na Solução Móvel: Verificar se local e quadra foram
alterados;
Realizar Consulta do Contêiner no Módulo Terminal: Verificar se local e quadra foram
alterados;
Realizar Saída de contêiner no Módulo Terminal;
Realizar Posicionamento na Solução Móvel: Sistema Não deve permitir; e
Verificar no TM se os logs das operações foram feitos corretamente.
Manutenção
Realizar a Manutenção de contêiner na Solução Móvel, alterar todos os campos;
Realizar a Manutenção novamente na solução móvel, verificar se os campos foram
alterados;
Realizar a Manutenção no TM, verificar se foram alterados; e
Verificar no TM se os logs das operações foram feitos corretamente.
Consulta
Realizar Entrada de contêiner no TM;
Realizar Vistoria na Solução Móvel;
Realizar Estimativa na Solução Móvel;
Realizar Autorização de Reparo e Reparo na Solução Móvel;
Realizar Saída no Módulo Terminal; e
Realizar a Consulta do Tracking na Solução Móvel: devem aparecer os movimentos de
Entrada, Vistoria, Estimativa, Autorização de Reparo, Reparo e Saída do contêiner. Nos
outros campos, verificar: No Pátio deve ser Não; Dias no Pátio deve ser 1 Dia, Data de
Entrada deve ser a atual; e Status Atual deve ser Fora do Pátio.
112
Estimativa
Realizar Entrada de contêiner no Módulo Terminal;
Realizar Estimativa Solução Móvel: Sistema Não deve permitir, pois não tem vistoria;
Realizar Vistoria na Solução Móvel: Sistema deve permitir;
Realizar Estimativa Solução Móvel: Sistema deve permitir digitar vários itens;
Realizar a Baixa da Estimativa no Módulo Terminal;
Realizar Consulta do Contêiner na Solução Móvel: Status deve ser "Ag. Autor. Reparo";
Realizar Consulta do Contêiner no Módulo Terminal: Status deve ser "Ag. Autor. Reparo";
Realizar a Autorização e o Reparo no módulo Terminal;
Realizar Estimativa na Solução Móvel: Sistema Não deve permitir;
Realizar Saída de contêiner no TM; e
Verificar no TM se os logs das operações foram feitas corretamente.
B.2 TESTES DE USABILIDADE
B.2.1 Ensaio de Interação
A lista a seguir apresenta o ensaio de interação aplicado aos usuários:
1. Cadastre um contêiner do tipo Reefer no TM e não faça vistoria;
2. Faça a vistoria "DM" no dispositivo;
3. Verifique o status atual do contêiner no dispositivo;
4. Cadastre um PTI para o contêiner no dispositivo;
5. Troque a posição do contêiner, alterado o Local e a Quadra;
6. Mude a situação do contêiner para "AGP - aguardando pintura";
7. Exclua o item do PTI cadastrado; e
8. Verifique a data da vistoria do contêiner.
113
B.2.2 Questionário
O questionário devia ser respondido a cada passo dado no ensaio de interação.
1 - O tamanho dos campos de exibição de dados/tela estão adequadas? Sim Não, justifique 2 - Os rótulos mostram aquilo que significam? Sim Não, justifique 3 - O uso de abreviaturas confunde? Sim Não, justifique 4 - As mensagens de erro e aviso são claras, mostrando o que esta acontecendo? Sim Não, justifique 5 - As telas estão poluídas, com dados demais e que podem confundir o usuário? Sim Não, justifique 6 - O sistema mostra claramente quais os passos que o usuário deve dar para executar uma
tarefa/ação? Sim Não, justifique 7- O uso do teclado do dispositivo é adequado? Sim Não, justifique 8 - Com relação ao uso em geral, qual a maior dificuldade encontrada? Justifique
114
ANEXOS
TERMINAL COLETOR DE DADOR CPT 9500 (WINDOWS)
Terminal Coletor de dados CPT 9500 (Windows) Coletor de dados CPT9500 (Windows)
Terminal Coletor de Dados CPT 9500 O CPT 9500 possui display colorido touch screen de 3,5 polegadas e utiliza Windows. Com as conexões de ultima geração, este modelo obtêm um ótimo desempenho em trabalhos que necessitam uma grande mobilidade. O CPT 9500 foi desenvolvido para suportar ambientes hostis a um coletor de dados comum, ele é
resistente a quedas de até 1,5 em concreto, além de estar na norma de proteção IP94, que especifica
imunidade contra poeira e contra respingos e projeções de água.
Especificações Alimentação: Bateria : LiIon 3,7 V, 4000 mAh recarregável Bateria de Backup : Suporta até 30 minutos sem a bateria principal Tempo de carga: Menos de 4 horas para a bateria principal ter carga total Adaptador: AC 110V/220V, saída de 6VDC/3.3A (via berço) Dimensões: Tamanho: 226 mm(C) x 89 mm (L) x 56 mm (A) Peso: Aproximadamente 600g Características Gerais CPU: Processador Intel XScale PXA 255 de 400 Mhz Sistema Operacional: Microsoft Pocket PC 2003 2ª Edição Memória: 128 MB de Flash ROM, 64 MB SDRAM Display: 3,5"(240x320); TFT transreflectivo colorido, LED backlight, Painel touch screen Teclado: 27 teclas com LED backlight Comunicação: Bluetooth Classe 2, Combo com RF 802.11b Opcional GSM 900/1800/1900 tri-band GPRS (CF I/F) Características Ambientais: Temperatura de Operação : -10°C a 50°C Umidade: 5% a 95% (sem condensação)
116
Resistência ao choque : 1.5m quedas múltiplas sobre superfície de concreto Índice de Proteção: IP64 (imunidade contra poeira e contra respingos e projeções d´água) Regulamentação na norma EMC: FCC, CE, C-Tick aprovado Regulamentação na norma ESD: 8 KVDC, contato Programação Linguagens: Visual C++ embedded, Visual Tools embedded, Visual Studio.NET Acessórios Berço de Carga & Comunicação USB Base seguradora móvel de padrão Pistola Carregador com 4 slots de carga
