Usuário:ViageFacil

INTRODUÇÃO

De acordo com Salerno (2015), os avanços da tecnologia estão trazendo grandes inovações e seus impactos já podem ser vistos em inúmeros setores. Seus recursos estão se tornando cada vez mais indispensáveis em nossa rotina. Tarefas comuns como comer, se vestir, deslocar-se de um lugar para outro e até mesmo relacionar-se com outras pessoas são confiadas a aplicativos e sites criados e programados para facilitar a vida.

Para muitas pessoas, planejar uma viagem acaba sendo uma atividade um tanto inconveniente pois necessita-se de tempo para pesquisar datas e preços, ficando na maioria das vezes condicionado aos pacotes de viagens.

Pensando em facilidade, este projeto apresenta uma solução que ajudará na interação interpessoal, propondo ao seu usuário criar grupos de viagens para planejar, organizar e administrar os vários recursos necessários em uma viagem.

OBJETIVO GERAL

Criar uma ferramenta simples e de fácil acesso para instituições criarem e gerenciarem eventos que envolvam viagens, ou excursões, e ajudar os usuários do sistema a encontrar e participar destes eventos.

OBJETIVOS ESPECÍFICOS

• Analisar como a aplicação desenvolvida poderá ajudar as instituições a gerenciar os eventos e viagens com base nos feedbacks e comentários dos usuários.
• Pesquisar como são gerenciados os eventos e viagens nas instituições, para poder melhorar o processo.
• Desenvolver uma aplicação que possa auxiliar as instituições e também os clientes a participar de eventos e viagens.
• Criar um aplicativo que atenda tanto instituições com grandes eventos e grande número de participantes, quanto clientes comuns que desejam gerenciar apenas pequenos eventos.

METODOLOGIAS

Desenvolveu-se uma aplicação web cujo objetivo é facilitar a gerência de eventos e viagens. Tal aplicação tem como público alvo usuários comuns e também instituições que tenham a demanda de fazer viagens para eventos (como, por exemplo, faculdades que organizam excursões para participar de fóruns ou palestras).

Para o desenvolvimento do projeto foram utilizadas as ferramentas:

• Eclipse - Ferramenta para desenvolvedores Java que criam aplicativos Java EE e Web, para a construção de Web Services;
• Apache Tomcat - software livre de implementação das tecnologias Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket que integra sistemas web, para executar as mesmas.

ESTUDO DE CASO

Este capítulo descreve o trabalho de modelagem realizado em linguagem UML, bem como os requisitos e diagramas da aplicação .

CONTEXTUALIZAÇÃO

O sistema foi desenvolvido com o objetivo de gerenciar excursões facilitando acesso às informações referentes ao transporte, passageiros, parceiros e eventos. O sistema auxilia os organizadores a gerenciar as listas de passageiros, eventos, localização e dados financeiros da viagem e facilitará aos passageiros acesso às informações da viagem.

O sistema deve manter:

• Usuários (com diferentes níveis de acesso: Administrador, Moderador, Organizador e Passageiro);
• Eventos (localização, rota de viagem, datas, valores, lista de passageiros e confirmação de pagamentos);
• Agências de Viagem (nome, endereço, contato, frota e valores);
• Instituições (nome, endereço, contato e tipo).

O sistema deve criar excursões com listas de passageiros, dados do evento, tempo de viagem, empresa responsável, veículos utilizados e gera relatórios com estatísticas de viagens e relatórios financeiros da viagem. O sistema deve tratar 3 tipos de mensagens. O primeiro tipo de mensagem é para o Moderador do sistema, que são sugestões e reclamações dos usuários sobre o evento. O segundo tipo de mensagem é composto por alertas para os organizadores, esses alertas são: inclusão de passageiro a um evento, confirmação de pagamento e a troca de mensagens direta do passageiro com o Organizador. O terceiro tipo é um grupo ao qual todos os passageiros e organizador poderão trocar mensagens livremente.

O acesso do tipo Passageiro pode visualizar datas de caravanas, localização e horários do evento, seus dados de pagamento e enviar mensagens ao Organizador.

Os usuários do tipo Organizador devem pertencer a uma instituição. Uma instituição pode ter vários organizadores. Este tem todos os acessos do usuário do tipo Passageiro, além de poder adicionar ou alterar informações de excursões (que devem ser posteriormente aprovadas pelo Moderador), passageiros e eventos. Esse tipo de usuário tem acesso aos relatórios estatísticos e financeiros de seus eventos e às listas de passageiros.

O usuário do tipo Moderador devem pertencer a uma instituição. Uma instituição pode ter apenas um Moderador. Ele tem todos os acessos dos usuários dos tipos Passageiro e Organizador, além de poder gerenciar todas as informações de todos os eventos e excursões criados pelos Organizadores de sua Instituição.

O usuário do tipo Administrador tem todos os acessos de Passageiro, Organizador e Moderador, além de poder alterar e excluir usuários do sistema.

O sistema foi desenvolvido para executar na plataforma WEB.

LEVANTAMENTO DE REQUISITOS

De acordo com Pressman (2011, p. 133), o levantamento de requisitos combina elementos de resolução de problemas, elaboração, negociação e especificação. São necessários para definir com o sistema irá funcionar e suas características.

A seguir serão descritas as lista de requisitos do sistema. O QUADRO 1 apresenta a lista de requisitos funcionais ou operações do sistema, o QUADRO 2 apresenta a lista de requisitos não funcionais tecnológicos ou as tecnologias utilizadas para o desenvolvimento e o QUADRO 3 apresenta a lista de regras de negócio.

QUADRO 1 - Lista de requisitos funcionais

Código	Requisito funcional
RF 1	O sistema deve manter usuários. Os usuários podem ser do tipo Cliente, Organizador, Moderador e Administrador. Os usuários Organizador, Moderador e Administrador devem possuir CPF, RG, nome, endereço, telefone, e-mail, login e senha. Os usuários Cliente deve possuir e-mail, login e senha. Além dos dados comuns os usuários do tipo Organizador e Moderador devem pertencer a uma instituição.
RF 2	O sistema deve manter eventos. Cada Evento deve possuir Título, Descrição, Data Saída Origem, Data Retorno Origem, Data Evento, Rota de Ida, Rota de Retorno, Instituição, Responsável (Organizador ou Moderador) e Lista de Participantes.
RF 3	O sistema deve manter Instituições. As Instituições devem ter Nome, Endereço, Telefone, Email e um Moderador.
RF 4	O sistema deve manter participante. Os participantes são compostos pelo cliente, evento e status de pagamento.
RF 5	O sistema deve possuir confirmações de pagamento.
RF 6	O sistema deve ser capaz de enviar mensagens. As mensagens podem ser entre Organizador e Passageiro, ou de um Passageiro para o grupo do evento. Também podem ser mensagens de notificação sobre eventos para os Organizadores e Moderadores.
RF 7	O sistema deve gerar relatórios. Os relatórios podem ser Listas de Participantes com de status de pagamento do evento, Relatório de viagens do Cliente e histórico de viagens das Instituições.
RF 8	O sistema deve criar rotas. Essas rotas devem ser traçadas do ponto inicial da viagem até o destino, devendo aparecer na rota as paradas programadas. No meio das viagens a rota deve ser traçada da localização atual do passageiro até o destino final da viagem.
RF 9	O sistema deve controlar o acesso por meio de login e senha.

QUADRO 2 - Lista de requisitos não funcionais tecnológicos

Código	Requisito não funcional tecnológico
RFNT 1	O sistema terá interface WEB.
RFNT 2	O sistema será desenvolvido na linguagem Java, HTML, PHP e Java Server Pages utilizando Eclipse.
RFNT 3	Será utilizado o Framework Hibernate para integração com o Banco de Dados.
RFNT 4	O sistema utilizará banco de dados POSTGRESQL.
RFNT 5	O sistema deve apresentar documentação com linguagem UML utilizando ferramenta Astah.
RFNT 6	O aplicativo utilizará APIs de Geolocalização do Google.

QUADRO 3 - Lista de regras de negócio

Código	RF	Regra de negócio
RFNT 1	RF 1, RF 9	O sistema deve prever hierarquia de acesso às funcionalidades.
RFNT 2	RF 1, RF 2	Usuário do tipo Cliente tem acesso de leitura a todos os eventos Abertos, podendo se inscrever em qualquer um deles.
RFNT 3	RF 1, RF 7	Usuário do tipo Cliente efetuará seu próprio cadastro e terá acesso somente às informações dos próprios pagamentos e eventos que se inscreveu.
RFNT 4	RF 1	Usuário do tipo Organizador só poderão ser cadastrados por um usuário do tipo Moderador.
RFNT 5	RF 1, RF 2, RF 8	Usuário do tipo Organizador terá acesso para criar Eventos e acesso para edição ou exclusão dos próprios Eventos.
RFNT 6	RF 1, RF 5	Usuário do tipo Organizador poderá confirmar pagamento dos participantes de seus próprios eventos.
RFNT 7	RF 1, RF 2, RF 8	Usuário do tipo Moderador terá acesso para criar Eventos e setar um Organizador como responder e acesso para edição ou exclusão dos Eventos da Instituição.
RFNT 8	RF 1, RF 3	Usuário do tipo Moderador será cadastrado somente junto com o cadastro de uma Instituição.
RFNT 9	RF 1, RF 5	Usuário do tipo Moderador poderão confirmar pagamentos de todos os eventos da instituição.
RFNT 10	RF 2, RF 4, RF 6	Os participantes serão incluídos no Eventos pelo Organizador, Moderador ou pelo próprio Cliente. Quando um Cliente se inscreve em um evento é enviado um pedido para o Organizador do evento, ou Moderador. A inscrição do Participante só é concretizada com a aprovação do Organizador ou Moderador.

DIAGRAMAS DE ANÁLISE E MODELAGEM DO SISTEMA

Booch (2012, p. 7) afirma que por meio da modelagem podem ser alcançados quatro objetivos:

• Os modelos ajudam a visualizar o sistema como ele é ou como desejamos que seja;
• Os modelos permitem especificar a estrutura ou o comportamento de um sistema;
• Os modelos proporcionam um guia para a construção do sistema;
• Os modelos documentam as decisões tomadas.

Os casos de uso são utilizados para captar o comportamento desejado do sistema que está sendo desenvolvido, sem necessidade de especificar como esse comportamento é implementado (BOOCH, 2012, P. 246). O seguinte subcapítulo apresentará os diagramas de análise e modelagem do sistema desenvolvidos em linguagem UML.

Diagrama de caso de uso geral

A FIGURA 4 representa o diagrama de caso de uso geral do sistema. Nota-se os níveis de acesso que cada ator/usuário tem no sistema. O moderador tem acesso a todas as funções do sistema, organizador não tem acesso apenas ao Manter instituição e o cliente tem acesso apenas às suas informações e consultas.

Erro ao criar miniatura: /bin/bash: /usr/bin/convert: No such file or directory Error code: 127