Aplicação do modelo em espiral neste projeto

5.4 Aplicação do modelo em espiral neste projeto

Inicialmente a equipe se deparou com a necessidade de oferecer versões do sistema (protótipos) para que pudessem ser depurada pelo “cliente” para que o mesmo participasse da criação do produto, inserindo sua opinião para melhoria na qualidade, preenchimento dos requisitos e estudando o funcionamento do software. Como a comunicação com o “cliente” não era possível nestes moldes, buscamos informações junto a estacionamentos que conhecemos e simulamos o refinamento dos requisitos a partir de problemas possíveis de acontecerem em estacionamentos reais e de refinamento dos requisitos levantados pelas componentes do grupo.

6. O Desenvolvimento do Sistema

6.1 Protótipo inicial e Requisitos

O protótipo inicial do sistema consistiu de uma tela de acesso, com um menu através do qual era possível acessar todas as funções do sistema. Em uma primeira instância, não havia funções implementadas, mas isto permitiu delinear uma estrutura para o sistema. Optamos por utilizar uma abordagem em que muitas funções interagissem, tentando, contudo, manter o número de variáveis globais reduzido ao mínimo. Outras prioridades foram minimizar o uso de recursos, já que o nosso “cliente simulado” dispõe de computadores mais ou menos antigos e com relativamente poucos recursos de memória. Este requisito autoimposto pelo grupo veio da observação por diferentes colegas de que a maioria dos estacionamentos conta com máquinas relativamente antigas, embora em relativamente bom estado. Foi decidido que o sistema deveria ser simples de usar, não demandando experiência significativa no uso de computadores pelos usuários finais. Também, na medida do possível, trabalhamos com a intenção de evitar falhas comuns em sistemas assim, como inserção de dados errados, pressionamentos de teclas erradas, etc. Conforme as especificações do trabalho (Manual do PIN IV, Unip, 2014), o produto foi projetado para um estacionamento encerra suas atividades à noite e não aceita veículso para pernoite. O requisitos iniciais do sistema (considerando a demanda do enunciado do projeto) podem ser assim sumarizados:

• Sistema para gerenciar o fluxo de entrada e saída de um estacionamento;
• Ao entrar no estacionamento, o automóvel tem sua placa registrada no sistema e há a geração de um comprovante, com a placa do automóvel, a data e a hora de entrada;
• No momento em que um automóvel deixa o estacionamentos, o sistema calcula o valor da estadia, sendo que a primeira hora tem valor diferenciado (mais alto) em relação às horas seguintes;
• Na saída, também é gerado um comprovante com o a placa do veículo, a hora de entrada, a hora de saída, a duração do período de estadia e o valor a ser pago;
• O sistema deve sinalizar quando o estacionamento está cheio, não aceitando a entrada de novos veículos;
• O sistema deve fazer a gestão do caixa, gerando um relatório ao final do dia com as movimentações do dia, os valores recebidos e o saldo total no fechamento.

Adicionalmente, e com base em nossas observações de estacionamentos em diferentes cidades (nosso grupo conta com componentes em quatro cidades diferentes, em três estados), nosso “cliente simulado” solicitou as seguintes funcionalidades adicionais:

• Uma tolerância de cinco minutos para um veículo entrar e sair, sem custo. Este pedido permite não apenas que o cliente desista de ficar no estacionamento, mas também evita que o registro equivocado de um veículo gere custos e estornos de valores, não contemplados pelo sistema;
• A primeira hora de estadia deve ser cobrada integralmente, após a tolerância de cinco minutos;
• Após a primeira hora, a cobrança se dá em frações de hora de quinze minutos;
• O sistema não deveria entrar em nenhum tipo de colapso (como congelamento de tela, loopings infinitos ou simplesmente fechar) diante da inserção de um caracter diferente dos esperados pelos menus;
• O sistema deveria ter algum tipo de proteção contra a inserção de placas flagrantemente incorretas, como as que não sejam compostas de três letras seguidas de quatro algarismos;
• O sistema não deveria aceitar a inserção da placa de um veículo já registrado em estadia;
• Possibilidade de consultar tanto a lista de veículos estacionados quanto o subtotal de faturamento do dia.
• O relatório elaborado ao final do dia deveria conter todas as entradas de saída de veículos com suas placas e respectivos horários, os valores recebidos e o valor total ao final do dia.

6.2 Sumário do Desenvolvimento

Tendo em vista o requisito da aplicação da linguagem C (e sem o uso de bancos de dados ou ferramentas externas) organizamos o sistema em torno de uma função principal (main function) que consiste em um laço infinito, controlado de forma a dar acessoa a todas as outras funções e com duas saídas do sistema incluídas em seu corpo.

Este protótipo inicial se manteve com poucas alterações, até o resultado final. Um protótipo mais recente incluiu a possibilidade de consultar a lista de carros estacionados, afora isso, as alterações foram estéticas e para facilitar a visualização.

A partir da função principal (e da tela principal), é chamado um menu de opções que leva às diferentes funções do sistema. Esta, em sua última versão, apresenta as seguintes opções, que foram implantadas gradualmente, a cada “passo” no processo:

• Inserção de veículo, com geração do comprovante de entrada;
• Saída de veículo, com emissão do comprovante. (Esta inclui o cálculo do tempo de permanência e o cálculo do valor da estadia)
• Consulta à lista de carros estacionados de suas horas de entrada;
• Saída do sistema com geração de um relatório do período;
• Saída do sistema, sem geração do relatório.

6.2.1 Estrutura interna e uso da linguagem C

Internamente, a placa de cada veículo e o horário de entrada são armazenados em dois vetores, a placa na forma de uma cadeia de caracteres e o horário de entrada na forma de variável “número natural long” (long int). Na impossibilidade de usar um banco de dados externos, decidimos usar vetores indexados que permitem armazenar e encontrar dados em pares ou grupos identificados entre si pelo mesmo índice.

Horário e tempo de permanência: O horário fica armazenado em um uma variável que conta os segundos deste a 01.jan.1970 às 00:00h GMT (hora do meridiano de Greenwich). O cálculo da duração da permanência (fornecido em horas e minutos) se realiza em duas etapas. O número total de minutos de permanência é calculado através da diferença entre a variável do horário de saída e a do horário de entrada, ambas divididas por 60 (divisão de inteiros, sem resto). A partir dos minutos, o número de horas é calculado a com a divisão de inteiros (sem resto) do número de minutos por 60, e os minutos em número menor que 60 são dados pelo resto da mesma divisão (MOD, ou operador %, em C). A hora atual UTC e as funções para conversão desta em dias, meses, anos e horários, são fornecidas pela biblioteca do padrão ANSI C. Foi necessário explorar estas funções para fornecer a data, hora de entrada, hora de saída e calcular as durações de permanência, bem como gerar o nome do arquivo de relatório.

...