Descrição da heurística

Ao se discretizar os pontos de um corredor como descrito na seção 3.3.4, tem-se que um aumento no número de pontos de coleta, não necessariamente implica em um aumento dos pontos a serem considerados no roteamento, estes agora ficam dependentes do número total de corredores com algum item a ser coletado.

Embora o número de pontos possa ficar reduzido, surge um problema de factibilidade: simplesmente resolver o TSP não garante que todos os pontos de coleta sejam visitados. A FIGURA 33 representa uma rota viável do TSP para os pontos discretizados da FIGURA 29, porém inviável para o SPRP, na medida em que o arco (1-(1,2)) deve, obrigatoriamente ser visitado, para que os itens entre os pontos 1 e 2 sejam coletados.

FIGURA 33 – ROTA INVIÁVEL SPRP

FONTE: O autor (2018).

Desta forma, uma verificação deve ser realizada em cada corredor, a fim de armazenar quais arcos do conjunto total ܣ devem ser visitados, para que não haja infactibilidades. Os arcos que possuem tal característica são rotulado de “obrigatórios”

ܣ^כ. Se um determinado conjunto de pontos ܲ possui um conjunto ܣ^כ, e uma determinada rota R não contém todos os arcos de ܣ^כ, os arcos de ܣ^כ que não estão contidos em R são chamados de “violações”.

A heurística proposta tem por objetivo a identificação e posterior correção de violações em um conjunto de rotas. Estas rotas são obtidas a partir da resolução em árvore do TSP, armazenando todas aquelas que são viáveis.

O pseudocódigo da TABELA 4 explicita a rotina principal para implementação computacional da heurística, nele estão algumas estruturas de dados necessárias à compreensão do todo, são elas:

l_bounds: Lista de classes do tipo rota, cada classe do tipo rota, por sua vez, é composta por uma lista de números inteiros, representando uma rota válida do TSP e um número inteiro bound com o custo da rota.

arco: estrutura com duas variáveis inteiras.

hash_restricao: Mapa ordenado, em que a chave é o número do corredor e o valor uma classe info_rest.

info_rest: Classe com 2 listas; l_bool_rest e l_bool_violacao, cada uma com dois valores booleanos, o primeiro valor das listas l_bool_rest é preenchido como verdadeiro se, para aquele corredor, existem pontos de coleta entre os pontos 1 e 2, e o segundo valor também é verdadeiro se, entre os pontos 3 e 4 também existirem itens a serem coletados (essas informações servem para garantir a obrigatoriedade de passagem em alguns arcos).

Já os primeiros valores de l_bool_violacao recebem TRUE quando os mesmos valores de l_bool_rest forem verdadeiros e o referido arco não está contida na rota, o mesmo vale para o segundo valor, agora referentes aos pontos 3 e 4, Um exemplo da hash_restricao para a FIGURA 33 é apresentado na TABELA 3

O conjunto info_rest verifica a factibilidade da rota para o SPRP.

TABELA 3 – RESTRIÇÕES VIOLAÇÕES

CHAVE l_bool_restricao l_bool_violacao

1 TRUE TRUE

FALSE FALSE

FONTE: O autor (2018).

TABELA 4 – PSEUDOCÓDIGO DA HEURÍSTICA DE CORREÇÃO DE ROTAS

RESOLVE_SPRP()

1 solve_tsp(l_bounds)

10 Fact_rota <- verifica_factibilidade_preenche_hash_restricao(rota_atual) 11 se (fact_rota == TRUE )

12 Return

13 Fim se

14 Se (l_bounds.bound < melhor_bound) 15 Corrige_rota(rota_atual)

16 Custo_atual<-calcula custo(rota_atual)

17 se (custo atual<melhor_bound) then

18 melhor_bound <- custo_atual

19 Limpa(melhor_rota)

20 Melhor_rota<-rota_atual

21 Fim se

22 Fim se 23 Fim se

FONTE: O autor (2018).

A primeira linha do código expande a árvore de busca para resolução do TSP, armazenando todas as informações dos nós que possuem uma rota viável para o TSP na lista l_bounds. A linha 2 calcula as listas l_bool_rest para o conjunto de pontos. A linha 3 inicializa uma variável inteira com um valor muito alto (neste caso, o máximo admissível para o tipo inteiro na máquina). A linha 4 recebe o número total de rotas viáveis coletados e armazenados em l_bounds. Na linha 5 é realizado o ordenamento da lista l_bounds crescentemente, em função de seus atributos bounds. O método de ordenação aqui empregado foi o Heap Sort.

O laço de iteração da linha 6 percorre todos os elementos da lista l_bounds. As linhas 7 e 8 reinicializam as variáveis rota_atual e hash_retricao e na linha 9 é feita a atribuição à variável rota_atual a rota com índice i da lista l_bounds. A linha 10 atribui à variável Fact_rota o valor TRUE se a rota atual já é viável para o SPRP. Para que essa verificação seja realizada, todos os elementos das listas l_bool_violacao devem ser TRUE, ou seja, nenhum corredor pode ter violação em seus arcos.

A verificação de violação por corredor, não necessariamente exige que um determinado arco obrigatório (1-(1,2) por exemplo), esteja contido rota, qualquer arco com ponto inicial em outro corredor, que se ligue ao ponto 2 do corredor 1, por meio do CTI já satisfaz o critério de factibilidade.

A mesma lógica pode ser combinada a todos os pontos do corredor para atribuição de FALSE às listas l_bool_violacao. Na FIGURA 34 tem-se os arcos obrigatórios para o corredor 1 e na sequência (b,c e d) todas as possibilidades de verificação para o segundo ponto do corredor 1 assumindo que o ponto ligado à ele está também no 1º corredor.

FIGURA 34 – TIPOS DE VIOLAÇÕES

FONTE: O autor (2018).

Os valores da lista l_bool_violacao para o corredor 1, em FIGURA 34 (a), FIGURA 34 (b), FIGURA 34 (c) e FIGURA 34 (d), ficam (assumindo que todos são inicializados com TRUE) como na TABELA 5:

TABELA 5 – LISTAS DE RESTRIÇÃO

L_bool_violacao

FIGURA 34(b) FALSE TRUE

FIGURA 34(c) FALSE FALSE

FIGURA 34(d) TRUE FALSE

FONTE: O autor (2018).

Já na FIGURA 35, os pontos ligados ao ponto 2 do corredor 1 são de outro corredor:

FIGURA 35 – RELIGAÇÕES DE ROTA

FONTE: O autor (2018).

E os valores da lista l_bool_violacao ficam como mostrado na TABELA 6:

TABELA 6 – LISTA DE VIOLAÇÕES

L_bool_violacao

DEP_7 (a) TRUE FALSE

DEP_7 (b) FALSE TRUE

FONTE: O autor (2018).

Realizando o procedimento de verificação descrito acima, para todos os pontos, em todos os corredores, verifica-se se a rota analisada é viável ou não para o SPRP.

As linhas 11, 12 e 13 do pseudocódigo tem por objetivo abortar a busca caso alguma das rotas da lista l_bound seja viável para o SPRP, como inicialmente os valores da lista foram ordenados, as próximas rotas que seriam avaliadas seriam piores ou tão boas quanto a solução viável atual. Na linha 14, é realizada uma verificação do custo associado à rota do TSP, caso o mesmo seja maior do que o melhor custo atual, a rota não é corrigida (linha 15), na medida em que a correção de rotas não tem o potencial de reduzir o custo, mas sim, na melhor hipótese, o manter constante.

A correção das rotas é realizada corredor a corredor, através do mapa ordenado hash_rest para cada chave, se algum elemento da lista l_bool_violacao estiver com valor TRUE, o corredor deve ser corrigido. Cada corredor pode ter no máximo uma violação (haja vista que a solução sem correção é viável ao TSP), dessa forma, a correção do corredor é feita por meio de 3 etapas:

x Exclusão de arco.

x Religação de arco removido.

x Religação de arco viável.

Os arcos a serem removidos da rota dependerão da posição em que a violação se encontra no corredor, X-(1,2) ou X-(3,4);

Se X-(1,2), remover os arcos que chegam ao 2º ponto.

Se X-(3,4), remover os arcos que chegam ao 3º ponto.

Os dois casos são mostrados na FIGURA 36, considerando que existem itens a serem coletados tanto em 1-(1,2) como em 1-(3,4), os arcos em azul e vermelho representam os que devem ser removidos.

FIGURA 36 – ARCOS A SEREM REMOVIDOS

FONTE: O autor (2018).

A partir dos arcos excluídos, dois novos devem ser formados, religando-os ao 2º ou 3º ponto de cada corredor, dependendo, novamente, da localização da violação:

x Se em X-(1,2), religar ao 3º ponto.

x Se em X-(3,4), religar ao 2º ponto.

Na FIGURA 37 são mostrados os arcos religados da FIGURA 36:

FIGURA 37 – RELIGAÇÃO DE ARCOS

FONTE: O autor (2018).

Dessa forma, a violação do corredor 1 foi removida. É importante ressaltar que o processo descrito, pode por sua vez, gerar infactibilidade em locais em que as

mesmas não existiam previamente. Isso se deve ao fato de que sempre existem 2 caminhos entre 2 pontos em corredores diferentes (passando por CTI e CTS), pode ocorrer que, após a remoção de um arco (que estava inicialmente passando pelo CTI), o processo de religação com um ponto diverso dite que a menor distância entre os pontos agora passa pelo CTS, quando isso ocorrer, ou seja, os custos dos arcos antes e depois da remoção forem diferentes, deve-se forçar o valor a ficar igual o anterior.

Após a rota ser corrigida, seu novo custo é calculado (linha 16), e se for menor do que o menor custo viável até o momento, o mesmo é substituído pelo menor encontrado (linha 17). O cálculo do custo nesta etapa deve levar em consideração as imposições realizadas sobre a matriz booleana, na medida em que o custo dos arcos pode não necessariamente ser o que representa a menor distância.

Com esse algoritmo, todas as rotas que têm possibilidade de melhoria são corrigidas, e ao final, a melhor destas é tomada como a solução.