Volta a Portugal Relatório Algoritmos e Estruturas de Dados 2º ano do Mestrado Integrado em Engenharia Informática e Computação Elementos do Grupo: João Carlos Figueiredo Rodrigues Prudêncio 070509111 ei07111@fe.up Pedro Miguel Cerqueira da Silva 060509002 ei06002@fe.up.pt José Miguel Teixeira Viana 070509139 - ei07139@fe.up.pt Turma: 2MIEIC5 10 de Dezembro de 2008
Índice 1. Introdução... 3 2. Descrição estruturada do problema... 4 2.1 Pressupostos...4 2.2 Casos de utilização...7 3. Desenho da solução...9 4. Implentação..... 14 5. Conclusão..... 16 6. Bibliografia 17 Índice de imagens Ilustração 1 Diagrama de casos de utilização... 8 Ilustração 2 Modelo de classes UML... 13 Ilustração 3 Menu de inserção de chegadas a etapas.....14 Ilustração 4 Menu de classificação geral individual por tempos.... 15 Ilustração 5 Menu de pesquisa de eventos..... 15 2
1. Introdução O trabalho prático que este relatório expõe é no âmbito da disciplina de Algoritmos e Estruturas de Dados leccionada no segundo ano do Mestrado Integrado de Engenharia Informática e Computação da Faculdade de Engenharia da Universidade do Porto. A elaboração deste relatório tem como objectivo explicitar e documentar um software desenvolvido pelos autores do mesmo, na linguagem de programação orientada por objectos C++. Desta forma, nos capítulos que se seguem será apresentada a estrutura e organização global do programa, usando, entre outros, o UML. Este trabalho prático foi dividido em duas partes, sendo que a segunda parte era a continuação do projecto iniciado. Sendo assim, este relatório irá fundamentar todas as opções usadas, e funcionalidades implementadas, tanto da primeira parte, como da segunda. Em relação aos objectivos gerais do trabalho, pretendia-se um programa que tivesse a funcionalidade de gerir a Volta a Portugal em ciclismo, exibindo todas as funcionalidades para o cálculo de classificações, gestão de etapas, gestão de equipas e ciclistas, entre outras. No próximo capítulo, será relatada estrutura global do problema assim como as interpretações e bases que nos permitiram projectar um programa, e pensar nos algoritmos que o resolvessem. A elaboração deste projecto, teve como fundamento pesquisa bibliográfica, com recorrência a livros, pesquisa na internet acerca de algoritmia e programação em específico sobre linguagem C++ e UML. É de salientar que foi usado como ambiente de desenvolvimento de programação o programa Microsoft Visual Studio 2008, desta forma o grupo não garante que os ficheiros sejam correctamente interpretados por outro compilador que não o que este software usa. Para a esquematização do modelo de casos de utilização, foi usado o programa Microsoft Office Visio 2007. Por fim, usou-se um programa para realizar o diagrama de UML denominado Architecture Enterprise. Considera-se portanto, que este projecto foi estimulante para a aprendizagem de programação, e da linguagem C++ em concreto, na medida em que motivou o grupo na procura de soluções para o problema proposto. Além de competências de programação, competências de trabalho de equipa e de organização de projectos foram da mesma forma estimuladas. 3
2. Descrição estruturada do problema 2.1. Pressupostos O enunciado do trabalho prático, propõe a elaboração de um sistema para gestão da Volta a Portugal em bicicleta. Considera-se portanto essencial entender toda a conjuntura deste desporto, em termos de organização das suas estruturas básicas e modelos de classificação, assim como dos elementos que têm uma participação activa no mesmo e de que maneiras é que intervêm. É portanto essencial, clarificar os pressupostos que consideramos, antes de iniciarmos o processo de estruturação do projecto, em termos de programação. Numa Volta a Portugal, existem um conjunto de equipas que participam na mesma. Uma equipa possui um conjunto de patrocinadores, para poder financiar a sua permanência na competição. É constituída por um director associativo, e por um conjunto de ciclistas. Não foi possível apurar qual o número de directores associativos que uma equipa pode ter, decidiu-se então definir que para a existência de uma equipa tem que existir um e só um director associativo que vai fazer a gestão da equipa. Sendo assim, para criar uma nova equipa na competição, é necessário referir qual o director associativo que vai assumir os cargos de gestão da mesma. Durante a competição é possível contratar outro director associativo para a equipa, mas uma equipa nunca pode ficar sem uma pessoa responsável por este cargo. Em relação aos ciclistas de uma equipa, estes são os principais intervenientes na competição. Um ciclista apenas pode existir associado a uma determinada equipa, tendo algumas características que achamos relevantes para o seu desempenho como desportista, tais como: eficácia a pedalar, altura, estilos dos quais é especialista, peso, potência a pedalar, assim como a sua capacidade aeróbia (VO2max). Note-se que consideramos que não existe limite para o número de ciclistas numa equipa. Consideramos apenas como restrição, que não podem existir nomes repetidos na competição. Iremos de seguida expor, de que medida é que estes agentes se envolvem na Volta a Portugal. Primeiro é importante referir que uma Volta a Portugal, ocorre com uma frequência anual, estando sempre associada a um ano. Uma volta de um determinado ano, é subdividida em várias etapas. Cada etapa é iniciada numa determinada data e está predefinido o número de quilómetros que o circuito dessa etapa possui, assim como o percurso que está irá tomar. Uma etapa é por sua vez subdivida, em várias locais, que podem ser ou uma meta-volante ou um prémiomontanha. Cada um destes checkpoints tem uma importância crucial para a classificação que irá ser explicada de seguida. 4
Tanto uma meta-volante como um prémio-montanha, possuem uma referência ao quilómetro que onde se encontra, ou seja, se pertencem a uma etapa que tem um circuito de 200 quilómetros, esses checkpoints terão que ter um quilómetro entre 0 e 200, garantindo assim que este se encontra dentro da etapa. Em cada meta-volante são registados os três primeiros ciclistas a chegar, e é registado o tempo a que estes chegam. São também atribuídos 5, 3 e 1 pontos pela ordem de chegada. Além disso, são atribuídas bonificações de 3, 2 e 1 minutos também pela ordem de chegada. Relativamente aos prémios-montanha, existem três tipos de categorias pelo que conseguimos apurar. Relativamente á categoria 1, não conseguimos descobrir qual era a pontuação que atribuía a um ciclista, pelo que arbitramos que seriam atribuídos 20, 16, 12, 8, 4 e 2 aos ciclistas pela sua ordem de chegada. Na categoria 2 seriam atribuídos os pontos da seguinte forma 10, 8, 6, 4, 2 e 1, e finalmente na categoria 3 seria 5, 3, 2, 1. Ainda relativamente aos checkpoints, apenas será importante guardar os tempos de chegada do ciclista em que são contabilizados os pontos. Por exemplo, num prémio-montanha de categoria 1, o sétimo ciclista a chegar, já não terá importância para a classificação, e portanto não será relevante contabilizar o tempo, nem o facto de ter chegado a esse local. Além destes locais referidos, também vai ser importante saber a ordem de chegada e o tempo que um ciclista chega no final de cada etapa. Neste caso, consideramos importante que todos os ciclistas possam cortar a meta, e portanto serão contabilizados todos os tempos. Aos primeiros três ciclistas a chegarem ao final da etapa, são atribuídas as bonificações de 10, 6 e 4 minutos respectivamente. Note-se ainda, que em cada um destes locais, não podem chegar dois ciclistas com o mesmo nome, ou seja, como seria óbvio um ciclista só pode chegar uma vez a um local. Ainda relativamente ás chegadas a um local, note-se que é importante que um ciclista não chegue primeiro ao final da etapa, e só posteriormente a uma metavolante, por exemplo. Com isto queremos dizer que, tem que haver coerência com a ordem de chegada de um ciclista em um local, e com a relação tempo/quilómetro de chegada. Apesar de parecerem situações óbvias, torna-se necessário esclarecer estas situações, porque quando se está a simular situações do mundo real através da programação, todos estes pressupostos convêm ser analisados e definidos. Após definir a estrutura de uma etapa, procede-se a explicação das classificações realizadas em cada etapa. A classificação individual por tempos é gerada a partir dos tempos alcançados por cada ciclista nessa etapa, que serão ordenados de forma crescente. Nesta classificação também são contabilizadas as 5
bonificações tanto da chegada ao final da etapa, como da chegada às metas-volante. No entanto, estas bonificações apenas são tomadas em conta aquando do cálculo da classificação individual por tempos. Para a classificação montanha, é preciso considerar os prémios-montanha existentes na etapa. A classificação montanha será portanto a soma de pontos montanha de cada ciclista. Estas pontuações serão ordenadas de forma decrescente, e portanto o ciclista que possuir mais pontos será o vencedor desta classificação. Relativamente à classificação por pontos, esta é determinada pela ordem de chegada ao fim da etapa. Para determinar esta ordem, consulta-se a classificação individual por tempos, ou seja, o ciclista que tiver menor tempo será o primeiro a chegar ao final da etapa. Serão considerados os dez primeiros a chegar, e a pontuação será atribuída da seguinte forma do primeiro para o último: 25, 20, 16, 13, 10, 8, 6, 4, 2 e 1 pontos. Existe também a classificação por equipas, que será como o nome indica ser constituída por equipas. A cada equipa soma-se então os três melhores tempos de todo o seu plantel activo de ciclistas. Posteriormente ordenam-se estes tempos de forma crescente, e a equipa que possuir um menor tempo será a vencedora desta classificação. Estes são os tipos de classificações existentes por cada etapa. Tal como já foi referido, uma volta é constituída por um conjunto de etapas. Assim, existe também uma classificação global que estará dependente da classificação de cada etapa. De seguida irá ser descrita como é calculada a classificação geral de uma volta. Existe também uma classificação individual geral por tempos, que para cada ciclista irá somar os tempos obtidos em cada uma das etapas. É nesta fase que serão contabilizadas as bonificações obtidas tanto nas metas-volante, como á chegada de cada etapa. Esta classificação irá ser ordenada de forma crescente por tempo. O ciclista com menor tempo será considerado o vencedor desta classificação e, portanto portador da camisola amarela. A classificação geral montanha, será como o nome indica obtida a partir da soma dos pontos de um ciclista em todos prémios-montanha de todas as etapas, caso tenho alcançado algum ponto de acordo com a metodologia já explicada. Estas pontuações serão ordenadas de forma decrescente, e portanto o ciclista que possuir mais pontos será o vencedor desta classificação e por conseguinte, portador da camisola azul. É também considerada a classificação geral juventude, que irá ser constituída pelos cinco melhores ciclistas da classificação geral individual por tempos, com 6
menos de vinte cinco anos de idade. O vencedor desta classificação é o portador da camisola laranja. Numa volta existe também uma classificação geral por pontos, mas esta é distinta da classificação por pontos das etapas. Assim, a classificação geral por pontos numa volta, não é mais do que para cada ciclista somar as pontuações obtidas por metas-volante assim como a sua pontuação na classificação montanha, se é que tem, para cada etapa. Note-se que o vencedor desta classificação é o portador da camisola branca. A classificação geral por equipas consiste na soma dos três melhores tempos individuais de cada equipa em todas as etapas disputadas. 2.2 Casos de utilização O diagrama de Use Case ou casos de utilização é referente a todas as acções que os intervenientes do processo de inscrição desencadeiam ou acções desencadeadas por terceiros que intervêm directamente com estes. O actor principal é o utilizador do programa. Tal como especificado no enunciado, serão considerados três tipos de utilizadores, visitante, administrador ou coordenador. O visitante apenas poderá consultar todos os dados relativamente às equipas, etapas, classificações, historial. Mas nada poderá alterar. O administrador tem as mesmas permissões para consultar toda a informação, e pode adicionalmente editar as classificações nas etapas, ou seja, adicionar tempos a um ciclista numa determinada etapa, ou uma chegada num prémio-montanha ou numa meta-volante. Pode também alterar o historial de um determinado ciclista, ou seja, adicionar ou remover prémios. Estas funcionalidades irão ser aprofundadas posteriormente. Para entrar no sistema como administrador será necessário um login e uma password, que estão guardados num ficheiro. O coordenador tem as mesmas permissões que o administrador, e adicionalmente pode alterar toda a constituição das equipas e das etapas, assim como configurar as contas dos utilizadores. Para entrar no sistema como coordenador é necessário também um login e uma password que estão armazenados num ficheiro. 7
Ilustração 2 Diagrama de casos de utilização 8
3. Desenho da solução Neste capítulo irá ser apresentada a organização das classes e suas funções. Note que devido á elevada extensão das classes e métodos do programa elaborado comparativamente com o número de páginas proposto para o relatório, irá apenas ser apresentado um modelo global e resumido das classes. Para um conhecimento profundo acerca das mesmas apenas é possível através da análise do código fonte. A classe Trabalhador tem como objectivo guardar as informações subjacentes a qualquer trabalhador numa equipa, ou seja, nome, data de nascimento e naturalidade. Esta classe possui os métodos set e get para poder alterar os membros dados assim como todas as outras classes que irão ser apresentadas de seguida. Utilizou-se o conceito de herança de classes e polimorfismo para elaborar as classes Ciclista e DirectorAssociativo, que herdam da classe trabalhador. Estas duas classes possuem os membros de dados que foram acordados ser os mais relevantes neste caso, e herdam todas as características do Trabalhador. Note-se ainda que existe um método imprimir em todas estas três classes, permitindo usar o conceito de polimorfismo, que dependente do tipo de objecto irá invocar o respectivo método imprime. A classe Equipa irá ser a classe que armazena Ciclistas e um Director Associativo. Assim esta classe irá ter os métodos adicionaciclista() e apagaciclista() que como o nome indica permite manipular o plantel da equipa. De notar que nesta classe já usamos o conceito de overloading de operadores, assim em muitas outras classes. Neste caso o método operator<<() foi definido, apesar de ser uma função friend e de não pertencer á classe. Estes operador é definido na maioria das classes que irão ser apresentadas. Foram desenvolvidas outras classes que o grupo achou pertinente e com bastante usabilidade. Uma dessas classes foi a classe Data e a classe Tempo. A classe Data possui um dia, mês e ano, e possui métodos para validação de datas e para impressão dessa data em forma de um tipo de dados do tipo string. Esta classe possui o método operator<() que permite comparar datas, o que é essencial para efectuar a classificação juventude, por exemplo. A classe Tempo é bastante similar, possuindo os membros dado hora, minuto, segundo. Possui alguns operadores implementados para incrementar, decrementar, comparar tempos. Esta classe também é essencial para toda a classificação. Uma outra classe não menos importante é a classe Excepcao, que é responsável por todas as excepções que possam ocorrer durante a execução do programa. Apesar de muito simples, contendo apenas um membro dado com o nome da excepção e o operator<<(), é correntemente usada ao longo de todo o programa. 9
A classe Etapa é fulcral no desenho deste programa. Responsável por grande parte das classificações como já explicado anteriormente, armazena também objectos do tipo MetaVolante, PremioMontanha, Pontuacao, que são também classes que foram elaboradas. A classe MetaVolante possui os membros dados do nome e do quilómetro a que essa meta-volante ocorre, mas também possui um vector com os primeiros ciclistas que chegaram a essa meta-volante, ou seja um vector de objecto do tipo Pontuacao. A classe PremioMontanha é muito similar, mas é utilizada para as pontuações montanha. A partir destas três classes ira ser possível gerar todas as classificações. Vão existir vários contentores genéricos do tipo vector que conterão as diferentes classificações. A classe Pontuacao é a classe base de todas as classificações, tendo portanto um apontador para Ciclista e um Tempo. Foi definido também o operator<() que irá ser usado para todo o tipo de classificações, este dirá que uma Pontuacao será menor que outra, quando o tempo da primeira for menor que o da segunda(usando o operador da classe Tempo). Relativamente ainda á classe Etapa, cada etapa possui um objecto do tipo Eventos, que irá conter uma Binary Search Tree(BST). Esta BST conterá um conjunto de objectos do tipo PontuacaoBST, este tipo de objectos contém um apontador para uma Pontuacao, e uma membro de dados do tipo string, que conterá a descrição dessa pontuação. Basicamente, um objecto do tipo PontuacaoBST será ou uma chegada ao final da etapa, ou uma chegada a uma meta-volante ou por último, uma chegada a um prémio-montanha. Desta forma, esta BST terá a funcionalidade para pesquisar eventos que ocorreram nessa etapa. Assim recorrendo a um algoritmo de pesquisa muito eficiente das árvores binárias, consegue-se encontrar rapidamente um conjunto de pontuações pretendidas, dentro de um intervalo de tempo estipulado. Relativamente á classe Volta, esta é basicamente constituída por um conjunto de etapas, apesar de conter também o seu próprio sistema de classificações baseado nas etapas já devidamente especificado. Este classe terá então acesso a um vector de objectos do tipo apontadores para Equipa, e um de objectos do tipo apontadores para Etapa. Ao longo da elaboração do programa, houve necessidade de usar sempre apontadores em todas as estruturas. Desta forma não se está a replicar os dados, existindo apenas a informação uma vez, o restante serão apontadores para essa posição de memória. Usamos esta situação no caso dos vectores de apontadores para Ciclista na classe Equipa, assim como na classe Etapa. Existem ainda as classes Visitante, Administrativo e Coordenador, responsáveis pelo interface com o utilizador. A classe Interface é o ponto de partida para o programa, permitindo escolher como deseja entrar no sistema. Esta classe possui um 10
apontador para um objecto do tipo Historico, e sempre que o programa é iniciado ou fechado os dados são carregados e actualizados a partir dos ficheiros que se encontram na pasta do projecto. A classe Historico é portanto responsável por carregar todas as voltas, que por sua vez carregam todas as suas respectivas etapas. Relativamente aos ficheiros existem os ficheiros equipasx.txt e etapasx.txt, em que X deverá ter o ano dessa volta. Estes ficheiros possuem uma organização própria e necessitam de ter este nome para serem reconhecidos pelo programa. Caso não exista pelo menos um ficheiro de etapas e um de equipas o programa lançará uma excepção e não poderá ser iniciado. Note-se que apesar disso o utilizador nada tem que fazer nos ficheiros, visto que a gestão destes será da inteira responsabilidade do programa. No entanto, pensou-se que não faria sentido o programa iniciar sem ter como base estes ficheiros, que permitem o carregamento e a actualização dos dados. Existem ainda os ficheiros Visitantes.txt, Administrativo.txt, Coordenadores.txt. No caso dos Visitantes, possui o número de visitantes total ao programa, assim como a última visita. No caso dos restantes ficheiros, possuem as passwords dos utilizadores e também os dados da última visita desse utilizador. São estas classes que também são responsáveis por todos os menus existentes na interface gráfica do programa, fazendo também todas as validações no decorrer no mesmo. Em todos os menus, são previstas todas as opções possíveis, e as que não se enquadra no panorama possível de opções, serão rejeitadas e aparecerá uma mensagem de erro para o utilizador voltar a inserir uma opção correcta. O grupo teve o cuidado de efectuar uma interface robusta, de maneira que o programa nunca bloquear aceitando por exemplo letras quando são pedidos números. Foi ainda elaborada outra classe denominada hashhistorico, que contém uma hash_set de objectos do tipo CiclistaHistorico. Um CiclistaHistorico conterá o nome de um ciclista e um vector de objectos do tipo Premium. Um objecto Premium representará um prémio de um ciclista, ou seja, terá um ano de realização, a equipa a que esse ciclista pertence nesse ano, assim como a modalidade que esse ciclista foi vencedor. Assim, permite-se adicionar, remover e visualizar todos os prémios que um determinado ciclista venceu. É possível carregar a partir de um ficheiro uma determinada modalidade, estando onze ficheiros disponíveis para o efeito. Ao actualizar os dados no ficheiro, o programa irá actualizar todos os ficheiros, colocando o prémio no respectivo ficheiro de acordo com a modalidade. Os ficheiros terão o seguinte formato historicoamadores.txt mas o utilizador não tem que se preocupar com a organização interna dos ficheiros, esta será da inteira responsabilidade do programa. 11
Relativamente às estruturas de dados usadas, foram várias de acordo com a situação pretendida. No caso da pesquisa de eventos a estrutura que achamos mais adequada foi a BST visto que tem como ordem de complexidade, para a execução da pesquisa de elementos pode ser realizada em O(log n). Usamos uma classe BST já definida, leccionado nas aulas da disciplina. No caso do histórico, o ideal é usar uma hash_set visto que pretende-se obter rapidamente os prémios de um utilizador. As tabelas de dispersão asseguram tempo médio constante para inserção, remoção e pesquisa. Isto é possível através de uma função de codificação que definimos, que é usada pela classe. Nas restantes situações foi usada a classe vector. Apesar de haver estruturas mais eficazes, pensamos não ser objectivo do trabalho alterar tudo o que já estava realizado numa primeira fase, para uma estrutura mais eficiente. Assim, o grupo resolveu manter a estrutura vector predominante no trabalho. Como algoritmo de ordenação foi usado o algoritmo InsertionSort, apesar de não ser dos algoritmos mais eficientes, pensamos que não teria grande impacto a alteração para o algoritmo mais eficiente, visto a quantidade pequena esperada nos dados do programa. 12
Ilustração 2 Modelo de classes UML 13
4. Implementação Existem vários algoritmos que foram aplicados ao longo da realização do projecto, é difícil escolher alguns mais relevantes para incluir neste relatório. Relativamente á fase de testes do programa, desde o ínicio da elaboração deste que se procederam a sucessivos testes. Tentando adivinhar possíveis erros e falhas do programa e dos algoritmos implementados, muitos testes foram feitos. Para a realização destes testes, foram introduzidas três etapas com prémios-montanha e metas-volante, cinco equipas, cada equipa com cinco ciclistas. A partir destes dados inseriu-se chegadas aos checkpoints, analisando a classificação tanto das etapas, como a classificação geral. De seguida apresentam-se esses testes efectuados e os resultados obtidos. Ilustração 3 Menu de inserção de chegadas a etapas A partir de dados inseridos como demonstrado na Ilustração 3, obteve-se a classificação geral demonstrado pela Ilustração 4. Devido às inúmeras classificações existentes na Volta a Portugal, é impossível demonstrar todos os testes efectuados. 14
Ilustração 4 Menu de classificação geral individual por tempos Para testar a pesquisa de eventos, usamos os dados já inseridos e testamos várias pesquisas, com vários tempos, e conferimos se todos os resultados das pesquisas estavam coerentes. Apresentamos de seguida um desses testes. Ilustração 5 Menu de pesquisa de eventos 15
5. Conclusão Relativamente às funcionalidades não implementadas, consideramos que não existem. Visto que consideramos que todos as funcionalidades e objectivos propostos no enunciado foram cumpridos, tanto relativo á primeira parte do trabalho, como á segunda parte. No entanto, seria possível implementar outras funcionalidades com mais tempo para a elaboração do programa. Uma das funcionalidades que pensamos em implementar seria a codificação da password nos ficheiros, de maneira que não existisse maneira de alguém descobrir a password de um determinado utilizador, ao pesquisar os ficheiros. Outras das funcionalidades que poderiam ter sido implementadas seria por exemplo permitir a elaboração de gráficos sobre a performance de um determinado ciclista, ou equipa. Analisando os dados de todas as provas de anos passados, poder-se-ia fazer o tratamento estatístico, e elaborar automaticamente um relatório acerca das probabilidades de cada equipa ou ciclista ganhar efectivamente uma determinada classificação. Poder-se-ia também ter implementado uma espécie de jogo/simulação, que permitisse gerar automaticamente as chegadas aos checkpoints de acordo com as características de cada ciclista e também dos dados estatísticos acima referidos. Possivelmente poder-se-á mesmo implementar as funcionalidades acima referidas após a conclusão da disciplina. Relativamente ao desempenho do grupo, todos os elementos do grupo contribuíram positivamente para o desenvolvimento do trabalho. Através de um bom trabalho de equipa, aproveitando os conhecimentos individuais de cada elemento do grupo, conseguiu-se alcançar os objectivos propostos inicialmente para este trabalho. 16
6. Bibliografia The C++ Programming Language, 3rd Edition / Stroustrup Addison-Wesley C++ Primer, 3rd Edition / Lippman and Lajoie Addison-Wesley http://www.cplusplus.com/doc/tutorial http://www.sgi.com/tech/stl 17