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

Será desenvolvida uma aplicação web cujo objetivo é facilitar a gerência de eventos e viagens. Tal aplicação terá como público alvo usuários comuns e 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 serão 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.
• Será utilizada linguagem HTML.
• Serão utilizadas as ferramentas de desenvolvimento:

-Bootstrap;

-Javascript;

-PHP;

-AJAX;

-jQuery;

-Json.

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 será desenvolvido com o objetivo de gerenciar excursões facilitando acesso às informações referentes ao transporte, passageiros, parceiros e eventos. O sistema auxiliará 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 deverá 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 deverá 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 deverá 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 poderá visualizar datas de caravanas, localização e horários do evento, seus dados de pagamento e enviar mensagens ao Organizador.

O usuário do tipo Organizador deverá pertencer a uma instituição. Uma instituição poderá ter vários organizadores. Este terá 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 terá acesso aos relatórios estatísticos e financeiros de seus eventos e às listas de passageiros.

O usuário do tipo Moderador deverá pertencer a uma instituição. Uma instituição poderá ter apenas um Moderador. Ele terá 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 terá todos os acessos de Passageiro, Organizador e Moderador, além de poder alterar e excluir usuários do sistema.

O sistema será 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.

Diagramas de casos de uso complexos

O esquema representado na FIGURA 5 mostra o caso de uso Manter evento expandido. É possível visualizar a interação dos atores com o caso de uso, bem como outros casos de usos que podem ser acessados durante a interação.

A FIGURA 6 mostra a interação do atores com o caso de uso Confirmar pagamento, onde o cliente solicita a confirmação de pagamento e o moderador ou organizador a efetivam.

O caso de uso Manter rota é representado na FIGURA 7. O esquema mostra que o ator organizador tem acesso a todas as funcionalidades do requisito, enquanto que o ator cliente tem acesso apenas a visualização.

Diagrama de classes conceitual

Para Pressman (2011, p. 166) a modelagem de classes:

...representa os objetos que o sistema irá manipular, as operações (também denominadas métodos ou serviços) que serão aplicadas aos objetos para efetuar
a manipulação, os relacionamentos (alguns hierárquicos) entre os objetos e as colaborações que ocorrem entre as classes definidas. 

A seguir será representado pela FIGURA 8 o diagrama de classes conceitual do sistema. Neste estão descritos os métodos que compõem cada classe do sistema. Os usuários do sistema podem ser um cliente, um moderador ou um organizador. O moderador está associado a uma instituição. A instituição cria um ou mais eventos e poderá nomear usuários para serem organizadores. Os eventos podem ter muitos participantes e possuírem uma ou mais rotas. Estas, por sua vez podem ter nenhum ou muitos pontos de parada. Usuários, instituições e eventos devem possuir um endereço.

VIAJE FÁCIL

O presente capítulo discorrerá sobre a implementação do aplicativo Viaje Fácil. Serão apresentados os diagramas do projeto e alguns resultados obtidos no desenvolvimento.

DIAGRAMAS DO PROJETO

A seguir serão apresentados os diagramas entidade relacionamento e de sequência.

Diagrama entidade relacionamento

A FIGURA 9 apresenta o diagrama entidade relacionamento (Workbench) do aplicativo Viaje Fácil.

Diagramas de sequência de casos de uso complexos

De acordo com Pressman (2011, p. 733) o diagrama de sequência é utilizado para representar as interações entre os objetos durante a execução de uma tarefa, mostrando a ordem temporal das mensagens que são enviadas entre os objetos para executar aquela tarefa.

O diagrama de sequência do caso de uso Manter evento está representado na FIGURA 10. O organizador acessa o método cadastrar evento que tem como retorno uma variável booleana que indicará se o evento foi cadastrado. O moderador acessa o método aprovar evento que também tem como retorno uma variável booleana. O organizador também acessa os métodos consultar evento, editar evento e excluir evento.

REFERÊNCIAS BIBLIOGRÁFICAS

APACHE. Tomcat. Disponível em: <http://tomcat.apache.org/index.html>. Acesso em: 26 abr. 2018.

BOOCH, Grady. UML: guia do usuário. Grady Booch, James Rumbaugh, Ivar Jacobson ; tradução de Fábio Freitas da Silva e Cristina de Amorim Machado. - Rio de Janeiro: Elsevier, 2012. - 12a reimpressão.

ECLIPSE. Descrição do pacote. Disponível em: <https://www.eclipse.org/downloads/packages/eclipse-ide-java-ee-developers/oxygen3a>. Acesso em: 26 abr. 2018.

PRESSMAN, Roger S. Engenharia de Software: uma abordagem profissional. Roger S. Pressman ; tradução Ariovaldo Griesi, Mario Moro Fecchio ; revisão técnica Reginaldo Arakaki, Julio Arakaki, Renato Manzan de Andrade. - 7. ed. - Porto Alegre: AMGH, 2011.

SALERNO, A. O mercado de trabalho, os impactos da tecnologia e as tendências de carreiras. Disponível em: <https://canaltech.com.br/carreira/O-mercado-de-trabalho-os-impactos-da-tecnologia-e-as-tendencias-de-carreiras/>. Acesso em: 10 abr. 2018.