REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2007 / 2008

Documentos relacionados
REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2004 / 2005

REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2003 / 2004

REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2008 / 2009

REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2011 / 2012

Servidor Bingo. : A interface utilizada por clientes para realizarem as apostas e para sinalizarem um

Como começar a Jogar? Para iniciar o jogo a forma mais fácil é ir a e começar a jogar.

PROGRAMAÇÃO DE MICROPROCESSADORES 2007 / 2008

REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2005 / 2006

REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2006 / 2007

PROGRAMAÇÃO DE MICROPROCESSADORES 2007 / 2008

APLICAÇÃO GOIVV. A sua ligação à IVV- Automação, Lda MANUAL DE UTILIZAÇÃO

REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2016 / 2017

Principais correcções efectuadas

SME Introdução à Programação de Computadores Primeiro semestre de Trabalho: jogo Semáforo

PROGRAMAÇÃO DE MICROPROCESSADORES 2011 / 2012

Universidade Federal do ABC BCM Processamento da Informação Prática Projeto Campo Minado Primeiro Quadrimestre de 2018

Fundamentos da Programação. Ano lectivo , 2 o Semestre Projecto Primeira Parte 1. Nim

MAC 115 Introdução à Ciência da Computação ROTHELO

Sage 50. Procedimentos para efectuar a Passagem de Ano.

Manual do utilizador do representado da Bomgar

REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2017 / 2018

REDES INTEGRADAS DE TELECOMUNICAÇÕES I 2018 / 2019

Projecto # 4: HangMan

Exercícios de Excel com Programação em VBA. Luís Vieira Lobo

Laboratório de Informática Avançada Automatização de Horários Manual do Aluno

Sistemas de Telecomunicações 2012/2013

Tabela de Conteúdo. Pág. 2

Centro de Competência Entre Mar e Serra

Instituto Superior de Engenharia de Lisboa

Computação e Programação

Inteligência Artificial Projecto 1

Introdução à Programação C

Formas de Pagamento Resumida Vendas Vendedor Vendas Vendedor Resumido Vendas Vendedor Caixa Vendas por Artigos...

Engenharia de Software

O Manual do Skanlite. Kåre Särs Anne-Marie Mahfouf Tradução: José Pires

Sistema de Controlo com Acesso Remoto

Laboratório de Informática Avançada Automatização de Horários Manual do Professor

Manual do Gestor da Turma

Grupo I [5,5v] Considere o seguinte código que ilustra uma componente programática de um sistema de RPC, neste caso do SUN-RPC.

GIAE VERSÃO SETEMBRO DE 2011

Tutorial: Criar um servidor SFTP no Windows para acesso remoto

Departamento de Informática

Manual do aluno Novembro de 2007

Common Object Request Broker Architecture

Manual de Configuração de Ligação à Internet por placas 3G

REDES AD HOC E DE SENSORES 2011 / 2012

Algoritmia e Programação APROG. Tecnologia JAVA. IDE Netbeans. Nelson Freire (ISEP DEI-APROG 2012/13) 1/31

UTILIZAÇÃO DE 1.º CHEQUE-DENTISTA


Manual de Utilizador. Documento de Apoio. (Versão Janeiro 2019)

PROGRAMAÇÃO DE MICROPROCESSADORES 2007 / 2008

Mestrado em Engenharia Física Tecnológica

Aplicação SICAJ. Após efectuar a autenticação é apresentado o ecrã principal da aplicação. Neste ecrã estão disponíveis duas funcionalidades:

PROGRAMAÇÃO DE MICROPROCESSADORES 2007 / 2008

Diagramas. Abordaremos agora cada um destes tipos de diagrama: 1. Diagrama Use-Case. 2. Diagrama de Colaboração. 3. Diagrama de Sequência

Biblioteca do Conhecimento Online b-on

Principais correções efectuadas:

INSTRUÇÃO BODIVA Nº 1/16 MANUAL DE UTILIZADOR SIMER (TWS) NEGOCIAÇÃO

ERP PRIMAVERA STARTER V9.15

Num sistema de objectos distribuídos, dois conceitos são fundamentais.

Manual do KsirK. Gael Kleag de Chalendar Tradução: José Pires

Partilha de ficheiros por rede entre Mac e Windows

O Manual do Desktop Sharing. Brad Hards Tradução: Pedro Morais

Programação 2. Trabalho Prático P4A. Efectue as tarefas de programação descritas abaixo, usando a linguagem C++ em ambiente Linux.

Manual de Instalação PRIMAVERA QPOINT

TimeNET. REPORTU Digital-Time. Manual de Utilizador do Software. Gestão de Assiduidade e Controlo de Acessos Página 1 de 35

PCAAC - Programa Comunitário de Apoio Alimentar a Carenciados Manual do Utilizador - Web

Sistema Revolucionário de Gestão de Ficheiros

A figura abaixo representa uma classe denominada Carteira. Esta classe é composta dos métodos depositar(valor) e retirar(valor) e do atributo saldo.

[ Arquitecturas Móveis ] 2017/2018

21090 Programação e-fólio A 2015/2016. E-fólio A. O e-fólio A é baseado no jogo do dominó (

Projecto de Algoritmos e Estruturas de Dados

Teclado. Mike McBride Anne-Marie Mahfouf Tradução: José Pires

Integração por Web Services

Fundo Florestal Permanente (FFP) Manual de Utilizador Externo Registo de Beneficiário no FFP

(Sistema Especialista)

BikeFantasy Regulamento. Última atualização: 2 de Fevereiro de 2018 Versão do regulamento: 5.0.0

Redes de Computadores

O Manual do KFourInLine. Martin Heni Eugene Trounev Benjamin Meyer Johann Ollivier Lapeyre Anton Brondz Tradução: José Pires

Manual de Utilizador

Metodologia Simplified. António Rocha

Instituto Federal de Minas Gerais - Campus Bambuí

Apresentação. Informação geral + Conceitos iniciais

Administrador de condomínio Art. 1456B Vdc. Art 1456B PT MANUAL TÉCNICO A2 A3 A4

Bomgar Connect Apoio Técnico a Dispositivos Apple ios

Manual do Utilizador. Portal do contribuinte Versão 1.0

GRADUAÇÃO EM ANÁLISE E DESENVOLVIMENTO PROGRAMAÇÃO DE COMPUTADORES I Trabalho Final Anual TFA

Implementação do Web SIG para o PGRH

Um sistema de difusão de informação a nível da aplicação

ZS Rest. Manual Profissional. BackOffice Mapa de Mesas. v2011

Diagramas de Use Case

ZS Rest. Manual Avançado. Funcionamento com cartões Sistema Pré-Pago. v2011

Guia de actualização

Gestão de Projectos de Software

CORBA IDL. Interface Definition Language. Mário Meireles Teixeira.

Rui Carneiro, Rui Pereira, Tiago Orfão

INSTALAÇÃO E CONFIGURAÇÃO

Melhor caminho entre duas estações de metro

Transcrição:

Departamento de Engenharia Electrotécnica REDES INTEGRADAS DE TELECOMUNICAÇÕES II 2007 / 2008 Mestrado Integrado em Engenharia Electrotécnica e de Computadores 4º ano 8º semestre 2º Trabalho prático: Jogo de dominó distribuído utilizando o serviço de nomes e de trading da arquitectura CORBA http://tele1.dee.fct.unl.pt Luis Bernardo

1. OBJECTIVOS Criação de uma aplicação distribuída, que usa a invocação remota de objectos e os serviços de nomes e de trading da arquitectura CORBA. O problema consiste na realização de um jogo de dominó distribuído. A aplicação permite a cada jogador jogar uma partida de dominó em rede. A agência Dominó é responsável por arrancar o jogo, e por coordenar a distribuição das peças, a ordem de jogo e a validade das jogadas. Cada agência recebe o registo dos clientes locais, mas coordena-se com outras agências para redistribuir os jogadores, criando jogos com jogadores oriundos de várias agências. Para tornar o jogo mais interessante, cada utilizador realiza uma aposta antes de começar a jogar. Como no jogo do dominó convencional, ganha o primeiro jogador que ficar sem peças. Cliente Dominó Cliente Dominó Agência Dominó Trader A aplicação é composta por dois tipos de programas: um programa para os clientes poderem realizar as apostas (Cliente Dominó); um programa servidor de dominó (Agência Dominó). São fornecidas implementações de código aberto do cliente e acesso a uma implementação da agência Dominó nos computadores do laboratório 3.3-X. Pretende-se que seja desenvolvida pelos alunos uma agência Dominó. 2. Especificações 2.1 Interfaces O conjunto de interfaces do jogo Dominó está declarado no ficheiro DominoIf.idl no módulo DominoIf. Este módulo inclui a definição das interfaces e de tipos de dados auxiliares usados nas funções das interfaces. Foram definidos quatro tipos de interfaces para interligar os dois tipos de programas: Cli_Login : A interface utilizada para realizar o registo de clientes na agência Domino, que é registada no serviço de nomes; Cli_Jogo : A interface utilizada por clientes para realizarem as jogadas, e sinalizar mudanças de estado; Cli_Callback : A interface utilizada pela agência para sinalizar as jogadas, e testar a actividade dos clientes; 1

Cli_Transfer : A interface utilizada para realizar a transferência de jogadores entre agências, que é registada no serviço de trading. O módulo inclui vários tipos de dados adicionais, usados nas funções das interfaces: typedef double Euros; // Unidade monetária typedef octet Numero; // Numero entre 0 e 7; 7==ausente // Definição das peças de dominó struct Peca { Numero a; Numero b; // A peça (a=7,b=7) significa peça ausente // Definicao do conjunto de pecas enviado no inicio do jogo // para cada jogador typedef Peca PecaInicial[3]; O tipo Peca define uma peça de dominó, ou o estado do jogo dominó (os valores das duas extremidades do jogo). Quando o jogo arranca, cada jogador recebe três peças iniciais, podendo pedir mais durante o jogo. A peça (7,7) tem o significado especial de peça ausente. As peças normais estão compreendidas entre (0,0) e (6,6). Relembra-se que como os tipos de dados estão declarados dentro do módulo DominoIf são referenciados no software a desenvolver como DominoIf.Peca, por exemplo. 2.1.1 Interface Cli_Login A interface Cli_Login define uma operação: // Interface cliente-agência (Login clientes) interface Cli_Login { boolean Join_game(in string nome, in Euros valor_aposta, in Cli_Callback callback, out Cli_Jogo jogo, out string razao); Esta interface é usada nos clientes para se ligarem a um jogo numa agência. A operação Join_game recebe como argumentos o nome do apostador (nome), o valor da aposta (valor_aposta), e uma referência para o objecto de callback do cliente (callback). A agência cria um objecto local do tipo Cli_Jogo, sinalizando posteriormente o início do jogo, ou a transferência para outra agência, através da interface Cli_Callback. A função retorna uma referência para o jogo criado (jogo), que poderá ser null em caso de erro. O campo razao permite à agência devolver uma descrição textual ao cliente sobre o que aconteceu durante a operação, e deve ser sempre preenchido com uma string válida. 2.1.2 Interface Cli_Jogo A interface Cli_Jogo define três operações: // Interface client-server (Jogo clientes) interface Cli_Jogo { boolean Joga(in Peca nova, in boolean at_a_side); boolean Get_peca_nova(out Peca peca); oneway void GiveUp(); // Desiste Esta interface é usada nos clientes para dar comandos para as agências. A função GiveUp é usada para sair de um jogo ou cancelar um registo de aposta. Caso se saia antes do arranque do 2

jogo, o jogador deve receber o dinheiro apostado, senão deve perder o dinheiro. A função Joga é usada para colocar uma peça no dominó na posição A (se at_a_side == true) ou na posição B (se at_a_side == true) do estado do jogo. O jogador passa a vez jogando uma peca inválida (7 7), uma vez que não é possível passar objectos a null em CORBA. A agência deve validar a jogada, retornando false caso ela não seja válida, ou não seja a vez do jogador. A função Get_peca_nova é usada para pedir mais uma peça, podendo retornar false caso já não haja mais peças ou não seja a vez do jogador. Dentro do tempo de jogo (10 segundos), o jogador pode pedir quantas peças quiser, mas só pode jogar uma peça. 2.1.3 Interface Cli_Callback A interface Cli_Callback define seis operações: // Interface server-client (Callback client) interface Cli_Callback { boolean InicioJogo(in PecaInicial pecas, in Cli_Jogo jogo); void update_ref(in Cli_Jogo jogo); // Actualiza referência boolean Jogo(in Peca state, in boolean vez); boolean FimJogo(in Euros premio); void Timeout(); // Perdeu a vez - demasiado tempo sem jogar oneway void update_state(in short jogadores, in Euros valor); Esta interface é usada nos clientes para receber informação das agências. A operação InicioJogo permite à agência sinalizar o início de um jogo, fornecendo o conjunto inicial de peças ao cliente e a interface de Cli_Jogo associada ao jogador. Esta interface também pode ser actualizada em qualquer altura utilizando-se a operação update_ref. A operação Jogo é invocada durante o jogo, cada vez que o estado do jogo muda, indicando quais são os números nas extremidades do bloco (state), e se é a vez do jogador jogar (vez). Para passar a indicação que se está no início do jogo, sem estado, é usado o estado (7 7). A operação FimJogo sinaliza o fim de um jogo, indicando o valor do prémio ganho. A operação Timeout é invocada pela agência para sinalizar que terminou o tempo para jogar (10 segundos), e que o jogo passou a outro jogador. A operação update_state é invocada enquanto o jogo não começa para informar os jogadores da agência sobre o número de participantes e o valor do prémio de jogo. Esta operação é do tipo oneway, não sendo garantida a sua entrega. 2.1.4 Interface Cli_Transfer A interface Cli_Transfer define uma operação: // Interface server-server (Transferência de clientes) interface Cli_Transfer { boolean transfer_player(in Cli_Jogo new_jogo, out string nome, out Cli_Callback callback, out Euros bet, out string razao); Esta interface é usada entre agências para pedir a transferência do jogador que fez uma aposta mais ainda não está associado a um jogo, que fez a maior aposta. A operação recebe como argumento de entrada a nova referência para o objecto Cli_Jogo que vai ficar associada ao cliente (new_jogo), e retorna os dados do cliente transferido, incluindo: o nome (nome), a referência para o objecto de callback (callback), o valor da aposta (bet). A operação retorna true caso seja aceite a transferência de um jogador, ou false em caso contrário (por exemplo, se entre a consulta ao trader e o pedido de transferência deixou de haver jogadores livres). O 3

campo razao permite à agência devolver uma descrição textual ao cliente sobre o que aconteceu durante a operação, e deve ser sempre preenchido com uma string válida. 2.2 Agência de dominó Deve desenvolver uma Agência de Dominó capaz de suportar vários jogos em paralelo. A agência de dominó é a aplicação responsável por manter toda a informação referente aos jogos activos, e aos clientes que realizam uma aposta e aguardam o início do jogo. Quando a agência arranca, oferece uma interface Cli_Login, de maneira a permitir que clientes se liguem à agência (através de uma aplicação cliente). A interface DominoIf.Cli_Login deve ser registada no servidor de nomes com um nome único no sistema (e.g. demo01), de forma a permitir a coexistência de várias agências em simultâneo. Os clientes usam o nome da agência para realizar a associação inicial. Cada agência deverá também registar a interface Cli_Transfer no serviço de trading, permitindo a partilha dos jogadores à espera de iniciarem o jogo entre as várias agências. Para se iniciar um jogo é necessário haver pelo menos um número mínimo de dois jogadores, embora o administrador da agência possa definir um número diferente de jogadores por jogo. O administrador define também um tempo máximo de espera até ao início do jogo, altura onde o jogo deve começar desde que existam pelo menos dois jogadores à espera nas agências disponíveis na rede. 2.2.1 Registo dos jogos no trader A interface Cli_Transfer deve ser registada com o serviço DominoService, definido no ficheiro DominoIf.st: #include "DominoIf.idl" module DominoIf { service DominoService { interface Cli_Transfer; mandatory property string server_name; mandatory property short number_players; mandatory property Euros highest_bet; Os registos incluem uma propriedade estática (server_name o nome da agência que arrancou o jogo) e duas propriedades dinâmicas, que devem retornar em cada instante o número de jogadores na agência à espera de iniciarem um jogo (number_players) e a maior aposta registada na agência por um jogador que ainda não começou a jogar (highest_bet). Quando um jogador inicia o jogo, deixa de ser contabilizado nas duas propriedades indicadas. 2.2.2 Associação de clientes a um jogo Sempre que a agência recebe um novo Join_game de um cliente, a agência deve activar um relógio com o tempo máximo que o administrador do sistema definiu para a espera (obtido com a função getplaytime) de um jogo. O jogo começa quando o número de jogadores locais à espera atingir o valor limite definido pelo administrador do sistema (obtido com a função getplayn), ou após o tempo máximo de espera, desde que existam pelo menos dois jogadores à espera. Quando expira o tempo de espera, a agência deve usar o serviço de trading para procurar 4

e transferir jogadores de outras agências, tentando atingir o número pedido pelo administrador. Os clientes podem sair da agência em qualquer altura. Caso um cliente abandone uma agência antes do jogo começar, a agência deve devolver o valor aposta. Caso contrário, o cliente perde o valor da aposta, que reverte para o vencedor do jogo. No fim do jogo, a agência sinaliza o fim de jogo com o método Cli_Callback.FimJogo indicando o prémio ganho por cada jogador. Os clientes que devem repetir os todos os procedimentos de ligação para jogar um novo jogo. 2.2.3 Jogo do dominó Durante o arranque de um novo jogo, a agência deve ordenar aleatoriamente todas as peças de dominó, controlando a sua distribuição inicial, e durante o jogo através da operação Get_peca_nova. Cada jogo deve ser encapsulado num objecto que mantém um estado do jogo (quais são os números das duas extremidades do jogo, quem é o próximo a jogar, etc.). Os jogadores são avisados através da operação Jogo que chegou a sua vez de jogar, tendo até 10 segundos para jogar uma peça, passar, ou pedir peças. Caso um jogador deixe passar 5 vezes sem jogar, o jogador deve ser excluído do jogo pela agência. O jogo termina quando o número de jogadores desce até um, ou caso um jogador fique sem peças. O jogo fica empatado caso ao fim de duas séries de rodadas a todos os jogadores ninguém consiga jogar nenhuma peça. A agência deve validar a invocação das operações sobre a interface Cli_jogo, verificando se a operação é válida para a fase da sessão da agência. 2.2.4 Desenvolvimento da agência Dominó Deve desenvolver uma Agência de Dominó, partindo da interface gráfica representada à direita. O botão Activar é usado para arrancar e registar os objectos Cli_Login e Cli_Transfer nos serviços de nomes e de trading, associados respectivamente aos endereços IP e portos representados em NS e TS. Os objectos são registados com o nome representado em Nome. A agência de dominó apresenta a informação referente aos apostadores registados localmente através da tabela indexada pelo nome do utilizador (Nome), onde consta o valor da aposta (Aposta), o nome do jogo (Jogo), e o estado do jogo (Estado). Caso um jogador não esteja associado a um jogo, é apresentado o número de jogo -1. No caso representado na figura está um jogo a decorrer (o 1 ) com os jogadores user_00 e user_01, e está o jogador user_02 à espera de iniciar o seu jogo. O estado indica o valor das peças nas extremidades do jogo e quem está a jogar. Os campos de texto N e Time definem o número ideal de jogadores para arrancar um jogo e o tempo máximo de espera por jogadores. O botão Iniciar tem o mesmo efeito que o expirar do relógio associado ao jogador seleccionado na tabela abaixo arranca com o jogo se já houver pelo menos dois jogadores disponíveis. O botão Abortar termina o jogo que estiver seleccionado. Finalmente, o botão Limpar limpa o conteúdo da caixa de texto no fim da janela, onde se ecoam mensagens para o administrador da agência. É fornecido um projecto NetBeans com a interface gráfica mais um conjunto de classes de suporte apresentadas abaixo. 5

2.3 Cliente de dominó O cliente de dominó começa por obter as referências para a Agência e para o serviço de nomes (usando os dados do campo NameServer), quando se selecciona o botão Active. Quando se selecciona o botão Jogar, pesquisa no serviço de nomes a agência com o nome Agência e liga-se a ela com a operação Join_game. Os parâmetros passados nesta operação são obtidos das caixas Nome (nome de utilizador) e Aposta (valor apostado). A aplicação cliente controla o saldo do jogador em Saldo, verificando se a aposta é inferior ao saldo. A partir do momento em que está ligado, o cliente recebe informações sobre o número de participantes e sobre o prémio de jogo. A partir do momento em que a agência inicia o jogo, o cliente monitoriza o estado das sessões, apresentando o estado do jogo ao utilizador (Peças do jogo) com a indicação de quando é a sua vez (estado a verde ou vermelho), e na caixa Estado do Jogo. O utilizador pode seleccionar qualquer uma das peças disponíveis para jogar (representadas no canto superior direito) ou passar (jogar sem seleccionar nenhuma peça, enviando (7 7) para a agência), com o botão Escolher, ou pedir novas peças com o botão Pedir, apenas durante a sua vez. O botão Reiniciar reinicia o cliente no estado inicial, com um saldo de 100. Para sair deve usar-se o botão Active. Finalmente, o botão Limpar limpa o conteúdo da caixa de texto no fim da janela. É fornecido um cliente totalmente realizado com o código aberto. 3. MÓDULOS FORNECIDOS Para facilitar o desenvolvimento da agência, são fornecidos: o código fonte do cliente e acesso a um executável da agência Bingo; os ficheiros DominoIf.idl e DominoIf.st com a definição das interfaces e do serviço; o ficheiro corba_thread.java para correr a tarefa CORBA em paralelo com o processamento dos eventos gráficos; o ficheiro NS_Client.java para facilitar o acesso ao serviço de nomes; os ficheiros de definição da interface gráfica da agência, com o código inicial da agência em Agencia.java. O trabalho deve ser desenvolvido utilizando o JDK1.4.2. Embora pareça que corre com Java 5 ou Java 6, a plataforma OpenORB não funciona correctamente nestas versões de Java. Não se esqueça de arrancar os Servidores de Nomes e de Trading antes de correr os executáveis da aplicação. 3.1 Desenvolvimento do trabalho O trabalho vai ser desenvolvido em cinco semanas, onde a primeira semana é principalmente uma aula de introdução à programação de aplicações CORBA com OpenORB em Java. Propõe-se que sejam definidas as seguintes metas para a realização do trabalho: 1. na primeira aula (de aprendizagem) deve realizar os exercícios propostos na Introdução ao desenvolvimento de aplicações CORBA em Java. Também deve preparar o projecto para desenvolver a agência; 6

2. no fim da segunda aula deve ter realizado o registo e cancelamento do objecto Cli_Login no serviço de nomes, e começado a realizar a operação Join_game, com a definição de classes que realizam as interfaces Cli_Login e Cli_Jogo; 3. no fim da terceira aula deve ter realizado a operação Join_game apenas para clientes locais, com a definição de toda as estruturas de dados de suporte. Deve também ter iniciado o desenvolvimento da tarefa de controlo do jogo (sorteio de peças, sequenciação de jogadas, temporização). Pode usar uma thread para controlar as temporizações para cada jogo; 4. no fim da quarta aula deve ter terminado a tarefa de controlo do jogo para clientes locais. Deve ter iniciado a realização do objecto Cli_Transfer que suporta a transferência de clientes, e o seu registo no serviço de Trading; 5. no fim da última aula deve ter acabado de realizar a agência, incluindo a pesquisa no serviço de trading por outros clientes à espera de jogo caso não existam clientes disponíveis na agência local em número suficiente. A aplicação deve ser testada, corrigindo-se os últimos erros de programação. 3.2 Postura dos Alunos Cada grupo deve ter em consideração o seguinte: Não perca tempo com a estética de entrada e saída de dados Programe de acordo com os princípios gerais de uma boa codificação (utilização de indentação, apresentação de comentários, uso de variáveis com nomes conformes às suas funções...) e Proceda de modo a que o trabalho a fazer fique equitativamente distribuído pelos membros do grupo. DATAS LIMITE A parte laboratorial é composta por dois trabalhos de avaliação. A duração prevista para o primeiro trabalho é de 4 semanas. O segundo trabalho tem início no dia 17 de Abril. O quadro seguinte mostra os dias das aulas de laboratório e as datas provisórias de entrega de cada trabalho de avaliação (P) e as datas previstas para os testes teóricos (T). Março 2008 Maio 2008 25 26 27 28 29 1 1 2 3 2 3 4 5 L1 7 8 7 4 5 6 7 L2 9 10 9 10 11 12 L1 14 15 8 11 12 13 14 L2 P2 17 1 16 17 18 19 20 21 22 9 18 19 20 21 22 23 24 2 P 24 25 26 L1 28 29 10 25 26 27 28 29 30 T2 Abril 2008 Junho 2008 2 30 31 1 2 L1 P1 5 10 1 3 6 7 8 9 10 11 T1 11 2 3 4 5 6 7 8 4 13 14 15 16 L2 18 19 12 9 10 11 Não há RIT2 13 14 15 5 20 21 22 23 L2 25 26 13 16 17 18 19 20 21 22 6 27 28 29 L2 extra 14 23 24 25 26 27 28 29 7