Técnicas de Projeto e Implementação de Sistemas II Descrição do Projeto da Disciplina 1 Introdução O projeto da disciplina consiste na implementação de um sistema de busca de tarifas de passagens aéreas. A ideia é desenvolver um sistema Web capaz de realizar buscas de opções de passagens aéreas de acordo com critérios especificados pelo usuário, como trechos desejados e datas para cada trecho. O sistema deverá obter as informações sobre as opções de voo a partir da API QPX (vide https://developers.google.com/qpx-express/). Esta API pode ser acessada através de requisições HTTPS do tipo POST, utilizando o formato JSON para troca de informações (tanto requisições, quanto respostas). A API contém apenas um método (o método search), que retorna opções de viagem, dados os critérios de busca. O sistema deve ser desenvolvido sobre as ferramentas e APIs disponíveis no J2EE. O desenvolvimento será feito de maneira gradual, com versões gradativamente mais completas. Cada versão deve ser entregue nas datas especificadas, e notas individuais serão atribuídas a cada uma delas. A nota final do trabalho será dada pela soma das notas das versões individuais. Nas seções a seguir, são definidas as versões a serem entregues com seus respectivos requisitos. 2 Versão 1: Funcionalidade Básica e Interface Web A versão 1 deve ser implantada na forma de um sistema Web baseado em Servlets, JSP, JSF ou uma combinação destes. Nesta versão, os dados devem ser inseridos pelo usuário na forma de um campos de um formulário. Nesta versão, o usuário deve ser capaz de especificar uma viagem com vários trechos. Um trecho é constituído de uma cidade ou aeroporto de origem, uma cidade ou aeroporto de destino e uma data de saída (dia, mês e ano). O sistema deve permitir a especificação de viagens com até 5 trechos e os trechos não precisam ser contíguos (i.e., a cidade de saída de um trecho não precisa ser a mesma de chegada do trecho anterior e a viagem não necessariamente começa e termina na mesma cidade). As cidades/aeroportos de origem/destino dos trechos devem ser especificados pelo usuário já no código aeroportuário IATA. As datas devem ser especificadas no formato DD/MM/AAAA. Caberá ao sistema fazer as conversões necessárias para os formatos esperados pela API. O sistema deve limitar o número de respostas a 500 (limite atual da versão gratuita da API QPX). Uma vez recebida a resposta, o sistema deve apresentar todas as opções encontradas, ordenadas por preço (do menor para o maior). Os opções de viagem encontradas devem ser exibidas na forma de uma tabela. Cada linha da tabela corresponde a uma opção de viagem. Para
cada opção, a tabela deve conter o valor total, incluindo impostos, as empresas que operam os voos da envolvidos na opção, o tempo total de cada trecho da viagem e um link ou botão para que o usuário possa ver mais detalhes. Ao clicar no link ou botão, o usuário deve ser redirecionado para outra página na qual as seguintes informações de saída devem ser exibidas: Preço. Tempo total de cada trecho da viagem. Cada conexão para cada trecho requisitado (aeroportos de saída e chegada). Tempo de espera para cada conexão. Cada escala para cada conexão (aeroporto de saída e chegada). A empresa que realiza cada conexão. Os horários de cada conexão (horário de saída e chegada). O formato de exibição é livre, desde que seja textual e legível. Esta página deve ainda permitir ao usuário que volte à página anterior (resultados da pesquisa) sem que a pesquisa precise ser feita novamente. Os aeroportos e empresas devem ser apresentados com seus nomes completos, ao invés de códigos eventualmente utilizados para representá-los. Em resumo, esta versão tem os seguintes requisitos: Requisitos funcionais: 1. O sistema deve permitir que o usuário faça buscas de opções de viagens com até 5 trechos não necessariamente contíguos. RN1: as cidades/aeroportos de origem e destino de cada trecho devem ser especificados pelo usuário utilizando o código IATA. 2. O sistema deve retornar até 500 possibilidades de viagem, conforme retornado pela API. 3. O sistema deve exibir as opções de viagem de acordo com o valor total, incluindo impostos. A exibição deve ser feita no formato de uma tabela. Para cada opção de viagem, devem ser exibidos também as empresas aéreas utilizadas, o tempo total de cada trecho e um link ou botão para mais detalhes. 4. Na página de detalhes de opção de viagem, o sistema deve exibir, para cada trecho, todas as conexões e respectivos tempos de espera, todas as escalas envolvidas em cada conexão, o nome da empresa que opera cada conexão, os horários de partida e chegada de cada conexão, o tempo total de cada trecho da viagem e o valor total, incluindo impostos, da opção. Esta página deve permitir ainda que o usuário volte à página anterior, com a tabela de opções, sem que o sistema precise refazer a consulta à API. 5. A saída deve ser em formato textual e legível.
6. Os aeroportos e empresas listados na saída do sistema devem ser referenciados pelos seus nomes. 7. A entrada de dados no sistema deve ser realizada através do preenchimento de campos de um formulário contendo, para cada trecho, cidade/aeroporto de origem e destino e data de partida. 8. Se o sistema não puder realizar mais consultas à API naquele dia por ter estourado o limite diário de requisições (a API permite no máximo 50 requisições por dia), este deverá apresentar uma mensagem de erro ao usuário. Requisitos não-funcionais: 1. O sistema deve ser implementado na linguagem Java. 2. O sistema deve ser implementado de acordo com uma arquitetura de três camadas. 3. O sistema deve utilizar Servlets, JSP, JSF ou uma combinação destas tecnologias. Versão 2: Busca Avançada A versão 2 do sistema deverá adicionar à versão 1 a funcionalidade de busca avançada. A busca avançada permitirá ao usuário que tenham flexibilidade de datas especificar parâmetros da viagem e encontrar as melhores opções dentro das restrições estabelecidas. Basicamente, o usuário poderá especificar uma duração para a viagem (em dias), as cidades que deseja visitar em ordem, os tempos máximo e mínimo que deseja ficar em cada cidade, as cidades de origem e destino da viagem, e um período no qual a viagem pode ser realizada. Por exemplo, o usuário poderia especificar as seguintes opções de busca: Duração da viagem: 15 dias. Cidade de origem: Rio de Janeiro. Cidade de destino: São Paulo. Primeira cidade a visitar: Porto Alegre (no máximo 7 dias, no mínimo 3). Segunda cidade a visitar: Manaus (no máximo 6 dias, no mínimo 3). Terceira cidade a visitar: Salvador (no máximo 8 dias, no mínimo 5). Período de realização da viagem: entre 5 de janeiro de 2015 e 4 de fevereiro de 2015. O sistema deve se encarregar de verificar se as restrições são viáveis (por exemplo, se o usuário especifica uma duração de 15 dias, mas o período especificado vai só de 4 de janeiro a 8 de janeiro, as restrições são inviáveis). O sistema deve gerar todas as combinações de dias de viagem que respeitem os valores máximos e mínimos, a duração da viagem e o período e para cada um deles, deve consultar a API verificando as opções de viagem. Se o número de combinações for maior do que a quantidade de requisições que o sistema ainda pode fazer à API, deve-se limitar a busca
ao número de requisições permitido e informar ao usuário que nem todas as combinações foram exploradas. A apresentação dos resultados é idêntica a da busca básica da versão 1. O número máximo de cidades visitadas deve ser limitado em 4. As cidades/aeroportos especificados pelo usuário devem usar o código IATA. Em suma, os requisitos da versão 2 do sistema são: Requisitos funcionais: 1. O sistema deve permitir que o usuário faça buscas de opções de viagens com até 5 trechos não necessariamente contíguos. RN1: as cidades/aeroportos de origem e destino de cada trecho devem ser especificados pelo usuário utilizando o código IATA. 2. O sistema deve permitir que o usuário faça buscas avançadas, especificando como entrada a duração da viagem, as cidades ou aeroportos de origem e destino, as cidades ou aeroportos que se deseja visitar (até 4), os tempos máximos e mínimos (em dias) de estadia em cada cidade/aeroporto que se deseja visitar, e o período (data inicial e data final) em que a viagem pode ser realizada. RN1: as cidades/aeroportos de origem e destino de cada trecho devem ser especificados pelo usuário utilizando o código IATA. 3. O sistema deve retornar até 500 possibilidades de viagem, conforme retornado pela API. No caso da busca avançada, o limite é de 500 opções de viagem por combinação de datas. 4. O sistema deve exibir as opções de viagem de acordo com o valor total, incluindo impostos. A exibição deve ser feita no formato de uma tabela. Para cada opção de viagem, devem ser exibidos também as empresas aéreas utilizadas, o tempo total de cada trecho e um link ou botão para mais detalhes. 5. Na página de detalhes de opção de viagem, o sistema deve exibir, para cada trecho, todas as conexões e respectivos tempos de espera, todas as escalas envolvidas em cada conexão, o nome da empresa que opera cada conexão, os horários de partida e chegada de cada conexão, o tempo total de cada trecho da viagem e o valor total, incluindo impostos, da opção. Esta página deve permitir ainda que o usuário volte à página anterior, com a tabela de opções, sem que o sistema precise refazer a consulta à API. 6. A saída deve ser em formato textual e legível. 7. Os aeroportos e empresas listados na saída do sistema devem ser referenciados pelos seus nomes. 8. A entrada de dados no sistema deve ser realizada através do preenchimento de campos de um formulário contendo, para cada trecho, cidade/aeroporto de origem e destino e data de partida. 9. Se o sistema não puder realizar mais consultas à API naquele dia por ter estourado o limite diário de requisições (a API permite no máximo 50 requisições por dia), este deverá apresentar uma mensagem de erro ao usuário. Se o limite for alcançado durante uma busca avançada, o sistema deve retornar os resultados parciais, avisando ao usuário que nem todas as combinações foram exploradas.
Requisitos não-funcionais: 1. O sistema deve ser implementado na linguagem Java. 2. O sistema deve ser implementado de acordo com uma arquitetura de três camadas. 3. O sistema deve utilizar Servlets, JSP, JSF ou uma combinação destas tecnologias. 3 Versão 3: Dados Persistentes Nesta versão, o sistema deve armazenar algumas informações em uma base de dados. Dois tipos de dados devem ser armazenados na base de dados: Lista de códigos IATA para os aeroportos (uma lista suficientemente completa para os propósitos do trabalho pode ser obtida em http://openflights.org/data.html). Resultados de buscas recentes interessantes. A lista de códigos IATA deve ser usada para que o sistema possibilite ao usuário buscar o código correto para uma dado aeroporto. As interfaces de busca de voos (tanto a busca básica, quanto a avançada) devem permitir que o usuário busque os códigos a partir do nome ou parte do nome de uma cidade ou aeroporto. A busca pode ser feita em uma página separada das páginas de busca de voos, contato que o usuário possa retornar à página de busca com outros valores para os campos de formulário que já haviam sido preenchidos intactos. Uma busca recente é deve ser considerada interessante pelo sistema (e portanto armazenada na base de dados) se as seguintes condições forem verdadeiras. Em primeiro lugar, a busca deve ser para uma viagem com apenas um trecho (somente ida) ou dois trechos simétricos (ida e volta). Além disso, o sistema deve verificar se há na base de dados um resultado de busca para o mesmo tipo de viagem (mesmos trechos, independentemente das datas envolvidas). Neste caso, há as seguintes possibilidades: Não há na base um resultado de busca para o mesmo tipo de viagem; o resultado da busca atual é interessante. Há um resultado guardado na base para o mesmo tipo de viagem, mas a data de ao menos um dos trechos é anterior ao dia de hoje; o resultado da busca atual é interessante. Há um resultado guardado na base para o mesmo tipo de viagem e a data de todos os seus trechos é posterior ao dia de hoje, mas o preço do resultado da base é maior que o preço do resultado da busca atual; o resultado da busca atual é interessante. Em qualquer outro caso, o resultado da busca atual não é interessante.
Note que os resultados interessantes incluem apenas uma opção de viagem (a mais barata). A medida que usuários fazem consultas, o sistema deve popular/atualizar a base com as buscas recentes interessantes. Cada vez que a página principal do sistema é acessada, o sistema deve escolher aleatoriamente até 6 destes resultados e exibi-los na interface, incluindo as informações de cidade de origem, cidade de destino, tipo (somente ida ou ida e volta) e valor. Note que apenas resultados cujos trechos tenham data no futuro devem ser escolhidos. Para cada um destes resultados exibidos, deve haver um link ou botão que peça ao sistema que refaça a busca para aquele(s) trecho(s) e encaminhe o usuário aos resultados atualizados (os resultados podem ter mudado desde a última atualização da base de dados). O grupo pode escolher entre duas maneiras de manipular/armazenar os dados: através de um SGBD relacional ou através de arquivos no formato XML. A solução adotada pode combinar as duas opções, se for interessante para o grupo. Em ambos os casos, no entanto, o acesso à base deve ser feito pelas APIs do J2EE (JDBC, no caso do SGBD relacional, ou alguma das APIs que manipulam arquivos XML). Em resumo, nesta versão do sistema, há seguintes requisitos: Requisitos funcionais: 1. O sistema deve permitir que o usuário faça buscas de opções de viagens com até 5 trechos não necessariamente contíguos. RN1: as cidades/aeroportos de origem e destino de cada trecho devem ser especificados pelo usuário utilizando o código IATA, mas o sistema deve dar a opção para que o usuário possa fazer a busca do código com base no nome ou parte do nome da cidade/aeroporto de interesse. 2. O sistema deve permitir que o usuário faça buscas avançadas, especificando como entrada a duração da viagem, as cidades/aeroportos de origem e destino, as cidades ou aeroportos que se deseja visitar (até 4), os tempos máximos e mínimos (em dias) de estadia em cada cidade/aeroporto que se deseja visitar, e o período (data inicial e data final) em que a viagem pode ser realizada. RN2: as cidades/aeroportos de origem e destino de cada trecho devem ser especificados pelo usuário utilizando o código IATA, mas o sistema deve dar a opção para que o usuário possa fazer a busca do código com base no nome ou parte do nome da cidade/aeroporto de interesse. 3. A lista de códigos IATA deve ser armazenada em uma base de dados no servidor. 4. O sistema deve retornar até 500 possibilidades de viagem, conforme retornado pela API. No caso da busca avançada, o limite é de 500 opções de viagem por combinação de datas. 5. O sistema deve exibir as opções de viagem de acordo com o valor total, incluindo impostos. A exibição deve ser feita no formato de uma tabela. Para cada opção de viagem, devem ser exibidos também as empresas aéreas utilizadas, o tempo total de cada trecho e um link ou botão para mais detalhes. 6. Na página de detalhes de opção de viagem, o sistema deve exibir, para cada trecho, todas as conexões e respectivos tempos de espera, todas as escalas envolvidas em cada
conexão, o nome da empresa que opera cada conexão, os horários de partida e chegada de cada conexão, o tempo total de cada trecho da viagem e o valor total, incluindo impostos, da opção. Esta página deve permitir ainda que o usuário volte à página anterior, com a tabela de opções, sem que o sistema precise refazer a consulta à API. 7. A saída deve ser em formato textual e legível. 8. Os aeroportos e empresas listados na saída do sistema devem ser referenciados pelos seus nomes. 9. A entrada de dados no sistema deve ser realizada através do preenchimento de campos de um formulário contendo, para cada trecho, cidade/aeroporto de origem e destino e data de partida. 10. Se o sistema não puder realizar mais consultas à API naquele dia por ter estourado o limite diário de requisições (a API permite no máximo 50 requisições por dia), este deverá apresentar uma mensagem de erro ao usuário. Se o limite for alcançado durante uma busca avançada, o sistema deve retornar os resultados parciais, avisando ao usuário que nem todas as combinações foram exploradas. 11. O sistema deve exibir, na sua página principal, um conjunto de até 6 resultados interessantes armazenados na base de dados. RN3: ss resultados interessantes são armazenados/atualizados na base de dados sempre que o sistema realizar uma busca por viagens de um trecho ou dois trechos simétricos (ida e volta). RN4: os resultados exibidos na página principal devem necessariamente corresponder a opções de viagem cujos trechos são em datas futuras. RN5: a cada resultado exibido, deve corresponder um link ou botão que faça o sistema refazer a busca para a viagem correspondente, exibindo os resultados para o usuário. Requisitos não-funcionais: 1. O sistema deve ser implementado na linguagem Java. 2. O sistema deve ser implementado de acordo com uma arquitetura de três camadas. 3. O sistema deve utilizar Servlets, JSP, JSF ou uma combinação destas tecnologias. 4. As bases de dados devem ser implementadas com base em bancos de dados relacionais ou em arquivos XML. Em ambos os casos, as APIs do J2EE (o JDBC, no caso de bancos de dados relacionais) devem ser usadas para a manipulação das bases. 4 Critérios de Avaliação e Entrega As seguintes datas são sugeridas para a entrega de cada uma das versões do trabalho: Versão 1: 07/10. Versão 2: 30/10.
Versão 3: 04/12. Estas datas são apenas sugestões e cabe aos alunos avaliar a complexidade de cada parte do projeto e determinar com antecedência os prazos para entrega (respeitando-se a data limite de 04/12, na qual, invariavelmente, a última versão deve ser entregue). A definição da data de entrega deve ser feita até uma semana após o início do período de desenvolvimento de cada versão. Cada versão deve ser entregue com código fonte completo e um arquivo do tipo readme explicando, resumidamente, o processo de compilação, o modo de uso do sistema e eventuais outras informações relevantes para a compilação e execução do sistema. Na data da entrega, os integrantes do grupo devem se reunir com o professor e devem estar preparados para explicar detalhes da implementação. As perguntas podem ser feitas para qualquer membro do grupo. A cada versão do trabalho será atribuída uma nota de 0 a 4. Isto significa que a soma das notas pode totalizar 12 pontos. No caso da nota do grupo ou de um dos componentes ultrapassar 10 pontos, a mesma será truncada para 10. A nota atribuída a cada versão do trabalho será de acordo com os seguintes critérios: Aderência aos requisitos da versão: até 1 ponto. Qualidade da documentação (incluindo arquivo readme): até 1 ponto. Organização do código: até 1 ponto. Conhecimento do sistema por parte de cada integrante: até 1 ponto. O último item é de avaliação individual e, por isso, membros diferentes do mesmo grupo podem obter notas finais distintas. Note que faz parte do trabalho (em especial da versão 1) o aprendizado de como utilizar a API QPX. É de responsabilidade do grupo consultar a documentação e descobrir como fazer as consultas e extrair os resultados. Note ainda que o grupo deve se certificar de que a especificação do projeto está compreendida e que não há inconsistências. Em caso de dúvidas, é responsabilidade do grupo entrar em contato com o professor, seja no horário de aula ou através de e-mail, para que os requisitos e especificações possam ser esclarecidos.