Embed Size (px)
Citation preview
FERNANDO KUTEKEN
DESENVOLVIMENTO DE UM SOFTWARE PARA SIMULAÇÃO DE CENTROS DE
DISTRIBUIÇÃO
Trabalho de Formatura apresentado à Escola
Politécnica da Universidade de São Paulo para
obtenção do Diploma de Engenheiro de
Produção.
São Paulo
2017
FERNANDO KUTEKEN
DESENVOLVIMENTO DE UM SOFTWARE PARA SIMULAÇÃO DE CENTROS DE
DISTRIBUIÇÃO
Trabalho de Formatura apresentado à Escola
Politécnica da Universidade de São Paulo para
obtenção do Diploma de Engenheiro de
Produção.
Orientador: Prof. Dr. Alberto Wunderler
Ramos
São Paulo
2017
Catalogação-na-publicação
Kuteken, Fernando
Desenvolvimento de um software para simulação de centros de distribuição / F. Kuteken -- São Paulo, 2017.
91 p.
Trabalho de Formatura - Escola Politécnica da Universidade de São Paulo. Departamento de Engenharia de Produção.
1.Desenvolvimento de produtos 2.Desenvolvimento de softwares
3.Simulação 4.Logística I.Universidade de São Paulo. Escola Politécnica. Departamento de Engenharia de Produção II.t.
AGRADECIMENTOS
Agradeço, primeiramente, à minha família, em especial aos meus pais, por todo o
incentivo aos estudos e o suporte que me foi fornecido.
Ao Pepe, que me proporcionou uma oportunidade de trabalho em sua empresa, por
todo o aprendizado e paciência, que foram fundamentais para a realização deste projeto.
Aos professores e funcionários da Escola Politécnica, em especial ao Departamento de
Engenharia de Produção, por todo o trabalho essencial empenhado na minha formação.
Ao meu orientador, Prof. Dr. Alberto Wunderler Ramos, por todo o suporte ao longo
deste ano, fundamental para a conclusão deste trabalho.
RESUMO
Neste trabalho, parte-se do problema enfrentado por uma empresa em realizar testes
de sistemas para centros de distribuição automatizados, devido às dificuldades inerentes a
essa tarefa. A solução proposta é a de desenvolver um software que simule um centro de
distribuição e que possa ser utilizado na realização de testes, a fim de auxiliar os funcionários
da empresa no processo de desenvolvimento de novos sistemas.
Para desenvolver um programa de simulação, buscou-se levantar uma lista de
funcionalidades a partir da realização de um benchmarking com softwares existentes no
mercado. Em seguida, para priorizar quais funcionalidades levantadas seriam efetivamente
implementadas, utilizou-se o modelo de Kano da satisfação do cliente por meio da aplicação
de um questionário. Para a implementação do código necessário, utilizou-se um ambiente
integrado de desenvolvimento, escolhido um dentre diversas alternativas por meio do
processo analítico hierárquico. O desenvolvimento foi feito a partir da programação orientada
a objetos, no qual as principais classes necessárias para a simulação foram projetadas e um
diagrama de classes da linguagem de modelagem unificada foi feito.
O programa desenvolvido permite construir modelos de centros de distribuição reais
para que as simulações possam ser realizadas. Uma vez que o software estava pronto para
testes, foram realizadas duas simulações utilizando cópias de sistemas de gerenciamento reais.
As simulações permitiram validar funcionalidades do sistema e também permitiram a coleta
de alguns dados estatísticos importantes.
Palavras-chave: Modelo de Kano. Processo analítico hierárquico. Linguagem de
modelagem unificada. Desenvolvimento de software. Simulação. Centro de distribuição.
ABSTRACT
The starting point of this project is a problem faced by a company in testing systems
for automated distribution centers, due to the difficulties inherent to this activity. The
proposed solution is to develop a software that simulates a distribution center and could be
used to perform tests, helping the employees of the company in the process of developing new
systems.
To develop a simulation software, a list of possible features was created from a
benchmark using other software available in the market. Then, to prioritize which listed
features were actually going to be implemented, the Kano model of client satisfaction was
used with the application of a questionnaire. To implement the necessary code, an integrated
development environment was used, chosen from a variety of alternatives by using the
analytical hierarchy process. The development was done using the object-oriented
programming, where the most important classes for the simulation were designed and a class
diagram from the unified modeling language was built.
The developed software allows the user to build real distribution center models,
necessary to run simulations. Once the software was ready to run some tests, two simulations
were done using copies of real warehouse management systems. The simulations allowed to
validate features in the system and they also allowed the retrieval of some important statistical
data.
Keywords: Kano model. Analytic hierachy process. Unified modeling language.
Software development. Simulation. Distribution center.
LISTA DE FIGURAS
Figura 1 – Modelo de esteira transportadora de caixas ............................................... 24
Figura 2 - Representação gráfica de um transelevador ................................................ 25
Figura 3 - Modelo de multishuttle ............................................................................... 25
Figura 4 - Diagrama da satisfação do cliente .............................................................. 27
Figura 5 - Exemplo de diagrama de atividades ........................................................... 33
Figura 6 - Exemplo de diagrama de classes ................................................................ 34
Figura 7 - Exemplo de um documento XML .............................................................. 36
Figura 8 - Modelo de tetraedro .................................................................................... 52
Figura 9 - Exemplo de arquivo .obj descrevendo um tetraedro ................................... 52
Figura 10 – Diagrama de classes do simulador ........................................................... 61
Figura 11 – Diagrama de atividades da simulação ...................................................... 64
Figura 12 – Janela principal da aplicação .................................................................... 65
Figura 13 – Sistema de grades para edição de layouts ................................................ 66
Figura 14 – Menu para edição das propriedades de uma esteira transportadora ......... 67
Figura 15 – Modelo de esteira transportadora de 3 metros de comprimento .............. 68
Figura 16 – Vista lateral de um corredor de transelevador .......................................... 69
Figura 17 – Visualização bidimensional de um corredor de multishuttle ................... 69
Figura 18 – Layout do primeiro teste de simulação .................................................... 72
Figura 19 – Validação do recebimento de cargas ........................................................ 73
Figura 20 – Validação da movimentação de um transelevador ................................... 74
Figura 21 – Câmera em perspectiva do segundo teste de simulação ........................... 75
Figura 22 – Exemplo de câmera ortográfica com vista isométrica ............................. 76
Figura 23 - Exemplo de câmera ortográfica com vista superior .................................. 76
Figura 24 - Armazenamento de uma caixa em um multishuttle .................................. 77
Figura 25 - Simulação com grande quantidade de cargas ........................................... 78
LISTA DE TABELAS
Tabela 1 – Classificação das características do produto .............................................. 28
Tabela 2 - Escala fundamental do AHP ....................................................................... 29
Tabela 3 - Índices de consistência aleatórios ............................................................... 30
Tabela 4 - Fatores de qualidade em desenvolvimento de software ............................. 31
Tabela 5 – Funcionalidades de softwares de simulação .............................................. 39
Tabela 6 – Resumo das respostas às perguntas do questionário de Kano ................... 40
Tabela 7 - Avaliação das funcionalidades ................................................................... 41
Tabela 8 - Classificação dos atributos do produto ....................................................... 41
Tabela 9 - Peso dos critérios de seleção do AHP ........................................................ 46
Tabela 10 – Preço de aquisição dos IDEs ................................................................... 47
Tabela 11 – Número de projetos de código aberto ...................................................... 48
Tabela 12 – Número de perguntas relacionadas a cada IDE ....................................... 48
Tabela 13 – Notas finais para cada alternativa ............................................................ 48
Tabela 14 – Atributos da classe “Elemento” ............................................................... 55
Tabela 15 – Atributos da classe “Unidade de Carga” ................................................. 56
Tabela 16 – Atributos da classe “Contentor de unidade de carga” ............................. 57
Tabela 17 – Atributos da classe “Corredor” ................................................................ 58
Tabela 18 – Atributos da classe “Esteira transportadora” ........................................... 58
Tabela 19 - Matriz de julgamento para os critérios de seleção ................................... 95
Tabela 20 – Pesos atribuídos a cada critério de seleção .............................................. 95
Tabela 21 - Matriz de julgamento para o custo ........................................................... 95
Tabela 22 - Matriz de julgamento para a base de código ............................................ 96
Tabela 23 - Matriz de julgamento para o suporte ........................................................ 96
Tabela 24 - Matriz de julgamento para a familiaridade ............................................... 96
Tabela 25 - Matriz de julgamento para as funcionalidades ......................................... 97
Tabela 26 - Sumário das notas de cada alternativa em cada critério ........................... 97
Tabela 27 - Nota final de cada alternativa ................................................................... 97
LISTA DE ABREVIATURAS E SIGLAS
AHP Analytic Hierarchy Process
AS/RS Automatic Storage and Retrieval System
CAD Computer Aided Design
CD Centro de Distribuição
GPU Graphics Processing Unit
IDE Integrated Development Environment
ISO International Organization for Standardization
UML Unified Modeling Language
W3C World Wide Web Consortium
WMS Warehouse Management System
XML Extensible Markup Language
SUMÁRIO
1 INTRODUÇÃO .................................................................................................. 13
1.1 Contextualização .......................................................................................... 14
1.2 Descrição do Problema ................................................................................ 14
1.3 Objetivo ........................................................................................................ 15
1.4 Relevância .................................................................................................... 16
1.5 Estrutura ....................................................................................................... 16
2 REVISÃO DA LITERATURA ......................................................................... 19
2.1 Logística e Centros de Distribuição ............................................................. 19
2.1.1 A importância da logística ....................................................................... 19
2.1.2 Atividades da Logística ........................................................................... 20
2.1.3 Armazenagem de produtos ...................................................................... 21
2.1.4 Movimentação de produtos ..................................................................... 23
2.2 Desenvolvimento de Produtos ..................................................................... 26
2.2.1 Modelo de satisfação do cliente ............................................................... 26
2.2.2 Processo analítico hierárquico ................................................................. 28
2.3 Desenvolvimento de softwares .................................................................... 31
2.3.1 Fatores de qualidade em softwares .......................................................... 31
2.3.2 Programação orientada a objetos ............................................................. 31
2.3.3 Linguagem de Modelagem Unificada ..................................................... 32
2.3.4 Extensible markup language .................................................................... 34
3 MATERIAIS E MÉTODOS ............................................................................. 37
3.1 Identificação das necessidades do cliente .................................................... 37
3.2 Benchmarking de softwares de simulação ................................................... 38
3.3 Questionário do Modelo de Kano ................................................................ 39
3.3.1 Respostas ................................................................................................. 40
3.3.2 Classificação dos atributos ...................................................................... 40
3.3.3 Análise dos resultados ............................................................................. 42
3.4 Escolha do ambiente de desenvolvimento integrado ................................... 43
3.4.1 Definição dos critérios de seleção ........................................................... 43
3.4.2 Definição das alternativas ........................................................................ 45
3.4.3 Comparação dos critérios de seleção ....................................................... 46
3.4.4 Comparação das alternativas ................................................................... 47
3.5 Simulação ..................................................................................................... 49
3.5.1 Escopo ..................................................................................................... 49
3.5.2 Elementos ................................................................................................ 49
3.5.3 Resultados ................................................................................................ 50
3.6 Ferramentas .................................................................................................. 50
3.6.1 Formato de arquivos ................................................................................ 50
3.6.2 Criação de modelos na linguagem de modelagem unificada (UML) ...... 51
3.6.3 Criação de modelos em 3D ...................................................................... 51
3.6.4 Biblioteca para renderização gráfica ....................................................... 53
3.7 Definição das classes ................................................................................... 53
3.7.1 Classe “Elemento” ................................................................................... 54
3.7.2 Classe “Unidade de Carga” ..................................................................... 56
3.7.3 Classe “Contentor de unidade de carga” ................................................. 57
3.7.4 Classe “Corredor” .................................................................................... 57
3.7.5 Classe “Esteira transportadora” ............................................................... 58
3.7.6 Classe “Câmera” ...................................................................................... 59
3.7.7 Sumário das classes ................................................................................. 60
4 RESULTADOS .................................................................................................. 63
4.1 Funcionamento do programa ....................................................................... 63
4.2 Interface do Usuário ..................................................................................... 64
4.3 Edição de Layouts ........................................................................................ 65
4.4 Representação 3D ........................................................................................ 67
4.5 Representação 2D ........................................................................................ 68
4.6 Coleta de dados estatísticos ......................................................................... 70
4.7 Funções não implementadas ........................................................................ 70
4.8 Testes de simulação ..................................................................................... 71
4.8.1 Primeiro teste de simulação ..................................................................... 71
4.8.2 Segundo teste de simulação ..................................................................... 74
4.8.3 Conclusão dos testes do software ............................................................ 79
5 DISCUSSÃO ....................................................................................................... 81
6 CONCLUSÕES .................................................................................................. 83
6.1 Limitações .................................................................................................... 85
6.2 Aprendizado ................................................................................................. 86
6.3 Próximos passos ........................................................................................... 86
REFERÊNCIAS ......................................................................................................... 89
APÊNDICE A – QUESTIONÁRIO DO MODELO DE KANO ........................... 93
APÊNDICE B – MATRIZES DO AHP ................................................................... 95
APÊNDICE C – ARQUIVO XML DE UM LAYOUT .......................................... 99
APÊNDICE D – COMUNICAÇÃO ENTRE O WMS E O SIMULADOR ....... 101
13
1 INTRODUÇÃO
Em um mercado cada vez mais competitivo, é essencial que as empresas que
comercializam produtos busquem reduzir o custo da sua cadeia de suprimentos. Em geral, os
produtos são produzidos em locais diferentes dos pontos em que são consumidos, pois na
sociedade moderna cada região tende a se especializar na produção de produtos que tiver uma
vantagem econômica para produzir (Ballou, 1993). Assim, existe um grande caminho a ser
percorrido desde a produção de um produto até a sua chegada ao consumidor final. Nesse
contexto, os centros de distribuição surgem como um elemento fundamental para que as
empresas consigam lidar com as suas necessidades logísticas, bem como com as mudanças na
economia e com a evolução tecnológica constante.
Os CDs (centros de distribuição) servem como ponto intermediário entre a produção
de um produto e o seu consumidor. Eles servem como ponto importante no transporte de
materiais, sendo tanto um ponto de destino quando os produtos ou matéria-prima chegam dos
fornecedores, como ponto de partida quando os produtos partem para os diferentes canais de
distribuição até chegarem aos consumidores finais. Além do transporte, os CDs também são
importantes por serem responsáveis pela manutenção e controle de estoques e pela separação
de pedidos.
Visando melhorar a eficiência de seus CDs, muitas empresas optam por centros de
distribuição automatizados, ou seja, instalações que contam com equipamentos de
movimentação e armazenagem de material sem a necessidade de operação manual. Estes
equipamentos são controlados por um sistema de gerenciamento de armazém. Este sistema,
conhecido pela sua sigla do inglês como WMS (Warehouse Management System), é um
software que conta com uma base de dados com informações de todos os produtos da
empresa, controla o estoque, recebe pedidos e envia ordens de movimentação aos
equipamentos da instalação, a fim de atender às necessidades operacionais de cada empresa.
O WMS, como elemento central no gerenciamento de um centro de distribuição, tem
impacto direto sobre a eficiência operacional de uma empresa, pois afeta diretamente as taxas
de utilização dos equipamentos e as taxas de separação de pedidos corretos e dentro do prazo.
É um elemento essencial para auxiliar a empresa a gerir bem os seus recursos, tornando-a
mais competitiva.
14
1.1 CONTEXTUALIZAÇÃO
O autor deste trabalho estagia em uma empresa que desenvolve sistemas de
gerenciamento de centros de distribuição automatizados, os WMSs. Cada cliente dessa
empresa possui características e necessidades específicas já que atuam em diferentes
mercados, como o alimentício, o farmacêutico e o têxtil. Assim, cada cliente necessita de um
WMS customizado.
O WMS desenvolvido pela empresa é responsável por controlar todo o fluxo de
entrada e saída de produtos de um CD. Além de controlar os níveis de estoque de cada
produto, o sistema é capaz de controlar os equipamentos existentes na instalação, como
esteiras transportadoras e sistemas de reaquisição e armazenamento automatizado, conhecidos
pela sigla AS/RS (automatic storage and retrieval system), que serão descritos mais
detalhadamente neste trabalho.
O sistema recebe em tempo real informações da leitura de escâneres e balanças
presentes em diferentes pontos da instalação. Ele deve processar todas as informações
recebidas e, com base nelas, deve decidir o destino de cada produto dentro do armazém.
Quando novos produtos chegam para serem armazenados, o sistema deve decidir qual o
melhor local para armazenar cada produto. Em outro caso, quando os produtos precisam ser
separados em pedidos, o sistema deve decidir de onde retirar cada material e em qual estação
de separação de pedidos eles serão processados.
Com uma breve descrição das funcionalidades de um WMS, já é possível perceber
que o desenvolvimento de sistemas como este apresenta diversos desafios. Cada sistema é um
produto único que deve atender às necessidades específicas de cada cliente de forma
personalizada. Outra dificuldade que surge no desenvolvimento desse tipo de sistema é
quando chega o momento da realização de testes.
1.2 DESCRIÇÃO DO PROBLEMA
O teste de um WMS é uma tarefa extremamente difícil, principalmente quando o
centro de distribuição já se encontra em plena operação. Como a grande maioria dos produtos
de uma empresa deve passar por um CD em algum momento do seu ciclo de vida, é quase
impossível parar completamente a sua atividade para a realização de testes de um novo
sistema sem acarretar em prejuízos, pois ele está sempre em operação para que a empresa
15
consiga atender a todos os seus pedidos dentro dos prazos que possuem. Um exemplo disso é
uma empresa que atua no setor de entregas de cartas e encomendas. Se o seu sistema parar por
qualquer motivo, mesmo que por pouco tempo, ela certamente terá grandes dificuldades em
conseguir entregar todos os seus pedidos dentro do prazo estipulado. Um outro exemplo de
prejuízos decorrentes da parada de uma instalação seria o de uma empresa que atua no
mercado alimentício, com fortíssima concorrência. Quando o consumidor final for ao
mercado e não encontrar o produto dessa empresa, ele muito provavelmente encontrará um
produto substituto de outra marca, levando a empresa a perder vendas por não ter o seu
produto disponível na prateleira. Assim, podemos ver que o tempo para a realização de testes
de um WMS é muito escasso, já que o tempo de operação de um CD é um recurso muito
precioso. Nenhuma empresa pode correr o risco de ter os seus pedidos atrasados e ter a sua
imagem prejudicada perante seus clientes.
Além do pouco tempo disponível, existem outras dificuldades na hora de realizar
testes de um sistema. A validação de um WMS envolve a movimentação de cargas para
verificações diversas. É preciso testar se o sistema está processando corretamente as
informações das leituras de escâneres e balanças quando cada carga passa por eles. Para isso,
é preciso que a empresa separe uma quantidade de cargas suficiente para serem utilizadas na
realização dos testes, o que não é uma tarefa simples. Existem empresas que lidam com
produtos de manipulação frágil, produtos muito pesados ou produtos resfriados e congelados,
o que dificulta a reserva de cargas para esta finalidade.
1.3 OBJETIVO
O objetivo deste trabalho é o desenvolvimento de uma solução alternativa que permita
o teste e a validação de WMSs desenvolvidos pela empresa, dadas as diversas dificuldades
discutidas anteriormente. A proposta é desenvolver um software que permita a realização de
testes virtuais do sistema de gerenciamento de armazém, funcionando como um simulador de
um centro de distribuição real. A ideia é que este simulador permita à empresa testar e validar
os seus sistemas, facilitando assim o seu desenvolvimento e antevendo problemas que só
seriam detectados durante testes na instalação real de seus clientes. Com este trabalho, espera-
se desenvolver uma solução que atenda à necessidade da empresa em realizar testes de
sistemas, utilizando os métodos e as ferramentas adequadas.
16
1.4 RELEVÂNCIA
A importância deste trabalho consiste em auxiliar a empresa no seu dia-a-dia no
desenvolvimento de novos sistemas e também na atualização e na manutenção de sistemas já
existentes. É de interesse tanto da empresa quanto de seus clientes que os testes dos WMSs
sejam mais ágeis.
O desenvolvimento de uma ferramenta que permita testar um WMS auxiliará a
empresa tanto a desenvolver sistemas mais confiáveis, já que testes poderão ser realizados
extensivamente sem acarretar em grandes custos como ocorre atualmente, quanto diminuir o
tempo de desenvolvimento de cada projeto, permitindo à empresa que ela atenda mais clientes
e, consequentemente, aumente a sua receita.
A realização de simulações de uma instalação poderá também ser oferecida pela
empresa como um novo serviço, mostrando aos clientes informações sobre a produtividade de
CDs previamente à operação ou mesmo à construção dos mesmos. Isso pode ser útil, por
exemplo, no caso de um cliente estar planejando a ampliação de sua instalação com base na
sua previsão de demanda. Poderia ser feita uma simulação para prever se a ampliação
planejada dará conta do aumento da demanda prevista.
1.5 ESTRUTURA
Este trabalho está estruturado em seis capítulos.
O capítulo 1 apresenta uma introdução ao tema do trabalho, apresentando o contexto
no qual ele está inserido. É apresentada a definição do problema a ser estudado, bem como os
objetivos e a relevância da realização do estudo.
O capítulo 2 consiste na revisão da literatura. Ele está dividido em duas partes: a
primeira apresenta referências importantes acerca da logística e de modelos e características
de centros de distribuição automatizados; a segunda parte apresenta referências a técnicas e
ferramentas utilizadas no desenvolvimento de produtos e no desenvolvimento de softwares
que serão importantes no desenvolvimento o software proposto neste trabalho.
17
O capítulo 3 mostra a metodologia utilizada no desenvolvimento do simulador de
centros de distribuição proposto, mostrando os detalhes importantes da sua implementação e
as razões para cada decisão tomada durante o desenvolvimento.
O capítulo 4 apresenta os resultados obtidos. São mostradas as funcionalidades
implementadas do simulador e a sua utilização para a realização de testes envolvendo a
simulação de instalações reais, a fim de mostrar uma aplicação prática do software
desenvolvido.
O capítulo 5 apresenta uma discussão a respeito do produto desenvolvido,
apresentando ideias de aplicações futuras que o simulador pode vir a proporcionar para a
empresa.
Por fim, o capítulo 6 encerra o trabalho com a conclusão, analisando os resultados do
trabalho como um todo, discutindo as suas limitações e os próximos passos a serem tomados
para a manutenção e a atualização do simulador.
18
19
2 REVISÃO DA LITERATURA
Neste capítulo, será feita a revisão da literatura a respeito do tema deste trabalho. Ela
está divida em três partes.
A primeira parte é uma revisão da bibliografia acerca da logística e de centros de
distribuição. É importante compreender a operação de um CD, bem como entender os
conceitos fundamentais relacionados ao mesmo. A segunda parte apresenta técnicas e
ferramentas utilizadas no desenvolvimento de produtos. A terceira parte traz informações
mais específicas para o desenvolvimento de softwares, já que temos como proposta deste
trabalho o desenvolvimento de um simulador.
2.1 LOGÍSTICA E CENTROS DE DISTRIBUIÇÃO
2.1.1 A importância da logística
A importância da logística é enfatizada por diversos autores em suas publicações a
respeito do assunto. Segundo Ballou (1993), a logística possibilita que os consumidores
tenham os bens e os serviços em boas condições quando e onde desejarem, apesar da ampla
distribuição geográfica dos recursos e dos clientes. Novaes (2015) afirma que a logística
permite agregar valor à cadeia produtiva e ao cliente em diversos aspectos:
• Valor de lugar: um produto só passa a ter valor para o cliente quando ele é entregue
em suas mãos.
• Valor de tempo: um produto só possui valor para o cliente a partir do momento em
que ele é entregue, respeitando-se os prazos estipulados. Por exemplo, um jornal de
notícias perde o seu valor se não é entregue dentro do prazo.
• Valor de qualidade: o produto deve ser entregue com as características corretas e em
bom estado de conservação.
• Valor de informação: empresas de entrega permitem que o cliente rastreie as suas
encomendas, permitindo que ele saiba em qual a etapa de entrega seu produto se
encontra a qualquer momento. Essa informação possui valor para o cliente.
20
Atualmente, grandes mudanças econômicas estão afetando a logística, que é cada vez
mais requisitada. Dentre essas mudanças, Fleury et al (2000) citam:
• Globalização: com a globalização, aumentam o número de clientes, o número de ponto
de vendas, a quantidade de fornecedores e, consequentemente, aumentam-se as
distâncias a serem percorridas e a complexidade operacional.
• Aumento da incerteza econômica: com o aumento da incerteza na economia, a
logística precisa se antecipar em relação à demanda mais do que nunca, para que seja
possível produzir e alocar os produtos no local e hora corretos.
• Proliferação de produtos: o aumento na quantidade de produtos disponíveis no
mercado aumenta o número de insumos e de fornecedores necessários, assim cresce a
dificuldade de planejar e controlar estoques. Os custos e a complexidade da logística
aumentam.
• Ciclo de vida encurtado: os produtos possuem um ciclo de vida cada vez menor
devido às características do mercado. Os estoques de produtos devem se adaptar
rapidamente aos lançamentos frequentes.
• Consumidores mais exigentes: em um mercado competitivo, a demora nos prazos de
entrega ou falta de disponibilidade de produtos leva à perda de clientes.
A evolução tecnológica vem permitindo que as operações logísticas sejam executadas
com a rapidez e a complexidade que elas exigem. Os centros de distribuição de hoje contam
com tecnologias como leitores de código de barras, identificadores por radiofrequência
(RFID), câmeras de monitoramento em tempo real, transelevadores e softwares de
gerenciamento de armazéns cada vez mais complexos.
2.1.2 Atividades da Logística
A logística apresenta três atividades-chave para que os seus objetivos de custo e nível
de serviço sejam atendidos (Ballou, 1993): transportes, manutenção de estoques e
processamento de pedidos.
O transporte é uma atividade da logística essencial para todas as empresas que
comercializam produtos. É preciso movimentar os materiais e os produtos desde a sua
produção até o consumidor final, que comumente se encontram distribuídos em pontos
21
geográficos amplos e dispersos. Devido a aspectos econômicos, as fábricas geralmente se
encontram distantes das grandes concentrações populacionais, onde costuma ser o destino
final das mercadorias.
A manutenção de estoques é outra atividade que surge na logística para lidar com a
diferença existente entre a oferta e a demanda. É preciso garantir a disponibilidade dos
produtos, o que nem sempre é fácil dada a imprevisibilidade da demanda do mercado e
também da sazonalidade, característica forte de algumas categorias de produto. Como a
capacidade produtiva das empresas em geral costuma não ser muito flexível, é preciso manter
uma quantidade mínima de produtos estocados para prover a disponibilidade aos clientes.
O processamento de pedidos é outra atividade da logística que, embora não seja
custosa como o transporte ou a manutenção dos estoques, também é uma atividade-chave.
Toda movimentação de produtos é iniciada com o processamento de algum pedido. É a
capacidade da empresa em processar rapidamente os seus pedidos que garante que os mesmos
sejam entregues no menor prazo possível, o que resulta em uma boa vantagem competitiva no
mercado.
Além das atividades-chave da logística, Ballou (1993) cita uma série de outras
atividades de apoio que auxiliam as atividades primárias. Dentre elas, temos a armazenagem,
a movimentação e o manuseio de materiais, a programação da produção / compra de produtos
e componentes e a manutenção da informação, essencial para o planejamento e o controle
logístico.
2.1.3 Armazenagem de produtos
A armazenagem de produtos é algo custoso, mas é necessária já que a produção e o
consumo de produtos não são sincronizados. Geralmente, a capacidade produtiva das
empresas é constante e a demanda por seus produtos apresenta flutuações, o que é outro
motivo para a necessidade de armazenar produtos. Ballou (1993) cita diversas razões para
uma organização utilizar espaço físico de armazenagem, dentre elas:
• Reduzir custos de transporte e produção: muitas vezes é possível reduzir os custos
de transporte e de produção pela estocagem de produtos mais próximos de seus
consumidores. O transporte direto da fábrica e a produção just-in-time podem ser
muito custosos.
22
• Coordenar suprimento e demanda: armazenar produtos permite que as empresas
coordenem suas demandas sazonais e assim produzam com taxas constantes para
minimizar custos de produção.
• Auxiliar o processo de marketing: a disponibilidade de produtos armazenados
permite ao marketing agregar valor ao produto no mercado, como por exemplo
conseguir entregas muito rápidas que melhorem o nível de serviço.
Já como funções do armazenamento, Ballou cita quatro:
• Abrigo de produtos: a função mais óbvia do armazenamento de produtos é o
abrigo físico dos mesmos, para que eles sejam adequadamente conservados e
mantenham as suas características.
• Consolidação de produtos: o armazenamento de produtos é capaz de consolidar
itens de diversas fontes, o que auxilia na redução de custos de fretes de grandes
lotes quando os carregamentos partem até o seu destino final.
• Transferência e transbordo: para atender pequenas demandas com baixos volumes,
é possível criar um espaço físico de armazenamento mais próximo dos clientes
finais, a fim de reduzir os custos no transporte desses itens.
• Agrupamento de produtos: muitas vezes diferentes produtos são produzidos em
diferentes fábricas, mas os clientes compram pedidos com linhas completas.
Assim, o armazenamento permite agrupar os produtos de diferentes fontes.
Quando um produto entra em um armazém para ser estocado, é preciso ter um sistema
que controle a localização de cada produto para que posteriormente seja possível recuperá-lo.
Também segundo Ballou, existem dois métodos de localização de produtos.
O sistema de endereçamento fixo atribui uma área específica do armazém para cada
produto diferente. Assim, a área do armazém é dividida de acordo com a necessidade de
espaço que cada produto possui. Quando é preciso recuperar um produto do estoque, basta ir
até a área específica do produto. Este método pode gerar muito espaço ocioso, e é difícil de
ser aplicado quando há muitos tipos de produtos diferentes a serem armazenados.
Existe também o sistema de endereçamento variável. Quando um produto entra no
estoque, ele vai a qualquer espaço livre disponível. Este método utiliza melhor o espaço
23
disponível, pois não possui o problema de espaço ocioso. Porém, é preciso manter um registro
da localização de cada item dentro do estoque. Este é o sistema de endereçamento utilizado
em centros de distribuição automatizados, pois um WMS consegue manter uma base de dados
com a localização de cada produto, que é rastreado de acordo com o seu código de barras.
Este código de barras é lido em diferentes pontos do armazém, assim o sistema consegue
rastrear a movimentação da carga dentro da instalação.
2.1.4 Movimentação de produtos
Um aspecto importante a ser abordado é a forma como os produtos são movimentados
dentro de um centro de distribuição. Quando lidamos com a movimentação de material, surge
o conceito de unidade de carga. Segundo Kay (2012), uma unidade de carga é uma única
unidade de um produto, ou múltiplos produtos organizados e restritos de forma que eles
possam ser movimentados como uma unidade única e manter a sua integridade. Como
exemplos mais comuns de unidade de carga encontradas em centros de distribuição temos
caixas e paletes.
Também segundo Kay, a unitização de cargas apresenta vantagens e desvantagens.
Como vantagens da utilização unidades de carga, ele cita a possibilidade de mais produtos
poderem ser manipulados ao mesmo tempo, assim reduzindo o número total de
movimentações, reduzindo o tempo gasto com operações de carga e descarga e reduzindo
danos de manipulação aos produtos. Também temos a possibilidade de utilizar equipamentos
de manipulação de materiais padronizados, projetados especificamente para trabalhar com
cada tipo de unidade de carga diferente. Como desvantagens da unitização de cargas, Kay cita
o tempo despendido para agrupar e desagrupar os produtos em unidades de carga, o custo dos
materiais utilizados na formação dos mesmos e também a necessidade de caixas e paletes
vazios muitas vezes terem de retornar à sua origem.
Para realizar a movimentação de unidades de carga dentro de um centro de
distribuição, existem diversos equipamentos utilizados. Dentre eles, em um CD automatizado,
encontramos principalmente esteiras transportadoras e sistemas AS/RS (automatic storage
and retrieval system).
24
Esteiras transportadoras
Esteiras transportadoras são utilizadas quando é necessário movimentar um alto fluxo
de unidades de carga de um ponto a outro. Estes pontos são fixos, e em suas extremidades
estão pontos importantes do centro de distribuição como as docas onde o material é recebido,
os corredores de armazenagem, as estações de separação de pedidos e as docas de expedição.
Na Figura 1, podemos ver um exemplo de esteiras transportadoras de caixas.
Figura 1 – Modelo de esteira transportadora de caixas
Fonte: Site da Dematic 1.
Sistemas de reaquisição e armazenamento automatizado (AS/RS)
Um sistema de reaquisição e armazenagem automatizado consiste em uma estrutura
verticalizada onde as unidades de carga são estocadas em diferentes níveis. Nessa estrutura,
existe um equipamento responsável pela movimentação das unidades de carga desde a entrada
do sistema, geralmente na cabeceira do corredor, até a posição de armazenamento desejada e
vice-versa.
Um exemplo de um sistema AS/RS é o transelevador, que pode ser visto na Figura 2.
Ele consiste em um carro que se movimenta horizontalmente sobre um trilho, onde há um
elevador que se movimenta verticalmente apoiado em sua estrutura. No elevador, há um garfo
(ou mais, dependendo do modelo) que é capaz de adquirir e armazenar as unidades de carga.
1 Disponível em: <http://www.dematic.com/en-us/supply-chain-solutions/by-technology/>. Acesso em maio de 2017.
25
Figura 2 - Representação gráfica de um transelevador
Fonte: Site do ME-JAN 2.
Outro exemplo de um sistema AS/RS é o multishuttle. Ele consiste em um ou mais
elevadores que movimentam as unidades de carga verticalmente entre a entrada de um
corredor e uma entrada em cada nível de armazenagem. Para a movimentação horizontal, há
um carro em cada nível, conferindo maior agilidade quando comparado ao transelevador
tradicional. A Figura 3 mostra uma foto de um modelo de multishuttle.
Figura 3 - Modelo de multishuttle
Fonte: Site da Dematic 3.
2 Disponível em: <www.me-jan.com/en/stacker-crane>. Acesso em maio de 2017. 3 Disponível em: <http://www.dematic.com/en-us/supply-chain-solutions/by-technology/storage-systems/>. Acesso em maio de 2017
26
2.2 DESENVOLVIMENTO DE PRODUTOS
A proposta deste trabalho é o desenvolvimento de um software que atenda à
necessidade da empresa em realizar testes de WMSs de uma forma alternativa. Assim, como
os usuários do simulador serão os desenvolvedores que trabalham na empresa, eles serão os
clientes do projeto de desenvolvimento do software, ou seja, os clientes do projeto são
clientes internos à empresa.
Para garantir o desenvolvimento de um produto com qualidade, é preciso entender
com clareza quais são as necessidades de seus usuários, para que elas sejam transcritas em
requisitos do software. Para isso, buscou-se na literatura modelos e ferramentas utilizados
para esta finalidade.
2.2.1 Modelo de satisfação do cliente
A satisfação de um cliente com relação a um determinado produto depende de suas
características e funcionalidades implementadas. Kano et al (1984) propõem um modelo para
analisar as características de um determinado produto, a fim de direcionar o seu
desenvolvimento. De acordo com este modelo, as características do produto podem ser
divididas em cinco categorias:
• Elementos de qualidade atrativa (attractive quality): estes elementos
proporcionam satisfação ao cliente quando estão presentes, mas se estiverem
ausentes não acarretam na perda de satisfação. São elementos acessórios.
• Elementos de qualidade unidimensional (one-dimensional quality): estes
elementos resultam na satisfação do cliente quando estão presentes, mas, por outro
lado, geram insatisfação se estiverem mal implementados ou ausentes.
• Elementos de qualidade obrigatória (must-be quality): espera-se que estes
elementos estejam presentes obrigatoriamente, gerando uma grande insatisfação se
estiverem ausentes.
• Elementos de qualidade indiferente (indifferent quality): estes elementos não
geram satisfação nem insatisfação, independentemente de estarem presentes ou
não.
• Elementos de qualidade reversa (reverse quality): estes elementos resultam em
insatisfação quando presentes, e em satisfação quando ausentes.
27
Kano et al propõem que as características de um produto possam ser observadas por
duas perspectivas, colocadas sobre os eixos de um diagrama (Figura 4): um eixo vertical,
representando a satisfação do cliente, e um eixo horizontal, representando o atendimento a um
determinado requisito ou a implementação de uma determinada característica.
Figura 4 - Diagrama da satisfação do cliente
Fonte: Site da Venki 4.
Para classificar as características do produto, o modelo propõe a elaboração de um
questionário a respeito dessas características. Para cada uma delas, o questionário conta com
duas perguntas: uma chamada funcional (pergunta positiva) e outra chamada disfuncional
(negativa). O cliente deve responder como se sente em relação a cada pergunta. Um exemplo
apresentado por Kano et al é a respeito da imagem fornecida por uma televisão. Como
pergunta funcional e disfuncional, respectivamente, temos:
1) Como você se sente em relação à imagem da televisão ser nítida?
a) Satisfeito
b) Aceitável
c) Indiferente
d) Obrigatório
e) Insatisfeito
4 Disponível em: <http://www.venki.com.br/blog/modelo-de-kano/>. Acesso em novembro de 2017.
28
2) Como você se sente em relação à imagem da televisão ser ruim?
a) Satisfeito
b) Aceitável
c) Indiferente
d) Obrigatório
e) Insatisfeito
As respostas às duas questões permitem classificar a característica do produto nas
cinco categorias apresentadas anteriormente, além de uma nova categoria “Cético”, utilizada
para respostas contraditórias (estar satisfeito tanto para a questão positiva quanto para a
questão negativa, ou estar insatisfeito tanto para a questão positiva quanto para a negativa). A
classificação da característica do produto em uma categoria é feita de acordo com a Tabela 1.
Tabela 1 – Classificação das características do produto
Questãodisfuncional(negativa)
Satisfeito Aceitável Indiferente Obrigatório Insatisfeito
Questão
funcional
(positiva)
Satisfeito C A A A U
Aceitável R I I I O
Indiferente R I I I O
Obrigatório R I I I O
Insatisfeito R R R R C
U = Unidimensional; A = Atrativa; O = Obrigatória; I = Indiferente; R = Reversa; C = Cético Fonte: Adaptado de Kano et al, 1984.
Uma vez que as características do produto estejam classificadas, elas serão muito úteis
para direcionar o desenvolvimento do produto, permitindo a correta atribuição de prioridades
às funcionalidades do produto a serem implementadas.
2.2.2 Processo analítico hierárquico
Em todo projeto, é necessário tomar decisões. O processo analítico hierárquico
(analytic hierarchy process ou AHP) é uma ferramenta utilizada para auxiliar na tomada de
decisões complexas, auxiliando chegar à melhor alternativa a ser escolhida. Esta ferramenta
foi introduzida por Thomas Saaty em 1980.
29
A ideia deste processo decisório é, a partir de uma certa quantidade de alternativas,
compará-las par a par segundo a sua importância relativa. Saaty propõe uma escala
fundamental a ser utilizada para realizar a comparação do grau de importância relativa entre
cada par de opções. Essa escala pode ser vista na Tabela 2.
Tabela 2 - Escala fundamental do AHP
Intensidade de importância
em escala absoluta Definição
1 Importância igual
3 Importância moderada
5 Importância forte ou essencial
7 Importância muito forte
9 Importância extrema
2, 4, 6, 8 Valores intermediários
Recíprocos Valores inversos (frações) são
utilizados como complementares
Fonte: Adaptado de Saaty, 1987. The analytic hierarchy process – what it is and how it is used.
O processo analítico hierárquico fornece uma forma de avaliar a existência de
inconsistências nas comparações realizadas. Por exemplo: se A é duas vezes mais importante
que B, e B é duas vezes mais importante que C, então A deve ser quatro vezes mais
importante que C. Caso a importância relativa de A sobre C seja qualquer valor diferente de
quatro, o modelo acusará uma inconsistência. No AHP, essa inconsistência pode ser calculada
numericamente, o que torna o modelo interessante. Modelos mais simples, como uma matriz
de decisão, não oferecem uma metodologia sistemática para identificação de inconsistências.
Um índice de consistência (CI – consistency index) pode ser calculado a partir de uma matriz
de julgamento, ou seja, uma matriz quadrada em que todas as alternativas estão dispostas
tanto nas linhas quanto nas colunas, e o cruzamento entre as linhas e colunas é a importância
relativa entre cada par de elemento. Dessa forma, o índice de consistência pode ser calculado
a partir da Equação 1.
𝐶𝐼 =l%&' −𝑛𝑛 − 1
(1)
30
Onde:
l%&' = máximo autovalor da matriz de julgamento
𝑛 = número de alternativas da matriz de julgamento
Uma vez calculado o índice de consistência, ele é então comparado a um índice de
consistência aleatório (RI – random index), índices que foram calculados a partir de matrizes
de julgamento geradas de forma aleatória. Para comparar estes dois índices, é calculada a taxa
de consistência (CR – consistency ratio), dada pela Equação 2.
𝐶𝑅 =𝐶𝐼𝑅𝐼(2)
Os índices de consistência aleatórios são valores tabelados em função do número de
alternativas da matriz de julgamento, conforme a Tabela 3.
Tabela 3 - Índices de consistência aleatórios
n Índice de consistência
aleatório (RI)
1 0,00
2 0,00
3 0,58
4 0,90
5 1,12
6 1,24
7 1,32
Fonte: Tekmono, 2006 5.
Saaty afirma que, para valores da taxa de consistência menores que 10%, possuímos
uma análise suficientemente consistente. Caso a taxa de consistência apresente valores mais
elevados, é necessário rever a atribuição das importâncias relativas entre cada alternativa.
Por fim, para se obter a melhor alternativa por meio do AHP, as importâncias relativas
são normalizadas em valores entre zero e um, e são multiplicadas com as respectivas
comparações de cada alternativa para se obter aquela com a maior pontuação. 5 Disponível em <http://people.revoledu.com/kardi/tutorial/AHP/ >. Acesso em junho de 2017.
31
2.3 DESENVOLVIMENTO DE SOFTWARES
2.3.1 Fatores de qualidade em softwares
São muitos os fatores que contribuem para a qualidade de um software. McCall et al
(1977) conduziram um estudo a respeito de fatores de qualidade utilizados no
desenvolvimento de softwares, propondo um modelo a partir do agrupamento de termos
semelhantes e da separação de termos relativos ao usuário e termos relativos ao software. O
modelo, conhecido como modelo da qualidade de McCall, apresenta os fatores divididos em
três categorias baseadas em atividades relacionadas a um software: operação, revisão e
transição. Os fatores são apresentados na Tabela 4.
Tabela 4 - Fatores de qualidade em desenvolvimento de software
Operação Revisão Transição
Corretitude Mantenabilidade Portabilidade
Confiabilidade Flexibilidade Reusabilidade
Eficiência Testabilidade Interoperabilidade
Integridade
Usabilidade
Fonte: McCall et al, 1997.
2.3.2 Programação orientada a objetos
Tratando-se de desenvolvimento de software, é essencial entender o conceito básico
de programação orientada a objetos e a sua lógica, utilizada para modelar e representar
elementos e as suas funções dentro de um programa.
Classes
De acordo com Ricarte (2001), o principal resultado da etapa de projeto de software é
a definição das classes. No paradigma da programação orientada a objetos, uma classe é um
elemento que define as propriedades ou atributos de um objeto, bem como as suas
funcionalidades, definidas por meio de métodos. Um método é uma função que manipula as
propriedades de um objeto.
32
Objetos
Em programação orientada a objetos, um objeto é uma instância de uma classe, ou
seja, uma variável cujo tipo é uma determinada classe. Um objeto guarda o seu estado atual
(valor de suas propriedades) na memória, e possui um conjunto de operações que podem ser
aplicados a ele.
Herança
Herança é um mecanismo que permite a criação de subclasses de uma classe. Uma
subclasse possui todos os atributos e funcionalidades de uma classe da qual ela deriva, além
de outros definidos por ela.
2.3.3 Linguagem de Modelagem Unificada
A Linguagem de Modelagem Unificada, conhecida por sua sigla em inglês UML
(Unified Modeling Language), é um conjunto de notações gráficas que auxiliam na descrição
e no projeto de sistemas (Fowler, 1997). Essa linguagem é atualmente mantida pelo Object
Management Group (OMG) e, desde 2005, ela é um padrão aceito pela International
Organization for Standardization (ISO).
A UML é utilizada para construir modelos, de forma que todos os envolvidos com o
projeto do sistema possam compreendê-lo e entrarem em um acordo (Rumbaugh et al, 2004).
A linguagem apresenta diversos diagramas que auxiliam na visualização do funcionamento de
um sistema e de seus componentes. Estes diagramas podem ser utilizados também para a
especificação e documentação de sistemas.
Diagrama de Atividades
O diagrama de atividades é um fluxograma no qual as atividades que ocorrem em um
determinado sistema são mostradas em uma sequência lógica. O diagrama é composto por
diversas atividades, representadas por retângulos com cantos arredondados, e por pontos de
tomada de decisão, representados por losangos. O fluxo do processo é desenhado a partir da
conexão entre as atividades e os pontos de tomada de decisão, utilizando setas unidirecionais.
Um diagrama de atividades deve possuir um nó inicial, representado por um círculo preto, e
33
ao menos um nó final, representado por círculos pretos circulados. Um exemplo de diagrama
de atividades pode ser visto na Figura 5, onde um processo de construção é mostrado.
Figura 5 - Exemplo de diagrama de atividades
Fonte: Site Purainfo6.
Diagrama de Classes
O diagrama de classes foi criado especialmente para ser utilizado com a programação
orientada a objetos. Com o diagrama, é possível visualizar cada classe juntamente com as suas
propriedades e os seus métodos. Também é possível modelar a relação entre as diferentes
classes, mostrando como elas estão relacionadas. Como exemplo de um diagrama de classes,
temos na Figura 6 a classe “Funcionário”, que possui duas subclasses, “Gerente” e
“Programador”, cada um com suas propriedades específicas. Além disso, a classe “Gerente”
também possui as suas respectivas subclasses, cada uma adicionando mais propriedades
necessárias.
6 Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso em novembro de 2017.
34
Figura 6 - Exemplo de diagrama de classes
Fonte: Figueiredo, 2016 7.
2.3.4 Extensible markup language
A chamada extensible markup language, conhecida pela sua sigla XML, é uma
linguagem que descreve dados em uma estrutura chamada documento XML. Esta linguagem
foi desenvolvida pelo World Wide Web Consortium (W3C), uma comunidade internacional
formada por diversas organizações a fim de desenvolver padrões para tecnologias web. De
acordo com o próprio W3C (2008), a linguagem diversos objetivos, por exemplo: ser
suportada por uma grande variedade de aplicações; ser fácil de ser criada e processada e
permitir a leitura e o entendimento por pessoas.
Um documento XML é basicamente um arquivo de texto que atende a determinadas
regras. Cada documento contém um ou mais elementos, que são definidos por estruturas
chamadas tags. Existem basicamente três tipos de tag:
1) Tag de início: marca o início de cada elemento XML. Possui o nome de um
elemento entre os símbolos menor (<) e maior (>). Exemplo: “<nome-do-
elemento>”.
2) Tag de fim: marca o fim de cada elemento XML. Deve possuir o mesmo nome
utilizado na tag de início, porém possui uma barra antes do nome do elemento para
que a sua diferenciação possa ser feita. Exemplo: “</ nome-do-elemento>”.
7 Disponível em <http://homepages.dcc.ufmg.br/~figueiredo/>. Acesso em Setembro de 2017.
35
3) Tag vazia: é um elemento XML que junta o início e o fim de um elemento em uma
única estrutura. Termina com uma barra após o nome do elemento. Exemplo:
“<nome-do-elemento />”.
Entre a abertura e o fechamento de um elemento, é possível inserir mais informações,
como texto. Também é possível criar subelementos dentro de um elemento, criando assim
uma estrutura hierárquica no documento com diversos dados.
Outra forma que um documento XML utiliza para o armazenamento de dados são os
chamados atributos. Cada elemento pode possuir diversos atributos, descritos por um nome e
seguido de um valor entre parênteses dentro de um tag de início. Exemplo: “<nome-do-
elemento atributo=“valor”>”.
Um exemplo de um trecho de um documento XML é apresentado na Figura 7, na qual
um arquivo representa uma parte de uma nota fiscal eletrônica. É possível ver que o texto do
arquivo contém informações a respeito do produto vendido, bem como dos impostos
associados à venda.
36
Figura 7 - Exemplo de um documento XML
Fonte: Site WebDANFE 8.
8 Disponível em: <https://www.webdanfe.com.br/danfe/ExemploXml.aspx>. Acesso em novembro de 2017.
37
3 MATERIAIS E MÉTODOS
Neste capítulo, será apresentado o método de desenvolvimento do simulador para
testes de WMSs da empresa. Primeiramente, serão levantadas as necessidades dos usuários do
software, ou seja, os desenvolvedores de sistemas da empresa, tratados como clientes internos
deste projeto. Posteriormente, será apresentada a realização de um benchmarking para
verificar possíveis funcionalidades de softwares de simulação de centros de distribuição. As
funcionalidades identificadas serão utilizadas pelo modelo de satisfação do cliente, proposto
por Kano et al (1984).
3.1 IDENTIFICAÇÃO DAS NECESSIDADES DO CLIENTE
O diretor da empresa percebeu a necessidade de se ter uma plataforma na qual fosse
possível testar os sistemas de gerenciamento de centros de distribuição desenvolvidos pela
empresa. Como descrito na introdução deste trabalho, o teste de sistemas em CDs reais não é
uma tarefa simples, demandando tempo e recursos preciosos tanto para a empresa quanto para
o cliente. Além disso, os centros de distribuição costumam estar localizados em pontos
afastados das grandes concentrações urbanas, local onde vivem os funcionários da empresa.
Assim, o deslocamento até as instalações para a realização de testes também gera um custo
com o transporte na forma de combustível e pedágios, além do tempo necessário para
percorrer o trajeto.
Vale ressaltar que o desenvolvimento da plataforma de testes de WMSs não é a
atividade prioritária dentro da empresa. A prioridade maior é dada ao desenvolvimento dos
projetos de novos sistemas ou de atualizações, projetos que possuem especificações e prazos
de entrega estabelecidos em acordo, bem como a manutenção e suporte de todos os sistemas
desenvolvidos que se encontram em operação nas instalações de clientes. Como a empresa
não possui recursos suficientes para alocar desenvolvedores exclusivamente para a criação do
software de testes, a estratégia foi designar a tarefa ao estagiário da empresa, autor deste
trabalho. Com essa estratégia, além da obtenção do produto final para testar sistemas, o
desenvolvimento do projeto permite um enorme ganho de aprendizado a respeito dos sistemas
desenvolvidos pela empresa, pois o desenvolvimento da plataforma requer interação frequente
com os mesmos.
38
Com o início do projeto, tem-se o objetivo primário de desenvolver um software que
permita testar os WMSs desenvolvidos pela empresa, necessidade explicitada pelos
desenvolvedores que atuam na empresa. Hoje, quando não se tem a disponibilidade de
realizar testes em instalações reais, o que ocorre na grande maioria do tempo, os
desenvolvedores dependem da leitura de extensos arquivos de texto que são gerados como
saída do sistema. A leitura de tais arquivos de texto não é uma forma fácil e intuitiva de
visualizar o comportamento do sistema.
3.2 BENCHMARKING DE SOFTWARES DE SIMULAÇÃO
Para identificar possíveis funcionalidades a serem implementadas no simulador, uma
alternativa é a realização de um benchmarking de softwares de simulação de centros de
distribuição existentes no mercado. A ideia é listar as funcionalidades desses softwares para
posteriormente incluí-las no questionário do modelo de Kano, a fim de identificar aquelas que
são mais importantes para o cliente e aquelas que possuem maior urgência de serem
implementadas.
Existem diversos softwares com capacidade de realizar uma simulação de centros de
distribuição no mercado. Porém, vale ressaltar que nenhum deles permite a realização de
testes de WMSs da forma que a empresa necessita. Eles estão mais centrados na simulação e
validação de layouts e operações. Mesmo assim, eles possuem diversas funcionalidades que
também são interessantes para a empresa que poderiam ser implementadas no simulador
desenvolvido neste trabalho.
Para a realização do levantamento de funcionalidades de um simulador, foram
escolhidos quatro programas presentes no mercado com capacidade de simular as operações
que existem em centros de distribuição: AnyLogic9, FlexSim10, Simcad11 e CLASS12. A partir
da descrição de cada um, baseada no fornecedor do programa, foi feito um levantamento das
funcionalidades existentes. Na Tabela 5, estão listadas as características que cada software
apresenta.
9 Disponível em: <https://www.anylogic.com/>. Acesso em Junho de 2017. 10 Disponível em: <https://www.flexsim.com/>. Acesso em Junho de 2017. 11 Disponível em: <http://www.createasoft.com/>. Acesso em Junho de 2017. 12 Disponível em: <http://cirruslogistics.com/products/class/>. Acesso em Junho de 2017.
39
Tabela 5 – Funcionalidades de softwares de simulação
AnyLogic FlexSim Simcad CLASS
A. Edição de layouts X X X X
B. Importação de layouts (CAD) X X X X
C. Representação gráfica em 2D X X X X
D. Representação gráfica em 3D X X X X
E. Importação de arquivos externos (modelos 3D, imagens)
X X X
F. Coleta de dados estatísticos X X X X
G. Geração de gráficos X X X X
H. Geração de relatórios customizados X
I. Exportar dados para Excel X X
J. Exportar dados para banco de dados X
K. Geração de vídeos de simulações X X
L. Funcionamento em múltiplos sistemas operacionais X
Fonte: Elaborada pelo autor.
A partir do levantamento dessas funcionalidades, podemos prosseguir para a
elaboração do questionário do modelo da satisfação do cliente de Kano, a fim de determinar a
classificação de cada uma.
3.3 QUESTIONÁRIO DO MODELO DE KANO
Um questionário seguindo as diretrizes do modelo da satisfação do cliente foi
elaborado e encontra-se no Apêndice A deste trabalho. Neste questionário, para cada uma das
doze funcionalidades do simulador levantadas no benchmarking realizado anteriormente, são
feitas duas perguntas a fim de se encontrar a classificação de cada atributo, totalizando vinte e
quatro perguntas.
40
3.3.1 Respostas
As respostas obtidas por meio da aplicação do questionário aos clientes encontram-se
resumidas na Tabela 6. A primeira coluna mostra a resposta para a pergunta funcional, ou
seja, perguntando como o cliente se sentiria caso o produto oferecesse determinada
funcionalidade. A segunda coluna mostra a resposta para a pergunta disfuncional, isto é,
perguntando como o cliente se sentiria no caso contrário, caso o produto não apresentasse a
funcionalidade em questão.
Tabela 6 – Resumo das respostas às perguntas do questionário de Kano
Pergunta
funcional
Pergunta
disfuncional
A. Edição de layouts Obrigatório Insatisfeito
B. Importação de layouts (CAD) Indiferente Indiferente
C. Representação gráfica em 2D Satisfeito Insatisfeito
D. Representação gráfica em 3D Obrigatório Insatisfeito
E. Importação de arquivos externos (modelos 3D,
imagens) Obrigatório Insatisfeito
F. Coleta de dados estatísticos Obrigatório Insatisfeito
G. Geração de gráficos Satisfeito Neutro
H. Geração de relatórios customizados Satisfeito Neutro
I. Exportar dados para Excel Obrigatório Insatisfeito
J. Exportar dados para banco de dados Satisfeito Insatisfeito
K. Geração de vídeos de simulações Satisfeito Neutro
L. Funcionamento em múltiplos sistemas operacionais Neutro Satisfeito
Fonte: Elaborada pelo autor.
3.3.2 Classificação dos atributos
A partir dos resultados obtidos por meio da aplicação do questionário, foi possível
classificar os atributos do produto nas categorias do modelo de Kano. As respostas para cada
funcionalidade estão resumidas na Tabela 7.
41
Tabela 7 - Avaliação das funcionalidades
Questãodisfuncional
Satisfeito Aceitável Indiferente Obrigatório Insatisfeito
Questão
funcional
Satisfeito - - G,H,K - C,J
Aceitável - - - - -
Indiferente L - B - -
Obrigatório - - - - A,D,E,F,I
Insatisfeito - - - - -
Fonte: Elaborada pelo autor.
Comparando as respostas obtidas com a aplicação do questionário à tabela de
classificação dos atributos do modelo sendo utilizado, podemos finalmente classificar as
funcionalidades do simulador nas seguintes categorias: qualidade atrativa, qualidade
unidimensional, qualidade obrigatória, qualidade reversa e qualidade indiferente, conforme
podemos ver na Tabela 8.
Tabela 8 - Classificação dos atributos do produto
Funcionalidade Característica
A. Edição de layouts Obrigatória
B. Importação de layouts (CAD) Indiferente
C. Representação gráfica em 2D Unidimensional
D. Representação gráfica em 3D Obrigatória
E. Importação de arquivos externos (modelos 3D, imagens) Obrigatória
F. Coleta de dados estatísticos Obrigatória
G. Geração de gráficos Atrativa
H. Geração de relatórios customizados Atrativa
I. Exportar dados para Excel Obrigatória
J. Exportar dados para banco de dados Unidimensional
K. Geração de vídeos de simulações Atrativa
L. Funcionamento em múltiplos sistemas operacionais Reversa
Fonte: Elaborada pelo autor.
42
3.3.3 Análise dos resultados
Uma vez obtidas as classificações de cada um dos atributos do simulador, é preciso
realizar uma análise para entender o resultado e validar o modelo utilizado.
A funcionalidade de edição de layouts foi classificada como obrigatória, pois é preciso
existir uma forma de descrever um layout de uma instalação dentro do software desenvolvido.
Editar um layout sem ser dentro do próprio programa, como por exemplo, editar manualmente
o conteúdo de dentro de um arquivo, é uma prática inviável em praticamente todos os
programas de computador.
A funcionalidade de importação de arquivos de CAD foi classificada como indiferente
pois esses arquivos possuem uma descrição física detalhada de cada layout, contendo as
localizações e as dimensões precisas de cada elemento existente na instalação. Em uma
simulação, nós estamos interessados na descrição lógica de um layout. Sendo assim, um
arquivo CAD conteria muitos elementos desnecessários à simulação. Se por um lado eles
acrescentariam um maior realismo, por outro lado os elementos adicionais poluiriam a
visualização dos elementos mais importantes.
Com relação à representação gráfica da simulação, a representação em 2D foi
classificada como unidimensional, enquanto a representação em 3D foi classificada como
obrigatória. Muitos layouts possuem elementos em diferentes alturas, portanto uma
visualização tridimensional seria fundamental para uma melhor compreensão do ambiente,
além de ser mais interessante e tornar o simulador um serviço mais atraente e,
consequentemente, mais fácil de ser vendido a clientes interessados. A representação em 2D
também é importante, pois muitas vezes uma visualização simplificada de uma parte
específica da simulação auxilia na compreensão do modelo.
A funcionalidade de coleta de dados estatísticos da simulação foi classificada como
obrigatória, o que já era esperado pois tais dados são o resultado principal que se espera de
qualquer simulação. Como consequência, a exportação de dados para planilhas Excel®
também foi classificada como uma funcionalidade obrigatória, já que dessa forma os dados
poderão ser analisados da forma que o usuário desejar. As funcionalidades de geração de
gráficos e geração de relatórios customizados foram classificadas como atrativas, já que se
espera que a análise da simulação seja feita principalmente por meio de planilhas. Ainda
dentro da análise dos resultados da simulação, há a funcionalidade de exportação de dados
43
para banco de dados, classificada como unidimensional. Em um banco de dados, de forma
semelhante a planilhas eletrônicas, também é possível realizar análises variadas de acordo
com a necessidade do usuário.
O atributo de geração de vídeos de simulações foi classificado como atrativo já que
não se trata de um fator indispensável para o software, apesar de ser interessante poder gravar
simulações para fins de divulgação do serviço a possíveis clientes interessados.
Por fim, o funcionamento do simulador em múltiplos sistemas operacionais foi
classificado como um atributo reverso. Não se vê a necessidade dentro da empresa de que o
simulador funcione em outro sistema operacional que não seja o Windows®. Caso o
programa funcionasse em diversos sistemas operacionais, isso se traduziria em mais linhas de
código, resultando em uma maior dificuldade de manutenção do software, bem como uma
maior susceptibilidade a erros.
3.4 ESCOLHA DO AMBIENTE DE DESENVOLVIMENTO INTEGRADO
Para o desenvolvimento de softwares, é necessário utilizar um ambiente de
desenvolvimento integrado adequado. Por um ambiente de desenvolvimento integrado, ou
simplesmente IDE (integrated development environment), entende-se um programa de
computador que reúne diversas funcionalidades essenciais para o desenvolvimento de
softwares, como um editor de código, um compilador e um depurador.
Existem diversos IDEs largamente utilizados no mercado. Sendo assim, é necessário
escolher aquele que melhor se adeque às necessidades e características deste projeto. Para
realizar tal escolha, utilizaremos o processo analítico hierárquico, dadas as vantagens de sua
utilização discutidos anteriormente. O objetivo da utilização desta ferramenta é a escolha da
IDE mais adequada para o desenvolvimento do simulador proposto.
3.4.1 Definição dos critérios de seleção
Após a definição do objetivo do AHP, o primeiro passo é a definição de quais critérios
de seleção serão utilizados. São diversas as características que nos fazem priorizar um IDE
em relação a outra, descritas a seguir.
44
Custo
O custo é um fator relevante para qualquer projeto, e para a seleção do ambiente de
desenvolvimento pode vir a ser um fator determinante. Busca-se priorizar a ferramenta que
tenha o menor custo de aquisição. Comparar o custo entre várias alternativas, nesse projeto, é
uma tarefa relativamente simples, já que os preços de ambientes de desenvolvimento
costumam ser tabelados.
Base de código
O desenvolvimento de software é uma atividade que conta com diversos exemplos em
sites especializados. Quanto maior a base de código que utiliza determinado IDE, mais fácil é
o desenvolvimento devido à disponibilidade e ao fácil acesso a projetos de código aberto.
Assim, busca-se o IDE que possua suporte às linguagens de programação com a maior
presença de código aberto.
Para mensurar a base de código de uma determinada linguagem de programação, é
possível utilizar a plataforma oferecida pelo site GitHub, o maior servidor de códigos do
mundo, contando com 5 milhões de desenvolvedores colaborando em 10 milhões de
repositórios de código (Gousios et al, 2014). Utilizando o nome de uma linguagem de
programação como palavra-chave na ferramenta de pesquisa da plataforma, é possível
mensurar e comparar a base de código de cada uma.
Suporte
Todo IDE necessita de suporte para a sua correta utilização. Por isso, o suporte é um
critério de seleção que não pode ser descartado. Para mensurar e comparar o suporte entre os
diferentes ambientes de desenvolvimento, poderá ser utilizado um critério semelhante ao
utilizado para a base de código, porém com outra plataforma. O site de perguntas e respostas
para desenvolvedores chamado Stack Overflow, de acordo com o resultado de sua pesquisa
anual13, recebeu em 2017 cerca de 40 milhões de visitas mensalmente, dos quais estima-se
que 16,8 milhões sejam desenvolvedores profissionais ou estudantes em nível universitário.
A ferramenta de pesquisa desse site permite a utilização de palavras-chave pré-
definidas, sendo possível utilizar o nome de um ambiente de desenvolvimento para tal
13 Disponível em <https://insights.stackoverflow.com/survey/2017>. Acesso em Junho de 2017.
45
finalidade. Assim, de acordo com o número de resultados retornados, é possível mensurar e
comparar os diferentes IDEs com relação ao suporte de cada um.
Familiaridade
A experiência prévia com a utilização de determinado ambiente de desenvolvimento é
importante, pois implica em menores esforços e recursos despendidos para aprender a utilizar
todas as funcionalidades que o programa oferece. Utilizar um ambiente de desenvolvimento
que já se tenha tido experiência prévia também permite um trabalho mais ágil e com menor
chance de cometer erros.
Funcionalidades
Cada IDE deve oferecer funcionalidades básicas que permitam o desenvolvimento de
softwares. Porém, eles podem possuir funcionalidades adicionais diversas que faz com que
eles se destaquem uns em relação aos outros.
Existem outros critérios de seleção que poderiam ser considerados quando queremos
escolher um ambiente de desenvolvimento integrado que será utilizado extensivamente ao
longo do projeto, como por exemplo a usabilidade. Porém, é muito difícil mensurar este
critério, pois seria necessária a realização de diversos testes de usabilidade e ergonomia
comparando os candidatos. Assim, para efeitos da utilização do AHP, os critérios descritos
anteriormente serão suficientes para nossa análise.
3.4.2 Definição das alternativas
O passo seguinte na aplicação do processo analítico hierárquico é a enumeração das
alternativas a serem escolhidas. Para isso, foram levantados os principais ambientes de
desenvolvimento utilizados no desenvolvimento de softwares, descritos a seguir:
a) Microsoft Visual Studio: é o principal ambiente de desenvolvimento da Microsoft.
Oferece diversas funcionalidades, dentre elas a possibilidade de criar layouts de
interface do usuário a partir de controles pré-definidos;
b) Eclipse: é um ambiente de desenvolvimento amplamente utilizado para projetos
escritos na linguagem de programação Java. Trata-se de um software gratuito e de
código aberto;
46
c) IntelliJ Idea: é um IDE utilizado para o desenvolvimento de projetos em Java. Possui
uma versão gratuita de código aberto e uma versão comercial paga.
d) NetBeans: é mais um IDE gratuito e de código aberto, sendo um software
multiplataforma.
e) MonoDevelop: similar ao anterior, é um software multiplataforma, gratuito e de
código aberto. Oferece suporte a diversas linguagens de programação.
3.4.3 Comparação dos critérios de seleção
Para realizar o cálculo das notas de cada alternativa para a seleção daquela que melhor
se adequa às necessidades do projeto, é preciso definir o peso de cada critério utilizado.
Assim, elaborou-se a matriz de julgamentos de acordo com o descrito no processo analítico
hierárquico. As matrizes do AHP estão no Apêndice B deste trabalho. O resultado obtido está
sumarizado na Tabela 9.
Tabela 9 - Peso dos critérios de seleção do AHP
Critério de Seleção Peso atribuído
Custo 0,36
Base de Código 0,10
Suporte 0,10
Familiaridade 0,20
Funcionalidades 0,24
Fonte: Elaborada pelo autor.
Podemos ver que o critério mais importante foi o custo, pois estamos trabalhando em
um projeto com recursos limitados. Em segundo lugar, temos o critério de funcionalidades.
Não basta ser um programa barato se ele oferecer poucos recursos. Em terceiro, temos a
familiaridade, outro fator de decisão importante em nossa análise. Por fim, os critérios de
seleção de base de código e de suporte foram os critérios avaliados com menor impacto na
decisão a ser tomada, já que se trata de características acessórias à utilização de um
determinado software.
47
3.4.4 Comparação das alternativas
Uma vez calculados os pesos de cada critério de seleção, cabe fazer uma comparação
entre as alternativas para cada critério levado em consideração.
Com relação ao custo de aquisição de cada IDE, foi elaborada a Tabela 10, permitindo
uma comparação entre as alternativas quanto ao critério de custo. Podemos observar que, das
cinco alternativas, três são gratuitas, enquanto as outras duas apresentam duas versões: uma
paga e uma também gratuita.
Tabela 10 – Preço de aquisição dos IDEs
IDE Preço
Microsoft Visual Studio Visual Studio Community – Gratuito; Visual
Studio Professional – 499 dólares / ano14
Eclipse Gratuito15
IntelliJ IDEA IntelliJ IDEA Community – Gratuito; IntelliJ
IDEA Ultimate – 499 dólares / ano16
NetBeans Gratuito17
MonoDevelop Gratuito18
Fonte: Elaborada pelo autor.
Para avaliar cada IDE com relação à base de código existente, devemos escolher uma
linguagem de programação de cada IDE para avaliar a existência de projetos de código
aberto. Para desenvolver o software deste projeto, vamos escolher a linguagem de
programação que suporte a programação orientada a objetos, e também dar preferência
àquelas de mais alto nível. Tanto o IDE Eclipse, IntelliJ IDEA e MonoDevelop, são utilizados
principalmente para o desenvolvimento de projetos em Java, enquanto o Visual Studio e o
MonoDevelop são utilizados principalmente para o desenvolvimento de projetos em C#.
Sendo assim, podemos pesquisar a quantidade de projetos em cada linguagem na plataforma
de projetos de código aberto GitHub, obtendo a Tabela 11.
14 Disponível em: <https://www.visualstudio.com/pt-br/vs/pricing/>. Acesso em Junho de 2017. 15 Disponível em: <https://www.eclipse.org/home>. Acesso em Junho de 2017. 16 Disponível em: <https://www.jetbrains.com/idea/buy/#edition=commercial>. Acesso em Junho de 2017. 17 Disponível em: < https://netbeans.org/features/index.html Acesso em Junho de 2017. 18 Disponível em: <http://www.monodevelop.com/>. Acesso em Junho de 2017.
48
Tabela 11 – Número de projetos de código aberto
Linguagem de Programação Quantidade de projetos
Java 1.244.695
C# 304.580
Fonte: Pesquisa na plataforma GitHub 19.
Já para mensurar o suporte, conforme mencionado anteriormente, será utilizada a
plataforma Stack Overflow, onde é possível pesquisar o nome de cada IDE como palavra-
chave. A Tabela 12 resume a medida utilizada para atribuir notas ao suporte.
Tabela 12 – Número de perguntas relacionadas a cada IDE
IDE Número de perguntas
Microsoft Visual Studio 73.207
Eclipse 109.483
IntelliJ IDEA 23.818
NetBeans 20.806
MonoDevelop 2.448
Fonte: Stack Overflow.
Comparando as alternativas a serem escolhidas, elaborou-se uma matriz de
julgamentos para cada um dos critérios de seleção. Utilizando as notas atribuídas a cada um
dos critérios juntamente com o peso de cada um, obtivemos as seguintes pontuações finais,
resumidas na Tabela 13.
Tabela 13 – Notas finais para cada alternativa
IDE Nota final
Microsoft Visual Studio 0,24
Eclipse 0,21
IntelliJ IDEA 0,17
NetBeans 0,18
MonoDevelop 0,20
Fonte: Elaborada pelo autor.
19 Disponível em: <https://github.com/search/advanced>. Acesso em setembro de 2017.
49
Assim, para o desenvolvimento do simulador de centros de distribuição, o programa
Microsoft Visual Studio foi o ambiente de desenvolvimento escolhido.
3.5 SIMULAÇÃO
Uma vez definidas as funcionalidades do simulador, juntamente com suas respectivas
prioridades, é preciso definir o que será abordado em uma simulação: o seu escopo, os seus
elementos principais e os resultados esperados.
3.5.1 Escopo
A simulação compreende a movimentação de unidades de carga dentro de um centro
de distribuição. O layout de um CD possui esteiras transportadoras como entradas e saídas do
armazém. Nas entradas, espera-se poder adicionar novas cargas a partir de um botão,
especificando-se as suas características como peso, volume e código de barras. Já com relação
às saídas, para simular a retirada das cargas das mesmas, espera-se que as cargas desapareçam
automaticamente para evitar que se acumulem. Também é preciso que seja possível enviar
ordens de movimentação de cargas dos corredores de armazenagem a um destino específico.
Todas as ordens de movimentação são feitas a partir do WMS, ao qual o simulador estará
conectado. Dessa forma, o usuário do software pode testar funcionalidades do sistema da
empresa, podendo observar qual destino cada carga é enviada.
3.5.2 Elementos
Um elemento indispensável para uma simulação é a unidade de carga. Ela deve
representar uma caixa ou um palete, por exemplo. Além dela, outro elemento importante é a
esteira transportadora, sobre as quais as cargas serão movimentadas entre pontos importantes
dentro de um centro de distribuição.
Como a proposta é a de simular um CD automatizado, é natural precisarmos
representar também os corredores automatizados, como os AS/RS. Existem diversos modelos
no mercado, mas com apenas o corredor de transelevador e o corredor multishuttle já é
possível cobrir a grande maioria dos armazéns dos clientes da empresa.
Resumindo, uma simulação compreende basicamente três elementos: unidades de
carga, esteiras transportadoras e corredores de armazenagem.
50
3.5.3 Resultados
Como ocorre em toda simulação, estamos interessados em seu resultado. Dentro do
nosso escopo, esperamos como resultado mínimo um registro da troca de mensagens entre o
simulador e o WMS. Além disso, esperamos ter registros de certos eventos ocorridos, como a
chegada de uma unidade de carga a um certo destino juntamente com o tempo associado ao
evento, para que posteriormente seja possível calcular dados estatísticos da simulação.
3.6 FERRAMENTAS
Para a implementação propriamente dita das funcionalidades levantadas, além do
ambiente de desenvolvimento integrado escolhido, existe a necessidade de se utilizar outras
ferramentas importantes para atingir o objetivo esperado. Para a seleção das ferramentas a
serem utilizadas, não se adotou um processo de decisão rigoroso como o utilizado
anteriormente para a seleção do ambiente de desenvolvimento pois, como visto, o AHP é um
método complexo de ser aplicado. As demais ferramentas necessárias, diferentemente do IDE,
serão utilizadas para necessidades pontuais.
3.6.1 Formato de arquivos
De acordo com as respostas do questionário do modelo de Kano, um dos atributos
classificados como obrigatórios foi a edição de layouts. Espera-se que o usuário do simulador
possa editar um layout de um centro de distribuição adicionando, movendo e editando
elementos como esteiras transportadoras, estações de picking e corredores de armazenagem.
Uma vez que o layout esteja pronto, é fundamental que o usuário possa salvá-lo em um
arquivo para uso posterior. Seria inaceitável perder o layout construído toda vez que o
programa fosse fechado. Assim, é preciso definir um formato de arquivo que possa ser gerado
toda vez que o usuário deseje salvar um layout criado e ser lido toda vez que o usuário deseje
carregar um layout editado previamente. A linguagem XML aparece como ideal para este
requisito, pois é uma linguagem flexível e também é suportada pela plataforma de
desenvolvimento escolhida.
51
3.6.2 Criação de modelos na linguagem de modelagem unificada (UML)
A linguagem de modelagem unificada define diversos diagramas que podem ser
utilizados para a elaboração e para a documentação de modelos e fluxogramas utilizados no
desenvolvimento do programa. Os diagramas poderiam ser desenhados em qualquer programa
que permita o desenho de formas geométricas simples, bastando seguir os padrões
estabelecidos pela UML. Porém, é interessante utilizar uma ferramenta apropriada para a
criação dos diagramas, como o UMLet20.
3.6.3 Criação de modelos em 3D
Um outro atributo classificado como obrigatório pela aplicação do modelo da
satisfação do cliente de Kano foi a representação gráfica em 3D das simulações. Para isso, é
necessário criar modelos tridimensionais para serem utilizados, representando os elementos
de um centro de distribuição, como paletes, caixas, esteiras e corredores. Seguindo a mesma
linha de raciocínio de optar por programas de código aberto, devido à sua gratuidade e
informações acessíveis, optou-se pelo software chamado Blender21.
O Blender possui diversas funcionalidades projetadas especificamente para a criação
de modelos para posteriormente exportá-los para diferentes formatos de arquivo. Para a nossa
simulação, é preciso escolher ao menos um formato que será suportado para realizar a
importação do mesmo para o programa. O formato do arquivo deve ser simples, descrevendo
os dados necessários para renderizar um modelo na aplicação. Não é necessário que o formato
de arquivos escolhido suporte animações, pois para a simulação todos os modelos necessários
são estáticos. Sendo assim, escolheu-se o formato .obj devido à sua simplicidade.
Para entender a especificação do formato, foi criado um tetraedro no programa para
ser usado como exemplo, devido à simplicidade dessa forma geométrica. Na Figura 8,
podemos ver o modelo criado no programa.
20 UMLet é um programa gratuito de código aberto para desenhar diagramas em conformidade com a linguagem de modelagem unificada. Disponível em: <http://www.umlet.com/>. Acesso em Setembro de 2017. 21 Blender é um programa gratuito de código aberto que oferece diversas funcionalidades para trabalhos em 3D, dentre elas a criação de modelos tridimensionais. Disponível em: <https://www.blender.org/about/>. Acesso em Setembro de 2017.
52
Figura 8 - Modelo de tetraedro
Fonte: Modelado pelo autor com o Blender.
Em seguida, o modelo foi exportado para um arquivo no formato .obj, que contém os
dados apresentados na Figura 9.
Figura 9 - Exemplo de arquivo .obj descrevendo um tetraedro
Fonte: Gerado pelo autor com o Blender.
Um arquivo .obj contém quatro tipos de informação:
1) Coordenadas dos vértices: são indicados pela letra “v”, e contém as coordenadas x, y e
z de cada vértice do modelo;
2) Coordenadas de textura: são indicados pelas letras “vt”, e são utilizadas para mapear
os vértices no espaço tridimensional para uma imagem bidimensional. É um atributo
opcional.
53
3) Vetores normais: são indicados pelas letras “vn”, e são utilizados para indicar vetores
unitários normais a cada superfície do modelo.
4) Faces poligonais: são indicados pela letra “f”. Cada face é determinada por um
conjunto de dados de um vértice, preferencialmente três. Uma face contém o índice de
qual vértice, coordenadas de textura e vetores normais, respectivamente, a face deve
utilizar.
Podemos observar que o formato de arquivos .obj é bastante simples, mas é suficiente
para a nossa aplicação.
3.6.4 Biblioteca para renderização gráfica
Para o desenvolvimento de uma aplicação que apresente a renderização de gráficos
tridimensionais, é preciso utilizar alguma biblioteca que permita ao programa ter acesso à
unidade de processamento gráfico do computador (graphics processing unit ou GPU). A GPU
de um computador é o que permite renderizar gráficos tridimensionais em tempo real, sendo
projetada especialmente para cálculos rápidos com matrizes e vetores, elementos
fundamentais para qualquer aplicação gráfica.
O ambiente de desenvolvimento escolhido não apresenta por padrão esta
funcionalidade, sendo necessário recorrer a uma biblioteca de código externa. Uma das
bibliotecas com melhor avaliação na plataforma GitHub é a chamada OpenTK, criada com a
finalidade de gerar gráficos acelerados pela GPU utilizando a linguagem de programação C#.
Por ser uma biblioteca de código aberto, é menos provável que o projeto seja descontinuado
quando comparado a uma biblioteca de uma empresa privada, como ocorreu com o DirectX,
da Microsoft, contraindicado pela própria empresa 22. Assim, a biblioteca OpenTK será
utilizada como parte fundamental para o desenvolvimento do simulador.
3.7 DEFINIÇÃO DAS CLASSES
Para desenvolver um programa que atenda aos fatores de qualidade em software, é
preciso planejar bem as principais classes que farão parte do código do simulador. As classes
22 Segundo a Microsoft, a tecnologia DirectX foi descontinuada e existe somente para suportar aplicações já existentes, não sendo recomendada para novas aplicações. Disponível em: <https://msdn.microsoft.com/en-us/library/windows/desktop/hh309465(v=vs.85).aspx>. Acesso em Setembro de 2017.
54
podem ser pensadas como componentes do programa, onde cada uma cumpre uma função
específica que lhe for designada. O planejamento das classes do simulador deve ser feito antes
do início da implementação do programa, pois o custo de mudança ao longo do ciclo de vida
de desenvolvimento do software cresce com o tempo. A eventual alteração de uma classe que
já está sendo utilizada em diversas partes do programa gera um enorme retrabalho.
A classe mais importante do programa é a classe “Elemento”, que representa qualquer
elemento da simulação em um espaço tridimensional. Desta classe, derivam outras três classes
importantes: as classes “Unidade de carga”, “Contentor de unidade de carga” e “Corredor”.
Elas constituem a base para todos os demais elementos da simulação. Também é importante
definirmos uma classe “Câmera”, para podermos navegar pelo espaço e visualizar os pontos
mais importantes do centro de distribuição que se deseja simular.
3.7.1 Classe “Elemento”
Para representar os elementos da simulação, é preciso criar uma classe base que
contenha as propriedades comuns a todos. Todos os elementos da simulação são
representados por um modelo em 3D, que possui uma posição e uma orientação no espaço.
Para trabalhar com o posicionamento no espaço tridimensional, é necessário que cada
elemento contenha uma matriz de transformação, que é o resultado da multiplicação de uma
matriz de translação com uma matriz de rotação em torno de cada um dos eixos. Os elementos
também podem ser organizados em uma hierarquia. Exemplos: quando um transelevador se
move, todos os seus garfos também se movem em conjunto; quando uma esteira
transportadora é movida, as caixas que estão sobre ela também se movem. Portanto, podemos
dizer que os garfos são elementos filhos do elemento transelevador, enquanto o transelevador
é um elemento pai em relação a eles. Para trabalhar com o posicionamento hierárquico, a
matriz de transformação de cada elemento é multiplicada pela matriz de seu elemento pai. A
esta classe damos o nome de Elemento. Podemos identificar os principais atributos dessa
classe na Tabela 14.
55
Tabela 14 – Atributos da classe “Elemento”
Atributo Tipo Descrição
Posição Vetor A posição do elemento nos eixos X, Y e Z.
Rotação Vetor A rotação do elemento ao redor dos eixos X, Y e Z.
Transformação Matriz A matriz de transformação do elemento.
Pai Elemento O pai do elemento na hierarquia da simulação.
Filhos Elemento[0..*] Uma lista com os filhos do elemento na hierarquia da
simulação.
Modelo Modelo O modelo 3D do elemento.
Cor Cor A cor de exibição do elemento.
Fonte: Elaborada pelo autor.
Para se obter a matriz de transformação de um elemento em seu sistema de
coordenadas local, é feito o cálculo da equação (3).
𝑀0 = 𝑅1𝑅2𝑅3𝑃(3)
Onde:
𝑀0 = Matriz de transformação local
𝑅1 = Matriz de rotação ao redor do eixo X
𝑅2 = Matriz de rotação ao redor do eixo Y
𝑅3 = Matriz de rotação ao redor do eixo Z
𝑃 = Matriz de translação
Porém, para renderizar um modelo em um sistema de coordenadas ao nível da
simulação, é preciso obter a matriz de transformação de um elemento em um sistema de
coordenadas global. Para isso, existem duas possibilidades: um elemento pode estar contido
em um outro elemento ou não. Caso esteja, utiliza-se a equação (4). Caso não esteja, utiliza-se
a equação (5).
𝑀6 = 𝑀7M9(4)
𝑀6 = 𝑀0(5)
56
Onde:
𝑀6 = Matriz de transformação global
𝑀7 = Matriz de transformação global do elemento pai
Como métodos da classe Elemento, temos duas que são imprescindíveis para a
simulação: a função “atualizar” e a função “converter para XML”:
1) Atualizar: esta função, com um único parâmetro indicando o tempo que se passou
desde a última atualização, deve atualizar as propriedades do próprio elemento.
2) Converter para XML: esta função deve criar um elemento XML que descreva o
elemento de simulação. Ela é muito importante para a geração do arquivo XML
que descreve um layout de um centro de distribuição.
3.7.2 Classe “Unidade de Carga”
Uma unidade de carga é um dos principais elementos de uma simulação. Esta classe é
a base para caixas e paletes, e deriva da classe “Elemento”. Uma unidade de carga precisa ter
um número de identificação único para rastreamento dentro de um centro de distribuição, bem
como um código de barras para leitura em escâneres. Cada unidade de carga também possui
dimensões e um peso. Durante uma simulação, o sistema atribui destinos para cada unidade
de carga, sinalizando para onde cada uma delas precisa ser movida. Também é interessante
armazenar os locais por onde uma carga passou. Os principais atributos da classe estão na
Tabela 15.
Tabela 15 – Atributos da classe “Unidade de Carga”
Atributo Tipo Descrição
Identificação Número inteiro Número de identificação único para rastreamento.
Código de barras Texto Código de barras da unidade de carga.
Peso Número inteiro Peso da unidade de carga, em gramas.
Dimensões Tamanho Tamanho da unidade de carga, em milímetros.
Destino Texto Identificação do destino da unidade de carga.
Histórico Contentor de unidade
de carga[0..*]
Armazena todos os locais por onde a unidade de
carga passou.
Fonte: Elaborada pelo autor.
57
3.7.3 Classe “Contentor de unidade de carga”
A qualquer momento durante uma simulação, uma unidade de carga pode estar
contida em outro elemento como, por exemplo, em uma esteira transportadora, em um garfo
de um transelevador ou em uma estação de picking. Sendo assim, faz sentido pensarmos em
uma classe que sirva como base para todos estes elementos que podem conter uma unidade de
carga, pois eles possuem muitas propriedades em comum.
Cada contentor deve possuir um nome de identificação. Um contentor de unidade de
carga também deve possuir uma lista das unidades de cargas nele contidas, bem como a
quantidade máxima que ele pode suportar simultaneamente. Por fim, esta classe deve possuir
propriedades booleanas (verdadeiro / falso) para indicar se ele deve trocar mensagens com o
sistema quando acontecem alguns eventos. Assim, os principais atributos da classe estão
descritos na Tabela 16.
Tabela 16 – Atributos da classe “Contentor de unidade de carga”
Atributo Tipo Descrição
Identificação Texto Nome do contentor para identificação única no sistema.
Unidades de
Carga
Unidade de
Carga[0..*] Lista de unidades de carga no contentor.
Capacidade Inteiro Capacidade máxima de unidades de carga do contentor.
Notifica saída Booleana Indica se uma mensagem deve ser enviada ao sistema
quando uma unidade de carga sai do contentor.
Notifica entrada Booleana Indica se uma mensagem deve ser enviada ao sistema
quando uma unidade de carga entra no contentor.
Requer destino Booleana Indica se um destino deve ser pedido ao sistema quando
uma unidade de carga entra no contentor.
Fonte: Elaborada pelo autor.
3.7.4 Classe “Corredor”
Em um centro de distribuição, as unidades de carga são estocadas em corredores de
armazenagem. O conceito de um corredor é simples, cada um possui um nome de
identificação, um número e a quantidade de níveis de armazenagem, conforme a Tabela 17.
58
Tabela 17 – Atributos da classe “Corredor”
Atributo Tipo Descrição
Identificação Texto Nome do corredor para identificação única no sistema.
Número Número inteiro Número do corredor
Níveis Número inteiro Quantidade de níveis de armazenagem do corredor.
Fonte: Elaborada pelo autor.
3.7.5 Classe “Esteira transportadora”
Uma esteira transportadora é um dos elementos que compõem um layout de um centro
de distribuição. É uma subclasse da classe “Contentor de unidade de carga”. Cada esteira
possui uma lista de outras esteiras que são antecessoras a si no fluxo de movimento de
unidades de carga, e outra lista que das esteiras sucessoras a si. Uma esteira também tem um
comprimento, além de uma velocidade com que ela movimenta as unidades de carga. A
velocidade é uma propriedade importante, pois ela afeta diretamente o resultado de uma
simulação. Outra propriedade é uma que indica se a esteira é uma entrada e outra que indica
se ela é uma saída por onde unidades de carga podem ser depositadas ou retiradas. Os
atributos desta classe estão descritos na Tabela 18.
Tabela 18 – Atributos da classe “Esteira transportadora”
Atributo Tipo Descrição
Sucessoras Esteira Transportadora[0..*] Lista de esteiras transportadoras para as quais
unidades de carga podem ser movidas.
Antecessoras Esteira Transportadora[0..*] Lista de esteiras transportadoras que podem
mover unidades de carga para a esteira.
Comprimento Número Comprimento da esteira, em metros
Velocidade Número Velocidade de movimento de unidades de
carga na esteira, em metros por segundo.
Entrada Booleana Indica se a esteira é uma entrada do sistema.
Saída Booleana Indica se a esteira é uma saída do sistema.
Fonte: Elaborada pelo autor.
59
Um layout é construído a partir de um conjunto de esteiras transportadoras de diversos
tipos: esteiras retas, curvas, bifurcações, rampas etc. Cada tipo possui as suas propriedades
específicas, como tamanho, raio da curvatura, tipo de bifurcação, inclinação da rampa entre
outros. Sendo assim, cada esteira diferente dá origem a uma subclasse específica: “Esteira
reta”, “Esteira curva”, “Esteira em rampa para cima”, “Esteira em rampa para baixo”, “Esteira
em convergência” e “Esteira em divergência”.
3.7.6 Classe “Câmera”
Para a reprodução de gráficos em 3D, além da matriz de transformação de cada
elemento, são necessárias mais duas matrizes: uma para posicionar uma câmera no espaço,
em um ponto do qual o observador enxerga o restante dos elementos; outra para projetar as
coordenadas em três dimensões para duas, a chamada matriz de projeção.
A matriz que posiciona uma câmera no espaço é o inverso da matriz de transformação
de uma câmera que possui determinada posição e rotação, conforme a equação 6:
𝑉 = 𝑀=>?(6)
Onde:
𝑉 = Matriz que posiciona elementos em frente a um ponto de observação no espaço
𝑀= = Matriz de transformação global da câmera
Por fim, para cada elemento que deve ser renderizado, é calculada uma matriz de
transformação, conforme a equação 7:
𝑇 = 𝑀=𝑉𝑃(7)
Onde:
𝑇 = Matriz de transformação para renderização
𝑃 = Matriz de projeção da câmera
Para a simulação, existem dois tipos interessantes de matriz de projeção: uma para a
projeção ortográfica e outra para a projeção em perspectiva.
60
3.7.7 Sumário das classes
Além das classes apresentadas anteriormente, o programa possui muitas outras que
não serão detalhadas para que a descrição não se estenda demasiadamente. Para a visualização
da estrutura geral do programa, foi desenvolvido um diagrama de classes de acordo com a
linguagem de modelagem unificada. No diagrama desenvolvido, na Figura 10, é possível ver
que todas as classes da simulação derivam da classe “Elemento”, herdando assim todas as
suas propriedades. Cada subclasse adiciona as suas próprias especificidades.
Como discutido anteriormente no detalhamento das classes, existem três classes
principais que são importantes para a simulação. A primeira delas é a unidade de carga, que
possui duas subclasses aparentes: caixas e paletes. Uma caixa tem como propriedade
adicional o seu tipo, assim como o palete. A segunda classe importante para a simulação é o
contentor de unidade de carga, que pode aparecer na forma de uma esteira, um garfo, um
elevador, um shuttles ou um raque, todos os elementos que podem possuir unidades de carga
associados. A terceira classe é um corredor de armazenamento, a qual em princípio possui
duas subclasses: corredores de transelevador e corredores de multishuttle.
No diagrama de classes, foram omitidos os tipos de cada propriedade para que o
diagrama não ficasse demasiadamente extenso e de um tamanho razoável. Com o
planejamento de cada classe que fará parte de uma simulação, finalmente partimos para a
efetiva implementação delas utilizando as ferramentas selecionadas.
61
Figura 10 – Diagrama de classes do simulador
Fonte: Elaborada pelo autor com o UMLet.
62
63
4 RESULTADOS
A partir das funcionalidades levantadas pela realização do benchmarking e pela
priorização de cada uma com a aplicação do modelo da satisfação do cliente, foi possível
realizar a implementação das classes definidas previamente utilizando as ferramentas
selecionadas.
Todas as classes definidas no diagrama de classes foram implementadas na linguagem
C# no Visual Studio. Durante a programação, foram acrescentadas outras propriedades que se
mostraram necessárias. Porém, a estrutura geral e a lógica de funcionamento foram mantidas.
4.1 FUNCIONAMENTO DO PROGRAMA
O software criado funciona com uma simulação contínua, diferentemente de uma
simulação por eventos discretos. Esse comportamento se mostrou necessário, uma vez que
desejamos testar e validar um sistema de gerenciamento de um centro de distribuição. É
necessário que seja possível, por exemplo, cancelar a movimentação de uma unidade de carga
em curso a partir do WMS da empresa, no momento desejado durante uma simulação, e
verificar que o movimento da unidade de carga especificado cessa. Isso só é possível em uma
simulação contínua, já que em uma simulação por eventos discretos o tempo corre em
intervalos muitas vezes grandes, não sendo possível cancelar a movimentação de uma unidade
de carga no instante desejado. Outra barreira para utilizar um sistema de simulação por
eventos discretos é a latência existente na troca de mensagens entre o simulador e o WMS.
Quando é necessário enviar uma mensagem ao sistema ou verificar se existe alguma
disponível para ser lida, um determinado processo é chamado para executar funções
específicas no banco de dados. A chamada a esse processo demanda certo tempo. Apesar de
ser muito rápida (da ordem de milissegundos), a espera por esse tempo inviabiliza a
possibilidade de realizar simulações por eventos discretos.
Para a implementação de uma simulação contínua, adotou-se dentro do programa o
processamento de um loop que é executado continuamente. Dentro deste loop, ocorrem as
seguintes etapas: processamento das entradas do usuário (via mouse e teclado),
processamento das mensagens recebidas do WMS, atualização dos elementos de simulação e
renderização da representação gráfica dos elementos. O loop é executado, preferencialmente,
a sessenta quadros por segundo (60Hz). A rotina só é interrompida em duas hipóteses. A
64
primeira é quando o programa é encerrado, seja pelo seu fechamento pelo usuário ou pelo
desligamento do computador. A segunda é quando ocorre um erro crítico no programa, que
pode ser frequente nas versões iniciais do programa. O diagrama de atividades mostra, na
Figura 11, uma representação esquemática do funcionamento do programa:
Figura 11 – Diagrama de atividades da simulação
Fonte: Elaborada pelo autor com o UMLet.
4.2 INTERFACE DO USUÁRIO
Para a criação da interface do usuário, foi utilizada a função de criação de formulários
do Windows presente no Microsoft Visual Studio. Esta função permite a criação de janelas
com controles padronizados do sistema operacional, como botões, caixas de texto e menus. A
interface ficou dividida basicamente em três partes principais: o menu, pelo qual os diversos
comandos podem ser acessados; a simulação em si, na qual os elementos podem ser
visualizados e editados; e a caixa de registro de mensagens, na qual são mostradas todas as
65
mensagens trocadas entre o simulador e o WMS, bem como o horário em que cada mensagem
foi enviada ou recebida. A janela principal da aplicação pode ser vista na Figura 12.
Figura 12 – Janela principal da aplicação
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
As imagens dos botões foram obtidas na Biblioteca de Imagens do Visual Studio 23,
um pacote de imagens e ícones padrões do sistema operacional Windows oferecido
gratuitamente para desenvolvedores pela Microsoft. Dessa forma, utilizando ícones padrões
do sistema operacional, o usuário rapidamente identifica a função de cada botão, pois ele já
está familiarizado com cada uma das imagens.
4.3 EDIÇÃO DE LAYOUTS
Uma das funcionalidades implementadas no programa foi a edição de layouts de
centros de distribuição. Para facilitar essa edição, foi criado internamente um sistema de uma
grade formada por quadrados. Cada quadrado representa virtualmente uma área de 1m2.
Assim, o usuário do programa pode movimentar os elementos da simulação em um plano
horizontal e posicioná-los sobre os quadrados. Para a movimentação vertical e para a rotação
dos elementos, foram criados botões específicos para esta funcionalidade. Na Figura 13, é
23 Disponível em: <https://docs.microsoft.com/en-us/visualstudio/designers/the-visual-studio-image-library>. Acesso em Agosto de 2017.
66
possível visualizar o sistema de grade, logo abaixo dos botões utilizados para realizar as
edições.
Figura 13 – Sistema de grades para edição de layouts
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
A utilização do sistema em grade apresenta diversas vantagens. Além da facilidade no
posicionamento dos elementos, internamente o software consegue ligar uma esteira
transportadora a outra simplesmente pela posição de cada uma, não sendo necessário que o
usuário determine qual é a sequência delas. Uma desvantagem é que se perde precisão na
representação de um centro de distribuição real, já que as posições acabam sendo valores
arredondados para números inteiros. Essa perda de precisão não deve ser um problema. Por
exemplo, caso uma esteira tenha um comprimento real que não seja inteiro, haverá uma
diferença máxima de 0,5 metros com relação à sua representação virtual. Para uma esteira que
movimenta caixas normalmente a uma velocidade de 0,70 m/s, a diferença final seria de no
máximo 0,71 segundos no tempo total de uma caixa para atravessar a esteira inteira. Essa
diferença não afeta o nosso interesse na simulação, sendo uma diferença aceitável já que
estamos mais interessados em testar funcionalidades.
Por fim, para editar outras propriedades de cada elemento além da sua posição e da
sua orientação, foram criados menus para cada tipo de elemento específico como, por
exemplo, um menu para editar as esteiras transportadoras, como mostra a Figura 14.
67
Figura 14 – Menu para edição das propriedades de uma esteira transportadora
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Neste menu, é possível editar propriedades de uma esteira como o seu nome de
identificação, a sua cor, a sua velocidade, indicar se ela é uma entrada, uma saída, se possui
uma balança e se envia mensagens ao WMS quando uma nova unidade de carga entra ou sai
dela. Para cada tipo de corredor, também foi criado um menu específico de forma semelhante.
Uma vez que a representação desejada de um centro de distribuição for construída, ela
pode ser salva em um arquivo no formato XML, gerada pelo simulador. Posteriormente, esse
mesmo arquivo pode ser carregado pela aplicação. A descrição do formato de arquivo
desenvolvido está no Apêndice C deste trabalho.
4.4 REPRESENTAÇÃO 3D
Para a representação virtual dos elementos de um centro de distribuição, foram criados
determinados modelos em 3D. Como utilizamos um sistema em grade representando
quadrados de 1m2, os modelos foram construídos para serem múltiplos inteiros desse
tamanho. Todos os modelos foram criados no software Blender.
Para esteiras retas, foram criados modelos com 1 metro de largura e comprimento
variando entre 1 e 10 metros. A largura real de esteiras transportadoras varia, mas em uma
simulação a largura é simplesmente uma representação gráfica e não afeta o resultado final.
68
Como exemplo, temos na Figura 15 o modelo de uma esteira de 3 metros de comprimento. A
sua direção é indicada por uma seta.
Figura 15 – Modelo de esteira transportadora de 3 metros de comprimento
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Outros modelos de esteira são as esteiras em arco, com raios de curvatura variando
entre 2 e 3 metros. Também há esteiras em rampa, curvas em 90 graus, pontos de
convergência e pontos de bifurcações.
Para os corredores, não se viu a necessidade de criar modelos para as estantes onde os
produtos são armazenados, como por exemplo uma estrutura porta-paletes. Como estamos
interessados na movimentação das unidades de carga, a decisão foi de representar apenas os
elementos móveis de cada corredor de armazenagem. Para os transelevadores, foram criados
modelos para representar apenas os garfos. Para os corredores de multishuttle, foram criados
modelos para representar três elementos: os elevadores, os shuttles e os raques de entrada e
saída.
4.5 REPRESENTAÇÃO 2D
Além da representação 3D, atributo classificado como obrigatório, um atributo
atrativo foi a representação em 2D. Uma visão simplificada da simulação muitas vezes auxilia
na sua compreensão. Foram criadas visualizações em duas dimensões para os dois tipos de
corredores, representando uma vista lateral dos mesmos.
Para um corredor de transelevador, foi feita uma visualização lateral do corredor
mostrando em qual posição, horizontal e vertical, o transelevador se encontra (Figura 16).
69
Figura 16 – Vista lateral de um corredor de transelevador
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Para um corredor de multishuttle, foi feita uma visualização adaptada para mostrar os
elevadores, os raques de entrada e os shuttles existentes (Figura 17).
Para as esteiras, a visualização se limitou apenas à tridimensional, já que muitos
centros de distribuição possuem movimentos em diferentes alturas. Planificar as diversas
alturas levaria ao cruzamento dos caminhos, o que dificultaria a representação. Uma possível
solução seria criar uma opção em que o usuário selecionasse uma altura, e de acordo com ela
o simulador mostrasse apenas as esteiras que estiverem na cota especificada. Essa
funcionalidade não foi implementada na versão atual do programa, mas futuramente seria
uma função interessante para a simulação.
Figura 17 – Visualização bidimensional de um corredor de multishuttle
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
70
4.6 COLETA DE DADOS ESTATÍSTICOS
A coleta de dados estatísticos, outro atributo classificado como obrigatório, pode ser
feita de três formas.
A primeira forma de coleta de dados a respeito da simulação é o registro de todos os
eventos importantes que ocorreram, como por exemplo cada vez que uma unidade de carga é
movimentada de um contentor a outro. O programa registra o número da unidade de carga que
foi movimentada e o horário em que ocorreu o evento, além da sua posição anterior e da sua
posição posterior ao movimento. A qualquer momento, é possível exportar todos os eventos
registrados pelo programa para um arquivo de uma planilha Excel. Na planilha, fora do
simulador desenvolvido, pode ser facilmente calculado o tempo que uma unidade de carga
levou de uma determinada posição a outra, ou calcular quantas unidades de carga determinado
contentor movimentou durante um certo período de tempo.
A segunda forma de coleta de dados é uma lista simples de cada contentor de unidade
de carga, que contém o seu nome de identificação e a porcentagem do tempo em que passou
ociosa e em que passou movimentando cargas.
Por fim, a terceira forma de coleta de dados estatísticos não é dada pelo simulador,
mas sim pelo WMS da empresa que se deseja testar. O simulador se conecta com o WMS
para trocar mensagens, mas o WMS não diferencia o simulador de uma instalação real. Ele
simplesmente processa e registra as mensagens recebidas e envia respostas. Pelo banco de
dados do sistema, é possível realizar as próprias análises estatísticas que se desejar.
4.7 FUNÇÕES NÃO IMPLEMENTADAS
O desenvolvimento de software se mostrou uma tarefa bastante trabalhosa. O projeto
envolveu a utilização de um ambiente de desenvolvimento integrado, além de interagir com
outras ferramentas mencionadas anteriormente. Para o desenvolvimento, além de se
programar as classes definidas previamente, é preciso testar extensivamente as funções
implementadas para assegurar que elas funcionam da forma esperada.
Dadas as dificuldades que o projeto de desenvolvimento de um software envolve, três
atributos classificados como atrativos não foram implementados. O primeiro deles é a geração
de gráficos. Esta função poderá ser implementada futuramente em atualizações subsequentes
71
do programa. Priorizou-se concentrar esforços nas funcionalidades mais críticas do projeto,
discutidas nos tópicos anteriores. Caso o usuário deseje visualizar gráficos dos resultados das
simulações, é possível utilizar planilhas para fazê-los. Outra funcionalidade que também não
foi implementada pelo mesmo motivo foi a geração de relatórios customizados.
Por fim, o último atributo de qualidade atrativa não implementado foi a geração de
vídeos de simulações. Essa funcionalidade não é simples de ser implementada, e para supri-la
existem diversos softwares no mercado que oferecem a função de gravar vídeos da tela de um
computador. Estes softwares poderiam ser utilizados para gravar a tela do simulador
desenvolvido durante uma simulação caso essa necessidade se mostre aparente.
4.8 TESTES DE SIMULAÇÃO
Uma vez que todas as funcionalidades anteriores foram implementadas, foram
realizados testes do software utilizando dois sistemas da empresa que já se encontram em
operação. Assim, foi possível validar se a simulação se comporta da forma esperada,
simulando eventos que ocorrem nos centros de distribuição reais. Para a construção dos
modelos e elaboração dos testes a seguir, foram utilizados dois centros de distribuição reais de
clientes da empresa, cujos nomes serão omitidos por questões de confidencialidade.
4.8.1 Primeiro teste de simulação
A construção do primeiro layout a ser simulado foi feita utilizando o sistema de
edição criado. Apesar de o sistema de construção de layouts ser intuitivo, notou-se que o
posicionamento correto de uma grande quantidade de elementos é um processo demorado.
Para adicionar uma esteira transportadora localizada na entrada de um corredor de
armazenamento, eram necessárias um grande número de ações: pressionar o botão de
adicionar um novo elemento; selecionar que deseja adicionar uma esteira; selecionar o tipo de
esteira a ser adicionado; posicionar a esteira na posição desejada; pressionar o botão para
rotacionar a esteira 90 graus duas vezes; pressionar o botão para elevar a esteira em um metro
e por fim alterar a propriedade da esteira que indica que ela deve pedir um destino ao sistema
quando uma carga é adicionada a ela. Como a instalação a ser simulada possui oito corredores
de armazenamento, foi necessária a repetição de todos esses passos oito vezes, só para as
entradas. Um procedimento semelhante também foi feito para a configuração das saídas de
cada corredor.
72
A configuração de um layout não apresentou usabilidade satisfatória, um fator de
qualidade importante no desenvolvimento de softwares. Porém, para contornar esse problema,
encontrou-se uma solução bastante simples. Como cada elemento da simulação já possuía
duas funções, uma para gerar um elemento em XML que o representa e outra para gerar um
novo elemento de simulação a partir do XML, criou-se a funcionalidade de copiar e colar
elementos dos layouts. Quando uma esteira, por exemplo, está selecionada, é possível utilizar
um novo botão para copiar o XML que a representa para a área de transferência do
computador. Quando o botão para colar é pressionado, um novo elemento é adicionado à
simulação, contendo em comum todas as propriedades da esteira anterior. Assim, para
terminar de configurar este primeiro teste de simulação, utilizou-se essa nova funcionalidade
que não estava prevista antes de iniciar o uso do programa.
Finalmente, foi possível construir uma representação virtual do centro de distribuição
que o WMS controla. Esse CD é composto por oito corredores de transelevador. As entradas
dos corredores são feitas a partir de um anel de esteiras, localizado logo acima de outro anel
onde estão localizadas as saídas de cada corredor. A instalação também possui seis estações
de picking, além de cinco esteiras para saídas para a expedição. A visualização do layout
construído pode ser observada na Figura 18.
Figura 18 – Layout do primeiro teste de simulação
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Uma vez que o layout foi construído, foram realizados alguns testes para verificar a
comunicação entre o simulador e o WMS. Foram adicionadas diversas cargas para analisar as
respostas de envio de destino de cada uma. Para uma carga entrar no armazém, ela deve
possuir uma autorização de recebimento do produto associado a ela. Assim, foi possível
73
verificar que, quando adicionamos uma caixa de um produto que não esteja autorizado a
entrar no armazém, o destino dela foi a esteira de rejeitos. Outras cargas rejeitadas foram
aquelas cujo número de identificação já existia no armazém. O sistema as rejeitou para
garantir que cada carga tenha uma identificação única, para elas possam ser rastreadas sem
que haja problemas de conflitos. Na Figura 19, é possível visualizar que foram adicionadas
duas caixas, e que cada carga recebe um destino diferente do WMS. O simulador processa as
direções diferentes corretamente: enquanto uma retorna para a mesa de rejeitos, a outra
prossegue para dar entrada no armazém. A esteira que contém uma bifurcação decide qual
caminho cada carga deve tomar com base em duas informações: o destino atribuído à carga e
a lista de caminhos da própria esteira. Esta lista de caminhos consiste basicamente em uma
tabela com duas colunas. Na primeira coluna, ela indica qual é o caminho para o qual a caixa
deve ser direcionada. Na segunda, ela indica o destino da carga.
Figura 19 – Validação do recebimento de cargas
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Outra análise que pode ser feita a partir da simulação é a respeito do tempo que uma
carga demora para ir da entrada do sistema de esteiras até a entrada de um corredor. Na
simulação feita, uma caixa foi adicionada quando o relógio da simulação marcava 3 horas, 8
minutos e 58 segundos. O destino que ela recebeu foi o corredor de número oito, ao qual ela
chegou quando o relógio marcava 3 horas, 10 minutos e 41 segundos. Assim, podemos
calcular que o trajeto da entrada do sistema até a cabeceira de um corredor leva, quando as
esteiras estão livres, cerca de 1 minuto e 43 segundos. O registro de mensagens da simulação
permite também verificar o horário exato em que a caixa passou por pontos intermediários.
74
Após a chegada da caixa ao corredor, o simulador envia uma mensagem ao WMS
pedindo um destino para a carga, conforme esperado. O sistema não responde imediatamente
com um destino, pois ele espera por um determinado tempo para aguardar a eventual chegada
de mais caixas na entrada do mesmo corredor, a fim de enviar uma ordem de movimentação
de até três caixas simultaneamente, já que o transelevador possui três garfos. Passado este
tempo, definido como um parâmetro no sistema, finalmente chega a ordem de movimentação
da caixa, e o transelevador inicia o movimento da entrada até a posição de armazenamento
indicada. Na Figura 20, é possível ver que a caixa é movimentada com sucesso.
Figura 20 – Validação da movimentação de um transelevador
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Com a simulação deste centro de distribuição, foi possível validar a movimentação de
cargas sobre as esteiras transportadoras, verificando que elas recebem e processam destinos
corretamente. Além disso, também se validou as ordens de movimentação de um
transelevador.
4.8.2 Segundo teste de simulação
Na aplicação desenvolvida ao longo deste trabalho, foram implementados dois tipos
de corredores: os transelevadores e os multishuttles. O primeiro tipo foi testado na primeira
simulação. Agora, os corredores do tipo multishuttle serão testados com um outro WMS que
está em desenvolvimento na empresa, já em fase final.
Este centro de distribuição possui quatro corredores de armazenagem, sete linhas de
expedição e seis estações de separação de pedidos. Apesar de ser mais complexo do que o
layout anterior, a sua elaboração foi mais rápida, graças à utilização da funcionalidade de
copiar e colar elementos que compartilhem as mesmas características. Nesta simulação,
75
demonstramos a seguir os dois tipos de câmera implementados, a validação do funcionamento
de um multishuttle e o teste de desempenho do simulador, tentando simular a entrada de uma
quantidade alta de cargas simultaneamente.
Tipos de câmeras
Uma das classes implementadas no programa foi a classe “Câmera”. Recordando, esta
classe possui uma propriedade que indica qual o seu tipo de projeção, podendo ser perspectiva
ou ortográfica. Na Figura 21, podemos observar o centro de distribuição a partir de uma
câmera com projeção em perspectiva, na qual os elementos mais distantes são visualizados
em tamanho menor.
Figura 21 – Câmera em perspectiva do segundo teste de simulação
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Outra projeção que pode ser utilizada para visualizar uma simulação é a ortográfica,
na qual os elementos mantêm o seu tamanho, independentemente da distância com relação à
câmera. Este tipo de projeção pode ser utilizado em qualquer configuração de posição e
orientação. Porém, existem dois casos específicos que são mais interessantes para serem
utilizados.
O primeiro caso específico da vista ortográfica é a vista em perspectiva isométrica, na
qual o ângulo aparente formado entre cada eixo é igual a 120º, conforme podemos observar
na Figura 22.
76
Figura 22 – Exemplo de câmera ortográfica com vista isométrica
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
O segundo caso específico é a vista superior, onde é possível visualizar o centro de
distribuição por diferentes cotas, conforme podemos observar na Figura 23.
Figura 23 - Exemplo de câmera ortográfica com vista superior
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Validação de um multishuttle
De forma similar à primeira simulação, uma caixa foi enviando mensagens de pedido
de destino a cada vez que passava por um ponto de decisão no sistema de esteiras de
transporte. O sistema respondeu às mensagens, de forma a guiar a caixa até a entrada de um
multishuttle.
Uma vez que a carga chega na entrada de um corredor, o simulador envia uma
mensagem ao sistema alertando a chegada da caixa. Em seguida, o WMS envia uma ordem de
77
movimentação para que o elevador transporte a caixa até a mesa de entrada de um certo nível.
Assim, o elevador movimenta a caixa verticalmente até o destino recebido, enviando
novamente mais uma mensagem para alertar o sistema que a caixa já se encontra no destino
solicitado. O sistema envia outra ordem de transporte, dessa vez da mesa de entrada de um
nível até a posição de armazenamento da carga. Este último movimento é realizado por meio
de um shuttle, que finalmente deixa a carga na posição de armazenamento adequada. A Figura
24 mostra passo a passo os movimentos descritos realizados pelo multishuttle na simulação.
Da esquerda para a direita, de cima para baixo: a caixa chega na entrada do corredor; o
elevador eleva a carga até o nível de destino; a caixa é depositada sobre uma mesa de entrada
no nível desejado; e, por fim, o shuttle transporta a carga até a posição de armazenamento.
Figura 24 - Armazenamento de uma caixa em um multishuttle
Fonte: Elaborada pelo autor.
Teste de desempenho
Nas duas simulações apresentadas anteriormente, foram mostrados exemplos do
programa desenvolvido funcionando com apenas uma caixa. Assim, foi possível validar
algumas funcionalidades da simulação, e obteve-se um resultado bastante satisfatório. Porém,
para testar o desempenho do programa, é preciso realizar um teste mais completo. Por isso,
foi feito um teste utilizando cinquenta caixas, utilizando o layout do centro de distribuição
com multishuttles, conforme podemos ver na Figura 25.
78
Figura 25 - Simulação com grande quantidade de cargas
Fonte: Captura de tela da aplicação desenvolvida pelo autor.
Com o grande número de caixas existentes simultaneamente na simulação, não se
notou uma queda de desempenho no programa, ou seja, não houve lentidão na atualização dos
elementos e na renderização dos gráficos. As caixas formaram filas nas entradas dos
corredores, e os elevadores pouco a pouco foram transportando cada caixa ao seu respectivo
nível de destino, enquanto os shuttles transportaram as cargas até a posição de
armazenamento.
Do início da adição das caixas na entrada do sistema de esteiras até o armazenamento
da última caixa no armazém, passaram-se aproximadamente 7 minutos, de acordo com o
relógio utilizado no software que marca o tempo que se passou na simulação. Este tempo não
possui muita precisão quando comparado ao sistema real, pois nesta simulação alguns
parâmetros como velocidade e aceleração máxima dos elevadores e dos shuttles não foram
configurados de acordo com os valores reais. Porém, caso seja necessário realizar uma
simulação para tentar medir o tempo para o armazenamento de uma lista de caixas, isso
poderia ser feito obtendo os valores reais e configurando-os na simulação. Isso forneceria uma
informação muito útil, pois poderia ser usada para dimensionar o tempo que a descarga de um
caminhão, que possui uma determinada quantidade de caixas, levaria até que todas as caixas
estejam devidamente armazenadas.
Nesse teste, notou-se que o maior empecilho para a realização da simulação com alto
volume de cargas foi a latência na troca de mensagens entre o simulador e o WMS. No teste
realizado, utilizou-se o programa em um computador, enquanto o WMS estava localizado em
um servidor remoto, na nuvem. O simulador enviava uma grande quantidade de mensagens, e
não recebia respostas em um tempo rápido suficiente, por isso notou-se um certo acúmulo de
79
caixas em determinados pontos de decisão, pois ainda não haviam recebido um destino do
sistema.
Uma forma de tentar reduzir este problema seria criar uma cópia do WMS para o
mesmo computador em que está sendo realizada a simulação. Dessa forma, as mensagens não
precisariam trafegar via internet do computador que está simulando até o servidor onde está o
sistema da empresa. Porém, existe o risco de que o computador enfrente lentidão, pois estaria
processando duas aplicações pesadas simultaneamente.
Para tentar contornar tanto os problemas enfrentados para a utilização de um servidor
na nuvem quanto os problemas enfrentados com a utilização de uma cópia local do WMS,
existe uma terceira solução. Poderia ser utilizado dois computadores, um com a simulação e
um com uma cópia do WMS, porém conectados por meio de uma rede local. Assim, a
latência da troca de mensagens via internet e o risco de sobrecarregar um só computador
seriam resolvidos. O problema desta última solução é, evidentemente, a necessidade de se
utilizar dois computadores conectados na mesma rede local, o que nem sempre é um recurso
disponível.
Por fim, concluímos que a simulação apresentou um resultado satisfatório,
funcionando como esperado e permitindo testar as funcionalidades dos sistemas
desenvolvidos pelo sistema. O único imprevisto encontrado foi o trade-off entre o tempo de
latência de troca de mensagens, o sobrecarregamento de um computador e a utilização de dois
computadores simultaneamente.
4.8.3 Conclusão dos testes do software
Os testes realizados neste trabalho, apesar de utilizarem modelos simplificados,
permitiram validar certas funcionalidades de um WMS. Em um sistema real, a comunicação
entre os equipamentos de um centro de distribuição e o seu sistema de gerenciamento dá
origem a um arquivo que registra todas as mensagens enviadas e recebidas pelo sistema. Estas
mensagens seguem o formato XML, definidos pela empresa. O software desenvolvido
substitui o centro de distribuição para a realização de testes, ou seja, de forma similar, a
comunicação entre o programa e o sistema de gerenciamento também dá origem a um arquivo
com o registro de toda a informação. Dessa forma, foi possível comparar o registro de
80
mensagens de um sistema em operação em um centro de distribuição real com o registro de
mensagens trocadas com o sistema pelo simulador, de forma a validar as simulações feitas.
Foi verificado que as mensagens que foram geradas pela comunicação entre o WMS e
o simulador foram conformes à realidade. Um exemplo de um trecho do arquivo gerado pela
simulação para a entrada de uma carga em um corredor de multishuttle pode ser encontrado
no Apêndice D deste trabalho.
81
5 DISCUSSÃO
O desenvolvimento do software de simulação se mostrou como uma tarefa
extremamente desafiadora. Foi necessário entender o problema enfrentado pela empresa e
oferecer uma solução que fosse simples o suficiente para poder ser projetada, implementada e
testada por uma pessoa no intervalo de tempo de um ano, mas que fosse detalhada o suficiente
para poder realizar algumas análises importantes.
O programa de simulação obtido com o desenvolvimento deste trabalho apresentou
resultados bastante satisfatórios para a empresa. Sob o aspecto funcional, ele atendeu à
necessidade do cliente em ter uma alternativa para a realização de testes de sistemas de
gerenciamento de centros de distribuição. Sob o aspecto visual, o resultado obtido também foi
bastante interessante.
Com a versão atual do simulador, algumas ideias para o futuro podem ser levantadas.
Outras finalidades para ele são pensadas, além da realização de testes de sistema e da
obtenção de dados estatísticos a respeito do fluxo de centros de distribuição. O programa
poderia ser utilizado para ajudar a empresa na hora de apresentar projetos para conseguir
novos clientes. Para a apresentação, a empresa poderia configurar alguns módulos de um
WMS e criar o layout do cliente no simulador. Em seguida, poderia ser realizada uma
demonstração ao cliente de algumas funcionalidades do sistema. Assim, o cliente poderia ter
uma percepção mais tangível sobre o produto que deseja adquirir, ajudando a empresa a
possivelmente aumentar a sua taxa de projetos que são efetivamente vendidos com relação ao
número de projetos que são apresentados.
Outra ideia de aplicação para o software desenvolvido seria vendê-lo a um cliente
juntamente com o WMS adquirido. Assim, parte do treinamento que é dado aos funcionários
para aprenderem a utilizar o sistema poderia ser feito com o WMS conectado a uma
simulação, tornando o processo de aprendizado mais prático e mais rápido. Os usuários do
sistema utilizariam a interface do sistema da empresa para, por exemplo, enviar ordens de
movimentação de cargas. Estes comandos seriam executados no simulador, sem a necessidade
de movimentar cargas reais somente para fins de aprendizado.
Por fim, a última ideia seria utilizar o simulador como um visualizador das cargas
reais que estão em movimentação em determinado centro de distribuição. Porém, para que
82
isso se torne possível, seria necessário realizar algumas alterações no programa. Ele não
poderia mais enviar mensagens ao WMS, pois as mensagens a serem processadas pelo
sistema seriam enviados do centro de distribuição real a partir da leitura de escâneres,
sensores e balanças. O simulador então se limitaria a ler as mensagens trocadas entre o
sistema e os equipamentos do centro de distribuição, para que possa obter informações a
respeito das posições de cada carga em movimento. Dessa forma, o simulador forneceria a
possibilidade de acompanhar operações de carga, descarga e separação de pedidos de forma
remota.
83
6 CONCLUSÕES
Este trabalho foi desenvolvido a partir de um problema real enfrentado por uma
empresa que desenvolve sistemas de gerenciamento de centros de distribuição automatizados.
A empresa relata a dificuldade de realizar testes de seus sistemas durante e após o
desenvolvimento dos mesmos.
Conforme foi discutido, a realização de testes de WMS apresenta diversos desafios.
Dentre eles, pudemos citar o longo tempo demandado para a execução dessa tarefa. O tempo
é um recurso muito escasso, principalmente no caso de o centro de distribuição já se encontrar
em operação. Outras dificuldades envolvidas seriam a localização afastada dos CDs dos
grandes centros urbanos, onde vivem os funcionários da empresa, bem como a necessidade de
se separar cargas para utilização nos testes, o que nem sempre é uma tarefa fácil já que
existem produtos de manipulação mais delicada, como produtos muito pesados, muito frágeis
ou resfriados e congelados. Sendo assim, a empresa viu a necessidade de se encontrar uma
alternativa, propondo o desenvolvimento de um software que simulasse um centro de
distribuição e o substituísse no momento de se testar as funcionalidades de um sistema.
Assim, a empresa espera poder testar um sistema que controla uma instalação sem a
necessidade de estar no local. Neste trabalho, este software foi desenvolvido a partir dessa
necessidade, utilizando as ferramentas mais adequadas escolhidas com base na revisão da
literatura.
Para o levantamento das possíveis funcionalidades que poderiam ser implementadas
no simulador desenvolvido, a realização de um benchmarking se mostrou como uma
ferramenta bastante útil. Foi possível comparar o que se pretendia desenvolver com outras
soluções semelhantes que já existem disponíveis no mercado, de forma a elaborar uma lista
com todas as possíveis funcionalidades que o simulador poderia ter. Porém, não seria viável
implementar todas elas, pois trata-se de um projeto com recursos escassos, desenvolvido por
apenas uma pessoa em um intervalo de tempo de um ano. Assim, foi necessário encontrar
uma forma de atribuir prioridades a cada atributo do programa.
A priorização das funcionalidades listadas para o software de simulação desenvolvido
foi solucionada de forma satisfatória por meio da utilização do modelo da satisfação do
cliente de Kano. A utilização deste modelo se mostrou como uma ferramenta bastante
interessante. Com a elaboração de um questionário simples, com respostas de múltipla
84
escolha, foi possível classificar cada atributo em diferentes categorias para as suas respectivas
priorizações. O resultado obtido com a classificação foi condizente com o esperado, ou seja,
foram objetivas e não apresentaram informações distorcidas quando comparadas à realidade.
Assim, obteve-se um planejamento de desenvolvimento de um software com as suas devidas
funcionalidades.
Para a elaboração do simulador, foi escolhido um ambiente de desenvolvimento
integrado dentre diversas alternativas conhecidas no mercado. Para isso, foi utilizado o
processo analítico hierárquico. O AHP se mostrou como uma ferramenta interessante para o
apoio à tomada de decisão, e pode ser utilizada para diversos projetos onde for preciso
escolher uma dentre diversas opções.
Para a efetiva implementação do simulador, foram projetadas classes para serem
criadas com a ajuda da programação orientada a objetos. As classes funcionam como
componentes interdependentes do programa, e a especificação das mesmas é importante no
desenvolvimento de software para que não seja necessário mudar a estrutura delas
posteriormente. Uma mudança mais profunda em uma classe em fases finais do
desenvolvimento de software pode acarretar em uma grande carga de retrabalho, já que o
custo de mudança aumenta gradativamente com o tempo com a consequente maturidade do
projeto.
Após o término do desenvolvimento do software, todas aquelas funcionalidades
classificadas como obrigatórias ou como unidimensionais pelo questionário do modelo de
Kano foram implementadas. Já aquelas classificadas como atrativas não foram desenvolvidas,
com a justificativa de que o esforço de adicioná-las ao software não compensava o ganho
obtido. Os atributos atrativos foram a geração de gráficos, a geração de relatórios
customizados e a gravação de vídeos de simulação. Os dois primeiros podem ser facilmente
substituídos pela utilização de planilhas eletrônicas, aplicações que já fazem parte do dia-a-
dia do trabalho da empresa e com as quais os funcionários já possuem familiaridade, enquanto
o último pode ser alcançado por meio da utilização de softwares que gravam a tela do
computador. Por fim, aquelas funcionalidades classificadas como indiferentes ou reversas não
foram implementadas, já que é este o objetivo principal do modelo de Kano, evitar com que
esforços sejam empreendidos em qualidades que não agregam ao produto final.
85
6.1 LIMITAÇÕES
Apesar da simulação fornecer uma forma de se testar sistemas de gerenciamento de
centros de distribuição, a solução desenvolvida não é um substituto perfeito para os testes
realizados em instalações reais, já que se trata de uma simplificação das operações que um
sistema precisa gerenciar. Mesmo assim, a simulação se mostra como uma ferramenta muito
útil que auxilia os desenvolvedores a realizar testes rápidos durante a produção de sistemas,
ajudando a diminuir a carga de trabalho e a taxa de falhas quando chega a hora de realizar
testes nas instalações reais.
A primeira limitação que surgiu foi na representação de um centro de distribuição em
uma simulação. Para isso, utilizou-se um sistema em grade para o posicionamento dos
elementos de simulação. Nesse sistema, a posição de cada elemento acaba sendo um número
inteiro, impossibilitando a representação precisa do posicionamento e do tamanho dos
equipamentos de um centro de distribuição. A discrepância entre a posição e o tamanho real
de um elemento e a posição e o tamanho de sua representação no modelo não afeta o teste de
funcionalidades do sistema, intuito principal da simulação. Porém, caso seja necessário
simular o tempo em que cada evento ocorre a fim de se obter resultados estatísticos em uma
simulação, essa discrepância afetará o tempo de ocorrência dos eventos, devendo este
resultado ser analisado com cautela.
A segunda limitação apareceu na hora de testar o software desenvolvido no teste de
desempenho do programa. Quando a simulação precisou enviar e receber uma quantidade
muito grande de mensagens em um intervalo muito curto de tempo, foi detectado um atraso
na comunicação entre a simulação e o sistema. Este atraso ocorreu devido ao fato de o sistema
utilizado para testes estar armazenado em um servidor remoto, fazendo com que as
mensagens tenham que trafegar via internet. Dessa forma, formou-se na simulação uma fila
de mensagens. Para contornar essa limitação, foram propostas duas soluções. A primeira
solução seria utilizar uma cópia do WMS no mesmo computador em que a simulação seria
executada, evitando assim que as mensagens demorem a trafegar. Porém, existe o risco de um
só computador enfrentar lentidões devido ao processamento simultâneo de duas aplicações. A
segunda solução seria utilizar dois computadores conectados por uma rede local, uma com o
simulador e outro com o WMS. A desvantagem desta última solução seria a necessidade de se
utilizar dois computadores para executar uma simulação.
86
6.2 APRENDIZADO
Com o desenvolvimento deste trabalho, foi possível aprender muito sobre o sistema da
empresa, pois foi necessária uma interação contínua com o mesmo. Foi preciso entender
como o sistema funciona, além de trabalhar com o protocolo das mensagens que o WMS
utiliza para fazer a comunicação. Para cada mensagem, foi importante saber como processá-la
e programar os devidos efeitos provocados na simulação.
Outro aprendizado está relacionado à competência chave da empresa, que é o
conhecimento logístico de operações que ocorrem em centros de distribuição. É esse
conhecimento que permite à empresa desenvolver sistemas que atendam às diferentes
necessidades de seus clientes. Neste trabalho, foi preciso entender tanto a respeito de
operações que ocorrem em um centro de distribuição para que fosse possível simulá-las, como
entender como ocorre o desenvolvimento de sistemas, pois é este o processo que se deseja
agilizar na empresa com o uso do simulador.
A utilização de certas ferramentas foi outro aprendizado importante para trabalhos
futuros que possam aparecer. Por exemplo, a linguagem UML pode ser utilizada para
documentar algoritmos utilizados em sistemas, sendo uma peça importante quando a criação
da documentação de WMSs for feita.
6.3 PRÓXIMOS PASSOS
Para futuros trabalhos envolvendo o simulador desenvolvido, propõe-se a melhoria
incremental do software. Assim, à medida que novas necessidades forem aparecendo, elas
poderão ser supridas gradualmente a partir da implementação de novas funcionalidades.
Durante a realização de testes de simulação em conjunto com os funcionários da
empresa, foram discutidas diversas funcionalidades interessantes que poderiam ser
implementadas futuramente. Atualmente, a simulação trabalha com um modelo
determinístico, ou seja, se um teste for executado utilizando os mesmos parâmetros, o
resultado sempre será o mesmo. Essa característica é desejada pois, quando estamos testando
uma funcionalidade específica de um WMS, queremos que o evento que desejamos testar
ocorra, e que não exista a possibilidade de outro evento ocorrer em seu lugar. Porém, para
futuros testes dotados de maior complexidade, seria interessante poder atribuir a cada evento
uma probabilidade de ocorrência. Assim, quando houver a necessidade de se testar um evento
87
específico, a sua probabilidade poderia ser configurada para ser igual a 1, mas quando se
deseje testar como o sistema se comporta quando ocorrem múltiplos eventos de natureza
diferente, as respectivas probabilidades poderiam ser configuradas conforme desejado.
Outra funcionalidade que foi discutida é a exportação de um arquivo de todas as
cargas em uma simulação em um determinado instante. Atualmente, o software exporta
apenas o layout de um centro de distribuição, devendo as cargas serem adicionadas no início
de cada simulação. A ideia dessa nova funcionalidade seria que o programa pudesse exportar
uma lista das cargas com as suas respectivas posições. Assim, este arquivo poderia ser
compartilhado para posteriormente ser importado em simulações feitas por outras pessoas. O
estado inicial da simulação seria o mesmo de quando o arquivo foi gerado, assim agilizando
ainda mais os testes das funcionalidades do WMS.
Por fim, conforme o software desenvolvido for sendo utilizado pelos funcionários da
empresa, com certeza novas ideias e novas necessidades surgirão. Essas ideias e necessidades
darão origem a novas funcionalidades do programa, que deverão também ser priorizadas
utilizando as ferramentas adequadas.
88
89
REFERÊNCIAS
ANYLOGIC. Features – AnyLogic Simulation Software. Disponível em: <https://www.anylogic.com/features/>. Acesso em Junho de 2017. BALLOU, R. H. Logística Empresarial. São Paulo: Atlas, 1993. BLENDER. Blender Software Website. Disponível em: <https://www.blender.org/about/>. Acesso em Setembro de 2017. CIRRUS logistics. CLASS Warehouse Simulation. Disponível em: <http://cirruslogistics.com/products/class/warehouse-simulation/>. Acesso em Junho de 2017. CREATEASOFT. SimCAD Process Simulator. Disponível em: <http://www.createasoft.com/Simulation-Software>. Acesso em Junho de 2017. DEMATIC. Solutions by Technology. Disponível em: <http://www.dematic.com/en-us/supply-chain-solutions/by-technology/>. Acesso em maio de 2017. DEMATIC. Storage and buffering Systems. Disponível em: <http://www.dematic.com/en-us/supply-chain-solutions/by-technology/storage-systems/>. Acesso em maio de 2017. ECLIPSE. About the Eclipse Foundation. Disponível em: <https://www.eclipse.org/org/>. Acesso em Junho de 2017. FIGUEIREDO, E. Relacionamento do Diagrama de Classes. UFMG, 2016. Disponível em <http://homepages.dcc.ufmg.br/~figueiredo/>. Acesso em Setembro de 2017. FLEURY, P.F.; WANKE, P.; FIGUEIREDO, K. Logística Empresarial: A Perspectiva Brasileira. São Paulo: Atlas, 2000. FLEXSIM. FlexSim Simulation Software. Disponível em: <https://www.flexsim.com/flexsim/>. Acesso em Junho de 2017. FOWLER, M. UML Distilled: A Brief Guide to the Standard Object Modeling Language. Addison-Wesley, 1997. GITHUB. Advanced Search. Disponível em: <https://github.com/search/advanced>. Acesso em setembro de 2017. GOUSIOS, G.; VASILESCU, B.; SEREBRENIK, A.; ZAIDMAN, A. Lean GHTorrent: GitHub Data on Demand. Association for Computing Machinery, 2014. JETBRAINS. JetBrains Toolbox Subscription. Disponível em: <https://www.jetbrains.com/idea/buy/#edition=commercial>. Acesso em Junho de 2017. KANO, N.; SERAKU, N.; TAKAHASHI, F.; TSUJI, S. Attractive Quality and Must-Be Quality. Journal of Japanese Society for Quality Control, 1984.
90
KAY, M. Material Handling Equipment. Dept. of Industrial and Systems Engineering, North Carolina State University, 2012. MCCALL, J.; RICHARDS, P.; WALTERS, G. Factors in Software Quality. Rome Air Development Center, 1977. ME-JAN. Stacker Crane. Disponível em: <www.me-jan.com/en/stacker-crane>. Acesso em maio de 2017. MICROSOFT. Classic DirectX Graphics. Disponível em: <https://msdn.microsoft.com/en-us/library/windows/desktop/hh309465(v=vs.85).aspx>. Acesso em Setembro de 2017. MICROSOFT. Visual Studio Pricing. Disponível em: <https://www.visualstudio.com/pt-br/vs/pricing/>. Acesso em Junho de 2017. MICROSOFT. The Visual Studio Image Library. Disponível em: <https://docs.microsoft.com/en-us/visualstudio/designers/the-visual-studio-image-library>. Acesso em Agosto de 2017. MONODEVELOP. Cross platform IDE for C#, F# and more. Disponível em: <http://www.monodevelop.com/>. Acesso em Junho de 2017. NETBEANS. NetBeans IDE – The Smarter and Faster Way to Code. Disponível em: <https://netbeans.org/features/index.html>. Acesso em Junho de 2017. NOVAES, A. G. N. Logística e gerenciamento da cadeira de distribuição. São Paulo: Elsevier, 2015. PURAINFO. UML – Diagrama de Atividades. Disponível em: <http://www.purainfo.com.br/artigos/uml-diagrama-de-atividades/>. Acesso em novembro de 2017. RICARTE, I. Programação Orientada a Objetos: Uma Abordagem com Java. Faculdade de Engenharia Elétrica e de Computação, Universidade Estadual de Campinas, 2001. RUMBAUGH, J.; JACOBSON, I.; BOOCH, G. The Unified Modeling Language Reference Manual. Addison-Wesley, 2004. SAATY, R. The analytic hierarchy process – what it is and how it is used. Mathematical Modelling, v. 9, Pittsburgh , 1987. p. 161-176. STACKOVERFLOW. Developer Survey Results 2017. Disponível em <https://insights.stackoverflow.com/survey/2017>. Acesso em Junho de 2017. UMLET. Free UML Tool for Fast UML Diagrams. Disponível em: <http://www.umlet.com/>. Acesso em Setembro de 2017. VENKI. 3 exemplos de modelo de Kano e como usar em projetos. Disponível em: <http://www.venki.com.br/blog/modelo-de-kano/>. Acesso em novembro de 2017.
91
W3C. Extensible Markup Language (XML) 1.0. Ed. 5. Disponível em: <https://www.w3.org/TR/xml/>. WEBDANFE. Exemplo de XML de Nota Fiscal Eletrônica. Disponível em: <https://www.webdanfe.com.br/danfe/ExemploXml.aspx>. Acesso em novembro de 2017.
92
93
APÊNDICE A – QUESTIONÁRIO DO MODELO DE KANO
O questionário do modelo de Kano foi composto por 24 perguntas, enumeradas a
seguir:
1. Como você se sentiria se você pudesse editar layouts dentro do simulador?
2. Como você se sentiria se você não pudesse editar layouts dentro do simulador?
3. Como você se sentiria se o simulador pudesse importar layouts de outros softwares?
(Exemplo: CAD)
4. Como você se sentiria se o simulador não pudesse importar layouts de outros
softwares?
5. Como você se sentiria se o simulador representasse os elementos das simulações em
2D?
6. Como você se sentiria se o simulador não representasse os elementos das simulações
em 2D?
7. Como você se sentiria se o simulador representasse os elementos de simulação em
3D?
8. Como você se sentiria se o simulador não representasse os elementos de simulação em
3D?
9. Como você se sentiria se o simulador pudesse importar arquivos externos como
imagens ou modelos em 3D para customização dos elementos de simulação?
10. Como você se sentiria se o simulador não pudesse importar arquivos externos para
customização dos elementos de simulação, e apenas utilizasse imagens e modelos
padrões?
11. Como você se sentiria se o simulador coletasse dados estatísticos da simulação?
12. Como você se sentiria se o simulador não coletasse dados estatísticos da simulação?
13. Como você se sentiria se o simulador pudesse gerar gráficos automaticamente com os
dados da simulação?
14. Como você se sentiria se o simulador não pudesse gerar gráficos com os dados da
simulação?
15. Como você se sentiria se o simulador pudesse gerar relatórios com um resumo da
simulação?
16. Como você se sentiria se o simulador não pudesse gerar relatórios com um resumo da
simulação?
94
17. Como você se sentiria se o simulador pudesse exportar dados para planilhas Excel?
18. Como você se sentiria se o simulador não pudesse exportar dados para planilhas
Excel?
19. Como você se sentiria se o simulador pudesse exportar dados para banco de dados?
20. Como você se sentiria se o simulador não pudesse exportar dados para banco de
dados?
21. Como você se sentiria se o simulador pudesse gravar vídeos das simulações?
22. Como você se sentiria se o simulador não pudesse gravar vídeos das simulações?
23. Como você se sentiria se o simulador funcionasse em múltiplos sistemas
operacionais?
24. Como você se sentiria se o simulador funcionasse apenas em um sistema operacional?
Para cada uma das 24 perguntas, foram apresentadas as cinco alternativas de resposta
a seguir:
a) Sinto-me satisfeito
b) Sinto que é obrigatório ser dessa forma
c) Sinto-me insatisfeito
d) É aceitável ser assim
e) Sinto-me neutro
95
APÊNDICE B – MATRIZES DO AHP
Tabela 19 - Matriz de julgamento para os critérios de seleção
Custo Base de Código Suporte Familiaridade Funcionalidades
Custo 1 5 5 3 1
Base de Código 1/5 1 1 1/3 1/3
Suporte 1/5 1 1 1/3 1/3
Familiaridade 1/3 3 3 1 1
Funcionalidades 1 3 3 1 1
Taxa de consistência: 0,06 Fonte: Elaborada pelo autor.
Tabela 20 – Pesos atribuídos a cada critério de seleção
Critério de Seleção Peso atribuído
Custo 0,36
Base de Código 0,10
Suporte 0,10
Familiaridade 0,20
Funcionalidades 0,24
Fonte: Elaborada pelo autor.
Tabela 21 - Matriz de julgamento para o custo
Visual Studio Eclipse IntelliJ Idea NetBeans MonoDevelop
Visual Studio 1 1/3 1 1/3 1/3
Eclipse 3 1 3 1 1
IntelliJ Idea 1 1/3 1 1/3 1/3
NetBeans 3 1 3 1 1
MonoDevelop 3 1 3 1 1
Taxa de consistência: 0,00 Fonte: Elaborada pelo autor.
96
Tabela 22 - Matriz de julgamento para a base de código
Visual Studio Eclipse IntelliJ Idea NetBeans MonoDevelop
Visual Studio 1 1/3 1/3 1/3 1
Eclipse 3 1 1 1 3
IntelliJ Idea 3 1 1 1 3
NetBeans 3 1 1 1 3
MonoDevelop 1 1/3 1/3 1/3 1
Taxa de consistência: 0,00 Fonte: Elaborada pelo autor.
Tabela 23 - Matriz de julgamento para o suporte
Visual Studio Eclipse IntelliJ Idea NetBeans MonoDevelop
Visual Studio 1 1 5 5 7
Eclipse 1 1 5 5 7
IntelliJ Idea 1/5 1/5 1 1 3
NetBeans 1/5 1/5 1 1 3
MonoDevelop 1/7 1/7 1/3 1/3 1
Taxa de consistência: 0,02 Fonte: Elaborada pelo autor.
Tabela 24 - Matriz de julgamento para a familiaridade
Visual Studio Eclipse IntelliJ Idea NetBeans MonoDevelop
Visual Studio 1 5 5 5 1
Eclipse 1/5 1 1 1 1/3
IntelliJ Idea 1/5 1 1 1 1/3
NetBeans 1/5 1 1 1 1/3
MonoDevelop 1 3 3 3 1
Taxa de consistência: 0,01 Fonte: Elaborada pelo autor.
97
Tabela 25 - Matriz de julgamento para as funcionalidades
Visual Studio Eclipse IntelliJ Idea NetBeans MonoDevelop
Visual Studio 1 3 1 3 3
Eclipse 1/3 1 1/3 1 1
IntelliJ Idea 1 3 1 3 3
NetBeans 1/3 1 1/3 1 1
MonoDevelop 1/3 1 1/3 1 1
Taxa de consistência: 0,00 Fonte: Elaborada pelo autor.
Tabela 26 - Sumário das notas de cada alternativa em cada critério
Custo BasedeCódigo Suporte Familiaridade Funcionalidades
VisualStudio 0,09 0,09 0,39 0,42 0,33
Eclipse 0,27 0,27 0,39 0,09 0,11
IntelliJIdea 0,09 0,27 0,09 0,09 0,33
NetBeans 0,27 0,27 0,09 0,09 0,11
MonoDevelop 0,27 0,09 0,04 0,31 0,11
Fonte: Elaborada pelo autor.
Tabela 27 - Nota final de cada alternativa
IDE Nota final
Microsoft Visual Studio 0,24
Eclipse 0,21
IntelliJ IDEA 0,17
NetBeans 0,18
MonoDevelop 0,20
Fonte: Elaborada pelo autor.
98
99
APÊNDICE C – ARQUIVO XML DE UM LAYOUT
Estrutura do documento XML para o armazenamento do layout de um centro de
distribuição em um arquivo.
Cada simulação possui uma lista de câmeras e um layout, que por sua vez possui uma
lista de esteiras e uma lista de corredores:
<?xml version="1.0" encoding="ISO-8859-1" ?> <simulation> <cameras> </cameras> <layout> <conveyors>
</conveyors> <aisles>
</aisles> </layout> </simulation>
Estrutura do elemento XML de uma lista de câmeras. Cada câmera possui uma
identificação, uma posição, uma rotação e um tipo de projeção:
<cameras> <camera id="C1" position="-34.8, 45.4, 17.7" rotation="-37, 270, 0" type="perspective" /> <camera id="C2" position="20.0, 50.0, 20.0" rotation="-90, 0, 0" type="orthographic" /> </cameras>
Estrutura do elemento XML de uma lista de esteiras. Cada esteira possui uma
identificação, um tipo, atributos relacionados ao seu tipo como tamanho ou direção, uma
posição, uma rotação e outros atributos opcionais que indicam as mensagens que a esteira
deve trocar com o sistema:
<conveyors> <conveyor id="IP01" type="straight" size="5" position="8, 0.6, 3" requests-destination="true"/> <conveyor id="MT00" type="divergence" position="13, 0.6, 3" /> <conveyor id="MT01" type="straight" size="1" position="13, 0.6, 4" rotation="0, -90, 0" /> <conveyor id="MT02" type="curve" direction="left" position="13, 0.6, 5" rotation="0, -90, 0" /> <conveyor id="MR01" type="straight" size="5" position="12, 0.6, 5" rotation="0, 180, 0" /> </conveyors>
100
Estrutura do elemento XML de uma lista de corredores. Cada corredor possui uma
identificação, um tipo, uma posição e um número. O corredor do tipo transelevador possui
uma lista de garfos. O corredor do tipo multishuttle possui uma lista de elevadores, de shuttles
e de raques.
<aisles> <aisle id="SRM01" type="stacker-aisle" position="42, 0, 31" number="1" > <stacker> <forks> <fork id="1" /> <fork id="2" position="1, 0, 0" /> <fork id="3" position="2, 0, 0" /> </forks> </stacker> </aisle> <aisle id="MS04" type="multishuttle-aisle" position="31, 0, 17" number="2" > <lifts speed="2"> <lift id="MSAI04EL01LO00" position="0, 3, -1" side="left" /> <lift id="MSAI04ER01LO00" position="0, 3, 1" side="right" /> </lifts> <shuttles speed="2"> <shuttle id="MSAI04LV01SH01" position="0, 3, 0" level="1" /> <shuttle id="MSAI04LV02SH01" position="0, 3.5, 0" level="2" /> <shuttle id="MSAI04LV03SH01" position="0, 4, 0" level="3" /> <shuttle id="MSAI04LV04SH01" position="0, 4.5, 0" level="4" /> </shuttles> <rack-entrances> <rack-entrance id="MSAI04LR01RI10" position="-1, 3, 1" level="1" side="left" type="1" /> <rack-entrance id="MSAI04LR01RO10" position="1, 3, 1" level="1" side="left" type="2" /> <rack-entrance id="MSAI04LL02RI10" position="-1, 4, -1 level="2" side="right" type="1" /> <rack-entrance id="MSAI04LL02RO10" position="1, 4, -1" level="2" side="right" type="2" /> <rack-entrance id="MSAI04LR03RI10" position="-1, 3, 1" level="3" side="left" type="1" /> <rack-entrance id="MSAI04LR03RO10" position="1, 3, 1" level="3" side="left" type="2" /> <rack-entrance id="MSAI04LL04RI10" position="-1, 4, -1" level="4" side="right" type="1" /> <rack-entrance id="MSAI04LL04RO10" position="1, 4, -1" level="4" side="right" type="2" /> </rack-entrances> </aisle> </aisles>
101
APÊNDICE D – COMUNICAÇÃO ENTRE O WMS E O SIMULADOR
Exemplo de registro de mensagens trocadas entre o simulador e o WMS para a
entrada de uma carga em um corredor de multishuttle.
1) Simulador pede destino ao WMS para a carga número 99902150:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type ="destination_request"> <body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>MSAI01CR01PS10</actual>
<destination> </destination> <status_code>OK</status_code> </body> </message> 2) WMS responde ao simulador com o destino da carga, a entrada do armazenamento
em um certo nível:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type="send_destination"> <body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>MSAI01CR01PS10</actual> <destination>MSAI01LR01RI10</destination> </body> </message>
3) O simulador notifica o WMS que a carga se encontra no elevador:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type ="notify_position"> <body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>MSAI01ER01LO00</actual> <destination>MSAI01LR01RI10</destination> <status_code>OK</status_code> </body> </message>
102
4) O simulador pede ao WMS um destino para a carga, que se encontra na entrada de
um certo nível:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type ="destination_request"> <body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>MSAI01LR01RI10</actual> <destination>MSAI01LR01RI10</destination> <status_code>OK</status_code> </body> </message>
5) O WMS responde ao simulador com uma posição de armazenamento para a carga:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type="send_destination"> <body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>MSAI01LR01RI10</actual> <destination>AB.1.1.38.1.2</destination> </body> </message>
6) O simulador notifica o WMS que a carga se encontra em um shuttle:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type ="notify_position">
<body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>MSAI01LV01SH01</actual> <destination>AB.1.1.38.1.2</destination> <status_code>OK</status_code>
</body> </message>
103
7) Finalmente, o simulador notifica o WMS que a carga se encontra na posição de
armazenamento desejada:
<?xml version="1.0" encoding="ISO-8859-1" ?> <message type ="notify_position"> <body> <device_id>MS01</device_id> <tracking_id>99902150</tracking_id> <ua_id>99902150</ua_id> <actual>AB.1.1.38.1.2</actual> <destination>AB.1.1.38.1.2</destination> <status_code>OK</status_code> </body> </message>
