—— Projecto ——

Parque Automatico

Grupo 46: Beatriz Ferreira (78794), Henrique Nogueira (78927)

Instituto Superior Tecnico - MEEC

Algoritmos e Estrutura de dados

12 de Dezembro de 2015

1

Conteudo

1 Introducao - exposicao do problema “Parque Autom�atico” 31.1 Regras e metrica do problema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

2 Abordagem ao problema 4

3 Arquitectura do programa 53.1 Inicializacao da estrutura de dados principal “Map” . . . . . . . . . . . . . . . . 6

3.1.1 Extraccao de informacao do ficheiro de configuracao de base do parque . . 63.1.2 Construcao do grafo direccionado ponderado relativo ao parque . . . . . . 6

3.2 Ordenacao de instrucoes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.3 Processamento de instrucoes/Calculos de caminhos . . . . . . . . . . . . . . . . . 7

4 Estruturas de dados usadas 94.1 Estrutura Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94.2 Estrutura Point . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.3 Estrutura Graph . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104.4 Estrutura Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

5 Manipulacao de dados e ADT’s 115.1 LinkedList . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.2 htable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115.3 queue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125.4 prioQ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

6 Sub-sistemas funcionais 136.1 parkmap - modulo de gestao do parque . . . . . . . . . . . . . . . . . . . . . . . . 136.2 graphL - modulo de operacoes sobre grafos . . . . . . . . . . . . . . . . . . . . . 146.3 Algoritmo de calculo de caminho ideal - Dijkstra . . . . . . . . . . . . . . . . . . 15

7 Analise de eficiencia computacional 157.1 Custo de seccao “Inicializacao de estrutura de dados principal” . . . . . . . . . . 157.2 Custo de seccao “Ordenacao de instrucoes” . . . . . . . . . . . . . . . . . . . . . 157.3 Custo de seccao “Processamento de instrucoes/Calculos de caminhos” . . . . . . 157.4 Analise do custo em memoria . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

8 Exemplo de aplicacao 16

9 Analise crıtica e conclusoes 18

2

1 Introducao - exposicao do problema “Parque Autom�atico”

Neste Projecto criou-se um programa capaz de automatizar a atribuicao de lugares num parquede estacionamento, calculando o caminho e o lugar ideal que o cliente devera respeitar de formaa conseguir chegar ao seu acesso tao eficientemente quanto possıvel.

Dizer que um lugar ou um caminho e ideal depende com certeza da configuracao do parque,do local de entrada do cliente, do acesso pretendido pelo mesmo, e claro, da metrica de calculodo custo de um caminho. Para este efeito foram definidas as regras fundamentais as quaisestavamos sujeitos na elaboracao do algoritmo de resolucao.

1.1 Regras e metrica do problema

E dada ao ınicio a configuracao de um parque explicıtando desde logo a sua arquitectura base(vias, paredes, acessos, entradas, rampas, estacionamentos). Este e fornecido pelo ficheiro deconfiguracao que tem de obedecer as seguintes imposicoes:

1. todos os pisos do parque tem o mesmo tamanho e tem uma forma rectangular;

2. cada piso esta divido em filas e colunas, em que cada posicao desta matriz e descrita porum unico caracter que limita o comportamento do peao ou de uma viatura;

3. as entradas encontram-se todas na parede exterior e sao descritas uma a uma bem comoos acessos;

4. o parque podera estar originalmente com posicoes ocupadas (marcadas com o caracter ’x’);

5. tanto a viatura como o peao demoram uma unidade de tempo para se deslocarem deuma coordenada para outra (a excepcao das rampas de mudanca de nıvel que implicam2 unidades de tempo), podendo apenas andar em direccao nao diagonal, e o custo porunidade de tempo associado a cada um e de 1 no caso do carro e de 3 no caso do peao;

6. para aceder ao acesso o cliente tem obrigatoriamente de estacionar primeiro e depoiscaminhar ate ao mesmo;

7. existe um numero restrito de caracteres que podem descrever o parque, cada um com umarepresentacao diferente no mundo real:

• ’@’ - parede intransponıvel

• ’e’ - entrada para viatura

• ’a’ - acesso (apenas pode ser acedido por um peao)

• ’.’ - local vazio de estacionamento, o qual nao pode ser usado como via de transito

• ’x’ - local de estacionamento ocupado

• ’ ’ - via de circulacao, pode-se circular livremente como peao ou na viatura

• ’u’ e ’d’ - rampa de subida/descida que permite transitar para o piso superior. Naopode ser usada como via de circulacao e a sua existencia implica que na mesma filae coluna do piso imediatamente acima/abaixo do actual se encontra uma rampa dosentido oposto

Para alem deste ficheiro de configuracao, podera ser aplicavel um ficheiro de restricoes queindica quais os locais nao transitaveis e em que intervalos de tempo (podendo ser uma restricaode coordenada ou uma restricao de piso).

Por fim, o ficheiro de instrucoes especifica as viaturas que pretendem entrar no parque deestacionamento e pretendem aceder a um acesso especıfico, bem como as viaturas que terao saıdoentretanto. Este contem informacao sobre o nome identificador da viatura, o tempo de entrada,

3

as coordenadas da entrada que usou e por fim o tipo de acesso (descrito por um caracter) queo cliente deseja chegar.

O objectivo do programa e, tendo presente a configuracao do parque fornecida, as restricoesaplicadas e as entradas de clientes, gerar um output que explicita qual o local de estacionamentoideal, o seu custo, e o caminho associado ao mesmo (com indicacao dos tempos previstos dasposicoes). Por fim, o correr do programa exige tambem a aplicacao de uma fila de prioridadecaso o parque seja incapaz de devolver um lugar de resposta ao cliente (estando cheio).

E de notar que nesta seccao nao estao explıcitas todas as regras de aplicabilidade destesficheiros, no entanto dado tratar-se apenas de uma exposicao superficial do problema esta in-formacao bastara.

2 Abordagem ao problema

Ao sermos colocados inicialmente perante este problema, tornou-se claro que se tratava de umproblema de aplicacao de calculo de caminhos mais curtos em grafos ponderados direccionados,isto porque a cada passagem de coordenada no mapa esta um custo associado que depende domodo de andamento (carro ou peao) e do tempo associado a transicao de coordenada (1 paratodos os casos excepto as rampas que tem um tempo associado 2). Sao tambem direccionadosporque certas coordenadas permitem passar de uma coordenada para outra apenas num sentido.

A partida, consideramos desde logo 2 hipoteses de resolucao:

• a primeira prendia-se com a ideia de calcular uma SPT para a entrada em causa, quechegasse a todos os lugares de estacionamento, depois, calculava-se uma outra SPT comcomeco no acesso pretendido e que chegasse tambem a todos os lugares. Dadas estas duasSPT’s bastaria entao de encontrar o estacionamento que oferecesse o caminho de menorcusto.

• a segunda, que acabamos por aplicar ao projecto, passava por criar um grafo com o dobroda dimensao onde a primeira metade indicaria o movimento em modo viatura e a segundametade o movimento em modo peao. A passagem da primeira para a segunda metadepodia entao ser realizada apenas ao passar por um lugar de estacionamento, e claro, osacessos so eram atingıveis a partir da segunda metade do grafo.

Dado o grafo aplicavel ser esparso, o algoritmo de Dijkstra (se implementado de formaeficiente) tem complexidade de E ∗ lg(V ), onde E e o numero de arestas e V o numero denos. E facil de ver que para calcular as SPT’s completas em ambas as implementacoes obtem-se aproximadamente a mesma complexidade, no entanto a segunda implementacao permitiriaaplicar uma condicao de paragem mais rapida caso o acesso seja atingido, ja que nem sequerha necessidade de passar pelo processo de juncao de SPT’s. Em contrapartida, a primeiraimplementacao permite o guardar em memoria as SPT’s anteriores, pelo que permitiria assimo reutilizar de solucoes, ao contrario da segunda.

Abordamos inicialmente o problema como uma situacao do mundo real, tendo em conta asregras impostas pelo enunciado. Assim assumimos que o ideal era que, dada uma configuracaode um parque, o programa conseguisse calcular rapidamente um novo caminho ideal. Assumi-mos igualmente que para configuracoes de parques mais complexos, com milhares de lugares emultiplas entradas e acessos, seria pouco realista guardar em memoria todas as SPT’s que aprimeira hipotese impoe, especialmente com os limites de memoria que nos foram impostos.

Dados estes factos, optamos por implementar a segunda hipotese que, para alem da vantagemdescrita acima, acabaria por permitir uma mais facil modificacao dinamica da configuracao doparque, visto que era sempre calculado um caminho novo para cada caso.

4

3 Arquitectura do programa

A arquitectura geral do programa pode ser dividida em 3 principais seccoes:

• Inicializacao da estrutura de dados principal “Map” - Esta estrutura de dados contem todaa informacao vital relativa ao mapa do estacionamento em causa. Numa primeira fase, oprograma pega na informacao contida no ficheiro de configuracao e processa-a, guardando-a de seguida nos campos indicados da estrutura (informacao como dimensoes, entradas,acessos e o mapa de caracteres). A construcao do grafo de base fica tambem contida nestafase ja que e um requerimento obvio para passar a parte posterior de processamento sobregrafos.

• Ordenacao de instrucoes - o modulo parkmap esta pensado de forma a requerer umainstrucao unica e independente para cada processamento de dados, isto e, as instrucoesde calculo tem de ser dadas uma a uma (nunca sao integralmente independentes ja quealgumas instrucoes so sao aplicaveis apos outras). Para este efeito, sao lidos os ficheirosde instrucoes, descrevendo a entrada das viaturas, e o das restricoes, e fundem-se estasinstrucoes numa unica lista de instrucoes ordenada por tempos. Note-se que se da sempreprioridade as restricoes, ja que estas tem de ser aplicadas primeiro.

• Processamento de instrucoes/Calculos de caminhos - nesta ultima fase e onde e feito todoo calculo baseado no processamento das instrucoes uma a uma aplicadas sobre o grafoinicializado na estrutura “Map”. Fazem-se modificacoes dinamicas ao grafo actual, paraaplicar as restricoes e o preenchimento do parque, e calculam-se os caminhos ideais apercorrer por cada viatura. E nesta fase que e tambem gerida uma fila com indicacao doscarros que se encontram por estacionar tendo chegado mais cedo.

Figura 1: Representacao dependencial das seccoes principais do programa

A imagem da Figura 1 explicita as relacoes de dependencias entre cada fase do programa.De seguida procede-se a uma descricao mais detalhada das mesmas.

5

3.1 Inicializacao da estrutura de dados principal “Map”

A inicializacao da estrutura “Map” feita nesta fase pode ser dividida em dois momentos distintos:

1. Extraccao de informacao do ficheiro de configuracao de base do parque

2. Construcao do grafo direccionado ponderado relativo ao parque (dependente da primeira)

Assim o preenchimento dos campos da estrutura estao separados em duas partes dado quealguns dos campos exigem primeiro o preenchimento do mapa de caracteres em primeiro lugar.

3.1.1 Extraccao de informacao do ficheiro de configuracao de base do parque

De acordo com o protocolo, este ficheiro de configuracoes tem indicacao da seguinte informacaoacerca do parque:

• Dimensao do mapa dada em filas, colunas e pisos (N, M, P)

• Numero de entradas/Numero de acessos

• Descricao integral de cada posicao do piso atraves de uma matriz de caracteres para cadapiso

• Para cada piso, a indicacao dos locais de acessos e dos locais de entrada

Dada esta informacao contida no ficheiro, o primeiro passo passa por extrair directamentedo mesmo a informacao para os campos contidos na estruturas. No entanto, para alem disto,esta fase serve igualmente para:

• Pre-inicializar todos os campos da estrutura a valores tipo default

• Preencher uma lista indicativa de todos os diferentes tipos de acessos

• Preencher tabelas com indicacao explicita de cada ponto de entrada e de saıda

3.1.2 Construcao do grafo direccionado ponderado relativo ao parque

E nesta fase que e elaborado o grafo relativo a configuracao de base fornecida pelo ficheiro epreenchidos alguns dados necessarios para o processamento posterior.

De acordo com a nossa hipotese de implementacao, a dimensao do grafo sera o dobro donumero de nos existentes no parque (2×N×M×P). Os primeiros N×M×P nos referem-se aosvertices tipo viatura, enquanto que os seguintes referem-se aos vertices tipo peao. E facil deperceber que a unica forma de passar da primeira metade para a segunda metade do grafo epassando por um vertice de estacionamento livre, pelo que, arquitectando o grafo desta formae aplicando o algoritmo de calculo de caminhos ideais, obtemos de certeza uma solucao validadesde que respeitemos as regras de conduta no parque. A representacao do grafo sera feita emforma de listas de adjacencias, ja que se trata de um grafo esparso (cada vertice tem no maximo4 arestas adjacentes).

Na realidade o grafo nao tem apenas (2×N×M×P) vertices mas sim (2×N×M×P + D) nos,onde D representa o numero de acessos de tipo diferente. Estes ultimos, estao reservados paraos vertices mae de cada tipo de acesso, permitindo ligar cada entrada de um determinado tipo aeste vertice mae a partir de arestas incidentes. Este ponto e particularmente importante pois osdados no ficheiro de instrucoes indicam, nao o acesso especıfico que o cliente pretende atingir,mas sim o tipo de acesso. Alem do mais, definir vertices mae permitiu simplificar tremendamentea implementacao do algoritmo de calculo de caminho ideal posteriormente utilizado.

6

Feita a atribuicao destes vertices mae, e necessario por fim criar uma ”lookup table”, indi-cando para cada tipo de acesso dado por um caracter qual a posicao do vertice mae correspon-dente. Embora se pudesse aplicar uma tabela de dispersao para este fim, e muito mais simplesconsiderar que existem apenas 255 caracteres distintos aplicaveis (de acordo a tabela ASCII)pelo que basta criar uma tabela indexada por caracteres com 255 posicoes distintas.

Esta fase passa portanto por, para cada ponto do mapa, representa-lo por 2 vertices nografo (modo viatura e modo peao) e proceder a um varrimento dos vertices adjacentes para osacrescentar ou nao a sua lista de adjacencias. E nesta fase que se definem as regras de conduta,pois estaremos a indicar directamente quais os vertices que permitem a transicao para outros.Por fim, os vertices do tipo acessos, que contem apenas como vertice adjacente o vertice maecom peso 0, sao apenas atribuıdos a arestas no final, percorrendo a tabela de pontos de acessocalculada na fase anterior.

Finalmente e feita a inicializacao de 3 estruturas de dados mais tarde usadas e reutilizadasno processamento de dados: o vector st de origens, o vector wt de pesos e a fila de prioridadesdinamicas PQ.

3.2 Ordenacao de instrucoes

Existem dois diferentes tipos de ficheiros de instrucoes fornecidos como input ao programa: o deviaturas (obrigatorio) e o de restricoes (opcional). Nesta fase, os ficheiros sao processados e asinstrucoes sao guardadas individualmente numa estrutura simples tipo “Order”, contendo apenasa informacao relativa a uma restricao (string identificadora, tipo de accao, caracter descritivoassociado, tempo e coordenadas). Codificando ambos os ficheiros em listas de “Orders” obtemosduas listas inversamente ordenadas em tempo (dado que a insercao em listas e feita sempre noinıcio). Obtidas estas listas e aplicada uma funcao “Merge”, que as coloca numa so lista e invertede novo a ordem (voltando a ordem original). Esta funcao tem o especial cuidado de colocaras restricoes em prioridade sobre as outras instrucoes, isto porque uma restricao aplicada numinstante e valida logo nesse mesmo instante.

Por fim e inicializada uma fila tipo “First in first out”, mais tarde utilizada no processamentodas ordens.

3.3 Processamento de instrucoes/Calculos de caminhos

Esta seccao corresponde ao ponto de funcionamento principal do programa, onde se percorrea lista de Ordens procedendo ao calculo e modificacao do grafo correspondente. Dada a inici-alizacao da estrutura de dados “Map” e a ordenacao das instrucoes pode-se entao proceder acomputacao de solucoes e impressao de output para o ficheiro final.

Para se perceber esta fase, e primeiro necessario entender a sequencia de operacoes a tomarpara cada tipo de ordem.

7

Figura 2: Fluxograma: Processamento de instrucoes. Pensa-se no inicio como sendo o blocoindicando ”Proxima ordem”, onde a primeira ”Proxima ordem”e obviamente a primeira ordem

A imagem da Figura 2 representa o procedimento de accoes a tomar dada uma nova ordempor processar:

• ’if ’ entrada no parque - se possıvel calcula-se o caminho para a entrada respectiva,senao envia-se a viatura para a fila de prioridade.

• ’if ordem saıda do parque - liberta-se o respectivo vertice do grafo para se poderutilizar de novo e imprime-se o output. Se a proxima ordem for diferente de uma entradano parque, entao passa-se a processar essa mesma, senao significa que existem condicoespara tentar calcular o caminho ideal para o carro mais prioritario da fila

• ’if ’ restricao retirada - semelhante ao anterior, excepto que se pode desactivar qualquerno no grafo neste caso

• ’if ’ ordem de restricao - bloqueia-se os nos respectivos e passa-se para a proxima ordemda lista

8

Mais a frente serao discutidas as funcoes intrınsecas a cada um dos tipos de ordens indicados.

4 Estruturas de dados usadas

Na implementacao deste programa utilizaram-se as seguintes estruturas de dados:

1. Map - implementada no modulo parkmap

2. Point - implementada no modulo point

3. Graph - implementada no modulo graphL

4. Order - implementado na main

Segue-se uma descricao detalhada das mesmas e argumentacao do seu proposito no ambitodo programa

4.1 Estrutura Map

Trata-se, como foi dito anteriormente, da estrutura mais fundamental para o funcionamento doprograma. Nela esta contida toda a informacao do mapa do parque e os dados necessarios aaplicacao dos algoritmos de processamento de instrucoes.

E composta pelos seguintes campos:

• N, M, P - a dimensao do mapa em causa: numero de colunas, numero de filas e numerode pisos. Sao essenciais ao longo de todo o programa dado que e muitas vezes necessarioutilizar estes parametros

• E, S - respectivamente numero de entradas e de acessos do parque.Utilizado sobretudo nainicializacao e preenchimento de outros dados tais como a tabela de entradas e de acessos.E contudo um parametro basico do parque.

• representacao de caracteres (mapRep) - contem a representacao em caracteres retiradado ficheiro de configuracao do parque. Essencial sobretudo no processo de construcaodo grafo, embora seja algumas vezes usados para inquirir sobre o tipo de caracter a quepertence um dado ponto do mapa

• difs, accessTable, e accessTypes - a primeira contem o numero de acessos diferentes, asegunda e a tabela tipo ”lookup”usada no processamento de instrucao de calculo de ca-minho, visto que indica o no de acesso mae, e a terceira e uma lista indicativa do tipode acessos diferentes presentes no mapa, que e util no contexto de inicializacao do campoimediatamente anterior e numa eventual listagem dos acessos disponıveis ao cliente

• ramps - tabela de listas de estruturas tipo Point indicando informacao sobre todas asrampas de um determinado piso. Util no contexto de restricoes aplicadas sobre um pisointeiro.

• vectores st e wt - respectivamente vectores de origens e de pesos de um grafo usados nocontexto da aplicacao do algoritmo de calculo do caminho ideal de Dijkstra. Pertencemao campo da estrutura Map pois sao guardados de modo a evitar a reinicializacao dosmesmos a cada calculo.

• PQ - fila de prioridades dinamicas usada na aplicacao do algoritmo de calculo do caminhoideal de Dijkstra. Tal como os vectores imediatamente acima pertence a um campo daestrutura que permite melhorar a eficacia de execucao

9

4.2 Estrutura Point

Esta estrutura foi implementada como uma forma de guardar certos pontos importantes domapa. Embora ao inıcio se pensasse que acabaria por ter mais importancia, continua a ser umaferramenta util para, por exemplo, guardar os pontos de entradas, acessos e rampas do mapa.E composta pelos seguintes campos

• x, y, z - coordenada cartesiana do ponto associado. Essencial para localizar o ponto nomapa

• id - string identificadora do ponto. Pouco importante, embora permita identificar qual oponto usando o seu nome

• desc - caracter descritivo do ponto. A identificacao do tipo de ponto, embora nao usadaexplicitamente, deve estar contida na estrutura, pois e ela que define o ponto

4.3 Estrutura Graph

Esta estrutura pertence ao modulo graphL e consiste na representacao de um grafo direccionadoponderado em representacao de listas, adaptado as necessidades do programa, mais especifica-mente, as necessidades do modulo parkmap. Define-se igualmente a estrutura edge representandouma aresta, para a simplificacao da representacao do grafo. E importante indicar que a funcaoprincipal de calculo do caminho ideal se encontra no mesmo modulo, pelo que a estrutura e omodulo terao sido arquitectada tambem de acordo com as necessidades do algoritmo. Contemportanto os seguintes campos:

• nodes - indica o numero total de nos num dado grafo

• adjL - grafo representado por uma tabela de listas de adjacencias indexada pelos nos,onde cada elemento da lista contem a informacao sobre uma aresta. Trata-se do elementoessencial na representacao do grafo

• active - vector adicionado de modo a satisfazer a necessidade de controlo sobre os verticesdo grafo. Trata-se de uma tabela indexada por vertices que contem informacao acerca daocupacao/restricao do lugar.

4.4 Estrutura Order

Por fim, dado que as instrucoes de viaturas e restricoes se encontram ordenadas por temposnuma so lista, surgiu a necessidade de criar uma estrutura guardando a informacao contida emambas as instrucoes independentemente de se tratar de um tipo ou outro. Assim fomos capazesde fazer com que o modulo parkmap possa funcionar em contextos mais gerais respondendo ainstrucoes individualmente fornecidas pelo sistema. Os seus campos sao:

• type - caracter descritor de um tipo. Util no contexto de entrada de viatura apenas, indicao acesso requisitado pelo cliente

• action - caracter descritor da ordem. Pode ser ’E’ (entrada de viatura), ’S’ ou ’s’ (saıdade viatura, por coordenadas ou por identificador de veiculo), ’P’ ou ’R’ (restricao de pisoou coordenada) e finalmente ’p’ ou ’r’ (restricao retirada)

• x, y, z - coordenada respectiva a uma dada ordem

• id - string identificadora do veıculo (apenas usada no contexto dos veıculos e nao nasrestricoes)

10

5 Manipulacao de dados e ADT’s

Ao longo do programa recorremos varias vezes a ADT’s (abstract data types) para gerir eficaz-mente a manipulacao das estruturas de dados descritas anteriormente. As ADT’s, nao triviais,utilizadas foram:

1. LinkedList1 - listas de itens sem tipo definido

2. htable - tabelas de dispersao de pares {key, object} onde a key e um identificador tipostring e o object e um numero inteiro

3. queue - fila prioritaria “FIFO” de itens sem tipo definido

4. prioQ - fila prioritaria dinamica

Segue-se uma descricao destes tipos, bem como dos algoritmos associados para manipulacaode dados e o seu proposito no ambito do programa

5.1 LinkedList

No programa e varias vezes chamada a utilizacao de listas para manipular todo o tipo de da-dos. Esta ADT torna-se portanto vital na representacao das listas permitindo inclusive a suautilizacao perante qualquer tipo de variavel em causa. Trata-se de uma ADT bem definida glo-balmente com algoritmos de manipulacao standard pelo que nao iremos abordar os algoritmosde implementacao basica das listas.

No entanto, no contexto do programa, acrescentou-se um algoritmo de manipulacao “Mer-geOrderedLists” capaz de fundir duas listas inversamente ordenadas numa so lista ordenada(relativamente a um parametro escolhido pelo cliente). O processo passa simplesmente por,para cada elemento de cada lista, compara-lo com o primeiro elemento da lista oposta e retiraro de maior prioridade de uma das listas originais para a nova lista fundida. E facil de ver queno final obtem-se uma lista ordenada fundida pois a ordem esta a ser invertida por insercao doelemento de mais alta prioridade no inıcio da lista final!

5.2 htable

Uma das instrucoes do programa e a indicacao de saıda de um veıculo previamente estacionado.Dadas as coordenadas do veıculo, seria directo o processo de update do grafo, no entanto, se forapenas fornecido um identificador do veıculo torna-se importante ser capaz de identificar em queno esta atribuıdo o seu respectivo lugar. Aı entra esta ADT que para cada string identificadorade veıculo, vai atribuir uma posicao na sua tabela e guardar o valor do no respectivo.

Para este efeito, implementaram-se tabelas de dispersao por listas, pois simplificava o pro-cesso de gerir as colisoes (duas viaturas diferentes com a mesma key gerada).

A inicializacao da estrutura e feita indicando um tamanho para a tabela e uma constante decalculo (esta sera entao usada no calculo do ındice na funcao hash). No contexto do problemaparque automatico, escolheu-se usar como dimensao o numero total de lugares no parque porrazoes de simplicidade, bem como uma constante de hashing com valor 17 (por ser um numeroprimo).

O processo de hashing da key fornecida e feito de forma simples: percorre-se a key daesquerda para a direita com um valor hash original de 0, isto e, h = 0. Utilizando o valor inteirorelativo ao caracter em causa soma-se ao hash esse valor mais o proprio hash multiplicado pelaconstante de hash, ou seja h = h× p + c. Apos percorrida a chave, o valor de hash obtido pelakey e o resto inteiro do valor calculado pela dimensao da tabela (h = h%m). Assim garantimosque o ındice e sempre valido, e que para duas chaves iguais se obtem o mesmo hash.

1modulo fornecido pelos professores da disciplina de AED

11

Definida a funcao anterior, o processo de insercao de um par {key, object} passa apenaspor: calcular o hash obtido com a key, e inserir o object na lista desse ındice da tabela. Nota:na realidade os objectos da lista sao uma estrutura simples que contem nao so oidentificador do no, mas tambem a sua chave. Isto para, no caso de existencia decolisao de chaves, se poder verificar que o no pretendido e mesmo o retirado da lista

A obtencao do valor do no da lista (HTget) e igual ao processo anterior, diferindo apenasque em vez de se fornecer um par {key, object}, fornece-se apenas a key e vai-se a procura narespectiva lista qual o object em causa.

5.3 queue

Para a representacao da fila de espera de entrada no parque de estacionamento implementou-seuma ADT de fila “FIFO” generico de tipos nao definidos. A aplicacao no programa passa porenviar para a fila a estrutura Order que ficou por executar.

Neste caso particular, acrescentou-se a funcao menos vulgar de QpushFirst que, em vez deenviar para o final da fila, envia de volta para o ınicio. No contexto do programa, a funcao eutil para reenviar carros cujo caminho foi impossıvel de calcular (por restricoes que bloqueiamindirectamente certos lugares de estacionamento que depois nao foram contabilizados para onumero de lugares disponıveis).

5.4 prioQ

O programa cinge-se a aplicacao correcta do algoritmo de Dijkstra para calculo de caminhosideais. A complexidade do algoritmo chega a ser quase linear quando se trata de grafos esparsos(o caso em estudo garante sempre um grafo esparso), no entanto isto so e verdade se para oefeito for usado uma fila de prioridade dinamica como a que se descreve de seguida.

Esta fila tem como proposito o de implementar um acervo aplicado sobre os pesos dos nos dografo em causa. Assim, podemos garantir que o no da primeira posicao do acervo tera sempreo menor peso do grafo inteiro. Para este efeito, o objectivo e que, apos modificado o peso deum dado no, se possa fazer um update sobre esse mesmo no de modo a manter a condicao deacervo. A estrutura desta fila contem os seguintes campos:

• N - indica a dimensao do acervo

• size - indica o tamanho da tabela que representa o acervo

• wt - vector de pesos que fornece a nocao de prioridade

• heap - tabela que representa o acervo em que o conteudo de cada ındice e precisamente ono do grafo

• index - tabela auxiliar que indica o ındice do no na tabela heap. Essencial para simpli-ficacao posterior do algoritmo de Dijkstra dado que para se poder fazer update do acervoe necessario saber que posicao do mesmo corresponde ao mesmo no

De seguida indicam-se algumas funcoes mais importantes da fila de prioridades dinamicabem como uma breve descricao do seu funcionamento:

• PQinit - inicializa a estrutura alocando espaco em memoria e inicializando as tabelas heape index com valores default

• FixDown, FixUp - algoritmo generico de actualizacao da prioridade do ındice da tabelade acervos. Aplicam trocas sucessivas com o pai (FixUp) ou um dos filhos (FixDown) atemanter a condicao de acervo

• PQupdateNode - procede a actualizacao do acervo escolhendo aplicar FixDown ou FixUpdependendo da relacao entre o pai no acervo relativo ao no e dos filhos no acervo

12

• PQdelMin - indica o no de mais alta prioridade do acervo, retirando-o do mesmo. Paraeste efeito e efectuada uma troca do primeiro com o ultimo, o decremento de N e aplicadoo FixDown ao ”novo”primeiro elemento do acervo.

• PQreset - tem como objectivo o de colocar wt, st e PQ na condicao inicial em tempoinferior ao que seria de reinicializar os dados todos. Para este efeito percorre os ultimosındices da tabela heap nao contidos no acervo, actualizando wt do seu no com o valor demais baixa prioridade e incrementando o valor de N. Depois para os nos do acervo originalpercorre-se o acervo para todos os nos com prioridade diferente da default mais baixa.Deste modo conseguimos garantir que sao percorridos sempre menos de N nos do acervo

6 Sub-sistemas funcionais

Nesta seccao indicam-se os diferentes sub-sistemas do programa, isto e, os diferentes modulos quepermitem o seu funcionamento, bem como uma breve descricao das suas funcoes fundamentais.Os sub-sistemas funcionais do programa sao os seguintes:

• parkmap - modulo principal onde estao definidas as funcoes de processamento de instrucoes(dependente do modulo graphL)

• graphL - modulo de operacoes sobre grafos (filho do modulo parkmap)

6.1 parkmap - modulo de gestao do parque

Este consiste no modulo principal do programa. Ao pensar na estruturacao do programa,chegamos a conclusao que o ideal estaria em ter um modulo que respondesse a instrucoes indi-viduais vindas de um parque de estacionamento real. Assim a passagem para a aplicacao numsistema de parque automatico passaria apenas por criar um sistema capaz de enviar instrucoespara o modulo e outro capaz de processar o seu output. Contudo, dadas restricoes de tempoe para simplificacao do programa como um todo, a impressao do output no seu estado actualainda e algo dependente do modulo da funcao main, no sentido que a impressao e feita em ambosos modulos dependendo da situacao.

Este modulo C, encontra-se definido na interface “parkmap.h” utilizando o ficheiro de source“parkmap.c”. E dependente de sub-modulos definidos nas interfaces: “LinkedList.h”, “point.h”,“graphL.h”, “queue.h”, “prioQ.h”, “htable.h” e “escreve saida.h”. Encontram-se definidas asseguintes funcoes fundamentais com o respectivo proposito:

• Map *mapInit(char *) - funcao que inicializa uma estrutura do tipo “Map”. E passadocomo argumento o ficheiro de configuracao do parque que por sua vez e processado peloprocesso definido anteriormente.

• void buildGraph(Map *) - inicializa e constroi o grafo interno a estrutura “Map” com basena representacao do mapa obtida na funcao MapInit

• int *findPath(Map *parkMap, char *ID, int ex, int ey,int ez, char accessType, int *cost, int*stSize) - dadas as coordenadas de entrada, o tipo de acesso e o identificador da viatura,o programa retorna o vector de origens obtido no calculo do caminho. As variaveis conste stSize sao enviadas por referencia para se obter o custo total do caminho bem como onumero de posicoes que se atravessam no mesmo.

• void restrictMapCoordinate(Map *parkmap, int x, int y, int z) - restringe uma posicao domapa para uso no calculo do caminho ideal

• void freeRestrictionMapCoordinate(Map *parkmap, int x, int y, int z) - retira a restricaoprevia da posicao no mapa

13

• void restrictMapFloor(Map *parkMap, int floor) - restringe um piso inteiro para uso nocalculo do caminho ideal

• void freeRestrictionMapFloor(Map *parkMap, int floor) - desfaz o efeito da funcao imedi-atamente acima

• void clearSpotCoordinate(map *parkMap, int x, int y, int z) - retira a indicacao de quelugar esta ocupado (argumento fornecido em coordenadas)

• void clearspotIDandWrite(FILE *fp, Map *parkMap, char *ID, int time) - retira a in-dicacao de que o lugar esta ocupado e escreve output (argumento fornecido em stringidentificadora)

• void writeOutput(FILE *fp, Map *parkMap, int *st, int cost, int time, char *ID, characcessType, int pathSize) - imprime output relativo a um vector de origens.

• void writeOutputAfterIn(FILE *fp, Map *parkMap, int *st, int cost, int time, char *ID,char accesstype, int origTime, int pathSize) - imprime output relativo a um vector deorigens, neste caso ignora-se a primeira linha de output relativa a entrada do carro noparque

• int isParkFull(Map *parkMap) - retorna o valor 1 se o mapa tiver lugares disponıveis e ovalor 0 caso contrario.

6.2 graphL - modulo de operacoes sobre grafos

Este modulo foi estruturado de forma a efectuar operacoes sobre o grafo ponderado direccionadodo parkmap. Para alem de funcoes basicas para gerir os grafos representados por tabelas delistas de adjacencias, a estrutura ”Graph”definida tem em conta quais o nos activos e quais osque devem ser ignorados por corresponderem a posicoes nao transitaveis. Deste modo, graphL eparkmap sao dois modulos mutuamente dependentes que trabalham para um mesmo objectivo,pode contudo ser pensado como o sub-modulo mais importante de parkmap.

Encontra-se definido na interface “graphL.h” com o ficheiro de source “graphL.c” sendodependente dos modulos definidos pelas seguintes interfaces: “LinkedList.h” e “prioQ.h”. Dasfuncoes implementadas, as seguintes tem particular relevancia no contexto do problema:

• Graph *Ginit(int nodes) - inicializa grafo com tabela indexada por nos sem arestas

• void GinsertEdge(GraphL *g, int v, int w, int value) - adiciona aresta ao grafo a partir dono fonte v, incidindo no no destino w com peso de aresta value.

• int Gnodes(Graph *g) - retorna o numero de nos existentes no grafo

• void GclearNode(Graph *g, int v) - modifica o no, indicando que deixou de estar ocupado

• void GoccupyNode(Graph *g, int v) - modifica o no, indicando que passou a estar ocupado

• void GrestrictNode(Graph *g, int v) - modifica o no, indicando que passou a estar restrin-gido

• void GunrestrictNode(Graph *g, int v) - modifica o no, indicando que deixou de estarrestringido

• int GDijkstra(Graph *G, int root, int dest, int *st, int *wt, PrioQ *PQ) - calcula o caminhoideal do no raiz (root) ate ao no destino (dest) modificando a tabela de origens na qualestara inscrito o resultado final. As tabelas st, wt e a fila de prioridade dinamica PQ saopassadas como argumentos em estado default simplesmente como uma forma de melhorar

14

a eficacia de calculos de multiplos caminhos. Assim, antes de serem enviados, e aplicadaa funcao PQreset que da reset ao seu estado inicial para se poderem reutilizar as mesmasestruturas.

6.3 Algoritmo de calculo de caminho ideal - Dijkstra

A base do problema do parque automatico prende-se com o calculo do caminho ideal aplicadosobre grafos direccionados ponderados pelo que e importante discutir a implementacao do algo-ritmo no nosso programa.

O algoritmo encontra-se aplicado numa funcao do modulo graph (GDijkstra) e utiliza afila dinamica de prioridades (prioQ) para maxima eficiencia em tempo. Difere apenas dumaimplementacao geral do algoritmo no sentido em que a relaxacao de arestas sobre um no erealizada somente se este estiver activo (desocupado ou sem restricao aplicada). Assim e sempreevitada a chegada ao destino passando por um no nao activo, pois sendo um acesso continua-sea nao estabelecer a conexao com o no mae de acesso.

7 Analise de eficiencia computacional

Finalmente, e importante fazer uma breve analise sobre a complexidade do programa implemen-tado.

Seja I o numero de viaturas por processar, R o numero de restricoes, N o numero depontos total do parque, E o numero de entradas, A o numero de acessos e P o numero deestacionamentos, faz-se uma analise de custo de cada uma das seccoes de runtime do programa.Fazendo em primeiro lugar uma analise sobre o custo.

7.1 Custo de seccao “Inicializacao de estrutura de dados principal”

Dado que para cada ponto do mapa e guardada a informacao do mesmo numa operacao unitariasabemos que temos pelo menos N × O(1) operacoes que tem de ser efectuadas neste processo.Para alem disto e guardado cada ponto de entrada e cada ponto de acesso com operacoes simplespelo que se acrescenta E ×O(1) + A×O(1). Como A + E < N temos que o custo total e iguala O(N) para esta primeira fase.

7.2 Custo de seccao “Ordenacao de instrucoes”

A colocacao em listas das instrucoes fornecidas pelos ficheiros tem complexidade I × O(1) eR × O(1) respectivamente no caso das instrucoes de entrada e das restricoes. A operacao dafuncao “MergeOrderedLists” efectua operacoes simples por cada elemento da lista pelo que temordem (I + R)×O(1). Logo esta seccao tem no total uma complexidade O(I + R).

7.3 Custo de seccao “Processamento de instrucoes/Calculos de caminhos”

Admitindo que no pior caso, cada instrucao de entrada de veıculo leva a um calculo de caminhotemos que o custo total seria I × C + R ×O(1)2, onde C e o custo do calculo de um caminho.O algoritmo de Dijkstra aplicado pode-se considerar ter, em casos de grafos esparsos, um com-portamento aproximadamente linear de O(N), obtido por aplicacao com auxılio de uma fila deprioridade dinamica como a utilizada, que por sua vez e O(N) na sua inicializacao e reutilizacao.Assim, por cada aplicacao de calculo de caminho temos um custo total de O(N) ou seja, no piorcaso temos um custo total de processamento de instrucoes de O(I ×N)3

2A implementacao das restricoes, do modo que foi feita, leva a uma independencia entre o calculo do caminhoe as restricoes em si

3Nota: embora a impressao de output bem com outros processos menos importantes cheguem a ter um custoigual ao tamanho do caminho, este e sempre menor que O(N) + O(R) pelo que nao e contabilizado

15

Contabilizando os custos de todas as fases do runtime, chegamos a um custo total de O(N ×I) +O(R), ou seja num caso usual O(N × I).

7.4 Analise do custo em memoria

Em termos de custos de memoria, a implementacao do programa tem custo total de O(I +R) +O(N) dado que o programa cria sempre um numero fixo de estruturas de dados de tamanhoO(N). Portanto o desempenho em memoria tem sempre complexidade linear.

8 Exemplo de aplicacao

Segue-se uma breve descricao da aplicacao do programa, no caso do calculo do caminho ideal(ignorando outro tipo de ordens cuja aplicacao e simples de entender)

1. START

2. abre ficheiro de configuracao para leitura

3. e chamada a funcao MapInit

4. (funcao MapInit)Inicializa estrutura Map alocando memoria

5. Coloca variaveis de campo a valores default

6. Inicializa matriz de representacao de caracteres (char ***mapRep)

7. le ficheiro de configuracao e copia primeiro piso de caracteres para a matriz

8. le ficheiro de configuracao e guarda em memoria na estrutura os acessos e as entradas dessepiso

9. no caso dos acessos, se for um novo tipo de acesso acrescenta-se a lista de tipos de acessose incrementa-se o numero de tipos de acessos

10. repetir os 2 processos acima para os pisos seguintes ate terminar o ficheiro de configuracoes

11. fecha ficheiro de configuracao para leitura

12. chama funcao buildGraphs

13. (funcao buildGraphs) inicializa grafo

14. atribui nos de acesso mae ao grafo

15. inicializa tabela de listas de rampas

16. para cada no do grafo, dependendo do caracter correspondente, le os caracteres vizinho eadiciona, ou nao, uma aresta

17. para cada acesso na lista de pontos de acessos da estrutura, adiciona-se uma aresta que oliga a sua aresta mae

18. inicializa os vectores st e wt com valores respectivamente -1 e “NOCON”4

19. inicializa a fila dinamica de prioridades associada a wt

20. abre ficheiro de instrucoes para leitura

4declarado como variavel global, valor suficientemente alto de baixa prioridade

16

21. inicializa a lista de instrucoes de veıculos

22. le a primeira instrucao

23. preenche estrutura Order e guarda na lista passando para a proxima instrucao veıculo(repete ate extinguir o ficheiro de instrucoes)

24. fecha o ficheiro de instrucoes

25. se houver ficheiro de restricoes aplicar processo semelhante ao da lista de instrucoes deveıculo

26. chama funcao “MergeOrderedList”

27. (funcao “MergeOrderedList”) enquanto existirem Ordens de veıculos e de restricao, com-parar a de maior tempo (com prioridade nas instrucoes de veıculos) e item numa nova lista(entretanto apagando as listas anteriores)

28. se uma das listas chegar ao fim, preencher com a lista oposta

29. obtida a lista fundida

30. procede-se ao processamento das Ordens

31. inicializar fila prioritaria tipo “FIFO”

32. abre-se o ficheiro de output para escrita

33. se ordem for do tipo ’E’ (estacionar)

34. verificar se a fila prioritaria esta vazia e o parque nao esta cheio

35. se sim chamar funcao findPath com o destino e origem respectivo a ordem retirada

36. (funcao findPath) calcula os ındices do no de origem com base nas coordenadas dadas edo destino olhando para a tabela ”lookup”accessTable

37. efectua o reset sobre os vectores st, wt, PQ (neste caso, como ainda e o primeiro, nada emodificado)

38. coloca a origem com a mais alta prioridade (wt[origin] = 0)

39. faz um update a PQ

40. e chamada a funcao GDijkstra

41. enquanto o no de mais alta prioridade de PQ nao tiver peso infinito, retira-se o no maisprioritario do acervo com PQdelmin(PQ) e verifica-se se e um no activo (nao esta ocupadonem restringido), verifica-se que o no nao e o destino, e para cada aresta do no aplica-sea relaxacao da aresta

42. por fim se o no destino e atingido, termina-se o ciclo

43. se o destino nao foi atingido retorna-se o vector null, senao com o vector st obtido, percorre-se o mesmo para preencher o lugar, enviando para a tabela de dispersao o par {id daviatura, no estacionado}

44. se nao existir caminho, e escrito apenas o output de entrada do carro e a ordem e enviadapara o fim da fila prioritaria “FIFO”

45. se existir o caminho e chamada a funcao writeOutput

17

46. (writeOutput) percorre o caminho descrito na tabela st, calculando o tempo total ao mesmotempo que imprime com a funcao escreve saida os nos que representam uma mudanca dedireccao ou outro ponto importante da trajectoria

47. terminada a lista de ordens liberta-se a memoria alocada pela estrutura Map usada bemcomo a funcao main

48. fecha-se o ficheiro de output para escrita

49. FIM

9 Analise crıtica e conclusoes

Com o desempenho da implementacao realizada conseguiu-se obter um resultado de 18/20 testespassados, sendo que os testes chumbados corresponderam a limites de tempo ultrapassados.

Tendo em conta a informacao fornecida pelo pessoal docente, os ficheiros de teste consistirammais no processamento de ficheiros com elevados numeros de veıculos de entrada, em mapasde relativamente baixa complexidade (onde o maior tinha dimensoes 20*20*10) com apenaspoucos casos onde se aplicavam restricoes. Dados os testes a que fomos submetidos estamossatisfeitos com os resultados ja que a implementacao escolhida tinha sido pensada com baseem mapas grandes, poucas instrucoes de entrada de veıculos e com facilidade na aplicacao dasrestricoes. Contudo, o ideal seria implementar-se um programa capaz de avaliar quais dos duaspossibilidades descritas aplicar consoante I R e N , ou seja, dados I grande e N pequenos aplicar-se ia o algoritmo capaz de reutilizar solucoes (1o hipotese) e dados I pequenos e N grandesaplicar-se ia o nosso. No entanto, para aplicacoes do mundo real, existindo estacionamentos deuma complexidade tremenda e visto que a capacidade de calcular muitos casos em pouco tempoe de um modo geral pouco importante (um condutor esta disposto a esperar centesimos desegundo em casos muitos excepcionais se necessario) acreditamos ter escolhido a implementacaoideal para um sistema de parque de estacionamento automatico.

Referencias

[Damas, 1999] Damas, L. (1999). Linguagem C. FCA.

[docente de AED, 2015a] docente de AED, C. (2015a). Acetatos.

[docente de AED, 2015b] docente de AED, C. (2015b). Guia do projecto.

[Sedgwick, 1988] Sedgwick, R. (1988). Algorithms in C. Addison-Wesley.

18