Trabalho Prático de Programação II

Organização e calendário

• O trabalho deverá ser começado a realizar imediatamente após entrega do enunciado.
• O trabalho será feito em duas fases, de acordo com o indicado nas próximas secções.
• No final da primeira fase será entregue um relatorio sobre o trabalho já desenvolvido, com uma página A4 no máximo, bem como as listagens do programa.
• No final da segunda parte será entregue o relatorio final, com quatro páginas A4 no máximo, bem como uma disquete (que será depois devolvida) com o programa e também as respectivas listagens.
• O relatorio consistirá numa breve explicação do funcionamento (interno) do programa e justificações para as opções tomadas. A interface com o utilizador deverá ser suficientemente simples e intuitiva para não ser necessária qualquer explicação a esse respeito no relatorio.
• O código deverá ser devidamente organizado e comentado:
  1. O programa deverá ser dividido em módulos de acordo com critérios lógicos e funcionais.
  2. Cada módulo deverá possuir o seguinte cabeçalho:

     /* 
      * Modulo: lista.c (ou lista.h) 
      * 
      * Descrição: Este modulo contem funções para 
      * processamento de listas de objectos genéricos. 
      * 
      * Notas: 
      * 
      * Autores: 
      *     Nome e número dos autores, ISCTE. 
      */
     

  3. Cada função deverá possuir o seguinte cabeçalho (E e S significam entrada e saída respectivamente):

     /* 
      * Função: Linsere()
      * 
      * Acção: Insere um elemento numa lista. 
      * 
      * Parametros: 
      *     lista (E/S) - ponteiro para a lista. 
      *     elemento (E) - ponteiro (generico) para o elemento a 
      *                    inserir. 
      * 
      * Devolve: o ponteiro para lista ou zero (NULL) se ocorrer 
      * algum erro. 
      */
     

  4. Devem ser comentadas todas as zonas do programa de mais dificil compreensão. Podem ser utilizados os seguintes estilos de comentário:

     /* Comentario de uma linha... */ 
     /* 
      * Ou de varias linhas, acerca de um conjunto de 
      * instruções: 
      */ 
     int i; 
     double x; 
     i = 10; /* inicialização de i */
     

  5. Devem ser evitadas tanto quanto possível as variáveis globais.

Objectivos

O objectivo do trabalho é a realização de um programa de gestão dos parques de estacionamento duma universidade:

Note que o enunciado refere-se a uma versão muito simplificada dum problema real. Há muitos casos que não foram considerados: por exemplo, não se prevê o acesso aos parques de visitantes ou de cargas e descargas, e agruparam-se os docentes e os funcionários da universidade numa única categoria de utente.

Descrição do problema

• Existem dois parques de estacionamento na universidade:
  • parque A - 11 lugares
  • parque B - 7 lugares

  com lugares numerados (e.g. A1, B13). Admite-se que os lugares mais apetecidos são os de numeração mais baixa em cada parque.

• Existem cancelas à entrada e à saída da universidade.
• Para entrar ou sair é necessário inserir um cartão (contendo o código do utilizador) no respectivo controlador de cancela. O controlador de entrada responde com "avance" (emitindo um talão com o número do lugar atribuído, que seria colocado no "tablier" do automóvel) ou "sem acesso" seguido de uma pequena explicação do motivo (código inválido, parque lotado, insuficiente prioridade, etc.).
• Há três categorias de utentes do parque:
  1. Direcção
  2. Professores (funcionários incluídos)
  3. Alunos

  cada uma delas com diferentes privilégios de estacionamento.

• Há três tipos de acesso aos parques:
  1. Lugar cativo - quando um utente tem sempre reservado para si um determinado local de estacionamento.
  2. Normal nível 1
  3. Normal nível 2

  Os utentes com acesso cativo têm sempre lugar. Os utentes de cada um dos níveis 1, 2 têm acesso nas seguintes circunstâncias:

  • Se a percentagem de lugares ocupados, calculada com base no total de lugares de estacionamento exceptuando os cativos, for inferior a 50%, então ambos os níveis tem acesso.
  • Se a percentagem de lugares ocupados for superior ou igual a 50%, então só o nível 1 tem acesso.

  Como é evidente, quando a lotação esgota ninguém entra (excepto os que têm lugar cativo, bem entendido). Note que o limiar de 50% deve poder ser alterado ao longo do programa (o que permite, por exemplo, usar um limiar de 100% para aumentar a "democracia" nos acessos...).

• A seguinte tabela apresenta os privilégios de acesso correspondentes a cada categoria de utente:

  	direcção	professores	alunos
  lugar cativo	X
  normal nível 1	X	X
  normal nível 2		X	X

• Os códigos de utente devem consistir em valores unsigned long e devem ser atribuídos sequencialmente a partir de zero. Os códigos de utentes que foram eliminados da base de dados não podem ser reutilizados.
• Todos os casos não cobertos neste enunciado deverão ser resolvidos com bom senso.

Funcionalidades requeridas

O programa a realizar deverá incluir o seguinte conjunto de funcionalidades mínimas:

• A identificação dos utentes constante nas bases de dados deve conter, pelo menos:
  1. Código
  2. Nome
  3. Categoria
  4. Tipo de acesso
• Devem existir dois modos fundamentais de funcionamento:

  modo administrativo

  serve para alterar a configuração do sistema (por exemplo, alteração do limiar de acesso, introdução e eliminação de utentes, etc.).

  modo portão

  simula a entrada e saída de utentes.

• Funcionalidades em modo administrativo:
  1. Alteração do limiar de acesso.
  2. Introdução, eliminação, e alteração dos dados dos utentes.
  3. Visualização do estado do parque (e.g. percentagem de ocupação, etc.).
  4. Listagem de utentes.
• Funcionalidades em modo portão:
  1. Devem ser possíveis duas operações: tentativa entrada, e saída.
  2. Durante uma tentativa de entrada será fornecido pelo utilizador do programa o código (ou o nome) do utente que pretende entrar. O programa deverá responder com "avance para o lugar X" ou, "sem acesso", fornecendo uma pequena explicação das razões da recusa. Cada utente pode estacionar apenas um veículo de cada vez.
  3. Numa saída, será fornecido o código do utente e será aberta a cancela (em sentido figurado, bem entendido), se esse utente constar das bases de dados como correntemente estacionado.
• Ao terminar, o programa deve guardar em ficheiro toda a informação relevante para a próxima execução (e.g., lista dos utentes, informação acerca do estado dos parques, próximo código a utilizar no registo de novos utentes, limiar de acesso, etc.). Os ficheiros utilizados podem ser binários ou de texto, se bem que a utilização de ficheiros de texto pode, por vezes, simplificar a fase de depuração de erros do programa.
• Ao ser executado, o programa deverá procurar os ficheiros referidos no ponto anterior e, se existirem, lê-los. Caso não existam, deverá inicializar-se com as bases de dados vazias admitindo que não existem quaisquer utentes e que os parques se encontram vazios.
• Deve-se ter em conta que as alterações administrativas podem causar problemas durante a operação do parque. Por exemplo, como eliminar um utente se ele ainda estiver estacionado? Serão valorizadas as soluções mais inteligentes...

Organização do programa

O programa deverá ser dividido em pelo menos três módulos, relativos, por exemplo, a:

• Gestão de listas genéricas.
• Gestão dos lugares dos parques.
• Módulo principal.

Fases do trabalho

No final da primeira fase do trabalho (a entregar até dia 30 de Abril de 1996) deve estar concluído o módulo de gestão de listas genéricas. Note que, no seu maior interesse, este módulo deve ser testado de forma independente, com um pequeno programa, eventualmente sem relação directa com este enunciado.

O trabalho completo será entregue obrigatoriamente até ao dia 5 de Junho (durante o horário de dúvidas do Eng. Manuel Sequeira).

Página concebida e mantida por Eng. Manuel Menezes de Sequeira (última actualização 2006/07/07) Copyright © 1996-2001 ISCTE