GuiaGuide: mudanças entre as edições
Linha 122: | Linha 122: | ||
===Diagrama Entidade Relacionamento (Workbench)=== | ===Diagrama Entidade Relacionamento (Workbench)=== | ||
Para que o sistema possa armazenar e manipular dados e informações foi necessária a criação de um banco de dados, o qual foi implementado na linguagem PostgreSQL na sua versão 10. A figura a seguir demonstra a representação gráfica das tabelas do banco de dados, seus atributos e o relacionamento existente entre elas. |
Edição das 15h57min de 31 de agosto de 2018
Equipe
- Professores/Orientadores
- Alcione Benacchio
- Wellington Oliveira
- Alunos
- Ederson Luiz Knoll
- Gustavo Mendes Ferreira
- Rodrigo Dantas Teixeira
Introdução
O turismo no Brasil vem destacando-se no cenário mundial. De acordo com Oliveira (2017), em uma comparação entre 136 países em que foram analisadas 14 dimensões do turismo o Brasil aparece na 27º colocação, segundo o Ranking de Competitividade de Viagens e Turismo divulgado em 2017 pelo Fórum Econômico Mundial, sendo o primeiro da América do Sul na pesquisa, e o primeiro do mundo no quesito recursos naturais. Concomitante a divulgação deste relatório segundo a Agência de Notícias do Turismo (2017), o Governo Federal anunciou um pacote de medidas para desenvolver o setor de turismo no país implantando assim o programa Brasil + Turismo que busca principalmente um melhor aproveitamento de nosso potencial turístico tendo como uma de suas metas alcançar 12 milhões de turistas estrangeiros anuais até 2022, além de incentivar também o turista local.
Neste cenário em expansão, um profissional imprescindível para consolidação desse crescimento é o Guia de Turismo. Conforme o artigo primeiro da Lei 8.623 (BRASIL, 1993) o exercício da profissão de Guia de Turismo é regulamentada e o profissional deve possuir curso técnico de formação em Guia de Turismo além de estar habilitado no Cadastro dos Prestadores de Serviços Turísticos - CADASTUR.
Dentre as principais atribuições deste profissional podemos destacar: atividades de acompanhamento, orientação e transmissão de informações a pessoas ou grupos, em visitas, excursões urbanas, municipais, estaduais, interestaduais, internacionais ou especializadas, dentre outras.
Problemas
- Escassez de informações de regiões turísticas regionais e seus atrativos, segmentadas por cidade, ponto turístico e/ou categoria;
- Falta de informações sobre profissionais Guias de Turismo que atuem em determinadas regiões ou pontos turísticos;
- Dificuldade de encontrar um Guia de Turismo que não seja por intermédio de empresas;
- Dificuldade em contratar pequenos serviços prestados por Guias de Turismo;
- Escassez de ferramenta web dedicada ao profissional Guia de Turismo, para a divulgação de seus serviços;
Objetivo
Este projeto tem por objetivo o desenvolvimento de um sistema web para divulgação dos principais pontos turísticos regionais, com o intuito de fomentar principalmente a atividade do profissional Guia de Turismo que atua nessas regiões, através de uma plataforma em que é possível a divulgação de seus serviços para um público segmentado e com interesses bastante definidos. Esse público será naturalmente composto por pessoas interessadas em viagens a passeio, turismo de compras, turismo de aventura, turismo rural, turismo histórico e cultural, dentre outros seguimentos. Além de proporcionar ferramentas para que o Guia de Turismo exponha sua atividade profissional e obtenha maior visualização no mercado. Este sistema também irá complementar as ações de estados e municípios na ampla divulgação de seus atrativos, buscando captar ainda mais visitantes e de forma indireta contribuindo para fomentar toda a cadeia da atividade turística.
Modelagem
Levantamento de Requisitos
O levantamento de requisitos é realizado na fase inicial do desenvolvimento de software e deve abranger o levantamento de dados e informações sobre o contexto das atividades que serão suportadas pelo sistema. De acordo com Silva (2008): “requisito é uma especificação de uma característica ou propriedade que um sistema deve possuir ou fazer, assim como sua restrição de operação”. No presente trabalho foram definidos os Requisitos Funcionais, Requisitos Não Funcionais Tecnológicos e Regras de Negócio.
Requisitos Funcionais
A necessidade de atender determinadas funcionalidades do software é concretizada através de funções desenvolvidas a partir do levantamento dos requisitos funcionais a seguir descritos:
Código | Requisito Funcional |
---|---|
RF 01 | O sistema deve manter “Guias” com os seguintes dados: usuário, nome, data de nascimento, data de cadastro, sexo, número de certificado CADASTUR, foto, endereço (país, estado, cidade, bairro, cep, rua, numero), e-mail, telefones para contato, senha, idiomas, redes sociais (opcional), categoria, empresas que trabalhou, e um pequeno texto (sobre mim) onde o profissional possa detalhar mais sobre sua experiência e histórico profissional (breve currículo). |
RF 02 | O sistema deve manter “Turistas” com os seguintes dados: usuário, nome, data de nascimento, data de cadastro, sexo, endereço (país, estado, cidade, cep, bairro, rua, número), e-mail, telefones para contato, senha, redes sociais (opcional) e regiões ou pontos turísticos de interesse (opcional). |
RF 03 | O sistema deve permitir a busca de “Guias” por cidade, ponto turístico, categoria e idioma. |
RF 04 | O sistema deve permitir um comparativo (Ranking) entre os Guias cadastrados, com pontuação expressa na escala likert de 5 níveis, resultantes da média das avaliações feitas pelo “Turista”. |
RF 05 | O sistema deve manter a avaliação do turista para o guia. A avaliação ficará visível para todos usuários do sistema. |
RF 06 | O sistema deve manter a avaliação do guia para o turista. A avaliação ficará visível somente para outro guia. |
RF 07 | O sistema deve manter e permitir a troca de mensagens entre guia e turista. |
RF 08 | O sistema deve manter Países, Estados e Cidades cadastrados pelo administrador do sistema. |
RF 09 | O sistema deve controlar o acesso dos usuários por meio de login e senha. |
RF 10 | O sistema deve manter Ponto Turístico, com os seguintes dados: nome, fotos, endereço (estado, cidade , cep, bairro, numero, rua), horário de funcionamento. |
RF 11 | O sistema deve permitir a troca de idiomas em momento de execução. |
RF 12 | O sistema deve manter Negociação. A negociação deve possuir sempre um "Guia", um "Turista", um ou mais pontos turísticos, data de abertura, data de encerramento e status. |
Lista de Requisitos Não Funcionais Tecnológicos
Os requisitos não funcionais foram levantados a partir de necessidades externas para o desenvolvimento do projeto como a infraestrutura, as ferramentas necessárias e a organização. No quadro a seguir foram elencados alguns requisitos não funcionais tecnológicos:
Código | Requisito Não Funcional Tecnológico |
---|---|
RNFT 01 | O sistema deve ser compatível com os principais navegadores web, e possuir layout responsivo. |
RNFT 02 | Deve ser desenvolvido em linguagem JAVA para o servidor de serviços (WebService), PHP para controles de sessão, utilizando-se elementos JQuery e o Framework Foundation para o Front End além de folhas de estilos em CSS e bibliotecas Java Script. As IDEs Eclipse e PHPStorm serão utilizadas para auxiliar no desenvolvimento. |
RNFT 03 | O sistema deve utilizar o banco de dados PostgreSQL. |
RNFT 04 | Utilizar o Framework Spring para realizar o mapeando de objetos relacionais. |
RNFT 05 | Todo o sistema deve ser mantido e hospedado em um servidor físico para o gerenciamento dos serviços e do banco de dados. |
Lista de Regras de Negócio
Em complementação aos requisitos funcionais e não funcionais existem as regras de negócio que, de acordo com Ventura (2016) referem-se a premissas ou restrições do negócio propriamente dito e devem atender as expectativas comerciais da empresa ou do setor para o qual o software está sendo desenvolvido, neste contexto no quadro abaixo foram elencadas as regras de negócio do sistema Guia Guide:
Código | RF | Regra de Negócio |
---|---|---|
RN 01 | 01 | O guia deve concordar em divulgar seus dados para o público do sistema. |
RN 02 | 01 | O guia deve informar obrigatoriamente o seu registro no CADASTUR. |
RN 03 | 02 | O turista deve concordar em divulgar seus dados para os guias do sistema. |
RN 04 | 06 | O guia somente terá acesso aos dados de um turista caso esteja em status de negociação aberto com o mesmo. |
RN 05 | 06 | O guia deve aceitar abrir uma negociação, somente mediante solicitação prévia do turista. |
RN 06 | 07 | O envio de mensagens somente poderá ser iniciado pelo turista. |
RN 07 | 12 | Uma negociação somente poderá ser iniciada se o turista escolher no mínimo um ponto turístico. |
Diagramas de Análise e Modelagem do Sistema
Os diagramas de análise e modelagem do sistema são concebidos na linguagem UML e tem por objetivo representar o sistema em níveis diferentes de detalhes. Segundo o IBM Knowledge Center os diagramas UML ilustram os aspectos qualificáveis de um sistema que podem ser descritos visualmente, como relacionamentos, comportamento, estrutura e funcionalidade.
Diagrama de Caso de Uso Geral
Diagrama de Classes Conceitual
Diagramas do Projeto
Diagrama Entidade Relacionamento (Workbench)
Para que o sistema possa armazenar e manipular dados e informações foi necessária a criação de um banco de dados, o qual foi implementado na linguagem PostgreSQL na sua versão 10. A figura a seguir demonstra a representação gráfica das tabelas do banco de dados, seus atributos e o relacionamento existente entre elas.