universidade regional de blumenaupericas/orientacoes/monitorprocessos... · 2011. 12. 2. · erros...
TRANSCRIPT
UNIVERSIDADE REGIONAL DE BLUMENAU
CENTRO DE CIÊNCIAS EXATAS E NATURAIS
CURSO DE CIÊNCIA DA COMPUTAÇÃO – BACHARELADO
ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE
PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO
WEB SERVICES
LEONARDO BROILO JUNIOR
BLUMENAU
2011
2011/2-15
LEONARDO BROILO JUNIOR
ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE
PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO
WEB SERVICES
Trabalho de Conclusão de Curso submetido à
Universidade Regional de Blumenau para a
obtenção dos créditos na disciplina Trabalho
de Conclusão de Curso II do curso de Ciência
da Computação — Bacharelado.
Prof. Francisco Adell Péricas, Mestre - Orientador
BLUMENAU
2011
2011/2-15
ECON: MONITORAMENTO DE EVENTOS DE CADEIAS DE
PROCESSOS PRODUTIVOS AUTOMOTIVOS UTILIZANDO
WEB SERVICES
Por
LEONARDO BROILO JUNIOR
Trabalho aprovado para obtenção dos créditos
na disciplina de Trabalho de Conclusão de
Curso II, pela banca examinadora formada
por:
______________________________________________________
Presidente: Prof. Francisco Adell Péricas, Mestre – Orientador, FURB
______________________________________________________
Membro: Prof. Paulo Fernando da Silva, Mestre – FURB
______________________________________________________
Membro: Prof. Oscar Dalfovo, Doutor – FURB
Blumenau, 01 de dezembro de 2011
Dedico este trabalho aos meus pais, Leonardo
e Deise, irmãos, namorada e todos os amigos,
especialmente aqueles que me ajudaram
diretamente na realização deste.
AGRADECIMENTOS
Aos meus pais, por acreditarem na minha capacidade e investirem no meu potencial.
À minha família, pelo constante apoio durante a realização deste trabalho.
À minha namorada, pela motivação e compreensão nos momentos difíceis.
Ao meu orientador, Francisco Adell Péricas, por apoiar minha idéia e ter acreditado na
conclusão deste trabalho.
Aos meus colegas, que deram sugestões e apoio na realização deste trabalho.
À T-Systems do Brasil pelo apoio concedido.
A todos que contribuíram direta ou indiretamente para a realização deste trabalho.
Mais que de máquinas, precisamos de
humanidade.
Charles Chaplin
RESUMO
Este trabalho apresenta a especificação e o desenvolvimento de um sistema de monitoramento
de processos produtivos de um sistema de planejamento e controle de produção automotiva
utilizando Web Services. O módulo servidor, o módulo cliente e o Web Service foram
desenvolvidos utilizando a linguagem Java. Através do módulo cliente é possível monitorar os
erros que ocorrem nos processos produtivos de montadoras de automóveis. O módulo servidor
mantém uma base de dados centralizada e gerencia a troca de informações entre os servidores
das fábricas e os módulos clientes ativos.
Palavras-chave: Monitoramento. Planejamento e controle de produção. Cadeia de processos.
Web services. SOAP.
ABSTRACT
This work presents the specification and development of a system for monitoring productive
processes from automotive production planning and control systems using Web Services. The
server module, the client module and the Web service were developed using the Java
programming language. Through the client module it is possible to monitor errors that occur
in production processes of automobile manufacturers. The server module maintains a
centralized database and manages the exchange of information between the plant's productive
servers and active clients.
Key-words: Monitoring. Production planning and control. Process chain. Web services.
SOAP.
LISTA DE ILUSTRAÇÕES
Figura 1 - Atividades básicas do PCP ...................................................................................... 17
Quadro 1 - Exemplo simples de uma cadeia de processos no arquivo de configuração .......... 22
Quadro 2 - Linhas do log que evidenciam erros nos processos................................................ 22
Quadro 3 - Exemplos da descrição de erros ............................................................................. 23
Figura 2 - Integração dos serviços de TI aos recursos e estratégias de negócio ....................... 24
Figura 3 - Perguntas para estabelecer uma visão incluindo métricas, metas e objetivo ........... 25
Figura 4 - Aplicação cliente acessando diretamente um Web Service ..................................... 26
Figura 5 - Arquitetura dos Web Services .................................................................................. 27
Quadro 4 - Exemplo de arquivo XML representando um número de telefone ........................ 28
Figura 6 - Estrutura da mensagem SOAP ................................................................................. 29
Quadro 5 - Exemplo de um envelope SOAP enviado em uma requisição HTTP .................... 29
Figura 7 - Principais elementos de um documento WSDL ...................................................... 30
Quadro 6 - Principais namespaces de um documento WSDL.................................................. 31
Figura 8 - Casos de uso do módulo servidor ............................................................................ 34
Quadro 7 - Caso de uso 05 ....................................................................................................... 35
Quadro 8 - Caso de uso 06 ....................................................................................................... 35
Quadro 9 - Caso de uso 07 ....................................................................................................... 35
Quadro 10 - Caso de uso 08 ..................................................................................................... 36
Quadro 11 - Caso de uso 09 ..................................................................................................... 36
Figura 9 - Casos de uso do módulo cliente ............................................................................... 36
Quadro 12 - Caso de uso 10 ..................................................................................................... 37
Quadro 13 - Caso de uso 11 ..................................................................................................... 37
Quadro 14 - Caso de uso 13 ..................................................................................................... 37
Quadro 15 - Caso de uso 14 ..................................................................................................... 38
Quadro 16 - Definição dos pacotes do módulo servidor .......................................................... 39
Figura 10 - Pacote econserver.ui..................................................................................... 39
Figura 11 - Pacote econserver.db..................................................................................... 40
Figura 12 - Pacote econserver.rmi .................................................................................. 41
Figura 13 - Pacote econaxisws ............................................................................................ 41
Quadro 17 - Definição dos pacotes do módulo cliente ............................................................. 42
Figura 14 - Pacote econclientmonitor.ui .................................................................... 42
Figura 15 - Pacote econclientmonitor.util.telegram ......................................... 43
Figura 16 - Pacote econclientmonitor.rmi ................................................................. 44
Figura 17 - Diagrama de atividades do módulo servidor ......................................................... 45
Figura 18 - Diagrama de atividades do módulo cliente ............................................................ 46
Figura 19 - MER do banco de dados ........................................................................................ 47
Quadro 18 – Classe econWS ................................................................................................... 49
Quadro 19 – Procedimento do script PERL e definição do endereço do arquivo WSDL ....... 50
Quadro 20 - Método run da thread ThreadListenMessagesFromWS .......................... 51
Figura 20 - Tela principal do módulo servidor ......................................................................... 52
Quadro 21 - Estrutura da barra de ferramentas......................................................................... 52
Quadro 22 - Estrutura de menus ............................................................................................... 53
Figura 21 - Tela de manutenção de fábricas ............................................................................. 53
Figura 22 - Tela para cadastro de nova fábrica ........................................................................ 53
Figura 23 - Tela de manutenção de servidores ......................................................................... 54
Figura 24 - Tela para cadastro de novo servidor ...................................................................... 54
Figura 25 - Tela de manutenção de instâncias .......................................................................... 55
Figura 26 - Tela para cadastro de nova instância ..................................................................... 55
Figura 27 - Tela de manutenção de usuários ............................................................................ 56
Figura 28 - Tela para cadastro de novo usuário........................................................................ 56
Figura 29 - Tela de manutenção da associação de usuários e fábricas ..................................... 57
Figura 30 - Tela de autenticação do módulo cliente ................................................................. 58
Figura 31 - Tela principal do módulo cliente ........................................................................... 58
Figura 32 - Aba de monitoramento de mensagens críticas ....................................................... 59
Figura 33 - Tela de visualização de mensagens críticas ........................................................... 60
Figura 34 - Tela de visualização dos possíveis erros ............................................................... 61
Figura 35 - Tela de relatório de erros ....................................................................................... 61
Figura 36 - Tela do simulador de mensagens ........................................................................... 62
Quadro 23 - Exemplo de um arquivo com mensagens de erro ................................................. 63
Quadro 24 - Comparativo com trabalhos correlatos ................................................................. 64
Quadro 25 - Arquivo WSDL .................................................................................................... 72
Quadro 26 - Laço principal do script PERL ............................................................................. 74
Figura 37 - Autorização da T-Systems do Brasil ..................................................................... 75
LISTA DE SIGLAS
AIX – Advanced Interactive eXecutive
AMS – Application Management Service
CS3 – Communication System 3
EM – Event Manager
ERP - Enterprise Resource Planning
HTTP – HyperText Transfer Protocol
IBM – International Business Machine
JIT - Just In Time
MER – Modelo Entidade Relacional
MRP - Material Requirement Planning
MRP II - Manufacturing Resource Planning
OPT - Optimized Production Technology
P2P – Peer To Peer
PCP - Planejamento e Controle de Produção
PERL – Practical Extraction and Report Language
RMI - Remote Method Invocation
SGBD – Sistema Gerenciador de Banco de Dados
SOAP - Sample Object Access Protocol
TI – Tecnologia da Informação
UML – Unified Modeling Language
W3C – World Wide Web Consortium
WSDL – Web Services Definition Language
XML - eXtensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................................. 13
1.1 OBJETIVOS DO TRABALHO ........................................................................................ 14
1.2 ESTRUTURA DO TRABALHO ...................................................................................... 15
2 FUNDAMENTAÇÃO TEÓRICA .................................................................................... 16
2.1 PLANEJAMENTO E CONTROLE DE PRODUÇÃO .................................................... 16
2.1.1 Atividades do planejamento e controle da produção ...................................................... 17
2.1.2 Conceitos e características dos sistemas produtivos ....................................................... 18
2.1.2.1 MRP – Planejamento das necessidades de materiais .................................................... 18
2.1.2.2 Just In Time (JIT) .......................................................................................................... 19
2.1.2.3 OPT – Tecnologia de produção otimizada ................................................................... 20
2.1.3 Sistema de planejamento e controle de produção do grupo ............................................ 21
2.1.3.1 Cadeia de processos ...................................................................................................... 21
2.1.3.2 Detecção de erros de processos .................................................................................... 22
2.2 GERENCIAMENTO DE SERVIÇOS DE TI ................................................................... 23
2.3 WEB SERVICES .............................................................................................................. 25
2.3.1 Arquitetura ...................................................................................................................... 26
2.3.2 XML ................................................................................................................................ 27
2.3.3 SOAP .............................................................................................................................. 28
2.3.4 WSDL ............................................................................................................................. 29
2.4 TRABALHOS CORRELATOS ........................................................................................ 31
3 DESENVOLVIMENTO .................................................................................................... 33
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO ....................... 33
3.2 ESPECIFICAÇÃO ............................................................................................................ 34
3.2.1 Diagrama de casos de uso ............................................................................................... 34
3.2.1.1 Módulo servidor ............................................................................................................ 34
3.2.1.2 Módulo cliente .............................................................................................................. 36
3.2.2 Diagrama de classes ........................................................................................................ 38
3.2.2.1 Módulo servidor ............................................................................................................ 38
3.2.2.2 Módulo Cliente. ............................................................................................................ 42
3.2.3 Diagrama de atividades ................................................................................................... 44
3.2.4 Modelo Entidade Relacional (MER) ............................................................................... 47
3.3 IMPLEMENTAÇÃO ........................................................................................................ 48
3.3.1 Técnicas e ferramentas utilizadas.................................................................................... 48
3.3.2 Implementação do sistema .............................................................................................. 48
3.3.3 Operacionalidade da implementação .............................................................................. 51
3.3.3.1 Módulo Servidor ........................................................................................................... 52
3.3.3.2 Módulo Cliente ............................................................................................................. 57
3.3.3.3 Simulador de mensagens .............................................................................................. 61
3.4 RESULTADOS E DISCUSSÃO ...................................................................................... 63
4 CONCLUSÕES .................................................................................................................. 65
4.1 EXTENSÕES .................................................................................................................... 66
REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 67
APÊNDICE A – Arquivo econ.wsdl ................................................................................. 70
APÊNDICE B – Laço principal do script PERL .................................................................. 73
ANEXO A – Autorização da T-Systems do Brasil............................................................... 75
13
1 INTRODUÇÃO
Frente às mudanças constantes na área da Tecnologia da Informação (TI) e ao aumento
na concorrência desta área, surge a necessidade de que as organizações sejam inteligentes e
que se modifiquem, o que requer um melhor planejamento de suas informações, de seu
conhecimento e de sua tecnologia da informação. Levando isso em consideração pode-se
chegar à conclusão de que as empresas lidam a cada dia com mais dados, os quais precisam
ser devidamente trabalhados para que possam agregar algum valor à organização a fim de
gerar conhecimento sempre que necessário (REZENDE, 2003, p. 39).
A empresa T-Systems do Brasil é uma destas organizações que se atualiza
frequentemente para continuar em uma posição destacada perante o mercado nacional e
internacional (T-SYSTEMS, 2011). Dentre os projetos de suporte e sustentação existentes na
empresa, um deles visa prestar suporte ao sistema de planejamento e controle que gerencia a
linha de produção das fábricas de um grupo de montadoras de automóveis. Denominado de
projeto de suporte Application Management Services (AMS), utiliza os conceitos de boas
práticas em gerenciamento de serviços de tecnologia da informação para garantir a satisfação
do cliente.
A equipe AMS é responsável por gerenciar e suportar os recursos e serviços do sistema
de planejamento e controle utilizado pela área de Planejamento e Controle da Produção (PCP)
dos clientes aos quais presta serviço. O bom funcionamento do sistema e a qualidade do
serviço prestado dependem de uma estratégia de monitoramento eficiente. É através deste
sistema que a área de PCP tem controle total sobre os produtos que estão sendo produzidos.
Hoje, esta equipe presta suporte ao sistema planejamento e controle de produção de doze
fábricas deste grupo em países como Brasil, Inglaterra, Índia, China, África do Sul, Argentina
e Espanha.
Dentro deste contexto, ferramentas que ajudem os analistas e técnicos no controle dos
processos produtivos do cliente, seja na coleta de informações, no monitoramento ou na
execução de tarefas automatizadas, são de suma importância para o ganho de produtividade e
a garantia da qualidade do serviço.
O presente trabalho possibilitará aos técnicos e analistas da empresa T-Systems do
Brasil aperfeiçoar o trabalho de monitoramento e controle dos eventos e dos processos
produtivos ativos nos servidores de todas estas doze fábricas. Para tal, foi desenvolvido um
módulo a ser executado no servidor, que disponibiliza serviços através de Web Services, e um
14
módulo a ser executado nos clientes, ambos utilizando a linguagem de programação Java e
rodando no sistema operacional Windows. Também foi desenvolvido um script utilizando a
linguagem de programação Practical Extraction and Report Language (PERL), para rodar
nos servidores produtivos das fábricas com sistema operacional Advanced Interactive
eXecutive (AIX), da International Business Machines (IBM), e que alimenta a base de dados
utilizada pelo servidor e pelos clientes ativos.
Segundo Albinader Neto e Lins (2006), a tecnologia dos Web Services pode fazer com
que dados sejam transmitidos entre várias entidades, desde que a semântica possa ser
transformada em informação útil para as entidades envolvidas. Esta tecnologia permite que
sistemas desenvolvidos em plataformas diferentes sejam compatíveis, enviando e recebendo
dados em formato padrão eXtensible Markup Language (XML). O protocolo básico para a
comunicação entre duas partes é o Sample Object Access Protocol (SOAP) (ALBINADER
NETO; LINS, 2006, p. 78). O SOAP é um protocolo utilizado para a troca de informações
estruturadas em uma plataforma distribuída e descentralizada.
A integração dos dados quando não se trabalha com Web Services apresenta-se como
um desafio complexo quando estes estão situados em entidades, plataformas e sistemas
diferentes (ALBINADER NETO; LINS, 2006, p. 8). Neste sentido, o desenvolvimento de
aplicações distribuídas e de serviços que utilizam Web Services torna-se relevante por se
adequarem a uma arquitetura com plataformas, linguagens e sistemas diferentes.
Este trabalho apresenta uma forma descentralizada de monitoramento dos processos
produtivos ativos nos servidores através de Web Services permitindo vários clientes
simultâneos avaliar continuamente de qualquer lugar o estado destes processos, garantindo a
qualidade do serviço de suporte e sustentação do sistema oferecido pela equipe da T-Systems,
que autorizou o uso de algumas informações conforme anexo A.
1.1 OBJETIVOS DO TRABALHO
O objetivo deste trabalho é disponibilizar uma ferramenta que, com o auxílio de Web
Services, seja capaz de receber, gerenciar e transmitir aos clientes ativos informações do
processo produtivo dos servidores produtivos da rede de um grupo de montadoras de veículos
para facilitar e otimizar seu processo de monitoramento.
Os objetivos específicos do trabalho são:
15
a) disponibilizar um módulo a ser executado no servidor, que faz a gerência do
sistema e disponibiliza os Web Services, e um módulo cliente que será executado
nos computadores de monitoramento;
b) centralizar informações coletadas dos servidores produtivos das fábricas no
módulo servidor;
c) proporcionar aos analistas e técnicos uma melhor qualidade do serviço prestado e
uma maior produtividade na detecção de erros durante o processo produtivo de
veículos.
1.2 ESTRUTURA DO TRABALHO
Este trabalho está estruturado em quatro capítulos. O segundo capítulo contém a
fundamentação teórica necessária para o desenvolvimento do trabalho. Nele são abordados
assuntos relacionados ao processo produtivo e planejamento e controle de produção, ao
gerenciamento de serviços de TI e ao funcionamento da tecnologia de Web Services e os
padrões que integram parte desta tecnologia. Por último, são apresentados quatro trabalhos
correlatos.
No terceiro capítulo são detalhados os passos do desenvolvimento da ferramenta,
intitulada eCon, onde são relacionados seus requisitos, bem como explicada a especificação
contendo diagramas de casos de uso, de classe, de atividades e a modelagem do banco de
dados. Também são feitos comentários sobre a implementação abrangendo ferramentas
utilizadas, técnicas, operacionalidade e, por fim, são discutidos os resultados obtidos.
O quarto capítulo refere-se às conclusões do presente trabalho e sugestões para
trabalhos futuros.
16
2 FUNDAMENTAÇÃO TEÓRICA
Neste capítulo, aspectos teóricos relacionados ao desenvolvimento e entendimento do
trabalho serão apresentados. Por primeiro, são abordados os temas PCP, sistema de
planejamento e controle de produção e gerenciamento de serviços de TI. Após serão
abordados temas como Web Services, XML, a tecnologia SOAP e a linguagem Web Service
Definition Language (WSDL). Por fim são apresentados trabalhos correlatos com
características semelhantes ao trabalho proposto.
2.1 PLANEJAMENTO E CONTROLE DE PRODUÇÃO
Segundo Vollmann et al. (2005, p. 25), o sistema de PCP ocupa-se do planejamento e
controle de todos os aspectos da produção, inclusive do gerenciamento de materiais e da
programação de máquinas e pessoas e da coordenação de fornecedores e clientes-chave.
A tarefa essencial do sistema de PCP é gerenciar com eficiência o fluxo de material,
a utilização de pessoas e equipamentos e responder às necessidades do cliente
utilizando a capacidade dos fornecedores, da estrutura interna e, em alguns casos,
dos clientes para atender à demanda do cliente. [...] O sistema de PCP não toma
decisões nem gerencia operações – os gerentes desempenham essas atividades. O
sistema de PCP dá o suporte para que eles o façam de maneira sábia. (VOLLMANN
et al., 2005, p. 28).
Os sistemas de PCP realmente eficazes coordenam cadeias de suprimento, ou supply
chain. Segundo Supply-Chain Council (2011), supply chain é todo esforço envolvido nos
processos e atividades empresariais que criam valor na forma de produtos e serviços para o
consumidor final, sendo também uma forma integrada de planejar e controlar o fluxo das
mercadorias. Sendo assim, engloba todos os esforços empenhados na elaboração e na
distribuição de um produto ou serviço, desde o primeiro fornecedor até o consumidor final.
Vários termos são frequentemente utilizados para tratar o mesmo assunto. Gestão da
produção, gerenciamento da produção, administração da produção e planejamento e controle
da produção são alguns destes termos (PIRES, 1995, p. 119).
A seguir são apresentadas as principais atividades de PCP, conceitos e principais
características dos sistemas produtivos.
17
2.1.1 Atividades do planejamento e controle da produção
Independentemente do sistema produtivo e abordagem utilizada pelo PCP, existem
algumas atividades que são tradicionalmente peculiares à sua realização. Isto significa que,
em um nível de complexidade variável, estas atividades, representadas na Figura 1, sempre se
farão necessárias (PIRES, 1995, p. 136).
Fonte: adaptado de Pires (1995, p. 137).
Figura 1 - Atividades básicas do PCP
Na previsão de vendas, o planejamento inicia-se com os dados fornecidos pela área de
vendas. Esses dados dizem respeito ao que produzir, em quais quantidades e em que prazo.
O planejamento agregado da produção consiste no estabelecimento dos níveis gerais de
capacidade e produção para um período de médio e longo prazo. Este planejamento é feito em
termos de famílias de itens e os produtos a serem produzidos não são definidos de forma
individual e especificada, mas são agregados formando famílias de itens semelhantes.
O programa mestre de produção é um referencial básico para a produção, e estabelece
quando e em que quantidade cada produto deverá ser produzido dentro de um certo horizonte
de planejamento. Geralmente é nesta etapa onde verificações mais detalhadas da capacidade
podem nivelar a produção por restrições organizacionais e econômicas.
O planejamento das necessidades materiais calcula as chamadas necessidades líquidas
para cada produto a ser produzido. Estas necessidades são calculadas com base nas
necessidades brutas vindas da lista de materiais, pelas exigências impostas pelo programa
18
mestre e pelas informações do controle de estoque, considerando itens em estoque e itens em
processo de fabricação ou compra.
O controle de estoques trata basicamente do controle sobre todos os itens fabricados,
comprados e utilizados para a produção de seus produtos. Este controle visa maximizar o
nível de atendimento aos clientes e a produção da indústria e minimizar os investimentos em
estoques.
A programação da produção determina os prazos de entrega para os itens definidos. As
restrições para esta tarefa são impostas pela capacidade disponível do centro produtivo para o
período em questão, bem como pelas exigências tecnológicas colocadas nos roteiros de
produção.
O planejamento e controle da capacidade estipula quais devem ser os níveis de
produção máximos que os centros produtivos devem ter em um certo horizonte de
planejamento. Cuida das informações a serem utilizadas por outras atividades do PCP e das
providências para que a capacidade planejada seja realizada.
O controle da produção consiste em acompanhar a fabricação e compra dos itens
programados com o objetivo de que os prazos sejam cumpridos. O controle da produção
também atua coletando dados importantes para o sistema de custos, tomando decisões típicas
de chão de fábrica e alimentando informações ao controle de estoques.
2.1.2 Conceitos e características dos sistemas produtivos
As atividades de planejamento e controle de produção podem ser implementadas e
operacionalizadas seguindo algumas das abordagens de PCP. Neste tópico serão brevemente
descritas três destas abordagens, que são o Material Requirement Planning (MRP), o Just In
Time (JIT) e a Optimized Production Technology (OPT).
2.1.2.1 MRP – Planejamento das necessidades de materiais
O termo MRP surgiu na década de 1960 com o objetivo de executar
computacionalmente a atividade de planejamento das necessidades de materiais, permitindo
assim determinar as prioridades das ordens de compra e fabricação precisa e rapidamente.
Na década de 70 este sistema, que executava o cálculo das necessidades materiais,
19
evoluiu paralelamente ao desenvolvimento da informática, surgindo um sistema
computacional com o pretensioso objetivo de realizar todas as principais atividades do PCP
(PIRES, 1995, p. 143). Este novo sistema passou a se chamar Manufacturing Resource
Planning (MRP II).
O MRP II pode ser descrito como um sistema hierárquico de gestão da produção, em
que os planos de longo prazo são sucessivamente detalhados até se chegar ao nível do
planejamento de componentes e máquinas (CORREA; GIANESI, 1993, p. 116).
Outros módulos começaram a ser acrescidos nos sistemas MRP II, como o módulo de
compras e o módulo financeiro. Estes sistemas integrados passaram a ser chamados de
Enterprise Resource Planning (ERP) e são capazes de atender a necessidade de diversas áreas
das empresas, apoiando a tomada de decisões de outros setores e não apenas aqueles ligados à
manufatura, a partir de uma base de dados central e não redundante. (CORREA; GIANESI;
CAON, 1997, p. 343).
2.1.2.2 Just In Time (JIT)
O princípio básico da filosofia JIT, no que diz respeito a produção, é atender de forma
rápida e flexível à variada demanda do mercado, produzindo geralmente em lotes pequenos. O
planejamento e programação da produção dentro do contexto desta filosofia procura adequar a
demanda esperada às possibilidades do sistema produtivo. Este objetivo é alcançado através
da utilização da técnica de produção nivelada.
Segundo Correa e Gianesi (1993, p. 88), a utilização do conceito de produção nivelada
envolve duas fases, a programação mensal e a programação diária da produção. Através do
conceito de produção nivelada, as linhas de produção podem produzir vários produtos
diferentes a cada dia, de acordo com a demanda do mercado. Para isto, é fundamental que se
busque a redução dos tempos envolvidos nos processos.
A filosofia JIT coloca a ênfase da gerência no fluxo de produção fazendo com que os
produtos fluam de forma contínua através das fases do processo de produção. A principal
ênfase do JIT para as linhas de produção é a flexibilidade. Espera-se que a produção esteja
ajustada às variações da demanda, sendo balanceadas muitas vezes.
A busca pela flexibilidade e pela redução dos tempos de preparação de equipamentos
reflete-se na ênfase dada à produção de modelos mesclados de produtos, permitindo uma
produção adaptável às mudanças de curto prazo e obtendo ganhos de produtividade.
20
2.1.2.3 OPT – Tecnologia de produção otimizada
A OPT pode ser apresentada como uma abordagem de gestão de produção orientada
por gargalos produtivos e baseada em uma técnica de programação da produção que utiliza
um software específico.
Os gargalos da produção são os recursos produtivos sobre os quais a demanda imposta
é maior que a sua capacidade de processamento. Os recursos anteriores ao gargalo são
puxados, na chamada programação para trás, e os recursos posteriores são empurrados, na
chamada programação para frente, de acordo com as saídas do gargalo.
Segundo Correa e Gianesi (1993, p. 163), a filosofia da OPT é baseada em 9
princípios:
a) balancear o fluxo e não a capacidade;
b) o nível de utilização de um recurso não gargalo não é determinada por sua
disponibilidade, mas por alguma outra restrição do sistema;
c) utilização e ativação de um recurso não são sinônimos;
d) uma hora ganha em um recurso gargalo é uma hora ganha para o sistema como um
todo;
e) uma hora ganha em um recurso não gargalo não é nada, apenas uma ilusão;
f) o lote de transferência pode não ser, e não deveria ser, igual ao lote de
processamento;
g) o lote de processamento deve ser variável e não fixo;
h) os gargalos governam o volume de produção e o volume de estoques;
i) a programação das atividades e a capacidade produtiva devem ser consideradas
simultaneamente e não sequencialmente. O lead time é resultado da programação e
não pode ser predeterminado.
Segundo Correa e Gianesi (1993, p. 158), o software OPT é composto de quatro
módulos. A OPT programa os Recursos Restritivos Críticos (RRC) com uma lógica de
programação finita para frente. O Buildnet cria e mantém a base de dados atualizada. O Serve
ordena os pedidos de utilização de recursos e programa os recursos não gargalos. O Split que
separa os recursos em gargalos e não gargalos.
A OPT tem-se mostrado capaz de reduzir o lead time em até 30% e o estoque na ordem
de 40 a 75% (CORREA; GIANESI, 1993, p. 164). Um fato desfavorável é que o algoritmo
não é público e cria uma dependência da empresa usuária com apenas um fornecedor do
21
sistema. Outra questão é que ela não possui nenhuma forma de retroalimentação do sistema
em função do que realmente ocorre no chão de fábrica, dificultando as funções de controle de
produção.
2.1.3 Sistema de planejamento e controle de produção do grupo
O sistema de planejamento e controle de produção utilizado pelo grupo de montadoras
de veículos é responsável por gerenciar toda linha de produção. Uma linha de produção é ―um
conjunto de estações de trabalho seqüencialmente dispostas, normalmente interligadas por um
sistema contínuo de movimentação de materiais, e projetada para montar componentes e
realizar qualquer operação necessária à obtenção de um produto acabado.‖ (ASKIN;
STANDRIDGE, 1993, p. 19). Neste caso o sistema gerencia desde a armação da carroceria
(onde as chapas de aço são soldadas), passando pela pintura até chegar à montagem final onde
acontece a montagem da carroceria e do chassi e são feitos os testes de qualidade.
Ele é dividido em módulos, que são responsáveis por gerenciar diferentes partes do
processo produtivo como, por exemplo, o depósito de carrocerias, os fornecedores, o
sequenciamento de peças na linha de montagem, a qualidade assegurada e a disponibilização
de veículos para serem produzidos. Estes módulos estão instalados em servidores da IBM
com sistemas operacionais IBM AIX, e cada módulo roda dentro de uma instância de um
middleware chamado Communication System 3 (CS3), desenvolvido pela T-Systems do
Brasil. Este middleware nada mais é do que um ambiente para aplicações distribuídas, o qual
divide um servidor em instâncias lógicas para uma melhor estruturação do sistema. O sistema
de planejamento e controle trabalha com o conceito de cadeia de processos, ou Supply Chain
Management, descrito anteriormente.
2.1.3.1 Cadeia de processos
Para cada instância CS3 que contenha um módulo do sistema há um arquivo de
configuração das cadeias de processos. O Event Manager (EM), ou gerenciador de eventos, é
o programa responsável por disparar estas cadeias e baseia-se neste arquivo para executar as
etapas do processo produtivo, do qual este módulo é responsável. O EM é acionado a cada
nova entrada de dados em algum equipamento que esteja ligado ao sistema de produção. Ele
22
recebe um telegrama com a sigla de identificação da cadeia a ser disparada e com todas as
informações necessárias para a execução dos processos. O Quadro 1 mostra a cadeia de
processos PRRD descrita no arquivo de configuração.
Quadro 1 - Exemplo simples de uma cadeia de processos no arquivo de configuração
O EM aciona sempre o primeiro processo da cadeia. Neste exemplo, o primeiro passo
a ser executado desta cadeia é o PRRD001, que irá acionar o processo INITPRRD. Cada
processo executado responde ao EM um código de retorno 0, 1 ou 2, que no arquivo
correspondem às colunas 4, 5 e 6 respectivamente, sendo 0 quando o processo não responde
até um determinado tempo, 1 quando não há dados no banco de dados correspondentes ao
veículo que disparou a cadeia e 2 quando o processo é executado com sucesso.
O EM se baseará nestes códigos de retorno para verificar qual o próximo processo
deve ser disparado até que esta cadeia se encerre com sucesso ou fracasso.
2.1.3.2 Detecção de erros de processos
Para cada tarefa executada por um processo de uma cadeia são gerados registros num
arquivo de log. Quando os processos respondem negativamente ao EM, são geradas linhas
neste arquivo contendo qual o processo está com problemas, e qual o código de identificação
definido para este tipo de erro. No Quadro 2, um exemplo de algumas linhas deste arquivo de
log que identificam erros.
Quadro 2 - Linhas do log que evidenciam erros nos processos
A descrição dos códigos de erro está definida no ambiente CS3. O Quadro 3 mostra a
descrição de alguns códigos de erros.
23
código do erro descrição do erro
POL0003 Error during sending to EM
POL0005 Timeout after sending telegram
POL0012 error during sending to resource
POL0077 no data in FIS database for KNR '%2'
POL0211 ***** state '%2' of KNR '%3' already exists ! *****
POL0218 FHSTATUS error ! (KNR=%2)
POL0224 ATTENTION! state '%2', KNR '%3': identical seq. No. exists! inserting not
possible
Quadro 3 - Exemplos da descrição de erros
Todos os erros gerados nos logs das instâncias CS3 devem ser analisados e, se
necessário, corrigidos. Estas mensagens com erros serão tratadas pelo script PERL e enviadas
ao Web Service para que os clientes conectados naquele instante tomem conhecimento dos
problemas que estão ocorrendo nas fábricas naquele instante.
2.2 GERENCIAMENTO DE SERVIÇOS DE TI
Com o crescimento da dependência das organizações em relação a TI e com o
crescimento da disponibilidade de informações, cada minuto de indisponibilidade de um
sistema em uma organização de grande porte pode significar um prejuízo da ordem dos
milhares de reais.
Atualmente as áreas de TI não podem mais se preocupar unicamente com questões
tecnológicas. É necessária uma integração com as demais áreas das organizações para que o
gerenciamento de serviços tenha um caráter mais formal e passe a ser visto como um
investimento e não como um custo.
Segundo Dias (2008), ―o gerenciamento do serviço de TI é fundamental para o sucesso
de uma organização pelo simples fato de alinhar pessoas, processos e infra-estrutura, a fim de
fornecer e suportar serviços de TI que possibilitem as funções e atividades do negócio‖. A
necessidade pelo gerenciamento de serviços cresce à medida que os negócios dependem dos
serviços de TI. A Figura 2 mostra que os serviços estão integrados aos recursos e estratégias
do negócio.
24
Fonte: Dias (2008).
Figura 2 - Integração dos serviços de TI aos recursos e estratégias de negócio
Segundo Fabiciack (2009), ―um serviço de TI é um conjunto de recursos da
infraestrura de TI que atendem uma ou mais necessidades dos seus clientes‖. Este conjunto é
considerado pelo cliente como uma solução que apóia a sua função no negócio.
O gerenciamento dos serviços de TI tem por objetivo garantir a entrega de serviços que
satisfaçam os requisitos acordados entre o cliente e o fornecedor, tanto em desempenho
quanto em custo, além de estar alinhado aos objetivos estratégicos da organização
(MAGALHÃES; PINHEIRO, 2007, p. 59).
Segundo Magalhães e Pinheiro (2007, p. 60), para atingir estes objetivos a área de TI
deve:
a) contribuir estrategicamente com o negócio;
b) permitir a mensuração da contribuição para o negócio;
c) realizar a entrega de serviços mais consistentes e estáveis;
d) enfatizar menos a tecnologia.
Para que uma organização de TI possa funcionar como um negócio é preciso traçar
uma visão incluindo objetivos, métricas e metas. Deve-se ter um programa de melhoria
contínua do gerenciamento de serviços e a cada ciclo traçar os objetivos que se espera obter
em determinado prazo, avaliando e adaptando os processos para uma melhor eficácia e
eficiência nos resultados (FABICIACK, 2009).
Para estabelecer um ciclo de evolução constante e uma política de melhoria contínua as
organizações podem se basear em algumas perguntas que poderão orientá-las nas suas
estratégias e objetivos, conforme a Figura 3.
25
Fonte: Fabiciack (2009).
Figura 3 - Perguntas para estabelecer uma visão incluindo métricas, metas e objetivo
2.3 WEB SERVICES
Os Web Services são utilizados para disponibilizar serviços interativos numa rede, com
o objetivo de integração e comunicação entre sistemas distribuídos ou aplicações stand-alone
(CUNHA, 2002).
Um sistema Web Service é implementado para fornecer interoperabilidade entre
hosts em uma determinada rede. Possui uma interface descrita no formato conhecido
como Web Services Definition Language (WSDL). Sistemas interagem com Web
Services usando mensagens SOAP, através do HyperText Transfer Protocol (HTTP)
com uma serialização XML em conjunto com outros padrões relacionados.
(WORLD WIDE WEB CONSORTIUM, 2011).
Interoperabilidade é um dos principais ganhos com a implementação de Web Services.
Segundo Singh (2006, p. 5), talvez esta interoperabilidade seja a razão primordial para o
crescimento do uso de Web Services, pois os sistemas que foram escritos em diferentes
linguagens e operam em plataformas distintas podem trabalhar juntas sem maiores problemas.
Ainda segundo ele, os Web Services reduzem custos operacionais e permitem que as
organizações reutilizem suas funcionalidades de sistemas existentes.
Cunha (2002) explica que ―a aplicação cliente, após localizar o serviço remoto
(definido por um documento WSDL), invoca os seus serviços [...]. O Web Service recebe a
chamada, a processa e envia uma resposta‖. É válido lembrar que cliente e Web Service
conversam usando SOAP sobre HTTP.
26
Fonte: Cunha (2002).
Figura 4 - Aplicação cliente acessando diretamente um Web Service
2.3.1 Arquitetura
O Web Service é baseado na integração de 3 entidades: provedor de serviços (service
provider), cliente do serviço (service consumer) e servidor de registros (service broker ou
service registry). A iteração destas entidades serve para que haja busca, publicação e
execução das operações (CHAPPELL, JEWEL, 2002, p. 14).
O provedor de serviços representa a entidade que hospeda o Web Service. É
considerado o dono do serviço e responsável pela disponibilização do mesmo para utilização.
Este serviço deve estar descrito em um formato padrão para que qualquer um que precise usar
este serviço possa compreendê-lo. O provedor de serviços deve publicar os detalhes dos Web
Services fornecidos por ele em um servidor de registros que esteja disponível.
O cliente do serviço é todo cliente que busca um serviço desejado e inicia a interação
com um provedor de serviços. Este cliente pode ser tanto uma pessoa acessando através de
um navegador quanto uma entidade computacional sem interface com o usuário, como um
outro Web Service por exemplo. O cliente do serviço deve conhecer a interface de
comunicação do Web Service, que é disponibilizada por um provedor e recuperada a partir de
uma pesquisa no servidor de registro.
O servidor de registro representa a busca de registros de serviços baseados em arquivos
de descrição publicados pelos provedores.
A Figura 5 mostra a ligação entre estas três entidades.
27
Figura 5 - Arquitetura dos Web Services
A base para a construção de um Web Service são os padrões XML, que definem os
tipos de dados a serem enviados, e SOAP, responsável pelo encapsulamento destes dados. A
transmissão dos dados é feita via HyperText Transfer Protocol (HTTP). Os métodos dos
serviços são descritos através da linguagem WSDL.
2.3.2 XML
O XML é uma recomendação da World Wide Web Consortium (W3C) para gerar
linguagens de marcação para necessidades especiais. Estas linguagens são um conjunto de
convenções para codificação de textos, que devem especificar quais marcas são permitidas,
quais são exigidas, como distinguí-las entre as marcas e o texto e qual o significado da
marcação (ALMEIDA, 2002).
De acordo com Singh (2006, p. 35), o XML é uma linguagem de marcação baseada em
textos, bastante flexível e simples. Os dados são marcados utilizando, entre colchetes
angulares, as tags, que contém o significado dos dados marcados por elas. Esta marcação
permite que sistemas interpretem facilmente dados enviados por qualquer outro sistema
distinto.
Segundo Marchal (2000, p. 9), o XML pode ser útil em áreas como carga e descarga de
bancos de dados, aplicações de comércio eletrônico e troca de informações entre
organizações.
O Quadro 4 mostra um exemplo de um arquivo XML com marcação de dados com
diferentes representações de um número telefônico, contendo o código de área, o prefixo e o
número do telefone. Um arquivo deste tipo poderia ser facilmente interpretado por diversos
sistemas para a troca de informações entre aplicações distintas.
28
Fonte: Snell, Tidwell e Kulchenko (2002, p. 12).
Quadro 4 - Exemplo de arquivo XML representando um número de telefone
2.3.3 SOAP
O SOAP é um protocolo que permite a dois sistemas, um cliente e um servidor, trocar
dados entre si. Este protocolo foi especificado de modo a ser implementado em uma variedade
de protocolos de transporte, porém ele é mais utilizado sobre o HTTP.
De acordo com Sant’Anna (2002), ―O SOAP é um protocolo elaborado para facilitar a
chamada remota de funções via internet, permitindo que dois programas comuniquem-se de
uma maneira tecnicamente muito semelhante à invocação de páginas Web‖. Por ser elaborado
como um padrão, sua utilização e implementação torna-se mais fácil.
O SOAP é uma especificação complexa e não se deve dizer que se resume apenas à
chamada de funções remotas. O SOAP, dentre suas variadas funções, permite a transmissão
assíncrona de mensagens em uma via, além de permitir serviços web orientado a documentos
(SNELL, TIDWELL, KULCHENKO, 2002, p. 11).
Conforme Seely (2002, p. 43), a especificação do SOAP é dividida em quatro partes
principais:
a) SOAP envelope: define uma plataforma para descrição do que há na mensagem e
como processá-la. É a única parte do protocolo que é obrigatória;
b) SOAP enconding rules: define um mecanismo de serialização que pode ser usado
para a troca de instâncias de tipos definidos pela aplicação;
c) SOAP Remote Procedure Call (RPC) style: define uma convenção que pode ser
usada para representar chamadas e respostas remotas a procedimentos, nada mais
que a dupla requisição/resposta, que não é obrigatória;
d) link SOAP-HTTP: define um protocolo que liga o SOA e o HTTP. Ele descreve
como mensagens SOAP são transmitidas via HTTP.
29
A mensagem SOAP, como demonstrado na Figura 6, consiste num envelope contendo
um cabeçalho opcional e um corpo obrigatório. O cabeçalho contém blocos de informações
relevantes sobre como a mensagem deve ser processada, incluindo rota e entrega,
autenticação ou autorização e contextos de transações. O corpo da mensagem contém a
mensagem atual que será entregue e processada. Tudo o que puder ser expressado em um
arquivo XML poderá estar no corpo da mensagem (SNELL, TIDWELL, KULCHENKO,
2002, p. 13).
Fonte: Snell, Tidwell e Kulchenko (2002, p. 13). Figura 6 - Estrutura da mensagem SOAP
Por ser um padrão XML, o SOAP possui suas próprias marcas para a identificação do
protocolo. No Quadro 5 é apresentado um exemplo de XML criado pelo protocolo SOAP com
uma marca preço, apresentando o último preço de troca de um produto exemplo.
Quadro 5 - Exemplo de um envelope SOAP enviado em uma requisição HTTP
2.3.4 WSDL
O WSDL define um sistema para descrição de serviços. A partir desta linguagem são
descritos os serviços oferecidos por uma determinada aplicação, bem como a sua localização.
Assim como a maioria das tecnologias para Web Services, a especificação do WSDL também
30
é baseada no XML (RECKZIEGEL, 2006b).
Em um documento WSDL existem componentes que formam sua especificação e
definem os parâmetros de um determinado serviço. Mello et al. (2006) define estes
componentes como:
a) types: tipos utilizados no serviço;
b) messages: definem, de forma abstrata, as mensagens que serão trocadas;
c) operations: definem, de forma abstrata, as operações para uma mensagem;
d) port type: descreve um conjunto abstrato de operações mapeadas para um ou mais
serviços, os quais são descritos como pontos finais de rede ou portas;
e) bindings: definem, de forma concreta, como mapear os elementos messages e
operations, nos protocolos de rede que serão utilizados;
f) port: uma combinação entre o elemento binding e o endereço de rede, provendo
um endereço único para acessar um serviço;
g) service: define onde encontrar um serviço usando sua porta.
A Figura 7 mostra os principais elementos de um documento WSDL.
Fonte: Reckziegel (2006a).
Figura 7 - Principais elementos de um documento WSDL
O WSDL utiliza namespaces para aumentar a reutilização dos elementos e
31
componentes definidos em seu documento. Estes namespaces são espaços para nomes
definidos no interior do XML permitindo a unicidade de nomes. Os principais namespaces
utilizados em documentos WSDL estão indicados no Quadro 6.
Prefixo URI do namespace Descrição
WSDL http://schemas.xmlsoap.org/wsdl Namespace de WSDL para framework WSDL
SOAP http://schemas.xmlsoap.org/wsdl/soap Namespace de WSDL para vinculo de SOAP e WSDL
HTTP http://schemas.xmlsoap.org/wsdl/http Namespace de WSDL para WSDL HTTP GET e vínculo POST
MIME http://schemas.xmlsoap.org/wsdl/mime Namespace de WSDL para vínculo MIME de WSDL
XSD http://www.w3.org/2001/XMLShema Namespace do esquema conforme definido pelo esquema de XML
Fonte: adaptado de Reckziegel (2006a).
Quadro 6 - Principais namespaces de um documento WSDL
2.4 TRABALHOS CORRELATOS
A seguir são apresentados trabalhos com características em comum ao trabalho
proposto. Os trabalhos têm características específicas do seu escopo, mas englobam áreas
relacionadas como o uso de Web Services e a necessidade de controlar e monitorar certos
eventos.
Venturi (2005) desenvolveu um protótipo de um sistema para controle e monitoração
residencial à distância através de dispositivos móveis. Os objetivos principais do protótipo
eram controlar e monitorar objetos de uma residência, criar a comunicação da casa com o
dispositivo móvel e desenvolver um simulador de um ambiente residencial. Todas as
informações relevantes ao controle e monitoramento residencial ficam centralizadas no
servidor. Este trabalho foi desenvolvido com o Visual Studio .NET com a linguagem Visual
C# e utilizando Web Services para a comunicação de dados via Internet.
Outro trabalho analisado é o Traffic Monitor (COUTO; GATTAI, 2008). Foram
desenvolvidas uma aplicação para dispositivos móveis e uma aplicação servidora contendo
Web Services e um banco de dados com informações dos dados e das rotas dos usuários. O
objetivo é disponibilizar ao usuário informações sobre o tráfego nas vias ou rotas definidas
pelo usuário no aplicativo para dispositivo móvel. O dispositivo, que deve estar conectado à
internet, requisita informações ao servidor que através de Web Services busca as informações
32
solicitadas e responde ao dispositivo. Os Web Services desenvolvidos buscam informações
nos Web Services disponibilizados pela MapLink, que além das informações sobre o trânsito
nas vias das cidades também disponibiliza imagens de mapas e rotas.
O Ministério do Meio Ambiente (2008) elaborou um sistema de monitoramento por
satélite do desmatamento dos biomas caatinga, cerrado, mata atlântica, pampa e pantanal, com
o intuito de quantificar desmatamentos de áreas de vegetação nativa e de embasar ações de
fiscalização e combate aos desmatamentos ilegais destes biomas. O objetivo do
monitoramento é permitir maior eficiência das políticas públicas voltadas à conservação e uso
sustentável destes biomas e de fiscalização e controle da aplicação da legislação ambiental. O
sistema capta imagens através de satélites e as envia a um servidor central que disponibiliza
Web Services que as processam e distribuem aos clientes da aplicação a informação recebida.
Trojan e Padoin (2008) desenvolveram um sistema para o monitoramento remoto de
servidores em subestações de energia. O objetivo principal do trabalho é possibilitar o
monitoramento remoto das grandezas trabalhadas nas subestações de energia elétrica através
de dispositivos móveis. O sistema utiliza Web Services para receber as informações do banco
de dados que representam a tensão, corrente elétrica, potência aparente, potência ativa e fator
de potência de uma subestação de energia. O aplicativo embarcado no dispositivo móvel
recebe estes dados no padrão SOAP e gera ao usuário gráficos que facilitam o monitoramento
no caso de uma ocorrência de variação elétrica anormal fora dos limites estipulados. Uma
mensagem do tipo Short Message Service (SMS) é enviada ao celular do técnico responsável,
o que torna a tarefa de monitoramento mais flexível e dinâmica.
33
3 DESENVOLVIMENTO
Neste capítulo são detalhadas as etapas do desenvolvimento da ferramenta. São
apresentados os principais requisitos, a especificação, a implementação e por fim são listados
resultados e discussão.
3.1 REQUISITOS PRINCIPAIS DO PROBLEMA A SER TRABALHADO
A ferramenta foi desenvolvida tendo em vista os seguintes requisitos:
a) enviar dados coletados aos Web Services através de um script escrito na
linguagem PERL que ficará residente nos servidores produtivos que serão
monitorados (Requisito Funcional - RF);
b) permitir, no módulo servidor, o cadastro e manutenção dos usuários (RF);
c) permitir, no módulo servidor, o cadastro das fábricas, dos servidores e das
instâncias que serão monitoradas (RF);
d) permitir, no módulo servidor, associar os usuários às fábricas que serão por eles
monitoradas (RF);
e) enviar dados do módulo servidor para os clientes ativos (RF);
f) oferecer uma tela de login no módulo cliente para autenticação do usuário (RF);
g) permitir o monitoramento dos servidores (RF);
h) permitir, no módulo cliente, cadastrar as ações tomadas pelo usuário na correção
de um erro detectado no monitoramento (RF);
i) permitir ao usuário visualizar relatórios de erros detectados (RF);
j) utilizar objetos SOAP para o envio de informações aos Web Services (Requisito
Não-Funcional - RNF);
k) implementar os módulos cliente e servidor e os Web Services utilizando a
linguagem Java e o ambiente Netbeans IDE 7.0 (RNF);
l) comunicar os módulos cliente e servidor utilizando o Java Remote Method
Invocation (RMI) (RNF);
m) utilizar um banco de dados PostgreSQL para armazenar informações no servidor
(RNF);
34
3.2 ESPECIFICAÇÃO
Nesta seção são apresentadas as especificações do sistema desenvolvido. Para
especificação dos requisitos foram utilizados alguns dos diagramas da Unified Modeling
Language (UML) em conjunto com a ferramenta Enterprise Architect 8.0.860 para a
descrição dos casos de uso, diagramas de classes e diagrama de atividades.
3.2.1 Diagrama de casos de uso
A seguir são demonstrados os principais casos de uso do módulo servidor e do módulo
cliente.
3.2.1.1 Módulo servidor
A Figura 8 demonstra os nove (9) casos de uso do módulo servidor.
Figura 8 - Casos de uso do módulo servidor
35
Abaixo são explanados os casos de uso, com exceção aos UC01, UC02, UC03 e UC04
por se tratarem de cadastros simples. O caso de uso UC05, chamado de Associar
Usuários e Fábricas é detalhado no Quadro 7.
UC05 - Associar usuários e fábricas
Pré-condições Usuário deve ser administrador; deve existir pelo menos uma fábrica e um
usuário cadastrados.
Cenário principal
01) O usuário acessa a tela Manage User x Plant.
02) O sistema busca os usuários cadastrados.
03) O sistema busca as fábricas cadastradas.
04) O usuário seleciona o usuário.
05) O usuário seleciona a planta na lista Non Associated Plants.
06) O usuário associa a planta ao usuário pressionando o botão >>.
07) O sistema salva a associação no banco de dados.
Fluxo alternativo 01
No passo 05, caso o usuário deseje desassociar uma planta ao usuário:
05.1) O usuário seleciona uma planta na lista Associated Plants.
05.2) O usuário pressiona o botão <<.
Pós-condição O usuário deverá estar apto a monitorar através do módulo cliente a fábrica
associada a ele.
Quadro 7 - Caso de uso 05
O caso de uso UC06, chamado Coletar Mensagens de Erros nos Processos,
e o caso de uso UC07, chamado Receber Mensagem de Erro do Web Service, são
descritos, respectivamente, nos quadros 8 e 9.
UC06 – Coletar mensagens de erros nos processos
Pré-condições Script PERL deve estar rodando no servidor produtivo.
Cenário principal
01) O script busca por erros de processos produtivos nos arquivos de log do
servidor produtivo.
02) O script trata a mensagem de erro encontrada.
03) O script envia a mensagem ao Web Service utilizando o protocolo
SOAP.
Pós-condição Módulo servidor deverá receber a mensagem de erro.
Quadro 8 - Caso de uso 06
UC07 – Receber mensagens de erro do Web Service
Pré-condições Não há pré-condições.
Cenário principal 01) include::UC06.
02) O sistema trata a mensagem recebida.
Pós-condição O sistema deverá enviar a mensagem tratada aos clientes ativos.
Quadro 9 - Caso de uso 07
Os casos de uso UC08, chamado Enviar Mensagens de Erro aos Clientes
Ativos, e UC09, chamado Receber Ações Tomadas no Erro, são detalhados nos
quadros 10 e 11, respectivamente.
36
UC08 – Enviar mensagens de erro aos usuários ativos
Pré-condições Ter uma conexão com um cliente ativo.
Cenário principal
01) include::UC07.
02) O sistema verifica de qual fábrica é a mensagem.
03) O sistema busca os usuários ativos.
04) O sistema verifica quais dos usuários ativos devem receber a mensagem.
05) O sistema envia a mensagem.
Exceção 01 No passo 03, se não houver usuário ativo, o caso de uso se encerra.
Exceção 02 No passo 04, se nenhum usuário está associado à fábrica em questão, o caso
de uso se encerra.
Exceção 03 No passo 05, se a conexão com o cliente for perdida, o caso de uso se
encerra.
Pós-condição Os clientes ativos deverão receber a mensagem enviada.
Quadro 10 - Caso de uso 08
UC09 – Receber ações tomadas no erro
Pré-condições Ter enviado uma mensagem de erro classificada como crítica ao cliente
ativo.
Cenário principal 01) O sistema recebe uma ação tomada por um usuário.
02) O sistema salva a ação na base de dados.
Pós-condição O erro deverá constar como resolvido na base de dados e estará disponível
nos relatórios.
Quadro 11 - Caso de uso 09
3.2.1.2 Módulo cliente
A Figura 9 demonstra os cinco (5) casos de uso do módulo cliente.
Figura 9 - Casos de uso do módulo cliente
37
Abaixo são explanados os casos de uso, com exceção do UC12. O caso de uso UC10 é
chamado Efetuar Login e tem uma exceção, conforme representado no Quadro 12. No
Quadro 13 é apresentado o caso de uso UC11, chamado Receber Mensagem de Erro do
Servidor e que possui um fluxo alternativo.
UC10 – Efetuar login
Pré-condições Não há pré-condições
Cenário principal
01) O usuário inicializa o módulo cliente.
02) O usuário informa o endereço IP do servidor, a porta de comunicação, o
login e a senha.
03) O sistema valida os dados.
04) O sistema autoriza o usuário e abre a tela inicial.
Exceção 01 No passo 03, os dados do usuário podem não ser validados:
03.1) O sistema mostra uma mensagem de erro.
Pós-condição O usuário deve estar autenticado e o sistema liberado para uso.
Quadro 12 - Caso de uso 10
UC11 – Receber mensagem de erro do servidor
Pré-condições Módulo cliente deve estar conectado ao servidor.
Cenário principal
01) O sistema recebe uma mensagem de erro de processo do módulo
servidor.
02) O sistema trata a mensagem recebida.
03) O sistema mostra a mensagem de erro na aba Monitoring.
Fluxo alternativo 01
No passo 03, caso a mensagem seja classificada como crítica:
03.1) O sistema também mostra a mensagem de erro na aba Critical
Messages.
03.2) O sistema emite um alarme sonoro.
Pós-condição O usuário identifica o erro e sua criticidade para o sistema.
Quadro 13 - Caso de uso 11
O caso de uso UC13 é chamado Enviar ao Servidor as Ações Tomadas no
Erro e está representado no Quadro 14. O caso de uso UC14 é chamado Ver Relatório
de Erros, como mostra o Quadro 15. Ambos possuem um fluxo alternativo.
UC13 – Enviar ao servidor as ações tomadas no erro
Pré-condições Módulo cliente deve estar conectado ao servidor e o usuário deve estar
autenticado.
Cenário principal
01) O usuário acessa a aba Critical Messages.
02) O usuário clica no botão OK ao lado da mensagem de erro.
03) O usuário seleciona seu login. 04) O usuário insere as ações tomadas sobre o erro.
05) O usuário salva a ação.
06) O sistema envia as ações ao servidor.
07) O alarme sonoro é desativado.
Pós-condição O erro constará como resolvido nos clientes ativos.
Quadro 14 - Caso de uso 13
38
UC14 – Ver relatório de erros
Pré-condições Módulo cliente deve estar conectado ao servidor e o usuário deve estar
autenticado.
Cenário principal
01) O usuário acessa a tela de relatórios.
02) O sistema lista as fábricas, servidores e instâncias disponíveis.
03) O usuário escolhe a fábrica.
04) O usuário escolhe o servidor.
05) O usuário escolhe a instância.
06) O usuário pressiona o botão Select.
Fluxo alternativo 01
No passo 05, o usuário pode adicionar uma data específica para a busca:
05.1) O usuário insere a data.
05.2) O usuário insere a hora.
Pós-condição As informações que satisfaçam as condições do usuário devem ter sido
mostradas.
Quadro 15 - Caso de uso 14
3.2.2 Diagrama de classes
Com a intenção de facilitar a leitura, entendimento e interpretação do diagrama de
classes, são apresentados os diagramas de acordo com o módulo e o pacote que o conjunto de
classes representa. Nos próximos tópicos, são apresentados os diagramas do módulo servidor
e do módulo cliente e as classes que representam os Web Services. Foram definidos métodos
getters e setters para os atributos de cada classe, mas os mesmos não estão sendo
apresentados para não comprometer o entendimento dos diagramas.
3.2.2.1 Módulo servidor
As classes do módulo servidor estão divididas nos pacotes explanados no Quadro 16.
39
Definição dos pacotes do módulo servidor
Pacote Definição
econserver define a classe CtrlMainApp, que é onde se inicia módulo servidor
econserver.ctrl contém as classes que fazem o controle do acesso aos métodos que utilizam
conexões com o banco de dados
econserver.dao contém as classes que persistem os dados no banco de dados da aplicação
econserver.db contém três classes de configuração do banco de dados e do pool de
conexões
econserver.model contém as classes dos objetos que serão persistidos no banco de dados e
que serão utilizados para troca de mensagens entre os módulos
econserver.rmi
contém as classes necessárias para a comunicação RMI do módulo servidor
com o módulo cliente. Possui também a implementação dos métodos do
módulo servidor que poderão ser invocados remotamente
econserver.ui contém as classes de definição da interface gráfica do módulo
econserver.util contém as classes que tratarão as mensagens recebidas do Web Service
antes de enviá-las aos clientes ativos
econaxisws contém as classes responsáveis pelos Web Services disponibilizados
econclientmonitor.rmi contém a interface do módulo cliente para a comunicação com o mesmo
através do RMI
Quadro 16 - Definição dos pacotes do módulo servidor
São explanados a partir de agora os pacotes considerados mais importantes para
funcionalidade deste módulo. A Figura 10 ilustra as classes do pacote econserver.ui.
Figura 10 - Pacote econserver.ui
A classe UIServer recebe em seu construtor uma instância da classe ServerRMI, e é
a classe principal deste módulo. É responsável pela interface gráfica e também por publicar
os Web Services. Nesta classe também é iniciada uma thread do tipo
40
ThreadListenMessagesFromWS, responsável por ouvir as mensagens enviadas ao Web
Service, e uma outra thread do tipo ThreadLoggedUsers, que é acionada quando o
administrador solicita a lista de usuários conectados ao servidor.
As classes do pacote econserver.db são apresentadas na Figura 11.
Figura 11 - Pacote econserver.db
A classe ConfigurationFile faz a leitura do arquivo de configuração do banco de
dados, chamado dbconfig.properties, que está localizado dentro da pasta etc na pasta
raiz do projeto. Esta classe carrega as informações deste arquivo e instancia um objeto do tipo
DBConfiguration. A classe ConnectionPool utiliza um objeto do tipo
DBConfiguration para a criação de um pool de conexões com o banco de dados. Os
métodos checkin e checkout gerenciam as conexões que estão ativas com o banco de
dados.
As classes do pacote econserver.rmi estão ilustradas na Figura 12. A classe
ServerRMI é a classe que disponibiliza o servidor RMI para que os módulos cliente se
conectem ao módulo servidor. A classe LoginUser, que implementa a interface
Serializable, é o modelo do objeto utilizado para que o cliente efetue o login. A classe
UserAuthImpl, que implementa a interface UserAuth, e contém os métodos que podem ser
invocados remotamente pelos clientes ativos. Nesta classe, pode-se destacar os métodos que
buscam informações no banco de dados relacional do módulo servidor, como por exemplo os
métodos SQLgetPlantInfo e SQLselectIdPlant.
41
Figura 12 - Pacote econserver.rmi
A Figura 13 apresenta as classes do pacote econaxisws.
Figura 13 - Pacote econaxisws
A classe EconWS é a classe responsável pelos métodos do Web Service. Esta classe
possui um atributo do tipo MessageHandler, que funciona como um gerenciador das
mensagens de erro recebidas através do método pushFISServerMessage, que é o método
mais importante para o monitoramento dos servidores. Este método também é responsável por
42
enviar estas mensagens ao atributo msgHandler. A classe MessageHandler é a principal
classe do pacote. É a classe responsável pelo gerenciamento das mensagens recebidas. A
classe KERNTypeTelegram é a classe responsável pela consistência das mensagens
recebidas. O método splitKERNTypeTelegram faz a consistência das mensagens recebidas
e as envia para o objeto msgHandler, que as organiza em uma fila. As mensagens
enfileiradas serão buscadas pela thread do tipo ThreadListenMessagesFromWS da classe
UIServer, explicada anteriormente. A classe FISMessage representa o modelo dos objetos
das mensagens que serão trabalhadas por estas classes.
3.2.2.2 Módulo Cliente.
As classes do módulo servidor estão divididas nos pacotes explanados no Quadro 17.
Definição dos pacotes do módulo cliente
Pacote Definição
econclientmonitor.ctrl define a classe CtrlGeneral, que faz o controle de acesso aos
métodos que serão invocados remotamente
econclientmonitor.rmi
contém as classes necessárias para a comunicação RMI do módulo
cliente com o módulo servidor. Possui também a implementação dos
métodos do módulo cliente que poderão ser invocados remotamente
econclientmonitor.ui contém as classes de definição da interface gráfica do módulo
econclientmonitor.util contém as classes que tratarão as mensagens recebidas do módulo
servidor
econserver.rmi contém a interface do módulo servidor para a comunicação com o
mesmo através do RMI
Quadro 17 - Definição dos pacotes do módulo cliente
As classes do pacote econclientmonitor.ui são apresentadas na Figura 14.
Figura 14 - Pacote econclientmonitor.ui
43
A classe UILoginClient é responsável pela tela de login do módulo cliente. Esta
classe é a responsável por conectar o módulo cliente ao módulo servidor, informando o
endereço e porta do servidor RMI, usuário e senha. A classe UIMainClient é responsável
pela tela principal deste módulo. É através desta classe que o usuário poderá interagir com o
sistema. A classe UIDialogCheckCriticalMessage é a classe responsável pela tela de
registro de ações tomadas sobre os erros críticos.
As threads do pacote econclientmonitor.ui.thread representam as principais
funcionalidades deste módulo. As classes responsáveis pela atualização das telas de
monitoramento são as classes ThreadMonitoring, ThreadKernErrorMessages e
ThreadCriticalMessages, enquanto a classe ThreadReports é a responsável pela
busca de dados solicitados pelo usuário através da tela de relatórios da classe
UIMainClient.
A Figura 15 detalha as classes do pacote econclientmonitor.util.
Figura 15 - Pacote econclientmonitor.util.telegram
As classes FISMessage e KERNTypeTelegram desempenham o mesmo papel
explicado no módulo servidor. A classe KERNCriticalMessage é utilizada para tratar uma
mensagem de erro considerada crítica, e que será mostrada separadamente na tela de
monitoramento. A classe KERNTeleHandler é a classe responsável por gerenciar, classificar
e entregar à interface a mensagem tratada e sua devida classificação quanto à criticidade.
44
A Figura 16 apresenta as classes do pacote econclientmonitor.rmi.
Figura 16 - Pacote econclientmonitor.rmi
A classe ClientServerRMI é responsável por iniciar a conexão do módulo cliente ao
servidor RMI. A classe ConnectionP2PImpl, que implementa a interface
ConnectionP2P, contém os métodos do cliente que podem ser invocados remotamente.
3.2.3 Diagrama de atividades
O diagrama de atividades foi desenvolvido para facilitar a visualização do processo de
determinadas situações do sistema. É essencialmente um gráfico de fluxo que mostra o
controle de uma atividade para outra. O diagrama da Figura 17 mostra as atividades do
módulo servidor quando inicializado e quando recebe telegramas através do Web Service.
45
Figura 17 - Diagrama de atividades do módulo servidor
Quando o módulo é iniciado, inicia-se o servidor RMI pelo qual os clientes se
conectam ao módulo servidor, publicam-se os serviços e então o servidor fica à espera de
novas mensagens de erro. Quando uma mensagem é recebida, ela é consistida, gravada no
banco de dados e tratada internamente. O servidor busca os clientes ativos e verifica quais
clientes devem receber esta mensagem. Caso o cliente deva receber a mensagem, a mesma é
enviada, caso contrário, busca-se o próximo cliente ativo. Em caso de ocorrência de exceção
por perda de conexão com algum cliente, o mesmo é descartado e é dado prosseguimento aos
próximos clientes ativos.
A Figura 18 representa as atividades do módulo cliente ao ser inicializado e ao receber
uma mensagem de erro do módulo servidor.
46
Figura 18 - Diagrama de atividades do módulo cliente
Ao iniciar o módulo cliente, é solicitado o endereço e a porta do servidor, nome de
usuário e senha para o login. Se os dados forem validados, é apresentada a tela principal e é
feita a conexão RMI com o servidor, e o módulo aguarda o recebimento de mensagens de
erro. Ao receber uma mensagem, o módulo trata e classifica a mensagem. Se a mensagem for
considerada crítica, é apresentada na tela de monitoramento de erros críticos e na tela de
monitoramento geral. Caso a mensagem não seja crítica, esta é apresentada apenas no
monitoramento geral.
As mensagens classificadas como críticas ficam aguardando o registro de ações por
parte do usuário. Ao solicitar o registro de uma ação, um diálogo para o cadastro de ações se
abrirá e enviará o registro ao servidor. Após o registro da ação, a mensagem desaparecerá da
tela de monitoramento crítico.
47
3.2.4 Modelo Entidade Relacional (MER)
O MER tem como objetivo representar de forma visual as estruturas de dados de um
banco de dados. Para desenhar o MER deste sistema foi utilizada a ferramenta DB Designer 4
da fabFORCE.net.
Como banco de dados, é utilizado o PostgreSQL 9.0 e para o gerenciamento e criação
dos objetos é utilizado o pgAdmin III. A Figura 19 mostra o MER da estrutura de banco de
dados utilizada neste trabalho.
Figura 19 - MER do banco de dados
Os dados persistidos no servidor estão distribuídos nas seguintes tabelas:
a) tabela plant – guarda informações das fábricas monitoradas: identificação e
descrição;
b) tabela server – guarda informações dos servidores de cada fábrica;
c) tabela instance – guarda informações das instâncias CS3 de cada servidor;
d) tabela user – guarda informações dos usuários do sistema;
e) tabela message type – guarda os tipos de mensagem de erro e sua descrição;
f) tabela message data – guarda os dados das mensagens de erro capturadas nos
servidores monitorados e enviadas aos Web Services;
48
g) tabela checked messages – guarda as informações das mensagens de erro já
tratadas e as ações corretivas tomadas pelo usuário para a solução do problema;
h) tabela client Peer To Peer (P2P) – guarda temporariamente as informações de
endereço de rede e porta utilizada pelo usuário para acessar o sistema;
i) tabela plant_client P2P – guarda a lista de quais fábricas o usuário monitora;
j) tabela kern error types – guarda informações sobre os diferentes tipos de erros. O
campo active indica se o erro deve ou não ser mostrado no monitoramento;
k) tabela kern color codes – guarda a relação do erro com a cor a qual ele deve
aparecer no cliente de monitoramento de acordo com sua criticidade.
3.3 IMPLEMENTAÇÃO
A seguir são mostradas as técnicas e ferramentas utilizadas e a operacionalidade da
implementação.
3.3.1 Técnicas e ferramentas utilizadas
O trabalho foi implementado sob o paradigma da orientação a objetos, utilizando a
linguagem Java na versão 6. A mesma linguagem foi utilizada para desenvolver o módulo
servidor e o módulo cliente. Como ambiente de desenvolvimento, foi utilizado o Netbeans
IDE na sua versão 7.0.1. O Sistema Gerenciador de Banco de Dados (SGBD) utilizado foi o
PostgreSQL 9.0.
Para auxiliar na publicação e na integração do Web Service, optou-se pela utilização do
servidor web Apache Tomcat 7 e do framework Apache Axis2/Java, que oferece todo o
suporte a comunicação entre aplicações utilizando o protocolo SOAP, ambos disponibilizados
pela Apache Software Foundation.
3.3.2 Implementação do sistema
O objetivo deste trabalho é implementar um sistema de monitoramento em dois
49
módulos, servidor e cliente, e utilizando Web Service, visando receber informações dos
processos produtivos do sistema de controle e planejamento de produção das fábricas de um
grupo de montadoras de automóveis através de um script escrito em PERL. Estas informações
são tratadas e persistidas no módulo servidor, e enviadas aos módulos clientes ativos.
No Quadro 18 é apresentada a classe que implementa os métodos disponibilizados
como Web Service. Estes métodos são descritos no arquivo econ.wsdl, que é apresentado no
apêndice A.
Quadro 18 – Classe econWS
O método pushFISServerMessage é o método principal do Web Service e que será
chamado através dos scripts PERL dos servidores. O método insertTelegram da classe
MessageHandler insere os telegramas recebidos numa fila de processamento do módulo
servidor.
No Quadro 19 é apresentado um comentário com o procedimento executado pelo
script PERL e a definição do endereço do Web Service.
50
Quadro 19 – Procedimento do script PERL e definição do endereço do arquivo WSDL
No apêndice B é apresentado o laço principal do script PERL, onde acontece a
chamada do método pushFISServerMessage.
No módulo servidor, a thread ThreadListenMessagesFromWS ficará ouvindo as
mensagens que serão recebidas através do Web Service. O método run desta thread é
apresentado no Quadro 20.
As mensagens captadas por esta thread são tratadas, gerenciadas e persistidas no
módulo servidor através da chamada do método getTelegramFromWebService. Após o
tratamento destas mensagens, o módulo servidor disponibiliza estas mensagens aos clientes
ativos, que interpretam as mensagens e verificam se devem ou não mostrar a informação no
módulo cliente.
A comunicação entre o módulo servidor e os módulos cliente é feita através de um
servidor RMI, o qual é disponibilizado na execução do módulo servidor. É a partir deste
servidor RMI que é feita a autenticação dos usuários, o envio de mensagens de erro detectadas
e são enviadas as ações tomadas sobre os erros críticos, esta última feita do módulo cliente
para o módulo servidor.
51
Quadro 20 - Método run da thread ThreadListenMessagesFromWS
3.3.3 Operacionalidade da implementação
A operacionalidade da implementação será apresentada através da simulação de casos
de utilização do sistema, ou seja, serão detalhadas as operações em nível de usuário para a
utilização dos recursos do sistema. De uma forma geral a ferramenta eCon tem por objetivo
disponibilizar acesso ao módulo servidor através do módulo cliente para facilitar o
monitoramento dos processos produtivos do sistema de planejamento e controle de produção.
Nas próximas seções serão abordadas as principais funcionalidades do módulo servidor e do
módulo cliente.
52
3.3.3.1 Módulo Servidor
O módulo servidor do eCon está instalado em um servidor que tem acesso à rede do
grupo de montadoras. O acesso ao módulo está restrito aos administradores do servidor.
Sendo assim, não é feito controle de usuário, pois este controle já é feito diretamente no
servidor.
As principais funções do administrador do sistema são manter os cadastros de fábricas,
servidores, instâncias e usuários e gerenciar a associação de quais fábricas serão monitoradas
por quais usuários.
Após a inicialização do módulo, os Web Services são publicados e é inicializado o
servidor RMI para a comunicação com os módulos cliente. A tela principal deste módulo é
apresentada conforme Figura 20.
Figura 20 - Tela principal do módulo servidor
As funções dos botões são vistas no Quadro 21, listados da esquerda para a direita,
enquanto a estrutura de menus é descrita no Quadro 22.
Botão Descrição
1º Fechar a aba ativa
2º Ir para a próxima aba da
esquerda
3º Ir para a próxima aba da
direita Quadro 21 - Estrutura da barra de ferramentas
53
Menu Submenu Descrição
File Exit Fecha o módulo servidor
Maintenance Manage Plant Manter fábricas
Manage Server Manter servidores
Manage Instance Manter instâncias
Manage User Manter usuários
Manage User x Plant Associar usuários e
fábricas
View Online Users Ver usuários conectados
Quadro 22 - Estrutura de menus
Ao clicar no menu Maintenance > Manage Plant, o sistema abrirá a aba de
manutenção de fábricas, apresentado na Figura 21. É possível inserir, alterar, excluir e
visualizar as fábricas cadastradas. Este cadastro é utilizado para identificar quais as fábricas
serão monitoradas pelo eCon.
Figura 21 - Tela de manutenção de fábricas
Para cadastrar uma nova fábrica basta clicar no botão Add e preencher os campos id e
plant, conforme Figura 22. Para editar ou excluir um registro o administrador deve
selecioná-lo na tabela e clicar em Change ou Delete. Os campos para edição são os mesmos
do cadastro.
Figura 22 - Tela para cadastro de nova fábrica
54
Para manter os servidores, o administrador deve clicar no menu Maintenance >
Manage Servers. O sistema abrirá a aba de manutenção de servidores, onde é possível
inserir, alterar, excluir e visualizar os servidores cadastrados, como mostra a Figura 23.
Figura 23 - Tela de manutenção de servidores
Para adicionar um novo servidor deve-se clicar no botão Add, e preencher os campos
necessários. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e
clicar em Change ou Delete. Os campos para edição são os mesmos do cadastro. Deve-se
obrigatoriamente associá-lo a uma fábrica cadastrada no sistema. A Figura 24 mostra a tela de
cadastro de um novo servidor.
Figura 24 - Tela para cadastro de novo servidor
A aba de manutenção das instâncias é habilitada ao clicar no menu Maintenance >
Manage Instances, conforme mostra a Figura 25. É possível inserir, alterar, excluir e
visualizar as instâncias cadastradas.
55
Figura 25 - Tela de manutenção de instâncias
Para adicionar um novo servidor deve-se clicar no botão Add, e preencher os campos
necessários. Deve-se obrigatoriamente associá-lo a uma fábrica e um servidor cadastrados no
sistema. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e clicar
em Change ou Delete. Os campos para edição são os mesmos do cadastro. A Figura 26
mostra a tela de cadastro de uma nova instância.
Figura 26 - Tela para cadastro de nova instância
A manutenção dos usuários é feita através do menu Maintenance > Manage
Users. Ao abrir esta aba, o administrador visualizará a lista dos usuários cadastrados. Através
desta aba, é possível inserir, alterar ou excluir usuários. A Figura 27 mostra a tela de
manutenção de usuários.
56
Figura 27 - Tela de manutenção de usuários
Para adicionar novos usuários, basta clicar no botão Add e preencher os campos
necessários. Para editar ou excluir um registro o administrador deve selecioná-lo na tabela e
clicar em Change ou Delete. Os campos para edição são os mesmos do cadastro. Todo
usuário cadastrado no módulo servidor pode autenticar-se no módulo cliente do eCon, e pode
visualizar o monitoramento das plantas associadas a ele. A Figura 28 apresenta a tela de
cadastro de usuários.
Figura 28 - Tela para cadastro de novo usuário
A associação de quais fábricas cada usuário deve monitorar é feita pelo administrador
do sistema através do menu Maintenance > Manage Users X Plant. A tela de
manutenção da associação de usuários e fábricas está ilustrada na Figura 29. O sistema
carrega os usuários cadastrados e os carrega em uma lista (Figura 29(1)). As fábricas não
associadas ao usuário selecionado aparecem na lista Non Associated Plants (Figura
29(2)), enquanto as fábricas associadas ao usuário aparecem na lista Associated Plants
57
(Figura 29(3)).
Figura 29 - Tela de manutenção da associação de usuários e fábricas
Para associar uma fábrica ao usuário selecionado, deve-se selecionar a fábrica desejada
na lista de fábricas não associadas e clicar no botão >> (Figura 29(4)). Para desassociar uma
fábrica associada ao usuário, deve-se selecionar a fábrica na lista de fábricas associadas e
clicar no botão << (Figura 29(5)).
3.3.3.2 Módulo Cliente
O módulo cliente pode ser instalado em qualquer computador que possua acesso à rede
do grupo e possua o Java Runtime Environment versão 6 ou superior instalado. Ao acessar
este módulo, será apresentada a tela de autenticação, que solicitará ao usuário o endereço do
servidor, a porta para conexão RMI, o usuário e a senha, conforme mostra a Figura 30.
58
Figura 30 - Tela de autenticação do módulo cliente
Após a autenticação do usuário, é apresentada a tela principal do módulo cliente com a
aba de monitoramento ativa (Figura 31(1)). Esta aba é dividida em três partes: lista das
plantas monitoradas pelo usuário (Figura 31(2)), tabela dos erros das plantas monitoradas
(Figura 31(3)) e o campo com a descrição do último erro recebido (Figura 31(4)). A partir do
momento em que esta tela está ativa, o módulo cliente já começa a receber as mensagens
enviadas pelo servidor.
Figura 31 - Tela principal do módulo cliente
As mensagens recebidas são classificadas de três maneiras. As mensagens na cor verde
são mensagens que não precisam ser verificadas, pois são apenas mensagens informativas
sobre algum processo do sistema. As mensagens em amarelo são erros que podem vir a causar
algum impacto na linha de produção, porém não causam impacto imediato. As mensagens em
vermelho são consideradas críticas e impactam diretamente o funcionamento do sistema na
59
linha de montagem, e devem ser analisadas e tratadas imediatamente.
A classificação dos erros no sistema de monitoramento é feita pelo administrador do
sistema diretamente no banco de dados do servidor, e esta classificação foi feita pelo grupo
dos analistas mais experientes da equipe de suporte AMS.
A lista de fábricas monitoradas serve como um filtro para as mensagens de erro, ou
seja, ao selecionar uma fábrica, serão mostrados na tabela de erros apenas os erros referentes à
fábrica selecionada. Para visualizar todos os erros, o usuário deve selecionar neste campo o
valor ALL PLANTS.
A aba de monitoramento de mensagens críticas é mostrada na Figura 32. Esta aba
conterá apenas os erros classificados como críticos pelo administrador do módulo servidor
que impactam diretamente a produção e que podem resultar numa parada da linha de
produção.
Figura 32 - Aba de monitoramento de mensagens críticas
Esta aba foi criada para diminuir o tempo de detecção de problemas críticos, para que
os mesmos sejam tratados antes que causem qualquer impacto à linha de montagem. É uma
tela simples com uma tabela informando a fábrica, o servidor, a instância, o tipo e o conteúdo
da mensagem. Na sexta coluna da tabela o usuário pode visualizar a situação do erro, que
pode ser true, para o erro que já foi tratado por um analista, ou false, que ainda não foi tratado
e pode estar impactando a produção. Se a situação do erro estiver true, na sétima coluna da
tabela estarão registradas as ações tomadas pelo analista que tratou o erro.
Para o usuário registrar uma ação tomada em um erro com o estado false ou ver as
informações de um erro, basta dar um duplo clique sobre o mesmo e a tela mostrada na Figura
60
33 estará disponível. Esta tela está dividida em duas partes: informações sobre o erro Figura
33(1)) e salvar informações no banco de dados central (Figura 33(2)).
Figura 33 - Tela de visualização de mensagens críticas
Para salvar uma ação tomada e atribuir o status true para o erro, é preciso selecionar
seu usuário na lista de usuários (Figura 33(3)), descrever a ação tomada e clicar no botão
Save (Figura 33(4)).
No módulo cliente ainda tem duas funções, as quais podem ser acessadas através do
menu View da tela principal: verificar a lista de possíveis erros com suas descrições (Figura
34) e buscar o histórico de erros detectados pelo eCon (Figura 35).
Na aba de mensagens de erro é possível buscar um erro específico utilizando o campo
de filtro (Figura 34(1)). Estes erros são inseridos diretamente na base de dados pelo
administrador do sistema, especificando o código do erro, a sua descrição e a sua criticidade.
Na aba de relatórios, é possível filtrar os erros ocorridos por fábrica, servidor,
instância, tipo, data e hora (Figura 35(1)). Para gerar o relatório de acordo com os filtros do
usuário, basta clicar no botão Select (Figura 35(2)). Se o usuário não usar nenhum filtro,
todos os erros detectados pelo monitoramento serão apresentados. O resultado da busca
aparece logo abaixo em uma tabela (Figura 35(3)).
61
Figura 34 - Tela de visualização dos possíveis erros
Figura 35 - Tela de relatório de erros
3.3.3.3 Simulador de mensagens
No módulo servidor foi desenvolvido um simulador de envio e recebimento de
mensagens para auxiliar na parte de testes de tratamento de mensagens e de comunicação
entre os módulos da ferramenta. Esta funcionalidade foi desenvolvida para possibilitar a
realização de testes locais em computadores que não fazem parte da rede do grupo de
62
montadoras de veículos, ou seja, não estão na mesma rede dos servidores de produção das
fábricas.
A tela do simulador de mensagens é apresentada na Figura 36.
Figura 36 - Tela do simulador de mensagens
As mensagens que serão transmitidas pelo simulador devem ser carregadas de um
arquivo texto. Ao clicar no botão Select File (Figura 36(1)) o usuário seleciona o arquivo
desejado, e então clica no botão Load File (Figura 36(2)). As mensagens do arquivo
selecionado serão carregadas na tabela (Figura 36(3)).
Ao selecionar uma mensagem na tabela, os dados da mesma serão mostrados na área
Attributes (Figura 36(4)). Para enviar esta mensagem basta clicar no botão Send
Message (Figura 36(5)). Ao enviar a mensagem, é disparada uma thread que simula uma
mensagem já tratada pelo Web Service, a qual é transmitida através de RMI aos clientes
ativos.
Para que o simulador consiga interpretar corretamente as mensagens contidas no
arquivo texto, todas devem estar no mesmo formato do exemplo apresentado no Quadro 23.
Cada mensagem deve conter a identificação da fábrica, do servidor e da instância, o tipo do
erro, e o dado da mensagem, todos separados por vírgula.
63
Quadro 23 - Exemplo de um arquivo com mensagens de erro
3.4 RESULTADOS E DISCUSSÃO
Os resultados obtidos com o término do trabalho foram satisfatórios, pois com a
utilização do eCon o processo de monitoramento foi facilitado, aumentando a eficácia na
detecção de problemas, a qualidade do serviço e a produtividade dos analistas de suporte e
sustentação do sistema de planejamento e controle de produção.
Foram desenvolvidos os dois módulos propostos. O módulo servidor, que
disponibiliza os serviços, o servidor RMI, e gerencia o sistema, e o módulo cliente, no qual é
feito um controle de acesso de usuários e que é capaz de receber informações do servidor e
disponibilizar ao usuário uma interface de monitoramento dos processos produtivos. Todas as
informações relevantes ao monitoramento são registradas no banco de dados do servidor.
Quanto ao desempenho, os dois módulos se mostraram eficientemente rápidos. Quanto
ao desempenho do Web Service, a operação que se acreditava ser demorada, que é o
recebimento de muitas mensagens de diferentes servidores ao mesmo tempo, se mostrou
muito eficaz e apresentou ótimos resultados durante os testes de carga.
A utilização de Web Services demonstra ser uma alternativa viável e interessante para
o monitoramento dos processos produtivos de sistemas de planejamento e controle de
produção, principalmente pela flexibilidade e interoperabilidade que pode ser observada.
Sistemas que foram escritos em diferentes linguagens e operam em plataformas distintas
podem trabalhar juntos sem maiores problemas.
Após a realização dos testes de implementação, a ferramenta foi disponibilizada aos
analistas para testes de viabilidade e usabilidade. De modo geral, a ferramenta foi bem aceita
pelos usuários, os quais contribuíram para a melhoria da mesma através de sugestões e
críticas. Quanto à usabilidade, um dos pontos mais relevantes relatados é a possibilidade de
monitorar remotamente diversas fábricas de diferentes países do mundo com apenas uma
ferramenta, a qual recebe de forma organizada as informações de todas elas. A ferramenta foi
considerada relevante pelos usuários, pois fornece informações em tempo real sobre a
situação dos processos produtivos da fábrica, que são fundamentais para o bom
64
funcionamento do sistema de planejamento e controle.
A implementação de uma tela que mostra apenas os erros críticos foi sugerida pelos
usuários para diminuir o tempo de detecção de um problema grave na produção. Outra
sugestão foi adicionar ao banco de dados o campo active à tabela KernErrorType, a qual
informa se este erro deve ser analisado ou é um erro o qual a equipe já tem conhecimento e
não precisa atuar. Este erro, classificado como conhecido pelo administrador do sistema, é
filtrado nas telas de monitoramento, aumentado a eficiência na identificação de problemas.
O Quadro 24 apresenta um comparativo com os trabalhos correlatos. Por se tratar do
monitoramento de um sistema em específico, não foi encontrado nenhum trabalho com o
mesmo objetivo específico deste, então o critério de comparação foi o uso das tecnologias e
funcionalidades próximas.
Quadro 24 - Comparativo com trabalhos correlatos
Pode-se verificar que as plataformas de desenvolvimento variam de acordo com a
linguagem de programação na qual os trabalhos foram desenvolvidos. Todos os trabalhos
apresentam sistemas gerenciadores de bancos de dados diferentes e utilizam a tecnologia de
Web Services. Apesar dos diferentes objetos de monitoramento, percebe-se que os objetivos
principais dos trabalhos são similares.
65
4 CONCLUSÕES
Para haver um planejamento e controle de produção eficaz e de qualidade, é
imprescindível a existência de um sistema de planejamento e controle de produção. O grupo
de montadoras utiliza o sistema de planejamento e controle de produção o qual a T-Systems
do Brasil tem uma equipe de especialistas. A tarefa de monitoramento de eventos e processos
que executam nos servidores produtivos é primordial para o bom funcionamento da linha de
produção, para a garantia de funcionamento do sistema e para manter a qualidade do serviço
prestado pela empresa.
O eCon tem como objetivo auxiliar no monitoramento dos processos produtivos do
sistema de controle e planejamento, e permite monitorar estes processos de fábricas do grupo
em vários países, como Argentina, Inglaterra, Índia, África do Sul entre outros.
A utilização de Web Services como solução para a integração de plataformas e
linguagens distintas foi fundamental. Com esta tecnologia é possível a comunicação de um
aplicativo servidor com qualquer outro que seja capaz de se conectar ao Web Service.
Desta forma concluiu-se que, com o auxílio das ferramentas descritas e das pesquisas
realizadas, todos os objetivos foram alcançados. Os módulos clientes e servidor foram
implementados e disponibilizados, todos os requisitos propostos estão disponíveis nas
funcionalidades da ferramenta e os dados estão centralizados no banco de dados do servidor.
Conclui-se também que a utilização da tecnologia de Web Services para o monitoramento dos
processos produtivos é viável.
A maior dificuldade encontrada foi no momento dos testes de integração dos
servidores produtivos com o Web Service. Ainda não existe um ambiente de testes que simule
o funcionamento real deste sistema de planejamento e controle. Assim, os testes reais de
integração foram realizados com um número reduzido de servidores e instâncias para que não
houvesse risco de comprometimento dos sistemas e dos servidores produtivos das fábricas do
grupo.
As principais vantagens deste sistema são a centralização da informação de diversos
servidores em apenas uma interface e a persistência em banco de dados das informações
gerenciadas pelo módulo servidor.
Desde o início do desenvolvimento do sistema tinha-se conhecimento da limitação de
acessos à rede. Devido às políticas de segurança interna do grupo, não é possível acessar a
rede externa a partir da rede interna e vice-versa, ou seja, todas as máquinas que possuam o
66
módulo cliente devem obrigatoriamente estar fisicamente conectadas à rede interna para
garantir o funcionamento do sistema. O sistema apresenta também limitações quanto à
segurança e disponibilidade, que são sugeridas para futuras extensões deste trabalho.
4.1 EXTENSÕES
Nesta seção são apresentadas sugestões de extensões e modificações para este trabalho,
que estão descritas a seguir:
a) implementar os módulos cliente e servidor em uma interface web para que seja
possível acessá-los através de um navegador web;
b) disponibilizar, além do monitoramento dos processos produtivos, o
monitoramento de recursos de hardware dos servidores em que o sistema de
planejamento e controle de produção opera;
c) contemplar questões de segurança, como criptografia dos dados transmitidos,
sigilo, a confiança entre cliente e servidor e autenticação no módulo servidor;
d) aperfeiçoar o mecanismo de relatórios de erros, possibilitando ao usuário exportá-
los para um arquivo;
e) disponibilizar uma base de conhecimento com todos os erros críticos detectados e
corrigidos, a fim de identificar reincidências e buscar a correlação da causa raiz
destes problemas;
f) integrar ao Web Service um serviço de envio de e-mails ou SMS aos usuários
associados à determinada fábrica, quando esta apresenta erro em algum processo
produtivo.
67
REFERÊNCIAS BIBLIOGRÁFICAS
ALBINADER NETO, Jorge A.; LINS, Rafael D. Web services em java. Rio de Janeiro:
Brasport, 2006.
ALMEIDA, Maurício B. Uma introdução ao XML, sua utilização na internet e alguns
conceitos complementares. [S.l.], 2002. Disponível em:
<http://www.scielo.br/pdf/ci/v31n2/12903.pdf>. Acesso em: 08 ago. 2011.
ASKIN, Ronald G.; STANDRIDGE, Charles R. Modeling and analysis of manufacturing
systems. New York: John Wiley & Sons, 1993.
CHAPPELL, David A.; JEWELL, Tyler. Java web services. Beijing: O’Reilly, 2002.
CORREA, Henrique L.; GIANESI, Irineu G. N. Just in time, MRP II e OPT: um enfoque
estratégico. São Paulo: Atlas, 1993.
CORREA, Henrique L; GIANESI, Irineu G. N; CAON, Mauro. Planejamento,
programação e controle da produção - MRPII/ERP, conceitos, uso e implementação. São
Paulo: Atlas, 1997.
COUTO, Gustavo C.; GATTAI, Vitor S. Monitoramento do trânsito via dispositivo móvel.
São Paulo, 2008. Disponivel em:
<http://143.107.106.66/sites/pmr.poli.usp.br.euniversidade.com.br/files/ARTIGO%20Couto_
Gattai.pdf>. Acesso em: 08 out. 2011.
CUNHA, Denis. Web services, SOAP e aplicações web. [S.l.], 2002. Disponível em:
<http://devedge-temp.mozilla.org/viewsource/2002/soap-overview/index_pt_br.html>.
Acesso em: 08 ago. 2011.
DIAS, Rodrigo. Como a Microsoft leva o ITIL v3 do conceito à prática - parte 3. [S.l.],
2008. Disponível em: <http://blogs.technet.com/b/rodias/archive/2008/10/03/como-a-
microsoft-leva-o-itil-v3-do-conceito-pr-tica-parte-3.aspx>. Acesso em: 30 de set. 2011.
FABICIACK, Daniel. Introdução ao gerenciamento de serviços de TI. [S.l.], 2009.
Disponível em: <http://danielfabiciack.wordpress.com/category/1-gerenciamento-de-servicos-
de-ti>. Acesso em 29 set. 2011.
MAGALHÃES, Ivan L; PINHEIRO, Walfrido B. Gerenciamento de serviços de TI na
prática: uma abordagem com base na ITIL, inclui ISO/IEC 20.000 e IT Flex. São Paulo:
Novatec, 2007.
MARCHAL, Benoit. XML: conceitos e aplicações. São Paulo: Berkeley, 2000.
68
MELLO, Emerson R. et al. Segurança em serviços web. Florianópolis, 2006. Disponível em:
<http://www.das.ufsc.br/~emerson/academico/artigos/mellomcsbseg06.pdf>. Acesso em: 08
de ago. 2011.
MINISTÉRIO DO MEIO AMBIENTE. Projeto de monitoramento do desmatamento dos
biomas brasileiros por satélite. Brasília, 2008. Disponível em:
<http://www.mma.gov.br/estruturas/sbf_chm_rbbio/_arquivos/act_mma_ibama_sistema_satel
ites_projeto_72.pdf>. Acesso em: 08 ago. 2011.
PIRES, Silvio. Gestão estratégica da produção. Piracicaba: Unimep, 1995.
RECKZIEGEL, Mauricio. Descrevendo um web service – WSDL. [S.l.], 2006a. Disponível
em: <http://imasters.com.br/artigo/4422/webservices/descrevendo_um_web_service_-_wsdl>.
Acesso em: 15 ago. 2011.
______. Protocolo de transporte padrão - SOAP. [S.l.], 2006b. Disponível em:
<http://imasters.com.br/artigo/4379/web-services/protocolo-de-transporte-padrao-soap>.
Acesso em: 09 ago. 2011.
REZENDE, Denis A. Planejamento de sistemas de informação e informática: guia prático
para planejar a tecnologia da informação integrada ao planejamento estratégico das
organizações. São Paulo: Atlas, 2003.
SANT’ANNA, Mauro. Soap e web services. [S. l.], 2002. Disponível em:
<http://www.linhadecodigo.com.br/Artigo.aspx?id=38&pag=1>. Acesso em: 08 ago. 2011.
SEELY, Scott. SOAP: cross platform Web Services development using XML. New Jersey:
Prentice Hall, 2002.
SINGH, Inderjeet et al. Projetando web services com a plataforma J2EE 1.4: tecnologias
JAX-RPC, SOAP e XML. Rio de Janeiro: Ciência Moderna, 2006.
SNELL, James; TIDWELL, Doug; KULCHENKO, Pavel. Programming web services with
SOAP. Beijing: O’Reilly, 2002.
SUPPLY-CHAIN COUNCIL. Introdução ao suply chain management. [S.l.], 2011.
Disponível em:
<http://www.supplychainonline.com.br/modules.php?name=FAQ&myfaq=yes&id_cat=1&ca
tegories=Introdu%E7%E3o+ao+Supply+Chain+Management>. Acesso em: 06 ago. 2011.
TROJAN, Ancelmo G.; PADOIN, Edson L. Utilização de dispositivos móveis e web
services no monitoramento remoto de servidores em subestações de energia. Ijuí, 2008.
Disponível em:
<https://sistemas.usp.br/siicusp/cdOnlineTrabalhoVisualizarResumo?numeroInscricaoTrabalh
o=5749&numeroEdicao=16>. Acesso em: 05 out. 2011.
69
T-SYSTEMS. T-Systems – um parceiro forte. São Paulo, 2011. Disponível em:
<http://www.t-systems.com.br/tsi/pt/93300/Homepage/Sobrea-a-T-Systems/Empresa>.
Acesso em: 05 ago. 2011.
VENTURI, Eli. Protótipo de um sistema para controle e monitoração residencial através
de dispositivos móveis utilizando a plataforma .NET. 2005. 68 f. Trabalho de Conclusão
de Curso (Bacharelado em Sistemas de Informação) – Centro de Ciências Exatas e Naturais,
Universidade Regional de Blumenau, Blumenau.
VOLLMANN, Thomas E. et al. Sistemas de planejamento e controle da produção para o
gerenciamento da cadeia de suprimentos. 5. ed. São Paulo: Bookman, 2005.
WORLD WIDE WEB CONSORTIUM. Web services activity. [S.l.], 2011. Disponível em:
<http://www.w3.org/2002/ws>. Acesso em: 08 ago 2011.
70
APÊNDICE A – Arquivo econ.wsdl
No Quadro 25 é apresentado o documento WSDL do Web Service, onde são descritos
os métodos disponibilizados.
71
72
Quadro 25 - Arquivo WSDL
73
APÊNDICE B – Laço principal do script PERL
No Quadro 26 é apresentado o laço principal do script PERL, onde é chamado o
método pushFISServerMessage.
74
Quadro 26 - Laço principal do script PERL
75
ANEXO A – Autorização da T-Systems do Brasil
Na Figura 37 é apresentada a autorização do uso de informações da T-Systems do
Brasil.
Figura 37 - Autorização da T-Systems do Brasil